UNIVERSIDADE FEDERAL DA PARAÍBA

JOÃO PAULO FREITAS DE OLIVEIRA

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Este trabalho está licenciado sob uma Licença Creative Commons Atribuição-Uso Não-Comercial
2.5 Brazil. Para ver uma cópia desta licença, visite http://creativecommons.org/licenses/by-nc-
nd/2.5/br/ ou envie uma carta para Creative Commons, 559 Nathan Abbott Way, Stanford, California
94305, USA.

JOÃO PESSOA
2005
 2

JOÃO PAULO FREITAS DE OLIVEIRA

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Monografia de estágio supervisionado de

conclusão do curso de Ciência da
Computação do Centro de Ciências Exatas
e da Natureza da Universidade Federal da
Paraíba, como requisito parcial para
obtenção do grau de Bacharel em Ciência
da Computação.

ORIENTADOR: Prof. Dr. Glêdson Elias

JOÃO PESSOA
2005
 3

JOÃO PAULO FREITAS DE OLIVEIRA

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Monografia de estágio supervisionado de

conclusão do curso de Ciência da Computação
do Centro de Ciências Exatas e da Natureza da
Universidade Federal da Paraíba, como
requisito parcial para obtenção do grau de
Bacharel em Ciência da Computação.

Aprovada em 06 de junho de 2005

_________________________
Prof. Dr. Glêdson Elias
Orientador

___________________________
Prof. Ed Porto Bezerra
Professor da cadeira estágio supervisionado
 4

A mainha e painho, com todo carinho, afeto e respeito.

Meus irmãos Sara e Saulo que sempre me instigaram.
 5

AGRADECIMENTOS

Primeiramente a Deus, Jesus Cristo e Nossa Senhora pela fé e coragem.

Ao Prof. Dr. Glêdson Elias que teve a atenção de se dispor e competência de ser
meu orientador.

Aos professores do Departamento de Informática da Universidade Federal da

Paraíba que foram meus mestres durante toda a graduação.

Aos todos os meus colegas da graduação de Ciência da Computação.

Aos meus amigos de sempre Charles, Alan e Guilherme. Que sempre se dispuseram
a me ajudar durante todos os momentos difíceis e alegres.

Meu eterno agradecimento ao amigo e conselheiro João Andrade.

 6

"Estratégia é a arte ou ciência de saber identificar e

empregar meios disponíveis para atingir determinados
fins, apesar de a eles se oporem obstáculos e/ou
antagonismos conhecidos."
Sun Tzu
 7

RESUMO

Objetivando dispor de um recurso organizacional e operacional que facilite e forneça

apóio técnico-administrativo ao gerenciamento de múltiplos projetos e auxilie a

mantê-los alinhados com a estratégia, objetivos e as metas do laboratório de

pesquisa COMPOSE – Component Oriented Service Enginnering. Buscamos

implantar Project Management Office (PMO) para projetos de software, com base na

metodologia de Gerenciamento de Projetos, PMBOK® Guide, padronizada pelo

Project Management Institute (PMI), com os controles básicos de gerência alinhado

com os processos chaves de CMM nível 2, de forma personalizada e adaptada às

características e peculiaridades do laboratório.

Palavras-chave: Gerenciamento de projetos. Engenharia de software. PMI. CMM.

PMO. PMBOK.
 8

ABSTRACT

Aiming to provide organizational and operational resources that facilite and provide

technical and administrative support to multiple projects management, in conjunction

with COMPOSE's (Component-Oriented Software Engineering research laboratory)

strategies, objectives and goals, we had implemented the Project Management Office

(PMO) especially adapted for software projects, based on PMBOK® Guide, a Project

Management Institute (PMI) Standard, controlling the management basics and key

processes of CMM level 2 and customized it to laboratory needs.

Keywords: Project management, software engineering. PMI. CMM. PMO. PMBOK.

 9

SUMÁRIO

1 APRESENTAÇÃO .................................................................................................10

2 JUSTIFICATIVA.....................................................................................................12

3 OBJETIVOS...........................................................................................................14
3.1 Objetivo Geral....................................................................................................14
3.2 Objetivo Específico ...........................................................................................14

4 REFERENCIAL TEÓRICO.....................................................................................15
4.1 Contexto Histórico ............................................................................................15
4.2 Gerenciamento de Projetos..............................................................................17
4.3 PMI......................................................................................................................19
4.4 PMBOK® Guide .................................................................................................21
4.5 CMM - Capability Maturity Model .....................................................................26

5 METODOLOGIA ....................................................................................................36

6 CONCLUSÃO.........................................................................................................38

REFERÊNCIAS..........................................................................................................40
 10

1 APRESENTAÇÃO

Após anos e promessas de obter um aumento de produtividade e qualidade

de software, as empresas, as organizações e o governo chegaram a conclusão que

a maior dificuldade é a inabilidade para gerenciar os processos de desenvolvimento

de software. Na maioria das organizações não há um cumprimento dos prazos

quando planejados e os seus custos de projetos ficam na maioria das vezes acima

do valor planejado, chegando a afetar o projeto para a organização. Os benefícios

dos melhores métodos e ferramentas não são alcançados e geram um ambiente

caótico e sem disciplina. Em alguns casos, organizações sem disciplinas de

planejamento de software conseguem excelentes resultados. A excelência de

resultado é obtida através da dedicação de uma pessoa ou de uma equipe, ao

contrário da repetição de métodos comprovados como os indicados pelo Project

Management Institute (PMI) ou pelo Software Engineering Institute (SEI).

Segundo Kaplan [KAPLAN 2004], o que não se pode medir, não se pode

gerenciar. A frase traduz a necessidade, cada vez maior, que os atuais gestores têm

de se servir de metodologias e indicadores que lhes permitam estabelecer objetivos,

monitorar os resultados e verificar, de forma objetiva, como essas metas propostas

foram atingidas.

O gerenciamento de projetos é um tema importante no contexto atual,

