Modelo de processo

Requisitos
Dos motivos destacados por Pressman, o maior foco está no tratamento de requisitos.
Sobre isso, Sommerville (2003) destaca que os acordos com os clientes devem ser feitos em um estágio inicial do processo de desenvolvimento em que, geralmente, os requisitos são desconhecidos ou não são claros.
Quando esses requisitos são alterados posteriormente, causam impacto negativo no produto de software, que deve ser refeito, ao menos em parte.
Assim, Sommerville aconselha a só utilizar esse modelo quando os requisitos forem bem compreendidos.
Embora o ciclo de vida Cascata constitua uma abordagem melhor que a abordagem casual (abordagem livre, antes da Engenharia de Software), a forma altamente dinâmica como se desenvolve software exige um processo mais ágil e dinâmico.

Ciclo de Vida Espiral

O Ciclo de Vida Espiral traz uma alternativa interessante a esse problema, pois divide a tarefa de levantar requisitos em etapas que não ocorrem todas de uma vez, no início do desenvolvimento.
O modelo Espiral mantém como princípio as mesmas etapas do modelo
Cascata. Porém, elas são executadas várias vezes ao longo do ciclo de desenvolvimento do software (uma vez para cada pacote de desenvolvimento). A figura 2 ilustra essas etapas. O centro da figura assinala o início do desenvolvimento. À medida que o desenvolvimento ocorre, caminha-se, na espiral, para sua parte mais externa, passando pelas disciplinas de desenvolvimento várias vezes.
O efeito dessa forma de trabalho são entregas parciais de software para o cliente, em vez de uma entrega única ao final do processo

Ciclo de Vida Espiral

O Ciclo de Vida Espiral traz uma alternativa interessante a esse problema, pois divide a tarefa de levantar requisitos em etapas que não ocorrem todas de uma vez, no início do desenvolvimento.
O modelo Espiral mantém como princípio as mesmas etapas do modelo
Cascata. Porém, elas são executadas várias vezes ao longo do ciclo de desenvolvimento do