As Áreas de Conhecimento da Gerência de Projetos

Livre

0
0
21
1 year ago
Preview
Full text

  

As Áreas de Conhecimento da Gerência de

Projetos

  Projeto é o oposto de rotina. Segundo Harold Kerzner “Trata-se de um empreendimento com um objetivo identificável, que consome recursos e opera sob pressões de prazos, custos e qualidade”. A necessidade de uma gestão de projetos tem se tornado uma realidade muito crescente. Neste contexto de gestão de projetos existem organizações que criam padrões de gerenciamento. Queremos destacar aqui o PMI - Project Management Institute: uma instituição sem fins lucrativos que se dedica ao desenvolvimento da atividade de Gerenciamento de Projetos. Com base na sua missão: “disseminar os conceitos e práticas de Gerenciamento de Projetos e apoiar o desenvolvimento da área de acordo com seus padrões”, o PMI reuniu as melhores práticas consolidadas na área de gestão de projetos em um guia, o PMBOK. Project Management Body of Knowledge (PMBOK) é um padrão de Gerência de Projetos que vem sendo amplamente utilizado e aceito nas mais diversas organizações. E por esse motivo tem se tornado padrão na Gerência de Projetos. Um dos objetivos principais do PMBOK é identificar e descrever as melhores práticas e os conhecimentos utilizados na gestão de projetos, tendo sobre esses conhecimentos e práticas um consenso da sua usabilidade. Além disso, o PMBOK objetiva estabelecer um conjunto de terminologias padrão a serem utilizadas na gestão de projetos. O PMBOK® Guide é dividido em áreas de conhecimento, cada uma contemplando conhecimentos, habilidades e práticas necessárias no gerenciamento de projetos. A versão 2000 do guia contempla as seguintes áreas de conhecimento:

  Gerência de Integração do Projeto: inclui os processos requeridos para garantir que diversos elementos do projeto estão adequadamente coordenados. Gerência do Escopo do Projeto: abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto.

  Gerência de Tempo do Projeto: inclui os processos necessários para assegurar que o projeto será implementado no prazo previsto. Gerência dos Custos do Projeto: inclui os processos necessários para assegurar que o projeto será concluído dentro do orçamento previsto. Gerência da Qualidade do Projeto: inclui os processos necessários para assegurar que o projeto irá satisfazer as necessidades para as quais foi empreendido. Gerência de Recursos Humanos do Projeto: inclui os processos necessários para tornar mais efetivo o uso dos recursos humanos empreendidos no projeto.

  Gerência das Comunicações do Projeto: inclui os processos necessários para garantir a regular e apropriada geração, coleta, disseminação, armazenamento e descarte final das informações do projeto.

9-I

  P R O J E T O N T E G R 3- A 2- E 1- P C S R Ç U C A S Ã O Z T O P O O O 4-QUALIDADE 5-RH Ố 6-COMUNICAđấO Ố 7-RISCOS 8-CONTRATOS

  

Figura 01 – 9 Áreas do Conhecimento em Gestão de Projetos

