WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.
12
Métricas para la Mejora del Performance en
Organizaciones que utilizan Scrum, ITIL y CMMi
Antonio Quin1
Universidad Nacional mayor de San Marcos
Abstract—Es muy importante saber qué tipos de métricas se
aplican dentro de los procesos de TI en la industria actual, por qué
son importantes y en qué tipos de empresas se aplican. La
finalidad de este estudio es hacer una revisión de algunas de las
métricas más utilizadas expuestas en la literatura, referentes a las
prácticas de Scrum, ITIL y CMMi, con el objetivo de determinar
el avance científico referente a este campo y conocer las métricas
candidatas que puedan ser utilizadas posteriormente en un modelo
de integración de métricas, que ayude a monitorear los servicios
de TI, con el objetivo de apoyar en la mejora del desempeño de las
organizaciones que usan Scrum, CMMi e ITIL. La búsqueda
exploratoria encontró 1196 artículos, de los cuales se revisaron 198
para finalmente elegir 31 artículos, de los cuales se obtienen 297
métricas, 38% son Scrum (112 métricas), 33% son de ITIL (98
métricas) y 29% son de CMMi (87 métricas), dichas métricas
fueron utilizadas mayormente en empresas de Europa 35%.
Keywords—ITIL; Scrum; CMMI; Metrics; Measurement.
I. INTRODUCCIÓN
Vivimos en una época de importantes avances disruptivos en
tecnología, avances en hardware y superpotencia de
procesamiento, de grandes cantidades de datos sin procesar y
nuevos conceptos, todo ello bajo un marco industrial de
competencia de marca y de apetito de los consumidores
tecnológicos nativos. Fitzgerald, (2018), denomina a este
panorama el “Software Crisis 2.0” caracterizado por grandes
cantidades de data por procesar, cambios tecnológicos que
desfasan a los profesionales y hacen caducar los procesos y
metodologías. Bajo este marco de avance tecnológico y en
medio de la competencia de las empresas por ofrecer servicios o
productos de calidad adecuada al requerimiento y demanda del
público objetivo, surge la necesidad de medir como actividad
vital para subsistir. Las métricas, son una herramienta poderosa
e incluso obligatoria para la gestión eficaz de pruebas y toma de
decisiones de toda empresa (Tudjarova et al., 2017). Mohsen et
al., (2017) asegura que la métrica de software es un estándar para
determinar la madurez del proceso y el esfuerzo requerido.
Sin embargo, no todas las empresas le dan importancia al uso
de las métricas. Kettunen et al. (2019) muestran los resultados
de un instrumento de encuesta realizada a 118 personas, donde
el 41% de encuestados respondieron que su empresa no sigue
ninguna métrica en particular. Gacenga & Cater-steel (2011)
complementan indicando que las áreas de Tecnología le dan
poca importancia a discutir si las métricas colocadas son las
adecuadas.
Por ello, es necesario proyectar métricas que sean útiles y
permitan mejorar el desempeño de las empresas. La literatura
científica presenta diversos estudios de métricas, pero solo
E-ISSN: 2415-1513
Sussy Bayona-Ore2
Universidad Autónoma del Perú
ciertos estudios se desarrollan dentro de las metodologías y
marcos Scrum, CMMi e ITIL. Consideramos necesario que las
métricas que se desarrollen cuenten con un marco o metodología
de soporte y que hayan sido probadas en empresas, ya que en
una segunda fase se construirá un modelo de integración de
métricas. Este estudio es la primera parte de una propuesta de
modelo para la integración de métricas Scrum, CMMi e ITIL,
que tiene como objetivo lograr la mejora del desempeño en las
empresas que utilizan estas prácticas.
II. MARCO TEÓRICO
La preocupación de contar con métricas para las diversas
actividades está ligado al avance de la humanidad. Sydenham
(2003) considera que la medición ha forjado los grandes avances
de la civilización gracias a que la medida se utilizó para
desarrollar las ideas del universo y todas las cosas. En la década
del 60 y 70 las métricas se utilizaban para evaluar productos
industriales creados en las grandes fábricas, y en los años 80 y
90 estuvieron centrados en medir procesos industriales
amparados por los nuevos conceptos de calidad (Bundschuh &
Dekkers, 2008), este cambio nos muestra como en un par de
décadas el concepto de productividad fue reemplazado por el
concepto de rendimiento. Hoy a pesar del gran avance
tecnológico, Tahir & Gencel, (2010) apoyan la idea de la falta
de madurez de los marcos, muchos de ellos con deficiencias en
controles, debido a que las empresas actuales tienen muchas
dependencias horizontales y verticales.
A. Métricas
Según el IEEE Std 610.12-1990 establece que métrica es
“Una medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado” (The Institute of
Electrical and Electronics Engineers, 1990). Kaner & Bond,
(2004) sostienen que “la medición es la asignación empírica y
objetiva de números, de acuerdo con una regla derivada de un
modelo o teoría, a atributos de objetos o eventos con la intención
de describirlos”.
Referida al software, “una métrica es un estándar para medir
el grado en que un sistema y proceso de software poseen alguna
propiedad” (Mohsen et al., 2017). Las métricas tienen una
importancia central en el desarrollo de todo equipo de TI,
permiten visualizar el posible impacto que podría tener cualquier
modificación durante el desarrollo del software, desde las
tempranas etapas de conformación del equipo o nueva
tecnología, hasta cambios posteriores o reprocesos (Erdogan et
al., 2018).
1|P age
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12
B. SCRUM
Schwaber & Sutherland, (2020) definen Scrum como un
marco ligero que emplea técnicas y métodos agiles, iterativos e
incrementales que permiten realizar un trabajo en ciclos cortos
denominados Sprints que generalmente son de 1 mes o menos,
al empezar el sprint se seleccionan los trabajos desde un
repositorio denominado Product backlog, el monitoreo se
controla con tableros de avance, y breves reuniones que
permiten facilitar los trabajos de los miembros del equipo; al
terminar el Sprint se entrega lo comprometido según lo
planificado. Para finalizar se lleva a cabo una retrospectiva para
mejorar la calidad y eficacia de los próximos trabajos.
La práctica Scrum tiene 3 fases. Cada fase describe subfases
y procesos en detalle, incluyendo sus entradas, herramientas y
salidas asociadas. La lista de subfases son las siguientes: (1)
Fase I. Planificación y diseño de alto nivel, incluye Creación del
Product Backlog, Visión del proyecto, Identificar interesados o
socios del proyecto, Formación del equipo Scrum, Riesgos y
otras necesidades de inicio (2) Fase II. Desarrollo, que incluye
la Realización del sprint y temas asociados como análisis,
monitoreo y delivery del producto (3) Fase III. El cierre del ciclo
y lanzamiento del producto, que incluye Integración, Testeo,
Documentación y Retrospectiva del proyecto. (Abrahamsson et
al., 2017).
Según Sharma & Hasteer, (2016) y Zaouali & Ghannouchi,
(2020), Scrum es la práctica más utilizada y la más útil
actualmente para dirigir proyectos, tanto en investigaciones
como en industria. Sin embargo pese a ser muy utilizada y estar
presente en la industria por más de una década, Mauro &
Messina, (2016) apoyan la idea de que Scrum aún debe
evolucionar mucho más en métricas, debido a que aún hay
mucho trabajo conceptual por hacer.
C. CMMI
El SEI (Software Engineering Institute, 2010) define CMMI
como un conjunto de productos integrados destinados a la
mejora de procesos y productos, cubriendo el ciclo de vida
completo. Cuenta con el modelo de Servicios (CMMi-SVC). El
modelo de Desarrollo (CMMi-DEV), y el de Adquisiciones
(CMMi-ACQ), Utilizando el concepto de niveles de madurez
para lograr la manera correcta para que una empresa pueda
seguir mejorando sus procesos. Khraiwesh, (2020), afirma que
una estrategia eficaz para garantizar la supervivencia de una
empresa necesita de la adopción de un modelo CMMI, Amer et
al. (2020) indica que CMMI debe utilizarse para controlar la
calidad y madurez del software para los cuales algunas otras
prácticas como Scrum no detallan. CMMI establece un área de
procesos relacionados con las métricas. Al desplegar los
procesos software utilizando CMMI se debe contar con un
repositorio para las métricas (Sussy et al., 2008). Para la gestión
de proyectos CMMI tiene como bases las métricas que
establecen PSP y TSP (Chavarria et al., 2016).
D. ITIL
IT Infrastructure Library (ITIL) es una práctica con
recomendaciones, descripciones e instrucciones para la gestión
de los servicios y procesos de todo el ciclo de vida de tecnología
de información, cuenta con roles y actividades adaptables a
cualquier tipo de empresa u organización (Steinberg, 2011). Las
E-ISSN: 2415-1513
fases del ciclo de vida de los servicios de ITIL en su tercera
Versión son: (1) Estrategia de servicio: que comprende el
diseño, desarrollo e implantación estratégica de la gestión de
servicios de TI. (2) Diseño del servicio, abarcando los procesos
necesarios para apoyar el desarrollo de dichos servicios, (3)
Transición del servicio, que se encargan de estrategias para
implantar servicios nuevos o modificados para apoyar las
operaciones de negocio, (4) Operaciones de servicio, que se
ocupa de las actividades y procesos designados para gestionar
los servicios que permitan apoyar a usuarios y clientes dentro de
los niveles de servicio pactados y (5) Mejora continua, que
comprende estrategias para el análisis y la mejora de forma
constante de los servicios para garantizar el óptimo desempeño
para el negocio. Respecto a sus métricas, ITIL no presenta
ninguna estrategia ni define secuencia que permita implementar
convenientemente los procesos (Sánchez & Luis, 2021).
III. REVISIÓN SISTEMÁTICA
Para poder hacer una buena elección de métricas en
empresas que utilizan practicas Scrum, CMMi e ITIL,
necesitamos hacer un estudio exploratorio verificando que tipos
de métricas se están utilizando y en qué tipos de empresas son
aplicadas, Con este propósito se realizó una revisión sistemática
de la literatura para conocer el estado actual de los avances
científicos en lo expuesto. Como método se utilizó la propuesta
por Kitchenham (2004), para revisión sistemática en el marco
del tipo de investigación realizada. La revisión sistemática
realizada tiene tres fases: Planificación de la revisión,
conducción de la revisión y exposición de resultados.
A. Planificación de la Revisión
La planificación es la creación del documento que será
utilizado para la conducción de la revisión, la cual posee las
preguntas de investigación que se han formulado los
investigadores (Bayona et al., 2013). Con dichas preguntas se
hallan las palabras a buscar, consideradas claves y se determina
la cadena de búsqueda, posteriormente se analiza y decide cuales
será las fuentes de datos y que criterios de inclusión y exclusión
deberán considerarse.
1) Conducción de la revisiòn. Se requiere construir un
catálogo de métricas orientadas al mejoramiento del desempeño
de servicios de producción de una empresa financiera. Para ello
se necesita conocer las métricas utilizadas en procesos Scrum,
CMMi e ITIL, teniendo en consideración (1) foco de
investigación: Métricas Scrum, CMMi e ITIL y (2) Contexto:
practicas Scrum, CMMi e ITIL.
2) Definición de la pregunta de investigación. Para poder
identificar los artículos científicos de interés de este estudio se
ha realizado una revisión sistemática de la literatura utilizando
la siguiente pregunta de investigación:
¿Qué tipo de métricas se han utilizado y en qué tipos
de empresas se han realizado trabajos de prácticas
Scrum, CMMi e ITIL?
3) Creacion de la cadena de búsqueda.
Se utilizaron las siguientes palabras claves utilizadas
para la búsqueda avanzada:
(metric OR indicator ) AND ( cmmi OR itil OR scrum
)
2|P age
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

