A metodologia de teste de software depende de dados defeituosos?


45

É um fato bem conhecido na engenharia de software que o custo de corrigir um erro aumenta exponencialmente quanto mais tarde no desenvolvimento esse bug é descoberto. Isso é suportado pelos dados publicados no Code Complete e adaptados em várias outras publicações.

No entanto, esses dados nunca existiram . Os dados citados pelo Code Complete aparentemente não mostram essa correlação de custo / tempo de desenvolvimento, e tabelas semelhantes publicadas apenas mostraram a correlação em alguns casos especiais e uma curva plana em outros (ou seja, nenhum aumento no custo).

Existem dados independentes para corroborar ou refutar isso?

E se verdadeiro (ou seja, se simplesmente não há dados para suportar esse custo exponencialmente mais alto para erros descobertos mais tarde), como isso afeta a metodologia de desenvolvimento de software?


Isso parece lógico, pois a descoberta de erros mais tarde na maioria dos casos também envolve corrupção de dados. Além disso, a existência de dados corrompidos custa muito às empresas, se isso for descoberto mais tarde no processo de correção do bug.
EL Yusubov 4/12/12

8
@ElYusubov Sim, de fato. Mas o senso comum pode ser muito enganador. Nossas mentes são facilmente enganadas pela lógica aparente quando na verdade é o contrário. É por isso que a engenharia de software baseada em evidências é tão importante.
precisa saber é o seguinte


2
Para o registro (e mencionado na minha resposta), a primeira menção a isso que consegui encontrar é muito antes do Código Completo. O trabalho de Fagan e Stephenson (independentemente) em 1976 é a primeira referência a isso que posso encontrar. A primeira edição do Code Complete não foi publicada até 1993, quase 20 anos depois. Eu esperaria que o trabalho de Barry Boehm nos anos 80 tenha levado ao aumento da popularidade dessa idéia - o trabalho de Boehm foi muito influente no processo de engenharia de software nos anos 80 e até no final dos anos 2000.
Thomas Owens

1
É axiomático que qualquer declaração sobre estatísticas de engenharia de software esteja errada, incluindo esta. (Os erros que encontrar mais tarde são geralmente os erros mais complexos e corrigi-los é complicado mais pelos "controles" postas em prática re correções tarde prazo..)
Daniel R Hicks

Respostas:


25

A metodologia de teste de software depende de dados defeituosos?

Sim, comprovadamente. Examinar a curva de custo ágil da mudança mostra que parte do trabalho de Kent Beck no XP (não tenho certeza se isso fazia parte de sua motivação ou justificativa) era "achatar a curva" dos custos de defeitos, com base no conhecimento da " curva exponencial "que fica atrás da tabela Código completo. Portanto, sim, trabalhe em pelo menos uma metodologia - a que mais fez popularizar o desenvolvimento do primeiro teste - é pelo menos em parte baseada em dados defeituosos.

Existem dados independentes para corroborar ou refutar isso?

Sim, certamente existem outros dados que você pode procurar - o maior estudo que conheço é a análise de defeitos feitos na Hughes Aircraft como parte de seu programa de avaliação CMM . O relatório de lá mostra como os custos dos defeitos dependiam da fase para eles : embora os dados nesse relatório não incluam variações, você precisa tomar cuidado para tirar muitas conclusões "isso custa mais do que isso". Você também deve observar que, independentemente da metodologia, houve mudanças nas ferramentas e técnicas entre os anos 80 e hoje que questionam a relevância desses dados.

Portanto, supondo que ainda tenhamos um problema para justificar esses números:

como isso afeta a metodologia de desenvolvimento de software?

O fato de confiarmos em números que não podem ser verificados não impediu as pessoas de progredir com base em histórias e experiências: da mesma maneira que muitos negócios de aprendizes são aprendidos. Eu não acho que houve um Journal of Maçonaria Baseada em Evidências durante a Idade Média, mas um monte de edifícios grandes, impressionantes e duradouros foram, no entanto, construídos com certa quantidade de sucesso observável. O que isso significa é que estamos baseando nossa prática principalmente no "que funcionou para mim ou para as pessoas que conheci"; não é uma coisa ruim, mas talvez não seja a maneira mais eficiente de melhorar um campo de milhões de pessoas que fornecem a pedra angular da era tecnológica atual.

