UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Transferência de Tecnologia entre Academia e
Indústria em Engenharia de Software: Um
Mapeamento Sistemático
Por
RAMON NOBREGA TENÓRIO
Dissertação de Mestrado Profissional
Universidade Federal de Pernambuco
[email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE
2014
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RAMON NOBREGA TENÓRIO
Transferência de Tecnologia entre Academia e Indústria
em Engenharia de Software: Um Mapeamento
Sistemático
Este trabalho foi apresentado à Pós-Graduação
em Ciência da Computação do Centro de
Informática
Pernambuco
da
Universidade
como
requisito
Federal
parcial
de
para
obtenção do grau de Mestre Profissional em
Ciência da Computação.
Orientador: Prof. Sérgio Castelo Branco Soares
RECIFE
2014
Catalogação na fonte
Bibliotecária Joana D’Arc L. Salvador, CRB 4-572
Tenório, Ramon Nobrega.
Transferência de tecnologia entre academia e
indústria em engenharia de software: um mapeamento
sistemático / Ramon Nobrega Tenório. – Recife: O Autor,
2014.
142 f.: fig., tab., graf., quadro.
Orientador: Sergio Castelo Branco Soares.
Dissertação (Mestrado Profissional) - Universidade
Federal de Pernambuco. CIN. Ciência da Computação,
2014.
Inclui referências e apêndices
1. Engenharia de software. 2. Transferência de
tecnologia. I. Soares, Sérgio Castelo Branco (orientador).
II. Título.
005.1
(22. ed.)
MEI 2014-110
Dissertação de Mestrado Profissional apresentada por Ramon Nobrega Tenório à
Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade
Federal de Pernambuco, sob o título, “Transferência de Tecnologia entre Academia
e Indústria em Engenharia de Software: Um Mapeamento Sistemático”, orientada
pelo Professor Sérgio Castelo Branco Soares e aprovada pela Banca Examinadora
formada pelos professores:
_______________________________________________
Prof. Kiev Santos da Gama
Centro de Informática / UFPE
______________________________________________
Prof. Maria da Conceição Moraes Batista
Universidade Federal Rural de Pernambuco
_______________________________________________
Prof. Sérgio Castelo Branco Soares
Centro de Informática / UFPE
Visto e permitida a impressão.
Recife, 30 de abril de 2014.
___________________________________________________
Profª. EDNA NATIVIDADE DA SILVA BARROS
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
Dedico este trabalho à meus familiares e à
minha esposa, por me proporcionarem o
apoio necessário durante toda a
caminhada.
AGRADECIMENTOS
O hoje está melhor do que o ontem, o tempo passa, as coisas mudam, a
perspectiva gera pensamentos e direções. Chegamos a exaustão por não
percebermos quão melhores nós somos diante do desafio que espreita. Agradeço a
Deus por proporcionar um plano para a minha existência, por me tornar útil para a
obra que está por vir e por me dar suporte com o que preciso para alcançar o lugar
que é de direito.
Agradeço a meus pais e meu irmão. Estes em que a presença sempre alegra
a minha alma e que nunca titubearam quando o assunto era a minha vida, vida essa
com todas as suas características.
Agradeço a minha esposa amada por estar comigo em todos os momentos
deste trabalho, proporcionando o apoio que precisei. Feliz é o homem que, durante a
sua existência, consegue encontrar a parte que o torna completo.
Agradeço ao meu Orientador, o Professor Sérgio Castelo Branco Soares pela
oportunidade de vivenciar a academia, por abrir o caminho para o conhecimento e
proporcionar acesso à pesquisa.
Agradeço a todos os colegas do grupo de pesquisa que constribuiram para a
realização deste trabalho. Um obrigado à Adauto Trigueiro, Helaine Lins, Diogo
Vinícios e em especial Emanoel Barreiros, por me ajudar em todas as fases deste
estudo e por atuar de forma eficaz para que este trabalho viesse à tona.
Agradeço ao meu amigo Carlos Vasconcelos, amigo para todas as horas.
Agradeço a empresa Dapal Distribuidora por me apoiar durante todo o
mestrado.
Enfim, só tenho agradecimentos!
“E o SENHOR apareceu-lhe e disse: Não
desças ao Egito; habita na terra que eu te
disser.”
Gênesis 26:3
RESUMO
A transferência de tecnologia é o processo pelo qual a indústria se mantém em
constante evolução e competitividade. Esta atividade proporciona um modo em que
as empresas possam alcançar maior efetividade no uso de seus recursos, provendo
informação e auxílio, que conduz a melhorias em diversas áreas do negócio. Em
engenharia de software, o processo tende a ser laborioso, dependente de condução
rigorosa e de fatores (ou influenciadores), que geralmente estão inclinados a assumir
papel decisivo quando do momento da adoção. Evidência contundente, benefício
claro, apoio organizacional e treinamento são alguns dos muitos fatores que podem
atuar com protagonismo e mudar o curso da atividade. A parceria entre academia e
indústria é propensa a ser uma fonte fértil para inovações tecnológicas de forma a
saciar o anseio do mercado e impulsionar a criação de novas ideias e visões
renovadas. Este estudo tem como objetivo a coleta e investigação do conhecimento
disponível na literatura, de forma sistemática, que tenham relação com fatores que
influenciam positiva ou negativamente a transferência de tecnologia entre academia e
indústria no campo da engenharia de software, assim como as abordagens existentes.
De modo a alcançar o objetivo, foi utilizado, como método de pesquisa, o estudo de
mapeamento sistemático. Este mapeamento obteve um total de 6228 estudos, por
meio de buscas automatizadas e manuais, dentre os quais 87 estudos primários foram
identificados como relevantes e classificados de acordo com as perguntas de
pesquisa. Com base na análise realizada, conclui-se que a transferência de tecnologia
em engenharia de software é uma atividade que envolve fatores tecnológicos,
organizacionais, culturais e sociais e que estes têm influência em todo o processo.
Além disso, fatores pouco explorados foram identificados, proporcionando abertura à
condução de novos estudos.
PALAVRAS-CHAVE: Engenharia de Software, Engenharia de Software Baseada em
Evidências, Estudo de Mapeamento Sistemático, Transferência de Tecnologia.
ABSTRACT
Technology transfer is the process by which the industry remains in constant evolution
and competitiveness. This activity provides a way in which companies can achieve
greater effectiveness in the use of its resources, providing information and assistance,
which leads to improvements in various areas of business. In software engineering,
the process tends to be laborious, dependent on accurate conduction and affecting
factors (or influencers), which are generally inclined to take decisive role in the
adoption process. Striking evidence, clear benefit, organizational support and training
are some of the many factors that have an effect on and change the course of the
activity. The partnership between academia and industry is likely to be a fertile source
for technological innovations in order to satisfy the markest’s longing and boost the
creation of new ideas. This study aims at collecting the available knowledge in the
literature in a systematic manner, regarding factors that influence positively or
negatively technology transfer between academia and industry in the field of software
engineering, as well as existing approaches. In order to achieve the objective, was
used as the research method the systematic mapping study. This mapping
investigated a total of 6228 studies, through automated and manual searches, among
which 87 primary studies were identified as relevant and ranked according to the
research questions. Based on the analysis, it is possible to conclude that technology
transfer in software engineering is an activity that involves technological,
organizational, cultural and social factors and that these have an influence on the
whole process. Moreover, poorly explored factors were identified, providing openness
to conducting new studies.
KEYWORDS: Software Engineering, Evidence Based Software Engineering,
Systematic Mapping Study, Technology Transfer.
LISTA DE FIGURAS
Figura 2.1 – Interação entre componentes do processo de inovação ................ 7
Figura 2.2 – Categorização de indivíduos com base no grau de inovação........ 9
LISTA DE TABELAS
Tabela 4.1 – Resumo dos estudos por fator positivos encontrado ................... 32
Tabela 4.2 – Resumo dos estudos por fator negativo encontrado ................... 35
Tabela 4.3 – Resumo dos estudos por abordagem encontrada ....................... 37
LISTA DE QUADROS
Quadro 2.1 – Exemplos dos Modelos que Encorajam a Transferência de Tecnologia
........................................................................................................................... 8
Quadro 3.1 – Classificação da Pesquisa .......................................................... 16
Quadro 3.2 – Classificação segundo Cooper ................................................... 18
Quadro 3.3 – String para a realização das buscas automatizadas .................. 22
Quadro 4.1 – Evolução do processo de seleção .............................................. 29
LISTA DE GRÁFICOS
Gráfico 4.1 – Resultado da busca automatizada .............................................. 26
Gráfico 4.2 – Resultado da busca manual ....................................................... 27
Gráfico 4.3 – Resultado da busca automatizada e manual juntas.................... 28
Gráfico 4.4 – Resultado da seleção de estudos potencialmente relevantes .... 28
Gráfico 4.5 – Representatividade por país ....................................................... 30
Gráfico 4.6 – Tipos de fatores positivos identificados ...................................... 31
Gráfico 4.7 – Tipos de fatores negativos identificados ..................................... 34
Gráfico 4.8 – Tipos de abordagens identificadas ............................................. 36
LISTA DE ABREVIATURAS/ACRÔNIMOS
ES
Engenharia de Software
EBSE
Evidence-based Software Engineering
RSL
Revisão Sistemática da Literatura
RS
Revisão Sistemática
EMS
Estudo de Mapeamento Sistemático
QP
Questão de Pesquisa
SUMÁRIO
1. INTRODUÇÃO .......................................................................................... 15
1.1
Enfoque do Estudo .............................................................................. 16
1.2
Objetivos ............................................................................................. 17
1.3
Estrutura da Dissertação ..................................................................... 17
2. REFERENCIAL TEÓRICO ........................................................................ 19
2.1
Transferência de Tecnologia ............................................................... 19
2.2
Transferência de Tecnologia em Engenharia de Software.................. 25
2.3
Engenharia de Software Baseada em Evidência ................................ 27
2.4
Resumo ............................................................................................... 31
3. METODOLOGIA ........................................................................................ 32
3.1
Classificação da Pesquisa .................................................................. 32
3.1.1
3.2
Classificação Segundo Cooper..................................................... 33
Ciclo da Pesquisa ............................................................................... 36
3.2.1.
Mapeamento Sistemático ............................................................. 37
3.2.2.
Escopo e Questões de Pesquisa .................................................. 37
3.2.3.
Estratégia de Busca...................................................................... 37
3.2.4
Processo de Busca ....................................................................... 38
3.2.5
Critérios de Inclusão/Exclusão e Procedimentos de Seleção ....... 39
3.2.6
Extração dos Dados ..................................................................... 39
3.2.7
Síntese dos Dados ....................................................................... 40
3.3
Resumo ............................................................................................... 40
4. RESULTADOS .......................................................................................... 41
4.1
Extração e Análise dos Dados ............................................................ 41
4.2
Resumo dos Resultados ..................................................................... 46
4.3
Mapeamento das Evidências .............................................................. 53
4.3.1.
Fatores Positivos .......................................................................... 53
4.3.2.
Fatores Negativos......................................................................... 77
4.3.3.
Abordagens .................................................................................. 94
4.4
Discussão sobre os Resultados .......................................................... 98
4.5
Resumo ............................................................................................. 101
5. CONSIDERAÇÕES FINAIS .................................................................... 102
5.1
Ameaças a Validade ......................................................................... 102
5.2
Trabalhos Futuros ............................................................................. 103
5.3
Conclusões ....................................................................................... 103
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................. 106
APÊNDICE A - ESTUDOS PRIMÁRIOS........................................................ 113
APÊNDICE B - ESTUDOS EXCLUÍDOS ....................................................... 121
APÊNDICE C – PROTOCOLO DO MAPEAMENTO SISTEMÁTICO ............ 131
1. INTRODUÇÃO
A engenharia de software está notadamente presente em grande parte
dos artefatos tecnológicos que regem diversas atividades na atualidade. Existem
vertentes em que um único equívoco na produção de software pode resultar em
ameaça à vida, outros podem ser motivadores para que empresas não mais
existam. Cenários como estes, que geram impacto, tendem a impulsionar a
aplicação de processos mais rigorosos, seja da parte de quem produz ou do lado
de quem recepciona a tecnologia. Deve-se enfatizar que uma tecnologia adotada
inadequadamente pode resultar em perdas importantes (BUXTON; MALCOLM,
1991).
A inovação, como a introdução de algo novo ou a modificação de algo já
existente (COOKE; MAYES, 1996), em engenharia de software, assim como o
seu processo de melhoria e amadurecimento, tem estado dependente de quão
bem são conduzidas as atividades que compõem a transferência tecnológica. O
estudo de Redwine e Riddle (1985), um dos primeiros a tratar da temática em
computação, relata que estas atividades podem durar um longo período de
tempo. No melhor caso, pode alcançar cerca de 11 anos para que uma
tecnologia em engenharia de software amadureça a ponto de ser disseminada e
amplamente
utilizada.
Este
período,
em
ambientes
de
produção
e
competitividade, como é praticado na indústria, é considerado impraticável e o
mercado tende a não esperar mais de uma década para que a inovação possa
ocorrer (PFLEEGER, 1999).
O processo de transferência de tecnologia entre academia e indústria
transcorre ao se conduzir um modelo prático que possa atestar a aplicabilidade
dos resultados gerados em uma pesquisa cientifica e produzir uma solução, com
a tecnologia-alvo embarcada, que seja, aplicada no ambiente corporativo, ou
seja, que este resultado de pesquisa possa gerar uma tecnologia aplicável ao
ambiente de produção (PUNTER et al., 2009). Entretanto, em meio aos passos
necessários para a sua realização, existem fatores que influenciam a adoção da
nova tecnologia e, em certos casos, estes podem exercer papel preponderante
quando da tomada de decisão (LARSSON et al., 2006). Seguindo o mesmo
raciocínio, há uma tendência mercadológica em tentar simplificar todo o
15
processo de transição e atender a pressão exercida pela indústria (RAGHAVAN;
CHAND, 1989), principalmente quando existe interesse acentuado por parte do
receptor, ocasionando, possivelmente, em adoções não plenamente realizadas
por falta de adequação ao tipo de atividade ou, em tecnologias sem maturidade
suficiente para serem colocadas em ambientes de produção.
Os fatores que influenciam a transferência tecnológica têm pouca
serventia se não forem estudados de forma a auxiliar a melhoria da transferência
tecnológica, que é considerado um processo longo, complexo e repleto de
dificuldades em todos os estágios, onde o menor problema pode ocasionar em
um resultado não satisfatório (BUXTON; MALCOLM, 1991).
Este trabalho tem como motivação a necessidade da produção de
conhecimento sobre fatores que influenciam a transferência tecnológica entre
academia e indústria no campo da engenharia de software, bem como a
identificação das abordagens existentes na condução da atividade, de forma a
servir de auxílio para o amadurecimento e maior efetividade do processo.
1.1
Enfoque do Estudo
De acordo com o que foi apresentado, o problema cerne da
pesquisa é definido como: “Quais são os fatores que
influenciam positiva e negativamente a transferência
tecnológica entre academia e indústria no campo da
engenharia de software?”.
Apoiado por esta questão principal, a pesquisa tem como propósito
investigar o processo de transferência tecnológica realizado entre a academia,
como quem produz a tecnologia, e a indústria, como quem a recepciona, no
contexto da engenharia de software, assim identificando os influenciadores e
abordagens existentes. Deste modo, dividimos a pesquisa em três questões, que
são:

QP1: Que fatores influenciam positivamente a transferência de
tecnologia entre academia e indústria em engenharia de software?
16

QP2: Que fatores influenciam negativamente a transferência de
tecnologia entre academia e indústria em engenharia de software?

QP3: Quais são as abordagens existentes para transferência de
tecnologia entre academia e indústria em engenharia de software?
1.2
Objetivos
Este trabalho tem como objetivo a coleta e investigação do conhecimento
disponível na literatura, de forma sistemática, relacionadas com fatores que
influenciem positiva ou negativamente o processo de transferência tecnológica
entre academia e indústria no campo da engenharia de software, assim como as
abordagens existentes.
Desta forma, os objetivos específicos deste trabalho são:

Identificar evidências na literatura sobre os fatores positivos que
influenciam a transferência de tecnologia entre academia e
indústria em engenharia de software;

Identificar evidências na literatura sobre os fatores negativos que
influenciam a transferência de tecnologia entre academia e
indústria em engenharia de software;

Identificar evidências na literatura sobre as abordagens existentes
em transferência de tecnologia entre academia e indústria em
engenharia de software.
1.3. Estrutura da Dissertação
Este trabalho está organizado da seguinte forma:

O Capítulo 2 apresenta o referencial teórico. De início, são
apresentados conceitos e teorias relacionados a Transferência de
Tecnologia. Em seguida a transferência de tecnologia no campo da
engenharia de software é contextualizada. Por fim, é abordada a
Engenharia de Software Baseada em Evidência com foco no
Mapeamento Sistemático;
17

O Capítulo 3 descreve a metodologia utilizada na condução do
estudo. A pesquisa é classificada, junto um quadro metodológico e os
principais passos da pesquisa. O protocolo é definido e os
procedimentos realizados no estudo de mapeamento são descritos;

O Capítulo 4 apresenta os resultados do estudo de mapeamento.
Também são apresentadas informações gerais em relação ao
processo de seleção dos estudos primários que participaram do
estudo. As perguntas de pesquisa são respondidas, a informação é
coletada e organizada;

O Capítulo 5 apresenta as limitações e ameaças a validade do
trabalho, assim como as considerações finais, conclusões obtidas por
meio deste estudo. Ao final trabalhos futuros são propostos.
18
2. REFERENCIAL TEÓRICO
Neste capítulo será apresentado o referencial teórico, conhecimento
necessário para a condução da pesquisa e entendimento do estudo realizado.
Deste modo, o capítulo apresenta os conceitos e teorias sobre a Transferência
de Tecnologia, aspectos relacionados a Transferência de Tecnologia no campo
da Engenharia de Software e os conceitos relacionados a Engenharia de
Software Baseada em Evidências.
2.1
Transferência de Tecnologia
Inicialmente, a transferência tecnológica foi vista como um processo
simples, com propósito de apenas mover máquinas, equipamentos e
ferramentas de um lugar à outro. O entendimento da matéria estava relacionado
de forma intrínseca ao passo de mover o material de quem produz para aquele
que o utiliza, assim, em decorrência desse tipo de entendimento, o mecanismo
despertava pouca atenção. A tecnologia era entendida simplesmente como um
material ou artefato, no sentido mais primitivo (LEVIN, 1993).
Com o passar do tempo, este processo ganhou atenção especial por ser
percebido como um diferencial mercadológico, muito por conta da intensa
competitividade que emergia resultante da descoberta de novos e aprimorados
produtos por parte do concorrente, assim relacionando-se diretamente à
sobrevivência das organizações (COOKE; MAYES, 1996). Ainda nessa lacuna,
a atividade começou a ser vista como o processo, todo ele, que visa transferir o
saber-fazer
(know-how)
tecnológico
daquele
que
cria
(por
exemplo,
universidades, centros de pesquisa e departamentos de P&D), para aquele que
recepciona, tal como empresas, que podem usar esta inovação diretamente ou
atuar como um parceiro no desenvolvimento e aprimoramento da tecnologia
(BURATTI; PENCO, 2001).
Vale ressaltar que o objetivo da transferência de tecnologia, como um
processo, não é diretamente o de fechar contratos ou promover lucro, mas o de
focar no conteúdo e em possíveis ganhos advindos da interação, que podem ser
recompensados no futuro. Neste ínterim, identifica-se a importância da parceria
entre academia e indústria, entre ciência e mercado, que tem como resultado a
19
promoção de avanços tecnológicos que podem impulsionar a criação de novas
ideias e estimular soluções e visões renovadas. Esta parceria, de um modo geral,
representa uma fonte fértil de inovações tecnológicas (HAMERI, 1996).
Entre outros trabalhos, pode-se definir a atividade de transferência
tecnológica como o processo pelo qual a indústria se mantém em constante
evolução e competitividade, garantindo que a produção, uma vez iniciada, seja
mantida e expandida. Esta atividade proporciona um modo em que as empresas
possam alcançar maior efetividade no uso de recursos humanos, físicos e
financeiros, provendo informação e auxílio, que conduz a melhorias em diversas
áreas do negócio (COOKE; MAYES, 1996; MORRISSEY; ALMONACID, 2005).
Por sua vez, Abramson et al. (1997) define transferência de tecnologia
como um movimento que conduz tecnologia ou saber-fazer (know-how)
relacionado a tecnologia entre parceiros de negócio (indivíduos, instituições e
empresas), afim de incrementar o conhecimento e experiência de no mínimo um
parceiro e reforçar a competitividade de cada um. Ressalta-se a importância não
somente da transição academia-indústria, mas também no sentido inverso, como
indústria-academia e indústria-indústria. Segundo Cooke e Mayes (1996), a
transição tecnológica ocorre por meio de todos os componentes relacionados a
inovação, desde uma ideia inicial até o produto final. De forma simples, se trata
da transação entre a mudança da tecnologia e da invenção (inovação), produção
e difusão. Assim como o processo de inovação o é, a transferência de tecnologia
também se trata de uma atividade iterativa, envolvendo diversos passos, e pode
surgir por meio de interações informais entre indivíduos, publicações,
workshops, intercâmbios, projetos envolvendo grupos de especialistas de
diferentes organizações, como também por atividades relacionadas a
patenteamento, licenciamento e contratação de pesquisa.
Ainda de acordo com Abramson et al. (1997) a transferência de tecnologia
abrange duas formas, a direta e a indireta. Contudo, as duas formas são
intimamente ligadas e, para que o processo ocorra de forma satisfatória,
independente por qual meio ocorra, a transferência tem que ser eficiente. A
seguir segue a caracterização das duas formas:
20

Transferência de Tecnologia Direta: Esta forma está relacionada
com tecnologias ou ideias específicas e por meio de canais com
maior visibilidade, como por exemplo os contratos ou projetos de
pesquisa em que haja cooperação. Em discussões relacionadas ao
tema, há uma forte tendência em olhar somente para este tipo de
transferência;

Transferência de Tecnologia Indireta: Esta forma está ligada à
troca de conhecimento por meio de canais de reuniões informais,
publicações ou workshops. O ato de publicar, em especial,
possibilita o acesso àqueles resultados de pesquisa ao gatekeeper,
indivíduo influente na organização que pode fazer a ponte entre a
tecnologia e a indústria.
Levin (1993), destaca em seu estudo que a transferência de tecnologia
está relacionada com os passos necessários para que o processo de inovação
ocorra e é considerado o meio necessário para que a inovação aconteça. Além
da relação, pode-se observar na Figura 2.1 que o processo é composto por
outros quatro componentes que atuam de forma iterativa, que são Invenção,
Inovação, Design e Difusão, e que a inovação tem se tornado o termo que
descreve todo o processo, abrangendo todos os fatores ao invés de ser apenas
um componente e que a transferência de tecnologia tem se tornado o meio para
que a inovação possa ser alcançada. Destaca-se também o papel da invenção,
porque se não há invenção, não há transferência tecnológica, afinal, não há
como transferir algo que não foi inventado (COOKE; MAYES, 1996).
Figura 2.1 – Interação entre componentes do processo de inovação
Fonte: Cooke e Mayes (1996)
21
Para Rogers (2003), a transição tecnológica é um processo de
comunicação que ocorre por meio da troca de informações a fim de estabelecer
um entendimento mutuo sobre o significado da tecnologia. Esta comunicação
ocorre em ambas as direções, seja por meio de um fluxo de possíveis erros
relacionados à tecnologia que são reportados pelos utilizadores ou através do
fluxo de inovação relacionado à tecnologia em uso.
Abaixo são listados os canais de comunicação em que a transferência de
tecnologia ocorre (ROGERS et al., 2001):

Spin-off: Se trata de uma empresa que é formada a partir de um grupo
de pesquisa de outra empresa com a tecnologia que foi transferida, ou
então, representa a transferência de uma inovação tecnológica para
uma nova empresa que é formada por motivo da inovação;

Licenciamento: Se trata da concessão de permissão ou direitos de
fazer, usar e/ou vender um certo produto, projeto ou processo, ou
executar outras ações;

Publicação: Artigos publicados em revistas acadêmicas são
frequentemente usados como meio para a ocorrência da transferência
tecnológica;

Reuniões: Se trata de interações pessoa-para-pessoa onde
informações técnicas são trocadas em relação à inovação;

Acordos de Cooperação em P&D: Destinam-se à transferência
tecnológica de laboratórios federais de pesquisa e desenvolvimento,
para companhias privadas que colaboram com a pesquisa.
Berniker (1991) identificou alguns modelos que podem encorajar a
transferência de uma tecnologia, exemplos podem ser vistos no Quadro 2.1. O
primeiro recebeu o nome de People-Mover Model, este depende de contato
pessoal entre quem desenvolve e quem utiliza, sendo considerado o mais efetivo
22
entre eles. O segundo, Communication Model, está relacionado a uma nova
tecnologia que é divulgada por meio impresso e notada por um indivíduo que
tenha influência (gatekeeper) em alguma organização. O terceiro modelo,
Quadro 2.1 – Exemplos dos Modelos que Encorajam a Transferência de Tecnologia
Modelos
A. People-Mover Model
B. Communication Model
C. On-The-Shelf Model
D. Vendor Model
Exemplos
Um conselho dado a outra pessoa; uma
recomendação a alguém com poder de decisão; a
utilização do artifício da persuasão.
Publicações em revistas científicas, relatórios
técnicos.
Uma aplicação com interface simples e agradável;
um manual de utilização de fácil manuseio e
completo.
Um software amplamente difundido e aceito serve
como instrumento para a adoção de outras
tecnologias da mesma empresa.
Fonte: Berniker (1991)
intitulado On-The-Shelf Model, trata de uma abordagem que depende do
material de apoio (packaging) e de quão fácil é a curva de aprendizagem para
que assim a tecnologia possa se tornar atraente aos usuários. E por último,
Vendor Model, onde a organização depende do sucesso de uma outra tecnologia
de sua autoria para que haja promoção de outras tecnologias.
Rogers (2003) delineia que o grau de inovação é aquele resultante da
medição de quão cedo um indivíduo ou unidade de adoção, especificamente,
adota uma nova ideia em relação a outro membro de um mesmo ambiente social.
A categorização de quem adota é realizada de acordo com o grau de inovação.
Observando a Figura 2.2 pode-se notar cada categoria e seu percentual de
ocorrência em relação as outras categorias.
23
Figura 2.2 – Categorização de indivíduos com base no grau de inovação
Fonte: Rogers (2003)
A categoria intitulada Innovators é descrita como uma categoria de
aventureiros, cujo interesse está voltado a novas ideias. Este tipo deve estar
preparado para lidar com um alto grau de incerteza relacionado a inovação do
momento em que é adotada e, diz respeito a 2,5% da provável audiência total
(ROGERS, 2003, p.282). Os Early Adopters dizem respeito a 13,5% da audiência
total. São mais integrados a cultura da organização e, mais do que qualquer
outro, tem um alto nível de liderança no ambiente organizacional. Geralmente,
aqueles em que estão em posição para realizar uma adoção consultam
indivíduos nesta categoria em busca de conselho e informação sobre a inovação.
Early Majority é aquele cuja decisão para adotar uma inovação só acontece após
pensar bem sobre o tema. Nesta categoria, composta por 34% da audiência total,
os indivíduos preferem seguir, ao invés de liderar outros. Entretanto, eles são
dispostos a tentar uma nova ideia quando a efetividade da tecnologia é
comprovada por outros (ROGERS, 2003, p.283). Late Majority é uma categoria
formada por indivíduos céticos e abrange 34% da audiência total. Nesta
categoria, a adoção pode ser resultado de pressão, seja econômica ou realizada
por colegas, contudo, toda incerteza ligada a ideia deve ser resolvida antes que
ocorra. Por fim, a categoria Laggards trata daqueles que somente adotam uma
nova ideia se for comprovado que esta não falhará ou quando há imposição por
parte dos superiores (ROGERS, 2003, p.284).
24
O processo de transferência tecnológica é, por natureza, uma atividade
complicada e demanda pessoas treinadas e habilidosas, bem como recursos e
estruturas adequadas (ROGERS et al., 2001). Além disso, delinear um processo
de transferência tecnológica como sendo adequado a todas as situações é
impossível, devido a inúmeros processos concorrentes existentes na literatura e
aplicados ao mercado (BOZEMAN, 2000).
2.2
Transferência de Tecnologia em Engenharia de Software
É inegável que a Transferência de Tecnologia é uma área de grande
relevância, ou até mesmo vital, em Engenharia de Software (RAGHAVAN;
CHAND, 1989; PFLEEGER, 1999; FOWLER; LEVINE, 1994; ZELKOWITZ,
1995; REDWINE; RIDDLE, 1985). Esta, por sua vez, como uma disciplina, está
diretamente relacionada ao desenvolvimento e não a produção do software e,
grande parte das tecnologias relacionadas a este campo são baseadas em
pessoas (LINKMAN; ROMBACH, 1997). Para que a transferência possa ocorrer,
é importante que haja uma boa ideia, evidências que comprovem o valor da
proposta, análise das evidencias encontradas, um bom material de apoio
(packaging) e a audiência adequada (PFLEEGER, 1999).
Em um dos primeiros estudos a tratar do assunto, Redwine e Riddle
(1985) por meio da coleta de estudos de caso sobre diversos conceitos e
tecnologias, perceberam que uma tecnologia para que amadureça e possa estar
pronta para ser colocada em prática, leva de 15 a 20 anos. No pior caso
identificado, foram necessários 23 anos da formulação do conceito ao ponto em
que a popularização possa ser considerada adequada. No melhor caso
identificado no estudo, este processo levou 11 anos. É evidente que este tempo
de espera é desproporcional quando se entende que o mercado de software
exige velocidade e a pressão por resultados é diária. Por motivos como estes,
muitas organizações aderem a novas tecnologias mesmo antes de haver
evidência que comprove o seu benefício (PFLEEGER, 1999).
Em um estudo sobre o processo de infusão tecnológica, realizado por
Zelkowitz (1996) no ambiente da NASA, foi encontrado que o tempo para que o
processo fosse concluído foi de 2 a 4 anos, incluindo durante esse tempo
treinamento e alguns projetos pilotos com o propósito de ajustar a tecnologia
25
para um ambiente em especial. Neste estudo, foi ressaltado que o entendimento
das tecnologias em engenharia de software que apoiam a transferência de
tecnologia é de crucial importância.
Rombach (2000) em seu estudo expõe que a Engenharia de Software
Experimental tem sido usada com sucesso como um meio para a transferência
de tecnologia e melhoria no domínio do software no laboratório de engenharia
de software da NASA. Desde 1992 este processo tem sido amadurecido e
ampliado.
Três problemas típicos acontecem quando da transferência de
tecnologias em software para aplicação na indústria, de acordo com Linkman e
Rombach (1997):

Novas tecnologias são rejeitadas por serem consideradas não
adaptadas às necessidades comerciais e por não convencerem,
sobre os benefícios da tecnologia, o gerente de projetos;

A vivência em projetos corporativos, bem como o benefício
percebido por seu staff são limitadores para que a tecnologia seja
colocada em uso;

Experiências antigas de projetos não são reusadas em novos
projetos, muito porque houve um esforço insuficiente para registrar
e demonstrar os benefícios, deste modo, as crenças alcançam um
apelo maior e a tecnologia não consegue ser disseminada.
Para Martens e Duvall (1980), uma pré-condição para que ocorra a
transferência de uma tecnologia em engenharia de software, no cenário do
pesquisador para o desenvolvedor de software, é o completo entendimento da
tecnologia e suas implicações em termos de riscos e benefícios que possam
surgir no ambiente de desenvolvimento de software. Desenvolvedores de
software precisam entender a tecnologia e todas as suas possíveis aplicações
antes que qualquer consideração possa ser feita. Este tipo de informação pode
ser provida por meio da academia ou laboratórios de pesquisa.
26
Zelkowitz et al. (1998), por meio de um survey aplicado entre engenheiros
de software e pesquisadores, encontrou que os métodos de maior valor para a
indústria no que diz respeito a transferência de tecnologia foram aqueles que
tiveram relevância ao seu ambiente, tal qual estudos de caso, estudos de campo
e experimentos controlados replicados. Em contrapartida, os pesquisadores
deram maior atenção a execução de estudos que envolviam métodos de
validação passíveis de serem reproduzidos isoladamente em laboratório. O
estudo demonstrou que para ocorrer a transferência de tecnologia de forma
satisfatória, precisa-se entender a audiência e coletar evidências relevantes e
confiáveis.
2.3
Engenharia de Software Baseada em Evidência
Segundo Kitchenham et al. (2004), houve uma mudança radical em
pesquisas realizadas no campo da medicina desde a adoção de um paradigma
baseado em evidência. Em seis anos, de 1992 a 1998, o número de estudos
sobre a prática do paradigma baseado em evidência cresceu de 1 publicação
para cerca de mil (SACKETT et al., 2000), além disso, também notou-se um
crescente interesse de outras áreas em adotar abordagens semelhantes, como
Psiquiatria, Enfermagem, Política Social e Educação.
A Engenharia de Software Baseada em Evidência (do Inglês, EvidenceBased Software Engineering - EBSE), de acordo com a definição de Kitchenham
et al. (2004), tem por objetivo prover meios pelos quais as atuais melhores
evidências de pesquisa possam ser integradas com experiência prática e valores
humanos no processo de tomada de decisão no que diz respeito a manutenção
e desenvolvimento de software. Nesse contexto, Dybå et al. (2005) delineia que,
no sentindo de evitar que a lacuna entre a pesquisa e a prática, que pode ser
ampla, torne o processo ambíguo, a EBSE encoraja uma metodologia mais
rigorosa enquanto foca na relevância para a prática (DYBA et al., 2005).
O processo de realização da EBSE acontece por meio dos cinco passos
seguintes:
1. Converter um problema relevante ou uma necessidade de informação em
uma pergunta de pesquisa;
27
2. Pesquisar a literatura com o intuito de encontrar evidências que possam
responder à questão de pesquisa;
3. Avaliar de forma crítica a evidência nos quesitos validade, impacto e
aplicabilidade;
4. Integrar a evidência avaliada com experiências práticas, valores dos
clientes e circunstâncias para a tomada de decisão sobre a prática;
5. Avaliar a performance dos passos anteriores e procurar meios para
melhorá-los.
É de se observar que os três primeiros passos da EBSE são
essencialmente o contexto em que se aplicam as Revisões Sistemáticas da
Literatura (RSL) ou somente Revisão Sistemática (RS), que são consideradas
ferramentas chave para a prática da EBSE. Este termo é usado para se referir a
uma forma de estudo secundário responsável por sumarizar todas as evidências
disponíveis fazendo uso de uma metodologia bem definida para identificar,
avaliar de forma crítica e sintetizar estudos relevantes a uma questão de
pesquisa específica (KITCHENHAM et al., 2004, 2011; KITCHENHAM;
CHARTERS, 2007; DYBA et al., 2007; BIOLCHINI et al., 2005; BUDGEN et al.,
2006).
Segundo Kitchenham e Charters (2007), existem diversos motivos para
se conduzir uma RSL, sendo os mais comuns listados a seguir:

Sumarizar as evidências existentes no que diz respeito a uma
tecnologia ou tratamento;

Identificar qualquer lacuna na pesquisa atual de forma a sugerir áreas
para investigações futuras;

Prover um framework afim de posicionar novas atividades de pesquisa
apropriadamente.
Um outro estudo secundário já bastante utilizado no campo da medicina
e que ainda é pouco aplicado em Engenharia de Software é o Estudo de
Mapeamento Sistemático (EMS), também identificado como Estudo de Escopo
(Scoping Study – em inglês) (ARKSEY; O’MALLEY, 2005). Considerado uma
28
forma mais aberta de RSL (KITCHENHAM; CHARTERS, 2007), este tipo de
estudo tem o objetivo de promover uma visão geral da área e identificar a
natureza e a extensão de estudos primários disponíveis que possam responder
uma questão de pesquisa de maior abrangência, o que contribui para a coleta
de um maior número de estudos primários. Recomenda-se este tipo de estudo
para áreas onde existem poucos estudos primários relevantes e de alta
qualidade (KITCHENHAM; CHARTERS, 2007).
Arksey e O’Malley (2005) identificam alguns motivos que justificam a
realização de um EMS:
1. Para examinar a extensão, alcance e natureza do que está sob
investigação. Se trata de uma maneira útil de mapear campos de
estudo onde há dificuldade em visualizar o alcance do material
disponível;
2. Para determinar a motivação para a realização de uma RSL
completa; a execução de um EMS preliminarmente pode servir
para identificar se há viabilidade ou relevância para a condução de
uma RSL e os potenciais custos relacionados a condução;
3. Para resumir e divulgar os resultados de pesquisa; este tipo de RSL
pode descrever em detalhes os resultados e o alcance da pesquisa
em uma área de investigação em específico, assim proporcionando
um mecanismo de síntese e disseminação dos resultados sob
investigação;
4. Para identificar lacunas de pesquisa na literatura atual; este tipo de
RSL realiza a disseminação das conclusões, a partir da literatura
existente, no que diz respeito ao estado geral da área em
investigação.
Os estudos de Petersen et al. (2008) e Kitchenham e Charters (2007) tem
demonstrado diversas diferenças quanto a condução de uma RSL e de um EMS,
entre elas podemos citar:
29

Diferença de meta: Uma RSL visa estabelecer o estado da
evidência, identificando as melhores práticas com base em
evidências empiricas. Esta por sua vez não é uma meta do EMS,
tendo em vista que os EMS não estudam os artigos em detalhe. O
EMS tem como meta a classificação, condução de análise temática
e identificar fóruns para publicação;

Diferença no processo: Em EMS os artigos não são avaliados de
acordo com sua qualidade, visto que a meta não é estabelecer o
estado da evidência. Em RSL, a aplicação de meta-análise requer
um outro nível de extração de dados a fim de trabalhar com dados
quantitativos coletados por meio de estudos primários;

Diferença em amplitude e profundidade: Em EMS, tendo em
vista que não há uma avalialão em detalhe, mais artigos podem ser
considerados.
Deste
modo,
um
campo
amplo
pode
ser
considerado. A RSL, por sua vez, declara o resultado e avaliação
da qualidade dos artigos como o foco principal, o que aumenta a
profundidade e o esforço requerido;

Considerações sobre validade: Em EMS, como não há avaliação
detalhada dos artigos, pode haver erro de julgamento quando da
classificação em categorias detalhadas. Em RSL esta ameaça é
minimizada por haver avaliação detalhada da metodologia de
pesquisa e extração de dados;

Acessibilidade e relevância para a indústria: O apelo visual
proporcionado pelo EMS pode sumarizar e ajudar a transferir os
resultados para o mercado. Contudo, em RSL, o foco em
profundidade e resultados empiricamente validados deveria ser de
grande importância para o mercado.
30
De acordo com os estudos e análises já mencionadas e conforme a
proposta para este trabalho, escolheu-se o Estudo de Mapeamento Sistemático
para guiá-lo.
2.4
Resumo
Transferência de tecnologia é de crucial importância para academia e
indústria. A habilidade de mover uma nova tecnologia de um laboratório para uso
geral na indústria é a última etapa de teste de aplicabilidade dos resultados de
pesquisa, o que valoriza o trabalho realizado na academia e mantém a indústria
economicamente competitiva. A geração de evidências e o entendimento dos
porquês quanto a realização das atividades de transferência habilita o melhor
uso dos recursos existentes, encurta o tempo para adoção e contribui para o
planejamento futuro, seja em engenharia de software ou qualquer outro campo
da ciência ou engenharia. Ainda nesse sentido, a EBSE exerce papel importante
ao encorajar metodologia rigorosa, provendo meios pelos quais se possa
integrar as evidências com experiência, prática e valores humanos, mantendo o
foco na relevância para a prática.
31
3. METODOLOGIA
Este capítulo apresenta a abordagem metodológica, que tem como
propósito, entre outros, assegurar que o estudo seja confiável, conduzido com
rigor, proporcionando a sua replicação por parte de outros pesquisadores de
forma independente. Sendo assim, para o corrente estudo, este capítulo de
metodologia foi estruturado da seguinte maneira. A Seção 3.1 traz a
classificação da pesquisa em conjunto com o quadro metodológico. As etapas
da pesquisa científica são detalhadas na Seção 3.2, onde se descreve o
protocolo usado na condução do mapeamento sistemático.
3.1
Classificação da Pesquisa
Esta pesquisa optou por utilizar o método de abordagem indutivo apoiado
por dados qualitativos. Foi utilizado como método o Estudo de Mapeamento
Sistemático (EMS), com o intuito de promover uma visão geral da área e
identificar
a
natureza
e
extensão
de
estudos
empíricos
disponíveis
(KITCHENHAM; CHARTERS, 2007).
Na Tabela 3.1 encontra-se o quadro metodológico dessa pesquisa.
Quadro 3.1 - Classificação da Pesquisa
Quadro Metodológico
Método de Abordagem
Indutivo
Método de Procedimento
Estudo de Mapeamento Sistemático
Natureza dos Dados
Qualitativa
Fonte: Próprio autor.
O método de abordagem indutivo, segundo Marconi e Lakatos (2007, p.
86), é um processo mental que a partir de dados particulares, é inferida uma
verdade geral ou universal, não encontrada nas premissas examinadas. Este
tipo de método tem como objetivo gerar conclusões de conteúdo com amplitude
maior do que o identificado nas partes em que foram baseados. Desse modo, “o
caminho de passagem vai do especial ao mais geral, dos indivíduos às espécies,
das espécies ao gênero, dos fatos às leis ou das leis especiais às leis mais
gerais” (MARCONI; LAKATOS, 2007, p. 86).
32
Ainda nesse contexto, segundo Marconi e Lakatos (2007, p. 87), a
indução é realizada em três fases fundamentais:
a) Observação dos fenômenos: O propósito desta etapa é descobrir as
causas da sua manifestação, assim observando e analisando os fatos
e fenômenos;
b) Descoberta da relação entre eles: Nesta etapa, o foco está em
descobrir a existência de relação entre os fatos e fenômenos por meio
de comparação;
c) Generalização da relação: Neste último estágio, é realizada a
generalização dos fatos e fenômenos semelhantes, muitos ainda não
observados ou inobserváveis.
O método de procedimento escolhido para este trabalho é o Estudo de
Mapeamento Sistemático (EMS), cujo propósito é promover uma visão geral da
área, de modo a identificar lacunas existentes no conjunto de estudos primários,
onde novos e melhores estudos são requeridos, bem como clusters onde possa
haver a existência de escopo para a realização de uma mais completa Revisão
Sistemática da Literatura (RSL) (BUDGEN et al., 2008).
Este estudo é composto, sobretudo, de variáveis de natureza qualitativa.
Em concordância com Marconi e Lakatos (2007), o método qualitativo difere do
quantitativo, entre outros, pelo modo em que se realiza a coleta e análise dos
dados, e também pela não aplicação de instrumentos estatísticos. Outrossim, a
metodologia qualitativa preocupa-se com a análise e interpretação de aspectos
mais profundos, descrevendo a complexidade do comportamento humano e
fornecendo uma análise de maior detalhamento em relação as investigações,
hábitos, atitudes, tendências de comportamento, etc.
3.1.1 Classificação Segundo Cooper
De forma a complementar a definição da metodologia de pesquisa,
considerou-se a taxonomia de Cooper (1988) para realizar a classificação por
ser adequada para revisões sistemáticas. Esta taxonomia utiliza cinco
33
características para fazer a classificação: foco, objetivo, perspectiva, cobertura,
organização e audiência. O Quadro 3.2 apresenta a classificação desta
pesquisa.
Quadro 3.2 – Classificação segundo Cooper
Características
Categorias
Resultados de Pesquisa
Foco
Métodos de Pesquisa
Práticas ou Aplicações
Objetivo
Integração
Perspectiva
Representação Neutra
Cobertura
Exaustiva
Organização
Conceitual
Audiência
Pesquisadores
Profissionais
Fonte: Próprio autor
Abaixo é apresentada cada característica da classificação de acordo com
Cooper (1988).

