Modelo em Cascata ou Clássico O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em engenharia de software e está na base de muitos ciclos de vida utilizados hoje em dia. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. Por exemplo, a análise de requisitos deve ser completada antes que o desenho do sistema possa ser iniciado. Os nomes dados a cada passo variam, assim como varia a definição exata de cada um deles, mas basicamente o ciclo de vida começa com a análise de requisitos movendo-se de seguida para a fase de desenho, codificação, implementação, teste e finalmente manutenção do sistema. Uma das grandes falhas deste modelo é o fato de os requisitos estarem constantemente a mudar já que os negócios e ambiente em que se inserem mudam rapidamente. Isto significa que não faz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementação do sistema são completados. Foi então reconhecido que seria necessário dar feedback às atividades iniciais a partir do momento em que este modelo começou a ser usado em grande escala. A ideia de interacção não foi incorporada na filosofia do modelo de cascata. Neste momento, é incluído algum nível de interação na maior parte das versões deste modelo e são comuns sessões de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No entanto, a possibilidade de revisão e avaliação com os utilizadores do sistema não está contemplada neste modelo. O modelo que vamos estudar está descrito no padrão PSS-05-0 da ESA o qual será detalhado brevemente. Até meados da década de 1980 foi o único modelo com aceitação geral. É recomendado para sistemas onde a segurança e a confiabilidade tem grande importância. Um dos pontos fortes do modelo cascata está na ênfase dada a uma abordagem disciplinada, está na definição da documentação liberável em cada fase e está na recomendação de que todos produtos de cada fase sejam formalmente revisados. Inerente a cada fase estão os procedimentos de verificação e validação (incluindo testes). Grande parte do sucesso do modelo cascata está no fato dele ser orientado para documentação. No entanto deve-se salientar que a documentação abrange mais do que arquivo do tipo texto. Abrange representações gráficas e mesmo simulação. Uma abordagem incorporando processos, métodos e ferramnetas deve ser utilizada
pelos desenvolvedores de software. Esta abordagem é muitas vezes chamada de Abordagem do Processo de Desenvolvimento. Existem três abordagens de modelos de processo de desenvolvimento de software. Elas tentam colocar ordem numa atividade inerentemente caótica. Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo - Cascata Pura; - Incremental; e - Evolucionária. Toda esta secção constitui uma interpretação do disposto na referência[fai96]. Abordagem Cascata Pura Todas as fases do ciclo de desenvolvimento são executadas em sequência. As fases anteriores são revisitadas para correções de erros ou para adaptações. Esta abordagem é adequada quando : - existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade; - a duração do projeto é pequena, isto é, menor do que dois anos; e - o sistema completo deve estar disponível de um única vez. A Figura 2.2 ilustra esta abordagem: Abordagem Incremental Figura 2.2 Abordagem Cascata Pura Nesta abordagem o desenvolvedor executa múltiplas fases de PD, TR e OM. Dentro desta abordagem está a abordagem cascata. A abordagem incremental é adequada quando: - a liberação do software deve estar de acordo com um conjunto de prioridades definidas nos Requisitos do Usuário; - é necessário melhorar a eficiência da integração do software com outra partes de um sistema maior; e - é requerido antecipadamente evidências de que o produto será aceito. A Figura 2.3 ilustra a abordagem:
Abordagem Evolucionária Figura 2.3 Abordagem Incremental Nesta abordagem, o desenvolvimento é formada por múltiplos ciclos da abordagem cascata pura, ocorrendo sobreposição das fases da operação e manutenção do sistema anterior com o novo desenvolvimento. Esta abordagem é adequada quando: - é necessário alguma experiência do usuário para refinar e completar requisitos; - algumas partes da implementação podem depender da existência de tecnologia ainda não disponível; - existem requisitos do usuário não bem conhecidos; e - alguns requisitos são muito mais difíceis de serem implementados do que outros, decidindo-se não implementá-lo para não atrasar o projeto. A Figura 2.4 ilustra a abordagem: Figura 2.4 Abordagem Evolucionária É opinião deste autor que o padrão PSS-05-0 da ESA revitalizou o modelo cascata, sendo atualmente um dos melhores modelos de ciclo de vida para desenvolvimento de software.
Problemas O ciclo de vida Cascata é o paradigma mais visto e mais amplamente empregue na engenharia de software, porém sua aplicabilidade, em muitos campos, tem sido questionada. Entre os problemas que surgem quando se aplica o modelo são: Na realidade, os projectos raramente seguem o fluxo sequencial que o modelo propõe. A interacção é sempre necessária e está presente, criando problemas na aplicação do modelo; Em princípio, é difícil para o cliente especificar os requisitos explicitamente, o que acarreta a incerteza natural do início de qualquer projecto; O cliente deve ser paciente, pois uma versão funcional não estará disponível até o final do desenvolvimento. Qualquer erro ou mal-entendido, se não for detectado até que o software seja revisado, pode ser desastroso. Apesar desses problemas, o modelo Cascata tem um lugar bem definido e importante nos trabalhos de engenharia de software. Ele fornece um padrão do qual se encaixam métodos para a análise, projecto, codificação e manutenção. O modelo Cascata aplica-se bem em situações em que o software a ser desenvolvido é simples, os requisitos são bem conhecidos, a tecnologia usada é bem acessível e os recursos para o desenvolvimento estão disponíveis.
Vantagens do modelo Torna o processo de desenvolvimento estruturado. Tem uma ordem sequencial de fases. Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte; Todas as actividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; Esta abordagem é actualmente a norma e provavelmente permanecerá como tal nos próximos tempos. Desvantagens do modelo Não fornece feedback entre as fases e não permite a actualização ou redefinição das fases anteriores; Não suporta modificações nos requisitos; Não prevê a manutenção; Não permite a reutilização; É excessivamente sincronizado; Se ocorrer um atraso todo o processo é afectado;
Faz aparecer o software muito tarde.