EngSoft PDF

Instituto de Informtica
Programa de Ps-Graduao Stricto Sensu
Estudo comparativo de metodologias de

gerenciamento de processos de desenvolvimento de
sistemas de informao
Anderson Luiz Barbosa
Dissertao desenvolvida sob orientao do

Professor Doutor Waldomiro Pelgio Diniz de
Carvalho Loyolla e apresentada ao Instituto de
Informtica da Pontifcia Universidade
Catlica de Campinas como requisito final
para obteno do ttulo de Mestre em
Informtica.
rea
de
concentrao:
Gerenciamento de Sistemas de Informao.
Campinas, 2000
PONTIFCIA UNIVERSIDADE CATLICA DE CAMPINAS
GRO-CHANCELER
Dom Gilberto Pereira Lopes
MAGNFICO REITOR
Prof. Pe. Jos Benedito de Almeida David
VICE-REITOR PARA ASSUNTOS ADMINISTRATIVOS

Prof. Jos Francisco B. Veiga Silva
VICE-REITOR PARA ASSUNTOS ACADMICOS

Prof. Carlos de Aquino Pereira
DIRETOR DO INSTITUTO DE INFORMTICA

Prof. Orandi Mina Falsarella
COORDENADOR DO PROGRAMA DE PS-GRADUAO STRICTU SENSU DO

INSTITUTO DE INFORMTICA
Prof. Dr. Waldomiro Pelgio Diniz de Carvalho Loyolla

Dissertao defendida e aprovada em 26 de junho de 2000 pela

Comisso Examinadora constituda pelos seguintes professores: Dr.
Waldomiro Pelgio Diniz de Carvalho Loyolla, Orientador e Presidente
da Comisso Examinadora, Instituto de Informtica, PUC-Campinas;
Dr. Leonel Mazzali, UNESP; Dr. Mrcio Luiz de Andrade Netto,
Instituto de Informtica, PUC-Campinas.
Barbosa, Anderson Luiz, 1967

B238e
Estudo comparativo de metodologias de gerenciamento de processos

de desenvolvimento de sistemas de informao / Anderson Luiz Barbosa. Campinas, PUC-Campinas, 2000.
XV, 124p. il.
Orientador: Waldomiro Pelgio Diniz de Carvalho Loyolla.
Dissertao (Mestrado) Pontifcia Universidade Catlica de
Campinas, Instituto de Informtica
Inclui anexos e bibliografia.
1. Gerenciamento da informao. 2. Sistemas de informao. 3.
Engenharia de software. I. Loyolla, Waldomiro Pelgio Diniz de Carvalho.
II. Pontifcia Universidade Catlica de Campinas, Instituto de Informtica.
III. Ttulo.
20.ed. CDDt658.4038
Dedicatria
A Deus, o criador, pela ddiva da existncia.

A Dbora e Thiago, que do sentido esta existncia, pelo
apoio, carinho e pacincia que tiveram durante o perodo
deste mestrado.
Agradecimentos
A Jos Milton, Margarida, Maria, derson, Mrcia, Cristina,

Edmar, Tereza, Jos Carlos, Daniela, enfim a toda minha
famlia, pelo incentivo constante;
Ao professor Doutor Waldomiro Loyolla pelo
apoio e dedicao;
Aos estimados professores e funcionrios do mestrado
pela convivncia e troca de experincia;
Promon e aos meus colegas de trabalho pela grande
escola de aprendizado contnuo;
Aos colegas professores, alunos e funcionrios do Centro UniSal
pela oportunidade de crescermos juntos.

RESUMO
Padres internacionais de gerenciamento de projeto (como o PMBoK Guide e a ISO 10006)
esto sendo adotados pelas empresas ao redor do mundo; profissionais vm sendo
capacitados para exercer a funo de gerentes de projetos nas mais diversas reas de
atividades. Mundialmente existe a preocupao com o gerenciamento adequado destes
diversos projetos a fim de garantir o atendimento s expectativas dos envolvidos e a
otimizao dos recursos alocados. Na rea de software, as preocupaes esto cada vez
maiores com relao a custos, prazos e qualidade em projetos de desenvolvimento de
sistemas de informao, forando um repensar nas prticas at ento utilizadas para o
gerenciamento destes processos. O presente trabalho aborda as tcnicas de engenharia de
software que vm sendo aplicadas ao desenvolvimento de projetos, constatando que na
maior parte das vezes so enfocados apenas os aspectos tcnicos; apresenta tambm uma
descrio dos padres de qualidade de uso genrico (como as normas ISO 9000) que vm
sendo utilizados por empresas que desenvolvem software, e descreve a utilizao de
modelos de qualidade especificamente desenvolvidos para informtica, como o CMM e o
PSP. A partir dos resultado da comparao entre os modelos de qualidade e os modelos de
gerenciamento de projetos, apresentada uma proposta para otimizao do gerenciamento
de processos de desenvolvimento de sistemas de informao, descrevendo a contribuio
de cada um destes modelos, alm das adaptaes necessrias a fim de contemplar os
aspectos especficos de software.
PALAVRAS-CHAVE
Gerenciamento de projetos, Sistemas de Informao, Engenharia de Software,
Gerenciamento de escopo, Gerenciamento da qualidade, Gerenciamento de prazos e custo.
Comparative study about project management

frameworks for the information systems
development process
SUMMARY
International standards of project management (like PMBoK Guide and ISO 10006) have
been used by companies around the world; professionals have been qualified to exercise
the project management function in most areas of activities. A global concern exists for the
appropriate administration of these several projects in order to achieve the expectations of
those involved. On the software area, the concern is bigger when related to costs, time and
quality in information systems development. This forces to rethink the practices used on the
administration of these processes. This work addresses the techniques of software
engineering that are being applied to the development of projects, verifying that most of
the time spent is just focused on the technical aspects; it also presents a description of the
patterns of quality for generic use (as the norms ISO 9000) that also have been used by
companies that develop software, and it specifically describes the use of quality models
developed for computer science, like CMM and PSP. A proposal is presented for
optimizing the management of information systems development processes, describing the
contribution provided by each one of these models, together with the necessary adaptations
in order to contemplate the specific aspects of software.
KEY WORDS
Project Management, Information System, Software Engineering, Scope Management,
Quality Management, Time and Cost Management.
SUMRIO
XIII
SUMRIO
1. INTRODUO.....................................................................................1
1.1. O problema do gerenciamento de projetos .....................................1
1.2. Estrutura da dissertao.................................................................3
2. GERENCIAMENTO DE PROJETOS..................................................6
2.1. Conceituao...................................................................................6
2.1.1. Conceito de projeto........................................................................................ 6
2.2. Organizaes/associaes................................................................7
2.2.1. PMI - Project Management Institute............................................................. 7
2.2.2. SEI - Software Engineering Institute............................................................. 8
2.2.3. ISO - International Organization for Standardization .................................. 9
2.2.4. Outras organizaes..................................................................................... 11
3. DESENVOLVIMENTO DE SOFTWARE...........................................13
3.1. Conceito ........................................................................................13
3.2. Histrico........................................................................................13
3.3. Engenharia de software.................................................................15
3.3.1. Paradigmas da engenharia de software........................................................ 17
3.3.1.1. Ciclo de vida clssico.................................................................... 17
3.3.1.2. Ciclo de vida de prototipao ....................................................... 19
3.3.1.3. Ciclo de vida espiral...................................................................... 21
3.3.1.4. Tcnicas de quarta gerao ........................................................... 22
3.3.1.5. Em busca de um novo paradigma ................................................. 24
3.4. Padres de qualidade ....................................................................26

3.4.1. ISO 9000 ...................................................................................................... 26
3.4.1.1. Histrico........................................................................................ 26
3.4.1.2. Caractersticas ............................................................................... 26
3.4.1.3. Elementos padres da ISO 9000 ................................................... 28
XIV SUMRIO
3.4.1.4. ISO 9000-3.....................................................................................31

3.4.2. ISO 9126.......................................................................................................32
3.4.3. ISO 12207, 15271 e 16326 ...........................................................................33
3.4.4. ISO 15504 - SPICE ......................................................................................36
3.4.5. SEI - CMM ...................................................................................................39
3.4.5.1. Histrico ........................................................................................39
3.4.5.2. Conceitos utilizados.......................................................................40
3.4.5.3. Nveis de maturidade em software ................................................41
3.4.5.4. Gerenciamento de software e o CMM ...........................................42
3.4.5.5. Estrutura do CMM .........................................................................44
3.4.5.5. Adoo do CMM pelas empresas ..................................................49
3.4.6. PSP - Personal Software Process ................................................................50
4. PADRES DE GERENCIAMENTO DE PROJETOS.......................52

4.1. ISO 10006......................................................................................52
4.2. PMBoK Guide ...............................................................................55
4.2.1. Apresentao ................................................................................................55
4.2.2. Contexto do gerenciamento de projetos.......................................................56
4.2.2.1. Ciclos de vida ................................................................................56
4.2.2.2. Estruturas organizacionais .............................................................57
4.2.3. Descrio do processo de gerenciamento de projetos ..................................60
4.2.3.1. Processos de Incio ........................................................................61
4.2.3.2. Processos de Planejamento ............................................................62
4.2.3.3. Processos de Execuo ..................................................................64
4.2.3.4. Processos de Controle ....................................................................66
4.2.3.5. Processos de Encerramento ...........................................................67
4.2.4. reas do gerenciamento de projetos.............................................................67
4.2.4.1. Gerenciamento de integrao ........................................................69
4.2.4.2. Gerenciamento de escopo ..............................................................69
4.2.4.3. Gerenciamento de tempo ...............................................................69
4.2.4.4. Gerenciamento de custo.................................................................69
4.2.4.5. Gerenciamento da qualidade do processo......................................69
4.2.4.6. Gerenciamento dos recursos humanos...........................................70
4.2.4.7. Gerenciamento das comunicaes.................................................70
4.2.4.8. Gerenciamento do risco .................................................................70
SUMRIO
XV
4.2.4.9. Gerenciamento de suprimentos..................................................... 70
5. ANLISE COMPARATIVA...............................................................72
6. CONCLUSO .....................................................................................79
6.1. Sugestes para Futuros Trabalhos................................................81
ANEXOS .................................................................................................82
ANEXO A - reas de conhecimento do gerenciamento de projetos....82
A.1. Gerenciamento de integrao......................................................................... 82
A.1.1. Grupo de processos 4.1. Desenvolver plano do projeto.................. 82
A.1.2. Grupo de processos 4.2. Executar plano de projeto........................ 83
A.1.3. Grupo de processos 4.3. Controlar mudanas................................. 84
A.2. Gerenciamento de escopo .............................................................................. 85
A.2.1. Grupo de processos 5.1. Iniciar....................................................... 86
A.2.2. Grupo de processos 5.2. Planejar escopo........................................ 86
A.2.3. Grupo de processos 5.3. Definir escopo ......................................... 87
A.2.4. Grupo de processos 5.4. Verificar escopo....................................... 88
A.2.5. Grupo de processos 5.5. Controlar mudanas de escopo................ 89
A.3. Gerenciamento de tempo ............................................................................... 89
A.3.1. Grupo de processos 6.1. Definir atividades .................................... 89
A.3.2. Grupo de processos 6.2. Seqenciar atividades .............................. 91
A.3.3. Grupo de processos 6.3. Estimar durao das atividades ............... 92
A.3.4. Grupo de processos 6.4. Desenvolver acompanhamento................ 93
A.3.5. Grupo de processos 6.5. Controlar acompanhamento..................... 94
A.4. Gerenciamento de custo................................................................................. 95
A.4.1. Grupo de processos 7.1. Planejar recursos...................................... 95
A.4.2. Grupo de processos 7.2. Estimar custos.......................................... 95
A.4.3. Grupo de processos 7.3. Orar custos ............................................. 97
A.4.4. Grupo de processos 7.4. Controlar custos....................................... 98
A.5. Gerenciamento da qualidade do processo...................................................... 99
A.5.1. Grupo de processos 8.1. Planejar qualidade ................................. 100
A.5.2. Grupo de processos 8.2. Garantir qualidade ................................. 100
A.5.3. Grupo de processos 8.3. Controlar qualidade ............................... 101
A.6. Gerenciamento dos recursos humanos......................................................... 102
A.6.1. Grupo de processos 9.1. Planejar organizao.............................. 102
XVI
SUMRIO
A.6.2. Grupo de processos 9.2. Aquisio de pessoal..............................104

A.6.3. Grupo de processos 9.3. Desenvolver time....................................104
A.7. Gerenciamento das comunicaes................................................................105
A.7.1. Grupo de processos 10.1. Planejar comunicao...........................105
A.7.2. Grupo de processos 10.2. Distribuir informaes..........................107
A.7.3. Grupo de processos 10.3. Reportar desempenho ...........................107
A.7.4. Grupo de processos 10.4. Encerrar projeto....................................108
A.8. Gerenciamento do risco ....................................................................109
A.8.1. Grupo de processos 11.1. Identificar risco ....................................109
A.8.2. Grupo de processos 11.2. Quantificar riscos .................................110
A.8.3. Grupo de processos 11.3. Desenvolver resposta aos riscos...........111
A.8.4. Grupo de processos 11.4. Controlar resposta aos riscos................113
A.9. Gerenciamento de suprimentos ....................................................................113
A.9.1. Grupo de processos 12.1. Planejar suprimentos............................113
A.9.2. Grupo de processos 12.2. Planejar cotaes ..................................115
A.9.3. Grupo de processos 12.3. Solicitaes...........................................115
A.9.4. Grupo de processos 12.4. Selecionar fornecedores .......................116
A.9.5. Grupo de processos 12.5. Administrar contratos...........................116
A.9.6. Grupo de processos 12.6. Encerrar contratos ................................117
REFERNCIAS BIBLIOGRFICAS.................................................. 118
NDICE DE FIGURAS
XVII
NDICE DE FIGURAS
FIGURA 1 - Projetos de Tecnologia de Informao - % de Sucessos e Fracassos...........2
FIGURA 2 - Ciclo de vida clssico.................................................................................18
FIGURA 3 - Prototipao................................................................................................20
FIGURA 4 - Modelo espiral............................................................................................21
FIGURA 5 - Tcnicas de quarta gerao ........................................................................23
FIGURA 6 - Combinando paradigmas............................................................................25
FIGURA 7 - Padres ISO 9000.......................................................................................28
FIGURA 8 - Processos e vises da ISO 12207 ...............................................................36
FIGURA 9 - Viso geral da estrutura do CMM ..............................................................41
FIGURA 10 - Viso gerencial sobre a visibilidade do processo de software a cada
nvel do CMM.............................................................................................42
FIGURA 11 - Capacidade de estimar e medir resultados dos projetos a cada nvel do
CMM ..........................................................................................................43
FIGURA 12 - Componentes de cada nvel do CMM ........................................................45
FIGURA 13 - reas chave de processo para cada nvel do CMM....................................46
FIGURA 14 - Classificao de empresas americanas nos nveis do CMM ......................49
FIGURA 15 - Relacionamento do gerenciamento de projetos com outras disciplinas
de gerenciamento........................................................................................56
FIGURA 16 - Modelo espiral de ciclo de vida de desenvolvimento de sistemas de
informao..................................................................................................57
FIGURA 17 - Gerenciame nto de projetos em uma organizao funcional.......................58
FIGURA 18 - Gerenciamento de projetos em uma organizao orientada para
projetos.......................................................................................................58
FIGURA 19 - Gerenciamento de projetos em organizao matricial...............................59
FIGURA 20 - Relacionamentos entre os grupos de processos de gerenciamento de
projetos.......................................................................................................60
FIGURA 21 - Influncia dos grupos de processos de gerenciamento de projetos ao
longo do ciclo de vida do projeto...............................................................61
FIGURA 22 - Processos de Incio.....................................................................................61
FIGURA 23 - Processos de Planejamento.........................................................................63
FIGURA 24 - Processos de Execuo...............................................................................65
FIGURA 25 - Processos de Controle ................................................................................66
FIGURA 26 - Processos de Encerramento........................................................................67
XVIII NDICE DE FIGURAS
FIGURA 27 - Viso geral dos processos de gerenciamento de projetos por rea de

conhecimento............................................................................................. 68
FIGURA 28 - Viso geral dos processos de gerenciamento de integrao....................... 82
FIGURA 29 - Viso geral dos processos de gerenciamento de escopo ............................ 85
FIGURA 30 - Exemplo de WBS para um projeto ............................................................ 88
FIGURA 31 - Viso geral dos processos de gerenciamento de tempo ............................. 90
FIGURA 32 - Viso geral dos processos de gerenciamento de custo............................... 96
FIGURA 33 - Viso geral dos processos de gerenciamento de qualidade........................ 99
FIGURA 34 - Viso geral dos processos de gerenciamento de recursos humanos......... 103
FIGURA 35 - Viso geral dos processos de gerenciamento da comunicao ................ 106
FIGURA 36 - Viso geral dos processos de gerenciamento do risco ............................. 112
FIGURA 37 - Viso geral dos processos de gerenciamento de suprimentos.................. 114
NDICE DE TABELAS
XIX
NDICE DE TABELAS
TABELA 1 - Nveis ISO 9000 x elementos padres .........................................................29
TABELA 2 - Processos e atividades da ISO 9000-3.........................................................32
TABELA 3 - Elementos da ISO 9126................................................................................33
TABELA 4 - Processos Fundamentais da ISO 12207 .......................................................34
TABELA 5 - Processos Organizacionais da ISO 12207....................................................34
TABELA 6 - Processos de Apoio da ISO 12207...............................................................35
TABELA 7 - Nveis e atividades do modelo SEI-PSP......................................................50
TABELA 8 - Estruturas com diferentes nveis de orientao por projetos .......................59
TABELA 9 - Processos de gerenciamento de projetos agrupados em reas e grupos. .....79
Cap. 1 Introduo
1. INTRODUO
1.1. O problema do gerenciamento de projetos

A demanda pela produo de sistemas de informao tem crescido demasiadamente desde
os primrdios do processamento de dados e surgimento dos computadores, h cerca de 50
anos. Desde ento o nvel de exigncia e complexidade dos sistemas vem evoluindo
medida que novos ambientes, novas plataformas, novas metodologias e um nmero muito
maior de usurios esto envolvidos com estes sistemas.
No incio os sistemas eram operados/manipulados por um conjunto reduzido de pessoas a
complexidade operacional e a tecnologia disponvel eram caras e de difcil acesso.
Informaes oriundas de sistemas de informao computadorizados eram normalmente
acessadas pelos usurios por intermdio de mdia impressa (listagens), com uma
defasagem de tempo (atualizao) grande muitas vezes a informao era referente ao ms
anterior. Hoje a demanda exige informaes atualizadas quase que instantaneamente,
favorecida pelo desenvolvimento de diversas mdias de acesso (disquetes, CD-Rom,
Internet) disponveis a um custo bastante acessvel.
Sistemas de informao que no passado consumiam anos de desenvolvimento com grandes
equipes hoje sofrem presses cada vez maiores de reduo de prazo e custo, sem a reduo
da qualidade e do escopo (pelo contrrio, cada vez aumentam estas exigncias).
Infelizmente a evoluo dos processos de desenvolvimento em especial os de
gerenciamento no acompanharam a evoluo das exigncias dos usurios.
Uma ilustrao bem expressiva de alguns destes problemas pode ser encontrada em
[BROO95]: "Nenhuma cena pr-histrica to marcante quanto o esforo dos grandes
animais atolados nos profundos lodaais. Imaginamos ver os dinossauros, mamutes e
megatrios, lutando para no afundar no pntano. E quanto mais se debatem mais afundam
at desaparecerem, pois nenhum dos animais to forte que, vencendo o lodaal, possa
escapar. A confeco de grandes sistemas tem sido o mortal pntano e grandes e poderosas
foras afundaram inexoravelmente nele. Muitos conseguiram produzir sistemas que
funcionaram, mas poucos atingiram os objetivos e oramentos. Equipe aps equipe,
independente do tamanho ou recursos, afundaram no pntano. E no foi possvel identificar
a causa, descobrir qual o erro e evitar. o somatrio de pequenos fatos simultneos ou
sucessivos que conduziram at o fundo da armadilha. Todos reconhecem a gravidade do
problema mas poucos discernem onde est a causa. A maior parte dos projetos no atingiu
seus objetivos no tempo, mais por falta de calendrios de eventos do que pelas demais
causas juntas". Entende-se por calendrio de eventos um planejamento e acompanhamento
do projeto de desenvolvimento de um software.
Este trecho foi escrito para a primeira edio do referido livro e ainda hoje vlido. A
FIGURA 1 - Projetos de Tecnologia de Informao - % de Sucessos e Fracassos,
comentada em detalhes em [SPEC99], ilustra um panorama entre os sistemas de
informao solicitados pelos usurios e o que realmente foi feito.
Cap. 1 Introduo
Comprometidos
53%
16%
31%
Fracassos
Sucessos
Fonte: Computerworld, Fev 97 / Standish Group
FIGURA 1 - Projetos de Tecnologia de Informao - % de Sucessos e Fracassos

Os dados da figura anterior se referem s empresas norte americanas pesquisadas ao longo
de do ano de 1996. Apesar de no estarem disponveis dados referentes s empresas
brasileiras, acredita-se que a realidade nacional no seja muito diferente da realidade norte
americana o problema na realidade um problema mundial.
Alguns autores procuraram identificar possveis razes para estes problemas relativos ao
desenvolvimento de software. Em [PRES95] so discutidas algumas destas possveis
razes: "gerentes de nvel mdio e superior sem nenhum background 1 em software recebem
a responsabilidade pelo seu desenvolvimento. H um antigo axioma da administrao que
afirma: "um bom gerente pode gerir qualquer projeto". Deveramos acrescentar: "...se ele
estiver disposto a aprender quais os marcos (milestones) que podem ser usados para medir
o processo, aplicar mtodos efetivos de controle, no levar em conta a mitologia e tornar-se
fluente numa tecnologia que se modifica rapidamente". O gerente deve comunicar-se com
todas as pessoas envolvidas no desenvolvimento de software2 - clientes, desenvolvedores
de software, pessoal de apoio e outros. A comunicao pode interromper-se porque as
caractersticas especiais do software e dos problemas associados ao seu desenvolvimento
so mal compreendidas. Quando isso ocorre, os problemas associados crise do software
so exacerbados".
Ainda hoje, perguntas presentes h pelo menos duas dcadas continuam sem resposta ou
com respostas insatisfatrias [PRES95]:
Por que demora tanto tempo para que os programas sejam concludos?
Por que os custos so to elevados?
Por que todos os erros no so descobertos e sanados antes da entrega para o

usurio?
Por que existe a dificuldade em medir o progresso do software enquanto este

est sendo desenvolvido?
Entende-se Background como experincia comprovada atravs de conhecimentos e prticas.
O captulo 2 - Gerenciamento de projetos - comenta em detalhes os envolvidos com o projeto. Corresponde ao conceito
de stakeholders definido pela terminologia do PMI.
Cap. 1 Introduo
Alguns dos fatores presentes na maior parte dos projetos de TI que no tiveram sucesso so
levantados em [FERN92]:
Absoro de inovaes tecnolgicas - introduo de novidades tecnolgicas,

novos ambientes, novas ferramentas - quase sempre causa impactos no
previstos no desenvolvimento do projeto;
Especificao de projetos incompleta - dificuldade em captar os requisitos dos

usurios e transform-los em uma especificao completa e viva (conhecimento
agregado tambm ao longo do projeto);
Metodologias inadequadas - no definio de qual metodologia ser adotada;
Subestimativa de riscos - ausncia de um processo formal de avaliao e

tratamento de riscos;
Dificuldades de estimar prazos e recursos - mtodo normalmente utilizado a

"achologia" ou "chutologia" uma vez que a cultura de estimativas baseadas em
modelos matemticos e registros histricos so adotadas por poucas empresas;
Dificuldade de aferir progresso - falta de marcos concretos e ponderados ao

longo do projeto a fim de verificar o real avano;
Fraco acoplamento entre as estratgias empresariais e as de TI - priorizao dos

projetos de TI no est normalmente convergente com as diretrizes da empresa,
o que normalmente se traduz em problemas;
Cultura das organizaes - [NOLA77] define e caracteriza empresas de acordo

com seu estgio na curva de aprendizado; para as empresas que esto no incio
desta curva (a grande maioria), o desafio do gerenciamento de projetos
extenuante, haja vista a omisso por parte dos usurios no seu envolvimento
requerido pelo projeto - eles pensam que isto o negcio dos profissionais de
TI e no deles;
Ambiente tpico de desenvolvimento de projetos - falta de instrumentos,

excesso de presso por parte dos usurios ("prazos para ontem"), falta de
instrumentos de motivao para o pessoal envolvido no projeto e outros fatores
relacionados.
A presente dissertao verifica o porque destas estatsticas to pouco favorveis produo

de sistemas de informao e propem algumas medidas gerenciais, baseadas nos conceitos
de gerenciamento de projetos to bem utilizados em outras reas da cincia e tecnologia,
que poderiam tornar o desenvolvimento de sistemas de informao um processo
controlvel.
1.2. Estrutura da dissertao

O presente trabalho est divido em cinco captulos, com as seguintes caractersticas:
O presente captulo - Captulo 1 - Introduo - visa apresentar os problemas existentes no
gerenciamento do processo de desenvolvimento de software. Apresenta um panorama geral
das origens do problema e demonstra o estgio atual nesta questo.
Cap. 1 Introduo
O Captulo 2 - Gerenciamento de projetos - apresenta uma viso geral do universo do

gerenciamento de projetos, as principais organizaes mundiais e nacionais que produzem
material sobre este tema, direta ou indiretamente. So apresentados os conceitos
tradicionais de gerenciamento de projetos e introduzido o grande questionamento:
gerenciar projetos de tecnologia de informaes da forma como so gerenciados os
projetos em outras reas pode trazer benefcios significativos? A presente dissertao
pretende responder a esta pergunta.
Dentre as organizaes que tratam o tema gerenciamento de projetos foram selecionadas as
seguintes:
PMI - Project Management Institute - principal organizao mundial sobre

gerenciamento de projetos;
SEI - Software Engineering Institute - um dos principais organismos mundiais

que trata de forma profissional o tema desenvolvimento de software;
ISO - International Organization for Standardization - um dos mais tradicionais

organismos internacionais existentes, tendo por misso padronizar os aspectos
do desenvolvimento de produtos e garantias de sua qualidade.
Existem outras inmeras organizaes que poderiam ser mencionadas, incluindo as

brasileiras Fundao Vanzolini, FGV, diversas universidades, dentre outras, que tambm
tm preocupaes constantes com os temas aqui abordados. Seria impossvel mencionar
todas sem esquecer de alguma. O objetivo maior conhecer um pouco mais as principais
organizaes produtoras de material cientfico/tecnolgico que podem auxiliar a melhorar
a efetividade dos processos relacionados ao desenvolvimento de software.
O Captulo 3 - Desenvolvimento de software - procura definir software enquanto produto e
apresentar o histrico da evoluo de seu desenvolvimento, desde seu surgimento como
produto at os presentes dias e as perspectivas futuras. Uma viso geral da disciplina
engenharia de software tambm apresentada, englobando os ciclos de vida dos sistemas
de informao e algumas abordagens tradicionalmente utilizadas.
Tambm so discutidos os modelos da ISO e do SEI (este desenvolvido especificamente
para software) que visam garantir a qualidade, a padronizao e o aperfeioamento dos
processos produtivos.
O Captulo 4 - Padres de gerenciamento de projetos apresenta o modelo proposto pela
ISO e o modelo de gerenciamento de projetos proposto pelo PMI, suas principais
caractersticas e preocupaes; o modelo do PMI o PMBoK Guide - a base para a
verificao da hiptese de que a aplicao dos conceitos de gerenciamento de projetos
utilizados com sucesso em empreendimentos de diferentes reas pode ser um grande fator
de evoluo para a conduo de projetos de tecnologia de informao.
O Captulo 5 - Anlise comparativa - tem por objetivo verificar os ganhos advindos da
utilizao do PMBoK como modelo de gerenciamento de projetos de tecnologia de
informao, bem como verificar possveis adaptaes em funo das caractersticas
peculiares dos projetos de software (a comear pelo prprio conceito de projeto discutido
no captulo 4). Tambm discutida a utilizao de documentos padronizados e adaptados,
ora propostos pelo PMBoK, ora propostos pelas abordagens de desenvolvimento de
software, ora propostos pelos modelos de qualidade, tanto da ISO quanto do SEI,
confrontados com a experincia acumulada do autor na coordenao de diversos softwares
comerciais, tanto para uso interno de uma organizao quanto para implementaes em
outras organizaes, e na rea acadmica, onde leciona disciplinas relacionadas a
Cap. 1 Introduo
engenharia de software, gerenciamento de projetos e anlise e projeto de sistemas de

informao.
Concluindo a dissertao, o Captulo 6 - Concluso - apresenta uma sntese dos temas
estudados e das concluses oriundas das anlises comparativas efetuadas. Espera-se que
estas concluses possam servir para melhorar os problemas descritos no captulo
introdutrio e que sirvam de inspirao para novos trabalhos; certamente este tema no
ser esgotado to cedo e diversos trabalhos podero ser realizados visando a melhoria
contnua dos processos relacionados a software.
O Anexo A - reas de conhecimento do gerenciamento de projetos apresenta todas as
reas de conhecimento do gerenciamento de projetos reconhecidas pelo PMI, discutindo
seus principais processos, entradas e produtos.
Cap. 2 Gerenciamento de Projetos
2. GERENCIAMENTO DE PROJETOS
2.1. Conceituao
Segundo [PMIS96], gerenciamento de projetos a aplicao de conhecimentos,
habilidades, ferramentas e tcnicas no sentido de concluir atividades que atendam ou
excedam s necessidades e expectativas dos stakeholders3 deste projeto. A fim de atingir
estes objetivos, algumas questes devem ser atentamente observadas:
Escopo - tudo o que deve ser produzido neste projeto
Prazos - ordem cronolgica dos resultados/produtos deste projeto
Custo - valor para a produo deste projeto
Qualidade - tanto do processo de conduo quanto dos produtos gerados pelo

projeto
Diferentes necessidades e expectativas dos stakeholders
Separar o que necessidade (requisito) de expectativa (requisito ainda no

identificado)
2.1.1. Conceito de projeto

As organizaes e as pessoas realizam trabalhos que devem ser gerenciados. Estes
trabalhos podem ser categorizados em operaes e projetos, embora existam diversas
caractersticas em comum:
So realizados por pessoas
Utilizam recursos
Devem ser planejados, executados e controlados
Enquanto as operaes so processos contnuos, os projetos se caracterizam por serem

temporrios e nicos. Desta forma tem-se uma primeira definio de projeto: " um
empreendimento temporrio - com incio e trmino bem definidos - cujo objetivo criar
um produto ou oferecer um servio nico, distinto de todos os produtos ou servios
produzidos anteriormente".[PMIS96]
33
Stakeholders um termo amplamente utilizado no universo de gerenciamento de projetos e usualmente sua grafia em
ingls a mais utilizada. Significa todos os envolvidos com um determinado projeto (cliente, equipe do projeto,
patrocinadores, governo e outros). Em funo de no haver consenso quanto a uma traduo que seja aceita por toda a
comunidade (alguns autores traduzem como interessados outros como envolvidos) adotou-se na presente dissertao a
terminologia original em ingls. Est sendo desenvolvido pelo captulo So Paulo do PMI um padro para traduo
para o portugus destes termos em ingls.
Cap. 2 Gerenciamento de Projetos 7
Projetos podem variar quanto suas dimenses, podem envolver uma nica organizao ou
diversas organizaes (formando consrcios, parcerias ou outro tipo de associao). Como
exemplos de projetos tem-se:
Desenvolvimento de um novo produto ou servio
Implementaes de mudanas em uma organizao
Desenvolvimento de um novo meio de transporte
Desenvolvimento de um sistema de informao 4
Implementao de um novo processo de negcio
O conceito de temporalidade em projetos fundamental. Deve ser claramente determinado

o incio e o fim no sentido de serem identificados os objetivos. Isto vital a fim de que seja
possvel determinado se um projeto est concludo (atingiu seus objetivos) ou ainda se
impossvel de se concluir. No necessariamente este limite pequeno, haja visto existirem
projetos com duraes de vrios anos (por exemplo a implantao de uma usina nuclear).
Ainda utilizando o exemplo acima, o projeto para a implantao de uma usina nuclear
termina assim que a mesma esteja com todas as condies de incio de funcionamento. A
partir deste ponto o projeto est concludo e entra na fase de operao.
2.2. Organizaes/associaes
Existem diversas organizaes mundiais e nacionais que agregam profissionais
preocupados com as questes envoltas no gerenciamento de projetos e de operaes.
Podem ser destacadas as seguintes organizaes:
2.2.1. PMI - Project Management Institute

