Mestrado - Um Guia para Estimativa de Projetos de Spftware em Micro e Pequenas Empresas

MARLISE THERE DIAS
UM GUIA PARA ESTIMATIVAS DE PROJETOS DE SOFTWARE

EM MICRO E PEQUENAS EMPRESAS
So Jos (SC), maro de 2009.
UNIVERSIDADE DO VALE DO ITAJA

CURSO DE MESTRADO ACADMICO EM
COMPUTAO APLICADA

por
MARLISE THERE DIAS
Dissertao apresentada como requisito parcial

obteno do grau de Mestre em Computao
Aplicada.
Orientadora:
Christiane
Gresse
von
Wangenheim, Dr. rer. nat
So Jos (SC), maro de 2009.
Dedico este trabalho a meu marido e meu filho, a minha famlia, aos amigos de verdade e a todos
aqueles a quem este trabalho possa ser til.
iii
Voc no sabe o quanto eu caminhei, pra chegar at aqui, percorri milhas e milhas antes de
dormir, eu no cochilei... (Toni Garrido)
iv
AGRADECIMENTOS
Agradeo a Deus que me permitiu a vida e a quem recorri nos momentos de desnimo.
Agradeo a toda minha famlia que sempre me apoiou. Em especial ao meu marido
Alexandre, meu Filho Pedro Henrique que se furtaram de minha presena nos momentos de estudo.
A meu pai e minha por me auxiliarem nos cuidados com meu filho e apoio para a finalizao da
dissertao. Agradeo tambm aos meus irmos e cunhadas pelo sempre apoio.
Agradeo ao professor Marcello Thiry pelo auxlio nas atividades iniciais para o ingresso ao
mestrado, durante o curso deste e tambm na presena da banca desta dissertao. Agradeo a
professora Christiane Gresse von Wangenheim, que com sua competncia e pacincia soube me
conduzir ao final deste trabalho. Agradeo aos professores Anita Maria da Rocha Fernandes,
Adhemar Maria do Valle Filho e Clenio Figueiredo Salviano pelas contribuies na banca. A todos
os professores do mestrado com os quais convivi durante estes 2 anos o meu muito obrigada.
Agradeo a todos os amigos que direta ou indiretamente contribuiriam para que eu chegasse
ao fim desta jornada especialmente a Lu que sempre me incentivou nas horas em que tive vontade
de desistir e pela ajuda durante as vrias fases da criao da dissertao; a Fe e Alessandro pela
compreenso no desempenho de atividades em comum; a Anita pelas conversas encorajadouras;
Maiara pelas trocas nos momentos de desespero; e as amigas J e Manu que mesmo distante sempre
me cobravam em forma de incentivo a defesa da dissertao. Amo todos vocs.
Agradeo tambm aos colegas Maiara, Richard, Jean, Gisele e Alecir que participaram da
avaliao do guia foco desta pesquisa, atividade crucial para a finalizao do trabalho. Ao Mauricio
Fiorese da empresa JExperts pela ateno em apresentar a ferramenta JExpChannel para este
trabalho. Tambm a professora e colega Elisa Coral pela colaborao na fase final desta dissertao.
Agradeo a UNIVALI por proporcionar este mestrado e tambm pela bolsa parcial recebida
para auxiliar nos custeios deste programa. Estendo aqui meus agradecimentos ao professor Cesar
Albenes Zeferino coordenador do mestrado pela ateno dispensada e a Maria de Lurdes Rodrigues
dos Santos secretria do programa de mestrado pelo carinho que sempre me atendeu.
Enfim, agradeo a todos que direta ou indiretamente contriburam para a realizao deste
trabalho.

Marlise There Dias
03/2009
Orientador(a): Christiane Gresse von Wangenheim, Dr. rer. nat

rea de Concentrao: Engenharia de Software
Palavras-chave: Gerenciamento de projetos, Planejamento. Estimativa.
Nmero de pginas: 167
RESUMO
A atividade de estimativa possui diferentes modelos/tcnicas para execut-la e tarefa exigida na

adoo de modelos de melhoria de processo de software e guias de gerenciamento de projetos. No
entanto, percebe-se que h por parte das micro e pequenas empresas (MPEs) de software
dificuldades em aplicar tais modelos/tcnicas de estimativa e tambm os modelos de melhoria de
processo de software. Desta forma, este trabalho apresenta o desenvolvimento de um guia de
estimativa de esforo e durao de atividades e tamanho de projeto para micro e pequenas em
empresas de software alinhado aos modelos de melhoria de processo CMMI-DEV, MPS.BR e
ISO/IEC 15504 e ao PMBOK como referncia gerncia de projetos. A pesquisa caracteriza-se por
ser aplicada e descritiva, utilizando-se como forma de coleta de dados para a criao do guia
levantamento bibliogrfico e documental. Para tanto, pesquisou-se as caractersticas das MPEs de
software, aspectos tericos dos modelos de melhoria de processo de software e do guia PMBOK e
os principais modelos/tcnicas de estimativas. A avaliao do guia utilizou-se do mtodo GQM com
profissionais de Engenharia de Software. O guia desenvolvido possui em sua estrutura aspectos
tericos sobre gerenciamento de projetos, planejamento e estimativas de software, alm da
apresentao dos modelos de melhoria de processo e guia PMBOK; descreve um processo genrico
para a atividade de estimativa; detalha os modelos/tcnicas de estimativas selecionados e templates
e exemplos para estes; ferramentas voltadas rea; e ainda uma tabela de conformidade entre o guia
e os modelos de melhoria de processo citados e o guia de gerncia de projetos. A avaliao do guia
demonstrou uma primeira indicao de que vivel sua aplicao em MPEs de software por
apresentar contedo relevante e adequado sobre o tema.
vi
A GUIDE TO SOFTWARE PROJECT ESTIMATES IN MICRO

AND SMALL COMPANIES
Marlise There Dias
03/2009
Adviser: Christiane Gresse von Wangenheim, Dr. rer. nat

Concentration area: Software Engineering
Key-words: Project management, planning, estimates
Number of pages: 167
ABSTRACT
The estimate activity has different models/techniques to be executed and it is a required task in
adoption of software process improvement and project management guidelines. However, it can be
noticed that micro and small software companies have some difficulties to apply such estimate
models/techniques and also software process improvement models. Thus, this work presents the
development of a guide to estimate activity effort and duration and also project size to software
micro and small companies. The guide is aligned to process improvement models CMMI-DEV,
MPS.BR e ISO/IEC 15504 and to PMBOK as a reference to project management. The research is
characterized as being applied and descriptive, using collection of data to guide the creation of
bibliographic and documentary guide. For this, characteristics of Software MPEs were researched,
as well as theoretical aspects of software improvement models, PMBOK guide and main estimates
models/techniques. The assessment guide used the GQM method with Software Engineering
professionals. The guide presents theoretical aspects about project management, planning and
software estimates, process improvement models and PMBOK guide; It describes a generic process
to the estimate activities, detailing selected estimate models/techniques, templates and examples for
those. It also presents specific tools to the area and a conformity table comparing the guide and the
process improvement models cited and the project management guide.
The guide evaluation showed a first indication that it is viable its application in Software Micro and
Small Businesses for presenting relevant and adequate content about the theme.
Keywords: Management projects. Planning. Estimative.
vii
LISTA DE FIGURAS
Figura 1 - Metodologia de criao e aplicao do guia ..................................................................... 24

Figura 2 - Atividades do planejamento de projetos ........................................................................... 29
Figura 3 Processo de estimativa genrico ....................................................................................... 35
Figura 4 - Estimativas no Planning Poker .......................................................................................... 61
Figura 5 reas de conhecimento e processos de gerenciamento de projetos ................................. 65
Figura 6 - Componentes do grupo de Planejamento .......................................................................... 67
Figura 7 Componentes do modelo CMMI ...................................................................................... 75
Figura 8 Componentes do MPS.BR ................................................................................................ 81
Figura 9 Componentes da ISO/IEC 15504 ..................................................................................... 86
Figura 10 - Estrutura de desenvolvimento do guia .......................................................................... 112
Figura 11 - Estrutura do Guia em captulos ..................................................................................... 113
Figura 12 - Processo genrico para estimar ..................................................................................... 115
Figura 13 - Template para execuo da tcnica Pert. ...................................................................... 122
Figura 14 - Template PERT: calculo das estimativas O, M, P......................................................... 124
Figura 15 - Template Pert: Clculo da durao esperada................................................................. 124
Figura 16 - Template PERT: clculo do desvio padro ................................................................... 125
viii
LISTA DE GRFICOS
Grfico 1 - Porte das empresas considerando a fora efetiva de trabalho ......................................... 93
Grfico 2 - Utilizao de estimativas por empresas de software ....................................................... 97
Grfico 3 Variao do esforo para aplicar o guia........................................................................ 142
Grfico 4 Indicativo percentual sugerido de base no PMBOK ..................................................... 149
Grfico 5 Comparativo do percentual de alinhamento aos modelos de melhoria de processo ..... 151
ix
LISTA DE QUADROS
Quadro 1- Relao de atividades dos passos referentes ao planejamento de projetos ....................... 30

Quadro 2 - Pesos dos componentes de acordo com as complexidades .............................................. 43
Quadro 3 - Graus de influncia das caractersticas de sistema da APF ............................................. 44
Quadro 4 - SLOC por pontos de funo ............................................................................................ 46
Quadro 5 - Relao nmero de transies e pesos de caso de uso..................................................... 51
Quadro 6 - Relao nmero de transies e pesos de caso de uso..................................................... 51
Quadro 7 - Fatores tcnicos de complexidade ................................................................................... 52
Quadro 8 - Fatores ambientais ........................................................................................................... 53
Quadro 9 - Grau de influncia dos fatores ......................................................................................... 53
Quadro 10 - Obteno de produtividade ............................................................................................ 57
Quadro 11 - Direcionadores de clculo.............................................................................................. 58
Quadro 12 - Nveis das representaes em estgio e contnua .......................................................... 76
Quadro 13 - Nveis de maturidade do processo de gerenciamento de projetos MPS.BR .................. 82
Quadro 14 - Nveis de capacidade ISO/IEC Std. 15504 .................................................................... 87
Quadro 15 - Relao CMMI-DEV / MPS.BR / ISO/IEC 15504-5 .................................................... 91
Quadro 16 - Classificao das MPEs quanto ao porte ....................................................................... 93
Quadro 17 - Comparao entre os guias pesquisados e os requisitos do guia proposto .................. 109
Quadro 18 - Relao ferramentas e requisitos ................................................................................. 128
Quadro 19 - Relao ferramentas e modelos/tcnicas suportados. .................................................. 129
Quadro 20 - Alinhamento com o PMBOK ...................................................................................... 130
Quadro 21 - Alinhamento CMMI-DEV, MPS.BR, ISO/IEC 15504 e o guia de estimativa............ 132
Quadro 22 - Perguntas GQM e mtricas .......................................................................................... 137
Quadro 23 - Resumo dos procedimentos de coleta de dados ........................................................... 139
LISTA DE TABELAS
Tabela 1- Exemplo de dados de projetos ........................................................................................... 38

Tabela 2 - Setores de atividades MPEs (2000 - 2004) ....................................................................... 92
Tabela 3 - Dados pesquisa gerenciamento de projetos (GP) ............................................................. 95
Tabela 4 - Utilizao dos modelos de melhoria de processo em MPEs ............................................ 96
xi
LISTA DE EQUAES
Equao 1 - Forma modelos paramtricos ......................................................................................... 37

Equao 2 - Distncia Euclidiana ...................................................................................................... 38
Equao 3 - Frmula PERT ............................................................................................................... 40
Equao 4 - Frmula Desvio Padro.................................................................................................. 40
Equao 5 - Clculo do ponto de funo no ajustado ...................................................................... 43
Equao 6 - Valor do fator de ajuste .................................................................................................. 45
Equao 7 - Ponto de funo ajustado ............................................................................................... 45
Equao 8 - Clculo do esforo ......................................................................................................... 47
Equao 9 - Clculo do esforo ......................................................................................................... 47
Equao 10 - Total no ajustado de atores (unadjusted actor weights - UAW) ................................ 50
Equao 11 - Clculo do total no ajustado de caso de uso ............................................................... 51
Equao 12 - Clculo do total no ajustado de caso de uso ............................................................... 52
Equao 13 - Calculo do FatorT ........................................................................................................ 53
Equao 14 - Clculo do TCF ............................................................................................................ 53
Equao 15 - Calculo do EFactor ...................................................................................................... 54
Equao 16 - Clculo do EF .............................................................................................................. 54
Equao 17 - Clculo do FA .............................................................................................................. 54
Equao 18 - Clculo do esforo (Pessoa/ms) ................................................................................. 57
Equao 19 - Frmula-padro para modelos algoritmos ................................................................... 58
Equao 20 - Clculo do conjunto simplificado de direcionadores de processo ............................... 58
Equao 21 - Clculo do esforo (pessoa-ms) ................................................................................. 58
Equao 22 - Frmula para estimar prazo ......................................................................................... 59
Equao 23 - Clculo do F ................................................................................................................. 59
Equao 24- Frmula PERT ............................................................................................................ 121
Equao 25 - Frmula desvio padro ............................................................................................... 121
xii
LISTA DE ABREVIATURAS E SIGLAS

BFPUG
CASE
CMMI
COCOMO
COSMIC-FPP
EAP
FP
FPA
GQM
IFPUG
ISO/IEC
LQPS
MCT
MPEs
MPS.BR
NESMA
PERT
PMI
QSM
SEBRAE
SEI
SLOC
SOFTEX
UML
UNIVALI
UKSMA
Brazilian Function Point Users Group

Capability Maturity Model Integration
Constructive Cost Model
Common Software Measurement International Consortium Full
Function Points
Estrutura Analtica do Projeto
Function Points
Function Points Analyse
Goal Question Metric
International Function Point Users Group
International Organization for Standardization/ International
Electrotechnical Commission
Laboratrio de Qualidade e Produtividade de Software
Ministrio da Cincia e Tecnologia
Micro e Pequenas Empresas
Melhoria de Processo do Software Brasileiro
Netherlands Software Metrics Association
Program evaluation and Review Technique
Project Management Institute
Quantitative Software Management
Servio Brasileiro de Apoio s Micro e Pequenas Empresas
Software Engineering Institute
S Line of code
Associao para Promoo da Excelncia do Software Brasileiro
Unified Modeling Language
Universidade do Vale do Itaja
United Kingdom Software Metrics Association
xiii
SUMRIO
1
INTRODUO ........................................................................................................................ 16
1.1 MOTIVAO .......................................................................................................................... 18

1.2 OBJETIVOS ............................................................................................................................. 21
1.2.1 Objetivo Geral .................................................................................................................... 21
1.2.2 Objetivos Especficos ......................................................................................................... 21
1.3 METODOLOGIA .................................................................................................................... 22
1.3.1 Metodologia da Pesquisa ................................................................................................... 22
1.3.2 Metodologia da Aplicao ................................................................................................. 23
1.4 ORGANIZAO DO DOCUMENTO .................................................................................. 25
2
FUNDAMENTAO TERICA .......................................................................................... 26
2.1 GERNCIA DE PROJETOS ................................................................................................. 26

2.2 PLANEJAMENTO .................................................................................................................. 27
2.2.1 Estimativas de software ..................................................................................................... 32
2.2.1.1 Tipos de Estimativas .................................................................................................. 36
2.2.1.2 Modelos/Tcnicas para Estimativas de Software....................................................... 37
2.3 PMBOK UM GUIA DO CONJUNTO DE CONHECIMENTOS EM
GERENCIAMENTO DE PROJETOS .......................................................................................... 63
2.4 MODELOS DE MELHORIA DE PROCESSO DE SOFTWARE ..................................... 73
2.4.1 CMMI................................................................................................................................. 73
2.4.2 MPS.BR ............................................................................................................................. 80
2.4.3 Norma ISO/IEC 15504....................................................................................................... 86
2.4.4 Consideraes sobre os modelos........................................................................................ 90
3
CONTEXTUALIZAO DO TRABALHO: MICRO E PEQUENAS EMPRESAS ....... 92
3.1 MPES DE SOFTWARE BRASILEIRAS .............................................................................. 92

3.2 CARACTERSTICAS DE MPES DE SOFTWARE ............................................................ 94
4
ESTADO DA ARTE E DA PRTICA ................................................................................... 99
4.1 DISCUSSO DOS GUIAS PESQUISADOS....................................................................... 109

5
DESENVOLVIMENTO DO GUIA ...................................................................................... 111
5.1 DESCRIO .......................................................................................................................... 111
xiv
5.2 PROCESSO GENRICO ..................................................................................................... 115

5.3 MODELOS E TCNICAS DE ESTIMATIVAS ................................................................ 119
5.4 TEMPLATES .......................................................................................................................... 121
5.5 EXEMPLOS ........................................................................................................................... 122
5.6 FERRAMENTAS ................................................................................................................... 125
5.6.1 Consideraes sobre as ferramentas ................................................................................ 128
5.7 AVALIAO DE CONFORMIDADE ............................................................................... 130
6
AVALIAO DO GUIA....................................................................................................... 135
6.1 PLANEJAMENTO DA AVALIAO ................................................................................ 135

6.2 EXECUO ........................................................................................................................... 140
6.3 ANLISE DOS DADOS COLETADOS ............................................................................. 141
6.4 AMEAAS A VALIDADE ................................................................................................... 152
7
CONCLUSES ...................................................................................................................... 154
7.1 RECOMENDAES E TRABALHOS FUTUROS .......................................................... 156

REFERNCIAS BIBLIOGRFICAS ......................................................................................... 157
APNDICES................................................................................................................................... 161
xv
1 INTRODUO
De acordo com Drucker (1989), as empresas so impulsionadas a investir para se manterem
num mercado complexo e dinmico, independente de seu porte. Atualmente, com os investimentos
das organizaes em softwares que facilitem o desenvolvimento de suas atividades h uma
preocupao das empresas de software em atender bem aos clientes e para isso buscam uma
estrutura que lhes permita fornecer a estes, produtos de qualidade de acordo com suas necessidades
(MIT, 2002).
Neste contexto, encontram-se as micro e pequenas empresas de software (MPEs), que de
acordo com MCT (2002) esto em torno de 70% no Brasil, se utilizado o critrio de fora de
trabalho, ou seja, nmero de funcionrios para definir o porte destas. Conforme SEBRAE (2004)
empresas com at 9 funcionrios considera-se micro empresa e de 10 a 49 empregados pequena
empresa. Estas, perante o aumento de demanda de mercado, necessitam adotar estratgias que
possibilitem seu crescimento e desenvolvimento com qualidade (UEHARA, 2003). Isto implica no
fornecimento e produo de software ou servio com qualidade e produtividade.
No entanto, percebe-se em pesquisa do Standish Group (1994) que 31,1% dos projetos so
cancelados antes de serem finalizados e 52,7% ultrapassam o custo estimado; apenas 16,2 dos
projetos so concludos no tempo e com o oramento previsto. Uma pesquisa mais recente do
Standish Group (2004) afirma que 27% dos projetos so finalizados dentro do tempo e com o custo
previsto, que 40% dos projetos so cancelados antes de terminarem e que 50% dos projetos em
mdia custam 180% a mais do que foi estimado inicialmente. Pode-se perceber que houve uma
melhora no que se refere aos projetos com sucesso de 16% para 27%, porm este nmero ainda
preocupante visto que no equivale nem a metade dos projetos. Ainda em trabalho mais recente
Charette (2005) afirma que de 5% a 15% dos projetos na rea de Tecnologia da Informao so
abandonados antes ou logo aps o seu incio; outros sero modificados em funcionalidade e
oramento at o final, e poucos sero completados com sucesso.
Charette (2005) ressalta ainda que quando um projeto falha pode por em risco a
sobrevivncia da empresa. Nas MPEs este fator ainda mais relevante, pois iniciam suas atividades
com um capital baixo e trabalham sempre no limite. De acordo com o SEBRAE (2004) 49,4% das
MPEs de vrios setores no Brasil at 2002, tiveram um tempo mximo de vida de 2 anos e as
principais causas foram falta de capital de giro e problemas financeiros, o que confirma uma
possvel mortalidade da empresa no caso de um projeto com insucesso, considerando o
investimento inicial das MPEs. Outro fator de mortalidade ressaltado foi a forte concorrncia.
No contexto das MPEs de software, para manter-se no mercado e crescer, estas necessitam
de solues em engenharia de software efetivas (RICHARDSON e WANGENHEIM, 2007). No
entanto, de acordo com pesquisa realizada pelo MCT (2005), as MPEs em sua maioria dependem
demais de seus recursos humanos, pois se utilizam de um processo de desenvolvimento de software
informal. Em sua grande maioria acreditam que modelos de referencias e padres/normas
despenderiam recursos e tempo demais, sendo muito difceis de serem aplicadas (RICHARDSON e
WANGENHEIM, 2007). Desta forma, para que se mantenham competitivas no mercado uma
soluo s MPEs o investimento na melhoria de sua qualidade e produtividade, que pode ser
visualizada em seu produto final (WEBER; HAUCK; WANGENHEIM. 2005).
Tipicamente, o desenvolvimento de um software ou servio considerado um projeto, sendo
este um esforo temporrio para criao de um produto ou servio nico (PMI, 2004). No entanto,
torna-se necessrio o planejamento e acompanhamento deste projeto para que se obtenha o produto
esperado. Sendo assim, a adoo de um modelo de gerenciamento de projetos de software pode
possibilitar as MPEs qualidade e produtividade no processo de criao e obteno de um produto
final. De acordo com Jalote (2002), entre as causas mais comuns para o insucesso em projetos est a
falta de uma metodologia de gerncia de projeto, justificando a carncia das empresas de software
na adoo destas.
De acordo com PMI (2004), o gerenciamento de projetos a aplicao de conhecimento,
habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O
objetivo do gerenciamento de projetos entregar ao cliente um produto/servio de qualidade que
est dentro do escopo, do tempo e do oramento determinados no planejamento do projeto (PMI,
2004).
Neste sentido, este projeto trata de uma das reas relacionadas ao gerenciamento de projetos,
considerada crucial para obteno de um desenvolvimento de software adequado, o planejamento.
Nesta atividade seus vrios processos e interaes definiro um plano para que o projeto possa ser
gerenciado (PMI, 2004). Wysocki e McGary (2003) afirmam que o planejamento de projeto
indispensvel, alm de apresentar a maneira como o trabalho deve ser desenvolvido, torna-se uma
17
ferramenta para tomada de deciso. O planejamento do projeto fornece informaes para o

desenvolvimento e controle das atividades do projeto (SEI, 2006).
Entre as atividades do planejamento de projeto, uma das reas que apresenta maior
dificuldade e complexidade e que ser o foco deste trabalho a de estimativa em projetos de
software. De acordo com Harman (1998), na maior parte das vezes h uma subestimao em
projetos, por isso considera a estimativa atividade crucial em qualquer projeto mesmo o que parece
ser o mais simples. Em um projeto com estimativas pobres existe a possibilidade das organizaes
desenvolvedoras e os patrocinadores tomarem decises baseadas em informaes sem grande
confiabilidade (THOMSETT, 2002).
Conforme PMI (2004), um projeto envolve estimativas de parmetros de projetos como
tamanho do produto e atributos durao e esforo de atividades e do projeto. Esta primeira
estimativa determinante para a previso das demais e avaliada considerando o cdigo do
software ou funcionalidades deste (SOMERVILLE, 2004)
A estimativa da durao de atividades define o nmero de perodos de trabalho (por
exemplo, em horas ou semanas) necessrio para execuo de cada tarefa destacada no cronograma.
(PMI, 2004). Esforo refere-se h quanto tempo (por exemplo, podendo ser medidas em
pessoa/hora, pessoa/ms) cada pessoa envolvida no projeto levar para executar cada atividade
definida no planejamento.
Atualmente vrias tcnicas so utilizadas para realizar estimativas no domnio de software,
incluindo Pontos por Funo FP (ALBRECHT, 1981), anlise por ponto de casos de uso
(KARNER, 1993), estimativa baseada na experincia do especialista, com base em dados histricos,
mtodos como Modelo construtivo de custo COCOMO (BOEHM, 1981) e Wideband delphi
(BOEHM, 1981) entre outros.
1.1 MOTIVAO
Percebe-se conforme Standish Group (1994), que entre as principais caractersticas
apontadas de falhas em projetos de software est a superao do custo e do tempo. A primeira
apresenta 214% (em pequenas empresas) acima da estimativa inicial e a segunda em 239% (em
pequenas empresas). Estes dados confirmam que a aplicao das tcnicas existentes no est
trazendo o resultado esperado. Torna-se relevante verificar que este fato pode ocorrer pela falta de
18
adoo das tcnicas/modelos existentes e/ou por estes no serem direcionados as MPEs e por este
motivo no estarem sendo adotados.
Aliado a isto, as micro e pequenas empresas apresentam dificuldades na aplicao nos
modelos e normas de melhoria de processo de software existentes (PMI, 2007a). Um dos fatores o
fato de modelos como o CMMI-DEV (SEI, 2006) e a norma ISO/IEC 15504-5 (ISO/IEC Std.
15504, 2005), terem sido direcionados principalmente para grandes empresas. Outro ponto que
estes modelos no foram desenvolvidos com intuito de apresentar descries ou definies da
melhor forma de realizar estimativa e de quais tcnicas seriam interessantes dependendo da
organizao (SEI, 2006; ISO/IEC 15504-5, 2005; SOFTEX, 2007). Esta caracterstica tambm
observada no MPS.BR (SOFTEX, 2007), modelo brasileiro criado objetivando pequenas e mdias
empresas, mesmo apresentando um guia de implementao no tem como objeto o detalhamento
das atividades relacionadas a estimativa de software.. Desta forma, modelos e normas se tornam, na
viso das MPEs demorados, caros e difceis de serem implantados segundo Johnson e Brodman
(1997), no que se refere ao CMM para pequenas organizaes. A falta de modelos especficos para
este tipo de empresa pode levar a no adoo de uma metodologia para a gesto de seus projetos
(JOHNSON e BRODMAN, 1997).
Desta forma, este trabalho est direcionado para suportar o processo de estimativa de
projetos de software alinhando aos modelos para gerenciamento de projetos e a modelos e normas
de qualidade existentes.
Pergunta de pesquisa
Desta forma, esta pesquisa pretende responder a seguinte questo:
A utilizao de um guia de estimativas contribui, em termos de facilidade e eficincia, para
definio de um processo de estimativa de projetos (tamanho de software, durao e esforo de
durao) em MPEs de software, de forma a orientar na implementao desta atividade alinhada a
modelos de melhoria de processo de software?
19
Proposta de soluo
Este trabalho prope a criao de um guia para estimativas de parmetros de projeto,
envolvendo esforo e durao de atividades; e atributos de produtos de trabalho como tamanho,
aplicado s MPEs de Software.
Pretende-se com base nos mtodos e tcnicas de estimativas existentes apresentar opes
que estejam adequadas e alinhadas as caractersticas de uma MPE. Tambm ser considerado como
base para este trabalho o guia de gerncia de projetos PMBOK (PMI, 2004), alm de modelos e
normas de qualidade e produtividade de software como CMMI-DEV (SEI, 2006), a norma ISO/IEC
15504 (ISO/IEC Std. 15504, 2005) e o MPS.BR (SOFTEX, 2007).
Justificativa
Pretende-se atravs da existncia e utilizao de um guia para estimativas voltado para o
contexto de MPEs de software, facilitar a tarefa de realizar estimativas em MPEs, fazendo com que
estas tenham projetos mais viveis e por conseqncia tornando a execuo destes mais precisos.
Isto pode aumentar a competitividade e o sucesso das MPEs e conseqentemente ser uma possvel
contribuio para evitar a mortalidade to precoce de tantas empresas deste porte. Alm disso,
poder favorecer ao aumento de preciso no processo de estimar em micro e pequenas empresas de
software, reduzindo, por exemplo, o tempo/esforo que os responsveis necessitam para estimar.
Este guia servir como orientao aos consultores que realizam a implantao de programas
de melhoria de processo baseado em modelos ou normas de qualidade e produtividade de software
em MPEs, para a escolha de tcnicas de estimativas que possam ser utilizadas pela empresa e
permitam o alinhamento aos modelos. Cabe salientar, que a atividade de estimar um processo
dentre os vrios que devem estar adequados aos modelos e normas para a obteno de avaliao
pelas empresas, assim a utilizao do guia poder contribuir tambm na obteno de avaliaes
oficiais das MPEs no que se refere a padronizao do processo de estimar.
Outro fator que pode ser considerado em relao ao uso do guia que por estar alinhado a
modelos internacionalmente reconhecidos, ele pode contribuir indiretamente para a insero destas
empresas no mercado exterior. De acordo com SOFTEX (2005), em pesquisa realizada com 30
empresas com valores significativos de exportao, quatorze empresas brasileiras que exportavam
software eram de pequeno e mdio porte. Entre as barreiras citadas para exportao de software
20
encontra-se a falta de certificaes de qualidade e tcnicas. Alm disso, o relatrio cita como fatores
crticos para competitividade no exterior a qualidade de produtos, pontualidade, preo de venda e
custo de produo. Logo, percebe-se que a proposta apresentada pode tambm auxiliar as MPEs na
busca de um mercado fora do pas, pois os recursos e o tempo estimados fazem parte dos aspectos
apontados que comprometem a competitividade no mercado externo.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Estabelecer um guia para estimativa de esforo e durao de atividades e tamanho do
produto de trabalho para micro e pequenas empresas de software alinhado aos modelos de melhoria
de processo CMMI-DEV, ISO/IEC 15504 e MPS.BR e ao PMBOK como referncia a gerncia de
projetos.
1.2.2 Objetivos Especficos
OE1. Identificar as caractersticas das MPEs e de seus processos de software, em

particular no cenrio nacional a partir da literatura, enfocando estimativa.
OE2. Analisar os requisitos referentes ao processo de estimar da rea de processo de

planejamento de projeto no PMBOK e nos principais modelos de melhoria de processo
CMMI-DEV, MPS.BR e ISO/IEC 15504.
OE3.
Analisar
modelos/tcnicas
existentes
para
estimativas
relacionadas
caractersticas de MPEs identificadas.
OE4. Analisar ferramentas existentes na rea de estimativas relacionadas s

caractersticas de MPEs identificadas.
OE5. Estabelecer diretrizes para a seleo dos modelos/tcnicas e ferramentas do guia.
OE6. Desenvolver o guia com base em modelos/tcnicas e ferramentas existentes na rea

de estimativas de projeto de software.
21
OE7. Avaliar o guia por meio de experincias prticas de profissionais certificados em

modelos de melhoria de processo.
1.3 METODOLOGIA
Para melhor compreenso dos mtodos que foram utilizados nesta dissertao, este tpico
ser dividido em metodologia da pesquisa e metodologia da aplicao.
1.3.1 Metodologia da Pesquisa

Este tpico descreve as caractersticas da pesquisa que tem como objetivo a soluo da
situao problema identificada. As pesquisas podem ser utilizadas para diversos fins, seja para
formular ou testar teorias.
A pesquisa pode ser definida como um processo formal e sistemtico que desenvolve o
mtodo cientfico, em que o principal objetivo encontrar as respostas para os problemas,
empregando o uso de procedimentos cientficos (GIL, 1994).
Este estudo utilizou como base do desenvolvimento do guia de estimativas os modelos de
melhoria de processos CMMI-DEV, MPS.BR e ISO/IEC 15504-5. A partir dos resultados da
comparao do PMBOK e os referidos modelos das caractersticas das MPEs e seus processos de
softwares; e da anlise dos modelos e tcnicas existentes para realizar estimativas relacionadas s
caractersticas das MPEs, obteve-se a descrio da realidade do fato em estudo, cujo interesse
prtico circunda na aplicao futura de um guia.
Desta forma, este trabalho classifica-se como uma pesquisa aplicada. No entendimento de
Gil (1994), a pesquisa aplicada caracteriza-se pelo interesse na aplicao, utilizao e
conseqncias prticas dos conhecimentos, alm de se preocupar com a aplicao imediata na
realidade circunstancial, porm est estreitamente relacionada com a pesquisa pura, uma vez que
depende dos resultados e desenvolvimento da mesma para sua aplicao. Sobre pesquisa aplicada,
contemplam Marconi e Lakatos (1999, p. 22) [...] caracteriza-se por seu interesse prtico, isto ,
que os resultados sejam aplicados ou utilizados, imediatamente, na soluo de problemas que
ocorrem na realidade. J Oliveira (2001) explica que a pesquisa aplicada tem por objetivo
pesquisar, comprovar ou rejeitar hipteses sugeridas pela teoria, aplicando-se a diferentes
necessidades humanas, considerando determinadas teorias como ponto de partida.
22
Os objetivos OE1, OE2, OE3 e OE4 vislumbram a descrio dos fenmenos em estudo, com
intuito de oportunizar aos pesquisados o conhecimento profundo e detalhado da realidade estudada,
possibilitando a comparao, levantamento e registro de caractersticas que abordam o PMBOK,
modelos de melhoria de qualidade de software e MPEs. Quanto pesquisa descritiva destaca-se o
pensamento de Oliveira (2001) em que sustenta que este tipo de estudo permite identificar diversas
formas dos fenmenos, bem como analisar as variveis de causa e efeito. Enfim, pode-se dizer que
o estudo descritivo fornece ao pesquisador a compreenso do comportamento de diversos
fenmenos.
Com base na descrio dos fenmenos so atendidos os objetivos OE5 e OE6, que esto
baseados no desenvolvimento do guia de estimativas. Estes por sua vez, reforam a caracterstica
aplicada deste estudo e se fundamentam em uma pesquisa bibliogrfica construda a partir dos
pensamentos de tericos a cerca do PMBOK, CMMI-DEV, ISO/IEC 15504-5 e MPS.BR. Destacase que, segundo Marconi e Lakatos (1999) a pesquisa bibliogrfica aborda o levantamento, a
seleo e a documentao de bibliografias j publicadas, sobre o assunto pesquisado, e tem como
objetivo proporcionar ao pesquisador contato direto com o material j escrito sobre o mesmo.
Em especial quanto s informaes sobre as caractersticas das MPEs, foram descritas por
meio de pesquisas disponveis no site do MCT (Ministrio da Cincia e Tecnologia) e outras
pesquisas relacionadas ao tema. No que diz respeito ao OE7, destaca-se que aborda conceitos e
resultados que norteiam as anlises deste estudo, pois pretende apresentar um cenrio de avaliao
da aplicao do guia.
1.3.2 Metodologia da Aplicao

Por meio da comparao entre o PMBOK e os principais modelos de melhoria de processo
de software CMMI-DEV, MPS.BR, ISO/IEC 15504-5, obteve-se parmetros adaptveis as MPEs
de forma a selecionar, com base nas caractersticas destas, modelos/tcnicas de estimativas
alinhadas aos modelos em destaque. Tendo como base o PMBOK, esta descrio envolve como
parmetro avaliativo esforo, durao de atividades e tamanho de software.
Realizou-se tambm, a anlise das ferramentas existentes na rea de gerenciamento de
projetos e estimativas. Inicialmente, foram levantadas por meio de pesquisas as ferramentas e a
seguir elencaram-se requisitos desejveis a estas. Em seguida as ferramentas foram executadas a
23
fim de identificar a existncia ou no das caractersticas desejadas descritas nos requisitos. Por fim,
foi possvel realizar a anlise das ferramentas assim como uma comparao entre as funcionalidades
disponveis e as desejadas.
A seqncia lgica desta aplicao est ilustrada na figura 1.
Figura 1 - Metodologia de criao e aplicao do guia
Como proposto na ilustrao supracitada, a construo do guia de estimativas est

