Ciclo de desenvolvimento de software em cascata

O modelo em cascata é uma abordagem linear, clássica e bastante utilizada no ciclo de desenvolvimento de software. Define uma sequência de etapas, cada uma com objetivos claros. Como a água que desce uma encosta, o modelo estrito avança sem voltar atrás.

A abordagem em cascata é rígida e oferece pouca margem para revisões. Os testes são tratados como uma etapa separada, sem ocorrer de forma contínua durante o desenvolvimento. Por isso, o modelo não permite detectar defeitos nas etapas iniciais do desenvolvimento.

Abrir diagrama em tamanho real ↗

Ciclo de desenvolvimento de software em cascata

As etapas seguem esta ordem:

1. Levantamento de requisitos. Registre os requisitos do cliente e prepare a documentação necessária.
2. Projeto do sistema. Use os requisitos para definir a arquitetura e as necessidades de hardware e software do sistema.
3. Implementação. Comece a programar a partir do projeto. Divida o programa em unidades pequenas e independentes, teste cada uma conforme suas especificações e depois integre as unidades ao sistema completo.
4. Testes de integração. Reúna as unidades já testadas e verifique o sistema inteiro em busca de defeitos.
5. Implantação. Corrija os defeitos encontrados durante os testes de integração e repita os testes para confirmar as correções. O sistema estará então pronto para ser lançado no mercado e implantado no ambiente do cliente.
6. Manutenção. Publique correções ou novas versões para resolver defeitos e problemas encontrados após a entrega.

As etapas avançam em cascata. Cada etapa só começa depois que a anterior é concluída com êxito.

Use o modelo em cascata quando os requisitos forem claros, o produto for estável e houver recursos suficientes em cada etapa. Na prática, reserve esse modelo para projetos pequenos e fáceis de gerenciar. Evite-o quando os requisitos apresentarem risco moderado ou alto.

Especificação e análise de requisitos

O desenvolvimento de software depende da qualidade do levantamento e da documentação dos requisitos. Identificar e documentar esses requisitos é o trabalho de especificação e análise de requisitos.

O cliente, a equipe de gestão e a equipe de suporte técnico discutem os requisitos em detalhe. Eles analisam, revisam e documentam esses requisitos até que estejam claros e completos.

Abrir diagrama em tamanho real ↗

Especificação de requisitos dos usuários

Use o formato exigido pela empresa, como documentos do Word, fluxogramas ou desenhos. O resultado é um registro detalhado do que o cliente quer, que ajuda a equipe a entender essas necessidades corretamente. Um defeito é tudo o que não atende aos requisitos do cliente. Levantar requisitos incorretos compromete o projeto desde o início.

Especificação de requisitos dos usuários

Esse documento não técnico descreve as expectativas e as necessidades de negócio dos usuários. Os usuários finais o escrevem, e seus requisitos são verificados nos testes de aceitação do usuário. Ele serve de base para as próximas atividades de requisitos e para o projeto do sistema.

Especificação de requisitos de software

A especificação de requisitos de software (SRS) define como os usuários esperam que o software funcione. Ela tem estas finalidades:

• Registrar o acordo entre o cliente e o fornecedor sobre as funcionalidades detalhadas do software.
• Servir de base para o projeto do software.
• Facilitar o desenvolvimento e os testes com requisitos claros.
• Apoiar a programação das atividades e as estimativas de custos.
• Fornecer uma base para a verificação e a validação.

Abrir diagrama em tamanho real ↗

Especificação de requisitos de software

Projeto de software

O projeto de software tem dois níveis:

• Projeto de software de alto nível
• Projeto detalhado de software

Abrir diagrama em tamanho real ↗

Projeto de software

Projeto de software de alto nível

O projeto de alto nível (HLD) descreve o projeto do banco de dados e a arquitetura funcional. Ele orienta os desenvolvedores e responde a perguntas sobre a estrutura do projeto. É preciso ter uma SRS clara antes de elaborar o HLD.

Projeto detalhado de software

O projeto detalhado, ou de baixo nível (LLD), divide o HLD em partes menores e registra a lógica que compõe a especificação do programa. Ele detalha o sistema e depende da conclusão do HLD.

Abordagens de projeto de software

O processo de projeto pode seguir uma destas abordagens:

• Projeto descendente
• Projeto ascendente

Abordagem de projeto descendente

O projeto descendente começa com uma visão geral do sistema, deixando os detalhes dos subsistemas para depois. Passe por cada subsistema e defina seus detalhes progressivamente até chegar aos elementos básicos.

Abordagem de projeto ascendente

O projeto ascendente começa com elementos básicos totalmente definidos. Reúna-os em subsistemas e combine esses subsistemas até formar o sistema inteiro. Imagine uma semente que você planta e que cresce aos poucos até se tornar uma árvore.