Fundado em 1969, o PMI (Project Management Institute http://www.pmi.org) uma
associao internacional sem fins lucrativos que tem como principais objetivos:
Avanar o estado da arte na prtica da gesto de projetos
Fomentar o profissionalismo na gesto de projetos
Promover a aceitao da gesto de projetos como profisso e disciplina
Esta associao possui atualmente em torno de 50.000 membros em todo o mundo,

divididos em 122 captulos (onde so discutidos temas mais especficos) em 37 pases (o
Brasil possui alguns captulos em So Paulo (hppt://www.fea.usp.br/programas/pmi-sp),
em Belo Horizonte (http://www.pmimg.org.br) e no Rio de Janeiro). Destes diversos
captulos so extradas contribuies que so consolidadas no chamado guia PMBoK
(corpo de conhecimento do gerenciamento de projetos), guia com as best practices nesta
disciplina; este guia visa consolidar padres (fases de um empreendimento,
responsabilidades), alm de propor uma abordagem universal s diversas reas de
4
Objeto principal deste trabalho.
conhecimento no gerenciamento de projetos. O tpico 4.2. - PMBoK Guide - discute em

detalhes este guia, que um dos alicerces desta dissertao.
Outra preocupao do PMI com o processo de profissionalizao dos profissionais que
lidam com o gerenciamento de projetos. Para tanto, esto sendo feitos nos diversos pases
exames de certificao onde so verificados os conhecimentos e a experincia dos
profissionais, baseados nas prticas do PMBoK. No dia 13 de junho de 1998 foi realizado
no Brasil o primeiro exame para PMP (Project Management Professional), contando com
a participao de 33 pessoas. At dezembro de 1998 existiam 10.125 PMP no mundo
[PLON98]. Estima-se que nos prximos anos as grandes empresas passaro a exigir de
seus profissionais de gerenciamento esta certificao.
O PMI tambm agrega diversos grupos de interesses para vrias reas de negcio. Para
este trabalho o grupo de interesse em sistemas de informao (ISSIG - http://www.pmiis.org) tem grandes contribuies 5 . Fundado em 1990 e considerado como um captulo
pelo PMI em 1995, possui aproximadamente 8.800 membros distribudos ao redor do
mundo (destes, cerca de 800 so PMP). Tem como misso avanar o estado da arte no que
diz respeito a tcnicas, mtodos, procedimentos e prticas de gerenciamento de projetos
para os profissionais envolvidos com sistemas de informao, em especial para as
indstrias. Inclui as seguintes metas ([MANG99] e [ISSI98]):
Demonstrar e promover os princpios profissionais de gerenciamento de

projetos como a forma mais efetiva de planejar e gerenciar projetos de sistemas
de informao;
Compartilhar e disseminar informaes com outros gerentes de projetos de

sistemas de informao, ou seja, prover acesso a informaes qualitativas e
quantitativas a respeito dos profissionais de gerenciamento de projetos e das
empresas;
Formao dos membros do grupo.
2.2.2. SEI - Software Engineering Institute

De acordo com [SEI99], o SEI (Software Engineering Institute - http://www.sei.cmu.edu)
foi estabelecido em 1984 pelo Congresso americano como uma fundao federal de
pesquisa e desenvolvimento com o propsito de verificar e acompanhar a transio entre as
tecnologias de engenharia de software; patrocinado pelo departamento de defesa
americano (DoD) atravs do Office of the Under Secretary of Defense for Acquisition and
Technology (OUSD - A&T). O SEI procura ser parceiro das organizaes industriais e
agncias governamentais nos processos de desenvolvimento, aquisio e suporte aos
sistemas de software.
Como um componente integral da Universidade Carnegie Mellon (CMU), o SEI mantm
um corpo tcnico altamente qualificado e conduz suas atividades de maneira sincronizada
com a Universidade. Pelo fato de ser patrocinado pelo DoD e tambm ser integrante da
CMU, o SEI procura utilizar a tecnologia de ponta desenvolvida/pesquisada na
universidade com os padres e exigncias de mercado exigidas pela comunidade.
5
Como exemplo destas contribuies tem-se [STEI99], que procura ilustrar os benefcios de gerenciamento de projetos
em software.
Em 1984, a comunidade de engenheiros de software desejava conseguir uma viso geral do

estado da arte das prticas adotadas a fim de obter um conjunto de preceitos comuns a
todos. Atividades de desenvolvimento e os resultados obtidos com os produtos eram
imprevisveis e o sucesso ou fracasso era totalmente dependente das pessoas envolvidas
com as atividades. Enquanto vrias tecnologias prometiam avanos, vrias organizaes
no estavam em condies de adotar novas tecnologias - e ainda que fizessem no
poderiam avaliar o seu real efeito.
A estratgia adotada pelo SEI foi desenvolver prticas na disciplina de engenharia de
software e preparar indivduos e organizaes para usar e evoluir estas prticas. Como
exemplo, tem-se o desenvolvimento do modelo de capacidade e maturidade de software
(CMM), discutido em detalhes no Captulo 3 - Desenvolvimento de software; o objetivo
principal era auxiliar estas organizaes a atingir um nvel de maturidade suficiente para
gerenciar a tecnologia. A estratgia habilitava o desenvolvimento de um infra-estrutura na
qual a tecnologia poderia ser instalada e os meios para estabelecimento de prioridades
ficassem disponveis.
Com esta estratgia o SEI implementou um modelo no qual a tecnologia poderia ser
inserida e como a comunidade poderia ser preparada para adaptar esta tecnologia. O SEI
est disposio para auxiliar a comunidade de software a enfrentar a evoluo causada
pela tecnologia de software e a avaliar seus efeitos.
Os programas tcnicos do SEI esto organizados em duas grandes reas:
Prticas de gerenciamento de engenharia de software
Prticas em tcnicas de engenharia de software
Estes programas so desenvolvidos visando habilitar a comunidade de software a lidar com

o desenvolvimento de sistemas como linhas de produo, baseadas em regras claras,
arquiteturas flexveis de software com interfaces para padres comerciais seguindo uma
metodologia/disciplina.
2.2.3. ISO - International Organization for Standardization

De acordo com [ISO99a], a ISO (International Organization for Standardization hppt://www.iso.ch) uma federao mundial composta por associaes de padronizao
nacionais de aproximadamente 130 pases. uma organizao no governamental fundada
em 1947; sua misso promover o desenvolvimento da padronizao e atividades
correlatas no mundo com vistas a facilitar a troca internacional de bens e servios e
desenvolver de forma cooperativa as esferas intelectuais, cientficas, tecnolgicas e
econmicas internacionais. mantido pelas taxas de inscrio de seus associados e pela
renda obtida com a venda de cpias dos materiais (artigos, padres e outros). Tem entre
seus parceiros a ITU (International Telecommunication Union - http://www.itu.org), a
WTO (World Trade Organization - http://www.wto.org) e a IEC (International
Electrotechnical Commission).
A preocupao com padronizao mundial comeou no campo da eletrotcnica: a IEC foi
criada em 1906; trabalhadores pioneiros de outros campos foram congregados pela ISA
(International Federation of the National Standardizing Associations http://www.isa.org), cujas atividades tiveram incio em 1926; a nfase maior das atividades
da ISA estavam voltadas para atividades relacionadas a engenharia mecnica.
10
As atividades da ISA foram suspensas em 1942 em funo da Segunda Guerra Mundial.

Aps um encontro ocorrido em 1946 em Londres, delegados de 25 pases decidiram criar
uma nova organizao internacional cujo objetivo era "facilitar a coordenao mundial e
unificao dos padres industriais"; com isso foi fundada a ISO cuja data oficial de
fundao 23 fevereiro de 1947. O primeiro padro publicado pela ISO foi feito em 1951
sob o ttulo "Standard reference temperature for industrial length measurement ".
Os trabalhos da ISO so resultados de acordos internacionais os quais so publicados como
padres internacionais.
O nome ISO, segundo [ISO99a], no corresponde exatamente a sigla do nome da
organizao; isto se deve ao fato de ISO no ser um acrnimo e sim uma palavra, derivada
do grego "isos" que significa "igual", o qual deu origem ao prefixo "iso-" que aparece em
vrios termos tais como isonomia (igualdade de leis ou de pessoas antes da lei) e isometria
(de igual medida ou dimenso).
De "igual" para "padro" - esta linha de pensamento levou adoo do nome "ISO" como
sendo o nome da organizao mais facilmente reconhecido. Outro fator que o nome ISO
usado ao redor do mundo para descrever a organizao, embora os acrnimos resultados
das diversas tradues de "International Organization for Standardization" sejam diversos
entre as diversas naes e seus diferentes idiomas (por exemplo, IOS em ingls, OIN em
Francs); com a adoo do termo ISO, em qualquer pas a terminologia a mesma.
A razo da existncia da ISO tem relao com a existncia de padres no harmnicos para
tecnologias similares em diferentes pases e regies, que contribuem para as chamadas
"barreiras tcnicas para comrcio". Empresas de exportao tem sentido a necessidade de
padronizao a fim de auxili-las na realizao de negcios internacionais. As reas de
atuao da ISO so processamento de informaes, comunicaes, pacotes, distribuio de
bens e servios, produo e utilizao de energia, construo naval, atividades bancrias e
servios financeiros, alm de ter sempre em mente a questo da evoluo das necessidades
com o surgimento de novos tipos de negcio.
As razes principais, segundo [ISO99a], so:
Progressos mundiais na liberao do comrcio - necessidade de identificao e

padronizao entre as diversas naes;
Inter-relaes entre os diversos setores - todas as indstrias atuais atuam de

forma integrada com componentes, produtos, regras de aplicao e outros. Isto
faz com que o desenvolvimento de padres seja realizado em todos os setores
envolvidos;
Sistemas de comunicao mundiais - especialmente impulsionado pela industria

de computadores, que requer uma maior compatibilidade entre os diversos
componentes;
Padres mundiais para tecnologias emergentes - preocupao em padronizar o

uso de novas tecnologias (terminologia, informaes relativas e outros)
evitando problemas futuros;
Desenvolvimento dos pases - agncias de desenvolvimento esto reconhecendo

cada vez mais que padres de infra-estrutura correspondem a uma das
condies bsicas para o sucesso das polticas econmicas que visam prover o
desenvolvimento sustentvel destes pases em desenvolvimento.
Segundo [ISO99a], facilitando os processos de comrcio, troca e transferncia de

tecnologia tem-se como ganhos:
Aumento na qualidade e confiabilidade dos produtos por um preo adequado;
Melhoria na sade, segurana e proteo ambiental, com reduo de lixo;
Grande capacidade e interoperabilidade de produtos e servios;
Simplificao dos processos para aumento da usabilidade;
Reduo do nmero de modelos e conseqente reduo de custos;
Aumento da eficincia de distribuio e facilidades adicionais de manuteno.
Dentre as principais contribuies advindas de padres propostos pela ISO tem-se que
milhares de empresas j implementaram (ou esto implamentando) a ISO 9000, que prov
um modelo 6 para gerenciamento de qualidade e garantia da qualidade. A srie ISO 14000
prov um modelo similar para gerenciamento ambiental. Os padres relacionados ao
desenvolvimento de software e ao gerenciamento deste processo de desenvolvimento so
discutidos no Captulo 3 - Desenvolvimento de software.
2.2.4. Outras organizaes

Alm das organizaes internacionais j mencionadas existem outras organizaes que
poderiam ser mencionadas, incluindo as brasileiras Fundao Carlos Alberto Vanzolini,
FGP, diversas outras universidades e outras instituies que tem preocupaes constantes
com os temas aqui abordados; mencionar todas seria extremamente difcil e fatalmente
alguma instituio seria esquecida.
Dentre as contribuies destas instituies podem ser destacados os trabalhos dos captulos
brasileiros do PMI; para mencionar algumas iniciativas, tem-se os trabalhos do captulo
So Paulo de traduo do PMBoK para a lngua portuguesa e a criao de uma traduo
padronizada para a terminologia de gerenciamento de projetos; tem-se o captulo Rio de
Janeiro, que promove diversos encontros discutindo temas referentes ao gerenciamento de
projetos, em especial de TI (um interessante artigo sobre tratamento de riscos em projetos
de TI pode ser obtido em [KRAU99]).
A Fundao Vanzolini (http://www.vanzolini.org.br), fundada em 31 de maro de 1967,
uma entidade sem fins lucrativos, criada, mantida e gerida pelos professores do
Departamento de Engenharia de Produo da Escola Politcnica da Universidade de So
Paulo para desenvolver atividades de carter inovador na rea de Engenharia de Produo
e Administrao de Operaes, priorizando seus projetos por critrios de relevncia
econmica e social e pautando sua atuao por critrios de excelncia acadmicos,
profissionais e ticos. Tem por objetivo a difuso da Engenharia de Produo e
Administrao Industrial. Dentre suas contribuies para a rea de gerenciamento de
projetos pode ser destacada a recente criao de curso especfico sobre gerenciamento de
projetos totalmente baseado no PMBoK (vide [VANZ99]); tambm pode ser destacada
Neste trabalho estamos traduzindo framework por modelo. Vrios autores preferem manter a ortografia original em
ingls visando preservar seu significado (que muito mais abrangente que modelo).
12
pela sua participao como auditora dos processos relativos s normas de qualidade, alm
de diversos cursos nas reas mais voltadas ao software (CMM).
A SUCESU-SP - Sociedade de Usurios de Informtica e Telecomunicaes de So Paulo.
- (http://www.sucesusp.com.br) - sociedade civil, representativa de setores das tecnologias
da informao, atua h 33 anos no mercado de informtica e telecomunicaes. Possui um
grupo de discusso especfico sobre o tema gerenciamento de projetos (o chamado Grupo
de Usurios - Gesto de Projetos em TI [SUCE99]); tambm tem promovido nos ltimos
trs anos o evento Project Management Conference on Information Tecnology, evento este
de grande impacto na comunidade de software. A presente dissertao utiliza vrios artigos
e referncias apresentados durante estes congressos, aos quais o autor esteve presente.
A FGV - Fundao Getlio Vargas - (http://www.fgv.br) e a USP - Universidade de So
Paulo - (http://www.usp.br)- em especial a FEA - Faculdade de Economia, Administrao
e Contabilidade (http://www.fea.usp.br) - tambm podem ser destacadas como instituies
que tem preocupaes com o tema de gerenciamento de projetos e participam das diversas
iniciativas mencionadas (captulo So Paulo do PMI, congressos da SUCESU-SP, grupo de
usurios de gerenciamento de empreendimentos).
Cap. 3 Desenvolvimento de Software 13
3. DESENVOLVIMENTO DE SOFTWARE
3.1. Conceito
Uma primeira definio formal pode ser obtida em [PRES95]: "Software : (1) instrues
(programas de computador) que quando executadas, produzem a funo e o desempenho
desejados; (2) estruturas de dados que possibilitam que os programas manipulem
adequadamente a informao; e (3) documentos que descrevem a operao e o uso dos
programas". Pode-se notar a preocupao em ampliar o entendimento comum de que
software corresponde apenas ao programa - de fato a complexidade atualmente existente
requer tratamentos especficos ao que se chama de configurao de software, englobando
alm dos aspectos j citados o ambiente necessrio ao software (bibliotecas dinmicas,
sistema operacional, tipo de equipamento e outros).
Diferentemente do hardware, o software um elemento lgico e no fsico [PRES95],
tendo como caractersticas diferenciadas:
desenvolvido ou projetado por engenharia (e no manufaturado no sentido

literal);
Enquanto o hardware se desgasta o software se deteriora com o tempo. No caso do

hardware este desgaste pode ser solucionado com a substituio de componentes e
no caso do software esta substituio (na realidade a liberao de uma nova
verso) acarreta no surgimento de novos erros que prejudicam a operao normal;
A maioria dos softwares feita sob medida em vez de ser montada a partir de
componentes j existentes - este item pretende ser otimizado com o maior uso das
tecnologias orientadas a objetos, descritas ainda neste captulo.
3.2. Histrico
O desenvolvimento de software passou por diversas etapas desde sua origem na dcada de
50; a percepo de sua importncia tambm se modificou muito ao longo do tempo:
segundo [PRES95], enquanto a preocupao com o software era secundria durante as
dcadas de 50, 60 e 70 (uma vez que a grande meta era desenvolver um hardware que
reduzisse o custo de processamento e armazenamento de dados), o que se v uma
preocupao mais acentuada a partir da dcada de 80 (muito em funo da grande evoluo
da microeletrnica durante essa dcada, que resultou em um maior poder de computao a
um custo cada vez mais baixo).
A programao de computadores nasceu como uma arte (e secundria); os
desenvolvimentos de software eram feitos virtualmente sem administrao, at que os
prazos comeassem a se esgotar e os custos a subir abruptamente. As pessoas envolvidas
com o software eram oriundas de diversas reas (engenheiros, administradores e outros),
no especializados em software, dificultando ainda mais o entendimento dos problemas
relacionados a computao.
14
Cap. 3 Desenvolvimento de Software
Os primeiros sistemas eram especificados, desenvolvidos, operados e mantidos pelo

mesmo grupo de pessoas, de forma bastante restrita - eram sistemas desenvolvidos com
propsitos especficos, apenas para uma empresa; sua caracterstica de processamento era
notadamente em lote (orientao batch 7 ). A documentao do software era na maior parte
das vezes negligenciada, ora no existindo (e estando apenas "na cabea" daquele que
desenvolveu o software) ora existindo, porm incompleta, ou desatualizada com o passar
das manutenes.
Um segundo momento na evoluo de software surgiu com o aumento do nmero de
usurios e solicitaes por novos desenvolvimentos; neste momento comea a nfase em
sistemas multiusurios, com o surgimento de preocupaes com a interface homemmquina (deve-se notar que at ento isto no era necessrio uma vez que o usurio era o
prprio desenvolvedor). Com o aumento da demanda vrias empresas comearam a criar
software para distribuio, visando atingir vrios clientes; no incio estas empresas foram
representadas pelos prprios fabricantes de hardware (o software ainda era considerado
como secundrio). Comea ento o que vrios autores ([PRES95], [REZE99], [MAFF92])
chamam de "crise de software": os profissionais no conseguiam atender toda a demanda
por novos sistemas (normalmente chamado de backlog) em funo de um nmero
crescente de sistemas disponibilizados para os usurios estarem em constante manuteno,
em sua maioria por motivos de correo. Isto ocorria por diversas razes:
Falta de documentao adequada do software produzido
Falta de entendimento das necessidades dos usurios
Falta de capacitao e mtodos aos profissionais envolvidos no processo de

produo do software
Constantes atrasos na entrega do software, o que poderia defas-lo antes mesmo do

incio de sua utilizao
Nota-se que vrios destes itens ainda hoje constituem problemas no desenvolvimento de
software.
O terceiro momento no desenvolvimento de software tem seu incio em meados da dcada
de 70 e marcado pelo advento da microinformtica, com a expanso do nmero de
usurios e com exigncias cada vez maiores por sistemas que apresentassem informaes
instantaneamente e em grandes volumes de dados. O processamento de dados,
anteriormente restrito aos computadores, agora tambm utilizado em outros
equipamentos com microprocessadores: automveis, microondas, robs, equipamentos de
diagnstico mdico e outros. Tem-se ento um problema histrico: o profissionalismo j
existente no desenvolvimento da tecnologia de hardware agora se v a frente de novos
desafios com o software para estes novos equipamentos, o que faz estes profissionais
buscarem alternativas para esta capacitao.
Vrias empresas de software foram criadas a partir do advento do microcomputador
(Microsoft, por exemplo); com a expanso do uso deste novo equipamento, os usurios
potenciais passaram rapidamente das centenas ou milhares existentes na segunda gerao
para centenas de milhares agora na terceira gerao, gerando um mercado consumidor cada
vez mais cobiado. Neste momento tambm inverte-se a curva de valor entre o hardware e
O processamento em lote (orientao batch) ainda hoje utilizado, em especial nos processamentos de grandes volumes
de dados (como por exemplo em sistemas de folha de pagamento, inicializao de mquinas e outros). Nota-se contudo
que a grande nfase de mercado atual no recai sobre este tipo de sistema.
o software: o hardware passa a ser considerado um produto primrio, o software passa a

ter um campo enorme de novas aplicaes a serem desenvolvidas; assim comum que o
custo do software para um computador pessoal ultrapasse em vrias vezes o custo do
hardware deste mesmo equipamento.
A quarta gerao de software marcada pelo surgimento de novas tecnologias para o
desenvolvimento do software - em especial a tecnologia de orientao a objetos. Novas
aplicaes de software levaram evoluo de sistemas especialistas, sistemas baseados em
redes neurais e s novas arquiteturas (cliente servidor).
Um novo desafio est presente nos dias atuais: a evoluo do hardware e do software em
funo da disseminao da Internet. Vrios autores consideram que est surgindo uma
quinta era de desenvolvimento de software, onde a distribuio das informaes
radicalmente modificada: se existiam sistemas com centenas de milhares de potenciais
usurios este nmero agora pode ultrapassar aos milhes de usurios de diferentes pases.
O tempo para o desenvolvimento de sistemas para a Internet cada vez menor em funo
das exigncias de agilidade das empresas que pretendem atuar neste segmento; surgem
novas reas de aplicao do software:
E-commerce (comrcio eletrnico), voltado para empresas de varejo e de grande

penetrao com o pblico consumidor em geral;
ASP - Application Services Provider, que so empresas que passam a oferecer

servios de outsourcing de aplicaes (notadamente de sistemas de gesto
empresarial e outros pacotes voltados a empresas de todos os portes); a grande
vantagem deste tipo de soluo o rpido tempo de liberao da soluo de TI
para uso, o que realmente muito interessante para empresas que esto se
instalando no pas ou aquelas que esto tecnologicamente (tanto em termos de
hardware quanto em termos de software) defasadas e no pretendem fazer grandes
investimentos (ou seja, imobilizaes) neste setor;
CRM - Customer Relationship Management, que so sistemas voltados ao

atendimento das necessidades dos clientes em todas as fases deste relacionamento,
desde a prospeo de oportunidades, a produo de um produto/encomenda e o
ps-venda, integrado aos sistemas de gesto e produtivos das empresas.
SCM - Supply Chain Management, que so sistemas voltados ao atendimento da

cadeia de suprimentos de uma dada organizao, envolvendo todos os
fornecedores, as cotaes e compras e o relacionamento com os sistemas de gesto
e produo.
O grande desafio atual garantir o cumprimento dos prazos, custo e escopo dos softwares
necessrios neste novo ambiente com a qualidade adequada.
3.3. Engenharia de software

O desenvolvimento de software notadamente algo recente, comparado a outras
atividades: algo em torno de 50 anos. A preocupao com a padronizao e qualidade no
desenvolvimento de software ainda mais recente, uma vez que o mesmo era considerado
como um parte secundria do conjunto hardware + software. Ainda hoje, onde
notadamente o software de vital importncia, suplantando o hardware, processos de
16
padronizao encontram dificuldades entre a comunidade de profissionais, refletindo at

mesmo no consenso quanto ao conceito de engenharia de software.
Vrias definies podem ser obtidas a partir de diversos autores. Para [MAFF92]
engenharia de software "a rea interdisciplinar que engloba vertentes tecnolgica e
gerencial visando abordar de modo sistemtico (modular) os processos de construo,
implantao e manuteno de produtos de software, com qualidade assegurada por
construo e segundo cronogramas e custos previamente definidos". Esta definio muito
interessante uma vez que considera o fator gerencial como um dos mais importantes e
crticos na construo do software; justamente o estudo destes fatores (gerenciais) o
escopo da presente dissertao.
Para [MART91], a engenharia de software corresponde "ao estudo dos princpios e sua
aplicao no desenvolvimento e manuteno de sistemas de software; corresponde assim, a
uma metodologia para desenvolvimento de solues em software". Neste conceito so
apresentadas caractersticas voltadas metodologia e suas ferramentas de apoio 8 como
fatores primordiais para a obteno de um produto de software com qualidade.
Para [REZE99] 9 a engenharia de software a "metodologia de desenvolvimento e
manuteno de sistemas modulares, com as seguintes caractersticas: a) adequao aos
requisitos funcionais do negcio do cliente e seus respectivos procedimentos pertinentes;
b) efetivao de padres de qualidade e produtividade em suas atividades e produtos; c)
fundamentao na Tecnologia da Informao disponvel, vivel e oportuna; d)
planejamento e gesto de atividades, recursos, custos e datas". Nesta definio o autor
procura sintetizar as principais caractersticas do processo de desenvolvimento de software,
englobando tambm as questes gerenciais.
Para [PRES95], a engenharia de software "o estabelecimento e uso de slidos princpios
de engenharia para que se possa obter economicamente um software que seja confivel e
que funcione eficientemente em mquinas reais. Abrange um conjunto de trs elementos
fundamentais (mtodos, ferramentas e procedimentos), que possibilitam ao gerente o
controle do processo de desenvolvimento do software e oferece ao profissional uma base
para a construo de software de alta qualidade". Esta definio mais abrangente que as
demais, detalhando os componentes que possibilitam atingir aos objetivos de um produto
de software com qualidade, no deixando de lado as questes gerenciais; na verdade existe
a correlao entre os fatores tcnicos e os fatores gerenciais e ambos devem andar de
forma alinhada a fim de garantir o sucesso do processo de obteno do produto software.
Os elementos mencionados tem as seguintes caractersticas:
Mtodos: proporcionam os detalhes de "como fazer" para construir o software,

envolvendo um amplo conjunto de tarefas que incluem: planejamento e estimativa
de projeto, anlise de requisitos de software e de sistemas, projeto da estrutura de
dados, arquitetura de programa e algoritmo de processamento, codificao, testes e
manuteno.
Ferramentas: proporcionam um apoio automatizado ou semi-automatizado aos

mtodos, correspondendo a instrumentos que possibilitam os detalhes de "como
fazer" para construir o software. Existem diversas tcnicas para sustentar os
Vale comentar que nesta referncia [MART91] a abordagem utilizada a estruturada, sempre com grandes
preocupaes relativas existncia e a posterior adoo de ferramentas automatizadas para possibilitar a utilizao de
tcnicas de engenharia de software.
Tambm presente em [REZE97], porm com enfoque de negcios.
mtodos, como por exemplo, ferramentas CASE10 , CAD 11 , Anlise estruturada,

Orientao a Objetos, Bancos de dados, linguagens de programao e outras.
Procedimentos : constituem o elo de ligao entre os mtodos e as ferramentas de

engenharia de software, possibilitando o desenvolvimento racional e oportuno de
software. Definem a seqncia na qual os mtodos sero aplicados, os produtos a
serem entregues, controles de qualidade e avaliao.
3.3.1. Paradigmas da engenharia de software

Segundo [PRES95], a engenharia de software compreende um conjunto de etapas que
envolvem mtodos, ferramentas e procedimentos. Essas etapas so citadas pela grande
maioria dos autores como sendo os paradigmas da engenharia de software. Um paradigma
da engenharia de software escolhido tendo como base a natureza do projeto e da
aplicao, os mtodos e as ferramentas a serem usados, os controles e os produtos que
precisam ser entregues. A seguir so detalhados os principais paradigmas descritos na
literatura e utilizados pelo mercado.
3.3.1.1. Ciclo de vida clssico
O ciclo de vida clssico, tambm conhecido como cascata ou waterfall, foi o primeiro ciclo
de desenvolvimento de software estudado pela engenharia de software e ainda hoje um dos
mais difundidos e utilizados. Requer, segundo [PRES95], uma abordagem sistemtica e
seqencial ao desenvolvimento do software. A FIGURA 2 - Ciclo de vida clssico - ilustra
as principais etapas.
Este ciclo funciona de maneira seqencial, contemplando as etapas de:
Anlise de requisitos : consiste em levantar os requisitos dos usurios a fim de

fazer uma primeira verificao de viabilidade; uma vez feita esta verificao,
consiste em coletar, classificar e validar os requisitos de software necessrios a
fim de garantir o atendimento s necessidades dos usurios.
Anlise: consiste em detalhar os requisitos coletados na primeira etapa e

garantir o perfeito entendimento das reais necessidades dos usurios. Tcnicas
10
CASE - Computer Aided Software Engineering - tradicionalmente mantida na sua grafia original (em ingls),
compreende um conjunto de ferramentas de apoio automatizado para as atividades de engenharia de software.
11
CAD - Computer Aided Design - tradicionalmente mantida na sua grafia original (em ingls), compreende um conjunto
de ferramentas de apoio automatizado para as atividades de desenho.
18
como Anlise Estrutura (DFD) 12 e Anlise Orientada a Objetos (OMT, UML e

outras) 13 devem ser utilizadas nesta etapa.
Projeto: consiste em projetar estruturas (projeto de banco de dados - relacional,

orientado a objetos etc.)14 , interfaces 15 e funes 16 .
Codificao: atividade que consiste em transformar o projeto anteriormente

elaborado em cdigo, preferencialmente atravs do uso de ferramentas CASE.
Anlise de
requisitos
Anlise
Projeto
Codificao
Testes
Manuteno
Fonte: [PRES95] - pg. 33 e [JACO98b] - pg. 71
FIGURA 2 - Ciclo de vida clssico
12
Para aprofundamento no tema recomenda-se as referncias: [GANE84], com a abordagem de DFD - Diagrama de
Fluxo de Dados; [MART91], onde so comentadas as tcnicas de anlise estruturada e as ferramentas disponveis no
mercado; [YOUR90], onde so comentados princpios e tcnicas de anlise de sistemas de grande porte.
13
Para aprofundamento no tema recomenda-se as referncias: [JACO98b], que aborda a da engenharia de software
orientada a objetos e estudos de use cases; [UML97] e [FURL98], onde so apresentado o ambiente da UML e seus
diagramas, alm de [JACO98a], onde apresentado o Objectory, uma das bases da UML; [RUMB94], onde
apresentada a metodologia OMT, dentre outras referncias; [YOUR99], onde so descritos os conceitos de orientao a
objetos e de uma forma bastante interessante so apresentados exemplos prticos, correspondentes a estudos de casos
completos; [MART95] e [AMBL99] tambm abordam as questes de orientao a objetos, comparando-a com as
tradicionais abordagens estruturadas.
14
Para aprofundamento no tema recomenda-se as referncias [HEUS99], onde so detalhados os princpios norteadores
do bom projeto de banco de dados, com nfase no projeto de banco de dados relacional; [KORT99], onde so
apresentados os conceitos dos bancos de dados relacionais, orientados a objeto, alm de aprofundar a discusso da
melhor forma de fazer bons projetos.
15
Para aprofundamento no tema recomenda-se a referncia [MICR95], onde so detalhados os princpios norteadores do
projeto de interfaces em ambiente grfico. Existem tambm algumas obras que esto procurando consolidar diretrizes
para as interfaces das aplicaes desenvolvidos para Internet.
16
Para aprofundamento no tema recomenda-se a referncia [PAGE88], onde so detalhados os princpios norteadores do
projeto estruturado de sistemas; [UML97], onde apresentado o ambiente da UML e seus diagramas para projeto.
Testes: etapa que consiste em testes internos (programas) e externos

(sistema). 17 Deve contar com a participao tanto do pessoal tcnico quanto dos
usurios.
Manuteno: aps a implantao do sistema inicia-se a etapa de manuteno;

esta pode ser divida em trs tipos: evolutiva, caracterizada por necessidades
adicionais no software originalmente especificado; corretiva, caracterizada pela
necessidade de correo de um erro, quer seja de projeto, anlise ou
codificao; preventiva, caracterizada pela necessidade de adaptao do
software a novos ambientes ou configuraes.
Este modelo enfrenta uma srie de questionamentos quanto a sua efetividade. Dentre os
principais podem ser destacados:
Os projetos reais raramente seguem o fluxo seqencial que este modelo prope,
o que causa grande dificuldade e ansiedade a todos os envolvidos;
Muitas vezes difcil para o cliente declarar todas as exigncias de forma

explcita, o que requer dos profissionais habilidade;
O cliente deve ter pacincia - o produto somente ser disponibilizado no final

do ciclo, podendo no contemplar s exigncias dos usurios;
Auto custo de correo de problemas quando identificados tardiamente (nas

fases de manuteno, testes...)
Manuteno: fase na qual o sistema passar sua maior parte - infelizmente em

manutenes corretivas.
3.3.1.2. Ciclo de vida de prototipao

um processo que capacita o desenvolvedor a criar um modelo do software que ser
implementado. A seqncia de eventos para o paradigma de prototipao ilustrada na
FIGURA 3 - Prototipao.
Diferentemente do ciclo clssico, a prototipao requer uma participao bastante ativa do
usurio, uma vez que sempre depender de sua avaliao para avanar para a prxima fase.
As etapas normalmente encontradas neste paradigma so:
17
Coleta e refinamentos dos requisitos : desenvolvedores e usurios definem os

objetivos globais para o software, identificam as exigncias conhecidas e
esboam as reas em que uma definio adicional obrigatria.
Projeto rpido: concentra-se na representao daqueles aspectos do software

que sero visveis aos usurios (basicamente entradas de dados, sadas de dados
e navegao).
Construo do prottipo : construo utilizando ambientes de

desenvolvimento rpido. Algumas vezes o prottipo consiste em telas e
relatrios, outras em um aplicativo e outras ainda em esboo em papel.
Para aprofundamento no tema recomenda-se a referncia [PRES95], onde existem captulos especficos sobre
metodologias e procedimentos que auxiliam na etapa de teste de software, desde a identificao da abordagem a ser
utilizada (testes de caixa branca, de caixa preta) at o que testar.
20
Fim
Incio
Coleta e
refinamento
dos requisitos
Projeto
Rpido
Engenharia
do
Produto
Construo
do
Prottipo
Refinamento
do Produto
Avaliao do
Prottipo pelo
Cliente
Fonte: [PRES95] - pg. 36
FIGURA 3 - Prototipao
Avaliao do prottipo pelo cliente: avaliao do prottipo pelo usurio

objetivando extrair crticas e sugestes.
Refinamento do prottipo : etapa onde as crticas e sugestes do usurio so

avaliadas e incorporadas ao prottipo; com isso, tanto usurios quanto os
desenvolvedores passam a ter uma viso mais clara das reais necessidades.
Repete-se ento novo ciclo a partir do projeto rpido para a incorporao destas
novas necessidades.
Engenharia do produto: uma vez definidos todos os produtos a serem gerados

e dirimidas todas as dvidas com o prottipo, o sistema propriamente dito pode
ser desenvolvido utilizando conceitos de engenharia de software.
Idealmente o prottipo serve como um mecanismo para identificar os requisitos de

software. Se um prottipo for construdo, o desenvolvedor tentar usar fragmentos de
programas j existentes ou aplicar ferramentas (por exemplo, geradores de relatrios e
janelas, ferramentas grficas) que possibilitem a gerao rpida do prottipo. O prottipo
no tem compromissos com a qualidade e com a forma de produo no tocante a mtodos;
como um cenrio de um filme ou novela, onde a aparncia o aspecto mais importe.
Surge ento a grande dificuldade deste mtodo: no raro, ao final do prottipo, o cliente
imagina que o produto est "quase" pronto e deseja a todo custo uma verso temporria e
um produto final em prazos muito rpidos. Os desenvolvedores tem freqentemente
dificuldades em esclarecer que os objetivos do prottipo so relativos eliminao das
dvidas existentes na coleta dos requisitos e que no um produto - alis o

desenvolvimento do produto propriamente dito somente neste momento iniciado, com a
viso clara dos resultados a serem atingidos conseguida graas ao prottipo.
A fim de evitar estes problemas a recomendao de que as regras do jogo sejam
negociadas com o usurio antes do incio do desenvolvimento do prottipo.
3.3.1.3. Ciclo de vida espiral
Este ciclo foi desenvolvido a fim de conter as melhores caractersticas dos paradigmas
clssico e prototipao, acrescentando um novo elemento - a anlise de riscos; definido
em quatro quadrantes conforme ilustra a FIGURA 4 - Modelo espiral.
Planejamento
Anlise dos riscos
Coleta inicial dos

requisitos e
planejamento do
projeto
Anlise dos riscos

baseada nos requisitos
iniciais
Anlise dos riscos

baseada na reao do
cliente
Deciso de prosseguir/
no prosseguir
Planejamento
baseado nos
comentrios do
cliente
Na direo de um
sistema concludo
Prottipo de software
Inicial
Avaliao do cliente
Prottipo no nvel
Seguinte
Anlise do cliente
Engenharia
Sistema construdo
pela engenharia
FIGURA 4 - Modelo espiral

Ao final de cada iterao ao redor da espiral (iniciando-se do centro e avanando para
fora), verses progressivamente mais completas do software so geradas. Os quatro
quadrantes representam as etapas:
Planejamento: determinao dos objetivos, alternativas e restries para o

desenvolvimento da verso atual do software.
Anlise de riscos: anlise das alternativas e identificao, priorizao,

acompanhamento e resoluo dos riscos.
22
Engenharia: desenvolvimento do produto, incorporando s verses j

existentes as novas funcionalidades definas nos quadrantes anteriores. Vale
notar que a tcnica de prototipao poder ser utilizada caso na etapa de anlise
de riscos tenha sido identificado um volume de incertezas que justifique a
construo de um prottipo 18 ; caso contrrio, a abordagem clssica poder ser
utilizada para desenvolver as novas funcionalidades.
Avaliao do cliente: avaliao, por parte do cliente, dos resultados da

engenharia.
A incorporao da anlise de riscos a grande novidade e virtude deste ciclo de vida.

Incorpora a necessidade de uma avaliao criteriosa dos riscos envolvidos com o projeto e
a deciso de prosseguir ou no com o desenvolvimento do software. Esta deciso, que no
ciclo de vida clssico muitas vezes no visvel at que seja tarde de mais (muitas vezes
apenas aps a etapa de codificao, quando o sistema comea a ser testado visando a
implantao), tomada baseada nos levantamento e requisitos da atual fase de
desenvolvimento.
Uma preocupao constante manter o entendimento de todos os envolvidos de que a
abordagem deste ciclo evolutiva e requer a participao ativa e constante de todos. Um
dos principais benefcios a entrega de produtos (ou verses do software) intermedirias
que j possuem caractersticas interessantes aos usurios, j podendo ser utilizada
(inclusive extremamente recomendvel que isto ocorra a fim de fornecer subsdios para o
planejamento do prximo ciclo de desenvolvimento).
3.3.1.4. Tcnicas de quarta gerao
O paradigma de tcnicas de quarta gerao da engenharia de software [PRES95]
concentra-se na capacidade de se especificar software a uma mquina em um nvel que
esteja prximo linguagem natural ou de se usar uma notao que comunique uma funo
significativa. Entende-se por estas tcnicas um amplo conjunto de ferramentas de software
(CASE) que tm uma caracterstica em comum: possibilitar ao desenvolvedor de software
especificar alguma etapa do software num nvel elevado e automatizar a gerao do
cdigo-fonte para a implementao desta caracterstica; as ferramentas disponveis
atualmente para este paradigma incluem, entre outras caractersticas:
Linguagens no procedimentais para consultas e operaes em bancos de dados.
Geradores de cdigo-fonte.
Geradores de interfaces, contemplando manipulao de dados, interao e

definio de telas.
Capacidade grfica de alto nvel.
Planilhas eletrnicas.
A FIGURA 5 - Tcnicas de quarta gerao - ilustra as etapas deste paradigma.
18
Normalmente este prottipo corresponde ao primeiro ciclo da espiral ou verso 0 do software.
Coleta de
requisitos
Estratgia de
projeto
Implementao
usando 4GT
Teste
FIGURA 5 - Tcnicas de quarta gerao

Este paradigma se inicia com a coleta de requisitos dos usurios 19 ; [PRES95] comenta que
idealmente esta atividade, bem como a introduo destes dados em uma ferramenta CASE,
deveria ficar a cargo dos usurios. Este tema bastante polmico, no havendo consenso
entre os autores sobre a responsabilidade da coleta de requisitos e o apoio efetivo das
ferramentas CASE disponveis; de fato o que existe a necessidade de se efetuar esta
atividade da melhor maneira possvel, uma vez que esta parte vital do desenvolvimento
do software. Deixar esta atividade apenas nas mos dos usurios poderia fazer com que o
software apenas informatize um processo tal qual ele realizado hoje - e a atividade de
anlise consiste, antes de especificar um sistema, verificar o processo atual e melhor-lo a
fim de que o software seja implantado em um ambiente otimizado. Outro ponto a ser
considerado o fato das ferramentas CASE, por mais avanadas e de alto nvel que sejam,
exigem preparao (e geralmente tcnica) de quem as ir operar, o que poder causar
restries quando da operao pelo usurio: detalhes vitais podem ser suprimidos assim
como outros de importncia relativa serem superestimados.
A etapa de projeto, subseqente atividade de coleta de requisitos, obrigatria no
desenvolvimento de sistemas de mdio e grande porte utilizando este paradigma (alguns
autores defendem que para desenvolvimentos de pequeno porte poder-se-ia ir diretamente
para a etapa de implementao em uma ferramenta CASE). A tese do uso do projeto
reforada pelo fato desta atividade requerer e revisar conceitos de planejamento do
desenvolvimento do software, sem os quais poder-se-iam surgir problemas de grande
19
Vale notar que a coleta de requisitos uma etapa presente a todos os paradigmas de engenharia de software e talvez o
mais importante, uma vez que sem a identificao clara e precisa das necessidades dos usurios o resultado do produto
(software) a ser gerado ser sempre questionado: atingiu realmente aos objetivos iniciais?
24
dificuldade de soluo nas etapas posteriores de teste, implantao e aceitao pelos

usurios.
A implementao ento efetivada utilizando ferramentas automatizadas. Um dos
principais ganhos previstos a no necessidade de traduo/codificao das
recomendaes do projeto em um cdigo-fonte - esta atividade estar sendo realizada de
forma automtica pela ferramenta. Com isso, elimina-se um dos pontos de possveis
introdues de erros no software: a etapa de programao, onde problemas com relao ao
entendimento da especificao e do projeto, alm de caractersticas pessoais dos
profissionais que fazem a codificao, introduzem erros - performance, caractersticas
diferentes das projetadas e outras. Vrios autores comentam que a atividade de
programao deveria ser um processo de transformao de especificao/projeto para um
cdigo-fonte, sem a introduo da criatividade do programador (em outras palavras, estes
autores defendem o uso de ferramentas automatizadas no s para acelerar o processo mas
tambm para garantir que o cdigo-fonte gerado realmente corresponder
especificao/projeto). Este um tema extremamente polmico e no faz parte do escopo
do presente trabalho procurar elucid-lo (at porque seria impraticvel).
Aps a obteno do cdigo-fonte so feitos exaustivos testes a fim de garantir a qualidade
do produto gerado e o nvel de atendimento aos requisitos anteriormente coletados.
Tambm so essenciais para a concluso do desenvolvimento a verificao completa de
toda a documentao produzida - em muitos casos gerada em parte pelas prprias
ferramentas utilizadas para o desenvolvimento do software.
Algumas crticas tem sido feitas ao uso deste paradigma:
Perda do conhecimento do processo de desenvolvimento como um todo, em

funo da automatizao de algumas etapas.
Gerao de cdigo no otimizado, o que pode causar problemas posteriores de

performance e manuteno.
rea de atuao das ferramentas de quarta gerao ainda restrita, notadamente

circunscrita ao desenvolvimento de software comercial; vrias reas de
aplicao de software no possuem ferramentas adequadas.
3.3.1.5. Em busca de um novo paradigma

Diante das caractersticas dos paradigmas da engenharia de software, que indubitavelmente
contribuem para o bom desenvolvimento de software porm com algumas restries, a
busca por um novo paradigma que contemple as melhores caractersticas dos anteriores
objeto de estudo de diversos autores e pesquisas. [PRES95] prope que a aplicao, o
software a ser desenvolvido quem determine o paradigma mais adequado; isto vivel
em funo da primeira atividade de todos os paradigmas da engenharia de software ser a
atividade de anlise e coleta de requisitos. A FIGURA 6 - Combinando paradigmas ilustra esta proposta.
Aps a coleta dos requisitos pode-se determinar dentre outras coisas o porte do sistema,
seu grau de complexidade, o nvel de risco/incerteza inerente ao seu desenvolvimento e
outros fatores; com a anlise destas caractersticas pode-se escolher o paradigma de
desenvolvimento que seja mais adequado.
OBTENO
PRELIMINAR DOS
REQUISITOS
ANLISE DE
REQUISITOS
PROTOTIPAO
4GT
MODELO
ESPIRAL
4GT
PROJETO
PROTOTIPAO
ENSIMA
ITERAO
MODELO ESPIRAL
ENSIMA ITERAO
CODIFICAO
4GT
REALIZAO DE
TESTES
SOFTWARE EM
OPERAO
MANUTENO
FIGURA 6 - Combinando paradigmas

Caso a especificao esteja totalmente fechada, ou prestes a ser fechada, sem grandes
problemas e dvidas, o ciclo clssico pode vir a ser adotado (anlise, projeto, codificao com ou sem uso de ferramentas de quarta gerao, testes e implantao); quando
detectado que existem muitas dvidas quanto a definio do produto, quer seja por
problemas relativos comunicao com os usurios, quer seja por complexidade do
software a ser desenvolvido, as alternativas de prototipao ou desenvolvimento em espiral
so as mais recomendadas; caso seja adotada a alternativa de prototipao, este pode vir a
ser produzido utilizando ferramentas de quarta gerao, sendo seguido pelo uso do ciclo de
vida clssico ou o desenvolvimento em espiral na seqncia, para o desenvolvimento do
produto propriamente dito.
Nas etapa de testes e manuteno as ferramentas de quarta gerao podem ser de grande
valia, quer seja documentando atividades e solicitaes efetuadas, quer seja apoiando a
realizao automatizada destas atividades.
26
3.4. Padres de qualidade

3.4.1. ISO 9000
3.4.1.1. Histrico
A srie de padres conhecidas como ISO 9000 contempla uma coleo de padres
internacionais de qualidade, desenvolvidos pela ISO (descrita em detalhes em 2.2.3. ISO International Organization for Standardization); so aplicveis a sistemas de
gerenciamento da qualidade e nos processos utilizados para a confeco de produtos. Esta
srie estabelece um conjunto bsico de requisitos necessrios ao sistema de qualidade a fim
de garantir que o processo capaz de produzir produtos de forma consistente, que atinjam
as expectativas dos consumidores/usurios; em outras palavras, ela prov uma excelente
base sobre a qual o processo produtivo das empresas pode ser aperfeioado, garantindo
como resultado final a melhoria da qualidade dos produtos e servios realizados. Foi
desenvolvida inicialmente para contemplar relaes contratuais entre empresas,
notadamente para aquelas envolvidas com processos de manufatura; porm o mercado a
vem adotando como padro para diversas outras reas, tais como indstria eletrnica,
qumica, automotiva, de transportes, de sade, bancos, entre outras.
A origem da srie ISO 9000 data do ano de 1979, a partir da organizao de um comit
tcnico (technical committee 176 - TC176) que ficou encarregado de elaborar um padro
internacional para sistemas de qualidade [SCHM94]. Em 1987 a ISO 9000 foi publicada e
comeou a ser adotada rapidamente por diversas naes como seus padres de qualidade;
vale notar que vrias naes procuraram tomar por base a srie ISO 9000 para
desenvolverem seus padres com alguma especificidade (por exemplo, a ANSI/ASQC Q91
corresponde a ISO 9001 para os Estados Unidos). Uma das principais razes para o
sucesso da ISO 9000 foi a globalizao do mercado, onde a ISO passou a ser uma
referncia internacional com a qual os clientes poderiam estar assegurados quanto ao
processo produtivo das empresas e, por conseguinte, com a qualidade dos produtos
produzidos pelas diversas empresas ao redor do mundo.
3.4.1.2. Caractersticas
Segundo [SCHM94], a premissa norteadora da ISO 9000 " se o processo produtivo e o
sistema de gerenciamento esto funcionando adequadamente, o produto a ser produzido
certamente tambm ser adequado". Foi escrita de forma genrica e no para um caso
especfico, gerando assim como resultado um modelo e no uma especificao; descreve o
que, no mnimo, deve ser acompanhado, no especificando como os processos devem ser
feitos, deixando ao administrador/desenvolvedor a deciso de como se fazer os processos.
A idia da ISO 9000 no a de que todos os sistemas de qualidade sejam iguais e sim de
que todos contenham as mesmas caractersticas quanto aos requisitos; requerem que "as
empresas saibam o que fazem, faam o que dizem e demonstrem que elas tem realmente
feito isto - de maneira formal, atravs de documentos. Devem ser escritos procedimentos
que definem como cada atividade relevante no processo produtivo deve ser realizada,
devendo ser suficientemente detalhados para garantir a continuidade do processo produtivo
mesmo que venham a ocorrer mudana nos recursos para a confeco destes processos"
[SCHM94].
A ISO 9000 enfatiza algumas reas:
Controle : garantir que a empresa est apta, em todas as etapas do processo

produtivo, a identificar cada item, quem responsvel por eles, sua
situao/progresso e onde est. Em outras palavras, "estar controlado ou sob
controle significa que no est fora de controle".
Auditoria: a empresa deve, sempre que requisitada, poder exibir evidncias de

como est o processo produtivo.
Verificao/validao: a empresa deve possuir processos de verificao

detalhados a fim de garantir que os produtos esto sendo produzidos de acordo
com a especificao.
Melhoria de processo: requisito principal da ISO 9000, que sempre aumenta as

exigncias das empresas no sentido de melhorar ainda mais o processo
produtivo.
As empresas podem solicitar a auditoria dos seus processos a entidades devidamente

registradas pela ISO a fim de garantirem sua aderncia aos padres. A empresa passar por
auditorias e, caso aprovada, obter o certificado de que est condizente com os padres da
ISO (a seguir sero detalhadas as diversas subdivises da ISO); vale notar que este
certificado deve ser freqentemente renovado, com novas auditorias. Para maiores
informaes recomenda-se [GIL94].
A ISO 9000 constituda de cinco partes:
ISO 9000 para sistema de qualidade - padro para gerenciamento e

garantia da qualidade : este padro prov um guia para a seleo de qual dos
demais padres da srie ISO 9000 aplicvel ao sistema de qualidade da
empresa em questo. A ISO 9000-3 - guia para a aplicao da ISO 9001 para o
desenvolvimento, fornecimento e manuteno de software - uma adaptao
que prov um guia para a aplicao de padres ao processos de
desenvolvimento de software (ser detalhado ainda neste captulo).
ISO 9001 para sistema de qualidade - modelo para garantia da qualidade

no desenho/desenvolvimento, produo, instalao e fornecimento: este
padro prov um guia para a aplicao da ISO 9000 para as atividades
envolvidas com desenho/desenvolvimento de produtos, produo, instalao e
fornecimento.

na produo e instalao: este padro prov um guia para a aplicao da ISO
9000 para as atividades envolvidas com a produo e instalao de produtos.

na inspeo final e teste : este padro prov um guia para a aplicao da ISO
9000 para as atividades envolvidas com a inspeo final e os testes de produtos.
ISO 9004 para sistema de qualidade - guia - elementos de sistemas para

gerenciamento e garantia da qualidade : este padro prov um guia para a
interpretao das normas ISO 9001, ISO 9002 e ISO 9003.
28
A FIGURA 7 - Padres ISO 9000 - ilustra a relao entre as partes constituintes da ISO
9000.
Fonte: [SCHM94] - pg. 9
FIGURA 7 - Padres ISO 9000

3.4.1.3. Elementos padres da ISO 9000
A ISO 9000 compreende vinte elementos padres, sendo que so todos obrigatrios para a
ISO 9001, dezoito destes obrigatrios para a ISO 9002 e doze para a ISO 9003. A
TABELA 1 - Nveis ISO 9000 x elementos padres 20 - ilustra a relao entre estes
elementos e as partes constituintes da ISO 9000. Com isso pode-se perceber que o nvel de
exigncia da ISO 9001 o mais elevado - abrange todas as etapas do processo produtivo enquanto que a ISO 9003 a que possui o menor nmero de elementos - abrange uma parte
bem definida do processo produtivo.
Os vinte elementos possuem as seguintes caractersticas [SCHM94] e [ISO94]:
20
4.1. Responsabilidade gerencial: a empresa deve possuir uma poltica de

qualidade para a organizao, que deve ser entendida e praticada por todos; esta
poltica deve definir claramente as responsabilidades, autoridades e relaes
entre todos os que influenciam a qualidade. Tambm devem ser identificadas as
atividades a serem verificadas para a garantia da qualidade e recursos, tanto
humanos quanto financeiros, devem ser alocados; um gerente deve ser
designado para o sistema de qualidade, devendo garantir revises peridicas
neste sistema a fim de garantir a contnua eficincia do mesmo.
A numerao utilizada neste trabalho para referenciar os elementos da ISO 9000 corresponde a mesma utilizada pela
ISO para referenciar estes elementos.
Elemento padro ISO 9000
ISO 9001 ISO 9002 ISO 9003

(20)
(18)
(12)
4.1. Responsabilidade gerencial
4.2. Sistema de qualidade
4.3. Reviso contratual
4.4. Controle de desenvolvimento
4.5. Controle de documentao
4.6. Compras
4.7. Compras - produtos fornecidos
4.8. Identificao e rastreabilidade de produtos
4.9. Controle de processo
4.10. Inspeo e testes
4.11. Inspeo, medio e equipamentos de teste
4.12. Verificao de inspeo e teste
4.13. Controle de no conformidade
4.14. Aes corretivas
4.15. Manipulao, armazenamento, embalagem e entrega
4.16. Registros de qualidade
4.17. Auditoria interna de qualidade
4.18. Treinamento
4.19. Servios
4.20. Tcnicas estatsticas
Fonte: [SCHM94] pg. 14
TABELA 1 - Nveis ISO 9000 x elementos padres
4.2. Sistema de qualidade : a empresa deve estabelecer, documentar,

implementar e manter um sistema de qualidade conforme o padro ISO 9000;
deve tambm possuir um manual de qualidade, de acordo com o padro
adotado.
4.3. Reviso contratual: a empresa deve possuir procedimentos para assegurar

que aquilo que foi especificado est adequadamente definido e documentado e
que possui capacidade para satisfazer a estes requisitos. Os contratos devem ser
entendidos e aceitos pelas partes envolvidas, alm de contemplar aquilo que o
fornecedor ir fazer (requerimentos do fornecedor) e o que o fornecedor dever
entregar (requerimentos do produto).
4.4. Controle de desenvolvimento: a empresa deve possuir procedimentos para

controlar e verificar as sadas do processo de desenvolvimento a fim de garantir
que os requisitos sero atendidos; devem ser previstas atividades para cada uma
das etapas do processo, alm de garantir procedimento para controle de
modificaes neste desenvolvimento.
30
21
4.5. Controle de documentao: a empresa deve possuir procedimentos para

controlar todos os documentos, incluindo revises, aprovaes e modificaes,
alm de garantir que o nvel adequado de informao est disponvel para as
pessoas certas no momento necessrio; um sistema ou processo de manuteno
da lista de documentos disponveis tambm exigido. O controle da produo,
reviso, aprovao, modificao e distribuio dos documentos para as pessoas
corretas (alm do processo de obsolescncia destes documentos) tambm
necessrio.
4.6. Compras : a empresa deve possuir procedimentos para garantir que as

partes, obtidas de outras empresas, usadas no produto ou para produzi-lo,
contemplam os requisitos necessrios. A seleo do fornecedores destas partes
normalmente feita a priori, baseada na habilidade deste fornecedor em
fornecer produtos de acordo com uma especificao. A ISO 9000 define que a
empresa responsvel pelo produto como um todo e, a fim de garantir a
qualidade do produto, a inspeo de partes produzidas por outras empresas deve
ser feita de forma criteriosa. A recomendao de que existe uma lista de
fornecedores, com critrios e procedimentos adotados, constantemente
atualizada, incluindo dados sobre posio de mercado, nvel de satisfao com
os produtos j apresentados e outras informaes importantes.
4.7. Compras - produtos fornecidos: a empresa deve possuir procedimentos

para verificao, armazenamento e manuteno de produtos ou partes
fornecidas pelo cliente para a elaborao do produto final. importante
verificar no recebimento desta parte/produto se este est de acordo com o
esperado, uma vez que a partir de ento este ser de responsabilidade da
empresa (isto comum, por exemplo, no processo de reparo de peas, placas de
centrais telefnicas e outros).
4.8. Identificao e rastreabilidade de produtos: a empresa deve possuir

procedimentos para identificar e rastrear produtos durante todos os estgios da
produo, entrega e instalao, possibilitando ao cliente a posio atual de sua
solicitao em um nvel de detalhe adequado.
4.9. Controle de processo: a empresa deve possuir procedimentos para garantir

que a produo est sendo feita sobre condies controladas 21 , incluindo
monitorao de progresso, aprovaes de processo e equipamentos entre outros.
4.10. Inspeo e teste: a empresa deve possuir procedimentos para todos os

nveis de inspeo e testes que devam ser realizados, mantendo um registro de
todos os procedimentos j efetuados.
4.11. Inspeo, medio e equipamentos de teste: a empresa deve possuir

procedimentos para garantir que a preciso dos equipamentos de teste e
inspeo esteja sempre em ordem, envolvendo controle, calibragem, inspees
de manuteno, medies e equipamentos de teste para aferio.
Segundo [SCHM94], "processo em condies controlveis significa processo que no est fora de controle". Este
comentrio importante uma vez que difcil verificar se um processo est sob controle mas certamente fcil
reconhecer quando este est fora de controle.
4.12. Verificao de inspeo e teste: a empresa deve possuir procedimentos

para garantir a verificao da situao dos testes sobre o produto ao longo do
processo produtivo.
4.13. Controle de no conformidade: a empresa deve possuir procedimentos

para controlar produtos que no estejam de acordo com a especificao; devem
incluir procedimentos para tratar estes produtos quando um erro for descoberto.
4.14. Aes corretivas: a empresa deve possuir procedimentos para investigar

as causas das no conformidades dos produtos e assegurar que aes corretivas
sejam tomadas de forma a evitar novas ocorrncias.
4.15. Manipulao, armazenamento, embalagem e entrega: a empresa deve

possuir procedimentos para manipulao, armazenamento, embalagem e
entrega de produtos.
4.16. Registros da qualidade: a empresa deve possuir procedimentos para

identificar e armazenar os registros a fim de demonstrar que a qualidade do
produto est adequada e que o sistema de qualidade implementado funciona
adequadamente.
4.17. Auditoria interna de qualidade: a empresa deve possuir procedimentos

para o planejamento e a realizao de auditorias internas de qualidade,
assegurar a qualificao dos auditores para a conduo destes processos e
verificar se a empresa est realmente fazendo aquilo que o sistema de qualidade
prev. Devem ser realizadas auditorias internas regularmente.
4.18. Treinamento: a empresa deve possuir procedimentos para identificar a

necessidade de treinamento de seu pessoal, providenciar os treinamentos
adequados e manter os registros atualizados com estes treinamentos.
4.19. Servios: a empresa deve possuir procedimentos para suportar os

produtos entregues; inclui procedimentos para a correo de defeitos e no
conformidades encontradas no produto aps este ter sido entregue.
4.20. Tcnicas estatsticas: a empresa deve possuir procedimentos a fim de

garantir que as tcnicas estatsticas que esto sendo utilizadas ao longo do
processo esto adequadas. Devem ser passveis de provas e os algoritmos
devem estar disponveis de forma documentada.
3.4.1.4. ISO 9000-3

A norma ISO 9000-3 (notar que diferente da ISO 9003) traz os roteiros para aplicar a ISO
9001 especificamente na rea de desenvolvimento, fornecimento e manuteno de
software. Todas as orientaes giram em torno de uma "situao contratual", onde uma
outra empresa contrata a empresa em questo para desenvolver um produto de software. A
TABELA 2 - Processos e atividades da ISO 9000-3 - apresenta um resumo das principais
caractersticas desta norma.
Para maiores informaes sobre a ISO 9000-3 recomenda-se [ISO97b] e [SCHM94].
32
Processos
Atividades
Estrutura do Sistema de Qualidade
Responsabilidade do fornecedor
Responsabilidade do comprador
Anlise crtica conjunta
Atividades do Ciclo de Vida
Anlise crtica do contrato

Especificao dos requisitos do comprador
Planejamento do desenvolvimento
Projeto e implementao
Testes e validao
Aceitao
Cpia, entrega e instalao
Manuteno
Atividades de Apoio
Gerenciamento de configurao
Controle de documentos
Registros da qualidade
Medio
Regras, convenes
Aquisio
Produto de software includo
Treinamento
Fonte: [BARR97]
TABELA 2 - Processos e atividades da ISO 9000-3
3.4.2. ISO 9126

Quando se pensa em qualidade de um "produto fsico", fcil imaginar padres de
comparao, provavelmente ligado s dimenses do produto ou a alguma outra
caracterstica fsica. Quando se trata de software, como possvel definir exatamente o que
a qualidade? A norma ISO/IEC 9126 [ISO93] representa a proposta da ISO para
padronizao mundial dos aspectos relativos a qualidade de produtos de software, tendo
sido publicada em 1991. Ela uma das mais antigas da rea de qualidade de software e
possui sua traduo para o Brasil, publicada em agosto de 1996 como NBR 13596
"Tecnologia da Informao - Avaliao de produtos de software - Caractersticas de
qualidade e diretrizes para seu uso" [BARR97].
Estas normas listam o conjunto de caractersticas que devem ser verificadas em um
software para que ele seja considerado um "software de qualidade". So seis grandes
grupos de caractersticas divididos em algumas subcaractersticas. A TABELA 3 Elementos da ISO 9126 - contempla um resumo destas caractersticas.
Esta norma define minuciosamente (em uma linguagem bem detalhada, estilo contrato) o
que se pretende avaliar em cada caracterstica e subcaracterstica. Para maiores
informaes recomenda-se [ISO93].
Caracterstica
Subcaracterstica
Pergunta chave para a subcaracterstica
Adequao
Prope-se a fazer o que apropriado?
Acurcia
Funcionalidade
(satisfaz as
Interoperabilidade
necessidades?)
Conformidade
Segurana de acesso
Faz o que foi proposto de forma correta?

Interage com os sistemas especificados?
Est de acordo com as normas, leis e outros?
Evita acesso no autorizado aos dados?
Maturidade
Confiabilidade
( imune a
Tolerncia a falhas
falhas?)
Recuperabilidade
Com que freqncia apresenta falhas?
Inteligibilidade
Usabilidade
Apreensibilidade
( fcil de usar?)
Operacionalidade
fcil entender o conceito e a aplicao?
Eficincia
( rpido e
"enxuto"?)
Tempo
Qual o tempo de resposta, a velocidade de

execuo?
Recursos
Quanto recurso usa? Durante quanto tempo?
Analisabilidade
fcil de encontrar uma falha, quando ocorre?
Modificabilidade
fcil modificar e adaptar?
Estabilidade
H grande risco quando se faz alteraes?
Testabilidade
fcil testar quando se faz alteraes?
Adaptabilidade
fcil adaptar a outros ambientes?
Manutenibilidade
( fcil de
modificar?)
Portabilidade Capacidade para ser

( fcil de usar instalado
em
Conformidade
outro ambiente?)
Capacidade para
substituir
Ocorrendo falhas, como ele reage?

capaz de recuperar dados em caso de falha?
fcil aprender a usar?

fcil de operar e controlar?
fcil instalar em outros ambientes?

Est de acordo com padres de portabilidade?
fcil usar para substituir outro?
Fonte: [BARR97]
TABELA 3 - Elementos da ISO 9126
3.4.3. ISO 12207, 15271 e 16326

A ISO 12207 [ISO95b] formaliza a arquitetura do ciclo de vida do software, detalhando os
diversos processos envolvidos nestes ciclos de vida. Estes processos esto divididos em
trs classes:
34
Processos Fundamentais - Definem o incio e a execuo do desenvolvimento,

operao ou manuteno do software durante o seu ciclo de vida. A TABELA 4
- Processos Fundamentais da ISO 12207 - apresenta um resumo de suas
caractersticas.
Processos Fundamentais Caractersticas.

Aquisio
Atividades de quem adquire um software. Inclui: definio da

necessidade de adquirir um software (produto ou servio),
pedido de proposta, seleo de fornecedor, gerncia da
aquisio e aceitao do software.
Fornecimento
Atividades do fornecedor de software. Inclui preparar uma

proposta, assinatura de contrato, determinao dos recursos
necessrios, planos de projeto e entrega do software.
Desenvolvimento
Atividades do desenvolvedor de software. Inclui: anlise de

requisitos, projeto, codificao, integrao, testes, instalao e
aceitao do software.
Operao
Atividades do operador do software. Inclui: operao do

software e suporte operacional aos usurios.
Manuteno
Atividades de quem faz a manuteno do software.

Fonte: [BARR97]
TABELA 4 - Processos Fundamentais da ISO 12207
Processos Organizacionais - Definem como implementar uma estrutura

constituda de processos de ciclo de vida e pessoal associados, de forma a
melhorar continuamente a estrutura e os processos. A TABELA 5 - Processos
Organizacionais da ISO 12207 - apresenta um resumo de suas caractersticas.
Processos
Organizacionais
Caractersticas
Gerncia
Gerenciamento de processos.
Infra-estrutura
Fornecimento de recursos para outros processos. Inclui:

hardware, software, ferramentas, tcnicas, padres de
desenvolvimento, operao ou manuteno.
Melhoria
Atividades para estabelecer, avaliar, medir, controlar e

melhorar um processo de ciclo de vida de software.
Treinamento
Atividades para prover e manter pessoal capacitado.

Fonte: [BARR97]
TABELA 5 - Processos Organizacionais da ISO 12207
Processos de Apoio - Definem os processos que auxiliam aos demais processos.

A TABELA 6 - Processos de Apoio da ISO 12207 - apresenta um resumo de
suas caractersticas.
Processos de Apoio
Caractersticas.
Documentao
Registro de informaes produzidas por um processo ou

atividade. Inclui planejamento, projeto, desenvolvimento,
produo, edio, distribuio e manuteno dos documentos
necessrios a gerentes, engenheiros e usurios do software.
Gerncia de Configurao Identificao e controle dos itens do software. Inclui: controle

de armazenamento, liberaes, manipulao, distribuio e
modificao de cada um dos itens que compem o software.
Garantia da Qualidade
Garante que os processos e produtos de software estejam em

conformidade com os requisitos e os planos estabelecidos.
Verificao
Determina se os produtos de software de uma atividade

atendem completamente aos requisitos ou condies impostas
a eles.
Validao
Determina se os requisitos e o produto final (sistema ou

software) atendem ao uso especfico proposto.
Reviso Conjunta
Define as atividades para avaliar a situao e os produtos de

uma dada atividade de um projeto, caso seja apropriado.
Auditoria
Determina adequao aos requisitos, planos e contrato, quando

apropriado.
Resoluo de Problemas
Analisa a resoluo dos problemas de qualquer natureza ou

fonte, descobertos durante a execuo do desenvolvimento,
operao, manuteno ou de outros processos. .
Fonte: [BARR97]
TABELA 6 - Processos de Apoio da ISO 12207

A norma detalha cada um dos processos descritos. Ela define ainda como eles podem ser
usados de diferentes maneiras por diferentes organizaes (ou parte destas), representando
diversos pontos de vista para esta utilizao. Cada uma destas vises representa a forma
como uma organizao emprega estes processos, agrupando-os de acordo com suas
necessidades e objetivos.
As vises tm o objetivo de organizar melhor a estrutura de uma empresa, para definir suas
gerncias e atividades alocadas s suas equipes. Existem cinco vises diferentes: contrato,
gerenciamento, operao, engenharia e apoio. A FIGURA 8 - Processos e vises da ISO
12207 - ilustra como estas vises se relacionam aos processos.
A ISO/IEC 12207 a primeira norma internacional que descreve em detalhes os processos,
atividades e tarefas que envolvem o fornecimento, desenvolvimento, operao e
manuteno de produtos de software. A principal finalidade desta norma servir de
referncia para os demais padres que venham a surgir. Lanada em agosto de 1995, ela
36
citada em quase todos os trabalhos relacionados Engenharia de Software desde ento.

Recomenda-se para aprofundamento as normas ISO 15271 [ISO98a] e ISO 16326
[ISO99b] que foram elaboradas a partir desta norma, complementando-a.
Fonte: [BARR97]
FIGURA 8 - Processos e vises da ISO 12207
3.4.4. ISO 15504 - SPICE

A norma ISO 15504 [ISO98b], mais conhecida como SPICE - Software Process
Improvement and Capability dEtermination, apresenta uma padro para a avaliao do
processo de software, visando determinar a capacitao de uma organizao. A norma visa
ainda orientar a organizao para uma melhoria contnua do processo. Ela cobre todos os
aspectos da Qualidade do Processo de Software e foi elaborada num esforo conjunto de
cinco centros tcnicos espalhados pelo mundo (EUA, Canad/Amrica Latina, Europa,
Pacfico Norte e Pacfico Sul), contando tambm com a participao de uma comisso
formada por profissionais vinculados ABNT (Associao Brasileira de Normas Tcnicas

- http://www.abnt.org.br) [BARR97].
O SPICE inclui um modelo de referncia, que serve de base para o processo de avaliao.
Este modelo um conjunto padronizado de processos fundamentais, que orientam e
garantem a boa engenharia de software. Este modelo dividido em cinco grandes
categorias de processo:
CUS - Cliente-Fornecedor: Processos que impactam diretamente os produtos e

servios de software na relao entre o fornecedor e o cliente:
CUS.1. Adquirir Software
CUS.2. Gerenciar necessidades do Cliente
CUS.3. Fornecer Software
CUS.4. Operar Software
CUS.5. Prover Servio ao Cliente
ENG - Engenharia: Processos que especificam, implementam ou mantm um

sistema ou produto de software e sua documentao:
ENG.1. Desenvolver requisitos e o projeto do sistema
ENG.2. Desenvolver requisitos de software
ENG.3. Desenvolver o projeto do software
ENG.4. Implementar o projeto do software
ENG.5. Integrar e testar o software
ENG.6. Integrar e testar o sistema
ENG.7. Manter o sistema e o software
SUP - Suporte: Processos que podem ser empregados por qualquer um dos
outros processos
SUP.1. Desenvolver a documentao
SUP.2. Desempenhar a gerncia de configurao
SUP.3. Executar a garantia da qualidade
SUP.4. Executar a verificao dos produtos de trabalho
SUP.5. Executar a validao dos produtos de trabalho
SUP.6. Executar revises conjuntas
SUP.7. Executar auditorias
SUP.8. Executar resoluo de problemas
MAN - Gerncia: Processos que contm prticas de natureza genrica que

podem ser usadas por quem gerencia projetos ou processos dentro de um ciclo
de vida de software:
MAN.1. Gerenciar o projeto
MAN.2. Gerenciar a qualidade
MAN.3. Gerenciar riscos
38
MAN.4. Gerenciar subcontratados
ORG - Organizao: Processos que estabelecem os objetivos de negcios da

organizao:
ORG.1. Construir o negcio
ORG.2. Definir o processo
ORG.3. Melhorar o processo
ORG.4. Prover recursos de treinamento
ORG.5. Prover infra-estrutura organizacional
A norma define detalhes de cada um dos processos mencionados. Para cada um deles
existe uma definio mais detalhada, uma lista dos resultados da sua implementao bem
sucedida e uma descrio detalhada de cada uma das prticas bsicas. Vale ressaltar que
esta norma tambm foi gerada a partir da ISO 12207 [ISO95b] descrita anteriormente.
O SPICE, entretanto, no se limita a listar categorias e processos. Seu principal objetivo,
na realidade, avaliar a capacitao da organizao em cada processo e permitir a sua
melhoria. O modelo de referncia do SPICE inclui seis nveis de capacitao:
Nvel 0 - Incompleto: Tem como caractersticas falhas gerais ao se realizar o

objetivo do processo. No existem produtos de trabalho nem sadas do processo
facilmente identificveis;
Nvel 1 - Realizado: O objetivo do processo em geral atingido, embora no

necessariamente de forma planejada e controlada. H um consenso na
organizao de que as aes devem ser realizadas e quando so necessrias.
Existem produtos de trabalho para o processo e eles so utilizados para atestar o
atendimento dos objetivos.
Nvel 2 - Gerenciado: O processo produz os produtos de trabalho com

qualidade aceitvel e dentro do prazo. Isto feito de forma planejada e
controlada. Os produtos de trabalho esto de acordo com padres e requisitos.
Nvel 3 - Estabelecido: O processo realizado e gerenciado usando um

processo definido, baseado em princpios de Engenharia de Software. As
pessoas que implementam o processo usam processos aprovados, que so
verses adaptadas do processo padro documentado.
Nvel 4 - Predizvel: O processo realizado de forma consistente, dentro dos

limites de controle, para atingir os objetivos. Medidas da realizao do processo
so coletadas e analisadas. Isto leva a um entendimento quantitativo da
capacitao do processo, produzindo a habilidade de predizer a realizao.
Nvel 5 - Otimizado: A realizao do processo otimizada para atender s

necessidade atuais e futuras do negcio. O processo atinge seus objetivos de
negcio e consegue ser repetido. So estabelecidos objetivos quantitativos de
eficcia e eficincia para o processo, segundo os objetivos da organizao. A
monitorao consistente do processo segundo estes objetivos conseguida
obtendo feedback quantitativo e o melhoramento conseguido pela anlise dos
resultados. A otimizao do processo envolve o uso piloto de idias e
tecnologias inovadoras, alm da mudana de processos ineficientes para atingir
os objetivos definidos.
Cada um dos processos mencionados anteriormente deve ser classificado nestes nveis;
com isso, obtm-se uma matriz que contempla os nveis de cada processo executado pela
organizao, que servir para avaliar a situao atual e promover melhorias nos pontos
crticos.
A norma ISO 15504 consiste em nove manuais, a saber:
Parte 1 - Guia de Introduo e Conceitos
Parte 2 - Modelo de referncia para processos e capacidade de processos
Parte 3 - Realizando uma avaliao
Parte 4 - Guia para realizao de uma avaliao
Parte 5 - Um modelo de avaliao e guia de indicadores
Parte 6 - Guia para qualificao de avaliadores
Parte 7 - Guia para uso no melhoramento de processos
Parte 8 - Guia para uso na determinao da capacidade do processo do

fornecedor
Parte 9 - Vocabulrio
A ltima edio publicada destes volumes de 1998 (exceto o volume 5, cuja ltima
atualizao de 1999). Maiores informaes em [ISO98b] e [BELL97].
3.4.5. SEI - CMM

3.4.5.1. Histrico
Em novembro 1986, o SEI, em conjunto com a Mitre Corporation, iniciaram o
desenvolvimento de um modelo (framework) de maturidade de processo que pudesse
auxiliar s organizaes a evoluir seus processos de software. Este esforo foi iniciado a
fim de atender a um pedido do governo federal norte-americano no sentido de prover um
mtodo que garantisse a capacitao de seus fornecedores de software. Em setembro 1987
a SEI publicou uma pequena descrio do modelo de maturidade de processo e um
questionrio de maturidade [HUMP95]. A SEI pretendia utilizar este questionrio como
uma ferramenta para identificar quais reas do processo de software das organizaes
pesquisadas necessitavam de melhorias. Infelizmente as empresas trataram o questionrio
como modelo - e no como veculo para explorar os principais aspectos do processo de
maturidade.
Aps quatro anos de experincia com o modelo de maturidade do processo de software e a
verso preliminar do questionrio de maturidade, a SEI gerou o Modelo de Capacidade e
Maturidade para Software (CMM), em 1991 [PAUL93]. O CMM baseado no
conhecimento adquirido e acumulado pelos processos de desenvolvimento de software e
pelo extensivo feedback 22 obtido tanto das indstrias quanto do governo [CMU95].
22
Neste trabalho est sendo mantida a palavra em seu original em ingls (feedback) em funo desta estar sendo utilizada
pelo mercado na grafia original; no caso de traduo, entende-se pelos processos de retorno a uma dada ao ou
processo, envolvendo crticas, sugestes e identificao de pontos positivos e pontos a melhorar.
40
A verso inicial do CMM (verso 1.0) foi revisada e utilizada pela comunidade de software
durante os anos de 1991 e 1992. Um encontro foi realizado em abril 1992, do qual
participaram cerca de 200 profissionais de software; como resultado deste encontro foi
gerada a verso 1.1 [PAUL93].
3.4.5.2. Conceitos utilizados
O CMM uma base para a construo sistemtica de um conjunto de ferramentas,
incluindo o questionrio de maturidade, o qual til no processo de melhoria da qualidade
do software. O ponto essencial a ser sempre lembrado que o modelo - e no o
questionrio - forma a base para o aprimoramento do processo de software.
A estratgia promover a evoluo da engenharia de software de uma atividade
desordenada e dispendiosa para uma atividade gerenciada, disciplinada e com qualidade de
produtos controlada23 .
O CMM, sendo um modelo para Software Process Improvement (SPI), no define como
implementar, e sim orienta na aplicao dos conceitos de gerncia de projetos e de
melhoria de qualidade para desenvolvimento e manuteno de software.
Entende-se por processo de software um conjunto de atividades, mtodos, prticas e
transformaes que pessoas utilizam para desenvolver e manter software e seus produtos
associados tais como planos de projeto, documentao, cdigo, casos de teste e os manuais
do usurio [PAUL93]. Como resultado de uma organizao madura, o processo de
software torna-se melhor definido e mais consistentemente implementado atravs da
organizao. Nota-se que o CMM avalia a empresa como um todo e no uma iniciativa
isolada de apenas parte da empresa.
A capacidade do processo de software descreve o conjunto de resultados que podem ser
atingidos seguindo-se um processo de software. A capacidade do processo de software de
uma organizao prov um meio de antecipar como sero os resultados com o prximo
projeto de software que esta organizao ir conduzir.
O desempenho do processo de software representa os resultados reais atingidos seguindose o processo de software. Portanto o desempenho do processo de software tem seu foco
nos resultados obtidos enquanto que a capacidade do processo de software foca os
resultados esperados. Baseado nos atributos de um projeto especfico e no contexto de
como ele foi conduzido, o desempenho real de um projeto pode no refletir a capacidade
total do processo de software da organizao, isto , a capacidade do projeto restrita pelo
ambiente. Por exemplo, mudanas radicais na aplicao e na tecnologia podem fazer com
que os recursos alocados ao projeto tenham que passar por treinamentos que podem afetar
a capacidade e o desempenho do projeto.
Maturidade do processo de software uma extenso de como um processo especfico
explicitamente definido, gerenciado, medido, controlado e produzido; implica em um
potencial para crescimento na capacidade e indica que isto aplicvel a toda organizao
(e no apenas a uma rea restrita). O processo de software melhor entendido pelas
organizaes maduras, usualmente atravs de documentao e treinamento, e o processo
23
Um referncia bastante interessante, que procura utilizar estes conceitos na engenharia de software, pode ser obtida em
[FIOR98].
continuamente monitorado e aperfeioado pelos seus usurios [MELL99a]. Maturidade no

processo de software implica que a produtividade e a qualidade resultante do processo de
software de uma dada organizao podem ser sempre melhorados atravs de anlise do
histrico dos processo j realizados utilizando este processo de software, revisando-o e
mantendo este histrico organizado e atualizado. Isto feito atravs da institucionalizao
de polticas, padres e estruturas organizacionais que suportem, de forma corporativa, este
processo [PAUL93].
3.4.5.3. Nveis de maturidade em software
O CMM est organizado em cinco nveis, de acordo com a maturidade das organizaes no
tocante ao processo de software. Estes cinco nveis definem uma escala para medir e
classificar a maturidade do processo de software de uma dada organizao e para avaliar a
capacidade do processo de software; estes nveis tambm auxiliam s organizaes a
priorizar seus esforos nas reas carentes [PIRE00]. A FIGURA 9 - Viso geral da
estrutura do CMM - ilustra estes nveis e suas caractersticas principais.
Processo
Melhorando
Continuamente
Processo
Previsvel
Processo Padro e
Consistente
Processo
Disciplina
do
(4) Gerenciado
(3) Definido
(2) Repetitivo
(1) Inicial
(5) Otimizado
Melhoria
contnua um
modo de vida
Processo medido
e controlado
O processo est
caracterizado e bem
entendido (foco na
organizao)
Sucesso em tarefas
previamente dominadas
(foco no gerenciamento)
Imprevisvel e
insatisfatoriamente
controlado
Fonte: [PAUL93] - pg. 25; [CRED99] -pg. 4 e [CMU95] - pg. 16
FIGURA 9 - Viso geral da estrutura do CMM

Cada nvel de maturidade prov um conjunto de regras para a evoluo contnua do
processo de software; so compostos de um conjunto de objetivos de processo que, quando
satisfeitos, tornam-se importantes componentes no processo de software. Para atingir cada
nvel de maturidade do modelo necessrio o estabelecimento de diversas polticas e
processos de software, resultando em aperfeioamento e capacitao da organizao.
Vale destacar que o nvel 1 (Inicial) o ponto de partida para a aplicao do CMM, ou seja,
marcado pela ausncia de controles satisfatrios.
42
O segundo nvel (Repetitivo) marcado pelo estabelecimento de processos bsicos de

gerenciamento de projetos a fim de verificar e acompanhar custos, prazos e funcionalidade.
Um mnimo de disciplina no processo de armazenamento destas informaes requerido a
fim de repetir os sucessos obtidos com projetos similares j realizados.
O terceiro nvel (Definido) caracterizado pela documentao, padronizao e integrao
dos processos de software, tanto gerenciais quanto tcnicos, para uma organizao como
um todo. Todos os projetos passam por processos formais de aceitao na organizao,
tanto os projetos de desenvolvimento quanto os projetos de manuteno.
O quarto nvel (Gerenciado) marcado pela coleta de medidas detalhadas do processo de
software e do produto final, com vistas a garantia da qualidade. Tanto o processo de
software quanto o produto final produzido so quantitativamente compreendidos e
controlados pela organizao.
O quinto nvel (Otimizado) caracterizado pelo contnuo processo de melhoria, habilitado
por feedback quantitativo a partir dos processos e a partir da introduo, sempre
acompanhada e avaliada, de novas idias e tecnologias.
3.4.5.4. Gerenciamento de software e o CMM
Fonte: [PAUL93] - pg. 37
FIGURA 10 - Viso gerencial sobre a visibilidade do processo de software a cada

nvel do CMM
Um dos benefcios a serem conseguidos com a evoluo das organizaes luz do CMM
a maior transparncia e efetividade nos processos de gerenciamento. A FIGURA 10 -
Viso gerencial sobre a visibilidade do processo de software a cada nvel do CMM,

apresentada em [PAUL93], ilustra a visibilidade gerencial em cada um dos cinco nveis.
A visibilidade gerencial no nvel 1 nula, totalmente obscura; causando aos gerentes uma
total incompreenso da real situao de cada projeto 24 . No nvel 2 comeam a existir
marcos gerenciais - ainda que internamente a estes marcos continuem existindo "caixas
pretas" - que possibilitam um mnimo de repetio e controle no processo; a postura do
gerente ainda reativa, ou seja, ele apenas reage aos problemas medida que estes
ocorram.
No nvel 3 a estrutura interna das "caixas pretas" do nvel 2 - as atividades envolvidas no
processo de software - passam a estar visveis. Tanto o pessoal tcnico quanto o pessoal
gerencial entendem as regras e responsabilidades sobre o processo e como as atividades
interagem a cada nvel de detalhe. Os gerentes passam a ter postura pr-ativa no que diz
respeito a riscos que possam via a ocorrer.
FIGURA 11 - Capacidade de estimar e medir resultados dos projetos a cada nvel do

CMM
24
[PAUL93] comenta que esta a sndrome dos "noventa porcento", ou seja, 90% dos projetos em desenvolvimento
esto com progresso em 90%. Infelizmente este percentual sempre mantido...
44
No nvel 4 o processo de software documentado e controlado de forma quantitativa. Os

gerentes esto habilitados a mensurar progressos e problemas dos projetos; tambm tem
bases objetivas e quantitativas para a tomada de decises.
No nvel 5 novas formas de melhoria de construo de software so continuamente
testadas, de forma controlada, a fim de melhorar a produtividade e a qualidade. A
disciplina j implementada procura identificar formas ineficientes atualmente adotadas e
substitu-las por processos otimizados. Os gerentes esto habilitados a estimar e a
simular/avaliar os impactos quantitativos e a efetividade das mudanas.
Outro grande benefcio a ser conseguido com a evoluo das organizaes luz do CMM
a melhoria do ndice de previso e de alcance dos reais objetivos dos projetos. A FIGURA
11 - Capacidade de estimar e medir resultados dos projetos a cada nvel do CMM,
apresentada por [PAUL93], ilustra esta melhoria em cada um dos cinco nveis.
Vale destacar que no nvel 1 a meta inicial (target) anterior ao do nvel 2 muito mais em
funo da total falta de histrico e ausncia de mecanismos formais de estabelecimento de
metas; de fato, numa primeira observao percebe-se que esta meta inicial ser atrasada mas certamente j muito mais real que a observada no nvel 1. A evoluo gradual, com
as metas sendo antecipadas e o grau de incerteza sendo gradativamente diminudo.
Percebe-se ento que como resultados atingidos tem-se uma maior aproximao entre a
estimativa original e o resultado atingido aps a realizao do projeto; uma concentrao
maior de projetos nesta rea da estimativa inicial e uma antecipao no processo de
estimativas, provocado pela substituio das tradicionais "folgas" - muitas vezes no
baseada em fatos concretos - por estimativas a partir de histricos de projetos j efetuados.
3.4.5.5. Estrutura do CMM
Com relao estrutura do CMM, cada nvel pode ser decomposto em partes 25
componentes, conforme ilustra a FIGURA 12 - Componentes de cada nvel do CMM,
apresentada em [PAUL93].
Cada nvel de maturidade composto por vrias reas chaves de processo (key process
areas - KPA); cada KPA organizada em cinco sees chamadas de funes comuns; cada
funo comum especifica as prticas chaves que, quando coletivamente (toda a
organizao) endereada, torna possvel atingir os objetivos da rea chave de processo.
3.4.5.5.1. reas chaves de processos
A FIGURA 13 - reas chave de processo para cada nvel do CMM - ilustra as KPA de cada
nvel do CMM [PAUL93].
reas chaves de processo (KPA) indicam onde uma organizao deve focalizar a melhoria
dos processos de software. A identificao da sada que deve ser concluda com xito em
um dado nvel de maturidade pode ser visualizada na FIGURA 13 - reas chave de
processo para cada nvel do CMM.
25
Sempre a partir do nvel 2 (Repetitivo). O nvel 1 (Inicial) apenas um marco introdutrio (ausncia de controle).
FIGURA 12 - Componentes de cada nvel do CMM

Cada rea chave do processo, identifica um ramo de atividades relativas, que, quando
realizadas coletivamente, terminam com xito uma srie de metas consideradas
importantes para o aumento da capacidade dos processos. O caminho para realizar com
xito estas metas pode variar por projeto, dependendo do domnio da aplicao ou do
ambiente. Todavia, todas as metas de uma rea de processo deve ser realizada com xito
por toda a organizao para satisfaz-la.
O uso da palavra "chave" implica que existem reas de processo (e processos) que no so
chave para resultar em um nvel de maturidade. O CMM no descreve em detalhes todas as
reas de processo envolvidas com o desenvolvimento e manuteno do software, apenas
aquelas que devem ser identificadas como chaves definidas de capacidade dos processos.
reas chaves do processo podem ser vistas como requerimentos para solues de nveis de
maturidade. Para se atender com xito um dado nvel de maturidade, as reas chaves de
processo para o nvel devem estar satisfeitas/realizadas - vale lembrar que o nvel 1 no
tem reas chaves de processos.
Cada rea chave acompanhada por cinco caractersticas que definem as prticas chaves:
46
Compromisso para realizar os preceitos da rea-chave.
Habilidade para realizar estes preceitos.
Forma como estas atividades esto sendo realizadas.
Medio e anlise da efetividade.
Verificao da implementao dos preceitos.
FIGURA 13 - reas chave de processo para cada nvel do CMM

A prtica especfica a ser executada em cada rea chave de processo poder envolver
caractersticas de nveis mais elevados de maturidade. Por exemplo: para se atingir muitas
das estimativas de projetos descritas como capacidade em planejamento de projetos na rea
chave de processo para o nvel 2 devem envolver o processo de coleta dos dados presente
no nvel 3.
3.4.5.5.2. reas chaves de processos para o nvel 2 do CMM
A rea chave de processo no nvel 2 focaliza-se no que se refere determinao dos

controles para os administradores do projeto.
Gerenciamento de requisitos : significa estabelecer um entendimento comum

entre um cliente (requisitante) e uma equipe de projeto do produto requerido.
Este consentimento a base para o planejamento e o gerenciamento de um
projeto.
Planejamento do projeto de software: significa estabelecer planos razoveis

para a engenharia e administrao do projeto.
Rastreabilidade do projeto de software - plano de contingncia: significa

estabelecer visibilidade adequada dentro do progresso atual, garantindo desta
maneira que o gerenciamento pode ter aes efetivas quando a execuo de um
projeto desviar-se significativamente dos planos.
Gerenciamento do subcontratados (terceiros e fornecedores) de software:

significa selecionar subcontratados qualificados e gerir os contratos em funo
do projeto.
Garantia de qualidade software: significa estabelecer gerenciamento com

visibilidade apropriada dentro da existncia dos processos usados e a existncia
dos produtos criados.
Gerenciamento de configurao do software: significa estabelecer e manter a

integridade de um projeto de produtos por todo o ciclo de vida.
As reas chaves de processo do nvel 3 endeream tanto projeto quanto organizao

empresarial, com o estabelecimento de uma infra-estrutura que institucionaliza a
engenharia de software efetiva e a gerncia de processos sobre todos os projetos.
Foco nos processos da organizao: significa uma responsabilidade

organizacional para atividades que melhoram-na como um todo e aumente a
capacidade dos processos de software.
Definio dos processos da organizao: significa desenvolver e manter um

conjunto usvel de processos ativos que melhoram os processos sobre projetos e
abastecem uma base de informaes importantes para o gerenciamento
quantitativo dos processos. Estes ativos so fundamentos que podem ser
institucionalizados atravs de bons mecanismos de treinamento.
Programa de treinamento: significa desenvolver habilidades e conhecimento

de indivduos a fim de que desta forma eles possam ser teis e eficientes.
Treinamento uma responsabilidade organizacional, mas os projetos deveriam
identificar habilidades necessrias e providenciar treinamentos especficos
quando suas necessidades so nicas.
Gerenciamento integrado de software: significa integrar a engenharia de

software e o gerenciamento das atividades de forma coerente, definindo os
processos que esto sendo executados a partir de um modelo da organizao do
48
processo de software e o relato dos processos ativos. A integrao est baseada

no ambiente de negcios e nas tcnicas necessrias a um projeto.
Engenharia de produtos de software: significa executar consistentemente um

processo bem definido que integra todas as atividades tcnicas - anlise,
projeto, desenho, codificao e teste, entre outros - com a finalidade de produzir
corretamente e consistentemente produtos de software teis e eficientes.
Coordenao entre grupos : significa estabelecer um caminho para que um

grupo de engenharia de software participe ativamente com outros grupos de
engenharia, fazendo assim com que uma equipe de projeto possa satisfazer
melhor as necessidades do usurio (requisitante).
Revises/inspees peridicas : significa remover defeitos de trabalhos de

forma fcil e eficiente. Uma importante medida desenvolver um bom
entendimento dos produtos do trabalho e prevenir defeitos. As revises
sugeridas so um importante e efetivo mtodo que pode ser implementado com
inspees completas ou procedimentos completos de forma estruturado.
As reas chave de processo para o nvel 4 visam estabelecer um entendimento quantitativo

do processo de desenvolvimento de software e do processo de trabalho criado pelo produto
gerado com o software.
Gerenciamento quantitativo do processo: significa controlar a execuo de

forma quantitativa de um processo de software; inclui o resultado atualmente
obtido atravs da comparao com processos de software anteriormente
executados. O foco est na identificao das causas fundamentais da variao
entre a medida do processo atual e o previsto.
Gerenciamento da qualidade de software: significa desenvolver um

entendimento quantitativo/qualitativo do projeto dos produtos de software para
obter a meta especificada de qualidade.
As reas chave do processo para o nvel 5 focalizam-se nas modificaes que ambas,
organizao e projeto, tem que implementar visando aprimoramento contnuo e baseado
nas melhorias obtidas a partir das medies dos processo realizados.
Preveno de defeitos: significa identificar as causas dos defeitos e preveni-las

contra possibilidade de volta atravs da anlise e da mudana dos processos
definidos.
Gerenciamento das mudanas de tecnologia: significa identificar os

benefcios das novas tecnologias (como ferramentas, mtodos e processos) e
transferi-las para a organizao de maneira ordenada. O foco aqui a eficincia
interna que a inovao poder trazer.
Gerenciamento das mudanas do processo: significa continuamente melhorar

os processos de uma organizao com o intuito de melhorar a qualidade,
aumentar a produtividade e diminuir o tempo de desenvolvimento de software.
A preocupao do presente trabalho conhecer os preceitos do CMM e utiliz-lo, sempre

em comparao com outros modelos, para procurar responder s perguntas chaves desta
dissertao - o gerenciamento de projetos de TI poderia ser otimizado com a introduo de
prticas de gerenciamento de projetos tradicionalmente utilizadas em outras reas? Quais
as adaptaes necessrias para o tratamento de software? Como relacionar isto aos
modelos especficos para o desenvolvimento de software (como o CMM)? O captulo 5 Anlise comparativa - faz estas consideraes.
3.4.5.5. Adoo do CMM pelas empresas
A FIGURA 14 - Classificao de empresas americanas nos nveis do CMM - ilustra o
mercado americano de produo de software no incio da difuso dos conceitos do CMM.
Fonte: Byte junho/1994
FIGURA 14 - Classificao de empresas americanas nos nveis do CMM

As empresas que desejam adotar o CMM como padro para seus processos de software
podem se submeter a auditoria para a verificao e enquadramento em qual nvel do CMM
a mesma se encontra. Normalmente as empresas fazem um trabalho preliminar de
preparao, contando com o apoio de empresas de consultoria, a fim de estabelecer as
reas chaves, verificar a uniformidade do processo ao longo de toda a organizao, realizar
auditorias prvias para ento se submeter a uma certificao efetiva. No Brasil o principal
rgo certificador a Fundao Vanzolini (http://www.vanzolini.org.br).
Com relao adoo do CMM pelas empresas nacionais tem-se que poucas so
certificadas e das j certificadas a maioria est nos nveis 2 e 3. Em [VOLP97] tem-se
como a NEC Brasil est se estruturando e iniciando o processo de certificao CMM; outro
exemplo pode ser obtido em [CRED99], onde a Credicard S/A apresenta os resultados
obtidos com a implantao do modelo CMM e seu processo de enquadramento inicial nvel 2 - visando a implantao dos processos adequados para obteno do nvel 3. Em
[WEBE99] so apresentados alguns dados referentes s pesquisas efetuadas pela
SEPIN/MCT (Secretaria de Poltica de Informtica e Automao do Ministrio da Cincia
50
e Tecnologia) em conjunto com PBQP/SSQP-SW (Programa Brasileiro de Qualidade e

Produtividade em Software) nos anos de 1993, 1995 e1997, apresentando um panorama do
uso dos padres de qualidade pelas empresas nacionais.
3.4.6. PSP - Personal Software Process

O modelo SEI-CMM muito interessante, mas aplica-se mais a grandes empresas de
software; o prprio SEI acabou percebendo que havia a necessidade de definir um modelo
mais simples, voltado para pequenas empresas ou at para um nico indivduo. Foi da que
surgiu o PSP, que significa "Processo Pessoal de Software".
Assim como o CMM, no modelo PSP, existem diversos nveis com caractersticas prprias.
A TABELA 7 - Nveis e atividades do modelo SEI-PSP - ilustra estes diversos nveis.
Nvel
Nome
Atividades
PSP0
PSP0.1
Medio Pessoal
Registro de tempo
Registro de defeitos
Padro de tipos de defeitos
Padro de codificao
Medida de tamanho
Proposta de melhorias do processo
PSP1
PSP1.1
Planejamento Pessoal
Estimativa de tamanho
Relatrio de testes
Planejamento de tarefas
Cronogramas
PSP2
PSP2.1
Qualidade Pessoal
Revises de cdigo
Revises de projeto
Padres de projeto
PSP3
Processo Cclico Pessoal Desenvolvimento cclico

Fonte: [BARR97]
TABELA 7 - Nveis e atividades do modelo SEI-PSP

No nvel PSP0 - Medio Pessoal o indivduo/organizao aprende a registrar o tempo
gasto em cada etapa do ciclo do desenvolvimento, registrando ainda os defeitos
encontrados. Isto conseguido atravs do uso de formulrios adequados. O sub-nvel
PSP0.1 inclui o uso de um padro de codificao, de medidas padronizadas e do
formulrio de proposta de melhorias de processo.
No nvel PSP1 - Planejamento Pessoal o indivduo/organizao aprende a planejar. A
idia geral obter a capacidade de estimar quanto tempo levar para realizar uma tarefa
baseado nas medies feitas em tarefas semelhantes realizadas anteriormente. Neste nvel
aprende-se a assumir compromissos que podem realmente ser cumpridos. O sub-nvel
PSP1.1 inclui o planejamento de tarefas e a elaborao de cronogramas.
No nvel de PSP2 - Qualidade Pessoal o indivduo/organizao aprende a lidar com seus

erros. Deve-se ter uma idia precisa de quantos erros so cometidos (em mdia) em cada
fase do ciclo de desenvolvimento. O modelo PSP mostra que a forma mais adequada para
tratar erros evit-los desde a sua origem. O indivduo/organizao deve utilizar os dados
sobre defeitos j coletados para criar uma lista de verificao (checklist) a ser utilizada em
revises de projeto e de cdigo. O sub-nvel PSP2.1 inclui a criao de padres de projeto,
bem como mtodos de anlise e preveno de defeitos.
O nvel de PSP3 - Processo Cclico Pessoal a ltima etapa do PSP. Neste nvel, o PSP
sai do desenvolvimento de pequenos programas para tratar do desenvolvimento de projetos
maiores, embora ainda em nvel pessoal. A idia dividir os grandes projetos em pequenos
projetos que possam ser tratados no PSP2. Neste caso, o desenvolvimento acontece em
passos incrementais.
Segundo [BARR97], o treinamento do PSP realizado atravs de 10 exerccios de
desenvolvimento de programas. Alm de servirem como exemplos de desenvolvimento, os
exerccios propostos no treinamento do PSP so pequenos utilitrios que ajudam aos
indivduos e organizaes a aplicarem o PSP, pois permitem medir o nmero de linhas e
objetos nos seus programas, calcular desvio padro, prever intervalos etc.
Uma descrio completa deste modelo e do treinamento proposto pode ser encontrada em
[HUMP96] 26 , [BELL97] e [RAPC98].
26
Watts Humphrey considerado como o pai do PSP.
52
Cap. 4 Padres de gerenciamento de projetos
4. PADRES DE GERENCIAMENTO DE PROJETOS
4.1. ISO 10006

A norma ISO 10006 [ISO97a] se refere a atividades de gerenciamento da qualidade no
tocante ao gerenciamento de projetos; prov guias para os elementos do sistema de
qualidade, conceitos e prticas para aprimorar e garantir a qualidade no processo de
gerenciamento de projetos, sendo suplementar norma ISO 9004. Foi desenvolvida para
ser aplicada ao gerenciamento de projetos de qualquer porte ou complexidade, servindo de
base para que profissionais de gerenciamento de projetos e auditores de qualidade possam
trocar experincias a respeito do projeto. Tambm teve por base a norma ISO 10005
[ISO95a], aplicvel mais especificamente na a elaborao de planos de qualidade.
Essa norma faz a distino entre os dois aspectos bsicos da aplicao dos conceitos de
qualidade no gerenciamento de projetos: a qualidade do processo do projeto e a qualidade
do produto do processo, considerando que ambos aspectos so vitais para o sucesso dos
projetos, requerendo uma abordagem sistemtica e contnua de forma a garantir a
conformidade.
Tambm descreve de forma resumida os processos de gerenciamento de projetos que so
considerados como aplicveis maioria dos projetos [ISO97a]. Esto agrupados por
afinidade em dez grupos:
Grupo de processos estratgicos: primeiro grupo, relativo aos processos

estratgicos necessrios para legitimar e definir direes para o projeto
(clusula 5.2 27 [ISO97a]);
Grupo de processos de gerenciamento de interdependncia: o segundo

grupo que tem por finalidade gerenciar as interdependncias entre os outros
processos; tem como processos principais:
5.3.1. Iniciao do projeto e desenvolvimento do plano do projeto:

consiste na anlise dos requisitos dos clientes e demais stakeholders,
preparao de um plano de projeto e incio dos demais processos.
5.3.2. Gerenciamento das interaes: consiste na forma de gerenciar as

interaes ao longo do projeto.
5.3.3. Gerenciamento de mudanas: consiste em antecipar s mudanas e

gerenci-las ao longo do projeto.
5.3.4. Encerramento: consiste em encerrar os processos e obter feedback.
Grupo de processos relacionados ao escopo: tem por finalidade gerenciar as

relaes envolvendo escopo do projeto, tendo como processos principais:
27
5.4.1. Desenvolvimento dos conceitos: consiste na definio genrica

daquilo que o produto do projeto dever ser.
A clusula se refere ao tpico da norma ISO 10006, facilitando sua referncia.
53
5.4.2. Desenvolvimento e controle de escopo: consiste na documentao

das caractersticas do produto a ser produzido pelo projeto em termos
mensurveis e controlveis.
5.4.3. Definio de atividades: consiste na identificao e documentao

das atividades e tarefas requeridas para que o projeto atinja seus objetivos.
5.4.4. Controle de atividades: consiste em controlar o trabalho que est

sendo realizado pelo projeto.
Grupo de processos relacionados ao tempo: tem por finalidade gerenciar as

relaes envolvendo tempo/prazos no projeto, tendo como processos principais:
5.5.1. Planejamento de dependncias de atividades: consiste na

identificao de relacionamentos e interaes lgicas, alm das
dependncias, entre as atividades do projeto.
5.5.2. Estimativa de durao: consiste na estimativa de durao de cada

atividade associada com condies especficas e com os recursos
necessrios para realiz-la.
5.5.3. Desenvolvimento do cronograma: consiste na identificao das

relaes entre as metas de tempo para o projeto, as dependncias entre as
atividades e suas duraes estimadas, visando a construo de um modelo
(cronograma) para o desenvolvimento geral e posteriores detalhamentos do
projeto.
5.5.4. Controle do cronograma: consiste no controle de realizao das

atividades do projeto em conformidade com o cronograma proposto,
tomando as medidas adequadas para reconduzir o andamento ao
inicialmente acordado.
Grupo de processos relacionados ao custo: tem por finalidade gerenciar as

relaes envolvendo custo no projeto, tendo como processos principais:
5.6.1. Estimativa de custo: consiste no desenvolvimento das estimativas de

custo para o projeto.
5.6.2. Oramento: consiste na utilizao dos resultados das estimativas de

custo de forma a produzir um oramento para o projeto.
5.6.3. Controle de custo: consiste no controle dos custos e medidas a fim

de evitar desvios em relao ao oramento.
Grupo de processos relacionados aos recursos: tem por finalidade gerenciar

as relaes envolvendo os recursos necessrios ao projeto, tendo como
processos principais:
5.7.1. Planejamento de recursos: consiste em identificar, estimar, nivelar,

distribuir e associar/alocar todos os recursos relevantes para o projeto.
5.7.2. Controle de recursos: consiste na comparao do consumo atual de

recursos frente ao previsto, tomando aes para evitar desvios.
Grupo de processos relacionados ao pessoal: tem por finalidade gerenciar as

relaes envolvendo o pessoal necessrio ao projeto, tendo como processos
principais:
54
5.8.1. Definio da estrutura organizacional: consiste na definio da

estrutura organizacional necessria para possibilitar a execuo adequada do
projeto, incluindo regras para o projeto e definindo autoridades e
responsabilidades.
5.8.2. Alocao de pessoal: consiste na seleo e na contratao (ou

alocao) do pessoal necessrio com as competncias 28 apropriadas para as
necessidades do projeto.
5.8.3. Desenvolvimento do time do projeto: consiste no desenvolvimento

das necessidades individuais e coletivas do grupo, objetivando melhorias
nas competncias e habilidades a fim de otimizar a performance do projeto.
Grupo de processos relacionados comunicao: tem por finalidade

gerenciar as relaes envolvendo as comunicaes necessrias ao projeto, tendo
como processos principais:
5.9.1. Planejamento da comunicao: consiste em planejar as informaes

e sistemas de comunicaes para o projeto.
5.9.2. Gerenciamento das informaes: consiste em tornar as informaes

necessrias disponveis para o time do projeto e para os demais
stakeholders.
5.9.3. Controle das comunicaes: consiste em controlar as comunicaes

de acordo com o plano de comunicaes.
Grupo de processos relacionados ao risco: tem por finalidade gerenciar as

relaes envolvendo os riscos existentes no projeto, tendo como processos
principais:
5.10.1. Identificao do risco: consiste na determinao dos riscos

envolvidos com o projeto.
5.10.2. Estimativa de risco: consiste em analisar a probabilidade da

ocorrncia de um evento de risco e o impacto deste evento de risco no
projeto.
5.10.3. Desenvolvimento de respostas ao risco: consiste em desenvolver

um plano de resposta aos riscos.
5.10.4. Controle de risco: consiste em implementar e atualizar o plano de

resposta aos riscos.
Grupo de processos relacionados s compras: tem por finalidade gerenciar as

relaes envolvendo as compras relativas ao projeto, tendo como processos
principais:
28
5.11.1. Planejamento e controle de compras: consiste em identificar e

controlar o que ser comprado e quando.
Utiliza-se o termo competncia para definir "a capacidade de executar algo no mundo real, diferenciando-se do
conhecimento - que sempre pragmtico - por exigir mais do que informao - exige um conhecimento pessoal e a
demonstrao de uma habilidade" [SETZ99]. Apenas para ilustrar o caso especfico de software, a Microsoft fez um
levantamento de suas competncias referente aos processos de desenvolvimento de software e chegou ao nmero de
trezentas competncias diferentes [DAVE98].
55
5.11.2. Documentao dos requisitos: consiste em compilar as condies

comerciais e tcnicas dos requisitos.
5.11.3. Avaliao de fornecedores: consiste em avaliar e determinar quais

fornecedores podem ser convidados para o fornecimentos dos produtos.
5.11.4. Subcontratao: consiste em controlar as atividades relativas a

propostas, avaliao das propostas, negociao, preparao e a contratao
de atividades e produtos de fornecedores.
5.11.5. Controle de contrato: consiste em garantir que a performance dos

fornecedores condiz com os requisitos explicitados na contratao.
A norma contempla ainda um glossrio com os principais termos utilizados e uma relao
entre os processos aqui descritos com a srie ISO 9000. Para maiores informaes
recomenda-se [ISO97a].
4.2. PMBoK Guide
4.2.1. Apresentao
Segundo [PMIS96], Project Management Body of Knowledge (PMBoK) um termo que
descreve um conjunto de conhecimentos referentes atividade de gerenciamento de
projetos; assim como em outras profisses (medicina, por exemplo), este conjunto de
conhecimento gerado e atualizado pelos acadmicos e pelos profissionais, atravs de
prticas tradicionalmente utilizadas, estudos e pesquisas em desenvolvimento e outras
atividades.
O propsito original do documento escrito pelo Standards Committe do PMI, tendo como
seu diretor principal Willian R. Duncan, (e adotado pelo PMI como seu documento base)
o de identificar e descrever um subconjunto deste conjunto de conhecimentos referentes ao
gerenciamento de projetos que tenha uma aceitao global, ou seja, reunir um subconjunto
que seja aplicvel maioria dos projetos e que tenha seu valor reconhecidamente
comprovado e aceito pela comunidade. 29
A FIGURA 15 - Relacionamento do gerenciamento de projetos com outras disciplinas de
gerenciamento - ilustra o relacionamento e a interpolao dos conhecimentos entre as
diversas disciplinas de gerenciamento.
A rea de gerenciamento geral se refere ao conjunto dos conhecimentos que englobam
planejamento, organizao, execuo e controle das atividades das organizaes.
A rea de aplicaes especficas engloba os aspectos especficos de algumas reas de
atuao. Este trabalho aborda uma destas reas: a de desenvolvimento de sistemas de
informao.
29
Vale ressaltar que como a natureza de cada projeto distinta, este subconjunto no tem a inteno de ser aplicado
uniformemente a todos os projetos. Cada equipe dever fazer uma anlise preliminar e verificar quais os itens so
aplicveis ao projeto em questo.
56
Outro objetivo do PMBoK estabelecer um conjunto comum de termos sobre a disciplina

gerenciamento de projetos, que ainda recente e congrega profissionais de diversas
origens acadmicas. O processo de certificao de profissionais realizado pelo PMI se
baseia, entre outros, neste subconjunto.
Fonte: A Guide to the Project Management Body of Knowledge pg. 9
FIGURA 15 - Relacionamento do gerenciamento de projetos com outras disciplinas

de gerenciamento
4.2.2. Contexto do gerenciamento de projetos

Todo projeto est inserido em um ambiente com caractersticas peculiares. Conhecer estas
caractersticas responsabilidade do time que conduzir o projeto e uma necessidade
premente no sentido de garantir o sucesso desta empreita.
4.2.2.1. Ciclos de vida
Uma vez que todo projeto tem como caracterstica bsica ser nico, esto implcitas em sua
concepo e desenvolvimento algumas incertezas. Para diminuir estas incertezas,
usualmente um projeto dividido em fases, que auxiliam a determinar os objetivos e a
gerenciar adequadamente o andamento das atividades. Estas diversas fases so conhecidas
como "ciclo de vida do projeto", segundo [PMIS96].
A FIGURA 16 - Modelo espiral de ciclo de vida de desenvolvimento de sistemas de
informao - ilustra um exemplo de ciclo de vida para projetos de TI. Vale notar que este
ciclo equivalente ao apresentado no Captulo 3 - Desenvolvimento de software.
57
Para cada fase devem ser identificados quais so os deliverables 30 , ou seja, qual o trabalho
a ser executado na fase. Outro ponto importante a identificao de quem deve ser
envolvido em cada fase.
FIGURA 16 - Modelo espiral de ciclo de vida de desenvolvimento de sistemas de

informao
4.2.2.2. Estruturas organizacionais
A estrutura da organizao que executa o projeto regula a disponibilidade e grau de
envolvimento dos recursos humanos da organizao com o projeto. O [PMIS96] prope
um espectro contnuo de estruturas organizacionais que vai da estrutura puramente
funcional quela totalmente orientada para projetos.
30
Termo utilizado na sua grafia em ingls, que significa os produtos/servios a serem entregues/produzidos. Deve ser
tangvel e verificvel em termos de sua concluso. Como exemplos de deliverables tem-se a elaborao de um
documento (projeto conceitual), a concluso de um levantamento ou a construo de um prottipo.
58
Em estruturas puramente funcionais o escopo percebido do projeto, sua coordenao e

execuo esto limitados a uma diviso funcional da empresa, conforme ilustra a FIGURA
17 - Gerenciamento de projetos em uma organizao funcional. Vale notar que as clulas
pretas representam especialistas envolvidos nos projetos.
Coordenao dos
projetos.
Executivo-chefe
Gerente funcional
Gerente funcional
Gerente funcional
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
FIGURA 17 - Gerenciamento de projetos em uma organizao funcional

Na estrutura totalmente orientada para projetos a estrutura da organizao composta de
times de projeto na empresa, conforme ilustra a FIGURA 18 - Gerenciamento de projetos
em uma organizao orientada para projetos. Ao trmino do projeto, o mesmo time pode
ser alocado a um novo projeto ou os especialistas podem mudar de time, de acordo com a
necessidade dos projetos que se iniciam.
A mudana de time tambm pode ocorrer em mudanas de fase do projeto. Por exemplo,
na fase de planejamento pode haver uma maior necessidade de engenheiros enquanto que
na fase de execuo a necessidade de compradores pode ser maior; tambm pode ocorrer a
necessidade de novos profissionais com caractersticas diferentes dos atualmente alocados
ao time, quer seja por novas competncias tcnicas exigidas do projeto, quer seja por
aspectos polticos, ou por outros fatores que possam vir a afetar os projetos gerenciados
por uma dada organizao.
Coordenao dos
projetos.
Executivo-chefe
Gerente de projetos
Gerente de projetos
Gerente de projetos
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
FIGURA 18 - Gerenciamento de projetos em uma organizao orientada para

projetos
59
possvel combinar caractersticas da organizao funcional e da organizao orientada

para projetos atravs do uso de estruturas matriciais em que cada especialista se reporta a
um gerente de projetos e a um gerente funcional, conforme ilustra a FIGURA 19 Gerenciamento de projetos em organizao matricial. A forma matricial chamada de
"forte" (do ponto de vista de orientao para projetos) se os gerentes de projeto se
reportarem a uma hierarquia distinta da hierarquia funcional, "balanceada" se os gerentes
de projeto se reportarem a gerentes ou diretores funcionais e "fraca" se a coordenao do
projeto ficar a cargo de um especialista que no gerente de projetos em tempo integral
(segundo [PMIS96] e [DIAS99]).
Coordenao dos
projetos.
Gerente funcional
Executivo-chefe
Gerente funcional
Gerente funcional
Gerente de
gerentes de projeto
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Especialista
Gerente de projeto
FIGURA 19 - Gerenciamento de projetos em organizao matricial

Um resumo comparativo das caractersticas gerenciais nos diversos tipos de organizaes
descritos neste captulo pode ser visualizado na TABELA 8 - Estruturas com diferentes
nveis de orientao por projetos.
Matriz
Caracterstica
Funcional
Projetizada
Fraca
Balanceada
Forte
Autoridade do gerente
de projetos
Pequena ou
nenhuma
Limitada
Baixa a
moderada
Moderada a alta
Alta a quase total
% do pessoal alocado
totalmente a projetos
Praticamente 0 0 a 25%
15 a 60%
50 a 95%
85 a 100%
Em tempo
parcial
Em tempo
integral
Em tempo integral
Em tempo integral
Coordenador
ou Lder de
projetos
Gerente de
projetos
Gerente de projetos Gerente de projetos

ou de programas
ou de programas
Dedicao do gerente
Em tempo
de projetos a este papel
parcial
Ttulo normalmente
atribudo ao gerente de
projetos
Coordenador
ou Lder de
projetos
TABELA 8 - Estruturas com diferentes nveis de orientao por projetos

Nota-se que a organizao por projetos (ou projetizada) acentua a funo de gerente de
projetos, que tem alocao quase que exclusiva nesta funo; j na organizao funcional,
60
a influncia do gerente de projetos muito limitada (a autoridade predominante a do

gerente funcional) e sua alocao a projetos parcial ( compartilhada com outras
funes); com isso a organizao projetizada tem melhores condies de sucesso em seus
projetos.
4.2.3. Descrio do processo de gerenciamento de projetos

Pode-se definir um processo como sendo uma srie de aes conduzidas por pessoas
objetivando um resultado especfico. No sentido de facilitar a compreenso do processo de
gerenciamento de projetos, o PMI adota um agrupamento dos diversos processos em
alguns grupos, a saber:
Processos de iniciao: reconhecem que um dado projeto ou fase pode ser

iniciado e concludo;
Processos de planejamento: estabelecem e mantm um esquema de trabalho que

objetiva atingir s necessidades que o projeto visa atender;
Processos de execuo: coordenam pessoas e outros recursos no sentido de

realizar o planejamento estabelecido;
Processos de controle: asseguram que os objetivos do projeto esto sendo

atingidos atravs de monitoramento e medies de progresso, tomando as
medidas corretivas quando necessrio;
Processos de encerramento: garantem a aceitao formal do projeto ou fase,

finalizando-o.
Estes diversos grupos de processos esto ligados atravs dos produtos produzidos - o
produto produzido por um grupo de processos ser entrada para outro grupo. A FIGURA
20 - Relacionamentos entre os grupos de processos de gerenciamento de projetos - ilustra
estas relaes.
Processos de
incio
Processos de
planejamento
Processos de
controle
(As setas representam

fluxo de documentos ou
de itens
documentveis.)
Processos de
execuo
Processos de
encerramento
FIGURA 20 - Relacionamentos entre os grupos de processos de gerenciamento de

projetos
Ao longo do ciclo de vida do projeto a influncia de um determinado grupo de processos
de gerenciamento de projetos mais marcante, conforme ilustra a FIGURA 21 - Influncia
dos grupos de processos de gerenciamento de projetos ao longo do ciclo de vida do projeto.
61
FIGURA 21 - Influncia dos grupos de processos de gerenciamento de projetos ao

longo do ciclo de vida do projeto
Cada processo de gerenciamento de projetos descrito no PMBoK atravs de trs
componentes bsicos:
Entradas: Correspondem aos documentos ou itens documentveis que serviro

de base para a execuo do processo;
Tcnicas e ferramentas: Mecanismos que podem ser aplicados s entradas para

produzir os resultados;
Resultados e produtos: Correspondem aos documentos ou itens documentveis

gerados a partir da execuo do processo.
Estes trs componentes possibilitam definir as ligaes lgicas entre os processos (o

resultado de um dos processos corresponde entrada de outros processos) e os requisitos
de cada processo. Na seqncia so apresentados os processos atravs dos grupos.
4.2.3.1. Processos de Incio
Processos de Incio
5.1.
Iniciar
FIGURA 22 - Processos de Incio

A FIGURA 22 - Processos de Incio - ilustra os processos deste grupo.
Processos de
Planejamento
62
Os processos de incio (5.1. Iniciar31 ) tm por finalidade garantir que todos os envolvidos
no projeto (stakeholders) estejam cientes e comprometidos com o projeto a ser iniciado.
de vital importncia e deve ser considerado como pr-requisito para os demais processos.
4.2.3.2. Processos de Planejamento
A FIGURA 23 - Processos de Planejamento - ilustra os processos deste grupo.
Os processos de planejamento so aqueles que tem a maior importncia para o projeto, em
funo de envolverem aspectos e atividades que no podem ser desenvolvidos adiante.
Existe um forte relacionamento deste grupo com os demais: tem como ponto de partida os
resultados dos processos de incio, a base para os processos de execuo do projeto e tem
como retroalimentao os resultados dos processos de controle, onde pode haver a
necessidade de novos planejamentos (ou replanejamentos).
O PMI (em [PMIS96]) tambm atenta para o fato de "Planejamento no uma cincia
exata - diferentes times de projeto podem gerar diferentes planos de projeto para o mesmo
projeto". Com isso, aspectos tais como experincia anterior, treinamento, qualificao dos
participantes e outros podem influir sobre o bom - e o mau - planejamento inicial.
Os processos de planejamento so divididos em principais e acessrios. Os processos
principais de planejamento tem uma clara interdependncia que faz com que eles sejam
realizados essencialmente em uma mesma ordem na maioria dos projetos, podendo serem
repetidos vrias vezes durante este projeto; conforme FIGURA 23 - Processos de
Planejamento, os principais processos de planejamento so:
5.2. Planejar Escopo: Corresponde ao desenvolvimento de um conjunto de

regras de escopo do projeto que sero base para futuras decises de projeto;
5.3. Definir Escopo: Diviso do produto principal do projeto em subprodutos

que sejam facilmente gerenciveis;
6.1. Definir Atividades: Identificao das atividades especficas que devem ser
realizadas para produzir os vrios subprodutos do projeto;
6.2. Seqenciar Atividades: Identificar e documentar as dependncias 32 entre as

atividades;
6.3. Estimar Durao das Atividades: Consiste em estimar o nmero de

perodos de tempo que ser necessrio para a concluso de cada atividade em
particular;
31
Vale notar que a numerao adotada para cada processo corresponde numerao adotada por [PMIS96]. Isto foi feito
uma vez que adotado desta forma pela comunidade de planejamento e facilita a correlao com o PMBoK. Esta
mesma notao utilizada ao longo de toda dissertao.
32
Dependncias entre atividades, tambm conhecidas como interdependncia, correspondem s ligaes de precedncia
entre as atividades, de forma a garantir um perfeito planejamento e controle de projetos. Tem origem na teoria CPM
(Critical Path Method) - Mtodo do Caminho Crtico - e adotada pelos profissionais de planejamento como base para
o controle de atividades. Maiores informaes podem ser obtidas em [PAGE90], [OCON94] e [BROO95].
63
Processos de Planejamento
Processos Principais
5.2.
Planejar
Escopo
Processos de
Incio
5.3.
Definir
Escopo
6.1.
Definir
Atividades
7.1.
Planejar
Recursos
6.2.
Seqenciar
Atividades
6.4.
Desenvolver
Acompanhamento
6.3.
Estimativar
Durao das
Atividades
7.3.
Orar
Custos
7.2.
Estimar
Custos
4.1.
Desenvolver
Plano do
Projeto
Processos de
Execuo
Processos Acessrios
Processos de
Controle
8.1.
Planejar
Qualidade
10.1.
Planejar
Comunicao
9.1.
Planejar
Organizao
9.2.
Aquisio de
Pessoal
12.1.
Planejar
Suprimentos
11.1.
Identificar
Riscos
12.2.
Planejar
Cotaes
11.2.
Quantificar
Riscos
11.3.
Desenvolver
Resposta aos
Riscos
FIGURA 23 - Processos de Planejamento
7.2. Estimar Custos: Desenvolver de forma aproximada/estimada a previso de

custos advindos dos recursos planejados no processo 7.1. (Planejar Recursos);
7.3. Orar Custos: Alocar os custos estimados a cada item de trabalho;
4.1. Desenvolver Plano do Projeto: Consiste em agrupar todos os resultados dos

processos anteriores de planejamento, organiz-los e armazen-los em um
documento de forma coerente.
64
Os processos acessrios de planejamento so mais dependentes da natureza de cada

projeto; alguns podem ter maior importncia que outros em funo das necessidades do
projeto. importante ressaltar que eles continuam sendo obrigatrios no sentido de
garantir o perfeito planejamento do projeto. A FIGURA 23 - Processos de Planejamento apresenta os seguintes processos acessrios:
8.1. Planejar Qualidade: Identificar quais so os padres de qualidade relevantes

para o projeto e determinar como satisfaz-los;
9.1. Planejar Organizao: Identificar, documentar e determinar regras de

projeto, responsabilidades e relacionamento entre os participantes
9.2. Aquisio de Pessoal: Obter os recursos humanos necessrios para

trabalhar no projeto;
10.1. Planejar Comunicao: Determinar que informaes e que necessidades

de comunicaes so necessrias aos stakeholders: quem necessita de qual
informao, quando estas sero necessrias e como elas sero enviadas para eles
(meio fsico);
11.1. Identificar Riscos: Determinar quais so os riscos que podem vir a afetar o
projeto e documentar as caractersticas de cada um;
11.2. Quantificar Riscos: Avaliar os riscos a fim de determinar sua

probabilidade de ocorrer e quanto ele pode vir a interferir no projeto; avaliar
quais so os riscos e quais podem vir a representar oportunidades;
11.3. Desenvolver Resposta aos Riscos: Definir um conjunto de passos para os

riscos que foram transformados em oportunidades e um plano de ao para os
demais (que continuaram como riscos);
12.1. Planejar Suprimentos: Determinar o que e quando ser contratado;
12.2. Planejar Cotaes: Documentar os requisitos dos produtos e identificar

potenciais fornecedores.
4.2.3.3. Processos de Execuo

Os processos de execuo so caracterizados pelo desenvolvimento do projeto. A FIGURA
24 - Processos de Execuo - apresenta os seguintes processos:
4.2. Executar Plano de Projeto: Processo principal que corresponde execuo

do plano de projeto atravs da realizao das atividades nele contidas;
5.4. Verificar Escopo: Processo acessrio que consiste em aceitar formalmente

os itens envolvidos com a questo escopo;
8.2. Garantir Qualidade: Processo acessrio que consiste em analisar o

desempenho do desenvolvimento do projeto em perodos regulares de tempo e
em atividades anteriormente planejadas de forma a garantir que o projeto est
satisfazendo aos requisitos (padres) de qualidade anteriormente estabelecidos;
9.3. Desenvolver Time do Projeto: Processo acessrio que consiste em

desenvolver (capacitar, estimular) as capacidades dos componentes do time de
projeto (individuais e coletivas) de forma a alcanar resultados de alto
desempenho no projeto;
65
Processos de Execuo
4.2.
Executar
Plano do
Projeto
Processos de
Planejamento
Processos Acessrios
Processos de
Controle
10.2.
Distribuir
Informaes
9.3.
Desenvolver
Time
12.3.
Solicitaes
Processos de
Controle
8.2.
Garantir
Qualidade
5.4.
Verificar
Escopo
12.4.
Selecionar
Fornecedores
12.5.
Administrar
Contratos
FIGURA 24 - Processos de Execuo
10.2. Distribuir Informaes: Processo acessrio que consiste em tornar

disponveis, em tempo hbil e com qualidade, as informaes na forma com que
cada stakeholder anteriormente estipulou;
12.3. Solicitaes: Processo acessrio que consiste em obter, junto aos

fornecedores, as cotaes, as propostas, as ofertas e as requisies baseadas nos
itens anteriormente planejados;
12.4. Selecionar Fornecedores: Processo acessrio que consiste em escolher

uma proposta dentre as diversas apresentadas;
12.5. Administrar Contratos: Processo acessrio que toma como base a proposta
selecionada, gera e administra o contrato com os fornecedores.
66
4.2.3.4. Processos de Controle

Os processos de controle estabelecem os procedimentos de controle necessrios ao bom
andamento do projeto; para tanto existe a necessidade de se verificar periodicamente o
desempenho do projeto de forma a identificar possveis variaes nas diversas reas
(escopo, tempo, custo, qualidade etc.) e tomar as medidas cabveis de forma a manter o
bom andamento do projeto. Vale ressaltar que as medidas preventivas, identificadas antes
mesmo de um desvio ocorrer, tambm so objeto deste grupo de processos. A FIGURA 25
- Processos de Controle - ilustra os processos deste grupo, a saber:
Processos de Controle
10.3.
Reportar
Desempenho
Processos de
Execuo
4.3.
Controlar
Mudanas
Processos de
Planejamento
Processos Acessrios
5.5.
Controlar
Mudanas de
Escopo
6.5.
Controlar
Acompanhamento
8.3.
Controlar
Qualidade
11.4.
Controlar
Resposta
aos Riscos
7.4.
Controlar
Custos
Processos de
Encerramento
FIGURA 25 - Processos de Controle
4.3. Controlar Mudanas: Processo principal que corresponde coordenao do

tratamento das mudanas e modificaes que porventura venham a ocorrer ao
longo do projeto;
5.5. Controlar Mudanas de Escopo: Processo acessrio que corresponde ao

controle das modificaes de escopo;
6.5. Controlar Acompanhamento: Processo acessrio que consiste em controlar

as ocorrncias que diferente do acompanhamento planejado;
67
7.4. Controlar Custos: Processo acessrio que consiste em controlar

modificaes no oramento de custos do projeto;
8.3. Controlar Qualidade: Processo acessrio que consiste em monitorar

resultados especficos do projeto a fim de determinar se esto de acordo com os
padres de qualidade estabelecidos e identificar caminhos para eliminar
possveis problemas de desempenho;
10.3. Reportar Desempenho: Processo principal que consiste em coletar e

disseminar informaes de desempenho; inclui relatrios de progresso, medidas
de desempenho e simulaes/projees;
11.4. Controlar Resposta aos Riscos: Processo acessrio que consiste em

responder s modificaes nos riscos ao longo do projeto.
4.2.3.5. Processos de Encerramento

Os processos de encerramento tm por finalidade estabelecer um fim formal ao projeto
desenvolvido. A FIGURA 26 - Processos de Encerramento - apresenta os seguintes
processos:
Processos de Encerramento
Processos de
Controle
12.6.
Encerrar
Contratos
10.4.
Encerrar
Projeto
FIGURA 26 - Processos de Encerramento
10.4. Encerrar Projeto: Processo que corresponde gerao, coleta e

disseminao das informaes de forma a formalizar o encerramento de uma
fase ou do projeto;
12.6. Encerrar Contratos: Processo que consiste em completar e encerrar os

contratos com fornecedores, incluindo a soluo de todas as pendncias que
porventura ainda possam existir.
4.2.4. reas do gerenciamento de projetos
68
reas de
conhecimento
4. Gerenciamento da
integrao
5. Gerenciamento de
escopo
6. Gerenciamento do
tempo
4.1.
Desenvolver plano do
projeto
4.2.
Executar plano de
projeto
4.3.
Controlar mudanas
5.1.
Iniciar
5.2.
Planejar escopo
5.3.
Definir escopo
5.4.
Verificar escopo
5.5.
Controlar mudanas de
escopo
6.1.
Definir atividades
6.2.
Seqenciar atividades
6.3.
Estimar durao das
atividades
6.4.
Desenvolver
acompanhamento
6.5.
Controlar
acompanhamento
7. Gerenciamento da
custos
8. Gerenciamento da
qualidade
9. Gerenciamento dos
recursos humanos
7.1.
Planejar recursos
7.2.
Estimar custos
7.3.
Orar custos
7.4.
Controlar custos
8.1.
Planejar qualidade
8.2.
Garantir qualidade
8.3.
Controlar qualidade
9.1.
Planejar organizao
9.2.
Aquisio de pessoal
9.3.
Desenvolver time do
projeto
10. Gerenciamento da
comunicao
11. Gerenciamento
do risco
12. Gerenciamento de
suprimentos
10.1.
Planejar comunicao
10.2.
Distribuir informaes
10.3.
Reportar desempenho
10.4.
Encerrar projeto
11.1.
Identificar riscos
11.2.
Quantificar riscos
11.3.
Desenvolver resposta
aos riscos
11.4.
Controlar resposta aos
riscos
12.1.
Planejar suprimentos
12.2.
Planejar cotaes
12.3.
Solicitaes
12.4.
Selecionar
fornecedores
12.5.
Administrar contratos
12.6.
Encerrar contratos
FIGURA 27 - Viso geral dos processos de gerenciamento de projetos por rea de

conhecimento
A FIGURA 27 - Viso geral dos processos de gerenciamento de projetos por rea de
conhecimento - ilustra os processos de gerenciamento de projeto nas diversas reas de
69
conhecimento. Vale notar que estes processos so os mesmos apresentados no tpico 4.3.
(Descrio do processo de gerenciamento de projetos), agora agrupados por rea de
conhecimento.
Os objetivos de cada rea de conhecimento so detalhados a seguir. Para um
aprofundamento recomenda-se o ANEXO A - reas de conhecimento do gerenciamento
de projeto - onde so apresentas as entradas, processamentos e produtos de cada rea.
4.2.4.1. Gerenciamento de integrao
Inclui os processos necessrios a fim de garantir que os vrios elementos componentes do
projeto esto sendo adequadamente coordenados. Pode-se dizer que correspondem a
processos que correm paralelamente aos demais grupos de processos e visam garantir o
correto funcionamento dos demais, a sincronizao dos mesmos, a interface adequada, a
atualizao em tempo e o atendimento s necessidades dos diversos stakeholders.
4.2.4.2. Gerenciamento de escopo
Inclui os processos necessrios a fim de garantir que o projeto inclua toda o trabalho
necessrio - e apenas o trabalho realmente necessrio - para atender aos requisitos. Em
uma primeira anlise, consiste em definir e controlar tudo aquilo que deve ou no deve ser
includo no projeto.
4.2.4.3. Gerenciamento de tempo
Inclui os processos necessrios a fim de garantir que o projeto em questo seja concludo
dentro do tempo planejado. Consiste em uma srie de processos necessrios para detalhar
as atividades e tarefas de forma a possibilitar controle sobre o projeto.
4.2.4.4. Gerenciamento de custo
Inclui os processos necessrios a fim de garantir que o projeto em questo seja concludo
dentro dos padres de custo (budget) aprovado. Primariamente so definidos tomando por
base o custo dos recursos necessrios para a concluso das atividades do projeto.
4.2.4.5. Gerenciamento da qualidade do processo
Inclui os processos necessrios a fim de garantir que o projeto em questo satisfaa a todas
as necessidades para as quais foi concebido. Segundo [PMIS96], esta rea de
conhecimento mantm forte correlao com os preceitos da ISO 9000 e ISO 10000,
devendo ter preocupaes tanto com a qualidade do projeto quanto com a qualidade do
produto resultando do projeto.
70
Devem estar sempre presentes as preocupaes com a satisfao do cliente/usurio, atravs

do entendimento, gerenciamento e garantia de que as necessidades e expectativas dos
clientes sejam atendidas ou suplantadas (que requer que o projeto atenda s especificaes
- garantia de que o produto gerado pelo projeto realmente realize aquilo para que fora
especificado - e que seja adequado ao uso - garantia de que o produto gerado pelo projeto
satisfaa s necessidades reais dos clientes). Recomenda-se para aprofundamento
[IREL91].
4.2.4.6. Gerenciamento dos recursos humanos
Inclui os processos necessrios a fim de garantir que o projeto faa uso da forma mais
efetiva possvel dos recursos humanos envolvidos com este projeto, incluindo todos os
stakeholders (responsveis, clientes, participante e demais envolvidos). Dentre os
principais aspectos a serem abordados quando o tema lidar com pessoas/indivduos temse negociao, comunicao, delegao, motivao, capacitao, mentorao, construo
do time de trabalho (relacionamento), lidar com conflitos, recrutamento, reteno de bons
profissionais, relaes de trabalho, motivao, sade, segurana, entre outros 33 .
A natureza temporria do projeto faz com que o time do projeto tenha que definir quais so
os temas aplicveis e em que grau, diferentemente de uma empresa onde a tendncia
natural de uma relao mais duradoura; assim, temas como capacitao e resoluo de
conflitos devem ser resolvidos de maneira gil, uma vez que afetam diretamente o projeto
em questo.
4.2.4.7. Gerenciamento das comunicaes
Inclui os processos necessrios a fim de garantir que as informaes acerca do projeto
sejam geradas, coletadas, disseminadas, armazenadas e disponibilizadas no tempo
adequado a todos os stakeholders do projeto, alm de garantir que a informao seja
entendida por todos que dela faam uso; envolve estudos sobre as melhores formas de
divulgao (mdia), estilo da escrita, tcnicas de apresentao e de reunio.
4.2.4.8. Gerenciamento do risco
Inclui os processos necessrios a fim de identificar, analisar e responder aos riscos do
projeto, incluindo maximizar os resultados de eventos positivos e minimizar as
conseqncias de eventos adversos.
4.2.4.9. Gerenciamento de suprimentos
33
Recomenda-se, para aprofundamento, leitura de [HALL97].
71
Inclui os processos necessrios a fim de adquirir bens e servios (chamados genericamente

de produtos) a partir de empresas externas organizao que executa o projeto. O foco a
ser dado nestes processos sempre o da perspectiva do comprador em uma relao
comprador-vendedor, incluindo a aspectos contratuais, aceitao dos produtos e demais
itens relacionados a estas operaes.
72
Cap. 5 Anlise Comparativa
5. ANLISE COMPARATIVA
Grande parte da anlise comparativa j foi realizada ao longo da descrio de cada modelo
(qualidade genrico, especfico para software ou de gerenciamento de projetos), com os
pontos positivos e negativos sendo enfocados. Este captulo procura sumarizar as
constataes efetuadas, ressaltando os principais aspectos envolvidos.
Modelos de gerenciamento de projetos
Conforme apresentado nos captulos anteriores, existem vrias metodologias 34 e
frameworks relativos aos processos de gerenciamento de projetos; apesar de tratarem do
mesmo tema, um amplo consenso ainda uma meta distante. Para ilustrar isto, a norma
ISO 10006 [ISO97a] bastante criticada por Duncan, um dos mais atuante membro ligado
ao PMI; em seu artigo [DUNC99], critica as empresas que pretendem adotar a ISO 10006
como seu padro de gerenciamento de projetos por entender que esta norma omite diversos
aspectos relevantes j abordados pelo PMBoK [PMIS96].
Uma referncia interessante sobre o papel do gerenciamento de projetos pode ser obtida
em [DINS98], onde o foco demonstrar que o gerenciamento de projetos pode ser
aplicado a todas as reas de negcio, inclusive no maior projeto de cada indivduo: sua
prpria existncia; Dinsmore sugere que as prticas de gerenciamento de projeto podem (e
devem) ser aplicadas vida das pessoas, a fim de que as metas pessoais possam vir a ser
atingidas 35 . Seu discurso baseado no PMBoK.
Padres de qualidade
No mbito dos modelos de qualidade, tem-se que diversos autores procuraram relacionar o
CMM e a ISO 9000, considerando que a ISO 9000 pode corresponder a uma qualificao
de CMM nvel 3 [PAUL94], podendo existir inclusive casos de empresas que ainda estejam
no nvel 1 do CMM [PESS97]; em outras palavras, estes autores consideram que o nvel de
exigncia do CMM bem mais elevado que os preceitos da ISO 9000.
Para [PESS97], a ISO 9000 foca o sistema da qualidade de uma empresa na relao cliente
/ fornecedor enquanto que o modelo CMM foca um sistema da qualidade para o
desenvolvimento de software; a ISO 9000 tem um sistema de certificao de terceira parte,
ou seja, rgos credenciados que realizam auditorias em intervalos regulares de tempo para
examinar o sistema da qualidade e garantir que o mesmo est funcionando adequadamente
enquanto que o CMM avaliado por auditores credenciados pelo SEI, rgo privado que
administra o modelo; o grau de abstrao do modelo ISO mais alto que o CMM e se
aplica a qualquer tipo de empresa enquanto que o modelo CMM muito mais profundo no
34
Alm das metodologias estudadas existem diversos livros e referencias sobre os processos de gerenciamento de
projetos em sistemas de informao, como por exemplo [DEMA89], [KUGL90] e mais recentemente [CASA99].
35
Este artigo complementa [DINS92], que tambm enfoca o gerenciamento de projetos, porm sobre o prisma de
executivos e empresrios.
73
tocante aos quesitos de desenvolvimento de software e, portanto, mais exigente.

Complementa tambm que "os modelos ISO e CMM so compatveis, sendo perfeitamente
vivel uma empresa que possui ISO 9000, implantar o modelo CMM, assim como tambm
perfeitamente possvel uma empresa com ISO 9000 estar ainda no nvel 1 do CMM pois
so modelos com diferentes requisitos"36 .
A rea de gerenciamento da qualidade descrita pelo PMBoK faz referncia ao preceitos de
qualidade previstos pelas sries ISO 9000 e ISO 10000, estudadas em captulos anteriores.
Uma distino se faz necessria no tocante qualidade: ela diferente de graduao, que
pode ser entendida "por uma categorizao ou classificao para entidades que tenham a
mesma funcionalidade mas diferentes requisitos de qualidade" [PMIS96]. Esta distino
importante uma vez que um projeto com baixa qualidade sempre um problema, enquanto
que um projeto com baixa graduao nem sempre o - por exemplo, um software com
pequeno nmero de funcionalidade pode ser considerado de baixa graduao e isto no
significa necessariamente um problema (pelo contrrio, pode ter sido um requisito),
enquanto que um software com baixa qualidade (quer seja por problemas de performance,
erros, comprometimento quanto sua entrega) certamente indica problemas. Vale ressaltar
que o nvel de graduao do software dever ser determinado em conjunto, envolvendo
todos os stakeholders (equipe do projeto, clientes, fornecedores e outros).
Outro aspecto fundamental levantado por [PMIS96] em relao ao gerenciamento da
qualidade, que totalmente aplicvel ao software, a diferenciao de preveno e
inspeo, que aparentemente so semelhantes (no deixar passar erros), porm diferem
drasticamente em suas formas: enquanto a preveno consiste em um processo contnuo de
melhoria (atualmente muito difundido pelos rgos de qualidade) cujo foco no
ocorrerem erros, a inspeo muito mais branda e consiste nos famosos testes apenas ao
final do desenvolvimento a fim de evitar que o usurio final detecte o erro antes dos
profissionais de informtica - em outras palavras, perpetuando o erro. A busca constante no
caso de software deve ser produzir software com qualidade, sem erros e correto da
primeira vez.
Escopo
A rea de escopo do projeto de desenvolvimento de sistemas de informao normalmente
negligenciada no tocante ao seu gerenciamento e controle. O levantamento e a definio do
escopo normalmente so feitos utilizando tcnicas de levantamento de dados junto aos
usurios e, aps isto, utilizando modelos estruturados 37 (DFD), orientados a objeto (use
case), texto em linguagem natural (por exemplo "portugus estruturado") ou outra forma
de documentao, porm nem sempre so feitas as validaes junto aos usurios e
normalmente no existe um processo formal de atualizao, autorizaes de mudanas e
controle deste escopo. As disciplinas de gerenciamento tm a contribuir com a
formalizao destes processos de controle e atualizao, instituindo procedimentos e
responsabilidades pelas ocorrncias.
36
Ainda com relao ao tema qualidade em projetos de sistemas de informao uma referncia interessante [XAVI95],
que utiliza uma abordagem com foco no cliente (e no no fornecedor do software).
37
Uma referncia muito utilizada para descrever as tcnicas estruturadas pode ser obtida em [MART91].
74
Diversos autores incluem estes processos como sendo dos mais relevantes para o sucesso
do desenvolvimento de sistemas. Para citar alguns, tem-se [CONN99], que procura se
concentrar nos aspectos envolvidos com a habilidade de se dividir os ciclos de
desenvolvimento de acordo com o escopo do projeto, entre outros fatores, utilizando uma
abordagem evolutiva no desenvolvimento; [COST99] tambm propem que processos de
controle de escopo sejam utilizados a fim de garantir coeso e profissionalismo na rea de
informtica.
Prazos
Tradicionalmente quando o termo gerenciamento utilizado a dimenso prazo
normalmente associada. Todas as abordagens metodolgicas apresentadas so unnimes
em atrelar o estabelecimento dos prazos a um efetivo entendimento do escopo, seu
respectivo detalhamento (utilizando tcnicas de decomposio e WBS), identificao dos
produtos a serem gerados pelo projeto (deliverables) para ento se chegar a identificao
das atividades, as estimativas de prazos e a lgica entre estas atividades, sendo ento
gerado o cronograma do projeto.
To importante quanto a elaborao de um plano de projeto (cronograma) o
acompanhamento de sua execuo a fim de detectar (e evitar) desvios e, caso no seja
possvel, ativar aes corretivas para que o projeto volte ao cronograma planejado.
Replanejamento tambm deve ser uma preocupao constante, uma vez que o projeto pode
sofrer modificaes em funo de um maior detalhamento dos aspectos envolvidos (em
especial escopo); este replanejamento deve ser devidamente gerenciado e seu impacto, nas
diversas reas de gerenciamento de projeto, deve ser analisado e implementado.
Como referncias para aprofundamento no tema de gerenciamento de prazos e seu impacto
nas demais reas de gerenciamento recomenda-se [LAUN99], que se dedica s
preocupaes para a criao de um planejamento de prazos (cronograma) efetivo;
[MART98] e [MART99], que abordam a criao de cronogramas efetivos e na medida
certa, discutindo aspectos como excesso de controle x escopo do trabalho a ser executado;
[MELL99b], que aborda o processo de elaborao de cronogramas utilizando a abordagem
evolutiva/incremental e [FABI99], que enfoca o gerenciamento de prazos e seu impacto
dentro do projeto.
Custos
Um dos aspectos mais importantes na hora da contratao de um desenvolvimento de
software o aspecto financeiro: quanto ir custar realmente o trabalho e qual o retorno
(financeiro) oriundo da implantao do software. Ainda que todos os cuidados referentes a
uma boa oramentao inicial38 , baseada nos requisitos do sistema (escopo), recursos
necessrios (tanto humanos quanto materiais), o risco de desvios de custo grande,
fazendo com que um processo de monitorao contnuo seja necessrio.
As tcnicas de acompanhamento de custos, baseadas em indicadores de desempenho
atrelados ao trabalho produzido comparados com o custo esperado (o chamado earned
38
Uma referncia bastante interessante sobre os aspectos de estimativa de custo pode ser obtida em [PILL97].
75
value), introduzem ferramentas poderosas de deteco de desvios de custos, antecipando

problemas. Para exemplificar, se o custo real em uma dada data est menor que o previsto,
no necessariamente significa que algo bom (economia) est ocorrendo - pelo contrrio,
pode ser que o custo menor que o previsto indique que os esforos necessrios no esto
sendo feitos adequadamente e que um atraso nos prazos no projeto possa estar sendo
vislumbrado. Com o uso das tcnicas mencionadas estas e outras concluses podem ser
tiradas e medidas preventivas/corretivas podem ser tomadas.
Riscos
O reconhecimento da necessidade de abordagem aos riscos presentes na maior parte dos
modelos de extrema importncia. Um processo formal para identificao, quantificao,
acompanhamento e controle destes riscos vital para que o projeto tenha sucesso. Alguns
autores argumentam que tcnicas de orientao a objetos aplicadas ao desenvolvimento de
software podem fazer com que alguns riscos de origem tcnica, de qualidade e de prazos
sejam eliminados ([AMBL98]), atravs da construo e reutilizao de componentes de
software.
Os projetos de desenvolvimento de sistemas de informao esto intimamente ligados a
riscos, motivado sobretudo pela natureza do software, a dificuldade em encar-lo como
produto, a presso normalmente feita aos desenvolvedores de software, o falta de foco nos
aspectos gerenciais e outros fatores. Este conjunto de fatores faz com que o
desenvolvimento de um software seja, por si s, um fator de risco a ser considerado.
Somente com o estabelecimento do processo formal de gerenciamento de riscos estes
problemas podem ser solucionados. Antes de mais nada preciso conscientizar sobre a
necessidade de se identificar os riscos antes do projeto ser efetivamente iniciado, definir a
melhor estratgia - muitas vezes o risco pode ser compartilhado com os clientes, trazendo
benefcios a todos os envolvidos com o projeto - para abord-lo. Vale notar tambm que os
riscos podem surgir (e desaparecer) ao longo do projeto, sendo necessrio um
acompanhamento constante e atualizao daqueles riscos anteriormente identificados.
Outro fator decorrente da anlise de riscos consiste em detectar oportunidades. Por vezes,
ao iniciar o desenvolvimento de um software o time do projeto percebe uma oportunidade,
quer seja de novos negcios com o cliente em questo, quer seja de ampliao do escopo
deste projeto, quer seja de expanso dos clientes atendidos pelo software a ser
desenvolvido. importante a institucionalizao de processo formal para tratar destas
oportunidades identificas, ainda que a deciso seja por no perseguir esta oportunidade.
Vrias empresas tiveram sucesso a partir desta abordagem, assim como outras no
conseguiram se manter em funo de no terem feito esta anlise (ou identificao) de
forma adequada.
Aspectos humanos
Outra contribuio dos modelos estudados se refere ao relacionamento dos projetos com
aspectos humanos, em especial algumas necessidades existentes como a capacitao dos
76
profissionais em disciplinas de gerenciamento de projetos 39 (alm das disciplinas tcnicas

relativas a software), a necessidade do ser humano em ser mantido informado da real
situao de um projeto (tratado no tpico gerenciamento de comunicaes do PMBoK,
com procedimentos formais para garantir que as comunicaes sejam completas, efetivas e
claras, tanto dos pontos positivos quanto dos problemas relativos ao projeto), a habilidade
de se trabalhar em times, a habilidade de resoluo de conflitos, inevitvel em projetos de
sistemas de informao onde algumas necessidades e solues para problemas so
antagnicas.
Outro aspecto importante na rea de desenvolvimento de software est relacionada ao
perfil dos profissionais. A grande maioria tem vocao tcnica, se preocupando apenas
com aspectos envolvidos com a construo tcnica do produto, no reservando tempo para
as atividades gerenciais envolvidas neste processo. A recomendao de vrios autores para
a conscientizao dos profissionais de que estes fatores so de vital importncia para o
sucesso dos desenvolvimentos 40 , porm a implantao destas recomendaes algo que
caminha vagarosamente, uma vez que aspectos culturais esto amplamente disseminados 41 .
Suprimentos
Outro aspecto considerado pelos modelos apresentados neste trabalho a possibilidade de
contratao de servios e produtos a partir de fornecedores externos organizao, prtica
cada vez mais comum no desenvolvimento de software. importante ressaltar as
preocupaes advindas desta escolha, desde os aspectos de seleo de fornecedores,
confiabilidade do fornecedor escolhido, regime de contratao deste fornecedor, clusulas
contratuais (jurdicas e tcnicas), administrao do contrato com este fornecedor, critrios
de inspeo dos produtos desta contratao, relacionamento entre o fornecedor e o time de
projeto; com isso, a habilidade de negociao e trabalho em times deve ser fortalecida e as
preocupaes gerenciais redobradas em funo deste novo panorama.
O porte atual dos projetos de desenvolvimento de sistemas de informao, associado s
especialidades e especificidades existentes, faz com que dificilmente uma organizao
possua (e que estejam disponveis) todos os recursos necessrios; sendo o processo de
contratao de pessoal especializado normalmente demorado, via de regra no atende s
necessidades do projeto, agravado pelo custo elevado (uma vez que envolve pessoal
especializado possivelmente valorizado pelo mercado) e pelo fato do projeto ter uma
durao finita, findo o qual cessa a necessidade do recurso e passa a no ser interessante
para a empresa a manuteno do mesmo - nestes casos indicada a contratao de servios
junto a fornecedores. A relao pode ser do tipo parceria, que estabelece uma relao de
39
Um excelente material pode ser obtido em [ESI97], que relaciona os aspectos humanos no desenvolvimento de
sistemas de informao. Vale comentar que a universidade George Washington referncia mundial quando o tema
gerenciamento de projetos, em especial quando envolve a capacitao de pessoas.
40
Recomenda-se os artigo [HAYE99], que fala em quebra de paradigmas para melhoria do processo de desenvolvimento,
e [JAME97], que explora as razes comuns para fracasso dos projetos de desenvolvimento de sistemas de informao.
41
Nos cursos de formao de analistas de sistemas nota-se que a grande maioria dos alunos (quer seja aqueles advindos
de escolas tcnicas em processamento de dados, quer seja aqueles que j atuam na rea de informtica, quer seja
aquelas que esto iniciando na informtica) tem necessidade e interesse especial pelos aspectos tcnicos envolvidos,
pelas linguagens de programao e ferramentas de desenvolvimento, porm quando o assunto ligado aos aspectos
gerenciais envolvidos com o projeto existe grande dificuldade. A cultura do "por a mo na massa" e "ligar o micro e
comear a desenvolver o sistema" muito forte, consistindo em uma barreira importante a ser ultrapassada.
77
cooperao mtua entre os envolvidos, pode ser especfica para um trabalho, pode ser
alocao de mo de obra especializada para exercer alguma atividade ou ainda pode ser
algo do estilo projeto global (chamado de "turn key"), onde um dado fornecedor se
responsabiliza por toda a obra/desenvolvimento, subcontratando outros fornecedores caso
necessrio.
Com a contratao de servios algumas preocupaes adicionais devem ser levadas em
considerao, como por exemplo porte do fornecedor, regime de contratao dos recursos
por parte do fornecedor (isto tem grande impacto na legislao trabalhista brasileira, uma
vez que pequenas empresas via de regra no contratam como empregados seus
funcionrios, contratando via empresa individual - a chamada "quarteirizao" - com riscos
trabalhistas tanto para a empresa que esta contratando estes indivduos quanto para a
empresa que originalmente contratou o servio). Clusulas contratuais adequadamente
revisadas nos seus aspectos jurdicos, bem como a exigncia das documentaes referentes
ao fornecedor contratado, so de vital importncia para a contratao de servios
terceirizados; no raro ocorrerem problemas trabalhistas em funo de um dado projeto
quando este projeto j se encerrou, gerando nus para os envolvidos.
Comunicaes
Aspecto vital de todo projeto, infelizmente nem sempre feito de forma satisfatria. Manter
todos os stakeholders de um projeto com informaes suficientes a respeito do andamento,
com freqncia adequada e de forma atualizada um desafio constante presente nos
desenvolvimentos, desafio este agravado nas etapas mais tcnicas do processo (por
exemplo, na durante a programao) onde existem problemas de se medir efetivamente a
situao do projeto.
Outro ponto importante atentar para o fato de que as necessidades de informaes so
diferentes entre os stakeholders: enquanto que o time do projeto provavelmente necessitar
de informaes detalhadas sobre o projeto, o gerente do projeto provavelmente necessitar
de outro tipo de informao (normalmente tudo aquilo que est diferente do planejado, a
fim de ser colocado em prtica o gerenciamento por exceo, ou seja, se concentrar nos
pontos onde pode ou iro acontecer os problemas), o cliente necessitar de outro nvel de
detalhe (mais voltada ao andamento do projeto). No incio do desenvolvimento deve ser
feita esta distino e mecanismos para a gerao destes dados devem ser providos e
considerados como parte integrante do prprio desenvolvimento.
Integrao das vrias reas
Aps a anlise individual das reas de gerenciamento, com seus impactos pormenorizados,
cabe ao projeto uma avaliao conjunta de todas estas reas; isto se aplica desde um
planejamento do projeto integrado, tomando por base os requisitos individuais de cada
rea, at o procedimento global de controle de modificaes, quer seja de escopo, prazo,
custo, e seu impacto por todo o projeto.
78
Deve ser constantemente revisada a fim de garantir um efetivo acompanhamento do

projeto, sendo que seu uso e implantao so facilitados com a adoo de metodologias por
parte da empresa responsvel pelo projeto 42 .
O grande enfoque deste grupo de atividades, que correspondem a atividades ao longo de
todo o projeto, padronizar os mecanismos a serem utilizados visando garantir o bom
andamento do projeto. Aspectos como plano do projeto integrado e controle de
modificaes nificado so relevantes e primordiais para a efetiva concluso do projeto
com sucesso.
42
Algumas referencias sobre o uso de metodologias em sistemas de informao podem ser obtidas em [ROBE98] e
[WHIT95].
Cap. 6 Concluso
79
6. CONCLUSO
Pode-se concluir, pelo estudo dos modelos de qualidade e de gerenciamento de projetos e
posterior anlise comparativa, que diversos aspectos podem ser introduzidos s prticas de
gerenciamento de processos de desenvolvimento de sistemas de informao. Partindo do
PMBoK Guide e complementando com caractersticas importantes dos demais modelos
estudados, foi gerada a TABELA 9 - Processos de gerenciamento de projetos agrupados
em reas e grupos - que apresenta um mapa com os principais processos de gerenciamento
de projetos e seus produtos; com isso, o gerenciamento de projetos claramente definido e
documentado, propiciando uma avaliao precisa dos impactos em todas as reas e etapas
do projeto, maximizando a possibilidade de sucesso deste projeto.
reas / Grupos Incio
Planejamento
Execuo
Controle
Integrao
Definio do plano de
projeto
Execuo do plano de
projeto
Controle geral de
mudanas
Escopo
Incio
Planejamento do escopo Verificao do escopo

Definio do escopo
Tempo
Definio de atividades
Fechamento
Controle de
mudanas de
escopo
Controle de
cronograma
Seqenciamento de
atividades
Estimativa de durao
de atividades
Definio do
acompanhamento
Custo
Planejamento de
recursos
Controle de custos
Estimativa de custos
Oramento de custos
Qualidade
Planejamento da
qualidade
Garantia da qualidade
Recursos
humanos
Planejamento
organizacional
Desenvolvimento de
times
Controle da
qualidade
Contratao de
funcionrios e outros
recursos
Comunicao
Planejamento da
comunicao
Risco
Identificao do risco
Distribuio da
informao
Relatrios de
desempenho
Encerramento do
projeto
Controle de
resposta ao risco
Quantificao do risco
Definio de resposta ao
risco
Suprimento
Planejamento de
suprimento
Planejamento de
requisies e cotaes
Requisio
Seleo do fornecedor
Encerramento do
contrato
Administrao do
contrato
TABELA 9 - Processos de gerenciamento de projetos agrupados em reas e grupos.
80
Cap. 6 Concluso
Vale ressaltar que o reconhecimento das reas de gerenciamento como grupos de

processos, que devem ter suas preocupaes distintas, e de que existe um grupo geral que
analisa os impactos nas demais reas de gerenciamento uma grande contribuio rea
de informtica. Analisando separadamente estas reas tem-se num primeiro momento o
impacto do andamento das atividades em cada segmento, com uma viso bastante
detalhada, para num segundo momento verificar o impacto global deste acompanhamento.
O que normalmente ocorre no desenvolvimento dos sistemas de informao a total falta
de controle, quanto mais separado por rea.
Outra valiosa contribuio a definio formal das vrias fases pelas quais um projeto
passa, reforando a importncia da fase de planejamento, onde os diversos aspectos
relativos a cada rea de gerenciamento sero levantados e planejados. Outra caracterstica
importante a necessidade do incio formal do processo de desenvolvimento de um
sistema de informao, envolvendo todos os stakeholders (clientes, equipe, fornecedores)
em busca do comprometimento.
Tambm importante a constatao da necessidade de um encerramento formal das
atividades, com a resoluo das pendncias ainda existentes; sem isso, o projeto no pode
ser considerado como efetivamente concludo - processo no muito difundido na rea de
software, com vrios produtos sendo gerados e concludos sem que todos os aspectos
tenham sido cuidadosamente verificados, causando desgaste, m qualidade, custos e
descrdito para com os profissionais de informtica.
Os processos de controle so essenciais para garantir que os rumos planejados esto sendo
alcanados e que medidas corretivas eficazes esto sendo adotadas, quando necessrias.
Estes processos introduzem a necessidade de revises peridicas nas bases do projeto
(custo, prazo, qualidade, escopo) a fim de refletir as modificaes, alm de verificar
globalmente o impacto, uma vez que as modificaes ocorrem normalmente em mais de
uma rea.
Com a introduo destes conceitos nas organizaes o gerenciamento de processos de
desenvolvimento de sistemas de informao certamente ser otimizado. A implantao de
uma base histrica contendo:
dados dos projetos j desenvolvidos
lies aprendidas ao longo destes projeto
principais modificaes ocorridas nestes projetos (com respectivas anlises e

planos de ao)
tcnicas de engenharia de software utilizadas (incluindo tcnicas de estimativa

de software, como function points [MOOR98], feature points [JONE91] e
linhas de cdigo)
premissas adotadas em cada projeto
restries destes projetos
caractersticas do projeto
comparaes entre o que foi planejado e o que foi efetivamente realizado,
Cap. 6 Concluso
81
auxiliar e garantir a evoluo dos processos e dos profissionais envolvidos com o

desenvolvimento do software43 .
Tambm recomendvel o intercmbio de experincias com profissionais e empresas que
utilizam tcnicas para melhorar a efetividade de seus processos de desenvolvimento de
sistemas de informao; vrias empresas no Brasil esto empenhadas em obter
certificaes como CMM e com isso a necessidade de aprofundamento nos requisitos, alm
da demonstrao prtica de que processos claros e efetivos de gerenciamento de projetos
esto sendo adotados, passa a ser vital. No mundo dos negcios isto passa a ser questo de
sobrevivncia para todos os envolvidos44 .
6.1. Sugestes para Futuros Trabalhos

A fim de continuar a abordagem aqui utilizada vrios aspectos poderiam vir a ser
trabalhados. Segue uma pequena lista com algumas sugestes de trabalhos futuros.
Verificao das mudanas introduzidas na nova verso do PMBoK Guide,

atualmente em fase de comentrios e com publicao final prevista para julho
de 2000 [BERG99], analisando os impactos e modificaes nos processos
relativos ao gerenciamento de projetos de software; segundo avaliao
preliminar, no havero grandes modificaes, excetuando-se o captulo sobre
gerenciamento de riscos que aparentemente foi rescrito.
Avaliar os resultados da implantao pelo PMI dos processos relativos ao

gerenciamento de competncias das organizaes ([AYER99] e [COMB99]) no
que diz respeito ao gerenciamento dos projetos; esta uma atividade nova
dentro do PMI e o enfoque o de classificar as empresas segundo os mtodos e
prticas de gerenciamento de projetos por elas adotado.
Avaliar, atravs de pesquisas, em que medida o mercado brasileiro (e mundial)

vem adotando as prticas de gerenciamento de projetos para o desenvolvimento
de software.
Verificar a adoo do CMM e do PSP pelas empresas brasileiras e mundiais, em

que proporo isto est sendo feito e quais so as expectativas futuras.
Verificar possvel convergncia entre os preceitos de gerenciamento do PMI e

da ISO, atualmente muito distantes e com divergncias marcantes.
Propor certificao PMP especfica para profissionais de gerenciamento de

projetos de desenvolvimento de sistemas de informao.
Publicao efetiva de um adendo ao PMBoK Guide referente s peculiaridades

com o gerenciamento de processos de desenvolvimento de software.
43
A necessidade de ser possvel a repetio de bons desenvolvimentos de software abordada em diversos artigos, como
por exemplo [ROTH98].
44
Recomenda-se [DINS99], que aborda o gerenciamento de projetos como estratgia de negcio para as empresas.
82
ANEXO A Viso geral dos processos de gerenciamento de projetos
ANEXOS
ANEXO A - reas de conhecimento do gerenciamento de projetos
A.1. Gerenciamento de integrao
Uma viso geral dos processos de gerenciamento de integrao pode ser obtida na
FIGURA 28 - Viso geral dos processos de gerenciamento de integrao.
Gerenciamento
de Integrao em
Projeto
4.1. Desenvolver plano do

projeto
4.2. Executar plano do

projeto
4.3. Controlar mundanas
Entradas
Dados de planejamento dos
demais processos
Informaes histricas
Polticas organizacionais
Restries
Suposies
Ferramentas e tcnicas
Metodologia de
planejamento de
projetos
Conhecimentos e
habilidades dos
stakeholders
Sistema de informaes de
gerenciamento de
projetos
Produtos
Plano de projeto
Detalhes de planejamento
Entradas
Plano de projeto
Detalhes de planejamento
Aes corretivas
Gerenciamento de
habilidades
Conhecimento e
habilidades de produtos
Sistemas de autorizao de
trabalho
Reunies de reviso de
andamento do projeto
gerenciamento de
projetos
Procedimentos
organizacionais
Produtos
Resultados do trabalho
Solicitaes de mudana
Entradas
Plano do projeto
Relatrios de performance
Solicitaes de mudana
Sistema de controle de
mudanas
Gerenciamento de
configurao
Medies de performance
Planejamento adicional
gerenciamento de
projetos
Produtos
Atualizao no plano de
projeto
Aes corretivas
Lies aprendidas
FIGURA 28 - Viso geral dos processos de gerenciamento de integrao

A.1.1. Grupo de processos 4.1. Desenvolver plano do projeto
83
Consiste no conjunto de processos necessrios a criao de uma documentao consistente

e coerente a partir das informaes geradas nas demais reas de gerenciamento de projetos,
possibilitando o correto desempenho dos processos de execuo e controle do projeto.
Dentre as entradas de dados destes processos tem-se os dados de planejamento gerados
nos demais processos , as informaes histricas, como estimativas, registros de
desempenho de projetos passados e outros, as polticas organizacionais, uma vez que o
projeto dever seguir alguns padres j estabelecidos nas organizaes envolvidas
(qualidade, aspectos administrativos, controles financeiros dentre outros), as restries,
que correspondem aos fatores que limitam o projeto 45 e as suposies, que correspondem
aos fatores assumidos como verdadeiros.
As ferramentas e tcnicas disponveis so a metodologia de planejamento de projetos,
que consiste em abordagem estruturada e padronizada que auxiliar o time na conduo do
projeto, envolvendo modelos (templates) de documentos necessrios, ferramentas de
planejamento e milestones principais no projeto (por exemplo, reunies de reviso e
validao ao longo do desenvolvimento); os conhecimentos e habilidades dos
stakeholders, que podem ser teis no desenvolvimento do projeto, cabendo ao identificlos e utiliz-los da melhor forma possvel, alm dos sistemas de informao de
gerenciamento de projetos, que garante a integrao de todas as reas de gerenciamento
de projetos46 .
Como produtos esperados tem-se o plano do projeto, que congrega todos os planos
elaborados nas demais reas de gerenciamento de projetos, de forma a possibilitar a
execuo e o controle integrado do projeto, alm de detalhes de planejamento, que
consistem em documentos e informaes complementares ao plano de projeto (como por
exemplo documentao tcnica, requisitos, notas de reunio e outros).
A.1.2. Grupo de processos 4.2. Executar plano de projeto
Consiste no conjunto de processos necessrios a execuo adequada do projeto, integrando
todas as demais reas de gerenciamento de projetos.
Dentre as entradas de dados destes processos tem-se o plano do projeto, que contm os
planos de gerenciamento e as bases para medidas de desempenho, os detalhes de
planejamento, as polticas organizacionais, que podem afetar a execuo do projeto e as
aes corretivas, que so geradas a partir dos diversos grupos de processos de controle e
que visam garantir que o projeto voltar a ser executado da forma planejada.
As ferramentas e tcnicas disponveis so o gerenciamento de habilidades, tais como
liderana 47 , comunicaes e negociao, essenciais para o bom andamento do projeto; os
conhecimentos e habilidades dos produtos, que devem estar acessveis ao time do
projeto; os sistemas de autorizao de trabalhos, que consistem em procedimentos
45
As condies contratuais do projeto correspondem a restries que devem ser rigorosamente observadas [PMIS96].
46
Ferramentas que tenham por objetivo garantir a integrao de todas as reas vm sendo perseguidas por diversas
empresas. A grande maioria das ferramentas se preocupa com alguns aspectos (por exemplo, gerenciamento de tempo
e custo) mas no existe ainda ferramentas que contemplem todos os processos envolvidos com o gerenciamento. A
System Corporation (http://www.syscorp.com) vem desenvolvendo uma ferramenta, contando com o aval do PMI, que
visa contemplar todas estas etapas [SYST97].
47
Existe vasta bibliografia sobre liderana; uma referncia interessante pode ser obtida em [BLAN86].
84
formais para garantir que os trabalhos sero feitos no tempo e na seqncia adequados48 ; as
reunies de reviso de andamento do projeto, que correspondem a reunies regulares
visando a troca de informaes sobre o projeto; o sistema de informaes de
gerenciamento de projetos e os procedimentos organizacionais, que correspondem aos
procedimentos j adotados pelas organizaes envolvidas com o projeto e que podem
contribuir para a perfeita execuo do mesmo.
Como produtos esperados tem-se os resultados do trabalho, que consistem em
informaes sobre os trabalhos que esto sendo executados (quais foram completamente
executados, quais no foram, qual o nvel de qualidade atingido, dentre outras
informaes), alm das solicitaes de mudana, identificadas durante a execuo e que
necessitaro serem tratadas pelo time do projeto.
A.1.3. Grupo de processos 4.3. Controlar mudanas
Consiste no conjunto de processos necessrios a) influenciar os fatores que criam
necessidades de mudanas a fim de garantir que estas mudanas sejam benficas para o
projeto; b) determinar que uma mudana aconteceu (ou vai acontecer) e c) gerenciar as
mudanas quando estas ocorrerem. Neste grupo de processos a preocupao de que a
mudana seja refletida em todas as reas de gerenciamento de projetos (por exemplo, uma
mudana de escopo pode introduzir modificaes em custos e prazos).
Dentre as entradas de dados destes processos tem-se o plano do projeto, os relatrios de
performance, que provem informaes referentes ao andamento do item que est sendo
modificado, as solicitaes de mudana, que podem ser geradas tanto pelos clientes
quanto pela equipe do projeto.
As ferramentas e tcnicas disponveis so o sistema de controle de mudanas, que define
o procedimento pelo qual o projeto poder ser modificado, devendo incluir as clusulas
jurdicas, os procedimentos de auditoria e aprovaes necessrias ao tratamento adequado
destas solicitaes 49 ; o gerenciamento de configurao, que correspondem a
procedimentos documentados usados para garantir rastreabilidade de todas as solicitaes
de mudanas e seus impactos, as medies de performance, que indicam o impacto das
mudana, o planejamento adicional, decorrente da mudana, podendo ocasionar
modificaes na WBS 50 ou at mesmo anlise de novas alternativas, alm do sistema de
informaes de gerenciamento de projetos.
Como produtos esperados tem-se a atualizao no plano de projeto, que deve ser
reportada adequadamente aos stakeholders, as aes corretivas, a fim de evitar novos
problemas neste e em futuros projeto, e lies aprendidas, que possibilitaro evitar no
48
Vale notar que estes controles devem ser feitos tendo em mente o tamanho do projeto e a relao entre os custos do
controle sobre o projeto; possivelmente pequenos projetos demandaro controles com menor grau de formalidade
[PMIS96].
49
Dependendo do porte do projeto existe a necessidade de criao de um comit de anlise de modificaes (change
control board - CCB [PMIS96]) composto por representantes dos diversos stakeholders a fim de entender e aprovar ou
rejeitar as modificaes encaminhadas.
50
WBS - work brekdown structure - corresponde a uma estrutura analtica em formato de rvore que agrupa os elementos
que descrevem totalmente o escopo do empreendimento - em tese, trabalho no descrito na WBS no faz parte do
projeto - deve ser tratado como mudana de escopo!; deve ser orientada produo dos deliverables. A WBS ilustra
como cada parte do trabalho contribui com o todo em termos de responsabilidades, oramento e prazos, servindo de
ponto de partida para os processos de identificao das atividades, suas duraes e estimativa de custos [GASP98c].
85
futuro algumas das modificaes ocorridas no projeto em questo, devendo serem

registrados e armazenados de forma organizada as causas, os efeitos e as medidas
adotadas.
A.2. Gerenciamento de escopo

Uma viso geral dos processos de gerenciamento de escopo pode ser obtida na FIGURA
29 - Viso geral dos processos de gerenciamento de escopo.
Gerenciamento
de Escopo de
Projeto
5.1. Iniciar
5.2. Planejar escopo
5.3. Definir escopo
Entradas
Descrio do produto
Plano da estratgia
Critrio de seleo
Dados histricos
Mtodos de seleo
Apoio de especialistas
Produtos
Contrato
Gerente do projeto
Restries
Suposies
Entradas
Descrio do produto
Contrato
Restries
Suposies
Anlise de produtos
Anlise de custo/benefcio
Identificao de alternativas
Produtos
Declarao de escopo
Detalhamento
Plano de gerenciamento de
escopo
Entradas
Declarao do escopo
Restries
Suposies
Dados histricos
Template de WBS
Decomposio
Produtos
WBS
5.4. Verificar escopo
5.5. Controlar mudanas de

escopo
Entradas
Documentao do produto
Inspeo
Produtos
Aceitao formal
Entradas
WBS
Relatrios de progresso
Requisies de mudanas
escopo
mudanas de escopo
Medies de progresso
Produtos
Mudanas de escopo
Aes corretivas
Lies aprendidas
FIGURA 29 - Viso geral dos processos de gerenciamento de escopo
86
A.2.1. Grupo de processos 5.1. Iniciar

Consiste no conjunto de processos necessrios ao reconhecimento formal de que um novo
projeto existe ou que um projeto j existente deva continuar em uma nova fase (evoluo).
o incio do reconhecimento formal de que um projeto est para ser iniciado. Pode ser
ativado a partir de um marco ou necessidade (evoluo tecnolgica), um pedido oriundo
dos clientes (requisio do usurio), um requisito legal (legislao) e outras razes.
Dentre as entradas de dados destes processos tem-se a descrio do produto, que contm
as caractersticas do produto/servio que o projeto dever gerar, bem como sua ligao
com as necessidades de negcio (justificativas), o plano da estratgia, onde o projeto em
questo deve estar alinhado com a estratgia da empresa (ou passar a ter mais um
componente de risco), o critrio de seleo, que a definio dos critrios aplicveis
seleo de projetos (retorno do investimento, participao de mercado, percepes de
rgos pblicos) e dados histricos, contendo os dados utilizados em projetos semelhantes
(vale notar que este item sempre estar presente, contendo o histrico das aes efetuadas
nas etapas anteriores de um dado processo).
As ferramentas e tcnicas disponveis so os mtodos de seleo de projetos, conhecidos
como modelos de deciso, estando divididos em duas grandes categorias: mtodos de
medio de benefcios (avaliaes comparativas, modelos econmicos e outros) e mtodos
de otimizao das restries (modelos matemticos lineares, no lineares, algoritmos), e
apoio de especialistas, podendo ser provido atravs de empresas de consultoria,
associaes tcnicas e de profissionais, grupos de empresas ou outras reas da empresa.
Como produtos esperados tem-se o contrato, que formaliza e reconhece a existncia do
projeto, incluindo as necessidades de negcio que o projeto deve atender e a descrio dos
produtos a serem gerados, a identificao do gerente do projeto, que deve ser feita o mais
breve possvel, as restries, que correspondem aos fatores que limitam o projeto (por
exemplo, um projeto somente poder ser feito com oramento inferior a um certo valor
corresponde a uma restrio de custo [PMIS96]) e as suposies, que so fatores
considerados como verdadeiros ou certos para o projeto, geralmente envolvendo riscos
(por exemplo, a data na qual um determinado recurso estar disponvel para iniciar sua
participao no projeto [PMIS96]).
A.2.2. Grupo de processos 5.2. Planejar escopo
Consiste no conjunto de processos necessrios ao desenvolvimento de uma declarao
formal do escopo que ser base para futuras decises (por exemplo, identificar se uma dada
fase foi completada com sucesso). Isto crucial a fim de garantir o perfeito entendimento
entre o time do projeto e o cliente, atravs da identificao dos objetivos do projeto (e cada
uma das fases) e os produtos e subprodutos a serem gerados.
Dentre as entradas de dados destes processos tem-se a descrio do produto, o contrato,
as restries e as suposies, descritas anteriormente no tpico A.2.1.
As ferramentas e tcnicas disponveis so a anlise de produtos, que envolve o
desenvolvimento de um melhor entendimento dos produtos do projeto (engenharia de
sistemas, engenharia de valor, anlise de valor, anlise funcional e outras tcnicas), as
87
anlises de custo/benefcio, que visam verificar a relao custo/benefcio do projeto,

envolvendo a estimativa de custos tangveis e intangveis e benefcios de vrias alternativas
de projeto para ento fazer a efetiva medio financeira, atravs da taxa de retorno do
investimento, a identificao das alternativas, com o uso de tcnicas de brainstorming51 e
outras tcnicas de identificao de novas possveis solues, alm do apoio de
especialistas.
Como produtos esperados tem-se a declarao de escopo, que prov para os envolvidos a
base para decises relativas ao escopo do projeto, devendo incluir a justificativa do projeto
(para que fazer o projeto), os produtos do projeto, os deliverables do projeto (detalhados
por fase, de forma a identificar quais deliverables determinam o cumprimento de quais
etapas), os objetivos do projeto (de forma a quantificar os resultados esperados a fim de
considerar que o projeto, ao seu trmino, tenha atingido suas metas), o detalhamento
relativo declarao de escopo, organizado de forma a facilitar possveis buscas de
detalhes e o plano de gerenciamento de escopo, que descreve como o escopo do projeto
ser gerenciado e como as modificaes de escopo sero tratadas no projeto (deve conter
uma breve descrio de como as mudanas de escopo sero identificadas e classificadas,
qual a periodicidade deste tratamento, alm de outras informaes relevantes para garantir
o bom andamento do projeto).
A.2.3. Grupo de processos 5.3. Definir escopo
Consiste no conjunto de processos necessrios diviso dos produtos necessrios ao
projeto em deliverables menores, a fim de garantir um maior gerenciamento, definindo
responsabilidades de forma mais detalhada, e melhorar as estimativas de custo, prazo e
esforo. Corresponde a uma das etapas mais crticas para o sucesso do projeto.
Dentre as entradas de dados destes processos tem-se a descrio do produto, as
restries, as suposies e os dados histricos, descritos anteriormente no tpico A.2.1.,
alm de possveis revises efetuadas.
indicado o uso de templates de WBS, que consistem em utilizar uma WBS de um projeto
similar anteriormente realizado como base para a construo da WBS especfica deste
projeto. A FIGURA 30 - Exemplo de WBS para um projeto - ilustra um exemplo real de
WBS [UCHO98].
Outra ferramenta indicada para esta fase a decomposio, que consiste em dividir os
produtos esperados do projeto em partes menores, envolvendo as etapas de identificar
quais so os elementos principais do projeto, que se tornaro deliverables de uma dada
fase/etapa (relativa a WBS), decidir se as estimativas de custo e prazos podem ser
realizadas com sucesso no atual nvel de detalhe - caso contrrio, recomenda-se uma maior
decomposio - identificar os elementos que constituem os deliverables (descritos em
funo de resultados a serem verificados e como o trabalho pode ser acompanhado); para
que o nvel de decomposio seja atingido necessrio analisar as respostas s seguintes
questes: a somatria de todos os elementos no nvel mais baixo de decomposio deve ser
51
A palavra brainstorming vem sendo tradicionalmente utilizada em sua grafia original (em ingls). Descreve um
processo de identificao de problemas e levantamento de idias que consiste em promover um encontro de diversas
pessoas envolvidas com o tema em questo e criar um ambiente no qual estas se sintam vontade para externar, livres
de censuras e crticas prvias, suas idias; somente aps este levantamento de dados que estas idias passam por uma
discusso e uma consolidao entre o grupo.
88
suficiente e necessria para a completa execuo do nvel de decomposio superior, todos

os itens devem estar clara e completamente definidos, alm da identificao do oramento,
planejamento e responsvel.
Work Breakdown Structure
SPG7
Localidade 1
Infra-estrutura
Infra IU
Obras Civis
Energia CC
Infra RD
Localidade ...
Localidade 15
Transmisso
MUX/ELO/MCP
Energia CA
Gerenciamento
Rede Externa
Radio
Comutao
Projeto
Projeto
Fornecimento
Fornecimento
Inst./testes
Inst./testes
Aceitao
Aceitao
Projeto
Fornecimento
Projeto
Inst./testes
Fornecimento
Aceitao
Inst./testes
Aceitao
Fonte: [UCHO98] pg. 64
FIGURA 30 - Exemplo de WBS para um projeto

Como produtos esperados tem-se a WBS do projeto. Cada elemento da WBS deve possuir
um cdigo nico de identificao, o que possibilita seu gerenciamento. Os elementos dos
nveis mais detalhados so chamados de work packages52 , que formam a base para o
gerenciamento de escopo.
A.2.4. Grupo de processos 5.4. Verificar escopo
Consiste no conjunto de processos necessrios formalizao do processo de aceitao do
escopo pelos stakeholders, sendo necessria a reviso dos produtos e resultados atingidos a
fim de garantir que o projeto foi completado com sucesso.
Dentre as entradas de dados destes processos tem-se os resultados do trabalho, que
correspondem a quais deliverables foram completamente ou parcialmente concludos e
com que custo e a documentao do produto, que consiste em ter os documentos
produzidos para descrever as caractersticas dos produtos atualizados para verificao.
A tcnica indicada para estes processos a inspeo, que inclui atividades de medio,
exame e testes a fim de determinar se os resultados esto conforme a especificao inicial.
52
O Grupo de Coordenao PERT (1962) definiu o Work Package como o trabalho necessrio para se completar uma
determinada tarefa ou processo como um relatrio, projeto, documentao ou frao de um dado produto ou servio.
O PMBoK define o Work Package como um deliverable no nvel mais baixo da WBS [GAPS98c].
89
Como produto esperado tem-se a aceitao formal do escopo, que formaliza a aceitao
por parte dos clientes. vital para a continuidade do desenvolvimento do projeto.
A.2.5. Grupo de processos 5.5. Controlar mudanas de escopo
Consiste no conjunto de processos necessrios determinar as possveis mudanas de
escopo, os fatores que levaram a estas mudanas e o gerenciamento destas mudanas, caso
ocorram. Deve interagir de forma integrada com os demais processos de controle de
mudanas (tempo, custo e outros).
Dentre as entradas de dados destes processos tem-se a WBS, os relatrios de progresso,
que provm informaes referentes ao andamento do item que est sendo modificado
(muitas vezes o item j foi concludo), servindo de referncia para posterior negociao, as
requisies de mudanas, que podem ser geradas tanto pelos clientes quanto pela equipe
do projeto geralmente como resultado de evento externo (modificaes na lei) ou
descoberta de erro ou omisso no escopo original ou evolues necessrias no previstas
anteriormente e o plano de gerenciamento de escopo, descrito anteriormente no tpico
A.2.3.
indicado o uso de sistema de controle de mudanas de escopo, que define o
procedimento pelo qual o escopo do projeto poder ser modificado, devendo incluir as
clusulas jurdicas, os procedimentos de auditoria e aprovaes necessrios ao tratamento
adequado destas solicitaes. Tambm so indicadas as medies de progresso, a fim de
identificar a magnitude de uma dada modificao de escopo, e o planejamento adicional,
decorrente da mudana de escopo, podendo ocasionar modificaes na WBS ou at mesmo
anlises de novas alternativas.
Como produtos esperados tem-se as mudanas de escopo do projeto que foram aceitadas,
com a respectiva documentao (WBS, documentos tcnicos, cronograma e outros)
atualizada; tambm so produtos as aes corretivas, a fim de evitar novos problemas
neste projeto, e lies aprendidas, que possibilitaro no futuro evitar que novos projetos
tambm sofram algumas das modificaes de escopo ocorridas no atual, devendo serem
adotadas.
A.3. Gerenciamento de tempo

Uma viso geral dos processos de gerenciamento de tempo pode ser obtida na FIGURA 31
- Viso geral dos processos de gerenciamento de tempo.
A.3.1. Grupo de processos 6.1. Definir atividades
Consiste no conjunto de processos necessrios identificao e documentao de
atividades especficas que devem ser realizadas a fim de produzirem os produtos
(deliverables) e sub-produtos identificados na WBS. Segundo [PMIS96], consiste em
90
"definir corretamente quais atividades devem ser realizadas a fim de que os objetivos do
projeto sejam atingidos".
Gerenciamento
de Tempo em
Projeto
6.1. Definir atividades
6.2. Seqenciar atividades
6.3. Estimar durao das

atividades
Entradas
WBS
Declarao de escopo
Informaes histricas
Restries
Suposies
Decomposio
Templates
Produtos
Lista de atividades
Detalhamento de atividades
Atualizaes da WBS
Entradas
Lista de atividades
Descrio do produto
Dependncias obrigatrias
Dependncias descritivas
Dependncias externas
Restries
Suposies
Diagramas de precedncia
Diagramas de setas
Diagramas condicionais
Templates de rede
Produtos
Rede do projeto
Lista atualizada de
atividades
Entradas
Lista das atividades
Restries
Suposies
Requisitos de recursos
Capacidade de recursos
Informaes histricas
Estimativa por analogia
Simulao
Produtos
Estimativas de durao
Base das estimativas
Lista atualizada de
atividades
6.4. Desenvolver
acompanhamento
6.5. Controlar
acompanhamento
Entradas
Rede do projeto
Estimativas de durao
Descrio dos recursos
Calendrios
Restries
Suposies
Folgas
Anlise matemtica
Compresso de durao
Simulao
Nivelamento de recursos
Software de planejamento
Produtos
Cronograma
Detalhamentos
Plano de gerenciamento
Atualizao dos requisitos
de recursos
Entradas
Cronograma
Plano de gerenciamento
mudanas de tempo/
prazos
Medies de progresso
Software de planejamento
Produtos
Mudanas de cronograma
Aes corretivas
Lies aprendidas
FIGURA 31 - Viso geral dos processos de gerenciamento de tempo
91
Dentre as entradas de dados destes processos tem-se a WBS, a declarao de escopo, que
contm a justificativa e os objetivos do projeto a serem considerados na identificao das
atividades, as informaes histricas, que correspondem s atividades identificadas e
realizadas anteriormente em projetos similares, as restries, que correspondem aos
fatores que limitam as opes de tempo do time do projeto, as suposies, que, para efeito
de planejamento, devem ser consideradas como verdadeiras, reais ou certas, envolvendo
geralmente um grau de risco (a ser detalhado em tpico oportuno).
As ferramentas e tcnicas disponveis so a decomposio, que consiste em subdividir os
elementos de projeto em elementos menores (componentes gerenciveis) a fim de prover
um melhor controle gerencial; semelhante quela descrita em A.2.3. (Grupo de processos
5.3. Definir escopo), sendo que a principal diferena entre a decomposio de escopo e de
tempo a preocupao da primeira com os deliverables (itens tangveis) e da segunda com
as atividades (aes). Outra tcnica que pode ser utilizada consiste no uso de templates,
que correspondem ao uso de listas de atividades j utilizadas em outros projetos como base
para o projeto em questo, cabendo tambm o uso de atividades definidas para um
determinado elemento da WBS do projeto como modelo para a definio de atividades de
outro elemento similar da mesma WBS.
Como produtos esperados tem-se a lista de atividades, que inclui todas as atividades que
devem ser realizadas no projeto; deve estar organizada como uma extenso da WBS a fim
de garantir a) que todo trabalho a ser realizado est descrito em termos de atividade e b)
que toda atividade tem sua correspondente solicitao no escopo de trabalho; tambm deve
ser gerado o detalhamento de atividades, que consiste no detalhamento das atividades
atravs de documentos necessrios ao perfeito entendimento das mesmas, e em
atualizaes da WBS, decorrentes de possveis identificaes de novos deliverables a
partir do processo de decomposio efetuado; estas atualizaes devem ser feitas em todos
os documentos gerados, tanto dos processos de gerenciamento de escopo quanto dos
processos de gerenciamento de custo, e podem ocorrer ao longo de todo o projeto.
A.3.2. Grupo de processos 6.2. Seqenciar atividades
Consiste no conjunto de processos necessrios identificao e documentao das
dependncias entre as atividades anteriormente especificadas. de vital importncia a fim
de possibilitar um efetivo controle e caminhos alternativos para o gerente do projeto em
questo.
Dentre as entradas de dados destes processos tem-se a lista de atividades, definidas no
grupo anterior de processos, a descrio do produto, que possibilitar definir
caractersticas para o seqenciamento lgico das atividades, as dependncias
obrigatrias 53 , que correspondem s situaes obrigatrias devido natureza do trabalho a
ser realizado, normalmente associadas a limitaes fsicas (por exemplo, no caso da
construo de uma planta industrial o incio da fase de levantamento da superestrutura est
condicionado ao trmino das obras de fundao [PMIS96]), as dependncias
descritivas 54 , que correspondem s dependncias definidas pelo time do projeto (devem
53
Na terminologia de gerenciamento de projetos estas dependncias tambm so conhecidas como hard logic.
54
Na terminologia de gerenciamento de projetos estas dependncias tambm so conhecidas como soft logic.
92
ser utilizadas cuidadosamente, muito bem documentadas e normalmente baseada em

conhecimentos oriundos das melhores prticas de uma determinada rea de aplicao), as
dependncias externas, que correspondem quelas que representam relacionamentos entre
atividades do projeto e atividades fora do projeto (externas a este), as restries e as
suposies.
As ferramentas e tcnicas disponveis so os diagramas de precedncia, que consistem
em construir a rede 55 de atividades utilizando ns para representar as atividades,
conectando-as com setas a fim de indicar as dependncias [PMIS96]; inclui quatro tipos de
dependncias entre as atividades: FS 56 (a atividade origem deve finalizar antes que a
atividade destino possa ser iniciada); FF (a atividade origem deve finalizar antes que a
atividade destino possa ser finalizada); SS (a atividade origem deve iniciar antes que a
atividade destino possa ser iniciada); SF (a atividade origem deve iniciar antes que a
atividade destino possa ser finalizada). Tambm podem ser utilizados os diagramas de
setas que consistem em construir a rede de atividades utilizando setas para representar as
atividades conectando-as em ns para representar duas dependncias, sempre do tipo FS.;
os diagramas condicionais 57 tambm podem ser utilizados para situaes especficas, em
especial situaes no suportadas pelos diagramas anteriormente mencionados (por
exemplo, para o tratamento de atividades no seqenciais tais como atividades repetitivas);
os templates de rede que correspondem s redes j utilizadas em outros projetos
anteriormente conduzidos, podendo ser na sua totalidade ou em partes (conhecidas como
sub-redes). Para a implantao dos mtodos acima mencionados podem ser utilizadas
ferramentas automatizadas disponveis no mercado, dentre as quais o MS-Project 58
corresponde ferramenta mais utilizada pelo mercado, o Primavera Project Planner59 e o
Artemis Views60 s ferramentas consideradas como as mais profissionais e completas
([CABA98], [CAJA99], [FOX98] e [KING98]).
Como produtos esperados tem-se a rede do projeto, que consiste em um diagrama que
ilustra as atividades do projeto e suas ligaes lgicas (dependncias), podendo ser feita de
forma a contemplar todo o detalhamento ou agrupar o projeto em atividades sumrio
(conhecidas como hammocks); tambm gerada como produto a lista atualizada de
atividades em funo de novas atividades includas nesta etapa do planejamento.
A.3.3. Grupo de processos 6.3. Estimar durao das atividades
55
O termo rede de atividades utilizado para descrever as atividades necessrias para o desenvolvimento de um projeto,
suas dependncias e recursos associados.
56
Este o tipo de dependncia entre atividades mais encontrado, indicando ligaes em srie (atividade predecessora
termina para que a atividade sucessora possa ser iniciada). Os demais tipos de dependncia indicam trabalhos em
paralelo e devem ser utilizados com cautela e critrio.
57
Dentre os modelos desta categoria tem-se o GERT (Graphical Evaluation and Review Technique), extenso do PERT
(Project Evaluation and Review Technique). Para maiores informaes recomenda-se [PMIS96].
58
Maiores informaes sobre o MS-Project em http://www.microsoft.com/project.
59
Maiores informaes sobre o Primavera Project Planner em http://www.primavera.com.
60
Maiores informaes sobre

http://www.artemispm.com.
Artemis
Views
em
http://www.konsultex.com.br/artemis.html
em
93
Consiste no conjunto de processos necessrios definio do nmero de perodos de

tempo necessrios para a concluso das atividades anteriormente especificadas; estes
perodos podem ser contnuos ou no, dependendo das exigncias das atividades.
Dentre as entradas de dados destes processos tem-se a lista das atividades, as restries,
as suposies, os requisitos de recursos, que podero influenciar na durao das
atividades (por exemplo, o fato de uma atividade ser executada por um ou por dois
recursos poder ter impacto na durao desta atividade), a capacidade de recursos, que
poder influenciar na durao das atividades (por exemplo, uma mesma atividade sendo
executada por um profissional snior ou por outro jnior poder ter sua durao
modificada) e as informaes histricas, podendo ser obtidas a partir de projetos j
realizados, catlogo internacionais de especialidades, base de conhecimento da empresa e
outras fontes.
As ferramentas e tcnicas disponveis so o apoio de especialistas, que consiste em contar
com o apoio de consultorias especializadas para apoiar os processos de estimativas no caso
de falta de capacitao da organizao para tal fim (vale notar que com isto o risco do
projeto pode ser elevado); a estimativa por analogia tambm pode ser utilizada, em
especial em projetos onde o nvel de detalhe ainda pequeno, consistindo em utilizar as
duraes de atividades j realizadas como base para o planejamento das atividades ainda
por fazer e a simulao que consiste em utilizar vrios modelos matemticos para clculos
de durao baseados em suposies/premissas diferentes 61 .
Como produtos esperados tem-se as estimativas de durao, que consistem em detalhar
para cada atividade o nmero de perodos de tempo necessrio, podendo ser de forma
conclusiva (2 dias, por exemplo), de forma aproximada (entre 2 e 4 dias, por exemplo) ou
indicando incertezas/probabilidades (85% de probabilidade de exceder 2 dias, por
exemplo); a base das estimativas, que consiste em documentar os critrios utilizados para
se chegar s estimativas de durao e a lista atualizada de atividades, contemplando
possveis atualizaes oriundas das estimativas de durao.
A.3.4. Grupo de processos 6.4. Desenvolver acompanhamento
Consiste no conjunto de processos necessrios determinao de datas de incio e trmino
para as atividades do projeto; devem ser realistas a fim de possibilitarem um planejamento
exeqvel, devendo para tanto interagir com outros processos de gerenciamento, em
especial com os processos de estimativas de durao e de custo.
Dentre as entradas de dados destes processos tem-se a rede do projeto, as estimativas de
durao, os requisitos de recursos, a descrio dos recursos, que identifica as
disponibilidades dos recursos, os calendrios, que identificam os perodos de tempo teis
para o trabalho, quer seja para os recursos quer seja para o projeto, as restries, que
correspondem especialmente a datas impostas, por questes contratuais ou para atender a
alguma exigncia de um dos stakeholders, as suposies e as folgas entre as atividades,
podendo ser negativas (por exemplo, uma atividade deve iniciar um dia antes de outra
finalizar) ou positivas (por exemplo, uma atividade deve comear aps trs dias do trmino
da atividade predecessora).
61
A anlise de Monte Carlo a tcnica mais utilizada para simulaes, estando disponvel em diversas ferramentas
automatizadas (aplicativos e planilhas de clculo).
94
As ferramentas e tcnicas disponveis so a anlise matemtica, que consistem em teorias

matemticas baseadas em clculos envolvendo as datas mais cedo e mais tarde 62 ; dentre as
tcnicas mais utilizadas tem-se o Mtodo do Caminho Crtico (CPM), que consiste em
determinar o caminho crtico de uma determinada rede, encontrando o ramo que no
contm folgas, a Tcnica de Reviso e Evoluo Grfica (GERT), que envolve a anlise
probabilstica referente a concluso total ou parcial de atividades, a Tcnica de Reviso e
Evoluo de Programa (PERT ), que tambm considera o uso de probabilidades e
expectativas, diferenciando-se assim do CPM, que utiliza a durao estimada para seus
clculos. Outras tcnicas que podem ser utilizadas so: a compresso de durao, que
corresponde a uma variao das tcnicas anteriores cujo objetivo principal o de descobrir
formas de tornar o projeto mais curto sem modificar o escopo (basicamente procurando
fazer mais atividades em paralelo), a simulao, o nivelamento de recursos, que significa
alocar os recursos s atividades e cuidar para que os conflitos sejam resolvidos da melhor
forma possvel (por exemplo, priorizando a alocao de recursos conflitantes em atividades
crticas, a fim de no atrasar o projeto) e o uso de software de planejamento, j
comentado anteriormente.
Como produtos esperados tem-se o cronograma, que contm ao menos as datas planejadas
mais cedo e mais tarde para cada atividade, podendo ser representado via grfico de barras
(a viso mais comum atualmente utilizada), rede de precedncias, grfico de marcos
(milestones) e outras; os detalhamentos, que consistem em documentos produzidos e que
podero auxiliar em outros processos; o plano de gerenciamento de atividades, que
define como as modificaes sobre o cronograma sero gerenciadas, e a atualizao dos
requisitos de recursos, contemplando possveis atualizaes oriundas deste maior
detalhamento.
A.3.5. Grupo de processos 6.5. Controlar acompanhamento
Consiste no conjunto de processos necessrios ao controle do cronograma, identificando e
gerenciando as mudanas caso estas venha a ocorrer.
Dentre as entradas de dados destes processos tem-se o cronograma, incluindo o
cronograma original (tambm chamado de baseline) e o cronograma atual, os relatrios de
progresso, que contm informaes sobre atividades que performaram (ou no) conforme
planejado, alertando o time do projeto caso sejam antevistas condies diferentes das
inicialmente planejadas, as requisies de mudanas, que podem provocar atrasos no
cronograma ou at mesmo solicitaes para aceler-lo e o plano de gerenciamento.
As ferramentas e tcnicas disponveis so o sistema de controle de mudanas de
tempo/prazos, que define o procedimento a ser seguido para atender s requisies de
mudanas, incluindo rastreabilidade dos impactos das mudanas e os nveis necessrios de
aprovao para aceitar - ou no - a mudana; as medies de progresso, que auxiliam a
identificar possveis desvios entre o planejado e o realizado at o momento, possibilitando
analisar se existe a necessidade de se adotar medidas corretivas a fim de garantir a
concluso do projeto dentro dos requisitos iniciais; planejamento adicional, que pode ser
necessrio em funo de mudanas solicitadas ou a fim de corrigir algum eventual desvio
62
Conhecidas como early/late dates, correspondem s datas mais cedo (e mais tarde) que uma dada atividade poder
iniciar sem atrasar o projeto. Vale notar que as folgas em relao ao caminho crtico so calculadas subtraindo-se a
data mais cedo da data mais tarde (sendo que folgas negativas significam atraso).
95
do projeto e o uso de software de planejamento, extremamente indicado por automatizar

as funes descritas.
Como produtos esperados tem-se as mudanas de cronograma, que contm as
modificaes efetuadas em funo dos controles apresentados, mudanas estas que devem
ser notificadas aos stakeholders e em alguns casos mais srios identificar a necessidade de
atualizao do cronograma original (baseline); as aes corretivas, a fim de evitar novos
problemas neste projeto (especial preocupao em identificar aes a serem tomadas para
garantir que as atividades sejam concludas no tempo previsto ou pelo menos com o menor
impacto possvel no projeto) e lies aprendidas, que possibilitaro no futuro evitar para
novos projetos algumas modificaes de cronograma ocorridas no atual, devendo serem
adotadas.
A.4. Gerenciamento de custo

Uma viso geral dos processos de gerenciamento de custo pode ser obtida na FIGURA 32 Viso geral dos processos de gerenciamento de custo.
A.4.1. Grupo de processos 7.1. Planejar recursos
Consiste no conjunto de processos necessrios identificao de quais recursos fsicos
(pessoas, equipamentos, materiais) e qual a quantidade de cada um destes recursos ser
necessria para a concluso das atividades do projeto [PMIS96].
Dentre as entradas de dados destes processos tem-se a WBS, que define os elementos do
projeto que necessitaro de recursos, a declarao de escopo, que contm a justificativa e
os objetivos do projeto a serem considerados no planejamento dos recursos, as
informaes histricas, que correspondem aos tipos de recursos que foram anteriormente
utilizados em projetos similares, a descrio do conjunto de recursos, que consiste no
conjunto de recursos que possivelmente estaro disponveis para uso no projeto e as
polticas organizacionais, que definem as regras da organizao para os recursos prprios
e para o aluguel ou compra de itens de fornecimento e equipamentos de terceiros que
porventura venham a ser necessrios para a execuo do projeto.
As ferramentas e tcnicas disponveis so o apoio de especialistas, podendo ser provido
atravs de empresas de consultoria, associaes tcnicas e de profissionais, grupos de
empresas, outras reas da empresa e a identificao de alternativas.
Como produtos esperados tem-se os requisitos de recursos, que incluem uma descrio de
que tipos de recursos so requeridos e em que quantidade para cada elemento de trabalho
da WBS, sendo que estes recursos podero ser obtidos atravs de aquisio de pessoal ou
contratao.
A.4.2. Grupo de processos 7.2. Estimar custos
96
Gerenciamento
de Custo em
Projeto
7.1. Planejar recursos
7.2. Estimar custos
Entradas
WBS
Declarao de escopo
Informaes histricas
Descrio do conjunto de
recursos
Identificao de
alternativas
Produtos
Entradas
WBS
Taxas de recursos
Estimativas de durao das
atividades
Informaes histricas
Plano de contas
Estimativa por analogia
Modelagem paramtrica
Estimativa bottom-up
Software especfico
Produtos
Estimativas de custo
Detalhamento de custos
custos
7.3. Orar custos
7.4. Controlar custos
Entradas
WBS
Cronograma
Ferramentas e tcnicas de
estimativas de custo
Produtos
Base de custo
Entradas
Base de custo
custos
mudanas de custo
Medies de progresso
Software especfico
Produtos
Estimativas revisadas de
custo
Atualizao da base de
custo
Aes corretivas
Estimativas para concluso
Lies aprendidas
FIGURA 32 - Viso geral dos processos de gerenciamento de custo
97
Consiste no conjunto de processos necessrios ao desenvolvimento/estimativa de custo

aproximado para os recursos necessrios para executar o projeto 63 .
Dentre as entradas de dados destes processos tem-se a WBS, a fim de garantir que todo
elemento de trabalho identificado tenha sua estimativa de custo efetuada, os requisitos de
recursos, as taxas de recursos, que indicam as taxas por unidades de recurso (por
exemplo, custo por hora, valor do m3 de concreto) a fim de calcular o custo total do
projeto, as estimativas de durao das atividades, as informaes histricas, que podem
ser obtidas atravs de arquivos de projetos anteriormente executados, de base de dados
comerciais de estimativas de custo e do conhecimento dos membros do time de projeto,
alm do plano de contas, que consiste em um diagrama que descreve a estrutura de
codificao utilizada pela organizao a fim de comunicar as informaes financeiras e
demonstraes contbeis.
As ferramentas e tcnicas disponveis so as estimativas por analogia, utilizadas
especialmente em projetos onde o nvel de detalhe ainda pequeno, consistindo em utilizar
as estimativas de custos j realizadas como base para a estimativa dos ainda por realizar
(vale notar que a ferramenta mais rpida de ser utilizada, porm depende muito da
identificao de projetos similares anteriormente realizados e de que o time de projeto
tenha a maturidade suficiente para utilizar estas informaes com discernimento), a
modelagem paramtrica, que consiste em utilizar as caractersticas do projeto em um
modelo matemtico de determinao de custos, a estimativa bottow-up, que consiste na
estimativa dos custos de cada item de trabalho, na sumarizao destes custos e na
distribuio destes custos ao longo do projeto a fim de se calcular o custo total, alm do
uso de software especfico, tipo ferramentas de planejamento e planilhas eletrnicas, para a
estimativa de custos. Uma ferramenta til em diversas reas e processos definidos pelo
PMBoK pode ser obtida em [SYST97].
Como produtos esperados tem-se as estimativas de custo, que correspondem ao valor do
custo associado aos recursos necessrios para a concluso do projeto em questo,
normalmente expressas em moedas (no caso do Brasil, ou em reais ou em dlar ou em um
ndice de referncia)64 , o detalhamento de custos, que inclui a descrio do escopo sobre
o qual o custo foi estimado, a documentao das bases utilizadas para a estimativa, a
documentao das premissas utilizadas e as margens das estimativas (quando no feita
pontualmente e indica um grau de incerteza), alm do plano de gerenciamento de custos,
que descreve como as variaes de custos sero gerenciadas.
A.4.3. Grupo de processos 7.3. Orar custos
Consiste no conjunto de processos necessrios para o estabelecimento de um oramento
base para o projeto, a partir das estimativas de custos associadas a cada item de trabalho.
Dentre as entradas de dados destes processos tem-se a WBS, as estimativas de custo e o
cronograma, incluindo as datas planejadas de incio e trmino de cada elemento ao qual
63
Vale notar que o foco custo (que envolve o quanto custar organizao a execuo do projeto) e no preo (que
definido em funo de definies do negcio - quanto a organizao receber pela execuo do projeto) - o custo
apenas um dos componentes do preo. [PMIS96]
64
Uma referncia bastante interessante pode obtida em [DEVE94].
98
sero alocados custos - esta informao necessria a fim de garantir que a alocao dos
custos seja feita no perodo correto de tempo no qual o custo incorrido.
As ferramentas e tcnicas para orar custos so as mesmas utilizadas para as estimativas de
custos.
Como produto esperado tem-se a base de custo, que corresponde a base de custos a ser
utilizada para medir e monitorar o desempenho de custos do projeto; desenvolvida
atravs da sumarizao das estimativas de custos por perodo e usualmente descrita como
uma curva S.
A.4.4. Grupo de processos 7.4. Controlar custos
Consiste no conjunto de processos necessrios ao controle dos custos, identificando e
gerenciando as mudanas quando estas ocorrerem, alm de garantir que estas mudanas
sejam beneficiais ao projeto. Deve incluir o monitoramento do desempenho do custo a fim
de detectar variaes frente ao planejado, garantir que as modificaes sejam registradas,
prevenir modificaes no autorizadas e informar adequadamente aos stakeholders sobre
as modificaes autorizadas.
Dentre as entradas de dados destes processos tem-se a base de custo, os relatrios de
progresso, que contm informaes sobre quais itens de custos estiveram de acordo com o
orado e quais no estiveram, alertando o time do projeto caso sejam antevistas condies
diferentes das inicialmente planejadas e que possam vir a representar problemas no futuro,
as requisies de mudanas, alm do plano de gerenciamento de custos.
As ferramentas e tcnicas disponveis so o sistema de controle de mudanas de custo,
que define o procedimento a ser seguido para atender s requisies de mudanas que
impactem no oramento base, incluindo rastreabilidade dos impactos destas mudanas e os
nveis necessrios de aprovao para autorizar que a mudana seja efetivada; as medies
de progresso, que auxiliam a identificar possveis desvios entre o planejado e o realizado
at o momento, utilizando anlise de valor presente (earned value) 65 e determinando o que
est causando as variaes visando identificar a necessidade de serem adotadas medidas
corretivas a fim de garantir a concluso do projeto dentro dos parmetros de custos iniciais;
planejamento adicional, que pode ser necessrio em funo de mudanas solicitadas ou a
fim de corrigir algum eventual desvio do projeto e reviso dos custos anteriormente
estimados e o uso de software especfico para controle de custos, tipo ferramenta de
planejamento e planilhas eletrnicas, normalmente utilizado para comparar custo real x
custo orado e o impacto previsto como efeito das modificaes de custo.
Como produtos esperados tem-se as estimativas revisadas de custo, que contm as
modificaes efetuadas em funo dos controles apresentados, mudanas estas que devem
ser notificadas aos stakeholders e em alguns casos mais srios identificar a necessidade de
atualizao da base de custo, que tambm pode ser modificada em funo de
modificaes de escopo; as aes corretivas, a fim de evitar novos problemas neste
projeto, as estimativas para concluso (estimate at completion - EAC), que
65
Identifica o esforo equivalente ao volume de recursos gasto at o momento. Para maiores informaes recomenda-se
[GASP98b] e [DINS97].
99
correspondem ao clculo do custo total do projeto baseado no desempenho do mesmo 66 e

lies aprendidas, que possibilitaro no futuro evitar para novos projetos as mesmas
causas de variao de custo, alm de registrar e organizar as aes tomadas no presente
projeto.
A.5. Gerenciamento da qualidade do processo

Uma viso geral dos processos de gerenciamento de qualidade pode ser obtida na FIGURA
33 - Viso geral dos processos de gerenciamento de qualidade.
Gerenciamento
de Qualidade em
Projeto
8.1. Planejar qualidade
8.2. Garantir qualidade
8.3. Controlar qualidade
Entradas
Poltica de qualidade
Declarao de escopo
Descrio do produto
Padres e normas
Outros documentos
Anlise custo/benefcio
Benchmarking
Diagramao
Desenvolvimento de
experimentos
Produtos
qualidade
Definies operacionais
Checklists
Entradas para os demais
processos
Entradas
qualidade
Resultados das medidas de
controle de qualidade
Ferramentas e tcnicas de
planejamento de
qualidade
Auditorias de qualidade
Produtos
Melhorias de qualidade
Entradas
qualidade
Checklists
Inspees
Diagramas de controle
Diagrama de pareto
Exemplos estatsticos
Diagramao
Anlise de tendncia
Produtos
Melhorias de qualidade
Decises para aprovao
Retrabalho
Complemento dechecklist
Ajustes de processo
FIGURA 33 - Viso geral dos processos de gerenciamento de qualidade
66
As tcnicas mais utilizadas para clculo de EAC so: a) Custo real at o momento + (custo orado remanescente * fator
de performance) - quando a expectativa de que o comportamento atual seja parmetro para o futuro; b) Custo real at
o momento + (nova estimativa para o trabalho remanescente) - quando se chega a concluso que o oramento de custos
original estava baseado em premissas que no se mostraram verdadeiras e c) Custo real at o momento + (custo orado
remanescente) - quando as modificaes so encaradas como normais e o oramento inicial considerado como
satisfatrio e capaz de suportar estas modificaes.
100
A.5.1. Grupo de processos 8.1. Planejar qualidade

Consiste no conjunto de processos necessrios identificao de quais padres de
qualidade so relevantes para o projeto e determinar como satisfaz-los, sempre tendo em
mente que o gerenciamento da qualidade moderno consiste em medidas preventivas
(planejamento) e no corretivas (apenas nas inspees dos resultados).
Dentre as entradas de dados destes processos tem-se a poltica de qualidade , que define as
intenes e direes expressas da organizao condutora do projeto em relao
qualidade, podendo ser adaptada para o projeto em questo (caso seja necessrio ou
quando envolva vrias organizaes para a execuo do projeto), a declarao de escopo,
que documenta os principais produtos a serem produzidos e os objetivos a serem atingidos,
a descrio do produto, que contm detalhes sobre o produto que podem ser relevantes
para o planejamento da qualidade, os padres e normas, que devem ser considerados
levando-se em considerao a natureza do projeto e outros documentos que foram
produzidos nas demais reas de gerenciamento.
As ferramentas e tcnicas disponveis so a anlise custo/benefcio, cujo benefcio
primrio que se consegue seguindo os requisitos iniciais evitar retrabalho, o que significa
maior produtividade com menor custo e conseqente aumento da satisfao dos
stakeholders, o benchmarking, que envolve comparar o realizado ou planejado do projeto
corrente com outros projetos a fim de gerar idias que possibilitem melhorias de
performance, a diagramao, que consiste em diagramas que ilustrem vrios aspectos de
comportamento, possibilitando avaliao dos aspectos de qualidade do projeto,
antecipando possveis problemas (como exemplos, tem-se o diagrama de causa-efeito tambm conhecido como diagrama de Ishikawa ou grfico de peixe - para ilustrar como as
causas afetam a determinados problemas e os grficos de processos ou fluxogramas) e o
desenvolvimento de experimentos, que corresponde a uma tcnica analtica que auxilia a
identificar quais as variveis tem maior influncia nos processos (no caso de software,
pode-se considerar que o uso de prottipos est associado a esta tcnica).
Como produtos esperados tem-se o plano de gerenciamento de qualidade , que descreve
como o time do projeto ir implementar as polticas de qualidade, as definies
operacionais, que descreve em termos especficos, quais e o que so os elementos e como
so medidos pelo processo de controle de qualidade (por exemplo, como reconhecido que
cada atividade foi iniciada ou concluda dentro do prazo esperado), os checklists, que
correspondem a listas utilizadas para verificar que um conjunto de etapas de requisitos foi
realizado adequadamente, podendo ser elaborados especificamente para o projeto ou
utilizados/adaptados a partir de bases ou organismos internacionais, alm das entradas
para os demais processos geradas a partir do processo de planejamento da qualidade
antecipando futuras necessidades das demais reas de gerenciamento.
A.5.2. Grupo de processos 8.2. Garantir qualidade
Consiste no conjunto de processos necessrios garantia de que o projeto est sendo
executado de forma a satisfazer os padres de qualidade definidos anteriormente no plano
de gerenciamento de qualidade.
Dentre as entradas de dados destes processos tem-se o plano de gerenciamento de
qualidade , os resultados das medidas de controle de qualidade, que correspondem a
101
registros de testes e medidas de controle de qualidade efetuados com o intuito de

possibilitar comparaes e anlises, alm das definies operacionais deste projeto.
As ferramentas e tcnicas disponveis so as mesmas utilizadas no planejamento da
qualidade, alm das auditorias de qualidade , que consistem em uma reviso estruturada
das atividades de gerenciamento de qualidade objetivando identificar lies aprendidas,
podendo serem extradas de forma a conquistar ganhos para a organizao que est
executando o projeto; estas auditorias podem ser pr-agendadas ou aleatrias, devendo ser
conduzidas por profissionais qualificados (seja em auditorias internas ou em auditorias
conduzidas por organismos externos).
Como produtos esperados tem-se as melhorias de qualidade, que incluem as aes
tomadas visando melhorias da efetividade e da eficincia do projeto em benefcio dos
stakeholders.
A.5.3. Grupo de processos 8.3. Controlar qualidade
Consiste no conjunto de processos necessrios monitorao dos resultados especficos do
projeto a fim de determinar se o projeto est contemplando satisfatoriamente os padres de
qualidade estabelecidos e identificar caminhos para eliminar causas de resultados
insatisfatrios, incluindo tanto os produtos a serem gerados quanto os resultados gerenciais
(como por exemplo o desempenho de custos e tempo). importante diferenciar alguns
aspectos, a saber:
Preveno (manter o projeto sem erros) de inspeo (manter o projeto sem erros
que cheguem aos usurios);
Exemplos definidos (o resultado est de acordo - ou no - com as expectativas)

de exemplos variveis (o resultado est evoluindo em uma escala contnua que
est dentro dos graus de conformidade);
Causas especiais (eventos no comuns) de causas aleatrias (variaes normais

do processo);
Tolerncia (o resultado aceitvel se estiver dentro dos limites de tolerncia) de

limites de controle (o processo est sobre controle se seu resultado estiver
dentro dos limites de controle)
Dentre as entradas de dados destes processos tem-se os resultados do trabalho, o plano

de gerenciamento de qualidade, as definies operacionais alm dos checklists.
As ferramentas e tcnicas disponveis so as inspees, de forma semelhante s auditorias,
os diagramas de controle, que ilustram os resultados do processo, objetivando determinar
se o processo est sob controle ou no, quando ento auxilia a identificao das medidas a
serem tomadas a fim de possibilitar a retomada de controle, o diagrama de Pareto 67 , que
corresponde a um histograma que ilustra quantos resultados foram gerados para cada tipo
ou categoria de causa identificada, os exemplos estatsticos, que envolve a escolha de qual
parte da totalidade dos dados interessa para a inspeo, servindo para a reduo do custo
do processo de controle de qualidade, a diagramao, conforme estudada nos processos de
67
Refere-se a Lei de Pareto, que especifica que um nmero relativamente pequeno de causas responsvel pela grande
maioria dos problemas ou defeitos [PMIS96].
102
planejamento da qualidade alm da anlise de tendncia, que consiste em utilizar tcnicas

matemticas para estimar desempenho futuro baseado nos resultados histricos,
monitorando tanto o desempenho tcnico (quantos erros ou defeitos foram identificados e
quantos ainda remanescem) e o desempenho de custo e tempo (quantas atividades por
perodo foram completadas sem variaes significativas).
Como produtos esperados tem-se as melhorias de qualidade, as decises para
aprovao, que correspondem aos itens inspecionados e que podem ser aceitos ou
rejeitados (neste caso, iro requerer retrabalho), o retrabalho, que a ao necessria para
corrigir um erro ou uma no conformidade detectada, sendo que justamente o retrabalho
que corresponde a uma das principais razes para atrasos no projeto, o complemento de
checklist, que servir tambm de base histrica para futuros projetos, alm dos ajustes de
processo, que incluem as aes corretivas e preventivas resultantes dos processos de
controle e medio da qualidade.
A.6. Gerenciamento dos recursos humanos

Uma viso geral dos processos de gerenciamento de recursos humanos pode ser obtida na
FIGURA 34 - Viso geral dos processos de gerenciamento de recursos humanos.
A.6.1. Grupo de processos 9.1. Planejar organizao
Consiste no conjunto de processos necessrios identificao, documentao e designao
das regras do projeto, das responsabilidades e dos relacionamentos de controle e
superviso, relativos a indivduos ou grupos, internos ou externos organizao
responsvel pela conduo do projeto; normalmente tem forte relao com a rea de
gerenciamento de comunicaes, com influncias mtuas.
Dentre as entradas de dados destes processos tem-se as interfaces do projeto, usualmente
classificadas em trs categorias: a) interfaces da organizao, que correspondem s
ligaes internas entre as diferentes unidades da organizao responsvel pelo projeto; b)
interfaces tcnicas, que correspondem s relaes entre as diferentes disciplinas tcnicas do
projeto (por exemplo, as reas civil e hidrulica de um empreendimento certamente tero
relaes); c) interfaces interpessoais, que caracterizam as relaes entre os indivduos que
compem o time do projeto; os requisitos de pessoal, que definem os tipos de habilidades
necessrios aos diversos tipos de recursos a serem utilizados pelo projeto e as restries,
que so os fatores que limitam as opes do time do projeto, sendo normalmente geradas a
partir de alguns fatores: a) estrutura organizacional (conforme visto no item 4.2.2.2.
Estruturas organizacionais) que pode influenciar na autonomia do time; b) acordos
coletivos para uso de recursos de outros envolvidos; c) preferencias do time do projeto,
normalmente oriundas de uso com sucesso em projetos anteriores; d) restries relativas ao
perfil dos indivduos envolvidos.
As ferramentas e tcnicas disponveis so os templates, que consistem no uso de materiais
elaborados em projetos anteriores similares de forma a agilizar a concluso destes
processos; as prticas de recursos humanos j adotadas pela organizao responsvel
pelo projeto que podem auxiliar na conduo destes processos; a vasta bibliografia
disponvel sobre teoria organizacional, que descreve como as organizaes podem (e
103
devem) ser estruturadas, alm da anlise dos stakeholders, que consiste em analisar as
necessidades dos diversos stakeholders a fim de garantir que estas sejam atendidas.
Como produtos esperados tem-se a designao de regras e responsabilidades, que
descrevem quem realiza o que (regras) e quem decide o que (responsabilidades), podendo
ser variveis ao longo do projeto 68 , o plano de gerenciamento de pessoal, que descreve
quando e como os recursos humanos sero alocados e desalocados do time do projeto 69 , o
diagrama organizacional, que exibe as relaes de autoridade e responsabilidade dos
envolvidos no projeto, sendo que a estrutura da organizao (OBS - Organizational
Breakdown Structure) um tipo especfico que ilustra como as unidades organizacionais
so responsveis pelos itens de trabalho, alm dos detalhes de pessoal, que consistem em
informaes adicionais que podem vir a ser utilizadas nos demais processos, tais como,
impacto organizacional, a descrio dos cargos e os treinamentos necessrios para o time.
Gerenciamento
de Recursos Humanos em
Projeto
9.1. Planejar organizao
9.2. Aquisio de pessoal
9.3. Desenvolver time
Entradas
Interfaces do projeto
Requisitos de pessoal
Restries
Templates
Prticas de recursos
humanos
Teoria organizacional
Anlise dos stakeholders
Produtos
Designao de regras e
responsabilidades
pessoal
Diagrama organizacional
Detalhes de pessoal
Entradas
pessoal
Descrio do conjunto de
pessoas
Prticas de recrutamento
Negociao
Pr-indicaes
Subcontratao
Produtos
Designao do pessoal do
projeto
Diretrio do time do projeto
Entradas
Pessoal do projeto
Plano do projeto
pessoal
Feedbackexterno
Atividades para formao
de times
Gerenciamento de
habilidades
Sistema de reconhecimento
e recompensa
Aproximao
Treinamentos
Produtos
Melhorias de performance
Dados para avaliao de
performance
FIGURA 34 - Viso geral dos processos de gerenciamento de recursos humanos
68
Recomenda-se a construo de uma matriz de designao de responsabilidades (conhecida como RAM), onde as fases
do projeto estaro relacionadas aos responsveis [PMIS96].
69
Usualmente so representados por um histograma de recursos que indique que quantidade de cada recurso est alocada
ao longo do tempo e das etapas do projeto [PMIS96].
104
A.6.2. Grupo de processos 9.2. Aquisio de pessoal