Gerenciamento de Escopo do Projeto

  A primeira atividade da gestão de projetos de software é a determinação do escopo do software que será desenvolvido. O escopo é definido respondendo-se às seguintes questões: Em qual contexto o software irá ser usado?

  • Quais os objetivos, ou seja: quais informações são requeridas como entrada e quais
  • são geradas como saída?

  Qual a funcionalidade disponível no software? Quais funções estarão disponíveis

  • para transformar um dado de entrada em dado de saída? Qual a performance necessária para estas funções? A determinação do escopo de um software deve possuir dados quantitativos como, por exemplo: quantidade de usuários simultâneos, tempo de resposta máximo admissível. Deve também anotar as restrições e as limitações, por exemplo: o custo do produto restringe o tamanho da memória. Descrever fatores facilitadores também faz parte da definição de um escopo de software. Exemplo de um fator facilitador seria saber que para resolver determinado problema já existem algoritmos bem definidos e devidamente testados. A estratégia de decompor o problema em problemas menores é muito útil neste contexto. Quando nos deparamos com problemas complexos usamos a estratégia “dividir para conquistar”.

  Como obter informação necessária para o escopo

  O analista deve começar utilizando um conjunto de perguntas que levarão ao entendimento básico do problema, do pessoal envolvido com o problema e da solução almejada. A esses tipos de questões chamamos questões de contexto livre que são sugeridas por Gause e Weinberg.

  O primeiro bloco de questões dever focalizar o cliente. Veja alguns exemplos: Quem está por trás da solicitação deste trabalho? - Quem vai usar a solução? - Qual será o benefício econômico de uma solução bem sucedida? - Há outra fonte para solução? -

  O segundo conjunto de questões de contexto livre deve permitir ao analista entender melhor o problema e ao cliente manifestar suas percepções sobre a solução vislumbrada:

  Como você (cliente) caracterizaria uma boa saída, gerada por uma solução bem - sucedida? Que(ais) problema(s) a solução vai resolver? - Você pode me mostrar ou descrever o ambiente no qual a solução será usada? -

  • Existem aspectos especiais de desempenho ou de restrições que afetarão o modo pelo qual a solução é abordada? O terceiro e último bloco de questões focaliza a efetividade da reunião:

  Você é a pessoa adequada para responder a essas questões? As respostas são - oficiais? As questões são relevantes ao problema que você tem? -

  • Eu estou fazendo perguntas demais?
  • Alguém mais pode dar informação adicional?
  • Eu deveria perguntar-lhe mais alguma coisa? Todas essas questões são muito importantes para iniciar o processo de comunicação que é extremamente necessário para que se defina o escopo do projeto. Porém reuniões do tipo perguntas e respostas devem acontecer apenas no primeiro encontro. As próximas reuniões devem combinar elementos de solução de problemas, negociação e especificação.

  ®

  Segundo o PMBOK GUIDE 2000, a Gerência de Escopo do Projeto abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto.

  Os principais processos da gerência de escopo do projeto são:

  1. Iniciação

  2. Planejamento do Escopo

  3. Detalhamento do Escopo

  4. Verificação do Escopo

  5. Controle de Mudanças do Escopo

  Deseja-se também com o gerenciamento de escopo de um projeto controlar todos os trabalhos a serem realizados no projeto de forma que o produto ou serviço a ser desenvolvido não quebre nenhuma regra previamente estabelecida, a essas regras chamamos premissas.

  O termo escopo é utilizado na gerência de projeto para tratar tanto o produto quanto o projeto. Assim sendo o escopo do produto trata aspectos e funções que caracterizam o produto ou serviço. Já o escopo do projeto trata o trabalho que dever ser feito para fornecer um produto em concordância com as especificações feitas.

  É importante que o leitor não confunda definição de escopo do projeto com levantamento de requisitos do software. Levantamento de requisitos do produto trata de obter as características do sistema ou a descrição do que o sistema será capaz de realizar, para atingir seus objetivos. Ou seja, levantar os requisitos tem por objetivo compreender o que os clientes e usuários esperam que o sistema realize. Independente do modelo escolhido para o processo de desenvolvimento de software sempre estará presente a atividade de identificação de requisitos. Podemos dizer que durante a definição de escopo acaba sendo levantado alguns requisitos, porém a definição do escopo vai além. Como exemplo podemos citar a definição de quantidade de pessoas que irão trabalhar no projeto. Isso é escopo de projeto mas não é levantamento de requisitos do produto Deve-se estar atento para não construir um gerenciamento de escopo exageradamente detalhado para que seu gerenciamento não seja complexo em demasia.

1. Iniciação

  Este é um processo formal do gerenciamento de escopo. Seu objetivo é formalizar a existência de um novo projeto.Um processo de iniciação de um projeto surge devido a algumas oportunidades, como por exemplo, uma demanda de mercado, uma necessidade do negócio, um pedido do cliente, um avanço tecnológico, uma exigência legal ou uma necessidade social.

  Sendo de caráter formal, o processo de iniciação tem como resultado um documento, que pode ser o contrato firmado entre contratante e contratado, ou o termo de referência. Termo de Referência, ou Project Charter é um documento de caráter legal onde é feito o reconhecimento de um projeto. Este documento tem as bases para que o gerente de projeto possa desenvolver seu trabalho. Segundo Vargas um termo de referência deve conter:

  Título do projeto;

  • Um resumo das condições que definem o projeto (introdução);
  • Nome do gerente de projeto e suas responsabilidades e autoridades;
  • Necessidades básicas do trabalho a ser realizado (por exemplo, compras de software
  • e hardware, treinamento de pessoal) Descrição do produto do projeto, ou seja, que produto final será gerado.
  • Cronograma básico do projeto;
  • Estimativas iniciais de custo;
  • Necessidades iniciais de recursos (por exemplo, uma equipe de 8 profissionais,
  • máquinas e/ou outros equipamentos)

  Necessidade de suporte pela organização, ou seja, descrever que tipo de suporte será

  • necessário ter da organização (por exemplo, a organização irá suportar toda necessidade que não puder ser atendida internamente);

  Controle e gerenciamento das informações do projeto. Implica em descrever quem

  • será o responsável em controlar e gerenciar as informações do projeto.Geralmente será o gerente de projeto. Sugere-se ter um banco de dados que centralize essas informações;

  Aprovações com assinatura do executivo responsável pelo documento ( elemento

  • externo ao projeto). Deve-se descrever nesta fase do gerenciamento do escopo as restrições e as premissas. Restrições são fatores que limitarão as opções da equipe de gerência do projeto. Exemplos de restrições: orçamento limitado, prazo limite é o final do ano fiscal da empresa, sob risco
de re-alocação orçamentária. Já premissas são fatores que são considerados verdadeiros, reais ou certos. Exemplos de premissas: “A comunicação dentro do time será feita através do site www.projetogestãovirtual.com.br com utilização do Microsoft Project”, “É necessário o apoio irrestrito de todos os envolvidos dentro da divisão”, “Os membros do time terão dedicação integral ao projeto”. A construção do termo de referência e a definição das restrições e das premissas são feitos com base nas informações da descrição do produto ou serviço que o projeto irá criar. Esta descrição deverá relatar não somente as características do produto ou serviço como também a relação entre este e a necessidade do negócio. O produto ou serviço deve ser detalhado o suficiente para auxiliar no planejamento do projeto. Outros dados que são relevantes na construção dos documentos do processo de iniciação são as informações históricas. Resultados de todas de decisões sobre seleção de projetos anteriores e de desempenho de projetos, devem ser consideradas e avaliadas.

  Biblioteca Um exemplo de um Termo de Referência – Projeto SABER-LER

  

PROJETO BIBLIOTECA SABER - LER

TERMO DE ABERTURA

PROJECT CHARTER

  Preparado por José Antunes Gomes - Patrocinador Vesão 1 Aprovado por José Antunes Gomes - Patrocinador 20/02/06

I. Resumo das condições do projeto

  A escola de ensino fundamental e médio SABER, em função do crescente números de alunos , percebeu que o controle de empréstimos de sua biblioteca está ficando de difícil gestão e vários erros estão sendo cometidos devido ao ineficiente controle feito através fichas e relatórios manuscritos. Diante deste quadro a escola decidiu contratar os serviços da casa de Software LA para a construção de um programa que atendesse a todas as necessidades da sua biblioteca.

II. Nome do gerente do projeto, suas responsabilidades e sua autoridade Deisymar Botega Tavares é a gerente do projeto.

  Possui autoridade total no que diz respeito ao projeto em questão, podendo: selecionar as pessoas adequadas para o projeto, desenvolver as estimativas de custos, prazos, qualidade e risco, desenvolver alternativas de backup, manter as modificações sob controle, estipular as prioridades do projeto e gerenciar o pessoal conforme seus critérios. No aspecto financeiro, o gerente tem sua autoridade limitada pelas definições a serem feitas no plano de gerenciamento de custo que terá a supervisão do gerente financeiro da Software LA.

  III. Necessidades básicas do trabalho a ser realizado Será necessária a aquisição de uma máquina servidora e quatro terminais de acesso. Um deles para uso da secretária da biblioteca e os demais serão disponibilizados que os alunos realizem suas consultas ao acervo. Será necessário também o treinamento dos funcionários da biblioteca no uso do software desenvolvido tanto da parte da secretária quanto do módulo de consulta disponibilizado aos alunos.

