Processo de Software pessoal (pSp)

processo de Software pessoal (pSp)
Todo desenvolvedor utiliza algum processo para construir software. Esse processo pode ser nebuloso ou específico; pode mudar diariamente; não ser eficiente, efetivo ou bem-sucedido; porém, um "processo" realmente existe. Watts Humphrey [Hum97] sugere que a fim de modificar um processo pessoal não efetivo, um indivíduo deve passar por quatro fases, cada uma exigindo treinamento e orquestração cuidadosa. O Processo de Software Pessoal (sigla PSP, Personal Soft- ware Process) enfatiza a medição pessoal, tanto do artefato de software gerado quanto da qualidade resultante dele. Além disso, responsabiliza o profissional pelo planejamento de projetos (por exemplo, estimativa de custos e cronograma) e lhe dá poder para controlar a qualidade de todos os artefatos de software desenvolvidos. O modelo PSP define cinco atividades estruturais:

Planejamento. Essa atividade isola os requisitos e desenvolve as estimativas de porte e de recursos. Além disso, faz-se uma estimativa dos defeitos (o número de defeitos estimado para o trabalho). Registram-se todas as métricas em formulários ou planilhas. Finalmente, identificam-se as tarefas de desenvolvimento e faz-se um cronograma para o projeto.

Projeto de alto nível. Desenvolvem-se especificações externas para cada componente a ser construído e elabora-se um projeto de componentes. Quando há incerteza, constroem-se protótipos. Todos os problemas são registrados e localizados. Revisão de projeto de alto nível. Aplicam-se métodos de verificação formais (Capítulo 21) para revelar erros no projeto. Métricas são mantidas para todos os resultados de trabalho e tarefas importantes. Desenvolvimento. O projeto em nível de componentes é refinado e revisado. Código é gerado, revisado, compilado e testado. Métricas são mantidas para todos os resultados de trabalho e tarefas importantesAutópsia. Usando as medidas e métricas coletadas (trata-se de um volume de dados substancial que deve ser analisado estatisticamente), é determinada a eficácia do processo. Medidas e métricas devem guiar as mudanças no processo de modo a melhorar sua eficiência. O PSP enfatiza a necessidade de registrar e analisar tipos de erros cometidos, para que se possa elaborar estratégias para eliminá-los. WebRef Informações sobre a formação de equipes com alto desempenho empregando-se TSP e PSP podem ser obtidas em: www .sei .cmu . edu/tsp/ . AVISO Para formar uma equipe autodirigida, deve haver boa colaboração internamente e boa comunicação externamente. O PSP enfatiza a necessidade de identificar erros precocemente e, tão importante quanto, compreender os tipos de erros que provavelmente ocorrerão. Isso é obtido por meio de uma rigorosa atividade de avaliação em todos os artefatos de software gerados. O PSP representa uma abordagem disciplinada e baseada em métricas para a engenharia de software que pode causar um choque cultural em muitos profissionais. Entretanto, quando apresentado de forma apropriada aos engenheiros de software [Hum96], a melhoria resultante na produtividade da engenharia e na qualidade de software é significativa [Fer97]. Apesar disso, não foi adotado largamente pelo setor. Os motivos, infelizmente, têm mais a ver com a natureza humana e com a inércia organizacional do que com os pontos fortes e fracos da abordagem PSP. Esse processo é intelectualmente desafiador e exige um nível de comprometimento (por parte dos profissionais e de seus gerentes) que nem sempre é possível alcançar. O período de treinamento é relativamente longo e os custos de treinamento são altos. O nível de medição exigido é culturalmente difícil para muitos profissionais da área de software. O PSP pode ser utilizado como um processo de software eficaz no nível pessoal? A resposta é um inequívoco "sim". Porém, mesmo se não adotado em sua totalidade, muitos dos conceitos de aperfeiçoamento do processo pessoal que introduz são importantes e vale a pena aprendê-los.