Vea discusiones, estadísticas y perfiles de autores para esta publicación en: https://www.researchgate.

net/publication/308857081

¿Qué es DevOps ?: Un estudio de mapeo sistemático sobre de fi niciones y prácticas

Documento de sesión · Mayo de 2016

DOI: 10.1145 / 2962695.2962707

CITACIONES LEE

109 8.520

4 autores , incluso:

Ramtin Jabbari Nauman Bin Ali

Instituto de Tecnología Blekinge Instituto de Tecnología Blekinge

3 PUBLICACIONES 121 CITACIONES 33 PUBLICACIONES 601 CITACIONES

VER EL PERFIL VER EL PERFIL

Binish Tanveer

11 PUBLICACIONES 194 CITACIONES

VER EL PERFIL

Algunos de los autores de esta publicación también están trabajando en estos proyectos relacionados:

HyEEASe Ver Proyecto

SERP conectar Ver Proyecto

Todo el contenido que sigue a esta página fue subido por Ramtin Jabbari el 09 de marzo de 2018.

El usuario ha solicitado una mejora del archivo descargado.

 ¿Qué es DevOps? Un estudio de mapeo sistemático sobre
Definiciones y prácticas
Ramtin Jabbari, Nauman bin Ali,
Kai Petersen
Instituto de Tecnología Blekinge
Karlskrona, Suecia
{rjb, nal, kps}@bth.se
RESUMEN
Contexto: DevOps, la combinación de Desarrollo y Operaciones, es una nueva forma
de pensar en el dominio de la ingeniería de software que recientemente recibió
mucha atención. Dado que DevOps es un término nuevo y un concepto novedoso
introducido recientemente, todavía no se ha logrado un entendimiento común de lo
que implica. En consecuencia, las definiciones de DevOps a menudo solo representan
una parte que es relevante para el concepto.
Objetivo: Este estudio tiene como objetivo caracterizar DevOps
explorando los componentes centrales de las definiciones de
DevOps reportadas en la literatura, especificando prácticas
propuestas explícitamente para DevOps e investigando las
similitudes y diferencias entre DevOps y otros métodos existentes
en ingeniería de software.
Método: Se realizó un estudio de mapeo sistemático que utilizó
seis bases de datos electrónicas: IEEE, ACM, Inspec, Scopus, Wiley
Online Library y Web of Science.
Resultado: Se han seleccionado 44 estudios que informan una
definición de DevOps, 15 estudios que declaran explícitamente las
prácticas de DevOps y 15 estudios que indican cómo DevOps se
relaciona con otros métodos existentes. En algunos casos, los artículos
indicaron una combinación de una definición, prácticas y relaciones con
otros métodos; el número total de estudios primarios fue de 49.
Conclusión: Propusimos una definición de DevOps que puede superar las
inconsistencias sobre las diversas definiciones existentes de estudios de
investigación individuales. Además, se han presentado las prácticas
propuestas explícitamente para DevOps, así como la relación con otros
métodos de desarrollo de software.
Conceptos de CCS
• Creación de software y su ingeniería → Creación y gestión de
software;
Palabras clave
Definición de DevOps; Práctica de DevOps; Método de desarrollo de
software
El permiso para hacer copias digitales o impresas de todo o parte de este trabajo para uso personal o
en el salón de clases se otorga sin cargo siempre que las copias no se hagan o distribuyan con fines
lucrativos o comerciales y que las copias lleven este aviso y la cita completa en el primera página. Se
deben respetar los derechos de autor de los componentes de este trabajo que son propiedad de
terceros distintos de ACM. Se permite resumir con crédito. Copiar de otra manera, o volver a publicar,
publicar en servidores o redistribuir a listas, requiere permiso específico previo y / o una tarifa. Solicite
permisos a permissions@acm.org.
Talleres XP '16, 24 de mayo de 2016, Edimburgo, Escocia, Reino Unido
©c 2016 ACM. ISBN 978-1-4503-4134-9 / 16/05. . . $ 15.00 DOI: http://dx.doi.org/10.1145/2962695.2962707
Binish Tanveer
Instituto Fraunhofer de software experimental
Ingeniería, IESE
Kaiserslautern, Alemania
binish.tanveer@iese.fraunhofer.de
1. INTRODUCCIÓN
Existe un interés considerable en "DevOps" por parte de los
profesionales. Numerosas consultorías ofrecen sus servicios para ayudar
a las organizaciones a adoptar y aprovechar los beneficios de DevOps.
Varias conferencias recientes y revisiones sistemáticas sobre el tema
sugieren que los investigadores de ingeniería de software también
tienen un gran interés en el tema.
La investigación en ingeniería de software a veces es criticada por
reempaquetar términos y conceptos existentes, lo que a menudo da como
resultado definiciones inconsistentes para el mismo concepto [45]. Por lo
tanto, el uso inconsistente de términos y, por lo tanto, de los conceptos
conduce a dificultades para encontrar investigaciones relevantes, ya que los
autores se refieren a la misma contribución conceptual con términos
totalmente diferentes [12, 52].
A menudo, las distinciones han obstaculizado en lugar de fomentar el
progreso y la colaboración en los campos. Por ejemplo, en varias áreas
de la ingeniería de software después de décadas de investigación,
hemos tenido un artículo que sugiere que nuestra investigación no es
tan diferente [3, 21].
Como DevOps es un tema reciente, no existe una definición
estándar para DevOps [48]. Por lo tanto, en este artículo intentamos
conceptualizar DevOps a través de las siguientes contribuciones:
• Analice y compare las definiciones de DevOps de la literatura
de investigación.
• Identificar y clasificar las prácticas asociadas con DevOps.
• Compare DevOps con otros métodos de desarrollo.
Seguimos un enfoque de estudio de mapeo sistemático [30, 47] para
lograr las contribuciones. La atención se centra en la literatura científica
y revisada por pares.
El resto del documento está estructurado de la siguiente manera: La
Sección 2 describe el trabajo relacionado. La sección 3 presenta el
método de investigación. A continuación, en la Sección 4 presentamos
los resultados, seguidos de discusiones y conclusiones en las Secciones 5
y 6, respectivamente.
2. TRABAJO RELACIONADO
En el trabajo relacionado, proporcionamos una descripción general de
los estudios secundarios, que revisan los estudios primarios sobre el
tema de DevOps, y detallan cómo estos se relacionan con nuestras
contribuciones para sintetizar / integrar la evidencia relacionada con el
tema.
Erich et al. [ 13, 15] realizó una literatura sistemática
revisar cómo la relación entre desarrollo y operaciones puede influir
en el desarrollo de los sistemas de información (SI). En particular,
intentaron identificar los conceptos principales de DevOps y los
desafíos que ocurren al usar
ellos en el desarrollo de SI, que estaban específicamente
Tabla 1: Cadenas de búsqueda, bases de datos utilizadas y
relacionados con el desarrollo y las operaciones. También
resultados de la búsqueda realizada el 4 de septiembre de 2015
investigaron cómo DevOps puede mitigar los desafíos identificados.
Además, mencionaron cultura, automatización, medición, Base de datos Cadena de búsqueda No.
de
intercambio, servicios, aseguramiento de la calidad, etc. como
documentos
conceptos para DevOps, pero los problemas relacionados con el IEEE ("DevoOps") 46
desarrollo de SI no han sido reportados. En su trabajo de ACM ("DevOps") y (Publicación 85
investigación, no encontraron pruebas sólidas en la literatura sobre lishedAs: diario O Pub-
cómo abordar los desafíos del uso de DevOps identificados en su lishedAs: procediendo)
estudio. Se ha destacado el potencial para una mayor investigación Inspec 1969-2016: (("DevOps") WN 41
Todos los campos)
sobre la relación entre DevOps y el desarrollo de SI. Erich et al. no
Scopus TITLE-ABS-KEY (“DevOps”) Y 51
consideró la definición de DevOps, la identificación de las prácticas
(LIMIT-TO (SRCTYPE, “p”) O LIMIT-TO
de DevOps y su relación con los otros métodos que han sido objeto (SRC- TYPE, “j”))
de nuestro estudio.
Smeds et al. [ 51] tenía como objetivo especificar el concepto de Wiley On- "DevOps" en todos los campos 7
DevOps y lo que los profesionales perciben como impedimentos biblioteca de línea

