1

1 Análise do Estado da Arte

Projetar Sistemas de Engenharia (SE) é uma atividade complexa que requer a
utilização de uma abordagem interdisciplinar robusta capaz de identificar os passos
importantes a serem realizados no desenvolvimento de um sistema de interesse (SOI
- system of Interest). O VANT é um exemplo de SE complexo construído por um
conjunto de diferentes elementos, ou subsistemas, que juntos produzem resultados
não alcançáveis apenas por um único elemento.
Os elementos do sistema podem incluir pessoas, hardware, software, instala-
ções, políticas e documentos; isto é, todas as coisas necessárias para produzir resul-
tados em nível de sistema. A integração destes elementos é uma tarefa complexa que
requer o uso de metodologias capazes de orientar as equipes de projetistas ao longo
do ciclo de vida de um sistema.
Um grande número de artigos na comunidade cientifica abordam a respeito dos
padrões internacionais, boas práticas e metodologias de desenvolvimento de SE. Em-
bora os autores apresentem propostas diferentes, o conjunto de processos e ativida-
des que compõem o desenvolvimento possuem similaridades e objetivos em comum.
Assim como métodos sistemáticos específicos para medir a maturidade e prontidão
tecnológica em projetos de agências espaciais e departamentos de defesa. Entre-
tanto, a aplicação destas metodologias em projetos de SE não é uma tarefa trivial em
virtude da ausência de informações suficientes que habilitem o uso pelas equipes de
desenvolvedores.
Com o objetivo de fornecer uma visão geral a respeito dos processos de desen-
volvimento de projetos de SE, avaliação de risco e prontidão de sistemas, este capítulo
apresenta um conjunto de trabalhos relacionados ao tema que foram propostos nos
últimos anos.
Os trabalhos pesquisados foram organizados em três categorias onde o pri-
meiro tópico descrevem a metodologia de desenvolvimento de projeto de SE assim
como os padrões internacionais e boas práticas advindas de aplicações militares e
aeroespaciais. O segundo apresenta os métodos utilizados para mensurar a maturi-
dade tecnológica dos sistemas. O terceiro trata de um método baseado em sistemas
de engenharia baseado em modelos (Model-based Systems Engineering - MBSE).
As três categorias apresentadas são definidas com base nas contribuições su-
geridas neste documento de qualificação, sendo apresentado uma visão geral rela-
cionada a esses tópicos, buscando identificar potenciais trabalhos relacionados que
contribuirão no direcionamento dos estudos e pesquisa visando formatar assim a li-
nha de pesquisa proposta. Os trabalhos científicos levantados foram escolhidos após
uma pesquisa exaustiva nas principais bases de dados científicas, incluindo www.
ieeexplore.ieee.org;www.incose.org;www.nasa.gov;www.elsevier.com;www.sciencedirect.com.
 2

1.1 Metodologia de Desenvolvimento de Projetos

Os primeiros registros documentados de utilização de modelos de processos
de desenvolvimento de SE advêm de projetos militares baseado nas boas práticas
industriais na engenharia utilizadas pelos Laboratórios Bell Telephones (Brill, 1998).
Com o avanço dos SE e Engenharia de Software (ESw) uma grande variedade de mo-
delos foram propostos pela comunidade científica para melhor representação gráfica
do ciclo de vida de desenvolvimento de projetos.
As dificuldades existentes no inicio do desenvolvimento de projetos mais com-
plexos fez com que os engenheiros de software propusessem novos métodos (ou
modelos) que melhor atendesse as necessidades específicas de cada aplicação bus-
cando representar de forma mais fiel os estágios, processos e atividades desenvolvi-
das durante o ciclo de vida do projeto.
As representações gráficas dos estágios do ciclo de vida podem ter um com-
portamento sequencial, incremental, interativo e recursivo entre os processos, sendo
necessário escolher qual abordagem de desenvolvimento atende ao Sistema de inte-
resse (SI).

1.1.1 Métodos Sequenciais - MS

Os métodos sequenciais são caracterizados por uma abordagem sistemática

que adere aos processos especificados à medida que o sistema evolui a partir dos
requisitos iniciais até o produto finalizado, sendo dada especial atenção a documenta-
ção, rastreabilidade e verificação dos resultados de cada processo.
O modelo waterfall desenvolvido por Royce(Royce, 1987) é um dos primeiros
modelos de que se tem registro. Neste método, o usuário determina os requisitos
e necessidades na fase inicial, apresentando uma visão geral de todo os processos
de forma cronológica entregando os resultados de cada conjunto de tarefas para a
próxima fase.
O autor Jason relatou em (Jason Bloomberg, 2015) que pelo menos 85% dos
projetos de software que utilizam o modelo waterfall apresentaram problemas como
atraso na entrega do projeto, orçamento acima do previsto e falta de algumas funci-
onalidades que foram definidas posteriormente pelo usuário. Há uma variedade de
registros de problemas ocorridos com esta abordagem no desenvolvimento de softwa-
res. Entretanto, este modelo demonstra um bom resultado quando aplicado em proje-
tos de pequeno porte e baixa complexidade. As vantagens e desvantagens do modelo
são apresentados na Tabela 1.
O O Conselho Internacional de Engenharia de Sistemas, do inglês INCOSE-
International Council on Systems Engineering) descreveu em (INCOSE, 2015) que
os pontos fortes deste método são: previsibilidade, estabilidade, repetibilidade e alta
 3

