Eu prefácio isso com o fato de que a maior parte do que estou descobrindo vem dos anos 1970 e início dos anos 1980. Durante esse período, os modelos de processos seqüenciais eram muito mais comuns do que as abordagens iterativas e / ou incrementais (o modelo Spiral ou os métodos ágeis). Grande parte deste trabalho é construída sobre esses modelos seqüenciais. No entanto, não acho que isso destrua o relacionamento, mas um dos benefícios das abordagens iterativas / incrementais é liberar recursos (uma fatia vertical inteira de um aplicativo) rapidamente e corrigir problemas nele antes que as dependências sejam injetadas e a complexidade de cada fase é alto.
Acabei de retirar minha cópia da Software Engineering Economics e encontrei uma referência aos dados por trás deste gráfico no Capítulo 4. Ele cita "Inspeções de projeto e código para reduzir erros no desenvolvimento de programas" por ME Fagan ( IEEE , PDF da UMD ), EB Daly, "Gerenciamento da engenharia de software", WE Stephenson, "Uma análise dos recursos utilizados no desenvolvimento de software para sistemas de salvaguarda" ( ACM ) e "vários projetos da TRW".
... o custo relativo de corrigir erros de software (ou fazer outras alterações de software) em função da fase em que as correções ou alterações são feitas. Se um erro de requisitos de software for detectado e corrigido durante a fase de planos e requisitos, sua correção é uma questão relativamente simples de atualizar a especificação de requisitos. Se o mesmo erro não for corrigido até a fase de manutenção, a correção envolverá um inventário muito maior de especificações, código, manuais do usuário e de manutenção e material de treinamento.
Além disso, as correções tardias envolvem um processo de aprovação e controle de mudanças muito mais formal e uma atividade muito mais extensa para revalidar a correção. Esses fatores se combinam para tornar o erro tipicamente 100 vezes mais caro de corrigir na fase de manutenção em grandes projetos do que na fase de requisitos.
Bohem também analisou dois projetos menores e menos formais e encontrou um aumento no custo, mas muito menos significativo do que as cem vezes identificadas nos projetos maiores. Dado o gráfico, as diferenças parecem ser 4 vezes maiores para corrigir um defeito de requisitos após o sistema estar operacional do que na fase de requisitos. Ele atribuiu isso ao menor estoque de itens que compõem o projeto e à formalidade reduzida que levou à capacidade de implementar reparos mais simples e mais rápidos.
Com base na Boehm em Economia de engenharia de software, a tabela no Code Complete é bastante inchada (a extremidade inferior dos intervalos geralmente é muito alta). O custo para fazer qualquer alteração na fase é de fato 1. Extrapolando da Figura 4-2 em Economia de Engenharia de Software, uma alteração de requisitos deve ser de 1,5 a 2,5 vezes na arquitetura, de 2,5 a 10 em codificação, de 4 a 20 em testes e de 4 a 4 100 em manutenção. A quantia depende do tamanho e complexidade do projeto, bem como da formalidade do processo usado.
No Apêndice E de Barry Boehm e Agilidade e Disciplina de Equilíbrio de Richard Turner, há uma pequena seção sobre as descobertas empíricas sobre o custo da mudança.
Os parágrafos de abertura citam o Extreme Programming Explained de Kent Beck, citando Beck. Ele diz que, se o custo das mudanças aumentasse lentamente ao longo do tempo, as decisões seriam tomadas o mais tardar possível e apenas o necessário seria implementado. Isso é conhecido como "curva plana" e é o que impulsiona a programação extrema. No entanto, o que a literatura anterior encontrou foi a "curva íngreme", com sistemas pequenos (<5 KSLOC) com alteração de 5: 1 e sistemas grandes com alteração de 100: 1.
A seção cita o Centro de Engenharia de Software Empiricamente Baseado da Universidade de Maryland (patrocinado pela National Science Foundation). Eles realizaram uma pesquisa na literatura disponível e descobriram que os resultados tendiam a confirmar uma proporção de 100: 1, com alguns resultados indicando um intervalo de 70: 1 a 125: 1. Infelizmente, esses eram tipicamente projetos de "grande design inicial" e gerenciados de maneira seqüencial.
Existem exemplos de "pequenos projetos Java comerciais" executados usando o Extreme Programming. Para cada história, a quantidade de esforço na correção de erros, novo design e refatoração foi rastreada. Os dados mostram que, à medida que o sistema é desenvolvido (mais histórias de usuários são implementadas), o esforço médio tende a aumentar em uma taxa não trivial. O esforço na refatoração aumenta cerca de 5% e os esforços para a fixação do esforço aumentam cerca de 4%.
O que estou aprendendo é que a complexidade do sistema desempenha um grande papel na quantidade de esforço necessária. Ao criar fatias verticais através do sistema, você diminui a velocidade da curva adicionando lentamente complexidade em vez de adicioná-la em pilhas. Em vez de lidar com a massa de complexidade de requisitos, seguida por uma arquitetura extremamente complexa, seguida por uma implementação extremamente complexa e assim por diante, você começa de maneira muito simples e complementa.
Que impacto isso tem no custo a ser corrigido? No final, talvez não muito. No entanto, possui as vantagens de permitir mais controle sobre a complexidade (por meio do gerenciamento de dívidas técnicas). Além disso, as entregas frequentes frequentemente associadas ao ágil significam que o projeto pode terminar mais cedo - em vez de entregar o "sistema", as peças são entregues até que as necessidades da empresa sejam satisfeitas ou mudem drasticamente em relação a um novo sistema (e, portanto, um novo projeto) é preciso.
As métricas e modelos de Stephen Kan em engenharia de qualidade de software têm uma seção no capítulo 6 sobre o custo-benefício da remoção de defeitos de fase.
Ele começa citando o artigo de Fagan de 1976 (também citado em Economia de Engenharia de Software) para afirmar que o retrabalho feito em design de alto nível (arquitetura do sistema), design de baixo nível (design detalhado) e implementação pode ser entre 10 e 100 vezes mais barato do que o trabalho realizado durante os testes no nível do componente e do sistema.
Ele também cita duas publicações, de 1982 e 1984, de Freedman e Weinberg que discutem sistemas grandes. O primeiro é "Manual de orientações, inspeções e revisões técnicas" e o segundo é "Revisões, orientações e inspeções". A aplicação das revisões no início do ciclo de desenvolvimento pode reduzir o número de erros que atingem as fases de teste em um fator de 10. Essa redução no número de defeitos leva à redução dos custos de teste em 50% a 80%. Eu precisaria ler os estudos com mais detalhes, mas parece que o custo também inclui encontrar e corrigir os defeitos.
Um estudo realizado por Remus em 1983, "Validação Integrada de Software na Visão de Inspeções / Revisão", estudou o custo de remoção de defeitos em diferentes fases, especificamente design / código de inspeções, testes e manutenção, usando dados do Santa Teresa Laboratory da IBM na Califórnia. Os resultados citados indicam uma relação de custo de 1:20:82. Ou seja, um defeito encontrado nas inspeções de projeto ou código tem um custo de alteração de 1. Se o mesmo defeito escapar para o teste, custará 20 vezes mais. Se ele escapa todo o caminho para um usuário, ele multiplicará o custo de correção em até 82. Kan, usando dados de amostra das instalações de IBM em Rochester, Minnessota, considerou o custo de remoção de defeitos do projeto AS / 400 semelhante em 1:13:92. No entanto, ele ressalta que o aumento no custo pode ser devido à maior dificuldade em encontrar um defeito.
As publicações de Gilb de 1993 ( "Inspeção de software" ) e 1999 ("Otimizando processos de controle e qualidade de especificação de engenharia de software") sobre inspeção de software são mencionadas para corroborar os outros estudos.
Informações adicionais podem ser encontradas na página da Construx em Aumento de custo de defeitos , que fornece várias referências sobre o aumento no custo de reparo de defeitos. Deve-se notar que Steve McConnell, autor do Code Complete, fundou e trabalha para o Construx.
Recentemente, ouvi uma palestra, Real Software Engineering , dada por Glenn Vanderburg na Lone Star Ruby Conference em 2010. Ele fez a mesma palestra na Scottish Ruby Conference e Erubycon em 2011, QCon San Francisco em 2012 e O'Reilly Software Architecture Conference em 2015 . Só ouvi a Lone Star Ruby Conference, mas a conversa evoluiu ao longo do tempo à medida que suas idéias eram refinadas.
Venderburg sugere que todos esses dados históricos estão realmente mostrando o custo para corrigir defeitos à medida que o tempo avança, não necessariamente à medida que um projeto se move através das fases. Muitos dos projetos examinados nos documentos e livros mencionados anteriormente eram projetos sequenciais de "cascata", onde fase e tempo se moviam juntos. No entanto, um padrão semelhante surgiria em projetos iterativos e incrementais - se um defeito fosse injetado em uma iteração, seria relativamente barato corrigi-la. No entanto, à medida que as iterações avançam, muitas coisas acontecem - o software se torna mais complexo, as pessoas esquecem alguns dos pequenos detalhes sobre o trabalho em módulos ou partes específicas do código, os requisitos mudam. Tudo isso aumentará o custo da correção do defeito.
Eu acho que isso provavelmente está mais próximo da realidade. Em um projeto em cascata, o custo aumenta devido à quantidade de artefatos que precisam ser corrigidos devido a um problema de upstream. Em projetos iterativos e incrementais, o custo aumenta devido a um aumento na complexidade do software.