Gerenciamento de Projetos Espaciais

Planejamento, Projeto e Implementação

Norma ECSS-M-ST-10C
Agência Espacial Européia - ESA

Aluno: Thiago Duarte Pereira

Prof: Dr. Petrônio Noronha de Souza
Curso: Engenharia de Plataformas Orbitais e Cargas Úteis
Conteúdo
• Gerenciamento de Projetos
Ø Introdução
Ø Planejamento do Projeto
Ø Organização do Projeto
Ø Quebra das Estruturas do Projeto
Ø Fases do Projeto
• Gerenciamento da Configuração e Documentação
Ø Gerenciamento da Configuração
Ø Gerenciamento da Documentação
Ø Processos
- Planejamento e Gerenciamento
- Implementação do Gerenciamento da Configuração
- Implementação do Gerenciamento da Documentação

• Referências
European Cooperation for Space Standardization – ECSS
Gerenciamento de Projetos

• Abrange um conjunto de Processos.

Ø Planejamento.

Ø Criar uma organização para todas

as atividades do projeto.

Ø Definição da Quebra da Estrutura

do Projeto – PBS para:
• Identificar as responsabilidades e
tarefas de cada ator.
• Facilitar a coerência de todas as
atividades de todo o projeto.

Ø Definição das Fases e etapas que

permitam o projeto ser controlado.
Introdução

• Os iniciadores mais comuns são:

Cliente
Ø Governo, ou vários governos.
Vs. Ø Agências espaciais, nacionais ou
internacionais.
Fornecedor Ø Comunidades científicas.
Ø Operadores de sistemas espaciais
Cadeia Cliente-Fornecedor
comercias.

• Cliente: pessoa ou organização • Nesta norma, o nível mais alto do cliente

que utilizará o produto, serviço é definido como a organização
ou resultado do projeto. responsável por gerar o nível mais alto do
segmento espacial e do segmento solo,
• Fornecedor: Um provedor ou
acordos entre empresas e interfaces com
fornecedor de produtos, serviços
outros elementos externos do sistema
ou resultados para uma
espacial.
organização.
Planejamento do Projeto

• Finalidades e Objetivos do Projeto.

Ø A finalidade e objetivos são definidos pelo iniciador do projeto (project initiator).

• Disponibilidade e Necessidade de Desenvolver novas Tecnologias.

Ø Entrada principal para a avaliação dos recursos necessários, instalações e avaliação
de riscos técnicos. Deve-se identificar a disponibilidade de informação científica.

• Disponibilidade e Necessidade de Reusar Equipamentos ou Produtos

existentes.
Ø Pode ter influência significativa no custo e no cronograma.

• Disponibilidade e Necessidade de Recursos Humanos, Competências e

Instalações Técnicas.
Ø O resultado desta análise mostra se os recursos, competências e instalações são
adequadas, ou se outros recursos, competências e instalações são necessários
para concluir o projeto.

• Avaliação dos Riscos

• Abordagem ao desenvolvimento.
Planejamento do Projeto

• Liberações do Projeto
Ø Entrega dos produtos para o início do projeto.

• Restrições e Requisitos do Cliente

Ø O cliente deve preparar os requisitos e restrições do projeto de acordo com os
itens anteriores e colocar em um formato para as Solicitações de Proposta /
Request for Proposal (RFP).
Ø As RFPs apresentam técnicas e requisitos, bem como políticas comerciais,
industriais e restrições que devem ser seguidas e aplicadas ao projeto.
Ø As RFPs representam os Documentos de Requisitos do Projeto que devem ser
preparados e liberados para os potenciais fornecedores.
Planejamento do Projeto

• Documentos de Requisitos do Projeto (PRD)

• Plano de Gerenciamento do Projeto

Ø Aborda a metodologia a ser utilizada durante todo o ciclo de vida do projeto,
juntamente com uma visão geral de todos os elementos das disciplinas do projeto.
Planejamento do Projeto – Requisitos

