1. Processo em Espiral
1.1. O processo é representado por uma espiral ao invés de ser representado como uma sequencia de atividades.
1.2. Cada volta na espiral representa uma fase
1.3. Preocupação explícita com os riscos do projeto de desenvolvimento.
1.4. Capacita tanto o desenvolvedor quanto o usuário para que ambos tenham formas de responder a problemas.
1.5. Pega o que há de melhor nos ciclos de vida clássicos e adiciona uma nova fase que é a analise de riscos.
1.6. Fases da Espiral
1.6.1. 1-Planejamento: Revisa-se o projeto e o projeto e a próxima etapa é planejada.
1.6.2. 2- Análise de risco: Os riscos são avaliados e são implementadas atividades para prevenir esses riscos.
1.6.3. 3- Engenharia ou Desenvolvimento: É escolhido um modelo de desenvolvimento para o sistema, que pode ser qualquer um dos modelos genéricos.
1.6.4. 4- Análise do Cliente / Definição dos Objetivos: Identificam-se os objetivos específicos da próxima fase.
2. RAD (Rapid Application Development)
2.1. Etapas
2.1.1. Comunicação: Entender os requisitos apresentados cliente.
2.1.2. Planejamento: É vital para formar a divisão de equipes.
2.1.3. Modelagem: Modelagem de negócio, modelagem de dados, modelagem de processo.
2.1.4. Construção: Uso de artefatos para criar o projeto.
2.1.5. Implantação: Base para futuras iterações.
2.2. Necessidade de dividir o sistema que deverá ser desenvolvido, de forma a utilizar equipes para cada etapa específica. É uma espécie de “força bruta” aplicada ao modelo cascata usando o modo incremental
2.3. Desvantagens
2.3.1. Requer um número alto de pessoas para criar um número suficiente de equipes
2.3.2. Não recomendado em programas de alto risco
2.3.3. Requer um comprometimento entre desenvolvedores e clientes para que as atividades possam ser feitas em pouco tempo e de forma eficiente. Este método é extremamente frágil, se alguma das partes não se comprometer, o projeto ruirá.
3. Cascata
3.1. Cascata Clássico
3.1.1. Esse modelo é extremamente rígido, ele é sequencial e não é possível pular fases para frente ou para trás.
3.1.2. Problemas com esse modelo incluem sua rigidez que não é condizente com a fluidez do projeto e do mercado.
3.1.3. Só se avança de fase quando a anterior está totalmente completa.
3.2. Cascata em V
3.2.1. Modelo de Cascata onde é adicionada uma fase de teste para cada fase de teste padrão.
3.2.2. O projeto não possui releases curtas, isso significa que ele só será entregue no final.
3.3. Cascata com Prototipação
3.3.1. Procura assegurar que os requisitos serão atendidos de forma adequada.
3.3.2. Técnica usual quando não há entendimento pleno dos requisitos, quando o usuário não tem entendimento completo do problema e quando existem requisitos que devem ser mais bem entendidos.
3.3.3. Prototipação Evolutiva: Protótipo desenvolvido por programação para servir como um projeto detalhado para o programa final.
3.3.4. Prototipação Descartável: Protótipo desenvolvido de maneira agil e resumida com programação de baixa qualidade. Só serve para validar os requisitos de usuários e depois deve ser jogado fora.
3.3.5. Prototipação de Baixa Fidelidade: Protótipo desenvolvido no papel ou em ferramentas gráficas, de forma extremamente simplista.
4. Modelo Iterativo e Incremental
4.1. Vantagens: Antecipa possíveis problemas no desenvolvimento em suas fases iniciais, e os resolve antes que esses problemas se tornem mais acentuados. O cliente vê o programa funcionando nas fases iniciais, o que cria confiabilidade. Redução do risco de lançar o projeto no mercado fora da data planejada.
4.2. Desvantagens: Passa a ter uma camada extra de gerenciamento, que é o controle e a ordem de cada iteração. Problemas contratuais pois o software pode terminar de maneira bem diferente do projeto inicial.
4.3. Iterativo: O software é feito progressivamente em passos parecidos.
4.4. O desenvolvimento é dado em diversas iterações de forma que as partes mais importantes devem ser finalizadas primeiro.
4.5. Incremental: O software é estendido em cada etapa.
5. Try MeisterTask!
6. Prototipação Evolucionária
6.1. Processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.
6.2. Idealmente, o modelo serve como um mecanismo para identificar os requisitos de software.
6.3. Apropriado para quando o cliente definiu objetivos mas não declarou objetivos.
6.4. Cliente não sabe o software que ele vê, não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Força a utilização do protótipo como produto final.
6.5. Deve prever refatorações (melhorias na qualidade do software) de tempos em tempos.
7. RUP
7.1. Características
7.1.1. É Focado em Riscos
7.1.1.1. Em função das priorizações dos casos de uso mais críticos nos primeiros ciclos iterativos, pode-se dizer que o UP é focado em riscos.
7.1.2. Iterativo e Incremental
7.1.2.1. UP preconiza o desenvolvimento baseado em ciclos iterativos de duração fixa, onde a cada iteração a equipe incorpora à arquitetura as funcionalidades necessárias para realizar os casos de uso abordados no ciclo
7.2. Fases do RUP
7.2.1. Concepção: - Definição do escopo do projeto. identificação dos atores, casos de uso e descrição dos mais significativos; - Também chamada de Concepção.
7.2.2. Elaboração: -Análise do sistema, definição da arquitetura do sistema e de seus requisitos.
7.2.3. Construção: - Desenvolvimento iterativo e incremental;
7.2.4. Transição: - Atividades de "entrega" do software.
7.3. Disciplinas
7.3.1. Modelagem de Negócios
7.3.1.1. Descreve a forma como a empresa funciona.
7.3.2. Requisitos
7.3.2.1. Baseia-se em casos de uso para identificar requisitos.
7.3.3. Análise e projeto
7.3.3.1. Descreve as diversas visões da arquitetura.
7.3.4. Requisitos
7.3.5. Implementação
7.3.5.1. Alinha o desenvolvimento do software.
7.3.6. Teste
7.3.6.1. Aborda testes, procedimentos e medidas para verificar erros.
7.3.7. Entrega
7.3.7.1. Aborda a configuração do sistema a ser entregue.
7.3.8. Gerenciamento de configuração
7.3.8.1. Controla modificações e mantém integridade dos artefatos.
7.3.9. Gerenciamento de projeto
7.3.9.1. Determina e descreve as várias estratégias para trabalhar com o modo iterativo.
7.3.10. Ambiente
7.3.10.1. Analisa os componente necessários para o desenvolvimento do sistema..
7.4. Fases x Disciplinas
7.4.1. Todas as fases devem ser visitadas pelo menos uma vez por disciplina, sendo que a importância de cada fase varia de acordo com cada disciplina.