U. S.
DEPARTAMENT OF
DEFENSE (DoD)
EXTENSION TO PMBOK
(section III)
Preparada para o curso
"Tecnologia de Plataformas Orbitais e Cargas Úteis"
Mario C. P. Almeida
Setembro, 2009
SUMÁRIO DA APRESENTAÇÃO
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Introdução ao PMBOK
Conteúdo do PMBOK 2000
Visão geral do PMBOK 2000
PMBOK x U. S. DoD Extension to PMBOK
A Razão da DoD extension PMBOK
Seção III do U. S. DoD Extension
Capítulo 13
Capítulo 14
Capítulo 15
Capítulo 16
Capítulo 17
Conclusão do U.S. DoD Extension
Dificuldade/comentários
Referências
INTRODUÇÃO AO PMBOK
•
•
•
•
•
•
•
•
•
•
•
•
"A Guide to the Project Management Body of Knowledge"
"Um Guia do Corpo de Conhecimentos em Gerenciamento de Projetos"
É uma compilação das "best-practices" em gerenciamento de projetos
Publicada pela 1a vez em 1987 pelo PMI (Project Management Institute)
1a versão oficial lançada em 1996
Atualmente está na 4a versão (Dez 2008)
Resultado de trabalho voluntário
Há diferenças de forma/estilos no seu texto
Pretende ser abrangente no seu escopo
Dirigido a Gerentes de Projetos
É um guia de uso não obrigatório
Baseado em processos
§ Entradas (documentos, planos, desenhos, etc)
§ Ferramentas e técnicas
§ Saídas (documentos, estudos, produtos, etc.)
• Planejadas versões em 10 línguas para 2009
• Extensões foram produzidas por interessados,
com aprovação da PMI, para áreas específicas, e.g.,
da construção civil, de governo, do DoD, gerência de operações, etc
CONTEÚDO DO PMBOK 2000
(base para o U. S. DoD Extension to PMBOK
• Seção I A Estrutura do Gerenciamento de Projetos
n
n
n
Cap. 1 Introdução
Cap. 2 O Contexto de Gerenciamento do Projeto
Cap. 3 Os Processos de Gerenciamento do Projeto
• Seção II As Áreas de Conhecimento do Gerenciamento
de Projetos
n
n
n
n
n
n
n
n
n
Cap.
Cap.
Cap.
Cap.
Cap.
Cap.
Cap.
Cap.
Cap.
4 Gerenciamento de Integração do Projeto
5 Gerenciamento do Escopo do Projeto
6 Gerenciamento de Tempo do Projeto
7 Gerenciamento de Custo do Projeto
8 Gerenciamento da Qualidade do Projeto
9 Gerenciamento de Recursos Humanos do Projeto
10 Gerenciamento das Comunicações do Projeto
11 Gerenciamento de Risco do Projeto
12 Gerenciamento de Compras do Projeto
CAP. 1 INTRODUÇÃO
• Apresenta o guia, definições, relacionamentos.
1.1 Propósito deste Guia
1.2 O que é Projeto?
1.3 O que é Gerenciamento de Projeto?
1.4 Relacionamento com Outras Disciplinas de
Gerenciamento
§ 1.5 Esforços Relacionados
§
§
§
§
CAP. 2 O CONTEXTO DO
GERENCIAMENTO DE PROJETOS
• Descreve o contexto onde o projeto se encontra.
§
§
§
§
§
2.1
2.2
2.3
2.4
2.5
Fases do Projeto e Ciclo de Vida do Projeto
Stakeholders do Projeto
Influências Organizacionais
Habilidades Chave em Gerenciamento Geral
Influências Sócio-Econômica-Ambiental
CAP. 3 O PROCESSO DE
GERENCIAMENTO DE PROJETOS
• Descreve os processos necessários para o
gerenciamento do projeto.
§
§
§
§
§
3.1 Processos do Projeto
3.2 Grupos de Processos
3.3 Interação de Processos
3.4 Customizando Interações de Processos
3.5 Mapeamento de Processos de Gerenciamento de
Projetos
§ DoD Extension to PMBOK refere-se integralmente ao
capítulo 3 do PMBOK original
CAP. 4 GERENCIAMENTO DE
INTEGRACÃO DE PROJETOS
• Descreve os processos necessários para
certificar-se que os vários elementos do projeto
estejam adequadamente coordenados.
§ 4.1 Desenvolvimento do Plano do Programa
§ 4.2 Execução do Plano do Programa
§ 4.3 Controle Integrado de Mudanças
CAP. 5 GERENCIAMENTO DE ESCOPO
DE PROJETOS
• Descreve os processos necessários para garantir
que o projeto inclua todo o trabalho necessário,
e somente o trabalho necessário, para completar
o processo com sucesso.
§
§
§
§
§
5.1
5.2
5.3
5.4
5.5
Início
Planejamento do Escopo
Definição do Escopo
Verificação do Escopo
Controle de Mudança de Escopo
CAP. 6 GERENCIAMENTO DE TEMPO
DE PROJETOS
• Descreve os processos necessários para garantir
que o projeto seja completado dentro do prazo.
§
§
§
§
§
6.1
6.2
6.3
6.4
6.5
Definição de Atividades
Sequenciamento de Atividades
Estimando a Duração da Atividade
Desenvolvimento do Cronograma
Controle do Cronograma
CAP. 7 GERENCIAMENTO DE CUSTOS
DE PROJETOS
• Descreve os processos necessários para que o
projeto seja completado dentro do orçamento.
§
§
§
§
7.1
7.2
7.3
7.4
Planejamento de Recursos
Estimando Custos
Orçando Custos
Controle de Custos
CAP. 8 GERENCIAMENTO DA
QUALIDADE DE PROJETOS
• Descreve os processos necessários para garantir
que o projeto satisfaça aos requisitos impostos.
§ 8.1 Planejamento da Qualidade
§ 8.2 Garantia da Qualidade
§ 8.3 Controle da Qualidade
CAP. 9 GERENCIAMENTO DE
RECURSOS HUMANOS DE PROJETOS
• Descreve os processos necessários para fazer o
melhor uso das pessoas envolvidas no projeto.
§ 9.1 Planejamento Organizacional
§ 9.2 Aquisição de Equipe
§ 9.3 Desenvolvimento de Equipe
CAP. 10 GERENCIAMENTO DE
COMUNICAÇÕES DE PROJETOS
• Descreve os processos necessários para garantir
rápida e adequada geração, coleção,
disseminação, armazenamento e disposição final
das informações do projeto.
§
§
§
§
10.1
10.2
10.3
10.4
Planejamento das Comunicações
Distribuição das Informações
Relatórios de Desempenho
Encerramento Administrativo
CAP. 11 GERENCIAMENTO DE RISCOS
DE PROJETOS
• Descreve os processos relacionados a identificar,
analisar e responder aos riscos do projeto.
§
§
§
§
§
§
11.1
11.2
11.3
11.4
11.5
11.6
Planejamento do Gerenciamento de Riscos
Identificação de Riscos
Análise Qualitativa de Riscos
Análise Quantitativa de Riscos
Planejamento de Respostas aos Riscos
Monitoramento e Controle dos Riscos
CAP. 12 GERENCIAMENTO DE
COMPRAS DE PROJETOS
• Descreve os processos necessários para adquirir
bens e serviços para o projeto.
§
§
§
§
§
§
12.1
12.2
12.3
12.4
12.5
12.6
Planejamento de Necessidades
Planejamento de Compras
Licitações
Seleção dos Fornecedores
Administração de Contrato
Encerramento de Contrato
PMBOK x U. S. DoD EXTENSION PMBOK
• DoD Extension PMBOK Versão 1.0, Junho 2003, baseado na
•
•
•
•
•
•
edição do PMBOK 2000
Deve ser visto como um complemento ao PMBOK original,
não um documento completo
Muitos parágrafos e um capítulo inteiro do DoD Extension se
referem integralmente ao PMBOK original
Preparado pela Defense Acquisition University (DAU)
Inclusões de parágrafos adicionais espalhados no corpo do
PMBOK original
Inclusão de uma nova seção (seção III) com 5 capítulos após
o capítulo 12 do original (Capítulo 13 até o Capítulo 17)
Essa nova seção é o escopo desta apresentação
RAZÃO DO DoD EXTENSION PMBOK
•
•
•
•
Identificar e descrever aplicações de defesa das áreas de
conhecimento de gerenciamento contidas no PMBOK
Identificar e descrever as aplicações de defesa não contidas no
PMBOK
Originado de:
Duas prioridades do secretário de defesa (Rumsfeld)
1. Reformar as estruturas, processos e organização do DoD, incluindo o processo
de aquisição
2. Introduzir novos sistemas bélicos para cobrir nossas novas circunstâncias
•
§
§
Reduzir o tempo do ciclo das nossas armas
Inserir novas tecnologias comerciais
Diretivas e gols pelos Vice Secretário e pelo Subsecretário de
Defesa para Aquisições, Tecnologia e Logística
§
Gol # 1 "Conseguir credibilidade e eficiência no processo de suporte de aquisição
e logística" - Uma parte chave deste gol é o uso de estimativas de custo realísticas e
subsidiar totalmente essas estimativas; usar aquisição evolucionária e desenvolvimento em
espiral como um meio de entregar sistemas mais rapidamente e a um menor custo (E. C.
Aldridge - 2002)
Seção III do DoD Extension PMBOK
• Seção III - Áreas de Conhecimento de Aquisição para
Defesa
• Cap. 13 - Gerenciamento da Engenharia de Sistemas do Projeto
13.1 Planejamento de Engenharia de Sistemas
13.2 Atividades de Engenharia de Sistemas
13.3 Análise e Controle
• Cap. 14 - Gerenciamento da Aquisição de Software do Projeto
14.1 Atividades de Gerenciamento de Aquisição de Software
• Cap. 15 - Gerenciamento da Logística do Projeto
15.1 Gerenciamento da Logística
• Cap. 16 - Gerenciamento de Testes e Avaliação do Projeto
16.1 Planejamento de Teste e Avaliação
• Cap. 17 - Gerenciamento da Produção do Projeto
17.1 Influenciar no Projeto
17.2 Planejamento da Produção
17.3 Produção
CAP 13 GERENCIAMENTO DE ENGENHARIA
DE SISTEMAS DE PROJETOS
Gerenciamento da Engenharia de Sistemas é o amplo processo pelo qual os
aspectos técnicos do programa são avaliados, gerenciados e controlados. Ele
inclui todas as disciplinas funcionais necessárias para projetar, desenvolver,
testar, produzir e suportar produtos no ambiente de defesa. É um processo
abrangente e iterativo de gerenciamento técnico.
O processo de Engenharia de Sistemas e as suas ferramentas e técnicas são
amplamente reconhecidas e aceitas em normas e textos de gerenciamento de
programas comerciais e de defesa.
Dividido em:
§
13.1 Planejamento da Engenharia de Sistemas
§
13.2 Atividades da Engenharia de Sistemas
§
13.3 Análise e Controle
CAP 13.1 PLANEJAMENTO DE
ENGENHARIA DE SISTEMAS
O desenvolvimento de planos é importante como um meio de auxiliar o
gerente de projeto a pensar através das especificidades do esforço técnico e
identificar riscos. Planos são um meio efetivo de comunicação entre o
"program office" do governo, as atividades de apoio do governo, e as
contratadas.
Muitos programas tem requisitos únicos. Os planos para esses programas
devem refletir essas necessidades únicas ao invés de seguir os modelos de
processos gerais. É importante também que os planos detalhados apresentem
uma abordagem individualizada em relação aos modelos genéricos da
engenharia de sistema.
13.1 PLANEJAMENTO DE ENGENHARIA
DE SISTEMAS
•13.1.1 Entradas do Planejamento da Engenharia de Sistemas
• Requisitos operacionais
•
Os requisitos iniciais são declarados pelo usuário nos documentos ICD (Initial Capability Document) ou Concept of Operation/Scenarios.
•
Conforme os requisitos evoluem e amadurecem eles são então expressos no CDD (Capability Development Document).
• Requisitos específicos do programa
•
Os requisitos específicos de programas de defesa (suporte logístico, testes, políticos, dimensões, complexidade, importância, etc).
• Políticas atuais de aquisição
Série DoD 5000 impõem restrições nas formas de procedimentos do gerenciamento de programas de defesa.
•
•13.1.2 Ferramentas e Técnicas do Planejamento da Engenharia de Sistemas
• IPPD/IPTs
•
Integrated Product and Process Development e Integrated Product Team são as abordagens de gerenciamento preferidas pelo DoD.
•
DoD se esforça para aplicar IPPD/IPTs dentro do DoD e nos seus contratados.
•
IPPD/IPT consta de equipe multidisciplinar de engenharias e gerenciamento envolvida desde o início do projeto com usuários,
produtores, fornecedores, testadores, especialistas em logística, especialistas em negócios, etc.
•
A meta do esforço coordenado dessa equipe é a preparação de projetos e planos realísticos que permitam atingir os objetivos de custo,
cronograma e desempenho.
• Outras ferramentas e técnicas
Gerenciamento de escopo, de custo, de recursos humanos e de riscos já descritos em outros capítulos deste guia.
•
•13.1.3 Saídas do Planejamento da Engenharia de Sistemas
• Plano de Gerenciamento Técnico
•
Um plano, preparado pelo lado do Governo, que descreve o gerenciamento dos aspectos técnicos do programa.
•
Esse plano descreve o programa e o processo de planejamento em um nível bastante alto e genérico.
•
As contratadas preparam planos que descrevem em detalhes os processos e técnicas empregadas para gerenciar seus contratos.
•
A combinação de todos esses planos compreende o Plano de Gerenciamento Técnico do Programa.
• Planos funcionais associados
•
Planos para área específicas poderão ser necessários, e.g., planos de testes, planos de manufatura, etc.
•
Esses planos específicos são anexados ao Plano de Gerenciamento Técnico devendo haver consistência entre todos eles.
• Plano mestre integrado
•
O DoD tem se voltado para planos integrados que integram todas as áreas (engenharia, finanças, logística, etc).
•
Caso planos específicos sejam anexados ao plano integrado, deve haver uma função de planejamento da integração, para resolver
conflitos naturais ao planejamento integrado.
13.2 ATIVIDADES DE ENGENHARIA DE
SISTEMAS
• O Processo de Engenharia de Sistemas usado pelo DoD é o mesmo amplamente
reconhecido e aceito em outras áreas. Ele aparece de forma similar ou idêntica em
inúmeros textos sobre o assunto.
• A sequência de atividades que transformam necessidades do usuário em concepções e
em produtos
13.2 ATIVIDADES DE ENGENHARIA DE
SISTEMAS
• 13.2.1 ENTRADAS DAS ATIVIDADES DA ENGENHARIA DE SISTEMAS
• Requisitos
•
Requisitos podem ser oriundos da organização representando o operador final (usuário, soldado) ou de outras fontes.
•
Requisitos, documentados num ICD/CDD, devem expressar funções, desempenho, requisitos de interfaces, restrições físicas, etc.
não requisitos de produto, de processo ou de projeto, permitindo ao projetista concepções alternativas que serão selecionadas pelo
governo com base em custos, riscos e desempenho.
• Outras restrições
•
Podem existir restrições de maturidade da tecnologia, legais, políticas, compatibilidade com sistemas preexistentes, etc.
•13.2.2 FERRAMENTAS E TÉCNICAS PARA ENGENHARIA DE SISTEMAS
• Análise de requisitos
•
Identificar funções, desempenho, requisitos de interface, restrições físicas ou de projeto.
•
Desenvolver um entendimento completo e não-ambíguo das necessidades do usuário.
•
Análise de requisito e análise funcional são realizadas em ciclos iterativos até chegar a especificação de sistemas.
• Análise funcional/alocação
•
É ferramenta chave para identificar áreas de risco e tomar decisões para controlá-lo.
•
Envolve a decomposição das funções de alto nível, identificadas na análise de requisitos, em funções de nível mais baixo, a alocação
de requisitos de desempenho para essas funções de baixo nível e otimização da arquitetura funcional.
•
Requer também análises de linha de tempo, diagramas de blocos, diagramas de fluxos de dados, diagramas de estados, etc.
•
Permite desenvolver especificações para itens abaixo do nível de sistemas.
• Síntese
•
É o processo de desenvolver soluções físicas que realizam as funções identificadas durante a análise funcional.
•
É quando são identificados os elementos físicos do sistema onde os requisitos são alocados.
•
O processo é repetido de forma iterativa para níveis seguidamente mais baixos até a descrição completa do sistema.
•13.2.3 SAÍDAS DAS ATIVIDADES DE ENGENHARIA DE SISTEMAS
• Arquitetura funcional
•
É uma descrição em termos funcionais, de um item ou sistema, resultado da Análise Funcional/Alocação.
•
Formado pelo conjunto de diagramas de blocos funcionais, de fluxo (DFDs, FFD), análise de tempo, etc., que descrevem o sistema.
• Arquitetura física
•
Descrição do item ou sistema em termos de seus elementos e componentes físicos.
•
Definição da arquitetura física, assim como a funcional, é um processo de cima para baixo.
• Documentação
•
Especificação do sistema.
•
Especificações de itens de níveis inferiores.
•
Technical Data Package (TDP) que fornece descrição funcional e física completa do item sendo desenvolvido, composto de desenhos
de produto, desenhos de interface, lista de componentes, lista de códigos de software, etc.
13.3 ANÁLISE E CONTROLE
Análise e controle se refere ao conjunto de ferramentas e técnicas
empregadas para avaliar, gerenciar, e controlar as Atividades de
Engenharia de Sistemas que transformam requisitos em projetos e em
produtos.
O processo de Engenharia de Sistemas é repetido várias vezes durante o
curso do projeto e desenvolvimento. Em cada repetição o projeto evolui
e amadurece.
Simultaneamente, os processos de suporte, como treinamento, testes e
avaliações, fabricação e logística são iniciados, planejados, projetados e
desenvolvidos.
Várias ferramentas de gerenciamento de engenharia são empregados
para garantir que alternativas sejam consideradas, o risco gerenciado,
definições de produto controladas, etc.
13.3 ANÁLISE E CONTROLE
• 13.3.1 ENTRADAS DE ANÁLISE E CONTROLE
• Atividades do processo de engenharia de sistemas
•
Análise de requisitos, análise funcional e alocação, e síntese, que transformam requisitos em sistemas, são repetidas seguidas vezes
com as saídas desse processo evoluindo nos ciclos seguidos.
• 13.3.2 FERRAMENTAS E TÉCNICAS PARA ANÁLISE E CONTROLE
• Estudos de compromisso
• Diferentes abordagens e soluções são avaliadas e selecionadas com base em critérios bem definidos.
• Envolve, definição de critério de decisão, análises de sensibilidade, de desempenho, de custos, de eficiência, definição de riscos, seleção
da abordagem ou solução preferida.
• Gerenciamento da configuração
• Documentar e manter atualizada a descrição funcional e características físicas, de desempenho e de interfaces do produto, permitindo
fornecer informações corretas em qualquer instante do seu ciclo de vida.
• Composto de identificar e documentar o item, gerenciar mudanças, manter registros de status, auditar para garantir consistência entre
documentos e produtos, gerenciar os dados associados com o gerenciamento da configuração, etc.
• Medidas de desempenho técnico
• Medidas de parâmetros do produto usadas para monitorar a evolução do sistema com o tempo através dos processos de projeto e
desenvolvimento, e.g., massa, MTBF, eficiência, etc.
• Revisões técnicas
• Usadas para avaliar o progresso técnico do programa durante os processos de projeto e desenvolvimento.
• Revisões podem ser em vários níveis, de sistema, de subsistema, de componente, etc.
• Revisões são programadas para ocorrerem em um ponto de transição do programa.
• Resultado positivo leva a recomendação para prosseguir para a próxima fase.
• No IPPT o tom da revisão é colaborativo já que governo e contratada trabalham em conjunto.
• A programação das datas das revisões é importante pois uma revisão mal-programada pode levar à decisões erradas.
• Gerenciamento de risco
•
Discutido no cap. 11.
•
Em engenharia de sistemas, gerenciamento de riscos é usado para determinar quais áreas técnicas necessitam de mais atenção.
• 13.2.3 SAÍDAS DE ANÁLISE E CONTROLE
• Especificações
• Especificação de desempenho e especificação de detalhe.
• Especificação de desempenho é uma descrição em termos funcionais, de desempenho, de interface, sem descrever solução.
• Especificação de detalhe descreve a solução e tem informação do produto, e sobre processos e materiais usados para obtê-lo.
• Conjunto de especificações de sistema, subsistema, item e seus associados formam o Technical Data Package (TDP).
• Baselines
• Baseline é uma configuração fechada em um determinado instante do projeto, no DoD há normalmente três baselines
• Baseline Funcional de Sistema descreve requisitos de nível de sistema.
• Baseline Alocada descreve requisitos de projeto para itens abaixo do nível de sistemas.
• Baseline de Produto descreve o produto como ele é produzido.
CAP. 14 GERENCIAMENTO DE AQUISIÇÃO DE
SOFTWARE DE PROJETOS
• Gerenciamento da Aquisição de Software é processo de gerenciar a
aquisição e o desenvolvimento de sistemas intensivos em software para
o DoD
•Definições e regulamentações:
• Sistemas intensivos em software são sistemas no qual o software é o maior segmento das funcionalidades, do custo, do risco ou do
tempo de desenvolvimento. No âmbito do DoD podem ser, a grosso modo, definidos e classificados como:
• Sistema de informação automáticos: sistemas de tecnologia de informação clássicos onde privacidade é um requisito crítico.
• Sistemas de inteligência, controle, comando, comunicação e computadores (C4I): aqueles que auxiliam planejadores e
comandantes de missões onde seguridade é um requisito crítico.
• Sistemas computacionais de armamento: sistemas computacionais de alta-performance em tempo-real embarcados em sistemas
bélicos de grande porte onde segurança é um requisito crítico.
• Regulamentações
• Outros regulamentos e.g., Decreto CCA (Clinger-Cohen Act), obrigam definir e classificar os sistemas de software de outra forma e
exigem outros requisitos de programa de desenvolvimento (Series DoD 5000 específicas para aquisição):
• Sistema de Informação Automático: todos sistemas de TI exceto os que fazem parte de armamento, sistemas bélicos ou sistemas
de comunicação tático
• Sistema de Segurança Nacional: qualquer sistema de informações ou telecomunicações operado pelo governo dos EUA nos quais a
função, operação ou uso envolve atividades de inteligência ou criptografia relacionadas com segurança nacional, comando e controle de
forças militares ou equipamento que é uma parte de armamento ou sistema bélico crítico para o cumprimento de uma missão militar ou
de inteligência. Não inclui sistemas administrativos como folha de pagamentos, finanças, logística, gerenciamento de pessoal, etc.
• Tecnologia da Informação: qualquer equipamento, sistema ou subsistema usado para automaticamente adquirir, armazenar,
manipular, gerenciar, mover, controlar, mostrar, chavear, trocar, transmitir ou receber dados ou informações. O termo TI inclui
computadores, equipamentos auxiliares, software, firmware, e serviços, recursos e procedimentos relacionados.
• Sistema de Informação Crítico para a Missão: um sistema que é classificado na definições de "Sistema de Informação" e "Sistema
de Segurança Nacional" do CCA e cuja perda causa a interrupção de operações de combate ou seus serviços de suporte diretos.
• Sistema de Informação Essencial para a Missão: um sistema que é classificado na definição de "Sistema de Informação" do CCA e
que o é considerado básico e necessário para o cumprimento da missão.
14.1 ATIVIDADES DE GERENCIAMENTO
DE AQUISIÇÃO DE SOFTWARE
§ 14.1.1 ENTRADAS DAS ATIVIDADES DE GERENCIAMENTO DE AQUISIÇÃO DE SOFTWARE
§ Verificação de conformidade e certificações de acordo com inúmeros regulamentos do DoD.
§ Avaliação de riscos de operações de informações de acordo com regulamentos do DoD.
§ Operabilidade com a rede global de informações - garantir compatibilidade, interoperabilidade e integração de acordo
com regulamentos do DoD.
§ Plano de suporte a Sistemas de Inteligência, Comando, Comunicações, Controle e Computadores (C4I).
§ Requisitos de garantia de informações - garantir disponibilidade, integridade, autenticação, confidencialidade,
sobrevivência.
§ Documento de Capacidade de Desenvolvimento (CDD)- preparado pelo usuário final.
§ Especificações de sistemas e subsistemas.
§ Documento de concepção operacional.
§ Planos de Engenharia de Sistemas.
§ Plano mestre de testes e avaliações.
§ Plano de desenvolvimento e gerenciamento de software.
§ Estudos de compromisso para seleção de linguagem.
§ Elementos de dados padrão.
§ Requisitos de suportabilidade de software.
§ Requisitos de software.
§ Arquiteturas padrão mandatórias do DoD - (arquiteturas abertas).
§ Abordagem de contratação - "contratação modular" - CCA prefere entrega de funcionalidades em curtos intervalos.
§ Avaliação da capacidade do desenvolvedor de software: experiência em sistemas similares, sucessos anteriores,
maturidade (SW - CMML nível 3).
§ Estratégia/abordagem de aquisição de sistemas: e.g., "aquisição evolucionária" ou "grande projeto".
14.1 ATIVIDADES DE GERENCIAMENTO
DE AQUISIÇÃO DE SOFTWARE
• 14.1.2 FERRAMENTAS E TÉCNICAS DAS ATIVIDADES DE GERENCIAMENTO DE
AQUISIÇÃO DE SOFTWARE
• Avaliação da maturidade de desenvolvimento de software: avaliação SCE/CMM durante o
desenvolvimento.
• Avaliação da maturidade da aquisição de software: o DoD avalia sua própria capacidade de adquirir
software SA/CMM.
• Medidas de software: métricas para avaliar o gerenciamento e qualidade de software.
• Ajustes nos ciclo de vida padrão: ajuste no modelo de desenvolvimento inicial para evitar riscos .
• Repositório de reuso de software de defesa: fazer uso de software disponíveis para reduzir custos.
• Recursos de contratadas de apoio: empresas contratadas para dar apoio em verificação,
gerenciamento, conhecimento técnico especializado, etc.
• Revisões de programa por expert independente: geralmente realizada antes da CDR por grupo de
especialistas do DoD em avaliação de riscos, custos, cronograma, projeto, desenvolvimento,
gerenciamento, melhores práticas, etc.
• Avaliação de risco de seguridade de software: avaliar impacto das modificações na confiabilidade;
análise de malware de COTS produzido fora do país ou por não-americanos .
• Avaliação de risco de operações de informações: avaliação de vulnerabilidade e ameaças;
implementar, demonstrar e certificar de contramedidas tais como encriptação, empacotamento,
enfeixamento.
• Modelos de desenvolvimento em espiral: processo cíclico, iterativo (build-test-fix-test-deploy).
14.1 ATIVIDADES DE GERENCIAMENTO
DE AQUISIÇÃO DE SOFTWARE
14.1.3 SAÍDAS DAS ATIVIDADES DE GERENCIAMENTO DE AQUISIÇÃO
DE SOFTWARE
§ Planos de gerenciamento, planos de suporte e de planos de campo: planos de
instalação, preparação, treinamento, etc.
§ Itens de software: o software, propriamente dito, dos sistemas do DoD.
§ Novos elementos de dados: novos elementos criados devem serem incluídos
no repositório de elementos de dados.
§ Componentes reutilizáveis de software: novos componentes devem ser
incluídos no repositório de software.
§ Avaliação da maturidade do produto de software: o software deve ser
certificado antes de ser submetido a testes operacionais por envolver riscos de
segurança.
§ Certificação Clinger-Cohen: sistemas críticos ou essenciais somente podem ser
lançados em campo após declaração, por escrito, do "Chief Information Officer"
que foram desenvolvidos de acordo com o Clinger-Cohen Act.
CAP. 15 GERENCIAMENTO DE LOGÍSTICA
DE PROJETOS
O gerenciamento da logística do projeto engloba tudo o que está
associado com o suporte material dos sistemas do DoD durante todo o
seu ciclo de vida.
Há duas fases:
Logística de Aquisição: as atividade técnicas e de gerenciamento
conduzidas para garantir que as necessidades de suportabilidade são
consideradas desde início e durante todo o processo de aquisição.
Logística de Sustento: começa quando o sistema é lançado em
campo e termina quando este é descartado.
Ocasionalmente muitos dos sistemas ultrapassam sua vida prevista e
necessitam upgrades fazendo com que ocorra superposição dos
esforços de logística de aquisição e de sustento.
15.1 GERENCIAMENTO DE LOGÍSTICA
14.1.1 ENTRADAS PARA O GERENCIAMENTO DA LOGÍSTICA
§ Requisitos de suportabilidade: documentos gerados pelos usuários considerando deficiências na área, ameaças,
tecnologias emergentes, ou melhorias nos sistemas de bélicos.
§ Política de suporte do produto: (extraído do DoD 5000 series)
§ A responsabilidade por conduzir a logística de aquisição durante a vida do sistema é do Gerente do Projeto.
§ Análise de suportabilidade deve ser realizada para fornecer uma abordagem analítica ao Gerente do Projeto
durante a vida do sistema.
§ Concepção de suporte deve ser estabelecida no início do projeto e deve ser continuamente refinada.
§ Fundos para suporte devem ser orçados de forma consistente com a concepção de suporte e desenvolvimento.
§ Recursos comerciais devem ser usados se disponíveis e se atendem os requisitos do usuário.
§ Sistemas de testes automáticos dedicados devem ser minimizados - preferência deve ser dada para sistemas de
testes automáticos do DoD ou comerciais disponíveis de prateleira.
§ Estratégia de suporte do produto: Documentos tratando da estratégia para sustento e melhoria contínua de
custos, confiabilidade, suportabilidade enquanto mantendo prontidão.
§ Disponibilidade do sistema: Um parâmetro que reflete a prontidão de um sistema e é vital para o interesse do
usuário - expressa a probabilidade do sistema estar em estado operável e pronto para iniciar uma missão em um
instante aleatório.
§ Custo no ciclo de vida: Custo total de aquisição e ownership de um sistema do DoD durante toda sua vida - inclui o
custo de desenvolvimento, aquisição, operação, suporte e descarte.
15.1 GERENCIAMENTO DE LOGÍSTICA
14.1.2 FERRAMENTAS E TÉCNICAS PARA O GERENCIAMENTO DE LOGÍSTICA
§ Elementos da logística: reduzir custos otimizando uso dos elementos de logística através da padronização,
simplificação, redução de variedade, etc.
§ Análise de suportabilidade são realizadas para influenciar no projeto para este atingir os objetivos de prontidão no
menor custo.
§ Confiabilidade e manutenibilidade:
•
Confiabilidade: Habilidade do sistema realizar sua missão sem falhas, degradação, ou exigência no sistema de
suporte - MTBF é a vida em operação de uma população de itens dividida pelo número de falhas durante um
intervalo.
•
Manutenibilidade: Habilidade de um item ser restaurado às condições especificadas quando manutenção é
realizada - MTTR é o tempo médio para reparos - MMT é o tempo médio de manutenção (corretiva ou preventiva).
§ Testes de suportabilidade são testes e demonstrações planejadas para demonstrar confiabilidade, disponibilidade e
manutenabilidade.
15.1 GERENCIAMENTO DE LOGÍSTICA
14.1.3 SAÍDAS DO GERENCIAMENTO DE LOGÍSTICA
§ Influenciar no projeto do sistema para suportabilidade: fazer com que
confiabilidade e manutenibilidade sejam considerados desde o início do
projeto.
§ Planejamento do gerenciamento de suporte do produto para todo o
ciclo de vida conforme a política de suporte de logística.
§ Fundos para logística: as necessidades de fundos devem ser
identificadas cedo para estes estarem disponíveis
§ Contratação para logística de aquisição: Requisitos de logística
levantados pelas análises serão incluídos aos contratos de aquisição.
CAP. 16 GERENCIAMENTO DE TESTES E
AVALIAÇÕES DE PROJETOS
• Gerenciamento de Testes e Avaliações do Projeto:
•
•
•
•
•
•
É parte integrante da Engenharia de Sistemas (Cap. 13)
Identifica níveis de desempenho do sistema,
Fornece dados em suporte de análises de trade-off,
Reduz riscos, e
Auxilia o gerente do projeto em corrigir deficiências
Auxilia as "Milestones Decision Authorities" fornecendo informações objetivas sobre o
desempenho do sistema
• Devido a sua importância para o DoD é tratado em um capítulo
separado
• Divido em:
• 16.1 Planejamento de Testes e Avaliações
• 16.2 Execução e Relatórios de Testes e Avaliações
16.1 PLANEJAMENTO DE T & A
16.1.1 ENTRADAS PARA O PLANEJAMENTO DE TESTES E AVALIAÇÕES
§ Documento de capacidades iniciais (ICD) documenta de uma forma ampla e genérica uma deficiência da missão e
expressa uma capacidade operacional desejada.
§ Análise de alternativas documenta as diferentes concepções do sistema que satisfaçam o documento de capacidades
iniciais.
§ Documento de desenvolvimento de capacidades documenta características operacionais de desempenho para o
sistema proposto.
§ Especificação de desempenho do sistema é um documento de contrato que documenta os requisitos funcionais e
técnicos do sistema, restrições físicas, etc.
§ Plano de suporte do C4I é exigido para toda aquisição que se conecta a infraestrutura de comunicações e informações.
§ Política de aquisição do DoD inclui diretivas, instruções e guias para suporte de testes e avaliações das aquisições.
16.1.2 FERRAMENTAS E TÉCNICAS PARA O PLANEJAMENTO DE TESTES E AVALIAÇÕES
§ Time Integrado de Produto para Testes e Avaliações (IPT-TE), composto por representantes do usuário, desenvolvedor,
teste operacional, teste de fogo real, logística, secretário de defesa, e liderado pelo gerente do projeto, é responsável
por todo planejamento de Testes e Avaliações.
§ Processo de planejamento de Time Integrado de Produto para Testes e Avaliações que segue os seguintes passos:
revisão dos documentos chave, concepção da estratégia de testes, preparação do Plano Mestre de Testes e Avaliações,
formação do grupo de aprovação e coordenação, acompanhamento do desenvolvimento do plano detalhado, revisão dos
resultados de testes.
16.1.3 SAÍDAS DO PLANEJAMENTO DE TESTES E AVALIAÇÕES
§ Plano Mestre de Testes e Avaliações (TEMP).
§ Definição de Falha/Critérios de Pontuação pelo Time Integrado de Produto para Testes e Avaliações do que constitui
uma falha e como pontuar dos resultados.
§ Requisitos de testes e avaliações do contrato definidos pelo Time Integrado de Produto T&A - métodos de verificação
(inspeção, demonstração, análise, teste) e outros requisitos.
§ Planos de testes detalhados para testes de desenvolvimento, testes operacionais, testes de fogo real.
§ Declaração de Impacto Ambiental é preparado pelo gerente do projeto com ajuda das agências de testes avaliando
possíveis impactos ambientais causados pelo desenvolvimento, uso, ou teste do sistema proposto.
16.2 EXECUÇÃO E RELATÓRIOS DE
T&A
16.2.1 ENTRADAS PARA EXECUÇÃO E RELATÓRIOS DE TESTES E AVALIAÇÕES
§ Documentos de planejamento de testes e avaliações preparados pelo processo de planejamento de
testes.
§ Recursos de testes e avaliações, tais como dispositivo sob teste, instalações, pessoal e serviços,
tropas, simuladores de alvo e ameaças, etc.
16.2.2 FERRAMENTAS E TÉCNICAS PARA EXECUÇÃO E RELATÓRIOS DE TESTES E
AVALIAÇÕES
§ Inspeções/exames que não requerem equipamentos especiais de laboratório.
§ Análises que usam técnicas estabelecidas ou modelos matemáticos, simulações, algoritmos, gráficos,
diagramas, etc. que evidenciam conformidade com os requisitos.
§ Demonstração é um método de verificação que mostra a operação real do sistema.
§ Teste é um método de verificação que verifica quantitativamente o desempenho ou propriedades
técnicas do sistema.
§ Ferramentas estatísticas para avaliar o significado estatístico dos resultados e estimar o número
mínimo de medidas ou resultados para conseguir resultados com significado estatístico.
§ Autenticação de dados/pontuação/conferência realizadas antes, durante ou após os testes.
§ Qualificação dos testes é o processo formal de verificação e documentação de requisitos de
desempenho.
16.2.3 SAÍDAS DE EXECUÇÃO E RELATÓRIOS DE TESTES E AVALIAÇÕES
§ Relatórios de testes e avaliações são produzidos pois podem realimentar no desenvolvimento do
projeto, verificar conformidade com especificações de desempenho, etc.
CAP. 17 GERENCIAMENTO DE
PRODUÇÃO DE PROJETOS
O Gerenciamento da Produção do Projeto envolve planejamento,
organização,direcionamento, controle e integração do uso de pessoas, recursos
financeiros, materiais, processos, equipamentos e instalações para executar o esforço de
fabricação de forma econômica.
O resultado desejado do gerenciamento eficiente da produção, é fornecer um produto
uniforme, sem defeitos, com desempenho consistente e que atenda os requisitos
documentados do cliente, por um baixo custo em termos de tempo e dinheiro
O foco do Gerenciamento da Produção é identificar recursos e capacidade de fabricação
(recursos humanos, materiais, maquinário, processos e dispositivos de medidas),
entender e priorizar os riscos associados com esses recursos e, desenvolver e
implementar estratégias de mitigação de riscos
Dividido em:
17.1 Influenciar no projeto
17.2 Planejamento para produção
17.3 Produção
17.1 INFLUENCIAR NO PROJETO
17.1.1 ENTRADAS PARA INFLUENCIAR NO PROJETO
Referência às seções 5.1.1.1 Descrição do Produto, e capítulo 13, Gerenciamento de Engenharia de
Sistemas do Projeto
17.1.2 FERRAMENTAS E TÉCNICAS DE INFLUENCIAR NO PROJETO
§ Engenharia simultânea é o trabalho em equipe com foco no cliente (CE/IPPD - TQM - QFD).
§ Design for "X" : projetos com objetivos específicos, e.g., design for manufacture and assembly, design
for disassembly, design for recycling, etc.
§ Características e processos "chave": identificar as características que mais afetam ou limitam a
produção.
§ 5M - manpower, materials, machines, process methods and measurement system: - técnica de análise
que serve para identificar e mitigar riscos, etc.
§ QFD - Quality Function Deployment: metodologia que emprega equipes multifuncionais para levantar
a voz do cliente e transformá-la em especificações e outros documentos formais em vários níveis,
desde especificações de projeto até instruções de fabricação.
§ e-manufaturing usa recursos de informática para alavancar a troca de informações de projeto e
gerenciar a produção.
17.1.3 SAÍDAS DE INFLUENCIAR NO PROJETO
§ Trade-off studies: estudos de compromissos (soluções negociadas) que demonstram o equilíbrio do
projeto em termos de requisitos do produto, capacidades dos processos, controles, etc.
17.2 PLANEJAMENTO PARA PRODUÇÃO
17.2.1 ENTRADAS PARA PLANEJAMENTO PARA PRODUÇÃO
§ Identificação da características/processos "chave" já referida na seção 17.1.2.3
17.2.2 FERRAMENTAS E TÉCNICAS PARA PLANEJAMENTO PARA PRODUÇÃO
§ Estratégia de fabricação é o plano geral para garantir produção no prazo e custo previsto de um item
que atende todos requisitos de efetividade e adequabilidade.
§ Avaliação de riscos baseado na identificação das características chaves auxilia a tomada de decisões e
escolha de alternativas de manufatura.
§ "Lean Manufacturing" : termo criado no MIT para descrever técnica empregada pela Toyota para
produzir com alta qualidade e com baixos custos.
§ Gerenciamento da cadeia de suprimentos se refere as atividades associadas com o fluxo e
transformação de materiais mas quando a produção está dividida entre subcontratadas se refere ao
gerenciamento desses subcontratados.
§ Avaliação da produtibilidade pode ser feita através de revisões.
§ Projeto de experimentação são metodologias estruturadas para determinar a sensibilidade da
qualidade com variações nos parâmetros dos processos.
§ Estimativas de custo e acompanhamento devem ser iniciadas cedo e continuamente reavaliadas
durante o desenvolvimento do projeto.
§ Avaliação de sistemas de qualidade das subcontratadas (ISO 9000, ANSI/ASQC Q9000, Boeing D19000, Six Sigma, etc).
17.2.3 SAÍDAS DE PLANEJAMENTO PARA PRODUÇÃO
§ Plano de produção contendo detalhes de projeto, produtibilidade, riscos e custos da contratada.
17.3 PRODUÇÃO
17.3.1 ENTRADAS DA PRODUÇÃO
Referência às seções 17.2.3
17.3.2 FERRAMENTAS E TÉCNICAS DA PRODUÇÃO
§ Práticas de gerenciamento de produção "Lean" (desenvolvidadas no MIT's Lean Enterprise Model)
•
Identificar e otimizar o fluxo da empresa.
•
Garantir fluxo desimpedido de informações.
•
Otimizar a capacidade e a utilização das pessoas.
•
Tomar decisões no nível mais baixo possível.
•
Implementar desenvolvimento integrado de produtos e processos (IPPD).
•
Desenvolver relações baseadas em confiança e compromissos mútuos.
•
Focar continuamente no cliente.
•
Promover lideranças em todos os níveis.
•
Questionar os processos existentes.
•
Incentivar um ambiente de aprendizado.
•
Garantir capacidade e maturação dos processos.
•
Maximizar estabilidade em um ambiente sujeito a mudanças.
§ Provas de processos: demonstração da capacidade da fábrica antes de atingir a plena capacidade de produção.
§ Métricas: medidas de efetividade e.g., cumprimento de cronograma, número de waivers e desvios concedidos, custos,
etc.
§ Redução de variabilidade e controle de processos: monitoramento de parâmetros dentro dos processos para reduzir
dispersão.
§ Custo da qualidade: orientação pela prevenção/pela inspeção tem diferentes custos de qualidade.
17.3.3 SAÍDAS DA PRODUÇÃO
§ Produtos de qualidade: as saídas da produção são produtos de qualidade, que atendem os requisitos do usuário, a
custos reduzidos, em um ambiente que promove redução da variabilidade e contínua melhoria dos processos e produtos.
CONCLUSÃO EXTRAÍDA DO US PMBOK
"Precisamos prestar mais atenção às pessoas da área de
aquisição. Precisamos treiná-los melhor. Precisamos prestar
mais atenção às suas carreiras. Precisamos prepará-los
como profissionais e então precisamos respeitá-los como
profissionais. Essa é a meta que estamos perseguindo“.
Palavras de Nicholas Mavroules, autor do US Defense Acquisition Workforce Improvent
Act perante o subcomitê de investigação de Acquisition Workforce
DIFICULDADES/COMENTÁRIOS
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Usa terminologia muito específica para público do DoD.
Referências a outros documentos do DoD.
Excessivo uso de acrônimos.
Tenta ser abrangente.
Repetitivo.
Vago.
Lacônico.
Algumas transparências são assunto para toda uma apresentação.
Talvez tenha sido produzido apenas para cumprir uma ordem.
Program x Project, no PMBOK e no U.S. DoD Extension PMBOK.
Certamente está desatualizado pois a última versão do PMBOK (4a) tem o
dobro de número de páginas da edição 2000 de base.
Alguns termos não foram traduzidos.
Falta de vocabulário adequado em Português.
Dificuldade de simplificar o texto para produzir as transparências.
Transparências com muito texto.
REFERÊNCIAS
Documentos:
U.S. Department of Defense Extension to: A Guide to the
Project mangement Body of Knowledge (PMBOK Guide)
A Guide to the Project mangement Body of Knowledge
(PMBOK Guide) edição 2000
Sites:
http://en.wikipedia.org/wiki/Pmbok
http://pt.wikipedia.org/wiki/Project_Management_Body_of_
Knowledge
http://www.pmi.org