• Clientes:
a. Cada cliente deve usar os padrões da ECSS para estabelecer o gerenciamento do
projeto, os requisitos de engenharia e garantia do produto aplicáveis ao projeto.
b. Cada cliente deve tornar aplicável aos seus fornecedores somente os padrões da
ECSS que sejam relevantes ao tipo e às fases do projeto.
c. Cada cliente deve aprovar os planos de gerenciamento e as pessoas chave dos
seus fornecedores.
d. Cada cliente deve verificar as conformidades dos seus fornecedores com relação a
todas as restrições e requisitos do projeto.
e. O cliente deve garantir que o planejamento feito para seus fornecedores esteja
consistente com os requisitos impostos ao projeto.

• Fornecedores:
a. Cada fornecedor deve preparar um Project Management Plan (PMP) e submetê-lo
ao cliente para aprovação.
Planejamento do Projeto – Requisitos

• Clientes:
a. Cada cliente deve usar os padrões da ECSS paraProject Management
estabelecer Plan
o gerenciamento do
projeto, os requisitos de engenhariaEscopo
e garantia do produto aplicáveis ao projeto.
e Conteúdo
b. <1>seus
Cada cliente deve tornar aplicável aos Introdução
fornecedores somente os padrões da
ECSS que sejam relevantes ao tipo e<2> Documentos aplicáveis e/ou de referência
às fases do projeto.
<3> Objetivos e limitações do projeto
c. Cada cliente deve aprovar os planos <4>
de Organização
gerenciamento e as pessoas chave dos
do projeto
seus fornecedores. <5> Quebra das estruturas do projeto
<6> Gerenciamento da configuração e documentação
d. Cada cliente deve verificar as conformidades dos seus
<7> Gerenciamento fornecedores
do cronograma com relação a
e custo
todas as restrições e requisitos do projeto.
<8> Apoio logístico
<9> Gerenciamento dos riscos
e. O cliente deve garantir que o planejamento feito para seus fornecedores esteja
<10> Gerenciamento da garantia do produto
consistente com os requisitos impostos ao projeto.
<11> Gerenciamento da engenharia

• Fornecedores:
a. Cada fornecedor deve preparar um Project Management Plan (PMP) e submetê-lo
ao cliente para aprovação.
Organização do Projeto

Com uma estrutura organizacional bem

• Estrutura Organizacional definida, facilita a alocação de papéis e
Ø Deve ser preparada para incluir responsabilidades individuais
todas as disciplinas essenciais para o
desenvolvimento de um projeto.

• Comunicação e relatórios
Ø Meios de comunicação são
ferramentas essenciais para garantir
clareza sobre os objetivos e metas
do projeto.

A Tecnologia da Informação é
o principal meio para a troca
de informações.
Organização do Projeto

• Auditorias
Ø São exames que determinam se os processos e os procedimentos adotados
conseguem ou conseguirão atingir os objetivos especificados.

São ideais para identificar

áreas problemáticas.

Ciclo completo de uma Auditoria

Organização do Projeto – Requisitos
• Estrutura Organizacional
Ø Clientes e Fornecedores:
a. Ambos devem definir a(s) autoridade(s) para a gestão do projeto.
b. Devem definir as responsabilidades quanto a gestão das interfaces.
c. No caso de contratação de Consultores e/ou Especialistas para dar assistência
no desenvolvimento das atividades, as regras e responsabilidades devem
também ser definidas.
d. Caso o cliente forneça um produto ou serviço ao fornecedor, o mesmo deve
ter as mesmas responsabilidades de um fornecedor.

Ø Fornecedores:
a. O fornecedor deve nomear um gestor do projeto com uma equipe sob sua
autoridade.
b. O gestor nomeado deve ter livre autoridade para executar todas as tarefas
necessárias, resolver conflitos, etc.
c. O fornecedor deve definir a equipe que irá realizar as atividades do projeto.
Organização do Projeto – Requisitos
e. O fornecedor deve demonstrar que a equipe possui a qualificação necessária,
habilidades e experiência para realizar as atividades.
f. Se o fornecedor possuir mais de um acordo dentro do projeto, cada acordo
deve ser claramente identificado.