relacionado com o estabelecimento de diretrizes que visam justificar a seleo dos mtodos e
ferramentas que iro compor o guia, e que por sua vez so resultados das informaes levantadas
nos objetivos OE1, OE2, OE3 e OE4, em destaque AZUL na figura 1.
Com relao a avaliao do guia, esta foi realizada por meio da aplicao de um
questionrio (apndice A) junto a profissionais com curso e/ou prova nvel introdutrio do MPS.BR
e relacionados a consultoria e implementao na rea citada do LQPS (Laboratrio de Qualidade e
Produtividade de Software UNIVALI).
A avaliao do guia de estimativas desenvolvido utilizou a proposta do Goal Question
Metric GQM que prope derivar mtricas por meio de perguntas e objetivos (BASILI,
CALDIERA e ROMBACH, 1994). Conforme a figura 1, a partir dos resultados da avaliao do
guia de estimativas que serviu como feedback do objeto em estudo, foram identificados elementos
24
que necessitam ser modificados e/ou adaptados que tornem o guia de estimativa contribuinte ao
processo de estimar da MPEs de softwares, alm de sua validao como um material de auxlio na
implantao de um processo de estimativa de software neste tipo de empresa.
1.4 ORGANIZAO DO DOCUMENTO

O Captulo 2 apresenta a fundamentao terica da dissertao abordando os conceitos de
gerncia de projetos e planejamento, descrio do PMBOK e modelos de melhoria de processo de
software.
O Captulo 3 apresenta as caractersticas das micro e pequenas empresas de software e o
Captulo 4 descreve o estado da arte e prtica discutindo os documentos que abordam contedos
referentes a guias para implantao de processos na rea de gerenciamento de projetos.
O Captulo 5 apresenta o desenvolvimento do guia, sua estrutura e descrio breve de seus
captulos. No Captulo 6 a avaliao do guia apresentada abordando o planejamento, execuo,
anlise dos dados coletados e ameaas a viabilidade desta avaliao. No Captulo 7 as concluses e
recomendaes do trabalho so apresentadas.
25
2 FUNDAMENTAO TERICA
Neste tpico so apresentados os fundamentos tericos que norteiam o desenvolvimento
deste trabalho. abordado o tema gerncia de projeto, em especial a fase de planejamento que
possui entre suas atividades a de estimar que o foco deste projeto. Neste caso, as tcnicas e
modelos de estimativa so tambm apresentados.
Alm disso, os principais modelos de melhoria de processo de software que so foco deste
trabalho: CMMI-DEV (SEI, 2006), MPS.BR (SOFTEX, 2007) e ISO/IEC 15504-5 (ISO/IEC Std.
15504, 2005), so apresentados abordando conceitos, a rea de planejamento de projetos e como
cada um trata estimativas.
O PMBOK que a base para o guia que foi proposto tambm apresentado em especial
suas reas de processo que tratam de estimativas.
2.1 GERNCIA DE PROJETOS

Cabe inicialmente definir o termo projeto, que para Wysocki e McGary (2003) uma
seqncia de atividades nica, complexa e conexa, tendo uma meta ou proposta a ser finalizada em
um tempo especfico e de acordo com especificaes. Em PMI (2004), conceitua-se projeto como
sendo um esforo temporrio, que possui um incio e fim bem definidos, para a criao de um
produto, servio ou resultado.
Em projetos de softwares h uma srie de atividades que necessitam ser compreendidas para
que este tenha sucesso, tais como o escopo, os riscos, as tarefas a executar, o esforo, os marcos de
referncia (PRESSMAN, 2006), sendo que a gerncia de projetos permite esta compreenso.
Wysocki e McGary (2003) definem a gerncia de projetos como mtodo e conjunto de tcnicas
baseado em princpios de gesto que se preocupa com planejamento, estimativas e controle de
atividades para alcance de um resultado final a tempo e dentro de um oramento.
De acordo com PMI (2004), gerenciar um projeto envolve a identificao do que se
necessita; o estabelecimento de objetivo claros e possveis de serem alcanados; qualidade, custo,
escopo e tempo devem ser balanceados; as especificaes, planos e abordagem devem ser adaptados
considerando as preocupaes e expectativas dos interessados.
O gerenciamento de projetos realizado atravs de processos, usando conhecimento,

habilidades, ferramentas e tcnicas do gerenciamento de projetos que recebem entradas e geram
sadas (PMI, 2004).
Conforme PMI (2004), a gerncia de projetos est integrada em cinco atividades gerenciais:
Iniciao: esta atividade define o incio de um projeto, com processos que facilitam a
autorizao formal desde o comeo. Esta atividade tambm realizada para incio de
fases do projeto visando sempre a verificao da viabilidade de continuao ou no do
projeto.
Planejamento: constitui-se de atividades de planejamento, definindo e refinando os

objetivos, alm do planejamento da ao necessria para alcanar os objetivos e o escopo
para os quais o projeto foi realizado.
Execuo: esta fase possui processos que executam atividades com intuito de cumprir o
que foi determinado no plano de projeto.
Monitoramento e controle: processos de observao da execuo do projeto so

encontrados nesta atividade, a fim de identificar a tempo problemas para que aes
corretivas sejam aplicadas sem que haja prejuzo ao projeto.
Encerramento: nesta fase so encontrados processo que finalizam de maneira formal as

atividades do projeto, seja um projeto cancelado ou um produto finalizado.
Por ser foco de trabalho desta dissertao a atividade planejamento ligada a gerncia de
projetos ser melhor detalhada nas prximas sees.
2.2 PLANEJAMENTO
O planejamento de projeto a chave para uma boa gerncia de projetos (THOMSETT,
2002). De acordo com o autor um planejamento detalhado e preciso fornece informaes bases para
o projeto e define os negcios que so relevantes para a criao da soluo tcnica.
A fase de planejamento de projeto identifica as atividades, marcos e os documentos que
sero criados em determinado projeto. Cabe ressaltar que o plano deve ser desenvolvido para
27
alcanar os objetivos do projeto (SOMMERVILLE, 2003). Wysocki e McGary (2003) afirmam que
o plano de projeto indispensvel tanto para determinar como o trabalho deve ser realizado quanto
para auxiliar na tomada de deciso. O planejamento fornece informaes para que o gestor possa
escolher a melhor alternativa para determinado projeto.
O planejamento apresenta pelo menos trs vantagens (Wysocki e McGary, 2003):
Reduz a incerteza, pois a partir das sadas desejadas possibilita aplicar aes corretivas
necessrias a tempo.
Aumenta a compreenso, j que durante sua criao tem-se maior clareza dos objetivos e
metas do projeto.
Melhora a eficincia, uma vez que favorece a alocao de recursos, agendamento de

atividades simultneas, diminuindo tempo e custo de projeto.
A realizao do planejamento envolve as atividades de definio de escopo e objetivos do

projeto, definio de atividades e cronograma, anlise de risco, estimativa e alocao de recursos.
(PRESSMAN, 2006; PMI, 2004; SEI 2007). A figura 2 apresenta detalhadamente as atividades
envolvidas no planejamento de projetos.
28
Figura 2 - Atividades do planejamento de projetos

Fonte: adaptado (HUGHES; COTTERELL, 1999)
Cada passo apresentado na figura 2 dividido em atividades (Quadro 1) que devem ser
realizadas para que o objeto da fase seja alcanado.
29
Passo
1
5
6
9
10
Atividades
IDENTIFICAO DO ESCOPO E OBJETIVOS DO PROJETO
1.1: Identificar os objetivos e medidas prticas para comprovar sua eficcia
1.2: Identificar todos os interessados (stakeholders) no projeto
1.3: Estabelecer mtodos de comunicao com todas as partes
IDENTIFICAR INFRA-ESTRUTURA DO PROJETO
2.1: Identificar a infra-estrutura do projeto
2.2: Identificar padres e procedimentos
2.3: Identificar a organizao da equipe de projeto
ANALISAR CARACTERSTICAS DO PROJETO
3.1: Analisar as caractersticas do projeto
3.2: Identificar riscos do projeto em alto nvel
3.3: Selecionar o ciclo de vida do projeto
3.4: Revisar estimativas de recurso
IDENTIFICAR AS ATIVIDADES E PRODUTOS DO PROJETO
4.1: Identificar e descrever produtos do projeto (deliverables)
4.2: Produzir uma rede de atividades
4.3: Introduzir validaes entre os estgios das atividades
ESTIMAR ESFORO PARA CADA ATIVIDADE
5.1: Estimar esforo
IDENTIFICAR RISCOS DAS ATIVIDADES
6.1: Identificar e quantificar as atividades de risco
6.2: Planejar reduo de risco e medidas de contingncia apropriadas
ALOCAR RECURSOS
7.1: Identificar e alocar recursos humanos
7.2: Estabelecer o cronograma
7.3: Estabelecer o oramento
REVISAR E PUBLICAR O PLANO
8.1: Revisar aspectos de qualidade do plano de projeto
8.2: Documentar planos e obter concordncia
EXECUTAR O PLANO
PLANEJAMENTO DE NIVEL BAIXO
Quadro 1- Relao de atividades dos passos referentes ao planejamento de projetos

Fonte: Adaptado (HUGHES; COTTERELL, 1999)
No passo 1 de identificao do escopo e objetivos apresentado o que ser realizado em

determinado projeto, sendo que o entendimento do que o cliente deseja deve ser compreendido por
todos os envolvidos, a fim de garantir que atividades desta fase sejam utilizadas durante todo o
projeto e de descrever as funes e caractersticas que sero entregues ao usurio final, dados de
entrada e sada, conhecer quais as conseqncias de uso do software, restries e a confiabilidade
que limitam o sistema (PRESSMAN, 2006; HUGHES; COTTERELL, 1999). Em complemento as
necessidades, desejos e expectativas das partes interessadas so analisados para ento serem
convertidos em requisitos (PMI, 2004).
30
Neste passo tambm devem ser definidos os stakeholders envolvidos no projeto, bem como,
seu grau de autoridade dentro do projeto. Alm disso, define-se tambm como se dar a
comunicao entre os envolvidos no projeto (HUGHES; COTTERELL, 1999).
A infra-estrutura do projeto considerada no passo 2, referindo-se aos recursos necessrios
a execuo do projeto considerando-se a existncia ou necessidade de aquisio de local e ambiente
de trabalho, hardware, software, servios, treinamentos, entre outros (HUGHES; COTTERELL,
1999).
O passo 3 refere-se a anlise de caractersticas dos projetos em que se torna relevante a
certificao de que os mtodos adequados sero utilizados para o alcance dos objetivos do projeto.
Destaca-se a seleo do ciclo de vida e as estimativas do projeto (vide seo 2.2.1). (HUGHES;
COTTERELL, 1999).
A identificao de produtos e atividades do projeto e ainda a descrio destes destacada no
passo 4 do quadro 1. Sugere-se que estas sejam definidas e documentadas de acordo com o ciclo de
vida selecionado com o intuito de alcana o objetivo do projeto (HUGHES; COTTERELL, 1999).
A documentao pode ser realizada por meio de workflow demonstrando aspectos relevantes como
se um determinado produto de trabalho precisa existir para que outro seja obtido.
Estimar esforo (vide 2.2.1) o passo 5 e implica em apontar o tempo que ser dedicado a
cada atividade para que sejam realizadas da forma adequada. Neste contexto, a tcnica/mtodo
escolhido depender de fatores relacionados a realidade da empresa desenvolvedora do projeto.
No passo 6 deve-se identificar riscos inerentes ao projeto com intuito de diminuir o nmero
de riscos, bem como planej-los e control-los durante a execuo do projeto para que no haja
possibilidades de perder o projeto.
A identificao e alocao de recursos humanos abordada no passo 7 a fim de realizar
proviso de quem executar qual tarefa. Com base nestes e em dados anteriores torna-se possvel
realizar o cronograma do projeto, assim como o oramento destinado a este.
No passo 8 h uma reviso e publicao do plano. No primeiro aspecto deve-se observar
atributos de qualidade por meio da definio de critrios para garantir o sucesso na execuo do
31
projeto. Com relao a publicao pressupe-se a documentao deste artefato a fim de que possa
obter o conhecimento e aval de todos os envolvidos no desenvolvimento.
Os passos 9 e 10 referem-se a execuo do plano e planejamento deste em nvel baixo. o
primeiro refere-se a por em prtica o planejamento criado, j o segundo diz respeito a elaborao
dos planos em um nvel maior de detalhamento.
Nesta pesquisa torna-se relevante considerar os passos 1, 3, 4, 5 e 7, por apresentarem
aspectos relativos ao foco deste estudo, as estimativas que so detalhadas no prximo tpico deste
captulo.
2.2.1 Estimativas de software

Estimativas so expectativas dos responsveis pelos projetos com relao a estes e seu
controle na gerncia de projetos vital ao bom desenvolvimento do projeto. De acordo com
DeMarco (1991) a estimativa a essncia da dificuldade que temos em controlar projetos de
software.
As estimativas so realizadas no incio do projeto e podem ser corrigidas continuamente
quando mais informaes sobre o projeto forem obtidas (JALOTE, 2002). Uma boa estimativa
realizada quando h uma boa compreenso do projeto e usa-se de tcnicas que os especialistas
julgam mais eficientes situao.
Pode-se evidenciar uma srie de aspectos que levam a dificuldade em estimar, tais como
(DEMARCO, 1991; PRESSMAN, 2006):
a complexidade do projeto, que depender da familiaridade que se tem com

experincias anteriores, se est no portflio da empresa a algum tempo ou o negcio do
projeto ser um novo conhecimento aos especialistas da empresa de software;
o tamanho do projeto de software, que aumenta a medida que a interdependncia entre

os vrios elementos do projeto cresce. Como o projeto necessita ser decomposto em
pequenas partes para serem estimadas individualmente, quanto maior for seu tamanho
mais complexidade;
32
o grau de estrutura do projeto, ou seja, a facilidade de dispor funcionalidades em

compartimento alm da natureza de hierarquia das informaes que so processadas no
projeto. Quanto mais estruturado melhor a qualidade da estimativa.
no ter a disposio um histrico e no considerar desempenhos passados. Por no

terem formas padronizadas para estimar muitas empresas no possuem dados histricos
de projetos anteriores, to pouco, fazem uso de estimativas realizadas e comparaes
com os resultados reais obtidos;
a no especializao em estimar. O processo de estimar complexo e exige um

conhecimento prvio desta atividade. Muitas vezes a estimativa realizada por meio de
comparaes incoerentes, assim como com desenvolvedores ou analistas sem
experincia ou sem conhecimento necessrios para realizar a referida tarefa;
a falta de preocupao em corrigir os efeitos de distores nas estimativas. Como

abordado anteriormente, por vezes a atividade de estimativa no armazenada e quando
no h preocupao dos responsveis em averiguar distores entre o resultado
estimado e o real no desenvolvimento do projeto. Desta forma, guardar os dados
estimados ter pouca serventia para que em casos futuros, erros possam ser evitados;
o fato de no ter conhecimento do que realmente uma estimativa. Este entre todos
o primeiro fator que quem participa do processo de estimar deve considerar o que
entende, compreende por estimativa. Saber que se deseja chegar o mais prximo
possvel da realidade e no estabelecer nmeros improvveis, apenas desejveis.
Desta forma, pode-se encontrar um conjunto de tcnicas voltadas a estimativas, com

caractersticas especficas. No entanto, estas apresentam tambm alguns atributos em comum
(PRESSMAN, 2006):
A necessidade de ter um escopo definido que implica em se ter todo o trabalho

necessrio definido, delimitando o que faz parte e o que no est no projeto (PMI, 2004).
A utilizao de medidas de software e o uso de histrico de estimativas e resultados de

projetos j realizados.
33
A diviso do projeto e partes menores que sero estimadas de forma individual.
As estimativas realizadas durante a fase de planejamento constituem-se em atividades das

mais complexas no processo de gerncia de projetos, por isso necessitam da definio do escopo do
projeto PMI(2004). Os parmetros de esforo, durao de atividade e tamanho de software so
estimados durante a fase de planejamento de projeto e so revisados durante a execuo do projeto.
(PMI, 2004; PRESSMAN, 2006).
Esforo indica o quanto de mo-de-obra se necessita para executar determinada atividade ou
componente da EAP (Estrutura Analtica de Projeto), podendo ser medido em pessoa-hora, pessoadia, pessoa-semana ou at pessoa-ms de trabalho em um projeto (LAIRD e BRENNAN, 1952;
PMI, 2004).
A identificao da durao de atividade refere-se a medida de tempo, normalmente expressa
em dias ou semanas, necessrias a obteno de uma tarefa por completo. o perodo de trabalho
total para que se consiga terminar uma atividade do cronograma ou de um componente da estrutura
analtica do projeto (PMI, 2004).
Para a realizao de estimativa dos dois parmetros torna-se relevante ter o escopo bem
definido, assim como conhecer o tamanho estimado para o projeto. Identificar o tamanho do
software mesmo que aproximado necessrio a fim de que se obtenha estimativas de esforo e
durao, sendo que a tarefa de estimar em projetos de software no uma atividade de fcil
obteno, principalmente durante a fase de planejamento (FENTON e PFLEEGER, 1997). De
acordo com SOFTEX (2007), o tamanho a dimenso das funcionalidades sob o ponto de vista do
usurio.
Fenton e Pfleeger (1997) sugerem que o processo de estimar deve ser realizado conforme a
figura 3.
34
Observaes
empricas
Dados
Teoria
Variveis
chaves
Resultados
Atuais
Relacionamentos
Modelos /
Tcnicas
Previses
Projetos
Figura 3 Processo de estimativa genrico

Fonte: Adaptado Fenton e Pfleeger (1997)
De acordo com a ilustrao, figura 3, pode-se perceber que, o processo genrico para estimar
prev a obteno de dados por meio de observaes empricas e que por vezes apresentam algum
grau de subjetividade, referentes a estimativas sobre atributos especficos (FENTON E PFLEEGER;
1997).
Com base nos dados e nas teorias j existentes e estudadas as variveis chaves no processo
so produzidas. A partir desta anlise de dados e teoria, torna-se possvel criar ou aplicar modelos e
tcnicas de estimativa de software.
Em seguida, a aplicao de modelos gerados ou j existentes torna-se necessria tendo como
objeto a verificao de sua eficincia e preciso por meio da gerao de previses para projetos de
software.
Por fim, a anlise dos resultados obtidos por meio da aplicao de mtodos e tcnicas
realizada, com intuito de avaliar se o que foi obtido demonstra se os mtodos e tcnicas empregados
esto adequados ou necessitam que sejam realizados ajustes, os tornando funcionais e aplicveis.
Cabe destacar que esta abordagem definida por Fenton e Pfleeger (1997), diz que qualquer
estimativa
deve
permitir
utilizao
de
diferentes
mtodos
de
estimativa,
utilizar medidas, no estimativas, como entrada para os modelos e como apoio peridico realizar re-
35
estimativa e fornecer feedback para melhorar a habilidade de estimadores e a preciso aos

modelos/tcnicas da estimativa.
2.2.1.1 Tipos de Estimativas
Este tpico sumariamente descreve os tipos de estimativas mais utilizados atualmente para
apoiar a atividade de estimativas de software durante a fase de planejamento e so utilizadas como
base para o desenvolvimento do guia.
Estimativa bottom-up
As estimativas so realizadas decompondo em detalhes o que se pretende estimar, no caso
projetos de software. Cada parte do projeto decomposta estimada e ao final faz-se a somatria
para que seja obtida a quantidade total estimada (PMI, 2004).
A EAP utilizada para as atividades referentes a esta tcnica, pois em projetos muito
grandes a diviso realizada em tpicos, subtpicos e assim por diante. Se necessrio at o estgio
em que foram encontrados componentes distintos que possam ser executados por algum recurso
humano EAP (HUGHES & COTTERELL, 1999).
A tcnica de estimativa bottom-up uma alternativa para casos em que a empresa no possui
dados histricos referentes a projetos de software anteriores e o estimador necessita fazer
suposies a respeito de caractersticas do sistema.
Estimativa top-down
De acordo com Fenton e Pfleeger (1997), nesta tcnica realiza-se a estimativa do projeto
como um todo e posteriormente cada parte, cada componente estimado considerando o que foi
estimado inicialmente.
A estimativa top-down envolve obter a estimativa de tamanho, definir o nvel de
produtividade do projeto considerando, por exemplo, projetos similares, obter a estimativa global
com base no tamanho e produtividade, realizar a estimativa de esforo das atividades do projeto e
por fim refinar estimativas considerando fatores especficos do projeto (JALOTE, 2002).
Cabe destacar que as estimativas top-down e bottom-up podem ter sua utilizao associada,
pois os gerentes de projetos podem adotar diferentes tcnicas para seus vrios estimadores e obter
36
diferentes estimativas. Como exemplo, parte do projeto pode ser estimado utilizando bottom-up e a
outra parte aplicando top-down (HUGHES & COTTERELL, 1999).
Estimativa paramtrica
Esta tcnica utiliza dados histricos em conjunto com outras variveis como, por exemplo,
linhas de cdigo para estimar. (PMI, 2004). Estes dados so trabalhados de forma estatstica,
obtendo-se informao quantitativa da estimativa.
Os modelos paramtricos utilizam frmulas que se assemelham e consideram a forma da
seguinte na Equao 1 (HUGHES & COTTERELL, 2006):
Esforo = T * P
Equao 1 - Forma modelos paramtricos
Fonte: HUGHES & COTTERELL (2006)
Sendo que T refere-se ao tamanho do projeto e P a taxa de produtividade. Como exemplo,

pode-se citar um sistema a ser medido em milhares de linhas de cdigo (KLOC) e que tenha o valor
especfico de 3 KLOC quando a taxa de produtividade foi de 40 dias por KLOC. Desta forma, o
trabalho estaria completo em 120 dias (HUGHES & COTTERELL, 2006).
2.2.1.2 Modelos/Tcnicas para Estimativas de Software
Por no ser tarefa trivial a estimativa de software possui vrios trabalhos que procuram
apresentar a melhor forma de obt-la (ALBRECHT, 1981; KARNER, 1993; BOEHM, 1981).
Alguns destes modelos ou tcnicas para obteno da estimativa mais realista aos parmetros de
projeto de software so apresentados em detalhes.
Estimativa por analogia

Esta tcnica tambm chamada de raciocnio baseado em caso em consonncia a seu
conceito. A idia desta tcnica a criao de estimativas para um novo projeto por meio de
comparao deste com projetos anteriores identificando diferenas e similaridades (MCCONNELL,
2006). Neste caso, o gerente de projeto pode realizar ajustes nos dados obtidos em casos anteriores
e aplicar no que est sendo o objeto atual de trabalho.
37
No entanto, identifica-se como principal dificuldade da tcnica, como encontrar semelhanas

e diferenas entre softwares variados. Como alternativa tem-se procurado automatizar o processo e
utilizando para isto a distncia euclidiana entre os casos, que pode ser obtida pela frmula da
Equao 2 (HUGHES & COTTERELL, 1999):
Distncia =
( parmetro _ atual
parmetro _ origemi )
i =1
Equao 2 - Distncia Euclidiana
Os dados para execuo da equao 2 referem-se a parmetros referentes a entrada e sada

do sistema atual e sistemas passados. Neste caso, aplica-se a frmula subtraindo-se o nmero de
entradas do sistema atual pelo sistema passado e somando-se com a subtrao do sistema atual com
o sistema de origem (HUGHES & COTTERELL, 1999). A comparao ideal ter uma distncia
entre 0 e 1, sendo o projeto antigo usado neste clculo o mais adequado para ser usado como base
para o processo de estimativa.
Como exemplo, observe a Tabela 1.
Tabela 1- Exemplo de dados de projetos
Funcionalidades
Projeto antigo 1
Projeto antigo 2
Projeto novo
Interface com usurio
14000
16300
19600
Regras de negcio
11000
10500
16500
Fonte: Adaptado de McConnell (2006).
Como exemplo, imagine que o tamanho de determinados projetos antigos de uma empresa,
em linhas de cdigo, para as variveis na Tabela 1. Aplicando a Equao 2 tem-se que a distncia
entre o projeto 1 e o novo de 7849 e entre o projeto 2 e o novo de 6847. Neste sentido, o projeto
2 de acordo com os autores tem uma aproximao maior com o atual e deve ser utilizado para esta
tcnica.
Outro trabalho sugere passos para realizar estimativa por analogia (MCCONNELL, 2006):
1. Obter detalhes referentes ao parmetro a ser estimado observando projetos anteriores
semelhantes, preferencialmente com decomposio de atividades, usando, por exemplo,
38
uma EAP ou outra forma de decomposio. Para encontrar o(s) projeto(s) com maior
semelhana pode-se utilizar a Equao 2.
2. Realizar uma comparao considerando dados e parmetros a estimar do novo projeto
com os dados do projeto antigo abrangendo todas as partes.
3. Construir a nova estimativa do parmetro desejado do novo projeto com base nos dados
obtidos e analisados do projeto antigo selecionado por apresentar maior semelhana.
4. Checar a consistncia dos pressupostos por meio dos projetos (novo e antigo).
Utiliza-se de informaes histricas e opinio especializada. (FENTON e PFLEEGER,
1997; PMI, 2004). Nesta tcnica torna-se interessante a documentao de projetos, principalmente
relativo a estimativas anteriores, forando os estimadores a faz-la para que os dados registrados
possam ser utilizados em novas estimativas. (FENTON e PFLEEGER, 1997).
Estimativa de trs pontos ou PERT (Program evaluation and Review Technique)

Esta tcnica baseia-se em trs tipos de estimativas para apresentar um resultado mais
prximo possvel do desejado, sendo estas estimativas classificadas como a mais provvel (M), a
otimista (O) e a pessimista (P) conforme so descritas a seguir (PMI, 2004; HUGHES &
COTTERELL, 2006):
A estimativa mais provvel (M) prev expectativas realistas para a estimativa, ou seja,
espera-se que apresente os resultados em circunstncias normais.
O melhor caso possvel focado na estimativa otimista (O). Neste tipo, considera-se
condies favorveis e estima-se o menor tempo em que se pode realizar determinada
atividade.
Por fim, a estimativa pessimista (P) que visualiza o pior caso para a estimativa, ou seja,
considera todas as circunstncias e eventualidades que possam prejudicar o
desenvolvimento do projeto.
Assim, PERT combina as trs estimativas previstas utilizando uma frmula apresentada na
Equao 3 em que T a mdia para a estimativa do parmetro desejado.
39
T = (O + 4M + P)/6
Equao 3 - Frmula PERT
Fonte: HUGHES & COTTERELL ( 2006)
possvel para a tcnica PERT calcular o desvio padro que proporciona um nvel de
confiana para a estimativa encontrada. A probabilidade de estar dentro do esperado pode ser
calculada usando a frmula apresentada na Equao 3.
DesvPad = (P O)/6
Equao 4 - Frmula Desvio Padro
Fonte: HUGHES & COTTERELL ( 2006)
Quanto maior for o desvio padro obtido, significa que h um grande intervalo entre o
previsto nas estimativas Otimista e Pessimista. O que se deseja que o resultado do desvio padro
(DesvPad) seja pequeno, pois indica que as estimativas apontadas inicialmente estavam adequadas.
Opinio especializada
De acordo com pesquisas esta tcnica a mais comum e mais utilizada na prtica. As
pesquisas apontam que 72% dos projetos utilizam opinio especializada para estimar
(KITCHENHAM et al., 2002 apud MCCONNELL, 2006).
Os membros da equipe com conhecimento especializado e a partir de dados histricos
podem fornecer estimativa na rea desejada e especfica de seu conhecimento (PMI, 2004). Este
tipo de estimativa exige que se tenha um especialista disponvel. Neste caso, deve-se considerar que
no necessariamente uma pessoa que especialista em desenvolvimento de software ser um
especialista em estimativa, assim sugere-se que a pessoa mais indicada para estimar nesta tcnica
ser aquele que desenvolve a atividade que est sendo foco da criao de estimativa
(MCCONNELL, 2006; LAIRD e BRENNAN, 2006).
Neste sentido, o estimador especialista tem condies de realizar anlises mais precisas, pois
por seu conhecimento consegue prever em suas estimativas, os impactos que solicitaes de
40
mudanas podem ocasionar ao longo do desenvolvimento do projeto, tanto em requisitos como no

prprio cdigo do sistema (HUGHES & COTTERELL, 1999).
Para utilizar esta tcnica, o gerente de projetos dever descrever quais os parmetros do
projeto de software deseja estimar e os especialistas principais faro previses baseadas em suas
experincias anteriores (FENTON e PFLEEGER, 1997). Sugere-se que em grandes projetos os
estimadores escolhidos sejam os mais experientes dentre os que atuaro no projeto (MCCONNELL,
2006).
Hughes e Cotterell (1999), afirmam que de acordo com suas pesquisas, especialistas tm
adotado a associao das tcnicas de estimativa anloga e a estimativa bottom-up a esta tcnica com
sucesso.
Wideband delphi
Esta tcnica proposta por Boehm (1981) realizada em grupo e tem como pressuposto a
realizao de vrias estimativas individuais inicialmente, e seguir para a convergncia em grupo. As

principais atividades para o desenvolvimento da tcnica do Wideband Delphi so:
1. Cada especialista recebe do gerente de projeto, informaes relevantes sobre o projeto,
como por exemplo, documentos disponibilizados pelo cliente e o prprio projeto que
ser estimado.
2. O grupo de especialistas reunido para questionamentos sobre o projeto, alm de uma
discusso acerca deste.
3. A seguir, os especialistas fornecem, em sigilo, baseados em suas experincias anteriores,
estimativas para as vrias atividades que sero realizadas no projeto.
4. Aps as estimativas individuais, o coordenador faz um relatrio em que se encontra a
estimativa individual do especialista e a mdia do grupo.
5. Uma reunio do coordenador e especialista ocorre para que se discuta sua estimativa
com a mdia do grupo.
41
6. Novas estimativas so realizadas, repetindo-se o passo 2 ao 6 at que se obtenha uma

mdia nas estimativas que seja vivel e satisfatria, ou seja, quando h um consenso
entre os dados apontados pelos especialistas.
As atividades podem ser realizadas pessoalmente ou eletronicamente via chat ou email e
ainda podem ser desenvolvidas imediatamente umas aps as outras ou no.
Cabe salientar que, nesta tcnica a experincias dos especialistas que participam do projeto,
principalmente em situaes semelhantes, torna-se de grande relevncia. Desta forma, caso a
empresa no possua profissionais com conhecimento suficiente no desenvolvimento de atividades
de projetos a tcnica pode se prejudicada.
No foi possvel obter dados referentes ao tempo ou esforo para execuo desta tcnica. O
que seria relevante, pois em empresas de pequeno porte torna-se difcil conseguir muito tempo para
a realizao desta atividade.
Anlise por pontos de funo

De acordo com Albrecht e Gaffney (1983), esta tcnica aborda fatores que existem em
qualquer aplicao e surgiu da necessidade de identificar o tamanho funcional de um programa

independente da linguagem de programao com a qual seria desenvolvido.
O objetivo est em listar e contar um conjunto de cinco componentes denominados pelos
autores do modelo como (HUGHES & COTTERELL, 1999):
Entradas externas: referem-se a entradas de transaes que alimentaro arquivos
internos do sistema.
Sadas externas: so transaes em que os dados so externalizados ao usurio,
normalmente na forma de relatrios impressos ou monitor.
Arquivos internos lgicos: so arquivos utilizados internamento pelo sistema, compese de um conjunto de dados que comumente acessado.
Arquivos de interface externos: permitem a entrada e sada de dados em uma aplicao
computacional.
42
Consultas externas: so informaes solicitadas pelo usurio, mas no permitem a

atualizao de arquivos internos do sistema.
Para esta tcnica adotam-se graus de dificuldade definidos como baixo, mdio, alto que so
relacionados com cada componente do modelo conforme Quadro 2.
Componente
Baixa
Mdia
Alta
3
4
7
4
4
10
6
7
15
10
Entradas externas (External Inputs - EI)

Sadas externas (External Outputs - EO )
Arquivos internos lgicos (Internal Logical Files ILF)
Arquivos de interface externos (External Interface
Files - EIF)
Consultas externas (External Inquiry - EQ)
Quadro 2 - Pesos dos componentes de acordo com as complexidades

