É o modelo em cascata, ou seja, o projeto vai progredindo com o passar do tempo. Semelhante ao TCC.

ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE

Modelagem

Como o software faz parte de um sistema maior (hardware, bd, pessoas, todos interagindo), o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois são alocados alguns subconjuntos desses requisitos para o software (por isso "em cascata").

Análise de Requisitos para o Software

O foco da análise volta-se para o software a ser desenvolvido. São levantadas as questões: Domínio da informação (para que o software serve e em que contexto ele está inserido), funções necessárias, comportamentos (sempre que acontecer X, fazer Y), desempenho e interface. Todos esses requisitos são documentados e revistos com o cliente.

Projeto

O processo de desenvolvimento envolve múltiplos passos, que focam: estrutura de dados, arquitetura do software (como ele será construído), protótipo e detalhes procedimentais (algorítmicos). Este processo traduz (agora já pensando em nível técnico) as especificações de requisitos citadas no item anterior.

Geração de código

Se o projeto é realizado detalhadamente, a geração de código vira algo mecânico (aquela velha história que discutimos com maria angélica, hélder, etc).

Teste

O processo de teste focaliza os aspecto lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos (descobrir erros na interface com o usuário e garantir que entradas definidas produzirão resultados reais, que estão de acordo com os resultados exigidos (é criada uma tabela de testes, contendo a entrada, o tipo dela - numérica, alfanumérica - e seu tamanho e informações sobre o que é esperado que se obtenha como saída).

Manutenção

A manutenção do software reaplica cada uma das fases anteriores a um programa existente ao invés de a um novo programa.

Este modelo é o mais antigo e o mais utilizado. Porém a crítica levou até mesmo seus atuais adeptos a questionar sua eficácia. Alguns problemas:

1) Projetos reais raramente seguem o fluxo proposto (como acontece em nosso TCC, agora que identificamos várias alterações a serem feitas no início). Como resultado, modificações podem causar confusão à medida que a equipe prossegue.

2) É difícil para o cliente estabelecer todos os requisitos explicitamente (sabemos mais que ninguém que isso sempre acontece. O Você Apita é um exemplo). Este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de vários projetos.

3) O cliente precisa ter paciência. Uma versão executável do programa não estará disponível enquanto o projeto não terminar. Um erro grosseiro pode ser desastroso se não for identificado até que o programa executável seja revisto.