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

• "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

INTRODUÇÃO AO PMBOK

CONTEÚDO DO PMBOK 2000 (base para o U. S. DoD Extension to PMBOK

• Seção I A Estrutura do Gerenciamento de Projetosn Cap. 1 Introduçãon Cap. 2 O Contexto de Gerenciamento do Projeton Cap. 3 Os Processos de Gerenciamento do Projeto

• Seção II As Áreas de Conhecimento do Gerenciamento de Projetosn Cap. 4 Gerenciamento de Integração do Projeton Cap. 5 Gerenciamento do Escopo do Projeton Cap. 6 Gerenciamento de Tempo do Projeton Cap. 7 Gerenciamento de Custo do Projeton Cap. 8 Gerenciamento da Qualidade do Projeton Cap. 9 Gerenciamento de Recursos Humanos do Projeton Cap. 10 Gerenciamento das Comunicações do Projeton Cap. 11 Gerenciamento de Risco do Projeton Cap. 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 Fases do Projeto e Ciclo de Vida do Projeto§ 2.2 Stakeholders do Projeto§ 2.3 Influências Organizacionais§ 2.4 Habilidades Chave em Gerenciamento Geral§ 2.5 Influências Sócio-Econômica-Ambiental

CAP. 3 O PROCESSO DE GERENCIAMENTO DE PROJETOS

§ DoD Extension to PMBOK refere-se integralmente ao capítulo 3 do PMBOK original

• 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

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 ESCOPODE 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 Início§ 5.2 Planejamento do Escopo§ 5.3 Definição do Escopo§ 5.4 Verificação do Escopo§ 5.5 Controle de Mudança de Escopo

CAP. 6 GERENCIAMENTO DE TEMPODE PROJETOS

• Descreve os processos necessários para garantir que o projeto seja completado dentro do prazo.§ 6.1 Definição de Atividades § 6.2 Sequenciamento de Atividades § 6.3 Estimando a Duração da Atividade § 6.4 Desenvolvimento do Cronograma § 6.5 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 Planejamento de Recursos§ 7.2 Estimando Custos§ 7.3 Orçando Custos§ 7.4 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 Planejamento das Comunicações§ 10.2 Distribuição das Informações§ 10.3 Relatórios de Desempenho§ 10.4 Encerramento Administrativo

CAP. 11 GERENCIAMENTO DE RISCOS DE PROJETOS

• Descreve os processos relacionados a identificar, analisar e responder aos riscos do projeto.§ 11.1 Planejamento do Gerenciamento de Riscos § 11.2 Identificação de Riscos § 11.3 Análise Qualitativa de Riscos § 11.4 Análise Quantitativa de Riscos § 11.5 Planejamento de Respostas aos Riscos § 11.6 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 Planejamento de Necessidades § 12.2 Planejamento de Compras§ 12.3 Licitações § 12.4 Seleção dos Fornecedores § 12.5 Administração de Contrato§ 12.6 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 Projeto13.1 Planejamento de Engenharia de Sistemas13.2 Atividades de Engenharia de Sistemas13.3 Análise e Controle

• Cap. 14 - Gerenciamento da Aquisição de Software do Projeto14.1 Atividades de Gerenciamento de Aquisição de Software

• Cap. 15 - Gerenciamento da Logística do Projeto15.1 Gerenciamento da Logística

• Cap. 16 - Gerenciamento de Testes e Avaliação do Projeto16.1 Planejamento de Teste e Avaliação

• Cap. 17 - Gerenciamento da Produção do Projeto17.1 Influenciar no Projeto17.2 Planejamento da Produção17.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ÍSTICA14.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 & A16.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 PROJETOSO 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 PROJETO17.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ÇÃO17.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 D1-9000, 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ÇÃO17.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/Pmbokhttp://pt.wikipedia.org/wiki/Project_Management_Body_of_Knowledgehttp://www.pmi.org