Modelo Waterfall
Vantagens Desvantagens
Usuário Desenvolvedores Usuário Desenvolvedores
- Maior gasto para - Requer intensa pesquisa na
- Documentação completa - Menor necessidade de efetuar
manter/atualizar definição das necessidades
de todas as fases. suporte.
o software do usuário.
- Conhece todas as necessidades
- Estrutura Simples. - Mais difícil de utilizar - Dificuldade de costumização.
e requerimentos do projeto.
Mais Flexível ( menor atuação - Transferência de informações -Exclui o cliente e - Requer equipe capacitada e
durante o desenvolvimento) entre as fases. usuário final. experiente.
- Dificuldades de efetuar mudanças
- Determina o objetivo final na etapa inicial.
de requisitos e funcionalidades.
- Atraso nos testes (desenvolvimento de software)

Tabela 1: Vantagens e Desvantagens do modelo Waterfall

segurança, sendo capaz de efetuar padronização dos processos e efetuar medições

e controle de resultados com o uso de dados históricos coletados e arquivados para
futuros planejamentos e melhorias de acurácia dos processos.
Estudos relacionados sugeriram que os projetistas precisavam utilizar uma nova
abordagem de modelo e estrutura de processos, para solucionar os dificuldades apre-
sentadas pelo modelo waterfall, no que tange a rigidez dos processos. O Modelo
Vee foi introduzido por Forsberg em 1991 (Forsberg & Mooz, 1991) e descrito em
(Forsberg et al., 2005) sendo apresentado como um método sequencial usado para
visualizar vários estágios e pontos chaves do SE.
O Modelo Vee destaca a necessidade de validação contínua com as partes in-
teressadas, a necessidade de definir planos de verificação durante o desenvolvimento
de requisitos e a importância da avaliação de risco e oportunidade. Os pontos fortes
são a rastreabilidade da maturidade em relação ao tempo decorrido, possibilitando
a equipe de desenvolvimento ter uma perspectiva ampla ao longo do ciclo de vida
desde o nível mais alto de requisitos do sistema até o nível mais baixo da arquitetura,
gerenciando os riscos de falhas nos estágios iniciais propondo conceitos alternativos
baseados nos resultados do nível mais baixo.
Numerosas variações deste modelo foram propostas para o ciclo de vida de
SE como em (Birowicz, 2005) apresentando uma extensão chamada de V-modell XT
utilizada em padrões internacionais de software e por empresas de desenvolvedoras
de sistemas inovadores, abordando também etapas administrativas e gerenciais do
projeto.
Em (Wasson, 2015) foi proposto um modelo chamado de W onde multi-camadas
do modelo Vee interagem até alcançar o resultado desejado que alimenta o próximo
processo de forma concorrente fazendo com que cada subsistema possa ser desen-
volvido de forma independente efetuando a integração dos processos na fase de inte-
gração, performance e verificação das especificações do sistema.
 4

1.1.2 Métodos Incremental e Interativo - MII

Este método vem sido utilizado desde 1958 em projetos de software e SE. O
modelo espiral (Boehm, 1986) é um exemplo de MII, introduzido em 1986 por Boehm
e evoluiu durante vários anos baseado na experiência e refinamentos dos modelo wa-
terfall e vee, tendo como objetivo propor uma estrutura de processos em espiral capaz
de mensurar a maturidade e riscos na definição dos requisitos do sistema. Nos dias
de hoje, o modelo evoluiu para modelo espiral de compromisso incremental (Boehm &
Lane, 2007; Boehm & Turner, 2015), do inglês Incremental Commitment Spiral (ICSM).
O ICSM combina os pontos positivos do modelo Vee, processo de verificação e
validação interativo e concorrente, agil e enxuto estabelecendo critérios de viabilidade
e resultados utilizando conceitos orientados/dirigidos por risco em conjunto com o mo-
delo Rational criado pela empresa IBM chamado de Unified Process (RUP), bastante
conhecido na engenharia de software (ESw)(Kruchten, 2003).
O MII representam uma abordagem prática e útil que permite que um projeto
forneça uma capacidade inicial seguida de entregas sucessivas para alcançar o sis-
tema de interesse desejado onde os requisitos ainda não estão completamente de-
finidos na fase inicial do projeto, ou quando as partes interessadas desejam fazer
mudanças durante o desenvolvimento, incluindo funcionalidades ou inserindo novas
tecnologias ao projeto.
Em (INCOSE, 2015) afirma-se que muitos artigos científicos concordam que os
MII apresentaram melhores resultados ao serem aplicados em projetos de sistemas
menores e menos complexos, contendo poucos elementos.
Publicações científicas da NASA (Kapurch, 2010) e DoD (Roadmap, 2005) re-
latam a utilização dos métodos ICSM, Vee e waterfall de forma integrada baseada
nas boas práticas de projetos de SE. O modelo de ciclo de vida utilizado por eles,
demonstra o uso de um conjunto de abordagens diferentes aplicadas a cada fase do
desenvolvimento do projeto combinando os pontos fortes de cada abordagem.
Uma nova linha de pesquisa propõe o uso da metodologia Agile , comumente
utilizada em ESw, em projetos de SE complexos denominado Agile systems enginee-
ring.