• Relatórios e Comunicação
Ø Clientes e Fornecedores:
a. O cliente deve especificar um sistema de relatórios e um sistema de
monitoramento de ações para ser usado tanto pelo cliente quanto pelo
fornecedor.
b. Reuniões formais devem ser feitas periodicamente para rever o progresso do
projeto e relatar possíveis desvios ou alterações propostas.
c. As reuniões devem ter a participação de todos os envolvidos.
d. Um presidente e uma secretária devem ser designados no início da reunião.
e. O resultado de cada reunião deve ser documentado em uma “ata” e assinada
por todos os envolvidos na reunião.
Organização do Projeto – Requisitos
Ø Fornecedores:
a. O fornecedor deve preparar e apresentar relatórios ao cliente.
b. O fornecedor deve elaborar atas do progresso das reuniões.
c. O fornecedor deve notificar rapidamente o cliente de qualquer eventualidade
que possa afetar os objetivos do negócio em termos de custo, desempenho
técnico, cronograma, etc.

• Auditorias
a. Cada auditoria deve ser documentada em um relatório editado pelo auditor,
contendo seus pontos de vista.
b. As conclusões da auditoria devem ser debatidas antes da sua finalização.
c. Em caso de desacordo, motivos e observações devem ser relatados.
d. O relatório final da auditoria não pode ser divulgado sem antes ser aprovado pelo
fornecedor.
Organização do Projeto – Requisitos
Ø Clientes:
a. O cliente deve notificar ao fornecedor sua intenção para realizar uma
auditoria, os objetivos, o auditor designado e o cronograma da auditoria.
Ø Fornecedores:
a. O fornecedor deve aceitar ser auditado pelo cliente ou por um terceiro.
b. O fornecedor deve ter o direito de exigir ser auditado por um terceiro.
c. O fornecedor deve realizar auditorias de seu próprio trabalho e dar o direito
de participação ao cliente.
d. O fornecedor deve permitir acesso pelo cliente às suas instalações e
informações relevantes no âmbito do acordo.
Quebra das Estruturas do Projeto

• Árvore Funcional
Ø Separa o sistema dentro de funções e sub-funções.
Ø Uma análise funcional deve ser feita. Com base nesta análise, a Árvore Funcional é
estabelecida.
Quebra das Estruturas do Projeto

• Árvore Funcional
Ø Ela é a base para o estabelecimento da árvore do produto e das especificações de
requisitos técnicos preliminares.

• Árvore de Especificação
Ø Define a hierarquia relacionada a todas as especificações de requisitos técnicos
para diferentes elementos do sistema ou produto.
Quebra das Estruturas do Projeto

• Árvore do Produto

A árvore do Produto forma a

base para a definição da WBS

Ø Divisão do projeto dentro de sucessíveis níveis

de produtos ou elementos de hardware e
software.
Quebra das Estruturas do Projeto

• Quebra da Estrutura de Trabalho – WBS

Principal estrutura usada no
O trabalho de cada fornecedor é gerenciamento de um projeto.
identificado com a definição da WBS.

Ø A WBS divide o projeto dentro de pacotes de trabalho

gerenciáveis, otimizados pela natureza do trabalho.
Ø Um Pacote de Trabalho, é qualquer elemento da WBS usado para o
planejamento, monitoramento e controle.
Ø Fornece um framework para o gerenciamento do custo, cronograma, e
conteúdos técnicos.
Quebra das Estruturas do Projeto

• Quebra da Estrutura de Trabalho – WBS

Ø Fornece assistência aos participantes do projeto ao:
• Conduzir negociações do acordo do negócio.
• Otimizar a distribuição de trabalho entre os diferentes fornecedores.
Ø Uma WBS com níveis exagerados ou reduzidos pode levar a níveis de
manutenção e elaboração de relatórios irrealistas, e conseqüentemente
em um projeto ineficiente e caro.

• Existe a necessidade de melhorar a avaliação das estimativas de custo ou

