Analisis de Los Criterios para La Seleccion de Una Metodologia Agil de Desarrollo de Software

Universidad Veracruzana Facultad de Contaduría y Administración
Región Coatzacoalcos-Minatitlán
Licenciatura en Ingeniería de software
Análisis de los criterios para la selección de una

metodología ágil de desarrollo de software
Modalidad Tesina para acreditar la Experiencia recepcional
Presenta:
Gabriel Garcia Alor
Director(a) del trabajo recepcional:

José Antonio Vergara Camacho
Noviembre de 2021
“Lis de Veracruz: Arte, Ciencia, Luz”

Universidad Veracruzana
Universidad Veracruzana
Región Coatzacoalcos-Minatitlán
Licenciatura en Ingeniería de software
Análisis de los criterios para la selección de una metodología ágil de desarrollo de software
Modalidad Tesina para acreditar la Experiencia recepcional
Presenta:
Gabriel Garcia Alor
Director del trabajo recepcional:

José Antonio Vergara Camacho
Agregar académico (s) participante (s) y su función

Dedicatoria
Quiero dedicar este trabajo a Dios, ya que gracias a él he podido enfrentar todas las
adversidades presentadas a lo largo de mi vida, me ha permitido llegar hasta esta última etapa
de mi trayectoria académica con su sabiduría y misericordia, me ha dado a unos padres
maravillosos que me criaron y me educaron para que me convirtiera en una persona de bien
y preparada, me han guiado y apoyado con su conocimiento, experiencia y amor para cumplir
todas las metas que me he propuesto a lo largo de mi vida. También me ha dado unos tíos
ejemplares que me apoyaron para terminar mi carrera cuando mis padres ya no tenían la
posibilidad de hacerlo y que siempre han estado presentes y visto por nosotros cuando más
lo hemos necesitado.
Así mismo quiero dedicarle este trabajo a mis profesores y a mi director de tesis, ya
que con su conocimiento y experiencia me han preparado para que enfrente con éxito mi
trayectoria laboral y me han permitido concluir este trabajo de investigación con su guía y
sus consejos, también quiero agradecerles por el tiempo que estuvieron con nosotros para
enseñarnos y prepararnos para nuestra nueva aventura, así como también por resolver las
dudas presentadas a lo largo de la carrera.
Agradecimientos
A Dios
Por darme la oportunidad de cumplir esta meta que me propuse al iniciar mis estudios, por
darme también el conocimiento necesario para poder cumplir con mi objetivo y por ayudarme
a enfrentar las dificultades presentadas.
A mis padres
Por el sacrificio que hicieron para poder darme estudios, por estar presentes en todo momento
cuando los necesitaba, por enseñarme con su guía, sus consejos y su experiencia como
enfrentar las situaciones adversas y seguir adelante sin rendirme.
A mis tíos
Por apoyarme para terminar mi carrera cuando mis padres se vieron en una necesidad grande,
por ayudar a mi familia en tiempos de necesidad y mostrarme que la familia es muy
importante y debemos apoyarnos entre nosotros.
A mis maestros
Por guiarme y prepararme durante toda la carrera para que sea un ingeniero con los
conocimientos necesarios para poder enfrentar el ámbito laboral de manera exitosa, les
agradezco de todo corazón por compartirme sus conocimientos y experiencia para poder
defenderme en mi trayecto profesional.
A mis hermanos y amigos
Por estar a mi lado durante toda mi trayectoria académica, apoyarme cuando se presentaba
algún problema, por sus consejos y por darme las herramientas necesarias para poder concluir
mis estudios.
Índice
Introducción ............................................................................................................................ 4
Capítulo 1. Generalidades de las metodologías ágiles de desarrollo de software .................. 6
1.1 Ingeniería de software ................................................................................................... 7
1.1.1 Antecedentes .......................................................................................................... 7
1.1.2 Concepto................................................................................................................. 8
1.1.3 Proceso de software ................................................................................................ 9
1.2 Metodologías de desarrollo de software ..................................................................... 11
1.2.1 Antecedentes ........................................................................................................ 11
1.2.2 Concepto............................................................................................................... 12
1.2.3 Clasificación ......................................................................................................... 13
1.3 Metodologías tradicionales ......................................................................................... 13
1.3.1 Concepto............................................................................................................... 13
1.3.2 Clasificación ......................................................................................................... 14
1.4 Metodologías ágiles .................................................................................................... 15
1.4.1 Antecedentes ........................................................................................................ 15
1.4.2 Introducción ......................................................................................................... 15
1.4.3 Scrum ................................................................................................................... 19
1.4.4 Extreme Programming ......................................................................................... 22
1.4.5 Crystal Clear ......................................................................................................... 28
1.4.6 Método de desarrollo de sistemas dinámicos ....................................................... 32
1.5 Ventajas ...................................................................................................................... 39
1.6 Desventajas ................................................................................................................. 40
Capítulo 2. Criterios para la selección de metodologías ágiles para un mejor proceso de
desarrollo de software. .......................................................................................................... 41
2.1 Criterios de selección de metodologías de desarrollo de software ............................. 43
2.1.1 Antecedentes ........................................................................................................ 43
2.2 Industria del software.................................................................................................. 47
2.2.1 Impacto general de las empresas de desarrollo de software................................. 47
2.2.2 Impacto de la industria de software en México.................................................... 48
2.2.3 Número de empresas de software en México....................................................... 49
2.2.4 Concepto general de empresas de desarrollo de software .................................... 49
2.2.5 Clasificación de las empresas de desarrollo de software ..................................... 50
2.3 Metodologías ágiles en las empresas de software....................................................... 51
2.3.1 Importancia general de una adecuada elección de metodología .......................... 51
2.3.2 Metodologías más utilizadas en empresas de desarrollo de software .................. 52
2.4 Criterios de selección usados por empresas de desarrollo de software ...................... 55
2.5 Proyectos de software ................................................................................................. 57
2.5.1 Administración de un proyecto de software ......................................................... 57
2.5.2 Factores de la administración de un proyecto. ..................................................... 58
2.5.3 Actividades de administración de un proyecto .................................................... 58
2.5.4 Organización del equipo en la administración del proyecto ................................ 58
Capítulo 3. Criterios para la selección de una metodología ágil adecuada para el desarrollo
de software. ........................................................................................................................... 60
3.1 Planteamiento del problema........................................................................................ 61
3.1.1 Objetivo general ................................................................................................... 62
3.1.2 Objetivos específicos............................................................................................ 62
3.1.3 Preguntas de investigación ................................................................................... 62
3.1.4 Justificación .......................................................................................................... 63
3.2 Delimitación del problema.......................................................................................... 63
3.3 Hipótesis ..................................................................................................................... 64
3.4 Método ........................................................................................................................ 64
3.5 Proceso de búsqueda ................................................................................................... 65
3.5.1 Criterios de inclusión y exclusión ........................................................................ 66
3.6 Proceso de selección ................................................................................................... 67
3.7 Evaluación de la calidad ............................................................................................. 69
3.8 Extracción de datos ..................................................................................................... 70
3.9 Síntesis de datos .......................................................................................................... 79
3.10 Resultados ................................................................................................................. 81
3.10.1 Preguntas de investigación específicas .............................................................. 84
3.10.2 Análisis crítico.................................................................................................... 95
3.10.3 Recomendaciones ............................................................................................... 97
Conclusiones......................................................................................................................... 98
Referencias ........................................................................................................................... 99
Índice de tablas
Tabla 1 Términos de búsqueda ............................................................................................. 65
Tabla 2 Criterios de inclusión y exclusión ........................................................................... 66
Tabla 3 Evaluación de la calidad .......................................................................................... 69
Tabla 4 Formulario de extracción de datos .......................................................................... 70
Tabla 5 Formulario de extracción de datos 1 ....................................................................... 71
Tabla 10 Formulario de extracción de datos 6 ..................................................................... 75
Tabla 14 Formulario de extracción de datos 10 ................................................................... 78
Tabla 15 Criterios para la selección de una metodología ágil .............................................. 83
Índice de figuras
Figura 1 Tamaño de la industria de Servicios de TI y Desarrollo de Software en México,
2010-2016. .................................................................................................................... 49
Figura 2 Porcentajes de metodologías y/o modelos para desarrollo de software usados por
pymes mexicanas. ......................................................................................................... 52
Figura 3 Porcentajes de metodologías ágiles más utilizadas en el 2020. ............................. 53
Figura 4 Porcentajes de metodologías ágiles más utilizadas en los años 2018, 2019, 2020.54
Figura 5 Porcentaje de las metodologías más utilizadas por diversas empresas. ................. 55
Figura 6 Fases de la revisión sistemática de la literatura. .................................................... 65
Figura 7 Proceso de selección de estudios primarios. .......................................................... 68
Figura 8 Número de estudios primarios por año. ................................................................. 79
Figura 9 Número de documentos por fuentes de información. ............................................ 80
Figura 10 Porcentaje de fuentes basado en temas extraídos. ................................................ 80
Figura 11 Porcentajes de estudios por relevancia. ................................................................ 81
Introducción
Hoy en día la mayoría de las organizaciones que se dedican al desarrollo de software buscan
crear sistemas de manera más rápida, más rentable y con mejor calidad por lo que en la
actualidad una gran parte de las empresas han adoptado metodologías ágiles que les ayuden
a optimizar y mejorar el proceso de desarrollo, ya que los métodos ágiles facilitan el proceso
de desarrollo más rápido y son adecuadas para entornos donde el proyecto está en constante
cambio.
Sin embargo, implementar una metodología ágil no siempre asegura el éxito del
proyecto, las empresas se enfrentan a la difícil tarea de determinar el método ágil más
adecuado. Los encargados de elegir el modelo a implementar se enfrentan a una compleja
decisión, ya que deben seleccionar entre las diferentes metodologías ágiles que existen hoy
en día. Determinar cuál es la metodología más adecuada implica identificar una serie de
características presentes en las metodologías ágiles y en los proyectos que permitan
determinar cuál modelo ágil es el que se adapta mejor a la naturaleza de un proyecto en
particular.
Según Taromirad y Ramsin (2008), mencionan que se deben tener en cuenta diversas
características presentes en los proyectos de desarrollo de software y así relacionar las
similitudes, diferencias, características y aplicaciones de las metodologías ágiles que existen
en la actualidad. Por lo que elegir el enfoque correcto entre varias metodologías ágiles es una
decisión compleja y de varios criterios que pueden tener implicaciones significativas en el
éxito del proyecto (Abdo, Noteboom y Sarnikar, 2015).
Es por esta razón que este trabajo de investigación pretende identificar una lista de
criterios que permita y sirva como referencia a las organizaciones y a las personas que se
dedican a desarrollar software sobre qué metodología ágil deberían implementar
dependiendo las necesidades del proyecto a desarrollar.
Para ello en el capítulo uno que lleva el nombre de Generalidades de las metodologías
ágiles de desarrollo de software se describe la ingeniería de software, el proceso de software,
así como algunas definiciones y conceptos de las metodologías de desarrollo de software
tanto las tradicionales como las ágiles y sus antecedentes para comprender cómo es que
surgieron y fueron evolucionando hasta las metodologías que se conocen hoy en día. Se
describe de manera más detallada cuatro de las metodologías ágiles más conocidas en la
4
actualidad, las cuales son Extreme Programming, Scrum, Crystal y Método de Desarrollo de
Sistemas Dinámicos describiendo algunos conceptos importantes como su definición, etapas,
roles, equipo y valores.
En el capítulo dos que lleva por nombre criterios para la selección de metodologías
ágiles para un mejor proceso de desarrollo de software, se presentan los antecedentes de
trabajos relacionados con esta investigación, el impacto que ha tenido la industria del
software así como temas referentes al impacto de las metodologías ágiles en las empresas de
desarrollo, la importancia de una adecuada selección de un modelo de desarrollo, las
metodologías ágiles más utilizadas, los criterios utilizados por las empresas y una descripción
de los proyectos de desarrollo de software.
En el capítulo tres que tiene el nombre de Criterios para la selección de una
metodología ágil adecuada para el desarrollo de software, que corresponde al marco
metodológico, se lleva a cabo el desenlace de este trabajo de investigación, donde se presenta
el planteamiento del problema, el objetivo general y específicos, a los cuales se les dará
respuesta, las preguntas de investigación que guiarán este trabajo y la justificación.
En este capítulo se realizará una revisión sistemática de la literatura para identificar
aquellos estudios primarios que sirvan para dar respuesta a las preguntas de investigación y
así poder identificar un conjunto de criterios que sirvan como referencia al momento de
seleccionar una metodología ágil adecuada de desarrollo de software para un proyecto en
específico.
Es importante señalar que la presente investigación se desarrolló en el año (2021) y
toda la información que se ha presentado es parte de una investigación previa, obtenida de
estudios relacionados con la selección de una metodología ágil de desarrollo de software
identificados a través de la revisión sistemática de la literatura, el tiempo que se le dedicó a
este trabajo de investigación fue de tres meses.
5
Capítulo 1. Generalidades de las metodologías ágiles de
desarrollo de software
6
A continuación, se muestran los temas que forman parte del marco teórico para el desarrollo
de este trabajo de investigación, se abordan temas como la ingeniería y el proceso de
software, conceptos generales de las metodologías de desarrollo de software, incluyendo las
tradicionales y ágiles. Así como también se describen algunos métodos ágiles.
1.1 Ingeniería de software
A continuación, se presenta como es que surge la ingeniería de software mostrando un poco
de sus antecedentes, de igual forma se menciona el concepto de la ingeniería de software
dados por diversos autores muy conocidos en esta rama, así como también el concepto y las
etapas del proceso de desarrollo de software.
1.1.1 Antecedentes
Frasser (2014), menciona que en la década de los 60 con la aparición de la multiprogramación
y los sistemas multiusuario se introdujeron nuevos conceptos de iteración “hombre-
máquina”, los sistemas realizados reunían, analizaban y transformaban datos de diferentes
fuentes y contribuían en la toma de decisiones. Debido a lo anterior nace la primera
generación de sistemas de administración de base de datos. Así mismo menciona que esa
época se caracterizó por el surgimiento del software como un producto y el origen de la casa
del software en el cual se desarrollaban sistemas de muchas líneas de código fuente que
debían ser corregidos en el momento en el que se detectaban fallas y actualizados cuando los
requisitos eran cambiados, lo que fomento el proceso de desarrollo de software en un ciclo
de codificar y corregir.
Como efecto de esa práctica y que los proyectos de software manifestaban demasiadas
fallas, ya que los desarrollos concluían excediendo el período y costos establecidos al
comienzo del proyecto, no se alcanzaban los resultados esperados y el sistema resultaba muy
poco flexible lo que condujo a una situación conocida como la crisis del software (Frasser,
2014).
Debido a lo anterior en el año de 1968 se realizó la conferencia número uno acerca
del desarrollo de software en Múnich, respaldada por la OTAN, donde la crisis surgida se
volvió el tema principal y se usó por primera vez la frase “Ingeniería del software” para
referirse al cúmulo de conocimientos que se encontraban en un estado inicial y fue así como
nació de manera formal el campo de ingeniería de software (Frasser, 2014).
7
Así mismo surgen distintas definiciones para el concepto de ingeniería de software
abordado por diferentes autores importantes en este ámbito. A continuación, se presentan
algunos conceptos dados por algunos autores (Frasser, 2014).
1.1.2 Concepto
Existen distintas definiciones para el término de ingeniería de software dadas por diferentes
autores, pero todas siguen un mismo ideal. A continuación, se presenta el concepto descrito
por tres autores.
Pressman (2010), describe que la ingeniería de software incluye procesos, métodos y
herramientas que permiten elaborar sistemas complejos basados en computadoras a tiempo
y con calidad. Así mismo menciona que es una tecnología con varias capas siendo este un
enfoque que se basa en un compromiso organizacional con la calidad. Son cuatro las capas
mencionadas que forman parte de la ingeniería de software, las cuales son herramientas,
métodos, proceso, y el compromiso con la calidad.
Por otro lado, Sommerville (2011), menciona que la ingeniería de software es una
disciplina que se interesa por todos los aspectos de la producción de software, desde las
primeras etapas de la especificación del producto hasta su mantenimiento, después de que se
pone en operación. Así mismo menciona que es un enfoque sistemático para la creación de
software que toma en cuenta algunos factores prácticos como el costo, fecha y confiabilidad,
así como las necesidades del cliente y de los fabricantes de software.
De igual forma, la ISO/IEC/IEEE International Standard (2017), define la ingeniería
de software como la aplicación sistemática de conocimientos científicos y tecnológicos,
métodos, experiencia de diseño, implementación, pruebas y documentación de software. Así
como el uso de un enfoque sistemático, disciplinado y cuantificable para la creación,
operación y el mantenimiento de software.
Según Sommerville (2011), en la actualidad la sociedad no podría funcionar sin
grandes sistemas de software y para construirlos existen una gran variedad de tecnologías
que ayudan al desarrollo y la implementación de grandes aplicaciones empresariales. El
software ha consentido la investigación del espacio y el desarrollo de la World Wide Web,
que es el sistema de información más importante en la historia de la humanidad. De igual
forma menciona que el mundo enfrenta un conjunto de desafíos como el cambio climático,
8
agotamiento de los recursos naturales, un alto crecimiento en la población, terrorismo y la
necesidad de ayudar a los adultos mayores a tener una vida plena por lo que se necesitan
nuevas tecnologías para enfrentar todas estas situaciones lo que vuelve a la ingeniería de
software una tecnología muy indispensable para el futuro de la humanidad.
1.1.3 Proceso de software
Debido a la crisis del software surgida en el año de 1968, los proyectos realizados tenían
muchas fallas y terminaban sobrepasando el tiempo y costo estimados. En la década de los
setenta debido a la presión impuesta al desarrollo de software por la evolución de los sistemas
distribuidos, las redes tanto local como global y una fuerte solicitud de acceso rápido,
aumentó de manera significativa la dificultad de los sistemas de información, lo cual condujo
a la identificación de las distintas etapas del desarrollo de software como los requerimientos,
análisis, codificación y pruebas. Es en esta década donde se introdujo la programación
estructurada y los procedimientos formales para la especificación de software (Frasser,
2014).
A partir de entonces se introdujo el proceso de desarrollo de software y muchos
autores definen una serie de etapas importantes que deben seguirse para un correcto
desarrollo de software. A continuación, se presentan algunos aspectos esenciales del proceso
de software como lo son su concepto y las etapas que lo componen presentados por diferentes
autores.
Concepto
Pressman (2010), describe el proceso de software como una modelo para las acciones,
actividades y tareas que se necesitan con el objetivo de elaborar software de mucha calidad.
Así mismo menciona que cada actividad, acción y tarea se localizan en el interior de un
modelo o estructura que determina su relación en el proceso cómo entre sí. Un proceso de
software describe el enfoque aceptado mientras se realiza ingeniería en el software.
De igual forma menciona que el proceso en el contexto de la ingeniería de software
no es una fórmula rígida de cómo crear software para computadoras. Es un enfoque que se
adapta y permite a los equipos de software buscar y elegir el grupo de acciones y tareas
apropiadas para el trabajo, ya que el objetivo es entregar el software de manera oportuna y
con la calidad necesaria que permita satisfacer al cliente (Pressman, 2010).
9
Por otro lado, Sommerville (2011), describe un proceso de software como un conjunto
de actividades relacionadas que conducen a la creación de software. Estas actividades son
abordadas por los ingenieros de software y son cuatro las actividades principales para el
proceso de software.
Etapas del proceso de software
Pressman (2010), menciona que el proceso de software integra cinco actividades
estructurales las cuales son comunicación, planeación, modelado, construcción y despliegue
que son aplicables a todos los proyectos de desarrollo de software las cuales se describen a
continuación.
• Comunicación. Esta actividad tiene la intención de comprender los objetivos que
tienen los integrantes respecto al proyecto y así recabar los requerimientos sean de
utilidad para determinar las características y funciones del software.
• Planeación. Define la función de ingeniería de software al detallar las tareas técnicas
por hacer, los riesgos que puedan surgir, los recursos requeridos, los resultados del
trabajo que se buscan obtener y la programación de actividades.
• Modelado. Elabora un diseño del objeto a desarrollar con el propósito de comprender
el panorama general. Un ingeniero de software crea modelos con el objetivo de
entender de manera más clara los requerimientos del sistema y el diseño que los
asistirá.
• Construcción. Esta actividad combina la creación de código ya sea de manera
manual o automatizada y las pruebas que sean necesarias para detectar errores en el
código.
• Despliegue. Es la fase donde el software es entregado al usuario que lo evalúa y que
da retroalimentación basado en el diagnóstico.
Por otro lado, Sommerville (2011), menciona que existen muchos y diferentes
procesos de software, pero todos deben incluir cuatro actividades que son clave para la
ingeniería de software las cuales se muestran a continuación.
• Especificación de software
• Diseño e implementación de software
• Validación de software
10
• Evolución del software.
1.2 Metodologías de desarrollo de software
A continuación, se presentan algunos aspectos de las metodologías de desarrollo de software
como sus antecedentes, su concepto y su clasificación.
1.2.1 Antecedentes
Zumba y León (2018), mencionan que las metodologías de desarrollo de software han pasado
por un proceso histórico y progresivo que comienza en los años 40 con la aparición de las
primeras computadoras y con ellas una serie de programas y sistemas que requieren para
funcionar. Durante esta época el desarrollo no seguía ninguna metodología, los
programadores únicamente se dedicaban a desarrollar sus códigos una vez comprendidos los
requerimientos otorgados por sus clientes. El desarrollo era totalmente artesanal y no había
metodologías establecidas, lo que provocaba una serie de problemas, ya que únicamente se
dedicaban a la tarea de codificar en lugar de comprender, diseñar y documentar los
requerimientos de los usuarios.
De igual forma Zumba y León (2018), dicen que debido al ambiente complicado que
caracterizó las primeras etapas de la codificación condujo a la inconformidad que iba en
aumento por parte de los usuarios, así como también una serie de proyectos superados en
tiempos de entrega y fondos de manera masiva por lo que resultó en la búsqueda de
alternativas para esquematizar el desarrollo de software.
A inicios de los 60 se introdujo un primer modelo conocido como “Code and Fix”
que significaba codificar y corregir que representaba el afán de abundantes equipos de
programación por seguir un conjunto de pasos formales para la creación de software. Este
modelo sentó las bases para la idea general de los requerimientos, el diseño, codificación,
depuración y los métodos de prueba hasta obtener un entregable y si al final del proceso se
conseguía un diseño incorrecto, se desecha y se iniciaba de nuevo desde la primera fase
(Zumba y León, 2018).
A mediados de los 60 surge la crisis del software para referirse a los problemas que
caracterizaban los procesos de desarrollo, como los costos, la fiabilidad, entregas fuera del
tiempo y presupuesto y la insatisfacción por parte de los clientes. Algunos de los proyectos
desarrollados eran muy importantes como un sistema de control de aeropuertos y equipos de
11
medicina por lo que el fracaso de estos iba más allá de las pérdidas millonarias que se
causaban (Zumba y León, 2018).
Debido a lo anterior en 1972 Edsger Dijkstra, presenta un trabajo titulado “The
Humble Programmer” donde se sientan las bases para la creación de las metodologías
tradicionales conocidas y usadas hasta el día de hoy. A partir de entonces empezaron a surgir
diferentes modelos y en 1970 y 1988 aparecen los modelos tradicionales de desarrollo de
software (Zumba y León, 2018).
A continuación, se presenta el concepto de metodologías de desarrollo de software
dados por distintos autores.
1.2.2 Concepto
Avison y Fitzgerald (1995) (citado en Tinoco, Rosales y Salas, 2010), definen las
metodologías de desarrollo como una colección de procedimientos, técnicas, herramientas y
documentos auxiliares que ayudan a los desarrolladores de software a implementar nuevos
sistemas de información.
Por otro lado, Sommerville (2011), describe un modelo de proceso del software como
una descripción simplificada de un proceso de software. Estos modelos incluyen actividades
que son parte de los procesos y productos de software, así como el papel que cumplen las
personas involucradas en la ingeniería de software.
De igual forma Pressman (2010), menciona que todos los modelos del proceso del
software pueden integrar las actividades estructurales generales las cuales son comunicación,
planeación, modelado, construcción y despliegue, pero cada modelo pone énfasis en ellas y
detalla de forma distinta el flujo de proceso que describe cada actividad estructural.
Así mismo Maida y Pacienzia (2015), afirman que una metodología es un conjunto
compuesto de técnicas y métodos que deja abordar de forma similar y abierta todas
actividades presentes en el ciclo de vida de un proyecto de software y que es un proceso de
específico y completo. También dicen que las metodologías se guían en la unión de los
modelos de proceso generales y determinan artefactos, actividades y roles junto con prácticas
y técnicas recomendadas.
A continuación, se presenta la clasificación de las metodologías de desarrollo de
software descrita por distintos autores expertos en esta rama.
12
1.2.3 Clasificación
Sommerville (2011), clasifica los procesos de software como dirigidos por un plan o como
procesos ágiles. Los procesos guiados por un plan son aquellos donde cada una de las tareas
del proceso se preparan de manera anticipada y el avance se evalúa contra dicho plan. Por
otro lado, la planeación en los procesos ágiles es incremental y resulta más sencillo cambiar
el proceso para manifestar los requerimientos cambiantes por parte del cliente.
De igual forma Pressman (2010) clasifica las metodologías de desarrollo de software
como procesos prescriptivos también conocidos como modelos tradicionales y procesos
ágiles.
Por otro lado, Canós Letelier y Penadés (2003), mencionan que existen muchas
propuestas metodológicas que influyen en diferentes partes del proceso de desarrollo. Una
de ellas es la propuesta tradicional que se centra en el control del proceso, estableciendo las
actividades implicadas, los artefactos que tienen que elaborarse, las herramientas y las
notaciones a usar de una manera estricta y precisa.
Así mismo mencionan que existe otra filosofía que proporciona las metodologías
ágiles que dan una mayor importancia a la colaboración con el cliente y al desarrollo del
software de manera incremental con iteraciones de corto plazo. Esta propuesta muestra su
efectividad en proyectos con requisitos cambiantes y cuando se tienen que reducir los tiempos
de desarrollo de una manera drástica, pero con la intención de mantener una alta calidad
(Canós, Letelier y Penadés, 2003).
A continuación, se describen y se presentan algunos aspectos claves de las
metodologías tradicionales como su concepto y su clasificación.
1.3 Metodologías tradicionales
1.3.1 Concepto
De acuerdo con Pressman (2010), los modelos clásicos son también llamados modelos de
proceso prescriptivo que fueron originalmente propuestos para poner orden en el caos del
desarrollo de software. Él los nombra prescriptivos debido a que determinan un grupo de
elementos del proceso como lo son las actividades estructurales, operación de ingeniería de
software, productos del trabajo, tareas, mecanismos de control del cambio para cada proyecto
y aseguramiento de la calidad.
13
De igual forma Maida y Pacienzia (2015), describe que las metodologías tradicionales
también llamadas metodologías pesadas se centran en llevar a cabo una documentación
exhaustiva, la planificación y el control de todo el proyecto, también se centran en las
especificaciones precisas de requisitos y modelado, así como en cumplir con el plan de
trabajo, definidos en la etapa inicial del desarrollo del proyecto.
A continuación, se presentan algunas de las metodologías tradicionales mencionadas
en el libro de Ingeniería de software escrito por Pressman (2010).
1.3.2 Clasificación
Existen numerosas metodologías tradicionales de desarrollo creadas para ayudar y facilitar
el proceso de desarrollo de software por lo que a continuación se muestran algunos de los
modelos tradicionales más utilizados por expertos en la industria del software.
El modelo de la cascada, a veces llamado ciclo de vida clásico sugiere un enfoque
sistemático y secuencial para el desarrollo del software, que comienza con la especificación
de los requerimientos por parte del cliente y avanza a través de planeación, modelado,
construcción y despliegue, para concluir con el apoyo del software terminado. (Pressman,
2010, p.34)
El modelo incremental aplica secuencias lineales en forma escalonada a medida que
avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de
software susceptibles de entregarse de manera parecida a los incrementos producidos en un
flujo de proceso evolutivo. (Pressman, 2010, p.35)
Los modelos de proceso evolutivos son iterativos y se identifican por la forma en la
que aceptan desarrollar prototipos de software cada vez más completos, entre ellos se
encuentran dos modelos comunes los cuales son hacer prototipos y el modelo espiral
(Pressman, 2010).
El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente,
permite que un equipo de software represente elementos iterativos y concurrentes de
cualquiera de los modelos de proceso descritos anteriormente. Por ejemplo, la actividad de
modelado definida para el modelo espiral se logra por medio de llamar una o más de las
siguientes acciones de software: hacer prototipos, análisis y diseño. (Pressman, 2010, p.40)
14
1.4 Metodologías ágiles
A continuación, se describen y presentan aspectos importantes de las metodologías
ágiles como sus antecedentes, concepto, Manifiesto Ágil, 12 principios del Manifiesto Ágil
y su clasificación.
1.4.1 Antecedentes
Varhol (2021), menciona que en 1990 cuando la informática comenzó a crecer en la industria,
el desarrollo de software se enfrentó a una crisis. En ese tiempo, se conocía como la crisis
del desarrollo de aplicaciones o retraso en la entrega de aplicaciones. Los expertos en la
industria de desarrollo estimaron que el tiempo entre una necesidad comercial validada y una
aplicación real en producción fue de tres años aproximadamente. En otras industrias el retraso
resultaba mucho mayor a tres años.
Debido a lo anterior Jon Kern, un ingeniero aeroespacial en la década de 1990 buscaba
una solución que fuera mucho más oportuna y con una capacidad de respuesta mucho más
rápida a los plazos largos de entrega y a las decisiones tomadas al comienzo de un proyecto
que no podían ser modificadas. Se unió a un grupo mayor de personas que buscaban una
mejor manera de desarrollar software y fue uno de los 17 líderes intelectuales de la industria
que se reunían con el fin de hablar sobre formas de desarrollar software de manera más
simple, sin la sobrecarga de procesos y la documentación del método de cascada y otras
técnicas populares de la ingeniería de software de esa época (Varhol, 2021).
Todas estas frustraciones en torno a las actividades de desarrollo fueron compartidas
por profesionales en la reunión llevada a cabo en Utah a principios del 2001 donde se creó el
manifiesto ágil y se fundó Agile Alliance (Varhol, 2021).
1.4.2 Introducción
Concepto
Sommerville (2011), menciona en su libro Ingeniería de software que los métodos ágiles son
métodos de desarrollo incremental, donde los incrementos son mínimos y, por lo general se
crean nuevas liberaciones del sistema las cuales se ponen a disposición del cliente cada dos
o tres semanas.
Así mismo describe que los métodos ágiles se apoyan de manera universal en el
enfoque incremental para la especificación, el desarrollo y la entrega del software. Estos
15
métodos son más adecuados para el desarrollo de aplicaciones en que los requerimientos del
sistema cambian de manera general rápidamente durante el proceso de desarrollo de software
(Sommerville, 2011).
Un modelo de desarrollo ágil generalmente es un proceso Incremental (entregas
frecuentes con ciclos rápidos), también cooperativo (clientes y desarrolladores
trabajan constantemente con una comunicación muy fina y constante), sencillo (el
método es fácil de aprender y modificar para el equipo) y finalmente Adaptativo
(capaz de permitir cambios de último momento). (Maida y Pacienzia, 2015, p.18)
Por otro lado, Pressman (2010) dice que un proceso de software ágil debe adaptarse
de manera incremental y que para lograr esta adaptación un equipo ágil requiere
retroalimentación con el cliente, deben entregarse incrementos de software en lapsos cortos
de tiempo. Así mismo este enfoque permite que el cliente evalúe en forma regular el
incremento de software y así de retroalimentación indispensable al equipo de software que
ayude en las adaptaciones del proceso que se lleven a cabo para usar de manera completa la
retroalimentación.
Manifiesto Ágil
En una reunión llevada a cabo del 11 al 13 de febrero del 2001 en las montañas Wasatch de
Utah, Estados Unidos por 17 expertos en la industria de software surgió el manifiesto para el
desarrollo de software ágil. Este manifiesto establece cuatro valores y doce principios del
desarrollo de software ágil. Los cuatro valores se muestran a continuación (Beck et al., 2001).
• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación de contratos.
• Respuesta ante el cambio sobre seguir un plan.
12 principios
Del manifiesto ágil surgieron 12 principios los cuales se muestran a continuación (Beck et
al., 2001).
1. Nuestra máxima prioridad es satisfacer al cliente por medio de entregas tempranas y
continuas de software que funcione.
16
2. Bienvenido los requisitos que cambian constantemente, aún si es al final del
desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva
del cliente.
3. Entregamos software funcional frecuentemente, desde un par de semanas hasta un
par de meses, de preferencia con el menor intervalo de tiempo posible.
4. Los empresarios y desarrolladores deben laborar unidos todos los días hasta que
finalice el proyecto.
5. Construya proyectos en torno a personas motivadas. Brindarles el entorno y el apoyo
que requieren, confiar en que ellos pueden hacer el trabajo.
6. El método más eficiente y efectivo de compartir información a un equipo de
desarrollo es mediante un diálogo cara a cara.
7. El software funcional es la principal medida del avance.
8. Los procesos ágiles promueven el proceso sostenible. Los patrocinadores,
desarrolladores y usuarios deben tener la capacidad de mantener un ritmo constante
de manera indefinida.
9. El interés continuo a la calidad técnica y al diseño correcto mejora la agilidad.
10. El arte de aumentar el número de trabajo no realizado es fundamental.
11. Las arquitecturas, requisitos y diseños más destacados nacen de equipos
autoorganizados.
12. En intervalos regulares, el equipo recapacita sobre cómo conseguir ser más eficaz y
luego sintoniza y adapta su conducta en consecuencia.
Clasificación
Existen muchas metodologías ágiles con características propias y que hacen hincapié en
aspectos más específicos. A continuación, se muestran algunos modelos ágiles más
conocidos en la actualidad.
Scrum. Es adecuado para proyectos con una alta tasa de cambio en los requisitos. Su
principal característica es la definición de sprints - cada una de las repeticiones del
proceso con una duración máxima de 30 días. El resultado de cada sprint es un
incremento ejecutable que se muestra al cliente. Otra característica relevante son las
17
reuniones diarias que se desarrollan durante el proyecto. (Mendes, Estevez y
Fillottrani, 2010, p.69)
Extreme Programming. XP, formulado por Kent Beck, se diferencia del resto de
metodologías por su énfasis en la adaptabilidad. La metodología está diseñada para
ofrecer el software que el usuario necesita y cuando lo necesita. El éxito de la
metodología se basa en potenciar las relaciones interpersonales, promover el trabajo
en equipo, el aprendizaje continuo de los desarrolladores y un ambiente de trabajo
amigable. (Mendes, Estevez y Fillottrani, 2010, p.70)
Crystal. Son un conjunto de metodologías para el desarrollo de software que se
caracterizan por el valor de las personas que componen el equipo de trabajo y la
máxima reducción del número de artefactos producidos. Enfatiza los esfuerzos para
mejorar las habilidades de los miembros del equipo y definir políticas de trabajo en
equipo. Las políticas dependerán del tamaño del equipo, donde se establecerá una
clasificación de colores; por ejemplo, Crystal Clear corresponde a equipos con 3-8
miembros y Crystal Orange a equipos con 25-50 miembros (Mendes, Estevez y
Fillottrani, 2010, p.69)
Dynamic System Development Method (DSDM). Es un proceso repetitivo, tolerante
a los cambios y dirigido a los componentes del software. Define tres etapas para el
ciclo de vida: a) Especulación: el proyecto comienza y se planifican las características
del software; b) Colaboración: se desarrolla el producto; y c) Aprendizaje: se controla
la calidad del producto y luego se entrega al cliente. El objetivo de la revisión es
aprender de los errores cometidos y volver a iniciar el ciclo de desarrollo. (Mendes,
Estevez y Fillottrani, 2010, p.69)
Feature-driven development (FDD). Define un proceso iterativo con iteraciones
cortas de dos semanas como máximo. El ciclo de vida consta de cinco pasos: a)
Desarrollo de un modelo global; b) Construcción de una lista de características
(funciones); c) Planificación de funciones; d) Diseño de funciones; y e) Construcción
de características. (Mendes, Estevez y Fillottrani, 2010, p.69)
18
A continuación, se describen más a detalle cuatro de las metodologías más conocidas
actualmente las cuales son Scrum, Extreme Programming, Crystal y Dynamic System
Development Method.
1.4.3 Scrum
Concepto.
Schwaber y Sutherland (2020), definen Scrum como un marco ligero que ayuda a las
personas, los equipos y a las organizaciones a producir valor a través de soluciones que se
adaptan para problemas difíciles.
1. En pocas palabras Scrum necesita un Scrum Master para promover un ambiente
donde:
2. El Product Owner organiza el trabajo de un problema difícil en un product Backlog.
3. El equipo Scrum transforma una parte del trabajo en un incremento de valor durante
un Sprint.
4. El equipo Scrum, así como sus partes interesadas inspeccionan los resultados y se
ajustan para el siguiente Sprint.
5. Repetir.
Equipo Scrum
Schwaber et al. (2020), dicen que la unidad fundamental de Scrum es un equipo pequeño de
personas. El equipo Scrum está formado por el Scrum Master, el Product Owner y los
desarrolladores. En el interior del equipo Scrum, no existen sub-equipos ni jerarquías. Es un
grupo unido de expertos enfocados en un objetivo a la vez. Así mismo mencionan que los
equipos son multifuncionales, lo que quiere decir que los integrantes poseen todas las
habilidades indispensables para crear valor en todos los Sprint. De igual forma son equipos
autogestionados lo que quiere decir que dictaminan de manera interna quién hace qué, en qué
momento y de qué manera lo hace.
De igual forma Schwaber et al. (2020), mencionan que el equipo Scrum es lo
suficientemente pequeño como para seguir siendo ágil y lo suficientemente grande como para
llevar a cabo con éxito un trabajo significativo dentro de un Sprint, generalmente está
compuesto por 10 personas o menos. Si los equipos Scrum se vuelven muy grandes, deben
reflexionar en reorganizarse en varios equipos Scrum unidos. El equipo Scrum es el
19
responsable de cada una de las actividades conectadas con el producto, iniciando por la
cooperación de las partes interesadas, la verificación, el mantenimiento, la operación, la
experimentación, la investigación y el desarrollo, así como cualquier otro elemento que
resulte indispensable.
Roles Scrum
Los desarrolladores son las personas que están comprometidos a crear cualquier aspecto de
un incremento utilizable en cada Sprint que realicen. Estos son los encargados de elaborar un
plan para el Sprint, el Sprint Backlog, inculcar calidad al adherirse a una definición de hecho,
adaptar su plan cada día en dirección al Sprint Goal y hacerse responsables unos a otros como
profesionales (Schwaber y Sutherland, 2020).
El Product Owner es el encargado de aumentar el valor del producto que resulta del
trabajo hecho por el equipo Scrum. La manera en la que se lleva a cabo puede cambiar entre
organizaciones, equipos Scrum y personas. Dentro de sus funciones están elaborar y
comunicar de forma explícita el objetivo principal del producto, crear y transmitir de manera
clara los elementos del Backlog del producto, pedido de elementos del Backlog de productos
y confirmar que la cartera de productos sea clara, visible y entendida (Schwaber y Sutherland,
2020).
El Scrum Master es el encargado de definir este método ágil como se establece en la
guía Scrum. Ayuda a comprender a todos los miembros ya sea dentro del equipo Scrum o la
organización completa la teoría y la práctica de este método. Este es el responsable de la
efectividad del equipo Scrum, ya que son apropiados líderes que sirven al equipo y a la
organización en general. Dentro de sus funciones se encuentran entrenar a los miembros del
equipo en autogestión, ayudarlos a enfocarse en crear incrementos de gran valor que cumplan
con la definición de terminado, así como eliminar impedimentos para el progreso de equipo
Scrum y asegurarse de que todos los eventos tengan un lugar y sean positivos, productivos y
se mantengan dentro del plazo (Schwaber y Sutherland, 2020).
Eventos de Scrum
Schwaber y Sutherland (2020), dicen que el Sprint es un contenedor para todos los demás
eventos. Cada evento dentro de Scrum es una ocasión para analizar y ajustar los artefactos
20
Scrum. Los eventos se emplean para crear regularidad y reducir la necesidad de juntas no
determinadas en Scrum.
De igual manera mencionan que los Sprints son eventos de duración fija de un mes o
menos para crear coherencia, así mismo un nuevo Sprint comienza de inmediato al concluir
el Sprint anterior. Todo lo necesario para cumplir con el objetivo del producto, incluida la
planificación de Sprint, Scrum diarios, Revisión de Sprint y Retrospectiva de Sprint se
llevan a cabo dentro de Sprints. A continuación, se muestran algunos puntos importantes
durante los Sprint (Schwaber y Sutherland, 2020).
• No se realizan cambios que pongan en peligro el Sprint Goal.
• La calidad no disminuye.
• La pila de producto se refina según sea necesario.
• El alcance se puede aclarar y renegociar con el propietario del producto a medida que
van teniendo más conocimiento.
La planificación de Sprint empieza el Sprint al establecer el trabajo a realizar. El plan
que resulta es desarrollado por el esfuerzo cooperativo de todo el equipo Scrum. Así mismo
el Product Owner confirma que todos los asistentes estén listos para tratar los elementos más
esenciales del Product Backlog y cómo se asignan al Product Goal (Schwaber y Sutherland,
2020).
El Scrum diario tiene el propósito de inspeccionar el progreso hacia el Sprint Goal y
adaptar el Sprint Backlog según sea necesario, al ajustar el próximo trabajo planificado. Así
mismo mencionan que es un evento de 15 minutos dirigido a los desarrolladores del equipo
Scrum y para minimizar la complejidad, se hace en el mismo horario y en el mismo sitio cada
uno de los días laborables del Sprint. Los Scrum diarios mejoran la comunicación, identifican
impedimentos, promueven la toma de decisiones rápida y debido a esto eliminan la necesidad
de otras reuniones (Schwaber y Sutherland, 2020).
Artefactos Scrum
Schwaber y Sutherland (2020), mencionan que los artefactos Scrum caracterizan el trabajo o
valor y están planteados para aumentar la claridad de la información primordial. Cada
artefacto incluye un compromiso para asegurar que aporte información que ayude a mejorar
la transparencia y también el sentido frente al cual se pueda medir el avance.
21
• En el caso de la Pila de Producto, es el objetivo del producto.
• Para el Sprint Backlog es el Sprint Goal.
• Para el incremento es la definición de terminado.
El Product Backlog es una lista emergente y sistematizada de lo necesario para hacer
mejor el producto. Es la única fuente de trabajo realizada por el equipo Scrum. Los elementos
del Product Backlog que pueden realizar el equipo Scrum dentro de un Sprint se consideran
listos para ser seleccionados en un evento de Sprint Planning. El refinamiento de la lista del
producto es la actividad de dividir y definir aún más los elementos de la lista en elementos
más pequeños y precisos (Schwaber y Sutherland, 2020).
El compromiso objetivo del producto detalla un estado del producto posterior que
puede ser de utilidad como objetivo para que el equipo Scrum pueda planear. El objetivo del
producto se encuentra en la lista de trabajos pendientes del mismo. El resto surge para definir
que cumplirá con el Product Goal (Schwaber y Sutherland, 2020).
Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos
seleccionados del Product Backlog para el Sprint (qué), así como un plan para entregar el
incremento (cómo). Así mismo es un plan realizado por y para los desarrolladores. Es una
imagen visible y en tiempo real del trabajo que tienen planeado realizar los desarrolladores
durante el Sprint para cumplir con el objetivo (Schwaber y Sutherland, 2020).
El compromiso Sprint Goal es el único objetivo que debe ser alcanzado en el Sprint.
Este es un compromiso de los desarrolladores que otorga flexibilidad con respecto al trabajo
necesario para conseguirlo. De igual forma crea coherencia y enfoque, alentando al equipo
Scrum a trabajar unidos en lugar de hacerlo separados. El Sprint Goal se crea durante el
Sprint Planning y luego se agrega al Sprint Backlog (Schwaber y Sutherland, 2020).
Un incremento es un trampolín concreto que va dirigido al objetivo del producto.
Cada incremento se suma a los anteriores y se examina cuidadosamente, lo que asegura que
cada uno de los incrementos funcionen de manera unida. Para que este tenga valor el
incremento debe ser utilizable (Schwaber y Sutherland, 2020).
1.4.4 Extreme Programming
Concepto
22
Jeffries (2011), define la programación extrema como una disciplina de desarrollo de
software basada en valores como la simplicidad, comunicación, retroalimentación, coraje y
respeto. Funciona al reunir a todo el equipo en prácticas simples, con suficiente
retroalimentación con el objetivo de que el equipo vea dónde están y sintonicen las prácticas
con su situación única.
La Programación Extrema es un enfoque de la ingeniería de software propuesto por
Kent Beck y se estima que es el proceso ágil más destacado. XP se guía en la
retroalimentación continua del cliente con el equipo de desarrollo, en la comunicación
constante entre todos los miembros, la sencillez en las soluciones implementadas y el coraje
para enfrentar las modificaciones presentadas. De igual forma define XP como una
metodología liviana de desarrollo de software, un grupo de prácticas y reglas usadas para el
desarrollo de software basadas en distintas ideas de cómo hacer frente a los ambientes
cambiantes (Bautista Q, 2012).
Por otro lado, Agile Alliance describe la Programación Extrema como un marco de
desarrollo de software ágil que tiene como objetivo principal producir software de alta
calidad y mayor calidad de vida para el equipo de desarrollo. XP es de los marcos ágiles el
más específico en relación con las prácticas de ingeniería apropiadas para el desarrollo de
software.
Prácticas XP
La metodología XP está compuesta por 12 prácticas esenciales las cuales se muestran a
continuación.
Juego de Planificación. Existen dos pasos clave de planificación en XP las cuales
son Release Planning que es una práctica en el que el cliente muestra las características que
necesita a los programadores los cuales se encargan de determinar su dificultad. El cliente
establece un plan para el proyecto con las estimaciones de los costos y con el conocimiento
de la importancia de las características y la Iteration Planning la cual es la práctica mediante
la cual se da dirección al equipo cada dos semanas. Los equipos XP crean software en
repeticiones de dos semanas, entregando software funcional al final de cada iteración.
Durante esta planificación el cliente presenta características deseadas para las próximas dos
semanas (Jeffries, 2011).
23
Pruebas de clientes. Como parte de la exposición de cada una de las características
esperadas, el cliente debe definir una o varias pruebas de aceptación automatizadas que
permita demostrar que la propiedad está funcionando. El equipo crea estas pruebas que
utilizan para demostrarse a sí mismos y al cliente que la función se implementa
correctamente. Los buenos equipos XP manejan cada prueba de sus clientes de igual forma
que las pruebas de los desarrolladores, una vez ejecutada la prueba, el equipo la mantiene
funcionando de manera correcta a partir de ese momento (Jeffries, 2011).
Pequeños lanzamientos. Los equipos XP realizan lanzamientos pequeños de dos
maneras, en primer lugar, el equipo lanza software probado y en ejecución, que ofrece el
valor comercial determinado por el cliente en cada iteración. El cliente puede hacer uso del
software entregado para cualquier propósito, ya sea de evaluación o inclusive de liberación
a los usuarios finales. En segundo lugar, los equipos XP también lanzan software a sus
usuarios finales frecuentemente. Los proyectos de XP Web se publican con frecuencia diaria
y los proyectos internos se publican mensualmente o con una frecuencia mayor (Jeffries,
2011).
Metáfora. Los equipos XP crean una visión de cómo funciona el sistema, lo que se
conoce como metáfora. La metáfora es una descripción evocadora de cómo funciona el
programa, como descripción de un sistema de recuperación de información basada en
agentes. Los equipos XP utilizan una técnica común de nombres con el objetivo de asegurar
que todos comprendan cómo funciona el programa y donde buscar para encontrar el lugar
indicado para colocar la funcionalidad por agregar (Jeffries, 2011).
Diseño simple. Los equipos de programación extrema crean software con un diseño
simple, pero adecuado en todo momento. Inician de manera simple y, a través de las pruebas
de los desarrolladores y la mejora del diseño se mantiene así. Un equipo XP mantiene el
diseño precisamente adecuado para la funcionalidad actual del sistema. El diseño en la
Programación Extrema no es una cosa de una sola vez, o una cosa por adelantado, es algo
que está presente todo el tiempo (Jeffries, 2011).
Programación en pareja. El software de producción en XP está constituido por dos
programadores, sentados uno al lado del otro, en la misma computadora. Esta práctica
garantiza que el código de producción sea examinado al menos por otro desarrollador, lo que
24
tiene como consecuencia un diseño mejor, mejores pruebas y un código superior. La
investigación sobre la programación en parejas muestra que se produce un mejor código
aproximadamente al mismo tiempo que los programadores que trabajan de manera individual
(Jeffries, 2011).
Desarrollo basado en pruebas. La Programación Extrema está firmemente ligada
con la retroalimentación y, en el desarrollo de software, una correcta retroalimentación
requiere de buenas pruebas. Los mejores equipos XP practican el desarrollo basado en
pruebas trabajando en ciclos muy pequeños para agregar una prueba y después hacer que
funcione. No basta con escribir pruebas, deben ser ejecutadas. Estas pruebas de programador
o unitarias se recopilan de manera en conjunta y cada vez que un programador libera un
código en el repositorio, todas y cada una de las pruebas deben ejecutarse de manera correcta
(Jeffries, 2011).
Mejora del diseño (refactorización). La Programación Extrema se enfoca en
proporcionar valor comercial en cada iteración realizada. Para lograr esto durante todo el
proyecto, el software debe estar diseñado de manera correcta. La alternativa sería reducir la
velocidad lo que llevaría a quedarse atascado. Por eso, la Programación Extrema utiliza un
proceso de mejora continua del diseño denominado refactorización. Este proceso se centra
en eliminar la duplicación y aumentar la cohesión del código mientras se reduce el
acoplamiento. El resultado es que los equipos comienzan con un diseño bueno y simple para
el software y lo mantienen así en todo momento. Esto les permite mantener su velocidad de
desarrollo, inclusive aumentar su velocidad conforme avanza el proyecto (Jeffries, 2011).
Integración continua. Los equipos XP conservan el sistema integrado todo el
tiempo. Los equipos de programación extrema compilan varias veces durante el día. Un
equipo XP de cuarenta personas compilan al menos ocho o diez veces al día. La integración
poco frecuente da como resultado problemas graves en el proyecto de software. El código
integrado con poca frecuencia es a menudo código con errores. El proceso de integración
débil conduce a largos bloqueos de código lo que significa que tienen periodos de tiempo
prolongados en los que los programadores pueden trabajar en funciones importantes que
pueden ser enviadas, pero que son retenidas (Jeffries, 2011).
25
Propiedad colectiva del código. En un proyecto XP, cualquier pareja de
desarrolladores tiene la autoridad de mejorar cualquier código en el momento que sea. Lo
que significa que todo el código se beneficia de la atención de muchas personas, lo que
aumenta la calidad en el código y reduce los defectos. La característica colectiva resulta en
un inconveniente si los miembros trabajan a ciegas en un código que no comprenden. XP
evita estos problemas a través de dos técnicas esenciales, la primera son las pruebas del
programador las cuales detectan errores, y la programación en parejas que significa que la
mejor manera de trabajar con código desconocido es hacer pareja con el experto. Esta práctica
difunde el conocimiento en todo el equipo (Jeffries, 2011).
Estándar de codificación. Los equipos de programación extrema siguen un estándar
de codificación común, de manera que todo el código del sistema parece haber sido escrito
por una sola persona, muy competente. Lo importante es que todo el código se muestra
familiar, en apoyo de la propiedad colectiva (Jeffries, 2011).
Marcha sostenible. Los equipos de programación extrema están en esto a largo
plazo. Trabajan duro y a un ritmo que puede mantenerse de manera indefinida. Esto quiere
decir que trabajan horas extras cuando es efectivo y por regular trabajan de manera que
maximizan la productividad semana tras semana (Jeffries, 2011).
Valores XP
Don Wells (2009), menciona que la Programación Extrema se basa en cinco valores los
cuales son comunicación, simplicidad, retroalimentación, coraje y respeto los cuales se
describen a continuación.
Sencillez. Haremos lo que se necesite y se nos pida, pero nada más. Esto maximizará
el valor creado por la inversión realizada hasta la fecha. Daremos pequeños pasos sencillos
hacia nuestro objetivo y mitigamos las fallas a medida que ocurran. Crearemos algo de lo
que estemos orgullosos y lo mantendremos a largo plazo por costos razonables (Don Wells,
2009).
Comunicación. Todos somos parte del equipo y nos comunicamos cara a cara a
diario. Trabajaremos juntos en todo, desde los requisitos hasta el código. Desarrollaremos la
mejor solución a nuestro problema que podamos juntos (Don Wells, 2009).
26
Comentarios. Tomaremos en serio cada compromiso de iteración al entregar un
software que funcione. Demostramos nuestro software temprano y, a menudo, escuchamos
atentamente y hacemos los cambios necesarios. Hablamos del proyecto y adaptamos nuestro
proceso a él, no al revés (Don Wells, 2009).
Respeto. Todos brindan y sienten el respeto que merecen como miembros valiosos
del equipo. Todos aportan valor, incluso si es simplemente entusiasmo. Los desarrolladores
respetan la experiencia de los clientes y viceversa. La gerencia respeta nuestro derecho a
aceptar la responsabilidad y recibir autoridad sobre nuestro propio trabajo (Don Wells, 2009).
Coraje. Diremos la verdad sobre avances y estimaciones. No registramos las
justificaciones del fracaso porque planeamos conseguir el éxito. No tememos a nada porque
nadie trabaja solo. Nos adaptamos a los cambios cuando ocurran (Don Wells, 2009).
Equipo XP
Agile Alliance, describe al equipo XP como un grupo multifuncional de personas con roles
necesarios para un producto que forman un solo equipo. Esto quiere decir que las personas
con una necesidad, así como todas las personas que desempeñan algún papel en la
satisfacción de esa necesidad trabajan de manera colaborativa todos los días para lograr un
resultado determinado (Don Wells, 2009).
Roles XP
Jeffries (2011), menciona que todos los miembros del equipo de un proyecto XP se sientan
juntos. A continuación, se describen los roles descritos por el autor.
• Cliente. El equipo incluye un representante comercial, que proporciona los
requisitos, establece las prioridades y dirige el proyecto.
• Programadores. El equipo incluye programadores.
• Probadores. Se pueden incluir probadores en el equipo que ayuden a definir las
pruebas de aceptación del mismo.
• Analistas. Sirven como ayudante al cliente para definir los requisitos.
• Entrenador. Apoya al equipo a conservar la dirección y hacer más fácil el proceso.
• Gerente. Proporciona recursos, manejando la comunicación externa y coordinando
actividades.
27
1.4.5 Crystal Clear
Concepto
Cockburn (2004), define el nombre de la metodología Crystal por la caracterización de
proyectos a lo largo de dos dimensiones, tamaño y criticidad, coincidiendo con los minerales
que se caracterizan por las dimensiones, color y dureza. Así mismo menciona que Crystal es
una familia de metodologías con un código genético común, el cual enfatiza la entrega
frecuente, la comunicación cercana, y la mejora reflexiva. No existe solo una metodología,
sino diferentes metodologías Crystal para diferentes tipos de proyectos.
Familia Crystal
Cockburn (2004), menciona que en las metodologías Crystal los proyectos más grandes, es
decir, que requieren de mayor coordinación y comunicación, se asocian a colores más
oscuros. Proyectos de sistemas que pueden provocar mayor daño, necesitan una metodología
más estricta, es decir, más validación y reglas de verificación.
Cockburn (2004), caracteriza las metodologías Crystal por color, según el número de
personas coordinadas.
• Clear. Es para un equipo de 8 personas.
• Amarillo. Es para equipos de 10-20 personas.
• Naranja. Es para equipos de 20-50 personas.
• Rojo. Para equipos de 50-100 personas.
El código genético de Crystal se componen del modelo de juego económico-
cooperativo, propiedades seleccionadas, principios seleccionados, técnicas de muestra
seleccionadas, y ejemplos de proyectos (Cockburn, 2004).
El modelo de juego económico-cooperativo. Este modelo dice que el desarrollo de
software es una serie de juegos cuyos movimientos no consisten en nada más que inventar y
comunicarse, donde normalmente se tienen recursos limitados. Cada juego de la serie tiene
dos objetivos que compiten por recursos los cuales son entregar el software durante el juego
y configurar para el próximo juego de la serie. Este modelo lleva a las personas en un
proyecto a pensar en su trabajo de manera muy específica, enfocada y efectiva (Cockburn,
2004).
Propiedades Crystal
28
Cockburn (2004), dice que las propiedades comunes de la familia Crystal son la seguridad
en el resultado del proyecto, eficiencia en el desarrollo, y habitabilidad de las convenciones.
Esta metodología hace que el equipo del proyecto se enfoque hacia siete propiedades de
seguridad, las tres primeras antes mencionadas son fundamentales para Crystal y las demás
se pueden agregar en el cualquier orden para aumentar el margen de seguridad. Estas
propiedades son, entrega continúa, comunicación cercana, mejora reflexiva, seguridad
personal, enfoque, acceso fácil a usuarios experimentados, y ambiente técnico con pruebas
automatizadas, gestión de la configuración e integración continúa.
Propiedad 1. Entrega frecuente. La propiedad más importante de cualquier
proyecto ya sea grande o pequeño, ágil o no, es el de entregar código probado y en ejecución
a usuario reales en periodos cortos mensuales. Algunas de las ventajas es que los
patrocinadores reciben comentarios críticos sobre el progreso del equipo, los usuarios tienen
la oportunidad de comprobar si su solicitud original fue para lo que realmente necesitan y
para llevar a cabo una retroalimentación en el desarrollo (Cockburn, 2004).
Propiedad 2. Mejora reflectiva. El autor menciona que un proyecto puede revertir
su fortuna, es decir desde un fracaso enorme hasta el éxito de este si el equipo se une, se debe
enumerar lo que sí y no funciona, así como discutir que puede funcionar mejor y realizar los
cambios pertinentes en la siguiente iteración. En otras palabras, reflexionar y mejorar. El
equipo puede realizar esta actividad una hora cada pocas semanas o meses sin tener que gastar
mucho tiempo (Cockburn, 2004).
Propiedad 3. Comunicación osmótica. Esta comunicación significa que la
información fluye en el fondo auditivo de los miembros del equipo, de tal manera que ellos
captan información relevante como si fuera por ósmosis. Esto se logra sentándose en la
misma habitación, así si algún miembro realiza una pregunta, los demás en la habitación
pueden poner atención o dejar de hacerlo, contribuyendo a la discusión o continuando con su
trabajo. Esta comunicación y la entrega frecuente facilitan una comunicación rápida y una
buena retroalimentación de que el proyecto puede funcionar con muy poca estructura
(Cockburn, 2004).
Propiedad 4. Seguridad personal. La seguridad personal es poder hablar cuando
algo molesta sin temor a represalias. Esto puede implicar decirle al gerente si el cronograma
29
no es correcto, o decirle a un compañero que su diseño necesita mejorar o incluso hacerle
saber a un colega que necesita bañarse más a menudo. Esta seguridad es importante porque
así el equipo puede descubrir y reparar sus debilidades. Sin la seguridad personal los
miembros no hablarían y las debilidades continuarán dañando al equipo (Cockburn, 2004).
Propiedad 5. Enfoque. El enfoque es saber primero en que trabajar, y luego tener
tiempo y tranquilidad para ello. Saber en qué trabajar proviene de la comunicación sobre la
dirección de los objetivos y las prioridades, por lo regular por parte del patrocinador
ejecutivo. El tiempo y la tranquilidad provienen de un entorno en el que las personas no se
apartan de su tarea para trabajar en otras cosas incompatibles (Cockburn, 2004).
Propiedad 6. Fácil acceso a usuarios expertos. El acceso continuo a usuarios
expertos proporciona al equipo un lugar para implementar y probar las entregas frecuentes,
así como una retroalimentación rápida sobre la calidad de su producto terminado, y sobre sus
decisiones de diseño y requisitos actualizados. Una hora a la semana de acceso a un usuario
real y experto, es de mucho valor para el equipo. Cuantas más horas a la semana esté
disponible un usuario real para un equipo, mayor será la ventaja y el provecho que podrán
obtener (Cockburn, 2004).
Propiedad 7. Entorno técnico con pruebas automatizadas, gestión de la
configuración e integración frecuente. Los equipos realizan con éxito las pruebas
manuales, por lo que esto no puede ser considerado un factor crítico de éxito. Durante la
semana se revisan secciones de código, con el beneficio de que se puede comprobar de
manera rápida que nada ha dejado de funcionar en el camino de manera inesperada. Las
pruebas ofrecen libertad de movimiento durante el día y tranquilidad durante la noche. El
sistema de gestión de la configuración permite a las personas registrar su trabajo de forma
asincrónica, realizar cambios, preparar una configuración particular para su lanzamiento, y
retroceder a esa configuración más adelante al presentarse un problema. Muchos equipos
integran el sistema varias veces durante el día. Cuanto más frecuente se integren, más rápido
detectan errores, menos son los errores que se acumulan (Cockburn, 2004).
Roles Crystal
Cockburn (2004), menciona que hay ocho roles dentro de la metodología Crystal, cuatro de
los cuales deben ser personas distintas y los otros cuatro pueden ser roles adicionales
30
asignados a personas en el proyecto. Los primeros cuatro roles son Patrocinador ejecutivo,
Usuario embajador, Diseñador principal, Diseñador-programador.
Patrocinador ejecutivo. Es la persona que asigna o defiende la asignación del dinero
para el proyecto. Debe pensar a largo plazo, equilibrando las prioridades a corto plazo con
las de lanzamientos y equipos posteriores que evolucionan o mantienen el sistema. Es el
encargado de crear visibilidad externa para el proyecto y proporcionará al equipo decisiones
cruciales a nivel empresarial (Cockburn, 2004).
Usuario embajador. Es la persona familiarizada con los procedimientos operativos
y el sistema en uso, conociendo cuáles son los modos de funcionamiento más frecuentes, los
menos frecuentes, que atajos son necesarios y qué información debe ser visible en la pantalla
al mismo tiempo (Cockburn, 2004).
Diseñador principal. Esta es la persona técnica principal. Es la persona que tiene
experiencia en el desarrollo de software, capaz de realizar el diseño principal del sistema,
decir cuando el equipo del proyecto va por buen camino o por mal camino, y si va por mal
camino como salir de él (Cockburn, 2004).
Diseñador-Programador. El autor combina estas palabras para destacar que cada
persona diseña y programa a la vez. Diseñar sin programar está lleno de fallos debido a la
falta de retroalimentación en los proyectos de cualquier tamaño. La programación por su
propia naturaleza, implica diseñar (Cockburn, 2004).
El coordinador. Es una ocupación parcial para alguien del equipo. Es la persona que
gestiona varios proyectos y desempeña este papel para cada uno de los proyectos. El
coordinador debe tomar notas en las sesiones de planificación y estado, y peinar la
información para su publicación y presentación. Él es responsable de dar a los patrocinadores
del proyecto visibilidad sobre la estructura y el estado del proyecto (Cockburn, 2004).
Experto en negocios. El experto en cómo funciona la empresa, qué estrategias o
políticas son fijas, que es probable que varíe pronto, a menudo o rara vez. Es la persona
encargada de responder todas las preguntas variadas que los desarrolladores tendrán sobre el
corazón del sistema (Cockburn, 2004).
Probador y escritor. Son por lo regular, asignaciones rotativas o temporales. En
muchos proyectos de Crystal Clear solo hay de cuatro a ocho personas, todos programadores
31
que en ocasiones deben turnarse para ocupar estos roles. Algunos equipos pueden hacer uso
de un escritor por periodos de tiempo o cuentan con algún probador dedicado a trabajar con
ellos (Cockburn, 2004).
1.4.6 Método de desarrollo de sistemas dinámicos
Concepto
Agile Business Consortium (2021), menciona que es un enfoque líder, probado y ágil que
proporciona la conducción y el rigor en unión con la agilidad y flexibilidad que demandan
las organizaciones hoy en día. Este marco se puede utilizar de forma independiente o en
combinación con otros métodos reconocidos como PRINCE2, MSP y PMI. De igual forma
es ideal como recubrimiento para enfoques ágiles más limitados, con el fin de garantizar que
se aborde todo el ciclo de vida del proyecto.
El DSDM es un “enfoque endurecido en la batalla” probado y ha sido responsable de
la entrega exitosa de innumerables proyectos en todo el mundo. Su procedencia se remonta
a 1994 con ganancias sustanciales de productividad verificadas en forma independiente por
la asociación de Métricas de software del Reino Unido (Agile Business Consortium, 2021).
Principios DSDM
Agile Business Consortium (2021), describe ocho principios que respaldan la filosofía
DSDM la cual menciona que el mejor valor comercial surge cuando los proyectos están
alineados con objetivos comerciales claros, se entregan con frecuencia e involucran la
colaboración de personas motivadas y empoderadas. A continuación, se muestran los ocho
principios.
Principio 1. Centrarse en la necesidad empresarial. Cada decisión que se tome
durante un proyecto debe considerarse a la luz del objetivo principal del mismo, entregar lo
que la empresa necesita en el tiempo en que debe ser entregado. Para cumplir con este
principio los equipos DSDM deben:
• Comprender las verdaderas prioridades comerciales.
• Establecer un caso comercial válido.
• Garantizar el patrocinio y el compromiso empresarial continuos.
• Garantizar la entrega del substrato mínimo utilizable.
32
Principio 2. Cumplir a tiempo. Entregar una solución a tiempo es el resultado
deseado para un proyecto, y con frecuencia, es el factor de éxito más importante. La entrega
fuera de tiempo a menudo puede socavar la justificación misma de un proyecto, en particular
cuando se trata de oportunidades de mercado con plazos legales. Incluso para proyectos sin
fecha de finalización fija, la entrega a tiempo de productos intermedios o contribuyentes
sigue siendo la manera más adecuada de probar el control sobre la evolución de la solución.
Para cumplir con este principio los equipos DSDM deben:
• Planificar el trabajo.
• Centrarse en las prioridades comerciales.
• Cumplir siempre con los plazos.
• Generar confianza a través de una entrega predecible.
Principio 3. Colaborar. Los equipos que trabajan de manera colaborativa y con
compromiso siempre serán superiores a los grupos de personas que trabajan solo en una
asociación flexible. La colaboración fomenta una mayor comprensión, una mayor velocidad,
y una propiedad compartida, lo que permite a los equipos desempeñarse a un nivel que excede
la suma de sus partes. Para cumplir con este principio, los equipos DSDM deben:
• Involucrar a las partes interesadas adecuadas, en el momento oportuno, durante todo
el proyecto.
• Fomentar la participación proactiva de los representantes comerciales.
• Asegurarse de que todos los miembros del equipo están facultados para tomar
decisiones en nombre de sus representantes.
• Construir una cultura de un solo equipo.
Principio 4. Nunca comprometa la calidad. En DSDM el nivel de calidad que se
entregará debe acordarse desde el principio. Todo el trabajo debe tener como objetivo lograr
dicho nivel de calidad. Una solución debe ser “suficientemente buena”. Si la empresa está de
acuerdo en que las funciones del subconjunto mínimo utilizable cumplen con los criterios de
aceptación acordados, entonces la solución debe ser lo suficientemente buena para utilizarla
de manera eficaz. Para cumplir con este principio, los equipos DSDM deben:
• Acordar el nivel de calidad desde el inicio, antes de comenzar el desarrollo.
• Asegurarse de que la calidad no se convierta en una variable.
33
• Probar temprano, probar continuamente y probar al nivel apropiado.
Principio 5. Construir incrementalmente a partir de cimientos firmes. Uno de los
diferenciadores clave para DSDM dentro del entorno ágil es el concepto de establecer bases
firmes para el proyecto antes de comprometerse con un desarrollo importante. Lo primero
que busca comprender es el alcance del problema empresarial a resolver y la solución
propuesta. Una vez establecidas las bases firmes para el desarrollo, DSDM aboga por la
entrega incremental de la solución a fin de brindar un beneficio comercial real lo más pronto
posible. Para cumplir con este principio, los equipos DSDM deben:
• Llevar a cabo un análisis adecuado y un diseño suficiente inicial (EDUF), para crear
cimientos sólidos.
• Reevaluar formalmente las prioridades y reevaluar de manera informal la viabilidad
del proyecto en curso con cada incremento entregado.
Principio 6. Desarrollar iterativamente. DSDM utiliza una combinación de
desarrollo iterativo, demostraciones frecuentes y revisión integral para fomentar la
retroalimentación oportuna. Adoptar el cambio como parte de este proceso evolutivo permite
al equipo coincidir en una solución empresarial precisa. La idea de iteración se encuentra en
el interior de todo lo desarrollado como una porción del enfoque DSDM. Para cumplir con
este principio, los equipos DSDM deben:
• Incorporar comentarios comerciales en cada iteración.
• Reconocer que la mayoría de los detalles deberían surgir más tarde que antes.
• Adoptar el cambio, la solución adecuada no evolucionará sin él.
• Utilizar el desarrollo iterativo para fomentar la creatividad, la experimentación y el
aprendizaje.
• Permitir el cambio y aprovechar sus beneficios. El cambio es inevitable.
Principio 7. Comuníquese de manera continua y clara. Una mala comunicación
comúnmente es la principal causa del fracaso del proyecto. Las prácticas DSDM están
diseñadas específicamente para mejorar la efectividad de la comunicación tanto para equipos
como para individuos. Para cumplir con este principio los equipos DSDM deben:
• Fomentar la comunicación informal y cara a cara en todos los niveles.
• Realizar sesiones diarias de stand-up en equipo.
34
• Utilizar los talleres, con un facilitador cuando corresponda.
• Utilizar prácticas de comunicación visual como el modelado y la creación de
prototipos.
• Demostrar la solución en evolución temprana y con frecuencia.
• Mantener la documentación simple y oportuna.
• Gestionar las expectativas de las partes interesadas en todos los niveles a lo largo del
proyecto.
• Apuntar siempre a la honestidad y transparencia en todas las comunicaciones.
Principio 8. Demostrar control. Es fundamental tener el control de un proyecto en
todo momento y poder demostrarlo. Esto se logra mediante la referencia a un plan para el
trabajo que se esté realizando, que esté claramente alineado con los objetivos comerciales
acordados. Así como también es de vital importancia garantizar la transparencia de todo el
trabajo que efectúa el equipo. Para lograr el objetivo de este principio, los equipos DSDM,
en especial el gerente del proyecto y jefe del equipo deben:
• Hacer que los planes y el progreso sean visibles para todos.
• Medir el progreso centrándose en la entrega de productos en lugar de actividades
completas.
• Gestionar proactivamente.
• Evaluar la viabilidad continua del proyecto en función de los objetivos comerciales.
• Utilizar un nivel adecuado de formalidad para el seguimiento y la presentación de
informes.
Proceso
Agile Business Consortium (2021), menciona que el enfoque DSDM para el desarrollo y para
la entrega es iterativo e incremental, y las necesidades comerciales por lo general se abordan
de manera temprana, mientras que las características menos importantes se entregan más
adelante. A diferencia de muchos de los enfoques ágiles, DSDM integra la gestión de
proyectos y el desarrollo de productos en un solo proceso.
De igual forma dicen que el modelo de proceso DSDM comprende un marco que
muestra las fases de este enfoque y su relación entre sí. Después cada proyecto utiliza este
modelo de proceso para derivar su ciclo de vida. Este proceso tiene cuatro fases principales
35
las cuales son viabilidad, fundamentos, desarrollo evolutivo y despliegue precedida por la
fase de pre-proyecto y post-proyecto, obteniendo seis en total (Agile Business Consortium,
2021).
Fase de pre-proyecto. En esta fase la filosofía DSDM describe que el mejor valor
empresarial surge cuando los proyectos están alineados con objetivos empresariales claros.
Esta fase garantiza que solo se inicien los proyectos correctos y que se configure de manera
correcta, sobre la base de un objetivo claro previamente definido (Agile Business
Consortium, 2021).
Fase de viabilidad. Esta fase tiene como objetivo principal, establecer si el proyecto
propuesto será viable desde una perspectiva técnica y si será rentable desde una perspectiva
empresarial. La viabilidad ayudará a decidir si se justifica una mayor investigación o si el
proyecto debe ser detenido por ser poco factible (Agile Business Consortium, 2021).
Fase de fundamentos. La fase de fundamentos lleva la investigación preliminar de
viabilidad al siguiente nivel. Su objetivo es establecer una comprensión fundamental, pero
no detallada de la base empresarial del proyecto, la solución potencial creada por el proyecto
y la manera en que se gestionará el desarrollo y la entrega de la solución. El objetivo de esta
fase es comprender el alcance del trabajo, cómo se llevará a cabo, quién, cuándo y dónde
(Agile Business Consortium, 2021).
Fase de desarrollo evolutivo. El propósito de esta fase es evolucionar la solución.
Así mismo requiere que el equipo de desarrollo de soluciones aplique prácticas como el
desarrollo iterativo, el cronograma y la priorización de MoSCoW, junto con el modelado y
talleres facilitados, para coincidir a lo largo del tiempo en una solución precisa que cumpla
con las necesidades de la empresa y que así mismo se construya de forma correcta desde un
punto de vista técnico (Agile Business Consortium, 2021).
Fase de implementación. El objetivo de esta fase es llevar una línea de base de la
solución en evolución al uso operativo. La versión que se implementará puede ser la solución
final o un subconjunto de esa solución. Algunos de los aspectos que se pueden implementar
son los siguientes. La fase de implementación comprende tres actividades principales las
cuales son ensamblar, revisar e implementar (Agile Business Consortium, 2021).
36
Fase post-proyecto. Después de la implementación final de un proyecto, esta fase
verifica que tan bien se lograron los beneficios comerciales esperados. Se produce una o más
evaluaciones de los beneficios obtenidos en relación con el caso empresarial. Los beneficios
pueden evaluarse para versiones individuales donde la evaluación debe comenzar antes de
que se alcance la fase post-proyecto (Agile Business Consortium, 2021).
Roles DSDM
Agile Business Consortium (2021), menciona que las personas que trabajan juntas de manera
eficaz son la base de cualquier proyecto exitoso. DSDM asigna roles y responsabilidades
claros a cada persona dentro de un proyecto. Así mismo dice que las mejores soluciones
surgen de equipos autoorganizados y empoderados. Es importante que los integrantes tengan
presentes los siguientes aspectos.
• Respetar el conocimiento, la experiencia, las habilidades y las opiniones de los demás.
• Asumir la responsabilidad personal de su trabajo y la dependencia de los demás
miembros del equipo.
• Tener el coraje de desafiar las formas de trabajar para mejorar la colaboración en
equipo y procesos de trabajo.
DSDM identifica roles en dos dimensiones, categorías e intereses. Los roles se
agrupan en tres categorías las cuales se muestran a continuación.
• Roles del proyecto.
• Roles del equipo de desarrollo de soluciones.
• Rol de apoyo.
Los roles a nivel proyecto son patrocinador comercial, visionario comercial,
coordinador técnico, gerente de proyecto y analista comercial y se describen a continuación.
• El patrocinador comercial proporciona la dirección estratégica general y controla
el presupuesto del proyecto.
• El visionario comercial y coordinador técnico tienen las visiones comerciales y
técnicas respectivamente del proyecto.
• El analista de negocios se posiciona de manera intencional como parte del nivel de
proyecto, así como parte del equipo de desarrollo de soluciones. Ayuda a la empresa
37
a formular el caso de negocio y también a definir sus requisitos durante la viabilidad
y los cimientos.
Los roles del equipo de desarrollo de soluciones son embajador comercial,
desarrollador de soluciones, probador de soluciones, analista comercial y líder del equipo y
se describen a continuación.
Embajador comercial. Es el representante clave de las necesidades comerciales
dentro del equipo de desarrollo de soluciones y como tal, debe tener el deseo de autoridad, la
responsabilidad y el conocimiento para cumplir con el rol. Durante la fase de fundamentos
el embajador tiene una participación significativa en la creación y priorización de requisitos
(Agile Business Consortium, 2021).
Desarrollador de soluciones. Colabora con los demás roles del equipo de desarrollo
de soluciones para interpretar los requisitos comerciales y traducirlos en un incremento de la
solución que satisfaga las necesidades funcionales y no funcionales. La persona que asuma
este rol debe contar con la facultad adecuada del coordinador técnico para tomar decisiones
cotidianas en su área de especialización (Agile Business Consortium, 2021).
El probador de soluciones. Es un rol completamente integrado con el equipo,
realizando pruebas durante todo el proyecto de acuerdo con la estrategia acordada (Agile
Business Consortium, 2021).
Analista de negocios. Hace más fácil la relación entre los roles comerciales y
técnicos, garantizando que se elijan decisiones precisas y adecuadas con respecto a la
solución en evolución en el día a día. De igual forma se asegura que las necesidades
comerciales se modelan y analizan de manera correcta y se reflejen de la misma manera en
la orientación que el equipo necesita para generar la solución (Agile Business Consortium,
2021).
Líder de equipo. Este actúa como líder de servicio para el equipo de desarrollo de
soluciones y se asegura de que funcione como un todo y cumpla con sus objetivos. Así mismo
trabaja con el equipo para planificar y coordinar todos los aspectos de la entrega del producto
a un nivel detallado (Agile Business Consortium, 2021).
Los roles de apoyo son asesores comerciales, asesores técnicos, facilitador de talleres
y entrenador DSDM y se describen a continuación.
38
Asesor comercial. Es el encargado de proporcionar información específica y
especializada para el desarrollo o pruebas de soluciones. El asesor comercial por lo general
será un usuario o beneficiario de la solución, así como también representante de grupo focal,
sin embargo, puede simplemente brindar asesoramiento legal o regulatorio que la solución
debe cumplir (Agile Business Consortium, 2021).
Asesor técnico. Se encarga de apoyar al equipo proporcionando información técnica
específica y especializada al proyecto, por lo general desde la perspectiva de los responsables
de la gestión de cambios operativos, soporte operativo, así como el mantenimiento continuo
de la solución (Agile Business Consortium, 2021).
Facilitador del taller. Es el responsable de gestionar el proceso del taller y es
catalizador para la preparación y la comunicación. Así como también de organizar y facilitar
una sesión que permita a los participantes lograr el objetivo del taller (Agile Business
Consortium, 2021).
Entrenador DSDM. Este rol resulta importante cuando un equipo tiene poca
experiencia en el uso DSDM. El entrenador ayuda a los miembros del equipo a aprovechar
al máximo el enfoque, dentro del contexto y las limitaciones de la organización más amplia
en la que trabajan (Agile Business Consortium, 2021).
1.5 Ventajas
Jordán Marcos (2020), menciona que algunas de las ventajas que ofrecen los métodos ágiles
son las siguientes.
• Se realizan entregas periódicas que funcionan y que puede ser usado por el cliente.
Por lo regular al finalizar cada Sprint lo que conlleva a una gran satisfacción para el
cliente.
• Mayor flexibilidad cuando es necesario realizar modificaciones a los requisitos o al
producto. Al finalizar cada Sprint, el cliente recibe una entrega del software final que
puede ser probado por si el cliente necesita hacer modificaciones, estos pueden
emplearse en futuros Sprints.
• Rapidez con la que es posible aplicar las modificaciones solicitadas por el cliente.
• Se eliminan tareas que no son necesarias y que no añaden valor al producto final, es
decir se elimina el trabajo que no resulta necesario.
39
• Se disminuye la documentación excesiva.
• La motivación del equipo aumenta debido a que se les integra en el desarrollo del
proyecto.
• Un producto con mejor calidad debido a la constante interacción que existe entre el
cliente y el equipo de desarrollo.
• Implica una reducción del tiempo de desarrollo a largo plazo lo que tiene como
consecuencia que los costos se reduzcan.
• Mejora continua de los procesos de trabajo.
1.6 Desventajas
Jordán Marcos (2020), menciona que algunas de las desventajas de las metodologías ágiles
son las que se muestran a continuación.
• Es común llegar al error de creer que un desarrollo ágil no necesita ser documentado.
• La poca documentación puede provocar malentendidos al cliente con el desarrollo.
Algo escrito no puede borrarse, sin embargo, algo dicho puede traer problemas.
• Si no se tiene la documentación apropiada, puede producir que se disminuya la
reusabilidad del código.
• Los métodos ágiles se basan en las personas y no tanto en la documentación, por lo
que, si un proyecto no tiene éxito, la compresión del software queda bajo la
responsabilidad del equipo de desarrollo.
• Si un proyecto ágil no tiene éxito es usual regresar a los modelos tradicionales.
• Por lo regular existe una sólida dependencia de los responsables. La persona que se
encarga de dirigir el proyecto concentra las decisiones.
40
Capítulo 2. Criterios para la selección de metodologías ágiles
para un mejor proceso de desarrollo de software.
41
En la actualidad vivimos en un mundo donde el desarrollo de software está presente en casi
todos los ámbitos de la sociedad, en el ámbito laboral, en los servicios de salud, la educación
y muchos sectores más que existen actualmente, facilitando el trabajo y la vida de muchas
personas al automatizar diversas actividades que anteriormente se hacían de manera manual
o en papel y lápiz.
Debido a lo anterior y con el fin de optimizar y mejorar el proceso de desarrollo de
software se han creado diversas metodologías entre las cuales se encuentran los modelos
tradicionales, los modelos ágiles y actualmente se están desarrollando metodologías híbridas
con el fin de obtener productos en menor tiempo, cumpliendo con lo establecido en el
contrato y de calidad.
Según Project Magnament Institute (citado en Merja, 2020), menciona que el 71% de
todas las organizaciones del mundo han adoptado métodos de gestión de proyectos ágiles.
Así mismo Mohammed y Abushama (2013), mencionan que los métodos ágiles se han vuelto
el desarrollo de software más adoptado en la industria de software debido a que estos métodos
abordan los cambios de requisitos de manera más rápida y eficaz, ayudan a satisfacer a los
clientes, respaldar la interacción, permiten una mejor comunicación y entregar productos de
calidad.
Por lo anterior hoy en día las organizaciones que desarrollan software se enfrentan a
la decisión de seleccionar entre las diferentes metodologías con el objetivo de determinar la
que se adapte mejor al tipo de proyecto a desarrollar, y así cumplir con los requisitos
establecidos, dentro del presupuesto y en un menor tiempo sin afectar la calidad.
BS Silva, Schramm y C. Damasceno (2016), mencionan que las empresas que
desarrollan proyectos de software específicos se enfrentan a la decisión de elegir entre
diferentes metodologías para satisfacer las necesidades del proyecto para un contexto en
específico. Así mismo menciona que la naturaleza de esta decisión es compleja e involucra
una serie de criterios y que como consecuencia tiene implicaciones significativas en el éxito
del proyecto.
Existen diferencias entre las distintas metodologías ágiles que pueden ser tomadas en
cuenta como criterios o factores que permitan determinar que método se adecua mejor a la
naturaleza del proyecto a desarrollar y al equipo de desarrollo. Por lo que es importante
42
identificar esos criterios o lineamientos dentro de las metodologías ágiles que facilite a las
organizaciones elegir una metodología ágil de desarrollo de software.
2.1 Criterios de selección de metodologías de desarrollo de software
En la actualidad las empresas de desarrollo de software se enfrentan al desafío de seleccionar
la metodología más adecuada dependiendo el tipo de proyecto a desarrollar, por lo que es
importante tener en cuenta criterios o características dentro de los métodos ágiles que le
permitan a las organizaciones determinar cuál metodología es la más factible de acuerdo con
la naturaleza del proyecto por lo que muchos investigadores han planteado una serie de
criterios que facilitarán este desafío.
A continuación, se muestran los antecedentes de los trabajos relacionados con la
adecuada selección de una metodología ágil de desarrollo de software.
2.1.1 Antecedentes
En la actualidad las metodologías ágiles se han posicionado fuertemente en las empresas de
desarrollo de software, ya que proporcionan una mayor flexibilidad a los cambios, buscando
obtener un resultado en menor tiempo sin afectar la calidad. Por lo que es vital identificar
esos criterios que ayuden a determinar la metodología ágil más adecuada.
BS Silva, Schramm y C. Damasceno (2016) realizaron un artículo titulado “A
multicriteria approach for selection of agile methodologies in software development
projects” dicho estudio tuvo como objetivo presentar un enfoque basado en el método
multicriterio SMARTER (Técnica simple de calificación de múltiples atributos que explotan
rangos) para respaldar las decisiones que impliquen la selección de una metodología ágil de
desarrollo de software más adecuada para pequeñas y medianas empresas de desarrollo,
mediante la definición de un conjunto de criterios medibles que deben ser tomados en cuenta
al momento de evaluar la metodología ágil a utilizar. La metodología utilizada fue una
revisión sistemática de la literatura para definir los criterios que sean de utilidad al momento
de elegir una metodología ágil, en el cual se seleccionaron 167 estudios de los cuales se
establecieron tres dimensiones principales. Como conclusión se obtuvo un enfoque basado
en el método SMARTER para respaldar la selección más apropiada de la metodología ágil
que mejor satisfaga las necesidades de proyectos de desarrollo de software específicos. Así
43
como también un conjunto de criterios medibles que deben ser evaluados en la decisión de
alguna metodología.
Bakhtouchi y Rahmouni (2018) realizaron un artículo nombrado “A Tree Decision
Based Approach for Selecting Software Development Methodology” el cual tuvo como
objetivo la definición de un número importante de criterios para la selección de una
metodología, la propuesta de un método de selección basado en árboles de decisión y el
desarrollo de un software que brinda a los encargados de proyecto una manera más sencilla
de seleccionar la metodología adecuada. La metodología utilizada fue la revisión de la
literatura para el análisis y búsqueda de criterios que caracterizan completamente todos los
aspectos de un proyecto de software mediante la revisión de diferentes metodologías de
desarrollo, así como también la experiencia en el desarrollo de software por parte de los
autores y el análisis de una serie de trabajos relacionados con el tema de selección de
metodologías de desarrollo de software realizados por diferentes autores. Como conclusión
se obtuvo una lista de 30 criterios distribuidos en siete categorías que permite establecer el
método de selección de metodologías y el árbol de decisiones que permite poder determinar
las metodologías más adecuadas a utilizar.
Kumar Rai, Agarwal y Kumar (2018) realizaron un artículo titulado “A Novel
Approach for Agile Software Development Methodology Selection Using Fuzzy Inference
System” el cual tuvo como objetivo establecer una técnica utilizando Fuzzy Inference System
que permite seleccionar un método ágil adecuado entre Extreme Programming, Scrum,
Feature Driven Development y Dynamic System Development Method, asi como identificar
los principales factores que juegan un papel importante al momento de seleccionar una
metodología ágil y así ayudar a las organizaciones a decidir que método ágil utilizar en los
diferentes proyectos que les asegure un mayor éxito. La metodología utilizada fue una
revisión de la literatura basada en estudios previos que resultan efectivos en la selección de
métodos ágiles. Como conclusión se obtuvo una base de diez reglas difusas sobre la fuerza
determinante del software ágil y la implementación a través del sistema de inferencia difusa
que evalúa los factores que afectan la selección de una metodología.
Simelane y Zuva (2019) realizaron un artículo titulado “Decision Support Framework
for the Adoption of Software Development Methodologies” que tuvo como objetivo
44
desarrollar un marco de apoyo que facilite a las organizaciones tomar una decisión adecuada
con respecto a qué metodología de desarrollo aplicar al iniciar un proyecto de software en
particular, así como también identificar los factores que influyen en la elección de un método
de desarrollo. La metodología utilizada fue una investigación cuantitativa, se hizo un estudio
de casos que se enfocó en la reutilización de experiencias pasadas combinada con una escala
Likert, la cual fue implementada en forma de cuestionario distribuido a los directores de
proyectos de diez empresas de desarrollo de software de Gauteng. Como conclusión se
obtuvo un puntaje promedio dado por los directores de las distintas empresas en la escala de
Likert a las diferentes características del proyecto en relación con una metodología que fue
aplicada en un proyecto lo que se usó para formular cinco reglas del marco de apoyo para las
organizaciones.
Mendes, Estevez y Fillottrani (2010) realizaron un artículo titulado “A Quantitative
Framework for the Evaluation of Agile Methodologies” el cual tuvo como objetivo presentar
un marco de evaluación cuantitativa de metodologías ágiles que brinde la oportunidad de
tomar una decisión más sólida al momento de seleccionar un método ágil. La metodología
utilizada fue la revisión sistemática de la literatura de diversos estudios relacionados que
tienen como objetivo comparar metodologías ágiles con el fin de encontrar factores o
aspectos relevantes que faciliten la elección de alguna de estas por parte de diferentes autores.
Como conclusión se obtuvo la definición un marco que permite evaluar de qué manera las
metodologías ágiles cumplen con principios del Manifiesto Ágil, de igual forma se
identificaron características esenciales en las metodologías que enfatizan aspectos
específicos y principalmente este marco clasifica los factores críticos de éxito en seis
dimensiones las cuales son la estrategia de entrega correcta, práctica adecuada de técnicas
ágiles de ingeniería de software, capacidad del equipo, procesos del proyecto, estilo de
trabajo en equipo y la participación del cliente como otro miembro del equipo.
Mnkandla y Dwolatzky (2007) realizaron un artículo titulado “Agile Methodologies
Selection Toolbox” el cual tuvo como objetivo presentar una herramienta que sirva de ayuda
para simplificar el proceso de selección de la metodología ágil más adecuada para un
proyecto de software determinado. Esta herramienta elige las prácticas ágiles más relevantes
para un entorno determinado. La metodología utilizada fue una combinación de técnicas de
45
taxonomía de proyectos existentes y resultados de encuestas que proporcionaron un conjunto
de parámetros usados para clasificar los proyectos de software. Como conclusión se obtuvo
una herramienta informática que permite la selección de las prácticas de metodologías ágiles
más apropiadas para un proyecto en específico, dicha herramienta se compone de tres etapas
que guían el proceso de selección. La primera etapa confirma la relevancia del desarrollo ágil
en un proyecto, la segunda es un conjunto de prácticas ágiles de diferentes metodologías
ágiles y en la tercera fase estas prácticas se clasifican en sociales y técnicas las cuales son
relacionadas con el entorno dado. De igual forma esta herramienta está dirigida a las etapas
iniciales de la planificación del proyecto donde se toman en cuenta el tipo de metodología y
el tipo de prácticas que resultan aplicables al proyecto.
Balaji y Obaidy (2016) realizaron un artículo titulado “Project characteristics used
for methodology selection to develop the software project” el cual tuvo como objetivo
facilitar y reducir el tiempo de elección de una metodología por parte del cliente y del equipo
de gestión de proyecto por medio del análisis de algunas metodologías de desarrollo con el
propósito de seleccionar la más adecuada de acuerdo a las características de los proyectos de
software identificadas en este estudio. La metodología utilizada fue la revisión de la
literatura, entrevistas realizadas a profesionales que trabajan en la industria de TI y una
encuesta realizada al equipo de desarrollo y de gestión de proyectos de software con el
objetivo de identificar las características dentro de los proyectos. Como conclusión se obtuvo
una serie de características propias de los proyectos de software como el tamaño, la
estabilidad del requisito y el entorno, la relación del equipo, compromiso con el cliente, el
alcance del proyecto, la claridad del riesgo, y la flexibilidad de las partes interesadas. Estas
características permiten efectuar la elección de una metodología de una manera sencilla.
Khan y Sufyan (2013) realizaron un artículo titulado “Extended Decision Support
Matrix for Selection of SDLC-Models on Traditional and Agile Software Development
Projects” dicho estudio tuvo como objetivo evaluar los métodos de selección utilizados en
una serie de proyectos y proponer una matriz de selección extendida que permite determinar
los modelos de desarrollo de software que mejor se adecúen a distintos tipos de proyectos.
La metodología utilizada en este estudio fue una combinación entre una investigación
explorativa y métodos de investigación de teoría fundamentada. Se realizó una encuesta
46
dirigida a los gerentes de proyectos reales y a profesionales en la industria de TI de diversas
organizaciones y se entrevistó a 32 personas incluidos directores de proyectos y los miembros
superiores del equipo del proyecto durante un periodo de seis meses. Como conclusión se
obtuvo una guía prescriptiva para proyectos de software mediante una matriz de soporte de
decisiones que facilita la elección adecuada de modelos de desarrollo de software y se
identificó la necesidad de contar con una herramienta de apoyo que facilite la decisión de
seleccionar una metodología adecuada.
Mohammed y Abushama (2013) realizaron un artículo titulado “Popular agile
approaches in software development: Review and analysis” dicho estudio tuvo como
objetivo tres factores principales el primero proponer una definición y evaluación de los
métodos ágiles más populares. En segundo lugar, explorar los desafíos de las pequeñas y
medianas empresas con el propósito de establecerlos en criterios y por último comparar las
metodologías ágiles con el fin de mostrar similitudes y diferencias con los criterios
identificados. La metodología utilizada fue una revisión sistemática de la literatura que
permitió recopilar una serie de estudios relevantes sobre las metodologías ágiles de desarrollo
de software más populares y explorar los desafíos de las pymes de software. Como
conclusión se obtuvo un número de criterios que representan los desafíos dentro de las
empresas que no cuentan con un proceso disciplinado adecuado. La formulación de estos
criterios proporciona a las pymes una forma de determinar el método y las prácticas ágiles
más adecuadas y así reducir los riesgos y obtener un producto de calidad.
2.2 Industria del software
Actualmente la industria del software ha tenido un alto crecimiento alrededor de todo el
mundo estando presente prácticamente en todos los sectores sociales y laborales facilitando
muchas de las actividades que por lo general se hacían de manera manual, así como también
es uno de los principales sectores económicos que más ganancia generan.
2.2.1 Impacto general de las empresas de desarrollo de software
Pino, García y Piattini (2006), mencionan que en las últimas décadas la industria del software
ha crecido y se ha fortalecido de tal manera que actualmente representa una actividad
económica de gran importancia para todos los países del mundo. De igual forma dice que las
micro, pequeñas y medianas empresas son un eslabón muy importante en la economía
47
mundial, ya que en la actualidad la industria del software en muchos países está formada por
un tejido industrial conformado en su mayoría por Pymes que desarrollan software ayudando
al crecimiento de las economías nacionales.
De igual forma mencionan que la mayoría de las empresas que desarrollan software
son empresas pequeñas que tienen menos de 50 empleados y desarrollan productos complejos
que para su desarrollo necesitan prácticas eficientes de Ingeniería de software adaptadas a su
tipo de negocio y tamaño (Pino, García y Piattini, 2006).
BS Silva, Schramm y C. Damasceno (2016), mencionan que las pequeñas y medianas
empresas (Pymes), juegan un papel muy fundamental en el desarrollo de software. De igual
forma menciona que los estudios muestran que más del 70% de los productos de software se
desarrollan en pequeñas y medianas empresas de desarrollo.
2.2.2 Impacto de la industria de software en México
Guerra (2018), menciona que, en el transcurso de esta última década, la industria de servicios
de tecnología de la información y desarrollo de software se ha vuelto uno de los sectores más
relevantes en el desarrollo de la economía en México, debido a su potencial para crecer, así
como la inercia favorable que tiene con los países.
Así mismo menciona que la industria de software ha tenido un crecimiento constante
en México durante las últimas décadas, por medio de la presencia de importantes empresas
líderes del sector en diferentes ciudades alrededor de todo el país, contribuyendo de manera
importante al Producto interno Bruto (PIB) y la oportunidad de empleos (Guerra, 2018).
De acuerdo con ProMéxico (citado en Guerra, 2018) en cifras de Marketline, el valor
de mercado de la industria de TI y desarrollo de software ha arrojado una tasa de crecimiento
promedio anual del 12.26% durante el periodo 2010-2016 y se calcula que el valor de
mercado de las dos industrias en 2016 fue de 11.3 mil millones de dólares.
A continuación, se muestra el valor del mercado de la industria de servicios de TI y
desarrollo de software en México.
48
Figura 1 Tamaño de la industria de Servicios de TI y Desarrollo de Software en México, 2010-
2016.
Tomada de: “Nuevas oportunidades en la industria de servicios de tecnologías de la información y desarrollo
de software en México” por Guerra. 2018.
2.2.3 Número de empresas de software en México
Conforme a la información dada por ProMéxico (citado en Guerra, 2018), se destaca que, de
las 30 empresas más importantes a nivel mundial, 25 cuentan con operaciones en México,
dentro de las que sobresalen las empresas norteamericanas Microsoft, Oracle, IBM,
Symantec y EMC.
Así mismo dice que nueve de las 15 empresas más destacadas en tercerización de
servicios empresariales por la International Association of Outsourcing Professionals
(IAOP) tiene presencia en México.
Guerra (2018), menciona que existen más de cuatro mil empresas en México
relacionadas al ámbito de TI, con 20 grupos de empresas de TI en 16 estados de la República
mexicana que forman aproximadamente mil empresas.
2.2.4 Concepto general de empresas de desarrollo de software
Cabach (2006), menciona que la primera empresa en el mundo que usó una organización de
software como fábrica fue Hitachi en el año de 1996, mientras que la segunda fue establecida
49
por un líder estadounidense en el ámbito de software llamada System Development
Corporation, durante 1975-1976.
El término fábrica hace referencia al compromiso a largo plazo, a los esfuerzos en
equipo en vez de proyectos individuales con el propósito de mejorar las operaciones del
software. Así como también mejorar la efectividad del proceso, reducir la cantidad de trabajo
y reutilizar el ciclo de vida de los productos, obteniendo mejores resultados en un tiempo
menor y con costos menores. Es una industria en el que las actividades de desarrollo de
software son predecibles, lo que quiere decir que los costos estimados y lo establecido en el
cronograma pueden ser satisfechos (Cabach, 2006).
Yousra, Cherie y Surendra (2015), dicen que actualmente las organizaciones que
desarrollan proyectos de software se enfrentan a la decisión de seleccionar qué metodología
es la más adecuada. De igual forma mencionan que los gerentes de TI deben identificar y
seleccionar entre diferentes metodologías de desarrollo de software con el objetivo de
satisfacer las necesidades del proyecto en particular y de la organización.
2.2.5 Clasificación de las empresas de desarrollo de software
Actualmente gran parte de las empresas de desarrollo de software y de muchos otros sectores
en diferentes países están compuestas por micro, pequeñas y medianas empresas (MiPymes)
las cuales están aportando mucho a la economía y ofrecen mucha oportunidad laboral.
De acuerdo con Yepes, Pardo y Gómez (2015), las empresas se pueden clasificar de
acuerdo con el número de sus trabajadores.
• Microempresas. No mayor a diez personas.
• Pequeñas empresas. Entre 11 y 50 empleados.
• Medianas empresas. Entre 51 y 200 empleados.
• Grandes empresas. Más de 200 empleados.
De acuerdo con el INEGI (2020), del total de establecimientos en nuestro país el 95%
son MiPymes de los siguientes tamaños.
• Micro. De 0 a 10 personas.
• Pequeñas. De 11 a 50 personas.
• Medianos. De 51 a 250 personas.
50
2.3 Metodologías ágiles en las empresas de software
Actualmente, las empresas que desarrollan software se enfrentan a la tarea de seleccionar una
metodología que les ayude a mejorar el proceso de desarrollo, cumpliendo con los requisitos
del cliente en el tiempo y con el presupuesto establecido por lo que muchas organizaciones
han optado por usar metodologías ágiles en sus proyectos que les asegure una mejor calidad
en menor tiempo.
2.3.1 Importancia general de una adecuada elección de metodología
De acuerdo con BS Silva, Schramm, y C. Damasceno (2016), las metodologías de software
se han desarrollado para optimizar y mejorar el proceso de desarrollo de software en las
últimas décadas como lo son Extreme Programming (XP), SCRUM, Dynamic Systems
Development Method (DSDM), Agile Modeling, Crystal, Rapid Application Development,
Feature Driven Development (FDD), Lean Software Development, Test Driven
Development, PRINCE2 y OPM3. En los últimos años, han surgido una serie de informes de
éxito sobre el uso de metodologías ágiles en proyectos de software, debido a eso la
comunidad técnica, el gobierno, el sector privado y la academia han implementado modelos
ágiles en el desarrollo de sus proyectos.
Bakhtouchi y Rahmouni (2018), mencionan que actualmente vivimos en un mundo
donde el software está presente en todas partes, para desarrollar software de calidad existen
diferentes metodologías de desarrollo de software y que determinar cuál utilizar en un
proyecto de software se ha convertido en uno de los desafíos que actualmente enfrentan los
ingenieros de software. De igual forma mencionan que la elección de una metodología
depende de muchos factores y que no existe una metodología universal que pueda ser
utilizada para cualquier tipo de proyecto. La selección de una metodología es crucial para el
éxito del proyecto y el uso de una metodología inadecuada tendría un alto riesgo de no
desarrollar software de calidad en el plazo establecido y dentro del presupuesto.
Por otro lado, Taromirad y Ramsin (2008), comentan que debido a la aparición de
muchas metodologías ágiles de desarrollo de software y la gran cantidad de variantes
presentes en estas, ha surgido la necesidad de evaluación y comparación para facilitar la
elección o ingeniería de una metodología ágil dirigida a una situación en particular de
desarrollo de software.
51
De igual forma Simelane y Zuva (2019) mencionan que la selección adecuada de una
metodología de desarrollo de software ayudará a terminar de manera exitosa los proyectos
de desarrollo de software críticos para el negocio y al cumplimiento de los objetivos por los
cuales se llevó a cabo el proyecto.
Vhutshilo, Kadyamatimba, Muganda Ochara y Tutani (2018), dicen que es muy
importante usar una metodología que aumente la probabilidad de éxito para cumplir con los
plazos, minimizar los costos y obtener los requisitos especificados por lo que el uso de una
metodología adecuada para un proyecto en específico a desarrollar tendrá un papel valioso
al momento de garantizar que el producto se produzca y se entregue en tiempo, dentro del
costo establecido, cumpla con los requisitos de los usuarios.
2.3.2 Metodologías más utilizadas en empresas de desarrollo de software
De acuerdo a una encuesta realizada a 21 pymes de desarrollo de software de la región centro
de México por Corona, Muñoz, Miramontes, Calvo y San Feliu (2016), la cual tuvo como
objetivo analizar las metodologías ágiles más utilizadas por las pymes, mostró que el 38% de
las pymes usan Scrum, un 14% utilizan Kanban y un 24% no hace uso de ninguna. A
continuación, se muestran los resultados de dicha encuesta.
Figura 2 Porcentajes de metodologías y/o modelos para desarrollo de software usados por
pymes mexicanas.
Tomada de: "Estado de arte sobre métodos de evaluación de metodologías ágiles en las pymes" por Corona,
Muñoz, Miramontes, Calvo Manzan, San Feliu. 2016.
52
Un informe realizado por Coding Sans (2020), muestra las metodologías ágiles más
populares en las empresas de desarrollo de software durante el 2020 y una comparación de
los cambios en la popularidad de las distintas metodologías ágiles en los últimos años.
Figura 3 Porcentajes de metodologías ágiles más utilizadas en el 2020.