1.1.3 Modelo Ágil(Modelo Enxuto)

O termo Ágil é aplicado ao uso de uma coleção de métodos de desenvolvimento

de projetos aplicados a ESw incluindo: Dynamic Systems Development Methods (DSDM)
(Teixeira et al., 2005), Feature Driven Design (Schmidt, 2006), Crystal, Scrum, Extreme
Programming e mais recentemente Lean Software Development (Cockburn, 2008).
O manifesto Ágil (Ágil, 2011) tem como premissa a satisfação total do cliente
por meio de entrega precoce e contínua de resultados onde representantes comerci-
 5

ais, membros da equipe de desenvolvimento e partes interessadas trabalham juntos

ao longo do projeto com diálogos constantes, buscando transmitir as informações da
maneira mais eficiente para a equipe de desenvolvimento. Em intervalos regulares,
a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta as tarefas
alinhando com o objetivo das atividades.
A metodologia Scrum é definida como uma metodologia de desenvolvimento
de produtos com modelo ágil, sendo utilizado mundialmente por organizações como
Microsoft, Google, IBM, Federal Reserve Bank, Yahoo, Siemens e outras pequenas
companhias desde 1986. Diversos artigos retratam o uso de metodologias hibridas
onde modelos como waterfall e vee são utilizados em conjunto com a metodologia
Scrum para extrair melhores resultados durante o ciclo de vida do projeto, adequando
a estrutura do modelo de acordo com o tipo de projeto. (Tanveer, 2015; Choudhary &
Rakesh, 2016; Schindel & Dove, 2016).
Organizações governamentais, departamentos de defesa e agencias de pe-
quisa que desenvolvem projetos de software e SE complexos ou efetuam a compra
destes sistemas, precisavam implementaram metodologias de processos que auxili-
assem no acompanhamento das atividades e tarefas. Alguns contratos de projetos
podem exigir o uso de metodologias empregadas especificamente para uma determi-
nada aplicação, um exemplo é a indústria de defesa dos EUA, que exige uma classi-
ficação baseada em modelos de processo seguindo normas específicas para desen-
volvimento de projetos militares e contrato destes sistemas.

1.1.4 Normas e guias aplicados a SE

A diversidade de métodos utilizados no desenvolvimento de softwares e SE

despertou o interesse das organizações internacionais não governamentais de padro-
nização, do inglês International Organization for Standardization (ISO), em busca de
padronizar e definir normas a respeito do ciclo de vida de projetos, requisitos, guias,
ferramentas, qualidade, maturidade, dentre outras características.
Em abril de 1995, o comite de engenharia de sistemas da Associação de Indús-
trias Eletrônicas ,Electronic Industries Association (EIA), definiu um grupo de trabalho
denominado G47 parar criar padrões com base no modelo militar Mil-Std 499, que de-
finia as práticas comerciais de contratos militares na época. Foram criados o padrão
provisório EIA/632 e um padrão de teste chamado IEEE 1220 que substituíram o mo-
delo militar Mil-Std 499B. O padrão definitivo, EIA 632, foi desenvolvido e implantado
em 1998 com o título de processos para SE. Este padrões permanecem ativos e são
atualizados periodicamente (Martin, 1998a,b).
O artigo (Martin, 1998a) apresentou um estudo a respeito da evolução do pa-
drão EIA 632 e sua herança para o demais padrões assim como a estrutura dos do-
 6

cumentos que compõem os padrões, sendo compostos em 3 camadas com níveis de