para adoptar DevOps. Definieron DevOps proponiendo tres
atributos principales, a saber, capacidades, cultura y tecnología. El
estudio no proporcionó una definición sintetizada a través de un
análisis sistemático de las definiciones existentes, que es una de las
contribuciones de nuestro estudio.
Además, complementamos el trabajo existente evaluando la
consistencia de las de fi niciones basadas en 49 estudios primarios.
Se ha utilizado un enfoque sistemático para derivar las definiciones.
Para investigar y comprender los impedimentos de adoptar
DevOps, Smeds et al. concluyó explícitamente que la definición de
DevOps aún necesita mucha atención por parte de los
investigadores.
Como contribuciones adicionales que complementan el trabajo
existente, también identificamos las prácticas asociadas con
DevOps, así como cómo los autores de los estudios incluidos en
nuestro estudio de mapeo comparan DevOps con otros enfoques
de desarrollo (como el desarrollo ágil de software).
3. MÉTODO DE INVESTIGACIÓN
Realizamos un estudio de mapeo sistemático [30, 47] para
comprender la siguiente pregunta: ¿Cómo se ha caracterizado
“DevOps” en la literatura de investigación? Formulamos tres
preguntas de investigación (RQ):
• PI1: ¿Cómo se define “DevOps” en la literatura revisada por
pares sobre el tema? El objetivo de esta pregunta de
investigación es lograr una comprensión alineada del
concepto de DevOps, ayudando a la comunicación entre
investigadores y profesionales al presentar resultados
relacionados con DevOps.
• RQ2. ¿Qué prácticas se asociaron con DevOps en la
literatura? Las metodologías ágiles específicas prescriben
prácticas a seguir, como Extreme Programming que propone
un conjunto de prácticas, por ejemplo, integración continua,
estándares de codificación, diseño simple, etc. Como DevOps
es un concepto relativamente nuevo, estamos investigando
qué prácticas los autores asocian con DevOps.
• RQ3. ¿Cuáles son las similitudes y diferencias informadas por
los autores de los estudios primarios entre “DevOps” y los
otros métodos de desarrollo? Para que DevOps se beneficie
de las lecciones aprendidas y las evidencias obtenidas
anteriormente, es interesante comparar y relacionar DevOps
con otros métodos de desarrollo.
3.1 Cadenas de búsqueda
La Tabla 1 muestra las cadenas de búsqueda, las bases de datos y el número de artículos
encontrados por base de datos. Como se muestra en la Tabla 1, la búsqueda
Web of Sci- TEMA :( “DevOps”) Periodo de tiempo: 8
ence Todos los años.
Total 238
Duplicados (detección automática) - 79
Duplicados (detección manual) -1
Eliminar procedimientos -
No revisado por pares - 10
23
Irrelevante -
No disponible en texto - 26
completo restante 117
conducido tiene como objetivo encontrar todos los artículos en los que
se ha mencionado DevOps. No limitamos la cadena de búsqueda a, por
ejemplo, definición, práctica, etc. de DevOps para evitar perder cualquier
artículo potencial que pudiera estar relacionado con DevOps. Para
aumentar la confianza en el proceso de búsqueda, el proceso se realizó
dos veces con un intervalo de una semana, lo que también se conoce
como procedimiento test-retest [35].
3.2 Criterios y proceso de selección
Para mejorar la confiabilidad del estudio, se tomaron varias medidas
[2] comenzando con la descripción de los criterios y el proceso de
selección del estudio. Se utilizaron criterios muy simples para evaluar la
relevancia de los artículos:
• Excluya cualquier artículo que no esté publicado en inglés.
• Excluya cualquier artículo que no haya sido revisado por pares.
• Excluir actas de conferencias (p. Ej., Mensajes de
presidente de consejos editoriales, etc.).
• Excluya cualquier artículo que no esté disponible en texto completo.
Para tener una comprensión confiable de los estudios y comprender
el papel de DevOps en particular, solo consideramos aquellos
estudios que están disponibles en texto completo. Para ello cabe
mencionar que solo incluimos los artículos que discuten
explícitamente “DevOps” para identificar cómo se define el término
en sí y qué prácticas están asociadas con el concepto DevOps, se
han excluido los estudios que no utilizan el término “DevOps”. Para
los artículos que no estaban disponibles en texto completo, se
contactó con el bibliotecario de la universidad y con los autores.
Podríamos obtener dos estudios más contactando al bibliotecario o
autor (es) que no estaban disponibles en texto completo. Siempre
existe el riesgo de que los criterios de selección se interpreten de
manera diferente. Por lo tanto, es importante involucrar a varias
personas en el proceso de selección. Para evitar sesgos individuales,
3.3 Extracción de datos
Para extraer datos, diseñamos el formulario de extracción de
datos como se ilustra en la Tabla 2 basado en los objetivos de este
estudio [30], que fueron respectivamente; definir DevOps,
identificar aquellas prácticas que se han propuesto explícitamente
en el contexto de DevOps y explorar cualquier comparación y / o
reflejo de la relación con otros métodos.
El formulario de extracción de datos se ha evaluado mediante la
realización de un estudio piloto. Cinco artículos, entre los 117
finalmente seleccionados, fueron seleccionados al azar para evitar
sesgos. La evaluación se realizó en dos rondas. En la primera ronda,
los dos primeros autores extrajeron cinco estudios para evaluar el
formulario de extracción de datos. El formulario de extracción de
datos se mejoró según el piloto. Se realizó un segundo piloto con
los cuatro autores. Después de la construcción de consenso, los
estudios se distribuyeron entre los autores en función de las
contribuciones.
Después de la extracción de datos, se hizo evidente que muchos
estudios no eran relevantes porque no se centraban en las de fi
niciones, prácticas y relaciones de DevOps con otros métodos. Esto
no fue posible deducirlo solo del título y el resumen, razón por la
cual se leyó el texto completo de los 117 estudios. De estos, solo se
incluyeron 49 estudios. La Tabla 3 describe el número de estudios
utilizados en nuestro trabajo de investigación de acuerdo con cada
RQ específico.
ting publicado). Dado que el enfoque de este estudio está en la
definición de DevOps y no en, por ejemplo, los beneficios y las
limitaciones, el sesgo de publicación puede no jugar un papel
significativo para este estudio.
Generalizabilidad (capacidad de generalizar a diferentes contextos):
Este estudio se centra en un conjunto limitado de estudios, y es posible
que la definición de DevOps no sea estática, sino que evolucione con el
tiempo. Es decir, es posible que se agreguen nuevas prácticas y nuevos
componentes en estudios futuros. Esta es una amenaza para la validez,
aunque no está bajo el control de los investigadores durante el diseño y
la ejecución del estudio. Por lo tanto, nuestro estudio presenta una
definición agregada y un conjunto de prácticas que pueden ampliarse
aún más en función de la evolución del campo de investigación.
Objetividad (capacidad para describir objetivamente las observaciones):
Es posible que haya múltiples sesgos durante la búsqueda, la selección de
estudios, la extracción de datos y el análisis. Para reducir los sesgos, varios
investigadores han participado en todos los pasos del estudio. Por ejemplo,
utilizamos dos investigadores durante la selección del estudio, realizamos una
prueba piloto de extracción de datos y revisamos el análisis de datos. También
existe el riesgo de que se pierdan estudios relevantes en la búsqueda. Para
evitar esto, seguimos la recomendación de Kitchenham y Brereton de incluir
bases de datos de editores y bases de datos indexadas en nuestros
procedimientos de búsqueda [34]. Además, se ha utilizado una
prueba-reprueba para reducir el riesgo de errores

