Download PDF
ads:
UNIVERSIDADE DE TAUBATÉ
Fernando Amâncio dos Santos
ANÁLISE DE PROCESSOS DE ENGENHARIA
DO VEÍCULO DE SONDAGEM VSB-30 USANDO
IDEF0 E CMMI
Taubaté-SP
2009
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Fernando Amâncio dos Santos
ANÁLISE DE PROCESSOS DE ENGENHARIA DO VEÍCULO
DE SONDAGEM VSB-30 USANDO IDEF0 E CMMI
Dissertação apresentada para obtenção do
Título de Mestre pelo Curso de Mestrado
Profissionalizante em Engenharia Mecânica do
Departamento de Engenharia da Universidade
de Taubaté.
Área de Concentração: Produção Mecânica.
Orientador: Prof. Dr. Jorge Muniz Junior.
Co-Orientador: Prof. Dr. Geilson Loureiro.
Taubaté-SP
2009
ads:
Santos, Fernando Amâncio dos
Análise de processos de engenharia do veículo de
sondagem VSB-30 usando IDEF0 e CMMI. / Fernando Amâncio
dos Santos.Taubaté/SP – 2009.
141f. : il.
Dissertação (mestrado) – Universidade de Taubaté,
Departamento de Engenharia Mecânica.
Orientação: Prof. Dr. Jorge Muniz Junior, Departamento de
Engenharia Mecânica.
1. Engenharia de Sistemas. 2. Veículo de Sondagem. 3.
Capabilidade. ǀ. Título.
FERNANDO AMÂNCIO DOS SANTOS
ANÁLISE DE PROCESSOS DE ENGENHARIA DO VEÍCULO DE SONDAGEM
VSB-30 USANDO IDEF0 E CMMI
Dissertação apresentada para obtenção do
Título de Mestre pelo Curso de Mestrado
Profissionalizante em Engenharia Mecânica do
Departamento de Engenharia da Universidade
de Taubaté.
Área de Concentração: Produção Mecânica.
Orientador: Prof. Dr. Jorge Muniz Junior.
Co-Orientador: Prof. Dr. Geilson Loureiro.
Data: 19 de dezembro de 2009.
Resultado: Dissertação aprovada pelos abaixo assinados.
BANCA EXAMINADORA
Prof .Dr. Antonio Faria Neto Universidade de Taubaté – UNITAU
Assinatura_______________________________
Prof. Dr. Mario Niwa Departamento de Ciência e Tecnologia Aeroespacial – DCTA
Assinatura_______________________________
Prof. Dr. Jorge Muniz Junior Universidade Estadual Paulista – UNESP
Assinatura_______________________________
Prof. Dr. Geilson Loureiro Instituto Nacional de Pesquisas Espaciais – INPE
Instituto Tecnológico de Aeronáutica – ITA
Assinatura_______________________________
Dedico este trabalho a minha amada
filha Vitória e amada esposa Patrícia.
AGRADECIMENTOS
À Agência Espacial Brasileira, pelo patrocínio do curso de mestrado.
Ao Instituto de Fomento e Coordenação Industrial, por acreditar no meu potencial e investir
tempo e recursos para minha formação.
Ao meu Orientador Jorge Muniz Junior, por transformar minhas idéias com seus
conhecimentos, pela sabedoria em me mostrar como é possível sempre melhorar as
colocações à medida que a dissertação caminhava para sua versão final e, por me incentivar a
cada fase.
Ao meu Co-Orientador Geilson Loureiro, pela objetividade em expor suas idéias facilitando o
meu entendimento, por passar o conhecimento amplo que possui em engenharia de sistemas
transformando esse entendimento em dissertação e, pela sabedoria em esclarecer as dúvidas
guiando-me para realização final do trabalho.
Ao Engenheiro Mario Niwa, pelas importantes colocações apontadas contribuindo com essa
dissertação e com a instituição aeroespacial, por conseqüência.
Ao Professor Antonio Faria Neto, pelas relevantes considerações contribuindo com a
melhoria da dissertação até sua versão final.
A todos os Entrevistados que tiveram paciência e tempo de me receberem e esclarecerem os
processos para que essa dissertação se tornasse realidade.
Sendo todas as coisas causadas e causadoras, ajudadas e ajudantes,
mediatas e imediatas, e todas elas mantidas por um elo natural e
imperceptível, que interliga as mais distantes e as mais diferentes,
considero impossível conhecer as partes sem conhecer o todo,
assim como conhecer o todo sem conhecer, particularmente, as
partes...
Pascal
RESUMO
Essa dissertação, motivada pelo relatório de investigação do acidente do Veículo Lançador de
Satélites VLS-1 V03, nas falhas em programas espaciais estrangeiros avançados e com suas
recomendações de melhoria, analisa os processos existentes e propõe processos adicionais
para a engenharia de sistemas do Veículo de Sondagem VSB-30. O VSB-30 é desenvolvido
pelo Instituto de Aeronáutica e Espaço. Os processos são: gerenciamento de requisitos,
desenvolvimento de requisitos, soluções técnicas, verificação, integração do produto e
validação. Todos os processos estão baseados na análise do atendimento às melhores práticas
do CMMI (Modelo Integrado de Capabilidade e Maturidade) e da utilização da notação
IDEF0. Os processos existentes foram analisados usando a notação IDEF0 com relação ao
CMMI. Os processos adicionais estão baseados nas melhores práticas do CMMI usando a
notação IDEF0. Melhorias foram propostas aos processos que atendiam ao CMMI, e
processos adicionais e seus respectivos diagramas IDEF0 foram propostos para as áreas de
processos que não são cobertas pelos processos existentes. Usando os diagramas IDEF0,
métricas de produto e processo foram derivadas para serem utilizadas em desenvolvimentos
futuros. A capabilidade de processos e a maturidade da organização foram avaliadas baseadas
nos níveis estabelecidos pelo CMMI. As conclusões dessa dissertação são que o CMMI pode
ser utilizado como um modelo de referência para avaliação do nível da capabilidade dos
processos do VSB-30 e de outros veículos, bem como da maturidade da organização e, que a
notação IDEF0 fornece a visibilidade necessária para identificar oportunidades para melhoria
de processos como, por exemplo, um melhor gerenciamento de requisitos de sistemas e
subsistemas, e a rastreabilidade dos requisitos no ciclo de vida de um programa espacial.
Palavras-chave: Engenharia de Sistemas. VSB-30. CMMI. Capabilidade. Maturidade. IDEF0.
Processos. Melhorias. Métricas.
ABSTRACT
This thesis, based on VLS-1 V03 accident investigation report, advanced foreigner space
programs faults and their improvements recommendations, analyses existing processes and
proposes additional ones for the systems engineering of Sounding Rocket VSB-30. VSB-30 is
developed by Instituto de Aeronáutica e Espaço. The processes are: requirements
management, requirements development, technical solution, verification, product integration
and validation. All processes are based on compliance with CMMI (Capability Maturity
Model Integration) best practices and the use of IDEF0 notation. Existing processes were
analysed in comparison with CMMI using IDEF0 notation. Processes proposed are based on
CMMI best practices using the IDEF0 notation. Improvements were proposed to the process
complying with CMMI and additional processes and their respective IDEF0 models were
proposed to processes areas not covered by existing processes. Using IDEF0 models, product
and process metrics were derived in order to serve as a reference for future developments.
Process capability and organization maturity were assessed based on CMMI scale.
Conclusions are that CMMI may be used as a reference model for assessing the status of
current and other rocket processes capability as well as the organization maturity and that
IDEF0 provides the necessary visibility for identifying opportunities for processes
improvement as better systems and subsystems requirement management and the traceability
of requirements during a space program life cycle.
Keywords: Systems Engineering. VSB-30. CMMI. Capability. Maturity. IDEF0. Processes.
Improvements. Metrics.
LISTA DE FIGURAS
Figura 1- Cadeia de suprimentos 23
Figura 2 - Áreas de atividade do movimento sistêmico 25
Figura 3 - Modelo de desenvolvimento de ciclo de vida em ´cascata´ 28
Figura 4 - Modelo de desenvolvimento de ciclo de vida em ´espiral´ 29
Figura 5 - O formato do diagrama em ´V´ para um ciclo de vida 31
Figura 6 - As três dimensões críticas 35
Figura 7 - Componentes do modelo CMMI® 37
Figura 8 – Áreas de processos de apoio 40
Figura 9 - Estrutura da representação contínua 40
Figura 10 - Estrutura da representação por estágios 42
Figura 11 - Os processos de engenharia de sistemas do CMMI e suas relações 43
Figura 12 - Diagrama IDEF0 50
Figura 13 - Decomposição Hierárquica do método IDEF0 51
Figura 14 - Representação de um bloco 52
Figura 15 - Representação de setas 52
Figura 16 - Diagrama A-0 54
Figura 17 - Fases do Procedimento Metodológico 56
Figura 18 - Mapeamento das áreas de processos do CMMI usando IDEF0 58
Figura 19 - Veículo de sondagem VSB-30 59
Figura 20 - Diagrama A0 de verificação dos componentes 61
Figura 21 - Diagrama A0 de integração de sistemas e subsistemas 62
Figura 22 - Diagrama A0 de validação 63
Figura 23 - Diagrama A0 do desenvolvimento de requisitos 69
Figura 24 - Desdobramento do Diagrama A0 do desenvolvimento de requisitos 70
Figura 25 - Desdobramento do subprocesso de desenvolvimento de requisitos do produto 71
Figura 26 - Desdobramento do subprocesso de análise e validação de requisitos 72
Figura 27 - Diagrama A0 de gerenciamento de requisitos 73
Figura 28 - Diagrama A0 das soluções técnicas 74
Figura 29 - Desdobramento do Diagrama A0 das soluções técnicas 75
Figura 30 - Desdobramento do subprocesso de desenvolvimento do projeto do produto 76
Figura A1- Diagrama A0 de verificação dos componentes 88
Figura A2 - Desdobramento do Diagrama A0 de verificação dos componentes 89
Figura A3 - Desdobramento do subprocesso de verificar pirotécnicos 89
Figura A4 - Diagrama A0 de integração 90
Figura A5 - Desdobramento do Diagrama A0 de integração 90
Figura A6 - Desdobramento do processo de testar rede elétrica 91
Figura A7 - Desdobramento do processo de montar o 1º estágio 92
Figura A8 - Desdobramento do subprocesso de montar motor S31 e empenas 92
Figura A9 - Desdobramento do subprocesso de montar módulo dianteiro 93
Figura A10 - Desdobramento do processo de montar o 2ºestágio 94
Figura A11 - Desdobramento do subprocesso de montar motor S30 e empenas 94
Figura A12 - Desdobramento do subprocesso de montar motor adaptor 95
Figura A13 - Diagrama A0 de validação 95
Figura A14 - Desdobramento do Diagrama A0 de validação 96
Figura A15 - Desdobramento do subprocesso de validação de estrutura 97
Figura A16 - Desdobramento do subprocesso de validação de descrições estruturais 97
Figura A17 - Desdobramento do subprocesso de validação de interfaces estruturais 98
Figura A18 - Desdobramento do subprocesso de validação subsistemas e integração 98
Figura A19 - Desdobramento do subprocesso de validação de propulsão 99
Figura A20 - Desdobramento do subprocesso de validação da descrição de propulsão 99
Figura A21 - Desdobramento do subprocesso de validação da funcionalidade propulsão 100
Figura A22 - Desdobramento do subprocesso de validação da mecânica de propulsão 100
Figura A23 - Desdobramento do subprocesso de validação de suprimento de energia 101
Figura A24 - Desdobramento do subprocesso de validação do desempenho de suprimento 101
de energia
Figura A25 - Desdobramento do subprocesso de validação da instrumentação e 102
seqüenciamento de eventos
Figura A26 - Desdobramento do subprocesso de validação da ignição dos propulsores 102
LISTA DE QUADROS
Quadro 1 - Matriz de maturidade de gestão da qualidade segundo Crosby 22
Quadro 2 - Níveis de maturidade de desempenho 23
Quadro 3 - Fases da aplicação da engenharia de sistemas para qualidade 34
Quadro 4 – Vantagens comparativas entre as representações contínua e por estágios 36
Quadro 5 – Descrição e significado da representação contínua 41
Quadro 6 – Descrição e significado da representação por estágios 42
Quadro 7 – Exemplos de métricas 46
Quadro 8 – Perfil dos entrevistados do presente trabalho 57
Quadro 9 - Evidência de atendimento do processo de verificação 65
Quadro 10 - Evidência de atendimento do processo de integração 66
Quadro 11 - Evidência de atendimento do processo de validação 67
Quadro 12 - Métricas propostas para cada área de processo 78
LISTA DE SIGLAS
ABNT
Associação Brasileira de Normas Técnicas
AEB
Agência Espacial Brasileira
BA
Bateria de Alimentação
BP
Bateria de Pirotécnicos
CAD
Computer-Aided Design
CAR
Causal Analysis and Resolution
CIP
Conector de Interface Pirotécnica
CM
Configuration Management
CMMI
Capability Maturity Model Integration
COTS
Commercial Off-The-Shelf
CP
Condição Passiva
CTQ
Controle Total da Qualidade
DAR
Decision Analysis and Resolution
DOD
Department Of Defense
DS
Dispositivo de Segurança
ECSS
European Cooperation on Space Standardization
EI
Electric Iniciators
EMC
Energy Module Commutation
ESA
European Space Agency
FMEA
Failure Modes and Effects Analysis
GP
IAE
Garantia do Produto
Instituto de Aeronáutica e Espaço
IAQG
International Aerospace Quality Group
ICD
Interface Control Document
IDEF0
IFI
Integration Definition for Function Modeling
Instituto de Fomento e Coordenação Industrial
INCOSE
International Council on System Engineering
IPM
Integrated Project Management
IPPD
Integrated Product and Process Development
ISO
International Organization for Standardization
M-02
Voltímetro
MA
Measurement and Analysis
MCE
Módulo de Comutação de Energia
MIP
Main Inspection Points
MNC
Material Não Conforme
MTBF
Mean Time Between Failures
NASA
National Aeronautics and Space Administration
NIST
National Institute of Standards and Technologies
OID
Organizational Innovation and Deployment
OPD
Organizational Process Definition
OPF
Organizational Process Focus
OPP
Organizational Process Performance
OT
Organizational Training
PI
Product Integration
PIR
Propulsor de Indução de Rolamento
PMC
Project Monitoring and Control
PN
Part Number
PNQ
Prêmio Nacional da Qualidade
PP
Project Planning
PQPA
Process and Product Quality Assurance
QFD
Quality Function Deployment
QPM
Quantitative Project Management
RD
Requirements Development
REQM
Requirements Management
RH
Recursos Humanos
RIPP
Roteiro de Inspeção de Peças Primárias
RSA
Relay Safety A
RSB
Relay Safety B
RSKM
Risk Management
SAD
Safety Arm Device
SAM
Supplier Agreement Management
SG
Specific Goals
SGQ
Sistemas de Gestão da Qualidade
SIR
Sistema de Indução de Rolamento
SN
Serial Number
SP
Specific Practices
SSE
Subsistema de Suprimento de Energia
TBD
To Be Defined
TS
Technical Solution
USAF
United States Air Force
VAL
Validation
VER
Verification
VLS
Veículo Lançador de Satélites
VS-40
Veículo de Sondagem VS-40
VSB-30
Veículo de Sondagem “Booster” - 30
LISTA DE ABREVIATURAS
c.
componente
comp.
componente
conect.
conector
dimens.
dimensional
disp.
disponibilidade
equip.
equipamento
ext.
externo
funcion.
funcionamento
int.
interno
integr.
integração
mod.
módulo
p.
plano
p/
para
reg.
regras
reutil.
reutilização
seg.
segurança
LISTA DE SÍMBOLOS
°
graus
m
metro
km
quilômetro
g
aceleração da gravidade na altitude H
°C
temperatura Celsius (centígrada)
%
porcentagem
s
segundo
kg
quilograma
V
Volt
N
Newton
I
corrente elétrica
SUMÁRIO
1 INTRODUÇÃO 17
1.1 Justificativa do trabalho 18
1.2 Objetivos e delimitação do trabalho 19
1.3 Contribuições 20
1.4 Estrutura do trabalho 20
2 SISTEMAS DE GESTÃO DA QUALIDADE 22
3 ENGENHARIA DE SISTEMAS 25
3.1 Sistemas 26
3.2 O que é engenharia de sistemas 26
3.3 Modelos de ciclo de vida para desenvolvimento 28
3.4 A qualidade na engenharia de sistemas 31
3.5 A abordagem de engenharia de sistemas para sistemas de gestão da qualidade 33
4 MODELO INTEGRADO DE CAPABILIDADE E MATURIDADE (CMMI®) 35
4.1 Níveis de capabilidade 40
4.2 Níveis de maturidade 41
4.3 Modelo de ciclo de desenvolvimento do CMMI® 43
5 MÉTRICAS 46
6 A FERRAMENTA IDEF0 49
6.1 Sintaxe do IDEF0 51
6.2 Diagramas IDEF0 53
6.2.1 Tipos de diagramas 53
6.2.2 Contexto do diagrama macro 53
6.2.3 Diagrama filho 54
7 PROCEDIMENTO METODOLÓGICO 55
7.1 Classificação da pesquisa 55
7.2 Descrição do método de pesquisa utilizado 55
8 O PROCESSO DE ENGENHARIA DE SISTEMAS DO VSB-30 59
9 DISCUSSÃO DOS RESULTADOS 64
9.1 Análise do processo de verificação 64
9.2 Análise do processo de integração de produtos 66
9.3 Análise do processo de validação 67
9.4 Análise do refinamento dos mapeamentos 67
9.5 Análise dos processos que não atenderam ao modelo CMMI 68
9.5.1 Mapeamento do processo de desenvolvimento de requisitos 68
9.5.2 Mapeamento do processo de gerenciamento de requisitos 72
9.5.3 Mapeamento do processo de soluções técnicas 74
9.6 Derivação de métricas 77
9.7 Análises de maturidade e capabilidade 79
9.7.1 Análise de capabilidade 79
9.7.2 Análise de maturidade 80
10 CONCLUSÕES 81
REFERÊNCIAS 83
APÊNDICE A - Diagramas IDEF0 das áreas de processos de Verificação, Integração e 88
Validação
ANEXO A - Áreas dos processos de engenharia do CMMI 103
ANEXO B - Regras gerais para diagramas IDEF0 138
ANEXO C - Conceitos de metodologia, processos, métodos e ferramentas 141
17
1 INTRODUÇÃO
O relatório de investigação do acidente de Alcântara-MA (2003) com o terceiro protótipo do
Veículo Lançador de Satélites (VLS–1 V03) resultou na recomendação para o Instituto de
Aeronáutica e Espaço (IAE), que é a organização aeroespacial executora do desenvolvimento
de projetos de foguetes de sondagem e veículos lançadores de satélites, a adoção de normas
para a garantia da qualidade, para o gerenciamento de projetos e para procedimentos de
certificação; entre elas, a estruturação de um programa e garantia do produto de sistemas
espaciais (NBR 14857) e o modelo para a garantia da qualidade em projeto, desenvolvimento,
produção, instalação e serviços associados (NBR 15100) (BRASIL, 2004).
Além da recomendação para adoção de normas, o relatório de investigação do VLS apontou
recomendações específicas como:
a incorporação de revisões preliminares e críticas de projeto nos planos de
desenvolvimento de produtos;
um melhor intercâmbio de informações entre as organizações participantes;
o aperfeiçoamento da gestão da qualidade;
um melhor gerenciamento de documentação (registro, controle e recuperação de
documentos);
uma melhor comunicação entre funcionários;
o gerenciamento de riscos relativos à segurança de centros de lançamento
principalmente na condução de atividades de integração e preparação para o
lançamento.
Para a Agência Espacial Brasileira (AEB) a responsabilidade pelo desenvolvimento de
sistemas complexos requer que as empresas executoras possuam a competência de engenharia
de sistemas para o fornecimento de equipamentos e subsistemas para os foguetes e satélites, o
que promove o desenvolvimento de tecnologias críticas, como câmaras de alta resolução de
satélites, e conseqüentemente qualifica a indústria nacional e amadurece programas de
melhoria da qualidade, normalização e certificação de produtos espaciais (CARVALHO,
2006).
É importante enfatizar que o Veículo de Sondagem VSB-30 foi certificado em outubro de
2009 pelo Instituto de Fomento e Coordenação Industrial (IFI) e o IAE possui um sistema de
gestão de qualidade aeroespacial implantado (FELICIO, 2008).
18
Segundo Niwa e Munaretto (2007), uma seqüência de falhas em lançamentos de aeronaves
espaciais de programas conduzidos pela United States Air Force (USAF) e National
Aeronautics and Space Administration (NASA) resultou na decisão de se adotar políticas e
instruções para organizar a certificação aplicável para todo o ciclo de vida de um projeto
espacial. Em ambos os casos, o conceito de sistemas foi utilizado de acordo com abordagens
de engenharia de sistemas, as quais podem ser encontradas, por exemplo, em referências
fornecidas por estas duas organizações, denominadas NASA Systems Engineering Handbook
(NASA, 2007) e SMC Systems Engineering Primer and Handbook (USAF, 2005).
O Department of Defense (DOD) dos Estados Unidos da América define engenharia de
sistemas como uma abordagem que traduz as necessidades operacionais e requisitos em
blocos de sistemas ajustados operacionalmente. A abordagem deve consistir em um processo
de análise de requisitos interativa, de cima para baixo, alocação e análise funcional, síntese do
projeto e verificação, e análise de sistema e controle. Deve permear o projeto, a manufatura,
ensaios e avaliações, e apoio ao produto. Os princípios devem influenciar o equilíbrio entre
desempenho, risco, custo e tempo de desenvolvimento (DOD, 2002 apud BLANCHARD,
2008).
Porém, a abordagem de processos do ciclo de vida de um produto é parcialmente aplicada na
engenharia de sistemas em organizações como a NASA, European Space Agency (ESA) e
USAF, e está orientada ao produto e suas especificações técnicas (WIENDL, 2009).
Para garantir que veículos espaciais fossem produzidos com tecnologias e processos estáveis,
evitando a proliferação de falhas, Fortescue e Stark e Swinerd (2003) afirmam que o processo
de qualificação de sistemas espaciais fosse concebido, pois, segundo os autores, a crescente
demanda de requisitos para que o próximo veículo tivesse um tempo de produção menor,
melhor desempenho e que fosse mais barato (faster, better, cheaper), aliado à redução de
apoio governamental, resultou na proliferação de tecnologias “comercialmente avançadas”
(itens de prateleira) usadas para atender custo e cronograma, porém sem um processo de
qualificação.
1.1 JUSTIFICATIVA DO TRABALHO
Considerando a recomendação no relatório de investigação para incorporação de revisões de
projeto e gerenciamento de riscos no desenvolvimento de produtos, a utilização de abordagem
19
de processos na engenharia de sistemas e as falhas de programas espaciais estrangeiros com
suas recomendações de melhoria; o presente trabalho justifica-se pela adoção do modelo de
referência de melhoria de processos, denominado Capability Maturity Model Integration
(CMMI), para a área de engenharia de sistemas, composta pelos processos de
desenvolvimento e gerenciamento de requisitos, soluções técnicas, verificação, integração de
produtos e validação.
Este modelo permite também que sejam analisadas a capabilidade dos processos citados
acima, bem como a maturidade da organização executora do produto (IAE), aperfeiçoando a
gestão da qualidade da organização.
Como ferramentas de análise, utiliza-se o conceito de métricas, que permite o gerenciamento
quantitativo da organização, assim como entrevistas com especialistas do IAE e IFI para que
os processos tornem-se explícitos e permitam uma análise completa do presente trabalho.
Propõe-se também, considerando as recomendações do relatório de investigação para um
melhor intercâmbio de informações entre organizações e entre funcionários, bem como
melhor gerenciamento da documentação; a aplicação da ferramenta Integration Definition for
Function Modeling (IDEF0) nos processos citados acima para permitir uma análise interativa
entre diversos níveis (subprocessos) tendo como benefícios a identificação de documentação
durante o ciclo de vida do produto, fluxos de informações que permitem a comunicação entre
pessoas de processos diferentes, elementos gráficos que auxiliam no gerenciamento
quantitativo e qualitativo dos processos, e gerenciamento de recursos dos processos.
Portanto, as recomendações do relatório de investigação do acidente do VLS e melhorias
propostas pelos programas espaciais estrangeiros em conjunto com as boas práticas apontadas
nas entrevistas e ferramentas, como CMMI e IDEF0, são os elementos para avaliação do
VSB-30 e do IAE.
1.2 OBJETIVOS E DELIMITAÇÃO DO TRABALHO
O presente trabalho está delimitado a um veículo de sondagem de dois estágios (VSB-30)
desenvolvido pelo IAE.
O objetivo do trabalho é analisar os processos de gerenciamento e desenvolvimento de
requisitos, soluções técnicas, verificação, integração e validação usando a ferramenta IDEF0
20
aplicada ao modelo CMMI em uma organização brasileira de desenvolvimento de um veículo
de sondagem de dois estágios (VSB-30).
Apresentam-se como objetivos específicos:
mapear os processos existentes de engenharia do VSB-30 utilizando a ferramenta
IDEF0;
comparar os processos mapeados com o modelo CMMI e analisar os mesmos
utilizando a ferramenta IDEF0;
propor métricas para os processos de forma a torná-los parte de um sistema gerenciado
quantitativamente.
1.3 CONTRIBUIÇÕES
O presente trabalho visa então contribuir para as atividades espaciais do Brasil com a proposta
de incentivar a utilização da abordagem de processos no ciclo de vida do produto, o
aprimoramento da qualidade, o aprimoramento sistemático de desenvolvimento de sistemas
complexos e o atendimento às normas sobre garantia da qualidade e ciclo de vida de
programas espaciais.
1.4 ESTRUTURA DO TRABALHO
O Capítulo 2 apresenta a revisão bibliográfica sobre a maturidade em sistemas de gestão da
qualidade.
O Capítulo 3 faz a revisão bibliográfica sobre a definição de sistemas, conceitos de
engenharia de sistemas, modelos de ciclo de vida para desenvolvimento de produtos, a
importância da qualidade na engenharia de sistemas e a abordagem de engenharia de sistemas
aplicada em sistemas de gestão da qualidade.
O Capítulo 4 apresenta a revisão bibliográfica sobre o modelo integrado de capabilidade e
maturidade, e suas áreas de processos relativas à engenharia de sistemas.
O Capítulo 5 aborda a definição e utilização de métricas.
21
No Capítulo 6 é apresentada a ferramenta IDEF0, sua sintaxe e os diagramas são ilustrados.
O Capítulo 7 aborda o procedimento metodológico utilizado, constituído da classificação da
pesquisa e a descrição do método utilizado.
O Capítulo 8 está estruturado por meio do mapeamento dos processos e subprocessos
estabelecidos da engenharia de sistemas do veículo de sondagem VSB-30 com a utilização da
ferramenta IDEF0.
O Capítulo 9 apresenta a discussão dos resultados obtidos, comparando-se os processos atuais
mapeados com o modelo da área de engenharia proposto, CMMI, e o mapeamento proposto
dos processos que não atendem em sua plenitude aos requisitos do modelo, as propostas de
métricas para cada área de processo e as análises de maturidade e capabilidade.
Finalmente, no Capítulo 10, são apresentados os comentários, recomendações e conclusões
com relação ao atendimento dos objetivos específicos e geral, bem como as contribuições do
presente trabalho para a indústria espacial e sugestões para trabalhos futuros.
22
2 SISTEMAS DE GESTÃO DA QUALIDADE
Abordagem de maturidade tem suas raízes no campo da gestão da qualidade. Um dos
introdutores foi Crosby (1986) com sua Matriz de Gestão da Qualidade, a qual descreve um
comportamento típico exibido por uma empresa em cinco níveis de „maturidade‟, para cada
um dos seis aspectos da gestão da qualidade (Quadro1).
Quadro 1 – Matriz de Maturidade de Gestão da Qualidade segundo Crosby
Estágio I:
Incerteza
Estágio II:
Despertar
Estágio III:
Esclarecimento
Estágio IV:
Sabedoria
Estágio V:
Certeza
Sem compreensão da
qualidade como uma
ferramenta gerencial.
Tendência de culpar o
departamento da
qualidade pelos
„problemas de
qualidade‟.
Reconhecimento de
que a gestão da
qualidade tem valor,
mas sem disposição
de fornecer dinheiro
e tempo necessários.
Enquanto vai de encontro
ao programa de melhoria
da qualidade, aprende
mais sobre gerenciamento
da qualidade, tornando-se
um facilitador e apoiador.
Participativo.
Entendimento
absoluto da gestão
da qualidade.
Reconhece suas
funções pessoais
com ênfase
contínua.
Considera a gestão da
qualidade como parte
essencial do sistema
da companhia.
A qualidade está
inserida na fabricação
ou departamento de
engenharia. Ênfase na
avaliação e
classificação.
Um líder da
qualidade é
designado, mas a
principal ênfase
ainda está na
avaliação e
operação do
produto.
O departamento da
qualidade relata à alta
direção; todas as
avaliações são
incorporadas e o gerente
tem a função na
administração da
companhia.
O gerente da
qualidade é um
executivo; status
efetivo relatado e
ação preventiva.
Envolvido com os
negócios do cliente
e atribuições
especiais.
Gerente da qualidade
integrado com os
diretores. Prevenção é
a preocupação
principal. Qualidade é
um pensamento
prioritário.
Os problemas são
tratados quando
ocorrem, sem soluções;
definição inadequada.
Equipes são
estabelecidas para
atacar os principais
problemas. Soluções
a longo prazo não
são solicitadas.
Comunicação de ações
corretivas determinadas.
Os problemas são
enfrentados abertamente e
resolvidos de uma
maneira sistemática.
Os problemas são
identificados
previamente no
desenvolvimento.
Todas as funções
estão abertas a
sugestões e
melhorias.
Exceto em casos
específicos, os
problemas são
preventivos.
Desconhecido.
Real: 20%.
Divulgada: 3%.
Real: 18%.
Divulgada: 8%.
Real: 12%.
Divulgada: 6,5%.
Real: 8%.
Divulgada: 2,5%.
Real: 2,5%.
Sem atividades
organizadas e sem
compreensão de tais
atividades.
Tentativas de
esforços
motivacionais
óbvios de curto
prazo.
Implementação do
programa dos 14 passos
de Crosby com perfeito
entendimento e
estabelecimento de cada
passo.
Continuidade do
programa dos 14
passos de Crosby e
começando a
“Fazer Certo”.
Melhoria da
qualidade é uma
atividade normal e
contínua.
"Nós não sabemos
porque temos problemas
com a qualidade."
"E necessário ter
sempre problemas
com a qualidade ?"
"Por meio do
comprometimento da
gerência e melhoria da
qualidade nós estamos
identificando e
resolvendo nossos
problemas."
"Prevenção de
defeitos é parte da
rotina de nossas
operações."
"Nós sabemos porque
não temos problemas
com a qualidade."
Fonte: CROSBY (1986) adaptado
A matriz tinha um tema evolucionário forte, sugerindo que as empresas passariam
provavelmente por todas as cinco fases – Incerteza, Despertar, Esclarecimento, Sabedoria e
Certeza – em busca da excelência na gestão da qualidade.
A abordagem de maturidade também é referenciada na NBR ISO 9004 (ABNT, 2000). O
objetivo é avaliar o sistema de gestão da qualidade para cada seção principal da norma,
23
usando uma escala de 1 (sem sistema formal) até 5 (o melhor desempenho da classe),
conforme Quadro 2.
Quadro 2 – Níveis de maturidade de desempenho
Nível de maturidade
Nível de desempenho
Orientações
1
Nenhuma abordagem
formal.
Nenhuma abordagem sistêmica evidenciada, nenhum resultado,
resultados pobres ou resultados imprevisíveis.
2
Abordagem reativa.
Abordagem sistemática baseada em correção de problemas; poucos
dados disponíveis sobre resultados de melhorias.
3
Abordagem estável e
formal do sistema.
Abordagem sistemática baseada no processo; estágio inicial de
melhorias sistemáticas; dados disponíveis sobre conformidade com os
objetivos e existência de tendências de melhoria.
4
Ênfase em melhoria
contínua.
Processos de melhoria em uso, bons resultados e tendências de
melhorias sustentadas.
5
Desempenho melhor da
classe.
Processo de melhoria fortemente integrado; resultados de melhor da
classe quando comparado com referenciais de excelência.
Fonte: ABNT (2000)
Outra vantagem desta abordagem é que resultados monitorados ao longo do tempo podem ser
utilizados para avaliar a maturidade de uma organização.
O IAQG (2009) estabeleceu um manual de gerenciamento da cadeia de suprimentos do setor
aeroespacial (espaço, aviação e defesa) para aplicação em melhoria de sistemas de gestão da
qualidade, cujo objetivo é estabelecer avaliações comuns da maturidade da cadeia de
suprimentos para obter os objetivos sustentáveis de entrega a tempo e com qualidade.
Independente do tipo de área (produção seriada, produção sob encomenda, projetos ou
serviços de apoio ao cliente), o processo para entrega ao cliente final é o mesmo, como mostra
a Figura 1 abaixo:
Fonte: IAQG (2009)
Figura 1 – Cadeia de suprimentos
VENDER
PROJETAR
INTEGRAR E
ENSAIAR
FAZER
PLANEJAR E GERENCIAR
COMPRAR
ENTREGAR
APOIO
REQUISITOS DOS
CLIENTES
RESULTADOS TANGÍVEIS
ENTREGUES AO CLIENTE
24
Este conceito está concentrado em todos os estágios da vida do programa para identificar
riscos, e áreas de melhoria e desenvolvimento de fornecedores. O modelo está definido e
contém 5 níveis:
1- Indefinido e incapaz (nenhum processo; método, ferramentas e/ou comportamentos
desapropriados);
2- Definido e aplicado: mas não 100% eficiente ou não aplicado em qualquer lugar da
empresa (capaz para produtos e serviços de baixo risco);
3- Definido, aplicado e eficaz: capabilidade de desempenho satisfatório e repetitivo;
4- Preditivo: desempenho de melhorias proativas para alvos planejados, mas não
sistematicamente para todos os processo/áreas/produtos; e,
5- Otimizado: melhor em sua classe, melhoria contínua implementada completamente e
envolvimento de todas as partes interessadas como parte da cultura da companhia
(IAQG, 2009).
25
3 ENGENHARIA DE SISTEMAS
A teoria geral dos sistemas é uma ciência geral da totalidade, uma disciplina lógico-
matemática, formal, mas aplicável a várias ciências empíricas como, por exemplo, a teoria da
informação, a cibernética, a teoria dos jogos, as teorias da decisão e das redes, os modelos
estocásticos e a pesquisa operacional (BERTALANFFY, 2008).
Enquanto a teoria dos sistemas tem o caráter de ciência básica, encontra seu correlato na
ciência aplicada e está ligado à moderna automação, distinguindo os seguintes campos:
engenharia de sistemas (planejamento, traçado, evolução e construção científicos de sistemas
homem-máquina), pesquisa operacional (controle científico dos sistemas existentes,
constituídos por homens, máquinas, materiais, dinheiro, etc.) e engenharia humana (adaptação
científica dos sistemas e especialmente das máquinas a fim de obter a máxima ciência com o
mínimo custo em dinheiro e outras despesas) (BERTALANFFY, 2008).
Portanto, para Bertalanffy (2008), o interesse teórico da engenharia de sistemas reside no fato
das entidades cujos componentes são muito heterogêneos poderem ser submetidos com êxito
à análise dos sistemas. A engenharia de sistemas emprega a metodologia da cibernética, da
teoria da informação, a análise das redes, os fluxogramas, os diagramas de bloco, etc. A
Figura 2 mostra as diversas ciências que se utilizam do movimento sistêmico.
Fonte: Mason-Jones e Berry e Nain (1998)
Figura 2 - Áreas de atividade do movimento sistêmico
26
3.1 SISTEMAS
Diversas organizações definem sistema, de maneira similar, como um conjunto de elementos
que se interagem e se inter-relacionam para satisfazer uma necessidade declarada, um objetivo
ou um propósito comum (DOD, 2001; ABNT, 2005; U.S. AIR FORCE, 2005; NASA, 2007).
Este conjunto não deve atuar isoladamente, ou por todos os elementos sem uma organização
(U.S. AIR FORCE, 2005; BLANCHARD, 2008).
Os elementos podem incluir pessoas, hardware, software, locais, políticas, processos e
documentos; ou seja, tudo o que é necessário para produzir resultados em nível de sistema
(NASA, 2009; BLANCHARD, 2008).
Para Blanchard (2008), os resultados incluem qualidades, propriedades, características,
funções, comportamento e desempenho. No sistema, devem ser considerados 4 princípios:
1) deve constituir-se de uma combinação complexa de recursos (materiais, humanos,
financeiros, etc.) de maneira efetiva;
2) deve estar inserido dentro de alguma forma de hierarquia. Um avião pode estar
incluído dentro de uma companhia aérea, que por sua vez é parte de um sistema de
transporte global e que opera em um ambiente geográfico específico, que é parte do
mundo e assim por diante;
3) pode ser estruturado em subsistemas e componentes relacionados, pois permite uma
abordagem mais simples quando se estabelece a determinação de requisitos, e
subseqüente análise do sistema e suas interfaces funcionais, para depois interagir
novamente como um sistema;
4) deve ter um propósito; ser funcional, capaz de responder a uma necessidade
identificada e obter um objetivo global a custo efetivo.
A NASA (2007) ainda define sistema como um produto final, que desempenha funções
operacionais, e habilita produtos, que fornecem serviços de apoio por todo ciclo de vida para
produtos finais, que por sua vez, moldam o sistema.
3.2 O QUE É ENGENHARIA DE SISTEMAS
27
Stevens et al (1998) considera engenharia de sistemas como uma atividade criativa que define
requisitos e produto a ser construído, criando soluções eficazes para problemas e gerenciando
a complexidade técnica de desenvolvimentos.
Engenharia de sistemas considera tanto as necessidades técnicas quanto de negócios para
todos os clientes com a meta de fornecer produtos de qualidade que satisfaçam as
necessidades dos usuários. É uma abordagem multidisciplinar colaborativa de engenharia para
derivar, desenvolver e verificar uma solução sistema balanceada ao longo do ciclo de vida e
que atenda às expectativas dos stakeholders (LOUREIRO, 1999).
Segundo Fortescue e Stark e Swinerd (2003), a engenharia de sistemas garante que todos os
aspectos de um projeto foram considerados e integrados de uma maneira consistente, e é
baseada no princípio de que não existe somente uma solução para atender aos objetivos.
Algumas são melhores que outras, baseado na discriminação de parâmetros, como por
exemplo, custo, massa ou alguma medida de desempenho de sistema. O problema é balancear
estas avaliações desconexas em uma solução simples.
De uma maneira bem simples, a U.S. Air Force (2005) define como a engenharia de um
sistema, ou seja, a aplicação da ciência para projetar um sistema.
A International Council on Systems Engineering (INCOSE) (2007 apud BLANCHARD,
2008) define engenharia de sistemas como uma abordagem interdisciplinar e significa
habilitar com sucesso a realização de um sistema. Tem o foco na definição das necessidades
dos clientes e requisitos funcionais o mais cedo possível do ciclo de desenvolvimento,
documentando os requisitos e então procedendo com a síntese do projeto e validação do
sistema, enquanto considera o problema por completo.
Blanchard (2008) prefere como uma aplicação de esforços científicos e de engenharia para:
transformar uma necessidade operacional em uma descrição dos parâmetros de
desempenho e configuração de sistema por meio do uso de um processo interativo de
definição, síntese, análise, projeto, ensaio, avaliação e validação;
integrar parâmetros técnicos relacionados e garantir a compatibilidade de todas as
interfaces físicas, funcionais e de programas de uma maneira a aperfeiçoar a definição
total do projeto;
integrar confiabilidade, manutenabilidade, ergonomia, segurança, produtividade, apoio
(serviços associados), disponibilidade e outros fatores em um esforço total de
engenharia para atender aos objetivos de custo, tempo e desempenho técnico.
É uma disciplina holística e integrativa, onde a contribuição de engenheiros de estruturas,
elétricos, projetistas de mecanismos, engenheiros de potência e muitas outras disciplinas são
28
avaliadas e balanceadas, uma contra a outra, para produzir um todo coerente que não é
dominado por uma perspectiva de uma disciplina. Procura um projeto seguro e balanceado
para enfrentar interesses opostos e múltiplos, algumas vezes restrições conflitantes (NASA,
2007).
3.3 MODELOS DE CICLO DE VIDA PARA DESENVOLVIMENTO
Uma empresa responsabiliza-se pelo processo de ciclo de vida de um produto que entrega ao
cliente, considerando as seguintes fases (VALERIANO, 2001): identificação de necessidades
do mercado; identificação dos produtos e serviços; definição de requisitos funcionais e de
desempenho; atribuição de requisitos físicos e funcionais, e suas verificações; materialização
do sistema; utilização do produto pelo cliente e sistema de apoio (serviços) e, finalmente, a
fase de declínio, que justifique a retirada do produto ou serviço.
Segundo Estefan (2008), existe uma quantidade grande de modelos utilizados no
desenvolvimento do ciclo de vida de sistemas e software, mas três deles se destacam: (1) o
modelo em „cascata‟ de Royce (1970 apud ESTEFAN, 2008), (2) o modelo em „V‟ de Boehm
(1988 apud ESTEFAN, 2008) e, (3) o modelo em „espiral‟ de Forsberg e Mooz (1992, 1995
apud ESTEFAN, 2008).
O modelo em cascata, conforme Figura 3, é provavelmente o mais antigo e usado.
Fonte: Estefan (2008)
Figura 3 – Modelo de desenvolvimento de ciclo de vida em ´cascata´
Especificação
de requisitos
Análise
Projeto
Construção
(implementação/
codificação)
Teste e
depuração
(verificação)
Operações
29
O modelo acima está baseado numa abordagem de cima para baixo e incluem passos de
iniciação, análise de requisitos, projetos, testes e assim por diante. Os passos são vistos como
independentes um do outro, eram executados em uma seqüência restrita e os efeitos não eram
retornados. Além disso, as interfaces requeridas com outros elementos do sistema (hardware,
fator humano, local, dados, etc.) não eram consideradas (BLANCHARD, 2008).
De acordo com U.S. Air Force (2005), duas das principais deficiências foram reconhecidas no
modelo em cascata. Primeira, a característica de evolução seqüencial inclui atividades de
desenvolvimento que só permitem interações entre fases adjacentes. Segunda, a interação
entre as fases são demoradas, o que tende a estender o período entre a declaração das
necessidades do usuário e a produção do sistema.
Barry Boehm introduziu o modelo de desenvolvimento espiral em 1986 para diminuir o ciclo
de vida de desenvolvimento de software, representado de uma maneira adaptada, conforme
Figura 4 (U.S. AIR FORCE, 2005).
Fonte: Estefan (2008)
Figura 4 – Modelo de desenvolvimento de ciclo de vida em ´espiral´
Neste método, o analista examina continuamente os objetivos, estratégias, alternativas de
projeto e métodos de validação. O desenvolvimento do sistema é resultado de muitas
interações. A prototipagem rápida é usada em cada ciclo e o modelo dá ênfase à análise de
30
riscos. Esta abordagem é particularmente útil em desenvolvimentos de alto risco porque o
projeto às vezes desenvolve-se com o surgimento de requisitos detalhados (BLANCHARD,
2008).
Portanto, para a U.S. Air Force (2005), a ênfase está na análise de risco e não em um processo
documentado ou codificado.
A espiral aplica-se igualmente em novos desenvolvimentos como em melhorias e
atualizações. Possui 4 fases. Inicia-se pelo primeiro quadrante no sentido horário: determine
os objetivos, alternativas e restrições; identifique e resolva os riscos; desenvolva e verifique o
desenvolvimento e produtos; e planeje a próxima fase (U.S. AIR FORCE, 2005).
Na primeira fase, as partes interessadas determinam os objetivos de desempenho e
possibilidades de atualizações. Identificam-se restrições de custo, cronograma, segurança,
ambientais, entre outras, que se aplicam a cada uma das alternativas em análise. Os objetivos
e restrições fornecem uma base para os requisitos (U.S. AIR FORCE, 2005).
As considerações de Boelm sobre riscos distinguem-se do restante. Ele cita numerosas
técnicas de mitigação ou resolução de riscos tais como prototipagem, simulação,
comparações, verificação de referências, questionários de usuários e modelagem analítica.
Isto inclui atividades de mock-up (modelo de um novo produto para teste ou exibição para
clientes) e prototipagem (U.S. AIR FORCE, 2005).
O esforço de prototipagem é usado inicialmente para concepção de provação, e apóia os
usuários ou operadores para definirem seus requisitos. Evoluções subseqüentes da espiral
apóiam a prototipagem de projetos detalhados e, finalmente, de projetos operacionais. A
prototipagem rápida, que não é um elemento do modelo, tem a intenção de produzir
parcialmente os mock-ups ou protótipos operacionais em uma fase antecipada do projeto,
iniciada durante a fase preliminar do projeto (U.S. AIR FORCE, 2005).
A fase de desenvolvimento e verificação tem elementos incluídos no modelo em cascata:
requisitos, projeto, códigos, integração e testes. Para o modelo espiral esta fase é revista 4
vezes. Planejamento, avaliações alternativas e análise de risco são desempenhadas cada vez,
precedidas pelo desenvolvimento e validação de requisitos, projeto preliminar do produto e
projeto detalhado (U.S. AIR FORCE, 2005).
O modelo em ´V´ da Figura 5 reflete, conforme expõe Blanchard (2008), uma abordagem de
cima para baixo e de baixo para cima para o desenvolvimento de sistemas.
31
Fonte: adaptado de STEVENS et al. (1998)
Figura 5 – Ó formato do diagrama em ´V´ para um ciclo de vida.
O lado esquerdo do diagrama em V define o que deve ser construído; o lado direito constrói a
partir dos componentes e verifica os produtos finais contra as especificações do lado
esquerdo. Informações fornecidas para componentes específicos são a base dos testes
daqueles componentes durante o estágio de integração. Componentes são aceitos, integrados e
verificados até serem formados em um sistema completo e testado. Quanto melhor o trabalho
do lado esquerdo é feito, mais fácil é o trabalho do lado direito. A validação é considerada
como uma verificação que mostra que o sistema atende os requisitos dos usuários sob
condições operacionais (STEVENS et al., 1998).
3.4 A QUALIDADE NA ENGENHARIA DE SISTEMAS
Segundo Garvin (1987), qualidade inclui os esforços despendidos no ciclo de vida de um
produto considerando-se as despesas com serviços e manutenção e, portanto, não está apenas
no processo produtivo, no método de trabalho, no produto em si ou atendimento no momento
da compra do produto. Todo um conjunto de processos deve ser determinado para que as
necessidades e requisitos dos clientes sejam atendidos.
Thompson (1999) argumenta que há pouca atenção aos projetos de sistema de gestão da
qualidade, que envolvam processos organizacionais de negócios em que o sistema de gestão
Requisitos do
cliente
Requisitos do
sistema
Projeto técnico
Desenvolvimento de
componente
Testes do
componente
Testes de integração
Testes do sistema
Testes de aceitação
Defini
ç
ão
do
que
ser
á
constru
í
do
Integra
ç
ão
e
verifica
ç
ão
do
que
foi
constru
í
do
tempo
Validação
Verificação
Verificação
32
da qualidade está alinhado com as necessidades do negócio, e indica a necessidade de uma
abordagem de sistema.
A ABNT (2000) determina que as organizações assegurem o desempenho e funcionamento
básico do projeto e desenvolvimento de produtos ou processos, durante o ciclo de vida dos
mesmos, para atender as expectativas dos clientes.
A qualidade de produtos ou serviços é determinada pela extensão que atendem (ou excedem)
os requisitos e satisfação dos clientes, a um custo favorável. Qualidade é um composto de
atributos materiais, incluindo características de desempenho, produtos ou serviços, e que
satisfazem os requisitos do cliente. A chave do sucesso é incorporar a qualidade do
projeto/engenharia de sistemas no produto definindo os requisitos de qualidade de serviços e
produto desde o começo. Um sistema de gestão da qualidade deve ser capaz de:
monitorar, medir, analisar e melhorar processos;
reduzir a variação do produto;
medir e verificar a conformidade do produto;
estabelecer mecanismos para realimentação de desempenho de produto em campo;
implementar uma análise de causa-raíz e sistema de ação corretiva (DOD, 2004).
Segundo Blanchard (2008), a gestão da qualidade total pode ser descrita como uma
abordagem gerencial totalmente integrada que endereça a qualidade do produto ou sistema
durante todas as fases do ciclo de vida, em todos os níveis na cadeia hierárquica do sistema
como um todo. Fornece uma orientação preventiva para a qualidade e é focada no projeto do
sistema, nas atividades de desenvolvimento, na fabricação e produção, manutenção e apoio, e
funções relacionadas. É um mecanismo de unificação que liga as capabilidades humanas à
engenharia, produção e processos de apoio.
A ênfase é a satisfação total do cliente, a prática interativa da melhoria contínua e uma
abordagem organizacional integrada. Com relação ao projeto do sistema e esforço de
desenvolvimento, destacam-se: (1) o projeto dos processos que será utilizado para fabricar e
produzir componentes do sistema e, (2) o projeto da infra-estrutura de apoio que fornecerá
uma manutenção contínua daquele sistema por todo o ciclo de vida planejado. Ou seja, os
princípios da gestão da qualidade total devem estar inseridos dentro do processo de
engenharia de sistemas (BLANCHARD, 2008).
33
3.5 A ABORDAGEM DE ENGENHARIA DE SISTEMAS PARA SISTEMAS DE GESTÃO
DA QUALIDADE
Para Feigenbaum (1988), o trabalho do Controle Total da Qualidade (CTQ) requer meios
efetivos de integrar esforços por parte de um grande número de pessoas, com um grande
número de máquinas e uma quantidade imensa de informações. Portanto, envolve questões de
sistemas em proporções significativas, e uma abordagem de sistemas é parte integrante no
CTQ. Requer a integração das ações da qualidade das pessoas, máquinas e informações em
um forte sistema da qualidade total.
Um sistema da qualidade é uma combinação sobre estrutura de trabalho de operações por toda
fábrica e organização, documentada em procedimentos gerenciais e técnicos integrados, para
direcionar ações coordenadas das pessoas, máquinas e informações da melhor e mais prática
forma, garantindo a satisfação da qualidade pelo cliente e custos da qualidade econômicos
(FEIGENBAUM, 1988).
Engenharia de sistemas, segundo a abordagem de Feigenbaum (1988), é um processo
tecnológico de criação e estruturação de sistemas da qualidade pessoas-máquinas-informações
eficaz. A Engenharia de Sistemas proporciona o que pode ser pensado como a tecnologia de
projeto fundamental do engenheiro da qualidade.
Portanto, Feigenbaum foi um dos pioneiros a definir a abordagem de engenharia de sistemas
para a qualidade por meio de uma nova engenharia que estava surgindo: a teoria dos sistemas
(WATSON, 2005).
A ABNT (2005) define Sistemas de Gestão da Qualidade (SGQ) como atividades organizadas
para dirigir e controlar uma organização com relação à qualidade.
Segundo DiOrio (2003), um SGQ é uma série de processos inter-relacionados e os
subsistemas podem ser vistos como processos de subsistema. O resultado é um programa de
desenvolvimento baseado na abordagem de processo combinado com a metodologia da
engenharia de sistemas. Para isto é necessário seguir 6 fases, conforme Quadro 3.
34
Quadro 3 – Fases da aplicação da engenharia de sistemas para qualidade
Fase
Atividades
1
Desenvolva a especificação do sistema.
2
Defina a configuração do sistema.
3
Desenvolva a especificação de subsistemas/componentes.
4
Desenvolva os subsistemas/componentes.
5
Monte e verifique o sistema.
6
Teste o sistema.
Fonte: (DiORIO, 2003)
A fase 1 já é especificada pelos requisitos de uma norma para SGQ.
A configuração do sistema (fase 2) é definida por meio de um diagrama, um esquema ou um
layout que identifique todos os subsistemas (ou neste caso, processos) e suas interfaces.
A fase 3 pode ser abordada por meio de uma lista de verificação de requisitos para cada
processo identificado no diagrama do SGQ.
O desenvolvimento de processos de subsistemas (fase 4) requer a formação de equipes de
projeto. Isto é facilitado se as interfaces técnica e organizacional, assim como
responsabilidades, são bem definidas. A equipe deve ser treinada na norma em questão e
entender sobre as especificações dos seus processos (lista de requisitos). Somente então,
deveriam definir os seus processos e comparar os resultados com a lista de verificação
correspondente. Se alguns requisitos não são atendidos, a equipe deve aproveitar cada
oportunidade para tornar o processo eficiente e eficaz. Quando o projeto do processo é aceito,
é necessário documentá-lo e implementá-lo.
A fase 5 corresponde à implementação de cada processo de subsistema assim que o projeto e
análise são revisados e aceitos. Isto significar treinar as pessoas em procedimentos e
instruções novos e revisados, liberando documentos aplicáveis e começando a estabelecer
práticas de auditoria para auditores internos e empregados.
Finalmente, a fase 6 compreende uma série de auditorias internas depois que todos os
subsistemas se tornarem operacionais por um período de tempo. Quando completada a fase, a
certificação da norma torna-se um exercício simples onde a melhoria contínua nada mais é do
que um ajuste de um sistema eficiente e eficaz.
Gerkes (1998) também considerou a aplicação na garantia da qualidade baseado na condição
de que a engenharia de sistemas era concebida como uma perfeição metodológica.
35
4 MODELO INTEGRADO DE CAPABILIDADE E MATURIDADE (CMMI®)
Hoje o mercado dispõe de modelos de maturidade, normas e diretrizes que podem ajudar as
organizações a melhorar os negócios. Mas a maioria das abordagens de melhoria foca em uma
parte específica do negócio, e não há uma abordagem de sistemas para os problemas
enfrentados (PHILLIPS et al., 2006).
Capability Maturity Model Integration (CMMI) consiste em práticas que focam o
desenvolvimento e atividades de manutenção que cobrem o ciclo de vida desde a concepção
até a entrega e manutenção. O CMMI é baseado no conceito de engenharia de sistemas,
software e desenvolvimento de produtos, e é focado na melhoria de processos de uma
organização; contém elementos essenciais de processos efetivos para uma ou mais disciplinas
e descreve um caminho de evolução da melhoria desde processos imaturos, disciplinados, até
processos maduros com qualidade e eficácia melhorados (PHILLIPS et al., 2006).
As organizações devem ser hábeis em gerenciar e controlar este complexo processo de
desenvolvimento e manutenção. O gerenciamento efetivo dos bens dos ativos de uma
organização é crítico para o sucesso do negócio (PHILLIPS et al., 2006).
A Figura 6 ilustra 3 dimensões críticas que as organizações tipicamente focam: pessoas,
procedimentos e métodos, e ferramentas e equipamentos.
Fonte: adaptado de PHILLIPS et al.(2006)
Figura 6 – As três dimensões críticas
Segundo Phillips et al. (2006), os processos permitem alinhar a forma como se faz negócios,
permitindo crescimento e fornecendo uma maneira de incorporar conhecimento de como fazer
36
as coisas melhores, e também permitem alavancar recursos e examinar as tendências dos
negócios.
Um foco em processos fornece uma infra-estrutura necessária para negociar com um mundo
em plena mudança e maximizar a produtividade das pessoas, além do uso da tecnologia ser
mais competitiva. Processos efetivos fornecem também um veículo de introdução e uso de
novas tecnologias de maneira a atender da melhor forma os objetivos de negócios da
organização (PHILLIPS et al., 2006).
Nos anos 30, Wallter Shewart começou a trabalhar em melhoria de processos com seus
princípios de controle estatístico da qualidade. Estes princípios foram refinados por Deming,
Crosby e Juran. Watts Humphrey, Ron Radice e outros estenderam estes princípios para
futuras aplicações em software inseridos no modelo de maturidade e capabilidade, com foco
na melhoria de processos dentro da organização (PHILLIPS et al., 2006).
Para Phillips et al. (2006), o modelo permite abordar processos de melhoria e avaliações
usando duas representações: a contínua e a por estágios. A representação contínua permite
selecionar uma área de processo (ou grupo de processos) e melhorá-los, utilizando-se de
níveis de capabilidade relativos a uma área de processo específica.
A representação por estágios usa grupos de áreas de processos predefinidos para definir um
caminho de melhoria para a organização. Cada nível de maturidade fornece um grupo de áreas
de processos que caracterizam diferentes comportamentos (PHILLIPS et al., 2006).
O Quadro 4 compara as vantagens de cada representação e auxilia na determinação de qual
representação é a mais adequada para a organização.
Quadro 4 – Vantagens comparativas entre as representações contínua e por estágio
Fonte: adaptado de (PHILLIPS et al., 2006)
Representação contínua
Representação por estágios
Liberdade para selecionar a ordem de melhoria
que melhor atende aos objetivos de negócio da
organização e diminui as áreas de risco da
organização
Permite as organizações terem um caminho de
melhoria demonstrado e predefinido.
Permite uma visibilidade crescente da
capabilidade obtida em cada área de
processos.
Foca em um grupo de processos que fornecem
uma organização com uma capabilidade
específica caracterizada por cada nível de
maturidade.
Permite melhorias de diferentes processos a
serem desempenhados em diferentes áreas.
Resume resultados de melhoria de processos em
uma forma simples – um simples número de
nível de maturidade.
Reflete uma nova abordagem que ainda não
dispõe de dados para demonstrar o retorno do
investimento.
Constitui um histórico de uso que inclui estudo
de casos e dados que demonstram o retorno do
investimento.
37
Os componentes do modelo são agrupados em 3 categorias – requerido, esperado e
informativo. A categoria requerida descreve o que uma organização deve obter para satisfazer
uma área de processo e é composta por objetivos específicos e genéricos, que são avaliados
para verificação da satisfação de atendimento aos requisitos. A categoria esperados descreve o
que uma organização pode implementar para obter um componente requerido. Guiam
avaliações de melhoria e desempenho. Incluem práticas específicas e genéricas. A categoria
informativo fornece detalhes que ajudam a organização em começar a pensar sobre como
abordar as categorias requeridos e esperados. Subpráticas, resultados típicos de trabalhos,
amplificações, elaborações de práticas genéricas, notas e referências são exemplos de
referência (PHILLIPS et al., 2006).
A Figura 7 mostra graficamente os componentes das áreas de processo.
Fonte: (PHILLIPS et al., 2006)
Figura 7 – Componentes do modelo CMMI®
Existem 22 áreas de processos conforme relação abaixo (PHILLIPS et al., 2006):
1) Causal Analysis and Resolution (CAR): Análise de Causa e Solução, cujo propósito é
identificar causas, defeitos e outros problemas de tal forma que não ocorram novamente;
2) Configuration Management (CM): Gestão da Configuração, cujo propósito é estabelecer e
manter a integridade dos produtos utilizando-se da identificação, controle, situação e auditoria
da configuração;
38
3) Decision Analysis and Resolution (DAR): Análise de Decisão e Solução, cujo propósito é
analisar possíveis decisões utilizando um processo formal de avaliação que analise
alternativas identificadas contra critérios estabelecidos;
4) Integrated Project Management +IPPD (IPM+IPPD): Gestão Integrada de Projeto, cujo
propósito é estabelecer e gerenciar o projeto e o envolvimento das partes interessadas de
acordo com um processo integrado e definido sendo sob medida para um grupo de processos-
padrão de organizações. Também cobre o estabelecimento de uma visão compartilhada para o
projeto e o estabelecimento de equipes integradas que realizarão os objetivos do projeto;
5) Measurement and Analysis (MA): Medição e Análise, cujo propósito é desenvolver e
sustentar uma capabilidade de medição usada para apoiar as necessidades de informações da
organização;
6) Organizational Innovation and Deployment (OID): Inovação e Mobilização
Organizacional, cujo propósito é selecionar e mobilizar melhorias incrementais e inovadoras
que melhorem mensuravelmente os processos e tecnologias da organização. As melhorias
apóiam a qualidade e os objetivos de desempenho de processos da organização são derivados
dos objetivos de negócios da organização;
7) Organizational Process Definition +IPPD (OPD+IPPD): Definição do Processo
Organizacional, cujo propósito é estabelecer e manter um grupo útil de ativos de processos da
organização e trabalhar normas ambientais. Em adição, cobre o estabelecimento de regras
organizacionais e diretrizes que habilitam a condução de trabalhos usando equipes integradas;
8) Organizational Process Focus (OPF): Ênfase no Processo Organizacional, cujo propósito
é planejar, implementar e mobilizar melhorias de processos organizacionais por meio de um
entendimento completo sobre os pontos fortes e pontos fracos correntes dos processos da
organização e dos ativos dos processos;
9) Organizational Process Performance (OPP): Desempenho do Processo Organizacional,
cujo propósito é estabelecer e manter um entendimento quantitativo do desempenho do grupo
de normas de processos da organização em apoio aos objetivos de qualidade e de desempenho
de processos, e fornecer os dados de desempenho de processos, referências e modelos para
gerenciar quantitativamente os projetos da organização;
10) Organizational Training (OT): Treinamento Organizacional, cujo propósito é desenvolver
as habilidades e conhecimento das pessoas de tal forma que possam desempenhar suas
funções efetivamente e eficientemente;
11) Product Integration (PI): Integração do Produto, cujo propósito é montar o produto a
partir de seus componentes garantindo que funcione apropriadamente, e entregar o produto;
39
12) Project Monitoring and Control (PMC): Monitoramento e Controle do Projeto, cujo
propósito é o entendimento do progresso do projeto de tal forma que ações corretivas sejam
tomadas quando o desempenho do projeto desvia significativamente do planejamento;
13) Project Planning (PP): Planejamento do Projeto, cujo propósito é estabelecer e manter
planos que definam as atividades do projeto;
14) Process and Product Quality Assurance (PPQA): Garantia da Qualidade do Produto e do
Processo, cujo propósito é fornecer pessoal e gerenciamento com o objetivo focado no
processo e produtos associados;
15) Quantitative Project Management (QPM): Gestão do Projeto Quantitativo, cujo propósito
é gerenciar quantitativamente os processos definidos do projeto para obter a qualidade
estabelecida do projeto e objetivos de desempenho dos processos;
16) Requirements Development (RD): Desenvolvimento de Requisitos, cujo propósito é
produzir e analisar os requisitos do cliente, do produto e dos componentes do produto;
17) Requirements Management (REQM): Gestão de Requisitos, cujo propósito é gerenciar os
requisitos do produto e dos componentes do projeto, e identificar inconsistências entre os
requisitos, os planos e os resultados do projeto;
18) Risk Management (RSKM): Gestão de Riscos, cujo propósito é identificar potenciais
problemas antes que ocorram de tal forma que atividades de tratamento de riscos possam ser
planejadas e solicitadas quando necessário por toda vida do produto ou projeto, de forma a
diminuir impactos adversos sobre os objetivos a serem atingidos;
19) Supplier Agreement Management (SAM): Gestão de Contrato com Fornecedores, cujo
propósito é gerenciar a aquisição de produtos dos fornecedores;
20) Technical Solution (TS): Soluções Técnicas, cujo propósito é projetar, desenvolver e
implementar soluções para os requisitos. Isto compreende produtos, componentes e processo
do ciclo de vida do produto relacionado em separado ou combinado conforme apropriado;
21) Validation (VAL): Validação, cujo propósito é demonstrar que um produto ou
componente atende completamente seu propósito de utilização quando inserido em um
ambiente especificado;
22) Verification (VER): Verificação, cujo propósito é garantir que os produtos selecionados
atendam seus requisitos especificados.
Todas estas 22 áreas de processos relacionam-se conforme Figura 8, onde as áreas de
processos de Medição e Análise (MA), Garantia da Qualidade do Processo e Produto (PPQA)
e Gestão de Configuração (CM) fornecem apoio básico às outras áreas de processos do
40
CMMI, como por exemplo, necessidades de ações corretivas para produtos não conformes,
abordagem de medição e integridade do produto por meio da gestão de sua configuração.
Fonte: (PHILLIPS et al., 2006)
Figura 8 – Áreas de processos de apoio
4.1 NÍVEIS DE CAPABILIDADE
Para apoiar as organizações que adotam a representação contínua, o CMMI® utiliza modelos
que refletem o nível de capabilidade. O nível de capabilidade engloba objetivos genéricos e
suas práticas genéricas, conforme Figura 9, relacionadas para cada área de processo com o
objetivo de melhoria dos mesmos.
Fonte: (PHILLIPS et al., 2006)
Figura 9 – Estrutura da representação contínua
41
Os 6 níveis de capabilidade, numerados de 0 a 5 conforme Quadro 5, são o Incompleto, o
Realizado, o Gerenciado, o Definido, o Gerenciado quantitativamente e o Em
aperfeiçoamento.
Quadro 5 – Descrição e significado da representação contínua
Fonte: adaptado de (PHILLIPS et al., 2006)
4.2 NÍVEIS DE MATURIDADE
Para apoiar a utilização da representação contínua, todos os modelos CMMI® refletem níveis
de maturidade em seus projetos e conteúdo. O nível de maturidade consiste de práticas
específicas e genéricas para um grupo específico de áreas de processo que melhoram o
desempenho global da organização. O nível de maturidade fornece um meio de prever o
desempenho em uma dada disciplina ou grupo de disciplinas. Os níveis de maturidade são
mensurados pela obtenção de objetivos genéricos e específicos associados com cada grupo
predefinido de áreas de processos, conforme Figura 10. Os cinco níveis são: 1º) inicial, 2º)
gerenciado, 3º) definido, 4º) gerenciado quantitativamente e 5º) em aperfeiçoamento.
Os níveis de 2 a 5 são termos semelhantes aos níveis de capabilidade porque os conceitos de
níveis de capabilidade e maturidade são complementares. Níveis de maturidade são usados
para caracterizar melhorias organizacionais relativas a um grupo de áreas de processos, e
níveis de capabilidade para caracterizar a melhoria organizacional relativas a áreas de
processos individuais.
Nível
Descrição
Significado
0 - Incompleto
Processo que não é realizado ou é parcialmente. Um ou mais
objetivos específicos não são satisfeitos e não existem objetivos
genéricos.
Não aplicável.
1 - Realizado
Atende aos objetivos específicos, mas não está institucionalizado.
Processos relacionados a uma área de
processo são processos realizados.
2 - Gerenciado
Possui infra-estrutura necessária para apoiar o processo; é
planejado e executado de acordo com políticas; emprega pessoas
habilitadas que possuem recursos para produzir resultados
controlados; envolve partes interessadas; é monitorado, controlado
e analisado criticamente.
Existe uma política que indica como o
processo será executado, por meio de
planejamento e monitoramento.
3 - Definido
É gerenciado de acordo com normas da empresa e diretrizes. O
propósito, as entradas, os critérios de entrada, atividades, regras,
medidas, verificações, saídas e critérios de saídas são claramente
declarados.
É mais consistente devido a normas
organizacionais.
4 – Gerenciado
quantitativamente
É um processo definido que utiliza técnicas estatísticas e
quantitativas durante a vida do processo.
É um fator chave que dá maior
visibilidade ao desempenho de
subprocessos, tornando-se mais
competitivo para o mercado.
5 – Em
aperfeiçoamento
É um processo gerenciado quantitativamente, que é melhorado por
meio do entendimento das causas das variações no processo.
Os subprocessos estão estabilizados.
42
Fonte: (PHILLIPS et al., 2006)
Figura 10 – Estrutura da representação por estágios
As descrições de cada nível de maturidade são apresentadas no Quadro 6.
Quadro 6 – Descrição e significado da representação por estágios
Fonte: adaptado de (PHILLIPS et al., 2006)
Nível
Descrição
Significado
1 - Inicial
Os processos são caóticos, não há um ambiente favorável para o
apoio dos processos as empresas.
Excedem o orçamento e não atendem
aos tempos de entrega, abandonam os
processos em tempo de crise e não
conseguem repetir o sucesso.
2 - Gerenciado
Os processos são planejados e executados conforme políticas da
organização e seguem descrições, normas e procedimentos da
organização, uso de pessoas habilidosas e há o envolvimento de
partes interessadas; os processos são monitorados, controlados,
analisados criticamente e verificados.
Há garantia de práticas mesmo em
tempos difíceis, os produtos e entregas
de serviços são visíveis para a
gerência por meio de pontos definidos,
os compromissos são estabelecidos e
revisados com as partes interessadas.
3 - Definido
Os processos são bem caracterizados e entendidos, e são descritos em
normas, procedimentos, ferramentas e métodos. O grupo de
processos-padrão da organização está estabelecido e é melhorado
com o tempo. Os processos declaram o propósito, entradas, critérios
de entrada, atividades, funções, medidas, etapas de verificação,
saídas e critérios de saída.
O grupo de processos-padrão visa à
utilização para um projeto particular e
por isso são mais consistentes.
Os processos são gerenciados
proativamente utilizando o
entendimento das inter-relações das
atividades de processos e medidas
detalhadas do processo, do produto e
do serviço.
4 – Gerenciado
quantitativamente
A organização e os projetos estabelecem objetivos quantitativos para
qualidade, desempenho dos processos e os usa como critérios para
gerenciar os processos. Para subprocessos selecionados, medidas
detalhadas de desempenho são coletadas e analisadas
estatisticamente. Causa especiais de variação de processo são
identificadas e se apropriado, corrigidas para prevenir futuros
problemas.
Os objetivos quantitativos são
baseados em necessidades do cliente e
usuários finais, organização e
implementadores dos processos. A
qualidade e o desempenho são
avaliados em termos estatísticos,
gerenciado por toda vida do processo
e são base para decisões da
organização.
5 – Em
aperfeiçoamento
A organização melhora continuamente seus processos baseados em
entendimento quantitativo da causas comuns de variações inerentes
dos processos. Os objetivos quantitativos de melhoria contínua são
estabelecidos, continuamente revisados para refletir as mudanças nos
objetivos de negócios, e usadas como critério de gerenciamento da
melhoria contínua.
Melhoria continua em processos
incrementais e inovativos, e melhorias
tecnológicas. Os efeitos da melhoria
são medidos e avaliados contra
objetivos quantitativos de melhoria.
43
4.3 MODELO DE CICLO DE DESENVOLVIMENTO DO CMMI®
As áreas de processos de engenharia de sistemas cobrem o desenvolvimento e a manutenção
das atividades com o uso da terminologia da engenharia de tal forma que o uso de qualquer
disciplina técnica do processo de desenvolvimento do produto (como engenharia de software
ou engenharia mecânica) pode usá-las para melhoria do processo (PHILLIPS et al., 2006).
As áreas de processos de engenharia também integram os processos associados com
diferentes disciplinas de engenharia em um processo singular de desenvolvimento de produto,
apoiando uma estratégia de melhoria de processo orientada ao produto. Esta estratégia foca
objetivos de negócios essenciais ao invés de disciplinas técnicas específicas. Esta abordagem
de processo evita efetivamente a tendência de mentalidade departamentalizada da organização
(PHILLIPS et al., 2006).
As áreas de processo de engenharia, conforme Figura 11, são aplicadas ao desenvolvimento
de qualquer produto ou serviço no domínio do desenvolvimento. São elas:
• desenvolvimento de requisitos;
• gestão de requisitos;
• soluções técnicas;
• integração do produto;
• verificação; e,
• validação (PHILLIPS et al., 2006).
Fonte: (PHILLIPS et al., 2006)
Figura 11 - Os processos de engenharia de sistemas do CMMI e suas relações
44
A área de processo Desenvolvimento de Requisitos (RD) identifica as necessidades dos
clientes e traduz estas necessidades em requisitos do produto. O conjunto de requisitos do
produto é analisado para resultar em uma solução conceitual de alto nível e são alocados para
estabelecer um conjunto inicial de requisitos dos componentes dos produtos. Esta área de
processo fornece requisitos para área de processo Soluções Técnicas (TS), onde os requisitos
são convertidos na arquitetura do produto, no projeto do componente do produto e no próprio
componente (PHILLIPS et al., 2006).
O processo de Gerenciamento de Requisitos (REQM) mantém os requisitos. Descreve as
atividades para obter e controlar mudanças de requisitos e garantir que outros planos e dados
relevantes são mantidos correntes, e fornece a rastreabilidade de requisitos do cliente para o
produto e para o componente. Garante que mudanças para requisitos são refletidas nos planos
de projeto, atividades e resultados. Este ciclo de mudanças pode afetar todas as áreas de
engenharia de sistemas; por isso, Gerenciamento de Requisitos é uma seqüência recursiva e
dinâmica de eventos, e é fundamental para processos de engenharia de projetos controlados e
disciplinados (PHILLIPS et al., 2006).
A área de processo Soluções Técnicas (TS) desenvolve um pacote de dados técnicos para os
componentes que serão usados pela Integração do Produto (PI). Soluções alternativas são
examinadas com a intenção de selecionar um projeto otimizado e baseado no estabelecimento
de critérios. Estes critérios podem ser significativamente diferentes para os produtos,
dependendo do tipo de produto, do ambiente operacional, requisitos de desempenho,
requisitos de apoio, e cronogramas de custos e entregas. Soluções Técnicas (TS) utiliza-se de
práticas específicas da verificação para desenvolver a verificação do projeto e revisões
durante o projeto e antes da construção final (PHILLIPS et al., 2006).
A Verificação (VER) garante que os resultados selecionados atendem aos requisitos
especificados. Seleciona os resultados e métodos de verificação que serão utilizados para
verificar os resultados contra os requisitos. É geralmente um processo incremental e
usualmente em conclusão com a verificação de todos os produtos montados. A verificação
também integra revisões, que são um método provado de remover defeitos mais cedo e
fornecer informações valiosas para os produtos finais e componentes que estão sendo
desenvolvidos e mantidos (PHILLIPS et al., 2006).
A Validação (VAL) homologa os produtos contra as necessidades dos clientes. Podem ser
realizados em ambiente operacional ou ambiente operacional simulado. Coordenação com o
cliente sobre a validação dos requisitos é uma importante atividade deste processo. O escopo
da validação inclui a validação de produtos, de componentes, produtos trabalhados, produtos
45
intermediários selecionados e processos. Estes elementos de validação requerem uma
reverificação e revalidação. Problemas descobertos durante a validação são resolvidos durante
o desenvolvimento de requisitos e soluções técnicas (PHILLIPS et al., 2006).
A Integração de Produto (PI) contém práticas específicas associadas com a geração da melhor
seqüência possível de integração, integrando os componentes e entregando o produto ao
cliente. Usa técnicas específicas, tanto da verificação quanto da validação, para implementar o
processo de integração (PHILLIPS et al., 2006).
Ressalta-se neste momento que somente este grupo de áreas de processos, conforme Figura
11, do CMMI serão avaliadas, mas que existem grupos de áreas de processos, como por
exemplo, as áreas de processos de apoio representados pela Figura 8, onde a Gestão de
Configuração, também é importante para análise do grupo de Engenharia de Sistemas.
Os objetivos e práticas específicas das áreas de processos de engenharia estão detalhados no
ANEXO A - Áreas dos processos de engenharia do CMMI.
46
5 MÉTRICAS
Métricas são medidas seqüenciais que rastreiam o progresso e tendências do desempenho
técnico de sistemas e processos de desenvolvimento de projetos. Esta atividade que estima e
monitora valores de parâmetros de desempenho técnicos essenciais de projetos são Métricas
de Produto, também conhecidas como medidas de desempenhos técnicos (GREENSPUN,
2004).
Métricas que fornecem informações sobre processos de desenvolvimento, ao contrário de
desempenho de produtos, são chamadas de métricas de processos, como mostra o Quadro 7
(GREENSPUN, 2004).
Quadro 7 – Exemplos de métricas
Métricas de desempenho
Métricas de processos
Outras métricas
O peso de um produto
Erros de desenho
Satisfação de clientes
Força
Rejeições pela qualidade
Qualidade do produto
Confiabilidade
Horas de fabricação de um
produto
Desempenho de fornecedores
Margem de segurança
Horas de tempo perdidos
Negócios de serviços
Tempo de resposta de
sistema
Custos variáveis
Inovações
Fonte: GREENSPUN (2004).
A coleta de métricas auxilia nas avaliações periódicas de um projeto para fornecer uma base
de ação para corrigir tendências adversas, identificar oportunidades para melhorar o processo
de engenharia de sistemas e avaliar o impacto de mudanças no processo; e fornecer um
conjunto de informações de projeto como base para dados empíricos, e estimar projetos
futuros. (GREENSPUN, 2004)
Métricas podem levar a melhorias de parâmetros de produto e desempenho, melhorar o
comportamento do pessoal em todos os níveis e podem ser usadas como prêmios de
reconhecimento (Prêmio Nacional de Qualidade, PNQ). É outro método para avaliar como as
metas e objetivos estão sendo atingidos, e alertar riscos inesperados aos projetos.
(GREENSPUN, 2004).
Segundo Stevens et al. (1998), as métricas de eficiência de desenvolvimento de sistema
necessitam ser gerenciadas em nível de organização. Os objetivos das métricas são melhorar a
eficiência de todos os desenvolvimentos e detectar problemas em uma fase inicial com
47
desenvolvimento simples. As métricas devem fornecer informações para melhorar a qualidade
de decisões, como re-direcionar ou cancelar um projeto, prover mais recursos, analisar os
objetivos de projeto ou determinar o efeito de uma mudança de processo.
A escolha de métricas deve ser cuidadosamente feita, perguntando questões como:
• quais são os requisitos para estas métricas?
• quais decisões são necessárias para realizar o projeto?
• quais informações são necessárias para fazer estas decisões?
• o processo de desenvolvimento pode atender aos objetivos da organização?
(STEVENS et al.,1998)
Ainda, segundo Stevens et al. (1998), métricas para os processos de engenharia de sistemas
poderiam incluir:
• porcentagem de requisitos de usuários atendidos – o que encoraja a criação de
requisitos dos usuários e mede quão bem eles estão sendo implementados por todo
ciclo de vida;
• conformidade a recursos e cronogramas planejados – mede a capacidade da equipe
de planejar e prever;
• quantidade de re-trabalho – pode ser subjetiva, mas mede o esforço que está sendo
desperdiçado. Esta métrica cobre trabalhos não planejados e a interação de um produto
não planejada;
• problemas causados aos usuários por falhas de produto – representa o dano causado
ao cliente por produto que não atendem seus requisitos mais os custos de reposição
e/ou re-instalação.
Para Hauser e Katz (1998), existem 7 armadilhas que levam a métricas não produtivas:
demora nas premiações, uso de premiações arriscadas, métricas difíceis de controlar, perda de
foco no objetivo, escolha de métricas que são precisamente erradas, assumir que os gerentes e
empregados não tem opções, e pensamento limitado.
Métricas como custo reduzido do tempo de desenvolvimento de um produto ou defeitos
descobertos no tempo de vida do produto levam a demora nas premiações e a tendência do
empregado a tomar decisões e ações que recompensam a curto prazo. A solução seria adotar
métricas que são medidas hoje, mas que impactam em resultados futuros.
Qualquer métrica que depende de resultados incertos, por serem além de seu controle, impõe
risco aos gerentes e empregados.
De maneira oposta, Hauser e Katz (1998) propõem 7 passos para boas métricas: ouvir o
cliente, entender os gerentes e empregados, entender a inter-relação, entender as ligações,
48
testar as correlações e testar as reações dos gerentes e empregados, envolverem os
empregados e gerentes, e procurar por novos padrões.
49
6 A FERRAMENTA IDEF0
De acordo com Stevens et al. (1998), a melhoria nos processos de engenharia de sistemas está
atrelada à definição de objetivos mensuráveis, documentação de como são os processos
correntes (as is), definição de como deveriam ser os processos melhorados (should be) e
identificação de lacunas (gaps) entre o padrão ideal e o atual.
Os requisitos de clientes são uma boa fonte de informação para que o desenvolvimento de um
sistema torne-se um processo medido. Melhoria na eficiência de desenvolvimento, tempo de
desenvolvimento de produto, qualidade entregue, medidas de cronogramas, alocação de
recursos, tempo de aplicação dos requisitos dos clientes e quantidade de re-utilização podem
ser avaliados contra os requisitos (STEVENS et al., 1998).
A ferramenta IDEF0 fornece uma “fotografia” das funções e suas interfaces que devem ser
capturadas e entendidas de modo a que se tomem decisões de engenharia de sistemas, que são
lógicas, acessíveis, integrativas e executáveis. Reflete como as funções do sistema se inter-
relacionam, e operam exatamente como uma “fotografia” de um produto que reflete como as
diferentes partes do produto se combinam. Quando usado de maneira sistemática, o IDEF0
fornece uma abordagem de engenharia de sistemas para (NIST, 1993):
realizar análises de sistemas e projetos em todos os níveis para sistemas compostos de
pessoas, máquinas, materiais, computadores e informações de todas as variedades,
toda organização, um sistema ou uma área de estudo;
produzir referência documentada simultaneamente com o desenvolvimento para servir
de base para integração de novos sistemas ou melhorar os sistemas existentes;
comunicação entre analistas, projetistas, usuários e gerentes;
permitir consenso entre a equipe de formar a ser obtida por entendimento comum;
gerenciar projetos amplos e complexos usando medições qualitativas de progresso;
fornecer uma arquitetura de referência para análise da organização, engenharia de
informação e gerenciamento de recursos.
A ferramenta IDEF0, que representa funções ou atividades de sistemas, é um diagrama de
bloco representado pela Figura 12.
50
Figura 12 - Diagrama IDEF0
Segundo Loureiro (1999), este bloco representa uma atividade ou grupo de atividades que
transforma entradas em saídas sob a influência de controles usando mecanismos fornecidos.
As entradas são objetos a serem processados ou transformados pela função ou atividade e
podem ser objetos físicos ou informações.
Os controles são definidos na forma de informação e são usados para ativar, regular e
sincronizar a função, como por exemplo, ordens de fabricação e engenharia, restrições, planos
de fabricação, cronogramas, diretrizes gerenciais e regulamentos.
Os mecanismos podem ser recursos físicos e/ou informações, como arquivos de dados, banco
de dados, máquinas, instalações, sistemas de software e operadores humanos.
As saídas são objetos processados pela função ou atividade. Podem ser objetos físicos ou
informações. Saídas de uma função podem ser entradas de outras funções. Se a saída é uma
informação, ela pode ser atribuída como um controle de entrada, uma atividade de entrada ou
um mecanismo de dados pelas outras funções.
Se a saída é um objeto físico somente poderá ser usada como uma entrada de atividade ou
mecanismo de entrada pelas outras funções (LOUREIRO, 1999).
O IDEF0 é uma ferramenta de análise de processos de qualquer natureza, mediante a
seqüência de diagramas inter-relacionados logicamente, iniciados pela função macro do
sistema. Este diagrama é desdobrado em outros diagramas detalhados a fim de completar o
objetivo do mapeamento, conforme Figura 13 (MARANHÃO; MACIEIRA, 2004).
Função ou atividade
controle
mecanismo
entrada saída
51
4
3
2
1
3
3
2
1
2
1
A0
A4
A42
A-0
More General
More Detailed
This box is the parent of
this diagram.
A4
A42
NOTE: Node numbers shown
here indicate that the box has
been detailed. The C-number
or page number of the child
diagram could have been used
instead of the node number.
A0
0
Mais Geral (nível superior)
Mais Detalhada (nível inferior)
Essa caixa ao ser decomposta
gera o diagrama A4
Fonte: WIENDL (2009)
Figura 13 - Decomposição Hierárquica do método IDEF0
Esta ferramenta fornece vantagens tais como: possibilidade de complementar a natural
limitação de descrições textuais dos processos; possibilidade de fazer análises concisas e
precisas, mesmo para processos complexos; facilidade de rever os processos sob custos e
prazos menores; facilidade de apresentação de alternativas de melhorias; e redução de
ambigüidades, em face à natureza gráfica (MARANHÃO; MACIEIRA, 2004).
6.1 SINTAXE DO IDEF0
Os componentes estruturais, características de linguagem e as regras que definem as relações
entre elas são consideradas como sintaxe de linguagem. Os componentes da sintaxe IDEF0
são os blocos, setas, regras e diagramas. Os blocos representam funções, definidas como
52
atividades, processos ou transformações. As setas representam dados ou objetos relacionados
às funções. Regras definem como os componentes são usados e os diagramas fornecem um
formato para retratar modelos tanto verbalmente como graficamente. O formato também
fornece uma base de modelo de gestão da configuração (NIST, 1993).
Um bloco fornece uma descrição do que acontece em uma função específica, conforme
mostra figura abaixo.
Fonte: NIST (1993).
Figura 14 - Representação de um bloco.
Cada bloco deve ter um nome e número dentro de seus limites. O nome deve ser um verbo no
imperativo ou frase verbal que descreva a função. Os números são utilizados para identificar o
bloco com o texto associado (NIST, 1993).
Uma seta é composta por um ou mais segmentos de linha, terminando com uma ponta de seta
no final. Como mostra a Figura 15, segmentos de retas podem ser retas horizontais e verticais,
ou curva (com um ângulo de 90° conectando partes horizontais e verticais), e podem ter
configuração de ramificações (bifurcação ou junção). As setas não representam um fluxo ou
seqüência como os modelos de fluxo de processos tradicionais; elas conduzem dados e
objetos relacionados às funções a serem executadas (NIST, 1993).
Fonte: NIST (1993).
Figura 15 - Representação de setas.
setas retilíneas
setas curvas
setas
bifurcadas
junções de
setas
Desenvolver
o modelo
1
53
As seguintes regras são definidas para os blocos:
os blocos devem ter tamanho suficiente para inserir um nome;
os blocos devem ter forma retangular com cantos vivos;
os blocos devem ser construídos com linhas sólidas (NIST, 1993)
Para as setas, segue-se:
setas que se curvam devem usar curvas somente com 90°;
setas devem ser desenhadas em segmentos de linhas retas;
setas devem ser desenhadas verticalmente ou horizontalmente, não diagonalmente;
o fim de cada seta deve tocar o perímetro externo do bloco da função e não deve
cruzá-la para o interior do bloco; e,
as setas devem se direcionar para os lados do bloco, não para os cantos (NIST, 1993)
6.2 DIAGRAMAS IDEF0
6.2.1 Tipos de Diagramas
O IDEF0 é composto por três tipos de informações: diagramas gráficos, texto e glossário. O
diagrama gráfico é o principal componente do IDEF0 contendo blocos, setas, interconexões
blocos/setas e relações associadas. Os blocos representam cada função principal de um
assunto, que por sua vez são desdobrados em diagramas mais detalhados até que o assunto
seja descrito em um nível necessário para apoiar os objetivos de um projeto em particular. O
nível macro do diagrama fornece a descrição mais geral ou abstrata do assunto. Este diagrama
é seguido por uma série de diagramas “filhos” fornecendo mais detalhes sobre o assunto
(NIST, 1993).
6.2.2 Contexto do Diagrama Macro
54
Cada representação deve ter um diagrama macro na qual o assunto é representado por um
bloco simples com suas setas ao redor. É também chamado de Diagrama A-0 (pronunciado de
A traço zero). As setas neste diagrama interagem com a área externa da função para
estabelecer um foco no modelo. Uma vez que o bloco representa todo o assunto, o texto
descritivo escrito no bloco é geral. O mesmo pode-se dizer das setas desde que elas
representem também um grupo externo de interfaces ao assunto (NIST, 1993).
O diagrama A-0 também estabelece o escopo e orientação. Um exemplo é mostrado na Figura
16.
Fonte: NIST (1993).
Figura 16 - Diagrama A-0.
6.2.3 Diagrama filho
A função representada no contexto macro do diagrama pode ser decomposta em subfunções
através da criação de diagramas filho. Por sua vez, cada diagrama filho pode ser decomposto
em diagramas-filho de níveis inferiores. Para um dado diagrama, algumas das funções podem
ser decompostas. Cada diagrama-filho contém blocos-filho e setas-filho que fornecem
detalhes adicionais sobre o diagrama-pai. O diagrama-filho, que resulta da decomposição de
uma função, cobre o mesmo escopo do bloco-pai, por isso, o diagrama filho pode ser
entendido como sendo o interior do bloco pai. Esta estrutura é mostrada na Figura 13 (NIST,
1993). As regras gerais são apresentadas no ANEXO B - Regras gerais para diagramas
IDEF0.
55
7 PROCEDIMENTO METODOLÓGICO
Neste capítulo, apresenta-se a classificação do método utilizado, o delineamento do trabalho
de campo e os aspectos relacionados com a sua realização.
7.1 CLASSIFICAÇÃO DA PESQUISA
Existem várias formas de classificar as pesquisas. Ao utilizar Silva e Menezes (2005), o
presente trabalho se classifica:
Sob o ponto de vista de sua natureza, como aplicada, pois se pretende gerar soluções
práticas de melhorias nos processos de engenharia de sistemas do veículo de
sondagem VSB-30;
Sob o ponto de vista da abordagem do problema, como qualitativa, por descrever os
processos e subprocessos da engenharia de sistemas estabelecidos no setor espacial,
pela abordagem de processos e seus significados, e sem o uso de métodos e técnicas
estatísticas ou quantitativas;
Sob o ponto de vista de seus objetivos, como exploratória, pois promove maior
familiarização com os processos estudados de forma a torná-los explícitos;
Sob o ponto de vista de procedimentos técnicos, com a utilização predominantemente
do levantamento, onde a principal fonte de coleta de dados foram entrevistas com
especialistas para mapear os processos estudados e levantar opiniões e melhorias a
respeito dos mesmos (refinamento destes mapeamentos de processo). As entrevistas
com os participantes foram não-estruturadas, o que permitiu explorar amplamente
questões de modo interativo sobre as entradas, saídas, controles e mecanismos da
ferramenta IDEF0. Foram realizadas também observações assistemáticas, sem
planejamento e controles prévios de documentos.
7.2 DESCRIÇÃO DO MÉTODO DE PESQUISA UTILIZADO
56
Nesta seção, apresenta-se uma descrição detalhada do método de pesquisa utilizado para o
mapeamento dos processos estudados, por meio da apresentação das etapas seguidas até o seu
refinamento. O método contempla uma atividade teórica e uma atividade de campo para
obtenção do mapeamento, conforme Figura 17.
Figura 17 – Fases do procedimento metodológico
A presente pesquisa iniciou-se por uma revisão teórica sobre maturidade de sistemas de
gestão da qualidade, engenharia de sistemas, CMMI, IDEF0 e métricas, cujo resultado foi
apresentado nos Capítulos 2, 3, 4, 5 e 6.
Foram realizadas entrevistas que visaram identificar as entradas, controles, mecanismos e
saídas para construção do mapeamento IDEF0, apresentando aos entrevistados o modelo
CMMI. Os entrevistados foram selecionados conforme uma amostra não-probabilística e
intencional, uma vez que foram escolhidos os profissionais das principias áreas de processos
57
de engenharia do VSB-30 que poderiam ter o bom julgamento das mesmas. O perfil dos
entrevistados é apresentado no Quadro 8.
Quadro 8 – Perfil dos entrevistados do presente trabalho
Área de Atuação
Formação
Experiência
Engenharia de Sistemas
Sistemas Espaciais
Engenharia Mecânica
Mestrado em Engenharia Aeronáutica
Doutorado em Engenharia Mecânica
Mais de 20 anos
Pirotecnia
Engenharia Química
Mestrado em Pirotecnia
Mais de 20 anos
Gerência de Projeto
Engenharia Mecânica
Mestrando
Mais de 20 anos
Garantia do Produto
Dimensional
Tecnólogo Mecânico
Mestrando
Mais de 20 anos
Certificação Espacial
Engenharia Mecânica
Mestrando
Mais de 8 anos
Processo de Certificação
Espacial
Engenharia Mecânica
Mestrado em Engenharia de Sistemas utilizando IDEF0
Mais de 5 anos
Engenharia de Sistemas
Sistemas Espaciais
Engenheiro Eletrônico
Mais de 20 anos
Eletrônica
Engenharia Eletrônica
Mestrando
Mais de 20 anos
A revisão teórica e o resultado das entrevistas permitiram o mapeamento dos processos de
gerenciamento e desenvolvimento de requisitos, soluções técnicas, verificação, integração do
produto e validação para o VSB-30, identificando como estão (as is) estabelecidos.
Para esta fase de refinamento utilizou-se de processos de entrevistas pessoais, mas muitas das
respostas obtidas e discussões foram coletadas de forma eletrônica, por e-mails, tais como o
Plano de Verificação da Qualificação (Validação) do Veículo de Sondagem (DURANTE,
2009), a Qualificação de ensaios de componentes eletrônicos (SPINA, 2009), o Roteiro de
Inspeção de Peças Primárias, o Fluxograma de Inspeção, os Procedimentos para
Processamento de Materiais Não-Conformes (FERNANDES, 2009), os Pontos principais de
inspeção (DORE, 2009) e a discussão sobre a área de processo de Soluções Técnicas
(PALMÉRIO, 2009).
Em seguida, por meio de observação dos dados coletados, foram analisadas as áreas de
processos de interesse, verificando se atendem aos objetivos e práticas específicas
estabelecidas no modelo CMMI.
Se os objetivos e práticas foram atendidos, apresentaram-se os mapeamentos preliminares dos
processos estudados com a participação dos mesmos entrevistados para refinamento do
mapeamento, verificando a contribuição da ferramenta IDEF0 para o processo mapeado e
58
analisando-se a proposta de métricas como oportunidade de melhoria dos processos. Por fim
os resultados são analisados em confronto com os aspectos teóricos.
Se o processo mapeado não atendeu aos objetivos e práticas específicas, foi proposta então o
mapeamento das áreas de processos do CMMI por meio da ferramenta IDEF0, apresentado na
Figura 18.
Figura 18 - Mapeamento das áreas de processos do CMMI usando IDEF0.
Por fim, o mapeamento foi apresentado aos mesmos entrevistados das áreas para verificarem
a aplicabilidade da proposta com a realidade implementada (should be), e também analisando
a proposta de métricas para identificar oportunidades de melhorias dos processos. Da mesma
forma que foi feita na etapa anterior, uma análise dos resultados da proposta com os aspectos
teóricos foi realizada.
Os mapeamentos são apresentados nos Capítulos 9 e 10, respectivamente. Os detalhes do
mapeamento são apresentados no APÊNDICE A - Diagramas IDEF0 das áreas de processos
de verificação, integração e validação.
Foram utilizados recursos disponíveis como Power-Point 2007 da Microsoft, suficiente para
realização do mapeamento (diagramas), mas vale salientar que existem recursos específicos
disponíveis no mercado como IDEFØ® da iGrafx® (IGRAFX.D, 1987), o AIØ WIN® da
Kbsi (KBSI, 2006), o Visio da Microsoft e o Cradle SYS (3SL, 2009).
Conceitos específicos para engenharia de sistemas é apresentada no ANEXO C - Conceitos de
metodologia, processos, métodos e ferramentas.
Requisitos
Requisitos dos
componentes e dos
produtos
Requisitos
Soluções
alternativas
Componentes Produto
Necessidades dos Clientes
Componentes
, produtos,
relatórios de
verificação e
validação
REQM
CONTROLE
MECANISMO
ENTRADA SAÍDA
TS
CONTROLE
MECANISMO
ENTRADA SAÍDA
RD
CONTROLE
MECANISMO
ENTRADA SAÍDA
PI
CONTROLE
MECANISMO
ENTRADA SAÍDA
VER
CONTROLE
MECANISMO
ENTRADA SAÍDA
VAL
CONTROLE
MECANISMO
ENTRADA SAÍDA
cliente
CONTROLE
MECANISMO
ENTRADA SAÍDA
59
8 O PROCESSO DE ENGENHARIA DE SISTEMAS DO VSB-30
Os foguetes de sondagem são utilizados para missões suborbitais de exploração do espaço,
capazes de lançar cargas úteis compostas por experimentos científicos e tecnológicos. O
Brasil possui foguetes de sondagem operacionais que suprem boa parte de suas necessidades,
com uma história bem sucedida de lançamentos (DORE et al., 2008).
O veículo de sondagem de dois estágios, conforme Figura 19, é um foguete sem controle
ativo, sendo estabilizado aerodinamicamente e dinamicamente por dois conjuntos de
superfícies aerodinâmicas, denominadas empenas. O foguete não dispõe de sistema de
separação do primeiro estágio. Durante a fase propulsada do primeiro estágio, esse empurra o
segundo estágio com tal intensidade, que não há necessidade de um sistema de fixação entre
os estágios. Cessado o empuxo, o primeiro estágio é empurrado para trás pelo arrasto
aerodinâmico (DORE et al.,2008).
Fonte: AEB (2007)
Figura 19 - Veículo de Sondagem VSB-30
Alguns equipamentos foram adotados a partir de outros foguetes, como por exemplo, o motor
do segundo estágio e as empenas e porta-empenas do primeiro estágio (PALMÉRIO et al.,
2005). O Veículo possui um comprimento de aproximadamente 12,5 (m), um apogeu de
aproximadamente 282 (km), alcance de aproximadamente 87 (km) e aceleração máxima de 12
(g) (PALMÉRIO et al., 2003).
A partir da ferramenta IDEF0 proposta, os processos atuais de verificação, integração do
produto e validação para o referido veículo foram mapeados. Esses mapeamentos encontram-
se no APÊNDICE A - Diagramas IDEF0 das áreas de processos de verificação, integração e
60
validação. Os processos de desenvolvimento de requisitos e gerenciamento de requisitos,
soluções técnicas não foram mapeados conforme IDEF0 porque não possuem um processo
estabelecido conforme modelo CMMI.
Os seguintes resultados foram obtidos no processo de engenharia sistemas do veículo de
sondagem VSB-30:
1) Para a área de processo desenvolvimento de requisitos e gerenciamento de requisitos, os
modelos do CMMI foram apresentados e foi informado que não há um processo sistemático
de avaliação de requisitos determinados pelos clientes baseados no modelo apresentado;
portanto, não atendem aos processos do modelo CMMI;
2) Para a área de processo soluções técnicas, o modelo de soluções técnicas do CMMI foi
apresentado à área de engenharia de sistemas da organização aeroespacial para comparação
com a forma com que foi tratado o projeto do VSB-30. Esse processo não atende ao modelo
CMMI porque o processo de desenvolvimento de requisitos é que fornece como entrada os
requisitos validados e recebe como controle desse processo a arquitetura do produto para
identificar requisitos de interface; portanto, o objetivo específico de selecionar soluções para
os componentes do modelo CMMI não é atendido.
Foi salientado pelo entrevistado o desejo de trabalhar dentro de sistemas padronizados de
desenvolvimento, mas limitações do corpo técnico e de sua incompleta formação naqueles
sistemas têm-se tornado um impeditivo. Foi feita sugestão de tema para tese de doutorado em
como se implantar a prática do modelo CMMI em um ambiente com aquelas limitações
apontadas.
Aquela área informou que não foi seguido plenamente o modelo, embora fosse desejado; os
requisitos de sistema foram apresentados por representantes da Agência Espacial Européia
(ESA) e, a AEB e a organização aeroespacial aceitaram a proposta de desenvolvimento do
veículo e de seus requisitos.
O principal esforço foi o desenvolvimento de um novo motor (S31) que atuaria no primeiro
estágio. Os seus estudos, nas áreas de propulsão e química, foram iniciados imediatamente. A
ESA também iniciou o projeto aerodinâmico do veículo.
Os estudos conjuntos de desempenho e de adaptação para as operações nos centros de
lançamento foram realizados e a redação da árvore de especificações de requisitos foi
concluída. Os subsistemas já desenvolvidos foram adaptados de outros projetos, tais como o
VLS-1 e o VS-40, e os relatórios técnicos de estudo foram cadastrados.
61
A avaliação da qualificação, o vôo de qualificação e os vôos operacionais foram realizados
com sucesso. O processo de produção dos veículos bem como seus dados foram
documentados.
Quanto ao emprego de normas no processo de desenvolvimento, foi esclarecido que não
houve esta imposição. Foram seguidos procedimentos e preceitos adotados internamente na
organização aeroespacial, alguns baseados em normas nacionais e internacionais.
3) Para a área de processo Verificação, após a análise dos documentos apresentados e
entrevistas, realizou-se o seu mapeamento; o resultado completo encontra-se no APÊNDICE
A - Diagramas IDEF0 das áreas de processos de verificação, integração e validação.
A Figura 20 representa a visão macro do processo citado, onde as entradas são informações,
como ordem de serviço a serem preenchidas e requisitos a serem verificados, e os
componentes a serem verificados.
Figura 20 - Diagrama A0 de verificação de componentes.
62
A saída, por sua vez, resulta em relatórios e na verificação dos componentes com base nos
seus controles e mecanismos. Os controles são basicamente normas de ensaios, principais
pontos de verificação do sistema determinados pelo cliente (Main Inspection Points - MIP),
desenhos, planos de fabricação, procedimentos para processos de materiais não-conformes
(MNC), procedimento para emissão de relatório de inspeção de peças primárias (RIPP),
fluxograma de inspeção dimensional e especificações de projeto.
Os mecanismos utilizados para a transformação das atividades baseiam-se nos recursos para
realização de ensaios, inspeções, análises e revisões de projeto, e recursos para preservação do
produto, como limpeza e etiquetagem.
4) Para a área de processo Integração de Produtos, após a análise dos documentos
apresentados e entrevistas, realizou-se o seu mapeamento; o resultado completo é apresentado
no APÊNDICE A - Diagramas IDEF0 das áreas de processos de verificação, integração e
validação.
A Figura 21 representa uma visão geral das entradas, controles, mecanismos e saídas do
processo de integrar os sistemas e subsistemas do Veículo de Sondagem VSB-30.
Figura 21- Diagrama A0 de integração de sistemas e subsistemas.
63
5) Para a área de processo Validação, após a análise dos documentos apresentados e
entrevistas, realizou-se o seu mapeamento; o resultado completo é apresentado no
APÊNDICE A - Diagramas IDEF0 das áreas de processos de verificação, integração e
validação.
A Figura 22 mostra o processo de validação de um veículo de sondagem (VSB-30) onde as
entradas são os componentes e o plano de qualificação que valida o processo; os mecanismos
são recursos utilizados para análises, ensaios realizados, inspeções e simulações; os controles
são os desenhos, normas e especificações técnicas; e as saídas controladas são os relatórios
técnicos e de qualificação.
Figura 22 - Diagrama A0 de validação
Os blocos destacados com “sombras” das Figuras 20, 21 e 22, e das figuras do APÊNDICE A
- Diagramas IDEF0 das áreas de processos de verificação, integração e validação; indicam
que esses processos serão desdobrados em subprocessos. Destaca-se também naqueles
diagramas que quando um desdobramento de uma saída, entrada, mecanismo ou controle não
contém indicações de texto, significa ser a mesma denominação anterior.
64
9 DISCUSSÃO DOS RESULTADOS
Este capítulo discute os resultados do mapeamento dos processos de verificação, integração e
validação bem como dos mapeamentos propostos para os processos de gerenciamento e
desenvolvimento de requisitos, e soluções técnicas da engenharia do VSB-30 referenciados na
Figura 18 (Capítulo 7).
A utilização da ferramenta IDEF0 vai ao encontro da abordagem de sistemas de Feigenbaum
(1988), quando considera a combinação de fatores pessoas-máquinas-informações
satisfazendo o atendimento aos requisitos do cliente com qualidade.
Esta aplicação pode ser estendida às outras áreas de processos da engenharia de sistema, como
preconiza Bertalanffy (2008), onde não foram identificados os atendimentos aos objetivos e
práticas específicas, tais como as áreas de processo de Desenvolvimento de Requisitos,
Gerenciamento de Requisitos e Soluções Técnicas.
Em comparação com o modelo em „cascata‟ discutido por Estefan (2008), a aplicação da
ferramenta IDEF0 em conjunto com o modelo CMMI permite uma melhor interface entre os
elementos do sistema, como os mecanismos e interações entre atividades adjacentes. Já para o
modelo em „V‟ pode-se observar que as atividades de definição do que será construído,
conforme Figura 5, não são satisfeitas para o presente trabalho, mas a integração e verificação
do que foi construído é satisfeita. O modelo em espiral não é aplicável ao VSB-30
pesquisado.
Estes diagramas auxiliam a qualidade durante todas as fases do ciclo de vida do produto, em
todos os níveis na cadeia hierárquica, conforme esclareceu Blanchard (2008), entre outros,
pois se pode verificar, por exemplo, as documentações (controles), os registros (saídas) e
infra-estrutura necessária (mecanismos).
9.1 ANÁLISE DO PROCESSO DE VERIFICAÇÃO
Para o mapeamento do processo de Verificação, todos os objetivos e práticas específicas do
modelo CMMI foram atendidos, conforme o Quadro 9.
65
Quadro 9 – Evidência de atendimento do processo de verificação
Objetivos e práticas
específicas do CMMI
Evidência do atendimento
Comentários
SG 1 Preparar a verificação
O atendimento às práticas específicas
corresponde à evidência de atendimento
deste objetivo específico.
Todas as práticas específicas (SP) foram atendidas.
SP 1.1 Selecionar os
produtos para verificação
Componentes (entradas) das Figuras de
A1 a A3.
A entrada correspondente aos
componentes não verificados da Figura
A1 é desdobrada nas entradas das
Figuras A2 e A3 com relação à
verificação dimensional, de eletrônicos
e pirotécnicos.
A seleção dos produtos para verificação dimensional
corresponde à entrada de componentes e é determinada no
fluxograma de inspeção dimensional e no MIP, que são
controles do bloco 1 da Figura A2.
A seleção dos produtos para verificação de eletrônicos
embarcados é determinada conforme prevê a verificação
de recebimento de sistemas eletrônicos em foguetes de
sondagem, representada na entrada da Figura A2, bloco 2.
A seleção dos produtos para verificação de pirotécnicos é
previsto no relatório técnico onde as amostras de
componentes a verificar são previstas como forma de
atendimento aos requisitos das normas e especificação de
projeto. As entradas são representadas no bloco 3 da
Figura A2 e blocos 1, 2 e 3 da Figura A3.
SP 1.2 Estabelecer o
ambiente para verificação
Mecanismos de infra-estrutura, ensaios,
inspeções, instrumentos
de todas as atividades das Figuras de
A1 a A3.
Estes mecanismos são previstos no procedimento de
MNC, fluxograma de inspeção dimensional, normas de
ensaios para pirotécnicos, especificações de projeto e
normas da NASA e ECSS.
SP 1.3 Estabelecer os
procedimentos e critérios para
verificação
Controles de todas as atividades das
Figuras de A1 a A3.
Os controles são representados em todas as figuras e
correspondem ao MIP, desenhos, especificações de
projeto, normas, plano de fabricação, fluxograma de
inspeção dimensional, procedimento de MNC e RIPP.
SG 2 Realizar
avaliações especializadas
O atendimento às práticas específicas
corresponde à evidência de atendimento
deste objetivo específico
Todas as práticas específicas (SP) foram atendidas.
SP 2.1 Preparar avaliações
especializadas
Controles como procedimento de
MNC, fluxogramas de inspeção,
cronograma de ensaios, roteiro de
inspeção de peças primárias são
preparações identificadas nos controles
das atividades 1, 2 e 3 da Figuras A2 e
A3
O procedimento de MNC prevê a participação do comitê
de revisão de projeto, com participação dos órgãos de
inspeção, garantia da qualidade, divisão de projeto e
divisão de mecânica, assim como avaliações previstas no
RIPP, no fluxograma de inspeção dimensional, onde
também são determinadas as inspeções. O fluxograma do
processo de verificação de eletrônicos prevê a
determinação dos métodos de verificação, como ensaios,
inspeções, análise e revisão de projeto. O cronograma de
ensaios de pirotécnicos previsto que faz parte do relatório
técnico também é uma forma de preparação das
avaliações.
SP 2.2 Conduzir
avaliações especializadas
Atividades dos blocos 1, 2 e 3 das
Figuras A2 e A3.
As atividades de verificação dimensional, eletrônicos e
pirotécnicos prevêem a condução das análises contra os
requisitos (saídas).
SP 2.3 Analisar dados das
avaliações especializadas
Relatórios (saídas) das Figuras A2 e
A3.
Os relatórios de não conformidade são registros de saídas
de problemas em componentes para inspeção dimensional
previsto no procedimento de MNC e fluxograma de
inspeção, bem como a reverificação no processo de
verificação de eletrônicos e pirotécnicos documentadas
nos relatórios.
SG 3 Verificar os
produtos selecionados
O atendimento às práticas específicas
corresponde à evidência de atendimento
deste objetivo específico.
Todas as práticas específicas (SP) foram atendidas.
SP 3.1 Realizar
Verificação
Atividades dos blocos 1, 2 e 3 das
Figuras A2 e A3, bem como os
componentes verificados (saídas dos
blocos 1, 2 e 3 das Figuras A2 e A3).
As atividades de verificação dos componentes podem ser
comprovadas nos relatórios de verificação dimensional,
de eletrônicos e pirotécnicos.
SP 3.2 Analisar os
resultados de verificação
Relatórios de verificação (saídas de
todas as atividades das Figuras de A1 a
A3) e requisitos a serem comprovados
(entradas de todas as atividades das
Figuras de A1 a A3).
A aceitação ou não dos componentes verificados são
registrados após análise dos resultados nos relatórios
técnicos.
66
9.2 ANÁLISE DO PROCESSO DE INTEGRAÇÃO DE PRODUTOS
Para o mapeamento do processo de Integração de Produtos, todos os objetivos e práticas
específicas do modelo CMMI foram atendidos, conforme o Quadro 10.
Quadro 10- Evidência de atendimento do processo de integração
Objetivos e práticas
específicas do
CMMI
Evidência do atendimento
Comentários
SG1 Preparar para a
Integração do Produto
O atendimento às práticas específicas
corresponde à evidência de atendimento deste
objetivo específico.
Todas as práticas específicas (SP) foram atendidas.
SP 1.1 Determinar a
seqüência de integração
As atividades das Figuras A4 a A12
representam a seqüência de integração, que é
por sua vez, entregue ao cliente por meio do
plano de integração e testes.
As datas que foram realizadas as atividades são
registradas no plano de integração e testes apesar da
seqüência ser definida de forma diferente (por itens).
Portanto, o mapeamento feito conforme datas contribui
para uma revisão do plano, apesar de ser entregue como
um requisito de cliente.
SP 1.2 Estabelecer o
ambiente para a
integração do produto
Para cada atividade das Figuras de A4 a A12
estão determinados nos mecanismos,
especificando equipamentos, dispositivos, etc.
As saídas das Figuras de A4 a A12
correspondem aos registros e verificações no
plano de integração e testes, que é uma
documentação de entrada.
Estes mecanismos correspondem ao painel elétrico para
realização dos testes da rede elétrica, contendo fontes de
tensão, lâmpadas, botões conectores, comutadores,
voltímetro (M-02 da Figura A6, bloco 1). Torquímetro
para ajuste dos parafusos nas empenas e motor,
clinômetro para ajuste de ângulo da empenas, gabarito de
trilho para montagem das sapatas de encosto no motor,
etc.
SP 1.3 Estabelecer
procedimentos e
critérios para integração
do produto
Os controles das Figuras de A4 a A12
correspondem aos procedimentos, requisitos de
segurança, tolerâncias, desenhos e restrições
para todas as atividades.
Os procedimentos da integração da rede elétrica são
determinados passo a passo, bem como restrições quanto
à conexão de componentes, tolerâncias de medidas como
voltagem e corrente elétrica, requisitos de segurança para
operação de componentes e restrições de segurança para
operadores (óculos de segurança, pulseira, pulseiras e
jaquetas de dissipação estática).
SG 2 Garantir a
compatibilidade da
interface
O atendimento às práticas específicas
corresponde à evidência de atendimento deste
objetivo específico.
Todas as práticas específicas (SP) foram atendidas.
SP 2.1 Rever as
descrições de interface
para integridade
As interfaces são determinadas pelos desenhos
indicados nos controles das atividades 1 e 2 da
Figura A8, 2 da Figura A9, 1 da Figura A11 e
2 da Figura A12.
Plano de integração e testes contém figuras ilustrativas
dos desenhos de interface, como por exemplo, a interface
entre o motor S31 e porta-empenas; motor S30 e porta
empenas; entre os parafusos, arruelas e sapatas de
encosto; entre o porta-empenas, empenas e o conjunto
parafusos/arruelas/sapatas; o motor S30 e motor adapter.
SP 2.2 Gerenciar as
interfaces
Informações disponíveis no plano de
integração e testes com o controle por meio de
listas dos principais componentes e respectivas
revisões dos desenhos. (controles da Figuras de
A4 a A12).
Para cada atividade de integração é previsto os desenhos
de interface aplicáveis, de forma a se confrontar com a
lista e respectiva revisão disponível.
SG 3 Montar o
produto e entregá-lo
O atendimento às práticas específicas
corresponde à evidência de atendimento deste
objetivo específico.
Todas as práticas específicas (SP) foram atendidas.
SP 3.1 Confirmar a
disponibilidade dos
componentes para
integração
Entradas e saídas de todas as atividades das
Figuras de A4 a A12.
Os planos contem a lista de componentes, registros de
dados referenciados como SN (Serial Number)
SP 3.2 Montar os
componentes
Saídas das Figuras de A4 a A12.
Estas saídas estão representadas por SN (Serial Number)
e à medida que os componentes são montados os SN de
diferentes componentes vão somando-se uns aos outros
como na Figura A8 da montagem do motor S31 e
empenas.
SP 3.3 Avaliar os
componentes montados
Os registros, verificações e componentes em
todas as saídas das Figuras de A4 a A12.
Registro como voltagem e corrente para avaliação dos
testes elétricos são representados na saída dos blocos 1,
2, 3 e 4 da Figura A6, ângulo de incidência das empenas
da saída do bloco 3 da Figura A8, por exemplo.
SP 3.4 Embalar e
entregar o produto
Realizado em site operacional.
O processo de validação fornece a qualificação dos
conteiners para transporte.
67
9.3 ANÁLISE DO PROCESSO DE VALIDAÇÃO
Para o mapeamento do processo de Validação, todos os objetivos e práticas específicas do
modelo CMMI foram atendidos, conforme o Quadro 11.
Quadro 11 - Evidência de atendimento do processo de validação
Objetivos e práticas
específicas do CMMI
Evidência do atendimento
Comentários
SG 1 Preparar para
validação
O atendimento às práticas específicas
corresponde à evidência de atendimento
deste objetivo específico.
Todas as práticas específicas (SP) foram
atendidas.
SP 1.1 Selecionar os produtos
para validação
O plano de qualificação está em todas as
Entradas dos blocos das Figuras de A13
a A26.
Restrições e requisitos em todos os
controles dos blocos das Figuras de A13
a A26.
Métodos de validação referenciados em
todos os mecanismos.
Lista de componentes e materiais, e
desmembramento gráfico do veículo inseridos
no plano de qualificação; além da identificação
de sistemas e subsistemas.
A definição dos métodos está inserida dentro do
plano de qualificação, mas em todas as figuras,
os controles indicam os mecanismos de
métodos.
SP 1.2 Estabelecer o ambiente
para validação
Os mecanismos para os métodos de
todas as atividades da Figura A20
incluem a interface de ferramentas de
ensaios com os produtos, assim como as
atividades da Figura A21, assim como a
validação de interfaces das atividade 4
da Figura A15, desdobrada na Figura
A16, atividade 5 da Figura A18,
atividade 4 da Figura A19, atividade 2
da Figura A23, atividade 3 da Figura
A25 e 4 da Figura A26.
Mecanismos de ensaios incluem os laboratórios
e sua infra-estrutura, como por exemplo,
laboratório de banco de ensaios
hidropneumáticos, metrologia linear, ensaios
dinâmicos, pirotécnica, ensaios estruturais
estáticos, propriedades de massa.
SP 1.3 Estabelecer os
procedimentos e critérios para
validação
Os desenhos, normas técnicas e
especificações técnicas estão nos
controles das Figuras de A13 a A26.
Regras gerais para concepção, projeto e
fabricação do VSB-30, especificação de
condições ambientais, especificação do foguete,
plano de garantia do produto, especificação de
compatibilidade eletromagnética, desenho do
conjunto PIR, ignitor, iniciador, suporte de
fixação do PIR, propulsor S30 e S31equipado.
SG 2 Validar o produto e
componentes
O atendimento às práticas específicas
corresponde à evidência de atendimento
deste objetivo específico.
Todas as práticas específicas (SP) foram
atendidas.
SP 2.1 Realizar a validação
As saídas das Figuras de A13 a A26
correspondem aos relatórios técnicos
que comprovam o atendimento.
Relatórios de ensaio hidráulico de aceitação do
envelope-motor, de queima de propelente, de
tiro em banco do propulsor equipado S31, de
aceitação de baterias, de aceitação do módulo de
comutação de energia, hidráulico do PIR.
SP 2.2 Analisar os resultados
da validação
O relatório de qualificação, que são as
saídas das Figuras de A13 a A26, pelo
organismo de certificação de produto é a
comprovação da análise dos resultados.
O VSB-30 foi certificado em outubro de 2009
por outra instituição aeroespacial.
9.4 ANÁLISE DO REFINAMENTO DOS MAPEAMENTOS
O mapeamento do processo de validação foi apresentado ao organismo certificador, que
homologa o veículo de sondagem VSB-30, para confirmação das atividades desempenhadas.
68
Aquele organismo informou que as saídas de alguns subprocessos são entradas de outros,
como por exemplo, as saídas dos subprocessos de validar desempenho e validar interfaces são
entradas do subprocesso de validar operacional.
Foi salientado também que a utilização da metodologia traz benefícios ao processo de
validação uma vez que permite um melhor gerenciamento dos requisitos de sistema em
relação aos subsistemas, pois a forma matricial atualmente utilizada não deixa clara a relação
entre o sistema e subsistema, apesar de comprová-los através dos subsistemas, mas de
maneira indireta.
Outro benefício observado foi que a utilização do mapeamento aplicado ao VSB-30 também
pode ser útil na aplicação de outros foguetes com o mesmo perfil de missão, como por
exemplo, foguetes de treinamento, VS-30 e VS-40.
Da mesma forma foi apresentado o mapeamento do processo de integração ao responsável da
área que argumentou a necessidade de aplicar denominações sem detalhes, pois há um
entendimento de que se poderia utilizar o mapeamento para as atividades de novas versões do
veículo de sondagem VSB-30.
As áreas envolvidas no processo de verificação confirmaram as etapas apresentadas no
mapeamento, porém com a ressalva de que os ensaios de impedância e sensibilidade de
pirotécnicos são considerados ensaios ambientais e não funcionais e, que o restante está de
acordo com a idéia discutida anteriormente (PINHEIRO, 2009).
9.5 ANÁLISE DOS PROCESSOS QUE NÃO ATENDERAM AO MODELO CMMI
Esta subseção apresenta os mapeamentos propostos dos processos de gerenciamento de
requisitos, desenvolvimento de requisitos e soluções técnicas, que são os processos da
engenharia do VSB-30 que não atendem os objetivos e práticas específicas do modelo CMMI.
9.5.1 Mapeamento do Processo de Desenvolvimento de Requisitos.
A Figura 23 é o diagrama macro do processo de desenvolvimento de requisitos.
Identificam-se na figura suas entradas, que são as necessidades e expectativas dos
69
stakeholders que serão transformadas em requisitos validados como saída, que por sua vez
são as entradas para o processo de Soluções Técnicas.
Figura 23 - Diagrama A0 do desenvolvimento de requisitos
Os controles são representados pelas restrições declaradas pelos stakeholders, as normas
identificadas que não são declaradas pelos stakeholders, requisitos ambientais (como por
exemplo, para laboratórios, ensaios ou infra-estrutura da tecnologia da informação) e
requisitos funcionais e subfuncionais. Estes controles serão alocados nos controles dos blocos
que representam os objetivos e práticas específicas desse processo.
Os mecanismos são representados por ferramentas para obtenção dos requisitos como as
pessoas que realizam análise preliminar de projeto, Quality Function Deployment (QFD) que
mapeia a necessidade dos stakeholders em parâmetros técnicos, e os protótipos e modelos.
Na figura acima também são identificados os mecanismos para identificação do processo de
ciclo de vida do produto; para identificação da qualidade e desempenho técnicos; para
desenvolvimento de cenários onde se inclui restrições quanto à funcionalidade e ambiente
operacionais do produto; para análise da funcionalidade do produto; mecanismos para gestão
de riscos sobre a concepção operacional e funcionalidade; mecanismos para validação dos
requisitos; e mecanismos para identificação de requisitos-chave e para medidas de
desempenho.
70
A Figura 24 é o desdobramento da Figura 23 para a área de processo de desenvolvimento de
requisitos e corresponde aos três objetivos específicos estabelecidos pelo CMMI
representados pelas frases verbais dos blocos do diagrama: desenvolver requisitos do cliente
(SG1), desenvolver requisitos do produto (SG2), e analisar e validar requisitos (SG3). O SG1
é formado pelas seguintes práticas específicas: Obter as necessidades (SP 1.1) e Desenvolver
os requisitos do cliente (SP 1.2). Estas duas práticas são “fundidas” porque a ferramenta
IDEF0 permite o desdobramento de um bloco somente para 3, 4, 5 ou 6 blocos.
Figura 24 - Desdobramento do Diagrama A0 do desenvolvimento de requisitos
O bloco 1 transformará as necessidades e expectativas dos stakeholders (entradas) em
requisitos dos stakeholders documentados (saídas). Os controles e mecanismos foram
comentados na figura anterior. O bloco 2 transformará requisitos dos stakeholders
documentados nos requisitos de produto, componentes e interface. O controle de restrições
dos stakeholders no bloco 1 se desdobrará no controle de restrições dos stakeholders quanto à
verificação e validação, que é o controle do bloco 2. O mecanismo QFD do bloco 1 se
desdobrará em mecanismo de parâmetros técnicos do bloco 2.
71
A Figura 25 é o desdobramento do SG2 da Figura 24, e é composto pelas seguintes práticas
específicas: Estabelecer os requisitos do produto e componentes (SP 2.1), Alocar os requisitos
dos componentes (SP 2.2) e Identificar os requisitos de interface (SP 2.3). As entradas, saídas,
controles e mecanismos seguem o mesmo raciocínio da aplicação anterior.
Figura 25 - Desdobramento do subprocesso de desenvolvimento de requisitos do produto
Os requisitos dos stakeholders documentados (entrada do bloco 1) são transformados nos
requisitos de produto e de componentes. Os requisitos de componentes serão alocados (saída
do bloco 2) e em conjunto com os requisitos do produto serão a entrada do bloco 3, para
serem somados aos requisitos de interface como saída. O controle “arquitetura do produto” do
bloco 3 é oriundo do processo soluções técnicas.
O SG3 da Figura 24 é desdobrado, conforme a Figura 26, em: Estabelecer os conceitos e
cenários operacionais (SP 3.1), Estabelecer a definição de funcionalidade requerida (SP 3.2),
Analisar os requisitos (SP 3.3), Analisar os requisitos para obter equilíbrio (SP 3.4) e Validar
os requisitos (SP 3.5).
72
Figura 26 – Desdobramento do subprocesso de análise e validação de requisitos
Este diagrama transforma seqüencialmente os requisitos do produto, componentes e interface
na concepção operacional, na arquitetura funcional, nos relatórios que identificam falhas,
requisitos-chave, medidas de desempenho, nos riscos relativos aos requisitos e, nos requisitos
validados.
Os diagramas foram apresentados ao entrevistado e comentou, após análise, que os processos
não foram implementados no VSB-30 e que considera uma boa prática. Foi comentado
também que a análise dos requisitos já está sendo utilizada na redefinição das redes elétricas
do VLS, e pode ser verificada na revisão preliminar de projeto do mesmo.
Ficou como sugestão considerar o controle “normas” (Figuras 23 e 24), como podendo ser
uma combinação de requisitos normativos e regulamentares.
9.5.2 Mapeamento do Processo de Gerenciamento de Requisitos.
73
Este mapeamento foi apresentado ao entrevistado em conjunto com o processo de
desenvolvimento de requisitos e foi enfatizado que quando se faz um ensaio de um sistema do
VSB-30, não se tem uma rastreabilidade clara de que os requisitos do cliente estão sendo
comprovados. Isto foi uma crítica feita no processo de certificação do VSB-30. Portanto, os
processos de gerenciamento de requisitos e desenvolvimento de requisitos, utilizando o
mapeamento apresentado, auxiliam na determinação da rastreabilidade de requisitos.
A Figura 27 é o diagrama correspondente à área de processos de gerenciamento de requisitos
e corresponde ao único objetivo específico que é o SG 1 para Gerenciar requisitos, composto
pelas seguintes práticas específicas: Obter o entendimento dos requisitos (SP 1.1), Obter o
comprometimento para com os requisitos (SP 1.2), Gerenciar mudanças de requisitos (SP
1.3), Manter uma rastreabilidade de requisitos (SP 1.4), e Identificar inconsistências entre o
projeto e os requisitos (SP 1.5).
Figura 27 - Diagrama A0 de gerenciamento de requisitos
Nesta figura todas as práticas específicas foram representadas por somente um diagrama.
As mudanças de requisitos, os planos e resultados dos projetos são gerenciados contra
critérios de avaliação e aceitação de requisitos e como mecanismo, utiliza-se de recursos
como um sistema de monitoramento de requisitos para a avaliação de impacto dos requisitos,
tendo como saídas os comprometimentos documentados quanto aos requisitos e mudanças,
74
bem como um banco de dados e status dos requisitos, uma matriz de rastreabilidade dos
requisitos de forma a monitorá-los e, por fim, inconsistências dos requisitos documentadas.
Outra saída são as ações corretivas dessas inconsistências para que as entradas da Figura 27
sejam revistas.
9.5.3 Mapeamento do Processo de Soluções Técnicas.
O mapeamento da área de Solução técnica foi apresentado aos entrevistados que comentaram
que intuitivamente é lógico e indagaram sobre a aplicação do mesmo para os componentes e
não somente ao processo, e compreenderam que a aplicação da metodologia IDEF0 não se
limita somente aos desdobramentos apontados, mas que se necessário poder-se-ia desdobrar
cada diagrama de blocos ao nível mais baixo de hierarquia necessário, incluindo em nível de
detalhes de componentes
A Figura 29 é o desdobramento da Figura 28, formado pelos três objetivos específicos, que
são: Selecionar soluções para os componentes (SG 1), Desenvolver o projeto (SG 2) e
Implementar o projeto do produto (SG 3).
Figura 28 - Diagrama A0 das Soluções Técnicas
75
A Figura 29 apresenta também o SG 1, que é composto pelas práticas específicas de
Desenvolver soluções alternativas e critérios de seleção (SP 1.1) e Selecionar soluções para os
componentes (SP 1.2); e o SG3, que é composto pelas práticas específicas de Implementar o
projeto (SP 3.1) e Desenvolver a documentação de apoio do produto (SP 3.2).
Figura 29 - Desdobramento do Diagrama A0 das Soluções Técnicas
A entrada do bloco 1 corresponde aos requisitos validados do processo de desenvolvimento
de requisitos. Os mecanismos de seleção correspondem às identificações da complexidade do
produto, de riscos, de características de itens de prateleiras (COTS), de evolução de
tecnologias e de fornecedores. Os controles para que as soluções alternativas (saídas) sejam
balanceadas correspondem às restrições de custos (de desenvolvimento, aquisição, apoio, etc.)
e de desempenho, às limitações tecnológicas e às condições operacionais e ambientais.
As entradas do bloco 3 correspondem ao projeto escolhido, como a documentação do projeto,
pacote de dados técnicos, especificações de interfaces, critérios de reutilização de
componentes, análise de se fazer ou comprar e escolha dos itens de prateleira. Para que o
projeto seja implementado (saída) é necessário controles como requisitos de desenhos, listas
76
de peças, normas de qualidade e processos, critérios de segurança, manutenabilidade e
confiabilidade, e mudanças de requisitos, projetos e produtos.
Os mecanismos do bloco 3 são recursos utilizados como CAD, métodos de fabricação,
simuladores de layout, mecanismos de análise de verificação e mecanismos de ensaios
funcionais, ambientais e de inspeções.
O único objetivo específico desdobrado foi o SG2, conforme Figura 30, pois é composto por
4 práticas específicas: Projetar o produto ou componente (SP 2.1), Estabelecer um pacote de
dados técnicos (SP 2.2), Projetar interface utilizando critérios (SP 2.3) e Realizar analises de
se fazer, comprar ou reutilizar (SP 2.4).
Figura 30 - Desdobramento do subprocesso de desenvolvimento do projeto do produto
A arquitetura de requisitos (entrada do bloco 1) é transformada na documentação do projeto,
no projeto dos componentes e na arquitetura do produto, considerando controles como:
restrições de projeto, normas de segurança, interfaces internas e externas, regras para
componentes e interfaces, normas de peças, regras de projeto, normas de interface, cenários,
restrições de produção e tolerâncias de projeto.
77
Os mecanismos do bloco 1 são a infra-estrutura disponível, protótipos, modelos estruturais e
reutilização de projetos.
O bloco 2 tem como entrada a arquitetura do produto, que baseada na documentação do
projeto define um pacote de dados técnicos como saída.
O bloco 3 tem como entradas, a arquitetura do produto e o projeto dos componentes.
Considerando o mecanismo de identificação de interfaces e o controle de documentação do
projeto, a saída determinada é a especificação de interfaces.
O bloco 4 tem como entradas as soluções alternativas, o projeto dos componentes e a
arquitetura do produto. Os controles são as funções do produto, custos, cronogramas,
parcerias, documentação do projeto, pacote de dados técnicos, licenças, garantias e limitações
de produto adquirido. Os mecanismos de redução de riscos, de pesquisa de mercado, de
fornecedores, de disponibilidade de produtos e da funcionalidade completam a figura acima
para determinar os critérios de reutilização, da análise de se fazer ou comprar, e das diretrizes
para se escolher itens de prateleiras.
Seguindo os conceitos Bertrand e Fransoo (2002) os mapeamentos apresentados são
classificados como empírico-descritivos, pois cada mapeamento descreve adequadamente as
relações que possam existir na realidade e leva ao entendimento do processo que está
acontecendo.
9.6 DERIVAÇÃO DE MÉTRICAS
Uma vez analisado o mapeamento dos processos e sua comparação com o modelo ideal foram
propostas métricas baseadas nos diagramas IDEF0, onde as métricas de produtos são
derivadas da relação entre as saídas em relação aos controles e, as métricas de processos são
derivadas da relação entre as saídas e entradas ou entre as saídas e mecanismos, como por
exemplo, tempo, produtividade e riscos programáticos (NASA, 2007). As métricas de
qualidade são métricas definidas pelo controle da qualidade que requerem verificações e
ações corretivas para controle das mesmas. O Quadro 12 são exemplos de métricas de
engenharia de sistemas:
78
Quadro 12 - Métricas propostas para cada área de processo
Processos
Métricas de Produto
Métricas de Processo
Métricas de
qualidade
1.Gerenciamento e
Desenvolvimento de
Requisitos
1.1 Falhas de requisitos
1.2 Requisitos-chave versus
cronograma
1.3 Requisitos funcionais
1.4 Medidas de desempenho versus
atividades de desempenho do
desenvolvimento
1.5 Funções críticas versus
desenvolvimento de componente
1.1 Requisitos identificados
Requisitos aprovados versus
Requisitos finalizados
1.2 Números de novos requisitos
ou requisitos mudados versus
tempo
1.3 Riscos associados aos
requisitos
1.1 Instabilidade de
requisitos
2.Soluções Técnicas
2.1 Funcionalidade
2.2 Segurança
2.3 Acessibilidade
2.4 Tecnologias em uso versus novas
tecnologias
2.5 Padronização
2.6 Tolerâncias de projeto
2.7 Compatibilidade eletromagnética
2.8 Interfaces versus ciclo de vida do
produto
2.1 Dados de defeitos versus itens
de prateleira qualificados
2.2 Desenhos de engenharia
planejados versus desenhos
entregues
2.3 Mitigações de riscos
2.4 Projetos escolhido versus
soluções alternativas
2.5 especificações planejadas
versus finalizadas
2.1 Propostas de
mudanças de
engenharia em
processo versus
pedidos de mudanças
de engenharia
3.Verificação
3.1 Teste funcional com variação de
temperatura
3.2 Verificação de não acendimento
de pirotécnicos
3.3 Números de defeitos versus
números esperados
3.4 Confiabilidade
3.1 Números de requisitos
testados satisfatoriamente
3.2 Requisitos de produto sujeitos
à verificação
3.3 Defeitos ainda em aberto e
fechados
3.4 Números de defeitos versus
fase do ciclo de vida
3.5 Tempo ou taxa de preparação
versus tempo ou taxa esperado
3.1 Processamentos
de problemas versus
Relatórios de falhas
4.Integração do Produto
4.1 Massa estimada versus medida
4.2 Ângulos de incidência
4.3 Comprimento estimado versus
medido
4.4 Resistência média dos iniciadores
4.5 Desvio mínimo de desempenho
4.6 Consistência das interfaces por
toda vida do produto
4.7 Configuração recebida versus
configuração esperada
4.1 Número de componentes
integrados
4.2 Número de interfaces testadas
4.3 Número de ensaios testados
4.1 Taxa de entrega e
sua variação
5.Validação
5.1 Manutenabilidade
5.2 Intercambiabilidade
5.3 Tolerância à falha
5.4 Vida útil
5.5 Medições e desempenhos atuais
para uso pretendido ou necessidade
operacional
5.1 Números de requisitos
operacionais determinados pelos
stakeholders sujeitos à validação
5.2 Números de componentes que
passam por validação
5.1 Requisitos
funcionais aprovados
versus verificados
Dentro as métricas propostas para a área de validação duas foram consideradas de importância
relevantes, segurança e cumprimento da missão, podendo adotar duas métricas: número de
requisitos de segurança atendidos versus número de requisitos e número de requisitos
atendidos da missão versus número de requisitos total da missão.
A relevância está no fato de que se possa atender em plenitude os requisitos da missão, mas
não atender os requisitos de segurança; e atender em plenitude os requisitos de segurança, mas
não atender a missão.
A área de soluções técnicas tem interesse e considera importante a aplicação de métricas, mas
relevou a dificuldade de se coletarem dados e justificativas para obtenção deles. Considerou
79
então uma métrica para controle de documentos e outra métrica combinada que é função do
tempo de queima de motor, volume de recursos gastos com o programa e massa do VSB-30.
A área de gerenciamento de requisitos e desenvolvimento de requisitos sugeriu como métrica
de processos, o número de requisitos validados em relação ao número de requisitos do cliente
documentados e, como métrica de produto, o número de requisitos documentados em relação
às normas regulamentares.
9.7 ANÁLISES DE MATURIDADE E CAPABILIDADE
9.7.1 Análise de capabilidade
Em termos de capabilidade, os processos de verificação, integração e validação da engenharia
de sistemas do veículo de sondagem VSB-30 possuem nível 3 cada um (PHILLIPS et al.,
2006), conforme Quadro 5, pois seguem as normas organizacionais da instituição
aeroespacial.
Contudo, a proposta da presente pesquisa visa estabelecer métricas para gerenciar
quantitativamente as áreas de processos, nível 4 de capabilidade, segundo Phillips et
al.(2006), pois é um fator que permite visualizar o desempenho de subprocessos.
Um nível 4 de capabilidade permite melhorias na qualidade dos processos de verificação,
integração e validação do veículo de sondagem VSB-30, conforme definido por Greenspun
(2004), Stevens et al. (1998) e Hauser e Katz (1998).
Para os processos de gerenciamento de requisitos, desenvolvimento de requisitos e soluções
técnicas, o nível de capabilidade de cada um corresponde ao nível 0 (incompleto), pois os
processos são parcialmente realizados, ou seja, um ou mais objetivos específicos do processo
não são atendidos em relação ao modelo CMMI (PHILLIPS et al., 2006).
Recomenda-se então a utilização dos diagramas representados nas Figuras de 23 a 30 para que
os objetivos específicos dos processos de gerenciamento de requisitos, desenvolvimento de
requisitos e soluções técnicas sejam atendidos, atingindo um nível de capabilidade 1, ou seja,
processo realizado; e posteriormente, a implementação do planejamento e monitoramento do
processo para que atinja o nível de capabilidade 2, ou seja, gerenciado.
80
Por fim, para atingir o nível 3, os processos devem ser institucionalizados de acordo com as
normas organizacionais do IAE.
Seguindo os níveis de capabilidade da IAQG (2009), os processos são definidos e aplicados
(nível 2), mas não aplicado em todos os lugares da organização.
9.7.2 Análise de maturidade
Segundo Stevens et al.(1998), um nível 3 de maturidade é de um modo geral equivalente aos
níveis de definição de uma ISO 9001. Mutafelija e Stromberg (2003) afirmam que as normas
ISO 9001 e o CMMI são compatíveis.
Desta forma entende-se que a maturidade corresponde ao estágio III (Esclarecimento) da
matriz de Crosby (1986), conforme Quadro 1 do Capítulo 2, pois a organização possui uma
coordenadoria da qualidade, representada pela alta direção, com todas as avaliações
necessárias incorporadas (FELICIO, 2008).
Para o modelo da NBR ISO 9004, o nível de maturidade corresponde a uma abordagem
estável e formal do sistema, conforme Quadro 2 (ABNT, 2000).
Comparando com o nível de maturidade definido por Stevens et al.(1998), para Phillips et
al.(2006), o nível de maturidade corresponde ao nível 3, ou seja, definido. Porém,
considerando o processo de gerenciamento de requisitos, que não atende ao CMMI, o nível de
maturidade da organização aeroespacial é 1 (Inicial), conforme Quadro 6 do Capítulo 4,
porque este processo em específico tem que ter um nível de capabilidade 2 para que se tenha,
pelo menos, um nível de maturidade 2 (PHILLIPS et al., 2006).
Para atingir o nível de maturidade 2, é necessário que a capabilidade do processo de
Gerenciamento de Requisitos atinja o nível 2 em conjunto com áreas de processos que não
foram avaliadas nessa dissertação que são: Gestão da Configuração, Planejamento do Projeto,
Monitoramento e Controle do Projeto, Gestão de Contrato com Fornecedores, Medição e
Análise, e Garantia da Qualidade do Produto e do Processo.
81
10 CONCLUSÕES
O presente trabalho teve por objetivo geral analisar os processos de gerenciamento e
desenvolvimento de requisitos, soluções técnicas, verificação, integração e validação usando a
ferramenta IDEF0 aplicada ao modelo CMMI em uma organização brasileira de
desenvolvimento de um veículo de sondagem de dois estágios (VSB-30).
O objetivo geral foi subdividido em três objetivos específicos com o propósito de conduzir o
processo da dissertação. Visando facilitar o entendimento dos comentários, recomendações e
conclusões, estes objetivos são listados a seguir:
1. Mapear os processos existentes de engenharia do VSB-30 utilizando a ferramenta
IDEF0;
2. Comparar os processos mapeados com o modelo CMMI e analisar os mesmos
utilizando a ferramenta IDEF0;
3. Propor métricas para os processos de forma a torná-los parte de um sistema gerenciado
quantitativamente.
O primeiro objetivo foi atendido conforme descreve o Capítulo 8 e o APÊNDICE A -
Diagramas IDEF0 das áreas de processos de verificação, integração e validação. Os processos
de gerenciamento de requisitos, desenvolvimento de requisitos e soluções técnicas não foram
mapeados por meio do IDEF0, pois não existiam processos sistematizados conforme o
modelo CMMI, de acordo com análises durante entrevistas.
Desta forma, atendendo ao segundo objetivo, os processos mapeados foram comparados com
o modelo CMMI por meio dos Quadros 9, 10 e 11 do Capítulo 9. Como os processos de
verificação, integração e validação atenderam aos objetivos e práticas específicas do CMMI,
os mapeamentos aplicados ao modelo CMMI foram propostos para os processos de
gerenciamento de requisitos, desenvolvimento de requisitos e soluções técnicas, conforme as
subseções 9.5.1, 9.5.2 e 9.5.3, respectivamente.
Por fim, o terceiro objetivo foi atendido por meio da Seção 9.6, onde a proposta de métricas
foi apresentada para todos os processos.
As maiores contribuições deste trabalho são os mapeamentos dos processos de engenharia do
VSB-30.
A representação dos diagramas como revisões nos projetos de produtos e gerenciamento de
riscos identificados nas atividades do processo Soluções Técnicas auxiliam o
desenvolvimento de sistemas complexos.
82
Os controles e saídas de todos os diagramas auxiliam o gerenciamento dos documentos e
registros de programas espaciais durante o ciclo de vida do produto; o atendimento ao modelo
CMMI permite uma análise dos níveis de maturidade e capabilidade dos processos e, todas as
atividades dos diagramas IDEF0 permitem a fácil identificação de métricas. Tudo isso
contribui com o aprimoramento da qualidade e atendimento às normas sobre garantia da
qualidade.
Os diagramas contribuem para a implementação da abordagem de processos no ciclo de vida
do produto e o atendimento às normas de ciclo de vida de programas espaciais, permitindo a
identificação de fluxos de informações, inter-relações entre áreas técnicas e os clientes, e
estabilidade dos processos, uma vez que são padronizados.
As análises dos diagramas dos processos de engenharia de sistemas do VSB-30 geram
benefícios como um melhor gerenciamento de requisitos de sistemas em relação aos
subsistemas, a aplicação em foguetes de treinamento e versões atuais do VSB-30 e a garantia
da rastreabilidade dos requisitos do cliente quando se realiza uma atividade.
Recomenda-se aplicar trabalhos futuros do modelo em outros grupos de áreas como Gestão de
Projetos, onde outras áreas de processos do CMMI são utilizadas para avaliar as melhorias
que se desejam implementar; assim como o grupo de processos de apoio (Figura 8); bem
como a implementação do presente trabalho em auditorias de sistemas de gestão da qualidade
tendo como ferramenta o mapeamento dos requisitos necessários para verificação da
conformidade dos mesmos.
83
REFERÊNCIAS
3SL Cradle SYS. © 3SL 2009. Disponível em: <http://www.threesl.com/pages/products/sys.
php>. Acesso em: 12 set. 2009.
AGÊNCIA ESPACIAL BRASILEIRA. Capacidade brasileira de acesso ao espaço. Espaço
Brasileiro, 2007. Disponível em: <http://www.aeb.gov.br>. Acesso em: 1 nov. 2009.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9004: sistemas de
gestão da qualidade: diretrizes para melhorias de desempenho. Rio de Janeiro, 2000.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000: sistemas de
gestão da qualidade: fundamentos e vocabulário. Rio de Janeiro, 2005.
BERTALANFFY, v. L. Teoria geral dos sistemas: fundamentos, desenvolvimento e
aplicações. 3. ed. Petrópolis: VOZES, 2008. 360 p.
BERTRAND, J. W. M.; FRANSOO, J. C. Modeling and simulation: operations management
research methodologies using quantitative modeling. International Journal of Operations
& Production Management, Eindhoven, v. 22, n. 2, p. 241-264, 2002. Disponível em:
<http://www.emeraldinsight.com/0144-3577.htm>. Acesso em: 17 out. 2009.
BLANCHARD, B. S. Introduction to systems engineering. In: ____System engineering
management. 4. ed. Chichester: John Wiley & Sons Ltd, 2008. Disponível em:
< http://media.wiley.com/product_data/excerpt/51/04701673/0470167351.pdf>. Acesso em:
21 maio 2009. cap. 1.
BRASIL. Ministério da Defesa. Comando da Aeronáutica. Departamento de Pesquisas e
Desenvolvimento. Relatório da investigação do acidente ocorrido com o VLS–1 V03, em
22 de agosto de 2003, em Alcântara, Maranhão. São José dos Campos, 2004. 130 p.
Disponível em: <http://www.aeb.gov.br/area/PDF/VLS-1_V03_Relatorio_Final.pdf>. Acesso
em: 02 jun. 2009.
CARVALHO, H. C. Entrevista: Himilcon de Castro Carvalho, diretor de Política Espacial e
Investimentos Estratégicos da Agência Espacial Brasileira (AEB). Defesa@net, jul. 2006.
Seção Exclusivo. Disponível em: <http://www.defesanet.com.br/space/himilcon.htm>.
Acesso em: 15 set. 2009.
CROSBY, P. B. Qualidade é investimento. 2. ed. Rio de Janeiro: JOSÉ OLYMPIO, 1986.
327 p. Tradução do título original Quality is free 1979. Traduzido por Áurea Weissenberg.
84
DEFENSE AQUISITION UNIVERSITY Quality Management Roadmap, 2005. Disponível
em: <https://acc.dau.mil/CommunityBrowser.aspx?id=23254&lang=en-US> .Acesso em: 06
abr. 2008
DEPARTMENT OF DEFENSE. DEFENSE ACQUISITION GUIDEBOOK: Quality
Estados Unidos da América, 2004. cap. 4.4.7. Disponível em:
< https://akss.dau.mil/dag/GuideBook/IG_c4.4.7.asp>. Acesso em: 26 maio 2009.
DEPARTMENT OF DEFENSE. Systems Management College. Systems engineering
fundamentals. Fort Belvoir, 2001. 222 p. Disponível em:
< http://www.dau.mil/pubs/pdf/SEFGuide%2001-01.pdf>. Acesso em: 23 maio 2009.
DiORIO, L.J. The proven way. Quality Progress, v. 36, n. 9. 2003. Disponível em:
<http:vnweb.hwwilsonweb.com/hww/results/external_link_maincontentframe.jhtml?_DARG
S=/hww/results/results_common.jhtml.42>. Acesso em: 20 out. 2009.
DORE, E. R. et al. Proposta para requisitos operacionais [mensagem pessoal]. Mensagem
recebida por <[email protected]> em 6 nov. 2008.
DORE, E. R. Re: MIP [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 3 abr. 2009.
DURANTE, E. Enviando email: 528-000000A4001 PVQ-VSB30. PLANO VERF
QUALIF ENVIADO 02 06 05doc.doc [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 17 abr. 2009.
ESTEFAN, J. A. Survey of Model-Based Systems Engineering (MBSE) Methodologies
Pasadena: Jet Propulsion Laboratory: California Institute of Technology, 2008. 70 p.
Disponível em: <http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf>.
Acesso em: 26 maio 2009.
FEIGENBAUM, A. V. Total Quality Control. 3 ed. Singapure: McGRAW HILL
INTERNATIONAL EDITIONS. 1988. 851 p.
FELICIO, D. Implantação de um sistema de gestão da qualidade: estudo de caso em uma
organização pública de pesquisa e desenvolvimento. 2008. 137f. Dissertação (mestrado) -
Universidade de Taubaté, 2008.
FERNANDES, J. H. RIPP, Inspeção [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 01 abr. 2009.
85
FORTESCUE, P.W.; STARK, J.P.W.; E SWINERD G.G. Spacecraft systems engineering.
3. ed. Chichester: JOHN WILEY & SONS LTD. 2003. 678 p.
GARVIN, D. Competing on the Eight Dimensions of Quality. Harvard Business Review,
1987, p. 101-109.
GERKES, M. Application of systems engineering in quality assurance. In: FÉDÉRATION
INTERNATIONALE D`INFORMATION ET DE DOCUMENTATION, 48., 1996, Graz.
Proceedings…Aslib Proceedings, 1998. v.50, n.7, p. 141-153.
GREENSPUN, R. J. Introduction to Systems Engineering: A Lauchspace Professional
Training Course. Maryland: Launchspace Training, 2004.
HAUSER, J. R.; KATZ, G. M. Metrics: you are what you measure. [S.I.]: MIT,1998.
Disponível em: <http://web.mit.edu/hauser/www/Papers/Hauser-Katz%20Measure%2004-
98.pdf.> Acesso em: 28 maio 2009. 28 p.
IAQG (Estados Unidos da América) (Org.). Supplier Selection and Capability Assessement
matrices. Disponível em:
<http://www.sae.org/servlets/registration?PORTAL_CODE=IAQG&OBJECT_PKG=iaqg.bu
sinessClasses&OBJECT_TYPE=SCMHGeneral&PAGE=viewFlash>. Acesso em: 02 fev.
2009.
IGRAFX.D. Disponível em: <http://www.igrafx.com/>. Acesso em: 12 set. 2009.
KNOWLEDGE BASED SYSTEMS, INC. University Dr. East College Station. Disponível
em: <http://www.kbsi.com/>. Acesso em: 12 set. 2009.
LOUREIRO, Geilson. A systems engineering and concurrent engineering framework for
the integrated development of complex products. Loughborough:. Departament of
Manufacturing Engineering, Loughborough University, 1999. 530 p. Thesis (Ph.D.).
MARANHÃO, M.; MACIEIRA, M.E.B. O processo nosso de cada dia: modelagem de
processos de trabalho. 1. ed. Rio de Janeiro: QUALITYMARK, 2008. 250 p.
MASON-JONES, R.; BERRY, D.; NAIN, M. M. A systems engineering approach to
manufacturing systems analysis. Integrated Manufacturing Systems. Birmingham
v. 9, n. 6, p. 350-365, 1998. Disponível em:
<http://www.emeraldinsight.com/Insight/viewPDF.jsp?contentType=Article&Filename=html/
Output/Published/EmeraldFullTextArticle/Pdf/0680090603.pdf>. Acesso em: 20 maio 2009.
86
MICROSOFT OFFICE ONLINE. ® 2009 Microsoft Corporation. Disponível em:
<http://office.microsoft.com/pt-br/visio/FX100487861046.aspx>. Acesso em: 12 set. 2009.
MUTAFELIJA, B.; STROMBERG, H. ISO 9001:2000 and CMMI synergy.
In: ____Systematic process improvement using ISO 9001:2000 and CMMI. 1. ed.
Norwood: Artech House Publishers, 2003.cap. 5.
NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. NASA: Systems
engineering handbook . Washington D.C, 2007. 360 p. Disponível em:
<http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-
6105%20Rev%201%20Final%2031Dec2007.pdf>. Acesso em: 23 maio 2009.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Integration definition
for function modeling (IDEF0). Gaithersburg: Federal Information Processing Standards
Publication, 1993. 128 p. Disponível em: <http://www.idef.com/pdf/idef0.pdf>. Acesso em:
28 maio 2008.
NIWA, M.; MUNARETTO, L. A. C. Conformity assessment in the brazilian space program:
a necessary discussion. In: INTERNATIONAL CONGRESS OF MECHANICAL
ENGINEERING, 19., 2007, Brasilia. Proceedings…Brasília: ABCM, 2007. p. 1-8.
PALMÉRIO, A. F. et al. The development of the VSB-30 sounding rocket vehicle. In: ESA
SYMPOSIUM ON EUROPEAN ROCKET AND BALLOON PROGRAMMES AND
RELATED RESEARCH, 16., 2003, St. Gallen. Proceedings… St. Gallen: ESA SP-530,
2003. p. 137-140.
PALMÉRIO, A. F. et al. Results from the first flight of the VSB-30 sounding rocket. In: ESA
SYMPOSIUM ON EUROPEAN ROCKET AND BALLOON PROGRAMMES AND
RELATED RESEARCH, 17., 2005, Sandefjord. Proceedings… Sandefjord.: ESA SP-590,
2005. p. 345-349.
PALMÉRIO, A. F. Engenharia de sistemas [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 28 ago. 2009.
PHILLIPS, M. et al. CMMI for development. Pittsburgh, 2006. 1.2 v. 573 p. Disponível em:
<http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html>. Acesso em: 27
maio 2009.
PINHEIRO, A. Mestrado Fernando IFI [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 22 set. 2009.
87
SILVA, E. L.; MENEZES, E. M. Metodologia da pesquisa e elaboração de dissertação. 4.
ed. Florianópolis: UFSC, 2005. 138 p.
SPINA, F. D. Dissertação material [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 23 jun. 2009.
STEVENS, R. et al. Systems engineering: coping with complexity. 5. ed. London:
PRENTICE HALL, 1998. 374 p.
THOMPSON, D. Systems Engineering Applied To Total Quality Management. The
Institution of Electrical Engineers. Londres, 1999. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=771499&isnumber=16718>.
Acesso em: 21 out. 2009.
U.S. AIR FORCE. Space & Missile Systems Center. SMC systems engineering primer &
handbook: concepts, processes, and techniques. Estados Unidos da América, 2005. 351 p.
3. ed. Disponível em: < http://www.sei.cmu.edu/programs/acquisition-
support/publications/afprimer.pdf>. Acesso em: 23 maio 2009.
VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. 1. ed. São
Paulo: MAKRON BOOKS, 2001. 295 p.
WATSON, G. H. Gurus of quality: Feigenbaum‟s enduring influence. QUALITY
PROGRESS, Stillwater, v. 38, n. 11, pp. 51-55, nov. 2005. Disponível em:
<http://vnweb.hwwilsonweb.com/hww/results/esternal_link_maincontentframe.jhtml?_DAR
GS=/hww/results_common.jhtml.30>. Acesso em: 15 mai. 2009.
WIENDL, V. Modelagem dos Processos do Ciclo de Vida de Produtos Complexos pelos
Métodos IDEF3 e IDEFØ. São José dos Campos: Dissertação de mestrado – Instituto
Tecnológico de Aeronáutica, 2009. 138p. Disponível em: <[email protected]>.
Acesso em: 26 fev. 2009.
88
APÊNDICE A - Diagramas IDEF0 das áreas de processos de Verificação, Integração e
Validação
Figura A1- Diagrama A0 de verificação de componentes.
A Figura A2 é o desdobramento da primeira em 3 principais atividades de verificação, que
são a verificação dimensional, a verificação de componentes eletrônicos embarcados e a
verificação de pirotécnicos.
A verificação dimensional é a que possui mais controles e mecanismos para transformação da
atividade; a verificação de componentes eletrônicos está baseada em uma proposta de
adequação a normas da agência espacial européia (ESA), e a verificação de pirotecnia está
fundamentada na adoção de ensaios não destrutivos, ambientais e funcionais estabelecidos em
normas como segurança de explosivos; requisitos de segurança para subsistemas eletro-
explosivos e métodos de ensaios para sistemas espaciais; critérios para sistemas explosivos e
dispositivos usados em veículos espaciais; métodos de ensaios ambientais e diretrizes de
engenharia; critérios de projeto de veículos da NASA – ignitores de motores de foguete
sólidos.
89
Figura A2 - Desdobramento do Diagrama A0 de verificação dos componentes.
Figura A3 - Desdobramento do subprocesso de verificar pirotécnicos.
90
Figura A4 - Diagrama A0 de integração de sistemas e subsistemas.
Este processo é então desdobrado em três subprocessos: testar rede elétrica, montar o primeiro
estágio e montar o segundo estágio, conforme demonstrado na Figura A5. Observa-se, por
exemplo, nesta figura que o controle “restrições” é desdobrado no controle “temperatura,
umidade, tempo e massa” para o subprocesso “montar primeiro estágio”.
Figura A5 - Desdobramento do Diagrama A0 de integração.
91
Figura A6 - Desdobramento do processo de testar rede elétrica
A Figura A7 é um desdobramento da Figura A5, apresentando seis subprocessos do
subprocesso “montar primeiro estágio”. Vê-se que para os subprocessos “integrar ignitor do
primeiro estágio”, “montar SAD no ignitor”, “montar iniciador no ignitor” e “armar o motor”,
todas as entradas, controles, mecanismos e saídas são desdobradas, a não ser para os
subprocessos “montar motor S31 e empenas”, e “montar módulo dianteiro”, que serão
desdobrados respectivamente conforme Figuras A8 e A9.
92
Figura A7 - Desdobramento do processo de montar o 1º estágio.
Figura A8 - Desdobramento do subprocesso de montar motor S31 e empenas.
93
Figura A9 - Desdobramento do subprocesso de montar módulo dianteiro
A Figura A10 segue o mesmo modelo da Figura A7, mas refere-se a seis subprocessos do
subprocesso “montar segundo estágio” da Figura A5. Vê-se que para os subprocessos
“integrar ignitor do segundo estágio”, “montar SAD no ignitor”, “montar iniciador no ignitor”
e “armar o motor”; todas as entradas, controles, mecanismos e saídas são desdobradas, a não
ser para os subprocessos “montar motor S30 e empenas”, e “montar motor adaptor”, que serão
desdobrados respectivamente conforme Figuras A11 e A12.
94
Figura A10 - Desdobramento do processo de montar o 2º estágio.
Figura A11- Desdobramento do subprocesso de montar motor S30 e empenas
95
Figura A12 - Desdobramento do subprocesso de montar motor adaptor
Figura A13 - Diagrama A0 de validação
96
A Figura A14 mostra o desdobramento do processo anterior em seus subprocessos, onde o
subprocesso “validar estrutura” contém as mesmas entradas, saídas e controles, porém os
mecanismos utilizados são somente recursos de análises, ensaios e inspeções.
Para o subprocesso “validar propulsão”, as entradas e saídas são as mesmas do subprocesso
anterior, mas os mecanismos são todos os considerados no processo inicial e os controles
somente especificações técnicas e desenhos.
Portanto, não necessariamente as mesmas entradas, saídas, controles ou mecanismos
ocorrerão para todos os subprocessos; somente os necessários para atender a suas atividades.
Observam-se todos os subprocessos para “validar VSB”: “validar estrutura”, “validar
propulsão”, “validar suprimento de energia”, “validar instrumentos e sequenciamento de
eventos” e “validar ignição dos propulsores”.
Figura A14 - Desdobramento do diagrama A0 de validação
A Figura A15 desdobra o subprocesso “validar estrutura” da Figura A14 nos subprocessos
“validar funções”, “validar descrições”, “validar desempenho”, “validar interfaces”, “validar
operacional” e “validar projeto e fabricação”. O controle “normas técnicas” é desdobrado em
“regras para concepção, projeto e fabricação do foguete”, “condições ambientais” e
97
“especificação do foguete aplicado” ao subprocesso “validar interfaces”. Para o subprocesso
“validar desempenho”, os componentes são desdobrados em “resistência estrutural” e
“parâmetros de desempenho”.
Figura A15 - Desdobramento do subprocesso de validação de estrutura
Figura A16 - Desdobramento do subprocesso de validação de descrições estruturais
98
Figura A17 - Desdobramento do subprocesso de validação interfaces estruturais
Figura A18 - Desdobramento do subprocesso de validação subsistemas e integração
99
Figura A19 - Desdobramento do subprocesso de validação de propulsão
Figura A20 - Desdobramento do subprocesso de validação da descrição de propulsão
100
Figura A21- Desdobramento do subprocesso de validação da funcionalidade de propulsão
Figura A22 - Desdobramento do subprocesso de validação da mecânica de propulsão
101
Figura A23 - Desdobramento do subprocesso de validação de suprimento de energia
Figura A24 - Desdobramento do subprocesso de validação do desempenho de suprimento de
energia
102
Figura A25 - Desdobramento do subprocesso de validação da instrumentação e seqüenciamento
de eventos
Figura A26 - Desdobramento do subprocesso de validação da ignição dos propulsores
103
ANEXO A - Áreas dos processos de engenharia do CMMI
A.1 Área de processo de Desenvolvimento de Requisitos
Estes requisitos em conjunto enfocam as necessidades relevantes dos stakeholders, incluindo
aquelas de fase do ciclo de vida do produto pertinentes (critérios de aceitação de ensaios, por
exemplo) e atributos do produto (segurança, confiabilidade e manutenabilidade). Enfocam
também nas restrições causadas pelas seleções das soluções de projetos (integração de
produtos padronizados). O desenvolvimento de requisitos inclui as seguintes atividades:
• obtenção, análise, validação e comunicação das necessidades do cliente, antecipações
e restrições para obter os requisitos dos clientes que constituem um entendimento do
que satisfará os stakeholders;
• coleção e coordenação das necessidades dos stakeholders;
• desenvolvimento dos requisitos de ciclo de vida do produto;
• estabelecimento dos requisitos dos clientes;
• estabelecimento dos requisitos iniciais dos produtos e componentes consistentes com
os requisitos do cliente (PHILLIPS et al., 2006).
Esta área de processo enfoca todos os requisitos do cliente mais que os requisitos do produto
porque o cliente fornece requisitos específicos de projeto. Posteriormente os requisitos são
refinados em requisitos do produto e componentes. Em adição aos requisitos dos clientes, os
requisitos dos produtos e componentes são derivados de soluções selecionadas de projetos.
(PHILLIPS et al., 2006).
A.1.1 Desenvolver os requisitos do cliente (SG 1)
As necessidades, expectativas, restrições, interfaces, concepção operacional e de produto dos
stakeholders (e.g., clientes, usuários finais, fornecedores, montadores, verificadores,
fabricantes, e pessoal de logística) são coletadas e traduzidas em requisitos de cliente, além de
serem analisadas, harmonizadas, refinadas e elaboradas para compor um grupo de requisitos
dos clientes (PHILLIPS et al., 2006).
104
A.1.1.1 Obter as necessidades (SP 1.1)
Esta prática consiste em obter as necessidades, expectativas, restrições e interfaces dos
stakeholders para todas as fases do ciclo de vida do produto. A obtenção vai além da coleta de
requisitos; utiliza-se da identificação proativa de requisitos adicionais não fornecidos
explicitamente pelos clientes. Exemplos de técnicas de obtenção de requisitos: análise
preliminar de projetos; protótipos e modelos; QFD; extração de fontes como documentos,
normas e especificações; observações de produtos existentes (PHILLIPS et al., 2006).
Exemplos de fontes de requisitos podem não ser identificados pelo cliente como normas e
requisitos ambientais de negócios (e.g., laboratórios, ensaios e outras plantas, infra-estrutura
da tecnologia da informação) (PHILLIPS et al., 2006).
A.1.1.2 Desenvolver os requisitos do cliente (SP 1.2)
As entradas dos stakeholders relevantes devem ser consolidadas, informações pendentes
devem ser obtidas e conflitos devem ser resolvidos em documentação que reconheça a série
de requisitos de cliente. Os requisitos de cliente podem incluir necessidades, expectativas e
restrições com relação à verificação e validação (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: requisitos de cliente; restrições de cliente em conduzir
verificações e restrições de cliente em conduzir validações. (PHILLIPS et al., 2006).
As subpráticas consistem em traduzir as necessidades, expectativas, restrições e interfaces em
requisitos de cliente documentados e definir as restrições para verificação e validação
(PHILLIPS et al., 2006).
A.1.2 Desenvolver os requisitos do produto (SG 2)
Os requisitos do cliente são refinados e elaborados para desenvolver os requisitos de produto
e componentes do produto. Os requisitos do cliente são analisados em conjunto com o
105
desenvolvimento conceitual de operação para derivar uma série de requisitos detalhados e
precisos, denominados requisitos do produto e componentes (PHILLIPS et al., 2006).
Os requisitos do produto e componentes endereçam uma necessidade associada com cada
produto na fase de ciclo de vida. Os requisitos derivados crescem de restrições, considerações
de questões implícitas, mas não explicitamente declaradas na base de requisitos do cliente, e
fatores introduzidos pela arquitetura, projeto, considerações de negócio impar dos
desenvolvedores. Os requisitos são re-examinados com cada serie de requisitos e arquitetura
funcional e a níveis hierárquicos mais baixos; e a concepção do produto requerido é refinada.
Os requisitos são alocados a funções do produto e componentes, incluindo objetos, pessoas e
processos. A rastreabilidade de requisitos para funções, objetos, ensaios, problemas e outras
entidades são documentadas. Os requisitos e funções alocados são a base para a síntese de
soluções técnicas (PHILLIPS et al., 2006).
A.1.2.1 Estabelecer os requisitos do produto e componentes (SP 2.1)
Os requisitos dos clientes podem ser expressos em termos dos clientes e podem ser descrições
não-técnicas. Os requisitos dos produtos são uma expressão destes requisitos em termos
técnicos que podem ser usados para decisões de projeto. Um exemplo desta tradução é
encontrado na casa do QFD, que mapeia os desejos dos clientes em parâmetros técnicos.
Os requisitos do produto e componentes refletem a satisfação do cliente, negócios, objetivos
de projeto e atributos associados tais como eficácia e disponibilidade financeira. Requisitos
derivados também refletem o custo e desempenho de outras fases de ciclo de vida (produção,
operações e disposições) para a extensão compatível com os objetivos de negócio (PHILLIPS
et al., 2006).
Os resultados de trabalhos típicos são: requisitos derivados, requisitos do produto e requisitos
dos componentes (PHILLIPS et al., 2006).
As subpráticas consistem em desenvolver requisitos em termos técnicos necessários para o
projeto do produto e componentes; desenvolver requisitos de arquitetura enfocando
qualidades e desempenho críticos do produto necessário para o projeto da arquitetura do
produto; derivar os requisitos que são resultados de decisões de projeto; estabelecer e manter
106
relações entre requisitos para considerações durante a gestão de mudanças e alocação de
requisitos (PHILLIPS et al., 2006).
A.1.2.2 Alocar os requisitos dos componentes (SP 2.2)
Os requisitos para os componentes incluem a alocação do desempenho do produto, restrições
de projeto, ajuste, forma e função para atender requisitos e facilitar a produção (PHILLIPS et
al., 2006).
Os resultados de trabalhos típicos são: folhas de alocação de requisitos; alocação provisória de
requisitos; restrições de projeto; requisitos derivados; relações entre requisitos derivados
(PHILLIPS et al., 2006).
As subpráticas consistem em alocar os requisitos às funções; alocar os requisitos aos
componentes; alocar os requisitos às restrições de projeto; documentar relações entre
requisitos alocados (PHILLIPS et al., 2006).
A.1.2.3 Identificar os requisitos de interface (SP 2.3)
Interfaces entre funções (ou entre objetos) são identificadas. Interfaces funcionais podem
direcionar o desenvolvimento de soluções alternativas. Requisitos de interface entre produtos
ou componentes identificados na arquitetura do produto estão definidos. Elas são controladas
como parte da integração de produtos e componentes, e é uma parte integral da definição da
arquitetura (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são os requisitos de interface (PHILLIPS et al., 2006).
As subpráticas consistem em: identificar interfaces tanto externa e interna ao produto e
desenvolver os requisitos para identificar interfaces (PHILLIPS et al., 2006).
A.1.3 Analisar e validar os requisitos (SG 3)
107
Os requisitos são analisados e validados e uma definição da funcionalidade dos requisitos é
desenvolvida. Análises são realizadas para determinar qual impacto o ambiente operacional
pretendido terá na habilidade de satisfazer as necessidades, expectativas, restrições e
interfaces dos stakeholders (PHILLIPS et al., 2006).
A.1.3.1 Estabelecer a concepção e cenários operacionais (SP 3.1)
Um cenário é uma seqüência de eventos que podem ocorrer no uso do produto, que é usado
para deixar explícito algumas das necessidades dos clientes. Em contradição, uma concepção
operacional para o produto depende tanto da solução de projeto como de cenário (PHILLIPS
et al., 2006).
Os resultados de trabalhos típicos são: concepção operacional; instalação de produtos e
componentes e concepção operacional, manutenção e apoio; concepção da disposição; casos
utilizados; cronologia do cenário; novos requisitos (PHILLIPS et al., 2006).
As subpráticas consistem em: desenvolver a concepção operacional e de cenários que incluam
funcionalidade, desempenho, manutenção, apoio e disposição conforme apropriado.
Identificar e desenvolver cenários, consistentes com o nível de detalhe das necessidades,
expectativas e restrições dos stakeholders na qual o produto ou componente é esperado
operar; definir o ambiente na qual o produto e componente operarão, incluindo restrições;
rever concepção operacional e de cenários para refinar e descobrir requisitos; desenvolver
uma concepção operacional detalhada, como os produtos e componentes são selecionadas,
que define a interação do produto, o usuário final, ambiente e que satisfaz as necessidades
operacionais, de manutenção, suporte e disposição (PHILLIPS et al., 2006).
A.1.3.2 Estabelecer a definição de funcionalidade requerida (SP 3.2)
A definição da funcionalidade, também chamada de análise funcional, é a descrição do que o
produto irá fazer. Também pode incluir ações, seqüência, entradas, saídas, e outras
108
informações que comunicam a maneira de como o produto será usado (PHILLIPS et al.,
2006).
Os resultados de trabalhos típicos são: arquitetura funcional; diagramas de atividade; análise
orientada ao objeto com serviços ou métodos (PHILLIPS et al., 2006).
As subpráticas consistem em: analisar e quantificar a funcionalidade requerida por usuários
finais; analisar requisitos para identificar divisões lógicas ou funcionais (sub-funções); dividir
requisitos em grupos, baseados em critérios estabelecidos (funcionalidade, desempenho ou
conexão similares), para facilitar e focar a análise de requisitos; considerar a seqüência de
funções críticas inicialmente e durante o desenvolvimento do componente; alocar os
requisitos do cliente a divisões funcionais, objetos, pessoas e elementos de apoio para apoiar a
síntese de soluções; alocar requisitos funcionais e de desempenho para funções e subfunções
(PHILLIPS et al., 2006).
A.1.3.3 Analisar requisitos (SP 3.3)
À luz da concepção operacional e de cenários, os requisitos de certo nível da hierarquia do
produto são analisados para determinar se eles são necessários e suficientes para atenderem os
objetivos de um nível hierárquico superior de tal forma a fornecerem uma base de requisitos
mais detalhada e precisa para os níveis mais baixos. Á medida que os requisitos são definidos,
a relação com níveis mais altos de requisitos e níveis mais altos de funcionalidade devem ser
entendidos (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: relatórios de falhas de requisitos; mudanças de
requisitos propostas para resolver falhas; requisitos-chave; medidas de desempenhos técnicos
(PHILLIPS et al., 2006).
As subpráticas consistem em: analisar as necessidades, expectativas, restrições e interfaces
externas para evitar conflitos e organizar em assuntos relacionados; analisar requisitos para
determinar se eles satisfazem os objetivos hierárquicos mais altos; analisar requisitos para
garantir que eles estejam completos, sejam praticáveis e verificáveis; identificar requisitos-
chave que tenham uma forte influência no custo, cronograma, funcionalidade, risco ou
desempenho; identificar medidas de desempenho que serão rastreados durante as atividades
de desenvolvimento; analisar concepções operacionais e de cenários para refinar as
necessidades dos clientes e descobrir novos requisitos (PHILLIPS et al., 2006).
109
A.1.3.4 Analisar requisitos para obter equilíbrio (SP 3.4)
As necessidades e restrições dos clientes podem expressar custo, cronograma, desempenho,
funcionalidade, componentes re-usáveis, manutenabilidade ou risco (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos é a avaliação de riscos relativos aos requisitos (PHILLIPS
et al., 2006).
As subpráticas consistem em: usar modelos qualificados, simulações e prototipagem para
analisar as necessidades e restrições dos stakeholders; desempenhar uma avaliação de risco
sobre os requisitos e arquitetura funcional; examinar a concepção do ciclo de vida do produto
para os impactos de requisitos sobre riscos (PHILLIPS et al., 2006).
A.1.3.5 Validar os requisitos (SP 3.5)
Organizações mais maduras desempenham esta atividade usando técnicas sofisticadas
ampliando a base de validação como, por exemplo: análises, simulações, prototipagem e
demonstrações (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são os registros e resultados de métodos de análise
(PHILLIPS et al., 2006).
As subpráticas consistem em: analisar os requisitos para determinar o risco que o produto
resultante não desempenhará apropriadamente em seu ambiente de utilização; explorar a
adequação e preenchimento de requisitos por meio do desenvolvimento de representações do
produto (protótipos, simulações, modelos, cenários, etc.) e pela obtenção do retorno dos
stakeholders relevantes; avaliar o projeto à medida que cresce no contexto do ambiente de
validação de requisitos para identificar questões de validação e expor necessidades não
declaradas e requisitos de clientes (PHILLIPS et al., 2006).
A.2 Área de processo de Solução Técnica
110
Esta área de processo é aplicável a qualquer nível da arquitetura do produto e para todos os
produtos, componentes e processos do ciclo de vida relacionados ao produto, e é focada:
• na avaliação e seleção de soluções (algumas vezes referenciada como “abordagem de
projeto”, “concepção de projeto” ou “projeto preliminar”) que satisfazem um grupo
apropriado de requisitos alocados;
• no desenvolvimento de projetos detalhados para soluções selecionadas (detalhado no
contexto de conter todas as informações necessárias para fabricação, codificação ou na
implementação do projeto como produto ou componente);
• na implementação de projetos do produto ou componente (PHILLIPS et al., 2006).
Estas atividades apóiam umas às outras. Algum nível de projeto, às vezes bem detalhado,
pode ser necessário para selecionar soluções. Protótipos ou pilotos podem ser usados como
meios de obter conhecimento suficiente para desenvolver um pacote de dados técnicos ou um
completo grupo de requisitos. O processo de ciclo de vida relacionado ao produto pode incluir
a seleção e adaptação de processos existentes (inclusive processos padronizados) para uso
tanto quanto para desenvolvimento de novos processos. Os processos relacionados com a
Solução Técnica são os requisitos do produto e componentes do processo de
Desenvolvimento de Requisitos (PHILLIPS et al., 2006).
A.2.1 Selecionar soluções para os componentes (SG 1)
Requisitos-chave, problemas de projeto e restrições são estabelecidas para uso na análise de
soluções alternativas. Características de arquitetura que fornecem uma base para melhoria do
produto são consideradas. O uso de itens de prateleira é considerado levando-se em conta
custo, cronograma, desempenho e risco. Um indicador de um bom processo de projeto é
relativo ao projeto que foi escolhido depois de compará-lo e avaliá-lo contra soluções
alternativas. Processos do ciclo de vida relacionados ao produto, como fabricação e entrega,
estão entre as soluções adotadas (PHILLIPS et al., 2006).
A.2.1.1 Desenvolver soluções alternativas e critérios de seleção (SP 1.1)
111
Soluções alternativas precisam ser identificadas e analisadas para permitir a seleção de uma
solução balanceada pelo ciclo de vida do produto em termos de custo, cronograma e
desempenho. Estas soluções estão baseadas nas arquiteturas do produto propostas que
apontam qualidades críticas do produto e amplia um tempo de projeto de soluções exeqüíveis
(PHILLIPS et al., 2006).
Soluções alternativas ampliam o alcance aceitável de custo, cronograma e desempenho. Os
requisitos do produto são recebidos e usados com os problemas, restrições e critérios de
projetos para desenvolver soluções alternativas. Critérios de seleção podem apontar custos
(tempo, pessoas e dinheiro), benefícios (desempenho, capabilidade e eficácia) e riscos
(técnico, custo e cronograma) (PHILLIPS et al., 2006).
Considerações para soluções alternativas e critérios de seleção incluem as seguintes: custo de
desenvolvimento, fabricação, aquisição, manutenção, apoio, etc.; desempenho; complexidade
do produto e processos do ciclo de vida; robustez à operação do produto e condições de
uso, modos de operação, ambientes e variações nos processos do ciclo de vida do produto;
limitações tecnológicas; risco; evolução de requisitos e tecnologia; limitações e capabilidades
de usuários finais e operadores; características dos itens de prateleira (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: relatórios de avaliação de novas tecnologias; soluções
alternativas; critérios de seleção para soluções finais; relatórios de avaliação de itens de
prateleira (PHILLIPS et al., 2006) (PHILLIPS et al., 2006).
As subpráticas consistem em: identificar critérios de separação para selecionar um grupo de
soluções alternativas para consideração; identificar tecnologias correntes em uso e novas
tecnologias de produto para se obter vantagem competitiva; gerar soluções alternativas; obter
uma alocação de requisitos para cada alternativa; desenvolver os critérios para selecionar a
melhor solução alternativa; identificar candidatos a itens de prateleira que satisfazem aos
requisitos (PHILLIPS et al., 2006).
Estes requisitos incluem: funcionalidade, desempenho, qualidade e confiabilidade; termos e
condições de garantia para os produtos; risco; responsabilidade dos fornecedores (PHILLIPS
et al., 2006).
A.2.1.2 Selecionar soluções para os componentes (SP 1.2)
112
Selecionar os componentes do produto que melhor satisfaçam aos critérios estabelecidos para
alocação de requisitos. Requisitos de nível mais baixo são gerados da alternativa selecionada
e usados para projetar o componente do produto. Requisitos de interface entre os
componentes são descritos funcionalmente em um primeiro momento. Descrições de interface
física estão incluídas na documentação para interfaces aos itens e atividades externas ao
produto (PHILLIPS et al., 2006).
A descrição das soluções e justificativas para seleção está documentada. A documentação
evolui por todo desenvolvimento à medida que soluções e projetos detalhados são
desenvolvidos e os projetos estão implementados. Manter um registro de justificativa é critico
para tomada de decisões a níveis inferiores (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: decisões e justificativas para seleção dos componentes;
relações entre requisitos e componentes documentadas; soluções, avaliações e justificativas
documentadas (PHILLIPS et al., 2006).
As subpráticas consistem em (PHILLIPS et al., 2006):
avaliar cada solução alternativa/grupo de soluções contra os critérios de seleção
estabelecidos no contexto da concepção da operação e cenários;
desenvolver cenários de cronograma para operações do produto e interação do usuário
para cada solução alternativa;
baseado na avaliação de alternativas, avaliar a adequação dos critérios de seleção e
atualizá-los se necessário;
identificar e resolver problemas com soluções alternativas e requisitos;
selecionar o melhor grupo de soluções alternativas que satisfaçam aos critérios
selecionados;
estabelecer os requisitos associados como o grupo de alternativas selecionadas como o
grupo de requisitos alocados aos componentes;
identificar as soluções para os componentes que serão reutilizados ou adquiridos;
estabelecer e manter a documentação das soluções, avaliações e justificativas.
A.2.2 Desenvolver o projeto (SG 2)
113
Projetos de produtos ou componentes devem fornecer um conteúdo apropriado não só para
sua implementação, mas também para outras fases do ciclo de vida como modificação,
aquisição, manutenção e apoio logístico. A documentação de projeto fornece uma referência
para apoiar o entendimento do projeto pelos stakeholders e apoiar mudanças de projeto tanto
durante o desenvolvimento quanto nas fases seguintes do ciclo de vida do produto (PHILLIPS
et al., 2006).
Uma descrição completa do projeto é documentada em um pacote de dados técnicos que
incluem uma série de características e parâmetros como forma, ajuste, função, interface,
características do processo de fabricação e outros (PHILLIPS et al., 2006).
A.2.2.1 Projetar o produto ou componente (SP 2.1)
O projeto do produto consiste em duas grandes fases que podem se sobrepor em execução: o
projeto preliminar e o projeto detalhado. O projeto preliminar estabelece as capabilidades e
arquitetura do produto, incluindo partes do produto, identificação dos componentes, as
principais interfaces entre os componentes e interfaces externas. O projeto detalhado define
integralmente a estrutura e capabilidades dos componentes (PHILLIPS et al., 2006).
A definição da arquitetura é dirigida de um grupo de requisitos desenvolvidos durante o
processo de desenvolvimento de requisitos. Estes requisitos expressam os pontos de qualidade
e desempenho que são críticos para o sucesso do produto. A arquitetura define os elementos
estruturais e mecanismos de coordenação que atendem diretamente os requisitos ou apóiam a
obtenção dos requisitos à medida que os detalhes do projeto do produto são estabelecidos.
Arquiteturas podem incluir normas e regras de projeto que regem o desenvolvimento dos
componentes e suas interfaces, bem como diretrizes para ajudar os desenvolvedores do
produto (PHILLIPS et al., 2006).
Exemplos de tarefas para definição da arquitetura incluem:
• estabelecer as relações estruturais das partes e regras sobre as interfaces entre
elementos dentro das partes, e entre as partes;
• identificar principais interfaces internas e todas as interfaces externas;
• definir mecanismos de coordenação (por exemplo, de software e hardware);
• estabelecer as capacidades de infra-estrutura e serviços;
114
• estabelecer regras de projeto e autoridades para tomada de decisão (PHILLIPS et al.,
2006).
Durante o projeto detalhado, os detalhes da arquitetura do produto serão finalizados, os
componentes estão completamente definidos e as interfaces estão completamente
caracterizadas. Os projetos dos componentes podem ser otimizados para certas características
de qualidade e desempenho. Os projetistas podem avaliar o uso de produtos antigos ou itens
de prateleira para os componentes. Assim que o projeto evolui, os requisitos alocados aos
níveis inferiores dos componentes são controlados para garantir que serão atendidos
(PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: arquitetura do produto; projeto dos componentes
(PHILLIPS et al., 2006).
As subpráticas consistem em: estabelecer e manter critérios contra os quais o projeto deve ser
avaliado; identificar, desenvolver ou adquirir métodos de projeto apropriados para o produto
como protótipos e modelos estruturais; garantir que o projeto segue padrões e critérios de
projeto aplicáveis como normas de segurança; restrições de projeto como compatibilidade
eletromagnética e integridade de sinal, limitações de produção e tolerâncias de projeto;
garantir que o projeto segue os requisitos alocados; documentar o projeto (PHILLIPS et al.,
2006).
A.2.2.2 Estabelecer um pacote de dados técnicos (SP 2.2)
Um pacote de dados técnicos fornece uma descrição compreensiva do produto e componente
à medida que é desenvolvido. O projeto é registrado em um pacote de dados técnicos que é
criado durante o projeto preliminar para documentar a definição da arquitetura e é mantido
durante o ciclo de vida do produto para registrar detalhes essenciais do projeto do produto
(PHILLIPS et al., 2006).
Fornece também a descrição do produto ou componente que dá suporte a uma estratégia de
aquisição ou aos processos do ciclo de vida. A descrição inclui a definição da configuração do
projeto requerido e procedimentos para garantir adequação do desempenho do produto ou
componente. Incluem desenhos, listas associadas, especificações, descrições de projeto,
normas, requisitos de desempenho e detalhes de armazenamento, além da descrição de
115
solução de alternativas selecionadas que foram escolhidas para implementação (PHILLIPS et
al., 2006).
Pode incluir as seguintes informações de acordo com o produto ou componente: descrição da
arquitetura do produto; requisitos alocados; descrição dos componentes; descrição dos
processos do ciclo de vida; características-chave do produto; características e restrições físicas
requeridas; requisitos de interface; requisitos de materiais; requisitos de fabricação; os
critérios de verificação usados para garantir que os requisitos foram atendidos (PHILLIPS et
al., 2006).
O resultado de trabalho típico é o pacote de dados técnicos (PHILLIPS et al., 2006).
As subpráticas consistem em: determinar o número de níveis de projeto e documentação;
apoiar descrições detalhadas de projeto sobre os requisitos alocados do componente,
arquitetura e projeto de níveis superiores; documentar o projeto no pacote; documentar a
justificativa para decisões críticas tomadas ou definidas; revisar o pacote quando necessário
(PHILLIPS et al., 2006).
A.2.2.3 Projetar interface utilizando critérios (SP 2.3)
Os critérios para interface freqüentemente refletem parâmetros críticos que devem ser
definidos, ou ao menos serem investigados, para averiguar sua aplicabilidade. Estes
parâmetros são peculiares ao tipo de produto e são associados com segurança, durabilidade e
características críticas de missão (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: especificações de projeto de interface; documentos de
controle de interface; critérios de especificação de interface; justificativa para selecionar o
projeto de interface (PHILLIPS et al., 2006).
As subpráticas consistem em: definir os critérios de interface; identificar interfaces associadas
com outros componentes; identificar interfaces associadas com itens externos; identificar
interfaces entre componentes e os processos do ciclo de vida do produto; aplicar os critérios
para alternativas de projeto de interface; documentar os projetos de interface selecionados e as
justificativas para seleção (PHILLIPS et al., 2006).
116
A.2.2.4 Realizar análises de se fazer, comprar ou reutilizar (SP 2.4)
Esta análise começa no projeto durante a primeira interação de projeto; continua durante o
processo de projeto e completa com a decisão de desenvolver, adquirir ou reutilizar o produto.
Fatores que influenciam esta decisão incluem: funções que o produto fornecerá e como estas
funções se ajustaram ao projeto; disponibilidade de recursos e competências; custos de se
adquirir versus desenvolvimento; datas de entrega e integração críticas; alianças estratégicas
de negócios; pesquisa de mercado de produtos disponíveis, incluindo itens de prateleira;
funcionalidade e qualidade dos produtos disponíveis; competências e capabilidades de
potenciais fornecedores; impacto sobre as competências essenciais; licenças, garantias,
responsabilidades e limitações associadas com os produtos a serem adquiridos;
disponibilidade do produto; questões de propriedade; redução de risco (PHILLIPS et al.,
2006).
Os resultados de trabalhos típicos são: critérios para projetar e reutilizar o componente;
análise make-or-buy; diretrizes para escolher itens de prateleiras para os componentes
(PHILLIPS et al., 2006).
As subpráticas consistem em: desenvolver critérios para reutilizar o projeto de componentes;
analisar projetos para determinar se o produto deveria ser desenvolvido, reutilizado ou
adquirido; analisar implicações de manutenção quando considerar adquirir itens adquiridos
(PHILLIPS et al., 2006).
A.2.3 Implementar o projeto do produto (SG 3)
A implementação inclui ensaios de unidade dos componentes antes de enviá-los à integração
do produto e o desenvolvimento da documentação do usuário final (PHILLIPS et al., 2006).
A.2.3.1 Implementar o projeto (SP 3.1)
117
A implementação no nível superior da hierarquia do produto envolve a especificação de cada
componente no próximo nível da hierarquia do produto. Esta atividade inclui a alocação,
refinamento e verificação de cada componente e também a coordenação entre os vários
esforços de desenvolvimento do componente (PHILLIPS et al., 2006).
Exemplos de características desta implementação incluem: dados são documentados; serviços
são documentados; peças elétricas e mecânicas são fabricadas; processos de fabricação são
colocados em operação; processos são documentados; plantas são construídas; materiais são
produzidos (PHILLIPS et al., 2006).
O resultado de trabalho típico é o projeto implementado (PHILLIPS et al., 2006).
As subpráticas consistem em: usar métodos eficazes para implementar os componentes, como
CAD e métodos de fabricação; atender a normas e critérios aplicáveis, como requisitos de
desenhos, lista de peças padronizadas, peças fabricadas e normas de processos e qualidade;
conduzir análise especializada para selecionar os componentes; desempenhar testes de
componentes conforme apropriado, como ensaios funcionais, teste de inspeção de radiação e
ensaios ambientais; revisar o componente conforme necessário (PHILLIPS et al., 2006).
Exemplos de critérios incluem a confiabilidade, segurança e manutenabilidade
A.2.3.2 Desenvolver a documentação de apoio do produto (SP 3.2)
Esta prática específica desenvolve e mantém a documentação que irá ser utilizada para
instalar, operar e manter o produto (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: materiais de treinamento de usuários; manual de
usuário; manual de operador; manual de manutenção; ajuda online (PHILLIPS et al., 2006).
As subpráticas consistem em: analisar os requisitos, projeto, produto e ensaios para garantir
que os problemas que afetam a documentação de instalação, operação e manutenção estão
identificados e resolvidos; usar métodos eficazes para desenvolver a documentação de
instalação, operação e manutenção; atender a normas de documentação aplicáveis;
desenvolver versões preliminares de documentação de instalação, operação e manutenção em
fases iniciais do ciclo de vida do projeto para ser analisado pelos stakeholders relevantes;
conduzir análises especializadas para documentação de instalação, operação e manutenção;
revisar documentação de instalação, operação e manutenção (PHILLIPS et al., 2006).
118
A.3 Área de processo de verificação
A área de processo de verificação inclui a preparação para verificação, a atividade de
verificação e a identificação de ação corretiva. A verificação inclui também a verificação do
produto e trabalhos intermediários contra os requisitos selecionados, incluindo requisitos de
cliente, produto e componentes do produto. Trata-se de um processo incremental porque
ocorre durante o desenvolvimento do produto, começando com a verificação dos requisitos,
prosseguindo pela verificação dos produtos resultantes e terminando na verificação do
produto completo (PHILLIPS et al., 2006).
As áreas de processo de verificação e validação são similares, mas determinam diferentes
pontos. A validação demonstra que o produto atenderá ao uso requerido, conforme fornecido
ou conforme será fornecido, e por sua vez, a verificação declara se o produto reflete
apropriadamente os requisitos especificados. Em outras palavras, verificação garante que foi
construído corretamente e validação garante que foi construído a coisa certa (PHILLIPS et al.,
2006).
A.3.1 Preparar a verificação (SG 1)
Preparações preliminares são necessárias para garantir que as condições de verificação estão
integradas nos requisitos, projetos, planos de desenvolvimento e cronogramas do produto ou
componente. A verificação inclui a seleção, inspeção, testes, análises e demonstração de
resultados. Os métodos de verificação incluem, mas não estão limitadas a, inspeções, análises
por especialistas, auditorias, acompanhamentos, análises, simulações, testes e demonstrações.
A preparação também envolve a definição de ferramentas de apoio, equipamentos de teste e
software, simulações, protótipos e instalações (PHILLIPS et al., 2006).
A.3.1.1 Selecionar os produtos para verificação (SP 1)
119
Os produtos são selecionados baseados na medida em que eles atendem aos objetivos e
requisitos do projeto, e ao atendimento dos riscos do projeto. Os produtos a serem verificados
incluem aqueles associados à manutenção, treinamento e serviços de apoio. A seleção de
métodos de verificação começa tipicamente com a definição dos requisitos de produto e
componentes para garantir que são verificáveis. A reverificação deveria ser abordada por
métodos de verificação para garantir que o retrabalho realizado sobre os resultados do produto
não causem defeitos não identificados. Os fornecedores deveriam ser envolvidos nesta seleção
para garantir que os métodos de projeto são apropriados para o ambiente dos fornecedores
(PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: listas de produtos selecionados para verificação;
métodos de verificação para cada produto selecionado (PHILLIPS et al., 2006).
As subpráticas consistem em: identificar os produtos para verificação; identificar os requisitos
a serem satisfeitos para cada produto selecionado; identificar métodos de verificação que
estão disponíveis para uso; definir métodos de verificação a serem utilizados para cada
produto selecionado; submeter para integração com o plano de projeto a identificação dos
produtos a serem verificados, os requisitos a serem satisfeitos e os métodos a serem utilizados
(PHILLIPS et al., 2006).
A.3.1.2 Estabelecer o ambiente para verificação (SP 1.2)
Um ambiente deve ser determinado para garantir que a verificação aconteça. O ambiente de
verificação pode ser adquirido, desenvolvido, reusado, modificado ou uma combinação
destes, dependendo das necessidades de projeto (PHILLIPS et al., 2006).
Um tipo de ambiente requerido dependerá dos produtos selecionados para a verificação e dos
métodos utilizados. Uma revisão especializada requer mais do que um pacote de materiais,
revisores e a sala. Um ensaio do produto pode requerer simuladores, geradores de cenários,
ferramentas de redução de dados, controle ambiental e interface com outros sistemas
(PHILLIPS et al., 2006).
O resultado de trabalho típico é o ambiente de verificação (PHILLIPS et al., 2006).
As subpráticas consistem em identificar os requisitos e ambiente de verificação; identificar os
recursos de verificação que estão disponíveis para reutilização e modificação; identificar
120
equipamentos de verificação e ferramentas; adquirir equipamentos de apoio e ambiente tais
como equipamentos de ensaio e software (PHILLIPS et al., 2006).
A.3.1.3 Estabelecer os procedimentos e critérios para verificação (SP 1.3)
Os critérios de verificação estão definidos para garantir que os produtos atendam os requisitos
(PHILLIPS et al., 2006).
Exemplos de fontes para critérios de verificação incluem os seguintes: requisitos do produto e
componentes; normas; políticas da empresa; tipo de ensaio; parâmetros de ensaio; parâmetros
para compensação entre qualidade e custo de ensaio; tipo de produto; fornecedores; propostas
e acordos (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são os procedimentos de verificação e critérios de
verificação (PHILLIPS et al., 2006).
As subpráticas consistem em: gerar um grupo procedimentos de verificação integrada para os
produtos e produtos de prateleira, se necessário; desenvolver e refinar os critérios de
verificação quando necessários; identificar os resultados esperados, quaisquer tolerâncias
permitidas em observação, e outros critérios para satisfazer os requisitos; identificar qualquer
equipamento e componentes ambientais necessários para apoiar a verificação (PHILLIPS et
al., 2006).
A.3.2 Realizar avaliações especializadas (SG 2)
Avaliações especializadas envolvem uma análise metódica dos produtos por especialistas para
identificarem defeitos a serem eliminados e recomendar outras mudanças necessárias. Uma
análise especializada é um método de verificação importante e implementada via inspeções e
outros métodos (PHILLIPS et al., 2006).
Uma análise especializada é primeiramente aplicada para os produtos desenvolvidos pelos
projetos, mas pode ser também aplicada a outros produtos, como documentação e treinamento
que são desenvolvidos tipicamente para grupos de apoio (PHILLIPS et al., 2006).
121
A.3.2.1 Preparar avaliações especializadas (SP 2.1)
Atividade de análise especializada tipicamente inclui a identificação de grupos que serão
convidados a participarem da análise para cada produto; identificar revisores-chave que
deverão participar da análise para cada produto; preparar e recolher qualquer material que será
necessária sua utilização durante as análises, tais como check-lists ou critérios de análise, e
análises de cronogramas (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: cronograma de análise especializada; Checklist de
analise especializada; critérios de entrada e saída para os produtos; critérios para requerer
outra análise especializada; material de treinamento de análise especializada; produtos
selecionados para serem analisados (PHILLIPS et al., 2006).
As subpráticas consistem em: determinar que tipo de análise especializada será conduzida,
como inspeções, ou outras; definir requisitos para coletar dados durante a análise; estabelecer
critérios de entrada e saída de analise especializada; estabelecer e manter critérios para
requerer outra analise especializada; estabelecer e manter listas de verificação para garantir
que os resultados serão analisados consistentemente; desenvolver um cronograma de análise,
incluindo datas para treinamento de análises e para quando o material para análise estará
disponível; garantir que o produto satisfaz os critérios de entrada e saída antes da distribuição;
distribuir o produto a ser analisado e suas informações para os participantes o mais cedo
possível para permitir se preparem adequadamente para a análise; designar funções para
análise especializada conforme apropriado; preparar para análise especializada por meio de
análise de resultados antes de conduzir a análise especializada (PHILLIPS et al., 2006).
A.3.2.2 Conduzir avaliações especializadas (SP 2.2)
Um dos propósitos de conduzir análise especializada é detectar e remover defeitos
antecipadamente. Análises especializadas são desempenhadas à medida que os resultados
estão sendo desenvolvidos e são estruturadas e não são uma análise de gestão (PHILLIPS et
al., 2006).
Análises especializadas podem ser desempenhadas em resultados-chave de especificações,
projeto, ensaio e atividades de implementação. O foco deveria ser sobre o resultado do
122
produto em análise e não na pessoa que o produziu. Quando problemas surgem durante as
análises, eles devem ser comunicados ao desenvolvedor do resultado para correção
(PHILLIPS et al., 2006).
Análises especializadas deveriam abranger as seguintes diretrizes: devem estar
suficientemente preparadas, a condução deve ser gerenciada e controlada, dados suficientes e
consistentes devem ser registrados (um exemplo é a condução de uma inspeção formal) e
itens de ação devem ser registrados (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são resultados de análises especializadas; problemas de
análises especializadas; dados de análises especializadas (PHILLIPS et al., 2006).
As subpráticas consistem em: desempenhar as funções designadas na análise; identificar e
documentar os defeitos e outros problemas dos resultados; registrar os resultados das análises,
incluindo itens de ação; coletar dados de análises; identificar itens de ação e comunicar os
problemas relevantes aos stakeholders; conduzir uma análise adicional se o critério definido
indicar tal necessidade; garantir que os critérios de saída para análise é satisfeita (PHILLIPS
et al., 2006).
A.3.2.3 Analisar dados das avaliações especializadas (SP 2.3)
Analisar dados sobre preparação, condução e resultados de análises.
Os resultados de trabalhos típicos são os dados de análises; itens de ação de análises
(PHILLIPS et al., 2006).
As subpráticas consistem em registrar dados para preparação, condução e resultados das
análises; armazenar os dados para referência e análise futuras; proteger os dados para garantir
que os dados de análise não serão usados desapropriadamente; analisar os dados de análise.
Dados típicos são: nome do produto, dimensão do produto, composição da equipe de análise,
tipo de análise, tempo de preparação por analista, tempo da reunião de análise, número de
defeitos encontrados, tipo e origem do defeito encontrado e assim por diante. Informações
adicionais devem ser coletadas como dimensão, fase de desenvolvimento, modos de operação
examinados e requisitos sendo avaliados.
Exemplos de dados de análise que podem ser analisados incluem os seguintes: tempo ou taxa
de preparação versus tempo ou taxa esperado; número de defeitos versus números esperados;
123
tipos de defeitos detectados; causas dos defeitos; impacto da resolução do defeito (PHILLIPS
et al., 2006).
A.3.3 Verificar os produtos selecionados (SG 3)
Os métodos de verificação, procedimentos e critérios são usados para verificar os produtos
usando o ambiente apropriado. Atividades de verificação deveriam ser realizadas durante o
ciclo de vida do produto (PHILLIPS et al., 2006).
A.3.3.1 Realizar Verificação (SP 3.1)
Os resultados de trabalhos típicos são: resultados de verificação; relatórios de verificação;
demonstrações (PHILLIPS et al., 2006).
As subpráticas consistem em: realizar a verificação contra seus requisitos; registrar os
resultados das atividades de verificação; identificar itens de ação resultantes da verificação;
documentar o método e procedimento correntes de verificação e desvios descobertos durante
a sua realização (PHILLIPS et al., 2006).
A.3.3.2 Analisar os resultados de verificação (SP 3.2)
Resultados atuais devem ser comparados com os critérios de verificação estabelecidos para
determinar sua aceitação. Os resultados das análises são registrados como evidência de que a
verificação foi realizada (PHILLIPS et al., 2006).
Para cada resultado, todos os resultados de verificação disponíveis são analisados
adicionalmente para garantir que os requisitos foram atendidos (PHILLIPS et al., 2006).
124
Os resultados de trabalhos típicos são: relatórios de análise (estatísticas de desempenho,
análise de causa de não conformidades, etc.); relatórios de desvios; pedidos de mudança de
métodos, critérios e ambiente de verificação (PHILLIPS et al., 2006).
As subpráticas consistem em: comparar resultados atuais de esperados; identificar produtos
que não atendem aos requisitos ou identificar problemas de ambientes de métodos,
procedimentos, critérios e verificação; analisar os dados de verificação sobre defeitos;
registrar todos os resultados das análises em um relatório; usar os resultados de verificação
para comparar as medições e desempenho atuais com parâmetros técnicos de desempenho;
fornecer informações sobre como os defeitos podem ser resolvidos (incluindo métodos,
critérios e ambiente de verificação) e atuar com ações corretivas (PHILLIPS et al., 2006).
A.4 Área de processo de Integração de Produtos
Esta área de processo corresponde à integração de componentes do produto em componentes
do produto mais complexo ou completo. O escopo deste processo é obter a integração
completa do produto por meio da montagem progressiva de componentes do produto, em um
estágio ou estágios complementares, de acordo com seqüência e procedimentos definidos de
integração. Um aspecto crítico da integração de produto é o gerenciamento das interfaces
interna e externa dos produtos e componentes para garantir a compatibilidade entre as
interfaces (PHILLIPS et al., 2006).
A.4.1 Preparar para a Integração do Produto (SG1)
A preparação para integração dos componentes do produto envolve o estabelecimento e
manutenção de uma seqüência de integração, o ambiente para desempenhar a integração e
procedimentos de integração (PHILLIPS et al., 2006).
A.4.1.1 Determinar a seqüência de integração (SP 1.1)
125
Os componentes dos produtos que são integrados podem incluir aqueles que são parte do
produto para ser entregue juntamente com equipamentos de testes, software de testes ou
outros itens tais como instrumentos. Uma vez analisados testes alternativos e seqüências de
montagem da integração, seleciona-se a melhor seqüência. A seqüência pode fornecer
montagem incremental e avaliações de componentes que fornecem referências livres de
problemas para incorporação de outros componentes assim que se tornam disponíveis, ou
protótipos de componentes de alto risco. A seqüência deve ser harmonizada com a seleção de
soluções e projeto do produto e componentes na área de Soluções técnicas (PHILLIPS et al.,
2006).
Resultados típicos são: a seqüência da integração do produto; justificativa para selecionar ou
rejeitar a seqüência de integração (PHILLIPS et al., 2006).
Subpráticas consistem em: identificar os componentes a serem integrados; identificar as
verificações a serem desempenhadas durante a integração dos componentes; identificar
seqüências alternativas da seqüência de integração de componentes; selecionar a melhor
seqüência de integração; revisar periodicamente a seqüência conforme necessário; registrar a
justificativa para as decisões feitas e deferidas (PHILLIPS et al., 2006).
A.4.1.2 Estabelecer o ambiente para a integração do produto (SP 1.2)
O ambiente para integração do produto pode ser tanto adquirido como desenvolvido. Os
requisitos de aquisição ou desenvolvimento do equipamento, software ou outros recursos
deverão ser desenvolvidos. Estes requisitos são coletados quando implementar o processo
associado com o Desenvolvimento de requisitos. Pode-se incluir o reuso de recursos da
organização. A decisão de adquirir ou desenvolver está associado com a área de Soluções
Técnicas. O ambiente requerido para cada passo da integração do produto pode incluir
equipamentos de ensaio, simuladores (ocupando o lugar de componentes não disponíveis),
partes de equipamentos reais e dispositivos de registro (PHILLIPS et al., 2006).
Resultados típicos são: ambiente para integração do produto verificado; documentação de
apoio para o ambiente de integração do produto (PHILLIPS et al., 2006).
Subpráticas consistem em: identificar os requisitos para o ambiente de integração do produto;
identificar critérios e procedimentos para o ambiente de integração do produto; decidir se faz
ou compra o ambiente de integração de produto necessário; verificar com a área de processo
126
de fornecedores para maiores informações sobre a aquisição de peças para o ambiente de
integração; desenvolver o ambiente de integração se um ambiente adequado não puder ser
adquirido; manter o ambiente de integração por todo o projeto; dispor das partes do ambiente
que não são de uso a longo prazo (PHILLIPS et al., 2006).
Para projetos complexos, o ambiente de integração pode ser um desenvolvimento principal.
Como tal, deveria envolver planejamento do projeto, desenvolvimento de requisitos, soluções
técnicas, verificação, validação e gerenciamento de riscos (PHILLIPS et al., 2006).
A.4.1.3 Estabelecer procedimentos e critérios para integração do produto (SP 1.3)
Procedimentos para integração dos componentes podem incluir números de interações
incrementais a serem desenvolvidas e detalhes dos testes esperados, e outras avaliações a
serem realizadas em cada estágio. Critérios podem incluir a disponibilidade de um
componente para integração ou sua aceitabilidade (PHILLIPS et al., 2006).
Procedimentos e critérios para integração do produto apontam: nível de ensaio para
construção de componentes; verificação de interfaces; desvio mínimo de desempenho;
requisitos derivados para montagem e interfaces externas; substituição de componentes
permitida; parâmetros de ambiente de ensaio; limites dos custos de ensaios; alternativas de
qualidade/custos para operações de integração; probabilidade de funcionamento adequado;
taxa de entrega e sua variação; lead time do pedido à entrega; disponibilidade de pessoal;
disponibilidade de instalação, linha, ambiente (PHILLIPS et al., 2006).
Os critérios podem ser definidos em como os componentes estão para serem verificados e as
funções para que são esperadas ter. Podem ser definidos para como os componentes montados
e produto integrado para serem validados e entregues. Podem também restringir o grau de
simulação permitido para um componente passar no teste ou ser restringido o ambiente a ser
usado no teste de integração. Partes pertinentes do cronograma e critérios para a montagem
deveriam ser compartilhadas com os fornecedores de produtos para reduzir a ocorrência de
atrasos e falhas de componentes (PHILLIPS et al., 2006).
Resultados típicos são: procedimentos de integração de produto; critérios de integração de
produto (PHILLIPS et al., 2006).
Subpráticas consistem em: estabelecer e manter procedimentos de integração do produto para
os componentes; estabelecer e manter critérios para integração e avaliação de componentes;
127
estabelecer e manter critérios para validação e entrega de produto integrado (PHILLIPS et al.,
2006).
A.4.2 Garantir a compatibilidade da interface (SG 2)
Muitos problemas de integração do produto crescem de aspectos desconhecidos ou não
controlados de interfaces internas e externas. Um gerenciamento efetivo de requisitos,
especificações e desenhos de interface de componentes ajudam a garantir que as interfaces
implementadas sejam completadas e compatíveis (PHILLIPS et al., 2006).
A.4.2.1 Rever as descrições de interface para integridade (SP 2.1)
As interfaces deveriam incluir todas as interfaces com o ambiente de integração do produto,
em adição às interfaces de componentes (PHILLIPS et al., 2006).
Resultados típicos são: categorias de interfaces; lista de interfaces por categoria; mapeamento
das interfaces dos componentes e ambiente de integração do produto (PHILLIPS et al., 2006).
Subpráticas consistem em rever os dados de interface para integridade e garantia completa da
cobertura de todas as interfaces; garantir que os componentes e interfaces são identificados
para garantir conexões fáceis e corretas para integração do produto (PHILLIPS et al., 2006).
Considerar todos os componentes e preparar uma tabela de relacionamentos. Interfaces são
classificadas por 3 classes principais: ambiental, física e funcional. Categorias típicas para
estas classes incluem: mecânica, fluído, elétrica, climática, eletromagnética, térmica,
mensagem e interface humana ou homem-máquina.
Exemplos:
• Interfaces mecânicas (peso e dimensão, centro de gravidade, folga de peças em
operação, espaço requerido para manutenção, conexões rígidas, conexões flexíveis, choques e
vibrações recebidas de estruturas de mancais/rolamentos);
• Interfaces de interferências (ruídos transmitidos por estruturas, pelo ar e
acústicas);
• Interfaces climáticas (temperatura, umidade, pressão e salinidade);
128
• Interfaces térmicas (dissipação de calor, transmissão de calor para a estrutura
de rolamento e características de ar condicionado);
• Interfaces de fluidos (ar condicionado, ar comprimido, nitrogênio, combustível,
óleo lubrificante e saída de gás);
• Interfaces elétricas (consumo de energia fornecida por redes com valores de
pico e transientes, controle de sinal não sensitivo para fornecimento de energia e
comunicação, sinal sensitivo – conexões analógicas, sinais de distúrbio – micro-ondas,
etc.)
• Interfaces eletromagnéticas (campo magnético, conexões de rádio e radar,
conexões de banda óptica, guias de ondas, fibras ópticas e coaxiais)
• Interface homem-máquina (síntese de voz ou áudio, reconhecimento de voz ou
áudio, display, monitor de televisão, ou display de cristal líquido, controles manuais,
etc.)
• Interface de mensagens (origem, destino, estímulo, protocolos e características
de dados)
As descrições de interface dos componentes deveriam ser revisadas com os stakeholders para
evitar interpretações erradas, reduzir atrasos, e prevenir que o desenvolvimento de interfaces
não funcione apropriadamente (PHILLIPS et al., 2006).
A.4.2.2 Gerenciar as interfaces (SP 2.2)
Gerenciar as definições de interfaces internas e externas, e mudanças para os produtos e seus
componentes, incluindo-se manutenção, consistência das interfaces por toda vida do produto e
solução de conflitos, não atendimento e lançamento de mudanças (PHILLIPS ET AL., 2006).
Resultados típicos são: tabela de relações entre os componentes e ambiente externo (fonte
principal de energia, etc.); tabela de relações entre os diferentes componentes; lista de
interfaces acordadas para cada par de componentes, quando aplicável; relatórios do controle
de interface em reuniões de grupo de trabalhos; ações para atualização de interfaces;
programa de aplicação de interfaces; descrição e concordância da interface atualizada
(PHILLIPS et al., 2006).
Subpráticas consistem em: garantir a compatibilidade das interfaces durante o ciclo de vida do
produto; resolver questões de conflito, não-atendimento e mudanças; manter o
129
armazenamento comum para acessibilidade dos dados de interface às equipes de projeto
(PHILLIPS et al., 2006).
A.4.3 Montar o produto e entregá-lo (SG 3)
Os componentes do produto verificados são montados e o produto integrado, verificado e
validado é entregue. A integração de componentes do produto procede de acordo com a
seqüência da integração do produto e procedimentos disponíveis. Antes da integração, cada
componente deveria ser confirmado para estar em acordo com os requisitos de interface. Se
problemas forem detectados durante a integração, eles deverão ser identificados, os problemas
documentados e um processo de ação corretiva devem ser iniciados. O envolvimento das
pessoas contribui para a integração bem sucedida (PHILLIPS et al., 2006).
A.4.3.1 Confirmar a disponibilidade dos componentes para integração (SP 3.1)
Confirmar, antes da montagem, que cada componente requerido para montar o produto foi
apropriadamente identificado, as funções estão de acordo com suas descrições, e que cada
interface atenda as descrições de interface. Cada componente é checado em quantidade, danos
observáveis e interfaces (PHILLIPS et al., 2006).
Resultados típicos são: documentos de aceitação do componente recebido; registros de
entrega; listas de embalagem verificadas; relatórios de exceções; desvios (PHILLIPS et al.,
2006).
Subpráticas consistem em: rastrear o status de todos os componentes tão cedo quanto possível
para torná-lo disponível para integração; garantir que os componentes são entregues para
integração do produto em acordo com a seqüência e procedimentos; confirmar o recebimento
de cada componente identificado; garantir que cada componente atenda suas descrições;
verificar o status da configuração recebida contra a configuração esperada; desempenhar uma
pré-avaliação (inspeção) de todas as interfaces físicas antes de integrar (PHILLIPS et al.,
2006).
130
A.4.3.2 Montar os componentes (SP 3.2)
Resultados típicos é o produto montado (PHILLIPS et al., 2006).
Subpráticas consistem em garantir a disponibilidade do produto no ambiente de integração;
garantir que a seqüência de montagem é desempenhada apropriadamente; registrar
informações apropriadas (status da configuração, número de série dos produtos, tipos e dados
de calibração); revisar a seqüência e procedimentos de integração conforme apropriado
(PHILLIPS et al., 2006).
A.4.3.3 Avaliar os componentes montados (SP 3.3)
Resultados típicos são: relatórios de exceção; relatórios de avaliação de interface; relatórios
de integração do produto (PHILLIPS et al., 2006).
Subpráticas consistem em: conduzir uma avaliação da montagem dos componentes seguindo a
seqüência de integração do produto e procedimentos de avaliação; registrar os resultados
avaliados.
A.4.3.4 Embalar e entregar o produto (SP 3.4)
Os requisitos de embalagem para alguns produtos podem ser inseridos em seus critérios de
especificações e verificações. Isto é especialmente importante quando os itens são
armazenados e transportados pelo cliente. Nestes casos deverá haver um espectro de
condições ambientais e de condições extremas específico para a embalagem. Em outras
circunstâncias fatores como os seguintes podem ser importantes: economia e facilidade de
transporte (ex: conteirners); contabilização; facilidade e segurança da desembalagem
(PHILLIPS et al., 2006).
Resultados típicos são: componentes ou produtos protegidos; documentação de entrega
(PHILLIPS et al., 2006).
131
Subpráticas consistem em: analisar requisitos, projeto, produto, resultados de verificação e
documentação para garantir que os problemas que afetam a embalagem e entrega do produto
sejam identificadas e solucionadas; usar métodos efetivos de embalagem e entrega para a
montagem do produto; satisfazer aos requisitos e normas para embalagem e entrega do
produto; preparar o site operacional para instalação do produto; entregar o produto e
documentação e confirmar recebimento; instalar o produto no site e confirmar a operação.
Instalação do produto pode ser responsabilidade do cliente e usuários. Em alguns casos pouco
pode ser feito para confirmar a operação. Em outros casos, uma verificação final do produto
integrado ocorre no site operacional (PHILLIPS et al., 2006).
A.5 Área de processo de validação
As atividades de validação podem ser aplicadas em todos os aspectos do produto e seus
ambientes, tais como operação, treinamento, fabricação, manutenção e serviços de apoio. Os
requisitos, projetos e protótipos devem ser selecionados com base na satisfação das
necessidades dos usuários e por isso a validação é considerada por todo ciclo de vida do
produto. A validação de que o produto conforme fornecido atenderá completamente o seu uso
intencional, apesar da verificação expressar se o produto atende aos requisitos especificados.
Ou seja, a verificação garante que foi construída corretamente, enquanto a validação que foi
construída a coisa certa. A validação utilize-se de atividades comuns à verificação como
ensaios, análise, inspeções, demonstrações ou simulações. Freqüentemente os usuários finais
e stakeholders estão envolvidos nas atividades de validação; tanto a validação como a
verificação são realizadas simultaneamente e podem utilizar-se de partes do mesmo ambiente.
Sempre que possível a validação deve ser realizada usando o produto e componentes em seus
ambientes pretendidos, podendo considerar o ambiente como um todo ou parcial (PHILLIPS
et al., 2006).
A.5.1 Preparar para validação (SG 1)
132
As atividades de preparação incluem a seleção de produtos e componentes para validação e o
estabelecimento e manutenção do ambiente, procedimentos e critérios de validação. Os itens
selecionados para validação podem incluir somente o produto ou níveis apropriados dos
componentes que são utilizados para construir o produto. O ambiente de validação pode ser
adquirido, especificado, projetado ou construído (PHILLIPS et al., 2006).
A.5.1.1 Selecionar os produtos para validação (SP 1.1)
Os produtos e componentes são selecionados para validação com base na sua relação com as
necessidades dos usuários. Para cada um o escopo da validação (comportamento operacional,
manutenção, treinamento e interface) deve ser determinado. Requisitos de projetos de
produtos e componentes, os produtos e componentes físicos, manuais e processos de
documentação são exemplos do que pode ser validado. Os requisitos e restrições são
determinados para realizar a validação para então selecionar os métodos de validação
baseados na capacidade de demonstrar as necessidades que serão satisfeitas. Demonstrações
de protótipos, funcionais, ensaios de produtos e componentes, e análises como simulações são
exemplos de métodos de validação (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: lista de produtos e componentes selecionados; métodos
de validação para cada produto e componentes; requisitos para realizar a validação para cada
produto ou componentes; restrições de validação para cada produto ou componente
(PHILLIPS et al., 2006).
As subpráticas consistem em: identificar os princípios, características e fases principais da
validação do produto e componentes por toda vida do projeto; determinar quais são as
categorias de necessidades de usuários (operacional, manutenção ou suporte) que serão
validadas; selecionar os produtos e componentes a serem validados; selecionar os métodos de
avaliação para validação do produto e componentes; rever seleção, restrições e métodos com
stakeholders (PHILLIPS et al., 2006).
A.5.1.2 Estabelecer o ambiente para validação (SP 1.2)
133
Os exemplos de tipos de elementos no ambiente de validação podem incluir: ferramentas de
ensaio com interface com o produto sendo validado; componentes ou subsistemas simulados;
sistemas de interface simulada; sistemas de interface real (PHILLIPS et al., 2006).
O resultado de trabalho típico é o ambiente de validação (PHILLIPS et al., 2006).
As subpráticas consistem em: identificar os requisitos ambientais de validação; identificar os
produtos fornecidos pelo cliente; identificar itens reutilizados; identificar equipamentos e
ferramentas de ensaio; identificar recursos; planejar a disponibilidade de recursos
detalhadamente (PHILLIPS et al., 2006).
A.5.1.3 Estabelecer os procedimentos e critérios para validação (SP 1.3)
Os procedimentos e critérios de validação são definidos para garantir que o uso pretendido do
produto será realizado quando estabelecido no ambiente pretendido. Testes ou ensaios de
aceitação e procedimentos podem atender aos procedimentos de validação. Requisitos de
produtos e componentes, normas, critérios de aceitação do cliente são exemplos de fontes para
critérios de validação (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: procedimentos de validação; critérios de validação;
procedimentos de ensaios e avaliações para manutenção, treinamento e apoio (PHILLIPS et
al., 2006).
As subpráticas consistem em: rever os requisitos do produto para garantir que questões que
afetam a validação estão identificadas e solucionadas; documentar o ambiente, cenário
operacional, procedimento, entradas, saídas e critérios para validação; avaliar o projeto à
medida que evolui no ambiente de validação para identificar questões de validação
(PHILLIPS et al., 2006).
A.5.2 Validar o produto e componentes (SG 2)
Métodos, procedimentos e critérios de validação são usados para validar os produtos e
componentes selecionados e qualquer serviço de manutenção, treinamento e suporte
associados usando o ambiente de validação apropriado (PHILLIPS et al., 2006).
134
A.5.2.1 Realizar a validação (SP 2.1)
Os procedimentos de validação devem ser documentados e os desvios que ocorrerem durante
sua execução devem ser registrados conforme apropriado (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: relatórios de validação; resultados de validação; matriz
de referência cruzada para validação; registro de procedimentos de como realizar;
demonstrações operacionais (PHILLIPS et al., 2006).
A.5.2.2 Analisar os resultados da validação (SP 2.2)
Os dados resultantes de ensaios, inspeções, demonstrações ou avaliações são analisados
contra critérios definidos de validação (PHILLIPS et al., 2006).
Os resultados de trabalhos típicos são: relatórios de deficiência; problemas de validação;
pedidos de mudanças de procedimento (PHILLIPS et al., 2006).
As subpráticas consistem em: comparar os resultados atuais com os esperados baseados nos
critérios; identificar produtos e componentes que tiveram problemas; analisar os dados de
validação para falhas; registrar os resultados das analises e identificar os problemas; usar os
resultados da validação para comparar medições e desempenhos atuais para uso pretendido ou
necessidade operacional (PHILLIPS et al., 2006).
A.6 Área de processo de gerenciamento de requisitos
Gerenciar dos produtos e componentes do projeto e identificar inconsistências entre aqueles
requisitos e os planos de projeto e resultados (PHILLIPS et al., 2006).
A.6.1 Gerenciar requisitos (SG 1)
135
O projeto mantém um grupo de requisitos correntes e aprovados durante a vida do projeto
fazendo o seguinte: gerenciando todas as mudanças de requisitos; mantendo as relações entre
os requisitos, os planos de projeto e os resultados de projeto; identificando inconsistências
entre os requisitos, os planos de projeto e os resultados de projeto e tomando ações corretivas
(PHILLIPS et al., 2006)
A.6.1.1 Obter o entendimento dos requisitos (SP 1.1)
Assim que o projeto vai amadurecendo e os requisitos são criados, todas as atividades ou
disciplinas receberão os requisitos. Para evitar requisitos indesejáveis, critérios são
estabelecidos para designar canais apropriados ou fontes oficiais sobre o quais irão receber os
requisitos. As atividades que receberão os requisitos devem conduzir análises dos requisitos
com os requisitos recebidos para garantir compatibilidade, entendimento comum é obtido
sobre o significado dos requisitos (PHILLIPS et al., 2006).
Resultados típicos são: lista de critérios para distinguir fornecedores de requisitos
apropriados; critérios para avaliação e aceitação de requisitos; resultados das análises contra
critérios; um acordo do grupo de requisitos (PHILLIPS et al., 2006)
As subpráticas consistem em: estabelecer critérios para distinguir fornecedores de requisitos
apropriados; estabelecer critérios, objetivos para avaliação e aceitação de requisitos
(PHILLIPS et al., 2006).
A falta de avaliação e aceitação de critérios resulta em uma verificação inadequada, custo de
retrabalho ou rejeição do cliente; analisar requisitos para garantir que os critérios
estabelecidos são atendidos; alcançar o entendimento dos requisitos de tal forma a haver
comprometimento (PHILLIPS et al., 2006).
A.6.1.2 Obter o comprometimento para com os requisitos (SP 1.2)
Onde quer que a prática específica anterior negocie com a obtenção de um entendimento com
os fornecedores dos requisitos, esta prática específica negocia com os acordos e
comprometimentos entre aqueles que têm que realizar as atividades necessárias para
136
implementar os requisitos. Requisitos evoluem por todo o projeto, especialmente os descritos
pelas práticas específicas das áreas de processo de Desenvolvimento de requisitos e soluções
técnicas. Assim que os requisitos evoluem, esta prática específica garante que os
participantes do projeto se comprometam com os requisitos aprovados e as mudanças em
planos de projeto, atividades e resultados (PHILLIPS et al., 2006).
Resultados típicos são: avaliações de impacto de requisitos; comprometimentos
documentados aos requisitos e mudanças de requisitos (PHILLIPS et al., 2006)
Subpráticas consistem em: avaliar o impacto dos requisitos em comprometimentos existentes;
negociar e registrar comprometimentos (PHILLIPS et al., 2006).
A.6.1.3 Gerenciar mudanças de requisitos (SP 1.3)
Os requisitos mudam por uma variedade de razões durante o projeto. Assim que as
necessidades mudam e o trabalho progride, requisitos adicionais são derivados e mudanças
podem ser feitas para os requisitos existentes. É essencial gerenciar estas mudanças e adições
eficientemente e com eficácia. Para analisar eficazmente o impacto das mudanças, é
necessário que a fonte de cada requisito seja conhecida e a justificativa para qualquer
mudança seja documentada (PHILLIPS et al., 2006).
Resultados típicos são: status dos requisitos; banco de dados dos requisitos; banco de dados
das decisões dos requisitos (PHILLIPS et al., 2006).
Subpráticas consistem em: documentar todos os requisitos e mudanças de requisitos que são
consideradas para gerar o projeto; manter o histórico de mudanças de requisitos com as
justificativas para as mudanças; avaliar o impacto das mudanças a partir do ponto de vista dos
stakeholders; deixar os dados de requisitos e mudanças para o projeto (PHILLIPS et al.,
2006).
A.6.1.4 Manter a rastreabilidade de requisitos (SP 1.4)
Quando os requisitos são bem gerenciados, a rastreabilidade pode estar estabelecida do
requisito-fonte até o nível mais baixo de requisitos a partir da fonte. Tal rastreabilidade ajuda
137
a determinar que todas as fontes de requisitos tivessem sido declaradas completamente e que
todos os requisitos de nível mais baixo podem ser rastreáveis de uma fonte válida (PHILLIPS
et al., 2006).
Rastreabilidade de requisitos podem também cobrir as relações entre outras entidades tais
como resultados finais e intermediários, mudanças em documentação de projeto e planos de
ensaios. A rastreabilidade pode cobrir relações horizontais para outras entidades tais como
interfaces cruzadas, tão bem quanto relações verticais. Rastreabilidade é particularmente
necessária em conduzir a avaliação de impacto de mudanças de requisitos nas atividades de
projeto e resultados (PHILLIPS et al., 2006).
Resultados típicos são: matriz de rastreabilidade de requisitos; sistema de monitoramento de
requisitos (PHILLIPS et al., 2006)
Subpráticas consistem em: manter a rastreabilidade de requisitos para garantir que a fonte do
nível derivado está documentada; manter a rastreabilidade de requisitos de um requisito aos
seus requisitos derivados e alocação às funções, interfaces, objetos, pessoas, processos e
resultados; gerar uma matriz de rastreabilidade de requisitos (PHILLIPS et al., 2006).
A.6.1.5 Identificar inconsistências entre os resultados e requisitos (SP 1.5)
Esta prática específica procura as inconsistências entre os requisitos e planos de projeto e
resultados e inicia uma ação corretiva para solucioná-las (PHILLIPS et al., 2006).
Resultados típicos são: documentação das inconsistências incluindo fontes, condições e
justificativas; ações corretivas (PHILLIPS et al., 2006)
Subpráticas consistem em: rever os planos de projeto, atividades e resultados para
consistência com os requisitos e as mudanças feitas neles; identificar a fonte da inconsistência
e a justificativa; identificar mudanças que necessitam serem feitas aos planos e resultados
resultantes das mudanças à referência de requisitos; iniciar ações corretivas (PHILLIPS et al.,
2006).
138
ANEXO B - Regras gerais para diagramas IDEF0
Regras da Metodologia IDEF0
Descrição
O desempenho da função número 3
requer a saída de dado/objeto da
função 2 e o dado/objeto fornecido
pela função 1.
Uma vez este dado/objeto é fornecido,
as funções 2 e 3 podem operar
simultaneamente.
A reta A se desdobra em seta B e C
para fornecer os controles de X e Y.
O desdobramento da reta A em duas
setas significa que as duas setas
desdobradas possuem a mesma
identificação
A junção de duas retas em uma seta A
significa que as informações contidas
nas retas são A.
A junção das retas A e B, onde B é
uma parte de A.
A junção das retas A e B resultou na
soma das mesmas
139
A saída “files” do bloco 1 contém os
controles necessários “customer
records” do bloco 2 e “price & Tax
tables” do bloco 3. A junção “account
earnes” é criada pelas informações
“deliver products” e “do billings”.
Em um diagrama, dados ou objetos
podem ser representados por uma seta
interna, com dois fins (fonte e uso), ou
por uma seta limítrofe, com somente
um fim conectado (fonte ou uso).
A seta de controle do bloco 1 do
diagrama filho é um controle do bloco
2 do diagrama pai. A entrada do bloco
1 do diagrama filho é a entrada do
bloco 2 do diagrama pai. A saída do
bloco 3 do diagrama filho é a saída do
bloco 2 do diagrama pai.
A notação parênteses indicada na
proximidade do bloco significa que os
dados ou objetos não são necessários
para o entendimento do próximo nível
(diagrama filho), e por isso não são
mostrados no diagrama filho.
As setas não correspondem às setas de
conexão do diagrama pai.
140
A seta com notação parênteses do
bloco 2 do diagrama pai não é
mostrada no diagrama filho. A saída
do bloco 2 do diagrama filho não é
mostrada em conexão no diagrama
pai.
Feedbacks de controle devem ser
indicados de baixo para cima sobre os
blocos.
Feedbacks de entradas devem ser
indicados de baixo para cima sob os
blocos.
Feedbacks de mecanismos devem ser
indicados de baixo para cima sob os
blocos.
Preferível o desdobramento da seta
que duas setas separadas.
141
ANEXO C - Conceitos de metodologia, processos, métodos e ferramentas
A palavra metodologia é freqüentemente considerada, de maneira errônea, como sinônimo da
palavra processo. Segue abaixo, então, definições que são usadas para distinguir metodologia
de processos, métodos e ferramentas (ESTEFAN, 2008):
Um processo é uma seqüência lógica de tarefas desempenhadas para obter um objetivo
particular. Um processo define “o quê” será feito sem especificar “como” cada tarefa
será desempenhada. A estrutura de um processo fornece muitos níveis de agregação
para permitir análise e definição do que será feito em vários níveis de detalhe para
apoiar necessidades diferentes de decisões e ações;
Um método consiste de técnicas para desenvolver uma tarefa, em outras palavras,
define “como” será feita cada tarefa (neste contexto, as palavras método, técnica,
prática e procedimento são freqüentemente utilizados intercambiavelmente). Em
qualquer nível as tarefas de processos são desempenhadas usando-se métodos.
Contudo, cada método é um processo em si mesmo com a seqüência das tarefas a
serem desempenhadas por aquele método em particular. Ou seja, o “como” em um
nível torna-se um “o quê” no próximo nível abaixo.
Uma ferramenta é um instrumento que quando aplicado em um método particular
pode melhorar a eficiência da tarefa, provavelmente aplicada apropriadamente ou por
alguém como habilidades e treinamento. O propósito da ferramenta deveria ser
facilitar a realização dos “como”. De uma maneira ampla, uma ferramenta melhora “o
quê” e o “como”.
Baseado nestas definições, a metodologia pode ser definida como uma coleção de processos,
métodos e ferramentas relacionados. Associados com as definições de processos, método (e
metodologia) e ferramentas está o ambiente. Um ambiente consiste de arredores, objetos
externos, condições e fatores que influenciam as ações de um objeto, pessoa ou grupo.
Estas condições podem ser sociais, culturais, pessoais, físicas, organizacionais ou funcionais.
Um ambiente pode habilitar (ou desabilitar) o “o quê” e o “como”.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo