O conceito de Engenharia de Software surgiu inicialmente em uma conferência organizada para discutir o que foi então chamada de crise de software. Este post tem como objetivo mostrar o fracasso da engenharia de sofware tradicional mostrando que pouco mudou desde então. O Standish Group, publicou uma série de relatórios de caos descrevendo embaraçosamente os projetos de TI e suas baixas taxas de sucesso, começando com uma péssima
taxa de 16 por cento em 1994 e uma melhoria para ridículos 34 por cento em 2006 . Outras pesquisas mostram que nossa Engenharia de Software não mudou muito a crise de software.
As estatísticas da Scientific American [filho, 2000] mostram que o tempo realizado dos projetos de software excede em 50% o tempo planejado no cronograma do projeto.
O standish Groups relatou em 1994 [Standish, 1994] que apenas 16% dos projetos de software atingem o seu objetivo dentro do cronograma e do orçamento previstos.
Os dados de 2001 do Standish Groups [Standish, 2001] mostram as seguintes estatísticas: 27% dos projetos de software são finalizados no tempo e custos previstos; 40% dos projetos são cancelados antes de finalizarem; 50% dos projetos custam em média 108% a mais da estimativa original; em 2006 a Standish O CHAOS Report [Standish, 2006] apresentou os seguintes dados: apenas 34% dos projetos são bem sucedidos.
Cabe salientar que ocorreu uma pequena melhoria nas estatísticas de projetos que terminam dentro do prazo (cronograma) e orçamento previstos do Standish Group de 1994 (16%) , 2001 (27%) e 2006 (34%). Entretando, a melhoria ainda se mostra frustrante e seus índices um tanto embaraçador.
Note que se um projeto é subestimado, mesmo utilizando-se os melhores métodos para a elicitação de requisitos, design, implementação e testes, o projeto corre um alto risco (40%) de ser cancelado.
O principal risco que afeta os projetos de software subestimados é o de pressão excessiva do cronograma, o qual pode forçar o término prematuro do projeto, colocando em risco a qualidade e a funcionalidade do projeto [Jones, 1994]. Entre as possíveis conseqüências desse risco temos: cancelamento do projeto, baixa moral da equipe, baixa qualidade, atrasos de cronograma, custos excessivos devido a um grande número de horas extras e atritos entre o gerente e a equipe [Hazan, 1999].
Nas pesquisas aqui explanadas, não são contempladas os projetos que não obtiveram êxito no processo de licitação ou as propostas que não foram aceitas por algum contratante devido a sua estimativa superestimada em seu orçamento.
Outra pesquisa muito conhecida no mundo ágil é de utilização das funcionalidades de um software. Esta estatística demonstra que 64% da funcionalidades de um software típico raramente ou nunca são usadas, salientando para um grade desperdício de código desenvolvido.
Estas pesquisas demonstram que, nossa área de Desenvolvimento de Software, não somente não fazemos software direito mas também fazemos as coisas erradas.
A solução para tudo isto fica para os próximos posts...
taxa de 16 por cento em 1994 e uma melhoria para ridículos 34 por cento em 2006 . Outras pesquisas mostram que nossa Engenharia de Software não mudou muito a crise de software.As estatísticas da Scientific American [filho, 2000] mostram que o tempo realizado dos projetos de software excede em 50% o tempo planejado no cronograma do projeto.
O standish Groups relatou em 1994 [Standish, 1994] que apenas 16% dos projetos de software atingem o seu objetivo dentro do cronograma e do orçamento previstos.
Os dados de 2001 do Standish Groups [Standish, 2001] mostram as seguintes estatísticas: 27% dos projetos de software são finalizados no tempo e custos previstos; 40% dos projetos são cancelados antes de finalizarem; 50% dos projetos custam em média 108% a mais da estimativa original; em 2006 a Standish O CHAOS Report [Standish, 2006] apresentou os seguintes dados: apenas 34% dos projetos são bem sucedidos.
Cabe salientar que ocorreu uma pequena melhoria nas estatísticas de projetos que terminam dentro do prazo (cronograma) e orçamento previstos do Standish Group de 1994 (16%) , 2001 (27%) e 2006 (34%). Entretando, a melhoria ainda se mostra frustrante e seus índices um tanto embaraçador.
Note que se um projeto é subestimado, mesmo utilizando-se os melhores métodos para a elicitação de requisitos, design, implementação e testes, o projeto corre um alto risco (40%) de ser cancelado.
O principal risco que afeta os projetos de software subestimados é o de pressão excessiva do cronograma, o qual pode forçar o término prematuro do projeto, colocando em risco a qualidade e a funcionalidade do projeto [Jones, 1994]. Entre as possíveis conseqüências desse risco temos: cancelamento do projeto, baixa moral da equipe, baixa qualidade, atrasos de cronograma, custos excessivos devido a um grande número de horas extras e atritos entre o gerente e a equipe [Hazan, 1999].
Nas pesquisas aqui explanadas, não são contempladas os projetos que não obtiveram êxito no processo de licitação ou as propostas que não foram aceitas por algum contratante devido a sua estimativa superestimada em seu orçamento.
Outra pesquisa muito conhecida no mundo ágil é de utilização das funcionalidades de um software. Esta estatística demonstra que 64% da funcionalidades de um software típico raramente ou nunca são usadas, salientando para um grade desperdício de código desenvolvido.
Estas pesquisas demonstram que, nossa área de Desenvolvimento de Software, não somente não fazemos software direito mas também fazemos as coisas erradas.
A solução para tudo isto fica para os próximos posts...
Postagens
Nenhum comentário:
Postar um comentário