Fonte: IFPUG (2000).
Baseado neste quadro pode-se calcular os pontos por funo no ajustados (unadjusted
function point count UFP), consistindo da frmula da Equao 5:
UFP = EI * PESO) + (EO * PESO) + ILF * PESO) + (EIF * PESO) + * PESO
(
(
EQ
Equao 5 - Clculo do ponto de funo no ajustado
Na Equao 5, para composio da frmula deve-se para cada componente, separ-lo por
complexidade baseado nos pesos identificados na Quadro 2. Em seguida a quantidade de cada
componente de uma complexidade deve ser multiplicada por seu peso (Quadro 2), por fim realizase o somatrio para estes resultados obtidos.
Com base no UFP realizado um ajuste baseado na complexidade ou dificuldade de
implementao do sistema. Para isso torna-se necessrio o valor do fator de ajuste (value
adjustment factor - VAF). Para determinar o VFA tem-se um conjunto de 14 caractersticas de
sistema com perguntas relacionadas a estas que permitem determinar qual o grau de influncia de
cada caracterstica para o projeto em questo, como segue:
Requer cpias segurana confiveis?
43
O sistema requer comunicao de dados?
Existe processamento distribudo de funo?
O desempenho um aspecto crtico?
Ambiente de execuo tem grande carga de processamento?
O sistema requer entrada on-line?
As transaes on-line so eficientes para o usurio?
Os arquivos so utilizados on-line?
Configurao e utilizao de equipamento?
O processamento complexo?
O cdigo projetado/construdo para ser reutilizado?
O projeto inclui converso ou instalaes?
O sistema projetado para o uso em mltiplas instalaes em diferentes

organizaes?
O sistema projetado para ser de fcil utilizao e para facilitar mudanas?
Para tanto, utiliza-se de pesos que variam de 0 a 5, sendo classificados como se pode
visualizar na Quadro 3.
Peso
0
1
2
3
4
5
Grau de influncia
Insuficiente
Mnima
Moderada
Mdia
Alta
Essencial
Quadro 3 - Graus de influncia das caractersticas de sistema da APF

Fonte: adaptado IFPUG (2000).
44
O Grau Total de Influncia (total degree of influence - TDI) obtido quando se faz o
somatrio de todos os pesos relacionados s 14 caractersticas do sistema. Desta forma, possvel
obter o ponto por funo ajustado conforme Equao 6, em que 0.01 o Coeficiente por Grau de
Influncia calibrado pela indstria como 0,01 e 0.65 uma constantes emprica.
VAF = (TDI * 0.01) + 0.65

Equao 6 - Valor do fator de ajuste
Desta forma, o VAF pode estar representando uma variao na converso da contagem dos
pontos de funo no ajustado em mais ou menos 35%.
Para finalizar este processo, obtm-se o ponto de funo ajustado (AFP) a partir da Equao
7.
AFP = UFP * VAF
Equao 7 - Ponto de funo ajustado

Esta tcnica possibilita a estimativa de tamanho de um sistema a partir do nmero de

caractersticas/funcionalidades visveis e previstas no projeto. Para obter o tamanho do projeto fazse a converso de pontos de funo para LOC (linhas de cdigo) utilizando uma tabela com a mdia
de LOC por ponto de funo considerando as diferentes linguagens de programa. Neste caso
preciso saber a linguagem de programao que ser utilizada no desenvolvimento do projeto que
est sendo estimado (BFPUG, 2008).
A recomendao do BFPUG (2008) que sejam medidos alguns projetos, para determinar o
valor mdio da razo SLOC/PF em cada caso especfico. No entanto, existem valores baseados em
vrios projetos que indicam a relao referida para cada situao como referenciada em QSM
(2005) que apresentada no Quadro 4.
45
SLOC/FP
Linguagem
Access
Ada
ASP
Mdia
35
154
69
Mediano
38
62
Baixo
15
104
32
Alto
47
205
127
Assembler
C
C++
C#
Clipper
COBOL
DBase III
DBase IV
Excel
FORTRAN
FoxPro
HTML
Informix
J2EE
Java
JavaScript
172
148
60
59
38
73
52
47
32
43
42
61
60
56
157
104
53
59
39
77
46
35
42
31
50
59
54
86
9
29
51
27
8
31
25
35
24
50
14
44
320
704
178
66
70
400
63
35
53
57
100
97
65
JCL
JSP
Lotus Notes
Mapper
Oracle
Perl
PL/1
PL/SQL
SAS
Smalltalk
SQL
VBScript
Visual Basic
VPF
Web Scripts
60
59
21
118
38
60
59
46
40
35
39
45
50
96
44
48
22
81
29
58
31
41
32
35
34
42
95
15
21
15
16
4
22
14
33
17
15
27
14
92
9
115
25
245
122
92
110
49
55
143
50
276
101
114
Quadro 4 - SLOC por pontos de funo

Fonte: Adaptado de QSM (2005)
Nesse sentido para obter o tamanho do software utilizando a converso para SLOC
multiplica-se o nmero encontrado na tabela referente a linguagem de programao utilizada pelos
pontos de funo encontrados (AFP). No caso seria interessante utilizar valor mdio apontado no
Quadro 4 (QSM, 2005).
46
De posse de dados histricos das empresas possvel estimar esforo considerando a

produtividade da equipe, por exemplo, quantas horas a equipe leva para produzir 1 ponto de funo.
Com esta informao possvel aplicar a equao 8:
Esforo = produtividade * AFP

Equao 8 - Clculo do esforo
A estimativa de durao tambm possvel desde que se tenha o esforo (E), o tamanho da
equipe de trabalho (TE) e a quantidade de horas dirias trabalhadas (HT) por seus integrantes
conforme Equao 9.
Durao (em dias) = E (horas) / (TE *HT)

Equao 9 - Clculo do esforo
Assim com a aplicao das equaes 8 e 9 finaliza-se o processo de obteno dos atributos
esforo e durao com base no tamanho do software obtidos em pontos por funo por meio da
tcnica de Anlise por pontos de funo (IFPUG, 2000).
Neste trabalho optou-se pelo uso da anlise por pontos de funo criada por Albrecht (1981)
e atualmente o desenvolvimento continua com IFPUG (2000). No entanto, torna-se relevante
salientar que existem outras verses desta tcnica desenvolvidas e adaptadas por outras entidades,
cita-se MARK II, NESMA, COSMIC-FFP.
O MARK II um mtodo de anlise quantitativa e medio de tamanho funcional,
considerando o conjunto de requisitos funcionais exigidos pelos usurios para aplicao de produto
de software. Este mtodo destina-se a cumprir com a norma ISO 14143 / 1, a norma internacional
para Medidas de Tamanho Funcional (UKSMA, 1998).
A aplicao deste mtodo independe do modelo de gerenciamento de projetos utilizado e
tambm do mtodo de desenvolvimento de projetos adotado. Por ser uma medida lgica torna-se
independente de como so executados. (UKSMA, 1998).
47
A diferena entre o FPA e o MK II encontra-se no fato de que no primeiro mtodo a

mensurao da contagem dos arquivos lgicos ocorre apenas uma vez para cada parte do software,
diferente no MK II em que toda vez que tipos de entidade so referenciados em cada transao
lgica estas so mensuradas. As duas mtricas apresentam pontuao semelhante em projetos com
at 400 pontos de funo, quando essa marca ultrapassada normalmente a mtrica MK II pontue
valores maiores que a FPA. (UKSMA, 1998).
O NESMA outra organizao formada por grupos de usurios do FPA. Possui seu prprio
manual de FPA sendo compatvel com o IFPUG. A diferena entre os dois mtodos est na
definio dos tipos de componentes definidos (EI, EO, ILF, EIF, EQ) (NESMA, 2008).
A NESMA reconhece trs tipos de contagem de pontos de funo a contagem de pontos de
funo detalhada, a contagem de pontos de funo estimativa, a contagem de pontos de funo
indicativa. Com relao s contagens de estimativa e contagens de indicativa para pontos de funo,
estas foram desenvolvidas para permitir que uma contagem de pontos de funo seja feita nos
momentos iniciais do ciclo de vida de um sistema. (NESMA, 2008).
Cabe salientar que o manual NESMA no est disponvel para download gratuito. (NESMA,
2008).
A tcnica nomeada COSMIC-FFP (Common Software Measurement International
Consortium Full Function Points) um mtodo padro de medio de tamanho funcional do
software a partir domnios funcionais para sistemas informaes gerenciais e software em tempo
real. O COSMIC foi padronizado como a norma internacional ISO / IEC 19761 de medio
(COSMIC, 2007).
Com relao ao mtodo FPA (IFPUG), ambos os mtodos tm objetivo em comum que
medir o tamanho funcional de um software, sem considerar a tecnologia que ser aplicada, tambm
o mtodo IFPUG apresenta tentativas para levar em conta o efeito sobre o tamanho de certas
exigncias tcnicas e de qualidade. O COSMIC preocupa-se apenas com os requisitos funcionais do
usurio. (COSMIC, 2007).
O IFPUG foi criado para dimensionar o tamanho de aplicativos de software empresarial, no
sendo adequado para a maioria dos softwares em tempo real e para software que apresenta
48
algoritmos matemticos. De maneira mais abrangente o COSMIC dedica-se a trabalhar tambm

com software em tempo real e softwares que consideram as duas abordagens. (COSMIC, 2007).
A apresentao de outras abordagens da tcnica anlise por pontos de funo existentes foi
realizada superficialmente, pois o intuito est em conhecer a existncia destas j que se optou pela
adoo da que foi explicada exaustivamente neste tpico.
Anlise por ponto de casos de uso

Em projetos de software em que se utiliza anlise orientada a objetos, os requisitos
funcionais so representados por meio de casos de uso (use cases) quando do uso da UML1. Estes
podem ser definidos como sendo a forma com a qual o usurio utiliza o sistema, sendo compostos
de um conjunto de interaes seqenciais referente as relaes entre o sistema que est sendo
desenvolvido e seu exterior (RIBU, 2001).
O caso de uso deve descrever um comportamento do ponto de vista de um ator2, o que pode
ser muito complexo. Assim, na tentativa de captar a essncia do comportamento torna-se necessrio
exigir um modelo de sistema que possibilite vrios nveis de decomposio (SMITH, 1999).
Partindo do pressuposto que os casos de uso sejam bem selecionados e analisados e que
represem realmente o que o usurio deseja para seu sistema pode-se dizer que se torna conveniente
basear neles estimativas de tamanho e recursos, o que conseqentemente possibilitar estimar
esforo. (RIBU, 2001).
A anlise de pontos por caso de uso teve como inspirao a anlise por pontos de funo,
mas com o beneficio da anlise dos requisitos na forma de modelos de casos de uso (KARNER,
1993). O mtodo necessita que seja possvel para cada caso de uso seja contabilizar o nmero de
transaes, sendo estas consideradas qualquer evento que ocorra entre o ator e o sistema, podendo
ser realizado por completo ou no (BENTE ANDA et al, 2001). Considera-se que a anlise por
pontos de caso de uso tem basicamente quatro passos que sero descritos em detalhes a seguir.
1
2
UML - Unified Modeling Language

Ator - algo ou algum que interage com o sistema (BOOCH, JACOBSON, RAMBAUNGH, 1996)
49
Primeiramente h uma categorizao dos atores dos casos de uso em Simples (S), Mdio
(M) ou Complexo (C) e o clculo de um valor no ajustado dos atores. Os pesos para cada categoria
so respectivamente, 1, 2 e 3 (KARNER, 1993).
Um ator simples refere-se, por exemplo, a uma API (Application Programming Interface)
com outro sistema, possui uma interface bem definida sendo que suas reaes, as sadas do sistema
ou entrada recebidas por ele so bastante previsveis. Pode-se citar como exemplo, no caso de um
sistema de matrcula de uma universidade, a interface com o sistema financeiro que verifica se o
aluno est matriculado (KARNER, 1993; RIBU, 2001).
No que se refere a atores classificados como mdio, so assim considerados quando a
comunicao realizada com um sistema externo por meio de um protocolo como o TCP/IP ou
ainda representa um sistema de hardware, pois a interface de comunicao exigida padronizada
como no caso de protocolo. Cabe destacar que estes atores tm mais propenses a erro e so difceis
de serem controlados (KARNER, 1993; RIBU, 2001).
Atores so classificados como do tipo complexos quando representam pessoas que iro
interagir com o sistema, normalmente por uma interface grfica ou ainda uma pgina web. Por este
motivo diz-se que h maior complexidade neste tipo de ator, j que este pode executar qualquer
atividade, sendo totalmente imprevisveis. Como exemplo, pode-se citar o aluno ou responsvel da
secretaria no sistema de matrcula da universidade (KARNER, 1993; DAMODARAN, 2003; RIBU,
2001; BENTE ANDA et al, 2001 ).
Finalizando este passo calcula-se o total no ajustado do ator (unadjusted actor weights UAW), somando a quantidade classificada para cada categorizao e multiplicando estes totais por
seus respectivos pesos (KARNER, 1993; DAMODARAN, 2003; RIBU, 2001; BENTE ANDA et
al, 2001 ). A Equao 10 demonstra o clculo do UAW.
UAW =
Atores* S + Atores* M + Atores* C
Equao 10 - Total no ajustado de atores (unadjusted actor weights - UAW)

Fonte: KARNER (1993); RIBU (2001)
A segunda etapa constitui-se em classificar tambm os casos de uso (USC) em Simples (S),
Mdio (M) ou Complexo (C). Esta categorizao depender do nmero de transies existentes para
50
cada caso de uso, considerando tambm os fluxos alternativos descritos neste. Os pesos para cada
categoria e nmero de transies para cada caso de uso so definidos no Quadro 5 (KARNER,
1993; DAMODARAN, 2003; RIBU, 2001; BENTE ANDA et al, 2001).
Categorias
Simples (S)
Mdio (M)
Complexo (C)
Nmero de transies
1.. 3
4..7
8..*
Pesos
5
10
15
Quadro 5 - Relao nmero de transies e pesos de caso de uso

Fonte: KARNER (1993)
Pode-se tambm realizar a classificao medindo a complexidade dos casos de uso baseado
na contagem das classes de anlise que identificam como um caso de uso implementado (RIBU,
2001). O Quadro 6 apresenta como ocorre a categorizao neste caso.
Categorias
Simples (S)
Mdio (M)
Complexo (C)
Nmero de transies
1.. 5
6..10
11..*
Pesos
5
10
15
Quadro 6 - Relao nmero de transies e pesos de caso de uso

Para completar deve-se calcular o total no ajustado de caso de uso (unadjusted use case
weights - UUCW) somando a quantidade de casos de uso em cada categorizao e multiplicando
por seu peso respectivo que pode ser obtido por meio das tabelas 3 e 4 dependendo do aspecto
considerado para a classificao. A Equao 11 representa o clculo do total no ajustado de caso
de uso (unadjusted use case weights - UUCW).
UUCW =
USC* S +USC* M + USC* C
Equao 11 - Clculo do total no ajustado de caso de uso

Fonte: KARNER (1993); RIBU (2001)
O ponto de caso de uso no ajustado (UUCP) calculado somando-se total no ajustado do

ator (UAW) obtido pela equao 10 e o total no ajustado de caso de uso (UUCW) obtido pela
equao de nmero 11. Esta operao pode ser observada na Equao 12.
51
UUCP = UAW + UUCW

Equao 12 - Clculo do total no ajustado de caso de uso
A prxima etapa a obteno valor ajustado de ponto de caso de uso (adjusted use case
points - UPC), realizado considerando fatores tcnicos como complexidade e fatores ambientais de
maneira a quantificar requisitos no funcionais, cita-se a usabilidade e motivao do programador.
(RIBU, 2001).
Cada fator tcnico associado a um peso que varia de 0 a 5 dependendo da influncia que
exerce sobre o projeto como um todo (KARNER, 1993): neste caso, o valor 0 significa que o fator
irrelevante no contexto do projeto; o valor 3 significa que o fator relevante com um grau de
influncia mdia; o valor 5 significa que o fator essencial para o sucesso do projeto.
Observe que o Quadro 7 apresenta os fatores tcnicos a serem considerados para encontrar o
valor ajustado de ponto de caso de uso.
FATOR
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
DESCRIO
Sistema distribudo
Tempo de resposta (desempenho)
Eficincia do usurio final
Complexidade de processamento interno
Reusabilidade de cdigo
Facilidade para instalao
Usabilidade
Portabilidade
Facilidade para mudana
Concorrncia
Caractersticas de segurana
Conexo com outros sistemas
Necessidade para treinamento de usurio
PESO
2
2
1
1
1
0.5
0.5
2
1
1
1
1
1
Quadro 7 - Fatores tcnicos de complexidade

Fonte:
Karner (1993)
Baseado no Quadro 7 inicia-se o clculo do Fator de complexidade Tcnica (Technical

Complexity Factor - TCF) multiplicando cada fator por seu peso e em seguida realizando a
somatria da multiplicao citada obtendo-se o TFactor. Na equao 13 FatorTn identifica cada
fator tcnico descrito no Quadro 7 e PesoTn reflete o peso de determinado fator tcnico.
52
TFactor =
FatorT * PesoT
n
Equao 13 - Calculo do FatorT

Para encontrar o valor final do TCF deve-se multiplicar o TFactor por 0.1 e somar a 0.6
conforme apresentado na Equao 14. A constante 0.6 deriva da tcnica de FPA proposta por
Albrecht (1981) em que se tinha 0,65.
TCF = 0.6 + (0.01* TFactor)
Equao 14 - Clculo do TCF
Na seqncia deve-se calcular o Fator ambiental tendo como base a tabela que elenca os
fatores considerados, descries e pesos destes.
Fator
F1
F2
F3
F4
F5
F6
F7
F8
Descrio
A equipe familiar com o processo formal de desenvolvimento que ser utilizado
Experincia da equipe com o tipo de aplicao
Experincia da equipe com orientao a objetos
Capacidade de analise chefe
Motivao da equipe
Estabilidade dos requisitos
Trabalhadores em tempo parcial
Dificuldade com a linguagem de programao escolhida
Peso
1.5
0.5
1
0.5
1
2
1
2
Quadro 8 - Fatores ambientais

Desta forma, cada um destes fatores deve ser classificado de acordo com seu grau de
influncia no projeto que pode variar entre 0, 3 ou 5 como a descrio apresentada no Quadro 9.
Fatores
F1 a F4
F5
F6
F7
F8
0
Nenhuma experincia
Nenhuma
Mudam constantemente
No haver
Fcil
3
Experincia mdia ou normal
Mdia ou normal
Mudam na mdia
Poucos Mdia
Mdia
5
Alta experincia
Alta
Praticamente no mudam
Pessoal Tcnico
Muito difcil
Quadro 9 - Grau de influncia dos fatores

53
O clculo do Fator de ambiente (Environmental Factor - EF) inicia pelo encontro do

EFactor multiplicando cada fator por seu peso e realizando a somatria de todos os produtos.
Observando-se a Equao 15 FatorFn refere-se a cada um dos fator do Quadro 8 e PesoFn ao peso
atribudo a este conforme Quadro 9.
EFactor =
FatorF * PesoF
n
Equao 15 - Calculo do EFactor

Para encontrar o valor final do EF deve-se realizar o clculo da Equao 16.

EF = 1.4 + (-0.03 * EFactor)
Equao 16 - Clculo do EF
Com base nos clculos do TCF e EF possvel obter o valor total ajustado de pontos de caso
de uso (adjusted use case points - UPC) por meio da Equao 17.
UPC = UUCP*TCF*EF
Equao 17 - Clculo do FA
O UPC obtido por meio da multiplicao entre o Total no ajustado de pontos por caso de
uso (UUCP) pelo Fator de complexidade tcnica (TCF) e pelo Fator ambiental (EF).
Por fim a partir deste clculo pode-se obter o esforo necessrio a determinado projeto de
software, utilizando como representao de produtividade um fator de 20 pessoas/hora por ponto de
caso de uso, sendo o total de pessoa/horas necessrias ou requeridas para completar o projeto todo
(KARNER, 1993; DAMODARAN, 2003).
Schneider e Winters (1998 apud BENTE ANDA et al, 2001), afirmam que embora seja
sugerido o uso de 20 pessoas/hora por ponto de caso de uso experincias tem demonstrado que este
nmero tem variado entre 15 e 30 horas por ponto de caso de uso. Ainda sugerem que dependendo
dos fatores ambientais pode-se determinar pessoa/hora por pontos de caso de uso. Se o nmero de
fatores ambientais entre F1 e F6 (Quadro 9) for entre 3 e 4 o esforo de 28 pessoas/horas e se
54
passar de 4 o esforo de 36 pessoas/horas (RIBU, 2001, p.114; SCHNEIDER e WINTERS, 1998

apud BENTE ANDA et al, 2001).
Linhas de cdigo
A tcnica de mensurao por linhas de cdigo (LOC Lines of Code) uma das medidas
mais antigas para estimar o tamanho, esforo e, conseqentemente, produtividade no

desenvolvimento de software. Os dados obtidos por esta tcnica podem ser utilizados para
dimensionar cada elemento do software ou como mtricas advindas de dados histricos, oriundo de
projetos anteriores que podem ser utilizados para estimar esforo (PRESSMAN, 2006)
Nesta tcnica, aps a delimitao do escopo do projeto este decomposto em funes que
sero estimadas individualmente prevendo o nmero de linhas de cdigo-fonte por pessoa-ms.
Consiste na contagem da quantidade do nmero de linhas de cdigo de um programa de software
sendo de fcil automao, eliminando esforos manuais.
No entanto, cabe ressaltar que esta tcnica apresenta desvantagens como (SOMERVILLE,
2003):
O fato de que inexato ter que medir a produtividade de um projeto de desenvolvimento
com a sada de somente uma das fases (fase de codificao);
Experincia do desenvolvedor, pois o nmero de linhas de cdigo pode variar de pessoa a
pessoa;
Diferena entre linguagens (o nmero de linhas de cdigo de uma aplicao desenvolvida
em Cobol certamente diferente da quantidade de linhas de cdigo da mesma aplicao
desenvolvida em linguagem C);
Ausncia de padres de contagem, j que no h uma definio de certas caractersticas,
como a contagem de comentrios, declaraes de dados, e a incapacidade de medio do
tamanho de um sistema em fases iniciais de desenvolvimento, tornando o gerenciamento
do projeto um tanto quanto complicado.
Esta tcnica pode ser adotada para estimativas em sistemas embarcados que possuem a
linguagem de programao C (predominante), por exemplo. Tambm pode ser utilizada para o caso
55
de sistemas com programao Assembly. No caso de linguagens orientadas a objeto a aplicao da

tcnica se complica no sendo indicada.
COCOMO II (Constructive Cost Model)

Este modelo permite estimar esforo, prazo, tamanho e custo, necessrios para o
desenvolvimento de software, tendo como premissa o tamanho deste (BOEHM, MADACHY,

SELBY, 1995).
O COCOMO II apresenta como objetivos ser um modelo de estimativa para modelo de ciclo
de vida de software e prticas de desenvolvimento mais atuais; fornecer ferramentas de suporte e
melhoria contnua; prover um framework analtico, ferramentas e tcnicas que auxiliem na
avaliao de efeitos.
Este mtodo foi projetado para trabalhar com trs modelos em diferentes estgios
(PRESSMAN, 2006; SOMERVILLE, 2003):
Application composition - Prototipao: caractersticas externas do sistema so
projetadas. Neste estgio para estimar esforo por pontos de objeto recomendado.
Early design arquitetura: as estruturas fundamentais do software so projetadas no nvel
inicial do projeto. Para estimar o tamanho do sistema recomendado pontos por funo
(vide Anlise por pontos por funo).
Post architecture desenvolvimento: a arquitetura ser construda, ou seja, o sistema ser
criado. Neste estgio a estimativa apresenta maior preciso, pois h mais informaes
disponveis.
Neste sentido para cada estgio o COCOMO II sugere o clculo diferenciado de estimativas
atentando para as informaes existentes em cada um destes nveis, no intento de alcanar a melhor
preciso possvel.
Por ser uma evoluo do modelo COCOMO (BOEHM, 1981) para adaptar-se a evoluo
das tecnologias e novas formas de desenvolvimento que no COCOMO II foi inserido o nvel de
prototipao, buscando auxiliar na realizao da estimativa de esforo em projeto desta natureza e
56
projetos em que o desenvolvimento ocorre pela composio de componentes j existentes

(HUGHES & COTTERELL, 1999; FENTON e PFLEEGER, 1997; SOMERVILLE, 2003) .
Neste estgio baseia-se estimativa em pontos de objeto em relao produtividade estimada,
sendo que este depender da capacitao em ferramentas CASE e at experincia dos recursos
humanos que estaro envolvidos no desenvolvimento do projeto (SOMERVILLE, 2003).
Neste caso, o esforo (E) medido em pessoa/ms dado pela Equao 18.
E = (NPO * (1-%reuso/100))/PROD
Equao 18 - Clculo do esforo (Pessoa/ms)
Fonte: SOMERVILLE (2003); HUGHES & COTTERELL (1999)
Sendo que NPO o nmero de pontos de objeto, usado para estimar o tamanho de
aplicaes baseadas programao de banco de dados. Esta estimativa se baseia no nmero de telas
exibidas, no nmero de relatrios produzidos e nmero de mdulos na linguagem de programao.
Neste caso, estas devem ser classificadas de acordo com a sua complexidade. As telas exibidas
classificam-se com simples (1 ponto), moderadamente complexas (2 pontos) e muito complexas (3
pontos). No caso dos relatrios, estes so classificados como simples (2 pontos), moderadamente
complexos (5 pontos) e muito complexos (8 pontos). E por ltimo, os mdulos devem contar 10
pontos cada um dos necessrios no sistema. (CENTER, 2004).
O percentual de reuso refere-se ao percentual de reuso que se espera para aquele projeto,
pelo COCOMO h uma calibrao de 2,94. Em casos em que a empresa tenha outros sistemas
semelhantes, o percentual de reuso mede o quanto o projeto ser copiado ou modificado a partir de
produtos j existentes. (CENTER, 2004).
PROD a produtividade que pode ser obtida pelo Quadro 10, dependendo de cada empresa.
Experincia e capacitao do Desenvolvedor
Muito baixa
Baixa
Nominal
Alta
Muito Alta
Maturidade e capacitao de CASE

PROD
Muito baixa
4
Baixa
7
Nominal
13
Alta
25
Muito Alta
50
Quadro 10 - Obteno de produtividade

Fonte: Somerville (2003); Hughes & Cotterell (1999)
O nvel inicial do projeto h uma equao (19) considerada padro que adotada em que E
o esforo, A um coeficiente que de acordo com definio 2,5, o tamanho obtido por KSLOC,
57
B refere-se ao aumento do esforo medida que o projeto tambm aumenta (varia de 1,1 a 1,24) e
M refere-se a um conjunto de direcionadores de processos:
E = A * TB * M
Equao 19 - Frmula-padro para modelos algoritmos
Cabe destacar que estes direcionadores podem ser classificados em uma escala de 1 a 6
sendo 1 considerado muito baixo e 6 muito alto conforme percebe-se no quadro 11.
SIGLA
DESCRIO
RCPX
RUSE
PDIF
Confiabilidade e complexidade
do produto
Reuso requerido
Dificuldade de plataforma
PERS
PREX
SCED
FCIL
Capacitao pessoal
Experincia pessoal
Prazo
Recursos de suporte
MUITO
BAIXO
0,75
BAIXO
NORMAL
ALTO
1,09
MUITO
ALTO
1,13
EXTRA
ALTO
1,66
0,88
0,91
0,87
1
1
1,14
1,06
1,29
1,21
1,49
1,57
1,24
1,22
1,29
1,24
1,1
1,10
1,1
1,10
1
1
1
1
0,83
0,88
1
0,86
0,67
0,81
1
0,72
1
0,78
Quadro 11 - Direcionadores de clculo

Fonte: Hughes
& Cotterell (1999)
Neste caso o clculo de M dado por:

M = RCPX x RUSE x PDIF x PERS x PREX x SCED x FCIL
Equao 20 - Clculo do conjunto simplificado de direcionadores de processo
Assim, o clculo de esforo por pessoa-ms realizado conforme Equao 20 em que a

varivel PMm utilizada somente quando gerada automaticamente uma percentagem significativa
do cdigo. Assim este calculado separadamente conforme a Equao 21.
PMm = (ASLOC X (AT/100))/ATPROD
Equao 21 - Clculo do esforo (pessoa-ms)
58
Para entender a equao cabe dizer que o nmero de linhas de cdigo-fonte geradas
automaticamente definido por ASLOC; o nvel de produtividade dada por ATPROD; e AT
cdigo total do sistema automaticamente gerado.
O clculo do prazo (TDEV) obtido pela Equao 22.
TDEV = C x (PMF)
Equao 22 - Frmula para estimar prazo
Na equao, C uma constante calibrada no COCOMO como 3.67, PM o esforo

calculado e F definido como sendo
F = (D + 0.2 x (B - 1.01))
Equao 23 - Clculo do F
Fonte: SOMERVILLE (2003); Hughes & Cotterell (1999)
Neste caso D uma constante multiplicativa para tempo de desenvolvimento, calibrada

como 0.28 no COCOMO II; e B tem o mesmo valor da frmula para clculo de esforo (dado pelo
somatrio dos fatores de Escala. O TDEV expresso em quantidade de meses.
Os clculos referentes as estimativas do nvel ps-arquitetura ou desenvolvimento no so
apresentados por no fazerem parte do escopo deste trabalho que se preocupa com a estimativa no
processo de planejamento.
Estimativa em modelos geis

Neste tipo de processo sugere-se que a atividade de estimativa seja realizada da forma mais
simplificada e rpida possvel devido as suas caractersticas. Considera alguns aspectos como
clculo somente do que for necessrio, a heurstica funciona to bem quanto algoritmo, confiana
na equipe e a transparncia com o cliente.
Alm disso, devem ocupar apenas 50% do tempo da equipe quando alocando
funcionalidades, considerando tempo para design, discusso, retrabalho, alimentao, entre outros.
Outra questo refere-se a eventuais folgas que devem ser preenchidas com a implementao de
funcionalidades previstas para prxima iterao.
59
Os seguintes passos podem ser considerados (PRESMANN, 2006):
Cada cenrio considerado separadamente.
H uma decomposio do cenrio em conjuntos de funes e tarefas.
Cada tarefa ser estimada individualmente e como alternativa o tamanho do cenrio

pode ser estimado em pontos por funo, linhas de cdigo ou outro modelo que seja
orientado a volume.
As estimativas de tarefas relacionadas a um cenrio so somadas, e o tamanho do

cenrio pode ser passado para esforo usando dados histricos, sendo esta uma
alternativa.
Estimativas de todos os cenrios so somadas para apresentar o esforo de um

incremento de software.
Estimativas em mtodos geis trabalham com conceito de user stories que so pequenas
histrias contadas pelo usurio para identificao de requisitos de software. Com isto possvel
definir sem formalismos exagerados as necessidade do usurio (COHN, 2006).
Neste trabalho sero discutidas as tcnicas voltadas a modelos geis Planning Poker e
estimativa no planning game.
Planning Poker
Esta tcnica combina outras tcnicas como opinio especializada, analogia e desagregao
para realizar estimativas que resultam em estimativas rpidas e confiveis.

A figura 4 ilustra o processo de desenvolvimento desta tcnica (GRENNING, 2002; COHN,
2005).
60
Figura 4 - Estimativas no Planning Poker
Como se pode observar na Figura 4, a forma de realizar esta tcnica simples e pode ser
divida nas fases que seguem (GRENNING, 2002; COHN, 2005).
1.
Leitura da estria e uma discusso se necessrio para esclarecimentos pelo moderador.
2.
Cada estimador (envolve todos os desenvolvedores3 da equipe) escreve sua estimativa

em cartas ou recebe cartas com nmeros j impressos para determinar sua estimativa,
sem que haja discusses sobre esta com os demais.
3.
As cartas so viradas.
4.
Se h um consenso com relao a estimativa, esta registrada e parte-se para a prxima

estria. Mas caso haja discrepncias entre as cartas, os valores podem ser explicados por
seus estimadores e novas rodadas so realizadas, voltando ao passo 2, at que se chegue
a uma convergncia e enfim uma nova estria seja estimada.
Um ponto relevante est no fato de que sua utilizao tende a apresentar reutilizao das
cartas utilizadas para estimar em que consta o valor estimado para determinado parmetro em uma
atividade. Assim, a equipe de estimadores acaba por realizar mais rapidamente esta atividade para
casos de estrias familiares.
Compreende testadores, programadores, administradores de banco de dados, analista de sistemas, enfim todos os
integrantes da equipe do projeto.
61
Estimativa no planning game

Nesta tcnica so estimuladas reunies entre o cliente e os tcnicos usando quadros brancos,
com o objetivo de captar e definir as user stories que so estrias em que se apresentam textos
claros ou diagramas com notao UML com as especificaes de regras de negcios inerentes ao
sistema, alm de poder estimar o tempo ideal das interaes, o projeto como um todo, elaborar
estratgias e tentar prever as contingncias para projeto (MEDEIROS, 2008; WAKE, 2002).
A seguir tem-se os passos para que esta tcnica seja realizada de forma adequada (WAKE,
2002).
1. Cliente-usurio cria a stories que so escritas em cartes descries de requisitos do
sistema.
2. Realizao de uma reunio para que o cliente fale sobre cada estria e as priorize.
No caso da estimativa de durao, se esta exceder a durao de uma iterao, o

cliente deve quebrar a estria de forma que ela possa ser melhor estimada e caber
numa iterao. Voltar ao passo 1.
3. Programadores estimam o parmetro definido.
Quando h dificuldade em estimar sugere-se que seja realizado o spike solutions.

Neste os programadores implementam parte do que deve que apresentado na
stories, tendo assim noo e envolvimento com a soluo com intuito de ento
realizar uma boa estimativa.
4. O passo 2 deve ser realizado semanalmente ou quinzenalmente, sendo que o cliente

novamente aborda cada estria, podendo sugerir mudanas por meio de novas stories, e
tambm h a possibilidade das priorizaes determinadas serem modificadas.
Consideraes sobre os modelos/tcnicas de estimativas.

As tcnicas abordadas podem ser usadas em diferentes parmetros estimados, bem como
podem ser utilizadas em conjunto dependendo da necessidade.
62
Os modelos/tcnicas de estimativas Pert, estimativa por Analogia, Opinio Especializada,

Wideband Delphi podem estimar parmetros de durao, esforo e tamanho. Estas tcnicas
caracterizam-se por depender em alto grau do conhecimento do estimador, de dados histricos e
comparao com projetos semelhantes.
A Anlise por Pontos de Funo, Anlise por Casos de Uso e COCOMO II so consideradas
paramtricas e apresentam frmulas para obteno dos parmetros de estimativas desejados. Na
primeira tcnica possvel estimar tamanho, durao e esforo; a tcnica a seguir possibilita a
estimativa de esforo; e o modelo COCOMO II permite clculo da estimativa de durao e esforo.
As tcnicas de estimativas direcionadas aos modelos geis de desenvolvimento de sistemas
podem ser consideradas verses da tcnica Wideband Delphi por sua estrutura, embora apresentem
caractersticas prprias. Neste caso, podem estimar os trs parmetros abordados neste projeto:
tamanho, durao e esforo.
Pode-se considerar que todas as tcnicas possam ser aplicadas em MPEs de software, porm
o que mudar ser o grau de confiabilidade dependendo do quanto possui das caractersticas
necessrias para executar o modelo e/ou tcnica selecionada. Algumas empresas podem ter dados
histricos considerveis, outras podem possuir profissionais experientes, algumas podem estar
iniciando o processo. Quanto mais aplicarem estes modelos ou tcnicas melhor ser a estimativa
obtida.
A escolha da tcnica a aplicar depender das caractersticas de determinada MPE de
software e do tipo de projeto em que se deseja realizar o processo de estimativa de software. Neste
sentido, o guia pode auxiliar as MPEs a conhecer os modelos/tcnicas, aplic-los e verificar de
acordo com suas caractersticas o mais adequado a sua realidade.
2.3 PMBOK UM GUIA DO CONJUNTO DE CONHECIMENTOS EM

GERENCIAMENTO DE PROJETOS
O Guia PMBOK (2004) foi publicado pelo PMI Project Management Institute. O
PMBOK - Project Management Body Of Knowledge a documentao do estudo realizado por esta
instituio sendo um guia para os profissionais da rea (PMI, 2007b). Como objetivo, o PMBOK
identifica o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que
amplamente reconhecido como boa prtica. Alm disso, fornecer um vocabulrio comum com base
63
no qual se pode discutir, escrever e aplicar o gerenciamento de projetos, podendo ser utilizado por
qualquer profissional da rea.
O PMBOK possui cinco reas de especializao em que se encontram PMI (2004):
O Conjunto de conhecimento em gerenciamento de projetos referente ao conhecimento

especfico desta rea.
Conhecimento, normas e regulamentos da rea de aplicao. Neste caso, rea de

aplicao faz referncia a reas que se relacionam com o projeto, mas no esto
necessariamente presentes em todos os projetos. Normas so documentos em consenso e
aprovados por um rgo reconhecido e regulamentos so exigncias impostas pelo
governo.
Entendimento do ambiente do projeto: refere-se a levar em conta durante a execuo o

acompanhamento do projeto o contexto social, econmico, ambiental, alm dos
impactos positivos ou no e os intencionais ou no.
Conhecimento e habilidades de gerenciamento geral uma atividade essencial ao

gerente de projetos.
Habilidades interpessoais referem-se a capacidade de gerenciar relaes interpessoais

dadas as diferentes caractersticas pessoais existentes em um Projeto.
As reas de processo de gerenciamento de projetos esto distribudas e organizadas

conforme Figura 5 e compe os captulos de 4 a 12 do Guia PMBOK.
64
Figura 5 reas de conhecimento e processos de gerenciamento de projetos

Fonte: PMI (2004)
Na Figura 5 pode-se verificar as etapas de gerenciamento de projetos definidas no PMBOK,

sendo abordadas neste trabalho o gerenciamento do escopo do projeto, em que se apresenta os
processos envolvidos na verificao de que o projeto inclui apenas as tarefas necessrias para que
este seja concludo com sucesso; e o gerenciamento de tempo do projeto que apresenta processos
relacionados ao trmino do projeto no prazo previsto.
No PMBOK os processos so agrupados em cinco grupos de processos da gerncia de
projetos: o grupo de processos de iniciao composto por processos que iro auxiliar na
autorizao formal para dar inicio a um projeto ou a uma fase deste; o grupo de processos de
planejamento define objetivos e planeja atividades para o projeto; o grupo de processos de execuo
realiza integrao entre pessoas e recursos para executar o planejamento do projeto; o grupo de
processos de monitoramento e controle verifica alteraes no que foi planejado para a tomada de
65
aes corretivas; e o grupo de processos de encerramento que finaliza uma fase ou um projeto por
meio de um documento.
O grupo interesse deste projeto o grupo de processo de planejamento, que tem por objeto
planejar e gerenciar um projeto bem sucedido para a organizao baseado na interao dos
componentes do grupo (PMI, 2004). Neste, informaes relevantes so coletadas assim como
identificado, definido e amadurecido o escopo do projeto, o custo do projeto e so agendadas as
atividades do projeto que ocorrem dentro dele. A Figura 6 apresenta os componentes do grupo de
processo de planejamento.
66
Figura 6 - Componentes do grupo de Planejamento

Fonte: PMI (2004)
Os componentes com pontilhado em vermelho so as reas do grupo de planejamento que

so objeto deste trabalho, por serem responsveis por estimativas ou conterem informaes
importantes para realiz-las. Desta forma, torna-se relevante apresent-las de acordo com o Guia
PMBOK (PMI, 2004). Cabe destacar, que o guia PMBOK para cada processo referente a uma rea
apresenta entradas, ferramentas e sadas que se pretender obter ao final daquela etapa.
67
Planejamento do escopo (PMI, 2004)

Nesta rea deve-se criar um plano de gerenciamento do escopo de projeto documentando
como este ser definido, verificado e controlado e de que forma a EAP ser criada e definida.
O desenvolvimento do plano de gerenciamento do escopo do projeto e o detalhamento desse
escopo do projeto se iniciam pela anlise das informaes contidas no termo de abertura do projeto,
pela declarao do escopo preliminar do projeto, pela ltima verso aprovada do plano de
gerenciamento do projeto, pelas informaes histricas contidas nos ativos de processos
organizacionais e por quaisquer fatores ambientais relevantes para a empresa.
Como entradas necessrias para que seja possvel realizar o planejamento do escopo tem-se
fatores ambientais da empresa (por exemplo, cultura da organizao e infraestrutura), ativos de
processos organizacionais (so polticas, procedimentos e diretrizes formais e informais, pode-se
citar polticas organizacionais e informaes histricas), termo de abertura do projeto, declarao do
escopo preliminar do projeto e plano de gerenciamento do projeto.
Como ferramentas e tcnicas para obteno dos resultados pode-se citar Opinio
especializada, Modelos, formulrios, Normas (podem incluir modelos da EAP, modelos do plano de
gerenciamento do escopo e formulrios do controle de mudanas no escopo do projeto).
A sada esperada desta rea o plano de gerenciamento do escopo do projeto, que fornece
orientao sobre como o escopo do projeto ser definido, documentado, verificado, gerenciado e
controlado. Um plano de gerenciamento de escopo inclui um processo para preparar uma declarao
do escopo detalhada do projeto, com base na declarao do escopo preliminar do projeto; processo
que permite a criao da EAP e que determina como a EAP ser mantida e aprovada; processo que
especfica como sero obtidas a verificao e a aceitao formais das entregas do projeto; processo
para controlar como sero processadas as solicitaes de mudanas.
Definio do escopo (PMI, 2004)

Esta atividade essencial para o sucesso do projeto e prev o desenvolvimento de uma
declarao do escopo detalhada como base para futuras decises do projeto. O desenvolvimento da
definio do escopo ocorre a partir das principais entregas, premissas e restries, que so
documentadas durante a iniciao do projeto, na declarao do escopo preliminar do projeto.
68
As entradas definidas para esta atividade so Ativos de processos organizacionais, Termo de

abertura do projeto. Declarao do escopo preliminar do projeto, Plano de gerenciamento do escopo
do projeto, Solicitaes de mudana aprovadas (podem ocasionar uma mudana no escopo do
projeto, na qualidade do projeto, nos custos estimados ou no cronograma do projeto).
As ferramentas e tcnicas sugeridas so anlise de produtos (inclui tcnicas, como
decomposio do produto, anlise de sistemas, engenharia de sistemas, engenharia de valor, anlise
de valor e anlise funcional); identificao de alternativas (uma tcnica usada para gerar diferentes
abordagens para executar e realizar o trabalho do projeto e ainda as mais comuns brainstorming e
pensamento lateral); opinio especializada; anlise das partes interessadas (influncia e os interesses
das diversas partes e documenta suas necessidades, desejos e expectativas, seleciona, prioriza e
quantifica as necessidades, desejos e expectativas para criar os requisitos).
Entre as sadas para o processo de definio do escopo o PMBOK (2004) exige declarao
do escopo do projeto (descreve detalhadamente as entregas do projeto e o trabalho necessrio para
criar essas entregas, e ainda entendimento comum das partes interessadas). O documento inclui:
objetivos do projeto, descrio do escopo do produto, requisitos do projeto, limites do projeto,
entregas do projeto, critrios de aceitao de produtos, restries do projeto, Premissas do projeto,
organizao inicial do projeto, riscos iniciais definidos, marcos do cronograma, limitao de fundos,
estimativa de custos, requisitos do gerenciamento de configurao do projeto, especificaes do
projeto, requisitos de aprovao.
Outras sadas apresentadas so as mudanas solicitadas anteriormente que podem ser
desenvolvidas durante o processo definio do escopo; e o plano de gerenciamento do escopo do
projeto no caso de ser necessrias atualizaes no referido plano.
Criar EAP (PMI, 2004)

A EAP uma subdiviso das principais entregas do projeto e do trabalho do projeto em
componentes menores e mais facilmente gerenciveis, sendo uma decomposio hierrquica

orientada entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do
projeto e criar as entregas necessrias.
A criao da EAP organiza e define o escopo total do projeto representando o trabalho
especificado na declarao do escopo do projeto atual aprovada, sendo possvel agendar, estimar
69
custos, monitorar e controlar o trabalho planejado contido nos componentes de nvel mais baixo da
EAP, denominados pacotes de trabalho.
As entradas necessrias a criao da EAP so ativos de processos organizacionais,
declarao do escopo do projeto, plano de gerenciamento do escopo do projeto e solicitaes de
mudana aprovadas.
Como ferramentas e tcnicas para a criao da EAP so apresentados: os modelos da
estrutura analtica do projeto (uma EAP de um projeto anterior pode ser usada como um modelo
para um novo projeto) e a decomposio.
As sadas destacadas so atualizaes, se houver, da declarao do escopo do projeto, a
estrutura analtica do projeto, dicionrio da EAP, linha de base do escopo, atualizaes, se houver,
do plano de gerenciamento do escopo do projeto, mudanas solicitadas
Estimativa de recursos da atividade

De acordo com PMI (2004), define-se como o processo responsvel por estimar o tipo e a
quantidade de recursos envolvidos no projeto, necessrios para realizar cada atividade constante no
cronograma. Envolve determinar os recursos que podem ser pessoas, equipamento e/ou material, a
quantidade destes e ainda define quando estaro disponveis.
Para o processo de estimativa de recursos de atividades o PMBOK (PMI, 2004) apresenta as
seguintes entradas: fatores ambientais da empresa, ativos de processos organizacionais (fornecem as
polticas da organizao executora relativas a pessoal e a aluguel ou compra de suprimentos e
equipamentos que so consideradas durante a estimativa de recursos da atividade), lista de
atividades (identifica as atividades do cronograma para os recursos estimados), atributos da
atividade, disponibilidade de recursos, plano de gerenciamento do projeto.
Quanto as Ferramentas e tcnicas utilizadas nas estimativas de recursos de atividades o PMI
(2004) descreve opinio especializada (vide Seo 2.2.1.2), anlise de alternativas (muitas
atividades do cronograma possuem mtodos alternativos de realizao, incluem o uso de vrios
nveis de capacidade ou habilidades de recursos, tipos ou tamanhos diferentes de mquinas,
ferramentas diferentes e decises de fazer ou comprar relativas ao recurso), dados publicados para
auxlio a estimativas (empresas publicam rotineiramente os valores de produo e os custos
70
unitrios atualizados de recursos, material e equipamentos em diversos pases e locais geogrficos

dentro de pases), software de gerenciamento de projetos (tem capacidade para ajudar a planejar,
organizar e gerenciar pools de recursos e para desenvolver estimativas de recursos, as estruturas
analticas dos recursos, as disponibilidades de recursos e os valores dos recursos podem ser
definidos, alm dos vrios calendrios de recursos), estimativa bottom-up (vide Seo 2.2.1.1).
No processo de Estimativa de recursos da atividade pretende-se ao final ter como sada
(PMI, 2004) recursos necessrios para a atividade (identificao e descrio de tipos e quantidades
de recursos necessrios para cada atividade do cronograma em um pacote de trabalho.), atualizaes
de atributos da atividade (tipo de recurso necessrio caso haja alterao aprovada), estrutura
analtica dos recursos (EAR estrutura hierrquicas de recursos por categoria e tipo), atualizaes do
calendrio de recurso (documenta os dias trabalhados e os dias no trabalhados que determinam as
datas nas quais um recurso especfico, uma pessoa ou material, pode estar ativo ou ocioso;
normalmente identifica feriados especficos de recursos e perodos de disponibilidade de recursos; e
ainda identifica a quantidade de cada recurso disponvel durante cada perodo), mudanas
solicitadas (adicionar ou excluir atividades planejadas do cronograma da lista de atividades.).
Estimativa de durao da atividade

Este o processo necessrio para estimar o nmero de perodos de trabalho que sero
necessrios para terminar atividades do cronograma especficas. Utiliza-se de informaes

referentes a escopo de trabalho da atividade do cronograma, tipos de recursos necessrios,
estimativas das quantidades de recursos e calendrios de recursos com as disponibilidades de
recursos (PMI, 2004).
Os dados que sero utilizados para as estimativas de durao da atividade do cronograma
sero obtidos por meio da pessoa ou do grupo da equipe do projeto que est mais familiarizado com
a natureza da atividade do cronograma especfica que ser estimada.
O processo de estimativa de durao da atividade exige que a quantidade de esforo de
trabalho necessria para terminar a atividade do cronograma seja estimada, que a quantidade
prevista de recursos a ser aplicada para terminar a atividade do cronograma seja estimada e que o
nmero de perodos de trabalho necessrio para terminar a atividade do cronograma seja
determinado.
71
Todos os dados e premissas que do suporte estimativa de durao so documentados

para cada estimativa de durao da atividade. A durao total do projeto calculada como uma
sada do processo.
As entradas do processo de estimativa de durao de atividades so fatores ambientais da
empresa, ativos de processos organizacionais, declarao do escopo do projeto, lista de atividades,
atributos da atividade, recursos necessrios para a atividade (afetar a durao da atividade do
cronograma, pois os recursos atribudos atividade do cronograma, e a disponibilidade desses
recursos, iro influenciar de forma significativa a durao da maioria das atividades.), calendrio de
recurso (inclui a disponibilidade, capacidades e habilidades dos recursos humanos), plano de
gerenciamento do projeto, registro de riscos, estimativas de custos da atividade (se j terminadas,
podem ser desenvolvidas com detalhes suficientes para fornecer as quantidades de recursos
estimados para cada atividade do cronograma da lista de atividades do projeto.
Conforme o guia PMBOK (PMI, 2004), as ferramentas e tcnicas utilizadas para estimar a
durao de atividades podem ser opinio especializada (vide Seo 2.2.1.2), estimativa anloga
(vide Seo 2.2.1.1), estimativa paramtrica (vide Seo 2.2.1.1), estimativas de trs pontos (vide
Seo 2.2.1.1), anlise das reservas (As equipes de projetos podem optar por incorporar tempo
adicional, chamado de reservas para contingncias, reservas de tempo ou buffers ao cronograma
total do projeto como reconhecimento do risco do cronograma, o que pode ser um percentual da
estimativa de durao da atividade).
As sadas apontadas pelo guia como sendo as viveis para este processo so as estimativas
de durao da atividade, atributos da atividade (atualizaes), lista de marcos e mudanas
solicitadas.
O PMBOK define as atividades de planejamento de escopo, definio de escopo e criao
da EAP como atividades relevantes e que devem ser consideradas no processo de estimar, por isso
estas so definidas e suas entradas, ferramentas e sadas desejadas apresentadas.
Especificamente sobre estimativas o guia PMBOK define esta atividade para 2 parmetros
sendo estes recursos de atividades e durao de atividades. No sendo o guia especfico para a rea
de software as entradas, ferramentas e sadas dos processos referentes a estimativas devem ser
adequados para a rea em questo.
72
Relacionando com o guia proposto o PMBOK ressalta o parmetro de durao de atividade

desejvel no guia, bem como o processo de estimativa de recursos de atividades em que se pode
vislumbra o parmetro de esforo tambm necessrio a este guia.
2.4 MODELOS DE MELHORIA DE PROCESSO DE SOFTWARE

Neste capitulo sero abordados os modelos de melhoria de processo de software que sero
foco do guia de estimativas desenvolvido. Aspectos conceituais, formas de atuao e seus nveis,
assim como as prticas envolvidas nas estimativas de software sero apresentadas.
2.4.1 CMMI
O CMMI um framework com objetivo de melhorar os processos de uma organizao de
acordo com a capacidade e maturidade destes (SEI, 2002). Alm disso, a melhoria da capacidade de
gerenciar o desenvolvimento, aquisio e manuteno de produtos e servios constituem-se em uma
atividade fim deste modelo (SEI, 2002).
O CMMI for Development (CMMI-DEV) um modelo de referncia para as atividades de
desenvolvimento e manuteno aplicadas a servios e produtos. Baseado em abordagens
comprovadas pela indstria de software, o CMMI-DEV pretende auxiliar as organizaes a terem
conhecimento sobre seu processo, permitindo que elas possam avaliar a capacidade das diferentes
reas de seus processos e, como conseqncia, identificar seu grau de maturidade. (SEI, 2006).
Desta forma, possvel que as organizaes possam estabelecer programas de melhoria que
indiquem as prioridades para as melhorias e um caminho para melhor-las. (SEI, 2002). No Brasil
at o ano de 2008 foram vinte e uma organizaes obtiveram qualificao CMMI-DEV destas onze
com nvel 2, 4 com nvel 3 e 6 nvel 5. (MCT, 2006).
Os componentes do CMMI-DEV relacionados com este projeto so (SEI, 2006):
reas de Processo: conjuntos de prticas relativos a uma determinada rea que quando
realizadas possibilitam atingir metas melhorando o contexto em que esto inseridas.
o Objetivos Especficos: so caractersticas nicas que descrevem o que se deseja de
terminada rea de processo, sendo que devem ser atingidas para assegurar na avaliao que a
rea do processo esta sendo satisfeita.
73
Prticas Especficas: so atividades que necessitam ser realizadas para que os objetivos
sejam atingidos.
Produtos de Trabalho Tpicos: componentes informativos que oferecem modelos de
sada referentes a uma prtica especfica ou genrica
Sub-prticas: descries detalhadas que facilitam a interpretao de prticas
especficas ou genricas.
o Objetivos Genricos: objetivos que aparecem em vrias reas de processo. Quando
satisfeitos sinal de que houve melhoria no planejamento e implementao daquela
determinada rea de processo.
Prticas Genricas: oferecem recursos que possibilitam a certeza de que os processos
associados a determinada rea de processo sero eficientes, repetveis e durveis.
Sub-prticas: descries detalhadas que facilitam a interpretao de prticas
especficas ou genricas.
Elaboraes de Prticas Genricas: apresentam como as informaes devem ser
aplicadas em determinada rea de processo.
Com intuito de melhor interpretar os componentes do CMMI-DEV estes so agrupados em
3 categorias: componentes requeridos que so essenciais para que uma determinada rea seja
satisfeita (os objetivos especficos e genricos); componentes esperados: descrevem as atividades
que uma organizao dever executar para atender a um componente exigido (prticas genricas e
especficas); e componentes informativos que tm como objetivo auxiliar no entendimento dos
objetivos prticos e genricos e o que deve ser realizado para que estas possam ser satisfeitas (Subprticas, produtos de trabalho tpicos, definies ampliadas de disciplinas, elaboraes de prticas
genricas, ttulos de metas e prticas, notas de metas e prticas e referncias). (SEI, 2006).
74
Legenda
Figura 7 Componentes do modelo CMMI

Fonte: Adaptado de SEI (2006)
Pode-se perceber na Figura 7 os componentes do CMMI-DEV e a relao entre estes, alm

de sua categorizao, em que o retngulo representa componentes requeridos, o losango indica
componentes esperados e a elipse os componentes informativos.
O modelo CMMI-DEV utiliza duas abordagens representao contnua e em estgios e
deixa a disposio da organizao adequar-se a que se adequar melhor ao seu caso.
O nvel de representao em estgios apresenta a organizao um modelo em que cada etapa
realizada de uma vez, baseado em 5 nveis de maturidade. H um nvel inicial e para alcanar o
prximo nvel este deve ter sido avaliado por completo, ou seja, h uma ordem de execuo das
reas de processo. Neste caso, a organizao recebe uma pontuao nica no resultado da avaliao
de determinado nvel. Um nvel de maturidade consiste de prticas genricas e especficas
relacionadas a reas de processo pr-defindas que melhoraram o desempenho global da
organizao. A representao em estgio do CMMI-DEV possui 5 nveis de maturidade (SEI,
2006).
75
De acordo com SEI (2006), na representao contnua pode-se optar por melhorar apenas
um processo, ou seja, usa-se nveis de capacidade para medir cada rea de processo
individualmente. Neste caso no h uma pr-definio de seqncia, sendo que so seis os nveis de
capacidade.
O Quadro 12 apresenta os nveis de maturidade e capacidade e seus respectivos nveis
almejados para a certificao pelas organizaes.
Nveis
0
Representao em Estgios
Nveis de maturidade
No h
Iniciado: processo utilizado no
definido e no h controle efetivo deste.
Gerenciado: processo definido,
planejado e executado conforme poltica
da empresa.
Definido: a organizao passa a ter
processos
bem
caracterizados,
compreendidos e adotados, descritos por
meio de normas, ferramentas e mtodos.
Gerenciado
quantitativamente:
objetivos quantitativos para qualidade e
desempenho. Tcnicas quantitativas e
estatsticas
so
utilizadas
como
ferramentas de mtrica.
Em Otimizao: melhoria continua dos
processos.
1
2
Representao Contnua
Nveis de capacidade
Incompleto: objetivos especficos do
processo no necessitam ser satisfeitos.
Executado: objetivos especficos da rea
de processo em questo so satisfeitos.
Gerenciado: processo planejado e
gerenciado
conforme
polticas
da
organizao.
Definido: processo definido e adequado
padronizaes definidas e institudas
pela organizao.
Gerenciado quantitativamente: processo
gerenciado usando estatstica ou outras
tcnicas
quantitativas.
Definem-se
objetivos quantitativos para qualidade e
desempenho.
Em otimizao: processo gerenciado
qualitativamente e estando em melhoria
contnua
Quadro 12 - Nveis das representaes em estgio e contnua

Fonte: Adaptado de SEI (2006)
A escolha do tipo de representao, se em estgio ou contnua, depender da empresa, de

sua estrutura, de seus objetivos estratgicos (SEI, 2006).
Considerando que o foco deste trabalho concentra-se na rea de planejamento de projeto,
especificamente em atividades voltadas a estimativas de projetos de software, a rea de processo
definida no CMMI-DEV refere-se ao planejamento de projetos. Desta forma, considera-se o nvel 2
de maturidade para representao em estgio e nvel de capacidade 1 e 2 para representao
contnua.
76
O objetivo da rea de processo de planejamento estabelecer e manter planos que definem

atividades em projeto, para isso as seguintes atividades devem ser executadas: desenvolvimento do
plano de projeto, interao com stakeholders, comprometimento com o plano garantido e dar
manuteno no plano. (SEI, 2006). Desta forma, cabe apresentar os objetivos especficos referentes
a rea de processo de planejamento de projetos, considerando seus objetivos e prticas relacionadas
a estimativas (SEI, 2006).
O Objetivo especfico 1 Estabelecer Estimativas que contempla estimar e manter as
estimativas de escopo, de parmetros de produto de trabalho e atributos de tarefa, de esforo e de
custo do planejamento de projeto.
Ao realizar estimativas, o CMMI-DEV (SEI, 2006) sugere considerar alguns fatores
incluindo requisitos e escopo do projeto, as tarefas e produtos de trabalho identificados, abordagem
tcnica, modelo de ciclo de vida selecionado, atributos de produtos e tarefas (como tamanho),
cronograma, modelos ou dados histricos envolvendo horas trabalhadas e custo, modelos para
determinar esforo, durao, custo, recursos.
A documentao da estimativa com seus dados torna-se necessria para que os envolvidos
revisem e se comprometam com o plano e sua manuteno medida que o projeto progrida.
Para este objetivo so apresentadas as seguintes prticas especficas que devem ser
realizadas:
Prtica especfica 1.1 Estimar o escopo do projeto: nesta h a definio de uma work
breakdown structure (Estrutura Analtica do Projeto - EAP). Os produtos de trabalho
que devem ser resultados desta prtica so descrio de tarefas, descrio de pacotes
de trabalho e a EAP.
Prtica especfica 1.2 Estabelecer estimativas de produtos de trabalho e atributos de

tarefas: as estimativas devem estar coerentes com os requisitos do projeto. Para
estimar deve-se atribuir aos atributos (esforo, custo e cronograma) um grau de
complexidade ou dificuldade para que se tenha uma margem.
Prtica especfica 1.3 Definir ciclo de vida de projeto: as fases de um ciclo de vida
de projeto devem ser definidas em consonncia com o escopo, estimativas de
77
recursos e a natureza do projeto. O produto de trabalho resultante ser o ciclo de vida

de projeto e suas fases.
Prtica especfica 1.4 Determinar estimativa de esforo e custo: so obtidas

baseando-se em tcnicas ou dados de bases histricas. Produtos de trabalho desta
prtica so estimativas de custo e esforo do projeto.
Desenvolver um plano de projeto o Objetivo Especfico 2 que se refere a um documento

formal aprovado, usado para gerenciar e controlar a execuo do projeto. baseado nos requisitos e
estimativas estabelecidas. Para este objetivo as seguintes prticas especficas so referentes a este
trabalho e neste sentido so apresentadas:
Prtica especfica 2.1 Estabelecer o oramento e cronograma tendo como base as

estimativas desenvolvidas. Apresenta como produtos de trabalho cronograma do
projeto e suas dependncias e oramento do projeto.
Prtica especfica 2.4 Plano para recursos do projeto. Definem os recursos do projeto
como equipamentos, pessoas e materiais, bem como a quantidade destes para realizar
as atividades estimadas. Produtos de trabalho nesta prtica pacotes de trabalho da
EAP, dicionrio de tarefas da EAP, requisitos efetivos baseados em tamanho e
escopo de projeto, lista de equipamentos, definies e diagramas de processos, lista
de requisitos de administrao do programa.
Prtica especfica 2.7 Estabelecer o plano de projeto. Um documento que abrange

todos os itens relevantes do projeto. Produto de trabalho e plano de todo o projeto.
O Objetivo Genrico 1 nesta rea de processo atingir objetivos especficos e considera-se

apenas para na representao contnua. Este objetivo pretende transformar entradas identificveis
em produtos de sada tambm identificveis.
Apresenta a Prtica genrica 1.1 que determina: Realizar prticas especficas para
desenvolver produtos e servios a fim de alcanar os objetivos especficos da rea de processo.
Institucionalizar um processo controlado o objetivo Genrico 2 e apresenta as seguintes
prticas genricas, sendo que sero detalhadas aquelas que se referem a este trabalho:
78
Prtica genrica 2.1 Estabelecer uma poltica organizacional: esta prtica prev
estabelecer e manter uma poltica organizacional para planejamento e execuo do
processo de planejamento de projetos. Para tanto, esta deve estabelecer expectativas
organizacionais
para
estimar
os
parmetros
de
planejamento,
tornando
compromissos internos e externos, e o desenvolvimento do plano de gerenciamento

de projeto.
Prtica genrica 2.2 Planejar o processo: estabelecer e manter o plano para

executar processo de planejamento de projeto.
Prtica genrica 2.3 Fornecer recursos: apresentar recursos suficientes

realizao do processo de planejamento do projeto, desenvolvendo produtos de
trabalho, e facilitar a prestao dos servios. Alguns recursos como especialistas,
equipamentos e instalaes tornam-se necessrios ao planejamento de projeto e
podem exigir: estimadores experientes, especialistas tcnicos nas reas de domnio,
programas de planilhas, estimativas, planejamento de projeto e cronograma de
pacotes.
Prtica genrica 2.4 Atribuir responsabilidades: atribuir responsabilidade e

autoridade para executar o processo, desenvolvendo produtos de trabalho, e
prestando servios paro o processo de planejamento do projeto.
Prtica genrica 2.5 Treinar pessoas: capacitar recursos humanos necessrios a

realizao ou suporte ao processo de planejamento de projetos. Como exemplo,
pode-se citar treinamentos na atividade de estimativa, planejamento e cronograma.
Prtica genrica 2.6 Gerenciar configurao: inserir produtos de trabalho sobre

nveis de controle apropriados.
Prtica genrica 2.7 Identificar e envolver Stakeholders relevantes: Identificar e

envolver as stakeholders no processo de planejamento do projeto, tal como foi
planejado.
79
Prtica genrica 2.8 Monitorar e Controlar Processo: acompanhar e controlar o

processo de planejamento do projeto em contraponto ao plano que est sendo
executado e tomar as necessrias medidas corretivas.
Prtica genrica 2.9 Avaliar objetivamente aderncia: avaliar objetivamente a

aderncia do processo de planejamento de projeto em contraste com sua descrio,
normas e procedimentos.
Prtica genrica 2.10 Revisar com o nvel mais alto da gerncia: rever as
atividades, status e resultados do processo de planejamento de projeto com o nvel de
gerncia e resolver problemas.
Neste tpico so apresentados apenas os objetivos especficos e genricos relacionados ao

planejamento mais especificamente a atividade de estimar que o propsito desta dissertao. Neste
sentido, so discutidos objetivos especficos 1 e 2 e suas prticas especficas e os objetivos
genricos 1 e 2 e suas prticas genricas. Cabe ressaltar, que o objetivo genrico 2 estudado
visando o gerenciamento do processo de estimar proposto no guia de estimativa.
2.4.2 MPS.BR
MPS.BR v.1.2 (SOFTEX, 2007) um modelo de melhoria de software desenvolvido no
Brasil desde 2003 e que se baseia nas normas ISO/IEC 12207:1995/Amd 1:2002 e Amd
2:2004(IEEE/IEA, 1998), ISO/IEC 15504(ISO/IEC, 2005) e CMMI-DEV (SOFTEX, 2007). Este
programa tem como foco as micros, pequenas e mdias empresas que apresentam grande
dificuldades em seus processos atuais de desenvolvimento de software. Entretanto, o modelo pode
ser tambm utilizado por organizaes de outros portes e com caractersticas diferentes. (SOFTEX,
2007).
Com intuito de ser compatvel com padres e normas internacionais e que contenha
caractersticas relevantes da experincia dos modelos de melhoria de processos existentes, o
MPS.BR baseia-se em requisitos de processo j definidos que atendem aos princpios da Engenharia
de Software, bem como nas abordagens internacionais no que se refere a definio, avaliao e
melhoria de processo de software. Todos estes aspectos considerando que o foco deste programa
so as empresas brasileiras. (SOFTEX, 2007).
80
O modelo do MPS.BR est dividido em 3 componentes o Modelo de Referncia (MR-MPS),

o Mtodo de Avaliao (MA-MPS) e o Modelo de Negcio (MN-MPS), como se pode observar na
Figura 8.
Figura 8 Componentes do MPS.BR

Fonte: SOFTEX (2007)
Alm dos componentes percebe-se na Figura 8 guias e documentos que so prprios da

MPS.BR. No modelo MR-MPS encontram-se os requisitos que devem ser atendidos para estarem
em conformidade com este modelo. Ainda define os nveis de maturidade, processos e atributos
deste. Associado ao modelo MR-MPS tem-se o guia de aquisio que pretende auxiliar a adquirir
softwares e correlatos. (SOFTEX, 2007).
O processo e o mtodo de avaliao MA-MPS esto em conformidade a norma 15504-2. O
guia de avaliao associado a este componente contm o processo e o mtodo de avaliao MAMPS, os requisitos para os avaliadores lderes e adjuntos, bem como para as instituies
avaliadoras. (SOFTEX, 2007).
O Modelo de Negcio MN-MPS descreve regras de negcio para que seja possvel
implementar o MR-MPS, avaliar de acordo com o MA-MPS, organizar grupos de empresas para
implementar o MR-MPS e avaliar MA-MPS, certificao de consultores de aquisio e programas
anuais de treinamento por meio de cursos, provas e workshops MPS.BR. (SOFTEX, 2007).
81
O MPS.BR trabalha com sete nveis de maturidade que procura combinar os processos e sua
capacidade. Estes nveis representam patamares de evoluo de processo, sendo compreendidos
como estgios de melhoria da organizao no que se refere ao processo de software. O Quadro 13
apresenta os nveis de maturidade do MPS.BR, sendo que seus processos so descritos em termos
de propsitos e resultados esperados. Cabe destacar que o progresso entre os nveis de maturidade
ocorre apenas quando todos os propsitos e os resultados esperados de determinado nvel so
alcanados.
Nvel
Maturidade
Atributos de Processo
Otimizao
Gerenciado quantitativamente
Definido
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2,

AP 4.1, AP 4.2, AP 5.1 e AP 5.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2,
AP 4.1 e AP 4.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Largamente definido
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Parcialmente definido
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Gerenciado
AP 1.1, AP 2.1 e AP 2.2
Parcialmente gerenciado
AP 1.1 e AP 2.1
Quadro 13 - Nveis de maturidade do processo de gerenciamento de projetos MPS.BR

Fonte: SOFTEX (2007)
O nvel G de maturidade, chamado parcialmente gerenciado, compe-se pelos processos

Gerncia de Projetos e Gerncia de Requisitos, sendo que apenas o primeiro ser apresentado por
ser o foco deste trabalho. E neste caso, cabe destacar que os processos deste nvel devem satisfazer
os atributos de processo 1.1 e 2.1, que determinam que neste nvel as organizaes possam
estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem
como prover informaes sobre o andamento do projeto que permitam a realizao de correes
quando houver desvios significativos no desempenho do projeto (SOFTEX, 2007).
No nvel G referente ao processo de Gerncia de Projetos (GPR), os processos de
planejamento e monitorao de projetos esto em um nico processo. Os resultados esperados que
se referem as estimativas apresentados no MPS.BR (SOFTEX, 2007) so:
GPR 1. O escopo do trabalho para o projeto definido: o escopo o ponto de partida
para o planejamento de projeto e define todo o trabalho necessrio para que se entregue
82
um produto e/ou servio que atenda as necessidades, caractersticas e funes

especificadas para o projeto para que seja finalizado com xito. A representao do
escopo pode ser realizada por meio de uma Estrutura Analtica do Projeto (EAP), que
fornece um esquema para identificao e organizao dos pacotes de trabalho que so as
unidades lgicas de trabalho a serem gerenciadas. Outras forma de implementar o escopo
por meio de um documento de Viso ou outro documento que o defina.
GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados

utilizando mtodos apropriados: a partir do escopo do projeto os produtos de trabalhos
e tarefas do projeto so decompostos em componentes menores, sendo mais facilmente
gerenciveis e dimensionados, como exemplo de decomposio tem-se a EAP. Cabe
destacar que, a decomposio fornece uma referncia para a atribuio de tamanho,
esforo, cronograma e responsabilidades, e utilizada como uma estrutura subjacente
para planejar, organizar e controlar o trabalho executado no projeto. O tamanho a
principal entrada de muitos modelos utilizados para estimar o esforo, custo e
cronograma. Assim, este resultado diz respeito estimativa de tamanho, sendo este
conceituado como sendo a dimenso das funcionalidades sob o ponto de vista do
usurio. Para obt-lo pode-se utilizar diferentes tcnicas que envolvem contagem das
tabelas internas e externas ao sistema, classes, objetos, relatrios, telas, consultas a
banco de dados, clculos, transaes e atores dos casos de uso, linhas de cdigo, entre
outros. No entanto, importante enfatizar que o uso de uma tcnica deste tipo no
exigido no nvel G do MPS.BR. Neste nvel, a estimativa de escopo, produtos e tarefas
pode ser feita baseada na complexidade, no nmero de requisitos ou no uso da EAP
juntamente com dados histricos e a experincia em projetos anteriores.
GPR 4. Define que at o nvel F o esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados histricos ou
referncias tcnicas; a partir do nvel E o planejamento e as estimativas das
atividades do projeto so feitos baseados no repositrio de estimativas e no
conjunto de ativos de processo organizacional. Estimativas de esforo e custo so,
normalmente, baseadas nos resultados de anlises utilizando modelos e/ou dados
histricos aplicados ao tamanho, atividades e outros parmetros de planejamento. Cabe
salientar que os dados histricos incluem os dados de custo, esforo e tempo de projetos
83
executados anteriormente, alm de dados apropriados de escala para equilibrar as

diferenas de tamanho e complexidade. As estimativas do escopo, produtos de trabalho e
as tarefas estimadas para o projeto so afetadas pelos parmetros de produtividade,
resultando nas estimativas de esforo e custo. Os parmetros de produtividade so
baseados em dados histricos e devem ser periodicamente calibrados. Os parmetros de
produtividade podem ter valores diversos, conforme fatores como experincia do
profissional, grau de ineditismo do servio para a organizao ou para os profissionais
alocados.
GPR 5. O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de
controle, so estabelecidos e mantidos: neste item as dependncias entre tarefas so
estabelecidas e potenciais gargalos so identificados utilizando mtodos apropriados. Os
gargalos so resolvidos quando possvel, e o cronograma das atividades com incio,
durao e trmino estabelecido. Com base na EAP e nas estimativas de esforo e custo
(GPR4), o cronograma definido, considerando as dependncias entre as tarefas e os
marcos e/ou pontos de controle (eventos significativos no mbito do projeto).
importante ter-se o cuidado de manter a coerncia entre ciclo de vida, EAP, estimativas e
cronogramas.
A capacidade de processo no MPS.BR (SOFTEX, 2007) representada por um conjunto de
atributos de processo que so descritos por meio de seus resultados esperados. Neste caso, cabe
apresentar os atributos de processo referentes ao Gerenciamento de Projeto nvel G.
No atributo de processo 1.1 o processo executado, sendo que este atributo uma medida
do quanto o processo atinge o seu propsito. Como resultado esperado tem-se o RAP 1. em que se
espera que o processo transforme produtos de trabalho de entradas identificveis em produtos de
trabalho de sada, tambm identificveis, permitindo atingir o propsito do processo. Este resultado
implica na gerao dos principais produtos requeridos pelos resultados dos processos.
O atributo de processo 2.1 garante que o processo seja gerenciado. Este atributo uma
medida do quanto a execuo do processo gerenciada e est ligado gerencia de processos. Este
atributo apresenta uma srie de resultados esperados, sendo destacados os relacionados ao tema
deste trabalho:
84
RAP 3. A execuo do processo planejada: criao de um plano para execuo do

processo incluindo recursos, responsabilidades, tempo, atividades de controle e
monitoramento da execuo do processo. Este plano deve ser estabelecido e
documentado. A reviso do planejamento deve ser realizada sempre que necessria.
RAP 4 (Para o Nvel G). A execuo do processo monitorada e ajustes so

realizados para atender aos planos: pretende monitorar a execuo dos processos de
acordo com o planejado e assegurar que aes corretivas sejam tomadas quando desvios
significativos forem identificados. As revises das atividades, estado e resultados dos
processos devem ser realizadas, podendo ocorrer periodicamente ou devido a algum
evento.
RAP 5. Os recursos necessrios para a execuo do processo so identificados e

disponibilizados: assegura que os recursos necessrios para executar o processo sero
identificados previamente e estaro disponveis quando forem necessrios. Incluem
recursos financeiros, condies fsicas adequadas, pessoal e ferramentas apropriadas
(incluindo processos e modelos de documentos predefinidos).
RAP 6. As pessoas que executam o processo so competentes em termos de

formao, treinamento e experincia.
RAP 7. A comunicao entre as partes interessadas no processo gerenciada de

forma a garantir o seu envolvimento no projeto.
RAP 8. Mtodos adequados para monitorar a eficcia e adequao do processo so

determinados.
Este tpico destinou-se ao estudo especfico das atividades do nvel G em que se encontram
o processo de Gerncia de Projetos (GPR), os processos de planejamento e monitorao de projetos.
Desta forma, so descritos os resultados esperados por este nvel referentes a atividade de estimar e
atributos de processo desejados. Os resultados esperados referentes ao processo gerenciado so
destacados para a proposta de gerenciamento da atividade de estimativa no guia desenvolvido.
85
2.4.3 Norma ISO/IEC 15504

Outra abordagem que fornece um framework para melhoria de processos a norma ISO/IEC
15504-5 (ISO/IEC, 2005), que possibilita planejamento, administrao, monitoramento, controle e
fornece recursos que auxiliam na aquisio, desenvolvimento, operao, avaliao e suporte ao
produto.
O uso desta norma pode ser realizado em toda ou parte de uma organizao tendo-se
diferentes objetivos: entender os processos e melhor-los; determinar a adaptabilidade de processos
prprios para um requisito ou uma classe desses; ou ainda determinar a adaptabilidade de processos
de outras organizaes para um contrato ou uma classe deste.
A verso de 2005 da norma ISO/IEC 15504 possui cinco componentes em sua estrutura
como est sendo apresentado na Figura 9.
Figura 9 Componentes da ISO/IEC 15504

Fonte: ISO/IEC Std. 15504 (2005)
86
A parte 1 (informativa) descreve como as partes da norma se relacionam e fornece

orientao sobre sua seleo e utilizao; j a parte 2 (normativa) define um modelo bidimensional
que descreve processos e capacidades usadas na avaliao de processos; a parte 3 (normativa)
define os requisitos para a execuo da avaliao; na parte 4 (informativa) apresenta-se um guia
para uso da avaliao de processo para o objetivo da melhoria de processo e determinao de
capacidade; e a parte 5 (informativa) descreve um exemplo de um modelo para a execuo de
avaliaes de processos que baseado e compatvel com o modelo de referncia do ISO/IEC
15504-2.
A norma apresenta 6 nveis de capacidade (representao contnua) conforme apresentao
no Quadro 14, em que para cada nvel tem-se atributos de processo (AP) relativo e aos quais so
apresentadas prticas genricas (indicadores atividades genricos que fornecem orientaes com
relao aplicao dos atributos de processo); recursos genricos (recursos que podem necessrios
quando um processo executado para alcance do AP); e produtos de trabalho genricos
(caractersticas que se espera obter como resultado final evidente de um AP).
Nvel
Capacidade
Em otimizao: melhoria contnua de processo.
Previsvel: medio e controle do processo.
Estabelecido: o processo estabelecido, bem como,

seus recursos.
Gerenciado: processo criado gerenciado bem como

os produtos de trabalho so devidamente
estabelecidos, controlados e mantidos.
Executado: o processo implementado.
Incompleto: no h processo implementado.

Quadro 14 - Nveis de capacidade ISO/IEC Std. 15504
Fonte: ISO/IEC Std. 15504 (2005)
Por este trabalho focar a rea de gerncia de projetos sero apresentadas as caractersticas do
grupo de processo MAN. 3 (Management Process Group) e do nvel 2 de capacidade desta norma.
O grupo de processo MAN. 3 tem como objetivo o gerenciamento de projetos que pretende
identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos necessrios ao
projeto para produo de produto ou servio de acordo com os requisitos e restries (ISO/IEC Std.
15504, 2003). Como resultados de processo (RP) deste grupo e relacionada a rea de planejamento
87
com o foco em estimativa tem-se: Definio do escopo do projeto e as tarefas e recursos necessrios
so dimensionados e estimados.
A norma ISO/IEC Std. 15504-5 (2003) destaca tambm Prticas Bases que devem ser
realizadas, sendo que aqui so apresentadas as que possuem referncia a estimativa de software.
Prtica Base 1: Definir o escopo do trabalho (RP 1).
Prtica Base 4: Determinar e manter estimativas para os atributos do projeto (RP 2 e 3).
Prtica Base 5: Definir atividades e tarefas do projeto (RP 3).
Prtica Base 7: Definir cronograma projeto (RP 5).
Com relao aos nveis de capacidade a gerncia de projetos est associada ao nvel 2, sendo
este apresentado juntamente com seus atributos de processo (AP). No nvel 2 o processo
gerenciado considerando planejamento, monitorao e ajuste, alm de que seus produtos de trabalho
estabelecidos, controlado e mantidos. Quanto aos atributos de processos referentes ao nvel 2 ser
descrito o 2.1 referente a atividades de planejamento e ligados a estimativa.
O atributo de processo 2.1 refere-se a gerenciamento de desempenho que uma medida de
como o processo gerenciado. Tem-se como resultados deste AP:
Identificao dos objetivos para a execuo do processo.
Planeja-se o desempenho do processo, bem como seu monitoramento.
Com intuito de atender ao plano o desempenho do processo ajustado.
Os responsveis pela execuo do processo so definidos e comunicados.
As informaes e recursos que so necessrios realizao do processo so

identificados, disponibilizados, alocados e utilizados;
Gerenciamento da comunicao entre as partes envolvidas, bem como a atribuio de

responsabilidades.
88
Para os atributos de processo apresentados existem prticas genricas, recursos genricos e

produtos de trabalho genricos.
Prtica genrica 2.1.1: identificao dos objetivos para a execuo do processo. Alm da
identificao de objetivo, o escopo do projeto definido restries ao projeto so
consideradas.
Prtica genrica 2.1.2: planejamento e monitorao do processo para cumprir objetivos

identificados. Nesta prtica, planos para o processo so desenvolvidos assim como o
ciclo do processo definido. Tambm se estabelece marcos e estimativas so
determinadas e mantidas. Atividades e tarefas possuem seu processo definido, alm de
que cronograma tambm estabelecido. O processo deve ser realizado conforme o plano
e monitorado para garantir o resultado desejado.
Prtica genrica 2.1.3: ajuste do processo, em que todas as atividades relativas ao

processo so avaliadas e questes preocupantes so identificadas. Para os casos em que
objetivos no so alcanados, aes so tomadas a fim de garantir o almejado, ajustando
sempre que necessrio o plano.
Prtica genrica 2.1.4: definio de responsveis para realizao do processo.
Prtica genrica 2.1.5: identificar e colocar a disposio os recursos necessrios para o

processo de acordo com o plano, tanto recursos humanos quanto de infra-estrutura. O
mesmo acontece com as informaes relevantes.
Prtica genrica 2.1.6: gerenciar a comunicao entre as partes envolvidas no processo.

Nesta fase estas pessoas so determinadas, assim como as responsabilidades que lhe
cabem. A comunicao entre os envolvidos garantida e efetivada.
O grupo de processo MAN3 voltado ao gerenciamento de projetos e seus resultados de

processos so apresentados neste tpico por estarem relacionados a atividade de estimativa. Alm
destes, prticas bases e atributo de processo 2.1 e as prticas genricas referentes, todos descrevem
atividades que devem compor o processo de estimativa de software inclusive o seu gerenciamento
que so foco do guia desenvolvido neste trabalho.
89
2.4.4 Consideraes sobre os modelos

Pode-se perceber algumas caractersticas dos modelos apresentados: o CMMI-DEV
apresenta duas abordagens a representao contnua com 6 nveis de capacidade e em estgios com
5 nveis de maturidade, o MPS.BR apresenta uma representao com 6 nveis de maturidade e a
ISO/IEC 15504-5 possui uma representao com 6 nveis de capacidade. Embora tenham suas
caractersticas especficas os modelos seguem um padro j que todos trabalham com nveis.
Por outro lado, a forma como os nveis so abordados em cada modelo os faz diferentes. Na
abordagem contnua pode-se escolher um processo para ser avaliado, j na representao em
estgios tem-se que atender a um conjunto de processos para avanar nos nveis que seguem.
Uma percepo em todos os modelos que estes tm como objetivo fornecer apenas
indicaes do que deve ser realizado, mas no de como fazer ou at os melhores modelos/tcnicas a
serem utilizados. Principalmente no que se refere a estimativa, percebe-se uma escassez de
informaes.
O Quadro 15 relaciona as atividades referentes a estimativa existentes nos modelos de
melhoria de processo, apresentando correlaes e discrepncias nas tarefas exigidas. Cabe destacar,
que escopo e cronograma, so destacados no quadro por serem atividades relacionadas ao processo
de estimar considerando os parmetros que fazem parte deste trabalho tamanho, durao e esforo.
90
CMMI-DEV v. 1.2
MPS.BR v. 1.2
ISO/IEC 15504-5:2203-2006
Prtica especfica 1.1 Estimar o
GPR 1. O escopo do trabalho para
Prtica Base 1: Definir o escopo
escopo do projeto
o projeto definido;
do trabalho (RP 1).
1.2
GPR 2. As tarefas e os produtos
Prtica Base 4: Determinar e
de
de
manter
Prtica
especfica
Estabelecer
produtos
estimativas
de
trabalho
atributos de tarefas
Prtica
do
projeto
dimensionados
so
utilizando
estimativas
para
os
atributos do projeto (RP 2 e 3).
mtodos apropriados;
especfica
Determinar
trabalho
1.4
estimativa
GPR 4. Define o esforo e o custo
de
para a execuo das tarefas e
esforo e custo
produtos
de
trabalho
so
estimados com base em dados

histricos ou referncias tcnicas;
Prtica
especfica
Estabelecer
2.1
oramento
GPR
5.
oramento
cronograma do projeto, incluindo
cronograma tendo como base as
Base
7:
Definir
marcos e/ou pontos de controle,
estimativas desenvolvidas
Prtica
so estabelecidos e mantidos;
cronograma projeto (RP 5)
Quadro 15 - Relao CMMI-DEV / MPS.BR / ISO/IEC 15504-5
Os modelos apresentados destacam a definio de escopo como atividade inicial para no que
se refere ao processo de estimar. Alm disso, em todos tambm possvel observar a determinao
de estabelecimento de estimativas de produto de trabalho e atributos de trabalho, sugerindo o uso de
tcnicas adequadas.
Os modelos destacam a necessidade e importncia de estimar, alm do que deve ser
estimado. No entanto, no apresentam qualquer informao de quais ferramentas e tcnicas
existentes que auxiliam a realizao da atividade de estimar ou como estas devem ser aplicadas.
Pode-se perceber que estes modelos apresentam aspectos relevantes para a melhoria de processos de
software, mas no so suficientes como guias por no descreverem como tais atividades devem ser
executadas.
91
3 CONTEXTUALIZAO DO TRABALHO: MICRO E

PEQUENAS EMPRESAS
O objetivo deste captulo apresentar as micro e pequenas empresas de software no Brasil,
sua classificao, caractersticas referentes a gerncia de projetos, adoo de processos de software
e enfoque na rea de planejamento. Estes aspectos serviro de base para a criao do guia de
estimativas proposto neste trabalho.
3.1 MPES DE SOFTWARE BRASILEIRAS

Existem no Brasil cerca de 5,1 milhes de empresas, sendo que destes 98% so micro e
pequenas empresas (MPEs). O crescimento foi de 22,4% entre os anos de 2000 e 2004, sendo que
dos 924 mil novos estabelecimentos, 99% so de MPEs. A Tabela 2 apresenta dados a respeito do
crescimento dos setores por atividades, destaca-se que as maiores taxas de expanso esto nos
segmentos que possuem atividades associadas modernizao da sociedade. Cabe destacar que
entre as atividades de Servios tm-se os relativos informtica e destaca-se entre as atividades de
comrcio, material e equipamento de informtica (SEBRAE, 2006).
Tabela 2 - Setores de atividades MPEs (2000 - 2004)
SETOR
Servios
Comrcio
Indstria
Taxa de expanso
deMPEs
28,4%
21,5%
12,9%
Participao relativa
28,1% 29,6%
56,4% 56,1%
15,4% 14,3%
Fonte: (SEBRAE, 2006)
Ainda, dentre as atividades relacionadas ao setor de servios verifica-se que as atividades de

informtica correspondem a 81,2% deste segmento (IBGE, 2003).
O SEBRAE (2006) classifica o porte das MPEs para o setor de comrcio e servios de
acordo com o nmero de empregados conforme est apresentado no Quadro 16.
Porte/Setor
Microempresas
Empresas de pequeno porte
Mdias
Grandes
Comrcio e Servios
At 9 empregados
De 10 a 49
De 50 a 99
100 ou mais
Quadro 16 - Classificao das MPEs quanto ao porte

Fonte: SEBRAE (2008)
O Grfico 1 apresenta, de acordo com pesquisa do MCT (2005), o porte das empresas entre
os anos 1995 a 2004 considerando a fora de efetiva de trabalho.
Grfico 1 - Porte das empresas considerando a fora efetiva de trabalho
Pode-se percebe pelo grfico o ndice maior de existncia de MPEs no contexto de porte das
empresas. O grfico tambm demonstra que h uma mdia na quantidade de empresas se observado
separadamente cada porte.
De acordo com dados do SEBRAE (2004) as MPEs representam 20% do PIB nacional,
considerando o nmero de empresas no pas so 99% destas, alm de possurem 56% da fora de
trabalho e cerca de 2% destas empresas no cenrio nacional realizam exportaes.
93
3.2 CARACTERSTICAS DE MPES DE SOFTWARE

Independente do setor de atividade percebe-se que as MPEs apresentam um cenrio em que
se tem capital, insumos e mo de obra em baixas escalas (SEBRAE, 2006). Os dados do SEBRAE
(2005) e IBGE (2003) apresentados a seguir demonstram algumas outras caractersticas de MPEs
visveis tambm naquelas que possuem software como negcio:
H uma informalidade considerada alta neste tipo de empresa sendo que em 2005 havia
10,3 milhes de micro negcios informais. Dados de pesquisa SEBRAE (2002) davam
conta de 4,9 milhes de micro e pequenas empresas formais. Acredita-se que esta
informalidade se deve a dificuldade em abrir e fechar um negcio devido a burocracia e
as taxas recorrentes disto, pois no h uma tributao adequada e diferenciada para
empresas destes portes.
Destaca-se tambm a alta Mortalidade destas empresas: so 49,4% com at dois anos de
vida; 56,4% com at trs anos de vida; e 59,9% com at quatro anos de existncia.
Dificuldade de acesso a financiamentos de capital de giro, pois estes so inadequados a

este tipo de empresa.
Baixa intensidade de capital.
A baixa competitividade tambm observada nas MPEs em que faziam parte de apenas
2,4% das exportaes totais das empresas industriais em 2003.
Baixo uso de melhores prticas e ferramentas de gesto empresarial.
Baixo investimento em inovao tecnolgica;
Estreito vnculo entre os proprietrios e as empresas, no se distinguindo, principalmente

em termos contbeis e financeiros, pessoa fsica e jurdica;
Contratao direta de mo-de-obra;
Utilizao de mo-de-obra no qualificada ou semiqualificada;
Relao de complementaridade e subordinao com as empresas de grande porte.
Tais caractersticas no que se refere s empresas de desenvolvimento de software podem

evidenciar em baixa qualidade de produto e processo, principalmente as referentes a capital, baixo
investimento em prticas, ferramentas de gesto e inovao tecnolgica.
94
Em pesquisa do PMI (2007a) foram pesquisadas 184 empresas sendo que 37% so MPEs.
Do total de empresas pesquisadas 32% so da rea de tecnologia da informao. A Tabela 3
apresenta dados da pesquisa referente a aspectos relacionados a gerncia de projetos como
planejamento, uso de metodologias e ferramentas, alm das dificuldades encontradas nesta rea.
Nos dados apresentados foram considerados aqueles relevantes para este trabalho e seus objetivos.
Tabela 3 - Dados pesquisa gerenciamento de projetos (GP)
Atividade
% Empresas
Planejam na maioria das vezes
51,5%
Controlam na maioria das vezes
43,5%
Dedicao ao Gerenciamento de projetos (GP) em tempo

integral
53,5%
A organizao conhece e utiliza modelos de maturidade em

GP
39,5%
Adoo de Modelos de maturidade em GP
23,5%
Uso de metodologia pela rea de TI
22%
Aspectos da Metodologia de GP
Prazo
95%
Escopo
94%
Profissionais com PMI

24,5%
Nenhum
57%
Entre 1 e 3
Softwares para GP
MS-Project (Stand Alone, sem integrao)
40%
Software desenvolvido internamente
16%
MS-Project (Soluo EPM, integrado)
12%
Funcionalidades das ferramentas

Cronograma
93 %
EAP
66 %
Problemas com mais freqncia

Prazo
75%
Mudanas de escopo constantes
71%
Escopo no definido adequadamente
71%
Estimativas incorretas ou sem fundamento
29%
Fonte: PMI (2007a)
95
Cabe ressaltar que mais da metade das empresas consideradas diz fazer uso de aspectos do
gerenciamento de projeto como planejamento e controle, possuem profissional certificado em PMI,
consideram na metodologia adotada prazo e escopo, porm percebe-se que ainda assim apresentam
entre seus mais freqentes problemas o atendimento ao prazo e aspectos relativos a incorrees nas
estimativas.
Neste sentido, percebe-se um contraponto uma vez que o percentual nos problemas
ocorridos com freqncia bem alto e assume-se que ao se adotar e aplicar corretamente
metodologias voltadas a gerncia de projetos a realidade deveria ser diferenciada.
No entanto, pode-se considerar que parte desta condio deve-se aos apenas 23,5% de MPEs
totais pesquisadas que adotam um modelo de maturidade em gerncia de projetos. Alm disso, de
acordo com a pesquisa (PMI, 2007) 25% das empresas no conhecem qualquer modelo de
maturidade.
Percebe-se tambm que as empresas utilizam softwares para gerenciamento de projeto e
entre as funcionalidades mais utilizadas esto as relacionadas a criao e controle de cronograma e
criao da EAP. No se encontrou entre as atividades realizadas por meio das ferramentas citadas
estimativas de projetos de software.
Em relao adoo dos modelos de melhoria de processo de software (CMMI, ISO/IEC
15504 e MPS.BR) a Tabela 4 apresenta dados obtidos na pesquisa MCT (2005), referentes a
utilizao de modelos de melhoria de processos de software a norma ISO/IEC 15504, CMMI,
MPS.BR pelas empresas de software.
Tabela 4 - Utilizao dos modelos de melhoria de processo em MPEs
Norma ISO/IEC
15504 (%)
CMMI
MPS.BR
Usa sistematicamente
0,65
2,5
2,3
Comea a usar
No usa
No conhece
Total
5,55
69,9
23,9
100
15,8
66,9
14,9
100
13,7
61,4
22,6
100
Fonte: MCT (2005)
Percebe-se pelos dados apresentados na Tabela 4 que h uma fraca incidncia no uso efetivo
destes modelos pela empresas pesquisadas. Outro fator que merece destaque o percentual de
96
empresas que no conhecem os modelos citados na pesquisa compactuando com as caractersticas

observadas das MPEs em que h baixo investimento no uso de melhores prticas e ferramentas de
gesto.
Embora na rea de software saiba-se da relevncia da realizao adequada de estimativas
pode-se observar no Grfico 2 que a realidade no condiz com os dados apresentados.
Grfico 2 - Utilizao de estimativas por empresas de software

Fonte - MCT (2001)
Os dados apresentados no grfico podem estar relacionados ao fato de que em geral no

universo de estimativas de software estas apresentam problemas na tentativa de realiz-la de forma
mais acertada possvel.
Neste sentido, pode-se perceber que considerando caractersticas gerais as MPEs possuem
baixo capital de giro, no adotam ou investem em boas prticas e tecnologias e no possuem Mode-obra qualificada. No que se refere a gerncia de projetos suas principais dificuldades esto na
fase de planejamento de projetos destacando-se problemas no atendimento a prazos e erros em
estimativas. Aliado a isto grande parte destas no realizam o processo sistemtico de estimar
esforo ou tamanho. Ainda apresentam baixa adeso aos modelos de melhoria de processo de
software.
97
Cabe ressaltar que estas caractersticas justificam a criao do guia proposto neste trabalho,
corroborando para incentivo a prtica de realizar estimativas e adeso aos modelos de melhoria de
processo e as boas prticas.
98
4 ESTADO DA ARTE E DA PRTICA

Este captulo demonstra o estado da arte e prtica atualmente referente a guias para
implantao de processos de estimativa em projetos de software principalmente voltados para
MPEs. Para a realizao de uma anlise sistemtica so apresentados requisitos desejveis que
foram identificados com base na caracterizao deste contexto para o guia de estimativas proposto e
uma anlise dos guias j existentes por meio de descrio destes e comparao aos requisitos
elencados para o guia que est sendo proposto.
Em se tratando de um guia de estimativas para MPEs de Software que esteja alinhado aos
modelos de melhoria de software (CMMI-DEV, MPS.BR, ISO/IEC 15504-5) e tenha como base o
PMBOK, so considerados os seguintes requisitos desejados para este guia que so observados na
anlise dos trabalhos j existentes.
REQ 01. Definir modelos/tcnicas de estimativas adequados as MPEs de software.
REQ 02. Listar e descrever os principais modelos/tcnicas de estimativas de software.
REQ 03. Apresentar como os modelos/tcnicas de estimativas de software devem ser aplicados.
REQ 04. Identificar critrios de escolha as quais caractersticas de MPEs cada modelo/tcnica se
adapta melhor.
REQ 05. Estar alinhado aos modelos de melhoria de processo de software (CMMI, MPS.BR,
ISO/IEC 15504) na parte de estimativas.
REQ 06. Estar alinhado ao guia de gerenciamento de projetos PMBOK na parte de estimativas no
contexto de desenvolvimento de Software.
REQ 07. Apresentar templates, exemplos e ferramentas referentes ao processo de estimativas.
REQ 08. Ser escrito em portugus.
REQ 09. Estar disponvel livremente para uso.
Analisando a literatura existente, identificou-se que atualmente no existe guia que atenda a
todos requisitos elencados (REQ 01 a 09). Neste sentido, so apresentados trabalhos relacionados
para verificar a sua possvel contribuio para o desenvolvimento do guia proposto, bem como se
fez a anlise de acordo com os requisitos elencados para a realizao de um guia destes. A natureza
dos documentos apresentados contempla contedos mais abrangentes em gerncia de projetos,
inclusive metodologias geis, aplicaes com modelos de melhoria de processo e especficos como
estimativas de software.
A. Software Project Management (HUGHES & COTTERELL, 1999)
No livro Software Project Management (HUGHES & COTTERELL, 1999), os autores
apresentam em um mtodo e em linhas gerais uma introduo ao gerenciamento de projetos, uma
reviso de planejamento de projetos, a monitorao e controle de projetos e o gerenciamento de
pessoas e equipes.
Uma viso geral do planejamento de projetos apresentada, sugerindo um framework
(chamado Step Wise) com passos que devem ser realizados nesta fase. Alm disso, demonstra
tambm algumas tcnicas que podem ser utilizadas e como aplic-las. As etapas destacadas so:
selecionar o projeto, identificar objetivos e escopo de projetos, identificar infra-estrutura de projeto,
analisar as caractersticas do projeto, identificar atividades e produtos do projeto, estimar esforo
para cada atividade, identificar atividades de risco, alocar recursos, revisar o plano e por fim
executar o plano (vide figura 2).
No que se refere s estimativas dedicam um passo a estimativa de esforo e durao,
explicando o que so estas atividades. Alm disso, apresentam tcnicas de estimativa de esforo
(REQ. 02) como opinio de especialista e estimativa por analogia (vide Seo 2.2.1.1).
Apesar do roteiro apresentado, o documento no demonstra detalhadamente como realizar
tais atividades (REQ. 03) ou qualquer modelo/tcnica que possa ser usado no processo de estimar
(REQ. 02, 03).
O guia no considera as caractersticas especficas das MPEs (REQ 01, 04) e no est
alinhado a qualquer modelo de melhoria de processo de software (REQ 05) ou ao guia de
gerenciamento de projeto PMBOK (REQ 06).
100
B. Integrated Project Management (HALL e JOHNSON, 2002)

Hall e Johnson sugerem o gerenciamento de projeto integrado (IPM - Integrated Project
Management) que segue os mesmos conceitos do PMBOK, acrescentando procedimentos que
identificam como seguir as etapas sugeridas. Alm disso, o gerente de projeto envolve todos que
tm responsabilidade no projeto e nas tarefas de planejamento do projeto.
Os autores sugerem que o gerenciamento de projeto integrado requer os seguintes processos:
Um gerente de projeto tecnicamente qualificado e que seja capaz de conduzir a equipe

em um planejamento colaborativo e que assuma a responsabilidade pela manuteno do
projeto.
Antes de seu incio deve ser elaborada uma anlise detalhada e precisa do que
necessrio para completar o projeto.
Uma estrutura de mudana deve ser planejada antes que o projeto seja executado, com
intuito de que ao ocorrem inevitveis pedidos de alterao seja fcil redefini-los.
Antes de planejamento de projeto a viabilidade do ser abordada e definida.
Para a estimativa de esforo, os autores utilizam o grfico de Gantt para represent-la e

monitor-la. De acordo com Hall e Johnson (2002) para uma boa estimativa torna-se necessrio
saber que a inexatido em uma estimativa pode prejudicar o planejamento e gerenciamento de
projetos; assegurar-se que os membros do grupo de trabalho com maior conhecimento estejam
participando do processo de estimar; e para uma estimativa nova ou experimental ter o auxlio de 2
ou mais especialistas na atividade de estimativa. Como exemplos algumas figuras na elaborao do
grfico de Gantt so apresentados (REQ 07).
O IPM no faz meno aos modelos de melhoria de processos (REQ 05), to pouco ao guia
PMBOK (REQ 06). Ao abordar estimativa de esforo no apresenta qualquer modelo/tcnica de
estimativa de software (REQ 02) ou templates (REQ 07) que possam ser usados nesta atividade. O
guia tambm no demonstra qualquer relao com MPEs (REQ 01, 04).
101
C. Practical Insight into the CMMI (KASSE, 2004)

A essncia de cada uma das reas do CMMI sem sua estrutura tcnica apresentada em
Kasse (2004). O livro preocupa-se em fornecer uma explicao e guiar a implementao do modelo
CMMI. O texto aborda tambm os princpios da engenharia de software utilizados para criao do
CMMI discutindo a abordagem orientada a negcios trazida neste modelo.
O trabalho apresenta 5 captulos referentes a gerncia de projetos apresentando abordagens
que pretendem auxiliar como gerenciar e controlar por meio do planejamento de projetos, da gesto
de riscos, da gesto da qualidade, da gesto de fornecedor e por meio da gesto de um projeto
integrado.
Quanto fase de planejamento o texto pretende auxiliar no desenvolvimento deste que tem
como objetivo estabelecer e manter planos que definem as atividades de cada parte envolvida no
projeto e como estas afetam o projeto. Nesta fase, so detalhadas a descrio de escopo, a EAP e
estimativa.
No que se refere a atividade de realizar estimativas o esforo, a durao e o tamanho so
abordados sem detalhamento, existindo apenas uma breve descrio destes e uma explicao
sumria sobre a tcnica Wideband Delphi (REQ 02, 03). No h exemplos ou templates para
auxiliar no direcionamento da execuo desta atividade (REQ 07).
O guia no se destina em especfico a MPEs ou apresenta qualquer meno a este tipo de
organizao (REQ 01, 04). A forma em que est escrito direciona o trabalho a pessoas que tenham
conhecimento prvio da rea de gerenciamento de projetos e tambm ao modelo CMMI (REQ 05).
D. Interpreting the CMMI: A Process Improvement Approach (KULPA e JOHNSON, 2003)
A abordagem de Kulpa e Johnson (2003) descreve e discute a estrutura do CMMI com suas
reas de processo, apresentando desde os motivos que devem ser considerados para a escolha de sua
utilizao ao direcionamento de como aplicar o modelo em uma organizao.
No que se refere rea de planejamento, o trabalho apresenta as prticas genricas
referentes a esta rea, bem como, a citao dos procedimentos que devem ser apresentados nesta
fase. Alguns templates, como do plano de implantao e plano de ao, so mostrados, porm no
h qualquer explicao da aplicao destes. Pode-se destacar um template para processo para a
102
previso de desempenho baseado no esforo, sendo este estimado considerando os requisitos do

sistema e a partir de dados histricos da organizao.
O texto apresenta uma discusso sobre a adoo do CMMI em pequenas empresas, mas no
demonstra como isto pode ser realizado ou referencia alguma maneira de adequao do modelo a
empresas deste porte (REQ 01, 04, 05).
Com relao a estimativas de software em especfico esforo, durao e tamanho, so
mencionadas no texto durante a explicao de gerncia de projeto no CMMI e nas templates
apresentadas para atendimentos as prticas genricas e especficas do modelo.
No so apresentados modelos/tcnicas referentes estimativa de software (REQ 02,03).
Por ser uma interpretao do CMMI no faz meno aos modelos MPS.BR e ISO/IEC 15504 (REQ
05) e no apresenta preocupao em alinhamento ao guia de gerenciamento de projetos PMBOK
(REQ 06) em se tratando de desenvolvimento de Software.
O trabalho deve ser lido por pessoas que tenham conhecimento prvio sobre a rea de
gerenciamento de projetos e tambm do modelo CMMI considerando sua estrutura.
E. How to run successful projects in Web time (O.CONNELL, 2000)
O autor faz uma comparao entre a indstria de software e de filmes, em que vrios so
realizados simultaneamente ou em seqncia, afirmando que os dois produtos assemelham-se em
sua forma de produo, principalmente no que se refere as estimativas, por serem produtos abstratos
e diferentes dos manufaturados como uma televiso. Como a indstria de filme teve uma
considervel melhora em estimativas os autores identificaram entre as fases de desenvolvimento
deste produto (pr-produo, produo, e ps-produo) a pr-produo a etapa em que se destina
o maior tempo e dedicao.
Desta forma, o trabalho alm de apresentar idias sobre o desenvolvimento de projetos na
indstria de filme, destaca principalmente como escolher o projeto correto, demonstra como criar de
plano de projeto, alm de tcnicas e ferramentas para esta atividade e por fim destaca a monitorao
e controle do plano, ou seja, como execut-lo.
Para o autor, as estimativas no so corretas em virtude dos objetivos do projeto no serem
bem definidos, por isso concentra o contedo do trabalho em planejamento de projetos.
103
Apresenta discusso a respeito de estimativa de esforo em que sugere trs fases: a criao
de uma lista de tarefas, a criao de dependncias entre estas e por fim determina o nmero de dias
necessrios para cada atividade considerando o nmero de horas de trabalho dirio. Para ilustrar o
sugerido, apresenta um exemplo e templates baseado em um escopo, identificando tarefas e o tempo
previsto para execuo de cada uma delas.
Cabe destacar que embora este trabalho demonstre, por meio do exemplo, como o modelo
deve ser aplicado contempla apenas estimativa de esforo (REQ 02, 03). Desta forma, no aborda
estimativas de tamanho de software e durao de desenvolvimento de software.
O material tambm no est direcionado a caractersticas das MPEs de software (REQ 01,
04), no referencia os modelos de melhoria de processo (REQ 05) ou possui alinhamento ao guia de
gerenciamento de projetos PMBOK (REQ 06).
F. Software measurement and estimation: a practical approach (LAIRD e BRENNAM, 2006)
Laird e Brennam (2006) apresentam uma abordagem prtica para medio e estimativa de
software. Em se tratando de medidas apresenta conceito e fundamentos e captulos destinados a
medidas de tamanho e complexidade, defeitos, confiabilidade de software, medidas financeira e
mtricas para gerenciamento.
Um captulo do livro dedicado a estimativa de esforo apresentando definio e discusso
sobre o tema, alm de modelos e metodologias utilizados para estimativas de software juntamente
com exemplos de aplicao (REQ 01, 02, 03, 07)
No entanto, no demonstra para quais tipos de empresas seria mais interessante cada modelo
e metodologia descrita. Tambm no relata se podem ser utilizados por organizao de qualquer
porte (REQ 01 e 04).
Esta abordagem tambm no contempla alinhamento aos modelos de melhoria de processo
de software e no est alinhado ao guia de gerenciamento de projetos PMBOK considerando o
contexto de desenvolvimento de Software (REQ 05, 06). Destaca-se tambm que o texto pressupe
maturidade no que se refere ao conhecimento na rea de gerncia de projetos.
104
G. Agile Project Management with Scrum (SCHWABER, 2004)

Este livro escrito pelo criador do Scrum contempla experincias do autor na aplicao deste
processo, apresentando seus fracassos e sucessos no desenvolvimento de sistemas de software. O
processo de desenvolvimento gil Scrum destina-se a sistemas complexos em que normalmente
existem requisitos volteis e possuem um prazo de entrega curto. Neste caso, torna-se relevante a
utilizao de um processo que se adapte as caractersticas e necessidades do projeto que estar
sendo desenvolvido.
A essncia do Scrum apresentada neste guia, bem como os envolvidos no processo, seus
papis e atividades que devem ser executadas durante o desenvolvimento do projeto.
O planejamento de projetos no livro abordado em um captulo em que apresenta esta
atividade como sendo uma relao entre expectativas de usurios e equipe de desenvolvimento. O
autor apresenta um estudo de caso para exemplificar, com pouca explicao terica do tema.
Em se tratando de estimativa de software percebe-se a sugesto em que a equipe deve
atribuir tamanho a cada requisito especificado no projeto. No h meno de outras tcnicas (REQ
02, 03) e tambm no so encontrados templates ou ferramentas para execuo desta atividade
(REQ 07).
A empresa utilizada no caso apresentado de grande porte e no h meno se este processo
precisaria de alguma adaptao para aplicao em MPEs de software (REQ 01, 04).
H. Radical Project Manager (THOMSETT, 2002)
Este livro aborda o gerenciamento de projeto adotando XP (eXtreme) advindo da
experincia do autor na rea e em projetos em empresas de setores diversificados. Divide-se em trs
partes em que a primeira se destina a definies iniciais abordando um novo ambiente de projeto, a
evoluo da gerncia de projetos e conceitos de eXtreme. Na parte 2 o autor discute sobre as
ferramentas utilizadas no XP como planejamento participativo e tcnicas utilizadas para
planejamento e controle. Recursos adicionais so apresentados na parte 3 do livro, como dicas,
ferramentas avanadas e questes relacionadas ( negociao, comunicao e tica).
Quanto a rea de planejamento h um explanao de como esta compreendida no eXtreme
envolvendo 10 fases: definio de escopo, stakeholds, objetivos e projetos relacionados, anlise e
105
desenvolvimento de cenrios de valor agregado e os benefcios realizao, definio de requisitos

de qualidade de produto, seleo de estratgias de desenvolvimento de projeto, anlise de riscos do
projeto e desenvolvimento de um plano de gerenciamento destes, definio de uma lista de tarefas,
estimativa de tarefas, desenvolvimento de um cronograma de projeto ou plano de execuo,
alocao de pessoal, desenvolver custo e retorno de investimento do projeto.
No que se refere a estimativas o texto apresenta um subcaptulo referente a estimativa de
atividades. Alguns fundamentos da estimativa participativa so apresentados, sendo mencionadas
tcnicas de estimativa como Wideband Delphi e pontos por funo em que h uma breve descrio
de como deve ser realizada (REQ 02 e 03).
No entanto, o livro sugere um processo de estimativa baseada no conceito de wideband
Delphi em equipe, em que se necessita de ao mnimo 3 especialistas. Os passos sugeridos so nove:
Troca de informaes: os membros da equipe e as partes interessadas devem receber
informaes relevantes sobre o projeto como o plano de negcios e exigncias de qualidade.
Reviso de riscos do projeto: os participantes devem realizar um procedimento formal de
avaliao dos riscos.
Reviso da EAP: Rever e refinar a EAP ou fase ou release que estar sendo estimada.
Estimao individual: cada integrante individualmente estima cada tarefa ou atividade
utilizando a anlise da sensibilidade para proporcionar uma melhor caso, caso provvel, e o
pior caso.
Reviso de estimativas: estas so escritas em um quadro branco ou em espao pblico e
agrupadas em trs faixas.
Anlise Delphi: participantes discutem as vrias hipteses e questes consideradas quando
elaboraram as estimativas.
Ajuste de estimativas: se houver necessidade, as diferentes estimativas so ajustados com
base na discusso da equipe.
Descartar insignificantes: Cada srie obtida com outriders descartados.
106
Checar os resultados finais: antes da publicao das estimativas os resultados finais so

analisados e discutidos novamente.
O texto sobre estimativas tambm apresenta uma discusso a respeito do processo proposto
e apresenta exemplo de sua aplicao por meio de um estudo de caso (REQ 07).
No h especificidade as MPEs (REQ 01, 04), no apresenta referncia aos modelos de
melhoria de processo adotados nesta dissertao (REQ 05) to pouco possui alinhamento ao guia de
gerenciamento de projetos PMBOK (REQ 06).
I. Practical software estimation: function point methods for insourced and outsourced
projects (Parthasarathy, 2007)
O livro apresenta dois captulos que introduzem a atividade de estimativa a fim de detalhar
caractersticas e aspectos bsicos para que o processo de estimar possa ser realizado
adequadamente. O primeiro pode-se obter informaes sobre parmetros necessrios a uma boa
estimativa cita-se escopo, ambiente de trabalho, ferramenta e aprendizagens anteriores;
especificamente sobre estimativa de projeto de software, a importncia de estimar e ainda quem
participa do processo.
O Captulo 2 detalha as regras de estimativa em projeto de software, neste sentido aborda a
atividade de estimativa contemplada no gerenciamento de projeto descrevendo os aspectos
relevantes a serem considerados. Apresenta as fases de projeto de software: aprovao, contrato e
execuo do projeto. Discute tambm os parmetros que fazem parte da estimativa destacando
tamanho, esforo e custo.
A abordagem do livro especifica a tcnica de analise de pontos de funo explicando
detalhadamente cada passo para a realizao desta de acordo com o IFPUG. Alm das explicaes
de cada tarefa para realizar estimativa usando FPA (Function Points Analisy), apresenta exemplos
de como aplicar a tcnica considerando cada uma de suas etapas (REQ 01, 02 em parte).
O livro tambm apresenta uma breve abordagem de outras tcnicas considerando a
abordagem heurstica e a paramtrica (REQ 01 e 02 em parte). Por fim, apresenta estudos de caso
aplicando passo a passo as atividades para realizao da tcnica de anlise por pontos de funo.
107
So apresentados templates para a aplicao da tcnica de anlise de pontos de funo que

o objeto do livro (REQ 03 e 07 em parte).
Os requisitos relacionados s MPEs de software no so considerados na descrio dos
aspectos relacionados a estimativas abordados no livro (REQ 04). Tambm no h meno dos
modelos de melhoria de software CMMI, MPS.BR, ISO/IEC 15504) na parte de estimativas, o
mesmo ocorrendo com o guia de gerenciamento de projetos PMBOK.(REQ 05 e 06).
Os requisitos 08 e 09 no so atendidos considerando as caractersticas do material
pesquisado aprofundamento em uma tcnica de estimativa, escrito em ingls e ser um livro que
deve ser adquirido em empresas comerciais especficas.
J. Agile estimating and planning (COHN, 2006)
O guia apresenta captulos que discutem sobre planejamento de projetos, incluindo a
aspectos relacionados proposta de realiz-lo, o que levam estes a serem falhos, e por fim a
abordagem gil para esta rea. Abrange tambm as atividades de agendamento, comunicao e
monitorao na fase de planejamento.
Quanto a estimativa de software em modelos geis h cinco captulos destinados a atividade
contemplando estimativa de tamanho e esforo, tcnicas geis para estimativa como planning poker
e aspectos relacionados a re-estimativa. H uma argumentao considervel sobre as estrias
abordadas nas tcnicas de estimativas em modelos geis.
Pelo que se percebe o livro destinado a modelo de processo geis especificamente, no
fazendo meno explicitamente a MPES de software (REQ 01 e 04). No entanto, o livro destaca 5
captulos destinado a contedos sobre estimativas de software voltadas a modelos de processo geis
(REQ 01, 02, 03, 04 em parte ) que so possveis de serem aplicados em MPEs de software.
No h preocupao em estar alinhado aos modelos de melhoria de processo de software
(CMMI, MPS.BR, ISO/IEC 15504) na parte de estimativas, nem to pouco ao guia de
gerenciamento de projetos PMBOK.
A descrio do contedo para seu intuito se d de forma clara e explicativa enfocando
modelos de processos geis. O livro em ingls no atendendo ao requisito REQ 08 e tambm no
108
est disponvel para uso sendo comercializado em empresa especializadas no estando a contento
do requisito REQ 09.
4.1 DISCUSSO DOS GUIAS PESQUISADOS

No Quadro 17 apresenta-se comparativo entre os guias pesquisados considerando os
objetivos do trabalho e os requisitos elencados para o guia proposto no incio deste captulo. A
anlise contemplou 3 alternativas de atendimento aos requisitos elencados totalmente Atendido (),
Parcialmente atendimento ( ) e No Atendido ( ).
Requisitos
01
02
03
04
05
06
07
08
09
Guias
A
B
C
D
E
F
G
H
I
J
Quadro 17 - Comparao entre os guias pesquisados e os requisitos do guia proposto
Pode-se perceber nos trabalhos abordados a falta de atendimento de requisitos desejados no

guia foco desta pesquisa. Com relao ao direcionamento a MPEs quase no considerado na
maioria destes, apenas um deles discute sobre empresas com este porte e os outros tm ligao
superficial por apresentarem tcnicas cabveis.
Com relao descrio e apresentao das tcnicas apenas um dos guias faz por completo
a citao da maior parte destas, porm no h um detalhamento necessrio. H na maioria dos guias
comentrio sobre modelos e/ou tcnicas, mas no contemplam todos os possveis as MPEs.
O alinhamento aos modelos de melhoria de processo de software (CMMI, MPS.BR,
ISO/IEC 15504) na parte de estimativas no so considerados na maioria do guias, e quando so
citados apenas um destes considerado. Com relao ao guia PMBOK nenhum dos contedos
pesquisados demonstra alinhamento ao guia em questo.
109
H maioria dos trabalhos pesquisados apresentava um dos itens constantes no requisito 07

cita-se templates, exemplos e ferramentas referentes ao processo de estimativas. Contudo, o
encontro de todos estes atributos em um mesmo guia no foi possvel de visualizar.
Nem todos os guias apresentavam um linguajar e contedo adequados a compreenso de
pessoas com um nvel inicial de conhecimento na rea de melhoria de processo e de gerncia de
projetos.
Os trabalhos pesquisados so todos escritos em ingls e no apresentam verses em
portugus e tambm a maioria deles no est disponvel livremente para uso.
110
5 DESENVOLVIMENTO DO GUIA
Neste capitulo ser descrito o processo de desenvolvido, considerando os documentos
norteadores, assim como as pesquisas que fizeram parte de sua constituio. A estrutura do guia
ser apresentada, assim como uma explicao sobre os captulos que compem o guia de estimativa
de software. As demonstraes dos captulos 4, 5, 6, 7 e 9 so extraes do que consta no guia e o
captulo 8 apresenta um resumo das ferramentas selecionadas e destacadas no guia.
Cabe destacar que o guia estar na forma de relatrio tcnico do Programa de Mestrado em
Computao Aplicada, contido em CD e disponibilizado junto com a dissertao. Desta forma, cada
item apresentado neste captulo com relao ao guia pode ser encontrado em maior detalhamento no
referido relatrio.
5.1 DESCRIO
A dissertao contempla o desenvolvimento de um guia para micro e pequenas empresas de
software para a rea de planejamento de projetos, em especfico, estimativa de esforo e durao de
atividades, bem como tamanho. A estrutura do guia tem como referncia o PMBOK (PMI, 2004) e
est alinhada as propostas dos modelos de melhoria de qualidade CMMI-Dev (SEI, 2006), MPS.BR
v. 1.2 (SOFTEX, 2007) e ISO/IEC 15504, considerando as tcnicas de estimativas.
Cabe ressaltar, que no contexto deste trabalho um guia compreendido como um
documento estruturado que contm contedos incluindo tcnicas, templates, exemplos e
ferramentas voltados a determinado assunto que possam auxiliar na implantao de determinado
processo, neste caso, estimativa de software. Alm disso, o guia pretende a atender modelos de
melhoria de processo de software e estar em consonncia com documentos norteados da rea.
A Figura 10 ilustra como ocorreu o processo de desenvolvimento do guia de estimativa de
software proposto nesta dissertao.
Figura 10 - Estrutura de desenvolvimento do guia
Por ser o guia de gerenciamento de projeto mais utilizado na atualidade, este projeto est
baseado no modelo de planejamento de projeto, em especfico as atividades de estimativa
apresentadas no PMBOK (2004). O guia de estimativas foi implementado, apresentando uma
seqncia de passos baseado nas caractersticas das MPEs considerando qual tcnica seria mais
apropriada, e atendendo as expectativas dos modelos e da norma de qualidade e produtividade de
software. Para tanto, tornou-se necessrio a apresentao no guia de uma descrio das tcnicas de
estimativas consideradas, bem como sua adequao as MPEs de software.
As definies de relacionamento entre as MPEs de software, os modelos/tcnicas de
estimativa, o PMBOK e os mtodos de qualidade e produtividade de software foram realizadas com
base na literatura, relatrios de experincias e aplicaes de tais tcnicas e ferramentas em empresa
deste porte.
112
A estrutura do guia desenvolvida apresentada na Figura 11, contemplando seus captulos e

os referidos contedos abordados.
Figura 11 - Estrutura do Guia em captulos
Como observado na Figura 11 os tpicos que compem o sumrio do guia em construo

so assim definidos:
Captulo 1 - Introduo: uma apresentao definindo a quem este se destina, tambm o

que se espera do guia, assim como uma explicao sobre sua aplicao.
Captulo 2 Conceitos Bsicos: aborda um referencial terico envolvendo

gerenciamento de projetos, planejamento e estimativas voltados ao desenvolvimento de
software.
Captulo 3 Documentos norteadores: descrio da atividade de estimativa com seus

requisitos mnimos em cada documento norteador: guia PMBOK e modelos de melhoria
de processo j ressaltados neste projeto CMMI / MPS.BR / ISO/ IEC 15504.
Capitulo 4 - Processo genrico: apresentao de uma forma genrica de como realizar a

atividade de estimar utilizando o guia desenvolvido. So destacadas atividades
113
predecessoras comuns a todas as tcnicas e modelos de estimativas considerados no

guia.
Captulo 5 - Tcnicas/modelos de estimativa: apresentao de tcnicas e modelos

considerados para estimativa dos parmetros abordados (tamanho, esforo e durao).
Para cada tcnica/modelo so descritos: conceitos destes; parmetros (tamanho, esforo
e durao) que o modelo/tcnica pode estimar; em qual ocasio deve ser utilizado; como
realizar a aplicao do modelo/tcnica; e outras referncias referente ao que est sendo
descrito alm do guia.
Captulo 6 - Templates: modelos documentos que podem auxiliar no processo de realizar

estimativas de software.
Captulo 7 - Exemplos: demonstrao de aplicao de cada uma das tcnicas/modelos e

templates apresentados no captulo 5.
Captulo 8 - Ferramentas: apresentar caractersticas e aplicao de ferramentas com

funcionalidades que atendam as necessidades dos colaboradores das MPEs de software.
Captulo 9 Conformidade documentos norteadores: apresenta-se neste captulo uma

avaliao de conformidade que apresenta caractersticas do guia criado e sua relao
com o guia PMBOK, alm da relao entre os modelos de melhoria de processo e o guia
de estimativas.
Este trabalho fornece um guia de estimativas de software considerando esforo e durao de

atividades e tamanho de software. Tal guia tem como base o PMBOK (PMI, 2004) e est alinhado
as normas e modelos de qualidade e produtividade de software. Tcnicas de estimativas tambm so
consideradas e todo o guia considera caractersticas das MPEs de software.
Espera-se com este trabalho auxiliar as MPEs na definio de estimativas, visto que o guia
est adequado a realidade das empresas deste porte.
Os captulos 1, 2 e 3 que contemplam respectivamente, introduo ao guia, conceitos
bsicos relacionados a estimativas e documentos norteadores no sero detalhados, pois destinam-se
114
a apresentar contedo de embasamento para utilizao das atividades mais especificas do processo
de estimar.
No entanto, os captulos 4 a 9 possuem contedos que norteiam a aplicao do guia e por
este motivo sero apresentados em detalhes contemplando em vrios momentos cpias literais do
guia para demonstrao do que foi desenvolvido.
5.2 PROCESSO GENRICO

Em um guia, a padronizao de processos facilita a sua aplicao pelos usurios potenciais,
uma vez que contribui para identificao da forma em que est constitudo. Neste sentido, a Figura
12 apresenta o processo genrico com atividades necessrias para que se possa executar uma das
tcnicas apresentadas no guia e em consonncia com o PMBOK e os modelos de melhoria de
processo que fazem parte do contexto deste trabalho.
Gerenciamento do Processo de Estimar

Figura 12 - Processo genrico para estimar
Inicialmente cabe destacar que as atividades de entrada podem ou no serem necessrias

dependendo do modelo/tcnica de estimativa adotado para realizar o processo de estimativa descrito
na Figura 12.
A definio do escopo uma fase destacada no planejamento que se dedica a apresentar o
que se deseja do projeto a ser desenvolvido. No PMBOK o planejamento do escopo de projeto e
definio de escopo so atividades predecessoras a de estimar.
115
Outra atividade necessria antes do processo de estimar a criao da EAP, ou seja,

organizar o escopo total do projeto por meio da diviso do projeto em componentes de trabalho
menores. Esta atividade no PMBOK est na seqncia das atividades de planejamento e definio
de escopo.
No CMMI-DEV prtica especfica 1.1 define os aspectos apresentados planejamento e
definio de escopo e a criao da EAP. No MPS.BR o resultado esperado 1 (GPR 1) requisita que
se tenha uma definio do escopo do trabalho constituda e sugere a representao do escopo por
meio de EAP. Da mesma forma a ISO/IEC 15504 define como prtica base 1 a definio do escopo
do trabalho.
Seguindo o processo genrico, os estimadores devem definir quais os parmetros de projeto
sero estimados. No caso deste guia os parmetros suportados so tamanho, esforo e durao e so
pr-requisitos para que se possa escolher a tcnica mais apropriada.
A atividade de aplicao de modelo/tcnica tem como pr-requisito alm do(s) parmetro(s)
desejado(s), a deciso pelo uso de um ou mais modelos/tcnicas no guia. Para auxiliar nesta
atividade na explicitao de como aplicar modelos/tcnicas tem-se o critrio utilizao, em que se
descrevem informaes necessrias a uma MPE para que determinado modelo/tcnica do guia seja
utilizado.
Aplicar o(s) mtodo(s)/tcnica(s) selecionados a prxima atividade a ser realizada de
acordo com o processo apresentado. A explicao de como aplic-los possui um captulo especifico
no guia em que todos os modelos/tcnicas sugeridos so apresentados passo a passo com intuito de
auxiliar e facilitar a aplicao do(s) modelos(s)/tcnica(s) selecionado(s).
Aps a execuo do modelo/tcnica de estimativa torna-se relevante documentar todas as
atividades realizadas durante o processo. Isso porque muitas tcnicas requerem dados histricos,
alm de que se torna um conjunto de informaes interessante para empresa, considerando
principalmente a exigncias dos modelos de melhoria de processo de software ao qual este guia est
alinhado.
A sada do processo de estimar refere-se ao fornecimento das estimativas realizadas para os
parmetros definidos inicialmente. Com a obteno destas pode-se dizer que o processo foi
realizado adequadamente apresentando os resultados de interesse da MPE.
116
A atividade de gerenciamento do processo de estimar pressupe que toda esta atividade seja
gerenciada desde o planejamento ao monitorao e controle, durante todo o processo de estimar. O
intuito que se chegue ao objetivo desejado sem que problemas ocorram no decorrer do processo e
no sejam sanados e corrigidos.
As atividades consideradas ao gerenciamento do processo de estimar possuem como base o
CMMI-DEV com o objetivo genrico 2 e suas prticas genricas; o atributo de processo 2.1 do
MPS.BR e os referidos resultados esperados; e as prticas genricas do atributo de processo 2.1 da
ISO/IEC 15504. Sero consideradas as atividades de planejar, monitorar e controlar.
A atividade de PLANEJAR envolve a realizao de um planejamento do processo de
estimar, sendo crucial a definio dos objetivos pretendidos com a aplicao deste processo. O
planejamento prev um plano documentado apresentando de que forma a execuo do processo
definido deve ser realizado. Sero considerados no planejamento:
Identificao e levantamento dos recursos que participaro deste processo e estes

devem ser documentados. Estes recursos podem ser humanos, ferramentas, templates
necessrios a execuo de determinada tcnica de estimativa, como por exemplo, no
caso do planning poker, as cartas utilizadas em sua aplicao devem ser
consideradas.
A definio de responsabilidade dos recursos humanos selecionados para o

processo deve ser identificada, garantindo que as atividades pertinentes a tarefa de
estimar sero executadas. Quem participar do processo como estimador ou quem
estar como coordenador dependendo do modelo/tcnica selecionada.
Identificao da capacitao dos recursos humanos que participaro do processo

de estimar. O levantamento das necessidades dos envolvidos, como por exemplo,
caso no conheam o modelo/tcnica definido devem ter um tempo para realizar
leitura da aplicao deste no guias, por exemplo.
Definio de estratgias para a comunicao entre os stakeholders (que so as partes

envolvidas com o processo). No processo de estimar esta atividade torna-se crucial
para que seja possvel envolver as partes que tenham interesse na realizao da
estimativa. Como exemplo, cita-se a marcao de encontros para realizao do
117
processo de estimar e ainda pode-se definir que tal reunio ser realizada por meio
eletrnico como email ou intranet.
A monitorao e controle devem ser realizados durante todo o processo de estimativa
objetivando realizar um acompanhamento do que foi planejado. Neste caso, cabe realizar a
observao nas atividades definidas e contidas no documento em que consta o planejamento cita-se
identificao e definio de recursos, definio de responsabilidades aos recursos selecionados,
alm de identificao de suas habilidades para realizao da tarefa de estimar, e ainda viabilizar a
comunicao durante a execuo do processo.
Alm disso, torna-se necessrio a realizao de um controle eficaz do que foi planejado e o
que est sendo executado para identificaes de desvios entre o plano e o que est sendo
desenvolvido pela equipe que participa do processo de estimativa. Havendo contradies medidas
corretivas devem ser aplicadas para que se chegue ao final do processo e o objetivo seja almejado.
No caso, de objetivos desenhados e no alcanados estes devem ser analisados e medidas
que tenham como intuito chegar ao desejado devem ser tomadas, algumas podem ser:
A reviso do plano aconselhvel buscando corrigi-lo e adequ-lo para a forma como

a empresa trabalha.
Rever os recursos como ferramentas, guias, exemplos e templates utilizados para

identificar se esto auxiliando no processo de estimar.
No caso dos recursos humanos no estarem correspondendo, pode-se investir na

identificao de suas dificuldades, verificando se o que recebeu como capacitao foi
suficiente. Assim como a mudana de sua responsabilidade no contexto do que est
sendo executado, e ainda envolv-los mais no desenvolvimento da atividade.
Falhas na comunicao implicam na reviso do que foi definido no documento do

planejamento, assim como ocorrncia de comunicao entre os envolvidos com
menor espao de tempo podem auxiliar no processo.
118
5.3 MODELOS E TCNICAS DE ESTIMATIVAS

Os modelos e tcnicas selecionados para compor o guia seguem critrios referentes a
tcnicas/modelo mais utilizados e citados nas referncias, caracterizao das MPEs e sugeridos pelo
PMBOK.
Alm das abordagens bottom-up, top-down e paramtrica, os seguintes modelos e tcnicas
so destacados no guia:
Analogia;
Opinio especializada;
PERT;
Wideband Delphi;
Anlise por ponto de funo;
Anlise por ponto de casos de uso;
COCOMO II; e
Linhas de cdigo.
Por se tratar de um guia uma padronizao foi utilizada para a descrio/aplicao das
tcnicas destacadas como opo para disciplinar e orientar o usurio desta ferramenta.
Para cada um dos modelos/tcnicas apresentados destacam-se os seguintes itens: o que
referindo-se ao conceito do modelo/tcnica e suas caractersticas; parmetros estimados cujo
objeto a definio de qual(is) parmetro(s) podem ser estimados utilizando o modelo/tcnica em
questo considerando o objetivo deste estudo: tamanho, esforo e durao; utilizao em que se
descreve qual situao seria mais adequado utilizar aquele modelo/tcnica; e como utilizar item
que apresenta passo a passo como se deve aplicar o modelo/tcnica discutido.
Para ilustrar como o os modelos/tcnicas so descritos no guia, a tcnica de estimativa de
trs pontos ou PERT (Program evaluation and Review Technique) ser apresentada a seguir
conforme est no guia. Cabe destacar que se parte do pressuposto que o processo genrico para
119
estimativa de software est sendo considerado quando da leitura do contedo referente ao

modelo/tcnica.
Estimativa de trs pontos ou PERT (Program evaluation and Review Technique)
O que : esta tcnica baseia-se em trs tipos de estimativas para apresentar um resultado
mais prximo possvel do desejado, sendo estas (PMI, 2004; HUGHES & COTTERELL, 2006):
estimativa mais provvel (M) que prev expectativas realistas para a estimativa, ou
seja, espera-se que apresente os resultados em circunstancias normais;
melhor caso possvel focado na estimativa otimista (O), consideram-se condies
favorveis e estima-se o menor tempo em que se pode realizar determinada
atividade;
estimativa pessimista (P) que visualiza o pior caso para a estimativa, ou seja,
considerar todas as circunstncias eventualidades que possam prejudicar o
desenvolvimento do projeto.
Utilizao: esta tcnica exige do estimador algum tipo de experincia em desenvolvimento
de software para indicar os tipos de estimativas possveis. Embora uma empresa seja recm criada
se tiver profissionais que j tenham trabalhado em algum projeto de software ser possvel utilizla. Obviamente, quanto mais experincia dos especialistas e programadores, maior ser a preciso
das estimativas.
Parmetros estimados: tamanho, esforo e durao.
Como utilizar: a estimativa PERT combina as trs estimativas previstas O, M e P, da forma
como apresentada a seguir na aplicao de frmulas.
1. Estimar para o(s) parmetro(s) selecionado(s) as estimativas: Otimista (O), Mais
provvel (M), Pior caso possvel (P). Para cada parmetro definir o tipo de estimativa
2. Aplicar a frmula apresentada na Equao 3 obtendo a estimativa considerando as
variveis necessrias a execuo da tcnica PERT. Na equao T a mdia para a
estimativa.
120
T = (O + 4M + P)/6
Equao 24- Frmula PERT
3. Calcular o desvio padro atravs da frmula apresentada na equao 4
DesvPad = (P O)/6
Equao 25 - Frmula desvio padro
i.
Quanto maior for o desvio padro obtido, significa que h um grande intervalo
entre o previsto nas estimativas Otimista e Pessimista. O que se deseja que o
resultado de DesvPad seja pequeno, pois indica que as estimativas apontadas
inicialmente estavam adequadas.
5.4 TEMPLATES
Baseado na descrio dos modelos/tcnicas descritos no guia sugere-se templates que tem
como intuito auxiliar no processo de estimativa de software e aplicao do guia. Neste sentido, para
cada modelo/tcnica individualmente sero apresentados templates mais adequados a sua aplicao.
Para a criao dos templates foram utilizados softwares aplicativos como processador de
texto e planilha eletrnica, bem como, far-se- uso de j existentes possveis de serem aplicados
junto ao guia produzido.
O template criado para a tcnica PERT apresentada anteriormente for criado em Microsoft
Excel (2007) utilizando frmulas da planilha para facilitar a realizao dos clculos que precisam
ser realizados na execuo da referida tcnica. A Figura 13 apresenta o template criado.
121
Parmetro
estimado
Atividades/Projeto
Responsvel
pela estimativa
Otimista (O)
Mais provvel
(M)
Pior caso possvel

(P)
Desvio
Padro
T
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Figura 13 - Template para execuo da tcnica Pert.
Nas colunas T e Desvio Padro constam as frmulas apresentadas nas equaes 20 e 21

respectivamente, conforme regras lgicas do software de planilha eletrnica Microsoft Excel.
5.5 EXEMPLOS
O objetivo dos exemplos a comprovao e demonstrao de utilizao dos
modelos/tcnicas que compem o guia, bem como dos templates sugeridos. Este tpico no guia foi
criado considerando que a partir da descrio de um caso de um projeto de software a ser
desenvolvido as modelos/tcnicas so executadas de acordo com os passos descritos no captulo de
apresentao dos modelos/tcnicas e utilizando os templates do referido captulo.
Neste sentido, para criar os exemplos de aplicao dos modelos/tcnicas e templates
utilizou-se um caso fictcio elaborado pelo LQPS (LQPS, 2008).
O contexto uma pequena empresa de software com cinco anos de existncia e que possui
como produto um sistema de software customizvel para controle de emprstimos em vdeolocadora. A empresa percebeu que hoje tem srios problemas com o cumprimento dos prazos e
oramento previstos. O desafio estimar tamanho, esforo e durao, considerando a possibilidade
de cada tcnica, para um novo contrato que alm das funcionalidades bsicas j disponveis desejam
mais duas funcionalidades.
122
Para a aplicao dos mtodos e tcnicas de estimativas em projetos de software sero

consideradas as seguintes atividades:
1. Cadastro de clientes;
2. Cadastro de filmes;
3. Controle de emprstimo e devoluo;
4. Consulta de filmes por ttulo e/ou categoria (ao, infantil, etc.) via web para qualquer
interessado; e
5. Reserva de filmes via web para os clientes j cadastrados na vdeo-locadora. O cliente j
cadastrado (o cadastro continua somente possvel pelo mdulo cliente/servidor instalado
na vdeo-locadora) pode reservar filmes via web (a reserva mantida por 24 horas).
Neste caso aplicando a tcnica PERT de acordo com o modelo genrico escopo e EAP j
esto prontos por serem entradas para execuo do processo de estimativa.
Nas atividades do processo genrico na seqncia tem-se a seleo de parmetro(s) para
estimar, no exemplo, o selecionado foi durao. A prxima atividade executar o modelo/tcnica
de estimativa mais adequado ou adotado pela empresa.
Desta forma, a tcnica PERT ser aplicada conforme passos descritos no item 6.3:
Passo 1 - Estimar para o(s) parmetro(s) selecionado(s) as estimativas: Otimista (O), Mais
provvel (M), Pior caso possvel (P). Para cada parmetro definir o tipo de estimativa. Esta tarefa
foi realizada utilizando o template apresentado, conforme Figura 14.
123
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)
Mais provvel Pior caso possvel

(M)
(P)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
Figura 14 - Template PERT: calculo das estimativas O, M, P
Passo 2 - Aplicar a frmula apresentada na Equao 20 obtendo a estimativa considerando

as variveis necessrias a execuo da tcnica PERT. Na equao T a mdia para a estimativa.
Como o template foi criado na planilha eletrnica esta tarefa realizada automaticamente quando os
dados so digitados (Figura 15).
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)

(M)
(P)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
T
5,50
5,50
8,67
16,67
41,67
Figura 15 - Template Pert: Clculo da durao esperada
Passo 3 - Calcular o desvio padro atravs da frmula apresentada na equao 21. O desvio
padro utilizado para verificar o intervalo entre as estimativas (O, M e P). Deseja-se que este seja
pequeno, por indicar que as estimativas apontadas inicialmente estavam adequadas. Da mesma
forma, o clculo j consta no template apresentado e o resultado desta tarefa aparece medida que
as estimativas so digitadas (Figura 16).
124
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)

