Estrategia Metodológica para la Elaboración de Síntesis Conceptuales en
Ingeniería de Software: una Aplicación al Caso del Constructo Teórico de
Práctica
Carlos Mario Zapata Jaramillo
Grupo de investigación en lenguajes computacionales
Universidad Nacional de Colombia—Sede Medellín
Medellín, Colombia
cmzapata@unal.edu.co
Resumen: La síntesis conceptual es el primer paso hacia una
definición unificada de un constructo teórico que tiene diversas
definiciones en un mismo contexto. Semat (Software
Engineering Method and Theory) propone la construcción
colectiva de una teoría general para la ingeniería de software.
El desarrollo de una teoría implica definir un vocabulario
común con constructos teóricos unificados. En ingeniería de
software, el constructo teórico de práctica se utiliza
universalmente y se define de manera diversa. Así, aunque hay
estudios sobre su definición, aún no existe una definición que
concilie las diferentes visiones. En este artículo se define una
estrategia metodológica para la elaboración de síntesis
conceptuales en ingeniería de software y su aplicación al caso
del constructo teórico de práctica. La estrategia facilita la
identificación, análisis y recopilación de la literatura más
relevante. De esta forma se garantiza que los resultados
obtenidos son fundamento válido para una definición del
constructo teórico de práctica que la comunidad de ingeniería
de software acepte y comparta. La estrategia metodológica
propone el uso de esquemas preconceptuales como mecanismo
para la extracción y la síntesis de información y se ejemplifica
con dos casos de estudio correspondientes al análisis de
artículos relevantes del área.
Palabras clave: Ingeniería de Software, Síntesis Conceptual,
Semat, Práctica de Software, Teoría.
I. INTRODUCCIÓN
Para construir una definición unificada de un constructo
teórico que tiene diversas definiciones en un mismo contexto
es necesario realizar la síntesis conceptual que permita
identificar elementos comunes sobre la manera como
diferentes propuestas lo caracterizan y lo definen.
La iniciativa de la Teoría y Método de la Ingeniería de
Software (Semat, por sus iniciales en inglés) busca redefinir
la disciplina a partir de los problemas críticos que la
comunidad identifica. Semat se enfoca en dos objetivos
principales: encontrar un núcleo de elementos ampliamente
aceptados que describan la esencia de la ingeniería de
software y definir una adecuada y ampliamente aceptada
base teórica para la disciplina [1].
Alexander Barón Salazar
Grupo de investigación Galeras .Net
Universidad de Nariño
San Juan de Pasto, Colombia
abaron_98@udenar.edu.co
Todo proceso para desarrollar una base teórica unificada
debe incluir un esfuerzo paralelo para lograr un consenso
sobre la terminología. Esta tarea es difícil para la ingeniería
de software, ya que hay una amplia gama de definiciones e
interpretaciones de los términos que comúnmente se usan en
la profesión [2]. En este sentido, Johnson y Ekstedt [3]
afirman que la ingeniería de software carece de un
vocabulario común para compartir conocimiento de manera
eficiente y proponen la definición de este vocabulario como
el primer paso hacia la construcción de una teoría general.
En ingeniería de software, práctica de software es un
constructo teórico común que se define de manera diversa
desde la particularidad de cada propuesta. Algunos enfoques
definen y caracterizan la práctica de software detalladamente
[1, 4, 5]; otros la definen desde contextos específicos [6]; en
otros casos no hay una definición explicita [7]. En general,
aún no se logra una definición que concilie las diferentes
visiones y que sirva como referente conceptual para la
construcción de una teoría general para la ingeniería de
software.
En este artículo se define una estrategia metodológica para
la elaboración de síntesis conceptuales en ingeniería de
software y su aplicación al caso del constructo teórico de
práctica. Esta estrategia facilita la identificación, análisis y
recopilación de la literatura más relevante. La estrategia
metodológica que se propone se basa en el proceso de
Revisión Sistemática de Literatura (RSL) de Kitchenham y
Charters [8].
Una RSL debe ser exhaustiva e imparcial, pues de lo
contrario es de poco valor científico; exhaustiva porque debe
incluir toda la literatura relevante; imparcial porque debe
incluir, tanto la literatura que respalda la hipótesis, como
aquella literatura que refuta la hipótesis [9]. De esta forma, la
estrategia metodológica que se propone, permite una síntesis
conceptual que garantiza resultados válidos como
fundamento para una definición del constructo teórico de
práctica, que la comunidad de ingeniería de software acepte
y comparta.
La estrategia metodológica propone el uso de esquemas
preconceptuales como mecanismo para la extracción y la
síntesis de información. Un esquema preconceptual es una
representación de un dominio específico. Los esquemas
preconceptuales permiten la representación de la
terminología de un dominio para facilitar su traducción a
esquemas conceptuales [10]. A fin de demostrar la validez de
la estrategia metodológica, se presentan los esquemas
preconceptuales de dos casos de estudio correspondientes al
análisis de artículos relevantes del área.
La estructura de este artículo es la siguiente: en la Sección
II se describe el marco teórico; en la Sección III se presenta
antecedentes de RSL en ingeniería de software y el proceso
de RSL de Kitchenham y Charters [8]; en la Sección IV se
describe la estrategia metodológica para la elaboración de
síntesis conceptuales en ingeniería de software y su
aplicación al caso del constructo teórico de práctica;
finalmente, en la Sección V se presentan las conclusiones y
el trabajo futuro.
II. MARCO TEORICO
A. Construcción de teorías
Existen muchas definiciones para el término teoría; sin
embargo, la mayoría de las teorías comparten cuatro
objetivos: (a) describir el fenómeno estudiado; (b) explicar
el cómo, por qué y cuándo del fenómeno; (c) predecir lo que
va a ocurrir a continuación; (d) prescribir cómo actuar con
base en las predicciones [11]. Una teoría integra cuatro
componentes: (a) constructos, conceptos básicos que
representan entidades observables o intangibles de un
dominio en particular; (b) Proposiciones que describen
como interactúan los constructos; (c) Explicaciones que
demuestran por qué es importante la aplicación de una teoría
y justifican las proposiciones para integrar constructos; (d)
Alcance que expresa condiciones, cómo, cuándo y dónde se
debe aplicar una teoría [12, 13].
B. Práctica de software
Es una aproximación repetible para realizar un propósito
específico. Una práctica provee una manera sistemática y
verificable de abordar un aspecto particular de un trabajo.
La práctica tiene un objetivo claro expresado en términos de
los resultados que permite su aplicación. Proporciona una
guía para ayudar y orientar a los profesionales en lo que se
debe hacer para lograr el objetivo, para asegurar que el
objetivo se entiende y para verificar que se logra [5].
C. Revisión sistemática de literatura
Tiene como objetivo resumir, compilar, criticar y
sintetizar la investigación existente sobre un área temática o
fenómeno de interés. La RSL es una contribución al
conocimiento actual, ya que sus hallazgos se obtienen
cuando la literatura más relevante se analiza como un todo y
no como la lectura de documentos aislados. La RSL puede
clarificar el estado de la cuestión, identificar tendencias de
investigación, dar soporte para nuevas investigaciones y
establecer la importancia de un problema de investigación
[14].
D. Esquema preconceptual
Es una representación de un dominio específico y emplea
una simbología que los conocedores de ese dominio pueden
validar. Los esquemas preconceptuales permiten la
representación de la terminología de un dominio para
facilitar su traducción a esquemas conceptuales. Los
esquemas preconceptuales utilizan una notación basada en
la notación de los grafos conceptuales, con símbolos
adicionales que representan propiedades dinámicas. Un
esquema preconceptual es un dígrafo etiquetado, sin bucles
y múltiples arcos, conformado con nodos que se conectan
con arcos [10]. La sintaxis básica de los esquemas
preconceptuales se muestra en la Fig. 1.
Figura 1. Sintaxis básica de los esquemas preconceptuales [10]
III. RSL EN INGENIERÍA DE SOFTWARE
A. Algunos trabajos de RSL
En ingeniería de software existen varios estudios sobre
RSL. Lenberg et al. [15] presentan una RSL sobre el
comportamiento humano en la ingeniería de software. El
principal objetivo de este estudio es mostrar el interés de la
comunidad científica en los aspectos humanos de la
ingeniería de software y crear una plataforma común para
futuras investigaciones en el área. Los autores proponen una
definición de comportamiento en ingeniería de software y
presentan los resultados de una RSL basada en esta
definición. Existen otros trabajos que evidencian la
creciente aplicación de la RSL en ingeniería de software
[16, 17, 18, 19].
B. La propuesta de Kitchenham y Charters [8]
La estrategia metodológica para la elaboración de
síntesis conceptuales que se propone en este artículo se
fundamenta en una guía para la realización de RSL en
ingeniería de software [8]. Esta guía presenta un conjunto de
lecciones sobre la aplicación del proceso de revisión
sistemática de la literatura dentro del dominio de la
ingeniería de software [20, 21] y los resultados de una RSL
que tiene como objetivo identificar, evaluar y sintetizar las
investigaciones publicadas sobre experiencias de revisiones 2) Contratación de la revisión
sistemáticas y las propuestas para mejorar el proceso [9]. De En ocasiones, una organización requiere información
acuerdo con Kitchenham y Charters [8], una revisión sobre un tema específico, pero no tiene el tiempo o la
sistemática de literatura involucra varias actividades experticia para realizar una RSL. En estos casos, la
discretas que se pueden agrupar en tres fases: planeación, organización contrata los servicios de investigadores para
realización de la revisión y reporte de la revisión. El proceso que realicen el estudio. En tal sentido, es necesario que
para la realización de RSL se ilustra en la Fig. 2. representantes de la organización y los investigadores
definan los requisitos de la RSL [8]. La síntesis conceptual
IV. ESTRATEGIA METODOLÓGICA del constructo de práctica de software es insumo para el
El proceso de RSL de Kitchenham y Charters [8] es el desarrollo de futuras investigaciones y especialmente para la
fundamento para la estrategia metodológica para la construcción de una definición unificada. Los investigadores
elaboración de síntesis conceptuales. A continuación se interesados cuentan con la experticia requerida para realizar
definen las fases y actividades de la estrategia metodológica el estudio. Por lo tanto, no es necesario contratar el
y se aplican al caso del constructo teórico de práctica en el desarrollo de la síntesis conceptual.
contexto de la ingeniería de software. 3) Especificación de las preguntas de investigación
La formulación de las preguntas de investigación es la
parte más importante del proceso de revisión sistemática.
Las preguntas guían las actividades de búsqueda de los
Planeación Realización Reporte
estudios primarios, extracción y síntesis de la información
necesaria para responder las preguntas [8]. La pregunta de
investigación en esta síntesis conceptual es: ¿De qué manera
las propuestas de ingeniería de software definen el
Identificación de Identificación de la Especificación constructo teórico de práctica?
necesidades investigación mecanismos de difusión 4) Desarrollo del protocolo
Durante el desarrollo del protocolo, los investigadores
Contratación de la Selección de especifican los métodos que se utilizarán para llevar a cabo
revisión Realización del reporte
estudios primarios una RSL. El protocolo debe especificar métodos que
garanticen una RSL exhaustiva e imparcial [8]. Los
Especificación de Evaluación de la métodos de la estrategia para la elaboración de síntesis
las preguntas Evaluación del reporte
calidad del estudio conceptuales se definen y aplican a medida que realiza el
proceso de RSL, como se puede observar en los apartados
Desarrollo del Extracción de siguientes.
protocolo información 5) Evaluación del protocolo
El protocolo es un elemento crítico de cualquier revisión
Evaluación del Síntesis de sistemática. Los investigadores deben acordar un
protcolo información procedimiento para evaluar el protocolo [8]. Para el
desarrollo de síntesis conceptuales en ingeniería de
Figura 2. Proceso de la revisión sistemática de literatura [8]. software, la estrategia propone la aplicación del protocolo a
una muestra de artículos relevantes. En el caso del
A. Planeación constructo teórico de práctica en ingeniería de software, el
1) Identificación de las necesidades de la síntesis protocolo se aplicó a las propuestas Kuali Beh [5] y CMMI-
conceptual DEV [22]. Este ejercicio permite ajustar el protocolo para su
La necesidad de una revisión sistemática de literatura posterior aplicación al universo de los estudios relevantes.
surge de la exigencia de los investigadores para resumir toda B. Realización
la información existente sobre algún fenómeno de manera
exhaustiva e imparcial [8]. La justificación de la síntesis 1) Identificación de la investigación.
conceptual del constructo teórico de práctica en ingeniería A fin de encontrar el mayor número de estudios primarios
de software es la siguiente: la síntesis conceptual tiene como relacionados con las preguntas de investigación, se requiere
objetivo identificar aspectos comunes de la definición del definir una estrategia de búsqueda exhaustiva e imparcial
constructo teórico de práctica en el contexto de la ingeniería [8]. Para la identificación de la investigación, la estrategia
de software. Los resultados serán el insumo para la metodológica plantea la especificación de cadenas de
caracterización del constructo teórico y para la formulación búsqueda. Las cadenas de búsqueda son configuraciones
de una definición unificada. Esta definición es un aporte al que describen las preguntas de investigación. Estas cadenas
logro de uno de los objetivos de la iniciativa Semat: definir son los criterios ingresados en los motores de búsqueda de
una adecuada y ampliamente aceptada base teórica para la las fuentes digitales. Las cadenas de búsqueda definidas en
ingeniería de software.
el caso de la síntesis conceptual del constructo teórico de
práctica se muestran en la Fig. 3.
2) Selección de estudios primarios
El objetivo de esta actividad es seleccionar los estudios
realmente relevantes que aporten a dar respuesta a las
preguntas de investigación. [8].
Cadena 1: “Software practice” or “software development
practice” or “Software engineering practice”
Cadena 2: “Software method” or “software development
method” or “Software engineering method”
Cadena 3 “Software Theory” or “software development
theory” or “Software engineering theory”
Figura 3. Cadenas de búsqueda
a) Identificación de las fuentes de estudios
En este punto se determinan las fuentes donde se puede
encontrar la literatura especializada en el tema de
investigación. Actualmente, las fuentes digitales se usan
frecuentemente como repositorios de estudios relevantes.
También es importante incluir aquellos estudios que aunque
no se reportan en las fuentes digitales, la comunidad los
reconoce [8]. La búsqueda de la literatura sobre el
constructo teórico de práctica en ingeniería de software se
realiza utilizando fuentes digitales, tales como: ACM Digital
Library [23], EBSCO [24], Engineering Village [25], IEEE
Xplore Digital Library [26], ScienceDirect [27], Scopus
[28] y Web of science [29]. Igualmente, se integran estudios
que reconoce la comunidad de la ingeniería de software y
que no se reportan las fuentes digitales. Los resultados de
este ejercicio se muestran en la Tabla 1.
TABLA I. Resultados de la búsqueda en fuentes digitales
b) Selección de estudios
El uso de las cadenas de búsqueda en las fuentes digitales
reporta algunos estudios que se deben evaluar con base en
su relevancia real. Los criterios de selección se utilizan para
identificar los estudios que proporcionan evidencia directa
sobre la pregunta de investigación. Los criterios de
selección se definen de acuerdo con la pregunta de
investigación [8]. La estrategia metodológica para síntesis
conceptuales plantea el uso de criterios de inclusión y
exclusión como lo proponen Kitchenham y Charters [8].
Los criterios de inclusión permiten identificar literatura
relevante para el estudio. Para el caso de la síntesis
conceptual del constructo teórico de práctica, los criterios de
inclusión son: estudios que se refieran a prácticas de
ingeniería de software, estudios que se refieran a métodos
de ingeniería de software y estudios que se refieran a teorías
para ingeniería de software. Los criterios de exclusión
permiten identificar literatura que no aporta al estudio y que
se debe omitir. Los criterios de exclusión utilizados en la
síntesis conceptual del constructo teórico de práctica son:
estudios que se refieran a prácticas de enseñanza, estudios
que se refieran a métodos de enseñanza y estudios que se
refieran a teorías de disciplinas diferentes a la ingeniería de
software.
Este proceso se realiza en dos iteraciones. En una primera
iteración se toma en cuenta el título del estudio;
posteriormente, se toma en cuenta el resumen y las palabras
clave. Los resultados de aplicar los criterios de inclusión y
exclusión se muestran en la Tabla II.
TABLA II. Resultados de la aplicación de los criterios inclusión/exclusión
3) Evaluación de la calidad del estudio
Además de los criterios generales de inclusión y de
exclusión, se pueden considerar criterios adicionales para
evaluar la calidad de los estudios primarios [8]. La
estrategia metodológica plantea que, durante las actividades
siguientes de extracción y de síntesis de información, los
investigadores adquieren una visión más detallada del
estudio que les permite determinar la inclusión o exclusión
definitiva de la síntesis conceptual. En el caso del constructo
teórico de práctica, este criterio se aplica como un filtro
adicional para evitar el sesgo y garantizar la inclusión de
estudios realmente relevantes.
4) Extracción de información
 El objetivo de esta fase es el diseño de formularios de