3.4 Análisis
Para la definición, investigamos los estudios que han utilizado
explícitamente el término DevOps, y luego propusimos una
definición para eso (ver sección 4.1). Basándonos en la frecuencia de
repetición para definir DevOps en estos estudios seleccionados,
identificamos los componentes centrales para la definición de
DevOps. (ver Figura 1 y Tabla 4).
Para mostrar mejor los componentes centrales identificados de la
definición de DevOps, excluimos 'Desarrollo' y 'Operaciones' en la
Figura 1, como la definición más común de DevOps. La figura
muestra los términos identificados, lo que es un buen punto de
partida para el análisis. Sin embargo, no pone los términos en un
contexto. En consecuencia, utilizamos codificación abierta para
identificar los componentes de las de fi niciones.
Para las prácticas de DevOps, investigamos los estudios que
propusieron explícitamente actividades que se ejecutan en el
contexto de DevOps. Después de identificar estas prácticas, las
hemos categorizado de acuerdo con las áreas de conocimiento
fundamental y las áreas de subconocimiento correspondientes,
propuestas en el cuerpo de conocimiento de ingeniería de software
(Swebok), como un estándar internacional para proporcionar una
colección categorizada integral de los límites de la ingeniería de
software. [1] (ver Tabla 5). Las áreas de conocimiento de Swebok
también proporcionan una indicación de cuántas áreas cubre
DevOps. Las prácticas individuales se han identificado mediante
codificación abierta. A partir de entonces, se han asociado y
colocado en las áreas de conocimiento de Swebok.
Para investigar la relación entre DevOps y otros métodos
existentes, investigamos los artículos, en los que se ha realizado
una comparación, discusión o reflexión explícita entre DevOps y
otros métodos. Luego, categorizamos los datos de acuerdo con los
métodos especificados (ver Tabla 6).

3.5 Amenazas de validez