da medida de progresso do elemento WBS?
• Existe mais de um indivíduo responsável pelo elemento da WBS?
A WBS deve continuar
• Será que o conteúdo do elemento WBS inclui mais de um tipo de processo
sendo decomposta? de trabalho ou produz mais de um tipo de atividade?
> 50% (SIM) – decompõe • Existe a necessidade de avaliar o custo dos processos de trabalho ou de
> 50% (NÂO) – não decompõe produtos que são internos no elemento WBS?
= 50% - BOM SENSO • Existem interações entre os resultados de um elemento WBS com outro
elemento WBS?
• Existem riscos identificados que requerem atenção específica para um
subconjunto do elemento WBS?
• Um subconjunto de trabalho a ser realizado dentro do elemento WBS
pode ser organizado em uma unidade separada?
Quebra das Estruturas do Projeto

• Quebra da Estrutura da Organização – OBS

Ø A OBS retrata as responsabilidades contratuais e interfaces externas.
Ø Ao contrário das divisões anteriores do projeto, que descreve os aspectos
funcionais, a OBS apresenta as pessoas chave e responsabilidades associadas às
partes de cada pacote na WBS.
Quebra das Estruturas do Projeto – Requisitos
a. O fornecedor deve desenvolver a árvore do produto.
b. A árvore do produto deve ser estabelecida no início da fase B e não pode ser finalizada
até a PDR.
c. Uma identificação única deve ser atribuída a cada item da árvore do produto e não
pode ser alterada antes do término do projeto.
d. O fornecedor deve estabelecer a sua WBS, incorporando a fabricação, montagem,
integração e teste de todos os produtos a ela.
e. A WBS deve ser submetida a aprovação pelo cliente.
f. Cada pacote de trabalho deve ter um único gerente responsável.
g. O fornecedor deve estabelecer a Quebra da Estrutura da Organização (OBS), incluindo:
a. As responsabilidades contratuais entre as partes envolvidas.
b. As pessoas chave e responsabilidades atribuídas para cada pacote de trabalho.

h. A OBS deve ser submetida a aprovação pelo cliente.

i. A árvore do produto e a OBS devem permanecer atualizadas no controle da
configuração.
Quebra das Estruturas do Projeto – Requisitos
a. O fornecedor deve desenvolver a árvore do produto.
b. A árvore do produto deve ser estabelecida no início da fase B e não pode ser finalizada
até a PDR.
Product Tree Document
c. Uma identificação única deve ser atribuída a cada item da árvore do produto e não
Escopo e Conteúdo
pode ser alterada antes do término do projeto.
<1> Introdução
d. O fornecedor deve estabelecer a sua WBS, <2>incorporando a fabricação,
Documentos aplicáveis e/ou demontagem,
referência
integração e teste de todos os produtos a<3> ela.Estrutura da árvore
e. A WBS deve ser submetida a aprovação pelo cliente. • Informações de cada item:
- Código de Identificação
f. Cada pacote de trabalho deve ter um único gerente responsável.
- Nome do item
g. O fornecedor deve estabelecer a Quebra da Estrutura da Organização
- Fornecedor do item(OBS), incluindo:
a. - Especificação aplicável
As responsabilidades contratuais entre as partes envolvidas.
b. • Apresentada
As pessoas chave e responsabilidades atribuídas comode
para cada pacote umtrabalho.
diagrama gráfico.
• Quando itens de missões passadas
h. A OBS deve ser submetida a aprovação pelo cliente. forem usados, os mesmos devem ser
identificados na árvore.
i. A árvore do produto e a OBS devem permanecer atualizadas no controle da
configuração.
Quebra das Estruturas do Projeto – Requisitos
a. O fornecedor deve desenvolver a árvore do produto.
b. A árvore do produto deve ser estabelecida no início da fase B e não pode ser finalizada
até a PDR.
c. Uma identificação única deve ser atribuída a cada item da árvore do produto e não
pode ser alterada antes do término do projeto.
d. O fornecedor deve estabelecer a sua WBS, incorporando a fabricação, montagem,
integração e teste de todos os produtos a ela.
e. A WBS deve ser submetida a aprovação pelo cliente.
f. Cada pacote de trabalho deve ter um único gerente responsável.
g. O fornecedor deve estabelecer a Quebra da Estrutura da Organização (OBS), incluindo:
a. As responsabilidades contratuais entre as partes envolvidas.
b. As pessoas chave e responsabilidades atribuídas para cada pacote de trabalho.