abrangência complementares que relacionam diretamente com a norma EIA/IS 632.
A camada 1 é a camada de ’alto nível’ que documenta os requisitos e princí-
pios de SE comuns a todos ambientes e aplicações. Este documento é o "guarda
chuva"para os documentos das camadas 2 e 3 apresentando o conceito de "What - o
que"deve ser levado em consideração ao desenvolver um projeto de SE ( por exemplo
o padrão internacional EIA 632).
A camada 2 refere as práticas em SE, sendo um documento suplementar que
define os requisitos aplicáveis a uma determinada aplicação( por exemplo: industria
automotiva, NASA, DoD, DoE, indústria farmacêutica). Cada um desses documen-
tos pode ser desenvolvido de acordo com suas particularidades e interesses, tendo
assim uma variedade de métodos, ferramentas e documentos padrões utilizados no
desenvolvimento de projetos de SE.
A camada 3 consiste nos documentos suplementares opcionais para fornecer
diretrizes para um ambiente específico de SE sugerindo o "o que e como"deve ser
implementado o processo de desenvolvimento de projetos de SE. A Figura 1 apresenta
o histórico de evolução e derivações dos padrões aplicados a processos de SE.

Figura 1: hereditariedade dos padrões aplicados a SE (Martin, 2000)

O conceito de modelo de capacidade iniciou em 1992 com um grupo de tra-

balho de Avaliação de Capacidades (Capability Assessment Working Group - CAWG)
criado pelo INCOSE e formado por representantes de grandes empresas. Este grupo
elaborou o modelo de avaliação de capacidade de engenharia de sistemas ( Systems
Engineering Capability Assessment Model - SECAM). Enquanto isso, em dezembro de
1993, um grupo se separou do grupo de trabalho do INCOSE SECAM. Este grupo in-
cluiu oito organizações que concordaram em fornecer autores em tempo integral para
que um modelo de maturidade de capacidade de engenharia de sistemas (Systems
engineering capability maturity model - SE-CMM) fosse lançado. A união dos dois
 7

modelos deu origem ao padrão EIA/IS 731, chamado de Modelo de Capacidade de

Engenharia de Sistemas(Sheard & Lake, 1998).
Os modelos de capacidade descrevem como os SE podem e devem se com-
portar mediante as definições previstas pelos padrões, sendo utilizado para validar
os requisitos e procedimentos adotados. O padrão EIA/IS 731 descreve o nível de
maturidade do SE em 5 níveis: inicial, performance, gerenciamento, definição, me-
dições e optimização. Os níveis de definições e medições tem como características
principais mensurar e monitorar os processos, estabelecendo métricas que estimam a
maturidade dos processos utilizados no ciclo de vida do projeto.
Sheard em 1997 (Sheard & Consortium, 1997; Sheard, 2001) apresentam uma
estrutura conhecida como framework quagmire, que descreve um conjunto de docu-
mentos, modelos de capacidade e conformidade assim como os padrões utilizados no
desenvolvimento de softwares e SE. A autora expõe recomendações aos desenvolve-
dores para adotar apenas algumas poucas estruturas que possam fazer com que a
empresa mantenha a competitividade, menor tempo para comercializar os produtos e
fatores que mantenham a empresa rentável.
Em (Sheard & Lake, 1998) foi apresentado as similaridades e diferenças entre
cinco padrões de engenharia de sistemas, sendo eles: Mil-Std 499B, EIA/IS 632, EIA
632, ISO/IEC 15288, IEEE 1220 e três modelos de capacidade de engenharia de sis-
temas: EIA/IS 731 SE capability Model,SECAM e SE-CMM. Os padrões e modelos de
capacidade pesquisados apresentaram similaridade nos seus processos e atividades
e diferenças no uso de terminologias e linguagem técnica utilizados. A autora sugeriu
um alinhamento entre os padrões e modelos, assim como o uso destes documentos
em camadas demonstrando a necessidade de utilizar um conjunto de documentos
para melhores resultados.
O pesquisador (Clark, 2008) afirmou que para processos tradicionais de SE os
seguintes documentos padrões e guias IEEE 1220, EIA/IS-632, EIA-632, ISO 15288 e
ISO TR 19760 são suficientes. Entretanto, é importante ter uma visão mais abrangente
do processo e considerar que cada padrão representa uma perspectiva diferente do
processo clássico de SE, sendo necessário avaliar a possibilidade de utilizar a abor-
dagem de multi-padrões integrando diferentes processos.
O autor (Xue et al., 2014) apresentou uma abordagem multi-padrão no desen-
volvimento de SE ao identificar a dificuldade de engenheiros e gerentes que neces-
sitavam de auxilio para entender e analisar as similaridades e diferenças entre os
padrões EIA-632, IEEE 1220 e ISO 15288, com objetivo de escolher um padrão para
ser adotado na empresa. O padrão escolhido não satisfez completamente os crité-
rios de seleção, sendo necessário estender e adaptar o padrão com a utilização de
uma abordagem multi-padrões. O autor apresentou uma comparação dos seguintes
critérios entre os padrões: cobertura do ciclo de vida do sistema, nível de abstração,
 8

