Modelo de Desenvolvimento de Software em Cascata

1. INTRODUÇÃO

Sabe-se que desenvolver softwares é uma tarefa longa, árdua e complexa. Os desenvolvedores de software devem ser altamente capacitados, competentes e organizados. Ao construir softwares, deve ser escolhida a forma como ele será construído, os passos a serem realizados, as responsabilidades devem ser atribuídas, os prazos devem ser estabelecidos, entre outras definições do processo.

As tarefas são definidas desde a identificação das necessidades, os problemas a serem resolvidos até ao descarte do software.

Neste trabalho será abordado os problemas relacionados ao negligenciar as metodologias de desenvolvimento de software, os problemas relacionados a utilização do modelo cascata quando aplicados a projetos de médio/grande porte ou requisitos instáveis; e vamos explorar o levantamento de requisitos de um software.

2. DESENVOLVIMENTO

2.1 MODELO DE CICLO DE VIDA CLÁSSICO OU MODELO CASCATA

O modelo cascata é utilizado quando os requisitos de uma aplicação ou projeto são compreendidos. Geralmente ele é utilizado em sistemas existentes e serve para fazerem adaptações e aperfeiçoamentos. Este sistema tem uma abordagem sistemática e sequencial, ou seja, só avança uma etapa caso a anterior tenha sido concluída.

A primeira etapa é o levantamento de requisitos junto ao cliente, após isso, inicia-se a etapa de planejamento onde o cronograma e estimativas são definidos. As próximas etapas são as fases de modelagem, construção, testes, implementação, suporte e feedback.

De forma resumida, respectivamente, podemos dizer que a primeira etapa, de acordo com o Higor (2013), da empresa DevMedia, existe para estabelecer as condições e requisitos junto ao cliente, desta forma, satisfazendo os interesses desejados e os serviços que serão fornecidos. Após isso, elaboramos a documentação e a viabilidade do projeto.

Consequentemente, começamos a definir prazos e objetivos baseando-se nos requisitos, seguimos para a modelagem e implementação dos códigos, testamos e entregamos o software para o cliente. O processo de suporte e feedback é feito após a entrega, onde tiramos as dúvidas do cliente e acompanhamos os feedbacks para que seja possível dar a manutenção do código e a correção dos erros previamente não identificados.

2.2 PROBLEMAS DO MODELO CASCATA

2.2.1 Nenhuma visibilidade do trabalho

O modelo cascata não consegue nos dar um projeto executável até que o trabalho esteja concluído. O projeto passará pelas suas fases de desenvolvimento para que possamos ter uma visão de como está o projeto. Em muitos casos isso pode ser ruim, pois muitas das vezes o cliente não tem paciência para esperar todas as etapas do projeto.

2.2.2 Riscos inesperados

Este modelo não consegue lidar com problemas inesperados, é preciso que a equipe de desenvolvimento dedique um pouco mais de atenção durante a fase de requisitos, para que possam identificar os riscos. Caso o contrário, uma situação inesperada durante o processo, faria com que o projeto demorasse mais do que o previsto para a conclusão.

2.2.3 Uma tarefa por vez

No modelo cascata os desenvolvedores precisam resolver uma etapa por vez, com isso, os outros membros da equipe são obrigados a esperar pela conclusão da etapa anterior para que possam dar início. Uma vez que uma etapa atrasa, acaba prejudicando as outras etapas em diante.

2.2.4 Não permite alteração no projeto

Como falamos acima, só podemos visualizar o projeto depois que passamos por algumas etapas cruciais. Tendo isso em mente, seguindo a mesma lógica, o modelo cascata não permite alteração no projeto, sejam elas: necessidades de negócio, necessidades dos clientes, leis governamentais e entre outras mudanças. Atualmente nós lidamos com muitas variações durante o desenvolvimento, com isso, o modelo cascata deixa de ser apropriado.

2.2.5 Falta de interação com o cliente

No modelo cascata, a interação com o cliente ocorre apenas durante a fase inicial de requisitos, e depois disso, a equipe de desenvolvimento trabalha em silêncio, sem dar feedbacks frequentes ou atualizações sobre o progresso do projeto. Isso pode resultar em um produto final que não atende às necessidades do cliente ou não corresponde às suas expectativas. Além disso, pode ser difícil corrigir erros ou fazer mudanças significativas no projeto após a fase de desenvolvimento ter sido concluída.

