Antonio Marcos Neves Esteca Apoio à maturidade pessoal ... · Paulista “Júlio de Mesquita...

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


(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


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


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


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.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.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.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.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


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


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


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


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



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


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


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



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


Reutilizadas (R) 169 169


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.


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



Linguagem C


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



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



Linguagem C


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.



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


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


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


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;



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


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



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


que o sistema deve permitir que os usuários executem, tendo como base o PSP 0.1. Na Tabela


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


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


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



(continua)


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


(conclusão)


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


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.


49



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



que o sistema deve permitir que os usuários executem, tendo como base o PSP 2. Na Tabela



50



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


revisão de projeto


já realizadas no projeto de cada programa


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



que o sistema deve permitir que os usuários executem, tendo como base o PSP 2.1. Na Tabela





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


revisão de projeto detalhado


já realizadas no projeto de cada programa


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


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


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.


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


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


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.


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


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"


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


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"


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


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"


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


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"


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


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"


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


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"


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


Usuário de nível 1 1 Seleciona página para geração

de relatórios


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 "


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


Usuário de nível

2

1 Acessa página para exibição

de indicadores dos membros

da equipe


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"


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


Usuário de nível 1 1 Acessa página de cadastro de

programas



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 5 Recarrega página para

cadastro de programas

118

Tabela A.11 - Cenário correspondente ao caso de uso "Cadastrar atividades

pessoais"


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



atividades pessoais



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


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 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"


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



programa



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"


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


Usuário de nível 1 1 Acessa página para estimativa

de tempo das atividades



selecionado



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


estimativa de tempo das

atividades

120

Tabela A.13 - Cenário correspondente ao caso de uso "Disponibilizar o Time

Recording Log"


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


Usuário de nível 1 1 Acessa página para uso do

Time Recording Log



selecionado

Sistema 2 Exibe programas para que o

usuário selecione um


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"


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


Usuário de nível 1 1 Acessa página para consulta do

Time Recording Log



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"


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


Usuário de nível 1 1 Acessa página para uso do

Defect Recording Log



selecionado




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"


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


Usuário de nível 1 1 Acessa página de envio de

programa para teste



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"


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


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"


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


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"


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



padrão de codificação



selecionado


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


Sistema 4 Efetiva cadastro Dados são válidos e extensão do

arquivo é válida


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"



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



dados obtidos com as medições

de software



selecionado




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



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"



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



dados no Process Improvement

Proposal



selecionado

Sistema 2 Gera formulário para cadastro de

dados no Process Improvement

Proposal




de dados no Process

Improvement Proposal


Tabela A.22 - Cenário correspondente ao caso de uso “Cadastrar proxy"



usuário

Cadastrar novo proxy

Objetivo do cenário Ilustrar a operação normal de cadastro de novo proxy



novo proxy



selecionado


novo proxy

Apenas nome do proxy e linguagem

de programação referente




de novo proxy

126

Tabela A.23 - Cenário correspondente ao caso de uso “Cadastrar categorias

funcionais de proxies”



usuário

Cadastrar categorias funcionais de proxies

Objetivo do cenário Ilustrar a operação normal de cadastro de categorias funcionais de proxies


Usuário de nível 1 1 Acessa página para cadastro de

categorias funcionais de proxies



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


categoria funcional



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”



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




tamanho dos proxies em




selecionado


selecione um


deseja registrar tamanho


tamanho

Formulário permite registro do

tamanho de n programas



Sistema 7 Recarrega página para registro de

tamanho dos proxies em


Tabela A.25 - Cenário correspondente ao caso de uso “Apresentar tabelas de tamanho

relativo”



usuário

Visualizar tabelas de tamanho relativo

Objetivo do cenário Ilustrar a operação normal de apresentação das tabelas de tamanho relativo


Usuário de nível 1 1 Acessa página para visualização

das tabelas de tamanho relativo



selecionado


selecione um


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”



usuário

Avaliar proxy definido

Objetivo do cenário Ilustrar a operação normal de apresentação de avaliação do proxy definido


Usuário de nível 1 1 Acessa página para avaliação do

proxy



selecionado


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”



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



dados no Size Estimating Template



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




dados no Size Estimating Template

129

Tabela A.28 - Cenário correspondente ao caso de uso “Apresentar estimativas

pessoais”



usuário

Visualizar estimativas pessoais

Objetivo do cenário Ilustrar a operação normal de apresentação de estimativas pessoais

referentes ao PSP 1


Usuário de nível 1 1 Acessa página para visualização de

estimativas pessoais



selecionado




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


cada atividade seguindo instruções do PSP 1”



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



tempo estimado para cada

atividade



selecionado




deseja registrar estimativa de

tempo para cada atividade



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



atividade

130

Tabela A.30 - Cenário correspondente ao caso de uso “Cadastrar dados no Test Report

Template”



usuário

Cadastrar dados no Test Report Template

Objetivo do cenário Ilustrar a operação de cadastro de dados no Test Report Template



dados no Test Report Template



selecionado



deseja cadastrar dados







131


cada atividade seguindo as restrições do PSP 1.1”



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




atividade



selecionado




deseja registrar estimativa de

tempo para cada atividade


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%


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


132

Tabela A.32 - Cenário correspondente ao caso de uso “Disponibilizar o Task Planning

Template”



usuário

Empregar o Task Planning Template

Objetivo do cenário Ilustrar a operação normal de disponibilização do Task Planning Template


Usuário de nível 1 1 Acessa página para emprego do

Task Planning Template



selecionado




deseja empregar o Task Planning

Template

Sistema 4 Gera formulário para emprego do


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



Sistema 7 Recarrega página para emprego do


Tabela A.33 - Cenário correspondente ao caso de uso “Apresentar o Schedule Planning

Template”


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


Usuário de nível 1 1 Acessa página para consulta do

Schedule Planning Template



selecionado




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”



usuário

Registrar conclusão de atividade

Objetivo do cenário Ilustrar a operação normal de registro de conclusão de atividade


Usuário de nível 1 1 Acessa página para gerenciamento

de atividades



selecionado




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


gerenciamento de atividades

Tabela A.35 - Cenário correspondente ao caso de uso “Apresentar o CPI”


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


Usuário de nível 1 1 Acessa página com um painel para

exibição de indicadores pessoais



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”



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



checklist de revisão de código



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

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






selecionado




deseja empregar o checklist de

revisão de código



Usuário de nível 1 5 Seleciona tópicos verificados e

submete formulário





135


checklist de revisão de projeto”



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



checklist de revisão de projeto



selecionado





revisão de projeto



Os tópicos do checklist de revisão de

projeto seguem o padrão proposto

pelo PSP


submete formulário




Tabela A.39 - Cenário correspondente ao caso de uso “Apresentar indicadores de

qualidade”


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


Usuário de nível 1 1 Acessa página com um painel de

visualização de indicadores pessoais



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”


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


Usuário de nível 1 1 Acessa página para emprego de

modelos de especificação de projeto



selecionado




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



Sistema 9 Recarrega página para emprego de

modelos de especificação de projeto


137


checklist de revisão de projeto detalhado”



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




detalhado



selecionado





revisão de projeto detalhado



detalhado

Os tópicos do checklist de revisão de

projeto seguem o padrão proposto

pelo PSP 2.1


submete formulário




detalhado

Antonio Marcos Neves Esteca Apoio à maturidade pessoal ... · Paulista “Júlio de Mesquita...

Documents

Transcript of Antonio Marcos Neves Esteca Apoio à maturidade pessoal ... · Paulista “Júlio de Mesquita...