4) Selección de las fuentes de datos.Las librerías digitales B. Conducción de la Revisión

seleccionadas como para realizar la búsqueda son las En esta etapa se establece e identifica los estudios primarios,
siguientes: IEEE Computer Society Digital Library verificando su calidad, para luego extraer la información
http://www.computer.org/portal/web/csdl, IEEE Xplore requerida por la investigación.
http://ieeexplore.ieee.org, IET Digital Library
1) Determinación de los estudios primarios. Posterior al
http://www.ietdl.org, Scopus
retiro de estudios duplicados se verificó que el título y resumen
https://www.scopus.com/home.uri, Springer Link
son de interés del tema a tratar, se obtuvo un total de 198
https://link.springer.com/ y Web of Science
estudios, de los cuales, luego de examinar detalladamente cada
https://www.webofscience.com.
contenido nos quedarnos con 31 artículos. En la Tabla I se
5) Determinacion de criterios de exclusión e inclusión: Se
muestra el resultado total de la selección realizada.
consideraron los criterios de exclusión y los criterios de
inclusión. TABLE I. PRIMARY ARTICLES
Los criterios de exclusión (CE) son cuatro:
Articles Distribution
 CE1: Artículos con contenido no disponible. Database Articles Candidate Primary
 CE2: Artículos duplicados. found Articles Articles
 CE3: Estudios no relacionados con tecnología, proyectos IEEE Computer Society
340 49 5
y procesos, por considerarlos fuera del rango requerido Digital Library
IEEE Xplore 55 23 6
de análisis IET Digital Library 30 10 2
 CE4: Estudios que no hayan utilizado empresas como Scopus 173 89 13
validación o caso de uso. Springer Link 21 4 2
Los criterios de inclusión (CI) son dos: Web of Science 577 23 3
Total 1196 198 31
 CI1 Incluir artículos del período 2016 al 2022 en
2) Evaluación de la calidad de los estudios: Se realizó la
primera revisión de literatura.
evaluacion de cada estudio primario. Luego, se evaluó la
 CI2 Incluir artículos relacionados con las
calidad de los estudios.
métricas CMMi, CMMi-DEV, CMMi-SVC, ITIL y
3) Extracción de los datos de los estudios primarios: La
Scrum.
data relevante de cada estudio fue extraida y se tabulo en hojas
de calculo para su posterior análisis.

La Figura 1 muestra la cantidad de artículos Scrum referente

IV. RESULTADOS a métricas (20 artículos, 64%) frente a números relativamente
A. Distribución de Artículos Primarios según Tipo de bajos y casi proporcionalmente iguales de artículos con métricas
Practica ITIL (7 artículos, 23%) y CMMi (4 artículos, 13%). Se puede
apreciar que casi las 2 terceras partes del total de estudios
Del total de 31 artículos revisados la distribución según las recopilados se enfocan en Scrum, mientras que solo una tercera
métricas ITIL, CMMi y Scrum, hemos considerado la parte lo comparten aquellos estudios enfocados en ITIL y
distribución según el tipo de práctica realizada, la cual se puede CMMi. Este hecho parece refrendar lo sustentado por Sharma &
ver en el Gráfico N.º 1. Hasteer, (2016) y Zaouali & Ghannouchi, (2020) quienes
afirman que Scrum es la práctica ágil más utilizada y la más útil
actualmente, tanto en investigaciones como en la industria.
B. Distribución de Artículos Primarios según Empresa de
4, Caso de Uso o Lugar de Aplicación del Estudio
13% Dentro de los estudios considerados se aprecian los lugares
físicos de las empresas en donde se realizaron los casos de
7, 23% estudio. Fueron considerados en su mayoría organizaciones del
20, 64%
continente europeo (11 estudios), seguidas por empresas
americanas, incluidas Sudamérica y Centroamérica (8 estudios)
y multinacionales (5 estudios). Las consideradas como varias
empresas son empresas deslocalizadas entre varios países, con
sedes entre Europa, América y Asia (véase Figura 2).
Scrum ITIL CMMi

Fig. 1 - Distribución según tipo de práctica realizada

3|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Varios Africa
Paises 10% Varios sectores 13%
16% Asia Tecnologia 45%
13% Gobierno/Publica 19%
Educacion 6%
Comercio/Industria 10%
Banca 6%
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Europa
America
35% Total
26%
Fig. 3 Sectores a los que pertenecen las empresas estudiada

Africa Asia America Europa Varios Paises En la Figura 3 se observa que los estudios son
predominantemente en empresas de tecnologia (14 estudios,
45%), seguidas de Gobierno y Publicas con 6 estudios y 19%
Fig..2 - Localización de empresas referenciadas en los
del total considerado. En la categoria de varios sectores se estan
estudios
agrupando aquellos estudios multiempresas, mayormente de
En cuanto a los sectores en la que se desarrollan las tipo de encuestas a profesionales. En la Tabla II se encuentra la
empresas, se distribuyeron en 6 tipos, según se muestra en la relacion de empresas según caso de estudio efectuado.
Figura 3.

TABLE II. EMPRESAS REFERENCIADAS EN ESTUDIOS EFECTUADOS DE ARTÍCULOS SELECCIONADOS

Practica Caso de estudio País Autor Año
Scrum Equipo de solución empresarial de empresa anónima Sudan Gadelsied et al. 2021
ITIL Universidad, nacional con 24000 estudiantes Bulgaria Mitev & Kirilov 2021
35 ejecutivos de procesos de ITIL de empresas de telecomunicaciones, de
ITIL Irán Baradari et al 2021
TI e industria bancaria
Scrum Equipos de desarrollo ágil de 14 países, de Polonia en su mayoría Varios Países Marek et al. 2021
Barcelo-Valenzuela
ITIL Departamento de TI en institución Electoral Publica México 2020
& Leal-Pompa
CMMi Empresa de software con casi 100,000 empleados, y nivel 5 de CMMi Varios Países Agrawal & Chari 2020
Empresa proveedora de servicios de TI con sede en más de 20 países y 38
Scrum Varios Países Shirokova et al 2020
mil empleados
Scrum Defense Industries Research and Development Institute Turquía Tekin et al. 2020
Universidad, 300 cuestionarios respondidos por trabajadores de la
CMMi Jordania Khraiwesh 2020
universidad
Scrum Empresa pública de aproximadamente 200 empleados Brasil Carneiro et al. 2019
Scrum Empresa financiera Brasil Bufon & Leal 2019
Organización privada que administra fondos públicos para la prestación
Scrum Costa Rica Chavarria & Madriz 2019
de los servicios de agua, alcantarillado, electricidad y alumbrado.
Scrum 115 personas encuestadas, de los sectores TI, financiero y retail Finlandia Kettunen et al. 2019
Scrum Varias entidades estatales con proyectos agiles Brasil Kovags et al. 2019
Scrum 25 proyectos de software ubicados en Chaco, Corrientes y Misiones Argentina Pinto et al. 2018
Empresa con oficinas en Estambul y Ámsterdam. desarrolló soluciones de
CMMi Turquía Utku & Şahin 2018
software.
9 proyectos en 9 empresas distintas, con personal de cinco y diez años y
Scrum India Arumugam et al. 2018
de 21 a 47 años de edad
Scrum Organización de TI de operadores digitales con más de 60 equipos ágiles Turquía Ertaban et al. 2018
Entrevistas a 14 personas de diferentes organizaciones en múltiples
Stettina &
Scrum sectores, tamaños y países, la mayoría fueron grandes organizaciones Varios Países 2018
Schoemaker
predominantemente del sector privado.
Instituto de investigación y desarrollo que ofrece soluciones de software
Scrum de gobierno electrónico, con 150 empleados, 60 de ellos son ingenieros de Turquía Erdogan et al. 2018
software
ITIL Área de operaciones de TI en Pyme Marruecos Yamami et al 2017
20 proyectos de 14 contratistas industriales para el Departamento de
Scrum USA Rosa et al. 2017
Defensa de EE. UU.
20 ingenieros del cuerpo técnico de empresa industrial, perteneciente a
ITIL Ecuador Bustamante et al 2017
cuatro plantas, 10 ingenieros externos de apoyo y 5 proyectos.
Empresa con negocios en telecomunicaciones que brinda servicios de
ITIL Indonesia Nugraha & Legowo 2017
datos.
Scrum Compañía de seguros con usuarios finales de diversos países. Varios Países Tudjarova et al. 2017

