Hélio Engholm Jr

Especializado em Engenharia de Software

cascata

Introdução

Existem no mercado diversas propostas relacionadas a metodologias de desenvolvimento de sistemas que podemos utilizar em nossos projetos. A escolha da metodologia mais adequada deve ocorrer na fase de pré-projeto, que ocorre normalmente antes do início formal do mesmo e deve levar em consideração aspectos como a cultura e tamanho da empresa, maturidade da equipe do projeto, tamanho e complexidade do sistema. De fato deveríamos poder selecionar a metodologia mais adequada de desenvolvimento a ser utilizada em cada projeto, ao invés de termos que utilizar alguma porque está institucionalizada na empresa onde estamos alocados.

A partir de agora, irei iniciar a publicação de artigos relacionados a propostas mais modernas de metodologia direcionadas para o desenvolvimento de software orientado a objetos (DSOO), entrando com mais detalhes no processo de desenvolvimento de software orientado a objetos.

Projetos diferentes merecem processo de desenvolvimento diferente[RP1]

Vamos ver neste em outros artigos, alguns exemplos de processo de desenvolvimento de software que podem ser utilizadas em projetos. Lembre-se que devemos selecionar a opção mais apropriada para cada projeto em específico, já que cada um possui características próprias e está dentro de cenários diferentes. Na verdade, configura-se um engano querer padronizar uma metodologia para todos os projetos.

Projetos emergenciais e de curta duração podem e devem ser tratados de uma maneira diferente projetos extremamente complexos e de grande escopo. Determinado projeto emergencial pode ser realizado colocando todos os envolvidos em uma sala de guerra até que o produto final seja obtido, tornando-se impraticável seguir qualquer metodologia de mercado devido às necessidades de negócio. Neste caso, a análise, o design e o desenvolvimento ocorrerem quase que paralelamente, sem a preocupação com processo definidos e artefatos previstos, o principal objetivo é gerar o produto do projeto o mais rápido possível. Academicamente, isto pode ser considerado indevido, mas na prática, pode ser a única opção.

Analisando várias propostas de mercado relacionados a metodologias de desenvolvimento de sistemas, acabamos percebendo que todos utilizam de alguma maneira as fases previstas no método cascata. Você observará que os processos incrementais acabam utilizando algumas das fases existentes no método cascata, como levantamento/refinamento de requisitos, análise, design, implementação, testes e entrega. Na verdade todas elas acabam existindo dentro de cada iteração.

Metodologia Cascata 

O método cascata possui as fases tradicionalmente conhecidas para o desenvolvimento de software. Estas fases devem ser executadas sequencialmente, sendo que a próxima somente pode ser iniciada quando a anterior esteja completamente finalizada.

Experiências de mercado há muito tempo mostram que esta metodologia é adequada somente para projetos pequenos, onde todos os requisitos são conhecidos no início do projeto e possuem baixa probabilidade de sofrerem mudanças. Aí vem umaa pergunta, o que seria um projeto pequeno? Alguns profissionais consideram projetos pequenos aqueles que possuem um tamanho inferior a cinquenta pontos de função.

A figura 1 representa graficamente este processo.

Veja que este processo determina que a fase de implementação deve ser iniciada somente após todas as fases anteriores estarem completas. Podemos enumerar as seguintes características do método cascata:

• Processo tradicional.

• Uma fase só iniciada quando a anterior estiver 100% completa.

• O processo de desenvolvimento é realizado de uma só vez passando por todas as fases de desenvolvimento.

• Cada fase deve estar completa e documentada antes de se iniciar a fase seguinte.

• Dificuldade de se retornar para fases anteriores ao se encontrar problemas na fase atual.

• Maior gasto de tempo e esforço pela equipe para garantir que as fases estão sendo executadas com 100% de conformidades.

Desvantagens do modelo Cascata

Trabalhando-se com esta metodologia e verificando experiências de mercado, podemos perceber que ela traz as seguintes desvantagens:

• Demora para mostrar resultados ao cliente, podendo causar nele impaciência e falta de confiança.

• Dificuldade de se retornar para fases anteriores ao se detectar problemas na fase atual, com maior custo relacionados a implementação dos acertos necessários.

• Probabilidade de haver decepção por parte do usuário ao receber o produto final.

• Custo relacionado à acomodação de mudanças do projeto.

• A equipe de desenvolvimento está sempre quase acabando

• Mascara riscos por muito tempo

• Retarda a solução de riscos críticos

Levantamentos de mercado demonstram que quanto mais adiantado estiver o projeto na linha do tempo, maior é o custo relacionado da correção de erros. Para tratar este fato, desenvolve-se com o passar do tempo outras opções que buscam o desenvolvimento e entrega modular de sistemas. A própria metodologia SCRUM trabalha desta maneira, considerando entregas parciais.

Estaremos vendo outras opções nos próximos artigos.

Saiba mais no livro Engenharia de Software na Prática: http://helioengholmjr.wordpress.com/2013/06/20/engenharia-de-software-na-pratica/

LivroES

Link Novatec: http://www.novatec.com.br/livros/engenhariasoftware/

Link Livraria Cultura:

http://www.livrariacultura.com.br/scripts/resenha/resenha.asp?nitem=22123724

Livraria Saraiva: 

http://www.livrariasaraiva.com.br/produto/3048891




+ Artigos