|
|
Alguns engenheiros de software sabem quanto defeito eles produzem. Não só os defeitos que são achados em integração e teste de sistema, mas todos os defeitos injetados, incluindo aqueles achados no papel, compilando, na checagem da sintaxe, na unidade de teste e em todo o resto de ciclo de vida do software. Se você só olha os defeitos no produto final, você não poderá provavelmente fazer uma grande melhoria. Estaria como tentar consertar um telhado mal vedado, estudando as possas no chão. Até que adquira a fonte do problema, você gastará a maioria do seu tempo arrumando a bagunça.
Engenheiros experientes geralmente injetam 100 ou mais defeitos /KLOC. No começo do curso de PSP, o defeitos/KLOC mediano era 131.3. Muitos engenheiros sem experiência têm taxas muito mais altas, e de maneira interessante, assim fazem engenheiros de dez ou mais anos de experiência. Não há uma correlação forte entre níveis de experiência e taxas de defeitos. Até mesmo com só 100 defeitos/KLOC, um sistema de 1.000,000 de LOC terá 100,000 defeitos injetados. Enquanto a maioria destes será encontrado em compilação e teste de unidade, uma porcentagem irá aparecer na integração, teste de sistema e usuário fim.
Se você estava trabalhando em um tal sistema, e decidiu fazer tudo que você poderia pensar para administrar defeitos, o que você faria? Se houvessem poucos defeitos, não faria muita diferença o que você decidiu. Com 100,000 defeitos porém, a situação é bastante diferente. Assuma como o PSP mostra os dados, que o compilador acha aproximadamente a metade dos defeitos a custo desprezível. Também assuma que você possa achar aproximadamente metade do resto dos defeitos em teste de unidade, novamente a custo modesto. Isso deixa 25.000 defeitos que podem ser achados em tempo de integração e teste de sistema. Mesmo que a maioria das organizações tomem de 10 a 40 horas de programador, isso levará aproximadamente 250,000 ou mais horas de programação. Isto é 125 anos de programação.
Quando você enfrenta um trabalho que pode levar 125 anos de empenho, você iria provavelmente querer recorrer. Um modo bom seria obter e estudar dados de defeitos. Quantos defeitos injetam os engenheiros? Onde eles os injetam, e o que fazem eles para achar e consertar? Quando eles usaram o PSP para medir e localizar os seus defeitos, 43 engenheiros e estudantes reduziram os números comuns que injetavam em 66.9%. Eles também, aprenderam a achar e consertar seus defeitos mais rapidamente de três a dez vezes. Usando métodos de PSP, os defeitos eram encontrados mais cedo e resolvidos, tanto que eles reduziram o número de defeitos que eles acharam em teste por 76.5%.
A pessoa poderia discutir que uma redução de 76.5% em defeitos de teste de uma unidade, necessariamente não significa que o programa acabado teve menos defeitos. Sem teste de sistema e usuários exaustivo, é claro que não há nenhum modo para ser certo. Porém, é razoável notar testando-se como um filtro, algum por cento dos defeitos que entram em teste é achado e o remanescente é perdido. Assim se você pusesse um produto com duas vezes mais defeitos em teste, você esperaria achar duas vezes mais. Semelhantemente, você também perderia duas vezes mais. Isto sugere que, o números de defeitos achados em teste é um bom indicador do número que permanece. Não há contudo, qualquer dados de PSP neste sentido, mas uma referência informa uma correlação de 0.91 entre o número de defeitos achados em teste e aqueles achados por usuários finais. Novamente, dados de PSP podem lhe ajudar a entender os defeitos que você injeta, por que você os injeta, e o que custa achá-los e consertá-los. Desde então, existe uma divergência entre indivíduos, porém, você poderia considerar juntando seus próprios dados e vendo você mesmo.