Acho decepcionante que, na chamada disciplina de engenharia, não tenha uma base melhor empirismo, e suspeito (embora claramente não possa provar) que poderíamos fazer um progresso melhor e mais claro na melhoria de nossas técnicas e metodologias. esse fundamento em vigor - assim como a medicina clínica parece ter sido transformada pela prática baseada em evidências. Isso se baseia em algumas grandes suposições:

  • que a natureza proprietária da maioria das práticas de engenharia de software não impede a coleta de dados úteis e relevantes suficientes;
  • que as conclusões tiradas desses dados são geralmente aplicáveis ​​(como a engenharia de software é uma profissão qualificada, variações pessoais na experiência, capacidade e gosto podem afetar essa aplicabilidade);
  • que os engenheiros de software "em campo" são capazes e motivados para fazer uso dos resultados assim obtidos; e
  • que sabemos realmente que perguntas devemos fazer em primeiro lugar. Este é obviamente o maior ponto aqui: quando falamos em melhorar a engenharia de software, o que queremos melhorar? Qual é a medida? Melhorar essa medida realmente melhora o resultado ou é uma brincadeira com o sistema? Como exemplo, suponha que a gerência da minha empresa decidisse que diminuiríamos a proporção entre o custo real do projeto e o custo previsto do projeto. Eu poderia começar a multiplicar todas as minhas estimativas de custo por um fator de falsificação e atingir essa "meta". Deveria então tornar-se prática padrão da indústria falsificar todas as estimativas?

Meta-resposta impressionante sobre engenharia baseada em evidências. Obrigado.
Konrad Rudolph

4
Porra, acabei de perceber que isso vem direto da boca do cavalo. Ele Ele. Impressionante.
Konrad Rudolph

1
Tenho a sensação de que todo mundo está interpretando o uso de "dados defeituosos" como "completamente falso, o oposto é verdadeiro", mas tenho a sensação de que sua posição é simplesmente apontar que pode ser falso. Isso está correto?
Daniel B

3
@DanielB Correct. Mostre-me evidências de que está realmente errado e eu posso mudar de idéia; até então, só sei que isso não é comprovadamente certo.

1
@GrahamLee Entendo o seu ponto (pense que o fraseado pode ter sido um pouco desnecessariamente agressivo). Por curiosidade, encontrei o artigo de Fagan aqui , e ele diz "... permite retrabalho ... perto de sua origem ... 10 a 100 vezes menos caro do que se fosse feito na última metade do processo". Não vejo citações próximas a este texto.
Daniel B

8

De minha parte, a resposta para "como isso afeta a metodologia de desenvolvimento de software" não é "muito".

Seja pego pelo desenvolvedor ou pelo usuário final, seja preciso mais dinheiro para corrigi-lo depois de ter sido pego pelo usuário ou não, o fato é que um bug foi encontrado no sistema. Se capturado pelo desenvolvedor, espero que seja uma solução rápida. A mesma esperança se aplica aos bugs detectados pelo usuário.

Independentemente do custo real por hora do desenvolvedor para corrigir um bug detectado por um usuário final, existe o custo intangível de manter o estereótipo de que os codificadores sugam o que fazem. Quando um usuário encontra um bug, a culpa é do desenvolvedor. Portanto, cada bug encontrado pelo usuário final reduz a confiança do usuário no sistema. É como visitar uma casa que você deseja comprar e ver uma mancha de água aparecendo pelo teto em um canto da casa. Isso, por si só, é uma solução fácil, mas você se pergunta o que a causou e o que mais essa causa raiz pode ter afetado. Quanto vale a sua paz de espírito? Você pode ter que rasgar as paredes de volta aos pregos e inspecionar visualmente tudo para garantir que a mancha provenha de um incidente isolado que foi corrigido. Saber que isso pode ser uma possibilidade não o deixa muito confiante em casa. Similarmente,

Esses custos intangíveis são evitados quanto mais cedo o bug for detectado, que é o objetivo declarado das metodologias no estilo TDD. Um bug detectado durante a digitação pelo desenvolvedor ou parceiro em um par, um detectado no momento da compilação ou detectado pelo teste de unidade / integração (a camada adicionada pelo TDD), é um bug que o usuário nunca precisa conhecer, que seu o gerente de projetos nunca precisa se desculpar e que você não precisa fazer nada do que está fazendo certo neste segundo para mudar de marcha para o modo de correção de defeitos em uma parte do sistema que você pensou ter deixado para trás semanas atrás.


3
Resposta interessante. Eu tento fazer com que meus usuários entendam que o desenvolvimento é um processo iterativo ou que refina e melhora. Posso dar a eles algo muito rapidamente e, se encontrarem problemas ou quiserem melhorias, também posso mudar essas mudanças muito rapidamente (minutos ou horas, não dias ou semanas). O sistema se torna mais estável ao longo do tempo, mas eles confiam no processo de desenvolvimento e no resultado final, em vez do processo de especificação e primeira compilação. (é claro que depende do ambiente em que você trabalha - estou escrevendo aplicativos de linha de negócios, portanto, se eles quebrarem, serão corrigidos).
precisa saber é o seguinte

Infelizmente, a evidência original - que os erros de requisitos encontrados quando o produto é colocado em campo são os mais caros do que os erros de implementação encontrados quando o produto é colocado em campo - implica na necessidade de uma melhor validação, não de uma melhor verificação. TDD - usar testes para verificar o produto em relação aos requisitos - simplesmente não é relevante para encontrar esses bugs.
Pete Kirkham

6

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.


@AndresF. um dos problemas que encontrei ao rastrear essas citações é o que Bossavit descreveu como o problema da "agulha no palheiro" no livro ao qual você vinculou. Citar um livro é uma grande ofuscação - mesmo que ainda esteja impresso quando você vai ler a citação, você tem algumas centenas de páginas para ler procurando a pequena pepita que sustenta a afirmação do autor que o cita.

3

É apenas uma lógica simples.

Erro detectado nas especificações.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Como você pode ver mais tarde, quando o erro é detectado, mais pessoas estão envolvidas, mais trabalho precisa ser refeito e, em qualquer ambiente "normal", a papelada e a burocracia aumentam exponencialmente quando você pressiona o UAT.

Tudo isso sem incluir os custos em que uma empresa pode incorrer devido a um erro no software de produção (vendas perdidas, excesso de pedidos, hackers de clientes etc. etc.)

Eu não acho que alguém tenha conseguido escrever um sistema não trivial que nunca teve bugs na produção, mas tudo o que você pode fazer para detectar bugs cedo economizará tempo e esforço a longo prazo. Revisões de especificações, revisões de código, testes de unidade extensivos, uso de codificadores diferentes para escrever os testes etc. etc. são todos métodos comprovados para detectar bugs mais cedo.


2
Isso cobre apenas um caso: erro detectado nas especificações, ou seja, um erro que é introduzido no início. Porém, erros podem ser introduzidos em todas as etapas do desenvolvimento (incluindo a correção de erros pós-implantação) e a correção desses erros será consideravelmente mais fácil, pois provavelmente influenciará uma parte menor do sistema.
precisa saber é o seguinte

2
Mas o problema é que as correções de bugs podem ter efeitos colaterais inesperados, portanto, a menos que você possa garantir absolutamente que a correção afetará apenas um subconjunto de componentes em particular, você poderá refazer o SIT UAT etc. mudança.
James Anderson

2
Ainda não estou convencido de que isso mostre que os bugs sempre serão mais caros de corrigir quando descobertos tarde. Eu diria que um bug fica mais caro para corrigir com o tempo decorrido após a sua introdução . Ou seja, um bug introduzido tardiamente, descoberto logo depois e corrigido, é mais barato que um bug introduzido muito cedo e descoberto cedo (mas com um atraso maior que no primeiro caso). Pelo menos eu poderia imaginar que é assim que funciona.
precisa saber é o seguinte

@KonradRudolph Você poderia elaborar? Este post é basicamente o meu entendimento também, e não estou vendo por que o tempo importaria, mas a fase não. Para mim, a medida de tempo em um projeto é sua fase atual (e às vezes sua iteração de timebox para passar por todas as fases). Não vejo a diferença entre o trabalho realizado no dia 3 do design detalhado e no dia 300 - o produto de trabalho do design detalhado não foi usado para fazer outros produtos de trabalho, portanto, um defeito injetado no design detalhado existe apenas em um local e apenas requer uma mudança lá. Não vejo como a passagem dos dias importa.
Thomas Owens

3
@ Thomas Estou apenas levantando a hipótese. Mas o tempo é importante, porque a maioria dos trechos de código ou recursos de especificação introduzidos influenciará mais componentes com o passar do tempo, a menos que sejam altamente especializados e nada mais dependa deles, direta ou indiretamente. Portanto, um bug que existe há muito tempo, independentemente da fase em que foi introduzido, potencialmente influenciará muitas partes do sistema e sua remoção exige a garantia de que nenhum outro componente seja quebrado por esse processo.
9289 Konrad Rudolph