Consiste no conjunto de processos necessrios garantir que os recursos humanos
necessrios ao projeto foram designados e esto trabalhando (de fato) no projeto.
Normalmente o recurso mais adequado no est disponvel, cabendo equipe do projeto
cuidar para que os recursos alocados tenham os requisitos necessrios.
pessoal, a descrio do conjunto de pessoas, que correspondem descrio dos
potenciais recursos disponveis, incluindo experincia anterior, interesses pessoais de
participar do projeto, caractersticas particulares e disponibilidade de cada um dos
possveis recursos, alm das prticas de recrutamento, que consistem nas polticas, guias
e procedimentos existentes e envolvidos com o recrutamento; caso existam, passam a ser
restries para o processo de aquisio de pessoal.
As ferramentas e tcnicas disponveis so a negociao, no sentido de garantir que o
projeto receba os recursos adequados, incluindo negociao com equipes de outros projetos
quando da necessidade de um recurso comum, a pr-indicao, que consiste na pralocao de determinados recursos humanos para o projeto (por exemplo, se o projeto for
estratgico e envolva habilidades especificas encontradas em determinados recursos, j na
fase da proposta pode ocorrer a pr-indicao), alm da subcontratao, que consiste em
obter recursos humanos a partir de empresas prestadoras de servio, motivado por vrias
razes dentre as quais: falta de capacitao dos recursos internos, poltica da empresa,
atividade especfica e outras.
Como produtos esperados tem-se a designao de pessoal do projeto, que consiste na
alocao dos recursos humanos aos trabalhos a serem executados no projeto, podendo esta
alocao ser em tempo integral, em tempo parcial ou varivel de acordo com as
necessidades ao longo das etapas do projeto e o diretrio do time do projeto, que contm
todos os membros participantes do time do projeto e todos os demais stakeholders.
A.6.3. Grupo de processos 9.3. Desenvolver time
Consiste no conjunto de processos necessrios ao aperfeioamento das habilidades
individuais dos participantes e ao aprimoramento das habilidades de relacionamento
garantindo que o time atue realmente como um time, podendo ser favorecido (ou no)
dependendo da estrutura adotada pela organizao.
Dentre as entradas de dados destes processos tem-se o pessoal do projeto, que ilustra
quais so as habilidades individuais e as habilidades de trabalho em time, o plano do
projeto, que descreve o contexto tcnico sobre o qual o time do projeto dever operar, o
plano de gerenciamento de pessoal, os relatrios de progresso e o feedback externo
que consiste em avaliaes peridicas por parte de indivduos que no esto alocados ao
projeto em questo.
As ferramentas e tcnicas disponveis so as atividades para a formao de times, que
incluem aes gerenciais e individuais de forma a possibilitar ganhos no desempenho do
time, por exemplo, envolver o pessoal que no est no nvel gerencial no processo de
planejamento, reunies rpidas e peridicas com todos os componentes do time e outras
105
aes, o gerenciamento de habilidades tcnicas, administrativas e gerenciais do time 70 , o