4|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12
CMMi Empresa que desarrolla software en industria de defensa
3 entornos de host privados y públicos con 29 clientes (empresas) y 11,430
ITIL
servidores analizados
Empresa con equipo de software distribuido entre Alemania, India y
Scrum
EEUU.
Scrum Organización de desarrollo de software de tamaño mediano
Empresa de telecomunicaciones con escenario deslocalizado y asociación
Scrum
de entrega con proveedor
Proveedor de soluciones de gestión de operaciones de marketing para
Scrum
grandes clientes internacionales
C. SCRUM
Dentro de la revisión de los nuevos avances propuestos en
los estudios, figura la creación de métricas basado en enfoque de
gestión de evidencias (EBM) propuesta por Shirokova et al.,
(2020), realizados en una empresa global de más de 20 países.
Los autores consideraron utilizar SAFE (Scale Agile
Framework), además de un sistema de indicadores cuantitativos
y cualitativos basados en factores como el valor, el tiempo de
comercialización y la calidad, con el objetivo de medir el valor
de entrega a los clientes. Tekin et al., (2020) por su parte, estudió
métricas de toma de decisiones de varios criterios en una
empresa de investigación y desarrollo en la industria de defensa,
en su trabajo realiza una selección sistemática utilizando criterio
de expertos combinados con inclusión de parámetros como la
solidez, simplicidad y rentabilidad, y refinando la elección con
el método Analytic Hierarchy Process (AHP); asegura que
Burndown Chart, Velocity Chart y Burnup Chart son las
métricas más utilizadas por los miembros de su grupo de
estudios.
Más enfocados en el tema de costos figura el estudio de
Chavarria & Madriz, (2019) quienes proponen una técnica para
la estimación del ROI (Return On Investment), aplicándola en
una organización privada que administra los fondos públicos.
La técnica propone una identificación de elementos de costo
basada de la revisión de 5 instrumentos metodológicos, además
de evaluación de la desviación del ROI al final de cada Sprint
mediante la estimación del valor ganado. Concluye que es
necesario definir parámetros de desviación mínima, invertir en
capacitación y creación de cultura en áreas financieras y
metodológicas.
Rosa et al., (2017), por su parte, realiza un estudio en el
departamento de Defensa de USA, en base a muestreo y
cuestionario con profesionales de TI, analizando tamaño,
factores de costo, requisitos funcionales y esfuerzo, con el
objetivo de mejorar la estimación de costos; los resultados
mostraron que los requisitos iniciales de software son una
métrica válida para estimar el esfuerzo de desarrollo de software
ágil, la precisión de la predicción mejora cuando se agregan el
personal y el dominio de esfuerzo como entradas a los modelos
de costos.
Bufon & Leal, (2019), utilizan un método para identificar
desperdicios dentro del proceso de desarrollo de software para
una empresa del mercado financiero, se identifican los
desperdicios como indicadores que muestran el número de
cuellos de botella, trabajo en curso y número de artículos
acumulados, en forma de retrasos, defectos, extras y trabajos
inconclusos.
E-ISSN: 2415-1513
Turquía Cenkler 2016
Alemania Fiegler et al 2016
Varios Países Gupta et al 2016
Egipto Anwar et al. 2016
United
Grimaldi et al. 2016
Kingdom
Dinamarca Kayes et al. 2016
Respecto a métricas para evaluar la cultura ágil tenemos el
modelo propuesto por Gadelsied et al., (2021), quienes realizan
un caso de estudio en una empresa de software sobre un modelo
VGQM, una extensión de la metodología GQM (valor, objetivo,
pregunta y métrica), colocando los valores Scrum como
indicadores de valores centrales que deben medirse, a partir de
ello enfocan GQM para establecer los indicadores necesarios,
obteniendo resultados que permitieron evaluar valores de cultura
ágil e identificar brechas como áreas de mejora.
Dentro de los estudios que buscan las métricas más
importantes y más utilizadas se encuentra el de Kettunen et al.,
(2019), quienes analizan los resultados de un instrumento de
encuesta realizada en los sectores TI, financiero y retail,
indagando desarrollo ágil en las organizaciones. Concluye que
las métricas de Lead time, cycle time, release cycle, Value y
Defects son las más utilizadas; las metas operativas de
productividad y calidad son consideradas las más importantes a
alcanzar; resalta que no existe una "forma ágil única" para todas
las empresas, sino que las organizaciones enfocan la importancia
de la agilidad según sus necesidades.
Kovags et al., (2019) identifican métricas con la finalidad de
medir el esfuerzo en el desarrollo ágil de software, a través de la
revisión de contratos de desarrollo en varias entidades de
administración pública. Concluye que los puntos de función
siguen siendo la métrica más utilizada debido a su objetividad
con respecto a los requisitos funcionales, además de la métrica
de Unidad Técnica de Servicios (UST), ambos presentes en la
mayoría de contratos. Arumugam et al., (2018) estudian
indicadores de rendimiento de los integrantes del equipo ágil a
través del método de encuesta, en 9 empresas distintas
desarrollando software global, para ello se basan en cuatro
métricas: Escaped defects, Team member velocity, Deliverables
y Effort, mostrando logros alcanzados y detectando alertas
tempranas que ayuden a los jefes de proyecto a administrar y
corregir el rumbo del proyecto cuando fuera necesario.
Dentro de grupo de estudios enfocados a la mejora de gestión
Scrum se encuentra el trabajo de Carneiro et al., (2019), quienes
muestran el uso de Scrum en la gestión de rutinas a través de un
estudio de caso en un departamento de empresa pública,
presentando 7 indicadores para medir su desempeño a través de
las practicas Scrum. Como resultado se mejoró el flujo de
trabajo rutinario, además de la gestión de planificación,
seguimiento, calidad y alineamiento de los miembros del
equipo.
Ertaban et al., (2018), proponen un modelo de métricas de
rendimiento en entorno corporativo de operadores digitales,
desarrolla 12 métricas basadas en los principios de agilidad
Scrum, con el objetivo de ayudar a sus equipos de desarrollo a
5|P age
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

