CAPÍTULO VI Modelo de Gerenciamento de Projeto Proposto
6.3 Composição do MGP Proposto
6.3.6 Modelos de Documentos
Estes modelos de documentos devem ser utilizados no processo de GP. Devem ser devidamente armazenados pois contêm os compromissos da equipe do projeto e dos clientes com relação ao projeto.
O principal documento relativo à gerência de projetos é o plano do projeto e é importante a participação das partes interessadas no desenvolvimento do mesmo pois, será o
“plano de todos”. As informações contidas no plano apresentado no Quadro 01 foram baseadas no plano de projeto de software apresentado por Pressman (1995).
Quadro 01. Plano do Projeto.
Empresa ABC Plano do Projeto P I. Introdução
1. Escopo e propósito do documento 2. Objetivos do projeto
a. Objetivos
b. Funções principais c. Questões de desempenho
d. Restrições técnicas e administrativas 3. Definições e Acrônimos
II. Organização do projeto
1. Limites e Interfaces da Organização 2. Estrutura Organizacional para o projeto
3. Mapa de Responsabilidade Linear (MRL) III. Estimativas de projeto
1. Dados históricos usados nas estimativas 2. Técnicas de estimativa
3. Estimativas
IV. Plano de Gerenciamento de Riscos V. Cronograma e Orçamento
1. WBS com todas as tarefas do projeto (suporte, treinamento, documentação, gerenciamento de configuração, garantia de qualidade, tarefas que poderão ter reuso de componentes, aquisição de bens e serviços, integração, instalação, monitoramento e controle de riscos, monitoramento e controle da qualidade, monitoramento e controle de stakeholders)
2. Gráfico de timeline (Gráfico de Gantt)
3. Definição dos RH e materiais necessários para cada uma das tarefas
4. Definição dos custos relacionados a cada uma das atividades e materiais utilizados VI. Recursos do projeto
1. Pessoal - Qtde de cada Habilidade/Treinamento/Conhecimento Necessários 2. Hardware e software - Qtde de cada tipo de Material Necessário
3. Recursos especiais - Qtde de cada tipo de Recurso Especial VII. Mecanismos de rastreamento e controle
1. Relatórios a serem entregues e destinatários VIII. Apêndices
O plano de projeto deve conter:
(a) A estrutura de divisão de trabalho com a descrição de todas as atividades do projeto, incluindo: as atividades referentes à documentação do projeto que irá fazer
parte do help do software e, as atividades de GP que devem ser explicitamente colocadas pois consomem até 25% do orçamento total do projeto (COREY et al., 2001);
(b) O cronograma do projeto com o tempo, o responsável e o custo de cada atividade;
(c) O plano para gerenciamento dos riscos. Em um projeto realmente grande, o plano deve estabelecer procedimentos para lidar com as situações difíceis, pois elas certamente ocorrerão ao longo dos meses em que o projeto estará em execução (COREY et al., 2001). Por isso, é necessário fazer um planejamento dos riscos no qual teremos um plano de contingência para cada um deles caso ocorram;
(d) Os produtos a serem entregues, relatórios semanais e reuniões (COREY et al., 2001);
(e) O plano de entrega/instalação do software que, dependendo do contrato, poderá envolver atividades para a instalação de um conjunto de softwares básicos necessários para que o software desenvolvido seja instalado e executado com boa performance. Além disso, são necessárias atividades de treinamento do usuário e de instalação do banco de dados.
O Plano de Gerenciamento de Riscos faz parte do Plano do Projeto e está apresentado no Quadro 02. Este plano foi baseado nas informações necessárias para o devido gerenciamento de riscos apresentado por Cleland e Ireland (2002), no qual, é necessário a identificação dos riscos, a quantificação dos riscos, a eliminação ou redução dos riscos e o planejamento de contingência de cada risco.
Quadro 02. Plano de Gerenciamento de Riscos.
Empresa: ABC
Plano de Gerenciamento de Riscos Projeto:
Data Inicio:
Descrição Probabilidade de ocorrer Conseqüência Plano de contingência
do Risco Custo e Tempo
Para os dados mais importantes ou sigilosos que não tem uma definição de responsabilidade/autoridade bem definida, para evitar confusões, um Plano de Gerenciamento de Dados é bem útil para se mostrar o devido cuidado que se deve ter com relação a eles.
Manter as informações apresentadas no Quadro 03 está em conformidade com o estabelecido no CMMI Staged-Nível 2. Os dados contidos neste plano, podem ser as métricas para o GP.
Quadro 03. Plano de Gerenciamento de Dados.
Empresa: ABC
Plano de Gerenciamento de Dados
Dados/Informações:
a) Quem e Quando Armazenar b) Quem e Quando Recuperar c) Quem e Quando Reproduzir d) Quem e Quando Distribuir
O Plano de Gerenciamento de Stakeholders apresentado no Quando 04 é importante nos casos onde eles podem impactar o projeto exercendo qualquer tipo de influência nos resultados do projeto. Alguns projetos foram comprometidos por ambientalistas que atrasaram a elaboração e construção de usinas nucleares e comunidades que impediram a construção de rodovias para preservar patrimônios históricos, entre outros. Nos projetos de software, podemos ter um ambiente não favorável à implantação do software, por exemplo quando este software trará conseqüências de demissão de funcionários. Para um ADDS deve-se formalizar a questão do gerenciamento de stakeholders que deve focar principalmente os stakeholders da organização na qual se pretende instalar o software. O gerenciamento deve ser iniciado o mais cedo possível para evitar barreiras de implantação e utilização do software.
Quadro 04. Plano de Gerenciamento de Stakeholders.
Empresa: ABC
Plano de Gerenciamento de Stakeholders Projeto:
Data Início:
Nome Responsável:
Stakeholder Objetivo Interesse no Projeto Quando Contatar Por que contatar
Para fornecer o treinamento que a organização necessita, é preciso conhecer o perfil dos usuários dentro da organização. Para isso, é necessário que se mantenha um controle sobre os perfis (conhecimentos, habilidades e treinamentos) já existentes dentro da organização. Uma visão resumida como apresentada no Quadro 05.
Já a necessidade de documentos para realizar o gerenciamento de requisitos foi identificada e apresentada no MGP para realizar as práticas e subpráticas sugeridas pelo CMMI Staged Nível 2. Os modelos de documentos necessários para o gerenciamento de requisitos são: compromisso com os requisitos, solicitação de mudança nos requisitos e inconsistências nos requisitos.
Quadro 05. Habilidades/Conhecimentos/Treinamentos dos Membros da Organização.
Empresa ABC
Habilidades/Conhecimentos/Treinamentos dos Membros da Organização
Habilidades:
Descrição da Habilidade Nível Qtde de Membros que Possui em Cada Local Conhecimentos:
Descrição do Conhecimento Nível Qtde de Membros que Possui em Cada Local Treinamentos:
Descrição do Treinamento Nível Qtde de Membros que Possui em Cada Local
Para entender os requisitos, um documento como o do Quadro 06 é necessário. As informações neste documento compreendem uma lista dos requisitos, seus fornecedores e o tipo do fornecedor de requisito que pode ser o usuário ou o cliente. Deve-se tomar o cuidado para identificar os melhores fornecedores de requisitos. Uma avaliação do fornecedor do requisito deve ser realizada para verificar se ele está em condições de fornecer o requisito (possui experiência necessária, conhece o domínio do requisito envolvido) e, depois, caso o fornecedor seja aprovado, o requisito é verificado na sua completude e entendimento. A concordância dos Stakeholders, principalmente dos clientes e ,do responsável pela obtenção dos requisitos fornecerá o compromisso ou responsabilidade sobre os requisitos.
Quadro 06. Documento de Compromisso com os Requisitos.
Empresa: ABC
Compromisso com os Requisitos ou DRS (Documento de Requisito de Software) Projeto:
Cliente:
Nome do Fornecedor do Requisito, Tipo do Fornecedor do Requisito, Avaliação do Fornecedor do Requisito (Aprovado ou Não), Requisito, Avaliação do Requisito (Completo, Incompleto),
Concordância dos Stakeholders Local, data e hora
Assinatura dos Stakeholders:
Glossário em anexo
Quando houver alteração nos requisitos deve-se refazer o Documento de Compromisso com os Requisitos para mantê-lo completo e atualizado. O documento completo deve ser revisado pois um requisito pode alterar outro (Ex.: se tivermos 2 requisitos, cadastramento de fornecedores, e emissão de relação de fornecedores e se o primeiro for eliminado ou tiver seus atributos alterados, o segundo também deverá ser eliminado ou
alterado). Para manter o documento atualizado, pode-se utilizar uma matriz de rastreamento de requisitos deve ser criada para manter o estado dos requisitos, e armazenar um histórico de mudanças de requisitos juntamente com a justificativa para as mudanças e o impacto das mudanças.
Quadro 07. Documento para Solicitação de Mudança nos Requisitos.
Empresa: ABC
Documento para Solicitação de Mudança nos Requisitos Projeto:
Cliente:
Data Solicitação: Hora Solicitação:
Fornecedor da Mudança nos Requisitos Tipo de Fornecedor Requisito Assinatura do Cliente:
Data Recebimento da Solicitação: Hora Recebimento da Solicitação:
O documento para solicitação de mudança nos requisitos, como mostra o Quadro 07, será usado quando o cliente quiser fazer uma alteração ou inclusão de um requisito. Quando do recebimento do documento pela organização, deve-se preencher a data e hora do recebimento para que a alteração seja devidamente cadastrada no repositório.
Nos marcos determinados pelo processo utilizado, será realizada a verificação de inconsistências nos requisitos para monitorar e controlar os requisitos e caso seja identificada alguma inconsistência, isso deverá ser registrado no modelo de documento apresentado no Quadro 08. Isso é feito pelo confronto dos mesmos com os produtos desenvolvidos.
Quadro 08. Relatório de Inconsistências dos Requisitos.
Empresa: ABC
Relatório de Inconsistências dos Requisitos Projeto:
Identificador Requisito Descrição Qual a condição para ocorrer Justificativa
Quando houver a necessidade de aquisição de recursos materiais ou serviços, o modelo de documento com os fornecedores candidatos deve ser preenchido e apresentado com as informações resumidas sobre as vantagens e desvantagens de cada um (melhor custo, prazo, serviço) para que o gerente geral possa fazer uma análise de qual fornecedor é mais vantajoso para a organização em termos estratégicos.
Quadro 09. Documento para Recebimento de Propostas de Fornecedores.
Empresa: ABC
Documento para Recebimento de Propostas de Fornecedores Produto a ser adquirido:
Qtde:
Fornecedor:
Nome Tipo de Fornecimento Vantagens/Desvantagens
Uma avaliação dos produtos recebidos será realizada pelo gerente local, usando o modelo do Quadro 10. O gerente local e o gerente de projeto poderão realizar uma avaliação mais confiável por manter contato com o fornecedor e por estarem a par dos problemas ocorridos no fornecimento de recursos materiais e serviços.
Quadro 10. Avaliação dos Produtos Recebidos Empresa ABC
Avaliação dos Produtos Recebidos Fornecedor:
Produto: Data:
Itens a serem Avaliados Pontuação (1-Ruim a 10-Excelente)
Outra avaliação realizada pelos clientes poderá ser realizada pelos membros da organização contratante para obter dados da satisfação do cliente com relação aos produtos e serviços fornecidos que podem ser: treinamentos, software, artefatos, instalação, etc. O modelo a ser usado é o do Quadro 11.
Quadro 11. Avaliação da Organização Empresa ABC
Avaliação dos Produtos e Serviços Fornecidos Avaliação realizada pelo Cliente C
Produto: Data:
Itens a serem Avaliados Pontuação (1-Ruim a 10-Excelente)
Uma avaliação realizada pelos participantes do projeto, utilizando o modelo do Quadro 121, trará um feedback para que toda a organização possa ganhar conhecimento e
1 Baseado no relatório de lições aprendidas de Kathy Schwalbe (http://www.augsburg.edu/ppages/~schwalbe/).
melhorar a qualidade do processo e do produto fazendo com que o aprendizado individual se torne coletivo em nível corporativo.
Quadro 12. Relatório de Lições Aprendidas.
Empresa ABC
Relatório de Lições Aprendidas Nome:
Função:
Projeto: Data:
1. O projeto terminou dentro do escopo, tempo e prazo pré-definidos?
2. Descreva as principais questões positivas do projeto.
3. Descreva as principais questões negativas no projeto.
4. O que você faria diferente no próximo projeto após a experiência de ter participado deste projeto?