Buscar

artigo_modeloprocessosoftware

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 8 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 8 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Modelos de Processo de Software 
Antonio Arias Silva Oliveira
1
 
1Departamento de Informática – Universidade Federal do Pará (UFPA) 
Rua Augusto Corrêa, 01 – 66.075-110 – Belém – PA – Brazil 
{arias,antonio.arias}@globo.com 
Abstract. We will show the parade of presentations done by several teams of 
the Piracy of Specialization in it Manages of Projects of Software, in the 
discipline "Model of Process of Software", supplied by the teacher and master 
Paulo Bastos. They were 10 models presented by the teams among the days 
19/04 to 24/05/2007 in the Federal University of Pará. It was a singular 
experience, to see those works cousins of the Engineering of Software to be 
shown and discussed for about 36 students, giving their opinions, asking what 
nobody had asked. The lesson was reviewed masterfully. We don't know which 
is the best, but now we are great aware in the transport and orientation of a 
development team, our role as Managers of Projects of Software. 
Resumo. Vamos mostrar o desfile de apresentações feito por várias equipes 
do Corso de Especialização em Gerencia de Projetos de Software, na 
disciplina “Modelo de Processo de Software”, ministrada pelo professor e 
mestre Paulo Bastos. Foram 10 modelos apresentados pelas equipes entre os 
dias 19/04 a 24/05/2007 na Universidade Federal do Pará. Foi uma 
experiência singular, ver essas obras primas da Engenharia de Software ser 
mostradas e discutidas por cerca de 36 alunos, dando suas opiniões, 
perguntando o que ninguém havia perguntado. A lição foi magistralmente 
repassada. Não sabemos qual é o melhor, mas agora temos grande 
consciência na condução e orientação de uma equipe de desenvolvimento, 
nosso papel como Gerentes de Projetos de Software. 
1. Introdução 
Podemos dizer com uma grande dose de certeza que “Modelos de Projeto de Software” 
é o veículo que conduz qualquer projeto de software rumo ao sucesso e qualidade. Bom, 
mas qualidade é algo abstrato, difícil de ser definido. Portanto vamos recorrer a um 
pouco de história da qualidade para podermos entender melhor esse conceito. 
A história da qualidade está repleta de exemplos de resultados extraordinários: os 
grandes templos construídos na Grécia e Roma antigas, os feitos de navegação do século 
XVI, as catedrais medievais. Em todas essas realizações, não se dispunha de 
instrumentos de precisão ou técnicas sofisticadas. Na França, os construtores de 
catedrais utilizavam simples compassos e cordas com nós a intervalos regulares para 
desenhar e construir edifícios [Koscianski 2006]. 
Na década de 1920 surgiu o controle estatístico de produção. Nas fábricas que 
produziam grande quantidade de itens tornou-se impossível garantir a qualidade 
individual de cada peça, ao contrário do que se fazia (e ainda faz) no trabalho artezanal. 
 
Dessa forma foi preciso desenvolver mecanismos diferentes e a resposta veio da 
estatística. 
Um dos pioneiros trabalhos associados ao assunto é o livro publicado por Walter 
Shewhart em 1931, Economic Control of Quality of Manufactured Producto. Shewhart, 
dos Bell Laboratories, teria introduzido os diagramas de controle (control charts ou 
Shewhart chart). [Koscianski - 2006]. 
Na década de 1940 foi fundado a ABNT (Associação Brasileira de Normas Técnicas) e 
a ISO (International Standardization Organization). Também o Japão destacou-se como 
um importante pólo no assunto e contribuiu com diversas novas ferramentas: o método 
de Taguchi para projeto experimental, a metodologia 5S ou, ainda, os diagramas de 
causa e efeito de Ishikawa, também conhecidos como diagrama espinha de peixe. 
[Koscianski - 2006] 
Estas citações nos mostram claramente que a qualidade de um programa de computador 
segue as mesmas especificações de um produto qualquer da indústria tradicional. 
 