h. A OBS deve ser submetida a aprovação pelo cliente.

i. A árvore do produto e a OBS devem permanecer atualizadas no controle da
configuração.
Quebra das Estruturas do Projeto – Requisitos
a. O fornecedor deve desenvolver a árvore do produto.
b. Work
A árvore do produto deve ser estabelecida no início Breakdown
da fase B e nãostructure
pode ser -finalizada
WBS
até a PDR. Escopo e Conteúdo
c. Uma identificação única deve ser atribuída a<1> Introdução
cada item da árvore do produto e não
pode ser alterada antes do término do projeto. <2> Documentos aplicáveis e/ou de referência
<3> Estrutura da árvore
d. O fornecedor deve estabelecer a sua WBS, incorporando a fabricação, montagem,
• A WBS deve incluir as funções de
integração e teste de todos os produtos a ela. Gerenciamento do Projeto, Engenharia e
e. A WBS deve ser submetida a aprovação pelo cliente.Garantia do Produto.
• Um sistema de codificação deve ser
f. Cada pacote de trabalho deve ter um único gerente responsável.
definido para os elementos da WBS.
- Ex: um simples decimal, ou um
g. O fornecedor deve estabelecer a Quebra da Estrutura da Organização (OBS), incluindo:
sistema de código alfanumérico
a. As responsabilidades contratuais entre as partes envolvidas.
sofisticado.
b. As pessoas chave e responsabilidades atribuídas•para cada pacote
A árvore de trabalho.
deve ser apresentada na forma
de um diagrama gráfico estruturado.
h. A OBS deve ser submetida a aprovação pelo cliente.
i. A árvore do produto e a OBS devem permanecer atualizadas no controle da
configuração.
Quebra das Estruturas do Projeto – Requisitos
a. O fornecedor deve desenvolver a árvore do produto.
b. A árvore do produto deve ser estabelecida no início da fase B e não pode ser finalizada
até a PDR.
c. Uma identificação única deve ser atribuída a cada item da árvore do produto e não
pode ser alterada antes do término do projeto.
d. O fornecedor deve estabelecer a sua WBS, incorporando a fabricação, montagem,
integração e teste de todos os produtos a ela.
e. A WBS deve ser submetida a aprovação pelo cliente.
f. Cada pacote de trabalho deve ter um único gerente responsável.
g. O fornecedor deve estabelecer a Quebra da Estrutura da Organização (OBS), incluindo:
a. As responsabilidades contratuais entre as partes envolvidas.
b. As pessoas chave e responsabilidades atribuídas para cada pacote de trabalho.

h. A OBS deve ser submetida a aprovação pelo cliente.

i. A árvore do produto e a OBS devem permanecer atualizadas no controle da
configuração.
Fases do Projeto
Conduzida pelo Initiation
Project, nível mais alto do
Cliente e representante dos
Usuários Finais

Conduzida pelo nível mais alto

do Cliente e o nível mais alto do
Fornecedor

• Os ciclos de vida do projeto garantem:

Ø Que trabalho técnico deve ser realizado em cada fase.
Ø Quando as entregas devem ser geradas em cada fase e como cada entrega é
revisada, verificada e validada.
Ø Quem está envolvido em cada fase.
Ø Como controlar cada fase.
Fases do Projeto
Fases do Projeto

• Elaboração, estabelecimento, identificação e

caracterização das necessidades da Missão.
• Estudos e análises da viabilidade econômica.
• Análise preliminar dos Riscos.
Fases do Projeto

Mission Definition Review:

• Apresentar e avaliar os
requisitos preliminares da
missão
Fases do Projeto
• Estabelecimento dos Planos Preliminares de
Gestão, Engenharia e da Garantia do Produto.
• Estabelecimento da Árvore Funcional.
• Identificação das possíveis restrições de
Desenvolvimento, Custos, cronograma,
organização, operações, manutenção,
produção e descarte.
• Identificação das tecnologias críticas.
• Elaborar a avaliação de riscos.
Fases do Projeto

Preliminar Requirements Review:

• Revisar e liberar os Planos
Preliminares e todas as atividades
citadas.
Fases do Projeto
• Finalizar os Planos de Gestão, Engenharia
e da Garantia do Produto.
• Estabelecer a baseline do cronograma
principal.
• Elaborar a baseline do custo total.
• Elaborar a Quebra da Estrutura
Organizacional.
• Finalizar a Árvore do Produto e a WBS.
• Identificar e definir interfaces externas.
• Preparar a especificação dos documentos
de acordos empresariais.
• Iniciar o trabalho das tecnologias críticas
quando é necessário para reduzir riscos.
• Preparar um Plano de Descarte e um de
Eliminação do Lixo Espacial.
• Conduzir um Controle de Confiabilidade e
Segurança.
• Atualizar a avaliação dos riscos.
Fases do Projeto

System Requirements Review:

• Liberar as especificações de
requisitos técnicos do sistema.

Preliminar Designer Review:

• Análise do Projeto Preliminar.
• Lançamento dos Planos finais
de gerenciamento, engenharia e
garantia do produto.
• Lançamento da Árvore do
Produto, da WBS e Árvore de
Especificação.
Fases do Projeto
• Conclusão das definições do projeto
detalhado.
• Produção, teste do desenvolvimento dos
Modelos de Engenharia, segundo o
Modelo de Filosofia selecionado.
• Integração e planejamento dos testes para
o sistema e suas partes.
• Definição detalhada das interfaces de
comunicação internas e externas.
• Edição preliminar do Manual do Usuário.
• Atualização da avaliação de riscos.
Fases do Projeto
Critical Designer Review:
• Avaliar os processos críticos e
sua disponibilidade para a fase D.
• Lançar o Projeto Final.
• Lançar o Plano de Montagem,
Integração e Testes.
• Lançar a Manufatura do
hardware/software de vôo.
• Lançar o manual do usuário.
Fases do Projeto
• Completar os testes de qualificação.
• Completar a manufatura, montagem e
testes do hardware/software de suporte
ao solo.
• Completar os testes de interoperabilidade
entre o segmento espacial e solo.
• Preparar o pacote de dados da aceitação.
Fases do Projeto Acceptance Review:
• Confirmar que o produto está
isento de erros e está pronto para
uso.
• Verificar se todos os produtos
para entrega estão disponíveis
Qualification Review: para a lista de itens aprovados.
• Verificar se o produto foi
• Verificar se o projeto satisfaz
construído de acordo com o que
os requisitos aplicáveis.
foi especificado.
• Autorizar ou não a entrega do
produto.

Operational Readiness Review:

• Verificar a disponibilidade dos
procedimentos operacionais e sua
compatibilidade com o sistema de
vôo.
• Verificar a disponibilidade das
equipes das operações
• Aceitar e liberar o segmento solo
para operações.
Fases do Projeto
• Preparar o Lançamento.
• Realizar o Lançamento.
• Realizar as atividades de Verificação de
Órbita.
• Realizar todas as operações de órbita, de
solo e de suporte ao solo para alcançar os
objetivos da Missão.
• Finalizar o Plano de Descarte.
Fases do Projeto Commissioning Result Review
• Realizada para verificar se
todos os elementos do sistema
estão operando conforme o
esperado em órbita.
• Autoriza o início das
atividades em órbita.
• A conclusão desta revisão é
usada para marcar a entrega End‐of‐Life Review
final do produto. • Verificar se o serviço da
missão foi concluído.
• Verificar se os elementos em
Flight Readness Review: órbita foram configurados
• Feita antes do lançamento. para permitir um descarte
• Verifica se os Segmentos de seguro.
Solo e de Vôo estão prontos
para o lançamento.

Launch Readiness Review:

• Feita pouco antes do lançamento.
• Verificar a disponibilidade do veículo
lançador, segmentos espacial e solo,
sistemas de suporte, comunicação e
segurança para prover autorização ao
lançamento.
Fases do Projeto

• Execução do Plano de Descarte

Fases do Projeto

Mission Close‐out Review

• Assegurar que todas as
atividades de descarte da
missão estão adequadamente
completadas.
Fases do Projeto

Top Down

Button up
Fases do Projeto

• Revisões na Cadeia Cliente-Fornecedor

Fases do Projeto – Requisitos