Validez teórica (factores de confusión, incapacidad para capturar lo
que pretendemos capturar :) Un factor de confusión común es el sesgo Figura 1: Wordcloud de términos comunes utilizados en las de fi
de publicación (es decir, principalmente los estudios positivos obtienen niciones de DevOps
 Tabla 2: Formulario de extracción de datos
Formulario de extracción de datos

ID de estudio
Nombre del revisor

¿De fi nición? (RQ1) Estados del autor; Por ejemplo, DevOps se define OR como OR ...

Practicas? (RQ2) Actividades que se proponen ejecutar en el contexto de DevOps.

Comparación / Discusión / Reflexión Si el artículo ha comparado y contrastado explícitamente DevOps con otras metodologías
de la relación con otras metodologías como Agile, Lean, VBSE, etc. (RQ3)

Nota adicional

¿Excluye el artículo basándose en Eg, ya que el artículo no trata sobre DevOps de forma explícita? tus
hallazgos?
Si / Incierto / No
si es así / incierto, ¿por qué?

Tabla 3: Número de estudios

Referencias # Ref DevOps DevOps Relación con
De fi Práctica otras metanfetaminas
nition (RQ2) ods (RQ3)
(RQ1)
[16, 25, 39, 48, 55, 62] [18, 6 sí sí sí

19, 23, 27, 41, 54] [5, 9, 10, 6 sí sí No

31, 40, 59, 65] 7 sí No sí

[6, 7, 8, 11, 14, 17, 24, 26, 29, 32, 33, 37, 38] [42, 43,
44, 46, 50, 53, 57, 58, 60, 61, 63, 64] 25 sí No No

[22, 28, 49] 3 No sí No

[4, 20] 2 No No sí

Número total de trabajos 49

toma en la búsqueda. En la literatura, intentamos identificar esas prácticas, que se han

Validez interpretativa (sacar las conclusiones correctas de los datos
proporcionados): Uno de los resultados clave de este estudio es la
definición de DevOps, que debe seguir y ser coherente con los datos
extraídos. Por lo tanto, múltiples investigadores han estado involucrados
en el análisis, las reflexiones y las conclusiones relacionadas con las
preguntas de investigación.
4. RESULTADOS
presentado explícitamente como prácticas de DevOps. Luego,
categorizamos las prácticas identificadas de acuerdo con la
categorización del área de conocimiento de ingeniería de software y
las subáreas de conocimiento correspondientes [1]. La Tabla 5
muestra las prácticas identificadas obtenidas de los estudios
correspondientes. La tabla muestra que las áreas de conocimiento
están cubiertas con respecto a las prácticas sugeridas en los
estudios primarios.

4.1 Definiciones de DevOps (RQ1)
Para explorar las definiciones de DevOps en la literatura,
intentamos identificar los componentes centrales para definir
DevOps explícitamente. La Tabla 4 muestra los componentes
identificados obtenidos de los estudios correspondientes.
4.2 Prácticas de DevOps (RQ2)
Explorar las prácticas propuestas como prácticas DevOps.
4.3 Relación con otros métodos (RQ3)
La relación de DevOps con los otros métodos de desarrollo de
software existentes se ha extraído de los estudios primarios. Las
relaciones se discutieron explícitamente en los documentos, lo que
permitió identificar las similitudes y diferencias entre DevOps y los
otros métodos. Las relaciones con otros métodos se muestran en la
Tabla 6. Las relaciones mencionadas explícitamente se destacaron
con la computación en nube ágil,
 Tabla 4: Componentes centrales de la definición de DevOps
Componente Definición de componente Referencias
C1: Desarrollar Se ha aclarado que el término “DevOps” ha sido acuñado por [5, 6, 7, 8, 9, 10, 11, 16, 17, 19, 23, 24, 26,
ment y Op- una combinación de Desarrollo y Operaciones (o 27, 29, 31, 32, 33, 37, 38, 39, 40, 41, 43, 44,
eraciones Desarrolladores y Operadores). 46, 48, 53, 54, 55, 56, 57, 59, 65]
C2: Comunicaciones DevOps se define como un paradigma o método o conjunto de [6, 7, 8, 11, 16, 24, 25, 27, 33, 41, 44, 57,
nicación principios y / o prácticas que permiten la comunicación y la 58, 64, 65]
Colaboración, colaboración, lo que resulta en un trabajo en equipo eficiente entre
Trabajo en equipo desarrolladores y operadores.
C3: Puente DevOps se define como un paradigma o método o conjunto de [7, 8, 9, 16, 25, 39, 46, 54, 55, 56, 57, 60,
el hueco principios y / o prácticas que cierra la brecha (como el objetivo 61, 63]
principal de DevOps) entre el desarrollo y las operaciones. Este
componente está en estrecha correlación con C2 en la literatura.

C4: Desarrollar DevOps se define como un método de desarrollo de software [10, 24, 26, 44, 48]
método de ment moderno para responder a las interdependencias entre el desarrollo
y las operaciones mediante la unificación de métodos y herramientas
modernos que dan como resultado una convergencia real entre
desarrolladores y operadores.
C5: software DevOps se define como un paradigma o conjunto de principios que [10, 11, 18, 27, 55, 65]
entrega se centran en la entrega de software al permitir una
retroalimentación continua, una respuesta rápida a los cambios y el
uso de canales de entrega automatizados que reducen el tiempo de
ciclo. Bayser et al. [ 10] han mencionado explícitamente que DevOps
nació para la entrega rápida de sistemas basados en web.
C6: Au- DevOps se define como un paradigma o conjunto de principios que [7, 29, 38, 61]
tomado permite automatizar el proceso de implementación desde el código
despliegue fuente en el control de versiones hasta el entorno de producción.
C7: Contin- Devops se define como una práctica que enfatiza las tareas que [18, 19, 26, 65]
uous integra- permiten la integración continua entre el desarrollo de software
ción y sus necesidades de implementación operativa.
C8: Calidad DevOps se define como un método que combina las preocupaciones [10, 43]
garantía de la garantía de calidad con las operaciones y las prácticas de
desarrollo para mejorar el rendimiento.

gestión de la nube, procesos de desarrollo (desarrollo en cascada),
ITIL y actividades de aseguramiento de la calidad.
4.3.1 Ágil
DevOps extiende Agile: DevOps se extiende ágil en términos de
los principios, ya que DevOps puede proporcionar una extensión
pragmática para las actividades ágiles actuales. Por ejemplo, como
DevOps enfatiza más en la comunicación y colaboración entre
desarrolladores y operadores que en herramientas y procesos,
puede lograr objetivos ágiles para reducir la latencia del trabajo en
equipo y extender los principios ágiles a todo el proceso de entrega
de software [16, 55].
Desarrollo y entrega ágil de aplicaciones web:
Bayser et al. [ 10] han mencionado brevemente que DevOps tiene
una relación particular con el desarrollo y la entrega ágiles de
aplicaciones web.
Ágil como habilitador de DevOps: Hosono [25] ha mencionado que los
métodos ágiles pueden considerarse habilitadores para adoptar el
pensamiento DevOps.
Agile admite DevOps: Agile puede respaldar DevOps fomentando la
colaboración entre los miembros del equipo, la automatización de la
construcción, implementación y prueba, medición y métricas de costos,
valor y procesos, intercambio de conocimientos y herramientas [5].
DevOps versus ágil: Terhi et al. [ 31] han mencionado que los
métodos ágiles para la integración e implementación continuas
tienen propiedades compartidas con DevOps, mientras que DevOps
en sí no puede cumplir con todos los principios propuestos en el
´szá́r et al. [ 9] di eso "Escalar DevOps para
manifiesto ágil. Csá
Las redes de operadores definidas por software son, en cierto sentido, como
escalar el desarrollo ágil a grandes proyectos en software multinacional.
empresas de cerámica ”, y finalmente Miglierina estados "DevOps
elimina la brecha entre desarrolladores y operadores, mientras que
ágil hace una alineación entre los requisitos comerciales y el
desarrollo" [ 40].
4.3.2 Computación en la nube
Computación en la nube: La computación en la nube puede
considerarse un facilitador de DevOps, en particular para lanzamientos
frecuentes, entrega e integración continuas, como ventajas competitivas
[4, 62].
Gestión de la nube basada en modelos: Wettinger et al.
[59] han realizado una comparación entre DevOps y la gestión de la
nube que menciona que la gestión de la nube basada en modelos
puede proporcionar un enfoque más completo para la gestión de
servicios, pero no puede reemplazar a DevOps, ya que proviene de
un entorno completamente diferente.
4.3.3 Cascada
En DevOps, el desarrollo y las operaciones fluyen juntos, que no se
ha proporcionado en Waterfall, como una metodología tradicional
basada en planes [48]. En otras palabras, Waterfall contradice DevOps
debido a los estándares y principios [14].
4.3.4 ITIL
Para definir ITIL (es decir, biblioteca de infraestructura de tecnología de la
información, un conjunto de prácticas para la gestión de servicios de TI que se
centra en alinear los servicios de TI con las necesidades de la empresa),
McCarthy et al. [ 39] ha mencionado explícitamente; al igual que DevOps, no es
un conjunto de estándares, sino un conjunto de prácticas que pueden
integrarse y organizarse de acuerdo con las necesidades de una organización
de TI.
 Tabla 5: Prácticas de DevOps
Conocimiento Subconocimiento del área Práctica de área Referencias
(KA) (Sub-KA)
Planificación continua [55]
Proyecto de software Bucle de retroalimentación entre desarrolladores y
Software Planificación operadores
Ingenieria Monitoreo continuo [55]
administración Monitoreo automatizado del desempeño durante la [23]
Proyecto de software prueba e integración continua Retroalimentación
Promulgación automatizada para modelos de desempeño y [54]
predicciones de desempeño
Monitoreo de aplicaciones [dieciséis]
Cuadros de mando automatizados [dieciséis]
Software Consideraciones prácticas Integración continua [16, 18, 19,
construcción 55]
Software Construcción Aplicación de prototipos [25]
Fundamentos
Planificación de implementación integrada [dieciséis]
Despliegue continuo [16, 55]
Despliegue automatizado [22, 62]
Lanzamiento de software Entrega continua [22, 62]
Administración y Configuraciones de aplicaciones cooperativas [41]
Entrega Aplicación de seguimiento y próximo desarrollo [25]
Software
configuración Gestión de la Aplicación de puesta en escena [25]
administración Proceso SCM Gestión de configuración integrada [dieciséis]

Configuración de software Gestión de cambios integrada [dieciséis]

Control Gestión del cambio [27]

Pruebas de software
Proceso de software
Calidad del software
Software
herramientas de ingenieria
y métodos
Software
requisitos
Diseño de software
Prueba continua [54, 55]
Técnicas de prueba Pruebas automatizadas [dieciséis]
Estandarización de procesos [48]
Definición de proceso Soporte de producción [dieciséis]
Consideraciones prácticas Uso de datos para guiar el control de calidad [48]
Infraestructura como código [49]
Modelado y simulación [41]
Ingeniería de software Mida las métricas de rendimiento [en CI, pruebas y [23]
Métodos operaciones]
Rendimiento continuo de la aplicación [54]
Práctica de elasticidad del modelo de evaluación [39]
Herramientas de software de la madurez de DevOps [28]
Requisitos de Software Definición de requisitos [25]
Fundamentos
Proceso de requisitos Participación de las partes interesadas [dieciséis]
Estructura del software y Diseñando arquitectura [25]
Arquitectura

4.3.5 Garantía de calidad
Roche [48] analiza la convergencia de la garantía de calidad y
DevOps.
5. DISCUSIÓN
Coherencia del uso de las definiciones de DevOps: Allí-
Los resultados de búsqueda de este estudio mostraron la necesidad de
una definición, ya que los estudios individuales no definen DevOps de
manera consistente. Como ejemplo, determinando el número de
artículos que definen todos los componentes más comunes C1, C2 y C3
(Tabla 4), es decir | C 1 ∩ C 2 ∩ C 3 | = 4, siendo los estudios [7, 8, 16, 57].
Curiosamente, ninguna de estas referencias definía ninguno de los
componentes restantes, a saber, C4 a C8. Esto muestra la necesidad de
proponer una definición que incorpore las diferentes visiones de lo que
significa DevOps.
Definición derivada: Con base en nuestra síntesis, considerando los componentes
identificados en la Tabla 4, definimos DevOps de la siguiente manera: “DevOps es
una metodología de desarrollo (C4) dirigida
para cerrar la brecha (C3) entre Desarrollo (Dev) y Operaciones (C1),
enfatizando la comunicación y la colaboración (C2), la integración
continua (C7), el aseguramiento de la calidad (C8) y la entrega (C5)
con implementación automatizada (C6) utilizando un conjunto de
prácticas de desarrollo ".
Las prácticas de desarrollo asociadas con DevOps en la literatura
se presentan en la Tabla 5.
Prácticas: DevOps versus Agile: En la Sección 4.3 presentamos
cómo los autores han comparado explícitamente DevOps con otros
métodos. Era visible que la computación en la nube jugó un papel
importante en DevOps para implementar continuamente soluciones
a los clientes, con respecto a los procesos de desarrollo, DevOps se
ha relacionado con el desarrollo ágil de software. Por tanto, es
interesante comparar las prácticas de la Tabla 5 con las prácticas de
desarrollo ágil de software, ya que esto facilita la reutilización de
conocimientos previos obtenidos en el campo del desarrollo ágil de
software. Para ello utilizamos el conjunto de prácticas identificadas
en Kurapati et al.
 Tabla 7: Comparación de prácticas de DevOps con prácticas ágiles (cf. Kurapati et al. [36])
Conocimiento Subconocimiento del área Prácticas de DevOps de área Prácticas ágiles [36]
(KA) (Sub-KA)
Planificación continua Reunión de planificación de Sprint,
Proyecto de software sprints e iteraciones, reunión de
Software Planificación revisión de sprints
Ingenieria Bucle de retroalimentación entre Trabajo en equipo,
administración desarrolladores y operadores comunicación
Monitoreo continuo Seguimiento del progreso, retro
reuniones de revisión de sprint,
Proyecto de software espectivas
Promulgación Automatizado actuación •
monitoreo durante la prueba e
integración continua
Retroalimentación automatizada •
para modelos de desempeño y
predicciones de desempeño
Monitoreo de aplicaciones •
Cuadros de mando automatizados •
Software Consideraciones prácticas Integración continua Integración continua, con-
construcción pruebas continuas
Software Construcción Aplicación de prototipos [25]
Fundamentos
Plan de implementación integrado •
ning
Despliegue continuo Lanzamientos cortos / pequeños

Lanzamiento de software Despliegue automatizado •

Administración y Entrega continua Configuración y cambio
Entrega administración, Continuo
integración, corto pequeño
Software
lanzamientos
configuración
Cooperativa solicitud Trabajar en equipos
administración
configuraciones
Aplicación de seguimiento y Lanzamientos cortos / pequeños
próximo desarrollo
Gestión de la Aplicación de puesta en escena Configuración y cambio
Proceso SCM administración
Integrado configuración Configuración y cambio
administración administración
Configuración de software Gestión de cambios integrada Configuración y cambio
Control ment administración
Gestión del cambio Configuración y cambio
administración
Prueba continua Prueba continua
Pruebas de software Técnicas de prueba Pruebas automatizadas Impulsado por pruebas desarrollo
(codificación / automatización de ejecu-
en el nivel de prueba unitaria)
Estandarización de procesos Estándares de codificación
Proceso de software Definición de proceso Soporte de producción •
Calidad del software Consideraciones prácticas Uso de datos para guiar el control de calidad •
Infraestructura como código •
Modelado y simulación •
Ingeniería de software Medir el desempeño alcanzado •
Software Métodos rics [en CI, Test & Ops] Período
herramientas de ingenieria de aplicación continuo •
y métodos formance
Evaluación de madurez de DevOps •
Herramientas de software modelo
Práctica de elasticidad •
Software Requisitos de Software Definición de requisitos Historias y características
requisitos Fundamentos
Proceso de requisitos Participación de las partes interesadas Cliente in situ, comunicación
catión, reunión de revisión de
sprint
Diseño de software Estructura del software y Diseñando arquitectura Diseño simple
Arquitectura

[36], mapeándolos a las prácticas en la Tabla 5. El mapeo de DevOps hecho por juicio experto del tercer autor, que tiene experiencias
y prácticas ágiles, que se muestra en la Tabla 7, ha particulares en el dominio, investigando a fondo
 PI1: ¿Cómo se define “DevOps” en la literatura revisada por pares
Tabla 6: En comparación con otros métodos
sobre el tema? Con respecto a RQ1, identificamos ocho
Método Relaciones especificadas por Reference los componentes de la definición que caracteriza a DevOps. El
autores del pri-
componente que se destacó con más frecuencia fue que el
estudios de maría
desarrollo y las operaciones aparecen juntos para acuñar el
DevOps amplía Agile [16, 55] término, en particular, ambos componentes son esenciales por
definición. Además, se destacaron la comunicación, la colaboración
Desarrollo ágil de aplicaciones [10]
y el trabajo en equipo, así como la reducción de la brecha entre Dev
web
y Ops. Además, DevOps es un método de desarrollo con énfasis en
Entrega ágil de aplicaciones web [10] la entrega de software, implementación automatizada, integración
Ágil continua y garantía de calidad. En síntesis, propusimos la siguiente
definición de DevOps: “DevOps es una metodología de desarrollo
Ágil como facilitador de DevOps [25] (C4) destinada a cerrar la brecha (C3) entre Desarrollo (Dev) y
Operaciones (C1), enfatizando la comunicación y la colaboración
Agile admite DevOps [5] (C2), la integración continua (C7), el aseguramiento de la calidad
(C8) y la entrega ( C5) con implementación automatizada (C6)
DevOps versus ágil [9, 31, 40] utilizando un conjunto de prácticas de desarrollo ". Aunque C7 y C8
solo se han mencionado en algunos estudios, decidimos usarlos en
la definición propuesta para DevOps, ya que especifican los
Comp en la nube. La computación en la nube como facilitador [4, 62]
objetivos centrales de la adopción de DevOps. La importancia de
una definición común se hizo evidente a partir de las diferencias de
Nube Gestión de la nube frente a [59] definiciones para los estudios individuales. Es decir, muy pocos
gestionar- DevOps estudios compartieron componentes de la definición.
ment
RQ2. ¿Qué prácticas se asociaron con DevOps en la literatura? Clasi
Cascada Cascada versus DevOps [48, 65] fi camos las prácticas de DevOps utilizando las áreas de
conocimiento y las áreas de subconocimiento de Swebok. Esto
proporcionó una idea de la cobertura de las prácticas asociadas con
ITIL ( En- similitud entre ITIL y [39]
formación DevOps DevOps en relación con la ingeniería de software en su conjunto. Al
Tecnología comparar las prácticas de DevOps con las de desarrollo ágil de
Infras- software, se compartieron muchas prácticas, mientras que varias
estructura prácticas eran específicas de DevOps, como automatizar el análisis
Biblioteca) de aplicaciones, es decir, monitorear continuamente el rendimiento
del sistema, presentar los resultados en cuadros de mando
automatizados,
Calidad Garantía de calidad y des- [48] vops
Garantía RQ3. ¿Cuáles son las similitudes y diferencias informadas por los
autores de los estudios primarios entre “DevOps” y los otros
métodos de desarrollo? Un subconjunto de estudios describió
explícitamente cómo DevOps se relaciona con otros métodos de
desarrollo. Las relaciones se identificaron con desarrollo ágil de
las actividades correspondientes relacionadas con un par de
software, computación y administración en la nube, ITIL y
prácticas mapeadas, por ejemplo, 'requisito de definición' (práctica
aseguramiento de la calidad. Con respecto a ágil, se de fi nieron
de DevOps) se ha mapeado a 'historias y características' (práctica
diferentes tipos de relaciones, como Devops se extiende ágil, y ágil
ágil), o 'configuración de aplicación cooperativa' mapeada a 'trabajo
soporta DevOps. Al observar las prácticas de DevOps y compararlas
en equipos', etc. Como es evidente, las prácticas en relación con la
con las prácticas comunes de desarrollo de software ágil, estos
planificación de proyectos de software, la gestión de versiones de
hallazgos fueron consistentes con RQ2.
software, la gestión de la configuración y las pruebas son similares
desde el punto de vista de los principios. Por ejemplo, tanto DevOps
En este estudio nos centramos en la investigación de cómo los
como ágil hacen hincapié en la integración, las pruebas y la entrega
artículos de investigación ven DevOps y qué de fi niciones, prácticas
continuas de software en funcionamiento. En particular, ágil
y relaciones con otros métodos se estudiaron. En el trabajo futuro,
enfatiza los lanzamientos pequeños y continuos. Lo que DevOps
para investigar la comprensibilidad y la usabilidad de los hallazgos,
agrega al desarrollo ágil de software es el énfasis en la
por ejemplo, la definición propuesta para DevOps, también se
automatización del análisis de aplicaciones, es decir, monitorear
deben considerar las perspectivas del profesional. Esto se puede
continuamente el desempeño del sistema, presentar los resultados
hacer, por ejemplo, a través de estudios de entrevistas y la
en cuadros de mando automatizados, etc. Además,
investigación de blogs escritos por líderes de opinión. También
observamos que se mencionaron prácticas, pero se presentaron
pocos detalles de cómo usarlas. Por lo tanto, el valor de las
diferentes prácticas (también prácticas ágiles) y sus combinaciones
6. CONCLUSIÓN para DevOps deben entenderse e investigarse en el futuro.

En este artículo presentamos un estudio de mapeo sistemático

que se centra en las de fi niciones y prácticas de DevOps y cómo se
colocan en relación con otros métodos de desarrollo. Se han
formulado tres preguntas de investigación.
7. REFERENCIAS
[1] A. Abran, JW Moore, P. Bourque, R. Dupuis y
L. Tripp. Guía del cuerpo de conocimientos de la ingeniería de
software: versión 2004. Sociedad de Informática IEEE, 1,
2004.
[2] NB Ali y K. Petersen. Evaluar estrategias para
Selección de estudios en estudios sistemáticos de literatura. En
Actas del 8vo Simposio Internacional ACM / IEEE sobre
Ingeniería y Medición de Software Empírico, ESEM '14,
2014.
[3] NB Ali, K. Petersen y C. Wohlin. Una sistemática
revisión de la literatura sobre el uso industrial de la simulación de
procesos de software. Revista de sistemas y software,
97: 65–85, 2014.
[4] P. Austel, H. Chen, TA Mikalsen, I. Rouvellou,
U. Sharma, I. Silva-Lepe y R. Subramanian. Entrega continua
de soluciones compuestas: un caso para entornos de paas
definidos por software colaborativo. En
Actas del segundo taller internacional sobre ecosistemas
definidos por software, BigSystem 2015, Portland,
Oregon, EE. UU., 16 de junio de 2015, páginas 3 a 6,
2015.
[5] SK Bang, S. Chung, Y. Choh y M. Dupuis. A
Análisis de teoría fundamentada de aplicaciones web modernas:
conocimientos, habilidades y habilidades para devops. En
Actas de la 2ª Conferencia Anual sobre Investigación en
Tecnología de la Información, RIIT '13, 2013.
[6] L. Bass, DR Je ff ery, H. Wada, I. Weber y L. Zhu.
Obtención de requisitos de operaciones para aplicaciones. En
Actas del 1er Taller Internacional sobre Ingeniería de
Liberaciones, RELENG 2013, San Francisco, California, EE.
UU., 20 de mayo de 2013, páginas 5–8, 2013.
[7] D. Bruneo, T. Fritz, S. Keidar-Barner, P. Leitner,
F. Longo, CC Marquezan, A. Metzger, K. Pohl,
A. Pulia fi to, D. Raz, A. Roth, E. Salant, I. Segall,
M. Villari, Y. Wolfsthal y C. Woods. Cloudwave: donde la
gestión adaptativa de la nube se encuentra con devops. En
Simposio IEEE sobre Computadoras y
Comunicaciones, ISCC 2014, Funchal, Madeira, Portugal,
23-26 de junio de 2014, páginas 1 a 6, 2014.
[8] CA Cois, J. Yankel y A. Connell. DevOps moderno:
Optimización del desarrollo de software a través de interacciones efectivas
del sistema. En 2014 IEEE International Professional Communication
Conference, IPCC 2014, Pittsburgh, PA, EE. UU., 13-15 de octubre de 2014, páginas
1–7,
2014.
[9] A. Csá ´szá́r, W. John, M. Kind, C. Meirosu,
G. Pongrá ´cz, D. Staessens, A. Taká ´cs, y
F. Westphal. Unificación de la nube y la red de operadores:
proyecto UNIFY del 7PM de la UE. En IEEE / ACM 6th
International Conference on Utility and Cloud Computing, UCC
2013, Dresde, Alemania, 9-12 de diciembre de 2013, páginas
452–457, 2013.
[10] M. de Bayser, LG Azevedo y RFG Cerqueira.
Investigaciones: el caso de devops en aplicaciones científicas.
En Simposio internacional IFIP / IEEE sobre gestión integrada
de redes, IM 2015, Ottawa, ON, Canadá, 11-15 de mayo de
2015, páginas 1398–1404,
2015.
[11] A. Dyck, R. Penners y H. Lichter. Hacia
de fi niciones para ingeniería de versiones y devops. En Tercero
Taller internacional IEEE / ACM sobre ingeniería de versiones,
RELENG 2015, Florencia, Italia, 19 de mayo de
2015, página 3, 2015.
[12] E. Engstr¨ öm y K. Petersen. Mapeo de la práctica de
pruebas de software con investigación de pruebas de
software taxonomía de pruebas de serp. En Octava
Conferencia Internacional IEEE sobre Pruebas, Verificación y
Validación de Software, Talleres de ICST 2015, Graz, Austria,
13-17 de abril de 2015, páginas 1–4, 2015.
[13] F. Erich, C. Amrit y M. Daneva. Cooperación
entre el desarrollo y las operaciones del sistema de
información: una revisión de la literatura. En Actas del 8vo
Simposio Internacional ACM / IEEE sobre Ingeniería y
Medición de Software Empírico,
página 69, 2014.
[14] F. Erich, C. Amrit y M. Daneva. Cooperación
entre el desarrollo y las operaciones del sistema de
información: una revisión de la literatura. En 2014 Simposio
internacional ACM-IEEE sobre ingeniería y medición de
software empírico, ESEM '14, Torino, Italia, 18-19 de
septiembre de 2014, página 69: 1, 2014.
[15] F. Erich, C. Amrit y M. Daneva. Un estudio de mapeo
sobre la cooperación entre el desarrollo y las operaciones del
sistema de información. En Mejora del proceso de software
centrado en el producto, páginas 277–280. 2014.
[16] B. Farroha y D. Farroha. Un marco para
gestionar las necesidades de la misión, el cumplimiento y la
confianza en el entorno de devops. En Conferencia de
Comunicaciones Militares (MILCOM), 2014 IEEE, 2014.
[17] DG Feitelson, E. Frachtenberg y KL Beck.
Desarrollo y despliegue en facebook. Computación por
Internet IEEE, 17 (4): 8-17, 2013.
[18] B. Fitzgerald y K. Stol. Software continuo
ingeniería y más allá: tendencias y desafíos. En 1er Taller
Internacional sobre Ingeniería de Software Continua Rápida,
RCoSE 2014, Hyderabad, India, 3 de junio de 2014, páginas 1 a
9, 2014.
[19] B. Fitzgerald y K.-J. Stol. Software continuo
ingeniería: una hoja de ruta y una agenda. Revista de
sistemas y software, 2015.
[20] G. Fox, J. Qiu, S. Kamburugamuve, S. Jha y
A. Luckow. La computación de alto rendimiento HPC-ABDS
mejoró la pila de big data de apache. En 15 ° Simposio
Internacional IEEE / ACM sobre Computación en Clústeres,
Nube y Grid, CCGrid 2015, Shenzhen, China, 4-7 de mayo,
2015, páginas 1057–1066, 2015.
[21] A. Fuggetta y E. Di Nitto. Proceso de software. En
Actas del sobre el futuro de la ingeniería de software,
páginas 1–12, 2014.
[22] K. Gohil, N. Alapati y S. Joglekar. Hacia
operaciones impulsadas por el comportamiento (bdops). En Advances
in Recent Technologies in Communication and Computing
(ARTCom 2011), 3a Conferencia Internacional sobre, 2011.
[23] W. Gottesheim. Desafíos, beneficios y mejores
prácticas de devops centradas en el rendimiento. En
Actas del 4 ° Taller internacional sobre pruebas a gran
escala, LT'15, Austin, TX, EE. UU., 1 de febrero de 2015, página
3, 2015.
[24] M. Guerriero, M. Ciavotta, GP Gibilisco y
D. Ardagna. Space4cloud: un entorno devops para
aplicaciones multinube. En Actas del 1er Taller Internacional
sobre DevOps consciente de la calidad, QUDOS 2015,
Bérgamo, Italia, 1 de septiembre de 2015,
 páginas 29-30, 2015.
[25] S. Hosono. Un marco devops para acortar la entrega
tiempo para las aplicaciones en la nube. IJCSE, 7 (4): 329–344,
2012.
[26] S. Hosono e Y. Shimomura. Kit de ciclo de vida de la aplicación
para personalización masiva en plataformas paas. En Octavo
Congreso Mundial de Servicios de IEEE, SERVICIOS 2012, Honolulu,
HI, EE. UU., 24-29 de junio de 2012, páginas 397–398,
2012.
[27] S. Hussaini. Fortalecimiento de la armonización de
silos de desarrollo (dev) y operaciones (ops) en el entorno de
TI a través del enfoque de sistemas. En Sistemas de
transporte inteligente (ITSC), 17a Conferencia Internacional
IEEE 2014 sobre, 2014.
[28] KR Jayaram. Hacia explícitamente elástico
marcos de programación. En 37a Conferencia Internacional
IEEE / ACM sobre Ingeniería de Software, ICSE 2015, Florencia,
Italia, 16-24 de mayo de 2015, Volumen
2, páginas 619–622, 2015.
[29] X. Ju, L. Soares, KG Shin, KD Ryu y DD
Silva. Sobre la resistencia a fallos del taco abierto. En Simposio
ACM sobre Computación en la Nube, SOCC '13, Santa Clara, CA,
EE. UU., 1-3 de octubre de 2013, páginas 2: 1–2: 16,
2013.
[30] S. Keele. Directrices para la realización sistemática
revisiones de literatura en ingeniería de software. En Informe
técnico, Ver. 2.3 Informe técnico EBSE. EBSE. 2007.
[31] T. Kilamo, M. Lepp¨ änen y T. Mikkonen. La
desarrollador social: ahora, entonces y mañana. En
Actas del 7mo Taller Internacional de Ingeniería de
Software Social, SSE 2015, 2015.
[32] J. Kim. Preparando el virtualizado de un extremo a otro
conexión en red sobre infraestructura definida por software. En
Optical Internet 2014 (COIN), 2014 12th
International Conference on, 2014.
[33] J. Kim, C. Meirosu, I. Papafili, R. Steinert,
S. Sharma, F. Westphal, M. Kind, A. Shukla,
F. N´émeth y A. Manzalini. Proveedor de servicios devops para
servicios de red modernos a gran escala. En Simposio
internacional IFIP / IEEE sobre gestión integrada de redes, IM
2015, Ottawa, ON, Canadá, 11-15 de mayo de 2015, páginas
1391-1397, 2015.
[34] B. Kitchenham y P. Brereton. Una revisión sistemática
de la investigación de procesos de revisión sistemática en ingeniería de
software. Tecnología de la información y el software,
55 (12): 2049-2075, 2013.
[35] BA Kitchenham. ¿Qué pasa con las métricas de software?
- Un estudio cartográfico preliminar. Revista de sistemas y
software, 83 (1): 37–51, 2010.
[36] N. Kurapati, VSC Manyam y K. Petersen. Ágil
Encuesta de adopción de prácticas de desarrollo de software. En
Procesos ágiles en ingeniería de software y programación
extrema - 13th International Conference, XP
2012, Malm¨ ö, Suecia, 21-25 de mayo de 2012. Actas,
páginas 16–30, 2012.
[37] T. Leesatapornwongsa, M. Hao, P. Joshi, JF
Lukman y HS Gunawi. SAMC: comprobación de modelos con conciencia
semántica para el descubrimiento rápido de errores profundos en
sistemas en la nube. En 11 ° Simposio de USENIX sobre diseño e
implementación de sistemas operativos, OSDI '14, Broomfield, CO, EE.
UU., 6-8 de octubre de 2014., páginas 399–414, 2014.
[38] L. Lemus Zà ˜ˇžÃ̃´śiga, N. Pintos, E. Pardo, A. Garza,
y J. Montaà ˜´śana Aliaga. Evaluación y
intervención con wii fit en ancianos. En G. Jezic,
RJ Howlett y LC Jain, editores, Sistemas de agentes y agentes
múltiples: tecnologías y aplicaciones,
volumen 38 de Innovación, sistemas y tecnologías
inteligentes. Springer International Publishing, 2015.
[39] MA McCarthy, LM Herger, SM Khan y
BM Belgodere. Devops componible: análisis de madurez
de devops basado en ontologías automatizadas. En 2015
IEEE International Conference on Services Computing,
SCC 2015, Nueva York, NY, EE. UU., 27 de junio al 2 de julio
de 2015, páginas 600–607, 2015.
[40] M. Miglierina. Despliegue de aplicaciones y
gestión en la nube. En 16o Simposio Internacional sobre
Algoritmos Simbólicos y Numéricos para Computación
Científica, SYNASC 2014, Timisoara, Rumania, 22 al 25 de
septiembre de 2014, páginas 422–428,
2014.
[41] S. Murphy, S. Gallant, C. Gaughan y M. Diego.
Estrategia de virtualización en la nube de implementación de
arquitectura ejecutable de simulación y modelado del ejército de
EE. UU. En 12 ° Simposio Internacional IEEE / ACM sobre
Computación en Clústeres, Nube y Grid, CCGrid 2012, Ottawa,
Canadá, 13-16 de mayo de 2012, páginas 880–885,
2012.
[42] J. Obstfeld, S. Knight, E. Kern, QS Wang,
T. Bryan y D. Bourque. VIRL: el laboratorio virtual de
enrutamiento de Internet. En Conferencia ACM SIGCOMM
2014, SIGCOMM'14, Chicago, IL, EE. UU., 17-22 de agosto,
2014, páginas 577–578, 2014.
[43] M. Olszewska y MA Wald´én. Devops se reúne
Modelado formal en sistemas complejos de alta criticidad. En Actas
del 1er Taller Internacional sobre DevOps consciente de la
calidad, QUDOS 2015, Bérgamo, Italia, 1 de septiembre de
2015, páginas 7-12, 2015.
[44] S. Park, B. Cha y J. Kim. Preparando y
interconexión de cajas smartx hiperconvergentes para el
banco de pruebas de iot-cloud. En 29th IEEE International
Conference on Advanced Information Networking and
Applications, AINA 2015, Gwangju, Corea del Sur, 24-27 de
marzo de 2015, páginas 695–697, 2015.
[45] DL Parnas. Detén el juego de los números. Comun.
ACM, 50 (11): 19-21, 2007.
[46] JF P´érez, W. Wang y G. Casale. Hacia un
enfoque devops para la ingeniería de calidad del software. En
Actas del Taller de 2015 sobre desafíos en los métodos de
rendimiento para el desarrollo de software, WOSP-C'15,
Austin, TX, EE. UU., 31 de enero de 2015,
páginas 5 a 10, 2015.
[47] K. Petersen, S. Vakkalanka y L. Kuzniarz.
Directrices para la realización de estudios de mapeo sistemático
en ingeniería de software: una actualización. Tecnología de la
información y el software, 64: 1–18, 2015.
[48] J. Roche. Adopción de prácticas devops en calidad
garantía. Comun. ACM, 56 (11): 38–43, 2013.
[49] J. Scheuner, J. Cito, P. Leitner y HC Gall. Nube
workbench: Evaluación comparativa de proveedores de iaas
basados en infraestructura como código. En Actas de la 24a
Conferencia Internacional sobre World Wide Web Companion,
WWW 2015, Florencia, Italia, 18-22 de mayo de 2015 - Volumen
complementario, páginas 239–242, 2015.
 [50] A. Sill. Factores en el desarrollo y adopción de nuevos
software y estándares en la nube. Computación en
la nube IEEE, 1 (4): 10-13, 2014.
[51] J. Smeds, K. Nybom e I. Porres. Devops: a
de fi nición e impedimentos de adopción percibidos. En
Procesos ágiles, en Ingeniería de software y Programación
extrema, páginas 166-177. 2015.
[52] D. Smite, C. Wohlin, Z. Galvina y R. Prikladnicki.
Una terminología y taxonomía de base empírica para la
ingeniería de software global. Ingeniería de software
empírica, 19 (1): 105-153, 2014.
[53] D. Spinellis. Sistemas de gestión de paquetes. IEEE
Software, 29 (2): 84–86, 2012.
[54] T. Ustinova y P. Jamshidi. Modelado de varios niveles
Comportamiento de aplicaciones empresariales con
técnica de diseño de experimentos. En Actas del 1er Taller
Internacional sobre DevOps consciente de la calidad,
QUDOS 2015, Bérgamo, Italia, 1 de septiembre de 2015,
páginas 13-18, 2015.
[55] M. Virmani. Entendiendo devops cerrando la brecha
desde la integración continua hasta la entrega continua. En
Tecnología Informática Innovadora (INTECH), Quinta
Conferencia Internacional 2015 sobre, 2015.
[56] W. Wang, JF P´érez y G. Casale. Llenando los espacios vacios:
una herramienta para automatizar la estimación de parámetros
para modelos de rendimiento de software. En Actas del 1er Taller
Internacional sobre DevOps consciente de la calidad, QUDOS
2015, Bérgamo, Italia, 1 de septiembre de 2015,
páginas 31–32, 2015.
[57] J. Wettinger. Optimización de la automatización de devops para
aplicaciones en la nube que utilizan {TOSCA} como metamodelo
estandarizado. Sistemas informáticos de futura generación,
2015.
[58] J. Wettinger, V. Andrikopoulos y F. Leymann.
Captura automatizada y uso sistemático del conocimiento de
devops para aplicaciones en la nube. En Conferencia
internacional IEEE 2015 sobre ingeniería en la nube, IC2E
2015, Tempe, AZ, EE. UU., 9-13 de marzo de 2015, páginas
60–65, 2015.
[59] J. Wettinger, M. Behrendt, T. Binz, U. Breitenb¨
Viie
ewwppu
ubblliiccaactitud
enn sstta
attss
G. Breiter, F. Leymann, S. Moser, I. Schwertle y
T. Spatzier. Integración de la gestión de la configuración con la
gestión de la nube basada en modelos basada en TOSCA. En MÁS
CERRADO 2013 - Actas de la 3a Conferencia Internacional sobre
Ciencias de la Computación y Servicios en la Nube, Aquisgrán,
Alemania, 8-10 de mayo de 2013,
páginas 437–446, 2013.
[60] J. Wettinger, T. Binz, U. Breitenb¨ ücher, O. Kopp,
F. Leymann y M. Zimmermann. Invocación unificada de scripts
y servicios para aprovisionamiento, implementación y
administración de aplicaciones en la nube basadas en TOSCA.
En CLOSER 2014 - Actas de la 4ta Conferencia Internacional
sobre Ciencia de Servicios y Computación en la Nube,
Barcelona, España, 3-5 de abril de 2014.,
páginas 559–568, 2014.
[61] J. Wettinger, U. Breitenb¨ ücher y F. Leymann.
Automatización de la implementación basada en compensaciones
frente a la convergente para servicios operados en la nube. En
Computación orientada a servicios - 12ª Conferencia
Internacional, ICSOC 2014, París, Francia, 3-6 de noviembre
de 2014. Actas, páginas 336–350, 2014.
[62] J. Wettinger, U. Breitenbü ¨cher y F. Leymann.
Devopslang: reduciendo la brecha entre el desarrollo
y operaciones. En Computación orientada a servicios y en
la nube - Tercera conferencia europea, ESOCC
2014, Manchester, Reino Unido, 2-4 de septiembre de
2014. Actas, páginas 108-122, 2014.
[63] J. Wettinger, U. Breitenbü ¨cher y F. Leymann.
Compensación y convergencia: comparar y combinar
enfoques de automatización de implementación. En t. J.
Cooperative Inf. Syst., 24 (3), 2015.
[64] J. Wettinger, U. Breitenbucher y F. Leymann. Dyn
Tail: motores de implementación adaptados dinámicamente
para aplicaciones en la nube. En Computación en la nube
(CLOUD), 2015 IEEE 8th International Conference on, junio
2015.
[65] SA Wright y D. Druta. Código abierto y
estándares: El papel del código abierto en el diálogo entre
investigación y estandarización. En 2014 Talleres IEEE
GLOBECOM, Austin, TX, EE. UU., 8-12 de diciembre de 2014, páginas
ücher,
650–655, 2014.