Tomada de: "State of software development" por Coding Sans. 2020.
Así mismo Cervera (2021), menciona que existen muchos tipos de metodologías
ágiles que analizan distintos principios con el objetivo de cumplir de manera completa con
las necesidades del sistema de información que se tiene la intención de implementar a
diferentes tipos de empresas. A continuación, se presentan algunas de las metodologías ágiles
más importantes mencionadas por el autor.
• Agile Project Managment (APM)
• Extreme Programming (XP)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Scrum
• Kanban
53
Rosselló (2019), dice que en la actualidad las empresas apuestan por el uso de
metodologías ágiles, ya que consiguen gestionar sus proyectos de forma flexible, autónoma
y eficaz consiguiendo reducir los costos e incrementando su productividad, debido a lo
anterior menciona que existen diversas opciones de metodologías ágiles, pero las más
utilizadas por las empresas actuales son Extreme Programming (XP), Scrum y Kanban las
cuales se guían a través de un patrón establecido por el Manifiesto Ágil.
A continuación, se muestra la variación en porcentajes de la popularidad de las
distintas metodologías en los últimos años.
Figura 4 Porcentajes de metodologías ágiles más utilizadas en los años 2018, 2019, 2020.
Tomada de: "State of software development" por Coding Sans. 2020.
En la decimocuarta encuesta anual State of Agile realizada entre agosto y diciembre
de 2019 patrocinada por Digital.ai (2020), anteriormente CollabNet VesionOne, se invitó a
muchas personas de una gran variedad de industrias en la comunidad global de desarrollo de
software a realizar la encuesta, la cual arrojó una serie de porcentajes sobre las metodologías
más usadas por las organizaciones encuestadas. Dichos resultados se muestran a
continuación.
54
Figura 5 Porcentaje de las metodologías más utilizadas por diversas empresas.
Tomada de: "14 Annual State Of Agile Report" por Digital.ai. 2020.
2.4 Criterios de selección usados por empresas de desarrollo de software
En la actualidad existe poca literatura y datos que describan los criterios o factores utilizados
en las empresas que desarrollan software para elegir qué metodología utilizar en sus
proyectos de software por lo que a continuación se presentan datos dados por algunos autores
acerca de la manera en que las organizaciones seleccionan una metodología.
Según Balaji y Obaidy (2016), por medio de la realización de entrevistas y encuestas
con equipos en la industria de TI se obtuvieron algunas características que son tomadas en
cuenta al seleccionar una metodología. A continuación, se presentan dichas características.
• Tamaño del proyecto: este es el alcance principal del desarrollo del proyecto y se
utiliza para la clasificación del proyecto.
• Tamaño del equipo: el tamaño del equipo es la cantidad de recursos necesarios para
desarrollar el proyecto.
• Estabilidad de requisitos: se ocupa de los cambios de requisitos en el desarrollo del
proyecto.
55
• Relación del equipo: la relación del equipo es importante, todos deben conocer el
estado del proyecto y cómo comunicarse con cualquier miembro del equipo, ya sea
en el extranjero o en el sitio
• Compromiso con el cliente: el compromiso del cliente se usa para considerar el
requisito del proyecto dado por él. También pueden participar en la fase de prueba de
aceptación del usuario (UAT).
• Claridad del alcance: el alcance del proyecto debe estar claro en todas las fases del
proyecto. Si el alcance no está claro, afectará a todas las fases de desarrollo del
proyecto.
• Claridad del riesgo: se debe analizar el riesgo del proyecto y el plan de mitigación
para superarlo. Dependiendo de la complejidad del proyecto, el riesgo será diferente.
• Estabilidad del entorno: se ocupa del entorno para lanzar el proyecto en tiempo real.
Esto debe quedar claro para implementar el proyecto.
• Flexibilidad de las partes interesadas: la flexibilidad depende del proceso que debe
desarrollarse con la satisfacción del cliente.
Por otro lado, Medina y López (2015) realizaron una encuesta dirigida a 50 empresas
de Bogotá que desarrollan software en el cual de los resultados arrojados se obtuvo un
hallazgo importante el cual menciona que las empresas que desarrollan software usan las
metodologías dependiendo de la necesidad del desarrollador, el analista, el diseñador o la
misma empresa lo que en muchos casos provoca que los productos carezcan de refinamiento
y se ve afectada su calidad.
Así mismo Öztürk (2013), menciona que algunos de los factores que las empresas
toman en cuenta al seleccionar una metodología de desarrollo de software son los que se
muestran a continuación.
• Utilizan la orientación de expertos externos a los proyectos o empresas para la
selección del SDLC apropiado. Los expertos generalmente deciden de acuerdo con el
éxito o el fracaso anterior.
• Algunas empresas deciden utilizar un SDLC más conocido o popular que se esté
utilizando actualmente y todos los proyectos siguen esta decisión.
• Utilizando tablas que comparan SDLC y así seleccionar el más apropiado.
56
• La gerencia del proyecto decide un SDLC de manera heurística. Por lo general la
gestión de proyectos generalmente utilizan el mismo SDLC cada vez que hacen un
proyecto.
2.5 Proyectos de software
Los proyectos de software son un proceso de gestión que permite la creación de un producto
de software por lo cual lleva un conjunto de actividades o etapas para el desarrollo de un
sistema. A continuación, se describen varios puntos importantes sobre la administración de
proyectos de software mencionados por un autor.
2.5.1 Administración de un proyecto de software
Según Maida y Pacienzia (2015), mencionan que las actividades de la administración de un
proyecto de software comprenden los métodos para organizar y seguir el curso del proyecto
dentro de los cuales se encuentran la estimación de costos, políticas de asignación de
recursos, control de presupuesto, determinación de avances, ajustes al calendario de trabajo,
procedimientos de control de calidad y comunicación con el cliente.
La administración de un proyecto de software consiste en gestionar el desarrollo de
un producto, dentro del tiempo y el presupuesto establecido. La administración involucra
recursos humanos, organización técnica, habilidades organizativas y el arte de dirigir a un
equipo de personas (Maida y Pacienzia, 2015).
Maida y Pacienzia (2015), muestran la estructura de cómo está comprendida la
administración de un proyecto la cual se observa a continuación.
• Estructura (Elementos organizativos involucrados)
• Proceso administrativo (Responsabilidades y supervisión de participantes)
• Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo)
• Programa (organización de los tiempos en los que deben realizarse los trabajos)
Así mismo mencionan que existen algunos problemas importantes identificados en la
administración de software los cuales se enlistan a continuación.
• Planeación de proyectos de software pobres.
• Procedimientos de selección de gerentes de proyecto pobres.
• La medición de proyectos es pobre.
• Falta de procedimientos para vigilar el avance del proyecto.
57
• Falta de estándares para medir la calidad del desempeño y cantidad de producción
esperada.
2.5.2 Factores de la administración de un proyecto.
Actualmente, existen muchos factores presentes dentro la administración de proyectos de
software muy cruciales que deben conocerse. Según Maida y Pacienzia (2015), mencionan
que la administración de un proyecto debe manejar ciertos factores muy importantes los
cuales se enlistan a continuación.
• El costo total del proyecto (aumentar o disminuir los gastos).
• Las capacidades del proyecto (añadir o eliminar características funcionales).
• La calidad del producto (aumentar el tiempo entre fallos de una cierta severidad).
• La duración del proyecto (reducir el tiempo programado un 20% o posponer un mes
la fecha de terminación)
2.5.3 Actividades de administración de un proyecto
Según Maida y Pacienzia (2015), enlistan una secuencia de actividades que forman parte de
la administración de proyectos.
• Comprender el contenido, alcance y tiempos del proyecto.
• Identificar el proceso de desarrollo (métodos, herramientas, lenguajes,
documentación, ayudas).
• Determinar la estructura organizativa (elementos de la organización involucrados).
• Identificar el proceso administrativo (establecer las responsabilidades de los
participantes).
• Programar el proceso (organigramas en los que se fijan los tiempos de ejecución de
cada actividad). Programar qué actividades deben realizarse y en qué tiempo.
• Establecer un equipo de personas (se busca y contrata el equipo de personas).
• Analizar los riesgos y buscar sus paliativos.
• Enumerar los productos que debe generar el proyecto.
2.5.4 Organización del equipo en la administración del proyecto
Según Maida y Pacienzia (2015), mencionan que para la organización de un equipo se deben
seguir los siguientes pasos.
1. Se debe seleccionar un líder
58
• Asegura que se activen todos los aspectos del proyecto.
• Resuelve las diferencias.
• Propone las primeras tentativas.
• Busca que el equipo lo acepte.
2. Se debe designar y documentar las responsabilidades
• Líder del equipo: Propone y mantiene.
• Responsable de gestión de la configuración.
• Responsable de calidad.
• Responsable de administración de requisitos.
• Responsable de diseño.
• Responsable de implementación.
3. Se debe designar y respaldar a cada responsable
• Cada responsable debe estar respaldado por otro, que lo suple en caso de
baja o ausencia.
59
Capítulo 3. Criterios para la selección de una metodología ágil
adecuada para el desarrollo de software.
60
A continuación, se muestran los temas que forman parte del capítulo 3 los cuales son el
planteamiento del problema, los objetivos generales y específicos, las preguntas de
investigación, la justificación, la delimitación del problema, de igual forma se describe la
revisión sistemática de la literatura que se siguió para dar respuesta a las preguntas de
investigación y cumplir con los objetivos y por último se define un análisis crítico, así como
las recomendaciones y conclusión.
3.1 Planteamiento del problema
Para las empresas que se encuentran dentro del ámbito de desarrollo de software es de vital
importancia seleccionar una metodología que les asegure una mejor calidad y un mejor
proceso en el desarrollo de software. Las metodologías ágiles se han posicionado fuertemente
en estas empresas, ya que una de sus principales características es que proporcionan una
mayor flexibilidad en los proyectos actuales debido a que estos necesitan de una
comunicación constante con el cliente, son altamente colaborativos y con estas metodologías
son más adaptables al cambio que pueda llegar a tener el sistema por las constantes
retroalimentaciones que se tienen.
Algunas de las ventajas que tienen las metodologías ágiles es que presentan una
solución para los proyectos en los cuales los requerimientos cambian constantemente, buscan
obtener resultados en menor tiempo sin afectar la calidad, así como también involucrar a los
usuarios potenciales desde etapas tempranas del proyecto con las entregas continuas, por el
contrario, elegir una mala metodología puede llevar a que los tiempos de entrega sean
mayores a los acordados, que no se aborden de manera más eficiente los cambios que puedan
llegar a surgir en los requerimientos y que esto afecte la calidad del producto.
Lopes (2019), mencionan que el entorno empresarial competitivo ha obligado a las
organizaciones a adoptar métodos de trabajo más flexibles, con la capacidad de afrontar el
cambio con mayor facilidad, estos métodos en el área de desarrollo de software se conocen
como métodos ágiles y se han vuelto más populares desde 2001 con la creación del manifiesto
ágil. Así mismo mencionan que durante los últimos años el porcentaje de empresas que
adoptan alguna metodología ágil aumentó del 14% al 65%.
Bakhtouchi y Rahmouni (2018), mencionan que la selección de una metodología
depende de muchos factores y no existe una metodología universal que se pueda utilizar para
61
cualquier tipo de proyecto. De igual forma dice que la adecuada elección es crucial para el
éxito de un proyecto de desarrollo de software y el uso de una metodología inadecuada
implica un alto riesgo de no desarrollar software de alta calidad a tiempo y dentro del
presupuesto.
Hoy en día estos cambios que pueden llegar a tener los proyectos actuales están muy
bien abordados por estas metodologías, por lo que es importante identificar y determinar los
criterios que permitan seleccionar una metodología ágil adecuada para el desarrollo de un
proyecto de software.
3.1.1 Objetivo general
Realizar un análisis de los criterios que permiten seleccionar de forma adecuada una
metodología ágil de desarrollo de software y proponer una lista de los criterios identificados.
3.1.2 Objetivos específicos
• Identificar los criterios o lineamientos dentro de las metodologías ágiles que permitan
determinar cuál es la más adecuada de acuerdo con el proyecto a desarrollar.
• Identificar factores dentro de los proyectos que permiten seleccionar una metodología
ágil de desarrollo de software.
• Realizar una lista de los criterios que permitan a las empresas o ingenieros en
desarrollo de software escoger la metodología ágil que mejor se adecue al proyecto a
desarrollar.
3.1.3 Preguntas de investigación
Pregunta general
¿Cuáles son los criterios o lineamientos que deben considerarse al momento de seleccionar
una metodología ágil adecuada para el desarrollo de software?
Preguntas específicas
¿Cuáles son las características en los proyectos de software que podrían ser tomadas en
cuenta al momento de seleccionar una metodología ágil de desarrollo de software?
¿Cuáles son las características en las metodologías ágiles que podrían ser tomadas en cuenta
al momento de ser seleccionadas para algún proyecto de desarrollo de software?
¿Qué tanto incide en el éxito de un proyecto de software la elección de la metodología ágil
adecuada?
62
¿Cuáles son las diferencias que tienen las metodologías ágiles de desarrollo de software que
pueden afectar al momento de ser seleccionadas en un proyecto de software?
¿Cuál es la lista de los criterios más utilizados para la selección de una metodología ágil más
adecuada para el desarrollo de un proyecto de software?
3.1.4 Justificación
Uno de los retos más importantes actualmente en el desarrollo de software es
determinar cuál metodología es la que mejor se adecúa al proyecto a desarrollar, por lo que
es importante analizar e identificar esos factores que permitan decidir entre una u otra.
Este trabajo va a generar un beneficio invaluable para las empresas de desarrollo de
software, ya que servirá como guía o referencia al momento de decidir la metodología ágil
de desarrollo de software que se usará en el proyecto a realizar proporcionando así criterios
o lineamientos que les permitan identificar cuál es la que mejor se adapta a la naturaleza del
producto que se va a desarrollar, así como al equipo de trabajo con el que cuenta la compañía.
Así mismo permitirá a los estudiantes de ingeniería de software y de este campo poder
tener una manera de identificar qué metodología deberían seguir al momento de empezar
algún proyecto de software y que se adecúe a lo que se va a realizar, al equipo de desarrollo
y a los recursos disponibles.
Este trabajo va a contribuir en la disciplina debido a que en la actualidad no existe
literatura alguna de que las empresas de software en México sigan algún tipo de modelo que
les permita determinar con base en la magnitud de su proyecto y el equipo de desarrollo con
el que cuenta qué metodología deberían implementar.
3.2 Delimitación del problema
El presente estudio aborda la temática de metodologías ágiles, así como las características
dentro de los proyectos de desarrollo de software para su análisis e identificación de criterios
o factores clave que ayuden al momento de seleccionar una metodología ágil. Este trabajo se
desarrollará para proporcionar una lista de criterios que sirva como guía o referencia para las
empresas de desarrollo de software al momento de seleccionar una metodología ágil. Esta
investigación se llevará a cabo en el periodo septiembre a noviembre del 2021.
Limitaciones
63
• Este trabajo se limitará a identificar los criterios para la selección de metodologías
ágiles de desarrollo de software mediante la revisión sistemática de la literatura.
• No se propondrán nuevos criterios solo se identificarán aquellos dados por distintos
autores en trabajos de investigación.
• Solo se analizarán metodologías ágiles, quedan fuera las metodologías tradicionales.
3.3 Hipótesis
En el presente estudio no se planteará una hipótesis debido a que este trabajo es de tipo
descriptivo y no intenta pronosticar una cifra o hecho.
Sampieri (2014) afirma que
Las hipótesis son las guías de una investigación o estudio. Las hipótesis indican lo
que tratamos de probar y se definen como explicaciones tentativas del fenómeno
investigado. Se derivan de la teoría existente y deben formularse a manera de
proposiciones. De hecho, son respuestas provisionales a las preguntas de
investigación. No, no en todas las investigaciones cuantitativas se plantean hipótesis.
El hecho de que formulemos o no hipótesis depende de un factor esencial: el alcance
inicial del estudio (p.104)
De acuerdo con lo anterior Sampieri (2014), menciona que cuando el alcance del
estudio es de tipo descriptivo solo se formula una hipótesis cuando se pronostica un hecho o
dato.
3.4 Método
El método utilizado en este trabajo de investigación será la revisión sistemática de la
literatura para analizar los estudios relacionados con la formulación de criterios que sirvan
como guía para seleccionar una metodología ágil de desarrollo de software adecuada.
Según Kitchenham y Charters (2007) la revisión sistemática de la literatura es una
forma de estudio secundario que sigue una metodología bien definida para identificar, evaluar
e interpretar toda la investigación disponible que sea relevante para una pregunta de
investigación, área temática o fenómeno de interés mediante estudios primarios.
De igual forma menciona que hay muchas razones para realizar una revisión
sistemática de la literatura las cuales se mencionan a continuación.
• Resumir la evidencia existente sobre un tratamiento o tecnología
64
• Identificar cualquier brecha en la investigación actual con el fin de sugerir áreas para
más investigación.
• Proporcionar un marco o antecedentes para posicionar adecuadamente los nuevos
trabajos de investigación.
La revisión sistemática de la literatura implica una serie de actividades importantes
que se deben seguir. Kitchenham y Charters (2007) describen en su guía las fases para el
correcto desarrollo de la RSL.
Se desarrollará el proceso de búsqueda mediante la revisión sistemática de la literatura
inspirada en la guía Kitchenham y Charters (2007), donde se pueden apreciar fases como las
que se muestran a continuación.
Figura 6 Fases de la revisión sistemática de la literatura.