IV. Descrição do projeto 1. Produto do Projeto

  Um software que gerencie os processos da biblioteca: empréstimos, devoluções, reservas, consultas ao acervo e relatórios que permitam controlar as diversas situações desses processos. Faz parte também do produto do projeto o manual de uso do sistema.

2. Cronograma básico do projeto

  O início do projeto será na primeira semana de março de 2006 e deverá durar aproximadamente 2 meses.

3. Estimativas iniciais de custo

  O custo médio esperado para este projeto e’de R$800,00 considerando todos os tipos de despesas relevantes para a empresa desenvolvedora ( pessoal, despesas básicas, traslados, depreciação de equipamentos).

V. Administração 1. Necessidade inicial de recursos

  O gerente do projeto necessitará de uma equipe de 2 profissionais, sendo um analista e um programador. Não será necessário adquirir máquinas ou software para o desenvolvimento do projeto.

  2. Necessidade de suporte pela organização

  A empresa LA irá suportar toda necessidade extra que por ventura venha surgir em relação ao desenvolvimento do projeto em questão, uma vez que existe a possibilidade de expansão do projeto para outras escolas da rede SABER.

  3. Controle de gerenciamento das informações do projeto

  O gerente do projeto é responsável por essas informações. Todas as informações devem ser armazenadas em um banco de dados e acessadas pelo site

  www.softwarela.gpdeisy/bibliotecasaberler

Aprovações

  José Antunes Gomes - Data:20/02/06

  Patrocinador

  Nota: quaisquer alterações neste documento deverão ser sobmetidas ao processo de

  controle através do site: www.softwarela.gpdeisy/bibliotecasaberler OBS: exemplo baseado na estrutura apresentada no livro Manual Prático do Plano de de Ricardo Vargas.

  Projeto