2. Os Modelos de Desenvolvimento 
 Vamos então nos focar nos modelos, como eles surgiram e evoluirão. Nas 
décadas 1960 e 1970 ocorreram mudanças tecnológicas importantes que afetaram a 
construção dos computadores e, em conseqüência, a de software. O período é conhecido 
como “crise de software” e as repercussões são sentidas até hoje [Pressman, 2002]. 
 A maior causa da crise de software é que as máquinas tornaram-se várias ordens 
de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, 
programar não era um problema; quando tivemos computadores fracos isso se tornou 
um problema pequeno e agora que temos computadores gigantescos, programar tornou-
se um problema gigantesco. [Koscianski, 2006] 
 
2.01. Modelo em Cascata 
 No dia 19 de abril de 2007, na disciplina “modelos de processos de software”, do 
curso de Especialização em Gerencia de Projetos de Software, foi dado inicio a um 
desfile de apresentações, feitas pelos alunos. O primeiro o “Modelo em Cascata”. Dos 
modelos prescritivos, o cascata é, sem dúvidas, o mais referenciados e discutidos em 
estudos e trabalhos acadêmicos e aplicações. Quando os requisitos de um problema são 
razoavelmente bem compreendidos, o trabalho flui da comunicação de um modo 
razoavelmente linear, recomenda-se o cascata. 
 O modelo em cascata é o paradigma mais antigo da engenharia de software, 
entretanto nas últimas décadas esse modelo tem sofrido muitos questionamentos. Talvez 
por essa razão ele seja o modelo mais evidente. 
 Podemos citar três problemas em que o cascata é aplicado: 
1) Projetos reais raramente seguem fluxos seqüenciais que o modelo propõe. 
Apesar de o modelo linear poder acomodar iterações, ele o faz indiretamente. 
Como resultado, as modificações podem causar confusão à medida que a equipe 
de projeto prossegue. 
2) Em geral, é difícil para o Cliente estabelecer todos os requisitos 
explicitamente. O modelo em cascata exige isso e tem dificuldade de 
acomodar a incerteza natural que existe no começo de muitos projetos. 
3) O Cliente precisa ter paciência. Uma versão executável do(s) programa(s) 
não vai ficar disponível até o período final do intervalo de tempo do 
projeto. Um erro grosseiro pode ser desastroso se não for detectado até que 
o programa executável seja revisto. [Pressman, 2005] 
2.02. Modelo de Desenvolvimento Evolucionário 
 Este modelo busca o desenvolvimento de software evoluindo a partir de 
protótipo inicial. Todos os conceitos e idéias vão sendo materializado em requisitos a 
medida que o protótipo evolui, até atingir o produto idealizado. 
 O objetivo é trabalhar com o Cliente em toda a fase do desenvolvimento, a partir 
das especificações iniciais. Entretanto os requisitos devem ser bem compreendidos. 
 O modelo evolucionário pode trazer diversas vantagens, tais como antecipar o 
produto final para avaliação do Cliente, manter uma comunicação entre os 
desenvolvedores e usuários para solucionar problemas técnicos e antecipar o 
treinamento dos usuários. 
2.03. Modelo de Desenvolvimento Rápido (RAD) 
 Aqui o objetivo principal é a velocidade do desenvolvimento. O termo Rapid 
Application Development (RAD) se aplica a projetos que tem prazos curtos e que 
geralmente usa prototipagem e ferramentas de desenvolvimento de alto nível. A 
 
orientação é a construção de componentes e que os requisitos e o escopo sejam bem 
conhecidos por diferentes equipes, conforme figura 1. 
 
