Artigo de opinião publicado no diário ‘As Beiras’
em 5 de Dezembro de 2011
O sucesso de qualquer projeto de engenharia exige, para além de uma série de condições materiais e de uma equipa com as necessárias competências técnicas, uma rigorosa metodologia de desenvolvimento. Assim acontece também no caso dos projetos de Engenharia Informática.
A metodologia tradicional de desenvolvimento de projetos informáticos é conhecida por metodologia “em cascata”, devendo-se esse nome ao fato de que cada fase do desenvolvimento dá origem à seguinte, de forma sequencial, sem que exista possibilidade de fases posteriores influenciarem o desenvolvimento. Com efeito, também a água que desce uma cascata não tem forma de voltar ao seu início.
Durante várias décadas, o desenvolvimento em cascata foi considerado o método perfeito. Numa primeira fase faz-se um exaustivo planeamento, que inclui o levantamento de requisitos, a especificação do sistema a desenvolver, a identificação das diversas tarefas a executar, a respectiva duração e os meios necessários. Todos estes aspetos devem ser exaustivamente documentados. Uma vez aprovado o planeamento, segue-se a fase da execução, na qual a equipa de desenvolvimento deve por em prática tudo o que foi decidido na fase de planeamento. A última fase é a dos testes – por entidade certificada – e aceitação por parte do cliente.
A metodologia em cascata é bastante rígida, tendo vantagens e desvantagens. Do lado das vantagens, há a assinalar o grande controlo que permite sobre a execução do projeto. No entanto, a principal desvantagem é a de que assume que quer os utilizadores, quer o cliente da aplicação quer, ainda, quem a desenvolve, são pessoas cuja visão não muda ao longo de todo o desenvolvimento, que não podem ter qualquer criatividade, e que executam as tarefas como se fossem robôs e não seres humanos.
O reconhecimento dessa desvantagem levou ao aparecimento, no início da década de 1990, de metodologias de desenvolvimento rápido, das quais a metodologia ‘Scrum’ é a mais conhecida e mais utilizada. Neste caso, a metodologia assume que os requisitos podem mudar ao longo do projeto, assim como os objetivos da aplicação ou sistema, por forma a refletir a natureza dinâmica de utilizadores, clientes e desenvolvedores. Em cada ciclo de desenvolvimento – denominado ‘sprint’ – os objetivos são reavaliados à luz do trabalho realizado, dos erros e experiência acumulados, e de novas ideias ou requisitos.
Também esta metodologia tem riscos – frequentemente desvalorizados e, quiçá, mais problemáticos que os de metodologias mais rígidas – compensados, no entanto, por um muito maior potencial para atingir produtos de maior qualidade, mais fáceis de utilizar e mais próximos das necessidades do mercado. Não existirá uma metodologia perfeita mas, ao prever formas de lidar com a mudança e com a imperfeição humanas, esta metodologia dá um grande passo nesse sentido.
Sem comentários:
Enviar um comentário