Trabalho Sobre Cmmi

UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PS-GRADUAO EM CINCIA DA

COMPUTAO
Andr Marques Pereira
MONITORAMENTO E CONTROLE DE PROJETOS DE

DESENVOLVIMENTO DE SOFTWARE PARA MICRO E
PEQUENAS EMPRESAS ALINHADO AO PMBOK E CMMI
Florianpolis - SC
2012

Dissertao submetida Universidade

Federal de Santa Catarina como parte
dos requisitos para a obteno do grau
de Mestre em Cincia da Computao
Orientadora: Prof. Dra. rer. nat.
Christiane Gresse von Wangenheim,
PMP
Florianpolis - SC
2012
Ficha de identificao da obra elaborada pelo autor,

atravs do Programa de Gerao Automtica da Biblioteca
Universitria da UFSC.
Pereira, Andr Marques

Monitoramento e Controle de Projetos de Desenvolvimento
de Software para Micro e Pequenas Empresas Alinhado ao
PMBOK E CMMI [dissertao] / Andr Marques Pereira ;
orientadora, Christiane Gresse von Wangenheim, Dra Florianpolis, SC, 2012.
205 p. ; 21cm
Dissertao (mestrado) - Universidade Federal de Santa
Catarina, Centro Tecnolgico. Programa de Ps-Graduao em
Cincia da Computao.
Inclui referncias
1. Cincia da Computao. 2. Modelo Genrico de
Processo. 3. CMMI e PMBOK. 4. Monitoramento e Controle de
Projetos. 5. Gerenciamento de Projetos. I. Wangenheim,
Christiane Gresse von . II. Universidade Federal de Santa
Catarina. Programa de Ps-Graduao em Cincia da Computao.
III. Ttulo.

Esta Dissertao foi julgada adequada para obteno do Ttulo de

Mestre em Cincias da Computao, e aprovada em sua forma final
pelo Programa de Ps-Graduao em Cincias da Computao.
Florianpolis, 28 de Novembro de 2012.
________________________
Prof. Ronaldo dos Santos Mello, Dr.
Coordenador do Curso
Banca Examinadora:
________________________
Prof. Christiane Gresse von Wangenheim, Dra
Orientadora
Universidade Federal de Santa Catarina
________________________
Prof. Jean Carlo Rosa Hauck, Dr.
________________________
Prof. Ricardo J. Rabelo, Dr.
________________________
Prof. Santiago Matalonga, Dr.
Universidad ORT Uruguay
A Deus, por ter ajudado a trilhar esse caminho.

Aos meus pais Csar e Iza, que me acompanham e me inspiram a ser
cada vez melhor e no desistir.
minha esposa, pelo companheirismo, amor e carinho.
Chris, orientadora e exemplo de comprometimento.
Ao Rafael, pelo esforo empregado no mesmo laboratrio em
busca tambm do seu ttulo de mestre.
"You cant connect the dots

looking
forward;
you
can
only
connect them looking backwards"
Steve Jobs
RESUMO
Muitas empresas falham no desenvolvimento de seus projetos e muito

se deve a falta de maturidade de seus processos. Analisando o cenrio
das Micro e Pequenas Empresas (MPE), muitas vezes inexiste
alinhamento modelos e normas atualmente em evidncia, talvez
explicado pelo fato de que os modelos podem ser muito abrangentes
para o contexto delas.
Acredita-se que o uso de ferramentas de gerncia de projetos possa
auxiliar
as
empresas
amadurecerem
seus
processos
consequentemente aumentar o nvel de qualidade almejado. Entretanto

tem se percebido que muitas ferramentas, que se intitulam de gerncia
de projetos, no atendem requisitos definidos em nenhuma das prticas
atualmente em evidncia.
Este trabalho aborda uma proposta de um modelo genrico de processo
para monitoramento e controle de projetos de MPE alinhado ao
Capability Maturity Model Integration (CMMI) e Project Management
Body of Knowledge (PMBOK), alm de um estudo comparativo de
ferramentas de cdigo livre para gerenciamento de projetos sendo uma
delas eleita para aprimorar suas funcionalidades aumentando o grau de
atendimento aos modelos supra citados. Todo o trabalho foi avaliado
por especialistas da rea que tiveram contato com a ferramenta para
fornecer suas opinies.
Palavras-chave: Gerenciamento de Projetos; PMBOK; CMMI;

Software Livre; Micro e Pequenas Empresas; Monitoramento e
Controle; dotProject.
ABSTRACT
Many companies fail to develop their projects and this is due to lack of
maturity of their processes. Analyzing the context of Small and Medium
Enterprises (SMEs), it was noted the nonexistent alignment to project
management models and standards currently in evidence. This perhaps
could demonstrate that the reference models arent very comprehensive
for SMEs. It is believed that the use of project management tools can
assist companies to mature their processes and consequently to increase
the level of quality of their products. However, it has been noticed that
many tools categorized as project management do not meet
requirements defined in any of best practice models. In this paper we
present a process of monitoring and controlling in SMEs aligned with
the Capability Maturity Model Integration (CMMI) and Project
Management Body of Knowledge (PMBOK), as well as presenting the
evolution the open-source tool dotProject, which was enhanced to
support this model. The work was evaluated by project management
experts who have analyzed the model, and have used the tool to give
their opinions by answering a questionnaire. Thus, it was subsequently
analyzed to identify how much the model and the tool are adequate to
be applied in SMEs projects, along with the completeness and
consistency of the proposed model.
Keywords: Project Management; PMBOK; CMMI; Open-Source

Software (OSS); Small and Medium Enterprises (SMEs); dotProject.
LISTA DE FIGURAS
FIGURA 1 - ESTIMATIVA DE VIDA DE EMPRESAS DE SOFTWARE EM 2005 ................... 21
FIGURA 2 - REAS DE CONHECIMENTO DE GERENCIAMENTO DE PROJETOS .................. 37
FIGURA 3 GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS ..................... 39
FIGURA 4 - CICLO MONITORAMENTO E CONTROLE PROPOSTO POR JALOTE.................. 44
FIGURA 5 - GRUPO DE PROCESSO DE MONITORAMENTO E CONTROLE ........................ 45
FIGURA 6 - DIAGRAMA DE FLUXO DE DADOS DO PROCESSO DE MONITORAR E CONTROLAR
O TRABALHO DO PROJETO ........................................................................ 48
FIGURA 7 - FLUXO DE ATIVIDADES DE MONITORAMENTO E CONTROLE ....................... 49

FIGURA 8 - ATIVIDADE DE CONTROLE INTEGRADO DE MUDANAS ............................. 53
FIGURA 9 - ESCOPO NA VISO DO PROJETO E DO CLIENTE ........................................ 56
FIGURA 10 - EAP PROJETO TROCAR-PNEU .......................................................... 57
FIGURA 11 - FLUXO DE DADOS DO PROCESSO CONTROLAR ESCOPO. ......................... 59
FIGURA 12 GRFICO DE GANTT DO PROJETO TROCAR-PNEU ................................. 64
FIGURA 13 - VALOR AGREGADO, VALOR PLANEJADO E CUSTO REAL ........................... 68
FIGURA 14 - CURVA S DO PROJETO PIZZARIA DO CHICO.......................................... 70
FIGURA 15 - PARADIGMA GQM (BASILI, 1994). ................................................ 72
FIGURA 16 - DIAGRAMA DE PARETO EXEMPLO ..................................................... 74
FIGURA 17 DIAGRAMA DE CAUSA E EFEITO EXEMPLO.......................................... 74
FIGURA 18 HISTOGRAMA EXEMPLO ................................................................. 75
FIGURA 19 - DIAGRAMA DE DISPERSO EXEMPLO ................................................. 75
FIGURA 20 - FLUXOGRAMA EXEMPLO ................................................................. 76
FIGURA 21 - GRFICO DE CONTROLE EXEMPLO..................................................... 77
FIGURA 22 - GRFICO DE EXECUO EXEMPLO..................................................... 77
FIGURA 23 GRFICO DE CONTROLE DO PROJETO TROCAR-PNEU ............................ 78
FIGURA 24 EXEMPLO 1 DE DASHBOARD ........................................................... 80

FIGURA 27 - PMBOK E METODOLOGIA DE DESENVOLVIMENTO .............................. 85
FIGURA 28 - REPRESENTAO POR ESTGIOS DO CMMI ........................................ 90
FIGURA 29 - REPRESENTAO CONTNUA DO CMMI ............................................. 92
FIGURA 30 - DOTPROJECT .............................................................................. 108
FIGURA 31 - PROJECT.NET .............................................................................. 109
FIGURA 32 - PHPCOLLAB ................................................................................ 110
FIGURA 33 - TRACK ....................................................................................... 112
FIGURA 34 - STREBBER ......................................................................... 113
FIGURA 35 - PROCESSO DE REFERNCIA PARA MONITORAMENTO E CONTROLE EM ALTO
NVEL (HAUCK, 2007) ........................................................................ 117
FIGURA 36 - NVEIS DE MODELAGEM NA ARQUITETURA DE QUATRO CAMADAS DA UML

........................................................................................................ 126
FIGURA 37 - MODELO DE MONITORAMENTO PROPOSTO ..................................... 128
FIGURA 38- CASOS DE USO PARA DOTPROJECT ................................................... 141
FIGURA 39 - MEDIDA 1 - CUSTO...................................................................... 163
FIGURA 40 - MEDIDA 2 - CUSTO RH ................................................................ 164
FIGURA 41 - MEDIDA 3 - CUSTO DE INVESTIMENTO ............................................. 165
FIGURA 42 - MEDIDA 4 - ESFORO DO PROJETO ................................................. 166
FIGURA 43 - MEDIDA 5 - ESFORO GERENCIAL ................................................... 167
FIGURA 44 - MEDIDA 6 - DURAO DO PROJETO ................................................ 168
FIGURA 45 - MEDIDA 7 - FATOR DE PRODUTIVIDADE ........................................... 169
FIGURA 46 - MEDIDA 8 - FATOR DE REUTILIZAO .............................................. 170
FIGURA 47 - MEDIDA 9 - INDICADOR DE QUALIDADE DAS ENTREGAS ....................... 171
FIGURA 48 - MEDIDA 10 - INDICADOR DE ADERNCIA DO MODELO......................... 172
FIGURA 49 - MEDIDA 11 - INDICADOR DE REJEIO............................................. 173

FIGURA 50 - MEDIDA 12 - ALTERAO DE REQUISITOS ........................................ 174
FIGURA 51 - MEDIDA 13 - NDICE DE SATISFAO DO CLIENTE ............................... 175
FIGURA 52 - MEDIDA 14 - NDICE DE APROVAO .............................................. 176
FIGURA 53 - MEDIDA 15 - SATISFAO COM A EQUIPE ........................................ 177
FIGURA 54 - MEDIDA 16 - SATISFAO TEMPO DE RESPOSTA ................................ 178
FIGURA 55 - TELA DO VISUALIZAO DE LINHAS DE BASE UC01 ............................. 179
FIGURA 56 - TELA DE CADASTRO DE LINHA DE BASE UC01 .................................... 180
FIGURA 57 - TELA DO VISUALIZAO DA LISTA DE AO CORRETIVA UC02 .............. 181
FIGURA 58 - TELA DE CADASTRO AO CORRETIVA UC02 .................................... 182
FIGURA 59 - TELA DE LISTA DE ATA DE REUNIO UC03 ........................................ 184
FIGURA 60 - TELA DO ATA DE REUNIO - PADRO UC03 ..................................... 185
FIGURA 61 - TELA DO ATA DE REUNIO - MONITORAMENTO UC04 ....................... 185
FIGURA 62 - TELA DO ATA DE REUNIO - ENTREGA UC05 .................................... 186
FIGURA 63 - TELA DO ATA DE REUNIO - STATUS REPORT UC06 ........................... 186
FIGURA 64 - TELA DO VISUALIZAO DE TEMPO UC07 ........................................ 188
FIGURA 65 - TELA DO VISUALIZAO DE CUSTOS UC08 ....................................... 190
FIGURA 66 - TELA DE REGISTRO DE QUALIDADE UC09 ......................................... 192
FIGURA 67 - TELA DO VISUALIZAO DE QUALIDADE UC10 .................................. 193
FIGURA 68 - TELA DO RELATRIO A GERNCIA SNIOR UC11 ................................. 194
FIGURA 69 - TELA DE MATRIZ DE RESPONSABILIDADES UC12 ............................... 196
FIGURA 70 - TELA DE CUSTO DE RECURSO UC13 ................................................. 198
LISTA DE TABELAS
TABELA 1 -CLASSIFICAO DAS EMPRESAS BRASILEIRAS .......................................... 21
TABELA 2 - MAPEAMENTO DE GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS E
REAS DE CONHECIMENTO. ...................................................................... 40
TABELA 3 - CUSTOS FIXO DO PROJETO PIZZARIA DO CHICO ...................................... 46

TABELA 4 - ATIVIDADES DO PROJETO PIZZARIA DO CHICO ........................................ 46
TABELA 5 - RESTRIES DO PROJETO TROCA-PNEU ................................................ 46
TABELA 6 - ANLISE DO DESEMPENHO DO CRONOGRAMA ....................................... 64
TABELA 7 - CUSTO REAL DO PROJETO PIZZARIA DO CHICO ....................................... 69
TABELA 8 ANLISE DE CUSTO PROJETO PIZZARIA ................................................. 70
TABELA 9 - RELAO ENTRE AS REPRESENTAES DO CMMI................................... 93
TABELA 10 - PRATICAS UNIFICADAS .................................................................... 96
TABELA 11 - FERRAMENTAS SELECIONADAS ....................................................... 103
TABELA 12 - TABELA DE PROCESSOS PMC ......................................................... 104
TABELA 13 - TABELA DE AVALIAO ................................................................. 106
TABELA 14 - RESULTADO DA AVALIAO DAS FERRAMENTAS................................. 114
TABELA 15 - EXEMPLO DE DADOS A SEREM COLETADOS ........................................ 119
TABELA 16 PRINCIPAIS ESTERETIPOS SPEM .................................................. 126
TABELA 17 - UBP - MAPEAMENTO MODELO VS ASPE ........................................ 128
TABELA 18 - REQUISITOS FUNCIONAIS .............................................................. 137
TABELA 19 - REQUISITOS NO FUNCIONAIS ....................................................... 140
TABELA 20 - RELAO CASO DE USO VS REQUISITOS ........................................... 141
TABELA 21 - QUESTES PARA AVALIAO COM O MTODO GQM .......................... 145
TABELA 22 - RESPOSTAS OBTIDAS NA AVALIAO PELOS ESPECIALISTAS.................... 147
TABELA 23 COMPARATIVO DE VERSO DO DOTPROJECT ....................................... 150
TABELA 24 - CASO DE USO MATRIZ DE RESPONSABILIDADES .................................. 195
LISTA DE ABREVIATURAS E SIGLAS
CEPSH - Comit de tica em Pesquisa com Seres Humanos

CMMI Capability Maturity Model Integration
CMMI-DEV - Capability Matutiry model integration for
development
GPL - General Public License
GQM - Goal/Question/Metric
GQS - Grupo de Qualidade de Software
INCoD - Instituto Nacional de Convergncia Digital
MCT - Ministrio da Cincia e Tecnologia
MPE Micro e Pequena Empresa
PMBOK Project Management Body of Knowleadge
PMC - Project Monitoring and Controlling
RF - Requisitos funcionais
RNF - Requisitos no funcionais
SPEM - Software & Systems Process Engineering Metamodel
Specification
TI - Tecnologia da Informao
UBP - Unified Best Practice
UC - Use case
UFSC - Universidade Federal de Santa Catarina
UML - Unified Modeling Language
SUMRIO
1.
2.
Introduo.........................................................................20
1.1
Contextualizao ......................................................20
1.2
Problema ..................................................................26
1.3
Pergunta de pesquisa ................................................27
1.4
Objetivos ..................................................................27
1.4.1 -
Objetivos Gerais ...............................................27
1.4.2 -
Objetivos Especficos .......................................27
1.4.3 -
Escopo e delimitao do trabalho .....................28
1.5
Metodologia .............................................................28
1.6
Justificativa ..............................................................34
Conceitos Fundamentais ...................................................36

2.1
Gerncia de Projetos ................................................36
2.1.1 -
Processo de Monitoramento e Controle (PMC-
Project monitoring & control) ......................................................42

2.2
3.
Modelos de Melhoria de Processos ..........................84
2.2.1 -
PMBOK............................................................84
2.2.2 -
CMMI-DEV .....................................................86
2.3
Micro e Pequenas Empresas.....................................95
2.4
Mapeamento PMBOK-CMMI .................................96
2.5
Trabalhos Correlatos ................................................99
Seleo das ferramentas ................................................. 101

3.1
Ferramentas Selecionadas ...................................... 106
3.1.1 -
DotProject ...................................................... 106
3.1.2 -
Project.net....................................................... 108
3.1.3 -
PhpCollab ....................................................... 109
3.1.4 -
Track+ ............................................................ 111
3.1.5 3.2
4.
Strebber .......................................................... 112
Resultado da avaliao ........................................... 114
Modelo Genrico de Processo para PMC ....................... 116

4.1
processo de referncia ............................................ 116
4.1.1 -
Passo 1 - Coleta de dados ............................... 118
4.1.2 -
Passo 2 - Analisar e Visualizar ....................... 120
4.1.3 -
Passo 3 - Interpretar e Comunicar .................. 120
4.1.4 -
Passo 4 - Verificar Questes .......................... 124
4.1.5 -
Passo 5 - Gerenciar aes corretivas .............. 124
4.1.6 -
Passo 6 - Replanejar ....................................... 124
4.2
Definio do Meta Modelo .................................... 125
4.3
Definio do Modelo Genrico de Processo .......... 127
4.3.1 -
MC01 - Planejar a Monitorao ..................... 129
4.3.2 -
MC02 - Coletar Dados ................................... 130
4.3.3 -
MC03 - Analisar os Dados ............................. 131
4.3.4 -
MC04 - Realizar Reunio de Monitorao
Equipe
133
4.3.5 -
MC05 - Realizar Reunio de Monitorao com
Gerncia Snior 134

4.3.6 5.
Aprimoramento da Ferramenta....................................... 137

5.1
6.
MC06 - Revisar Plano de Projeto ................... 136
Casos de uso ........................................................... 140
Avaliao da soluo ...................................................... 144

6.1
Definio da avaliao ........................................... 144
6.2
Resultado da avaliao ........................................... 146
6.3
Discusso ............................................................... 150
6.4
Ameaas validade ................................................ 151
7.
Concluso ....................................................................... 153
8.
Referncias Bibliograficas.............................................. 156
9.
Apndice......................................................................... 163
9.1
Exemplos de Medidas ............................................ 163
9.2
Detalhamento dos Casos de uso ............................. 178
9.2.1 -
UC01 - Registrar Linha de Base Projeto ........ 178
9.2.2 -
UC02 - Registrar aes corretivas .................. 180
9.2.3 -
UC03 - Registrar Ata de Reunio (UC03, UC04,
UC05, UC06)
182
9.2.4 -
UC07 - Visualizar Monitoramento de tempo . 186
9.2.5 -
UC08 - Visualizar Monitoramento de Custo .. 188
9.2.6 -
UC09
Qualidade
Registrar
no
Conformidade
de
190
9.2.7 -
UC10 - Visualizar Monitoramento Qualidade192
9.2.8 -
UC11 - Relatrio de Projeto Gerencia Snior 194
9.2.9 -
UC12 - Registrar Matriz de Responsabilidades

195
9.2.10 -
UC13 - Registrar Custo de Recursos do Projeto

196
9.3
Termo de consentimento do questionrio .............. 198
9.4
Avaliao realizada pelos Especialistas ................. 200
9.4.1 -
Objetivo 1 ....................................................... 200
9.4.2 -
Objetivo 2 ....................................................... 201
9.4.3 -
Objetivo 3 ....................................................... 204
20
1. INTRODUO
Este captulo apresenta a problemtica da falta de um modelo
para monitoramento e controle de projetos alinhado ao CMMI-DEV
v1.3 e PMBOK (4. ed.) para MPE (Micro e Pequenas Empresas)
relevando aspectos empresariais, financeiros e tecnolgicos. So
apresentados neste captulo: contextualizao, problema, objetivos,
procedimentos metodologia e justificativa deste trabalho.
1.1 CONTEXTUALIZAO
A indstria brasileira de software e servios de TI (Tecnologia
da Informao) vem crescendo a uma taxa mdia de 4,3% ao ano. Em
2009 existiam 64.345 empresas sendo que a perspectiva para 2012
que esse nmero alcance o patamar de 73 mil empresas (PSBB 2010).
No setor de software as MPE possuem uma alta representatividade.
Segundo uma pesquisa realizada pela ABES (Associao Brasileira de
Empresas de Software) 93,4% das empresas do setor so MPEs, destas
43,8% so microempresas e 49,6% so classificadas como de pequeno
porte. As mdias e grandes empresas so representadas por 5,3% e 1,3%
do total das empresas.
As empresas no Brasil so classificada segundo sua receita
bruta anual ou pelo nmero de funcionrios (Tabela 1).
21
Tabela 1 -Classificao das empresas brasileiras
Faturamento
(BNDS, 2012)
Nmero de Funcionrios
(SEBRAE, 2011)
Classificao
Industria
Comercio
Microempresa
<= R$ 2,4 milhes <=19 pessoas
<= 9 pessoas
> R$ 2,4
> 19 pessoas
> 9 pessoas
Pequena Empresa <= R$ 16 milhes <= 99 pessoas <= 49 pessoas
Alm de mais MPE estarem surgindo, elas vm aumentando
gradativamente suas estimativas de vida no mercado brasileiro.
Realizando um comparativo entre 2002 e 2005, o percentual de MPE
que sobrevivem pelo menos dois anos passou de 51% para 78%, ou
seja, 27% a mais de empresas no fecharam suas portas (SEBRAE
2010). Analisando novamente o setor de software, temos ainda um
cenrio um pouco mais favorvel se comparado a mdia brasileira
conforme Figura 1.
50,00% 41,00%
40,00%
24,700%
26,00%
25,300%
30,00%
18,500%
20,00%
17,800%
20,00%
11,500%9,500%
5,700%
10,00%
,00%
0a5
6 a 9 10 a 19 20 a 29 30 anos
anos
anos
anos
anos
ou +
Empresas de
Software
Brasil
Figura 1 - Estimativa de vida de Empresas de Software em 2005

Fonte: PSBB(2010)
Esse aumento no nmero de MPE e maior tempo de vida se

devem a ambientes economicamente mais favorveis, mas tambm a
22
melhora na qualidade empresarial (SEBRAE 2010), que pode ser
explicado talvez pelo crescente percentual de empresrios preocupados
com o planejamento de projetos na empresa (SEBRAE 2010).
Mesmo existindo mais pessoas buscando conhecimento e
capacitao, as empresas ainda enfrentam vrios problemas que s
levam mortalidade. Segundo o SEBRAE (2010), os principais
problemas so: ponto/local inadequado, falta de conhecimentos
gerenciais e desconhecimento do mercado, seguida de causas
econmicas. Dentre esses itens citados, pode-se associar parte do
problema de falta de conhecimentos gerenciais ao baixo nmero de
empresas que possuem uma avaliao oficial reconhecida, como por
exemplo, CMMI (Capability Maturity Model Integration). Em 2005 o
MCT (Ministrio da Cincia e Tecnologia) mostrava que somente 49
empresas estavam certificadas em algum dos 5 nveis de maturidade
CMMI (MCT 2006). Esse nmero passou para 151 empresas em
setembro de 2012 mas ainda considerado baixo se comparado a paises
como China, Estados Unidos, ndia (SEI 2012). importante salientar
ainda que o nvel de maturidade das empresas diminui junto com o
tamanho do seu porte (SEI 2010).
Ainda que existam modelos de referncia para gerenciamento
de projetos disponveis, eles em geral tem o foco em grandes
organizaes (MCT 2006). No cenrio das MPE, em geral, as empresas
seguem processos informais focados na sobrevivncia da empresa e na
entrega do produto (RICHARDSON 2007). A adaptao desses
modelos para a realidade de MPE pode ser um trabalho complicado pois
normalmente afeta diretamente o custo e o tempo empregado em cada
projeto.
23
Algumas empresas adotam abordagens geis de processo de
software (BECK 1999) (QURESHI 2012) para realizar o gerenciamento
de seus projetos, fugindo dos modelos mais tradicionais. Essas tcnicas
propem mais dinamismo e flexibilidade para o desenvolvimento de
software, porm no descrevem suas prticas de forma que possam ser
diretamente aplicadas e evidenciadas. O sucesso desse mtodo muitas
vezes esta vinculado s pessoas que o executam e no ao modelo
adotado.
Alm do CMMI, podemos ainda citar o PMBOK (Project
Management Body of Knowledge) como outra fonte de conhecimento
sobre gerenciamento de projeto voltada para a melhoria dessas
atividades. Segundo o PMI (2008), Gerenciamento de Projeto a
aplicao de conhecimentos, habilidades, ferramentas e tcnicas s
atividades do projeto a fim de atender aos seus requisitos. O
gerenciamento de projetos realizado atravs de aplicao e integrao
de processos agrupados em 5 grupos (PMI 2008):
Grupo de processo de inicializao: So os processos realizados
para definir um novo projeto ou fase em um projeto j existente atravs

da obteno de autorizao para iniciar o projeto ou fase.
Grupo de processos de planejamento: So os processos
realizados para definir o escopo do projeto, refinar os objetivos e

desenvolver o curso da ao necessrio para alcanas os objetivos para
os quais o projeto foi criado.
Grupo de processos de execuo: So os processos realizados
para executar o trabalho definido no plano de gerenciamento do projeto

para satisfazer as especificaes do mesmo.
24
Grupo de processos de monitoramento e controle: So os
processos necessrios para acompanhar, revisar e regular o progresso e

o desempenho do projeto, identificar todas as reas nas quais sero
necessrias mudanas no plano e iniciar as mudanas correspondentes.
Grupo de processos de encerramento: So os processos
executados para finalizar todas as atividades de todos os grupos de

processos, visando encerrar formalmente o projeto ou fase.
Seguindo o foco deste trabalho, monitoramento e controle tm

como objetivo fornecer uma compreenso do andamento do projeto para
que aes corretivas apropriadas possam ser tomadas quando o
desempenho do projeto desviar significativamente do planejamento
inicial (SEI 2010). A compreenso do andamento feita comparando
dados coletados durante o andamento do projeto com um plano base
anteriormente definido. Os resultados obtidos com a anlise dos dados
coletados so divulgados com informaes para uma avaliao e
possvel tomada de deciso (PMI 2008).
Portanto,
"monitorar" significa
capturar,
analisar,
criar
relatrios e comunicar o desempenho em relao ao andamento do

projeto. O termo "controlar" significa gerenciar as aes corretivas para
fazer com que o projeto volte para o seu planejamento inicial.
Monitoramento e controle andam juntos em um projeto, pois no existe
controle sem o monitoramento.
Uma pesquisa recente realizada pelo PMI revelou a frequncia
com que as empresas brasileiras, que responderam o questionrio,
adotam atividades de controle em seus projeto (Figura 1).
25
Figura 1 - Frequncia de Atividades de Controle em Projetos de

Empresa Brasileiras (PMI 2012).
Esses dados no se diferem muito do cenrio mundial e ajudam