• O cliente deve organizar o projeto dentro de fases seqüenciais,

incluindo todas as revisões.

• O cliente deve preparar os procedimentos das revisões do projeto.

• O cliente deve garantir que as revisões sejam feitas em paralelo com a

seqüência descendente/ascendente do plano de revisão global do
projeto.

• O cliente é quem toma a decisão de passar para a próxima fase com

base nas informações da revisão associada à fase em questão.
Fases do Projeto – Requisitos

A última cruz de cada linha indica que a

revisão esperada pelo documento é
concluída e finalizada.
ECSS-M-ST-40-C

• São partes integrais do gerenciamento do

projeto.
• Principais atividades:
Ø Planejamento e Gerenciamento.
Ø Implementação das atividades de Gerenciamento
da Configuração.
Ø Implementação das atividades de Gerenciamento
da Documentação das informações.
European Cooperation for Space Standardization
Gerenciamento da Configuração

• O Gerenciamento da Configuração é o processo para estabelecer e

manter um registro consistente das características físicas e funcionais
de um produto, referentes aos requisitos operacionais e do projeto.

• Benefícios:
Ø Permite conhecer a qualquer hora a descrição técnica de um produto, usando a
documentação aprovada.
Ø Grava, controla e provê rastreabilidade na evolução da descrição técnica de um
produto.
Ø Permite demonstrar para os atores do projeto que a documentação que é feita e
se mantém é a imagem exata dos produtos desenvolvidos.
Ø Identifica a baseline de configuração corrente.
Ø Permite conhecer as limitações de cada item do produto.
Ø No caso de uma não-conformidade, permite conhecer quais itens serão afetados.
Gerenciamento da Documentação

• O Gerenciamento da Documentação das Informações é o processo para

garantir a criação eficiente, revisão, entrega, armazenamento e
arquivamento das informações do projeto.

• Para atingir estes objetivos, todas as informações do projeto são

gerenciadas eletronicamente.

• Benefícios:
Ø Exatidão, acesso rápido, confiabilidade e segurança das informações.
Ø Garante a coerência de todas as informações do projeto, de maneira a facilitar o
efetivo e eficiente uso das informações
Ø Garante que todos os atores que necessitam de acesso às informações sejam
conscientes de sua disponibilidade, dos meios e processos de acesso.
Processos
Planejamento e Gerenciamento
• O cliente é quem deve definir os requisitos do gerenciamento da configuração.

• Com base nestes requisitos, cada fornecedor produz um Configuration

Management Plan (CM Plan) e submete-o a aprovação pelo cliente.

• CM Plan: Define os processos e recursos para gerenciar a configuração do

produto de forma controlada durante todo o ciclo de vida do projeto.

• Cada ator deve associar uma pessoa responsável pelo desenvolvimento das
atividades do Gerenciamento da Configuração e das atividades de
Gerenciamento da Documentação. Seu papel, responsabilidades e autoridades
devem ser definidos no CM Plan.

• Sistema de Informação: Repositório de informações onde os dados gerados

através das Interfaces são armazenados.

• Interfaces de Gerenciamento da Configuração e Documentação com a

Engenharia, Garantia do Produto, Manufatura e Produção contribuem para o
fornecimento de todas as informações necessárias.
Planejamento e Gerenciamento

• Interfaces
INPUTS
Planejamento e Gerenciamento

• Interfaces
OUTPUTS
Implementação do Gerenciamento da Configuração
Implementação do Gerenciamento da Configuração
Implementação do Gerenciamento da Configuração

• Identificação da Configuração
Ø Tem o propósito de identificar as características da configuração de um produto,
em relação a sua parte funcional, desempenho, características físicas, e assim
garantir a contínua integridade da configuração do produto.
Implementação do Gerenciamento da Configuração

• Identificação da Configuração
Ø Item de Configuração Desenvolvido e Não-Desenvolvido.
Ø A árvore do produto é usada para a seleção dos itens de configuração.
Implementação do Gerenciamento da Configuração

• Identificação da Configuração
Ø Baselines de Configuração: representam o Status aprovado da configuração do
produto e compreende a documentação que descreve suas características. São
aplicadas tanto pra Hardware – HW quanto Software – SW.

