Sucessos e Fracassos em projetos de sw

O que impediria um projeto de software não se tornar estatística para a Crise de Software?

Em primeiro lugar, é importante identificar o que não contribui para o fracasso. Jim Johnson, do The Standish Group, afirma que "quando um projeto falha, raramente a causa é técnica". Em outras palavras, o problema não é que .NET, Java ou outras tecnologias e ferramentas sejam instrumentos limitados para a construção de soluções de TI. A raiz comum para a maioria das falhas, na verdade, está na (ausência de) utilização de metodologias de desenvolvimento e como elas interagem com os indivíduos envolvidos em um projeto de software.

Por "metodologia de desenvolvimento", entende-se o conjunto de atividades, responsabilidades, artefatos (documentos, diagramas, código-fonte, etc.), orientações e boas práticas utilizadas para planejar, construir e implantar software.

Um dos problemas mais críticos que a utilização de uma metodologia pode apresentar é ignorar o cliente e o usuário final em um projeto. A falta de envolvimento de ambos durante todo o desenvolvimento está diretamente relacionada ao fracasso. Requisitos e especificações incompletas, como conseqüência, também constituem uma deficiência-chave.

Por outro lado, falta de suporte executivo e pouca agilidade na resposta a mudanças também impactam bastante negativamente, de maneira decisiva, em um projeto de software. Ambos os fatores demandam articulação competente da gerência de projeto não apenas com a equipe como também com o ambiente externo ao projeto.

Outra causa do fracasso consiste na incapacidade de negociar conflitos entre os indivíduos envolvidos (equipe, cliente, usuários ou qualquer outro afetado pelo projeto). A esse problema, também estão relacionados:

• Objetivos nebulosos (não existe uma visão comum, compartilhada, entre o que o cliente deseja e o que a equipe do projeto está construindo);
• Expectativas irrealistas (o cliente ou usuários, por exemplo, podem não estar cientes do escopo a