Figura 1 – Modelo de processo RAD 
Modelagem do Negócio: 
O fluxo de informação entre os módulos de função d negócio são modeladas para que 
possa responder: 
• Qual a informação que dirige o processo do negócio? 
• Qual a informação gerada? 
• Quem processa? 
• Quem gera a informação? 
• Para onde vai a informação? 
Modelagem dos dados: 
O fluxo definido na modelagem do negócio é refinado em um conjunto de objetos de 
dados necessários para dar suporte ao negócio; 
Aqui são identificadas as características e seus relacionamentos para cadaobjeto. 
Modelagem do Processo: 
Os objetos de dados são transformados para obter uma função de negócio. 
Geração da Aplicação: 
De posse dos componentes a aplicação é gerada. São utilizados ferramentas 
automatizadas tal como o GeneXus. 
2.04. Modelo Formal 
 Este modelo requer Clientes tecnicamente bem preparados, engenheiros de 
software com conhecimento profundo do negócio em questão. E as especificações 
devem ser bem consistentes, claras sem qualquer ambigüidade. Utiliza fortemente os 
modelos matemáticos nas especificações. Portanto recomendado para aplicação 
extremamente crítica 
 
 Os métodos formais têm um potencial tremendo para melhorar a clareza e a 
precisão da especificação dos requisitos e de encontrar erros importantes e sutis. 
 O método é formal tem uma sólida base matemática, dada tipicamente por uma 
linguagem formal de especificação. Essa base fornece um meio para definir 
precisamente noções como consistência e completeza, e mais relevantemente, 
especificação, implementação e correção. 
2.05. Modelo de Desenvolvimento Orientado a Reuso 
 A reutilização sempre foi utilizada por outras engenharias. Apenas nos últimos 
anos é que a engenharia de software começou adotar o reuso como uma abordagem 
prática no desenvolvimento de software. 
 A reutilização é o processo de incorporar em um novo produto: 
• Código; 
• Plano de Teste; 
• Conhecimento Geral; 
• Especificações de requisitos e projetos. 
2.06. Modelo de Desenvolvimento Incremental 
 O modelo incremental combina diversos elementos do Modelo em Cascata, 
dividindo os requisitos em incrementos, de maneira a garantir um melhor entendimento 
e uma maior participação do Cliente. Usa bem o conhecimento adquirido em projetos 
anteriores. É um modelo que objetiva minimizar os riscos do projeto, dando maior 
importância aos requisitos mais importantes. Veja figura 2. 
 
Figura 2 – Modelo de processo Incremental 
 Podemos dizer que este modelo é de fácil gerenciamento. Possibilita o aumento 
da qualidade do software, facilitando a integração e reduzindo as falhas. E o projeto 
pode ser tocado com pouca mão-de-obra. 
 Entretanto trata-se de um modelo, cujo software desenvolvido é de difícil 
modularização. Também não permite alterações nos requisitos durante os incrementos. 
 
2.07. Modelo de Desenvolvimento em Espiral 
Este modelo surgiu com o objetivo de resolver os seguintes problemas: 
- Os projetos raramente seguem o fluxo seqüencial que o modelo Cascata propõe 
- No início do projeto é difícil para o cliente especificar os requisitos 
explicitamente 
- Na Prototipagem o cliente vê o que parece ser uma versão executável do 
software, ignorando que o protótipo apenas consegue funcionar precariamente. 
Para tanto é esperado que os requisitos básicos estejam bem entendidos, muito embora 
os detalhes ainda precisem ser definidos. O produto evoluirá com o tempo, gerando 
versões cada vez mais completas. 
2.08. Modelo do Processo Unificado 
 O RUP é uma abordagem de desenvolvimento de software de forma iterativa, 
baseada na arquitetura e dirigida por casos de uso, que são levantamentos de requisitos 
baseados na visão do usuário. Também pode ser definido como um processo de 
engenharia de software bem definido e bem estruturado. Definindo de forma clara e 
precisa quem é responsável, como e quando será feito. 
 É composto por cinco elementos principais: papéis, atividades, artefatos, fluxos 
de trabalho e disciplinas, conforme figura 3. 
 
Figura 3 – Fases e disciplinas do modelo RUP 
 Após atingir o consenso dos envolvidos, dentro da fase conhecida como 