2.3 LEVANTAMENTO DE REQUISITOS

O levantamento de requisitos é o primeiro passo para o desenvolvimento de um software, através dele, sabemos das necessidades do cliente, se o solicitante será o usuário final e até mesmo podemos detectar possíveis problemas na utilização do software.

Com base no problema apresentado na tirinha de dilbert (2016), um dos maiores problemas dentro do levantamento de requisitos, é a comunicação do analista e do cliente. Vemos o analista questionando o cliente a respeito das exigências para o software. Porém o cliente não tem o conhecimento da capacidade de ação que um software possuí, não consegue se expressar, não consegue explicar o que quer que o software faça.

Esse problema de comunicação pode acarretar em um software mal desenvolvido, totalmente diferente do requisitado pelo cliente, causando um grande prejuízo financeiro e desperdício de tempo.

Uma forma de prevenção e solução para essas ocorrências é a entrevista acompanhada de um questionário, eles permitem que o analista entreviste o cliente, de maneira lógica e ordenada, sobre suas ideias e necessidades.

É imprescindível que o analista tenha conhecimentos técnicos e contextuais em softwares, pois o analista deverá apresentar ao cliente todas as possibilidades de desenvolvimento de um projeto. Sendo assim, o cliente expressará seus requisitos, também de forma lógica, para que se dê o início ao desenvolvimento do protótipo.

3. CONCLUSÃO

Neste trabalho, foi possível observar as características do modelo cascata e exemplicar o seu funcionamento. O modelo cascata funciona bem para projetos pequenos e que não sofrerão eventuais interferências do mundo externo como por exemplo leis governamentais. O modelo é fácil de aplicar e simples de entender.

Os problemas surgem quando os projetos são de médio/grande porte e quando há possibilidade de interferência externa pois este modelo funciona de forma linear e sequencial. Só podemos avançar para a próxima etapa quando concluímos as etapas anteriores. Além disso, este modelo dificulta a manutenção do código e os gastos para possíveis atualizações são caros.

Observamos também a importância do levantamento de requisitos junto ao cliente através de entrevistas ou questionários. Esta etapa do desenvolvimento serve para que seja possível entender o que o cliente deseja, quais poderão ser os possíveis problemas, prazos, detalhes específicos da produção, entre outros pontos que devem ser esclarecidos antes de se iniciar a produção do software.

REFERÊNCIAS

1. DevMedia. Metodologia de desenvolvimento de Software. DevMedia. [Online] DevMedia, 2006. [Citado em: 22 de Março de 2023.] https://www.devmedia.com.br/metodologia-de-desenvolvimento-de-software/1903.

2. DevMedia —. Introdução ao Modelo Cascata. DevMedia. [Online] DevMedia, 2013. [Citado em: 22 de Março de 2023.] https://www.devmedia.com.br/introducao-ao-modelo-cascata/29843.

3. Alff, Francilvio Roberto. A importância da análise de requisitos. Análise de Requisitos. [Online] 14 de Fevereiro de 2018. [Citado em: 22 de Março de 2023.] https://analisederequisitos.com.br/importancia-da-analise-de-requisitos/.

4. Rodrigo. Modelo em cascata: vantagens e desvantagens. Estudyando. [Online] Estudyando, 2020. [Citado em: 22 de Março de 2023.] https://pt.estudyando.com/modelo-em-cascata-vantagens-e-desvantagens/.

5. DevMedia. Técnicas para levantamento de Requisitos. DevMedia. [Online] 2009. [Citado em: 22 de Março de 2023.] https://www.devmedia.com.br/tecnicas-para-levantamento-de-requisitos/9151.

6. Precioso, Vitor. Como realizar o Levantamento de Requisitos no desenvolvimento de software. CedroTech. [Online] 31 de Outubro de 2018. [Citado em: 22 de Março de 2023.] https://www.cedrotech.com/blog/levantamento-de-requisitos-e-desenvolvimento-de-softwares/.