relações entre os processos e processos de validação e verificação.

Estudos foram feitos buscando identificar a evolução dos padrões e normas,
suas características, arquitetura e aplicação com o intuito de entender a taxonomia e
classificação destes documentos nos dias atuais. Padrões e modelos de SE apresen-
tam diferentes tipos de estruturas de processos, níveis de detalhes, particularidades e
camadas. O Corpo de Conhecimento em Engenharia de Sistemas, do inglês Systens
Enginnering Body of Knowledge (SEBok)(Pyster et al., 2012), listou aproximadamente
35 referências de padrões que podem ser utilizados em diferentes aspectos do SE.
Sendo apresentando também uma taxonomia que classifica os tipos de padrões e os
objetivos de cada tipo. No entanto, não incluem herança ou padrões substituídos. Um
estudo no repositório do IEEE e ANSI foi feito buscando identificar estas informações,
rastreando os documentos e padrões com objetivo de identificar a ordem cronológica
dos padrões válidos mais citados no desenvolvimento de projetos de SE, como mos-
trado na Figura 2.

previous
Now or under development
Will be replaced by
ISO/IEC/IEEE 24748

ISO/IEC TR 24748-1:2010 ISO/IEC TS 24748-1:2016 ISO/IEC/IEEE FDIS 24748-1

ISO/IEC TR 19760:2003 ISO/IEC TR 24748-2:2011 ISO/IEC/IEEE FDIS 24748-2

ISO/IEC TR 15271:1998 ISO/IEC TR 24748-3:2011

IEEE 1220:2005 ISO/IEC 26702:2007 ISO/IEC/IEEE 24748-4:2016

ISO/IEC/IEEE 24748-5:2017
ISO/IEC 12207:1995 ISO/IEC 12207:1995/Amd 1:2002

ISO/IEC 12207:1995/Amd 1:2004 ISO/IEC 12207:2008 ISO/IEC 12207:2017

ISO/IEC 15288:2002 ISO/IEC 15288:2008 ISO/IEC/IEEE 15288:2015

Figura 2: hereditariedade dos padrões aplicados a SE

O padrão ISO/IEC/IEEE 15288 de 2015 é um documento com alto nível de abs-

tração que estabelece uma estrutura que aborda todos processos técnicos, gerenciais
e organizacionais do ciclo de vida de um SE, indicando o uso de modelos interativos
e recursos, do tipo waterfal e vee. Este padrão é constituído de 4 grupos e 25 proces-
 9

sos sendo possível incluir processos de acordo com a necessidade da empresa. Os 4

grupos são: 1) processos de acordo; 2) projeto organizacional; 3) processos de geren-
ciamento técnico; 4) processos técnicos. Estes grupos trabalham em conjunto com um
modelo de ciclo de vida genérico de um sistema, tipicamente composto por 6 estágios:
concepção, desenvolvimento, produção, utilização, suporte e descarte/aposentadoria
(Iee, 2015).
Os processos do ciclo de vida de um sistema, de acordo com o padrão in-
ternacional (Iee, 2015), são descritos em relação ao sistema que é composto por
um conjunto de elementos que se interagem, onde cada um pode ser desenvolvido,
reutilizado ou adquirido para atender as respectivas especificações dos requisitos do
projeto. A relação entre o sistema e o seu conjunto de elementos do sistema pode
ser tipicamente representada em uma hierarquia, buscando simplificar a visualização
gráfica do sistema de interesse, conforme apresentado na Figura 3.

Figura 3: Estrutura de um sistema de interesse

A definição de quais elementos que devem compor o sistema é uma atividade

multidisciplinar que requer a integração entre os 4 grupos e seus processos. Mensurar
os riscos e possíveis falhas da arquitetura do sistema quando compostos por elemen-
tos que podem ser produtos disponíveis comercialmente no mercado, do inglês com-
mercial off-the-shelf (COTS), reutilizados de projetos previamente desenvolvidos em
outras plataformas, desenvolvido por uma equipe de projetistas parceira do projeto ou
até mesmo o grupo de desenvolvedores do projeto é um desafio.
O uso de ferramentas capazes de estimar a avaliação de risco, maturidade e
prontidão tecnológica dos elementos e sistemas, assim como a sua integração durante
o desenvolvimento do SE pode auxiliar na toma de decisões.

1.2 Avaliação de prontidão de sistemas

À medida que a complexidade dos sistemas aumenta, é essencial desenvolver
uma compreensão mais abrangente do status de desenvolvimento, ou prontidão, do
sistema para auxiliar decisões técnicas e administrativas de nível de sistema mais in-
 10

formadas ao longo do ciclo de vida. A falta de um pensamento sistemático abrangente

