universidade federal de pernambuco centro de …‡… · dissertação de mestrado profissional...
TRANSCRIPT
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
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 da Universidade Federal de
Pernambuco como requisito parcial para
obtenção do grau de Mestre Profissional em
Ciência da Computação.
Orientador: Prof. Sérgio Castelo Branco Soares
RECIFE
2014
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
Catalogação na fonte Bibliotecária Joana D’Arc L. Salvador, CRB 4-572
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 Classificação Segundo Cooper..................................................... 33
3.2 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
15
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
16
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?
17
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;
18
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.
19
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
20
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:
21
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)
22
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
23
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 Exemplos
A. People-Mover Model 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.
B. Communication Model Publicações em revistas científicas, relatórios técnicos.
C. On-The-Shelf Model Uma aplicação com interface simples e agradável; um manual de utilização de fácil manuseio e completo.
D. Vendor Model 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.
24
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).
25
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
26
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.
27
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, Evidence-
Based 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;
28
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
29
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:
30
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.
31
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.
32
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).
33
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
34
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
Foco
Resultados de Pesquisa
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 pesquisador-
revisor. 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.
35
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
36
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,
37
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;
38
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
39
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.
40
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.
41
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.
42
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.
ACM69%
SCIENCE DIRECT28%
IEEE3%
ACM SCIENCE DIRECT IEEE
43
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.
STTT33%
TT67%
STTT TT
44
Gráfico 4.3 - Resultado da Busca Automatizada e Manual juntas
Fonte: Próprio autor
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,
ACM52%
SCIENCE DIRECT21%
IEEE2%
STTT8%
TT17%
ACM SCIENCE DIRECT IEEE STTT TT
ACM45%
SCIENCE DIRECT24%
IEEE26%
STTT2%
TT3%
ACM SCIENCE DIRECT IEEE STTT TT
45
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
Seleção de Estudos Primários
Fontes Estudos
Retornados
#1 Seleção #2 Seleção
Excluído Incluído
Estudos
Potencialmente
Relevantes
Não R
ele
va
nte
Repetid
o/D
uplic
ado
Incom
ple
to
Sem
Acesso
Estudos
Primários
IEEE 111 47 12 0 4 0 31
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
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.
46
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
0 10 20 30 40 50 60
ESCÓCIA
DINAMARCA
ISRAEL
HONG KONG
INDIA
HOLANDA
AUSTRIA
NORUEGA
TAIWAN
CHILE
NOVA ZELÂNDIA
ESPANHA
JAPÃO
AUSTRÁLIA
ITÁLIA
CANADA
SUÉCIA
INGLATERRA
ALEMANHA
EUA
47
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.
Gráfico 4.6 - Tipos de fatores positivos identificados
Fonte: Próprio autor
0,00% 2,00% 4,00% 6,00% 8,00% 10,00% 12,00% 14,00%
Experimentação
Apoio da Alta Gerência
Formação e Aprendizagem
Percepção do Benefício
Cooperação e Colaboração
Material de Apoio (Packaging)
Custo
Agente
Senso de Oportunidade (Timing)
Compatibilidade com o Processo Atual
Resposta ou Retorno (Feedback)
Integração
Cultura
Relacionamento
Pessoa-Chave
Parceria
Motivação
Reorganização Societária
Trabalho e Dedicação
Compromisso com o Cliente
Desejo de Inovar
Ambiente
Normas
Trabalho em Equipe
Protótipo
Recompensa
Fácil de Usar
Reutilização do processo de gestão
Tratamento da transferência
Flexibilidade
Vantagem Relativa
Ferramentas CASE
Caso de Negócio
SOA
Público
Melhoria Contínua
Competitividade
Satisfação do Cliente
Características Pessoais
Comunicação
Projetos de Pesquisa
48
Tabela 4.1 - Resumo dos estudos por fator positivos encontrado
Código Tópicos de Pesquisa Referências – EP: Estudos Primários
Quantidade de Trabalhos – (%)
FP1 Experimentação EP31, EP32, EP38, EP42, EP61, EP65, EP67, EP85, EP86
9 (11,54 %)
FP2 Apoio da Alta Gerência EP15, EP19, EP22, EP41, EP77
5 (6,41 %)
FP3 Formação e Aprendizagem
EP15, EP39, EP40, EP69, EP70
5 (6,41 %)
FP4 Percepção do Benefício EP10, EP66, EP75, EP77 4 (5,13 %)
FP5 Cooperação e Colaboração
EP37, EP49, EP59, EP69 4 (5,13 %)
FP6 Material de Apoio (Packaging)
EP18, EP28, EP44 3 (3,85 %)
FP7 Custo EP1, EP9, EP19 3 (3,85 %)
FP8 Agente EP4, EP5, EP79 3 (3,85 %)
FP9 Senso de Oportunidade (Timing)
EP54, EP69 2 (2,56 %)
FP10 Compatibilidade com o processo atual
EP33, EP45 2 (2,56 %)
FP11 Resposta ou Retorno (Feedback)
EP84, EP57 2 (2,56 %)
FP12 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
EP69 1 (1,28 %)
FP21 Desejo de Inovar 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 Reutilização do processo de gestão
EP27 1 (1,28 %))
FP29 Tratamento da transferência
EP34 1 (1,28 %)
FP30 Flexibilidade EP58 1 (1,28 %)
FP31 Vantagem Relativa EP19 1 (1,28 %)
FP32 Ferramentas CASE EP74 1 (1,28 %)
49
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.
50
Gráfico 4.7 - Tipos de fatores negativos identificados
Fonte: Próprio autor
0,00% 2,00% 4,00% 6,00% 8,00% 10,00% 12,00% 14,00%
Custo
Falta de ferramenta
Falta de entendimento
Formação e Aprendizagem
Resistência a mudança
Falta de correspondência
Comunicação
Falta de maturidade
Evidência
Experiência
Recompensas pessoais
Cultura
Incerteza
Percepção do benefício
Relacionamento
Deficiências gerais
Retorno claro
Resposta ou retorno (Feedback)
Agenda e Orçamento apertado
Expectativa
Aversão ao risco
Perspectiva
Intervenção da gerência
Público errado
Falta de orientação
Ambiente
Robustez
Material de apoio (Packaging)
Core Business
Sucesso do negócio
Lacuna no processo de inovação conjunta
Falta de confiança
Pessoas inadequadas
Retorno do Investimento
51
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
– (%)
FN1 Custo EP15, EP16, EP23, EP24,
EP62, EP78
6 (12,00 %)
FN2 Falta de ferramenta EP21, EP47, EP60 4 (8,00 %)
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 Resposta ou retorno
(Feedback)
EP20 1 (2,00 %)
FN19 Agenda e orçamento
apertado
EP34 1 (2,00 %)
FN20 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 Material de apoio
(Packaging)
EP38 1 (2,00 %)
FN29 Core business EP68 1 (2,00 %)
FN30 Sucesso do negocio EP59 1 (2,00 %)
FN31 Lacuna no processo de
inovação conjunta
EP59 1 (2,00 %)
FN32 Falta de confiança EP59 1 (2,00 %)
FN33 Pessoas inadequadas EP59 1 (2,00 %)
FN34 ROI EP30 1 (2,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
52
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.
Gráfico 4.8 - Tipos de abordagens identificadas
Fonte: Próprio autor
Tabela 4.3 – Resumo dos estudos por abordagem encontrada
Framework33%
Modelo47%
Processo13%
Esquema7%
Framework Modelo Processo Esquema
53
Código Tópicos de
Pesquisa
Referências – EP: Estudos
Primários
Quantidade de Trabalhos –
(%)
A1 Modelo EP18, EP31, EP53, EP58,
EP72, EP78, EP85
7 (46,67 %)
A2 Framework EP14, EP36, EP51, EP55, EP70 5 (33,33 %)
A3 Processo EP30, EP34 2 (13,33 %)
A4 Esquema EP63 1 (6,67 %)
Fonte: Próprio autor
4.3 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.
54
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 experimentally-
based 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.”
55
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.”
56
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.”
57
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.”
58
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
59
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.
60
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.
61
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 [...]”
62
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
63
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.
64
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.”
65
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 [...]”
66
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.”
67
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:
68
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.”
69
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
70
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.
71
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.”
72
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
73
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.
74
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.”
75
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.
76
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.”
77
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.
78
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
79
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 time-
consuming 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.
80
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.”
81
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”
82
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
83
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
84
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.
85
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,
86
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.
87
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
88
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.
89
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).”
90
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.
91
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 [...]”
92
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 [...]”
93
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.
94
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.
95
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.”
96
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
97
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.”
98
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
99
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
100
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, pode-
se 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.
101
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.
102
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.
103
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
104
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;
105
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.
106
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.
107
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.
108
GOODE, S. Something for nothing: Management rejection of open source
software in Australian’s top firms. Information Manager, v. 42, n. 5, p. 669-
681, 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/SE-
0401 and NICTA TR 0400011T.1, 2004.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for Performing
Systematic Literature Reviews in Software Engineering, Version 2.3,
109
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
110
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. 111-
124, 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.
111
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. 80-
89, 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.
112
ZELKOWITZ, M. V.; WALLACE, D.; BINKLEY, D. Culture Conflicts in
Software Engineering Technology Transfer. In NASA Goddard Software
Engineering Workshop, 1998.
113
APÊNDICE A – Estudos Primários
ID Ano Fonte Referência
EP1 1979 TT 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.
EP2 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.
EP3 1980 ACM MCGILL, M. J. Considerations in the transfer of software engineering technology. AFIPS ’80, National Computer Conference, p. 683-686, 1980.
EP4 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.
EP5 1985 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.
EP6 1987 SCIENCE DIRECT
ALEXANDER, H.; POTTER, B. Case study: the use of formal specification and rapid prototyping to establish product feasibility. Information and Software Technology, v. 29, n. 7, p. 388-394, 1987.
EP7 1988 IEEE SNODGRASS, J. G. Software requirements specification from a cognitive psychology perspective. Proceedings of International Conference on Computer Languages, p. 422-430, 1988.
EP8 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.
EP9 1989 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.
EP10 1990 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.
EP11 1990 IEEE FINKELSTEIN, A.; MAIBAUM, T.; FINKELSTEIN, L. Engineering-in-the-large: software engineering
114
and instrumentation. UK IT Conference, p. 1-7, 1990.
EP12 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.
EP13 1991 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.
EP14 1992 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.
EP15 1993 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.
EP16 1993 IEEE DEWAL, S. CASE development: Improving software development by transfer of technology. Proceedings of Software Engineering Environments Conference, p. 199-208, 1993.
EP17 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.
EP18 1994 IEEE BASILI, V.; DASKALANTONAKIS, M. K.; YACOBELLIS, R. H. Technology Transfer at Motorola. IEEE Software, v. 11, n. 2, p. 70-76, 1994.
EP19 1995 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.
EP20 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.
EP21 1996 SCIENCE DIRECT
SAIEDIAN, H., HINCHEY, M. G. Challenges in the successful transfer of formal methods technology into industrial applications. Journal of Information and Software Technology, v. 38, n. 5, p. 313-322, 1996.
EP22 1996 SCIENCE DIRECT
RODGER, J. A.; PENDHARKAR, P. C.; BHATT, G. D. Diffusion theory and the adoption of software
115
innovation: Common errors and future issues. The Journal of High Technology Management Research, v. 7, n. 1, p. 1-13, 1996.
EP23 1997 IEEE FICHMAN, R. G.; CARROL, W. E.; KEMERER, C. F. Object Technology and Reuse: Lessons from Early Adopters. IEEE Computer, v. 30, n. 10, p. 47-59, 1997.
EP24 1997 SCIENCE DIRECT
HARDGRAVE, B. C. Adopting object-oriented technology: Evolution or revolution?. Journal of Systems and Software, v. 37, n. 1, p. 19-25, 1997.
EP25 1997 SCIENCE DIRECT
FOWLER, P. An expert system in the domain of software technology transfer. Expert Systems with Applications, v. 12, n. 3, p. 275-300, 1997.
EP26 1997 TT 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.
EP27 1998 IEEE 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.
EP28 1998 IEEE 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.
EP29 1998 SCIENCE DIRECT
JAGADEESAN, L. J.; VOTTA, L. G. Specification-based testing of reactive software: A case study in technology transfer. Journal of Systems and Software, v. 40, n. 3, p. 249-262, 1998.
EP30 1999 IEEE HEFNER, R. A Corporate Approach to Technology Transition. Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences, v. 7, 1999.
EP31 1999 SCIENCE DIRECT
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.
EP32 2000 ACM ROMBACH, D. Fraunhofer: the German model for applied research and technology transfer. Proceedings of the International Conference on Software Engineering, p. 531-537, 2000.
EP33 2000 ACM CURTIS, B. From MCC to CMM: technology transfers bright and dim. Proceedings of the ICSE’00, p. 521-530, 2000.
EP34 2000 ACM 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.
116
EP35 2000 IEEE COLYER, A. M. From research to reward: challenges in technology transfer. Proceedings of ICSE’00, p. 569-576, 2000.
EP36 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.
EP37 2000 IEEE SCHMID, K. et al. Introducing a software modeling concept in a medium-sized company. Proceedings of ICSE’00, p. 558-567, 2000.
EP38 2000 IEEE PFLEEGER, S. L.; MENEZES, W. Marketing Technology to Software Practitioners. IEEE Software, 17(1), p. 27-33, 2000.
EP39 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.
EP40 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.
EP41 2002 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.
EP42 2003 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.
EP43 2003 SCIENCE DIRECT
GALLIVAN, M. J. The influence of software developers’ creative style on their attitudes to and assimilation of a software process innovation. Information and Management, v. 40, n. 5, p. 443-465, 2003.
EP44 2004 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. 199-206, 2004.
EP45 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.
EP46 2005 SCIENCE DIRECT
GREEN, G. C.; HEVNER, A. R.; COLLINS, R. W. The impacts of quality and productivity perceptions
117
on the use of software process improvement innovations. Information and Software Technology, v. 47, n. 8, p. 543-553, 2005.
EP47 2006 ACM 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.
EP48 2006 ACM 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.
EP49 2006 ACM 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.
EP50 2006 ACM TILLEY, S.; HUANG, S. On the "selling" of academic research to industry. Proceeding of TT’06, p. 41-42, 2006.
EP51 2006 ACM WOO, F. et al. A framework for the effective adoption of software development methodologies. Proceeding of ACM-SE44, p. 198-203, 2006.
EP52 2006 ACM DORENBOS, D. Aligning technology transfer using basic business measures. Proceeding of TT’06, p. 19-22, 2006.
EP53 2006 ACM AOYAMA, M. Co-Evolutionary service-oriented model of technology transfer in software engineering. Proceeding of TT’06, p. 3-8, 2006.
EP54 2006 ACM LARSSON, M. et al. Technology transfer: why some succeed and some don't. Proceeding of TT’06, p. 23-28, 2006.
EP55 2006 ACM HAZZAN, O.; DUBINSKY, Y. The concept of change in technology transfer. Proceeding of TT’06, p. 29-34, 2006.
EP56 2006 ACM 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.
EP57 2006 IEEE 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.
EP58 2006 IEEE GORSCHEK, T. et al. A Model for Technology Transfer in Practice. IEEE Software, v. 23, n. 6, p. 88-95, 2006.
EP59 2007 ACM ROMBACH, D.; ACHATZ, R. Research Collaborations between Academia and Industry. Proceeding of FOSE’07, p. 29-36, 2007.
EP60 2007 IEEE MARKOSIAN, L. Z. et al. Program Model Checking Using Design-for-Verification: NASA Flight
118
Software Case Study. IEEE Aerospace Conference, p. 1-9, 2007.
EP61 2007 IEEE 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.
EP62 2007 IEEE HINCHEY, M. G. et al. Software Assurance Research Infusion: The NASA Experience. Proceeding of ISoLa’06, p. 18-27, 2007.
EP63 2007 SCIENCE DIRECT
CORBIN, R. D.; DUNBAR, C. B.; ZHU, Q. A three-tier knowledge management scheme for software engineering support and innovation. Journal of Systems and Software, v. 80, n. 9, pp. 1494-1505, 2007.
EP64 2007 STTT HUTH, M. Some current topics in model checking. International Journal on Software Tools for Technology Transfer, v. 9, n. 1, p. 25-36, 2007.
EP65 2008 ACM GUO, Y.; SEAMAN, C. B. A survey of software project managers on software process change. Proceeding of ESEM’08, p. 263-269, 2008.
EP66 2008 ACM 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.
EP67 2009 ACM 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.
EP68 2009 SCIENCE DIRECT
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.
EP69 2009 SCIENCE DIRECT
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.
EP70 2009 SCIENCE DIRECT
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.
EP71 2009 SCIENCE DIRECT
COLOSIMO, M. et al. Evaluating legacy system migration technologies through empirical studies. Information and Software Technology, v. 51, n. 2, p. 433-447, 2009.
EP72 2010 ACM IVARSSON, M.; GORSCHEK, T. A method for evaluating rigor and industrial relevance of technology evaluations. Journal of Empirical
119
Software Engineering, v. 16, n. 3, p. 365-395, 2010.
EP73 2010 IEEE 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.
EP74 2010 SCIENCE DIRECT
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.
EP75 2011 ACM BISHOP, J. et al. Browser-based software for technology transfer. Proceeding of SAICSIT’11, p. 338-340, 2011.
EP76 2011 IEEE ZHANG, H. et al. Impact of process simulation on software practice: an initial report. Proceeding of ICSE’11, p. 1046-1056, 2011.
EP77 2011 SCIENCE DIRECT
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.
EP78 2011 SCIENCE DIRECT
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.
EP79 2011 SCIENCE DIRECT
ZAFFAR, M. A.; KUMAR, R. L.; ZHAO, K. Diffusion dynamics of open source software: An agent-based computational economics (ACE) approach. Decision Support Systems, v. 51, n. 3, p. 597-608, 2011.
EP80 2012 ACM 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.
EP81 2012 IEEE 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.
EP82 2012 SCIENCE DIRECT
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. 257-273, 2012.
EP83 2012 SCIENCE DIRECT
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.
EP84 2012 SCIENCE DIRECT
SENAPATHI, M.; SRINIVASAN, A. Understanding post-adoptive agile usage: An exploratory cross-
120
case analysis. Journal of Systems and Software, v. 85, n. 6, p. 1255-1268, 2012.
EP85 2012 SCIENCE DIRECT
GU, V. C.; CAO, Q.; DUAN, W. Unified Modeling Language (UML) IT adoption — A holistic model of organizational capabilities perspective. Decision Support Systems, v. 54, n. 1, p. 257-269, 2012.
EP86 2013 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.
EP87 2013 SCIENCE DIRECT
EDISON, H.; ALI, N. B.; TORKAR, R. Towards innovation measurement in the software industry. Journal of Systems and Software, v. 86, n. 5, p. 1390-1407, 2013.
121
APÊNDICE B – Estudos Excluídos
ID Ano Fonte Referência Critério
1 2010 ACM JAGER, G. P.; HUISMAN, H. M.; KRUGER, H. A. A quantitative model to evaluate post-implementation efficiency of Scrum. Proceeding of SoMeT’10, p. 163-181, 2010.
Sem Acesso
2 2003 SCIENCE DIRECT
RIFKIN, S. Why New Software Processes Are Not Adopted. Advances in Computers, v. 59, p. 83-126, 2003.
Sem Acesso
3 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.
Sem Acesso
4 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. 297-344, 1998.
Sem Acesso
5 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. 121-124, 2006.
Sem Acesso
6 1979 SCIENCE DIRECT
GOODMAN, S. E. Software in the Soviet Union: Progress and Problems. Advances in Computers, v. 18, p. 231-287, 1979.
Sem Acesso
7 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.
Sem Acesso
8 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.
Sem Acesso
9 2002 ACM SEROUR, M. K. et al. Organizational Transition to Object Technology: Theory and Practice. Proceedings of OOIS’02, p. 229-241, 2002.
Sem Acesso
122
10 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.
Sem Acesso
11 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.
Sem Acesso
12 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.
Sem Acesso
13 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.
Sem Acesso
14 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.
Sem Acesso
15 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.
Sem Acesso
16 1995 SCIENCE DIRECT
RADER, J. A. CASE Adoption: A Process, Not an Event. Advances in Computers, v. 41, p. 83-156, 1995.
Sem Acesso
17 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.
Sem Acesso
18 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.
Sem Acesso
19 2006 ACM SHERIF, K.; ZMUD, R. W.; BROWNE, G. J. Managing peer-to-peer conflicts in
Sem Acesso
123
disruptive information technology innovations: the case of software reuse. Journal MIS Quarterly, v. 30, n. 2, p. 339-356, 2006.
20 2004 ACM WINSCHIERS, H.; PATERSON, B. Sustainable software development. Proceedings of SAICSIT’04, p. 274-278, 2004.
Incompleto
21 2006 ACM HARRISON, W.; WIERINGA, R. Introduction to the workshop on technology transfer in software engineering. Proceedings of TT’06, p. 1-2, 2006.
Incompleto
22 2006 ACM PUNTER, T.; KRIKHAAR, R. L.; BRIL, R. J. Sustainable Technology Transfer. Proceedings of TT’06, p. 15-18, 2006.
Incompleto
23 2006 ACM GIDS, M.; VOS, T. Tales about a small software testing bridge from academy to SMEs. Proceedings of SSEE’06, p. 17-20, 2006.
Incompleto
24 2007 ACM ANTONIOL, G. Requiem for software evolution research: a few steps toward the creative age. Proceedings of IWPSE’07, p. 1-3, 2007.
Incompleto
25 2008 ACM 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.
Incompleto
26 2011 ACM ZHANG, D. et al. Software analytics as a learning case in practice: approaches and experiences. Proceedings of MALETS’11, p. 55-58, 2011.
Incompleto
27 1990 IEEE FOWLER, P. J. Technology transfer as a collaboration: the receptor group. Proceedings of International Conference on Software Engineering, p. 332-333, 1990.
Incompleto
28 1994 IEEE CANNING, A. A. et al. Sharing ideas: the SEMSPLC Project. IEEE Review, p. 23-26, 1994.
Incompleto
29 1997 IEEE 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.
Incompleto
30 2012 IEEE SANTOS, G. et al. Strategic Alignment between Academy and Industry: A Virtuous Cycle to Promote Innovation in
Incompleto
124
Technology. Braziliam Symposium on Software Engineering, p. 196-200, 2012.
31 1997 SCIENCE DIRECT
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.
Incompleto
32 2005 ACM MATHIASSEN, L.; VOLGESANG, L. Managing knowledge in software method adoption. International Journal of Business Information Systems, v. 1, n. 1/2, p. 102-117, 2005.
Irrelevante
33 2006 ACM BASS, M. A survey of software related academic collaborations at siemens. Proceedings of TT’06, p. 55-58, 2006.
Irrelevante
34 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.
Irrelevante
35 2012 ACM CARTAXO, B. et al. ESEML: empirical software engineering modeling language. Proceedings of DSM’12, p. 55-60, 2012.
Irrelevante
36 1994 IEEE GRADY, R. B.; SLACK, T. V. Key Lessons in Achieving Widespread Inspection Use. IEEE Software, p. 46-57, 1994.
Irrelevante
37 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.
Irrelevante
38 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.
Irrelevante
39 2000 IEEE RUHE, G. Methodological Contributions to Professional Education and Training. COMPSAC’00, p. 11-16, 2000.
Irrelevante
40 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. 73-83, 2000.
Irrelevante
41 2005 IEEE SCHMID, K. et al. Introducing the puLSE approach to an embedded system
Irrelevante
125
population at testo AG. Proceedings of ICSE’05, p. 544-552, 2005.
42 2005 IEEE 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.
Irrelevante
43 2005 IEEE UMARJI, M.; EMURIAN, H. Acceptance Issues in Metrics Program Implementation. IEEE International Symposium Software Metrics, p. 10-20, 2005.
Irrelevante
44 2005 IEEE DYBA, T.; KITCHENHAM, B. A.; JORGENSEN, M. Evidence-based software engineering for practitioners. IEEE Software, v. 22, n. 1, p. 58-65, 2005.
Irrelevante
45 2007 IEEE 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.
Irrelevante
46 2010 IEEE ERDOGMUS, H. Déjà Vu: The Life of Software Engineering Ideas. IEEE Software, v. 27, n. 1, p. 2-5, 2010.
Irrelevante
47 2011 IEEE BELLAMY, R.; JOHN, B.; KOGAN, S. Deploying CogTool: integrating quantitative usability assessment into real-world software development. ICSE’11, p. 691-700, 2011.
Irrelevante
48 1986 SCIENCE DIRECT
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.
Irrelevante
49 1987 SCIENCE DIRECT
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.
Irrelevante
50 1991 SCIENCE DIRECT
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.
Irrelevante
51 1993 SCIENCE DIRECT
KOCH, G. R. Process assessment: the ‘BOOTSTRAP’ approach. Information and Software Technology, v. 35, n. 6-7, p. 387-403, 1993.
Irrelevante
52 1997 SCIENCE DIRECT
ZELKOWITZ, M.; CUTHILL, B. Application of an information technology model to software engineering environments.
Irrelevante
126
Journal of Systems and Software, v. 37. n. 1, p. 27-40, 1997.
53 1998 SCIENCE DIRECT
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.
Irrelevante
54 2000 SCIENCE DIRECT
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.
Irrelevante
55 2001 SCIENCE DIRECT
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.
Irrelevante
56 2002 SCIENCE DIRECT
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.
Irrelevante
57 2002 SCIENCE DIRECT
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.
Irrelevante
58 2003 SCIENCE DIRECT
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.
Irrelevante
59 2004 SCIENCE DIRECT
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.
Irrelevante
60 2008 SCIENCE DIRECT
STAPLES, M.; NIAZI, M. Systematic review of organizational motivations for adopting CMM-based SPI. Information and Software Technology, v. 50, n. 7-8, p. 605-620, 2008.
Irrelevante
61 2011 SCIENCE DIRECT
ROOIJ, S. W. Higher education sub-cultures and open source adoption. Computers & Education, v. 57, n. 1, p. 1171-1183, 2011.
Irrelevante
127
62 2011 SCIENCE DIRECT
AYALA, C. et al., 2011. Selection of third 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. 620-637, 2011.
Irrelevante
63 2012 SCIENCE DIRECT
SPINELLIS, D.; GIANNICAS, V. Organizational adoption of open source software. Journal of Systems and Software, v. 85, n. 3, p. 666-682, 2012.
Irrelevante
64 1982 TT ROLAND, R. J. A decision support system model for technology transfer. The Journal of Technology Transfer, v. 7, n. 1, p. 73-93, 1982.
Irrelevante
65 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.
Irrelevante
66 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.
Irrelevante
67 1999 ACM HEFNER, R. A Corporate Approach to Technology Transition. Proceedings of HICSS-32, volume: Track 7, 1999.
Duplicado. 1ª Fonte: IEEE
68 1988 SCIENCE DIRECT
BAYER, J.; MELONE, N. A critique of 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.
Duplicado. 1ª Fonte: IEEE
69 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.
Duplicado. 1ª Fonte: IEEE
70 2005 ACM UMARJI, M., EMURIAN H. Acceptance Issues in Metrics Program Implementation. IEEE International Symposium on Software Metrics, p. 10-20, 2005.
Duplicado. 1ª Fonte: IEEE
71 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. 257-273, 2012.
Duplicado. 1ª Fonte: SCIENCE DIRECT
128
72 2010 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.
Duplicado. 1ª Fonte: SCIENCE DIRECT
73 1995 ACM 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.
Duplicado. 1ª Fonte: IEEE
74 2009 ACM COLOSIMO, M. et al. Evaluating legacy system migration technologies through empirical studies. Information and Software Technology, v. 51, n. 2, p. 433-447, 2009.
Duplicado. 1ª Fonte: SCIENCE DIRECT
75 2000 ACM ROMBACH, D. Fraunhofer: the German model for applied research and technology transfer. Proceedings of the International Conference on Software Engineering, p. 531-537, 2000.
Duplicado. 1ª Fonte: IEEE
76 2000 ACM CURTIS, B. From MCC and CMM: technology transfers bright and dim. Proceedings of ICSE’00, p. 521-530, 2000.
Duplicado. 1ª Fonte: IEEE
77 2000 ACM COLYER, A. M. From research to reward: challenges in technology transfer. Proceedings of the International Conference on Software Engineering, p. 569-576, 2000.
Duplicado. 1ª Fonte: IEEE
78 2007 ACM 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.
Duplicado. 1ª Fonte: SCIENCE DIRECT
79 2006 ACM PRESSBURGER, T. et al. Infusing Software Engineering Technology into Practice at NASA. SMC-IT 2006, p. 9-100, 2006.
Duplicado. 1ª Fonte: IEEE
80 1999 ACM 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.
Duplicado. 1ª Fonte: IEEE
81 2005 ACM 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: IEEE
129
82 2012 ACM SPINELLIS, D.; GIANNIKAS, V. Organizational adoption of open source software. Journal of Systems and Software, v. 85, n. 3, p. 666-682, 2012.
Duplicado. 1ª Fonte: SCIENCE DIRECT
83 2007 ACM 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.
Duplicado. 1ª Fonte: IEEE
84 2006 ACM HINCHEY, M. G. et al. Software Assurance Research Infusion: The NASA Experience. Proceedings of ISoLa’06, p. 18-27, 2006.
Duplicado. 1ª Fonte: IEEE
85 2009 ACM 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.
Duplicado. 1ª Fonte: SCIENCE DIRECT
86 2012 ACM 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.
Duplicado. 1ª Fonte: IEEE
87 2006 ACM HARRISON, W. Technology Transfer and the Tech Broker. IEEE Software, v. 23, n. 5, p. 5-7, 2006.
Duplicado. 1ª Fonte: IEEE
88 2000 ACM 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.
Duplicado. 1ª Fonte: IEEE
89 2000 ACM 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.
Duplicado. 1ª Fonte: IEEE
90 1996 ACM MITCHELL, K. I. Technology transfer to and from the industrial sector. Proceedings of the International Conference on Software Engineering, p. 495-496, 1996.
Duplicado. 1ª Fonte: IEEE
91 2004 ACM 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: IEEE
130
92 2003 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.
Duplicado. 1ª Fonte: SCIENCE DIRECT
93 2013 ACM 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
131
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
132
Equipe
Nome Afiliação Papel
Ramon Nobrega Tenório CIn – Universidade Federal de Pernambuco
Autor e Revisor
Sérgio Castelo Branco Soares
CIn – Universidade Federal de Pernambuco
Revisor
Emanoel Francisco Sposito Barreiros
CIn – Universidade Federal de Pernambuco
Revisor
Helaine Solange Lins CIn – Universidade Federal de Pernambuco
Revisor
Adauto Trigueiro de Almeida Filho
CIn – Universidade Federal de Pernambuco
Revisor
Diogo Vinicius de Sousa Silva
CIn – Universidade Federal de Pernambuco
Revisor
133
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.
134
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 meta-
aná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
135
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.
136
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"
137
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
138
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;
139
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:
140
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:
141
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
142
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.