|
|
Um Engenheiro treinado pelos métodos PSP aprende a relacionar produtividade e a qualidade. Os Engenheiros reconhecem que não faz sentido comparar a produtividade de um processo de programação que não encontrou defeitos no teste com outro que tem muitos. Quando Engenheiros cometem muito código defeituoso, o projeto que usa este código provavelmente gastará muitas horas de integração e teste de sistema. Do contrário, uma vez que Engenheiros aprendem a produzir programas com pouco ou sem defeitos, seus projetos serão provavelmente mais produtivos.
LOCPerHrImp.jpg A figura ao lado LOC/Hour vs. Total Defects/KLOC (Linhas de
Código por
hora X Total de feitos por Mil Linhas de Código) mostra que a proporção de
linhas de
códigos por hora realizada por 104 Engenheiros no primeiro programa PSP. A
proporção
tendeu a ficar menor para Engenheiros que apresentaram muito defeitos. Destes
dados,
percebe-se que o mais alto índice de defeito está associado com a menor
produtividade.
Note, contudo, que o menor índice de defeito por si mesmo não garante alta
produtividade. É interessante notar que este mesmo relacionamento é ainda mais
citado
com o programa 10: aqueles que injetaram a maioria dos defeitos tiveram a mais
baixa taxa
de desenvolvimento de LOC/hour(linhas de código por hora).
A figura acima que trata do aperfeiçoamento de Linhas de Código por hora
(LOC/Hour)
relacionada com Linhas de Código por hora (LOC/hour) no programa 1 mostra a
porcentagem
de aprimoramento LOC por hora para os mesmo 104 Engenheiros do gráfico anterior.
O eixo y
mostra a porcentagem de aperfeiçoamento do programa 1 para o programa 10. O eixo
x mostra
a taxa de LOC por hora que cada Engenheiro realizou com o programa 1. Note que
estes
Engenheiros que tinham a mais alta taxa no programa 1 tenderam a ter taxa de
aperfeiçoamento negativo.
Enquanto na média este grupo aperfeiçoou em 20,84%, é claro também que uma
alta
porcentagem daqueles Engenheiros que tiveram alta taxa de LOC por hora no
programa 1
tiveram menores taxas para o programa 10. Isto sugere duas conclusões:
 |
Desde que muitos Engenheiros inexperientes tenham inicialmente as maiores taxas de erro e menores taxas de LOC por hora, as disciplinas do PSP mais provavelmente incrementarão as taxas de LOC por hora deles. Eles verão então o PSP como uma ajuda para eles trabalharem mais rápido. Portanto, eles irão provavelmente continuar a usar os métodos PSP. Alguns Engenheiros experientes começam com menos taxas de defeitos e altas taxas de LOC por hora. |
|
Quando estes Engenheiros adicionam as tarefas de planejamento e avaliação do PSP, seguindo os padrões de código definido, revendo os programas deles, e pistas e relatórios, a taxa de LOC por hora desses Engenheiros freqüentemente irá diminuir. Estes Engenheiros verão o PSP como um método que diminui o desempenho deles. |
Aqueles que não apreciam os benefícios destas práticas de planejamento e gerenciamento de qualidade provavelmente pararão de usar o PSP.
É importante reconhecer que o PSP adiciona muitas tarefas importantes que muitos Engenheiros normalmente não fazem. E assim não é surpreendente que quando as tarefas adicionadas são incluídas alguns Engenheiros terminarão com taxas menores de LOC por hora. Escrever programas do tamanho de módulos é um pouco parecido como correr uma milha em 4 minutos. Quando Engenheiros podem produzir 40 ou mais LOC por hora não há mais o que melhorar. Isto focaliza a maximização na taxa de pessoal do Engenheiro, portanto, levam uma sub-otimização. Enquanto os métodos de planejamento e gerenciamento PSP levam um tempo adicional, são justamente estes métodos que tornam os Engenheiros de Software membros efetivos de times e organizações. Gastando o tempo para seguir métodos de disciplina pessoal, elas irão ajudar a melhorar a performance total da organização.