empresas ao redor do mundo estão enviando seus funcionários para serem

treinados com o objetivo de melhorar a eficiência e a eficácia de seus projetos. Com

isso os gerentes de projetos estão se tornando melhores em completar seus projetos

no prazo, dentro do orçamento e de acordo com o escopo. Apesar disso, há uma

 11

emergente preocupação de que o gerenciamento de projetos deve ser no nível

organizacional e não no individual. Reconhecendo isto, recentemente tem existido

um grande esforço em direção à criação e a manutenção de um departamento

chamado Project Management Office (PMO) [HALLOWS 2002].

O presente trabalho, diante esta necessidade, destina-se a oferecer

informações sobre o projeto de estagio de João Paulo Freitas de Oliveira. Entre as

atividades a serem desenvolvidas pelo estagiário destaca-se a implantação de um

PMO (Project Management Office ou Escritório de Gerenciamento de Projetos) para

projetos de software.

Para a realização deste estágio, com orientação do Prof. Dr. Glêdson Elias,

estudaremos as técnicas de Planejamento e Gerenciamento de Projetos de

Software, alinhados com as normas do Project Management Body of Knowledge –

PMBOK Guide versão 2000 e os padrões CMM do Software Engineering Institute

(SEI).
 12

2 JUSTIFICATIVA

Projetos são meios de implementação de estratégias de negócios e podem

fracassar por vários motivos, pois gerenciar projeto não é tarefa fácil.

Segundo estudo feito por Barki et al. [BARKI 2001], mais de 50% dos projetos

analisados ultrapassaram os valores previstos no orçamento, enquanto que 42%

ultrapassaram o tempo previsto para sua conclusão. De acordo com o Standish

Group [2000], 74% dos projetos de software não são bem sucedidos, sendo que a

taxa de cancelamento antes da sua conclusão atinge 31,1%. Boehm [BOEHM 1991]

enfatiza que os efeitos de outputs negativos se refletem em várias dimensões,

atingindo clientes, usuários, desenvolvedores e mantenedores dos projetos.

O sucesso na execução de projetos depende de uma série de fatores, tais

como: a seleção dos Gerentes de Projetos; o treinamento; a retenção dos talentos; a

priorização dos padrões de métodos e ferramentas; e o apoio aos Gerentes de

Projetos. No entanto tarefas tem sido vistas como uma função organizacional assim

como RH ou finanças.

O Escritório de Gerenciamento de Projetos (ou simplesmente Escritório de

Projetos) surge como uma possível alternativa para a administração de projetos num

ambiente complexo.

A adoção de uma metodologia de gerenciamento de projetos personalizada,

dentro dos padrões do PMBOK Guide, impactará positivamente nos programas de

qualidade de qualquer organização.

As organizações, para colherem os benefícios esperados, devem ter

conscientização em adotar o gerenciamento de projetos não somente como uma

 13

profissão, mas como uma metodologia na qual os seus gerentes devam ser

devidamente treinados, de forma a agregar valor às experiências individuais de cada

um deles. O gerenciamento de projetos deve ser feito de forma profissional e

conduzido por pessoa qualificado. Desta forma, a cultura de projetos deve ser

criada, a sua implantação deve ser realizada de forma sistemática e os seus

princípios colocados em prática da maneira mais adequada às necessidades.

Diante deste contexto, nossa proposta se dá na implantação de um Project

Management Office (PMO) para projetos de software tendo como referências o

PMBOK Guide versão 2000 e os processos chaves de CMM Nível 2.

 14

3 OBJETIVOS

3.1 Objetivo Geral

Dispor de um recurso organizacional e operacional que facilite e forneça apóio

técnico-administrativo ao gerenciamento de múltiplos projetos e auxilie a mantê-los

alinhados com a estratégia, objetivos e as metas do laboratório de pesquisa

COMPOSE - Component-Oriented Software Engennering.

3.2 Objetivo Específico

• Implantar Project Management Office (PMO) para projetos de software, com

base na metodologia de Gerenciamento de Projetos padronizada pelo Project

Management Institute (PMI), de forma personalizada e adaptada às

características e peculiaridades do laboratório;

• Estabelecer controles básicos de gerência alinhado com os processos chaves

de CMM nível 2.
 15

4 REFERENCIAL TEÓRICO

Para a elaboração deste projeto, foram levados em conta estudos das

seguintes áreas:

• Contexto Histórico

• Gerenciamento de Projetos

• PMI

• PMBOK Guide 2000

• CMM

4.1 Contexto Histórico

Projetos vêm sendo realizados desde os primórdios da civilização. A

construção das Pirâmides do Egito, 2780 a.C. [Vicentino 1997], por exemplo, foi um

grande projeto.

Na metade do século XIX, com a Revolução Industrial alterando

profundamente a estrutura econômica do mundo ocidental, uma das suas principais

conseqüências foi o desenvolvimento do capitalismo industrial. Com um crescente

aumento na complexidade dos novos negócios em escala mundial surgindo assim os

princípios da gerencia de projetos [SISK 1998].

Frederick Taylor, iniciou seus estudos de forma detalhada sobre trabalho. Ele

aplicou raciocínio científico para mostrar que o trabalho pode ser analisado e

melhorado focando em suas partes elementares. Ele aplicou sua teoria às atividades
 16

encontradas na indústria de aço (por exemplo, carregar areia, levantar areia) [SISK

1998].

Antes de Taylor a única maneira de aumentar a produtividade era através de

longas horas de trabalho dos empregados. Dentro da história da gerência de

projetos ele é conhecido como "o pai do gerenciamento científico" [SISK 1998].

Henry Gantt, sócio de Taylor, estudou detalhadamente a ordem de operação

no trabalho. Ele construiu diagramas com barras de tarefas e marcos, que esboçam

a seqüência e a duração de todas as tarefas em um processo. Os diagramas de

Gantt provaram ser uma ferramenta analítica tão poderosa para gerentes que se

