Ciclo de vida do software

Transcrição

1 Ciclo de vida do software Ciclo de vida = plano de projeto = metodologia de desenvolvimento de sistema ou O modo como fazemos as coisas por aqui ou Seqüência de fases e atividades a serem desenvolvidas no transcorrer do projeto Por que? 1) Para definir as atividades a serem executadas no projeto 2) Para introduzir consistência entre muitos projetos de desenvolvimento da mesma organização 3) Para introduzir pontos de verificação para o controle gerencial de decisões ( milestones ) 1

2 Ciclo de vida clássico ( Waterfall ou Cascata) Extraída de Jones, 1990 Ciclo de vida clássico ( Waterfall ou Cascata) Dificuldades: Falta de conhecimento sobre o produto que está sendo desenvolvido Ânsia da equipe pela obtenção de algum resultado imediato Contato entre projetista e cliente muito cedo (na Análise de Requisitos) e muito tarde (nos testes de aceitação), sem contatos intermediários 2

3 Ciclo de vida de prototipação Extraída de Jones, 1990 Ciclo de vida de prototipação Protótipos: descartáveis / definitivos em papel, executável, programa já existente (sendo refeito) Dificuldades: Protótipo se torna o produto: coação do usuário análise precária feita para o protótipo torna-se definitiva devido a problemas de prazos 3

4 Desenvolvimento incremental Extraída de Jones, 1990 Desenvolvimento incremental Implementação do sistema parte a parte 1a. Parte: Implementação das estruturas de controle e interfaces homem-máquina Posteriormente: Implementação das partes mais importantes para o usuário Interação com o usuário: através da implementação, ao longo das várias etapas; nas fases iniciais, para a implementação das estruturas de controle e interfaces. Exige planejamento cuidadoso das fases. Dificuldades: Não se deve alterar a metodologia ao longo do desenvolvimento 4

5 Ciclo para reutilização de software Extraída de Jones, 1990 Ciclo para reutilização de software Integração de partes existentes desenvolvimento bottom-up Casos especiais colagem de partes através da interface / linguagem de comandos Econômico Dificuldades: Pode ser difícil combinar os componentes Reutilização ainda é mal conhecida Alterações de componentes, mesmo que pequenas, podem constituir um problema sério 5

6 Uso de técnicas de 4a. Geração Extraída de Pressman, 3a. Ed. Uso de técnicas de 4a. Geração Uso de ferramentas específicas: Gerenciadores de bancos de dados Geradores de relatórios Gerenciadores de interfaces Fases a considerar dependem do domínio da aplicação e da ferramenta 6

7 Implementação radical versus Implementação conservadora Lida com paralelismo entre as atividades (fases) Ultra radical Moderadamente radical Moderadamente Conservadora Ultra conservadora Fatores que influenciam a abordagem: Inconstância do usuário Pressão para produzir resultados Requisito de produção de cronogramas e orçamento Perigo de erro técnico Implementação radical versus Implementação conservadora Abordagem Radical: Pouco dinheiro envolvido Cronograma apertado A percepção do usuário é importante para o desenvolvimento do sistema Abordagem conservadora: Grandes projetos, envolvendo grandes quantias de dinheiro 7

8 Modelo Operacional ANÁLISE INICIAL ESPECIFICAÇÃO DE REQUISITOS OPERAÇÃO Enfoque em especificações As especificações devem ser executáveis Codificação para ambiente específico, geralmente através de um Engenheiro de Software, auxiliado por ferramentas apropriadas Dificuldades: âmbito de pesquisa Geradores de Aplicativos e VHLL ( Very High level Languages ) Seguem o modelo tradicional Geralmente, não procedimentais O programador apenas descreve o problema (fase de especificação) O sistema gera o programa automaticamente, reduzindo as fases de projeto, codificação e testes Possuem interfaces com gerenciadores de bancos de dados Aumento da produtividade: 10 vezes Exemplos: Planilhas de cálculo, Oracle, Dbase Dificuldades: Domínios de problemas restritos Baixo desempenho 8

9 Coleta inicial dos requisitos e planejamento do projeto Planejamento baseado nos comentários do cliente Avaliação do cliente Planejamento Análise de riscos Modelo Espiral Modelo Espiral Análise dos riscos baseada nos requisitos iniciais Análise dos riscos baseada na reação do cliente Decisão de prosseguir/ não prosseguir Na direção de um projeto concluído Protótipo do software inicial Protótipo no nível seguinte Avaliação do cliente Engenharia Sistema construído pela Engenharia Extraída de Pressman, 3a. Ed. Referências Bibliográficas Yourdon, E. Análise Estruturada Moderna. Editora Campus Trad. Alencar, D. C. Jones, G. W. Software Engineering. John Wiley & Sons, New York, Pressman, R. Engenharia de Software. Makron Books,