Construcción propia a partir de Guidelines for Performing Systematic Literature Reviews in Software Engineering
por Kitchenham y Charters. 2007.
3.5 Proceso de búsqueda
Según Kitchenham y Charters (2007), es importante determinar y seguir una estrategia de
búsqueda para la revisión sistemática de la literatura. Para realizar una búsqueda es
fundamental identificar los distintos términos de búsqueda derivados de la pregunta de
investigación. Se han utilizado conceptos claves como “Agile methodology”, “selection”,
“software development” y sinónimos de estas palabras. Los términos se han escrito en inglés,
debido a que la mayoría de las bases de datos están en ese idioma. A continuación se muestran
los términos de búsqueda empleados en este trabajo de investigación.
Tabla 1 Términos de búsqueda
Concepto Términos de búsqueda
65
Agile methodology
Agile methodology
Agile methodologies
Selection
Election
Selecting
Selection
determin
evaluaution
implement
Software development
software development
software project
Nota: Construcción propia, 2021.
Con la identificación de los términos de búsqueda anteriores se formó una cadena de
búsqueda mediante la combinación de las diferentes palabras claves y utilizando los
conectores booleanos “OR”, para definir las diferentes variables de los términos y “AND”
para unir los diferentes conceptos. A continuación, se muestra la cadena de búsqueda
utilizada para la recopilación de los estudios primarios relevantes para la investigación.
("Agile methodology" OR "Agile methodologies") AND ("selection" OR "selecting" OR
"election" OR “determin” OR “evaluation” OR “implement”) OR ("Agile methodology" OR
"Agile methodologies") AND ("selection" OR "selecting" OR "election" OR “determin” OR
“evaluation” OR “implement”) AND ("software development" OR "software project")
3.5.1 Criterios de inclusión y exclusión
Según Kitchenham y Charters (2007), los criterios de selección tienen el propósito de
identificar aquellos estudios primarios que proporcionan información necesaria para
responder las preguntas de investigación. A continuación se muestran los criterios de
inclusión y exclusión que se utilizaron para filtrar los estudios e identificar los más relevantes
para este trabajo de investigación.
Tabla 2 Criterios de inclusión y exclusión
Criterios de inclusión Criterios de exclusión
CI1 El estudio es un artículo, revista o tesis. CE1 El estudio es un libro, curso o estándar
CI2 El estudio fue publicado entre el año 2007 CE2 Estudios que no tengan acceso al texto
y 2021 completo
CI3 El estudio está escrito en idioma inglés o CE3 Es una investigación duplicada (Aparece en
español más de una base de datos)
66
CI4 El título y resumen tratan sobre temas
CE4 Es una investigación previa a un estudio más
relacionados con metodologías ágiles de
completo de la misma investigación
desarrollo de software y su elección
CI5 El estudio responde al menos una CE5 Estudios que no sean una versión completa
pregunta de investigación y descargable
3.6 Proceso de selección
Para la selección de estudios lo primero que se realizó fue una búsqueda usando la cadena
formulada con las palabras claves que se muestran en la tabla uno, en tres fuentes de
información las cuales se muestran a continuación.
• IEEEXplore
• LA Referencia
• Core
Kitchenham y Charters (2007), mencionan que una vez obtenidos los estudios, es
necesario evaluarlos para determinar qué tan útiles resultan para el trabajo de investigación.
Por lo que es importante aplicar los criterios de selección que tienen el propósito de
identificar aquellos estudios que den respuesta a las preguntas de investigación. A
continuación se muestra el proceso de selección aplicando los criterios de inclusión y
exclusión en tres etapas con el objetivo de filtrar aquellos documentos que sean de utilidad.
Para la selección de los estudios se agruparon los criterios de inclusión y exclusión
en tres etapas diferentes para poder filtrar los documentos obtenidos y obtener aquellos que
son relevantes para las preguntas de investigación. A continuación se describen las etapas
seguidas en este proceso.
Etapa 1
• Para la primera etapa se usaron cuatro criterios, tres de inclusión y uno de exclusión
para elegir los estudios que cumplieran con los siguientes criterios.
• El estudio fue publicado entre el año 2007 y 2021 AND (CI2)
• El estudio es un artículo OR revista OR tesis AND (CI1)
• El estudio está escrito en idioma inglés o español AND (CI3)
• El estudio es un libro, curso o estándar (CE1)
Etapa 2
67
Para la segunda etapa se utilizaron cuatro criterios de selección, tres de exclusión y uno de
inclusión los cuales se muestran a continuación.
• El título o resumen tratan sobre temas relacionados con metodologías ágiles de
desarrollo de software y su elección AND (CI4)
• Estudios que no tengan acceso al texto completo AND (CE2)
• Es una investigación duplicada (Aparece en más de una base de datos) AND (CE3)
• Es una investigación previa a un estudio más completo (CE4)
Etapa 3
Para la tercera etapa se usaron dos criterios de selección, uno de inclusión y uno de exclusión
los cuales permitieron obtener aquellos estudios que responden a las preguntas de
investigación.
• El estudio responde al menos una pregunta de investigación AND (CI5)
• CE5 Estudios que no sean una versión completa y descargable (CE5)
A continuación se muestra el proceso de selección de las fuentes aplicando las tres
etapas mencionadas anteriormente para obtener los estudios más relevantes que respondan a
las preguntas de investigación.
Resultados
Etapa 1 Etapa 2 Etapa 3
Fuente Cadena de búsqueda resultante de
búsqueda
CI2 CI3 CI1 CE1 CI4 CE2 CE3 CE4 CI5 CE5
("Agile methodology" OR "Agile methodologies") AND
("selection" OR "selecting" OR "election" OR “determin” OR
“evaluation” OR “implement”) OR ("Agile methodology" OR
IEEEXplore 137 127 17 7
"Agile methodologies") AND ("selection" OR "selecting" OR
"election" OR “determin” OR “evaluation” OR “implement”)
AND ("software development" OR "software project")
CORE 4814 2143 21 2
LA Referencia 55 19 5 1
Total 4960 2247 43 10
Figura 7 Proceso de selección de estudios primarios.
Construcción propia, 2021.
Con la cadena de búsqueda se obtuvo un total de 4960 estudios de las tres fuentes de
información sin aplicar ningún criterio, de la base de datos IEEEXplore se obtuvieron 137,
en CORE se obtuvieron 4814 y en LA Referencia se obtuvieron 55.
68
En la primera etapa se filtraron 2247 estudios. En esta fase se identificaron aquellos
trabajos que estuvieran en un rango del 2007 al 2021, documentos que fueran un artículo,
revista o tesis, que estuvieran en el idioma inglés o español y que no fuera un libro, estándar
o algún curso.
En la segunda etapa se identificaron 45 estudios que tuvieran en el título o en el
resumen temas relacionados con las metodologías ágiles y con su selección, así mismo se
eliminaron aquellos estudios que no tuvieran acceso al texto completo, que fueran una
investigación duplicada que apareciera en alguna de las otras fuentes de información y
también se desecharon los documentos que fueran una investigación previa a un estudio más
completo.
En la tercera etapa se identificaron los documentos utilizados para responder a las
preguntas de investigación y que pudieran ser descargados en el cual se obtuvieron 10
estudios que responden al menos a una de las preguntas de investigación.
3.7 Evaluación de la calidad
A continuación, se muestra una tabla con las preguntas que permitirán evaluar la calidad de
los estudios identificados en la revisión sistemática de la literatura. Donde “Y” significa Sí,
N, significa No, y Parcial.
Tabla 3 Evaluación de la calidad
Pregunta IEEE Xplore LA Referencia CORE
¿Están claramente Y Y Y
especificados los objetivos
de la investigación?
¿El estudio fue diseñado Y Y Y
para lograr objetivos?
¿Se describen claramente las Y Y Y
técnicas utilizadas y se
justifica su selección?
¿Se miden adecuadamente Y Parcial Y
las variables consideradas
para el estudio?
¿Se describen claramente los Y Y Y
métodos de recopilación de
datos?
¿Se describen Y Y Y
adecuadamente los datos
recopilados?
¿Es claro el propósito de Y Parcial Y
análisis de datos?
¿Se utilizan técnicas Parcial N Parcial
estadísticas para analizar los
datos adecuadamente
69
descritas y su uso está
justificado?
¿Se presentan resultados Y Parcial Y
negativos?
¿Los investigadores discuten Y Y Y
algún problema con la
validez de los resultados?
¿Se responden Y Y Y
adecuadamente las
preguntas de investigación?
¿Qué tan claros son los Y Y Y
vínculos entre los datos, la
interpretación y las
conclusiones?
Nota: Creación propia a partir de Revisión sistemática de la literatura por la Universidad Veracruzana. 2021.
3.8 Extracción de datos
En esta etapa según Kitchenham y Charters (2007), se deben diseñar formularios de
extracción de datos para registrar con precisión la información obtenida de los estudios. Los
formularios deben estar diseñados para recopilar toda la información necesaria que permita
abordar las preguntas de investigación y contener información estándar que incluya nombre
del revisor, fecha, título, autores, revista, detalles de la publicación y espacio para
observaciones.
Se diseñó el formulario tomando como base lo descrito por Kitchenham y Charters
(2007), en el cual se extrajeron los datos de los estudios que cumplieron con la tercera etapa
de selección y que darán respuesta a las preguntas de investigación. A continuación se
muestra el formulario utilizado para la recolección de los datos.
Tabla 4 Formulario de extracción de datos
Elementos de
datos Valor
Identificador
Fuente
Título
Autores
Publicación
Año de
publicación
Tipo de
publicación
Resumen
Objetivo del
estudio
70
Aporte a
nuestro
estudio
Criterios
identificados
Relevancia
Observaciones
Nota: Construcción propia a partir de “Guidelines for performing Systematic Literature Reviews in Software
Engineering” por Kitchenham y Charters. 2007.
Siguiendo el formulario anterior se recopilaron los datos de los 10 estudios
identificados en el proceso de selección para dar respuesta a las preguntas de investigación.
A cada estudio se le puso un identificador en este caso números iniciando por el uno hasta el
diez, la fuente donde fue extraído el estudio, título del estudio, los autores, donde fue
publicado, año de publicación, tipo de publicación si era un artículo, tesis o revista, resumen
de la investigación, objetivo del estudio, lo que aporta a este trabajo de investigación, criterios
de selección descritos en el estudio en caso de que hubiese, la relevancia para esta
investigación tomando como medidas baja, media o alta.
A continuación, se muestra el formulario de extracción de datos aplicado al primer
estudio analizado, con el identificador número uno.
Tabla 5 Formulario de extracción de datos 1
Elementos de
datos Valor
Identificador 1
Fuente IEEEXplore
Título A multicriteria approach for selection of agile methodologies in software
development projects
Autores Vanessa B. S. Silva, Fernando Schramm, Adriana C. Damasceno
Revista 2016 IEEE International Conference on Systems, Man, and Cybernetics (SMC)
Año de
publicación 2016
Tipo de
publicación Artículo
Este artículo presenta un enfoque, basado en el método multicriterio SMARTER,
que puede ser útil para respaldar decisiones que impliquen la selección de la
metodología de desarrollo de software ágil más adecuada para pequeñas y
Resumen
medianas empresas. El inicio de este estudio fue una investigación sobre criterios
medibles que deben ser considerados en este tipo de decisiones con el objetivo de
dar respuesta a las necesidades de proyectos específicos
El objetivo de este trabajo es proporcionar la estructuración del problema de
decisión que implica la elección de una metodología ágil para apoyar el desarrollo
Objetivo del
de software, que incluye la búsqueda de las principales metodologías ágiles
estudio
utilizadas en proyectos reales y la definición de un conjunto de criterios medibles
que deben ser considerados en la evaluación de tales metodologías.
71
En este estudio el autor establece tres dimensiones principales, la configuración
Aporte a
del proyecto, complejidad del proyecto y gestión del proyecto las cuales
nuestro
comprenden aspectos o criterios que sirven como referencia para seleccionar una
estudio
metodología ágil.
Para la configuración del proyecto establece los siguientes criterios, medio
ambiente, ubicación, diseño y equipo de desarrollo. Para la complejidad del
proyecto son gestionar cambios en requisitos, manejar el tiempo del proyecto y
Criterios coste estimado, manejar la escalabilidad del proyecto, manejar decisiones no
identificados aprobadas de clientes, equilibrar el negocio y necesidades del cliente. Para la
gestión del proyecto son cambios en los requisitos y necesidades, estimación del
tiempo y costo, decisiones de clientes no aprobadas y retraso en el tiempo de
entrega.
Relevancia Media
Observaciones Algunos criterios no están claramente definidos
A continuación, se muestra el formulario de extracción de datos aplicado al segundo
estudio analizado, con el identificador número dos.
Elementos de
Valor
datos
Identificador 2
Fuente IEEEXplore
A Novel Approach for Agile Software Development Methodology Selection Using
Título
Fuzzy Inference System
Autores Anand Kumar Rai, Shalini Agarwal, Abhishek Kumar
2018 International Conference on Smart Systems and Inventive Technology
Publicación
(ICSSIT)
Año de
publicación 2018
Tipo de
Una metodología ágil de desarrollo de software ha sido más popular en la industria
del software en términos de entrega rápida de software, menos documentación,
Resumen más satisfacción y más interacciones entre desarrolladores y usuarios. En este
artículo se propone un modelo basado en el sistema de inferencia difusa para
seleccionar un método ágil apropiado para el desarrollo de software exitoso.
El objetivo de este estudio es identificar el determinante de la selección del método
Objetivo del ágil y ayudar a las organizaciones a determinar qué metodología de desarrollo de
estudio software se debe utilizar en los proyectos para facilitar la entrega de estos dentro
del cronograma, dentro del costo y cumplir con todos los requisitos del proyecto.
En este trabajo el autor establece una lista de 10 determinantes del desarrollo de
Aporte a
software ágil que son factores claves en la selección de una metodología ágil
nuestro estudio
adecuada de desarrollo de software.
Los determinantes del desarrollo de software ágil como los menciona el autor son
el tamaño de proyecto, incertidumbre del requisito, flexibilidad de costos y
Criterios
horarios, criticidad del software, complejidad del proyecto, componente
identificados
reutilizable, tamaño del equipo, participación de usuario, flexibilidad del desarrollo
y cohesión de equipo.
Relevancia Alta
Observaciones Ninguna
72
A continuación, se muestra el formulario de extracción de datos aplicado al tercer
estudio analizado, con el identificador número tres.
Elementos de
Valor
datos
Identificador 3
Fuente IEEEXplore
Título Agile Methodologies Selection Toolbox
Autores E. Mnkandla, B. Dwolatzky
Publicación International Conference on Software Engineering Advances (ICSEA 2007)
Año de
publicación 2007
Tipo de
Las metodologías ágiles han estado en la escena del desarrollo de software durante
más de cinco años y esto ha resultado en la proliferación de una serie de enfoques
para esta nueva forma de desarrollar software. Los problemas ágiles iniciales se
centraron en la definición de qué son las metodologías ágiles y la evidencia
Resumen
empírica de su aplicación exitosa. Hoy en día, uno de los desafíos más formidables
es la selección de procesos ágiles apropiados para un proyecto determinado y el
siguiente problema al que ya se enfrentan algunos profesionales es la certificación
ágil.
El objetivo de este estudio es presentar una herramienta que puede simplificar el
Objetivo del
proceso de selección del método ágil más apropiado para un proyecto
estudio
determinado.
Aporte a Presenta una matriz que se puede utilizar para clasificar proyectos y conducir a la
nuestro estudio elección de una metodología la cual contiene cinco parámetros importantes.
Los parámetros que se presentan son la estabilidad de requisitos, tamaño del
Criterios
proyecto, periodo de tiempo de desarrollo, complejidad del proyecto y riesgo del
identificados
proyecto.
Relevancia Media
A continuación, se muestra el formulario de extracción de datos aplicado al cuarto estudio
analizado, con el identificador número cuatro.
Elementos de
Valor
datos
Identificador 4
Fuente IEEEXplore
Título Extended Decision Support Matrix for Selection of SDLC-Models on Traditional and
Agile Software Development Projects
Autores P.M. Khan, M. M. Sufyan Beg
Publicación 2013 Third International Conference on Advanced Computing and Communication
Technologies (ACCT)
73
Año de
publicación 2013
Tipo de
Los proyectos de desarrollo de software pueden variar considerablemente en
dificultad, tamaño y tipo. Esto ha llevado a la evolución y el desarrollo de muchas
metodologías de gestión de proyectos asociadas y modelos SDLC estándar. Este
Resumen documento reconoce los riesgos asociados con la selección incorrecta de modelos
SDLC en proyectos de software críticos para el negocio y ofrece una solución
pragmática al proponer una práctica matriz de selección para elegir los modelos
SDLC que mejor se ajustan a diferentes tipos de proyectos de desarrollo de
software, que cubre tanto las metodologías tradicionales como las ágiles.
El objetivo de este estudio es proponer mejores métodos y orientación prescriptiva
Objetivo del
para el proceso de toma de decisiones para la selección correcta del modelo SDLC
estudio
en proyectos de desarrollo de software críticos para el negocio.
Aporte a Aporta información sobre la importancia de seleccionar una metodología de
nuestro desarrollo adecuada y consecuencias de seleccionar una incorrecta y algunos
estudio criterios para seleccionar una metodología.
Los criterios mencionados en este estudio son criticidad empresarial, participación
Criterios
del cliente a lo largo del ciclo de vida, claridad de requisitos, volatilidad de
identificados
requisitos y disponibilidad de usuarios comerciales.
Relevancia Media
A pesar de que es un estudio centrado en seleccionar entre una metodología
tradicional y una ágil brinda algunos criterios que podrían ser tomados en cuenta
Observaciones
para aplicarlos únicamente en los modelos ágiles y proporciona información sobre
la importancia de seleccionar una adecuada metodología.
A continuación, se muestra el formulario de extracción de datos aplicado al quinto
estudio analizado, con el identificador número cinco.
Elementos de
Valor
datos
Identificador 5
Fuente IEEEXplore
Factors Influencing the Adoption of Agile Methodology within SMEs in Cape Town
Título
Software Development Projects
Autores Barrington Bruiners, Osden Jokonya
Publicación 2019 International Multidisciplinary Information Technology and Engineering
Conference (IMITEC)
Año de
publicación 2019
Tipo de
Hay muchas pequeñas y medianas empresas (PYME) de desarrollo de software en
Ciudad del Cabo que continúan haciendo uso de la metodología de desarrollo de
Resumen software en cascada rígida y heredada. El estudio utilizó el marco tecnológico-
organizacional-ambiental para obtener aquellos factores para comprender cuáles,
sino todos, influyen en la adopción de una metodología ágil.
74
Este estudio tuvo como objetivo identificar y comprender los factores que influyen
Objetivo del
en la adopción de una metodología ágil dentro de las pymes en Ciudad del Cabo,
estudio
Sudáfrica
Aporte a
nuestro Este trabajo aporta algunas características y diferencias que existen entre las
estudio distintas metodologías ágiles mencionadas en este estudio.
Criterios
identificados Sin criterios.
Relevancia Baja
Observaciones Solo se utilizará la información proporcionada de las metodologías ágiles.
A continuación, se muestra el formulario de extracción de datos aplicado al sexto
estudio analizado, con el identificador número seis.
Elementos de
Valor
datos
Identificador 6
Fuente IEEEXplore
Project characteristics used for methodology selection to develop the software
Título
project
Autores S. Balaji, Mohaned Al. Obaidy
Publicación 2016 International Conference on Electrical, Electronics, and Optimization
Techniques (ICEEOT)
Año de
publicación 2016
Tipo de
Existen numerosas metodologías disponibles en la industria de TI para desarrollar
proyectos. Depende de ciertas características del proyecto. Vamos a discutir sobre
cómo se elige la metodología utilizando la característica del proyecto. Para este
Resumen desarrollo tenemos que considerar las características del proyecto como el tamaño
del proyecto, la estabilidad del requisito y el entorno, la relación del equipo, el
compromiso con el cliente, el alcance del proyecto, la claridad del riesgo y la
flexibilidad de las partes interesadas.
Objetivo del El principal objetivo de este estudio es reducir el tiempo de elección de la
estudio metodología por parte del cliente y del equipo de gestión del proyecto.
Aporte a
nuestro Este estudio aporta algunas características dentro de los proyectos de software
estudio usados para elegir una metodología de desarrollo.
Las características del proyecto descritas en este estudio son el tamaño del
Criterios proyecto, tamaño del equipo, estabilidad de requisitos, relación del equipo,
identificados compromiso con el cliente, claridad del alcance, claridad del riesgo, estabilidad del
entorno y la flexibilidad de las partes interesadas.
Relevancia Alta
Las características dadas aplican tanto para la selección de metodologías
Observaciones tradicionales y ágiles por lo que es importante identificar las que sean relevantes
para esta investigación.
75
A continuación, se muestra el formulario de extracción de datos aplicado al séptimo
estudio analizado, con el identificador número siete.
Elementos de
Valor
datos
Identificador 7
Fuente IEEEXplore
Título Towards Tool Support for Situational Engineering of Agile Methodologies
Autores Zahra Shakeri Hossein Abad, Mahsa Hasani Sadi, Raman Ramsin
Publicación 2010 Asia Pacific Software Engineering Conference (ICEEOT)
Año de
publicación 2010
Tipo de
En la última década se han propuesto varias metodologías, prácticas y técnicas de
desarrollo de software ágil, algunas presentan ideas novedosas, mientras que
muchas simplemente se componen de tareas y técnicas tomadas de metodologías
Resumen ágiles prominentes. Cada una de estas metodologías prescribe un conjunto de
prácticas y técnicas que se consideran apropiadas para su aplicación en un contexto
específico. Sin embargo, no existe un método único que se adapte a todas las
situaciones del proyecto.
Objetivo del El objetivo de este estudio es proporcionar una base para la aplicación de la
estudio ingeniería de métodos situacionales basada en ensamblajes para el desarrollo de
metodologías ágiles a medida.
Aporte a Describe un conjunto completo de características metodológicas relevantes, así
nuestro como también un conjunto de características que deben ser abordadas por las
estudio metodologías dependiendo la situación del proyecto
Criterios
identificados Ninguno.
Relevancia Baja
Es un estudio que proporciona una serie de requisitos que pueden ser de utilidad
Observaciones
para la investigación
A continuación, se muestra el formulario de extracción de datos aplicado al octavo
estudio analizado, con el identificador número ocho.
Elementos de
Valor
datos
Identificador 8
Fuente CORE
Título A Quantitative Framework for the Evaluation of Agile Methodologies
Autores Karla Mendes Calo, Elsa Estevez, Pablo Rubén Fillottrani
Publicación Centro de Servicios en Gestión de Información.
Año de
publicación 2010
76
Tipo de
Las metodologías para el desarrollo ágil de software se basan fundamentalmente
en la colaboración con los usuarios del software durante todo el proceso de
desarrollo, la simplicidad para adaptar el producto a los cambios en los requisitos
Resumen y en la entrega incremental del producto. Basados en el Manifiesto Ágil, han sido
aceptados y se utilizan con éxito en proyectos donde los requisitos detallados se
desconocen al principio y se identifican durante el proceso de desarrollo a partir
de las interacciones con los usuarios y la retroalimentación así obtenida.
El objetivo de este trabajo es presentar un marco de evaluación de metodologías
Objetivo del
ágiles que permitan evaluar cómo las metodologías alcanzan los valores declarados
estudio
por el Manifiesto Ágil
Este estudio proporciona un marco de evaluación de dos metodologías ágiles muy
Aporte a
populares que son SCRUM y XP, por lo que describe estos métodos a detalle
nuestro
ayudando a identificar algunas características de estas que pueden ayudar al
estudio
momento de ser seleccionadas.
Propusieron 4 postulados para comparar ambas metodologías los cuales son valora
al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
Criterios herramientas, valorar el desarrollo de software que funciona sobre una
identificados documentación exhaustiva, valorar la colaboración con el cliente sobre la
negociación contractual y valorar la respuesta al cambio por encima del
seguimiento de un plan. Cada una de ellas define un conjunto parámetros a detalle.
Relevancia Media
Es un estudio que proporciona características de dos metodologías ágiles
Observaciones
importantes por lo que es de utilidad.
A continuación, se muestra el formulario de extracción de datos aplicado al noveno
estudio analizado, con el identificador número nueve.
Elementos de
Valor
datos
Identificador 9
Fuente CORE
Evaluating Project Characteristics for Selecting the Best-fit Agile Software
Título
Development Methodology: A Teaching Case
Autores Yousra Abdo Harb, Cherie Noteboom, Surendra Sarnikar
Publicación Beadle Scholar en Dakota State University
Año de
publicación 2015
Tipo de
Los métodos ágiles han atraído una atención significativa en la industria como un
enfoque para el desarrollo de software y la gestión de proyectos de TI debido a los
entornos comerciales que cambian rápidamente, los costos y las presiones
Resumen
competitivas. Sin embargo, elegir el enfoque correcto entre varios modelos de
desarrollo ágil es una decisión compleja y de varios criterios que puede tener
implicaciones significativas en el éxito del proyecto.
77
El objetivo de este trabajo es presentar un caso de enseñanza diseñado para ayudar
Objetivo del a los estudiantes de Sistemas de Información a mejorar sus habilidades para
estudio comprender y evaluar requisitos comerciales complejos y seleccionar la
metodología de desarrollo de software más adecuada para satisfacer las
necesidades de un proyecto de TI específico y de la organización.
Este estudio describe distintas metodologías ágiles proporcionando información
Aporte a
relevante necesaria para identificar sus diferencias, así mismo aporta una serie de
nuestro
características de estas metodologías que pueden ser utilizados para seleccionar
estudio
una metodología respecto a un proyecto.
Dentro de las características de las metodologías mencionadas en el estudio están
Criterios
el estilo de desarrollo, tamaño del equipo del proyecto, distribución del equipo,
identificados
intervención del cliente, nivel de documentación y periodo de tiempo de iteración.
Relevancia Alta
A continuación, se muestra el formulario de extracción de datos aplicado al décimo
estudio analizado, con el identificador número diez.
Elementos de
Valor
datos
Identificador 10
Fuente LA Referencia
Título Criterios para la selección de una metodología de gerencia de proyectos que
permita el desarrollo de proyectos eficientes en el área de infraestructura de IT
Autores Wlfrank Javier Quintana Diosa
Publicación Repositorio institucional biblioteca digital de la Universidad nacional de Colombia
Año de
publicación 2017
Tipo de
publicación Trabajo final de maestría
El presente documento expone una investigación mixta - cualitativa y cuantitativa,
de enfoque empírico-analítico, desarrollada con base en el diseño metodológico
propuesto por Quivy y Campenhoudt. Como propósito principal, busca establecer
Resumen
criterios priorizados que faciliten la selección de una metodología de gerencia de
proyectos, que permita el desarrollo de proyectos eficientes en un caso de estudio
relacionado con proyectos de infraestructura de IT, en una empresa específica.
Objetivo del El objetivo de este trabajo es establecer criterios priorizados que faciliten la
estudio selección de una metodología de gerencia de proyectos
Aporte a Describe algunas de las metodologías ágiles más populares actualmente,
nuestro aportando información relevante para identificar las diferencias entre los distintos
estudio métodos ágiles, así como también una serie de criterios que pueden ser tomados
en cuenta para la selección de una metodología.
En el estudio se mencionan algunas categorías las cuales son los requerimientos,
Criterios usuarios, documentación, tamaño del proyecto, soporte organizacional, miembros
identificados del equipo, criticidad del proyecto, plan de proyecto, costos, alcance,
comunicación, partes interesadas, desarrollo del proyecto, entrega de productos.
Relevancia Media
78
Los criterios establecidos se hicieron para comparar metodologías ágiles como
Observaciones PRINCE2 y PMBOK, pero algunos criterios pueden ser considerados para
seleccionar una metodología ágil distinta.
3.9 Síntesis de datos
Según Kitchenham y Charters (2007), la síntesis de datos implica cotejar y resumir los
resultados de los estudios primarios previamente identificados. A continuación se muestran
las gráficas de la clasificación de los estudios por año, por fuente de información, por
relevancia y porcentajes de los estudios basados en los temas que darán respuesta a las
preguntas de investigación.
En la siguiente gráfica se observa la distribución de los estudios primarios obtenidos
por año que son relevantes para este trabajo de investigación, fueron diez los estudios
primarios obtenidos en el proceso de selección de los cuales se puede apreciar que se obtuvo
solo un estudio de los años 2007, 2013, 2015, 2017, 2018, 2019 y dos estudios de los años
2010 y 2016.
Número de estudios primario por año