2. Planejamento do Escopo

  O planejamento do escopo é um processo que tem por objetivo elaborar e documentar todo o trabalho do projeto (escopo do projeto) de forma progressiva. O escopo do projeto que é criado durante este processo será utilizado como base para futuras decisões do projeto, tendo principalmente critérios para avaliar se o projeto, ou uma fase dele foi desenvolvido com sucesso. A descrição do produto, o termo de referência e a definição inicial das premissas e restrições são as entradas iniciais para o desenvolvimento do planejamento do escopo. Com essas informações de entrada são produzidos os documentos que chamamos de saídas do planejamento do escopo:

  Declaração do escopo;

  • O plano de gerenciamento de escopo
  • 2.1. Declaração do escopo

  É o documento que servirá de base para decisões futuras no projeto uma vez que ele formaliza o escopo de todos os trabalhos a serem desenvolvidos no projeto. Com o desenvolvimento do projeto, a declaração do escopo poderá ser revisada conforme necessidades surgidas através de mudanças aprovadas no escopo do projeto. Itens que normalmente compõem uma declaração de escopo:

  Título do projeto; − − − −

  Nome da pessoa que elaborou o documento; − − − −

  Nome do patrocinador; − − − −

  Nome do gerente do projeto e suas responsabilidades e autoridades; − − − −

  Nome dos integrantes do time do projeto; − − −

  Descrição do projeto; − − − −

  Objetivo do projeto: os objetivos do projeto devem incluir, no mínimo, custo, − − − − cronograma e medidas de qualidade. É importante ter cuidado com objetivos que não podem ser mensurados, por exemplo um objetivo descrito com “satisfação do cliente” representa um alto risco para um término com sucesso. Um exemplo completo de uma descrição de objetivo do projeto: “Implementar o controle financeiro no setor financeiro da empresa XY seguindo as especificações feitas na descrição do produto, dentro de um prazo máximo de 150 dias úteis a partir de agosto de 2005 e com um custo total estimado de $ 200”.

  Justificativa do projeto: os requisitos do negócio que o projeto irá atender; − − − −

  Produto do projeto: um breve resumo da descrição do produto; − − −

  Subprodutos do projeto: seriam principais subprodutos de um projeto de − − − − desenvolvimento de software: um manual de usuário e um tutorial interativo;

  Expectativa do cliente/patrocinador: seriam exemplos de expectativa do cliente: − − − − projeto em conformidade com o Termo de Referência, e, projeto dentro do prazo e custo previsto;

  Fatores de sucesso do projeto: citar pontos, características que o produto irá possuir − − − − e que será de grande receptividade pelos seus usuários. Por exemplo, tarefas que antes eram muito trabalhosas e que com o produto desenvolvido será muito mais prática de ser desenvolvida;

  Restrições: citar mais restrições além das descritas na fase de iniciação; − − − −

  Premissas: citar mais premissas além das descritas na fase de iniciação; − − − −

  Exclusões específicas ( tudo o que não será abordado pelo projeto); − − − −

  Principais atividades e estratégias do projeto: relata-se neste item estratégias e − − − − atividades que serão realizadas no projeto. Por exemplo, um projeto poderá ter uma estratégia a nível de diagnóstico e estabelecer que o projeto terá um acompanhamento de um consultor externo. Ou então estabelecer que despesas com deslocamentos, traslados e hospedagem serão arcadas pela empresa contratante. É neste item também que devem ser feitas especificações de software e hardwares que serão necessárias para que o projeto possa ser utilizado após a sua conclusão. Poderá descrever também possíveis treinamentos a serem realizados pela empresa contratada para que o contratante possa aprender a utilizar o produto.

  Principais entregas do projeto: citar os marcos que representam um subproduto − − − − entregue. Por exemplo: treinamento concluído, software instalado, piloto realizado e avaliado.

  Orçamento básico do projeto: citar previsões de gastos e descrever restrições com − − − − relação ao orçamento ( por exemplo: antecipação ou atrasos não deslocam fluxo de caixa do projeto);

  Plano de entregas e marcos do projeto: deve ser montado um quadro com as fases − − − − do projeto, datando a entrega de cada item relevante da fase. Por exemplo, na fase de planejamento pode-se datar quando será a entrega do cronograma, do orçamento e do plano de projeto. Na fase de execução pode-se datar etapas como treinamento, instalação do hardware, entrega do piloto etc.

  Registro de alterações no documento: consta de uma tabela onde são registradas as − − − − alterações feitas neste documento, sendo necessário destacar data de alteração, nome do responsável pela alteração e descrição da mudança realizada; Aprovações: assinatura do responsável pela aprovação e data.

  − − − −