concepção, inicia-se a meta dominante. O objetivo da fase concepção é estabelecer o 
escopo do sistema, fazer um esboço da arquitetura, identificar os riscos, estimar 
tempo/custo e a viabilidade do sistema. E na seqüência as atividades básicas, com o 
planejamento e preparação do caso de negócio, formular o escopo, sintetizar a 
arquitetura e preparar o ambiente. 
 
 Depois as fases de Elaboração, Construção e Transição, onde o software já pode 
ser disponibilizado para o usuário final. 
 
2.09. Modelo Paxis 
 Este modelo tem o foco principal no processo educacional da engenharia de 
software. Orientado a objetos e baseado em paradigmas de grande difusão: UML, SW-
CMM, UP e IEEE. Pode ser bem adaptado a uso individual ou para pequenas equipes. 
Indicado para organizações em vias de melhoria de processos. 
 Segue fortemente o Processo Unificado e as fases são compostas por uma ou 
mais iterações. Os fluxos são divididos em uma ou mais atividades, sendo essas 
iterações e atividades exemplos de passos. 
 As fases são: Concepção, Elaboração, Construção e Transição. E os fluxos 
técnicos são: Requisitos, Análise, Desenho, Implementação, Testes e Engenharia de 
Sistemas. E os fluxos gerenciais são: Gestão de Projetos, Gestão de Qualidade e 
Engenharia de Processos. 
 
2.10. XP (eXtreme Programming) 
 
 Quando Kent Beck e outros 16 notáveis desenvolvedores, produtores e 
consultores, em 2001, assinaram o “Manifesto Agil”, estavam buscando valorizar: 
- Indivíduos e interações em vez de processos e ferramentas. 
- Software funcionando em vez de documentação abrangente 
- Colaboração do cliente em vez de negociação de contratos 
- Resposta a modificações em vez de seguir plano 
 Data a dificuldade de predizer quais requisitos serão mantidos e quais vão 
mudar, bem como quais prioridades mudarão. Da mesma forma é muito difícil precisar 
quando um projeto estará pronto para começar. Assim projeto e implementação são 
feitos juntos. 
 O eXtreme Programming busca melhorar a comunicação entre o Cliente e a 
Equipe de desenvolvimento e entre a própria Equipe. É o olho - no - olho. Simplicidade 
para fazer o necessário e respeito ao ser humano. 
 Baseado em princípios e nas práticas para trabalhar lado a lado, Equipe e 
Cliente. Decidindo fazer o que realmente é importante fazer em reuniões, normalmente 
em pé, dando assim maior agilidade as decisões. [Astels 2002] 
 O XP é normalmente recomendado para projetos sujeitos a mudanças, com 
equipes pequenas e Clientes com domínio do negócio. 
 
3. Conclusão 
 Com este desfile de modelos é possível compreender que toda a dificuldade de 
se construir software pode, com simples adoção de um ou mais modelos, assegurar 
grande controle da situação do processo de software. Como em outras engenharias, os 
processos são bem definidos e normalizados para que perdure por todo o ciclo de 
desenvolvimento do produto. E caso aja possível melhoria a ser feita no modelo, é 
providenciado para uma próxima instancia do referido modelo. Na engenharia de 
software também deve ser assim. E mesmo com as dificuldades naturais de se fazer algo 
pouco tangível, devemos buscar adequar um modelo a ser seguido. Qual deles? Isso é 
importante mas, nem tanto. O mais importante é adotar um e segui-lo o mais fielmente 
possível para que os benefícios possam ser colhidos. Deve ser dado tempo suficiente 
para as tarefas advindas dos modelos, preencher os documentos preparar os artefatos, 
seguir o script à risca. As adaptações são necessárias e devem ser feitas mas, sem 
reinventar a roda, se ela já está disponível use-a. 
 
4. References 
Astels, David; Granville Miller e Miroslov Novak, eXtreme Programming – Guia 
Prático, 2002 
Koscianski, André. Qualidade de software, 2006

Outros materiais