(M)
(P)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
Emanuela
Desvio
Padro
5,50
5,50
8,67
16,67
41,67
1,17
1,17
1,67
3,33
5,00
Figura 16 - Template PERT: clculo do desvio padro
5.6 FERRAMENTAS
O objetivo deste tpico no guia de analisar ferramentas utilizadas para o gerenciamento de
projetos, em face das vrias atividades envolvidas nesta rea e da necessidade de armazenar dados e
informaes referentes aos diferentes projetos executados pela empresas de desenvolvimento de
software. Em especfico no que tange ao planejamento de projeto pretende-se verificar aspectos
relevantes a estimativa de esforo, durao e tamanho existentes nas ferramentas e que possam
contribuir a sua obteno.
Neste sentido, esta avaliao foi realizada considerando os modelos e tcnicas de
estimativas abordados no guia, nas caractersticas destacadas das MPEs de software, alm de
verificar as exigncias apresentadas nos modelos de melhoria de processo e no PMBOK.
Estas ferramentas foram analisadas para que sejam indicadas como tecnologia de apoio a
realizao das estimativas de esforo, durao e tamanho no guia. Assim, tornou-se necessrio
conhecer suas caractersticas e quais funcionalidades destas ferramentas podem colaborar com o
processo de estimativa desejado.
Para a anlise foram elencados requisitos com base nas caractersticas das MPEs e nas
atividades necessrias ao processo de estimar observados no guia PMBOK e nos modelos de
melhoria de processo.
REQ 01. Permitir o registro da definio de escopo do projeto: para realizao das estimativas
torna-se necessrio aos estimadores conhecerem dados do projeto.
125
REQ 02. Permite refinar escopo: o detalhamento do projeto importante para que as tarefas
possam ser estimadas. Por exemplo, por meio do uso de EAP.
REQ 03. Possuir tcnica para estimativas de tamanho: identificar se a ferramenta apresenta alguma
tcnica para esta atividade e qual seria esta e suas caractersticas.
REQ 04. Possuir tcnica para estimativas de esforo: identificar se a ferramenta apresenta alguma
REQ 05. Possuir tcnica para estimativas de durao: identificar se a ferramenta apresenta alguma
REQ 06. Permitir o registro das estimativas de tamanho: independente da ferramenta possuir uma
tcnica de estimativa, verificar se permite o armazenamento dos processos de estimativa
de tamanho realizados pelos estimadores.
REQ 07. Permitir o registro das estimativas de esforo: independente da ferramenta possuir uma
de esforo realizados pelos estimadores.
REQ 08. Permitir o registro das estimativas de durao: independente da ferramenta possuir uma
de durao realizados pelos estimadores.
REQ 09. Permitir a elaborao do cronograma do projeto: alm de identificar se ferramenta prov
esta atividade, verificar como faz isso, por exemplo, diagramas de rede.
REQ 010. Ser acessvel s MPEs de software: verificar se o acesso desta ferramenta possvel
financeiramente as MPEs.
REQ 011. Possuir visualizao grfica: apresentar os dados de uma forma que facilite a
visualizao e que facilite a utilizao da ferramenta.
REQ 012. Registro de dados histricos: permitir o armazenamento, a consulta, inclusive por meio
de relatrio de dados histricos referentes aos processos de estimativa de vrios projetos.
REQ 013. Aderncia ao PMBOK e/ou modelos de melhoria.
126
REQ 014. Apresentar verso em portugus;