2.2. O plano de gerenciamento de escopo

  O plano de gerenciamento de escopo descreve como o projeto será gerenciado. Gera-se com esta descrição, um documento formal onde deverão estar documentadas os seguintes itens: − − − − Título do projeto; − Nome da pessoa que elaborou o documento; − − − − Regras gerais dos processos de gerenciamento do escopo. Algumas possíveis regras a − − − serem definidas nesse item seriam:

  • Estabelecer como serão tratadas as medidas corretivas, as inovações e as novas características do produto/projeto que por ventura surgirem. Uma estratégia seria considerar como mudança de escopo apenas a medidas corretivas. .Inovações e novas características não seriam consideradas pelo gerenciamento de escopo.
  • Estabelecer quais documentos serão a base para o gerenciamento do escopo ser realizado.
  • Estabelecer como deverão ser solicitadas mudanças no escopo (exemplo: por escrito e enviado por email ao gerente de projeto).

  − Priorização das mudanças e respostas: para cada mudança ocorrida deve-se atribuir um − − − grau de prioridade que indicará que tipo de ação será tomada (imediata, , não imediata ). Um exemplo de classificação de prioridade para as mudanças de escopo é mostrado nos itens abaixo:

  • Prioridade 0 – para mudanças urgentes, de alto impacto no projeto e em outras áreas que não são de autonomia do gerente de projeto. Esse tipo de mudança requer ação imediata.
  • Prioridade 1 – são mudanças que também requerem uma ação imediata devido a seu caráter de urgência. Deve ser acionada a figura do contratante (patrocinador do projeto) no caso de mudanças de ordem financeira que fuja a alçada do gerente do projeto.
  • Prioridade 2 – são mudanças que incorporam valor ao sucesso do projeto, são urgentes e não têm impacto significativo nos custos e prazos do projeto. Para esse tipo de mudança deve ser montado um planejamento de ações .
  • Prioridade 3 – são mudanças que têm influência no sucesso do projeto, mas não são urgentes. Esse tipo de mudança deve ser implementada mas não requer ação imediata.

  − Sistema de controle de mudanças: este sistema de controle deve proporcionar que todas − − − as mudanças no escopo do projeto sejam tratadas como o fluxo mostrado na Figura 2. − Freqüência de avaliação do escopo: deve-se estabelecer com que freqüência será − − − avaliado o escopo do projeto; − − Alocação financeira das mudanças do escopo: especificar onde serão obtidos os − − recursos financeiros gerados pelas mudanças de escopo; − Nome do responsável pelo projeto; − − − − − Freqüência de atualização do plano de gerenciamento do escopo: deve-se estabelecer − − com que freqüência será atualizado o plano de gerenciamento do escopo;

  − − Outros assuntos relacionados ao gerenciamento do escopo do projeto não previsto neste − − plano: deve-se estabelecer que procedimentos serão tomados nesses casos ( por exemplo: todas as solicitações não previstas neste plano deverão ser submetidas ao comitê de controle de mudanças); − Registro de alterações no documento: consta de uma tabela onde são registradas as − − − alterações feitas neste documento, sendo necessário destacar data de alteração, nome do responsável pela alteração e descrição da mudança realizada; − − − − Aprovações: assinatura do responsável pela aprovação e data.

  INÍCIO Solicitação de mudanças Análise da mudança solicitada

  Medida corretiva ou inovação ? Impacto no sucesso do projeto.

  Urgência da mudança Impacto nos custos e/ou Prazos do projeto

  Impacto em outras áreas Prioridade 3 Prioridade 2

  Prioridade 1 Prioridade 0 Alto Alto

  Urgente Alto Correção Áreas afetadas

  

Medida corretiva ou inovação

Impacto nos custos Impacto na qualidade Impacto nos prazos Impacto nos riscos Relatório de

  Mudanças Inovação Renegociar

com o

patrocinador

ou ignorar

  Baixo Ignorar Não urgente Baixo Baixo

  Figura 2 – Fluxo de mudanças no escopo do projeto.

3. Detalhamento do Escopo

  Detalhamento do escopo é um processo no qual se faz a subdivisão dos principais subprodutos do projeto que foram identificados na declaração do escopo. Com essa subdivisão são gerados componentes menores e mais manejáveis. Essa subdivisão trás algumas vantagens, como por exemplo melhorar a precisão das estimativas de custo, tempo e recursos. Além disso, facilita a atribuição clara de responsabilidades uma vez que os subprodutos estão mais bem definidos.

  Detalhamentos inadequados podem implicar em projetos com custo final mais elevado por causa das inevitáveis mudanças que geram retrabalho, comprometendo prazos e diminuindo a produtividade. Para realização deste processo de detalhamento do escopo são utilizadas as informações contidas na declaração do escopo, nas premissas, nas restrições, em outras saídas de planejamento e em informações históricas. Outras saídas de planejamento seriam saídas de processo de outras áreas de conhecimento que possam causar impactos no detalhamento do escopo do projeto. No contexto de informações históricas devem ser úteis as informações referentes a erros e omissões que ocorreram em outros projetos.

  Como resultado desse processo de detalhamento do escopo são geradas a EAP ( estrutura analítica do projeto) e as devidas atualizações na declaração do escopo. A estrutura analítica do projeto é um agrupamento de componentes do projeto que organiza e define o escopo total do projeto. Uma das abordagens mais comuns na construção da EAP é a decomposição. A abordagem por decomposição compreende subdividir os principais subprodutos do projeto em componentes menores até que estes subprodutos estejam detalhados o suficiente para que possam passar pelas fases do projeto: planejar, executar, controlar e fechar. Passos principais para que seja realizada a decomposição:

  I. Identificar os principais subprodutos do projeto. É importante lembrar que o próprio gerenciamento do projeto terá que fazer parte deste processo de decomposição. O primeiro nível da decomposição deverá ser as fases do ciclo de vida do projeto. Num segundo nível virá os subprodutos. Veja figura ilustrativa (Figura 3). Para cada subproduto, quando existir detalhe suficiente deve-se prosseguir até o passo IV, caso contrário segue-se até o passo III.

  