evaluar su desempeño para buscar una mejor calidad y
motivación.
Erdogan et al., (2018), realiza un análisis estadístico en un
Instituto de investigación de gobierno electrónico, evaluando
qué tipo de datos se requieren para el monitoreo; concluye que
las estadísticas de Correlación entre el punto de historia y
esfuerzo real y la Consistencia de la estimación relativa son
adecuadas para la estimación de los equipos; las estadísticas de
"Esfuerzo real del equipo en el producto", "Velocidad del
equipo", "Esfuerzo real para un punto de historia", "Tasa de
innovación" y "Velocidad frente a la tasa de esfuerzo no
planificado" son útiles para controlar y aumentar la
productividad de los equipos.
Grimaldi et al., (2016), implementa métricas bajo el marco
SAFe3.0, con equipos de trabajo Scrum, buscando demostrar
cómo pueden trabajar de manera eficaz una empresa
deslocalizada y un proveedor externo; expone 8 métricas para
cuantificar la adopción del modelo aplicado; concluye que la
introducción del marco ha mejorado significativamente el
proceso, además de generar ahorros de costos del 8% durante el
período de observación.
Dentro del grupo de mejoras a procesos Scrum, Stettina &
Schoemaker, (2018), estudian rutinas de informes, artefactos y
métricas en Agile Portfolio Management en base a entrevistas a
10 grandes organizaciones, identificando 5 tipos de métricas: de
desempeño, calidad, progreso, estado y contextuales. Los
resultados muestran tres dominios de conocimiento, generación
de artefactos y métricas de informes, identificando y mejorando
la comprensión de los requisitos de informes bajo nuevos
conceptos.
En gestión de requisitos, Pinto et al., (2018), validan la
calidad de 25 proyectos de software basándose en el marco AQF
(Agile Quality Framework), compuesto por el modelo, QuAM
(Agile Quality Model), el cual contiene métricas, atributos y
criterios. Su aporte se centra en que el nivel de calidad de un
proyecto no es solo un valor numérico, sino una serie de
interrogantes, en función del contexto del proceso; los resultados
obtenidos indicaron una reducción considerable de tiempos de
producción, mejor comunicación y disminución del volumen de
historias de usuario no aceptadas por el cliente.
En procesos de Testing, Tudjarova et al., (2017) analizan
dentro de una empresa internacional de TI comparativos de
métricas para pruebas de software con diferentes metodologías
de desarrollo, revisando su importancia e influencia en la calidad
del software; los resultados muestran 11 métricas necesarias
para fase de pruebas. Concluye que no existe un enfoque general
para pruebas de métricas, ya que depende de cada proyecto y
objetivo.
Kayes et al., (2016), proponen una métrica denominada
Product Backlog Rating (PBR) dentro de una empresa
proveedora de gestión de operaciones, con el objetivo de evaluar
el proceso de prueba en Scrum. Dicha métrica considera la
complejidad de las funciones a desarrollarse en una iteración de
Scrum, evalúa las calificaciones de pruebas y cuenta con una
puntuación numérica.
Anwar et al., (2016) trabaja en la adopción ágil en una
empresa de software, con el objetivo de ser ágil y no perder el
nivel de madurez CMMi alcanzado, para ello utiliza cuatro
métricas relacionadas con la reducción del costo de desarrollo:
Testing overhead, Rework, Leaking-defects rate y Customer
Satisfaction, Los resultados obtenidos mostraron una reducción
de la tasa de reelaboración del 29 % al 13 %, un retrabajo
disminuido al 55.2%, los gastos generales de prueba y las
métricas de fuga de defectos también mejoraron en más del 20%.
Gupta et al., (2016) por su parte, describe un caso de estudio
sobre adopción de pruebas ágiles en el desarrollo de un producto
de software heredado, en un entorno de empresa deslocalizada
entre Alemania, India y EEUU, midiendo la efectividad de
pruebas a través de 13 métricas, los resultados maximizaron los
impactos de las pruebas en el éxito del producto, ayudando a los
desarrolladores a colaborar mejor dentro de los equipos.
Por último Marek et al., (2021), investiga el impacto de la
pandemia de Covid-19 en equipos de desarrollo ágil verificando
las herramientas y métricas utilizadas, para ello realiza una
encuesta global a diferentes equipos de ingeniería de software
de 14 países. Las métricas más utilizadas fueron Velocity,
Calidad, Trabajo en progreso, Tasa de éxito y Valor entregado.
Los resultados obtenidos indicaron que la pandemia de Covid-
19 no logro hacer gran impacto en los equipos de Desarrollo ágil,
la frecuencia de lanzamiento y la definición de hecho por
ejemplo, la mayoría de encuestados refirieron que sus empresas
no sufrieron cambios mayores.
En la Tabla III se presenta las métricas utilizadas en los
estudios sobre Scrum.

TABLE III. MÉTRICAS UTILIZADAS EN ESTUDIOS SCRUM SELECCIONADOS

Indicador
LdTime = Tdel - Tdev
Satisfaction
SDR=(nuf /tnf)∗ 100%
Get the customers feedback.
Measures the degree of the organization
Cross rate= (Croimp/ TotTask) ∗ 100%
CourC = (RejUn / TotUn) ∗ 100%
CourT= ActiveMember/to talMember)∗100%
Uso Objetivo Autor Año
Cálculo del tiempo de entrega de la tarea restando el tiempo de desarrollo.
Evaluar la satisfacción del cliente midiendo el tiempo que tarda el equipo en resolver la
solicitud de los clientes.
Evaluar el grado de enfoque de los equipos en el trabajo al medir la cantidad de funciones
descubiertas al final de la iteración del producto.
Capacidad de las organizaciones para obtener comentarios de los clientes. Evaluación de la Gadelsied et
2021
Grado de apertura de la organización con sus empleados. cultura Scrum al.
Nivel dentro del equipo al calcular el número de implementaciones cruzadas que
ocurrieron al sobrepasarse sin tener en cuenta el permiso de otros compañeros de equipo.
Mide el nivel de compromiso con el cliente al rechazar solicitudes innecesarias que
pueden entorpecer el proceso de trabajo.
Compromiso del gerente para eliminar a los miembros inactivos del equipo.

6|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Indicador Uso Objetivo Autor Año

Velocity, Quality, Work in progress, Sprint, goal
success rate, Value delivered, Productivity, Métricas
Sustainability, Delivered rate, Lead time, Focus Métricas más utilizadas por equipos de trabajo remoto por Covid 19 utilizadas para
factor, Cycle time, Throughput, Work ítem y Cost of gestión de
delay equipos agiles Marek et al. 2021
Focus Factor, Vanity Metrics, Daily resolved defects debido a
per team member, Skills gained and shared with the pandemia Covid
Nuevas métricas utilizadas para Covid 19
team y Weekly work hours reporting instead of 19
monthly reporting
Revenue per Employee Indicador competitivo clave dentro de una industria.
Product Cost Ratio Gastos y costos totales incluidos los costos operativos en comparación con los ingresos
Análisis de sentimientos para ayudar a medir la energía y el entusiasmo del compromiso Área de Valor:
Employee Satisfaction
de los empleados Current Value
Análisis de sentimientos para ayudar a medir el compromiso del cliente y la felicidad con
Customer Satisfaction
el producto
Release Frequency Número de lanzamientos por período de tiempo
Shirokova et
Cantidad de tiempo desde que comienza el trabajo en un lanzamiento hasta el punto en 2020
Cycle Time Área de Valor: al
que se lanza.
Time to market
Cantidad de tiempo desde que se propone una idea hasta el momento que el cliente puede
Lead Time
beneficiarse de dicha idea
Number of defects Número de defectos encontrados con un ciclo.
Número de quejas sobre la calidad del software recopiladas de clientes y usuarios después Área de Valor:
Number of incidents
del lanzamiento. Quality
Number of repeated defects Número de defectos que se repiten de un ciclo a otro
Punctually of daily meeting (DM)
Adherence to planning (%)
Points accepted by the PO (%) Medir el
Esfuerzo del departamento de Sistemas para medir su desempeño a través de prácticas Carneiro et
Burn-ups inserted (%) desempeño de las 2019
Scrum al
Sprint Speed prácticas Scrum
Average of people in each sprint
Points achieved per person
Retorno de la inversión (ROI) Estimar costos al
Chavarria &
TIR (Taza interna de retorno) Medir los costos y el retorno de inversión del proyecto final de cada 2019
Madriz
VAN (Valor actual neto) sprint
Number of bottlenecks (NB) Número de cuellos de botella considerando el tiempo de entrega de un requerimiento Indicadores para
Work in progress (WIP) WIP ajustado para cuantificar todos los requisitos que se desvían del flujo de valor control de Bufon &
2019
Número de ítems acumulados de requerimientos para cada colaborador en cada fase de residuos en Leal
Number of accumulated items (NAI)
desarrollo proyectos
Lead time (features, epics, issues), cycle time,
release cycle, Value, Defects, Outcomes, releases, Métricas que se
Kettunen et
deployments, Velocity, Automation (test, release), Métricas más utilizadas por las empresas usan en la 2019
al.
Employee experience, “happy-or-not”, empresa
Predictability, NPS, customer experience
Escaped defects Medir los defectos que existen en el producto entregado. Desempeño
Team member velocity Completitud de las tareas según los compromisos individual de Arumugam
2018
Deliverables Efectividad de entrega dentro del plazo especificado miembros del et al.
Effort Relación de esfuerzos dedicados a la corrección vs esfuerzos para desarrollarlo equipo
Velocity
Lead Time and Cycle Time Producción
Distribution of Waste (bottleneck waste)
Number of Defects
Calidad Indicadores de
Defect Density
rendimiento Ertaban et al. 2018
# of Active Customers Customer Satisfaction ágiles
Refactoring (Technical Debt Ratio), Unit Test
Coverage, Automated Test Case Coverage, Code
Otros indicadores
Quality Issues, Security metrics, Continuous
Integration & Deployment Trends (CI & CD)
Suma del tiempo ideal de sus subtareas, subdefectos, submejoras, subrevisión y
Ideal time of a Product Backlog Item (PBI)
subprueba.
Daily planning
Suma del esfuerzo real de sus subtareas, subdefectos, submejoras, subrevisión y
Effort of a product backlog item
subprueba
Team's Actual Effort on Product Distribución del tiempo dedicado en función de los sprints
En cada etapa de planificación del sprint, los PBI reciben puntos y los puntos totales
Team Velocity
indican qué tan grande es el sprint.
Es mejor que el número estimado de puntos de historia sea similar durante cada plan,
Actual Effort for One Story Point Development
aunque los esfuerzos invertidos en cada PBI pueden variar.
team productivity
El valor comercial es la proporción de PBI cuyos tipos son historia, mejora y cambio de
Innovation Rate Erdogan et
requisitos para todos los PBI en un sprint. 2018
al.
Velocidad del equipo frente a la proporción del tiempo no planificado empleado dentro
Velocity vs Unplanned Effort Rate
del sprint
Identifica valores atípicos extremos que consideran los PBI con el punto de la historia y
Consistency of Relative Estimation
los esfuerzos de cada PBI. Capacidad de
Se implementa para evaluar si existe una correlación entre los puntos de historia, los PBI estimación,
Correlation between Story Point and Actual Effort
y los esfuerzos reales
La asignación de tiempo para las actividades de verificación y prueba se calcula
Actual Effort Rate of Quality Activities
dividiendo el esfuerzo total. El resultado esperado es ver una tendencia creciente Calidad del
Mide la densidad de defectos de los subcomponentes, El objetivo es reducir el tiempo producto
Subcomponent Defect Density
dedicado a los defectos.

7|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Indicador Uso Objetivo Autor Año