na fase inicial do projeto de um SE e a falha nos pontos de integração são duas das
principais causas do desenvolvimento malsucedido do sistema. Para medir a pronti-
dão do sistema, uma ênfase maior deve ser colocada na integração dos elementos e
subsistemas(Austin & York, 2016).
A metodologia de avaliação de prontidão do sistema„ do inglês system readi-
ness level (SRA), tem como premissa a captura de métricas que medem os aspectos
vitais de um esforço de desenvolvimento e como o processo de desenvolvimento está
avançando. Essas métricas fornecem informações para o processo de otimização e
tomada de decisão. Foram identificadas cinco métricas utilizadas inicialmente no na
composição do SRA. Sendo duas, o Technology Readiness Level (TRL) e o Integration
Readiness Level (IRL), são atribuídos e as três métricas restantes, Component SRL,
Composite SRL e SRL, são calculadas.

1.2.1 Avaliação de prontidão tecnológica

A abordagem dos níveis de prontidão tecnológica (TRL - Technology Readi-

ness Levels) originou-se na American National Aeronautics and Space Administration
(NASA) onde começou como um método de quantificar subjetivamente a maturidade
de certas tecnologias para uso em programas espaciais. Os TRLs vão desde o nível
1: conceito conceituado até o nível 9: missão comprovada. Os engenheiros usaram
os TRLs para tomar decisões sobre tecnologias e sua probabilidade de contribuir para
o sucesso de um sistema(Mankins & Mankins, 1995).
Mankins publicou também uma metodologia estendida de avaliação de TRL
para o gerenciamento eficaz da tecnologia(Mankins, 2002) e uma retrospectiva de
30 anos sobre os TRLs (Mankins, 2009) .O departamento de Defesa dos Estados
Unidos (DoD), juntamente com várias outras organizações, incluindo a International
Standards Organization (ISO), adotou posteriormente essa métrica e adaptou suas
definições para atender às suas necessidades sendo criado o padrão internacional
ISO/FDIS 16290 que descreve as definições dos níveis de prontidão tecnológica e
seus critérios (ISO, 2013).
Diversos artigos relatam o uso de TRL como ferramenta para desenvolvimento
de pesquisa cientifica e inovação e o impacto da inserção do TRL nas organiza-
ções(EARTO, 2014), aplicações em inovação na política pública da União Europeia(Héder,
2017), processo de aquisição de projetos complexos para o DoD (Graettinger, 2002),
guia para aplicações em tecnologias com fontes de energias renováveis(A. De Rose,
M. buna, C. Strazza, N. Olivieri, T. Stevens, L. Peeters, 2017), o impacto do TRL em
projetos de robótica desenvolvidos pelo programa Horizon 2020 (Butter et al., 2014)
são alguns dos relatos de boas práticas com o iso desta abordagem.
 11

Embora os níveis de TRL sejam métodos úteis para medir a prontidão tecno-
lógica, eles não levam em conta os aspectos negativos que as tecnologias imaturas
e sua integração podem introduzir aos SE. Aspectos negativos como a obsolescência
tecnológica podem ser combinados com os aspectos positivos destacados nos TRLs
para formar uma medida de risco tecnológico que reflita mais precisamente a influên-
cia de uma determinada tecnologia (Valerdi & Kohl, 2004).
Outras pesquisas apresentam critérios diferentes de definir a forma de calcular
o TRL dos elementos. Li et al. apresenta um sistema de avaliação para calcular os
níveis de prontidão de tecnologia de sete dimensões, incluindo requisito, projeto, im-
plementação, verificação, configuração, risco e segurança. Este método indica mais
detalhes de maturidade tecnológica além de escalares definidas por TRL demons-
trando a possibilidade de determinar métricas em estágios diferentes do ciclo de vida
de um projeto (Li et al., 2017).
Olechowski et.all em (Olechowski et al., 2015) apresentou um estudo descre-
vendo os 15 maiores desafios da avaliação de prontidão de sistemas, um dos pontos
críticos discutidos é o desafio da “integração e conectividade” entre os componentes
de um sistema. Embora os TRLs sejam principalmente avaliados em um nível de
componente, qualquer gerente de engenharia pode atestar que as interfaces preci-
sam ser levadas em conta para avaliar adequadamente a prontidão da tecnologia e as
definições de TRL não fornecem orientação suficiente sobre esse ponto (Garg et al.,
2017).

1.2.2 Níveis de prontidão de integração