2

Eu acredito que isso é, e sempre foi, sobre gerenciamento de riscos e economia. Qual é o custo de reduzir o número de defeitos versus o valor presente do impacto de defeitos futuros. A trajetória do pássaro amarelo estar um pouco fora do Angry Birds não equivale à trajetória de um míssil de cruzeiro Tomahawk estar fora. Os desenvolvedores de software em qualquer projeto não podem tomar decisões com base nessa tabela. Nesse sentido, nada muda.

A maneira como acho que isso tende a funcionar é via feedback, erros caros no campo fazem as empresas restringirem seus processos de qualidade, enquanto nenhuma reclamação do campo faz com que as empresas o relaxem. Assim, com o tempo, as empresas de desenvolvimento de software tenderão a convergir ou oscilar em torno de algo que funcione para elas (+/-). O código completo pode influenciar alguns valores iniciais ou pode puxar as empresas levemente de uma maneira ou de outra. Uma empresa que gasta muito esforço na remoção de defeitos que ninguém notaria provavelmente perderá negócios para um concorrente que tem uma abordagem mais otimizada. Por outro lado, uma empresa que libera produtos de buggy também sai do negócio.

Alguns artigos relevantes de uma pesquisa rápida (leia os artigos completos, faça mais pesquisas e forme sua própria opinião):

Uma revisão sistemática da literatura sobre pesquisa de custo de qualidade de software (2011)

"Embora a comunidade tenha desenvolvido um bom entendimento da estrutura do domínio de pesquisa, a validação empírica costuma faltar. Apenas cerca de um terço dos artigos analisados ​​apresenta um estudo de caso ou resultados empíricos mais abrangentes. Isso parece ser insuficiente para a pesquisa de custo de qualidade de software , que depende fortemente de dados quantitativos para gerar novas descobertas. Portanto, há uma necessidade de novas abordagens para coletar dados de custo de qualidade, além de uma cooperação mais forte entre a indústria e a pesquisa para disponibilizar esses dados ".

Avaliando o custo da qualidade do software (1998)

"Finalmente, vimos que é importante monitorar os custos de conformidade e não conformidade de software, para que as políticas de conformidade possam ser ajustadas para reduzir os custos totais de qualidade de software".

O comportamento de custo de defeitos de software (2004)

Resumo ... "A pesquisa atual tenta atualizar nosso conhecimento da maneira como os defeitos e as despesas para corrigi-los (ou alternativamente, deixando-os não corrigidos) influenciam o custo final do software" ... "defeitos não corrigidos tornam-se exponencialmente mais caros com cada fase em que não estão resolvidos "

Cobertura de teste e defeitos pós-verificação: um estudo de caso múltiplo (2009)

"Também descobrimos que o esforço de teste aumenta exponencialmente com a cobertura de teste, mas a redução nos problemas de campo aumenta linearmente com a cobertura de teste. Isso sugere que, para a maioria dos projetos, é provável que os níveis ideais de cobertura sejam bem inferiores a 100%".

Faça a ponte entre o processo de teste de software e o valor comercial: um estudo de caso (2009)


0

Não consigo responder à sua primeira parte da pergunta, pois simplesmente não verifiquei. Mas posso formular uma resposta para sua segunda pergunta e talvez sugerir uma possível resposta para a primeira.

Não é necessário dizer que alguns fatores mais importantes no custo de correção de um bug, exceto as ferramentas de desenvolvimento intrinsecamente difíceis de usar, são a complexidade intrínseca do produto e o quão bem o usuário pode entender esse produto.

Focando um segundo no código, sob a suposição de que o código é tipicamente escrito e mantido por desenvolvedores capazes de lidar com as complexidades intrínsecas de seu código (o que pode não ser totalmente verdadeiro e pode merecer seu próprio debate), eu ousaria sugerir que: importância crucial na manutenção e, portanto, na correção de bugs, é a capacidade dos mantenedores de entender o referido código.

A capacidade de entender o código é bastante aprimorada pelo uso de ferramentas comprovadas de engenharia de software que, infelizmente, são na maioria das vezes usadas de maneira inadequada ou inadequada. Usando o nível certo de abstração, a modularidade, o aprimoramento da coesão do módulo e a redução do acoplamento do módulo são ferramentas críticas para lidar com a complexidade que precisam de uso adequado. Codificação para interfaces, ou, no POO, evitando o uso excessivo de herança sobre composição, empacotando por recurso, são algumas das técnicas que geralmente recebem atenção insuficiente na codificação.

