A SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT

1.1. Informações sobre modelos de processos de software

As principais funções de um modelo de processo de software são determinar a ordem dos estágios envolvidos no desenvolvimento e evolução do software e estabelecer os critérios de transição para o processamento de um estágio para o próximo. Estes incluem critérios de conclusão para o estágio atual além de critérios de escolha e critérios de entrada para o próximo estágio. Assim, um modelo de processo aborda o que deve ser feito e por quanto tempo isso deve ser feito em um projeto de software.

Os modelos de processos de software fornecem orientações sobre a ordem nas quais um projeto deve executar suas principais tarefas. Muitos projetos de software têm sofrido porque perseguiram suas várias fases de desenvolvimento e evolução na ordem errada.

1.2. Evolução de modelos de processo

1.2.1. O modelo code-and-fix (codificar e corrigir)

O modelo básico utilizado nos primeiros dias de desenvolvimento de software consistia em duas etapas: escrever um código e corrigir os problemas do código. Desse modo, a ordem das etapas era fazer primeiro uma codificação e pensar nos requisitos, no design, no teste e na manutenção mais tarde. Este modelo apresenta três dificuldades principais:

a) Após várias correções, o código ficava tão mal estruturado que as correções subsequentes eram muito caras. Isso ressaltou a necessidade de uma fase de projeto antes da codificação;

b) Até mesmo softwares bem projetados correspondiam tão mal às necessidades dos usuários que eram rejeitados ou completamente reformulados. Isso tornou a necessidade de uma fase de requisitos antes do design evidente;

c) A correção do código tinha custo elevado devido à má preparação para testes e modificações. Isso deixou claro que o reconhecimento explícito dessas fases, bem como tarefas de planejamento e preparação de testes e evolução nas fases iniciais, eram necessários.

1.3. Os modelos de etapas e cascata

A experiência em grandes sistemas de software levou ao reconhecimento desses problemas e ao desenvolvimento de um modelo de etapas. Este modelo estipulava que o software fosse desenvolvido em etapas sucessivas.

O modelo em cascata foi um refinamento altamente influente do modelo de etapas. Ele forneceu dois aprimoramentos primários para o modelo de etapas:

a) Reconhecimento dos ciclos de retroalimentação entre os estágios, uma diretriz para limitar os ciclos de feedback a etapas sucessivas para minimizar o retrabalho caro envolvido no feedback em vários estágios;

b) Incorporação inicial de prototipagem no ciclo de vida do software, através de uma etapa "construa duas vezes" em paralelo com a análise e o design de requisitos.

A abordagem do modelo em cascata ajudou a eliminar muitas dificuldades encontradas anteriormente em projetos de software e se tornou a base para a maioria dos padrões de aquisição de software no governo e na indústria. Algumas de suas dificuldades iniciais foram abordadas adicionando-se extensões para abranger o desenvolvimento incremental, desenvolvimentos paralelos, famílias de programas, acomodação de mudanças evolutivas, desenvolvimento e verificação de software formal, e validação em etapas e análise de risco.

No entanto, mesmo com extensas revisões e refinamentos, o esquema básico do modelo em cascata encontrou algumas dificuldades mais fundamentais, e isso levou à formulação de modelos de processos alternativos.

1.4. O modelo de desenvolvimento evolutivo

Suas etapas consistem em enriquecer os incrementos de um produto de software operacional, com as direções de evolução sendo determinadas pela experiência operacional.

O modelo de desenvolvimento evolucionário oferece aos usuários capacidade operacional inicial rápida e fornece base operacional realista para determinar as melhorias subsequentes do produto.

Porém, ele também tem suas dificuldades. É difícil distingui-lo do modelo code-and-fix. Também se baseia na suposição de que o sistema operacional do usuário será flexível o suficiente para acomodar caminhos de evolução não planejados.

Os projetos de desenvolvimento evolucionário têm sofrido ao seguir os estágios na ordem errada.

1.5. O modelo de transformação

Foi proposto como uma solução para as dificuldades encontradas nos modelos citados anteriormente.

Ele pressupõe a existência de uma capacidade de converter automaticamente uma especificação formal de um produto de software em um programa que atenda à especificação. Os passos então prescritos pelo modelo de transformação são: especificação formal da melhor compreensão inicial do produto desejado; transformação automática da especificação em código; loop iterativo para melhorar o desempenho do código resultante, fornecendo orientação de otimização para o sistema de transformação; exercício do produto resultante e loop iterativo externo para ajustar a especificação com base na experiência operacional resultante e rederivar, reotimizar e exercitar o produto de software ajustado.

O modelo de transformação contorna a dificuldade de modificar o código que se tornou mal estruturado por meio de repetidas reotimizações, uma vez que as modificações são feitas na especificação. Além disso, evita o tempo e as despesas extras envolvidas nas atividades de design, código e teste intermediários.

Ainda assim, o modelo de transformação possui várias dificuldades. Os recursos de transformação automática estão disponíveis apenas para produtos pequenos em algumas áreas limitadas além de dificuldades como a suposição de que os sistemas operacionais dos usuários sempre serão flexíveis o suficiente para suportar caminhos de evolução não planejados. Além disso, enfrentaria um problema de manutenção de base de conhecimento ao lidar com o crescente fornecimento de componentes de software reutilizáveis e produtos comerciais de software.

1.6. O modelo espiral

O modelo espiral vem evoluindo com base na experiência com vários refinamentos do modelo em cascata. Ele pode acomodar a maioria dos modelos anteriores como casos especiais e ainda fornece orientação sobre qual combinação de modelos anteriores melhor se adapta a uma dada situação de software.

A dimensão radial representa o custo cumulativo