Foram selecionadas 5 ferramentas para anlise, sendo 3 para gerenciamento de projetos e 2
especficas para estimativas de software e 1 ferramenta genrica.
Os critrios para seleo das ferramentas foram: a utilizao da ferramenta pelas empresas, o
software Microsoft Project a ferramenta utilizada por 47% das empresas de tecnologia da
informao (PMI, 2007); apresentao da caracterstica de ser open source, o software selecionado
foi o DotProject por ser um dos mais populares observando o nmero de downloads realizados
(SOURCEFORGE); desenvolvida na regio de Florianpolis, o JEXPCHANNEL desenvolvido
pela empresa JExpets Tecnologia com sede em Florianpolis; ferramentas com aplicao de
diferentes modelos/tcnicas de estimativas: USC COCOMO II e COSTAR XPERT por
apresentarem como tcnicas as apresentadas neste projeto; e ferramenta de propsito genrico, o
Microsoft Excel foi escolhido por possibilitar realizao de clculos.
Ferramentas para gerenciamento de projetos
a) MS-Project: teve sua primeira verso em 1990 e utilizado para planejar, programar e
acompanhar a execuo de projetos, permitindo o controle de custo, cronograma e cargas de
trabalho de maneira detalhada ou resumida (VARGAS, 1998). A verso utilizada para a
avaliao foi o MS-Project 2007.
b) dotProject: a verso desta ferramenta avaliada foi a 2.1.1 web disponvel para acesso em
http://www.dotproject.net/demo. Caracteriza-se por ser um software livre, de cdigo aberto e
distribudo sob a licena GNU-GPL (General Public License).
c) JExpChannel: foi avaliada a verso 2.0 da ferramenta. Auxilia as empresas a controlar seus
portflios, programas e projetos, conforme as melhores prticas e padres internacionais
consolidados (JEXPERTS, 2008). Alm disso, tem como propsito auxiliar as empresas a atingir
os objetivos traados, garantindo a entrega dos produtos ou servios na forma acordada e dentro
das restries de oramento e cronograma.
Ferramentas para estimativas

