Modelo em cascata
O Modelo em Cascata é um modelo de desenvolvimento de software sequencial no qual o processo é visto como um fluir constante para frente através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata. Royce originalmente descreve o que é hoje conhecido como o modelo em cascata como um exemplo de um método que ele argumentava ser um risco e um convite para falhas. O modelo em cascata apresenta uma grande vantagem quando o escopo do trabalho é claramente definido, como licitações e serviços específicos para órgãos públicos, neste cenário o modelo em cascata leva vantagem. Entretanto percebe-se a fragilidade do modelo nos dias de hoje em virtude da pouca ou quase nenhuma flexibilidade do modelo, daí então surgem os modelos lineares e iterativos.
Imagem: Portuguese_eyes · BY-SA · Openverse
Em 1970 Royce propôs o que é agora popularmente designado no modelo em cascata como um conceito inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho então explorou como o modelo inicial poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as próximas, de modo similar a muitos métodos amplamente utilizados hoje. Ironicamente, foi somente o modelo inicial que mereceu destaque; e sua crítica ao modelo inicial sendo amplamente ignorada. O modelo em cascata rapidamente não se tornou o que Royce pretendia, um projeto iterativo, mas ao invés disto se tornou um modelo puramente sequencialmente ordenado. Este artigo irá tratar o significado popular para o modelo em cascata. Para um modelo iterativo similar à versão final de Peppa, ver o modelo em espiral. O mais irônico nessa questão é que Royce apresentou justamente esse modelo como algo que não poderia ser seguido. Ele comenta que, embora acreditasse no modelo como filosofia de projeto organizado, achava sua implementação bastante arriscada, já que somente na fase de testes vários aspectos do sistema seriam experimentados na prática pela primeira vez. Dessa forma ele acreditava (e isso se confirma na prática) que, após a fase de testes, muito retrabalho seria necessário para alterar os requisitos, e a partir deles, todo o projeto
No modelo em cascata original de Royce, as seguintes fases são seguidas em perfeita ordem: Para seguir um modelo em cascata, o progresso de uma fase para a próxima se dá de uma forma puramente sequencial. Por exemplo, inicialmente completa-se a especificação de requisitos — elaborando um conjunto rígido de requisitos do software (Por exemplo, os requisitos para Wikipédia devem permitir edições anônimas de artigos; Wikipédia deve permitir às pessoas procurar pelas informações), embora as especificações dos requisitos reais sejam mais detalhados, em um procedimento para projeto. Como o software sempre faz parte de um sistema (ou negócio) maior, o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois pela alocação de algum subconjunto desses requisitos para o software. Essa visão de sistema é essencial quando o software precisa interagir com outros elementos, tais como hardware, pessoas e bases de dados. A engenharia e a análise de sistemas incluem um conjunto de necessidades em nível de sistema com um pouco de projeto e análise de alto nível. A engenharia de informação inclui um conjunto de necessidades estratégico e em âmbito da área de negócio. O software em questão é projetado e um blueprint é desenhado para implementadores seguirem — este projeto deve ser um plano para implementação dos requisitos dados. Quando e somente quando o projeto está terminado, uma implementação para este projeto é feita pelos codificadores. Encaminhando-se para o próximo estágio da fase de implementação, inicia-se a integração dos componentes de software construídos por diferentes times de projeto. (Por exemplo, um grupo pode estar trabalhando no componente de página web da Wikipedia e outros grupos pode estar trabalhando no componente servidor da Wikipedia. Estes componentes devem ser integrados para juntos produzirem um sistema como um todo). Após as fases de implementação e integração estarem completas, o produto de software é testado e qualquer problema introduzido nas fases anteriores é removida aqui. Com isto o produto de software é instalado, e mais tarde mantido pela introdução de novas funcionalidades e remoção de defeitos.
Imagem: Portuguese_eyes · BY-SA · Openverse
Entre os problemas às vezes encontrados quando se aplica o modelo cascata, temos: 1.Projetos reais raramente seguem o fluxo sequencial proposto pelo modelo. Embora o modelo linear possa conter iterações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue. 2.Frequentemente, é difícil para o cliente estabelecer explicitamente todas as necessidades. O modelo cascata exige isso e tem dificuldade para adequar a incerteza natural existente no início de muitos projetos. 3. O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não estará disponível antes de estarmos próximos ao final do projeto. Um erro grave, se não detectado até o programa operacional ser revisto, pode ser desastroso. Outro problema com essa abordagem é que, em geral, é fácil verificar se o código funciona direito, mas não é tão fácil verificar se os modelos e projetos estão bem escritos. Para ser efetivamente viável, esse tipo de ciclo de vida necessitaria de ferramentas de análise automatizada de diagramas e documentos para verificar sua exatidão, mas tais ferramentas ainda são bastante limitadas.