10
9
8
7
6
5
4
3
2
1
0
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
Figura 8 Número de estudios primarios por año.

Nota: Creación propia, 2021.
En la siguiente gráfica se muestra el número de documentos obtenidos por fuente de
información, donde se puede observar que en la base de datos IEEEXplore es donde se
obtuvieron un mayor número de estudios con siete documentos primarios que responde a las
preguntas de investigación, en CORE se obtuvieron dos estudios primarios y en LA
Referencia solo se obtuvo un estudio importante para este trabajo.
79
Número de documentos por fuentes de información
8
0
IEEEXplore CORE LA Referencia
Figura 9 Número de documentos por fuentes de información.

En la siguiente gráfica se muestra el porcentaje de las fuentes que abarcan algunos de
los temas que responden a las preguntas de investigación en donde se puede observar que el
54% de los estudios primarios identificados presentan criterios para seleccionar una
metodología, mientras que un 38% presentan información relevante que muestra las
características y diferencias que existen entre las diferentes metodologías ágiles y un 8%
equivale a los estudios que describen el impacto de una adecuada selección de metodología.
Porcentaje de fuentes basado en temas extraídos

8%
38% 54%
Estudios que presentan criterios de selección para una metodología
Estudios que presentan información relevante sobre metodologías ágiles
Estudios que presentan información sobre el impacto de una adecuada selección de

