CAMPINAS 2019
UNIVERSIDADE ESTADUAL DE CAMPINAS Faculdade de Engenharia Elétrica e de Computação
RAMON CRAVO FERNANDES
ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA
CAMPINAS 2019
Dissertação de Mestrado apresentada à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas para obtenção do título de Mestre em Engenharia Elétrica, na área de Engenharia Biomédica.
Orientador: Prof. Dr. Eduardo Tavares Costa
ESTE TRABALHO CORRESPONDE À VERSÃO FINAL DA DISSERTAÇÃO DEFENDIDA PELO ALUNO RAMON CRAVO FERNANDES, E ORIENTADA PELO PROF. DR. EDUARDO
TAVARES COSTA
ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA
COMISSÃO JULGADORA – DISSERTAÇÃO DE MESTRADO
Candidato: Ramon Cravo Fernandes RA: 142386 Data da Defesa: 20 de fevereiro de 2019
Título da Tese: “ARES: Um processo centrado em modelagem para pesquisa aplicada em engenharia”
Prof. Dr. Eduardo Tavares Costa (Presidente) Prof. Dr. Eduardo Jorge Valadares Oliveira Prof. Dr. José Wilson Magalhães Bassani
A ata de defesa, com as respectivas assinaturas dos membros da Comissão Juldadora, encontra-se no SIGA (Sistema de Fluxo de Dissertação/Tese) e na Secretaria de Pós-Graduação da Faculdade de Engenharia Elétrica e de Computação
RESUMO
A inovação enquanto sistema constrói-se sobre as relações entre seus agentes, materializada pelas trocas e transferências de conhecimento e tecnologias. Neste contexto, a pesquisa torna-se parte do sistema de inovação, e a produção de conhecimento um empreendimento de facto. Assim, o empreendedorismo acadêmico é um processo de internalização das atividades de transferência tecnológica e de conhecimento.
Na tentativa de abordar as questões referentes à gestão de interfaces entre os produtores de conhecimento e tecnologia (universidades, organizações e centros de pesquisa e desenvolvimento, etc.) e os demais atores da inovação, suas interdependências e iteratividades, esta dissertação apresenta o desenvolvimento de um processo centrado em modelagem e simulação, denominado processo ARES.
Direcionado para a pesquisa aplicada em engenharia, o processo ARES é um processo incremental-evolutivo, baseado em transições uniformes e suaves de modelos mentais do domínio do problema para modelos de sistema e, assim, para modelos de design e implementação. De forma que, durante o desenvolvimento de um sistema ou pesquisa, os conhecimentos gerados ou empregados em seu esforço são adquiridos, selecionados, armazenados e transferidos através de mecanismos explícitos do processo, dando suporte à gestão do conhecimento, atributo da capacidade motriz de inovação de uma organização.
Palavras-chave: Engenharia de sistemas, Inovação, Pesquisa aplicada de engenharia, Processo ARES.
ABSTRACT
Innovation as a system is built on the relationship between its agents, materialized by the exchange and transfer of knowledge and technologies. In this context, research become part of the innovation system, and the production of knowledge an enterprise de facto. Consequently, academic entrepreneurship is a process of internalization of the activities of knowledge and technological transfer.
In a bid to address the issues of interface management between knowledge and technology producers (universities, organizations and centers of research and development, etc.) and the other actors of innovation, their interdependencies and iterations, this dissertation presents the development of a model-centric process, called ARES.
Targeting applied research in engineering science, ARES is an incremental-evolutionary process, based on seamless and smooth transitions from mental models of the problem domain to system models, and thus to design and implementation models. Therefore, during the development of a system or research, the knowledge generated or employed in its effort is acquired, selected, stored and transferred through explicit mechanisms within ARES, supporting knowledge management, attribute of the innovation driving power of an organization.
Keywords: Systems engineering, Innovation, Applied research in engineering
LISTA DE FIGURAS
Figura 2.1 - Modelo dinâmico do quadrante de Pasteur ... 22
Figura 2.2 - Fase 1 do modelo hélice tripla... 24
Figura 2.3 - Fase 2 do modelo hélice tripla... 25
Figura 2.4 - Fase 3 do modelo hélice tripla... 27
Figura 2.5 - Modelo de triangulação da hélice tripla ... 30
Figura 2.6 - Relação entre engenharia, scientia, techné e praxis ... 34
Figura 2.7 - Interação entre engenharia, ciência e organizações industriais e empresariais ... 35
Figura 2.8 - Relação engenharia/ciência ... 37
Figura 2.9 - Relação engenharia/organizações industriais e empresariais ... 38
Figura 3.1 - Fases e atividades da metodologia OOSEM ... 42
Figura 3.2 - O processo FDD ... 57
Figura 4.1 - Estratégia de design do processo ARES ... 67
Figura 4.2 - Primeira abstração do processo ARES ... 69
Figura 4.3 - Segunda abstração do processo ARES ... 70
Figura 4.4 - Terceira abstração do processo ARES ... 72
Figura 4.5 - Quarta abstração do processo ARES ... 73
Figura 5.1 - O processo ARES ... 86
Figura 5.2 - Modelo Rugby ... 93
Figura 5.3 - Níveis de abstração no domínio da modelagem ... 95
Figura 5.4 - Exploração: Modelagem cognitiva e Análise preliminar ... 102
Figura 5.5 - Análise: Modelagem e validação conceitual ... 107
Figura 5.6 - Arquitetura: Modelagem, especificação e validação sistêmica ... 112
Figura 5.7 - Arquitetura: Design da arquitetura e Particionamento ... 118
Figura 5.8 - Design: Encapsulamento e validação do design ... 124
Figura 5.9 - Implementação e teste: Implementação, verificação e validação de implementação e de pesquisa ... 129
Figura 5.10 - Extração de propriedades essenciais por simplificações/abstrações sucessivas ... 133
Figura 5.11 - Representação de domínio específico das pontes de Königsberg 135
Figura 5.12 - Esforço de modelagem do processo ARES ... 143
Figura 5.13 - Natureza dos modelos mentais ... 146
Figura 5.14 - Co-design: Modelagem homogênea ... 153
Figura 5.15 - Processo de aquisição de conhecimento de especialistas de domínio ... 157
Figura 6.1 - Modelo mental da natureza e física da formação de imagens modo-B ... 166
Figura 6.2 - Formação de imagens por ultrassom focalizado ... 167
Figura 6.3 - Esboço da arquitetura da plataforma de ultrassonografia diagnóstica ... 170
Figura 6.4 - Modelo conceitual do sistema ... 174
Figura 6.5 - Framework FBS situado ... 181
Figura 6.6 - Modelo em "caixa cinza": Decomposição do sistema em suas macro-funções ... 185
Figura 6.7 - Estrutura ontológica do catálogo de soluções ... 187
Figura 6.8 - Diagrama lógico do sistema-solução ... 190
Figura 6.9 - Estratégia Pipeline ... 194
Figura 6.10 - Arquitetura geral das FPGAs Virtex-6 ... 195
Figura 6.11 - Diagrama de blocos de núcleo DSP C66x ... 197
Figura 6.12 - Diagrama da arquitetura da plataforma ... 202
Figura 6.13 - Modelo encapsulado: Topologia e mapeamento dos filtros FIR na tecnologia alvo ... 206
Figura 6.14 - Modelo encapsulado: Implementação do algoritmo não-restaurativo de raiz quadrada ... 208
Figura 6.15 - Modelo encapsulado: Lógica de carry ... 209
Figura 6.16 - Modelo encapsulado: Decimador ... 210
Figura 6.17 - Imagem ultrassônica gerada pela plataforma a partir do phantom CIRS 068 ... 213
LISTA DE QUADROS
Quadro 3.1 - Dimensões do framework RUP SE ... 47 Quadro 5.1 - Níveis de interoperabilidade conceitual LCIM ... 88 Quadro 5.2 - Papéis descritivos e prescritivos dos níveis do framework LCIM .... 90
SUMÁRIO 1 CONSIDERAÇÕES INICIAIS ... 14 1.1 OBJETIVOS ... 15 1.2 MÉTODO DA PESQUISA ... 16 1.2.1 Análise ... 16 1.2.2 Design ... 17 1.2.3 Implementação ... 18 1.2.4 Teste ... 18 1.3 ESTRUTURA DO TRABALHO ... 19
2 INOVAÇÃO, CIÊNCIA E TECNOLOGIA ... 21
2.1 O MODO 2 ... 22
2.2 A HÉLICE TRIPLA ... 23
2.2.1 As fases do modelo ... 23
2.2.2 O papel das instituições ... 28
2.3 O QUE É ENGENHARIA? ... 32
2.3.1.1 Engenharia, ciência e indústria ... 34
3 PROBLEMATIZAÇÃO ... 39
3.1 ANÁLISE E INVESTIGAÇÃO ... 40
3.1.1 Object-Oriented Systems Method (OOSEM) ... 40
3.1.1.1 Análise e características da metodologia OOSEM ... 44
3.1.2 Rational Unified Process for System Engineering (RUP SE)... 46
3.1.2.1 Metodologia use-case flowdown ... 51
3.1.2.2 Análise e características do framework RUP SE ... 52
3.1.3 Feature-Driven Development (FDD) ... 55
3.1.3.1 Análise e características do processo FDD ... 60
3.2 CARACTERÍSTICAS DESEJÁVEIS À INOVAÇÃO ... 61
4 ARQUÉTIPO E DESIGN DO PROCESSO ARES ... 65
4.2 PROGRESSÃO DO DESIGN ... 69
4.2.1 O arquétipo do processo ARES ... 74
4.2.1.1 Modelagem cognitiva e plano de desenvolvimento preliminar ... 75
4.2.1.2 Modelagem conceitual e engenharia de requisitos... 76
4.2.1.3 Modelagem e especificação do sistema ... 77
4.2.1.4 Particionamento e design da arquitetura do sistema ... 79
4.2.1.5 Desenvolvimento incremental/evolutivo ... 79
4.2.1.6 Transição ... 80
4.3 O DESIGN SOB A ANÁLISE DOS REQUISITOS ... 81
5 O PROCESSO ARES ... 84
5.1 FRAMEWORKS USADOS NO PROCESSO ARES ... 87
5.1.1 LCIM ... 87
5.1.2 Rugby ... 93
5.1.3 Triângulo de Couclelis ... 97
5.2 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DE SUAS ATIVIDADES ... 101
5.2.1 Modelagem cognitiva e plano de desenvolvimento preliminar ... 101
5.2.2 Modelagem conceitual e validação conceitual ... 106
5.2.3 Modelagem e especificação do sistema e validação sistêmica .. 111
5.2.4 Design da arquitetura do sistema e particionamento ... 117
5.2.5 Encapsulamento e validação do design ... 122
5.2.6 Implementação, verificação e validação da implementação e validação e transferência da pesquisa ... 128
5.3 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DO ESFORÇO DE MODELAGEM 132 5.3.1 O propósito de um modelo ... 135
5.3.2 Transformação de modelo ... 136
5.3.3 Validação de modelos ... 138
5.3.3.1 Critérios de validade gerencial de modelos ... 138
5.3.4 O esforço de modelagem ... 141
5.3.4.1 Modelagem cognitiva ... 144
5.3.4.3 Modelagem sistêmica ... 149
5.3.4.4 Modelagem do sistema-solução ... 150
5.3.4.5 Modelagem da arquitetura do sistema ... 151
5.3.4.6 Modelagem do design do sistema ... 152
5.3.4.7 Modelagem da implementação do sistema ... 153
5.4 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DA GESTÃO DO CONHECIMENTO ... 154
5.4.1 Estratégias da gestão do conhecimento associada ao processo ARES 154 5.4.1.1 Identificação... 155 5.4.1.2 Aquisição ... 156 5.4.1.3 Seleção e validação ... 159 5.4.1.4 Organização e armazenagem ... 161 5.4.1.5 Compartilhamento... 161 5.4.1.6 Aplicação ... 162 5.4.1.7 Criação ... 163 6 CASO DE ESTUDO ... 164 6.1 O PROJETO PROTO85 ... 165 6.1.1 Modelagem cognitiva ... 165 6.1.2 Modelagem conceitual ... 172
6.1.3 Modelagem sistêmica e do sistema-solução ... 177
6.1.3.1 Framework FBS situado... 178
6.1.3.2 O resultado da modelagem sistêmica e do sistema-solução e a estrutura ontológica do catálogo de soluções ... 184
6.1.4 Arquitetura, design e implementação do sistema ... 192
6.1.4.1 Modelo da abstração de tecnologia ... 199
6.1.4.2 Particionamento, encapsulamento e implementação ... 203
6.1.5 Validação e transferência do conhecimento ... 212
6.2 O PROCESSO ARES SOB A ANÁLISE DOS REQUISITOS ... 215
7 CONSIDERAÇÕES FINAIS ... 218
REFERÊNCIAS ... 223 ANEXO A ... 243
1 CONSIDERAÇÕES INICIAIS
Nas últimas décadas, a teoria da inovação, ciência e tecnologia têm se expandido e avançado nas definições quanto a sua natureza, processos e interrelações. Intimamente relacionados entre si, os atores participantes do processo de inovação constroem um círculo virtuoso de saber interdisciplinar. Sempre que mudanças socioeconômicas ou culturais ocorrem, o processo de inovação, ciência e tecnologia se altera de acordo, conduzindo à evolução de seu entendimento, fundamentos e modelos que, por sua vez, contribuem para sua condução e realização.
Neste sentido, como observa Dudziak (2007), há uma inerente ligação dialética1 entre a teoria da inovação, ciência e tecnologia, a práxis acadêmica de
pesquisa e as intervenções no processo empreendidas pelo poder público, e que apenas uma visão harmonizada desses três fatores produz um sistema de inovação. Da práxis acadêmica elegeu-se o objeto desta dissertação, um processo de pesquisa e desenvolvimento voltado para a inovação, na qual, busca-se estabelecer uma relação entre as prerrogativas da inovação e a pesquisa aplicada em engenharia, elencando as características e requisitos desejáveis à inovação, sob a ótica da pesquisa continuada e do avanço tecnológico.
A aparente inabilidade ou incapacidade dos processos e metodologias disponíveis, principalmente nos ditos ágeis, em suportar a pesquisa continuada ou em assistir a interdisciplinaridade crescente nos empreendimentos de avanço tecnológico e inovação, foi o motivador e motor do presente trabalho. Um olhar mais atento sobre os processos e metodologias de desenvolvimento de software e sistemas mostra inúmeras omissões e deficiências (NUSEIBEH; EASTERBROOK, 2000; PAIGE; OSTROFF, 2002; BOEHM, 2006), incluindo:
• Precária rastreabilidade entre requisitos e a coisa. • A inconsistência entre artefatos.
1 Entende-se aqui a dialética no sentido de Hegel (HEGEL, 1998), com a compreensão de que o conflito entre opostos não é ideal, mas real, e que a superação dessa disputa não representa uma correção no conteúdo, mas o surgimento de algo novo (FERREIRA, 2013), sob a tríade Abstrato-Negativo-Concreto.
• A adoção de premissas e pressupostos não realistas, especialmente nas metodologias ágeis.
• O desenvolvimento contínuo não é adequadamente apreciado.
• A inconsistência dos artefatos nas metodologias guiadas ou baseadas em modelos.
• O vínculo patente com a disciplina da engenharia de software.
• Ausência de vínculo entre a estrutura dos processos e metodologias e gestão do conhecimento.
1.1 OBJETIVOS
Da motivação, pode-se resumir o esforço empregado neste trabalho como: A criação de um processo, chamado ARES, centrado na modelagem e simulação para pesquisa aplicada em engenharia através de um processo genérico de desenvolvimento de sistemas, analisando processos, meta-processo e metodologias existente, extraindo suas características básicas e produzindo um conjunto de requisitos que define as propriedades que o processo alvo deve atender. A metodologia pode então ser projetada e implementada a partir de técnicas de especificação existentes de forma a satisfazer os requisitos.
Os objetivos específicos que devem ser alcançados pelo processo ARES estão detalhados na seção 3.2, características desejáveis à inovação, e podem ser resumidos em:
• Criação de um processo que contemple explicitamente a gestão do conhecimento
• Criação de uma cadeia de atividades e artefatos uniforme e rastreável • Criação de um processo independente de linguagens ou ferramentas
específicas
• Criação de uma cadeia de validação contínua dos artefatos gerados no ciclo de vida do processo.
1.2 MÉTODO DA PESQUISA
Uma vez que este trabalho visa o desenvolvimento de um processo, o que poder-se-ia considerar por método aplicável? Na abordagem desta dissertação, o desenvolvimento do processo centrado na modelagem e simulação para pesquisa aplicada em engenharia (processo ARES) foi aproximado ao desenvolvimento de um sistema ou software de domínio-específico. Desta forma, o processo empregado consiste de quatro fases comuns ao desenvolvimento de sistemas de domínio-específico e similares àquelas empregas pela engenharia de software: Análise, Design, Implementação e Teste; abordagem proposta por Ramsin em sua tese,
The Engineering of an Object-Oriented Software Development Methodology
(RAMSIN, 2006).
Nesta abordagem o processo é desenvolvido através de um ciclo iterativo de
design, implementação e teste com base no resultado da análise. Ao final de cada
fase e de cada ciclo, uma atividade complementar de verificação e revisão do processo é realizada, garantindo um esforço coerente de desenvolvimento.
1.2.1 Análise
As atividades e os objetivos na fase de Análise focam na descoberta e análise dos requisitos, através da exploração do domínio do problema. No escopo desse trabalho, listam-se os seguintes objetivos como os principais dessa fase:
• Identificação e análise detalhada do domínio do problema; extrair as características essenciais para a identificação dos requisitos para o processo através da compreensão das estruturas e comportamentos do domínio do problema.
• Definição dos critérios de análise; produzir os requisitos do processo através da aplicação dos critérios de análise ao domínio do problema.
• Determinar o escopo do processo e delinear os requisitos aplicáveis.
Abaixo enumera-se um possível conjunto de atividades que satisfazem os principais objetivos da fase de Análise:
Atividade 1: Exploração do domínio do problema, abrangendo o estudo e a análise das metodologias e processos existentes, elencando os atributos de cada metodologia, levando, por sua vez, as características desejáveis ao processo proposto; esta tarefa é a base para a concepção de um conhecimento analítico sobre processos e metodologias, pré-requisito para a elaboração de um conjunto confiável de requisitos de processo e de um método adequado para arquitetar o processo proposto.
Atividade 2: Composição de um conjunto de requisitos concretos, a que deve obedecer ao processo proposto; esta tarefa requer uma análise das metodologias existentes.
1.2.2 Design
Análogo a engenharia de software, a fase de Design refere-se à produção de uma especificação detalhada para o software em desenvolvimento, que, no escopo desta dissertação trata-se do processo ARES, a ser implementada nas fases posteriores.
Os objetivos dessa fase são:
• Desenvolvimento de um arquétipo para o processo proposto.
• Produção de uma especificação detalha para o processo alvo baseada no processo e nos requisitos.
As atividades que compõem a fase de Design são:
Atividade 3: Adução do arquétipo para projetar o processo com base na compreensão e conhecimentos acumulados sobre o domínio do problema e nos requisitos descobertos a partir deste.
Atividade 4: Concepção do processo alvo através da aplicação do arquétipo selecionado; o produto desta fase inclui o esqueleto do processo alvo, com sua arquitetura, fases, e subfases, fornecendo indicações de atividades e tarefas numa dada ordem, especificando quais artefatos devem ser produzidos em cada fase.
1.2.3 Implementação
Esta fase trata do desenvolvimento do processo em si. Tal qual a noção de implementação aplicada no desenvolvimento de softwares e sistemas, essa fase produz o processo e o disponibiliza ao usuário. No contexto dessa dissertação, a implementação tem por objetivos:
• Produção do processo através do detalhamento das especificações da fase de Design.
• Disponibilização do processo aos usuários.
As atividades que constituem a implementação são:
Atividade 5: Produção da documentação necessária ao uso do processo alvo com sua especificação detalhada descrevendo suas fases, processos e métodos.
1.2.4 Teste
A fase de teste de um processo não difere muito dos testes aplicados a sistemas, o principal objetivo de um teste é verificar e validar o produto e suas características. A fase de teste para o desenvolvimento do processo tem por objetivos:
• Aplicação do processo a um caso de estudo.
• Análise, verificação e validação a aderência do processo ao caso de estudo proposto.
As atividades dessa fase são:
Atividade 6: Definição do caso de estudo; seus requisitos, escopo e características próprias.
Atividade 7: Validação do processo através da análise do fluxo de desenvolvimento e obtenção do produto final definido no escopo do caso de estudo.
1.3 ESTRUTURA DO TRABALHO
Esta dissertação foi organização de maneira pouco ortodoxa com a finalidade única de tornar a descrição do processo ARES (apresentada no Capítulo 5) completa e autocontida num capítulo independente e de que cada fase do processo de seu desenvolvimento esteja contida em um capítulo dedicado. Assim, todo e cada pedaço de informação pertinente ao processo e ao seu desenvolvimento encontra-se oportuno em seu capítulo correspondente. Dessa maneira, segue-se:
• No Capítulo 1 (Consideração Iniciais) é feita uma pequena introdução, apresentando o contexto geral que permeará toda a dissertação, a motivação, objetivos e método aplicado no desenvolvimento do processo ARES.
• No Capítulo 2 (Inovação, Ciência e Tecnologia) são apresentados os fundamentos teóricos de um sistema de inovação. Com o objetivo de lançar luz sobre os atores e componentes de um sistema de inovação e suas relações e interdependências, este capítulo foi estruturado para apresentar o contexto específico no qual se insere o processo desenvolvido.
• No Capítulo 3 (Problematização) um cânone de metodologias de engenharia de sistemas é investigado, correspondendo à fase de Análise do desenvolvimento do processo ARES. Ao final deste capítulo lista-se um conjunto de características e requisitos desejáveis à inovação.
• No Capítulo 4 (Arquétipo e Design do Processo ARES) discute-se sobre o processo de desenvolvimento iterativo aplicado na fase de Design do desenvolvimento do processo ARES, seus mecanismos e resultados. O processo é gradualmente formado a cada iteração, resultando num arquétipo, cujas interfaces entre fases e macro-atividades são suficientemente detalhadas, delineado no final do capítulo.
• O Capítulo 5 (O Processo ARES) apresenta o processo ARES em si, e corresponde à fase de Implementação do processo. Neste capítulo o processo ARES é descrito detalhadamente sob três perspectivas singulares – das atividades, do esforço de modelagem e da gestão do conhecimento –
englobando, em cada uma delas, os conceitos, premissas e visões particulares.
• No Capítulo 6 (Caso de Estudo), referente à fase de Teste do processo, o caso de estudo, denominado projeto Proto85, no qual o processo ARES foi aplicado, é apresentado. Para cada subprocesso do processo ARES, os principais resultados, decisões e artefatos são apresentados, evidenciando o vínculo e a coerência entre estes e a cadeia de desenvolvimento proposto pelo processo. Ao final do capítulo o processo ARES é analisado quanto aos seus requisitos.
• No Capítulo 7 (Considerações Finais) são apresentadas as conclusões parciais do esforço inicial empregado no desenvolvimento do processo ARES, contendo um sumário das principais contribuições e resultados alcançados com o desenvolvimento do processo e uma lista de cursos potenciais (sugestões de encaminhamento) para o aprofundamento e complementação de alguns de seus aspectos.
2 INOVAÇÃO, CIÊNCIA E TECNOLOGIA
A inovação enquanto processo evolucionário de interação entre mercado e a base de conhecimentos e capacidades das empresas (PORTER, 1990) considera por base uma visão gerencial estratégica. Nesta perspectiva é preciso considerar, por um lado, a trajetória da empresa, sua estratégia tecnológica e seu sistema de gestão e, por outro lado, fatores externos, como o contexto econômico, a variabilidade intra- e intersetorial, a organização do mercado, a localização geográfica, etc.
A inovação enquanto sistema constrói-se sobre as relações entre seus agentes, materializada pelas trocas e transferências de conhecimentos e tecnologias, considerando a capacidade que os atores possuem em transformar ações em bens econômicos (CARLSSON et al., 2002), definida como competência tecno-econômica de ênfase estratégica (DUDZIAK, 2007). Para Metcalfe (2003), um sistema de inovação é tal um conjunto de instituições distintas que juntas e individualmente contribuem para o desenvolvimento e difusão de novas tecnologias e que provê a estrutura dentro da qual governos formam e implementam políticas para influenciar o processo de inovação. Como tal, é um sistema de instituições interconectadas para criar, estocar e transferir conhecimento, habilidades e artefatos os quais definem novas tecnologias.
A pesquisa e a investigação científica, encarada como uma forma de resolver problemas, torna-se atividade adjunta, parte da cadeia de inovação e não mais pré-condição de sua iniciativa. Segundo Dudziak (2007), neste momento, a atividade de pesquisa abandona seu isolamento acadêmico e torna-se parte do sistema de ciência, tecnologia e inovação.
Para Stokes (1997), não existe, de fato, uma oposição entre as ciências, em suas pesquisas básicas e aplicadas, mas uma visão diferente a respeito da motivação que leva à pesquisa, quer seja orientada pela necessidade de entendimento, pela necessidade de uso ou ambos. O que o autor chama de quadrante de Pasteur, cuja representação dinâmica é representada na figura 2.1.
Figura 2.1 - Modelo dinâmico do quadrante de Pasteur
Fonte: STOKES, 1997
Neste contexto, trata-se, portanto, de determina que valor uma pesquisa possui: científico, econômico, social ou tecnológico.
2.1 O MODO 2
Do ponto de vista em que o conhecimento somente é produzido em um contexto de aplicação e em que se encontra influenciado pelos interesses de diversos agentes sociais, Gibbons et al. (1994) sumarizaram a transformação do paradigma de produção de conhecimento, no que se convencionou chamar de “modo 2” de produção. O “modo 2” diferencia-se por considerar a transdisciplinaridade e o entendimento de que o conhecimento é produzido no
contexto de sua aplicação, é socialmente distribuído, heterogêneo, variável e cujos mecanismos de comunicação são mais densos e horizontais.
Nessa abordagem, a visão da ciência como saber puro é substituída por uma ciência baseada na força produtiva, condicionada pelas estruturas sociais que moldam seu curso, métodos e resultados (VELHO, 1996), tornando-se socialmente relevante a partir de seu impacto econômico, legitimadora de mudanças tecnológicas, cujo ápice encontra-se no mundo empresarial.
2.2 A HÉLICE TRIPLA
No mesmo raciocínio do “modo 2” de produção, porém com foco nos relacionamentos entre atores, surge o modelo teórico de inovação: o modelo da hélice tripla de Etzkowitz e Leydesdorff (1995).
O modelo da hélice tripla representa as relações entre universidades (entendidas aqui como entidades de ensino e pesquisa), empresas e governo, articulando redes de comunicação e trocas, conhecimentos e sistemas envolvidos em ciência, tecnologia e inovação. O modelo da hélice tripla compreende três estágios/fases distintas: primeiro, um papel proeminente da universidade na inovação; segundo, um movimento em torno das relações colaborativas entre as três esferas institucionais – as políticas de inovação são construídas a partir das interações entre os três agentes; terceiro, a sobreposição de funções e desenvolvimento em diferentes eixos retro-alimentadores (DUDZIAK, 2007) – a universidade é formadora de empresas e também exerce papel como fornecedora de pessoas e serviços.
2.2.1 As fases do modelo
Num processo de desenvolvimento econômico com base em dinâmicas do tipo hélice tripla, é possível identificar, como dito anteriormente, três fases distintas, baseadas nas estruturas funcionais de cada uma das esferas e na forma como interagem.
FASE 1: O modelo político
Figura 2.2 - Fase 1 do modelo hélice tripla
Fonte: ETKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)
No arranjo institucional tradicional, predominante até meados do século vinte, as três esferas evidenciam fronteiras bem definidas e sem sobreposições, com funções próprias bem delimitadas (ETZKOWITZ; LEYDESDORFF, 2000): a universidade produz ciência fundamental e ensina; a indústria produz. Os novos produtos resultam do desenvolvimento experimental na esfera da indústria; o governo regula e regimenta o funcionamento da universidade e da indústria e as relações entre elas (Figura 2.2).
As relações entre universidade e indústria processa-se no nível do ensino, com a consideração da necessidade de adaptação da oferta de mão de obra especializada (formação acadêmica) às necessidades do mercado de trabalho.
O governo alinha-se cada vez mais a um nível internacional, na contínua necessidade de adaptação a um mundo em constante mutação, implicando na necessidade de constante mudança, análise, avaliação e adaptação dos objetivos no tocante a informações disponíveis e resultado pretendidos (AUXILIAR, 2010). Neste contexto, a aproximação do governo às duas outras esferas institucionais é inevitável.
As mudanças que se vão processando no interior das diferentes esferas institucionais e no meio em que operam, imperam a reestruturação das estruturas organizacionais e institucionais e da mentalidade e o estreitamento das relações prevalecentes. É este ciclo de mudanças que impulsiona o sistema de inovação para a fase seguinte.
FASE 2: O modelo laissez-faire
Figura 2.3 - Fase 2 do modelo hélice tripla
Fonte: ETZKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)
Nesta fase, as hélices do sistema se redefinem como sistemas de comunicações que consistem no funcionamento do mercado, na tecnologia e no controle existentes sobre as interfaces (ETZKOWITZ; LEYDESDORFF, 2000).
As reestruturações internas de cada um dos agentes e o aprofundamento das relações bilaterais, gera um aumento da circulação de informações entre as esferas (Figura 2.3). À medida que a rede relacional toma forma e se consolida, novas transformações ocorrem em cada uma das esferas institucionais. A pressão exercida sobre as universidades em termos de autonomia financeira, e a decorrente orientação para o mercado, faz com que adquiram competências empreendedoras: • Numa filosofia de prestação de serviços e captação de financiamento, acordos de pesquisa e investigação acadêmica são estabelecidos entre universidade e indústria.
• O sistema de controle da qualidade da produção científica passa a ser feito por avaliadores acadêmicos e empresariais. Ao envolver a indústria, esta avaliação permite uma correção de trajetória quando existe um desvio de objetivo, cada vez mais orientada à indústria.
• Aumento da autonomia dos centros de pesquisas que passa a ser geridos de acordo com objetivos sociais e organizacionais.
A aceitação da importância das interrelações entre as três esferas gera uma aproximação entre governo, universidade e indústria, mobilizando os diferentes atores num sentido único. As instâncias do governo passam a assumir uma atitude facilitadora das dinâmicas interrelacionais entre as esferas, promovendo e participando em parcerias de interesse social, mas, essencialmente, com o reconhecimento (promovendo aceitação pública) de que o desenvolvimento tecnológico e industrial constitui a base do desenvolvimento sustentável.
Nesse cenário, a indústria tem cada vez mais noção de que sua competitividade depende da constante inovação e adequação às exigências do mercado. Entretanto, a maior parte das empresas não dispõe de capital para assumir projetos de pesquisa aplicada e desenvolvimento experimental. Neste sentido, essas empresas buscam projetos de parceria com as universidades.
A entrada da fase 3 é marcada pelo momento em que os atores do processo de inovação tomam consciência de que “[...] as organizações são entretecidas, as
suas fronteiras definidas e alteradas, e as suas interrelações concretizadas não apenas como relações entrada-saída, mas como interdependências não negociáveis, sujeitas a um elevado grau de reflexividade” (STORPER, 1997).
Figura 2.4 - Fase 3 do modelo hélice tripla
Fonte: ETZKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)
O reconhecimento das alterações ocorridas na fase 2, e as implicações da reorganização institucional e interrelacional entre as diferentes esferas, implicam na reestruturação das esferas, a um passo que levam a assumir o papel umas das outras, diluindo as fronteiras entre as instituições no centro da dinâmica helicoidal formada pelas três esferas (Figura 2.4). A diluição das fronteiras institucionais não corresponde a uma perda de identidade dos atores do processo de inovação, mas resulta na atribuição de uma missão comum a todas as esferas: A “capitalização do conhecimento” (ETZKOWITZ, 2008).
A indústria assume a “capitalização do conhecimento” como a forma de se manter competitiva. A universidade passa a assumi-la não apenas como uma forma de obter financiamento externo, mas como uma função social, adotando um papel de agente com poder para se tornar o motor do desenvolvimento social, através de sua capacidade em transferir conhecimento. Desta forma, a universidade torna-se um agente econômico direto, e a produção de conhecimento um empreendimento
de facto. Nesta nova filosofia, instituições governamentais agem como parceiros
com igual poder, agindo como financiadores, mas também como sócios com poder de decisão e orientação do processo de inovação, encarando a “capitalização do conhecimento” como um mecanismo para alavancar o desenvolvimento.
O sistema de inovação na fase 3 do modelo da hélice tripla apresenta cinco características particulares (ETZKOWITZ, 2008) que o distingue dos sistemas nas fases 1 e 2, a saber:
1. A “capitalização do conhecimento” torna-se a base para o desenvolvimento econômico e social, pela qual a universidade, enquanto entidade empreendedora, adota um papel central nos processos de transferência de tecnologia e na “economia do conhecimento”.
2. As três hélices do modelo, universidade, indústria e governo, são autônomas e independentes.
3. A densa rede de relações entre as três esferas do modelo e a formação das relações institucionais, resulta num grau de interdependência elevado. De forma que, o posicionamento de cada uma das esferas determina e é determinado pelo posicionamento das outras esferas no processo de inovação.
4. A resolução das tensões entre independência institucional e interdependência organizacional dá origem a novas formas de organização funcional e instituições híbridas (incubadoras, institutos de pesquisas, etc.), potencializando e agilizando os processos de transferência tecnológica. 5. A alteração dos modelos relacionais entre as três hélices dá origem a ajustes
estruturais contínuos em cada uma delas, o que, por sua vez, promove a renovação dos modelos relacionais e novas formas de interação.
A “capitalização do conhecimento”, que permite a cada uma das esferas atingir objetivos próprios, constitui o fator de aproximação delas, originando um “espaço” central de cooperação e discussão voluntárias, onde ocorre a partilha de informações mútuas (AUXILIAR, 2010).
2.2.2 O papel das instituições
Nos processos de desenvolvimento com base em dinâmicas do tipo hélice tripla, pode-se constatar que o papel de cada um dos atores no processo de
transferência tecnológica e de conhecimento, se vai alterando à medida que o processo passa por suas diferentes fases
Na fase 1, identifica-se uma universidade pouco envolvida no processo de transferência tecnológica. A universidade como “Torre de Marfim” produz ciência e sua relação com a indústria ocorre fundamentalmente pelo ensino, não tendo papel ativo na inovação. A inovação pertence, e está contida, à esfera da indústria, que desenvolve novos produtos, aplicações e processos. O governo, por sua vez, determina o enquadramento de todo o processo, porém, embora controle-o, não participa ativamente no processo.
Na fase 2, a universidade participa mais ativamente do processo de inovação, partilhando com a indústria as funções de pesquisa aplica e desenvolvimento experimental. Nesta fase, o governo assume uma postura de menor controle, no entanto aproxima-se mais das outras duas esferas, como facilitador das relações entre estas. Já a indústria adere mais facilmente a laboratórios e equipamentos para desenvolver seus projetos de investigação e pesquisa, inicialmente com a aquisição de serviços e parcerias com as universidades.
Na fase 3, as três hélices encontram-se entrelaçadas numa espiral, em que o posicionamento de cada uma influencia o, e é influenciado pelo, posicionamento das outras. As três esferas institucionais participam como parceiras na transferência de tecnologias e conhecimentos, alterando e alternando-se em suas funções, diluindo as fronteiras institucionais e criando instituições híbridas.
A iteratividade e interdependência entre os atores corroboram para a necessidade de gestão das interfaces entre produtores, intermediários e usuários de inovação, fruto da conscientização crescente que demanda articulação permanente pelo provimento de estratégias e pontes entre os atores e grupos de interesse com diferentes anseios sociais e posições institucionais.
Nesta conjectura, Farinha e Ferreira (2013) propuseram o modelo da triangulação da hélice tripla, apresentado na figura 2.5, onde a inovação e o empreendedorismo são vistos como catalisadores do desenvolvimento e como mediadores da competitividade empresarial com base na gestão em rede e enraizada nos três pilares da sustentabilidade: ambiental, econômico e social.
Figura 2.5 - Modelo de triangulação da hélice tripla
Fonte: FARINHA et al., 2016 (Reproduzido com autorização)
A análise das motivações e dos elementos que influenciam e catalisam o processo auxilia no entendimento das condições que regem e criam o sistema de inovação. Do ponto de vista das regras, normas e relações, as ações são sempre de fundo político, definidas com base nos valores e paradigmas vigentes nas distintas instâncias do sistema.
A propagação da inovação se dá por adoção e troca de informações entre agentes, num processo associado à teoria de percolação social (FRENKEN, 2006). Deste modo, a inovação é compreendida como processo coletivo, socialmente construído e passível de transformações a partir de novas leituras/percepções da realidade e apropriações tecnológicas. Assim, não é o mercado que cria a oportunidade de inovação; são os usuários que traçam estas oportunidades (SMITS; KUHLMANN, 2004).
Neste esteio desenvolve-se o conceito de inovação sustentável, na qual a inovação é direcionada ao bem estar das população, que respeita princípios éticos, adapta-se ao usuários, sendo consistente ao seu modo de vida, é transparente, ecológica e inclusiva (DEARING, 2000), fruto de uma trajetória de evolução da racionalidade instrumental para a racionalidade substantiva (DUDZIAK, 2007).
A universidade, no contexto da plena integração entre as instituições, não vende inovação, mas produz conhecimento que potencialmente pode traduzir-se em inovação na indústria. Assim, o empreendedorismo acadêmico é, por um lado a extensão das atividades de ensino e pesquisa, e por outro lado, um processo de internalização da atividade de transferência tecnológica e de conhecimento. De acordo com Auxiliar (2010), a universidade empreendedora assenta-se em quatro pilares fundamentais:
1. Liderança acadêmica com capacidade de formular e implementar uma visão estratégia.
2. Autonomia patrimonial, administrativa e financeira. A universidade detém o controle legal dos recursos acadêmicos, incluindo a propriedade física e intelectual resultante da pesquisa acadêmica, e tem a capacidade para proceder a decisões e atos administrativos definitivos, com celeridade e flexibilidade adequadas a situações específicas.
3. Capacidade organizacional para transferir tecnologia através de patenteamento, licenciamento e incubação. A existência de estruturas acadêmicas dedicadas, com competências para procurar, promover e comercializar competências, projetos e resultados de pesquisas e investigações entre a universidade e o setor empresarial
4. Uma cultura empreendedora entre administradores, acadêmicos e estudantes.
Sendo a universidade incubadora de iniciativas empresariais e viveiro de novos ramos científicos e de novos setores industriais, a universidade empreendedora toma a iniciativa neste processo, tornando-se fonte de tecnologia, da mesma forma que o é de recursos humanos e conhecimentos, utilizando suas competências de investigação e ensino, em áreas avançadas de ciência e tecnologia, para a promoção de inovação.
2.3 O QUE É ENGENHARIA?
Segundo a enciclopédia britânica, engenharia é a aplicação da ciência para a conversão ótima dos recursos naturais para os usos da humanidade (ENCYCLOPÆDIA BRITANNICA, 2018). Já a Academia Real de Engenharia (ROYAL ACADEMY OF ENGINEERING, 2018) propõe uma definição igualmente extensional, porém tão abrangente que praticamente engloba toda atividade humana.
É Callaos (2018), em seu trabalho intitulado The Essence of Engineering and
Meta-Engineering: A Work in Progress, quem dá o primeiro passo para uma
definição intensional da engenharia – exposta aqui e base para a contextualização da engenharia no processo ARES –, estruturando suas características necessárias e suficientes, comuns em suas diferentes disciplinas e contextos.
Utilidade: O ato de produzir coisas úteis ou gerar benefícios para a humanidade é condição necessária (porém não suficiente) para a atividade de engenharia.
Know-how e know-that (Techné e Scientia): O conceito geral de aprendizagem através da experiência remonta ao berço da filosofia ocidental. Aristóteles em sua ética a Nicômaco escreveu que “as coisas que temos que aprender antes de
podermos fazê-las, aprendemos fazendo-as” (ARISTÓTELES, 1999). O filósofo da
língua inglesa, Ryle, categoriza esse aprendizado como know-how – saber fazer ou conhecimento técnico, techné – diferenciando este do que ele chamou de know-that – saber fatos, scientia. Know-that e know-how estão intimamente interligados na
engenharia, de fato é impossível desenvolver um software, por exemplo, que certamente precisa de know-how, sem conhecer as regras da linguagem de programação escolhida e os requisitos a serem atendidos pelo software, bem como suas entradas e saídas, que são instâncias do know-that. Para Callaos (2018),
know-how, enquanto conhecimento metodológico e processual/procedimental, faz
parte da essência da engenharia e, como tal, é condição necessária nas atividades de engenharia, mas não suficiente para defini-la unicamente. Scientia e techné são duas dimensões diferentes da engenharia.
Conhecimento tácito: Uma vez que a engenharia, principalmente em sua fase de
design, é uma atividade extremamente criativa (MALPAS, 2000), a intuição
(conhecimento tácito, não-proposicional) é ingrediente – e condição necessárias – de muitas de suas práticas. O conhecimento tácito (POLANYI, 1962) está intrinsicamente embutido nas atividades da engenharia; representações visuais, como imagens e diagramas, ajudam a expor o conhecimento tácito, incorporado à experiência como conhecimento pessoal e resultante da prática individual.
Prática e praxis: Sendo o conhecimento tácito/pessoal e o know-how/techné condições necessárias nas atividades da engenharia, torna-se evidente que a prática/praxis também é condição necessária para a engenharia; tanto para adquirir novos conhecimentos tácitos e apoiar o know-how e o conhecimento de processo, quanto para gerar techné, a fim de produzir a coisa técnica ou artificial, i.e., artefatos.
Das propriedades acima descritas, define-se engenharia como “o desenvolvimento de novos conhecimentos (scientia), novas “coisas feitas” (techné) e/ou novas formas de trabalhar e fazer (praxis) com o propósito de criar novos produtos úteis (artefatos) ou serviços” (CALLAOS, 2018).
Scientia, techné e praxis, figura 2.6, são três dimensões imprescindíveis para
Figura 2.6 - Relação entre engenharia, scientia, techné e praxis
Fonte: CALLAOS, 2018
A engenharia como scientia, ou mais especificamente como scientia
ingenieriae, é desenvolvida principalmente na academia; como techné é praticada
principalmente na indústria gerando inovações tecnológicas; e como praxis é realizada tanto em organizações técnicas quanto não-técnicas, apoiando atividades gerenciais e procedimentos técnicos, por meio de design e implementação metódico e metodológico.
2.3.1.1 Engenharia, ciência e indústria
As interrelações entre engenharia, ciência e indústria, sumarizadas na figura 2.7, ocorrem em ciclos de feedback baseados na combinação dos diferentes tipos de conhecimentos envolvidos na atividade de engenharia, e em ciclos de feedback mediados pela criação de valor, tendo a engenharia como elemento de ligação, ou uma ponte, entre a academia (representada pela ciência) e a indústria.
Figura 2.7 - Interação entre engenharia, ciência e organizações industriais e empresariais
Engenharia e ciência: O conhecimento científico é um conhecimento sobre fatos (know-that), descritivo/declarativo e proposicional, apoiado em lógica. A engenharia é nutrida por esse tipo de conhecimento, mas também precisa do conhecimento prescritivo, procedimental e não-proposicional. Destarte, as relações dialéticas geradas entre ciência e engenharia removem qualquer relação hierárquica entre elas; não a ciência nem superior nem inferior à engenharia. As atividades científicas e de engenharia estão relacionadas umas às outras e integradas num todo mais abrangente (figura 2.7), no qual a ciência fornece o conhecimento proposicional que as atividades e pensamentos de engenharia precisam como um de suas entradas; e os processos e tecnologias produzidos pela engenharia apoiam as atividades científicas e proporcionam um processo científico racional e uma possível base para reflexões filosóficas.
De acordo com essa perspectiva, Callaos (2018) advoga que as atividades científicas e de engenharia podem ser relacionadas, tal qual apresentado na figura 2.8, por meio de feedback e de feedforward, a fim de gerar sinergias mútuas em que o todo seria maior que a soma de suas partes.
Figura 2.8 - Relação engenharia/ciência
Fonte: CALLAOS, 2018
Engenharia e indústria: Os produtos de engenharia, para tornassem realmente utilizados (coisa útil em uso) e, assim exercer seus impactos sobre a criação de valor/riqueza e trazer benefícios para a humanidade, requerem a processos industriais e empresariais/comerciais. Os processos de engenharia interagem com os processos industriais e empresariais a fim de transformar o conhecimento de engenharia, apoiado em suas três dimensões (scientia, technê e praxis), em inovações tecnológicas e bens e serviços. Cabe ressaltar que a relação entre as organizações industriais e empresariais e a engenharia, esquematizada na figura 2.9, ocorrem por meios complementares e sinérgicos similares aos das relações entre ciência e engenharia – por feedback positivo e feedforward.
Figura 2.9 - Relação engenharia/organizações industriais e empresariais
3 PROBLEMATIZAÇÃO
A pesquisa aplicada, em sua realização prática da ciência, acessa parte dos conhecimentos, métodos, técnicas e tecnologias acumulados no acervo da academia com uma finalidade específica, que anseia a inovação. Intuitivamente, pode-se pensar que a pesquisa aplicada advém diretamente da pesquisa básica, e que prossegue para a invenção, e desta para a inovação. Entretanto, a progressão da pesquisa parece abranger várias etapas intermediárias e o desenvolvimento de elementos de múltiplas tecnologias, que se combinam no produto da invenção e inovação, retratando a complexidade desordenada do “mundo real” em seu entorno. Em seu intento, os agentes de inovação e motores da pesquisa aplicada – universidades e instituições científicas e tecnológicas (ICTs) – empenham-se na busca e no uso de metodologias que tragam transparência e solidez ao processo de inovação (CELEST et al., 2014).
Segundo Dudziak (2007, p. 48), “a tecnologia, sendo produtora e produto do
processo de inovação, reflete o grau de conhecimento acumulado, o conjunto de competências e a capacidade de aprendizado que uma organização mobiliza em um dado momento. A capacidade tecnológica seria aumentada a partir do aprendizado contínuo, que alimentaria as competências essenciais e as capacidades dinâmicas”. Partindo desta perspectiva e sob a ótica da pesquisa
aplicada de engenharia, define-se inovação como um processo de transformação resultante das competências e das tecnologias acumuladas, obtidas a partir do conhecimento tácito e explícito acumulados como resultado do aprendizado e da pesquisa continuada.
Sob a luz da prospecção, internalização, apropriação, transformação e transferência do conhecimento, preposto da pesquisa continuada e atributo da capacidade motriz de inovação a uma organização, e da busca por solidez e transparência nos procedimentos e métodos aplicados ao empreendimento de inovação, conduziu-se uma investigação de um cânone de metodologias da engenharia de sistemas. Uma busca por um caminho, dentro do ambiente da pesquisa aplicada de engenharia, para a inovação.
3.1 ANÁLISE E INVESTIGAÇÃO
Da miríade de processos, metodologias e meta-processos investigados, algumas características desfavoráveis, contraproducentes à pesquisa continuada e a inovação, parecem permear grande parte do universo de metodologias. Dessas características, destacam-se:
• A forte ligação com um conjunto específico de ferramentas e/ou linguagens que, num mecanismo similar ao relativismo linguístico (WHORF, 1980), limita a criação de artefatos e de conhecimento, visto ser necessário o domínio da sintaxe, semântica e pragmatismo da ferramenta e/ou linguagem específica para que hajam efetivas contribuições dos participantes e membros da pesquisa.
• O vínculo patente com a disciplina da engenharia de software que, principalmente naquelas ditas ágeis, parece desassistir as demais disciplinas da engenharia.
• A ausência de um mecanismo explícito sobre a prospecção, internalização, apropriação, transformação e transferência do conhecimento que fere o princípio basilar de uma pesquisa continuada.
Entretanto, dos objetos estudados, uma metodologia, um framework e um processo se destacam dos demais por apresentarem qualidades únicas que prefiguram trilhar o caminho da inovação no contexto da pesquisa aplicada de engenharia, a saber: Object-Oriented Systems Engineering Method (OOSEM),
Rational Unified Process for System Engineering (RUP SE), Feature-Driven Development (FDD).
3.1.1 Object-Oriented Systems Method (OOSEM)
A metodologia OOSEM (ESTEFAN et al., 2008) fornece um framework integrado que combina técnicas de orientação a objetos (OO), uma abordagem de
design baseada em modelos e práticas tradicionais top-down de engenharia de
Group Unified Modeling Language ™), a OOSEM foi realinhada com a linguagem
SysML® (Object Management Group System Modeling Language ™) em 2006 e é atualmente recomendada como um exemplo de boas práticas e o paragone das metodologias baseadas em modelos. A descrição detalhada da OOSEM é fornecida pela INCOSE em seu Systems Engineering Handbook (INCOSE, 2015).
Os objetivos dessa metodologia são:
• Capturar informações em todo o ciclo de vida suficientes para especificar, analisar, projetar, verificar e validar o sistema.
• Integrar a engenharia de sistema baseada em modelos (Model-Based
System Engineering – MBSE) com métodos OO de software, hardware, e de
outras disciplinas da engenharia.
• Suportar a reutilização a nível de sistema e a evolução/mutação do design. As fases e atividades definidas na OOSEM, apresentadas na figura 3.1, são praticadas sobre um ciclo de vida “Vee” recursivo e aplicadas iterativamente em cada nível de hierarquia do sistema.
Figura 3.1 - Fases e atividades da metodologia OOSEM
Análise das necessidades das partes interessadas: Neste primeiro grupo de atividades, os requisitos (necessidades/desejos) das partes interessadas (stakeholders) para o sistema são reunidos e analisados usando-se de uma abordagem de design “orientado para o uso” (usage-driven); definindo interações do usuário com o sistema e elaborando casos de uso (use-cases) em cenários operacionais definidos na terminologia nativa do usuário final. Esta atividade captura as características do sistema atual (se existir) em termos das partes interessadas, do contexto do negócio, do uso e do design. Esta análise ajuda a identificar os candidatos à reutilização (do sistema atual ‘as-is’ ao sistema proposto ‘to-be’), documentar procedimentos e doutrinas operacionais relevantes, e revelar aspectos do sistema atual que podem ser melhorados.
Definição dos requisitos do sistema: O método de “orientação ao uso”, empregado na análise das necessidades das partes interessadas, gera casos de uso e diagramas de cenários que descrevem o comportamento pretendido do sistema. Os requisitos do sistema são então modelados e definidos dessa maneira, começando com a definição do sistema como uma “caixa-preta” que interage com outros sistemas e com os usuários. A partir dessas interações e cenários, é possível consolidar um conjunto mínimo de funções de alto nível para o sistema. Essas funções constituem o ponto de partida para a arquitetura e design.
Definição da arquitetura lógica: Esta atividade consiste em decompor e particionar o sistema em componentes lógicos, que capturam as funcionalidades do sistema, que interagem para satisfazer seus requisitos. Os cenários lógicos preservam as interações do sistema em “caixa preta” com o ambiente. Além disso, as funcionalidades dos componentes lógicos são re-particionadas com base em critérios tais como coesão, acoplamento, confiabilidade e desempenho.
Síntese da arquitetura alocada: Na metodologia OOSEM, as arquiteturas físicas candidatas são constituídas por nós, que representam a agregação de componentes físicos em um local específico. Os componentes lógicos do sistema são então alocados nesses nós físicos. Esses nós físicos são tipicamente definidos em termos de hardware, software, dados ou componentes de procedimento manual.
A forma como os nós estão conectados pode ser baseada em designs existentes ou arquiteturas de referência.
Otimização e avaliação de alternativas: Esta atividade é invocada em todas as demais fases e atividades da metodologia OOSEM para otimizar as arquiteturas candidatas e realizar estudos de mercado para selecionar arquiteturas. Modelos paramétricos para modelagem de desempenho, confiabilidade, disponibilidade e outras preocupações da engenharia especializada são utilizados na análise, comparação e otimização das arquiteturas candidatas.
Verificação e validação do sistema: Esta atividade destina-se a verificar se o
design do sistema satisfaz os requisitos e validar se os requisitos atendem às
necessidades e desejos das partes interessadas. Planos, procedimentos e métodos de verificação, a exemplo da inspeção, demonstração e testes, são desenvolvidos. Casos de uso, cenários e requisitos associados em nível de sistemas são as entradas primárias para o desenvolvimento de casos de teste e de procedimentos de verificação. Durante esta atividade, os requisitos do sistema e informações de
design são rastreados para os métodos de verificação do sistema, casos de teste e
resultados.
3.1.1.1 Análise e características da metodologia OOSEM
Tão universais quanto os conceitos de OO empregados na OOSEM podem ser, quando combinados e aplicados em sistemas complexos, ou em sistema-de-sistemas, apresentam uma curva de aprendizado significativa para aqueles que não estão familiarizados com a terminologia e abstrações da engenharia de software. Mesmo que haja um paralelo imediato nas mais diversas disciplinas da engenharia para conceitos como herança e instanciação, isso não implica dizer que um pesquisador ou engenheiro conseguirá enxergar ou mesmo fazer uso de uma abstração OO. Em certo sentido, um objeto na percepção e cognição humana é apenas uma maneira de ver o mundo dentre muitas possíveis, e a “orientação a objetos” impede o uso de múltiplas visões sobre o problema ou o uso de transformações lógicas ou funcionais.
Um modelo OO é a decomposição do domínio do problema em classes ou interfaces e relações, de modo que a capacidade para suportar visões múltiplas exigiria a capacidade de alterar/trocar facilmente entre diferentes decomposições de classes e relações, o que violaria o encapsulamento. Se o conceito de concorrência for adicionado a este contexto, o aporte de múltiplas visões numa modelagem OO se tornaria ainda mais complicada e contra intuitiva.
Outro aparente problema da abordagem OO da metodologia OOSEM, reside na definição dos requisitos ditos não-funcionais, a exemplo dos requisitos de desempenho, confiabilidade, segurança, disponibilidade, etc. Nesta abordagem, os requisitos não-funcionais se apresentam geralmente de maneira incompleta ou vaga sobre as condições de operação contra as quais precisam ser alcançadas. Esta ambiguidade muitas vezes leva o designer a fazer suposições sobre as condições implícitas em um requisito, o que pode levar a uma solução que não executa a operação da maneira pretendida.
Na definição dos requisitos do sistema, a metodologia utiliza uma aproximação bastante didática e intuitiva. Definindo-se um sistema como uma “caixa-preta” primeiro, pode-se descrevê-lo em termos de suas interações com o ambiente e com entidades externas (através de diagramas de contexto, casos de uso e cenários); a ênfase é colocada na identificação e definição de interfaces, propriedades e uso do sistema num contexto mais amplo, delimitando o problema que se quer resolver, sem prefixar uma solução particular.
Desenvolver e visualizar um design em diferentes níveis de abstração pode ajudar a lidar e gerenciar a complexidade do sistema. Sendo assim, uma abstração é usada com o propósito de revelar apenas informações e propriedades do sistema pertinentes para um determinado nível, escondendo detalhes de baixo nível irrelevantes para o propósito da abstração. Mesmo que não explicitamente, a metodologia OOSEM traz a análise das necessidades das partes interessadas, capturadas como declarações e diagramas de alto nível, como a representação mais abstrata do sistema. O que faz da arquitetura física, detalhada em esquemáticos e artefatos de engenharia, a representação de menor abstração para um sistema. No entremeio destas abstrações, a OOSEM aporta uma arquitetura
funcional, composta por descrições independentes de solução, e uma arquitetura lógica, que descreve soluções em termos de componentes lógicos. Estes componentes representam as tecnologias e a implementação da abstração independente de componentes físicos, restando a arquitetura física definir uma implementação específica para o design correspondente a uma arquitetura lógica particular.
3.1.2 Rational Unified Process for System Engineering (RUP SE)
O framework RUP® oferece uma estrutura para racionalizar as atividades relacionadas ao ciclo de vida de desenvolvimento de software. Desde sua estreia formal em 1996, o RUP® sofreu, e vem sofrendo, mudanças para suportar uma variedade de requisitos de desenvolvimento, incluindo a disciplina de engenharia de sistemas. Neste sentido, o plug-in RUP SE® (CANTOR, 2003), criado em 2001, foi desenvolvido para abordar os problemas e requisitos relacionados ao design de sistemas dentro do ambiente RUP. O objetivo do RUP SE é dar suporte às equipes de engenharia de sistemas na medida em que elas determinam e delimitam o sistema em “caixa-preta” e especificam um design do sistema em “caixa-branca” (e.g., estrutura interna do sistema, seus elementos, componentes e partes) que atende os requisitos das partes interessadas. Em particular, o RUP SE abrange:
• Um framework de arquitetura, que descreve os elementos internos de um sistema (elementos de arquitetura) de vários pontos de vista;
• Um conjunto de artefatos baseados em UML e/ou SysML para modelagem da arquitetura do sistema; e
• Uma metodologia, denominada use-case flowdown, que deriva e desdobra requisitos para elementos de design e arquitetura.
O framework RUP SE para a arquitetura do sistema é implantado em duas dimensões distintas, nível de modelo e ponto de vista (BALMELLI et al., 2006), relacionadas no quadro 3.1.
Quadro 3.1 - Dimensões do framework RUP SE
Nível de modelo
Um nível de modelo é definido como um subconjunto do modelo de arquitetura que representa certo nível de especificidade; níveis mais baixos apresentam mais especificidade e capturam escolhas tecnológicas. Níveis de modelo são elementos projetados para agrupar artefatos com níveis similares de detalhes e abstração.
O nível de contexto considera todo o sistema como uma única entidade, um sistema “caixa-preta”, endereçando as interações do sistema com entidades externas e com o meio. No nível de análise, os elementos internos do sistema são identificados e descritos num nível de abstração relativamente alta (sistema em “caixa-branca”). A construção desses elementos varia, dependendo do ponto de vista específico. Por exemplo, no ponto de vista lógico, subsistemas são criados para representar elementos de funcionalidades numa abstração de alto nível.
No nível de design, as decisões que direcionarão a implementação são capturadas. Na transição entre o nível de análise e o nível de design, subsistemas, classes, e a distribuição dos recursos físicos (localities) são transformados em
hardware, software, etc. Cabe notar que a transição entre os níveis de análise e design não se trata de um mapeamento direto dos elementos do sistema para design; representa, em contrapartida, decisões de design, balizadas por requisitos
derivados e escolhas de distribuição, representadas pelas localidades (localities) e suas características. Ou seja, é no nível que análise que a arquitetura do sistema é definida e especificada, criando requisitos que o nível de design deve satisfazer.
No nível de implementação, as decisões sobre escolhas técnicas e tecnológicas para a implementação são capturadas. Como antes, a transição entre os níveis de design e implementação é uma transformação. Porém, diferente das transformações anteriores, onde a transição entre níveis geralmente acarreta na decomposição dos componentes dos modelos, neste nível o mapeamento é mais direto, onde, no geral, um componente de design é transformado em um componente de implementação.
