Esse modelo combina técnicas de prototipagem com aspectos controlados e sistemáticos do modelo sequencial linear. Esse modelo oferece suporte ao desenvolvimento de verões incrementais, como por exemplo, em versões iniciais pode ser prototipagem, em versões finais pode ser entregue funcionalidades ainda mais completas.
A estrutura do modelo espiral é distribuída em atividades normalmente conhecidas como regiões de tarefa, segundo Pressman (2001 apud Sbrocco e Macedo, 2012, p.66), existem de três a seis destas regiões de tarefas, conforme descrito a seguir:
- Comunicação com o cliente: tarefas de comunicação entre desenvolvedor e cliente para a obtenção dos objetivos.
- Planejamento: tarefas de definição de recursos, prazos, entre outras.
- Análise de risco: tarefas de avaliação de riscos técnicos e gerenciais, por exemplo, se houver dúvida sobre os requisitos há a necessidade da construção de um protótipo do sistema.
- Desenvolvimento e validação: tarefas para construir, testar, instalar e apoiar o usuário (documentação e treinamento).
- Avaliação pelo cliente: tarefas para obter o posicionamento do cliente sobre as funcionalidades oferecidas e o modelo de implantação, oportunizando uma realimentação advinda do cliente e a liberação para o próximo incremento.
Esse modelo pode ser aplicado tanto para pequenos, quanto grandes projetos, cada tarefa pode definir um conjunto de atividades e essas variam dependendo do tamanho do projeto. Diferentemente do modelo clássico, o modelo espiral pode ser utilizando durante todo o clico de desenvolvimento do software, visto que sempre requer um novo planejamento após a realimentação da avaliação do cliente. Da mesma forma que ocorre com outros modelos clássicos, é fundamental a avaliação apurada dos ricos para garantir aos clientes que o modelo é sustentável, a imagem a seguir ilustra o desenvolvimento em espiral.
| Vantagens | Desvantagens |
|---|---|
| Estimativas tornam-se mais realísticas | Muita ênfase a parte funcional |
| Mais versátil para lidar com mudanças | A avaliação dos riscos exige experiência |
| Melhora o tempo de implementação do sistema | É bem aplicado somente a sistemas de larga escala |
| Fácil de decidir o quanto testar | O modelo é relativamente novo e não tem sido muito utilizado. |
| Não faz distinção entre desenvolvimento e manutenção. | |
| Melhora o tempo de implementação do sistema | É bem aplicado somente a sistemas de larga escala |
| Fácil de decidir o quanto testar | O modelo é relativamente novo e não tem sido muito utilizado. |
| Não faz distinção entre desenvolvimento e manutenção. |
Referências:
[1] MATIAS1, Lorival Warmeling. AVALIAÇÃO DOS MÉTODOS DE DESENVOLVIMENTO TRADICIONAIS E ÁGEIS PARA APLICAÇÃO EM UMA EMPRESA DE SOFTWARE. Unibave - Centro Universitário Barriga Verde. Disponível em: http://www.projedata.com.br/images/notificacoes/artigo_lorival_metodos_de_desenvolvimento.pdf. Acesso em: 11 nov. 2018.
[2] HENRIQUE, Guilherme et al. Metodologias Clássicas: Espiral: Comparação geral das metodologias clássicas de desenvolvimento de software.. 2013. Disponível em: http://metodologiasclassicas.blogspot.com/p/blog-page.html. Acesso em: 20 nov. 2018.