Um modelo de cascata, o modelo de seis fases é um modelo de cascata. Por outras palavras, as etapas ocorrem sequencialmente. Assim como nadar a montante contra uma cascata é impossível, a técnica pura cascata impede o regresso a uma fase depois de ter terminado.
Não é ideal decidir alterar o desenho durante a fase de implementação, interrompendo assim a implementação. A abordagem waterfall é muitas vezes menos adequada para projetos de desenvolvimento de software por uma variedade de razões.
- O desenvolvimento de software é um esforço artístico; é praticamente difícil antecipar todas as necessidades (funcionalidades).
- Estimar o tempo necessário para desenvolver uma funcionalidade é muito desafiante.
- Ao longo do ciclo de vida do projeto, os utilizadores devem ser capazes de testar todos os resultados intermédios.
Desenvolvimento de Software é um esforço artístico #
Para os não iniciados, o desenvolvimento de software parece ser mais sobre engenharia do que sobre invenção. No entanto, relaciona-se de várias formas de inventar. No processo de criação, nunca se sabe exatamente o que vai acontecer.
Os designers e programadores responsáveis pelo desenvolvimento de novos softwares devem encontrar respostas para os problemas que lhes são apresentados. Independentemente das muitas técnicas e prescrições para o trabalho, a criação de código informático ainda é, na sua maioria, desconhecida e, portanto, imprevisível. Os programadores podem selecionar entre milhões de soluções escritas em dezenas de linguagens de programação e operar em milhares de diferentes combinações de hardware e plataformas de software. Embora esta flexibilidade tenha muitos benefícios, também torna o projeto mais desafiante para gerir do que a gestão de projetos mais convencionais (como projetos de construção ou construção).
Configuração de implementação #
A abordagem cachoeira exige que os requisitos sejam definidos como consequência da fase de definição do projeto. Idealmente, deve ocorrer um desvio adicional mínimo destes critérios para o resto do projeto. A abordagem cachoeira do desenvolvimento de software requer um compromisso inicial de esforço significativo na análise da funcionalidade necessária (requisitos). Isto resulta num design funcional (ver I para obter informações adicionais sobre desenhos funcionais). O arquiteto de software cria um design técnico em todo o processo de design, usando o design funcional como referência. Além disso, o desenho técnico fornece instruções sobre como executar a funcionalidade necessária.
Embora esta possa parecer uma questão simples, considere o seguinte cenário. Um novo veículo está a ser desenvolvido como parte de um projeto. Como condutor ativo de automóveis, é-lhe incumbido o desenvolvimento de necessidades de automóveis. Conferencia com outros automobilistas e compila uma lista exaustiva:
- O carro deve acomodar quatro pessoas;
- O automóvel deve ter um volante na frente do lado esquerdo do condutor; • O automóvel deve ter um pedal de travão, um pedal a gás e um travão de mão.
- Os faróis do automóvel devem ser brancos e os faróis devem ser vermelhos. (obviamente, a lista real seria enorme)
Design & Modelação #
Os designers criam um novo design usando a sua lista como guia, que é depois construído muitos meses depois. Ao descer a rua, vê-se que um veículo parou. Sabe que omitiu luzes de travão da sua lista! Contacte rapidamente o engenheiro do fabricante do automóvel, que quase rebenta em resposta à sua chamada. Diz que é um pequeno ajuste. No entanto, é uma catástrofe para os construtores de automóveis. Os automóveis já fabricados devem ser totalmente desmontados, os fios dos pedais do travão para trás devem ser estendidos, a parte traseira do veículo deve ser totalmente redesenhada para se adaptar às luzes do travão, e as escotilhas de arranque já fabricadas devem ser desmanteladas e a lista continua.
Embora o cenário acima pareça ridículo, representa uma ocorrência quase diária no desenvolvimento de software. Os programadores assumem erradamente que os clientes, clientes ou utilizadores do produto criado entendem exatamente o que querem. Os clientes acreditam incorretamente que os desenvolvedores de software podem criar (e modificar) qualquer coisa no menor período de tempo possível. Esta é a principal causa de discórdia entre consumidores e desenvolvedores de software.