sistema de reconhecimento e recompensa, que auxilia na deteco de bons exemplos que
indiquem postura que supere os requisitos planejados, a aproximao, que consiste em
colocar o maior nmero de pessoas (se possvel todas) do time do projeto em um mesmo
ambiente fsico de forma a aumentar a habilidade de trabalho em time, alm de
treinamentos, que incluem todas as atividades voltadas ao aprimoramento das habilidades,
conhecimentos e capacitao para o time do projeto, podendo ser formal ou informal
(conhecido como treinamento on the job); vale notar que se o volume de treinamento
necessrio for de um porte considervel, recomenda-se a utilizao da estratgia de se ter
atividades especficas para estes treinamentos relacionadas execuo do projeto.
Como produtos esperados tem-se as melhorias de performance, que identificam pontos
onde podem ser obtidas melhorias de performance no time, podendo ser melhorias
individuais, coletivas (por exemplo, formas para lidar com a resoluo de conflitos no
time) ou gerais (por exemplo, identificar forma mais eficientes de se realizar o projeto),
alm dos dados para avaliao de performance, a serem utilizados nas demais reas de
gerenciamento.
A.7. Gerenciamento das comunicaes

Uma viso geral dos processos de gerenciamento da comunicao pode ser obtida na
FIGURA 35 - Viso geral dos processos de gerenciamento da comunicao.
A.7.1. Grupo de processos 10.1. Planejar comunicao
Consiste no conjunto de processos necessrios determinao de quais so as necessidades
de informaes e comunicaes dos stakeholders: quem precisa de quais informaes,
quando eles precisam delas e como elas sero geradas para eles, sendo que atender a estes
requisitos consiste em importante fator de sucesso (ou insucesso) do projeto. Vale notar
que as necessidades de informaes podem variar ao longo do projeto, necessitando
portanto de constante reviso.
Dentre as entradas de dados destes processos tem-se os requisitos de comunicao, que
correspondem a todas as necessidades de informaes dos stakeholders, envolvendo o tipo
de informao e o formato no qual esta deve ser apresentada; a tecnologia de
comunicao, que corresponde s tcnicas e mtodos usados para transferir e coletar a
informao dentre os diversos elementos componentes do projeto, desde reunies at
conversas informais, incluindo anlise de fatores como freqncia de divulgao das
informaes, tecnologia disponvel, as expectativas (e familiaridades) dos envolvidos e o
tamanho do projeto; as restries, que so os fatores que limitam as opes do time do
projeto e focam em determinadas necessidades (por exemplo, maior nfase em fatores
contratuais caso o projeto seja executado em grande parte por empresas subcontratadas) e
as suposies, que so fatos considerados como verdadeiros durante a fase de
planejamento, normalmente envolvendo um certo grau de risco.
70
Para aprofundamento recomenda-se [AIPM95].
106
Gerenciamento
da Comunicao
em Projetos
10.1. Planejar
comunicaes
10.2. Distribuir informaes
Entradas
Requisitos de comunicao
Tecnologia de
comunicao
Restries
Suposies
Anlise dos stakeholders
Produtos
comunicaes
Entradas
Resultados dos trabalhos
comunicaes
Plano do projeto
Habilidade de comunicao
Sistemas de recuperao
de informaes
Sistemas de distribuio
de informaes
Produtos
Registros do projeto
10.3. Reportar desempenho
10.4. Encerrar projeto
Entradas
Plano do projeto
Resultados dos trabalhos
Outros registros do projeto
Revises de performance
Anlise de variaes
Anlise de tendncias
Anlise de earned value
Tcnicas e ferramentas de
distribuio de
informaes
Produtos
Relatrios de performance
Requisies de
modificaes
Entradas
Documentao referente s
medies de
performance
Documentao referente
aos produtos do projeto
Outros registros do projeto
Tcnicas e ferramentas de
reportar desempenho
Produtos
Arquivos do projeto
Aceitao formal
Lies aprendidas
FIGURA 35 - Viso geral dos processos de gerenciamento da comunicao
107
As ferramentas e tcnicas disponveis correspondem a anlise dos stakeholders, que