O TRL não capta com precisão o risco envolvido na adoção de uma tecnolo-
gia, e qualquer tecnologia pode ter uma desigualdade de arquitetura relacionada à
integração (Smith, 2005). Como o TRL não pode avaliar interconexões de sistemas
complexos (Mankins, 2002; Sauser et al., 2008, 2010), uma métrica de sete níveis de
prontidão de integração (IRL) foi sugerida por Sauser et al. (Sauser et al., 2006). Após
mais pesquisas, os IRLs avançou para uma escala de nove níveis com fundamentos
teóricos alinhados com os níveis de TRLs (Sauser et al., 2010) e baseados também
nas sete camadas do modelo OSI (Open Systems Interconnection)(Jimenez & Mavris,
2014).
IRLs descrevem a maturidade da integração de uma tecnologia em desenvol-
vimento com outra tecnologia. A adição de IRLs não apenas fornece uma verificação
para onde a tecnologia está em uma escala de prontidão de integração, mas também
uma direção para melhorar a integração com outras tecnologias.
Brian et. all (Brian, 2009) apresentou um estudo de verificação e validação do
IRL atribuído aos elementos através de uma lista de verificação de critérios críticos de
 12

maturação. O autor apresentou uma proposta de dividir os 9 níveis em 3 estágios de

integração definidos como: semântica, sintático e pragmático.
O estágio semântica esta relacionado com a clareza e diferenciação. Assim, as
IRL 1-3 são consideradas fundamentais para descrever o que definimos como os três
princípios de integração: interface, interação e compatibilidade. O próximo estágio é
o sintáctico, que é definido como uma conformidade às regras. Assim, as IRLs 4-7
tratam da garantia de que um esforço de integração está em conformidade com as
especificações. O estágio final é o pragmático, que se relaciona com considerações
práticas. Assim, as IRLs 8-9 são sobre a afirmação da aplicação de um esforço de
integração. Os Critérios de Decisão e Avaliação da Criticidade IRL possibilitam estimar
com mais precisão o nível de integração do componente auxiliando no processo de
decisão com o uso de um checklist de atribuições.
A avaliação explícita da prontidão da integração dá aos gerentes de projeto
mais pontos de dados no processo de tomada de decisão, no entanto, a avaliação em
si pode ser cara, especialmente considerando que cada componente provavelmente
terá muitas interfaces.
Embora o IRL tenha fornecido uma valiosa adição ao TRL para avaliar as com-
ponentes do sistema, foi necessária uma abordagem holística para avaliar sistemas
complexos em vez de apenas componentes individuais. A fim de avaliar o estado tec-
nológico de um sistema complexo composto de elementos de tecnologia e conexão
integrada.

1.2.3 Níveis de prontidão de sistemas

O nível de prontidão de sistemas, do inglês system readiness level (SRL), foi de-
senvolvido para avaliar o risco de desenvolvimento de todo o sistema e para suporte
a aquisição de SE de programas organizacionai. Os SRLs combinaram matematica-
mente os valores de TRL do componente com a integração do sistema IRL e criaram
uma medida separada do progresso técnico dos sistemas (Sauser et al., 2008).
Os SRLs foram inicialmente desenvolvidos no Laboratório de Maturidade de
Desenvolvimento de Sistemas (SysDML) e foram expandidos em numerosos trabalhos
subsequentes (Ramirez-Marquez & Sauser, 2009; Sauser & Ramirez-Marquez, 2012).
A motivação subjacente do SRL era que os sistemas complexos e o SoS exigem uma
avaliação de prontidão mais robusta do que a avaliação isolada do componente de
TRL poderia fornecer.
(Sauser et al., 2008) relata o processo de aquisição utilizado pelo DoD com
base na utilização dos índices de maturidade TRL, IRL e SRL, relacionando direta-
mente com os estágios de ciclo de vida do projeto, tendo como referência a estrutura
comum de ciclo de vida de projeto definido no padrão ISO/IEC/IEEE 15288:2105,sendo
 13

representado em 5 faixas de valores (London, 2015). De acordo com (Austin & York,
2015) podemos definir três métricas de compõem a prontidão de sistemas.

Nível de prontidão de sistemas do elemento

Um componente de SRL é o nível de prontidão do sistema de um componente

individual do sistema e sua integração links. Os SRLs de componentes são usados
para identificar quais componentes do sistema estão atrasados ou podem estar muito
à frente em termos de disponibilidade e, portanto, exigem atenção do Gerenciamento
de Programas e/ou engenharia.

Nível de prontidão de sistemas composto

O SRL composto mede o SRL de todo o sistema ou todos os componentes do

sistema integrados juntos. A abordagem SRA calcula o SRL composto pela média dos
SRLs do componente e pela renderização do valor em um formato decimal. Como em
qualquer cálculo envolvendo uma média, o usuário precisa estar ciente do risco poten-
cial de mascarar um SRL de componente que pode estar significativamente atrasado
ou levando a média.

Nível de prontidão de sistemas: Global

O SRL é obtido convertendo o SRL composto para uma escala inteira de 1 a 9,