Produção de Software

Versão 5.0

Gerência do Requisitos do Detalhes do Construção Integração Projeto Produto Projeto e teste

  

Planejamento Software Software Software Software

Reuniões Documentação Documentação Documentação Documentação de Usuário de Usuário de Usuário de Usuário

Administração Materiais do Materiais do Materiais do Materiais do

  Programa de Programa de Programa de Programa de Treinamento Treinamento Treinamento Treinamento

  Figura 3. Exemplo de uma Estrutura Analítica de Projeto, organizada por fase. Esta EAP é somente ilustrativa.

  II. Quando possível, estabelecer de forma adequada as estimativas de custo e prazo para cada subproduto.

  III. Identificar os elementos constituintes do subproduto. Esses elementos constituintes devem ser descritos em termos de resultados tangíveis e verificáveis.

  Resultados tangíveis e verificáveis podem incluir tanto serviços quanto produtos (por exemplo, relatório da situação poderia ser descrito como relatório semanal da situação). Tem-se que repetir o passo II para cada elemento constituinte.

  IV. Verificar a exatidão da decomposição, para isso deve-se questionar os seguintes itens: Os itens mais baixos são necessários e suficientes para a conclusão do item decomposto? Se não, os elementos constituintes devem ser modificados.

  Cada item está definido de forma clara e completa? Se não as descrições

  • devem ser revisadas.

  Para cada item pode-se fazer um cronograma e um orçamento adequados?

  • Se não, fazer revisões para possibilitar o controle necessário.

  É importante ressaltar que a EAP não deve ser confundida com outros tipos de estruturas de decomposição usadas para apresentar informações do projeto. Alguns exemplos seriam: estrutura analítica do projeto contratual ( Contractual EAP), estrutura de decomposição organizacional (OBS), estrutura de decomposição de recurso (RBS), lista de materiais (BOM), estrutura de decomposição de projeto (PBS).

  Um exemplo de uma Estrutura Analítica de Projeto EAP - Projeto Biblioteca SABER-LER Projeto Biblioteca SABER-LER Versão 5.0

Gerência do Requisitos do Detalhes do Construção Integração Treinamento

Projeto Produto Projeto e teste Planejamento Software Software Software Software Demonstração Reuniões Documentação Documentação Programa de Treinamento Módulo Aluno Módulo Aluno Software Módulo Secretaria Módulo Secretaria Documentação Documentação Atendimento de Usuário de Usuário Personalizado Materiais do Prazos Planejamento Treinamento Programa de de Usuário de Usuário Treinamento Módulo Secretaria

  Módulo Aluno

4. Verificação de Escopo

  Segundo o PMBOK GUIDE 2000, Verificação de Escopo é o processo que formaliza a aceitação do escopo do projeto pelas partes envolvidas. Faz-se necessário então uma revisão dos produtos e resultados do trabalho para garantir que tudo foi completado de forma correta e satisfatória. Em caso de término prematuro do projeto, a verificação do escopo deve estabelecer e documentar o nível e a extensão do que foi concluído.

  Veja listado abaixo alguns dos documentos que são utilizados como entrada para este processo: Resultados do trabalho: quais subprodutos foram total ou parcialmente

  • completados.

  Documentação do produto: todos os documentos que foram produzidos com o

  • objetivo de descrever os produtos serão utilizados para verificação do escopo.

  Estrutura analítica do projeto (EAP).

  • Declaração do Escopo.
  • A saída gerada após inspeções feitas nos documentos disponíveis é a aceitação formal: documentação de que o cliente ou patrocinador aceitou o produto. Tal aceitação poderá ser condicional quando for referente a um produto parcial (subproduto da fase do projeto).