metodología
Figura 10 Porcentaje de fuentes basado en temas extraídos.

80
En la siguiente gráfica se muestra el porcentaje de los estudios primarios identificados
por relevancia tomando como medida las opciones de alta, media y baja, en el que se puede
observar que un 40% de los documentos obtenidos tienen una alta aportación, así mismo un
40% tiene una aportación media y un 20% tiene una baja aportación para este trabajo de
investigación.
Porcentajes de estudios por relevancia
20%
40%
40%
Alta Media Baja
Figura 11 Porcentajes de estudios por relevancia.

3.10 Resultados
A continuación, se da respuesta a las preguntas de investigación con los estudios obtenidos
a través de la revisión sistemática de la literatura para cumplir con los objetivos establecidos
en este trabajo de investigación y así determinar una lista de los criterios que sirvan como
referencia al momento de seleccionar una metodología ágil adecuada dependiendo del
proyecto a desarrollar. A continuación, se presenta la pregunta general seguida de las
preguntas específicas.
PIG. ¿Cuáles son los criterios o lineamientos que deben considerarse al momento de
seleccionar una metodología ágil adecuada para el desarrollo de software?
En la actualidad existen muchas metodologías ágiles por lo que las organizaciones que se
dedican al desarrollo de software se enfrentan a la difícil decisión de elegir que método ágil
se adecúa más a la naturaleza del proyecto a desarrollar. Por lo que en este trabajo se
identifica y proporciona una lista de factores dentro de los proyectos y las metodologías que
pueden ayudar a identificar la metodología ágil más adecuada.
81
Para determinar los criterios más cruciales que sirvan como guía al momento de la
selección de una metodología ágil se analizaron los criterios dados por distintos autores para
identificar aquellos que fueran descritos en más de un trabajo de investigación, aquellos
criterios mencionados por más de un autor se consideran relevantes para este trabajo de
investigación, ya que son criterios que aparecen en más de un estudio. Así mismo solo se
seleccionaron aquellos criterios que fueron definidos de manera clara y aquellos que
proporcionan una idea clara de cómo seleccionar una metodología.
Durante el análisis de los criterios algunos autores definen los criterios con base en
las características del proyecto y otros con algunas características particulares de las
metodologías, sin embargo, algunos de los criterios tanto para la parte de las características
de los proyectos como en la de las metodologías aplican su principio de selección con el
mismo propósito.
A continuación, se muestran los criterios enfocados al proyecto identificados por estar
presentes en más de un estudio.
• Tamaño del equipo del proyecto
• Tamaño del proyecto
• Estabilidad de requisitos
• Involucramiento del cliente
• Riesgo del proyecto
• Complejidad del proyecto
• Plazo de desarrollo
De igual manera se muestran aquellos criterios enfocados a las metodologías ágiles
de desarrollo de software que están presentes en más de un trabajo de investigación.
• Estilo de desarrollo
• Tamaño del equipo
• Distribución del equipo
• Participación del cliente
Sin embargo, existen algunos criterios que no fueron contemplados por más de un
autor, pero que aportan de manera clara un factor decisivo al momento de seleccionar una
82
metodología adecuada por lo que a continuación se en listan los criterios que están claramente
definidos y son clave al momento de seleccionar un método ágil de desarrollo.
Para los proyectos se muestran los siguientes criterios que no fueron contemplados
por más de un autor, pero que sí expresan de manera clara un principio para la selección de
una metodología ágil.
• Periodo de tiempo de iteración
• Nivel de documentación
Para las metodologías se muestran los siguientes criterios que no fueron
contemplados por más de un autor, pero que expresan de manera clara la forma en que sirven
como guía para seleccionar un método ágil adecuado.
Al final se agruparon aquellos criterios mencionados por más de un autor y aquellos que
resultan relevantes para seleccionar una metodología correcta. La lista de los criterios
cruciales para identificar qué metodología ágil se adapta mejor a un proyecto en específico
se presenta a continuación.
Tabla 15 Criterios para la selección de una metodología ágil
Criterios de selección enfocados al proyecto Descripción de los criterios
Tamaño del proyecto Se refiere al alcance principal del desarrollo
del proyecto, y se utiliza para clasificar si el
proyecto es grande o pequeño.
Tamaño del equipo del proyecto Se refiere a si es un equipo grande o