mantiveram virtualmente inalteradas por quase cem anos, somente nos anos 90,

onde linhas de ligação foram adicionadas às barras de tarefa que descrevem as

dependências mais precisas entre tarefas. Sisk (1998 apud TORREÃO 2005)

No início dos anos 60, o gerenciamento de projetos foi formalizado como

ciência (Prado 2000). Os negócios e outras organizações começaram a enxergar o

benefício do trabalho organizado em torno dos projetos e a entender a necessidade

crítica para comunicar e integrar o trabalho através de múltiplos departamentos e

profissões. Sisk (1998 apud TORREÃO 2005).

Em 1969, no auge dos projetos espaciais da NASA, um grupo de cinco

profissionais de gestão de projetos, da Philadelphia e Pensilvania nos Estados

Unidos, se reuniram para discutir as melhores práticas e Jim Snyder fundou o

Project Management Intitute – PMI (EUA). O PMI é a maior instituição internacional

dedicada à disseminação do conhecimento e ao aprimoramento das atividades de

gestão profissional de projetos atualmente (PMI, 2004; SISK, 1998).

 17

4.2 Gerenciamento de Projetos

Um projeto é um empreendimento único, com início e fim bem definidos, que

utiliza recursos limitados e é conduzido por pessoas, visando atingir metas e

objetivos pré-definidos, estabelecidos dentro de parâmetros de prazo, custo e

qualidade (PMI, 2000).

O projeto pode ser definido por características distintas como temporário,

único e progressivo. A característica de ser temporário é muito importante, pois todo

projeto tem um início e fim bem definidos, diferente dos serviços continuados, onde

os mesmo são contínuos e repetitivos. O projeto termina quando os objetivos para o

qual foi criado são atingidos ou quando se torna claro que os objetivos do projeto

não serão ou não poderão ser mais atingidos ou a necessidade do projeto não existe

mais (PMI, 2000).

Ser único significa que todo produto ou serviço gerado por um projeto é

diferente de outros produtos e serviços. Os projetos envolvem a realização de algo

jamais realizado anteriormente e logo é único (PMI, 2000).

Para ser executado, um projeto precisa ser gerenciado. Segundo Koontz e

O’Donnel (1980), gerenciar consiste em executar atividades e tarefas que têm como

propósito planejar e controlar atividades de outras pessoas para atingir objetivos que

não podem ser alcançados caso as pessoas atuem por conta própria, sem o esforço

sincronizado dos subordinados.

Segundo o PMI, o gerenciamento de projetos é a aplicação de

conhecimentos, habilidades e técnicas para projetar atividades que visem atingir os

requerimentos do projeto. O gerenciamento do projeto é acompanhado através do

 18

uso de processos como: iniciação, planejamento, execução, controle e

encerramento.

A gestão de projetos envolve criar um equilíbrio entre as demandas de

escopo, tempo, custo, qualidade e bom relacionamento com o cliente. O sucesso na

gestão de um projeto está relacionado ao alcance dos seguintes objetivos: entrega

dentro do prazo previsto, dentro do custo orçado, com o nível de desempenho

adequado, aceitação pelo cliente, atendimento de forma controlada às mudanças de

escopo e respeito à cultura da organização (PMI, 2000).

A pessoa responsável pelo gerenciamento do projeto é o gerente de projetos,

conseqüentemente é responsável também pelo seu sucesso. O gerente deve ser

designado desde o início do projeto e deve ter o apoio visível da alta administração.

Ele deve ter sua competência reconhecida pelos demais interessados no projeto,

embora não precise ter profundo conhecimento técnico uma vez que sua

competência está mais voltada para o entendimento geral e não para o específico

(PMI, 2000).

O gerente de projetos possui várias atividades e responsabilidades, como por

exemplo: definir e controlar os objetivos do projeto; definir e controlar os requisitos

do produto; definir e controlar os riscos do projeto; definir e avaliar os fatores críticos

de sucesso do projeto; definir e avaliar os pontos fortes e fracos do projeto; definir e

controlar o cronograma; alocar e gerenciar recursos; definir prioridades; coordenar

interações entre os envolvidos no projeto; assegurar que prazos e custos estão

sendo mantidos dentro do planejado; assegurar que os produtos do projeto atendam

ao critérios de qualidade e que estejam de acordo com os padrões estabelecidos;

participar de reuniões de acompanhamento e de revisão do projeto (PMI, 2000).

 19

4.3 PMI

Utilizando as informações disponibilizadas pelo Chapter São Paulo, Brasil do

PMI (PMI® - SP), descreveremos uma breve história do Project Management

Institute (PMI®)

Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o Project

Management Institute (PMI®) é a principal associação mundial sem fins lucrativos

em gerenciamento de projetos, cujo principal objetivo é difundir a gestão de projetos

no mundo, de forma a promover ética e profissionalismo no exercício desta

atividade. Esta associação ocupa posição de liderança global no desenvolvimento

de padrões para a prática da profissão de gerente de projetos, atualmente com mais

de 150.000 associados em todo o mundo.

O Project Management Institute foi fundado em 1969 por cinco voluntários. A

Comunidade da Pensilvânia emitiu as Cláusulas de Incorporação do PMI®,

oficializando sua fundação. Durante aquele mesmo ano, o primeiro PMI® Seminars

& Symposium aconteceu em Atlanta, Geórgia EUA, com a participação de 83

pessoas.

Nos anos setenta, a primeira edição do Project Management Quarterly (PMQ)

foi publicada, e posteriormente renomeada para Project Management Journal (PMJ).

O primeiro evento anual “Seminars & Symposium” foi realizado fora dos EUA, o

primeiro Capítulo do PMI® foi oficializado e o primeiro Programa de Prêmios

Profissionais estabelecido. Ao final da década de setenta, o PMI® somava mais de

2.000 associados no mundo.

Durante os anos oitenta, o número de associados do PMI® continuou

crescendo, bem como os programas e serviços oferecidos pela associação. Um

 20

