Personal software process

Foram assinalados vários problemas nesta página ou se(c)ção: As fontes não são citadas no corpo do artigo, o que compromente a verificabilidade. Contém referências que necessitam de formatação. Não tem imagens.

Personal Software Process (PSP) é um processo de desenvolvimento de software projetado para ser utilizado por engenheiros de software para a elaboração de projetos individuais. O PSP foi desenvolvido por Watts Humphrey e está descrito no seu livro "A Discipline for Software Engineering" (Uma disciplina para Engenharia de Software) de 1995. O PSP foi desenvolvido para orientar o planejamento e desenvolvimento de módulos de software ou pequenos programas, mas pode ser adaptado para outras tarefas pessoais.

Sendo um sub-conjunto do CMM (Capability Maturity Model), o PSP tem como filosofia a revisão contínua em cada estágio do ciclo de desenvolvimento. Enquanto o CMM é focado na melhoria da capacidade organizacional, o foco do PSP é o engenheiro individual.

Os objetivos principais do PSP são:

• Melhorar a estimativa de prazo e esforço para o desenvolvimento de um módulo de software ou programa;
• Melhorar o planejamento e o acompanhamento de cronogramas;
• Evitar o excesso de compromissos;
• Criar um comprometimento pessoal com a qualidade e com a melhoria contínua do processo;

Naturalmente, a melhoria da capacidade de organização do indivíduo favorece a melhoria da capacidade organizacional como um todo.

O PSP tem como objetivo prover engenheiros de software métodos bem definidos para melhoria individual do processo de desenvolvimento de software. O PSP auxilia engenheiros de software em:

• Melhorar sua capacidade de estimativa e planejamento;
• Assumir compromissos que possam cumprir;
• Gerenciar a qualidade dos seus projetos;
• Reduzir o número de defeitos no seu trabalho.

O objetivo do PSP é auxiliar aos desenvolvedores a produzir software sem defeitos, com qualidade, dentro do prazo. Por este motivo, ele é considerado o seis sigma do desenvolvimento de software.

O processo de treinamento do PSP tem metodologia evolutiva , onde o engenheiro de software aprende a integrar o PSP em seus projetos do primeiro nível o -PSP0- e segue progredindo o processo até o último nível , o PSP2.1. Cada nível possui passos detalhados , checklists e modelos a serem seguidos para progredir nos níveis do PSP.   Watts Humphrey incentiva os engenheiros de software a personalizar e melhorar o modelo do PSP para adquirirem melhores métricas sobre seus pontos fracos e seus pontos fortes.

Processos

Cada nível do PSP tem seus requisitos:

PSP0, PSP0.1 : Introduz disciplina e metrificação de seus processos

PSP0 possui 3 etapas: Planejamento , Desenvolvimento (design, codificação , compilação e testes) . Uma base é estabelecida na medição do processo atual: tempo gasto desenvolvendo, falhas  e correção de falhas. Os engenheiros devem garantir que todos os dados do projeto foram devidamente registrados e analisados.

PSP0.1 avança o processo anterior adicionando um padrão de codificação, medição de tamanho e desenvolvimento de um plano pessoal de melhoria de projeto (PIP), no PIP o engenheiro registra as ideias para melhorar sua próprias habilidades de desenvolvimento.

PSP1 , PSP 1.1 (introduz estimativa e planejamento) Com base nos dados da linha de base coletando no PSP0 e no PSP0.1 , o engenheiro estima o quão grande será um novo projeto e prepara um relatório de teste do mesmo(PSP1).

Com base nos dados de antigos projetos, esses dados são usados para estimar o tempo necessário para a entrega. Cada novo projeto irá registrar o tempo gasto para seu desenvolvimento , assim melhorando continuamente a base de dados analiticos .

Estas informações serão usadas em projetos futuros para mensurar e planejar estimativas(PSP1.1).

PSP2, PSP2.1( Introduz qualidade , gerenciamento e design)

PSP2 adiciona duas novas fases: análise de design e revisão de código. Prevenção de defeitos e remoção de defeitos são o foco no PSP2. Os Engenheiros aprendem a avaliar e melhorar os processos medido o tempo para determinadas tarefas e o número de defeitos que os engenheiros encontram e removem em cada fase de desenvolvimento.

   Os Engenheiros constroem checklists de verificação , para revisões de design e revisões de código.

PSP2.1 introduz técnicas de especificação e  análise de projeto .

PSP3 é um nível legado substituído pelo TSP .

Um dos principais aspectos do PSP é o uso de dados para a análise e melhorar a performance dos processos. A coleta de dados do PSP tem quatro métodos principais, Scripts, Medidas, Padrões, Formulários.

Os Scripts fornecem orientação avançada para seguir as etapas do processo e fornecem uma estrutura (framework) para aplicar as medidas do PSP.

• Tamanho - Medida de tamanho para determinado parte de um produto, como por exemplo linhas de código.
• Esforço: usualmente o tempo necessário para concluir uma tarefa, normalmente medido em minutos.
• Qualidade: A quantidade e o número de defeitos no produto.
• Cronograma: uma medida da progressão do projeto, rastreada em relação às datas planejadas e as datas reais da conclusão das tarefas.

