Upload
diana-barbosa
View
218
Download
0
Embed Size (px)
DESCRIPTION
Relatório Final da cadeira de PDI
Citation preview
Faculdade de Engenharia da Universidade do Porto
Especificação de um Space Project Management Handbook
Diana Maria dos Santos Barbosa
Preparação da Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores
Major Telecomunicações
Orientador: Prof. Américo Lopes de Azevedo Coorientador: Eng. João Costa Pinto
Fevereiro de 2012
© Diana Maria dos Santos Barbosa, 2012
iii
Índice
Índice _____________________________________________________ iii
Lista de Figuras ______________________________________________ v
Lista de Tabelas _____________________________________________ vi
Abreviaturas e Símbolos ______________________________________ vii
Introdução _________________________________________ 1 Capítulo 1
1.1 MOTIVAÇÃO E ENQUADRAMENTO __________________________________________ 1 1.2 OBJETIVOS DO PROJETO _______________________________________________ 2 1.3 ESTRUTURA DO DOCUMENTO ____________________________________________ 2
Levantamento do Estado da Arte : Enquadramento Normativo Capítulo 2no Âmbito da Gestão de Projetos ________________________________ 3
2.1 INTRODUÇÃO DA NORMA IEEE 1220 – STANDARD FOR APPLICATION AND MANAGEMENT OF
THE SYSTEMS ENGINEERING PROCESS ____________________________________________ 3 2.2 APRESENTAÇÃO GERAL DAS NORMAS ECSS ___________________________________ 5 2.3 APRESENTAÇÃO DAS NORMAS ECSS RELATIVAS À GESTÃO DE PROJETOS ESPACIAIS _______ 6 2.4 ESPECIFICAÇÃO DAS NORMAS ECSS RELATIVAS À GESTÃO DE PROJETOS ESPACIAIS _______ 8
ECSS-M-ST-10C_Rev.1 Project planning and implementation _________ 8 2.4.1.
ECSS-M-ST-10-01C Organization and conduct of reviews ___________ 14 2.4.2.
ECSS-M-ST-40C_Rev.1 Configuration and information management __ 19 2.4.3.
ECSS-M-ST-60C Cost and schedule management __________________ 25 2.4.4.
ECSS-M-70A Integrated Logistic Support _________________________ 30 2.4.5.
ECSS-M-ST-80C Risk management ______________________________ 32 2.4.6.
Proposta de um Space Project Management Handbook : Capítulo 3Ferramentas e Plataformas, Objetivos e Funcionalidades ____________ 40
3.1 PLATAFORMAS EM UTILIZAÇÃO PELA EQUIPA DE PROJETO _______________________ 40 3.2 INTEGRAÇÃO DO SPACE PROJECT MANAGEMENT HANDBOOK _____________________ 41 3.3 PRINCIPAIS OBJETIVOS ________________________________________________ 41
iv
3.4 PRINCIPAIS FUNCIONALIDADES __________________________________________ 42
Plano de Trabalho __________________________________ 44 Capítulo 4
4.1 PLANEAMENTO _____________________________________________________ 44 4.2 PARTES ENVOLVIDAS _________________________________________________ 45
Referências ________________________________________________ 46
v
Lista de Figuras
Figura 2.1 – Esquema da ramificação das normas ECSS (fonte: ecss.nl – ECSS ARCHITECTURE) 5 Figura 2.2 – Ramificação dos standars para gestão de projetos espaciais (fonte: ecss.nl –
MANAGEMENT BRANCH) ______________________________________________________ 6 Figura 2.3 – Diagrama de processamento de uma RID (fonte: ECSS-M-ST-10-01C Annex E) __ 18 Figura 2.4 – Inputs da interface da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1) __ 20 Figura 2.5 – Ouputs da interface da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1) _ 21 Figura 2.6 – Implementação da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1) _____ 22 Figura 2.7 – Esquema da configuração de identificação (fonte: ECSS-M-ST-40C Rev.1) _____ 23 Figura 2.8 – Diagrama representativo das fases constituintes da implementação da gestão de
informação/documental (fonte: ECSS-M-ST-40C Rev.1) ___________________________ 24 Figura 2.9 – Vista geral da análise funcional da gestão de custos e de horários (fonte: ECSS-M-
ST-60C) ___________________________________________________________________ 26 Figura 2.10 – Processo iterativo da gestão de risco (fonte: ECSS-M-ST-80C) ______________ 33 Figura 2.11 – Tarefas associadas a cada passo do processo iterativo da gestão de risco (fonte:
ECSS-M-ST-80C) ____________________________________________________________ 34
vi
Lista de Tabelas
Tabela 2.1 – Exemplo de um diagrama de Gantt: atividades e durações (fonte: ECSS-M-ST-
60C) ______________________________________________________________________ 28 Tabela 2.2 – Exemplo da ferramenta “traffic light” (fonte: ECSS-M-ST-60C) _____________ 29 Tabela 2.3 – Sistema de classificação da severidade das consequências (fonte: ECSS-M-ST-80C)
__________________________________________________________________________ 35 Tabela 2.4 – Sistema de classificação da probabilidade de ocorrência do risco (fonte: ECSS-M-
ST-80C) ___________________________________________________________________ 35 Tabela 2.5 – Sistema de classificação do índex de risco e esquema de magnitude (fonte: ECSS-
M-ST-80C) _________________________________________________________________ 35 Tabela 2.6 – Exemplo das designações das magnitudes de risco e ações propostas (fonte:
ECSS-M-ST-80C) ____________________________________________________________ 36 Tabela 2.7 – Exemplo de uma análise de tendência de risco (fonte: ECSS-M-ST-80C) _______ 38 Tabela 4.1 – Planeamento do trabalho a ser desenvolvido durante a Dissertação __________ 45 Tabela 4.2 – Partes envolvidas na Dissertação apresentada no documento _______________ 45
vii
Abreviaturas e Símbolos
Lista de Abreviaturas
ESA – European Space Agency
SPMH – Space Project Management Handbook
IEEE - Institute of Electrical and Electronics Engineers
SEP – Systems Engineering Process
ECSS - European Cooperation for Space Standardization
PBS - Project Breakdown Structure
RID – Review Item Discrepancy
PRD - Project Requirements Documents
WBS - Work Breakdown Structure
OBS - Organization Breakdown Structure
MDR - Mission Definition Review
SRR - System Requierements Review
PDR - Preliminary Design Review
CDR – Critical Design Review
QR – Qualification Review
AR – Acceptance Review
ORR – Operational Readiness Review
FRR – Flight Readiness Review
LRR – Launch Readiness Review
CRR – Commissioning Result Review
ELR – End of Life Review
MCR – Mission Close-out Review
PMP - Project Management Plan
RAR - Review Authority Report
CM – Configuration Management
CI – Configuration Item
viii
CCB – Configuration Control Board
CCS – Country/Company Structure
CCN – Contract Change Notice
DCP – Development Cost Plan
CBS – Cost Breakdown Structure
OBCP – Original Baseline Cost Plan
CBCP – Current Baseline Cost Plan
EAC – Estimate At Completion
ETC – Estimate To Completion
ILS – Integrated Logistic Support
INTRODUÇÃO Capítulo 1
O projeto a ser desenvolvido no âmbito de Dissertação tem como principal objectivo a
especificação de um Space Projects Management Handbook, isto é, a especificação de um
sistema baseado num conjunto de normas disponibilizadas pelo European Cooperation for
Space Standardization (ECSS) aplicadas à gestão de projetos que permitirá uma gestão mais
eficaz de todos os projetos espaciais desenvolvidos pela Divisão de Produção Electrónica e
Aeroespacial da EFACEC.
1.1 Motivação e enquadramento
A motivação para o tema da Dissertação surgiu a partir de um interesse pessoal pela área
espacial e o gosto pela área de gestão de projetos. Este tema foi autoproposto, por mim,
através do interesse demostrado pela Divisão de Produção Electrónica e Aeroespacial da
EFACEC, numa primeira avaliação às necessidades demonstradas pela equipa durante o
desenvolvimento dos projetos espaciais efectuados em contratos com a ESA.
Na tentativa de desenvolver um trabalho digno de Dissertação e ao mesmo tempo de
interesse prático para a empresa, foram levantadas questões relativas à eficácia da gestão
dos projetos ao longo do seu desenvolvimento e das atividades de controlo utilizadas.
Verificou-se que a gestão utilizada apresentava aspetos que poderiam beneficiar de um
melhoramento, pelo que se demonstrou o interesse de avançar com o projeto que me
proponho a desenvolver.
O objectivo é especificar um Space Project Management Handbook, SPMH, que constituirá
uma plataforma informática e que terá como base todas as normas aplicadas à gestão de
projetos disponibilizadas pelo ECSS bem como documentos de requisitos normativos. Tratar-
se-á, ainda, de um auxiliar importante para toda a equipa de projeto no que diz respeito a
planeamento de atividades, reuniões, tarefas e controlo de responsabilidades.
O SPMH a desenvolver, irá ajudar a equipa na preparação e emissão de relatórios de
progresso sujeitos a avaliação rigorosa por parte da ESA.
Devido à elevada complexidade existente na gestão dos projetos espaciais, torna-se
necessária a existência de uma check-list diária de forma a, atempadamente, garantir todas
as etapas do seu desenvolvimento, especialmente no que diz respeito ao cumprimento das
normas ECSS.
2
2
A organização de todas as tarefas é essencial para garantir o correto desenvolvimento de
todas as atividades, sistematizando as normas ECSS e os outros requisitos contratuais, com
vista a ser possível criar to-do lists diárias, semanais ou mensais.
O SPMH irá permitir também ao gestor de projetos um controlo ativo e mais eficaz sobre
a sua equipa e atividades durante todo o ciclo de vida do projeto.
1.2 Objetivos do projeto
O tema escolhido para o trabalho de Dissertação tem como objectivo estudar e
especificar todos os elementos necessários para a criação de um handbook dedicado à gestão
de projetos espaciais na empresa EFACEC.
O handbook deverá cobrir todos os requisitos ligados à gestão de projetos assim como
possuir as especificações exigidas nas normas disponibilizadas pelo European Cooperation on
Space Standardization (ECSS).
Estas normas disponibilizadas pelo ECSS têm como objectivo principal a criação de regras
standard que facilitem e estabeleçam um desenvolvimento coerente em todas as atividades
espaciais europeias.
Este projeto vai de encontro às necessidades da divisão no que diz respeito à gestão de
todos os projetos efectuados em parceria com a Agência Espacial Europeia (ESA) que
necessitam de um controlo rigoroso no cumprimento das normas ECSS, assim como, nas
tarefas associadas a cada etapa do projeto. O Space Project Management Handbook permitirá
ao gestor de projetos um controlo ativo sobre os projetos em desenvolvimento.
1.3 Estrutura do documento
A estrutura deste documento está dividida em quatro capítulos, o primeiro realiza uma
pequena introdução ao tema assim como ao seu enquadramento e motivação, o segundo diz
respeito à apresentação da norma IEEE 1220 e à análise das normas para gestão de projetos
espaciais disponibilizadas pelo ECSS, o terceiro capítulo apresenta algumas plataformas
existentes e utilizadas pela equipa de projeto na gestão das atividades, tarefas e
calendarização dos projetos espaciais, por fim o quarto capítulo apresenta os principais
objetivos do SPMH e funcionalidades básicas. Todas as figuras e tabelas apresentadas neste
documento são retiradas das normas disponibilizadas pelo ECSS e identificadas pela respetiva
legenda.
LEVANTAMENTO DO ESTADO DA Capítulo 2ARTE : ENQUADRAMENTO NORMATIVO
NO ÂMBITO DA GESTÃO DE PROJETOS
2.1 Introdução da norma IEEE 1220 – Standard for Application and Management of the Systems Engineering Process
A aplicação da gestão dos processos em sistemas de engenharia exige uma vasta e
complexa implementação de regras base, definidas como tarefas interdisciplinares,
necessárias ao longo do ciclo de vida do sistema, de forma a criar soluções para as
necessidades de todas as partes interessadas, para os requisitos especificados e para todas as
restrições identificadas.
O objetivo desta norma é criar um standard para gerir um sistema desde a sua definição
inicial até ao seu desenvolvimento, estado operativo e por fim encerramento. De forma a
gerar um sistema mais preciso, é necessário incluir os componentes humanos de hardware e
de software de forma a optimizar a performance do sistema.
Um sistema é tipicamente composto por subsistemas e componentes e suas interfaces. Os
elementos de um sistema incluem todos os atores necessários para desenvolver, produzir,
testar, distribuir, operar, manter ou descartar os produtos.
Os elementos de origem humana são parte integral de um sistema e devem estar
presentes em todos os níveis. Estes elementos não são identificados na hierarquia do sistema
pois a intenção é identificar os elementos que o definem e as integrações necessárias em
todas as etapas de operação, produção, manutenção, etc. O nº de elementos de um sistema
depende diretamente do seu nível de complexidade.
Um sistema deve ser representado através de uma estrutura de blocos onde todos os
processos de ciclo de vida necessários para manter e gerir todos os subsistemas são
identificados. Todo um processo de ciclo de vida, isto é, desde o desenvolvimento, produção,
4
4
teste, distribuição, operação, manutenção até ao seu descarte, é ele mesmo considerado
como um sistema. Quando o objetivo e necessidade de um processo de ciclo de vida é
identificado, o processo é tratado como um sistema e o systems engineering process (SEP) é
aplicado para definir, desenhar e estabelecer os processos e produtos, necessários para
manter o processo em condições ideais de operação.
É necessário num sistema definir o plano de engenharia e atualizá-lo ao longo do seu ciclo
de vida de forma a guiar e controlar os esforços técnicos do projeto. O plano de engenharia
deverá refletir o esforço técnico integrado no desenvolvimento do produto que vai de
encontro aos requisitos do sistema. É importante definir os subsistemas para cada produto
assim como definir o seu design, requisitos funcionais e requisitos de performance assim
como identificar restrições e/ou limitações detetadas.
Os fatores de qualidade de sistema devem ser definidos em termos de influência à
capacidade de atingir os requisitos estabelecidos de forma a serem decompostos e alocados
dentro dos processos e subsistemas do ciclo de vida do sistema principal.
Após a definição inicial do sistema, devem ser efetuadas revisões de forma a determinar
se o sistema definido é suficiente para proceder à definição do subsistema. A arquitetura
funcional e física do subsistema deve ser definida e os riscos, associados a cada processo,
avaliados e registados para tratamento futuro.
Uma análise importante e essencial na gestão de um sistema é a análise dos requisitos
com o objetivo de estabelecer o que é que o sistema será capaz de atingir, a que níveis de
qualidade irão os produtos operar, em que ambientes é que estes estarão em funcionamento,
os requisitos humanos ou de interfaces de sistema que são necessários e que
restrições/limitações é que o sistema irá apresentar que possam afetar as soluções
programadas. As necessidades do mercado alvo, as expectativas de todas as partes
interessadas e as possíveis limitações externas são analisadas de forma a ser possível definir
requisitos de alto nível para o sistema. A validação dos requisitos deve ser estabelecida na
fase de levantamento dos mesmos para assegurar que estes representam as necessidades e
vão de encontro às expectativas dos consumidores finais.
Neste capítulo irão ser apresentadas as normas relativas à gestão de projetos espaciais
que aplicam todos os conceitos da norma IEEE 1220 e ainda outros elementos adicionais
específicos aos projetos espaciais.
Apresentação geral das normas ECSS
5
5
2.2 Apresentação geral das normas ECSS
As normas ECSS têm como objectivo principal a criação de regras standard que facilitem e
estabeleçam um desenvolvimento coerente entre todos os projetos espaciais europeus. No
caso da EFACEC, a Divisão de Produção Electrónica e Aeroespacial utiliza as normas ECSS
como guias através das quais consegue realizar uma boa gestão dos projetos em contrato com
a ESA.
Estas normas foram criadas num esforço cooperativo entre a ESA, agências espaciais
nacionais e associações industriais europeias de modo a garantir standards comuns. Os
requisitos standards são definidos em termos de objectivos a alcançar, não contemplando, no
entanto, a forma de organizar e aplicar o trabalho necessário para os atingir.
A normas ECSS estão organizadas em três grupos, Engenharia Espacial (Space Engineering),
Gestão de Projetos Espaciais (Space Project Management) e Garantia de Produto Espacial
(Space Product Assurance). A ramificação dos três grupos é apresentada na figura 2.1.
Figura 2.1 – Esquema da ramificação das normas ECSS (fonte: ecss.nl – ECSS ARCHITECTURE)
6
6
2.3 Apresentação das normas ECSS relativas à gestão de projetos espaciais
A ramificação que será utilizada na especificação do SPMH diz respeito à gestão de
projetos espaciais que está disponível para download de forma livre a partir do site do ECSS e
é apresentada na figura 2.2. As normas que constituem a ramificação relativa à gestão de
projetos espaciais, estão divididas em seis partes para as quais se seguem pequenas
descrições:
Figura 2.2 – Ramificação dos standars para gestão de projetos espaciais (fonte: ecss.nl – MANAGEMENT
BRANCH)
• ECSS-M-ST-10C_Rev.1 Project Planning and Implementation
Esta norma diz respeito às diferentes áreas de um projeto tais como, o planeamento das
fases do projeto, organização, analise estrutural e organização temporal das fases de
trabalho. No que toca ao planeamento de um projeto, são considerados os requisitos do
cliente e dos fornecedores.
Apresentação das normas ECSS relativas à gestão de projetos espaciais
7
7
Em relação aos requisitos organizacionais de um projeto, são apresentados os que se
referem à estrutura organizacional, comunicação e relatórios, e auditorias. São também
especificados os requisitos referentes ao Project Breakdown Structure, PBS.
• ECSS-M-ST-10-01C Organization and Conduct of Reviews
Esta norma diz respeito à realização de revisões e todas as etapas que as constituem,
desde a sua fase inicial, passando pela preparação de pacotes de dados para revisão, revisão
da documentação e finalmente as conclusões e descobertas relevantes a apontar.
Os requisitos da organização e realização de revisões são apresentados relativamente à
atribuição das responsabilidades, tarefas e distribuição de autoridade.
As reuniões de revisão são igualmente especificadas, através da definição dos
pressupostos, da agenda das reuniões, da iniciação das reuniões, da coordenação das
reuniões, definição da equipa de avaliações e conclusões das reuniões e ainda definição das
ações subsequentes.
O processamento RID e a ação de seguimento de itens também serão pontos abordados
por esta norma.
• ECSS-M-ST-40C_Rev.1 Configuration and Information Management
Os princípios da gestão de configuração são apresentados nesta norma através de uma
visão geral sobre a documentação e informação de atividades, gestão de processos e
objectivos. A gestão do plano de configuração e de interfaces de gestão são especificadas,
bem como a respectiva implementação, através da identificação de configuração, controlo,
ponto de situação, verificação, processo de auditoria da gestão de configuração, gestão de
condução para fases de operações e implementação da gestão de informação/documentação.
Os requisitos para a gestão de configuração são divididos em duas partes, gestão e
planeamento e implementação.
• ECSS-M-ST-60C Cost and Schedule Management
Nesta norma são especificados os princípios comuns à gestão de custos e de planeamento
identificando a sua estrutura de projeto, tipos de acordos de negócio e a gestão de riscos.
Os princípios exclusivos à gestão de planeamento são divididos em três tópicos: definição,
controlo e relatório de acompanhamento.
8
8
Os princípios exclusivos à gestão de custos são divididos em cinco tópicos: interfaces
contratuais e financeiras, planeamento, estimação de custos, controlo de custos e declaração
de custos.
Os requisitos comuns à gestão de custos e de planeamento são especificados na estrutura
de projeto e na gestão de riscos.
• ECSS-M-70A Integrated Logistic Support
O apoio logístico integrado é especificado nesta norma através dos seus princípios
fundamentais dentro do contexto de cada projeto.
Os requisitos para a gestão do ILS estão divididos em requisitos para o controlo de
atividades logísticas, requisitos para a analise de sistemas e requisitos para relatórios de
acompanhamento. No contexto dos projetos espaciais a necessidade do ILS diz respeito ao
desenvolvimento dos recursos materiais e serviços essenciais nas operações de suporte,
manutenção e controlo, particularmente na utilização de custos e disponibilidade de
produtos/serviços.
• ECSS-M-ST-80C Risk Management
Os princípios da gestão de risco apresentam-se nesta norma através do seu conceito
principal, do processo, da implementação num projeto e da documentação. Os passos e
tarefas características do processo da gestão de risco e a implementação da gestão de risco
são também especificados.
No que diz respeito à implementação da gestão de risco são feitas considerações gerais,
bem como especificadas as responsabilidades, o ciclo de vida do projeto, a visibilidade do
risco, tomada de decisões e documentação da gestão de risco. Os requisitos dos processos da
gestão de risco e da implementação da mesma são igualmente especificados nesta norma.
2.4 Especificação das normas ECSS relativas à gestão de projetos espaciais
Neste capítulo são apresentadas e analisadas as normas relativas ao ramo da gestão de
projetos espaciais. Estas normas dizem respeito às diferentes áreas da gestão de projetos.
Cada norma possui documentos normativos que irão ser integrados no SPMH respeitando todos
os requisitos especificados.
ECSS-M-ST-10C_Rev.1 Project planning and implementation 2.4.1.
O planeamento e implementação de projetos são conseguidos estabelecendo os requisitos
Especificação das normas ECSS relativas à gestão de projetos espaciais
9
9
do projeto e reconhecendo as suas limitações. A definição de fases ao longo do ciclo de vida
do projeto e dos seus marcos temporais permite um melhor e mais eficiente controlo
relativamente a custos, calendarização e objectivos técnicos.
É necessário também definir o Project Breakdown Structure (PBS), isto é, a arquitetura
da estrutura do projeto que constitui uma forma única para o gestor de projeto controlar e
supervisionar todo o sistema em termos de identificação de tarefas e atribuição de
responsabilidades a diferentes atores, facilitar a coerência entre todas as atividades do
projeto e programar uma calendarização e custo de atividades.
i. Planeamento do projeto
O planeamento e implementação do projeto envolve a identificação de todos os processos
necessários ao planeamento e execução de um projeto espacial desde a sua iniciação à sua
conclusão em todos os níveis da cadeia cliente-fornecedor de uma forma coordenada,
eficiente e estruturada.
Os principais objectivos do projeto são definidos pelo iniciador do projeto na declaração
da missão inicial que inclui os parâmetros chave de performance, assim como, limitações
técnicas e programáticas que possam existir.
No planeamento de projetos espaciais é necessário identificar uma série de tópicos antes
de iniciar o planeamento organizacional dos mesmos, bem como, verificar a disponibilidade
ou necessidade de desenvolvimento de novas tecnologias, reutilização de
equipamentos/produtos, recursos humanos, habilitações e instalações técnicas. A avaliação
da análise de risco é também importante, assim como, a abordagem do desenvolvimento do
projeto, entrega de documentação e requisitos/restrições impostas pelo cliente.
Em projetos espaciais a apresentação e entrega de documentos é necessária ao longo de
todo o ciclo de vida do projeto, a estes documentos designamos de Project Requirements
Documents (PRD), estes documentos dizem respeito tipicamente ao trabalho desenvolvido,
requisitos técnicos, requisitos de gestão, engenharia e garantia de produto.
O plano de gestão do projeto define a abordagem da gestão do projeto e metodologia
adoptada ao longo do seu ciclo de vida assim como uma visão geral de todos os elementos
necessários à sua gestão. O plano inclui uma definição do sistema de engenharia envolvido e
da garantia de produto que juntos representam toda a documentação de planeamento
necessária à implementação do projeto.
ii. Organização do projeto
Estabelecer uma estrutura organizacional coerente para a implementação do projeto em
todos os níveis da cadeira cliente-fornecedor é um factor chave para assegurar uma gestão
eficiente e eficaz do projeto.
10
10
É necessário que a organização estrutural do projeto inclua todas as especialidades
essenciais para a implementação do mesmo com as funções bem definidas, assim como,
linhas de apresentação de relatórios e interfaces relacionais. A organização estrutural
oferece uma definição clara e não-ambígua de todos os papéis e responsabilidades bem como
de todos os níveis de autoridade associados.
A comunicação e a apresentação de relatórios são ferramentas importantes para garantir
uma interação entre todos os atores ativos no projeto, entre a equipa de desenvolvimento e
entre eventuais interfaces exteriores. A comunicação oferece clareza na definição dos
objetivos a atingir e por consequência um apoio diário ao trabalho desenvolvido pela equipa
de projeto. Relatórios regulares são ferramentas importantes na troca de informação no que
diz respeito ao progresso do projeto.
Outra ferramenta importante é a realização de auditorias, de forma a determinar se os
processos e os procedimentos atingem os objectivos especificados. São essenciais para a
identificação de áreas problemáticas.
iii. Project Breakdown Structure
O PBS disponibiliza uma visão do projeto quebrada até aos seus elementos base. A
function tree, isto é, a árvore de processos, oferece uma visão de todos os processos e
subprocessos independentemente do tipo de produto envolvido. Esta abordagem, é realizada
na fase da definição do projeto.
Por sua vez a specification tree, isto é, a árvore de especificações, define as relações
hierárquicas de todas as especificações dos requisitos técnicos dos elementos do sistema ou
do produto.
Finalmente a product tree, árvore de produto, inclui os itens submetidos ao controlo da
configuração do cliente, assim como, os itens referentes à especificação técnica de requisitos.
Esta árvore, forma a base necessária à elaboração do Work Breakdown Structure (WBS).
O WBS é a principal estrutura usada na gestão de projetos pois oferece o quadro
necessário à gestão de custos, calendarização e de conteúdos técnicos. Divide o projeto em
pacotes de trabalho organizados segundo a natureza do trabalho, aumentando, assim, o nível
de detalhe. Os pacotes de trabalho podem ser divididos em três áreas, planeamento,
supervisão e controlo.
A Organization Breakdown Structure (OBS) identifica as partes responsáveis por cada
pacote de trabalho apresentado no WBS.
iv. Planeamento de fases do projeto
O ciclo de vida dos projetos espaciais está dividido tipicamente em sete fases que estão
ligadas a atividades ao nível do sistema e do produto. As diferentes fases de um
Especificação das normas ECSS relativas à gestão de projetos espaciais
11
11
projeto podem-se sobrepor, dependendo de circunstâncias especificas, risco envolvido e de
atividades que possam sobrepor-se a diferentes fases do projeto.
A fase 0 (Análise da missão e Identificação das necessidades) é conduzida somente pelo
iniciador do projeto e pelo cliente. As principais tarefas nesta fase são, a elaboração do
objectivo da missão, isto é, identificação e caracterização das necessidades da missão,
performance esperada e objectivos a atingir em termos de segurança, assim como, as
restrições de operação. A especificação técnica preliminar de requisitos e identificação de
conceitos da missão, assim como, uma primeira analise de risco deverão ser feitas nesta fase.
Em termos documentais, esta fase, tem como documento normativo a Mission Definition
Review (MDR) que determinará se o projeto se encontra pronto para seguir para a fase
seguinte.
A fase A (Viabilidade) tem como principais tarefas o estabelecimento de planos de gestão,
de engenharia e de garantia de produto, a elaboração do sistema, a definição de conceitos de
operação e de arquitetura do sistema, e compará-los com a identificação das necessidades,
de modo, a determinar os níveis de risco e de incerteza. A realização da function tree é feita
nesta fase, assim como, a identificação da viabilidade dos conceitos, identificando as
restrições relativas à implementação, custos, calendarização, organização, operações,
manutenção, produção e processo de descarte.
A seleção do sistema, conceitos de operações e soluções técnicas, incluindo a filosofia de
modelos e a abordagem de verificação, são necessárias para a aceitação da passagem à fase
seguinte.
Na fase B (Definição preliminar) é necessário finalizar os planos de gestão, de engenharia
e de garantia de produto, bem como, estabelecer uma calendarização base do projeto. O OBS
é elaborado nesta fase, assim como, a preparação dos documentos para ser efetuado o
acordo de negócio. É essencial a finalização da product tree, do WBS e da specification tree.
Na fase B, é necessária a elaboração de dois documentos normativos, o System
Requierements Review (SRR) e o Preliminary Design Review (PDR), este último determina a
viabilidade do projeto passar à fase seguinte.
Os tópicos a analisar no SRR serão as especificações dos requisitos técnicos, a avaliação
da definição preliminar de design e do programa de verificação. No PDR, os tópicos
analisados, serão a verificação do design preliminar e soluções técnicas em relação aos
requisitos do projeto e do sistema, a apresentação dos planos finais de gestão, de engenharia
e de garantia de produto, a product tree, o WBS, a specification tree e finalmente o plano de
verificação (incluindo a filosofia de modelos).
12
12
A fase C (Definição detalhada) tem como documento normativo o Critical Design Review
(CDR) que terá que incluir a avaliação da qualificação e validação do estado dos processos
críticos, confirmar a compatibilidade com interfaces externas, a apresentação do design final,
a montagem, a integração e planeamento de testes, assim como, a apresentação da produção
de hardware/software. O manual de utilização do utilizador também deverá ser realizado.
Na fase D (Qualificação e Produção) as principais tarefas a realizar são, a definição de
atividades completas associadas aos testes e verificação do produto, a realização de testes
de interoperabilidade, entre os segmentos espaço e terra, e a preparação da aceitação dos
pacotes de dados.
Os três relatórios normativos associados a esta fase são o Qualification Review (QR),
Acceptance Review (AR) e Operational Readiness Review (ORR). No que diz respeito ao QR, é
necessário confirmar que o processo de verificação demonstra que o design vai de encontro
aos requisitos, verificar que o registo do processo de verificação está completo em todos os
níveis da cadeia cliente-fornecedor e verificar a aceitação de todas as renúncias e desvios. O
AR verifica se o produto fabricado e os seus componentes estão de acordo com o produto
idealizado, verifica também a aceitação do pacote de dados e autoriza a entrega do produto
e do seu certificado de autorização. Por fim, o ORR tem como objectivo verificar a
viabilidade dos procedimentos operacionais e a sua compatibilidade com o sistema de voo.
Na fase E (Operações/Utilização) todas as atividades no espaço e em terra são efectuadas,
assim como, todas as operações em orbita, de forma a atingir os objectivos especificados
para a missão. O plano de descarte deverá ser finalizado.
Os relatórios a apresentar nesta fase serão os Flight Readiness Review (FRR), o Launch
Readiness Review (LRR), o Commissioning Result Review (CRR) e finalmente o End of Life
Review (ELR). O FRR é realizado anteriormente ao lançamento, o objectivo deste relatório
será verificar todos os sistemas de apoio em terra, comunicações e segurança. Por sua vez o
LRR irá autorizar o lançamento, através da verificação de todos os sistemas e segmentos de
apoio, comunicação e segurança de lançamento.
O CRR é elaborado no final da verificação, em orbita, de todos os sistemas e parâmetros
de performance que permitem declarar a viabilidade de todas as operações de rotina. Por fim,
o ELR irá assegurar que a missão completou todas as operações necessárias e garantir que
todos os elementos em orbita estão configurados e prontos a serem descartados com
segurança.
A fase final F (Descartar) implementa o plano de eliminação da missão e emite um
relatório designado de Mission Close-out Review (MCR) que assegura que todas as atividades
designadas para a eliminação da missão estão completas.
Especificação das normas ECSS relativas à gestão de projetos espaciais
13
13
v. Requisitos do cliente
Todos os clientes devem preparar o contrato de negocio incluindo o Project Requirements
Documents (PRD) a ser aplicado entre este e o fornecedor. Os standards ECSS devem ser
seguidos ao longo de todo o projeto podendo variar a sua utilização de acordo com a natureza
do projeto a desenvolver.
vi. Requisitos do fornecedor
Todos os fornecedores de um projeto espacial devem elaborar o Project Management
Plan (PMP,) em conformidade com o standard, disponibilizado pelo ECSS. Este PMP deverá ser
submetido ao cliente para aprovação.
O plano de gestão do fornecedor deve garantir que todos os recursos necessários ao
desenvolvimento do projeto estão devidamente localizados, de forma a assegurar a duração
acordada no contrato, assim como, nomear um gestor de projeto e uma equipa de
desenvolvimento para o mesmo. O gestor de projeto terá a autoridade necessária para
realizar todas as tarefas e atividades da sua responsabilidade, assim como, definir todos os
atores com qualificação e habilitações necessárias para que a equipa seja capaz de atingir os
seus objetivos.
Deverá existir uma organização que permita um controlo e supervisionamento de todas as
atividades, de forma a garantir que estas se encontram de acordo com os requisitos
especificados pelo cliente.
vii. Comunicação, relatórios e auditorias
Um sistema de controlo constante é importante em todos os projetos espaciais, portanto,
é necessária a existência de relatórios e reuniões entre os elementos da equipa e com o
cliente, de modo a garantir um fluxo de informação constante. Em cada reunião, deverão ser
registadas todas as tomadas de decisão e ações incluindo a identificação única de cada uma,
a descrição e o ator responsável pela tarefa.
O fornecedor deverá emitir relatórios de progresso conforme o standard disponibilizado
pelo ECSS e submeter o mesmo para aprovação do cliente.
No que diz respeito a auditorias, o cliente deverá notificar o fornecedor da sua intenção
de realizar uma auditoria, os objetivos da mesma, o auditor responsável e suas referências e
por fim a data e hora desejadas. Por sua vez, o fornecedor deverá autorizar qualquer
auditoria solicitada pelo cliente e terá o direito de requisitar uma terceira entidade para
realizar a auditoria desde que seja de acordo mútuo entre o cliente e o fornecedor. O
14
14
fornecedor deverá também efetuar as suas próprias auditorias às atividades do projeto, de
modo a verificar a conformidade com os requisitos especificados para as mesmas. O cliente
terá direito a aceder às instalações do fornecedor e a dados relevantes dentro do contrato
efectuado.
Todos os documentos normativos são disponibilizados pelo ECSS a qualquer utilizador ou
interveniente num projeto espacial.
viii. Arquitetura da estrutura do projeto
O fornecedor deverá elaborar e emitir todos os relatórios normativos respectivos às fases
que o projeto atravessa durante o seu ciclo de vida. A estrutura organizacional deverá
também garantir uma comunicação eficiente entre atividades e operações realizadas pela
equipa de desenvolvimento. Todos os documentos sujeitos a aprovação por parte do cliente,
devem ser apresentados respeitando o tempo de entrega estipulado.
ECSS-M-ST-10-01C Organization and conduct of reviews 2.4.2.
O principal objetivo desta norma é providenciar os meios necessários à identificação e
estruturação de todas as atividades sujeitas a revisão durante um projeto. É essencial a
análise de toda a informação de saída das atividades que completam os processos de um
projeto de forma a detectar eventuais discrepâncias em relação aos objetivos estipulados.
Nesta norma são referidas três entidades diferentes, o consumidor que, no caso deste
projeto, se refere à ESA, o cliente, sendo a Divisão de Produção Electrónica e Aeroespacial da
EFACEC e por fim o fornecedor que representa todas as entidades contratadas pelo cliente
para desenvolvimento de elementos durante o projeto.
As revisões dos projetos são essencialmente análises ao estado de um projeto num certo
período de tempo e que permitem verificar se o progresso em curso é igual ao esperado.
i. Tarefas das revisões
Uma revisão é composta por diferentes tarefas que juntas permitem realizar uma boa
análise das atividades em questão. Estas tarefas são então, a iniciação da revisão onde são
nomeados membros da revisão e entidades sujeitas à mesma, a preparação e distribuição do
pacote de dados, isto é, da documentação necessária à revisão, a revisão da documentação,
onde são identificados todos os problemas, questões e soluções que surgem durante a análise
que por sua vez serão registados no formulário Review Item Discrepancy (RID)
Especificação das normas ECSS relativas à gestão de projetos espaciais
15
15
disponibilizado pelo ECSS. Este documento regista as discrepâncias encontradas e vai servir
de apoio às reuniões entre a equipa de revisão e o cliente/fornecedor. Todas as questões
levantadas e recomendações sugeridas são registadas pela equipa de revisão.
Finalmente a última tarefa diz respeito à análise dos registos emitidos pela equipa de
revisão, à confirmação das recomendações e às decisões de acompanhamento das atividades
e por fim à confirmação do alcance dos objetivos da revisão.
ii. Requisitos
A revisão do projeto deverá aconselhar o cliente através de recomendações que tenham
como objetivo a resolução de qualquer deficiência identificada durante os processos. É
necessária a verificação do cumprimento dos objetivos do projeto, o registo adequado dos
requisitos, a credibilidade do design, desenvolvimento e verificação, a análise de risco e a
credibilidade do planeamento e calendarização. O cliente deverá organizar as revisões com a
aprovação do consumidor.
A revisão do pacote de dados deve estar de acordo com os documentos entregues
especificamente para a revisão em questão e que estes sejam suficientes para demonstrar a
realização dos objetivos.
As entidades responsáveis pelas revisões são o consumidor, o cliente e o fornecedor, no
entanto os membros da autoridade revisora são exclusivamente nomeados pela organização
do consumidor embora possa existir um membro representativo da organização do cliente.
iii. Papéis e tarefas
Os papéis e tarefas atribuídas a cada interveniente da equipa de desenvolvimento do
projeto são designados pelo gestor de projeto de acordo com a necessidade de habilitações
associadas a cada atividade. Todas as tarefas são sujeitas a revisões de modo a garantir a
conformidade com os requisitos especificados e de forma a verificar que os outputs obtidos
são os desejados.
iv. Autoridade Revisora
A autoridade revisora deve aprovar o procedimento da revisão e seus objetivos, a
composição da equipa de revisão e a execução da revisão. No final de uma revisão, a equipa
da autoridade revisora deve examinar todos os documentos emitidos pela equipa de revisão e
em caso de necessidade, reforçar ou emendar as recomendações e ações resultantes da
revisão.
16
16
É também a equipa da autoridade revisora quem decide se os objetivos da revisão foram
ou não atingidos e assim, caso seja necessário, aconselhar o cliente.
Todas as recomendações e conclusões finais são emitidas pela equipa da autoridade
revisora e colocadas no documento Review Authority Report (RAR) disponibilizado pelo ECSS.
v. Cliente
O cliente deverá propor o procedimento para a realização da revisão de acordo com
documento Review Procedure disponibilizado pelo ECSS. O cliente deverá assegurar reuniões
de início de projeto, intermédias, reuniões entre a equipa de revisão e o fornecedor e uma
reunião final com a equipa da autoridade revisora.
É importante que o cliente disponibilize à equipa de revisão um sistema de gestão de
informação para distribuição e armazenamento dos pacotes de dados de revisões e
informação adicional necessária.
vi. Fornecedor
O fornecedor deverá disponibilizar todas as instalações e logística ao cliente para
reuniões de revisão e sessões requisitadas pelo mesmo. Deverá ainda assegurar que todos os
meios necessários, informação e documentação especificados para o procedimento da revisão,
estão disponíveis para a realização da mesma.
O fornecedor deverá apoiar o cliente propondo um planeamento adequado das ações
propostas pela revisão de discrepância de itens (RID’s).
vii. Líder da equipa de revisão
O líder da equipa de revisão deverá gerir todas as atividade da equipa de revisão e, após
a consulta com o cliente, deverá também confirmar se as condições pré-requisitadas
definidas no procedimento da revisão estão em conformidade.
O líder deverá aprovar os conteúdos dos RIDs emitidos pela equipa e efetuar o relatório
final da equipa de acordo com o documento Review Team Report disponibilizado pelo ECSS.
viii. Equipa de revisão
A equipa de revisão deverá realizar a análise documental, identificar problemas, emitir
recomendações ou explicações requisitadas de acordo com o RID, verificar a conformidade
das ações corretivas aos RIDs e por fim apoiar o líder da equipa na preparação do relatório
final.
Especificação das normas ECSS relativas à gestão de projetos espaciais
17
17
ix. Reuniões de revisão
As reuniões de revisão estão divididas em diferentes tipos de reunião, numa primeira fase
é feita a reunião de início onde é necessário verificar que as condições estipuladas para a
realização da revisão estão asseguradas, e onde é apresentado o procedimento da revisão e
sua organização assim como todos os documentos sujeitos a análise.
A reunião de coordenação deverá rever todas as entradas da equipa, acordar com o
cliente nos problemas a serem resolvidos com o fornecedor e emitir todos os RIDs ao
fornecedor.
Por sua vez, a reunião de colocação tem como objetivos rever as respostas dadas pelo
fornecedor aos RIDs emitidos, acordar a disposição final dos mesmos entre o cliente e o
fornecedor, identificar as ações a tomar e as suas datas de finalização e finalmente
identificar eventuais desacordos a serem reportados à equipa da autoridade revisora.
Numa fase final é realizada a reunião de encerramento da equipa de revisão onde são
sintetizados todos os resultados obtidos na reunião de colocação e são providenciadas todas
as entradas para o relatório de revisão e acordadas todas as questões classificadas como de
maior importância a serem reportadas à equipa da autoridade revisora.
Finalmente a reunião da equipa da autoridade revisora deverá confirmar que a revisão foi
realizada de acordo com o procedimento aprovado, examinar todas as conclusões finais da
equipa de revisão, confirmar o alcance dos objetivos da revisão e efetuar decisões se estas
forem emitidas pelo consumidor. A equipa da autoridade revisora deve efetuar o documento
Review Authority Report em conformidade com o standard disponibilizado pelo ECSS.
Todos os documentos emitidos ao longo do processo de uma revisão são de carácter
normativo, em qualquer projeto espacial e devem ser preenchidos de acordo com os
standards disponibilizados pelo ECSS.
x. Processamento do RID e acompanhamento de ações
O relatório RID deverá ser o principal mecanismo para registar questões e identificar
problemas e soluções resultantes da análise da documentação da revisão. A categorização das
RIDs é feita de duas maneiras possíveis, como principal, se o problema em questão afetar um
objetivo da revisão, e como menor, se for considerado parte do trabalho normal. O conteúdo
de um RID terá que ser preenchido conforme o formulário disponibilizado pelo ECSS. Por sua
vez, o cliente terá que supervisionar todas as ações resultantes da revisão e assim que estas
terminem, e todas as partes estejam de acordo, a ação é considerada como fechada.
Na figura 2.3 é apresentado um diagrama lógico do processamento de uma RID.
18
18
Figura 2.3 – Diagrama de processamento de uma RID (fonte: ECSS-M-ST-10-01C Annex E)
Especificação das normas ECSS relativas à gestão de projetos espaciais
19
19
ECSS-M-ST-40C_Rev.1 Configuration and information 2.4.3.management
Este documento define a configuração da gestão de informação/documental para os
projetos espaciais, estruturado em duas partes, a primeira apresenta os processos e a
segunda os requisitos mais detalhados. O principal objetivo desta norma está em
disponibilizar os requisitos para a gestão de informação/documental e a configuração de
produtos dentro de um projeto espacial.
i. Princípios da configuração da gestão
As principais atividades da gestão de configuração e de informação/documental são a
gestão e o planeamento, a implementação de atividades como a identificação, controlo,
relatório de estado, verificação e auditoria. Também são necessárias as atividades
relacionadas com a gestão da informação/documental como a criação, recolha, revisão,
entrega, armazenamento e recuperação e finalmente o arquivo. Estas são atividades que são
apresentadas com mais detalhe nos pontos seguintes.
O processo da gestão de configuração tem como objetivo estipular um processo que
estabeleça e mantenha um registo das características funcionais e físicas de todos os
produtos comparando-as com os requisitos de design e operacionais estipulados. Permite
assim, o acesso a toda a descrição técnica, através de documentos atualizados e aprovados, e
à evolução do produto durante todo o ciclo de vida do projeto.
Por sua vez, a gestão de informação/documental é um processo que assegura a criação,
recolha, revisão, armazenamento e arquivação de toda a informação durante um projeto. É
necessário que toda a informação seja gerida eletronicamente. O acesso facilitado de toda a
informação aos atores intervenientes no projeto é assegurado de acordo com os seus níveis
de autorização e informação restrita. É importante a existência de uma gestão documental
eficiente que permita facilitar a consulta de dados relevantes durante o desenvolvimento do
projeto, assim como a criação de documentos normativos exigidos pelo ECSS.
ii. Gestão e planeamento
O plano da gestão de configuração é definido pelo fornecedor com base nos requisitos
estipulados pelo cliente para o projeto, estes requisitos são aplicáveis a todos os atores
envolvidos incluindo todos os níveis dos seus fornecedores. Cada um destes irá criar e
desenvolver o seu CM plan.
O objetivo deste plano é definir os processos e recursos necessários à gestão de
configuração de produtos de uma forma controlada ao longo do ciclo de vida do projeto.
Também permite um acompanhamento da evolução do produto, sendo assim mais eficiente a
comparação entre o estado previsto, isto é as-designed, com o estado real, as-built.
20
20
A gestão de configuração possui interfaces com o sistema de engenharia, garantia de
produto, fabrico e produção, contribuindo de forma transversal para a organização do projeto
e do seu calendário de execução, através da identificação de todas as restrições que surgem
relacionadas com as previsões acordadas no negócio. Esta relação entre interfaces é
apresentada em forma de diagrama na figura 2.4 na qual são apresentados todos os inputs
envolvidos na gestão de configuração e de informação/documental.
Figura 2.4 – Inputs da interface da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1)
Os outputs resultantes permitem uma organização mais eficiente de todas as interfaces
envolvidas no que diz respeito à documentação necessária durante todo o projeto espacial
como mostra a figura 2.5 .
Especificação das normas ECSS relativas à gestão de projetos espaciais
21
21
Figura 2.5 – Ouputs da interface da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1)
iii. Implementação da gestão de configuração
A implementação da gestão de configuração implica uma definição, organização,
execução e supervisão das seguintes atividades:
• Configuração de identificação
É necessário estabelecer regras para a identificação de produtos e definir as suas
arquiteturas de modo a permitir selecionar itens e os seus respectivos documentos para
configuração.
• Configuração de controlo
A implementação de um processo de controlo de produtos/sistemas e suas interfaces
internas/externas através do registo atualizado das suas configurações em livrarias ou
repositórios, em ambiente controlado com back-up copies.
• Configuração de relatórios de estado
A aprovação do estado dos produtos deve ser feita através de relatórios aos quais o
acesso é permitido em repositórios digitais.
22
22
• Configuração de verificações e auditorias
Para verificar e demonstrar que o produto vai de encontro às características funcionais,
físicas e de performance documentadas assim como verificar também que o sistema da
gestão de configuração é eficaz e vai de encontro ao requisitos estabelecidos para a
configuração do projeto.
A implementação da gestão de configuração é apresentada em forma de esquema na
figura 2.6 .
Figura 2.6 – Implementação da gestão de configuração (fonte: ECSS-M-ST-40C Rev.1)
iv. Configuração de identificação
A configuração de identificação estabelece e disponibiliza documentação controlada com
o objetivo de identificar características de identificação de um produto até que este esteja
totalmente definido no que diz respeito a funcionalidades, performance e características
físicas, assegurando assim a integridade da configuração de um produto.
O Configuration Item, CI, atribuído a cada produto, pode ser de duas categorias,
Developed Configuration Item ou Non-Developed Configuration Item. A diferença entre as
duas categorias está no facto do Non-Developed Configuration Item se tratar de um produto
que não foi desenvolvido para o projeto mas de um off-the-shelf, isto é, um
Especificação das normas ECSS relativas à gestão de projetos espaciais
23
23
produto standard. No entanto também se pode referir a qualquer produto desenvolvido
noutro projeto espacial e que possua todos os requisitos necessários à sua aplicação no
projeto em desenvolvimento.
A configuração de identificação é apresentada em forma de esquema na figura 2.7 .
Figura 2.7 – Esquema da configuração de identificação (fonte: ECSS-M-ST-40C Rev.1)
A seleção de itens para identificação é feita seguindo o guião para seleção de itens
disponibilizado pelo ECSS.
Os documentos digitais devem também ser sujeitos às mesmas regras de classificação que
os itens de um produto.
v. Configuração de controlo
Trata-se do processo de controlo da evolução ou desvio em relação às linhas base
acordadas. Este processo inclui diferentes fases, a preparação, justificação, avaliação,
disposição e implementação de alterações contratuais ou de engenharia, desvios e renúncias.
De facto este processo assegura que qualquer alteração, desvio e renúncia das linhas base
acordadas é tratada de forma controlada até à a sua aprovação. As alterações podem ser
iniciadas pelo cliente, devido à evolução de requisitos, seguidas de uma resposta por parte do
fornecedor definindo um prazo limite, ou propostas pelo fornecedor, devido a um
melhoramento do design, seguidas de uma resposta do cliente.
24
24
As alterações são avaliadas e aprovadas pelo Configuration Control Board (CCB) que é
estabelecido em todos os níveis do projeto e representa a autoridade responsável pelas
mesmas. Cada alteração pode ser classificada sendo de classe 1 ou 2, e o seu desvio como
major ou minor.
vi. Configuração de relatórios de estado
Este processo tem como objetivo manter uma gestão documental eficiente e
disponibilizar todas as propostas de alterações durante o projeto. É feita também a
comparação entre o estado real do produto e o idealizado, isto é as-built vs as-design.
vii. Implementação da gestão de informação/documental
Todas as atividades do processo de implementação da gestão de informação/documental
são apresentadas no diagrama da figura 2.8 .
Figura 2.8 – Diagrama representativo das fases constituintes da implementação da gestão de
informação/documental (fonte: ECSS-M-ST-40C Rev.1)
Especificação das normas ECSS relativas à gestão de projetos espaciais
25
25
A norma para gestão de configuração e informação/documental apresenta uma complexa
e extensa lista de documentos normativos para as diferentes áreas de
informação/documentação, assim como, documentos auxiliares para a classificação de itens
que são disponibilizados pelo ECSS.
ECSS-M-ST-60C Cost and schedule management 2.4.4.
A gestão de custos e de horários é definida através de um sistema de organização de
processos e ações que apoiam e suportam a gestão do projeto. Este sistema permite uma
utilização optimizada dos recursos humanos, instalações, materiais e fundos, que por sua vez
leva ao sucesso no que diz respeito a metas financeiras, conclusões de tempo e performance
técnica.
A identificação de situações críticas que podem resultar em impactos significativos no
projeto, é feita de forma mais eficaz quando as atividades e custos associados são planeados
de forma controlada, permitindo realizar as ações de recuperação mais apropriadas.
i. Princípios comuns à gestão de custos e de horários
Os principais objetivos desta gestão são o planeamento de todas as fases, das despesas e
dos recursos do projeto e identificar os desvios e a criação de propostas de ações corretivas
para que o projeto seja realizado dentro do tempo disponibilizado e das limitações
financeiras estipuladas. A gestão de horários inclui como atividades principais a definição dos
horários, da duração das atividades, do controlo do trabalho em desenvolvimento em relação
ao planeado e a emissão de relatórios de estado. No que diz respeito à gestão de custos, as
principais atividades são o planeamento e estimativa de custos, controlo de custos e a
emissão de relatórios de estado.
As estruturas utilizadas nestas atividades são o WBS, CBS, o BAS e o CCS. A figura 2.9
mostra a análise funcional da gestão de horários e de custos, assim como, a relação entre as
duas.
26
26
Figura 2.9 – Vista geral da análise funcional da gestão de custos e de horários (fonte: ECSS-M-ST-60C)
O WBS permite conduzir uma optimização da distribuição do trabalho entre fornecedores
e ainda gerir e supervisionar o planeamento do projeto, isto é, a rede de eventos e de
atividades. A relação lógica que existe entre atividades, permite produzir e completar os
deliverables do WBS. Os recursos e os responsáveis dentro da organização podem ser
identificados para cada atividade existente.
De facto, a identificação dos elementos do WBS serve de base ao planeamento do
trabalho a desenvolver e permite assim uma estimativa dos recursos necessários.
O CBS define uma série de categorias usadas para “quebrar” todos os custos do projeto. O
custo total planeado para cada work package é “quebrado” por categoria, onde a distinção
entre custos diretos e indiretos é feita por cada fornecedor ao seu cliente.
O BAS é um gráfico cujo objetivo é identificar os relatórios entre os fornecedores e os
respetivos clientes demonstrando qual o fornecedor responsável por cada work package. Ao
relacionar os work packages do WBS com o BAS é possível traçar as responsabilidades
contratuais o que facilita o processo da gestão de custos.
Por fim o CCS demonstra as relações entre as organizações presentes no BAS cujo
trabalho é desenvolvido em diferentes países. Ao identificar as relações entre os work
packages do WBS e os acordos de negocio do BAS, podem ser gerados relatórios, de forma a
ilustrar como cada trabalho de cada fornecedor está distribuído por país.
Especificação das normas ECSS relativas à gestão de projetos espaciais
27
27
ii. Tipos de Business Agreements
O modo de gerir os custos e horários de um projeto depende do tipo de acordo de negócio
realizado. Existem dois tipos base de contratos, o de acordo de preço fixo e o de reembolso
de despesas.
O contrato de preço fixo existe quando o preço do acordo de negócio não é sujeito a
alterações ou revisões por causa das despesas que ocorrem durante a realização das
obrigações do fornecedor com a exceção de alterações que possam ocorrer nas condições
económicas atuais.
O contrato do tipo de reembolso de despesas com taxa fixa permite o pagamento de uma
taxa fixa ao fornecedor. O contrato com taxa de incentivo permite o pagamento de uma taxa
ao fornecedor se este desenvolver o trabalho como especificado no acordo de negócio. Por
fim existe o contrato com a taxa de tempo e de material cujo o valor a pagar é determinado
com base nas taxas por hora quer de pessoal quer de instalações, assim como, pelos custos de
materiais utilizados.
iii. Gestão de risco
A gestão de risco é um processo sistemático de identificação, análise e de resposta ao
risco de um projeto durante o seu ciclo de vida. Permite maximizar a probabilidade e
consequências de eventos positivos e minimizar a probabilidade e as consequências dos
eventos adversos para os objetivos do projeto. A gestão de custos e de horários é suportada
por uma avaliação de risco apropriada, de modo a permitir a tomada de decisões relevantes
durante o desenvolvimento do projeto.
Os elementos de risco com relevância explicita para a gestão de custos e de horários são
listados no registo de riscos que inclui restrições programáticas, desafios tecnológicos,
elementos de condução de custos e restrições financeiras e geográficas.
iv. Princípios da gestão de horários
O desenvolvimento de uma rede de atividades, marcos e relações entre estes permite
uma análise do planeamento temporal eficaz e da avaliação de riscos. A identificação do
caminho crítico ajuda a antecipar ações corretivas nas atividades criticas, de forma a evitar
um deslizamento nos horários. A rede de atividades é derivada do WBS onde estas são
colocadas em sequência e identificando as dependências entre cada uma. Uma vez
identificadas as atividades e respetivas durações, o resultado obtido é colocado em
calendário, tendo em conta as horas de trabalho, dias de trabalho e feriados, assim como, a
disponibilidade de recursos humanos, mecânicos, ferramentas e instalações.
28
28
As key milestones são estabelecidas durante o acordo feito entre o cliente e o fornecedor
e são utilizadas no horário base, assim como, a descrição de atividades, datas de início e fim
das mesmas, duração de cada uma e a identificação dos caminhos críticos.
O calendário de trabalho decorrente é o que permite a vista mais realística do estado do
projeto, dado pelo fornecedor ao cliente. Este horário reflete toda a informação atualizada
do estado das atividades e do estado das key milestones.
O progresso do projeto é controlado através da comparação do calendário de trabalho
decorrente e do calendário base estabelecido.
Os elementos da avaliação da performance do projeto são feitos através da análise da
obtenção das datas dos marcos a atingir, do progresso do trabalho, das durações das
atividades e das mudanças dos caminhos críticos.
A avaliação da performance é feita através da avaliação da obtenção dos marcos
estipulados durante o projeto, do verdadeiro progresso do trabalho, duração das atividades,
contingências e alterações em caminhos críticos. A forma mais comum da apresentação da
calendarização e horários do projeto é feita através do diagrama de Gantt. Este diagrama
representa cada atividade e a sua respetiva duração através de um sistema de barras
horizontais. As atividades podem ser agrupadas em conformidade com o WBS permitindo uma
visão geral sobre o projeto em desenvolvimento. Na tabela 2.1 é ilustrado um exemplo de um
diagrama de Gantt.
Tabela 2.1 – Exemplo de um diagrama de Gantt: atividades e durações (fonte: ECSS-M-ST-60C)
Outra ferramenta igualmente utilizada na monitorização de projetos é a representação
“traffic light” onde as cores atribuídas são o verde para as atividades dentro do horário
previsto com mais de 10 dias de margem, o amarelo para atividades que se encontram dentro
+/- 10 dias da data prevista e vermelho para as atividades com mais de 10 dias após a data
prevista. A tabela 2.2 ilustra um exemplo desta ferramenta.
Especificação das normas ECSS relativas à gestão de projetos espaciais
29
29
Tabela 2.2 – Exemplo da ferramenta “traffic light” (fonte: ECSS-M-ST-60C)
v. Relatório de planeamento
Reportar o estado atual do projeto, no que diz respeito aos custos associados às
atividades em desenvolvimento, permite avaliar o desempenho e progresso obtido ao longo
do seu ciclo de vida. No que diz respeito ao estado do progresso de um projeto é necessário
reportar no mínimo as atividades que tiveram início, assim como, a sua data de iniciação, as
atividades completas e datas de conclusão, previsão de datas de conclusão das atividades em
progresso e a validação das sequências, relações e restrições das atividades planeadas. Cada
relatório de informação de progresso é acompanhado de uma descrição de suposições e
efeitos resultantes, bem como as causas de desvios e ações corretivas propostas.
O sistema utilizado para reportar o estado do projeto assegura uma boa comunicação
entre o cliente e o fornecedor, este sistema deve incluir reuniões de progresso e listas de
itens de ações, relatórios de progresso, revisões, relatórios de notificação de problemas,
comparação entre o estado atual com o previsto, diagramas de Gantt e representação
“traffic light” para definição do estado dos marcos planeados.
vi. Gestão de custos
Na gestão de custos existem diferentes elementos que asseguram uma boa comunicação e
por consequência uma análise mais eficaz do projeto, permitindo a tomada de decisões de
forma controlada. Um destes elementos diz respeito às alterações dos contratos, o CCN, que
tem como função reportar qualquer alteração com impacto financeiro ou de planeamento no
projeto submetido pelo fornecedor ao cliente, que deverá ser acompanhado com a
documentação necessária à classificação da alteração.
Outro elemento importante na gestão de custos é o processo do cálculo da estimativa de
custos, pois uma estimativa correta e de confiança possui um impacto positivo no custo total
de um projeto. As atividades de preparação para o cálculo da estimativa de custos
necessitam do WBS para a análise de atividades de trabalho e identificação de tarefas para a
definição dos parâmetros de custos a usar no modelo de custo utilizado no plano de
estimação de custos.
30
30
O relatório de estimação de custos consiste na captação dos resultados obtidos, desde o
início até à conclusão do projeto, é portanto necessário manter este relatório sempre
atualizado.
O plano de desenvolvimento de custos, DCP, demonstra todas as despesas do projeto em
desenvolvimento ao longo do tempo. Este plano é baseado no WBS e no CBS. Os planos de
pagamentos estão incluídos no DCP e são geralmente derivados dos marcos definidos aos
longo do projeto ou do planeamento das despesas, no caso dos contratos com reembolso de
despesas.
O controlo de custos é feito através da comparação entre o plano original da base de
custos, OBCP, e o plano atual da base de custos, CBCP. De facto, o OBCP juntamente com as
alterações aprovadas resulta no CBCP. O controlo de custos também utiliza duas estimativas
na análise do estado atual de custos do projeto, a estimativa no término, EAC, e a estimativa
para conclusão, ETC. A EAC oferece uma estimativa total das despesas do projeto no seu
término e a ETC faz parte da EAC, pois oferece a estimativa total das despesas do trabalho a
ser realizado, desde a sua definição até à sua conclusão.
Existem vários elementos sujeitos a controlo como por exemplo os tipos de contratos
envolvidos no projeto, a distribuição geográfica do trabalho, o controlo do inventário, a
realização de auditorias financeiras e o alcance dos marcos de pagamentos.
Por fim, o reportar dos custos possui elementos comuns a todos os tipos de contratos, tais
como o OBCP, CBCP, EAC, elementos financeiros da distribuição geográfica e os registos de
inventário. No que diz respeito aos contratos do tipo reembolso de despesas, os elementos
adicionais são a análise de desvios no CBCP e o ETC.
Todos os documentos normativos referidos estão disponibilizados pelo ECSS.
ECSS-M-70A Integrated Logistic Support 2.4.5.
No contexto dos projetos espaciais, a necessidade do ILS diz respeito ao desenvolvimento
dos recursos materiais e serviços essenciais nas operações de suporte, manutenção e controlo,
particularmente na geração de custos e disponibilidade. O ILS não é uma nova atividade mas
sim uma integração nos objetivos do projeto, de forma a coordenar as atividades e recursos
envolvidos na preparação do sistema de suporte, com vista a minimizar o custo do ciclo de
vida do projeto, de acordo com os requisitos e riscos de operação.
A capacidade do sistema de suporte de entregar em tempo e na quantidade apropriada os
recursos materiais e serviços que mantêm o sistema suportado durante a fase de utilização,
dentro das restrições de custos definidas, no seu ambiente operacional, deve ser estabelecida
com sucesso.
Dentro do contexto de um projeto, o suporte logístico deve ser oferecido
Especificação das normas ECSS relativas à gestão de projetos espaciais
31
31
durante a fase de utilização e requer uma preparação inicial, no que diz respeito à gestão de
atividades especificas, chamadas de atividades logísticas, que estão envolvidas com outro
tipo de atividades, no que diz respeito a dependência e segurança.
A gestão destas atividades logísticas está integrada nos requisitos de gestão do projeto e
demonstra que a dependência e critérios de segurança são tomados em consideração dentro
do ambiente operacional que o produto utiliza, a conformidade, coerência e continuidade do
sistema de suporte e a habilidade de controlo de riscos específicos à performance das tarefas
associadas à operação e manutenção. O objetivo do sistema de suporte é manter os níveis
técnicos de performance respeitando todas as restrições de segurança, optimizando assim o
custo associado ao ciclo de vida do projeto.
i. Principais conceitos do ILS
A implementação do sistema de suporte integrado, ILS, é atingida através da
consideração de quatro aspectos: a integração do sistema de suporte no ambiente do cliente
e dentro das suas necessidades, a integração das atividades logísticas na gestão do projeto, a
integração do sistema de suporte desenhado no sistema suportado que tem como objetivo
principal atingir a performance funcional esperada pelo cliente e por fim, a integração dos
elementos de suporte.
O conceito de disponibilidade operacional refere-se ao facto dos recursos externos
requisitados, incluindo recursos de manutenção a serem fornecidos para a performance das
atividades, serem fornecidos dentro das condições operacionais de utilização. Os recursos
externos são providenciados pelo sistema de suporte, de forma a manter o sistema suportado
num estado operacional dentro das condições atuais de utilização e restrições económicas
previstas. Esta capacidade de disponibilização dos recursos chama-se capacidade de suporte.
Os factores humanos influenciam diretamente as características quer da capacidade de
suporte quer do sistema suportado.
Outro aspecto importante é o custo associado ao ciclo de vida do projeto e os riscos
operacionais do mesmo. O conceito de custo do ciclo de vida refere-se quer aos custos de
aquisição do sistema suportado e do sistema de suporte quer aos custos de operação,
manutenção e libertação. Da análise do custo do ciclo de vida do projeto, o ILS define a
relação entre a dependência e análise de segurança e a seleção de uma solução optimizada
para o sistema de suporte.
32
32
ECSS-M-ST-80C Risk management 2.4.6.
O objetivo da norma para a gestão de risco é identificar, avaliar, reduzir, aceitar e
controlar os riscos em projetos espaciais de forma sistemática e proactiva, compreendendo
todos os efeitos em termos de custos e tendo em conta as restrições técnicas e programáticas
dos projetos. De facto, os riscos representam ameaças ao sucesso de um projeto pois
introduzem efeitos negativos no que diz respeito ao custo, planeamento e performance
técnica, no entanto, a aplicação de práticas apropriadas para o controlo de riscos, podem
representar novas oportunidades com impactos positivos.
A gestão de risco é implementada em todos os níveis da cadeia cliente-fornecedor e exige
um conhecimento das práticas do projeto em termos de sistema e análise de engenharia,
segurança, de itens críticos, dependabilidade, caminhos críticos e de custos.
i. Princípios da gestão de risco
A gestão de risco é um processo iterativo e sistemático que otimiza os recursos
disponíveis de acordo com a política de gestão de risco. A integração da gestão de risco é
feita através da definição de papéis e responsabilidades nas atividades do dia-a-dia em todos
os domínios e níveis do projeto. A gestão de risco apoia os gestores e engenheiros incluindo
os aspetos de risco durante o ciclo de vida do projeto.
O processo da gestão e risco é caracterizado pela detecção de eventos indesejados e
avaliação destes de acordo com a severidade e probabilidade de ocorrência. A avaliação de
alternativas para atenuação de riscos e as medidas resultantes de performance assim como a
tendência do risco ao longo do projeto, são utilizadas para otimizar os recursos.
Dentro do processo da gestão de risco é produzida a informação de riscos existentes que é
estruturada, facilitando a comunicação de risco e a gestão de tomadas de decisões. Os
resultados da avaliação dos riscos, e da redução dos mesmos, são comunicados à equipa de
projeto.
A implementação da gestão de risco deve assegurar uma aproximação integrada e
coerente em todos os domínios do projeto pois deve integrar dentro dos processos de gestão
existentes no projeto.
A gestão de risco é documentada de modo a assegurar que as políticas de gestão de risco
se encontram bem estabelecidas, compreendidas, implementadas e mantidas, e que estas são
mapeadas até à origem. A documentação da gestão de risco inclui a política de gestão de
risco que define a atitude da organização face à gestão de riscos e oferece um contorno em
alto nível do processo de implementação da mesma. Além deste documento, ainda são
estabelecidos, o plano de gestão de risco que descreve a implementação do processo de
gestão, e o relatório da avaliação de risco. Este relatório é usado para comunicar o
Especificação das normas ECSS relativas à gestão de projetos espaciais
33
33
risco identificado, a sua avaliação, assim como para descrever as ações de seguimento e seus
resultados. Todos estes documentos são de carácter normativo e encontram-se
disponibilizados pelo ECSS.
ii. Processo da gestão de risco
O processo da gestão de risco trata-se de um processo iterativo de quatro passos que é
ilustrado na figura 2.10. As tarefas a serem realizadas em cada passo são demonstradas na
figura 2.11.
Figura 2.10 – Processo iterativo da gestão de risco (fonte: ECSS-M-ST-80C)
34
34
Figura 2.11 – Tarefas associadas a cada passo do processo iterativo da gestão de risco (fonte: ECSS-M-ST-
80C)
Passo 1: Definir os requisitos de implementação da gestão de risco
O propósito deste passo será iniciar o processo da gestão de risco definindo a política de
gestão de risco e preparar o plano da gestão de risco para o projeto. As diferentes tarefas
que constituem as atividades a desempenhar no passo 1 são apresentadas de seguida:
Tarefa 1 – Definir a política da gestão de risco
As atividades constituintes desta tarefa são a identificação do conjunto de recursos com
impacto nos riscos, os objetivos e restrições do projeto. A definição de sistema de
classificação da severidade das consequências e probabilidades de ocorrência de riscos. Dois
exemplos de tipos de sistemas de classificação são apresentados nas tabelas 2.3 e 2.4. O
índex de risco, isto é, a combinação entre a severidade e a probabilidade do mesmo, também
deverá possuir um sistema de classificação que é apresentado na tabela 2.5 e respetivas
ações corretivas na tabela 2.6.
Especificação das normas ECSS relativas à gestão de projetos espaciais
35
35
Tabela 2.3 – Sistema de classificação da severidade das consequências (fonte: ECSS-M-ST-80C)
Tabela 2.4 – Sistema de classificação da probabilidade de ocorrência do risco (fonte: ECSS-M-
ST-80C)
Tabela 2.5 – Sistema de classificação do índex de risco e esquema de magnitude (fonte:
ECSS-M-ST-80C)
36
36
Tabela 2.6 – Exemplo das designações das magnitudes de risco e ações propostas (fonte: ECSS-M-ST-80C)
Tarefa 2 – Preparar o plano de gestão de risco
O plano de gestão de risco possui tipicamente os seguintes dados:
→ Descrição da organização do projeto de gestão de risco incluindo papéis e
responsabilidades.
→ Sumário da política de gestão de risco.
→ Conceito de seguimento de risco e documentação relacionada com a gestão de risco.
Passo 2: Identificar e avaliar os riscos
O propósito deste segundo passo é identificar cada cenário de risco para determinar,
baseado nas saídas do passo 1, a magnitude de cada risco e finalmente classificá-los segundo
o tipo de risco. Os possíveis itens de risco são os técnicos, de custo, de calendário e de
aspetos organizacionais internos.
Tarefa 3 – Identificar cenários de risco
As seguintes atividades estão incluídas nesta tarefa:
→ Identificação dos cenários de risco, incluindo causas e consequências, de acordo com
a política de gestão de risco.
→ Identificação dos meios de detecção e aviso de ocorrência de um evento indesejado,
de forma a evitar a propagação das consequências.
→ Identificação dos objetivos do projeto em risco.
Especificação das normas ECSS relativas à gestão de projetos espaciais
37
37
Tarefa 4 – Avaliar os riscos
Esta tarefa é constituída pelas seguintes atividades:
→ Determinação da severidade das consequências de cada cenário de risco.
→ Determinação da probabilidade, índex de risco e magnitude em cada cenário.
→ Utilização das fontes de informação disponíveis e aplicação de métodos de suporte
para o processo de avaliação.
→ Determinação do risco geral de projeto, através da avaliação dos riscos individuais
identificados, suas magnitudes e iterações, e os resultados com impacto significativo no
projeto.
Passo 3: Decidir e agir
Esta passo tem como objetivo analisar a aceitação de risco e as opções para redução do
mesmo de acordo com a política de gestão e risco implementada, e determinar as estratégias
apropriadas.
Tarefa 5 – Decidir se os riscos poderão ser aceites
Esta tarefa é constituída pelas seguintes atividades:
→ Aplicação do critério de aceitação de risco.
→ Identificação dos riscos aceites, dos riscos sujeitos a redução, e determinação do
nível da gestão de decisão.
→ Para riscos aceites deve proceder-se diretamente para o passo 4, e para os riscos
inaceitáveis proceder para a tarefa 6.
Tarefa 6 – Reduzir os riscos
Esta tarefa é constituída pelas seguintes atividades:
→ Determinação de medidas/opções preventivas para cada risco inaceitável, do sucesso
da redução de risco, e da falha e critério de verificação.
→ Determinação do potencial da redução de risco para cada medida executada.
→ Seleção da melhor medida de redução de risco e decisão nas prioridades para
implementação.
→ Verificação da redução de risco.
38
38
→ Identificação dos riscos que não possam ser reduzidos a um nível aceitável e
apresentação do nível de gestão apropriado.
→ Documentação dos riscos reduzidos com sucesso numa lista, e dos riscos não
resolvidos noutra lista.
Tarefa 7 – Aceitação recomendada
As opções de decisões para a aceitação de riscos são apresentadas nesta tarefa, assim
como, a aprovação dos riscos aceites e resolvidos. Os riscos não aceites são apresentados
para tomada de decisões.
Passo 4: Supervisionar, comunicar, e aceitar riscos
O objetivo principal deste passo é seguir, supervisionar, atualizar, comunicar e
finalmente aceitar os riscos detectados.
Tarefa 8 – Supervisionar e comunicar riscos
Esta tarefa é constituída pelas seguintes atividades:
→ Avaliação periódica e revisão de todos os riscos identificados e atualização de
resultados após a interação do processo de gestão de risco.
→ Identificação de mudanças e alterações nos riscos existentes e iniciação na nova
análise de risco necessária para o esclarecimento de incertezas.
→ Verificação da performance e efeitos correspondentes à redução de risco.
→ Ilustração da tendência de risco ao longo da evolução do projeto através da
identificação de como as magnitudes dos riscos alteraram-se ao longo do tempo.
→ Implementação de um sistema de alerta para novos riscos.
Tabela 2.7 – Exemplo de uma análise de tendência de risco (fonte: ECSS-M-ST-80C)
Especificação das normas ECSS relativas à gestão de projetos espaciais
39
39
Tarefa 9 – Submissão de riscos para aceitação
A submissão dos riscos para uma aceitação formal do nível apropriado de gestão é
realizada nesta tarefa, no caso de riscos não aceites é necessário regressar à tarefa 6.
iii. Implementação da gestão de risco
A gestão de risco é aplicada dentro da estrutura da gestão normal do projeto, garantindo
uma identificação de riscos sistemática, avaliação e seguimento dos mesmos de forma eficaz.
A gestão de risco é implementada através de um esforço coletivo com tarefas e
responsabilidades atribuídas a funções e indivíduos dentro da organização com as habilitações
mais relevantes dentro das áreas associadas a determinado risco. Os resultados da gestão de
risco são considerados dentro da rotina da gestão do projeto e nas decisões relativas à
evolução das linhas base do projeto.
As responsabilidades associadas à gestão de risco são descritas no plano de gestão de
risco de acordo com a política de gestão de risco implementada. O gestor de projeto possui a
responsabilidade geral na integração da gestão de risco dentro do projeto e reporta os
resultados das tarefas ao responsável superior na cadeia cliente/fornecedor. O gestor de
projeto define quem, dentro do projeto, é responsável pelo controlo de riscos na sua área
respetiva e quais são as guias de comunicação, informação e de relatórios a respeitar.
As atividades associadas à gestão de risco estão presentes ao longo de todas as fases do
projeto definidas anteriormente. Os processos de gestão e de fluxo de informação dentro da
organização, asseguram uma visibilidade capaz de prevenir a ocorrência de riscos. Os planos
de ação são preparados de acordo com o tipo de risco detetado e a sua magnitude e
garantem que o estado de cada risco é atualizado de forma regular, especificando todas as
consequências detetadas e atores afetados pelas mesmas. A informação relativa a todos os
riscos identificados é mantida em registo.
A documentação relativa à gestão de risco é mantida de forma a que cada passo do
processo apresentado e resultados obtidos sejam rastreáveis. Os dados a emitir no processo
da gestão de risco são a política da gestão de risco, os objetivos principais, o plano da gestão
de risco, a identificação dos cenários, a probabilidade de eventos, os resultados do risco, as
decisões perante o risco, registo da redução de riscos e ações de verificação, a tendência de
risco e a aceitação de riscos. Todos estes documentos são considerados “vivos” pois devem
estar sempre em atualização constante para, se necessário, serem usados em reuniões de
projeto, revisões e milestones como é requisitado no plano de gestão de risco.
40
40
PROPOSTA DE UM SPACE Capítulo 3PROJECT MANAGEMENT
HANDBOOK : FERRAMENTAS E
PLATAFORMAS, OBJETIVOS E
FUNCIONALIDADES
De facto não existe nenhuma aplicação semelhante à proposta para a gestão de projetos
espaciais, tornando o SPMH uma ferramenta de extremo interesse para a equipa de projeto
que se vê obrigada a utilizar diferentes programas para realizar a gestão das atividades
estipuladas pelo gestor de projeto. O SPMH tem como objetivo juntar numa só plataforma
todas as funcionalidades que satisfazem as necessidades da equipa e do gestor de projetos.
3.1 Plataformas em utilização pela equipa de projeto
A equipa da Divisão de Produção Electrónica e Aeroespacial recorre a diferentes
ferramentas para satisfazer as suas necessidades durante a gestão dos projetos em curso,
uma destas plataformas é o programa iBann, desenvolvido para a EFACEC e que controla o
estado financeiro dos projetos indicando todas as despesas, custos, e aquisições associadas.
Outra plataforma utilizada pela equipa de projeto é o programa Microsoft Project, onde
são criados os diagramas de Gantt associados a cada projeto, com a identificação de todas as
fases, atividades, tarefas, durações e responsáveis atribuídos.
Para realizar a agenda de tarefas e reuniões a equipa recorre ao Microsoft Outlook onde
são criadas check-lists de todas as atividades como reuniões, revisões, auditorias e por fim a
associação das tarefas aos respectivos responsáveis.
Integração do Space Project Management Handbook
41
41
3.2 Integração do Space Project Management Handbook
A equipa da Divisão de Produção Electrónica e Aeroespacial utiliza plataformas digitais
existentes na empresa às quais o SPMH deverá realizar uma integração para obtenção de
dados e informações relevantes aos projetos espaciais.
Assim, o SPMH irá importar todas as informações que necessita do iBann e tratá-las de
forma eficiente de acordo com as necessidades documentais, técnicas e programáticas.
Embora não exista qualquer tipo de distinção entre os códigos dos departamentos e os dos
projetos identificados no iBann, o SPMH terá como objetivo filtrar e recolher toda a
informação e dados relativos à Divisão de Produção Electrónica e Aeroespacial.
No que diz respeito aos digramas de Gantt criados na plataforma utilizada pela equipa, o
estado atual das atividades deverá ser identificado de acordo com as regras acima definidas
pelas normas apresentadas e o SPMH deverá importar todos os diagramas criados pelo gestor
de equipa.
Por fim o SPHM deverá importar e guardar na sua base de dados a check-list de tarefas
criada pelo gestor de projeto no Outlook. O gestor de projeto deverá associar cada tarefa e
atividade aos responsáveis, permitindo ao SPHM emitir alertas de acompanhamento e de
evolução das mesmas.
3.3 Principais objetivos
O Space Project Management Handbook será especificado de acordo com os requisitos e
regras definidas pelas normas acima apresentadas. A gestão de um projeto espacial, além de
possuir as regras de gestão básicas de qualquer projeto empresarial, possui por acréscimo
todas as tarefas, atividades e documentação normativa estipulada pelo ECSS, o que torna a
sua gestão difícil de manter e de controlar.
O principal objetivo do SPMH é facilitar as tarefas da gestão de qualquer projeto espacial
desenvolvido pela equipa de projeto tendo em conta todas as fases e respetivas atividades, a
desempenhar durante todo o ciclo de vida do mesmo. A grande vantagem deste handbook é o
facto de ser proactivo e não reativo, isto é, o handbook não reage a problemas mas antecipa-
os através de uma boa organização e controlo de atividades, recorrendo a um calendário
composto por uma daily to-do list e uma base de dados associada, de modo a recolher
diariamente todos os dados emitidos pela equipa de projeto e, assim, poder emitir alertas
para as tarefas com prazos de conclusão iminentes.
Também se tornará necessária a integração do SPMH com plataformas já existentes e que
são utilizadas pela equipa de projeto e pelo seu gestor no desenvolvimento das suas
42
42
atividades. De facto, estas plataformas não satisfazem todas as necessidades da equipa de
projeto, daí a importância do handbook para integrar as funcionalidades disponibilizadas por
essas plataformas e desenvolver novos métodos de gestão de informação, documentação,
controlo e alertas baseados nas normas ECSS.
3.4 Principais funcionalidades
As principais funcionalidades do SPMH estão divididas em três áreas:
i. Funcionalidades de gestão de equipa
A criação de um novo projeto na base de dados do SPMH é um objetivo essencial para que
todos os requisitos da gestão de projetos sejam capazes de serem aplicados. Seguindo uma
gestão baseada nas normas do ECSS é necessário, numa primeira fase, identificar todas as
fases e atividades associadas a cada uma dentro do projeto.
É de extrema importância que o SPMH permita ao gestor de equipa gerir um diagrama de
Gantt de forma a controlar os objetivos em termos temporais, atividades e respetivas
durações. As atividades identificadas possuirão atores responsáveis cuja atribuição é feita
pelo gestor de equipa.
O calendário das atividades do projeto é gerido pelo gestor de equipa mantendo um
controlo ativo sobre toda a equipa de desenvolvimento. A criação de uma daily to-do list que
será supervisionada pelo gestor de equipa, irá permitir à equipa uma focagem mais eficaz
sobre as atividades e tarefas diárias a serem realizadas. O SPMH também deverá emitir
alertas aos responsáveis acerca as atividades, tarefas e emissão de documentação normativa
que estejam com as datas de conclusão próximas.
O SPMH permitirá ao gestor de projeto emitir convocatórias de reuniões automaticamente
através de um sistema de avisos a todos os convocados.
A revisão do planeamento diário é conseguido através das funcionalidades que o SPMH irá
disponibilizar aos seus utilizadores.
ii. Funcionalidades de gestão documental
O SPMH deverá incluir templates de todos os documentos normativos exigidos pelo ECSS
assim como formulários, relatórios e documentos que o gestor de projeto considere
indispensáveis, que permitirão à equipa de projeto preencher e submeter de forma
automática para aprovação.
Principais funcionalidades
43
43
iii. Funcionalidades de integração com programas existentes
A Divisão de Produção Electrónica e Aeroespacial da EFACEC realiza a gestão das suas
atividades recorrendo a diferentes plataformas utilizadas na empresa cujas funcionalidades
são de interesse para a gestão dos projetos espaciais. Um dos grandes objetivos do SPMH é,
por um lado, criar funcionalidades que as plataformas existentes não possuem, e por outro
lado, conjugar a integração com estas tirando partido daquilo que possuem e que é vantajoso
para a equipa e para o seu gestor.
PLANO DE TRABALHO Capítulo 4
Neste último capítulo do presente documento é apresentado o planeamento do trabalho a
ser desenvolvido para a Dissertação em ambiente empresarial. O planeamento é estruturado
ao longo de fases e suas respectivas metodologias com recursos associados, assim como
distribuído ao longo do tempo disponibilizado para o seu desenvolvimento.
As fases do trabalho especificadas são estimadas e poderão sempre sofrer alterações ao
longo do desenvolvimento do trabalho.
4.1 Planeamento
Fases
Metodologia
Recursos (Físicos e Humanos)
Revisão da literatura (de Nov. 2011 a Jan. 2012)
• Estabelecer o primeiro contato com a empresa, nomeadamente com a Divisão de Produção Electrónica e Aeroespacial
• Estudar as normas ECSS da gestão de projetos espaciais
• Elaborar o presente relatório para ser enviado aos Professores responsáveis pela unidade curricular de PDI
• Conjunto das normas ECSS
• Norma IEEE 1220 • Reunião com o
orientador na FEUP, Professor Américo Azevedo
• Reuniões com o orientador na EFACEC, Eng. Costa Pinto
• Internet • PC Pessoal
Análise e definição de requisitos
(Fev. 2012)
• Proceder ao levantamento das necessidades do gestor de projetos
• Proceder ao levantamento das necessidades da equipa de projetos
• Definir os requisitos do sistema
• Reuniões com o gestor de projetos, Eng. Costa Pinto
• Reuniões com a equipa de projetos
• Reunião com o orientador na FEUP, Prof. Américo Azevedo
• Documentos referência adquiridos em unidades
Partes envolvidas
45
45
Tabela 4.1 – Planeamento do trabalho a ser desenvolvido durante a Dissertação
4.2 Partes envolvidas
Na seguinte tabela são definidas todas as partes envolvidas na Dissertação com o tema
Especificação de um Space Project Management Handbook.
Tabela 4.2 – Partes envolvidas na Dissertação apresentada no documento
• Realizar a especificação dos requisitos do sistema
curriculares de anos anteriores
• Internet • PC Pessoal
Definição do sistema e seus componentes (Mar. 2012)
• Identificar e definir a arquitetura do sistema
• Identificar e definir os subsistemas
• Definir e especificar os processos, suas entradas e saídas
• Caracterizar os elementos base de cada processo
• Definir a especificação técnica necessária para o sistema
• Documentos referencia adquiridos em unidades curriculares de anos anteriores
• Bibliografia especializada
• Reuniões com o gestor de projetos, Eng. Costa Pinto
• Reuniões com a equipa de projetos
• Reuniões com o orientador na FEUP, Prof. Américo Azevedo
• Internet • PC Pessoal
Design das interfaces do sistema
(de Abr. 2012 a Mai. 2012)
• Especificar os elementos necessário para as interfaces do sistema
• Idealizar e desenhar as interfaces do sistema
• Internet • PC Pessoal • Reunião com o gestor
de projetos, Eng. Costa Pinto
• Reunião com o orientador na FEUP, Prof. Américo Azevedo
Elaboração do relatório Final (Jun. 2012)
• Elaborar o relatório final
• Validar o documento para entrega
• Reunião com o gestor de projetos, Eng. Costa Pinto
• Reunião com o orientador na FEUP, Prof. Américo Azevedo
• Internet • PC Pessoal
Aluna
Orientador FEUP Empresa Divisão
Orientador Empresa
Diana Barbosa Prof. Américo Azevedo EFACEC Produção Electrónica
e Aeroespacial Eng. Costa Pinto
Referências
[1] IEEE Std 1220-2055, Standard for Application and Management of the Systems Engineering Process
[2] Published Standards On-line, Management Branch. Disponível em http://www.ecss.nl/ .
[3] Published Standards On-line, Management Branch, ECSS-M-ST-10C_Rev.1 - Project planning and implementation. Disponível em http://www.ecss.nl/ .
[4] Published Standards On-line, Management Branch, ECSS-M-ST-10-01C - Organization and conuct of reviews. Disponível em http://www.ecss.nl/ .
[5] Published Standards On-line, Management Branch, ECSS-M-ST-40C_Rev.1 - Configuration and information management. Disponível em http://www.ecss.nl/ .
[6] Published Standards On-line, Management Branch, ECSS-M-ST-60C - Cost and schedule management. Disponível em http://www.ecss.nl/ .
[7] Published Standards On-line, Management Branch, ECSS-M-ST-70-A - Integrated logistic support. Disponível em http://www.ecss.nl/ .
[8] Published Standards On-line, Management Branch, ECSS-M-ST-80C - Risk management. Disponível em http://www.ecss.nl/ .