Coefficient of Determination Shows how much variation in dependent variable is explained by the regression equation. Estimar el
Coefficient of Variation Percentage expression of the standard error compared to the mean of dependent variable. esfuerzo de
Método utilizado para indicar si la multicolinealidad está presente en un análisis de desarrollo de
Variance Inflation Factor costos de
regresión múltiple.
El error estándar de la estimación es una medida de la diferencia entre el esfuerzo estimadosoftware ágil a
Standard Error Rosa et al 2017
y el observado. través del análisis
del tamaño del
MMRE se define como la media muestral (M) de la magnitud del error relativo (MME). producto,
Mean Magnitude of Relative Error (MMRE) MME es el valor absoluto de la diferencia entre el esfuerzo real y el estimado dividido por personal y
el esfuerzo real. dominio
Total effort consumed in testing calculated as a percentage of total effort consumed in
Testing overhead
code writing.
Total effort consumed in fixing defects calculated as a percentage of total effort consumed
Rework Reducir el Costo
in code writing. Anwar et al. 2016
de desarrollo
Number of found defects that belong to the basic coverage category calculated as a
Leaking-defects rate
percentage of the total number of found defects.
Customer Satisfaction Average rating for a product given by the customer
Delta estimation precision (DEP) The precision of the estimation
Effectiveness (IE) Internal effectiveness
Efficiency (TE) Technical efficiency Cuantificar el
beneficio logrado
Virtual planned hour cost (VPHC) Hours cost considering planned hours Grimaldi et
con la adopción 2016
Virtual actual hour cost (VAHC) Hours cost considering actual hours al.
del modelo
Waste (W) Cost originated from DEP propuesto
Impediments (I) Hours that do not produce a tangible outcome
Delta cost (DC) Cost originated from the virtual hours cost
Test Coverage, Test Debt, Defect Detection
Percentage, Load & Performance, Regression &
Adaptación de
Baseline, Smoke Test, API Test, Production Server
Impact and effectiveness of adapting agile testing pruebas ágiles en Gupta et al 2016
Availability Check, Ping Test, Customer Feedback,
producto legado
User Scaling?, Time to Market, Production Down
Time
Medición de la fase de prueba en Scrum. PBR considera el nivel de complejidad del Medición de la
Product Backlog Rating (PBR)
producto (PCL) y la calificación de evaluación de prueba (TAR) y ofrece una puntuación calidad de las Kayes et al. 2016
numérica pruebas

D. CMMi confirmó mediante el uso de un cuestionario para probar la

En mejoras de procesos y control figuran los estudios de
Utku & Şahin, (2018), quienes definen métricas dentro de un
enfoque basado en CMMi-DEV para desarrollar un modelo de
diversidad de procesos de software en una empresa internacional
basada en CMMi v.2. Los resultados obtenidos mostraron que
estos procesos, implementados en un año, fueron exitosos en
cuanto a aumentar la velocidad y reducir el número de fallas.
Sobre auditoria de procesos Agrawal & Chari, (2020),
utilizan la métrica de esfuerzo de revisión y control de auditoría
de procesos (ARC) para estimar el esfuerzo y defectos en
proyectos de software con datos de 49 proyectos de software de
una organización global de nivel 5 de CMMi. Los resultados
mostraron que hay mayores esfuerzos de auditoria en las fases
de requisitos y construcción de proyectos, lo cual se asocia a un
aumento del esfuerzo general del proyecto.
Khraiwesh, (2020) estudia el proceso de Capacitación
Organizacional de CMMi (OT) , aplicó el modelo Goal Question
Metrics (GQM) a siete objetivos obteniendo métricas que luego
validez y la confiabilidad.
Cenkler (2016) por su parte, estudia la evolución de las
métricas de procesos y productos de una organización que
desarrolla software en la industria de defensa, el objetivo era
satisfacer los requisitos de la certificación CMMi-Development
e ISO 9001, para ello define métricas de procesos y productos
con el propósito de recopilar datos, hacer análisis y tomar
decisiones. Con este estudio se pudo detectar debilidades como
la falta de claridad em los objetivos de negocio y el esfuerzo
inútil en recopilar 52 métricas, ya que muchas de ellas no
aportaban al objetivo deseado. Debido a ello las métricas
evolucionaron a solo 39, lo que trajo efectividad al proceso. En
la Tabla IV se presenta las métricas identificadas en los estudios
sobre CMMi.

TABLE IV. MÉTRICAS UTILIZADAS EN ESTUDIOS CMMI SELECCIONADOS

Indicador Uso Objetivo Autor Año
Proporcionar Agrawal & 2020
Aseguramiento de la calidad de procesos y información sobre Chari
Esfuerzo de revisión y control de auditoría de procesos (ARC)
producto (PPQA) procesos y productos de
trabajo asociados
Puntos de función Tamaño del proyecto Revisión y control de
Incluye el esfuerzo desde la recopilación auditoría en proyectos
El esfuerzo de desarrollo de software de requisitos, diseño, codificación, pruebas
y test de aceptación
Esfuerzo de revisión y control de auditoría de procesos (ARC) Porcentaje del esfuerzo total del proyecto
para cada fase asignado a las auditorías por fase

8|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Indicador Uso Objetivo Autor Año

Recuentos de defectos entregados al
Calidad del software
cliente
Total number of days Evaluar las fallas y la Utku & Şahin 2018
Number of days’ delay velocidad al final del
Planned person days proyecto.
Realized person days
Daily average closed
Número de fallas al final del proyecto y
Person days
mejora en la velocidad.
Number of analysis test faults
Number of approved set faults
Approved set workdays
Number of approved
Set faults per day
Análisis del valor Ganado Gestión de proyectos Métricas que Cenkler 2016
Eficacia de mitigación de riesgos en el proyecto Gestión de riesgos evolucionaron producto
Puntaje de satisfacción del desempeño para subcontratistas, Administración de subcontratos del estudio de caso
Métricas en el área de desarrollo de
Volatilidad de requisitos de software
productos:
Puntaje de satisfacción del cliente que incluye tema de costo, Métricas en el área de satisfacción del
cronograma y relaciones con STM cliente
Proporción de acciones correctivas para los incumplimientos del
Métricas en el área de garantía de calidad:
proceso evaluados como efectivos
Número de entrenamiento efectivo por persona Métricas en el área de entrenamiento:

revisar los factores de gestión de incidentes, además de

E. 4.3 ITIL
En relación a las métricas para medir el desempeño Barcelo-
Valenzuela & Leal-Pompa, (2020), presentan una adaptación
metodológica ITSM de ITIL, proporcionando indicadores útiles
y procedimientos operativos estandarizados para que un
departamento de TI sea capaz de medir su desempeño.
Proporcionan 18 métricas en base a informes de servicio y
proceso de mejora continua. Concluyen con un caso de estudio
en un organismo electoral, con una mejora del 88% en tiempos
de respuesta a solicitudes de servicio.
Yamami et al., (2017), muestran un enfoque con varios
criterios para evaluar el desempeño de los servicios TI en una
Pyme, el modelo utiliza una combinación del proceso de
jerarquía analítica (AHP) y la Técnica de Orden de Preferencia
por Semejanza a Soluciones Ideales (TOPSIS), en el proceso se
describen 12 indicadores claves del desempeño de procesos
ITIL.
Fiegler et al., (2016), introducen dos métricas: la tasa de
aprendizaje de operación y la de entropía del sistema. Ambas
métricas se utilizan para evaluar la calidad de los procesos de
gestión de servicios TI en los entornos de hosting, los resultados
mostraron que las métricas esperadas fueron confirmadas en 2
de 3 entornos reales. Esto beneficiaría la capacidad de control y
el cumplimiento de los SLA en entornos de nube, que siempre
tiene dinamismo en sus tasas de crecimiento.
En lo relacionado a gestión de incidencias, Nugraha &
Legowo, (2017), evalúan dicho proceso en una corporación de
telecomunicaciones, obteniendo cuatro métricas que permiten
observaciones a los procesos con fines de mejora.
Para el logro de objetivos comerciales, Mitev & Kirilov,
(2021) proponen una metodología de selección de métricas
basada en un enfoque de toma de decisiones en grupo para
evaluar su relevancia. Como caso de estudio uso se evaluó la
calidad del servicio de correo electrónico de una universidad a
través de 18 métricas que hicieron seguimiento a la
disponibilidad, requerimientos, incidentes, cambios y
capacidad.
Bustamante et al., (2017), exponen métricas como resultado
de un año de mejora continua, en un estudio realizado en una
planta industrial que necesitaba adaptar marcos de TI como
COBIT, PMI-PMBOK, ITIL y NIST para proteger a las
empresas industriales y manufactureras contra las interrupciones
y actividades maliciosas de TI. Los resultados obtenidos
indicaron una mejora en la reducción de incidentes y gestión
holística, además de alineamiento a los objetivos estratégicos sin
dejar de cumplir el control de seguridad de la información.
Por último, Baradari et al., (2021), identifican la relación
entre IT Service management (ITSM) y knowledge management
(KM) con el fin de establecer una base para el diseño de un
sistema integrado, enfocándose en procesos de ITSM de
configuración, cambios, release, incidentes y problemas,
listando un total de 44 métricas, y aplicando mapa cognitivo
difuso para hallar relaciones e indicadores importantes para la
óptima gestión de los procesos de ITSM. Como resultado de esta
práctica se puede seleccionar las actividades de KM que mejor
se adecuen a las necesidades de las actividades de ITSM que se
requiera. En la Tabla V se detalla la relación de métricas ITIL
encontradas en literatura.