Código de Ética foi adotado para a profissão e o primeiro Project Management

Professional (PMP®) foi certificado.

O primeiro modelo padrão de Gerenciamento de Projetos foi publicado: o

PMQ Special Report on Ethics Standards and Accreditation. As publicações do

PMI® sobre produtos e serviços cresceram rapidamente durante esta década. O

primeiro livro do PMI® foi co-publicado e nasceu a PMNetwork, revista mensal do

PMI®. Em função deste crescimento foi estabelecida a Divisão de Publicações do

PMI® na Carolina do Norte, EUA.

Em 1990, o PMI® somava mais de 8.500 associados e em 1993 este número

crescia cerca de 20% ao ano. Durante os anos noventa foram formados os Grupos

de Interesses Específicos, os Colleges e o Seminars USA, uma série de programas

educacionais em Gerenciamento de Projeto (depois renomeado como World

Seminars). O PMI® também marcou presença na rede mundial da Internet e

publicou o “A Guide to the Project Management Body of Knowledge (PMBOK®

Guide)”, um guia englobando todas as áreas do conhecimento que regem as regras

do gerenciamento de projetos. O PMI® Today, boletim informativo mensal do PMI®,

foi impresso pela primeira vez e o Programa de Desenvolvimento Profissional

(Professional Development Program - PDP) foi estabelecido para que os

profissionais certificados como PMP® mantenham sua certificação.

No inicio do século 21, o PMI® tinha mais de 50.000 associados, mais de

10.000 Profissionais de Gerenciamento de Projeto (PMP®) certificados e mais de

270.000 cópias do PMBOK® Guide estavam em circulação.

Publicado a primeira versão em 1996, o principal documento padrão do PMI®,

“A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”, é um

padrão globalmente reconhecido para o Gerenciamento de Projetos nos mercados

 21

de hoje. O PMBOK® Guide , edição de 1996 e 2000, foram aprovados como um

padrão pelo Instituto de Engenheiro Elétricos e Eletrônicos (Institute of Eletrical and

Eletronics Engineers – IEEE). O PMBOK® Guide , edição 2000, é aprovado como

um Padrão Nacional Americano (ANS) pelo Instituto de Padrões Nacional Americano

(ANSI).

O PMI® está compromissado com a expansão e melhoria contínua do

PMBOK® Guide, assim como com o desenvolvimento de padrões adicionais.

Desde 1984 o PMI® tem se dedicado a desenvolver e manter um rigoroso

programa de certificação profissional para promover o crescimento da profissão de

Gerente de Projetos e reconhecer as realizações de indivíduos no tema. A

certificação de Project Management Professional do PMI® (PMP®) é a credencial

mais reconhecida mundialmente para indivíduos envolvidos com o Gerenciamento

de Projetos. Em 1999, o PMI® se tornou a primeira organização no mundo a ter seu

Programa de Certificação reconhecido pela ISO 9001.

4.4 PMBOK® Guide

Segundo o PMI, seguindo as orientações do PMBOK, o gerente de projetos

aprende a metodologia aplicada à maioria dos projetos, porém maleável às diversas

necessidades de utilização, e conhece a linguagem peculiar ao segmento de forma

padronizada. Talvez o maior sucesso desta proposta do PMI venha do fato de que

esta é uma abordagem que confere o desejado enfoque profissional na condução do

projeto. As exigências e as restrições de toda ordem, principalmente as financeiras,

exigem que o projeto seja cercado de todas as garantias para que os objetivos
 22

propostos sejam atendidos e que o mesmo seja finalizado com sucesso e de forma

profissional (PMI, 2000 apud TORREÃO 2005).

Grande parte do conhecimento e muitas das ferramentas e técnicas usadas

para gerenciar projetos são exclusivas do gerenciamento de projetos, como

estruturas analíticas do projeto, análise do caminho crítico e gerenciamento de valor

agregado. No entanto, o entendimento e a aplicação do conhecimento, das

habilidades, das ferramentas e das técnicas amplamente reconhecidas como boa

prática não são suficientes isoladamente para um gerenciamento de projetos eficaz.

Um gerenciamento de projetos eficaz exige que a equipe de gerenciamento de

projetos entenda e use o conhecimento e as habilidades de pelo menos cinco áreas

de especialização:

a) O Conjunto de conhecimentos em gerenciamento de projetos

b) Conhecimento, normas e regulamentos da área de aplicação

c) Entendimento do ambiente do projeto

d) Conhecimento e habilidades de gerenciamento geral

e) Habilidades interpessoais.

A figura 01 ilustra as áreas especializadas necessárias à equipe de projeto

Fig 01 - Áreas de especialização

 23

O gerenciamento de projetos, de acordo com o PMBOK Guide edição 2000,

identifica e descreve as principais áreas de conhecimento e práticas. Cada uma

destas áreas, no total 9, é descrita através de 39 processos, e se refere a um

aspecto a ser considerado dentro da gerência de projetos.

As áreas de conhecimento de gerenciamento são: Gerenciamento de

Integração do Projeto, Gerenciamento do Escopo do Projeto, Gerenciamento do

Tempo do Projeto, Gerenciamento do Custo do Projeto, Gerenciamento da

Qualidade do Projeto, Gerenciamento de Recursos Humanos do Projeto,

Gerenciamento de Comunicação do Projeto, Gerenciamento do Risco do Projeto e

Gerenciamento de Contratação do Projeto.

A não execução de processos de uma área afeta negativamente o projeto,

pois o projeto é um esforço integrado. Por exemplo, uma mudança de escopo quase

sempre afeta o custo do projeto. Entretanto, ela pode ou não afetar a qualidade do

produto.

A Gerência de Integração do Projeto: descreve os processos necessários

para assegurar que os diversos elementos do projeto sejam adequadamente

coordenados. Sendo composto pelo desenvolvimento do plano do projeto, execução

do plano do projeto e controle integrado de mudança.

