A Crise no Desenvolvimento de Software

Nos anos mais recentes temos assistido a uma preocupação crescente em relação à “crise do software”, a qual está relacionada com duas ordens de fatores: 1) O aumento do custo do desenvolvimento de software; 2) Com a Incapacidade dos sistemas de software para entregarem os resultados alinhados com as necessidades dos utilizadores.

Projetos de desenvolvimento de software falhados foram, por exemplo:
  • O sistema produzido nos EUA pelo Departamento de Veículos Motorizados. Este sistema tinha como objetivo harmonizar o processo de registo de licenças de condução em todos os Estados. Custou 43 M$ e nunca foi usado.
  • Uma companhia aérea de renome tentou ligar o seu sistema de reservas com o sistema de reservas de duas grandes cadeias de hotéis. O projeto foi cancelado depois de se ter gasto 165 M USD.
  • O sistema computorizado de tratamento de bagagens num novo aeroporto resultou em perdas de milhões de USD decorrentes dos atrasos a que obrigou na data da inauguração do aeroporto.

Estes são exemplos bem conhecidos provenientes dos Estados Unidos mas um pouco por todo o lado existem exemplos de projetos de desenvolvimento de sowftare mal sucedidos e que acarretaram grandes prejuizos para os seus promotores.
As razões para esta incapacidade de desenvolver produtos de software que cumpram com as expectativas dos utilizadores / clientes explica-se por um conjunto relativamente pequeno de razões, dentre as quais as mais importantes são:

Os sistemas de software são cada vez mais complexos


O software é cada vez mais complexo em grande medida porque as novas tecnologias possibilitam o desenvolvimento de funcionalidades muito complexas, e porque as expectativas dos utilizadores em relação ao software criado são cada vez mais elevadas.

Os sistemas de software assentam cada vez mais em plataformas distribuídas


A maioria dos sistemas atuais são distribuídos funcionando em LAN, WAN ou Internet o que coloca dificuldades adicionais ao desenvolvimento. Os projetos de software são frequentemente tão complexos que uma só pessoa não consegue ter uma visão global, clara sobre a totalidade do sistema. Isto tem como consequência que os técnicos de desenvolvimento produzem aplicações elaboradas que tentam fazer demais, e acabam por falhar não conseguindo cumprir com as espectativas dos utilizadores.

A maioria dos sistemas antigos são baseados em Código Proprietário (Sistemas Legados)


A necessidade de integrar código proprietário (código legado) com nova tecnologia, frequentemente adiciona complexidade aos projetos. Este problema é agravado pelo facto de muitos dos programadores originais já não estarem na organização.

Ciclos de desenvolvimento cada vez mais curtos (pressão de mercado)


A necessidade de colocar no mercado novos produtos, e produtos inovadores, antes da concorrência coloca pressão acrescida nas equipas de desenvolvimento.

Requisitos iniciais mal definidos


Pouco tempo dedicado a perceber o que os utilizadores pretendem do novo sistema e falta de método, faz com que os técnicos de desenvolvimento não tenham uma compreensão completa sobre o que estão a criar. Se os requisitos do sistema não estão completamente definidos, antes do desenvolvimento se iniciar, é provável que o resultado não vá de encontro às expectativas dos utilizadores, causando insatisfação ou excesso de alterações e de repetição de trabalho.

Gestão de risco deficiente


A incapacidade para analisar e gerir o risco, ao longo de todo o processo de desenvolvimento do software, aumenta a probabilidade do projeto falhar.

Testes insuficientes


Os testes devem acompanhar todo o processo de desenvolvimento, quanto mais cedo começarem as ações de verificação menor será a probabilidade de encontrar no final erros que exigirão muito trabalho adicional para serem resolvidos. Contudo só a realização de testes não garantem a qualidade. É preciso planear os testes e garantir que os mesmos são realizados e que os resultados são avaliados dando lugar às ações de melhoria ou correção necessárias.

Postagens mais visitadas deste blog

PMBOK v6: 7.4 Controlar os Custos do Projeto

PMBOK v6: 5.2 Coletar os Requisitos