a explicar porque 65,7% dos problemas mais frequentes enfrentados
pelas empresas so relacionados a prazo, 61,7% ao escopo e 41,3% ao
oramento. interessante citar que nesse estudo 18,4% dos problemas
so relacionados a falta de uma ferramenta de apoio e que 24,5 % dos
softwares mais utilizados so desenvolvidos internamente, o que mostra
que as empresas no conseguem encontrar uma ferramenta adequada
para as suas necessidades (PMI 2012).
Existem softwares mais completos em relao ao suporte das
atividades de gerenciamento de projetos mas em geral so proprietrios
e possuem um custo alto para sua aquisio. Os softwares livres para
gerenciar projetos se encaixam como uma opo de baixo custo para as
MPE (EBERT 2009), mas em geral no apresentam um suporte
26
completo para prticas de modelos de referencias como, por exemplo,
CMMI-DEV. Alm disso, esse softwares oferecem suporte para prticas
de gerncia de projetos principalmente na fase de planejamento, mas
nem
tanto
para
atividades
de
monitoramento
controle
(WANGENHEIM 2009).
1.2 PROBLEMA
O cenrio onde as MPE esto inseridas complexo por
diversos motivos. Aumentar o nvel de qualidade dos produtos dentro
desse tipo de empresa pode comear pela melhoria na qualidade do
gerenciamento dos projetos, mas a limitao de capacidade de recursos
e financeira muitas vezes no levada em considerao pelos modelos e
guias em evidencia atualmente.
importante que se defina um modelo em alinhamento com as
prticas atualmente utilizadas, mas gerenciar projetos sem uma
ferramenta de apoio uma tarefa muito custosa.
Existem opes para utilizao de ferramentas, uma delas seria
o desenvolvimento interno de solues. Essa opo muito interessante
do ponto de vista de aderncia aos processos, mas ainda consome tempo
e capital financeiro no reembolsvel diretamente, pois o seu
desenvolvimento normalmente deve gerar um software de apoio e no
um produto comercializvel alm de ser necessrio um especialista na
empresa para fornecer o conhecimento necessrio na concepo da
ferramenta.
Convm destacar que antes de se desenvolver uma ferramenta
para gerenciamento de projetos fundamental que se defina antes qual o
27
alinhamento que ela deve seguir. A falta de uma direo para o suporte
fornecido pode ser um dos principais problemas na maioria das
ferramentas disponveis.
1.3 PERGUNTA DE PESQUISA
Como desenvolver um modelo genrico para que MPE possam
realizar atividades de monitoramento e controle alinhada aos
processos/prticas do CMMI e PMBOK sendo apoiadas por uma
ferramenta?
1.4 OBJETIVOS
Abaixo so apresentados os objetivos a serem atingidos por este
trabalho.
1.4.1 - OBJETIVOS GERAIS
O objetivo geral desse trabalho consiste em definir um modelo
genrico de processos, e ferramenta de suporte ao modelo, para
monitoramento e controle de projetos que esteja alinhado ao PMBOK
(4. ed.) e CMMI-DEV v1.3 para a gesto de projetos em MPE.
1.4.2 - OBJETIVOS ESPECFICOS
Os objetivos especficos so:
Objetivo 1: Definir um modelo genrico de processo para
monitoramento e controle de projetos alinhado a realidade das Micro e
Pequenas Empresas.
Objetivo 2: Avaliar ferramentas de cdigo livre para
gerenciamento de projetos em relao ao suporte fornecido para
28
monitoramento e controle em alinhamento ao PMBOK (4. ed.) e
CMMI-DEV v1.3.
Objetivo 3: Realizar a anlise de requisitos, concepo,
especificao, implementao e testes para a implementao de novas
funcionalidades na ferramenta selecionada, direcionando o suporte para
monitoramento e controle alinhado ao CMMI v1.3 e PMBOK (4. ed.).
Objetivo 4: Avaliar a evoluo do software aperfeioado por
meio de um survey com especialistas que devero avaliar o modelo e a
ferramenta sobre sua aderncia ao ambiente das MPE.
1.4.3 - ESCOPO E DELIMITAO DO TRABALHO
Os estudos realizados nesse trabalho limitam-se a definio do
modelo genrico de processo para monitoramento e controle de projetos
suportado pelo PMBOK (4. ed.) e CMMI-DEV v1.3 para MPE mais
especificamente da rea de desenvolvimento de softwares e
implementao de funcionalidades de apoio em somente uma
ferramenta livre selecionada.
1.5 METODOLOGIA
Este trabalho realizado em cinco etapas: estudo da literatura,
avaliao de softwares livres para gerncia de projetos, definio do
para MPE,
implementao da abordagem mapeada no software
selecionado e por ltimo a aplicao e avaliao de resultados.

O mtodo de trabalho aplicado para as pesquisas definido
segundo sua natureza como pesquisa aplicada. A pesquisa aplicada
29
busca gerar conhecimentos para a aplicao prtica dirigida a soluo
de um problema especifico (SILVA 2001).
Do ponto de vista de forma de abordagem, so classificadas
como pesquisas qualitativas, onde no requer uso de mtodos e tcnicas
estatsticas sendo o pesquisador instrumento chave na coleta de dados
(SILVA 2001).
Com relao aos objetivos, essas pesquisas so classificadas
como exploratrias em primeiro nvel, pois tem como foco proporcionar
maior familiaridade com um problema com vistas a torn-lo explicito,
posteriormente so classificadas como explicativa, pois procura
identificar os fatores que determinam ou contribuem para a ocorrncia
do fenmeno estudado (SILVA 2001).
Abaixo segue o detalhamento de cada etapa:
Etapa 1: Estudo da literatura

A primeira etapa desse trabalho destinada a realizao de uma
pesquisa de reviso bibliogrfica sobre gerncia de projetos mais
especificamente focada no tpico monitoramento e controle. O objetivo
dessa etapa fundamentar os conceitos necessrios para o
desenvolvimento
dos
estudos
melhoria
da
ferramenta
de
gerenciamento que selecionada posteriormente. A pesquisa baseia-se

em artigos cientficos, WEB, jornais, revistas tcnicas e livros.
E1.1 Realizar a reviso bibliogrfica sobre gerncia de projetos

em PMC (Project Monitoring and Control);
E1.2 Estudar os modelos de melhoria de processos (PMBOK e

CMMI-DEV);
30
E1.3 Pesquisar o estado da arte no assunto abordado.
Etapa 2: Avaliao de softwares livres para gerncia de projetos

O
objetivo
desta
etapa
identificar
ferramentas
de
gerenciamento de projetos para verificar o seu grau de suporte para

monitoramento e controle segundo as prticas e processos das
referncias atuais, PMBOK e CMMI-DEV. Nesta etapa feita uma
pesquisa, com base em critrios pr-definidos, para selecionar
ferramentas livres de gerenciamento de projetos. Aps a seleo e
classificao elas so instaladas e avaliadas com mais detalhamento
com base nos critrios de monitoramento e controle. O alinhamento das
funcionalidades implementadas nas ferramentas comparado com um
estudo
para
mapeamento
entre
PMBOK
CMMI
(WANGENHEIM 2009).
E2.1 Definir a avaliao com base no conjunto de critrios

identificado na reviso bibliogrfica;
E2.2 Coletar dados referentes aos critrios de avaliao e

analisar cada um nas ferramentas selecionadas
Etapa 3: Definio do modelo genrico de processo para

monitoramento e controle de projetos para micro e pequenas
empresas
O objetivo desta etapa criar um modelo genrico de processo
para monitoramento e controle de projetos que possa ser utilizado em
MPE atendendo a critrios estabelecidos no PMBOK e CMMI-DEV. O
modelo composto de processos com suas entradas, sadas,
31
responsveis e ferramentas e tcnicas utilizadas para transformar as
entradas nas sadas previstas. Para a definio do modelo realizado um
estudo levando em considerao o contexto em que as MPE esto
inseridas.
E3.1 Definir o modelo genrico de processo identificando

entradas e sadas de cada etapa no processo;
E3.2 Definio de templates que podem servir de modelo no

processo de monitoramento e controle.
Etapa 4: Implementao da abordagem mapeada no software

selecionado
Na etapa de implementao selecionada a ferramenta que
mais fornece suporte entre todas avaliadas e os requisitos funcionais so
definidos para aumentar o seu grau de suporte, alinhando as
funcionalidades ao modelo previamente definido. Os requisitos so
mapeados em casos de uso que por sua vez guiam o processo de
implementao da soluo proposta. Toda a soluo concebida
implementada sob o conceito de
mdulo, para que possa ser
disponibilizado posteriormente para a comunidade.

O ciclo de vida utilizado no desenvolvimento o iterativo
incremental (PRESSMAN 2011), onde o projeto tem um ciclo de vida
consistindo de vrias repeties (ou fases). Uma iterao incorpora o
conjunto sequencial de atividades em modelagem de negcio,
requisitos, anlise e projeto, implementao, teste e distribuio em
vrias propores, dependendo de onde a iterao est localizada no
ciclo de desenvolvimento. Iteraes nas fases de incio e de elaborao
focam nas atividades de gerenciamento, requisitos e design; iteraes na
32
fase de construo focam em projeto, implementao e teste, e iteraes
na fase de transio focam em testes e distribuio dos produtos
gerados.
Os artefatos gerados para a implementao so diagramas de
caso de uso, descrio de casos de uso, prottipos de tela e diagrama de
entidade e relacionamento (OMG 2005).
Para a realizao dos testes solicitado para uma pessoa
externa ao projeto avaliar o trabalho realizado a fim de encontrar
problemas e falhas antes da etapa de validao dos resultados.
E4.1 Desenvolver os requisitos para evoluir a ferramenta

dotProject em PMC alinhado ao PMBOK (4. ed.) e CMMI
v1.3.
E4.2 Criar os casos de uso para as novas funcionalidades da

ferramenta;
E4.3 Elaborar os artefatos necessrios para o desenvolvimento
da evoluo da ferramenta;
E4.4 Testar a implementao realizada.
Etapa 5: Aplicao e avaliao de resultados

A ltima etapa deste trabalho consiste em realizar um survey com
especialistas com experincia em gerenciamento de projetos, para que
eles possam avaliar o modelo e a implementao realizada por meio de
um cenrio proposto de um projeto.
Primeiramente so definidos quais indicadores devem ser
analisados para medir a aderncia do modelo genrico de processo e
novas funcionalidades para o contexto das MPE.
33
Em seguida elaborado um questionrio que deve ser autorizado
pelo Comit de tica em Pesquisa com Seres Humanos (CEPSH),
conforme determina a Universidade Federal de Santa Catarina (UFSC)
onde este trabalho est sendo realizado.
A ferramenta dotProject instalada em um servidor web e e-mails
so enviados para listas de discusso da rea de gerenciamento de
projetos explicando o objetivo da pesquisa. Detalhes do modelo
genrico de processo, funcionamento da ferramenta evoluda e local
onde o questionrio pode ser respondido para fornecer o feedback do
trabalho executado so detalhados no e-mail. As respostas recebidas so
contabilizadas para verificar se o modelo e ferramenta conseguiram
atingir os objetivos inicialmente previstos.
E5.1 Definir os indicadores de desempenho para avaliar o

modelo e a ferramenta utilizando a tcnica de GQM (Goal
Question Metric) (GQM 2012);
E5.2 Montar o projeto para avaliao dos especialistas;
E5.3 Elaborar manual de suporte para a ferramenta.
E5.4 Analisar os dados coletados
Etapa 6: Avaliao da ferramenta evoluda

Ao final do trabalho realizada uma nova avaliao da ferramenta
para verificar a nova avaliao do seu suporte com as novas
funcionalidades desenvolvidas.
E6.1 Executar novamente a anlise do estado da arte agora com

o sistema evoludo usando o conjunto de indicadores
unificados.
34
1.6 JUSTIFICATIVA
Do ponto de vista cientifico, este projeto est definindo um
para MPE alm de realizar um estudo sobre ferramentas livres que
fornecem suporte para monitoramento e controle de projetos seguindo
os modelos de referncia PMBOK e CMMI-DEV.
No mbito tecnolgico est aprimorando uma ferramenta,
analisando seus recursos j existentes, modelando novos com base em
requisitos elencados a partir do mapeamento do PMBOK com o CMMIDEV e implementando esses novos recursos resultando em uma
ferramenta mais aderente s atividades de monitoramento e controle de
projetos.
Pela viso social, existe essa tendncia de ferramentas de
cdigo livre, que vm adquirindo cada vez mais adeptos com o mesmo
objetivo: criar ferramentas de qualidade e sem custos financeiros para
serem utilizadas pela comunidade em geral. Este trabalho pretende
aprimorar uma ferramenta e disponibiliz-la com a mesma licena de
uso GNU-GPL (General Public License)(GNU 2007) que significa que
esta ferramenta pode ser copiada, instalada e utilizada gratuitamente .
A existncia de uma ferramenta gratuita com os recursos
disponveis alinhados ao estado da arte em gesto de projetos tende a
auxiliar as MPEs que tem vontade de crescer, mas no possuem
recursos financeiros. Esse projeto, portanto, justificvel pelo mbito
social.
Ainda se pode citar o ponto de vista econmico, pois no Brasil
a taxa de mortalidade das micro e pequenas empresas nos primeiros
cinco anos considerada alta (ORTIGARA 2006) e o presente trabalho
35
tem como pretenso melhorar uma ferramenta de gesto de projetos sob
o aspecto de monitoramento e controle, atividade que realizada
durante todo o ciclo de vida de um projeto e o seu sucesso diretamente
relacionado ao sucesso do projeto e da empresa.
36
2. CONCEITOS FUNDAMENTAIS
Neste captulo do trabalho so apresentados os conhecimentos
necessrios que serviro como base para o aprimoramento e avaliao
da ferramenta de gerncia de projetos a ser estudada. Inicialmente sero
apresentados os conceitos sobre gerncia de projetos e em seguida
aprofundaremos a rea de monitoramento e controle de projetos.
2.1 GERNCIA DE PROJETOS
Gerenciar projetos pode ser definido como a aplicao de
conhecimentos, habilidades, ferramentas e tcnicas s atividades do
projeto a fim de atender aos seus requisitos (PMI 2008). Essa afirmao
pode se observada em outros modelos de melhoria de processos como o
CMMI-DEV que exalta procedimentos, pessoas e ferramentas como as
trs principais dimenses as quais as organizaes tipicamente focam
esforos (SEI 2010).
Para se entender bem o conceito acima necessrio que se
saiba com clareza o que um projeto. Segundo Vargas (2005), um
empreendimento no repetitivo, caracterizado por uma sequencia clara e
lgica de eventos, com incio, meio e fim, que se destina a atingir um
objetivo claro e definido sendo conduzido por pessoas dentro de
parmetros predefinidos de tempo, custo, recursos envolvidos e
qualidade.
O gerenciamento de projetos de acordo com o PMI (2008),
identifica e descreve 42 processos que so classificados em duas
dimenses, reas de conhecimento e grupos de processos. As reas de
conhecimento podem ser visualizadas conforme Figura 2 abaixo:
37
Escopo
Aquisies
Riscos
Tempo
Custos
Integrao
Comunicaes
Qualidade
Recursos
Humanos
Figura 2 - reas de conhecimento de gerenciamento de projetos

Fonte: PMI (2008).
Cada uma das 9 reas de conhecimento trata de um ponto

especfico para o gerenciamento de projetos, abaixo segue uma breve
descrio de cada uma das reas:
Gerenciamento da Integrao - Inclui todos os processos e as

atividades necessrias para combinar as demais reas de
gerenciamento.
Gerenciamento de Escopo Seu objetivo assegurar que todo

o trabalho a ser realizado est includo no projeto, e apenas o
necessrio, para terminar o projeto com sucesso.
38
Gerenciamento de Tempo Engloba os processos necessrios

para assegurar a concluso do projeto pontualmente no prazo
previsto.
Gerenciamento de Custos Contm os processos requeridos

para estimativa, oramentos e controle de custo para assegurar
que um projeto seja concludo de acordo com seu oramento
previsto.
Gerenciamento de Qualidade Inclui os processos e atividades

da organizao executora que determinam as polticas de
qualidade, os objetivos e as responsabilidades para atender o
nvel de qualidade exigido no projeto.
Gerenciamento de Recursos Humanos Contm os processos

responsveis por organizar e gerenciar a equipe definindo
papeis e responsabilidades necessrias para a concluso do
projeto.
Gerenciamento das Comunicaes Engloba os processos

requeridos para assegurar que as informaes do projeto sejam
geradas, coletadas, distribudas, armazenadas, recuperadas e
organizadas de maneira oportuna e apropriada.
Gerenciamento
de
Riscos
Inclui
os
processos
de
planejamento, identificao, anlise, planejamento de resposta,

monitoramento e controle de riscos do projeto.
Gerenciamento de Aquisies - Engloba os processos

requeridos para comprar ou adquirir produtos, servios ou
resultados externos equipe do projeto. Tambm conhecido
como gerenciamento de suprimentos.
39
Os grupos de processo esto relacionados ao ciclo de vida de
um projeto. Essas fases permitem que sejam identificadas diversas
familiaridades que podem ser encontradas em todos os projetos,
independente de sua natureza. Os grupos de processos podem ser
visualizados na Figura 3 abaixo.
Figura 3 Grupos de Processos de gerenciamento de projetos

Fonte: PMI (2008).
Note na figura acima que o processo de monitoramento e

controle uma atividade que engloba praticamente todo o ciclo de vida
do projeto.
Abaixo segue uma breve descrio sobre cada grupo de
processo segundo o PMI (2008).
Grupo de processo de inicializao - So os processos

realizados para definir um novo projeto ou fase em um projeto
j existente atravs da obteno de autorizao para iniciar o
projeto ou fase.
Grupo de processos de planejamento - So os processos

realizados para definir o escopo do projeto, refinar os objetivos
40
e desenvolver o curso da ao necessrio para alcanar os
objetivos para os quais o projeto foi criado.
Grupo de processos de execuo - So os processos realizados

para executar o trabalho definido no plano de gerenciamento do
projeto para satisfazer as especificaes do mesmo.
Grupo de processos de monitoramento e controle - So os

processos necessrios para acompanhar, revisar e regular o
progresso e o desempenho do projeto, identificar todas as reas
nas quais sero necessrias mudanas no plano e iniciar as
mudanas correspondentes.
Grupo de processos de encerramento - So os processos

executados para finalizar todas as atividades de todos os grupos
de processos, visando encerrar formalmente o projeto ou fase.
Finalmente na Tabela 2 fica clara a relao entre as reas de

conhecimento, os grupos de processos e os processos propriamente
ditos.
Tabela 2 - Mapeamento de grupos de processos de gerenciamento de
projetos e reas de conhecimento.
Fonte: PMI (2008).
reas de
conhecimento
Grupo de
processo de
iniciao
Grupo de
processos de
planejamento
Grupo de
processos de
execuo
Gerenciamento 1.Desenvolda Integrao

ver o termo
do projeto
de abertura
do processo
2. Desenvolver
o plano de
gerenciamento
do projeto
3. Orientar e
gerenciar a
execuo do
projeto
Grupo de
Grupo de
processos de
processos de
monitoramento encerramento
e controle
4. Monitorar e 6. Encerrar o
controle o
projeto ou fase
trabalho do
projeto
5. Realizar o
controle
integrado de
mudanas
41
Gerenciamento
do escopo do
projeto
1. Coletar os
requisitos
2. Definir o
escopo
3. Criar a EAP
1. Definir as
atividades
2. Sequenciar
as atividades
3. Estimar os
recursos das
atividades
4. Estima as
duraes das
atividades
5. Desenvolver
o cronograma
4. Verificar o
escopo
5. Controlar o
escopo
Gerenciamento
dos custos do
projeto
1. Estimar os
custos
2. Determinar
o oramento
3. Controlar
os custos
Gerenciamento
da qualidade
do projeto
1. Planejar a
qualidade
2. Realizar a
garantia da
qualidade
Gerenciamento
dos recursos
humanos do
projeto
1. Desenvolver
o plano de
recursos
humanos
Gerenciamento 1. Identificar
das
as partes
comunicaes
do projeto
2. Planejar as
comunicaes
2 Mobilizar
a equipe do
projeto
3
Desenvolver
a equipe do
projeto
4 Gerenciar
a equipe do
projeto
3. Distribuir
as
informaes
4. Gerenciar
as
expectativas
das partes
interessadas
Gerenciamento
do tempo no
projeto
6. Controlar o
cronograma
3. Realizar o
controle da
qualidade
5. Reportar o
desempenho
42
1 Planejar o
gerenciamento
dos riscos
2 Identificar os
riscos
3 Realizar a
anlise
qualitativa dos
riscos
4 Realizar a
anlise
quantitativa
dos riscos
5 Planejar as
respostas aos
riscos
1 Planejar as
aquisies
Gerenciamento
dos riscos do
projeto
Gerenciamento
das aquisies
do projeto
6 Monitorar e
controlar os
riscos
2 Conduzir
3 Administrar
as aquisies as aquisies
4 Encerrar as
aquisies
No contexto desse trabalho, podemos notar que na Tabela 2 a

quinta coluna "Grupo de processos de monitoramento e controle", ser
abordada mais detalhadamente no prximo tpico desse trabalho. Esse
grupo de processo de monitoramento e controle faz parte de um dos 5
grupos de conhecimento do PMBOK e est presente em praticamente
em todas as reas de conhecimento com exceo da rea de
conhecimentos de recursos humanos.
2.1.1 - PROCESSO DE MONITORAMENTO E CONTROLE
(PMC-PROJECT MONITORING & CONTROL)
O objetivo do processo de monitoramento e controle fornecer
o entendimento do progresso do projeto para que aes corretivas
possam
ser
tomadas
quando
projeto
estiver
desviando
significantemente do seu plano (MCCONNELL 1997) (JALOTE 2000)

(HANAKAWA, KIMIHARU 2004) (SEI 2010).
43
Quando falamos em projetos de software, monitoramento e
controle tornam-se um pouco mais complexos devido a natureza
abstrata que envolve desenvolvimento de software (HAUCK 2007).
Frequentemente projetos de software falham porque eles no so
devidamente monitorados e controlados a ponto de uma falha se tornar
visvel antes que seja tarde demais para tomar uma ao corretiva
(WANGENHEIM 2009).
Monitoramento
significa
capturar,
analisar,
reportar
comunicar o desempenho do projeto cruzando as medidas reais de

andamento das atividades com as medidas previamente estimadas no
planejamento. Controlar significa tomar aes necessrias de correo
para que as medidas reais se aproximem o mximo possvel das
medidas planejadas (WANGENHEIM 2009).
Segundo Jalote (2000), um dos primeiros passos a serem
tomados antes de iniciar um projeto de monitoramento selecionar
quais so os dados que realmente so relevantes dentro do contexto do
projeto.
Depois de selecionado os dados, o monitoramento ingressa em
um ciclo que seguido durante toda e existncia do projeto e em todas
as fases e reas de conhecimento. Abaixo na Figura 4 segue o modelo
do ciclo de monitoramento e controle proposto por Jalote.
44
Figura 4 - Ciclo monitoramento e controle proposto por Jalote

Fonte: Jalote (2000).
Para exemplificarmos os processos que so executados dentro

do monitoramento e controle de um projeto, tomaremos como
referncia o PMBOK. Dentro desse modelo o processo de
monitoramento e controle est incorporado a diversas atividades que
devem ser executadas durante o gerenciamento. Abaixo na Figura 5
podemos verificar como o monitoramento e controle se integra com os
demais processos de um projeto.
45
Figura 5 - Grupo de processo de monitoramento e controle

Fonte: PMI (2008)
Para ilustrar os prximos tpicos do trabalho, ser feita uma

analogia a um projeto imaginrio, nomeado de Pizzaria do Chico que
pode ser observado na caixa abaixo.
46
Um cliente chamado Chico, que dono de uma pizzaria, ligou com
uma proposta de projeto. Atualmente, oferece a entrega em domiclio via
ligaes telefnicas. Para ampliar o seu negcio, ele deseja possibilitar que os
seus clientes, por meio da internet, possam encomendar pizzas no site de seu
estabelecimento. Estas informaes sero processadas por seus dois
atendentes, que precisaro ser treinados, visto que atualmente tm pouco
conhecimento de TI. O cliente pretende lanar o sistema trs meses aps a
aprovao do projeto. Para esse projeto, sero utilizados R$15.000,00 que
estavam rendendo em aplicaes. Estaro disponveis para desenvolver o
projeto mais duas pessoas interessadas em participar.
Tabela 3 - Custos Fixo do projeto Pizzaria do Chico
Custo
Compra de servidor
Tipo de servio
Produto
Valor
R$ 3.000,00
Tabela 4 - Atividades do projeto Pizzaria do Chico
Atividade
Modulo de Segurana
Mdulo de Cadastros
Mdulo de Pedidos
Durao
1 Ms
1 Ms
1 Ms
Data
Custo
01/06/2012
R$ 2.000,00
01/07/2012
R$ 4.000,00
01/08/2012
R$ 6.000,00
Tabela 5 - Restries do projeto Troca-Pneu
Restries
O sistema deve rodar no navegador Interne Explorer, Mozilla e
Chrome com resposta de no mximo 3 segundos.
Ao final de cada tpico iremos fazer uma analogia do assunto

tratado com o projeto acima descrito.
47
2.1.1.1
MONITORAR E CONTROLAR O TRABALHO DO

PROJETO
Sendo parte da rea de conhecimento de integrao, esse
processo abrange todas as outras reas e tem como foco acompanhar,

avaliar e regularizar o progresso do projeto para atender aos objetivos
de desempenhos previamente definidos no plano.
Esse conceito e sua importncia j faz parte da maioria das
atividades rotineiras das empresas brasileira onde, em uma pesquisa
realizada pelo PMI (2012), aproximadamente 60% das empresas
declararam que possuem processos para monitoramento dos projetos
dentro do seu portflio.
Entre algumas atividades desempenhadas por esse processo
podemos destacar (PMI 2008):
Comparao entre o andamento real do projeto e o planejado;
Avaliao de desempenho para determinar atividades necessrias de

correo ou preveno;
Identificao, anlise e acompanhamento de novos riscos e

monitoramento de riscos j existentes, aplicando os critrios
definidos no planejamento de riscos para tratar de forma adequada
todos eles;
Manter uma base de informaes completa sobre os produtos do

projeto e os documentos referentes a eles;
Disponibilizar informaes sobre andamento, medio do progresso

e previso;
Fornecer previses para atualizaes de informaes do projeto;
Monitorar a execuo de atividades aprovadas.
48
A Figura 6 ilustra a integrao do processo de monitoramento e
controle do trabalho do projeto com outras atividades desenvolvidas
durante o projeto conforme o PMI (2008).
Figura 6 - Diagrama de fluxo de dados do processo de monitorar e

controlar o trabalho do projeto
Fonte: PMI (2008).
Monitorar envolve medir os dados atuais do projeto e comparar

as medidas com o planejamento feito para cada etapa do projeto (SEI
2010). Caso as atividades monitoradas fiquem fora dos limites
estabelecidos, medidas corretivas devem ser executadas (HUGHES
2001) (SEI 2010). A Figura 7 ilustra o modelo de um projeto de
monitoramento e controle e mostra como, uma vez que o plano inicial
do projeto tenha sido publicado, o monitoramento contnuo durante
todo o ciclo de vida do projeto. Alm disso, mostra tambm atividades
49
importantes que devem ser executadas ao final do projeto, como a
definio de lies aprendidas.
Figura 7 - Fluxo de atividades de monitoramento e controle

Fonte: HUGHES (2001).
Segundo o CMMI, tomar medidas corretivas pode incluir atividades

como (SEI, 2010):
Reparar produtos de trabalho ou servios com problemas;
Alterar o plano de execuo do processo;
Ajustar recursos, incluir pessoas, ferramentas e outros;
50
Negociar mudanas nos compromissos assumidos;
Caso seja necessrio alterar requisitos e objetivos, negociar

com as partes interessadas afetadas pela alterao de forma a
obter sua concordncia;
Encerrar o trabalho.
Independente do porte da organizao comum notarmos

grande dificuldade em se obter informaes precisas no processo de
monitoramento do projeto. Essa dificuldade pode ser explicada por
alguns problemas comuns encontrados dentro de organizaes como
(HUGHES, 2002):
Estimativas e planejamentos realizados de maneira simples