pequeño, incluyendo el número de
miembros que lo componen.
Estabilidad de requisitos Se refiere a la frecuencia en la que los
requisitos cambian a lo largo del proyecto.
Involucramiento del cliente Se refiere al nivel de participación por parte
del cliente dentro del proyecto
Riesgo del proyecto Se refiere al grado de riesgo que tendrá el
desarrollo de un proyecto.
Complejidad del proyecto Se refiere al nivel de cálculos pesados que
deben realizar los proyectos
83
Plazo de desarrollo Se refiere a la duración del tiempo del
desarrollo de un proyecto
Periodo de tiempo de iteración Se refiere al periodo de tiempo de iteración
establecido por las organizaciones
Nivel de documentación Hace referencia a la cantidad de
documentación del proyecto en particular.
Criterios de selección enfocados a las
metodologías ágiles
Tamaño del proyecto Se refiere al tamaño del proyecto que
abordan las metodologías.
Tamaño del equipo Se refiere al tamaño de los equipos dentro de
las metodologías.
Intervención del cliente Se refiere al nivel de participación por parte
del cliente establecido en las metodologías
Distribución del equipo Se refiere a la manera en que las
metodologías abordan la distribución de los
equipos de las organizaciones, puede ser
coubicado o distribuido.
Complejidad del proyecto Se refiere a cómo abordan el nivel de
complejidad de un proyecto las
metodologías ágiles
Estilo de desarrollo Se refiere al estilo de desarrollo aplicado por
las metodologías ágiles
Periodo de tiempo de iteración Se refiere a la duración del tiempo de las
iteraciones establecidas dentro de las
diferentes metodologías ágiles
Nivel de documentación Se refiere al nivel de documentación
requerida por cada metodología
3.10.1 Preguntas de investigación específicas
A continuación, se da respuesta a las preguntas de investigación específicas con los estudios
primarios identificados en la revisión sistemática de la literatura donde se identificaron los
criterios que sirven como guía al momento de seleccionar una metodología ágil adecuada y
las cuales se utilizaron para responder la pregunta de investigación general.
PI1. ¿Cuáles son las características en los proyectos de software que podrían ser
tomadas en cuenta al momento de seleccionar una metodología ágil de desarrollo de
software?
Abdo, Noteboom y Sarnikar (2015), mencionan en su estudio titulado “Evaluating Project
Characteristics for Selecting the Best-fit Agile Software Development Methodology: A
Teaching Case” que existen diferentes metodologías ágiles y elegir la que mejor se adapta es
84
un problema debido a las diferentes necesidades y requisitos de una organización o un
proyecto de software. Para identificar la metodología de desarrollo más apropiada presentó
una lista de criterios utilizados para determinar la metodología más adecuada para el
proyecto.
• Involucramiento con el cliente
• Producto final, puede ser de alta calidad o diseño simple
• Garantía de éxito
• Especificación de requisitos
• Tiempo de implementación
El involucramiento con el cliente se refiere al nivel de participación por parte del
cliente dentro del proyecto, el tamaño del equipo se refiere a si es un equipo pequeño o grande
incluyendo el número de integrantes, el producto final se refiere al nivel de calidad que debe
tener el producto final, puede ser de alta calidad o de diseño simple, la garantía de éxito hace
referencia al grado de éxito que debe obtener el proyecto de desarrollo, la especificación de
requisitos se refiere al nivel de cambio de los requisitos por parte del cliente, el tiempo de
implementación se refiere a la duración del proyecto, el periodo de tiempo de iteración se
refiere al periodo de tiempo de iteración establecido por parte de las organizaciones en sus
proyectos de software y el nivel de documentación hace referencia a la cantidad de
documentación requerida para el proyecto en particular (Abdo, Noteboom y Sarnikar, 2015).
Mnkandla y Dwolatzky (2007), presenta en su estudio titulado “Agile Methodologies
Selection Toolbox” una matriz que sirve como guía para clasificar proyectos con el fin de
determinar la idoneidad de utilizar metodologías ágiles para un proyecto determinado. Así
mismo menciona que para poder seleccionar la metodología más adecuada para un proyecto
en específico, lo primero que se debe hacer es entender el proyecto por lo que es importante
clasificarlos con el objetivo de encontrar la metodología que mejor se adapte. La matriz
enlista un conjunto de parámetros para clasificar los proyectos los cuales se muestran a
continuación.
85
La estabilidad de requisitos se refiere al grado de cambio que sufren los requisitos
con respecto a la variación del alcance, el tamaño del proyecto se refiere al número de
integrantes dentro de los equipos de proyectos, el plazo de desarrollo se refiere al tiempo que
tarda el periodo de desarrollo del proyecto, la complejidad se refiere al nivel de cálculos
pesados que deben realizar los proyectos y el riesgo del proyecto se refiere al grado de riesgo
que implica el desarrollo de un proyecto (Mnkandla y Dwolatzky, 2007).
Balaji y Obaidy (2016), mencionan en su artículo titulado “Project Characteristics
used for Methodology Selection to Develop the Software Project” que para seleccionar una
metodología de desarrollo es importante analizar las características del proyecto, para
encontrar criterios se analizó las ventajas y desventajas de las metodologías utilizadas para
el desarrollo del proyecto, con el propósito de reducir el tiempo de elección de una
metodología, por lo que describen una serie de características en los proyectos que permitan
elegir entre distintas metodologías. Los criterios se recopilaron mediante una discusión cara
a cara y la aplicación de una encuesta a profesionales de TI.
• Relación del equipo
• Compromiso con el cliente
• Claridad del alcance
• Claridad del riesgo
• Estabilidad del entorno
• Flexibilidad de las partes interesadas
El tamaño del proyecto se refiere al alcance principal del desarrollo del proyecto y se
utiliza para clasificar el tamaño puede ser grande o pequeño, el tamaño del equipo se refiere
86
a la cantidad de recursos humanos necesarios para el desarrollo del proyecto, la estabilidad
de requisitos se refiere a la frecuencia de los cambios realizados en los requisitos durante el
desarrollo del proyecto, la relación del equipo se refiere a la importancia de la relación del
equipo, todos los miembros deben conocer el estado del proyecto y cómo comunicarse entre
ellos ya sea que se encuentren en el extranjero o en el mismo sitio, el compromiso con el
cliente se utiliza para considerar el requisito del proyecto dado por el mismo, y a la
participación de este durante el proyecto, la claridad del alcance se refiere a que tan claro está
el alcance en cada una de las fases del proyecto, la claridad del riesgo se refiere a la capacidad
de analizar el riesgo del proyecto y el plan de mitigación para superar esa situación,
dependiendo de la complejidad del proyecto el riesgo será menor, la estabilidad del entorno
se refiere a la estabilidad del entorno para lanzar el proyecto en tiempo real, esto debe estar
claro para implementar el proyecto, la flexibilidad de las partes interesadas depende del
proceso que se deba desarrollar para obtener una mayor satisfacción del cliente (Balaji y
Obaidy, 2016).
PI2. ¿Cuáles son las características en las metodologías ágiles que podrían ser tomadas
en cuenta al momento de ser seleccionadas para algún proyecto de desarrollo de
software?
Kumar, Agarwal y Kumar (2018), definen en su estudio titulado “A Novel Approach for Agile
Software Development Methodology Selection Using Fuzzy Inference System” un marco para
estimar las metodologías ágiles con base en sus características de agilidad, lo que llevó a
identificar una serie de factores que influyen en la decisión de determinar la metodología ágil
de desarrollo más adecuada para un proyecto en particular. El autor define una lista de 10
determinantes del método ágil que son decisivos en la elección de una metodología ágil
adecuada. Con el objetivo de identificar que método ágil es el más apropiado determinado
por los factores de un proyecto en específico.
• Incertidumbre del requisito
• Flexibilidad de costos y horarios
• Criticidad del software
87
• Componente reutilizable
• Participación de usuario
• Flexibilidad de desarrollo
• Cohesión de equipo
Por otro lado, Abdo, Noteboom y Sarnikar (2015), mencionan en su estudio
nombrado “Evaluating Project Characteristics for Selecting the Best-fit Agile Software
Development Methodology: A Teaching Case” que con el surgimiento de las metodologías
ágiles es importante identificar un conjunto de características claves las cuales se muestran a
continuación.
• Intervención del cliente
El estilo de desarrollo de metodologías ágiles se basa en un proceso de desarrollo
iterativo e incremental realizado con un alto nivel de colaboración por equipos
autoorganizados. Los requisitos y el desarrollo evolucionan a través de la colaboración entre
los integrantes de los equipos que permite producir soluciones de mucha calidad para
satisfacer las necesidades cambiantes de los clientes (Abdo, Noteboom y Sarnikar, 2015).
Tamaño del equipo del proyecto. Los métodos ágiles agrupan a equipos pequeños y
un número reducido de equipos para proyectos, ya que, con equipos más pequeños, se
requieren menos procesos, planificación y coordinación para las actividades de los miembros
del equipo (Abdo, Noteboom y Sarnikar, 2015).
Distribución del equipo. En las metodologías ágiles, la distribución de equipos es un
tema complejo cuando participan equipos de diferentes organizaciones y en diferentes sitios
en un proyecto. Se pueden presentar distintos desafíos como la falta de comunicación, las
dificultades de coordinación, el estilo de trabajo y la cultura de un país (Abdo, Noteboom y
Sarnikar, 2015).
88
Intervención del cliente. Todos los métodos ágiles promueven una alta participación
del cliente, el estímulo y la comunicación continua y directa con el cliente cuando surgen
interrogantes sobre el proyecto. Dejar que el cliente participe continuamente en el esfuerzo
del desarrollo es una forma de empoderamiento y de colaboración del cliente (Abdo,
Noteboom y Sarnikar, 2015).
Nivel de documentación. Los métodos ágiles son procesos ligeros que se basan en el
conocimiento implícito de un equipo en contraposición a la documentación y hace más
énfasis en el desarrollo de la aplicación que en la documentación. Se utilizan documentos
ligeros para intercambiar opiniones, lo que reduce el consumo de recursos en términos de
tiempo y personas (Abdo, Noteboom y Sarnikar, 2015).
Periodo de tiempo de iteración. Los programas de lanzamientos de los métodos ágiles
pueden ser de dos semanas o hasta de seis meses. Por lo regular al final de cada versión, los
clientes pueden evaluar los productos y solicitar que se realicen cambios en las versiones
realizadas posteriormente (Abdo, Noteboom y Sarnikar, 2015).
PI3. ¿Qué tanto incide en el éxito de un proyecto de software la elección de la
metodología ágil adecuada?
Teaching Case” que las organizaciones dedicadas a desarrollar proyectos de software se
enfrentan al desafío de seleccionar la metodología de desarrollo de software más adecuada.
Así mismo mencionan que los gerentes de TI deben identificar y elegir entre diferentes
metodologías de desarrollo para satisfacer las necesidades del proyecto.
De igual forma dicen que los métodos ágiles han atraído la atención significativa en
la industria como un enfoque para el desarrollo de software y la gestión de proyectos de TI
debido a los entornos comerciales que cambian de manera rápida los costos y las presiones
competitivas. Por lo que elegir el enfoque correcto entre varias metodologías ágiles es una
decisión compleja y de varios criterios que pueden tener implicaciones significativas en el
éxito del proyecto (Abdo, Noteboom y Sarnikar, 2015).
De igual forma Khan y Sufyan, (2013), mencionan en su documento nombrado
“Extended Decision Support Matrix for Selection of SDLC-Models on Traditional and Agile
89
Software Development Projects” que la selección correcta de la metodología de desarrollo
de software ayudará a finalizar con éxito los proyectos de software críticos para la
organización, así como el cumplimiento de los objetivos comerciales propuesto al inicio
sobre el proyecto. Así mismo dice que en una encuesta realizada a gerentes del proyecto y
profesionales de la industria de TI sobre los impactos que tiene el seleccionar una
metodología incorrecta, se obtuvo como resultado que una mala elección puede arriesgar
seriamente el éxito del proyecto, ya que la selección correcta de una metodología adecuada
es vital para el resultado del proyecto.
PI4 ¿Cuáles son las diferencias que tienen las metodologías ágiles de desarrollo de
software que pueden afectar al momento de ser seleccionadas en un proyecto de
software?
Teaching Case” algunos de los métodos ágiles más comunes, los cuales incluyen Extreme
Programming (XP), Scrum, Feature Driven Development (FDD), y Crystal. Así mismo
describe algunas diferencias entre los distintos métodos ágiles.
Una de las diferencias más notables que tienen las metodologías ágiles son el tamaño
de equipo, la distribución del equipo, la intervención del cliente, el nivel de documentación
y el periodo de tiempo de iteración (Abdo, Noteboom y Sarnikar, 2015).
En el caso del tamaño del equipo el autor menciona que para Extreme Programming
el número de integrantes debe estar compuesto de menos de 20 personas, ya que está más
orientada a equipos pequeños, para el caso de Scrum mencionan que el número de integrantes
del equipo aplica a todas las tallas, para Feature-driven development está más enfocado a
equipos grandes y Crystal al igual que Scrum está enfocado a todas las tallas (Abdo,
Noteboom y Sarnikar, 2015).
Con respecto a la distribución del equipo el autor menciona que para XP el equipo
debe ser coubicado lo que quiere decir que los integrantes del equipo del proyecto deben estar
físicamente cerca unos de otros, para el caso de Scrum el equipo puede ser coubicado o puede
ser un equipo distribuido, para FDD de la misma manera el equipo puede ser coubicado o
distribuido y para Crystal el equipo debe ser coubicado (Abdo, Noteboom y Sarnikar, 2015).
90
Con referencia a la intervención del cliente en Extreme Programming el cliente debe
estar involucrado, para Scrum la participación del cliente es a través del rol de propietario
del producto, para el caso de Feature-driven development el cliente está involucrado
mediante informes y para Crystal el cliente está involucrado a través de los lanzamientos
(Abdo, Noteboom y Sarnikar, 2015).
Para el caso del nivel de documentación el autor menciona que en XP es básica y lo
mínimo posible, para Scrum es básica y cualquier cosa de valor, para el caso de FDD la
documentación es muy importante y para Crystal al igual que Extreme Programming es
básica (Abdo, Noteboom y Sarnikar, 2015).
Otra de las características mencionadas por el autor en las que se pueden diferenciar
las metodologías ágiles es el tiempo de iteración, para Extreme Programming la iteración va
de una a seis semanas, para el caso de Scrum es de dos a cuatro semanas, para Feature-driven
development es de dos días a dos semanas y para el caso de Crsytal es dependiendo del
método utilizado (Abdo, Noteboom y Sarnikar, 2015).
PI5 ¿Cuál es la lista de los criterios más utilizados para la selección de una metodología
ágil más adecuada para el desarrollo de un proyecto de software?
Para identificar los criterios más utilizados para la selección de una metodología ágil
adecuada, se agruparon los criterios identificados de los distintos estudios en dos campos
muy importantes, el primero relacionado con las propiedades de los proyectos y el segundo
con las características presentes en las metodologías ágiles que permitan poder determinar
que metodología se adapta mejor a la naturaleza de un proyecto en particular.
Primero se identificaron aquellos criterios enfocados a las características de los
proyectos de desarrollo de software presentes en los estudios dados por distintos autores. A
continuación, se muestra la lista de todos los criterios recopilados en los distintos trabajos de
investigación.
Los siguientes criterios son presentados por Abdo, Noteboom y Sarnikar (2015), en
su estudio titulado “Evaluating Project Characteristics for Selecting the Best-fit Agile
Software Development Methodology: A Teaching Case”.
• Involucramiento con el cliente
91
• Producto final, puede ser de alta calidad o diseño simple
• Especificación de requisitos
• Tiempo de implementación
Los siguientes criterios son presentados por Mnkandla y Dwolatzky (2007), en su
estudio titulado “Agile Methodologies Selection Toolbox”.
Los siguientes criterios son descritos por Balaji y Obaidy (2016), en su artículo
titulado “Project Characteristics used for Methodology Selection to Develop the Software
Project”.
• Compromiso con el cliente
• Claridad del riesgo
De acuerdo con los criterios dados por cada uno de los autores, se realizó un análisis
para identificar aquellos que estuvieran presentes en al menos otro estudio, de los cuales se
tuvieron que agrupar, ya que los criterios dados por algunos autores tenían un nombre
distinto, pero su principio era el mismo. A continuación, se muestra la lista de los criterios
92
identificados en los diferentes trabajos de investigación proporcionados por diferentes
autores.
• Tamaño del equipo de proyecto
• Estabilidad de requisito
De la lista anterior se identificaron aquellos criterios presentes en más de un estudio
con el propósito de mostrar aquellos criterios más utilizados para la selección de una
metodología ágil. Son siete los criterios identificados en los trabajos de investigación de los
distintos autores relacionados con las características del proyecto que pueden ser
consideradas para la selección de una metodología ágil adecuada, los cuales se muestran a
continuación.
93
En segundo lugar, se identificaron aquellos criterios enfocados a las características de
las metodologías ágiles proporcionadas en los trabajos de investigación de distintos autores.
A continuación, se muestra la lista de los criterios recopilados de los distintos estudios.
Los siguientes criterios son presentados por Kumar, Agarwal y Kumar (2018), en su
estudio titulado “A Novel Approach for Agile Software Development Methodology Selection
Using Fuzzy Inference System”
• Participación de usuario
• Flexibilidad de desarrollo
• Cohesión de equipo
Los siguientes criterios son presentados por Abdo, Noteboom y Sarnikar (2015), en su
estudio nombrado “Evaluating Project Characteristics for Selecting the Best-fit Agile
Software Development Methodology: A Teaching Case”
De la misma manera que con los criterios enfocados al proyecto de desarrollo se
realizó un análisis para identificar aquellos que estuvieran presentes en al menos otro estudio,
de los cuales se tuvieron que agrupar, ya que los criterios dados por algunos autores tenían
un nombre distinto, pero con el mismo principio. A continuación, se muestra la lista de los
94
criterios identificados en los diferentes trabajos de investigación proporcionados por
diferentes autores.
De la lista anterior se identificaron aquellos criterios presentes en más de un estudio
con el propósito de mostrar aquellos criterios más utilizados para la selección de una
metodología ágil. A continuación, se muestran la lista de los criterios más usados
identificados en los trabajos de investigación.
3.10.2 Análisis crítico
A medida que se fue desarrollando este trabajo de investigación se hizo énfasis en la
importancia que implica la selección de una metodología ágil adecuada para un proyecto en
específico, ya que actualmente muchas organizaciones utilizan modelos ágiles en el
desarrollo de sus proyectos por lo que es de vital de importancia poder determinar el método
ágil que mejor se adapte a sus necesidades.
La elección de una metodología correcta puede ayudar a concluir con éxito los
proyectos de software en los tiempos y costos establecidos desde el inicio del desarrollo, así
95
como también cumplir con los objetivos comerciales propuestos para el proyecto, por el
contrario, la selección del método ágil incorrecto tiene implicaciones significativas en el éxito
del proyecto, lo que puede llevar a que se exceda el tiempo y presupuesto establecidos para
el desarrollo. Por lo que es importante que tanto las organizaciones como todas aquellas
personas que se dedican a desarrollar software sean consciente de lo importante que es
utilizar la metodología ágil más adecuada dependiendo de las necesidades del proyecto a
realizar y se esfuercen por identificar la metodología que les asegure el éxito en sus
proyectos.
Debido a lo anterior y con el objetivo de proporcionar una lista de criterios que
permita a las organizaciones y a los profesionales que desarrollan software poder seleccionar
entre distintas metodologías ágiles, se realizó un análisis de los criterios más utilizados y
relevantes descritos en diferentes estudios relacionados con la selección de modelos ágiles,
desarrollados por distintos autores y recopilados a través de una revisión sistemática de la
literatura. En el cual se identificaron diez estudios primarios que responden al menos una
pregunta de investigación.
De los estudios obtenidos se pudo observar que algunos autores describen una serie
de criterios enfocados a las características de los proyectos mientras que otros enfocados a
las características presentes en las metodologías ágiles e incluso algunos aportan los dos
grupos de criterios. De los criterios descritos en los distintos trabajos de investigación se
pudo observar que varios de ellos estaban presentes en distintos estudios esto debido a que
más de un autor los mencionan por lo que fueron considerados relevantes para el objetivo
principal de esta investigación. Sin embargo, no todos los criterios identificados expresaban
de manera clara cómo es que ayudan a determinar qué metodología ágil es la más adecuada
por lo que solo se eligieron aquellos criterios que aparecían en más de un documento y
aquellos claramente definidos.
Fueron 17 los criterios identificados que permiten seleccionar una metodología ágil
adecuada, respecto al proyecto se determinaron nueve los cuales son el tamaño del proyecto,
tamaño del equipo, estabilidad de requisitos, involucramiento del cliente, riesgo del proyecto,
complejidad del proyecto, plazo de desarrollo, periodo de tiempo de iteración y nivel de
documentación. Para las metodologías ágiles de igual forma se identificaron ocho criterios
96
enfocados a lo establecido por los documentos oficiales de las distintas metodologías ágiles
los cuales son tamaño del proyecto, tamaño del equipo, intervención del cliente, distribución
del equipo, complejidad del proyecto, estilo de desarrollo, periodo de tiempo de iteración y
nivel de documentación, todas estas características permiten identificar de manera clara qué
metodología se adapta mejor a un proyecto en particular.
Con respecto a lo anterior se puede apreciar que la mayoría de los criterios presentes
tanto en las características de los proyectos como en la de las metodologías ágiles tienen una
relación en común, inclusive en el nombre, por ejemplo en el caso del tamaño del equipo que
está presente en ambos grupos, uno hace referencia al tamaño del equipo del proyecto y el
otro al tamaño del equipo ideal especificado en una metodología, ambos tienen el mismo
propósito que es identificar el número de miembros del equipo para así definir que método
ágil se adecúa más a las necesidades del proyecto. De lo anterior se puede determinar que
todos los criterios presentes enfocados en el proyecto deben ser los criterios enfocados en las
características de las metodologías ágiles, ya que cada criterio de un proyecto debe
identificarse en la metodología.
3.10.3 Recomendaciones
Con base en los criterios que se obtuvieron a lo largo de esta investigación, se plantean una
serie de recomendaciones para las organizaciones y las personas que se dedican a desarrollar
software con el objetivo de poder mejorar el proceso de elección de una metodología ágil
adecuada.
Para las empresas y las personas que se dedican a desarrollar proyectos de software
se recomienda que tomen como referencia algún marco de evaluación de metodologías ágiles
o alguna lista de criterios o factores que les ayude a seleccionar una metodología ágil
adecuada a las necesidades del proyecto, ya que la incorrecta elección de un método ágil
puede llevar al fracaso del proyecto excediendo el tiempo y los costos establecidos.
Para los futuros trabajos de investigación se recomienda utilizar como base los
criterios presentados en este estudio para crear algún modelo o matriz que permita determinar
la metodología ágil más adecuada para un proyecto en particular. De igual forma se
recomienda indagar más a detalle toda la documentación de las diversas metodologías ágiles
para identificar más características que resulten útiles al momento de elegir un método ágil.
97
Conclusiones
En esta investigación se ha hecho énfasis en la importancia de seleccionar la metodología
ágil más adecuada para un proyecto en específico, ya que elegir un método ágil incorrecto
puede tener muchas implicaciones en el éxito de este, por lo que es importante determinar
desde un principio que método ágil utilizar que asegure un mejor proceso de desarrollo y que
se adapte a las necesidades de un proyecto en particular.
Debido a lo anterior en este trabajo se ha identificado una lista de criterios que
permiten seleccionar la metodología ágil más adecuada dependiendo de las características de
un proyecto en específico. Fueron 17 los criterios identificados que se presentan en esta
investigación los cuales se dividen en dos grupos, nueve criterios identificados de las
características de los proyectos y ocho identificados de las características de las metodologías
ágiles.
Los criterios enfocados a los proyectos son tamaño del proyecto, tamaño del equipo
del proyecto, estabilidad de requisitos, involucramiento del cliente, riesgo del proyecto,
complejidad del proyecto, plazo de desarrollo, periodo de tiempo de iteración y nivel de
documentación. Para los criterios enfocados a los métodos ágiles son tamaño del proyecto,
tamaño del equipo, intervención del cliente, distribución del equipo, complejidad del
proyecto, estilo de desarrollo, periodo de tiempo de iteración y nivel de documentación.
Estos criterios fueron recopilados de múltiples trabajos de investigación en el cual se
identificaron y seleccionaron aquellos descritos por más de un autor, y se dejó el nombre del
criterio que mejor expresaba a que hacía referencia, así mismo se seleccionaron aquellos
criterios que, aunque no eran mencionados por más de autor describen con claridad cómo es
que ayudan a seleccionar una metodología ágil de desarrollo de software.
Con los criterios antes mencionado se cumple el objetivo principal de esta investigación que
es el proponer una lista de los criterios que permitan seleccionar una metodología ágil
adecuada para un proyecto en específico. Así mismo la lista de criterios sugeridos en este
trabajo puede servir como guía para aquellas organizaciones y personas que se dedican a
desarrollar software a elegir la metodología más adecuada dependiendo de las características
del proyecto.
98
Referencias
Abdo Harb, Y., Noteboom, C., & Sarnikar, S. (2015). Evaluating Project Characteristics for Selecting the
Best-fit Agile Software Development Methodology: A Teaching Case. Journal of the Midwest
Association for Information Systems (JMWAIS): Vol. 1, 33-52.
Agile Alliance. (s.f.). Agile Alliance. Obtenido de Agile Alliance: https://www.agilealliance.org
Agile Business Consortium. (01 de Octubre de 2021). Agile Business Consortium. Obtenido de Agile Business
Consortium: https://www.agilebusiness.org/page/TheDSDMAgileProjectFramework
Bakhtouchi, A., & Rahmouni, R. (2018). A Tree Decision Based Approach for Selecting Software
Development Methodology. 2018 International Conference on Smart Communications in Network
Technologies (SaCoNeT), 211-216.
Balaji, S., & Obaidy, M. (2016). Project characteristics used for methodology selection to develop the
software project. 2016 International Conference on Electrical, Electronics, and Optimization Techniques
(ICEEOT), 3570-3573.
Bautista Q, J. M. (2012). PROGRAMACIÓN EXTREMA (XP). Bolivia: Unión Bolivariana.
Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Fowler, M., . . . Sutherland, J. (2001).
Agile Manifiesto. Obtenido de Agile Manifiesto: http://agilemanifesto.org/
BS Silva, V., Schramm, F., & C. Damasceno, A. (2016). A multicriteria approach for selection of agile
methodologies in software development projects. 2016 IEEE International Conference on Systems,
Man, and Cybernetics (SMC), 002056-002060.
Cabach Pisani, A. (Diciembre de 2006). Estructura y organización de una fábrica de software. Estructura y
organización de una fábrica de software. Valparaíso, Chile: Pontificia Universidad Católica de
Valparaíso.
Canós, J., Letelier, P., & Penadés, M. (2003). Métodologías Ágiles en el Desarrollo de Software. Universidad
Politécnica de Valencia, 1-8.
Cervera Castro, N. S. (22 de Septiembre de 2021). Aplicación de metodologías ágiles para la gestión de
proyectos de construcción. Aplicación de metodologías ágiles para la gestión de proyectos de
construcción. Guayaquil, Ecuador: Universidad Católica de Santiago de Guayaquil.
Cockburn, A. (2004). Crystal clear a human-powered methodology for small teams. Humans and Technology,
1-309.
Coding Sans. (2020). State of software development. Coding Sans.
Corona , B., Muñoz, M., Miramontes, J., Calvo Manzan, J., & San Feliu, T. (2016). Estado de arte sobre
métodos de evaluación de metodologías ágiles en las pymes. ReCIBE. Revista electrónica de
Computación, Informática, Biomédica y Electrónica.
Digital.ai. (2020). 14 Annual State of Agile Report. digital.ai.
Don Wells. (2009). Extreme Programming. Obtenido de Extreme Programming:
http://www.extremeprogramming.org/values.html
Frasser Acevedo, W. (2014). Historia y evolución de la ingeniería de software. Bogotá.
Guerra, B. G. (Mayo de 2018). Nuevas oportunidades en la industria de servicios de tecnologías de la información y
desarrollo de software en México. Obtenido de Nuevas oportunidades en la industria de servicios de
tecnologías de la información y desarrollo de software en México:
https://www.grantthornton.mx/globalassets/1.-member-
firms/mexico/pdf/boletin_economia_mayo_2018.pdf
Hernández Sampieri, R. (2014). Metodología de la investigación. México: McGraw-Hill / Interamericana
Editores, S.A. de C.V.
INEGI. (2020). Estadísticas a propósitos del día de las micro, pequeñas y medianas empresas. INEGI.
ISO/IEC/IEEE International Standard. (28 de August de 2017). Systems and software engineering--Vocabulary.
24765-2017 - ISO/IEC/IEEE International Standard - Systems and software engineering--Vocabulary,
Segunda, 1-541. IEEE. doi:10.1109/IEEESTD.2017.8016712.
Jeffries, R. E. (16 de Marzo de 2011). Ron Jeffries. Obtenido de Ron Jeffries:
https://ronjeffries.com/xprog/what-is-extreme-programming/
Jordán Marcos, D. (Septiembre de 2020). Estudio sobre las metodologías ágiles y metodologías tradicionales
para gestión de proyectos de software. Estudio sobre las metodologías ágiles y metodologías
tradicionales para gestión de proyectos de software. Madrid, España.
99
Khan, P., & Sufyan Beg, M. (2013). Extended Decision Support Matrix for Selection of SDLC-Models on
Traditional and Agile Software Development Projects. 2013 Third International Conference on
Advanced Computing and Communication Technologies (ACCT), 8-15.
Kitchenham, B., & Charters, S. (9 de Julio de 2007). Guidelines for performing Systematic Literature Reviews
in Software Engineering. Guidelines for performing Systematic Literature Reviews in Software Engineering.
Durham, Reino Unido: Department of Computer Science University of Durham.
Kumar Rai, A., Agarwal, S., & Kumar, A. (2018). A Novel Approach for Agile Software Development
Methodology Selection Using Fuzzy Inference System. 2018 International Conference on Smart Systems
and Inventive Technology (ICSSIT), 518-526.
Lopes Macedo, H. I. (October de 2019). Development of a continuous improvement process for agile
software development teams. Development of a continuous improvement process for agile software
development teams. Braga, Portugal: Universidade do Minho: RepositoriUM.
Maida, E. G., & Pacienzia, J. (Diciembre de 2015). Metodologías de desarrollo de software. Metodologías de
desarrollo de software. Santa María, Argentina: Biblioteca Digital de la Universidad Católica Argentina.
Medina Velandia, L. N., & López López, W. M. (2015). Escoger una metodología para desarrollar software,
difícil decisión. Revista Educación en Ingeniería, 98-109.
Mendes Calo, K., Estevez, E., & Fillottrani, P. (2010). A Quantitative Framework for the Evaluation of Agile
Methodologies. 68-73.
Merja, S. (2020). Project success in Agile –driven software delivery projects. Project success in Agile –driven
software delivery projects. Vaasa, Finlandia: Universiity of Vaasa.
Mnkandla , E., & Dwolatzky, B. (2007). Agile Methodologies Selection Toolbox. International Conference on
Software Engineering Advances (ICSEA 2007), 72-72.
Mohammed Hamed, A., & Abushama, H. (2013). Popular agile approaches in software development: Review
and analysis. 2013 INTERNATIONAL CONFERENCE ON COMPUTING, ELECTRICAL AND ELECTRONIC
ENGINEERING (ICCEEE), 160-166.
Öztürk, V. (2013). Selection of appropriate software development life cycle using fuzzy logic. Journal of
Intelligent & Fuzzy Systems 25, 797-810.
Pino, F. J., García, F., & Piattini, M. (2006). Revisión sistemática de mejora de procesos software en micro,
pequeñas y medianas empresas. REICIS. Revista Española de Innovación, Calidad e Ingeniería del
Software, 6-23.
Pressman, R. S. (2010). Ingeniería del software. Un enfoque práctico (Séptima ed.). New York: McGraw-Hill.
Rosselló Villán, V. (15 de Marzo de 2019). IEBS. Obtenido de IEBS: https://www.iebschool.com/blog/que-son-
metodologias-agiles-agile-scrum/
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org.
Simelane, L., & Zuva, T. (2019). Decision Support Framework for the Adoption of Software Development
Methodologies. 2019 International Multidisciplinary Information Technology and Engineering Conference
(IMITEC), 1-6.
Sommerville, I. (2011). Ingeniería de software (Novena ed.). Pearson Educación de México.
Taromirad, M., & Ramsin, R. (2008). An Appraisal of Existing Evaluation Frameworks for Agile
Methodologies . 15th Annual IEEE International Conference and Workshop on the Engineering of
Computer Based Systems (ecbs 2008), 418-427.
Tinoco Gómez, O., Rosales López, P. P., & Salas Bacalla, J. (2010). Criterios de selección de metodologías de
desarrollo de software. Industrial Data, 70-74.
Varhol, P. (2021). TechBeacon. Obtenido de TechBeacon: https://techbeacon.com/app-dev-testing/agility-
beyond-history-legacy-agile-development
Vhutshilo, M., Kadyamatimba, A., Muganda Ochara, N., & Tutani, D. (2018). Factors Influencing the Design of
Unbounded Rule-Based Expert Architecture for Selection of Software Development Methodologies.
2018 Open Innovations Conference (OI), 155-160.
Yepes González, J., Pardo Calvache, C. J., & Gómez Gómez, O. S. (2015). Revisión sistemática acerca de la
implementación de metodologías ágiles y otros modelos en micro, pequeñas y medianas empresas
de software. Revista Tecnológica ESPOL, 464-479.
Yousra, H., Cherie, N., & Surendra, S. (2015). Evaluating Project Characteristics for Selecting the Best-fit
Agile Software Development Methodology: A Teaching Case. Journal of the Midwest Association for
Information Systems (JMWAIS), 33-52.
100
Zumba Gamboa, J. P., & León Arreaga, C. (2018). Evolución de las Metodologías y Modelos utilizados en el
Desarrollo de Software. Guayaquil: INNOVA.
101
“Lis de Veracruz: Arte, Ciencia, Luz”
www.uv.mx

