Sie sind auf Seite 1von 214

UNIVERSIDADE ESTADUAL DO CEAR

CENTRO DE CINCIA E TECNOLOGIA


MESTRADO ACADMICO EM CINCIA DA COMPUTAO

TARCIANE DE CASTRO ANDRADE

ProMePE:: PROCESSO DE MEDIO SIMPLIFICADO BASEADO EM


PADRES PARA MICRO E PEQUENAS EMPRESAS

FORTALEZA - CEAR
2010
TARCIANE DE CASTRO ANDRADE

ProMePE: PROCESSO DE MEDIO DE SOFTWARE BASEADO EM


PADRES PARA MICRO E PEQUENAS EMPRESAS

Dissertao submetida Comisso


Examinadora do Programa de Ps-
Graduao Acadmica em Cincia da
Computao da Universidade Estadual
do Cear, como requisito para obteno
do titulo de Mestre em Cincia da
Computao.

Orientador: Prof. Jerffeson Teixeira de


Souza, Ph.D.

FORTALEZA - CEAR
2010
A533p Andrade, Tarciane de Castro
ProMePE Processo de Medio Simplificado
baseado em Padres para Micro e Pequenas Empresas /
Tarciane de Castro Andrade. - Fortaleza, 2010.
217p. ; il.
Orientador: Prof. Dr. Jerffeson Teixeira de Souza.
Dissertao (Mestrado Acadmico em Cincia da
Computao) Universidade Estadual do Cear;
Centro de Cincias e Tecnologia.
1. Processo de Medio 2. Estimativa 3. Micro e
Pequena Empresa. I. Universidade Estadual do Cear,
Centro de Cincias e Tecnologia.
TARCIANE DE CASTRO ANDRADE CDD: 001.6
PRoMePE: PROCESSO DE MEDIO SIMPLIFICADO BASEADO EM
PADRES PARA MICRO E PEQUENAS EMPRESAS

Dissertao submetida Comisso


Examinadora do Programa de Ps-
Graduao Acadmica em Cincia da
Computao da Universidade Estadual do
Cear, como requisito para obteno do
titulo de Mestre em Cincia da
Computao.

Aprovada em 11/03/2010.

BANCA EXAMINADORA

________________________________________________
Prof. Dr. Jerffeson Teixeira de Souza (Orientador)
Universidade Estadual do Cear UECE

________________________________________________
Profa. Dr. Mariela Ins Corts
Universidade Estadual do Cear UECE

________________________________________________
Prof. Dr. Srgio Castelo Branco Soares
Universidade Federal de Pernambuco UFPE
Aos meus pais Jesus e Andrade, aos meus irmos
Rossana e Cssio e ao meu marido Rodrigo
AGRADECIMENTOS

Antes de tudo agradeo a Deus por me prover sade, pacincia, fora e todas as
condies para que eu chegasse at aqui, em especial, por me permitir a finalizao
deste trabalho.

Gostaria de agradecer tambm a meu marido, por estar sempre ao meu lado,
principalmente nos momentos de maior dificuldade, sempre me motivando e me
ajudando, pela pacincia nos momentos estressantes pelos quais passamos.

Agradeo minha famlia pela compreenso e apoio, em especial aos meus pais,
por tudo que fizeram por mim para que eu pudesse ser quem eu sou. Agradeo tambm
a meus irmos, Rossana e Cssio, pela ajuda, motivao e inspirao que sempre me
proporcionaram. No poderia deixar de agradecer aos meus queridos sobrinhos Sofia e
Joo que me deram inmeros momentos de alegria.

Agradeo ao meu orientador Prof. Jerffeson pela ateno, dedicao e,


principalmente, por acreditar no meu trabalho. Valeu Prof!

Agradeo a todos os colegas e funcionrios do MACC que direta ou


indiretamente me ajudaram neste trabalho, mesmo que somente por me fazer sentir
confortvel neste ambiente acadmico, em especial ao Fabrcio que me ajudou nas
revises e elaboraes de artigos.

Agradeo ao Banco do Nordeste do Brasil, em especial ao Paulo Juc e Jesuno


pelo apoio ao me conceder a licena para dedicao exclusiva concluso deste
trabalho. Tambm gostaria de agraceder Ana Cristina, Anchieta, Bia, Igor, Leonardo,
Lvia, Kennia, Marum, Rafael, Sales, Shamya, Silma e Valria pela fora e por me
proporcionarem momentos de descontrao.
Agradeo a compreenso dos meus demais amigos quando neguei me juntar s
divertidas reunies, happy hours, viagens, etc, para no perder a concentrao nem o
foco neste trabalho.
Toda a sabedoria vem de Deus.

Eclesistico, 1:1
RESUMO

Para produzir software de forma competitiva preciso focar na qualidade. Para isto,
dados quantitativos que descrevam a realidade dos produtos e do processo precisam ser
obtidos e devidamente analisados atravs de um processo de medio. A realizao das
estimativas de software est inserida como um primeiro passo no processo de medio.
Com a estimativa pode-se confrontar o planejado com o realizado e formar base
histrica para os prximos projetos. A maioria das Micro e Pequenas Empresas de
Software (MPES) no trabalham com estimativas ou processo de medio devido
principalmente limitao de recursos e imaturidade nos processos. Nesse contexto o
presente trabalho prope um processo de medio simplificado para MPES, baseado em
padres, para auxiliar no controle de seus processos e produtos e, assim, produzir
software de forma controlada, com maior qualidade e tornando-as mais competitivas.

Palavras-chave: Estimativa. Medio. Padro de Processo. Processo de Medio.


Processo de Estimativa. Micro e Pequenas Empresas de Software.
ABSTRACT

In order to produce competitive software, one must focus on quality. To do this,


quantitative data that describe the reality of the product and the process must be duly
obtained and analyzed through a measurement process. The software estimation
process is inserted as a first step in the measurement process. With the estimate it is
possible compare the planned with the performed and to build a historical basis for
future projects. Most of the Micro and Small Software Organizations (MPES) do not
apply an estimattion or measurement process due mainly to limited resources and
immaturity on their development processes. In this context, this work proposes a
simplified measurement process for MPES, based on patterns, to assist in the control of
their processes and products and thus producing software in a controlled manner, with
higher quality and making them more competitive.

Key-words: Estimation. Measurement. Software Patterns. Measurement Process.


Estimation Process. Small Organizations.
LISTA DE ILUSTRAES

Figura 2.1 Contagem de Transao da Tcnica APF (IFPUG, 1999) ...... 28

Figura 2.2 Detalhe da etapa de Contagem de Funes do Tipo Dado da


APF .............................................................................................................. 29

Figura 2.3 Processo de Contagem da Tcnica PCU (KARNER, 1993) ... 32

Figura 2.4 PSM como referncia a demais modelos e padres (DOD,


2003) ............................................................................................................ 37

Figura 2.5 Detalhamento dos nveis de medidas do PSM (DOD, 2003) .. 39

Figura 2.6 - Modelo de Processo de Medio do PSM (DOD, 2003) ......... 40

Figura 4.1 Diagrama de Atividades do MPG (CARDOSO et al., 2005) .. 58

Figura 4.2 MIS-PyME Framework (LEY; GARCIA; PIATTINI, 2008) . 59

Figura 4.3 Nveis de Capacidade do Modelo de Maturidade de Medio,


MIS-PyME (LEY; GARCIA; PIATTINI, 2008) ......................................... 60

Figura 6.1 - Linguagem de Padres para Estimativa de Software ............... 70

Figura 6.2 Casos de Uso do Sistema de Matrcula de Estudantes ............ 72

Figura 7.1 Metamodelo do Processo ProMePE ...................................... 109

Figura 7.2 Diagrama de Atividade do Processo, ProMePE .................... 110

Figura 7.3 - Estrutura da Atividade Planejar Medio, ProMePE ............. 112

Figura 7.4 Detalhe da Atividade Aplicar Estimativa, ProMePE ............ 115

Figura 7.5 Detalhe da Atividade Aplicar e Analisar Medidas, ProMePE


................................................................................................................... 123

Figura 7.6 Detalhe da Atividade Avaliar Processo Medio, ProMePE 126

Figura 7.7 Viso Geral do ProMePE ...................................................... 132

Figura 8.1 Resultado da Entrevista com os Gerentes de Projeto ............ 136

Figura 8.2 Progresso do Cronograma do Projeto em Outubro, seo


Progresso do Cronograma da Planilha de Coleta e Anlise dos Dados . 151
Figura 8.3 Progresso do Cronograma do Projeto no Perodo, seo
Progresso do Cronograma da Planilha de Coleta e Anlise dos Dados . 151

Figura 8.4 Esforo do projeto no perodo: realizado x planejado, seo


Esforo da Planilha de Coleta e Anlise dos Dados .............................. 152

Figura 8.5 Varincia de Esforo entre o realizado e o previsto no contrato,


seo Esforo, Planilha de Coleta e Anlise dos Dados ........................ 152

Figura 8.6 Esforo Previsto no Contrato x Realizado, seo Esforo,


Planilha de Coleta e Anlise dos Dados .................................................... 153

Figura 8.7 Custo do Projeto por Contrato, seo custo da Planilha de


Coleta e Anlise dos Dados ....................................................................... 154

Figura 8.8 Comparao Custo Total do Projeto, seo custo da Planilha


de Coleta e Anlise dos Dados .................................................................. 154

Figura 8.9 Esforo estimado acumulado para mudana de requisitos, seo


estabilidade de requisitos, Planilha de Coleta e Anlise de Dados ........ 155

Figura 8.10 Taxa de Defeito por Tamanho de UC, seo defeitos da


Planilha de Coleta e Anlise de Dados ...................................................... 156
LISTA DE TABELAS

Tabela 1.1 Porcentagem de mtricas primitivas utilizadas para medir a


produtividade dos processos de software (MCT, 2005) .............................. 21

Tabela 1.2 Porcentagem de empresas que utilizam prticas de engenharia


de software (MCT, 2005) ............................................................................ 21

Tabela 2.1 Complexidade Funcional (IFPUG, 1999) ............................... 29

Tabela 2.2 Complexidade de Entrada Externa da APF (IFPUG, 1999) ... 30

Tabela 2.3 Complexidade de Sada e Consulta Externa da APF (IFPUG,


1999) ............................................................................................................ 30

Tabela 2.4 Caractersticas Gerais da APF (IFPUG, 1999) ....................... 31

Tabela 2.5 Classificao dos Atores do PCU (KARNER, 1993) ............. 32

Tabela 2.6 Classificao dos Casos de Uso do PCU (KARNER, 1993) .. 33

Tabela 2.7 Fatores Tcnicos, Technical Factors, da PCU (KARNER,


1993). ........................................................................................................... 34

Tabela 2.8 Clculo dos Fatores Ambientais.do PCU (KARNER, 1993) . 35

Tabela 5.1 Anlise dos Trabalhos Relacionados frente aos Requisitos.... 67

Tabela 6.1 Resumo dos Padres ............................................................... 71

Tabela 6.2 Classificao das Transaes .................................................. 75

Tabela 6.3 Caractersticas No-Funcionais .............................................. 76

Tabela 6.4 Pesos para o Sistema de Matrcula ......................................... 78

Tabela 6.5 Valores atribudos aos Fatores No-Funcionais ..................... 79

Tabela 6.6 Caractersticas da Experincia da Equipe ............................... 83

Tabela 7.1 Detalhe do Processo ProMePE ............................................. 111

Tabela 7.2 Mapeamento entre necessidade de informao e medidas base


presente no Plano de Medio de Referncia, ProMePE .......................... 114

Tabela 7.3 Guia de Orientao para Classificao das Transaes,


ProMePE .................................................................................................... 117
Tabela 7.4 Caractersticas No Funcionais, ProMePE ........................ 118

Tabela 7.5 Percentual de esforo por papel, presente no plano de medio


de referncia, aba medidas derivadas, ProMePE, adaptado de (PADUA,
2009). ......................................................................................................... 122

Tabela 7.6 Anlise do ProMePE frente aos Requisitos .......................... 128

Tabela 7.7 Mapeamento PSM e ProMePE ............................................. 130

Tabela 8.1 Lista de Necessidades de Informao do Projeto e reutilizao


em relao ao Plano de Medio de Referncia ........................................ 139

Tabela 8.2 Apresentao parcial da seo Medidas Base do Plano de


Medio do Projeto .................................................................................... 140

Tabela 8.3 Apresentao parcial da seoMedidas Derivadas do Plano


de Medio do Projeto ............................................................................... 140

Tabela 8.4 Porcentagem de Esforo Realizado no Projeto por Papel..... 141

Tabela 8.5 Apresentao Parcial da Seo Procedimento Coleta de


Dados do Plano de Medio do Projeto ................................................... 141

Tabela 8.6 Apresentao parcial da seo Procedimento Anlise dos


Dados do Plano de Medio do Projeto ................................................... 142

Tabela 8.7 Apresentao Parcial da Classificao das Transaes por Caso


de Uso, presente na Planilha de Coleta e Anlise dos Dados .................... 143

Tabela 8.8 Apresentao Completa do Clculo da Funcionalidade,


presente na Planilha de Coleta e Anlise dos Dados ................................. 143

Tabela 8.9- Caractersticas No-Funcionais, planilha de Anlise e Coleta de


Dados ......................................................................................................... 144

Tabela 8.10 Apresentao Parcial de estimativa de esforo por caso de uso


e disciplina, planilha de Anlise e Coleta de Dados, seo Esforo ...... 145

Tabela 8.11 Apresentao Parcial do Esforo Previsto no Contrato 1,


planilha de Anlise e Coleta dos Dados, seo Esforo......................... 145

Tabela 8.12 Tarefas planejadas e executadas no period, seo Progresso


do Cronograma da Planilha de Coleta e Anlise dos Dados .................... 148
Tabela 8.13 Distribuio de Esforo no Projeto Realizado, seo
Esforo da Planilha de Coleta e Anlise dos Dados .............................. 148

Tabela 8.14 Esforo Realizado no Perodo do Contrato 1, seo Esforo


da Planilha de Coleta e Anlise dos Dados ............................................... 148

Tabela 8.15 Apresentao Parcial da Estimativa de Esforo para


Mudanas de Requisitos do Projeto, seo Estabilidade dos Requisitos da
Planilha de Coleta e Anlise de Dados ...................................................... 149

Tabela 8.16 Apresentao parcial da quantidade de defeitos encontrados


no projeto por caso de teste, seo defeitos da planilha de coleta e anlise
dos dados ................................................................................................... 150
LISTA DE ABREVIATURAS E SIGLAS

APF Anlise de Ponto de Funo


CUSTO Custo Total do Desenvolvimento do Projeto
EPRZ Estimativa de Prazo Total
ESF Estimativa do Esforo Total
ESF_REAL Esforo Real
ETT Estimativa do Tamanho Total
FF Fatores Funcionais
FTNF Fatores Tcnicos No Funcionais
IES Instituio de Ensino Superior
MCT Ministrio de Cincia e Tecnologia
MPES Micro e Pequenas Empresas de Software
P Porcentagem de Esforo Necessrio para cada papel
PCU Pontos de Caso de Uso
PROD Produtividade
PSM Practical Software and Systems Measurement
QtdRD Quantidade de Humanos Recursos Disponveis
SPI Software Process Improvement
TCD Transaes de consulta
TED Transaes de entrada de dados por parte do usurio
TEX Transaes externas, mantidas por outra aplicao
TPD Transaes de persistncia de dados
TSD Transaes de sada de dados
UFC Universidade Federal do Cear
VlrJTRAB Valor da Jornada de Trabalho
SUMRIO

1 INTRODUO................................................................................................................ 18

1.1 Motivao .................................................................................................................... 20


1.1.1 Benefcios e Dificuldades das Medies ............................................................... 22

1.2 Objetivo Geral ............................................................................................................. 23


1.3 Objetivos Especficos .................................................................................................. 24
1.4 Organizao dos Captulos .......................................................................................... 24
2 ESTIMATIVA E MEDIO .......................................................................................... 26

2.1 Introduo .................................................................................................................... 26


2.2 Estimativas ................................................................................................................... 27
2.3 Medio de Software ................................................................................................... 35
2.3.1 Practical Software Measurement (PSM) ............................................................... 37

2.4 Consideraes Finais ................................................................................................... 41


3 PADRES DE SOFTWARE ........................................................................................... 42

3.1 Introduo .................................................................................................................... 42


3.2 O que so padres? ...................................................................................................... 43
3.2.1 reas de Aplicao e Tipos de Padres ................................................................. 47

3.2.2 Coletneas de Padres ........................................................................................... 48

3.2.3 Formato dos Padres.............................................................................................. 49

3.3 Consideraes Finais ................................................................................................... 51


4 TRABALHOS RELACIONADOS .................................................................................. 52

4.1 Introduo .................................................................................................................... 52


4.2 Abordagens de Processos de Estimativa e Medio: Contexto Geral ......................... 52
4.3 Abordagens de Processos de Medio: Contexto MPES ............................................ 55
4.4 Consideraes Finais ................................................................................................... 60
5 REQUISITOS PARA DEFINIO E IMPLANTAO DE PROCESSO DE
MEDIO PARA MPES ....................................................................................................... 62

5.1 Introduo .................................................................................................................... 62


5.2 Requisitos para definio de processo de medio para MPES .................................. 63
5.3 Requisitos para implantao de processo para MPES ................................................. 65
5.4 Como os trabalhos relacionados atendem aos requisitos ............................................. 67
5.5 Consideraes Finais ................................................................................................... 68
6 LINGUAGEM DE PADRES PARA ESTIMATIVA DE SOFTWARE ...................... 69

6.1 Introduo .................................................................................................................... 69


6.2 Running Example ........................................................................................................ 72
6.3 Os Padres ................................................................................................................... 73
6.4 Consideraes Finais ................................................................................................. 107
7 ProMePE: PROCESSO DE MEDIO SIMPLIFICADO BASEADO EM
PADRES PARA MICRO E PEQUENAS EMPRESAS .................................................... 108

7.1 Introduo .................................................................................................................. 108


7.2 Descrio do ProMePE .............................................................................................. 109
7.2.1 Pr-Condies: Estabelecer Compromisso Organizacional e Planejar de
Recursos .......................................................................................................................... 111

7.2.2 Atividade Planejar Medio ................................................................................ 112

7.2.3 Atividade Aplicar Estimativa .............................................................................. 115

7.2.4 Atividade Aplicar e Analisar Medidas ................................................................ 123

7.3 Anlise do ProMePE frente aos Requisitos ............................................................... 128


7.4 Mapeamento PSM e ProMePE .................................................................................. 130
7.5 Consideraes Finais ................................................................................................. 131
8 ESTUDO DE CASO: APLICAO DO ProMePE EM UMA MICRO E
PEQUENA EMPRESA DE SOFTWARE ............................................................................ 133

8.1 Introduo .................................................................................................................. 133


8.2 Perfil da Empresa ....................................................................................................... 134
8.2.1 Caracterizao do Ambiente ................................................................................ 134
8.2.2 Processo de Desenvolvimento ............................................................................. 135

8.2.3 Entrevista com os Gerentes de Projetos .............................................................. 135

8.3 Aplicao do ProMePE.............................................................................................. 136


8.3.1 Pr-condies: Estabelecer Compromisso Organizacional e Planejar
Recursos .......................................................................................................................... 138

8.3.2 Tarefa Desenvolver Plano de Medio ................................................................ 138

8.3.3 Tarefa Estimar Tamanho ..................................................................................... 142

8.3.4 Tarefa Estimar Esforo ........................................................................................ 144

8.3.5 Tarefa Estimar Prazo ........................................................................................... 145

8.3.6 Tarefa Estimar Custo ........................................................................................... 146

8.3.7 Tarefa Executar Medio ..................................................................................... 147

8.3.8 Tarefa Analisar Medio ..................................................................................... 150

8.3.9 Tarefa Avaliar Processo de Medio ................................................................... 156

8.4 Avaliao da Implantao do ProMePE .................................................................... 157


8.5 Consideraes Finais ................................................................................................. 158
9 CONCLUSES E TRABALHOS FUTUROS .............................................................. 160

9.1 Trabalhos Futuros ...................................................................................................... 162


REFERNCIAS BIBLIOGRFICAS .................................................................................. 163

APNDICE A ProMePE: Plano de Medio de Referncia .............................................. 171

APNDICE B ProMePE: Plano de Medio do Projeto (Estudo de Caso) ....................... 185

APNDICE C ProMePE: Planilha de Coleta e Anlise dos Dados do Projeto (Estudo


de Caso) ................................................................................................................................. 197

APNDICE D ProMePE: Relatrio de Avaliao do Processo (Estudo de Caso) ............ 212


18

1 INTRODUO

Desenvolver software hoje um desafio. Diversas abordagens para o desenvolvimento


de software tm surgido tendo como objetivo comum produo de software de
qualidade. O esforo est voltado para o desenvolvimento de sistemas menos propensos
a falhas, mais eficientes e com o menor custo de desenvolvimento possvel
(SOMMERVILLE, 2009).
O avano da tecnologia, o aumento no tamanho e complexidade dos sistemas faz
com que as organizaes, de todo o mundo, busquem aprimorar as tcnicas de
desenvolvimento de software. Tal aprimoramento tem como foco melhorar a qualidade
do processo de desenvolvimento e conseqentemente do produto. Desta forma, na
tentativa de assegurar a qualidade do processo de desenvolvimento de software, muitas
empresas esto adotando modelos de maturidade de software, como o CMMI (SEI,
2006) e MPS-BR (SOFTEX, 2009a). Esses modelos definem os elementos necessrios
para tornar um processo de desenvolvimento de software definido, eficiente e
controlado, atravs de etapas evolutivas do processo.
Para alcanar nveis cada vez mais altos de qualidade, torna-se necessrio
melhorar o ciclo de vida do software e, para tornar isto possvel, dados quantitativos que
descrevam a realidade dos produtos e do processo precisam ser obtidos e devidamente
analisados. Segundo Demarco (DEMARCO, 1986), voc no pode controlar aquilo
que voc no mede.
Nesse cenrio, a realizao das estimativas de software est inserida como um
primeiro passo no processo de medio e garantia da qualidade do processo e do
produto (ANDRADE; OLIVEIRA, 2004). O clculo de estimativas de tamanho,
esforo, prazo e custo so a base para um processo de medio (VASQUEZ, 2003).
A estimativa de software considerada uma das primeiras atividades da fase de
planejamento do projeto e parte essencial da melhoria do processo de software.
Estimativas eficientes permitem a verificao da viabilidade do projeto, a elaborao de
propostas tcnicas e comerciais, a confeco de planos e cronogramas detalhados, o
acompanhamento efetivo do projeto (MONTEIRO, 2005), controle da produtividade da
equipe, do custo, do prazo e do esforo estimado para o desenvolvimento do projeto,
alocao adequada da equipe, definio clara das responsabilidades, indicao de
desempenho, avaliao em relao s novas tecnologias, melhoria na preciso das
19

estimativas, entre outros. A partir dos dados estimados possvel controlar o realizado,
comparar e manter as medies em uma base histrica e servir de insumo em futuros
projetos.
Ao elaborar uma estimativa para o desenvolvimento de um projeto de software
desejvel que haja um conhecimento sobre tcnicas de estimativas, uma viso global do
escopo do projeto a ser gerenciado e um histrico de estimativas de outros projetos
semelhantes o que capacita o gerente a quantificar, administrar e planejar mais
efetivamente o projeto a ser produzido. Planejar o projeto somente baseando-se no
feeling ou em experincias anteriores gera, na maioria das vezes, estouro de prazos e
elevado custo de desenvolvimento.
Dessa maneira, a medio de software auxilia no monitoramento do processo de
desenvolvimento do software, desde a estimativa at a medio do realizado,
proporcionando uma avaliao contnua desse processo e possibilitando alteraes caso
seja identificado algum desvio (ROCHA; MALDONARO; WEBER, 2001). Atravs da
medio, o processo de produo de software pode ser monitorado, proporcionando
uma avaliao constante do processo e dos produtos e a possibilidade de ajustes em
funo de tendncias detectadas.
Existem muitos trabalhos importantes na rea de estimativa (ALBRECHT,
1979) (SYMONS, 1991) (KARNER, 1993) (IFPUG, 1999) (BOEHM, 2000) e na rea
de medio que auxiliam na definio e implantao de medidas e de um processo de
medio (SEI, 2006) (SOFTEX, 2009a) (BASILE; CALDIERA; ROMBACH, 1994)
(DOD, 2003). Um deles, o modelo de processo de medio, Practical Software and
Systems Measurement (PSM) (DOD, 2003), um modelo internacionalmente conhecido
e tem como objetivo guiar a definio de processos de medio. O PSM serviu de base
para a construo de um padro internacional de medio, ISO/IEC 15939 (ISO/IEC
15939, 2007), e para definio da rea de processo de medio do CMMI (SEI, 2006).
O PSM e demais modelos e tcnicas de medio foram desenvolvidos na forma de
processos genricos, para atender s mais diversas organizaes.
As Micro e Pequenas Empresas de Software (MPES), em especial, tem sentido
dificuldade em utilizar essas abordagens (ANACLETO; WANGENHEIM; HAMMES,
2002) (GAVA et al., 2006) (LEY; GARCIA; PIATTINI, 2008). Como as MPES
representam cerca de 77% das empresas de software nacional (MCT, 2005) e diante da
relevncia de um processo de medio na melhoria do processo e do produto, observou-
20

se a necessidade de definio de um programa de medio considerando os fatores de


dificuldades enfrentados por tais empresas.
Esse captulo introdutrio est dividido da seguinte forma: a Seo 1.1 descreve
a motivao desse trabalho para MPES e os benefcios e dificuldades de medir, a Seo
1.2 descreve o objetivo geral desse trabalho, a Seo 1.3 detalha os objetivos especficos
e a Seo 1.4 mostra a organizao dessa dissertao em relao aos captulos.

1.1 Motivao

As grandes organizaes brasileiras de software so caracterizadas por possurem,


segundo (MCT, 2005), mais de 100 empregados e normalmente os programas de
medio so projetados para empresas nesse contexto (SCHNAIDER et al., 2004)
(BASILI; ROMBACH, 1994) (GARCIA; NUNES, 2006) (GAVA et al., 2006). Isso se
deve, principalmente, pela disponibilidade de recursos humanos e financeiros para a
implantao desses programas. Por outro lado, as MPES, segundo (MCT, 2005),
empresas com at 50 empregados, representam uma parcela significativa no percentual
de empresas brasileiras desse ramo e possuem caractersticas tpicas, como por exemplo
(ANDRADE; FREITAS; SOUZA, 2008): baixa intensidade de capital, imaturidade nas
metodologias, crescimento por demanda, acmulo de papis entre os funcionrios e
utilizao de mo de obra no qualificada.
Outro problema crtico enfrentado pelas MPES est relacionado prpria cultura
organizacional, onde os funcionrios esto acostumados informalidade ou at mesmo
ausncia de processos. Em alguns casos, a implantao de processo vista como
aumento da burocracia e restrio liberdade individual (LARYD; ORCI, 2000). Esta
ausncia de processos bem definidos caracteriza um dos fatores para a grande
quantidade de falncias nessas MPES. No Brasil, cerca de 50% das MPES fecham aps
os trs primeiros anos de vida (MCT, 2005). Este cenrio tambm se repete em vrios
outros pases em todo o mundo (RICHARDSON; WANGENHEIM, 2007). Dessa
forma, um caminho que contribui para que essas empresas se tornem competitivas
investir na melhoria dos processos.
Segundo (MCT, 2005) as MPES enfrentam mais um problema: carncia na
utilizao de mtricas consideradas primitivas (estimativas), Tabela 1.1, e na definio
de processos formais de medio, Tabela 1.2. Pode-se observar na Tabela 1.1 que a
grande maioria das MPES no realizam estimativas baseadas em tcnicas formais. De
21

acordo com a Tabela 1.2 uma minoria das MPES utiliza programas de medio como
forma de verificar o andamento dos projetos e auxiliar nas tomadas de decises.

Tabela 1.1 Porcentagem de mtricas primitivas utilizadas para medir a produtividade dos
processos de software (MCT, 2005)
Categorias Total Micro Pequena Mdia Grande
Linhas de
10,3% 7,5% 10,3% 11,9% 14,6%
cdigo (LOC)
Pontos por
funo
18,2% 10,6% 21,4% 14,3% 28,1%
(Function
Point)
Outras
6,7% 3,7% 5,5% 11,9% 11,5%
Mtricas
No utiliza 70% 81,4% 66,9% 69% 55,2%

Tabela 1.2 Porcentagem de empresas que utilizam prticas de engenharia de software (MCT,
2005)
Categorias Total Micro Pequena Mdia Grande
Auditorias 22,6% 7,8% 22,1% 39% 39,4%

Reviso por pares 16,3% 3,9% 16,4% 29,3% 30,9%

Levantamento de
Requisitos 18,1% 12,4% 17,1% 22% 27,7%
qualidade
Medies
17,4% 6,5% 17,9% 26,8% 30,9%
(Mtricas)
Testes 54,9% 53,6% 61,4% 48,8% 51,1%
No adota tais
11,6% 18,3% 7,1% 7,3% 8,5%
prticas

Assim, alguns trabalhos tem surgido para ajudar as MPES a implementar um


processo de medio (LEY; GARCIA; PIATTINI, 2008) (WANGENHEIM; PUNTER;
ANACLETO, 2003) (ANACLETO; WANGENHEIM, 2002). Em todos eles, os fatores
de custo e esforo de implementar um programa de medio so largamente
considerados. Para Ley e Wangenheim (LEY; GARCIA; PIATTINI, 2008)
(WANGENHEIM; PUNTER; ANACLETO, 2003) o reuso de informaes de um
processo de medio uma forma de diminuir o custo e esforo da sua implantao.
22

Existem vrias formas de reusar as informaes e uma delas atravs de


padres. Padres so solues bem sucedidas para um determinado problema recorrente
(ALEXANDER, 1979) (COPLIEN, 1996). Ao documentarmos um padro estamos
garantindo que ele largamente utilizado e considerado uma boa soluo para um
problema.
Nesse contexto, surge a oportunidade de criao de um processo de medio
simplificado para as MPES (ANDRADE; SOUZA, 2009). A criao do processo ser a
partir de um conjunto de boas prticas de estimativas, documentadas como uma
linguagem de padres de software, para possibilitar o seu reuso (ANDRADE; SOUZA,
2008). Assim, o presente trabalho est voltado para gerentes e lderes de projetos que
necessitam medir quantitativamente o software e tem como objetivo guiar as MPES
atravs de um processo simplificado de boas prticas de como medir o software, dando
apoio desde a elaborao das estimativas de tamanho, esforo, prazo e custo at o
planejamento, realizao e anlise das medidas.

1.1.1 Benefcios e Dificuldades das Medies


Atravs da medio, o processo de produo de software pode ser monitorado,
proporcionando uma avaliao constante do processo e a possibilidade de ajustes diante
das tendncias detectadas. Assim, um programa de medio de software contribui para
alcanar certo nvel de maturidade nas questes de controle e desenvolvimento dos
produtos de software. A medio permite o aprendizado organizacional bem como a
criao de competncias atravs do acmulo de experincias no desenvolvimento dos
projetos. Os benefcios e valores agregados medio dizem respeito s decises e
aes tomadas a partir da anlise dos dados obtidos.
Sendo assim, uma organizao de software, em especial uma MPES, pode ter
por objetivo estabelecer um processo de medio por vrias razes, entre elas
(PFLEEGER; ROMBACH, 1994) (STAA; HAZAN, 2004):
Entendimento dos processos de desenvolvimento adotados;
Suporte gerncia de projeto, atravs de dados;
Avaliao de melhoria do processo de desenvolvimento;
Identificao dos problemas sistemticos encontrados nos produtos e no
processo.
23

Outros benefcios da medio so (LEY; GARCIA; PIATTINI, 2008)


(KANTORSKI; KROTH, 2004):
Maior controle do processo e do produto por parte dos gerentes;
Maior capacidade para quantificar decises a serem tomadas;
Melhor entendimento do processo e ambiente de desenvolvimento;
Identificao de reas de potencial melhoria no processo, bem como uma
mtrica objetiva do esforo necessrio para melhoria;
Comunicao entre membros da organizao otimizada;
Previsibilidade: dados quantitativos podem ser usados para gerar indicadores de
tendncias ou estimativas mais apuradas.
A maioria dos profissionais da rea de desenvolvimento de software
compreendem a importncia e os benefcios trazidos por um processo de medio, mas
infelizmente a sua introduo marcada por dificuldades, inicialmente na definio e
posteriormente na sua execuo. As principais razes para essas dificuldades no so
problemas tcnicos e sim organizacionais, tais como (SCHNAIDER et al., 2004) (LEY;
GARCIA; PIATTINI, 2008):
No alinhamento aos objetivos de negcio;
Resistncia cultural;
Falta de liderana;
Uso incorreto dos dados medidos e coletados.
Diante dessas dificuldades, a existncia de um processo de medio simples e
bem definido pode facilitar a sua implantao nas MPES e permitir um maior controle
dos projetos.

1.2 Objetivo Geral

Definir um processo de medio de software simplificado, direcionado para Micro e


Pequenas Empresas, baseado em boas prticas de tcnicas reconhecidas de estimativa de
software, e com aderncia ao modelo de processo do Practical Software and System
Measurement (PSM).
24

1.3 Objetivos Especficos

No sentido de alcanar o objetivo geral descrito acima, os seguintes objetivos


especficos so definidos:
Levantar as caractersticas especfcas das Micro e Pequenas Empresas com
impacto na implantao de processos de estimativa e medio, atravs da anlise
de diferentes abordagens de implantao de processos em geral para MPES;
Levantar e catalogar os requisitos para a construo de um processo de
estimativa e medio especfico para MPES, a partir das caractersticas
levantadas anteriormente;
Documentar uma linguagem de padres de estimativa a partir do levantamento
de boas prticas presentes em tcnicas reconhecidas de estimativa, como a
Anlise de Pontos de Funo e Pontos de Casos de Uso;
Definir, a partir da linguagem de padres de estimativa documentada
anteriormente, um processo simplificado de medio de software aderente no
PSM;
Analisar o processo proposto atravs de um estudo de caso.

1.4 Organizao dos Captulos

Este trabalho est organizado em nove captulos, incluindo esta introduo, alm de um
conjunto de apndices descritos resumidamente a seguir:
O Captulo 2 apresenta a fundamentao terica em relao a estimativa e
medio, com seus principais conceitos.
O Captulo 3 apresenta a fundamentao terica em relao aos padres de
software e o seu objetivo de reusabilidade.
O Captulo 4 discorre sobre alguns trabalhos relacionados na rea de estimativa
e medio.
O Captulo 5 exibe um conjuntos de requisitos para a definio de um processo
de medio para MPES e mostra como os trabalhos relacionados no Captulo 4 atendem
a esses requisitos.
O Captulo 6 apresenta uma linguagem de padres de estimativa documentada a
partir de boas prticas de clculo de estimativa encontradas na literatura.
25

O Captulo 7 exibe a proposta principal deste trabalho, compreendendo um


processo de medio simplificado para MPES baseado em padres, ProMePE, sendo
detalhado suas tarefas, papis e artefatos a ser usados pela organizao que venha a
implement-lo, alm de como ProMePE atende aos requisitos descritos no Captulo 5.
O Captulo 8 apresenta um estudo de caso da aplicao do ProMePE em uma
MPES, com seus benefcios e dificuldades.
O Captulo 9 exibe as principais concluses e trabalhos futuros.
Os apndices mostram os templates sugeridos pelo processo proposto e os
documentos utilizados no estudo de caso.
26

2 ESTIMATIVA E MEDIO

2.1 Introduo

As estimativas de software ocorrem sempre que h a necessidade de planejamento do


projeto e so fundamentais para fornecerem um guia para a distribuio do tempo de
cada atividade e dos recursos. O processo de estimativa apia a gerncia de projetos
(SEI, 2006) (SOFTEX, 2009a) e constitudo de uma srie de atividades ou
procedimentos como a estimativa de tamanho, de esforo, de prazo, de custo, avaliao
dos riscos e acompanhamento das estimativas (ARGAVAL, 2001) (VASQUEZ, 2003).
O clculo da estimativa de tamanho a primeira atividade de um processo de estimativa
a partir do qual so realizadas as demais estimativas. A ltima atividade, de
acompanhamento das estimativas, verifica se o realizado est de acordo com as
estimativas calculadas e entrada para um processo de medio (ARGAVAL, 2001).

A medio tambm uma rea de apoio que auxilia os gerentes de projetos a


tomar as decises tcnicas e gerenciais e mostra como as informaes do
desenvolvimento do software esto relacionadas de forma quantitativa. A medio
funciona bem melhor quando integrada com outras disciplinas, como a de gerncia de
projeto e de gesto de riscos e de desempenho financeiro. Juntos, eles ajudam a
identificar e priorizar os pontos chaves, gerenciar a alocao de recursos para otimizar o
custo do projeto, cronograma e curva de desempenho, por exemplo (DOD, 2003).

Diante disso, percebe-se uma interseco entre as reas de estimativas e


medio, uma vez que preciso estimar, planejar, para posteriormente comparar com o
realizado e assim, possibilitar o constante refinamento das estimativas para os projetos
subseqentes.

Este captulo tem como objetivo introduzir os conceitos fundamentais de


estimativa e medio. A Seo 2.2 detalha duas das principais tcnicas de estimativa de
tamanho, a Anlise de Pontos de Funo (APF) e a Pontos de Caso de Uso (PCU). A
Seo 2.3 expe algumas definies relativas medio e o modelo de processo de
medio utilizado nesse trabalho, o PSM. A Seo 2.4 descreve as consideraes finais
do captulo.
27

2.2 Estimativas

As estimativas constituem a base para a elaborao do planejamento do projeto. Em


especial, as estimativas de tamanho devem ser utilizadas para a derivao das demais
estimativas como esforo, prazo e custo para o desenvolvimento do projeto.
Um dos principais riscos que atinge o processo de estimativa a falta de
credibilidade nas estimativas elaboradas pela equipe (BOEHM, 2000). Isso ocorre
freqentemente quando os projetos so subestimados ou superestimados. A preciso das
estimativas de tamanho essencial para um correto planejamento do projeto, o que
inclui a elaborao de cronograma e oramento realistas.
Essa seo tem por objetivo introduzir duas tcnicas largamente conhecidas de
estimativa de tamanho que serviram de base para a documentao da linguagem de
padres que ser descrita no Captulo 6. A Subseo 2.2.1 descreve a tcnica de Anlise
de Pontos de Funo e a Subseo 2.2.2 detalha a tcnica de Pontos de Caso de Uso
(PCU).

2.2.1 Anlise de Pontos de Funo

A tcnica de Anlise de Pontos de Funo (APF) foi desenvolvida na dcada de 70 por


Allan Albrecht (ALBRECHT, 1979). Desde ento, aps alguns refinamentos da tcnica,
a APF tornou-se a mtrica de estimativa mais utilizada na engenharia de software e por
isso, virou um padro internacional em 2002 atravs da norma ISO/
IEC 20.926 (ISO/IEC 20.926, 2003). A mtrica APF permite uma contagem indicativa
no nicio do desenvolvimento com a especificao dos requisitos independente da
tecnologia utilizada para implementao. O processo de contagem dessa mtrica
composto por sete etapas, conforme Figura 2.1, descritas a seguir:
1. Determinar Tipo de Contagem: a APF se prope a estimar o tamanho de projetos em
desenvolvimento, aplicaes em uso ou projetos de manuteno;
2. Identificar o Escopo da Contagem e a Fronteira da Aplicao: o escopo define as
funes que sero contadas de acordo com a viso do usurio, e a fronteira da
aplicao separa o projeto a ser contado dos usurios e das aplicaes externas ao
domnio do projeto. O escopo da contagem pode abranger:
o Todas as funcionalidades disponveis;
o Apenas as funcionalidades efetivamente utilizadas pelo usurio;
28

o Algumas funcionalidades especficas, como relatrios.

Contagem
1. Determinar 5. Determinar Contagem
Tipo de Contagem de Pontos de Funo No
Ajustados
3. Contar
Funes do Tipo
Dado
2. Identificar Escopo 7. Calcular o nmero
da Contagem e de Pontos de Funo
Fronteira da 4. Contar Ajustados
Aplicao Funes doTipo
Transao

6. Determinar Valor
do Fator de Ajuste

Figura 2.1 Contagem de Transao da Tcnica APF (IFPUG, 1999)

A fronteira da aplicao indica o limite entre o software que est sendo medido e
o usurio. Define o que externo aplicao e pode ser considerada como a interface
conceitual entre a aplicao interna e o mundo externo do usurio. A fronteira atua
como uma 'membrana' pela qual os dados processados por transaes passam para
dentro e para fora da aplicao.
3. Contar as Funes do Tipo Dados: as funes de dados consistem de Arquivos
Lgicos Internos (ALI) e Arquivos de Interface Externa (AIE). Um ALI um grupo
lgico de dados de controle sob o ponto de vista do usurio e a manuteno feita
internamente pela aplicao. O ALI uma entidade lgica persistente, mantida
dentro da fronteira da aplicao. Um AIE um grupo lgico de dados referenciado
na aplicao cuja responsabilidade pela manuteno de outra aplicao, ou seja,
no mantido pela aplicao que est sendo contada e portanto so armazenados
fora da fronteira da aplicao. Um AIE de uma aplicao sempre ser contado como
um ALI na aplicao de origem. A Figura 2.2 ilustra o processo de contagem de
funes do tipo dado.
A complexidade dos ALI identificada atravs do nmero de itens de dados e
dos registros lgicos. Item de dados representa um segmento de um registro do ALI e
so identificados pelo usurio. So os campos da tabela, por exemplo, e deve-se
29

contabilizar um item de dado para cada campo. J os registros lgicos so subgrupos de


dados reconhecidos pelo usurio dentro de um ALI.

Identificar ALI

Determinar Complexidade
e Contribuio
3. Contar
Funes do Tipo
Dado
Identificar AIE

Determinar Complexidade
e Contribuio

Figura 2.2 Detalhe da etapa de Contagem de Funes do Tipo Dado da APF

De acordo com o nmero de itens de dados e registros lgicos identificados,


deve-se classificar cada ALI e AIE, conforme Tabela 2.1, e atribuir pesos de 7, 10 ou 15
para os ALI e 5, 7 ou 10 para os AIE relativo s complexidades baixa, mdia e alta,
respectivamente.

Tabela 2.1 Complexidade Funcional (IFPUG, 1999)


Itens de Dados
Registros Lgicos 1 a 19 20 a 50 51 ou mais
1 BAIXA BAIXA MDIA
1a5 BAIXA MDIA ALTA
6 ou mais MDIA ALTA ALTA

4. Contar as Funes do Tipo Transao: representam as funes de processamento


dos dados fornecidos pela aplicao ao usurio. As funes transacionais podem ser
Entradas Externas (EE), Sadas Externas (SE) e Consultas Externas (CE).
As Entradas Externas (EE) so transaes que processam dados ou informaes
de controle originados de fora da fronteira da aplicao que tem por objetivo manter o
ALI ou alterar o comportamento do sistema.
As Sadas Externas (SE) so transaes que enviam dados ou informaes de
controle para fora da fronteira da aplicao. As transaes podem conter clculos, a
30

criao de dados derivados, a manuteno de um ALI ou a alterao do comportamento


do sistema.
As Consultas Externas (CE) so combinaes entre atividades de entrada e sada
de dados, ou seja, so solicitaes enviadas para a aplicao, a qual gera uma
recuperao correspondente e a exibio de dados.
Cada EE, SE e CE deve ser classificada com relao sua complexidade
baseado em:
o Nmero de Arquivos Referenciados:
 Um ALI lido ou mantido pela funo do tipo transao;
 Um AIE lido pela funo transao.
o Nmero de Itens de Dados Referenciados:
 De acordo com a viso do usurio.
De acordo com o nmero de itens de dado e a quantidade de arquivos
referenciados, cada EE deve ser classificada de acordo com a Tabela 2.2, e cada SE e
CE deve ser classificada de acordo com a Tabela 2.3.
Para cada EE ou CE com complexidade baixa, mdia e alta, deve-se atribuir os
pesos 3, 4 ou 6 respectivamente. Para cada SE com complexidade baixa, mdia e alta,
deve-se atribuir os pesos 4, 5 ou 7 respectivamente.

Tabela 2.2 Complexidade de Entrada Externa da APF (IFPUG, 1999)


Itens de Dados Referenciados
Arquivos Referenciados 1a4 5 a 15 16 ou mais
0a1 BAIXA BAIXA MDIA
2 BAIXA MDIA ALTA
3 ou mais MDIA ALTA ALTA

Tabela 2.3 Complexidade de Sada e Consulta Externa da APF (IFPUG, 1999)


Itens de Dados Referenciados
Arquivos Referenciados 1a5 6 a 19 20 ou mais
0a1 BAIXA BAIXA MDIA
2a3 BAIXA MDIA ALTA
4 ou mais MDIA ALTA ALTA

5. Determinar Contagem de Pontos de Funo No Ajustados (PFNA): aps identificar


as funes do tipo dado e as funes tipo transao, deve-se multiplicar o total de
31

ALI, AIE, EE, SE e CE pela respectiva complexidade para determinar o valor de


Pontos de Funo No Ajustado (PFNA). Logo,

   
   
 

onde Tipos Dados composto pela multiplicao da quantidade de ALI e AIE


pela respectiva complexidade, e Tipos Transaes formado pela multiplicao da
quantidade de EE, SE e CE pela respectiva complexidade.
6. Determinar o Valor do Fator de Ajuste (FA): tem o propsito de medir a influncia
de fatores tcnicos como os requisitos no funcionais da aplicao. Tem como
finalidade o ajuste dos Pontos de Funo No Ajustados em 35% de acordo com a
influncia de 14 caractersticas gerais, conforme Tabela 2.4.

Tabela 2.4 Caractersticas Gerais da APF (IFPUG, 1999)


Caractersticas Gerais
Comunicao de Dados Atualizao On-Line
Processamento Distribudo Processamento Complexo
Desempenho Reutilizao de Cdigo
Utilizao de Equipamentos Facilidade de Implantao
Volume de Transaes Facilidade Operacional
Entrada de Dados On-Line Mltiplos Locais
Eficincia do Usurio Final Facilidade de Mudanas

Cada uma das caractersticas possui um nvel de influncia sobre a aplicao que
varia de 0 a 5: 0 nenhuma influncia, 1 influncia mnima, 2 influncia moderada,
3 influncia mdia, 4 influncia significativa, 5 grande influncia. Aps a
atribuio do nvel de influncia de cada caracterstica, deve-se som-los para obter o
Nvel de Influncia da aplicao e aplicar a seguinte frmula:

       0,01#  0,65

7. Calcular o Nmero de Pontos de Funo Ajustados (PFA): so calculados a partir


dos pontos de funo no ajustados (PFNA) e do fator de ajuste (FA) de acordo com
a frmula:
    
O valor obtido dessa multiplicao representa a estimativa de tamanho do projeto em
Pontos de Funo.
32

2.2.2 Pontos de Caso de Uso

A tcnica de Pontos de Casos de Uso uma mtrica para o clculo do tamanho de


software orientado a objetos. Os Pontos de Casos de Uso (PCU) foram criados em 1993
por Gustav Karner (KARNER, 1993) e so baseados na tcnica de Anlise de Pontos
por Funo (APF) (ALBRECHT, 1979) onde as funcionalidades do usurio de entrada e
sada so insumo para ambas as tcnicas. A mtrica PCU permite fazer estimativas de
tamanho logo no incio do projeto, com algum entendimento do domnio do problema.
Por ser centrada nos casos de usos importante que todos eles estejam documentados
de forma padronizada. O processo de contagem dessa mtrica composto por seis
etapas, conforme ilustrado na Figura 2.3.

Contagem

4. Clculo
1. Classificao dos
dos Atores Fatores
Tcnicos
3. Clculo dos 6. Clculo dos
Pontos de Pontos de
Casos de Uso Casos de Uso
2. Classificao no Ajustados
dos
Casos de Uso 5. Clculo
dos Fatores
Ambientais

Figura 2.3 Processo de Contagem da Tcnica PCU (KARNER, 1993)

Abaixo so descritas as etapas do PCU.


1. Classificao dos Atores: identificar os atores e relacion-los de acordo com seu
nvel de complexidade. Os atores podem ser classificados em simples, mdio e
complexo, com pesos 1, 2 e 3, respectivamente, conforme Tabela 2.5.

Tabela 2.5 Classificao dos Atores do PCU (KARNER, 1993)


Complexidade do Ator Descrio Peso
Simples Aplicao com APIs definidas. 1
Mdio Aplicao com interface baseada em protocolo ou 2
interao de usurio baseado em linhas de comando.
Complexo Interao de Usurio baseado em Interface Grfica ou 3
Pgina Web.
33

Cada ator do projeto classificado e o peso total dos atores do sistema,


Unadjusted Actor Weight (UAW), calculado pela soma dos produtos de cada tipo de
ator por seu respectivo peso.
2. Classificao dos Casos de Uso: identificar os casos de uso e classific-los de
acordo com sua complexidade. Os casos de uso podem ser classificados em simples,
mdio ou complexo de acordo com o nmero de transaes presentes na descrio
do caso de uso e nos cenrios alternativos. Uma transao um conjunto de
atividades que podem ser executadas juntas ou no. Cada passo do caso de uso pode
ser considerado uma transao. Karner (KARNER, 1993) sugere que no sejam
contados os casos de uso de incluso e de extenso. Uma outra forma de contar a
complexidade dos casos de uso atravs da quantidade de classes de anlise por
caso de uso. Um caso de uso simples composto por pelo menos cinco classes de
anlise, um caso de uso mdio formado entre cinco e dez classes de anlise e um
caso de uso complexo formado por mais de 10 classes de anlise, Tabela 2.6. A
quantidade de transaes ou classes de anlise por casos de uso determina a
complexidade do caso de uso.

Tabela 2.6 Classificao dos Casos de Uso do PCU (KARNER, 1993)


Complexidade do Caso de Uso Descrio Peso
Simples Considerar at 3 transaes com menos de 5 5
classes de anlise.
Mdio Considerar de 4 a 7 transaes com 5 a 10 10
classes de anlise.
Complexo Considerar mais de 7 transaes com pelo 15
menos 10 classes de anlise.

Os pesos dos casos de uso so calculados da mesma forma dos atores. O peso
total dos casos de uso do sistema, Unadjusted Use Case Weight (UUCW), calculado
pela soma dos produtos de cada tipo de caso de uso por seu respectivo peso.
3. Clculo dos Pontos de Casos de Uso no Ajustados: o peso total dos atores (UAW)
adicionado ao peso total dos casos de uso (UUCW) para obteno dos pontos de
casos de uso no ajustados, Unajusted Use Case Points (UUCP). Logo,
UUCP = UAW + UUCW;
4. Clculo dos Fatores Tcnicos: um fator que mede o nvel tcnico do sistema e
influi diretamente no clculo da estimativa de tamanho. O objetivo determinar o
34

Fator de Complexidade Tcnica, Technical Complexity Factor (TCF), a partir do


conhecimento tcnico do sistema em relao a algumas caractersticas pr-
determinadas, como facilidade de instalao, desempenho e segurana, por exemplo,
Tabela 2.7. Cada fator (caracterstica) classificado por uma escala de 0 a 5, que
varia de acordo com o grau de dificuldade da aplicao a ser construda. O valor 0
indica ausncia de influncia da cararacterstica, 3 influncia mdia e o valor 5
indica influncia significativa atravs de todo o processo.
Aps a atribuio dos valores para cada fator, o resultado dos Fatores Tcnicos,
Technical Factor TF, calculado pela soma dos produtos de cada peso por seu
respectivo valor na escala de 0 a 5. A partir do valor dos Fatores Tnicos obtido o
Fator de Complexidade Tcnica, conforme frmula abaixo:
TCF = 0.6 + (0.01*TF)

Tabela 2.7 Fatores Tcnicos, Technical Factors, da PCU (KARNER, 1993).


Descrio Peso
Sistemas Distribudos 2,0
Desempenho da Aplicao 1,0
Eficincia do Usurio Final 1,0
Processamento Interno Complexo 1,0
Reusabilidade de Cdigo em outras aplicaes 1,0
Facilidade de Instalao 0,5
Usabilidade 0,5
Portabilidade 2,0
Facilidade de Manuteno 1,0
Concorrncia 1,0
Caractersticas Especiais de Segurana 1,0
Acesso Direto para Terceiros 1,0
Facilidades Especiais de Treinamento 1,0

5. Clculo dos Fatores Ambientais: os fatores de complexidade ambientais,


Environmental Complexity Factor (ECF), indicam a maturidade da equipe de
desenvolvimento da aplicao, ou seja, o seu grau de experincia. Esses fatores so
obtidos da mesma forma que os fatores tcnicos, com caractersticas e pesos pr-
determinados. Cada um dos fatores deve ser classificado atravs de uma escala de 0
a 5, onde 0 indica ausncia de experincia, 3 indica mdia experincia e 5 indica
muita experincia. Aps a atribuio dos valores para cada fator, o resultado dos
35

Fatores Ambientais, Environment Factor (EF), calculado pela soma dos produtos
de cada peso por seu respectivo valor na escala de 0 a 5, Tabela 2.8.
O Fator de Complexidade Ambiental obtido atravs da frmula:
ECF = 1,4 + (-0,03*EF).

Tabela 2.8 Clculo dos Fatores Ambientais.do PCU (KARNER, 1993)


Fator Descrio Peso
F1 Familiaridade com o Processo de 1,5
Desenvolvimento de Software
F2 Experincia na Aplicao 0,5
F3 Experincia em OO, na linguagem e na 1,0
tcnica de desenvolvimento
F4 Capacidade do Lder de Anlise 0,5
F5 Motivao 1,0
F6 Requisitos Estveis 2,0
F7 Trabalhadores com dedicao parcial -1,0
F8 Dificuldade da Linguagem de Programao -1,0

6. Clculo dos Pontos de Casos de Uso: o tamanho total do projeto do software, Use
Case Points (UCP), obtido atravs do produto entre os Pontos de Casos de Uso
no Ajustados (UUCP), Fatores de Complexidade Tcnicas (TCF) e Fatores de
Complexidade Ambientais (ECF), de acordo com a frmula:
UCP = UUCP*TCF*ECF
O valor obtido dessa multiplicao representa a estimativa de tamanho do projeto
em Pontos de Casos de Uso.

2.3 Medio de Software

A medio o processo pelo qual nmeros ou smbolos so designados a atributos de


entidades do mundo real com o objetivo de descrev-los de acordo com regras
previamente definidas (FENTON, 1994). Uma entidade pode ser caracterizada como um
objeto ou um evento (carro ou uma viagem, por exemplo). Um atributo uma
caracterstica ou propriedade da entidade (por exemplo, cor e modelo do carro ou ainda
o tempo de uma viagem). As entidades de software podem ser divididas em trs
categorias: processos, produtos e recursos (FENTON, 1994). Processos so colees de
atividades relativas ao desenvolvimento ou manuteno do software. Produtos so
quaisquer artefatos provenientes de uma atividade do processo. Recursos so entidades
36

requeridas para realizar uma atividade do processo. Atravs de um conciso processo de


medio pode-se coletar e analisar dados quantitativos sobre os aspectos relevantes dos
processos, produtos e recursos.
Uma mtrica de software qualquer tipo de medio em um sistema, processo
ou documentao. As mtricas correspondem a uma funo de dois ou mais valores e
podem representar, por exemplo: medidas de tamanho de um produto, nmero de
defeitos relatados em um produto entregue, nmero de pessoas-dia para desenvolver um
componente de um sistema (SOMMERVILLE, 2009). As mtricas podem ajudar a
entender o processo tcnico usado para se desenvolver um produto, como tambm o
prprio produto.
Na definio de um processo de medio o nmero de mtricas que podem ser
utilizadas enorme. Existem basicamente duas abordagens para o levantamento das
mtricas que devem ser coletadas em um processo de medio: bottom-up e top-down
(PFLEEGER; ROMBACH, 1994).
A abordagem bottom-up parte da definio de um conjunto de mtricas que
independem dos objetivos da organizao. Essa abordagem pode gerar um esforo
desnecessrio na coleta de mtricas que no agregam real valor organizao. A
abordagem top-down, por outro lado, auxilia a derivar mtricas a partir das metas da
organizao e permite interpretar os dados coletados de acordo com o contexto das
metas definidas (BASILI; ROMBACH, 1994). A abordagem top-down a mais
utilizada atualmente. Alguns autores enfatizam que a utilizao de mtricas por si s
(abordagem bottom-up), no apresenta resultados significativos, e defendem a criao
de um processo de medio com atividades planejadas para a realizao das medies,
baseado nos objetivos da organizao, implementado e regularmente avaliado para se
tornar efetivo (BASILE; CALDIERA; ROMBACH, 1994) (DOD, 2003).
No entanto, a definio de um processo de medio no constitui uma tarefa
simples. Quando uma organizao opta por iniciar um programa de medio, vrias
aes devem ser tomadas: as medidas a serem coletadas devem ser definidas, a forma de
armazenamento deve ser selecionada e diretrizes para anlise desses dados devem ser
estabelecidas (BORGES; PAULA, 2003).
Diante disso, algumas abordagens top-down de definio de processo de
medio foram criadas e so largamente utilizadas, como o Goal-Question-Metric
(GQM) (BASILI; ROMBACH, 1994) e o Practical Software Measurement (PSM)
(DOD, 2003).
37

A subseo seguinte detalha o modelo de processo de medio PSM.

2.3.1 Practical Software Measurement (PSM)


O PSM um projeto patrocinado pelo Departamento de Defesa e Foras Armadas
Norte-Americanas. Foi construdo com base na experincia do governo e de projetos
industriais e representa as melhores prticas em medio utilizadas por profissionais da
rea de desenvolvimento de software. Assim, a iniciativa, que teve a participao de
universidades, empresas privadas e rgos governamentais, possui a estratgia de
agrupar as prticas de maior sucesso para compor um processo nico, que possa ser
utilizado como guia para a implantao de um processo de medio nas organizaes.
Para enfatizar a importncia do PSM, em 2003 os princpios do PSM foram
formalizados em um padro, o ISO/IEC 15939 (ISO/IEC 15939, 2007), que estabeleceu
algumas convenes terminolgicas em relao a medio. A Figura 2.4 ilustra que o
PSM foi a base de construo da ISO/IEC 15939 e do modelo de processo CMMI (SEI,
2006), alm de demais ISO. O PSM prov detalhes adicionais em relao s atividades
e tarefas presents na ISO 15939. O PSM prov tambm detalhes de como executar as
tarefas com sucesso, o que inclui exemplos de medidas, lies aprendidas, estudos de
caso e um guia detalhado de implementao.

Figura 2.4 PSM como referncia a demais modelos e padres (DOD, 2003)

O PSM tem como objetivo estabelecer um conjunto de prticas e servios para


auxiliar os gerentes de projetos a obter informaes objetivas sobre o andamento de
38

seus projetos, para que estes atinjam as metas pr-estabelecidas de prazo, custo e
qualidade.
Em linhas gerais, o PSM um modelo para a estruturao de mensurao em um
projeto de software. O PSM foi criado com a inteno de ser utilizado por:
Gerentes Tcnicos e de Projeto: com a finalidade de obter melhor entendimento do
uso da medio para o gerenciamento dos seus projetos. Os gerentes definem as
medidas especficas para atender as necessidades dos seus projetos;
Equipe Tcnica do Projeto: com a inteno de ajudar a implementar medies em
um ambiente de projeto;
Alta Gerncia ou Empresrios: para atender os requisitos associados com a
implementao da mensurao em suas organizaes.
O PSM utiliza da abordagem de medio top-down, ou seja, as atividades de
medio, para obterem sucesso, devem possuir duas caractersticas:
Alinhamento direto das atividades de coleta e anlise dos dados com as
necessidades de informao dos responsveis pela tomada de decises nos projetos.
O PSM usa das necessidades e objetivos da organizao para direcionar os
requisitos da medio;
A existncia de um processo de medio estruturado e bem documentado
(BORGES; PAULA, 2003).
Fundamentado nessas caractersticas, o PSM define dois modelos: o modelo de
informao e o modelo de processo de medio. O modelo de informao determina
como as medidas utilizadas devem ser especificadas para atender s necessidades de
informao. O modelo de processo especifica como o processo de medio deve ser
conduzido.
O modelo de informao determina como mapear as necessidades de informao
nos atributos dos produtos ou processos que se deseja medir. A construo de uma
medio deve descrever como os atributos devem ser combinados para formar os
critrios de deciso, base para a tomada de decises. Para isso, o modelo de informao
orienta a criao de trs nveis de medidas:
Medidas base: medidas obtidas diretamente da observao das entidades do produto
ou processo que est sendo medido;
Medidas derivadas: valores obtidos a partir da aplicao de algoritmos ou funes
matemticas que combinam duas ou mais medidas;
39

Indicadores ou critrios de deciso: viso de um conjunto de medidas em um


formato grfico ou tabular voltado para o atendimento de uma ou mais necessidades
de informao.
A Figura 2.5 apresenta a combinao desses conceitos para formar a estrutura para a
construo das medies segundo o modelo de informao do PSM.

Figura 2.5 Detalhamento dos nveis de medidas do PSM (DOD, 2003)


Enquanto o modelo de informao fornece uma estrutura para a definio e
construo das medidas de acordo com as necessidades de informao, o modelo de
processo apresenta um conjunto de atividades que devem ser executadas para a
implementao de um processo de medio em um projeto ou organizao.
O modelo de processo de medio orienta na conduo das atividades de
medio em um projeto de desenvolvimento e formado por quatro atividades
principais que, segundo o PSM, so essenciais para o sucesso da implantao de
qualquer poltica de medio, so elas: planejar a medio, executar a medio, avaliar a
medio e estabelecer e sustentar o compromisso com a medio, conforme Figura 2.6.
A seguir sero descritas as atividades do modelo de processo de medio:
Atividade Planejar Medio: uma das atividades mais importantes na
definio do processo de medio e engloba a identificao e priorizao das
necessidades de informaes do projeto e a seleo das medidas de acordo com
estas informaes. Geralmente as necessidades de informaes do projeto vm
do modelo de medio de informao, onde so definidas as medidas. Alm da
identificao das medidas, nesta atividade so planejados como os dados sero
40

coletados e analisados a fim de satisfazer as necessidades de informaes do


projeto. Isto envolve a integrao das atividades de coleta de dados aos
processos que fornecem dados e a integrao das atividades de anlise de dados
aos processos que necessitam de tomadas de decises. Assim, permite a
integrao das atividades de mensurao aos processos tcnicos e gerenciais
existentes e assegura o uso efetivo das medidas pr-definidas no
projeto;

Processos Tcnicos e
Gerenciais Analisar Resultados
Objetivos

Ncleo do Processo de Medio


Estabelecer e
Sustentar Planejar Executar
Compromisso com a Medio Medio
Medio Plano de
Medio

Analisar Resultados e
Aes de Avaliar Executar Medies
Melhoria Medio

Escopo do PSM

Figura 2.6 - Modelo de Processo de Medio do PSM (DOD, 2003)

Atividade Executar Medio: tambm faz parte do ncleo do processo de


medio e contm todas as tarefas que compe a execuo do processo de
medio, a saber: coletar e processar os dados e disponibiliz-los para uso e
posterior anlise, anlisar as medidas e transform-las em indicadores e critrios
de decises de planejamento, alem de possibilitar aes corretivas e produo de
recomendaes decorrentes da anlise dos indicadores com os riscos e
obstculos, se existirem, ao sucesso do projeto;
Avaliar Medio: composto por tarefas relacionadas avaliao das medidas,
do processo de medio definido, coleta e armazenamento de lies aprendidas
com o processo de medio, ou seja, os casos de sucessos, os casos de fracassos
e com isso, possibilitar a identificao e melhorias do processo atual e prover
mais maturidade ao processo de medio organizacional;
Estabelecer e Sustentar o Compromisso com a Organizao: inclui
atividades como a obteno do comprometimento da organizao com o
41

processo de medio, a disponibilizao de recursos e infra-estrutura


organizacional e definio de responsabilidades.
Uma quinta atividade apresentada na Figura 2.6 trata dos processos tcnicos e
gerenciais, aos quais no correspondem a uma atividade especfica de medio, mas
esto relacionados, uma vez que as necessidades de informaes e as decises do
projeto so definidas e executadas pelos tomadores de decises, que so os gerentes de
projeto.
Nesse sentido, o PSM um guia de boas prticas de medio que apia tanto a
definio de medidas de acordo com as necessidades de informao como a construo
de um processo de medio ao sugerir um conjunto de atividades essenciais para a
execuo de um programa de medio.

2.4 Consideraes Finais

O presente captulo apresentou uma breve reviso terica relativa aos principais
conceitos de estimativa e medio de software.
Algumas das tcnicas de estimativa apresentadas mostram a preocupao dos
pesquisadores na elaborao de estimativas mais precisas e que tentem retratar o
tamanho do sistema naquele momento. As estimativas de software tm papel importante
no processo de medio uma vez que de posse delas algumas medidas podem ser
obtidas, principalmente medidas mais simples, de apoio gerencial e que podem ser
utilizadas mais facilmente pela MPES.
De maneira geral, as abordagens apresentadas ressaltam a importncia da rea de
medio para o processo de desenvolvimento de software, em especial, a realizao de
atividades de planejamento, coleta e anlise dos dados para que os resultados sejam
efetivos.
Para as MPES, escopo desse trabalho, a implementao de um processo de
medio requer maiores cuidados, principalmente devido limitao de recursos.
Portanto, o reuso de algumas informaes pode tornar o processo de medio menos
oneroso para tais empresas.
No captulo seguinte apresentada a fundamentao terica de padres de
software como um meio de reuso de informaes.
42

3 PADRES DE SOFTWARE

3.1 Introduo

Padres de Software tm se tornado um instrumento fundamental de garantia de


qualidade e produtividade no desenvolvimento de projetos de software. Alm de
fornecer um vocabulrio comum para expressar solues e uma linguagem para
relacion-las, os padres permitem a criao de uma biblioteca de solues para ajudar
na resoluo de problemas recorrentes, incentivando uma cultura de documentao e
reuso de boas prticas no processo de desenvolvimento de sistemas computacionais.
Todas as pessoas que lidam com a construo de software, sejam elas analistas,
projetistas ou desenvolvedores, certamente j se depararam com um problema que de
alguma forma j foi resolvido, de forma que a soluo para esse problema poderia
benefici-los. O reuso consiste na utilizao de quaisquer solues pr-existentes em
novos sistemas e tem sido largamente adotado por todos aqueles que produzem software
(BRAGA et al., 2001). Porm, tornar uma soluo reutilizvel e aproveitar todo seu
potencial no tarefa fcil, pois a reutilizao requer a documentao adequada do
conhecimento necessrio para a resoluo do problema.
Diante desse contexto, na ltima dcada, padres de software tm sido estudados
e documentados como uma forma promissora de propiciar o reuso, no somente na fase
de projeto, mas em todas as outras fases do desenvolvimento do software, como,
anlise, implementao e testes. Por intermdio dos padres podem ser documentadas
solues para diferentes tipos de problemas que em quaisquer que sejam seus nveis de
abstrao, podem ser reusadas por aqueles que se deparar com problemas similares.
Este captulo tem por finalidade introduzir o conceito de padres de software para
todos aqueles que desejam conhecer sobre essa forma de reuso, ao discutir em detalhes
os conceitos, classificaes e formatos de padres. A Seo 3.2 descreve os conceitos
bsicos de padres, juntamente com as reas de aplicao, tipos de padres, coletneas
de padres e formato dos padres. A Seo 3.3 descreve as consideraes finais do
captulo.
43

3.2 O que so padres?

Os primeiros conceitos de padres surgiram na rea de arquitetura, por meio do trabalho


de Christopher Alexander na dcada de 70 (ALEXANDER, 1979) (ALEXANDER et
al., 1977) (ALEXANDER et al., 1975). Ele criou as primeiras definies para os termos
padro e linguagem de padres, usadas hoje na rea de software. De acordo com
Alexander, padres podem ser definidos da seguinte forma:

Um padro uma entidade que descreve um problema que ocorre


repetidamente em um ambiente e ento descreve a essncia de uma soluo
para este problema, de tal forma que voc possa usar essa soluo milhes de
vezes, sem nunca utiliz-la do mesmo modo, (ALEXANDER et al., 1977).

Ou ainda como:

Como um elemento no mundo, cada padro uma relao entre um certo


contexto, um certo sistema de foras que ocorrem repetidamente naquele
contexto, e uma certa configurao espacial que permite que estas foras se
solucionem por si s, (ALEXANDER, 1979).

Como pode-se observar, nas definies de Alexander, o conceito de padres no


aplicvel apenas arquitetura, podendo ser usado ainda para documentar solues
recorrentes para problemas na rea de desenvolvimento de software.
Existem inmeras definies para o conceito de padres de software. Aqui so
apresentados alguns:

Um padro uma soluo para um problema em um contexto, (COPLIEN,


1994).
Um padro um pedao da literatura que descreve um problema de projeto e
uma soluo geral para o problema em um contexto particular, (COPLIEN,
1996).
Cada padro uma regra de trs partes, que expressa a relao entre um certo
contexto, um certo sistema de foras que ocorre repetidamente naquele
contexto, e certa configurao de software que permite solucionar as foras,
(GABRIEL, 2002).
44

De fato, todas as definies de padres levam para o mesmo objetivo:


documentar uma soluo recorrente para um problema que ocorre em um determinado
contexto. Vale destacar que os padres so documentaes de boas solues, ou seja,
solues realmente comprovadas pela experincia prtica.
A disseminao da utilizao de padres de software, em especial, padres de
projeto, iniciou atravs dos padres publicados no livro do GoF1 (GAMMA et al., 1995)
que retratam diversos tipos de solues para problemas de projeto em sistemas
orientados a objetos
Dessa forma, o uso de padres de software, em geral, permite no apenas a
reutilizao de solues j existentes e documentadas por especialistas, mas tambm a
captura de estruturas, prticas e tcnicas em um determinado domnio. A seguir, so
listados outros benefcios da utilizao de padres, tais como (VLISSIDES, 1990)
(SCHMIDT et al., 2000) (ANDRADE et al., 2003):
Melhorar a comunicao entre os engenheiros de software ao oferecer um
vocabulrio comum, conciso e compartilhado;
Otimizar o tempo ao concentrar esforo de desenvolvimento em aspectos
inditos e particulares do sistema;
Facilitar o entendimento de sistemas e a evoluo do cdigo. Quando utilizados
desde o incio do desenvolvimento, padres podem gerar menor retrabalho nas
etapas mais avanadas do projeto;
Melhor distribuio de responsabilidades e conseqente diminuio dos efeitos
colaterais causados por mudanas;
Facilitar a reestruturao de um sistema.
No caso especial de padres de projetos, pode-se citar as seguintes vantagens:
Independncia, ao permitir a adoo de solues abstratas e independentes de
implementao;
Possibilitar a criao de frameworks contendo padres de projeto j
implementados a fim de facilitar o reuso dos padres;
Modularidade, ao permitir maior autonomia funcional entre os mdulos com
conseqente diminuio da complexidade por quebrar o problema em problemas
menores.

1
Gang of Four: nome do grupo formato pelos quatros autores do livro
45

Segundo Coplien (COPLIEN; HARRISON, 2004), a utilizao de padres no


desenvolvimento de software contribui indiretamente para:
Maior produtividade, ao permitir a disponibilidade de solues prontas,
evitando o retrabalho;
Diminuio do tempo de desenvolvimento, ao possibilitar o reuso das
solues e conseqente diminuio do custo do software ao cliente;
Satisfao do cliente derivado do fator anterior.
Ainda segundo Coplien, a utilizao de padres, por si s, no oferece nenhum
desses benefcios. Eles so um instrumento que aumenta a habilidade humana e o poder
de aplicao de tecnologias, gerncia de boas prticas e oportunidades (COPLIEN;
HARRISON, 2004). Contudo, o uso de padres de projeto pode ocasionar
conseqncias negativas ao projeto, como as citadas em (ANDRADE et al., 2003):
Menor eficincia, ao exigir, em alguns casos, a incorporao de novas classes ou
camadas de aplicao, aumentando a quantidade de mtodos executados,
tornando o sistema mais lento. Assim, se a prioridade em um determinado
sistema o alto desempenho, deve-se tomar cuidado ao optar por utilizar certos
padres;
Menor legibilidade/manutenibilidade ao permitir, por exemplo, o aumento de
nveis hierrquicos de classes, podendo tornar o cdigo do sistema menos
legvel e consequentemente, elevando o custo de manuteno do mesmo,
principalmente para desenvolvedores que no tenham conhecimento tcnico
sobre os padres aplicados.
Em relao aos padres de software em geral, uma desvantagem da sua
utilizao seria a falta de motivao da equipe devido ausncia de conhecimento
prvio sobre padres, causando resistncia ao seu uso.
Segundo Alexander, o objetivo da arquitetura satisfazer as necessidades
humanas. A Qualidade sem Nome (The Quality Without a Name) um conceito
pregado por Alexander (ALEXANDER, 1979), cuja idia principal est no fato de que
todo padro deve ter certas caractersticas difceis de serem nomeadas que o fazem
satisfazer s necessidades do ser humano. Ao fazer uma analogia qualidade subjetiva
de Alexander, padres de software tambm precisam satisfazer s necessidades
daqueles que constroem software e para tal necessitam possuir qualidade. Mas o que faz
com que um padro seja realmente bom, com qualidade?
46

As premissas bsicas que tornam um padro bom, de acordo com Coplien


(COPLIEN; HARRISON, 2004), so:
Autenticidade. Os padres capturam solues comprovadas na prtica por meio
de usos conhecidos, ao invs de teorias ou postulados. A soluo do padro deve
dizer ao leitor o qu fazer de forma especfica e concreta. Um bom padro
descreve exemplos reais, que possam ser usados facilmente na prtica;
O padro resolve o problema. Os padres capturam solues para o problema
em um determinado contexto. Um bom padro deve ajudar o leitor a focar no
problema ao extrair as Foras (seo 3.2.3) importantes que apresentam
elementos favorveis e desfavorveis adoo da soluo para o problema.
Essas foras devem ser balanceadas pela soluo, de forma que o problema seja
resolvido da melhor maneira possvel diante do contexto existente;
A soluo do padro no bvia. O poder dos padres est na documentao de
solues que levaram esforo e tempo para serem concebidas e que podem ser
reusadas por pessoas inexperientes quando deparadas com o mesmo problema.
Um bom padro no possui solues simplistas e triviais;
O padro descreve um relacionamento. Um bom padro no descreve apenas os
mdulos que compem a soluo, mas descreve tambm os seus
relacionamentos atravs de estruturas dinmicas e mecanismos de
funcionamento da soluo;
O padro possui um componente humano. Um bom padro deve ser elegante e
til para prover ao ser humano o conforto e a facilidade de compreend-lo e
utiliz-lo de forma correta e estimulante.
importante lembrar que nem toda soluo ou boa prtica constitui um padro.
Mesmo que tenha algo que se deseja documentar com todos os requisitos de um padro,
ele no deve ser considerado um padro at que seja verificada a sua recorrncia
preferivelmente em no mnimo trs casos existentes. A esse fato, d-se o nome de Teste
de Paternidade do padro (APPLETON, 1997). Porm, a recorrncia por si s no
uma caracterstica to importante para um padro, alm disso, necessrio mostrar que
o padro adequado e til para o seu propsito. Enfim, para que um padro tenha
qualidade, todos esses fatores devem ser levados em considerao. Na dvida, deve-se
documentar o padro e submet-lo anlise da comunidade de padres.
47

3.2.1 reas de Aplicao e Tipos de Padres


Apesar da disseminao dos to conhecidos padres de projeto GoF, e do seu foco
inicial na comunidade de padres, os padres de software esto presentes em todas as
reas e domnios especficos da computao, incluindo: sistema operacional, segurana,
processos de software, anlise, projeto, desenvolvimento entre outros. Para quaisquer
que sejam as reas de atuao, um padro de software pode ser documentado e
reutilizado por aqueles do domnio em questo. Para isso, necessria a existncia de
uma boa soluo recorrente para um determinado problema do domnio.
Existem inmeros tipos de padres com diversas reas de atuao, aqui so
listados alguns tipos de padres mais conhecidos:
Padres Arquiteturais: padres que expressam a organizao estrutural
fundamental ou esquema para o software (BRAGA et al., 2001). Eles provem o
conjunto de subsistemas pr-definidos, especificam suas responsabilidades, e
incluem regras e guias para organizar os relacionamentos entre as partes.
Diversos tipos de padres arquiteturais podem ser encontrados, por exemplo, no
livro do POSA (BUSCHMANN et al., 1996);
Padres de Projeto: padres que provem solues para refinar os subsistemas
ou componentes do software ao nvel de projeto, bem como o relacionamento
entre eles. Descrevem aspectos do projeto do software, como objetos, classes,
herana, agregao entre outros. Diversos tipos de padres de projeto podem ser
encontrados no livro GoF (GAMMA et al., 1995);
Padres de Anlise: padres que descrevem solues para problemas da fase
anlise de sistemas e so padres especficos de domnio (BRAGA et al., 2001).
Alguns exemplos de padres de anlise podem ser encontrados no livro de
Fowler (FOWLER, 1997);
Padres de Programao: padres que descrevem solues de programao
particulares de determinada linguagem ou regras gerais de programao. Alguns
padres de programao podem ser encontrados no livro Core J2EE Patterns
(ALUR; CRUPI; MALKS, 2003);
Padres Organizacionais: padres voltados para solues de crescimento,
melhoria ou maturidade das organizaes, a fim de estrutur-las da melhor
forma. Padres organizacionais podem ser encontrados no livro Organizational
Patterns of Agile Software Development (COPLIEN; HARRISON, 2004);
48

Padres de Processo: padres que definem solues para os problemas nos


processos da engenharia de software: desenvolvimento, controle de
configurao, testes, etc. Alguns padres de processo podem ser encontrados no
livro Process Patterns: Building Large-Scale Systems Using Object
Technology, (AMBLER, 1998) e no artigo de Coplien (COPLIEN, 1994). Os
padres documentados nesse trabalho so padres de processos para estimativas
de software e esto descritos detalhadamente no Captulo 6;
Anti-padres: os anti-padres, ao contrrio dos padres, descrevem uma lio
aprendida a cerca de uma soluo ruim para um determinado problema
(APPLETON, 1997). Eles descrevem como escapar de uma situao ruim e
como, a partir de tal situao, proceder para alcanar uma boa soluo. Alguns
anti-padres esto documentados no livro intitulado AntiPatterns: Refactoring
Software, Architectures, and Projects in Crisis (BROWN et al., 1995).

3.2.2 Coletneas de Padres


Os padres de software, como citados anteriormente, tratam de resolver problemas de
software atravs de solues j existentes, possibilitando assim o reuso dessas solues.
Os padres quando da sua aplicao podem gerar outros problemas que necessitam de
outros padres para ser resolvidos, e assim por diante. Em geral os padres no
funcionam isoladamente: um padro pode depender da aplicao de outro padro
anterior, ou pode conter como parte da sua soluo outro padro, ou ainda pode ser uma
combinao de vrios padres (BRAGA et al., 2001). De forma geral, um padro e seus
padres relacionados descrevem solues similares, que se completam ou se encaixam
dependendo das influncias envolvidas.
Os padres podem ser agrupados em categorias que permitem claramente expor,
se existirem, os seus relacionamentos, dependncias ou combinaes. Isso pode ser feito
por meio de colees de padres, catlogos de padres, sistemas de padres ou
linguagens de padres (BRAGA et al., 2001):
Coleo de Padres: uma coletnea de padres onde os padres no possuem
nem um tipo de ligao, nem relacionamento semntico entre si, funcionam
completamente isolados e independentes. Os padres contidos em uma coleo
podem ter sido apresentados no mesmo congresso ou documentados pelo mesmo
autor. Por exemplo, uma coleo de padres pode ser encontrada nos anais da
conferncia SugarLoafPLoP 2007;
49

Catlogo de Padres: uma coletnea de padres com fraco relacionamento


entre eles ou relacionados informalmente. Em geral, agrupa os padres de forma
abrangente e pode possuir referncias cruzadas entre eles. Um catlogo de
padres atribui um pouco de estrutura e organizao a uma coleo de padres,
mas usualmente no vai alm de mostrar apenas relaes mais superficiais (se,
de fato mostrar alguma delas) (APPLETON, 1997). Como exemplo, os padres
descritos no GoF (GAMMA et al., 1995) esto agrupados no formato de
catlogo de padres;
Sistema de Padres: um conjunto coeso de padres sobre o mesmo tema. Um
sistema de padres possui padres relacionados entre si e que juntos apiam a
construo e evoluo de temas completos. Um sistema de padres descreve
todas as relaes entre os padres e como eles podem ser combinados ou
conectados a outros padres do sistema para resolver problemas mais complexos
(APPLETON, 1997). Como exemplo, os padres descritos no POSA esto
agrupados no formato de sistema de padres (BUSCHMANN et al., 1996);
Linguagem de Padres: uma coleo estruturada de padres que se apiam
uns nos outros para transformar requisitos e restries numa arquitetura
(COPLIEN; HARRISON, 2004). Uma linguagem de padres uma forma de
subdividir um problema geral e sua soluo complexa em problemas menores
relacionados e suas respectivas solues. Uma linguagem de padres possui um
contexto comum compartilhado entre todos os padres pertencentes a ela. Os
padres podem ser usados isoladamente ou com demais padres relacionados na
linguagem, porm, cada um deles resolve seu prprio problema. Como exemplo,
o artigo MetaPatterns: A Pattern Language for Pattern Writing (MESZAROS;
DOBLE, 1996) descrevem uma linguagem de padres para auxiliar na escrita de
padres.

3.2.3 Formato dos Padres


Um padro descreve uma soluo para um problema em um contexto especfico. Para
que possa ser facilmente encontrado e utilizado com facilidade, necessita ser
documentado de forma adequada.
Os padres so documentados textualmente e organizados em sees ou
componentes que definem o template ou formato do padro. No existe um consenso
dentro da comunidade de padres sobre qual a melhor forma de documentar um padro.
50

Diferentes autores adotam diferentes estilos para formalizar seus padres. Alguns
preferem ser mais textuais e menos estruturados, enquanto outros preferem o contrrio.
No existe um formato adequado para todas as ocasies, mas os formatos j existentes
podem e devem ser usados como base.
Entre os formatos de padres mais conhecidos e utilizados por pesquisadores da
rea, esto: o formato alexandriano, o formato dos padres do GoF, o formato dos
padres do POSA, o formato dos anti-padres e o formato cannico. Aqui, apenas o
formato cannico ser descrito por ser o formato escolhido para documentar os padres
detalhados, posteriormente, no Captulo 6.
Apesar de cada formato ter sido criado para atender padres de reas
especficas, diferentes formatos podem, a princpio, ser utilizados na documentao de
qualquer padro. Cabe ento, a cada autor utilizar o formato que mais se adqe ao seu
propsito, ou ainda, definir o seu prprio formato. No entanto, segundo (MESZAROS;
DOBLE, 1996), a documentao dos elementos nome, contexto, problema,
foras e soluo so obrigatrios para a documentao de um padro, mesmo que
no estejam explicitamente visveis.
O formato cannico assim chamado por ser uma forma de compor padres, ou
seja, estrutur-los em sees, onde cada seo composta por um cabealho e um texto
contendo a sua descrio. Ao contrrio do formato Alexandriano, o formato Cannico
possui sees explicitamente delimitadas.
Para documentar no formato Cannico, o autor deve estruturar o padro com as
seguintes sees:
Nome: palavra ou frase que nomeie o padro. O nome do padro deve ser
significativo no sentido de refletir de forma sucinta a sua essncia;
Problema: descreve o problema que o padro resolve diante de um certo
contexto;
Contexto: circunstncias iniciais dentro das quais o problema emerge e para as
quais a soluo desejvel. uma situao que ocorre antes da aplicao do
padro;
Foras: descrio dos aspectos relevantes para o problema e que influenciam na
escolha de uma soluo para esse problema;
Soluo: instrues de como solucionar o problema;
51

Exemplo: descreve um exemplo de aplicao do padro. Ilustra como o padro


pode ser utilizado. Caso o exemplo seja comum a todos os padres de uma
linguagem de padres, esse exemplo chamado de Running Example;
Contexto Resultante: descreve as circunstncias que ocorrem aps a aplicao
do padro, podendo ter uma subseo chamada de Conseqncias (tanto boas,
quanto ruins);
Racional: mostra porque a soluo uma boa soluo e como as Foras
foram priorizadas. Esta seo afirma realmente como o padro funciona, porque
funciona e porque ele bom;
Padres Relacionados: descreve os relacionamentos desse padro com outros
dentro da mesma linguagem ou fora dela.
Usos Conhecidos: descreve ocorrncias conhecidas do padro e sua aplicao
em sistemas existentes. Esta seo ajuda a validar o padro, verificando se ele
realmente uma soluo provada para um problema recorrente.

3.3 Consideraes Finais

Padro de software uma importante na rea da computao por ser um meio de reuso
de informaes. O muito que j foi produzido em termos de padres pouco diante de
todo conhecimento acumulado em dcadas de desenvolvimento de sistemas
computacionais. Nesse sentido, o presente captulo trouxe a importncia e o
reconhecimento dos padres na comunidade de software de todo o mundo.
O captulo seguinte detalha os trabalhos relacionados com processo de medio
em geral e em especial para MPES.
52

4 TRABALHOS RELACIONADOS

4.1 Introduo

O presente captulo descreve os trabalhos relacionados nas reas de estimativa e


medio no contexto das MPES. Para isso, foram levantados alguns trabalhos presentes
na literatura e realizados por pesquisadores da rea. Um grande nmero dos trabalhos
refere-se a relatos de experincia na rea de mensurao seguindo algumas abordagens,
como o GQM (BASILE; CALDIERA; ROMBACH, 1994) e o PSM (DOD, 2003) e
outros tantos relatam a busca contnua de melhoria do processo de medio de software
para as MPES.
Sero relacionadas, neste captulo, algumas abordagens utilizadas no contexto de
mensurao de software em geral, Seo 4.2 e em seguida sero apresentados alguns
trabalhos relacionados no contexto especfico de MPES, Seo 4.3. A Seo 4.4
descreve as consideraes finais deste captulo.

4.2 Abordagens de Processos de Estimativa e Medio: Contexto Geral

Oliveira e Koloski (2006) apresentam uma abordagem de melhoria de estimativa de


esforo que considera essencialmente a caracterizao adequada da produtividade, a fim
melhorar a preciso dessa estimativa. Segundo os autores, alguns fatores influenciam na
produtividade, como a experincia da equipe, presses de agenda, plataforma de
desenvolvimento, conhecimento do negcio, entre outros. Eles utilizam a abordagem de
melhoria contnua da qualidade do processo atravs da aprendizagem a partir de
experincias de processos na organizao, chamada de Quality Improvement Paradigm
(QIP) presente na proposta do GQM (BASILI; ROMBACH, 1994).

A idia de melhoria contnua consiste na utilizao de um dado conjunto de


caractersticas (cerca de trinta) de produtividade e na escolha dos valores mais anlogos
para um determinado projeto. Ao executar um projeto feita a comparao entre os
valores previstos, em projetos similares, e realizados. Assim, essa abordagem possibilita
a gerao de avaliaes que realimentam o conjunto de caractersticas estabelecido e
evidencia comportamentos ou influncias de fatores de impacto na produtividade. Este
conhecimento, devidamente registrado e disponibilizado, constitui num refinamento
53

evolutivo de caractersticas de produtividade, servindo para melhorar continuamente a


preciso das prximas estimativas da organizao.

Em outra abordagem, proposta em (STAA; HAZAN, 2004), os autores


apresentam um mtodo para gerao de estimativas baseado em experimentos e na
tcnica de APF (VASQUEZ, 2003). Alm disso, os autores apresentam um processo
simplificado para a gerao e documentao de estimativas de tamanho, esforo, custo,
cronograma e recursos computacionais. Os autores iniciam o trabalho apresentando o
processo de gerncia de projetos, em especial, o estabelecimento de estimativas
proposto pelo CMMI (SEI, 2006) e PMBOK (PMI, 2009), em seguida, os autores
analisam o processo de estimativa da Empresa de Informtica do Governo Federal
(SERPRO) atravs do diagrama Espinha-Peixe, ao detectar as causas e os efeitos das
falhas no processo. Uma das principais causas encontradas foi a utilizao da mtrica de
medio de tamanho Use Case Point (UCP). Entre os principais problemas encontrados
esto: falta de acurcia das estimativas, dificuldade de gerao e manuteno de dados
histricos de produtividade, dificuldade de estimar pequenos projetos, impossibilidade
de gerao das estimativas no incio do projeto.

Em seguida, os autores propem um processo de estimativa de tamanho baseado


na tcnica de estimativa Anlise de Ponto de Funo (APF), clculo da estimativa de
esforo de forma simplificada baseando-se apenas em dois parmetros (estimativa de
tamanho e produtividade), prazo, estimativa de custo e estimativas de recursos
computacionais.

Em (GARCIA; NUNES, 2006) os autores descrevem a criao de um sistema de


apoio mensurao como forma de coordenar a aplicao de mtricas em diferentes
aspectos do desenvolvimento de software e, assim, determinar o progresso do projeto e
auxiliar a tomada de deciso na gerncia do projeto. O sistema de mensurao apresenta
uma seqncia de aes coordenadas para a realizao de medies, muitas vezes
baseadas nos objetivos das organizaes e cuidadosamente planejadas, implementadas e
regularmente avaliadas para se tornar efetivo. O componente APSEE-Metrics consiste
em um mecanismo responsvel pelo gerenciamento da mensurao e dividido em
quatro componentes principais: planejamento (definio do processo, definio das
mtricas, dos procedimentos de coleta e anlise dos resultados), coleta (coleta dos
dados), anlise e controle (visualizao das informaes coletadas e o registro das
anlises realizadas) e avaliao (armazenamento das experincias obtidas com a
54

avaliao das mtricas utilizadas). Todas as mtricas utilizadas pelo programa de


mensurao foram definidas de acordo com o proposto pelo PSM.

Em (GAVA et al., 2006) os autores mostram algumas condies, requisitos, para


a implantao de um processo de medio e descrevem um estudo de caso com a
aplicao do PSM e da ISO/IEC 15939 (ISO/IEC 15939, 2007). A ISO 15939 segue
basicamente o que prope Deming (1986) no ciclo PDCA (Plan-Do-Check-Act) para
construo de um processo: estabelecer, planejar, executar e avaliar. Segundo os
autores, um planejamento de medio inicia com o reconhecimento das necessidades de
informao do projeto, definio dos dados a serem coletados, anlise e procedimentos
de comunicao e tarefas de avaliao. As necessidades de informaes do suporte
tomada de decises tanto no mbito operacional quanto no estratgico e organizacional.
Foram criados trs processos de medio de software: treinamento da equipe, para
gerncia de projetos e para testes de software. O processo de medio de treinamento
visa o planejamento de quais cursos e conhecimentos devem ser ministrados de acordo
com as habilidades de cada profissional. O processo de gerncia de projetos auxilia no
controle das atividades de cada desenvolvedor e permite a criao de um histrico para
apoiar as estimativas esforo. O processo de teste visa registrar medidas em relao aos
defeitos apresentados no desenvolvimento.

Borges e Paula (2003) propem um arcabouo genrico de medio,


fundamentado em tcnicas consagradas, como o GQM e o PSM, que pode ser
configurado e aplicado a boa parte dos processos de desenvolvimento de software.
Muitos autores defendem a idia de que cada organizao deve criar seu prprio modelo
de informao, ento o trabalho prope um modelo de medio genrico, que possa ser
adotado por processos de desenvolvimento de software de um grande nmero de
organizaes. Para alcanar os objetivos da criao do modelo de medio foi realizada
uma srie de atividades: seleo das medidas a serem coletadas, formalizao das
medidas e procedimentos de coleta, criao do modelo conceitual e aplicao de uma
instanciao do arcabouo para um processo concreto. Na atividade de seleo de
medidas foi definido um conjunto de metas que so comuns maioria das organizaes
(produzir software de qualidade, obter boa produtividade, cumprir os compromissos de
prazo e custo assumidos). Algumas medidas foram derivadas: esforo empregado na
correo de defeito, classificao do defeito, data em que foi detectado e data em que
foi corrigido. A atividade formalizao das medidas tem por objetivo garantir a
55

comunicao (outras pessoas devem ser capazes de saber o que foi medido) e
repetibilidade (outras pessoas devem ser capazes de realizar as mesmas medies e
obter os mesmo resultados). As medidas foram agrupadas em um modelo conceitual que
apresenta as entidades envolvidas e os relacionamentos existentes entre elas. A ltima
atividade a incorporao do modelo de medio ao processo Praxis (PADUA, 2009).

4.3 Abordagens de Processos de Medio: Contexto MPES

Anacleto e Wangenheim (2002) descrevem o desenvolvimento de um programa de


mensurao de apoio gerncia de projetos baseado na abordagem GQM. Os autores
mostram as dificuldades encontradas na tentativa de aplicar um mtodo de mensurao
em micro empresas. O processo composto por algumas atividades de acordo com o
previsto pelo GQM. O primeiro passo a definio e formalizao da meta (objetivo)
de mensurao e os fatores que guiam a mensurao (durao total, durao por
mdulo, esforo total do projeto, esforo por mdulo, esforo por tarefa, custo total e
custo por mdulo, por exemplo). A segunda etapa o desenvolvimento do plano GQM,
onde, a partir dos fatores, so criadas perguntas (questes), hipteses, grficos e
concluses que permitem fazer um planejamento de como os dados so analisados. A
terceira etapa o desenvolvimento do plano de coleta de dados, onde para cada medida
criado um procedimento de mensurao, declarando quando, como e por quem o dado
deve ser coletado. Na etapa de coleta, validao e armazenamento dos dados, cada
membro envolvido no projeto preenche seu formulrio para coleta de dados individuais.
Mensalmente estes instrumentos so agrupados e feita a validao dos dados. Para a
atividade seguinte, anlise dos dados coletados, os dados so analisados no intuito de
responder as perguntas formuladas. So construdos grficos de apoio para interpretao
dos dados. Para a interpretao dos dados, ltima etapa, mensalmente organizada uma
sesso de feedback com os membros da equipe. Nesta etapa realizada a reviso do
programa de mensurao e a captura de experincias para serem utilizados em projetos
futuros.

Em (WANGENHEIM; PUNTER; ANACLETO, 2003), os autores descrevem


um modelo de processo de medio de produtos e processos, orientado a objetivos
(baseado no GQM), para pequenas e mdias empresas. Os autores adaptam o GQM para
56

pequenas e mdias empresas e constroem um novo modelo chamando de GQM


Lightweight Process. O processo GQM Lightweight dividido em cinco fases.

Fase de Planejamento: responsvel por introduzir o programa de medio na


empresa atravs da escolha de um projeto piloto onde todas as pessoas
envolvidas no programa so treinadas e motivadas;
Fase de Definio: auxilia na definio do programa de medio, o que inclui a
definio dos objetivos do GQM, o desenvolvimento do plano de medio, as
questes derivadas dos objetivos, as mtricas, o procedimento de coleta dos
dados (quando, como e por quem os dados so coletados) e as ferramentas de
apoio. Nesta fase os autores sugerem o reuso de algumas informaes para todos
os projetos como forma de reduzir o esforo e facilitar a definio do programa.
Os autores sugerem, por exemplo, o reuso de alguns objetivos do programa de
medio para todos os projetos da organizao ou ainda entre organizaes
diferentes que possuem um contexto similiar;
Fase de Coleta de Dados: os dados so coletados, validados e armazenados de
acordo com o que foi definido no plano de medio. Devido ao alto grau de
informalidade dos processos de empresa desse porte, a maioria dos dados
coletada de forma manual atravs do uso de planilhas;
Fase de Interpretao: os dados coletados so analisados periodicamente. Esta
fase prev a execuo de sesses de feedback envolvendo todas as pessoas do
projeto para que ocorra interpretao dos dados de forma vlida e mantenha a
motivao da medio. Os autores sugerem que o intervalo entre as reunies de
feedback sejam guiadas pelos objetivos da medio (quando uma determinada
informao tem que estar disponvel) e pela disponibilidade dos dados
necessrios para responder as questes envolvidas;
Fase de Empacotamento: ao trmino do programa de medio no projeto, o
resultado das medidas, incluindo os dados coletados e suas interpretaes,
analisado, empacotado e armazenado de forma que este conhecimento possa ser
reusado em programas futuros.
Os autores aplicaram o GQM Lightweight Process em cinco pequenas
organizaes e relataram alguns problemas, entre eles: ausncia de um processo de
desenvolvimento estruturado nas pequenas e mdias empresas, pessoas que exercem
mltiplas funes, necessidade de consultores para guiar e implementar o programa de
57

medio (sem os consultores, os autores acharam que no seria possvel a introduo do


programa de medio), complicaes decorrente da tentativa de automatizar a coleta de
dados e grande mudana no domnio das aplicaes.
Os autores tambm relataram que o custo e o esforo de aplicao de um
programa de medio foram reduzidos significantemente devido ao reuso de algumas
informaes entre as organizaes. O GQM Lightweight Process se preocupa tanto com
mtricas de qualidade quanto mtricas de apoio gerencial.

No trabalho de (CARDOSO et al., 2005), os autores propem um processo


simplificado para medio e anlise de desenvolvimento de software com foco no
CMMI e PSM para pequenos grupos. O principal objetivo do processo fornecer
informaes concisas e claras sobre os projetos de desenvolvimento possibilitando aos
gerentes tomar as decises com base em dados e fatos reais e mitigar eventuais riscos. O
processo possui basicamente quatro atividades: planejar medio e anlise, coletar
dados, analisar medidas e comunicar resultados, Figura 4.1. Na atividade de
planejamento, os responsveis identificam as medidas a serem coletas, data em que
ocorrero as coletas dos dados e a divulgao do Relatrio de Medio e Anlise para a
gerncia. Na fase de coleta das medidas o Grupo de Garantia da Qualidade (GGQ) deve
coletar as medidas e preencher o relatrio. O GGQ responsvel pela anlise das
medidas coletadas e a avaliao de possveis riscos que possam prejudicar o sucesso do
projeto. Ao final do projeto o GGQ deve comunicar os resultados a todos os
participantes do projeto, devendo tambm anex-lo base de dados de projetos
anteriores. O processo utiliza as seguintes medidas: esforo real, esforo estimado, custo
estimado, custo real, tamanho estimado, tamanho real, por exemplo.

O processo de medio e anlise foi construdo em cima do processo de


desenvolvimento, chamado MPG (Modelo para Pequenos Grupos), de uma determinada
empresa. Portanto, no se preocupa com uma atividade de avaliao do processo de
medio e especfico para esta empresa e para o processo de desenvolvimento
utilizado, MPG.
58

Figura 4.1 Diagrama de Atividades do MPG (CARDOSO et al., 2005)

Em (LEY; GARCIA; PIATTINI, 2008) os autores definem um framework de


programa de medio adaptado para pequenas e mdias empresas chamado de MIS-
PyME. O framework composto de dois mdulos principais: MIS-PyME - Metodologia
(tabela de medidas guiadas a objetivo, template de indicadores e banco de dados), MIS-
PyME Modelo de Maturidade de Medio, Figura 4.2.
A metodologia do MIS-PyME foi construda a partir do GQM e GQ(I)M para
adaptar-se s pequenas e mdias empresas.
A metodologia descrita conforme os seguintes passos e so executadas
basicamente pelo gerente de projeto ou analista de medio:
Identificar os objetivos da melhoria de processo: definir os objetivos de
melhoria de processo e identificar quais as entidades que ajudaro a alcanar
estes objetivos definidos;
59

Figura 4.2 MIS-PyME Framework (LEY; GARCIA; PIATTINI, 2008)

Formalizar os objetivos da medio e checar se o modelo de medio pode


ser reusado: descrever os objetivos da medio na tabela de medidas objetivo e
verificar se os objetivos definidos no foram levantados e trabalhados em
projetos anteriores, no caso afirmativo, apenas reutilizar as medidas definidas e
indicadores;
Especificar um plano de projeto: um pequeno plano de projeto deve ser
definido. Ele deve apenas conter: uma descrio dos objetivos do programa de
medio, os benefcios, as pessoas envolvidas com seus respectivos papis e o
cronograma do projeto;
Definir os indicadores: definio dos indicadores requeridos para implementar
os objetivos da medio;
Definir as medidas e identificar as aes e necessidades a serem
implementadas: as medidas a serem coletadas so identificadas em detalhes,
definidas em checklists e como elas sero coletadas. feito uma anlise da
habilidade da organizao em analisar as medidas e a forma como as medidas
podem ser coletadas;
Integrar o programa de medio: integrar as atividades de medio em
processos de medio anteriores e em outros processos de desenvolvimento de
software, como de qualidade;
60

Verificar o programa de medio: o processo de medio revisado e


modificado se necessrio;
Estabelecer recursos: desenvolvimento, adaptao ou aquisio de ferramentas
de suporte ao processo de medio;
Aceitar o programa de medio: primeiramente realizada uma anlise
experimental com o programa de medio dentro da empresa e posteriormente o
programa aceito para ser efetivado. Aps a efetivao realizado uma breve
sesso de treinamento para as pessoas envolvidas para mostr-las como usar as
ferramentas de coleta de dados, os objetivos dos dados e o processo de medio.
O Modelo de Maturidade MIS-PyME, Figura 4.3, foi projetado para guiar os
usurios na definio do programa de medio que mais se adqua maturidade da
empresa. O modelo de medio define um conjunto de quatro temas (gerenciamento de
projetos, capacidade de desenvolvimento e qualidade, escopo da medio, ferramentas
de suporte e gerenciamento de problemas) e cinco nveis de maturidade.

Figura 4.3 Nveis de Capacidade do Modelo de Maturidade de Medio, MIS-PyME (LEY;


GARCIA; PIATTINI, 2008)

4.4 Consideraes Finais

Este captulo apresentou um conjunto bibliogrfico de algumas das principais


contribuies encontradas na literatura sobre o tema abordado neste trabalho. Diante dos
trabalhos apresentados tem-se um importante entendimento na definio de processos
de medio em geral e em especfico para MPES.
61

O Captulo 5 define um conjunto de requisitos para construo de um processo


de medio voltado para atender as MPES e mostra como os trabalhos relacionados
atendem ou no os requisitos definidos.
62

5 REQUISITOS PARA DEFINIO E IMPLANTAO DE


PROCESSO DE MEDIO PARA MPES

5.1 Introduo

Esse captulo tem por objetivo o levantamento de um conjunto de requisitos para


definio e implantao de processo de medio para MPES.
Durante o estudo realizado e apresentado no captulo anterior pode-se perceber
uma grande quantidade de abordagens e recomendaes de melhoria de processo para
MPES em todas as reas de apoio ao desenvolvimento de software, inclusive na rea de
medio. Muitas das abordagens, independente do contexto, so bastante relevantes no
que diz respeito explorao das boas prticas para a implantao de processos nas
MPES.
Diante das dificuldades enfrentadas pelas MPES, relacionadas no captulo de
introduo e no levantamento bibliogrfico realizado, observou-se a ausncia de um
conjunto de requisitos voltados para a definio e implantao de um processo de
medio para MPES. Assim, optou-se pelo levantamento de um conjunto de requisitos
para definio de um processo de medio para MPES, de modo que o mesmo possa ser
utilizado como base na construo deste trabalho e em pesquisas futuras, procurando
agrupar algumas das contribuies presentes na literatura de forma unificada e
categorizada.
Esse conjunto de requisitos permitir delimitar o escopo de um processo de
medio para atender s demandas das MPES de forma que maximize a produtividade e
minimize os custos. Tal conjunto foi dividido em duas categorias. A primeira se refere
aos requisitos relacionados definio de um processo de medio nas MPES e a
segunda se refere aos requisitos relacionados implantao do processo nas MPES. A
segunda categoria se refere implantao de qualquer tipo de processo nas MPES,
independente de ser um processo de medio ou no. Com isso, contribumos tambm
para os pesquisadores interessados em implantar um processo ou modelo de apoio
voltado para atender esse nicho de mercado.
Esse captulo est organizado da seguinte forma: a Seo 5.2 relaciona o
requisitos para definio de processo de medio, a Seo 5.3 relaciona os requisitos
para implantao de um processo geral nas MPES, a Seo 5.4 descreve como os
63

trabalhos relacionados no Captulo 4 atendem aos requisitos aqui definidos e a ltima


Seo, 5.5, com as consideraes finais do captulo.

5.2 Requisitos para definio de processo de medio para MPES

Atravs de um processo de medio possvel analisar quantitativamente o andamento


do projeto, dos produtos e, dependendo do grau de maturidade da organizao, at
mesmo dos processos. A informalidade ou ausncia de processos nas MPES tornam a
definio de um processo de medio ainda mais importante para apoiar o gerente no
acompanhamento e controle dos projetos. Devido a esta relevncia, entende-se como
necessrio que metodologias reconhecidas e trabalhos consistentes presentes na
literatura nos orientem na definio de um processo de medio para MPES e no
levantamento de um conjunto bsico de requisitos para tal finalidade.
Garcia e Nunes (2006) elencam um conjunto de requisitos relevantes para
criao de metodologias e ferramentas de medio. Alguns dos requisitos relacionados a
seguir foram extrados desse trabalho e comparados com os demais requisitos presentes
em trabalhos especficos para o contexto de MPES e a partir de ento foram agrupados
em um conjunto bsico de requisitos para definio do processo de medio para
MPES.
A seguir so apresentados os requisitos:
RDef.1 Compromisso organizacional: para a definio de qualquer processo
dentro de uma organizao necessrio o comprometimento da alta gerncia e
de todos os envolvidos diretos. A definio de um processo de medio merece
maiores cuidados em se tratando de MPES. O processo de medio pode ser
visto como um programa que ir medir desempenhos individuais e assim, inibir
ou coagir o empenho dos participantes na execuo do processo. Isso pode ser
agravado em se tratando de MPES por, geralmente, no possurem uma cultura
de verificao da qualidade dos produtos. Todos os envolvidos no processo,
inclusive a alta gerncia, tem de estar cientes dos reais benefcios provenientes
da medio e utiliz-los para avaliar e melhorar o desempenho da organizao
(BASILI; ROMBACH, 1994) (ANACLETO; WANGENHEIM, 2002) (DOD,
2003) (GAVA et al., 2006);
RDef.2 Planejamento das medies: planejar as medies fundamental
para o sucesso do processo de medio. necessrio entender o motivo da
64

medio, ou seja, qual o objetivo (necessidade de informao) da medio para a


organizao e definir as medidas apropriadas para satisfaz-lo. Os
procedimentos de coleta, anlise e armazenamento dos dados para cada mtrica
a ser coletada deve fazer parte do planejamento das medies (plano de
medio). No contexto das MPES o planejamento das medies deve ser o mais
simples possvel uma vez que no existe uma equipe de medio dedicada para
tal finalidade. Geralmente uma pessoa da prpria equipe do projeto alocada
parcialmente para exercer a funo de planejamento (BASILI; ROMBACH,
1994) (FRANCA; STAAZ; LUCENA, 1998) (ANACLETO; WANGENHEIM,
2002) (WANGENHEIM; PUNTER; ANACLETO, 2003) (BORGES; PAULA,
2003) (DOD, 2003) (SCHNAIDER et al., 2004) (CARDOSO et al., 2005)
(GAVA et al., 2006) (GARCIA; NUNES, 2006) (LEY; GARCIA; PIATTINI,
2008) (SOFTEX, 2009c);
RDef.3 Reuso e adaptao dos planos de medio: a ausncia de recursos
das MPES deve estimular o reuso, em especial, dos planos de medio. O plano
de medio contm todas as informaes das medidas, como sero coletadas e
analisadas, por quem e em qual momento do processo. A reutilizao de planos
de medio anteriormente utilizados, realizando as devidas adaptaes quando
necessrio pode reduzir significativamente o custo de planejamento das
medies e de elaborao do plano de medio (BASILI; ROMBACH, 1994)
(WANGENHEIM; PUNTER; ANACLETO, 2003) (BORGES; PAULA, 2003)
(LEY; GARCIA; PIATTINI, 2008);
RDef.4 Coleta e armazenamento dos dados: as medies devem ser
guardadas em local apropriado para anlise e formao de base de dados
histricas. O armazenamento pode ser feito atravs de ferramentas especficas
que automatizam o processo, planilhas ou sistemas de gerenciamento de banco
de dados. Todas as ferramentas de armazenamento possuem as suas vantagens,
mas no caso especfico de MPES preciso avaliar se o esforo necessrio para
implantao de ferramentas automticas e treinamento de pessoal possui
vantagem em detrimento ao uso de ferramentas mais simples, como planilhas e
documentos. Dependendo dos objetivos da medio, a coleta dos dados pode ser
feita rapidamente sem a necessidade de ferramentas automticas (BASILI;
ROMBACH, 1994) (FRANCA; STAAZ; LUCENA, 1998) (ANACLETO;
WANGENHEIM, 2002) (WANGENHEIM; PUNTER; ANACLETO, 2003)
65

(DOD, 2003) (SCHNAIDER et al., 2004) (CARDOSO et al., 2005) (GAVA et


al., 2006) (GARCIA; NUNES, 2006) (LEY; GARCIA; PIATTINI, 2008)
(SOFTEX, 2009c);
RDef.5 Anlise dos dados coletados: nesta fase que os dados so
interpretados de acordo com os objetivos definidos no planejamento da medio.
Desta tarefa se obtm o embasamento para as tomadas de decises durante o
projeto (BASILI; ROMBACH, 1994) (FRANCA; STAAZ; LUCENA, 1998)
(ANACLETO; WANGENHEIM, 2002) (WANGENHEIM; PUNTER;
ANACLETO, 2003) (DOD, 2003) (SCHNAIDER et al., 2004) (CARDOSO et
al., 2005) (GAVA et al., 2006) (GARCIA; NUNES, 2006) (LEY; GARCIA;
PIATTINI, 2008) (SOFTEX, 2009c);
RDef.6 Comunicao dos resultados da medio: o processo de medio
deve prover mecanismos de divulgao das medies sempre que necessrio e
com apresentao dos dados de forma grfica e de fcil compreenso. No
contexto das MPES essencial a realizao de sesses de feedback para
consolidao das interpretaes expostas pela equipe e motivao no programa
de medio (WANGENHEIM; PUNTER; ANACLETO, 2003) (DOD, 2003)
(SCHNAIDER et al., 2004) (CARDOSO et al., 2005) (GARCIA; NUNES,
2006) (LEY; GARCIA; PIATTINI, 2008) (SOFTEX, 2009c);
RDef.7 Avaliao do programa de medio: consiste na avaliao crtica do
processo de medio como um todo, o que inclui as medidas utilizadas, os
resultados das anlises dos dados, a consistncia do processo, a verificao se
os objetivos foram atingidos, as falhas no processo e as lies aprendidas
(WANGENHEIM; PUNTER; ANACLETO, 2003) (DOD, 2003) (GAVA et al.,
2006) (GARCIA; NUNES, 2006).

5.3 Requisitos para implantao de processo para MPES

A implantao de um processo dentro de uma MPES merece maior ateno. A


imaturidade da empresa aliada, principalmente, falta de recursos pessoais e
financeiros, contribui para a atual situao enfrentada por tais empresas. Em virtude
destas dificuldades, entende-se como necessrio que experincias de sucesso e fracasso
enfrentadas por inmeras MPES nos orientem na definio de processos que minimizem
as falhas e maximizem as situaes de sucesso. Neste sentido, um conjunto bsico de
66

requisitos relativos implantao de processos em MPES foi identificado e visa


contemplar a implantao de qualquer processo no contexto de MPES.
A seguir so apresentados os requisitos (JOHNSON; BRODMAN, 1997)
(ALLEN; RAMACHANDRAN; ABUSHAMAM, 2003) (ANACLETO;
WANGENHEIM, 2005) (HAUCK; WANGENHEIM; THIRY, 2007) (ANDRADE;
FREITAS; SOUZA, 2008):
RImpl.1 - Custo compatvel: a implantao do processo de medio e os
treinamentos necessrios, se possvel, no devem despender custos financeiros
para a empresa. No caso de haver custos os mesmos devem ser compatveis com
o porte da empresa;
RImpl.2 - Rpida implantao e entendimento: reduo do esforo necessrio
para implantao. O processo de medio tem que ser simples e auto-
explicativo. essencial a gerao de resultados rpidos de forma incremental,
possibilitando a melhoria contnua dos processos. Deve ser fcil de
compreender, com itens importantes em destaque e uso de linguagem de fcil
leitura. O processo deve ser descrito de forma clara e indicar os papis de cada
um e suas atividades e indicar quando possvel ou no que um papel exera
mais de uma atividade (WANGENHEIM; PUNTER; ANACLETO, 2003)
(LEY; GARCIA; PIATTINI, 2008);
RImpl.3 - Alto grau de flexibilidade: o processo deve possibilitar a aplicao
de prticas de acordo com o perfil de cada empresa, no obrigar, portanto, a
implantao de sua totalidade e permitir cenrios alternativos, manutenes e
melhorias;
RImpl.4 - Quantidade de documentao compatvel: a quantidade de
documentos a ser preenchida durante o processo de desenvolvimento do
software deve ser compatvel com a quantidade limitada de recursos humanos
presente em tais empresas. Devem ser simplificados para tornar as tarefas
produtivas (LEY; GARCIA; PIATTINI, 2008);
RImpl.5 - Voltado para os objetivos de negcio: observar e preservar algumas
caractersticas marcantes da empresa, principalmente os objetivos de negcio.
Com isso, o processo pode oferecer baixo risco estratgico para a organizao
(WANGENHEIM; PUNTER; ANACLETO, 2003) (CARDOSO et al., 2005)
(LEY; GARCIA; PIATTINI, 2008);
67

RImpl.6 - Prticas reconhecidas internacionalmente: o processo deve ser


compatvel com as boas prticas dos modelos existentes e bem conceituados
(WANGENHEIM; PUNTER; ANACLETO, 2003) (CARDOSO et al., 2005)
(LEY; GARCIA; PIATTINI, 2008).

5.4 Como os trabalhos relacionados atendem aos requisitos

Diante dos requisitos descritos para processo de medio para MPES e os requisitos
gerais para implantao de processos importante realizar uma verificao junto
literatura sobre quais processos de medio existentes atendem ao conjunto de
requisitos levantados. Para realizar tal verificao foi considerado o conjunto de
trabalhos relacionados, contexto MPES, descritos no Captulo 4.
A Tabela 5.1 descreve o atendimento dos trabalhos relacionados, contexto MPES,
aos requisitos. Para realizao da avaliao dos trabalhos relacionados em relao aos
requisitos foi considerado as informaes contidas exclusivamente nos trabalhos
referenciados. Para avali-los foi utilizada a seguinte classificao: atende, no
atende e indefinido. A classificao atende foi extrada da avaliao de acordo
com a presena explcita do requisito no trabalho relacionado, a classificao no
atende foi avaliada em virtude da ausncia do requisito no trabalho e, atravs da
classificao indefinido no foi possvel afirmar que o trabalhado relacionado atende
ou no ao requisito em virtude da ausncia de maiores informaes.

Tabela 5.1 Anlise dos Trabalhos Relacionados frente aos Requisitos


Trabalhos Anacleto et al., Wangenheim et Cardoso et Ley et al., 2008
Requisitos 2002 al., 2003 al., 2005
RDef.1: Compromisso Organizacional
RDef.2 : Planejamento das Medies
RDef.3: Reuso das Medies
RDef.4: Coleta e Armazenamento
RDef.5: Anlise dos Dados
RDef.6: Comunicao dos Resultados
RDef.7: Avaliao do Programa
RImpl.1: Custo Compatvel ? ? ? ?
RImpl.2: Rpido Entendimento e ?
Implantao
RImpl.3: Alto grau de flexibilidade ? ? ?
68

Trabalhos Anacleto et al., Wangenheim et Cardoso et Ley et al., 2008


Requisitos 2002 al., 2003 al., 2005
RImpl.4: Quantidade de ? ? ?
Documentao Compatvel
RImpl.5: Objetivos de Negcio
RImpl.6: Prticas Reconhecidas
Legenda: Atende No Atende ? Indefinido

Ao analisar criteriosamente os trabalhos, em alguns deles no foi possvel deduzir


o atendimento ou no aos requisitos, isso se deve principalmente ao fato dos trabalhos
serem publicados de forma resumida. Mesmo assim, como para alguns trabalhos no
houve o completo atendimento dos requisitos, pode-se inferir que nenhum dos trabalhos
relacionados atende a todos os requisitos levantados.

5.5 Consideraes Finais

Neste captulo foi apresentado um conjunto bsico de requisitos, fundamentados na


reviso bibliogrfica, que apiam a definio e implantao de processo de medio nas
MPES. Com esse conjunto de requisitos pretende-se construir um processo de medio
voltado para atender tais empresas.

Uma anlise importante que diante de tantos trabalhos na rea de medio de


software e do grande valor para a literatura de cada um deles, ainda h uma carncia na
definio de processos de medio simplificados, fceis de serem aplicados para MPES
e genricos o suficiente para serem adaptados por qualquer organizao deste porte.

No Captulo 6 apresentada uma linguagem de padres de estimativa para


MPES cujo objetivo a documentao de um conjunto de boas prticas de estimativas
para o contexto especfico das MPES.
69

6 LINGUAGEM DE PADRES PARA ESTIMATIVA DE SOFTWARE

6.1 Introduo

O gerente de projeto confronta-se com um dilema logo no incio do projeto: produzir


estimativas quantitativas, como mensurar custo, tempo e esforo de desenvolvimento do
projeto mais prximos realidade e assim, minimizar possveis prejuzos financeiros.
Para isso, ele deve conhecer a capacidade de sua equipe e os recursos com os quais pode
contar para executar as atividades. Dessa forma, adequando-se ao custo disponvel e
qualidade desejada, o gerente poder estabelecer prioridades para a realizao dessas
atividades.

O objetivo da linguagem de padres para estimativa de software (ANDRADE;


SOUZA, 2008) auxiliar o gerente de projeto a estimar o software na fase de
planejamento do projeto. Como se pode observar na Linguagem de Padres ilustrada na
Figura 6.1, todos os padres da linguagem apoiam fase de planejamento do projeto
desde a elaborao de estimativas at a sua aprovao pelo cliente, consolidao dos
dados reais e posterior apoio de tais dados nas tomadas de decises da empresa. Para
diferenci-los das demais sees, vamos sempre referenciar os padres em negrito,
itlico e sublinhado. Na Figura 6.1 pode-se encontrar um resumo de todos os padres da
linguagem, com problema e soluo descritos de forma geral.

Vale lembrar que a linguagem aqui apresentada no possui o intuito de estimar o


software com a menor margem de erro possvel, maior preciso, sendo isto deixado para
as diversas tcnicas de estimativa de software existentes e que primam para minimizar
esta margem. A formulao dessa linguagem est voltada para oferecer aos gerentes de
projetos das MPES um guia padro, simples e preciso o suficiente para o processo de
obteno e calibragem das estimativas de software, como forma de atender realidade
das empresas e auxili-los juntamente com o cliente nas tomadas de decises.
O formato dos padres apresentados na linguagem, bem como a descrio geral
do problema e soluo abordados por cada um deles esto descritos abaixo:
Nome: nome do padro;
Contexto: situao em que o padro deve ser aplicado;
Problema: problema que o padro resolve;
Foras: aspectos que influenciam na escolha da soluo do padro;
70

Soluo: apresenta a soluo para o problema, no contexto definido;


Variantes2: variaes da soluo para o problema, no contexto definido;
Exemplo3: exemplo da aplicao do padro;
Contexto Resultante: cenrio posterior aplicao do padro;
Racional: mostra porque a soluo resolve o problema, e como as foras
foram priorizadas;
Usos Conhecidos: descreve situaes existentes onde o padro
utilizado;
Padres Relacionados: identificam e relacionam outros padres que so
importantes para o padro descrito.

1. Estimativa do 10. Obteno


Tamanho Total de Dados
Histricos

2. Estimativa do
Esforo Total
3. Obteno da Jornada de
Trabalho 6. Obteno da Hora

4. Obteno dos Recursos 5. Estimativa do 7. Estimativa do Custo


Humanos Disponveis Prazo Total Total

8. Aprovao das
Estimativas

Legenda:

Padres 9. Coleta das Medidas


Sada/Entrada Reais

Figura 6.1 - Linguagem de Padres para Estimativa de Software

2
Em alguns padres, por no existir variaes da soluo, esta seo no foi apresentada.
3
Em alguns padres, por no se encaixar no Running Example, esta seo no foi referenciada.
71

Tabela 6.1 Resumo dos Padres


Nome do
Problema Soluo
Padro
Estimativa do Como estimar o Divida o sistema de acordo com suas funcionalidades; Para cada
Tamanho tamanho do projeto? funcionalidade classifique-a de acordo com sua complexidade:
Total baixa, mdia ou alta; D pesos e calcule o tamanho total do
projeto; Obtenha uma medida de tamanho, chamada de ETT.

Estimativa do Como estimar o Obtenha a Produtividade da Equipe (PROD); Obtenha a


Esforo Total esforo necessrio Estimativa do Tamanho Total, o tamanho do software (ETT);
para execuo do Estime o esforo total com a frmula:
projeto? ESF = PROD ETT .
Obteno da Como obter o valor da Verifique junto ao departamento de recursos humanos a jornada
Jornada de jornada de trabalho? de trabalho, em horas, dos profissionais.
Trabalho
Obteno de Como obter a Faa um levantamento de todos os profissionais da empresa
Recursos quantidade de recursos para saber a alocao de cada um. Verifique a quantidade de
Humanos disponveis? recursos disponveis e contabilize-os.
Disponveis
Estimativa do Como estimar o prazo Obtenha os valores: Estimativa do Esforo Total (ESF);
Prazo Total total de durao do Obteno do Valor da Jornada de Trabalho (VlrJTRAB) e
projeto? Obteno de Recursos Disponveis (QtdRD). Estime o prazo
total com a frmula:
ESF
EPRZ =
(QtdRD VlrJTRAB )
Obteno da Como obter o valor da Salrio
Hora hora de trabalho? VlrHORA( Papel) =
VlrJTRAB 30
Estime com a frmula, onde Salrio o salrio em reais por
papel e VlrJTRAB o valor da jornada de trabalho obtido a
partir de Obteno do Valor da Jornada de Trabalho.
Estimativa do Como estimar o valor CUSTO = ESF P( Papel) VlrHORA( Papel)
Custo Total do custo total do
projeto? Estime com a frmula, onde ESF a Estimativa do Esforo
Total, P a porcentagem de esforo necessrio para cada papel
e VlrHORA calculado a partir da Obteno do Valor da Hora.
Aprovao Como aprovar as Marque reunio com o cliente. Apresente os valores de custo e
das estimativas realizadas? prazo do software. Apresente ao cliente como os valores foram
Estimativas calculados.
Coleta das Como coletar as Defina o qu ser medido. Construa documentos a serem
Medidas Reais medidas reais no preenchidos pelos membros do projeto. Defina marcos para
decorrer do andamento realizao de tais coletas. Armazene-as.
do projeto?
Obteno de Como obter dados de Realize consultas na base de dados para obteno de dados
Dados medies anteriores? histricos.
Histricos

Esse captulo est organizado da seguinte forma: a Seo 6.2 descreve uma
aplicao exemplo para demonstrar a aplicabilidade e o passo a passo da linguagem de
72

padres, a Seo 6.3 detalha os padres documentados nesse captulo e a Seo 6.4
descreve as consideraes finais.

6.2 Running Example

Considere uma pequena empresa hipottica de software, aqui nomeada de XYZ,


com cerca de 15 profissionais entre gerentes, analistas, projetistas e desenvolvedores. A
empresa XYZ tem como cliente a Universidade Estadual do Cear que necessita de um
Sistema de Matrcula de Estudantes simplificado.
De forma geral, o Sistema possui as seguintes funcionalidades:
Cadastro de Professores e Estudantes;
Matrcula dos Estudantes nos cursos ofertados e nas disciplinas.
O professor pode logar no sistema, escolher os cursos que quer ministrar e
submeter as notas dos estudantes no decorrer da disciplina. O estudante pode logar no
sistema atravs de usurio e senha, realizar matrcula nos cursos disponveis e visualizar
o relatrio com as suas notas, boletim. O Administrador pode logar no sistema, alm de
manter o cadastro dos professores e dos estudantes. O Sistema de Matrcula se integra
com o sistema de graduao da universidade (catlogo de cursos) que mantm o
catlogo atualizado dos cursos e disciplinas disponveis no semestre.
A Figura 6.2 ilustra o diagrama de casos de usos do Sistema de Matrcula de
Estudantes, com as responsabilidades de cada um no sistema.

Figura 6.2 Casos de Uso do Sistema de Matrcula de Estudantes


73

6.3 Os Padres

1. Estimativa do Tamanho Total

Contexto:
As MPES de desenvolvimento de software, representada pelos seus gerentes de
projeto, tm dificuldade em estimar o tamanho dos projetos na fase de planejamento,
com escopo geral definido, devido ao custo exigido pelo grande nmero de tcnicas
existentes.

Problema:
Como elaborar estimativas do tamanho total do projeto de forma significativa,
simples e a um custo satisfatrio?

Foras:
1) O gerente de projeto, baseado em experincias anteriores prprias, pode
simplesmente, estimar o tamanho do software sem realizar nenhum clculo,
porm tal estimativa pode acarretar um valor totalmente fora da realidade do
projeto, podendo causar prejuzo financeiro empresa;
2) O gerente de projeto pode optar por estimar o tamanho do software de
acordo com a quantidade de linhas de cdigo por funcionalidade, porm tal
tcnica depende da linguagem de programao utilizada, tornando-a instvel;
3) Estimativas de alto nvel em fases iniciais do projeto podem ser imprecisas,
porm estimativas detalhadas demais podem despender tempo e custo s
MPES;
4) Estimativas baseadas na anlise do projeto quanto s suas funcionalidades e
quantificao delas em relao complexidade podem ser simples e a um
custo satisfatrio s MPES;
5) Dados histricos de estimativas podem ajudar na preciso, uma vez que
auxiliam na contabilizao das funcionalidades;
6) Especialistas externos e o uso de componentes prontos do mercado facilitam
a elaborao de estimativas de forma rpida e precisa, porm as MPES no
possuem recursos financeiros para investir em tal soluo.
74

Soluo:
Para estimar o tamanho do projeto necessrio contabilizar as
funcionalidades. A contabilizao realizada atravs do clculo do nmero de
transaes por caso de uso.

Passo 1. Determinao dos Fatores No-Ajustveis (FNA).

Os Fatores No-Ajustveis apresentam as funcionalidades ou requisitos


funcionais exigidos pelo cliente para execuo do projeto. Logo, para obter tais
fatores:

a. Separe o projeto por funcionalidades4 e determine a quantidade de


transaes de acordo com os seguintes grupos:
i. Transaes de entrada de dados por parte do usurio com
persistncia na base de dados (TED);
ii. Transaes de sada de dados da base para fornecer
informaes ao usurio (TSD);
iii. Transaes de consulta, onde o usurio entra com os dados, e
solicita uma resposta da base de dados (TCD);
iv. Transaes externas, mantidas por outra aplicao (TEX);
v. Transaes de persistncia de dados (TPD). Para cada TEX
contabilizado uma TPD;
b. Para cada um dos grupos acima, classifique-o de acordo com sua
complexidade (vide d), atribuindo complexidade baixa, mdia ou
alta.
c. Atribua peso menor s que possuem complexidade baixa, peso
intermedirio s que possuem complexidade mdia e maior peso s
que possuem alta, de acordo com d, Tabela 6.2.
d. Verifique os dados histricos em Obteno de Dados Histricos para
auxiliar na classificao das transaes;

4
No caso de projeto com Notao UML, deve-se construir o diagrama de caso de uso, e a partir dele,
identificar as transaes;
75

Tabela 6.2 Classificao das Transaes


Grupos de Complexidade Quantidade Peso
Transaes
TED Baixa Q1 P1
Mdia Q2 P2
Alta Q3 P3
TSD Baixa Q4 P4
Mdia Q5 P5
Alta Q6 P6
TCD Baixa Q7 P7
Mdia Q8 P8
Alta Q9 P9
TEX Baixa Q10 P10
Mdia Q11 P11
Alta Q12 P12
TPD Baixa Q13 P13
Mdia Q14 P14
Alta Q15 P15

e. Calcule os Fatores No-Ajustveis (FNA) de acordo com a frmula a


seguir:

15
FNA = Qi Pi
i =1

Passo 2. Clculo dos Fatores Tcnicos No-Funcionais (FTNF).

Os Fatores Tcnicos No-Funcionais so as funcionalidades ou requisitos no


funcionais do sistema. Logo, para obter tais fatores:

a. Classifique o projeto quanto s caractersticas abaixo, de acordo com


a Tabela 6.3. Cada caracterstica deve ser avaliada com notas: 0 no
atende, 3 atende parcialmente, 5 atende completamente
(MONTEIRO, 2005) (IFPUG, 1999), conforme Tabela 6.3.
76

Tabela 6.3 Caractersticas No-Funcionais


Caracterstica Nota
Processamento Distribudo N1
Desempenho N2
Eficincia do Usurio N3
Processamento Complexo N4
Reusabilidade N5
Facilidade de Instalao N6
Usabilidade N7
Portabilidade N8
Facilidade de Manuteno N9
Concorrncia N10

10
FTNF = 0.65 + Ni 0.01
i =1

Passo 3. Clculo da Estimativa do Tamanho Total (ETT)

Finalmente, calcule o Tamanho Total do Software atravs da frmula:

ETT = FNA FTNF , onde:

FNA = Fatores No-Ajustveis


FTNF = Fatores Tcnicos No Funcionais

Variantes
Ao clculo dos Fatores Tcnicos No-Funcionais FTNF pode ser acrescido
pesos de importncia a cada uma das caractersticas. Assim sendo, ao somatrio do
clculo da frmula estaria incluso o peso de cada uma delas. Os pesos podem variar de
0.5 a 2, de acordo com o grau de complexidade que cada caracterstica trar ao sistema.
Com isso, a frmula do clculo do FTNF seria (MONTEIRO, 2005) (IFPUG, 1999)
(KARNER, 1993):
10
FTNF = 0.65 + 0.01 Ni Pi
i =1
77

Outra forma de calcular o tamanho do projeto atravs da utilizao das tcnicas


de APF (IFPUG, 1999) e PCU (KARNER, 1993):

Exemplo:
Considere o Sistema de Matrcula descrito na Seo 6.2.
Passo 1. Clculo dos Fatores No-Ajustveis (FNA):

a. Separao das funcionalidades por caso de uso:


i. Manter Professor
Considere trs transaes simples para cadastrar, alterar e
excluir um professor (3 TED), e uma transao de consulta (1
TCD);
ii. Manter Estudante
Considere trs transaes simples para cadastrar, alterar e
excluir um professor (3 TED), e uma transao de consulta (1
TCD);
iii. Logar no Sistema
Considere duas consultas para validar usurio e senha (2
TCD);
iv. Selecionar Cursos
Considere trs transaes para gravar os cursos selecionados:
cadastrar, atualizar e excluir (3 TED); Considere uma
transao externa para consulta dos cursos disponveis (1
TEX e, consequentemente, 1 TPD); Considere duas
transaes de sadas de dados da base para verificar se os
horrios dos cursos no so conflitantes com os demais cursos
do professor (2 TSD); Considere uma consulta aos cursos do
professor (1 TCD);
v. Submeter Notas
Considere uma transao de consulta para listar as notas dos
estudantes do curso (1 TCD); Considere uma transao
externa para listar os cursos ministrados pelo professor (1
TEX, 1 TPD); Considere trs transaes para: cadastrar as
78

notas, atualizar e excluir (3 TED); Considere uma transao


para que o professor selecione o curso (1 TSD);
vi. Visualizar Boletim
Considere uma transao externa para listar os cursos
matriculados (1 TEX, 1 TPD); Considere uma transao de
consulta para as notas de cada curso (1 TCD);
vii. Realizar Matrcula
Considere uma transao externa para que o estudante liste os
cursos ofertados (1 TEX, 1 TPD); Considere uma transao
para que o estudantes escolham os cursos (1 TSD); Considere
duas transaes para realizao e cancelamento da matrcula
(2 TED); Considere uma transao de consulta aos cursos
matriculados (1 TCD);

b. Atribuio de complexidade e pesos:


Para cada uma das transaes acima, classifique-as como simples,
mdia e complexa e contabilize, de acordo com a Tabela 6.4;

Tabela 6.4 Pesos para o Sistema de Matrcula


Grupos de Complexidade Quantidade Peso5 Valor
Transaes
TED Simples 6 3 18
Mdia - 4 0
Complexa 8 6 48
TSD Simples 4 4 16
Mdia - 5 0
Complexa - 7 0
TCD Simples 3 3 9
Mdia - 4 0
Complexa 5 6 30
TEX Simples - 5 0
Mdia - 7 0
Complexa 4 10 40
TPD Simples - 7 0

5
Pesos referentes e calibrados de acordo com a tcnica de Pontos de Funo [IFPUG, 1995].
79

Mdia - 10 0
Complexa 4 15 60
FNA 221

Passo 2. Clculo dos Fatores Tcnicos No Funcionais (FTNF), de acordo com


a Tabela 6.5.
a. Atribua pesos para cada uma das caractersticas, onde peso 0
significa ausncia de caracterstica, peso 3 mdia influncia e peso 5
alta influncia da caracterstica no sistema que est sendo
desenvolvido.

Tabela 6.5 Valores atribudos aos Fatores No-Funcionais


Caracterstica Peso
Processamento Distribudo 3
Desempenho 5
Eficincia do Usurio 3
Processamento Complexo 3
Reusabilidade 5
Facilidade de Instalao 5
Usabilidade 5
Portabilidade 5
Facilidade de Manuteno 5
Concorrncia 3
Total 42

FTNF = 0.65 + (42 0.01) = 1.07

Passo 3. Clculo da Estimativa do Tamanho Total (ETT)

ETT = FNA FTNF = 221 1.07 = 236.47 unid. de tamanho. Onde,


FNA = Fatores No-Ajustveis
FTNF = Fatores Tcnicos No Funcionais
Contexto Resultante:
Vantagens
o A empresa poder confiar mais em suas estimativas ao fechar
contratos, tendo mais segurana e visibilidade do tamanho de cada
80

projeto, alm de possibilitar a estimativa de outras medidas como


esforo, custo e prazo total do projeto;
o O gerente de projeto de posse do tamanho do software poder realizar
estimativas mais prximas realidade, minimizando eventual
prejuzo financeiro empresa;
o As primeiras estimativas tendem a ser mais discrepantes em relao
realidade. medida que novos projetos surgem, as estimativas
tendem a ser mais precisas.
Desvantagens
o O nvel de detalhamento das funcionalidades no momento do clculo
da estimativa tem que ser satisfatrio. Qualquer mudana de escopo,
no decorrer do projeto, afetar a estimativa realizada;
o A empresa precisa ter maturidade ao classificar um caso de uso de
acordo com sua complexidade. O que simples pra uma empresa,
pode ser complexo em outra. Nesse caso, os dados histricos e
experincia da equipe auxiliam na classificao.

Racional:
Os gerentes de projeto das MPES necessitam estimar o tamanho do software de
forma precisa, rpida e simples. Os principais problemas enfrentados por estas empresas
so referentes diversidade de tcnicas existentes, complexidade oferecida por elas,
aliada reduzida quantidade de recursos humanos e financeiros.
O uso de componentes ou softwares disponveis no mercado torna o processo de
estimar rpido e preciso de acordo com a tcnica empregada, no entanto, as MPES no
podem realizar tal investimento.
Dados histricos de estimativas podem ajudar na preciso, caso sejam
consolidadas e avaliadas previamente, mas por si s no funcionam satisfatoriamente.
Ento, estimar o tamanho do software baseado na diviso das funcionalidades
em transaes e na atribuio de complexidades a cada transao torna a estimativa
precisa, rpida e simples uma vez que atende tanto a software estruturados como
orientados a objetos, alm de torn-los independentes de plataforma e linguagem de
desenvolvimento, fazendo o processo apto s MPES.
81

Usos Conhecidos:
A tcnica de medir o tamanho do software por Anlise de Ponto por Funo
(Function Point Analysis FPA) (IFPUG, 1999) derivada a partir de mtricas diretas,
onde o projeto deve ser inteiramente decomposto em funcionalidades de acordo as
interfaces com o usurio, entradas, sada e consultas, atribuindo-se pesos a cada uma
dessas funcionalidades.
O MKII Function Point Analysis (SYMONS, 1991) uma variao da FPA onde
estende a lista dos fatores tcnicos no-funcionais.
O Cosmic Full Function Point - FPP (ABRAN, 2000) outra variao da FPA
onde pode ser ajustada a projetos orientados a objetos. A FPP no leva em considerao
para efeito de tamanho os fatores tcnicos no-funcionais e nem os de qualidade que so
medidos separadamente.
O Use Case Point UCP (KARNER, 1993) uma tcnica de estimativa de
tamanho para software orientado a objetos, onde foi desenvolvida a tcnica de
diagramao para o conceito de caso de uso. O UCP foi criado baseado na FPA onde
explora o modelo e a criao de casos de uso, substitui algumas caractersticas tcnicas
proposta pela FPA, cria os fatores ambientais, como experincia da equipe, e prope
uma estimativa de produtividade.
O Ponto de Caso de Uso Tcnicos TUCP (MONTEIRO, 2005) uma extenso
do UCP como forma de torna a estimativa mais precisa para casos de uso mais
complexos.

Padres Relacionados:
A partir dos dados estimados do tamanho do software pode-se obter a
Estimativa do Esforo Total do desenvolvimento. Com o padro Obteno de Dados
Histricos possvel obter informaes sobre medies anteriores e auxiliar na
classificao das funcionalidades e caractersticas do software a ser desenvolvido.

2. Estimativa do Esforo Total

Contexto:
Os gerentes de projetos das MPES de software tm dificuldade em estimar o
esforo, em horas de trabalho, necessrio para desenvolver o projeto.
82

Problema:
Como elaborar estimativas de esforo para o desenvolvimento do software?

Foras:
1) Para maior preciso das estimativas de esforo, o gerente de projeto pode
realizar a estimativa por fase do projeto de acordo com cada funcionalidade,
e logo aps obter a estimativa de esforo total do software, porm exige um
nvel de detalhamento maior, despendendo tempo e custo s MPES;
2) Estimativas de esforo podem ser obtidas atravs de relatos de experincia
dos especialistas da empresa, porm tais relatos podem remeter a dados
discrepantes e fora da realidade, podendo causar prejuzos financeiros
empresa, risco que as MPES no podem se submeter;
3) A MPES, em virtude do seu porte e condies salariais baixas comparadas s
grandes empresas, possui elevada rotatividade de pessoal, o que prejudica a
elaborao de estimativas precisas de esforo;
4) O cliente do projeto pode exigir um valor limite de esforo para a construo
do software, induzindo o gerente a elaborar estimativas de esforo prximas
a esse valor e fora da realidade da empresa;
5) O clculo de estimativas mais elaboradas ao considerar o tamanho do
software, alm de outros fatores, como por exemplo, o nvel de
desenvolvimento exigido, coeso da equipe e maturidade do processo
tornam a estimativa mais precisa, porm necessitam de tempo para serem
planejadas e calculadas;
6) O clculo de estimativas de esforo baseadas no tamanho total do software e
de acordo com as funcionalidades do software torna a estimativa mais
precisa. Dados histricos de estimativas podem reforar a preciso do
clculo do esforo, alm de fornecer dados como a Produtividade da Equipe;

Soluo:
1) Obtenha a Produtividade (PROD) da equipe atravs do padro Obteno de
Dados Histricos;
2) Obtenha atravs de Estimativa do Tamanho Total (ETT) a estimativa do
tamanho total do software a ser desenvolvido;
83

3) Calcule a Estimativa de Esforo Total (ESF) em horas:

ESF ( horas ) = PROD ETT , onde,

PROD = Produtividade,
ETT = Estimativa do Tamanho Total

Variantes:
O Esforo Total do software pode ser obtido com maior preciso ao considerar o
nvel de Experincia da Equipe (EE) nas tecnologias e processos envolvidos.
Classifique a equipe quanto sua experincia de acordo com as caractersticas da
Tabela 6.6. Cada caracterstica deve ser avaliada com notas: 0 no atende, 3 atende
parcialmente, 5 atende completamente;

Tabela 6.6 Caractersticas da Experincia da Equipe


Caracterstica Nota
Dificuldade na Linguagem de Programao N1

Conhecimento do Processo de Desenvolvimento N2

Capacidade de Anlise N3
Experincia com a Orientao a Objetos N4

Estime o Esforo Total com a frmula abaixo:


ESF = PROD ETT EE , onde
PROD = Produtividade,
ETT = Estimativa do Tamanho Total,
4
EE(Experincia da Equipe) = 1.4 (0.03 x Ni )
i =1

Exemplo:
Considere, por exemplo, que a produtividade mdia da equipe da empresa XYZ
de 10hs/ETT.
Logo,
ESF = 10 236.47 2364 horas
Suponha agora, que a Experincia da Equipe seja 11. Logo,
FA = 1 .4 ( 0 .03 x11) = 1 .07
84

ESF = 10 236.47 1.07 2530 horas


Contexto Resultante:
Vantagens
o O gerente do projeto ter o valor do esforo de desenvolvimento do
projeto em horas. De posse desse valor, poder contabilizar outras
medidas de estimativas como custo e prazo total do projeto para
auxiliar nas decises estratgicas do projeto;
o Ao estimar o esforo a partir do tamanho, o gerente de projeto tem
um embasamento racional para a quantidade de horas necessrias, o
que possibilita o aumento do poder de negociao com cliente.
Desvantagens
o O clculo do esforo depende do clculo do tamanho do software. Se
as funcionalidades no estiverem sido levantadas de forma coerente,
ento iro impactar no clculo das demais estimativas, incluindo o
esforo.
o O clculo do esforo depende da produtividade da equipe. As MPES
tendem a possuir elevada rotatividade de pessoal e como
conseqncia, queda na produtividade.

Racional:
Simplesmente estimar o esforo necessrio para o projeto atravs de relatos de
experincia individuais dos membros da empresa, no to preciso quanto a obteno
de valores reais baseados em clculos previamente definidos.
Outra abordagem a obteno de estimativas por fase do projeto, para
posteriormente estimar o todo. Abordagens destes tipos tendem a possuir maior grau de
preciso, porm necessitam de dedicao e tempo para planejamento das fases do
projeto, itens que as MPES no possuem.
Estimar o esforo total para desenvolvimento do software baseado no clculo
prvio do seu tamanho total e na produtividade mdia da equipe uma boa soluo em
virtude da sua simplicidade, porm em projetos maiores convm considerar tambm o
nvel de experincia da equipe nas tecnologias exigidas.
85

Usos Conhecidos:
A tcnica de Anlise de Ponto por Funo calcula o esforo a partir do produto
entre o tamanho do projeto e a a utilizao da taxa de entrega.
A tcnica Construtive Cost Model - COCOMO II (BOEHM, 2000) calcula
esforo, prazo, tamanho de equipe e custo necessrio para o desenvolvimento do
software, desde que se tenha a dimenso do mesmo, ou seja, seu tamanho. Nesta
tcnica, alm dos fatores considerados para o clculo do esforo so considerados
outros fatores de escala.
As tcnicas UCP (MONTEIRO, 2005) (KARNER, 1993) e TUCP calculam o
esforo a partir dos dados citados na soluo, levando em considerao os fatores
ambientais que so calculados a partir de vrios itens com atribuies de pesos.

Padres Relacionados:
O padro Estimativa do Tamanho Total e Obteno de Dados Histricos
servem como entrada desse padro ao calcular o tamanho do software e a produtividade
da equipe, respectivamente. Com o valor em horas do esforo total do projeto, o gerente
pode obter as demais estimativas de prazo e custo com os padres: Estimativa do Prazo
Total e Estimativa do Custo Total.

3. Obteno da Jornada de Trabalho

Contexto:
No planejamento do projeto, o gerente necessita de todas as informaes
referentes aos profissionais da rea para calcular as estimativas de prazo total do
projeto, entre elas, o valor da jornada de trabalho dos empregados.

Problema:
Como obter o valor da jornada de trabalho dos funcionrios da empresa para
estimar de forma mais precisa o prazo do projeto?

Foras:
1) Cada profissional tem horrio e jornada de trabalho diferenciada, o que
dificulta este tipo de levantamento;
86

2) O gerente pode considerar que todos os funcionrios da empresa possuam a


mesma jornada de trabalho, porm tal levantamento pode impactar no prazo
total do projeto;
3) A existncia de um setor de recursos humanos, responsvel pelo controle da
jornada de trabalho dos funcionrios, facilita ao gerente o levantamento
deste valor;
4) A ausncia de um setor de recursos pode dificultar por parte do gerente a
obteno da jornada de trabalho.

Soluo:
1) Caso exista o departamento de recursos humanos verifique a jornada de
trabalho diria, em horas, dos profissionais;
2) Se houver divergncia na jornada de trabalho dos profissionais, realize uma
mdia para obter o valor da jornada geral.

Valor da Jornada de Trabalho = VlrJTRAB horas/dia


Variantes:
1) Caso no haja o departamento de recursos humanos verifique com todos os
profissionais um a um o valor da jornada de trabalho;

Valor da Jornada de Trabalho = VlrJTRAB horas/dia

Exemplo:
O gerente de projeto do Sistema de Matrcula verificou junto ao setor de
recursos humanos da empresa XYZ que todos os profissionais possuem a mesma
jornada de trabalho de 8 horas por dia. Logo,
VlrJTRAB = 8 horas/dia

Contexto Resultante:
Vantagens:
o O gerente do projeto, de posse do valor da Jornada de Trabalho dos
profissionais da empresa, poder estimar e decidir quanto ao prazo
total de concluso do projeto. Sendo assim, o gerente pode negociar
melhor com o cliente.
87

Racional:
O departamento de recursos humanos responsvel por controlar desde a
contratao dos empregados, at salrio e freqncia. este departamento que possui
relatrios sobre a jornada de trabalho de cada profissional. Nem todas as MPES
possuem tal setor em virtude da quantidade reduzida de profissionais, cabendo ento ao
gerente realizar o levantamento por si s.

Usos Conhecidos:
Em geral todos os gerentes de projetos que necessitam realizar estimativas
obtm o valor da jornada de trabalho dos empregados da empresa.
Uma instituio financeira atualmente em todo o Brasil obtm o valor da jornada
de trabalho de todos os profissionais da rea de TI como forma de estimar os projetos de
software. Tal instituio utiliza a tcnica de TUCP (MONTEIRO, 2005) para estimar os
softwares em todos seus projetos.

Padres Relacionados:
Com a informao da jornada de trabalho, o gerente de projeto poder dar
continuidade s demais medies como: Obteno de Recursos Humanos Disponveis,
Estimativa do Prazo Total e Estimativa do Custo Total.

4. Obteno dos Recursos Humanos Disponveis

Contexto:
No planejamento do projeto, os gerentes de projetos das MPES precisam ter
visibilidade de todos os seus recursos humanos para devida alocao no projeto.

Problema:
Como obter a quantidade de recursos humanos disponveis da empresa para
serem alocados no projeto?

Foras:
88

1) O gerente de projeto pode se reunir com cada profissional da empresa para


saber em qu est alocado e os horrios livres, porm os gerentes de projeto
das MPES no possuem tempo suficiente para realizar tal atividade;
2) O gerente de projeto pode, via e-mail, solicitar que cada profissional
responda com o seu horrio disponvel;
3) Nas MPES um membro do projeto alocado em vrias atividades diferentes
ao exercer diversos papis, ou at mesmo em projetos diferentes, o que
dificulta ao gerente de projeto obter a quantidade de recursos humanos
disponveis;
4) O gerente de projeto pode verificar junto ao setor de recursos humanos a
alocao de cada um nos projetos e horrios disponveis, porm esse setor
possui dados macros e muitas vezes desatualizados.
5) Um levantamento da quantidade de recursos disponveis junto ao
profissional possibilita a obteno de dados mais prximos da realidade,
alm de permitir ao gerente visualizar a alocao de cada um no projeto.

Soluo:
1) Faa um levantamento, por e-mail, de todos os profissionais da empresa para
saber a alocao de cada um;
2) Verifique atravs do padro Obteno do Valor da Jornada de Trabalho a
quantidade de horas trabalhadas diariamente;
3) Verifique a quantidade de recursos humanos completamente disponveis e
contabilize-os;
4) Verifique aqueles recursos que esto parcialmente alocados, e contabilize-os
atravs de horas/dia disponveis. Realize regra de trs simples para calcular a
porcentagem de tempo disponvel em relao ao todo.
5) Some e obtenha a Quantidade de Recursos Disponveis (QtdRD);
6) Realize mapeamento inicial dos recursos disponveis com respectivos papis
necessrios no projeto;

Quantidade de Recursos Disponveis = QtdRD pessoas


89

Exemplo:
A empresa XYZ possui 15 funcionrios, entre gerentes, analistas, projetistas e
desenvolvedores. Entre eles, apenas 3 (trs) esto completamente disponveis (um
analista de sistemas e dois programadores) para serem alocados ao projeto de Matrcula
dos Alunos na Universidade. O gerente de projeto possui apenas 6 horas livre por dia.
Suponha ainda, que nenhum dos recursos est disponvel para realizao de horas-extras
e que o valor da jornada de trabalho de 8horas/dia. Logo, fazendo uma regra de trs
simples, temos que o gerente de projeto contabiliza apenas 75% do tempo.
Ento:
QtdRD = 3 + 0.75 = 3.75 pessoas

Contexto Resultante:
Vantagens
o O gerente de projeto, de posse da quantidade de recursos disponveis
e da jornada de trabalho poder calcular o prazo total de execuo do
projeto;
o O gerente de projeto poder distribuir os recursos disponveis no
projeto de acordo a disponibilidade de cada um..
Desvantagens
o Nas MPES, devido ao reduzido quadro de empregados, cada um
deles exerce mais de um papel, logo, tal levantamento no trivial.
Cabe ao gerente de projeto encontrar a melhor forma de quantificar a
disponibilidade de cada um.

Racional:
Realizar o levantamento da quantidade de recursos disponveis via e-mail uma
soluo prtica e com tempo de resposta satisfatrio, o que facilita ao gerente o
levantamento dos recursos disponveis, uma vez que nas MPES o quadro de
funcionrios reduzido.
Ao analisar criteriosamente a distribuio e alocao dos recursos nos projetos
atuais da empresa e contabiliz-los, o gerente de projeto poder planejar melhor a
utilizao de tais recursos no novo projeto.
90

Usos Conhecidos:
O Rational Unified Process RUP (KRUCHTEN, 2003), na disciplina Gerncia
de Projeto, possui o artefato chamado de Plano de Projeto, onde o gerente de projeto
tem a misso de verificar os recursos disponveis da empresa para alocao no projeto.
O Capability Maturity Model Integrated - CMMI (SEI, 2006) na rea de
processo de Planejamento de Projeto possui uma prtica especfica chamada de Plan for
Project Resources onde alm do planejamento e obteno dos recursos humanos
disponveis para o projeto, verifica a disponibilidade de recursos de hardware e
software.
O PMBOK (PMI, 2009) voltado para a gerncia de projetos, entre as diversas
reas de conhecimento est a rea de Gerncia do Custo do Projeto que inclui o
processo de Planejamento de Recursos para determinar quais recursos (pessoas,
equipamentos, materiais) e em que quantidade devem ser usados para executar as
atividades do projeto.
O MPS.BR (SOFTEX, 2009a), no nvel G, possui o processo de Gerncia de
Projetos, onde entre tantas atividades encontra-se a de planejamento de recursos
humanos.

Padres Relacionados:
Para obter os recursos da empresa e observar a alocao e disponibilidade de
cada um, necessrio a Obteno do Valor da Jornada de Trabalho. A quantidade de
recursos disponveis para o projeto auxilia na Estimativa do Prazo Total.

5. Estimativa do Prazo Total

Contexto:
O gerente de projeto, na fase de planejamento de projeto, de posse do esforo em
horas total do projeto, da quantidade de recursos disponveis ao projeto e do valor da
jornada de trabalho dos profissionais, necessita quantificar ao cliente o prazo necessrio
para desenvolver o sistema solicitado, como forma de firmar um acordo e fechar o
contrato.
91

Problema:
Como elaborar estimativas de prazo do desenvolvimento do software na fase
inicial do projeto?

Foras:
1) O cliente do projeto pode exigir um valor limite de prazo para entrega do
produto, induzindo o gerente a elaborar estimativas de prazo prximas a esse
valor, fora da realidade da empresa e sem nenhum embasamento;
2) Estimativas de prazo podem ser obtidas atravs de relatos de experincia dos
especialistas da empresa, porm tal valor pode ser subestimado ou
sobreestimado, podendo causar, respectivamente, prejuzos financeiros
empresa ou insatisfao ao cliente;
3) O gerente pode obter o prazo total do projeto baseado em dados
quantitativos de medio, como o esforo total e a quantidade de recursos
disponveis, o que causa maior preciso estimativa;
4) O gerente de projeto pode estimar o prazo total atravs de tcnicas
elaboradas que levam em considerao vrios fatores de ponderao, porm
a utilizao de tais tcnicas despende tempo que os gerentes de MPES no
possuem;
5) As MPES no possuem segurana ao estimar o prazo de um projeto, porm
se este for decomposto e contabilizado em escopos menores para
posteriormente estimar o prazo total, este ser mais facilmente contabilizado,
entretanto, tal decomposio exige tempo que estas empresas no possuem;

Soluo:
1) Obtenha atravs de Estimativa do Esforo Total o esforo total, em horas,
necessrio para o desenvolvimento do projeto;
2) Atravs de Obteno dos Recursos Humanos Disponveis, obtenha a
quantidade de recursos disponveis para o projeto;
3) Atravs de Obteno do Valor da Jornada de Trabalho, obtenha o valor da
jornada de trabalho dos funcionrios da empresa;
4) Calcule a Estimativa de Prazo Total do Software (EPRZ):
92

ESF
EPRZ = , onde:
(QtdRD VlrJTRAB )
ESF = Esforo Total do Projeto
QtdRD = Quantidade de Recursos Humanos Disponveis
VlrJTRAB = Valor da Jornada de Trabalho

Exemplo:
A empresa XYZ, para desenvolver o projeto Sistema de Matrcula, necessitar
de um prazo de aproximadamente:

2530
EPRZ = 84 dias teis
3.75 8

Contexto Resultante:
Vantagens:
o A empresa obter o valor do prazo total de desenvolvimento do
projeto em dias a partir de dados objetivos e racionais, podendo
assim, negociar mais facilmente com o cliente.
Desvantagens:
o O clculo do prazo depende do calculo da jornada de trabalho e dos
recursos disponveis. Esses dois ltimos so complicados nas MPES
em virtude do reduzido quadro de profissionais e da alocao deles
em outros projetos.

Racional:
Simplesmente estimar o tempo necessrio para o desenvolvimento do projeto
atravs de relatos de experincia individuais dos membros da empresa, no to preciso
quanto a obteno de valores reais baseados em clculos previamente definidos.
As obtenes do prazo do projeto atravs de tcnicas mais elaboradas e da
decomposio do projeto tornam a estimativa com maior grau de preciso, porm a
execuo de tais estimativas necessita de tempo, preparo e custo.
Estimar o prazo baseado em dados previamente calculados, como o esforo,
quantidade de recursos disponveis e jornada de trabalho, torna a estimativa precisa o
93

suficiente e simples, possibilitando com que as MPES sejam objetivas no clculo das
estimativas.

Usos Conhecidos:
A tcnica Anlise de Ponto por Funo calcula a estimativa de prazo atravs da
razo entre esforo e recursos.
A tcnica do COCOMO II (BOEHM, 2000) obtm o prazo total do projeto a
partir do esforo e equipe mdia necessria para o desenvolvimento.
J o UCP (KARNER, 1993) e TUCP (MONTEIRO, 2005) calculam o prazo
total do projeto a partir dos valores do esforo, quantidade de recursos e horas de
trabalho dirio de cada profissional. No caso do TUCP as jornadas de trabalho dos
profissionais so consideradas informaes pr-definidas.

Padres Relacionados:
Os seguintes padres so necessrios para o clculo do valor do prazo total do
projeto: Estimativa do Esforo Total, Obteno dos Recursos Humanos Disponveis e
Obteno do Valor da Jornada de Trabalho. O gerente de projeto aps ter mensurado
o projeto quanto a prazo, dever aprov-lo junto ao cliente atravs do padro Aprovao
das Estimativas.

6. Obteno do Valor da Hora

Contexto:
O gerente de projeto, ao planejar o desenvolvimento do sistema, necessita obter
informaes do valor da hora de trabalho dos funcionrios da empresa, como forma de
mensurar o custo total de execuo do projeto.

Problema:
Como obter o valor da hora de trabalho dos funcionrios da empresa?
94

Foras:
1) O gerente de projeto pode obter o valor da hora de trabalho baseado no
mercado e no em valores internos da empresa, podendo posteriormente ter
um impacto significativo no custo do software;
2) O gerente de projeto pode obter o valor da hora de trabalho de acordo com
dados de projetos anteriores, porm tais valores podem estar desatualizados;
3) O gerente de projeto pode calcular o valor da hora de acordo com o maior
salrio ou ainda com a mdia geral de todos os salrios dos funcionrios. No
entanto, tal forma de calcular pode gerar um valor elevado, com impacto
direto no custo do software;
4) Os salrios dos funcionrios variam de acordo com o cargo,
conseqentemente, o valor da hora de trabalho tambm. O gerente pode,
ento, calcular o valor da hora de trabalho de acordo com o papel de cada
um;
5) Os funcionrios das MPES geralmente assumem mais de um papel no
processo de desenvolvimento, o que pode influenciar na obteno do valor
da hora de trabalho em cada projeto.

Soluo:
1) Para cada papel necessrio no processo de desenvolvimento do projeto,
calcule o valor da hora de trabalho:

Salrio
VlrHORA( Papel) = , onde:
VlrJTRAB 30
VlrJTRAB = Valor da Jornada de Trabalho

Exemplo:
Para o Sistema de Matrcula sero alocados 4 profissionais. Trs deles alocados
plenamente no projeto e um deles alocado parcialmente (6 horas por dia). Supondo que
a alocao no projeto esteja distribuda da seguinte forma: 1 gerente de projeto (6 horas
por dia), 1 analista, 2 desenvolvedores. Supondo ainda que estes funcionrios possuam
os respectivos salrios: R$3.500,00, R$2.600,00, R$ 2000,00. Logo,
95

3.500,00
VlrHORA(Gerente) = R$19.50
6 30
2.600,00
VlrHORA( Analista) = R$10.90
8 30
2.000,00
VlrHORA( Desenvolvedor) = R$8.40
8 30

Contexto Resultante:
Vantagens
o Nas MPES, na maioria das vezes, cada profissional exerce mais de um
papel, logo o clculo poder ser realizado de acordo com a quantidade de
horas trabalhadas em cada papel;
o Com os valores acima, o gerente do projeto poder calcular o valor
gasto, em reais, de cada um dos profissionais para execuo do projeto.
Podendo negociar os valores com o cliente.
Desvantagens
o Para cada cargo ou variao salarial da empresa, o gerente de projeto ter
que calcular o valor da hora do profissional. Para contornar isso, o
gerente poder considerar a maior variao salarial dentro de
determinado cargo, por exemplo.

Racional:
Obter o valor da jornada de trabalho de profissionais de informtica no mercado
um risco ao projeto. Cada empresa brasileira possui porte e salrios diferenciados, nas
MPES esses valores so mais discrepantes, necessitando, portanto, clculos reais de
acordo com sua realidade. Os salrios de quaisquer profissionais variam constantemente
e o valor da hora de trabalho necessita ser recalculado periodicamente.
A opo de calcular individualmente o valor da hora de trabalho de cada papel
do profissional no projeto torna a estimativa mais precisa do que, por exemplo, pegar
uma mdia geral do valor.

Usos Conhecidos:
De acordo com o Artigo 64 da Lei Trabalhista CLT o valor da hora de trabalho
de um trabalhador obtido a partir do salrio e da jornada de trabalho dividido por 30
dias.
96

Uma instituio financeira atuante em boa parte do territrio nacional utiliza a


TUCP (MONTEIRO, 2005) para estimar os softwares. Para estimar o software de
Central de Cadastro dos Clientes, por exemplo, tal instituio necessita como entrada da
TUCP o valor da hora de trabalho de cada profissional. Os valores so calculados de
acordo com a frmula acima. Demais sistemas desenvolvidos tambm utilizam de tal
tcnica de estimativa.

Padres Relacionados:
O valor da hora de trabalho de cada profissional dado de entrada para o clculo
da Estimativa do Custo Total.

7. Estimativa do Custo Total

Contexto:
O gerente do projeto necessita na fase de planejamento, obter o custo, ou seja, a
despesa do projeto para a empresa como forma de negociar com o cliente o valor do
desenvolvimento do mesmo.

Problema:
Como elaborar estimativas de custo do desenvolvimento do software?

Foras:
1) Estimar o custo de desenvolvimento ao levar em considerao apenas o valor
do salrio mais elevado da empresa e do esforo total de desenvolvimento do
software pode acarretar no superfaturamento do software;
2) O gerente de projeto, baseado em experincias anteriores, pode estimar o
custo do desenvolvimento do software. No entanto, tal estimativa pode
superfaturar ou subfaturar o valor do software;
3) O gerente de projeto pode levar em considerao a necessidade financeira da
MPES e assim estimar o valor do custo do software, porm tal estimativa
pode prejudicar a negociao com o cliente;
97

4) As MPES no possuem recursos suficientes para despender muito tempo


com a utilizao de tcnicas elaboradas, como a utilizao de desvio padro,
para o clculo do custo do projeto;
5) O gerente de projeto pode ponderar dados histricos de projetos anteriores,
atravs da Obteno de Dados Histricos, para considerar o esforo
necessrio por papel do projeto, obter o valor da hora de trabalho de cada
profissional e, posteriormente, obter o custo total de desenvolvimento do
software;
6) O cliente pode exigir que o valor do custo de desenvolvimento do software
no ultrapasse um valor teto, induzindo o gerente a obter estimativas
prximas a esse valor e totalmente diferentes do custo real do projeto para
empresa, podendo causar um prejuzo financeiro significativo, risco este que
as MPES no podem arcar.

Soluo:
1) Obtenha a Estimativa do Esforo Total;
2) Obtenha, em porcentagem, o esforo necessrio para cada papel no projeto.
Para isso, verifique dados histricos anteriores em Obteno de Dados
Histricos;
3) Com a Obteno do Valor da Hora, o valor da hora de trabalho de cada
papel do projeto obtido;
4) Calcule o custo total do desenvolvimento do projeto, da seguinte forma:

CUSTO = ESF P( Papel) VlrHORA( Papel) , onde:


ESF = Estimativa do Esforo Total
P = Porcentagem de esforo necessrio para cada Papel
VlrHORA = Valor da Hora de Trabalho para cada Papel

Exemplo:
Supondo que as fases do desenvolvimento do Software estejam divdiidas em:
Requisitos, Anlise, Projeto, Codificao e Teste. Supondo ainda que 15% do esforo
total ser gasto com o Gerente de Projeto, 35% do esforo total ser gasto nas fases de
98

Requisitos, Anlise e Projeto com o Analista de Sistemas e 50% com o desenvolvedor


para a codificao e testes do sistema.
No sistema de matrcula o custo total para o desenvolvimento do software ser:

CUSTO = (2530 0.15 R$19.50) +


(2530 0.35 R$10.90) +
(2530 0.5 R$8.40) R$27.677.00

Contexto Resultante:
Vantagens
o A empresa ter o valor do custo total de desenvolvimento do projeto
baseado em valores objetivos, calculados a partir de dados concretos
do custo do software, podendo assim, acrescentar custos adicionais e
negociar com o cliente.
Desvantagens
o O custo calculado do software pode ser maior do que o esperado pelo
cliente. Cabe ao gerente efetuar as devidas negociaes e assumir os
riscos;

Racional:
Estimar o custo do software baseado em experincias anteriores ou de acordo
com a presso do cliente pode gerar um risco financeiro alto as MPES que geralmente
no possuem recursos financeiros extras para sustentar a empresa. Portanto, o ideal
estimar o custo baseado em valores reais do tamanho e esforo do software.
A porcentagem gasta em cada fase do desenvolvimento do software varia de
empresa pra empresa. Cada empresa deve guardar estas informaes em dados
histricos para avaliao dos projetos subseqentes. O resultado do custo total do
software depende consideravelmente da porcentagem de contribuio de cada
profissional ao longo do projeto e conseqentemente do valor da hora de trabalho de
cada um. Estimar o software baseado em tais valores torna a estimativa simples e
precisa. Superfaturar um pouco o custo do software melhor do que a situao
contrria, principalmente para as MPES.
99

Usos Conhecidos:
As tcnicas UCP (KARNER, 1993) e sua variao TUCP (MESZAROS;
DOBLE, 1996) e COCOMO II (BOEHM, 2000) utilizam esta forma de clculo do custo
do software por fase de desenvolvimento.

Padres Relacionados:
A partir da Estimativa do Esforo Total, Obteno do Valor da Hora e
Obteno de Dados Histricos o gerente estima o tempo gasto por fase do projeto para
calcular o custo. Posteriormente, o gerente necessita a Aprovao das Estimativas por
parte do cliente.

8. Aprovao das Estimativas

Contexto:
O gerente de projeto calculou todas as estimativas do software quanto a prazo e
custo do projeto. O gerente necessita da aprovao do cliente.

Problema:
Como aprovar as estimativas?

Foras:
1) O gerente de projeto pode optar por aprovar as estimativas junto ao cliente
sem despender tempo, podendo realizar a negociao atravs de trocas de e-
mails ou contato telefnico. No entanto, tal forma de aprovao pode gerar
ao cliente m impresso e desleixe por parte da empresa;
2) O gerente de projeto pode tentar aprovar as estimativas com o cliente atravs
de reunies, o qu pode transmitir maior grau de segurana, organizao e
ateno ao cliente, deixando-o mais confiante;
3) O gerente pode tentar aprovar as estimativas com o cliente ao explicar
minuciosamente como obteve os valores de prazo e custo do software.
Assim, pode aumentar a segurana do cliente em relao a essas estimativas,
tornando mais fcil a sua aprovao;
100

4) O gerente pode tentar aprovar as estimativas com o cliente ao apresentar um


prottipo do projeto, com algumas telas de funcionalidades, alm de fazer
um bom marketing para a venda do projeto, sem se ater muito a explicar
como obteve os valores estimados. No entanto, as MPES no possuem
tempo e recursos humanos e financeiros suficientes para investir na criao
de prottipos e marketing pessoal nesta fase do desenvolvimento;
5) O gerente pode simplesmente apresentar os valores ao cliente, sem entrar
nos detalhes de como foram obtidos. No entanto, tal tcnica arriscada, pois
o cliente pode no se convencer dos valores de prazo e custo e desistir da
negociao.

Soluo:
1) Marque reunio com o cliente;
2) Apresente os valores de prazo e custo do desenvolvimento ao cliente;
3) Apresente ao cliente as informaes de como foram calculados os valores
apresentados;
4) Transmita segurana ao cliente, que o clculo dos valores justo e de acordo
com as funcionalidades e complexidades exigidas por ele;
5) O cliente aceita os valores e assina o contrato.

Variantes:
Na reunio, aps a apresentao dos valores por parte do gerente e tentativa de
convencer o cliente:
1) O cliente no aceita os valores;
2) O gerente marca outra reunio com o cliente para apresentao de novos
valores;
3) O gerente refaz os clculos na tentativa de atender a expectativa do cliente;
4) O gerente apresenta os novos valores ao cliente;
5) O cliente aceita os valores e assina o contrato;
6) O cliente pode ainda no aceitar os valores e cancelar o projeto com a
empresa.

Contexto Resultante:
Vantagens
101

o Como o calculo das estimativas foi baseado em valores extrados a partir


das funcionalidades do software, o gerente possui maior embasamento
para justificar o custo e prazo do desenvolvimento do software;
o Caso o cliente imponha resistncia quanto ao prazo/custo, o gerente
tambm poder renegociar tendo como base valores consistentes, sem
colocar em risco o lucro da empresa.
Desvantagens
o O cliente pode aceitar ou no os termos de prazo e custo de
desenvolvimento do software. Caso o cliente aceite, o gerente deve
iniciar o desenvolvimento do software. Caso no aceite, o gerente deve
analisar em quais aspectos da negociao houve falha.
Racional:
O cliente poder insistir e discordar de algumas informaes no intuito de
reduzir o custo do software e/ou receb-lo em menos tempo. Com isso, o Gerente ter
que refazer os clculos de prazo e custo do software, e apresentar novamente ao cliente
em outra oportunidade.
Cabe ao gerente de projeto negociar o prazo com o cliente e convenc-lo que o
prazo obtido foi baseado em clculos derivados a partir de tamanho e esforo do
software. O cliente deve estar ciente que em uma MPES a quantidade de recursos
disponveis para alocao nos projetos sempre reduzida, o que pode influenciar no
prazo do projeto.

Usos Conhecidos:
Uma instituio financeira utiliza o processo de aprovao de estimativas atravs
de reunies com cliente. O gerente de projeto apresenta ao cliente as estimativas e
ocorrem as devidas negociaes. No caso dessa instituio, o cliente a prpria
instituio, ou seja, desenvolvimento interno de software. Para todos os sistemas
produzidos em tal instituio utilizado o TUCP (MONTEIRO, 2005) para o clculo
das estimativas e posteriormente efetuada a aprovao das mesmas.

Padres Relacionados:
Os padres de Estimativa do Custo Total, Estimativa do Prazo Total so
essenciais para a negociao com o cliente. Uma vez aprovados os valores, cabe ao
102

gerente de projetos definir, durante todo o processo de desenvolvimento, a Coleta de


Medidas Reais.

9. Coleta de Medidas Reais

Contexto:
No decorrer do processo de desenvolvimento do software necessrio coletar
informaes reais sobre o andamento do projeto. O Gerente de Projeto deve definir as
medies;

Problema:
Quais as medies que auxiliam no processo de estimar o software? Como
coletar medidas reais do tamanho do software, do esforo, do prazo e do custo?

Foras:
1) Realizar medies em um ambiente sem cultura de medies pode provocar
resistncias;
2) Para definio das medies a serem realizadas necessrio planejamento
por parte do gerente de projeto. O planejamento e definio de tais mtricas
so realizados apenas uma vez no processo de desenvolvimento e atende a
todos os projetos da empresa;
3) A organizao precisa estar disposta a encarar as medies como um
investimento em longo prazo, visto que para disponibilizar a realidade da
organizao com base em mtricas, necessrio tempo;
4) Para realizar as medies, o gerente de projeto pode obter pessoalmente as
informaes com os membros do projeto. No entanto, tal coleta por parte do
gerente faz com ele deixe de executar atividades prprias do seu papel;
5) A compra de uma ferramenta que automatize o processo de coleta e obteno
de medidas reais e que possa ser integrada com as ferramentas de anlise e
desenvolvimento dos projetos torna o processo rpido e simples. No entanto,
as MPES no possuem recursos financeiros para tal investimento;
103

6) O gerente de projeto pode definir marcos no projeto para medio. Cada


membro do projeto responsvel pela coleta das medidas nas datas
definidas;

Soluo:
1) Defina o qu ser medido, por exemplo:
a. Para cada funcionalidade do projeto, classifique-a como transao de
entrada de dados (TED), de sada de dados (TSD), consulta (TCD), sada
de dados externa (TEX) e de persistncia de dados (TPD);
b. Para cada funcionalidade do projeto, classifique-a como baixa, mdia ou
alta e realize a medio;
c. Esforo em horas gasto por fase/total do projeto;
d. Quantidade de horas e/ou dias total gasto por papel (contabilize tambm
em relao ao todo); Quantidade de horas e/ou dias total gasto por fase
(contabilize tambm em relao ao todo); Quantidade de horas e/ou dias
total do projeto;
e. Tamanho Total Real do software no final do projeto (verifique mudanas
de requisitos);
f. Produtividade da Equipe = Esforo Total Real/Tamanho Total Real;
g. Custo real do projeto total;
2) Defina o plano de mtricas, com as informaes: o que ser medido, como,
por quem e quando.
3) Construa documentos a serem preenchidos pelos profissionais aptos do
projeto, onde cada documento contm informaes sobre os dados que sero
medidos;
4) Disponibilize base de dados para guardar as medies;
5) Defina marcos no projeto para coletar as medies;
6) Cada membro do projeto responsvel por preencher documento sobre as
suas correspondentes medies;
7) O gerente de projeto de posse das medies deve alimentar base de dados
para posterior Obteno de Dados Histricos.

Contexto Resultante:
Vantagens
104

o A empresa ter base de dados com dados histricos reais por projeto,
podendo melhorar as estimativas em projetos futuros;
o A medio ajuda na avaliao objetiva dos dados. No se pode
melhorar o que no medido;
o O gerente de posse dos indicadores extrados das medies pode, por
exemplo: avaliar o status do projeto, controlar os riscos, ajustar as
atividades e avaliar a capacidade da equipe de controlar a qualidade
do produto de trabalho.
Desvantagens
o Todo trabalho de medio poder ser colocado em risco se no for
garantido a obteno de dados confiveis.

Racional:
Apesar da resistncia das pessoas para realizar as medies, a definio de
medidas simples no tomam tempo dos membros do projeto. Com o decorrer do tempo,
esse tipo de atividade se torna habitual, o essencial insistir na importncia da medio
para o futuro da empresa.

Usos Conhecidos:
O CMMI (SEI, 2006) na rea de processo Medio e Anlise utiliza a coleta de
dados no decorrer do processo de desenvolvimento.
O MPS.BR (SOFTEX, 2009a) no processo de Medio possui a atividade de
coletar dados e armazenamento dos dados e resultados.
Em (VASQUEZ, 2003) utilizado a atividade de Aprovar Estimativas no
processo de estimativa de um projeto de software.

Padres Relacionados:
Com a concentrao de tais informaes em uma base de dados compartilhada
pelos gerentes, os mesmos podem consult-las, Obteno de Dados Histricos, para
melhorar a preciso das estimativas em projetos futuros.
105

10. Obteno de Dados Histricos

Contexto:
Na fase de planejamento de projeto, o gerente necessita estimar o tamanho do
software, o esforo, o prazo e o custo para o seu desenvolvimento. Os membros dos
projetos realizam a coleta de medies de dados reais dos projetos envolvidos e
armazenam tais dados. Dados histricos de projetos anteriores devem ser capazes de
melhorar a preciso das estimativas.

Problema:
Como obter dados histricos com o intuito de melhorar a preciso das
estimativas?

Foras:
1) O gerente de projeto pode obter dados histricos atravs da sua prpria
experincia em projetos anteriores, dados estes puramente intuitivos,
podendo comprometer as estimativas;
2) O gerente de projeto pode obter dados histricos de outras empresas ou do
mercado de forma geral, dados estes que no esto de acordo com a
realidade da empresa;
3) O gerente de projeto pode obter dados histricos a partir de uma base de
dados consolidada na empresa que guarde essas informaes.
Soluo:
1) Realize consultas na base de dados;
a. Ao estimar o tamanho total do software, Estimativa do Tamanho Total,
verifique em projetos anteriores como as funcionalidades foram
classificadas quanto complexidade e transaes;
b. Ao estimar o esforo total do software, Estimativa do Esforo Total,
verifique a mdia da produtividade da equipe em projetos anteriores;
c. Ao estimar o custo total do software, Estimativa do Custo Total,
verifique a porcentagem de esforo gasto para cada papel do projeto em
relao ao todo;
106

Contexto Resultante:
Vantagens
o A empresa ter dados consolidados de acordo com seu prprio perfil.
o Com base em dados de projetos anteriores, o gerente de projeto poder
calcular as estimativas com maior preciso.
Desvantagens
o Possibilidade de dbia interpretao dos dados histricos, prejudicando o
clculo das estimativas. Para tanto, a base dos dados histricos necessita
estar consolidada e claramente interpretada.

Racional:
Simplesmente consultar a base de dados no suficiente para melhorar a
preciso das estimativas. necessrio, alm disso, fazer uma anlise criteriosa dos
dados que so realmente relevantes e podem ser considerados no clculo das
estimativas.

Usos Conhecidos:
O CMMI (SEI, 2006), na rea de processo Medio e Anlise, obtm dados
histricos dos resultados provenientes de base de dados e possibilita a anlise dos
dados.
O MPS.BR (SOFTEX, 2009a) no processo de Medio possui a atividade de
anlise dos dados e resultados. As informaes produzidas so usadas para apoiar
decises e para fornecer uma base objetiva para comunicao aos interessados;
Em (VASQUEZ, 2003) utilizado a atividade de Obter Dados Histricos no
processo de estimativa de um projeto de software.

Padres Relacionados:
Os dados histricos so obtidos a partir da coleta prvia de medidas reais, Coleta de
Medidas Reais. Obtenha dados histricos de projetos anteriores para auxiliar na
classificao das funcionalidades da Estimativa do Tamanho do Software. Na
Estimativa de Esforo Total os dados histricos auxiliam na obteno da produtividade
mdia da equipe. Na Estimativa do Custo Total os dados histricos auxiliam na
porcentagem de esforo por atividade.
107

6.4 Consideraes Finais

Este captulo tem por principal objetivo auxiliar os gerentes e lderes de projeto das
MPES a mensurar valores de estimativa de software na fase de planejamento de projeto
de forma padronizada. Alm de prover um processo simples de melhoria da qualidade
ao sugerir a coleta de medidas reais no decorrer do desenvolvimento do software para
apoiar em futuras estimativas e decises estratgicas da empresa.
O Captulo 7 descreve um processo formal de medio simplificado para MPES
baseado nos padres documentados nesse captulo.
108

7 ProMePE: PROCESSO DE MEDIO SIMPLIFICADO BASEADO


EM PADRES PARA MICRO E PEQUENAS EMPRESAS

7.1 Introduo

Este captulo descreve um processo de medio simplificado para as micro e pequenas


empresas (ProMePE) proposto nessa dissertao (ANDRADE; SOUZA, 2009). O
processo foi construdo baseado na linguagem de padres descrita no captulo anterior.
Alm disso, segue as boas prticas previstas pelo PSM para o estabelecimento de um
processo de medio e procurou atender ao conjunto de requisitos elencados no
Captulo 5.
Inicialmente, alguns pontos relacionados ao ProMePE merecem destaque. O
termo simplificado utilizado no nome do processo no empregado para refletir uma
possvel incompletude desse processo. Na verdade, o ProMePE um processo
completo, mas simples, j que o objetivo atender o nicho de mercado das MPES.
Nesse sentido, o processo possui um conjunto de tarefas e medidas para apoiar o incio
do controle quantitativo do processo de desenvolvimento e, assim, se restringe coleta
de medidas voltadas melhor fundamentao da disciplina de gerncia de projetos,
provendo informaes tanto para o clculo de estimativas quanto para coleta de medidas
reais. Portanto, est fora do escopo do ProMePE a preocupao com medidas
relacionadas verificao da qualidade de produtos e processos (medidas de qualidade),
em virtude da imaturidade e demais dificuldades enfrentadas pelas MPES.
Diante do exposto, ao analisar os requisitos levantados para a construo e
implantao de processos nas MPES, verificou-se a necessidade de aplicao dos
padres de estimativas relacionados no captulo anterior dentro do ProMePE. Assim,
nota-se a grande importncia da realizao de estimativas iniciais do projeto para a
definio de medidas de apoio gerencial, dando subsdios para o acompanhamento mais
efetivo do projeto. Nesse sentido, as solues dos padres foram utilizadas no ProMePE
como tarefas a serem executadas pelo gerente de projeto.
O presente captulo est organizado da seguinte forma: a Seo 7.2 descreve
detalhadamente o processo ProMePE, com seus papis, tarefas e artefatos, a Seo 7.3
mostra uma anlise do ProMePE frente aos requisitos definidos anteriormente, a seo
7.4 descreve a aderncia do ProMePE ao PSM e a seo 7.5 descreve as consideraes
finais do captulo.
109

7.2 Descrio do ProMePE

A Figura 7.1 ilustra metamodelo do processo de medio6 do processo de medio,


ProMePE, de acordo com a hierarquia de diviso do processo. Como mostrado, o
ProMePE constitudo de atividades, que por sua vez contm tarefas que podem ser
executadas por um ou mais papis. As tarefas podem ser divididas em etapas e podem
possuir artefatos de entrada e resultarem na produo de um ou mais artefatos de sada.
Os guias, padres e ferramentas do apoio execuo do processo.
O ProMePE, como citado anteriormente, foi elaborado a partir do PSM (Modelo
de Medio de Informao e Modelo de Processo de Medio). As atividades do
ProMePE esto alinhadas com as atividades previstas pelo PSM salvo que, por este
trabalho se tratar da definio de um processo de medio voltado para MPES, as
atividades do PSM foram adaptadas para atender tal restrio de escopo.

Processo de
Medio
1...*
Etapas
1

1*
1*
Papel
Atividade

1
1* Artefato
1*

1
Tarefa
0*
Guias,
Padres e
Ferramentas

Figura 7.1 Metamodelo do Processo ProMePE

A Figura 7.2 ilustra de forma geral o processo ProMePE com suas atividades.
Para a implatano do ProMePE necessrio estabelecer, primeiramente, o
compromisso organizacional que trata de garantir o envolvimento de todos da
organizao na implantao do processo.
Aps o acordo de todos da organizao em relao ao processo de medio,
surge a primeira atividade do ProMePE, denominada de Planejar Medio, onde feita

6
O PSMSE foi modelado utilizando a ferramenta de modelagem de processo EPF Composer (ECLIPSE,
2007).
110

a escolha das medidas a serem coletadas de acordo com a identificao das necessidades
informao do projeto, como essas medida sero coletadas, por quem e em qual
momento dentro do processo.
Logo aps, a atividade Aplicar Estimativas ocorre. O objetivo desta atividade a
realizao das estimativas iniciais do projeto. De posse dos requisitos do projeto, o
gerente de projeto estima tamanho, prazo e custo do projeto. As estimativas esto de
acordo com as solues dos padres descritas no Captulo 6.

Figura 7.2 Diagrama de Atividade do Processo, ProMePE

Em seguida, vem a atividade Aplicar e Analisar Medidas. Essa atividade


responsvel pela coleta, transformao dos dados brutos coletados em dados teis para
serem analisados como forma de apoiar a gerncia dos riscos do projeto.
A ltima atividade pertinente ao processo de medio Avaliar Processo de
Medio, que trata da identificao de reas de melhoria dentro do processo de
medio, sejam elas: a adoo de novas medidas, a apurao de indicadores ou ainda o
maior detalhamento do processo.
A Tabela 7.1 mostra as pr-condies para implantao do ProMePE e como as
atividades esto divididas em tarefas.
111

Tabela 7.1 Detalhe do Processo ProMePE


Pr-Condies
Estabelecer o Compromisso Organizacional
Planejamento de Recursos
Atividades e Tarefas

Nas sees seguintes o ProMePE descrito em maiores detalhes. Para cada


atividade do processo so descritas as suas respectivas tarefas. Cada tarefa possui uma
breve descrio, seguida das etapas para a execuo da tarefa, do papel responsvel e
dos respectivos artefatos de entrada e de sada. Opcionalmente uma tarefa pode possuir
um guia de orientao para sua execuo. O guia de orientao um artefato de apoio e
oferece um conjunto de informaes pr-definidas para auxiliar e facilitar a execuo da
tarefa, alm de possibilitar o reuso das suas informaes.

7.2.1 Pr-Condies: Estabelecer Compromisso Organizacional e Planejar de


Recursos
O objetivo de obter o compromisso organizacional garantir o apoio dos
membros da organizao em todos os nveis e obter o entendimento comum dos
benefcios do programa de medio. Para isso, uma breve apresentao do ProMePE
deve ser realizada para todos os membros da organizao.
A implementao de um programa de medio requer grande mudana cultural,
uma vez que os dados coletados podem ser usados dentro de todos os nveis
hierrquicos da organizao e, assim, algumas pessoas podem se sentirem acuadas, com
receio dos dados serem usados de forma imprpria para avaliar desempenhos
individuais. Cabe ao gerente de projeto divulgar a medio de forma correta e incentivar
o seu uso, mostrando sempre os benefcios da medio para a organizao e para o
maior controle do projeto. nesse momento que o gerente ou consultor responsvel
112

pela implantao do processo obtm o comprometimento da organizao, em especial


da equipe do projeto para dar andamento ao processo de medio.
Alm do comprometimento da organizao importante fazer um planejamento
dos recursos que sero utilizados no processo de medio. Todos os participantes devem
conhecer seus papis e responsabilidades para o cumprimento dos seus deveres dentro
do processo, deve-se estabelecer os demais recursos para implementao do processo de
medio, como os recursos fsicos e de ferramentas, se necessrio.
O tamanho e a estrutura de cada organizao determinam como as
responsabilidades para o processo de medio so definidas. O nmero de pessoas
envolvidas e a alocao de tarefas variam consideravelmente de organizao para
organizao. Dependendo do tamanho e do escopo do projeto, a distribuio de
responsabilidades pode mudar. Todos os responsveis por atividades de medio dentro
do processo devem receber treinamentos apropriados para a correta execuo de suas
atividades.

7.2.2 Atividade Planejar Medio


Esta atividade, ilustrada na Figura 7.3, composta apenas da tarefa Desenvolver Plano
de Medio.

Figura 7.3 - Estrutura da Atividade Planejar Medio, ProMePE

7.2.2.1 Tarefa Desenvolver Plano de Medio


O objetivo da tarefa Desenvolver Plano de Medio prover um mtodo
consistente para identificar as necessidades de informao do projeto, selecionar e
especificar as medidas e integr-las com o projeto tcnico e com o processo de gerncia
atravs da determinao de quais fases do processo as tarefas sero executadas, por
quem e com que frequncia.
113

Etapas
As etapas para execuo da tarefa so:
Identificar e priorizar as necessidades de informaes para auxiliar a
organizao na definio das medidas;
Selecionar e especificar as medidas base e medidas derivadas baseadas nas
necessidades de informao do projeto;
Determinar a freqncia de coleta e anlise dos dados, os responsveis por
cada um e as ferramentas utilizadas;
Determinar os mecanismos de divulgao dos dados, quando necessrios.
Papel
O gerente de projeto o papel principal e nico nessa tarefa. Ele o responsvel
pela definio de quais as medidas que o projeto utilizar dependendo dos seus
objetivos e restries, ou seja, da lista de necessidades do projeto.
Artefato(s) de Sada
Plano de Medio do Projeto: o gerente de projeto desenvolve o plano de
medio com, entre outras informaes, a lista de necessidades do projeto, o
planejamento das medidas que sero coletadas e analisadas (medidas base,
medidas derivadas e indicadores), freqncia da coleta, ferramentas
utilizadas, alocao das pessoas responsveis pela coleta e anlise dos dados
durante o ciclo do projeto.
Guia de Orientao
Plano de Medio de Referncia: plano geral que contm um conjunto de
lista de necessidades e medidas pr-selecionadas para servir de base para a
construo do plano de medio especfico do projeto. O ProMePE prov
este plano de medio para ser instanciado pelos projetos das MPES. O
objetivo ajudar as MPES na construo do plano de medio e possibilitar
sua instanciao (incluso, remoo e adaptao das listas de necessidade e
medidas). Outro objetivo do plano de medio de referncia possibilitar o
reuso de suas informaes dentro da empresa. O plano de medio de
referncia tambm contm outras informaes, tais como os pesos para
contagem da estimativa de esforo e a porcentagem de esforo por papel, por
exemplo. A Tabela 7.2 apresenta a parte do Plano de Medio de Referncia
relacionada lista de necessidades de informao com as possveis medidas
114

que podem ser utilizadas. Demais informaes do Plano de Medio de


Referncia, incluindo os clculos das medidas base e derivadas, encontram-
se no Apndice A.

Tabela 7.2 Mapeamento entre necessidade de informao e medidas base presente no Plano
de Medio de Referncia, ProMePE

Categoria da Informao Necessidade de Informao Medidas Base


Datas do inicio do planejamento
Datas do fim do planejamento
Progresso do Cronograma Quantas tarefas esto atrasadas?
Datas do inicio real
Datas do fim real
Classificao das transaes por complexidade
e atribuio de pesos para cada complexidade
Qual a estimativa de tamanho (FF)
Tamanho
do projeto?
Total de Fatores Tcnicos No Funcionais
(FTNF)
Produtividade da Equipe (PROD)
Qual a estimativa de esforo Estimativa de Tamanho Total (ETT)
Esforo total do projeto comparado com
o realizado? Quantidade total de horas realizadas pela
equipe (ESF_REAL)
Estimativa de Esforo Total (ESF)
Quantidade de Recursos humanos no projeto
Qual a estimativa de prazo total (QtdRD)
Prazo do projeto comparado com o Carga horria diria de cada recurso
realizado? (VlrJTRAB)
Quantidade total de horas realizadas pela
equipe (ESF_REAL)
Estimativa de Esforo Total (ESF)
Porcentagem de Esforo por Papel (P)
Qual a estimativa de custo total
Valor da Hora de Trabalho por Papel
Custo de projeto comparado com o
(VlrHORA)
realizado?
Quantidade total de horas realizadas pela
equipe (ESF_REAL)
Quantidade total de requisitos aprovados
Quantidade de novos requisitos
Quantidade de requisitos modificados
O quo estvel esto os
Estabilidade dos Requisitos Estimativa de esforo para modificao dos
requisitos?
requisitos
Esforo realizado para modificao dos
requisitos
Quantidade total de defeitos
Como est o andamento dos
Defeitos Quantidade de defeitos corrigidos
testes?
Esforo para correo de cada defeito
115

7.2.3 Atividade Aplicar Estimativa


Esta atividade composta por quatro tarefas: Estimar Tamanho, Estimar Esforo,
Estimar Prazo e Estimar Custo. Todas as tarefas, Figura 7.4, so de responsabilidade do
gerente de projeto que pode ter o apoio do analista de sistema para execut-las.

Figura 7.4 Detalhe da Atividade Aplicar Estimativa, ProMePE

7.2.3.1 Tarefa Estimar Tamanho


O tamanho do projeto uma medida que tem como base os requisitos do projeto,
portanto, como pr-condio para estimar o tamanho do projeto, alguns requisitos
precisam ser levantados, anteriormente. Estes requisitos podem estar no formato,
por exemplo, de caso de uso ou outline de caso de uso. Para estimar o tamanho do
projeto necessrio contabilizar as funcionalidades. A contabilizao realizada
atravs do clculo do nmero de transaes por caso de uso.
Etapas
Para calcular o valor do tamanho do projeto, o gerente de projeto tem que
realizar as seguintes etapas:
Calcular os Fatores Funcionais (FF).
Os Fatores Funcionais apresentam os requisitos funcionais
exigidos pelo cliente para execuo do projeto. Logo, para obter tais
fatores, o gerente de projeto tem que:
116

a. Separar o projeto por funcionalidades e determinar a quantidade de


transaes de acordo com os seguintes grupos:
i. Transaes de entrada de dados por parte do
usurio com persistncia na base de dados (TED);
ii. Transaes de sada de dados da base para fornecer
informaes ao usurio (TSD);
iii. Transaes de consulta, onde o usurio entra com
os dados, e solicita uma resposta da base de dados (TCD);
iv. Transaes externas, mantidas por outra aplicao
(TEX);
v. Transaes de persistncia de dados (TPD). Para
cada TEX contabilizada uma TPD;
b. Para cada transao, de cada grupo, classifique-o de acordo com sua
complexidade, Tabela 7.3 (vide Plano de Medio de Referncia, seo
medidas derivadas), atribuindo complexidade baixa, mdia ou alta de
acordo com a experincia da equipe na execuo daquele tipo de
transao.
c. Atribuir um peso para cada nvel de complexidade7 de cada grupo. Cada
peso representa o grau de dificuldade de desenvolvimento de cada tipo
de transao. Atribua peso menor s transaes que possuem
complexidade baixa, peso intermedirio s que possuem complexidade
mdia e peso maior s que possuem alta, Tabela 7.3. Verificar os dados
histricos para auxiliar na classificao das transaes e calibragem dos
pesos;

7
Para classificar as transaes pode-se considerar a complexidade relativa de acordo com a experincia
da equipe no desenvolvimento de determinada transao.
117

Tabela 7.3 Guia de Orientao para Classificao das Transaes, ProMePE


Grupos de Complexidade Quantidade Peso
Transaes
Baixa Q1 P1
TED Mdia Q2 P2
Alta Q3 P3
Baixa Q4 P4
TSD Mdia Q5 P5
Alta Q6 P6
Baixa Q7 P7
TCD Mdia Q8 P8
Alta Q9 P9
Baixa Q10 P10
TEX Mdia Q11 P11
Alta Q12 P12
Baixa Q13 P13
TPD Mdia Q14 P14
Alta Q15 P15

d. Calcular os Fatores Funcionais (FF) de acordo com a frmula a seguir:


15
FF = Qi Pi , onde,
i =1

Qi = Quantidade de Transaes
Pi = Peso de cada grupo de transaes de acordo com sua
complexidade
Calcular os Fatores Tcnicos No-Funcionais (FTNF).
Os Fatores Tcnicos No-Funcionais so obtidos a partir dos
requisitos no funcionais do sistema. Logo, para obter tais fatores:
a. Classificar o projeto quanto s caractersticas abaixo, de
acordo com a 0. Cada caracterstica deve ser avaliada com notas: 0
no requerida, 3 requerida parcialmente, 5 requerida
completamente (MONTEIRO, 2005) (IFPUG, 1999). Presente no
Plano de Medio de Referncia, seo medidas derivadas,
conforme Tabela 7.4.
b. Calcular os Fatores Tcnicos No- Funcionais de acordo
com a frmula:
10
FTNF = 0.65 + Ni 0.01 , onde,
i =1
Ni = Nota de cada caracterstica
118

Tabela 7.4 Caractersticas No Funcionais, ProMePE


Caracterstica Nota
Processamento Distribudo N1
Desempenho N2
Eficincia do Usurio N3
Processamento Complexo N4
Reusabilidade N5
Facilidade de Instalao N6
Usabilidade N7
Portabilidade N8
Facilidade de Manuteno N9
Concorrncia N10

Calcular a Estimativa do Tamanho Total (ETT)


Calcular o Tamanho Total do Software atravs da frmula:
ETT = FF FTNF , onde:
FF = Fatores Funcionais
FTNF = Fatores Tcnicos No Funcionais
Papel
O gerente de projeto deve estimar o tamanho do projeto de acordo com os
requisitos levantados at o momento. Por acompanhar o projeto desde o incio com
o cliente, o gerente de projeto detm boa parte do conhecimento para executar tal
tarefa. Os analistas de sistemas e desenvolvedores devem participar do processo de
contagem das transaes para transmitir seu conhecimento no negcio e no
desenvolvimento de transaes com complexidade similares.
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm entre outras informaes as
necessidades de informaes, medidas base, medidas derivadas e indicadores
a serem utilizadas no projeto. Entre as medidas est, por exemplo, a do
tamanho do projeto. medida que a MPES adquire maturidade, esta poder
atualizar o Plano de Medio de Referncia para retratar novas informaes
e mais precisas em relaes s medidas e indicadores;
Outline de Caso de Uso ou Requisitos Funcionais: os requisitos do projeto
podem estar descritos no formato de caso de uso ou de como funcionalidades
pontuais (requisitos funcionais). No formato de caso de uso, uma forma de
estimar o tamanho o mais cedo possvel para se ter uma previso do tamanho
a utilizao de outline de caso de uso. Entende-se por outline de caso de
uso, um caso de uso com completa descrio do fluxo bsico e fluxos
119

alternativos ou subfluxos identificados. Os fatores funcionais da contagem


do tamanho so obtidos atravs da contagem de transaes dos requisitos;
Requisitos No-Funcionais: so os requisitos tcnicos do projeto. Os
requisitos no funcionais so utilizados para a contagem dos fatores tcnicos
no funcionais.
Artefato(s) de Sada
Estimativa do Tamanho Total (ETT): valor que contm o tamanho do projeto
em relao s suas funcionalidades levantadas at o momento.
Guia de Orientao
Plano de Medio de Referncia, seo Medidas Derivadas: plano que
poder ser instanciado para cada projeto e contm os pesos para a
classificao das transaes em baixa, mdia e alta.

7.2.3.2 Tarefa Estimar Esforo


De posse do tamanho do projeto, o Gerente de Projeto ir estimar o esforo
necessrio para execut-lo. O esforo do projeto calculado em horas trabalhadas e
depende da quantidade mdia de horas trabalhadas por tamanho do projeto, ou seja,
este valor depende da produtividade da equipe.
Etapas
A seguir, as etapas para a execuo da tarefa Estimar Esforo:
Calcular a Estimativa de Esforo Total (ESF) em horas:
ESF ( horas ) = PROD ETT , onde,

PROD = Produtividade,
ETT = Estimativa do Tamanho Total
Papel
O gerente de projeto o responsvel por calcular o esforo total em horas de
trabalho para execuo do projeto.
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm as necessidades de
informao, as medidas base, medidas derivadas e indicadores a serem
utilizadas no projeto. Entre as possveis medidas est o tamanho do projeto,
o esforo e uma breve descrio de como calcul-las, por exemplo;
120

Estimativa de Tamanho: valor do tamanho do projeto de acordo com suas


funcionalidades;
Produtividade: a produtividade um fator que depende de cada empresa e
geralmente calculado atravs da quantidade mdia de horas trabalhadas por
tamanho do projeto (ETT). Geralmente a produtividade obtida de atravs
de dados histricos e experincias em projetos anteriores.
Artefato(s) de Sada
Estimativa de Esforo (ESF): valor estimado em horas de trabalho para
execuo do projeto.

7.2.3.3 Tarefa Estimar Prazo


A tarefa Estimar Prazo tem por finalidade estimar o prazo em dias para
execuo do projeto. Para estimar o prazo, o gerente de projeto deve levar em
considerao, alm do esforo total do projeto em horas, a quantidade de recursos
disponveis e o valor da jornada de trabalho dos profissionais envolvidos no projeto.
Etapas
A seguir as etapas para execuo da tarefa:
Calcular a Estimativa de Prazo Total do Software (EPRZ)8:
ESF
EPRZ = , onde:
n

QtdRD VlrJTRAB
i =1
ESF = Esforo Total do Projeto
QtdRD = Quantidade de Recursos Humanos Disponveis
VlrJTRAB = Carga horria de trabalho por dia
Papel
O responsvel por exercer essa tarefa o gerente de projeto. O gerente deve
calcular o prazo total de execuo do projeto, em dias, a partir do esforo estimado,
da quantidade em horas da jornada de trabalho da equipe e da quantidade de
profissionais disponveis.

8
Esta frmula foi alterada em relao ao que est descrito no padro Estimar Esforo.
121

Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm a lista de medidas
especficas para o projeto e o momento que as medidas devem ser coletadas.
O gerente deve consultar o plano para saber informaes sobre o clculo do
prazo do projeto, por exemplo;
Quantidade de Recursos Humanos Disponveis (QtdRD): quantidade de
profissionais disponveis para trabalhar no projeto. a contabilizao do
tamanho da equipe. O gerente de projeto deve verificar quais os recursos que
esto disponveis o tempo todo (full time) e quais os que esto parcialmente
alocados (part time) e contabilizar atravs da quantidade horas/dia
disponveis;
Carga Horria de Trabalho por Dia (VlrJTRAB): verificar junto equipe ou
ao setor de recursos humanos qual a jornada de trabalho dos profissionais, ou
seja, quantas horas por dia eles trabalham ou esto alocados no projeto;
Estimativa de Esforo: estimativa do esforo, em horas, para execuo do
projeto.
Artefato(s) de Sada
Estimativa de Prazo: estimativa, em dias, para execuo do projeto. Prazo
estimado para concluso de todo o projeto.

7.2.3.4 Tarefa Estimar Custo


A tarefa Estimar Custo tem por objetivo estimar quanto o desenvolvimento do
projeto vai custar para a empresa. O custo calculado de acordo com o valor da
hora de trabalho de cada profissional ou papel exercido dentro do projeto.
Etapas
Para calcular o custo do projeto, o gerente de projeto dever executar as
seguintes etapas:
Calcular, em porcentagem, o esforo necessrio para cada papel no projeto.
Para isso, verifique, se possvel, dados histricos em projetos anteriores. O
Plano de Medio de Referncia do ProMePE, seo medidas derivadas,
pr-define um percentual de esforo por papel;
Calcular o custo total do desenvolvimento do projeto, da seguinte forma:
122

n
CUSTO = ESFxP ( Papel ) xVlrHORA ( Papel ) , onde:
i =1

ESF = Estimativa do Esforo Total


P = Porcentagem de esforo necessrio para cada Papel
VlrHORA = Valor da Hora de Trabalho por profissional
Papel
O gerente de projeto o responsvel por estimar o custo interno do projeto. Com
o custo do projeto, o gerente pode negociar melhor com o cliente e ajustar a margem
de lucro da empresa.
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm as mtricas para clculo da
estimativa de esforo e o momento que elas precisam ser executadas;
Estimativa do Esforo: estimativa do esforo, em horas, para execuo do
projeto;
Valor da hora de trabalho: valor, em moeda local, da hora de trabalho
exercido por cada papel do projeto.
Artefato(s) de Sada
Estimativa do Custo: estimativa de custo interno do projeto para a empresa.
Guia de Orientao
Plano de Medio de Referncia, seo medidas derivadas: plano de
referncia que contm o percentual de esforo necessrio para cada papel,
Tabela 7.5. O percentual de esforo para cada papel apenas uma orientao
inicial para o clculo do custo do projeto e deve ser atualizado ao final de
cada projeto com os dados do esforo real para cada papel de acordo com o
perfil dos profissionais da empresa ou ainda, deve ser analisado
historicamente na empresa qual o esforo desempenhado para cada papel.

Tabela 7.5 Percentual de esforo por papel, presente no plano de medio de referncia, aba
medidas derivadas, ProMePE, adaptado de (PADUA, 2009).
Papel Percentual de Esforo
Gerente de Projeto 10 15%
Analista de Sistemas 15 20 %
Projetista/Arquiteto 15 20%
Desenvolvedor 25 30 %
Testador 10 15%
123

7.2.4 Atividade Aplicar e Analisar Medidas

A atividade Aplicar e Analisar Medidas composta por duas tarefas: Executar Medio
e Analisar Medio, Figura 7.5.

Figura 7.5 Detalhe da Atividade Aplicar e Analisar Medidas, ProMePE

7.2.4.1 Tarefa Executar Medio


A tarefa Executar Medio tem por finalidade a execuo dos procedimentos de
coleta de dados, ou seja, tornar os dados disponveis para serem capturados e
armazenados. A presente tarefa pr-requisito para a tarefa seguinte Analisar
Medio, Figura 7.5. A tarefa Executar Medio envolve a coleta de dados de
diversas fontes, identificadas no Plano de Medio, e armazenamento dos dados em
local acessvel para posterior anlise.
Etapas
Coletar os dados de vrias fontes que foram identificadas no Plano de
Medio;
124

Preparar os dados para anlise, realizar os clculos necessrios para


consolidao dos dados coletados. Verificar quais dados deixaram de ser
coletados e se houve algum erro no procedimento de coleta;
Armazenar os dados para anlise. Disponibilizar os dados para que o
responsvel possa analis-los e realizar as recomendaes.
Papel
Todos os papis previstos no Plano de Medio so responsveis pela coleta dos
dados. Os analistas de sistemas, arquitetos, desenvolvedores e testadores devem
reportar as medidas definidas no Plano de Medio. O gerente de projeto o
responsvel pela preparao dos dados para anlise e armazenamento.
Artefato(s) de Entrada
Plano de Medio: contm as medidas a serem coletadas, a frequencia de
coleta, o responsvel, a fase de desenvolvimento, a funo de medio e a
ferramenta utilizada.
Artefato(s) de Sada
Documento de Coleta e Anlise dos Dados: local onde as medidas coletadas
sero armazenadas e onde ocorre a realizao dos clculos dos valores das
medidas. Esse documento pode ser substitudo por alguma ferramenta que
automatize a coleta e prepaparao para a anlise dos dados, caso necessrio.

7.2.4.2 Tarefa Analisar Medio


Na tarefa Analisar Medio, as medidas so analisadas para prover retorno
efetivo para apoiar as decises gerenciais. Neste momento, o gerente de projeto deve
comparar o que foi estimado com o que foi realizado. Informaes de desempenho
do projeto so consideradas pelo gerente de projeto nas tomadas de decises e com
isso, problemas podem ser identificados no decorrer do projeto possibilitando sua
preveno e resoluo o quanto antes.
Etapas
A seguir as etapas da tarefa:
Comparar dados estimados com dados coletados (medidas reais);
Usar os indicadores existentes para apoiar a anlise dos dados coletados;
125

Tomar as decises para o projeto tendo como base as informaes, resultado


da medio e dos indicadores9;
Comunicar as informaes e as decises da anlise para os principais
interessados.
Papel
Em marcos de coleta e anlise das medies, o gerente de projeto analisa as
medies para ajustar os valores dos indicadores e toma as decises para o
progresso do projeto.
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm o planejamento da medio,
como a freqncia de anlise dos dados, o responsvel, a fase do
desenvolvimento em que anlise deve ser realizada, os critrios de deciso
(indicadores) e os mecanismos de divulgao.
Estimativa de Tamanho, Custo, Esforo e Prazo: as estimativas iniciais do
projeto servem de comparao com os dados coletados para analisar o desvio
entre o previsto e real;
Documento de Coleta e Anlise dos Dados: documento que contm os dados
coletados e calculados previstos no Plano de Medio;
Artefato(s) de Sada
Documento de Coleta e Anlise dos Dados: documento com grficos e
tabelas que retratam a anlise das medidas de acordo com os critrios de
deciso definidos no Plano de Medio para auxiliar nas tomadas de decises.

7.2.4.3 Atividade Avaliar Processo de Medio

A tarefa Avaliar Medio, nica que compe a corrente atividade, Figura 7.6, tem por
objetivo, entre outros, avaliar as medidas, indicadores e resultados das anlises ao final
do projeto.

9
Os indicadores sero calibrados ao final de cada projeto.
126

Figura 7.6 Detalhe da Atividade Avaliar Processo Medio, ProMePE

7.2.4.4 Tarefa Avaliar Medio


A tarefa Avaliar Medio tem por finalidade a avaliao do processo de medio
e executada ao final do projeto. A avaliao deve levar em considerao a
confiabilidade dos dados analisados, a necessidade de retirada ou de acrscimo de
medidas e se o propsito da realizao da medio foi atingido. Esta tarefa tem um
papel importante, pois ao final do projeto, o gerente avalia a efetividade do Plano de
Medio, ou seja, o quo eficiente foi o planejamento das medies e os benefcios
ou malefcios (excesso de burocracia, dados no efetivos e anlise errnea dos
dados) trazidos ao projeto. O gerente documenta tambm as lies aprendidas,
identifica e implementa as melhorias ao processo de medio.

Etapas
A seguir esto descritas as etapas para execuo da tarefa:
Determinar a eficcia dos produtos medidos, ou seja, avaliar o processo de
medio em relao performance (processo oneroso), concordncia e
maturidade;
127

Atualizar o Plano de Medio de Referncia para calibrar as medidas,


calibrar os pesos das estimativas, ajustar o percentual do esforo por papel e
ajustar os indicadores;
Identificar aes de melhoria, que podem ser feitas atravs de reunies de
feedback;
Atualizar a base de medies com as lies aprendidas;
Elaborar Relatrio de Avaliao do Processo.
Papel
O gerente de projeto o responsvel principal por esta tarefa de fechamento do
projeto em relao ao processo de medio. Para execut-la ele pode ter como apoio
alguns membros da equipe do projeto, como analistas e desenvolvedores para que
eles dem o feedback em relao coleta das medidas.
Artefato(s) de Entrada
Plano de Medio de Referncia: plano que contm a consolidao de todas
as medidas base, medidas derivadas e indicadores utilizados durante os
projetos da empresa.
Plano de Medio do Projeto: plano atual do projeto, especfico para o
projeto e que inicialmente adaptado a partir do plano de medio de
referncia;
Documento de Coleta e Anlise dos Dados: documento com os grficos e
tabelas que retratam a anlise dos dados inclusive com as comparaes entre
o estimado e o realizado.
Artefato(s) de Sada
Plano de Medio de Referncia: plano atualizado para servir de base (reuso)
para projetos futuros. Na primeira vez que o ProMePE executado dentro da
empresa, o Plano de Medio de Referncia contm um conjunto de medidas
previamente selecionadas pelo ProMePE. medida que novos projetos da
empresa executem o ProMePE, o Plano de Medio de Referncia
atualizado com as novas medidas e indicadores, possibilitando, assim, o
reuso de suas informaes nos projetos seguintes.
Relatrio de Avaliao do Processo: relatrio crtico em relao ao processo
de medio. Aqui deve estar descrito o que funcionou e o que no funcionou
no processo de medio;
128

7.3 Anlise do ProMePE frente aos Requisitos

No Captulo 5 foi definido um conjunto de requisitos para construo de um


processo de medio para MPES. Abaixo,Tabela 7.6, encontra-se uma rpida anlise do
ProMePE frente aos requisitos levantados indicando o atendimento de cada um dos
requisitos pelo processo.

Tabela 7.6 Anlise do ProMePE frente aos Requisitos


Atendimento Anlise do Atendimento
Categoria: Requisitos para Definio de Processo de Medio para MPES
RDef.1 Compromisso Organizacional
O ProMePE suporta esse requisito atravs da pr-condio para Obter Compromisso
Organizacional onde todos da empresa devem conhecer o processo e estar
Sim
comprometidos a executar suas devidas atividades, alm do planejamento dos
recursos do processo de medio.
RDef.2 - Planejamento das Medies
Atravs da atividade Planejar Medio onde utilizado da lista de necessidades do
Sim projeto ou da empresa para obter as medidas base e medidas derivadas do processo.
Alm disso, so definidos os procedimentos de coleta, anlise e divulgao dos dados.
RDef.3 Reuso e Adaptao dos Planos de Medio
O ProMePE possui um Plano de Medio de Referncia com um conjunto base de
lista de necessidades, medidas base, medidas derivadas, sugesto de coleta e anlise
dos dados. Esse Plano de Medio de Referncia pode ser instanciado e adaptado pela
Sim empresa quando da implantao do processo. Posteriormente, a empresa pode definir
o seu Plano de Medio de Referncia para ser reutilizado completamente nos
projetos ou ainda com pequenas adaptaes, o que diminui bastante o esforo
necessrio para constru-lo.
RDef.4 Coleta e Armazenamento dos Dados
O ProMePE prev na tarefa Executar Medio que os dados sejam coletados e
armazenados em local apropriado para anlise. O processo tambm prev a formao
Sim
de base de dados histrica para posterior calibragem dos critrios de deciso,
indicadores.
RDef.5 Anlise dos Dados Coletados
Atravs da tarefa Analisar Medio, os dados so analisados de acordo com os
critrios de deciso previstos no Plano de Medio e com isso possibilita a tomada de
Sim deciso pelos gerentes. O Plano de Medio prev tambm a freqncia de anlise
dos dados, a fase do desenvolvimento que deve ocorrer a anlise, a pessoa
responsvel e a ferramenta utilizada.
RDef.6 Comunicao dos Resultados da Medio
Sim Uma das etapas da tarefa Analisar Medio a divulgao peridica do resultado da
129

anlise para os principais interessados (equipe e alta gerncia, por exemplo). O Plano
de Medio tambm prev o planejamento dos mecanismos de divulgao dos
resultados.
RDef.7 Avaliao do Programa de Medio
O ProMePE suporta a tarefa Avaliar Processo de Medio onde realizado uma
anlise crtica do programa de medio do projeto com as lies aprendidas
Sim
provenientes da execuo do processo. Alm disso, as medidas podem ser calibradas
para servir de base histrica para os prximos projetos.
Categoria: Requisitos para Implantao de Processo para MPES
RImpl.1 Custo Compatvel
O ProMePE foi projetado com tarefas e artefatos que podem ser executados sem que a
empresa invista em ferramentas caras ou em treinamentos. O custo para implantar o
ProMePE diz respeito ao esforo necessrio para gerenciamento das medidas, por
Parcial parte do gerente, custo esse que est embutido dentro da implantao de qualquer
processo, ou seja, a empresa possui um maior esforo para ter um processo definido,
mas, em compensao, ganha os benefcios do desenvolvimento de software de forma
controlada e minizando os riscos.
RImpl.2 Rpida Implantao e Entendimento
O ProMePE tenta ser auto-explicativo, mostrando claramente como as tarefas devem
ser executadas e como as medidas devem ser calculadas e portanto pretende-se que o
Parcial
esforo necessrio para implant-lo e execut-lo seja compatvel com a realidade das
MPES.
RImpl.3 Alto Grau de Flexibilidade
O ProMePE prope uma sequncia de atividades e tarefas que precisam ser
executadas para implantao de um processo de medio dentro da empresa. Algumas
tarefas, como as de estimativas, por exemplo, podem no ser executadas, porm isso
Parcial pode acarretar prejuzo em relao ao reuso das informaes contidas no Plano de
Medio de Referncia e em relao comparao do planejado com o efetivamente
realizado. A flexidade do ProMePE no est nas atividades, mas sim no conjunto de
medidas que podem ser definidas de acordo com o perfil de cada empresa.
RImpl.4 Quantidade de Documentao Compatvel
O ProMePE prope um conjunto mnimo de artefatos cujo papel principal para
execuo o gerente de projeto. Por possibilitar o reuso do Plano de Medio e do
Documento de Coleta e Anlise dos Dados, o ProMePE foi construdo com o intuito
Sim de minimizar a quantidade de documentos. Um fato que deve ser levado em
considerao que dependendo da quantidade de medidas definidas no Plano de
Medio, os documentos podem se tornar mais complexos e consequentemente mais
onerosos para a empresa.
RImpl.5 Voltado para os Objetivos de Negcio
Sim O ProMePE foi construdo utilizando da abordagem top-down, onde a definio das
130

medidas realizada a partir da lista de necessidades da empresa. Na tarefa Planejar


Medio, o gerente de projeto deve fazer um levantamento de quais informaes
merecem ser medidas para trazer dados concretos para a empresa de acordo com seu
objetivo de negcio.
RImpl.6 Prticas Reconhecidas Internacionalmente
O ProMePE foi construdo tendo como base o PSM. O PSM por sua vez foi
Sim formalizado como um padro atravs da ISO 15939 e serviu de base para definio do
processo de Medio tanto do CMMI, como do MPS.BR.

De acordo com a anlise do ProMePE frente aos requisitos pode-se observar que
o ProMePE atende de forma integral maioria dos requisitos e de forma parcial a uma
minoria.

7.4 Mapeamento PSM e ProMePE

A seguir, Tabela 7.7, sero descritas como foi realizado o mapeamento entre o Modelo
de Processo de Medio do PSM e o Processo de Medio, ProMePE, aqui proposto,
para cada uma das atividades consideradas no Modelo de Processo de Medio do PSM.
O objetivo desse mapeamento mostrar que o processo aqui proposto, o
ProMePE, adere integralmente ao Modelo de Processo de Medio PSM.

Tabela 7.7 Mapeamento PSM e ProMePE


Atividades do Modelo de Processo de Medio Como foram atendidas no ProMePE
do PSM
Planejar Medio O ProMePE possui a atividade Planejar Medio
Identificao das necessidades de informaes, que possui um Plano de Medio de Referncia
priorizao e seleo das medidas e planejamento com um conjunto base de medidas bsicas e
de como os dados sero coletados e armazenados; derivadas. As medidas foram pr-definidas com o
objetivo de dar apoio s atividades gerenciais.
Algumas medidas foram obtidas atravs da
linguagem de padres de estimativas
documentados;
Executar Medio O ProMePE possui duas atividades: Aplicar
Coletar e processar os dados e analisar os dados e Estimativa e Aplicar e Analisar Medidas. A
transform-los em indicadores; primeira se refere apenas ao clculo das
estimativas, enquanto que a segunda se refere
coleta de medidas reais e anlise comparativa com
o estimado. O gerente de projeto analisar as
medidas e tomar as decises;
131

Avaliar Medio O ProMePE possui a atividade de Avaliar Processo


Avaliao das medidas: casos de sucesso, de de Medio onde todo o processo de medio
fracasso e propor melhorias; avaliado, incluindo as medidas coletadas. As lies
aprendidas so discutidas e ocorre uma atualizao
dos indicadores e da base histrica para alimentar a
construo de estimativas mais prximas
realidade;
Estabelecer Compromisso Organizacional Os responsveis pela organizao devem ser os
Obteno do comprometimento da organizao principais patrocinadores do processo de medio e
com o processo de medio, a disponibilizao de devem disponibilizar os recursos necessrios para
recursos e infra-estrutura organizacional e tal finalidade. Para tal o ProMePE colocou como
definio de responsabilidades. pr-condio para a implantao de um processo de
medio o engajamento da alta gerncia e o
planejamento dos recursos.
Processos Tcnicos e Gerenciais Os gerentes operam, deste a atividade de
planejamento, com as necessidades de informao
para a definio das medidas, na coleta dos dados
junto equipe e ao analisar os indicadores e tomar
as decises.

7.5 Consideraes Finais

Neste captulo foi apresentado o ProMePE, um processo de medio de software


simplificado para MPES. O processo proposto formado por um conjunto de tarefas,
artefatos e guias de apoio para a implantao de um processo sistemtico e orientado
necessidade do projeto podendo atuar de forma integrada ao processo de
desenvolvimento dos sistemas das MPES.
Aqui tambm foi realizado uma anlise do ProMePE frente aos requisitos e ao
PSM. Em relao aos requisitos, observou-se que o ProMePE atende integralmente
maioria dos requisitos e de forma parcial uma minoria. O atendimento integral de todos
os requisitos s poder ser avaliado quando o ProMePE for implantado de forma
sistemtica nas MPES e calculado o esforo de sua implantao e avaliao concreta em
relao a esses requisitos. Em contrapartida, o ProMePE adere integralmente ao PSM,
pois foi construdo seguindo as boas prticas recomendadas pelo PSM. A Figura 7.7
mostra uma viso geral do ProMePE com suas atividades, tarefas e artefatos de entrada
e sada.
132

Pr-Condies
Estabelecer o Compromisso Organizacional
Planejamento de Recursos
Atividade Tarefa Artefato de Entrada Artefato de Sada
Planejar Desenvolver Plano de
Plano de Medio
Medio Medio
Outline de Caso de Uso
Estimativa de
Estimar Tamanho Plano de Medio
Tamanho
Requisitos No-Funcionais
Estimativa de Tamanho
Estimativa de
Estimar Esforo Produtividade
Esforo
Plano de Medio
Estimativa de Esforo
Aplicar
Quantidade de Recursos
Estimativa Estimativa de
Estimar Prazo Humanos
Prazo
Carga Horria de Trabalho
Plano de Medio
Estimativa de Esforo
Valor da Jornada de Estimativa de
Estimar Custo
Trabalho Custo
Plano de Medio
Plano de Medio
Estimativa de Tamanho Documento de
Executar Medio Estimativa de Esforo Coleta e Anlise de
Aplicar e
Estimativa de Prazo Dados
Analisar
Medidas Estimativa de Custo
Documento de
Documento de Coleta e
Analisar Medio Coleta e Anlise de
Anlise de Dados
Dados
Plano de Medio
Plano de Medio
Plano de Medio de
Avaliar Processo de Referncia
Avaliar Medio Referncia
de Medio Relatrio de
Documento de Coleta e
Avaliao
Anlise de Dados
Figura 7.7 Viso Geral do ProMePE

O captulo seguinte mostra um estudo de caso da aplicao do ProMePE em um


projeto de uma MPES cearense.
133

8 ESTUDO DE CASO: APLICAO DO ProMePE EM UMA MICRO E


PEQUENA EMPRESA DE SOFTWARE

8.1 Introduo

Este captulo apresenta e discute uma aplicao do processo ProMePE em um projeto


real de software em uma micro e pequena empresa (MPES) de desenvolvimento de
software cearense. A aplicao do ProMePE em uma MPES possui os seguintes
objetivos principais:
Avaliar a completude do processo, ou seja, se o ProMePE possui todos os
passos necessrios para a implantao de um processo de medio;
Possibilitar a avaliao da necessidade de realizao de alguns ajustes no
ProMePE.
De forma secundria, podem-se destacar os seguintes objetivos:
Gerar dados quantitativos para a empresa e assim possibilitar uma anlise
real do andamento do projeto analisado. Espera-se com esse objetivo que a
empresa alcance os benefcios de um programa de medio para as tomadas
de deciso;
Exemplificar os artefatos do ProMePE para melhor entendimento do
processo ao descrever detalhadamente como o processo foi implantado na
empresa.
Para isto, todas as atividades pertinentes ao processo ProMePE foram executadas
e analisadas de acordo com potencias facilidades e dificuldades para implantao do
processo. Desta forma, a abordagem utilizada para aplicao do processo foi dividida
nas seguintes etapas:
Identificao do perfil da empresa onde o estudo de caso foi realizado, o que
inclui:
o Caracterizao do ambiente, no sentido de enquadr-la dentro do
escopo das MPES onde o ProMePE adequado;
o Caracterizao do processo de desenvolvimento da empresa para
mostrar o nvel de maturidade da empresa e a viabilidade de
aplicao do ProMePE;
134

o Entrevista com os gerentes de projetos da empresa para entender


como eles gerenciam seus projetos e obter informaes concretas das
dificuldades e oportunidades de melhoria;
Aplicao do ProMePE a um projeto especfico da empresa, o que inclui a
caracterizao do projeto e a execuo de todas as atividades do processo;
Avaliao da implantao do ProMePE no projeto com as dificuldades
enfrentadas e os benefcios obtidos, discusso crtica.
Este captulo est organizado da seguinte forma: a Seo 8.2 descreve o perfil da
empresa atravs da caracterizao do ambiente, processo de desenvolvimento e
entrevista com os gerentes de projetos, a Seo 8.3 detalha a aplicao do ProMePE na
MPES, a Seo 8.4 realiza uma avaliao crtica da implantao do processo e a seo
8.5 mostra as consideraes finais do captulo.

8.2 Perfil da Empresa

A aplicao do ProMePE foi realizada no grupo de Redes de Computadores, Engenharia


de Software e Sistemas (GREat) (PORTAL GREAT, 2009), do departamento de
Computao (DC) da Universidade Federal do Cear (UFC), que por conta da sua
atuao em projetos de pesquisa e desenvolvimento (P&D), pode ser caracterizado
como uma empresa de desenvolvimento de software. O GREat foi fundado em 2002 e
composto por funcionrios e estudantes de graduao e ps-graduao da Universidade
Federal do Cear (UFC) e de outras Instituies de Ensino Superior (IES). O grupo
desenvolve pesquisas e projetos de P&D em parceria com outras instituies de ensino e
empresas atravs da Lei de Informtica (Lei 10.176). O perfil dos clientes do Great so
empresas multinacionais que firmam acordo com o grupo atravs da Lei de Informtica.
O escopo de atuao do GREat envolve a pesquisa e desenvolvimento de
solues nas reas de redes de computadores, engenharia de software e de sistemas.
Essas solues so desenvolvidas mediante projetos de P&D prprios ou projetos
especficos para clientes e so caracterizadas pelo desenvolvimento de aplicaes para
uso Desktop, Web e para dispositivos mveis em diversas linguagens de
desenvolvimento, como JAVA, .NET, PHP, entre outros.

8.2.1 Caracterizao do Ambiente


Em relao equipe, o GREat composto por cerca de 45 pessoas que
trabalham em projetos de P&D em parceria com empresas atravs da lei de informtica.
135

O GREat possui atualmente 7 projetos em execuo, destes, 5 so projetos em


parceria com empresas atravs da lei de informtica e 2 so projetos de pesquisas
prprios. Cada projeto do GREat composto por um coordenador (pesquisador), um
gerente de projeto, analistas e programadores.
Como definido pelo Ministrio de Cincia e Tecnologia (MCT) uma MPES
possui at 50 pessoas, portanto, nota-se que o GREat se enquadra como uma tpica
MPES e assim est apto para a aplicao do ProMePE.

8.2.2 Processo de Desenvolvimento


Com relao ao processo de desenvolvimento foi verificado que o grupo no possui um
processo de desenvolvimento consolidado. De acordo com as caractersticas de cada
projeto a equipe escolhe o processo de desenvolvimento a ser seguido. Em muitos
casos, o processo de desenvolvimento exigido, via contrato, pela empresa que est
adquirindo o software. Alguns projetos utilizam a metodologia de desenvolvimento
cascata, outros utilizam o modelo iterativo e incremental e outros utilizam metodologias
geis como o Scrum (SCHWABER, 2004).
Em virtude disso, observa-se que a empresa no possui maturidade no processo
de desenvolvimento, apresentando algumas dificuldades tpicas de MPES. O fato da
empresa no possuir maturidade no processo de desenvolvimento no inviabiliza a
aplicao do ProMePE em projetos da empresa, principalmente por que o ProMePE foi
construdo pensando nessas dificuldades e no exige, obrigatoriamente, que o processo
de desenvolvimento esteja consolidado ou maduro.

8.2.3 Entrevista com os Gerentes de Projetos


Foram realizadas entrevistas com cinco gerentes de projetos do GREat a fim de coletar
informaes acerca dos projetos, como a utilizao de estimativas, de medidas, de
ferramentas de acompanhamento e controle do andamento do projeto, controle de
defeitos, entre outros. A Figura 8.1 exibe o grfico que retrata o resultado da entrevista
com os gerentes de projetos.
De acordo com o grfico possvel notar a instabilidade no processo de
desenvolvimento no grupo. Alguns gerentes controlam o projeto mais efetivamente do
que outros. Pode-se observar tambm a ausncia de medidas sistemticas e com foco
especfico durante o processo de desenvolvimento. Alguns gerentes ainda controlam
apenas o esforo estimado versus o realizado. Apesar da maioria dos gerentes utilizarem
136

ferramentas para controlar os defeitos, no h um controle efetivo da quantidade de


defeitos por tamanho do projeto, ou ainda a porcentagem de esforo necessrio para
corrig-los. As ferramentas so utilizadas apenas para o cadastro do defeito e delegao
da atividade de correo para algum desenvolvedor.

Resultado da Entrevista

3 3

0 0

Realiza Realiza Realiza Gerencia os Utiliza Utiliza outras


estimativa de controle do estimativa de defeitos ferramenta de medidas
esforo esforo tamanho do controle do
baseado na estimado x projeto andamento do
experincia realizado projeto

Figura 8.1 Resultado da Entrevista com os Gerentes de Projeto

Assim, observou-se a ausncia de um processo de medio para padronizar o


clculo de estimativas, a coleta de medidas de valor para o projeto e permitir a anlise
dos dados coletados para ajudar no acompanhamento do projeto. Observou-se tambm
que diante dos atrasos enfrentados nos projetos do Great, o mesmo enfrenta problemas
no clculo das estimativas.

8.3 Aplicao do ProMePE

Dentre os cinco projetos do GREat, com parceria com empresas, em apenas um foi
possvel a aplicao do ProMePE, devido principalmente confidencialidade das
informaes dos demais projetos. O projeto escolhido est em desenvolvimento h mais
de trs anos e atualmente se encontra na fase de testes e implantao, com prazo para
concluso no final de fevereiro de 2010. O fato de o projeto estar em fase de concluso,
no inviabiliza a sua utilizao nesse estudo de caso. Isso se d pelo fato de que o
137

objetivo da aplicao do ProMePE a um projeto avaliar sua completude e a possvel


realizao de ajustes no processo.
O projeto foi desenvolvido com a metodologia cascata e encontra-se com todos
os casos de uso concludos e em fase de testes e homologao por parte do cliente. O
projeto teve como foco o desenvolvimento de uma aplicao web para acompanhamento
da produo de uma fbrica de placas eletrnicas (linha de produo) e foi dividido em
trs mdulos, que compem trs contratos vinculados empresa contratante. Um deles
era responsvel pelo controle bsico como, cadastro de cliente, cadastro de usurios,
cadastro de produto, cadastro das etapas dos produtos e segurana. O segundo mdulo
era responsvel pela definio e controle dos estados da produo do produto. O terceiro
e ltimo mdulo era responsvel pela emisso de relatrios diversos. O projeto foi
desenvolvido utilizando a plataforma .NET com linguagem C# e banco de dados SQL
Server.
Diante do porte do grupo, este projeto era considerado mdio e enfrentou
durante seu ciclo de vida inmeros problemas tpicos de MPES, entre eles: elevada
modificao de requisitos, elevada rotatividade de pessoal, dificuldade de
relacionamento com o cliente, ausncia de documentao apropriada e de processo de
desenvolvimento bem definido. O impacto gerado por esses problemas ser discutido,
posteriormente, durante a descrio da aplicao do ProMePE.
A equipe do projeto era composta por um gerente de projeto, um analista de
sistemas e dois programadores (bolsistas). O analista de sistemas possua 50% do seu
tempo alocado para tal funo e os outros 50% como programador. Os dois
programadores realizavam atividades de programadores e de testadores. O gerente de
projeto tambm fazia o papel de testador, quando necessrio. O gerente de projeto e o
analista de sistemas eram considerados pessoas experientes. Os programadores,
bolsistas, apesar da baixa experincia no mercado, possuam elevada experincia na
tecnologia do projeto.
A implantao do ProMePE no GREat durou cerca de quatro meses, tendo o seu
incio em outubro de 2009 e trmino em janeiro de 2010. Durante este perodo as
atividades do processo foram executadas pelo gerente de projeto com o apoio do
analista, dos programadores e de um consultor10.

10
O consultor para a implantao do processo foi a autora deste trabalho.
138

A seguir so descritas como as tarefas do processo ProMePE foram aplicadas ao


projeto do GREat.

8.3.1 Pr-condies: Estabelecer Compromisso Organizacional e Planejar Recursos


O ProMePE foi formalmente apresentado, em uma reunio, para a equipe e para o
pesquisador responsvel por todos os projetos do grupo. A apresentao do ProMePE
(tarefas, papis, artefatos e guia) teve como objetivo a disseminao da importncia de
um processo de medio, do custo da incluso da medio e dos benefcios que um
programa como este pode trazer para a empresa.
O pesquisador responsvel por todos os projetos do grupo frisou que por se tratar
de um processo de medio de apoio gerencial, as medidas no sero utilizadas para
avaliar as pessoas e sim o andamento do projeto. Todos os membros da equipe ficaram
cientes e se comprometeram a reportar e coletar as informaes quando necessrio.
Em relao ao planejamento dos recursos, ficou acordado durante a reunio que
os gerentes de projetos seriam os responsveis pela coleta de informaes, de forma
manual, junto aos analistas e desenvolvedores. Outro ponto foi em relao ao uso de
ferramentas que automatizem o processo de coleta, ficando decidido que no seria
necessrio por se tratar de projetos com equipes pequenas.

8.3.2 Tarefa Desenvolver Plano de Medio


Para o planejamento da medio, o gerente de projeto foi instigado a levantar algumas
necessidades de informao que ele gostaria de possuir para melhor acompanhar o
desempenho do projeto, visando sempre informaes fceis e rpidas de serem obtidas
diante do contexto do projeto. Para isso, foi utilizado o Plano de Medio de Referncia
do ProMePE, que contm um conjunto de medidas pr-estabelecidas para ajudar o
gerente a elencar as necessidades de informaes. O gerente de projeto, ento,
acrescentou novas necessidades ao plano de medio e realizou algumas adaptaes.
As necessidades de informaes que possuem maior relevncia para a tomada de
deciso do projeto do GREat, segundo o gerente de projeto, esto descritas na Tabela
8.1. Algumas necessidades de informaes foram reutilizadas a partir do Plano de
Medio de Referncia (indicadas como Sim), outras foram adaptadas do plano
(indicadas como Adaptada) e outras criadas para atender s necessidades especficas
do projeto em questo (indicadas como No).
139

Tabela 8.1 Lista de Necessidades de Informao do Projeto e reutilizao em relao ao


Plano de Medio de Referncia

Necessidade de Informao Reutilizao


Quantas tarefas esto atrasadas? Sim
Qual a estimativa de tamanho total e por caso de uso do projeto?
Adaptada
Qual a estimativa de esforo total do projeto comparado com o
realizado? Sim
Qual a estimativa de esforo por caso de uso para cada disciplina
comparado com o realizado? No
Qual a estimativa de esforo comparado com o realizado no
perodo? Sim
Qual a estimativa de esforo total previsto no contrato comparado
com o realizado? No
Qual a estimativa de prazo total do projeto comparado com o
realizado? Sim
Qual a estimativa de custo previsto no contrato comparado com o
realizado no perodo? No
O quo estvel esto os requisitos? No
Como est o andamento dos testes? No

Alm de definir as necessidades de informao, o gerente de projeto definiu a


partir delas, juntamente com o consultor, as medidas base e a unidade da medida, seo
medidas base do Plano de Medio do Projeto, conforme Tabela 8.2 (o detalhe
completo de todos os artefatos oriundos da aplicao do processo encontra-se nos
APNDICES). De posse das medidas base possvel a obteno das medidas derivadas
bem como da funo para calcular tais medidas, Tabela 8.3

De acordo com as necessidades de informaes levantadas inicialmente houve a


incluso de algumas novas medidas, base e derivadas, quelas presentes no Plano de
Medio de Referncia. Essas medidas foram, por exemplo, a estimativa de tamanho
por caso de uso e a estimativa de esforo por disciplina. Outras, como, estimativa de
tamanho total e quantidade total de horas realizadas puderam ser diretamente
reutilizadas a partir do descrito no Plano de Medio de Referncia.
140

Tabela 8.2 Apresentao parcial da seo Medidas Base do Plano de Medio do Projeto
Necessidade de Informao Medidas Base Unidade de Medio
Datas do inicio do planejamento dias
Datas do fim do planejamento dias
Quantas tarefas esto atrasadas?
Datas do inicio real dias
Datas do fim real dias
Produtividade da Equipe (PROD) horas/tamanho

Qual a estimativa de esforo total Estimativa de Tamanho Total (ETT) inteiro


do projeto comparado com o
realizado?

Quantidade total de horas realizadas


horas
pela equipe (ESF_REAL)

Estimativa de Tamanho por Caso de


inteiro
Qual a estimativa de esforo por Uso (ETT_CASO_USO)
caso de uso para cada disciplina? Porcentagem de Esforo por Disciplina
%
(P_ESF)

Tabela 8.3 Apresentao parcial da seoMedidas Derivadas do Plano de Medio do


Projeto

Medidas Base Medidas Derivadas Funo de Medio


Datas do inicio do 1. Total de Tarefas 1. Soma do nmero de tarefas planejadas cuja data final
planejamento Planejadas menor ou igual que o periodo que se deseja comparar.
Datas do fim do 2. Total de Tarefas em 2. Soma do nmero de tarefas em execuo cuja data final
planejamento Execuo menor ou igual que o periodo que se deseja comparar.
Datas do inicio real 3. % Concluso das 3.(Total de Tarefas Atuais - Total de Tarefas
Datas do fim real Tarefas Planejadas)/Total de Tarefas Planejadas
Produtividade da 1. Estimativa de
Equipe (PROD) Esforo Total do
Projeto (ESF) 1. ESF = PRODxETT
Estimativa de Tamanho
Total (ETT)
2. Total de Horas 2. ESF_REAL = Soma da quantidade de horas trabalhadas
Trabalhadas durante o por todos os membros do projeto
Quantidade total de
projeto
horas realizadas pela
3. Variancia entre o 3. ESF_VAR = (ESF_REAL-ESF)/ESF
equipe (ESF_REAL)
estimado e o realizado
(ESF_VAR)
4. Estimativa de
Estimativa de Tamanho
Esforo por Caso de
por Caso de Uso 4. ESF_CASO_USO = PRODxETT_CASO_USO
Uso
(ETT_CASO_USO)
(ESF_CASO_USO)
5. Estimativa de
Porcentagem de
Esforo de cada caso
Esforo por disciplina 5. ESF_DISP = PRODxETT_CASO_USOxP_ESF
de uso por disciplina
(P_ESF)
(ESF_DISP)

O Plano de Medio de Referncia do ProMePE prev um percentual de esforo


para cada papel dentro do projeto, considerando 10% do esforo para o gerente de
141

projeto, 15 a 20% para o analista de sistemas e outros percentuais para os demais


papeis. No estudo de caso, o gerente de projeto adaptou os percentuais de esforo
presentes no Plano de Medio de Referncia, para atender de forma real o projeto,
conforme apresentado na Tabela 8.4.

Tabela 8.4 Porcentagem de Esforo Realizado no Projeto por Papel

Papel Percentual de Esforo


Coordenador do Projeto 1%
Analista de Sistemas 46%
Gerente de Projeto 4%
Projetista 0%
Arquiteto 0%
Desenvolvedor 49%
Testador 0,00%

Outra porcentagem que o Plano de Medio de Referncia tambm considera


em relao ao esforo por disciplina. O gerente de projeto dividiu o esforo de
desenvolvimento de cada caso de uso de acordo com o percentual de esforo por
disciplina (gerncia de projetos, requisitos, anlise e projeto, implementao e testes).
Para realizar esta diviso considerou-se como padro o que est definido no Plano de
Medio de Referncia, que 20% do esforo total foi gasto na disciplina de requisitos,
20% na disciplina de analise e projeto, 35% na disciplina de implementao, 15% na
disciplina de testes e 10% na disciplina de gerencia de projetos. Estes valores de
percentual de esforo foram adaptados a partir de pesquisa bibliogrfica (MONTEIRO,
2005) (PMI, 2009) e foram considerados valores estimados para a empresa, devendo ser
calibrado ao passo que novos projetos utilizem o ProMePE.
Alm de definir as medidas e o percentual de esforo por caso de uso e por
disciplina, h a necessidade de se determinar como elas sero coletadas. O
procedimento de coleta das medidas derivadas engloba, entre outras informaes, a
freqncia de coleta, o responsvel e qual a ferramenta ser utilizada, Tabela 8.5.

Tabela 8.5 Apresentao Parcial da Seo Procedimento Coleta de Dados do Plano de


Medio do Projeto

Freqncia da Responsvel pela Ferramenta Utilizada na


Medidas Derivadas Fase da Coleta
Coleta Coleta Coleta dos Dados
1. Total de Tarefas
Semanalmente Todas Gerente de Projeto MS Project
Planejadas
2. Total de Tarefas em
Semanalmente Todas Gerente de Projeto MS Project
Execuo
3. Porcentagem de
Semanalmente Todas Gerente de Projeto MS Project
Concluso das Tarefas
142

O mesmo acontece no procedimento de anlise dos dados, onde aps a coleta, os


dados precisam ser analisados para auxiliar nas tomadas de deciso, Tabela 8.6. Nessa
aplicao, a anlise foi realizada a partir de uma planilha excel devido simplicidade e
rapidez para anlise dos dados.

Tabela 8.6 Apresentao parcial da seo Procedimento Anlise dos Dados do Plano de
Medio do Projeto

Freqncia da Fase da Responsvel pela Ferramenta Utilizada na


Medidas Derivadas
Anlise Anlise Anlise Anlise dos Dados
1. Total de Tarefas
Semanalmente Todas Gerente de Projeto MS Project/Excel
Planejadas
2. Total de Tarefas em
Semanalmente Todas Gerente de Projeto MS Project/Excel
Execuo

3. Porcentagem de
Semanalmente Todas Gerente de Projeto MS Project/Excel
Concluso das Tarefas

Alm das informaes citadas acima, o Plano de Medio do Projeto tambm


contm informaes como o mecanismo de divulgao da anlise dos dados, possveis
pesos adaptados para o clculo da estimativa de tamanho e percentuais de esforo por
disciplina de acordo com o projeto. Essas informaes podem ser consultadas no
APNDICE B.

8.3.3 Tarefa Estimar Tamanho


Pelo fato de o projeto j estar em fase de concluso, a tarefa de estimar tamanho teve
que ser realizada de forma retroativa. Para conseguir estimar o tamanho do projeto foi
necessrio resgatar os documentos de caso de uso e de requisitos no-funcionais do
perodo em que o projeto iniciou. O projeto possui, desde seu incio, 29 casos de uso
que foram analisados pelo gerente de projeto juntamente com o analista de sistemas
para contabilizao da quantidade de transaes por caso de uso e posterior
classificao, tanto por grupo de transao quanto por complexidade. A Tabela 8.7
ilustra de forma parcial a contagem de transaes por caso de uso, onde a coluna
Tamanho retrata o tamanho por caso de uso aps o processo de contagem.
O gerente, ento, atribuiu um peso, Tabela 8.8, pr-definido no Plano de
Medio de Referncia, e multiplicou a quantidade total de transaes pelo respectivo
peso (coluna Valor). Aps isso, o gerente somou todos os valores das funcionalidades
(FF).
143

FF= 690

Tabela 8.7 Apresentao Parcial da Classificao das Transaes por Caso de Uso, presente
na Planilha de Coleta e Anlise dos Dados
TED TSD TCD TEX TPD
Caso de
Complexidade Complexidade Complexidade Complexidade Complexidade Tamanho
Uso
BaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAlta
UC1 1 2,67
UC2 4 1 20,47
UC3 4 1 20,47
UC4 3 1 1 1 20,47
UC5 3 1 1 16,91
UC6 3 1 1 19,58
UC7 3 2 1 24,03
UC8 3 1 1 16,91
UC9 2 1 11,57
UC10 1 1 3 1 28,48

Tabela 8.8 Apresentao Completa do Clculo da Funcionalidade, presente na Planilha de


Coleta e Anlise dos Dados
Grupos de Transaes Complexidade Peso Quantidade Valor
Baixa 3 53 159
TED Mdia 4 20 80
Alta 6 4 24
Baixa 4 7 28
TSD Mdia 5 13 65
Alta 7 3 21
Baixa 3 18 54
TCD Mdia 4 8 32
Alta 6 11 66
Baixa 5 0 0
TEX Mdia 7 0 0
Alta 10 0 0
Baixa 7 23 161
TPD Mdia 10 0 0
Alta 15 0 0

O gerente tambm solicitou aos programadores que caracterizassem o sistema de


acordo com os requisitos no-funcionais (FTFN) e, posteiormente, somou todas as
notas, Tabela 8.9.
)*

 0  5  3  5  0  3  5  0  3  0  24
+,)

FTFN = 0,65+(24*0,01) = 0,89


144

Tabela 8.9- Caractersticas No-Funcionais, planilha de Anlise e Coleta de Dados

Caracterstica Peso
Processamento Distribudo 0
Desempenho 5
Eficincia do Usurio 3
Processamento Complexo 5
Reusabilidade 0
Facilidade de Instalao 3
Usabilidade 5
Portabilidade 0
Facilidade de Manuteno 3
Concorrncia 0

Logo em seguida, o gerente informou os resultados das contagens na Planilha de


Anlise e Coleta de Dados para contabilizao da estimativa de tamanho total do
projeto. Para o corrente projeto, a estimativa de tamanho total (ETT) foi de acordo com
a frmula:
-  .
A partir dessa aplicao, o tamanho total do projeto foi estimado em:
-  690. 0,89  614,1

8.3.4 Tarefa Estimar Esforo


No projeto em questo, o gerente obteve a estimativa de esforo total (ESF) a partir da
estimativa de tamanho (ETT) e da produtividade da equipe (PROD). Por ter enfrentado
diversos problemas durante o projeto, o gerente de projeto estimou, em virtude da
ausncia de dados histricos, a produtividade da equipe como 20hs para cada tamanho
do projeto. A partir desse valor, o esforo total foi calculado como:
-1  23 .-  614,10.20  12.282 5 
A partir do esforo total do projeto e de posse da estimativa de tamanho por caso
de uso, calculada na seo anterior, o gerente de projeto obteve a estimativa de esforo
por caso de uso do projeto. Com a estimativa de esforo por caso uso, o gerente
distribuiu o esforo entre as disciplinas de acordo com o previsto no Plano de Medio
do Projeto, Tabela 8.10.
145

Tabela 8.10 Apresentao Parcial de estimativa de esforo por caso de uso e disciplina,
planilha de Anlise e Coleta de Dados, seo Esforo

Esforo Esforo Esforo


Esforo Estimado Esforo Estimado
Caso Estimado Estimado Estimado Esforo Estimado
Disciplina Anlise Disciplina Gerncia
de Uso por Caso de Disciplina Disciplina Disciplina Testes
e Projeto de Projetos
Uso Requisitos Implementao

UC1 53,4 10,68 10,68 18,69 8,01 1,068


UC2 409,4 81,88 81,88 143,29 61,41 8,188
UC3 409,4 81,88 81,88 143,29 61,41 8,188
UC4 409,4 81,88 81,88 143,29 61,41 8,188
UC5 338,2 67,64 67,64 118,37 50,73 6,764
UC6 391,6 78,32 78,32 137,06 58,74 7,832
UC7 480,6 96,12 96,12 168,21 72,09 9,612
UC8 338,2 67,64 67,64 118,37 50,73 6,764
UC9 231,4 46,28 46,28 80,99 34,71 4,628

Alm da estimativa de esforo total e por caso de uso, o gerente obteve as


estimativas de esforo previstas nos contratos. Cada contrato previa uma quantidade
diferente de recursos humanos e de horas trabalhadas mensalmente. A Tabela 8.11
ilustra os recursos humanos (papel) previstos no Contrato 1 entre a empresa contratante
e o GREat e o esforo total (horas) previsto para o perodo de vigncia do contrato.

Tabela 8.11 Apresentao Parcial do Esforo Previsto no Contrato 1, planilha de Anlise e


Coleta dos Dados, seo Esforo
Papel Quant. nov/06 dez/06 jan/07 fev/07 mar/07 Total
Coordenador 1 5 5 5 5 5 25
Gerente de Projeto 1 160 160 160 160 160 800
Desenvolvedor 2 160 160 160 160 160 1600
Bolsista 2 120 120 120 120 120 1200
Esforo Total Previsto no Contrato 1 no Perodo (horas) 3600

8.3.5 Tarefa Estimar Prazo


A partir da estimativa de esforo, o gerente de projeto aplicou a medida derivada de
estimar prazo (EPRZ) de acordo com o especificado no plano de medio. Para cada
membro da equipe (QtdRD), nesse caso, 4 pessoas, o gerente de projeto contabilizou a
quantidade de horas trabalhadas (JTRAB) por dia, sendo duas pessoas com 8 horas
dirias e duas com 4 horas dirias, e aplicou a funo para clculo da medida derivada
de prazo. Dessa forma, o gerente calculou o prazo final, em dias, de concluso do
projeto.
-1 12.282
-26    512  
<+,) 892 .:2; 1.8  1.8  2.4
146

Uma importante considerao a ser feita sobre o clculo da estimativa de prazo


diz respeito quantidade de recursos humanos. O clculo foi realizado tendo como base
a quantidade de recurso no momento da sua aplicao e no h trs anos quando o
projeto efetivamente iniciou. Ao discutir com membros que participaram do projeto na
poca, o gerente concluiu que a quantidade de recursos era bem prxima do atual, no
impactando muito no prazo estimado calculado.

8.3.6 Tarefa Estimar Custo


Para calcular a estimativa de custo, o gerente obteve o esforo total do projeto em horas
(ESF) e a porcentagem de esforo para cada papel do projeto (P_CONTRATO), ambos
presentes no Plano de Medio do Projeto. Para o clculo da porcentagem de esforo
para cada papel do projeto foi considerado a porcentagem de acordo com o previsto nos
contratos (coordenador do projeto cerca de 1%, gerente de projeto cerca de 26,5% e
desenvolvedor cerca de 72%). Outra informao que precisou ser coletada para o
clculo da estimativa de custo foi o valor da hora de trabalho de cada profissional
(VlrHORA). Mais uma vez, por se tratar de uma medida retroativa, no foi possvel
precisar o valor da hora dos profissionais no incio real do projeto. Para tanto, o gerente
considerou o valor atual da hora trabalhada com um valor inferior ao atual em 20%,
totalizando os valores de hora de trabalho em R$ 82,00, R$ 18,96, R$11,38 e R$11,38
para os papis de coordenador, gerente de projeto, analista de sistemas e programadores,
respectivamente.
De posse dessas informaes, o gerente de projeto calculou o custo estimado
(CUSTO) do projeto:
<

=>13   -1._=323.@A32
#
+,)

=>13  12282.0,012.82  12282.0,264.18,96  12282.0,724.11,38


 2$ 175.397,71
Outra estimativa calculada pelo gerente de projeto foi em relao estimativa de
custo total do projeto considerando o esforo previsto no contrato (ESF_CONTRATO =
19.336 horas) e o valor da hora de trabalho pago pelos profissionais no perodo
(VlrHORA). O objetivo dessa segunda estimativa foi a obteno de um valor financeiro
para posterior comparao com o que foi realmente pago pelos contratos.
Portanto, o custo estimado de acordo com o esforo previsto no contrato era de:
147

<

=>13DEFGHIGE   -1_=323._=323.@A32
+,)

 19336.0,01.82  19336.0,26.18,96  19336.0,72.11,38  2$ 276.135,00

A seguir, Seo 8.3.7, ser detalhado a implantao da tarefa Executar Medio


no projeto da empresa.

8.3.7 Tarefa Executar Medio


A finalidade desta tarefa a coleta dos dados definidos no Plano de Medio do Projeto.
O Plano de Medio do Projeto foi definido na tarefa Planejar Medio, conforme visto
anteriormente. As medidas a serem coletadas foram obtidas de acordo com as
necessidades de informaes descritas pelo gerente de projeto. Periodicamente, a equipe
reportou, com freqncia pr-definida no Plano de Medio do Projeto, os dados para o
gerente de projeto que consolidou as informaes na Planilha de Coleta e Anlise dos
Dados. Aqui sero detalhadas algumas medidas derivadas definidas no Plano de
Medio do Projeto. As demais medidas sero apresentadas no APNDICE C.
Entre as medidas reportadas pela equipe esto: total de tarefas planejadas, total
de tarefas em execuo, % concluso das tarefas, total de horas trabalhadas durante o
projeto, variao entre o estimado e o realizado, variao entre o realizado e o estimado
no contrato, % requisitos modificados e quantidade de defeito por caso de uso. Todas
estas medidas foram coletadas de acordo com a freqncia determinada no Plano de
Medio do Projeto.
Para o atendimento da necessidade de informao quantas tarefas esto
atrasadas previsto no Plano de Medio do Projeto, o gerente de projeto acompanhou o
progresso das atividades atravs da coleta do total de tarefas planejadas e concludas no
perodo. No perodo de aplicao do ProMePE no GREat a equipe estava planejada para
executar 31 tarefas, sendo 12 delas no ms de outubro, 11 no ms de novembro e 8 no
ms de dezembro. Das 12 tarefas previstas no ms de outubro apenas 7 foram
executadas, Tabela 8.12, o restante ficou para ser executado no ms de novembro e
dezembro.
148

Tabela 8.12 Tarefas planejadas e executadas no period, seo Progresso do Cronograma


da Planilha de Coleta e Anlise dos Dados

Ano de 2009 Ms de Outubro


Tarefas Semana 1 Semana 2 Semana 3 Semana 4
Qtd. Tarefas Planejadas 3 3 3 3
Qtd. Tarefas Concludas 1,5 1,5 2 2

A Tabela 8.13 mostra a distribuio de esforo do projeto no perodo, conforme


medida derivada total de horas trabalhadas durante o projeto definida no Plano de
Medio do Projeto. A medida de esforo mensal planejado foi obtida pelo gerente de
projeto atravs da ferramenta MS Project, j a medida de esforo mensal executado foi
obtida semanalmente com a equipe. Ambas as medidas foram consolidadas,
posteriormente, na Planilha de Coleta e Anlise de Dados. As medidas de esforo
mensal planejado acumulado e esforo mensal executado acumulado so calculadas
automaticamente pela planilha.

Tabela 8.13 Distribuio de Esforo no Projeto Realizado, seo Esforo da Planilha de


Coleta e Anlise dos Dados
Ano 2009
Esforo no Perodo
out nov dez
Esforo Mensal Planejado 320 320 320
Esforo Mensal Planejado Acumulado 320 640 960
Esforo Mensal Executado do Projeto 220 233 280
Esforo Mensal Executado Acumulado 220 453 733

Em relao ao esforo, a medida derivada quantidade de horas previstas nos


contratos tambm foi coletada. Essa medida foi coletada retroativamente em virtude da
solicitao de necessidade de informao (qual a estimativa de esforo total previsto no
contrato comparado com o realizado?) por parte do gerente, definido no Plano de
Medio de Projeto. Para o contrato 1, o esforo realizado no perodo est descrito na
Tabela 8.14.

Tabela 8.14 Esforo Realizado no Perodo do Contrato 1, seo Esforo da Planilha de


Coleta e Anlise dos Dados
Nov Dez Jan Fev Mar Abr Mai Jun Jul Ago Set Out
Papel Qtd. Total
2006 2006 2007 2007 2007 2007 2007 2007 2007 2007 2007 2007
Coordenador 1 8 8 8 8 8 4 4 4 4 4 4 4 68
Gerente de
0 0 0 0 0 0 0 0 0 0 0 0 0 0
Projeto
Desenvolvedor 2 160 160 160 160 160 80 80 80 80 80 80 80 2720
Analista 1 160 160 160 160 160 80 80 80 80 80 80 80 1360
Esforo Total Realizado no Perodo (horas) 4148
149

De posse do esforo realizado no perodo, a medida derivada custo real do


projeto foi calculada pelo gerente de projeto para todos os contratos. Abaixo o clculo
do custo real para o Contrato 1, de acordo com a distribuio de esforo previsto na
tabela anterior e com valor real das horas de trabalho de cada profissional.
<

=>13HJIK   -1_2-L_-L.@A32
+,)

=>13HJIK  68.100,00  2720.13,88  1360.13,88  2$63.410,00

Outra medida derivada calculada foi a porcentagem de requisitos modificados


e tambm foi coletada de forma retroativa, Tabela 8.15. O gerente de projeto analisou
tanto as solicitaes de mudanas formais da empresa contratante, como as solicitaes
de mudanas informais (e-mails e atas de reunies) e juntamente com a equipe
conseguiu chegar porcentagem de mudana de cada caso de uso do sistema. Esta
informao foi til para o clculo do esforo estimado para a mudana por caso de uso e
posterior clculo da estimativa de custo para cada mudana. Pode-se notar na Tabela
8.15 que a mudana de requisitos para alguns casos de uso foi considerada alta. Em
especial o UC7 que foi totalmente alterado em relao sua especificao inicial.

Tabela 8.15 Apresentao Parcial da Estimativa de Esforo para Mudanas de Requisitos do


Projeto, seo Estabilidade dos Requisitos da Planilha de Coleta e Anlise de Dados

Esforo Estimado para Mudana


Caso %
de Uso Mudana Requisitos Anlise e Gerncia de Total
Implementao Testes
Projeto Projeto (horas)
UC1 0% 0 0 0 0 0 0
UC2 50% 40,94 40,94 71,645 30,705 20,47 205
UC3 50% 40,94 40,94 71,645 30,705 20,47 205
UC4 80% 65,504 65,504 114,632 49,128 32,752 328
UC5 0% 0 0 0 0 0 0
UC6 30% 23,496 23,496 41,118 17,622 11,748 117
UC7 100% 96,12 96,12 168,21 72,09 48,06 481
UC8 0% 0 0 0 0 0 0
UC9 10% 4,628 4,628 8,099 3,471 2,314 23

Em relao aos defeitos encontrados provenientes dos testes (medidas derivadas


quantidade de defeitos por caso de uso e porcentagem de defeito por tamanho de
caso de uso) a equipe do projeto mantm um documento chamado de relatrio de erros
que contm todos os erros encontrados por casos de teste. Cada erro possui uma
150

descrio, o nome do testador, a data do teste e o nome da pessoa responsvel por


corrigi-lo. No perodo de aplicao deste estudo de caso, foram encontrados um total de
77 erros. Para a aplicao em questo, foi considerado um caso de teste para cada caso
de uso. A Tabela 8.16 ilustra a quantidade de defeitos encontrados por caso de teste e
porcentagem de defeito por tamanho de caso de uso. O tamanho de caso de uso
considerado para o clculo foi o tamanho estimado de acordo com as mudanas de
requisitos, como mostrado na tabela anterior.
Com isso, pode-se notar que atravs da coleta dos dados possvel realizar uma
anlise critca do andamento do projeto, escopo que ser detalhado na Seo 8.3.8.

Tabela 8.16 Apresentao parcial da quantidade de defeitos encontrados no projeto por caso
de teste, seo defeitos da planilha de coleta e anlise dos dados
Porcentagem de
Defeito por
Casos de Testes Qtd. de Defeitos Tamanho de UC
CT1 26 0%
CT2 8 4%
CT3 0 0%
CT4 3 1%
CT5 1 0%
CT6 13 11%
CT7 2 0%
CT8 2 0%
CT9 5 22%

8.3.8 Tarefa Analisar Medio


A tarefa analisar medio tem por objetivo a realizao de uma anlise crtica em
relao aos dados coletados na tarefa anterior. Nesse momento o gerente de projeto deve
comparar o estimado com o realizado, observar os indicadores presentes no Plano de
Medio do Projeto, divulgar os resultados e tomar as aes cabveis para o melhor
andamento do projeto.
A Figura 8.2 detalha o progresso no ms de outubro atravs do acompanhamento
semanal das execuo das atividades (medidas derivadas total de tarefas planejadas e
total de tarefas em execuo). Ao analisar o grfico de progresso do cronograma
percebe-se o atraso no projeto. Apesar do grfico de acompanhamento semanal indicar
que o mximo permitido de atraso de 15% do esforo da tarefa, o projeto no
conseguiu acompanhar tal critrio de deciso em virtude de problemas tcnicos
encontrados durante execuo das tarefas e continuou, durante todo o ms de outubro,
bem abaixo do planejado.
151

A Figura 8.3 ilustra o progresso do cronograma do projeto no perodo (out/09 a


dez/09), medida derivada porcentagem de concluso das tarefas onde percebe-se a
porcentagem de tarefas pendentes, a serem concludas, e a porcentagem de tarefas
concludas.
A anlise do esforo total do projeto, medidas derivadas de estimativa de
esforo total do projeto e total de horas trabalhadas durante o projeto no perodo, foi
realizada pelo gerente de projeto aps a coleta das informaes, conforme ilustra a
Figura 8.4.

Tarefas Planejadas x Tarefas Concluda em Outubro


4
Quantidade de Tarefas

3,5 Qtd. Tarefas


3 Planejadas
2,5 Qtd. Tarefas
2 Concludas
1,5
Critrio de Deciso
1 +15%
0,5
Critrio de Deciso -
0
15%
Semana 1 Semana 2 Semana 3 Semana 4

Figura 8.2 Progresso do Cronograma do Projeto em Outubro, seo Progresso do


Cronograma da Planilha de Coleta e Anlise dos Dados

Progresso do Cronograma no Perodo de 1/10/2009 a


30/12/2009

Porcentagem de Tarefas
39% Pendentes (%)
61% Porcentagem de Tarefas
Concludas (%)

Figura 8.3 Progresso do Cronograma do Projeto no Perodo, seo Progresso do


Cronograma da Planilha de Coleta e Anlise dos Dados

Para o esforo executado no perodo, foi definido no Plano de Medio do


Projeto, um critrio de deciso de +20% e -20%. O grfico, Figura 8.4, ilustra o esforo
planejado e o executado no perodo. Observa-se que apenas o esforo realizado no ms
de dezembro se encontra dentro do definido pelo indicador do projeto (entre as linhas
152

limites), devido a um maior acompanhamento por parte do gerente e a resoluo de


problemas tcnicos apresentados. O projeto continua com um esforo menor do que o
planejado para os demais meses (outubro e novembro). Essas informaes foram
divulgadas para a equipe nas reunies semanais e para a alta gerncia mensalmente.

Esforo em Horas: Planejado x Executado


450
400
Esforo Mensal
Esforo em Horas

350
Planejado
300
250 Esforo Mensal
200 Executado do Projeto
150 Critrio de Deciso
100 +20%
50 Critrio de Deciso -20%
0
out nov dez

Figura 8.4 Esforo do projeto no perodo: realizado x planejado, seo Esforo da Planilha
de Coleta e Anlise dos Dados

O grfico de varincia de esforo, Figura 8.5, ilustra a porcentagem de variao


de esforo entre o previsto em cada contrato e o realizado (medida derivada variao
entre o estimado e o realizado no contrato). Se a porcentagem de varincia for
negativa, essa indica que aquele contrato teve um esforo realizado menor do que o
previsto, ao contrrio da porcentagem positiva que indica que o esforo realizado foi
maior do que o previsto no contrato. O contrato 1 claramente teve um esforo maior do
que o previsto, enquanto que o contrato 2 teve um esforo menor e o contrato 3 um
esforo bem prximo do previsto.

Varincia de Esforo: Realizado x Previsto no Contrato


20%

10%

0%
Contrato 1 Contrato 2 Contrato 3 Varincia
-10%

-20%

-30%

Figura 8.5 Varincia de Esforo entre o realizado e o previsto no contrato, seo Esforo,
Planilha de Coleta e Anlise dos Dados
153

A Figura 8.6 ilustra um comparativo entre o esforo em horas previsto em cada


contrato e o realizado. O esforo realizado no perodo de vigncia do contrato 2 foi
menor do que o previsto em virtude da alocao de bolsistas em perodo parcial, o que
reduziu o esforo realizado.
Por se tratar de medidas retroativas, o gerente de projeto utilizou dessas
medies de contrato (variao entre o estimado e o realizado no contrato,
quantidade de horas previstas no contrato, quantidade de horas realizadas) para
reportar alta gerncia um resumo de como o projeto se comportou em relao ao
esforo previsto no contrato e servir como base histrica para os futuros projetos.

Esforo Previsto no Contrato x Realizado


12000

10000
Esforo (horas)

8000

6000 Previsto no Contrato


Realizado
4000

2000

0
Contrato 1 Contrato 2 Contrato 3

Figura 8.6 Esforo Previsto no Contrato x Realizado, seo Esforo, Planilha de Coleta e
Anlise dos Dados
Como resultado da anlise das medidas derivadas de custo (estimativa de custo
total previsto no contrato e custo real do projeto) ilustrado na Figura 8.7, nota-se que
o custo gasto na realizao do projeto foi maior que o custo pago pela empresa
contratante em todos os contratos. Apesar dos grficos anteriores, de esforo, apontarem
que o esforo realizado foi menor do que o previsto nos contratos, o valor pago pelos
contratos foi baixo comparado com o valor pago para os profissionais. Isso se deve
principalmente pelo enorme retrabalho que a equipe teve com as mudanas de requisitos
solicitadas pelo contratante, constatado e detalhado posteriormente.
Se esse controle tivesse sido realizado durante todo o perodo de execuo do
projeto, tanto o gerente de projeto como a alta gerncia poderiam ter tomado alguma
deciso em relao viabilidade de continuidade do projeto a partir do contrato 1
154

quando claramente percebe-se o seu prejuzo financeiro, mais do que os 20% previsto
como critrio de deciso.

Custo do Projeto por Contrato


R$ 140.000,00
R$ 120.000,00
R$ 100.000,00
R$ 80.000,00
R$ 60.000,00
R$ 40.000,00
R$ 20.000,00
R$ -
Contrato 1 Contrato 2 Contrato 3

Previsto Realizado
Critrio de Deciso +20% Critrio de Deciso -20%

Figura 8.7 Custo do Projeto por Contrato, seo custo da Planilha de Coleta e Anlise dos
Dados

A Figura 8.8 exibe a comparao entre o valor pago pela contratante (todos os
trs contratos) e o custo real do projeto para o GREat, o que corresponde a um prejuzo
financeiro de aproximadamente 72 mil reais.

Custos do Projeto

R$ 263.205,00

R$ 191.542,77

Custo Pago pela Contratante Custo Real do Projeto (RH) Prejuzo (RH)
(RH)
R$ 71.662,23

Figura 8.8 Comparao Custo Total do Projeto, seo custo da Planilha de Coleta e
Anlise dos Dados
155

Em relao mudana de requisitos, no foi possvel a contagem do esforo


realizado para corrigi-los em virtude da ausncia de informaes anteriores (medida
derivada impacto real das mudanas de requisitos). Como base para projetos futuros e
conscientizao da equipe e da alta gerncia, o gerente estimou o esforo para
realizao das mudanas (medida derivada impacto estimado das mudanas de
requisitos). O grfico abaixo, Figura 8.9, ilustra o esforo estimado acumulado para
realizao das mudanas de requisitos, o que corresponde, para todos os casos de uso, a
um total de aproximadamente 5000 horas a mais no projeto para atender s
modificaes solicitadas, o que corresponde a um custo estimado de aproximadamente
R$76mil reais. Como na poca no houve esse controle, o gerente atendeu a todas as
solicitaes sem adio de valor ao contrato, o que contribuiu para o prejuzo financeiro
do projeto. Essa informao retroativa foi divulgada para equipe e para alta gerncia e
servir de alerta em projetos futuros.

Esforo Estimado Acumulado


6000

5000

4000

3000
Esforo Estimado
2000 Acumulado

1000

Figura 8.9 Esforo estimado acumulado para mudana de requisitos, seo estabilidade de
requisitos, Planilha de Coleta e Anlise de Dados

Para o controle dos defeitos, Figura 8.10, o gerente de projeto verificou que para
alguns casos de uso a taxa de defeito foi elevada quando comparado com o tamanho de
cada caso de uso (medida derivada porcentagem de defeito por caso de uso). A taxa
de defeito por caso de uso poder ser utilizada tambm em projetos futuros para anlise
e acompanhamento da quantidade de defeitos encontrados. Essa medida servir para
acompanhar o trabalho dos desenvolvedores responsveis pelo desenvolvimento de cada
caso de uso. A quantidade de defeitos encontrados por caso de uso pode ser um indcio
156

da m qualidade do cdigo produzido, o que pode ter como causa inmeros fatores que
precisam ser analisados, como por exemplo, elevada presso para o desenvolvimento do
caso de uso e inexperincia do desenvolvedor.

Porcentagem de Defeito por Tamanho de UC

25%
20%
15%
10%
5%
0%
CT1 CT2 CT3 CT4 CT5 CT6 CT7 CT8 CT9

Taxa de Defeito por Tamanho de UC

Figura 8.10 Taxa de Defeito por Tamanho de UC, seo defeitos da Planilha de Coleta e
Anlise de Dados
A anlise dos dados mostrou que o projeto enfrentou problemas durante sua
execuo, o que ocasionou um elevado prejuzo final para o GREat. Os demais
grficos que possibilitam a anlise das outras medidas derivadas no citadas aqui
esto disponveis no APNDICE C.

8.3.9 Tarefa Avaliar Processo de Medio


Ao final do perodo de aplicao do ProMePE no projeto em questo, o gerente de
projeto e o consultor realizaram uma anlise do processo de medio.
O gerente de projeto observou que a lista de necessidades levantadas no Plano de
Medio do Projeto foi, de forma geral, atendida. Algumas medidas no puderam ser
analisadas de forma mais concreta em virtude da ausncia de informaes retroativas.
Isso se deu devido aplicao do ProMePE a um projeto que estava em fase de
concluso. As demais medidas serviram de apoio para a tomada de deciso, quando
possvel, e para dar uma viso geral do projeto (esforo, custo, modificao de
requisitos) para a alta gerncia.
Para a medida de progresso do cronograma, observou-se que o critrio de
deciso de apenas 15% baixo quando se fala de projetos de MPES e decidiu-se
aumentar esse critrio para 20% para os prximos projetos. As estimativas produzidas
no incio do projeto e os dados coletados durante a execuo do projeto foram
157

analisados e guardados em base histrica para servir de insumo nos projetos


subsequentes.
As demais medidas serviro de base para os prximos projetos, onde sero
melhor analisadas para posterior ajuste.
Aps os pequenos ajustes, o Plano de Medio de Referncia padro do
ProMePE foi atualizado de acordo com a execuo do projeto, como o ajuste do critrio
de deciso e a incluso de novas medidas. Espera-se que para os prximos projetos o
esforo necessrio para ajuste do Plano de Medio do Projeto seja ainda menor. A
Planilha de Coleta e Anlise dos Dados do projeto foi salva em local compartilhado
entre todos do grupo. Essa planilha tambm servir de template para os prximos
projetos.
Devido quantidade de informaes solicitadas para realizao de medio
(mais medidas do que o previsto no ProMePE), o gerente de projeto achou que o
processo de medio foi um pouco oneroso para o projeto. Isso ocorreu devido
inexperincia de todos no processo de medio e ausncia de algumas das
informaes necessrias para a medio. O Relatrio de Avaliao do Processo foi
elaborado com todas essas consideraes e lies aprendidas do projeto, APNDICE D.

8.4 Avaliao da Implantao do ProMePE

A implantao do processo demorou cerca de duas semanas para disseminao do


processo entre todos e elaborao do Plano de Medio e Planilha de Coleta de Anlise
dos Dados, realizado pelo gerente de projeto e consultor.
O ideal era que a aplicao do ProMePE fosse realizada em um projeto iniciante
e perdurasse durante todo o projeto, mas infelizmente isto no aconteceu, devido a
limitaes de tempo e disponibilidade de empresas e projetos para implantao. A
ausncia de um processo de desenvolvimento bem definido foi outra dificuldade que
impactou na imaturidade do acompanhamento dos gerentes e dos artefatos produzidos.
Todas as tarefas previstas no processo foram executadas e algumas delas
adaptadas no decorrer da aplicao, como por exemplo as pr-condies para
implantao do ProMePE que, anteriormente, faziam parte do processo.
O incio da implantao foi a fase mais dificil para a equipe em virtude da
construo do Plano de Medio de Projeto e ajuste das medidas a serem coletadas na
Planilha de Coleta e Anlise dos Dados. Apesar do ProMePE prever um Plano de
158

Medio de Referncia para ser instanciado para os projetos, este plano foi largamente
modificado para atender lista de necessidades do projeto e para tanto, despendeu cerca
de uma semana para ser ajustado.
Outro ponto que merece destaque foi a ausncia de algumas informaes para as
medidas, discutidas ao longo da aplicao do processo, que tambm despendeu tempo
do gerente de projeto e do consultor. A coleta de algumas medidas retroativas
mostraram apenas estimativas, que podem no ser efetivas, podendo levar a uma anlise
errnea dos dados. Mesmo com essas dificuldades, as medidas serviram de guia para o
gerente e alta gerncia, j que anteriormente eles no possuam essas informaes.
Apesar das dificuldades enfrentadas, o gerente, equipe e alta gerncia acharam
que o processo de medio trouxe benefcios para a empresa. Atravs dele foi possvel
acompanhar mais de perto o andamento do projeto e tomar decises baseadas em dados
reais. Com o clculo de estimativas mais precisas, o grupo ter uma menor
probabilidade de atrasos em seus cronogramas e consequentemente poder gerenciar
melhor suas finanas. Se tivesse tido, desde o incio, um acompanhamento mais
profundo do projeto atravs do uso de medio, muitas aes poderiam ter sido
evitadas, como a elevada mudana de requisitos e o elevado custo do projeto para a
empresa.

8.5 Consideraes Finais

O estudo de caso apresentado nesse captulo permitiu demonstrar a aplicabilidade do


ProMePE em uma MPES. Em relao aos objetivos da aplicao propostos no incio do
captulo, pode-se observar que:
O ProMePE atende ao objetivo da completude, pois foi possvel verificar que
ele possui todos os passos necessrios para a implantao de um programa
de medio;
Com a aplicao do ProMePE foi possvel realizar ajustes no processo como
a criao de pr-condies para sua aplicao e adaptaes de medidas;
Ocorreu a gerao de dados quantitativos que possibilitou uma anlise crtica
do andamento do projeto e com isso trouxe benefcios para a empresa;
Com a aplicao do ProMePE foi possvel a exemplificao da utilizao do
processo atravs da construo de um passo a passo da sua aplicao e
159

ilustrao de exemplos reais das medidas e dos artefatos gerados, ajudando


no entendimento do processo.
Assim, os objetivos propostos inicialmente foram atendidos.
Observou-se tambm que apesar da empresa no possuir um processo de
desenvolvimento bem definido e do projeto estar na fase final, foi possvel a aplicao
do ProMePE. A simples definio de um conjunto de passos necessrios para a
implantao de um processo de medio bem definido, com clculo de estimativas e
coleta de medidas reais, j proporcionou um importante ganho para a empresa em
termos de padronizao, controle e acompanhamento das atividades, reuso das
informaes e tomadas de deciso. A construo do Plano de Medio do Projeto com
a definio das medidas base, derivadas, dos procedimentos de anlise e critrios de
deciso proporcionaram maior orientao e controle em relao utilizao dos dados
coletados, que anteriormente no existiam ou eram realizados sob demanda e de forma
emprica e ad-hoc.
Outro ponto importante, foi a possibilidade de reuso das informaes, em
especial do Plano de Medio e da Planilha de Coleta e Anlise dos Dados. Esses dois
documentos podem ser reutilizados e alimentados para os projetos futuros, formando,
no decorrer do tempo, uma base de conhecimento com as caractersticas dos projetos da
empresa, possibilitanto a anlise e mitigao de futuros riscos aos projetos.
160

9 CONCLUSES E TRABALHOS FUTUROS

A comunidade de software vem, nos ltimos anos, tentando introduzir nas MPES a
melhoria do processo de software de forma a torn-las mais produtivas e competitivas
no mercado e um dos passos importantes para essa melhoria contnua a medio.
Medir o software significa, alm de obter informaes quantitativas, analis-las e tomar
as iniciativas apropriadas para corrigir possveis desvios durante a execuo do projeto.
Alm disso, medir o software significa obter dados histricos dos projetos para auxiliar
na constante melhoria do processo de desenvolvimento e na tomada de decises futuras.
A estimativa a base para a medio e juntamente com a coleta de dados reais
permite o controle quantitativo do que est sendo produzido. Ao medir o projeto
possvel acompanhar de forma mais efetiva o seu andamento e assim, minimizar os
riscos de insucesso e tomar as decises necessrias para mitigar possveis riscos antes
que esses se tornem crticos.
A medio um importante processo de apoio para o controle do
desenvolvimento do software e, por isso, existem algumas abordagens que auxiliam na
definio de um processo de medio, seja atravs de modelos de processos com boas
prticas de medio ou atravs de tcnicas que auxiliam na definio das medidas de
acordo com os objetivos de negcio das empresas.
A grande parte dessas abordagens so voltadas para atender grandes
organizaes, entretanto, elas representam a minoria das empresas de desenvolvimento.
As MPES, por outro lado, constituem cerca de 77% das empresas de desenvolvimento
de software do Brasil e, portanto, merecem ateno em todas as reas que compem o
ciclo de vida do software, em especial, as reas de estimativa e medio.
Existem atualmente inmeras tcnicas para estimar software. Algumas delas so
simples demais, baseadas na experincia do gerente ou da equipe, e outras mais
robustas, baseadas de forma mais objetiva na quantidade e qualidade dos requisitos,
porm, quando aplicadas para MPES podem despender custo de aprendizado e de
aplicao.
Para construir a base desse trabalho, inicialmente, foi realizado um estudo dos
trabalhos relacionados na rea de estimativa e de medio de software. Com o estudo,
observou-se que muitos trabalhos possuam caractersticas similares e com isso foi
definido um conjunto de requisitos para definio e implantao de processo de
161

medio nas MPES. Cada um dos requisitos foi comparado com os trabalhos
relacionados com a finalidade de realizar uma anlise crtica deles frente aos requisitos.
Com isso, observou-se que os trabalhos relacionados no atendiam, por completo, ao
conjunto de requisitos especificados.
Em muitas abordagens utilizadas na literatura, costuma-se separar a elaborao
de estimativas da definio do processo de medio. Entende-se que estimar uma
forma de medir, ento, devido a carncia de utilizao nas MPES tanto de estimativas
quanto de medies em conjunto com a definio de medidas simples que comparam o
planejado com o realizado, surgiu a necessidade de propor um processo para medio
que atendesse desde o clculo das estimativas at a coleta de medidas reais.
Para propor o processo de medio alguns itens foram analisados: o conjunto de
requisitos especificados e a similaridade entre os processos e tcnicas de estimativas.
Como forma de padronizar e possibilitar o reuso de infomaes com foco nas MPES,
foi documentado um conjunto de padres de estimativas. A linguagem de padres de
estimativa traz uma forma de estimar software orientado a requisitos, independente de
plataforma de desenvolvimento e voltado a atender as MPES.
A partir dos padres foi, ento, definido o processo simplificado de medio de
software para as MPES, ProMePE, que fornece pontos essenciais para o incio do
processo de medio nesse nicho de mercado. O ProMePE foi construdo seguindo as
boas prticas de medio definidas no PSM e atende de forma geral ao conjunto de
requisitos especificados.
Portanto, este trabalho de dissertao apresenta as seguintes contribuies
principais:
Levantamento e documentao de um conjunto de requisitos para a construo e
implantao de um processo de medio de software especfico para Micro e
Pequenas Empresas;
Documentao de boas prticas de estimativa de software na forma de uma
linguagem de padres;
Construo de um processo de medio de software simplificado para Micro e
Pequenas Empresas com aderncia ao PSM.
Com isso, espera-se contribuir com pesquisas relacionadas rea de melhoria de
processo de software para MPES, ao propor um processo de medio simplificado e
com o objetivo de facilitar a implantao de atividades de estimativa e medio e
permitir o amadurecimento de empresas desse tipo.
162

Na seo 9.1 so apresentados os trabalhos futuros.

9.1 Trabalhos Futuros

Como trabalhos futuros pretende-se dar continuidade a esse processo de medio e


investir em outras iniciativas de melhoria de processo para MPES.
Em relao ao ProMePE, pretende-se:
Aplicar em mais projetos ou em outras empresas para refinar o processo e as
medidas base presentes no Plano de Medio de Referncia;
Avaliar o processo de medio em uma empresa de acordo com o processo de
avaliao MA-MPS previsto no MPS.BR;
Averiguar ferramentas existentes na literatura que possibilitem a automatizao
da coleta, armazenamento e anlise das medidas;
Implantar o ProMePE em uma empresa que utilize metodologias geis e
verificar sua integrao;
Avaliar o ProMePE utilizando os princpios da engenharia de software
experimental.
Dando continuidade ao trabalho de melhoria de processo para MPES, pretende-se
realizar uma pesquisa para conhecer outras reas de processo das MPES com
problemas, como a gerncia de requisitos e garantia da qualidade e tentar aprimorar
tcnicas e processos que auxiliem tais empresas a lidar melhor com essas reas.
163

REFERNCIAS BIBLIOGRFICAS

ABRAN, A. Functional size measurement methods: COSMIC-FFP:


design and fieldtrials. FESMA-AEMES Software Measurements Conference. [S.l.]:
[s.n.]. 2000.

ALBRECHT, A. J. Measuring Applications Development Productivity.


IBM Applic. Dev. Joint SHARE/GUIDE Symposium. Monterey: [s.n.]. 1979.

ALEXANDER, C. The Timeless Way of Building. New York: Oxford


University Press, 1979.

ALEXANDER, C. et al. The Oregon Experiment. New York: Oxford


University Press, 1975.

ALEXANDER, C. et al. A Pattern Language: Towns, Buildings,


Construction. New York: Oxford University Press, 1977.

ALLEN, P.; RAMACHANDRAN, M.; ABUSHAMAM, H. PRISMS: an


Approach to Software Process Improvement for Small to Medium Enterprises. Third
International Conference on Quality Software. [S.l.]: [s.n.]. 2003.

ALLEN, P.; RAMACHANDRAN, M.; ABUSHAMAM, H. PRISMS: an


Approach to Software Process Improvement for Small to Medium Enterprises. IEEE
Software, 2003.

ALMEIDA, R. Medio e Mtricas de Software. [S.l.]: [s.n.], 2007.

ALUR, D.; CRUPI, J.; MALKS, D. Core J2EE Patterns: Best Practices
and Design Strategies. [S.l.]: Prentice Hall, 2003.

ALVAREZ, F.; WEINTZEFELD, A. CMM Compliance in Small


Organizations. 15th Annual IRMA International. New Orleans: [s.n.]. 2004.

AMBLER, S. Process Patterns: Building Large-Scale Systems Using


Object Technology. [S.l.]: Cambridge University Press, 1998.
164

ANACLETO, A.; WANGENHEIM, C. Mtodo e Modelo de Avaliao


para Melhoria de Processos de Software em Micro e Pequenas Empresas. IV
Simpsio Brasileiro de Qualidade de Software. Porto Alegre: [s.n.]. 2005.

ANACLETO, A.; WANGENHEIM, C. G. V. Aplicando Mensurao em


Microempresas de Software para Suporte da Gerncia de Projetos. Simposio
Brasileiro de Qualidade de Software. Gramado: [s.n.]. 2002.

ANACLETO, A.; WANGENHEIM, C. G. V.; HAMMES, J. F.


Mensurao para o Suporte de Gerncia de Projetos em uma Micro Empresa de
Software. XIII Conferencia Internacional de Qualidade de Software. Curitiba: [s.n.].
2002.

ANDRADE, E. L. P.; OLIVEIRA, K. M. Uso Combinado de Anlise de


Pontos de Funo e Casos de Uso na Gesto de Estimativa de Tamanho de Projetos
de Software Orientado a Objetos. III Simpsio Brasileiro de Qualidade de Software.
Braslia: [s.n.]. 2004.

ANDRADE, R. et al. Uma Proposta de um Repositrio de Padres


Integrado ao RUP. SugarLoafPLoP. Porto de Galinhas: [s.n.]. 2003.

ANDRADE, T. D. C.; FREITAS, F. G.; SOUZA, J. T. Dificuldades,


Solues e Requisitos para a Implantao da Melhoria do Processo de Software
nas Micro e Pequenas Empresas. Infobrasil. Fortaleza: [s.n.]. 2008.

ANDRADE, T.; SOUZA, J. Uma Linguagem de Padres de Estimativa


de Software para Micro e Pequenas Empresas. SugarloafPloP. Fortaleza: [s.n.].
2008.

ANDRADE, T.; SOUZA, J. Processo de Medio para Micro e Pequenas


Empresas baseado em Padres. Infobrasil. Fortaleza: [s.n.]. 2009.

APPLETON, B. Patterns and Software: Essential Concepts and


Terminology, 1997. Disponivel em:
<http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html>. Acesso em: Junho
2009.
165

ARGAVAL, R. Estimating Software Projects. 4. ed. [S.l.]: Software


Engineering Notes, v. 26, 2001. 57-60 p.

BASILE, V.; CALDIERA, G.; ROMBACH, H. Goal Question Metric


Approach Paradigm. In: ______ Encyclppedia of Software Engineering. [S.l.]: John
Wiley & Sons, 1994. p. 528-532.

BASILI, V.; ROMBACH, H. Goal Question Metric Paradigm. [S.l.]:


Encyclopedia of Software Engineering, v. 2, 1994.

BOEHM, B. Software Cost Estimation with COCOMOII. [S.l.]: Prentice


Hall, 2000.

BORGES, E. P.; PAULA, W. P. Um Modelo de Medio para


Desenvolvimento de Doftware. Simposio Internacional de Melhoria de Processos de
Software. Recife: [s.n.]. 2003.

BRAGA, R. et al. Introduo aos Padres de Software. Universidade de


So Paulo. So Carlos. 2001.

BROWN, W. et al. AntiPatterns: Refactoring Software, Architectures, and


Projects in Crisis. [S.l.]: Wiley, 1995.

BUSCHMANN, F. et al. Pattern-Oriented Software Architecture


Volume 1: A System of Patterns. [S.l.]: Wiley, 1996.

CARDOSO, R. D. C. B. et al. Procedimento de Medio e Anlise do


Modelo para Pequenos Grupos. ProQuality - Qualidade na Produo de Software,
Lavras, v. 1, p. 47-55, Maio 2005.

COPLIEN, J. Advanced C++ Programming Styles and Idioms. Reading:


Addison-Wesley, 1991.

COPLIEN, J. A Development Process Generative Pattern Language.


Pattern Languages of Programs, Monticello, 1994.

COPLIEN, J. Generative pattern languages: An emerging direction of


software design. C++ Report, 1994. 18-22; 66-67.

COPLIEN, J. Software Patterns: A White Paper. SIGS Publication, 1996.


166

COPLIEN, J.; HARRISON, N. Organizational Patterns of Agile Software


Development. [S.l.]: Prentice Hall, 2004.

COPLIEN, J.; SCHMIDT, D. Pattern Language of Program Design.


[S.l.]: Addison-Wesley, 1995.

DEMARCO, T. Controlling Software Projects: Management


Measurement and Estimation. [S.l.]: Upper Saddle River: Yourdon Press, 1986.

DOD. Department of Defense and US Army. Practical Software and


Systems Measurement: A Foundation for Objective Project Management, Washington,
2003. Disponivel em: <http://www.psmsc.com>. Acesso em: 05 jan. 2009.

FENTON, N. Software Measurement: A Necessary Scientific Basis. In:


IEEE Transactions on Software Engineering, v. 20, March 1994.

FONTOURA, L.; PRICE, R. Usando GQM para Gerenciar Riscos em


Projetos de Software. XVIII Simpsio Brasileiro de Engenharia de Software. [S.l.]:
[s.n.]. 2004.

FOWLER, M. Analysis Patterns: Reusable Object Models. [S.l.]: Addison-


Wesley, 1997.

FRANCA, L.; STAAZ, A.; LUCENA, C. Medio de Software para


Pequenas Empresas: Uma Soluo Baseada na Web. XII Simpsio Brasileiro de
Engenharia de Software. Rio de janeiro: SBC. 1998. p. 71-84.

GABRIEL, R. Writers' Workshops & the Work of Making Things:


Patterns, Poetry. [S.l.]: Pearson Education, 2002.

GAMMA, E. et al. Design Patterns - Abstraction and Reuse of Object-


Oriented Design. LNCS, n. 707, p. 406-431, 1993.

GAMMA, E. et al. Design Patterns - Elements of Reusable Object-


Oriented Software. [S.l.]: Addison-Wesley, 1995.

GARCIA, P. R.; NUNES, D. J. APSEE-Metrics: um Modelo para


Mensurao em Processos de Software. Universidade Federal do Rio Grande do Sul.
Porto Algre. 2006. (599397).
167

GAVA, V. L. et al. Modelo do Processo de Media de Software: pr-


condies para sua aplicao. Fortaleza: [s.n.]. 2006.

HAUCK, J.; WANGENHEIM, C.; THIRY, M. Suportando a Modelagem


de Processo de Monitorao e Controle em Micro e Pequenas Empresas, alinhado
ao CMMI, MPS.BR e ISO/IEC 15504. VI Simpsio Brasileiro de Qualidade de
Software. [S.l.]: [s.n.]. 2007.

HAZAN, C. Implantao de um Processo de Medies de Software,


seguindo o Modelo CMMI. Rio de Janeiro: [s.n.]. 2004.

IEEE STD 1061. IEEE Standard for a Software Quality Metrics


MethodologyDescription, 1998. Disponivel em: <:
http://standards.ieee.org/reading/ieee/std_public/description/se/1061-1998_desc.html>.
Acesso em: 05 Junho 2008.

IFPUG. Function Point Counting Practices Manual. 4.1. ed. [S.l.]: [s.n.],
1999.

ISO/IEC 15939. Systems and Software Engineering - Measurement


Process, Switzerland, August 2007.

ISO/IEC 20.926. In: ______ Unadjusted functional size measurement -


Counting practices manual. [S.l.]: [s.n.], 2003.

JOHNSON, D.; BRODMAN, J. Tailoring the CMM for Small Businesses,


Small Organizations, and Small Projects. IEEE Computer Society, n. 8, 1997.

KANTORSKI, G. Z.; KROTH, M. L. Controle de Mtricas no Processo


de Desenvolvimento de Software atravs de uma Ferramenta de Workflow. I
Workshop de Computao - WORKCOMP-SUL. Florianpolis: [s.n.]. 2004.

KARNER, G. Metrics for Objectory. University of Linkping. Sweden.


1993. (LiTH-IDA-Ex-9344:21).

KAUTZ, K. Software, IEEE. Making Sense of Measurement for Small


Organizations, March 1999. 14-20.
168

KOLOSKI, R.; OLIVEIRA, K. M. Melhoria Contnua de Estimativa de


Esforo para o Desenvolvimento de Software: Uma Abordagem sobre Produtividade.
V Simpsio Brasileiro de Qualidade de Software. Vila Velha: [s.n.]. 2006. p. 409-423.

KRUCHTEN, P. Introduo ao RUP Rational Unified Process. 2. ed.


[S.l.]: Cincia Moderna, 2003.

LARYD, A.; ORCI, T. Dynamic CMM for Small Organizations.


Proceedings of the First Argentine Symposium on Software Engineering. Tandil,
Argentina: [s.n.]. 2000.

LEY, M. D.; GARCIA, F.; PIATTINI, M. Implementing a software


measurement program in small and medium enterprises: a suitable framework. IET
Institute of Engineering and Technology, v. 2, n. 5, p. 417-436, 2008.

MAIA, J. Use Mtricas Adequadas. Garanta a Qualidade de Projeto


Orientado a Objeto, 2006. Disponivel em:
<http://www.euax.com.br/art.00.index.shtml>. Acesso em: 10 dezembro 2008.

MCT. Ministrio de Cincia e Tecnologia. Pesquisa Nacional de


Qualidade e Produtividade no Setor de Software Brasileiro, Braslia, 2005.
Disponivel em: <http://www.mct.gov.br>. Acesso em: 06 novembrp 2008.

MELO, A. Requisitos de Ferramentas de Apoio aos Processos de


Medio de Software. Universidade Federal de Minas Gerais. Minas Gerais. 2007.

MESZAROS, G.; DOBLE, J. MetaPatterns: A Pattern Language for


Pattern Writing. Patterns Languages of Program Design, PLoP. [S.l.]: [s.n.]. 1996.

MONTEIRO, T. Pontos de Caso de Uso Tcnicos TUCP: Uma


extenso do UCP. Universidade de Fortaleza. Fortaleza. 2005.

PADUA, W. Engenharia de Software: Fundamentos, Mtodos e Padres.


3. ed. Rio de Janeiro: LCT, 2009. ISBN 9788521616504.

PETERS, J.; PEDRYCK, W. Engenharia de Software. [S.l.]: Campus,


2000.
169

PFLEEGER, S. L.; ROMBACH, H. Measurement based Process


Improvement. IEEE Software, 1994.

PMI. Um Guia do Conjunto de Conhecimentos do Gerenciamento de


Projetos - PMBOK. Traduo de ingls. [S.l.]: Project Management Institute, 2009.

PORTAL GREAT. Universidade Federal do Cear, 2009. Disponivel em:


<http://www.great.ufc.br/>. Acesso em: 11 out. 2009.

PRESSMAN, R. Engenharia de Software. [S.l.]: Makron Books, 2006.

REVANKAR, A.; MITHARE, R.; NALLAGONDA, V. Accelerated


Process Improvements for Small Settings. Proceedings of the First International
Research Workshop for Process Improvement in Small Settings Process Improvement
Approaches and Models. [S.l.]: [s.n.]. 2006.

RICHARDSON, I.; WANGENHEIM, C. Why Are Small Software


Organizations Different?. IEEE Software, January 2007.

ROCHA, A.; MALDONARO, J.; WEBER, K. Qualidade de Software


Teoria e Prtica. 1. ed. So Paulo: Prentice Hall, 2001. ISBN 85-87918-54-0.

RUIZ, K.; FIGUEIRA, F. Minerao em Mtricas de Software. Escola


Regional de Banco de Dados. Porto Alegre: [s.n.]. 2007.

SCHMIDT, D. et al. Pattern-Oriented Software Architecture Volume 2:


Patterns for Concurrent and Networked Objects. [S.l.]: Wiley, 2000.

SCHNAIDER, L. et al. Uma Abordagem para Medio e Anlise em


Projetso de Software. Simpsio Brasileiro de Qualidade de Software. Salvador: [s.n.].
2004.

SCHWABER, K. Agile Project Management with Scrum. [S.l.]:


Microsoft Press, 2004.

SEI. CMMI for Development. Software Engineering Institute. [S.l.]. 2006.


CMU/SEi-2006-TR-008.
170

SOFTEX. MPS.BR Melhoria de Processo do Software Brasileiro. Guia


Geral: 2009, Braslia, 2009a. Disponivel em: <http://www.softex.br/mpsbr>. Acesso
em: 10 outubro 2009.

SOFTEX. MPS.BR Melhoria de Processo do Software Brasileiro. Guia de


Implementao - Parte 1: Nvel G:2009, 2009b. Disponivel em:
<http://www.softex.br/mpsbr>. Acesso em: 10 outubro 2009.

SOFTEX. MPS.BR Melhoria de Processo do Software Brasileiro. Guia de


Implementao - Parte 2: Nvel F:2009, 2009c. Disponivel em:
<http://www.softex.br/mpsbr>. Acesso em: 10 outubro 2009.

SOMMERVILLE, I. Engenharia de Software. 8. ed. So Paulo: Pearson


Addison Wesley, 2009. ISBN 9788588639287.

STAA, A. V.; HAZAN, C. Anlise e Melhoria de um Processo de


Estimativas de Tamanho de Projetos de Software. VI Simposio Internacional de
Melhoria de Processos de Software. So Paulo: [s.n.]. 2004. p. 33-44.

SYMONS, C. R. Software Sizing and Estimation: MK II FPA. [S.l.]:


Wiley-Interscience, 1991. ISBN 978-0471929857.

VASQUEZ, C. E. Anlise de ponto de funo: medio, estimativas e


gerenciamento de projetos de software. 1. ed. So Paulo: rica, 2003.

VLISSIDES, J. Patterns: The Top Ten Misconceptions. Object Magazine,


1990. Disponivel em: <http://hillside.net/patterns/papersbibliographys.htm>. Acesso
em: Junho 2009.

WANGENHEIM, C. G.; PUNTER, T.; ANACLETO, A. Software


Measurement for Small and Medium Enterprises. 7th International Conference on
Empirical Assessment in Software Enfineering. Keele, UK: [s.n.]. 2003.

WEBER, S.; HAUCK, J. C. R.; WANGENHEIM, C. G. V. Estabelecendo


Processo de Software em Micro e Pequenas Empresas. SBQS. [S.l.]: [s.n.]. 2005.
171

APNDICE A ProMePE: Plano de Medio de Referncia

Descrio do Plano de Medio de Referncia

Seo Descrio
Histrico de Revises Histrico de alteraes do plano
Lista das Necessidades de Informao Objetivos da medio de acordo com o perfil do projeto
Descrio das Medidas Base Medidas simples, com uma funo
Descrio das Medidas Derivadas Medidas derivadas das medidas base, mais de uma funo

Procedimento de Coleta de Dados Frequncia, fase e responsvel pela coleta

Procedimento de Anlise dos Dados Frequncia, fase e responsvel pela anlise

Mecanismos Mecanismos de divulgao e anlise dos indicadores

Referncias
<Coloque aqui as referncias utilizadas>
172

Histrico de Revises

Data Verso Descrio Autor


<dd/mm/aa> <numero da verso> <descrio da alterao> <responsvel pela alterao>

Lista das Necessidades de Informao

Necessidade de Informao Categoria da Informao


Quantas tarefas esto atrasadas? Progresso do Cronograma
Qual a estimativa de tamanho do projeto? Tamanho
Qual a estimativa de esforo total do projeto comparado com o realizado?
Esforo
Qual a estimativa de esforo comparado com o realizado no perodo?
Esforo
Qual a estimativa de prazo total do projeto comparado com o realizado?
Prazo
Qual a estimativa de custo total de projeto comparado com o realizado?
Custo
O quo estvel esto os requisitos? Estabilidade dos Requisitos
Como est o andamento dos testes? Defeitos
173

Descrio das Medidas Base

Necessidade de Informao Medidas Base Unidade de Medio


Datas do inicio do planejamento dias
Datas do fim do planejamento dias
Quantas tarefas esto atrasadas?
Datas do inicio real dias
Datas do fim real dias
Classificao das transaes por complexidade e atribuio de pesos para cada inteiro
complexidade (FF)
Qual a estimativa de tamanho do projeto?
Total de Fatores Tcnicos No Funcionais (FTNF) inteiro

Produtividade da Equipe (PROD) horas/tamanho


Qual a estimativa de esforo total do projeto Estimativa de Tamanho Total (ETT) inteiro
comparado com o realizado?
Quantidade total de horas realizadas pela equipe (ESF_REAL) horas

Qual a estimativa de esforo comparado com o Esforo Planejado no Perodo horas


realizado no perodo? Esforo Realizado no Perodo horas
174

Descrio das Medidas Base - Continuao

Necessidade de Informao Medidas Base Unidade de Medio


Estimativa de Esforo Total (ESF) horas
Quantidade de Recursos humanos no projeto (QtdRD) inteiro
Qual a estimativa de prazo total do projeto
comparado com o realizado? Carga horria diria de cada recurso (VlrJTRAB) horas/dia

Quantidade total de horas realizadas pela equipe (ESF_REAL) horas

Estimativa de Esforo Total (ESF) horas

Qual a estimativa de custo total de projeto Porcentagem de Esforo por Papel (P) %
comparado com o realizado? Valor da Hora de Trabalho por Papel (VlrHORA) reais

Quantidade total de horas realizadas pela equipe (ESF_REAL) reais


Quantidade total de requisitos aprovados inteiro

Quantidade de novos requisitos inteiro


O quo estvel esto os requisitos? Quantidade de requisitos modificados inteiro

Estimativa de esforo para modificao dos requisitos horas


Esforo realizado para modificao dos requisitos horas

Quantidade total de defeitos inteiro


Como est o andamento dos testes? Quantidade de defeitos corrigidos inteiro
Esforo para correo de cada defeito horas
175

Descrio das Medidas Derivadas

Medidas Base Medidas Derivadas Funo de Medio


1. Soma do nmero de tarefas planejadas cuja data final menor ou
Datas do inicio do planejamento 1. Total de Tarefas Planejadas
igual que o periodo que se deseja comparar.
2. Soma do nmero de tarefas em execuo cuja data final menor ou
Datas do fim do planejamento 2. Total de Tarefas em Execuo
igual que o periodo que se deseja comparar.
Datas do incio real 3.((Total de Tarefas Atuais - Total de Tarefas Planejadas)/Total de
3. % Concluso das Tarefas
Datas do fim real Tarefas Planejadas)*100
Classificao das transaes por complexidade e atribuio de 1. Utilize a Tabela 1 para classificao das transaes por
pesos para cada complexidade (FF) complexidade e atribuio dos pesos (FF). A tabela 1 possui valores
padres de pesos que podem ser calibrados.
1. Estimativa de Tamanho Total
(ETT) 2. Utilize a Tabela 2 para o clculo dos Fatores Tnicos No-
Total de Fatores Tcnicos No Funcionais (FTNF) Funcionais (FTNF).
FTNF = 0.65+(Soma(Ni)x0.01)
3. ETT=FFxFTNF
1. Estimativa de Esforo Total do
Produtividade da Equipe (PROD) Projeto (ESF) 1. ESF = PRODxETT
Estimativa de Tamanho Total (ETT)
2. Total de Horas Trabalhadas 2. ESF_REAL = Soma da quantidade de horas trabalhadas por todos os
durante o projeto membros do projeto
Quantidade total de horas realizadas pela equipe (ESF_REAL)
3. Variancia entre o estimado e o 3. ESF_VAR = (ESF_REAL-ESF)/ESF
realizado (ESF_VAR)
176

Descrio das Medidas Derivadas Continuao

Medidas Base Medidas Derivadas Funo de Medio


Estimativa de Esforo Total (ESF)

Quantidade de Recursos humanos no projeto (QtdRD) 1. Estimativa de Prazo Total (EPRZ) 1. EPRZ = (ESF)/SOMA(QtdRDxVlrJTRAB)

Carga horria diria de cada recurso (VlrJTRAB)


2. Prazo Real de Entrega
Quantidade total de horas realizadas pela equipe (ESF_REAL) (PRZ_REAL) 2. PRZ_REAL = (ESF_REAL)/SOMA(QtdRDxVlrJTRAB)

Estimativa de Esforo Total (ESF)

Porcentagem de Esforo por Papel (P)


1. Estimativa de Custo Total 1. CUSTO = SOMA (ESFxPxVlrHORA). A Tabela 3 possui uma
(CUSTO) porcentagem de esforo por papel pr-definida
Valor da Hora de Trabalho por Papel (VlrHORA)

2. Custo Real do Projeto 2. CUSTO_REAL = SOMA(ESF_REALxPxVlrHORA)


(CUSTO_REAL)
Quantidade total de horas realizadas pela equipe (ESF_REAL) 3. Varincia entre o custo estimado e o
realizado (CUSTO_VAR) 3. CUSTO_VAR = (CUSTO_REAL-CUSTO)/CUSTO

1. (Qtd Novos Requisitos/Qtd Total Requisitos Aprovados)x100


Quantidade total de requisitos aprovados
1. % Requisitos em Crescimento
Quantidade de novos requisitos
2. (Qtd Requisitos Modificados/Qtd Total de Requisitos
Quantidade de requisitos modificados 2. % Requisitos Modificados Aprovados)x100
3. Impacto estimado das mudanas de 3. Soma das horas estimadas das mudanas de requisitos no
Estimativa de esforo para modificao dos requisitos perodo
requisitos no perodo
177

Descrio das Medidas Derivadas Continuao

Medidas Base Medidas Derivadas Funo de Medio


4. Impacto real das mudanas de 4. Soma das horas realizadas das mudana de requisitos no perodo
Esforo realizado para modificao dos requisitos
requisitos
Quantidade total de defeitos 1. Qtd Defeito por Requisito 1. Soma da quantidade de defeitos por requisito
2. Qtd Requisitos Corrigidos no 2. Soma da quantidade de defeitos corrigidos no periodo
Quantidade de defeitos corrigidos perodo
3. Quantidade de horas para 3. Soma das horas realizadas para correo dos defeitos
Esforo para correo de cada defeito correo dos defeitos
178

Tabelas de Apoio s Medidas

Tabela 1 - Fatores Tcnicos Funcionais (FF) Tabela 2 - Fatores Tcnicos No-Funcionais (FTNF)

Grupos de Transaes Complexidade Quantidade Peso Caracterstica Nota


Baixa Q1 3 Processamento Distribudo N1
TED Mdia Q2 4 Desempenho N2
Alta Q3 6
Eficincia do Usurio N3
Baixa Q4 4
Processamento Complexo N4
TSD Mdia Q5 5
Reusabilidade N5
Alta Q6 7
Facilidade de Instalao N6
Baixa Q7 3
Usabilidade N7
TCD Mdia Q8 4
Portabilidade N8
Alta Q9 6
Facilidade de Manuteno N9
Baixa Q10 5
Mdia Q11 7 Concorrncia N10
TEX
Alta Q12 10
Baixa Q13 7
TPD Mdia Q14 10
Alta Q15 15

Tabela 4 - Esforo por Disciplina Tabela 3 - Esforo por Papel

Disciplina Percentual de Esforo Papel Percentual de Esforo


Requisitos 20% Gerente de Projeto 10 15%
Anlise Projeto 20%
Analista de Sistemas 15 20 %
Implementao 35% Projetista/Arquiteto 15 20%
Testes 15% Desenvolvedor 25 30 %
Gerencia de Projeto 10% Testador 10 15%
179

Procedimento de Coleta dos Dados

Frequncia da Ferramenta Utilizada na


Medidas Derivadas Fase da Coleta Responsvel pela Coleta
Coleta Coleta dos Dados
Equipe e Gerente de Projeto
1. Total de Tarefas Planejadas Mensalmente Todas MS Project

2. Total de Tarefas em Execuo Mensalmente Todas Equipe e Gerente de Projeto MS Project


Equipe e Gerente de Projeto
3. % Concluso das Tarefas Mensalmente Todas MS Project
1 vez Incio do projeto: final da iniciao ou aps a Equipe e Gerente de Projeto Planilha de Anlise e Coleta de
1. Estimativa de Tamanho Total (ETT) primeira iterao da fase de elaborao Dados, seo Tamanho
Funcional
1. Estimativa de Esforo Total do Projeto Incio do projeto: final da iniciao ou aps a Equipe e Gerente de Projeto
1 vez MS Project/Excel
(ESF) primeira iterao da fase de elaborao
2. Total de Horas Trabalhadas durante o Equipe e Gerente de Projeto
Semalmente Todas MS Project/Excel
projeto
3. Variancia entre o estimado e o Equipe e Gerente de Projeto
Mensalmente Todas MS Project/Excel
realizado (ESF_VAR)
Incio do projeto: final da iniciao ou aps a
1. Estimativa de Prazo Total (EPRZ) 1 vez Gerente de Projeto MS Project/Excel
primeira iterao da fase de elaborao
2. Prazo Real de Entrega (PRZ_REAL) Semalmente Todas Gerente de Projeto MS Project/Excel
Incio do projeto: final da iniciao ou aps a
1. Estimativa de Custo Total (CUSTO) 1 vez Gerente de Projeto Excel
primeira iterao da fase de elaborao
2. Custo Real do Projeto
Mensalmente Todas Gerente de Projeto Excel
(CUSTO_REAL)
3. Varincia entre o custo estimado e o
Mensalmente Todas Gerente de Projeto Excel
realizado (CUSTO_VAR)
Analista de Sistemas e
1. % Requisitos em Crescimento Mensalmente Todas Excel
Gerente de Projeto
Analista de Sistemas e
2. % Requisitos Modificados Mensalmente Todas Excel
Gerente de Projeto
180

Procedimento de Coleta dos Dados - Continuao

Frequncia da Ferramenta Utilizada na


Medidas Derivadas Fase da Coleta Responsvel pela Coleta
Coleta Coleta dos Dados

3. Impacto estimado das mudanas de


Mensalmente Todas Equipe e Gerente de Projeto Excel
requisitos no perodo

4. Impacto real das mudanas de


Mensalmente Todas Equipe e Gerente de Projeto Excel
requisitos

1. Qtd Defeito por Requisito Mensalmente Todas Equipe e Gerente de Projeto Excel

2. Qtd Requisitos Corrigidos no perodo Mensalmente Todas Equipe e Gerente de Projeto Excel

3. Quantidade de horas para correo dos


Mensalmente Todas Equipe e Gerente de Projeto Excel
defeitos
181

Procedimento de Anlise dos Dados

Frequncia da Ferramenta Utilizada


Medidas Derivadas Fase da Anlise Responsvel pela Anlise Critrio de Deciso - Indicador
Anlise na Anlise dos Dados
1. Total de Tarefas Planejadas Mensalmente Todas Gerente de Projeto MSProject/Excel
A quantidade de tarefas executadas
2. Total de Tarefas em Execuo Mensalmente Todas Gerente de Projeto MSProject/Excel no podem ser menor que 15% da
quantidade de tarefas planejadas
3. % Concluso das Tarefas Mensalmente Todas Gerente de Projeto MSProject/Excel
Incio do projeto: final
1. Estimativa de Tamanho Total da iniciao ou aps a
Incio do projeto Gerente de Projeto Excel No possui
(ETT) primeira iterao da
fase de elaborao
1. Estimativa de Esforo Total do
Incio do projeto Todas Gerente de Projeto Excel
Projeto (ESF) O esforo realizado no pode ser
2. Total de Horas Trabalhadas menor que 20% do estimado
Semalmente Todas Gerente de Projeto Excel
durante o projeto

3. Variancia entre o estimado e o


Mensalmente Todas Gerente de Projeto Excel No pode ser maior que 20%
realizado (ESF_VAR)
1. Estimativa de Prazo Total
Incio do projeto Todas Gerente de Projeto Excel
(EPRZ) O prazo final de entrega no pode
2. Prazo Real de Entrega ser maior que 30% do estimado
Semalmente Todas Gerente de Projeto Excel
(PRZ_REAL)
1. Estimativa de Custo Total
Incio do projeto Todas Gerente de Projeto Excel No possui
(CUSTO)
2. Custo Real do Projeto
Mensalmente Todas Gerente de Projeto Excel
(CUSTO_REAL)
O custo real no pode ser maior que
3. Varincia entre o custo 20% do estimado
estimado e o realizado Mensalmente Todas Gerente de Projeto Excel
(CUSTO_VAR)
Grfico que mostra o crescimento
1. % Requisitos em Crescimento Mensalmente Todas Gerente de Projeto Excel
dos requisitos ao longo do tempo
182

Procedimento de Anlise dos Dados Continuao

Frequncia da Responsvel pela Ferramenta Utilizada


Medidas Derivadas Fase da Anlise Critrio de Deciso Indicador
Anlise Anlise na Anlise dos Dados
Grfico que mostra a porcentagem de
2. % Requisitos Modificados Mensalmente Todas Gerente de Projeto Excel
requisitos modificados ao longo do tempo
3. Impacto estimado das
Grfico que mostra a estimativa de esforo
mudanas de requisitos no Mensalmente Todas Gerente de Projeto Excel
das mudanas ao longo do tempo
perodo
4. Impacto real das mudanas de Grfico que mostra o esforo real das
Mensalmente Todas Gerente de Projeto Excel
requisitos mudanas ao longo do tempo
Grfico que mostra a quantidade de defeito
1. Qtd Defeito por Requisito Mensalmente Todas Gerente de Projeto Excel
por requisito

2. Qtd Requisitos Corrigidos no Grfico que mostra a quantidade atual de


Mensalmente Todas Gerente de Projeto Excel
perodo defeitos corrigidos versus o total no periodo

3. Quantidade de horas para Grfico que mostra o esforo realizado para


Mensalmente Todas Gerente de Projeto Excel
correo dos defeitos correo dos defeitos no perodo
183

Mecanismo de Divulgao dos Indicadores

Medidas Derivadas Mecanismo Indicador(es) Interessado(s) Periodicidade Responsvel(eis)


1. Total de Tarefas Planejadas Divulgao da Planilha de Todos da Aba de Progresso Todos os
Ao fim de cada
2. Total de Tarefas em Execuo Anlise dos Dados. Seo de Cronograma da Planilha membros do Gerente de Projeto
Iterao do projeto
3. % Concluso das Tarefas Progresso do Cronograma de Anlise dos Dados projeto
Divulgao da Planilha de Todos os
1. Estimativa de Tamanho Total No inicio do
Anlise dos Dados. Seo No possui membros do Gerente de Projeto
(ETT) projeto
Tamanho Funcional projeto
1. Estimativa de Esforo Total do
Projeto (ESF) Divulgao da Planilha de Todos da Aba de Esforo Todos os
Anlise dos Dados. Seo da Planilha de Anlise dos membros do Mensalmente Gerente de Projeto
2. Total de Horas Trabalhadas
Esforo Dados projeto
durante o projeto
Divulgao da Planilha de Todos da Aba de Esforo Todos os
3. Variancia entre o estimado e o
Anlise dos Dados. Seo da Planilha de Anlise dos membros do Mensalmente Gerente de Projeto
realizado (ESF_VAR)
Esforo Dados projeto
1. Estimativa de Prazo Total Todos os
(EPRZ) Divulgao da Planilha de Todos da Aba de Esforo
membros do
Anlise dos Dados. Seo da Planilha de Anlise dos Mensalmente Gerente de Projeto
2. Prazo Real de Entrega projeto e o
Prazo Dados
(PRZ_REAL) cliente
1. Estimativa de Custo Total
(CUSTO)
2. Custo Real do Projeto Divulgao da Planilha de Todos da Aba de Custo da
(CUSTO_REAL) Anlise dos Dados. Seo Planilha de Anlise dos Alta gerncia Mensalmente Gerente de Projeto
Custo Dados
3. Varincia entre o custo estimado
e o realizado (CUSTO_VAR)
184

Mecanismo de Divulgao dos Indicadores - Continuao

Medidas Derivadas Mecanismo Indicador(es) Interessado(s) Periodicidade Responsvel(eis)

1. % Requisitos em Crescimento

2. % Requisitos Modificados Todos da Aba de


Divulgao da Planilha dos Todos da equipe.
Estabilidade de Requisitos
Dados. Seo Estabilidade dos Alta gerncia. Mensalmente Gerente de Projeto
3. Impacto estimado das mudanas da Planilha de Anlise dos
Requisitos Cliente
de requisitos no perodo Dados

4. Impacto real das mudanas de


requisitos

1. Qtd Defeito por Requisito


Todos da Aba de
Divulgao da Planilha dos
2. Qtd Requisitos Corrigidos no Estabilidade de Requisitos
Dados. Seo Estabilidade dos Todos da equipe Mensalmente Gerente de Projeto
perodo da Planilha de Anlise dos
Requisitos
3. Quantidade de horas para Dados
correo dos defeitos
185

APNDICE B ProMePE: Plano de Medio do Projeto (Estudo de Caso)

Lista de Necessidades de Informao do Projeto

Necessidade de Informao Categoria da Informao


Quantas tarefas esto atrasadas? Progresso do Cronograma
Qual a estimativa de tamanho total e por caso de uso do
projeto? Tamanho Funcional
Qual a estimativa de esforo total do projeto comparado com o
realizado? Esforo
Qual a estimativa de esforo por caso de uso para cada
disciplina comparado com o realizado? Esforo
Qual a estimativa de esforo comparado com o realizado no
perodo? Esforo
Qual a estimativa de esforo total previsto no contrato
comparado com o realizado? Esforo
Qual a estimativa de prazo total do projeto comparado com o
realizado? Prazo
Qual a estimativa de custo previsto no contrato comparado
com o realizado no perodo? Custo
O quo estvel esto os requisitos? Estabilidade dos Requisitos
Como est o andamento dos testes? Defeitos
186

Descrio das Medidas Base do Projeto

Necessidade de Informao Medidas Base Unidade de Medio


Datas do inicio do planejamento dias
Datas do fim do planejamento dias
Quantas tarefas esto atrasadas?
Datas do inicio real dias
Datas do fim real dias

Classificao das transaes de cada caso de uso de acordo com a sua


Qual a estimativa de tamanho total e por caso de inteiro
complexidade e atribuio de pesos para cada complexidade (FF)
uso do projeto?
Total de Fatores Tcnicos No Funcionais (FTNF) inteiro
Produtividade da Equipe (PROD) horas/tamanho
Qual a estimativa de esforo total do projeto Estimativa de Tamanho Total (ETT) inteiro
comparado com o realizado?
Quantidade total de horas realizadas pela equipe (ESF_REAL) horas

Qual a estimativa de esforo por caso de uso para Estimativa de Tamanho por Caso de Uso (ETT_CASO_USO) inteiro
cada disciplina comparado com o realizado? Porcentagem de Esforo por disciplina (P_ESF) %
Qual a estimativa de esforo comparado com o Esforo planejado no perodo horas
realizado no perodo? Esforo realizado no perodo horas
Qual a estimativa de prazo total do projeto
Esforo total previsto nos contratos (ESF_CONTRATO) horas
comparado com o realizado?
Esforo estimado total (ESF) horas
Quantidade de Recursos humanos no projeto (QtdRD) inteiro
Qual a estimativa de prazo total do projeto Carga horria diria de cada recurso (VlrJTRAB) horas/dia
comparado com o realizado?
Quantidade total de horas realizadas pela equipe (ESF_REAL) horas
187

Descrio das Medidas Base do Projeto - Continuao

Necessidade de Informao Medidas Base Unidade de Medio


Esforo Total Previsto no Contrato (ESF_CONTRATO) horas
Qual a estimativa de custo previsto no contrato Porcentagem de Esforo por Papel (P) %
comparado com o realizado no perodo? Valor da Hora de Trabalho por Papel (VlrHORA) reais
Quantidade total de horas realizadas pela equipe (ESF_REAL) reais
Quantidade de requisitos modificados inteiro
O quo estvel esto os requisitos?
Estimativa de esforo para modificao dos requisitos horas
Quantidade total de defeitos inteiro
Como est o andamento dos testes?
Tamanho por Caso de Uso inteiro
188

Descrio das Medidas Derivadas do Projeto

Medidas Base Medidas Derivadas Funo de Medio


1. Soma do nmero de tarefas planejadas cuja data final menor ou igual que o periodo que
Datas do inicio do planejamento 1. Total de Tarefas Planejadas
se deseja comparar.
2. Soma do nmero de tarefas em execuo cuja data final menor ou igual que o periodo
Datas do fim do planejamento 2. Total de Tarefas em Execuo
que se deseja comparar.
Datas do inicio real
3. % Concluso das Tarefas 3.((Total de Tarefas Atuais - Total de Tarefas Planejadas)/Total de Tarefas Planejadas)*100
Datas do fim real
Classificao das transaes de cada 1. Classificar as transaes por complexidade de cada caso de uso e atribuio dos pesos
caso de uso de acordo com a sua (FF). A tabela 1, Apndice A, possui valores padres de pesos que podem ser calibrados.
complexidade e atribuio de pesos para
cada complexidade (FF)
1. Estimativa de Tamanho Total
(ETT)
2. Utilizar a Tabela 2, Apndice A, para o clculo dos Fatores Tnicos No-Funcionais
Total de Fatores Tcnicos No
(FTNF).
Funcionais (FTNF)
FTNF = 0.65+(Soma(Ni)x0.01)
3. ETT=FFxFTNF
1. Estimativa de Esforo Total do
Produtividade da Equipe (PROD) Projeto (ESF) 1. ESF = PRODxETT
Estimativa de Tamanho Total (ETT)
2. Total de Horas Trabalhadas durante 2. ESF_REAL = Soma da quantidade de horas trabalhadas por todos os membros do
Quantidade total de horas realizadas o projeto no perodo projeto no perodo
pela equipe (ESF_REAL) 3. Variao entre o estimado e o 3. ESF_VAR = (ESF_REAL-ESF)/ESF
realizado (ESF_VAR)
Estimativa de Tamanho por Caso de 4. Estimativa de Esforo por Caso de
4. ESF_CASO_USO = PRODxETT_CASO_USO
Uso (ETT_CASO_USO) Uso (ESF_CASO_USO)

Porcentagem de Esforo por disciplina 5. Estimativa de Esforo de cada caso 5. ESF_DISP = PRODxETT_CASO_USOxP_ESF. Utilizar porcentagem por disciplina
(P_ESF) de uso por disciplina (ESF_DISP) presente na Tabela 5
189

Descrio das Medidas Derivadas do Projeto Continuao

Medidas Base Medidas Derivadas Funo de Medio


6. Quant. de horas previstas no
8. Soma das horas previstas no perodo do contrato (ESF_CONTRATO)
Esforo total previsto nos contratos contrato
(ESF_CONTRATO) 7. Variao entre o realizado e o
ESF_VAR_CONT = (ESF_REAL-ESF_CONTRATO)/ESF_CONTRATO
estimado no contrato

Esforo estimado total (ESF)

Quantidade de Recursos humanos no


1. Estimativa de Prazo Total (EPRZ) 1. EPRZ = (ESF)/SOMA(QtdRDxVlrJTRAB)
projeto (QtdRD)
Carga horria diria de cada recurso
(VlrJTRAB)
Quantidade total de horas realizadas 2. Prazo Real de Entrega
2. PRZ_REAL = (ESF_REAL)/SOMA(QtdRDxVlrJTRAB)
pela equipe (ESF_REAL) (PRZ_REAL)
Esforo Total Previsto no Contrato
(ESF_CONTRATO)
1. Estimativa de Custo Total Previsto
Porcentagem de Esforo por Papel (P) 1. CUSTO_CONTRATO = SOMA (ESF_CONTRATOxP_CONTRATOxVlrHORA).
no Contrato (CUSTO_CONTRATO)
Valor da Hora de Trabalho por Papel
(VlrHORA)
Quantidade total de horas realizadas 2. Custo Real do Projeto
2. CUSTO_REAL = SOMA(ESF_REAL_PAPELxVlrHORA)
pela equipe (ESF_REAL) (CUSTO_REAL)

Quantidade de requisitos modificados 1. % Requisitos Modificados 2. (Qtd Requisitos Modificados/Qtd Total de Requisitos Aprovados)x100

Estimativa de esforo para modificao 2. Impacto estimado das mudanas de


3. Soma das horas estimadas das mudanas de requisitos no perodo
dos requisitos requisitos no perodo

Quantidade total de defeitos 1. Qtd Defeito por caso de uso 1. Soma da quantidade de defeitos por caso de uso

2. Porcentagem de defeito por caso de


Tamanho por Caso de Uso 2. (Quantidade de Defeito por Caso de Uso/Tamanho do caso de uso)*100
uso
190

Tabela 5 Percentual de Esforo por Papel

Papel Percentual de Esforo


Coordenador do Projeto 1%
Analista de Sistemas 46%

Gerente de Projeto 4%
Projetista 0%
Arquiteto 0%
Desenvolvedor 49%
Testador 0,00%

Tabela 6 Percentual de Esforo por Disciplina

Disciplina Percentual de Esforo


Requisitos 20%
Anlise Projeto 20%
Implementao 35%
Testes 15%
Gerencia de Projeto 10%
191

Procedimento de Coleta dos Dados do Projeto

Frequncia da Ferramenta Utilizada na Coleta


Medidas Derivadas Fase da Coleta Responsvel pela Coleta
Coleta dos Dados

1. Total de Tarefas Planejadas Semanalmente Todas Equipe e Gerente de Projeto MS Project

2. Total de Tarefas em Execuo Semanalmente Todas Equipe e Gerente de Projeto MS Project

3. % Concluso das Tarefas Semanalmente Todas Equipe e Gerente de Projeto MS Project

Incio do projeto: final da iniciao


Planilha de Anlise e Coleta de
1. Estimativa de Tamanho Total (ETT) 1 vez ou aps a primeira iterao da fase Equipe e Gerente de Projeto
Dados, seo Tamanho Funcional
de elaborao
Incio do projeto: final da iniciao
1. Estimativa de Esforo Total do
1 vez ou aps a primeira iterao da fase Equipe e Gerente de Projeto MS Project/Excel
Projeto (ESF)
de elaborao
2. Total de Horas Trabalhadas durante o
Semalmente Todas Equipe e Gerente de Projeto MS Project/Excel
projeto no perodo
3. Variao entre o estimado e o
Mensalmente Todas Gerente de Projeto MS Project/Excel
realizado (ESF_VAR)
1 vez ou quando
4. Estimativa de Esforo por Caso de
houver mudana de Todas Equipe e Gerente de Projeto MS Project/Excel
Uso (ESF_CASO_USO)
requisito
1 vez ou quando
5. Estimativa de Esforo de cada caso
houver mudana de Todas Equipe e Gerente de Projeto MS Project/Excel
de uso por disciplina (ESF_DISP)
requisito

6. Quant. de horas previstas no contrato 1 vez No incio do projeto Gerente de Projeto Excel

7. Variao entre o realizado e o


Mensalmente Todas Gerente de Projeto MS Project/Excel
estimado no contrato
192

Procedimento de Coleta dos Dados - Continuao

Frequncia da Ferramenta Utilizada na Coleta


Medidas Derivadas Fase da Coleta Responsvel pela Coleta
Coleta dos Dados
Incio do projeto: final da iniciao
1. Estimativa de Prazo Total (EPRZ) 1 vez ou aps a primeira iterao da fase Gerente de Projeto MS Project/Excel
de elaborao

2. Prazo Real de Entrega (PRZ_REAL) Semalmente Todas Gerente de Projeto MS Project/Excel

Incio do projeto: final da iniciao


1. Estimativa de Custo Total Previsto no
1 vez ou aps a primeira iterao da fase Gerente de Projeto Excel
Contrato (CUSTO_CONTRATO)
de elaborao
2. Custo Real do Projeto
Mensalmente Todas Gerente de Projeto Excel
(CUSTO_REAL)
Analista de Sistemas e Gerente
1. % Requisitos Modificados Mensalmente Todas Excel
de Projeto

2. Impacto estimado das mudanas de


Mensalmente Todas Equipe e Gerente de Projeto Excel
requisitos no perodo

1. Qtd Defeito por caso de uso Mensalmente Todas Equipe e Gerente de Projeto Excel

2. Porcentagem de defeito por caso de


Mensalmente Todas Equipe e Gerente de Projeto Excel
uso
193

Procedimento de Anlise dos Dados do Projeto

Frequncia da Responsvel pela Ferramenta Utilizada


Medidas Derivadas Fase da Anlise Critrio de Deciso - Indicador
Anlise Anlise na Anlise dos Dados

1. Total de Tarefas Planejadas Semanalmente Todas Gerente de Projeto MSProject/Excel


A quantidade de tarefas executadas
2. Total de Tarefas em
Semanalmente Todas Gerente de Projeto MSProject/Excel no podem ser menor que 15% da
Execuo
quantidade de tarefas planejadas
3. % Concluso das Tarefas Semanalmente Todas Gerente de Projeto MSProject/Excel

Incio do projeto: final da iniciao


1. Estimativa de Tamanho Total
Incio do projeto ou aps a primeira iterao da fase Gerente de Projeto Excel No possui
(ETT)
de elaborao
1. Estimativa de Esforo Total
Incio do projeto Todas Gerente de Projeto Excel
do Projeto (ESF)
O esforo realizado no pode ser
2. Total de Horas Trabalhadas menor que 20% do estimado
Semalmente Todas Gerente de Projeto Excel
durante o projeto no perodo

3. Variao entre o estimado e o A variao entre o estimado e o


Semalmente Todas Gerente de Projeto Excel
realizado (ESF_VAR) realizado no pode passar de 20%

Incio do Projeto Incio do projeto: final da iniciao


4. Estimativa de Esforo por
ou quando ou aps a primeira iterao da fase
Caso de Uso Gerente de Projeto Excel No possui
houver mudana de elaborao ou quando houver
(ESF_CASO_USO)
de requisitos mudana de requisitos

Incio do Projeto
5. Estimativa de Esforo de
ou quando
cada caso de uso por disciplina Todas Gerente de Projeto Excel No possui
houver mudana
(ESF_DISP)
de requisitos
194

Procedimento de Anlise dos Dados do Projeto - Continuao

Frequncia da Responsvel pela Ferramenta Utilizada


Medidas Derivadas Fase da Anlise Critrio de Deciso - Indicador
Anlise Anlise na Anlise dos Dados

6. Quant. de horas previstas no


1 vez Incio do Projeto Gerente de Projeto Excel No possui
contrato

7. Variao entre o realizado e O realizado no pode ser maior que


Mensalmente Todas Gerente de Projeto Excel
o estimado no contrato 10% do previsto no contrato

1. Estimativa de Prazo Total


Incio do projeto Todas Gerente de Projeto Excel
(EPRZ) O prazo final de entrega no pode
2. Prazo Real de Entrega ser maior que 30% do estimado
Semalmente Todas Gerente de Projeto Excel
(PRZ_REAL)
1. Estimativa de Custo Total
Previsto no Contrato Incio do projeto Todas Gerente de Projeto Excel No possui
(CUSTO_CONTRATO)
2. Custo Real do Projeto O custo real no pode ser maior que
Mensalmente Todas Gerente de Projeto Excel
(CUSTO_REAL) 20% do estimado
Grfico que mostra a porcentagem
1. % Requisitos Modificados Mensalmente Todas Gerente de Projeto Excel de requisitos modificados ao longo
do tempo
2. Impacto estimado das Grfico que mostra a estimativa de
mudanas de requisitos no Mensalmente Todas Gerente de Projeto Excel esforo das mudanas ao longo do
perodo tempo
Grfico que mostra a quantidade de
1. Qtd Defeito por caso de uso Mensalmente Todas Gerente de Projeto Excel
defeito por caso de uso

2. Porcentagem de defeito por Grfico que mostra a taxa de


Mensalmente Todas Gerente de Projeto Excel
caso de uso defeitos por tamanho de caso de uso
195

Mecanismo de Divulgao dos Dados do Projeto

Medidas Derivadas Mecanismo Interessado(s) Periodicidade Responsvel(eis)


1. Total de Tarefas
Planejadas
2. Total de Tarefas em Divulgao da Planilha de Anlise dos
Todos os membros do projeto Semalmente Gerente de Projeto
Execuo Dados. Seo Progresso do Cronograma

3. % Concluso das Tarefas

1. Estimativa de Tamanho Divulgao da Planilha de Anlise dos


Todos os membros do projeto No inicio do projeto Gerente de Projeto
Total (ETT) Dados. Seo Tamanho Funcional

1. Estimativa de Esforo
Total do Projeto (ESF)
Divulgao da Planilha de Anlise dos
Todos os membros do projeto Mensalmente Gerente de Projeto
2. Total de Horas Dados. Seo Esforo
Trabalhadas durante o
projeto no perodo

3. Variao entre o estimado Divulgao da Planilha de Anlise dos


Todos os membros do projeto Mensalmente Gerente de Projeto
e o realizado (ESF_VAR) Dados. Seo Esforo

4. Estimativa de Esforo por


Divulgao da Planilha de Anlise dos
Caso de Uso Todos os membros do projeto Mensalmente Gerente de Projeto
Dados. Seo Esforo
(ESF_CASO_USO)
5. Estimativa de Esforo de
Divulgao da Planilha de Anlise dos
cada caso de uso por Todos os membros do projeto Mensalmente Gerente de Projeto
Dados. Seo Esforo
disciplina (ESF_DISP)

6. Quant. de horas previstas Divulgao da Planilha de Anlise dos


Todos os membros do projeto Mensalmente Gerente de Projeto
no contrato Dados. Seo Esforo
196

Mecanismo de Divulgao dos Dados do Projeto - Continuao

Medidas Derivadas Mecanismo Interessado(s) Periodicidade Responsvel(eis)


7. Variao entre o realizado Divulgao da Planilha de Anlise dos
Alta gerncia Mensalmente Gerente de Projeto
e o estimado no contrato Dados. Seo Esforo
1. Estimativa de Prazo Total
(EPRZ) Divulgao da Planilha de Anlise dos Todos os membros do projeto
Mensalmente Gerente de Projeto
2. Prazo Real de Entrega Dados. Seo Prazo e o cliente
(PRZ_REAL)
1. Estimativa de Custo Total
Previsto no Contrato
Divulgao da Planilha de Anlise dos
(CUSTO_CONTRATO) Alta gerncia Mensalmente Gerente de Projeto
Dados. Seo Custo
2. Custo Real do Projeto
(CUSTO_REAL)
1. % Requisitos Modificados
Divulgao da Planilha de Anlise dos
2. Impacto estimado das Todos Mensalmente Gerente de Projeto
Dados. Seo Estabilidade dos Requisitos
mudanas de requisitos no
perodo
1. Qtd Defeito por caso de
uso Divulgao da Planilha dos Dados. Seo
Todos da equipe Mensalmente Gerente de Projeto
2. Porcentagem de defeito Estabilidade dos Requisitos
por caso de uso
197

APNDICE C ProMePE: Planilha de Coleta e Anlise dos Dados do Projeto (Estudo de Caso)
Progresso do Cronograma no Perodo

Data Inicial Data Final


Perodo Analisado
1/10/2009 30/12/2009

Total de Tarefas Planejadas no Perodo 31


Total de Tarefas Concludas no Perodo 12

Impacto no Cronograma (dias) 38


Nova Data de Trmino das Tarefas 6/2/2010
Total de Tarefas Atrasadas no Perodo 19
Porcentagem de Tarefas Pendentes (%) 61,29
Porcentagem de Tarefas Concludas (%) 38,71

Tarefas Planejadas x Tarefas Concludas no Perodo


30

25
Qtd de Tarefa

20
Critrio de Deciso -15%
15 Critrio de Deciso +15%

10 Qtd. Tarefas Concludas


Qtd. Tarefas Planejadas
5

0
out nov dez
198

Tamanho Funcional

Passo 1
Separar o projeto por funcionalidades e determinar a quantidadade de transaes por complexidade
TED TSD TCD TEX TPD Tamanho
Caso de Uso Complexidade Complexidade Complexidade Complexidade Complexidade
Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta
UC1 1 2,67
UC2 4 1 20,47
UC3 4 1 20,47
UC4 3 1 1 1 20,47
UC5 3 1 1 16,91
UC6 3 1 1 19,58
UC7 3 2 1 24,03
UC8 3 1 1 16,91
UC9 2 1 11,57
UC10 1 1 3 1 28,48
UC11 3 1 1 1 21,36
UC12 3 1 1 16,91
UC13 3 4 7 1 66,75
UC14 4 1 1 1 23,14
UC15 1 1 1 11,57
UC16 4 1 1 19,58
UC17 3 1 1 1 21,36
UC18 3 1 1 1 21,36
UC19 3 1 1 1 24,92
UC20 1 1 1 1 17,8
UC21 3 2 1 1 25,81
UC22 1 1 1 3 27,59
UC23 3 1 4 28,48
199

Passo 1 - Continuao
Separar o projeto por funcionalidades e determinar a quantidadade de transaes por complexidade
TED TSD TCD TEX TPD Tamanho
Caso de Uso Complexidade Complexidade Complexidade Complexidade Complexidade
Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta
UC24 3 1 8 56,96
UC25 1 1 1 8,9
UC26 1 1 2 14,24
UC27 2 1 1 11,57
UC28 2 1 2 14,24

Passo 2
Calcular o valor das Funcionalidade (FF)
Grupos de Transaes Complexidade Peso Quantidade Valor
Baixa 3 53 159
TED Mdia 4 20 80
Alta 6 4 24
Baixa 4 7 28
TSD Mdia 5 13 65
Alta 7 3 21
Baixa 3 18 54
TCD Mdia 4 8 32
Alta 6 11 66
Baixa 5 0 0
TEX Mdia 7 0 0
Alta 10 0 0
Baixa 7 23 161
TPD Mdia 10 0 0
Alta 15 0 0
FF = 690
200

Passo 3
Calcular os Fatores Tcnicos No- Funcionais (FTNF)
Caracterstica Nota
Processamento Distribudo 0
Desempenho 5
Eficincia do Usurio 3
Processamento Complexo 5
Reusabilidade 0
Facilidade de Instalao 3
Usabilidade 5
Portabilidade 0
Facilidade de Manuteno 3
Concorrncia 0

FTNF = 0,89

Estimativa de Tamanho Total (ETT)

ETT = 614,1
201

Esforo do Projeto

Esforo Estimado por Caso de Uso (horas)

Esforo Estimado Esforo Estimado Esforo Estimado


Esforo Estimado Esforo Estimado Esforo Estimado
Caso de Uso Disciplina Anlise e Disciplina Disciplina Gerencia de
por Caso de Uso Disciplina Requisitos Disciplina Testes
Projeto Implementao Projetos

UC1 53,4 10,68 10,68 18,69 8,01 1,068


UC2 409,4 81,88 81,88 143,29 61,41 8,188
UC3 409,4 81,88 81,88 143,29 61,41 8,188
UC4 409,4 81,88 81,88 143,29 61,41 8,188
UC5 338,2 67,64 67,64 118,37 50,73 6,764
UC6 391,6 78,32 78,32 137,06 58,74 7,832
UC7 480,6 96,12 96,12 168,21 72,09 9,612
UC8 338,2 67,64 67,64 118,37 50,73 6,764
UC9 231,4 46,28 46,28 80,99 34,71 4,628
UC10 569,6 113,92 113,92 199,36 85,44 11,392
UC11 427,2 85,44 85,44 149,52 64,08 8,544
UC12 338,2 67,64 67,64 118,37 50,73 6,764
UC13 1335 267 267 467,25 200,25 26,7
UC14 462,8 92,56 92,56 161,98 69,42 9,256
UC15 231,4 46,28 46,28 80,99 34,71 4,628
UC16 391,6 78,32 78,32 137,06 58,74 7,832
UC17 427,2 85,44 85,44 149,52 64,08 8,544
UC18 427,2 85,44 85,44 149,52 64,08 8,544
UC19 498,4 99,68 99,68 174,44 74,76 9,968
UC20 356 71,2 71,2 124,6 53,4 7,12
UC21 516,2 103,24 103,24 180,67 77,43 10,324
UC22 551,8 110,36 110,36 193,13 82,77 11,036
UC23 569,6 113,92 113,92 199,36 85,44 11,392
202

Esforo Estimado por Caso de Uso - Continuao

Esforo Estimado Esforo Estimado Esforo Estimado


Esforo Estimado Esforo Estimado Esforo Estimado
Caso de Uso Disciplina Anlise e Disciplina Disciplina Gerencia de
por Caso de Uso Disciplina Requisitos Disciplina Testes
Projeto Implementao Projetos

UC24 1139,2 227,84 227,84 398,72 170,88 22,784


UC25 178 35,6 35,6 62,3 26,7 3,56
UC26 284,8 56,96 56,96 99,68 42,72 5,696
UC27 231,4 46,28 46,28 80,99 34,71 4,628
UC28 284,8 56,96 56,96 99,68 42,72 5,696

Produtividade da Equipe (esforo/tamanho) 20

Esforo Total Horas


Esforo Total Previsto no Contrato 19336
Esforo Inicial Estimado 12282
Esforo Total Realizado 17080

Ano 2009
Esforo no Perodo
out nov dez
Esforo Mensal Planejado 320 320 320
Esforo Mensal Planejado Acumulado 320 640 960
Esforo Mensal Executado do Projeto 220 233 280
Esforo Mensal Executado Acumulado 220 453 733
Esforo Mensal Previsto no Contrato 160 160 160
Critrio de Deciso +20% 384 384 384
Critrio de Deciso -20% 256 256 256
203

Esforo do Projeto Continuao

Esforo em Horas: Planejado x Executado


450
400
Esforo Mensal Planejado
350

Esforo em Horas
300
250 Esforo Mensal
Executado do Projeto
200
150 Critrio de Deciso +20%
100
50 Critrio de Deciso -20%
0
out nov dez
204

Esforo do Projeto Previsto no Contrato

Papel Qtd. nov/06 dez/06 jan/07 fev/07 mar/07Total


Coordenador 1 5 5 5 5 5 25
Gerente de Projeto 1 160 160 160 160 160 800
Desenvolvedor 2 160 160 160 160 160 1600
Bolsista 2 120 120 120 120 120 1200
Esforo Total Previsto no Contrato 1 no Perodo (horas) 3600

Papel Qtd. nov/07 dez/07 jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08 Total
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 8 96
Gerente de Projeto 1 160 160 160 160 160 160 160 160 160 160 160 160 1920
Desenvolvedor 3 160 160 160 160 160 160 160 160 160 160 160 160 5760
Esforo Total Previsto no Contrato 2 no Perodo (horas) 7776

Papel Qtd. nov/08 dez/08 jan/09 fev/09 Total


Coordenador 1 8 8 8 8 32
Gerente de Projeto 1 160 160 160 160 640
Desenvolvedor 3 160 160 160 160 1920
Esforo Total Previsto no Contrato 2 no Perodo (horas) 2592

Papel Qtd. mar/09 abr/09 mai/09 jun/09 jul/09 ago/09 set/09 out/09 nov/09 dez/09 jan/10 Total
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 88
Gerente de Projeto 1 160 160 160 160 160 160 160 160 160 160 160 1760
Desenvolvedor 2 160 160 160 160 160 160 160 160 160 160 160 3520
Esforo Total Previsto no Contrato 3 no Perodo (horas) 5368

Esforo Total Previsto nos Contratos (horas) 19336


205

Esforo Realizado no Projeto

Papel Qtd. nov/06 dez/06 jan/07 fev/07 mar/07 abr/07 mai/07 jun/07 jul/07 ago/07 set/07 out/07
Coordenador 1 8 8 8 8 8 4 4 4 4 4 4 4
Gerente de Projeto 0 0 0 0 0 0 0 0 0 0 0 0 0
Desenvolvedor 2 160 160 160 160 160 80 80 80 80 80 80 80
Analista 1 160 160 160 160 160 80 80 80 80 80 80 80
Esforo Total Realizado no Perodo do Contrato 1 (horas)

Papel Qtd. nov/07 dez/07 jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 8
Gerente de Projeto 0 0 0 0 0 0 0 0 0 0 0 0 0
Desenvolvedor 2 120 120 120 120 120 120 120 120 120 120 120 120
Analista 2 160 160 160 160 160 160 160 160 160 160 160 160
Esforo Total Realizado no Perodo do Contrato 2 (horas)

Papel Qtd. nov/08 dez/08 jan/09 fev/09 Total


Coordenador 1 8 8 8 8 32
Gerente de Projeto 0 0 0 0 0 0
Desenvolvedor 2 120 120 120 120 960
Analista 2 160 160 160 160 1280
Esforo Total Realizado no Perodo do Contrato 2 (horas) 2272

Papel Qtd. mar/09 abr/09 mai/09 jun/09 jul/09 ago/09 set/09 Total
Coordenador 1 4 4 4 4 4 4 4 28
Gerente de Projeto 1 40 40 40 40 40 40 40 280
Analista/Desenvolvedor 2 160 160 160 160 160 160 160 2240
Desenvolvedor 2 80 80 80 80 80 80 80 1120
Esforo Total Realizado no Perodo do Contrato 3 (horas) 3668
206

Esforo Realizado no Projeto - Continuao

Papel Qtd. out/09 nov/09 dez/09 jan/10Total


Coordenador 1 4 4 4 4 16
Gerente de Projeto 1 80 80 80 80 320
Analista/Desenvolvedor 1 160 160 160 160 640
Desenvolvedor 2 80 80 80 80 640
Esforo Total Realizado no Perodo do Contrato 3 (horas) 1616

Esforo Total Realizado (horas) 17080

Esforo Previsto no Contrato x Realizado Varincia de Esforo: Previsto no Contrato x


Realizado
12000
20%
10000 15%
10%
Esforo (horas)

8000
5%
6000 Previsto no Contrato 0%
Realizado -5% Contrato 1 Contrato 2 Contrato 3 Varincia
4000
-10%
2000 -15%
-20%
0
-25%
Contrato 1 Contrato 2 Contrato 3
-30%
207

Custo do Projeto

Percentual de Esforo Previsto Percentual de Esforo Valor da Hora de Valor da Hora de


Papel
no Contrato Realizado Trabalho (Estimado) Trabalho (Real)
Coordenador do Projeto 1,246% 1% R$82,00 R$100,00
Analista de Sistemas 0% 46% R$11,38 R$13,88
Gerente de Projeto 26,479% 4% R$18,96 R$23,13
Projetista 0% 0% R$0,00 R$0,00
Arquiteto 0% 0% R$0,00 R$0,00
Desenvolvedor 72,404% 49% R$11,38 R$13,88
Testador 0% 0% 0,00 0R$,00

Contrato Valor Pago Total Recursos Humanos (RH)


Contrato 1 R$ 58.406,25 R$ 38.465,62
Contrato 2 R$ 143.319,00 R$ 96.737,15
Contrato 3 R$ 100.933,33 R$ 56.340,00
TOTAL R$ 302.658,58 R$ 191.542,77

Custos Valores
Estimativa de Custo (RH) R$ 276.135,00
Custo Pago pela Contratante (RH) R$ 191.542,77
Custo Real do Projeto (RH) R$ 263.205,00
Prejuzo (RH) R$ 71.662,23
208

Custo do Projeto - Continuao

Custos do Projeto Custo do Projeto por Contrato


R$ R$ 140.000,00
263.205,00
R$ 120.000,00
R$
191.542,77 R$ 100.000,00
R$ 80.000,00
R$ 60.000,00
R$ 40.000,00
R$ 20.000,00
R$ -
Contrato 1 Contrato 2 Contrato 3
Custo Pago pela Custo Real do Projeto Prejuzo (RH)
Contratante (RH) (RH) Previsto Realizado
R$ 71.662,23 Critrio de Deciso +20% Critrio de Deciso -20%
209

Estabilidade dos Requisitos

Esforo Estimado
Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo
Caso % para Mudana -
para Mudana - para Mudana - para Mudana - para Mudana - Total para Estimado
de Uso Mudana Gerencia de
Requisitos Anlise e Projeto Implementao Testes Mudana Acumulado
Projeto

UC1 0% 0 0 0 0 0 0 0
UC2 50% 40,94 40,94 71,645 30,705 20,47 205 205
UC3 50% 40,94 40,94 71,645 30,705 20,47 205 409
UC4 80% 65,504 65,504 114,632 49,128 32,752 328 737
UC5 0% 0 0 0 0 0 0 737
UC6 30% 23,496 23,496 41,118 17,622 11,748 117 854
UC7 100% 96,12 96,12 168,21 72,09 48,06 481 1335
UC8 0% 0 0 0 0 0 0 1335
UC9 10% 4,628 4,628 8,099 3,471 2,314 23 1358
UC10 80% 91,136 91,136 159,488 68,352 45,568 456 1814
UC11 80% 68,352 68,352 119,616 51,264 34,176 342 2156
UC12 20% 13,528 13,528 23,674 10,146 6,764 68 2223
UC13 80% 213,6 213,6 373,8 160,2 106,8 1068 3291
UC14 50% 46,28 46,28 80,99 34,71 23,14 231 3523
UC15 0% 0 0 0 0 0 0 3523
UC16 0% 0 0 0 0 0 0 3523
UC17 50% 42,72 42,72 74,76 32,04 21,36 214 3736
UC18 0% 0 0 0 0 0 0 3736
UC19 0% 0 0 0 0 0 0 3736
UC20 20% 14,24 14,24 24,92 10,68 7,12 71 3807
UC21 0% 0 0 0 0 0 0 3807
UC22 0% 0 0 0 0 0 0 3807
UC23 0% 0 0 0 0 0 0 3807
210

Estabilidade dos Requisitos Continuao

Esforo Estimado
Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo
Caso % para Mudana -
para Mudana - para Mudana - para Mudana - para Mudana - Total para Estimado
de Uso Mudana Gerencia de
Requisitos Anlise e Projeto Implementao Testes Mudana Acumulado
Projeto

UC24 100% 227,84 227,84 398,72 170,88 113,92 1139 4947


UC25 0% 0 0 0 0 0 0 4947
UC26 0% 0 0 0 0 0 0 4947
UC27 20% 9,256 9,256 16,198 6,942 4,628 46 4993
UC28 20% 11,392 11,392 19,936 8,544 5,696 57 5050
211

Defeitos do Projeto

Casos de Qtd. de Porcentagem de Defeito por


Casos de Uso
Testes Defeitos Tamanho de UC
UC1 CT1 26 0%
UC2 CT2 8 4%
UC4 CT4 3 1%
UC5 CT5 1 0%
UC6 CT6 13 11%
UC7 CT7 2 0%
UC8 CT8 2 0%
UC9 CT9 5 22%
UC10 CT10 5 1%
UC11 CT11 1 0%
UC13 CT13 1 0%
UC17 CT17 5 2%
UC18 CT18 3 0%
UC19 CT19 1 0%
UC20 CT20 1 1%
212

APNDICE D ProMePE: Relatrio de Avaliao do Processo (Estudo de Caso)

Avaliao Anlise Justificativa


A lista de necessidade de informao foi atendida? Sim
Todas as medidas foram efetuadas? Sim
Algumas anlises no foram concretas. Algumas medidas foram
Foi possvel analisar as medidas? Parcialmente
coletadas retroativamente
O processo foi eficiente, ou seja, produziu o efeito desejado? Sim
Por ter sido o primeiro projeto a utilizar o processo de medio, houve
O processo foi custoso para a equipe? Parcialmente
uma curva de aprendizado.
O indicador do progresso do cronograma no foi satisfeito para o
Os indicadores foram satisfeitos? Parcialmente
projeto

Lies Aprendidas e Aes de Melhoria

- Critrio de Deciso do Progresso do Cronograma de apenas 15% foi baixo para esse tipo de
projeto;
- Utilizar o processo desde o incio de um projeto ajuda a consolidar as medidas e facilita na
posterior anlise dos dados, sem ambiguidade;
- Como a alta gerncia queria realizar medies relativas aos contratos, o processo ficou
oneroso devido busca constante de informaes retroativas;

Das könnte Ihnen auch gefallen