com baixa qualidade;
Falta de padres de qualidade e de medidas;
Falta de orientao sobre as tomadas de deciso da

organizao;
Falta de tcnicas para tornar claro o progresso do projeto;
Falta de definies de papis;
Critrios incorretos de sucesso.
A principal ferramenta para monitorar e controlar o trabalho do

projeto a opinio especializada (PMI 2008). Nesse caso a experincia
do gerente de projetos e tambm de sua equipe so fatores importantes
para se obter uma leitura precisa do projeto. A utilizao de uma
metodologia e utilizao de um sistema de informaes do
gerenciamento de projetos so tambm recursos sugeridos pelo PMI
51
(2008) para monitorar e controlar o trabalho do projeto. Existem
tambm tcnicas que pode ser adotadas no processo de medio como,
por exemplo, a tcnica do valor agregado que mede o desempenho do
projeto conforme seu andamento (ZHU 2010). Normalmente essa
tcnica realizada pelas ferramentas de apoio.
Realizando a analogia desse tpico ao nosso projeto Pizzaria
do Chico, podemos sugerir o seguinte cenrio:
Andr, gerente do projeto, faz reunies semanais para
verificar se o projeto est sendo executado conforme o planejado.
No final da primeira semana ele verifica que o andamento das
atividades esto ocorrendo com uma produtividade maior que o
previsto no cronograma, mesmo estando dentro do gasto previsto.
Como essa informao acarreta em um impacto positivo para o projeto
decidido no tomar nenhuma deciso e continuar o projeto.
No decorrer da segunda semana um funcionrio faltou ao
trabalho por 2 dias e com isso o projeto teve um impacto negativo nas
atividades planejadas. Em reunio decidido que ser solicitada horas
extras para que o projeto volte ao seu planejamento inicial
Dessa forma, monitorar e controlar o trabalho do projeto tem
como objetivo colocar novamente o projeto no caminho do que foi
planejado ou adequar as demais atividades ao desvio identificado.
Qualquer mudana dentro do projeto seja ela com impacto negativo ou
positivo deve refletir em atualizao da documentao e registro da
mudana para que se torne notria a alterao.
52
2.1.1.2
REALIZAR O CONTROLE INTEGRADO DE

MUDANAS
Segundo o PMI (2008), o controle integrado de mudanas deve
incluir vrias atividades de gerenciamento de mudanas em nveis

diferentes de detalhamento, com base no progresso do projeto de
execuo:
Influenciar os fatores que tentam evitar o controle integrado de

mudanas para que somente as mudanas aprovadas sejam
implementadas;
Revisar, analisar e aprovar as solicitaes de mudanas

imediatamente;
Gerenciar as mudanas aprovadas;
Manter a integridade do planejamento inicial das atividades

liberando somente as mudanas aprovadas para serem
incorporadas ao plano de gerenciamento do projeto e aos
documentos do projeto;
Revisar, aprovar ou rejeitar todas as aes corretivas e

preventivas recomendadas;
Coordenar as mudanas atravs de todo o projeto;
Documentar o impacto completo das solicitaes de mudana.
O tamanho do projeto influencia diretamente no controle que

deve ser realizado sobre as mudanas. Geralmente essas mudanas no
so solicitadas de maneira ordenada e ao mesmo tempo, por esse motivo
pode ser muito difcil compreender a sua natureza e os impactos que
cada uma delas pode causar dentro do projeto.
53
Toda alterao no projeto pode ser solicitada de maneira
informal, mas deve sempre ser registradas formalmente dentro dos
documentos do projeto. Tendo essa solicitao formalizada,
necessrio que ela passe por um processo de aprovao que pode
envolver somente o gerente do projeto ou uma comisso previamente
definida para esse fim. Aps a aprovao necessrio ser feito um novo
planejamento para que possam ser identificados pontos de impactos e
com isso revisado estimativas de custos, sequencias de atividades, datas
do cronograma, requisitos de recursos e anlise de riscos. Por fim,
necessrio atualizar toda a documentao necessria para registrar a
nova atividade que foi solicitada e sua adaptao ao projeto (PMI 2008).
Esse fluxo de atividades pode ser visualizado na Figura 8.
Figura 8 - Atividade de controle integrado de mudanas
54
As aplicaes dessas etapas procura alcanam trs objetivos
(PMI 2008):
Estabelecer um mtodo evolutivo para consistentemente

identificar e modificar atividade no planejamento e avaliar seus
impactos em termos de esforo e benefcios;
Proporcionar oportunidades de avaliar e aprimorar o projeto

continuamente considerando todos os aspectos que envolvem a
mudana a ser implementada;
Fornecer equipe de gerenciamento o mecanismo para que se

comunique com os envolvidos no projeto sobre mudanas
aprovadas e rejeitadas.
A opinio especializada tambm nesse processo uma das
principais ferramentas na realizao do controle integrado de mudanas.

Dessa forma a experincia do gerente e da equipe so fatores
importantes que podem levar ao sucesso desse processo.
Outra ferramenta importante a chamada reunio de controle
de mudanas, que tem como objetivo revisar e aprovar/rejeitar
qualquer solicitao de alterao no planejamento anterior do projeto.
Esse comit reunido sempre que o gerente do projeto encontre alguma
solicitao de mudana a qual ele no tenha autorizao para aprovar ou
rejeitar sozinho. Os poderes delegados ao gerente de projetos
normalmente so definidos claramente no plano de gerenciamento do
projeto.
55
Voltando ao projeto Pizzaria do Chico, sugerimos o seguinte
exemplo de controle de mudanas:
O filho do Chico, sugere que seria uma boa oportunidade
para tambm trocar outros computadores da pizzaria pois os que
existem hoje so ultrapassados e lentos. Realizando um oramento
aproximado verificou-se que o custo ficaria 30% maior.
Chico avalia essa solicitao, documenta ela para poder
realizar todas as atividades de planejamento necessrias e definir se
essa alterao no escopo do projeto deve ser aceita ou no.
Em reunio chegou-se a concluso que o custo deve
inviabilizar essa solicitao pois o valor ficaria muito superior ao
que foi inicialmente planejado. Talvez em uma prxima
oportunidade possa ser realizado um outro projeto que inclua a troca
do outro computador da pizzaria.
A solicitao novamente atualizada e registrada no
projeto.
2.1.1.3
VERIFICAR O ESCOPO
Este processo destina-se a formalizao de aceitao das
entregas terminadas do projeto. Normalmente o projeto envolve muito

mais que somente as expectativas do cliente e por esse motivo
importante ressaltar os pontos relevantes ao entendimento do cliente. A
Figura 9 exibe esse conceito.
56
Figura 9 - Escopo na viso do projeto e do cliente
As entregas devem ser revisadas junto ao cliente ou

patrocinador
para
se
ter
garantia
de
que
esto
concludas
satisfatoriamente e com isso se obter a aceitao formal da entrega.

A principal ferramenta nesse processo a inspeo. Seu
objetivo medir, examinar e verificar se o trabalho e as entregas
atendem aos requisitos e aos critrios de aceitao do produto (PMI
2008).
Um dos componentes utilizados como dado de entrada para a
verificao de escopo a EAP1 (Estrutura Analtica de Projeto) (PMI
2008). Essa ferramenta consiste em decompor um projeto em seus
elementos componentes. uma imagem da hierarquia do projeto,
decompondo nvel a nvel em subprojetos e finalmente em tarefas
(DAYCHOUM 2010).
Structure)
A EAP conhecida tambm como WBS (Work Breakdown
57
Referenciando o nosso projeto Pizzaria do Chico, podemos
evidenciar a diferena de escopo do projeto e para o cliente
claramente. Para o Chico, o projeto se resume em fazer um site para
solicitar pedidos de pizza online, isso que interessa para ele e as
atividades suplementares como elaborao da estrutura de segurana
e cadastros auxiliares poderiam fica em um segundo plano e talvez
no fossem percebidas por ele apesar de fazer parte do escopo.
Mesmo no sendo percebida, a verificao do escopo do projeto deve
abranger todas as atividades previstas. Na
visualizar um da EAP desse projeto
Figura 10 - EAP Projeto Trocar-pneu
Figura 10 podemos
58
2.1.1.4
CONTROLAR O ESCOPO
Este processo responsvel por monitorar o andamento do
escopo do projeto e do produto e gerenciamento de mudanas (PMI

2008).
Com a evoluo do projeto e o contato entre os colaboradores,
usurios e patrocinadores muitas vezes surgem necessidades novas e
adaptaes. As mudanas de escopo tambm podem ser originadas por:
Nova legislao e regulamentos inerentes ao negcio do

projeto;
Mudanas no planejamento estratgico do cliente;
Mudanas gerenciais;
Mudanas tecnolgicas.
Todos esses fatores nos mostram como um projeto frgil ao

risco de alteraes e como o processo de controle de escopo
importante para analisar e tratar devidamente todas as solicitaes de
mudana que podem ser efetuadas.
Na Figura 11 podemos visualizar um resumo do fluxo bsico e
interaes dentro do processo de controle do escopo.
59
Figura 11 - Fluxo de dados do processo Controlar Escopo.

Fonte: PMI (2008)
De forma geral, podemos ainda definir o controle de escopo

atravs das seguintes etapas:
Divulgao inicial do escopo do projeto;
Formalizao de pedidos de mudanas;
Indicao dos responsveis pelas mudanas;
Avaliao de impacto das solicitaes;
Aprovao ou rejeio das solicitaes;
Homologao e disseminao das mudanas aprovadas;
Implementao da mudana.
A principal ferramenta nesse processo a anlise de variao
onde medies de desempenho do projeto so usadas para avaliar o grau

de variao a partir do planejamento do projeto.
60
No nosso projeto Pizzaria do Chico, o controle de escopo
pode ser exemplificado com a seguinte situao. Imagine que Andr
est na primeira semana do projeto realizando a atividade prevista
para o mdulo de segurana do projeto. Ao conversar com o arquiteto
do projeto ele fica sabendo que poderia incluir no projeto um mdulo
responsvel pela integrao da central telefnica com o sistema que
est sendo desenvolvido sem nenhum tipo de impacto em custo ou
tempo. Essa situao mesmo que parecendo ser favorvel vai alterar o
escopo originalmente previsto para o projeto. Controlar o escopo
nessa situao garantir que somente as atividades planejadas sejam
executadas, qualquer situao nova deve ser tratada como fora do
escopo inicial do projeto e submetido para a anlise de aprovao de
mudana.
2.1.1.5
CONTROLAR O CRONOGRAMA
Segundo o PMI (2008), este processo responsvel por
atualizar o progresso e gerenciamento das mudanas feitas no

planejamento inicial do cronograma. O controle do cronograma est
relacionado a:
Determinao da situao atual do cronograma do projeto;
Influncia nos fatores que criam mudanas no cronograma;
Constatao de que o cronograma do projeto foi alterado;
Gerenciamento das mudanas reais conforme ocorrem.
61
Uma das principais ferramentas utilizadas em gerenciamento de
cronograma o Grfico de Gantt 2. Essa ferramenta um diagrama que
utiliza barras horizontais representando as atividades de um projeto e
mostra o perodo em que cada atividade ocorre dentro do projeto
(DAYCHOUM 2010).
Alm de visualizar o cronograma em forma de barras, podemos
tambm calcular o desempenho utilizando a tcnica conhecida como
anlise de desempenho. A anlise mede, compara e analisa o
desempenho do projeto tomando como parmetro datas reais de incio e
trmino das atividades assim como percentuais de completude das
tarefas. O controle do cronograma utiliza duas das trs dimenses do
Gerenciamento do Valor Agregado (GVA) para controlar o seu
desempenho, abaixo segue um pequeno descritivo sobre essas duas:
Valor Planejado VP (Planned Value - PV): Como o prprio

nome j denota, essa dimenso determina o valor financeiro que o
projeto necessita para alcanar um ponto planejado anteriormente,
no necessariamente no final de uma atividade. Esse calculo
realizado somando todas as atividades planejadas at o ponto que se
deseja medir, levando em considerao o percentual de concluso
de cada uma das atividades. O valor planejado para o projeto
tambm conhecido como Oramento no Trmino (ONT).
Valor Agregado VA (Earned Value - EV): Indica o valor do

trabalho finalizado em um determinado ponto do cronograma. Esse
clculo feito somando todas as atividades realizadas at o ponto
O grfico de Gantt comumente chamado de Cronograma Fsico
62
que se deseja medir, levando em considerao o percentual de
concluso de cada uma das atividades.
As dimenses do GVA so utilizadas na elaborao de

indicadores que fornecem leituras sobre o controle do cronograma.
Abaixo segue um descritivo de alguns desses indicadores:
ndice de desempenho
Variao de cronograma/prazo - VPR (Schedule Variance - SV):

Indica se o projeto est adiantado, atrasado ou em dia em relao ao
seu planejamento. Seu calculo definido subtraindo-se o Valor
Planejado do Valor Agregado (VPR = VA - VP).
VPR < 0: cronograma atrasado em relao ao planejado.
VPR > 0: cronograma adiantado em relao ao planejado.
VPR = 0: cronograma em dia em relao ao planejado.
ndice de desempenho de cronograma/prazo - IDP (Schedule

Performance Index - SPI): Indica a eficincia do uso do tempo pela
equipe. Seu clculo definido dividindo o Valor Agregado pelo
Valor Planejado (IDP = VA / VP).
IDP < 1: o desempenho do cronograma est abaixo do planejado.
IDP > 1: o desempenho do cronograma est acima do planejado.
IDP = 1: o desempenho do cronograma est como o planejado.
Os dois indicadores acima fornecem informaes sobre as
mesmas medidas sendo que o primeiro demonstra uma variao e o

segundo um ndice de desempenho.
Uma vez identificado atrasos dentro do projeto, necessrio
atuar na durao das atividades do caminho crtico do projeto. Para
63
esclarecer as variveis utilizadas no cronograma necessrio entender
os termos utilizados nesse contexto (PMI 2008):
Folga Livre: o atraso permitido para a data de incio mais cedo

de uma atividade sem atrasar qualquer atividade do cronograma
imediatamente subsequente.
Folga Total: o atraso total permitido para a data de incio mais

cedo de uma atividade sem atrasar a data de termino do projeto ou
violar alguma restrio do cronograma.
Caminho crtico: Geralmente, mas no sempre, a sequencia de

atividades que determina a durao do projeto, ou seja, so as
atividades sem folga livre presentes no projeto.
Durao: Nmero total de perodos de trabalho necessrios para

terminar uma atividade.
Existem duas tcnicas mais comuns para realizar a reduo do
prazo do projeto (DAYCHOUM 2010):

a) Caminho rpido ou paralelismo: Identifica atividades do caminho
crtico dentro do cronograma que inicialmente estavam organizadas
de maneira sequencial, mas podem ser executadas em paralelo.
b) Compresso: Inclui atividades realizadas como adio de novos
recursos, reduo de escopo, mudana de recursos, reduo de
qualidade
O uso de softwares so normalmente utilizados para realizar o
controle de cronograma, assim como as atividades de apoio.
64
Realizando a analogia ao nosso projeto Pizzaria do Chico, Andr que
o nosso gerente do projeto, vem acompanhando diariamente o
andamento das atividades utilizando o grfico de Gantt conforme a
Figura 12.
Figura 12 Grfico de Gantt do projeto Trocar-Pneu
No fim da segunda semana de projeto ele identifica que, pelo

fato de um funcionrio ter adoecido, as atividades previstas para dois
dias no foram executadas. Realizando a anlise de variao de prazo
e verificando o ndice de desempenho conforme Tabela 6, chegamos
a concluso de que o projeto est atrasado em relao ao planejado
pois a variao do cronograma est abaixo de 0 e o ndice de
desempenho est abaixo de 1.
Tabela 6 - Anlise do desempenho do cronograma
Avaliao do projeto no fim do segundo dia

Valor Agregado
Valor Planejado
Variao do cronograma
ndice de Desempenho de Prazo
R$ 700,00
R$ 1000,00
-R$ 300,00
0,7
65
Para reverter essa situao Andr pode incluir mais um
recurso para realizar o trabalho que no foi executado e continuar
com o andamento das atividades planejadas normalmente. Dessa
forma, no decorrer da terceira semana o cronograma estaria
novamente controlado. Outra possibilidade seria contar com o
esforo da equipe no decorrer das prximas semanas para recuperar o
tempo perdido.
O importante nessa atividade de controle de cronograma
identificar o mais cedo possvel o desvio para com isso poder tomar
uma deciso e correo tambm o mais cedo.
2.1.1.6
CONTROLAR OS CUSTOS
Este processo responsvel por atualizar o oramento das
mudanas feitas no planejamento dos custos. Segundo o PMI (2008), o

controle de custos do projeto est relacionado a:
Influenciar os fatores que criam mudanas no planejamento

inicial de custos autorizado;
Assegurar que todas as solicitaes de mudana sejam feitas de

maneira oportuna;
Gerenciar as mudanas reais conforme ocorrem;
Assegurar que os gastos de custos no excedam os recursos

financeiros autorizados, por perodo e total do projeto;
Monitorar o desempenho de custos para isolar e entender as

variaes do planejamento inicial dos custos;
66
Monitorar o desempenho do trabalho em relao aos recursos

financeiros gastos;
Prevenir que mudanas no aprovadas sejam includas no relato

do custo ou do uso de recursos;
Informar as partes interessadas apropriadas a respeito de

mudanas aprovadas e custos associados;
Agir para manter os excessos de custos no previstos dentro de

limites aceitveis.
Para realizar o monitoramento dos gastos em um projeto,

essencial se considerar o valor do trabalho sendo realizado para cada
atividade. Dessa forma, a relao entre o consumo de fundos do projeto
e o trabalho fsico sendo realizado para esses gastos a base do controle
de custos (PMI 2008).
O controle dos custos utiliza algumas tcnicas para auxiliar
nessa atividade, uma das mais conhecidas o Gerenciamento de Valor
Agregado (GVA):
O gerenciamento do valor agregado, conforme apresentado no
tpico anterior trabalha baseada em trs dimenses, para o controle do
custo iremos trabalhar com o custo real (CR).
Custo Real - CR (Actual Cost - AC): Indica o custo real que foi
utilizado na execuo do trabalho em uma atividade. Esse clculo
feito somando todos os valores reais consumidos por cada
atividade.
67
As dimenses do GVA so utilizadas na elaborao de mais
indicadores para fornecer leituras sobre os custos que envolvem o
projeto. Abaixo segue um descritivo de alguns desses indicadores:
Variao de Custo VC (Cost Variance - CV ): A Variao de

Custo mostra se o projeto est abaixo ou acima do valor orado.
calculado pela subtrao do Custo Real do Valor Agregado (VC =
VA CR).
VC < 0 => Projeto est com custo maior que o previsto no
oramento.
VC > 0 => Projeto est com custo menor que o previsto no
oramento.
VC = 0 => Projeto est com os custos iguais aos previstos no
oramento.
ndice de Desempenho do Custo IDC (Cost Performance Index CPI): O ndice de Desempenho do Custo mostra a eficincia da
utilizao dos recursos do projeto. Ele calculado dividindo-se o
Valor Agregado pelo Custo Real (IDC = VA / CR).
IDC < 1 => Indica um desempenho de custo acima do limite
planejado.
IDC > 1 => Indica um desempenho de custo abaixo do limite
planejado.
IDC = 1 => Projeto est com o custo conforme o planejado.
68
As dimenses utilizadas no gerenciamento do valor agregado
podem ser tambm monitoradas e relatadas de forma visual, conforme
apresentado na abaixo.
Figura 13 - Valor agregado, valor planejado e custo real

Fonte: PMI (2008)
Baseado na leitura atual do projeto e realizando projees com

os ndices de desempenho, possvel calcular a Estimativa no Trmino
(ENT) do projeto, que pode ser diferena do Oramento no Trmino
(ONT). A diferena entre eles que o ONT o oramento total do
projeto e a ENT calculada levando em considerao o ndice de
desempenho do custo do projeto e o seu oramento total (ENT = ONT /
IDC).
Outro ndice importante calculado com o gerenciamento do
valor agregado o ndice de Desempenho para Trmino (IDPT) que a
69
projeo de desempenho calculado de custos que deve ser atingida para
se alcanar um objetivo especfico como o ONT ou ENT.
Alm do GVA, podemos citar a Curva S como outra
ferramenta utilizada no controle do custo do projeto. Essa ferramenta
apresenta graficamente o status dos custos do projeto distribudos pela
linha do tempo. Dessa forma podemos acompanhar os desembolsos
previstos e realizados durante o tempo de vida do projeto.
Assim como no controle de cronograma, softwares de
gerenciamento so utilizados para realizar o controle de custos,
principalmente
no monitoramento
daspodemos
trs dimenses
do gerenciamento
Conforme
os outros tpicos,
exemplificar
o controle de
de valor
agregado:
valor planejado,
agregado e custo real.
custos
pelo
nosso projeto
Pizzaria dovalor
Chico.
Supondo no segundo ms do projeto Andr tenha gasto R$
10.000,00 ao invs dos R$ 9.000,00 previstos, conforme apresentado na
Tabela 7.
Tabela 7 - Custo real do projeto Pizzaria do Chico
Atividade
Compra do servidor
Modulo Segurana
Modulo Cadastro
Modulo Pedidos
Durao Data
1 dia
01/06/2012
30 dias
01/06/2010
30 dias
01/07/2010
30 dias
01/08/2010
Custo
R$ 3.000,00
R$ 2.400,00
R$ 4.600,00
R$ 0,00
A curva S nesse cenrio pode ser observada na Figura 14

formando um "S" no grfico.
70
R$ 18.000,00
R$ 16.000,00
R$ 14.000,00
R$ 12.000,00
R$ 10.000,00
VP
R$ 8.000,00
CR
R$ 6.000,00
R$ 4.000,00
R$ 2.000,00
R$ 0,00
01/06/2012
01/07/2012
01/08/2012
Figura 14 - Curva S do projeto Pizzaria do Chico
Ainda nesse cenrio, poderamos realizar uma avaliaes de valor

agregado do projeto conforme pode ser observado na Tabela 8.
71
Por fim importante ressaltar que o gerenciamento de uma
atividade no est restrita ao uso de uma tcnica especfica,
principalmente no assunto monitoramento e controle de projetos a
juno de vises com informaes diferentes pode auxiliar na
efetividade do monitoramento.
2.1.1.7
REALIZAR O CONTROLE DA QUALIDADE

Este processo responsvel por monitorar e registrar os
resultados da execuo das atividades de qualidade para avaliar o

desempenho e recomendar mudanas. importante que a equipe do
projeto conhea a diferena entre alguns termos utilizados nesse
processo (PMI 2008):
Preveno: manter os erros fora do processo;
Inspeo: manter os erros fora do alcance do cliente;
Amostragem de atributos: o resultado est em conformidade ou

no;
Amostragem de variveis: resultado que classificado em uma

escala contnua que mede o grau de conformidade;
Tolerncias: intervalo especfico de resultados aceitveis;
Limites de controle: limites que podem indicar se o processo

est fora de controle.
So vrios os benefcios obtidos pela medio de software,
dados quantitativos podem fornecer informaes precisas quanto s

caractersticas do produto em desenvolvimento, alm de possibilitar
mecanismos adequados de acompanhamento e controle da evoluo do
produto (GARCIA 2006).
72
Especificamente na rea de software podemos citar duas
abordagens existentes na literatura para tratar medio, o GQM (GoalQuestion-Metric) (BASILI 1994) e o PSM (Practical Software &
System Measurement) (DOD 2003).
A abordagem GQM tem como princpio que para uma
organizao medir de maneira eficiente, ela precisa inicialmente
verificar quais objetivos devem ser alcanados. Tendo os objetivos
identificados, ela precisa ento associ-los com os dados que definem
esses objetivos operacionalmente e finalmente prover uma estrutura
para interpretao desses dados em relao aos objetivos (GARCIA
2006). O ponto de partida do GQM comea com o estabelecimento de
uma quantidade de objetivos de melhoria e o refinamento desses
objetivos em um nmero de questes e mtricas conforme apresentado
na Figura 15.
Figura 15 - Paradigma GQM (BASILI, 1994).
73
O PSM tem como objetivo estabelecer um conjunto de prticas,
ferramentas e servios para auxiliar os gerentes de projetos a obter
informaes objetivas sobre os projetos em andamento para que estes
atinjam suas metas de qualidade, prazo e custo (GARCIA 2006). No
PSM estabelecido um processo de medio e a partir disso so
apresentados vrios exemplos de medidas a serem coletadas onde o
gerente de projeto seleciona as medidas que melhor se adaptam a
realidade do projeto. Alm disso, o modelo apresenta indicaes de
como usar essas medidas exemplificando com casos reais (HAUCK
2007).
O PMI (2008) define ferramentas e tcnicas para realizar o
controle de qualidade de projetos entre essas ferramentas, esto as
conhecidas
como
ferramentas
de
qualidade
utilizadas
em
gerenciamento de projetos:
Diagrama de Pareto3: um mtodo de classificao de
informaes para segmentar os itens de maior importncia ou impacto.

Dentro dessa abordagem 80% dos problemas podem ser solucionados
tratando-se 20% da causas. Abaixo na Figura 16 podemos ver um
exemplo desse diagrama onde no eixo horizontal temos as causas dos
problemas dentro do projeto e no eixo vertical esto as incidncias de
problemas originados por essas causa. Na chamada linha acumulada
est sendo mapeada a totalidade dos problemas dentro do projeto.
O termo Diagrama ABC, 80-20, 70-30 tambm pode ser
encontrado em outras literaturas.
74
45
40
35
30
25
20
15
10
5
0
100,00%
50,00%
25,00%
Incidencia
Acumulado
Causa 1
Causa 2
Causa 3
Causa 4
Causa 5
Causa 6
Causa 7
Causa 8
Causa 9
Causa 10
12,50%
Figura 16 - Diagrama de Pareto Exemplo
Diagrama de causa e efeito4: O objetivo desse diagrama
estudar hierarquias de causas potenciais para problemas conhecidos

chegando dessa forma a causa raiz do problema ao continuar a
perguntar por qu? ou como? seguindo uma das linhas. Abaixo na
Figura 17 podemos visualizar um exemplo desse tipo de diagrama.
Tempo
Recurso
Defeito
significativo
Cliente
Ambiente
Figura 17 Diagrama de Causa e Efeito Exemplo
O termo diagrama de Ishikawa ou diagrama de espinha de peixe
tambm pode ser encontrado em outras literaturas
75
Histogramas: utilizado para mostrar a frequncia com que
ocorreu um determinado estado de uma varivel. Podemos visualizar

um exemplo na Figura 18 abaixo.
Figura 18 Histograma Exemplo
Diagrama de disperso: Seu objetivo mostrar a relao
existente entre duas variveis, quanto mais prxima estiverem os pontos

em uma reta longitudinal, mais prxima a relao entre as duas
variveis. O exemplo desse diagrama pode ser visto na Figura 19
abaixo.
Figura 19 - Diagrama de Disperso Exemplo
76
Fluxogramas: Essa tcnica utilizada para determinar etapas do
processo que no esto em conformidade e identificar oportunidades de

melhoria dos processos. O exemplo dessa ferramenta pode ser obtido na
Figura 20 abaixo.
Incio
Processo 1
Processo 3
Sim
Deciso 1
Sim
Processo 2
Deciso 2
No
Processo 4
No
Fim
Figura 20 - Fluxograma Exemplo
Grfico de controle: O grfico de controle tem como objetivo
responder graficamente a pergunte A variao desse processo est

dentro dos limites aceitveis?. Normalmente utilizado para verificar
pontos de disperso fora do padro normal de um processo. Podemos
visualizar esse grfico na Figura 21.
77
Figura 21 - Grfico de Controle Exemplo
Grfico de execuo: Esse grfico semelhante ao grfico de
controle, mas sem as definies de limites. Seu objetivo mostrar a

