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


15

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.


3
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

11
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

11
@ 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:


10

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:

  1. "Inspeções de projeto e código para reduzir erros no desenvolvimento de programas" (Fagan 1976)

  2. Remoção de defeitos de software (Dunn 1984)

  3. "Melhoria de processo de software na Hughes Aircraft" (Humphrey, Snyder e WIllis 1991)

e vários mais


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

10

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.