A Gerência do Escopo do Projeto: descreve os processos necessários para

assegurar que o projeto termine dentro do prazo e contemple todo o trabalho

requerido, e nada mais que o trabalho requerido, para completar o projeto com

sucesso. Sendo composto pela iniciação, planejamento do escopo, detalhamento do

escopo, verificação do escopo e controle de mudanças do escopo.

A Gerência do Tempo do Projeto: descreve os processos necessários para

assegurar que o projeto termine dentro do prazo previsto. Sendo composto pela
 24

definição das atividades, seqüenciamento das atividades, estimativa da duração das

atividades, desenvolvimento do cronograma e controle do cronograma.

A Gerência do Custo do Projeto: descreve os processos necessários para

assegurar que o projeto seja completado dentro do orçamento previsto. Sendo

composto pelo planejamento dos recursos, estimativa dos custos, orçamento dos

custos e controle dos custos

A Gerência da Qualidade do Projeto: descreve os processos necessários para

assegurar que as necessidades que originaram o desenvolvimento do projeto serão

satisfeitas. Sendo composto pelo planejamento da qualidade, garantia da qualidade

e controle da qualidade.

A Gerência dos Recursos Humanos do Projeto: descreve os processos

necessários para proporcionar a melhor utilização das pessoas envolvidas no

projeto. Sendo composto pelo planejamento organizacional, montagem da equipe e

desenvolvimento da equipe.

A Gerência das Comunicações do Projeto: descreve os processos

necessários para assegurar que a geração, captura, distribuição, armazenamento e

pronta apresentação das informações do projeto sejam feitas de forma adequada e

no tempo certo. Sendo composto pelo planejamento das comunicações, distribuição

das informações, relato de desempenho e encerramento administrativo.

A Gerência dos Riscos do Projeto: descreve os processos que dizem respeito

à identificação, análise e resposta a riscos do projeto. Sendo composto pelo

Planejamento da Gerência de Risco, identificação dos riscos, análise qualitativa de

riscos, análise quantitativa de riscos , desenvolvimento das respostas aos riscos e

controle e monitoração de riscos.

 25

A Gerência das Aquisições do Projeto: descreve os processos necessários

para a aquisição de mercadorias e serviços fora da organização que desenvolve o

projeto. Sendo composto pelo planejamento das aquisições, preparação das

aquisições, obtenção de propostas, seleção de fornecedores, administração dos

contratos e encerramento do contrato.

O conjunto das fases de um projeto é conhecido como ciclo de vida do

projeto. O Gerenciamento do Projeto é acompanhado através do uso de processos

em cada uma das fases formando cinco grupos de processos: iniciação,

planejamento, execução, controle / monitoramento e encerramento.

Fig 02 - Mapeamento entre os grupos de processos de gerenciamento de projetos e o

Os grupos de processos do ciclo de vida do projeto se ligam pelos resultados

que produzem. O resultado ou saída de um grupo torna-se entrada para outro. Entre

grupos de processos centrais, as ligações são iterativas, ou seja, o planejamento

alimenta a execução, no início, com um plano do projeto documentado, fornecendo,

a seguir, atualizações ao plano, na medida em que o projeto progride. Os grupos de

processos da gerência de projetos não são separados ou descontínuos, nem

acontecem uma única vez, durante todo o projeto. Eles são formados por atividades
 26

que se sobrepõem, ocorrendo em intensidades variáveis ao longo de cada fase do

projeto.

Fig 03 - Interação de grupos de processos em um projeto

Os processos interagem e se relacionam por suas entradas e saídas. Cada

processo possui 3 itens: entradas, ferramentas e técnicas, e saídas. As entradas são

documentos ou itens documentáveis que influenciarão o processo. As ferramentas e

técnicas são mecanismos aplicados às entradas para criar as saídas. As saídas são

documentos ou itens documentáveis resultantes do processo.

4.5 CMM - Capability Maturity Model

O Modelo de Maturidade da Capacidade (CMM) é uma iniciativa do SEI

(Software Engineering Institute) para avaliar e melhorar a capacitação de empresas

que produzem software. O projeto CMM foi apoiado pelo Departamento de Defesa

do Governo dos Estados Unidos, que é um grande consumidor de software e

precisava de um modelo formal que permitisse selecionar os seus fornecedores de

software de forma adequada. Embora não seja uma norma emitida por uma
 27

instituição internacional (como a ISO ou o IEEE), esta norma tem tido uma grande

aceitação mundial, até mesmo fora do mercado americano.

O CMM é uma estrutura que representa um caminho para melhoria de

processos, recomendada para organizações de software que desejam melhorar seus

processos de software. Esta estrutura operacional do CMM é projetada para dar

suporte às suas várias formas de utilização, tais como: as mudanças que a

instituição deve usar para desenvolver e manter os produtos de software; fornecer

para a organização guia ou métodos e subsídios para que as empresas programem

estas melhorias em seus processos de desenvolvimento de software.

O CMM é um modelo para medição da maturidade de uma organização no

que diz respeito ao processo de desenvolvimento de software. Maturidade de

processos são conjunto de atividades, métodos, práticas e mudanças que deverão

ser implementadas para o desenvolvimento e manutenção dos produtos de software.

Toda a organização, que deseja alcançar esta maturidade, precisará descrever os

conjuntos de atividades, métodos, práticas e transformação para o desenvolvimento

e manutenção dos seus produtos de software, através de uma política de padrões e

estrutura organizacional.

A definição do que é “Maturidade” pode ser mais bem compreendida através

da análise do quadro abaixo:

Organizações maduras Organizações imaturas

Papéis e responsabilidades bem
definidos
Existe base histórica
É possível julgar a qualidade do
produto
A qualidade dos produtos e
processos é monitorada
O processo pode ser atualizado
Existe comunicação entre
gerente e seu grupo
Processo improvisado
Não existe base histórica
Não há maneira objetiva de julgar
a qualidade do produto
Qualidade e funcionalidade do
produto sacrificada
Não há rigor no processo a ser
seguido
o
Resolução de crises imediatas
 28