tendncia de um processo ao longo do tempo. Abaixo na Figura 22
temos um exemplo desse grfico.
Figura 22 - Grfico de Execuo Exemplo
Realizando a analogia ao nosso projeto Pizzaria do Chico,
78
podemos fazer a seguinte referncia ao controle de qualidade.

Lembrando da nossa restrio do projeto, o sistema deve
rodar nos navegadores Internet Explorer, Mozilla e Chrome com o
tempo de resposta de no mximo 3 segundos para cada solicitao.
Realizando o teste de qualidade verificou-se que nas 5 primeiras
telas (Eixo das abscissas (x) da Figura 23), todos os navegadores
atenderam a restrio imposta.
3,5
3
2,5
IE
Mozila
1,5
Chrome
1
0,5
0
0
Figura 23 Grfico de controle do projeto Trocar-pneu
2.1.1.8
REPORTAR O DESEMPENHO
Este processo responsvel por coletar e distribuir indicadores
do projeto obtendo periodicamente dados reais da execuo das

atividades e distribuir essa informao de maneira adequada. Os
indicadores podem ser considerados atributos de produtos de trabalho,
custo, esforo e prazo (SEI 2010). Podemos citar alguns exemplos de
indicadores tpicos para a rea de software (SEI 2010):
79
Cronograma;
Esforo;
Recursos;
Conhecimento e perfil dos participantes;
Atributos dos produtos de trabalho e tarefas.
Cada relatrio de desempenho do projeto precisa ser elaborado

de maneira que atenda as necessidades do pblico ao qual ele se destina.
Investidores precisam de informaes relacionadas aos custos,
programadores precisam de relatrios mais focados em cronograma e
estimativa de atividades por exemplo.
Segundo o PMI (2008), os relatrios mais completos devem
incluir em seu escopo:
Anlise do desempenho anterior;
Situao atual dos riscos e questes;
Trabalho concludo durante o perodo;
Trabalho a ser executado no prximo perodo;
Resumo das mudanas aprovadas no perodo;
Outras informaes relevantes que devem ser revisadas e

analisadas. Isso pode depender do contexto e criticidade de
cada projeto.
Uma das formas mais completas e atualmente utilizadas para
apresentar resultados de medies, e dessa forma reportar o

desempenho do projeto, so os Dashboards (HAUCK 2007).
Um Dashboard uma ferramenta grfica de suporte para
apresentao de medies com o objetivo de demonstrar tendncias e
80
identificar discrepncias para anlise de dados coletados (SELBY
2005). Abaixo na Figura 24, Figura 25 e Figura 26 podemos visualizar
exemplos de dashboards.
Figura 24 Exemplo 1 de Dashboard

Fonte: Selby (2005)

Fonte: IBM (2010)
81

Fonte: Microsoft (2010)
Assim como qualquer relatrio gerencial, existem informaes

que so tratadas de forma diferenciada para cada nvel hierrquico
dentro de uma organizao. Um dashboard para um diretor pode
apresentar informaes sobre o andamento geral do projeto, custos e
recursos, um gerente pode visualizar um dashboard com informaes
somente das tarefas destinadas a sua rea durante um perodo prdefinido e ainda seria possvel um dashboard para o cliente que pode
visualizar o andamento das atividades do projeto.
Referenciando o nosso projeto Pizzaria do Chico, um
dashboard poderia ser bem representado como uma juno dos
vrios indicadores grficos apresentados nos captulos anteriores, em
um lugar nico facilitando dessa forma o acompanhamento do
controle de qualidade, custos, cronograma, etc.
82
2.1.1.9
ADMINISTRAR AS AQUISIES
Este processo responsvel por gerenciar as relaes de
aquisio, monitorar o desempenho do contrato e fazer mudanas ou

correes quando necessrio. O contrato sempre possui no mnimo duas
partes interessadas principais, o fornecedor e o comprador. Ambos
buscam assegurar que as definies previstas nos contratos sejam
seguidas conforme o acordo realizado.
A administrao de aquisies tambm tem um cunho
financeiro que envolve o monitoramento dos pagamentos dos
fornecedores. Alm disso, o processo de administrao de aquisies
analisa e documenta como o fornecedor est se desempenhando ou se
desempenhou com base no contrato e estabelece aes corretivas
quando necessrio (PMI 2008).
Existem algumas ferramentas que so utilizadas dentro do
processo de administrao das aquisies que servem para auxiliar o
trabalho do gerente de projeto ou responsvel pelos contratos em um
projeto (PMI 2008):
Sistema de controle de mudanas no contrato: Essa ferramenta tem

como finalidade definir o processo pelo qual as aquisies podem
ser alteradas. Esse sistema integrado com o sistema de controle de
mudanas;
Anlise de desempenho das aquisies: a avaliao estruturada do

progresso do fornecedor para entregar o escopo e a qualidade do
projeto, dentro dos custos e do cronograma, em comparao com o
contrato. O objetivo da anlise identificar xitos e fracassos do
desempenho, o progresso em relao declarao do trabalho da
aquisio e o no cumprimento do contrato;
83
Inspees de auditoria: Desde que acordada entre as partes,

inspees podem ocorrer durante a execuo do projeto para
verificar a conformidade nos processos de trabalho e nas entregas
do fornecedor;
Relatrios de desempenho: tem como objetivo proporcionar

gerncia uma visibilidade sobre a eficcia com que o fornecedor
est atingindo os objetivos contratuais;
Sistema de pagamento: Os pagamentos ao fornecedor so

processados por um sistema de contas pagar do comprador aps a
certificao de trabalho satisfatrio por uma pessoa autorizada;
Administrao de reivindicaes: As mudanas em um contrato

podem gerar insatisfao de alguma das partes envolvidas, nesse
sentido sero geradas reivindicaes que precisam ser monitoradas
e tratadas adequadamente;
Sistema de gerenciamento de registros: Tem o objetivo de gerenciar

os registros e a documentao do contrato e da aquisio.
O processo de aquisio muita vezes realizado pelo

departamento jurdico ou rea comercial pois frequentemente envolve
aspectos legais para garantir os interesses da organizao.
Novamente nos referenciando ao projeto Pizzaria do Chico,
a administrao de aquisies, nesse contexto est restrita ao
relacionamento com o fornecedor do servidor.
84
2.2 MODELOS DE MELHORIA DE PROCESSOS
O aprimoramento de estudos relacionados a gerenciamento de
projetos vm tornando cada vez mais populares modelos de melhoria de
processos. Nessa sesso do trabalho nos aprofundamos em dois deles, o
PMBOK e CMMI-DEV.
2.2.1 - PMBOK
O PMBOK (Project Management Body of Knowledge) surgiu
em 1987 como uma tentativa do PMI (Project Management Institute) de
documentar e padronizar prticas adotadas em gerenciamento de projeto
de maneira que esse conhecimento seja amplamente reconhecido e
utilizado pela comunidade de projetos.
Segundo o prprio PMI (2008), ele um documento formal que
descreve normas, mtodos, processos e prticas estabelecidas que
contm o conhecimento evoludo a partir de medidas reconhecidas de
profissionais de gerenciamento de projetos.
No podemos considerar o PMBOK como uma metodologia de
desenvolvimento de projetos, pois:
No foi desenvolvido para um contexto especifico de uma rea

de projetos (Lembrando que um projeto de desenvolvimento de
software possui caractersticas muito diferentes de outras
reas);
No apresenta em seu escopo informaes sobre caractersticas

especificas das organizaes;
No apresenta modelos especficos de documentos a serem

preenchidos.
85
A Figura 27 ilustra como o PMBOK e outros fatores contribuem
para a elaborao de produo de uma metodologia de projetos dentro
de uma organizao.
Figura 27 - PMBOK e Metodologia de Desenvolvimento
Conforme visto no captulo anterior, o PMBOK apresenta 5

grupos de processos divididos em 9 reas de conhecimento. A rea de
conhecimento abordada por este trabalho o monitoramento e controle
onde todos os processos que fazem parte dessa rea tambm j foram
descritos no captulo anterior.
86
Convm ainda destacar que o PMBOK foi selecionado como
uma das referncias deste trabalho pelo fato de ser considerado um guia
completo na definio de processos para monitoramento e controle de
projetos (PMI 2008).
2.2.2 - CMMI-DEV
O CMMI (Capability Maturity Model Integration Modelo
Integrado de Maturidade e de Capacidade) um modelo de maturidade
para melhoria de processo, destinado ao desenvolvimento de produtos e
servios, e composto pelas melhorias prticas associadas a atividades de
desenvolvimento e de manuteno que cobrem o ciclo de vida dos
produtos desde a concepo at a entrega e manuteno (SEI 2010).
A histria do CMMI comeou em 1986, quando o SEI
(Software Engineering Institute), iniciou o desenvolvimento de um guia
para melhoria de processos de software, a partir de necessidades do
governo
americano
para
avaliao
de
seus
contratados.
No ano seguinte, a partir de necessidades do Departamento de Defesa

Americano (DoD), o SEI desenvolveu um questionrio preliminar para
avaliao da maturidade do processo de desenvolvimento de software
das empresas. Em 1991, foi entregue comunidade a verso 1.0 do SWCMM. O CMMI surge ento em 2002 como a evoluo das verses do
SW-CMM (SEI 2010).
O CMMI apresentava inicialmente em sua verso 1.1 duas
abordagens diferentes, a representao contnua e a por estgios, para
melhoria de processo que foram unificadas em um nico documento a
partir da verso 1.2. A verso atual do CMMI a 1.3.
87
Estas representaes permitem que a organizao possa tomar
diferentes caminhos para a melhoria de acordo com o seu interesse.
Na representao por estgios, o modelo CMMI possui nveis
de maturidade na sua concepo e contedo. Um nvel de maturidade
contm prticas especficas e genricas para um conjunto predefinido de
reas de processos que melhorem o desempenho global da organizao.
O nvel de maturidade de uma organizao fornece uma maneira de
caracterizar o seu desempenho sendo um patamar definido na melhoria
de processos das organizaes. Cada nvel de maturidade amadurece um
importante subconjunto dos processos da organizao, preparando-o
para passar para o nvel de maturidade seguinte. Os nveis de
maturidade so medidos pela realizao dos objetivos especficos e
genricos associados a cada conjunto predefinido de reas de processo.
Nvel de Maturidade 1: Inicial (Ad-hoc): As organizaes desse

nvel tm processos imprevisveis que so pobremente controlados
e reativos e so caracterizados pela tendncia de sobrecarga de
trabalho, abandonar os seus processos em tempo de crise, e ser
incapaz de repetir seus sucessos. Geralmente no fornece um
ambiente estvel;
Nvel de Maturidade 2: Gerenciado: Os projetos tm garantido que

os processos so planejados e executados de acordo com a poltica
da organizao. O status dos produtos de trabalho so visveis a
gerncia em pontos. Compromissos so estabelecidos entre as
partes interessadas e so revistos, conforme necessrio. Os produtos
de trabalho so controlados adequadamente. Os produtos de
trabalho e servios de satisfazem suas expectativas previstas em
normas e procedimentos;
88
Nvel de Maturidade 3: Definido: Todos os processos do nvel 1 e

2
foram alcanados
e os
processos agora so
melhor
caracterizados, entendidos e descritos em padres, procedimentos,

ferramentas e mtodos. O conjunto de organizao de processos
padro, que a base para o nvel de maturidade 3, estabelecido e
melhorado ao longo do tempo. Estes processos padres so
utilizados para estabelecer a coerncia em toda a organizao.
Uma distino fundamental entre os nveis de maturidade 2 e 3 o
escopo dos padres, descries de processos e procedimentos. No
nvel 2 de maturidade, os padres, descries de processos e
procedimentos podem ser completamente diferente em cada
instncia especfica do processo (por exemplo, em um projeto
especfico). No nvel de maturidade 3, os padres, descries de
processos e procedimentos para um projeto so feitos para definir a
organizao de processos padro para atender um determinado
projeto ou unidade organizacional e, portanto, so mais
consistentes com exceo dos casos pela organizao. Outra
distino importante que no nvel de maturidade 3, os processos
so normalmente descritos de forma mais rigorosa do que no nvel
2 de maturidade. Um processo define claramente o objetivo,
entradas, critrios de entrada, atividades, papis, medidas, medidas
de verificao, sadas e critrios de sada. No nvel de maturidade
3, os processos so geridos de forma mais ativa com a
compreenso das inter-relaes das atividades do processo e
medidas detalhadas do processo, os produtos do seu trabalho, e
seus servios;
89
Nvel de Maturidade 4: Quantitativamente gerenciado / Gerido

quantitativamente: A organizao e projetos estabelecem objetivos
quantitativos para a qualidade e o desempenho do processo e
utilizam-nos como critrios na gesto de projetos. Objetivos
quantitativos so baseados nas necessidades do cliente, os usurios
finais, a organizao e implementao do processo. Qualidade e
desempenho do processo entendido em termos estatsticos, e
administrado ao longo da vida dos projetos. Baselines de
desempenho de processos e modelos podem ser usados para ajudar
a definir a qualidade e os objetivos de desempenho do processo que
ajudam a alcanar objetivos de negcio. Uma distino fundamental
entre os nveis de maturidade 3 e 4 a previsibilidade do
desempenho do processo. No nvel 4, o desempenho dos projetos
selecionados e subprocessos controlado usando tcnicas
estatsticas e quantitativas, e as previses so baseadas, em parte,
em uma anlise estatstica dos dados do processo de granulao
fina;
Nvel de Maturidade 5: Em otimizao: Uma organizao melhora

continuamente seus processos com base em uma anlise
quantitativa dos seus objetivos de negcio e as necessidades de
desempenho. A organizao utiliza uma abordagem quantitativa
para entender a variao inerente ao processo e as causas dos
resultados do processo. O nvel de maturidade 5 foca em melhorar
continuamente o desempenho do processo atravs de melhorias
incrementais e inovadoras de processos e tecnolgicas. A qualidade
da organizao e os objetivos de desempenho do processo so
estabelecidos, continuamente revisados para refletir os objetivos de
90
negcios em mudana e desempenho organizacionais, e utilizados
como critrios na gesto de melhoria de processos. Os efeitos da
melhoria dos processos implantados so medidos atravs de
tcnicas estatsticas e quantitativas e comparados com os objetivos
de desempenho de qualidade e processo. Uma distino
fundamental entre os nveis de maturidade 4 e 5 o foco na gesto
e melhoria do desempenho organizacional. No nvel 4, o foco da
organizao e projetos na compreenso e controle do desempenho e
usar os resultados para gerenciar projetos. No nvel de maturidade
5, a organizao est preocupada com o desempenho global da
organizao com dados coletados de vrios projetos. A anlise dos
dados identifica as falhas ou lacunas no desempenho. Essas lacunas
so usadas para conduzir a melhoria do processo organizacional,
que gera melhoria mensurvel no desempenho.
Abaixo na Figura 28 podemos visualizar como essa

representao relacionada entre seus nveis de maturidade.
Nvel 5
Nvel 4
Nvel 3
Nvel 2
Nvel 1
Figura 28 - Representao por estgios do CMMI
91
A representao contnua permite que uma organizao
selecione uma rea ou grupo de processos e melhore os processos
relacionados. Nessa representao existem metas e prticas de dois
tipos: especficas e genricas. A partir das prticas e metas possvel
classificar o nvel de capacidade de cada rea de processo. Capacidade
pode ser entendido como a habilidade com que determinado processo
alcana o seu objetivo. A capacidade pode ser classificada em nveis de
zero a cinco (SEI 2010):
Nvel de Capacidade 0 - Incompleto: um processo parcialmente

realizado ou no realizado. Pelo menos um dos objetivos
especficos do processo no est satisfeitos;
Nvel de Capacidade 1 - Realizado: um processo realizado satisfaz

todos os objetivos especficos da rea de processo e produz algum
trabalho;
Nvel de Capacidade 2 - Gerenciado: um processo de capacidade

nvel 2 um processo realizado (nvel 1) que tambm planejado e
executado de acordo com polticas pr-definidas. Emprega pessoas
hbeis com os recursos adequados para produzir sadas adequadas,
envolve os stakeholders principais e monitorado, controlado,
revisto e avaliado quanto aderncia sua descrio. A gerncia do
processo relacionada com a realizao de objetivos especficos
estabelecidos para o processo, como custo, cronograma e qualidade;
Nvel de Capacidade 3 - Definido: uma distino fundamental entre

os nveis de capacidade de 2 e 3 incluso dos padres, descries
de processos e procedimentos. No nvel da capacidade de 2, os
padres, descries de processos e procedimentos podem ser
92
completamente diferente em cada instncia especfica do processo.
J no nvel 3 de capacidade, os padres, descries de processos e
procedimentos para um projeto so mais consistentes, com exceo
dos casos permitidos por algum diretriz. Outra distino importante
que no nvel 3 de capacidade os processos so geralmente
descritos com mais rigor do que no nvel de capacidade 2. Nesse
nvel os processos so geridos de forma mais pr-ativa usando uma
compreenso das inter-relaes das atividades do processo e
medidas detalhadas do processo e seus produtos de trabalho.
Abaixo na Figura 29 podemos visualizar como essa representao

relacionada com os outros processos da estrutura.
Figura 29 - Representao contnua do CMMI
Para finalizar, podemos ainda realizar uma comparao dos nveis

de maturidade de cada uma das representaes acima mencionadas que
pode ser visualizada na Tabela 9 abaixo.
93
Tabela 9 - Relao entre as representaes do CMMI
Fonte: SEI ( 2010)
Representao
Continua
Representao por Estgios
Nvel
Nvel 0
Nvel 1
Nveis de Capacidade
Incompleto
Executado
Nveis de Maturidade
N/A
Inicial
Nvel 2
Nvel 3
Gerenciado
Definido
Gerenciado
Definido
Nvel 4
Nvel 5
N/A
N/A
Gerenciado Quantitativamente
Otimizado
Assim como o PMBOK, o CMMI no deve ser entendido

como uma metodologia, pois ele no define como realizar determinado
processo, mas sim o que deve ser feito.
A verso atual do CMMI (verso 1.3) apresenta trs modelos:
a)
CMMI para Desenvolvimento (CMMI-DEV): Voltado aos
processos de desenvolvimento de produtos e servios;

b)
CMMI para Aquisio (CMMI-ACQ): Voltado aos processos
de aquisio e terceirizao de bens e servios;

c)
CMMI para Servios (CMMI-SVC): Voltado aos processos de
empresas prestadoras de servios.

Dentro do modelo CMMI-DEV algumas reas de processos
esto relacionadas gerenciamento de projetos:
Planejamento de Projetos;
Monitoramento e Controle de Projetos;
Gerenciamento de acordo com o Fornecedor;
Gerenciamento Integrado do Projeto;
Gerncia de Riscos.
94
Gerenciamento Quantitativo do Projeto.
Dentre essas reas, esta dissertao trata com maior nfase da

rea sobre Monitoramento e Controle de Projeto.
Segundo o CMMI (2010), o propsito do monitoramento e
controle do projeto (PMC) prover um entendimento sobre o progresso
do projeto de maneira que aes corretivas possam ser tomadas quando
o projeto se desviar significativamente do seu planejamento. As aes
corretivas podem tambm influenciar no plano do projeto, forando
revises e replanejamento. As metas e prticas especificas da rea so:
SG 1 Monitorar o Projeto em Relao ao Plano

SP 1.1 Monitorar os Parmetros de Planejamento do Projeto
SP 1.2 Monitorar os Compromissos
SP 1.3 Monitorar os Riscos do Projeto
SP 1.4 Monitorar o Gerenciamento de Dados
SP 1.5 Monitorar o Envolvimento das partes Interessadas
SP 1.6 Conduzir Revises de Progresso
SP 1.7 Conduzir Revises nos Milestones
SG 2 Gerenciar as aes corretivas at sua concluso

SP 2.1 Analisar Questes
SP 2.2 Tomar Aes Corretivas
SP 2.3 Gerenciar as Aes Corretivas
Assim como o PMBOK, o CMMI-DEV foi selecionado por ser

um modelo completo e tambm adotado por muitas MPEs para
95
avaliao de seus processos (SEI 2012). Apesar do CMMI-DEV no ter
sido projeto pensando no mbito das MPEs, ele utilizado no sentido de
aumentar a competitividade das empresas, tornando-se um diferencial
no mercado (SEI 2012). No Brasil existe a opo de modelos
alternativos como, por exemplo, o MPS.BR (SOFTEX 2012). Mas por
se tratar de um modelo relativamente novo e pouco estvel se
comparado ao CMMI, neste trabalho estamos considerando somente o
CMMI alm de que o MPS.BR um modelo baseado no CMMI-DEV.
2.3 MICRO E PEQUENAS EMPRESAS

Neste tpico est sendo apresentado o cenrio em que as MPE
de software do Brasil esto inseridas para ser possvel criar um processo
que seja aderente a realidade dessas empresas.
Apesar das MPE serem classificadas como empresas de at 19
colaboradores (SEBRAE 2010) a maioria das empresas da rea de
tecnologia possuem at 9 colaboradores (MCT 2010) (SOFTEX 2009).
As empresas desse setor em sua grande maioria desenvolvem
focados
na
gesto
empresarial,
controle
de
vendas,
sistema
administrativos, para acompanhamento de atividades e websites. Os

sistemas desenvolvidos pelas MPEs em sua grande maioria so:
sistemas integrados de gesto empresarial (ERP), para controle de
produo e vendas; sistemas administrativos, para acompanhamento de
atividades e relatrios; e websites (MCTI 2010).
Os integrantes dessas empresas possuem equipes reduzidas,
algumas vezes com contratos temporrios de trabalho ou com perfil de
estgio onde alguns papis dentro da organizao so sobrepostos em
96
uma nica pessoa tornando o processo interno de produo muito
enxuto e com poucos passos. Convm ainda citar que independente do
porte da empresa ou tamanho dos projetos, eles ainda possuem
restries em comum como restries de tempo, solicitaes de
mudanas, e requisitos vagos (CAO 2004).
2.4 MAPEAMENTO PMBOK-CMMI
Um dos primeiros passos tomados na avaliao das ferramentas
definir os critrios que sero utilizados para este fim. Para este
trabalho procuramos abranger mais de um framework como modelo de
referncia harmonizando suas prticas para evitar a redundncia de
tcnicas
na
construo
de
uma
soluo
mais
eficiente
(BALDASSARRE 2011). A base de prticas unificadas entre o

PMBOK e CMMI foi obtida pelo artigo "Best practice fusion of CMMIDEV v1.2 (PP, PMC, SAM) and PMBOK 2008" (WANGENHEIM
2008). As prticas descritas no trabalho foram obtidas com base no
CMMI-DEV e no PMBOK, sendo elas (Tabela 10):
Tabela 10 - Praticas Unificadas
UBP
M1
Nome
Monitor and Control
Project Work
Descrio
Monitorar e controlar o
progresso com respeito aos
parmetros do planejamento
para atingir os objetivos
definidos no plano de
gerenciamento.
M2
Perform Integrated
Change Control
Revisar todas as solicitaes

de mudanas, aprovando e
gerenciando as entregas,
processos, documentos e o
plano do projeto.
97
M3
Verify Scope
Formalizar o aceite das

entregas completas do projeto.
Monitorar o status do projeto,
escopo do produto e gerenciar
as mudanas na linha de base
do escopo.
M4
Monitor and Control

Scope
M5
Monitor and Control

Schedule
Monitorar o status do projeto

para atualizar o progresso e
gerenciar a mudanas na linha
de base do cronograma.
M6
Monitor and Control

Costs
Monitorar o status do projeto

para atualizar o oramento e
gerenciar a linha de base dos
custos.
M7
Monitor and Control

Quality
Monitorar e gravar os
resultados de testes de
qualidade para avaliar o
desempenho e recomendar
mudanas necessrias.
M8
Conduct Progress
Reviews
Periodicamente revisar o
progresso do projeto,
desempenho e duvidas
coletando e distribuindo
informaes, incluindo
relatrios de status,
mensurao do progresso e
previses.
M9
Conduct Milestone
Reviews
Revisar as realizaes e os
resultados do projeto nos
marcos selecionados.
M10
Monitor and Control

Risks
Monitorar os riscos
identificados no plano de
projeto, implementar plano de
respostas aos riscos,
acompanhar os riscos
identificados e identificar
novos.
98
M11
Administer
Procurements
Gerenciar os contratos,
acompanhar a execuo,
selecionar e avaliar
fornecedores e fazer
mudanas e correes quando
necessrio.
Selecionar, monitorar e
analisar os processos
utilizados pelos fornecedores.
M12
Monitor Selected
Supplier Processes
M13
Monitor
Commitments
Monitorar os compromissos
identificados no plano do
projeto
M14
Monitor Data
Management
Monitorar a gesto de dados

do projeto identificados no
projeto.
M15
Monitor Stakeholder
Involvement
Monitorar o envolvimento dos

participantes do projeto
conforme identificado no
plano do projeto.
M16
Analyze Issues
Coletar e analisar os
problemas e determinar as
medidas corretivas necessrias
para resolver os problemas
M17
Take Corrective
Action
Tomar aes corretivas para

as questes identificadas no
projeto.
M18
Manage Corrective
Action
Gerenciar aes corretivas

para o encerramento do
projeto.
Essas prticas foram formadas a partir da juno de todas os