TABLE V. MÉTRICAS UTILIZADAS EN ESTUDIOS ITIL SELECCIONADOS

9|P age
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Indicador Uso Objetivo Autor Año

Incident Evaluar el
Baradari
KPI IM-01 Percentage of incidents closed by the service desk management desempeño de los
et al
procesos ITIL
KPI IM-02 Mean Time to Resolution
KPI IM-03 Percentages of reduction in total number of incidents
KPI IM-04 Percentages of reduction in number of Major incidents
KPI IM-05 Percentages of user satisfaction from quality of services
KPI IM-06 Number of user complaints from quality of services
KPI IM-07 Percentage of incidents handled within agreed SLA target
KPI IM-08 Percentage of incidents related to changes and releases.
KPI IM-09 percentage of incidents incorrectly assigned
KPI IM-10 Average cost per incident (COSTO PROMEDIO POR
INCIDENTE)
KPI PM-01 The number of known errors added to the KEDB
KPI PM-02 Percentage of incidents closed by the service desk
KPI PM-03 Average incident resolution time for those incidents linked to
problem records
KPI PM-04 Total numbers of problems
KPI PM-05 Size of current problem backlog for each IT service Problem management
KPI PM-06 Number of repeat incidents for each IT service
KPI PM-07 Number and percentage of problems incorrectly assigned
KPI PM-08 Percentage of problems closed successfully
KPI PM-09 Size of current problem backlog for each IT service
KPI PM-10 Average cost per problem
KPI CHM-01 Increase in the percentage of changes that meet the customer’s
agreed requirements
KPI CHM-02 Reduction in the backlog of change requests
KPI CHM-03 Increase in accuracy of predictions for time, quality, cost, risk,
resource and commercial impact
KPI CHM-04 Increase in change success rate
KPI CHM-05 Reduction in the percentage of changes lead to service Change management
disruption
KPI CHM-06 Reduction in the percentage of emergency changes 2021
KPI CHM-06 Reduction in the number of unauthorized changes identified
KPI CHM-07 number of incidents attributed to changes
KPI CHM-08 Reduction in the number and percentage of changes with
incomplete change specifications
KPI CM-01 Reduction in business impact of outages caused by poor
configuration management
KPI CM-02 Improvement in time to identify poor performing and poor-
quality Cis
KPI CM-03 Reduction in the average time and cost of diagnosing and
resolving incidents and problems Configuration management
KPI CM-04 Increase in reuse and redistribution of under- utilized CIs
KPI CM-05 Reduced number of exceptions reported during configuration
audits
KPI CM-06 Reduced percentage of changes not completed successfully
because of poor impact assessment, incorrect data in the CMS, or poor version
control
KPI RM-01 Increased number and percentage of releases that meet customer
expectations
KPI RM-02 Reduced number of deployments from sources other than the
KPI RM-03 Decreased customer dissatisfaction of service issues resulting
from poorly tested or untested services (DISMINUCION DE LA
INSATISFACCION DEL CLIENTE)
KPI RM-04 Increased customer and user satisfaction with the services
delivered Release Management
KPI RM-05 Reduced number of incidents due to incorrect components being
deployed
KPI RM-06 Reduced number of incidents of new releases due to incorrect
testing
KPI RM-07 Increased percentage of incidents solved by level 1 and level 2
support
KPI RM-08 Reduced resources and costs to diagnose and fix incidents and
problems in deployment and live use
Uptime percentage of the service PORCENTAJE DE TIEMPO DE ACTIVIDAD DEL Service Evaluación de la Mitev &
2021
SERVICIO) availability calidad del servicio Kirilov

10 | P a g e
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Indicador Uso Objetivo Autor Año

de correo
electrónico
Count of complete unplanned service outages
Count of service degradation events
Average time for completing the service requests
Percentage of service requests completed within the agreed SLA
Service request management
Percentage of service requests completed within one shot
Percentage of complaints
Average time for starting work on case
Average time for resolution
Percentage of incidents resolved within the SLA timeframes
Incident management
Percentage of incidents completed within one shot
Percentage of incidents with proper initial assessment
Percentage of complaints
Percentage of successful changes
Number of failed changes Change management
Number of unauthorized changes
Consumed disc storage per user
Capacity
Supported user per FTE
Barcelo-
Service
Valenzue
# of services portfolio Planning
la & Leal-
management
Pompa
# of services (CATALOGADOS) Service catalogue management
# of unavailability incidents
Service level Management
# of lack of capacity incidents
Information security
# of preventive measures implemented
management
Transition planning and
# of service requests
support
# of changes per service
# of non- planned changes per service Change management Transition 2020
% of deadlines compliance
Release and deployment
% of successful service deployment
management
# of service or incident requests
# of' to attend' requests
# of 'in process' requests
# of 'completed' requests Incident management
# of requests per type Evaluation
% of requests per type
% of requests per priority
# of KPI's implemented Continual improvement process
Weekly reports Service reports
Indicadores de
Number of incidents, Rate of incidents resolved remotely, Incident resolution time, Rate of Incident Yamami
desempeño claves
incidents resolved within SLA management et al
de ITIL
Number of problems, Problem Resolution Time, Rate of unresolved 2017
Problem management
problems, Rate of proactively problem solved
Change accepted rate, Rate of emergency changes, Time for change
Change management
Approval/Rejection, Rate of unsuccessfully realized changes
Total de
incidentes Métricas de Nugraha
Total Number of Incident completados procesos de gestión &
como medida de incidentes Legowo
de control
Porcentaje de problemas
Percentage of Trouble handled within target resolution time manejados dentro del tiempo de
respuesta objetivo 2017
Duración promedio desde la
creación hasta el cierre de los
Average duration of trouble tickets by priority
tickets de problemas de cada
prioridad.
Número de Tickets que FO
First time restoration restaura por primera vez después
de abrir
ITIL en cloud Evaluate the quality Fiegler et
System operation learning 2016
con DevOps of IT service al