consiste em analisar as necessidades de informaes dos diversos stakeholders a fim de
garantir que estas sejam atendidas. importante verificar se no esto sendo geradas
informaes em demasia, desnecessrias, com tecnologia inadequada, consumindo tempo e
esforo dos recursos do projeto.
Como produto esperado tem-se o plano de gerenciamento de comunicaes, que
documenta os mtodos e procedimentos a serem utilizados para obter, divulgar e
armazenar as informaes, a estrutura de distribuio, quais os tipos de informaes
(relatrios de progresso, documentos tcnicos e outros), nvel de detalhe necessrio a cada
tipo de informao a ser gerada, freqncia de gerao e atualizao, alm dos mtodos de
acesso a estas informaes.
A.7.2. Grupo de processos 10.2. Distribuir informaes
Consiste no conjunto de processos necessrios garantia de que todos as informaes
necessrias estaro disponveis aos stakeholders do projeto no tempo adequado, incluindo
a implementao do plano de gerenciamento de comunicaes bem como os
procedimentos de resposta a requisies de informaes anteriormente no planejadas.
Dentre as entradas de dados destes processos tem-se os resultados dos trabalhos, o plano
de gerenciamento de comunicaes, e o plano do projeto.
As ferramentas e tcnicas disponveis correspondem a habilidade de comunicao, que
utilizada para trocar informaes, sendo que o porta voz da informao responsvel por
fazer com que a informao seja transmitida de forma clara, sem ambigidade, completa a
fim de que o receptor desta informao possa receb-la corretamente, passando este a ser
responsvel pelo correto entendimento e aplicabilidade da informao recebida, podendo a
informao ser transmitida de forma oral, escrita, formal, hierrquica, interna ou externa ao
projeto; os sistemas de recuperao de informaes, podendo ser planilhas de clculo,
software de planejamento, sistemas de gerenciamento de documentos, entre outros, alm
dos sistemas de distribuio de informaes, podendo ser reunies de projeto,
distribuio de relatrios, compartilhamento de rea comum onde as informaes possam
ser disponibilizadas, pgina na internet, e-mail, vdeo conferncia, entre outros.
Como produto esperado tem-se os registros do projeto, que envolvem as
correspondncias, os memorandos, os relatrios e os documentos descritos no projeto,
devendo serem garantidos o armazenamento, a segurana e os mecanismos de busca destes
registros quando necessrio.
A.7.3. Grupo de processos 10.3. Reportar desempenho
Consiste no conjunto de processos necessrios para coletar e disseminar as informaes de
desempenho do projeto a fim de prover os stakeholders com informaes acerca de como
os recursos esto sendo utilizados para que o projeto atinja seus objetivos, incluindo
relatrios de situao (como est o projeto), relatrios de progresso (o que j foi realizado e
o que ainda falta) e previses de como o projeto seguir. Podem ser relatrios detalhados
ou apenas apontando as excees frente ao planejamento original (facilitando o chamado
108
gerenciamento por exceo, onde a concentrao dos esforos gerenciais se d nos pontos
onde o projeto est com problemas).
Dentre as entradas de dados destes processos tem-se o plano do projeto, que contm as
informaes que servem de base para as informaes de desempenho, os resultados dos
trabalhos, que correspondem a quais produtos (deliverables) j foram total ou
parcialmente produzidos, quais custos j foram incorridos ou compromissados e outras
informaes relevantes sobre os trabalhos, alm de outros registros do projeto.
As ferramentas e tcnicas disponveis correspondem s revises de performance, que so
reunies feitas com o objetivo de verificar a situao e o progresso de um dado projeto,
sendo realizadas periodicamente; a anlise de variaes, que corresponde comparao
dos resultados do projeto com os resultados planejados/previstos para cada uma das reas
de gerenciamento de projetos; a anlise de tendncias, que consiste em avaliar o
progresso do projeto a fim de verificar se seu desempenho est progredindo ou
deteriorando frente ao planejado; a anlise de earned value, que consiste em uma medida
de desempenho do projeto envolvendo e integrando o desempenho das reas de
gerenciamento de escopo, custo e tempo, atravs do clculo de trs variveis: a) custo
estimado para o trabalho planejado (BCWS), que corresponde ao custo aprovado para a
execuo dos trabalhos, b) o custo atual do trabalho realizado (ACWP), que corresponde ao
total dos custos diretos e indiretos incorridos em um dado projeto em um dado perodo, e
c) custo estimado do trabalho executado (BCWP ), que o prprio earned value,
correspondente ao percentual do oramento total em relao ao percentual do trabalho j
realizado; a partir da combinao destas trs variveis possvel efetuar medidas no
projeto, a saber: a) variao de custo (CV = BCWP - ACWP), b) variao de tempo (SV =
BCWP - BCWS), c) ndice de desempenho de custo (CPI = BCWP/ACWP), usado para
projetar o custo quando da concluso do projeto, d) ndice de desempenho de tempo (SPI =
BCWP/BCWS), usado para projetar o tempo ainda necessrio para a concluso do projeto,
alm das tcnicas e ferramentas de distribuio de informaes.
Como produtos esperados tem-se os relatrios de performance, que organizam e
sumarizam as informaes coletadas e os resultados atuais do projeto em questo para
anlise dos stakeholders, incluindo normalmente grficos (Gantt71 ), histogramas e tabelas,
alm das requisies de modificaes, resultantes das anlise dos resultados, a fim de
garantir o bom andamento do projeto (ou sua correo).
A.7.4. Grupo de processos 10.4. Encerrar projeto
Consiste no conjunto de processos necessrios para verificar e documentar os resultados do
projeto a fim de formalizar a aceitao final do produto gerado pelo responsvel, cliente ou
consumidor, de forma a garantir o encerramento e concluso formal do projeto; inclui a
coleta dos registros do projeto, garantia de que o projeto realmente executou tudo aquilo
que estava planejado/especificado, anlise do sucesso do projeto e sua efetividade e o
arquivamento destas informaes para uso futuro. Vale notar que encerramentos
intermedirios, referente aos subprodutos do projeto, devem ser feitos a fim de facilitar o
encerramento final e evitar perda de informaes.
71
Os grficos de Gantt foram desenvolvidos por Henry Gantt, em parceria com Frederick Taylor, durante o
gerenciamento da construo de navios de guerra no perodo da 1 guerra mundial [SISK98].
109
Dentre as entradas de dados destes processos tem-se a documentao referente s