Foco: Esta característica diz respeito ao interesse central do pesquisadorrevisor. As revisões, no geral, centralizam em uma ou mais áreas das
seguintes: Resultados de Pesquisa, Métodos de Pesquisa, Teorias, e
Práticas ou Aplicações. Não há interesse mutuo por estas áreas, no entanto
é raro para um pesquisador ter apenas um único foco. Os pesquisadores
tendem a ter dois ou três focos que recebem grau variado de atenção.

Objetivo: Esta segunda característica diz respeito aos resultados que o autor
espera que a revisão alcance, podendo classificá-los como: Integração,
Crítica e Identificação de Problemas Centrais. O objetivo de maior evidência
para uma revisão diz respeito a integração e sintetização da literatura
passada, onde se espera que haja relação com a mesma questão
investigada. Vale ressaltar que, por este objetivo ser bastante difundido,
dificilmente encontram-se revisões que não tentem sintetizar de alguma
forma os trabalhos. O intuito destas revisões usualmente é demonstrar que,
no passado, as conclusões derivadas da literatura foram injustificáveis.
34

Perspectiva: Esta característica diz respeito a como o ponto de vista
influencia a discussão da literatura por parte dos revisores. Dois papéis são
identificados, chamados de Representação Neutra e Exposição de
Posicionamento. No primeiro, o revisor tenta apresentar argumentos a favor
e contra diferentes interpretações da literatura. As interpretações são
expostas com certa similaridade em relação a aquelas empregadas pelos
autores originais, e tenta-se assegurar que ambos sejam apresentados. Na
segunda perspectiva, o revisor utiliza seu ponto de vista de forma mais ativa
no processo editorial. Neste ponto, o revisor tende a acumular e sintetizar a
literatura de forma a demonstrar a importância de um ponto de vista em
específico.

Cobertura: Esta característica está relacionada a tomada de decisão por
parte do pesquisador no que se refere a busca e inclusão de trabalhos de
acordo com a relevância, adequação e qualidade. Existem quatro tipos de
cobertura: Exaustiva, Exaustiva com Seleção de Citação, Representativa e
Central ou Essencial. Na Exaustiva, o pesquisador pretende coletar toda ou
quase toda a literatura disponível na área investigada. No que se refere ao
segundo tipo, têm-se também a exaustão como meta, porém somente uma
amostra é selecionada e descrita no trabalho. Na cobertura representativa, o
pesquisador seleciona a amostra que representa em sua totalidade a área de
pesquisa. No último tipo, a cobertura central ou essencial, são selecionados
pelo pesquisador trabalhos que tenham como foco esforços importantes e
iniciais que direcionam um campo de pesquisa.

Organização: Esta quinta característica está relacionada a organização do
trabalho e dos resultados. Nessa etapa, três são as formas de apresentação:
(i) historicamente, onde a apresentação dos temas tem a ver com a ordem
cronológica do surgimento na literatura, (ii) conceitualmente, cujo propósito
está em apresentar trabalhos relacionados onde as mesmas idéias aparecem
juntas, ou (iii) metodologicamente, onde trabalhos que empregam métodos
onde haja similaridade são agrupados em subtópicos. Pesquisadores podem
35
combinar estes tipos de organização, abordando, por exemplo, trabalhos
historicamente dentro de um quadro conceitual ou metodológico.

Audiência: Apresenta o público-alvo da pesquisa, que pode diferir de uma
para a outra. Revisores podem escrever para Pesquisadores Especializados,
Pesquisadores em Geral, Profissionais, ou para o Público em geral. A
distinção da audiência será determinante para o estilo de escrita e emprego
de jargões e conceitos específicos da área.
3.2
Ciclo da Pesquisa
Inicialmente, identificou-se por meio do estudo de Barreiros (2011) a
dificuldade em realizar a adoção de novas tecnologias por parte da indústria e
que o processo de transferência tecnológica continuava a ser uma atividade
problemática. A partir desse ponto, foi iniciada uma pesquisa bibliográfica
tradicional sobre a realização do processo de transferência tecnológica. O
material avaliado foi composto de dissertações acadêmicas, artigos científicos e
livros.
Após a investigação inicial, foi observada a existência de influenciadores
(facilitadores e inibidores) relacionados às etapas do processo de transferência
que atuavam com o intuito de acelerar, retardar ou encerrar a adoção
tecnológica. Além disso, percebeu-se a não existência de estudo sistemático
com o propósito de reunir e consolidar o conhecimento da área.
Com base nesse estudo exploratório, ficou claro a necessidade da
realização de um estudo de mapeamento sistemático. Deste modo, o foco da
pesquisa foi definido resultando em questões de pesquisa, encontradas na
Seção 3.2.2 deste trabalho. Em seguida, um protocolo a ser seguido foi definido
e executado, com o intuito de coletar evidências que respondam as perguntas
de pesquisa estabelecidas. Este protocolo é apresentado por completo no
Apêndice C e de forma resumida nesse capítulo.
Ao final, propõe-se um mapeamento que se caracteriza em contribuir com
o conhecimento agregado referente à transferência de tecnologia entre a
Academia (Criador) e Indústria (Receptor) em Engenharia de Software,
36
apontando assim lacunas existentes e possibilitando que o estudo possa ser
repetido e refinado. Ressalta-se que existem outras formas de se realizar a
transferência de tecnologia, mas para o presente trabalho o foco estará entre a
academia e indústria.
3.2.1 Mapeamento Sistemático
O protocolo do mapeamento teve sua criação guiada de acordo com as
instruções constantes no guideline definido por Kitchenham e Charters (2007).
Este protocolo é apresentado por completo no Apêndice C.
3.2.2 Escopo e Questões de Pesquisa
Determinar a estrutura e definir as questões de pesquisa são passos
essenciais para o processo de busca por estudos primários que sejam
adequados ao que predispõe o estudo. Portanto, com o intuito de encontrar
estudos primários relevantes à temática, seguem as questões de pesquisa que
precisam ser abordadas por este protocolo:

QP1: Que fatores influenciam positivamente a transferência de
tecnologia entre academia e indústria em engenharia de software?

QP2: Que fatores influenciam negativamente a transferência de
tecnologia entre academia e indústria em engenharia de software?

QP3: Quais são as abordagens existentes para transferência de
tecnologia entre academia e indústria em engenharia de software?
3.2.3 Estratégia de Busca
A identificação e seleção dos termos para a composição da string de
busca é um dos primeiros passos a se levar em conta quando da definição da
estratégia que irá guiar o processo. Segundo Kitchenham e Charters (2007), a
criação da estratégia de busca é um processo iterativo e deveria ser
desenvolvida com o auxílio de consultores com experiência relevante no campo
de estudo.
Deste modo, a elaboração da string de busca seguiu os seguintes passos:

