Esta série de artigos sobre Metodologia XP de desenvolvimento ágil é uma versão compacta do trabalho de conclusão de curso (TCC) onde o título original da monografia em que foi baseada esta série é:
O USO DA METODOLOGIA XP NO DESENVOLVIMENTO DE SOFTWARE E OS IMPACTOS NA GESTÃO DE RISCOS
Toda semana, sempre às segundas-feiras, postaremos uma parte ou capítulo da monografia, o que totalizará 10 semanas de postagens. No capitulo de hoje, abordaremos o tópico “A crise do Software” para familiarizarmos com as dificuldades que equipes de desenvolvimento enfrentam nos seus projetos de software.
Sumário do artigo “Metodologia XP”:
- Metodologia XP (eXtreme Programming) – A crise do software
- Metodologia XP (eXtreme Programming) – Qualidade de software
- Metodologia XP (eXtreme Programming) – Modelos tradicionais
- Metodologia XP (eXtreme Programming) – Desenvolvimento Ágil
- Metodologia XP (eXtreme Programming) – Breve histórico da XP
- Metodologia XP (eXtreme Programming) – Valores da XP
- Metodologia XP (eXtreme Programming) – Boas Práticas da XP (parte1)
- Metodologia XP (eXtreme Programming) – Boas Práticas da XP (parte 2)
- Metodologia XP (eXtreme Programming) – Comparativos entre as metodologias
A crise do Software
O software tornou-se um elemento imprescindível na nossa vida, estando presente tanto nas tarefas corriqueiras do dia-a-dia, como programar a TV, até as transações bancárias que movimentam bilhões de dólares e aquecem a economia global (ASTELS et al, 2002). As inúmeras aplicações foram aumentando gradativamente ao longo dos anos e segundo Pressman (2006), o software passou por diversas transformações, a começar pelo programador, que antigamente trabalhava solitário e depois foi substituído por uma equipe de especialistas em software, cada um se concentrando em uma pequena parte da aplicação.
De acordo com Brooks (1975, apud PRESSMAN, 2006), a necessidade de softwares mais complexos era indispensável para acompanhar as transformações ocorridas no mundo nas décadas de 60 e 70. Infelizmente, a comunidade de software ainda não estava preparada para essas mudanças, tanto que muitos projetos de software fracassaram durante esse período. Os softwares eram mal projetados e por isso estouravam o tempo planejado e consequentemente custavam mais, Sommerville no seu livro vem reafirmar:
[…] O software era entregue com atraso, não era confiável, custava várias vezes mais do que previam as estimativas originais e, muitas vezes, exibia características precárias de desempenho […] (BROOKS, 1975, p.60 apud SOMMERVILLE, 2007).
A comunidade de software necessitava de algo que a ajudasse a melhorar seus processos e técnicas de desenvolvimento, e em 1968 surgiu o termo “Engenharia de Software”, uma disciplina criada exclusivamente para estudar e aprimorar o desenvolvimento de software (SOMMERVILLE, 2007). Nesse mesmo ano, de acordo com Teles (2005), ocorreu na Alemanha a Conferência da OTAN (Organização do Tratado do Atlântico Norte) sobre Engenharia de Software, organizada para discutir sobre a chamada “Crise de Software”, a qual Sommerville (2007) atribuía à evolução do hardware de terceira geração que tornava possível muitas aplicações de softwares até então inimagináveis.
Para vencer a “crise do software” a Engenharia de Software tem proposto a cada dia novos métodos para controlar a complexidade dos softwares, começando pelas metodologias de desenvolvimento linear, conhecidas inicialmente por modelo em cascata, até os atuais processos ágeis de desenvolvimento. Entretanto, ainda hoje muitos projetos de software têm problemas e isso levou alguns críticos (PRESSMAN, 1997) a sugerirem que a Engenharia de Software está em um estado de aflição crônica.
A “aflição crônica” sugerida por Pressman pode ser comprovada através de um estudo intitulado de Chaos Research (STANDISH, 2006), que é realizado desde 1994 pela Standish Group International. O resultado é um relatório abrangente sobre o sucesso e o fracasso de milhares de projetos na área da tecnologia da informação. De acordo com Castro (2007), este estudo engloba uma grande quantidade de projetos e a maior parte deles são baseados no desenvolvimento tradicional.
No relatório Chaos Research, os projetos são enquadrados em três categorias distintas:
- Mal sucedido – O projeto é cancelado em algum momento do desenvolvimento por uma ou mais razões;
- Bem sucedido – O projeto é concluído dentro do prazo previsto e do orçamento estimado;
- Comprometido – O Projeto é concluído. Porém, é entregue com atraso, com orçamento além do estimado, e em alguns casos, o software não possui todas as funcionalidades especificadas.
Figura 1 – Resultado do relatório Chaos Research de 1994
Fonte: modificado de The Standish Group International Inc (2006).
Figura 2 – Resultado do relatório Chaos Research de 2004
Fonte: modificado de The Standish Group International Inc (2006).
Observando as Figuras 1 e 2, nota-se que em 10 anos os projetos bem sucedidos tiveram uma melhora de quase 100%. Entretanto, esses resultados ainda são muito ruins, pois os projetos mal sucedidos e comprometidos correspondem a mais de 70% do total. Isto leva a deduzir que as técnicas e métodos desenvolvidos pela Engenharia de Software ainda não são adequados para atender a evolução que o desenvolvimento de software necessita para vencer a “crise do software”.
Continue lendo essa série de artigos sobre em Metodologia XP ( eXtreme Programming ) – Qualidade de software
Observação: Todos as referências serão creditadas no último artigo da série.
