chesteve/teaching-ea976 — pull request #23 by ra134762 (2014-09-17 02:31:50+00:00)
Title: Merge pull request #1 from chesteve/master

+ATIVIDADE COMPLEMENTAR 1
+
+Leia o artigo de Cerpa e Verner (Why did your project fail?),
+disponível em http://dl.acm.org/citation.cfm?id=1610286 e na área de Leituras do ambiente Ensino Aberto,
+e responda às seguintes questões:
+
+1. No estudo dos autores, qual foi a proporção de projetos de software que falharam? Esse valor é confiável?
+

Resposta: Depois de tirar os projetos com valores incompletos da pesquisa, sobraram 235 projetos, dos quais 70 (30%) foram considerados como falhos pelos desenvolvedores. Como o método dos autores foi abrangente (perguntaram para diferentes tipos de desenvolvedores, de diferentes partes do mundo), e teve perguntas para mais de um integrante de cada projeto (isso evita inconsistências como a descrita no artigo, dos project managers serem enviesados a não admitirem falhas, pelas políticas da empresa que o pressionam a pensar assim), pode-se dizer que o valor é confiável. Por causa da natureza neutra das perguntas e do texto, além das perguntas sobre casos bem sucedidos além dos mal sucedidos, essa pesquisa não teria os mesmos questionamentos da pesquisa do Standish Group.

2. A figura 1 apresenta os principais fatores de falhas em projetos de software e relações entre eles, mas não dá nome para essas relações. Escolha dois fatores que estejam relacionados e discuta qual a relação que você acha que existe entre elas, justificando sua resposta.

Resposta: Um exemplo de fatores que causam problemas nos projetos e estão relacionados diretamente são os de o projeto ser mal estimado e ele ter trabalhadores adicionados tardiamente. Neste caso, o segundo é causa direta do primeiro, já que um projeto que não é bem planejado desde o começo tem muita chance de precisar de mais pessoal mais pra frente, o que acaba sendo um novo fator problemático, como atraso do projeto para integrar os novos desenvolvedores.

3. Qual é a sugestão dos autores para que futuros projetos de software fracassem menos, e como essa sugestão ajudaria a melhorar os novos projetos? +

Resposta: Os autores mostram vários fatores que são recorrentes nos projetos falhos, e citam o artigo do Glass dizendo que parece que temos que aprender as mesmas lições várias vezes. Seria importante que entendessemos bem esses problemas recorrentes a fim de evita-los, como por exemplo dar mais importância e escolher as pessoas certas para realizar as estimativas anteriores ao projeto. É muito importante também, com esse planejamento, escolher prazos que sejam saudáveis e sempre pensar bem nos riscos de cada projeto.