Palavras-chave foram derivadas das questões de pesquisa;
37

Uma busca por estudos relevantes relacionados a pesquisa foi
realizada em Revistas e Bibliotecas Digitais, onde foram coletadas
palavras-chave constantes nesses estudos;

Sinônimos e abreviações de termos derivados dos passos anteriores
foram considerados;

Foram consultados especialistas das áreas de transferência de
tecnologia e engenharia de software, alguns advindos da academia,
outros da indústria;

Testes com a utilização de combinações diferentes dos termos
identificados foram realizados, resultando em versões diferentes da
string até que se chegou a versão final para este estudo.
O Quadro 3.3 apresenta a string de busca gerada.
Quadro 3.3 - String para a realização das buscas automatizadas
String de Busca
("software engineering") AND ("technology diffusion" OR "technology infusion" OR "technology
transfer" OR "transfer of technology" OR "technology transition" OR "technology innovation"
OR "technology adoption" OR "innovation adoption") AND (obstacle OR improvement OR
incentive OR difficult OR insight OR barrier OR constraint OR success factor OR problem OR
benefit OR restriction OR implication) AND (pattern OR method OR approach OR process OR
framework OR technique OR practice OR guideline OR strategy OR methodology)
Fonte: Próprio autor
3.2.4 Processo de Busca
Para dar início ao processo de busca automatizada, cujo propósito é
encontrar estudos primários relevantes através da aplicação da string criada,
foram selecionadas as seguintes fontes eletrônicas:

