Taxa de defeito de software incorporado

Question

Que taxa de defeito posso esperar em uma base de código C ++ que seja gravada para um processador incorporado (DSP), uma vez que não houve testes de unidade, revisões de código, análise de código estático e que compilar o projeto gera cerca de 1500 avisos. 5 Defeitos/100 linhas de código são uma estimativa razoável?

Answer 1

Apesar do meu ceticismo com a validade de qualquer estimativa neste caso, encontrei algumas estatísticas que podem ser relevantes.

Dentro Este artigo, o autor cita figuras de um "um grande corpo de estudos empíricos", publicado em Avaliações de software, benchmarks e práticas recomendadas (Jones, 2000). No Sie CMM Nível 1, que soa como o nível deste código, pode -se esperar uma taxa de defeito de 0,75 por ponto de função. Vou deixar para você determinar como Pontos de função e LOC pode se relacionar em seu código - você provavelmente precisará de um Ferramenta de métricas para realizar essa análise.

Steve McConnell no código completo cita um estudo de 11 projetos desenvolvidos pela mesma equipe, 5 sem análises de código, 6 com revisões de código. A taxa de defeito para o código não revisado foi de 4,5 por 100 LOC e, para a revisão, foi 0,82. Portanto, nessa base, sua estimativa parece justa na ausência de qualquer outra informação. No entanto, eu tenho que assumir um nível de profissionalismo entre essa equipe (apenas pelo fato de que eles sentiam a necessidade de realizar o estudo) e que teriam pelo menos atendido aos avisos; Sua taxa de defeito pode ser muito mais alto.

O ponto sobre avisos é que alguns são benignos e outros são erros (ou seja, resultará em comportamento indesejado do software), se você os ignorar na suposição de que todos são benignos, você apresentará erros. Além disso, alguns vão vir a ser Os erros em manutenção quando outras condições mudam, mas se você já optou por aceitar um aviso, não tem defesa contra a introdução de tais erros.

Answer 2

Sua pergunta é "5 defeitos/100 linhas de código uma estimativa razoável?" Essa pergunta é extremamente difícil de responder e é altamente dependente da base de código e da complexidade do código.

Você também mencionou em um comentário "para mostrar à gerência que provavelmente existem muitos bugs na base de código" - isso é ótimo, parabéns, bem.

Para abrir os olhos figurativos da gerência, eu sugeriria pelo menos uma abordagem de três frentes:

• Pegue avisos específicos do compilador e mostre como alguns deles podem causar comportamento indefinido / desastroso. Nem todos os avisos serão tão pesados. Por exemplo, se você tem alguém usando um ponteiro não inicializado, isso é ouro puro. Se você tem alguém preenchendo um valor de 16 bits não assinado em um valor de 8 bits não assinado e pode ser mostrado que o valor de 16 bits sempre será <= 255, que não se ajudará a tornar seu caso com a mesma força.
• Execute uma ferramenta de análise estática. PC-Lint (ou FlexElint) é barato e oferece um bom "estrondo para o dinheiro". Certamente, ele certamente pegará as coisas que o compilador não fará, e também pode ser encontrado nas unidades de tradução (fie tudo juntos, mesmo com 2 ou mais passes) e encontrar bugs mais sutis. Novamente, use alguns deles como indicações.
• Execute uma ferramenta que fornecerá outras métricas sobre a complexidade do código, outra fonte de bugs. Eu recomendo M Metrics Standard de Recurso de M Squared (RSM) O que fornecerá mais informações e métricas (incluindo a complexidade do código) do que você poderia esperar. Quando você diz à gerência isso Uma pontuação de complexidade acima de 50 é "basicamente não testável" E você tem uma pontuação de 200 em uma rotina, que deve abrir alguns olhos.

Outro ponto: preciso de compiladores limpos em meus grupos e também limpar a saída de fiapos. Geralmente, isso pode ser realizado apenas escrevendo um bom código, mas ocasionalmente os avisos do compilador / fiapo precisam ser ajustados para acalmar a ferramenta para coisas que não são problemas (use criteriosamente).

Mas o ponto importante que quero fazer é o seguinte: Tenha muito cuidado ao entrar e consertar o compilador e avisos de fiapos. É um objetivo admirável, mas você também pode interromper inadvertidamente o código de trabalho e/ou descobrir um comportamento indefinido que acidentalmente trabalhou no código "quebrado". Sim, isso realmente acontece. Então pise com cuidado.

Por fim, se você já tiver um conjunto sólido de testes, isso ajudará você a determinar se você quebrar algo acidentalmente enquanto refatora.

Boa sorte!

Answer 3

Dê uma olhada na qualidade do código. Isso lhe daria rapidamente uma indicação da quantidade de problemas escondidos na fonte. Se a fonte for feia e demorar muito para entender, haverá muitos bugs no código.

Código bem estruturado com estilo consistente e isso é fácil de entender, conterá menos problemas. Código mostra quanto esforço e pensamento entraram nele.

Meu palpite é que, se a fonte contém que muitos avisos haverá muitos bugs escondidos no código.

Answer 4

Isso também depende de quem escreveu o código (nível de experiência) e qual o tamanho da base de código.

Eu trataria todos os avisos como erros.

Quantos erros você recebe quando executa uma ferramenta de análise estática no código?

EDITAR

Execute o CCCC e verifique a complexidade cíclica do McCabe. Deve dizer o quão complexo é o código.

http://sourceforge.net/projects/cccc/

Execute outras ferramentas de análise estática.

Answer 5

Se você deseja obter uma estimativa do número de defeitos, a maneira usual de estimativa estatística é submarcar os dados. Eu escolheria três sub-rotinas de tamanho médio aleatoriamente e as verificava cuidadosamente quanto a bugs (eliminar os avisos do compilador, executar uma ferramenta de análise estática, etc.). Se você encontrar três bugs em 100 linhas totais de código selecionadas aleatoriamente, parece razoável que uma densidade semelhante de bugs esteja no restante do código.

O problema mencionado aqui de introduzir novos bugs é uma questão importante, mas você não precisa verificar o código modificado de volta na filial de produção para executar este teste. Eu sugeriria um conjunto completo de testes de unidade antes de modificar quaisquer sub -rotinas e limpar todo o código seguido de testes muito completos do sistema antes de lançar um novo código para a produção.

Answer 6

Se você deseja demonstrar os benefícios dos testes de unidade, revisões de código, ferramentas de análise estática, sugiro fazer um estudo piloto.

Faça alguns testes de unidade, revisões de código e execute ferramentas de análise estática em uma parte do código. Mostre a gerenciamento de quantos bugs você encontra usando esses métodos. Felizmente, os resultados falam por si.

Answer 7

O artigo a seguir possui alguns números baseados em projetos da vida real aos quais a análise estática foi aplicada a: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html

É claro que os critérios pelos quais uma anomalia é contada pode afetar drasticamente os resultados, levando à grande variação nas figuras mostradas na Tabela 1. Nesta tabela, o número de anomalias por mil linhas de código para C varia de 500 (!) a cerca de 10 (gerado automaticamente).