a) Software USC - COCOMO II: uma ferramenta de anlise que tem como objetivo gerar um
resultado automatizado de estimativa para facilitar a gerncia de software. A verso utilizada
para a anlise de 2000, foi desenvolvido pela University of Southern Califrnia e est
127
disponvel
para
download
no
site
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html.
b) Cost Xpert: destina-se a realizar estimativas de tempo e custo em projetos de desenvolvimento

de software e est na verso 3.5 que foi a utilizada nesta avaliao. Os modelos/tcnicas
relacionados a este guia apresentados pela ferramenta so anlise por pontos de caso de uso,
anlise por pontos de funo (em diferentes verses), linhas de cdigo.
Ferramenta Genrica
a) Microsoft Excel: uma planilha eletrnica que pode funcionar como um administrador de todos
os tipos de dados. Apresenta diversos recursos de clculos fazendo com que a maioria das
pessoas o utilize para criar planilhas de clculos nas mais diversas reas financeiras, estatsticas
e at operaes de matemtica bsica. A ferramenta no especfica para gerenciamento de
projetos ou estimativas de software, porm com esta foi possvel criar quase todos os templates
utilizados e abordados no guia, com exceo das cartas do planning poker e modelos para
criao de estrias. A verso avaliao foi a 2007.
5.6.1 Consideraes sobre as ferramentas