IEEExplore Digital Library (httt://ieeexplore.ieee.org/);

ACM Digital Library (http://portal.acm.org);

Elsevier SciencDirect (http://www.sciencedirect.com).
Diante da relevância em relação aos tópicos abordados pelo trabalho e para
que não haja perda de informação, foi identificada a necessidade da realização
38
de buscas manuais nos seguintes periódicos (a data inicial de pesquisa em cada
periódico identifica a ocorrência de sua primeira edição):

The Journal of Technology Transfer (de 1977 a 2013);

The International Journal on Software Tools for Technology Transfer (de
1997 a 2013).
3.2.5 Critérios de Inclusão/Exclusão e Procedimentos de Seleção
Esta etapa visa avaliar os estudos em potencial que foram selecionados
quanto a relevância em relação as questões de pesquisa. Deste modo, a
inclusão ou não de algum dos estudos leva em consideração critérios de inclusão
e exclusão.
Os estudos serão selecionados se forem adequados aos seguintes critérios:

O estudo deve estar disponível na Web;

O estudo deve estar escrito em inglês;

O estudo deve apresentar fatores que influenciam positiva ou
negativamente a transferência de tecnologia ou tratar de
alguma abordagem relacionada ao tema;

O estudo deve estar relacionado a transferência de tecnologia
em Engenharia de Software.
Em contrapartida, serão excluídos os estudos segundo os seguintes critérios:

Estudos sem relevância para a pesquisa;

Estudos duplicados, considerando o mais completo;

Estudos incompletos (resumos, resumos expandidos ou
apresentações)
3.2.6 Extração dos Dados
Os dados utilizados como evidências para responder às questões de
pesquisa deste estudo foram coletados através dos formulários disponíveis no
Apêndice C.
39
3.2.7 Síntese dos Dados
Com o propósito de representar os dados coletados, é realizada uma
síntese das informações de forma a mapear o conhecimento gerado na pesquisa
em categorias de acordo com sua representatividade. Esta síntese visa
relacionar os tópicos que tratam da transferência de tecnologia em engenharia
de software, os tipos de influências positivas e negativas e as abordagens
utilizadas.
Recursos gráficos são utilizados como meio para a apresentação dos
resultados de cada categoria, assim auxiliando na identificação de lacunas onde
haja escassez de estudos e também possibilidades de pesquisas futuras com
um maior nível de especificidade.
3.3
Resumo
Este capítulo teve como missão a descrição da metodologia utilizada na
pesquisa, sua estrutura, o modo em que foi conduzida e as razões de uso dos
procedimentos ou métodos. Em adição, o protocolo usado para guiar a execução
do Estudo de Mapeamento Sistemático foi descrito de forma breve.
40
4. RESULTADOS
O Capítulo 4 apresenta os resultados do EMS (Estudo de Mapeamento
Sistemático), bem como sua análise. Sendo assim, para o corrente estudo, este
capítulo de resultados foi estruturado da seguinte maneira. A seção 4.1 traz a
extração e análise dos dados. A seção 4.2 traz o resumo dos resultados. O
mapeamento das evidências é apresentado na seção 4.3. Na seção 4.4 é
apresentada a discussão sobre os resultados.
4.1
Extração e Análise dos Dados
O mapeamento sistemático foi executado de acordo com o protocolo,
encontrado de forma resumida no Capítulo 3 e disponível por completo no
Apêndice C. Por meio da aplicação string de busca nas fontes definidas, as
buscas primárias automatizadas retornaram um total de 4689 trabalhos, sendo
111 trabalhos identificados na IEEE, 1327 no ScienceDirect e 3251 na ACM. O
Gráfico 4.1 exibe o percentual de trabalhos retornados por cada biblioteca
digital.
41
IEEE
3%
SCIENCE DIRECT
28%
ACM
69%
ACM
SCIENCE DIRECT
IEEE
Gráfico 4.1 - Resultado da busca automatizada
Fonte: Próprio autor
Com o objetivo de aumentar o alcance do estudo, também foram
realizadas buscas manuais, onde as pesquisas são realizadas sem o auxílio dos
mecanismos automáticos de engenhos de busca. Estas buscas foram aplicadas
nos periódicos The Journal of Technology Transfer (TT), no período de 1977
(ano da primeira edição) a 2013 e The International Journal on Software Tools
for Technology Transfer (STTT), no período de 1997 (ano da primeira edição) e
2013. O total de estudos que cada periódico proporcionou foi conhecido por meio
de contagem dos estudos em suas edições, cujo resultado foi um montante de
1538, divididos em 1036 para o periódico TT e 503 para o STTT. O percentual
por periódico encontrado na busca manual é ilustrado no Gráfico 4.2.
42
STTT
33%
TT
67%
STTT
TT
Gráfico 4.2 - Resultado da Busca Manual
Fonte: Próprio autor
O montante final, que abrange os resultados das buscas automatizadas e
manuais, foi um total de 6228 estudos, onde a busca manual obteve
representatividade de 25% dos estudos retornados dos periódicos TT e STTT
juntos, assim também a busca automatizada obteve representatividade de 75%
do total de estudos. O resultado é ilustrado no Gráfico 4.3.
É de se observar que a quantidade de estudos primários retornados nas
buscas foi alta. Este elevado número de estudos é comum em estudos
secundários (Revisão Sistemática da Literatura e Estudo de Mapeamento
Sistemático) por utilizarem processos automatizados de busca em razão das
características e funcionalidades disponíveis nos engenhos de busca
(KITCHENHAM; CHARTERS, 2007).
Após a conclusão da leitura do título e resumo, a seleção dos estudos
potencialmente relevantes resultou em 180 trabalhos. Utilizou-se dos critérios de
inclusão e exclusão, bem como descartando estudos claramente irrelevantes,
chegando a uma redução de 6228 para 180 estudos (97% de redução) com
potencial relevância. A distribuição dos trabalhos potencialmente relevantes é
exibida no Gráfico 4.4.
43
TT
17%
STTT
8%
ACM
52%
IEEE
2%
SCIENCE DIRECT
21%
ACM
SCIENCE DIRECT
IEEE
STTT
TT
Gráfico 4.3 - Resultado da Busca Automatizada e Manual juntas
Fonte: Próprio autor
STTT TT
2% 3%
IEEE
26%
ACM
45%
SCIENCE DIRECT
24%
ACM
SCIENCE DIRECT
IEEE
STTT
TT
Gráfico 4.4 - Resultado da Seleção de Estudos Potencialmente Relevantes
Fonte: Próprio autor
A etapa seguinte foi responsável por guiar uma avaliação com o propósito
de selecionar os estudos que seriam incluídos na lista final de estudos primários,
44
lista essa que está disponível no Apêndice A, é importante ressaltar que este
passo foi executado por 3 duplas, formadas por 6 revisores. Assim, a partir dos
180 encontrados anteriormente, chegou-se a 87 estudos primários. Os demais
estudos tiveram sua exclusão realizada por motivos de irrelevância, duplicidade,
que diz respeito àqueles identificados em duas fontes diferentes, e completude.
O Apêndice B contêm os estudos excluídos assim como a motivação, já o
Quadro 4.1 apresenta a evolução do processo de seleção de estudos primários.
Quadro 4.1 - Evolução do Processo de Seleção
Fontes
Estudos
Retornados
Seleção de Estudos Primários
#1 Seleção
#2 Seleção
Excluído
Incluído
Sem Acesso
Incompleto
Repetido/Duplicado
Não Relevante
IEEE
111
Estudos
Potencialmente
Relevantes
47
SCIENCE
DIRECT
1327
44
16
1
1
3
23
ACM
3251
80
4
26
7
16
27
TT
1036
6
1
0
0
0
5
STTT
503
3
2
0
0
0
1
TOTAL
6228
180
35
27
12
19
87
12
0
4
0
Estudos
Primários
31
Fonte: Próprio autor
Esta revisão contabilizou o envolvimento de 206 autores. Em meio a estes
autores, estão àqueles que publicaram mais de uma vez, são eles: Michael G.
Hinchey, Thomas Pressburger, Alan R. Hevner, Lawrence Markosian, Martin S.
Feather, Andrea de Lucia, Bill C. Hardgrave, Dieter H. Rombach, Gina C. Green,
Giuseppe Scanniello, Priscilla Fowler, Ross Jeffery, Shari Lawrence Pfleeger,
Tony Gorschek e Wes Deadrick. Os pesquisadores são originários de 20 países
diferentes, como pode-se observar no Gráfico 4.5. Em decorrência da
cooperação entre dois ou mais pesquisadores de origem em instituição de países
diferentes, o somatório das publicações de cada país ultrapassa a quantidade
de estudos selecionados.
45
EUA
ALEMANHA
INGLATERRA
SUÉCIA
CANADA
ITÁLIA
AUSTRÁLIA
JAPÃO
ESPANHA
NOVA ZELÂNDIA
CHILE
TAIWAN
NORUEGA
AUSTRIA
HOLANDA
INDIA
HONG KONG
ISRAEL
DINAMARCA
ESCÓCIA
0
10
20
30
40
50
60
Gráfico 4.5 - Representatividade por país
Fonte: Próprio autor
Deste modo, esta seção apresentou alguns dados gerais encontrados por
meio do mapeamento sistemático. Estas informações podem ser usadas por
outros estudos ou replicações que confirmem ou refutem os resultados.
4.2
Resumo dos Resultados
Esta seção resume os resultados encontrados após a etapa de avaliação,
cujo propósito foi o de selecionar os estudos primários que compõem a lista final
que está disponível no Apêndice A. O Gráfico 4.6 exibe, em ordem de
frequência, as 41 categorias que foram mapeadas e obtidas a partir da extração
da QP1. O Gráfico 4.7 exibe, em ordem de frequência, as 34 categorias de
tópicos que foram mapeadas e obtidas a partir da extração da QP2. Já o Gráfico
4.8 exibe, em ordem de frequência, as 4 categorias de tópicos que foram
mapeadas e obtidas a partir da extração da QP3. Mesmo esta seção possuindo
o aparato de informações necessárias para que se possa assimilar a informação
46
contida nas evidências, as Seções 4.3.1, 4.3.2 e 4.3.3 estão disponíveis para
que se possa verificar as evidências coletadas e categorizadas.
Projetos de Pesquisa
Comunicação
Características Pessoais
Satisfação do Cliente
Competitividade
Melhoria Contínua
Público
SOA
Caso de Negócio
Ferramentas CASE
Vantagem Relativa
Flexibilidade
Tratamento da transferência
Reutilização do processo de gestão
Fácil de Usar
Recompensa
Protótipo
Trabalho em Equipe
Normas
Ambiente
Desejo de Inovar
Compromisso com o Cliente
Trabalho e Dedicação
Reorganização Societária
Motivação
Parceria
Pessoa-Chave
Relacionamento
Cultura
Integração
Resposta ou Retorno (Feedback)
Compatibilidade com o Processo Atual
Senso de Oportunidade (Timing)
Agente
Custo
Material de Apoio (Packaging)
Cooperação e Colaboração
Percepção do Benefício
Formação e Aprendizagem
Apoio da Alta Gerência
Experimentação
0,00%
2,00%
4,00%
6,00%
8,00%
10,00%
12,00%
14,00%
Gráfico 4.6 - Tipos de fatores positivos identificados
Fonte: Próprio autor
47
Tabela 4.1 - Resumo dos estudos por fator positivos encontrado
Referências – EP: Estudos
Primários
Quantidade de Trabalhos –
(%)
EP31, EP32, EP38, EP42,
EP61, EP65, EP67, EP85,
EP86
EP15, EP19, EP22, EP41,
EP77
EP15, EP39, EP40, EP69,
EP70
EP10, EP66, EP75, EP77
9 (11,54 %)
EP37, EP49, EP59, EP69
4 (5,13 %)
EP18, EP28, EP44
3 (3,85 %)
FP7
Cooperação e
Colaboração
Material de Apoio
(Packaging)
Custo
EP1, EP9, EP19
3 (3,85 %)
FP8
Agente
EP4, EP5, EP79
3 (3,85 %)
FP9
EP54, EP69
2 (2,56 %)
EP33, EP45
2 (2,56 %)
EP84, EP57
2 (2,56 %)
FP12
Senso de Oportunidade
(Timing)
Compatibilidade com o
processo atual
Resposta ou Retorno
(Feedback)
Integração
EP12, EP64
2 (2,56 %)
FP13
Cultura
EP69, EP78
2 (2,56 %)
FP14
Relacionamento
EP13, EP60
2 (2,56 %)
FP15
Pessoa-Chave
EP19, EP36
2 (2,56 %)
FP16
Parceria
EP59, EP77
2 (2,56 %)
FP17
Motivação
EP3, EP46
2 (2,56 %)
FP18
Reorganização Societária
EP14
1 (1,28 %)
FP19
Trabalho e Dedicação
EP15
1 (1,28 %)
FP20
Compromisso com o
cliente
Desejo de Inovar
EP69
1 (1,28 %)
EP71
1 (1,28 %)
FP22
Ambiente
EP80
1 (1,28 %)
FP23
Normas
EP70
1 (1,28 %)
FP24
Trabalho em equipe
EP80
1 (1,28 %)
FP25
Protótipo
EP49
1 (1,28 %)
FP26
Recompensa
EP70
1 (1,28 %)
FP27
Fácil de usar
EP43
1 (1,28 %)
FP28
EP27
1 (1,28 %))
EP34
1 (1,28 %)
FP30
Reutilização do processo
de gestão
Tratamento da
transferência
Flexibilidade
EP58
1 (1,28 %)
FP31
Vantagem Relativa
EP19
1 (1,28 %)
FP32
Ferramentas CASE
EP74
1 (1,28 %)
Código
Tópicos de Pesquisa
FP1
Experimentação
FP2
Apoio da Alta Gerência
FP3
Formação e
Aprendizagem
Percepção do Benefício
FP4
FP5
FP6
FP10
FP11
FP21
FP29
5 (6,41 %)
5 (6,41 %)
4 (5,13 %)
48
FP33
Caso de negócio
EP52
1 (1,28 %)
FP34
SOA
EP53
1 (1,28 %)
FP35
Público
EP26
1 (1,28 %)
FP36
Melhoria contínua
EP32
1 (1,28 %)
FP37
Competitividade
EP77
1 (1,28 %)
FP38
Satisfação do cliente
EP69
1 (1,28 %)
FP39
Características pessoais
EP69
1 (1,28 %)
FP40
Comunicação
EP48
1 (1,28 %)
FP41
Projetos de pesquisa
EP8
1 (1,28 %)
Fonte: Próprio autor.
Ao final das avaliações, chegou-se ao total de 87 estudos primários. A
partir desse montante, encontrou-se evidências para fatores positivos em 58
estudos primários, fatores negativos em 40 estudos primários e abordagens em
15 estudos primários. Pode-se observar que o total de estudos incluídos na lista
final difere do somatório dos estudos que identificaram fatores positivos,
negativos e abordagens, o que pode ser justificado por haver ocorrência de mais
de uma evidência em alguns dos estudos. As evidências extraídas dos estudos
primários estão sumarizadas nas Tabelas 4.1, 4.2 e 4.3 e suas transcrições
estão contidas nas Seções 4.3.1, 4.3.2 e 4.3.3.
49
Retorno do Investimento
Pessoas inadequadas
Falta de confiança
Lacuna no processo de inovação conjunta
Sucesso do negócio
Core Business
Material de apoio (Packaging)
Robustez
Ambiente
Falta de orientação
Público errado
Intervenção da gerência
Perspectiva
Aversão ao risco
Expectativa
Agenda e Orçamento apertado
Resposta ou retorno (Feedback)
Retorno claro
Deficiências gerais
Relacionamento
Percepção do benefício
Incerteza
Cultura
Recompensas pessoais
Experiência
Evidência
Falta de maturidade
Comunicação
Falta de correspondência
Resistência a mudança
Formação e Aprendizagem
Falta de entendimento
Falta de ferramenta
Custo
0,00%
2,00%
4,00%
6,00%
8,00%
10,00% 12,00% 14,00%
Gráfico 4.7 - Tipos de fatores negativos identificados
Fonte: Próprio autor
50
Tabela 4.2 - Resumo dos estudos por fator negativo encontrado
Código
Tópicos de Pesquisa
Referências – EP: Estudos
Primários
Quantidade de Trabalhos
– (%)
6 (12,00 %)
FN1
Custo
FN2
Falta de ferramenta
EP15, EP16, EP23, EP24,
EP62, EP78
EP21, EP47, EP60
FN3
Falta de entendimento
EP35, EP38, EP76
3 (6,00 %)
FN4
Formação e aprendizagem
EP6, EP25, EP33
3 (6,00 %)
FN5
Resistência a mudança
EP10, EP41
2 (4,00 %)
FN6
Falta de correspondência
EP1, EP29
2 (4,00 %)
FN7
Comunicação
EP50, EP73
2 (4,00 %)
FN8
Falta de maturidade
EP13, EP56
2 (4,00 %)
FN9
Evidência
EP7, EP61
1 (2,00 %)
FN10
Experiência
EP13
1 (2,00 %)
FN11
Recompensas pessoais
EP30
1 (2,00 %)
FN12
Cultura
EP30
1 (2,00 %)
FN13
Incerteza
EP82
1 (2,00 %)
FN14
Percepção do benefício
EP83
1 (2,00 %)
FN15
Relacionamento
EP38
1 (2,00 %)
FN16
Deficiências gerais
EP11
1 (2,00 %)
FN17
Retorno claro
EP17
1 (2,00 %)
FN18
EP20
1 (2,00 %)
EP34
1 (2,00 %)
FN20
Resposta ou retorno
(Feedback)
Agenda e orçamento
apertado
Expectativa
EP54
1 (2,00 %)
FN21
Aversão ao risco
EP56
1 (2,00 %)
FN22
Perspectiva
EP87
1 (2,00 %)
FN23
Intervenção da gerência
EP81
1 (2,00 %)
FN24
Audiência
EP31
1 (2,00 %)
FN25
Falta de orientação
EP60
1 (2,00 %)
FN26
Ambiente
EP2
1 (2,00 %)
FN27
Robustez
EP7
1 (2,00 %)
FN28
EP38
1 (2,00 %)
FN29
Material de apoio
(Packaging)
Core business
EP68
1 (2,00 %)
FN30
Sucesso do negocio
EP59
1 (2,00 %)
FN31
EP59
1 (2,00 %)
FN32
Lacuna no processo de
inovação conjunta
Falta de confiança
EP59
1 (2,00 %)
FN33
Pessoas inadequadas
EP59
1 (2,00 %)
FN34
ROI
EP30
1 (2,00 %)
FN19
4 (8,00 %)
Fonte: Próprio autor
Do total de 87 estudos primários, foram encontradas 143 evidências. Para
fatores positivos, de 58 estudos primários, foram encontradas 78 evidências, o
51
que representa 55% do total. Para fatores negativos dos 40 estudos primários
foram encontradas 50 evidências, o que representa 35% do total e para
abordagens, foram encontradas 15 evidências, representando 10% do total de
evidências.
Dentre os estudos primários, foi identificada a ocorrência de 13 estudos
possuindo fatores positivos e negativos, são eles EP1, EP10, EP13, EP15, EP31,
EP34, EP38, EP41, EP54, EP59, EP60, EP61 e EP78. Também, entre os 15
estudos primários que identificaram evidência para abordagem, 11 deles
encontraram evidência para outra questão de pesquisa do presente estudo.
Ainda neste contexto, verificou-se também que algumas categorias apareceram
em resposta a QP1 e QP2 respectivamente. Podemos citar formação e
aprendizagem, percepção do benefício, material de apoio (packaging), custo,
resposta ou retorno (feedback), cultura, relacionamento, ambiente, público,
comunicação.
Esquema
7%
Processo
13%
Framework
33%
Modelo
47%
Framework
Modelo
Processo
Esquema
Gráfico 4.8 - Tipos de abordagens identificadas
Fonte: Próprio autor
Tabela 4.3 – Resumo dos estudos por abordagem encontrada
52
Código
Tópicos de
Pesquisa
A1
Modelo
A2
A3
A4
Framework
Processo
Esquema
4.3
Referências – EP: Estudos
Primários
Quantidade de Trabalhos –
(%)
EP18, EP31, EP53, EP58,
EP72, EP78, EP85
EP14, EP36, EP51, EP55, EP70
EP30, EP34
EP63
Fonte: Próprio autor
7 (46,67 %)
5 (33,33 %)
2 (13,33 %)
1 (6,67 %)
Mapeamento das Evidências
Esta seção está dividida de forma a responder com evidências as
questões de pesquisa. A Seção 4.3.1 lista as evidências relacionadas à fatores
positivos que influenciam a transferência de tecnologia entre academia e
indústria em engenharia de software. Na Seção 4.3.2, por sua vez, apresenta as
evidências que estão relacionadas com fatores negativos que influenciam a
transferência de tecnologia entre academia e indústria em engenharia de
software. E por último, a Seção 4.3.3 apresenta quais as abordagens existentes
em transferência de tecnologia entre academia e indústria em engenharia de
software. As referências são apresentadas para cada evidência. É utilizado o
prefixo EP e uma numeração de 1 a 87 seguindo a ordem contida no Apêndice
A para os estudos primários.
4.3.1 Fatores Positivos
Q1 – Que fatores influenciam positivamente a transferência de tecnologia
entre academia e indústria em engenharia de software?
O objetivo da questão de pesquisa é identificar os fatores positivos que
influenciam a transferência de tecnologia entre academia e indústria no campo
da engenharia de software. O surgimento das categorias se deu de forma
automática. Por sua vez, cada estudo pode estar relacionado a mais de uma
questão de pesquisa ou a mais de uma categoria, tendo em vista que em alguns
estudos primários foi encontrada a ocorrência de mais de um fator. Esta seção
apresenta as evidências por categoria.
53
FP1 - Experimentação
Experimentos controlados, quando aplicados apropriadamente, são
considerados veículos para uma bem-sucedida e sustentável transferência
tecnológica em engenharia de software. Estes geram informações importantes
que servem de auxílio para aqueles que detem o poder de decisão quando do
momento da adoção de uma nova tecnologia. Tecnologias não deveriam ser
sugeridas,
publicadas
ou
apresentadas
para
venda
sem
que
haja
experimentação ou validação. (TRAVASSOS et al., 2002).
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP31, EP32, EP38, EP42, EP61, EP65, EP67, EP85 e EP86.

EP31 - “[...] techniques such case studies, field studies and replicated
controlled experiments were considered to be important to the
decision-making process in choosing a new technology.”

EP32 - “Experimental Software Engineering has been used as a
vehicle for successful technology transfer and improvement in the
software domain at NASA's Software Engineering Laboratory (SEL)
[...] It is our strong belief that there is no alternative to experimentallybased technology transfer, if sustained improvements are to be
achieved
in
the
highly
human-based
software
development
environment.”

EP38 - “Understanding how evidence helps determine which types of
people choose which technologies is an important part of successful
technology transfer.”

EP42 - “The results of this experiment facilitate the understanding of
the models currently used by the two communities and the connections
between them. This, in turn, facilitates technology transfer, the ultimate
goal.”
54

EP61 - “From a research point of view, successful technology transfer
requires knowing which information decision makers in industry need,
and where they actually look for it. With this knowledge, empirical
research can strive to produce the needed information in order to
increase the likelihood of successful technology adoption.”

EP65 - “Effective technology transfer is a concern for all software
engineering researchers who want to see their work put to practical
use. It is also a concern for all practitioners who want their work to
benefit from the most effective practices. However, the adoption of new
research-based techniques in the industry is frustratingly slow and
difficult. The study presented in this paper provides some empirical
evidence for particular strategies and emphases in the technology
transfer process, namely a pilot strategy and an emphasis on the
innovation’s effect on cost, quality, and schedule.”

EP67 - “And as a bottom line, the SCRover testbed provided a working
example of how SETTs and their ability to provide users with
comparable empirical data can overcome the challenges of technology
adoption and maturation in order to increase the speed of the
technology maturation and adoption process.”

EP85 - “The empirical support for environment on adoption (H3)
demonstrates that firms in highly competitive markets tend to adopt
UML more quickly than firms in less competitive markets.”

EP86 - “Experimentation, applied properly, is therefore a powerful
means for obtaining the body of evidence necessary for introducing
new software engineering technologies into industrial environments.
Only in this way cooperation across academia and industry can be
endorsed.”
55
FP2 - Apoio da Alta Gerência
O apoio da alta gerência visa estabelecer compromissos organizacionais
que favoreçam a nova tecnologia, instituindo um conjunto de objetivos e
avaliações que possam servir de mecanismo para avaliar o atual estado
tecnológico da organização, suas vantagens e desvantagens, em comparação
ao que proporciona a tecnologia que está sendo proposta para adoção.
Abaixo são apresentadas as evidências coletadas a partir dos estudos primários
EP15, EP19, EP22, EP41 e EP77.

EP15 - “There are additional factors which contributed to the successful
technology transfer. Executive management in IBM has instituted quality
initiatives that have inspired product laboratories to adopt better methods
of software development.”

EP19 - “The results of data analyses revealed that, of the seven variables,
[...], strong top management support [...] were found to be important
factors to differentiate adopters from non-adopters.”

EP22 - “Technological competitiveness requires top management
commitment to adopting new software innovations, development of
software engineering processes, and instituting an array of objective and
comprehensive
evaluations
of
current
and
prospective
software
advantages and disadvantages. Management must also be concerned
with establishing organizational commitment to planning, designing,
controlling, monitoring, evaluating, appraising, and integrating alternative
technological improvements.”

EP41 - “By knowing the determinants of a developer’s intention,
management can take appropriate action to increase the adoption of a
new methodology.”
56

EP77 - “A considerable number of factors can influence adoption of new
technologies, including characteristics of an organization, competitiveness
and management strategies of an organization, influences of internal and
external parties on the adoption decision process, characteristics of new
technologies, perceived benefits, organizational readiness, the CEO’s
attitude toward the adoption of new technologies, and the presence or
absence of top management support”
FP3 - Formação e Aprendizagem
O treinamento, quando disponibilizado e aplicado de forma efetiva, é visto
como fator crucial e visa demonstrar o benefício de forma prática, aumentando
a habilidade individual dos desenvolvedores de software, assim assimilando
conhecimento sobre uma determinada tecnologia e fomentando a transferência
do conhecimento para a prática real.
Abaixo são apresentadas as evidências coletadas a partir dos estudos primários
EP15, EP39, EP40, EP69 e EP70.

EP15 - “Results indicate that the CSTC has developed a successful
strategy for transferring Cleanroom technology to new teams. [...] The
combination of education and consulting has been found to be
absolutely essential.”

EP39 - “Our experience in offering three-day courses based on these
materials has been very positive. Equipped with this introduction to
formal methods and some follow-up consultations, practicing software
developers have successfully applied formal methods to requirements
specification on real projects.”

EP40 - “The availability and effectiveness of training represent crucial
factors
in
the
successful
diffusion
of
software
development
innovations.”
57

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are customer satisfaction, customer collaboration, customer
commitment, decision time, corporate culture, control, personal
characteristics, societal culture, and training and learning.”

EP70 - “Training increases an individual's ability to transfer knowledge
accumulated on one task to a related task [80]. Thus, training helps
increase developers' abilities to learn about the agile methodology and
transfer the knowledge to the real practice.” A referência citada no
trecho anteriormente transcrito diz respeito à Thompson et al. (2000).
FP4 - Percepção do Benefício
O benefício percebido por parte dos atores que participam do processo de
transferência da tecnologia ou por aqueles que simplesmente usarão a
tecnologia quando da relação entre a tecnologia e o ambiente em que se planeja
implantar é visto como um importante fator para que a adoção possa ocorrer com
maior velocidade.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP10, EP66, EP75 e EP77.

EP10 - “When people can perceive benefits to a new technology with only
a small initial investment in training, they will be more receptive to try it on
their own problems.”

EP66 - “Transferring innovative technologies and tools to practitioners has
long been investigated in the area of software technology [43–46]. In
particular, Pfleeger and Menzes [43] suggest the need for building a
technology transfer model to gain a better understanding of how
technology adoption works in individual organizations. Usually, such a
model entails an evaluation performed by intended users of the technology
to see whether it solves their problem.” As referências citadas no trecho
58
anteriormente transcrito dizem respeito à Pfleeger e Menezes (2000),
Raghavan e Chand (1989), Redwine e Riddle (1985), Rogers (1995),
respectivamente.

EP75 - “Adoption of tools and technologies widely perceived to be
community-based and supported on many platforms, such as Eclipse,
Java and Linux, has been easy in principle for universities, [...]”

EP77 - “A considerable number of factors can influence adoption of new
technologies, including characteristics of an organization, competitiveness
and management strategies of an organization, influences of internal and
external parties on the adoption decision process, characteristics of new
technologies, perceived benefits, organizational readiness, the CEO’s
attitude toward the adoption of new technologies, and the presence or
absence of top management support.”
FP5 - Cooperação ou Colaboração
A introdução bem sucedida de uma nova tecnologia é possível graças a
ativa cooperação daqueles que atuam na organização que irá realizar o processo
de adoção. A colaboração entre a academia e a indústria proporciona o avanço
do processo transferência e é considerada critério para que haja sucesso.
Abaixo são apresentadas as evidências coletadas a partir dos estudos primários
EP37, EP49, EP59 e EP69.

EP37 - “Successful introduction of new practices is only possible with
the active cooperation of the people in the target organization. It is not
enough if a consulting company only shows how things are to be done
in the future. To make sure that new practices will be performed, it is
necessary, that these practices are tailored to the organization. For this
task, the active cooperation of people in the target [...]”

EP49 - “This experience report presents highlights from the ongoing
effort to transfer an intelligent road-mapping technology based on the
concept of software engineering decision support to industrial practice.
59
We are currently in the fourth year of this process. Key factors for
progress achieved so far include: [...] Early and ongoing collaboration
between academia and industry to guide the direction of release
planning research and development, in order to advance that
technology. [...]”

EP59 - “In this chapter we present a list of success criteria and a
decision model for designing a successful technology transfer
approach in the global age. Possible Success Criteria:
o Use of (few) high-quality strategic external partners
o Excellent external partners
o Choice of partner to complement companyinternal coverage of
innovation process
o Close, trusting & continuing cooperation
o Joint transfer test labs (e.g., IESE R&D Lab)
o Complementary Personnel transfer
o Confidentiality (to avoid information flow to competitors)
o Etc.”

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are customer satisfaction, customer collaboration, customer
commitment, decision time, corporate culture, control, personal
characteristics, societal culture, and training and learning.”
FP6 - Material de Apoio (Packaging)
Na busca por informações que sejam relevantes e que possam facilitar o
caminho para a transferência tecnológica ocorra na organização, os agentes de
mudança e usuários locais necessitam de materiais de apoio. Materiais de
treinamento, ferramentas ou materiais que sirvam como fonte para consulta
trazem à tona informações relevantes e com poder de mudar a visão relacionada
à tecnologia.
60
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP18, EP28 e EP44.

EP18 - “Fundamental to our approach is the process package, a set of
documents and training material that communicates everything about the
technology you are trying to transfer.”

EP28 - “We had a theory, based on experience in collaborative work, the
results of a workshop, and technology adoption and diffusion literature,
that a packaged set of materials for organizational change agents would
expedite the introduction of software technology. This theory was
supported by work in organizations where we used a defined model of
technology introduction (the TxM): our collaborators had asked for
additional materials, specifically examples, coordinated with both the TxM
and the software CMM.”

EP44 - “[...] can develop a competitive advantage by articulating business
process improvement that can be achieved by infusing B2B technology
and packaging it for use in ARM. It’s design and construction will take into
account the need for a system that is transferable to other SMEs and
organisations that have similar requirements.”
FP7 - Custo
O custo-benefício é considerado um dos principais incentivos para que a
transferência de tecnologia possa ocorrer, seja em relação ao custo com
marketing ou o próprio custo final da tecnologia, tornando-se fator que diferencia
aqueles que adotam daqueles que não.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP1, EP9 e EP19.

EP1 - “The major incentives for transfer in URBIS are cost and time
savings and availability of special and/or sophisticated applications [...]”
61

EP9 - “Data analyses suggest that PLATO developers made decisions
reflecting viable dissemination theory and practice of the time,
committed substantial resources to the dissemination process, and
selected what appeared to be a cost-effective marketing strategy.”

EP19 - “The results of data analyses revealed that, of the seven
variables, existence of a product champion, strong top management
support, low IS expertise, perception that CASE technology has greater
relative advantage over other alternatives, and a conviction on the cost
effectiveness of the technology were found to be important factors to
differentiate adopters from non-adopters.”
FP8 - Agente
O agente é aquela entidade responsável por intermediar a relação entre
a academia e a indústria, de modo a facilitar o processo de transferência
tecnológica e assim poder promover uma atividade bem sucedida. Geralmente
este papel é exercido por centros de análise de informações.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP4, EP5 e EP79.

EP4 - “Various methodologies and mechanisms exist for this transfer
process. One process, using an information analysis center as a
transfer agent, is appealing because the capability of the information
analysis center as synthesizer of technology fits the task of transferring
technology in such a way that the software developer and user can
understand and evaluate the technology.”

EP5 - “Technology transfer activities can be carried out in a formal or
informal manner. Technology transfer agents employ the formal
approach which consists of locating the relevant technology and
reformulating it to a form which is usable by the recipient.”

EP79 - “This research assumed that the unit of adoption is an
organization. However, it is possible to generalize the agent behavior
62
to other units of adoption, such as a department or project or individual.
Of course, model parameters would have to be modified. Such a
generalization would facilitate hybrid (OSS and PS) adoption in
organizations.”
FP9 - Senso de Oportunidade (Timing)
O senso de oportunidade é um dos mais importantes fatores relacionados
a transferência tecnológica por perceber o momento certo ou hora oportuna para
que uma determinada ação possa ocorrer, realizar a transferência da tecnologia
com sincronismo.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP54 e EP69.

EP54 - “Successful technology transfer is a function of many critical
parameters among which timing is one of the more important. A
business unit that stands in front of crucial decisions or problems
regarding current- or future technology tends to be receptive for
influences from others.”

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are customer satisfaction, customer collaboration, customer
commitment, decision time, corporate culture, control, personal
characteristics, societal culture, and training and learning.”
FP10 - Compatibilidade com o Processo atual
É muito mais simples transferir uma tecnologia que seja compatível com
o atual processo de atividades do ambienteda organização do que transferir
qualquer coisa que seja forçada. Ser compatível com o que já ocorre na indústria
é facilitador para que a transferência ocorra de forma positiva.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP33 e EP45.
63

EP33 - “It is far easier to transfer technologies that support processes
people already perform, than to transfer anything that forces them to
adopt a new process.”

EP45 - “However, in terms of general lessons learned with respect to
technology transfer, these results indicate that: New technologies
should be properly aligned with high priority problems [...] New
technologies must be well-aligned with exiting processes [...] Support
tools must be suitably mature, particularly if the technology underlying
the tools requires continual re-calibration to the environment [...]
Training activities must focus on the way the technology will be used in
practice.”
FP11 - Resposta ou Retorno (Feedback)
O conhecimento adquirido com um feedback efetivo é crucial para uma
plena assimilação das inovações. O processo de fornecimento de informação
sobre a transferência de tecnologia faz como que a adoção seja realizada de
forma mais eficaz.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP57 e EP84.

EP57 - “The overall impact and benefits of research infusion to space
systems are several: previously inaccessible software assurance
technologies have been successfully infused; some have been
adopted for inclusion in organizations’ development practice; several
have continued to be used for some time following the end of the
collaboration; the software development team has provided feedback
to the technology developers; and, lesson learned have been identified
regarding
the
challenges
and
success
factors
for
software
development within NASA.”

EP84 - “The rationale is that knowledge gained by effective feedback
and reflective learning is crucial for the successful assimilation of
adaptive innovations such as AM.”
64
FP12 - Integração
Um modo eficaz de realizar a transferência de tecnologia é por meio da
integração de uma nova tecnologia com um projeto ou produto que possui
diversas outras funcionalidades e que já está em andamento.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP12 e EP64.

EP12 - “Integration of new software methods with ongoing projects can
be an effective means of technology transfer in some environments [...]
Finally, the product provided a convincing demonstration of the
effectiveness of the methods.”

EP64 - “Such transfer took almost 20 years to reach blue-chip
companies such as Microsoft. But model-checking technology is
already part of commercial products [...]”
FP13 - Cultura
O conjunto de tradições, estruturas sociais, conhecimento adquirido
atuam de modo a influenciar o processo de avaliação da transferência
tecnológica. A cultura de uma comunidade influencia o modo pelo qual a
tecnologia será recepcionada.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP69 e EP78.

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are [...], corporate culture, [...] societal culture, [...]”

EP78 - “[...] the strong community-oriented OSS culture highlighted in
the previous section implies that the effect of social influence on OSS
adoption is more likely to manifest in the form of social identification
with the OSS community [...]”
65
FP14 - Relacionamento
Profissionais que estão incubidos de realizar a transferência da tecnologia
precisam
manter
um
relacionamento
profissional
entre
os
grupos
organizacionais e profissionais-chave, de modo a facilitar a adoção tecnológica.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP13 e EP60.

EP13 - “The key to the success of these technology transfer and
software development efforts was the relationship between the
development projects and the process group [...]”

EP60 - “Success in applying a new software engineering technology in
the context of a significant application requires a good working
relationship among the application developers and the technology
developers.”
FP15 - Pessoa-Chave
Os champions ou gatekeepers são pessoas-chave com grande respeito
dentro de uma organização e que possuem contatos externos e internos no que
tange às novidades do mercado tecnológico. Está também entre suas atribuições
o poder de filtrar e propagar uma nova idéia (BUXTON; MALCOLM, 1991).
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP19 e EP36.

EP19 - “The results of data analyses revealed that, of the seven
variables, existence of a product champion, [...] were found to be
important factors to differentiate adopters from non-adopters.”

EP36 - “In NP, the managing directors acted as champions striving to
improve by encouraging, arguing, and convincing the SEPG and the
developers to get the implementation process off the ground.”
66
FP16 - Parceria
Empresas precisam trabalhar em parceria com outras de forma a superar
desafios com uma maior eficiência, complementando a cobertura interna da
organização e conduzindo a um resultado benéfico quando a proposta por
adoção de uma tecnologia.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP59 e EP77.

EP59 - “In this chapter we present a list of success criteria and a
decision model for designing a successful technology transfer
approach in the global age. Possible Success Criteria:
o Use of (few) high-quality strategic external partners
o Excellent external partners
o Choice of partner to complement company internal coverage of
innovation process [...]
o Joint transfer test labs (e.g., IESE R&D Lab) [...]”

EP77 - “A considerable number of factors can influence adoption of
new technologies, including characteristics of an organization,
competitiveness and management strategies of an organization,
influences of internal and external parties on the adoption decision
process, characteristics of new technologies, perceived benefits,
organizational readiness, the CEO’s attitude toward the adoption of
new technologies, and the presence or absence of top management
support”
FP17 - Motivação
Motivar a equipe por meio de estímulos internos e externos para que esta
possa caminhar em igualdade com os interesses da indústria é considerado um
combustível necessário para que a tecnologia não seja rejeitada em um primeiro
momento, quando se deseja adotá-la.
Abaixo são apresentadas as evidências coletadas a partir dos estudos primários
EP3 e EP46:
67

EP3 - “But software engineering technologies will be accepted and used
by even the most mediocre programmer if there is adequate motivation
provided.

EP46 - “This study has examined factors that motivate developers to adopt
and sustain use of SPIs Previous research has noted the importance of
SPIs having ‘visible success’ in order to motivate developers to use them.”
FP18 - Reorganização Societária
A reorganização que muitas indústrias sofrem devido a mudanças
societárias, acarreta em mudança de visão quando da decisão de se realizar a
adoção tecnológica.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP14:

EP14 - “Many attempts within large companies to collaborate on
technology transfer and other issues are failed by [...] continual corporate
reorganization. Thus it is important that the envisioned entity: [...] be an
independent legal entity sponsored by multiple organizations [...] have a
balance of power between the organization's leadership and its corporate
sponsors [...] have a lean and small organization.”
FP19 - Trabalho e Dedicação
É importe que haja dedicação e trabalho, direcionando esforços para que
seja gerado resultado que colabore de alguma forma com o sucesso da
transferência tecnológica.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP15:

EP15 - “There are additional factors which contributed to the successful
technology transfer. [...] The hard work and dedication of the
Cleanroom teams has also been a factor in making the transfers
successful.”
68
FP20 - Compromisso com o Cliente
Seja em que fase esteja, o foco está no compromisso com o cliente. A
equipe técnica precisa estar alinhada com a necessidade do cliente para que
seja possível produzir e transferir a tecnologia com sucesso.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP69.

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are [...] customer commitment, [...]”
FP21 - Desejo de Inovar
O desejo da indústria ou de quem representa a indústria de inovar, de ser
o primeiro a utilizar a tecnologia, mesmo que não haja evidência suficiente de
sua eficiência é fator que determina uma adoção tecnológica.
Abaixo são apresentadas as evidências coletadas a partir dos estudos primários
EP71.

EP71 - “The motivation of the industrial partner for moving to the web was
less a desire to be technically innovative than the need to accommodate
the changing business requirements of its customers.”
FP22 - Ambiente
O ambiente em que a tecnologia é aplicada, a possibilidade de se utilizar
a tecnologia em um ambiente de produção de modo a testar sua adequação
causa influência na sua adoção.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP80:

EP80 - “Our most important conclusion is that it is crucial to provide an
environment in which technology resulting from research can have an
immediate impact on practice. Such an environment should also let
69
practice have an immediate impact on how the research on these
technologies will evolve.”
FP23 - Normas
Um documento contendo especificações técnicas, um conjunto de boas
práticas organizacionais para serem utilizadas como regra acelera a
transferência tecnológica.
Abaixo é apresentada a avidência coletada a partir do estudo primário EP70:

EP70 - “Previous research has found that [...] norms are important factors
that facilitate knowledge transfer [54,65].” As referências citadas no trecho
anteriormente transcrito dizem respeito à Menon e Pfeffer (2003),
Reagans e McEvily (2003), respectivamente.
FP24 - Trabalho em Equipe
Quando duas organizações trabalham juntas, em equipe, e cujo propósito
é comum entre as partes, facilita a transferência da tecnologia e gera resultados
benéficos para a organização.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP80:

EP80 - “Infusing new technology is difficult, so what makes an infusion
successful? Second to the support from NASA IV&V, the most important
success factor was probably the fact that the two organizations worked
together as one team.”
FP25 - Protótipo
O projeto piloto possui a missão de coletar informações de modo a servir
de subsídio para adequações da tecnologia para que em um segundo momento
possa ocorrer uma adoção com menor taxa de erro.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP49.
70

EP49 - “This experience report presents highlights from the ongoing
effort to transfer an intelligent road-mapping technology based on the
concept of software engineering decision support to industrial practice.
We are currently in the fourth year of this process. Key factors for
progress achieved so far include: [...] Early development of a
technology prototype that enabled early evaluation and end-user
feedback to us [...]”
FP26 - Recompensa
O usuário da tecnologia precisa se sentir valorizado pela adoção da
tecnologia que está sendo proposta, esta valorização pode vir por meio de
incentivos internos e se faz necessário deixar claro toda e qualquer vantagem
que a tecnologia possa trazer.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP70:

EP70 - “Previous research has found that rewards [...] are important
factors that facilitate knowledge transfer [54,65].” As referências citadas
no trecho anteriormente transcrito dizem respeito à Menon e Pfeffer
(2003), Reagans e McEvily (2003), respectivamente.
FP27 - Fácil de Usar
Os profissionais que percebem que a inovação tecnológica é simples e de
fácil utilização são propensos a aceitar a tecnologia em seu ambiente em um
tempo menor.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP43:

EP43 - “Software developers who perceived the technological innovation
to be useful or easy-to-use were more satisfied in their jobs, as were those
developers who perceived the innovation to be compatible with prior
approaches to software development.”
71
FP28 - Reutilização do processo de gestão
O ato de se reutilizar o processo de gestão já utilizado para realizar
transferências tecnológicas acelera e fomenta a adoção da nova tecnologia no
ambiente organizacional.
Abaixo é apresentada a evidência coletada a partir do estudo primário
EP27.

EP27 - “[...] the reuse management process strand, which we see as
critical to successful technology transfer.”
FP29 - Tratamento da transferência
A tecnologia que se está tentando transferir precisa ser tratada de forma
adequada e ambientada à necessidade da organização para assim ser aceita e
adotada. Todo o processo de transferência de tecnologia precisa ser respeitado
para que possa haver uma adoção adequada.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP34:

EP34 - “We find that the key factor to successful introduction of
technologies is not how good the chosen technology is, but in how well
the transfer is handled [...]”
FP30 - Flexibilidade
A possibilidade de se modificar, adicionar passos e iterações é necessário
para satisfazer as demandas da indústria e necessidades dos pesquisadores.
Deste modo, a flexibilidade é considerada como fator importante para uma bem
sucedida transferência tecnológica.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP58

EP58 - “Thus, flexibility is an important ingredient of successful
technology transfer. Openness to modifying and adding steps and
72
iterations is necessary to satisfy industry demands of risk minimization
and relative value evidence as well as researcher needs.”
FP31 - Vantagem Relativa
Vantagem relativa é vista como o grau pelo qual a inovação é percebida
como sendo superior em algum aspecto à tecnologia que pretende substituir no
ambiente de produção.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP19.

EP19 - “The results of data analyses revealed that, of the seven
variables, existence of [...] perception that CASE technology has
greater relative advantage over other alternatives, and a conviction on
the cost effectiveness of the technology were found to be important
factors to differentiate adopters from non-adopters.”
FP32 - Ferramentas CASE
Para manter a qualidade e apoiar as atividades de desenvolvimento de
software é importante a utilização de ferramentas case. Estas ferramentas
facilitam a adoção de novas práticas.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP74.

EP74 - “[...] organizations adopting OSS development practices are
also frequently using OSS CASE tools to facilitate the adoption of these
practices [...]”
FP33 - Caso de Negócio
Para que a tecnologia seja implantada com sucesso, precisa-se fazer uso
do caso de negócio, de forma a demonstrar o impacto, servindo como meio para
armazenar toda informação relevante que possa colaborar com o projeto.
73
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP52.

EP52 - “Universities attempting to interest industry in a technology
change would do well to decide which of the top-level P/L lines the
innovation is targeting. Once the relevant P/L targets are selected the
university researchers should attempt to build a business case that
demonstrates the impact of the innovation; the outcome may be to
sharpen the marketing of the technology.”
FP34 - SOA
A transferência de tecnologia é acelerada por meio da aplicação da
arquitetura orientada a serviço, atuando na disponibilização das funcionalidades
implementadas como serviço.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP53.

EP53 - “Regard technology transfer as a service, service-oriented
architecture can be applied to accelerate right technology transfer.”
FP35 - Público
Profissionais tendem a buscar por aplicações que venham a colaborar
com suas atividades do dia a dia e geralmente então prontos para assimilar a
tecnologia, demonstrando ser o público certo para que seja transferida.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP26.

EP26 - “The target audience of private sector technology transfer
professionals is ready and willing to use the Internet and the WWW to
interact with federal laboratories to learn about new technologies and
business opportunities.”
74
FP36 - Melhoria Contínua
A proposta de adoção de uma nova tecnologia que possa vir a aprimorar
a prática existente na organização, assim como a sua adoção, proporciona uma
mudança positiva nas atividades internas e externas.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP32.

EP32 - “Continuous improvement – either evolutionary by optimizing
the use of the existing technology portfolio, or revolutionary by jumping
onto a new technology curve – is a prerequisite for success and needs
to be managed well.”
FP37 - Competitividade
A competitividade impõe a necessidade por inovar para se manter no
mercado, assim como a necessidade de manter a liderança, tendendo a facilitar
a adoção da tecnologia e acelerar todo o processo de transferência mesmo que
a tecnologia não esteja madura o suficiente.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP77.

EP77 - “A considerable number of factors can influence adoption of
new technologies, including characteristics of an organization,
competitiveness and management strategies of an organization,
influences of internal and external parties on the adoption decision
process, characteristics of new technologies, perceived benefits,
organizational readiness, the CEO’s attitude toward the adoption of
new technologies, and the presence or absence of top management
support”
FP38 - Satisfação do Cliente
Atender a necessida do cliente, observando o ambiente e procurando
encontrar por meio da tecnologia forma de satisfazer a vontade do cliente torna
a transferência uma atividade com mais índice de sucesso.
75
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP69.

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are customer satisfaction, [...]”
FP39 - Características pessoais
As características do ser humano, seja do modo em que trabalha, da
forma como enxerga uma situação no ambiente de trabalho, etc, servem de
motivação para que a tecnologia possa vir a ser adotada e coloca em produção.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP69.

EP69 - “Determining the factors that lead to the success of software
development projects that want to adopt ASD practices. We have found
that 9 of the 14 hypothesized factors significantly relate with success.
They are [...] personal characteristics, [...]”
FP40 - Comunicação
A comunicação entre aqueles que estão relacionados de alguma forma
com a tecnologia que está sendo proposta para transferência visa promover a
troca de informações de forma a alcançar um entendimento mútuo e facilitar a
adoção tecnológica.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP48.

EP48 - “[...] had realized that one-year funding resulted in a lack of
stability within SARP. In this capacity, she pushed for three year
funding of SARP initiatives. This had previously been thought of as an
insurmountable barrier. Strong communication between the IV&V
Facility and Dr. John Kelly, representing the NASA Office of the Chief
Engineer (OCE), made this change possible.”
76
FP41 - Projetos de Pesquisa
O projeto de pesquisa como um retrato da pesquisa e roteiro do trabalho
que está em andamento é considerado meio pelo qual a indústria pode patrocinar
e utilizar para que a tecnologia seja produzida e venha a ser adotada pela
organização com maior eficácia.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP8.

EP8 - “Although all of the recommendations would enhance the theory
by either refining or testing it, the recommendation with the greatest
payoff to both theory and practice is that involving the use of more
appropriate research designs [...] perhaps we can provide practitioners
with a theory powerful enough to assist them in making ex ante
statements about adoption behavior for software engineering
innovations.”
4.3.2 Fatores Negativos
Q1 – Que fatores influenciam negativamente a transferência de tecnologia
entre academia e indústria em engenharia de software?
O objetivo da questão de pesquisa é identificar os fatores negativos que
influenciam a transferência de tecnologia entre academia e indústria no campo
da engenharia de software. O surgimento das categorias se deu de forma
automática. Cada estudo pode estar relacionado a mais de uma questão de
pesquisa ou a mais de uma categoria, tendo em vista que em alguns estudos
primários foi encontrada a ocorrência de mais de um fator. Esta seção apresenta
as evidências por categoria.
FN1 - Custo
O custo com licenciamento, treinamento, o investimento que é ou deverá
ser feito para que a transferência da tecnologia possa ocorrer no ambiente
industrial são considerados limitadores.
77
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP15, P16, EP23, EP24, EP62 e EP78.

EP15 - “Results indicate that the CSTC has developed a successful
strategy for transferring Cleanroom technology to new teams.
Cleanroom skills take study and practice to develop, and a learning
curve is involved, but experience shows these start-up costs can be
accommodated within project schedules and resources.”

EP16 - “There are many factors which have to be considered ([5]). In
particular the costs for buying SEE components are only a small part
of the investment. For instance it may be necessary to employ new
developers. It may be useful to change the enterprise organization and
it may be necessary to buy new hardware. The costs of all these
changes must be added to the overall costs of the deployment.” A
referência citada no trecho anteriormente transcrito diz respeito à Huff
(1992).

EP23 - “Early adopters of network technologies like OO incur
considerable costs simply because they have joined a small and
immature technological network.”

EP24 - “OO represents a different “paradigm” from structured
techniques. Thus, the move to completely adopt the OO approach is
very costly in personnel costs. It has been suggested that training time
is typically 6 to 18 months for OO developers [...]”

EP62 - “[...] there are factors that constrain immediate adoption. For
example, a high TRL commercial product may have a high license fee,
accommodation of which requires advance budgetary planning.”

EP78 - “Lending support to this conjecture are prior studies that have
documented substantial learning costs and concerns over on-going
training and support as two major barriers to OSS adoption [26,28].” As
78
referências citadas no trecho anteriormente transcrito dizem respeito
à Goode (2005), Gwebu e Wang (2010), respectivamente.
FN2 - Falta de ferramenta
A falta de ferramentas tecnológicas que auxiliem o processo de
transferência, seja automatizando alguma etapa, gerando informações
relevantes para a tomada de decisão, e etc, é considerada uma limitação à plena
ocorrência da adoção tecnológica.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP21, EP47 e EP60.

EP21 - “One factor limiting the use of formal methods is the lack of
investment in automated tools and support structures to reduce the
efforts of applying these methods. In fact, lack of support tools is often
seen as a major barrier to using formal methods.”

EP47 - “The slow adoption of developer testing is primarily due to the
lack of tools that automate some of the more tedious and timeconsuming aspects of this practice.”

EP60 - “Barriers to wider deployment of program model checking for
real-world applications include the large, usually unbounded, state
space of the application; the lack of tools (model checkers) that accept
common programming languages; [...]”
FN3 - Falta de entendimento
Aqueles que farão uso da tecnologia, seja quem lida com a gerência da
informação ou quem está na ponta, se preparando para utilizá-la no dia-a-dia
precisa de entendimento suficiente, tendo em vista que algumas tecnologias são
de difícil compreensão em um primeiro momento, e esta falta de entendimento
se torna um limitador para toda a atividade.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP35, EP38 e EP76.
79

EP35 - “To couch a technology in terms of a solution to the customer’s
business problem requires deep insight and understanding of the
customer’s business and industry - which the technology transfer group
may not have.”

EP38 - “[...] technology transfer is inhibited by lack of packaging, by
lack of relationship to a pressing technical or business problem, and by
difficulty of use and understanding [...]”

EP76 - “In software process simulation practice, potential customers
are usually unfamiliar with using simulation as a process management
tool. Consequently, they often do not understand well how simulation
results can be used to support their process management decisions.
[...] Others react mostly with skepticism at the ability to obtain the data
necessary to produce an accurate simulation. [...] These reactions
represent barriers to putting software process modeling into practice
[...]”
FN4 - Formação e Aprendizagem
O treinamento visa demonstrar o benefício de forma prática, simulando
situações reais tratadas por meio da nova tecnologia. A importância da educação
profissional, do treinamento recebido por aqueles que farão uso da tecnologia no
dia-a-dia e/ou aqueles que possuem poder de decisão técnica, é percebida em
todos os ambientes envolvidos. A falta ou o treinamento inadequado pode inibir
a adoção da tecnologia.
Abaixo é apresentada a evidência coletada a partir do estudo primário EP6, EP25
e EP33.

EP6 - “The following reasons state why, in particular, this has proved
inadequate for 'me too': [...]
o Managers did not attend the course and therefore failed to
appreciate the advantages of the method, hence their
reluctance to invest in it.”
80

EP25 - “One of the main problems in correct TT is that many people
still think that the adoption of a new software technology by an
organization is straightforward and that anyone can do it. The view is
that it is enough to replace the equipment, install the new software,
supply user manuals and train a small group of people. This mistaken
view may be due to the eminently technical training of the person who
generally acts as the change agent, which means that he/she tends to
look at the problem from the hardware/software perspective, seeing
these as the only TT components.”

EP33 - “Every time we tried to transfer a technology, managers and
developers were too busy fighting fires to take notice. They did not have
time to take the training, read the manuals, or update to current
versions of the tools.”
FN5 - Resistência a mudança
Algumas decisões corporativas urgem por aplicabilidade no ambiente de
trabalho por demonstrarem evidências claras de sua eficácia, mas estes fatores
não são autossuficientes para que haja adoção tecnológica. Profissionais que
lidam a algum tempo com um estilo peculiar de exercer suas atividades em seu
meio tendem a resistir à mudança, fazendo com que seja necessário o
convencimento da equipe antes que haja a adoção para ampla prática. Esta
resistência é fator impeditivo.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP10 e EP41.

EP10 - “A major obstacle for the effective use of any new technology
is convincing people to change their approach to their job; to work in a
different way.”

EP41 - “The adoption of a methodology represents a significant change
in work practices, and many developers are resistant to such change”
81
FN6 - Falta de correspondência
Algumas necessidades locais da indústria, ou de setores desta,
proporcionam abertura quando não ainda satisfeitas pelo acervo tecnológico
atuante. Esta abertura quando não combinada com o que a tecnologia tem a
proporcionar, gera um limitador para que haja adoção.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP1 e EP29.

EP1 - “In OECD the problems with transfer are similar; primarily lack of
match between local needs and the, capabilities of potentially
transferrable applications.”

EP29 - “[...] we found that the greatest barriers to transfer did not come
from the developer community (which was motivated to use our work),
but came from mismatches between our system and the needs of the
users.”
FN7 - Comunicação
A comunicação entre pesquisadores acadêmicos e profissionais da
indústria é considerada barreira importante, quando não a primeira barreira a ser
superada para a transferência da tecnologia. Pesquisadores e profissionais
falaram línguas diferentes, seus vocabulários, siglas e gírias são diferentes e
geram grande dificuldade de entendimento por ambos os lados. Segundo Rogers
(2003, p.5) a comunicação é um processo em que os participantes criam e
compartilham informações entre eles de forma a alcançar um entendimento
mútuo (ROGERS, 2003, p.5).
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP50 e EP73.

EP50 - “Perhaps the first barrier to adoption is communication. It’s no
secret that academic researchers and industrial practitioners speak
different languages. Their vocabulary is different, the acronyms they
82
use are different, and their slang is different. Consequently, when an
academic approaches someone from industry and attempts to describe
their work using academic terminology, the person from industry may
have great difficulty understanding its relevance.”

EP73 - “Another conclusion is that the cooperation between the
academic and the industrial world is not always easy—there are many
pitfalls in the technology transfer process. As indicated by the lessons
learned, the essential factors in a close cooperation are of social and
communicational nature; these are usually difficult to control.”
FN8 - Falta de maturidade
A tecnologia para ser transferida à prática precisa alcançar maturidade
suficiente que a faça exercer o seu papel na indústria. Contudo não só a
maturidade da tecnologia é suficiente, em alguns casos a equipe que está
envolvida com a atividade de transferência também precisa ter maturidade em
relação ao objeto da adoção. Deste modo, a falta de maturidade é considerado
fator impeditivo para que ocorra a transferência da tecnologia.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP13 e EP56.

EP13 - “The lack of development experience and the relative
immaturity of the methods required a close relationship among
customers, developers, and methodologists to ensure acceptance and
success.”

EP56 - “There are many obstacles to software engineering technology
infusion within NASA [...] include a significant gap in the perception of
adequate maturity when viewed from a researcher’s and practitioner’s
viewpoint; [...]”
FN9 - Evidência
Na indústria, os tomadores de decisão hesitam em implantar novas
técnicas de engenharia de software em decorrência da falta de evidências que
83
comprovem os benefícios e os riscos ao ambiente, tornando lento todo o
processo de transferência, quando não encerrando a atividade.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP7 e EP61.

EP7 - “There are several reasons for the difficulty in transferring
requirements specification approachers [...] Some of the approaches
are not robust enough for industrial use and require a large investment.
Also, there is a lack of concrete evidence that the use of the
approaches would improve the process of developing software.”

EP61 - “One potential reason for the slow transfer of software
engineering techniques is that decision makers in industry hesitate to
introduce new techniques, as evidence on the benefits and risks is not
or not easily available.”
FN10 - Experiência
Algumas tecnologias para serem adotadas precisam que profissionais
experientes estejam envolvidos no processo. Deste modo, desenvolvedores de
software que não tenham experiência suficiente em relação ao tipo de tecnologia
que se deseja implantar tendem a comprometer todo o esforço empregado e
dificultar a realização da transferência.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP13.

EP13 - “The lack of development experience [...] of the methods
required a close relationship among customers, developers, and
methodologists to ensure acceptance and success.”
FN11 - Recompensas Pessoais
Os atores envolvidos na atividade de transferência, mais especificamente
aqueles que estarão lidando com a tecnologia no dia-a-dia, precisam entender
de forma clara que recompensa pessoal lhes será concebida por intermédio da
adoção, caso contrário este causará dificuldade.
84
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP30.

EP30 - “Technology change management is a challenging task [3]-[8].
Key lessons we have learned include: [...]
o Technologists
may
resist
“pre-packaged”
technology
information because of the personal rewards of reinventing. It
may be perceived as more rewarding to create rather than
reuse. [...]” As referências citadas no trecho anteriormente
transcrito dizem respeito à Stokes (1991), Schaffer e Thomson
(1992), respectivamente.
FN12 - Cultura
A cultura que habita no meio onde a tecnologia está para ser implantada
é enxergada como fator que pode criar barreira para a adoção caso haja a
percepção de que a disponibilização da tecnologia de forma ampla venha a gerar
perda de poder pessoal, afinal o acesso aberto a informação tende a equiparar
o conhecimento.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP30.

EP30 - “Technology change management is a challenging task [3]-[8].
Key lessons we have learned include: [...]
o The culture may resist broad dissemination of technology
information. Knowledge is power, and there may be a perceived
loss of personal power if information is widely available. This is
best addressed by top management communicating and
enforcing their desire for an open environment” As referências
citadas no trecho anteriormente transcrito dizem respeito à
Stokes (1991), Schaffer e Thomson (1992), respectivamente.
FN13 - Incerteza
A indústria, antes de iniciar o processo de transferência da tecnologia alvo,
tende a buscar informações por meios de midias de massa, como jornais,
85
revistas, internet e etc, de modo a reduzir a incerteza que permeia o objeto.
Nestes casos, quanto mais elevado o nível de incerteza, mais lento e complicada
será a atividade de adoção.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP82.

EP82 - “An organization’s decision to adopt a software or system is
usually preceded by a phase where the intent is to reduce the
uncertainties surrounding the innovation by acquiring information,
mainly through mass media [...]”
FN14 - Percepção do benefício
A não percepção do benefício que a tecnologia trará para o ambiente de
produção, na visão dos atores que detem o poder de decisão na indústria, tende
a se tornar barreira antes mesmo que esta seja proposta.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP83.

EP83 - “These findings, summarized along with their implications in
Table 6, highlight the need for adoption researchers to examine both
enabling and detracting factors and the dialectic interplay between the
two. In particular, since training, subjective norm, experience, and the
interaction between perceived benefits and perceived hindrances are
the key factors, research might focus on how to leverage these factors
effectively, and how to facilitate the dialog regarding perceived benefits
and hindrances.”
FN15 - Relacionamento
A transferência de tecnologia é inibida por falta de relacionamento, seja
entre os profissionais da indústria e os pesquisadores da academia ou entre a
solução proposta e o problema exposto.
86
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP38.

EP38 - “[...] technology transfer is inhibited by [...] by lack of relationship
to a pressing technical or business problem, [...]”
FN16 - Deficiências gerais
As deficiências gerais que habitam no modo como a tecnologia é
transferida são vistas como inibidoras no que tange a adoção de uma nova
tecnologia.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP11.

EP11 - “A number of difficulties stand in the way of transferring formal
specification techniques to instrument system design. These are
difficulties in large part related to the general shortcomings of existing
formal specification techniques [Cunningham et al 1985). They may be
divided into the following categories' language, method, validation,
verification, automated support and technology transition.” A referência
citada no trecho anteriormente transcrito diz respeito à Cunningham et
al. (1985).
FN17 - Retorno claro
Deve-se estar claro para a indústria o retorno quando da adoção da
tecnologia e nesses casos boas habilidades de consultoria servem para auxiliar
o processo com informações relevantes que possam municiar a transferência
tecnológica. A não demonstração do retorno de forma objetiva e que justifique a
mudança, se torna um empecilho.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP17.

EP17 - “Sometimes that means you can't change during the current
project unless there is a clear payoff In a decentralized, empowered
87
organization, this is a critical factor. It requires developing good
consulting skills and excellent listening habits.”
FN18 - Resposta ou Retorno (Feedback)
Modelos de transferência de tecnologia tendem a fracassar por não haver
mecanismos que proporcionem feedback com informações relevantes que
possam dar suporte a implantação.
Abaixo são apresentadas as evidências coletadas a partir do estudo primário
EP20.

EP20 - “We conclude that successful models of technology transfer
may not available because either: the feedback loop is deemphasized
or the cooperative aspects are not supported.”
FN19 - Agenda e Orçamento Apertado
A competitividade do mercado tem feito emergir a necessidade de obter a
inovação, o objeto de desejo da indústria, no menor espaço de tempo possível
com o menor orçamento. Nesse contexto, por orçamento e por prazo insuficiente
a tecnologia tende a não ser plenamente adotada.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP34.

EP34 - “Some of the major hurdles that these organizations face during
technical transfers are tight schedules and budgets.”
FN20 - Expectativa
O valor da tecnologia pode ser visto de forma diferente, gerando
expectativas diversas entre quem está propondo a transferência e aquele que
está recepcionando, o valor da tecnologia pode ser visto de perspectiva
diferente, agindo como inibidor.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP54.
88

EP54 - “A big risk when it comes to technology transfer is that
expectations from all parties deviate. The transferer and the receiver
can have different expectations on the value that the new technology
can bring.”
FN21 - Aversão ao Risco
A aversão que os desenvolvedores de software possuem quando se trata
de alguma tecnologia que possa trazer risco ao ambiente em que se tenta inserir
cria obstáculo para que a adoção da tecnologia possa ocorrer.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP56.

EP56 - “There are many obstacles to software engineering technology
infusion within NASA [...] include a significant gap in the perception of
adequate maturity when viewed from a researcher’s and practitioner’s
viewpoint; [...] the risk-averse nature of most NASA software
developers; and the differing motivation structures for researchers and
developers.”
FN22 - Perspectiva
Entre os maiores desafios está a falta de uma consistente perspectiva
sobre a inovação. Esta diferença de visão afeta como a inovação é medida e
executada, inibindo a transferência tecnológica.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP87.

EP87 - “The study found that among major challenges is a lack of a
consistent perspective of innovation. This difference in views affects
how innovation measurement initiatives are conceived (what is
considered key aspect of innovation) and executed (which metrics are
required to capture a particular aspect).”
89
FN23 - Intervenção da Gerência
A transferência da tecnologia para a indústria tende a ser uma atividade
laboriosa e que depende de diversas variáveis para que possa alcançar a plena
adoção. A gerência pode utilizar de sua atribuição e poder dentro do ambiente e
intervir para que a tecnologia possa ser implantada ou não.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP81.

EP81 - “Evidence suggests that MDD tools and techniques are not
being as broadly adopted as expected, despite the advantages they
introduce in certain phases of the development process. Insofar as
beliefs are determinants of individuals' intentions to use the MDD
paradigm, it would be clearly valuable to know what management
interventions and/or other factors can positively influence the UMAM
variables.”
FN24 - Público errado
A adoção tecnológica se torna lenta, incompleta e inadequada por se
abordar o público errado. Encontrar o público em potencial para a tecnologia é
uma tarefa complicada e muitas vezes não exata.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP31.

EP31 - “Because the potential audience for a technology is not the
same as the population of software developers at large, slow,
incomplete or inadequate adoption is often due to addressing the
wrong audience.”
FN25 - Falta de orientação
Desenvolvedores de software precisam de orientação quando passam a
vivenciar uma nova forma de executar tarefas do dia-a-dia e a falta dessa
orientação cria barreiras para a adoção da tecnologia.
90
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP60.

EP60 - “Barriers to wider deployment of program model checking for
real-world applications include the large, usually unbounded, state
space of the application; [...] and the lack of guidance for software
developers on how to take verification requirements into account during
development.”
FN26 - Ambiente
A falta de adaptação gera dificuldade ou impossibilidade para que a
adoção ocorra. Está de acordo com o ambiente alvo da inovação é primordial e
deve ser observado sempre que houver intenção de se transferir uma tecnologia.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP2.

EP2 - “Finally, by their very nature, nonroutine computer applications
imply use of technology which is designed specifically for one set of
institutional and political circumstances. To transfer such technology to
a different political and institutional setting is difficult, and in some
cases perhaps impossible.”
FN27 - Robustez
Algumas tecnologias não são robustas o suficiente para atender as
necessidades da indústria diante da competitividade do mercado, que de tempos
em tempos tem se tornado ainda mais exigente.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP7.

EP7 - “There are several reasons for the difficulty in transferring
requirements specification approachers [...] Some of the approaches
are not robust enough for industrial use [...]”
91
FN28 - Material de Apoio (Packaging)
A falta de material como documentos, material de treinamento e
ferramentas que apoie a adoção tecnológica com informações relevantes
transforma a transferência tecnológica em uma atividade complicada.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP38.

EP38 - “[...] technology transfer is inhibited by lack of packaging, by
lack of relationship to a pressing technical or business problem, and by
difficulty of use and understanding [...]”
FN29 - Core Business
Estar em desacordo com o tipo de negócio praticado e que interessa para
a indústria torna a adoção uma atividade desafiadora.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP68.

EP68 - “[...] we experienced that technology transfer is particularly
challenging when the technology to be transferred does not belong to
the core business of the receiving organization.”
FN30 - Sucesso do Negócio
Grande tecnologias são propostas no mercado e muitas empresas
consideradas grandes e bem sucedidas tendem a ignorar por estarem obtendo
sucesso com o que atualmente possui em seu acervo.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP59.

EP59 - “[...] we present a list of success criteria and a decision model
for designing a successful technology transfer approach in the global
age. Possible Obstacles:
o Business Success [...]”
92
FN31 - Lacuna no Processo de Inovação Conjunta
Quando uma inovação é compartilhada por mais de uma empresa, são
realizados esforços conjuntos para que esta tecnologia possa alcançar a adoção,
mas a existência de lacunas neste relacionamento pode tornar toda a atividade
negativa.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP59.

EP59 - “[...] we present a list of success criteria and a decision model
for designing a successful technology transfer approach in the global
age. Possible Obstacles: [...]
o Gap in joint innovation process [...]”
FN32 - Falta de confiança
Para que uma tecnologia seja aceita para adoção, não basta que esta seja
somente adequada e eficaz, mas é preciso que haja confiança por parte da
gerência, equipe técnica e usuários. A falta desta confiança pode colaborar para
que a tecnologia seja rejeitada.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP59.

EP59 - “[...] we present a list of success criteria and a decision model
for designing a successful technology transfer approach in the global
age. Possible Obstacles: [...]
o Missing trust [...]“
FN33 - Pessoas inadequadas
Escalar
uma
equipe
composta
por
pessoas
despreparadas
e
inadequadas, que não tenham intenção de colaborar para que a tecnologia
possa ser avaliada com seriedade e com critério, não promove a adoção.
93
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP59.

EP59 - “[...] we present a list of success criteria and a decision model
for designing a successful technology transfer approach in the global
age. Possible Obstacles: [...]
o Inadequate personnel on either side [...]”
FN34 - Retorno do Investimento
O retorno do investimento que será realizado para que a tecnologia possa
vir a ser plenamente adotada no ambiente corporativo é difícil de medir e pode
inibir a transferência tecnológica.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP30.

EP30 - “Technology change management is a challenging task [3]-[8].
Key lessons we have learned include:
o The return-on-investment from technology transfer is difficult to
measure. Suppose a new technology is a factor in winning a
proposal. How do you quantify the percentage of the total value?
Can you be sure that the technology use is a result of the
transfer program? [...]” As referências citadas no trecho
anteriormente transcrito dizem respeito à Stokes (1991),
Schaffer e Thomson (1992), respectivamente.
4.3.3 Abordagens
Q1 – Quais as abordagens existentes para transferência de tecnologia entre
academia e indústria em engenharia de software?
O objetivo da questão de pesquisa é identificar as abordagens existentes
que auxiliam a transferência de tecnologia entre academia e indústria no campo
da engenharia de software. O surgimento das categorias se deu de forma
automática, ou seja, a palavra identificada e que deu sentido à argumentação
nomeou a categoria. Cada estudo está relacionado a apenas uma categoria.
94
A1 - Modelo
O modelo é uma forma simplificada, parte menor de uma realidade com o
propósito de tornar o entendimento menos complexo (GRIFFITHS, 2010). Nesta
categoria foram identificados 7 dos estudos coletados. O estudo EP31 apresenta
um modelo de acordo com o aprendizado de outras disciplinas. O EP58 enfatiza
em seu modelo a cooperação entre profissionais e pesquisadores. O EP53
propõe um modelo com propósito de acelerar a transferência tecnológica. Os
estudos EP72 e EP78 apresentam modelos para avaliação. O EP85 apresenta
um modelo com intuito de examinar fatores que afetam a adoção tecnológica. Já
o EP18 apresenta um modelo que permite o ajuste, treinamento e consulta em
transferência de tecnologia.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP18, EP31, EP53, EP58, EP72, EP78 e EP85.

EP18 - “While developing a formal soharereview process, a working
group at Motorola devised a technology transfer model that is built on
process packages, each one targeted to a different user group. Their
model allows for tailoring, makes training and consuhing widely
available, and relies on champions.”

EP31 - “By learning from other disciplines, we present a model of
technology transfer that can be tailored to a particular organisation's
needs.”

EP53 - “This article proposes a co-evolutionary service-oriented model,
an organizational architecture for accelerating technology transfer
between co-evolving organizations.”

EP58 - “Successful technology transfer requires close cooperation and
collaboration between researchers and practitioners. A seven-step
transfer model embodying this philosophy emerged from two
academic-industry partnerships.”
95

EP72 - “This paper presents model for evaluating the rigor and
industrial relevance of technology evaluations in software engineering.”

EP78 - “The proposed model provides a useful decision support tool
for assessing and proactively designing interventions targeted at
successful OSS adoption and diffusion.”

EP85 - “This study develops an integrated research model to examine
various factors affecting the IT adoption in the context of the Unified
Modeling Language (UML).”
A2 - Framework
De acordo com Johnson (1996), framework é um projeto de sistema
reutilizável em todo ou parte. O estudo EP14 trata de um framework com o
propósito de identificar o conhecimento relevante existente que sirva como base
para uma transição segura e efetiva. O EP36, por sua vez, trata de um framework
cujo uso é direcionado a apresentação e interpretação de casos. Já o EP51
delineia sobre um framework que habilita as organizações na seleção e adoção
de forma efetiva. O EP55 aborda um framework que possibilita a análise de
processos de mudança e eventos de transferência de tecnologia. Por fim, o EP70
aborda um conceitual framework para aceitação de metodologias ágeis
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP14, EP36, EP51, EP55 e EP70.

EP14 - “The proposed framework calls for a thorough search of the
research literature, technical reports, conference proceedings,
commercial literature, and interviews with developers, consultants,
managers and researchers to identify knowledge regarding "theory;
practice; standards; and management" that are relevant to the safe
transition to, and effective management of, emerging software
Technologies [...]”

EP36 - “A framework integrating theories of general innovation with
theories on adoption of information technologies is used to present and
96
interpret the cases. The framework consists of three perspectives: an
individualist, a structuralist, and an interaction process perspective.”

EP51 - “The purpose of this study is to propose a framework for
organizations to effectively select and adopt systems development
methodologies so that they can decide on the most suitable tools and
methods for their specific environment.”

EP55 - “We propose that these concepts, as well as a combination
thereof, can serve as a framework within which change processes in
general, and technology transfer events in particular, can be analyzed.”

EP70 - “We provide a critical review of the extant literature on the
acceptance of traditional SDMs and agile methodologies, and develop
a conceptual framework for agile methodologies acceptance based on
a knowledge management perspective.”
A3 - Processo
Segundo Behl (2009), no que diz respeito ao CMM, o processo é
entendido como uma coleção estruturada de práticas eficazes baseadas em
experiência. O processo é identificado em 2 dos estudos coletados. O EP34
apresenta um processo para a introdução de novas ferramentas, tecnologias e
processos no ambiente organizacional. O EP30, por sua vez, implementa um
processo proativo para a transferência de tecnologia.
Abaixo são apresentadas as evidências coletadas a partir dos estudos
primários EP30 e EP34.

EP30 - “This paper discusses the approach used by TRW for
technology transfer, both internally and externally. The approach is
based on the definition of Technology Change Management activities,
as specified in the Software Engineering Institute’s Capability Maturity
Model (CMM) [...] TRW has implementing a proactive process for
technology transfer, based on the guidance of the CMM.”
97

EP34 - “This paper introduces this simple and practical process along
with important methods and concepts such as the Process Plug-in
Method and the Process Warehouse, for the introduction of new tools,
technologies, and processes within an organization.”
A4 - Esquema
O esquema é responsável por combinar experiências de pesquisas
acadêmicas com as existentes na indústria para fornecer conhecimentos
técnicos e qualificação para a gestão do conhecimento em engenharia de
software (CORBIN et al., 2007). O EP63 apresenta um esquema de gestão de
conhecimento em três níveis por meio de um planejamento sistemático de ações
abrangendo a transição tecnológica.
Abaixo são apresentadas as evidências coletadas a partir do estudo
primário EP63.

EP63 - “We present a three-tier knowledge management scheme
through a systematic planning of actions spanning the transition
processes in levels from conceptual exploration to prototype
development, experimentation, and product evaluation.”
4.4 Discussão sobre os Resultados
Um bom número de trabalhos foi selecionado, respondendo assim as
perguntas de pesquisa propostas no estudo de mapeamento. Visto a
complexidade, quando tratamos da transferência de tecnologia, não foi surpresa
o grande número de estudos retornados e selecionados.
A primeira pergunta de pesquisa buscou encontrar os fatores que
influenciam de forma positiva a transferência de tecnologia entre a academia e
a indústria no campo da Engenharia de Software. Em resposta a esta pergunta,
dentre os 87 estudos primários, foram encontradas 41 categorias, como pode
ser visto no Gráfico 4.6. Este alto número de categorias pode ser explicado
como resposta a dificuldade de se realizar a transferência da tecnologia e por
haverem obstáculos ainda não identificados ou ultrapassados quando da
98
condução do processo. Alguns destes fatores podem ser específicos a um
ambiente, o que pode justificar a diversidade de influenciadores.
Por meio dos oito primeiros tópicos, observou-se que a maioria das
pesquisas está voltada ao entendimento da influência dos experimentos
controlados, o apoio da alta gerência, formação e aprendizagem, percepção do
benefício, cooperação e colaboração, material de apoio, custo e agente. Estes
tópicos abrangem 46% dos estudos primários. Entre estes tópicos, percebe-se
que os estudos empíricos têm recebido grande atenção dos pesquisadores, vêse que cerca de nove estudos trabalham de alguma forma a experimentação,
este número equivale a 11% do total.
Por outro lado, grande é o número de categorias cujo a quantidade de
estudos é mínima, cerca de 54%, que equivale a 33 categorias, o que demonstra
a necessidade de uma maior investigação, de se conduzir mais pesquisas. O
resumo com as categorias e a quantidade de trabalhos pode ser visto na Tabela
4.1.
A segunda pergunta da pesquisa buscou encontrar os fatores que
influenciam de forma negativa a transferência de tecnologia entre a academia e
a indústria no campo da Engenharia de Software. Em resposta a esta pergunta,
dentre os 87 estudos primários, foram encontradas 34 categorias, sete a menos
se comparado com o que foi encontrado como fator positivo. Este dado pode ser
visto no Gráfico 4.7. Neste tipo de influenciador, o custo é o mais investigado,
seguido pela falta de compatibilidade, falta de conhecimento, resistência ao uso,
maturidade, falta de ferramenta, evidência e experiência. Estes correspondem a
43% dos estudos realizados. Uma grande quantidade de tópicos, cerca de 32
que equivale a 58% do total, foi identificado por conter apenas uma evidência. O
que demonstra a necessidade da realização de mais estudos, uma maior
investigação. Estes dados podem ser encontrados na Tabela 4.2.
Dentre todos os tópicos, formação e aprendizagem, percepção do
benefício, material de apoio, custo, resposta ou retorno, cultura, relacionamento,
ambiente, público e comunicação possuem evidências para fatores positivos e
negativos. No que se refere aos fatores positivos, estes oito tópicos representam
99
30% do total, já em relação aos fatores negativos, estes tópicos representam
36% do total.
A terceira pergunta da pesquisa buscou encontrar as abordagens
existentes no contexto da transferência de tecnologia entre academia e indústria
em engenharia de software. De acordo com as evidências obtidas, dividiu-se os
resultados em quatro categorias: modelo, framework, processo e esquema. O
dois tipos de abordagens com maior ocorrência foram modelo e framework, que
juntos abrangem 80% dos estudos encontrados. Processos e esquemas foram
tipos de abordagens com menor número de ocorrência, o que pode abrir espaço
à novas investigações e concepções. É de se destacar que em nenhum dos
estudos foi encontrada a reutilização de alguma abordagem dentre aquelas
encontradas. Algumas hipóteses podem ser delineadas (não é função deste
trabalho confirmar estas hipóteses):

As abordagens podem estar visando um ambiente específico ou a
resolução de um problema vivenciado apenas em um nicho
mercadológico;

Não há um consenso em relação às características essenciais que
guiam a transferência de tecnologia em Engenharia de Software e, por
este motivo, a generalização se torna uma atividade complexa;

A falta de um padrão pode estar resultando em uma diversidade de
abordagens, mesmo estas trabalhando de forma semelhante.
Após a análise dos resultados apresentados por este mapeamento, podese afirmar que há uma falta de padronização da atividade de transferência de
tecnologia entre academia e indústria no contexto da engenharia de software.
Além disso, o que existem são abordagens para situações específicas ou
àquelas que não se adequam a mais de uma situação por não se observar algum
fator específico. A diversidade de fatores tecnológicos, organizacionais, sociais
e culturais torna a transição um trabalho ainda mais laborioso e repleto de
inconsistências.
100
4.5 Resumo
Neste Capítulo foram apresentados os resultados do estudo de
mapeamento sistemático. A busca automatizada e manual retornou o total de
6228 estudos, sendo a ACM e o ScienceDirect os que mais contribuíram para o
trabalho, responsáveis por 73% dos estudos encontrados.
Além disso, foram identificados 41 tópicos relacionados a fatores
positivos, 34 tópicos no que se refere a fatores negativos e 4 tópicos sobre
abordagens através de 143 evidências, no contexto da transferência tecnológica
entre academia e indústria em engenharia de software.
101
5. CONSIDERAÇÕES FINAIS
Neste capítulo são apresentadas as considerações finais deste estudo.
Discute-se as ameaças a validade do estudo, trabalhos futuros e conclusões
obtidas por meio do trabalho.
5.1 Ameaças a Validade
Mesmo o mapeamento sistemático sendo conduzido de forma rigorosa,
algumas limitações ficaram evidentes. A primeira diz respeito a estratégia
utilizada para realizar a busca, pois mesmo havendo preocupação em encontrar
todos os estudos disponíveis que são relevantes, a utilização de engenhos de
busca automatizados abriu possibilidade de que estudos importantes possam
não ter sido incluidos na relação de estudos selecionados ou, por motivo de
indexação, o estudo ainda não esteja disponível para busca. Além disso, a
seleção das palavras-chave representa outro gargalo ao mapeamento
sistemático por abrir espaço a não identificação de algum termo que detecte
estudos com relevância a pesquisa. Neste trabalho, a busca automatizada foi
realizada nos engenhos IEEExplore Digital Library, ACM Digital Library e
Elsevier ScienceDirect. Também realizou-se busca manual nos seguintes
periódicos: The Journal of Technology Transfer (de 1977 a 2013) e The
International Journal on Software Tools for Technology Transfer (de 1997 a
2013).
Outra limitação diz respeito ao fato de somente um pesquisador ter
realizado a extração dos dados. Kitchenham e Charters (2007) previu esta
limitação e definiu que é aceitável para alunos de PhD, sem mencionar alunos
de mestrado. Porém o trabalho foi revisado pelo orientador e este participou da
revisão do protocolo de mapeamento, o que também é aceito pela autora. Outros
pesquisadores, listados no Apêndice C, participaram ativamente da etapa de
seleção dos estudos primários.
102
5.2 Trabalhos Futuros
A seguir são propostas, com base no que foi identificado neste trabalho,
algumas sugestões para realização de novos estudos.
 Ampliar a busca manual a outros periódicos e conferências, assim
como encontrar novos engenhos de busca que tenham relevância com
o propósito de estender o protocolo;
 Realizar uma busca nas referências dos estudos encontrados com o
propósito de encontrar novos estudos;
 Avaliar a aplicabilidade das abordagens selecionadas em resposta a
QP3, identificando abertura a melhorias e proporcionando a produção
de uma nova abordagem que acelere o processo de transferência de
tecnologia em engenharia de software;
 Verificar de forma mais detalhada a relação entre o experimento
controlado e a transferência de tecnologia em engenharia de software;

Promover novos estudos em categorias que poucas evidências foram
encontradas com o intuito de uma melhor investigação

Promover novos estudos sobre processos e esquemas em
transferência de tecnologia entre academia e indústria em engenharia
de software.
5.3 Conclusões
Este estudo de mapeamento sistemático registrou todos os passos
necessários para a sua realização de forma a possibilitar replicação. Também
apresentou duas contribuições importantes. Primeiro realizou a estruturação e
síntese de forma sistemática de todo estudo científico que teve relevância a
transferência de tecnologia entre academia e indústria em engenharia de
103
software. Segundo, apresentou lacunas que proporcionam espaço para a
realização de outros estudos complementares com o intuito de explorar a área
com maior amplitude.
Neste estudo, três perguntas de pesquisa foram utilizadas, 6228 estudos
foram encontrados advindo da busca manual e automatizada, sendo 3251
somente na ACM, resultando 87 estudos primários selecionados. Além disso, a
pesquisa contabilizou 206 autores originários de 20 países diferentes.
Percebe-se que a condução de experimentos controlados ganhou grande
atenção dos pesquisadores e que nesta pesquisa foi responsável por 11% do
total de fatores positivos encontrados.
A busca manual obteve representatividade de 25% do total de estudos
encontrados, mas somente 6 estudos foram selecionados como primários, o que
representa 7% do total. Este resultado nos mostra que a busca manual nos
periódicos selecionados teve pouca relevância para a pesquisa.
Com relação às lacunas identificadas, podemos citar:

Necessidade de maior investigação nos tópicos que encontraram poucas
evidências;

Pode haver falta de estudos robustos sobre a transferência de tecnologia
entre a academia e a indústria brasileira em engenharia de software. O
estudo atual não encontrou nenhum estudo com origem no Brasil;

As abordagens que respondem a QP3 não foram reutilizadas em nenhum
dos estudos primários da pesquisa, deste modo há a necessidade de se
investigar as causas da aparente não disseminação das abordagens;

De modo a proporcionar abertura a melhoria e produção de nova
abordagem que produza um melhor desempenho no processo de
transferência de tecnologia em engenharia de software, há de se destinar
um maior esforço na investigação;
104

As pessoas estão presentes em muitos pontos no processo de
transferência de tecnologia. Desta forma, se faz necessário maior
investigação do papel do ser humano na transferência de tecnologia em
engenharia de software.
105
REFERÊNCIAS BIBLIOGRÁFICAS
ABRAMSON, N. H. et al. Technology Transfer Systems in the United
States and Germany. Lessons and Perspectives. Washington, DC:
National Academy Press, 1997.
ARKSEY, H.; O'MALLEY, L. Scoping studies: towards a methodological
framework. International Journal of Social Research Methodology, v. 8,
n. 1, p. 19–32, 2005.
BARREIROS, E. F. S. A Systematic Mapping Study on Software
Engineering Testbeds. Master Thesis, Federal University of Pernambuco,
86p, 2011.
BEHL, R. Information Technology for Management. Tata McGraw-Hill
Education Private Limited, 2009.
BERNIKER, E. Models of Technology transfer: a dialectical case study.
Proceedings of the IEEE Conference: The New International Language,
July, p. 499-502, 1991.
BIOLCHINI, J. et al. Systematic review in software engineering: relevance
and utility, Technical Report, PESC - COPPE/UFRJ, 2005.
BOZEMAN, B. Technology Transfer and Public Policy: A Review of
Research and Theory. Research Policy, v. 29, p. 627-655, 2000.
BUDGEN, D. et al. Investigating the applicability of the evidence-based
paradigm to software engineering. In Proceedings of WISER Workshop,
ICSE’06, p. 7-13, 2006.
BUDGEN, D. et al. Using Mapping Studies in Software Engineering.
Proceedings of PPIG’08, Lancaster University, p. 195-204, 2008.
106
BURATTI, N.; PENCO, L. Assisted Technology Transfer to SMEs:
Lessons from an Exemplary Case. Technovation, v. 21, n. 1, p. 35-43,
2001.
BUXTON, J.N.; MALCOLM, R. Software Technology Transfer. Software
Engineering Journal, p. 17–23, 1991.
COOKE, I.; MAYES, P. Introduction to Innovation and Technology
Transfer. London and Boston: Artech House, 256p, 1996.
COOPER, H. Organizing knowledge syntheses: A taxonomy of literature
reviews. Knowledge, Technology & Policy, v. 1, n. 1, p. 104–126, 1988.
CORBIN, R. D.; CHRISTOPHER, B. D.; ZHU, Q. A three-tier knowledge
management scheme for software engineering support and innovation.
The Journal of Systems and Software, v. 80, n. 9, p. 1494-1505, 2007.
CUNNINGHAM, R. et al. Formal Requirements Specification – The
FOREST
project:
Proc
3rd.
International
Workshop
Software
Specification and Design, IEEE Comp Soc Press, p. 186-192, 1985.
DYBA, T.; KITCHENHAM, B. A.; JORGENSEN, M. Evidence-based
software engineering for practitioners. IEEE Software, v. 22, p. 58–65,
2005.
DYBA, T.; DINGSOYR, T.; HANSSEN, G. K. Applying Systematic
Reviews to Diverse Study Types: An Experience Report. In ESEM 2007
First International Symposium on Empirical Software Engineering and
Measurement, p. 225-234, 2007.
FOWLER, P.; LEVINE, L. From Theory to Practice: Technology transition
at the SEI. In Proceedings of the Hawaii International Conference on
System Sciences, Maui, Hawaii. IEEE Computer Society Press, 1994.
107
GOODE, S. Something for nothing: Management rejection of open source
software in Australian’s top firms. Information Manager, v. 42, n. 5, p. 669681, 2005.
GRIFFITHS, E. C. What is a model? NC State University. Disponível em:
https://sites.google.com/a/ncsu.edu/emily-griffiths/whatisamodel.pdf>.
Acesso em: 04 Abril. 2014.
GWEBU, K. L.; WANG, J. Seeing eye to eye? An exploratory study of free
open source software users perceptions. The Journal of Systems and
Software, v. 83, n. 11, p. 2287-2296, 2010.
HAMERI, A.P. Technology-transfer between basic research and industry.
Technovation, v. 16, n. 2, p. 51-57, 1996.
HUFF, C. C. Elements of a Realistic CASE Tool Adoption Budget.
Communication of the ACM, v. 35, n. 4, 1992.
JOHNSON, R. How to Develop Frameworks. Tutorial Notes of ECOOP
96. Linz, Austria, 1996.
KITCHENHAM, B. A.; DYBA, T.; JORGENSEN, M. Evidence-based
Software Engineering. Proceedings of the 26th International Conference
on Software Engineering, p. 273-281, 2004.
KITCHENHAM, B. A. Procedures for Performing Systematic Reviews.
Keele University and National ICT Australia Ltd, Tech. Report TR/SE0401 and NICTA TR 0400011T.1, 2004.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for Performing
Systematic Literature Reviews in Software Engineering, Version 2.3,
108
Technical Report. Software Engineering Group, Keele University and
Department of Computer Science University of Durham, 2007.
KITCHENHAM, B.; BUDGEN, D.; BRERETON, O.P. Using mapping
studies as the basis for further research - a participant-observer case
study. Information and Software Technology, v. 53, n. 6, p. 638–651,
2011.
LAKATOS, E. M.; MARCONI, M. A. Metodologia Científica. Atlas, 2007.
LARSSON, M. et al. Technology transfer: why some succeed and some
don’t. In: Proceedings of the International Workshop on Software
Technology Transfer in Software Engineering (WOTTSE) at ICSE06,
ACM, Shanghai, p. 23–27, 2006.
LEVIN, M. Technology Transfer as a Learning and Developmental
Process: an analysis of Norwegian programmes on technology transfer,
v. 13, n. 8, p. 497-518, 1993.
LINKMAN, S.; ROMBACH, H. D. Experimentation as a vehicle for
software technology transfer - A family of software reading techniques.
Information and Software Technology, v. 39, n. 11, p. 777-780, 1997.
MARTENS, J.; DUVALL, L. The role of an information analysis center in
software engineering technology transfer. AFIPS National Computer
Conference, v. 49, p. 677-682, 1980.
MENON, T.; PFEFFER, J. Valuing internal versus external knowledge.
Management Science, v. 49, n. 4, p. 497-513, 2003.
MORRISSEY, M. T.; ALMONACID, S. Rethinking Technology Transfer.
Journal of Food Engineering, v. 67, p. 135-145, 2005.
PETERSEN, K. et al. Systematic Mapping Studies in Software
Engineering.
12th
International
Conference
on
Evaluation
and
109
Assessment in Software Engineering (EASE), Department of Informatics,
2008.
PFLEEGER, S.L. Understanding and Improving Technology Transfer in
Software Engineering. Journal of Systems and Software, v. 47, p. 111124, 1999.
PFLEEGER, S. L.; MENEZES W. Marketing Technology to Software
Practitioners. IEEE Software, v. 17, n. 1, p. 27-33, 2000.
PUNTER, H. T.; KRIKHAAR, R. L.; BRIL, R. J. Software Engineering
Technology Innovation: Turning research results into industrial success.
Journal of Systems and Software, v. 82, n. 6, p. 993-1003, 2009.
RAGHAVAN, S. A.; CHAND, D. R. Diffusing Software-Engineering
Methods. IEEE Software, v. 6, n. 4, p. 81-90, 1989.
REAGANS, R.; MCEVILY, B. Network structure and knowledge transfer:
the transfer problem revisited. Working Paper, Columbia University, New
York, 2003.
REDWINE, S. T.; RIDDLE, W. E. Software Technology Maturation. In
ICSE ’85: Proceedings of the 8th international conference on Software
engineering, IEEE Computer Society Press, Los Alamitos, CA, USA, p.
189-200, 1985.
ROGERS, E. M. Diffusion of Innovations. Fourth Edition. New York: Free
Press, 1995.
ROGERS, E. M., TAKEGAMI, S.; YIN, J. Lessons learned about
technology transfer. Technovation, v. 21, n. 4, p. 253-261, 2001.
ROGERS, E. M. Diffusion of Innovations. Fifth edition. New York: Free
Press, 551p, 2003.
110
ROMBACH, H. D. Fraunhofer: The German Model for Applied Research
and Technology Transfer. In Proceedings of International Conference on
Software Engineering (ICSE'00), p. 531-537, 2000.
SACKETT, D. L. et al. Evidence-Based Medicine: How to Practice and
Teach EBM. 2ed, 280p, 2000.
SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Operating System
Concepts with Java. 8. Ed. John Wiley & Sons, Inc, 1040p, 2010.
SCHAFFER, R. H.; THOMSON, H. A. Successful Change Programs
Begin with Results. Havard Business Review, January/February, p. 8089, 1992.
STOKES, S. L.; Managing Technology-Driven Change. QED Information
Science, Inc, 189p, 1991.
TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. A. G. Introdução a
Engenharia de Software Experimental. Relatório Técnico ES-590/02,
COPPE/UFRJ, 2002.
THOMPSON, L.; GENTNER, D.; LOWENSTEIN, J. Evoiding missed
opportunities in managerial life: analogical training more powerful than
individual case training. Organizational Behavior and Human Decision
Process, v. 82, p. 60-75, 2000.
ZELKOWITZ, M. V. Assessing Software Engineering Technology transfer
within NASA. NASA Technical report NASA-RPT-003095. National
Aeronautics and Space Administration, Washington, DC, 1995.
ZELKOWITZ, M. V. Software Engineering Technology Infusion within
NASA. IEEE Trans. On Engineering Management, v. 43, n. 3, p. 250-261,
1996.
111
ZELKOWITZ, M. V.; WALLACE, D.; BINKLEY, D. Culture Conflicts in
Software Engineering Technology Transfer. In NASA Goddard Software
Engineering Workshop, 1998.
112
APÊNDICE A – Estudos Primários
ID
EP1
Ano
1979
EP2
1979
EP3
1980
EP4
1980
EP5
1985
EP6
1987
EP7
1988
EP8
1988
EP9
1989
EP10 1990
EP11 1990
Fonte
TT
Referência
KRAEMER, K. L.; KING, J. L. New findings on the
transfer of computing applications among cities.
The Journal of Technology Transfer, v. 4, n. 1, p.
99-110, 1979.
TT
COLTON, K. W.; TIEN, J. M. Technology transfer
of computer-based applications in law
enforcement. The Journal of Technology Transfer,
v. 4, n. 1, p. 63-76, 1979.
ACM
MCGILL, M. J. Considerations in the transfer of
software engineering technology. AFIPS ’80,
National Computer Conference, p. 683-686, 1980.
ACM
MARTENS, J.; DUVALL, L. The role of an
information analysis center in software engineering
technology transfer. AFIPS ’80, National Computer
Conference, p. 677-682, 1980.
TT
HUFFMAN, G. D. Software support systems for
use in technology transfer activities. The Journal of
Technology Transfer, v. 9, n. 2, p. 29-39, 1985.
SCIENCE ALEXANDER, H.; POTTER, B. Case study: the
DIRECT
use of formal specification and rapid prototyping to
establish product feasibility. Information and
Software Technology, v. 29, n. 7, p. 388-394, 1987.
IEEE
SNODGRASS, J. G. Software requirements
specification from a cognitive psychology
perspective. Proceedings of International
Conference on Computer Languages, p. 422-430,
1988.
IEEE
BAYER, J. A critique of diffusion theory as a
managerial framework for understanding adoption
of software engineering innovations. Proceedings
of the Twenty-First Annual Hawaii International
Conference on System Sciences, v. 2, p. 311-316,
1988.
TT
DRISCOLL, F. D.; WOLF, W. C. An analysis of
strategies used to disseminate the PLATO system.
The Journal of Technology Transfer, v. 14, n. 3-4,
p. 54-59, 1989.
IEEE
KRIST, J. T. Applications of CASE for
requirements and design in communications
systems. IEEE International Conference on
Communications, v. 2, p. 325-330, 1990.
IEEE
FINKELSTEIN, A.; MAIBAUM, T.; FINKELSTEIN,
L. Engineering-in-the-large: software engineering
113
EP12 1990
EP13 1991
EP14 1992
EP15 1993
EP16 1993
EP17 1993
EP18 1994
EP19 1995
EP20 1995
EP21 1996
EP22 1996
and instrumentation. UK IT Conference, p. 1-7,
1990.
IEEE
ZUCCONI, L.; MACK, G.; WILLIAMS, L. G. Using
object-oriented development to support
prototyping. Proceedings of 12th International
Conference on Software Engineering, p. 129-132,
1990.
ACM
ANDERSON, J. A.; WARD, E. S. Technology
transfer: experiences in introducing object-oriented
methods to government projects. Proceedings of
WADAS‘91, p. 10-15, 1991.
ACM
KORSON, T. D.; VAISHNAVI, V. K. Managing
emerging software technologies: a technology
transfer framework. Communications of the ACM,
v. 35, n. 9, p. 101-111, 1992.
IEEE
LINGER, R. C.; HEVNER, A. R. Achieving software
quality through Cleanroom software engineering.
Proceeding of the Twenty-Sixth Hawaii
International Conference on System Sciences, v. 4,
p. 740-748, 1993.
IEEE
DEWAL, S. CASE development: Improving
software development by transfer of technology.
Proceedings of Software Engineering
Environments Conference, p. 199-208, 1993.
IEEE
ZEMLIN, B. Establishing a software engineering
process group in a medical device company.
Proceedings of Sixth Annual IEEE Symposium on
Computer-Based Medical Systems, p. 272-277,
1993.
IEEE
BASILI, V.; DASKALANTONAKIS, M. K.;
YACOBELLIS, R. H. Technology Transfer at
Motorola. IEEE Software, v. 11, n. 2, p. 70-76,
1994.
ACM
PREMKUMAR, G.; POTTER, M. Adoption of
computer aided software engineering (CASE)
technology: an innovation adoption perspective.
ACM SIGMIS Database, v. 26, n. 2-3, p. 105-124,
1995.
IEEE
KRASNER, H. Bottlenecks in the transfer of
software engineering technology: lessons learned
from a consortium failure. Proceedings of the
Twenty-Eighth Hawaii International Conference on
System Sciences, v. 4, p. 635-641, 1995.
SCIENCE SAIEDIAN, H., HINCHEY, M. G. Challenges in the
DIRECT
successful transfer of formal methods technology
into industrial applications. Journal of Information
and Software Technology, v. 38, n. 5, p. 313-322,
1996.
SCIENCE RODGER, J. A.; PENDHARKAR, P. C.; BHATT, G.
DIRECT
D. Diffusion theory and the adoption of software
114
EP23 1997
IEEE
EP24 1997
SCIENCE
DIRECT
EP25 1997
SCIENCE
DIRECT
EP26 1997
TT
EP27 1998
IEEE
EP28 1998
IEEE
EP29 1998
SCIENCE
DIRECT
EP30 1999
IEEE
EP31 1999
SCIENCE
DIRECT
EP32 2000
ACM
EP33 2000
ACM
EP34 2000
ACM
innovation: Common errors and future issues. The
Journal of High Technology Management
Research, v. 7, n. 1, p. 1-13, 1996.
FICHMAN, R. G.; CARROL, W. E.; KEMERER, C.
F. Object Technology and Reuse: Lessons from
Early Adopters. IEEE Computer, v. 30, n. 10, p. 4759, 1997.
HARDGRAVE, B. C. Adopting object-oriented
technology: Evolution or revolution?. Journal of
Systems and Software, v. 37, n. 1, p. 19-25, 1997.
FOWLER, P. An expert system in the domain of
software technology transfer. Expert Systems with
Applications, v. 12, n. 3, p. 275-300, 1997.
WIGAND, R. T. et al. Electronic commerce and
user-based design of a web site: Targeting the
technology transfer audience. The Journal of
Technology Transfer, v. 22, n. 1, p. 19-28, 1997.
LAM, W.; JONES, S.; BRITTON, C. Technology
Transfer for Reuse: A Management Model and
Process Improvement Framework. Proceedings of
Third International Conference on Requirements
Engineering, p. 233-240, 1998.
FOWLER, P. et al. Transition packages: an
experiment in expediting the introduction of
requirements management. Proceedings of Third
International Conference on Requirements
Engineering, p. 138-145, 1998.
JAGADEESAN, L. J.; VOTTA, L. G. Specificationbased testing of reactive software: A case study in
technology transfer. Journal of Systems and
Software, v. 40, n. 3, p. 249-262, 1998.
HEFNER, R. A Corporate Approach to Technology
Transition. Proceedings of the 32nd Annual Hawaii
International Conference on Systems Sciences, v.
7, 1999.
PFLEEGER, S. L. Understanding and improving
technology transfer in software engineering.
Journal of Systems and Software, v. 47, n. 2-3, p.
111-124, 1999.
ROMBACH, D. Fraunhofer: the German model for
applied research and technology transfer.
Proceedings of the International Conference on
Software Engineering, p. 531-537, 2000.
CURTIS, B. From MCC to CMM: technology
transfers bright and dim. Proceedings of the
ICSE’00, p. 521-530, 2000.
NISHIYAMA, T.; IKEDA, K.; NIWA, T. Technology
transfer macro-process. A practical guide for the
effective introduction of technology. Proceedings of
ICSE’00, p. 577-586, 2000.
115
EP35 2000
EP36 2000
EP37 2000
EP38 2000
EP39 2000
EP40 2000
EP41 2002
EP42 2003
EP43 2003
EP44 2004
EP45 2004
EP46 2005
IEEE
COLYER, A. M. From research to reward:
challenges in technology transfer. Proceedings of
ICSE’00, p. 569-576, 2000.
IEEE
KAUTZ, K.; NIELSEN, P. A. Implementing software
process improvement: two cases of technology
transfer. Proceedings of the 33rd Annual Hawaii
International Conference on System Sciences,
2000.
IEEE
SCHMID, K. et al. Introducing a software modeling
concept in a medium-sized company. Proceedings
of ICSE’00, p. 558-567, 2000.
IEEE
PFLEEGER, S. L.; MENEZES, W. Marketing
Technology to Software Practitioners. IEEE
Software, 17(1), p. 27-33, 2000.
IEEE
ABERNETHY, K. et al. Technology Transfer Issues
for Formal Methods of Software Specification.
Proceedings of 13th Conference on Software
Engineering Education, p. 23-31, 2000.
IEEE
GREEN, G. C.; HEVNER, A. R. The successful
diffusion of innovations: guidance for software
development organizations. IEEE Software, v. 17,
n. 6, p. 96-103, 2000.
IEEE
RIEMENSCHNEIDER, C. K.; HARDGRAVE, B. C.;
DAVIS, F. D. Explaining Software Developer
Acceptance of Methodologies: A Comparison of
Five Theoretical Models. IEEE Transactions on
Software Engineering, v. 28, n. 12, p. 1135-1145,
2002.
ACM
ZELKOWITZ, M. V.; WALLACE, D. R.; BINKLEY,
D. W. Experimental validation of new software
technology. Lecture notes on empirical software
engineering, p. 229-263, 2003.
SCIENCE GALLIVAN, M. J. The influence of software
DIRECT
developers’ creative style on their attitudes to and
assimilation of a software process innovation.
Information and Management, v. 40, n. 5, p. 443465, 2003.
IEEE
RAMAKRISHMANN, S.; CAMBRELL, A. Muse
over university organisational ecology in action and
service-oriented architectures. Proceedings of
Ninth IEEE International Conference on
Engineering Complex Computer Systems, p. 199206, 2004.
IEEE
KEUNG, J.; JEFFERY, R.; KITCHENHAM, B. The
Challenge of Introducing a New Software Cost
Estimation Technology into a Small Software
Organisation. Proceedings of Australian Software
Engineering Conference, p. 52-59, 2004.
SCIENCE GREEN, G. C.; HEVNER, A. R.; COLLINS, R. W.
DIRECT
The impacts of quality and productivity perceptions
116
EP47 2006
ACM
EP48 2006
ACM
EP49 2006
ACM
EP50 2006
ACM
EP51 2006
ACM
EP52 2006
ACM
EP53 2006
ACM
EP54 2006
ACM
EP55 2006
ACM
EP56 2006
ACM
EP57 2006
IEEE
EP58 2006
IEEE
EP59 2007
ACM
EP60 2007
IEEE
on the use of software process improvement
innovations. Information and Software Technology,
v. 47, n. 8, p. 543-553, 2005.
BOCHERNITSAN, M.; DOONG, R.; SAVOIA, A.
From daikon to agitator: lessons and challenges in
building a commercial tool for developer testing.
Proceedings of ISSTA’06, p. 169-180, 2006.
MCGILL, K. et al. Houston, we have a success
story: technology transfer at the NASA IV&V
facility. Proceeding of TT’06, p. 49-54, 2006.
BHAWNANI, P. et al. Intelligent decision support
for road mapping a technology transfer case study
with seimens corporate technology. Proceeding of
TT’06, p 35-40, 2006.
TILLEY, S.; HUANG, S. On the "selling" of
academic research to industry. Proceeding of
TT’06, p. 41-42, 2006.
WOO, F. et al. A framework for the effective
adoption of software development methodologies.
Proceeding of ACM-SE44, p. 198-203, 2006.
DORENBOS, D. Aligning technology transfer using
basic business measures. Proceeding of TT’06, p.
19-22, 2006.
AOYAMA, M. Co-Evolutionary service-oriented
model of technology transfer in software
engineering. Proceeding of TT’06, p. 3-8, 2006.
LARSSON, M. et al. Technology transfer: why
some succeed and some don't. Proceeding of
TT’06, p. 23-28, 2006.
HAZZAN, O.; DUBINSKY, Y. The concept of
change in technology transfer. Proceeding of
TT’06, p. 29-34, 2006.
HINCHEY, M. G. et al. The NASA software
research infusion initiative: successful technology
transfer for software assurance. Proceeding of
TT’06, p. 43-48, 2006.
PRESSBURGER, T. et al. Infusing Software
Engineering Technology into Practice at NASA.
Second IEEE International Conference on Space
Mission Challenges for Information Technology, p.
9-100, 2006.
GORSCHEK, T. et al. A Model for Technology
Transfer in Practice. IEEE Software, v. 23, n. 6, p.
88-95, 2006.
ROMBACH, D.; ACHATZ, R. Research
Collaborations between Academia and Industry.
Proceeding of FOSE’07, p. 29-36, 2007.
MARKOSIAN, L. Z. et al. Program Model Checking
Using Design-for-Verification: NASA Flight
117
EP61 2007
IEEE
EP62 2007
IEEE
EP63 2007
SCIENCE
DIRECT
EP64 2007
STTT
EP65 2008
ACM
EP66 2008
ACM
EP67 2009
ACM
EP68 2009
SCIENCE
DIRECT
EP69 2009
SCIENCE
DIRECT
EP70 2009
SCIENCE
DIRECT
EP71 2009
SCIENCE
DIRECT
EP72 2010
ACM
Software Case Study. IEEE Aerospace
Conference, p. 1-9, 2007.
JEDLITSCHKKA, A. et al. Relevant Information
Sources for Successful Technology Transfer: A
Survey Using Inspections as an Example.
Proceeding of ESEM’07, p. 31-40, 2007.
HINCHEY, M. G. et al. Software Assurance
Research Infusion: The NASA Experience.
Proceeding of ISoLa’06, p. 18-27, 2007.
CORBIN, R. D.; DUNBAR, C. B.; ZHU, Q. A threetier knowledge management scheme for software
engineering support and innovation. Journal of
Systems and Software, v. 80, n. 9, pp. 1494-1505,
2007.
HUTH, M. Some current topics in model checking.
International Journal on Software Tools for
Technology Transfer, v. 9, n. 1, p. 25-36, 2007.
GUO, Y.; SEAMAN, C. B. A survey of software
project managers on software process change.
Proceeding of ESEM’08, p. 263-269, 2008.
LUCIA, A. et al. Developing legacy system
migration methods and tools for technology
transfer. Journal of Software Practice &
Experience, v. 38, n. 13, p. 1333-1364, 2008.
LAM, A.; BOEHM, B. Experiences in developing
and applying a software engineering technology
testbed. Journal of Empirical Software Engineering,
v. 14, n. 5, p. 479-601, 2009.
PUNTER, T.; KRIKHAAR, R. L.; BRIL, R. J.
Software engineering technology innovation –
Turning research results into industrial success.
Journal of Systems and Software, v. 82, n. 6, p.
993-1003, 2009.
MISRA, S. C.; KUMAR, V.; KUMAR, U. Identifying
some important success factors in adopting agile
software development practices. Journal of
Systems and Software, v. 82, n. 11, p. 1869-1890,
2009.
CHAN, F. K. Y.; THONG, J. Y. L. Acceptance of
agile methodologies: A critical review and
conceptual framework. Decision Support Systems,
v. 46, n. 4, p. 803-814, 2009.
COLOSIMO, M. et al. Evaluating legacy system
migration technologies through empirical studies.
Information and Software Technology, v. 51, n. 2,
p. 433-447, 2009.
IVARSSON, M.; GORSCHEK, T. A method for
evaluating rigor and industrial relevance of
technology evaluations. Journal of Empirical
118
EP73 2010
IEEE
EP74 2010
SCIENCE
DIRECT
EP75 2011
ACM
EP76 2011
IEEE
EP77 2011
SCIENCE
DIRECT
EP78 2011
SCIENCE
DIRECT
EP79 2011
SCIENCE
DIRECT
EP80 2012
ACM
EP81 2012
IEEE
EP82 2012
SCIENCE
DIRECT
EP83 2012
SCIENCE
DIRECT
EP84 2012
SCIENCE
DIRECT
Software Engineering, v. 16, n. 3, p. 365-395,
2010.
ASCHAUER, T.; DAUENHAUER, G.; PREE, W. A
modeling language's evolution driven by tight
interaction between academia and industry.
Proceeding of 32nd International Conference on
Software Engineering, v. 2, p. 49-58, 2010.
HAUGE, O.; AYALA, C.; CONRADI, R. Adoption of
open source software in software-intensive
organizations – A systematic literature review.
Information and Software Technology, v. 52, n. 11,
p. 1133-1154, 2010.
BISHOP, J. et al. Browser-based software for
technology transfer. Proceeding of SAICSIT’11, p.
338-340, 2011.
ZHANG, H. et al. Impact of process simulation on
software practice: an initial report. Proceeding of
ICSE’11, p. 1046-1056, 2011.
WU, W. Mining significant factors affecting the
adoption of SaaS using the rough set approach.
Journal of Systems and Software, v. 84, n. 3, p.
435-441, 2011.
GWEBU, K. L.; WANG, J. Adoption of Open
Source Software: The role of social identification.
Decision Support Systems, v. 51, n. 1, p. 220-229,
2011.
ZAFFAR, M. A.; KUMAR, R. L.; ZHAO, K. Diffusion
dynamics of open source software: An agentbased computational economics (ACE) approach.
Decision Support Systems, v. 51, n. 3, p. 597-608,
2011.
LINDVALL, M. et al. Connecting research and
practice: an experience report on research infusion
with software architecture visualization and
evaluation. Journal of Innovations in Systems and
Software Engineering, v. 8, n. 4, p. 255-277, 2012.
DIEGUEZ, M.; SEPULVEDA, S.; CACHERO, C.
UMAM-Q: An instrument to assess the intention to
use software development methodologies.
Proceeding of CISTI’12, p. 1-6, 2012.
MARSAN, J.; PARE, G.; BEAUDRY, A. Adoption of
open source software in organizations: A sociocognitive perspective. The Journal of Strategic
Information Systems, v. 21, n. 4, p. 257-273, 2012.
VIJAYASARATHY, L.; TURK, D. Drivers of agile
software development use: Dialectic interplay
between benefits and hindrances. Information and
Software Technology, v. 54, n. 2, p. 137-148, 2012.
SENAPATHI, M.; SRINIVASAN, A. Understanding
post-adoptive agile usage: An exploratory cross119
EP85 2012
EP86 2013
EP87 2013
case analysis. Journal of Systems and Software, v.
85, n. 6, p. 1255-1268, 2012.
SCIENCE GU, V. C.; CAO, Q.; DUAN, W. Unified Modeling
DIRECT
Language (UML) IT adoption — A holistic model of
organizational capabilities perspective. Decision
Support Systems, v. 54, n. 1, p. 257-269, 2012.
ACM
BALDASSARRE, M. T.; CAIVANO, D.; VISAGGIO,
G. Empirical studies for innovation dissemination:
ten years of experience. Proceeding of EASE’13,
p. 144-152, 2013.
SCIENCE EDISON, H.; ALI, N. B.; TORKAR, R. Towards
DIRECT
innovation measurement in the software industry.
Journal of Systems and Software, v. 86, n. 5, p.
1390-1407, 2013.
120
APÊNDICE B – Estudos Excluídos
ID
1
2
3
4
5
6
7
8
9
Ano Fonte
2010 ACM
Referência
JAGER, G. P.; HUISMAN, H. M.;
KRUGER, H. A. A quantitative model to
evaluate post-implementation efficiency of
Scrum. Proceeding of SoMeT’10, p. 163181, 2010.
2003 SCIENCE RIFKIN, S. Why New Software Processes
DIRECT
Are Not Adopted. Advances in Computers,
v. 59, p. 83-126, 2003.
1983 ACM
ZMUD, R. W. The effectiveness of
external information channels in facilitating
innovation within software development
groups. Journal MIS Quartely, v. 7, n. 2, p.
43-58, 1983.
1998 ACM
STELZER, D.; MELLIS, W.; HERZWURM,
G. Technology diffusion in software
development processes: the contribution
of organizational learning to software
process improvement. Information
Systems Innovation and Diffusion, p. 297344, 1998.
2006 ACM
SCHNEIDER, K. Technology transfer and
education introduction. Proceedings of the
International Conference on Empirical
Software Engineering Issues: Critical
Assessment and Future Directions, p. 121124, 2006.
1979 SCIENCE GOODMAN, S. E. Software in the Soviet
DIRECT
Union: Progress and Problems. Advances
in Computers, v. 18, p. 231-287, 1979.
2001 ACM
BECKER-KORNSTAEDT, U.; NEU, H.;
HIRCHE, G. Software Process
Technology Transfer: Using a Formal
Process Notation to Capture a Software
Process in Industry. Proceedings of
EWSPT’01, p. 63-76, 2001.
2009 ACM
CALISTI, M.; RIMASSA, G. Opportunities
to support the widespread adoption of
software agent Technologies. International
Journal of Agent-Oriented Software
Engineering, v. 3, n. 4, p. 411-415, 2009.
2002 ACM
SEROUR, M. K. et al. Organizational
Transition to Object Technology: Theory
and Practice. Proceedings of OOIS’02, p.
229-241, 2002.
Critério
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
121
10
11
12
13
14
15
16
17
18
19
2000 ACM
KING, G. A. Quality technique transfer:
Manufacturing and software. Journal
Annals of Software Engineering, v. 10, n.
1-4, p. 359-372, 2000.
2003 ACM
HARDGRAVE, B. C.; DAVIS, F. D.;
RIEMENSCHNEIDER, C. K. Investigating
Determinants of Software Developers'
Intentions to Follow Methodologies.
Journal of Management Information
Systems, v. 20, n. 1, p. 123-151, 2003.
2006 ACM
JEDLITSCHKA, A. How to improve the
use of controlled experiments as a means
for early technology transfer. Proceedings
of the International Conference on
Empirical Software Engineering Issues:
Critical Assessment and Future Directions,
p. 130-130, 2006.
2008 ACM
CAPALDO, G.; RIPPA, P.; TETA, V.
Effects of technological change on the
skills and competencies of software
development professionals: a case study
on the transition from ABAP to JAVA.
International Journal of Information
Technology and Management, v. 7, n. 4,
p. 440-451, 2008.
2006 ACM
WEYUKER, E. J. Empirical studies as a
basis for technology transfer. Proceedings
of the International Conference on
Empirical Software Engineering Issues:
Critical Assessment and Future Directions,
p. 125-127, 2006.
1996 ACM
RAI, A.; PATNAYAKUNI, R. A structural
model for CASE adoption behavior.
Journal of Management Information
Systems, v. 13, n. 2, p. 205-234, 1996.
1995 SCIENCE RADER, J. A. CASE Adoption: A Process,
DIRECT
Not an Event. Advances in Computers, v.
41, p. 83-156, 1995.
2002 ACM
CHO, I.; KIM, Y. Critical Factors for
Assimilation of Object-Oriented
Programming Languages. Journal of
Management Information Systems, v. 18,
n. 3, p. 125-156, 2002.
2006 ACM
BORJESSON, A.; MARTINSSON, F.;
TIMMERAS, M. Agile improvement
practices in software organizations.
European Journal of Information Systems,
v. 15, n. 2, p. 169-182, 2006.
2006 ACM
SHERIF, K.; ZMUD, R. W.; BROWNE, G.
J. Managing peer-to-peer conflicts in
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
Sem
Acesso
122
20
2004 ACM
21
2006 ACM
22
2006 ACM
23
2006 ACM
24
2007 ACM
25
2008 ACM
26
2011 ACM
27
1990 IEEE
28
1994 IEEE
29
1997 IEEE
30
2012 IEEE
disruptive information technology
innovations: the case of software reuse.
Journal MIS Quarterly, v. 30, n. 2, p. 339356, 2006.
WINSCHIERS, H.; PATERSON, B.
Sustainable software development.
Proceedings of SAICSIT’04, p. 274-278,
2004.
HARRISON, W.; WIERINGA, R.
Introduction to the workshop on
technology transfer in software
engineering. Proceedings of TT’06, p. 1-2,
2006.
PUNTER, T.; KRIKHAAR, R. L.; BRIL, R.
J. Sustainable Technology Transfer.
Proceedings of TT’06, p. 15-18, 2006.
GIDS, M.; VOS, T. Tales about a small
software testing bridge from academy to
SMEs. Proceedings of SSEE’06, p. 17-20,
2006.
ANTONIOL, G. Requiem for software
evolution research: a few steps toward the
creative age. Proceedings of IWPSE’07, p.
1-3, 2007.
HATCLIFF, J. Contract-Based Reasoning
for Verification and Certification of Secure
Information Flow Policies in Industrial
Workflows. Proceedings of ICFEM’08, p.
2-4, 2008.
ZHANG, D. et al. Software analytics as a
learning case in practice: approaches and
experiences. Proceedings of MALETS’11,
p. 55-58, 2011.
FOWLER, P. J. Technology transfer as a
collaboration: the receptor group.
Proceedings of International Conference
on Software Engineering, p. 332-333,
1990.
CANNING, A. A. et al. Sharing ideas: the
SEMSPLC Project. IEEE Review, p. 2326, 1994.
OHBA, M.; SATO, Y. Experimenting
component-based technology in industry
settings. Proceedings of International
Symposium on Assessment of Software
Tools and Technologies, p. 98-99, 1997.
SANTOS, G. et al. Strategic Alignment
between Academy and Industry: A
Virtuous Cycle to Promote Innovation in
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
Incompleto
123
31
32
33
34
35
36
37
38
39
40
41
Technology. Braziliam Symposium on
Software Engineering, p. 196-200, 2012.
1997 SCIENCE LINKMAN, S.; ROMBACH, H. D.
DIRECT
Experimentation as a vehicle for software
technology transfer-A family of software
reading techniques. Information and
Software Technology, v. 39, n. 11, p. 777780, 1997.
2005 ACM
MATHIASSEN, L.; VOLGESANG, L.
Managing knowledge in software method
adoption. International Journal of Business
Information Systems, v. 1, n. 1/2, p. 102117, 2005.
2006 ACM
BASS, M. A survey of software related
academic collaborations at siemens.
Proceedings of TT’06, p. 55-58, 2006.
2010 ACM
MORGAN L.; FINNEGAN, P. Open
innovation in secondary software firms: an
exploration of managers' perceptions of
open source software. ACM SIGMIS
Database, v. 41, n. 1, p. 76-95, 2010.
2012 ACM
CARTAXO, B. et al. ESEML: empirical
software engineering modeling language.
Proceedings of DSM’12, p. 55-60, 2012.
1994 IEEE
GRADY, R. B.; SLACK, T. V. Key Lessons
in Achieving Widespread Inspection Use.
IEEE Software, p. 46-57, 1994.
1998 IEEE
LEVINE, L.; MONARCH, I. Collaborative
technology in the learning organization:
integrating process with information flow,
access and interpretation. Proceedings of
Hawaii International Conference on
System Sciences, v. 1, p. 444-459, 1998.
1999 IEEE
USHAKOV, I. B. Introducing an OO
Technology in Non-OO Standard
Environment. Proceedings of International
Symposium and Forum on Software
Engineering Standards, p. 158-162, 1999.
2000 IEEE
RUHE, G. Methodological Contributions to
Professional Education and Training.
COMPSAC’00, p. 11-16, 2000.
2000 IEEE
LAW, W.; SHANKARARAMAN, V.;
ROBINSON, B. A process framework for
the systematic evaluation and diffusion of
reuse methods. Proceedings of Australian
Software Engineering Conference, p. 7383, 2000.
2005 IEEE
SCHMID, K. et al. Introducing the puLSE
approach to an embedded system
Incompleto
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
124
42
2005 IEEE
43
2005 IEEE
44
2005 IEEE
45
2007 IEEE
46
2010 IEEE
47
2011 IEEE
48
1986 SCIENCE
DIRECT
49
1987 SCIENCE
DIRECT
50
1991 SCIENCE
DIRECT
51
1993 SCIENCE
DIRECT
52
1997 SCIENCE
DIRECT
population at testo AG. Proceedings of
ICSE’05, p. 544-552, 2005.
BRABERMAN, V.; KICILLOF, N.;
OLIVERO, A. A Scenario-Matching
Approach to the Description and Model
Checking of Real-Time Properties. IEEE
Transactions on Software Engineering, v.
31, n. 12, p. 1028-1041, 2005.
UMARJI, M.; EMURIAN, H. Acceptance
Issues in Metrics Program Implementation.
IEEE International Symposium Software
Metrics, p. 10-20, 2005.
DYBA, T.; KITCHENHAM, B. A.;
JORGENSEN, M. Evidence-based
software engineering for practitioners.
IEEE Software, v. 22, n. 1, p. 58-65, 2005.
STRATTON, W. C. et al. The SAVE Tool
and Process Applied to Ground Software
Development at JHU/APL: An Experience
Report on Technology Infusion. SEW’07,
p. 187-193, 2007.
ERDOGMUS, H. Déjà Vu: The Life of
Software Engineering Ideas. IEEE
Software, v. 27, n. 1, p. 2-5, 2010.
BELLAMY, R.; JOHN, B.; KOGAN, S.
Deploying CogTool: integrating
quantitative usability assessment into realworld software development. ICSE’11, p.
691-700, 2011.
TATKIN, H. The Japan-Singapore Institute
of Software Technology — A case study in
technology transfer. Education and
Computing, v. 1, n. 4, p. 249-263, 1986.
REIFER, D. J. SoftCost-R: User
experiences and lessons learned at the
age of one. Journal of Systems and
Software, v. 7, n. 4, p. 279-286, 1987.
BLOOMFIELD, R. E.; FROOME, P. K. D.
Formal methods in the production and
assessment of safety critical software.
Reliability Engineering & System Safety, v.
32, n. 1-2, p. 51-66, 1991.
KOCH, G. R. Process assessment: the
‘BOOTSTRAP’ approach. Information and
Software Technology, v. 35, n. 6-7, p. 387403, 1993.
ZELKOWITZ, M.; CUTHILL, B. Application
of an information technology model to
software engineering environments.
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
125
53
1998 SCIENCE
DIRECT
54
2000 SCIENCE
DIRECT
55
2001 SCIENCE
DIRECT
56
2002 SCIENCE
DIRECT
57
2002 SCIENCE
DIRECT
58
2003 SCIENCE
DIRECT
59
2004 SCIENCE
DIRECT
60
2008 SCIENCE
DIRECT
61
2011 SCIENCE
DIRECT
Journal of Systems and Software, v. 37. n.
1, p. 27-40, 1997.
RINE, D. C.; SONNEMANN, R. M.
Investments in reusable software. A study
of software reuse investment success
factors. Journal of Systems and Software,
v. 41, n. 1, p. 17-32, 1998.
CIOCH, F. A.; BRABBS, J. M.; SIEH, L.
The impact of software architecture reuse
on development processes and standards.
Journal of Systems and Software, v. 50, n.
3, p. 221-236, 2000.
EDAN, Y.; PLISKIN, N. Transfer of
software engineering tools from
information systems to production
systems. Computer & Industrial
Engineering, v. 39, n. 1-2, p. 19-34, 2001.
NELSON, R. A. et al. Infusing the use of
seasonal climate forecasting into crop
management practice in North East
Australia using discussion support
software. Agricultural Systems, v. 74, n. 3,
p. 393-414, 2002.
RAINER, A.; HALL, T. Key success factors
for implementing software process
improvement: a maturity-based analysis.
Journal of Systems and Software, v. 62, n.
2, p. 71-84, 2002.
FUJIWARA, H. et al. Case studies to
evaluate a domain specific application
framework based on complexity and
functionality metrics. Information and
Software Technology, v. 45, n. 1, p. 43-49,
2003.
GREEN, G. C.; COLLINS, R. W.;
HEVNER, A. R. Perceived control and the
diffusion of software process innovations.
The Journal of High Technology
Management Research, v. 15, n. 1, p.
123-144, 2004.
STAPLES, M.; NIAZI, M. Systematic
review of organizational motivations for
adopting CMM-based SPI. Information and
Software Technology, v. 50, n. 7-8, p. 605620, 2008.
ROOIJ, S. W. Higher education subcultures and open source adoption.
Computers & Education, v. 57, n. 1, p.
1171-1183, 2011.
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
126
62
63
64
65
66
67
68
69
70
71
2011 SCIENCE AYALA, C. et al., 2011. Selection of third
DIRECT
party software in Off-The-Shelf-based
software development—An interview study
with industrial practitioners. Journal of
Systems and Software, v. 84, n. 4, p. 620637, 2011.
2012 SCIENCE SPINELLIS, D.; GIANNICAS, V.
DIRECT
Organizational adoption of open source
software. Journal of Systems and
Software, v. 85, n. 3, p. 666-682, 2012.
1982 TT
ROLAND, R. J. A decision support system
model for technology transfer. The Journal
of Technology Transfer, v. 7, n. 1, p. 7393, 1982.
2000 STTT
AVRUNIN, G. S.; CORBETT, J. C.;
DWYER, M. B. Benchmarking finite-state
verifiers. International Journal on Software
Tools for Technology transfer, v. 2, n. 4, p.
317-320, 2000.
2009 STTT
WYK, E. V., HEIMDAHL, M. P. E.
Flexibility in modeling languages and
tools: a call to arms. International Journal
on Software Tools for Technology
Transfer, v. 11, n. 3, p. 203-215, 2009.
1999 ACM
HEFNER, R. A Corporate Approach to
Technology Transition. Proceedings of
HICSS-32, volume: Track 7, 1999.
1988 SCIENCE BAYER, J.; MELONE, N. A critique of
DIRECT
diffusion theory as a managerial
framework for understanding adoption of
software engineering innovations.
Proceedings of Annual Hawaii
International Conference on System
Sciences, v. 2, p. 311-316, 1988.
2005 ACM
BRABERMANN, V.; KICILOFF, N.;
OLIVERO, A. A Scenario-Matching
Approach to the Description and Model
Checking of Real-Time Properties. IEEE
Transactions on Software Engineering, v.
31, n. 12, p. 1028-1041, 2005.
2005 ACM
UMARJI, M., EMURIAN H. Acceptance
Issues in Metrics Program Implementation.
IEEE International Symposium on
Software Metrics, p. 10-20, 2005.
2012 ACM
MARSAN, J.; PARE, G.; BEAUDRY, A.
Adoption of open source software in
organizations: A socio-cognitive
perspective. The Journal of Strategic
Information Systems, v. 21, n. 4, p. 257273, 2012.
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Irrelevante
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
127
72
2010 ACM
73
1995 ACM
74
2009 ACM
75
2000 ACM
76
2000 ACM
77
2000 ACM
78
2007 ACM
79
2006 ACM
80
1999 ACM
81
2005 ACM
HAUGE, O.; AYALA, C.; CONRADI, R.
Adoption of open source software in
software-intensive organizations - A
systematic literature review. Information
and Software Technology, v. 52, n. 11, pp.
1133-1154, 2010.
KRASNER, H. Bottlenecks in the transfer
of software engineering technology:
lessons learned from a consortium failure.
Proceedings of Hawaii International
Conference on System Sciences, v. 4, p.
635-641, 1995.
COLOSIMO, M. et al. Evaluating legacy
system migration technologies through
empirical studies. Information and
Software Technology, v. 51, n. 2, p. 433447, 2009.
ROMBACH, D. Fraunhofer: the German
model for applied research and technology
transfer. Proceedings of the International
Conference on Software Engineering, p.
531-537, 2000.
CURTIS, B. From MCC and CMM:
technology transfers bright and dim.
Proceedings of ICSE’00, p. 521-530,
2000.
COLYER, A. M. From research to reward:
challenges in technology transfer.
Proceedings of the International
Conference on Software Engineering, p.
569-576, 2000.
MISRA, S. C.; KUMAR, V.; KUMAR, U.
Identifying some important success factors
in adopting agile software development
practices. Journal of Systems and
Software, v. 82, n. 11, p. 1869-1890, 2007.
PRESSBURGER, T. et al. Infusing
Software Engineering Technology into
Practice at NASA. SMC-IT 2006, p. 9-100,
2006.
USHAKOV, I. B. Introducing an OO
Technology in Non-OO Standard
Environment. Proceedings of International
Symposium and Forum on Software
Engineering Standards, p. 158-162, 1999.
SCHMID, K. et al. Introducing the puLSE
approach to an embedded system
population at testo AG. Proceedings of
ICSE’05, p. 544-552, 2005.
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
128
82
2012 ACM
83
2007 ACM
84
2006 ACM
85
2009 ACM
86
2012 ACM
87
2006 ACM
88
2000 ACM
89
2000 ACM
90
1996 ACM
91
2004 ACM
SPINELLIS, D.; GIANNIKAS, V.
Organizational adoption of open source
software. Journal of Systems and
Software, v. 85, n. 3, p. 666-682, 2012.
JEDLITSCHKA, A. et al. Relevant
Information Sources for Successful
Technology Transfer: A Survey Using
Inspections as an Example. Proceedings
of ESEM’07, p. 31-40, 2007.
HINCHEY, M. G. et al. Software
Assurance Research Infusion: The NASA
Experience. Proceedings of ISoLa’06, p.
18-27, 2006.
PUNTER, T.; KRIKHAAR, R. L.; BRIL, R.
J. Software engineering technology
innovation - Turning research results into
industrial success. Journal of Systems and
Software, v. 82, n. 6, p. 993-1003, 2009.
SANTOS, G. et al. Strategic Alignment
between Academy and Industry: A
Virtuous Cycle to Promote Innovation in
Technology. Proceedings of Brazilian
Symposium on Software Engineering, p.
196-200, 2012.
HARRISON, W. Technology Transfer and
the Tech Broker. IEEE Software, v. 23, n.
5, p. 5-7, 2006.
ABERNETHY, K. et al. Technology
Transfer Issues for Formal Methods of
Software Specification. Proceedings of
13th Conference on Software Engineering
Education, p. 23-31, 2000.
NISHIYAMA, T.; IKEDA, K.; NIWA, T.
Technology transfer macro-process: a
practical guide for the effective
introduction of technology. Proceedings of
the International Conference on Software
Engineering, p. 577-586, 2000.
MITCHELL, K. I. Technology transfer to
and from the industrial sector.
Proceedings of the International
Conference on Software Engineering, p.
495-496, 1996.
KEUNG, J.; JEFFERY, R.; KITCHENHAM,
B. The Challenge of Introducing a New
Software Cost Estimation Technology into
a Small Software Organisation.
Proceedings of Australian Software
Engineering Conference, p. 52-59, 2004.
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
Duplicado.
1ª Fonte:
IEEE
129
92
2003 ACM
93
2013 ACM
GALLIVAN, M. J. The influence of
software developers' creative style on their
attitudes to and assimilation of a software
process innovation. Information &
Management, v. 40, n. 5, p. 443-465,
2003.
EDISON, H.; ALI, N.; TORKAR, R.
Towards innovation measurement in the
software industry. Journal of Systems and
Software, v. 86, n. 5, p. 1390-1407, 2013.
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
Duplicado.
1ª Fonte:
SCIENCE
DIRECT
130
APÊNDICE C – Protocolo do Mapeamento Sistemático
PROTOCOLO
Transferência de Tecnologia entre Academia e
Indústria em Engenharia de Software: Um Mapeamento
Sistemático
Ramon Nobrega Tenório¹
Sérgio Castelo Branco Soares¹
Emanoel Francisco Sposito Barreiros¹
Helaine Solange Lins¹
Adauto Trigueiro de Almeida Filho¹
Diogo Vinicius de Sousa Silva¹
¹Centro de Informática – CIn
Universidade Federal de Pernambuco – UFPE
Recife-PE, Brasil
{rnt,scbs,efsb,hsl,ataf,dvss}
Outubro de 2013
131
Equipe
Nome
Ramon Nobrega Tenório
Sérgio Castelo Branco
Soares
Emanoel Francisco
Sposito Barreiros
Helaine Solange Lins
Adauto Trigueiro de
Almeida Filho
Diogo Vinicius de Sousa
Silva
Afiliação
CIn – Universidade Federal de
Pernambuco
CIn – Universidade Federal de
Pernambuco
CIn – Universidade Federal de
Pernambuco
CIn – Universidade Federal de
Pernambuco
CIn – Universidade Federal de
Pernambuco
CIn – Universidade Federal de
Pernambuco
Papel
Autor e
Revisor
Revisor
Revisor
Revisor
Revisor
Revisor
132
C.1 Introdução
A Engenharia de software, apesar de se tratar de uma área de
conhecimento ainda jovem, nos últimos anos tem assumido papel importante na
sociedade, e o reflexo é visto em ambientes onde a tecnologia em software tem
participado ativamente na condução de procedimentos relacionados à atividades
do dia a dia. Fatores que tenham capacidade de afetar de alguma forma a
sociedade devem receber tratamento rigoroso e a produção de software não é
diferente. A tomada de decisão quando da escolha por uma tecnologia precisa
estar munida de evidências que comprovem a existência de vantagem em
relação ao que já é praticado e, com isto posto, enxerga-se a necessidade de se
aplicar metodologias confiáveis, disciplinadas, adequadas a área e que
garantam a qualidade do que é coletado.
A Engenharia de Software Baseada em Evidência (EBSE) é um
mecanismo que tem como propósito aprimorar a tomada de decisão relacionada
ao desenvolvimento e manutenção de software integrando as melhores
evidências de pesquisas e valores humanos, assim diminuindo a lacuna
existente entre pesquisa e prática (DYBA et al., 2005).
De acordo com o estudo desenvolvido por Dyba et al. (2005), o processo
para aplicação da EBSE envolve os cinco passos seguintes:

Converter um problema relevante ou uma necessidade de informação
em uma pergunta de pesquisa;

Pesquisar a literatura com o intuito de encontrar a melhor evidência
disponível para responder a pergunta de pesquisa;

Criticamente avaliar a evidência em relação a validade, impacto e
aplicabilidade;

Integrar a evidência com experiências práticas e circunstâncias para
tomada de decisão sobre a prática;

Avaliar a performance dos passos anteriores e procurar meios de
melhorá-los.
133
Uma das principais tecnologias que sustentam a EBSE é a Revisão
Sistemática da Literatura (RSL) ou somente Revisão Sistemática (RS). Este
termo é usado para se referir a uma metodologia de estudo secundário com
propósito de identificar, avaliar e interpretar de forma imparcial, rigorosa e
auditável todas as evidências disponíveis em estudos primários que sejam
relevantes a uma pergunta de pesquisa específica (KITCHENHAM et al., 2004,
2011; KITCHENHAM; CHARTERS, 2007; BIOLCHINI et al., 2005). Segundo
Petersen et al. (2008), há diversos benefícios quando da aplicação deste
método, entre eles a redução de viés, a coleta de um amplo conjunto de
situações e contextos que podem permitir mais generalizações e o uso de metaanálise estatística que permite detectar mais do que estudos individuais em
isolamento.
Um outro estudo secundário já bastante utilizado no campo da medicina
e que ainda é pouco aplicado em Engenharia de Software é o Mapeamento
Sistemático (MS). Considerado uma forma mais aberta de Revisão Sistemática
(KITCHENHAM; CHARTERS, 2007), este estudo tem o objetivo de promover
uma visão geral da área e identificar a natureza e a extensão de estudos
empíricos disponíveis que possam responder uma questão de pesquisa de maior
abrangência, o que contribui para a coleta de um maior número de estudos
primários. Recomenda-se este tipo de estudo para áreas onde existem poucos
estudos primários relevantes e de alta qualidade (KITCHENHAM; CHARTERS,
2007).
Deste modo, este documento apresenta um protocolo de mapeamento
sistemático cujo propósito é guiar a coleta de informações relevantes
relacionadas ao processo de transferência tecnológica entre academia e
indústria, no contexto da Engenharia de Software, que possam identificar
lacunas que propiciem abertura à geração de novos estudos primários ou a
realização de um outro estudo de maior especificidade.
C.2 Escopo e Questões de Pesquisa
134
Determinar a estrutura e definir as questões de pesquisa são passos
essenciais para o processo de busca por estudos primários que sejam
adequados ao que predispõe o estudo. Portanto, com o intuito de encontrar
estudos primários relevantes à temática, seguem as questões de pesquisa que
precisam ser abordadas por este protocolo.

QP1: Que fatores influenciam positivamente a transferência de
tecnologia entre academia e indústria em engenharia de software?

QP2: Que fatores influenciam negativamente a transferência de
tecnologia entre academia e indústria em engenharia de software?

QP3: Quais são as abordagens existentes para transferência de
tecnologia entre academia e indústria em engenharia de software?
C.3 Estratégia e Fonte de Busca
A identificação e seleção dos termos para a composição da string de
busca é um dos primeiros passos a se levar em conta quando da definição da
estratégia que irá guiar o processo. Segundo Kitchenham e Charters (2007), a
criação da estratégia de busca é um processo iterativo e deveria ser
desenvolvida com o auxílio de consultores com experiência relevante no campo
de estudo.
Deste modo, a elaboração da string de busca seguiu os seguintes passos:

Palavras-chave foram derivadas das questões de pesquisa;

Uma busca por estudos relevantes relacionados a pesquisa foi
realizada em Revistas e Bibliotecas Digitais, onde foram coletadas
palavras-chave constantes nesses estudos;

Sinônimos e abreviações de termos derivados dos passos anteriores
foram considerados;

Foram consultados especialistas relacionados ao âmbito da pesquisa;

Testes com a utilização de combinações diferentes dos termos
identificados foram realizados.
135
Como resultado da realização dos passos acima, são exibidos no Quadro
1 os termos e sinônimos identificados.
Quadro 1 - Termos e Sinônimos para composição da String de Busca
Termos
Sinônimos
Engenharia de Software
software engineering
Transferência de Tecnologia
technology diffusion, technology infusion,
technology transfer, transfer of technology,
technology transition, technology, innovation,
technology adoption, innovation adoption
Influências Positivas e Negativas
obstacle, improvement, incentive, difficult,
insight, barrier, constraint, success fator,
problem, benefit, restriction, implication
Abordagens
pattern,
method,
approach,
process,
framework, technique, practice, guideline,
strategy, methodology
Fonte: Próprio autor
Assim, com a identificação dos termos, finalizou-se o processo com o
auxílio dos conectores Booleanos OR (ou) e AND (e), onde OR foi utilizado na
associação de palavras sinônimas, já o conector AND foi empregado para ligar
palavras-chave. Vale ressaltar que todos os termos foram trabalhados na língua
inglesa, de modo a se adequar com a linguagem utilizada nos estudos e fontes.
O Quadro 2 apresenta a string de busca gerada.
Quadro 2 - String para a realização das buscas automatizadas
String de Busca
("software engineering") AND ("technology diffusion" OR "technology infusion" OR "technology
transfer" OR "transfer of technology" OR "technology transition" OR "technology innovation"
136
OR "technology adoption" OR "innovation adoption") AND (obstacle OR improvement OR
incentive OR difficult OR insight OR barrier OR constraint OR success factor OR problem OR
benefit OR restriction OR implication) AND (pattern OR method OR approach OR process OR
framework OR technique OR practice OR guideline OR strategy OR methodology)
Fonte: Próprio autor
Para dar início ao processo de busca automatizada, cujo propósito é
encontrar estudos primários relevantes através da aplicação da string criada,
foram selecionadas as seguintes fontes eletrônicas:

IEEExplore Digital Library (httt://ieeexplore.ieee.org/);

ACM Digital Library (http://portal.acm.org);

Elsevier SciencDirect (http://www.sciencedirect.com).
Diante da relevância em relação aos tópicos abordados pelo trabalho e para
que não haja perda de informação, foi identificada a necessidade da realização
de buscas manuais nos seguintes periódicos (a data inicial de pesquisa em cada
periódico identifica a ocorrência de sua primeira edição):

The Journal of Technology Transfer (de 1977 a 2013);

The International Journal on Software Tools for Technology Transfer (de
1997 a 2013).
C.4 Seleção de Estudos
Esta etapa visa avaliar os estudos em potencial que foram selecionados
quanto a relevância em relação as questões de pesquisa. Deste modo, a
inclusão ou não de algum dos estudos leva em consideração critérios de inclusão
e exclusão.
C.4.1 Critérios de Inclusão e Exclusão
137
Os estudos serão selecionados se forem adequados aos seguintes
critérios:

O estudo deve estar disponível na web;

O estudo deve estar escrito em inglês;

O estudo deve apresentar fatores que influenciam positiva ou
negativamente a Transferência de Tecnologia ou tratar de
alguma abordagem relacionada ao tema;

O estudos deve estar relacionado a Transferência de
Tecnologia em Engenharia de Software.
Em contrapartida, serão excluídos os estudos segundo os seguintes
critérios:

Estudos sem relevância para a pesquisa;

Estudos duplicados, considerando o mais completo;

Estudos incompletos (resumos, resumos expandidos ou
apresentações).
C.4.2. Processo de Seleção dos Estudos Primários
O processo de seleção dos estudos primários segue os seguintes passos:

O estágio inicial é caracterizado pela execução das buscas manuais e
automáticas, com o propósito de selecionar potenciais estudos
primários com relevância para a pesquisa de acordo com a estratégia
anteriormente definida. Deste modo, avalia-se título, palavras-chave e
abstract afim de descartar estudos claramente não relacionados à
pesquisa. Normalmente, neste ponto, nota-se o retorno de uma grande
quantidade de estudos, o que é justificado em decorrência da
abrangência e natureza das questões. Ao final deste passo inicial, é
gerada uma lista de potenciais estudos;
138

Em uma segunda etapa, todos os potenciais estudos são avaliados
de acordo com os critérios cujo propósito é considerar se deve ser
incluído na lista final ou excluído definitivamente. Logo, há o processo
de leitura por completo dos potenciais estudos e em consequência é
gerada a lista de inclusão e exclusão;

Os possíveis conflitos que surgirem são trabalhados entre os
pesquisadores afim de se chegar a um consenso. Assim, é definida a
lista final de estudos primários relevantes;

O registro das informações é mantido através dos Formulários A, B e
C. O Formulário A é utilizado para o registro dos estudos que tiveram
sua inclusão confirmada, já o Formulário B tem função de registrar
todos os estudos que foram excluídos. Para finalizar, usa-se o
Formulário C para o registro da extração de dados.
C.4.3. Extração de Dados
Segundo Kitchenham e Charters, (2007), o objetivo da extração de dados
é registrar as informações obtidas dos estudos primários. Em decorrência dessa
necessidade, foram definidos três formulários com finalidades distintas.
C.4.3.1. Formulário A
O objetivo deste formulário é registrar dados relevantes relacionados aos
estudos que tiveram sua inclusão confirmada. Assim, o formulário é composto
pelos seguintes campos:
139

ID: Um identificador é definido para o estudo com o propósito de
auxiliar na referência do estudo no mapeamento;

Fonte: registra a fonte onde o estudo foi encontrado;

Ano: registra o ano de publicação;

Título: registra o título do estudo;

Autor: registra a lista de autores do estudo;

País: registra a lista de países referentes as instituições de origem dos
autores.
C.4.3.2. Formulário B
Este formulário tem a finalidade de registrar informações relacionadas à
exclusão dos estudos que não tiveram relevância de acordo com a estratégia
definida. Os campos definidos para registrar esta etapa são os seguintes:

ID: Um identificador é definido para o estudo com o propósito de
auxiliar na referência do estudo no mapeamento;

Fonte: registra a fonte onde o estudo foi encontrado;

Ano: registra o ano de publicação;

Título: registra o título do estudo;

Autor: registra a lista de autores do estudo;

Critério de exclusão: registra qual o critério utilizado para excluir o
estudo.
C.4.3.3. Formulário C
Este formulário tem a finalidade de registrar informações relevantes dos
estudos primários selecionados que respondem as questões de pesquisa. As
informações são as seguintes:
140

Data da Avaliação: registra a data em que o artigo foi avaliado;

Revisor: registra o pesquisador que coletou a informação e utilizou do
formulário;

Questão de Pesquisa 1: Que fatores influenciam positivamente a
transferência de tecnologia entre academia e indústria em engenharia
de software?

Questão de Pesquisa 2: Que fatores influenciam negativamente a
transferência de tecnologia entre academia e indústria em engenharia
de software?

Questão de Pesquisa 3: Quais são as abordagens mais utilizadas?

Nota: registra alguma observação relevante que o revisor queira
documentar.
C.5 Síntese dos Dados
Com o propósito de representar os dados coletados, é realizada uma síntese
das informações de forma a mapear o conhecimento gerado na pesquisa em
categorias de acordo com sua representatividade. Esta síntese visa relacionar
os tópicos que tratam da transferência de tecnologia em engenharia de software,
os tipos de influências positivas e negativas e as abordagens utilizadas.
Recursos gráficos são utilizados como meio para a apresentação dos
resultados de cada categoria, assim auxiliando na identificação de lacunas onde
haja escassez de estudos e também possibilidades de pesquisas futuras com
um maior nível de especificidade.
Referências do Protocolo
141
BIOLCHINI, J. et al. Systematic review in software engineering: relevance and
utility, Technical Report, PESC - COPPE/UFRJ, 2005.
DYBA, T.; KITCHENHAM, B.; JORGENSEN, M. Evidence-based software
engineering for practitioners. IEEE Software, v. 22, n. 1, p. 58–65, 2005.
KITCHENHAM, B.; DYBA, T.; JORGENSEN, M. Evidence-based software
engineering. In: Proceedings of the 27th IEEE International Conference on
Software Engineering (ICSE 2004), IEEE Computer Society, 2004.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for Performing Systematic
Literature Reviews in Software Engineering, Version 2.3, Technical Report.
Software Engineering Group, Keele University and Department of Computer
Science University of Durham, 2007.
KITCHENHAM, B.; BUDGEN, D.; BRERETON, O.P. Using mapping studies as
the basis for further research – a participant–observer case study. Information
and Software Technology, v. 53, n. 6, p. 638–651, 2011.
PETERSEN, K. et al. Systematic mapping studies in software engineering. In
Proceeding of the 12th International Conference on Evaluation and Assessment
in Software Engineering, University of Bari, Italy, 2008.
TRAVASSOS, G.; BIOLCHINI, J. Revisões Sistemáticas Aplicadas a Engenharia
de Software. In: XXI SBES - Brazilian Symposium on Software Engineering, João
Pessoa, PB, Brasil, 2007.
142