processos descritos no PMBOK e todos as prticas especificas do
CMMI-DEV no mbito de monitoramento e controle. Um ponto
interessante a ser citado que nessa juno existem processos que no
so diretamente mapeados no CMMI-DEV, assim como existem
prticas que no so mapeadas diretamente no PMBOK, no entanto,
99
todas eles foram utilizadas para compor as chamadas UBP (Unified Best
Practice) listadas acima.
2.5 TRABALHOS CORRELATOS
Na busca do estado da arte do tema proposto nessa dissertao
e para situar a contribuio deste trabalho existem correlatos na
literatura que merecem ser citados. Podemos dividir os trabalhos em
dois grupos para facilitar o entendimento de sua relao:
Modelagem de processo:
A dificuldade para as MPE utilizaram os modelos e normas
disponveis seja porque no os conhecem ou porque no conseguem a
produtividade esperada pelo mercado pode ser observada no trabalho
"Uma abordagem de modelagem de processos suportada por um guia de
referncia alinhado ao CMMI-DEV, MPS.BR e ISO/IEC 15504"
(HAUCK 2005). Este trabalho apresenta uma extenso da abordagem
ASPE/MSC introduzindo um guia de referncia de processos, para
monitoramento e controle de projetos, alm de dois estudos de casos da
aplicabilidade desse guia em empresas.
Outro trabalho semelhante a uma das etapas propostas nesse
trabalho "Harmonization of ISOIEC 90012000 and CMMI-DEV"
(BALDASSARRE et al. 2012) o qual apresenta a harmonizao entre
dois modelos de maturidade a ISO/IEC 9001 e o CMMI-DEV. A
harmonizao de modelos uma pratica cada vez mais comum
motivada pelo aumento da competitividade e este trabalho busca
auxiliar uma organizao que j tenha implantando a ISO/IEC 9001 a
identificar quais prticas do CMMI-DEV tambm j foram atendidas.
100
Podemos ainda citar o trabalho "Agile software development
methodology for medium and large projects" (QURESHI 2012) o qual
realizou um trabalho inverso ao nosso, adotando a metodologia gil, que
muito comum em pequenas organizaes, para o contexto de mdios e
grandes projetos. A avaliao do trabalho foi realizada por meio de trs
estudos de caso que abordaram projetos de pequeno, mdio e grande
porte.
Ferramentas para MPE:
Conforme citado anteriormente existe um movimento por parte
do governo federal para o aprimoramento e divulgao de ferramentas
livres que podem ser aplicadas para o contexto das MPE (PSBB 2011).
Esse movimento vm sendo apoiado tambm pelo setor privado
conforme o artigo "How Open Source Tools Can Benefit Industry"
(EBERT 2009) e pelas instituies de ensino, como pode ser observado
no GQS (Grupo de Qualidade de Software) que faz parte do INCoD
(Instituto Nacional de Convergncia Digital). Como parte de trabalhos
de concluso de curso, vrias funcionalidades da ferramenta dotProject
esto sendo evoludas para se tornarem mais alinhadas com os modelos
de gerenciamento de projetos existentes. Podemos citar Wrasse (2012)
que aborda a rea de Planejamento de Recursos Humanos, Pescador
(2012) abordando a rea de encerramento de projetos, Khlkamp (2012)
abordando a rea de planejamento de riscos e Abreu (2011) com o
grupo de processos de Iniciao. Alm dos trabalhos de graduao
acima, foi desenvolvido, como dissertao de mestrado, um modelo
genrico de processos para o planejamento de tempo (GONALVEZ
2012) o qual tambm contempla o aprimoramento da ferramenta.
101
3. SELEO DAS FERRAMENTAS
A pesquisa das ferramentas a serem avaliadas foi realizada no
repositrio web SourceForge (http://sourceforge.net), um dos maiores
sites de aplicaes de cdigo aberto.
Definido o ponto inicial de pesquisa, no dia 08 de junho de
2010 foi realizada uma busca utilizando exatamente a frase "project
management" e no utilizando as palavras "desktop" ou "groupware"
dentro da categoria "Office/Business - Project Management". Ao total a
pesquisa retornou 206 resultados de softwares disponveis para o
download ento foram aplicados critrios de incluso e de excluso para
selecionar as ferramentas.
Critrios de incluso:
Atualizao: no mnimo a partir de 2008 para excluir ferramentas

que no tiveram mais manuteno;
Popularidade:
taxa
de
download
no
mnimo
de
50
downloads/semana dessa forma considerando as mais utilizadas;
Equipe: grupo de desenvolvimento de 4 pessoas para tentar

aumentar a garantia de continuidade do projeto;
Foco: suporte para caractersticas tradicionais de gerenciamento de

projetos.
102
Critrios de excluso:
Tecnologia: sistemas desktop que no oferecem nenhum suporte

para coletar e distribuir informao pela web;
Suporte: suporte para processos como gerenciamento de

configurao, rastreamento de bugs, gerenciamento de mudanas
sem oferecer um suporte devido ao gerenciamento de projetos.
Especificidade: suporte para funes isoladas de gerenciamento de

projeto, como simulao de monte carlo ou funes para clculo
de esforo ou tambm para um contexto especifico.
Metodologia: suporte para mtodos geis, por exemplo SCRUM

(SCRUM 2012).
Utilizando os critrios acima foi possvel reduzir a lista das

206 ferramentas para 48, o critrio "Especificidade" foi o principal
recurso utilizado para excluir possveis candidatas da lista para serem
avaliadas, pois a grande maioria dos softwares so destinados a pontos
especficos do gerenciamento de projetos ou como ferramenta de apoio
para alguma atividade pontual.
Dentre as ferramentas restantes foram aplicados os critrios de
incluso e de excluso, mas agora um pouco mais detalhada para evitar
selecionar ou excluir ferramentas injustamente.
A principio, o objetivo desse trabalho seria identificar as 10
principais ferramentas dentro os critrios listados, mas somente foi
possvel selecionar 5, conforme Tabela 11.
.
103
Tabela 11 - Ferramentas Selecionadas
Ferramenta
ltimo
release
25/11/2009
No.
Downloads
por semana
2252
No. of
Project
members
8
Tipo de
Interface
Web-based
27/01/2010
648
Web-based
23/02/2010
346
Web-based
27/04/2010
135
Commandline, Webbased
12/12/2009
89
22
Web-based
dotProject
project.net
phpCollab
track +
streber
Estas
ferramentas
foram
avaliadas
utilizando
suas
funcionalidades originais, sem considerar plug-ins que proporcionem

funcionalidades adicionais.
O prximo passo foi definir os critrios, Tabela 12, para
avaliao das ferramentas em monitoramento e controle, para essa
atividade foi tomado como base o artigo "Best practice fusion of
CMMI-DEV v1.2 (PP, PMC, SAM) and PMBOK 2008" que faz uma
comparao das prticas empenhadas pelo CMMI-DEV e pelo
PMBOK. Apesar da verso do CMMI-DEV utilizado no artigo ser a
1.2, na nova verso 1.3 do CMMI nada mudou em relao s prticas
de monitoramento e controle, dessa forma o artigo continua valido para
este trabalho.
104
Tabela 12 - Tabela de Processos PMC
CMMI-DEV
v1.3:2010
PMC/ SP 1.1
Monitor
Project
Planning
Parameters
UBP
M1
Description
Monitor and
Control
Project Work
M2
Perform
Integrated
Change
Control
M3
Verify Scope
5.4 Verify Scope
M4
Monitor and
Control
Scope
PMC/ SP 1.1
Monitor
Project
Planning
Parameters
5.5 Control Scope
M5
Monitor and
Control
Schedule
PMC/ SP 1.1
Monitor
Project
Planning
Parameters
6.6 Control Schedule
M6
Monitor and
Control Costs
PMC/ SP 1.1
Monitor
Project
Planning
Parameters
7.3 Control Costs
M7
Monitor and
Control
Quality
M8
Conduct
Progress
Reviews
[REQM]
PMC/SP 1.6
Conduct
Progress
Reviews
PMBOK 4ed:2008
4.4 Monitor and Control
Project Work
4.5 Perform Integrated

Change Control
8.3 Perform Quality

Control
10.5 Report Performance
105
M9
Conduct
Milestone
Reviews
PMC/SP 1.7
Conduct
Milestone
Reviews
M10
Monitor and
Control Risks
PMC/SP 1.3
Monitor
Project Risks

Risks
M11
Administer
Procurements
12.3 Administer
Procurements
M12
Monitor
Selected
Supplier
Processes
SAM/ SP2.3
Evaluate
Selected
Supplier
Work
Products
SAM/SP 2.2
Monitor
Selected
Supplier
Processes
M13
Monitor
Commitments
PMC/SP 1.2
Monitor
Commitments
M14
Monitor Data
Management
PMC/SP 1.4
Monitor Data
Management
M15
Monitor
Stakeholder
Involvement
PMC/SP 1.5
Monitor
Stakeholder
Involvement
10.4 Manage Stakeholder

Expectation
M16
Analyze
Issues
PMC/SP 2.1
Analyze
Issues [CAR]

Project Work
M17
Take
Corrective
Action
PMC/ SP 2.2
Take
Corrective
Action

Change Control
12.3 Administer
Procurements
106
M18
Manage
Corrective
Action
PMC/ SP 2.3
Manage
Corrective
Action

Change Control
Com os critrios definidos foi montada uma tabela de avaliao

dos critrios a serem avaliados, segue abaixo na Tabela 13.
Tabela 13 - Tabela de Avaliao
Grade
Description
No prove nenhum suporte
Oferece suporte bsico, mas as funcionalidades no foram

projetadas para este fim.
**
Oferece suporte bsico e as funcionalidades foram

projetadas para este fim.
***
Oferece suporte completo
A avaliao e comentrios sobre cada uma das ferramentas

seguem nos prximos tpicos.
3.1 FERRAMENTAS SELECIONADAS
As ferramentas relacionadas abaixo foram selecionadas
seguindo os critrios anteriormente definidos sendo que agora so
apresentadas com mais detalhes.
3.1.1 - DOTPROJECT
O dotProject (http://www.dotproject.net/) uma ferramenta
para gerenciamento de projetos distribudo sob a licena GNU-GPL.
Isto significa que seus usurios detm o poder de copi-lo
gratuitamente, fazer sua instalao, executar alteraes para melhor-lo
e at mesmo distribu-lo novamente, desde que a licena GNU-GPL seja
107
mantida.
Apesar
de
ser
desenvolvido
pela
comunidade
de
desenvolvedores, seus fundadores faziam parte da empresa Saki

Computers da Austrlia.
O software tem como base tecnolgica o banco de dados
MySQL (http://www.mysql.com/) ou ADOdb e a linguagem de
programao PHP
podendo rodar em qualquer servidor web que
suporte essas tecnologias. Podemos citar como exemplo a arquitetura

LAMP (Linux, Apache, MySQL e PHP), WAMP (Windows, Apache,
MySQL e PHP) ou WIMP (Windows, IIS, Mysql e PHP).
Lanado em 2000, atualmente o dotProject est na verso 2.1.7
que foi lanada em novembro de 2012. Abaixo na Figura 30 se pode
visualizar uma das telas do sistema.
Apesar de ser a melhor ferramenta qualificada na avaliao a
falta da possibilidade de se definir uma linha de base fez com que
critrios como o M1, M3 e M5 no atingissem a sua pontuao mxima.
Funcionalidades como o frum e upload de arquivos
contriburam para que alguns recursos como o M15, M17, M18 e M19
tivessem alguma pontuao, mas no foram projetados para atender a
prtica avaliada.
108
Figura 30 - DotProject
3.1.2 - PROJECT.NET
Fundada inicialmente em 1999 foi adquirida pela Integrated
Computer Solutions em 2006 e ento lanada a sua verso livre.
Project.net (http://www.project.net/) livre para utilizar porm
a empresa vende os servios como suporte, customizao e manuteno.
Sua licena de uso GPLv3.
O banco de dados que utilizado o Oracle e a aplicao
utiliza qualquer servidor web que suporte Java.
Atualmente sua verso a 9.3 lanada em 10 de maro de
2011. Abaixo na Figura 31 podemos visualizar uma das telas do
sistema.
109
Figura 31 - Project.net
Assim como o dotProject, o Project.net possuem vrios

recursos que podem ser utilizados para monitoramento e controle, mas
no de maneira completa ou focada em monitoramento. A maior
diferena entre os dotProject a possibilidade de definir uma linha de
base e a falta de definio de um custo para as tarefas do projeto.
Esta ferramenta se destacou pela boa usabilidade, suporte de
forma parcial o monitoramento e controle, incluindo o monitoramento
do progresso das atividades e do cronograma do projeto (UBP's M1 e
M5) .
3.1.3 - PHPCOLLAB
O software phpCollab (http://www.phpcollab.com/blog/) tem
suporte para os bancos Microsoft SQL Server, MySQL e PostgreSQL, a
110
linguagem de programao PHP. Podemos citar como exemplo a
arquitetura LAMP (Linux, Apache, MySQL e PHP), WAMP
(Windows, Apache, MySQL e PHP) ou WIMP (Windows, IIS, MySQL
e PHP) que tambm suportada pelo dotProject e PhpCollab.
Atualmente sua verso a 2.5 lanada em 15 de setembro de
sistema.
Figura 32 - PhpCollab
A falta da possibilidade de se definir uma linha de base fez com

que critrios como o M1, M3 e M5 no atingissem a sua pontuao
mxima.
111
Funcionalidades como o lista de discusso e upload de
documentos contriburam para que alguns recursos como o M15, M17,
M18 e M19 tivessem alguma pontuao, mas no foram projetados para
atender a prtica avaliada.
Em relao s outras ferramentas avaliadas, o phpCollab
apresentou um bom suporte ao monitoramento e controle das atividades
do projeto (UBP's M1, M5), mas ainda sim de maneira parcial
3.1.4 - TRACK+
Track+
(http://www.trackplus.com/)
um
software
de
gerenciamento de projeto desenvolvido e mantido pela Steinbeis

Transfer Center Software Quality System (STC SQS). Apesar de ser um
software distribudo sob a licena GPL a empresa fornece treinamento,
customizao e servios de consultoria em torno do produto.
O software tem suporte para os bancos Firebird/InterBase, IBM
DB2, Microsoft SQL Server, MySQL e PostgreSQL e Oracle, a
linguagem de programao Java.
Atualmente sua verso a 3.8.1 lanada em 12 de janeiro de
sistema.
112
Figura 33 - Track
A ferramenta Track+ apresentou diversos pontos negativos, por

exemplo, no apresentou recursos significativos para realizar quaisquer
atividades definidas nas UBP's.
3.1.5 - STREBBER
O software Strebber (http://www.streber-pm.org/) tem como
base tecnolgica o banco de dados
MySQL e a linguagem de
programao PHP, assim como o dotProject e o PhpCollab, podendo

rodar em qualquer servidor web que suporte essas tecnologias. Podemos
citar como exemplo a arquitetura LAMP (Linux, Apache, MySQL e
PHP), WAMP (Windows, Apache, MySQL e PHP) ou WIMP
(Windows, IIS, MySQL e PHP).
113
Atualmente sua verso a 0.092 lanada em 12 de dezembro
de 2009. Abaixo na
Figura 34 possvel visualizar uma das telas
do sistema.
Figura 34 - Strebber
A falta de relatrios foi um dos fatores que influenciou na baixa

classificao desta ferramenta, mas tambm podemos citar a
inexistncia de baseline e grfico de Gantt.
Assim como a ferramenta Track+, no apresentou recursos
significativos para que se realizar quaisquer atividades definidas nas
UBP's.
114
3.2 RESULTADO DA AVALIAO
O monitoramento e controle suportado pelas ferramentas
principalmente em relao ao cronograma, atravs da anlise do
andamento da execuo das atividades em relao ao planejado.
Tambm suportado pela maioria das ferramentas a definio de aes
corretivas e seu gerenciamento, tipicamente no possvel controlar e
monitorar stakeholders, fornecedores ou riscos. A coleta de dados para
o monitoramento e controle aparentemente dificultada, pois
necessrio navegar por diversas telas at encontrar o local de edio
onde algumas vezes no sem tem histrico do trabalho realizado. Ficou
evidente a falta de foco dos relatrios fornecidos, pois muitas vezes as
ferramentas oferecem diversos relatrios que somente trazem
informaes relevantes se combinados uns com os outros, dificultando a
anlise das informaes para a tomada de deciso pelo gerente de
projeto. Aparentemente nenhuma das ferramenta analisadas utiliza
tcnicas avanadas para auxiliar no monitoramento e controle, como por
exemplo valor agregado.
O resultado final da avaliao das ferramentas apresentado na
Tabela 14 de forma consolidada.
Tabela 14 - Resultado da Avaliao das Ferramentas
dotProject
projectNet
phpCollab
Track+
Streber
UBP
M1
Description
Monitor and Control Project Work
**
**
**
M2
Perform Integrated Change Control
M3
Verify Scope
**
**
**
115
M4
Monitor and Control Scope
M5
Monitor and Control Schedule
**
**
**
M6
Monitor and Control Costs
M7
Monitor and Control Quality
M8
Conduct Progress Reviews
M9
Conduct Milestone Reviews
M10
Monitor and Control Risks
M11
Administer Procurements
M13
Monitor Commitments
M14
Monitor Data Management
M15
Monitor Stakeholder Involvement
M16
Analyze Issues
M17
Take Corrective Action
M18
Manage Corrective Action
Conforme pode ser observado nenhuma das ferramentas atingiu

a pontuao mxima adotada, alm disso as principais funcionalidades
pontuadas tem relao ao cronograma e escopo do projeto.
116
4. MODELO GENRICO DE PROCESSO PARA PMC
Neste captulo do trabalho ser apresentada a elaborao do
modelo genrico de processo para monitoramento e controle para MPE,
alinhado ao PMBOK e CMMI, independente de ferramentas.
Aps essa definio sero apresentados os requisitos, casos de
uso, prottipos de tela e por fim as melhorias implementadas na
ferramenta dotProject.
O modelo genrico de processos visa atender as caractersticas
das MPE de software do Brasil.
4.1 PROCESSO DE REFERNCIA
Monitorar e controlar projetos tm como objetivo assegurar que
as atividades do projeto estejam
sendo executados e entregues
conforme o seu planejamento. No mbito das MPE no simples,

principalmente pela falta de organizao e imaturidade das organizaes
(WANGENHEIM 2009).
Adequar os modelos de referncia para essa realidade tambm
pode ser uma tarefa difcil, pois problemas como disponibilidade de
recurso, tempo e oramento podem influenciar na aderncia fiel dos
modelos a realidade das empresas.
A abordagem ASPE/MSC (Approach for Software Process
Establishment in Micro and Small Companies) surgiu para estabelecer
uma metodologia para a modelagem de processos voltada s
caractersticas e limitaes de MPE de software. A aplicao dessa
abordagem teve resultados positivos em diversas aplicaes dentro do
contexto das MPE (WANGENHEIM 2006; THIRY et al, 2006;
117
HAUCK 2005) e foi aprimorado com a criao de um guia de referncia
para o processo de PMC (HAUCK 2007).
Abaixo na Figura 35 temos o processo de monitoramento e
controle definido para a implementao do guia em alto nvel.
Figura 35 - Processo de Referncia para Monitoramento e Controle

em alto nvel (HAUCK, 2007)
Tomando como base o processo acima, pode-se visualizar 3

passos para o monitoramento e 3 passos para o controle de projetos.
118
Monitorar
Passo 1 - Coleta de dados
Passo 2 - Analisar e Visualizar
Passo 3 - Interpretar e Comunicar

Controlar
Passo 4 - Verificar Questes
Passo 5 - Gerenciar Aes Corretivas
Passo 6 - Replanejar
Na Figura 35 nota-se que todos os processos esto sempre em

conformidade com a linha de base de planejamento pois esta uma
premissa para se realizar o monitoramento e controle, no possvel
monitorar o que no foi planejado. Os passos descritos a seguir so
referentes o monitoramento de projetos.
4.1.1 - PASSO 1 - COLETA DE DADOS
O monitoramento de um projeto feito medindo quanto o
planejamento se aproxima da execuo das atividades e os fatores que
podem alterar o que foi planejado, porm coletar os dados pode ser um
processo mais complexo do que planejar as atividades do projeto.
Segundo Sommerville (2007), existem 3 classes de dados que
podem ser coletadas:
O tempo para que um processo especfico possa ser concludo;
Os recursos necessrios para um processo especfico;
O nmero de ocorrncias de um evento especfico.
119
Essas mtricas coletadas durante o projeto servem como base
para a anlise de quase todas as informaes do projeto pois delas so
derivadas outras informaes que so utilizadas em anlises posteriores.
Entre os problemas que podemos encontrar para coletar dados
no monitoramento, podemos citar:
Objetivo
Inexistncia de processos para sua realidade;
Falta de planejamento para a atividade que sero executadas;
Falta de ferramentas adequadas;
Subjetivo
Falta de comprometimento da equipe;
Falta de experincia da equipe;

Os dados a serem coletados em um projeto podem variar a
depender da estrutura do projeto e da prpria organizao. Na Tabela 15

seguem exemplos de dados que podem ser coletados.
Tabela 15 - Exemplo de dados a serem coletados
Categoria
Medida
1. Custo do
projeto
Custo
Custo atual
Custo orado
Variao do custo
2. Custo de
Custo total com empregados,
recursos humanos contrataes e consultorias
3. Custo de
investimento
Esforo
Exemplo de Dados Coletados
4. Esforo do
projeto
Custo associados construo de

componentes para reutilizao em
outros projetos semelhantes
Esforo atual
120
Durao
Produtividade
5. Esforo
gerencial
6. Durao do
projeto
7. Fator de
produtividade
Esforo do gerente de projetos

Durao real do projeto
Desvio do cronograma em relao
ao seu planejamento
Desvio do custo em relao ao
seu planejamento
4.1.2 - PASSO 2 - ANALISAR E VISUALIZAR

Tendo definidos os dados que sero coletados, o prximo passo
a definio das medidas e indicadores que sero coletadas para a
elaborao dos relatrios.
Acima na Tabela 15 j temos as medidas sugeridas para serem
analisadas divididas por categorias.
Para melhorar o entendimento das medidas e sua aplicabilidade
foram elaborados exemplos disponibilizados no apndice 9.1-Exemplos
de Medidas.
4.1.3 - PASSO 3 - INTERPRETAR E COMUNICAR
No monitoramento e controle de projetos uma das reas de
conhecimento abordada a de gerenciamento das comunicaes. Esse
relacionamento pode ser exemplificado por meio de relatrios de
desempenho e o gerenciamento das partes interessadas (CHAVES
2007).
O processo de comunicar informaes em um projeto pode
ocorre de vrias formas, uma delas por meio de reunies peridicas.
Segundo Chaves (2007 ), reunies so importantes quando:
121
Precisa-se de uma resposta rpida de vrias pessoas sobre um

determinado assunto;
Existem problemas ou questes a serem esclarecidas,

compartilhadas, expostas ou resolvidas com os demais
participantes;
Se quiser envolver o grupo na tomada de deciso, reconciliao

de situaes de conflito ou na busca de consenso;
Se desejar trocar informaes e experincias com o grupo;
Para analisar, avaliar, e resolver problemas que envolvem

pessoas de reas ou empresas distintas;
Existem exigncias legais a serem implantadas.
O momento em que ocorrem as reunies est associado ao ciclo

de vida do projeto, as mais importantes so:
Reunio de partida;
Reunies de acompanhamento (mudanas, aes corretivas e

preventivas, problemas);
Reunies para registro de lies aprendidas;
Reunio de encerramento ou de entrega do projeto.
As reunies de acompanhamento fornecem aos interessados

informaes sobre como os recursos esto sendo aplicados para se
atingir os objetivos do projeto. Informaes sobre o escopo prazo, custo
e qualidade normalmente esto includos nesse tipo de relatrio, abaixo
temos alguns exemplo (DINSMORE, 2005):
122
Informaes do andamento: este tipo de relatrio fornece o

status do projeto atual descrevendo em qual estgio o projeto se
encontra em relao ao cronograma, custos e pendncias que
esto afetando o projeto.
Informaes sobre o progresso: este tipo de relatrio fornece

informaes sobre o trabalho que j foi realizado com os
percentuais das atividades concludas e das que esto em
andamento.
Informaes relativas previso (forecast): este tipo de

relatrio faz uma previso do progresso das atividades futuras
baseando-se nas atividades presentes por meio de mecanismos
de anlise matemtica como, por exemplo, anlise de regresso.
A periodicidade dessas reunies pode variar de projeto para

projetos, isso pode depender dos participantes, disponibilidade,
criticidade e durao. Por exemplo, um projeto de duas pessoas com
durao de 5 dias no tem a mesma frequncia de reunies que um
projeto com 30 pessoas e durao de 1 ano.
Outra variao de reunio que podemos citar com relao aos
seus participantes. Dentro de um projeto, custos pode no ser uma
informao que a equipe do projeto deva ter acesso, assim como no
seria importante convocar o cliente ou a gerncia snior para discutir a
problemas inerentes ao dia-dia do trabalho de desenvolvimento.
Uma maneira eficiente de organizar as informaes mais
importantes para o gerenciamento do projeto por meio de relatrios de
desempenho. O objetivo desse tipo de relatrio mapear no tempo as
123
variveis mais importantes do projeto e fornecer informaes sobre a
evoluo dos trabalhos realizados. A qualidade do relatrio est
diretamente associado a finalidade pela qual ele foi criado, ou seja,
quanto mais explicita a sua finalidade melhor elaborado o relatrio vai
estar (CHAVES 2007).
Os relatrios voltados para monitoramento e controle de
projetos tm como finalidade responder perguntas relevantes no
controle de projetos (CHAVES 2007):
Onde estamos em relao ao custo que foi orado para o

projeto;
Onde estamos com relao data planejada de concluso do

projeto;
Onde estamos em relao ao trabalho que j deveria estar

concludo.
As informaes acima so embasadas em 3 categorias,

consideradas a base da "trplice restrio" (PMI 2008) em
gerenciamento de projetos, mas podemos ainda incluir outras categorias
como por exemplo:
Qual o esforo por unidade de trabalho realizado;
Qual o nmero de problemas encontrados nas entregas

realizadas;
Qual o nvel de satisfao do cliente com as entregas e

com relao a equipe;
Qual o valor do projeto em relao ao investimento

realizado.
124
As categorias sugeridas como exemplo tambm podem ser
visualizadas na Tabela 15.
Os passos a seguir so referentes ao controle de projetos.
4.1.4 - PASSO 4 - VERIFICAR QUESTES
Este passo responsvel por identificar e registrar questes que
podem resultar em desvios que o projeto est sofrendo. O registro de
informaes pode ser realizados em qualquer momento durante o
projeto e deve ser discutidos durante as reunies.
4.1.5 - PASSO 5 - GERENCIAR AES CORRETIVAS
Durante as reunies do projeto, todas as questes anteriormente
levantadas devem ser revisadas e discutidas. Questes relevantes devem
ser tratadas e monitoradas at o seu encerramento. A relevncia de uma
questo deve vir da avaliao do gerente de projetos juntamente com os
envolvidos.
4.1.6 - PASSO 6 - REPLANEJAR
Caso alguma ao corretiva tenha influncia no que foi
anteriormente planejado, ser necessrio replanejar o projeto gerando
uma nova linha de base para os dados novos. A atividade de
replanejamento pode incluir aes como (HAUCK 2007):
revisar Introduo do Plano de Projeto;
revisar o Contexto do Projeto;
revisar escopo do Projeto;
125
redefinir a EAP;
atualizar Estimativas;
definir a Alocao de Recursos;
definir o Cronograma de Execuo;
definir o Plano de Riscos;
definir o Plano de Gerncia de Dados;
definir o Oramento;
atualizar a linha de base do Plano de Projeto.
4.2 DEFINIO DO META MODELO

Para iniciar a definio do modelo proposto por este trabalho,
foi definido o SPEM - Software Process Engineering Metamodel
Specification, proposto pela OMG (2007) - Object Management Group
para a descrio do processos utilizando uma linguagem suportada pela
UML Unified Modeling Language. A OMG define quadro camadas de
abstrao, conforme Figura 36 abaixo:
126
Figura 36 - Nveis de Modelagem na arquitetura de quatro camadas da
UML
A camada M0 representa os processos reais que so utilizados

internamente nas organizaes e esto adaptados pra o mundo real. A
camada M1 representa um nvel mais alto de abstrao onde so
definidos os modelos de processos. J no nvel M2, onde se encontra o
SPEM, esto definidos as meta-especificaes que so base para a
definio dos modelos de processo. E no nvel mais alto M3 esto as
especificaes que definem como devem ser documentados os demais
nveis (HAUCK 2007).
A nomenclatura utilizada pelo SPEM segue alguns padres
conforme pode ser observado na Tabela 16 Principais esteretipos
SPEM:
Tabela 16 Principais esteretipos SPEM
Esteretipo
Meta-/Superclasse
TaskDefinition
MethodContentElement,
WorkDefinition
RoleDefinition
MethodContent Element / Class
Artifact
WorkProductKind
ToolDefinition
MethodContent Element / Class
TeamProfile
BreakdownElement / Classifier
Fonte: SPEM verso 2.0 (OMG 2008), adaptado.
cone
127
4.3 DEFINIO DO MODELO GENRICO DE PROCESSO
A prxima etapa na construo de uma soluo que atenda as
necessidades de processos e atividades descritas nas UBP's a
formulao de um modelo genrico de processo para ser agregado ao
ambiente de MPE que pretendem realizar o monitoramento de seus
projetos. Pela estrutura enxuta das organizaes que se enquadram
nessa modalidade, em sua maioria tendo no mximo 5 funcionrios
(MCTI 2010), a elaborao do modelo foi realizada com a preocupao
de no criar passos excessivamente longos e otimizar ao mximo as
etapas pois caso contrrio pode se tornar um empecilho no processo
produtivo.
O modelo genrico de monitoramento proposto est dividido
em 6 etapas (Figura 37):
MC01 - Planejar a Monitorao;
MC02 - Coletar Dados;
MC03 - Analisar os Dados;
MC04 - Realizar Reunio de Monitorao Equipe;
MC05 - Realizar Reunio de Monitorao com Gerncia

Snior;
MC06 - Revisar Plano de Projeto.
128
Figura 37 - Modelo de Monitoramento Proposto
Pode-se notar que os passos definidos esto alinhados com a

abordagem ASPE/MSC conforme
Tabela 17 abaixo.
Tabela 17 - UBP - Mapeamento Modelo vs ASPE
Etapas do Modelo Genrico de

Processo
MC01 - Planejar a Monitorao

MC02 - Coletar Dados
MC03 - Analisar os Dados
Etapas ASPE/MSC
Passo 6 - Replanejar (Planejar)

Passo 1 - Coleta de dados
Passo 2 - Analisar e Visualizar
129
MC04 - Realizar Reunio de
Monitorao Equipe

MC05 - Realizar Reunio de

Monitorao com Gerncia Snior
MC06 - Revisar Plano de Projeto

Passo 6 - Replanejar
Abaixo segue uma descrio mais detalhadas sobre cada um dos

processos e os casos de uso que o compem.
4.3.1 - MC01 - PLANEJAR A MONITORAO
Processo responsvel por definir quais so as informaes
sobre o andamento do projeto que sero analisadas. Essas informaes
podem variar de projeto para projeto em virtude de fatores como
tamanho do projeto, criticidade, recursos, etc.
Entrada
Plano de projeto
Sada
Plano de monitoramento e controle
Mtodos, Tcnicas e Ferramentas

Opinio tcnica especializada
Responsvel
Gerente do Projeto
Papis Envolvidos
Gerente de Projeto
Representante do Cliente (quando possvel)
Descrio
130
1. O gerente de projetos analisa o plano de projeto e define
quais dados devem ser obtidos durante o projeto para que seja
possvel monitorar os itens definidos no plano de projeto.
2. O gerente de projetos atualiza o plano de monitoramento e
controle e salva o documento para divulgar a informao para
os demais integrantes do projeto.
Periodicidade
No incio do projeto e quando ocorrerem mudanas no
planejamento
Esforo Tpico
Depende do tamanho do projeto.
4.3.2 - MC02 - COLETAR DADOS

Este processo responsvel por coletar as informaes base
para o monitoramento. De modo geral, a equipe do projeto deve
apontar, periodicamente, a evoluo do trabalho realizado em cada uma
das tarefas designadas, informando horas trabalhadas e grau de
completude das atividades. Lembrando que todos os itens do plano de
monitoramento e controle deve ser observados e devidamente
apontados.
Entrada
Plano de monitoramento e controle do projeto
Sada
Dados coletados de monitoramento e controle devidamente
apontados
131
Ferramenta para gerenciamento de projetos
Opinio tcnica especializada
Responsvel
Equipe do Projeto
Papis Envolvidos
Equipe do Projeto
Descrio
1. Ao final do expediente o integrante da equipe do projeto
aponta as horas consumidas em cada uma das tarefas realizadas
no dia na ferramenta de gerenciamento de projetos.
Periodicidade
Diariamente ao final do experiente.
Esforo Tpico
10 minutos
4.3.3 - MC03 - ANALISAR OS DADOS

O processo de anlise dos dados consiste em obter o
planejamento do projeto para confrontar com o estado atual da evoluo
das atividades. A partir dessas informaes sero elaborados relatrios
para a gerncia e para a equipe do projeto informando desvios
significantes e aes corretivas que porventura possam existir.
Entrada
Apontamento dos dados coletados
Sada
132
Levantamento de informaes relevantes para as reunies de
status do projeto

Anlise de valor agregado
Responsvel
Gerente do Projeto
Papis Envolvidos
Gerente de Projetos
Descrio
1. O gerente de projetos verifica os itens a serem analisados que
foram definidos no plano de monitoramento e controle do
projeto;
2. O gerente de projetos obtm os dados apontados pelos
integrantes da equipe na ferramenta de gerenciamento de
projetos;
3. O gerente de projetos acessa o sistema para verificar:
Anlise de valor agregado com base no tempo e custo,
ndice de desempenho,
Atividades concludas,
Atividades no iniciadas,
Atividades em andamento,
Atividades atrasadas,
Riscos,
Aes corretivas.
Periodicidade
133
Seguir o que for definido inicialmente no plano do projeto
Esforo Tpico
Depende do tamanho do projeto.
4.3.4 - MC04 - REALIZAR REUNIO DE MONITORAO

EQUIPE
Este processo definido para que as informaes de andamento
do projeto sejam apresentadas para a equipe e ela possa perceber o
andamento do projeto, sugerir alteraes e auxiliar para que o projeto
chegue a sua concluso satisfatoriamente.
Entrada
Informaes de monitoramento do projeto
Sada
Ata de reunio com a equipe
Lista de Aes Corretivas

Responsvel
Gerente do Projeto
Papis Envolvidos
Gerente de Projetos
Equipe do Projeto
Descrio
1. O gerente de projetos inicia a reunio com a equipe do
projeto;
134
2. O gerente de projeto apresenta as informaes sobre o
monitoramento do projeto (tempo, escopo, qualidade);
3. O gerente de projetos apresenta as aes corretivas que
devem ser realizadas no projeto, caso exista;
4. A equipe do projeto junto com o gerente discute,
complementa e atualiza a lista de aes corretivas;
5. O gerente de projetos apresenta itens pendentes da ltima
reunio, caso exista;
6. A equipe do projeto junto com o gerente discute, os itens da
ltima reunio.
Periodicidade
Esforo Tpico
1-2 horas.
4.3.5 - MC05 - REALIZAR REUNIO DE MONITORAO

COM GERNCIA SNIOR
Este processo definido para que as informaes de andamento
do projeto sejam apresentadas para a gerncia snior e com isso
medidas a serem tomadas possam ser definidas e aprovadas.
Entrada
Informaes de monitoramento do projeto
Ata de reunio com a equipe
Sada
Ata de reunio
135
Responsvel
Gerente do Projeto
Papis Envolvidos
Gerente de Projetos
Gerncia Snior
Descrio
1. O gerente de projetos inicia a reunio com a gerncia snior;
2. O gerente de projeto apresenta as informaes sobre o
andamento do projeto em relao ao tempo, custo, escopo,
riscos, qualidade;
3. O gerente de projetos apresenta as aes corretivas que
devem ser realizadas no projeto, caso exista;
4. A gerncia snior junto com o gerente discute, complementa
e atualiza a lista de aes corretivas;
5. O gerente de projetos apresenta itens pendentes da ltima
reunio, caso exista;
6. A equipe do projeto junto com o gerente discute, os itens da
ltima reunio.
Periodicidade
Esforo Tpico
1-2 horas.
136
4.3.6 - MC06 - REVISAR PLANO DE PROJETO
Este processo responsvel por realizar alterao no plano
original do projeto, quando necessrio, de maneira que o fluxo das
atividades e um acompanhamento mais eficiente possam ser realizado
Entrada
Ata de reunio
Sada

Responsvel
Gerente do Projeto
Papis Envolvidos
Gerente de Projetos
Descrio
1. Caso existam alteraes significativas o gerente de projetos
deve atualizar a documentao de monitoramento e controle
com as definies tomadas junto com a equipe e com a gerncia
snior.
Periodicidade
Sempre que alteraes forem identificadas aps a reunio de
status com a gerncia snior.
Esforo Tpico
1-2 horas.
137
5. APRIMORAMENTO DA FERRAMENTA
Com base nos captulos anteriores foi realizada uma avaliao
do dotProject a fim de identificar qual o trabalho necessrio para
aumentar o seu grau de alinhamento aos modelos e normas apresentados
anteriormente com o foco em monitoramento e controle de projetos.
A ferramenta dotProject foi eleita para ser aprimorada com base
em 2 fatores. Primeiramente ela foi uma das melhores qualificadas na
avaliao de aderncia aos processos de monitoramento e controle. Sua
diferena em relao a ferramenta Project.Net que esta no permite
que melhorias sejam realizadas e disponibilizadas para a comunidade. O
segundo fator que j existe um movimento da comunidade e do
prprio governo federal que vm tomando o dotProject base para
produo de ferramentas de gerenciamento de projetos, podemos tomar
como exemplo o GP-Web (PSBB 2011).
O resultado desse trabalho de avaliao pode ser observado na
Tabela 18, onde a ltima coluna refere-se a existncia ou no de uma
funcionalidade de suporte na ferramenta dotProject.
Tabela 18 - Requisitos Funcionais
U
UBP
. Requisito Funcional
Descrio
N. RF
O sistema deve definir

atividades do projeto.
O sistema deve definir
linha de base para o
projeto.
O sistema deve apontar

horas trabalhadas em cada
atividade.
1
M1
Monitor and
Control Project
Work
(RF)
dotProject
v2.1.6
Existe
No Existe
Existe
138
4
M2
M3
Perform
Integrated
Change
Control
Verify Scope
6
M4
M6
Monitor and
Control
Schedule
O sistema deve gerenciar

solicitao de mudanas
de escopo do projeto e/ou
aes corretivas.
O sistema deve realizar as
entregas de maneira
formal pelo sistema
contendo o escopo
entregue.
Existe
No Existe
No Existe
O sistema deve apresentar

as atividades do projeto
identificando as
concludas e as pendentes
o grfico de Gantt do
projeto identificando as
tarefas completas e
incompletas em relao a
data atual

informao sobre o
desempenho do
CRONOGRAMA do
projeto pela anlise de
valor agregado
No Existe
10

informaes sobre o
desempenho do CUSTO
do projeto pela anlise de
valor agregado
No Existe
Monitor and
Control Scope
7
M5
O sistema deve exibir o

acompanhamento do
progresso do trabalho
realizado
Monitor and
Control Costs
Existe
Existe
139
M7
O sistema deve cadastrar

no conformidades de
atividades realizadas no
projeto
Monitor and
Control Quality
No Existe
11

informaes
sobre
o
desempenho do controle
de qualidade
No Existe
12
O sistema deve cadastrar

atas de reunio
No Existe
Conduct
Milestone
Reviews
13
O sistema deve emitir um

relatrio de entregas por
milestones
No Existe
M10
Monitor and
Control Risks
14
O sistema deve monitorar

riscos
No Existe
M11
Administer
Procurements
15
O sistema deve arquivar

contratos derivados do
projeto
Existe
M12
Monitor
Selected
Supplier
Processes
M8
M9
Conduct
Progress
Reviews
M13
Monitor
Commitments
M14
Monitor Data
Management
M15
Monitor
Stakeholder
Involvement
16
17
M16
M17
Existe
No Existe
19

os dados do projeto.
a matriz de
responsabilidades do
projeto
20

aes corretivas do projeto No Existe
21
O sistema deve registrar

aes corretivas do projeto No Existe
18
Analyze Issues
Take
Corrective
O sistema deve arquivar

contratos de fornecedores
do projeto
dashboard com as
principais informaes do
projeto
No Existe
No Existe
140
Action
M18
Manage
Corrective
Action
22

aes corretivas tomadas
no projeto
No Existe
Podemos notar que os requisitos tiveram o seu embasamento

nas UBP's. Cada um dos requisitos pode ser atendido por um ou mais
casos de uso.
Conforme definido anteriormente, a ferramenta a ser utilizada
neste trabalho o dotProject, portanto, podemos ainda listar alguns
requisitos no funcionais para este trabalho, conforme Tabela 19 abaixo.
Tabela 19 - Requisitos No Funcionais
N. RNF
1
2
3
Requisitos No Funcionais (RNF)

O sistema ser desenvolvido sobre a plataforma do
dotProject
A implementao deve respeitar o framework de
desenvolvimento da ferramenta para posteriormente ser
integrado e disponibilizado no site do produto
Funcionalidades referentes a outros grupos de processo no
sero implementados
Funcionalidades j existentes no produto devem ser
respeitadas e somente alteradas caso no torne invlida a
funcionalidade original.
5.1 CASOS DE USO

Com base nos requisitos levantados no tpico anterior, foram
definidos os casos de uso que servem como base para o alinhamento da
ferramenta em direo ao atendimento das prticas definidas nas UBP's.
141
Abaixo na Figura 38 podemos visualizar todos eles que sero
detalhados posteriormente.
Figura 38- Casos de uso para dotProject
Para melhorar o entendimento sobre mapeamento dos casos de

uso com os requisitos levantados, foi construda a Tabela 20 que mostra
a relao entre os requisitos funcionais e o caso de uso que dever
fornecer o suporte necessrio.
Tabela 20 - Relao Caso de Uso vs Requisitos
N.
RF
1
2
3
4
Requisito Funcional (RF)

O sistema deve definir atividades do
projeto.
O sistema deve definir linha de base para
o projeto.
O sistema deve apontar horas trabalhadas
em cada atividade.
O sistema deve exibir o acompanhamento
do progresso do trabalho realizado
Caso de Uso
UC01 - Registrar Linha
de Base Projeto
-
142
UC02 - Registrar Aes

O sistema deve registrar solicitao de
Corretivas
mudanas de escopo do projeto e/ou aes UC03 - Registrar Ata de
corretivas.
Reunio
O sistema deve realizar as entregas de
maneira formal pelo sistema contendo o
escopo entregue.
O sistema deve apresentar as atividades
do projeto identificando as concludas e as
pendentes
O sistema deve apresentar o grfico de
Gantt do projeto identificando as tarefas
completas e incompletas em relao a
data atual
O sistema deve apresentar informao
sobre o desempenho do CRONOGRAMA
do projeto pela anlise de valor agregado
UC05 - Registrar Ata de

Entrega
UC07 - Visualizar
Monitoramento Tempo
UC13 - Registrar Custo
de Recursos do Projeto
UC08 - Visualizar
Monitoramento de Custo
10
O sistema deve apresentar informaes

sobre o desempenho do CUSTO do
projeto pela anlise de valor agregado
11
O sistema deve cadastrar no

UC09 - Registrar no
conformidades de atividades realizadas no Conformidade de
projeto
Qualidade
12
O sistema deve apresentar informaes

sobre o desempenho do controle de
qualidade
13
O sistema deve cadastrar atas de reunio
14
15
UC10 - Visualizar
Monitoramento
Qualidade
Monitoramento
Entrega
Status Report
O sistema deve disponibilizar um relatrio UC05 - Registrar Ata de

de entregas por milestones
Entrega
Desenvolvido pela
O sistema deve monitorar riscos
equipe GQS
143
(KHLKAMP, 2012)
16
O sistema deve arquivar contratos

derivados do projeto
17
O sistema deve arquivar contratos de

fornecedores do projeto
18
O sistema deve apresentar dashboard com UC11 - Relatrio de

as principais informaes do projeto
Projeto Gerencia Snior
19
O sistema deve cadastrar o plano do

projeto.
20
O sistema deve monitorar a matriz de

responsabilidades do projeto
UC12 - Registrar Matriz

de Responsabilidades
21
O sistema deve cadastrar solicitaes de

mudana do projeto

Corretivas
O sistema deve monitorar aes corretivas

do projeto
O sistema deve gerenciar aes corretivas
tomadas no projeto

Corretivas
Corretivas
22
23
importante ressaltar que o dotProject um software que

possui um mdulo central com um conjunto de funcionalidades padro
para o sistema. Todas as funcionalidades projetadas nesse trabalho,
visam completar o suporte da ferramenta. Somente foram elaborados
casos de uso para funcionalidades complementares, no caso onde j
existe a funcionalidade no sistema no foram feitas alteraes. No item
9.2 deste trabalho apresentado o detalhamento sobre cada um dos
casos de uso.
O trabalho de implementao dos casos de uso foi realizado
pelo autor do trabalho com auxlio de um programador PHP, o qual
realizou a implementao de alguns dos casos de uso descritos no
trabalho.
144
6. AVALIAO DA SOLUO
Este captulo apresenta o mtodo de avaliao do modelo
genrico de processo para monitoramento e controle e da soluo
desenvolvida no dotProject. Esta avaliao tem como objetivo coletar a
opinio de especialistas que atuam na rea de gerenciamento de projetos
dentro de MPE sobre a aderncia do que foi desenvolvido ao contexto
das MPE assim como apresentar propostas de melhorias que possam
agregar na evoluo do trabalho. Ao final desse processo ser
apresentada a avaliao da ferramenta evoluda quanto ao grau de
atendimento das UBP's.
6.1 DEFINIO DA AVALIAO
O
mtodo
utilizado
nessa
avaliao
GQM
Goal/Question/Metric (BASILI 1994). O GQM define o primeiro passo

para se medir algo de maneira eficaz sendo a definio de objetivos que
devem servir como rota para a definio de mtricas.
Objetivo 1: Avaliar a adequao e eficincia do modelo

proposto para monitoramento e controle na realidade das micro
e pequenas empresas de software, sob o ponto de vista de
pessoas com experincia em gerenciamento de projetos.
Objetivo 2: Avaliar a aderncia da soluo proposta e sua

eficincia para realizar as operaes que se dispem dando
suporte ao modelo proposto.
Objetivo 3: Identificar melhorias no trabalho realizado e

experincia do avaliador.
145
Seguindo o mtodo GQM, para cada objetivo definido so
definidas perguntas que por sua vez geram mtricas. As perguntas e
mtricas definidas no objetivo 1 e 2 so organizadas em conformidade
com o tpico "4.3 - Definio do Modelo Genrico de Processo" deste
trabalho.
Com os objetivos definidos, avanamos para segunda etapa do
GQM, a definio das questes (Tabela 21).
Tabela 21 - Questes para avaliao com o mtodo GQM
Objetivos
Objetivo 1
Questes
1.1 Considero o modelo genrico de processo adequado
para realizar o monitoramento e controle em MPE.
1.2 Considero o modelo genrico de processo para o
monitoramento e controle consistente.
1.3 Considero o modelo genrico de processo completo
para realizar o monitoramento e controle.
Objetivo 2
2.1 Considero a evoluo do dotProject til para registrar

o envolvimento dos stakeholders no projeto.
2.2 Considero a evoluo do dotProject til para realizar
o monitoramento de cronograma do projeto.
o monitoramento de custo do projeto.
o monitoramento de qualidade do projeto.
e acompanhar aes corretivas.
reunies referentes ao projeto.
2.7 Considero a evoluo do dotProject til para exibir
gerncia snior a situao atual dos projetos da empresa.
2.8 A evoluo do dotProject est consistente.
2.9 A evoluo do dotProject est adequada para
suportar monitoramento e controle em MPE.
146
Objetivo 3
3.1 Quantos anos de experincia voc possui com

gerenciamento de projetos?
3.2 Quais so os principais pontos fortes que voc
observou?
3.3 Quais so as principais sugestes de melhoria?
3.4 Mais algum outro comentrio?
A mtrica utilizada para os objetivos 1 e 2 foi a opinio dos

especialistas sobre o grau de aderncia do modelo/ferramenta utilizando
a escala de Likert (MITCHELL 2012), no seu formato tpico com uma
escala de 1 a 5 onde 1 representa "Discordo Totalmente" e 5 representa
"Concordo Totalmente". Essas perguntas tm como medida a impresso
subjetiva do avaliador sobre o grau de atendimento do item que est
sendo questionado. No objetivo 3 o avaliador deve fornecer sua opinio
sobre o que lhe chamou a ateno e sobre melhorias que podem ser
implementadas.
A avaliao foi realizada pela web, onde o manual, questionrio
e ferramenta ficaram disponveis para o acesso. O questionrio foi
elaborado de forma que o participante tivesse informaes prvias sobre
o contexto em que a avaliao esta sendo realizada, conforme 9.3Termo de consentimento do questionrio. As perguntas utilizadas no
questionrio so as mesmas visualizadas na Tabela 21.
6.2 RESULTADO DA AVALIAO
Durante o ms de junho e julho foram enviados e-mails para
grupos de discusso de gerenciamento de projetos, empresas e
comunidades de desenvolvedores do dotProject, convidando para
147
participar da avaliao do modelo e da ferramenta tendo ao final que
responder o questionrio.
O questionrio foi disponibilizado na web utilizando o Google
Forms (http://www.google.com/google-d-s/forms), a aplicao em um
servidor privado e o manual disponvel tambm na web.
Ao todo 12
pessoas responderam o questionrio avaliando o modelo e a ferramenta

evoluda onde os resultados so apresentados abaixo na Tabela 22.
Tabela 22 - Respostas obtidas na avaliao pelos especialistas
Mediana
Objetivo 1
1.1 Considero o modelo genrico de processo adequado
para realizar o monitoramento e controle em MPE.
1.2 Considero o modelo genrico de processo para o
monitoramento e controle consistente.
1.3 Considero o modelo genrico de processo completo
para realizar o monitoramento e controle.
Objetivo 2
2.1 Considero a evoluo do dotProject til para registrar o

envolvimento dos stakeholders no projeto.
2.2 Considero a evoluo do dotProject til para realizar o
monitoramento de cronograma do projeto.
monitoramento de custo do projeto.
monitoramento de qualidade do projeto.
2.5 Considero a evoluo do dotProject til para registrar e
acompanhar aes corretivas.
reunies referentes ao projeto.
2.7 Considero a evoluo do dotProject til para exibir
gerncia snior a situao atual dos projetos da empresa.
2.9 A evoluo do dotProject est adequada para suportar
4
4
5
5
5
5
5
5
4
5
148
monitoramento e controle em MPE.
A resposta foi avaliada pela mediana pois com ela possvel

eliminar valores discrepantes que possam influenciar nas respostas. A
mdia de experincia das pessoas entrevistadas foi de 6,75 anos e em
todos os objetivos as respostas foram mais prximas do nvel 5 na
escala de 1 a 5, onde 1 significa discordo totalmente e 5 concordo
plenamente.
No objetivo 1 (adequao do modelo genrico de processo)
tivemos efetivamente uma mediana 4, sendo que nenhuma resposta 1 ou
2. Talvez o detalhe para que os avaliadores concordem plenamente seja
a instabilidade e imaturidade que as MPE de modo geral vivem onde
cada um possui uma realidade especfica e tm que adaptar seus
processos para ela. Entre algumas resposta e sugestes de melhorias que
foram obtidas nas avaliaes podemos citar:
Unificar as reunies: Foi proposto que no modelo existisse
somente uma reunio e no uma para a equipe e outra para a gerncia.
Durante a elaborao do modelo houve a preocupao de definir duas
reunies para segmentar assuntos que so somente tratados pela
gerncia ou pela equipe do projeto. Por esse motivo importante termos
essas duas etapas no modelo, mesmo que em alguns casos os assuntos
tratados possam ser os mesmos existindo uma nica reunio.
Definir no modelo o que est sendo avaliado: Foi proposto que
no prprio modelo os itens de monitoramento fossem definidos. No
podemos definir no modelo pois o que ser avaliado depende do cenrio
em que a empresa est inserido, do tamanho do projeto e sua criticidade,
149
onde cada item pode ser abordado com mais nfase em determinado
momento.
Unificar a avaliao da qualidade tomando como base a
"trplice aliana" (prazo, custo e escopo): Foi proposto criar um
indicador de qualidade com base nesses parmetros. A qualidade do
projeto sim influenciada por estes fatores mas estamos tratando neste
item sobre a qualidade do produto apresentados pelo projeto.
Lembrando que o conceito de tripla restrio vm se modificando e
atualmente no se resumem somente a 3 bases.
Com relao ao objetivo 2 (aderncia da soluo proposta),
tivemos tambm uma mediana 5, sem nenhuma resposta 1 ou 2. Neste
item especificamente tivemos um agravante que a complexidade da
ferramenta dotProject (ZHAO et al. 2010). Alm de entender o que foi
evoludo, o avaliador teve que ter um conhecimento prvio do
funcionamento do dotProject que possui vrios problema de usabilidade
(FERNANDES
2008),
fator
esse
que
pode
ter
influenciado
negativamente a avaliao.
Os recursos grficos desenvolvidos na ferramenta foram muito
bem destacados pelos avaliadores. Ferramentas grficas muitas vezes
tornam mais fcil a compreenso e o julgamento da informao que est
sendo apresentada. O mais interessante nesse trabalho que e evoluo
da ferramenta foi realizada com recurso simples que no alteraram o as
funcionalidade originais da ferramenta e mesmo assim tornaram
aderentes os seus processos aos modelos e guias citados no trabalho.
Existem recursos que poderiam ser melhor implementados se fossem
concebidos diretamente no cdigo original, mas essa uma das
restries de desenvolvimento.
150
E por ltimo, no objetivo 3 (identificar melhorias) foram
sugeridos mais recursos, principalmente de integrao entre os
processos de qualidade, aes corretivas, tarefas e cronograma.
Tambm foi citado o processo de risco, mas este item no foi
implementado pois outro trabalho do grupo GQS foi realizado nessa
rea de conhecimento (KHLKAMP 2012).
Os resultados podem ser visualizados na ntegra no apndice
9.4-Avaliao realizada pelos Especialistas deste trabalho.
6.3 DISCUSSO
Os resultados obtidos nas avaliaes deixam claro que tanto o
modelo quanto a implementao tiveram os seus objetivos alcanados.
Realizando um comparativo entre a verso original do dotProject com a
verso evoluda (dotProject com Add-on), notamos que ocorreram
evolues em vrias UBP's, conforme apresentado na Tabela 23 abaixo:
Tabela 23 Comparativo de verso do dotProject
dotProject
v2.1.6
dotProject
Add-on
M1
Monitor and Control Project Work
**
***
M2
Perform Integrated Change Control
***
M3
Verify Scope
**
***
M4
Monitor and Control Scope
**
M5
Monitor and Control Schedule
**
***
M6
Monitor and Control Costs
***
M7
Monitor and Control Quality
**
UBP Description
151
M8
Conduct Progress Reviews
**
M9
Conduct Milestone Reviews
**
M10 Monitor and Control Risks
M11 Administer Procurements
M13 Monitor Commitments
**
M14 Monitor Data Management
M15 Monitor Stakeholder Involvement
**
M16 Analyze Issues
**
M17 Take Corrective Action
***
M18 Manage Corrective Action
**
Podemos notar que apesar de no terem sido contempladas

todas as UBP's, vrias delas tiveram o suporte muito mais alinhado com
os modelos de referncia. Para este trabalho, pelo tempo disponvel,
foram abordados as funcionalidades consideradas mais relevantes para
atender os requisitos solicitados pelo modelo genrico de processo para
monitoramento proposto. Essas funes visam o suporte para a chamada
trplice restrio (PMI 2008), que so custo, tempo e escopo.
6.4 AMEAAS VALIDADE
Neste trabalho foram identificados algumas pontos que podem
representar ameaas validade do trabalho.
A ferramenta dotProject um software que apresenta
problemas de usabilidade e alguns processos no muito intuitivos para
realizar determinadas operaes. Dessa forma o avaliador, pode ter
encontrado dificuldades em diferenciar o que realmente foi construdo
nesse trabalho, o que eram funcionalidades nativas do dotProject e quais
eram as limitaes encontradas no desenvolvimento de novos recursos.
152
Para tentar amenizar essa situao foi desenvolvido um manual de
usurio com vrias informaes que auxiliavam o avaliador a se
contextualizar e apresentava com detalhes o que foi desenvolvido. Este
documento se tornou um documento com 20 pginas e dessa forma
tambm surgiu a preocupao do avaliador deixar de avaliar por
entender que o tempo para isso seria demasiamente grande para um
trabalho voluntrio de avaliao.
No intuito de agilizar o contato na ferramenta com as novas
funcionalidades, foi criado um projeto modelo que tentou reproduzir um
projeto real em andamento dentro de uma micro empresa de software.
Apesar da tentativa de facilitar o trabalho do avaliador, este projeto
pode no ter atendido todas as situaes possveis que ocorrem em uma
MPE e dessa forma o avaliador pode ter sentido falta de algum recurso
especifico. Este problema foi amenizado pelo projeto ter sido criado por
um gerente de projeto de uma micro e pequena empresa com 6 anos de
experincia e revisado por outro com mais de 10 anos de experincia.
153
7. CONCLUSO
O objetivo principal deste trabalho foi definir um modelo
genrico de processo para monitoramento e controle de projetos
alinhado ao PMBOK (4. ed.) e CMMI-DEV 1.3 para micro e pequenas
empresas de desenvolvimento de software alm de aprimorar uma
ferramenta para atender os requisitos do modelo proposto.
A elaborao do modelo foi realizada levando-se em
considerao aspectos e restries em que as MPE vivem. Os passos e
artefatos gerados em cada uma das etapas buscam alinhar o trabalho a
ser realizado com a capacidade e estrutura desse tipo de empresa, no
sendo to grande que exija excesso de trabalho por parte do gerente de
projetos mas tambm no to pequeno preservando o formalismos
necessrio das normas e modelos citados durante o trabalho.
Outros objetivos tambm foram atingidos, sendo o primeiro
deles referente a avaliao de ferramentas de cdigo livre para
gerenciamento de projetos em relao ao monitoramento e controle.
Como citado durante o trabalho, a ferramenta que obteve a melhor
pontuao foi o dotProject. Convm lembrar que mesmo essa
ferramenta em sua verso original apresentou diversas carncias,
impossibilitando que as atividades fossem executadas de maneira
completa.
Aps a definio do modelo, foi realizado o levantamento de
requisitos, concepo de novas funcionalidades para o dotProject,
especificao das funcionalidades, implementao e testes. Durante essa
atividades foi possvel verificar que a ferramenta no foi projetada
convergindo para um modelo de suporte de gerenciamento de projetos.
154
Existem funcionalidades simples que podem agregar muito valor a
ferramenta se tivessem sido projetadas na sua concepo. Talvez seja
esse o motivo que leva vrias empresas a desenvolverem solues
proprietrias, j que as ferramentas disponveis em sua maioria no
fornecem o grau de suporte necessrio.
Outro ponto importante a ser citado que a concepo da
soluo proposta para complementar o suporte do dotProject, seguiu a
abordagem de mdulo Add-on, ou seja, essa implementao no altera
as funcionalidades bsicas do dotProject e com isso pode ser
simplesmente adicionada no sistema original completando o seu
suporte. O mdulo desenvolvido foi publicado na internet e at o
momento da redao deste trabalho conta com 485 downloads .
Com o modelo e ferramentas finalizados, foi realizado o survey
com especialistas para verificar a aderncia do trabalho executado para
a realidade das MPE. Para todos os objetivos definidos no survey foi
obtido um resultado satisfatrio atestando que o trabalho est
compatvel com o contexto em que as MPE esto inseridos.
Desta forma, todos os objetivos previstos neste trabalho foram
atingidos.
Considerando os aspectos financeiros das MPE, este trabalho
est apresentando uma soluo que tem o potencial de ser aproveitada
pelas MPE pois alm de evoluir uma ferramenta de forma gratuita, est
propondo uma direo para que empresas desse porte possam realizar
atividades de monitoramento e controle de projetos alinhadas um
modelo, visto que este grupo de atividade, dentro do contexto de
gerenciamento um dos mais crticos para se atingir o sucesso do
projeto.
155
Como trabalhos futuros para continuar a evoluo deste
trabalho propem-se:
evoluo de outras reas do dotProject;
elaborao de uma metodologia para gerenciamento de projetos

em MPE;
elaborao de manuais iterativos ou vdeos explicativos;
melhoras na usabilidade do dotProject;
desenvolvimento de uma nova ferramenta criada desde a sua

concepo alinhada aos modelos de referncia.
156
8. REFERNCIAS BIBLIOGRAFICAS
ABES - Associao Brasileira de Empresas de Software. MERCADO
BRASILEIRO DE SOFTWARE E SERVIOS DE TI -2011. 2012.
Disponvel em:
<http://arquivos.s2publicom.com.br/345/multimidia/7958_345_Image.p
df>
ABREU, Srgio Mendes de Oliveira. Evoluo da ferramenta de
gerenciamento de projetos dotProject para suporte ao grupo de
processo de iniciao. 2011. Trabalho de Concluso de Curso.
(Graduao em Ciencia da Computacao) Universidade Federal de
Santa Catarina.
BALDASSARRE, Maria Teresa et al. Harmonization of ISO/IEC
9001:2000 and CMMI-DEV: from a theoretical comparison to a
real case application. Software Quality Journal, Springer US, p. 309335. 21 jul. 2010.
BASILI, V. R., G. Caldiera, H. D. Rombach. Goal/Question/Metric
Approach. In J. Marciniak (ed.), Encyclopedia of Software
Engineering, volume 1. John Wiley & Sons, 1994.
BECK, K. Programao Extrema Explicada. Essence and Accidents
of Software Engineering. Proc. IFIP, IEEE CS Press, pp. 1069-1076;
reprinted in IEEE Computer, pp. 10-19, Apr. 1987.
BNDS -Banco Nacional do Desenvolvimento. Porte da Empresa.
Disponvel em:
<http://www.bndes.gov.br/SiteBNDES/bndes/bndes_pt/Navegacao_Sup
lementar/Perfil/porte.html>. Acesso em: 15 setembro de 2012.
CAO, Lan, MOHAN, Kannan, PENG, Xu, RAMESH,
Balasubramaniam. How extreme does extreme programming have to
be adapting XP practices to large scale project.Proc. 37th Annual
Hawaii Int. Conf. on System Sciences, Hawaii, p. 30083c. 2004.
157
CHAVES, Lucio Edi, e outros. Gerenciamento da comunicao em
projetos. Fundao Getulio Vargas. V. FGV Management. VI Titulo
VII. 2007
DAYCHOUM, Merhi. 40 + 4 Ferramentas e Tcnicas de
Gerenciamento. 4. ed. Rio de Janeiro: Brasport, 2010. 257 p.
DINSMORE, Paul Campbell, e outros. Como se tornar um
profissional em gerenciamento de projetos: livro-base de "Preparao
para Certificado PMP - Project Management Professional". Rio de
Janeiro: Qualitymark, 2005.
DOD, Department of Defense & US Army. PSM - Practical Software
and System Measurement, A foundation for Objective Project
Management, Version 4.0c. Department of Defense & US Army, maro
de 2003.
EBERT, Christof. How Open Source Tools Can Benefit Industry.
IEEE Software, IEEE Computer Society, vol. 26, n. 2, p. 50-51. abr.
2009.
FERNANDES, L. S.; GRESSE VON WANGENHEIM, C.;
PACHECO, A. P.; HAUCK, J. C. R. Uma avaliao da interface de
usurio de uma ferramenta Open Source de gerenciamento de
projetos baseado na web. In: Anais do P&D Congresso Brasileiro de
Pesquisa e Desenvolvimento em Design, So Paulo, 2008.
GARCIA JUNIOR, Paulo Roberto Garcia. APSEE-Metric: Um modelo
para Mensurao em Processo de Software. Porto Alegre: UFRS-RS,
2006 165p.
GNU - General Public License. GNU-GPL., June 2007. Disponvel em:
<http://www.gnu.org/copyleft/gpl.html>. Acesso em 3 de dezembro de
2012.
GONALVES Rafael, A. Pereira, C. Wangenheim, and J. Hauck,
Supporting time planning by enhancing an Open Source Software
in Alignment with CMMI-DEV and PMBOK. International.
International Free Software Workshop. Porto Alegre, Brazil, 2012.
158
GONALVES, Rafael. Planejamento de Tempo em Projetos de
Desenvolvimento de Software para Micro e Pequenas Empresas
Alinhado ao PMBOK e CMMI. Dissertao (Mestrado em Cincia da
Computao) - UFSC, Florianpolis, 2012.
HANAKAWA, Noriko; KIMIHARU, Okura. A Project Management
Support Tool using Communication for Agile Software Development.
In: ASIA-PACIFIC SOFTWARE ENGINEERING CONFERENCE,
11., 2004, Busan/coria. Washington: Ieee Computer Society, 2004. v.
1, p. 316 - 323.
HAUCK, Jean Carlo Rossa. Uma abordagem de modelagem de
processos suportada por um guia de referncia alinhado ao CMMIDEV, MPS.BR e ISO/IEC 15504. Dissertao (Mestrado em Cincia
da Computao) - UFSC, Florianpolis, 2007.
HUGHES, B.; COTTERELL M.. Software Project Management,
McGraw-Hill, 2rd Edition, 2001.
HUGHES, B.; COTTERELL M.. Software Project Management,
McGraw-Hill, 3rd Edition, 2002.
IBM - International Business Machines; Presentation: Get more from
your information with IBM Alphablox. Disponvel em: <
ftp://ftp.software.ibm.com/software/data/bi/alphabloxvideo/alphablox.ht
ml>Acessado em: 22 de julho de 2010.
JALOTE, Pankaj. CMM in Practice: Processes for Executing
Software Projects at Infosys. Addison Wesley: Longman, 2000.
KHLKAMP, Elisa de Freitas. Evoluo da Ferramenta para
Gerenciar Projetos Alinhado ao CMMI-DEV e PMBOK para
Planejamento de Riscos. 2012. Trabalho de Concluso de Curso.
(Graduao em Sistemas de Informao) Universidade Federal de
Santa Catarina.
MCTI - Ministrio da Cincia, Tecnologia e Inovao (Brasil).

Evoluo da Qualidade de Software no Brasil de 1994-2010
baseada nas pesquisas e projetos do PBQP Software.
159
Disponvel em:
<http://www.mct.gov.br/upd_blob/0222/222128.pdf>. Acesso
em: 08 dez. 2012.
MCT, MINISTRIO DA CINCIA E TECNOLOGIA (Brasil).
Qualificao CMM e CMMI no Brasil. 2006. Disponvel em: <
http://www.mct.gov.br/upd_blob/0009/9238.pdf >. Acesso em: 20 abr.
2010.
MITCHELL, Mark & JOLLEY, Janina. Research Design Explained.
8rd ed. Wadsworth: Harcourt Brace, 2012.
MICROSOFT; CRM Online Custom Built Dashboards. Disponvel
em: <
http://blogs.msdn.com/b/dynamicscrmonline/archive/2009/06/02/crmonline-custom-built-dashboards.aspx>Acessado em: 22 de julho de
2010.
OMG - Object Management Group. UML 2.0., Julho, 2005. Disponvel
em: < http://www.omg.org/spec/UML/2.0/>. Acesso em: 1 dezembro de
2012.
OMG - Object Management Group. Software & Systems Process
Engineering Meta-Model Specification - 2ed version. Abril, 2008.
Acessvel em: http://www.omg.org/spec/SPEM/2.0/PDF.
ORTIGARA, Anacleto ngelo. Causas que condicionam a
mortalidade e/ou o sucesso das micro e pequenas empresas no
estado de Santa Catarina. Florianpolis, 2006. 168 f. Tese
(Doutorado) - Universidade Federal de Santa Catarina, Centro
Tecnolgico. Programa de Ps-Graduao em Engenharia de Produo.
PEREIRA, Andr; GONALVES, Rafael; WANGENHEIM,
Christiane; BUGLIONE, Luigi. Comparion of Open Source Tools for
Project Management. International Journal of Software Engineering
and Knowledge Engineering (IJSEKE), 2012, in press March/April
2013.
160
PESCADOR, Suzana Vilas Boas. Evoluo da Ferramenta
dotProject para Suporte ao Encerramento de Projetos. 2012.
Trabalho de Concluso de Curso. (Graduao em Cincia da
Computao) Universidade Federal de Santa Catarina.
PMI - PROJECT MANAGEMENT INSTITUTE. Um guia do
conjunto de conhecimentos em gerenciamento de projetos: Guia
PMBOK. 4. ed. Pennsylvania. 2008.
PMI - PROJECT MANAGEMENT INSTITUTE. Pesquisa
PMSURVEY.ORG 2012: PMI. 2012. Disponvel em:
<http://www.pmsurvey.org/>. Acesso em: 06 out. 2012.
PRESSMAN, ROGER S. Engenharia de software: uma abordagem
profissional. 7 Edio. Ed. McGrawHill, 2011. ISBN:
9788563308337.
PSBB, PORTAL DO SOFTWARE PUBLICO BRASILEIRO (Brasil).
Software e Servios de TI: A Indstria Brasileira em Perspectiva
Resumo Executivo. Disponvel em: <
http://www.softwarepublico.gov.br/5cqualibr/2-documentostecnicos/download/resumoexecutivo.pdf?file_id=17072441>. Acesso
em: 20 mar. 2010.
PSBB, PORTAL DO SOFTWARE PUBLICO BRASILEIRO (Brasil).
GP-WEB. Disponvel em: < http://www.softwarepublico.gov.br/vercomunidade?community_id=31574974>. Acesso em: 4 out. 2011.
QURESHI, M. Rizwan Jameel. Agile software development
methodology for medium and large projects. IEEE Software, volume
6, August 2012, p. 358-363.
RICHARDSON, Ita; WANGENHEIM, C. Gresse von. Why are Small
Software Organizations Different?. IEEE Software, volume 24, 2007,
p. 18-22.
SCRUM, PORTAL DO SOFTWARE PUBLICO BRASILEIRO
(Brasil). SCRUM. Disponvel em: < http://www.scrumalliance.org/
>. Acesso em: 12 julho de 2012.
161
SEBRAE, SERVIO BRASILEIRO DE APOIO S MICRO E
PEQUENAS EMPRESAS (Brasil). Fatores Condicionantes e Taxas
de Sobrevivncia e Mortalidade das Micro e Pequenas Empresas no
Brasil 20032005. Disponvel em:
<http://www.sebrae.com.br/exibeBiblioteca?documento=8F5BDE7973
6CB99483257447006CBAD3>. Acesso em: 22 jan. 2010.
SEBRAE, SERVIO BRASILEIRO DE APOIO S MICRO E
PEQUENAS EMPRESAS (Brasil). Anurio de trabalho na Micro e
Pequena Empresa 2010/2011. Disponvel em: <
http://www.biblioteca.sebrae.com.br/bds/BDS.nsf/25BA39988A7410D
78325795D003E8172/$File/NT00047276.pdf>. Acesso em: 15 set.
2012.
SEI - SOFTWARE ENGINEERING INSTITUTE. CMMI for
Development (CMMI DEV). Technical report CMU/SEI-2010-TR033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, 2010 Disponvel em: <http://cmmiinstitute.com/ >. Acesso
em: 1 de dezembro de 2012.
SEI - SOFTWARE ENGINEERING INSTITUTE (Usa). Process
Maturity Profile CMMI/SCAMPI Class A Appraisal Results:
Setember 2012. Pittsburgh: Carnegie Mellon University, 2012. 28 p.
SILVA, E.; MENEZES, E. Metodologia da Pesquisa e Elaborao de
Dissertao. 3 edio. Universidade Federal de Santa Catarina. 2001.
Disponvel em:
<http://projetos.inf.ufsc.br/arquivos/Metodologia%20da%20Pesquisa%
203a%20edicao.pdf. >Acessado em: 18 de fevereiro de 2010.
SILVA, Djoni Antonio. Um suporte para a integrao de
ferramentas de gerenciamento de projeto, visando o alinhamento
com normas e modelos. So Jos, 2009. 120f. Trabalho de Concluso
de Curso (Graduao em Cincia da Computao)Centro de Cincias
Tecnolgicas da Terra e do Mar, Universidade do Vale do Itaja, So
Jos, 2009.
SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro,
162
Guia de Implementao Parte 6: Fundamentao para
Implementao do Nvel B do MR-MPS: Maio 2009: Softex, 2009.
ISBN 978-85-99334-16-4.
SOFTEX, A indstria brasileira em perspectiva v2. Observatrio
Softex. Campinas: [s.n.], 2012. ISSN 1984-6797.
SOMMERVILLE, Ian. Software Enginneering.8 ed. So Paulo:
Pearson, 2007. 552p.
VARGAS, Ricardo Viana. Gerenciamento de Projetos: Estabelecendo
diferenciais. 6. ed. Rio de Janeiro: Brasport, 2005. 250 p.
WANGENHEIM, C. G. V; HAUCK, J. C. R; WANGENHEIM, A. V.
Enhancing Open Source Software in Alignment with CMMI-DEV.
IEEE Software, vol. 26 no. 2 Maro-Abril. 2009.
WANGENHEIM, C. G. V, C.; DA SILVA, D. A.; BUGLIONE, L.;
SCHEIDT, R.; PRIKLADNICKI, R. Best Practice Fusion of CMMIDEV v1.2 (PP, PMC, SAM) and PMBOK 2008. Information and
Software Technology, Elsevier, 2010.
WRASSE, Deise Luise. Evoluo da Ferramenta dotProject para o
Planejamento de Recursos Humanos. 2012. Trabalho de Concluso
de Curso. (Graduao em Ciencia da Computacao) Universidade
Federal de Santa Catarina.
ZHAO, L., DEEK, F.P., MCHUGH, J.A.: Exploratory inspection a
userbased learning method for improving open source software
usability, J. Softw. Maint. Evol.: Res. Pract., 2010, 22, (8), pp. 653
675.
ZHU Kedi; YANG Hongping. Application of earned value analysis in
project monitoring and control of CMMI. Advanced Computer
Theory and Engineering (ICACTE), 2010 3rd International Conference
on , vol.4, no., pp.V4-164-V4-168, 20-22 Aug. 2010
163
9. APNDICE
9.1 EXEMPLOS DE MEDIDAS
Medida: 1. Custo - Custo do Projeto
Objetivo: Obter o custo planejado do projeto, o custo atual e
com isso visualizar a variao desse valor para identificar desvios.
Exemplo: No relatrio abaixo podemos visualizar duas linhas
uma mostrando a evoluo do custo planejado para o projeto ao longo
do tempo e outra mostrando o custo real que est sendo efetuado.
800
700
600
500
400
Planejado
300
Real
200
100
Figura 39 - Medida 1 - Custo
Dez
Out
Nov
Set
Ago
Jul
Jun
Abr
Mai
Mar
Fev
Jan
164
Medida: 2. Custo - Custo de recursos humanos
Objetivo: Obter os valores gastos com todos os recursos
humanos, consultorias e contratao comparando esse valor com o
planejado.
Exemplo: No relatrio abaixo podemos visualizar 3 linhas que
apresentam o custo total planejado do projeto o custo planejado e real
com recursos humanos.
800
700
600
500
Total
400
Planejado RH
300
Real RH
200
100
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
Figura 40 - Medida 2 - Custo RH
165
Medida: 3. Custo - Custo de investimento
Objetivo: Obter o custo para implementar componentes e
recursos que podem ser utilizados em outros projetos
Exemplo: No relatrio abaixo podemos visualizar 3 linhas que
apresentam o custo total planejado do projeto o custo planejado e real
gasto como investimento.
700
600
500
400
Total
300
Planejado Invest.
200
Real Invest.
100
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
Figura 41 - Medida 3 - Custo de investimento
166
Medida: 4. Esforo - Esforo do projeto
Objetivo: Obter os esforo inicialmente calculado no projeto e
o atualmente calculado para identificar variaes.
Exemplo: No relatrio abaixo apresentado o esforo
planejado e real mensal utilizados para realizar todas as atividades
relacionadas ao projeto
600
500
400
300
Planejado
Real
200
100
Figura 42 - Medida 4 - Esforo do projeto
Dez
Nov
Out
Set
Ago
Jul
Jun
Mai
Abr
Mar
Fev
Jan
167
Medida: 5. Esforo - Esforo gerencial
Objetivo: Obter o esforo gasto com recursos destinados ao
gerenciamento e controle do projeto.
Exemplo: No relatrio abaixo apresentado o esforo real do
projeto e o real utilizado em atividades relacionadas ao gerenciamento
do projeto.
600
500
400
300
Esforo total
Esforo gerencial
200
100
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
Figura 43 - Medida 5 - Esforo gerencial
168
Medida: 6. Durao - Durao do projeto
Objetivo: Obter a durao atualizada do projeto
Exemplo: O relatrio abaixo apresenta a durao do projeto
utilizando o grfico de Gantt
Figura 44 - Medida 6 - Durao do projeto
169
Medida: 7. Produtividade - Fator de produtividade
Objetivo: Obter o ndice de produtividade do projeto para
acompanhar desvios e calcular entregas futuras.
Exemplo: O relatrio abaixo apresenta a variao do
cronograma e do custo em relao ao planejado. A linha 0 indica que o
projeto est correndo conforme o previsto e todos os valores acima
dessa linha indicam que a variao que ocorreu positiva, abaixo indica
variao negativa.
30%
20%
10%
-10%
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
0%
Variao
Cronograma
Variao Custo
-20%
-30%
-40%
-50%
Figura 45 - Medida 7 - Fator de produtividade
170
Medida: 8. Produtividade - Reutilizao
Objetivo: Obter o esforo oriundo da reutilizao de
componentes previamente construdos em outros projetos.
Exemplo: O relatrio abaixo mostra um grfico de barras onde
em uma mesma coluna podemos visualizar o esforo total do projeto e o
esforo ganho com a utilizao de componentes
35
30
25
20
15
Esforo ganho
10
Esforo Planejado
5
0
Figura 46 - Medida 8 - Fator de reutilizao
171
Medida: 9. Qualidade das entregas (deliverables) - Indicador de
qualidade
Objetivo: Informar o nvel de qualidade das entregas realizadas
no projeto
Exemplo: O relatrio abaixo mostra o percentual das entregas
realizadas e quantas dessas foram aprovadas com retrabalho, sem
retrabalho e rejeitadas pelo cliente.
Aprovado sem
Retrabalho
Aprovado com
Retrabalho
Rejeitadas
Figura 47 - Medida 9 - Indicador de qualidade das entregas
172
Medida: 10. Qualidade das entregas (deliverables) - Indicador
de aderncia ao processo de desenvolvimento
Objetivo: Indicar o percentual das entregas que passaram por
todas as etapas do processo de desenvolvimento previstas no plano.
Exemplo: O relatrio abaixo indica o percentual de entregas
que passaram por todos os processos de desenvolvimento previstos no
plano e o percentual que tiveram uma ou mais etapas suprimidas.
Aderentes ao modelo
No aderentes ao
modelo
Figura 48 - Medida 10 - Indicador de aderncia do modelo
173
Medida: 11. Qualidade das entregas (deliverables) - Indicador
de rejeio
Objetivo: Identificar o nmero de problemas identificados aps
a aceitao da entrega pelo cliente.
Exemplo: O relatrio abaixo mostra um grfico de barras
segmentado pelas entregas realizadas no projeto o nmero de defeitos
identificados em cada uma das etapas.
12
10
8
6
Erros identificados
4
2
0
Etapa 1 Etapa 2 Etapa 3 Etapa 4
Figura 49 - Medida 11 - Indicador de rejeio
174
Medida: 12. Qualidade das entregas (deliverables) - Alterao
de requisito
Objetivo: Identificar alteraes de requisitos nas entregas do
projeto.
Exemplo: O relatrio abaixo mostra quantas alteraes foram
solicitadas pelo cliente em cada uma das etapas do projeto previstas.
Figura 50 - Medida 12 - Alterao de requisitos
175
Medida: 13. Satisfao com as entregas - ndice de satisfao
do cliente (Entregas).
Objetivo: Realizar um benchmark sobre a viso do cliente em
relao a sua satisfao das entregas do projeto.
Exemplo: O relatrio abaixo o nvel de satisfao do cliente em
relao as entregas realizadas do projeto medindo o valor em oito
categorias distintas.
12
10
8
6
4
2
0
Figura 51 - Medida 13 - ndice de satisfao do cliente
176
Medida: 14. Satisfao com as entregas - ndice de requisies
aprovadas.
Objetivo: Obter o nmero de solicitaes realizadas durante o
projeto que foram devidamente atendidas conforme o solicitado.
Exemplo: O relatrio abaixo mostra o total de requisies feitas
no projeto e agrupa elas segundo o seu status.
Pendentes
Rejeitadas
Requisies
Aprovadas
Requisioes
0
10
15
20
Figura 52 - Medida 14 - ndice de aprovao
25
177
Medida: 15. Satisfao com a equipe do projeto - ndice de
satisfao do cliente (Equipe).
Objetivo: Realizar um benchmark sobre a viso do cliente em
relao a sua satisfao sobre a equipe do projeto.
Exemplo: O relatrio abaixo o nvel de satisfao do cliente em
relao a equipe do projeto medindo o valor em dez categorias distintas.
12
10
8
6
4
2
0
Figura 53 - Medida 15 - Satisfao com a equipe
178
Medida: 16. Satisfao com a equipe do projeto - Tempo de
resposta.
Objetivo: Informar o tempo mdio de resposta s solicitaes
realizadas em cada uma das etapas do projeto
Exemplo: O relatrio abaixo mostra o tempo mdio de resposta
que foi obtido para atender as solicitaes realizados durante o projeto.
14
12
10
8
Tempo
de
6
4
2
0
Etapa 1
Etapa 2
Etapa 3
Etapa 4
Figura 54 - Medida 16 - Satisfao tempo de resposta
9.2 DETALHAMENTO DOS CASOS DE USO

9.2.1 - UC01 - REGISTRAR LINHA DE BASE PROJETO
O objetivo de uma linha de base (baseline) criar uma
"imagem" dos artefatos do projeto com o objetivo de reproduzir uma
situao anteriormente existente, rastrear mudanas ou elaborar
relatrios. Essa situao ocorre principalmente por mudanas que
normalmente ocorrem durante a execuo do projeto. Este caso de uso
179
tem como objetivo criar esse registro para que posteriormente possam
ser feitas anlises comparativas de mudanas que ocorreram no
planejamento do projeto.
UC01 - Registrar linha de base.
Fluxo: Base
1.
O sistema apresenta a lista de linhas de base cadastradas para o
projeto (Figura 55).
2.
O usurio clica no boto "Nova Baseline" para cadastrar uma
nova linha de base
3.
O sistema apresenta a tela de cadastro de uma nova linha de
base onde ele deve informar: Nome da baseline, Verso e Observao
(Figura 56 - Tela de Cadastro de linha de base UC01Figura 56).
4.
O usurio clica no boto Gravar
5.
O sistema grava a posio atual de todas as tarefas, custo de
recursos, registro de horas consumidas em cada tarefa.
Fluxo: Alternativo
1.
No passo 2, o usurio pode escolher uma linha de base e clicar
no boto excluir para apagar esse registro ou alterar para modificar o
nome, verso ou observao desse registro. A alterao no altera as
informaes gravadas anteriormente das tarefas do projeto, somente as
informaes acima mencionadas.
Fluxo: Exceo
Figura 55 - Tela do Visualizao de linhas de base UC01
180
Figura 56 - Tela de Cadastro de linha de base UC01
9.2.2 - UC02 - REGISTRAR AES CORRETIVAS

Durante um projeto inevitvel que mudanas sejam
solicitadas. No caso de MPE onde muitas vezes adotado o ciclo de
vida iterativo incremental (PRESSMAN 2011) para desenvolvimento de
sistemas, casos de uso que foram anteriormente finalizados podem
sofrer alteraes em virtude de novos requisitos levantados. Neste caso
importante manter o histrico dessas mudanas para que no final do
projeto todas as mudanas possam ser rastreadas e justificadas para
todos os envolvidos.
Esta caso de uso tem a funo de registrar mudanas no projeto
identificando causa, pontos de impacto, responsvel e tambm um
registro de aes tomadas com base nessa solicitao.
Fluxo: Base
1.
O usurio seleciona uma tarefa do projeto e clica na aba aes
corretivas.
2.
O sistema apresenta a lista de aes corretivas da tarefa
181
selecionada (Figura 57).
3.
O usurio clica no boto "Nova Ao Corretiva" para cadastrar
nova ao corretiva.
4.
O sistema apresenta o formulrio contendo: Projeto, tarefa,
Impacto em horas, descrio, impacto, ao corretiva, responsvel,
prazo e a ata de origem da solicitao (Figura 58).
5.
6.
O sistema grava os dados informados.
Fluxo: Alternativo
1. No passo 1, o usurio pode registrar tambm uma ao corretiva
diretamente pelo projeto, sem precisa selecionar uma tarefa ou
dentro de uma ata de reunio.
2. No passo 2, o usurio pode escolher uma ao corretiva e clicar no
boto excluir para apagar esse registro ou alterar para alterar as
informaes.
Fluxo: Exceo
Figura 57 - Tela do Visualizao da lista de Ao Corretiva UC02
182
Figura 58 - Tela de Cadastro Ao Corretiva UC02
9.2.3 - UC03 - REGISTRAR ATA DE REUNIO (UC03, UC04,

UC05, UC06)
Este caso de uso responsvel por registrar as informaes
discutidas em reunies referentes ao projeto no mbito de
monitoramento e controle do projeto.
Existem 4 tipo de ata que podem ser cadastradas no sistema:
Ata Padro (Figura 60): serve somente para registrar algum
encontro que deve ser documentado no sistema por ter sido relevante.
Ata de Monitoramento (Figura 61): esta ata possui os mesmos

campos da ata padro, mas inclui perguntas que devem ser respondidas
183
para ajudar a guiar a monitorao de itens importantes que devem ser
abordados no gerenciamento de um projeto:
A utilizao e comunicao dos dados est seguindo o plano?
O cronograma est sendo realizado de acordo com o plano?
O envolvimento dos interessados est seguindo o plano?
Ocorreram alteraes nos riscos?
Ocorreram riscos?
Os custos esto sendo realizados de acordo com o plano?
Ata de Entrega (Figura 62): Serve para registrar oficialmente

entregas de tarefas finalizadas no sistema. O sistema mostra todas as
tarefas 100% finalizadas e tambm possui todos os campos da ata
padro.
Ata Status Report (Figura 63): Assim como as demais atas,

possui todos os campos da ata padro e a posio da anlise de valor
agregado atual do projeto que ser arquivada na ata.
Fluxo: Base
1.
O usurio seleciona a aba de Ata dentro das informaes do
projeto.
2.
O sistema apresenta a lista de atas anteriormente cadastradas no
sistema para o projeto selecionado (Figura 59).
3.
O usurio clica no boto "Nova Ata de Reunio" para cadastrar
nova ata (Figura 60).
4.
O sistema apresenta o formulrio contendo: Projeto, data, ttulo,
participantes, assunto e tipo de reunio.
5.
O usurio preenche os dados e escolhe o tipo de reunio que
184
esta cadastrando.
6.
O sistema apresenta informaes diferenciadas para o tipo de
ata selecionado pelo usurio.
Ata de monitoramento (Figura 61).
Ata de Entrega (Figura 62).
Ata de Status Report (Figura 63).
7.
8.
Fluxo: Alternativo
1. No passo 2, o usurio pode escolher uma ata e clicar no boto
excluir para apagar esse registro ou alterar para alterar as
informaes.
Fluxo: Exceo
Figura 59 - Tela de lista de Ata de reunio UC03
185
Figura 60 - Tela do Ata de reunio - Padro UC03
Figura 61 - Tela do Ata de reunio - Monitoramento UC04
186
Figura 62 - Tela do Ata de reunio - Entrega UC05
Figura 63 - Tela do Ata de reunio - Status Report UC06
9.2.4 - UC07 - VISUALIZAR MONITORAMENTO DE TEMPO

Este caso de uso tem o objetivo de exibir um resumo das
informaes de tempo do projeto com base na anlise de valor agregado
das informaes cadastradas no sistema. Devem existir nessa
funcionalidade as seguintes informaes: valor planejado, valor
agregado do trabalho realizado, variao do cronograma, ndice de
desempenho de prazo.
O valor planejado (VP), obtido pelo somatrio da
multiplicao do percentual de completude de todas as tarefas que
deveriam estar finalizadas na data atual pelo valor da prpria tarefa.
O valor agregado (VA), obtido pelo somatrio da
multiplicao do percentual de completude de todas as tarefas pelo
valor da prpria tarefa na data atual.
A variao do prazo (VPR) obtida pela diferena entre o
valor agregado e o valor planejado. VPR = VA - VP
Recordando que:
VPR < 0: Projeto est com atrasado em relao ao previsto.
VPR > 0: Projeto est adiantado em relao ao previsto.
VPR = 0: Projeto est conforme o previsto.
187
O ndice de desempenho de prazo (IDP) calculado
dividindo o valor agregado pelo valor planejado. IDP = VA / VP
Recordando que:
IDP < 1: o desempenho do cronograma est abaixo do limite.
IDP > 1: o desempenho do cronograma est acima do limite.
IDP = 1: o desempenho do cronograma est como o planejado.
Alm das informaes acima o sistema deve tambm apresentar

um grfico a variao do cronograma dos ltimos 12 meses.
Fluxo: Base
1.
O sistema apresenta a tela com o calculo de valor agregado de
tempo efetuado para a data e planejamento atual (Figura 64).
2.
O usurio pode alterar a data de consulta e/ou escolher uma
linha de base anteriormente cadastrada.
3.
O sistema calcula o valor presente, valor agregado, a variao
do prazo e o ndice de desempenho com base nos dados informados.
4.
O sistema apresenta o grfico com os ltimos 12 meses de
projeto em relao a data informada. Por exemplo, caso o usurio
informe dia 20, o sistema obtm os ltimos meses com base no dia 20
tambm.
Fluxo: Alternativo
Fluxo: Exceo
1.
No passo 1 do fluxo base, caso no exista alguma informao
necessria para o calculo o sistema deve apresentar o campo e grfico
em branco.
2.
No passo 2 do fluxo base, caso o usurio no informe o valor o
sistema no apresenta os demais dados.
188
3.
No passo 4, caso o sistema no tenha histrico dos ltimos 12
meses o sistema apresenta o grfico a partir da data de incio do projeto.
Figura 64 - Tela do Visualizao de Tempo UC07
9.2.5 - UC08 - VISUALIZAR MONITORAMENTO DE CUSTO

Este caso de uso tem o objetivo de exibir um resumo das
informaes de custo do projeto com base na anlise de valor agregado
das informaes cadastradas no sistema. Devem existir nessa
funcionalidade as seguintes informaes: valor planejado, valor
agregado do trabalho realizado, custo real, variao do custo, ndice de
desempenho e estimativa do valor no termino.
O valor agregado (VA) obtido pelo somatrio da
multiplicao do percentual de completude de todas as tarefas pelo
valor da prpria tarefa na data atual.
189
O custo real (CR) o valor efetivamente gasto at o momento
no projeto. Esse fornecido pelo usurio.
A variao do custo (VC) obtido pela diferena do valor
agregado e do custo real. VC = VA CR
Recordando que:
VC < 0: Projeto est com custo maior que o previsto.
VC > 0: Projeto est com custo menor que o previsto.
VC = 0: Projeto est com os custos iguais aos previstos.
O ndice de desempenho de custo (IDC) feito dividindo o
valor agregado pelo custo real. IDC = VA / CR
Recordando que:
IDC < 1: Indica um desempenho de custo acima do limite.
IDC > 1: Indica um desempenho de custo abaixo do limite.
IDC = 1: Projeto est com o custo conforme o planejado.
Alm das informaes acima o sistema deve tambm apresentar
um grfico com custo planejado e real dos ltimos 12 meses.
Fluxo: Base
1.
O sistema apresenta a tela com o calculo de valor agregado de
tempo efetuado para a data e planejamento atual (Figura 65).
5.
O usurio pode alterar a data de consulta e/ou escolher uma
linha de base anteriormente cadastrada.
2.
O sistema calcula a variao do custo, valor agregado, ndice de
desempenho e estimativa no trmino com base na data informada.
3.
O sistema apresenta o grfico com os ltimos 12 meses de
projeto em relao a data informada. Por exemplo, caso o usurio
informe dia 20, o sistema pega os ltimos meses com base no dia 20
tambm.
Fluxo: Alternativo
190
1.
No passo 2, o usurio pode alterar a data informada para que os
clculos sejam executados com base nessa nova data.
Fluxo: Exceo
1.
No passo 1 do fluxo base, caso no exista alguma informao
necessria para o calculo o sistema deve apresentar o campo e grfico
em branco.
2.
No passo 2 do fluxo base, caso o usurio no informe o valor o
sistema no apresenta os demais dados.
3.
No passo 4, caso o sistema no tenha histrico dos ltimos 12
meses o sistema apresenta o grfico a partir da data de incio do projeto.
Figura 65 - Tela do Visualizao de Custos UC08
9.2.6 - UC09 - REGISTRAR NO CONFORMIDADE DE

QUALIDADE
Este caso de uso responsvel por registrar problemas
identificados no processo de desenvolvimento das tarefas do projeto. A
191
equipe ou pessoa designada para verificar a qualidade das entregas do
projeto deve registrar pelo sistema qual o tipo de problema identificado
no processo de desenvolvimento. Os problemas que foram aplicados
para este trabalho podem ser de 3 tipos: erros de lgica, de negcio e de
anlise.
Os erros de lgica so provenientes da m implementao de
uma funo resultando em uma resposta no esperada pelo sistema ou
tratada de forma equivocada pela programao.
Os erros de negcio tem origem de regras de negcio mal
previstas que foram implementadas corretamente mas no satisfazem os
requisitos previamente levantados com o cliente.
Os erros de anlise so erros que tem origem no levantamento
de requisitos onde foram definidos recursos que no atendem as
necessidades do cliente.
Fluxo: Base
1.
O sistema lista dos os itens de qualidade da tarefa em modo de
somente leitura (Figura 66).
2.
O usurio responsvel pela qualidade no projeto acessa a tarefa
e clica no boto add.
3.
O sistema insere uma linha nova com a opo do tipo de erro,
Descrio, Status e data de encerramento.
Fluxo: Alternativo
1.
Aps o item 1, caso o usurio clique no boto alterar o sistema
torna a linha altervel.
2.
Aps o item 1, caso o usurio clique no boto excluir
solicitado uma confirmao
Fluxo: Exceo
192
Figura 66 - Tela de registro de qualidade UC09
9.2.7 - UC10 - VISUALIZAR MONITORAMENTO

QUALIDADE
Este caso de uso responsvel por resumir as informaes de
acompanhamento da qualidade do projeto. Conforme descrito no tpico
anterior, a pessoa responsvel por testes na empresa avalia as tarefas
entregues e registra no prprio sistema os problemas encontrados. Com
essas informaes apontadas o sistema totaliza o resumo delas referente
ao projeto da seguinte forma:
Percentual de erros total do projeto;
Numero de erros por ms.
193
Essas informaes acima podem ser visualizadas com um
grfico do tipo pizza e de barras.
Fluxo: Base
1.
O sistema apresenta os dados de qualidade em forma de
grficos, o primeiro mostrando: total de tarefas sem erro, com erros de
lgica, erros de negocio e erros de anlise, o segundo grfico informa os
mesmos dados mensalmente (Figura 67).
2.
O grfico referente aos meses obtido levando em
considerao a data de termino das tarefas.
Fluxo: Alternativo
1.
Caso o sistema no o projeto no tenha 12 meses de histrico o
sistema deve contar a partir da data de incio do projeto.
Fluxo: Exceo
Figura 67 - Tela do Visualizao de Qualidade UC10
194
9.2.8 - UC11 - RELATRIO DE PROJETO GERENCIA
SNIOR
O relatrio para a gerncia snior serve para buscar as
principais informaes do projeto de forma rpida e organizada,
facilitando o trabalho de avaliao dos projetos.
Este caso de uso responsvel por listar todos os projetos
ativos de cada empresa com as informaes para analisa-los.
Fluxo: Base
1.
O usurio seleciona a empresa que deseja analisar e aps clica
na aba "Monitoramento"
2.
O sistema listas os projetos pelo nome em ordem alfabtica,
tamanho do projeto em horas, percentual de completude, IDC, IDP, VP,
VA, CR e nmero de baselines criado (Figura 68).
Fluxo: Alternativo
Fluxo: Exceo
1.
Somente os projetos ativos sero exibidos, caso no existam
projetos, a tabela ser exibida sem informaes
Figura 68 - Tela do relatrio a gerncia snior UC11
195
9.2.9 - UC12 - REGISTRAR MATRIZ DE
RESPONSABILIDADES
A matriz de responsabilidade uma ferramenta que ajuda a
manter o envolvimento dos participantes do projeto. Essa matriz delega
responsabilidades e atribui funes dentro de um projeto.
Este caso de uso responsvel por registrar a matriz de
responsabilidade para o projeto.
Abaixo na Tabela 24, podemos visualizar um exemplo da
matriz de responsabilidade que pode ser alterada para incluir o nome do
participante da equipe no lugar do papel desempenhado.
Tabela 24 - Caso de uso Matriz de responsabilidades
Responsabilidade
Atividades
Concepo
Planejamento
Execuo
Encerramento
Mudanas
Consultado
Diretoria
Equipe do Projeto
Gerente de
Projetos
Cliente
Cliente
Executa
Equipe
Comercial
Gerente de
Projetos
Equipe do
Projeto
Gerente de
Projetos
Equipe do
Projeto
Apoia
Aprova
Gerente de Diretoria
Projetos
Cliente
Gerente de Diretoria
Projetos
Cliente
Gerente de
Cliente
Projetos
Gerncia Diretoria
Snior
Cliente
Gerente de
Cliente
Projetos
Fluxo: Base
1.
O usurio seleciona o menu de projetos e depois na aba Matriz
de Responsabilidades.
2.
O sistema listas a tabela de responsabilidades previamente
cadastrada no sistema para este projeto (Figura 69).
3.
O usurio clica no boto adicionar e informa o nome da
196
atividade e preenche as 4 colunas com o papel ou usurio responsvel.
4.
O usurio clica no boto salvar
Fluxo: Alternativo
1.
No passo 2, caso no exista tabela previamente cadastrada para
o projeto o sistema exibe a tabela sem registros.
Fluxo: Exceo
1.
No passo 4, o sistema verifica se pela menos uma das aes foi
preenchida, caso no tenha sido envia a mensagem " necessrio
informar pelo menos um usurio responsvel por alguma ao".
Figura 69 - Tela de Matriz de Responsabilidades UC12
9.2.10 - UC13 - REGISTRAR CUSTO DE RECURSOS DO

PROJETO
O custo de um projeto de software tem vrios alicerces mas o
que certamente mais impacta no projeto custo relacionado a mo de
197
obra. Com base nessa informao possvel calcular tanto o custo total
do projeto, quanto custo atual no momento da medio.
Este caso de uso responsvel por criar uma interface onde
deve ser possvel informar o valor/hora de cada papel assumido dentro
de um projeto por um perodo determinado.
1.
Fluxo: Base
O usurio seleciona qual cadastro de usurio que deseja alterar.
2.
O sistema a lista de valor hora cadastradas para o usurio
(Figura 70).
3.
O usurio informa a data incio de vigncia, data fim de
vigncia e taxa padro.
4.
Fluxo: Alternativo
1.
No passo 3, o usurio pode no informar a data fim de vigncia,
deve informar pelo menos uma taxa padro ou custo por uso e no pode
inserir uma vigncia anteriormente cadastrada no sistema para o mesmo
usurio.
Fluxo: Exceo
198
Figura 70 - Tela de custo de recurso UC13
9.3 TERMO DE CONSENTIMENTO DO QUESTIONRIO
Termo de consentimento livre e esclarecido

Considerando as determinaes da Comisso de tica em Pesquisa
com Seres Humanos da UFSC,convidamos o Sr. a participar de nossa
avaliao do modelo para realizao de monitoramento e controle de
projetos, implementado na ferramenta de gerenciamento de projetos
dotProject.
Esta pesquisa faz parte da dissertao de mestrado do aluno Andr
Marques Pereira sob a coordenao da Prof. Dr. rer. nat. Christiane
Gresse von Wangenheim, PMP no GQS - Grupo de Qualidade de
Software do INCoD - Instituto Nacional de Convergncia Digital
(http://
www.incod.ufsc.br).
Dentro
desse
contexto,
estamos
199
convidando voc, como especialista na rea de gerenciamento de
projetos para avaliar nosso trabalho.
O objetivo desse survey avaliar a aderncia desse modelo no cenrio
de Micro e Pequenas Empresas (MPE), seu alinhamento ao CMMI e
PMBOK juntamente com as funcionalidades criadas na ferramenta
para este fim.
Para realizar a tarefa de avaliao foi desenvolvido um manual
resumido do modelo incluindo os processos em alto-nvel e uma
descrio da evoluo do dotProject. Para guiar a sua avaliao da
ferramenta dotProject definimos um cenrio onde sero efetuadas
algumas etapas do monitoramento e controle que voc pode realizar
para entender melhor as novas funcionalidades desenvolvidas no
dotProject. Ao todo esta atividade no deve levar mais de 30 minutos
do seu tempo. Sua participao nesta pesquisa totalmente voluntria.
As
informaes
que
coletarmos
neste
questionrio
sero
compartilhadas apenas em forma acumulada, no permitindo a

identificao de respostas individuais.
Os resultados desta investigao sero utilizados para melhorar o
modelo proposto e a ferramenta de suporte, bem como para dirigir
pesquisas futuras. Os resultados sero divulgados como parte de
dissertao de mestrado e publicaes cientificas. Ser mantido o
anonimato da procedncia dos participantes e as informaes coletadas
sero utilizadas exclusivamente para o desenvolvimento do trabalho.
De acordo com o esclarecido, ao responder esse questionrio o

Sr.
est
aceitando
colaborar/participar
da
avaliao
estando
200
devidamente informado sobre a natureza da avaliao, objetivos
propostos e metodologia utilizada.
9.4 AVALIAO REALIZADA PELOS ESPECIALISTAS
Abaixo seguem as respostas na integra da pesquisa realizada

com os especialistas.
9.4.1 - OBJETIVO 1
1.1 Considero o modelo genrico de processo adequado para

realizar o monitoramento e controle em MPEs.
1 - discorda totalmente 0 0%
2
0 0%
3
0 0%
4
6 50%
5 - concorda totalmente 6 50%
1.2 Considero o modelo genrico de processo para o monitoramento e

controle consistente.
2
0 0%
3
1 8%
4
5 42%
201
1.3 Considero o modelo genrico de processo completo para realizar o
monitoramento e controle.
2
0 0%
3
2 17%
4
5 42%
9.4.2 - OBJETIVO 2
2.1 Considero a evoluo do dotProject til para registrar o
envolvimento dos stakeholders no projeto.
2
0 0%
3
1 8%
4
4 33%

monitoramento de cronograma do projeto.
2
0 0%
3
0 0%
4
2 17%
202
monitoramento de custo do projeto.
2
0 0%
3
0 0%
4
3 25%

monitoramento de qualidade do projeto.
2
0 0%
3
0 0%
4
6 50%
2.5 Considero a evoluo do dotProject til para registrar e acompanhar

aes corretivas.
2
0 0%
3
1 8%
4
6 50%
203
2.6 Considero a evoluo do dotProject til para registrar reunies
referentes ao projeto.
2
0 0%
3
0 0%
4
3 25%
2.7 Considero a evoluo do dotProject til para exibir gerncia snior

a situao atual dos projetos da empresa.
2
0 0%
3
1 8%
4
3 25%
2
0 0%
3
0 0%
4
8 67%
204
2.9 A evoluo do dotProject est adequada para suportar
monitoramento e controle em MPE.
2
0 0%
3
2 17%
4
5 42%
9.4.3 - OBJETIVO 3
3.1 Quantos anos de experincia voc possui com gerenciamento de
projetos?
Especialista
Anos
10
15
10
11
12
12
3.2 Quais so os principais pontos fortes que voc observou?

Acredito que os principais pontos fortes esto relacionados a
visualizao grfica do monitoramento de custos e
205
monitoramento do cronograma, pois facilita o entendimento de

desvio de prazo e custo no projeto. Outro ponto a destacar a
possibilidade do controle de qualidade por tarefa do projeto,
possibilitando o registro de possveis erros individualmente por
tarefa e ainda visualizao de forma grfica dos apontamentos.
Facilidade de uso.
Clareza das informaes apresentadas.
1. Boa contextualizao amarrando CMMI e PMBOK;
2. Interessante o uso de um projeto real para demonstrar a
utilizao do sistema;
3. Bem explicado com telas demonstrando passo a passo dos
requisitos apresentados;
Funcionalidade para monitorar o cronograma e custos, muito
til.
Registro de aes corretivas, e seu acompanhamento atravs
das atas de reunies.
Anlise de valor agregado, linha de base e atas de reunies.
A simplicidade como se aplica as implementaes no
dotProject.
As funcionalidades desenvolvidas agregaram valor a
ferramenta, sem alterar os mdulos original.
Muito interessante a anlise de valor agregado
O gerenciamento de projetos em MPEs passar por uma
variao muito grande de cenrio, desde metodos agis at
processos formais. O modelo proposto, ao me entender, ilustra
bem o ambiente das micro e pequenas empresas e pode servir
de referncia para melhor organizar o que deve ser monitorado
pela utilizao das denominadas UBPs.
Anlise de valor agregado
No possuo tanta experincia em gerenciamento de projetos,
mas pelo que tenho estudado e observado, este modelo um
suporte completo a MPEs, auxiliando muito o monitoramento
de praticamente todo o processo de desenvolvimento de
software. Alm disso, elimina ou diminui grandes falhas/erros
que acompanham muitos projetos.
- Diversos tipos de atas de reunio pr-definidas;
- Registro de Baselines do projeto;
- Definio do custo de um usurio em um intervalo de datas;
- Compatvel com a verso atual do dotProject."
206
3.3 Quais so as principais sugestes de melhoria?
Entendo que quanto ao modelo como o foco so MPEs, acho
que seria importante simplificar, pois entendo que o mesmo
ainda seria de dficil implantao para esse tipo de empresa.
Nesse sentido, a minha sugesto seria reavaliar principalmente
o fluxo que define reunies com gerencia e equipe, talvez esse
tipo de reunio possas ser unficada e consequentemente os
processos desdobrados a partir delas tambm seriam.
Quanto a ferramenta a principal sugesto seria em relao a

rea de qualidade, como a ferramenta permite registrar os erros
e problemas de qualidade e tambm as aes corretivas a serem
realizadas, acho que seria importante possibilitar o vinculo das
aes corretivas, com os problemas de qualidade, pois os
problemas de qualidade em sua grande maioria devem gerar
aes corretivas. Dessa forma, seria possvel medir prazo e
custo necessrio para resolver os problemas de qualidade
Melhoria na Gesto de Riscos na seo de Monitoramento e
Controle:
1. Incluir anlise qualitativa e quantitativa
2. Incluir avaliao peridica da reduo de riscos do projeto,
mediante aes tomadas, relacionadas ao registro em ata e
associada matriz de responsabilidade.
1. Por ser um documento digital, acho interessante incluir
videos demonstrando a utilizao nas novas funcionalidades da
ferramenta (facilitando a didtica);
2. A abordagem das funcionalidades descreve itens sem ter um
roteiro (ou mapa) do que seria abordado. Talvez um
fluxograma da apresentao descrevendo os pontos abordados
no manual contribuiria para o entendimento;
O modelo no deixa claro o que ser avaliado e monitorado:
custos, qualidade, escopo, tempo, comunicao, recursos
humanos etc.
Na aplicao do modelo na ferramenta, a separao do que est
sendo monitorado fica melhor definido.
O monitoramento da qualidade aparentemente um pouco
superficial. Talvez fosse possvel incluir no monitoramento da
207
qualidade a trplice restrio (qualidade em funo do tempo,

custo, escopo) .
A implementao tambm um ponto de elogios, mas algumas
funcionalidades poderiam ser melhor elaboradas unificando
alguns
processos e telas.
A princpio, nada lgico ou funcional, apenas mudana visual e
de organizao das funcionalidades.
- Seria interessante adicionar uma tela de acompanhamento de
todas as aes corretivas, independente de projeto;
- Alterar o mdulo de Grfico de Gantt para possibilitar a
comparao com uma das linhas de base;
- Adicionar s atas: responsvel pela elaborao da ata
(selecionar um usurio)
- Enviar a ata por e-mail automaticamente para todos os
participantes;
- Nas abas Cronograma e Custo, exibir o nome da linha de base
no combo e no somente a verso;
3.4 Mais algum outro comentrio?

Assim como descreve o modelo, as aes corretivas podem ser
criadas simultaneamente com a ata de reunio de
monitoramento. Entretanto na ferramenta, precisamos criar s
aes corretivas em um momento posterior a criao da ata.
Projeto muito interessante tendo em vista que pequenas
empresas no precisar aplicar todas as tcnicas de
Gerenciamento de Projetos.
Muito interessante embasar o desenvolvimento em um modelo
de referncia
Interessante como as ferramentas livres realmente no criar
seus recursos tomando como base alguma referncia
Muito bom
- A listagem das atas aparentemente apresenta problemas de set
de caracteres, no exibindo " " no navegador Chrome.*

Trabalho Sobre Cmmi

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Trabalho Sobre Cmmi

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDADE FEDERAL DE SANTA CATARINA

PROGRAMA DE PS-GRADUAO EM CINCIA DA

Andr Marques Pereira

MONITORAMENTO E CONTROLE DE PROJETOS DE

Andr Marques Pereira

MONITORAMENTO E CONTROLE DE PROJETOS DE

Dissertao submetida Universidade

Ficha de identificao da obra elaborada pelo autor,

Pereira, Andr Marques

Andr Marques Pereira

MONITORAMENTO E CONTROLE DE PROJETOS DE

Esta Dissertao foi julgada adequada para obteno do Ttulo de

A Deus, por ter ajudado a trilhar esse caminho.

"You cant connect the dots

connect them looking backwards"

Muitas empresas falham no desenvolvimento de seus projetos e muito

consequentemente aumentar o nvel de qualidade almejado. Entretanto

Palavras-chave: Gerenciamento de Projetos; PMBOK; CMMI;

Keywords: Project Management; PMBOK; CMMI; Open-Source

FIGURA 7 - FLUXO DE ATIVIDADES DE MONITORAMENTO E CONTROLE ....................... 49

FIGURA 25 EXEMPLO 2 DE DASHBOARD ........................................................... 80

FIGURA 36 - NVEIS DE MODELAGEM NA ARQUITETURA DE QUATRO CAMADAS DA UML

FIGURA 49 - MEDIDA 11 - INDICADOR DE REJEIO............................................. 173

TABELA 3 - CUSTOS FIXO DO PROJETO PIZZARIA DO CHICO ...................................... 46

TABELA 24 - CASO DE USO MATRIZ DE RESPONSABILIDADES .................................. 195

LISTA DE ABREVIATURAS E SIGLAS

CEPSH - Comit de tica em Pesquisa com Seres Humanos

Pergunta de pesquisa ................................................27

Objetivos Gerais ...............................................27

Objetivos Especficos .......................................27

Escopo e delimitao do trabalho .....................28

Conceitos Fundamentais ...................................................36

Gerncia de Projetos ................................................36

Processo de Monitoramento e Controle (PMC-

Project monitoring & control) ......................................................42

Modelos de Melhoria de Processos ..........................84

Micro e Pequenas Empresas.....................................95

Mapeamento PMBOK-CMMI .................................96

Trabalhos Correlatos ................................................99

Seleo das ferramentas ................................................. 101

Ferramentas Selecionadas ...................................... 106

DotProject ...................................................... 106

PhpCollab ....................................................... 109

Track+ ............................................................ 111

Strebber .......................................................... 112

Resultado da avaliao ........................................... 114

Modelo Genrico de Processo para PMC ....................... 116

processo de referncia ............................................ 116

Passo 1 - Coleta de dados ............................... 118

Passo 2 - Analisar e Visualizar ....................... 120

Passo 3 - Interpretar e Comunicar .................. 120

Passo 4 - Verificar Questes .......................... 124

Passo 5 - Gerenciar aes corretivas .............. 124

Passo 6 - Replanejar ....................................... 124

Definio do Meta Modelo .................................... 125

Definio do Modelo Genrico de Processo .......... 127

MC01 - Planejar a Monitorao ..................... 129

MC02 - Coletar Dados ................................... 130

MC03 - Analisar os Dados ............................. 131

MC04 - Realizar Reunio de Monitorao

MC05 - Realizar Reunio de Monitorao com

Gerncia Snior 134

Aprimoramento da Ferramenta....................................... 137