Objetivando a melhoria na estimativa de prazo e melhor acompanhamento do aprendizado do profissional, o PSP (Personal Software Process) se mostrou com alguns elementos interessantes para este trabalho, o PSP foi desenvolvido por Humphrey (1996) com objetivo de melhorar o desempenho individual dos desenvol- vedores de software, como a capacidade de planejamento, acompanhamento e qua- lidade dos resultados. Ele tem como base o modelo CMM (Capability Maturity Model for Software), focado na melhoria da capacidade organizacional. Os principais objeti- vos do PSP são:
Melhorar a estimativa de prazo e esforço para o desenvolvimento de um módu- lo 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;
Para Humphrey (1997), os conceitos básicos do PSP podem ser utilizados como ferramenta de uso geral para gerenciar as atividades pessoais particulares ou profissionais, permitindo que os desenvolvedores de software, obtenham melhor de- sempenho na realização de suas atividades. Ainda de acordo com Humphrey (1996), as pessoas só assumem compromissos pessoais voluntariamente. Imposições não seriam compromissos, mas obrigações. Nesse sentido, cronogramas e planos corpo- rativos podem não serem vistos necessariamente como compromissos pessoais pe- los desenvolvedores, mesmo que esses desenvolvedores busquem constantemente estratégias para melhorarem seu desempenho profissional e também realçarem a produtividade, mas como um processo de auto-aprimoramento.
Pelo modelo PSP, existem quatro níveis de maturidade no processo de soft- ware: (i) Processo de Linha Básica Individual (Nível 0); (ii) Processo de Planejamen- to Individual (Nível 1); (iii) Gerenciamento Individual de Qualidade (Nível 2) e (iv)
49
Processo Cíclico Individual (Nível 3). A Figura 9 ilustra esses níveis.
No nível 0 são definidos os processos que serão utilizados para auxiliarem a administrar projetos, auxiliando pequenas equipes a se organizarem em seu traba- lho. Deste nível constam os elementos PSP 0 (Processo Corrente, Registro de Tem- po, Registro de Defeitos, Padrão de Tipos de Defeitos, estabelecimento de práticas de medida e alguns formatos de relatórios que constituirão uma baseline ou funda- ção sobre a qual será implantada a melhoria contínua do indivíduo) e PSP 0.1 (Pa- drão de Codificação, Medida de Tamanho, Process Improvement Proposal).
Figura 9: Níveis do PSP e seus elementos (HUMPHREY, 1996)
Sem uma definição das atividades que serão realizadas (nível 1), é difícil rea- lizar uma estimativa de tempo e de recursos necessários. Nesse contexto, Humprey (1996) define que o planejamento é o primeiro passo no PSP por três razões: (i) sem bons planos não se pode efetivamente gerenciar, (ii) planejamento é uma habilidade que será aprendida e aprimorada com a prática e (iii) habilidades em planejamento ajudarão a melhor realizar os trabalhos de software. Os elementos deste nível são PSP 1 (Estimativa de Testes, Relatório de Testes), que acrescenta práticas de pla- nejamento ao PSP 0, e PSP 1.1 (Planejamento das Tarefas e dos Cronogramas), cujo objetivo é (i) uma melhor compreensão da relação entre o tamanho dos pro- gramas e o tempo gasto no seu desenvolvimento, (ii) assumir compromissos com mais certeza de que serão cumpridos, (iii) organizar o trabalho e (iv) melhor acom- panhamento do status do desenvolvimento.
No nível 2 é avaliada a qualidade do software. Com os dados recolhidos, o engenheiro de software pode estabelecer checklists de revisão e fazer sua própria
50
avaliação da qualidade do processo. Os elementos deste nível são PSP 2 (Revisões de Código, Revisões de Projeto), sendo introduzidas (i) técnicas de inspeção e revi- são para auxiliar na detecção precoce de defeitos, (ii) a coleta e análise de dados dos defeitos da compilação e de testes encontrados em programas anteriores, sendo também possível criar listas de verificação mais ajustadas ao perfil de defeitos do programador e fazer avaliações da evolução de sua qualidade, e PSP 2.1 (Padrões de Projetos, ou Templates), que auxilia no estabelecimento de critérios de complete- za e de técnicas de verificação e consistência do projeto, especialmente importantes para verificar se as condições para iniciar a próxima fase de desenvolvimento estão satisfeitas.
No nível 3, é utilizado o modelo proposto por Boehm (1988), ou Modelo Espi- ral, onde se criam protótipos de cada uma dessas fases de desenvolvimento. Seu único elemento PSP 3 (Desenvolvimento Cíclico), introduz o conceito iterativo do desenvolvimento: o programa é subdivido em módulos que possam ser tratados convenientemente com o ferramental apresentado nos níveis inferiores do modelo.
Em cada iteração, concentra-se na verificação da qualidade dessa iteração e assume-se que as anteriores já estão garantidas ou verificadas. Se uma iteração anterior tem baixa qualidade, o teste será muito mais difícil e os benefícios do de- senvolvimento incremental serão perdidos. Testes de regressão são realizados para verificar se as condições de qualidade verificadas na iteração anterior não foram afe- tadas negativamente pela inclusão de novos módulos. No entanto, observa-se que o processo cíclico do PSP3 proporciona efetivamente um crescimento para grandes programas, somente se cada sucessivo incremento for de alta qualidade. Com isto, a melhoria contínua da qualidade de software não fica apenas voltada para o resultado final apresentado.
Diversos autores defendem o PSP. Bublitz (1999), por exemplo, justifica as- sim a utilização do PSP por engenheiros de software:
Um engenheiro de software deve conhecer ferramentas que o auxiliem em seu trabalho e o modelo PSP se adapta perfeitamente a estas necessida- des, possibilitando ao engenheiro de software criar uma estrutura de organi- zação das atividades e avaliação das mesmas, para verificar e avaliar seu desempenho e de sua equipe, gerando qualidade.
Para Montini et al (2006, p. 2),
[em um contexto de melhoria contínua de qualidade em projetos de desen- volvimento de software] é aplicado experimentalmente o processo PSP para disciplinar alguns dos processos sugeridos pelo CMMI nível 2 com duas es- tratégias distintas. A primeira consiste em observar o comportamento de
51
uma fábrica de software colhendo os dados necessários para atender o mo- delo PSP manualmente e na segunda visão a coleta ocorreu com o amparo de uma ferramenta CASE. Os resultados alcançados apontam os impactos nos rendimentos e nos padrões de qualidade que as duas estratégias pro- porcionaram e com os seus pontos fortes e as suas vulnerabilidades. Em ambos os casos o cumprimento dos prazos foi conseguido a partir do mo- mento em que a especificação e o andamento das atividades foram contro- lados pelas práticas sugeridas pelo PSP.
[...] O PSP tanto manual quanto amparado por ferramentas fornece uma es- trutura conceitual para a melhoria da gestão e do desenvolvimento de pro- dutos de software de uma forma consistente e disciplinada.
Silva et al (2006) afirmam:
Um caminho promissor para a obtenção de qualidade na produção de soft- ware é investir na melhoria do nível de qualidade pessoal de cada progra- mador. O PSP tem exatamente o objetivo de auxiliar nesse processo de au- to-conhecimento e posterior melhoria de competência em produção de soft- ware, fornecendo mecanismos para que o programador alcance a disciplina e a organização necessárias.
Desenvolvedores de software entenderiam melhor o que eles fazem se o seu trabalho for definido, medido e acompanhado. Humprhey (1996), afirma que, ao utili- zarem práticas bem definidas e níveis elevados de qualidade no seu trabalho, eles tornar-se-iam membros mais produtivos e eficazes nas suas organizações.
O conceito dos níveis definidos no PSP, juntamente com o incentivo a prática do planejamento e a possibilidade futura comparação entre atividades realizadas em diferentes projetos, estão alinhados a este trabalho no que diz respeito a uma auto- reflexão, e possíveis valores para análises comparativas da educação continuada deste profissional.