medies de performance, devendo estar disponvel para a execuo destes processos
toda a documentao produzida para registro e anlise do desempenho do projeto,
incluindo documentos utilizados quando do planejamento inicial para o estabelecimento de
um modelo para a medio de desempenho; a documentao referente aos produtos do
projeto, correspondente aos planos, especificaes, documentao tcnica, desenhos,
arquivos eletrnicos e outros gerados para os produtos a serem produzidos pelo projeto,
alm de outros registros do projeto, que devero estarem disponveis para a execuo dos
processos em questo.
As ferramentas e tcnicas disponveis correspondem s mesmas utilizadas para reportar
desempenho do projeto.
Como produtos esperados tem-se os arquivos do projeto, que consistem no conjunto
completo de todos os registros do projeto preparados para o arquivamento de forma
organizada, alm de garantir que as bases de informaes histricas e de medio foram
atualizadas com os dados do projeto em questo; a aceitao formal, que consiste em
documento formal indicando que os responsveis ou clientes aceitaram o projeto, devendo
ser distribudo a todos os stakeholders do projeto, alm das lies aprendidas.
A.8. Gerenciamento do risco
Uma viso geral dos processos de gerenciamento do risco pode ser obtida na FIGURA 36 Viso geral dos processos de gerenciamento do risco.
A.8.1. Grupo de processos 11.1. Identificar risco
Consiste no conjunto de processos necessrios determinao de quais so os riscos que
podem afetar o projeto e documentao de cada um destes riscos, sendo que so
processos que devem ser ativados freqentemente ao longo do projeto. Os riscos podem ser
internos ao projeto (provocados por eventos que podem ser controlados ou influenciados
pelo time do projeto, como por exemplo substituio de recursos internos) ou externos
(esto fora de controle ou de influncia do time do projeto, como por exemplo aes
governamentais)72 .
Dentre as entradas de dados destes processos tem-se a descrio dos produtos, uma vez
que a natureza dos produtos tem grande impacto na identificao dos riscos j que projetos
que envolvam utilizao de tecnologias consolidadas certamente tero menor risco que
projetos que utilizem tecnologias inovadoras e no adequadamente experimentadas; as
outras sadas de planejamento, geradas em outras reas de gerenciamento tais como
WBS, durao das atividades e estimativas de custo (uma vez que caso no tenham sido
consideradas "folgas" o risco associado certamente ser maior), planejamento de
contrataes e planejamento de recursos humanos (onde por exemplo a exigncia de
requisitos que apenas um dos componentes do time possui certamente representa um risco
72
Vale ressaltar que riscos no envolvem apenas aspectos negativos: podem indicar oportunidades de negcio
[SABA99].
110
em potencial) e as informaes histricas, que correspondem aos registros de como