extracción de datos para registrar con precisión la
información que los investigadores obtienen a partir de los
estudios seleccionados [8].
En la estrategia metodológica que se propone, cada uno
de los estudios relevantes se somete a un proceso de
análisis. Los productos del análisis del estudio son: la
unificación terminológica y el esquema preconceptual. La
unificación terminológica se refiere a integrar los términos
Figura 4. Formato de análisis documental de la propuesta Kuali-Beh [5]
que se refieren al mismo concepto en un término común. El
esquema preconceptual sintetiza la manera como el estudio
define el constructo teórico de práctica de software.
Ejemplos de los formatos de análisis documental con
algunos elementos de la unificación terminológica, se
presentan en las Fig. 4 y Fig. 5. Los correspondientes
esquemas preconceptuales que resultan de la extracción de
información se presentan en las Fig. 6 y Fig. 7.
Figura 5. Formato de análisis documental de la propuesta CMMI [22]
Figura 6. Esquema preconceptual resultado de la extracción de información dela propuesta Kuali-Beh [5]

Figura 7. Esquema preconceptual resultado de la extracción de información dela propuesta CMMI [22]
 5) Síntesis de información síntesis conceptual del constructo teórico de práctica es
Esta fase consiste en integrar y resumir los resultados de parte de un proyecto de investigación de tesis doctoral. Por
los estudios relevantes. La síntesis puede ser descriptiva y lo tanto, se somete a la rigurosa evaluación de la comunidad
complementada con un resumen cuantitativo [8]. En la de la ingeniería de software, tanto en el proceso académico
estrategia metodológica, los insumos son los formatos de de la investigación como en los escenarios donde se
análisis documental de los estudios relevantes. A partir de presente los resultados de la síntesis conceptual.
estos insumos se consolida la unificación terminológica y se
realiza el esquema preconceptual que describe una versión
preliminar de la definición unificada del constructo teórico
de práctica de software. El formato de síntesis de
información integrando las propuestas Kuali Beh [5] y
CMMI-DEV [22], se muestra en la Fig. 8. El estudio de
varias propuestas incluidas en la síntesis conceptual permite
definir una versión preliminar de la definición del
constructo teórico. Esta versión preliminar integra cuatro
vistas: vista estática, vista operacional, vista humana y vista
de gestión. En la Fig. 9 se muestra la vista general y, a
manera de ejemplo, en la Fig. 10 se muestra la vista estática.
C. Reporte
La fase final de una revisión sistemática consiste en la
redacción de los resultados de la revisión y la difusión de los
resultados a la comunidad interesada [8].
1) Especificación de mecanismos de difusión
Es importante difundir los resultados de una revisión
sistemática de manera efectiva. Por esta razón la mayoría de
las guías recomiendan la planificación de la estrategia de
difusión [8]. La estrategia metodológica sugiere especificar
mecanismos de difusión de acuerdo con la particularidad de
la síntesis conceptual. En este caso, el reporte de la síntesis
conceptual se realiza a manera de informe técnico de
investigación y como una sección de una Tesis Doctoral. La
difusión se realiza por medio de la presentación de artículos
y ponencias en publicaciones y eventos académicos de
ingeniería de software.
2) Formato del reporte
Normalmente, los mecanismos de difusión especificados
determinan el formato del reporte y la extensión; sin
embargo, existen recomendaciones sobre la estructura y
extensión del reporte para garantizar eficiencia de
comunicación con la comunidad interesada [8]. La
estrategia metodológica sugiere utilizar algunos formatos de
la guía [8] y los establecidos en las publicaciones y en los
eventos académicos en los cuales se presente los resultados
de la síntesis conceptual.
3) Evaluación del reporte
La evaluación del reporte se realiza de acuerdo con el
mecanismo de difusión. Cuando se presenta a una
publicación o a un evento, los comités científicos y la
comunidad objetivo son los encargados de evaluar el rigor y
la validez de la RSL. Cuando hace parte de una tesis
doctoral, la RSL se evalúa en el marco del proceso de
evaluación del proyecto de investigación [8]. La estrategia
metodológica se acoge a someter la síntesis conceptual a la Figura 8. Formato de unificación terminológica integrando las propuestas
evaluación de expertos por medio de la postulación a Kuali Beh [5] y CMMI-DEV [22].
publicaciones y eventos de ingeniería de software [8]. La