5. Controle de Mudanças do Escopo

  Segundo o PMBOK GUIDE 2000, “O controle de mudanças do escopo consiste em (a) influenciar os fatores que criam mudanças no escopo para garantir que as mudanças sejam discutidas e combinadas (b) determinar que uma mudança no escopo ocorreu, e (c) gerenciar a mudanças efetivas quando ocorrerem.”

  Como entrada para realização desse processo de controle são utilizados os seguintes documentos e ou eventos: estrutura analítica do projeto (EAP), relatórios de desempenho, requisições de mudanças e o plano de gerenciamento do escopo. Os relatórios de desempenho contêm informações sobre o desempenho do escopo como por exemplo: quais subprodutos que foram completados ou não. As requisições de mudança podem ser feitas de forma oral, escrita, ter sido gerada interna ou externamente, ter sido imposta por ordem legal ou surgido de forma opcional. Quando necessidades de mudanças ocorrem é devido a:

  Um acontecimento externo como, por exemplo, de uma mudança de

  • regulamentação;

  Um erro ou omissão no detalhamento do escopo do projeto, por exemplo: construir

  • uma lista de material ao invés de uma EAP;

  Uma mudança no valor agregado. Isso ocorre quando uma nova tecnologia surge

  • depois que o escopo do projeto foi definido e esta é capaz de reduzir custo, por exemplo; Implementação de um plano de contingência quando um evento de risco acontece.
  • A partir da análise dessas entradas são geradas as seguintes saídas para o controle de mudanças do escopo:

  I. Mudanças de Escopo: qualquer alteração feita no escopo do projeto, desde que negociada e aprovada conforme a EAP. Todos os ajustes necessários em outras partes deverão ser feitos, por exemplo, ajuste de orçamento, prazo, dentre outros.

  II. Ações Corretivas: são ações que buscam o curso do projeto de forma compatível ao estabelecido no plano do projeto.

  III. Lições Aprendidas: deve-se documentar todas as informações que possam formar um banco de dados histórico para ser usado no projeto atual e em futuros projetos.

  Esse banco deverá conter, dentre outras lições aprendidas, as causas das mudanças e as razões por trás das ações corretivas.

  Viabilidade de um projeto de Software

  Depois de definido o escopo do software deve ficar atento às questões de viabilidade. O projeto proposto é exeqüível? Muitas vezes nem se questiona essa possibilidade. Porém tem-se que ficar atento a quatro dimensões para avaliar possibilidade de execução de um projeto:

  • Tecnologia: o projeto é exeqüível tecnicamente?
  • Finanças: o projeto é exeqüível financeiramente? O custo total do desenvolvimento do projeto é um custo que o cliente ou o mercado pode pagar?
  • Tempo: o prazo para o projeto chegar ao mercado vai vencer a concorrência?
  • Recursos: a organização tem os recursos necessários para obter sucesso? Para projetos que você já tenha feito algum parecido, chegar a uma resposta para essas perguntas é fácil e não demanda muito tempo. Porém se o projeto for algo totalmente novo
uma equipe pode gastar até meses descobrindo quais são os requisitos principais e difíceis de implementar no novo sistema. Isso implica que chegar a uma resposta para essas questões é bem mais trabalhoso. E quando se obtém respostas negativas às perguntas, uma redução dos requisitos pode ser necessária e negociada.

  Referências Bibliográficas

  GAUSE, D.C. and G.M. WEINBERG. Exploring Requirements: Quality Before Design, Dorset House, 1989. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) -- 2000 Edition. ISBN 1880410230 Elaboração e Gestão de Projetos © 2005 Ítalo de Azeredo Coutinho PRESSMAN, R. Engenharia de Software. Makron books, 2002.

  VARGAS, R. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos. 6a ed. Rio de Janeiro: Brasport, 2005.

  VARGAS, R. Manual Prático do Plano de Projeto. . 1a ed. Rio de Janeiro: Brasport, 2003.

Novo documento