Acredito que as realidades da concorrência no setor impõem uma força negativa ao emprego de métodos de melhoria da qualidade no desenvolvimento de software, mantendo baixa a qualidade intrínseca do software como uma medida de sucesso contínuo.

Consequentemente, acredito que, na indústria, o software tende a sofrer mais com os custos de correção de erros, à medida que cresce. Nesses produtos, os bugs se tornam mais difíceis de corrigir com o tempo, porque o sistema fica mais difícil de entender à medida que cresce. As preocupações apresentadas por cada recurso são excessivamente acopladas a outras preocupações, dificultando a compreensão. Ou, o nível certo de abstração não foi empregado, dificultando ao mantenedor formular um modelo adequado do sistema e raciocinar sobre ele. A falta de documentação certamente não ajuda.

Há exceções. Tenho certeza de que o Google não está funcionando no seu ritmo sem algumas práticas sólidas confirmadas por desenvolvedores estelares. E outros provavelmente estão na mesma situação. Mas para a maioria do software, eu não ficaria surpreso se os dados fez de fato confirmam a alegação de código completo .


Eu mantenho minha resposta mesmo com a classificação negativa. Recentemente, entrevistei um candidato que mantém a ferramenta de banco on-line de um dos principais bancos. Durante o bate-papo casual, ele sugeriu não usá-lo, por causa da reutilização pesada de copiar e colar e de uma estrutura de má qualidade. Em um trabalho anterior, eu era desenvolvedor de uma empresa que escrevia ferramentas de análise para bancos como Lehman, MS, UBS e tínhamos que atuar como especialistas em domínio, descobrindo a próxima coisa a ser implementada na documentação mais escassa. Mesmo em desacordo com as práticas específicas, a mensagem geral re: industry é verdadeira.
Mihai Danila

-1

Outra resposta! Desta vez, para abordar a questão do título "A morhtodoligia de software depende de dados defeituosos".

A resposta real é "não há dados". Como não há um grande corpo confiável de dados em projetos de software, existem defeitos, sucessos no mercado, etc.

Todas as tentativas de reunir esses dados foram subfinanciadas, estatisticamente defeituosas ou, portanto, específicas para um projeto específico, das quais não é possível derivar conclusões gerais.

Além disso, acho que nunca haverá, o processo de desenvolvimento de software é muito subjetivo e escorregadio para uma medição rigorosa. As organizações mais bem posicionadas para reunir esses dados (as grandes casas de software e os integradores de sistemas) sabem em seu coração que quaisquer números obtidos a partir de seu desempenho seriam profundamente embaraçosos.

As únicas organizações que publicam números sobre o custo e o sucesso de projetos de software
são departamentos governamentais e, somente então, porque precisam fazê-lo; sim, esses números são profundamente embaraçosos, não importa o quanto eles massageiem os números.

Portanto, em conclusão, todos os estudos de software são necessariamente puramente subjetivos, porque não há dados reais nos quais basear uma conclusão objetiva.


1
Não, eu não compro isso. Primeiro, não é de dados, embora você pode estar certo de que ele é falho. Mas isso requer uma crítica individual de cada conjunto de dados, não uma demissão geral. E desconfio profundamente da afirmação de que nunca haverá dados e de razões como "é muito subjetivo". Isso é essencialmente um argumento por falta de imaginação . Não pretendo que reunir estatísticas confiáveis ​​aqui seja fácil, mas afirmo que é totalmente viável. Em outros campos, sistemas muito mais complicados são analisados ​​com sucesso.
Konrad Rudolph

@Konrad - use algo básico e simples como "contagem de defeitos", algumas lojas contam falhas de teste de unidade, algumas lojas não começam a rastrear defeitos até o UAT, algumas lojas apenas rastreiam defeitos no código, algumas lojas incluem documentação, configuração e scripts de implantação em seu processo de rastreamento de defeitos. Ter a cor de fundo incorreta conta como um defeito? Alguns projetos o rastreiam como um defeito, outros o ignoram.
James Anderson

Todos esses são problemas paroquiais - isto é, solucionáveis ​​-. Eles não impõem restrições fundamentais ao que é possível, apenas adicionam dificuldades que exigem solução.
Konrad Rudolph
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.