O CMM classifica as organizações em cinco níveis distintos, cada um com

suas características próprias. Nestes cinco níveis é possível a organização medir em

qual escala ou estágio se encontra.

Fig 04 - Os cinco níveis de CMM para software

Nível 1 - Nível Inicial: chamado também de nível caótico, os processos não

estão definidos e o sucesso depende de esforços individuais. As aplicações são

desenvolvidas com um método individual. Carecem de processos de cronograma e

os prazos são sacrificados e comprometedores. Os Gerentes de Projetos

administram o caos, dependente de esforços individuais de seu time de trabalho. O

comprometimento do projeto não existe e as rupturas sempre acontecem.

Nível 2 - Nível Repetível: o gerente de projetos planeja com eficiência os

cronogramas e estabelece um controle dos requerimentos para a produção do

software. As instituições possuem capacitação para liberar seus produtos dentro dos

prazos e não elevando o custo dos projetos. O planejamento e a gestão de novos

projetos são baseados na experiência adquirida em projetos similares. Neste nível,

as organizações têm a possibilidade de repetir as práticas bem sucedidas de

 29

desenvolvimento. Um processo efetivo pode ser caracterizado como hábil,

documentado, robusto, treinado, medido e com capacidade de poder ser melhorado.

Os compromissos realistas do projeto são baseados em resultados observados em

projetos anteriores e nos requisitos do projeto atual. Os gerentes de projetos

acompanham os custos, cronogramas e funcionalidades, os problemas com

compromissos são identificados quando surgem. Os requisitos e os produtos de

trabalho de software desenvolvidos para satisfazê-los são armazenados de forma

criteriosa e a integridade dos mesmos é controlada. Os padrões são seguidos

fielmente. Os processos estão sob um controle efetivo de um sistema de gestão de

projetos, seguindo planos realistas baseados no desempenho de projetos anteriores.

Nível 3 - Nível Definido: prática de repetição adquirida ao longo dos processos

e o amadurecimento da prática de desenvolvimento. A instituição começa a adquirir

uma cultura de desenvolvimento no nível três. Com uma forte cultura com a

reutilização de processos comuns. Os projetos adaptam o processo de software

padrão da organização para desenvolver seus próprios processos de software

definidos, que consideram as características únicas de cada projeto. A capabilidade

de processo de software das organizações de nível três pode ser resumida como

sendo padronizada e consistente porque tanto as atividades de gestão como as de

engenharia de software são estáveis e repetíveis. Nas de linhas de produtos

estabelecidas, a qualidade de software é acompanhada, além do custo, cronograma

e funcionalidades estarem sob controle. Essa capabilidade de projeto é baseada em

um entendimento global da organização com relação às atividades, regras e

responsabilidades decorrentes do processo de software definido.

Nível 4 - Nível Gerenciado: após o estágio três, com as práticas adquiridas

para o projeto de desenvolvimento de software, as instituições estão capacitadas a

 30

gerar estatísticas que caracterizam o desempenho de seus processos. Com os

resultados dos projetos, uma organização pode gerenciar os seus desempenhos dos

processos estatisticamente. A organização estabelece metas quantitativas de

qualidade para os produtos e processos de software. A produtividade e a qualidade

são medidas nas atividades importantes de processo de software em todos os

projetos, como parte de um programa organizacional de medições. Um banco de

dados de processo de software, que abrange a organização toda, é utilizado para

coletar e analisar os dados disponíveis dos processos de software definidos dos

projetos. No nível quatro, os processos de software são instrumentalizados com

medições consistentes e bem definidas. Essas medições estabelecem as bases para

avaliar os processos e os produtos de software do projeto. Os projetos possuem

controle sobre seus produtos e processos, reduzindo a variação no desempenho

desses últimos, para atingir limites quantitativos aceitáveis. As variações

significativas no desempenho dos processos podem ser distinguidas das variações

aleatórias (ruídos), particularmente dentro de linhas de produtos estabelecidas. Os

riscos decorrentes da introdução de um novo domínio de aplicação são conhecidos

e cuidadosamente gerenciados. A capabilidade de processo de software das

organizações de nível quatro pode ser resumida como sendo previsível porque o

processo é medido e opera dentro de limites mensuráveis. A capabilidade de

processo desse nível permite que a organização preveja as tendências na qualidade

dos produtos e dos processos dentro das fronteiras quantitativas desses limites.

Quando esses limites são excedidos, são tomadas providências para corrigir a

situação. Como era de se esperar, os produtos de software são de alta qualidade.

Nível 5 - Em Otimização: contínuas mudanças no gerenciamento dos

processos de desenvolvimento. Com a maturidade adquirida e com o aprendizado,

 31

as instituições adquirem a prática de novos processos ou novas tecnologias. Neste

nível, toda a organização está voltada para a melhoria contínua de processo. A

organização tem meios de identificar as oportunidades de melhoria e fortalecer o

processo de maneira pró-ativa, com o objetivo de prevenir a ocorrência de falhas. Os

dados sobre a efetividade do processo de software são utilizados para realizar

análises de custo benefício das novas tecnologias e das mudanças propostas no

processo de software da organização. As inovações decorrentes das melhores

práticas de engenharia de software são identificadas e transferidas para a

organização toda. As equipes de projeto de software das organizações de nível

cinco analisam as falhas para determinar suas causas. Os processos de software

são revistos para prevenir tipo de falhas já conhecidas que normalmente se repetem

e as lições apreendidas são disseminadas para outros projetos. A capabilidade de

processo de software das organizações de nível cinco pode ser resumida como

sendo de melhoria contínua porque estas estão sempre se esforçando para

melhorar a abrangência de sua capabilidade de processo, melhorando dessa forma

o desempenho dos processos de seus projetos. As melhorias ocorrem através de

avanços incrementais nos processos já existentes e através de inovações que

utilizam novos métodos e tecnologias.

