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
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.
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?
3-E
S
C
O
P
O
2-P
R
A
Z
O
1-C
U
S
T
O
P R O J E T O
9-I N T E G R A Ç Ã O
5-RH – 6-COMUNICAÇÃO – 7-RISCOS 8-CONTRATOS
• 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?
- 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
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
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).
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 produtoou 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.
Um exemplo de um Termo de Referência – Projeto
BibliotecaSABER-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.
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 - Patrocinador
Data:20/02/06
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
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,
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
− − −
− 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
• 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
− − −
− 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;
− − −
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
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
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.
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.
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.
Planejamento Reuniões Administração Gerência do Projeto Software Documentação de Usuário Materiais do Programa de Treinamento Requisitos do Produto Software Documentação de Usuário Materiais do Programa de Treinamento Detalhes do Projeto Software Documentação de Usuário Materiais do Programa de Treinamento Construção Software Documentação de Usuário Materiais do Programa de Treinamento Integração e teste Produção de Software
• 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
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
Software Treinamento Planejamento Reuniões Prazos Gerência do Projeto Software Documentação de Usuário Requisitos do Produto Módulo Secretaria Módulo Aluno Software Documentação de Usuário Planejamento Programa de Treinamento Detalhes do Projeto Módulo Secretaria Módulo Aluno Software Módulo Secretaria Módulo Aluno Documentação de Usuário Construção Software Documentação de Usuário Materiais do Programa de Treinamento Integração e teste Demonstração Atendimento Personalizado Treinamento Projeto Biblioteca SABER-LER
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.”
• 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?
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.