projetos anteriores enfrentaram a questo do riscos (previstos ou no).
As ferramentas e tcnicas disponveis correspondem a checklists, que consistem em
relaes de itens a serem verificados por fonte de risco, podendo serem oriundas do
contexto do projeto, razes tecnolgicas, qualificao de profissionais internos, fatores
polticos e outros; os fluxogramas, que podem auxiliar ao time do projeto a entender
melhor as causas e efeitos dos riscos e as entrevistas orientadas a identificao de riscos,
que podem (e devem) ser realizadas com diversos stakeholders do projeto, alm da reviso
de todas as entrevistas feitas anteriormente visando identificar riscos j alertados.
Como produtos esperados tem-se as fontes de risco, que so as categorias de possveis
eventos de risco que podem afetar o projeto, tanto negativa quanto positivamente, devendo
serem detalhadas contemplando informaes referentes a probabilidade de ocorrncia e
dimenso do ganho ou perda associada 73 ; os eventos potenciais de risco, que
correspondem s ocorrncias, tais como desastres da natureza, que podem afetar o projeto,
devendo ser identificados de maneira adicional s fontes de risco anteriormente
identificadas, incluindo a probabilidade de que este risco venha a ocorrer, possveis
alternativas, tempo esperado para o evento, alm da freqncia de ocorrncia deste evento
(j que alguns eventos podem ocorrer mais que uma vez no projeto), os sintomas de risco,
que correspondem a manifestaes indiretas de eventos de risco, auxiliando na tomada de
medidas de ajuste caso seja necessrio, alm de entradas para os demais processos de
gerenciamento, podendo sinalizar a necessidade de incluso de preocupaes adicionais
nas demais reas de gerenciamento a fim de minimizar (ou maximizar, dependendo do
caso) os efeitos dos riscos identificados.
A.8.2. Grupo de processos 11.2. Quantificar riscos
Consiste no conjunto de processos necessrios quantificao e avaliao dos riscos do
projeto, determinando quais so os eventos de risco que necessitam de resposta. Este
processo dificultado em funo de alguns fatores como, por exemplo, oportunidades para
um determinado stakeholder podem significar penalidades para outros, uso de tcnicas
matemticas que podem gerar a falsa impresso de preciso e confiabilidade total, alm de
eventos recorrentes de risco.
Dentre as entradas de dados destes processos tem-se a tolerncia dos stakeholders aos
riscos, que normalmente so diferente (e muitas vezes contraditrias), dependendo de
vrios fatores (como por exemplo, porte), as fontes de risco, os eventos potenciais de
risco, as estimativas de custo e as estimativas de durao de atividades.
As ferramentas e tcnicas disponveis correspondem a expectativa de valor monetrio,
que resultado de dois nmeros: a probabilidade de um dado evento ocorrer e o valor do
ganho ou da perda caso o evento ocorra; as somas estatsticas, que podem ser utilizadas
para calcular os custos associadas aos eventos de risco, bem como as relaes entre estes
custos e os custos j considerados para o projeto; as simulaes, que so utilizadas para
representar um modelo ou um sistema para analisar a natureza ou a performance do
73
Algumas fontes de risco: mudanas nos requisitos do projeto, erros de desenho, omisses, itens no compreendidos, m
definio de regras e responsabilidades, estimativas pobres e falta de detalhes das caractersticas necessrias aos
profissionais do time do projeto [GASP98a].
111
projeto 74 ; as rvores de deciso, que correspondem s relaes entre as possveis decises