A maturidade do processo de software de uma organização ajuda a se prever

a habilidade do projeto em atingir as suas metas. Os projetos nas organizações de

Nível 1 apresentam grandes desvios em relação às metas de custo, cronograma,

funcionalidade e qualidade. Como pode ser visto na Figura 05, três melhorias

relacionadas ao alcance de metas são observadas à medida que o processo de

software da organização vai se tornando mais maduro.

 32

Fig 05 - Capabilidade dos processos como indicado pelo nível de maturidade

À medida que a organização de software amadurece, os custos diminuem, o

tempo de desenvolvimento se torna menor, e a produtividade e a qualidade

aumentam. Isto é, os resultados esperados melhoram à medida que a maturidade da

organização aumenta.

Cada nível de maturidade pode ser decomposto em partes. Com exceção do

nível 1, a decomposição de cada nível de maturidade abrange desde os sumários

abstratos de cada nível até as definições operacionais das práticas chaves, como é

mostrada na Figura 06. Cada nível de maturidade é composto por vários processos

chaves. Cada processo chave é organizado dentro de 5 seções chamadas de

características comuns. As características comuns especificam as práticas chaves

que, quando corretamente usadas, atingem os objetivos dos processos chaves das

áreas.
 33

Fig 06 - Estrutura interna dos níveis de maturidade

Cada processo chave identifica um conjunto de atividades relacionadas que,

quando executadas coletivamente, cumprem o objetivo do proposto. O processo

chave deve ser definido para um único nível de maturidade. O caminho para atingir

os objetivos de um processo chave poderá ser diferente para cada projeto,

dependendo das diferenças entre os projetos.

O processo é considerado chave, pois ele é crítico para atingir o nível de

maturidade. O CMM não descreve todos os processos chaves em detalhes que são

requeridos para desenvolver e manter os produtos de software.

Os processos chaves para o nível 2 têm foco nos problemas de controle dos

projetos de software:

• Gerenciamento dos requesitos do projeto.

• Gerenciamento do plano de atividades do projeto.

• Acompanhamento e inspeção do progresso do projeto.

 34

• Gerenciamento dos fornecedores contratados para o projeto.

• Gerenciamento da qualidade do projeto.

• Gerenciamento da configuração de software.

Os processos chave para o nível 3 têm foco no projeto e na organização:

• Estabelecimento de uma organização responsável pelas atividades que

compõem os processos de software.

• Estabelecimento de uma organização para definir, desenvolver e

manter um conjunto de processos de software para melhorar a

desempenho dos projetos.

• Estabelecimento de um programa de treinamento para desenvolver os

talentos da organização.

• Integração do gerenciamento entre a engenharia e as atividades

administrativas dentro de um processo coerente.

• Estabelecimento de uma engenharia de produto que integre todas as

atividades de engenharia para o desenvolvimento eficiente do produto.

• Estabelecimento de um método de revisão dos produtos de software

para avaliar os defeitos e eficiência.

Os processos chave para o nível 4 estão ligados a métricas qualitativas dos

processos de software e dos produtos de software:

• Gerenciamento dos processos quantitativos para controlar a

performance dos projetos.

• Gerenciamento da qualidade dos produtos de software.

Os processos chave para o nível 5 cobrem os aspectos de como as

organizações e os projetos devem implementar continuamente e aferir as melhorias

nos processos de software:

 35

• Estabelecimento de processos para prevenir defeitos e evitar a

recorrência dos problemas.

• Estabelecimento de processos para identificar mudanças tecnológicas

e transferi-las para os processos de software.

Por conveniência, as práticas que são descritas nos processos chaves são

organizadas por características comuns. Essas características comuns são atributos

que indicam se a implementação e a institucionalização dos processos chaves são

efetivos, repetíveis e duradouros. As cinco características comuns são:

• Compromisso para fazer: descreve as ações que a organização está

tomando para assegurar que o processo está estabelecido e será

permanente.

• Habilidade para fazer: descreve os pré-requisitos que devem existir em

um projeto ou organização para implementar um processo de software

de forma competente.

• Atividades realizadas: escreve as funções e procedimentos

necessários para implementar um processo chave.

• Aferição e análise: descreve necessidade de medir um processo e

analisar os resultados aferidos.

• Inspeção de implementação: descreve os passos para assegurar que

as atividades são realizadas conforme os processos estabelecidos.

Cada processo chave é descrito em termos de práticas chave que contribuem

para atingir o objetivo do projeto. As práticas chave descrevem a infra-estrutura e as

atividades que mais contribuem para uma implementação efetiva e institucionalizada

dos processos chave.

 36

5 METODOLOGIA

Metodologicamente fez-se necessário aprofundar os estudos nos processos

de Gerenciamento de Projetos do PMBOK® Guide 2000, pois o mesmo foi nossa

referência. Posteriormente, foi realizado um estudo nos processos chave em CMM

nível 2.

De posse desses elementos conceituais, iniciamos a implantação do Project

Management Office (PMO), que foi um trabalho realizado em conjunto com o

professor Glêdson Elias e os alunos ligados ao projeto COMPGOV.

Alguns cuidados e providências foram tomados para definir e implantar um

processo de gerenciamento de projetos, baseado no PMBOK. Foi preciso definir o

processo e planejamento da sua implantação, conforme descreveremos com mais

detalhes no ponto seguinte.

5.1 Project Management Office (PMO)

Há quatro estágios pelos quais o laboratório passou para sair da concepção

do PMO com vista a se tornar uma organização madura, dinâmica e produtivamente

gerenciada por projetos.

a) A venda da idéia: primeiro passo consistiu em fazer com que a idéia fosse

compreendida e adotada (“comprada”) pela direção do laboratório COMPOSE, pois

essa foi e é a única forma de garantir o sucesso do programa. A forma se deu

 37

através de exposição da metodologia do PMBOK a ser empregada e os resultados

que poderão ser gerados por ela.