Figura 9. Versión preliminar de la vista general de la definición del
constructo teórico de práctica.
Figura 10. Versión preliminar de la vista general de la definición del
constructo teórico de práctica.
V. CONCLUSIONES Y TRABAJO FUTURO
En este artículo se puso a consideración de la comunidad
académica una estrategia metodológica para la elaboración
de síntesis conceptuales en ingeniería de software. La
estrategia metodológica se validó mediante su aplicación al
caso del constructo teórico de práctica. La propuesta de
Kitchenham y Charters [8] para la elaboración de RSL se
puede utilizar como guía para definir la estrategia
metodológica, ya que provee el proceso y los métodos
adecuados para realizar síntesis conceptuales. El ejercicio
permitió evidenciar las bondades de escalabilidad,
flexibilidad y adaptación de la propuesta de Kitchenham y
Charters [8], además de la incorporación de los esquemas
preconceptuales para realizar la síntesis y dirigir la
unificación terminológica. La aplicación de la estrategia
metodológica al caso del constructo teórico de práctica
facilitó la identificación, análisis y recopilación de la
literatura más relevante sobre el tema. La rigurosidad de
aplicación de la estrategia metodológica en el caso del
constructo teórico de práctica permite garantizar que los
resultados obtenidos son fundamento válido para una
definición que la comunidad de ingeniería de software
acepte y comparta. Por otro lado, los esquemas
preconceptuales son un mecanismo eficiente para la
extracción y síntesis de información a partir de los estudios
identificados como relevantes, debido a la facilidad que
ofrecen para representar la terminología de un dominio.
Como mecanismo de retroalimentación y mejora de la
estrategia metodológica, los autores proponen su aplicación
en la elaboración de síntesis conceptuales tanto en
ingeniería de software como en otras áreas. Igualmente, se
proyecta el uso de los resultados de la síntesis conceptual
del constructo teórico de práctica en las etapas siguientes del
proceso para construir una definición unificada.
REFERENCIAS
[1] I. Jacobson, Pan-Wei Ng, P. E. McMahon, I. Spence, and S. Lidman,
“The Essence of Software Engineering: The SEMAT Kernel,”
Commun. ACM, vol. 55, no. 12, pp. 42–49, Dec. 2012.
[2] B. C. E. Cengiz Erbas, “Modules and transactions: Building blocks for
a theory of software engineering,” Sci. Comput. Program., vol. 101,
pp. 6-20, Ap. 2015.
[3] P. Johnson and M. Ekstedt, “In search of a unified theory of software
engineering,” in International Conference on Software Engineering
Advances ICSEA 2007, Cap Esterel, France, 2007, pp. 1–1.
[4] D. Kirk and E. Tempero, “A lightweight framework for describing
software practices,” J. Syst. Softw., vol. 85, no. 3, pp. 582–595, Mar.
2012.
[5] Object Management Group, “Kernel and Language for Software
Engineering Methods (Essence)-Version 1.0,” Object Manag. Group,
Feb, 2012.
[6] C. Passos, D. S. Cruzes, T. Dyba, and M. Mendonca, “Challenges of
applying ethnography to study software practices.,” in Proceedings of
the 2012 ACM-IEEE International Symposium on Empirical Software
Engineering & Measurement, Ipswich, Massachusetts, 2012, p. 9.
[7] B. Rolandsson, M. Bergquist, and J. Ljungberg, “Open Source in the
Firm: Opening Up Professional Practices of Software Development,”
Res. Policy, Göteborg, Sweden, vol. 40, no. 4, pp. 576–587, May 2011.
[8] B. Kitchenham and S. Charters, “Guidelines for performing systematic
literature reviews in software engineering,” EBSE., Durham, UK, Tec.
Rep, EBSE-2007-01, Jul. 2007.
[9] B. Kitchenham and P. Brereton, “A systematic review of systematic
review process research in software engineering,” Inf. Softw. Technol.,
vol. 55, no. 12, pp. 2049–2075, Dec. 2013.
[10] C. Zapata, A. Gelbukh, and F. Isaza, “Pre-conceptual schema: A
conceptual-graph-like knowledge representation for requirements
elicitation,” MICAI 2006 Adv. Artif. Intell, vol 4293, Apizaco, Mexico,
pp. 27–37, 2006.
[11] S. Gregor, “The Nature of Theory in Information Systems,” MIS Q.,
Mn, USA, vol. 30, no. 3, pp. 611–642, 2006.
[12] R. Dubin, Theory building, 2ª ed. New York: Free Press, 1978.
[13] D. A. Whetten, “What Constitutes a Theoretical Contribution?,” Acad.
Manage. Rev., vol. 14, no. 4, pp. 490–495, Oct. 1989.
[14] G. W. Suter, “Review papers are important and worth writing: Review
papers are important,” Environ. Toxicol. Chem., vol. 32, no. 9, pp.
1929–1930, Sep. 2013.
[15] P. Lenberg, R. Feldt, and L. G. Wallgren, “Behavioral software
engineering: A definition and systematic literature review,” J. Syst.
Softw., vol. 107, pp. 15–37, Sep. 2015.
[16] F. Selleri Silva, F. Soares, A. L. Peres, I. M. de Azevedo,
A.Vasconcelos, F. K. Kamei, and S. R. de L. Meira, “Using CMMI
together with agile software development: A systematic review,” Inf.
Softw. Technol., vol. 58, pp. 20–43, Feb. 2015.
[17] M. Zarour, A. Abran, J.-M. Desharnais, and A. Alarifi, “An
investigation into the best practices for the successful design and
implementation of lightweight software process assessment methods:
A systematic literature review,” J. Syst. Softw., vol. 101, pp. 180–192,
Mar. 2015.
[18] H. Zhang and M. Ali Babar, “Systematic reviews in software
engineering: An empirical investigation,” Inf. Softw. Technol., vol. 55,
no. 7, pp. 1341–1354, Jul. 2013.
[19] D. Heaton and J. C. Carver, “Claims about the use of software
engineering practices in science: A systematic literature review,” Inf.
Softw. Technol., vol. 67, pp. 207–219, Nov. 2015.
[20] P. Brereton, B. A. Kitchenham, D. Budgen, M. Turner, and M. Khalil,
“Lessons from applying the systematic literature review process within
the software engineering domain,” J. Syst. Softw., vol. 80, no. 4, pp.
571–583, Apr. 2007
[21] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey,
and S. Linkman, “Systematic literature reviews in software
engineering – A systematic literature review,” Inf. Softw. Technol., vol.
51, no. 1, pp. 7–15, Jan. 2009.
[22] Carnegie Mellon University, “CMMI® for Development, Version
1.3,” Nov 2010.
[23] ACM Digital Library. (2015, Jun), [Online]. Available: http://dl.acm.org/
[24] EBSCO, http://eds.a.ebscohost.com.
[25] Engineering Village. (2015, Jun), [Online]. Available:
https://www.engineeringvillage.com/
[26] IEEE Xplore Digital Library, (2015, Jun). [Online]. Available:
http://ieeexplore.ieee.org/Xplore/home.jsp
[27] ScienceDirect, (2015, Jun). [Online]. Available:
http://www.sciencedirect.com/
[28] Scopus, (2015, Jun). [Online]. Available: http://www-scopus-com.
[29] Web of science, (2015, Jun). [Online]. Available:
http://thomsonreuters.com/en/products-services/scholarly-scientific-
research/scholarly-search-and-discovery/web-of-science.html