Tempo gasto no requisito e seu efeito no sucesso do projeto e no tempo de desenvolvimento

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

Como os modelos ágeis se encaixam aqui? Pode-se argumentar que eles gastam tempo com requisitos (ligado e desligado), mas não há "fase" de requisitos como tal.

— Raphael

Concordo com @Raphael. Vamos fazer perguntas sobre engenharia de software? Ou é a política oficial do site que não vale a pena distinguir entre "ciência da computação" e "engenharia de software" neste momento?

— precisa saber é o seguinte

@ Patrick87 Vamos passar isso para meta .

— Raphael

Parece-me que essa pergunta seria mais adequada para os sites existentes de Engenharia de Software e Gerenciamento de Projetos .

— Adam Lear

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

— Joe
fonte

Isso por si só não é suficiente. Erros caros têm que acontecer com bastante frequência e precisam ser detectados com bastante frequência, apresentando os requisitos adequados. Caso contrário, o custo extra da apresentação de requisitos ainda poderá superar os custos de erro.

— Raphael

Isso é verdade. Temos que assumir que, até um certo ponto, não se apressar nos requisitos significa que há menos erros nos requisitos, mas isso não parece exagero.

— Joe

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.

— Fabian Fagerholm
fonte