e a anlise de seus impactos, com as probabilidades, custos e outros fatores envolvidos,
alm do julgamento de especialistas.
Como produtos esperados tem-se as oportunidades a perseguir e ameaas a responder,
alm das oportunidades a ignorar e ameaas a aceitar, contemplando tambm o
responsvel pela deciso.
A.8.3. Grupo de processos 11.3. Desenvolver resposta aos riscos
Consiste no conjunto de processos necessrios para definio de melhorias para as
oportunidades e repostas para os problemas, que podem ser: a) evitar, que consiste em
eliminar as causas, b) minimizar, que consiste em reduzir o impacto (normalmente
monetrio) do evento de risco reduzindo a probabilidade de sua ocorrncia, c) aceitar, que
consiste em aceitar as conseqncias, podendo ser ativa (elaborao de um plano de
contingncia) ou passiva (aceitando reduo de lucro em algumas atividades afetadas).
Dentre as entradas de dados destes processos tem-se as oportunidades a perseguir e
ameaas a responder, alm das oportunidades a ignorar e ameaas a aceitar, geradas
nos processos anteriores.
As ferramentas e tcnicas disponveis correspondem contratao, que consiste em
contratar servios a fim de eliminar certos tipos de riscos, em especial aqueles que esto
associados ao uso de tecnologias especficas no dominadas pela organizao executante
do projeto (ainda que muitas vezes possa introduzir novos riscos como a certeza - ou no de que o fornecedor cumprir o contrato); o planejamento de contingncias, que consiste
na definio de aes a serem tomadas para o caso de ocorrerem os eventos de risco
identificados; as estratgias alternativas, que correspondem a alternativas que podem ser
adotadas, modificando a forma de abordagem inicialmente acordada, a fim de prevenir ou
eliminar alguns eventos de risco, alm de seguros, que correspondem contratao de
seguros para alguns eventos de risco, sendo necessria a avaliao de diversos aspectos
(custo, freqncia, probabilidade) envolvidos com estes eventos de risco.
Como produtos esperados tem-se o plano de gerenciamento de riscos, que documenta os
procedimentos a serem utilizados para o gerenciamento dos riscos ao longo do projeto,
definindo quem responsvel por este gerenciamento, como os eventos de risco
identificados e quantificados sero atualizados, como os planos de contingncia sero
implementados e como as reservas sero alocadas; as entradas para os demais processos
de gerenciamento; o plano de contingncia; as reservas75 , que correspondem a provises
a serem includas no plano do projeto a fim de minimizar os riscos de custo e de tempo do
projeto, alm dos acordos contratuais, que podem ser feitos na forma de seguros, servios
externos e outros a fim de minimizar os impactos, correspondendo a importante
instrumento para o gerenciamento efetivo dos riscos.
74
Diversas tcnicas podem ser utilizadas para estas anlises; as mais comuns esto relacionadas s redes de precedncia
(cronogramas) e tcnicas associadas a estas (por exemplo, a anlise de Monte Carlo). Ferramentas tais como MSProject (recomenda-se leitura de [CREP98]), Primavera Project Plan, Risk@Master e @Risc vm sendo utilizadas com
esta finalidade.
75
Tambm conhecidas como reservas gerenciais, reservas de contingncia ou reserva de planejamento.
112
Gerenciamento
do Risco em
Projetos
11.1. Identificar riscos
11.2. Quantificar riscos
Entradas
Descrio dos produtos
Outras sadas de
planejamento
Informaes histricas
Checklists
Fluxogramas
Entrevistas
Produtos
Fontes de risco
Eventos potenciais de risco
Sintomas de risco
Entradas para demaisos
processos
Entradas
Tolerncia dosstakeholders
aos riscos
Fontes de risco
Eventos potenciais de risco
Estimativas de durao de
atividades
Expectativa de valor
monetrio
Somas estatsticas
Simulaes
rvores de deciso
Julgamento de especialistas
Produtos
Oportunidades a perseguir,
ameaas a responder
Oportunidades a ignorar,
ameaas a aceitar
11.3. Desenvolver resposta

aos riscos
10.4. Controlar resposta aos

riscos
Entradas
Oportunidades a perseguir,
ameaas a responder
Oportunidades a ignorar,
ameaas a aceitar
Contratao
Planejamento de
contingncias
Estratgias alternativas
Seguros
Produtos
riscos
Entradas para os demais
processos
Plano de contingncia
Reservas
Acordos contratuais
Entradas
riscos
Eventos de risco ainda
presentes
Identificao adicional de
riscos
Trabalhos em paralelo
Desenvolvimento de resposta
adicional de riscos
Produtos
Aes corretivas
Atualizaes no plano de
gerenciamento de riscos
FIGURA 36 - Viso geral dos processos de gerenciamento do risco
113
A.8.4. Grupo de processos 11.4. Controlar resposta aos riscos

Consiste no conjunto de processos necessrios para garantir a execuo do plano de
gerenciamento de riscos a fim de responder adequadamente aos eventos de risco ao longo
do projeto; vale ressaltar que caso ocorram mudanas, o ciclo bsico de identificao,
quantificao e resposta aos riscos repetido, sendo que manter este ciclo funo deste
controle.
Dentre as entradas de dados destes processos tem-se o plano de gerenciamento de riscos,
os eventos de risco ainda presentes, alm de identificao adicional de riscos, que
podem ser identificados agora aps maior conhecimento dos fatores de risco.
As ferramentas e tcnicas disponveis correspondem aos trabalhos em paralelo, que so
respostas no planejadas em resposta a eventos negativos de risco, alm do
desenvolvimento de resposta adicional de riscos, necessrio quando os eventos de risco
no foram antecipados ou os efeitos so maiores que o esperado.
Como produtos esperados tem-se as aes corretivas, que consistem primariamente em
executar aquilo que foi planejado como resposta ao riscos, alm de atualizaes no plano
de gerenciamento de riscos 76 .
A.9. Gerenciamento de suprimentos

Uma viso geral dos processos de gerenciamento de suprimentos pode ser obtida no
FIGURA 37 - Viso geral dos processos de gerenciamento de suprimentos.
A.9.1. Grupo de processos 12.1. Planejar suprimentos
Consiste no conjunto de processos necessrios identificao de quais necessidades do
projeto podem ser melhor atendidas atravs de bens e servios produzidos por empresas
externas organizao, envolvendo os aspectos de como contratar, o que contratar, quanto
contratar e quando contratar. Caso seja optado pela contratao, um contrato deve ser
elaborado para o item a ser produzido e este contrato deve ser adequadamente gerenciado
at seu encerramento. Caso o projeto no venha a executar contrataes externas, os
demais processos deste grupo no sero ativados. 77
Dentre as entradas de dados destes processos tem-se a declarao do escopo, a descrio
do produto, os recursos de suprimentos, que identificam os recursos necessrios para o
gerenciamento dos contratos com fornecedores, as condies de mercado, que
correspondem aos produtos disponveis no mercado, com que fornecedores, em que termos
e condies, os outros produtos de planejamento gerados nas demais reas de
76
Para aprofundamento no tema gerenciamento de riscos recomenda-se [SCHN98], [KRAU99] e [SPEC99].
77
Um projeto pode optar por executar todas as atividades internamente em funo principalmente de porte (pequenos
projetos) ou grau de confidencialidade elevado.
114
gerenciamento (por exemplo, fluxo de caixa, WBS entre outros), as restries e as

suposies.
Gerenciamento
de Suprimentos em
Projeto
12.1. Planejar suprimentos
12.2. Planejar cotaes
12.3. Solicitaes
Entradas
Declarao do escopo
Descrio do produto
Recursos de suprimentos
Condies de mercado
Outros produtos de
planejamento
Restries
Suposies
Anlise fazer ou comprar
Seleo de tipos de
contratos
Produtos
suprimentos
Descrio do trabalho
Entradas
suprimentos
Declarao do escopo
Descrio do trabalho
Outros produtos de
planejamento
Formulrios padres
Produtos
Documentao de
contratao
Critrios de aceitao
Atualizao das descries
do trabalho
Entradas
Documentao de
contratao
Lista de fornecedores
qualificados
Conferncias com
fornecedores
Anncios
Produtos
Propostas
12.4. Selecionar
fornecedores
12.5. Administrar contratos
12.6. Encerrar contratos
Entradas
Propostas
Critrios de aceitao
Polticas da organizao
Negociaes contratuais
Sistemas de comparao
Sistemas de seleo
Estimativas independentes
Produtos
Contrato
Entradas
Contrato
Solicitaes de mudanas
Pedidos dos fornecedores
mudanas de contratos
Sistema de pagamento
Produtos
Correspondncias
Modificaes contratuais
Requisies de pagamento
Entradas
Documentao do contrato
Auditoria de contrataes
Produtos
Arquivo de contrato
Aceitao e encerramento
formal
FIGURA 37 - Viso geral dos processos de gerenciamento de suprimentos
115
As ferramentas e tcnicas disponveis correspondem a anlise "fazer ou comprar", que

consiste em analisar a relao de custos diretos e indiretos referentes a produo com
recursos prprios ou a contratao a partir de fornecedores, envolvendo tambm a
possibilidade de aluguel; o apoio de especialistas e a seleo de tipos de contratos, que
corresponde a verificar os tipos mais apropriados de contrato para cada necessidade. 78
Como produtos esperados tem-se o plano de gerenciamento de suprimentos, que
nortear as demais etapas do gerenciamento de suprimentos e a descrio do trabalho,
que descreve os itens a serem contratados em um nvel de detalhe adequado, tanto para a
empresa contratante quanto para a empresa a ser futuramente contratada.
A.9.2. Grupo de processos 12.2. Planejar cotaes
Consiste no conjunto de processos necessrios preparao da documentao adequada
para suportar os processos de cotao/solicitao junto s empresas fornecedoras.
suprimentos, a declarao do escopo, a descrio do trabalho a ser executado e outros
produtos de planejamento, que devem ser revistos e atualizados em funo das
atividades/produtos que forem contratados externamente.
As ferramentas e tcnicas disponveis correspondem aos formulrios padres (contratos,
padres de itens a serem contratados, clusulas jurdicas e outros, cujo objetivo facilitar o
processo de contratao), alm do apoio de especialistas.
Como produtos esperados tem-se a documentao de contratao, que ser utilizada a
fim de solicitar as propostas aos fornecedores, os critrios de aceitao e avaliao, que
sero utilizados para classificar as propostas recebidas dos fornecedores, contendo critrios
objetivos (tais como exigncias e obrigatoriedades) e subjetivos, alm da atualizao das
descries do trabalho, decorrentes das anlises para as solicitaes.
A.9.3. Grupo de processos 12.3. Solicitaes
Consiste no conjunto de processos envolvidos com a obteno das informaes a partir dos
fornecedores potenciais de como as necessidades do projeto podem ser atendidas.
Normalmente a maior parte dos esforos deste grupo de processos est a cargo dos
fornecedores, via de regra sem custo para o projeto [PMIS96].
Dentre as entradas de dados destes processos tem-se a documentao de contratao, a
lista de fornecedores qualificados, a ser organizada pelo time do projeto a partir de
experincias passadas, catlogos, consultores, visitas tcnicas e outras fontes.
As ferramentas e tcnicas disponveis correspondem as conferncias com fornecedores,
que so as reunies preliminares com os fornecedores a fim de preparar a proposta,
78
Normalmente estes contratos pertencem a uma das trs categorias: contrato a preo fechado (para produtos bem
definidos, com preo fixo para sua produo), contrato por reembolso (para produtos experimentais ou no bem
definidos, com reembolso das despesas efetuadas) e contrato por unidades (onde so estipuladas tarifas de uso e o
custo dado pela quantidade alocada x tarifa praticada).
116
garantindo o correto entendimento das necessidades do projeto, alm dos anncios, que
consistem em aumentar o leque de fornecedores atravs de anncios em mdia
especializada contendo as necessidades de contratao. 79
Como produto esperado tem-se as propostas, que correspondem aos documentos
encaminhados pelo fornecedor a fim de demonstrar interesse, capacidade e competncia
para executar os trabalhos solicitados, envolvendo aspectos tcnicos e financeiros.
A.9.4. Grupo de processos 12.4. Selecionar fornecedores
Consiste no conjunto de processos envolvidos com a recepo das propostas e a aplicao
dos critrios de classificao dos fornecedores. Os critrios a serem aplicados nesta
classificao/seleo das propostas normalmente correspondem primeiramente a aspectos
financeiros (custo), seguidos por aspectos tcnicos (capacidade) e complexidade.
Dentre as entradas de dados destes processos tem-se as propostas, os critrios de
aceitao e as polticas da organizao que podem afetar a avaliao das propostas e dos
fornecedores.
As ferramentas e tcnicas disponveis correspondem as negociaes contratuais, que so
comuns antes da assinatura definitiva do contrato, envolvendo detalhamento de
caractersticas tcnicas, determinao de responsabilidades e penalidades, aspectos
financeiros e outros 80 ; os sistemas de comparao e medidas, que correspondem a
mtodos para quantificar dados qualitativos a fim de garantir uma classificao adequada
de todas as propostas81 ; os sistemas de seleo, que estabelecem os requisitos mnimos de
desempenho para um ou mais critrios de avaliao das propostas, servindo como filtro
para restringir e eliminar algumas das propostas recebidas, alm das estimativas
independentes, que correspondem a estimativas feitas pela prpria organizao ou por
outras instituies a fim de serem utilizadas como parmetros dos processos posteriores de
validao das propostas.
Como produto esperado tem-se o contrato, que corresponde a um acordo que obriga o
fornecedor a prover um especificado produto e o comprador a efetuar pagamentos
referentes a este produto.
A.9.5. Grupo de processos 12.5. Administrar contratos
Consiste no conjunto de processos evolvidos com a garantia de que o desempenho do
fornecedor contratado est de acordo com os requisitos contratuais. Envolve aspectos
referentes a prazo, custo, desempenho tcnico, qualidade e controle de modificaes 82 .
79
Vale ressaltar que em alguns casos, como contratos governamentais, isto obrigatrio [PMIS96].
80
Existe vasta literatura sobre negociao que pode (e deve) ser utilizada para contemplar este grupo de processos. Boas
referncias podem ser encontradas em [OCON94], [KELL95] e [GOLD92], dentre outras.
81
Normalmente atribuindo pesos a determinadas caractersticas e multiplicando pelas notas de cada item das proposta, de
forma a ter, ao final do processo, uma nota associada a cada proposta (equivalente ponderao anteriormente
aplicada) [PMIS96].
82
Em outras palavras, corresponde aproximadamente ao gerenciamento descrito pelo PMBoK porm aplicado a um
contrato com fornecedor.
117
Dentre as entradas de dados destes processos tem-se o contrato, os resultados do

trabalho, que correspondem especialmente aos deliverables que foram completamente
produzidos, aqueles que ainda no foram, qual o nvel de qualidade atingido pelo contrato,
quais os custos incorridos ou compromissados, as solicitaes de mudanas, que
envolvem desde pleitos de modificaes contratuais at casos extremos de rompimentos
(por exemplo, por insuficincia tcnica do fornecedor), alm dos pedidos dos
fornecedores, que correspondem s solicitaes de pagamentos feitas pelo fornecedor
referente aos trabalhos por ele executados.
As ferramentas e tcnicas disponveis correspondem ao sistema de controle de mudanas
de contratos, que define as regras para acompanhamento das modificaes, rastreabilidade
dos impactos, aprovaes necessrias e outros aspectos relacionados 83 , os relatrios de
progresso, que indicam o desempenho dos fornecedores nos aspectos contratuais, alm do
sistema de pagamento, que consiste no processo envolvendo a aceitao dos produtos e a
posterior liberao dos pagamentos referentes a estes produtos.
Como produtos esperados tem-se as correspondncias, que corresponde s comunicaes
necessrias com os fornecedores a fim de garantir o bom andamento do contrato, as
modificaes contratuais, que correspondem as modificaes, aprovadas ou no, que
serviro para futuras negociaes e planejamentos de contrataes, alm de requisies de
pagamento, que correspondem aos pedidos de pagamento feitos pelo fornecedor e aceitos
pelo time do projeto, estando prontos para serem efetivamente pagos pela organizao
contratante.
A.9.6. Grupo de processos 12.6. Encerrar contratos
Consiste no conjunto de processos envolvidos com a garantia de que todo trabalho previsto
pelo contrato foi realmente realizado e em conformidade com a especificao, alm de
preocupaes com arquivamento e outros aspectos de encerramento. Um caso especial de
encerramento de contrato consiste em rompimento contratual, quer seja por solicitao do
fornecedor quer seja por solicitao do time do projeto.
Dentre as entradas de dados destes processos tem-se a documentao do contrato, que
consiste em todos os documentos produzidos anteriormente, durante e como decorrncia
do contrato em questo.
As ferramentas e tcnicas disponveis correspondem a auditoria de contrataes, que
consiste em uma reviso formal de todas as etapas do processo de contratao a fim de
identificar sucessos ou problemas que serviro de base para futuros processos de
contratao.
Como produtos esperados tem-se o arquivo de contrato e a aceitao e encerramento
formal do contrato, que consiste em dar cincia a todos os envolvidos, de forma formal,
de que o contrato foi concludo e no existem pendncias.
83
Existem softwares no mercado que executam estas e outras funes relativas administrao de contratos; um bom
exemplo a ferramenta Expedition, da Primavera (http://www.primavera.com).
118
Referncias Bibliogrficas
REFERNCIAS BIBLIOGRFICAS
[AMBL98] AMBLER, Scott W. Maturing the OO Software Process - reducing risks and
aumenting quality. Object Magazine - Fevereiro 1998.
[AMBL99] AMBLER, Scott W. UML Deployment Modeling and Beyound. Software
Development Magazine - Abril 1999.
[AIPM95] AIPM. National Competency Standards for Project Management . Vol. 1 a 4.
Australian Insitute of Project Management. Dezembro 1995.
[AYER99] AYER, Frederick L. & William R. Duncan. Project Manager Competence and
Competencies. Disponvel em http://www.pmpartners.com, 1999.
[BARR97] BARRETO JUNIOR, Jos. Qualidade de Software. Disponvel em
http://www.barreto.com.br/qualidade.
[BELL97] BELLOQUIM, tila. "Gerenciamento de projetos". Artigo apresentado no 1st .
Project Management Conference - SUCESU/SP, Julho 1997.
[BERG99] BERG, Cynthia A. & William R. Duncan. Updating "A Guide to the Project
Management Body of Knowledge". Disponvel em http://www.pmpartners.com,
1999.
[BLAN86] BLANCHARD, Kenneth, Patricia Zigarmi e Drea Zigarmi. Liderana e o
gerente minuto. Rio de Janeiro, Editora Record, 1986.
[BROO95] BROOKS, Frederick P., Jr. The mythical man-month: essays on software
engineering. Addison Wesley Longman, Inc. 1995.
[CABA98] CABANIS, Jeannette. What's Out There ... and What Could Be - The 1998
Project Management Software Survey. PM Network - Agosto 1998.
[CAJA99] CAJADO, Eduardo A. Gerncia de Projetos: Conceitos, Objetivos e Softwares
de Apoio. Developers Magazine, Setembro 1999.
[CASA99] CASAROTTO FILHO, Nelson. Gerncia de Projetos/engenharia simultnea.
So Paulo, Editora Atlas, 1999.
[CMU95] CMU - Carnegie Mellon University & SEI - Software Engineering Institute. The
Capability maturity model: Guidelines for improving the software process (SEI
Series in Software Engineering). Addison Wesley Longman, 1995.
[COMB99] COMBE, Marge & William R. Duncan. Standards Committee Tackles Project
Management Maturity Models. Disponvel em hppt://www.pmpartners.com, 1999.
[CONN99] CONNELL, Charles. Improve your company's ability to estimate softwaredevelopment cycles. Datamation, Abril 1999.
[COST99] COSTA, Geraldo M. & Joo Paulo Barbosa de Miranda. Implantando Processos
de Desenvolvimento de Software. Developers Magazine, Setembro 1999.
[CRED99] CREDICARD S/A. "Utilizando o CMM para melhoria do processo de
software". Artigo apresentado no 3rd. Project Management Conference SUCESU/SP, Dezembro 1999.
Referncias Bibliogrficas 119
[CREP98] CREPEAU, Neicole M. Risk Assessment and Management. Disponvel em

http://officeupdate.microsoft.com/2000/articles/ProjRiskAnalysis.htm, 1998.
[DAVE98] DAVENPORT, T.H. et al. Successful Knowledge Management Projects. Sloan
Management Review, 1988.
[DEMA89] DE MARCO, Tom. Controle de projetos de software: gerenciamento,
avaliao, estimativa. Rio de Janeiro, Editora Campus, 1989.
[DEVE94] DEVELIN, Nick. Gerenciamento de Custo Baseado em Atividades. So Paulo,
IMAM, 1994.
[DIAS99] DIAS, Fernando Rodrigues Teixeira. Sistemas Corporativos de Informao
para o Gerenciamento de Projetos: Um Estudo Exploratrio . Dissertao de
mestrado, Universidade de So Paulo, Faculdade de Economia, Administrao e
Contabilidade, Departamento de Administrao, So Paulo, 1999
[DINS92] DINSMORE, Paul Campbell. Gerncia de Projetos: Princpios e Tcnicas
Aplicadas Administrao Geral: Roteiro para Empresrios e Executivos. BTC Suma Econmica, 1992.
[DINS97] DINSMORE, Paul Campbell. "MOBP - Managing Organizations By Projects The Cutting Edge Of Management". Artigo apresentado no 1st . Project Management
Conference - SUCESU/SP, Julho 1997.
[DINS98] DINSMORE, Paul Campbell. "Managing the Project of Your Life". Disponvel
em http://www.dinsmore.com.br/manag.htm, 1998.
[DINS99] DINSMORE, Paul Campbell. "Winning in Business with Enterprise Project
Management". New York, American Management Association, 1999.
[DUNC99] DUNCAN, William R. ISO 10006: Risky Businness. Disponvel em
http://www.pmpartners.com/resources/iso10006.html, 1999.
[ESI97] ESI. System Integration Project Management - Course Material. ESI & The
George Washington University, julho 1997.
[FABI99] FABIAN-ISAACS, Constance & Ed. Robinson. The Project Management
Puzzle. Software Development Magazine, Maro 1999.
[FERN92] FERNANDES, Aguinaldo Aragon e Murilo Maia Alves. Gerncia Estratgica
da Tecnologia da Informao. Rio de Janeiro, LTC Livros Tcnicos e Cientficos
Ltda, 1992.
[FIOR98] FIORINI, Soeli T e outros. Engenharia de software com CMM. Rio de Janeiro,
Brasport, 1998.
[FOX98] FOX, Terry L. e SPENCE, J. Wayne. Tools of the Trade: A Survey of Project
Management Tools. Project Management Journal, Setembro 1998.
[FURL98] FURLAN, Jos Davi. Modelagem de Objetos atravs da UML. So Paulo,
Makron Books, 1998.
[GANE84] GANE, Chris & Trish Gorson. Anlise Estruturada de Sistemas. Rio de
Janeiro, LTC Livros Tcnicos e Cientficos Ltda., 1984.
[GASP98a] GASPARINI, Gustavo Demtrio. Metodologias para identificao e
quantificao de riscos. Frum Promon de gerenciamento de empreendimentos,
Outubro 1999.
120
[GASP98b] GASPARINI, Gustavo Demtrio. Implementando Anlise de Earned Value de

forma simples e eficiente. Frum Promon de gerenciamento de empreendimentos,
Novembro 1999.
[GASP98c] GASPARINI, Gustavo Demtrio. WBS e a Estruturao dos Work Packages.
Frum Promon de gerenciamento de empreendimentos, Dezembro 1999.
[GIL94] GIL, Antnio de Loureiro. Auditoria de qualidade. So Paulo, Atlas, 1994.
[GOLD92] GOLDRATT, Eliyahu M. e Jeff Cox. A Meta: um processo de aprimoramento
contnuo. So Paulo, Educator Editora e IMAM, 1992.
[HALL97] HALLOWS, Jolyon. The politics of projects - IT project management is more
about people than technology. Datamation, Novembro 1997.
[HAYE99] HAYES, Linda. To win at software development, change the game. Software
Development, Julho 1999.
[HEUS99] HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre, Editora
Sagre Luzzatto, 1999.
[HUMP95] HUMPHREY, Watts S. A Discipline for Software Engineering (SEI Series in
Software Engineering). Addison Wesley Publishing Company, 1995.
[HUMP96] HUMPHREY, Watts S. Introduction to the Personal Software Process (SEI
Series in Software Engineering). Addison Wesley Publishing Company, 1996.
[IREL91] IRELAND, Lewis R. Quality management in projects and programs. Project
Management Institute, 1991.
[ISO93] ISO - International Organization for Standardization. ISO/IEC 9126:1991
Information technology -- Software product evaluation -- Quality characteristics and
guidelines for their use. Genebra, ISO, 1993.
[ISO94] ISO - International Organization for Standardization. ISO 9000-1 - Quality
management and quality assurence standards - Part 1: Guidelines for selection and
use. Genebra, ISO, 1994.
[ISO95a] ISO - International Organization for Standardization. ISO 10005 - Quality
management - Guidelines for quality plans. Genebra, ISO, 1995.
[ISO95b] ISO - International Organization for Standardization. ISO 12207 - Information
technology -- Software life cycle processes. Genebra, ISO, 1995.
[ISO97a] ISO - International Organization for Standardization. ISO 10006 - Quality
management - Guidelines to quality in project management. Genebra, ISO, 1997.
[ISO97b] ISO - International Organization for Standardization. ISO 9000-3 - Quality
management and quality assurance standards -- Part 3: Guidelines for the
application of ISO 9001:1994 to the development, supply, installation and
maintenance of computer software. Genebra, ISO, 1997.
[ISO98a] ISO - International Organization for Standardization. ISO 15271 - Information
technology -- Guide for ISO/IEC 12207 (Software Life Cycle Processes). Genebra,
ISO, 1998.
[ISO98b] ISO - International Organization for Standardization. ISO 15504 Information
technology -- Software process assessment -- Part 1: Concepts and introductory
guide; Part 2: A reference model for processes and process capability; Part 3:
Performing an assessment; Part 4: Guide to performing assessments; Part 5: An
assessment model and indicator guidance (atualizada em 1999); Part 6: Guide to

competency of assessors; Part 7: Guide for use in process improvement; Part 8:
Guide for use in determining supplier process capability; Part 9: Vocabulary.
Genebra, ISO, 1998.
[ISO99a] ISO - International Organization for Standardization. Introdution to ISO.
Disponvel em http://www.iso.ch.
[ISO99b] ISO - International Organization for Standardization. ISO 16326 - Software
engineering -- Guide for the application of ISO/IEC 12207 to project management.
Genebra, ISO, 1999.
[ISSI98] ISSIG. Information Systems Extension Project for PMBoK Guide - (version 2
Agosto 1998). Disponvel em http://www.nauticom.net/www/eaa.
[JACO98a] JACOBSON, Ivar. Objectory is the Unified Process. Object Magazine, Abril
1998.
[JACO98b] JACOBSON, Ivar & Others. Object-Oriented Software Engineering. AddisonWesley, 1998.
[JAME97] JAMES, Geoffrey. IT fiascoes... and how to avoid them. Datamation,
Novembro 1997.
[JONE91] JONES, Capers. Produtividade no desenvolvimento de software. So Paulo,
Makron Books, 1991.
[KELL95] KELLY, Francis J. & Heather Mayfield Kelly. O que realmente se ensina na
Escola de Administrao de Harvard. Rio de Janeiro, Editora Record, 1995.
[KING98] KING, Nelson H. Project Management - According to Plan - The latest project
management programs can transform the daunting into the doable. PC Magazine,
Junho 1998.
[KORT99] KORTH, Henry F. & Abraham Silberschatz. Sistemas de Bancos de Dados 3
edio. So Paulo, Makron Books, 1999.
[KRAU99] KRAUSE, Walther. Gerenciamento de Risco: Garantindo o sucesso da TI.
Developers Magazine, Setembro 1999.
[KUGL90] KUGLER, Jos Luiz Carlos. Gerncia de projetos de sistemas. Rio de Janeiro,
LTC Livros Tcnicos e Cientficos Ltda, 1990.
[LAUN99] LAUNI, Joe. Create a Project Plan. Software Development, Maio 1999.
[MAFF92] MAFFEO, Bruno. Engenharia de Software e Especificao de Sistemas. Rio de
Janeiro, Editora Campus, 1992.
[MANG99] MANGAL, Sheridan F. Defining the Capability Project & The Applicable
Development Lifecycle. Disponvel em http://www.pmi-is.org, 1999.
[MART91] MARTIN, James e Carma McClure. Tcnicas Estruturadas e Case. So Paulo,
Makron McGraw-Hill, 1991.
[MART95] MARTIN, James e James J. Odell. Anlise e projeto orientados a objeto. So
Paulo, Makron McGraw-Hill, 1995.
[MART98] MARTIN, Paula K. & Karen Tate. Three Secrets for Creating Successful
Projects. The Journal of Quality & Participation, Novembro/Dezembro 1998.
122
[MART99] MARTIN, Paula K. & Karen Tate. How much planning is enough? PM
Network magazine, Fevereiro 1999.
[MELL99a] MELLO FILHO, Moacyr Cardoso de. O CMM Como um Guia na Evoluo
dos Processos. Developers Magazine, Setembro 1999.
[MELL99b] MELLO FILHO, Moacyr Cardoso de. Planejamento de Projeto em Processo
Interativo e Incremental. Developers Magazine, Setembro 1999.
[MICR95] Microsoft Pres. The Windows interface guidelines for software design.
Redmond, Washington, Microsoft Corporation, 1995.
[MOOR98] MOORE, James W. "Demystifying Software Engineering Standards". Artigo
apresentado na Conferncia Anual da IFPUG de 1998, Agosto 1998.
[NOLA77] NOLAN, R.L. Management Accounting and Control of Data Processing. Nova
York, National Association os Accountants, 1977.
[OCON94] OCONNELL, Fergus. How to run Successful Projects - the silver bullet.
Londres, Prentice-Hall, 1994.
[PAGE88] PAGE-JONES, Meilir. Projeto estruturado de sistemas. So Paulo, McGrawHill, 1988.
[PAGE90] PAGE-JONES, Meilir. Gerenciamento de projetos: guia prtico para
restaurao da qualidade em projetos e sistemas de processamento de dados. So
Paulo, McGraw-Hill, 1990.
[PAUL93] PAULK, Mark C. & others. Capability Maturity Model for Software, Version
1.1 Technical Report CMU/SEI-93-TR-024, 1993.
[PAUL94] PAULK, Mark C. & others. A Comparison of ISO 9001 and the Capability
Maturity Model for Software. Technical Report CMU/SEI-94-TR-12, 1994.
[PESS97] PESSOA, Marcelo Schneck de Paula. "Uma comparao entre os modelos ISO
9000 e CMM aplicados ao software". Artigo apresentado no 1st . Project Management
[PILL97] PILLAI, Krishnakumar &V. S. Sukumaram Nair. A Model for Software
Development Effort and Cost Estimation. IEEE Transactions on Software
Engineering, vol. 23 n 8, Agosto 1997.
[PIRE00] PIRES, Ftima. Modelo CMM de qualidade de software. Informativo tcnico n
70 - revista de Informao e Tecnologia - Centro de Computao da UniCamp,
janeiro/fevereiro 2000.
[PLON98] PLONSKI, Guilherme Ary. "PMI Brasil e o PMBoK". Artigo apresentado no
2nd. Project Management Conference - SUCESU/SP, Julho 1998.
[PMIS96] PMI STANDARDS COMMITTEE. A Guide to the Project Management Body of
Knowledge. Upper Darby, PA: . PMI Management Insitute, 1996. Disponvel em
http://www.pmi.org/publictn/pmbok.
[PRES95] PRESSMAN, Roger S. Engenharia de Software. So Paulo, Makron Books,
1995.
[RAPC98] RAPCHAN, Francisco. Modelos de qualidade em software. Disponvel em
http://www.inf.ufes.br/~rapchan/unesc, 1998.
[REZE97] REZENDE, Denis Alcides. Engenharia de software Empresarial. Rio de

Janeiro, Brasport, 1997.
[REZE99] REZENDE, Denis Alcides. Engenharia de software e sistemas de informao.
Rio de Janeiro, Brasport, 1999.
[ROBE98] ROBERTS Jr, Tom L.; GIBSON, Michael L.; FIELDS, Kent T. e RAINER Jr,
Kelly. Factor that Impact Implementing a System Development Methodology. IEEE
Transactions on Software Engineering, vol. 24 n8 Agosto 1998.
[ROTH98] ROTHMAN, Johanna. Achieving a Repeatable Process. Software Development
Magazine, Junho 1998.
[RUMB94] RUMBAUGH, James e outros. Modelagem e Projetos baseados em objetos.
Rio de Janeiro, Editora Campus, 1994.
[SABA99] SABAG, Paulo Yazigi. "Conceito de Gerenciamento de Riscos em Projetos".
Artigo apresentado no 3rd. Project Management Conference - SUCESU/SP,
Dezembro 1999.
[SCHM94] SCHMAUCH, Charles H. ISO 9000 for software developers. Milwaukee,
ASQC Quality Press, 1994.
[SCHN98] SCHNEIER, Robert e MICCOLIS, Jerry. Gerenciamento holstico do risco.
HSM Management, Setembro/Outubro 1998.
[SEI99] SEI - Software Engineering Institute. History.
http://www.sei.cmu.edu/about/overview/sei/history.html, 1999.
Disponvel
em
[SETZ99] SETZER, Valdemar W. Information, Knowledge and Competency. . Disponvel

em http://www.ime.usp.br/~vwsetzer/data-info.html, 1999.
[SISK98] SISK, Toney. The History of Project Management. Disponvel em
http://officeupdate.microsoft.com/articlelist/Projectarticles.htm, 1998.
[SPEC99] SPECTRUM Engenharia Ltda. "Gerenciamento de Riscos". Artigo apresentado
no 3rd. Project Management Conference - SUCESU/SP, Dezembro 1999.
[SUCE99] SUCESU-SP - Sociedade de Usurios de Informtica e Telecomunicaes de
So Paulo. Grupo de Usurios - Gesto de Projetos em TI. Disponvel em
http://www.sucesusp.com.br/html/grupos/ge.htm, 1999.
[STEI99] STEINER, Phyllis A. Let's Use Project Management for IT Infraestructure
Projects. http://www.pmi-issig.org, 1999.
[SYST97] SYSTEM CORPORATION. Managing Projects Step-by-Step. Software
produzido pela System Corporation, Verso 2.0, 1997.
[UCHO98] UCHOA, Paulo Roberto. "Aplicao do modelo PMI/PMBoK de prticas de
"Project Management" na Promon". Artigo apresentado no 2nd. Project Management
[UML97] UML. Quick reference for Rational Rose - version 1.1. Setembro/1997. Rational
Software.
[VANZ99] VANZOLINI. CEGP - Curso de Especializao em Gesto de Projetos.
Disponvel em http://www.vanzolini.org.br/areas/gerenciamento/curso.html, 1999.
124
[VOLP97] VOLPE, Renato Dela e Ana Cecilia P. Zabeu. "A Experincia da NEC do
Brasil no Planejamento e Controle de Projetos de Software". Artigo apresentado no
1st . Project Management Conference - SUCESU/SP, Julho 1997.
[WEBE99] WEBER, Kival Chaves e Ana Regina Cavalcanti. Qualidade e Produtividade
em Software. So Paulo, Makron Books, 1999.
[WHIT95] WHITEN, Neal. Managing Software development projects: formula for sucess.
John Wiley & Sons, Inc, 1995.
[XAVI95] XAVIER, Carlos Magno da S e Carla Portilho. Projetando com qualidade a
tecnologia em Sistemas de Informao. Rio de Janeiro, LTC Livros Tcnicos e
Cientficos Ltda, 1995.
[YOUR90] YOURDON, Edward. Anlise Estruturada Moderna. Rio de Janeiro, Editora
Campus, 1990.
[YOUR99] YOURDON, Edward. Anlise e Projeto Orientados a Objetos. So Paulo,
Makron Books, 1999.

EngSoft PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

EngSoft PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Instituto de Informtica

Programa de Ps-Graduao Stricto Sensu

Estudo comparativo de metodologias de

Anderson Luiz Barbosa

Dissertao desenvolvida sob orientao do

PONTIFCIA UNIVERSIDADE CATLICA DE CAMPINAS

VICE-REITOR PARA ASSUNTOS ADMINISTRATIVOS

VICE-REITOR PARA ASSUNTOS ACADMICOS

DIRETOR DO INSTITUTO DE INFORMTICA

COORDENADOR DO PROGRAMA DE PS-GRADUAO STRICTU SENSU DO

Estudo comparativo de metodologias de

Anderson Luiz Barbosa

Dissertao defendida e aprovada em 26 de junho de 2000 pela

Barbosa, Anderson Luiz, 1967

Estudo comparativo de metodologias de gerenciamento de processos

A Deus, o criador, pela ddiva da existncia.

A Jos Milton, Margarida, Maria, derson, Mrcia, Cristina,

Estudo comparativo de metodologias de

Anderson Luiz Barbosa

Comparative study about project management

Anderson Luiz Barbosa

3.4. Padres de qualidade ....................................................................26

3.4.1.4. ISO 9000-3.....................................................................................31

4. PADRES DE GERENCIAMENTO DE PROJETOS.......................52

4.2.4.9. Gerenciamento de suprimentos..................................................... 70

A.6.2. Grupo de processos 9.2. Aquisio de pessoal..............................104

REFERNCIAS BIBLIOGRFICAS.................................................. 118

XVIII NDICE DE FIGURAS

FIGURA 27 - Viso geral dos processos de gerenciamento de projetos por rea de

1.1. O problema do gerenciamento de projetos

Fonte: Computerworld, Fev 97 / Standish Group

FIGURA 1 - Projetos de Tecnologia de Informao - % de Sucessos e Fracassos

Por que os custos so to elevados?

Por que todos os erros no so descobertos e sanados antes da entrega para o

Por que existe a dificuldade em medir o progresso do software enquanto este

Entende-se Background como experincia comprovada atravs de conhecimentos e prticas.

Absoro de inovaes tecnolgicas - introduo de novidades tecnolgicas,

Especificao de projetos incompleta - dificuldade em captar os requisitos dos

Metodologias inadequadas - no definio de qual metodologia ser adotada;

Subestimativa de riscos - ausncia de um processo formal de avaliao e

Dificuldades de estimar prazos e recursos - mtodo normalmente utilizado a

Dificuldade de aferir progresso - falta de marcos concretos e ponderados ao

Fraco acoplamento entre as estratgias empresariais e as de TI - priorizao dos

Cultura das organizaes - [NOLA77] define e caracteriza empresas de acordo

Ambiente tpico de desenvolvimento de projetos - falta de instrumentos,

A presente dissertao verifica o porque destas estatsticas to pouco favorveis produo

1.2. Estrutura da dissertao

O Captulo 2 - Gerenciamento de projetos - apresenta uma viso geral do universo do

PMI - Project Management Institute - principal organizao mundial sobre

SEI - Software Engineering Institute - um dos principais organismos mundiais

ISO - International Organization for Standardization - um dos mais tradicionais

Existem outras inmeras organizaes que poderiam ser mencionadas, incluindo as

engenharia de software, gerenciamento de projetos e anlise e projeto de sistemas de

Cap. 2 Gerenciamento de Projetos

Escopo - tudo o que deve ser produzido neste projeto

Prazos - ordem cronolgica dos resultados/produtos deste projeto

Custo - valor para a produo deste projeto

Qualidade - tanto do processo de conduo quanto dos produtos gerados pelo

Diferentes necessidades e expectativas dos stakeholders

Separar o que necessidade (requisito) de expectativa (requisito ainda no

2.1.1. Conceito de projeto

So realizados por pessoas

Devem ser planejados, executados e controlados