A aplicação correta dos padrões ao processo pode garantir que os dados sejam precisos e consistentes. Os dados são registrados em formulários, normalmente usando uma ferramenta de software PSP. O SEI desenvolveu uma ferramenta para uso do PSP e também existem softwares livres disponíveis, como por exemplo o Process dashboard. Os dados principais coletados nas ferramentas PSP são tempo, defeitos e tamanho da tarefa - o tempo de desenvolvimento de cada fase; quando e o onde defeitos encontrados e corrigidos. Os engenheiros de software podem fazer o uso de várias outras medidas derivadas das medidas citadas acima para melhor entender e melhorar seu desempenho pessoal.

• Algumas medidas derivadas são:
• Precisão de estimativa (tamanho/tempo)
• Intervalos de previsão (tamanho/tempo)
• Tempo de planejamento
• Planejamento de defeitos no decorrer do processo.
• Planejamento de correção de defeitos.
• Porcentagem de reuso.
• Rendimento do processo
• Taxas de revisão
• Número de defeitos por fase do produto
• Número de remoção de defeitos por fase do produto

O registro de tempo, defeitos e dados é uma parte essencial do planejamento e acompanhamento de projetos com PSP, pois os dados coletados são usados ​​para melhorar a precisão das estimativas.

           O PSP usa o método de PROxy-Based Estimation (PROBE) para melhorar as habilidades de estimativa do engenheiro para um planejamento de projeto mais preciso. Para acompanhamento de projetos, o PSP usa o earned value method (EVM). O PSP também usa técnicas estatísticas, como correlação, regressão linear e desvio padrão, para converter dados em informações úteis para melhorar a estimativa, o planejamento .

Na prática, as habilidades de PSP são usadas em um ambiente de equipe de team software process (TSP). As equipes de TSP consistem em desenvolvedores treinados pela PSP que se voluntariam para áreas de responsabilidade do projeto, portanto, o projeto é gerenciado pela própria equipe. Usando dados pessoais recolhidos usando suas habilidades de PSP; a equipe faz os planos, as estimativas e controla a qualidade.

           O uso de métodos de processo PSP pode ajudar as equipes TSP a cumprir seus compromissos de cronograma e produzir software de alta qualidade. Por exemplo, de acordo com a pesquisa de Watts Humphrey, um terço de todos os projetos de software falham, mas um estudo da SEI sobre 20 projetos TSP em 13 organizações diferentes descobriu que as equipes TSP perderam suas metas por uma média de apenas seis por cento.

           O cumprimento com sucesso dos compromissos do cronograma pode ser atribuído ao uso de dados coletados para fazer estimativas mais precisas, portanto os projetos são baseados em planos realistas - e usando métodos de qualidade do PSP, eles produzem software com baixo nível de defeitos, o que reduz o tempo gasto na remoção de defeitos como testes de integração e aceitação.

Software de alta qualidade é o maior objetivo do PSP e a qualidade é medida em termos de defeitos. Para o PSP, um processo de qualidade deve produzir software com baixo índice defeito que atenda às necessidades do usuário.

A estrutura de fase do PSP permite que os desenvolvedores do PSP detectem defeitos antecipadamente. Ao detectar defeitos precocemente, o PSP pode reduzir o tempo gasto em fases posteriores, como o teste.

A teoria da PSP é a de que é mais econômico e eficaz remover defeitos o mais rápido possível de onde e quando foram encontrados, para que os engenheiros de software sejam encorajados a conduzir avaliações pessoais para cada fase de desenvolvimento. Portanto, a estrutura da fase do PSP inclui duas fases de revisão:

• Revisão do projeto
• Revisão de código

Para fazer uma revisão eficaz, você precisa seguir um processo de revisão estruturada. O PSP recomenda o uso de listas de verificação para ajudar os desenvolvedores a seguir consistentemente um procedimento ordenado.

O PSP segue a premissa de que quando as pessoas cometem erros, seus erros geralmente são previsíveis, então os desenvolvedores do PSP podem personalizar suas listas de verificação para direcionar seus próprios erros comuns. Espera-se também que os engenheiros de software concluam as propostas de melhoria de processos, para identificar áreas de fraqueza em seu desempenho atual que devem ser alvo de melhorias. Os dados históricos do projeto, que expõem onde o tempo é gasto e os defeitos introduzidos, ajudam os desenvolvedores a identificar áreas a serem aprimoradas.

Espera-se também que os desenvolvedores do PSP conduzam avaliações pessoais antes que o seu trabalho seja submetido a uma revisão.

• Capability Maturity Model Integration (CMMI)
• Carnegie Mellon University
• Proxy-based estimating (PROBE)
•  Software Engineering Institute  (SEI)
•  Team Software Process (TSP)
•  Watts Humphrey
•   Agile Software Development

• Artigo Using a defined and measured Personal Software Process. by Watts S. Humphrey, publicado em IEEE Software, maio de 1996, páginas 77-88.
• Watts S. Humphrey^[1] "Delivering Successful Projects With Challenges of New Teams" por Mukesh Jain (http://www.sei.cmu.edu/tspsymposium/2009/2006/deliver.pdf), Setembro de 2006 "The Personal Software Process (PSP) Body of Knowledge" artigo de “the Software Engineering Institute at Carnegie Mellon”.

• The Personal Software Process (PSP) Body of Knowledge - Um artigo que aborda o conhecimento básico e os princípios que estão por trás do PSP, e que descreve suas práticas e métodos básicos.
• Iniciativa "Software Process Dashboard Project".