Gerenciamento De Projetos De Software

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-ncnd/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 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 gerente e seu grupo

entre

o

Organizações imaturas 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 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: . 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: . Acesso em 01 de mar de 2005. Standish Group. CHAOS Report. 2000. Disponível em: . 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 . 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.