11 | P a g e
E-ISSN: 2415-1513
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12
Indicador
System entropy rate
V. DISCUSIÓN DE RESULTADOS
El ámbito Scrum, mostrado en un entorno comparativo con
ITIL y CMMI es mucho más utilizado. La cantidad de artículos
a las que hace referencia este trabajo así lo demuestra, 64% son
estudios Scrum, versus 23% de ITIL y 13% de CMMi, lo que
comprueba lo sostenido por Sharma & Hasteer, (2016) y Zaouali
& Ghannouchi, (2020), indicando que Scrum es la práctica más
utilizada actualmente, nosotros agregaríamos que es la práctica
que tiene mayor cantidad de métricas llegando a 38% /112
métricas), frente a 33% de ITIL (98 métricas) y 29% de CMMi
(87 métricas), los nuevos avances dentro del modelo Scrum
comienzan a seccionar la practica en varios modos, a unificarse
con otros modelos o a especializarse.
Edison et al., (2021) sostiene que el desafío actual es diseñar
e implementar variantes de esta agilidad a gran escala y en toda
la organización para la cohesión con otros equipos y alinearse
con otras prácticas. Tuncel et al., (2020) sostiene que los
estudios de madurez de desarrollo ágil aún se encuentran en sus
primeras fases, por lo que es importante profundizar métodos al
respecto.
Por otro lado, CMMi también se está adaptando a
ecosistemas con diferentes tipos de prácticas, con agilidad
(Anwar et al., 2016), ISO 9001 (Cenkler, 2016), PSP y TSP
(Cerón & Arboleda, 2018) u otras prácticas, la incursión de
CMMi se encuentra mayormente ligado a empresas
consolidadas, no se ha encontrado estudios sobre métricas
CMMi en Pymes.
Por su parte ITIL cuenta en la mayoría de casos con una
fuerte integración con otros modelos como COBIT o Balanced
Scorecad, de las cuales obtiene métricas, por lo que algunos
documentos que contenían excelentes estudios ITIL no fueron
considerados debido a que se realizan enfoques de ecosistema
colocando métricas de otro tipo de prácticas ajenas a ITIL.
Respecto a la calidad de métricas, se está conservando la
propuesta de definición y objetivo original de los autores, sin
embargo, hay algunas métricas que para algunos autores se
catalogan diferente: para citar un ejemplo el Burndown Chart
(Kayes et al., 2016) lo considera artefacto indicador, mientras
que (Carneiro et al., 2019), (Tekin et al., 2020) lo incluyen como
parte de su relación de métricas utilizadas.
VI. LIMITACIONES
Se han obviado artículos que no cuentan con referencia que
indique el tipo de empresa en la que se hizo el caso de estudio u
otros documentos de aspecto teóricos o exploratorio que no
consideraron casos de estudio; en otros tantos artículos que no
consignan el país de referencia de la experimentación, se ha
colocado país del primer autor del artículo, iguales exclusiones
obtuvieron los artículos que no referenciaban tácitamente las
métricas utilizadas. Por otro lado, algunos autores no citan todos
los tipos de métricas utilizadas en sus prácticas realizadas, sino
algunos ejemplos de métricas o métricas de resumen general,
E-ISSN: 2415-1513
Uso Objetivo Autor Año
management
processes
Otros autores nombran las métricas en su fase teórica, pero en
sus listados de cuadro de utilización final no nombran dichas
métricas, por lo que no son consideradas. Respecto a las
empresas donde se referencian los casos de uso realizados, hay
una fuerte orientación de utilizar estas prácticas en tecnología,
en algunos estudios no referenciados se hizo uso de Scrum no
ligado a tecnología, dichos estudios se alejaban del aporte
centrado en tecnología que deseábamos dar al presente
documento, por lo que no fueron considerados.
VII. CONCLUSIONES
Contar con métricas es de vital importancia si uno quiere
medir el avance de los procesos. En este artículo se ha conducido
una revisión de literatura para identificar las métricas en Scrum,
CMMi e ITIL, se identificaron un total de 297 métricas, 38%
son Scrum (112 métricas), 33% son de ITIL (98 métricas) y 29%
son de CMMi (87 métricas). En cuanto a las empresas donde se
utilizaron las métricas referenciadas, figuran mayormente
empresas europeas (35%), con una clara inclinación a empresas
de tendencia tecnológica (45%) seguidas de empresas de
gobierno (19%) y de sectores diversos (13%).
En el caso de Scrum, la mayor tendencia de métricas
expuestas reside en aquella que se utilizaron con fines de gestión
ágil de software (33%, 59 métricas), seguida de aquellas que se
utilizaron para gestión ágil de la calidad (21%, 38 métricas),
muy cerca de esta cantidad figuran aquellas métricas que se
utilizaron para controlar los costos o valor de entrega al cliente
(17%, 31 métricas). En el caso de CMMi, destacan las métricas
de formación en la organización con 75% (65 métricas), seguida
muy de lejos por monitorización y control de proyectos con 14%
(12 métricas). En lo que respecta a métricas ITIL, los 3 tipos de
objetivo con más cantidad de métricas son: Gestión de
incidentes con 29% (31 métricas), gestión de cambios con 18%
(19 métricas) y gestión de problemas con 13% (14 métricas).
Por otro lado, dentro de los avances en investigación en
Scrum, resaltan nuevos enfoques para medición orientado a
gestión de evidencias (Shirokova et al., 2020), toma de
decisiones de varios criterios (Tekin et al., 2020), ROI y costos
(Chavarria & Madriz, 2019), (Rosa et al., 2017), gestión de
desperdicios (Bufon & Leal, 2019) y cultura ágil (Gadelsied et
al., 2021). Otros autores muestran la búsqueda de mejores
métricas en base a encuestas y estudios de datos (Kettunen et al.,
2019), (Kovags et al., 2019), (Arumugam et al., 2018), enfoque
en mejorar los procesos Scrum (Carneiro et al., 2019), (Ertaban
et al., 2018), (Erdogan et al., 2018) y (Grimaldi et al., 2016);
gestión de portafolio (Stettina & Schoemaker, 2018), gestión de
requisitos (Pinto et al., (2018) gestión de pruebas (Gafurov &
Hurum, 2020), (Tudjarova et al., 2017), (Kayes et al., 2016). En
adopción ágil y sistemas heredados tenemos los trabajos de
Anwar et al., (2016) y Gupta et al., (2016), por ultimo figura el
estudio de Marek et al., (2021), enfocado en desarrollo ágil en
pandemia por Covid 19.
Para el caso de CMMi, los estudios muestran avances
orientados a la mejora de procesos (Utku & Şahin, 2018),
12 | P a g e
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12
auditoria de procesos (Agrawal & Chari, 2020), certificación
(Cenkler, 2016) y Capacitación Organizacional (Khraiwesh,
2020).
En relación a los estudios hallados de ITIL se exponen
métricas en adaptación de ITIL para el desempeño (Barcelo-
Valenzuela & Leal-Pompa, 2020), (Yamami et al., 2017),
monitorear la calidad de los servicios (Fiegler et al., 2016),
gestionar incidencias (Nugraha & Legowo, 2017), elegir
objetivos comerciales (Mitev & Kirilov, 2021), gestionar
interrupciones maliciosas (Bustamante et al., 2017) y relacionar
ITSM con knowledge management (Baradari et al., 2021).
Como trabajo futuro se desarrollará un framework de
métricas basadas en CMMi, Scrum e ITIL, para mejorar el
desempeño de una organización privada.
REFERENCES
[1] Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2017). Agile
Software Development Methods: Review and Analysis
(arXiv:1709.08439). arXiv. https://doi.org/10.48550/arXiv.1709.08439
[2] Agrawal, M., & Chari, K. (2020). Impacts of process audit review and
control efforts on software project outcomes. IET Software, 14(3), 293–
299. https://doi.org/10.1049/iet-sen.2019.0185
[3] Ahmed, A. R., Tayyab, M., Bhatti, S. N., Alzahrani, A. J., & Babar, M. I.
(2017). Impact of Story Point Estimation on Product using Metrics in
Scrum Development Process. International Journal of Advanced
Computer Science and Applications, 8(4), 385–391.
[4] Amer, S. K., Badr, N., & Hamad, A. (2020). Combining CMMI Specific
Practices with Scrum Model to Address Shortcomings in Process
Maturity. In A. E. Hassanien, A. T. Azar, T. Gaber, R. Bhatnagar, & M.
F. Tolba (Eds.), The International Conference on Advanced Machine
Learning Technologies and Applications (AMLTA2019) (pp. 898–907).
Springer International Publishing. https://doi.org/10.1007/978-3-030-
14118-9_88
[5] Anwar, A., Kamel, A. A., & Ahmed, E. (2016). Agile adoption case study,
pains, challenges & benefits. 28-29-May-2016, 60–65. Scopus.
https://doi.org/10.1145/2944165.2944175
[6] Arumugam, C., Vaidayanthan, S., & Karuppuchamy, H. (2018). Global
software development: Key Performance measures of team in a SCRUM
based agile environment. Lecture Notes in Computer Science (Including
Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in
Bioinformatics), 10963 LNCS, 672–682. Scopus.
https://doi.org/10.1007/978-3-319-95171-3_53
[7] Baradari, I., Shoar, M., & Nezafati, N. (2021). Defining the relationship
between IT Service management and knowledge management: Towards
improved performance. Knowledge Management Research and Practice.
Scopus. https://doi.org/10.1080/14778238.2021.1903349
[8] Barcelo-Valenzuela, M., & Leal-Pompa, C. M. (2020). An ITSM
framework adaptation: Case study in an electoral institution. 468–473.
Scopus. https://doi.org/10.1109/CDS49703.2020.00098
[9] Bayona, S., Calvo-Manzano, J. A., & San Feliu, T. (2013, June). Review
of critical success factors related to people in software process
improvement. In European Conference on Software Process
Improvement (pp. 179-189). Springer, Berlin, Heidelberg.
[10] Bufon, M. T., & Leal, A. G. (2019). Method for identification of waste in
the process of software development in agile teams using lean and scrum.
Communications in Computer and Information Science, 1027, 466–476.
Scopus. https://doi.org/10.1007/978-3-030-21451-7_40
[11] Bundschuh, M., & Dekkers, C. (2008). Software Measurement and
Metrics: Fundamentals. In The IT Measurement Compendium (pp. 179–
206). Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-
68188-5_7
[12] Bustamante, F., Fuertes, W., Diaz, P., & Toulkeridis, T. (2017).
Integration of IT frameworks for the management of information security
within industrial control systems providing metrics and indicators.
Proceedings of the 2017 IEEE 24th International Congress on Electronics,
E-ISSN: 2415-1513
Electrical Engineering and Computing, INTERCON 2017. Scopus.
https://doi.org/10.1109/INTERCON.2017.8079672
[13] Carneiro, L. B., Silva, A. C. C. L. M., & Alencar, L. H. (2019). Scrum
Agile Project Management Methodology Application for Workflow
Management: A Case Study. 2019-December, 938–942. Scopus.
https://doi.org/10.1109/IEEM.2018.8607356
[14] Cenkler, Y. (2016). Evolution of Process Product Metrics Based on
Information Needs. 2016 10th International Conference on the Quality of
Information and Communications Technology (QUATIC), 143–145.
https://doi.org/10.1109/QUATIC.2016.036
[15] Cerón, K. J., & Arboleda, H. F. (2018). Model of strategic relationships
between organizational and technical factors in colombian software
factories. Informacion Tecnologica, 29(3), 29–38. Scopus.
https://doi.org/10.4067/S0718-07642018000300029
[16] Chavarria, R. C., & Madriz, F. L. (2019). Roi estimation in a scrum
project: A case study. 64, 78–87. Scopus. https://doi.org/10.29007/nqq6
[17] Chavarría, A. E., Oré, S. B., & Pastor, C. (2016). Aseguramiento de la
Calidad en el Proceso de Desarrollo de Software utilizando CMMI, TSP
y PSP/Quality Assurance in the Software Development Process using
CMMI, TSP and PSP. Revista Ibérica de Sistemas e Tecnologias de
Informação, (20), 62.
[18] Edison, H., Wang, X., & Conboy, K. (2021). Comparing Methods for
Large-Scale Agile Software Development: A Systematic Literature
Review. IEEE Transactions on Software Engineering. Scopus.
https://doi.org/10.1109/TSE.2021.3069039
[19] Erdogan, O., Pekkaya, M. E., & Goek, H. (2018). More effective sprint
retrospective with statistical analysis. Journal of Software-Evolution and
Process, 30(5), e1933. https://doi.org/10.1002/smr.1933
[20] Ertaban, C., Sarikaya, E., & Bagriyanik, S. (2018). Agile performance
indicators for team performance evaluation in a corporate environment.
Part F147763. Scopus. https://doi.org/10.1145/3234152.3234156
[21] Fiegler, A., Zwanziger, A., Herden, S., & Dumke, R. R. (2016). Quality
Measurement of ITIL Processes in Cloud Systems. 2016 Joint Conference
of the International Workshop on Software Measurement and the
International Conference on Software Process and Product Measurement
(IWSM-MENSURA), 87–94. https://doi.org/10.1109/IWSM-
Mensura.2016.022
[22] Fitzgerald, B. (2018). Software Crisis 2.0. In Software Technology: 10
Years of Innovation in IEEE Computer (pp. 1–16). IEEE.
https://doi.org/10.1002/9781119174240.ch1
[23] Gacenga, F., & Cater-steel, A. (2011). Performance Measurement Of IT
Service Management: A Case Study Of PERFORMANCE
MEASUREMENT OF IT SERVICE MANAGEMENT: A CASE
STUDY OF AN AUSTRALIAN.
[24] Gadelsied, A. O., Elhassan, T. M. M., Mohamed, W. M., & Abushama,
H. M. (2021). Assessment method for Scrum culture within the
Development team. 2020 International Conference on Computer, Control,
Electrical, and Electronics Engineering (ICCCEEE), 1–6.
https://doi.org/10.1109/ICCCEEE49695.2021.9429608
[25] Gafurov, D., & Hurum, A. E. (2020). Efficiency Metrics and Test Case
Design for Test Automation. 2020 IEEE 20th International Conference on
Software Quality, Reliability and Security Companion (QRS-C), 15–23.
https://doi.org/10.1109/QRS-C51114.2020.00015
[26] Grimaldi, P., Perrotta, L., Corvello, V., & Verteramo, S. (2016). An agile,
measurable and scalable approach to deliver software applications in a
large enterprise. International Journal of Agile Systems and Management,
9(4), 326–339. Scopus. https://doi.org/10.1504/IJASM.2016.081561
[27] Gupta, R. K., Manikreddy, P., & GV, A. (2016). Challenges in Adapting
Agile Testing in a Legacy Product. 2016 IEEE 11th International
Conference on Global Software Engineering (ICGSE), 104–108.
https://doi.org/10.1109/ICGSE.2016.21
[28] Kaner, C., & Bond, W. P. (2004). Software Engineering Metrics: What
Do They Measure and How Do We Know? Undefined.
https://www.semanticscholar.org/paper/Software-Engineering-
Metrics%3A-What-Do-They-Measure-Kaner-
Bond/7e63e256311e956093f9bea27456bc4e7206325a
[29] Kayes, I., Sarker, M., & Chakareski, J. (2016). Product backlog rating: A
case study on measuring test quality in scrum. Innovations in Systems and
13 | P a g e
 WSEAS TRANSACTIONS on ELECTRONICS DOI: 10.37394/232017.2022.13.12