Ø Qualquer mudança subsequente da configuração de um produto, um

procedimento de mudança formal é realizado.

Ø Baselines estabelecidas:
- Mission Objective Baseline (MOB): estabelecida na PRR.
- Functional Configuration Baseline (FCB): estabelecida na SRR.
- Development Configuration Baseline (DCB): estabelecida na PDR.
- Design Baseline (DB): estabelecida na CDR.

Ø Cada item de HW ou SW é identificado unicamente por um código de identificação

específico. As regras para identificação dos códigos são definidas no Plano de CM.
Implementação do Gerenciamento da Configuração

Fases do Projeto e Baselines de Configuração

Implementação do Gerenciamento da Configuração
Implementação do Gerenciamento da Configuração

• Controle da Configuração
Ø É o processo usado para registrar as diferentes configurações de um produto.
Ø Garante que todas as alterações feitas, incluindo a documentação gerada e
liberada sejam controladas e processadas.
Ø Inclui cópias de backup.
Ø Atividades:
- Prevenção de mudanças que afetarão
gradativamente o projeto.
- Controle das mudanças autorizadas.
- Prevenção de mudanças não-autorizadas.
Implementação do Gerenciamento da Configuração
Implementação do Gerenciamento da Configuração

• Contabilidade do Status da Configuração

Ø Compreende a criação e organização da base de conhecimento necessária para a
execução do gerenciamento da configuração.

Ø Uma Configuration Item Data List (CIDL) é gerada para relatar o status corrente de
cada item de configuração do produto.

Ø Quando os CIs do produto de Software estão envolvidos, um arquivo de

configuração do Software também é preparado para fornecer mais informações
relevantes.
Implementação do Gerenciamento da Configuração
Implementação do Gerenciamento da Configuração

• Verificação e Auditoria da Configuração

Ø A verificação é o processo usado para verificar o status da configuração corrente
do produto analisado e os resultados no estabelecimento das baselines de
configuração.

Ø Realizadas durante as revisões do projeto.

Ø Para verificar e demonstrar que o produto conhecido está com suas funções,
desempenho e características físicas documentadas.

Ø As auditorias são realizadas para verificar se os requisitos de gerenciamento da

configuração estão sendo corretamente aplicados durante o ciclo de vida do
produto.
Implementação do Gerenciamento da Documentação
Implementação do Gerenciamento da Documentação

• s

• O conteúdo de um documento é
estabelecido e a documentação
referência é associada.
• Nesta fase, o documento fica no
Status “In Preparation”.
Implementação do Gerenciamento da Documentação

• Status “In Review”.

• Esta etapa é feita para aprovar e
liberar o documento.
• A aprovação pode ser feita por
Assinatura Eletrônica.
• A Assinatura Eletrônica garante que
o autor não possa rejeitar sua
responsabilidade pelo conteúdo do
documento.
• Ao final desta revisão, uma vez que
todas as aprovações são dadas, o
documento alcança o Status
“Released” (liberado).
Implementação do Gerenciamento da Documentação

• Os documentos são distribuídos de

acordo com os procedimentos
definidos no CM Plan.
• Os documentos são distribuidos
usando o formato Technical Data
Package (TDP), que define o
caminho para a troca de conteúdo
e para estruturá-los dentro de suas
pastas.
• O TDP é um arquivo ZIP contendo
documentos e metadados
descrevendo estes documentos.
Estão no formato XML.
Implementação do Gerenciamento da Documentação
Implementação do Gerenciamento da Documentação
Implementação do Gerenciamento da Documentação

• Armazenar e Recuperar.
Implementação do Gerenciamento da Documentação

• Garante que a documentação

do projeto seja:
Ø Preservada de danos ou
perdas;
Ø Acessível e restaurável pelo
usuário;
Ø Acesso controlado por
pessoas autorizadas.
Referências
http://www.ecss.nl/

• Norma ECSS-M-ST-10C, revisado em (6March2009).

• Norma ECSS-M-ST-40C, revisado em (6March2009).
• Guia PMBok 3ª Edição.
Frutos de má gestão...