Analisis de Los Criterios para La Seleccion de Una Metodologia Agil de Desarrollo de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis de Los Criterios para La Seleccion de Una Metodologia Agil de Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Universidad Veracruzana Facultad de Contaduría y Administración

Licenciatura en Ingeniería de software

Análisis de los criterios para la selección de una

Director(a) del trabajo recepcional:

“Lis de Veracruz: Arte, Ciencia, Luz”

Licenciatura en Ingeniería de software

Modalidad Tesina para acreditar la Experiencia recepcional

Director del trabajo recepcional:

Agregar académico (s) participante (s) y su función

Figura 3 Porcentajes de metodologías ágiles más utilizadas en el 2020.

Figura 6 Fases de la revisión sistemática de la literatura.

Criterios de inclusión Criterios de exclusión

Número de estudios primario por año

Figura 8 Número de estudios primarios por año.

Figura 9 Número de documentos por fuentes de información.

Porcentaje de fuentes basado en temas extraídos

Estudios que presentan criterios de selección para una metodología

Estudios que presentan información relevante sobre metodologías ágiles

Estudios que presentan información sobre el impacto de una adecuada selección de

Figura 10 Porcentaje de fuentes basado en temas extraídos.

Porcentajes de estudios por relevancia

Alta Media Baja

Figura 11 Porcentajes de estudios por relevancia.

Tamaño del equipo del proyecto Se refiere a si es un equipo grande o

También podría gustarte