O Quadro 18 apresenta um comparativo entre as ferramentas e os requisitos analisados em
cada uma destas considerando os objetivos do projeto, em que h 3 alternativas de atendimento aos
requisitos elencados: totalmente Atendido (), Parcialmente atendimento ( ) e No Atendido ( ).
Requisitos
Ferramentas
Microsoft Project
DotProject
JExpChannel
USC-COCOMO II
Cost Xpert
Microsoft Excel
01
02
03
04
05
06
07
08
09
10
11
Quadro 18 - Relao ferramentas e requisitos
128
12
13
14
Pode-se perceber de acordo com o Quadro 18 que nenhuma das ferramentas apresenta todas
as caractersticas elencadas nos requisitos que contemplam atividades relacionadas ao processo de
estimativa. De forma geral, as ferramentas voltadas ao gerenciamento de projetos no apresentam
recursos especficos referentes a estimativa, bem como, as ferramentas direcionadas a estimar no
apresentam funcionalidade que envolvam as atividades relacionadas a gerncia de projetos. J a
ferramenta genrica apresentada apresenta recursos que permitem adaptaes de forma a comportar
totalmente ou parcialmente cada um dos requisitos do guia.
Outra relao interessante de ser realizada entre as ferramentas e os modelos/tcnicas
abordados neste guia. O Quadro 19 apresenta este relacionamento para facilitar a seleo de
ferramentas pelas organizaes. Para representar a existncia de suporte ao modelo/tcnica na
ferramenta : totalmente () se a ferramenta tem a contemplao do modelo/tcnica na sua
concepo; parcialmente ( ) no caso de ser possvel realizar, mas no ter concepo do suporte ao
modelo/tcnica; No existncia de suporte aos modelos/tcnicas abordados no guia ( ).
Ferramentas
Modelos/tcnicas
Estimativa por analogia
Estimativa PERT
Opinio especializada
Linhas de cdigo
Wideband delphi
Anlise por pontos de
funo
Anlise por ponto de casos
de uso
COCOMO II
Planning poker
Tcnica do planning game
Microsoft
Project
DotProject
JExpChannel
USCCOCOMO
II
Cost
Xpert
Microsoft
Excel
Quadro 19 - Relao ferramentas e modelos/tcnicas suportados.
Neste sentido, torna-se interessante as empresas realizar um estudo das ferramentas

apresentadas e utiliz-las em conjunto para possibilitar a execuo do processo de estimativa de
software, considerando especificamente os parmetros escolhidos a este projeto, o mais adequado
possvel. Como soluo pode-se optar pelo uso de uma ferramenta genrica que permite o clculo
de todos os dados obtidos por meio da aplicao dos modelos e/ou tcnicas abordados
129
5.7 AVALIAO DE CONFORMIDADE

Neste tpico deseja-se apresentar o alinhamento entre o guia de estimativa de software e o
guia PMBOK, alm do alinhamento entre o guia de estimativa de software e os modelos de
melhoria de processo (CMMI-DEV, ISO/IEC 15504 e o MPS.BR).
A representao para o grau de alinhamento com o PMBOK e os modelos de melhoria de
processo ser da seguinte forma: totalmente () se houver alinhamento completo; parcialmente
( ) se parte dos itens forem atendidos; ( ) no caso de no haver alinhamento qualquer.
A anlise apresentada no Quadro 20 foi realizada observando o que o guia PMBOK sugere
com relao a estimativas e a abordagem realizada por este guia de estimativas de software. De
forma qualitativa, comparou-se o guia apresentado neste trabalho com o PMBOK para identificar o
embasamento do guia de estimativa com o PMBOK.
O Quadro 20 refere-se a relao entre PMBOK e o guia de estimativa proposto.
PMBOK
Atendimento
Guia
Processo genrico (captulo 4)

Template (captulo 6)
Exemplos (captulo 7)
Ferramentas (captulo 8)

Estimativa de recursos da atividade
Estimativa de durao da atividade
Quadro 20 - Alinhamento com o PMBOK
O Quadro 20 foi realizado considerando o objetivo primordial do guia que a determinao

de um processo de estimativa de software e aplicao de tcnicas e modelos de estimativa de
software.
As estimativas de recursos de atividades e durao de atividade alm de serem apresentadas
como contedo (captulo 3), so tambm apresentadas como suporte para serem realizadas em
processo genrico (captulo 4), modelos/tcnicas (captulo 5), template (captulo 6), exemplos
(captulo 7) e ferramentas (captulo 8).
130
Com relao ao contedo o guia contempla um resumo sobre o guia PMBOK e em

especfico as estimativas de recurso de atividades e durao de atividade so detalhadas segundo as
observaes do guia de gerenciamento de projetos o PMBOK.
No que se refere ao processo genrico este apresenta assim como no PMBOK entradas
possveis de serem exigidas para a realizao destas estimativas, atividades meio que identificam o
que fazer para estabelecer uma estimativa e sada que diz respeito ao encontro da estimativa
propriamente dita.
Com intuito de atender ao quesito no PMBOK que indica ferramentas para que as
estimativas sejam realizadas so apresentados no guia proposto modelos/tcnicas de estimativas,
templates, exemplos e ferramentas. Estes tem por intuito auxiliar na execuo do processo de
estimar considerado no guia.
O Quadro 21 refere-se a relao entre os modelos de melhoria de processo (CMMI-DEV,
MPS.BR, ISO/IEC 15504) e o guia de estimativa proposto.
131
CMMI-DEV 1.2
MPS-BR 1.2
ISO/IEC 15504-5:2006
Prtica
especfica
1.2
Estabelecer estimativas de
produtos de trabalho e
atributos de tarefas
GPR 2. As tarefas e os
produtos de trabalho do
projeto so dimensionados
utilizando
mtodos
apropriados;
Prtica
Base
4:
Determinar e manter
estimativas
para
os
atributos do projeto (RP 2
e 3).
Prtica
especfica
1.4
Determinar estimativa de
esforo e custo
GPR 4. Define o esforo e

o custo para a execuo
das tarefas e produtos de
trabalho so estimados
com base em dados
histricos ou referncias
tcnicas;
Prtica
2.1
GPR 5. O oramento e o
Prtica Base 7: Definir
Estabelecer o oramento e
cronograma do projeto,
cronograma projeto (RP
cronograma tendo como
incluindo
5)
base
pontos de controle, so
especfica
as
desenvolvidas
estimativas
marcos
e/ou
Atendimento
Guia

Templates (captulo 6)

Templates (captulo 6)

estabelecidos e mantidos;
Quadro 21 - Alinhamento CMMI-DEV, MPS.BR, ISO/IEC 15504 e o guia de estimativa
132
As atividades que determinam o estabelecimento de estimativas so atendidas pelo guia por

serem foco deste e so mais especificamente detalhadas no processo genrico (captulo 4),
templates (captulo 6), exemplos (captulo 7), e ferramentas (captulo 8).
Por meio do processo genrico o guia apresenta como as estimativas podem ser obtidas
definindo entradas possveis de serem exigidas pelas tcnicas que sero adotadas; o processo define
tambm atividades meio como a definio dos parmetros que sero estimados, a aplicao do
modelo/tcnica que seja mais adequado a MPE em questo e a documentao das atividades
realizadas; e ainda atividade de sada.
Atendendo ainda a primeira linha da tabela que se refere a prticas de estimativas de
produtos de trabalho e atributos de tarefas tem-se os captulos 6 e 7 do guia em que so
apresentados respectivamente, templates e exemplos. Estes so apresentados a fim de auxiliar no
processo de aplicao dos modelos/tcnicas sugeridos que possibilitam realizar as estimativas
solicitadas nas referidas prticas. J as ferramentas apresentadas no captulo 8 do guia so
apresentadas como uma forma de auxiliar na obteno e armazenamento de estimativas.
Com relao as prticas relativas a determinao e definio de esforo e custo apontados no
CMMI-DEV e MPS.BR o guia est em alinhamento, em virtude de estimativa de custo estar fora do
escopo deste trabalho, alm do que tais modelos aceitam que as empresas atendam a estas prticas
sem utilizar custo mas sim a varivel esforo apenas.
No entanto, cabe destacar que as informaes pertinentes a estimativa de esforo podem ser
obtidas por meio da aplicao dos vrios modelos/tcnicas apresentados no guia, atendendo ao que
pede a Prtica especfica 1.4 do CMMI-DEV e ao MPS.BR GPR 5. Alm de apresentar vrios
modelos e tcnicas que possibilitam identificar o esforo necessrio a determinado projeto, tambm
se torna possvel visualizar a definio do que esforo e como compreendido e desejado nos
modelos de melhoria de processo de software destacados.
A ltima linha do quadro contempla prticas referentes a oramento e cronograma. O
primeiro no foco deste trabalho, embora o guia fornea subsdios para cri-lo. Quanto ao
cronograma as informaes como esforo e durao fornecem informaes que possibilitam a
criao deste, entende-se assim que guia atende totalmente a este quesito.
133
Por meio desta anlise pode-se perceber que o guia atende a proposta de estar alinhado aos
modelos CMMI-DEV, MPS.BR e norma ISO/IEC 15504 no que se refere a atividade de estimativa
de software. As prticas relacionadas a norma e modelos citados, esto contempladas ao observar os
captulos apresentados no guia, o contedo disponvel e os resultados que se pode obter pela sua
aplicao.
134
6 AVALIAO DO GUIA
Neste captulo descreve-se o processo de avaliao do guia de estimativa de software
proposto neste trabalho. A avaliao aplicada tem por base o mtodo GQM, iniciando pelo
planejamento em que se definiu o que, como e quando a avaliao seria realizada, em seguida
houve a execuo do planejado com intuito de coletar dados, por meio de um questionrio aplicado
junto a especialistas em Engenharia de software que possuem conhecimento nas reas de gerncia
de projeto, estimativas de software e em modelos de melhoria de software. Por fim, realizou-se a
anlise dos dados identificando o alcance do objetivo definido para a avaliao.
Neste sentido, so detalhados a seguir o planejamento, a execuo e a anlise da avaliao
do guia de estimativas.
6.1 PLANEJAMENTO DA AVALIAO

A avaliao do guia de estimativa de software se torna relevante inicialmente para que se
possa verificar se atende aos requisitos elencados e desejados para o guia, alm de identificar se a
sua utilizao pode orientar na definio de um processo de estimativa de projetos de software. Em
um segundo momento se busca com a avaliao identificar problemas e sugestes de melhoria para
o referido guia.
Para esta avaliao utilizado o mtodo GQM (BASILI, CALDIERA, ROMBACH, 1994)
em que inicialmente deve-se identificar objetivos da avaliao, e em seguida tendo como base os
objetivos, perguntas so definidas
para que estes sejam alcanados. Cabe destacar que estas
perguntas no sero necessariamente utilizadas na coleta de dados junto aos participantes da

pesquisa. Cada pergunta deve possuir medida(s) relacionada(s) que sero foco para a realizao da
coleta de dados. Cabe ressaltar, que para estas medidas torna-se necessrio definir como estas sero
coletadas, quem ir fornec-las e quando.
Os dados advindos da pesquisa so em sua maioria qualitativos por se tratar de uma
pesquisa exploratria, alm de subjetivos tendo como base a experincia dos pesquisados que so
profissionais que possuem ao menos curso e/ou prova de do nvel introdutrio em MPS.BR e
conhecimento em modelos de melhoria de processo de software.
O objetivo de medio da avaliao foi identificado com base na pergunta de pesquisa do

trabalho que pretende saber se: a utilizao de um guia de estimativas contribui, em termos de
facilidade e eficincia, para definio de um processo de estimativa de projetos (tamanho de
software, durao e esforo de durao) em MPEs de software, de forma a orientar na
implementao de modelos de melhoria de processo de desenvolvimento de software, em
consonncia aos requisitos elencados e desejados ao guia proposto. Logo, acredita-se que caso o
guia apresente estes requisitos fornecer subsdios para responder a pergunta de pesquisa da
dissertao.
Objetivo de Medio: Avaliar o guia de estimativa de software em relao ao atendimento
dos requisitos estabelecidos (captulo 4) sob o ponto de vista de engenheiros de processo
especialistas no contexto de programas de melhoria de processos de software em MPEs.
Cabe esclarecer que por engenheiro de processo com conhecimento no contexto de
programas de melhoria de processos de software, entende-se pessoas com formao voltada a rea
de engenharia de software (pode-se citar cursos de Cincia da Computao, Engenharia de
computao ou reas afins e/ou ainda ps-graduao na rea) e que tenham conhecimento em algum
programa de melhoria de processo de software.
Seguindo o GQM deve neste momento, indicar perguntas para medio e quais as medidas
deseja-se obter pela avaliao proposta, observando o objetivo de medio, conforme Quadro 22.
Pode-se perceber que as perguntas 01, 03, 08 possuem um carter subjetivo, pois partir de uma
suposio do respondente j que no haver a aplicao do guia para responder com efetividade as
questes. Cabe ressaltar, que no haver possibilidades de aplicao em virtude de no se ter
empresa em processo de implantao de modelos de melhoria de processo em que seria possvel
aplicar o guia e tambm pelo grande volume de atividades necessrio a sua aplicao.
136
Objetivo
Pergunta Q01:
Avaliar o guia de estimativa de software em relao ao atendimento dos

requisitos estabelecidos sob o ponto de vista de engenheiros de processo
experientes no contexto de programas de melhoria de processos de software
em MPEs.
PERGUNTAS
Qual a facilidade, considerando o esforo necessrio,
para aplicao do guia em uma MPE de software?
Pergunta Q02:
O guia apresenta contedo suficiente para o

entendimento, por um leigo, do processo de
estimativa contemplado na fase de planejamento?
Pergunta Q03:
O contedo sobre tcnica de estimativas do guia est

suficiente para o entendimento e aplicao destas por
um leigo em estimativas de software?
As tcnicas de estimativas propostas no guia esto
adequadas as MPEs de software?
Pergunta Q04:
Pergunta Q05:
Pergunta Q06:
Pergunta Q07:
Pergunta Q08:
Os exemplos apresentados no guia auxiliam no

entendimento da aplicao dos modelos e tcnicas de
estimativas?
Os templates esto adequados aos modelos e tcnicas
de estimativas apresentados?
As ferramentas indicadas no guia podem indicar uma
forma de automao? Automao ou suporte? do
processo de estimar?
Um processo de estimar com qualidade pode ser
definido de forma mais rpida quando da utilizao
do guia, comparando com a no utilizao deste?
Pergunta Q09:
Quantas fontes alm do guia para implantao do

processo de estimar seriam necessrias utilizar?
Pergunta Q10:
O guia est baseado no PMBOK?
Pergunta Q11:
Qual o atendimento do guia no que se refere ao

processo de estimativa nos modelos de melhoria
(CMMI DEV, MPS.BR, ISO/IEC 15504)?
MEDIDAS
MQ1.1. Impresso subjetiva do
percentual de variao do esforo
com o uso do guia.
MQ2.1. Lista de atividades do
processo que no esto claras.
processo que o guia no apresenta
contedo de modelos/tcnicas de
estimativa apresentado no guia.
MQ4.1Lista
de
tcnicas
inadequadas
MQ4.2 Lista de tcnicas no
apresentadas e adequadas as MPEs.
MQ5.1. Lista de exemplos que no
esto a contento.
MQ6.1 Lista de templates que
devem ser revisados.
MQ7.1
Indicao
de
outras
ferramentas.
MQ8.1 Impresso subjetiva do
percentual de variao do tempo
com uso do guia comparando a no
utilizao.
MQ09.1 Quantidade de outras
fontes necessrias.
MQ09.2 Indicao de outras fontes.
MQ10.1. Percentual de no
atendimento do guia ao PMBOK.
MQ10.2 Lista de requisitos que no
so atendidos.
MQ11.1 Percentual de alinhamento
ao CMMI-DEV
MQ11.2.
Lista
de
prticas
especficas no atendidas.
ao MPS.BR.
MQ11.4 Lista de GPR- a sigla esta
introduzido antes? no atendidos.
a ISO/IEC 15504
MQ11.6 Lista de prticas base no
atendidas.
Quadro 22 - Perguntas GQM e mtricas
137
Com base nas perguntas da avaliao criadas para alcanar o objetivo proposto, juntamente
com as medidas indicadas, derivado o plano de coleta de dados em que se apresenta a medida
relacionada a forma como os dados referentes a esta sero coletados e quem ser responsvel por
fornecer os dados necessrios, como se pode observar no Quadro 23.
138
Medida
Como coletar?
Quem coleta?

percentual de variao do esforo
com o uso do guia.
Questionrio Pergunta 01(apndice a)
Engenheiro de processo



MQ4.1Lista de tcnicas inadequadas.


esto a contento.

MQ7.1
Indicao
ferramentas.

percentual de variao do tempo com
uso do guia comparando a no
utilizao.
MQ09.1 Quantidade de outras fontes

necessrias.
MQ10.1.
Percentual
atendimento ao guia.

so atendidos.

ao CMMI-DEV.
MQ11.2.
Lista
de

ao MPS.BR.
Questionrio Pergunta 12 (apndice a)
MQ11.4 Lista
atendidos.
MQ11.5 Percentual de alinhamento a

ISO/IEC 15504.

atendidas.
de
de
outras
de
no
prticas
GPR
no
Quadro 23 - Resumo dos procedimentos de coleta de dados
139
Esta avaliao utilizou como tcnica de coleta de dados um questionrio aplicado junto a
profissionais no mbito do LQPS e UNIVALI, que fizeram ao menos curso e/ou prova de do nvel
introdutrio em MPS.BR e foram aprovados pela SOFTEX e apresentam diferente nveis de
experincia na rea, variando entre pouca e mdia, considerando o conhecimento em Engenharia de
Software.
Inicialmente, criou-se um questionrio (Apndice A) para identificar o perfil do pesquisado
para que ajudasse na anlise dos dados obtidos uma vez que a experincia e conhecimento dos
mesmos na rea influenciam nos dados coletados. Em seguida so apresentadas as perguntas
direcionadas a obteno das medidas desejadas e elencadas no GQM.
A interpretao dos dados foi realizada em sua maioria de forma qualitativa por meio de
anlise de contedo, em que dados obtidos em atividades individuais (questionrios e entrevistas)
so registrados, tabulados por categorias de anlise e posteriormente descritas no captulo da anlise
e descrio dos dados da pesquisa. (MINAYO, 1994). Buscou-se por meio desta anlise apresentar
resposta ao objetivo de medio que se refere ao atendimento aos requisitos elencados como
interessante de se ter em um guia deste tipo. Cada pergunta do questionrio derivada do GQM ser
analisada individualmente considerando o perfil dos respondentes.
6.2 EXECUO
A realizao desta pesquisa foi realizada com a primeira verso do guia finalizada (v. 1.1),
em que constavam todos os captulos finalizados com exceo do captulo de ferramentas em que a
Ferramenta Microsoft Excel ainda no havia sido descrita. Outro aspecto que no constava nesta
primeira verso refere-se a avaliao de conformidade do guia com o PMBOK e de alinhamento do
guia com os modelos de melhoria de processo (CMMI-DEV, MPS.BR e ISO/IEC 15504). Alm
disso, o guia no havia sido revisado por completo em toda sua estrutura e contedo, por exemplo,
na tcnica de anlise por pontos de funo outros grupos de pesquisa na rea ainda no haviam sido
apresentados.
Foram identificados, com base nas caractersticas desejadas os respondentes no mbito da
UNIVALI e LQPS e que tambm atuam profissionalmente na grande Florianpolis, sendo que a
amostra da pesquisa teve definidos seis participantes.
140
Por meio da aplicao do questionrio referente ao perfil dos pesquisados, pode-se perceber
que os entrevistados, na sua maioria, possuem formao acadmica voltada a rea do trabalho e
todos possuem ou cursam especializao em Engenharia de Software. Dos entrevistados trs atuam
na implantao ou consultoria de modelos de melhoria de software, sendo que o tempo varia entre 2
e 5 anos. Cabe destacar ainda que quatro destes possuem experincia na rea de estimativa de
software, sendo que o tempo varia de 2 a 10 anos.
A pesquisa foi realizada por meio do envio do questionrio aos participantes no incio do
ms de janeiro eletronicamente e sendo devolvido por estes da mesma forma no incio do ms de
fevereiro (06/01/2009 a 10/02/2009). Os respondentes receberam alm do questionrio, o guia de
estimativa de software e por meio da leitura deste foi possvel aos participantes informar os dados
solicitados para responder ao objetivo desta pesquisa.
Ressalta-se que todas as questes objetivas foram respondidas pelos participantes da
pesquisa. No que se refere aos questionamentos subjetivos percebeu-se que todos responderam ao
menos a questes com explicaes quando a resposta no era o percentual total ou a opo
TOTALMENTE. Apenas 1 dos participantes fez apenas 1 explicao, acredita-se por ser o menos
experiente dos respondentes da pesquisa. As respostas corroboraram para que fosse possvel obter
dados relevantes para o guia. As questes em que se solicitou indicao por parte do respondente
deixou a desejar apresentando poucas sugestes ao guia.
Durante o ms de aplicao foram trocadas informaes com os respondentes para saber se a
pesquisa transcorria de maneira adequada e nenhum dos participantes fez qualquer questionamento
ou apresentou dificuldades na realizao da avaliao. O questionrio de avaliao foi enviado a
seis participantes, sendo que apenas um deixou de respond-lo.
Embora no tenha sido possvel aplicar em uma empresa o guia e no se tenha obtido um
nmero maior de respondentes, foi possvel avaliar que os resultados iniciais obtidos pela avaliao
apresentam indcios da possibilidade da aplicao do guia em empresas com pretenses de
implantar modelos de melhoria de software.
6.3 ANLISE DOS DADOS COLETADOS

Neste tpico so apresentadas as perguntas do GQM e suas referidas medidas para que
sejam conhecidos os dados coletados por meio da aplicao do questionrio (Apndice A) e
141
verificado o atendimento ao objetivo proposto. So realizadas tambm anlises referentes a

respostas, perfil de respondente e caractersticas do guia.
Objetivo de Medio: Avaliar o guia de estimativa de software em relao ao atendimento
dos requisitos estabelecidos (captulo 4) sob o ponto de vista de engenheiros de processo
conhecedores do contexto de programas de melhoria de processos de software em MPEs.
Pergunta
Q01:
Qual a facilidade, considerando o esforo MQ1.1. Impresso subjetiva

necessrio, para aplicao do guia em uma do percentual de variao do
MPE de software?
esforo com o uso do guia.
[01-25 / 26-50 / 51-75 / 75-100]
Por ser uma pergunta subjetiva houve uma variao considervel entre os percentuais
sugeridos pelos participantes conforme Grfico 3.
Grfico 3 Variao do esforo para aplicar o guia
Cabe ressaltar que a variao de 51% a 75% foi considerada pelos pesquisados com
experincia menor na rea e que no atuam em implantao e/ou consultoria de modelos de
melhoria de software, apesar de conhecerem a atividade. Neste sentido, considera-se a variao
entre 01 a 50 % que contempla a opinio dos respondentes que possuem experincia como
consultores/implementadores de modelos de melhoria de software. Cabe destacar que um dos
respondentes escolheu a opo que afirma estar entre 1 e 25% o esforo necessrio para aplicar o
guia, sendo este considerado um resultado positivo, principalmente pelo respondente ter experincia
considervel na rea de estimativa de software e implantao de modelos de melhoria de processo
142
de software. Embora sejam opinies subjetivas torna-se relevante para que se tenha noo da
facilidade de aplicao do guia quanto a implantao de um processo de estimativa.
Percebe-se que pela subjetividade da questo os respondentes procuram deixar claro nas
justificativas das respostas a relevncia do guia. Na questo 01 salientam a contribuio do guia
pelos contedos disponveis voltados ao processo de estimar e destacam o mrito do guia por
permitir identificar os modelos mais adequados a sua necessidade.
Outra contribuio apresentada foi a necessidade da disponibilizao do guia em formato de
eletrnico, especificamente em pginas WEB. Na opinio do entrevistado facilitaria a sua
implantao, pela melhor possibilidade de navegao entre teoria, templates e exemplos.
Destaque tambm para a dependncia da experincia do projetista, que influencia na
implantao de um processo de estimar, impondo certa dificuldade na aplicao de um Guia, se
no houver a presena de um profissional experiente.
Considerando as explicaes e justificativas para os percentuais apontados, foi possvel
perceber que no houve resistncia ou contrariedade utilizao do guia. Pelo contrrio, as opinies
apontaram vantagens considerveis na sua utilizao, porm se desejou evidenciar que este
percentual de esforo depende da equipe de trabalho envolvida no processo.
Pergunta Q02:
O guia apresenta contedo suficiente para o

entendimento, por um leigo, do processo de
estimativa contemplado na fase de planejamento?

[Totalmente]/[Parcialmente]/[No]
Todos os respondentes apontaram a opo PARCIALMENTE como resposta a esta

pergunta, apresentando justificativa para tal opinio.
Como a pergunta tratava do entendimento dos contedos por leigos, os respondentes
apontam mais uma vez a necessidade de algum experiente junto para aplicao do processo, como
um consultor, por exemplo.
Embora a pergunta questionasse a respeito do processo de estimar, houve apontamento de
modelos de estimativa que no esto totalmente claros na explicitao como a definio do grau de
complexidade em pontos de funo e outros termos tcnicos.
143
Pode-se perceber que embora considerem parcial o entendimento por um leigo do processo
de estimar as justificativas apontadas demonstram que no tem relao com o contedo apresentado
no guia sobre o processo de estimar sugerido. Alm disso, no houve descrio de atividades ou
contedos no claros no guia ou falta de qualquer atividade no processo de estimar descrito no guia.
Pergunta Q03:
O contedo sobre tcnica de estimativas do guia est

suficiente para o entendimento e aplicao destas por
um leigo em estimativas de software?

Para a pergunta de nmero 3 foram coletadas 2 respostas TOTALMENTE e 3 participantes

responderam PARCIALMENTE. Para o primeiro caso um dos participantes quis deixar claro de
que o guia apresenta os principais modelos, as caractersticas principais e os templates. J o
suficiente..
Os que optaram pela segunda opo indicaram novamente a necessidade de ter algum
como um consultor para o suporte. Outro apontamento diz respeito a complexidade dos
modelos/tcnicas que dificultam o completo entendimento para quem est tendo o primeiro contato
com o tema.
Cabe salientar, que o objetivo do uso do guia no est em substituir o profissional
experiente, mas contribuir para definio de um processo de estimativa e orientar na implementao
de modelos de melhoria de processo de desenvolvimento de software. Neste sentido, o contedo
deve ser base e no por si s funcionar como um auto-aprendizado aos leigos.
Pergunta Q04:
As tcnicas de estimativas propostas no guia esto

adequadas as MPEs de software?
MQ4.1Lista
inadequadas
de
tcnicas

A pergunta de nmero quatro obteve 4 respostas PARCIALMENTE e 1 TOTALMENTE na

opinio dos respondentes.
Os modelos com base em especialista, como Wideband Delphi, foram indicadas como
tcnicas difceis de serem implementadas em MPEs. Outro ponto ressaltado foi o fato de que a
144
maioria dos modelos e tcnicas exigem registro histrico apurado. Isto requer um nvel de
maturidade mais alto das organizaes que no encontrado em MPEs de software no incio de um
programa de melhoria. Citou-se tambm que a adequao dos modelos dependeria do projeto que
estivesse sendo realizado.
Como tcnicas consideradas no adequadas s MPEs foi citado o modelo COCOMO II e
como tcnicas no apresentadas sugeriu-se comentar sobre a existncia de outros grupos que
estudam a anlise por ponto de funo como o Nesma.
Com relao aos modelos baseados em especialista cabe destacar que uma empresa que
inicia um processo de implantao de um modelo de melhoria, via de regra, necessita de
especialistas em sua equipe de trabalho.
Embora os modelos e tcnicas mais conhecidos e utilizados sejam apontados no guia e
dependam de alguns aspectos para serem aplicados se a empresa deseja implantar um processo de
estimativa de software, ser necessrio optar por uma das tcnicas apresentadas, visto que so as
mais aplicadas.
Pergunta Q05:
Os exemplos apresentados no guia auxiliam no

entendimento da aplicao dos modelos e tcnicas de
estimativas?

esto a contento.
Com relao a pergunta de nmero 5, na obteno dos dados dos questionrios respondidos
percebeu-se que 4 dos participantes respondeu que os exemplos estavam TOTALMENTE a
contento. Apenas 1 dos respondentes considerou que os exemplos estavam apenas atendendo
PARCIALMENTE o seu objetivo.
Como sugesto foi indicado a justificativa de valores que fazem parte das tcnicas e
modelos e tambm um maior detalhamento na execuo destes.
Pelos nmeros obtidos pode-se perceber que a maioria dos respondentes considerou
adequados os exemplos apresentados no guia. Cabe destacar, que dentre os participantes com esta
opinio h uma variao na experincia o que relevante, pois tanto os mais experientes quanto
menos experientes puderam compreender o que foi apresentado. No entanto, as indicaes
apresentadas sobre melhorias sero consideradas.
145
Pergunta Q06:
Os templates esto adequados aos modelos e tcnicas

de estimativas apresentados?

Para a questo de nmero 6, dos 5 participantes 3 consideraram os templates

TOTALMENTE adequados e 2 PARCIALMENTE.
Os respondentes que consideraram os templates parcialmente adequados justificaram a
opo destacando revises em alguns templates, para que possam ser aplicados de forma melhor.
Um dos participantes chamou a ateno para que na apresentao dos resultados obtidos nos
templates as unidades para esforo, durao e tamanho, sejam apresentadas de forma mais clara
para evitar inconsistncia nos resultados.
Outra considerao relevante foi a respeito do template da tcnica do Planning Poker, em
que o participante julgou que no seria necessrio armazenar as estimativas de todos os
estimadores, mas somente a estimativa final obtida por consenso.
Alm disso, tambm foi sugerido que no template da tcnica do Wideband Delphi, seria
interessante ter outro template destinado aos estimadores em que teria uma lista de todas as
atividades a serem estimadas, assim como informaes dos valores mdios e desvio padro do que
foi estimado anteriormente.
As observaes dos participantes sero consideradas para que se possa corrigir e aperfeioar
os templates sugeridos. Considerando principalmente as sugestes referentes Planning Poker e
Wideband Delphi em que h uma experincia considervel do respondente.
Pergunta Q07:
As ferramentas indicadas no guia podem indicar uma

forma de automao? Automao ou suporte? do
processo de estimar?
MQ7.1
Indicao
ferramentas.
de
outras
Para a questo de nmero 7 na coleta de dados pode-se identificar que 3 dos participantes
respondeu TOTALMENTE e 2 PARCIALMENTE e estes ltimos apresentaram justificativa
resposta escolhida.
146
Uma das justificativas apresentadas foi que o respondente conhecia quase todas as
ferramentas apresentadas e que embora auxiliem no processo torna-se necessrio que os usurios
conheam as tcnicas e tambm como aplic-las de forma consistente.
Alm disso, outra justificativa por um dos respondentes com mais experincia relata que
pelo que foi apresentado no guia por meio das avaliaes e tambm pela atividade prtica deste
participante na rea, percebe-se que o suporte das ferramentas em geral ao processo de estimativa
muito fraco.
Cabe destacar que conforme anlise apresentada sobre as ferramentas (seo 6.6) estas no
suportariam todo o processo de estimativa, no texto da seo 6.6 afirma-se nenhuma das
ferramentas apresenta todas as caractersticas elencadas nos requisitos que contemplam atividades
relacionadas ao processo de estimativa.
Pergunta Q08:
Um processo de estimar com qualidade pode ser

definido de forma mais rpida quando da utilizao
do guia, comparando com a no utilizao deste?

percentual de variao do tempo
com uso do guia comparando a no
utilizao.
[01-25 / 26-50 / 51-75 / 75-100]
Na questo de nmero 8 os respondentes deveriam opinar se seria mais rpido estabelecer

um processo de estimar com qualidade em uma MPE utilizando o guia em detrimento a sua no
utilizao. Tambm deveriam indicar um percentual de quanto mais rpido seria. Dos participantes
2 indicaram TOTALMENTE e 3 PARCIALMENTE.
Dois dos participantes que optaram por totalmente apresentam o indicativo de percentual
entre 76 e 100. Cabe destacar que estes possuem experincia relevante em implantao/consultoria
modelo de processos de melhoria de software. Um dos participantes indicou de 56 a 75% sendo que
este possui uma experincia mediana na atividade. Entre 26 e 50% foi a indicao dos dois
participantes mais inexperientes na atividade.
Os candidatos que optaram por totalmente, fizeram justificativas sobre sua escolha,
argumentando que por meio do guia possvel conhecer tcnicas e ferramentas e identificar a(s)
147
mais adequada(s) para cada caso, alem de que possvel a utilizao do guia como instrumento de
estudo e levantamento bibliogrfico.
Na opinio de outro participante pelos exemplos prticos e tambm por meio da leitura dos
templates, a tendncia a reduo do esforo necessrio ao aprendizado dos modelos e tcnicas, j
que no caso da no existncia do guia deveria ser empregado em pesquisas na internet, ou na
elaborao de material semelhante na organizao.
Pode-se identificar que subjetivamente a tendncia que a utilizao do guia possa diminuir
o tempo de processo de 50 a 100%, pois estas foram opinies de participantes com mais experincia
na implantao/consultoria de modelos de melhoria de software. No houve argumentos vindos
daqueles que consideraram um percentual mais baixo (26% a 50%).
Pergunta Q09:
Quantas fontes alm do guia para implantao do

processo de estimar seriam necessrias utilizar?
MQ09.1 Quantidade
fontes necessrias.
de
outras
Para saber se as fontes existentes no guia estavam suficientes para a implantao do

processo de estimar, identificando quantas mais seriam necessrias e quais seriam, foi criada a
questo de nmero 9 do questionrio (Apndice A). Os respondentes deveriam indicar o nmero de
fontes necessrias e tambm indicar quais seriam estas.
Na maioria, 4 dos participantes, indicaram que as fontes eram suficientes para a implantao
do processo. Embora tenham argumentado que dependeria de qual modelo o engenheiro de
processo adotaria para isto, pois no momento da implantao talvez se julgasse necessrio, como
exemplo, pesquisar na fonte original da tcnica ou modelo.
O participante que indicou referncia sugeriu material especfico sobre o modelo ou tcnica
selecionado e pesquisa em sites oficiais e dos grupos dos modelos ou tcnicas adotados.
O guia possui compilaes das principais fontes sobre os modelos e tcnicas propostos,
fornecendo neste caso, vrias referncias sobre estes no caso de um melhor detalhamento sobre o
tema. Alm disso, em cada modelo/tcnica referncia adicionais especifcas destes so indicadas ao
final da explanao e detalhamento no guia.
148
Pergunta Q10:
O guia est baseado no PMBOK?
MQ10.1. Percentual de atendimento

