Antonio Marcos Neves Esteca
Apoio à maturidade pessoal visando a melhoria dos projetos de software
São José do Rio Preto 2013
Antonio Marcos Neves Esteca
Apoio à maturidade pessoal visando a melhoria dos projetos de software
Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Ciência da Computação, junto ao Programa de Pós-Graduação em Ciência da Computação, Área de Concentração - Sistemas de Computação, do Instituto de Biociências, Letras e Ciências Exatas da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de São José do Rio Preto.
Orientadora: Profª. Drª. Rogéria Cristiane Gratão de Souza
São José do Rio Preto 2013
Esteca, Antonio Marcos Neves
Apoio a maturidade pessoal visando a melhoria dos projetos de
software / Antonio Marcos Neves Esteca. - São José do Rio Preto: [s.n.],
2013.
137 f. : il. ; 30 cm.
Orientador: Rogéria Cristiane Gratão de Souza
Dissertação (mestrado) - Universidade Estadual Paulista, Instituto de
Biociências, Letras e Ciências Exatas
1. Computação. 2. Engenharia de software. 3. Software de
aplicação. I. Souza, Rogéria Cristiane Gratão. II. Universidade Estadual
Paulista, Instituto de Biociências, Letras e Ciências Exatas. III. Título.
CDU - 004.41
Ficha catalográfica elaborada pela Biblioteca do IBILCE
Campus de São José do Rio Preto - UNESP
i
Aos meus pais, avós e namorada.
ii
AGRADECIMENTOS
Agradeço primeiramente a Deus, por sempre ter iluminado os caminhos por onde
trilhei, dando força e coragem para seguir em frente da maneira correta.
Agradeço aos meus pais, João e Angela, que sempre apoiaram meus estudos como a
forma de alcançar horizontes cada vez melhores.
Agradeço também a todos os familiares que ajudaram e incentivaram minha formação,
principalmente a meus avós, Antônio e Tereza, e irmãs, Ariane e Fernanda, pelo apoio que
deram, mesmo sem saber que o estavam dando, desde meus primeiros anos de estudo.
Gostaria de expressar também profunda gratidão à minha namorada, Talita, que desde
o primeiro ano de graduação esteve ao meu lado, fazendo com que eu enxergasse as situações
com olhar mais tranqüilo e confiante, sempre com muita compreensão e carinho nos
momentos em que estive ausente para dedicar-me exclusivamente aos estudos.
À professora Rogéria, agradeço imensamente por ter me orientado desde o primeiro
semestre da graduação, oferecendo condições para meu amadurecimento não somente
intelectual, mas também pessoal, tendo me ensinado, dentre outras lições, que enfrentar
desafios é a única maneira de crescermos e aprimorarmos nossas capacidades.
Ao Grupo de Estudos e Pesquisas em Engenharia de Software (GEPES), em especial à
Professora Adriana e ao Wanderson, agradeço por todo o suporte oferecido durante a
realização deste projeto.
De maneira especial, agradeço a todos meus colegas, principalmente ao Victor, Júlio
César e Junior que, compartilhando momentos de dificuldade, mostraram que o importante
não é vencer todos os dias, mas batalhar sempre por nossos objetivos.
Por fim, agradeço à Fundação de Amparo à Pesquisa do Estado de São Paulo
(FAPESP) por ter apoiado financeiramente a realização deste projeto através da concessão de
bolsa de mestrado por meio do processo número 2010/13478-8.
iii
“Procure ser uma pessoa de valor, em vez de procurar ser uma pessoa de sucesso. O sucesso é
consequência.”
Albert Einstein
iv
RESUMO
Estudos revelam que os resultados dos projetos de software ainda estão muito
aquém do esperado. Devido a isso, organizações produtoras de software bem
sucedidas têm adotado uma abordagem mais completa em relação aos processos
de desenvolvimento. Nos últimos anos, além de gerenciarem seus projetos, tais
organizações estão investindo em um processo para capacitação individual e
monitoramento rigoroso dos recursos humanos, denominado Personal Software
Process – PSP. Tal processo tem levado à maior disciplina e controle sobre todas as
fases do desenvolvimento e, consequentemente, ao aumento da taxa de sucesso
dos projetos. Neste contexto, este trabalho apresenta a integração das técnicas
propostas no modelo PSP a um sistema web previamente desenvolvido,
denominado Sistema de Apoio à Gerência de Projetos - SAGP. A avaliação dos
resultados foi realizada por meio de uma análise comparativa da nova versão do
SAGP em relação a outras ferramentas disponíveis no mercado. Além disso, o
sistema foi avaliado por desenvolvedores de software, que constituem o seu público-
alvo. Os resultados obtidos permitem concluir que a integração realizada levou à
obtenção de um sistema de qualidade capaz de facilitar o emprego do PSP e de
gerar indicadores que auxiliam os gerentes de projetos em suas atividades.
Palavras-chave: Maturidade de recursos humanos. Personal Software Process.
Melhoria dos projetos de software.
v
ABSTRACT
Studies show that the results of software projects are still much less than expected.
Due to this, successful software-producing organizations have adopted a more
complete approach towards development processes. Nowadays, besides managing
their projects, such organizations are investing in a process of individual qualification
and strict monitoring of team members called Personal Software Process - PSP. This
process has led to maintenance of greater discipline and control throughout all
development phases and, consequently, to the increase in the rate of successful
projects. In this context, this work presents the integration of the techniques proposed
in the PSP model with a previously developed web-based system, which is called
System to Aid Project Management - SAPM. The evaluation of the results was
carried out through comparative analysis of the new version of SAGP in relation to
other tools commercially available. Furthermore, the system was evaluated by
software developers, who are their target audience. The results indicate that the
proposed integration led to obtaining of a system of quality able to facilitate the use of
the PSP and generate indicators that aid project managers in their activities.
Keywords: Maturity of human resources. Personal Software Process. Improvement
of software projects.
vi
LISTA DE ILUSTRAÇÕES
Figura 1.1 – Processo metodológico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figura 2.1 - Arquitetura de software do SAGP (ESTECA, 2010). . . . . . . . . . . . . . . . . . . 8
Figura 2.2 - Página inicial do SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 2.3 - Portfólio de projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 2.4 - Página principal do SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figura 2.5 - Página para vincular membros ao projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figura 2.6 - Fluxo do processo PSP (Adaptado de HUMPHREY, 1997). . . . . . . . . . . . . 13
Figura 2.7 - Níveis do PSP (Adaptado de HUMPHREY, 1997). . . . . . . . . . . . . . . . . . . . 15
Figura 3.1 - Diagrama de casos de uso - Requisitos gerais . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 3.2 - Diagrama de casos de uso - Requisitos referentes ao PSP 0. . . . . . . . . . . . . 44
Figura 3.3 - Diagrama de casos de uso - Requisitos referentes ao PSP 0.1. . . . . . . . . . . . 46
Figura 3.4 - Diagrama de casos de uso - Requisitos referentes ao PSP 1 . . . . . . . . . . . . . 47
Figura 3.5 - Diagrama de casos de uso - Requisitos referentes ao PSP 1.1 . . . . . . . . . . . 48
Figura 3.6 - Diagrama de casos de uso - Requisitos referentes ao PSP 2. . . . . . . . . . . . . 49
Figura 3.7 - Diagrama de casos de uso - Requisitos referentes ao PSP 2.1. . . . . . . . . . . . 50
Figura 3.8 - Diagrama arquitetural do SAGP estendido a partir de ESTECA (2010). . . . 52
Figura 3.9 - Menu principal do SAGP com destaque para os itens relacionados ao PSP . 55
Figura 3.10 - Página inicial da Área exclusiva - Nível 0 . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 3.11 - Página para cadastro de programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 3.12 - Página para gerenciamento de programas . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 3.13 - Página para seleção de programas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 3.14 - Página para definição de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 3.15 – Diagrama de estados representando o funcionamento do Time Recording
Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 3.16 – Telas associadas aos estados do Time Recording Log . . . . . . . . . . . . . . . . 59
Figura 3.17 – Defect Recording Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 3.18 – Diagrama de atividades referente ao envio de programas para teste. . . . . . 61
Figura 3.19 – Página de envio de programa para teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 3.20 – Página para recebimento de programa para teste. . . . . . . . . . . . . . . . . . . . . 62
Figura 3.21 – Sumário do Plano de Projeto - PSP 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 3.22 - Página inicial da Área exclusiva - Nível 0.1. . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 3.23 - Página de cadastro de propostas no Process Improvement Proposal . . . . . 65
Figura 3.24 - Página de cadastro de padrão de codificação. . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 3.25 - Página para registro e consulta do tamanho de programas. . . . . . . . . . . . . 66
Figura 3.26 - Página para definição de proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 3.27 - Página para registro de categorias funcionais . . . . . . . . . . . . . . . . . . . . . . . 68
Figura 3.28 - Página para registro de tamanho de proxies. . . . . . . . . . . . . . . . . . . . . . . . . 69
Figura 3.29 - Tabela de tamanho relativo gerada pelo sistema . . . . . . . . . . . . . . . . . . . . . 69
Figura 3.30 - Página para registro de tamanho de proxies. . . . . . . . . . . . . . . . . . . . . . . . . 70
Figura 3.31 - Resultado da avaliação do proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figura 3.32 - Página de registro de dados para estimativa de tamanho de programas. . . 71
vii
Figura 3.33 - Size Estimating Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 3.34 - Página de gerenciamento de atividades com campo para estimativa de
tempo de cada atividade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 3.35 - Página para registro do tamanho real dos programas . . . . . . . . . . . . . . . . . 74
Figura 3.36 - Página para registro testes planejados/executados . . . . . . . . . . . . . . . . . . . 74
Figura 3.37 – Página para estimativa do tempo de duração das atividades de um
programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Figura 3.38 – Página para ordenação de programas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 3.39 – Página para ordenação de atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 3.40 – Schedule Planning Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 3.41 – Task Planning Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figura 3.42 – Página para cadastro do checklist de revisão de código. . . . . . . . . . . . . . . . 79
Figura 3.43 – Página para emprego do checklist de revisão de código. . . . . . . . . . . . . . . 80
Figura 3.44 – Indicadores gerais de qualidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figura 3.45 – Evolução dos indicadores de qualidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 3.46 – Página para cadastro do modelo de especificação operacional . . . . . . . . . . 83
Figura 3.47 – Página para cadastro do modelo de especificação funcional. . . . . . . . . . . . 84
Figura 3.48 – Página para cadastro do modelo de especificação de estados . . . . . . . . . . . 84
Figura 3.49 – Página para cadastro do modelo de especificação lógica. . . . . . . . . . . . . . 84
Figura 3.50 – Menu principal do SAGP com destaque para os itens relacionados aos
indicadores do PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figura 3.51 – Página para geração de indicadores por equipe . . . . . . . . . . . . . . . . . . . . . 87
Figura 3.52 – Página para geração de rankings sobre os indicadores do PSP. . . . . . . . . . 88
Figura 3.53 – Página para seleção de atividades para geração de indicadores de tempo. . 89
Figura 3.54 – Página para exibição dos indicadores de tempo. . . . . . . . . . . . . . . . . . . . . . 90
Figura 4.1 – Perfil dos participantes quanto ao tempo de experiência. . . . . . . . . . . . . . . . 95
Gráfico 4.1 – Avaliação da Compreensão dos elementos e práticas do PSP antes e
depois da apresentação do SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Gráfico 4.2 – Avaliação da Importância dos elementos e práticas do PSP antes e depois
da apresentação do SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Gráfico 4.3 – Avaliação do Grau de dificuldade dos elementos e práticas do PSP antes
da apresentação da ferramenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Gráfico 4.4 – Avaliação da Facilidade de uso dos elementos e práticas do PSP após a
apresentação da ferramenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Gráfico 4.5 – Avaliação da concordância quanto às assertivas antes e depois da
apresentação da ferramenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Gráfico 4.6 – Avaliação da Aderência ao PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Gráfico 4.7 – Avaliação da contribuição decorrente da integração do PSP ao ambiente
de gerenciamento de projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Gráfico 4.8 – Avaliação dos aspectos de qualidade do sistema. . . . . . . . . . . . . . . . . . . . . 103
viii
LISTA DE TABELAS
Tabela 2.1 – Sumário do Plano de Projeto - PSP 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Tabela 2.2 – Sumário do Plano de Projeto - PSP 0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 2.3 - Tabela de tamanho relativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Tabela 2.4 – Size Estimating Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Tabela 2.5 – Critérios de seleção dos métodos para cálculo das estimativas pelo
PROBE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Tabela 2.6 – Sumário do Plano de Projeto – PSP 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Tabela 2.7 – Sumário do Plano de Projeto – PSP 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Tabela 2.8 – Sumário do Plano de Projeto – PSP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tabela 3.1 – Descrição resumida dos casos de uso – Requisitos gerais. . . . . . . . . . . . . . . 43
Tabela 3.2 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 0. . . . 45
Tabela 3.3 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 0.1. . 46
Tabela 3.4 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1
(continua) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tabela 3.4 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1
(conclusão) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Tabela 3.5 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1.1. . 49
Tabela 3.6 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 2. . . . 50
Tabela 3.7 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 2.1 . 50
Tabela 4.1 – Análise comparativa das ferramentas de apoio ao PSP. . . . . . . . . . . . . . . . . 94
Tabela A.1 - Cenário correspondente ao caso de uso "Registrar interesse em empregar
o PSP na gestão de projetos". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Tabela A.2 - Cenário correspondente ao caso de uso "Registrar nível do PSP a ser
empregado em cada projeto". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Tabela A.3 - Cenário alternativo correspondente ao caso de uso "Registrar nível do PSP
a ser empregado em cada projeto". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Tabela A.4 - Cenário correspondente ao caso de uso "Apresentar instruções do PSP" . . 115
Tabela A.5 - Cenário correspondente ao caso de uso "Apresentar sumário de plano de
projeto". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Tabela A.6 - Cenário correspondente ao caso de uso "Registrar conclusão de projeto". . 116
Tabela A.7 - Cenário correspondente ao caso de uso "Gerar relatório" . . . . . . . . . . . . . . 116
Tabela A.8 - Cenário correspondente ao caso de uso "Exibir indicadores de membros
da equipe " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Tabela A.9 - Cenário correspondente ao caso de uso "Cadastrar programas a serem
construídos" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Tabela A.10- Cenário correspondente ao caso de uso "Apresentar atividades a serem
realizadas no projeto". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Tabela A.11 - Cenário correspondente ao caso de uso "Cadastrar atividades pessoais" . . 118
Tabela A.12 - Cenário correspondente ao caso de uso "Registrar estimativa de tempo
das atividades". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
ix
Tabela A.13 - Cenário correspondente ao caso de uso "Disponibilizar o Time
Recording Log". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Tabela A.14 - Cenário correspondente ao caso de uso "Apresentar o Time Recording
Log". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Tabela A.15 - Cenário correspondente ao caso de uso "Disponibilizar o Defect
Recording Log". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Tabela A.16 - Cenário correspondente ao caso de uso "Enviar um programa para teste" 122
Tabela A.17 - Cenário correspondente ao caso de uso "Apresentar um programa para
teste". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Tabela A.18 - Cenário correspondente ao caso de uso "Registrar dados sobre os testes
no programa". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Tabela A.19 - Cenário correspondente ao caso de uso "Cadastrar padrão de
codificação". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Tabela A.20 - Cenário correspondente ao caso de uso "Registrar dados obtidos com as
medições de software". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Tabela A.21 - Cenário correspondente ao caso de uso "Cadastrar dados no Process
Improvement Proposal". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Tabela A.22 - Cenário correspondente ao caso de uso “Cadastrar proxy" . . . . . . . . . . . . 125
Tabela A.23 - Cenário correspondente ao caso de uso “Cadastrar categorias funcionais
de proxies” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Tabela A.24 - Cenário correspondente ao caso de uso “Registrar tamanho dos proxies
em programas já construídos” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Tabela A.25 - Cenário correspondente ao caso de uso “Apresentar tabelas de tamanho
relativo” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Tabela A.26 - Cenário correspondente ao caso de uso “Apresentar avaliação do proxy
definido” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Tabela A.27 - Cenário correspondente ao caso de uso “Registrar dados no Size
Estimating Template”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Tabela A.28 - Cenário correspondente ao caso de uso “Apresentar estimativas
pessoais” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Tabela A.29 - Cenário correspondente ao caso de uso “Registrar tempo estimado para
cada atividade seguindo instruções do PSP 1” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Tabela A.30 - Cenário correspondente ao caso de uso “Cadastrar dados no Test Report
Template” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Tabela A.31 - Cenário correspondente ao caso de uso “Registrar tempo estimado para
cada atividade seguindo as restrições do PSP 1.1”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Tabela A.32 - Cenário correspondente ao caso de uso “Disponibilizar o Task Planning
Template” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Tabela A.33 - Cenário correspondente ao caso de uso “Apresentar o Schedule Planning
Template” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Tabela A.34 - Cenário correspondente ao caso de uso “Registrar conclusão de
atividade” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Tabela A.35 - Cenário correspondente ao caso de uso “Apresentar o CPI” . . . . . . . . . . . 133
Tabela A.36 - Cenário correspondente ao caso de uso “Cadastrar o checklist de revisão
de código” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Tabela A.37 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de código” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Tabela A.38 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de projeto” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
x
Tabela A.39 - Cenário correspondente ao caso de uso “Apresentar indicadores de
qualidade” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Tabela A.40 - Cenário correspondente ao caso de uso “Disponibilizar modelos de
especificação de projeto” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Tabela A.41 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de projeto detalhado” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
xi
LISTA DE ABREVIATURAS
AF/R: Appraisal to Failure Ratio
CMM: Capability Maturity Model
COQ: Cost of Quality
CPI: Cost Performance Index
DRL: Defect-Removal Leverage
EV: Earned Value
GEPES: Grupo de Estudos e Pesquisas em Engenharia de Software
HTML: Hypertext Markup Language
KLOC: 1000 Lines Of Code
LOC: Lines Of Code
LPI: Lower Prediction Interval
MPS.BR: Melhoria de Processo do Software Brasileiro
PDF: Portable Document Format
PHP: acrônimo recursivo para PHP: Hypertext Preprocessor
PIP: Process Improvement Proposal
PMBoK: Project Management Body of Knowledge
PQI: Process Quality Index
PROBE: Proxy-Based Estimating
PSP: Personal Software Process
PV: Planned Value
SAGP: Sistema de Apoio à Gerência de Projetos
SEI: Software Engineering Institute
TSP: Team Software Process
UFPE: Universidade Federal de Pernambuco
UML: Unified Modeling Language
UNICAMP: Universidade Estadual de Campinas
UPI: Upper Prediction Interval
xii
SUMÁRIO
Capítulo 1 - Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Justificativa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Metodologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Organização da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Capítulo 2 – Melhoria dos Projetos de Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Sistema de Apoio à Gerência de Projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Personal Software Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Visão geral do PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Estrutura do PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Trabalhos relacionados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Capítulo 3 – Ferramenta de Apoio ao PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Requisitos identificados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Requisitos gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2 Requisitos referentes ao PSP 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.3 Requisitos referentes ao PSP 0.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.4 Requisitos referentes ao PSP 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.5 Requisitos referentes ao PSP 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.6 Requisitos referentes ao PSP 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.7 Requisitos referentes ao PSP 2.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Extensão da arquitetura de software do SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Funcionamento do componente de apoio ao PSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 Integração do PSP ao SAGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.2 Nível 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.3 Nível 0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.4 Nível 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.5 Nível 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.6 Nível 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.7 Nível 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.8 Indicadores oriundos do emprego individual do PSP. . . . . . . . . . . . . . . . . . . . . . . . 85
3.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
xiii
Capítulo 4 – Avaliação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2 Análise comparativa de ferramentas de apoio ao PSP. . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Visão dos usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.4 Considerações finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Capítulo 5 – Considerações Finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.1 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2 Contribuições. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3 Trabalhos futuros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.4 Conclusões. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Referências bibliográficas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Apêndice A – Cenários de especificação dos casos de uso. . . . . . . . . . . . . . . . . . . . . . . . 113
1
CAPÍTULO 1 – Introdução
1.1 Considerações iniciais
A atual concorrência entre organizações tem tornado cada vez mais necessária a
obtenção de informações de maneira rápida e segura, para que decisões adequadas possam ser
tomadas em tempo hábil, de modo a aumentar o potencial competitivo das empresas. Com
isso, os processos organizacionais tornam-se dependentes de sistemas de informação, o que
eleva a demanda por software de qualidade (SILVA, 2006).
Segundo Pressman (2009), qualidade de software consiste na conformidade com
requisitos funcionais e não-funcionais explicitamente declarados, normas de desenvolvimento
documentadas e características implícitas esperadas em todo o software desenvolvido
profissionalmente.
A qualidade de software pode ser analisada sob duas diferentes perspectivas: a
qualidade do produto de software e a qualidade do processo de desenvolvimento e
manutenção de software (SOMMERVILLE, 2011).
A qualidade do produto de software resulta das atividades realizadas durante seu
desenvolvimento, sendo mensurada pela verificação do atendimento ou não dos requisitos
identificados, o que é feito por meio de técnicas e atividades operacionais (SILVA, 2006). A
qualidade do processo de desenvolvimento e manutenção de software tem assumido um papel
tão importante quanto a qualidade dos produtos entregues aos clientes, uma vez que um
processo de qualidade auxilia na obtenção de um produto de qualidade, além de permitir a
repetição de bons resultados (ROCHA; MALDONADO; WEBER, 2001). Diante da
relevância da qualidade do processo, surgiram modelos de maturidade, como o CMM
(Capability Maturity Model) (Software Engineering Institute - SEI, 1993) e o MPS.BR
2
(Melhoria de Processo do Software Brasileiro) (SOFTEX, 2003), que guiam e possibilitam a
certificação das organizações em relação ao processo de desenvolvimento (NOGUEIRA,
2006).
1.2 Motivação
Para o desenvolvimento de software de qualidade, é necessário incorporar um
conjunto de boas práticas ao processo de desenvolvimento, dentre as quais está a gerência dos
projetos, que consiste na aplicação de conhecimentos, habilidades, ferramentas e técnicas nas
atividades do projeto, a fim de atender aos requisitos, bem como satisfazer às necessidades e
expectativas dos interessados (stakeholders) no projeto (PMI, 2008; PRESSMAN, 2009;
SOMMERVILLE, 2011).
Apesar das técnicas de gerenciamento estarem em constante aperfeiçoamento, os
resultados obtidos nos projetos de desenvolvimento de software ainda estão muito aquém do
esperado, conforme revela o estudo CHAOS (STANDISH GROUP, 2011), segundo o qual
42% dos projetos concluídos apresentam alterações em relação às estimativas iniciais, 21%
são abortados e apenas 37% são concluídos com sucesso. De acordo com o Standish Group,
um projeto é bem sucedido se é concluído dentro do prazo e orçamento previstos e atende às
funções inicialmente solicitadas, bem como às eventualmente incorporadas aos requisitos no
decorrer do projeto (EVELEENS; VERHOEF, 2010). Dentre as razões apontadas pelo estudo
CHAOS para o baixo índice de sucesso dos projetos de software destacam-se a falta de
comprometimento dos recursos humanos envolvidos e a definição de metas irreais baseadas
em expectativas acima da realidade (JIRACHIEFPATTANA, 2012), o que pode ser atribuído
à falta de indicadores sólidos sobre os membros de equipe.
Com o intuito de obterem melhores resultados em seus projetos, organizações
produtoras de software bem sucedidas têm adotado uma abordagem mais completa em relação
aos processos de desenvolvimento (SILVA, 2006). Nos últimos anos, além de gerenciarem
seus projetos, tais organizações estão investindo em um robusto processo para capacitação
individual e monitoramento rigoroso dos membros da equipe denominado Personal Software
Process - PSP, o qual tem levado à manutenção de maior disciplina e controle em todas as
fases do desenvolvimento e, conseqüentemente, ao significativo aumento da taxa de sucesso
dos projetos (HUMPHREY, 2005).
3
1.3 Objetivo
Este trabalho teve o objetivo de incorporar um componente de apoio ao emprego do
PSP a um sistema web de apoio à gerência de projetos previamente desenvolvido pelo Grupo
de Estudos e Pesquisas em Engenharia de Software – GEPES. Tal sistema, denominado
Sistema de Apoio à Gerência de Projetos - SAGP (ESTECA, 2010; SOUZA et al., 2011), tem
como intuito principal apoiar a execução de atividades gerenciais segundo as práticas
propostas por um dos mais conceituados guias para o gerenciamento de projetos, o Project
Management Body of Knowledge (PMBoK) (PMI, 2008). Para tanto, o SAGP fornece um
ambiente onde os gerentes de projeto de qualquer segmento de atuação podem cadastrar seus
projetos e vincular membros de equipe a eles. Deste modo, tanto o gerente de projetos como
os demais membros de equipe podem acessar cada projeto para usar as funções disponíveis,
que apoiam a efetivação de um gerenciamento adequado (SOUZA et al., 2011).
Neste contexto, as novas funções incorporadas ao SAGP automatizam a aplicação dos
mecanismos propostos pelo PSP, permitindo que todos os usuários do SAGP possam
empregá-lo durante a execução das atividades dos projetos de software aos quais estão
vinculados, fazendo com que a melhoria pessoal proporcionada pelo PSP contribua para o
sucesso dos projetos realizados.
Finalmente, cabe ressaltar que, em razão da abrangência e complexidade do PSP,
também foi objetivo deste trabalho oferecer elementos para apoiar os usuários do SAGP no
entendimento do PSP, motivando o uso efetivo de seus mecanismos durante a execução dos
projetos.
1.4 Justificativa
A integração de funções relacionadas ao PSP a um ambiente de apoio à gerência de
projetos pode acarretar uma série de benefícios, tanto em âmbito pessoal como em âmbito
organizacional.
Em âmbito pessoal, um dos principais benefícios é a automatização de todos os
complexos cálculos propostos pelo PSP, que normalmente representam uma barreira ao
emprego do processo (ABBAS; AFZAL; AHMED, 2012). Além disso, a integração ao
ambiente de gerenciamento de projetos é um importante diferencial da proposta, uma vez que
permite ao sistema apontar automaticamente o papel de cada membro de equipe nos projetos,
bem como as atividades e períodos em que estão alocados, o que facilita sobremaneira a
4
definição e o gerenciamento do trabalho pessoal a ser desenvolvido pelos membros de equipe.
Outro benefício importante do componente proposto é a disponibilização de elementos de
apoio ao aprendizado do PSP, o que é algo especialmente importante no Brasil e em países
onde são raros os cursos para ensino do assunto. Como resultado de todos esses benefícios,
constata-se que o componente proposto pode levar à melhoria da maturidade dos recursos
humanos, uma vez que facilita a adoção do PSP (HUMPHREY, 2005).
Em âmbito organizacional, um dos principais benefícios é o aumento da taxa de
sucesso dos projetos, uma vez que o PSP leva a um maior comprometimento dos membros de
equipe (HUMPHREY, 2005). Além disso, há um aumento da produtividade dos recursos
humanos, bem como uma melhoria na qualidade dos produtos de software resultantes
(WOHLIN, 1998). Outro benefício relevante é a disponibilização de mais informações de
apoio às tomadas de decisão dos gerentes de projetos, as quais podem ser geradas a partir do
processamento dos dados coletados sobre cada membro de equipe que emprega o PSP
individualmente. Tais informações podem ser úteis para direcionar decisões cujo impacto
pode afetar qualquer uma das nove áreas de conhecimento em gerenciamento de projetos, a
saber: Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicação,
Riscos e Aquisições (PMI, 2008). Além de apoiar as tomadas de decisão, tais informações
podem servir ainda como base para a aplicação de políticas para bonificação de recursos
humanos, uma vez que representam um meio para a avaliação dos recursos quanto a diversos
aspectos (HUMPHREY, 2005; JOHNSON et al., 2003).
Outro ponto que torna ainda mais relevante a proposta é a falta de sistemas de apoio ao
PSP mais completos. Além disso, durante o levantamento bibliográfico realizado neste
trabalho, não foram encontrados sistemas que integrem a aplicação do PSP ao contexto de
gerenciamento de projetos.
Diante do exposto, é possível constatar que os benefícios observados podem contribuir
fortemente para a melhoria do panorama atual dos projetos de software. Deste modo,
considera-se relevante incorporar ao SAGP o componente de apoio ao emprego do PSP.
1.5 Metodologia
A metodologia adotada para a realização deste trabalho dividiu-se em cinco principais
etapas:
1. Revisão bibliográfica: seleção e estudo de artigos relacionados ao tema e publicados
em periódicos e congressos científicos, os quais foram coletados em base de dados como o
5
portal de periódicos da CAPES, a SciELO, a ACM Digital Library, bem como nos anais de
congressos. Além disso, foram considerados livros, teses e dissertações relacionados ao tema.
A partir da revisão bibliográfica realizada, foram identificados os requisitos a serem
incorporados ao SAGP de modo a fornecer um apoio adequado para o emprego do PSP pelos
membros das equipes de projetos, bem como informações importantes que possam auxiliar os
gerentes de projetos em suas tomadas de decisões;
3. Extensão da arquitetura de software do SAGP: a partir dos requisitos definidos,
foram identificados os módulos a serem incorporados na versão atual da arquitetura de
software do SAGP, de modo a contemplar as novas funções;
4. Implementação e integração de novas funções ao SAGP: os módulos arquiteturais
identificados foram implementados e integrados ao ambiente do SAGP utilizando os seguintes
recursos computacionais gratuitos: linguagens PHP (acrônimo recursivo para "PHP:
Hypertext Preprocessor"), JavaScript e HTML (HyperText Markup Language); gerenciador
de banco de dados MySQL; servidor web Apache;
5. Avaliação da proposta: a avaliação da contribuição deste trabalho foi realizada em
duas etapas. Inicialmente, foi executada uma análise comparativa entre o sistema proposto e
algumas ferramentas de apoio ao PSP disponíveis no mercado. Posteriormente, o sistema foi
avaliado também por um grupo de 22 usuários com diferentes níveis de experiência em
desenvolvimento de software, o que permitiu identificar a abrangência do sistema
desenvolvido e o quanto ele auxilia no aprendizado de conceitos relacionados ao PSP.
O fluxo entre tais etapas e os artefatos gerados por elas estão ilustrados na Figura 1.1.
Figura 1.1 - Processo metodológico
6
1.6 Organização da dissertação
O restante dessa dissertação está organizado da seguinte forma:
Capítulo 2 - Melhoria dos Projetos de Software: neste capítulo é apresentado o SAGP,
fornecendo uma visão geral de sua arquitetura, bem como um estudo detalhado sobre o tema
central deste trabalho, o PSP, abordando desde conceitos básicos até os detalhes envolvidos
em sua estruturação;
Capítulo 3 – Ferramenta de Apoio ao PSP: neste capítulo são apresentados os
requisitos funcionais definidos para o sistema em desenvolvimento, bem como a extensão da
arquitetura de software original do SAGP;
Capítulo 4 – Avaliação dos Resultados: neste capítulo é apresentada a avaliação da
contribuição deste trabalho, descrevendo uma análise comparativa de sistemas de apoio ao
PSP, bem como um estudo sobre a visão dos usuários do sistema desenvolvido;
Capítulo 5 – Considerações Finais: neste capítulo são discutidas as principais
contribuições deste trabalho e são propostos alguns trabalhos futuros.
7
CAPÍTULO 2 – Melhoria dos Projetos de Software
2.1 Considerações iniciais
O objetivo deste capítulo é apresentar a arquitetura original do SAGP e uma visão
geral sobre seu funcionamento, bem como a estrutura do PSP, de maneira a permitir a
compreensão do contexto no qual este trabalho está inserido. Além disso, também são
apresentados trabalhos relacionados à melhoria da maturidade pessoal no contexto de
desenvolvimento de software, fornecendo uma visão geral sobre o estado da arte.
Na seção 2.2, é apresentada uma breve descrição sobre o funcionamento do SAGP,
destacando sua arquitetura. Na seção 2.3 é apresentada uma visão geral sobre o PSP, bem
como sua estrutura básica, descrevendo cada um dos seus níveis. Na seção 2.4 são
apresentados trabalhos relacionados à melhoria da maturidade pessoal. Por fim, na seção 2.5,
são apresentadas as considerações finais deste capítulo.
2.2 Sistema de Apoio à Gerência de Projetos
O SAGP foi construído com o intuito de apoiar a execução das boas práticas de
gerência de projetos descritas no guia PMBoK. Com isso, a arquitetura de software
estabelecida, ilustrada na Figura 2.1, visou contemplar os requisitos necessários para apoiar
as atividades gerenciais propostas no guia PMBoK.
8
Figura 2.1 - Arquitetura de software do SAGP
Fonte: ESTECA (2010).
Conforme apresentado na Figura 2.1, a arquitetura do SAGP é constituída por dois
componentes, a saber:
Controle de acesso: constituído por módulos que se comunicam para fornecer as
funções relacionadas ao controle de acesso ao SAGP, o que envolve o cadastro de
novos usuários, a autenticação no sistema, o cadastro de novos projetos e o controle do
nível de acesso de cada usuário aos projetos cadastrados;
Gestão de projetos: constituído por módulos que se comunicam para fornecer as
funções relacionadas ao gerenciamento de projetos propriamente dito, o que envolve o
apoio ao emprego das práticas referentes às nove áreas de conhecimento propostas no
guia PMBoK.
A descrição detalhada dos módulos desses componentes está disponível em ESTECA
(2010).
Com o intuito de exemplificar o funcionamento do SAGP, proporcionado pela
implementação dos respectivos módulos, cabe observar que para uma instituição ter acesso ao
SAGP é necessário que um de seus membros seja cadastrado pelo administrador do sistema.
Em seguida, este membro pode acessar o sistema autenticando-se pela página ilustrada na
Figura 2.2. Após a autenticação, esse usuário pode cadastrar um projeto ou acessar um projeto
9
cadastrado ao qual tenha acesso, selecionando-o no portfólio de projetos, ilustrado na Figura
2.3. Ao acessar um projeto, é exibida a página principal do sistema, apresentada na Figura 2.4,
a qual dá acesso ao menu principal, que categoriza as funções oferecidas pelo SAGP de
acordo com as nove áreas de conhecimento definidas no guia PMBoK.
Figura 2.2 - Página inicial do SAGP
Figura 2.3 - Portfólio de projetos
10
Figura 2.4 - Página principal do SAGP
Observa-se que o usuário criador de um projeto pode permitir que tal projeto seja
acessado por outros usuários. Para tanto, por meio da página ilustrada na Figura 2.5, o criador
do projeto pode vincular outros membros já cadastrados, bem como cadastrar novos
membros. Ao vincular um usuário a um projeto, é possível atribuir a ele um dos três níveis de
acesso:
Nível 3: permite acesso a todos os recursos e informações cadastradas no sistema.
Esse é o nível de acesso dos criadores dos projetos, que, por padrão, são definidos
como gerentes do projeto. Usuários com esse nível de acesso podem cadastrar
novos usuários, bem como vincular usuários aos projetos. Observa-se que um
usuário de nível 3 em um projeto pode não ter acesso a algum outro projeto, uma
vez que o nível de acesso varia por projeto;
Nível 2: permite todos os privilégios dos usuários de nível 3, exceto a
possibilidade de consultar informações financeiras dos projetos;
Nível 1: permite acesso apenas a informações referentes às atividades do projeto.
11
Figura 2.5 - Página para vincular membros a um projeto
Além das funções referentes às áreas de conhecimento em gerenciamento de projetos,
o SAGP permite a geração de relatórios em formato PDF, o que facilita a análise,
acompanhamento e distribuição das informações.
2.3 Personal Software Process
O objetivo desta seção é apresentar detalhadamente o PSP. Para tanto, na seção 2.3.1,
é apresentada uma visão geral do processo, descrevendo suas principais metas e elementos,
bem como os benefícios oriundos de sua aplicação. Na seção 2.3.2, é apresentada a estrutura
do PSP, descrevendo os mecanismos propostos em cada um de seus níveis.
2.3.1 Visão geral do PSP
A criação do PSP foi iniciada em 1989 por Watts Humphrey no SEI (HUMPHREY,
1989). A estrutura do PSP foi baseada no CMM, do qual foram selecionadas e adaptadas para
12
o nível individual 12 das 18 áreas chave de processo, não sendo abordadas apenas as que não
são aplicáveis em nível individual (REINEHR, 2001).
De modo geral, o PSP pode ser definido como um processo de auto-melhoria
projetado para ajudar o desenvolvedor de software a controlar, administrar e melhorar o modo
como trabalha (HUMPHREY, 2005). Em termos específicos, as metas do PSP são
(BALBINO, 2004; OVER, AKIYAMA, 2009):
fornecer subsídios para estimativas bastante precisas do tempo de esforço individual
necessário para o desenvolvimento de software;
direcionar o trabalho da equipe de desenvolvimento de acordo com um processo bem
definido;
definir e refinar o processo de desenvolvimento;
auxiliar na identificação e solução das deficiências do processo de desenvolvimento;
utilizar revisões eficientemente para melhorar a qualidade do software;
promover a diminuição de erros durante o desenvolvimento através da análise de
dados coletados.
Para atingir todas estas metas, o PSP é um processo bem definido que se divide em
três fases (POMEROY-HUFF et al., 2009):
Planejamento: nesta fase é produzido um plano para direcionar o desenvolvimento do
trabalho;
Desenvolvimento: nesta fase, com base no plano desenvolvido, é realizado o trabalho
propriamente dito, o qual engloba os passos de definição de requisitos, projeto do
software, revisão e correção de defeitos do projeto, codificação do software, revisão e
correção de defeitos do código, compilação e correção de defeitos, teste do software e
correção de defeitos;
Autópsia: nesta fase são estabelecidos comparativos entre os dados planejados e os
reais. Além disso, são registradas propostas para melhoria do processo.
Durante todas as fases do PSP devem ser empregados quatro elementos básicos
(POMEROY-HUFF et al., 2009):
Scripts: são descrições em alto-nível que guiam os usuários na execução de um
processo. Os scripts documentam o objetivo do processo, critérios de entrada,
13
diretrizes gerais, passos a serem executados, medições e critérios de qualidade do
processo e suas condições de saída;
Formulários: constituem uma forma consistente de coletar dados necessários para
execução dos processos. Existem ainda formulários especializados, denominados
checklists, que guiam os usuários na execução de algumas revisões propostas pelo
PSP;
Medições: quantificam o processo e o produto e habilitam os usuários a
desenvolverem perfis de dados com base em projetos anteriores, os quais podem ser
usados para planejamentos e melhorias de processo. Além disso, as medições
possibilitam monitorar a produtividade pessoal;
Padrões: oferecem definições precisas e consistentes que guiam o trabalho e a coleta e
uso dos dados, tornando possível aplicar medições uniformemente em vários projetos
para obtenção de dados que reflitam corretamente a realidade.
O fluxo destes elementos ao longo das fases do PSP é ilustrado na Figura 2.1.
Figura 2.6 - Fluxo do processo PSP
Fonte: Adaptado de HUMPHREY (1997).
Estudos empíricos revelam que, através de sua estrutura robusta e bem definida, o PSP
oferece diversos benefícios pessoais e/ou organizacionais, a saber (FERGUSON et al., 1997;
14
HUMPHREY 2005; JOHNSON et al., 2003; RAMINGWONG; RAMINGWONG, 2012;
WOHLIN, 1998):
aumento da produtividade;
diminuição da taxa de produção de defeitos;
melhoria da qualidade dos produtos de software;
estimativas de custo e cronograma cada vez mais próximas da realidade;
diminuição do tempo de realização de testes nos produtos de software e consequente
redução do tempo total de desenvolvimento;
aperfeiçoamento do processo de desenvolvimento de software;
atendimento, pelo menos parcial, de 12 das 18 áreas chave de processo do CMM;
aumento da chance de sucesso nos projetos como um todo devido ao cumprimento
adequado das metas estabelecidas em nível individual.
Diante de todos estes benefícios, o interesse pela implantação do PSP tem aumentado
significativamente nos últimos anos (RAMINGWONG; RAMINGWONG, 2012; SHEN;
YONG-JI; LI, 2009). Atualmente, a maneira mais comum de se obter os conhecimentos
necessários para o emprego do PSP é através de cursos com duração entre 100 e 150 horas ao
longo dos quais são executados exercícios e produzidos relatórios que permitem fixar
conceitos importantes e exercitá-los na prática. Além disso, em algumas universidades, como
a Universidade Estadual de Campinas - UNICAMP e a Universidade Federal de Pernambuco
- UFPE, o PSP vem sendo abordado em disciplinas de cursos de graduação e pós-graduação
da área de Ciência da Computação.
Apesar dos cursos habilitarem os desenvolvedores de software a empregarem o PSP,
sua incorporação dentro das organizações deve ser feita de maneira gradativa, uma vez que,
primeiramente, é necessário implantar mecanismos que apoiem o autoconhecimento dos
membros de equipe de desenvolvimento para que, posteriormente, com base nesse
conhecimento adquirido, possam ser implantados adequadamente os mecanismos que
proporcionarão os benefícios práticos do PSP.
2.3.2 Estrutura do PSP
O PSP é estruturado em 7 níveis, conforme ilustrado na Figura 2.7, sendo que a cada
nível são incorporados novos elementos de apoio a auto-melhoria contínua dos
15
desenvolvedores de software. A seguir são apresentados cada um destes níveis, exceto o
último, correspondente ao Team Software Process (TSP), que não é o objeto de interesse
deste trabalho, uma vez que representa uma expansão do PSP para ser utilizada por equipes,
não por indivíduos.
Figura 2.7 - Níveis do PSP
Fonte: Adaptado de HUMPHREY (2005).
Nível 0
Os níveis 0 e 0.1, também denominados PSP 0 e 0.1, pertencem ao grupo de processos
que constituem a base do PSP, introduzindo medições e relatórios padronizados. Os objetivos
do nível 0 do PSP são (HUMPHREY, 2005):
usar o processo atual como um processo introdutório;
incorporar medidas básicas no processo de desenvolvimento de software;
requerer mudanças mínimas nas práticas pessoais.
16
No PSP 0, os desenvolvedores de software são estimulados a incluir pequenas
modificações em seu processo de desenvolvimento. A primeira delas consiste em categorizar
as atividades de acordo com a sequência de passos das fases pré-definidas no PSP, ou seja,
planejamento, desenvolvimento e autópsia. Para cada uma destas fases, como todos os níveis
do PSP, o PSP 0 fornece um script para guiar os desenvolvedores ao longo do processo.
A fase de planejamento do PSP 0 é bastante simples, resumindo-se à estimativa de
tempo (em minutos) que o desenvolvedor espera levar para a construção total do produto de
software.
Já na fase de desenvolvimento do PSP são introduzidos dois formulários: o Time
Recording Log e o Defect Recording Log (HUMPHREY, 2005; REINEHR, 2001; SILVA
JÚNIOR, 2000).
O Time Recording Log tem a função de registrar o tempo gasto pelos desenvolvedores
em cada uma das atividades. Para tanto, o desenvolvedor deve registrar o momento em que
iniciou a execução de uma atividade e, para cada interrupção que ocorrer, deve registrar sua
duração e motivo. Por fim, o desenvolvedor deve registrar o momento em que parou de
executar a atividade, mesmo que ela ainda não tenha sido concluída. Este formulário pode ser
considerado um dos principais mecanismos de apoio ao autoconhecimento dos
desenvolvedores de software, pois, por meio dele, é possível conhecer onde é gasto o tempo e
como isso muda à medida que o processo evolui.
O Defect Recording Log tem a função de registrar dados sobre os defeitos encontrados
e o tempo para consertar cada um deles. Para tanto, sempre que um defeito é encontrado, o
desenvolvedor deve registrar os seguintes dados: data em que o defeito foi encontrado;
identificador exclusivo do defeito, que normalmente é um número; o tipo do defeito, que pode
ser selecionado a partir um conjunto padrão de dez defeitos sugerido pelo PSP; o passo da
fase de desenvolvimento em que defeito foi injetado; o passo da fase de desenvolvimento ou
autópsia em que defeito foi removido; tempo gasto para correção do defeito. Além destes
dados, caso um defeito Y seja gerado durante a correção de um defeito X, deve-se registrar
que Y refere-se à correção de X. A partir dos dados constantes neste formulário, os
desenvolvedores passam a ter parâmetros para o estabelecimento de metas de diminuição da
produção de defeitos.
Na fase de autópsia, os dados coletados através do Time Recording Log e do Defect
Recording Log são descritos no Sumário do Plano de Projeto do PSP 0, exemplificado na
Tabela 2.1, o qual é exclusivo para cada programa desenvolvido.
17
Tabela 2.1 – Sumário do Plano de Projeto - PSP 0
O formulário apresentado na Tabela 2.1 permite obter, de maneira clara e eficiente, as
seguintes informações:
diferença entre o tempo estimado e o tempo realmente utilizado para desenvolver o
produto de software, que é dado pelo somatório do tempo gasto em cada atividade do
projeto;
tempo gasto em cada um dos passos das fases do PSP, que é dado pelo somatório do
tempo gasto pelas atividades executadas em cada passo;
número de defeitos injetados e removidos em cada passo das fases do PSP, uma vez
que isto é registrado no Defect Recording Log;
Desenvolvedor José da Silva Data 10/01/2009
Projeto Fórmulas de estatística Programa 2
Linguagem C
Tempo em fase (minutos) Planejado Real To Date To Date %
Planejamento
5 8 5,7
Projeto 30 34 24,1
Codificação 32 36 25,5
Compilação 15 18 12,8
Teste 5 10 7,1
Autópsia 30 35 24,8
Total 180 117 141 100
Defeitos injetados Planejado Real To Date To Date %
Planejamento
0 0 0
Projeto 2 5 31,2
Codificação 5 11 68,8
Compilação 0 0 0
Teste 0 0 0
Total 7 16 100
Defeitos removidos Planejado Real To Date To Date %
Planejamento
0 0 0
Projeto 0 0 0
Codificação 0 2 12,5
Compilação 6 10 62,5
Teste 1 4 25
Total 7 16 100
Pós-desenvolvimento 0 0
18
atributo To Date que registra os valores acumulados em todos os programas
construídos usando o PSP. Por exemplo: o atributo Real refere-se ao tempo gasto num
dado programa na fase de planejamento, enquanto que o atributo To Date refere-se ao
tempo gasto em todos os programas durante a fase de planejamento;
atributo To Date % que mostra a distribuição percentual dos dados do atributo To Date
entre as fases do PSP, revelando aquelas em que a construção de seus programas mais
consome tempo ou gera defeitos, o que permite aos desenvolvedores elaborar futuras
estimativas com maior precisão.
Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais
elementos do PSP 0 são:
quatro scripts: um para guiar os desenvolvedores na utilização do PSP 0 e os outros
três para guiá-los em cada fase do PSP;
três formulários: Sumário do Plano de Projeto, Time Recording Log e Defect
Recording Log;
medições de tempo e defeitos produzidos;
padrão de tipo de defeitos.
Nível 0.1
O PSP 0.1 tem como foco de atuação a fase de autópsia do PSP, de modo que não são
incorporadas mudanças às fases de planejamento e desenvolvimento. Além de manter os
objetivos do PSP 0, o PSP 0.1 tem como objetivos específicos (SILVA JÚNIOR, 2000):
estimular a criação de um padrão de codificação;
estimular e auxiliar o processo de medição do tamanho dos programas produzidos;
estimular a melhoria do processo empregado para o desenvolvimento de software.
O estímulo ao processo de medição tem como intuito criar um histórico com o
tamanho dos programas construídos, que servirá de base para estimar o tamanho de
programas durante a elaboração de planejamentos de projetos futuros.
O processo de medição proposto pelo PSP 0.1 expressa o tamanho dos programas por
meio do número de linhas de código (LOCs, do inglês lines of code) e opera sistematicamente
para alcançar resultados consistentes e repetíveis. Neste processo, o primeiro passo a ser
executado é a adoção de um padrão de codificação que deve ser seguido em todos os
19
programas que forem construídos em uma mesma linguagem, para que todas as medições em
LOCs sejam proporcionais à quantidade de trabalho realizado. Como o padrão de codificação
é dependente da linguagem que está sendo utilizada, existem padrões propostos para Java
(ALBUQUERQUE; MEIRA, 1997), C++ (HUMPHREY, 1995), PHP (MARTINS;
OLIVEIRA, 2009) e outras linguagens.
Após adotar um padrão de codificação, o próximo passo do PSP 0.1 é a contagem e
classificação das linhas produzidas entre as seguintes categorias (HUMPHREY, 2005):
base (B): refere-se às linhas que já estavam codificadas no início da construção do
programa;
adicionadas (A): refere-se às linhas que foram criadas durante a construção do
programa;
modificadas (M): refere-se às linhas do código base que foram alteradas;
deletadas (D): refere-se às linhas do código base que foram excluídas e não utilizadas
no programa construído;
reutilizadas (R): refere-se às linhas de código que foram copiadas e utilizadas sem
nenhuma alteração. Se houver qualquer alteração, todas as linhas utilizadas devem ser
contadas como código base (B) e as alteradas devem ser contadas como modificadas
(M);
adicionadas e modificadas (A&M): esta categoria pode ser empregada quando o
tempo de criação ou alteração de uma linha de código é aproximadamente o mesmo.
Salienta-se que toda linha A&M deve ser classificada também como A ou M para que
seja possível calcular corretamente o tamanho total do programa;
novas reutilizáveis (NR): refere-se às linhas criadas com intenção de reutilização
futura ou às linhas do código base que foram modificadas para torná-lo reutilizável.
Salienta-se que toda linha NR deve ser classificada também como A ou M para que
seja possível calcular corretamente o tamanho total do programa.
Deste modo, tem-se a classificação adequada das linhas do código-fonte, bem como o
total (T) de linhas do programa construído, que deve ser calculado da seguinte forma:
T = B + A + R – D (2.1)
Embora este processo de contagem de tamanho pareça desnecessariamente complexo,
ele permite a obtenção de informações que serão necessárias para a realização de cálculos
20
estatísticos essenciais para a elaboração de estimativas de tamanho de software, que, por sua
vez, serão utilizadas em níveis posteriores do PSP para a criação de planos bastante precisos.
Para reduzir a complexidade do processo de contagem de tamanho, é recomendável a
utilização de programas específicos para este fim. Já para o registro das linhas deletadas e
modificadas, uma abordagem que pode ser empregada consiste em marcar tais linhas com um
comentário especial reconhecido e contabilizado por um contador específico.
Com os dados obtidos a partir da medição do tamanho dos programas, podem-se
realizar cálculos para a determinação de parâmetros capazes de indicar a qualidade do
programa e a produtividade do desenvolvedor. Como indicativo de qualidade do programa,
pode-se utilizar o número de defeitos para cada 1000 LOCs ou 1 KLOC produzido. Já a
produtividade do desenvolvedor pode ser indicada de diferentes maneiras, por exemplo: se for
considerada a produtividade para criar linhas de código, calcula-se o número de linhas
adicionadas (A) dividido pelo tempo de codificação (em horas); se for considerada a
produtividade para adicionar ou modificar linhas de código, calcula-se o A&M dividido pelo
tempo de codificação (em horas).
Além do processo de medição do tamanho dos programas, o PSP 0.1 propõe o uso de
um formulário denominado Process Improvement Proposal (PIP) para o registro de sugestões
de melhoria do processo de software utilizado, onde os principais dados a serem registrados
são: descrição do problema/situação atual; proposta de solução/mudança; comentários
adicionais. O formulário PIP pode ser utilizado em qualquer fase do PSP.
Na fase de autópsia, todas as medições devem ser registradas no Sumário do Plano de
Projeto do PSP 0.1, exemplificado na Tabela 2.2, o qual acrescenta as seguintes informações
em relação ao PSP 0:
quantidade de LOCs pertencentes a cada categoria;
quantidade total de LOCs criadas ou modificadas em programas construídos;
quantidade total de LOCs dos programas construídos;
quantidade total de LOCs reutilizadas nos programas construídos;
quantidade total de LOCs reutilizáveis criadas nos programas construídos.
21
Tabela 2.2 – Sumário do Plano de Projeto - PSP 0.1
Desenvolvedor José da Silva Data 14/01/2009
Projeto Fórmulas de estatística Programa 4
Linguagem C
Tamanho do programa
(LOC) Planejado Real To Date
Base (B)
20
Adicionadas (A)
50
Modificadas (M)
10
Deletadas (D)
5
Reutilizadas (R)
8 28
A&M
60 300
Total (T)
73 600
Novas reutilizáveis (NR)
5 18
Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais
elementos do PSP 0.1 são:
quatro scripts: um para guiar os desenvolvedores na utilização do PSP 0.1 e os outros
três para guiá-los em cada fase do PSP;
dois formulários: Sumário do Plano de Projeto, Process Improvement Proposal (PIP);
medição do tamanho dos programas construídos;
padrão de codificação.
Nível 1
Os níveis 1 e 1.1 do PSP, denominados PSP 1 e 1.1, têm como foco de atuação as
fases de planejamento e desenvolvimento do PSP e pertencem ao grupo de processos de
planejamento. Além de manter os objetivos do PSP 0.1, o PSP 1 tem como objetivos
específicos (HUMPHREY, 2005):
estabelecer um método ordenado e repetível para estimar o tamanho e tempo total de
desenvolvimento de um software;
estimular o registro de uma maior quantidade de informações sobre os testes
realizados em programas.
+ campos do Sumário do Plano de Projeto do PSP 0
22
O método de estimativa de tamanho de software estabelecido no PSP 1 é denominado
Proxy-Based Estimating (PROBE) e pode ser considerado o elemento central do PSP, tendo
sido criado especialmente para ser utilizado durante sua fase de planejamento. O PROBE foi
baseado em princípios e técnicas conhecidos, como lógica Fuzzy, método do componente
padrão, análise por pontos de função e técnicas estatísticas (REINEHR, 2001). O nome do
método deve-se ao fato de que todo seu funcionamento baseia-se em um proxy, que nada mais
é que uma unidade capaz de representar o esforço demandado para o desenvolvimento de um
programa. No contexto de desenvolvimento de software, exemplos de proxies são classes,
tabelas de banco de dados, janelas de interface, etc. Observa-se que para cada linguagem de
programação empregada deve ser definido um proxy apropriado.
Antes de se aplicar o método PROBE, é necessário criar uma tabela de tamanho
relativo, que busca definir o número médio de LOCs de proxies para cinco categorias de
tamanho relativo: muito pequena, pequena, média, grande e muito grande. Para tanto, é
necessário que inicialmente sejam estabelecidas as categorias funcionais do proxy definido,
pois o tamanho relativo de um proxy varia de acordo com a sua função. No caso em que se
emprega classe como proxy, exemplos de suas possíveis funções são execução de cálculos,
realização de operações de entrada/saída, etc. Em geral, não são necessárias mais que seis
categorias para descrever todas as possíveis funções que um proxy pode exercer
(HUMPHREY, 2005). Após a definição das categorias funcionais, deve-se registrar dados
históricos sobre o tamanho e tempo de desenvolvimento do proxy para cada tipo de função
que ele pode exercer. Tais dados devem então ser submetidos a uma análise da correlação
matemática, a qual deve ser maior que 0,7 para comprovar que o proxy definido realmente é
capaz de indicar o esforço demandado para o desenvolvimento dos programas, uma vez que
há proporcionalidade entre o tamanho e o tempo de desenvolvimento. Caso o valor da
correlação seja superior a 0,7, deve-se ainda calcular a significância dos dados para constatar
se a quantidade de dados históricos é suficiente ou se devem ser registrados mais dados. Se o
valor da correlação for inferior a 0,7 e a significância for adequada, é necessário alterar o
proxy ou remover dados históricos considerados outliers. Após a coleta de dados históricos e
comprovação da adequação do proxy, finalmente deve-se realizar cálculos que apontem o
tamanho médio do proxy para cada categoria funcional. Na Tabela 2.3 é apresentado um
exemplo de tabela de tamanho relativo usando classe como proxy para programas
desenvolvidos em C++. O detalhamento de todos os cálculos pode ser encontrado em
HUMPHREY (2005).
23
Tabela 2.3 - Tabela de tamanho relativo
Tamanho de classe em LOCs - Linguagem C++
Categoria Muito pequena Pequena Média Grande Muito grande
Cálculo 2,34 5,13 11,25 24,66 54,04
Dados 2,60 4,79 8,84 16,31 30,09
Entrada/Saída 9,01 12,06 16,15 21,62 28,93
Lógica 7,55 10,98 15,98 23,25 33,83
Configuração 3,88 5,04 6,56 8,53 11,09
Texto 3,75 8,00 17,07 36,41 77,66
Fonte: Extraído de HUMPHREY (2005).
Com a tabela de tamanho relativo já estabelecida, o PROBE pode ser aplicado
empregando-se os seguintes passos (HUMPHREY, 2005):
Passo 1. elaboração de um projeto conceitual do programa a ser construído, cujas partes
devem ser definidas em termos do proxy;
Passo 2. estimativa inicial do tamanho do programa a ser desenvolvido, a qual é feita
analisando-se a função e o tamanho relativo esperado para cada parte do projeto conceitual;
Passo 3. categorização das LOCs que comporão as partes do programa. Para apoiar a
execução deste trabalho, o PSP 1 oferece um formulário denominado Size Estimating
Template, ilustrado na Tabela 2.4. Neste formulário, devem ser estimadas as partes base, as
partes adicionadas e as partes reutilizadas do programa a ser construído. As partes base são
aquelas sobre as quais será iniciada a construção do programa. As partes adicionadas referem-
se ao código que deverá ser criado e que deve ser estimado em termos de proxies. Já as partes
reutilizadas são aquelas que serão inteiramente extraídas da biblioteca de reuso, sem
alterações. Observa-se que, ao término da construção do programa, deve-se registrar no
mesmo formulário os dados reais sobre as partes do programa.
24
Tabela 2.4 – Size Estimating Template
Fonte: Adaptado de HUMPHREY (2005).
Após o preenchimento das estimativas no Size Estimating Template, devem ser
calculados os valores de duas variáveis:
A = BA + PA (2.2)
onde A é o número total de linhas a serem criadas, BA é o número de linhas que serão
adicionadas às partes base e PA é o tamanho total das partes adicionadas
E = A + M (2.3)
onde E é o tamanho estimado do proxy e M é o número de linhas que serão modificadas nas
partes base.
25
Passos 4 e 5. estimativa definitiva do tamanho do programa (Passo 4) e estimativa definitiva
do tempo total de desenvolvimento do programa (Passo 5). Para tanto, vários cálculos devem
ser realizados para atribuir valores a um conjunto de variáveis, que são reunidas numa
planilha fornecida pelo PSP 1 para apresentação clara das informações. Durante o quarto e
quinto passos do PROBE, a primeira decisão a ser tomada é sobre qual método será utilizado
para a realização dos cálculos para estimativa de tamanho e tempo de desenvolvimento dos
programas. São quatro métodos: A, B, C ou D, sendo que a adequação de um ou outro método
relaciona-se à quantidade de dados históricos que se tem disponível. Na Tabela 2.5 são
apresentados os critérios de seleção de cada método.
Tabela 2.5 – Critérios de seleção dos métodos para cálculo das estimativas pelo PROBE
Método Critérios de seleção
A Para estimativas de tamanho, este método só poderá ser usado caso existam três
ou mais pontos de dados sobre o tamanho estimado do proxy (E) e o número
real de LOCs adicionadas e modificadas nos programas construídos. Já para
estimativas de tempo, este método só poderá ser usado caso existam três ou
mais pontos de dados sobre o tamanho estimado do proxy (E) e o tempo real de
desenvolvimento. Além disso, para ambas estimativas a correlação matemática
entre os dados deve ser maior que 0.7.
B Deverá ser usado caso o método A não seja adequado. Para estimativas de
tamanho, este método poderá ser usado caso existam três ou mais pontos de
dados sobre o tamanho planejado de LOCs adicionadas e modificadas e os
correspondentes tamanhos reais. Já para estimativas de tempo, este método
poderá ser usado caso existam três ou mais pontos de dados sobre o tamanho
planejado de LOCs adicionadas e modificadas e o correspondente tempo real de
desenvolvimento. Além disso, para ambas estimativas, a correlação matemática
entre os dados deve ser maior que 0.7. Note que, neste método, não é necessário
ter dados sobre a variável E em outros programas, mas apenas estimativas do
número de LOCs adicionadas e modificadas, as quais podem ter sido estimadas
pelo julgamento do desenvolvedor.
C Deverá ser usado caso o método B não seja adequado. Para estimativas de
tamanho, este método poderá ser usado caso exista pelo menos um ponto de
dados sobre o tamanho planejado de LOCs adicionadas e modificadas e o
correspondente tamanho real. Para estimativas de tempo, este método poderá ser
usado caso exista pelo menos um ponto de dados sobre o tamanho planejado de
LOCs adicionadas e modificadas e o correspondente tempo real de
desenvolvimento. Neste método não se calcula a correlação matemática entre
os dados de tamanho e tempo.
D Deverá ser usado se não houver nenhum dado histórico. Este método consiste
em apenas julgar o tamanho esperado de LOCs adicionadas e modificadas ou o
tempo de desenvolvimento.
Após a escolha do método a ser utilizado, deve-se calcular os parâmetros de regressão
linear β0(size) e β1(size) para a estimativa de tamanho e β0(time) e β1(time) para estimativa do tempo.
26
Em termos gerais, β0 indica a variação percentual média do tamanho/tempo real em relação ao
estimado, enquanto β1 indica uma relação entre o valor de E e o número de LOCs/tempo real
(em minutos). No entanto, o cálculo destes parâmetros não consiste em simplesmente
calcular médias aritméticas e varia de acordo com o método utilizado (A, B, C ou D). Os
valores encontrados pelos cálculos realizados podem indicar a necessidade de mudar de um
método para outro. Detalhes sobre o cálculo dos parâmetros β0 e β1 podem ser encontrados em
HUMPHREY (2005).
Ainda no quarto passo, após a definição de β0(size), β1(size), β0(time) e β1(time) deve-se
estabelecer os valores para as seguintes variáveis:
P = β0(size) + β1(size)*E (2.4)
onde P é a estimativa final do tamanho do programa a ser desenvolvido em LOCs adicionadas
e modificadas
T = P + B - D - M + R (2.5)
onde T é o tamanho total estimado do programa a ser desenvolvido
Tempo total estimado = β0(time) + β1(time)*E (2.6)
Com o tempo total de desenvolvimento já estabelecido, a definição do tempo de cada
fase pode ser feita pelo julgamento do desenvolvedor.
Passo 6. cálculo do intervalo de previsão, que estabelece um valor mínimo e máximo dentro
do qual as variáveis tamanho e tempo totais têm determinada probabilidade de cair. O PSP
sugere o emprego de um intervalo de previsão de 70%, o qual estabelece um intervalo de
valores dentro do qual há 70% de chance de os valores de tamanho e tempo reais caírem. Para
definir os intervalos de previsão de 70%, deve-se executar as seguintes etapas:
a) calcula-se a variância entre os dados projetados e os dados reais para tamanho e tempo
aplicando-se a seguinte fórmula:
(2.7)
onde n é o tamanho do conjunto de dados histórico, yi é o dado real (o tamanho real do
programa ou o tempo real de desenvolvimento), xi é o dado estimado, devendo-se utilizar
β0(size) e β1(size) quando calculando o intervalo de previsão para o tamanho e β0(time) e β1(time)
quando calculando o intervalo de previsão para o tempo;
b) calcula-se o desvio padrão:
Desvio padrão = σ = (2.8)
27
c) utiliza-se uma tabela t - distribution (HUMPHREY, 2005) para encontrar o valor de t
(p, d), com p = 70% e d = n - 2 graus de liberdade, o qual indica o número de variáveis
livres que serão utilizados para o cálculo estatístico;
d) calcula-se a variação do intervalo de previsão:
Variação = t (p, d) σ 1 + 1
𝑛+
(𝑥𝑘− 𝑥𝑎𝑣𝑔 )2
(𝑥𝑖− 𝑥𝑎𝑣𝑔 )2𝑛𝑖=1
(2.9)
onde xavg é a média das n estimativas e xk é o valor da estimativa do tamanho do proxy (E)
para o programa atual.
Após encontrar o valor da variação do intervalo de previsão, finalmente são calculados
o menor (LPI, do inglês Lower Prediction Interval) e o maior (UPI, do inglês Upper
Prediction Interval) valores do intervalo de previsão, dados por:
LPI = β0 + β1xk - Variação (2.10)
UPI = β0 + β1xk +Variação (2.11)
Salienta-se que se deve utilizar β0(size) e β1(size) quando calculando o intervalo de
previsão para o tamanho e β0(time) e β1(time) quando calculando o intervalo de previsão para o
tempo.
Observa-se que para auxiliar o emprego do método PROBE, o PSP 1 fornece
instruções através do PROBE Estimating Script.
Após a execução do método PROBE, tem-se a estimativa de tamanho total do
programa a ser desenvolvido, bem como o tempo total de desenvolvimento esperado. Embora
seja bastante minucioso, o método PROBE permite obter estimativas cada vez mais próximas
da realidade, uma vez que elas se baseiam em dados históricos pessoais. Além disso, desde
que sejam feitas as devidas adaptações, é possível utilizar este método para estimar tamanho e
tempo de diversos tipos de tarefas, e não apenas de tarefas de programação.
Além do método PROBE, o PSP 1 propõe o emprego de um formulário denominado
Test Report Template para o registro de informações mais detalhadas sobre os testes
realizados nos programas, tais como: número do teste, objetivo, descrição, condições de teste,
resultados esperados e resultados reais.
28
Como em todos os níveis do PSP, o PSP 1 estabelece o Sumário do Plano de Projeto
do PSP 1, exemplificado na Tabela 2.6, o qual acrescenta ao PSP 0.1 as seguintes
informações:
produtividade real, planejada e geral (To Date) em LOCs/hora, indicando quantas
linhas são adicionadas ou modificadas por hora;
dados sobre o tamanho planejado e real do programa, categorizados de acordo com os
tipos de LOC;
dados sobre o tempo total planejado e real necessário para o desenvolvimento do
programa;
dados sobre o tempo planejado e real necessário para cada fase de construção do
programa.
Tabela 2.6 – Sumário do Plano de Projeto – PSP 1
Desenvolvedor José da Silva Data 10/03/2009
Projeto Fórmulas de estatística Programa 10
Linguagem C
Planejado Real To Date
LOCs/hora 27,2 30,9 23,4
Tamanho do programa
(LOC) Planejado Real To Date
Base (B) 695 695
(medido) (medido)
Adicionadas (A) 533 464
(A&M - M) (T - B + D -R)
Modificadas (M) 5 18
(estimado) (contado)
Deletadas (D) 0 0
(estimado) (contado)
Reutilizadas (R) 169 169
(estimado) (contado)
A&M
538 482 2081
(projetado, dado por P) (A + M)
Total (T)
1397 1328 5161
(P + B - M - D + R) (medido)
Novas reutilizáveis (NR)
54 294
Tamanho estimado do
proxy (E) 366
+ campos do PSP 0.1, incluindo planejamento de tempo das fases
29
Além desses dados, caso seja de interesse, os valores de LPI e UPI podem também ser
apresentados no sumário.
Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais
elementos do PSP 1 são:
cinco scripts: um para guiar os desenvolvedores na utilização do PSP 1, três para
guiá-los em cada fase do PSP e um com instruções de apoio ao emprego do método
PROBE;
três formulários: Sumário do Plano de Projeto, Test Report Template, Size Estimating
Template.
Nível 1.1
O PSP 1.1 tem como foco de atuação as fases de planejamento e desenvolvimento do
PSP, de modo que não são incorporadas mudanças à fase de autópsia. Além de manter os
objetivos do PSP 1, o PSP 1.1 tem como objetivos específicos (HUMPHREY, 2005):
elaborar o planejamento de tarefas de um projeto;
criar cronogramas;
monitorar o progresso real em relação ao progresso planejado para o projeto.
Para elaborar o planejamento de tarefas, o desenvolvedor deve, primeiramente,
distribuir entre as fases do PSP o tempo total estimado pelo PROBE para o desenvolvimento
de cada um dos programas do projeto. Esta distribuição deve basear-se no atributo To Date %
(relacionado ao tempo) do Sumário do Plano de Projeto. Caso exista mais de uma atividade
em uma ou mais fases, o desenvolvedor deve julgar o tempo necessário para cada atividade de
modo que a soma seja igual ao tempo total da fase. Após a definição da duração das
atividades, esta informação deve ser lançada no Task Planning Template, que registra as
seguintes informações:
nome da atividade;
fase a qual pertence;
duração planejada (em horas);
total de horas acumuladas até cada atividade, o qual é dado pela soma da duração
das atividades anteriores;
30
valor planejado (PV, do inglês planned value) para cada atividade, o qual deve ser
dado pelo percentual do tempo total planejado que se espera gastar com a
atividade;
PV acumulado até cada atividade, o qual é dado pela soma do PV das atividades
anteriores;
semana planejada, que é estimada com apoio do Schedule Planning Template e
corresponde à semana em que se planeja concluir uma atividade;
horas realmente gastas com cada atividade;
semana em que cada atividade foi realmente concluída;
valor agregado (EV, do inglês earned value) pela atividade, o qual é atribuído
apenas quando a atividade é totalmente concluída e corresponde ao PV;
EV acumulado até cada atividade, o qual é dado pela soma do EV das atividades
anteriores.
Conforme citado, o Schedule Planning Template tem como função auxiliar na
definição das semanas em que cada atividade de determinado projeto será concluída. Para
tanto, este formulário registra a disponibilidade do desenvolvedor para um determinado
projeto em cada semana (até que se complete a quantidade de horas total estimada para o
projeto) por meio dos seguintes atributos:
data de início da semana;
identificador numérico da semana;
horas disponíveis na semana;
horas disponíveis acumuladas até determinada semana;
horas realmente gastas em cada semana;
horas realmente acumuladas até determinada semana;
PV de cada semana, o qual corresponde ao somatório dos PVs das atividades que
deverão ser concluídas em cada semana;
PV acumulado até determinada semana;
EV de cada semana, o qual corresponde ao somatório dos EVs das atividades
concluídas em cada semana;
EV acumulado até determinada semana.
31
Salienta-se que o EV é atribuído a uma atividade somente quando ela é completamente
concluída, de modo que não se atribui 50% do PV como sendo o EV de uma atividade 50%
concluída.
A partir do Task Planning Template e do Schedule Planning Template, o
desenvolvedor consegue elaborar o planejamento de suas atividades em termos das semanas
de execução do projeto. Além disso, é possível monitorar e comparar o progresso real em
relação ao planejado, o que é feito comparando-se o EV acumulado com o PV acumulado. Se
o EV acumulado for maior ou igual ao PV acumulado, o progresso do projeto está dentro do
esperado ou além do esperado. Caso contrário, o progresso está aquém do esperado.
O PSP 1.1 fornece também um indicador capaz de sinalizar a capacidade do
planejamento do tempo, o qual é denominado Cost Performance Index (CPI), que consiste na
razão entre o tempo de desenvolvimento total planejado acumulado até a data e o tempo de
desenvolvimento total real acumulado até a data (POMEROY-HUFF et al., 2009). O ideal é
que o CPI seja próximo a 1, refletindo que o tempo planejado está próximo ao tempo
realmente gasto.
Como em todos os níveis do PSP, o PSP 1.1 estabelece o Sumário do Plano de Projeto
do PSP 1.1, exemplificado na Tabela 2.7, o qual acrescenta ao PSP 1 as seguintes
informações:
tempo planejado e real para o desenvolvimento do programa;
tempo planejado e real acumulado até a data, desde que se iniciou o emprego do PSP;
CPI e percentual de LOCs reutilizadas (R) e novas reutilizadas (NR).
Tabela 2.7 – Sumário do Plano de Projeto – PSP 1.1
Desenvolvedor José da Silva Data 29/03/2009
Projeto Fórmulas de estatística Programa 11
Linguagem C
Planejado Real To Date
LOCs/hora 26,7 25,3 23,6
Tempo planejado 680 4805,8
Tempo real
709,2 6052,2
CPI
0,80
% de LOCs R 1,3 1,4 0,50
% de LOCs NR 4,4 5,3 5,7
+ campos do PSP 1
32
Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais
elementos do PSP 1.1 são:
quatro scripts: um para guiar os desenvolvedores na utilização do PSP 1 e três para
guiá-los em cada fase do PSP;
três formulários: Sumário do Plano de Projeto, Task Planning Template, Schedule
Planning Template.
Nível 2
Os níveis 2 e 2.1, denominados PSP 2 e 2.1, têm como foco o gerenciamento da
qualidade pessoal. Além de manter os objetivos do PSP 1.1, o PSP 2 tem como objetivos
específicos (HUMPHREY, 2005):
introduzir revisões de projeto e código;
introduzir métodos para avaliar e melhorar a qualidade do processo de software e das
revisões;
estimar o número de defeitos em cada fase.
O objetivo das revisões é encontrar e corrigir defeitos o mais cedo possível, pois,
conforme apontam estudos empíricos (HUMPHREY, 2005; PRESSMAN, 2009), é muito
mais rápido e barato encontrar e corrigir defeitos em fases iniciais do desenvolvimento de
software. Para apoiar a execução das revisões, o PSP 2 fornece um script para orientar a
revisão de projeto e outro para a revisão de código, os quais devem ser aplicados em conjunto
com checklists de revisão de projeto e código, respectivamente. Enquanto o PSP 2 fornece
checklist para revisão de projeto, o checklist de revisão de código é um formulário específico
para cada linguagem, onde os desenvolvedores registrarão cada um dos itens verificados nas
revisões, de modo a evitarem esquecimentos. Este checklist deve ser criado e atualizado com
base no conjunto de tipos de defeitos padrão e no Defect Recording Log, com o intuito de
evitar que tais defeitos estejam presentes no código. Observa-se que as revisões de projeto
devem ser realizadas após a criação do projeto e antes da codificação, enquanto as revisões de
código devem ser realizadas ao término da codificação e antes da compilação.
Além de introduzir as revisões de projeto e código, o PSP 2 introduz diversos métodos
para avaliar a qualidade do processo de software e das revisões e, com isso, melhorá-las. Tais
33
métodos consistem na obtenção de indicadores calculados com base nos dados registrados
durante o desenvolvimento. Os principais indicadores gerados para análise são:
rendimento da remoção de defeitos - quantifica a eficiência da remoção de defeitos
em cada fase do PSP. Há duas formas de mensurá-lo:
- rendimento de uma fase = número de defeitos corrigidos na fase (2.12)
número de defeitos presentes no início da fase +
número de defeitos produzidos na fase
- rendimento do processo = número de defeitos corrigidos antes da compilação (2.13)
número de defeitos presentes antes da compilação +
número de defeitos presentes durante a compilação
Salienta-se que os rendimentos das fases de revisão de projeto e código podem ser
calculados como forma de sinalizar a qualidade das revisões.
densidade de defeitos - é dado pelo número de defeitos encontrados por volume de
projeto ou pelo número de defeitos encontrados por KLOC.
taxa de defeitos - é dado por:
número de defeitos encontrados em uma fase (2.14)
tempo gasto em horas na fase
defect-removal leverage (DRL) - mede o poder de remoção de defeitos de uma fase
em relação a uma outra fase e é dado por:
número de defeitos removidos em uma fase X (2.15)
número de defeitos removidos em uma fase Y
Este indicador é especialmente útil quando envolve fases de revisão e teste, pois
demonstra qual delas tem um poder maior para remover defeitos.
34
taxa de revisão - esse é um indicador usado principalmente para revisão de LOCs, não
sendo muito comum para revisão de projeto. É dado por:
número de LOCs revisadas (2.16)
tempo de revisão de código em horas
cost-of-quality (COQ) - é uma forma de quantificar o tamanho do problema de
qualidade (HUMPHREY, 2005). As medidas de COQ do PSP são as seguintes:
a) Failure COQ - mede o percentual de tempo que a compilação e os testes demandam
em relação ao tempo total de desenvolvimento e é dado por:
100* (tempo de compilação + tempo de testes) (2.17)
tempo total de desenvolvimento
b) Appraisal COQ - mede o percentual de tempo que as revisões de código e de
projeto demandam em relação ao tempo total de desenvolvimento e é dado por:
100* (tempo de revisão de projeto + tempo de revisão de código) (2.18)
tempo total de desenvolvimento
c) COQ total - mede percentual de tempo que as medidas de qualidade demandam em
relação ao tempo total de desenvolvimento e é dado por:
Failure COQ + Appraisal COQ (2.19)
d) Appraisal como % do COQ total - é dado por:
100* (Appraisal COQ) (2.20)
COQ total
e) Appraisal to Failure Ratio (AF/R) - calcula a razão entre Appraisal COQ e Failure
COQ, sendo muito útil para monitorar o melhoramento da qualidade do processo
pessoal, pois valores maiores de AF/R demonstram que uma quantidade de tempo
adequada está sendo empregada em revisões. No entanto, deve haver um equilíbrio no
gasto de tempo com revisões, de modo que um bom valor para o AF/R é próximo a 2.0
(HUMPHREY, 2005).
process quality index (PQI) - é um índice que quantifica a qualidade do processo de
software e é calculado como o produto dos seguintes valores (HUMPHREY, 2005):
a = tempo de projeto (2.21)
tempo de codificação
35
b = 2 * tempo de revisão do projeto (2.22)
tempo de projeto
c = 2 * tempo de revisão do código (2.23)
tempo de codificação
d = 20 (2.24)
(10 + defeitos de compilação/KLOC)
e = 10 (2.25)
(10 + defeitos de teste de unidade/KLOC)
Logo, PQI = a*b*c*d*e. Quanto mais próximo de 1 for o PQI, melhor é a qualidade
do processo de desenvolvimento.
Por fim, o PSP 2 estimula os desenvolvedores a estimarem o número de defeitos que
serão produzidos em cada fase. Para tanto, primeiramente deve ser estimado o tamanho do
programa a ser desenvolvido. Em seguida, com base no número de defeitos por KLOC
(obtido pelos dados históricos), estima-se o número total de defeitos que o programa terá.
Para distribuir estes defeitos entre as fases, utiliza-se os dados de To Date %.
Como em todos os níveis do PSP, o PSP 2 estabelece o Sumário do Plano de Projeto
do PSP 2, exemplificado na Tabela 2.8, o qual acrescenta ao PSP 1.1 as seguintes
informações:
defeitos encontrados na fase de teste por KLOC (planejado, real e até a data), sendo
que quanto menor for este valor, melhor é a qualidade do processo, uma vez que os
defeitos devem ser encontrados preferencialmente antes da fase de teste;
defeitos encontrados por KLOC (planejado, real e até a data), sendo que quanto menor
for este valor, melhor é a qualidade do produto;
rendimento do processo;
UPI e LPI para as estimativas de tamanho e tempo, os quais já eram calculados no PSP
1;
dados sobre a eficiência na remoção de defeitos.
36
Tabela 2.8 – Sumário do Plano de Projeto – PSP 2
Desenvolvedor José da Silva Data 15/04/2009
Projeto Fórmulas de estatística Programa 12
Linguagem C
Planejado Real To Date
LOCs/hora 24,6 26,6 23,8
Tempo planejado 451 5256,8
Tempo real
448,5 6500,7
CPI
0,81
% de LOCs R 2,4 3,1 0,6
% de LOCs NR 5,4 7,2 5,8
Defeitos de teste/KLOC 13,5 5 12,8
Defeitos/KLOC 81,1 90,5 81,8
Rendimento 0,5 0,8 0,5
Indicadores sobre
remoção de defeitos Planejado Real To Date
Defeitos/hora- Revisão
de projeto - 5,6 5,6
Defeitos/hora- Revisão
de código - 6 6
Defeitos/hora-
Compilação 12,1 6,6 11,7
Defeitos/hora
- Teste 2,3 1,1 2,2
DRL (revisão de
código/teste de unidade) - 5 0,3
DRL (compilação/teste
de unidade) 3,4 3 3,5
Observa-se que alguns campos do Sumário do Plano de Projeto estão preenchidos com
"-", pois não há dados que fundamentem seu planejamento até o momento de criação do
sumário para o programa 12. Em resumo, a partir do conteúdo apresentado pode-se concluir
que os principais elementos do PSP 2 são:
seis scripts: um para guiar no emprego do PSP 2, três para guiar as fases do PSP, um
para guiar as revisões de projeto e outro para as revisões de código;
três formulários: Sumário do Plano de Projeto, checklist para revisões de projeto e
checklist para revisões de código.
+ campos do PSP 1, incluindo o planejamento de defeitos por fase
37
Nível 2.1
O PSP 2.1 tem como foco de atuação a fase de projeto do PSP. Além de manter os
objetivos do PSP 2, o PSP 2.1 tem como objetivos específicos (HUMPHREY, 2005):
reduzir o número de defeitos nos projetos;
prover critérios para determinar se um projeto está completo;
prover uma estrutura consistente para documentar e verificar os projetos.
Para atingir tais objetivos, o PSP 2.1 fornece modelos para especificação dos projetos,
a saber:
a) modelo de especificação operacional - consiste em um formulário simplificado para
descrever o comportamento operacional do programa. Este modelo registra, de
maneira estruturada, informações similares às do diagrama de casos de uso da Unified
Modeling Language (UML);
b) modelo de especificação funcional - consiste em um formulário para descrever as
interfaces e lógicas dos métodos de cada classe. Este modelo registra, de maneira
estruturada, informações similares às do diagrama de classes da UML;
c) modelo de especificação de estados - consiste em um formulário para descrever o
estados de um sistema ou parte dele. Este modelo registra, de maneira estruturada,
informações similares às do diagrama de estados da UML;
d) modelo de especificação lógica - consiste em um formulário para descrever a lógica
dos programas por meio de pseudocódigo.
Observa-se que os modelos de especificação devem ser tratados como um
complemento aos modelos gráficos que representam o comportamento ou estrutura dos
sistemas. Portanto, é importante manter a consistência entre as representações empregadas.
Além destes modelos de especificação de projeto, o PSP 2.1 fornece também versões
mais detalhadas para o script e o checklist de revisão de projeto.
Por fim, como todos os demais níveis, o PSP 2.1 estabelece o Sumário do Plano de
Projeto do PSP 2.1, o qual não será apresentado, pois inclui apenas 3 informações obtidas em
níveis anteriores, sendo elas: Appraisal como % do COQ total, Failure COQ, A/FR.
Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais
elementos do PSP 2.1 são:
38
cinco scripts: um para guiar os desenvolvedores na utilização do PSP 2.1, três para
guiá-los em cada fase do PSP e um para guiar as revisões de projeto.
seis formulários: Sumário do Plano de Projeto, checklist para revisões de projeto;
quatro modelos de especificação de projeto.
2.4 Trabalhos relacionados
Nos últimos anos, estudos vêm apontando que as habilidades pessoais de cada membro
de equipe são cruciais para o sucesso dos projetos de software (BADDOO; HALL, 2003;
JIRACHIEFPATTANA, 2012). Diante disso, trabalhos vêm propondo mecanismos para a
melhoria da maturidade dos recursos humanos envolvidos nos projetos. Em geral, tais
mecanismos devem ser empregados pelos próprios indivíduos durante suas rotinas de
trabalho, de modo a estimular o autoconhecimento e posterior melhoria da produtividade e
qualidade do trabalho desenvolvido.
Uma das vertentes das pesquisas realizadas visa propor ferramentas de apoio à
melhoria de aspectos específicos, relacionados ao aumento da produtividade dos recursos
humanos ou à melhoria da qualidade dos produtos de software desenvolvidos. Quanto ao
aumento da produtividade dos recursos humanos, a maioria dos trabalhos oferece ferramentas
de suporte ao registro do tempo gasto pelos membros de equipe para desenvolver suas
atividades pessoais (EPIFORGE SOFTWARE, 2012; RESPONSIVE SOFTWARE, 2012).
Em relação à melhoria da qualidade dos produtos de software, alguns trabalhos propõem
sistemas computacionais de apoio às revisões de projeto e código (BRYKCZYNSKI;
MEESON; WHEELER, 1994; KLEINE, 2011), enquanto outros propõem recursos para
documentação de defeitos encontrados (BUGZILLA, 2012; EDGEWALL, 2012; MANTIS,
2012). Apesar do grande potencial dessas propostas, muitas vezes não se consegue extrair
todos os seus benefícios, uma vez que são empregadas de maneira isolada, sem a integração
com outros mecanismos que poderiam apoiar a obtenção de informações mais amplas e
relevantes. Diante dessa situação, é muito comum que dados registrados não sejam
devidamente aproveitados.
Além das pesquisas com objetivos mais específicos, vários trabalhos visam a melhoria
de todo o processo pessoal de desenvolvimento de software. Neste contexto, diversos
trabalhos vêm propondo sistemas computacionais de apoio ao emprego do PSP (JOHNSON et
al., 2005; NAZIR; YUSOF, 2005; SHIN; CHOI; BAIK, 2007; SISON et al., 2005; TUMA
39
SOLUTIONS, 2012; YUAN et al., 2005). No entanto, a maioria das propostas não oferece
apoio a todos os níveis do PSP ou, quando oferecem, não apoiam a aplicação de elementos
importantes, como a medição do tempo de correção de defeitos e a geração de indicadores do
processo. Além disso, durante toda a revisão bibliográfica não foram encontradas ferramentas
computacionais que apoiem o emprego do PSP no contexto de gerenciamento de projetos, o
que impede que os gerentes de projetos possam obter informações importantes sobre os
membros de equipe a partir dos dados coletados individualmente. Outro problema decorrente
disso é a necessidade de os membros de equipe cadastrarem em um sistema externo os dados
sobre suas atividades pessoais, que muitas vezes já estão disponíveis no ambiente de apoio ao
gerenciamento de projetos.
Diante desse cenário, atesta-se a originalidade e a importância deste trabalho como
uma forma de apoiar a melhoria da maturidade pessoal e fornecer informações importantes
para as tomadas de decisão dos gerentes de projetos.
2.5 Considerações finais
Neste capítulo foi apresentada a arquitetura originalmente estabelecida para o
desenvolvimento do SAGP que foi expandido neste trabalho para incorporar técnicas de apoio
à capacitação individual. Foi também apresentado um estudo sobre o PSP, o qual abordou as
suas características gerais, bem como uma descrição de cada um de seus níveis. Além disso,
foi apresentado um panorama geral sobre os trabalhos relacionados à melhoria da maturidade
pessoal no contexto de desenvolvimento de software.
Com isso, foi possível observar a complexidade do PSP, a partir do qual se tem o
estabelecimento de passos bem fundamentados capazes de direcionar o aperfeiçoamento
individual dos profissionais. Por fim, cabe salientar que o estudo de trabalhos relacionados
permitiu constatar a originalidade e a contribuição deste trabalho.
40
CAPÍTULO 3 – Ferramenta de Apoio ao PSP
3.1 Considerações iniciais
O objetivo deste capítulo é apresentar os requisitos funcionais identificados a partir
dos estudos realizados, os quais foram contemplados pelo componente incorporado ao SAGP
de modo a apoiar o emprego do PSP pelos membros das equipes de projetos, bem como
fornecer informações importantes que possam auxiliar os gerentes de projetos em suas
tomadas de decisões. Além disso, este capítulo apresenta a arquitetura de software do SAGP
estendida para incorporar os requisitos identificados. Por fim, é apresentado o funcionamento
do componente construído.
Na seção 3.2 são apresentados os requisitos funcionais identificados para o
componente de apoio ao PSP. Na seção 3.3 é apresentada a arquitetura de software do SAGP
estendida. Na seção 3.4 é apresentado o funcionamento do componente construído. Por fim,
na seção 3.5, são apresentadas as considerações finais deste capítulo.
3.2 Requisitos identificados
A partir do estudo realizado em torno do PSP, foram identificados os requisitos
funcionais a serem contemplados pelo componente de apoio ao PSP, os quais estão descritos
nas próximas subseções. Observa-se que a apresentação dos requisitos está organizada em
sete categorias: uma geral e outras seis referentes a cada nível do PSP. A categoria geral reúne
os requisitos relacionados a todos os níveis, enquanto as outras seis reúnem os requisitos
necessários para atender especificamente a cada nível do PSP considerando o ambiente de
gerenciamento de projetos.
41
Os requisitos foram representados por meio do diagrama de casos de uso sendo que,
para cada caso de uso, uma breve descrição é apresentada. Observa-se que os cenários para
especificação detalhada dos casos de uso são descritos no Apêndice A segundo o modelo de
especificação operacional proposto pelo nível 2.1 do PSP, no qual são declaradas as seguintes
informações:
dados gerais: nome do autor, data de autoria e linguagem;
número do cenário;
objetivo do cenário;
ator de cada passo;
número de cada passo;
ação de cada passo;
comentários, onde são registrados resultados, condições de exceção ou outras
informações úteis.
Em relação à especificação dos requisitos, observa-se que:
cenários alternativos oriundos de ações de validação mal sucedidas não foram
apresentados por se tratarem apenas da emissão de mensagens de erro, embora tenham
sido implementados;
todos os dados cadastrados podem também ser consultados, alterados e excluídos.
Entretanto, apenas os cenários de cadastro são apresentados, uma vez que as consultas,
alterações e exclusões ocorrem de maneira similar ao cadastro, apesar das
particularidades referentes às validações específicas de cada operação.
Para a elaboração do diagrama de casos de uso e do modelo de especificação
operacional foram definidos 4 possíveis atores:
Usuário de nível 1 - usuários que tem acesso de nível 1 a um projeto do SAGP;
Usuário de nível 2 - usuários que tem acesso de nível 2 a um projeto do SAGP;
Usuário de nível 3 - usuários que tem acesso de nível 3 a um projeto do SAGP;
Gerente de projeto - usuário de nível 3 que cadastrou o projeto.
42
3.2.1 Requisitos gerais
O diagrama de casos de uso ilustrado na Figura 3.1 representa o conjunto de operações
que o sistema deve permitir que os usuários executem. Na Tabela 3.1 é apresentada uma
descrição resumida de cada caso de uso.
Figura 3.1 - Diagrama de casos de uso - Requisitos gerais
3.2.2 Requisitos referentes ao PSP 0
O diagrama de casos de uso ilustrado na Figura 3.2 representa o conjunto de operações
que o sistema deve permitir que os usuários executem, tendo como base o PSP 0. Na Tabela
3.2 é apresentada uma descrição resumida de cada caso de uso.
43
Tabela 3.1 – Descrição resumida dos casos de uso – Requisitos gerais
ID Caso de uso Descrição resumida
1 Registrar interesse em empregar o PSP na
gestão de projetos
Este caso de uso permite que, no momento de
cadastro de um projeto, o gerente de projetos
registre se deseja ou não empregar informações
oriundas do PSP durante a gestão
2 Registrar nível do PSP a ser empregado em
cada projeto
Este caso de uso permite que, no primeiro acesso a
um projeto, o usuário registre se deseja empregar o
PSP no projeto e qual será o nível empregado.
Com isso, são habilitadas as ferramentas de apoio
à aplicação do nível selecionado
3 Apresentar instruções do PSP Este caso de uso permite que qualquer usuário que
empregue o PSP possa consultar instruções sobre
o seu uso
4 Apresentar sumário de plano de projeto Este caso de uso permite consultar o sumário do
plano de projeto referente a cada programa
construído em um projeto, o qual é gerado
automaticamente a partir da reunião e organização
dos dados coletados ao longo do PSP
5 Registrar conclusão de projeto Este caso de uso permite que os usuários do PSP
registrem a conclusão do projeto quando
completarem suas atividades
6 Gerar relatório Este caso de uso permite gerar relatórios em PDF
sobre todas as informações oriundas do emprego
do PSP
7 Exibir indicadores de membros da equipe Este caso de uso permite que usuários de nível 2
acessem uma página para apresentação de
indicadores de membros de equipe oriundos do
uso pessoal do PSP, os quais podem ser
relacionados à qualidade ou tempo de execução de
atividades. Podem ser visualizados indicadores
individuais ou de um conjunto de membros
44
Figura 3.2 - Diagrama de casos de uso - Requisitos referentes ao PSP 0
45
Tabela 3.2 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 0
ID Caso de uso Descrição resumida
8 Cadastrar programas a serem construídos Este caso de uso permite que os usuários do PSP
cadastrem os programas a serem construídos,
registrando o nome do programa, a linguagem de
programação usada e a atividade do projeto à qual
o programa se refere. Observa-se que os
programas cadastrados referem-se àqueles que
cada membro deverá desenvolver para cumprir as
atividades do projeto às quais está alocado
9 Apresentar atividades a serem realizadas no
projeto
Este caso de uso permite que, no momento de
cadastro de um programa, sejam apresentados os
dados sobre as atividades do projeto às quais o
usuário está alocado, facilitando a identificação
dos programas que ele deverá desenvolver para
cumprir seu papel no projeto
10 Cadastrar atividades pessoais Este caso de uso permite cadastrar as atividades
envolvidas na construção de cada programa
11 Registrar estimativa de tempo das atividades Este caso de uso permite registrar o tempo total
estimado para o desenvolvimento das atividades
envolvidas na construção de cada programa
12 Disponibilizar o Time Recording Log Este caso de uso permite a coleta de dados de
tempo das atividades pessoais por meio de um
mecanismo que registra o início das atividades, as
interrupções realizadas e o término da contagem
do tempo
13 Apresentar o Time Recording Log Este caso de uso permite que os usuários do PSP
consultem os dados coletados pelo Time Recording
Log para cada programa cadastrado
14 Disponibilizar o Defect Recording Log Este caso de uso permite registrar dados sobre os
defeitos encontrados nos programas por meio de
um formulário
15 Enviar um programa para teste Este caso de uso permite que os usuários que
empregam o PSP no projeto acessem uma página
para seleção de programas que desejam enviar
para teste, sendo necessário definir o arquivo
referente a cada programa. Feito isso, o sistema faz
upload do arquivo e o disponibiliza para os
membros da equipe do projeto responsáveis por
atividades de teste
16 Apresentar um programa para teste Este caso de uso permite que qualquer usuário com
o papel de testador no projeto possa acessar uma
página com os programas que estão aguardando o
início de testes. Ao selecionar um dos programas,
o usuário torna-se o responsável pelos seus testes e
o programa não é mais apresentado a outros
testadores
17 Registrar dados sobre testes realizados Este caso de uso permite registrar defeitos
encontrados em programas recebidos para testes.
Os dados sobre os defeitos são registrados entre as
estatísticas do autor do programa
46
3.2.3 Requisitos referentes ao PSP 0.1
O diagrama de casos de uso ilustrado na Figura 3.3 representa o conjunto de operações
que o sistema deve permitir que os usuários executem, tendo como base o PSP 0.1. Na Tabela
3.3 é apresentada uma descrição resumida de cada caso de uso.
Figura 3.3 - Diagrama de casos de uso - Requisitos referentes ao PSP 0.1
Tabela 3.3 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 0.1
ID Caso de uso Descrição resumida
18 Cadastrar padrão de codificação Este caso de uso permite que os usuários do PSP
cadastrem o padrão de codificação que pretendem
seguir para cada linguagem de programação
19 Registrar dados obtidos com as medições de
software
Este caso de uso permite cadastrar os dados
obtidos com as medições de cada programa
construído
20 Cadastrar dados no Process Improvement
Proposal
Este caso de uso permite cadastrar propostas de
melhoria no processo de acordo com o formulário
PIP
3.2.4 Requisitos referentes ao PSP 1
O diagrama de casos de uso, ilustrado na Figura 3.4, representa o conjunto de
operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 1.
Na Tabela 3.4 é apresentada uma descrição resumida de cada caso de uso.
47
Figura 3.4 - Diagrama de casos de uso - Requisitos referentes ao PSP 1
Tabela 3.4 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1
(continua)
ID Caso de uso Descrição resumida
21 Cadastrar proxy Este caso de uso permite cadastrar o proxy a ser
empregado para cada linguagem de programação
utilizada
22 Cadastrar categorias funcionais de proxies Este caso de uso permite cadastrar as categorias
funcionais de cada proxy cadastrado
23 Registrar tamanho dos proxies em
programas já construídos
Este caso de uso permite registrar o tamanho dos
proxies em programas já construídos, de modo a
criar uma base histórica
24 Apresentar tabelas de tamanho relativo Este caso de uso permite gerar automaticamente a
tabela de tamanho relativo, realizando os cálculos
a partir dos dados históricos cadastrados
25 Apresentar avaliação do proxy definido Este caso de uso permite executar
automaticamente a avaliação do proxy, realizando
os cálculos de correlação e significância a partir
dos dados históricos cadastrados
26 Registrar dados no Size Estimating Template Este caso de uso permite registrar dados sobre as
estimativas das partes que comporão os programas
a serem construídos, de acordo com o Size
Estimating Template
48
Tabela 3.4 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1
(conclusão)
ID Caso de uso Descrição resumida
27 Apresentar estimativas pessoais O sistema permite a geração automática das
estimativas de tempo e tamanho dos programas a
serem construídos, realizando os cálculos a partir
dos dados registrados no Size Estimating Template
28 Registrar tempo estimado para cada
atividade seguindo restrições do PSP 1
O sistema permite o registro de tempo estimado
para cada atividade pessoal, de acordo com o
proposto no PSP 1
29 Cadastrar dados no Test Report Template O sistema permite o cadastro de dados sobre os
testes realizados, de acordo com o Test Report
Template
3.2.5 Requisitos referentes ao PSP 1.1
O diagrama de casos de uso, ilustrado na Figura 3.5, representa o conjunto de
operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 1.1.
Na Tabela 3.5 é apresentada uma descrição resumida de cada caso de uso.
Figura 3.5 - Diagrama de casos de uso - Requisitos referentes ao PSP 1.1
49
Tabela 3.5 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 1.1
ID Caso de uso Descrição resumida
30 Registrar tempo estimado para cada
atividade seguindo restrições do PSP 1.1
Este caso de uso permite registrar o tempo
estimado para cada atividade pessoal, de acordo
com o proposto no PSP 1.1
31 Disponibilizar o Task Planning Template Este caso de uso permite empregar o Task
Planning Template. Para tanto, o usuário deve
apenas definir a ordem de execução das atividades
pessoais, sendo o restante do template gerado
automaticamente
32 Apresentar o Schedule Planning Template Este caso de uso permite gerar automaticamente o
Schedule Planning Template a partir dos dados do
Task Planning Template e dos períodos de
alocação dos usuários a cada atividade do projeto
33 Registrar conclusão de atividade Este caso de uso permite registrar a conclusão das
atividades pessoais, de modo a viabilizar a
atualização automática do valor de VP no
Schedule e no Task Planning Template
34 Apresentar o CPI Este caso de uso permite executar
automaticamente o cálculo do valor do CPI a partir
dos dados cadastrados
3.2.6 Requisitos referentes ao PSP 2
O diagrama de casos de uso ilustrado na Figura 3.6 representa o conjunto de operações
que o sistema deve permitir que os usuários executem, tendo como base o PSP 2. Na Tabela
3.6 é apresentada uma descrição resumida de cada caso de uso.
Figura 3.6 - Diagrama de casos de uso - Requisitos referentes ao PSP 2
50
Tabela 3.6 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 2
ID Caso de uso Descrição resumida
35 Cadastrar o checklist de revisão de código Este caso de uso permite cadastrar o checklist de
revisão de código que deve ser empregado para
cada linguagem de programação
36 Registrar verificações no checklist de
revisão de código
Este caso de uso permite registrar as verificações
já realizadas no código de cada programa
cadastrado, de modo a facilitar o acompanhamento
das revisões
37 Registrar verificações no checklist de
revisão de projeto
Este caso de uso permite registrar as verificações
já realizadas no projeto de cada programa
cadastrado, de modo a facilitar o acompanhamento
das revisões. Observa-se que o checklist de revisão
de projeto segue o padrão proposto pelo PSP
38 Apresentar indicadores de qualidade Este caso de uso permite executar
automaticamente os cálculos para geração dos
indicadores de qualidade propostos pelo PSP, os
quais são exibidos numérica e graficamente na
forma de um painel
3.2.7 Requisitos referentes ao PSP 2.1
O diagrama de casos de uso ilustrado na Figura 3.7 representa o conjunto de operações
que o sistema deve permitir que os usuários executem, tendo como base o PSP 2.1. Na Tabela
3.7 é apresentada uma descrição resumida de cada caso de uso.
Figura 3.7 - Diagrama de casos de uso - Requisitos referentes ao PSP 2.1
Tabela 3.7 – Descrição resumida dos casos de uso – Requisitos referentes ao PSP 2.1
ID Caso de uso Descrição resumida
39 Disponibilizar modelos de especificação de
projeto
Este caso de uso permite cadastrar os quatro
modelos de especificação de projeto para cada
programa cadastrado, sendo eles: modelo de
especificação operacional, modelo de
especificação funcional, modelo de especificação
de estados e modelo de especificação lógica
40 Registrar verificações no checklist de
revisão de projeto detalhado
Este caso de uso permite registrar as verificações
já realizadas no projeto de cada programa
cadastrado, de modo a facilitar o acompanhamento
das revisões. Observa-se que no PSP 2.1 são
incluídos dois itens em relação ao checklist de
revisão de projeto do PSP 2
51
3.3 Extensão da arquitetura de software do SAGP
Para incorporar as novas funções de apoio ao emprego do PSP, a arquitetura original
do SAGP foi estendida, recebendo um novo componente, denominado “Gestão pessoal”. Na
Figura 3.8, é ilustrada a arquitetura do SAGP estendida, mostrando os componentes originais
e os módulos alterados, bem como o novo componente criado.
No componente “Controle de acesso”, foram alterados os módulos “Gerenciador de
projetos” e “Controlador de conteúdo”. O “Gerenciador de projetos”, antes responsável
apenas pelo registro de dados gerais sobre os projetos cadastrados, passa agora a registrar
também se o gerente de projetos optou por empregar o PSP em cada projeto. Já o
“Controlador de conteúdo”, antes responsável apenas pelo registro e controle dos níveis de
acesso dos usuários aos projetos, passa agora a registrar também o nível do PSP empregado
pelos usuários em cada projeto.
A seguir, os módulos do componente “Gestão pessoal” são descritos detalhadamente:
1. Gerenciador de atividades pessoais: Este módulo recebe dados do "Gerenciador de
stakeholders" sobre as atividades às quais cada membro da equipe está alocado e as
apresenta aos membros que estiverem empregando o PSP no projeto para possibilitar a
definição e cadastro das atividades pessoais, cuja conclusão pode ser posteriormente
registrada pelos usuários. Além disso, este módulo recebe dados do "Gerenciador de
programas" para vincular cada atividade pessoal aos programas que serão construídos
por meio delas;
2. Gerenciador de programas: Este módulo permite que cada desenvolvedor cadastre
dados gerais sobre os programas que desenvolverá e recebe dados do "Gerenciador de
atividades pessoais" para vincular os programas às atividades envolvidas em seu
desenvolvimento. Além disso, este módulo registra dados nos formulários do PSP
sobre os defeitos encontrados e testes realizados e recebe dados do "Gerenciador de
stakeholders" para identificar quais recursos humanos poderão executar as atividades
de teste. A partir disso, o "Gerenciador de programas" apresenta esses programas a
estes recursos, que podem registrar, nos formulários do PSP, os dados sobre os
defeitos encontrados, os quais são lançados entre os registros do autor do programa.
Por fim, este módulo permite cadastrar dados sobre as medições do tamanho dos
programas, bem como o checklist de revisão de código;
52
Figura 3.8 - Diagrama arquitetural do SAGP estendido a partir de ESTECA (2010)
3. Gerenciador de estimativas: Este módulo recebe dados do "Gerenciador de
atividades pessoais" e do "Gerenciador de programas" para gerar estimativas de
tempo, tamanho e número de defeitos dos programas de acordo com o nível do PSP
empregado pelo usuário em cada projeto. Além disso, para viabilizar o emprego do
método PROBE e do cálculo dos intervalos de previsão de tamanho e tempo, este
módulo permite que os usuários cadastrem o proxy que utilizarão, bem como suas
categorias funcionais e o tamanho mensurado nos programas já construídos. A partir
disso, todos os cálculos do PROBE e dos intervalos de previsão são efetuados
automaticamente. Por fim, o "Gerenciador de estimativas" fornece aos usuários o Task
53
Planning Template e o Schedule Planning Template para auxiliar na gestão pessoal do
tempo;
4. Gerador de relatórios pessoais: Este módulo recebe dados do "Gerenciador de
atividades pessoais", do "Gerenciador de programas", do "Gerenciador de estimativas"
e do "Gerador de painel", reunindo todas as informações necessárias para gerar os
sumários de plano de projeto e outros relatórios sobre cada programa construído, de
acordo com o nível do PSP empregado nos projetos;
5. Gerador de painel: Este módulo recebe dados do "Gerenciador de atividades
pessoais", do "Gerenciador de programas" e do "Gerenciador de estimativas" para
gerar todos os indicadores propostos pelo PSP de acordo com seus seis níveis. Após
gerar tais indicadores, eles são disponibilizados em um painel de acesso restrito a
membros autorizados, podendo ser visualizados de maneira ordenada por parâmetros
escolhidos pelos usuários;
6. Gerenciador de padrões: Este módulo permite que os usuários registrem e atualizem
os padrões de codificação e de tipos de defeitos;
7. Apresentador de instruções: Este módulo mantém o registro das instruções
fornecidas pelo PSP e as apresenta aos usuários do sistema para auxiliá-los no
preenchimento de formulários e no emprego de indicadores fornecidos pelo PSP;
8. Registrador de especificações de projeto: Este módulo recebe dados do
"Gerenciador de programas" sobre cada programa a ser desenvolvido pelos recursos
humanos e disponibiliza os formulários de especificação de projeto propostos pelo
PSP, os quais podem ser registrados, alterados e consultados pelos autores dos
programas;
9. Registrador de sugestões de melhoria: Este módulo permite que os usuários
registrem sugestões de melhoria ao processo pessoal adotado para o desenvolvimento
de software, as quais podem ser consultadas apenas por seus autores.
3.4 Funcionamento do componente de apoio ao PSP
Nesta seção é descrito o funcionamento do componente de apoio ao PSP
implementado. Na subseção 3.4.1 são apresentadas as funções que viabilizaram a integração
do componente ao ambiente do SAGP. Nas subseções 3.4.2 a 3.4.7 são apresentadas as
54
funções referentes a cada nível do PSP. Por fim, na subseção 3.4.8 são apresentados os
indicadores gerados aos gerentes de projeto por meio do emprego individual do PSP.
3.4.1 Integração do PSP ao SAGP
O primeiro passo para empregar o PSP como apoio às atividades de gerenciamento de
projetos deve ser dado no momento da criação dos projetos, quando é necessário declarar o
interesse em utilizá-lo. Feito isso, ao acessar o projeto no SAGP, os usuários de nível 2 e 3,
bem como os gerentes de projetos, poderão visualizar os indicadores gerados por meio das
informações oriundas do uso do PSP pelos membros da equipe.
Já o emprego pessoal do PSP pode ser feito por qualquer usuário interessado e em
qualquer projeto. Para tanto, no primeiro acesso aos projetos, o usuário deve declarar se tem
ou não interesse em utilizar o PSP. Além disso, se tiver interesse em empregá-lo, o usuário
deve selecionar o nível do PSP desejado, sendo possível utilizar apenas níveis já empregados
em projetos anteriores ou um nível acima do mais alto já empregado, como forma de
comprovar maturidade para uso do nível selecionado. Observa-se que um nível só é
considerado como já empregado em um projeto após o usuário declarar a sua conclusão.
Ao optar por empregar o PSP, no menu principal do SAGP é exibido um item
adicional, conforme ilustrado na Figura 3.9, por meio do qual o usuário poderá acessar sua
Área exclusiva, onde somente ele terá acesso para fazer uso das ferramentas de apoio ao PSP
disponíveis. É importante destacar que na Área exclusiva os usuários definirão os programas
que deverão desenvolver e as atividades pessoais envolvidas na construção desses programas.
Por sua vez, os programas serão definidos com base nas atividades do projeto às quais os
usuários estão alocados.
55
Figura 3.9 - Menu principal do SAGP com destaque para os itens relacionados ao PSP
3.4.2 Nível 0
Quando o usuário acessa sua Área exclusiva, é exibida a página inicial do sistema,
ilustrada na Figura 3.10, a qual apresenta apenas alguns dados gerais sobre sua experiência no
PSP. Ainda na Figura 3.10, é possível visualizar também as opções que o menu principal
oferece ao usuário. Como se pode notar, a terminologia usada no sistema é completamente
alinhada ao PSP, o que torna mais fácil o emprego por usuários que já conhecem o processo e,
por outro lado, facilita o aprendizado dos conceitos por usuários iniciantes.
56
Figura 3.10 - Página inicial da Área exclusiva - Nível 0
Seguindo as diretrizes propostas pelo PSP, o emprego de todas as funções de apoio
disponibilizadas no SAGP é baseado nos programas que o usuário cadastra.
O cadastro de programas é feito por meio da página ilustrada na Figura 3.11. Os
únicos dados solicitados são o título do programa, a atividade do projeto ao qual se relaciona e
a linguagem em que será desenvolvido, a qual pode ser selecionada caso já tenha sido
utilizada anteriormente, agilizando o preenchimento do cadastro. Outra facilidade que o
sistema fornece é a apresentação das atividades do projeto às quais o usuário está alocado, o
que o direciona na definição dos programas que deverá construir. Ao passar o cursor do
mouse sobre o nome de uma atividade, informações sobre ela são exibidas, conforme é
ilustrado na Figura 3.11.
57
Figura 3.11 - Página para cadastro de programas
Os programas registrados podem ser consultados, alterados e excluídos por meio de
uma única página, ilustrada na Figura 3.12, que possibilita também registrar a conclusão dos
programas. Esta forma de execução das operações evita a necessidade de troca de páginas, o
que facilita o trabalho dos usuários do sistema.
Figura 3.12 - Página para gerenciamento de programas
Após cadastrar um ou mais programas, o usuário deve definir as atividades envolvidas
na construção de cada um. Para tanto, primeiramente deve ser selecionado o programa para o
58
qual é desejado definir as atividades, o que é feito pela página ilustrada na Figura 3.13. Ao
selecionar o programa, é exibida a página de definição de atividades, ilustrada na Figura 3.14,
a partir da qual o usuário pode também importar atividades, tornando o cadastro mais rápido.
Figura 3.13 - Página para seleção de programas
Figura 3.14 - Página para definição de atividades
59
As operações de consulta, alteração, exclusão e registro de conclusão das atividades
são feitas por uma página de gerenciamento de atividades semelhante à de gerenciamento de
programas, já apresentada na Figura 3.12.
Para registrar os dados sobre o tempo de execução das atividades, o usuário deve
selecionar o programa sobre o qual irá atuar e, em seguida, a atividade que iniciará a
execução. Feito isso, o sistema abrirá, em uma janela de pop-up, o Time Recording Log, cuja
operação é especificada no diagrama de estados da Figura 3.15. Observa-se que as figuras
3.16a, 3.16b e 3.16c representam as telas associadas aos estados que as referenciam entre
parênteses.
Figura 3.15 – Diagrama de estados representando o funcionamento do Time Recording Log
Figura 3.16 – Telas associadas aos estados do Time Recording Log
60
Para empregar o Defect Recording Log, o usuário deve inicialmente selecionar o
programa para o qual deseja registrar os defeitos. Feito isso, o sistema exibirá a página
ilustrada na Figura 3.17, que apresenta os dados sobre os defeitos já registrados e permite
registrar dados de novos defeitos com o auxílio de um cronômetro controlado pelos botões
"Play/Pause" e "Limpar", bem como por teclas de atalho. Ao encontrar um defeito e iniciar
sua correção, o usuário deve iniciar a marcação de tempo pelo cronômetro. Assim que
concluir a correção, o usuário deve interromper o cronômetro e registrar os dados solicitados,
podendo, logo após o preenchimento, iniciar novamente o cronômetro para registrar o tempo
de correção de outro defeito.
Figura 3.17 – Defect Recording Log
O Defect Recording Log oferecido pelo sistema permite que o usuário interrompa a
correção de um defeito A para corrigir um defeito B e depois retorne à correção do defeito A.
Para tanto, antes de submeter o formulário com os registros de cada rodada, basta que o
usuário digite um mesmo número natural maior que zero no campo “Identificador” nas
rodadas referentes a um mesmo defeito. Deste modo, o sistema registra as várias rodadas de
mesmo identificador como um único defeito, cujo tempo de correção é dado pela soma do
tempo das rodadas. No exemplo da Figura 3.17, as rodadas 2 e 4 serão registradas como um
61
único defeito com tempo de correção de 15 minutos, enquanto as demais serão registradas
cada uma como um defeito.
Os autores de programas que empregam o PSP também podem enviar seus programas
para que outros membros de equipe do projeto realizem testes. Na Figura 3.18, é apresentado
um diagrama de atividades que especifica a sequência de interações relacionadas ao envio de
programas para testes. Neste diagrama, interagem o autor de um programa que emprega o
PSP, o sistema, e um testador, que pode ser qualquer membro da equipe do projeto
responsável pela realização de testes. Observa-se que nas Figuras 3.19 e 3.20 são
representadas as telas associadas às interações que as referenciam entre parênteses no
diagrama de atividades. Cabe destacar que mesmo os testadores que não empregam o PSP
usam o Defect Recording Log para declarar os defeitos encontrados nos programas, uma vez
que a página para recebimento de programas para teste é acessível pelo menu principal do
SAGP na área de conhecimento de Qualidade, não dependendo, portanto, de acesso à Área
exclusiva do PSP. Os dados sobre os defeitos encontrados pelos testadores são registrados
entre os dados dos autores desses programas, de modo a viabilizar a geração de indicadores de
qualidade.
Figura 3.18 – Diagrama de atividades referente ao envio de programas para teste
62
Figura 3.19 – Página de envio de programa para teste
Figura 3.20 – Página para recebimento de programa para teste
Sempre que solicitado pelos usuários, todas as informações registradas sobre os
programas são reunidas e organizadas para a geração do Sumário do Plano de Projeto do PSP
0, ilustrado na Figura 3.21, o que permite ao usuário fazer uma análise geral dos dados
obtidos. Além da geração do Sumário do Plano de Projeto, nos seis níveis do PSP é possível
exportar todos os dados sobre os programas para relatórios em formato PDF, o que facilita a
análise, acompanhamento e distribuição das informações.
63
Figura 3.21 – Sumário do Plano de Projeto - PSP 0
Por fim, o sistema disponibiliza também os scripts do PSP 0 e mensagens de ajuda
oferecidas pelos links “Saiba mais”, de modo a guiar os usuários ao longo do PSP 0 e a
auxiliá-los no preenchimento de formulários.
3.4.3 Nível 0.1
Ao acessar a Área exclusiva empregando o nível 0.1 do PSP, as primeiras mudanças
podem ser notadas já no menu principal e na página inicial, conforme ilustrado na Figura
3.22. Em relação ao menu, são incluídos os itens referentes ao nível 0.1 do PSP. Quanto à
página inicial, são disponibilizados os indicadores de produtividade e densidade de defeitos
para cada linguagem empregada pelo usuário. A produtividade é dada em número de linhas de
código por hora e seu cálculo é feito usando os dados de tamanho que o usuário passa a
registrar no nível 0.1. Já a densidade de defeitos é dada em número de defeitos produzido por
KLOC e seu cálculo baseia-se nos registros do Defect Recording Log.
64
Figura 3.22 - Página inicial da Área exclusiva - Nível 0.1
O primeiro item disponibilizado no menu é o cadastro de propostas no Process
Improvement Proposal, feito por meio da página ilustrada na Figura 3.23. As consultas às
propostas cadastradas podem ser feitas por palavras ou parte de palavras constantes nos
campos "Processos relacionados", "Descrição do problema" e "Descrição da proposta".
65
Figura 3.23 - Página de cadastro de propostas no Process Improvement Proposal
No nível 0.1 é disponibilizado também o cadastro de padrões de codificação, que deve
ser feito por meio da página ilustrada na Figura 3.24, que solicita o nome da linguagem para a
qual o padrão será cadastrado e fornece o campo para o upload do arquivo contendo o padrão
definido. Além disso, para auxiliar o entendimento dos usuários, essa página fornece
exemplos reais de padrões de codificação propostos para as linguagens C, Java e PHP.
Outra função disponibilizada nesse nível é o registro e consulta do tamanho de
programas, que devem ser feitos pela página ilustrada na Figura 3.25 após a seleção do
programa desejado. Observa-se que a obtenção e classificação dos dados de tamanho de
programas podem ser facilitadas com o uso de ferramentas de comparação de código
gratuitamente encontradas na internet para download ou acesso online.
66
Figura 3.24 - Página de cadastro de padrão de codificação
Figura 3.25 - Página para registro e consulta do tamanho de programas
67
Ainda no nível 0.1, o usuário pode consultar a densidade de defeitos por programa,
sendo possível visualizar o número de defeitos produzido por KLOC em cada fase de
desenvolvimento de cada programa. A página exibida ao usuário contempla os mesmos dados
relativos à densidade de defeitos apresentados na página inicial da área exclusiva (vide Figura
3.22).
Por fim, o usuário pode ainda consultar os scripts fornecidos pelo nível 0.1 do PSP,
bem como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao
ilustrado na Figura 3.21, o qual acrescenta apenas as informações sobre o tamanho dos
programas em relação ao sumário do PSP 0.
3.4.4 Nível 1
O suporte oferecido ao nível 1 do PSP contribui para otimizar a efetivação de tarefas a
serem executadas pelos usuários, uma vez que automatiza uma quantidade significativa de
cálculos complexos e organiza um grande volume de dados de maneira transparente ao
usuário, que, com isso, pode concentrar-se em questões relacionadas ao desenvolvimento de
programas, fornecendo dados facilmente obtidos.
Conforme proposto pelo PSP, o primeiro passo para empregar o nível 1 consiste em
definir um proxy para cada linguagem de programação utilizada, o que pode ser feito pela
página ilustrada na Figura 3.26. As operações de consulta, alteração e exclusão dos proxies
são feitas por uma página de gerenciamento de proxies semelhante à de gerenciamento de
programas, já apresentada na Figura 3.12.
Figura 3.26 - Página para definição de proxy
Após a definição do proxy, devem ser estabelecidas suas categorias funcionais, o que é
feito pela página ilustrada na Figura 3.27, que permite também excluir categorias
estabelecidas.
68
Figura 3.27 - Página para registro de categorias funcionais
O próximo passo consiste em registrar dados históricos de tamanho de proxy por meio
da página ilustrada na Figura 3.28. Esses dados devem ser mensurados em programas já
construídos para a criação de uma base histórica que permita gerar a tabela de tamanho
relativo, ilustrada na Figura 3.29.
Além de os dados históricos serem úteis para a geração da tabela de tamanho relativo,
eles serão usados também como base para a avaliação do proxy, que permite verificar se o
proxy definido representa adequadamente o esforço demandado para o desenvolvimento dos
programas. Essa avaliação é feita em duas etapas:
desconsiderar/excluir dados considerados outliers, que, portanto, não deverão constar
na avaliação. Essa etapa deve ser executada pela página ilustrada na Figura 3.30;
analisar os resultados da avaliação, que considera a correlação e significância dos
dados de tamanho e tempo de desenvolvimento dos programas. A página com a
exibição dos resultados da avaliação está ilustrada na Figura 3.31. Como se pode
observar, além das considerações sobre a correlação e significância, é apresentado um
gráfico ao usuário, o qual auxilia na determinação dos pontos com comportamentos
diferenciados dos demais, podendo indicar que se tratam de outliers e, portanto,
devem ser desconsiderados para que a avaliação apresente resultados corretos.
69
Figura 3.28 - Página para registro de tamanho de proxies
Figura 3.29 - Tabela de tamanho relativo gerada pelo sistema
70
Figura 3.30 - Página para registro de tamanho de proxies
Figura 3.31 - Resultado da avaliação do proxy
71
A partir dos dados de proxies, podem ser feitas as estimativas de tamanho e tempo dos
programas usando o método PROBE. Para tanto, inicialmente deve ser feito o preenchimento
do formulário de estimativa de tamanho, ilustrado na Figura 3.32. Após a submissão deste
formulário, o usuário é redirecionado para a página ilustrada na Figura 3.33, o Size Estimating
Template, que executa automaticamente o método PROBE, desde a escolha dos métodos para
estimativa de tamanho e tempo até a execução de cada um dos métodos. Além disso, é
calculado também o intervalo de previsão de 70% para as estimativas realizadas e, ao término
de todos os cálculos, uma planilha resumindo os resultados obtidos é apresentada ao usuário.
Observa-se que quando o método D é o adequado para a estimativa de tamanho e/ou tempo, o
sistema solicita o preenchimento dos parâmetros de regressão β0(size) e β1(size) e/ou β0(time) e
β1(time).
Figura 3.32 - Página de registro de dados para estimativa de tamanho de programas
72
Figura 3.33 - Size Estimating Template
Com base nas estimativas geradas para um programa, o usuário deve planejar o tempo
de duração de cada atividade relacionada, o que é feito pela página exibida na Figura 3.34.
Conforme proposto pelo PSP, o tempo de duração total das atividades não deve ultrapassar o
tempo de desenvolvimento estimado pelo método PROBE acrescido do intervalo de previsão.
73
Figura 3.34 - Página de gerenciamento de atividades com campo para estimativa de tempo de
cada atividade
Ao concluir o desenvolvimento de um programa, o usuário deve acessar a página
ilustrada na Figura 3.35 para registrar o seu tamanho real. Esses dados são utilizados para
alimentar a base de dados históricos sobre o tamanho dos proxies, o que leva a atualização da
avaliação do proxies e da tabela de tamanho relativo.
Ainda no nível 1, o usuário pode também empregar o Test Report Template. O registro
de testes planejados/executados é realizado na página ilustrada na Figura 3.36. As operações
de consulta, alteração e exclusão podem ser realizadas por uma página de gerenciamento de
testes semelhante à de gerenciamento de programas, já apresentada na Figura 3.12.
Por fim, o usuário pode consultar os scripts fornecidos pelo nível 1 do PSP, bem como
acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na
Figura 3.21, o qual acrescenta apenas as informações sobre o tamanho e tempo planejados
para os programas em relação ao sumário do PSP 0.1.
74
Figura 3.35 - Página para registro do tamanho real dos programas
Figura 3.36 - Página para registro testes planejados/executados
75
3.4.5 Nível 1.1
O suporte oferecido ao nível 1.1 do PSP permite que os usuários do sistema elaborem
rapidamente seus planos pessoais de trabalho.
O primeiro passo para o planejamento pessoal consiste em estimar a duração das
atividades, o que é feito pela página ilustrada na Figura 3.37. Como é possível verificar, para
direcionar a definição do tempo o sistema aponta a duração das fases às quais as atividades
pertencem. Para tanto, baseando-se no valor do campo To Date % do Sumário do Plano de
Projeto, é feita a distribuição do tempo total estimado pelo método PROBE para construção
do programa. Embora o sistema aponte a duração das fases, não é obrigatório que o somatório
da duração das atividades de uma fase tenha o valor apontado.
Figura 3.37 – Página para estimativa do tempo de duração das atividades de um programa
Após a estimativa do tempo de duração das atividades, deve-se definir a ordem de
construção dos programas, o que é feito pela página ilustrada na Figura 3.38. Em seguida, por
meio da página ilustrada na Figura 3.39, deve-se ordenar as atividades envolvidas na
construção de cada programa. Observa-se que, após a ordenação, novos programas ou
atividades que forem cadastrados são lançados ao final da ordenação pré-estabelecida, embora
os usuários possam reordená-los.
76
Figura 3.38 – Página para ordenação de programas
Figura 3.39 – Página para ordenação de atividades
A última etapa do planejamento pessoal é executada automaticamente. Nessa etapa, o
sistema reúne três informações: tempo de duração estimado para as atividades pessoais;
77
ordem de execução das atividades pessoais; tempo de alocação às atividades do projeto, que
equivale à disponibilidade dos usuários. Com base nessas informações, é gerado o Schedule
Planning Template e o Task Planning Template, ilustrados nas figuras 3.40 e 3.41,
respectivamente.
É importante destacar que, além de gerar a tabela do Task Planning Template, o
sistema gera também o diagrama de Gantt correspondente, o que auxilia os usuários na gestão
pessoal do tempo. Outro ponto importante a ser considerado é que os indicadores EV e PV
são gerenciados automaticamente pelo sistema, com base no registro de conclusão das
atividades pessoais. Além disso, o sistema confronta o tempo de disponibilidade dos usuários
com o tempo estimado para realizar as atividades, o que permite apontar potenciais atrasos
que deverão ocorrer no projeto. Esse apontamento é feito na tabela do Task Planning
Template, no diagrama de Gantt - não são apresentadas as barras correspondentes às
atividades para as quais se estima insuficiência de tempo, bem como na matriz apresentada ao
final da página do Task Planning Template. Por meio do apontamento dos potenciais atrasos,
os usuários do PSP podem constatar a necessidade de serem alocados por um tempo maior às
atividades do projeto.
Figura 3.40 – Schedule Planning Template
78
Figura 3.41 – Task Planning Template
a
79
Por fim, o usuário pode consultar os scripts fornecidos pelo nível 1.1 do PSP, bem
como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado
na Figura 3.21, o qual acrescenta apenas alguns indicadores em relação ao sumário do PSP 1.
3.4.6 Nível 2
O suporte oferecido ao nível 2 do PSP permite que os usuários do sistema empreguem
facilmente os checklists de revisão de código e projeto e gerem rapidamente os indicadores de
qualidade propostos.
Na Figura 3.42, é ilustrada a página para cadastro do checklist de revisão de código,
cujos tópicos podem também ser consultados, alterados e excluídos. Observa-se que para cada
linguagem de programação deve ser cadastrado um checklist de revisão de código. Quanto ao
checklist de revisão de projeto, seus tópicos não precisam ser cadastrados, uma vez que são
propostos pelo PSP e são independentes da linguagem de programação adotada.
Figura 3.42 – Página para cadastro do checklist de revisão de código
Para empregar os checklists de revisão de código ou de projeto, primeiramente o
usuário deve selecionar o programa que deseja revisar e, em seguida, selecionar os campos já
verificados, conforme ilustrado na Figura 3.43. Deste modo, o usuário consegue controlar as
verificações já realizadas.
80
Figura 3.43 – Página para emprego do checklist de revisão de código
Além de apoiar as revisões, o sistema gera automaticamente todos os indicadores
propostos pelo PSP 2, os quais são exibidos na forma de um painel para cada linguagem de
programação empregada. Junto a cada indicador, é disponibilizado um link “Saiba Mais” com
informações explicativas. Na Figura 3.44, é ilustrada a primeira parte do painel gerado pelo
sistema, a qual apresenta os indicadores considerando a média de todos os dados históricos
registrados pelo usuário ao longo do emprego do PSP. Já na Figura 3.45, é ilustrada a segunda
parte do painel, a qual apresenta a evolução dos indicadores ao longo dos projetos executados
com o emprego do PSP. É importante destacar que a visão evolutiva dos indicadores pode
contribuir sobremaneira para a constatação do impacto de mudanças no processo.
81
Figura 3.44 – Indicadores gerais de qualidade
82
Figura 3.45 – Evolução dos indicadores de qualidade
83
Por fim, o usuário pode consultar os scripts fornecidos pelo nível 2 do PSP, bem como
acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na
Figura 3.21, o qual acrescenta apenas alguns indicadores e o planejamento de defeitos por
fase, calculado automaticamente com base no tamanho estimado para o programa, na
produção de defeitos por KLOC e no valor do To Date %.
3.4.7 Nível 2.1
O suporte oferecido ao nível 2.1 do PSP permite que os usuários do sistema
empreguem facilmente os modelos de especificação de projeto e o checklist de revisão de
projeto detalhado.
Para empregar os modelos de especificação de projeto, o usuário deve primeiramente
selecionar o programa que deseja especificar. Nas figuras 3.46, 3.47, 3.48 e 3.49 são
ilustradas, respectivamente, as páginas para cadastro dos modelos de especificação
operacional, funcional, de estados e lógica. Tais modelos podem também ser consultados,
alterados e excluídos.
Figura 3.46 – Página para cadastro do modelo de especificação operacional
84
Figura 3.47 – Página para cadastro do modelo de especificação funcional
Figura 3.48 – Página para cadastro do modelo de especificação de estados
Figura 3.49 – Página para cadastro do modelo de especificação lógica
85
Em relação ao checklist de revisão de projeto, a única mudança ocorrida foi a inclusão
de dois tópicos a serem verificados: Análise de estados e Uso de prova matemática para
verificação da lógica.
Por fim, o usuário pode consultar os scripts fornecidos pelo nível 2.1 do PSP, bem
como acessar o Sumário do Plano de Projeto deste nível de maneira semelhante ao ilustrado
na Figura 3.21.
3.4.8 Indicadores oriundos do emprego individual do PSP
A partir do emprego individual do PSP, o sistema permite a geração de informações
que podem auxiliar nas atividades de gerenciamento de projetos. Tais informações são
disponibilizadas aos gerentes de projeto e aos usuários de nível 2.
Na Figura 3.50, é ilustrada a página inicial do SAGP, com destaque para os links do
menu principal que dão acesso aos indicadores oriundos do PSP. Como se pode verificar,
podem ser gerados indicadores relacionados a equipes, à formação de rankings e à gestão de
tempo.
Em relação aos indicadores sobre equipes, o sistema permite gerar os indicadores de
um determinado conjunto de recursos humanos, de modo a verificar quais recursos levam à
composição de uma equipe com o perfil mais próximo ao de interesse. Para tanto, os usuários
devem, primeiramente, acessar a página ilustrada na Figura 3.51. Por meio dessa página, os
usuários podem selecionar os recursos humanos sobre os quais desejam visualizar
indicadores. Essa seleção pode ser precedida por uma busca capaz de considerar a
disponibilidade dos recursos em determinado período de interesse, o que é especialmente útil
quando se deseja formar uma equipe de trabalho, já que é necessário que ele esteja disponível
quando necessário.
86
Figura 3.50 – Menu principal do SAGP com destaque para os itens relacionados aos
indicadores do PSP
87
Figura 3.51 – Página para geração de indicadores por equipe
Após a seleção dos recursos humanos, deve-se selecionar a linguagem de programação
para a qual se deseja visualizar os indicadores. Feito isso, o sistema pode gerar dois tipos de
painel:
se for selecionado apenas um recurso humano, é gerado um painel constituído
pelos indicadores gerais e evolutivos deste recurso, com as mesmas informações e
estrutura ilustradas nas figuras 3.44 e 3.45, incluindo apenas a apresentação do
percentual de tempo que o recurso humano gasta com interrupções;
se for selecionado mais de um recurso humano, é gerado um painel constituído
apenas pela média de cada indicador geral dos recursos, com as mesmas
informações e estrutura ilustradas na Figura 3.44, incluindo apenas a apresentação
do percentual de tempo médio que os recursos humanos gastam com interrupções.
Observa-se que, caso um ou mais recursos não tenham dados para a geração de um
indicador, o sistema aponta o nome desses recursos logo abaixo do gráfico
correspondente ao indicador.
Em relação à geração de ranking, o sistema permite classificar os recursos humanos
considerando cada um dos indicadores de qualidade do PSP, o que pode ser útil para a
88
aplicação de políticas de bonificação. Para tanto, o usuário deve acessar a página ilustrada na
Figura 3.52. Por meio dessa página, o usuário pode selecionar se deseja gerar o ranking
considerando os dados de todos os projetos ou apenas do projeto atual, bem como o indicador
e a linguagem de programação a ser considerada. Além disso, também é possível realizar uma
busca considerando a disponibilidade dos recursos humanos antes de gerar o ranking.
Figura 3.52 – Página para geração de rankings sobre os indicadores do PSP
O sistema permite também que os usuários visualizem indicadores de tempo referentes
a cada atividade do projeto. O funcionamento dessa função baseia-se no fato de que cada
programa que um usuário do PSP constrói está relacionado a uma atividade do projeto à qual
ele está alocado. O primeiro passo para geração das informações é a seleção ou busca da
atividade de interesse, o que pode ser feito por meio da página ilustrada na Figura 3.53. Como
pode ser visto, já nessa página é exibido o progresso registrado para as atividades do projeto e
89
o progresso estimado automaticamente pelo sistema com base no progresso das atividades
pessoais. Quando um ou mais usuários alocados a uma atividade não empregam o PSP, o
progresso não pode ser estimado e, então, é exibido apenas “#”.
Figura 3.53 – Página para seleção de atividades para geração de indicadores de tempo
Após a seleção de uma das atividades, é exibida a página ilustrada na Figura 3.54, que
apresenta as seguintes informações sobre cada recurso humano vinculado à atividade:
nível no PSP: nível do recurso humano no PSP. Quanto maior o nível, maior a
qualidade das estimativas pessoais;
tempo de alocação à atividade: tempo de alocação do recurso humano à atividade;
tempo estimado pelo usuário: tempo estimado pelo recurso humano para desenvolver
sua parte da atividade;
diferença: diferença percentual do tempo de alocação à atividade estimada pelo
gerente e pelo próprio recurso humano. Valores positivos indicam que o recurso está
alocado por mais tempo do que considera necessário. Valores negativos indicam o
oposto;
desvio médio: diferença percentual média entre o tempo planejado pelo usuário e o
tempo realmente gasto por ele para executar uma atividade. Valores positivos indicam
que o recurso, em média, estima que precisará de mais tempo do que realmente utiliza
para executar uma atividade. Valores negativos indicam o oposto;
tempo real consumido: tempo já utilizado para a execução da atividade;
% concluído: percentual da atividade já concluído pelo recurso humano, o qual é
calculado de acordo com a técnica da análise de valor agregado.
90
Figura 3.54 – Página para exibição dos indicadores de tempo
Após a listagem do último recurso humano na tabela, é apresentado o percentual
concluído da atividade, que é calculado automaticamente pelo sistema por meio de uma média
ponderada. No cálculo, considera-se como elementos os percentuais concluídos pelos recursos
humanos, enquanto os pesos são os tempos de alocação à atividade. Observa-se que o tempo
de alocação à atividade foi considerado como peso, pois é proporcional à carga de trabalho
que se espera de cada recurso.
Por meio das informações fornecidas pela página ilustrada na Figura 3.54, os
responsáveis pelo projeto podem decidir atualizar o progresso da atividade, o que pode ser
feito pelo link “Atualizar progresso”. Além disso, baseando-se em todas as informações
apresentadas na tabela, pode-se decidir aumentar ou diminuir o tempo de alocação dos
recursos humanos, o que pode ser feito pela própria página.
91
3.5 Considerações finais
Neste capítulo, foi apresentada toda a construção do componente de apoio ao PSP,
abordando desde a identificação de requisitos, até a apresentação do funcionamento do
componente implementado.
Com isso, foi possível observar que o sistema proposto contempla uma ampla
quantidade de funções, que permitem o emprego rápido e adequado de todos os elementos do
PSP, além de gerar informações capazes apoiar o gerenciamento de projetos. Outro aspecto
importante do componente construído é a disponibilização de textos de ajuda, especialmente
úteis para usuários com pouco conhecimento sobre o PSP.
92
CAPÍTULO 4 – Avaliação dos Resultados
4.1 Considerações iniciais
O objetivo deste capítulo é apresentar a avaliação das novas funções de apoio ao PSP
incorporadas ao SAGP por meio do componente “Gestão pessoal”.
Na seção 4.2 é apresentada uma análise comparativa entre o sistema proposto e
algumas ferramentas de apoio ao PSP disponíveis no mercado. Na seção 4.3 é apresentada
uma avaliação do sistema por um grupo de 22 usuários com diferentes níveis de experiência
em desenvolvimento de software, permitindo identificar sua abrangência, bem como o apoio
fornecido ao aprendizado de conceitos relacionados ao PSP. Por fim, na seção 4.4 são
apresentadas as considerações finais deste capítulo.
4.2 Análise comparativa de ferramentas de apoio ao PSP
A análise comparativa considerou o SAGP e outras seis ferramentas de apoio ao PSP
disponíveis no mercado. A seleção dessas ferramentas buscou contemplar as mais citadas em
artigos consultados durante o estudo de trabalhos relacionados. Além disso, foram
selecionadas apenas aquelas sobre as quais foram encontradas informações suficientes para a
realização da análise. Seguindo esses critérios, foram selecionadas as seguintes ferramentas:
Process Dashboard: ferramenta open-source, cujo projeto é financiado pela Tuma
Solutions (TUMA SOLUTIONS, 2012);
Jasmine: ferramenta desenvolvida pela Escola de Engenharia da Information and
Communications University, na Coréia do Sul (SHIN; CHOI; BAIK et al. 2007);
93
Hackystat: ferramenta open-source, desenvolvida para apoiar a coleta e análise de
dados necessários a diversas metodologias de desenvolvimento de software, não
sendo exclusiva para o PSP (JOHNSON et al., 2005);
PSP Assistant (PSPA): ferramenta desenvolvida pela Faculdade de Estudos de
Computação na De La Salle University, nas Filipinas (SISON et al., 2005);
PSP.NET: ferramenta desenvolvida pela Faculdade de Ciência da Computação e
Tecnologia da Informação na University of Malaya, na Malásia (NASIR; YUSOF,
2005);
Plug-in Eclipse: ferramenta open-source que pode ser instalada no ambiente de
programação Eclipse para apoiar a coleta e análise de dados de interesse ao
emprego do PSP (YUAN et al., 2005).
Após a seleção das ferramentas, foram definidos os quesitos a serem analisados, os
quais buscaram avaliar o apoio ao emprego dos elementos e práticas de cada nível do PSP.
Tais quesitos foram avaliados por meio de uma análise observacional realizada por um
membro da equipe do GEPES não envolvido no desenvolvimento do componente de apoio ao
PSP integrado ao SAGP, o que garantiu uma avaliação imparcial dos sistemas. Para a
atribuição de uma qualificação, foi considerada uma escala de 0 a 100%, variando de 25 em
25%, conforme a cobertura das ferramentas aos itens considerados.
Na Tabela 4.1, é apresentado o resultado da avaliação. Como se pode verificar, em
geral o SAGP apresenta cobertura igual ou melhor que as demais ferramentas avaliadas. Um
dos pontos de destaque identificados é que a maioria das ferramentas oferece pouco ou
nenhum apoio ao PSP 1, que pode ser considerado um dos níveis mais importantes, uma vez
que permite a obtenção de estimativas de tamanho e tempo de desenvolvimento de software
muito precisas. Além disso, apenas a ferramenta PSP.NET aborda o nível 2.1, que também é
de grande importância por apoiar a qualidade dos projetos de software. Em relação aos pontos
em que o SAGP não obteve 100%, as principais deficiências observadas foram:
1. Registro do padrão de tipos de defeitos: o SAGP considera apenas os tipos de
defeitos propostos pelo PSP, não permitindo o cadastro de outros itens;
2. Medição e classificação das linhas de código: o SAGP não mede e classifica
automaticamente as LOCs dos programas construídos, tornando necessário o uso
de outras ferramentas;
3. Registro das revisões de código e projeto: o SAGP considera apenas os itens
propostos pelo PSP no checklist de revisão de projeto, não permitindo o cadastro
94
de adicionais.
Em complemento aos resultados apresentados na Tabela 4.1, a análise realizada
permitiu constatar que nenhuma das ferramentas é integrada a um ambiente de gerenciamento
de projetos. Além disso, com exceção da PSPA e da PSP.NET, nenhuma das ferramentas
exige autenticação dos usuários para o acesso, o que pode comprometer a privacidade dos
usuários (ABBAS; AFZAL; AHMED, 2012).
Tabela 4.1 – Análise comparativa das ferramentas de apoio ao PSP
Process
Dashboard
Jasmine Hackystat PSPA PSP.NET Plug-in
Eclipse
SAGP
PSP 0
Registro de tempo e defeitos 100% 100% 100% 100% 100% 100% 100%
Registro do padrão de tipos
de defeitos
0% 75% 0% 0% 75% 0% 50%
PSP 0.1
Registro de padrão de
codificação
0% 0% 0% 0% 0% 0% 100%
Medição e classificação das
linhas de código
100% 100% 100% 75% 75% 75% 50%
Registro de propostas de
melhoria do processo
0% 0% 0% 100% 0% 0% 100%
PSP 1
Geração automática das
estimativas
100% 25% 25% 25% 25% 0% 100%
Registro de relatórios de
teste
0% 25% 0% 100% 50% 0% 100%
PSP 1.1
Elaboração do Schedule
Planning Template
75% 75% 0% 75% 75% 0% 100%
Elaboração do Task
Planning Template
25% 75% 0% 75% 75% 0% 100%
Distribuição automática do
tempo entre as fases do PSP
0% 100% 0% 0% 100% 100% 100%
PSP 2
Registro das revisões de
código e projeto
75% 75% 25% 75% 25% 25% 75%
Geração dos indicadores de
qualidade
100% 75% 50% 50% 50% 50% 100%
Estimativa de defeitos em
cada fase
75% 75% 0% 0% 75% 75% 100%
PSP 2.1
Apoio à especificação de
projeto
0% 0% 0% 0% 100% 0% 100%
95
4.3 Visão dos usuários
Esta etapa teve como objetivo analisar a visão dos usuários quanto à contribuição
deste trabalho. Para tanto, em outubro de 2012 foi realizado no campus da Universidade
Estadual Paulista (UNESP) de São José do Rio Preto um curso de 16 horas, que se dividiu em
duas etapas. Na primeira etapa, que teve duração de 8 horas, foi ministrado um curso teórico,
no qual foram abordados todos os elementos e práticas do PSP, de modo a garantir um
conhecimento básico sobre o processo a todos os participantes do curso. Na segunda etapa,
também com duração de 8 horas, foi apresentado o sistema de apoio ao emprego do PSP,
abordando tanto a Área exclusiva que garante o acesso às funções de apoio ao PSP
disponíveis, como as funções relacionadas aos indicadores para gerenciamento de projetos.
O curso contou com 22 participantes, entre profissionais e alunos de graduação e pós-
graduação da área de computação, sendo que nenhuma delas tinha conhecimento prévio sobre
o PSP. Na Figura 4.1, é apresentado o perfil dos participantes quanto ao tempo de experiência
em desenvolvimento de software, revelando a abrangência da amostra selecionada.
Figura 4.1 – Perfil dos participantes quanto ao tempo de experiência
Ao término de cada uma das duas etapas do curso ministrado, foi aplicado um
questionário online aos participantes. Observa-se que os participantes não foram identificados
nos questionários, garantindo uma avaliação imparcial. Além disso, ao iniciar o segundo
questionário, não era possível alterar as respostas do primeiro.
No primeiro questionário, cada prática do PSP foi avaliada com base nos seguintes
quesitos:
96
Compreensão: refere-se ao grau de entendimento de um elemento ou prática do PSP,
quantificado em uma escala de 1 (pior entendimento) a 5 (melhor entendimento);
Importância: refere-se ao grau de importância que o participante atribui a um
elemento ou prática do PSP, quantificado em uma escala de 1 (menor importância) a
5 (maior importância);
Dificuldade: refere-se ao grau de dificuldade que o usuário sentiu para empregar um
elemento ou prática do PSP contando apenas com o apoio dos recursos que tem
disponível, quantificado em uma escala de 1 (menor dificuldade) a 5 (maior
dificuldade).
Além desses quesitos, os participantes fizeram uma avaliação geral do PSP, julgando
quatro assertivas quanto ao grau de concordância, quantificado numa escala de 1 (discordo
plenamente) a 5 (concordo plenamente). As assertivas foram:
O PSP me ajudaria no desenvolvimento de sistemas;
Um desenvolvedor que não conhece o PSP pode aprender as práticas em pouco tempo;
A simplicidade do PSP estimula seu uso;
Pretendo usar o PSP em meu cotidiano.
Por fim, foi deixado um campo aberto para o recebimento de comentários.
Já o segundo questionário foi dividido em três partes, sendo a primeira para avaliar o
apoio do SAGP às práticas do PSP; a segunda para averiguar o quanto os gerentes e membros
de equipe dos projetos podem ser auxiliados pela integração das práticas do PSP ao ambiente
de gerenciamento de projetos; e a terceira para avaliar aspectos gerais de qualidade da
ferramenta.
Assim, na primeira parte do questionário, foram reavaliadas a Compreensão e a
Importância dos elementos ou práticas do PSP, bem como a concordância com as assertivas,
de modo a constatar as diferenças da visão dos usuários antes e depois da apresentação do
sistema desenvolvido. Além disso, foram avaliados também:
Facilidade de uso: refere-se ao grau de facilidade que o usuário sentiu para empregar
um elemento ou prática do PSP contando com o apoio do SAGP, quantificado em
uma escala de 1 (menor facilidade) a 5 (maior facilidade);
Aderência ao PSP: refere-se ao grau de proximidade entre elemento ou prática
proposto pelo PSP e a abordagem oferecida pela ferramenta, considerando também a
97
completeza do apoio oferecido. Esse quesito também foi avaliado em uma escala de 1
(sem aderência) a 5 (totalmente aderente).
Na segunda parte do questionário, foram avaliados, em uma escala de 1 (pior
avaliação) a 5 (melhor avaliação), os seguintes quesitos:
Contribuição para o uso individual do PSP: refere-se ao quanto a integração ao
ambiente de gerenciamento de projetos ajuda cada recurso humano no emprego do
PSP durante os projetos;
Importância para o recrutamento de recursos humanos: refere-se ao quanto a
integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projeto a
formarem suas equipes;
Importância para o gerenciamento da equipe do projeto: refere-se ao quanto a
integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a
monitorarem o desempenho dos recursos humanos e aplicarem políticas de incentivo;
Importância para as estimativas de tempo: refere-se ao quanto a integração ao
ambiente de gerenciamento de projetos ajuda os gerentes de projetos a planejarem o
tempo demandado para o desenvolvimento dos projetos;
Importância para o controle do tempo: refere-se ao quanto a integração ao ambiente
de gerenciamento de projetos ajuda os gerentes de projetos a controlarem o
andamento das atividades dos projetos;
Importância para o planejamento da qualidade dos projetos: refere-se ao quanto a
integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a
planejarem a qualidade dos projetos;
Importância para o controle da qualidade dos projetos: refere-se ao quanto a
integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos no
controle da qualidade dos projetos;
Importância dos indicadores gerados: refere-se ao grau de importância dos
indicadores gerados pela ferramenta para os gerentes de projetos.
Na terceira parte foram avaliados, em uma escala de 1 (menor) a 5 (maior), os
seguintes aspectos de qualidade:
Qualidade da interface: refere-se ao grau de atratividade da interface;
98
Organização das informações: refere-se à organização das informações na
ferramenta e nos relatórios gerados;
Frequência de falhas: refere-se à frequência de falhas ocorridas durante o uso da
ferramenta. Salienta-se que, quanto maior a avaliação recebida, maior a frequência de
falhas;
Desempenho: refere-se à rapidez da ferramenta para a execução das solicitações;
Portabilidade: refere-se à capacidade de uso da ferramenta em vários ambientes
computacionais (sistemas operacionais e navegadores);
Operacionalidade: refere-se à quantidade de recursos de ajuda oferecidos pela
ferramenta, tais como textos de apoio, manuais e contato para suporte.
Por fim, foi deixado um campo aberto para registro dos pontos fortes e outro para
registro dos pontos fracos do sistema.
No Gráfico 4.1, são apresentados os resultados obtidos com a avaliação do quesito
Compreensão, considerando a média das notas atribuídas pelos participantes. Observando-se
o gráfico, é possível constatar que houve uma melhoria significativa no entendimento dos
elementos e práticas do PSP após a apresentação do SAGP. Isso permite afirmar que o
sistema desenvolvido é capaz de contribuir para o aprendizado do processo, o que era um dos
objetivos iniciais deste trabalho.
No Gráfico 4.2, são apresentados os resultados obtidos com a avaliação do quesito
Importância, considerando a média das notas atribuídas pelos participantes. Observando-se o
gráfico, é possível constatar que houve um aumento da importância dos elementos e práticas
do PSP após a apresentação do SAGP, o que permite afirmar que o sistema desenvolvido foi
capaz de elucidar a contribuição do PSP, fato que pode contribuir sobremaneira para a
implantação do referido processo em uma organização.
99
Gráfico 4.1 – Avaliação da Compreensão dos elementos e práticas do PSP antes e
depois da apresentação do SAGP
Gráfico 4.2 – Avaliação da Importância dos elementos e práticas do PSP antes e
depois da apresentação do SAGP
100
No Gráfico 4.3, são apresentados os resultados obtidos com a avaliação do quesito
Grau de dificuldade, abordado no primeiro questionário. Já o Gráfico 4.4 refere-se à
Facilidade de uso, abordada no segundo questionário. Ao confrontar os dois gráficos, é
possível notar que muitos elementos e práticas inicialmente considerados como sendo de
difícil uso, passaram a ser avaliados como de fácil utilização, o que atesta o apoio fornecido
para o emprego do PSP.
Gráfico 4.3 – Avaliação do Grau de dificuldade dos elementos e práticas do PSP antes da
apresentação da ferramenta
101
Gráfico 4.4 – Avaliação da Facilidade de uso dos elementos e práticas do PSP após a
apresentação da ferramenta
No Gráfico 4.5, são apresentados os resultados obtidos com a avaliação do grau de
concordância quanto às quatro assertivas, considerando a média das notas atribuídas pelos
participantes. Observando-se o gráfico, é possível constatar que houve um forte aumento da
concordância quanto as assertivas, o que permite afirmar que os participantes sentiram-se
mais interessados em empregar o PSP após a apresentação do sistema desenvolvido.
Gráfico 4.5 – Avaliação da concordância quanto às assertivas antes e depois da apresentação
da ferramenta
102
No Gráfico 4.6, são apresentados os resultados obtidos com a avaliação do quesito
Aderência ao PSP, considerando a média das notas atribuídas pelos participantes.
Observando-se o gráfico, é possível constatar que a avaliação recebida foi muito boa, uma vez
que a maioria dos quesitos recebeu avaliação média superior a 4,5.
Gráfico 4.6 – Avaliação da Aderência ao PSP
No Gráfico 4.7, são apresentados os resultados obtidos com a avaliação da
contribuição decorrente da integração do PSP ao ambiente de gerenciamento de projetos,
considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é
possível constatar que a avaliação recebida foi muito boa, uma vez que todos os quesitos
receberam avaliação média próxima a 4,5.
103
Gráfico 4.7 – Avaliação da contribuição decorrente da integração do PSP ao ambiente de
gerenciamento de projetos
No Gráfico 4.8, são apresentados os resultados obtidos com a avaliação dos aspectos
de qualidade do sistema desenvolvido, considerando a média das notas atribuídas pelos
participantes. Observando-se o gráfico, é possível constatar que, de maneira geral, a avaliação
recebida foi muito boa. No entanto, a portabilidade, a organização das informações e a
qualidade da interface podem ser melhoradas em projetos futuros. Cabe observar que,
atualmente, o sistema opera apenas no navegador Mozilla Firefox, o que explica a avaliação
mais baixa do quesito portabilidade. Quanto à frequência de falhas, embora a avaliação média
recebida tenha sido boa (por ser baixa), todas as falhas foram corrigidas à medida que foram
encontradas.
Gráfico 4.8 – Avaliação dos aspectos de qualidade do sistema
104
Quanto aos comentários recebidos no primeiro questionário destacam-se: dificuldade
para o entendimento do PSP; demora para execução de todos os cálculos envolvidos no
processo; complexidade dos cálculos estatísticos; dificuldade para manutenção dos dados
históricos; dificuldade para geração dos indicadores de qualidade.
Após a apresentação da ferramenta, os principais pontos fortes registrados pelos
usuários foram: facilidade de emprego do Time Recording Log e do Defect Recording Log;
facilidade para a geração das estimativas; agilidade para geração de diversos tipos de
relatórios; qualidade do painel com indicadores de qualidade; abrangência das informações
disponibilizadas aos gerentes de projetos a partir do emprego individual do PSP; organização
do menu de acordo com os níveis do PSP; presença de links “Saiba mais” ao longo de todo o
sistema. Quantos aos pontos fracos, destacam-se: dificuldade para uso do menu; mau
aproveitamento do espaço da tela; mau funcionamento da interface em algumas resoluções de
tela; falta de classificador automático de linhas de código; disponibilidade apenas para o
navegador Mozilla Firefox; poucos tipos de gráficos nos relatórios gerados.
É importante observar que não foram identificadas diferenças significativas entre as
avaliações de participantes com diferentes níveis de experiência em desenvolvimento de
software, o que pode ser explicado pelo fato de o sistema não ter sido usado por um período
mais longo e em situações reais do cotidiano.
4.4 Considerações finais
Neste capítulo, foi apresentado o processo de avaliação da contribuição deste trabalho.
A análise comparativa de sistemas de apoio ao emprego do PSP sugeriu que o SAGP
apresenta uma abrangência maior que os outros sistemas considerados. Além disso, apenas o
SAGP proporciona uma solução integrada ao ambiente de gerenciamento de projetos, o que
facilita o emprego do PSP e possibilita a geração de indicadores aos gerentes de projetos.
Por meio do estudo da visão dos usuários, foi possível observar que o sistema proposto
realmente melhora o entendimento dos elementos e práticas do PSP, o que, por sua vez,
contribui para que os usuários entendam a importância do processo. Além disso, o estudo
realizado revelou que os participantes sentiram-se mais interessados a usar o PSP após a
apresentação do sistema. A avaliação permitiu também confirmar a contribuição da integração
ao ambiente de gerenciamento de projetos. Por fim, a avaliação apontou que a qualidade do
sistema desenvolvido é boa, mas pode ser melhorada em alguns aspectos.
105
CAPÍTULO 5 – Considerações Finais
5.1 Considerações iniciais
O objetivo deste capítulo é apresentar as contribuições oriundas da realização deste
trabalho, bem como as possibilidades de trabalhos futuros. Para tanto, na seção 5.2 são
listadas as contribuições obtidas. Já na seção 5.3 são apresentadas algumas propostas para
trabalhos futuros. Finalmente, na seção 5.4 são apresentadas as considerações finais.
5.2 Contribuições
As principais contribuições deste trabalho foram:
estudo detalhado sobre o PSP, que pode auxiliar futuramente os interessados em
empregar o processo ou realizar pesquisas científicas relacionadas ao assunto;
identificação de requisitos necessários para a criação de um sistema de apoio ao
PSP integrado a um ambiente de gerenciamento de projetos;
extensão da arquitetura de software do SAGP, de modo a incluir os requisitos
identificados neste trabalho. Observa-se que o novo componente arquitetural foi
estabelecido de modo a facilitar posteriores alterações e inclusões de novas
funções;
construção do componente de apoio ao PSP integrado ao SAGP, cujos principais
benefícios são:
automatização de todos os complexos cálculos propostos pelo PSP, que
normalmente representam uma barreira ao emprego do processo;
106
integração ao ambiente de gerenciamento de projetos, o que facilita
sobremaneira a definição e o gerenciamento do trabalho pessoal a ser
desenvolvido. Durante as pesquisas realizadas, não foram encontrados
sistemas que oferecem essa solução integrada, que pode ser considerada
como o principal diferencial deste trabalho;
disponibilização de elementos de apoio ao aprendizado do PSP, o que é
algo especialmente importante no Brasil e em países onde são raros os
cursos para ensino do assunto;
apoio à melhoria da maturidade dos recursos humanos, uma vez que facilita
a adoção do PSP;
disponibilização de mais informações de apoio às tomadas de decisão dos
gerentes de projetos, as quais são geradas a partir do processamento dos
dados coletados sobre cada membro de equipe que emprega o PSP
individualmente.
análise comparativa de sistemas de apoio ao PSP, que auxilia na rápida
identificação das restrições de cada um, além de indicar o diferencial do sistema
construído;
avaliação do sistema por um grupo de desenvolvedores de software, o que permitiu
comprovar os benefícios e detectar pontos a serem melhorados, norteando
trabalhos futuros.
5.3 Trabalhos futuros
As sugestões para trabalhos futuros são relacionadas a três principais aspectos:
aprimoramento de funções existentes; estabelecimento de novas funções para ampliar a
abrangência do sistema; melhoria de aspectos de qualidade do sistema.
Em relação ao aprimoramento de funções existentes, trabalhos futuros poderão incluir
mais informações e gráficos nos relatórios, que poderiam ser gerados em outros formatos,
como XLS, CSV e outros.
Quanto ao estabelecimento de novas funções para o sistema, destacam-se:
classificação automática das LOCs dos programas; cadastro de novos tipos de defeitos;
incorporação das práticas propostas pelo TSP ao SAGP; possibilidade de registrar as
propostas de melhoria do processo como sendo lições aprendidas em nível de projeto,
107
acessíveis a todos os membros de equipe do projeto; geração de gráfico relacionando o valor
planejado e o valor agregado em cada projeto; entre outros.
Em relação à melhoria de aspectos de qualidade do sistema, alguns trabalhos poderão
ser desenvolvidos visando à melhoria da portabilidade e da qualidade da interface do sistema.
Com isso, o sistema poderia ser acessado de outras plataformas e seria mais atrativo aos
usuários.
Por fim, é importante considerar que deverão ser realizados estudos mais extensos e
detalhados sobre o sistema para identificar novos pontos de melhoria, os quais deverão
envolver seu emprego durante o desenvolvimento de projetos reais.
5.4 Conclusões
Este trabalho apresentou a integração de um componente de apoio ao PSP a um
ambiente web de gerenciamento de projetos previamente desenvolvido, denominado SAGP. O
intuito dessa integração foi contribuir para o progresso dos resultados de projetos de software
a partir da melhoria da maturidade dos recursos humanos e da disponibilização de mais
informações de apoio às tomadas de decisão dos gerentes de projetos.
Os resultados obtidos foram avaliados por meio de duas etapas. Inicialmente foi
realizada uma análise comparativa entre o sistema proposto e algumas ferramentas de apoio
ao PSP disponíveis no mercado. Em seguida, foi realizada uma avaliação da visão dos
usuários do sistema. A partir disso foi possível concluir que o componente de apoio ao PSP
construído contribui fortemente para o aprendizado e emprego do processo, proporcionando
um ambiente capaz de estimular a melhoria da maturidade dos recursos humanos. Além disso,
verificou-se que a integração ao ambiente de gerenciamento de projetos permite a geração de
indicadores que podem apoiar as tomadas de decisão dos gerentes de projetos, contribuindo
para a melhoria dos resultados dos projetos executados.
Diante do exposto, constata-se que os objetivos iniciais foram plenamente atendidos.
Porém, apesar da abrangência atual, observa-se que outros trabalhos poderão ser
desenvolvidos futuramente de modo a aprimorar e ampliar o sistema proposto.
108
Referências bibliográficas
ABBAS, A.; AFZAL, M. F.; AHMED, S. A critical analysis of Personal Software Process
(PSP) & PSP tools support. International Journal of Reviews in Computing, v. 10, p. 22 -
27, Julho de 2012.
ALBUQUERQUE, J. O.; MEIRA, S. R. PSP-JOA Processo de Software Pessoal - Uma
abordagem orientada a Java. Dissertação (Mestrado), Recife: Universidade Federal de
Pernambuco, 1997.
BADDOO, N.; HALL, T. De-motivators for software process improvement: an analysis of
practitioners’ views. The Journal of Systems and Software, v. 66, n. 1, p. 23 - 33, Abril de
2003.
BALBINO, M. S. Um modelo para diagnóstico e melhoria de competência pessoal em
qualidade de software. Dissertação (Mestrado), Belo Horizonte: Universidade Federal de
Minas Gerais, 2004.
BRYKCZYNSKI, B.; MEESON, R.; WHEELER, D. A. Software inspection: Eliminating
software defects. In: Proceedings of the 6th Annual Software Technology Conference,
Alexandria, Egito, Maio de 1994.
BUGZILLA. Bugzilla Mozilla. Disponível em: https://bugzilla.mozilla.org/. Acesso em: 27
nov. 2012.
EDGEWALL. Edgewall Software. Disponível em: http://www.edgewall.org/. Acesso em: 27
nov. 2012.
EPIFORGE SOFTWARE. Grindstone Software. Disponível em:
http://www.epiforge.com/Grindstone/. Acesso em: 27 nov. 2012.
ESTECA, A. M. N. Gerência de Projetos: Apoio automatizado para efetivação das
atividades. Monografia (Trabalho de Conclusão de Curso), São José do Rio Preto:
Universidade Estadual Paulista, 2010.
109
EVELEENS, J. L.; VERHOEF, C. The Rise and Fall of the Chaos Report Figures. IEEE
Software, v. 27, n. 1, p. 30 – 36, Fevereiro de 2010.
FERGUSON, P.; HUMPHREY, W.; KHAJENOORI, S.; MACKE, S.; MATVYA, A.
Introducing the personal software process: Three industry case studies. IEEE Computer, v.
30, n. 5, p. 24-31, Maio de 1997.
HUMPHREY, W. S. Modeling Implications of the Personal Software Process. In:
Proceedings of the 5th International Software Process Workshop, Kennebunkport,
Estados Unidos, Outubro de 1989.
HUMPHREY, W. S. A Discipline for Software Engineering: The Complete PSP Book.
Reading: Addison-Wesley Publishers, 1995. 816 p.
HUMPHREY, W. S. Introduction to the Personal Software Process. Reading: Addison-
Wesley Publishers, 1997. 278 p.
HUMPHREY, W. S. PSP: A Self-Improvement Process for Software Engineers. Reading:
Addison-Wesley Publishers, 2005. 368 p.
JIRACHIEFPATTANA, W. Understanding the Influence of Individual Values on
Management of Software Development: Thai IT Professionals. International Association of
Computer Science & Information Technology, v. 36, p. 11 - 15, Abril de 2012.
JOHNSON, P. M.; KOU, H.; AGUSTIN, J.; CHAN, C.; MOORE, C.; MIGLANI, J.; ZHEN,
S.; DOANE, W. E. J. Beyond the Personal Software Process: metrics collection and analysis
for the differently disciplined. In: Proceedings of the 25th International Conference on
Software Engineering, Portland, Estados Unidos, Maio de 2003.
JOHNSON, P. M.; KOU, H.; PAULDING, M. G.; ZHANG, Q.; KAGAWA, A.;
YAMASHITA, T. Improving software development management through software project
telemetry. IEEE Software, v. 22, n. 4, p. 76 – 85, Agosto de 2005.
KLEINE, C. Software de apoio ao processo de revisão por pares na codificação. Trabalho
de Conclusão de Software, Blumenau: Universidade Regional de Blumenau, 2011.
110
MANTIS. Mantis Bug Tracker. Disponível em: http://www.mantisbt.org/index.php. Acesso
em: 27 nov. 2012.
MARTINS, S. R.; OLIVEIRA, W. A. Manual de padronização de codificação PHP coding
standards v0.1. SkySoft, 2009. 11p.
MAXIMIANO, A. C. A. Administração de Projetos: Como Transformar Idéias em
Resultados. 3. ed. São Paulo: Editora Atlas, 2008. 376 p.
MCHALE, J.; CHICK, T.; DAVIS, N.; MILUK, G. Accelerating CMMI Adoption with
PSP/TSP. In: Proceedings of the 3rd TSP Symposium, Phoenix, Estados Unidos, Setembro
de 2008.
NASIR, M. H. N. M.; YUSOF, A. M. Automating a Modified Personal Software Process.
Malaysian Journal of Computer Science, v. 18, n. 2, p. 11 - 27, Dezembro de 2005.
NOGUEIRA, M. O. Qualidade no Setor de software Brasileiro. 2006. Tese (Doutorado),
Rio de Janeiro: COPPE/UFRJ, 2006.
OVER, J.; AKIYAMA, Y. Bringing Science for High Maturity Practices with PSP/TSP. In:
Proceedings of the 4th TSP Symposium, New Orleans, Estados Unidos, Setembro de 2009.
PMI, Project Management Institute. Guide of Project Management Body of Knowledge. 4.
ed. Newtown Square: Project Management Institute – PMI, 2008. 459 p.
POMEROY-HUFF, M.; CANNON, R.; CHICK, T. A.; MULLANEY, J.; NICHOLS, W. The
Personal Software Process (PSP) Body of Knowledge. Technical Report, CMU/SEI-2009-
SR-018, v2.0, Agosto de 2009.
PRESSMAN, R. Software Engineering: A Practitioner’s Approach. 7th ed. McGraw-Hill,
2009. 928 p.
RAMINGWONG, S.; RAMINGWONG, L. Implementing a Personal Software Process
(PSPSM
) Course: A Case Study. Journal of Software Engineering and Applications, v. 5, n.
8, p. 639 – 644, Agosto de 2012.
111
REINEHR, S. S. PSPi - Uma instância do Personal Software Process para o ambiente
corporativo. Dissertação (Mestrado), Curitiba: Pontifícia Universidade Católica do Paraná,
2001.
RESPONSIVE SOFTWARE. Responsive Time Logger. Disponível em: http://www.
http://responsivesoftware.com/. Acesso em: 27 nov. 2012.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. Qualidade de Software – Teoria e
Prática, São Paulo: Prentice Hall, 2001.
SHEN, Z.; YONG-JI, W.; LI, R. Personal Software Process Capability Assessment
Method. Journal of Software, v. 20, n. 12, p. 3137 – 3149, Dezembro de 2009.
SHIN, H.; CHOI, H. J.; BAIK, J. JASMINE: A PSP Supporting Tool. In: Internacional
Conference on Software Process, Minneapolis, Estados Unidos, Maio de 2007.
SILVA, R. A. C. PSP e métodos ágeis na melhoria da qualidade em produção de
software: um estudo de caso. Dissertação (Mestrado). Viçosa: Universidade Federal de
Viçosa, 2006.
SILVA JÚNIOR, J. W. Uma disciplina para engenharia de software: Estudo do Personal
Software Process (PSP), Proposto por Watts Humphrey (A profissionalização do
desenvolvedor de software). Monografia (Trabalho de Conclusão de Curso), Pelotas:
Universidade Federal de Pelotas, 2000.
SISON, R.; DIAZ, D.; LAM, E.; NAVARRO, D.; NAVARRO, J. Personal Software Process
(PSP) Assistant. In: Proceedings of the 12th Asia-Pacific Software Engineering
Conference, Washington, Estados Unidos, Dezembro de 2005.
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro. Technical report,
SOFTEX, v. 1.0, 2003.
SOFTWARE ENGINEERING INSTITUTE (SEI). Capability Maturity Model (CMM) for
software. Technical report, CMU/SEI, v. 1.1, 1993.
112
SOMMERVILLE, I. Engenharia de Software. 9 ed. São Paulo: Pearson Addison Wesley,
2011.
SOUZA, R. C. G.; ESTECA, A. M. N.; SANTOS, A. B.; VALÊNCIO, C. R.; HONDA, M. T.
Web System to Aid Project Management. In: Proceedings of the SEKE 23rd Conference on
Software Engineering and Knowledge Engineering, Miami, Estados Unidos, 2011.
STANDISH GROUP. Chaos Report. Boston: The Standish Group International, 2009.
TUMA SOLUTIONS. Process Dashboard. Disponível em: http://www.processdash.com/.
Acesso em: 27 nov. 2012.
WOHLIN, C. The Personal Software Process as a Context for Empirical Studies. IEEE
TCSE Software Process Newsletter, n. 12, p. 7 - 12, 1998.
YUAN, X.; VEGA, P.; YU, H.; LI, Y. A Personal Software Process Tool for Eclipse
Environment. In: Proceedings of the International Conference on Software Engineering
Research and Practice, Las Vegas, Estados Unidos, 2005.
113
APÊNDICE A – Cenários de especificação dos casos
de uso
Neste apêndice, são apresentados os cenários de especificação dos casos de uso a
serem contemplados pelo componente de apoio ao PSP, os quais foram descritos segundo o
modelo de especificação operacional, proposto pelo nível 2.1 do PSP.
Requisitos gerais
Tabela A.1 - Cenário correspondente ao caso de uso "Registrar interesse em
empregar o PSP na gestão de projetos"
Linguagem Javascript/PHP/HTML
Número do
cenário
1 Objetivo do
usuário
Registrar interesse em empregar o PSP na gestão
de projetos
Objetivo do cenário Ilustrar a operação normal de registro de interesse em empregar o PSP
durante a gestão de projetos
Ator Passo Ação Comentários
Gerente de projeto 1 Preenche e submete formulário
para cadastro de novo projeto
Sistema 2 Efetiva cadastro Dados são válidos
Sistema 3 Solicita que o usuário responda
se tem interesse em empregar o
PSP durante a gestão do projeto
Gerente de projeto 4 Responde solicitação
Sistema 5 Registra resposta Caso seja empregado o PSP, é
habilitado painel com
informações oriundas dele
Sistema 6 Carrega tela com dados gerais do
projeto
114
Tabela A.3 - Cenário alternativo correspondente ao caso de uso "Registrar nível
do PSP a ser empregado em cada projeto"
Linguagem Javascript/PHP/HTML
Número do
cenário
2a Objetivo do
usuário
Registrar nível do PSP a ser empregado em cada
projeto em que os usuários estão vinculados
Objetivo do cenário Ilustrar a operação alternativa que pode ocorrer durante o cenário de
registro do nível do PSP a ser empregado em cada projeto, quando o
usuário não tem interesse em empregar o PSP no projeto
Ator Passo Ação Comentários
Sistema 5 Carrega tela com dados gerais
do projeto
Ocorre se resposta foi "não"
Tabela A.2 - Cenário correspondente ao caso de uso "Registrar nível do PSP a ser
empregado em cada projeto"
Linguagem Javascript/PHP/HTML
Número do
cenário
2 Objetivo do
usuário
Registrar nível do PSP a ser empregado em cada
projeto em que os usuários estão vinculados
Objetivo do cenário Ilustrar a operação normal de registro do nível do PSP a ser
empregado em cada projeto
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa um projeto
Sistema 2 Solicita que o usuário responda
se tem interesse em empregar o
PSP no projeto
Esta ação ocorre somente no
primeiro acesso ao projeto
Usuário de nível 1 3 Responde solicitação
Sistema 4 Registra resposta
Sistema 5 Solicita que o usuário selecione
o nível a ser aplicado
Ocorre se resposta foi "sim" e
oferece como opções somente
níveis já aplicados em outros
projetos concluídos e um nível
imediatamente acima do maior já
aplicado.
Usuário de nível 1 6 Seleciona nível
Sistema 7 Registra resposta São habilitadas, para o projeto,
ferramentas de apoio à aplicação
do nível do PSP selecionado
Sistema 8 Carrega tela com dados gerais do
projeto
115
Tabela A.4 - Cenário correspondente ao caso de uso "Apresentar instruções do
PSP"
Linguagem Javascript/PHP/HTML
Número do
cenário
3 Objetivo do
usuário
Visualizar instruções do PSP
Objetivo do cenário Ilustrar a operação de acesso a instruções do PSP
Ator Passo Ação Comentários
Usuário de nível 1 1 Solicita instruções Instruções devem estar disponíveis
em todo o sistema
Sistema 2 Gera e exibe instrução devida
Tabela A.5 - Cenário correspondente ao caso de uso "Apresentar sumário de
plano de projeto"
Linguagem Javascript/PHP/HTML
Número do
cenário
4 Objetivo do
usuário
Visualizar sumário de plano de projeto
Objetivo do cenário Ilustrar a operação de acesso ao sumário de plano de projeto
Ator Passo Ação Comentários
Usuário de nível 1 1 Seleciona página para acesso
ao sumário de plano de projeto
Um projeto já está selecionado
Sistema 2 Exibe sumários disponíveis Um sumário para cada programa
cadastrado
Usuário de nível 1 3 Seleciona sumário
Sistema 4 Gera e exibe sumário com
base nas informações
cadastradas
As informações constantes no
sumário referem-se ao nível do PSP
116
Tabela A.6 - Cenário correspondente ao caso de uso "Registrar conclusão de
projeto"
Linguagem Javascript/PHP/HTML
Número do
cenário
5 Objetivo do
usuário
Registrar conclusão de projeto
Objetivo do cenário Ilustrar a operação de registro de conclusão de projeto
Ator Passo Ação Comentários
Usuário de nível 1 1 Clica em botão para registrar
conclusão de projeto
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Altera status do projeto para
concluído
Tabela A.7 - Cenário correspondente ao caso de uso "Gerar relatório"
Linguagem Javascript/PHP/HTML
Número do
cenário
6 Objetivo do
usuário
Visualizar relatório em formato PDF
Objetivo do cenário Ilustrar a operação de geração de relatório em formato PDF
Ator Passo Ação Comentários
Usuário de nível 1 1 Seleciona página para geração
de relatórios
Um projeto em que o PSP é
empregado já está selecionado
Sistema 2 Exibe itens que podem compor
o relatório para cada programa
cadastrado
Quanto mais elevado o nível do PSP,
maior a quantidade de itens
disponíveis
Usuário de nível 1 3 Seleciona itens que devem
compor o relatório e submete
pedido
Sistema 4 Gera e exibe relatório em
formato PDF
117
Tabela A.8 - Cenário correspondente ao caso de uso "Exibir indicadores de
membros da equipe "
Linguagem Javascript/PHP/HTML
Número do
cenário
7 Objetivo do
usuário
Visualizar indicadores de membros da equipe
Objetivo do cenário Ilustrar a operação de exibição de indicadores de membros da equipe
Ator Passo Ação Comentários
Usuário de nível
2
1 Acessa página para exibição
de indicadores dos membros
da equipe
Um projeto em que o PSP é
empregado já está selecionado
Sistema 2 Oferece critérios para
organização dos dados
exibidos
Possibilita visualizar indicadores
relacionados a qualidade ou tempo
de execução de atividades para um
único membro de equipe ou para um
conjunto de membros
Usuário de nível
2
3 Seleciona critérios desejados
Sistema 4 Coleta informações oriundas
do PSP sobre os membros da
equipe do projeto selecionados
Sistema 5 Organiza dados e os exibe no
painel
Organização é feita de acordo com
os critérios selecionados
Requisitos referentes ao PSP 0
Tabela A.9 - Cenário correspondente ao caso de uso "Cadastrar programas a
serem construídos"
Linguagem Javascript/PHP/HTML
Número do
cenário
8 Objetivo do
usuário
Cadastrar programas a serem construídos
Objetivo do cenário Ilustrar a operação normal de cadastro de programas a serem
construídos
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
programas
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Gera formulário para cadastro
de programa
Os únicos dados solicitados são
nome e linguagem
Usuário de nível 1 3 Preenche e submete
formulário
Sistema 4 Efetiva cadastro Dados são válidos
Sistema 5 Recarrega página para
cadastro de programas
118
Tabela A.11 - Cenário correspondente ao caso de uso "Cadastrar atividades
pessoais"
Linguagem Javascript/PHP/HTML
Número do
cenário
10 Objetivo do
usuário
Cadastrar atividades pessoais
Objetivo do cenário Ilustrar a operação de cadastro das atividades pessoais
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
atividades pessoais
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas existentes
Usuário de nível 1 3 Seleciona o programa para o
qual deseja cadastrar atividades
Não existe atividade padrão
cadastrada
Sistema 4 Gera formulário para cadastro
de atividades
Destaca-se uma importante
informação que será solicitada,
dentre outras: fase do PSP a qual a
atividade pertence. Além disso, o
usuário deverá dizer se a atividade
é padrão ou não. Atividades padrão
poderão ser posteriormente
importadas.
Usuário de nível 1 5 Preenche dados sobre as
atividades
Usuário de nível 1 6 Seleciona atividades que deseja
importar e submete formulário
Sistema 7 Efetiva cadastro Dados são válidos
Sistema 8 Recarrega página para cadastro
de atividades pessoais
Tabela A.10- Cenário correspondente ao caso de uso "Apresentar atividades a
serem realizadas no projeto"
Linguagem Javascript/PHP/HTML
Número do
cenário
9 Objetivo do
usuário
Visualizar atividades a serem realizadas no projeto
Objetivo do cenário Ilustrar a operação de apresentação das atividades a serem realizadas
no projeto pelos membros da equipe
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
programa
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Coleta informações sobre as
atividades em que o usuário
está alocado
Sistema 3 Exibe informações sobre as
atividades em que o usuário
está alocado
119
Tabela A.12 - Cenário correspondente ao caso de uso "Registrar estimativa de
tempo das atividades"
Linguagem Javascript/PHP/HTML
Número do
cenário
11
Objetivo do
usuário
Registrar estimativa de tempo das atividades
Objetivo do cenário Ilustrar a operação de registro de estimativa de tempo das atividades
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para estimativa
de tempo das atividades
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas existentes
Usuário de nível 1 3 Seleciona o programa para o
qual deseja estimar o tempo
das atividades
Sistema 4 Redireciona para a página
exibindo formulário com
atividades envolvidas na
elaboração do programa e um
campo com o tempo total
estimado para realizá-las
Usuário de nível 1 5 Preenche tempo total estimado
e submete o formulário
Sistema 6 Efetiva cadastro da estimativa Dados são válidos
Sistema 7 Recarrega página para
estimativa de tempo das
atividades
120
Tabela A.13 - Cenário correspondente ao caso de uso "Disponibilizar o Time
Recording Log"
Linguagem Javascript/PHP/HTML
Número do
cenário
12 Objetivo do
usuário
Empregar o Time Recording Log
Objetivo do cenário Ilustrar a operação de disponibilização do Time Recording Log
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para uso do
Time Recording Log
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas para que o
usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o
qual deseja registrar tempo de
execução das atividades
Sistema 4 Redireciona para página
exibindo atividades envolvidas
na elaboração do programa
Usuário de nível 1 5 Seleciona uma atividade
Sistema 6 Inicia marcação do tempo de
execução da atividade
Usuário de nível 1 7 Para cada interrupção, clica em
"Interromper"
Sistema 8 Para cada vez que é solicitada
uma interrupção, pede que o
usuário escreva o motivo da
interrupção
Usuário de nível 1 9 Para cada solicitação, preenche
o motivo da interrupção e
submete resposta
Sistema 10 Registra cada motivo fornecido
e inicia interrupção
Dados são válidos
Usuário de nível 1 11 Para cada vez que retorna, clica
em "Iniciar"
Interrupção é finalizada
Usuário de nível 1 12 Clica em "Parar"
Sistema 13 Finaliza registro de tempo
121
Tabela A.14 - Cenário correspondente ao caso de uso "Apresentar o Time
Recording Log"
Linguagem Javascript/PHP/HTML
Número do
cenário
13 Objetivo do
usuário
Consultar Time Recording Log
Objetivo do cenário Ilustrar a operação de apresentação do Time Recording Log
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para consulta do
Time Recording Log
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe dados do Time
Recording Log para cada
programa
Tabela A.15 -
Cenário correspondente ao caso de uso "Disponibilizar o Defect
Recording Log"
Linguagem Javascript/PHP/HTML
Número do cenário 14 Objetivo do
usuário
Empregar o Defect Recording Log
Objetivo do cenário Ilustrar a operação de disponibilização do Defect Recording Log
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para uso do
Defect Recording Log
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas para que o
usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o
qual deseja registrar defeitos
Sistema 4 Gera formulário para registro
de defeitos
Formulário permite registro de n
defeitos e apresenta defeitos já
registrados
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva registro Dados são válidos
Sistema 7 Recarrega página para uso do
Defect Recording Log
122
Tabela A.16 - Cenário correspondente ao caso de uso "Enviar um programa para
teste"
Linguagem Javascript/PHP/HTML
Número do
cenário
15 Objetivo do
usuário
Enviar um programa para teste
Objetivo do cenário Ilustrar a operação de envio de um programa para teste
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de envio de
programa para teste
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Solicita que o usuário anexe o
arquivo com o programa a ser
testado
Usuário de nível 1 3 Seleciona e submete arquivo
Sistema 4 Faz upload do arquivo Extensão do arquivo é válida
Sistema 5 Atribui identificador ao
programa
Sistema 6 Disponibiliza arquivo para
todos os membros da equipe
do projeto responsáveis por
testes
Sistema 7 Recarrega página para envio
de programa para teste
Tabela A.17 -
Cenário correspondente ao caso de uso "Apresentar um programa
para teste"
Linguagem Javascript/PHP/HTML
Número do
cenário
16 Objetivo do
usuário
Visualizar programas para teste
Objetivo do cenário Ilustrar a operação de apresentação de um programa para teste
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de
recebimento de programa
para teste
Um projeto já está selecionado. O
usuário tem o papel de testador em
alguma atividade do projeto.
Observa-se que este cenário ocorre
mesmo em projetos em que o usuário
que está realizando os testes não
esteja empregando o PSP
Sistema 2 Exibe programas que estão
aguardando testes
Se não há programas, exibe apenas
mensagem comunicando
Usuário de nível 1 3 Seleciona um programa
Sistema 4 Remove o programa da lista
de Aguardando
Apenas altera status para constar que
a análise foi iniciada. Deste modo, o
programa não é mais visualizado por
outros testadores
Sistema 5 Redireciona para a página de
registro de dados sobre testes
realizados
123
Tabela A.18 -
Cenário correspondente ao caso de uso "Registrar dados sobre os
testes no programa"
Linguagem Javascript/PHP/HTML
Número do
cenário
17 Objetivo do
usuário
Registrar dados sobre os testes no programa
Objetivo do cenário Ilustrar a operação de registro de dados sobre os testes realizados em
programas de outros membros da equipe
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
dados sobre testes realizados
Usuário de nível 1 2 Seleciona um dos programas
recebidos
Sistema 3 Gera formulário para registro
dos dados sobre os testes
realizados com link para
download do programa
Usuário de nível 1 5 Clica no link para download
Sistema 6 Envia programa
Usuário de nível 1 7 Para cada defeito, cadastra
uma entrada no formulário
Usuário de nível 1 8 Declara se os testes estão
concluídos
Usuário de nível 1 9 Submete formulário
Sistema 10 Registra dados do formulário
entre as estatísticas do autor
do programa
Altera status de acordo com
declaração do usuário
Sistema 11 Recarrega página para registro
de dados
124
Tabela A.19 -
Cenário correspondente ao caso de uso "Cadastrar padrão de
codificação"
Linguagem Javascript/PHP/HTML
Número do
cenário
18 Objetivo do
usuário
Cadastrar padrão de codificação
Objetivo do cenário Ilustrar a operação normal de cadastro de padrão de codificação
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
padrão de codificação
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Gera formulário para cadastro
de padrão de codificação
Os únicos dados solicitados são
nome do padrão, arquivo com o
padrão e linguagem de programação
referente
Usuário de nível 1 3 Preenche e submete formulário
Sistema 4 Efetiva cadastro Dados são válidos e extensão do
arquivo é válida
Sistema 5 Recarrega página para cadastro
de padrão de codificação
Requisitos referentes ao PSP 0.1
Tabela A.20 -
Cenário correspondente ao caso de uso "Registrar dados obtidos
com as medições de software"
Linguagem Javascript/PHP/HTML
Número do cenário 19 Objetivo do
usuário
Registrar dados obtidos com as medições de
software
Objetivo do cenário Ilustrar a operação normal de registro de dados obtidos com as medições
de software
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
dados obtidos com as medições
de software
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas para que o
usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o
qual deseja registrar dados
sobre medições
Sistema 4 Gera formulário para registro de
dados obtidos com as medições
de software
Formulário apresenta dados já
registrados sobre medições
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva registro Dados são válidos
Sistema 7 Recarrega página para registro
de dados obtidos com as
medições de software
125
Tabela A.21 -
Cenário correspondente ao caso de uso "Cadastrar dados no Process
Improvement Proposal"
Linguagem Javascript/PHP/HTML
Número do cenário 20 Objetivo do
usuário
Cadastrar dados no Process Improvement Proposal
Objetivo do cenário Ilustrar a operação normal de cadastro de dados no Process Improvement
Proposal
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
dados no Process Improvement
Proposal
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Gera formulário para cadastro de
dados no Process Improvement
Proposal
Usuário de nível 1 3 Preenche e submete formulário
Sistema 4 Efetiva cadastro Dados são válidos
Sistema 5 Recarrega página para cadastro
de dados no Process
Improvement Proposal
Requisitos referentes ao PSP 1
Tabela A.22 - Cenário correspondente ao caso de uso “Cadastrar proxy"
Linguagem Javascript/PHP/HTML
Número do cenário 21 Objetivo do
usuário
Cadastrar novo proxy
Objetivo do cenário Ilustrar a operação normal de cadastro de novo proxy
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
novo proxy
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Gera formulário para cadastro de
novo proxy
Apenas nome do proxy e linguagem
de programação referente
Usuário de nível 1 3 Preenche e submete formulário
Sistema 4 Efetiva cadastro Dados são válidos
Sistema 5 Recarrega página para cadastro
de novo proxy
126
Tabela A.23 - Cenário correspondente ao caso de uso “Cadastrar categorias
funcionais de proxies”
Linguagem Javascript/PHP/HTML
Número do cenário 22 Objetivo do
usuário
Cadastrar categorias funcionais de proxies
Objetivo do cenário Ilustrar a operação normal de cadastro de categorias funcionais de proxies
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para cadastro de
categorias funcionais de proxies
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe proxies para que o usuário
selecione um
Usuário de nível 1 3 Seleciona o proxy para o qual
deseja cadastrar categorias
funcionais
Sistema 4 Gera formulário para cadastro de
categoria funcional
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para cadastro de
categorias funcionais de proxies
127
Tabela A.24 - Cenário correspondente ao caso de uso “Registrar tamanho dos proxies
em programas já construídos”
Linguagem Javascript/PHP/HTML
Número do cenário 23 Objetivo do
usuário
Registrar tamanho dos proxies em programas já
construídos
Objetivo do cenário Ilustrar a operação normal de registro de tamanho dos proxies em
programas já construídos
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
tamanho dos proxies em
programas já construídos
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe proxies para que o usuário
selecione um
Usuário de nível 1 3 Seleciona o proxy para o qual
deseja registrar tamanho
Sistema 4 Gera formulário para registro de
tamanho
Formulário permite registro do
tamanho de n programas
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva registro Dados são válidos
Sistema 7 Recarrega página para registro de
tamanho dos proxies em
programas já construídos
Tabela A.25 - Cenário correspondente ao caso de uso “Apresentar tabelas de tamanho
relativo”
Linguagem Javascript/PHP/HTML
Número do cenário 24 Objetivo do
usuário
Visualizar tabelas de tamanho relativo
Objetivo do cenário Ilustrar a operação normal de apresentação das tabelas de tamanho relativo
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para visualização
das tabelas de tamanho relativo
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe proxies para que o usuário
selecione um
Usuário de nível 1 3 Seleciona o proxy para o qual
deseja visualizar tabela
Sistema 4 Executa cálculos para geração da
tabela
Sistema 5 Exibe tabela de tamanho relativo
128
Tabela A.26 - Cenário correspondente ao caso de uso “Apresentar avaliação do proxy
definido”
Linguagem Javascript/PHP/HTML
Número do cenário 25 Objetivo do
usuário
Avaliar proxy definido
Objetivo do cenário Ilustrar a operação normal de apresentação de avaliação do proxy definido
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para avaliação do
proxy
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe proxies para que o usuário
selecione um
Usuário de nível 1 3 Seleciona o proxy que deseja
avaliar
Sistema 4 Solicita que o usuário selecione os
programas cujos dados referentes
ao proxy deseja desconsiderar ou
excluir na avaliação
Dados desconsiderados apenas não
entrarão nos cálculos da avaliação.
Dados excluídos são removidos
permanentemente.
Sistema 5 Executa cálculos para avaliação
Sistema 6 Exibe o resultado da avaliação e
um gráfico ilustrativo
Tabela A.27 - Cenário correspondente ao caso de uso “Registrar dados no Size
Estimating Template”
Linguagem Javascript/PHP/HTML
Número do cenário 26 Objetivo do
usuário
Registrar dados no Size Estimating Template
Objetivo do cenário Ilustrar a operação normal de registro de dados no Size Estimating Template
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
dados no Size Estimating Template
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja registrar dados no Size
Estimating Template
Sistema 4 Gera formulário correspondente ao
Size Estimating Template
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva registro Dados são válidos
Sistema 7 Recarrega página para registro de
dados no Size Estimating Template
129
Tabela A.28 - Cenário correspondente ao caso de uso “Apresentar estimativas
pessoais”
Linguagem Javascript/PHP/HTML
Número do cenário 27 Objetivo do
usuário
Visualizar estimativas pessoais
Objetivo do cenário Ilustrar a operação normal de apresentação de estimativas pessoais
referentes ao PSP 1
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para visualização de
estimativas pessoais
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja visualizar estimativas
pessoais
Sistema 4 Executa cálculos para geração de
estimativas
Estimativas são geradas
dinamicamente segundo o método
PROBE
Sistema 5 Exibe estimativas geradas
Tabela A.29 - Cenário correspondente ao caso de uso “Registrar tempo estimado para
cada atividade seguindo instruções do PSP 1”
Linguagem Javascript/PHP/HTML
Número do cenário 28 Objetivo do
usuário
Registrar tempo estimado para cada atividade
Objetivo do cenário Ilustrar a operação normal de registro de tempo estimado para cada atividade
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
tempo estimado para cada
atividade
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja registrar estimativa de
tempo para cada atividade
Sistema 4 Gera formulário para registro de
tempo estimado para cada
atividade
É informado ao usuário o tempo total
máximo que as atividades poderão ter
de acordo com o intervalo de previsão
de 70% do método PROBE
Usuário de nível 1 5 Preenche e submete o formulário
Sistema 6 Efetiva cadastro Dados são válidos e o somatório de
tempo das atividades está no intervalo
de previsão de 70% do método
PROBE
Sistema 7 Recarrega página para registro de
tempo estimado para cada
atividade
130
Tabela A.30 - Cenário correspondente ao caso de uso “Cadastrar dados no Test Report
Template”
Linguagem Javascript/PHP/HTML
Número do cenário 29 Objetivo do
usuário
Cadastrar dados no Test Report Template
Objetivo do cenário Ilustrar a operação de cadastro de dados no Test Report Template
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
dados no Test Report Template
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas existentes
Usuário de nível 1 3 Seleciona o programa para o qual
deseja cadastrar dados
Sistema 4 Gera formulário para cadastro de
dados no Test Report Template
Usuário de nível 1 5 Preenche e submete formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para cadastro de
dados no Test Report Template
131
Tabela A.31 - Cenário correspondente ao caso de uso “Registrar tempo estimado para
cada atividade seguindo as restrições do PSP 1.1”
Linguagem Javascript/PHP/HTML
Número do cenário 30 Objetivo do
usuário
Registrar tempo estimado para cada atividade
Objetivo do cenário Ilustrar a operação normal de registro de tempo estimado para cada atividade
de acordo com a distribuição do tempo entre as fases do PSP
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para registro de
tempo estimado para cada
atividade
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja registrar estimativa de
tempo para cada atividade
Sistema 4 Gera formulário para registro de
tempo das atividades agrupadas
por fase do PSP
É informado ao usuário o tempo total
máximo e mínimo que as fases
poderão ter de acordo com o intervalo
de previsão de 70% do método
PROBE e com a distribuição
automática de tempo entre as fases do
PSP dada pelo To Date%
Usuário de nível 1 5 Preenche e submete o formulário
Sistema 6 Efetiva cadastro e recarrega página
para registro de tempo estimado
para cada atividade
Para efetivar cadastro, dados devem
ser válidos e o somatório de tempo de
cada fase está no intervalo de previsão
de 70% do método PROBE
Requisitos referentes ao PSP 1.1
132
Tabela A.32 - Cenário correspondente ao caso de uso “Disponibilizar o Task Planning
Template”
Linguagem Javascript/PHP/HTML
Número do cenário 31 Objetivo do
usuário
Empregar o Task Planning Template
Objetivo do cenário Ilustrar a operação normal de disponibilização do Task Planning Template
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para emprego do
Task Planning Template
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja empregar o Task Planning
Template
Sistema 4 Gera formulário para emprego do
Task Planning Template
Todas as informações são
completadas automaticamente, sendo
permitido que o usuário apenas
sobrescreva a duração da atividade e a
semana planejada
Usuário de nível 1 5 Preenche e submete o formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para emprego do
Task Planning Template
Tabela A.33 - Cenário correspondente ao caso de uso “Apresentar o Schedule Planning
Template”
Linguagem Javascript/PHP/HTML
Número do cenário 32 Objetivo do usuário Consultar o Schedule Planning Template
Objetivo do cenário Ilustrar a operação normal de disponibilização do Schedule Planning
Template
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para consulta do
Schedule Planning Template
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja consultar o Schedule
Planning Template
Sistema 4 Extrai dados e gera o Schedule
Planning Template
São extraídos dados sobre cada
usuário para viabilizar a geração
completamente automatizada do
Schedule Planning Template
133
Tabela A.34 - Cenário correspondente ao caso de uso “Registrar conclusão de
atividade”
Linguagem Javascript/PHP/HTML
Número do cenário 33 Objetivo do
usuário
Registrar conclusão de atividade
Objetivo do cenário Ilustrar a operação normal de registro de conclusão de atividade
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para gerenciamento
de atividades
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja registrar conclusão de
atividade
Sistema 4 Exibe atividades envolvidas na
construção do programa
Usuário de nível 1 5 Seleciona atividades para as quais
deseja registrar conclusão
Usuário de nível 1 6 Clica em registrar conclusão
Sistema 7 Registra conclusão
Sistema 8 Recarrega página para
gerenciamento de atividades
Tabela A.35 - Cenário correspondente ao caso de uso “Apresentar o CPI”
Linguagem Javascript/PHP/HTML
Número do cenário 34 Objetivo do usuário Consultar o CPI
Objetivo do cenário Ilustrar a operação normal de apresentação do CPI
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página com um painel para
exibição de indicadores pessoais
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Executa o cálculo para obtenção do
CPI
Sistema 3 Exibe o valor do CPI Se o tempo de desenvolvimento total
real acumulado até a data for igual a
zero, é exibida mensagem informando
impossibilidade do cálculo
134
Tabela A.36 - Cenário correspondente ao caso de uso “Cadastrar o checklist de revisão
de código”
Linguagem Javascript/PHP/HTML
Número do cenário 35 Objetivo do
usuário
Cadastrar o checklist de revisão de código
Objetivo do cenário Ilustrar a operação normal de cadastro do checklist de revisão de código
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página de cadastro de
checklist de revisão de código
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe linguagens de programação
cadastradas para que o usuário
selecione uma
Usuário de nível 1 3 Seleciona linguagem
Sistema Gera formulário para cadastro de
checklist de revisão de código
Usuário de nível 1 4 Preenche e submete formulário
Sistema 5 Efetiva cadastro Dados são válidos
Sistema 6 Recarrega página para cadastro de
checklist de revisão de código
Tabela A.37 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de código”
Linguagem Javascript/PHP/HTML
Número do cenário 36 Objetivo do
usuário
Empregar o checklist de revisão de código
Objetivo do cenário Ilustrar a operação normal de registro das verificações no checklist de
revisão de código
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para emprego do
checklist de revisão de código
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja empregar o checklist de
revisão de código
Sistema 4 Gera formulário para emprego do
checklist de revisão de código
Usuário de nível 1 5 Seleciona tópicos verificados e
submete formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para emprego do
checklist de revisão de código
Requisitos referentes ao PSP 2
135
Tabela A.38 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de projeto”
Linguagem Javascript/PHP/HTML
Número do cenário 37 Objetivo do
usuário
Empregar o checklist de revisão de projeto
Objetivo do cenário Ilustrar a operação normal de registro de verificações no checklist de revisão
de projeto
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para emprego do
checklist de revisão de projeto
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja empregar o checklist de
revisão de projeto
Sistema 4 Gera formulário para emprego do
checklist de revisão de projeto
Os tópicos do checklist de revisão de
projeto seguem o padrão proposto
pelo PSP
Usuário de nível 1 5 Seleciona tópicos verificados e
submete formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para emprego do
checklist de revisão de projeto
Tabela A.39 - Cenário correspondente ao caso de uso “Apresentar indicadores de
qualidade”
Linguagem Javascript/PHP/HTML
Número do cenário 38 Objetivo do usuário Consultar indicadores de qualidade
Objetivo do cenário Ilustrar a operação normal de apresentação de indicadores de qualidade
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página com um painel de
visualização de indicadores pessoais
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Executa cálculos para obtenção dos
indicadores de qualidade do nível 2
do PSP
Indicadores são obtidos sempre
dinamicamente
Sistema 3 Exibe os indicadores de qualidade Se algum indicador não puder ser
gerado no momento da consulta, é
exibida uma mensagem de
notificação
136
Tabela A.40 - Cenário correspondente ao caso de uso “Disponibilizar modelos de
especificação de projeto”
Linguagem Javascript/PHP/HTML
Número do cenário 39 Objetivo do usuário Empregar modelos de especificação de projeto
Objetivo do cenário Ilustrar a operação normal de disponibilização de modelos de especificação de
projeto
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para emprego de
modelos de especificação de projeto
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja empregar algum modelo de
especificação de projeto
Sistema 4 Exibe modelos de especificação
disponíveis
Usuário de nível 1 5 Seleciona modelo desejado
Sistema 6 Gera formulário correspondente ao
modelo
Usuário de nível 1 7 Preenche e submete formulário
Sistema 8 Efetiva cadastro Dados são válidos
Sistema 9 Recarrega página para emprego de
modelos de especificação de projeto
Requisitos referentes ao PSP 2.1
137
Tabela A.41 - Cenário correspondente ao caso de uso “Registrar verificações no
checklist de revisão de projeto detalhado”
Linguagem Javascript/PHP/HTML
Número do cenário 40 Objetivo do
usuário
Empregar o checklist de revisão de projeto detalhado
Objetivo do cenário Ilustrar a operação normal de registro de verificações no checklist de revisão
de projeto detalhado
Ator Passo Ação Comentários
Usuário de nível 1 1 Acessa página para emprego do
checklist de revisão de projeto
detalhado
Um projeto em que o PSP é
empregado pelo usuário já está
selecionado
Sistema 2 Exibe programas cadastrados para
que o usuário selecione um
Usuário de nível 1 3 Seleciona o programa para o qual
deseja empregar o checklist de
revisão de projeto detalhado
Sistema 4 Gera formulário para emprego do
checklist de revisão de projeto
detalhado
Os tópicos do checklist de revisão de
projeto seguem o padrão proposto
pelo PSP 2.1
Usuário de nível 1 5 Seleciona tópicos verificados e
submete formulário
Sistema 6 Efetiva cadastro Dados são válidos
Sistema 7 Recarrega página para emprego do
checklist de revisão de projeto
detalhado