Existe alguma evidência sugerindo que o tempo gasto na redação ou pensando nos requisitos terá algum efeito no tempo de desenvolvimento? Estudo realizado por Standish (1995) sugere que requisitos incompletos (13,1%) contribuíram parcialmente para o fracasso dos projetos. Existem estudos realizados que mostram que o tempo gasto na análise de requisitos terá algum efeito no tempo de desenvolvimento de um projeto, ou no êxito do projeto.
software-engineering
Ken Li
fonte
fonte
Respostas:
Veja Código Completo, por Steve McConnell, Tabela 3-1. Ele compara o custo médio de correção de defeitos com base em quando eles são introduzidos e detectados. A detecção no tempo de construção custa 5 a 10 vezes mais do que a detecção no tempo necessário e 10 a 100 vezes mais após a liberação.
A tabela é baseada nas seguintes fontes:
"Inspeções de projeto e código para reduzir erros no desenvolvimento de programas" (Fagan 1976)
Remoção de defeitos de software (Dunn 1984)
"Melhoria de processo de software na Hughes Aircraft" (Humphrey, Snyder e WIllis 1991)
e vários mais
fonte
Sim, existem muitos estudos sobre esse tópico. Obviamente, a pergunta é geral demais para responder a todos os tipos de projetos de desenvolvimento de software, mas há evidências de vários contextos que apóiam a noção de que a análise adequada dos requisitos terá um impacto positivo no estágio de implementação. Essa evidência foi parcialmente coletada em "leis" e aqui estão três exemplos:
Lei do vidro: deficiências de requisitos são a principal fonte de falhas do projeto.
Essa lei é apoiada por evidências de estudos de caso de grandes projetos de desenvolvimento de software. Glass constatou que, nos casos com falha, havia muitos requisitos, eram instáveis devido a alterações tardias e eram ambíguos e incompletos.
Isso sugere que existe uma relação entre a qualidade dos requisitos e o resultado do projeto.
Primeira lei de Boehm: os erros são mais frequentes durante os requisitos e as atividades de design e são mais caros quanto mais tarde são removidos.
Isso também é apoiado por evidências de estudo de caso e contribui para responder à pergunta da seguinte maneira: fazer os requisitos corretamente reduzirá o número de erros no sistema e corrigi-los antes de iniciar a implementação será mais barato do que procurá-los inativo quando a implementação já foi iniciada (ou pior, quando o sistema já foi enviado).
Segunda lei de Boehm: a prototipagem (significativamente) reduz os requisitos e os erros de design, especialmente para interfaces de usuário.
Isso é apoiado por experimentos controlados no contexto do aluno. Uma possível interpretação é que os requisitos e as fases do projeto não precisam ser inteiramente orientados por documentação e teóricos. Em vez disso, executar a prototipagem como parte das fases de requisitos e design - o que equivale a gastar tempo pensando e sobre os requisitos - afetará o sucesso do projeto e o tempo de implementação.
Também existem muitas outras evidências que apontam na mesma direção: gastar tempo na preparação da implementação compensa na forma de menos risco e menos chance de exceder o cronograma devido a surpresas. Embora a pergunta não fosse sobre testes, a preparação adequada também afeta positivamente os testes.
As referências para essas leis são:
Lei do vidro: Glass, RL: Runaways de software. Lições aprendidas com falhas maciças em projetos de software. Rio Saddle superior, NJ: Prentice Hall 1998
Primeira lei de Boehm: Boehm, BW, McClean, RK, Urfrig, DB: Alguma experiência com auxílios automatizados para o design de software confiável em larga escala. IEEE Trans on Engenharia de Software 1, 1 (1975), 125–133
Segunda lei de Boehm: Boehm, BW, Gray, TE, Seewaldt, T. Prototipagem versus especificação: uma experiência de multiprojeto. IEEE Trans on Engenharia de Software 10, 3 (1984), 290–302
Além disso, a seguinte referência pode ser interessante: Endres, A. e Rombach, D. Um Manual de Engenharia de Software e Sistemas. Observações empíricas, leis e teorias. A série Fraunhofer IESE sobre engenharia de software. Addison Wesley, 2003.
fonte