Software Engineering, 12(4), 303–317. Scopus. oversight. Lecture Notes in Business Information Processing, 314, 199–
https://doi.org/10.1007/s11334-016-0271-0 215. Scopus. https://doi.org/10.1007/978-3-319-91602-6_14
[30] Kettunen, P., Laanti, M., Fagerholm, F., & Mikkonen, T. (2019). Agile in [48] Sussy, B. L., Antonio, C. M. J., Gonzalo, C., Tomás, S. F., & Angel, S.
the Era of Digitalization: A Finnish Survey Study. Lecture Notes in (2008). Process deployment in a multi-site CMMI level 3 organization: a
Computer Science (Including Subseries Lecture Notes in Artificial case study. In Computer and Information Science (pp. 147-156).
Intelligence and Lecture Notes in Bioinformatics), 11915 LNCS, 383– Springer, Berlin, Heidelberg
398. Scopus. https://doi.org/10.1007/978-3-030-35333-9_28 [49] Sydenham, P. H. (2003). Relationship between measurement, knowledge
[31] Khraiwesh, M. (2020). Measures of Organizational Training in the and advancement. Measurement, 34(1), 3–16.
Capability Maturity Model Integration (CMMI). International Journal of https://doi.org/10.1016/S0263-2241(03)00023-X
Advanced Computer Science and Applications, 11(2), 584–592. [50] Tahir, T., & Gencel, C. (2010). A structured goal based measurement
[32] Kitchenham, B. (2004). Procedures for Performing Systematic Reviews framework enabling traceability and prioritization. 2010 6th International
(Joint Technical Report). Software Engineering Group, Department of Conference on Emerging Technologies (ICET), 282–286.
Computer Science, Keele University and Empirical Software Engineering https://doi.org/10.1109/ICET.2010.5638475
National ICT Australia Ltd. [51] Tekin, N., Kosa, M., Yilmaz, M., Clarke, P., & Garousi, V. (2020).
https://scholar.google.es/scholar?hl=es&q=procedures+for+performing+ Visualization, Monitoring and Control Techniques for Use in Scrum
systematic+reviews&btnG=&lr=&oq=procedures+for+per Software Development: An Analytic Hierarchy Process Approach.
[33] Kovags, D., Falchi, F. L., & Rivas, A. R. (2019). Analysis of the Communications in Computer and Information Science, 1251 CCIS, 45–
utilization of scrum framework effort estimation metrics in federal public 57. Scopus. https://doi.org/10.1007/978-3-030-56441-4_4
administration. ACM International Conference Proceeding Series. [52] The Institute of Electrical and Electronics Engineers. (1990). IEEE
Scopus. https://doi.org/10.1145/3364641.3364645 Standard Glossary of Software Engineering Terminology. IEEE Std
[34] Marek, K., Wińska, E., & Dąbrowski, W. (2021). The State of Agile 610.12-1990, 1–84. https://doi.org/10.1109/IEEESTD.1990.101064
Software Development Teams During the Covid-19 Pandemic. Lecture [53] Tudjarova, S., Chorbev, I., & Joksimoski, B. (2017). Software Quality
Notes in Business Information Processing, 408, 24–39. Scopus. Metrics While Using Different Development Methodologies.
https://doi.org/10.1007/978-3-030-67084-9_2 Communications in Computer and Information Science, 778, 240–250.
[35] Mauro, V., & Messina, A. (2016). AMINSEP-agile methodology Scopus. https://doi.org/10.1007/978-3-319-67597-8_23
implementation for a new software engineering paradigm definition. A [54] Tuncel, D., Körner, C., & Plösch, R. (2020). Comparison of Agile
research project proposal. Communications in Computer and Information Maturity Models: Reflecting the Real Needs. 51–58.
Science, 422, 27–33. Scopus. https://doi.org/10.1007/978-3-319-27896- https://doi.org/10.1109/SEAA51224.2020.00019
4_3
[55] Utku, S., & Şahin, S. (2018). Process diversity in software development:
[36] Mitev, Y., & Kirilov, L. (2021). Group Decision Support for e-Mail An industrial study. IET Software, 13(4), 260–267.
Service Optimization through Information Technology Infrastructure https://doi.org/10.1049/iet-sen.2018.5079
Library Framework. 227–230. Scopus. https://doi.org/10.15439/2021F93
[56] Yamami, A. E., Mansouri, K., Qbadou, M., & Illousamen, E. H. (2017).
[37] Mohsen, W., Aref, M., & ElBahnasy, K. (2017). Software metrics for Multi-criteria decision making approach for ITIL processes performance
cooperative scrum based ontology analysis. 2017 2nd International evaluation: Application to a Moroccan SME. 2017 Intelligent Systems
Conference on Knowledge Engineering and Applications (ICKEA), 60– and Computer Vision (ISCV), 1–6.
70. https://doi.org/10.1109/ICKEA.2017.8169903 https://doi.org/10.1109/ISACV.2017.8054937
[38] Nugraha, A. D., & Legowo, N. (2017). Implementation of incident [57] Zaouali, S., & Ghannouchi, S. A. (2020). Quality assessment in scrum
management for data services using ITIL V3 in telecommunication software development through Metrics: A conceptualization using
operator company. 2017 International Conference on Applied Computer concept maps. 161–166. Scopus.
and Communication Technologies (ComCom), 1–6.
https://doi.org/10.1109/COMCOM.2017.8167093
[39] Pinto, N., Tortosa, N., Geat, B. C., Ibáñez, L., & Bollati, V. (2018).
Quality Evaluation of Agile Processes: Measurement of Requirements
Management Using AQF v2. 15–20.
https://doi.org/10.1109/QUATIC.2018.00013
[40] Rosa, W., Madachy, R., Clark, B., & Boehm, B. (2017). Early Phase Cost
Models for Agile Software Processes in the US DoD. 30–37.
https://doi.org/10.1109/ESEM.2017.10
[41] Sánchez, R., & Luis, J. (2021). Model to Optimize the Decision Making
on Processes in IT Departments. Mathematics, 9(9), 983.
https://doi.org/10.3390/math9090983
[42] Sharma, S., & Hasteer, N. (2016). A comprehensive study on state of
Scrum development. 2016 International Conference on Computing,
Communication and Automation (ICCCA), 867–872.
https://doi.org/10.1109/CCAA.2016.7813837
[43] Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-
US.pdf
[44] Shirokova, S., Kislova, E., Rostova, O., Shmeleva, A., & Tolstrup, L.
(2020). Company efficiency improvement using agile methodologies for
managing IT projects. ACM International Conference Proceeding Series.
Scopus. https://doi.org/10.1145/3446434.3446465
[45] Software Engineering Institute. (2010). CMMI® para Servicios, Versión
1.3.
[46] Steinberg, R. A. (2011). ITIL Service Operation (2011 ed. edition). The
Stationery Office.
[47] Stettina, C. J., & Schoemaker, L. (2018). Reporting in agile portfolio
management: Routines, metrics and artefacts to maintain an effective

14 | P a g e
E-ISSN: 2415-1513