sendo 9 o o mais alto nível. A conversão para uma escala de números inteiros facilita
o relatório e a interpretação dos resultados.
Levantar os potenciais elementos que podem ser utilizados no SE proposto
demonstra ser uma atividade complexa e que pode interferir diretamente no compor-
tamento do sistema, caso as especificações dos elementos seja atendida pelos requi-
sitos mínimos definidos inicialmente na arquitetura do sistema mas não tenha um alto
nível de integração com os outros componentes e subsistemas poderá afetar avaliação
da maturidade do SE.
O design do sistema emerge das peças, e não da arquitetura ... resultando em
sistemas que são frágeis, difíceis de testar e complexos e caros de operar.
O SRL é calculado baseado nos valores de TRL e IRL escolhidos após a es-
colha dos elementos que compõem o sistema, a elaboração de experimentos e testes
ocorridos em outra fase do ciclo de vida do projeto devem comprovar os os níveis de
prontidão definidos inicialmente e informando ao gerente de projeto a necessidade de
efetuar alterações dos elementos para atender requisitos adicionais encontrados du-
rante a verificação e validação dos testes em laboratório, inclusão de novas atividades
 14

e tarefas buscando a integração e até mesmo a mudança de arquitetura que atenda

as limitações encontradas.
A avaliação dos potenciais elementos que foram levantados e que atendem os
requisitos mínimos definidos é uma tarefa que normalmente ocorre em conjunto com
outros setores de uma empresa como o setor de compra e importação, manufatura e
almoxarifado. A utilização de uma ferramenta capaz de mensurar os níveis de TRL
e IRL de cada elemento pode proporcionar um mapeamento geral que pontos fortes
e fracos de cada elemento dos fornecedores indicando o melhor grupo de elementos
que rastreia pode proporcionará o maior nível de SRL, sugerindo a equipe de desen-
volvedores a arquitetura que apresenta melhores resultados diminuindo o tempo de
trabalho na integração destes elementos e garantindo melhores resultados na valida-
ção experimental do SE proposto.
O nível de prontidão de fabricação, do inglês manufacture readiness level (MRL),
é uma ferramenta que pode também ser beneficiada por esta ferramenta em virtude
da integração necessária entre os processos garantindo a futura fabricação do SE. Um
estudo mais detalhado deve ser feito para avaliar o fator de impacto desta ferramenta
com a integração do MRL e os níveis TRL 5 a 7, conhecido como o vale da morte.

1. Estudo da relação existente entre os métodos utilizados para avaliação de

prontidão dos sistemas

o vale da morte ocorre entre os níveis 5 a 7 do TRL, estudos avaliam os poten-

ciais problemas que afetam diretamente no nível de classificação de maturidade tec-
nologica. integrar TRL, IRL, SRL, MRL rastreando as atividades e tarefas que devem
ser levadas em consideração no desenvolvimento do projeto para que possamos ien-
tificar fatores de risco que impactam diretante na definição das metricas levantadas. A
relação existente entre estes métodos de quantificação de maturidade demonstra que
existe a necessidade de uma integração ou relação que influenciam diretamente no
projeto do SE.
A engenharia de sistemas baseada em modelos (MBSE) é a aplicação formali-
zada de modelagem para suportar requisitos de sistema, projeto, análise, verificação
e validação, começando na fase de projeto conceitual e continuando ao longo do de-
senvolvimento e fases posteriores do ciclo de vida.
A integração de uma ferramenta capaz de avaliar a prontidão dos elementos, in-
tegração e sistema em uma linguagem de modelagem utilizada em MBSE e baseada
em um ciclo de vida padrão com fases, atividades e tarefas definidas onde o resul-
tado de cada possa sincronizar as informações de requisitos do SE pode auxiliar na
diminuição dos riscos e falhas na escolha e validação dos elementos do SE.
A linguagem de programação utilizada pela metodologia MBSE OOSEM desen-
volvida por INCOSE é SYSML. Será proposto um modelo capaz de avaliar os possíveis
 15

elementos que compõem a arquitetura do sistema efetuando os calculos de SRL e su-

gerindo a melhor combinação de elementos. Os resultados do SRL podem alimentar
o modelo de requisitos do SE que se comunica com os outros modelos através da
ferramenta de MBSE, sendo feito a realimentação dos dados adquiridos dos estágios
de desenvolvimento, atualizando assim os valores do modelo da avaliação de nível do
sistema.
Segundo aplicações da ferramenta SRL em projetos do DoD esta métrica é
relacionanda com o ciclo de vida do projeto, (Olechowski et al., 2015) apresentou
como desafio da adequação desta métrica as fases de desenvolvimento do projeto,
onde em alguns casos o nível SRL não representava de forma clara como deve ser
feito este particionamento entre as fases.
O modelo de desenvolvimento RUP relata o nível de ativiadade realizada em
cada fase do projeto, onde grande parte das implementações e arquitetura é definida,
verificada e validada nos primeiros estágios do ciclo não sendo representado de forma
fiel o nível SRL.