MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO
EDUARDO ALVES DE OLIVEIRA
UM PROCESSO DE ACOMPANHAMENTO DE PRODUTIVIDADE
PARA O DESENVOLVIMENTO DE SOFTWARE
Rio de Janeiro
2014
INSTITUTO MILITAR DE ENGENHARIA
EDUARDO ALVES DE OLIVEIRA
UM PROCESSO DE ACOMPANHAMENTO DE
PRODUTIVIDADE PARA O DESENVOLVIMENTO DE
SOFTWARE
Dissertação de Mestrado apresentada ao Curso de
Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção
do título de Mestre em Sistemas e Computação.
Orientador: Prof. Ricardo Choren Noya - D.Sc.
Rio de Janeiro
2014
c2014
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80-Praia Vermelha
Rio de Janeiro-RJ CEP 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo
em base de dados, armazenar em computador, microlmar ou adotar qualquer forma de
arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modicação de seu texto, em qualquer meio que esteja ou venha
a ser xado, para pesquisa acadêmica, comentários e citações, desde que sem nalidade
comercial e que seja feita a referência bibliográca completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s)
orientador(es).
005.1
O48p
Oliveira, Eduardo Alves de
Um processo de acompanhamento de produtividade
para o desenvolvimento de software / Eduardo Alves de
Oliveira, orientado por Ricardo Choren Noya - Rio de
Janeiro: Instituto Militar de Engenharia, 2014.
99p. : il
Dissertação (mestrado) - Instituto Militar de Engenharia, Rio de Janeiro, 2014.
1. Curso de Sistemas e Computação - teses e dissertações. 2. Processo de Desenvolvimento de Software. I.
Noya, Ricardo Choren. II. Título. III. Instituto Militar
de Engenharia.
2
INSTITUTO MILITAR DE ENGENHARIA
EDUARDO ALVES DE OLIVEIRA
UM PROCESSO DE ACOMPANHAMENTO DE
PRODUTIVIDADE PARA O DESENVOLVIMENTO DE
SOFTWARE
Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção do
título de Mestre em Sistemas e Computação.
Orientadores: Prof. Ricardo Choren Noya - D.Sc.
Orientadore:
Aprovada em 15 de julho de 2014 pela seguinte Banca Examinadora:
Prof. Ricardo Choren Noya - D.Sc. do IME - Presidente
Prof. Gustavo Robichez de Carvalho - D.Sc., da PUC-Rio
Prof. Ronaldo Ribeiro Goldschmidt - D.Sc., do IME
Rio de Janeiro
2014
3
Dedico este estudo a minha família, em especial a minha amada esposa Luciana e ao meu
lho Gustavo, minhas eternas paixões e felicidades.
4
AGRADECIMENTOS
Agradeço a todas as pessoas que contribuíram com o desenvolvimento desta dissertação de mestrado, tenha sido por meio de críticas, idéias, apoio, incentivo ou qualquer
outra forma de auxílio. Em especial, desejo agradecer ao meu professor orientador que
desde o início deste estudo acreditou em minhas idéias e no meu trabalho.
Por m, a todos os professores e funcionários do Departamento de Engenharia de
Sistemas (SE/8) do Instituto Militar de Engenharia.
Eduardo Alves de Oliveira
5
O único lugar onde o sucesso vem antes do trabalho
é no dicionário. - Albert Einstein
6
SUMÁRIO
LISTA DE ILUSTRAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
LISTA DE ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1
Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3
Contribuições Esperadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4
Estrutura do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2
CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1
Processo de Desenvolvimento de Software - PDS . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2
Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3
Indicador de Produtividade no PDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Produtividade usando Linhas de Código (LOC) . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Produtividade usando Pontos de Caso de Uso (PCU) . . . . . . . . . . . . . . . . . . . . 29
2.3.3 Produtividade usando Análise por Pontos de Função (APF) . . . . . . . . . . . . . . . 30
2.4
Regras de Associação e o Algoritmo APRIORI . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.1 Ferramenta de Mineração de Dados WEKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3
MÉTODO PARA MONITORAMENTO DA PRODUTIVIDADE . 35
3.1
Fase do Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 Denição da Produtividade de Acompanhamento de um PDS (PAP) . . . . . . . 36
3.1.2 Atividade 1 - Obter Informações da Iteração do Projeto. . . . . . . . . . . . . . . . . . . 38
3.1.3 Atividade 2 - Estimar o Tamanho e o Esforço da Iteração. . . . . . . . . . . . . . . . . 39
3.1.4 Atividade 3 - Calcular o Tamanho Final da Iteração e a PAP ou PFP. . . . . . . 41
3.2
Fase do Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.1 Atividade 4 - Aplicar o Checklist do PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3
Atividade 5 - Denir Relatório de Ações de Ajuste (RAA) . . . . . . . . . . . . . . . . 46
7
4
ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1
Iteração 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.1 Atividade 1 - Obter Informações da Iteração do Projeto. . . . . . . . . . . . . . . . . . . 52
4.1.2 Atividade 2 - Estimar o Tamanho e o Esforço da Iteração. . . . . . . . . . . . . . . . . 54
4.1.3 Atividade 3 - Calcular o Tamanho Final da Iteração e a PAP ou PFP . . . . . . 54
4.1.4 Atividade 4 - Aplicar o Checklist do PMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.5 Atividade 5 - Denir o RAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2
Iteração 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.1 Atividade 1 - Obter Informações da Iteração do Projeto. . . . . . . . . . . . . . . . . . . 59
4.2.2 Atividade 2 - Estimar o Tamanho e o Esforço da Iteração. . . . . . . . . . . . . . . . . 60
4.2.3 Atividade 3 - Calcular o Tamanho Final da Iteração e a PAP ou PFP. . . . . . . 60
4.2.4 Atividade 4 - Aplicar o Checklist do PMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.5 Atividade 5 - Denir o RAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3
Iteração 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Atividade 1 - Obter Informações da Iteração do Projeto. . . . . . . . . . . . . . . . . . . 64
4.3.2 Atividade 2 - Estimar o Tamanho e o Esforço da Iteração. . . . . . . . . . . . . . . . . 65
4.3.3 Atividade 3 - Calcular o Tamanho Final da Iteração e a PAP ou PFP. . . . . . . 66
4.3.4 Atividade 4 - Aplicar o Checklist do PMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.5 Atividade 5 - Denir o RAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.1 O PMP e o Gerenciamento de Contratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5
TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1
Análise do Valor Agregado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2
Regressão Linear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3
Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6
CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2
Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.1 Construção de uma Ferramento de Apoio ao PMP . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.2 Denição ou Evolução de um Modelo Estatístico para a Base Histórica
de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8
7
REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8
APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.1
Apêndice 1 - Atributos da Base Histórica de Projetos da Empresa Avaliada . 85
8.2
Apêndice 2 - Tipos de PDS da Empresa Avaliada . . . . . . . . . . . . . . . . . . . . . . . . 86
8.3
Apêndice 3 - Questionário de Avaliação dos Projetos da Base Histórica . . . . . 87
8.4
Apêndice 4 - Checklist do PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.4.1 O Checklist do PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.4.2 Denição e Submissão do Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.4.3 Fatores que Impactam a PAP e o Checklist do PMP . . . . . . . . . . . . . . . . . . . . . 95
8.5
Apêndice 5 - Modelo de RAA do PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9
LISTA DE ILUSTRAÇÕES
FIG.2.1
Modelo Simplicado de Produtividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
FIG.2.2
Fórmula de Suporte do Algoritmo APRIORI . . . . . . . . . . . . . . . . . . . . . . . . 34
FIG.2.3
Métodos Implementados pelo WEKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
FIG.3.1
Gráco SPEM (SPEM, 2008) do PMP (fase Monitoramento) . . . . . . . . . . 37
FIG.3.2
Exemplo da PDI preenchida na Atividade - Obter Informações da
Iteração do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
FIG.3.3
Exemplo da PDI preenchida na Atividade - Estimar o Tamanho e
o Esforço da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
FIG.3.4
Exemplo da PDI preenchida na Atividade - Calcular o Tamanho
Final da Iteração e a PAP ou PFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
FIG.3.5
Gráco SPEM (SPEM, 2008) do PMP (fase Diagnóstico) . . . . . . . . . . . . . 46
FIG.4.1
Exemplo da PDI preenchida na Atividade de Monitoramento Obter Informações da Iteração do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 53
FIG.4.2
Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o Tamanho e o Esforço da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . 55
FIG.4.3
Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o Tamanho Final da Iteração e a PAP ou PFP . . . . . . . . . . . . . . . . 57
FIG.4.4
Exemplo da PDI preenchida na Atividade de Monitoramento Obter Informações da Iteração do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 60
FIG.4.5
Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o Tamanho e Esforço da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
FIG.4.6
Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o Tamanho Final da Iteração e a PAP ou PFP . . . . . . . . . . . . . . . . 63
FIG.4.7
Exemplo da PDI preenchida na Atividade de Monitoramento Obter Informações da Iteração do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 65
FIG.4.8
Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o Tamanho e Esforço da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
FIG.4.9
Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o Tamanho Final da Iteração e a PAP ou PFP . . . . . . . . . . . . . . . . 68
FIG.5.1
Exemplo de Gráco do Valor Agregado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10
FIG.5.2
Exemplo de Regressão Linear - Diagrama de Dispersão . . . . . . . . . . . . . . . 75
FIG.8.1
Tela de Parâmetros do algoritmo APRIORI do WEKA . . . . . . . . . . . . . . . 96
11
LISTA DE TABELAS
TAB.5.1
Comparação entre os trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . 76
12
LISTA DE ABREVIATURAS
ABREVIATURAS
ANS
-
Acordo de Nível de Serviço
APF
-
Análise de Pontos por Função
ARFF
-
Attribute-Relation File Format
CBO
-
Coupling Between Object Classes
CC
-
Complexidade Ciclomática
COCOMO
-
Common Software Measurement International Consortium
CPM
-
Counting Practices Manual
CS
-
Class Size
DI
-
Depth of the Inheritance Tree
EVA
-
Técnica do Valor Agregado
FFP
-
Full Function Point
HH
-
Homem Hora
IFPUG
-
International Function Point User Group
ISO
-
International Organization for Standardization
LCOM
-
Lack of Cohesion in Methods
LOC
-
Lines of Code
NESMA
-
Netherlands Software Metrics Association
NOA
-
Number of Operations Added by a Subclass
NOC
-
Number of Children
NOO
-
Number of Operations Overriden by a Subclass
PAP
-
Produtividade de Acompanhamento de Projeto
PCU
-
Pontos de Caso de Uso
PDI
-
Planilha com os Dados da Iteração
PDS
-
Processo de Desenvolvimento de Software
PEI
-
Produtividade Estimada Inicial
PF
-
Ponto de Função
PFP
-
Produtividade Final do Projeto
PHP
-
Acrônimo Recursivo para Hypertext Preprocessor
PMI
-
Project Management Institute
13
PMP
-
Processo de Monitoramento de Produtividade
RAA
-
Relatório de Ações de Ajuste
RAP
-
Relatório de Acompanhamento do Projeto
RFC
-
Response for a Class
SI
-
Specialization index
SPEM
-
Software & Systems Process Engineering Meta-Model Speci-
UKSMA
-
cation
United Kingdom Software Metrics Association
WEKA
-
Waikato Enviroment for Knowledge Analysis
WMC
-
Weighted Methods per Class
14
RESUMO
Este estudo demonstra de forma quantitativa e qualitativa os impactos positivos e
negativos na produtividade dos projetos de software. O objetivo é ajudar o gerente de
projeto no monitoramento da produtividade do desenvolvimento do software (OLIVEIRA,
2013). O processo de monitoramento de produtividade (PMP) de um PDS deve ser
utilizado em paralelo com o processo de desenvolvimento de software (PDS) para controlar
a produtividade do projeto. O estudo de impactos na produtividade auxilia e direciona as
decisões que o gerente de projeto deve tomar no planejamento e acompanhamento de seus
projetos. Para chegarmos as conclusões deste estudo foi analisada uma base histórica de
projetos de um empresa de desenvolvimento de software que possui uma grande variedade
de tipos diferentes de sistemas, tecnologias, linguagens e processos de desenvolvimento.
Para complementar a base histórica, um questionário foi respondido por uma amostragem
qualitativa de projetos desta base histórica. Grande parte das questões são relacionadas a
questões qualitativas dos impactos na produtividade dos projetos. Os potenciais impactos
na produtividade dos projetos foram obtidos de pesquisa bibliográca.
15
ABSTRACT
This study shows the quantitative and qualitative impacts that positively and negatively the productivity of software projects. The objective is to assist the project manager
in the use of the monitoring software productivity (OLIVEIRA, 2013). This productivity
monitoring process (PMP) of must be performed in parallel to the software development
process (SDP) controlling project productivity. The study of the impacts assists and
directs decision making of a project manager in the planning and monitoring of their
projects. To reach the conclusions of this study analyzes were performed on a database
project for a software development corporate with a wide range of systems, technologies,
languages and development processes. For complete the historical basis, a questionnaire
was answered by a qualitative sample of projects of this historical basis. The most questionnaire questions are qualitative issues that impact the productivity of a project. These
potential impacts were obtained from bibliographical studies.
16
1 INTRODUÇÃO
Empresas de desenvolvimento de software estão cada vez mais competitivas. Para
conhecer o quanto uma empresa é competitiva é necessário medir a sua produtividade
e qualidade no seu processo de desenvolvimento de software (PDS) (JOSEPH, 2011).
Saber a produtividade de um PDS, permite que a empresa melhore a sua previsibilidade
em alguns parâmetros de projeto como esforço, prazo e custo.
O PDS de uma organização determina as áreas chaves que um projeto de software
deve atender para ter uma efetiva utilização da engenharia de software. O PDS garante
o controle gerencial do projeto através de métodos, gera produtos de trabalho, estabelece
marcos de controle, garante a qualidade e a gestão de mudanças (PRESSMAN, 2011).
O resultado nal de um projeto é ter um produto que atende ao escopo denido pelo(s)
usuário(s) especicador(es).
O escopo de um projeto de software é composto por dados e controles que precisam
ser processados (PRESSMAN, 2011). A qualidade de um projeto entregue está diretamente ligada com a entrega ou não do escopo denido pelo usuário especicador através
das funcionalidades. Este escopo deve atender desempenho, normas de desenvolvimento
explicitamente declaradas e caracterísiticas implícitas de qualquer aplicação de software
(PRESSMAN, 2011).
A denição do escopo inicial deve ser feita na fase de planejamento inicial do projeto
(PRESSMAN, 2011). Nesta fase, tanto o prazo quanto o custo precisam ser estimados
utilizando o escopo inicial denido. A viabilidade de um projeto passa pela análise desses
dois parâmetros. Antes do início de um projeto, os usuários e gestores querem saber o
prazo e custo estimados com a maior acurácia possível (AGRESTI, 2010). Assim, podem
determinar se a continuidade do projeto é viável ou não. Para se chegar ao cálculo de
prazo e custo é necessário medir o tamanho do projeto. Para isso é utilizada uma métrica
de software.
1.1 PROBLEMA
Embora seja importante medir a Produtividade Final do Projeto (PFP), esta medida
dicilmente serve como parâmetro de acompanhamento de projetos, pois somente ao nal
17
de cada projeto tem-se o prazo e custo reais. Assim, quando a produtividade real for
medida, o projeto já se encerrou. Se ocorreu atraso na entrega e/ou aumento de custos,
estes não foram avaliados durante o ciclo de projeto (OLIVEIRA, 2013).
Vários motivos podem acarretar desvios nos parâmetros estimados de um projeto. Um
dos mais comuns é a variação do escopo do projeto (JONES, 1998). Ou seja, é preciso
continuamente avaliar se houve aumento de escopo nos requisitos do usuário. A taxa de
crescimento de escopo de requisitos chega a 2% ao mês do momento da especicação até
a codicação (JONES, 2007). Também devem ser avaliadas as alterações de requisitos já
especicados e aprovados pelo usuário, pois acarretam aumento de esforço decorrente do
retrabalho.
Assim, ter apenas as estimativas iniciais não ajuda a realizar as ações de ajuste no
processo de desenvolvimento. Essas ações tentam recolocar o projeto dentro da Produtividade Estimada Inicialmente (PEI). Ao longo do projeto a produtividade deve ser medida,
assim o gestor do projeto poderá tomar ações de correção e ajuste no PDS com objetivo
de corrigir eventuais desvios.
Já existem outras técnicas de monitoriamento de produtividade de um PDS, como por
exemplo, a do Valor Agregado (PMI, 2008) e outras que se preocupam com as estimativas
iniciais dos projetos como, por exemplo, a de Regressão Linear (MACDONELL, 1996).
Não é objetivo deste trabalho aprofundar-se nestas técnicas, pois as mesmas não atendem
por completo o escopo do estudo.
Porém, nenhuma dessas técnicas analisa a variação da produtividade, durante o ciclo
de desenvolvimento de projeto, através das funcionalidades que fazem parte do escopo do
projeto.
O gerente de projeto não consegue fazer uma correlação entre as causas da mudança
da produtividade e as funcionalidades que estão ocasionando esta mudança. Da mesma
forma, o PDS não é avaliado pelas funcionalidades atendidas pelo projeto, mas sim por
outros parâmetros que não permitem uma fácil identicação de qual(is) fase(s) do PDS
está(ão) apresentando mudança(s) em sua(s) produtividade(s) planejada(s) inicialmente.
A falta dessa análise acarreta perda de controle: do escopo funcional do projeto, das
funções que estão impactando a produtividade do PDS, e por consequência, que funções
do escopo estão impactando o custo e o prazo do projeto.
18
1.2 OBJETIVO
O objetivo deste trabalho é denir um processo de monitoramento da produtividade
(PMP) de um PDS a m de permitir que o gestor de um projeto acompanhe a produtividade de um PDS através das funcionalidades do escopo do projeto e de uma métrica
de tamanho funcional. O propósito é saber se o prazo e o custo mantêm-se dentro da
estimativa inicial, ao longo do ciclo de desenvolvimento do projeto, reestimando estes
parâmetros a cada acompanhamento do projeto.
A produtividade do PDS precisa ser medida em cada marco de acompanhamento para
que o gestor do projeto saiba se o PDS está adequado ou se precisa de ajustes para
atender a PEI. Dessa forma, a produtividade de acompanhamento medida pode impactar
diretamente no PDS utilizado.
Este trabalho usa uma métrica funcional chamada de Análise de Pontos por Função
(APF) por diversos motivos:
• O acompanhamento através das funcionalidades facilita a gestão do aumento de
escopo e retrabalho no projeto;
• Normaliza todos os projetos facilitando a comparação entre eles independente de
quais funcionalidades estão presentes no escopo;
• Permite a criação de uma base histórica que é uma referência importante para um
gestor de projeto que precisa prever a produtividade inicial de novos projetos;
• O tamanho funcional de toda funcionalidade pode ser particionado por fase do
PDS, possibilitando controlar a produtividade de um PDS por fase (por exemplo:
requisitos, construção, testes);
• Permite-se ter uma rastreabilidade entre as funcões medidas e as funcionalidades do
projeto de forma direta, ajudando o gestor do projeto na avaliação de impacto no
caso de alteração de algum requisito do projeto ou aplicação;
• A comunicação entre gestor do projeto e usuário especicador ca facilitada, pois
toda a medição funcional é rastreável para um requisito funcional especicado pelo
usuário.
19
1.3 CONTRIBUIÇÕES ESPERADAS
As contribuições esperadas deste trabalho são:
• Monitorar a produtividade de um PDS ao longo do ciclo de vida de um projeto.
Dar ao gerente de projeto um meio de acompanhar a produtividade do PDS possibilitando ajustá-lo antes de seu término, evitando atrasos e aumento de custo do
projeto;
• Detectar fatores que impactam a produtividade de um PDS. Mostrar ao gerente
de projeto os fatores que estão provocando aumento ou perda de produtividade do
PDS em relação a produtividade planejada inicialmente no projeto;
• Auxiliar o gerente de projeto, quando for necessário, sugerindo mudanças no PDS.
Apresentar possíveis mudanças no PDS para ajuste de sua produtividade.
1.4 ESTRUTURA DO TEXTO
Este trabalho está estruturado da seguinte forma: a seção 2 apresenta os conceitos básicos
utilizados para a denição do PMP; a seção 3 apresenta a metodologia de acompanhamento, inicia-se demonstrando a fase de monitoramento e naliza descrevendo a fase de
diagnóstico; a seção 4 apresenta um estudo de caso utilizando a metodologia proposta; a
seção 5 apresenta trabalhos relacionados e a seção 6 conclusões, contribuições e trabalhos
futuros.
20
2 CONCEITOS BÁSICOS
Nesta capítulo são apresentados conceitos básicos que precisam ser aprendidos para o
uso correto do processo proposto.
2.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE - PDS
O processo de desenvolvimento de software foi criado para tornar o desenvolvimento de
um software em algo conável e com a qualidade esperada pelo usuário que especicou as
funcionalidades que deve possuir (LARMAN, 2004).
Também pode ser denido como um conjunto de atividades, métodos, práticas e mudanças que tem como objetivo a construção de um produto entregável ao usuário que
solicitou o produto (PAULA, 2001).
Na construção ou manutenção de um software é importante termos um processo que
nos indique a sequencia do que precisa ser feito para a construção e entrega do produto. Esse processo é um conjunto de passos que estão em uma determinada ordem para
execução. Os passos seguidos envolvem atividades, limitações e recursos que produzem
resultados (PRESSMAN, 2011; PFLEEGER, 2001).
Um processo de desenvolvimento de software dentro de uma empresa, quando maduro,
trás estabilidade, controle e organização para o desenvolvimento de software. Este processo deve possuir documentos bem detalhados que devem dizer a quem os utiliza quando
algo será realizado, quem irá fazer, os insumos e o produto entregue ao nal do ciclo.
A seguir são enumeradas mais características que um processo no desenvolvimento de
projetos de software deve possui (AMBLER, 1999):
a) Adequação ao desenvolvimento de software;
b) Fácilidade no entendimento de como o software será produzido, por todos os envolvidos na construção ou manutenção do projeto;
c) Busca do reuso de componentes para minimizar esforços;
d) Melhora no gerenciamento da complexidade do software;
21
e) Absorção de outras tecnologia de forma rápida e sem grandes ajustes no próprio
processo.
Usar o processo de desenvolvimento em um projeto de software exige que o mesmo
seja monitorado ao longo do PDS. Para isto existe a fase de monitoramento do projeto,
que já está previsto como boa prática de gerenciamento de projetos, conforme denido
no PMBok (Project Management Body of Knowledge ) (PMI, 2008). Porém não existe
uma forma única de se acompanhar o projeto. Existem algumas técnicas que fazem este
acompanhamento, como por exemplo do Valor Agregado (PMI, 2008).
É importante saber que o processo de desenvolvimento a ser adotado depende do
software que está sendo construído. Os passos a serem executados devem ser os que
melhor acomodam as necessidades do projeto e as características da equipe. Para avaliar
o processo é necessario medir o quanto ele está sendo produtivo. Se a sua produtividade
não está adequada, o gerente de projeto deve ajustá-lo para atender os objetivos acordados
entre a equipe do projeto e o usuário especicador.
Portanto, analisar e avaliar a produtividade do processo de desenvolvimento de software adotado por uma empresa é essencial para estabelecer se este está sendo executado
de forma adequado.
Este estudo é dedicado em denir uma metodologia de acompanhamento da produtividade de um processo de desenvolvimento de software baseado em uma métrica funcional.
O autor percebe que os métodos tradicionais apresentão diculdades em monitorar
a produtividade do processo do ciclo de desenvolvimento, desde o momento de sua estimativa, passando pela motivação dos impactos que ocasionaram mudanças nesta e o
gerenciamento de uma base histórica de produtividade nais de projetos realizados com
sucesso ou não.
Ao vericar a produtividade de um PDS, durante o seu ciclo de desenvolvimento, o
gerente de projeto sabe se o projeto está apresentando riscos de atrasar ou aumentar os
seus custo de desenvolvimento. Neste estudo, para realizar essa vericação o gerente de
projeto precisa medir o projeto utilizando uma métrica de software.
2.2 MÉTRICAS DE SOFTWARE
Uma métrica é a medição de um atributo (propriedades ou características) de uma determinada entidade (produto, processo ou recursos). Exemplos:
22
a) Tamanho do produto de software (ex: número de linhas de código);
b) Número de pessoas necessárias para implementar um caso de uso;
c) Número de defeitos encontrados por fase de desenvolvimento;
d) Esforço para a realização de uma tarefa;
e) Tempo para a realização de uma tarefa;
f) Custo para a realização de uma tarefa;
g) Grau de satisfação do cliente (ex: adequação do produto ao propósito, conformidade
do produto com a especicação).
Vários motivos fazem a medição de software ser importante. A seguir são listados
alguns deles:
a) Entender e aperfeiçoar o processo de desenvolvimento;
b) Melhorar a gerência de projetos e o relacionamento com clientes;
c) Reduzir frustrações e pressões de cronograma;
d) Gerenciar contratos de software;
e) Indicar a qualidade de um produto de software;
f) Avaliar a produtividade do processo;
g) Avaliar os benefícios (em termos de produtividade e qualidade) de novos métodos e
ferramentas de engenharia de software;
h) Avaliar retorno de investimento;
i) Identicar as melhores práticas de desenvolvimento de software;
j) Embasar solicitações de novas ferramentas e treinamento;
k) Avaliar o impacto da variação de um ou mais atributos do produto ou do processo
na qualidade e/ou produtividade;
l) Formar uma baseline para estimativas;
23
m) Melhorar a exatidão das estimativas;
n) Oferecer dados qualitativos e quantitativos ao gerenciamento de desenvolvimento de
software, de forma a realizar melhorias em todo o processo de desenvolvimento de
software.
São consideradas propriedades desejáveis de uma métrica de software:
a) Facilmente calculada, entendida e testada;
b) Passível de estudos estatísticos;
c) Expressa em alguma unidade;
d) Obtida o mais cedo possível no ciclo de vida do software;
e) Passível de automação;
f) Repetível e independente do observador;
g) Sugere uma estratégia de melhoria.
As métricas de software são divididas em categorias, são elas:
a) Métricas diretas (fundamentais ou básicas): medida realizada em termos de atributos observados. Por exemplo: custo, esforço, no. linhas de código, capacidade de
memória, no. páginas, no. diagramas, etc;
b) Métricas indiretas (derivadas): medidas obtidas a partir de outras métricas. Por
exemplo: complexidade, eciência, conabilidade, facilidade de manutenção;
c) Métricas orientadas a tamanho: são medidas diretas do tamanho dos artefatos de
software associados ao processo por meio do qual o software é desenvolvido. Por
exemplo: esforço, custo, no. KLOC, no. páginas de documentação, no. erros;
d) Métricas orientadas por função: consiste em um método para medição de software
do ponto de vista do usuário, determinando de forma consistente o tamanho e a
complexidade de um software. Por exemplo: APF, COSMIC, Mark II;
e) Métricas de produtividade: concentram-se na saída do processo de engenharia de
software. Por exemplo: no. de casos de uso/iteração;
24
f) Métricas de qualidade: oferecem uma indicação de quanto o software se ajusta às
exigências implícitas e explícitas do cliente. Por exemplo: erros/fase;
g) Métricas técnicas: concentram-se nas características do software e não no processo
por meio do qual o software foi desenvolvido. Por exemplo: complexidade lógica e
grau de manutenibilidade.
Uma métrica deve ser válida (quantica o que queremos medir), conável (produz
os mesmos resultados dadas as mesmas condições) e prática (barata, fácil de computar
e de interpretar). Para medição de software existem dois contextos: o de Produto (por
exemplo qualidade) e o de Processo (por exemplo produtividade). O processo apresentado
neste estudo foca na medição do processo e não do produto gerado pelo processo.
As métricas de software são meios fundamentais para avaliar a modularidade do software e detectar falhas de projeto (CHIDAMBER, 1994) (FENTON, 1996). Elas exploram
propriedades do módulo quanticáveis, tais como acoplamento de classe, coesão e tamanho
da interface (LANZA, 2006). Geralmente as métricas tradicionais são aplicadas de forma
isolada e sem um processo de validação de sua aplicação em vários ambientes com diferentes características e tecnologias. Por esse motivo vêm sendo consideradas insatisfatórias
(MILLS, 1998).
São exemplos de métricas de software tradicionais (SEIBT, 2011):
a) Linhas de código fonte (LOC). Utiliza a quantidade de linhas de código de uma
aplicação para medir o seu tamanho;
b) Complexidade ciclomática (CC). Fornece uma medição quantitativa da complexidade lógica de uma aplicação;
c) Número de lhos (NOC). Mede o número de subclasses de uma classe;
d) Métodos ponderados por classe (WMC). Calcula o número de serviços por classe;
e) Profundidade da árvore de herança (DIT). Mede o número máximo de superclasses
acima de uma determinada classe;
f) Acoplamento entre classes de objetos (CBO). Mede o nível de acoplamento entre
classes;
25
g) Falta de coesão em métodos (LCOM). Mede o número de acessos a um ou mais
atributos em comum pelos métodos da própria classe;
h) Resposta de uma classe (RFC). Indica a capacidade de resposta que a classe tem ao
receber mensagens de seus objetos;
i) Tamanho da classe (CS). É o número de métodos e atributos de uma classe herdados
de suas superclasses;
j) Número de operações redenidas por uma subclasse (NOO). É o número de sobrescritas de método em subclasses;
k) Número de operações adicionadas por subclasse (NOA). Mede o número de métodos
e atributos denidos em uma subclasse;
l) Índice de especialização (SI). Número de métodos adicionados, eliminados ou redenidos em uma classe.
Já as métricas funcionais vêm se apresentando mais efetivas, pois preocupam-se em
medir o tamanho do projeto que está se desenvolvendo sem estar atrelada a uma tecnologia
especíca e nem de como o produto está sendo desenvolvido.
Diferentemente das métricas tradicionais, as métricas funcionais estão preocupadas
com a medição de software em termos de funcionalidade que ela oferece e não na tecnologia
e forma com este está sendo desenvolvido. As métricas funcionais são usadas, por exemplo,
para medir o tamanho funcional da aplicação ou projeto através do dimensionamento das
funcionalidades deste projeto ou software (IFPUG, 2010).
A métrica funcional padroniza a forma de se estimar o tamanho funcional de qualquer
projeto (IFPUG, 2010). Além disso, usando medição funcional os gerentes de projetos
podem monitorar a produtividade dos seus projetos, baseado nos requisitos do usuário,
ao longo de todo o seu ciclo de desenvolvimento e não somente ao seu nal.
São exemplos de métricas de software funcionais:
a) APF: Técnica de medição funcional mais difundida no mundo. Mede o tamanho dos
requisitos funcionais de um projeto ou aplicação, sob o ponto de vista do usuário
especicador do requisito. O tamanho funcional é medido considerando os requisitos de dados e de transação solicitados pelo usuário requisitor. Cada requisito
identicado como função de dados ou transação recebe um grau de complexidade
26
(baixa, média ou alto), e de acordo com o seu tipo de função receberá uma valor em
pontos de função. Este valor pode varia de 5 a 15 pontos de função para as funções
de dados e de 3 a 7 para as funções transacionais (IPFUG, 2010);
b) NESMA: O grupo de usuário de APF da Holanda mantém um métrica própria de
medição funcional de tamanho baseada na APF. A diferença em relação a APF é
que essa determina que toda função de dados, identicada no requisito, deve ter
complexidade baixa e toda função transacional deve ter complexidade média;
c) COSMIC-FFP: O método Full Function Point (FFP) foi criado para medir o tamanho
funcional de aplicações de tempo real. A seguir foi criado o Common Software Mea-
surement International Consortium (COSMIC) com o objetivo de desenvolver um
novo método de medição de tamanho funcional baseado nas melhores características dos métodos existentes e que incorporasse novas idéias. É uma técnica muito
semelhante a APF, porém diferente da APF, possui um tratamento mais especíco
para complexidade algorítmica da aplicação ou projeto medido;
d) Mark II (Mk2 FPA): É um método de medição funcional de tamanho de software de
domínio público mantido pela associação de métricas do Reino Unido - UKSMA. É
um método de aplicação pouco utilizado no mundo, basicamente restrito ao Reino
Unido. Essa técnica visa melhorar a escala de tamanho funcional, contando mais
apuradamente a complexidade de processamento interno de Sistemas de Informações
Gerenciais. Uma das diferenças principais entre APF e Mk 2 é que a primeira técnica
conta Arquivos Lógicos uma vez para cada parte de software sendo mensurada,
enquanto que a Mk 2 conta tipos de entidade toda vez que elas são referenciadas
em cada transação lógica. (UKSMA, 1998)
No indicador de produtividade de um projeto, a métrica funcional mede o produto
que está sendo entregue, enquanto o esforço mede o custo que a equipe do projeto teve
para entregar o produto produzido.
2.3 INDICADOR DE PRODUTIVIDADE NO PDS
O indicador de produtividade no PDS deve ser utilizado para avaliar o ciclo de desenvolvimento do software, independente de qual tipo de projeto ou metodologia está sendo
utilizada.
27
É considerado uma medição de complexidade do projeto que pode sofrer alteração motivada por mais de 100 fatores ja conhecidos (JONES, 1998). A produtividade representa
o quanto se gasta de esforço para a produção de uma unidade de produto, através dos
recursos do projeto (KARNER, 1993). A unidade de produto em software pode ser representada por linhas de código, componentes, artefatos ou pontos de função. Os recursos
utilizam esforço (tempo) que se transformam em custo para o projeto.
Na gura 2.1 é demonstrado um diagrama simplicado do modelo de produtividade
(CARD, 2006). Ele mostra como os recursos são consumidos por um processo ou subprocesso em particular para a geração de um produto de software. Logo pode ser usada
como unidade de medida para a medição da produtividade.
FIG. 2.1: Modelo Simplicado de Produtividade
Este modelo de produtividade não permite um controle da produtividade ao longo
do ciclo de desenvolvimento do projeto. Ao nal do ciclo tem-se o produto gerado, com
o escopo entregue e o esforço dos recursos. É possível medir a produtividade nal do
processo, porém não é possível saber durante o mesmo qual a produtividade que está
sendo alcançada. É como se toda a complexidade de um processo só precisasse ser avaliado
no nal do seu ciclo.
2.3.1 PRODUTIVIDADE USANDO LINHAS DE CÓDIGO (LOC)
Linhas de código é uma medida física do tamanho do software, pois objetiva medir a
quantidade de código-fonte produzida (AGUIAR, 2003). O grande benefício da técnica é
que ela pode ser automatizada, não sendo necessário uma contagem manual. A produtividade estimada em LOCs pretende estimar a quantidade de linhas de código produzidas
por uma determinada quantidade de esforço.
A técnica de Linha de Código, apesar de ser de fácil medição, apresenta limitações.
Além de ser dependente de linguagem de programação, ela está ligada diretamente a uma
fase do ciclo de desenvolvimento de um projeto, a construção. Isso torna a medição do pro28
jeto muito tardia, dicultando a estimativa mais precisa de parâmetros do projeto, como
esforço, prazo e custo em fases mais iniciais do projeto. É mais fácil analisar, juntamente
com o usuário, as suas requisições (requisitos) do que as linhas de código produzidas por
elas (ALBRECHT, 1983). Outro problema é a inexistência de uma padronização de contagem, pois não há uma denição de certos aspectos do código fonte, como por exemplo,
os comentários e declarações de dados. Ela é uma técnica vaga, ambígua e inadequada
para medir tamanho de projetos (SCHOFIELD, 2005).
Por muito tempo ela foi a métrica mais utilizada, porém aos poucos veio sendo substituída por outras métricas. As novas métricas procuram medir o tamanho das funcionalidades de um software/projeto e não o seu tamanho físico.
2.3.2 PRODUTIVIDADE USANDO PONTOS DE CASO DE USO (PCU)
Pontos de Caso de Uso é um modelo de contagem inspirado na Análise por Pontos de
Função (KARNER, 1993) e baseia-se nos caso de uso e na orientação objeto. A ponderação
de um projeto é feita avaliando-se os atores, casos de uso, além de fatores técnicos e
ambientais (SOUSA, 2011). Estando os casos de uso do projeto denidos, é possível
estimar o tamanho do projeto, de forma simples e ajustada.
A produtividade medida em PCUs considera a quantidade de tempo, que pode ser
em horas, dias, meses para a produção de 1 PCU. Para se chegar ao esforço estimado de
um projeto utilizando o tamanho em PCUs, basta multiplicar o tamanho estimado em
PCUs pela produtividade estimada do projeto. Esta produtividade estimada, deve estar
baseada em projetos que foram medidos em PCUs.
A métrica PCU apresenta problemas com sua padronização (AGUIAR, 2003). O
principal deles se refere ao fato de que o artefato caso de uso não possui um padrão de
preenchimento. Os passos dos casos de uso são descritos de forma subjetiva e não existe
uma padronização predominante (VIEIRA, 2007). O formato de preenchimento pode ser
diferente entre empresas, equipes e até mesmo na mesma equipe é possível encontrar dois
analista preenchendo casos de uso com formato diferentes um do outro. Desta forma, a
técnica, em parte, depende de aspectos que estão diretamente ligados ao formato do caso
de uso. Sem a padronização do artefato de contagem, não se pode garantir uma contagem
padronizada.
Uma segunda limitação da técnica de PCU diz respeito ao fato de não existir o tamanho
estimado no inicio de um projeto (AGUIAR, 2003). Sem uma estimativa sobre o tamanho,
29
não se pode derivar o esforço, prazo e custo estimados do projeto. A análise de viabilidade
de um projeto não poderá ser feita utilizando essa métrica. Por esses motivos, apesar de
ser um técnica bem difundida, a PCU não pode ser considerada completamente adequada
para servir de medida de produtividade de uma empresa.
2.3.3 PRODUTIVIDADE USANDO ANÁLISE POR PONTOS DE FUNÇÃO (APF)
A técnica de Análise por Pontos de Função (APF) é a mais utilizada no mercado para
medir o tamanho funcional dos projetos de desenvolvimento e melhoria de software. Ela foi
inicialmente denida por especialistas no assunto de métricas na IBM, sem uma referência
explícita a uma fundamentação teórica (ABRAN, 1996). A unidade de medida é o Ponto
de Função (PF). Hoje a técnica é uma padrão internacional ISO 20926:2010 e apresenta-se
descrita em um manual de contagem CPM (Counting Practices Manual ), atualmente em
sua versão 4.3.1, publicado e mantido pelo IFPUG (International Function Point Users
Group ).
A APF baseia-se na contagem de funções que armazenam os dados da aplicação, que
está sendo contada, e nas funções transacionais que manipulam esses dados. O manual
limita-se a descrever uma técnica de medição do tamanho funcional de projetos e sistemas
(IFPUG, 2010). A técnica não dene, dentre outras coisas, como devemos tratar indicador
de produtividade e nem custos (precicação). O método de contagem em pontos de função,
utilizado neste estudo, é descrito a seguir:
1) Encontrando os Processos Elementares: o gerente de projeto deve encontrar os processos elementares nos uxo dos casos de uso. Um processo elementar é a menor unidade
de atividade signicativa para o usuário especicador (IFPUG, 2010). Basicamente para
cada processo elementar encontrado existe uma função transacional associada a ela. Depois de encontrar as funções transacionais o gerente de projeto deve identicar os dados
que são manipulados por estas funções.
2) Encontrando as Funções de Dados: durante a análise das funções transacionais
é possível identicar as funções de dados que são manipuladas por estas funções. A
presença de um modelo de dados lógico é importante para identicar de forma mais precisa
os dados, porém este modelo nem sempre está presente na documentação dos projetos.
Assim como cada função transacional, cada função de dados possui uma complexidade
que corresponderá a um valor em PF. Porém cada função de dados pode ser utilizada por
mais de uma função transacional (mantida e/ou lida) e em diferentes casos de uso. Para
30
solucionar este problema, o gerente de projeto pode decidir por estas duas possibilidades:
2.1) selecionar um caso de uso dono da função: um caso de uso dono é o caso de uso
mais importante (sob o ponto de vista do usuário especicador) ou aquele que mais usa
a função de dado. Para este estudo, a função de dado vai contribuir para o tamanho
do caso de uso dono. 2.2) dividir a contribuição da função de dado: cada caso de uso
que manipular o dado deve receber uma parte da contribuição da função de dado que
manipula. O percentual de divisão deve ser determinado pelo gerente de projeto.
3) Encontrando o tamanho estimado em PF do caso de uso: o somatório da contribuição das funções transacionais e de dados de um caso de uso resulta no tamanho
estimado do caso de uso em PF.
A técnica de APF possui, dentre outros, os seguintes benefícios e vantagens (PARO,
1995):
a) Conta o tamanho funcional de um pacote adquirido;
b) Normaliza a comparação de software, pois consegue através do tamanho funcional
parametrizar os sistemas com uma medida padrão e objetiva;
c) Através de seu cálculo, tem-se uma estimativa de esforço, prazo e custo de um
projeto de manutenção ou desenvolvimento de software;
d) Permite analisar produtividade dos processos e a qualidade dos produtos produzidos;
e) Por ser um padrão, permite que seja utilizada para comparar indicadores de diferentes empresas;
f) Possibilita a criação de baseline para estimativas;
g) Pode ser utilizada em qualquer momento do ciclo de desenvolvimento de um projeto,
ao contrário do LOC e do PCU.
Adicionalmente pode se estabelecer correlações do tamanho do projeto com o esforço
de desenvolvimento ou manutenção do projeto. Havendo essa correlação, a técnica de
APF pode ser utilizada como uma técnica de estimativa dos projetos de software (CONNOLLEY, 1990).
A produtividade medida em PF considera a quantidade de tempo, que pode ser em
horas, dias, meses para a produção de 1 PF. Para se chegar ao esforço estimado de um
31
projeto utilizando o tamanho em PF, basta multiplicar o tamanho estimado em PFs pela
produtividade estimada do projeto. Esta produtividade estimada, deve estar baseada em
projetos que foram medidos em PFs.
Este trabalho utiliza PF como medida básica no cálculo do indicador de produtividade,
as demais métricas descritas não são utilizadas. PF é uma medida paramétrica que busca o
tamanho funcional dos produtos de software produzidos (IFPUG, 2010). Parametrizando
o tamanho é possível medir projetos de naturezas, equipes, empresas diferentes em uma
unidade de medida de tamanho comum a todos os projetos.
A fórmula para se encontrar a produtividade do projeto utiliza duas medidas: a
primeira é o total de esforço, em homem hora (HH), de todos os recursos que trabalham
no projeto medido. A segunda é o tamanho funcional do escopo do projeto trabalhado
em PF. A seguir é descrita da fórmula da produtividade.
Produtividade = Esforço/Tamanho (HH/PF)
Os parâmetros custo e prazo de um projeto usam a produtividade como medida de cálculo. Sabendo a produtividade estimada e esperada, é possível se chegar às estimativas
de prazo e custo do projeto. Para saber a produtividade estimada, a empresa precisa ter
uma base histórica de registro de produtividades de projetos passados. Existem tabelas
de produtividades de desenvolvimento de software publicadas por órgão e empresas especializadas em benchmarking de projetos, por exemplo o ISBSG (ISBSG, 2012). Porém
este números devem ser utilizados com cuidado, pois a memória de cálculo dessas produtividades é baseada no histórico de projetos de outras empresas. Esses números podem
divergir bastante da realidade de quem busca uma produtividade média estimada para
utilizar em seu projeto de software.
2.4 REGRAS DE ASSOCIAÇÃO E O ALGORITMO APRIORI
Representam padrões onde a ocorrência de eventos em conjunto é alta. Podemos dizer que
é a probabilidade de que um conjunto de itens apareça em uma transação, dado que outro
conjunto esteja presente. Um exemplo de tal tipo de regra seria 75% dos consumidores
que compram o produto A e B também compram o produto C (ARBEX, 2013).
O objetivo de minerar regras de associação é encontrar todos os conjuntos de itens
que frequentemente ocorrem de forma conjunta na base de dados e formar regras a partir
32
destes conjuntos.
As regras de associação são consideradas um método não supervisionado, e obtém o
segundo lugar em percentual de utilização em aplicações, so cando atrás de classicação
(ARBEX, 2013).
As regras de associação são representadas da seguinte forma: X ⇒ Y (lê-se X implica
em Y) , onde X é o antecessor e Y o consequente e X e Y são dois itemsets (conjunto de
itens frequentes) distintos na base de dados.
Cada regra da forma X ⇒ Y possui duas medidas que determinam sua validade no
conjunto de dados e também limitam a quantidade de regras extraídas. São eles o suporte
e a conança. Estes possibilitam o descarte das regras julgadas de pouco interesse, já que
são menos frequentes e conáveis.
A função do suporte é determinar a frequência que ocorre um itemset dentre todas as
transações da base de dados, é a porcentagem de transações onde este itemset aparece.
Um itemset será considerado frequente se o seu suporte for maior ou igual a um suporte
mínimo estabelecido previamente.
O algoritmo APRIORI é considerado um clássico na extração de regras de associação.
Ele foi proposto pela equipe de pesquisa QUEST da IBM que deu origem ao Software
Intelligent Miner. Este algoritmo faz recursivas buscas no banco de dados à procura dos
conjuntos frequentes (conjuntos que satisfazem um suporte mínimo estabelecido).
Alem disto, possui diversas propriedades que otimizam o seu desempenho, como por
exemplo, a propriedade de antimonotonicidade da relação, que diz que para um itemset
ser frequente, todos os seus subconjuntos também devem ser, além de utilizar recursos da
memória principal e estrutura hash.
As três fases que compõem o APRIORI são: geração dos conjuntos candidatos; poda
dos conjuntos candidatos e contagem do suporte (nesta fase é necessário visitar o banco
de dados).
A este algoritmo é aplicada a propriedade de antimonotonia da relação ou propriedade
APRIORI que é descrita a seguir:
Se X está contido em Y e X não é frequente, logo Y também não é frequente.
Isto implica uma diminuição do tempo de execução, pois se X não é frequente, então
não será necessário calcular o suporte de Y, e não será necessária a análise de todas as
combinações entre atributos. Na gura 2.2 é mostrada a fórmula de suporte do algoritmo.
33
>
FIG. 2.2: Fórmula de Suporte do Algoritmo APRIORI
2.4.1 FERRAMENTA DE MINERAÇÃO DE DADOS WEKA
A suite WEKA (Waikato Enviroment for Knowledge Analysis ) é formada por um conjunto
de implementações de algoritmos de diversas técnicas de Mineração de Dados (WEKA,
2013) muito utilizada no meio acadêmico.
Foi desenvolvida em linguagem Java na Universidade de Waikato, Nova Zelândia.
Atualmente é disponível sobre a licensa GPL (DAMASCENO, 2005). Ela está disponível
para download na URL http://www.cs.waikato.ac.nz/ml/weka.
O WEKA possui um formato para a organização dos dados, seu nome é ARFF. O
arquivo deve conter uma série de informações, dentre elas: domínio do atributo, valores
que os atributos podem representar e atributo classe.
O arquivo ARFF é dividido em duas partes, a primeira contém uma lista de todos os
atributos, onde se deve denir o tipo do atributo e/ou os valores que ele pode representar.
Os valores devem estar entre chaves ({}) separados por vírgulas. A segunda é composta
pelas instâncias presentes nos dados, os atributos de cada instância devem ser separados
por vírgula, e aqueles que não contêm valor, o valor deve ser representados pelo caractere
"?". A gura 2.3 mostra alguns métodos implementados pelo WEKA:
>
FIG. 2.3: Métodos Implementados pelo WEKA
34
3 MÉTODO PARA MONITORAMENTO DA PRODUTIVIDADE
Ações gerenciais de ajuste do projeto precisam ser feitas o quanto antes. Assim o
gerente de projeto está mitigando riscos decorrentes do desvio da PEI. Com o método
proposto ele será capaz de saber qual fase do seu PDS está tendo problemas de produtividade dentro do ciclo de desenvolvimento, pois a PAP é medida por iteração. A PAP
deve ser medida em marcos do projeto por iterações ou em outros momentos do projeto,
que o gerente de projeto considerar importante.
A PAP é diferente da PEI e da PFP de um projeto, por ser medida ao longo do
ciclo de desenvolvimento do projeto. A cada término de iteração, módulo ou sprint, a
produtividade do projeto até o momento é medida e comparada com a PEI, onde se
dene o prazo e custo do projeto estimados. Este trabalho divide o projeto em iterações,
mas poderia ser divido em módulos ou sprints. Isto depende de como o PDS divide o
projeto de software que está sendo desenvolvido. Cada iteração corresponde a um subciclo
do PDS. Basicamente toda iteração deve passar por todas as fases do PDS. Caso haja
mudanças no PDS de uma iteração, estas devem ser justicadas pelo gerente de projeto.
Uma justicativa inaceitável é a de redução de esforço para mascarar uma melhora de
produtividade da iteração.
O método proposto está dividido em duas fases: a do Monitoramento e a do Diagnóstico. O método de monitoramento da produtividade é dividido em duas fases. A fase
de Monitoramento é obrigatória e de Diagnóstico não. O gerente de projeto só executa a
fase de Diagnóstico caso a PAP esteja diferente da PEI.
O Monitoramento é a fase que permite que o gerente de projeto acompanhe a PAP do
seu PDS, permitindo que verique se a PAP está diferente da PEI. Na fase de Diagnóstico
o gerente de projeto identica os fatores que zeram a PAP desviar da PEI, através do uso
de um checklist de fatores que impactam a produtividade de um PDS denido no método
proposto por este estudo. Para a fase de Monitoramento existem as seguintes atividades:
Obter Informações da Iteração do Projeto; Estimar o Tamanho e o Esforço da Iteração
e Calcular o Tamanho Final da Iteração e a PAP ou PFP. Para a fase de Diagnóstico
existem as seguintes atividades: Aplicar o Checklist do PMP e Denir Relatório de Ações
de Ajuste (RAA).
35
Além das atividades o PMP possui um papel, insumos de entrada, resultados e uma
ferramenta que armazena dados. O PMP possui um papel chamado Gerente de Projeto,
responsável pela execução do PMP, e uma Ferramenta que é uma Planilha com os Dados da Iteração. São insumos de entrada (input): Informações da Iteração do Projeto,
Esforço Real da Iteração, Relatório de Acompanhamento do Projeto (RAP) e o checklist
respondido. São resultados do PMP (output): PAP, PFP, checklist respondido e o RAA.
Este estudo adota o agrupamento funcional por caso de uso. O caso de uso é um
documento utilizado para descrever os requisitos na visão do usuário especicador do
projeto. Outras formas de agrupamento podem ser utilizadas no PMP, como, por exemplo,
documentos com as histórias utilizadas em metodologias ágeis.
Para exemplicar o PMP, é apresentado ao longo de sua descrição um projeto que foi
utilizado na amostragem da base histórica da empresa avaliada.
O projeto é uma manutenção com o tamanho funcional estimado em 70 PFs. O
PDS que foi utilizado para o seu desenvolvimento foi do tipo completo (ver Anexo 2),
a linguagem predominante foi Java. O esforço estimado para o seu desenvolvimento foi
de 980 horas. A PEI denida pelo gerente de projeto foi de 14 H/PF. A quantidade de
recursos foi de 4 analistas e o prazo para a entrega cou acordado para 2 meses. Este
projeto foi dividido em 2 iterações, sendo que a primeira teve 4 casos de uso e a segunda
teve apenas 2 casos de uso. Este projeto apresentou durante o seu desenvolvimento perda
de produtividade no seu PDS.
3.1 FASE DO MONITORAMENTO
O gerente de projeto deve analisar se a PAP da iteração está diferente da PEI. O monitoramento é a fase responsável pela medição das iterações entregues e a avaliação de que
o PDS precisa ou não de ajustes para não haver desvio no custo e prazo ao término do
projeto. A gura 3.1 mostra o gráco SPEM (SPEM, 2008) da fase de Monitoramento
do PMP.
3.1.1 DEFINIÇÃO DA PRODUTIVIDADE DE ACOMPANHAMENTO DE UM PDS
(PAP)
O objetivo dessa seção é avaliar se a PAP da iteração está diferente da PEI. Caso esteja,
o gerente de projeto deverá avaliar os motivos dessa mudança.
36
FIG. 3.1: Gráco SPEM (SPEM, 2008) do PMP (fase Monitoramento)
O PMP mede a PAP realizada em uma iteração para saber qual caso de uso teve
a PAP diferente da PEI do projeto. Mas para avaliar uma iteração, o PMP calcula a
PAP da iteração. O cálculo da PAP da iteração é realizado somando-se o esforço para o
desenvolvimento da iteração dividido pelo tamanho dos casos de uso da iteração em PF.
Se a PAP da iteração não desviou da PEI ou cou acima desta, signica que o projeto
cumprirá o prazo estimado e o custo estimado não será acrescido por consequência do
prazo. Se a PAP da iteração estiver abaixo da PEI, o projeto atrasará e haverá aumento
de custo.
Cada fase de uma iteração é responsável por uma parte do esforço estimado da iteração.
O gerente de projeto deve estabelecer como deve ser distribuído o esforço despendido em
cada fase do PDS na iteração. Normalmente o PDS possui uma divisão de esforço por
fase padrão, porém o gerente de projeto pode alterar esta distribuição para adequar a
realidade da iteração do seu projeto. Esta divisão de esforço entre as fases deve se basear
em dados históricos de projetos passados ou por experiência própria do gerente de projeto.
O importante é que esta distribuição seja realista.
Sendo necessário, o gerente de projeto deve, a cada iteração, tomar as ações necessárias
para ajustes no PDS. Estas ações vão ajustar as atividades dentro do processo do projeto
analisado.
37
3.1.2 ATIVIDADE 1 - OBTER INFORMAÇÕES DA ITERAÇÃO DO PROJETO.
O objetivo dessa atividade é coletar as informações do projeto que serão utilizadas em
outras atividades do PMP.
Nesta atividade, o gerente de projeto deve obter como insumos de entrada as seguintes
informações: os casos de uso da iteração (ou outro documento equivalente adotado pelo
PDS do projeto), qual é a iteração do projeto, as fases do PDS da iteração, o percentual
de distribuição de esforço por fase do PDS e a PEI.
O armazenamento dessas informações em uma Planilha com os Dados da Iteração
(PDI) é o resultado dessa atividade, pois estes dados serão necessários em atividades
futuras do PMP. Estes dados são: o número da iteração do projeto, o nome dos casos
de uso da iteração, as fases do PDS da iteração e o percentual de distribuição de esforço
por fase do PDS do projeto. A gura 3.2 apresenta um exemplo de PDI preenchido que
atende esta atividade do PMP.
O projeto exemplo foi dividido em 2 iterações, sendo que a primeira teve 4 casos de
uso e uma PEI de 14 H/PF. Para usar o PMP, o gerente de projeto deve dividir sua
iteração em fases do PDS. Assim é possível fazer uma análise da PAP por fase.
No PDS completo da organização está prevista as fases de Requisitos, Análise e Projeto, Construção, Testes, Homologação e Implantação. Para cada fase está denido um
percentual de esforço (tamanho em PF) do ciclo. A seguir é apresentada a lista de fase
por percentual de esforço (tamanho) do PDS completo da organização avaliada.
a) Requisitos = 25%
b) Análise e Projeto = 10%
c) Construção = 40%
d) Testes = 10%
e) Homologação = 10%
f) Implantação = 5%
38
FIG. 3.2: Exemplo da PDI preenchida na Atividade - Obter Informações da Iteração do
Projeto
3.1.3 ATIVIDADE 2 - ESTIMAR O TAMANHO E O ESFORÇO DA ITERAÇÃO.
O objetivo que o gerente de projeto deve alcançar nessa atividade é a estimativa do
tamanho e esforço da iteração.
O insumo de entrada desta atividade será o conjunto de casos de uso da iteração
medida. A organização que adotar o PMP poderá utilizar outro tipo de artefato para
registro dos requisitos do projeto. O gerente de projeto deve obter a relação dos nomes
dos casos de uso na PDI.
O gerente de projeto, exercendo o seu papel nesta atividade do PMP, deve contar em
PF estas funcionalidades por caso de uso no início da iteração. Apesar de existirem outras
alternativas, PF é o método de dimensionamento funcional proposto por este estudo. A
escolha pela APF foi motivada por ela ser a técnica de dimensionamento funcional de
software mais difundida no mundo e pelo conhecimento que o autor tem sobre a técnica.
A organização que adotar o PMP poderá usar outra técnica de dimensionamento funcional.
Ao nal do cálculo, o gerente de projeto deve armazenar na PDI o tamanho de cada
caso de uso, o somatório do tamanho de todos os casos de uso da iteração. Para encontrar
a estimativa de esforço em horas de uma iteração, o gerente de projeto deve multiplicar
39
a PEI pelo tamanho estimado de todos os casos de uso da iteração. O valor da PEI é
obtido na PDI.
Como resultado dessa atividade, o gerente de projeto deve armazenar as seguintes
informações na PDI: o valor em PF estimado de cada caso de uso da iteração, o somatório
do tamanho estimado dos casos de uso da iteração, o esforço estimado por caso de uso e
o esforço estimado da iteração.
Voltando ao projeto exemplo o gerente de projeto calcula os PFs estimados das funcionalidades por caso de uso da iteração. A primeira iteração teve 4 casos de uso. A seguir
é listada a quantidade de PFs por caso de uso. Essa medição foi feita após o detalhamento
dos casos de uso no PDS e não ao nal da iteração.
a) Caso de Uso 1 = 20 PFs
b) Caso de Uso 2 = 7 PFs
c) Caso de Uso 3 = 14 PFs
d) Caso de Uso 4 = 3 PFs
Logo a primeira iteração teve 44 PFs estimados.
Para encontrar a estimativa de esforço em horas da primeira iteração, o gerente de
projeto deve multiplicar a PEI pelo tamanho de todos os casos de uso da iteração estimados.
Para este projeto o tamanho estimado da primeira iteração é de 44 PFs e a PEI é de
14 H/PF. Logo o esforço estimado da iteração é de 616 horas. O gerente de projeto deve
armazenar na PDI o esforço estimado por caso de uso e o total de esforço estimado da
iteração. A gura 3.3 apresenta um exemplo de PDI preenchido que atende esta atividade
do PMP.
Essas horas de esforço são as previstas para a alocação de esforço de toda a equipe do
projeto durante a iteração. O gerente de projeto precisa monitorar a apropriação (horas)
e o escopo da iteração (tamanho) durante a iteração. Se há super ou subalocação de
horas existem problemas com o esforço, se há mudança de escopo ou retrabalho durante
a iteração existe um aumento ou redução do tamanho da iteração. Esse fatores podem
impactar a PAP da iteração.
40
FIG. 3.3: Exemplo da PDI preenchida na Atividade - Estimar o Tamanho e o Esforço da
Iteração
3.1.4 ATIVIDADE 3 - CALCULAR O TAMANHO FINAL DA ITERAÇÃO E A PAP
OU PFP.
Diferente da atividade anterior, aqui o gerente de projeto objetiva o cálculo do tamanho
nal da iteração em PF que será a PAP ou PFP da iteração.
No nal de cada iteração, o gerente de projeto deve calcular o total de horas de esforço
real (nal) gastos para o desenvolvimento da iteração. Ele obtém esse dado somando
todas as horas apropriadas pelos membros da equipe do projeto em todas as atividades
do projeto. Além do esforço gasto, o gerente de projeto deve medir o tamanho nal em PF
da iteração. Ele obtém este dado realizando a contagem nal em PF do produto entregue
pela iteração. Com estas duas medidas é possível calcular a PAP ou PFP da iteração,
apenas dividindo o esforço real pelo tamanho nal da iteração.
O gerente de projeto, nesta atividade, recebe como insumo de entrada um RAP do
projeto que está sendo acompanhado e o PDI, onde obtém a PEI, o nome dos casos de
uso e os dados do projeto obtido na Atividade 1. A análise do RAP é função do gerente
de projeto de acordo com a experiência que ele possui no projeto medido e em outros
41
projetos anteriores.
O RAP servirá de insumo de entrada para o checklist do PMP na fase de Diagnóstico.
Se a PAP calculada for diferente da PEI e o conteúdo da RAP for relevante o gerente
de projeto passará para a fase de diagnóstico do PMP. A próxima fase começa fazendo a
análise dos fatores que impactaram a PAP da iteração através do checklist do PMP.
Se houve desvio da PAP em relação a PEI o gerente de projeto pode tomar ações de
correção para evitar que este problema se propague pelas iterações seguintes. Se o gerente
de projeto não zer isto corre risco de atrasar e/ou aumentar o custo do projeto, além de
inuenciar a qualidade do produto entregue.
Para se detectar onde ocorreu o desvio da PAP o gerente de projeto deve apurar o
esforço da equipe por fase e fazer cálculo da PAP por fase do PDS. A divisão do tamanho
da iteração deve obedecer a tabela de divisão de percentual por fase denida pelo PDS
ou pelo gerente de projeto. Na PDI está armazenado o valor percentual por fase do PDS
adotado no projeto medido.
Caso seja a última iteração de um projeto, o gerente de projeto precisa calcular a PFP
e fazer a vericação em relação a PEI. Se esta não for a última iteração e o projeto já
teve outras iterações antes desta, o gerente de projeto deve calcular o PAP do projeto
até a presente iteração. O esforço será o somatório de todas as apropriações de todas as
iterações até a presente iteração. O tamanho em PF será o somatório do tamanho em
PF de todos os casos de uso até a presente iteração. Dessa forma, ele poderá comparar a
PEI com a PAP acumulada até o momento no projeto. Se a PAP tem o valor diferente
da PEI, o gerente de projeto deve seguir para o passo seguinte de diagnóstico do PMP
independente em qual momento o projeto se encontra.
Aplicado ao projeto exemplo, no nal da primeira iteração o gerente de projeto calcula
o total de HH de esforço real (nal) gastos para o desenvolvimento da iteração. Além do
esforço gasto o gerente de projeto deve medir o tamanho nal em PF da primeira iteração.
Com estas duas medidas é possível calcular a PAP da iteração.
A seguir é feita a apuração do esforço da equipe do projeto por fase da primeira
iteração.
a) Requisitos = 217,5 Horas
b) Análise e Projeto = 70 Horas
c) Construção = 280 Horas
42
d) Testes = 181,5 Horas
e) Homologação = 70 Horas
f) Implantação = 35 Horas
O gerente de projeto mediu a esforço apropriado pela equipe do projeto e foram apropriadas 854 horas e o tamanho da primeira iteração cou em 50 PFs. O tamanho nal
foi obtido através da recontagem dos casos de uso ao nal da iteração. Se os casos de uso
da iteração mudaram em relação a início da iteração o gerente de projeto deve atualizar
o PDI com a nova relação de casos de uso. O aumento do tamanho desta iteração foi
provocado pelo retrabalho de dois casos de uso (uma Entrada Externa simples de 3 PFs
que faz parte do Caso de Uso 1 que teve seu tamanho aumentado de 20 PF para 23 PF)
e todo o Caso de Uso 4 (que teve seu tamanho duplicado, passou de 3 PFs para 6 PFs).
O tamanho inicial estimada para a primeira iteração foi de 44 PFs e passou para 50 PFs
ao nal da mesma.
Sabendo o tamanho nal da primeira iteração (50 PFs) e o esforço apropriado pela
equipe do projeto na primeira iteraçao (854 horas), basta o gerente de projeto dividir o
esforço pelo tamanho para encontrar a PAP da primeira iteração. Fazendo a divisão a
PAP dá aproximadamente 17 H/PF.
O gerente de projeto obtém a PEI do PDI e detecta desvio da PAP da primeira
iteração em relação a PEI do projeto, o gerente de projeto deve tomar ações de correção
para evitar que este problema se propague pelas iterações seguintes. Se o gerente de
projeto não zer isto corre risco de atrasar e/ou aumentar o custo do projeto, além de
inuenciar a qualidade do produto entregue.
Para saber em qual fase do PMP houve desvio da produtividade é preciso medir a
PAP por fase. A seguir é feito o cálculo dos PFs por fase da primeira iteração do projeto.
a) Requisitos (25%) = 12,5 PFs
b) Análise e Projeto (10%) = 5 PFs
c) Construção (40%) = 20 PFs
d) Testes (10%) = 5 PFs
e) Homologação (10%) = 5 PFs
43
f) Implantação (5%) = 2,5 PFs
Sabendo o tamanho e o esforço por fase da iteração, basta agora o gerente de projeto
calcular a produtividade da iteração por fase do PDS. A seguir é calculada a produtividade
do PDS por fase da primeira iteração.
a) Requisitos = 17,4 H/PF
b) Análise e Projeto = 14 H/PF
c) Construção = 14 H/PF
d) Testes = 36,3 H/PF
e) Homologação = 14 H/PF
f) Implantação = 14 H/PF
Pode ser visto que as fases que desviaram da produtividade inicial do planejamento
foram as de requisitos e de testes. Para chegar a essa conclusão o gerente de projeto
comparou a PAP da fase com a PEI do projeto.
A análise dos motivos do desvio da PAP será feita na fase de Diagnóstico do PMP da
iteração e os dados da iteração devem ser armazenado na PDI. A gura 3.4 apresenta um
exemplo de PDI preenchido que atende esta atividade do PMP.
FIG. 3.4: Exemplo da PDI preenchida na Atividade - Calcular o Tamanho Final da
Iteração e a PAP ou PFP
44
3.2 FASE DO DIAGNÓSTICO
O gerente de projeto deve analisar os impactos positivos e negativos na PAP do seu
projeto. Só assim ele poderá tomar ações de ajuste no PDS para realinhar a produtividade
do projeto. A análise dos impactos no PDS é feita na fase de diagnóstico do PMP. O
principal documento utilizado nesta fase é o checklist. O checklist é estruturado em duas
seções, a primeira com questões que devem ser respondidas para o projeto que está com
a PAP pior que a PEI, e a segunda seção para projetos com a PAP melhor que a PEI.
O checklist deve incluir questões que permitam avaliação de cada fase do PDS. Uma
organização que for usar o PMP deve denir seu próprio conjunto de questões adaptada ao
seu PDS. A seguir é apresentada uma lista de fatores de impacto que podem ser usados no
checklist (SUDHAKAR, 2012) (WALT, 1995): complexidade do projeto; tipo de projeto
(ex. tempo real, distribuído); suporte a inovação; infraestrutura de desenvolvimento;
ambiente de trabalho; integração com outras aplicações; experiência da equipe (análise,
projeto e programação); motivação da equipe, comunicação e coesão; comunicação com
o cliente; maturidade do PDS; reuso (projeto e codicação); frequência na mudança de
requisitos; requisitos não funcionais complexos; linguagem de programação complexa; uso
de vericação (teste e remoção de defeitos); retrabalho (gerenciamento de mudanças);
padrões de qualidade; evolução (aspectos de manutenção, refactoring, etc.); mudanças
na equipe, dentre outras. A gura 3.5 mostra o gráco SPEM (SPEM, 2008) da fase de
Diagnóstico do PMP.
3.2.1 ATIVIDADE 4 - APLICAR O CHECKLIST DO PMP
O objetivo dessa atividade é fazer a avaliação de quais fatores acarretaram alteração no
PAP da iteração do projeto. Essa avaliação é feita através de um checklist.
Esta atividade do PMP deve ser executada, se o gerente de projeto detectar que a PAP
desviou em relação a PEI de forma signicativa e o RAP apresentou aspectos signicativos
durante o acompanhamento do projeto. A decisão de algo ser signicativo é critério que
deve ser denido pelo gerente de projeto baseado na sua experiência e na sua visão geral
do projeto. O desvio pode ser para a melhora ou piora da PAP. O artefato principal
desta atividade é o checklist de avaliação de impactos na PAP. No Anexo 4 deste estudo
encontra-se uma descrição de como o autor deniu o checklist utilizado no PMP.
45
FIG. 3.5: Gráco SPEM (SPEM, 2008) do PMP (fase Diagnóstico)
3.3 ATIVIDADE 5 - DEFINIR RELATÓRIO DE AÇÕES DE AJUSTE (RAA)
O objetivo desta atividade é ter como resultado um relatório que sugere, ao próprio
gerente de projeto, mudanças no PDS do projeto medido. Se as mudanças sugeridas
serão realizadas não é foco da pesquisa, pois cabe decisão do gerente de projeto aplicá-las
ou não.
Após a aplicação do checklist, o gerente de projeto deve denir as ações de ajuste do
PDS. Se ele não executar esta atividade é porque a PAP não sofreu impactos signicativos
em relação a produtividade denida no planejamento inicial ou no momento não cabe
tomar ações em relação ao PDS. A decisão para a criação do RAA é do gerente de projeto,
baseado no RAP, no checklist respondido e no seu conhecimento no projeto medido.
Como insumo de entrada ele terá o RAP e o checklist respondido. Como resultado
dessa atividade ele dene o RAA do PMP para ser aplicado ao PDS.
O gerente de projeto deve realizar a análise do checklist respondido. A seguir o autor
faz uma descrição detalhada de como deve ser feita análise de cada pergunta do checklist.
Parte 1 do checklist (piora da PAP em relação a PEI)
Perguntas:
1) A equipe mudou?
Resposta Sim: o gerente de projeto deve considerar que a mudança de equipe traz
46
impacto na piora da produtividade por conta da perda de conhecimento no projeto. Porém
nem sempre isso ocorre para grandes projetos, pois é comum que outros membros da
equipe que permaneceram no projeto acabem compensando a perda de conhecimento dos
que saíram.
Resposta Não: quando a equipe se mantem estável é comum que melhore a produtividade do projeto ao longo do tempo. Logo, no caso de não haver mudança na equipe o
gerente de projeto a princípio não consideraria esse um possível impacto para a perda da
produtividade do projeto.
2) A iteração sofreu acompanhamento?
Resposta Sim: quando um PDS é acompanhado pelo gerente de projeto e este acompanhamento é bem executado tende a melhorar a produtividade do projeto, pois monitora os
riscos que podem ocorrer no projeto, possibilitando a mitigação destes, ou caso já tenham
ocorrido, o tratamento de forma antecipada.
Resposta Não: PDS sem acompanhamento é preocupante, pois pode estar com riscos
ocorrendo que não estão sendo detectados. Estes riscos podem ser fonte de perda de
produtividade do projeto.
3) Os usuários responsáveis pelos requisitos do projeto mudaram?
Resposta Sim: é comum que novos usuários especicadores mudem os requisitos especicados para atender sua visão particular do negócio. Essa mudança gera retrabalho
e por consequência aumento de esforço e perda de produtividade.
Resposta Não: mesmo assim o gerente de projeto precisa atentar para a mudança ou
aumento de escopo pelos usuários especicadores. Mesmo que eles se mantenham estáveis
é provável que mudem a especicação de requisitos ao longo do projeto, por diversos
motivos como por exemplo mudança de regras de negócio, esquecimento, desconhecimento,
um melhor entendimento do objetivo do projeto ao longo do tempo. Neste caso cabe uma
análise mais cuidadosa da pergunta a seguir.
4) Houve retrabalho?
Resposta Sim: todo retrabalho vem com aumento de esforço. Mesmo que este retrabalho acrescente PFs (tamanho funcional) ao projeto é provável que ele piore a produtividade do projeto.
Resposta Não: neste caso o gerente de projeto não deve considerá-lo impacto para a
perda da produtividade, pois não houve aumento de esforço provocado pelo retrabalho.
5) Foi usado ferramenta para suportar o PDS?
47
Resposta Sim: o uso de ferramentas de apoio é importante para uma boa execução de
um PDS. Além da existência de um ferramental, o gerente de projeto precisa avaliar se o
ferramental é adequado ao PDS que está sendo usado no projeto. Se o ferramental não
está adequado a melhor resposta seria um não.
Resposta Não: provavelmente este PDS está tendo perda de produtividade por falta
de ferramentas. Pois muitas atividades que poderiam ser automatizadas estão sendo feitas
manualmente pela equipe do projeto, acarretando perda de performance e aumento de
risco de erros. Com isso gerando retrabalho provocado pela própria equipe do projeto.
6) Foi utilizada ferramenta para os testes?
Resposta Sim: a análise que o gerente de projeto tem que fazer aqui é a mesma da
pergunta anterior. Porém o uso de ferramental para testes é muito mais importante que
para outras disciplinas do PDS. O não uso de ferramental de testes provoca mais impactos
na qualidade e no aumento de esforço do projeto. O teste é responsável pela validação
e vericação do requisito do usuário, se não bem realizada deixará que inconformidades
cheguem ao produto nal acarretando retrabalho em fases tardias do projeto, o que aumenta o esforço do projeto e por consequência redução da produtividade.
Resposta Não: mesma análise da pergunta anterior, com o agravante de ser na disciplina de testes.
Parte 2 do checklist (melhora da PAP em relação a PEI)
7) Houve reuso de requisitos?
Resposta Sim: o reuso de requisito melhora bastante a produtividade. É uma boa
prática criar padrões de casos de uso para atender determinados domínios de requisitos,
como por exemplos cadastros básicos (cria, alterar, consultar, apagar algo). Isso reduz o
esforço e diminui o risco de erro, evitando retrabalho.
Resposta Não: não quer dizer que será um problema para a produtividade do projeto,
mas deve deixar o gerente de projeto mais atendo quando a qualidade dos casos de uso.
Por conta disso, ele precisa colocar no seu projeto testes nos requisitos para evitar que
erros sejam propagados e descobertos tardiamento. Quando mais tarde for descoberto o
erro mais esforço e perda de produtividade.
8) Não foi encontrado erro nos requisitos especicados?
Resposta Sim: neste caso não haverá aumento de esforço e por consequência não
piorará a produtividade do projeto.
Resposta Não: foram encontrados erros nos requistos. Dependendo da natureza do
48
erro a perda de produtividade será maior ou menor no projeto. Se o erro foi provocado
pelo usuário especicador provavelmente haverá uma acréscimo de tamanho no projeto por
conta do retrabalho, compensando o aumento de esforço para a reconstrução do requisitos.
Por outro lado, se o erro foi por culpa da própria equipe do projeto, haverá aumento de
esforço com perda de produtividade.
9) Não houve subalocação de horas no projeto?
Resposta Sim: o gerente de projeto pode considerar que o esforço apropriado pela
equipe do projeto está adequado e não causou impacto na produtividade. Neste caso o
gerente de projeto deve analisar que este item é neutro no impacto da produtividade.
Resposta Não: este é um típico problema nos projetos que tem baixa performance no
seu PDS. Os membros da equipe do projeto não apropriam as horas corretamente para
não demonstrar a falta de produtividade no processo. Dessa forma estão mascarando a
verdadeira produtividade do projeto. Cabe aqui o gerente de projeto monitorar mais de
perto a apropriação (apropriação diária) ou até mesmo fazer uma análise comparativa
do esforço que os membros do projeto tiveram em outros projetos, realizando as mesmas
atividades.
10) Não houve integração com outras aplicações?
Resposta Sim: quanto menor a quantidade de integrações melhor será a produtividade
do projeto. Toda integração, principalmente aquelas que ainda não estão bem estruturadas, acarretam perda de produtividade de um projeto, por conta do aumento de esforço
gerado pelo retrabalho e testes.
Resposta Não: é uma grande preocupação que o gerente de projeto precisa ter. Cada
integração é um grande risco de retrabalho, pois outras aplicações podem estar mudando
suas interfaces e por consequência gerando retrabalho no projeto.
11) Foi utilizada prototipação?
Resposta Sim: a prototipação é uma forma bem eciente do usuário especicador
observar se o seu requisito especicado está de acordo com a sua expectativa. Além disso,
permite que o analista de requisitos conheça a necessidade do usuário e consiga descrever
melhor os casos de uso, reduzindo o retrabalho e melhorando a produtividade.
Resposta Não: não quer dizer que a ausência de protótipos vai reduzir a produtividade, mas não usar protótipos aumenta o risco de retrabalho por conta de mudança de
especicação pelo usuário especicador ou até mesmo por erro de especicação dos casos
de uso.
49
12) Foi utilizada métrica para o acompanhamento da iteração?
Resposta Sim: a métrica é importante para o projeto, pois permite o controle do
escopo do mesmo. O gerente de projeto sabendo o tamanho do projeto planeja melhor a
sua execução, melhora o acompanhamento, além de permitir avaliar a produtividade do
mesmo comparando com outros projetos já realizados.
Resposta Não: não se pode gerenciar o que não se pode medir. Em grande parte dos
projetos de desenvolvimento de software isso é uma verdade. O gerente de projeto que
não acompanha seu projeto através de uma métrica corre o risco de perder o controle do
escopo, não controlar o retrabalho e não conseguir medir a PAP.
13) Os usuários especicadores dos requisitos conhecem bem os requisitos?
Resposta Sim: provavelmente não haverá retrabalho provocado pela mudança dos
requisitos por parte do usuário especicador. Essa característica não elimina o risco de
retrabalho pela mudança do requisitos, apenas reduz a probabilidade dela ocorrer.
Resposta Não: o gerente de projeto precisa car bem atento se essa característica
existir em seu(s) usuário(s) especicador(es), pois é um grande risco de retrabalho e por
consequência perda de produtividade. Nem sempre o usuário especicador quer assumir
que alterou a especicação, pois simplesmente ele declara que os analistas de requisitos já
deveriam saber do que ele estava falando, e os mesmos deveriam o ter questionado melhor
durante o levantamento de requisitos.
14) Não houve teste não-funcional a partir da especicação dos requisitos?
Resposta Sim: a empresa utilizada neste estudo, essa característica fez a produtividade
melhorar quando não houve testes não-funcional a partir da especicação dos requisitos do
usuário especicador. A explicação para isso deve ser pela redução de esforço apropriado
que exitiria para a execução dessa atividade. Não foi relatado, nos projetos pesquisados
na base histórica, aumento de esforço por conta do retrabalho na ausência desta atividade.
Resposta Não: no caso contrário há aumento de esforço para a realização desta atividade. Principalmente se não foi utilizado ferramenta para os testes não-funcionais.
15) Não foram usados componentes de outras aplicações?
Resposta Sim: o não uso de componentes melhora a produtividade dos projetos avaliados, pois não há perda de esforço para adaptação dos mesmos e testes para vericar seu
funcionamento.
Resposta Não: neste caso a análise é a inversa da resposta do sim.
Com a análise do checklist respondido em conjunto com a análise do RAP o gerente de
50
projeto elabora o resultado dessa atividade no RAA. No Anexo 5 é apresentado o modelo
de RAA proposto pelo PMP.
Se for a iteração nal do projeto, os resultados presentes no RAA devem alimentar a
base histórica dos projetos da empresa, inclusive com as lições aprendidas. Esta atividade
está presente no PDS do projeto e não faz parte do escopo do PMP.
Na primeira iteração do projeto exemplo o diagnóstio identicou problemas em relação
ao retrabalho e o não uso de ferramental para realização dos testes. Este diagnóstico foi
obtido da análise do checklist respondido e do RAP do projeto. O RAP transcreve
mudanças de escopo nos requisitos do projeto, provocados pelo cliente. Além disso relata
a diculdade da equipe de testes na realização das suas atividades, pois estas estão sendo
realizadas manualmente, sem uso de ferramenta automatizada.
Com relação ao retrabalho o gerente de projeto deve atuar junto a equipe de requisitos
e do cliente para melhorar o levantamento de requisitos, reduzindo a mudança dos mesmos
ao longo da iteração. Já com relação aos testes, o não uso de ferramental foi o motivo
que causou o maior aumento de esforço em relação ao previsto.
Com estas ações denidas, o gerente de projeto deve iniciar a segunda iteração e
focando nestes ajustes no PDS do projeto.
51
4 ESTUDO DE CASO
Este capítulo apresenta um exemplo da aplicação do PMP. O objetivo é aplicar em
um dos projetos utilizados na amostragem da base histórica, que o processo proposto é
valido e pode ser aplicado de forma paralela ao PDS de uma organização.
O projeto teve como resultado um ganho de produtividade ao longo do seu ciclo de
vida de desenvolvimento.
Dessa forma ca evidenciada a aplicação do processo em relação a produtividade de
um projeto de software. Quando se perde produtividade aumenta-se o risco de atrasos e
aumentos de custo, e quando se melhora a produtividade pode ser que o produto gerado
possa estar perdendo qualidade, por conta do não cumprimento integral das fases do PDS.
O estudo de caso é de um projeto de manutenção com o tamanho funcional estimado
em 122 PFs. O projeto possui 10 casos de uso, sendo que 6 foram na primeira iteração, 2
na segunda e 2 na terceira iterações. O PDS que foi utilizado para o seu desenvolvimento
foi o completo (ver Anexo 2), a linguagem predominante foi PHP. O esforço estimado
para o seu desenvolvimento foi de 1159 horas. A PEI denida pelo gerente de projeto foi
de 9,5 H/PF. A quantidade de recursos foi de 3 analistas e o prazo para a entrega cou
acordado para 4 meses. Este projeto foi dividido em 3 iterações e apresentou durante o
seu desenvolvimento ganho de produtividade no seu PDS.
4.1 ITERAÇÃO 1
Na primeira iteração foram desenvolvidos 6 casos de uso. A seguir são descritas todas as
atividades das fases de monitoramento e diagnóstico do PMP para a primeira iteração do
projeto deste estudo de caso.
4.1.1 ATIVIDADE 1 - OBTER INFORMAÇÕES DA ITERAÇÃO DO PROJETO.
Para usar o PMP o gerente de projeto deve dividir sua iteração em fases do PDS. Assim
é possível fazer uma análise da PAP por fase.
A seguir é apresentada a lista de fases por percentual de esforço (tamanho) do PDS
completo da organização avaliada. Neste estudo de caso o gerente de projeto alterou
52
a tabela por conhecer o seu cliente. A alteração que ele fez foi aumentar o percentual
da fase de requisitos para 35% e diminuir o percentual da fase de construção para 30%
em relação a tabela denida pelo PDS. No PDS a fase de requisitos tem 25% e a de
construção tem 40%. O gerente de projeto também redeniu os percentuais das fases de
testes e homologação. Essa redenição de percentuais pode ser para o projeto como um
todo ou por iteração.
a) Requisitos = 35%
b) Análise e Projeto = 10%
c) Construção = 30%
d) Testes = 10%
e) Homologação = 10%
f) Implantação = 5%
O dados obtidos são armazenados na PDI. A gura 4.1 apresenta um exemplo de PDI
preenchido que atende esta atividade do PMP.
FIG. 4.1: Exemplo da PDI preenchida na Atividade de Monitoramento - Obter Informações da Iteração do Projeto
53
4.1.2 ATIVIDADE 2 - ESTIMAR O TAMANHO E O ESFORÇO DA ITERAÇÃO.
O gerente de projeto deve contar os PFs estimados das funcionalidades por caso de uso
da iteração. Neste projeto do estudo de caso, a primeira iteração teve 6 casos de uso.
A seguir é listada a quantidade de PFs por caso de uso. Essa medição foi feita após o
detalhamento dos caso de uso e não ao nal da iteração.
a) Caso de Uso 1 = 25 PFs
b) Caso de Uso 2 = 10 PFs
c) Caso de Uso 3 = 14 PFs
d) Caso de Uso 4 = 3 PFs
e) Caso de Uso 5 = 19 PFs
f) Caso de Uso 6 = 3 PFs
A primeira iteração teve 74 PFs estimados.
Para encontrar a estimativa de esforço em horas da primeira iteração, o gerente de
projeto deve multiplicar a PEI pelo tamanho de todos os casos de uso da iteração estimados.
Para este projeto o tamanho estimado da primeira iteração é de 74 PFs e a PEI é de
9,5 H/PF. Logo o esforço estimado da iteração é de 703 horas.
Estas horas são as previstas para a alocação de esforço de toda a equipe do projeto
durante a iteração. O gerente de projeto precisa monitorar a apropriação (horas) e o
escopo da iteração (tamanho) durante a iteração. Se há super ou subalocação de horas
exitem problemas com o esforço, se há mudança de escopo ou retrabalho durante a iteração
existe um aumento ou redução do tamanho da iteração. Esse fatores podem impactar a
PAP da iteração. A gura 4.2 apresenta um exemplo de PDI preenchido que atende esta
atividade do PMP.
4.1.3 ATIVIDADE 3 - CALCULAR O TAMANHO FINAL DA ITERAÇÃO E A PAP
OU PFP
Ao nal da primeira iteração o gerente de projeto deve calcular o total de HH de esforço
real (nal) gastos para o desenvolvimento da iteração. Além do esforço gasto o gerente de
54
FIG. 4.2: Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o
Tamanho e o Esforço da Iteração
projeto deve medir o tamanho nal em PF da primeira iteração. Com estas duas medidas
é possível calcular a PAP da iteração.
A seguir é feita a apuração do esforço da equipe do projeto por fase da primeira
iteração.
a) Requisitos = 235 Horas
b) Análise e Projeto = 55,92 Horas
c) Construção = 181,1 Horas
d) Testes = 66,75 Horas
e) Homologação = 67,5 Horas
f) Implantação = 33,73 Horas
55
O gerente de projeto mediu a esforço apropriado pela equipe do projeto e foram apropriadas 640 horas. O tamanho da primeira iteração cou em 71 PFs. O tamanho da
iteração diminuiu, pois houve uma redução de escopo pelo cancelamento do caso de uso
6.
Sabendo o tamanho nal da primeira iteração (71 PFs) e o esforço apropriado pela
equipe do projeto na primeira iteraçao (640 horas), basta o gerente de projeto dividir o
esforço pelo tamanho para encontrar a PAP da primeira iteração. Fazendo a divisão a
PAP ca em aproximadamente 9 H/PF.
Houve desvio da PAP da primeira iteração em relação a PEI do projeto, o gerente de
projeto deve tomar ações de correção para evitar que este problema se propague pelas
iterações seguintes. Se o gerente de projeto não zer isto corre risco de atrasar e/ou
aumentar o custo do projeto, além de inuenciar a qualidade do produto entregue.
Neste projeto o risco, até o momento, está na perda da qualidade por conta da melhora
da PAP em relação a PEI do projeto.
Para saber em qual fase do PMP houve desvio da produtividade é preciso medir a
PAP por fase. A seguir é feito o cálculo dos PFs por fase da primeira iteração do projeto.
a) Requisitos (35%) = 24,85 PFs
b) Análise e Projeto (10%) = 7,1 PFs
c) Construção (30%) = 21,3 PFs
d) Testes (10%) = 7,1 PFs
e) Homologação (10%) = 7,1 PFs
f) Implantação (5%) = 3,55 PFs
Sabendo o tamanho e o esforço por fase da iteração, basta agora o gerente de projeto
calcular a produtividade da iteração por fase do PDS. A seguir é calculado a produtividade
do PDS por fase da primeira iteração.
a) Requisitos = 9,5 H/PF
b) Análise e Projeto = 7,9 H/PF
c) Construção = 8,5 H/PF
56
d) Testes = 9,4 H/PF
e) Homologação = 9,5 H/PF
f) Implantação = 9,5 H/PF
Pode ser visto que as fases que desviaram da PEI foram a de análise e projeto, construção e a de testes. A gura 4.3 apresenta um exemplo de PDI preenchido que atende
esta atividade do PMP.
FIG. 4.3: Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o
Tamanho Final da Iteração e a PAP ou PFP
Na próxima fase do PMP tem a aplicação do checklist para o diagnóstico das causas
do desvio da PAP.
4.1.4 ATIVIDADE 4 - APLICAR O CHECKLIST DO PMP.
Esta seção detalha os passos denidos pelo PMP para atender a fase de diagnóstico do
PDS do projeto. Esta fase não é obrigatória no PMP, pois nem toda iteração do projeto
terá desvios na sua PAP. Mas para este projeto é obrigatório, pois a PAP da primeira
iteração foi diferente da PEI do projeto. Lendo o RAP do projeto o gerente de projeto
não encontraria nenhum fator que impactaria a PAP da iteração.
No Anexo 4 está descrito o checklist do PMP. Abaixo segue a parte 2 do checklist da
primeira iteração respondido, pois houve melhora na produtividade na iteração.
57
a) Houve reuso de requisitos? Sim
b) Não foi encontrado erro nos requisitos especicados? Sim
c) Não houve subalocação de horas no projeto? Sim
d) Não houve integração com outras aplicações? Sim
e) Foi utilizada prototipação? Sim
f) Foi utilizada métrica para o acompanhamento da iteração? Sim
g) Os usuários especicadores dos requisitos conhecem bem os requisitos? Sim
h) Não houve teste não-funcional a partir da especicação dos requisitos? Sim
i) Não foram usados componentes de outras aplicações? Sim
Diagnóstico: A melhora na produtividade não é por conta do não cumprimento de
algum item do checklist. Aqui o motivo da melhora da produtividade é que a PEI superestimou o esforço do projeto. O gerente de projeto tem uma folga de prazo e custo.
Porém ainda precisa car alerta para as próximas iterações para não perder essa folga ou
até mesmo a produtividade piorar ao ponto de ocasionar atrasos e aumentos de custo do
projeto.
4.1.5 ATIVIDADE 5 - DEFINIR O RAA.
A seguir descrevo o RAA da Iteração 1 preenchido, de acordo com o modelo de RAA
previsto no Anexo 5.
Seção 1: Informações Gerais
Data do Relatório: 10/03/2014
Nome do Gerente do Projeto: Eduardo Alves de Oliveira
Identicação do Projeto: Estudo de Caso
Número da Iteração: 1
A PAP acumulada (ou PFP) em relação a PEI: (X) melhorou ( ) piorou
Seção 2: Itens Impactados do Checklist do PMP (para cada item deve haver a sua
descrição e diagnóstico do impacto)
Não houve.
58
Seção 3: Ações a serem tomadas para a próxima Iteração do PDS ou Lições Aprendidas
O gerente de projeto precisa manter o acompanhamento efetivo do projeto, para manter
a PAP menor ou igual a PEI sem perda de qualidade no produto entregue.
Após a denição do RAA é encerrado o PMP da primeira iteração do projeto do estudo
de caso. Agora será feita a avaliação da iteração 2 do estudo de caso.
4.2 ITERAÇÃO 2
Na segunda iteração foram desenvolvidos 2 casos de uso. A seguir são descritas todas as
atividades das fases de monitoramento e diagnóstico do PMP para a segunda iteração do
projeto deste estudo de caso.
4.2.1 ATIVIDADE 1 - OBTER INFORMAÇÕES DA ITERAÇÃO DO PROJETO.
Para usar o PMP o gerente de projeto deve dividir sua iteração em fases do PDS. Assim
é possível fazer uma análise da PAP por fase.
Para a segunda iteração o gerente de projeto manteve a mesma distribuição de esforço que foi denida na primeira iteração. O gerente de projeto poderia ter mudado
esta distribuição, levando-se em conta mudanças que tenham ocorrido no projeto que
justicassem a mudança na distribuição do percentual pelas fases do PDS.
a) Requisitos = 35%
b) Análise e Projeto = 10%
c) Construção = 30%
d) Testes = 10%
e) Homologação = 10%
f) Implantação = 5%
O dados obtidos são armazenados na PDI. A gura 4.4 apresenta um exemplo de PDI
preenchido que atende esta atividade do PMP.
59
FIG. 4.4: Exemplo da PDI preenchida na Atividade de Monitoramento - Obter Informações da Iteração do Projeto
4.2.2 ATIVIDADE 2 - ESTIMAR O TAMANHO E O ESFORÇO DA ITERAÇÃO.
O gerente de projeto deve contar os PFs estimados das funcionalidades por caso de uso
da iteração. Neste projeto, a segunda iteração teve 2 casos de uso. A seguir é listada a
quantidade de PFs por caso de uso. Essa medição foi feita após o detalhamento dos casos
de uso e não ao nal da iteração.
a) Caso de Uso 7 = 20 PFs
b) Caso de Uso 8 = 10 PFs
A segunda iteração teve 30 PFs estimados e a PEI é de 9,5 H/PF. Logo o esforço
estimado da iteração será de 285 horas. A gura 4.5 apresenta um exemplo de PDI
preenchido que atende esta atividade do PMP.
4.2.3 ATIVIDADE 3 - CALCULAR O TAMANHO FINAL DA ITERAÇÃO E A PAP
OU PFP.
A seguir é feito a apuração do esforço acumulado (iteração 1 e 2) da equipe do projeto
por fase.
a) Requisitos = 323,45 Horas
b) Análise e Projeto = 94,94 Horas
60
FIG. 4.5: Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o
Tamanho e Esforço da Iteração
c) Construção = 275,73 Horas
d) Testes = 95,95 Horas
e) Homologação = 92,92 Horas
f) Implantação = 42,1 Horas
Nas duas iterações o projeto teve 925 horas de apropriação com o tamanho nal de 101
PFs. Os casos de uso da iteração 2 não sofreram mudança de tamanho nal em relação ao
tamanho estimado. A PAP da segunda iteração cou em aproximadamente 9,16 H/PF.
Para saber em qual fase do PMP houve desvio da produtividade é preciso medir a
PAP por fase. A seguir é feito o cálculo dos PFs por fase do projeto.
a) Requisitos (35%) = 35,35 PFs
b) Análise e Projeto (10%) = 10,1 PFs
c) Construção (30%) = 30,3 PFs
d) Testes (10%) = 10,1 PFs
61
e) Homologação (10%) = 10,1 PFs
f) Implantação (5%) = 5,05 PFs
Sabendo o tamanho e o esforço por fase do projeto, basta agora o gerente de projeto
calcular a produtividade do projeto por fase do PDS. A seguir é calculado a produtividade
do PDS por fase.
a) Requisitos = 9,15 H/PF
b) Análise e Projeto = 9,4 H/PF
c) Construção = 9,1 H/PF
d) Testes = 9,5 H/PF
e) Homologação = 9,2 H/PF
f) Implantação = 8,34 H/PF
Nenhuma das fases teve sua produtividade pior que a PEI do projeto. Porém tirando
a fase de testes todas as outras tiveram melhora na produtividade em relação a estimada
no PEI. Neste caso o gerente de projeto deve diagnosticar os motivos dessa melhora na
produtividade no projeto. A análise dos motivos do desvio da PAP será feita na fase de
Diagnóstico do PMP da iteração e os dados da iteração devem ser armazenado na PDI.
A gura 4.6 apresenta um exemplo de PDI preenchido que atende esta atividade do
PMP.
Na próxima fase do PMP tem a aplicação do checklist para o diagnóstico das causas
do desvio da PAP.
4.2.4 ATIVIDADE 4 - APLICAR O CHECKLIST DO PMP.
Esta seção detalha os passos denidos pelo PMP para atender a fase de diagnóstico do
PDS do projeto. Esta fase não é obrigatória no PMP, pois nem todo ciclo de projeto terá
desvios na sua PAP. Mas para este projeto é obrigatório pois a PAP foi diferente da PEI
do projeto. No RAP do projeto o gerente de projeto relatou problemas com a apropriação
de horas da equipe na implantação do projeto.
No Anexo 4 está descrito o checklist do PMP. Abaixo segue a parte 2 do checklist da
segunda iteração respondido, pois houve melhora na produtividade na iteração.
62
FIG. 4.6: Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o
Tamanho Final da Iteração e a PAP ou PFP
a) Houve reuso de requisitos? Sim
b) Não foi encontrado erro nos requisitos especicados? Sim
c) Não houve subalocação de horas no projeto? Não
d) Não houve integração com outras aplicações? Sim
e) Foi utilizada prototipação? Sim
f) Foi utilizada métrica para o acompanhamento da iteração? Sim
g) Os usuários especicadores dos requisitos conhecem bem os requisitos? Sim
h) Não houve teste não-funcional a partir da especicação dos requisitos? Sim
i) Não foram usados componentes de outras aplicações? Sim
Diagnóstico: Houve melhora na produtividade mas foi detectado subalocação de horas apropriadas na fase de Implantação. O gerente de projeto deve criar uma ação de
monitoramento da apropriação de horas do projeto.
63
4.2.5 ATIVIDADE 5 - DEFINIR O RAA.
A seguir é descrito o RAA da Iteração 2 preenchido, de acordo com o modelo de RAA
previsto no Anexo 5.
Seção 1: Informações Gerais
Data do Relatório: 15/04/2014
Nome do Gerente do Projeto: Eduardo Alves de Oliveira
Identicação do Projeto: Estudo de Caso
Número da Iteração: 2
A PAP acumulada (ou PFP) em relação a PEI: (X) melhorou ( ) piorou
Seção 2: Itens Impactados do Checklist do PMP (para cada item deve haver a sua descrição e diagnóstico do impacto)
2.1.1) Descrição: Não houve subalocação de horas no projeto? Não
2.1.2) Diagnóstico: Foi detectado subalocação de horas apropriadas na fase de Implantação.
Seção 3: Ações a serem tomadas para a próxima Iteração do PDS ou Lições Aprendidas
O gerente de projeto deve ajustar o PDS de alguma forma para que possa evitar essa
subalocação, pois ela acaba distorcendo o valor da PAP do PDS do projeto.
Após a denição do RAA é encerrado o PMP da segunda iteração do projeto do estudo
de caso. Agora será feita a avaliação da iteração 3 do estudo de caso.
4.3 ITERAÇÃO 3
Na terceira e última iteração do projeto do estudo de caso foram desenvolvidos 2 casos de
uso. A seguir são descritas todas as atividades das fases de monitoramento e diagnóstico
do PMP para a terceira iteração do projeto deste estudo de caso.
4.3.1 ATIVIDADE 1 - OBTER INFORMAÇÕES DA ITERAÇÃO DO PROJETO.
Para usar o PMP o gerente de projeto deve dividir sua iteração em fases do PDS. Assim
é possível fazer uma análise da PAP por fase.
Para a terceira iteração o gerente de projeto manteve a mesma distribuição de esforço
que foi denida na primeira e segunda iterações. O gerente de projeto poderia ter mudado
esta distribuição, levando-se em conta mudanças que tenham ocorrido no projeto que
justicassem a mudança na distribuição do percentual pelas fases do PDS.
64
a) Requisitos = 35%
b) Análise e Projeto = 10%
c) Construção = 30%
d) Testes = 10%
e) Homologação = 10%
f) Implantação = 5%
O dados obtidos são armazenados na PDI. A gura 4.7 apresenta um exemplo de PDI
preenchido que atende esta atividade do PMP.
FIG. 4.7: Exemplo da PDI preenchida na Atividade de Monitoramento - Obter Informações da Iteração do Projeto
4.3.2 ATIVIDADE 2 - ESTIMAR O TAMANHO E O ESFORÇO DA ITERAÇÃO.
O gerente de projeto deve contar os PFs estimados das funcionalidades por caso de uso
da iteração. Neste projeto, a terceira iteração teve 2 casos de uso. A seguir é listada a
quantidade de PFs por caso de uso. Essa medição foi feita após o detalhamento dos caso
de uso e não ao nal da iteração.
a) Caso de Uso 9 = 7 PFs
b) Caso de Uso 10 = 4 PFs
65
A terceira iteração teve 11 PFs estimados.
O tamanho estimado da terceira iteração é de 11 PFs e a produtivida denida no
planejamento inicial do projeto foi de 9,5 H/PF. Logo o esforço estimado da iteração será
de 104,5 horas. A gura 4.8 apresenta um exemplo de PDI preenchido que atende esta
atividade do PMP.
FIG. 4.8: Exemplo da PDI preenchida na Atividade de Monitoramento - Estimar o
Tamanho e Esforço da Iteração
4.3.3 ATIVIDADE 3 - CALCULAR O TAMANHO FINAL DA ITERAÇÃO E A PAP
OU PFP.
Como esta é a última iteração do projeto o gerente de projeto precisa vericar se a PFP
está diferente da PEI do projeto.
A seguir é feito a apuração do esforço acumulado (iteração 1, 2 e 3) da equipe do
projeto por fase.
a) Requisitos = 360,96 Horas
b) Análise e Projeto = 103,85 Horas
c) Construção = 310,54 Horas
66
d) Testes = 102,85 Horas
e) Homologação = 102,85 Horas
f) Implantação = 48,42 Horas
Nas três iterações o projeto teve 1029,5 horas de apropriação com o tamanho nal
de 112 PFs. Os casos de uso da iteração 3 não sofreram mudança de tamanho nal em
relação ao tamanho estimado. A PFP cou em aproximadamente 9,2 H/PF.
Para saber em qual fase do PMP houve desvio da produtividade é preciso medir a
PAP por fase. A seguir é feito o cálculo dos PFs por fase do projeto.
a) Requisitos (35%) = 39,2 PFs
b) Análise e Projeto (10%) = 11,2 PFs
c) Construção (30%) = 33,6 PFs
d) Testes (10%) = 11,2 PFs
e) Homologação (10%) = 11,2 PFs
f) Implantação (5%) = 5,2 PFs
Sabendo o tamanho e o esforço por fase do projeto, basta agora o gerente de projeto
calcular a produtividade do projeto por fase do PDS. A seguir é calculado a produtividade
do PDS por fase.
a) Requisitos = 9,2 H/PF
b) Análise e Projeto = 9,3 H/PF
c) Construção = 9,2 H/PF
d) Testes = 9,2 H/PF
e) Homologação = 9,2 H/PF
f) Implantação = 9,3 H/PF
67
Todas as fases tem sua produtividade melhor que a PEI do projeto. Sendo assim o
gerente de projeto deve diagnosticar os motivos dessa melhora já no término do projeto.
A análise dos motivos do desvio da PFP será feita na fase de Diagnóstico do PMP da
iteração e os dados da iteração devem ser armazenado na PDI.
A gura 4.9 apresenta um exemplo de PDI preenchido que atende esta atividade do
PMP.
FIG. 4.9: Exemplo da PDI preenchida na Atividade de Monitoramento - Calcular o
Tamanho Final da Iteração e a PAP ou PFP
Na próxima fase do PMP tem a aplicação do checklist para o diagnóstico das causas
do desvio da PPF.
4.3.4 ATIVIDADE 4 - APLICAR O CHECKLIST DO PMP.
Esta seção detalha os passos denidos pelo PMP para atender a fase de diagnóstico do
PDS do projeto. Esta fase não é obrigatória no PMP, pois nem todo ciclo de projeto terá
desvios na sua PAP. Mas para este projeto é obrigatório pois a PFP foi diferente da PEI
do projeto.
No Anexo 4 está descrito o checklist do PMP. Abaixo segue a parte 2 do checklist da
segunda iteração respondido, pois houve melhora na PFP em relação a PEI do projeto.
a) Houve reuso de requisitos? Sim
68
b) Não foi encontrado erro nos requisitos especicados? Sim
c) Não houve subalocação de horas no projeto? Sim
d) Não houve integração com outras aplicações? Sim
e) Foi utilizada prototipação? Sim
f) Foi utilizada métrica para o acompanhamento da iteração? Sim
g) Os usuários especicadores dos requisitos conhecem bem os requisitos? Sim
h) Não houve teste não-funcional a partir da especicação dos requisitos? Sim
i) Não foram usados componentes de outras aplicações? Sim
Diagnóstico: A melhora na PFP não é por conta do não cumprimento de algum item
do checklist. Aqui o motivo da melhora da produtividade é que a PEI foi superestimada.
Por conta disso o projeto foi entregue com prazo e custos menores que o planejado.
4.3.5 ATIVIDADE 5 - DEFINIR O RAA.
A seguir descrevo o RAA da Iteração 3 preenchido, de acordo com o modelo de RAA
previsto no Anexo 5.
Seção 1: Informações Gerais
Data do Relatório: 13/05/2014
Nome do Gerente do Projeto: Eduardo Alves de Oliveira
Identicação do Projeto: Estudo de Caso
Número da Iteração: 3
A PAP acumulada (ou PFP) em relação a PEI: (X) melhorou ( ) piorou
Seção 2: Itens Impactados do Checklist do PMP (para cada item deve haver a sua
descrição e diagnóstico do impacto)
Não houve.
Seção 3: Ações a serem tomadas para a próxima Iteração do PDS ou Lições Aprendidas
O gerente de projeto deve avaliar junto aos responsáveis pela base histórica de projetos
da empresa se cabe uma mudança ou não na produtividade estimada para este tipo de
PDS com a linguagem PHP.
69
4.4 DISCUSSÃO
O processo de acompanhamento proposto permite ao gerente de projeto realizar uma
acompanhamento da produtividade de seu projeto, ao longo do ciclo de vida de seu
desenvolvimento. O grande benefício desse processo em relação a outros métodos de
acompanhamento de produtividade é que este é baseado no requisito funcional do projeto
e permite que o gerente de projeto faça o monitoramento e diagnóstico de impactos que
estão aumentando ou reduzindo a produtividade do projeto em relação à produtividade
estimada no início do projeto.
Utilizar o requisito funcional permite que o projeto seja medido usando uma métrica
funcional de tamanho. A métrica funcional proposta por este estudo é a APF, porém a
empresa que utilizar o PMP poderá utilizar outra métrica funcional, ou seja o PMP é
ajustável em relação à métrica de dimensionamento funcional.
O monitoramento dos impactos é feito através de um checklist que avalia os fatores
que podem estar reduzindo ou aumentando a produtividade do projeto que está sendo
acompanhado. Também o checklist pode ser ajustado de acordo com a base histórica da
empresa que estiver utilizando o PMP. Isso é possível graças ao uso de uma ferramenta de
mineração de dados WEKA e o algoritmo APRIORI, que gera as regras de relação entre
as variáveis antecedentes e a consequente produtividade.
A aplicação do PMP não é possível em projetos que tenham apenas uma iteração, ou
seja, apenas uma entrega denida. Isso ocorre porque o objetivo principal do processo
proposto é monitorar a produtividade do projeto ao longo do ciclo de vida do mesmo. Se
ele tem apenas uma iteração, esse monitoramento não pode ocorrer.
Outra diculdade que a empresa que for adotar o PMP vai encontrar é com relação
a ela possuir uma base histórica de projetos. Caso ela não possua essa base histórica
ela terá diculdades para criar o seu próprio checklist. Isso pode ser contornado através
da aplicação de um questionário que obterá os atributos de projeto que serão candidatos
a antecedentes da variável consequente produtividade nas regras de associação extraídas
pelo algoritmo APRIORI.
4.4.1 O PMP E O GERENCIAMENTO DE CONTRATOS
O PMP, além de atender ao acompanhamento da produtividade de um PDS, pode ser
utilizado para: acompanhar o desembolso de um determinado contrato de desenvolvimento
70
remunerado por esforço baseado em métrica funcional; e ser indicador de controle dos
acordos de níveis de serviço (ANSs) do contrato, que impõem parâmetros de qualidade e
prazo no produto entregue.
Conforme já descrito neste estudo, o PMP monitora a PAP acumulada do projeto a
cada término de uma iteração, em relação a PEI calculada no planejamento inicial do
mesmo. Ocorrendo desvio da PAP em relação a PEI é um indicativo que poderemos
ter problemas de custo, prazo ou na qualidade do produto entregue ao nal do ciclo de
desenvolvimento do projeto.
O acompanhamento do custo pelo PMP ajuda ao gestor do contrato a saber se o
custo estimado, para a execução do projeto, está saindo do previsto ou não durante a
execução do contrato. Inclusive pode alertá-lo de forma antecipada se o contrato irá ter
nanceiro suciente para atender o escopo contratado. O monitoramento das ANSs pelo
PMP permite avaliar se o prazo e a qualidade no nal de cada iteração está atendendo aos
critérios denidos em contrato, podendo ser aplicado penalidades (multas) ao contratante
pelo não cumprimento do(s) ANS(s) .
Sendo assim o PMP pode: acompanhar o desembolso nanceiro de um contrato
baseado nas funcionalidade contratadas pelo usuário e entregues pelo projeto de software por iteração. O ponto de vista é baseado nas funcionalidades contratadas pelo
usuário (escopo) e não simplesmente no custo do projeto; e monitorar os ANSs de prazo
de entrega e qualidade do produto produzido pelo projeto.
Se a PAP de uma iteração está pior que a PEI já é um sinal de que provavelmente o
custo do projeto será maior que o previsto inicialmente e provavelmente o projeto sofrerá
atraso em sua entrega, violando uma ou mais ANSs. Ajustes no PDS precisam ser feitos,
antes do término do projeto, para recolocar o custo e prazo do projeto dentro do previsto.
Pois caso contrário, o projeto não terá recursos nanceiros sucientes para atender todo
o escopo contratado pelo usuário, e no caso do prazo o projeto não será entregue no prazo
esperado. Se isso acontecer o projeto precisará de um aporte nanceiro, muitas vezes
impossível de ser realizado, e no caso de perda de prazo pode inviabilizar a sua entrega e
acarretar penalidade à contratada por conta do ANS. Outra solução seria reduzir o escopo
funcional do projeto previsto inicialmente, o que não atenderia plenamente as necessidades
do usuário que solicitou o projeto.
Esse acompanhamento pode ser incluído na atividade de Calcular o Tamanho Final
da Iteração e a PAP ou PFP na fase de Monitoramento do PMP. É nesta atividade que o
71
gerente de projeto sabe se a PAP até o momento ou o PFP está melhor ou pior que a PEI.
O PFP seria calculado na última iteração do projeto e se for diferente da PEI, precisa ser
apurado as diferenças nos parâmetros de custo, prazo e qualidade previsto inicialmente
no projeto, acarretando aumento ou não de custo, prazo no projeto e a cobrança ou não
de penalidades por conta do não cumprimento de alguma ANS de prazo ou qualidade.
Caso a PAP esteja melhor, o gerente de projeto a princípio pode considerar que não
terá desvio de custo em relação ao previsto pelo projeto. Porém ele precisa passar pela
fase de Diagnóstico do PMP para saber os motivos para a melhora da PAP, para saber
se não haverá até o nal do projeto perda de qualidade no produto entregue, acarretando
possível aumento de custo e surgimento de penalidades pelo não cumprimento de uma ou
mais ANSs, principalmente as ligadas ao controle da qualidade do produto entregue.
Se a PAP esta pior que a PEI, o projeto poderá ter aumento de custo se precisar
entregar todo o escopo denido no início do projeto. Caso não seja tomada alguma
providência de ajuste no PDS, que melhore a PAP, o aumento de custo vai ocorrer por
conta do aumento de esforço pela perda de produtividade em relação a PEI.
72
5 TRABALHOS RELACIONADOS
Neste capítulo apresento um método que objetiva o monitoramento da produtividade
dos projetos de software e outro que se preocupa com a estimativa da produtividade dos
projetos. A seção 5.1 apresenta a Análise de Valor Agregado (PMI, 2008); a seção 5.2 apresenta o modelo de Regressão Linear (MACDONELL, 1996), (GRAY, 1997), (ASCARI,
2012).
5.1 ANÁLISE DO VALOR AGREGADO
A técnica do valor agregado foca na relação entre os custos reais e o produto entregue,
através da realização efetiva de um trabalho (ver gura 5.1) (PMI, 2008).
FIG. 5.1: Exemplo de Gráco do Valor Agregado
É um método de mensuração e reporte de desempenho de projeto, que pode ser usado
para a gestão do custo e prazo. Sua base de avaliação está na comparação do que o projeto
já obteve de resultado em relação ao que realmente foi gasto, e o que foi planejado para se
gastar. O nome de valor agregado é dado ao valor orçado para um determinado trabalho,
em um determinado período de tempo, no ciclo de vida de um projeto (VARGAS, 2005).
Podem ser consideradas vantagens deste método:
a) Dar uma resposta de desempenho com relação ao trabalho executado, ou seja, avaliase quanto se gastou com relação ao que se deveria ter gasto para realizar o trabalho
73
que foi realizado. Enquanto a abordagem tradicional simplesmente compara o que
foi gasto com o quanto se planejou gastar até determinado momento do projeto,
sem a preocupação de avaliar o trabalho realizado com esse custo;
b) Segundo (SPARROW, 2000) propicia um valor adicional ao projeto por oferecer
uma visibilidade precoce dos seus resultados nais, ou seja, pode-se determinar a
tendência de custos e prazos nais do projeto em uma fase do projeto onde ainda
exista possibilidade de implementação de ações corretivas;
Podem ser consideradas desvantagens deste método:
a) Segundo (CHRISTENSEN, 1998) a aplicação deste método requer uma mudança
cultural na empresa que o utilizar. Por isso demanda tempo e esforço para ser
efetivamente implantado. As políticas e o conhecimento de sua aplicação devem ser
entendidos pelas equipes de projeto, para assim garantir um uso correto da técnica;
b) Requer grande quantidade de esforço em sua manutenção, necessitando de uma
equipe qualicada para compreender e proporcionar informações conáveis (WIDEMAN, 1999);
c) Diversos gerentes de projeto não a consideram uma boa relação custo-benefício
(WIDEMAN, 1999);
d) Não controla as variáveis de custo e prazo através dos requisitos do projeto. Isso
diculta uma análise da produtividade do projeto com foco nos requisitos solicitados
(OLIVEIRA, 2013);
e) Não faz uma avaliação dos impactos que acarretaram um ganho ou perda de produtividade do projeto, ou seja, não facilita a denição de ações de correção do gerente
de projeto no PDS do projeto (OLIVEIRA, 2013).
5.2 REGRESSÃO LINEAR
Os modelos de Regressão Linear são modelos matemáticos que criam uma relação entre
uma variável Y com outra variável X. Quando existem apenas duas variáveis relacionadas,
esta é chamada regressão simples. Quando a relação envolve mais de duas variáveis é uma
74
FIG. 5.2: Exemplo de Regressão Linear - Diagrama de Dispersão
regressão multivado (MACDONELL, 1996). A representação dessa relação ocorre através
de pontos em um gráco cartesiano chamado de diagrama de dispersão (ver gura 5.2).
É um modelo utilizado para denir uma equação que relaciona uma variável independente a uma outra variável dependente desta. Pode ser usada para prever valores futuros
da variável dependente baseados na equação denida pelo modelo. No caso deste estudo
seria a previsão de produtividade de um novo projeto baseado em uma equação denida
através do estudo da base histórica da empresa.
Podem ser consideradas vantagens deste modelo:
a) Permite estabelecer a relação funcional entre uma variável dependente e uma variável
independente. Assim consegue representar o fenômeno em estudo através de uma
equação, permitindo uma simulação a tendência de uma variável em relação a outra;
b) É baseada em conceitos de estatística experimental, ou seja, possuem comprovação
matemática.
Podem ser consideradas desvantagens deste modelo:
a) O estabelecimento da relação funcional de uma variável dependente e outra independente não responde se a variável independente inuencia signicamente a variação
da variável dependente. Sendo assim, esse modelo não permite avaliar a correlação
entres variáveis independentes do projeto que podem estar impactando a variável
dependente (LIMA, 2014);
75
b) O foco desse modelo é denir a produtividade estimada inicial de um projeto,
baseado na produtividade de projetos já realizados (base histórica) e não na produtividade do projeto ao longo do seu ciclo de vida de desenvolvimento.
5.3 COMPARATIVO
O processo de monitoramento de produtividade proposto neste trabalho permite que o
gerente de projeto monitore e faça o diagnóstico de impactos na produtividade do projeto
ao longo do seu ciclo de vida focado nos requisitos solicitados.
Por estar baseado nos requisitos é possível medir o projeto usando uma métrica de
tamanho funcional. A medição funcional permite que um projeto seja comparado com
projetos anteriores, que já foram medidos funcionalmente, independente dos requisitos
que foram atendidos. Assim o processo de medição torna parametrizado o tamanho dos
projetos, permitindo a comparação entre eles e a denição de produtividade histórica.
O uso do algoritmo APRIORI no processo proposto permite que se encontre as relações
entre as variáveis que impactam a produtividade através do uso de uma base histórica de
projetos e a aplicação de um questionário para a denição de mais variáveis não disponíveis
nesta base. Essas relações servem para avaliar o impacto na produtividade durante o ciclo
de vida do projeto, que é objetivo desse estudo.
Na análise comparativa conclui-se que a regressão linear calcula apenas a produtividade
inicial de um novo projeto, logo não atende o objetivo desse estudo. Já a técnica do valor
agregado (EVA) preocupa-se com a produtividade de acompanhanto do projeto, porém
não é focado nos requisitos do projeto. Nos dois casos não há uma denição de um
processo de avaliação do impacto na produtividade de um PDS.
TAB. 5.1: Comparação entre os trabalhos relacionados
Conceito
EVA Regressão Linear Metodologia Proposta
Foco nos Requisitos do Projeto NÃO
Avalia a PEI do Projeto
SIM
Acompanha a PAP do Projeto SIM
Possui Checklist de Avaliação NÃO
Usa APRIORI
NÃO
NÃO
SIM
NÃO
NÃO
NÃO
76
SIM
SIM
SIM
SIM
SIM
6 CONSIDERAÇÕES FINAIS
6.1 CONCLUSÃO
Em grandes projetos de desenvolvimento é comum haver a divisão em projetos menores,
que, em muitos casos, continuam sendo grandes projetos. Adotando o PMP, é possível
que estes projetos possam beneciar-se, não somente de análises de suas produtividades,
mas também das análises das PAPs dos outros projetos em paralelo.
A empresa que adotar o PMP poderá alimentar uma base histórica com as informações
geradas por ele, que seria de grande importância para o monitoramento da produtividade
de projetos posteriores. O benefício desse método está na descrição da utilização de um
indicador para medição e análise de possíveis desvios da PEI chamado PAP.
A grande vantagem de se medir a PAP, ao longo do ciclo de desenvolvimento, é permitir
que o gerente de projeto tenha mais insumos para tomada de decisão durante o ciclo de
vida do projeto.
A cada término de iteração é possível que o gerente de projeto tome ações de ajuste
no PDS do projeto de acordo com o diagnóstico realizado através do checklist e do RAP
do projeto que está sendo monitorado.
O gerente de projeto deve ter atenção em relação a PAP quando estiver acima da
PEI, pois esta melhoria de produtividade pode estar ligada ao não cumprimento integral
do que deve ser seguido pelo PDS, o que pode acarretar perda de qualidade no produto
entregue.
6.2 CONTRIBUIÇÕES
A grande contribuição deste estudo é a denição de um processo que permite acompanhar
a produtividade de um projeto de software utilizando as funcionalidades do projeto. Ter
um checklist que avalia os motivos que zeram a PAP desviar da PEI é outro diferencial
em relação a outros trabalhos relacionados.
O PMP pode ser adaptado pela empresa que adotá-lo. A empresa pode utilizar a
métrica funcional que ela desejar, assim como criar o seu próprio checklist utilizando sua
base histórica de projetos, e se necessário, um questionário para obtenção de informações
77
relevantes para a obtenção dos atributos de projeto que impactam na produtividade dos
projetos da empresa. A ferramenta data mining utilizada também poderá ser outra.
6.3 TRABALHOS FUTUROS
Como trabalhos futuros o autor sugere.
6.3.1 CONSTRUÇÃO DE UMA FERRAMENTO DE APOIO AO PMP
A automatização do processo faria que todas as informações utilizadas e geradas pelo PMP
cassem armazenadas em um banco de dados invês do uso de uma planilha eletrônica.
A ferramenta possibilitaria a construção de um workow para a execução do PMP
e a centralização dos dados em uma base histórica com um estrutura que permitisse a
geração facilitada de consultas gerenciais.
6.3.2 DEFINIÇÃO OU EVOLUÇÃO DE UM MODELO ESTATÍSTICO PARA A BASE
HISTÓRICA DE PROJETOS
Existem modelos estatísticos que possibilitam a simulação qualitativa de atributos em
projetos de software. Seria uma solução para os casos onde o histórico de projetos não
é signicativo na empresa. A simulação de Monte Carlo (WHITHESIDE, 2008) é um
exemplo de modelo estatístico que é utilizado quando não é possível obter dados históricos
utilizando técnicas de regressão tradicionais.
Denindo um modelo estatístico de simulação para o PMP possibilitaria a aplicação
em empresas com bases históricas pequenas ou inexistentes. Assim aumentaria a aplicação
do processo no mercado.
O conceito por trás deste modelo seria o uso de uma pequena amostragem de projetos
da empresa e daí a derivação de mais dados através destes. Assim o PMP teria um
suporte estatístico na apuração das relações entre as variáveis utilizando a ferramenta de
data mining.
78
7 REFERÊNCIAS BIBLIOGRÁFICAS
Function Point Analysis: An Empirical Study
AAaof Its Measurement Processes, IEEE Transaction on Software Engineering, V.
ABRAN, A.; ROBILLARD P. N.
AAA22, No . 12, December 1996.
AGRAWAL, R. et al. The Quest Data Mining System, in Proc, 2nd Int'l Conference
AAAon Knowledge Discovery in Databases and Data Mining, Portland, p.244-249, 1996.
AGRESTI, W.; EVANCO W. M.; THOMAS W. M. Models for Improving Software
AAaSystem Size Estimates during Development, J. Software Engineering AppliAAAcations, p.1-10, 2010.
Pontos de Função ou Pontos por Caso de Uso? Como Estimar
AAaProjetos Orientados a Objeto. Disponível em: <http://www.bfpug.com.br/ArAGUIAR, M.
AAaatigos/UCP/Aguiar-Pontos-de-Funcao-ou-Pontos-por-Caso-de-Uso.pdf>. Acessado
AAaaem: 01/05/2013.
Software Function, Source Lines of Code, and
AAaDevelopment Eort Prediction: A Software Science Validation, IEEE TranALBRECHT, A.; GAFFNEY J.
AAAsactions on Software Engineering, SE-9, 1983.
AMBLER, S. W. Completing
AAAbySoft Inc., 1999.
the Unied Process With Process Patterns, Am-
ARBEX, E. C.; SABOREDO A. P.; MIRANDA P., Implementação e Estudo de caso
AAado algoritmo Apriori para Mineração de Dados, Associação Dom Bosco,
AAAResende, 2013.
Aplicação de Lógica Fuzzy na Estimativa de Prazo de
AAaProjetos de Software, Revista Eletrônica de Sistemas de Informação, 2012.
ASCARI, R. E. O. S. et al.
BOEHM, B. Managing Software
AAAPress, p.111-113, 1999.
Productivity and Reuse, IEEE Computer Society
BORSOI, B. T. et al. Redes Neurais Aplicadas na Estimativa de Prazo de Projeto
AAade Software, Universidade Tecnológica Federal do Paraná (UTFPR), Pato Branco,
AAA2012.
BRUCKHAUS, N. T.; MADHAVJI, I. J.; HENSHAW J. The Impact of Tools
AAaSoftware Productivity, IEEE Computer Society Press, p.29-38, 1996.
79
on
CARD, D. N. The Challenge of Productivity
AAASoftware Quality Conference, 2006.
Measurement, Pacic Northwest
CHIDAMBER, S. R.; KEMERER, C. F. A Metrics Suite for
AAasign, Transactions on Software Engineering (TSE), 1994.
CONNOLLEY, M. An Empirical Study of Function
AAAMassachusetts Institute of Technology, USA, 1990.
CHRISTENSEN, D. S. The Cost and Benets of
AAaProcess, Acquisition Review Quarterly, 1998.
Object Oriented De-
Points Analysis Reliability,
the Earned value Management
DAMASCENO, M. Introdução a Mineração de Dados Utilizando o Weka, Instituto
AAAFederal de Educação, Ciência e Tecnologia do Rio Grande do Norte, 2005.
FENTON, N. E.; PFLEEGER, S. L. Software
AAaApproach, 2nd ed. Thomson, 1996.
Metrics: A Rigorous and Practical
FLEMING, Q. W.; KOPPELMAN, J. M. Earned Value Project Management, NewAAAton Square, 1999.
A Comparative of Techniques for Developing
AAaPredictive Models of Software Metrics, University of Otago, Dunedin, 1997.
GRAY, A. R.; MACDONELL S. G.
HAN, S. L. Quantied Comparison and Analysis of Dierent Productivity MeaAAasurements, Journal of Asian Architecture and Building Engineering, November
AAA2008.
INTERNATIONAL FUNCTION USERS GROUP (IFPUG). Counting Practices ManAAual (CPM), V. 4.3.1, publicado em 2010.
THE INTERNATIONAL SOFTWARE BENCHMARKING STANDARDS GROUP LIMAAAITED (ISBSG). Disponível em: <http://www.isbsg.org>. Acessado em: 20/10/2013.
JONES, C. Positive and Negative Factors that Inuence Software Productivity,
AAAV. 2.0. Software Productivity Research Inc., 1998.
Role of Function Point as a Reuse Metric in a Software AsAAaset Reuse Program, International Conference on Software Engineering Research
JOSEPH,J. T.
AAAand Practice (SERP),Las Vegas, 2011.
KARNER, G. Resource
AAAAB, 1993.
KERZNER, H.
Estimation for Objectory Projects, Objective Systems SF
Project Management: A Systems approach to planning, sched80
AAauling and controlling, New Jersey, 2009.
LANZA, M.; MARINESCU, R.
AAAlag, 2006.
Object-Oriented Metrics in Practice, Springer Ver-
LARMAN, C. Utilizando UML e Padrões:
uma introdução à análise e ao projeto
AAaorientado a objetos e ao Processo Unicado, Trad. Luiz Augusto Meirelles
AAASalgado e João Tortello. 2 ed. Porto Alegre: Bookman, 2004.
LIMA, P. C; LIMA, R. R. Estatística Experimental. Guia de Estudos, UniversiAAAdade Federal de Lavras. Disponível em: <http://www.dex.ua.br/images/stories>.
AAAAcessado em: 20/06/2014.
MACDONELL, S. G.; GRAY, A. R. Alternatives to Regression Models for EstiAAamation Software Projects, The Information Science Discussion Paper Series,
AAA1996.
MILLS, E. E. Software Metrics - SEI Curriculum Module SEI-CM-12-1.1, Seattle
AAaUniversity, Carnegie Mellon University, Software Engineering Institute, 1988.
Estudo e Propostas Iniciais para a Denição de um
AAaprocesso de desenvolvimento para software cientíco, Centro Federal de
MOURA, M. C.; PURRI, S.
AAAEducação Tecnológica de Minas Gerais, 2006.
OLIVEIRA, E. A.; NOYA, R. C. Using Productivity Measure and Function Points
AAato Improve the Software Development Process, The 2013 International ConAAAference on Software Engineering Research and Practice (SERP), Las Vegas, 2013.
PARO, C. Medidas de tamanho de desenvolvimento e de melhorias de software.
AAADisponível em: <http://www.bfpug.com.br>. Acessado em: 02/07/2013.
PAULA, W. P. Engenharia de Software
AAAEditora, Rio de Janeiro, 2001.
Fundamentos, Métodos e Padrões, LTC
PFLEEGER, S. L. Software Engineering: Theory
AAASaddle River, New Jersey: Prentice-Hall, 2001.
and Practice, 2o ed. Upper
PROJECT MANAGEMENT INSTITUTE (PMI), PMBok - Project Management
AAaBody of Knowledge- Guide and Standards, 4a Edition, 2008.
PRESSMAN, R.
Engenharia de Software, McGraw-Hill, 2011.
PRESSMAN, R.
AAA2005.
Software Engineering: A Practitioners Approach, McGraw-Hill,
81
RAHMESH, S. P. Factors inuencing productivity of software projects
AAAScenario, Research Scholar, Sathyabama University, India, [199-].
Indian
A Review of Productivity Factors and Strategies on
AAaSoftware Development, Software Engineering Advances (ICSEA), 2010
SAMPAIO, B.S.C. et al.
AAAFifth International Conference, p.196 204, 2010.
SCHOFIELD, J. The Statistically Unreliable
AAANational Laboratory, Albuquerque, 2005.
SEIBT, P.R.R. Ferramenta para Cálculo
AAa Objetos, Blumenau, Novembro 2011.
SHARP H. et al. Models
AAATechnologie, 2008.
Nature of Lines of Code, Sandia
de Métricas em Softwares Orientados
of motivation in software engineering, Inf. Software.
SOUSA, P.; ABREU, F. P. Uma
Abordagem de Estimativa de Software Baseada
AAaem Produtividade por Categoria de Caso de Uso. Anais do X Simpósio
AAABrasileiro de Qualidade de Software, Curitiba, Brasil, p.361-368, 2011.
EVM - Earned value Management Results in Early Visibility
AAaand Management Opportunities, Houston: 31st Annual Project Management
SPARROW, H.,
AAAInstitute Seminars Symposium, 2000.
SPEM - Software Systems Process EngiAAaneering Metamodel Specication, V. 2.0, 2008.
OBJECT MANAGEM GROUP (OMG),
SOFTWARE PRODUCTIVITY RESEARCH (SPR), Disponível em: <http://www.spr.
AAAcom/index.php>. Acessado em : 01/02/2013.
SUDHAKAR, G. P.; FAROOQ A.; Patnaik S. Measuring Productivity
AAaDevelopment Teams, Serbian Journal of Management, 2012.
of Software
Comparison of Articial
AAaNeural Network and Regression Models in Software Eort Estimation,
TRONTO, I. F. B., SILVA, J.D.S. and SANT'ANNA, N.
AAAIJCNN - International Joint Conference on Neural Networks, Florida, 2007.
UNITED KINGDOM SOFTWARE METRICS ASSOCIATION (UKSMA). MK II FuncAAtion Point Analysis Counting Practices Manual, V. 1.3.1, Setembro, 1998.
Análise de Valor Agregado: revolucionando o gerenciamento
AAade custos e prazos. 3a Ed. Rio de Janeiro: Brasport, 2005.
VARGAS, Ricardo.
VIEIRA, E. Uso do Conceito de Passos Obrigatórios para Aprimorar o Processo
AAde Contagem do Método Pontos de Caso de Uso, Universidade Federal de
82
AAASanta Catarina, Florianópolis, 2007.
WAIKATO ENVIRONMENT FOR KNOWLEDGE ANALYSIS (WEKA), Data Mining
AAaSoftware in Java, Machine Learning Group at the University of Waikato. Disponível
AAAem: <http://www.cs.waikato.ac.nz/ml/weka>. Acessado em: 01/09/2013.
WALT, S. Understanding Software Productivity, Software Engineering and KnowlAAAedge Engineering: Trends for the Next Decade, D. Hurley (ed.), V. 4, World Scientic
AAAPress, 1995.
WHITHESIDE II, J. D. A Practical Application of Monte Carlo Simulation
AAaForecasting, EST.04, AACE International Transactions, Toronto, 2008.
WIDEMAN, R. M. Cost
in
Control of Capital Projects and the Project Cost ManAAAagement Systems Requirements, 2a ed. Vancouver: AEW Services e BiTech,
AAA1999.
83
8 APÊNDICES
84
8.1 APÊNDICE 1 - ATRIBUTOS DA BASE HISTÓRICA DE PROJETOS DA EMPRESA AVALIADA
• Produtividade Estimada: produtividade utilizada no planejamento inicial;
• Produtividade Final: produtividade real do projeto, calculada ao seu nal;
• Tamanho Estimado: tamanho estimado em PFs dos requisitos do projeto;
• Tamanho Final: tamanho nal em PFs do produto entregue pelo projeto;
• Esforço Estimado: número estimado de horas de esforço para a entrega do projeto;
• Esforço Real: número real de horas apropriadas pela equipe do projeto;
• Data de Entrega Esperada: data esperada pelo cliente para o recebimento do pro-
jeto. Esta data é denida no planejamento inicial;
• Data Real de Entrega: data que o projeto foi entregue;
• Taxa de Defeitos: indicador gerado pela área de testes da organização, que indica a
quantidade erros encotrados no produto por PF;
• Tipo de Processo: tipo de PDS utilizado no projeto (ver próxima seção para mais
detalhes);
• Linguagem: linguagem de progamação predominante no projeto. Entre várias pos-
sibilidade destacam-se - Cobol, Natural, PHP, .NET, Java;
• Tipo de Demanda: tipo de demanda de projeto. Entre várias possibilidades destacam-
se - Novo Desenvolvimento, Manutenção Corretiva, Manutenção Evolutiva.
85
8.2 APÊNDICE 2 - TIPOS DE PDS DA EMPRESA AVALIADA
• Expresso: PDS simples para pequenas demandas de 8 a 16 horas de esforço estimado;
• Sumário: PDS com um subcojunto de atividades e artefatos do PDS da organização.
É utilizado para projetos com esforço estimado menores que 480 horas;
• Ágil: PDS baseado na metodologia de desenvolvimento ágil. Sua aplicação inde-
pende do esforço previsto pelo projeto. A decisão pelo seu uso é gerencial;
• Completo: PDS que inclui grande parte das atividades e artefatos do PDS da orga-
nização. Deve ser adotado para projetos com mais de 480 horas de esforço estimado.
86
8.3 APÊNDICE 3 - QUESTIONÁRIO DE AVALIAÇÃO DOS PROJETOS DA BASE
HISTÓRICA
Assunto 1 - Equipe
• Pergunta 1: Houve redução da equipe?
• Pergunta 2: Houve aumento da equipe?
• Pergunta 3: Houve troca de membros da equipe?
• Pergunta 4: Não houve troca de membros da equipe?
• Pergunta 5: Houve retrabalho provocado pela equipe?
• Pergunta 6: Não houve retrabalho provocado pela equipe?
• Pergunta 7: Os membros da equipe possuiam conhecimento do PDS?
• Pergunta 8: Os membros da equipe não possuiam o conhecimento do PDS?
• Pergunta 9: Os membros da equipe possuiam o conhecimento do negócio?
• Pergunta 10: Os membros da equipe não possuiam o conhecimento do negócio?
• Pergunta 11: Os membros da equipe possuiam conhecimento da tecnologia/arquitetura?
• Pergunta 12: Os membros da equipe não possuiam conhecimento da tecnologia/arquitetura?
• Pergunta 13: Houve membro(s) da equipe exercendo atividades fora do seu perl?
• Pergunta 14: Os membros da equipe exerceram atividades no seu perl?
• Pergunta 15: Houve problemas de comunicação entre os membros da equipe?
• Pergunta 16: Não houve problemas de comunicação entre os membros da equipe?
• Pergunta 17: Houve alocação de horas extras remuneradas?
• Pergunta 18: Houve alocação de horas extras sem remuneração (banco de horas)?
• Pergunta 19: Houve treinamento da equipe antes do projeto?
• Pergunta 20: Houve treinamento da equipe durante o projeto?
87
Assunto 2 - Requisitos
• Pergunta 20: Os requisitos foram complexos?
• Pergunta 21: Os requisitos foram simples?
• Pergunta 22: Os requisitos foram instáveis (mudança de escopo)?
• Pergunta 23: Os requisitos foram estáveis (sem mudança de escopo)?
• Pergunta 24: Os requisitos estavam incorretos?
• Pergunta 25: Os requisitos estavam bem documentados?
• Pergunta 26: Houve retrabalho provocado pela mudança de requisitos?
• Pergunta 27: Não houve retrabalho provocado pela mudança de requisitos?
• Pergunta 28: Houve reuso de requisitos?
Assunto 3 - Projeto
• Pergunta 29: Houve subalocação de horas trabalhadas?
• Pergunta 30: Houve superalocação de horas trabalhadas?
• Pergunta 31: Houve alocação correta das horas trabalhadas?
• Pergunta 32: Houve utilização de componentes do próprio projeto (reuso)?
• Pergunta 33: Houve utilização de componentes de outros projetos (reuso)?
• Pergunta 34: Houve utilização de protótipos?
• Pergunta 35: Houve integração com outras aplicações com a mesma tecnologia?
• Pergunta 36: Houve integração com outras aplicações com outra(s) tecnologia(s)?
• Pergunta 37: Houve retrabalho provocada por mudança de ambiente?
• Pergunta 38: Não houve retrabalho provocada por mudança de ambiente?
• Pergunta 39: Houve retrabalho provocado por mudança de tecnologia/arquitetura?
• Pergunta 40: Não houve retrabalho provocado por mudança de tecnologia/arquitetura?
88
Assunto 4 - Processo de Desenvolvimento de Software (PDS)
• Pergunta 41: Houve etapas do processo que foram puladas para cumprimento de
prazo?
• Pergunta 42: Todas as etapas do processo foram cumpridas?
• Pergunta 43: O PDS foi imaturo?
• Pergunta 44: O PDS foi maduro?
• Pergunta 45: O PDS foi burocrático?
• Pergunta 46: O PDS foi simplicado?
• Pergunta 47: O PDS não usou ferramental ou o ferramental foi deciente?
• Pergunta 48: O PDS possuia ferramentas?
• Pergunta 49: Não houve acompanhamento do projeto?
• Pergunta 50: O acompanhamento realizado foi sem utilizar métricas?
• Pergunta 51: O acompanhamento realizado foi utilizando métricas?
Assunto 5 - Usuário
• Pergunta 52: O usuário que especicou o requisito não tinha experiência no negócio?
• Pergunta 53: O usuário que especicou o requisito era experiente no negócio?
• Pergunta 54: O usuário que especicou o requisito não foi o mesmo que testou?
• Pergunta 55: O usuário que especicou o requisito foi o mesmo que testou?
• Pergunta 56: O usuário que especicou o requisitos não foi o mesmo que homologou?
• Pergunta 57: O usuário que especicou o requisitos foi o mesmo que homologou?
• Pergunta 58: Houve retrabalho provocado pelo usuário especicador?
• Pergunta 59: Não houve retrabalho provocado pelo usuário especicador?
Assunto 6 - Teste
89
• Pergunta 60: Os testes unitários foram realizados?
• Pergunta 61: Não foram realizados os testes unitários?
• Pergunta 62: Os testes funcionais foram realizados ao longo de todo ciclo de vida
do projeto (a partir da especicação de requisitos)?
• Pergunta 63: Os testes não funcionais foram realizados ao longo de todo ciclo de
vida do projeto (a partir da especicação de requisitos)?
• Pergunta 64: Os testes funcionais foram realizados somente ao nal do ciclo de vida
do projeto?
• Pergunta 65: Os testes não funcionais foram realizados somente ao nal do ciclo de
vida do projeto?
• Pergunta 66: Apenas parte das funcionalidades do projeto foram testadas?
• Pergunta 67: Todas as funcionalidades do projeto foram testadas?
• Pergunta 68: Os testes foram realizados por equipe especializada em testes (equipe
de testes)?
• Pergunta 69: Os testes foram feitos sem uso de ferramentas?
• Pergunta 70: Houve uso de ferramentas de automação de testes?
90
8.4 APÊNDICE 4 - CHECKLIST DO PMP
Parte 1 do Checklist (piora da PAP ou PFP em relação a PEI)
a) A equipe mudou?
b) A iteração sofreu acompanhamento?
c) Os usuários responsáveis pelos requisitos do projeto mudaram?
d) Houve retrabalho?
e) Foi usada ferramenta para suportar o PDS?
f) Foi utilizada ferramenta para os testes?
Parte 2 do Checklist (melhora da PAP ou PFP em relação a PEI)
a) Houve reuso de requisitos?
b) Não foi encontrado erro nos requisitos especicados?
c) Não houve subalocação de horas no projeto?
d) Não houve integração com outras aplicações?
e) Foi utilizada prototipação?
f) Foi utilizada métrica para o acompanhamento da iteração?
g) Os usuários especicadores dos requisitos conhecem bem os requisitos?
h) Não houve teste não-funcional a partir da especicação dos requisitos?
i) Não foram usados componentes de outras aplicações?
8.4.1 O CHECKLIST DO PMP
Todos os fatores presentes no checklist deste trabalho foram denidos através de referencial
bibliográco (SUDHAKAR, 2012) (WALT, 1995) e da submissão de um questionário
padrão para alguns projetos presentes em uma base de dados com informações de mais de
30.000 projetos de uma grande empresa de desenvolvimento de software público brasileira.
O questionário padrão utilizado neste estudo pode ser visto no Apêndice 3. A seleção da
91
amostragem dos projetos da base histórica foi baseada num combinação dos principais
tipos de PDS, porte e linguagem de programação da empresa avaliada. Os tipos de PDS
e linguagens de programação estão descritos no Apêndice 2 deste estudo, já o porte foi
avaliado pelo tamanho do projeto informado. Para projetos até 50 PFs são considerados
projetos de pequeno porte, de 51 PFs a 100 PFs são de médio porte e maiores de 100 PFs
de grande porte. Esta classicação de porte de projetos é utilizado pelo PDS padrão da
empresa avaliada.
O questionário não é um documento do PMP. A empresa que for adotar o PMP pode
usar o questionário como instrumento ou não de auxílio para a denição de seu próprio
checklist. Outras opções são: utilizar o checklist padrão denido por este estudo ou criar
outro checklist a partir apenas do estudo de sua base histórica de projetos.
Para este estudo as perguntas presentes no questionário serviram para preencher lacunas
na base histórica dos projetos e acrescentar questionamentos voltados a pontos mais subjetivos do PDS da empresa avaliada que não estão presentes na base histórica. As lacunas
que são complementadas pelo questionários são: 1) mudança de equipe (perguntas 1 a
4); 2) retrabalho (perguntas 5, 6, 26, 27, 37 a 40, 58 e 59); 3) treinamento da equipe
(perguntas de 7 a 12, 19 e 20); 4) perl da equipe (perguntas 13 e 14); 5) comunicação
da equipe (perguntas 15 e 16); 6) alocação de esforço da equipe (perguntas 17 e 18, 29 a
31); 7) complexidade dos requisitos (perguntas 20 e 21); 8) alteração dos requisitos (perguntas 22 e 23); 9) qualidade dos requisitos (perguntas 24 e 25); 10) reuso de requisitos
(pergunta 28); 11) componentização (perguntas 32 e 33); 12) prototipação (pergunta 34);
13) integração com outras aplicações (perguntas 35 e 36); 14) qualidade do PDS (perguntas 41 e 42); 15) maturidade do PDS (perguntas 43 a 51); 16) usuário especicador de
requisitos (perguntas 52 a 57); 17) testes funcionais (perguntas 60 a 62, 64); 18) testes
não funcionais (perguntas 63 e 65); 19) cobertura dos testes (perguntas 66 e 67) e 20)
qualidade do teste (perguntas 68 a 70).
8.4.2 DEFINIÇÃO E SUBMISSÃO DO QUESTIONÁRIO
No Apêndice 3 deste estudo é apresentado o modelo de questionário baseado em referencial
bibliográco em (SUDHAKAR, 2012) (WALT, 1995) e nos atributos encontrados na base
histórica dos projetos da empresa. Os atributos da base histórica da empresa também
estão no Apêndice 1. O questionário foi composto de 70 perguntas.
O questionário está dividido em seções que avaliam subgrupos que estão relacionados
92
diretamente com os possíveis impactos na PAP, são eles: equipe, requisitos, projeto, PDS,
usuário e teste. A denição destes subgrupos foi obtida através da pesquisa bibliográca
e experiência do autor do estudo em desenvolvimento de projetos.
Este questionário pode ser usado da mesma forma por uma outra empresa ou poderá ser
adaptado a sua realidade. O importante é que ele complemente informações já existentes
em sua base histórica, ou seja, atue conjuntamente com a base histórica de projetos como
fonte de geração das relações entre os fatores de impacto da PAP através de uma ferramenta de mineração de dados. Na ausência de uma base histórica o questionário precisará
ser mais abrangente para compensar a falta de informações históricas da empresa.
Foram selecionados da base histórica de projetos uma amostragem de 40 projetos representativos. O critério de seleção destes projetos foi: representatividade pelos tipos de PDS,
porte e linguagem de programação. Estes critérios estão descritos na subseção anterior
deste capítulo. Dos 40 questionários enviados 25 foram respondidos e 2 foram descartados
por respostas incoerentes.
O questionário deve possuir perguntas com intensão de capturar respostas incoerentes.
Isso permite que dados incorretos não afetem o resultado das associações encontradas pela
ferramenta de mineração de dados.
Para chegar ao checklist do PMP é preciso denir as regras de relação das variáveis
antecedentes e consequentes obtidas pela base histórica dos projetos da empresa e dos
questionários respondidos. Dessa forma é possível encontrar os fatores que impactam
em relação a melhora ou piora da PAP em relação a PEI de um PDS. Exemplicando,
a mudança de escopo pode ser uma variável antecedente para o impacto na variável
consequente produtividade (PAP) de um PDS. Para encontrar estas regras de relação foi
feito um estudo de mineração de dados usando o algoritmo APRIORI implementada na
ferramenta WEKA (WEKA, 2013).
As redundâncias introduzidas para ns de checagem de coerência no questionário foram
retiradas para não inuenciar os resultados do algoritmo. De todos os atributos da base
histórica dos projetos da empresa e questões presentes no questionário foram extraídas 41
variáveis que foram submetidas ao algoritmo APRIORI. As variáveis submetidas foram:
• Produtividade;
• Redução da equipe durante o projeto;
• Aumento da equipe durante o projeto;
93
• Troca de membros da equipe durante o projeto;
• Retrabalho provocado pela equipe do projeto;
• Alocação de horas extras remuneradas;
• Treinamento da equipe antes do projeto;
• Treinamento da equipe durante o projeto;
• Requisitos complexos;
• Requisitos simples;
• Requisitos instáveis;
• Requisitos incorretos;
• Requisitos bem documentados;
• Retrabalho provocado pela mudança de requisitos;
• Reuso de requisitos;
• Subalocação de horas trabalhadas;
• Superalocação de horas trabalhadas;
• Utilização de componentes do próprio projeto;
• Utilização de componentes de outros projetos;
• Uso de prototipação;
• Integração com outras aplicações com a mesma tecnologia;
• Integração com outras aplicações com outra(s) tecnologia(s);
• Não houve retrabalho provocado por mudança de ambiente;
• Não houve retrabalho provocado por mudança de tecnologia;
• Todas as etapas do PDS foram cumpridas;
• PDS maduro;
94
• PDS burocrático;
• Uso de ferramentas para apoio ao processo;
• Não houve acompanhamento do projeto;
• Usuário que especicou o requisito é experiente no negócio;
• Usuário que especicou o requisito foi o mesmo que testou o projeto;
• Usuário que especicou o requisito foi o mesmo que homologou o projeto;
• Retrabalho provocado pelo usuário especicador;
• Testes unitários não foram realizados;
• Testes funcionais realizados ao longo de todo o ciclo de vida do projeto;
• Testes não funcionais realizados ao longo de todo o ciclo de vida do projeto;
• Testes funcionais realizados somente ao nal do ciclo de vida do projeto;
• Testes não funcionais realizados somente ao nal do ciclo de vida do projeto;
• Todas as funcionalidades do projeto foram testadas;
• Testes realizados por equipe especializada em testes;
• Testes sem uso de ferramentas.
A próxima subseção descreve os fatores de maior impacto da PAP neste estudo. O importante para o PMP é que os projetos selecionados sejam signicativos dentro do universo da
base histórica e que os dados presentes nestes projetos estejam corretamente preenchidos.
8.4.3 FATORES QUE IMPACTAM A PAP E O CHECKLIST DO PMP
O checklist é dividido em duas partes: a primeira diz respeito a perguntas para o caso da
PAP ter sido pior que a PEI e a segunda quando a PAP foi melhor que a PEI do projeto.
Para chegar as perguntas do checklist foi feita uma análise de regras de associação das
variáveis, através do algoritmo APRIORI.
Este algoritmo faz buscas na base de dados submetida a avaliação à procura dos conjuntos frequentes (conjuntos que satisfazem um suporte mínimo estabelecido). Ao nal ele
95
dene as regras de associação existentes entre as variáveis antecedentes e consequentes
(AGRAWAL, 1996).
Para este estudo a variável consequente se restringe a produtividade, se esta aumentou
ou piorou durante o projeto. As variáveis antecedentes foram extraídas do questionário e
dos atributos da base histórica dos projetos, já descritos na subseção anterior. A gura
7.1 apresenta os parâmetros que foram utilizados para a geração das regras de associação
na ferramenta WEKA.
FIG. 8.1: Tela de Parâmetros do algoritmo APRIORI do WEKA
Com as regras de associação obtidas da ferramenta é possível denir os fatores que impactam a PAP para melhor ou para pior. Baseado nessas regras foi denido o checklist do
PMP. Nem todos os atributos da base histórica e questões do questionário surgiram como
fatores de impacto para o PAP do PMP, pois não apresentaram regras de associação geradas pelo algoritmo APRIORI ou apresentaram regras de associação com conabilidade
inferior a 1. A conabilidade de uma regra representa o quanto ela é signicativa dentro
da base de dados que foi submetida ao algoritomo APRIORI.
96
Como resultado das regras do algoritmo APRIORI os seguintes fatores foram considerados
determinantes para a piora da produtividade na empresa avaliada: mudança da equipe,
falta de acompanhamento do projeto, mudança do usuário especicar de requisitos do
projeto, retrabalho, o não uso de ferramental para o apoio ao PDS do projeto e o não uso
de ferramenta para os testes.
Já os fatores que melhoram a produtividade dos projetos avaliados da empresa são: reuso
de requisitos, ausência de erros na especicação dos requisitos da iteração, a não subalocação das horas de esforço por parte da equipe, baixa integração com outras aplicações,
uso de prototipação, uso de métrica para acompanhamento do projeto, os usuário especicadores de requisitos conhecem muito bem o domínio do negócio que estão especicando,
ausência de teste não funcional a partir da especicação dos requisitos, não uso de componentes de outras aplicações.
Com o resultado do checklist e o RAP o gerente de projeto já tem insumos sucientes
para determinar se deve ou não tomar ações de ajuste no PDS do projeto. A atividade
seguinte descreve como o gerente de projeto deve denir o RAA do PMP.
Abaixo segue o checklist (parte 1) respondido da primeira iteração do projeto exemplo
apresentado no Capítulo 3 deste estudo.
a) A equipe mudou? Não.
b) A iteração sofreu acompanhamento? Sim.
c) Os usuários responsáveis pelos requisitos do projeto mudaram? Não.
d) Houve retrabalho? Sim.
Diagnóstico: O aumento do tamanho foi provocado pelo retrabalho de dois casos de
uso (uma Entrada Externa simples de 3 PFs que faz parte do Caso de Uso 1) e todo
o Caso de Uso 4 (3 PFs). O tamanho inicial estimada para a primeira iteração foi
de 44 PFs e passou para 50 PFs ao nal da mesma.
e) Foi usada ferramenta para suportar o PDS? Sim.
f) Foi utilizada ferramenta para os testes? Não.
Diagnóstico: A ausência de uma ferramenta para os testes fez com que parte da
equipe responsável pelos testes apropriasse mais horas de esforço para realizar suas
atividades do que o previsto pelo PDS.
97
Ao responder este checklist o gerente de projeto pode denir ações que deve adotar para as
próximas iterações, evitando problemas com o custo e prazo do projeto. Se for a última
iteração do projeto o gerente de projeto pode denir as lições aprendidas para serem
aplicadas aos próximos projetos.
98
8.5 APÊNDICE 5 - MODELO DE RAA DO PMP
Seção 1: Informações Gerais
Data do Relatório:
Nome do Gerente do Projeto:
Identicação do Projeto:
Número da Iteração:
A PAP acumulada (ou PFP) em relação a PEI: ( ) melhorou ( ) piorou
Seção 2: Itens Impactados do Checklist do PMP (para cada item deve haver a sua descrição
e diagnóstico do impacto)
2.1.1) Descrição:
2.1.2) Diagnóstico:
2.2.1) Descrição:
2.2.2) Diagnóstico:
2.3.1) Descrição:
2.3.2) Diagnóstico:
Seção 3: Ações a serem tomadas para a próxima Iteração do PDS ou Lições Aprendidas
99