b) Planejamento do Processo de Implantação do PMO: essa fase envolveu

a definição dos processos do PMO e os papéis dos diferentes indivíduos que estão

ativamente envolvidos (stakeholders) no projeto de implantação do PMO.

Definição das políticas e procedimentos para:

• Seleção de Equipes de Projeto e Patrocinadores (sponsors)

• Metodologia Padronizada (CMM nível 2)

• Bases de Dados Integradas

• Implantação do Sistema de Gestão de Projeto

c) Implementação dos Processos do PMO: Nessa fase, foram executados

os programas educacionais necessários em todos os níveis da organização. Foram

colocados em operação os processos e procedimentos necessários para instalação

do PMO.

As principais atividades dessa fase foram as seguintes:

− Disseminação para todos os membros e envolvidos (stakeholders) os

princípios e a metodologia de Gerência de Projetos;

− Implementação das normas e procedimentos com as quais os sponsors

e as equipes de projeto se nortearão.

d) Fase de Implementação: Atualmente o projeto de implantação do PMO

está nessa fase. A implementação é a fase mais difícil e longa do projeto. Nessa

fase, desenvolver-se-á o gerenciamento do projeto, o controle dos prazos e dos

orçamentos. Verificar-se-á se os produtos dos projetos estão dentro dos padrões de

qualidade especificados.
 38

6 CONCLUSÃO

Simplesmente melhorar a maneira como as coisas são feitas não é suficiente.

Essa enorme mudança significa ir além do óbvio, atingindo um segundo nível de

lógica e examinando a situação através de um par de diferentes lentes. Na gestão

empresarial, isso significa ajustar a filosofia gerencial de cima para baixo, para

assegurar que as melhorias propostas em eficiência sejam correspondidas por uma

abordagem estratégica de gerenciamento de projetos em toda a

organização.(DINSMORE, 1998).

Para uma instituição atingir o mais elevado nível de maturidade de software

no CMM, às vezes pode levar anos para obter uma fundação sólida e uma cultura

orientada para melhorias contínuas conforme descrição do processo no nível cinco.

Preocupado com essa realidade, orientado pelo Professor Glêdson, partimos

para implantação de uma estrutura organizacional de gerenciamento de projetos no

laboratório COMPOSE. Nossa proposta de utilizar uma metodologia padronizada de

gerenciamento de projetos, PMBOK® Guide, como instrumento para se almejar uma

futura certificação de CMM nível 2 se mostra coerente, visto que o mesmo têm foco

nos problemas de controle dos projetos de software.

Verificamos que existem outros aspectos que devem ser analisados antes de

uma implementação de uma estrutura organizacional de gerenciamento de projetos

seja tomada. Alguns destes aspectos são: grande envolvimento da alta gerência e

dos demais gerentes com a metodologia de gerenciamento de projetos e com os

benefícios que a nova estrutura trará. E, principalmente, a escolha da adequada

estrutura organizacional de gestão de projetos deve estar conectada com a

 39

estratégia da empresa ou organização, pois este é um fator crítico de sucesso de

uma implementação bem sucedida.

 40

REFERÊNCIAS

BARKI, H.; RIVARD, S.; TALBOT J. An Integrative Contingency Model of Software Project Risk
Management. Journal of Management Information Systems. V. 17, N. 4, p. 37-69, Spring 2001.

BOEHM, B. W. Software Risk Management: Principles and Practices. IEEE Software. V. 8. N. 1.

p. 32-41, Jan. 1991.

DINSMORE, P. C. Winning Business with enterprise project management. New York: AMACOM,
1998.

FAGUNDES, Eduardo M. Capability maturity model for software. Disponível em:

<http://www.efagundes.com/Artigos/CMM.htm>. Acesso em: dez de 2004.

FIORINI, Soeli T.; STAA, Arndt; BAPTISTA, Renan Martins. Engenharia de Software com CMM.
Brasport Livros e Multimídia Ltda. Rio de Janeiro. 1998.

HALLOWS, J.E, The Project Management Office Toolkit. AMACOM. New York. 2002.

KAPLAN, Robert S. David P. Norton. Kaplan e Norton na prática. CAMPUS. Rio de janeiro. 2004

KOONTK, H. e O’DONNEL,C. Os Princípios de Administração: Uma Análise das Funções

Administrativas. São Paulo, Pioneira. 1980

PAULK, Marck C.; CURTIS, Bill; CRISSIS, Mary B. Capbility Maturity Model for software, Version
1.1; Software Engineering Institute, CMU/SEI-93-TR-024, Fevereiro 1993

PRADO, D. Gerenciamento de projetos nas Organizações, Vol-I, Belo Horizonte, FDG. 2000.

Project Management Institute Brazil Minas Chapter (PMI MG). Tradução livre do PMBOK 2000
– Versão 1.0. 2002. 135p.

Project Management Institute Brazil São Paulo Chapter (PMI SP). Referência histórica do PMI.
Disponível em: <http://www.pmisp.org.br>. Acesso em 01 de mar de 2005.

Standish Group. CHAOS Report. 2000. Disponível em: <http://www.standishgroup.com>. Acesso

em 01 de mar de 2005.

SILVA, Sérgio; MARODIN, Helio. A busca da administração por projetos. MYLUS & MARODIN.
Documento Técnico. 2003.

Sisk, T.1998. History of Project Management. Disponível em

<http://office.microsoft.com/downloads/9798/projhistory.aspx>. Acesso em 01 fevereiro de 2005.

SHENHAR, A. J.; DVIR. D. Toward a typological theory of project management. Research Policy,
V. 25, N. 4, p. 607-632, 1996.

TORREÃO, Paula. Project Management Knowledge Learning Environment: ambiente inteligente

de aprendizado para educação em gerenciamento de projetos. Dissertação de Mestrado, local
da defesa Centro de Informática, Universidade Federal de Pernambuco, 2005.

VICENTINO, C.. História Geral. São Paulo, Editora Scipione, 1997.