do guia ao PMBOK.
so atendidos.
[01-25 / 26-50 / 51-75 / 75-100]
A pergunta Q10 tinha como objeto identificar se o guia est baseado no PMBOK, no que se
refere ao processo de estimativa, a idia no era que os engenheiros de processo formalmente
verificassem o embasamento ou no, mas que fosse possvel obter mais sugestes de melhoria para
o guia. A variao apresentada no grfico 10 deve-se a subjetividade da questo.
Grfico 4 Indicativo percentual sugerido de base no PMBOK
Pelo grfico de nmero quatro pode-se perceber que a base do guia no PBMOK varia de 50
a 100%. Interessante ressaltar que as duas opinies referentes a variao de 76 a 100% refere-se a
respondentes com maior experincia do que os respondentes de 51 a 75%.
Os participantes argumentaram a respeito desta questo apontando que cada processo no
PMBOK seria em iniciao, planejamento, execuo, controle e finalizao e este
desenvolvimento no fica claro no guia.
Outro comentrio destaca que o guia atende ao estabelecido na referncia PMBOK pela base
conceitual no texto. O PMBOK um guia genrico e aborda estimativa de um nvel mais
abrangente, j o guia de estimativas proposto est mais concentrado em software devido as suas
caractersticas especficas.
A proposta de basear o guia no PMBOK estava considerando apenas o processo de estimar
proposto no guia de referncia de gerncia de projetos referenciado. Neste sentido, descreveu-se de
que forma o PMBOK trata as estimativas contempladas e outros processos envolvidos como o
149
escopo. No prprio processo de estimativa sugerido pelo guia de estimativa utiliza-se a estrutura do
PMBOK, por ser este base para seu desenvolvimento.
Pergunta Q11:
Qual o atendimento do guia no que se refere ao

processo de estimativa nos modelos de melhoria
(CMMI DEV, MPS.BR, ISO/IEC 15504)?

ao CMMI-DEV
[01-25 / 26-50 / 51-75 / 75-100]
MQ11.2.
Lista
de
prticas

ao MPS.BR.
[01-25 / 26-50 / 51-75 / 75-100]
MQ11.4 Lista de GPR- a sigla esta
introduzido antes? no atendidos.
a ISO/IEC 15504
[01-25 / 26-50 / 51-75 / 75-100]
atendidas.
Na pergunta Q11 do GQM tinha-se como intuito subjetivamente identificar o percentual de

alinhamento do guia aos modelos de melhoria de processo considerados no guia: CMMI-DEV,
MPS.BR e ISO/IEC 15504, alm de identificar quais prticas especficas no so atendidas pelo
guia proposto. Cabe ressaltar como na pergunta Q11 no se tinha a inteno de uma verificao
formal dos engenheiros de processo sobre o alinhamento ou no com os modelos, mas que se
fossem obtidas outras sugestes de melhoria para o guia. Neste sentido foram criadas 3 perguntas
no questionrio (apndice A) para responder a pergunta Q11.
De forma geral, os respondentes selecionaram o percentual que consideram adequados e
comentaram suas respostas, mas um dos participantes no respondeu aos questionamentos, por
acreditar que esta avaliao dependeria do modelo a ser definido.
As questes de nmero 11, 12 e 13 solicitavam informaes sobre o alinhamento
respectivamente dos modelos de melhoria CMMI-DEV, MPS.BR e ISO/IEC 15504. O grfico 5
apresenta um comparativo entre o alinhamento dos modelos citados.
150
Grfico 5 Comparativo do percentual de alinhamento aos modelos de melhoria de processo
Pode-se perceber que cada participante na sua avaliao selecionou o mesmo intervalo
percentual ao alinhamento para cada um dos modelos de melhoria de processo foco do guia de
estimativa de software proposto.
No entanto, foram realizados comentrios sobre o alinhamento do guia ao modelo CMMIDEV. Foi citado que para nveis de maturidade mais elevados torna-se necessria a utilizao de
estimativas estatsticas, pois as que no se utilizam de estatsticas no seriam totalmente aceitas
em uma avaliao oficial. O mesmo sendo considerado para os outros dois modelos MPS.BR e
ISO/IEC 15504-5.
De acordo com os dados coletados, pode-se verificar que de maneira geral h o alinhamento
com os modelos. Com relao ao comentado a respeito dos modelos referente a modelos/tcnicas
no estatsticas, no se torna um fator de no alinhamento j que h no guia modelos paramtricos e
modelos/tcnicas baseados em opinies especializadas e dados histricos.
Este tpico teve como intuito apresentar os resultados da pesquisa realizada para avaliao
do guia de estimativa de software a partir dos requisitos elencados para o guia no captulo 5 deste
trabalho. Com base neste foi criado um planejamento por meio do GQM para medio do guia de
software.
Alm disso, foi possvel tambm avaliar que o contedo constante no guia suficiente as
necessidades da implantao de um processo de estimativa de software. A mesma constatao podese ter para a estrutura do guia quanto a modelos e tcnicas descritos, exemplos e templates e ainda
as ferramentas apresentadas.
151
Neste sentido, fica evidente a necessidade da realizao de aplicao em empresas,

preferencialmente em mais de uma, para que se possa obter uma avaliao em que sero obtidos
dados e resultados da anlise com maior confiana.
H indcios pela avaliao realizada junto aos engenheiros de processo que o uso do guia
poder contribuir em termos de facilidade e eficincia na definio de um processo de estimativa de
software em MPEs alinhado aos modelos de melhoria de processo de software, considerando as
ameaas a validade desta avaliao.
6.4 AMEAAS A VALIDADE

Pode-se verificar na aplicao da avaliao alguns pontos fracos no processo como um todo.
Estes pontos podem representar ameaas a validade desta avaliao.
Inicialmente a proposta de avaliao era sua realizao em uma MPE de software para
que se pudesse validar o guia. No entanto, por no haver empresas em processo de
implantao de modelo de melhoria de processo decidiu-se pela avaliao com
engenheiros de processo. Desta forma, isto prejudicou a obteno de informaes mais
apuradas sobre eficincia e facilidade no uso do guia no auxlio as atividades do processo
de estimar. Cabe salientar que possvel a utilizao do guia em empresas que no
estejam implantando modelos de melhoria de processo, porm no seria o intuito desta
dissertao.
Considerando as caractersticas definidas e necessrias aos pesquisados, aceitaram
participar da pesquisa 6 engenheiros de processo. No entanto, responderam ao
questionrio de avaliao 5 destes. Neste sentido, o nmero pequeno de participantes
pode ter melindrado informaes e haver comprometimento na anlise de dados.
Como no houve avaliao em empresa as respostas dependeram do conhecimento e
experincia, sendo desta forma avaliaes subjetivas sobre o guia. Ressalta-se maior risco
nas perguntas do GQM 01, 08 e 11, que solicitavam dados percentuais e foram
respondidos subjetivamente pelos respondentes. Os dados obtidos pelas outras perguntas
tambm teriam um percentual mais aproximado do real caso houvesse aplicao prtica
do guia.
152
Outro fator que merece ser comentado como ameaa a viabilidade est no que concerne
ao perfil dos pesquisados. Como se pode observar nem todos possuam o mesmo tempo e
grau de experincia, alm de alguns no terem experincia na implantao de modelos de
melhoria de software (embora tenham prova nvel introdutrio do MPS.BR), o que pode
ter apresentado dados no to precisos, principalmente pela falta de experincia.
Como a pesquisa foi realizada com uma verso inicial do guia houve o risco na falta de
explicao de uma das ferramentas prejudicar na avaliao deste item. No entanto, podese perceber que os comentrios realizados no seriam diferentes, at porque os templates
do guia na sua maioria foram criados com a ferramenta em questo. De qualquer forma
deve-se considerar que algum dos respondentes poderia ter uma viso diferente no que se
refere s ferramentas. Outro ponto foi a no reviso por completo do guia o que incidiu
em alguns comentrios dos quais j se tinha conhecimento.
O fato de todos os pesquisados serem da mesma instituio pode ameaar o processo de
avaliao caso haja uma relao com prtica conhecida e aplicada pelos mesmos, alm do
fator de ser possvel o contato entre estes na realizao da avaliao. Pode-se considerar
tambm a relao dos participantes com a pesquisadora, devido ao contato no mbito da
instituio que pertencem, o que poderia mascarar dados, principalmente negativos sobre
o guia. Apesar de que se pode observar a variao entre resultados positivos e negativos
na avaliao.
Independente das ameaas apresentadas pesquisa em questo acredita-se que pelo objetivo
desejado com esta que seria avaliar o guia considerando os requisitos elencados este foi alcanado
de acordo com engenheiros de processo participantes da pesquisa. Alm disso, verificou-se a
viabilidade de sua aplicao em uma MPE e conseqentemente sua avaliao possibilitando alcance
de resultados com dados reais.
A avaliao possibilitou tambm a identificao de pontos que podem ser melhorados e
aperfeioados na verso do guia colocada disposio dos respondentes e participantes da pesquisa
realizada.
153
7 CONCLUSES
Neste trabalho, em atendimento ao seu objetivo principal, desenvolveu-se um guia de
estimativas de software contemplando os parmetros de tamanho, esforo e durao, com foco nas
MPEs. Alm disso, houve a preocupao em apresentar seu embasamento com guia PMBOK e
alinhamento aos modelos de melhoria de processo CMMI-DEV, MPS.BR e ISO/IEC 15504-5.
Em especial o guia se destina a MPEs de software (empresas com at 49 funcionrios) e por
este motivo caracterizou-se este tipo de empresa no contexto de desenvolvimento de software.
Percebeu-se que poucas adotam normas ou modelos de melhoria da qualidade, realizam pouco a
atividade de estimar e apresentam como um dos maiores problemas estimativas inadequadas.
O guia PMBOK, adotado como base para a criao do guia de estimativa, possibilitou o
desenvolvimento de um processo genrico para estimativa de software, considerando tanto a
estrutura do PMBOK quanto seus desgnios sobre a atividade de estimar. Buscou-se tambm a
definio dos parmetros de estimativas de recursos de atividades (esforo) e durao de atividades,
para o detalhamento no guia de estimativas desenvolvido.
No desenvolvimento do guia considerou-se os quesitos desejveis pelos modelos de
melhoria, e ao mesmo tempo o que estes no especificam como a definio da forma genrica do
processo de estimar e o detalhamento desta atividade e de modelos/tcnicas para realizar
estimativas.
Os principais modelos/tcnicas de estimativas foram selecionados e apresentados no guia
detalhadamente incluindo o conceito, quais parmetros estima (tamanho, esforo, durao), quando
devem ser utilizados e a descrio passo a passo de sua aplicao, alm de templates e os exemplos.
Para a consecuo deste trabalho foi necessrio tambm a anlise de 6 ferramentas, sendo 3
de gerncia de projetos, 2 especficas de estimativa e 1 genrica, em que se pode observar a falta
das funcionalidades para todos os requisitos desejveis desde aspectos de gerncia de projetos, aos
modelos e tcnicas de estimativas, sendo necessria utilizao destas ferramentas em conjunto.
Outro aspecto desejado a este trabalho o estabelecimento de diretrizes para nortear a
seleo do modelo/tcnica mais prximo da realidade da MPE que utilizar o guia. Acredita-se que
este foi iniciado com o item Utilizao no captulo 5 do guia (explicao de modelos/tcnicas) em
que so apresentadas algumas caractersticas necessrias empresa que deseja aplic-los.
Entretanto, torna-se necessrio aplicar o guia em uma empresa para efetivar estas consideraes e
instituir novas diretrizes para a seleo dos modelos e tcnicas disponveis.
O guia est em desenvolvimento contnuo e inicialmente contempla sua estrutura em
captulos constando a teoria relacionada a gerenciamento de projeto, ao processo de estimativa e
modelos e tcnicas de estimativas de software. Desenvolveu-se uma forma genrica de estimar
apresentando entradas, atividades e sadas para o processo de estimar. Alm disso, o guia ainda
contempla o passo a passo para executar os modelos/tcnicas; templates e exemplos de aplicao
para cada modelo/tcnica; ferramentas voltadas ao gerenciamento de projetos e estimativas de
software; e por fim o guia apresentar uma anlise de conformidade com os modelos de melhoria de
processo de software.
A avaliao do guia foi realizada com seis profissionais que possuem ao menos curso e/ou
prova do nvel introdutrio em MPS.BR e com especialidades em engenharia de software (apenas 1
no respondeu ao questionrio). Pretendeu-se com a pesquisa o atendimento dos requisitos
elencados como bsicos ao guia, cita-se aplicao do guia em MPEs, detalhamento dos
modelos/tcnicas selecionados, alinhamento com os modelos de melhoria de processo de software
(CMMI-DEV, MPS.BR, ISO/15504-5) e embasamento ao PMBOK. Os dados obtidos por meio da
avaliao num primeiro momento do indcios de que o objetivo do guia que seria sua utilizao
como apoio a implantao de um processo de estimativa em uma MPE de software, considerando
facilidade e eficincia, alm de servir como contedo orientador na implementao de modelos de
melhoria de processo de desenvolvimento de software.
Com relao aos requisitos elencados como desejveis para o guia pode-se dizer que todos
foram obtidos parcialmente. Os modelos e tcnicas sugeridos so descritos e sua aplicao
detalhada, sendo possvel a aplicao destes MPEs de software, contudo no houve aplicao deste
para que se possa confirmar a possibilidade. Na descrio de cada modelo/tcnica no guia so
apresentados critrios que definem que tipo de organizao poderia adotar tal tcnica, porm so
sugestes iniciais que devem ser desenvolvidas para que sejam mais especficas. O guia est
alinhado aos modelos de melhoria de processo de software (CMMI-DEV, MPS.BR, ISO/IEC
15504) no que se refere a estimativas (quadro 21). O desenvolvimento do guia se embasou no
PMBOK no contexto de estimativa (quadro 20). Os templates, exemplos e ferramentas referentes ao
155
processo de estimativas so apresentados no guia mas sua eficincia podero ser comprovadas por
meio de sua avaliao. Por fim o guia est escrito em Portugus e est livre para utilizao.
7.1 RECOMENDAES E TRABALHOS FUTUROS

Por no ter sido possvel aplicar o guia em MPE de software, recomenda-se que sejam
realizadas novas avaliaes deste por meio da aplicao do guia em MPEs, para que alm da
realizao de melhorias contnuas, seja possvel realizar comparativos entre o uso ou no do guia.
Considerando que o guia est em sua primeira verso, acredita-se que por meio da avaliao
seja possvel realizar um refinamento do guia e permitir que este esteja em processo de constante
melhoria. Como sugesto, a evoluo do guia pode ser mantida por meio da aplicao do processo
de evoluo de guias proposto por SOUZA(2008). Desta forma, pode-se tornar o guia cada vez
mais propcio para implantao de um processo de estimativa, estar alinhado aos modelos de
melhoria de processo de software favorecendo a implantao destes e ainda ter seus captulos mais
direcionados e adaptados s necessidades das MPEs, cita-se especialmente detalhamento dos
modelos/tcnicas, exemplos e templates.
Como recomendao tem-se a transformao deste guia em material eletrnico para facilitar
seu acesso e utilizao. Uma opo seria a utilizao de uma Wiki.
Outra recomendao seria a transformao deste guia em um livro considerando a
dificuldade existente em encontrar no meio acadmico material compilado sobre estimativa de
software. Acredita-se que um livro seria de grande valia aos acadmicos da rea por seu contedo
que apresenta diferentes tcnicas de estimativa e como aplic-las reunidas em um mesmo material.
156
REFERNCIAS BIBLIOGRFICAS
ALBRECHT, Allan J. Function Points as a Measure of Productivity. Actas do 53rd meeting of
GUIDE International Corp. Dallas, 1981.
ALBRECHT, Allan J; GAFFNEY JR, John E. Software Function, source line of code, and
development effort prediction: a software science validation. IEEE Transactions on Software
Engineering. SE-9, 6, 639-648; 1983.
BASILI, Victor R.; CALDIERA G., ROMBACH H, D. Goal Question Metric Paradigm.
Encyclopedia of Software Engineering. vol.2. John Wiley, 1994.
BENTE ANDA, et al. Estimating Software Development Effort based on Use Cases: Experiences
from Industry. Fourth International Conference on the UML, 2001 Springer. 2001.
BFPUG Brazilian Function Point Users Group. Perguntas e Dvidas Freqentes. Disponvel
em < http://www.bfpug.com.br/>. Acessado em 01/07/2008.
BOEHM, Barry. Software Engineering Economics. Prentice-Hall, 1981.
BOEHM, Barry; MADACHY, Ray; SELBY, Richard. The COCOMO 2.0 software cost estimation
model. 1995. Disponvel em: http://sunset.usc.edu/research/COCOMOII/. Acessado em:
24/11/2007.
BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. The Unified Modeling Language for
Object-Oriented Development. Documentation Set Version 0.91Addendum UML Update. Rational
Software Corporation. 1996.
CENTER for Software Engineering, USC. Cocomo II Model Definition Manual. 2004.
Disponvel em: http://sunset.usc.edu/research/COCOMOII. Acessado em: 01/10/2008.
CHARETTE , Robert N. Why Software Fails. 2005. Disponvel em:
http://www.spectrum.ieee.org/sep05/1685/2. Acessado em 19/10/2007.
COHN, Mike. Agile Estimating and Planning. 2006.
COHN, Mike. Planning Poker in Detail. 2005. Disponvel em:
http://www.planningpoker.com/detail.html. acessado em 10/07/2008.
COSMIC (Common Software Measurement International Consortium). The COSMIC Functional
Size Measurement Method Version 3.0: - Method Overview. 2007. Disponvel em:
http://www.cosmicon.com/. Acessado em 10/02/2009.
DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliao, estimativa. Rio
de Janeiro: Campus, 1991.
DAMODARAM, Mel. Estimation using use case points. Computer Science Program, Universt of
Houston-Victory. 2003.
DRUCKER, Peter F. As novas realidades. So Paulo: Pioneira, 1989.
FENTON, Norma E.; PFLEEGER, Shari L. Software Metrics: a rigorous and practical approach.
Boston: PWS Publishing Company, 1997.
GIL, Antnio Carlos. Mtodos e tcnicas de pesquisa social. 4 ed. 207 p ISBN 85 224 1041 0,
(broch.),1994.
GRENNING, James W. Planning Poker or How to avoid analysis paralysis while release
planning. 2002. Disponvel em: https://segueuserfiles.middlebury.edu/xp/PlanningPoker-v1.pdf.
Acessado em 10/07/2008.
HALL, Earl , JOHNSON, Juliane. Integrated Project Management. Prentice Hall, 2002.
HARMAN, Mark. Project Estimation: How long is this going to take? EXE Magazine. 1998.
Disponvel em: http://www.dcs.kcl.ac.uk/staff/mark/exe11.html. Acessado em 26/10/2007.
HUGHES, Bob; COTTERELL, Mike. Software Project Management. 2 ed. New York: McGrawHill, 1999.
HUGHES, Bob; COTTERELL, Mike. Software Project Management. 4 ed. New York: McGrawHill, 2006.
IBGE Instituto Brasileiro de Geografia e Estatstica. As micro e pequenas empresas comerciais
e de servios no Brasil. Rio de Janeiro : IBGE, 2003.
IFPUG - International Function Point Users Group. Function Point Counting Practices Manual.
Release 4.1.1 Westerville: IFPUG, 2000.
IEEE/IEA. ISO/IEC 12207 standard for Information Technology: software life cycle processes.
1998.
ISO/IEC Std. 15504: Information Technology Process Assessment, Part 1 to Part 5. 2005.
International Organization for Standardization, 2003-2006.
JALOTE, Pankaj. Software project management in practice. Boston: Pearson Education, 2002.
JOHNSON, D.L.; BRODMAN, J.G. Tailoring the CMM for Small Businesses, Small
Organizations, and Small Projects. IEEE CS Press. 1997. Disponvel em
http://www2.umassd.edu/swpi/McGill/spn_no8.pdf. Acessado em 19/10/2007.
KANER, Gustav. Resource estimation for objectory projects. Objective systems SF AB. 1993.
KASSE, T. Practical Insight into the CMMI. Ed. Artech House. Massachussets, 2004.
KULPA, Margaret K.; JOHNSON, Kent A. Interpreting the CMMI: A Process Improvement
Approach. Auerbach Publications, 2003.
LAIRD, Linda M., BRENNAM, M. Carol. Software Measurement and Estimation - A. Practical
Approach. New York: John Wiley & Sons, 2006.
LQPS. Caso exemplo VENDESOFT. Working Paper, Laboratrio de Qualidade e Produtividade
de Software, UNIVALI, So Jose, 2008.
MARCONI, Maria de Andrade; LAKATOS, Eva Maria. Tcnicas de pesquisa: planejamento e
execuo de pesquisas, amostragens e tcnicas de pesquisas, elaborao, anlise e interpretao de
dados. So Paulo: Atlas, 1999.
MCCONNELL, Steve. Software estimation: demystifying the black art. Washington: Microsoft
Press, 2006.
MCT - Ministrio da Cincia e Tecnologia. Secretaria de Poltica de Informtica. Qualificao
CMM e CMMI no Brasil. 2006
MCT Ministrio de Cincia e Tecnologia (Brasil). Pesquisa sobre Qualidade e Produtividade
no Setor de Software. 2005. Disponvel em: http://www.mct.gov.br.
158
MCT Ministrio de Cincia e Tecnologia. Pesquisa nacional de qualidade e produtividade no

setor de software brasileiro. Braslia: 2002.
MEDEIROS, Manoel Pimentel . Extreme Programming Conceitos e Prticas. DevMEdia:2008.
Disponvel em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=1498. Acessado em
10/07/2008.
MINAYO, MCS et al. Pesquisa social: teoria, mtodo e criatividade. (2 ed.). Petrpolis: Vozes,
1994,
MIT - Massachussets Institute of Technology. A indstria de software no Brasil 2002:
fortalecendo a economia do conhecimento Brasil. Coordenao geral Sociedade SOFTEX. Campinas: SOFTEX. 2002.
NESMA (Netherlands Software Metrics Association). FPA according to NESMA and IFPUG.
2008. Disponvel em: http://www.nesma.org. Acessado em 10/02/2009.
O.CONNELL, Fergus. How to run successful projects in Web time. Artech House computing
library, 2000.
. 1 0 0 2 , g ni n r a e L n o s m o h T a ri e n oi P : ol u a P o S . s e s et
9
e seatressid ,saifargonom ,CCT ,IGT ,sasiuqsep ed sotejorp :9 .ed ziuL oivliS ,ARIEVILO
9
9
PARTHASARATHY, M. A. Practical Software Estimation: Function Point Methods for
Insourced and Outsourced Projects. Inforsys Press. 2007
PMI - PROJECT MANAGEMENT INSTITUTE. Chapters Brasileiros .estudo de benchmarking em

gerenciamentos de projetos. 2007 (a).
PMI - PROJECT MANAGEMENT INSTITUTE. PMBOK Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos. 3.ed. 2004.
PMI - PROJECT MANAGEMENT INSTITUTE. Who We Are: About PMI. 2007(b). Disponvel em:
http://www.pmi.org/WhoWeAre/Pages/About-PMI.aspx. Acessado em 19/10/2007.
PRESSMAN. Roger S. Engenharia de software. So Paulo: Makron Books, 2006.
QSM Function Point Programming Languages Table. Quantitative Software Management. 2005.
Disponvel em: < http://www.qsm.com/FPGearing.html>. acessado em 10/10/2008.
RIBU, Kirsten. Estimating Object-Oriented Software Projects with Use Cases. Master of
Science Thesis. University of Oslo. 2001.
RICHARDSON, Ita; WANGENHEIM, Chrisiane Gresse von. Why are small software
Organizations Different?. IEEE Computer Society. 2007. Disponvel em:
www.computer.org/software. acessado em: 13/08/2007.
SCHWABER , Ken. Agile Project Management with Scrum. Washington: Microsoft Press, 2004.
SEBRAE. O compromisso do SEBRAE com a competitiviidade das MPEs. 2005. Disponivel
em: www.portal.sebrae.com.br. Acessado em: 21/05/2008.
SEBRAE. Onde esto as micro e pequenas empresas no Brasil. 2006. Disponivel em:
www.portal.sebrae.com.br. Acessado em: 21/05/2008.
159
SEBRAE. Servio Brasileiro de Apoio s Micro e Pequenas Empresas. Fatores Condicionantes e

Taxa de Mortalidade de Empresas no Brasil. Relatrio de pesquisa. Braslia: AGOSTO/2004.
Acessado em 18/10/2007.
SEI. Software Engineering Institute. CMMI for Systems Engineering/Software Engineering,
Version 1.2 (CMMI-SE/SW, V1.1) Continuous Representation. Dezembro, 2002. Disponvel em
http://www.sei.cmu.edu/cmmi Acessado em 27/04/2007.
SEI. Software Engineering Institute. CMMI for Development, Version 1.2 (CMMI-Dev V1.2).
Agosto, 2006. Disponvel em http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf
acessado em 01/07/2007.
SMITH, John. The Estimation of Effort Based on Use Cases. Rational Software white paper.
1999.
SOFTEX. Sociedade para Promoo da Excelncia do Software Brasileiro. Softex prev
exportaes de US$ 314 milhes em 2005. Artigo. 2005. Disponvel em:
<http://www.serpro.gov.br/noticias-antigas/noticias-2005-1/20051028_09>. Acessado em:
21/10/2007.
SOFTEX. Sociedade para Promoo da Excelncia do Software Brasileiro. Melhoria de processo
de Software Brasileiro verso 1.2. 2007. Disponvel em
http://www.softex.br/portal/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf. Acessado em
27/04/2007.
SOMMERVILLE, Ian. Engenharia de software. 6.ed. So Paulo: Addison-Wesley, 2004.
SOUZA, Richard Henrique de. Processo de evoluo colaborativo de guias de referncia de
software. 2008. 100 f. Dissertao (mestrado em Cincia da Computao). Programa de PsGraduao em Cincia da Computao. Universidade Federal de Santa Catarina, Florianpolis,
2008.
STANDISH GROUP. The CHAOS Report. 1994. Disponvel em:
http://www.standishgroup.com/sample_research/chaos_1994_1.php. Acessado em: 19/10/2007.
STANDISH GROUP. The CHAOS Report. 2004. Disponvel em:
http://www.standishgroup.com/sample_research/chaos_2004_1.php. Acessado em: 18/01/2008.
THOMSETT, Rob. Radical Project Management. Prentice Hall PTR. 2002.
UEHARA, Irineu. Software: qualidade total. 2003. Disponvel em: <
http://www.biblioteca.sebrae.com.br/bds/BDS.nsf/22657BE9023F807503256D520059A9D0/$File/
411_1_Arquivos_softwareEM4.pdf>. Acessado em jan/2007.
UKSMA (United Kingdom Software Metrics Association). MK II Function Point Analysis
Counting Practices Manual. Version 1.3.1. 1998.
WAKE, William C. Extreme Programming Explored. Boston: Addison-Wesley, 2002.
WEBER, Sergio; HAUCK, Jean Carlo Rossa; VON WANGENHEIM, Christiane Gresse.
Estabelecendo Processos de Software em Micro e Pequenas Empresas. In: SBQS - Simpsio
Brasileiro de Qualidade de Software, Porto Alegre, Brazil, 2005.
WYSOCKI, Robert K; MCGARY, Rudd. Effective Project Management. 3 ed. John Wiley &
Sons. 2003.
160
APNDICES
Apndice A Questionrio avaliao
LQPS - Laboratrio de Qualidade e Produtividade de Software

Universidade do Vale do Itaja - UNIVALI
Ttulo: Questionrio de avaliao do guia de estimativas de software
Avaliador:
Data:
Objetivo:
Avaliar o guia de estimativa de software em relao ao atendimento de requisitos estabelecidos
sob o ponto de vista de engenheiros de processo experientes no contexto de programas de
melhoria de processos de software em MPEs (Micro e pequenas empresas).
Esta pesquisa est sendo feito como parte da dissertao de mestrado Um guia para estimativas
de projetos de software em micro e pequenas empresas, do MCA (Mestrado em Computao
Aplicada) da UNIVALI.
Instrues:
O questionrio contempla questes com respostas fechadas, porm oportunizando a realizao de
comentrio em casos em que no h atendimento por completo de determinado questionamento.
Ressalta-se que tais consideraes so de grande valia para a melhoria continua do guia.
Perfil de avaliador:
As questes que sero apresentadas a seguir esto fora do escopo de avaliao do guia, porm
por estarem provendo uma identificao do perfil dos avaliadores estar auxiliando na
apresentao da avaliao e como contextualizao desta.
Qual sua formao acadmica?

Cincia da Computao
Qual? ________________________________
Sim Qual? ________________________________
Voc tem experincia na implantao/consultoria de modelos de melhoria de processo de Software?

No
Sim
Voc tem alguma certificao em modelos de melhoria de processo de software?

No
Outra: ____________________
Voc tem especializao em Engenharia de Software ou afim?

No
Sistemas de Informao
Sim Quanto tempo? ________________________
Voc tem experincia estimativa de Software?

No
Sim
Quanto tempo? ________________________ Qual modelo/tcnica aplica:______________________
Pergunta 01: Qual sua impresso subjetiva sobre o percentual de esforo necessrio para que o guia, em
sua forma atual, seja aplicado em uma MPE de software?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Explique sua opinio:
Pergunta 02: Voc acredita que no contexto de uma MPE, como Engenheiro de processo, se necessitar
aplicar o guia utilizando-o como fonte para implantar um processo de estimar junto a colaboradores leigos,
estes compreenderiam o referido processo especificamente na fase de planejamento?
Totalmente
Parcialmente
No
Justifique sua resposta. Indique contedos incompletos ou inexistentes no guia:
Pergunta 03: Voc como Engenheiro de processo, acredita que o contedo referente aos modelos/tcnicas
de estimativas de software suficiente para a compreenso de um leigo?
Totalmente
Parcialmente
No
Pergunta 04: Voc considera que todos modelos/tcnicas de estimativas apresentados no guia so
adequados a MPEs de software?
Totalmente
Parcialmente
No
Indique o que voc considera inadequado:
Sugira novos modelos/tcnicas:
Pergunta 05: Em sua opinio, os exemplos de aplicao dos modelos/tcnicas apresentados no guia ajudam
na compreenso e utilizao destes modelos/tcnicas?
Totalmente
Parcialmente
No
163
Pergunta 06: Em sua opinio, os templates sugeridos no guia esto coerentes com os modelos/tcnicas
apresentados?
Totalmente
Parcialmente
No
Pergunta 07: Voc percebe que as ferramentas indicadas no guia podem indicar uma forma de suporte o
do processo de estimar?
Totalmente
Parcialmente
No
Sugira outras ferramentas:

Pergunta 08: Considerando o uso do guia em detrimento a sua no utilizao, voc acredita ser mais rpido
estabelecer um processo de estimar com qualidade em uma MPE?
Totalmente
Parcialmente
No
Em qual percentual:
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 09: Quantas fontes alm do guia voc acredita serem necessrias para estabelecimento de um
processo de estimar, considerando o alinhamento os modelos de melhoria de processo (CMMI-DEV,
MPS.BR, ISO/IEC 15504)? ________
Liste outras fontes:
Pergunta 10: Considerando o processo de estimar e suas atividades qual o percentual do guia que se baseia
no PMBOK.
nenhum
1% - 25%
26% - 50%
51% - 75%
164
76% - 100%
Pergunta 11: Em sua opinio qual o percentual de alinhamento ao CMMI-DEV, considerando o processo de
estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Explique sua opinio (indique o que no est alinhado):
Pergunta 12: Em sua opinio qual o percentual de alinhamento ao MPS.BR, considerando o processo de
estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 13: Em sua opinio qual o percentual de alinhamento ao ISO /IEC 15504, considerando o processo
de estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
165
76% - 100%

Mestrado - Um Guia para Estimativa de Projetos de Spftware em Micro e Pequenas Empresas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mestrado - Um Guia para Estimativa de Projetos de Spftware em Micro e Pequenas Empresas

Enviado por

Direitos autorais:

Formatos disponíveis

MARLISE THERE DIAS

UM GUIA PARA ESTIMATIVAS DE PROJETOS DE SOFTWARE

So Jos (SC), maro de 2009.

UNIVERSIDADE DO VALE DO ITAJA

UM GUIA PARA ESTIMATIVAS DE PROJETOS DE SOFTWARE

Dissertao apresentada como requisito parcial

So Jos (SC), maro de 2009.

UM GUIA PARA ESTIMATIVAS DE PROJETOS DE SOFTWARE

Orientador(a): Christiane Gresse von Wangenheim, Dr. rer. nat

A atividade de estimativa possui diferentes modelos/tcnicas para execut-la e tarefa exigida na

A GUIDE TO SOFTWARE PROJECT ESTIMATES IN MICRO

Adviser: Christiane Gresse von Wangenheim, Dr. rer. nat

Keywords: Management projects. Planning. Estimative.

Figura 1 - Metodologia de criao e aplicao do guia ..................................................................... 24

Quadro 1- Relao de atividades dos passos referentes ao planejamento de projetos ....................... 30

Tabela 1- Exemplo de dados de projetos ........................................................................................... 38

Equao 1 - Forma modelos paramtricos ......................................................................................... 37

LISTA DE ABREVIATURAS E SIGLAS

Brazilian Function Point Users Group

1.1 MOTIVAO .......................................................................................................................... 18

FUNDAMENTAO TERICA .......................................................................................... 26

2.1 GERNCIA DE PROJETOS ................................................................................................. 26

CONTEXTUALIZAO DO TRABALHO: MICRO E PEQUENAS EMPRESAS ....... 92

3.1 MPES DE SOFTWARE BRASILEIRAS .............................................................................. 92

ESTADO DA ARTE E DA PRTICA ................................................................................... 99

4.1 DISCUSSO DOS GUIAS PESQUISADOS....................................................................... 109

DESENVOLVIMENTO DO GUIA ...................................................................................... 111

5.1 DESCRIO .......................................................................................................................... 111

5.2 PROCESSO GENRICO ..................................................................................................... 115

AVALIAO DO GUIA....................................................................................................... 135

6.1 PLANEJAMENTO DA AVALIAO ................................................................................ 135

CONCLUSES ...................................................................................................................... 154

7.1 RECOMENDAES E TRABALHOS FUTUROS .......................................................... 156

ferramenta para tomada de deciso. O planejamento do projeto fornece informaes para o

1.2.2 Objetivos Especficos

OE1. Identificar as caractersticas das MPEs e de seus processos de software, em

OE2. Analisar os requisitos referentes ao processo de estimar da rea de processo de

caractersticas de MPEs identificadas.

OE4. Analisar ferramentas existentes na rea de estimativas relacionadas s

OE5. Estabelecer diretrizes para a seleo dos modelos/tcnicas e ferramentas do guia.

OE6. Desenvolver o guia com base em modelos/tcnicas e ferramentas existentes na rea

OE7. Avaliar o guia por meio de experincias prticas de profissionais certificados em

1.3.1 Metodologia da Pesquisa

1.3.2 Metodologia da Aplicao

Figura 1 - Metodologia de criao e aplicao do guia

Como proposto na ilustrao supracitada, a construo do guia de estimativas est

1.4 ORGANIZAO DO DOCUMENTO

2.1 GERNCIA DE PROJETOS

O gerenciamento de projetos realizado atravs de processos, usando conhecimento,

Planejamento: constitui-se de atividades de planejamento, definindo e refinando os

Monitoramento e controle: processos de observao da execuo do projeto so

Encerramento: nesta fase so encontrados processo que finalizam de maneira formal as

Melhora a eficincia, uma vez que favorece a alocao de recursos, agendamento de

A realizao do planejamento envolve as atividades de definio de escopo e objetivos do

Figura 2 - Atividades do planejamento de projetos

Quadro 1- Relao de atividades dos passos referentes ao planejamento de projetos

No passo 1 de identificao do escopo e objetivos apresentado o que ser realizado em

2.2.1 Estimativas de software

a complexidade do projeto, que depender da familiaridade que se tem com

o tamanho do projeto de software, que aumenta a medida que a interdependncia entre

o grau de estrutura do projeto, ou seja, a facilidade de dispor funcionalidades em

no ter a disposio um histrico e no considerar desempenhos passados. Por no

a no especializao em estimar. O processo de estimar complexo e exige um