relatório final

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

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


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.


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)


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.


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)


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 .


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


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)


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.


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.


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


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


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.


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.


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


→ 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


→ 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


→ 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)


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


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


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


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



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/ .