TFM Moises Lopez Magic GXV 21

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/337404157
Método ágil en el desarrollo de software aplicando la herramienta Genexus
Thesis · November 2018
CITATIONS READS
0 4,209
1 author:
Ricauter Lopez-Bermudez
State University of Milagro
3 PUBLICATIONS 2 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Analysis of the RUP methodology in the development of academic software using the DJANGO tool View project
Metodo agil con Genexus View project
All content following this page was uploaded by Ricauter Lopez-Bermudez on 21 November 2019.
The user has requested enhancement of the downloaded file.

López Bermúdez Ricauter Moisés Máster Universitario en Ingeniería de Software y
Sistemas informáticos
Método ágil en el desarrollo

de software aplicando la
herramienta Genexus
Trabajo Fin de Máster
Tipo de trabajo: Desarrollo de metodología
Presentado por: López Bermúdez, Ricauter Moisés
Director: Dr. Bermejo Higuera, Juan Ramón
Ciudad: Milagro, Ecuador

Fecha: 21 de Julio del 2018
1
Resumen
El trabajo de fin de master propone un método de desarrollo de software apoyado en las
mejores prácticas de Metodologías Agiles, utilizando la herramienta Case Genexus, se
crea una aplicación Web que permita validar la propuesta en una organización
agropecuaria.
La propuesta del método toma como referencia el análisis de las mejores prácticas de
las metodologías agiles como Scrum, Xp y Kanban. Se aplica un desarrollo basado en
conocimiento, incremental y aplicando la técnica de prototipos.
El método define roles para las personas que forman parte del equipo y ejecutan los
pasos del método propuesto. Se definen elementos que constituyen resultados de las
actividades. Se definen actividades que permiten poner en acción el método entre las
personas que forman el equipo de trabajo, estas actividades son reuniones definidas.
El trabajo aporta para solucionar el problema de la no utilización de metodologías por

parte de los profesionales del software, con un método de desarrollo ágil de software.
Se utilizó la herramienta Case Genexus que enfoca la filosofía de los conceptos agiles
para automatizar las tareas rutinarias de desarrollo como son la programación,
documentación técnica y creación de base de datos. Esta automatización de tareas
redujo el tiempo del proyecto y le incorpora calidad y seguridad al producto final, el
software.
La experimentación realizada del método nos permitió observar la forma de

implementarlo y se concluye el logro siguiente:
1) Reducir tiempo de desarrollo, porque la aplicación se describe no se programa, existe

generación automática de base de datos y programas partiendo de la descripción
almacenada en la base de conocimiento de Genexus.
2) Alta participación del usuario en el proceso, garantizando la calidad en los resultados.
3) El método no elimina la documentación, la fomentó en línea por medio de Genexus
en todos los integrantes del equipo de desarrollo.
Palabras Clave: Método Ágil, Genexus, Software
2
Abstract
The end-of-master project proposes a method of software development supported by the
best practices of Agile Methodologies, using the Case Genexus tool, a Web application
is created to validate the proposal in an agricultural organization.
The proposal of the method takes as reference the analysis of the best practices of agile
methodologies such as Scrum, Xp and Kanban. A development based on knowledge is
applied, incremental and applying the technique of prototypes.
The method defines roles for the people who are part of the team and execute the steps
of the proposed method. Define elements that constitute results of the activities. Activities
are defined that allow to put the method into action among the people that make up the
work team, these activities are defined meetings.
The work contributes to solve the problem of non-use of methodologies by software

professionals, with a method of agile software development. The Case Genexus tool was
used, which focuses on the philosophy of agile concepts to automate routine
development tasks such as programming, technical documentation and database
creation. This task automation reduced project time and adds quality and security to the
final product, the software.
The experimentation carried out in the method allowed us to observe the way to
implement it and the following achievement is concluded:
1) Reduce development time, because the described application is not programmed,

there is automatic generation of database and programs based on the description stored
in the Genexus knowledge base.
2) High user participation in the process, guaranteeing quality in the results.
3) The method does not eliminate the documentation, it was promoted online through
Genexus in all the members of the development team.
Keywords: Agile Method, Genexus, Software
3
ÍNDICE DE CONTENIDOS
1. Introducción ......................................................................................................... 10
1.1 Justificación....................................................................................................... 10
1.2 Planteamiento del trabajo .................................................................................. 11
1.3 Estructura de la memoria .................................................................................. 12
2. Contexto y estado del arte ................................................................................... 13
2.1 Ingeniería de software ....................................................................................... 13
2.2 Enfoques de Métodos desarrollo de software .................................................... 14
2.2.1 Modelo en cascada ..................................................................................... 14
2.2.2 Modelo de Prototipos .................................................................................. 15
2.2.3 Modelo Incremental .................................................................................... 17
2.2.4 Modelo Espiral ............................................................................................ 17
2.3 Metodologías Ágiles .......................................................................................... 18
2.3.1 Las Metodologías Agiles Aplican desarrollo iterativo e incremental ............ 19
2.3.2 El manifiesto ágil ......................................................................................... 19
2.3.3 Postulados del Manifiesto Ágil .................................................................... 20
2.3.4 Doce Principios del Manifiesto Ágil ............................................................. 22
2.3.5 Estado del Desarrollo Ágil ........................................................................... 23
2.4 Metodologías Agiles más usadas ...................................................................... 29
2.5 Metodología Scrum ........................................................................................... 29
2.5.1 Introducción ................................................................................................ 29
2.5.2 Roles en Scrum .......................................................................................... 31
2.5.3 Artefactos o Elementos de Scrum ............................................................... 31
2.5.4 Eventos o Actividades en Scrum................................................................. 33
2.5.5 Resumen del Ciclo de vida del desarrollo de Software en Scrum ............... 36
2.6 Metodología Kanban ......................................................................................... 38
2.6.1 Introducción ................................................................................................ 38
2.6.2 Actividades principales de Kanban ............................................................. 38
4
2.6.3 Roles de Kanban ........................................................................................ 40
2.7 Metodología Programación eXtrema (XP) ......................................................... 41
2.7.1 Elementos de XP ........................................................................................ 41
2.7.2 Roles de XP ................................................................................................ 41
2.7.3 Proceso XP ................................................................................................. 42
2.8 Herramientas de Desarrollo ............................................................................... 45
2.8.1 La herramienta GeneXus ............................................................................ 45
2.8.2 La herramienta Velneo. ............................................................................... 52
3. Objetivos concretos y metodología de trabajo ..................................................... 56
3.1 Objetivo general ................................................................................................ 56
3.2 Objetivos específicos......................................................................................... 56
3.3 Metodología del trabajo ..................................................................................... 56
4. Desarrollo de la Propuesta de Metodología ......................................................... 58
4.1 Identificación de requisitos ................................................................................ 58
4.1.1 Roles .......................................................................................................... 58
4.1.2 Elementos ................................................................................................... 59
4.1.3 Actividades o Reuniones............................................................................. 60
4.2 Descripción de la Metodología propuesta .......................................................... 60
4.2.1 Fases y Actividades. ................................................................................... 61
4.3 Fase de Apertura............................................................................................... 63
4.3.1 Reunión para definir el alcance del Producto. ............................................. 63
4.3.2 Historia de Usuario ..................................................................................... 64
4.3.3 Evaluar La Calidad de la Historia de Usuario .............................................. 65
4.3.4 Reunión para planificar el desarrollo del producto....................................... 65
4.4 Fase de Construcción........................................................................................ 66
4.4.1 Etapa Diseñar ............................................................................................. 66
4.4.2 Etapa Generar ............................................................................................ 67
4.4.3 Etapa Implementar...................................................................................... 68
5
4.5 Fase de Entrega ................................................................................................ 68
4.5.1 Reunión Entrega final del “Producto Software” ........................................... 69
4.5.2 Reunión de reflexión ................................................................................... 69
4.6 Evaluación......................................................................................................... 70
4.6.1 Presentación del caso de estudio: Experiencia real en APASA................... 70
4.6.2 Organización y capacitación del Equipo de desarrollo ................................ 70
4.6.3 Fase de Apertura para el Proyecto ............................................................. 72
4.6.4 Fases de Construcción. .............................................................................. 79
4.6.5 Fase de Entrega ......................................................................................... 81
4.6.6 Reunión Entrega final del “Producto Software” ........................................... 81
4.6.7 Reunión de reflexión Final .......................................................................... 81
5. Conclusiones y trabajo futuro............................................................................... 82
5.1 Conclusiones ..................................................................................................... 82
5.2 Líneas de trabajo futuro..................................................................................... 83
6. Bibliografía........................................................................................................... 84
7. Anexos ................................................................................................................ 90
7.1 Anexo I. Pantallas de Construcción, Etapa Diseñar ........................................... 90
7.2 Anexo II. Pantallas de Prototipos ..................................................................... 101
7.3 Anexo III. Configuración Genexus y Documentaciòn ....................................... 110
7.4 Anexo IV. Pantallas de Producción.................................................................. 114
7.5 Anexo V. Artículo............................................................................................. 122
6
ÍNDICE DE TABLAS
Tabla 1. Postulados del Manifiesto Ágil ...................................................................... 20
Tabla 2: Roles, Artefactos y Eventos Scrum ............................................................... 30
Tabla 3. Ambiente de Ejecución ................................................................................. 50
Tabla 4. Fases de la Metodología Magi-Gx................................................................. 61
Tabla 5. Reuniones de la Fase Apertura ..................................................................... 63
Tabla 6. Preguntas que responde la Historia de usuarios ........................................... 64
Tabla 7. Lista de historia de Usuarios ......................................................................... 74
Tabla 8. Planificación de historias por Ciclo ................................................................ 77
Tabla 9 Lista de requerimientos Ciclo 1 ...................................................................... 78
Tabla 10. Lista de requerimientos Ciclo 2 ................................................................... 78
Tabla 11. Lista de requerimientos ciclo 3 .................................................................... 78
7
ÍNDICE DE FIGURAS
Figura 1. Comparativos de Informes de Caos (Adaptado de Standish Group, 2014-2015)

................................................................................................................................... 10
Figura 2. Capas de la Ingeniería de Software (Pressman, 2010) ............................... 13
Figura 3. Modelo Cascada (Adaptado de Pressman, 2010) ....................................... 15
Figura 4. Etapas del Modelo Prototipo (Pressman 2010) ........................................... 16
Figura 5. Modelo Incremental (Pressman, 2010) ....................................................... 17
Figura 6. Modelo Espiral (Pressman, 2010) ............................................................... 18
Figura 7.Método Ágil (Rodriguez, 2015)..................................................................... 19
Figura 8. Localización de los encuestados (CollabNet VersionOne, 2018) ................ 24
Figura 9. Razones para adoptar el desarrollo ágil (CollabNet VersionOne, 2018) ...... 25
Figura 10. Beneficios para adoptar el desarrollo ágil (CollabNet VersionOne, 2018) . 26
Figura 11. Técnicas ágiles empleadas (CollabNet VersionOne, 2018) ....................... 27
Figura 12. Desafíos al adoptar el desarrollo ágil (CollabNet VersionOne, 2018) ........ 28
Figura 13. Metodologías ágiles usadas (CollabNet VersionOne, 2018)...................... 28
Figura 14. Ejemplo de Scrum Board (Jim Bowes, 2014) ............................................ 33
Figura 15. Eventos en Scrum (Capó, 2013) ............................................................... 34
Figura 16. Flujo de Planificación de Sprint (Palacios, 2017)....................................... 35
Figura 17. Marco Scrum (Saiz Jorge, 2017) ............................................................... 37
Figura 18. Tablero Kanban (Alcocer M., 2015)........................................................... 39
Figura 19. (WIP límite de tareas, (Bahit, 2011) .......................................................... 39
Figura 20. Cycle time y Lead time (Roock Stefan, 2010) ........................................... 40
Figura 21. Proceso XP(sites.google.com,2017) ......................................................... 43
Figura 22. Esquema de funcionamiento de GeneXus (GeneXus training, 2017a) ...... 46
Figura 23. Desarrollo con Genexus (GeneXus training, 2017a) ................................. 48
Figura 24. Ciclo de vida del desarrollo de aplicaciones (Artech Consultores, 2012b) . 49
Figura 25. Tecnologías compatibles con GeneXus .................................................... 51
8
Figura 26. Fases de Desarrollo Velneo (velneo, 2016) .............................................. 54
Figura 27: Método Magi-GX (elaboración propia) ...................................................... 62
Figura 28. Ejemplo de historia de usuario (elaboración propia) .................................. 64
9
1. Introducción
El desarrollo del software ha cambiado con las nuevas técnicas que se van
desarrollando. El uso adecuado de las metodologías de desarrollo permitirá optimizar
recursos y tiempo a las empresas al construir productos de software con calidad y
seguridad.
1.1 Justificación
El software se ha convertido silenciosamente en un aliado que nos causa dependencia

para nuestra vida diaria, lo tenemos en los televisores, nuestros vehículos, en los
teléfonos y lo necesitamos para nuestro trabajo diario. Cuando presenta problemas
paraliza nuestras actividades.
Un análisis y seguimiento a los proyectos de software a nivel mundial lo encontramos

en un Informe anual denominado Chaos Report. El grupo Standish Group desde 1994
publica este informe estadístico. Analiza los criterios de alcance, presupuesto y plazos
para medir el éxito o fracaso de los proyectos de software. El análisis que se muestra
en la figura 1, elaborado en base a un informe resumen publicado el 2014 y el informe
2015 por el grupo Standish Group, nos indica que la tendencia del éxito de los proyectos
de software a lo largo del tiempo no mejora, los proyectos deficientes van en aumento y
los proyectos fracasados no disminuyen. Las causas: bajo apoyo de los mandos altos,
baja participación de los usuarios, equipos no calificados, desconocimiento de la
aplicación de metodologías agiles, desconocimiento de uso de herramientas entre otras
(Standish Group, 2014).
Éxito de Proyectos
60% Exitoso Deficiente Fracasado 55%
53% 52%
46% 48%
50% 44%
40% 41%40%
38% 37%
40% 36% 36%
31% 29%
28%
30%
20% 22%
17% 19% 17% 19%
20% 16% 16%
10%
0%
1994 2009 2010 2011 2012 2013 2014 2015
Figura 1. Comparativos de Informes de Caos (Adaptado de Standish Group, 2014-2015)
10
Un estudio indicó que en Ecuador el 48% de empresas no aplica normas de calidad y

el 8% no utiliza ninguna metodología para el desarrollo de software. En las
organizaciones que se dedican al desarrollo de software en la provincia del Guayas-
Ecuador, la tendencia que se observa es que no utilizan una metodología de desarrollo
adecuada para la construcción de software (Vinueza, 2012).
El problema en toda actividad son los obstáculos que tenemos para alcanzar los
objetivos. La industria del software se enfrenta a un gran problema, no se aplican
metodologías para su desarrollo de manera generalizada y obtener un producto de
calidad, hacerlo sin metodología se convierte en una artesanía. Una de las causas es
que la mayoría de profesionales tienen deficiencias académicas (Zavala Ruiz, 2004).
1.2 Planteamiento del trabajo
Una alternativa para solucionar el problema, de no utilizar metodologías, y darle calidad

a la producción de software es, invitar a utilizar metodologías ágiles o procedimientos
estándares para el análisis, diseño, programación y prueba del software, por parte
de los profesionales del software; creando una filosofía de trabajo uniforme, y elevando
su productividad (Lomprey & Hernandez, 2008).
El Chaos report nos indica que la tendencia de los proyectos exitosos es que utilizan
metodologías agiles. Del total de proyectos exitosos, el 46% utilizan metodologías
agiles mientras que 14% utilizan la metodología en cascada (Standish Group, 2014).
Como contribución a la solución hay que considerar la formación en las universidades

de los futuros profesionales en el área de Software haciendo énfasis en la aplicación de
metodologías en proyectos integradores mediante la modernización de los currículos y
los investigadores pueden colaborar mediante la realización de experimentos que
evalué la calidad del software mediante la aplicación de metodologías agiles (Melo et al.,
2013).
La propuesta de este trabajo es un aporte a solucionar el problema de la no utilización

de metodologías, se propone realizar un esquema para implementar un método de
desarrollo de software, basado en las mejores prácticas de las metodologías agiles
incorporando una herramienta de apoyo en el ciclo de vida que automatice el desarrollo.
Se plantea construir una aplicación Web para el sector agropecuario basado en los
requerimientos de los usuarios para validar la propuesta.
11
1.3 Estructura de la memoria
A continuación, se describen cada uno de los capítulos que se desarrollaran en el

documento de trabajo de fin de máster.
En el capítulo 2, se especificará a detalle la información referente a los antecedentes

del problema en el desarrollo de software, para de esa manera poder contextualizar
todos los conceptos relacionados a las metodologías de desarrollo agiles y las
características de la herramienta Genexus.
En el capítulo 3, se describirán los objetivos y la metodología de trabajo que se va a

poner en práctica en el proyecto de investigación donde se especificara de una forma
concreta y clara haciendo un análisis de comparación referente al desarrollo de software
empresarial en la actualidad.
En el capítulo 4, se especificará el aporte que tendrá el método propuesto como

investigación y cuál será su contribución al desarrollo de software, se toma como
referencia el desarrollo de una aplicación Web para el sector agropecuario.
Finalmente en el capítulo 5, se especificaran las conclusiones de la investigación

relacionados a los resultados que se detecten con sus respectivas fuentes bibliográficas.
12
2. Contexto y estado del arte
2.1 Ingeniería de software
Ingeniería de software es el análisis de los elementos y metodologías para la

construcción y mantenimiento de sistemas de software(Zelkowitz, Shaw, & Gannon,
1979).
Figura 2. Capas de la Ingeniería de Software (Pressman, 2010)
Se define la ingeniería de software como una tecnología con varias capas, ver figura 2,
estas capas son: procesos, métodos y herramientas que permiten elaborar a tiempo y
con compromiso de calidad sistemas complejos basados en computadoras, las
características de estas capas se definen a continuación (Pressman, 2010):
El Proceso de software forma la base para el control de la administración de proyectos

de software, y establece el contexto en el que se aplican métodos técnicos para
asegurar la calidad.
Los Métodos de la ingeniería de software proporcionan la experiencia técnica para

elaborar software. Incluyen un conjunto amplio de tareas como: comunicación, análisis
de los requerimientos, modelación del diseño, construcción del programa, pruebas y
apoyo. Otro concepto propuesto es:
“Los Métodos de desarrollo de software es un enfoque estructurado para el desarrollo
de software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseño
y guías de procesos” (Sommervjlle, 2005, p. 10).
Para Pressman ( 2010, p. 12) considera que: “Las Herramientas de la ingeniería de

software proporcionan un apoyo automatizado o semiautomatizado para el proceso y
los métodos”.
13
En el momento que se integran las herramientas, queda establecido un sistema llamado

ingeniería de software asistido por computadora (Computer Assist Software Engieneing)
que apoya el desarrollo de software. (Pressman, 2010).
En los años 80 se introducen los computadores personales, esto permite el desarrollo

de herramientas para automatizar el proceso de crear software de manera económica
(Chikofsky & Rubenstein, 1988).
2.2 Enfoques de Métodos desarrollo de software
Pressman (2010) nos propone que todos los modelos para desarrollar software pueden
incluir las actividades estructurales generales: la comunicación, la planeación, el
modelado, la construcción y el despliegue, pero cada modelo pone distinto énfasis en
ellas y define en forma diferente el flujo de proceso que invoca cada actividad
estructural, a continuación, se analiza los enfoques:
 Modelo en cascada.
 Modelo de Prototipo.
 Modelo Incremental
 Modelo Espiral
2.2.1 Modelo en cascada
Winston Royce (Royce, 1970), propone este modelo en su artículo “Administrando el

desarrollo de grandes sistemas de software”, determinó que el desarrollo de programas
de computadora, sin importar el tamaño o complejidad, se podían separar en 2 etapas
de desarrollo: Análisis y programación. Para pequeños proyectos estos 2 pasos eran
suficientes. Para el desarrollo de grandes sistemas de software, Royce representó el
modelo con los siguiente 7 pasos:
 Requerimientos de sistema
 Requerimientos de software
 Análisis
 Diseño del programa
 Programación
 Pruebas, y
 Operación
14
El modelo de la cascada, a veces llamado ciclo de vida clásico, propone una perspectiva
sistemática y a la vez secuencial para el proceso del desarrollo de un software, se ilustra
en la figura 3:
“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 original de Winston Royce de la cascada considera la retroalimentación,

quienes lo utilizan lo emplean considerando que es rigorosamente en linea (Pressman,
2010).
Figura 3. Modelo Cascada (Adaptado de Pressman, 2010)
2.2.2 Modelo de Prototipos
Las siguientes etapas considera este modelo y son:
 Comunicación
 Plan rápido
 Modelado, diseño rápido
15
 Construcción del Prototipo

 Desarrollo, entrega y retroalimentación
El modelo de prototipos (véase la figura 4), inicia aplicando comunicación, se reúnen

los que participan para definir el software en términos generales, identificando los
requerimientos y se encuentran las áreas necesarias para detallar una mejor
enunciación. El prototipo se planea rápidamente con una iteración, luego se comienza
el modelado como un rápido diseño, representado lo visible para los interesados finales,
como la disposición de la interfaz y formatos de salida. El siguiente paso es construir
el prototipo. Luego los usuarios se encargan de evaluar lo realizado, esta evaluación
permite la mejora de los requerimientos. La iteración sucede, el proceso de prototipar
se afina hasta conseguir que los participantes cubran sus requisitos (Pressman, 2010).
Figura 4. Etapas del Modelo Prototipo (Pressman 2010)
El uso de prototipos permite al usuario de forma temprana ver el software como va

tomando forma, e interactuar con los diseñadores y desarrolladores. Se puede adelantar
el resultado de los requerimientos aplicando el modelo, esto es una ayuda a los
desarrolladores y a los interesados para comprender como conseguir el objetivo final
satisfacer sus requisitos (Lawrence Shari, 2002).
16
2.2.3 Modelo Incremental
Pressman (2010), en la figura 5 se representa el modelo, el cronograma de actividades

trascurre mientras se aplican secuencias lineales con carácter escalonado. Cada ciclo
lineal tiene como resultado incrementar paso a paso el software que se construye con
entregas funcionales, de manera similar a los incrementos realizados en un modelo de
proceso evolutivo como espiral o prototipos. El modelo de prototipo se puede incorporar
para desarrollar los incrementos.
Figura 5. Modelo Incremental (Pressman, 2010)
2.2.4 Modelo Espiral
Se basa en las mejores características del prototipado en conjunto con el ciclo de vida
clásico. “Incluye también el análisis de alternativas, y reducción de riesgos” (León,
Eberth, & Marco, 2003, p. 3).
Pressman ( 2010, p. 39) nos indica que: “Con el empleo del modelo espiral, el software
se desarrolla en una serie de entregas evolutivas”.
En las primeras iteraciones, se puede entregar un modelo o prototipo, a continuación,

un resumen de su enfoque.
17
En este modelo el equipo de desarrollo divide las actividades en un conjunto de

estructuras para desarrollar el proceso . Las actividades empiezan con la planeación,
modelado, construcción y despliegue, cada una de ellas representa una porción en el
recorrido de la espiral, ver la figura 6. El ciclo uno alrededor de la espiral entrega el
desarrollo de los primeros requerimientos del producto; cada vuelta de la espiral da
como resultado prototipos que se van mejorando hasta conseguir versiones más
completas del software partiendo desde el eje central (Pressman, 2010).
Figura 6. Modelo Espiral (Pressman, 2010)
El desarrollo puede realizarse a gran escala, como el software evoluciona según conforme
el proceso continúe avanzando, tanto el cliente como el desarrollador pueden comprender
y en base a la retroalimentación reaccionan ante los riesgos en cada ciclo. La reducción de
riesgos en este modelo se logra utilizando los prototipos, este enfoque aplica el desarrollo
de prototipos en cualquier momento para evolucionar el producto(Pressman, 2010).
2.3 Metodologías Ágiles
En los últimos años ha nacido un nuevo estilo de metodología de software, conocido

como métodos ágiles (Fowler, 2005). Las metodologías ágiles, intentarían disminuir los
fracasos por minimización de tiempos, costos y funcionalidades en cuanto a proyectos
que tienen relación con desarrollar software. (Navarro Cadavid, Fernández Martínez, &
Morales Vélez, 2013).
18
Las metodologías ágiles para el desarrollo de software crean interés en la industria y

son reconocidas en ambientes académicos y de investigación, esto genera la necesidad
de desarrollar la capacitación necesaria, pero los enfoques tradicionales no son
aplicables, porque se requiere otro enfoque propio de las metodologías agiles y
herramientas que lo soportan (Canos, Letelier, & Penadés, 2003).
Figura 7.Método Ágil (Rodriguez, 2015)
2.3.1 Las Metodologías Agiles Aplican desarrollo iterativo e

incremental
Las metodologías Agiles se caracterizan en que deben entregarse incrementos de

software (prototipos ejecutables) en periodos cortos de tiempo, ver figura 7, de modo
que la adaptación vaya a ritmo con el cambio (impredecible). Hay un enfoque iterativo
que permite al usuario evaluar permanentemente el incremento que se le hace al
producto software, se genera con esta evaluación del usuario, retroalimentación al
equipo de desarrollo, que la aprovecha en el proceso. Es una alternativa a metodologías
tradicionales para mejorar la calidad del software, esto genera debate sobre sus
beneficios (Pressman, 2010) .
2.3.2 El manifiesto ágil
Nació el Manifiesto para Desarrollar Software Ágil, con la firma de un grupo de 17

personalidades del software, en Utha, Estados Unidos, en febrero del año 2001. El
19
propósito de dicha reunión era analizar los principios y valores que ayudarían el
desarrollo de software con mayor rapidez. Representantes de Programación Extrema
(eXtreme Programming), SCRUM, DSDM (Dynamic Systems Development Method),
ASD (Adaptive Software Development), entre otros, proponían la necesidad de una
opción distinta a la existente, por ejemplo: que haya documentación pero no cientos de
páginas nunca utilizadas (Highsmith, 2001).
Este grupo de desarrolladores y consultores de software, y competidores entre ellos en

algunas ocasiones, tomaron el nombre de “The Agile Allience”. Se planteaba una opción
a los procesos de desarrollo habituales, los cuales se definían como rígidos y cuyo
control dependía de la documentación generada en cada etapa (MendesCalo, Estevez,
& Fillottrani, 2009).
2.3.3 Postulados del Manifiesto Ágil
El Manifiesto Ágil establece cuatro postulados que el desarrollo de software debe

valorar (Beck et al., 2001), en la tabla 1 se resumen lo que se valora:
Tabla 1. Postulados del Manifiesto Ágil
POSTULADOS
Valorar personas e interacciones sobre procesos y herramientas.
Valorar software funcionando sobre documentación amplia.
Valorar colaboración con el usuario sobre negociación contractual.
Valorar respuesta ante el cambio sobre seguir un plan.
Adaptado de (Agile Alliance, 2001a)
A continuación, se detalla un análisis de cada postulado considerando la propuesta de

varios autores:
Valorar los individuos y las interacciones del equipo de desarrollo por

encima de las herramientas y los procesos.
Canos (2003) nos indica que para obtener una mejor producción al desarrollar software,
los métodos agiles consideran el talento humano como la pieza fundamental para
20
obtenerlo. Es preferible darle al equipo de desarrollo la libertad que éste defina su

organización de acuerdo a sus necesidades (Canos et al., 2003).
Se brinda atención a quienes integran el equipo de desarrollo esto es opuesto a quienes

consideran que los integrantes del equipo son piezas que se reemplazan facilmente
(Cockburn, 2007).
Valorar el desarrollo de software que funcione por encima de la

documentación.
Los métodos ágiles apoyan lo importante que es la documentación, pero aconsejan solo
preparar la documentación estrictamente indispensable, la cual debe ajustarse a la parte
fundamental, dando predominio al contenido. La documentación ágil pretende aplicar
elementos menos costosos y con mayor dinámica como por ejemplo la comunicación
personal, la correcta funcionalidad del equipo de trabajo, los estándares y la auto
documentación (Herrera Uribe & Valencia Ayala, 2007).
Es más importante la comunicación entre los individuos que la documentación, solo

redactar lo necesario (Cockburn, 2007).
Valorar la colaboración del cliente por encima de la negociación

contractual.
En los métodos clásicos el usuario define sus necesidades, y según lo planificado tendrá
resultados en un tiempo definido; en el desarrollo ágil el usuario se convierte en parte
del equipo. El contrato firmado define la responsabilidad que se formaliza para cada
una de las partes (MendesCalo et al., 2009).
Las metodologías ágiles incorporan de forma comprometida y directa al usuario en el

equipo de trabajo. Según Cockburn ( 2007) nos indica que intentan lograr el beneficio
en común de todos los participantes. La colaboración del cliente es importante, de
principio hasta el final del desarrollo. El usuario es el que conoce y sabe lo que desea,
se fomenta la comunicación entre individuos.
21
Valorar la respuesta al cambio por encima del seguimiento de un plan.
Valencia Ayala, (1995) menciona que considerando la naturaleza progresiva de la

tecnología y también la dinámica en una sociedad, un proyecto de desarrollo de software
confronta cambios durante la ejecución, pueden ser desde simples ajustes en cuanto a
la personalización del software hasta variaciones complejas.
Los métodos tradicionales no tienen la habilidad para dar respuesta ante las variaciones.
Al contrario, la planificación en las metodologías agiles, debe tener flexibilidad para la
adaptación al surgimiento de cambios. Una estrategia es realizar planificaciones
destinadas para pocas semanas y planificaciones con mayor cobertura para los meses
siguientes. Al laborar con pequeñas iteraciones, los líderes del proyecto pueden realizar
cambios a las prioridades para reflejar sus necesidades (Cockburn, 2007).
2.3.4 Doce Principios del Manifiesto Ágil
De los postulados, se crean los doce principios del Manifiesto Ágil (Cunningham, 2001).
La Agile Alliance (2001b) define los principios que dan las características del desarrollo
ágil, están publicados en su página web, los Principios se transcriben a continuación:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana

y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
Los procesos ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles
el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
22
Las mejores arquitecturas, requisitos y diseños, emergen de equipos auto

organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.(Agile
Alliance, 2001b, párr. xx)
Cada propuesta de metodología ágil considera los principios, pero poseen propiedades
particulares y hacen énfasis en aspectos más específicos (Cockburn, 2007).
Según Poole (2009) establecer una definición precisa de Metodología ágil no es sencillo,
quizá porque ágil encierra una extensa propuestas de metodologías y por la razón de
que Ágil está determinado como los cuatro postulados del Manifiesto Ágil (ver Tabla 1).
Canos (2003) considera que un modelo resulta ser ágil o liviano al momento de emplear
para su construcción un procedimiento o herramienta sencilla, la cual tenga como
objetivo desarrollar un modelo suficientemente bueno y aceptable, un modelo resulta
ser suficientemente bueno al momento de cumplir con los objetivos para el que fue
creado, adiciona valor al proyecto, y es fácil de construir (Canos et al., 2003).
Cockburn (2007) indica que la clave para el éxito del enfoque ágil son las personas.
Así como MendesCalo (2008) menciona que estos modelos ágiles planifican realizar la
entrega del software en pequeñas y utilizables partes, las cuales se les atribuye el
nombre de incrementos, consideran ciclos de desarrollo iterativos e incrementales.
2.3.5 Estado del Desarrollo Ágil
La doceava encuesta que analiza el Desarrollo Ágil, presentó sus resultados, fueron
publicados el 9 de abril del 2018. Esta encuesta la realiza anualmente CollabNet
VersionOne entre los que practican metodologías ágiles. (CollabNet VersionOne, 2018).
Esta encuesta hace un análisis del estado del desarrollo ágil, por ejemplo, nos responde
¿Cuál es la metodología con mayor aceptación? A continuación, un detalle de sus
principales respuestas.
Se obtuvieron 1.492 respuestas. Los encuestados pertenecen a diferentes lugares del
planeta, la distribución geográfica se muestra en la imagen, Figura 8, el 55% pertenecen
a América del Norte, 7 % América del Sur dando un total del 62% en el nuevo
Continente, Europa el 27 %, Asia el 7%, África el 1 % y Oceanía (Australia) el 3%.
23
Figura 8. Localización de los encuestados (CollabNet VersionOne, 2018)
Para los encuestados la razón para adoptar el desarrollo ágil es: con un 75%, aumenta
la aceleración de la gestión del desarrollo del software; un 64% opinan porque se
gestiona el cambio de prioridades, seguido con un 55% de personas que opinan que el
desarrollo ágil incrementa la productividad, mientras que el 49% indica que su razón es
la alineación para mejorar los negocios TI, y un 46% opina que la causa es que aumenta
la calidad del software (Figura 9).
24
Figura 9. Razones para adoptar el desarrollo ágil (CollabNet VersionOne, 2018)
De la misma manera se observa en la Figura 10 que los beneficios para adoptar el

desarrollo ágil son varios, entre ellos un 71% coincide en que ayuda a gestionar el
cambio de prioridades, también un 66% indica que le brinda una visibilidad al proyecto,
el 65% opina que influye en la alineación de los negocios TI, 62% dice que hay una
mayor velocidad de entrega al momento de realizar la compra del producto y un 61%
menciona que posee un mejor equipo de productividad.
25
Figura 10. Beneficios para adoptar el desarrollo ágil (CollabNet VersionOne, 2018)
En la Figura 11 se hace referencia a las técnicas ágiles empleadas, la encuesta nos da

como resultados de varias técnicas, pero entre las 5 primeras tenemos en primer lugar
con un 90% Daily Standup (reunión diaria de pie), luego un 88% para la planificación de
la iteración, el 85% le corresponde a la retrospectiva, el 80% es para la revisión de la
iteración y luego el 69% para las iteraciones cortas.
26
Figura 11. Técnicas ágiles empleadas (CollabNet VersionOne, 2018)
Se observa que existe una disminución, relacionando el anterior año, en cuanto al

porcentaje de personas encuestadas expresando que las culturas organizacionales en
desacuerdo con las practicas o valores agiles, además de la falta de disponibilidad ya
sean de negocios clientes, propietario del producto, fueran las barreras además de
herramientas fragmentadas, procesos inconsistentes entre equipos y resistencia
general al cambio (Figura 12).
En relación a la Figura 13 se observa que Scrum (56%), ScrumBan (8%) y Scrum/XP

Hibrido (6%) acumulan el 70% resultando en donde se indica que son las metodologías
agiles comunes que son más utilizadas en las organizaciones de los encuestados.
También aparecen Híbridas (múltiples tecnologías 14%), otras metodologías (6%),
Kanban (5%) y desarrollo iterativo (3%). Con el 1% cada una aparecen las metodologías
Extreme Programming (XP), Lean Startup y Spotify Model.
27
Figura 12. Desafíos al adoptar el desarrollo ágil (CollabNet VersionOne, 2018)
Figura 13. Metodologías ágiles usadas (CollabNet VersionOne, 2018)
28
2.4 Metodologías Agiles más usadas
Considerando como referencia la encuesta 2018 del estado del desarrollo Ágil a nivel
mundial, las metodologías para desarrollo de software más utilizadas son (ver figura 13):
 Scrum
 Kanban
 Programación eXtrema
Existe una tendencia según la encuesta a una mezcla de las mejores prácticas de estas
metodólogas, se describe a continuación las tres metodologías más importantes.
2.5 Metodología Scrum
2.5.1 Introducción
“Scrum es un modelo de desarrollo ágil definido por Ikujiro Nonaka e Hirotaka Takeuchi
en los años ochenta del siglo pasado, y adaptado por Ken Schwaber y Jeff Sutherland
como procedimiento de desarrollo de software en 1995” (Monte, 2016, p. 14).
Ken Schwaber y Jeff Sutherland propuesieron Scrum con el objetivo de encontrar una
forma diferente a lo tradicional para construir software, sus creadores lo consideran un
marco de trabajo, no una metodología, dentro del cual se pueden emplear otros
métodos (Kniberg, 2007).
“El marco de trabajo Scrum consiste en los Equipos Scrum, sus roles, eventos,
artefactos y reglas asociadas”. (Schwaber & Sutherland, 2017, p. 3). Cada elemento en
este método de trabajo tiene su función específica.
Scrum se fundamenta en la teoría de control de procesos empírica, basado en toma de

decisiones de acuerdo a la experiencia de lo que se conoce. Este control empírico se
centra en revisiones periódicas para analizar si estamos por el camino correcto, si hay
forma de mejorar o que nos impide avanzar (Schwaber & Sutherland, 2017).
El control dentro de este método necesita: inspección, transparencia, y adaptación; la

inspección y adaptación requieren reflexión y disciplina (Schwaber & Sutherland, 2017).
29
Transparencia: Los aspectos significativos del proceso tienen que ser conocidos por
todos, mediante un estándar, por ejemplo: una interpretación común de
“terminado”(Monte, 2016).
Inspección: Los artefactos son chequeados por los usuarios para localizar cambios
inesperados (Schwaber & Sutherland, 2017).
Adaptación: La ejecución de tareas que ayuden a corregir alguna desorientación, o se

plantee nuevo objetivo (Monte, 2016).
Scrum busca crear equipos guiados por el principio de Planificar, hacer, comprobar y
actuar en ciclos de mejora continua(Monte, 2016).
Scrum se constituye de unos elementos que ayudan a la gestión del proyecto. No

establece herramientas que controlen el proyecto, sino que lo deja a la elección de las
que sean útiles para ejecutar las tareas. Scrum propone los roles, las actividades y los
artefactos siguientes para su marco de trabajo (Monte, 2016):
Tabla 2: Roles, Artefactos y Eventos Scrum
Roles Artefactos Actividades o Eventos
El Equipo Scrum (Scrum Del proyecto(Software):  Sprint (Ciclo)

Team) formado por:  Product Backlog Contiene:
 Product Owner  Sprint backlog

 Sprint Planning
 Scrum Master (Planificación del
 Development Del Sprint: Sprint)
Team  Increment  Daily Scrum
(Scrum Diario)
 Parking backlog
 Sprint Review
 Scrum board (Revisión del
Sprint)
 Sprint Retrospective
(Retrospectiva del
Sprint)
Adaptado de (Monte, 2016)
30
2.5.2 Roles en Scrum
El equipo Scrum (Scrum Team), se compone de 5 a 9 miembros, es autoorganizado y

multifuncional, capaz de gestionar su trabajo de manera eficaz. Los Equipos Scrum
entregan resultados de forma iterativa e incremental. Se detalla los tres roles que
componen el equipo: (Schwaber & Sutherland, 2017).
Product Owner (Dueño del Producto). “Conoce qué producto final desea obtener y
cómo debe ser” (Saiz Jorge, 2017). Define junto con el Scrum master los criterios de
aceptación del proyecto y de cada sprint. Es el único individuo que se encarga de tratar
toda la Lista del Producto, además manipula las prioridades en la lista, asegura que es
visible, transparente y clara para todos; y señala los requerimientos de esta lista en
que el Equipo de desarrollo se ocupará (Monte, 2016).
Scrum Master. Es el experto en Scrum, es decir es la persona que dirige y da la debida

asistencia a todo el grupo que pertenece al Equipo Scrum, de alguna manera coordina
a los demás sin ser su líder para que se auto-gestionen, es la ayuda para que todos
entiendan las prácticas, reglas, valores y teoría de Scrum(Schwaber & Sutherland,
2017).
Development Team (Equipo de Desarrollo). Formado entre tres y nueve

integrantes, el equipo podría incluir a personas con habilidades en la documentación,
diseño de base de datos, el análisis, programación, pruebas y diseño de interfaces;
estos profesionales se encargan de dividir los requisitos en tareas, estimar su esfuerzo
y desarrollarlas, son auto-organizados. Los papeles que desempeñan tanto el Dueño
del Producto como el Scrum Master no intervienen en el cálculo, salvo que estén
desarrollando. Pueden existir múltiples equipos Scrum, cada uno concentrado en otras
particularidades del producto. (Sutherland & Schwaber, 2011).
2.5.3 Artefactos o Elementos de Scrum
Los elementos Scrum son las evidencia físicas que se generan como resultado de su
aplicación, representan el resultado de las actividades(Palacios, 2017). Se consideran
como las herramientas para que los diferentes roles puedan organizarse y ejecutar su
trabajo (Monte, 2016).
31
Entre los principales elementos encontramos: Product Backlog, Sprint Backlog e

Incremento.
Product Backlog (Lista de Producto). Todos los requisitos a desarrollar forman un

detalle en una lista (Palacios, 2017). Esta lista la crea el Product Owner, es su
responsable directo, se apoya para crearla con los distintos Stakeholders de la
organización, y refleja el trabajo que queda pendiente, menciona el autor (Palacios,
2017). “Se escribe en el idioma del cliente”, no se utiliza lenguaje técnico (Monte, 2016).
Se empieza con los requisitos conocidos, mejor entendidos y priorizados; se aceptan
nuevos requerimientos para la lista (Schwaber & Sutherland, 2017).
Sprint Backlog (Lista de Pendientes del Sprint). Es el conjunto de requerimientos

seleccionados del Product Backlog, después de realizar la planificación del Sprint
Planning, para que sean procesados en el ciclo Sprint. El equipo de desarrollo se
encargará de gestionarlo y de mantenerlo actualizado (Schwaber & Sutherland, 2017).
Increment (Incremento). Es el resultado del ciclo Sprint, una parte del Producto total,
construido de manera iterativa e incremental. La suma de los incrementos es el Producto
final, mediante las iteraciones de cada Sprint(Palacios, 2017).
Parking backlog (Tareas bloqueadas). Son las tareas bloqueadas por problemas
que no permiten finalizarlas, por ejemplo: se necesita de un resultado intermedio; deben
quedar solucionados al final del ciclo por los miembros del Equipo. (Monte, 2016).
Scrum board (tablero Scrum). Es una herramienta visual que muestra el estado del
sprint, el Scrum Master lo administra con el apoyo del Equipo de desarrollo. Se divide
mínimo en tres columnas: Por Hacer (not started), En Proceso (In progress), Finalizado
(Done). Por las columnas del tablero se desplazan las tareas (historias) a medida que
avanza el sprint. Se pueden añadir otros estados según necesidad del Equipo(Monte,
2016). En la Figura 14 se muestra un ejemplo de Scrum Board.
32
Figura 14. Ejemplo de Scrum Board (Jim Bowes, 2014)
2.5.4 Eventos o Actividades en Scrum
Existen eventos (reuniones) que se determinan para minimizar las reuniones que aún
no se encuentran definidas. Estos eventos se denominan bloques de tiempo con
duración máxima. Las mínimas actividades que propone Scrum para manejar el control
del proceso son: (Schwaber & Sutherland, 2017).
 Sprint (Ciclo)
 Daily Scrum (Scrum Diario)
 Sprint Planning (Planificación del Sprint)
 Sprint Review (Revisión del Sprint)
 Sprint Retrospective (Retrospectiva del Sprint)
33
Figura 15. Eventos en Scrum (Capó, 2013)
Sprint. Es un periodo de tiempo, semanas o un mes, donde se construye una parte

del producto final (Increment, de origen en inglés), este incremento es integrado y útil
para los usuarios. Es como un proyecto y no se hacen cambios durante su ejecución,
sólo el Product Owner lo puede cancelar (Schwaber & Sutherland, 2017).
El sprint contiene el resto de actividades que forman Scrum (Palacios, 2017). Se

aconseja que la duración del sprint se elija al principio y sea constante. El equipo puede
decidir cambiarla (Monte, 2016).
Sprint Plannig (Planificación de Sprint). Es una reunión de máximo 8 horas,

donde el Equipo Scrum participa completo, antes de planificar, el Product Owner,
prioriza y crea el Product Backlog; y propone el objetivo del Sprint (Sprint Goal). Tiene
dos partes la reunión: primero se trata el ¿Qué? puede hacerse en el Sprint, es liderada
por el Product Owner, el equipo analiza, evalúa y selecciona ítems para el Sprint. En la
segunda parte, se discute el ¿Cómo?, el equipo completo lidera y crea el plan de acción.
El Scrum Master se asegura que la reunión se realiza.(Palacios, 2017). La figura 16

muestra el flujo de la reunión.
34
Figura 16. Flujo de Planificación de Sprint (Palacios, 2017)
Como resultado de la planificación se obtiene: Product Backlog actualizado, Sprint

Backlog y Sprint Goal.
Daily Scrum (Scrum Diario). Consiste en reunirse diariamente el Equipo de

desarrollo, utilizando la herramienta del Scrum Board y a una hora establecida. Toma
unos 15 minutos y es controlada por el Scrum Master. Sirve al equipo para explicarse,
hacer seguimiento del estado a nivel de tarea, identificar impedimentos, resolver dudas
y mejorar el nivel de conocimiento, no se proponen soluciones. Cada miembro se dirige
solamente al Equipo(Schwaber & Sutherland, 2017). Sutherland, (2015), nos indica un
ejemplo de preguntas que se pueden plantear:
¿Qué hice ayer para conseguir el objetivo del Sprint?,
¿Qué haré hoy para conseguir el objetivo del Sprint?,
¿Existe algún impedimento que no permita lograr el objetivo del Sprint?
Sprint Review (Revision Del Sprint). Los autores de Scrum Schwaber & Sutherland
(2017, p.13) nos describen la revisión del Sprint:
35
Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si fuese necesario. Durante la Revisión
de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo
durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto
durante el Sprint, los asistentes colaboran para determinar las siguientes cosas
que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no
una reunión de seguimiento, y la presentación del Incremento tiene como objetivo
facilitar la retroalimentación de información y fomentar la colaboración.
Se trata de una reunión de, a lo sumo, cuatro horas para Sprints de un mes. Para
Sprints más cortos, el evento usualmente más corto. El Scrum Master se asegura
de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El
Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo
fijado (Schwaber & Sutherland, 2017, p. 13).
Sprint Retrospective (Retrospectiva de Sprint). Es una reunión para la

autoevaluación del Equipo Scrum y para la creación de un plan de mejoramiento que
será aplicado en el próximo Sprint. Se da luego de la respectiva Revisión de Sprint y
anteriormente de la próxima Planificación de Sprint. A lo sumo durará tres horas la
reunión para Sprints de 30 días. Asiste El equipo Scrum completo, el Dueño de la
reunión es Scrum Master (Schwaber & Sutherland, 2017).
Sirve para debatir entre Scrum Master y el Equipo de desarrollo sobre lo desarrollado
en el Sprint, analizar incidentes y bloqueos, buscar soluciones, aplicar la mejora
continua al proceso y compartir los éxitos (Palacios, 2017).
2.5.5 Resumen del Ciclo de vida del desarrollo de Software en

Scrum
Saiz Jorge ( 2017), ilustra en la figura 17 el proceso Scrum y nos comentan un resumen
del ciclo de vida para desarrollar con Scrum:
Antes del Sprint
El Product Backlog es creado por El Product Owner, esta lista contiene las características
que el producto final debe tener. Una de las ventajas es que esta lista no es cerrada y las
necesidades del cliente pueden variar a lo largo del proyecto.
En una reunión llamada Sprint Planing Meeting, en la que se reúne todo el equipo Scrum,
se decide qué se debe obtener en el primer Sprint, será el Sprint Goal. En esa reunión se
elabora el Sprint Backlog, otra lista que reúne las características que debe cumplir el
incremento que se va a entregar. Además, se planifica el trabajo que va a desarrollar el
Development Team.
36
El Sprint
A partir de ahí comienza el Sprint, de 2 a 4 semanas de trabajo en las que el equipo de

desarrollo realiza las acciones que dan como resultado un producto intermedio entregable
y plenamente operativo. Cada día se realiza el Daily Scrum, una mini reunión de no más
de 15 minutos. En ella el Scrum Master con el Development Team evalúan el desarrollo
del Sprint y ponen en común todo aquello relevante que pueda afectar al equipo.
Figura 17. Marco Scrum (Saiz Jorge, 2017)
Después del Sprint
Transcurrido el plazo acordado finaliza el Sprint. Se entrega el producto intermedio y se

realiza una tercera reunión, el Sprint Review. En esta reunión todo el equipo Scrum valora
el resultado alcanzado en el Sprint. A partir de este punto el Product Owner podrá
actualizar su Product Backlog y decidir qué quiere alcanzar en el siguiente Sprint.
Pero antes de iniciar un nuevo ciclo falta una última reunión, el Sprint Retrospective.
Aunque no lo parezca, esta reunión puede ser de gran utilidad. En ella el Scrum Master y
el Development Team tratan de analizar los aspectos positivos y negativos del Sprint
anterior. El objetivo es identificar las mejores prácticas que se deben aplicar en la operativa
para mejorar en eficiencia y calidad.
Desde este punto comienza un nuevo Sprint, otro ciclo. Esto se repetirá tantas veces como
sea necesario hasta el final del proyecto.
37
2.6 Metodología Kanban
2.6.1 Introducción
Kanban proviene de la palabra kan cuyo significado es visual, y el significado de ban es

tarjeta o tablero, es un concepto que se desarrolló en el Sistema de Producción de la
marca Toyota. David Anderson en el 2004 adapto Kanban para desarrollar software
(Figuerola, 2011).
“Es una herramienta que sirve para organizar el trabajo, para ser cada vez más óptimo,
productivo y eficiente” (Rua, 2017, párr. xx).
2.6.2 Actividades principales de Kanban
Bahit (2011) nos indica que Kanban es uno de los métodos adaptativos que presenta
una menor tenacidad al cambio y sus actividades principales son: “Visualizar el proceso,
Limitar el trabajo en curso, Optimizar el flujo de trabajo” (Bahit, 2011).
Visualizar el proceso. Los pizarrones o tableros de tarjetas permiten un control

visual y de seguimiento, convirtiéndose en herramientas populares de control para el
desarrollo ágil (Leonardo De Seta, 2008).
Un tablero kanban como el mostrado en la Figura 18 es un ejemplo, pero no representa

la única forma de visualizar. Para que sea un sistema Kanban de visualización, debe
definir las entregas y compromisos, además de las restricciones de carga en cada una
de las columnas del tablero, desde su inicio hasta la fase final (Anderson & Carmichael,
2016).
Fragmenta el trabajo en tareas representadas en tarjetas, estas tarjeta se colocan en

el tablero (kanban board ), existen columnas predefinidas con nombres adecuados que
identifican el estado de cada tarea. (Figuerola, 2011).
38
Figura 18. Tablero Kanban (Alcocer M., 2015)
Limitar el trabajo en curso (WIP). Indica cuantas tareas se pueden procesar

(Figuerola, 2011). El equipo acuerda por anticipado, el máximo de ítems que pueden
realizarse por columnas del tablero.
Bahit, (2011) afirma que: Nos permite conocer la lentitud de un proceso por
aglomeración de tareas. Esto produce un cuello de botella representado cuando se
detiene un proceso. Se ilustra el WIP en la Figura 19.
Figura 19. (WIP límite de tareas, (Bahit, 2011)
39
Optimizar el flujo de trabajo. Kanban propone estos conceptos para controlar el

flujo de las tareas(Bahit, 2011):
 El Lead Time (Tiempo de entrega), comienza cuando realiza la solicitud el
usuario y finaliza en el momento de la entrega al usuario(Rua, 2017), para el
usuario esto es lo importante, ver figura 20.
 El Cycle Time (Tiempo del ciclo), es el tiempo promedio para completar un
tarea, desde el inicio hasta el fin de las columnas del tablero (Figuerola, 2011),
es el tiempo de trabajo utilizado por el Equipo de desarrollo, ver Figura 20 para
su ilustración.
Figura 20. Cycle time y Lead time (Roock Stefan, 2010)
El rendimiento de trabajo (Throughput), se obtiene al dividir, CycleTime / WIP, esto

indica en un tiempo determinado que cantidad de tareas(ítems) un equipo puede
desarrollar (Bahit, 2011). Se busca que el cycle Time sea el mínimo y el rendimiento de
trabajo sea el máximo.
2.6.3 Roles de Kanban
Anderson & Carmichael ( 2016), sobre los roles nos explican que no hay Roles pero
han surgido con la práctica los siguientes:
Dos roles han surgido de la práctica común y ahora se definen en el método en sí mismo.
Es el propósito de los roles lo importante, más que asignarle a alguien un cargo.
40
El Gestor de Peticiones de Servicio (Service Request Manager), es responsable de

entender los requsiitos y expectativas de los usurios, y de facilitar, seleccionar y ordenar
los elementos de trabajo en la Reunión de revisión de la cartera de trabajo (Replenishment
Meeting). Otros nombres alternativos del rol son Gestor de Producto (Product Manager),
Dueño de Producto (Product Owner) y Gestor de Servicio (Service Manager).
El Gestor de Prestación de Servicio (Service Delivery Manager) es el responsable del

flujo de trabajo entregando los elementos seleccionados a los clientes y facilitando la
Reunión de Kanban y la planificación de la entrega (Delivery Planning). Otros nombres
alternativos a este rol son Gestor del Flujo de trabajo (Flow Manager), Gestor de la
Entrega, o Maestro del Flujo (Flow Master) (Anderson & Carmichael, 2016, p. 42).
2.7 Metodología Programación eXtrema (XP)
Programación eXtrema conocida como XP, su nombre original en inglés es: “Extreme
Programming”. Kendall & Kendall( 2005,p. 68) lo define como: “Es un enfoque de
desarrollo de sistemas que acepta lo que conocemos como buenas prácticas de
desarrollo de sistemas y las lleva al extremo”.
Algunos de los componentes y sus reglas son tan antiguos y conocidos como la
programación. Se aclara que el resultado es una metodología única y compacta para
aplicarla al proceso de crear software creada por Kent Beck (Robles & Carlos, 2014).
2.7.1 Elementos de XP
Dentro de los instrumentos utilizados en XP se resaltan las historias de usuarios como

el instrumento fundamental y las tarjetas CRC (clases-responsabilidades- colaboración).
2.7.2 Roles de XP
Tomando como referencia lo propuesto por Beck & Andres( 2004): los roles que se
aplican en XP son: programador, cliente, Probador, Rastreador, Entrenador, Consultor
y Gesto.
Kendall & Kendall (2005) nos describe cada rol a continuación:
Programador. Es el núcleo del desarrollo de XP. Las habilidades de comunicación se

exigen para codificar en parejas de programación, cada programador codifica.
“El programador necesita tener excelentes habilidades técnicas para programar,

rediseñar y realizar pruebas unitarias al código que escriba. Además, aprender de otros,
41
compartir el código y el diseño, y tener el valor para superar cualquier fracaso” (Kendall
& Kendall, 2005, p. 74).
Cliente. Define especificaciones por medio de las historias de usuario, redacta pruebas
funcionales para validar las aplicaciones. Enfrenta los problemas del desarrollo(Kendall
& Kendall, 2005).
Probador (tester). Encargado de todas las pruebas, da asistencia al usuario para

redactar las pruebas funcionales. Además de poner en ejecución las pruebas con
regularidad, hace público los resultados obtenidos en el equipo. A los programadores
se les pide que realicen las pruebas y comunicarse con el cliente sobre las pruebas de
funcionamiento, además elaborar informes precisos acerca de los resultados de las
pruebas.
Rastreador (tracker). Encargado de seguimiento del proceso general, brinda

retroalimentación al equipo en el proceso XP. Evalúa las estimaciones contra el tiempo
real dedicado para mejorarla, Además, da seguimiento a las pruebas.
Entrenador (coach). Es experto en XP, responsable del proceso total, identifica

desviaciones y muestra la corrección, guía al grupo de forma indirecta.
Consultor: Forma parte de las personas externas del equipo que cuenta con
conocimiento determinado en un tema en concreto para el proyecto. El equipo de
desarrollo XP espera del consultor es con el resolver sus propios problemas y recobrar
la confianza (Kendall & Kendall, 2005).
Gestor (big boss): Jefe del Proyecto o líder, es el coordinador.
“Es el vínculo entre programadores y clientes, ayuda a que el equipo realice un efectivo
trabajo creando las condiciones adecuadas” (Kendall & Kendall, 2005).
2.7.3 Proceso XP
Los proyectos de XP tienen un enfoque interactivo e incremental que construyen un

software con evolución, las iteraciones son los ciclos que permiten los cambios
incrementales a través de pruebas y retroalimentación repetidas que crean un producto
estable (Kendall & Kendall, 2005).
42
El ciclo de vida de XP según su creador, Beck(2004) consta de seis fases: Exploración,

Release (Planificación de la entrega), Iteraciones, Mantenimiento, Producción y Muerte
del Proyecto (Beck & Andres, 2004).
Pressman (2010) indica que, el paradigma preferido de desarrollo XP es un enfoque

orientado a objetos, y para esto lo resume en cuatro actividades estructurales:
planeación, diseño, codificación y pruebas. La Figura 21 muestra el proceso XP con sus
tareas e ideas asociadas para cada actividad. A continuación se resume las actividades
de XP tomando como referencia el punto de vista de Pressman (2010):
Figura 21. Proceso XP(sites.google.com,2017)
Planeación. Previo hay una etapa llamada exploración considerada por su creador
Beck(2000). Se conformará el equipo y valorará sus habilidades, dura desde unas
semanas, si se tiene experiencia, hasta algunos meses si todo es nuevo. Se examina
las tecnologías que se utilizan para el proyecto. Se practica y estima el tiempo para las
tareas. Los clientes experimentan con la redacción de sus historias de usuario. Lo
43
importante en esta etapa es comprender y desarrollar el entorno XP (Kendall & Kendall,

2005)
La Planeación comienza escuchando los requerimientos de los usuarios por parte del
equipo de desarrollo XP para entender la funcionalidad que requieren, se utiliza la
técnica de Historia de Usuario (Pressman, 2010). Aquí radica una diferencia con las
metodologías tradicionales, al cliente no se le pide una historia exacta de lo que quiere
al principio, solo tiene que escribirla y ponerle prioridad, no se usan casos de uso
tradicionales, propuesto por UML(Robles & Carlos, 2014).
Las personas encargadas de trabajar en equipo para tomar la decisión de cómo asociar
las historias en las próximas entregas, es decir cuando haya un incremento de software,
serán los clientes y los desarrolladores. Se llega a un compromiso para la primera
entrega, luego se pasa a la siguiente entrega, llamada incremento de software, y así
sucesivamente hasta el n incremento, el equipo XP calcula el tiempo total y la velocidad
de éste. Si es necesario, habrá modificaciones tanto del contenido como de las fechas
de la entrega final. («Funcionamiento - Metodología XP», s. f.).
Diseño. Se aplica el principio, Diseño Simple. Con el diseño se implementan las

historias de usuarios del paso anterior. XP utiliza el mecanismo de las tarjetas
CRC (clase-responsabilidad-colaborador) para un enfoque orientado a objetos, esto
permite identificar y organizar las clases para el trabajo actual de la interacción. El
diseño tiene como único producto las tarjetas CRC. (Pressman, 2010).
“Se crea un prototipo operativo en el caso de que haya un problema cuando se diseñe
una historia, esto se denomina solución en punta” (Pressman, 2010).
Pressman( 2010) nos indica lo siguiente sobre el diseño y rediseño:
El diseño se da tanto antes como después que se realiza la codificación.

Rediseñar significa que el diseño se hace de manera continua conforme se
construye el sistema. En realidad, la actividad de construcción en sí misma dará
al equipo XP una guía para mejorar el diseño. (Pressman, 2010, p. 64).
Codificación. Antes de codificar se tiene listo las historias y el diseño preliminar, el

equipo empieza preparando pruebas para cada historia a implementar. El desarrollador
se capacita para aprobar la prueba. Una prueba unitaria se le aplica de inmediato al
44
código terminado, con esto los desarrolladores tienen retroalimentación (Pressman,

2010)
Pressman (2010) nos comenta sobre XP y nos indica que dos programadores trabajan
en equipo con el objetivo de crear la codificación de una historia, las parejas de
programadores consideran la integración su responsabilidad.
Pruebas. Beck ( 2000) divide las pruebas en XP en dos grupos:

 Pruebas Unitarias. Para verificar el código, se diseña por medio de los
programadores. Deben permitir ejecutarse en repetidas veces y con facilidad, se
debe considerar utilizar estructuras que permitan automatizarlas. La filosofía del
rediseño en XP acepta modificar código varias veces (Pressman, 2010).
 Pruebas de aceptación o Pruebas funcionales. Evalúa al final de una iteración si

se consiguió la funcionalidad requerida, el cliente es el encargado de diseñarla.
Se enfocan en el funcionamiento y las características generales del sistema
donde el cliente puede observarlas y revisarlas, provienen de las historias de los
usuarios que se han efectuado para desplegar a funcionar (Pressman, 2010).
2.8 Herramientas de Desarrollo
A continuación, se analizan dos herramientas de desarrollo que hacen una propuesta

ágil, la herramienta Genexus que se manifiesta como una capa de abstracción sobre los
lenguajes de programación y base de datos existentes, y la herramienta Velneo que
propone su propia base de datos y un marco de elementos para el desarrollo.
2.8.1 La herramienta GeneXus
El ambiente Genexus permite desarrollar sistemas considerando una abstracción de

muy alto nivel sobre la tecnología existente de lenguajes y bases de datos, es una
herramienta que tiene elementos para describir los sistemas de información. (Latorres,
Salvetto, Borges, & Nogueira, 2015).
GeneXus es una herramienta diseñada para el desarrollo de aplicaciones informáticas

en dispositivos móviles, Web, Windows y plataformas heredadas, basada en la
obtención del conocimiento general de la empresa partiendo del conocimiento de los
45
usuarios involucrados, llamado “realidad”, de tal manera que nos permite un desarrollo
ágil y flexible por medio de una base de conocimiento, cumpliendo así el objetivo
principal de GeneXus que es la implementación en el menor tiempo posible y con la
mayor calidad posible(GeneXus training, 2017a). GeneXus provee una poderosa
herramienta con un enfoque diferente a las metodologías clásicas, como se observa en
la Figura 22.
Figura 22. Esquema de funcionamiento de GeneXus (GeneXus training, 2017a)
Artech Consultores(2012b), indica que en resumen Genexus fue creado para que sus
clientes se puedan dedicar sin sobresaltos a su negocio, se conviertan en competitivos
y exitosos, dejando la tecnología de Software en manos de GeneXus. Bachmann( 2012)
le agrega al enfoque presentado: “Y de la seguridad también”, indicando que la
seguridad en las aplicaciones es automática, considerando las 10 vulnerabilidades más
clásicas de la OWASP”.
GeneXus da soporte y libera al analista de las tareas automatizables dentro sus

actividades como, por ejemplo: escribir el código fuente de programas, base de datos
con sus tablas y conexión respectiva al programa, entre otras. Concentrando el esfuerzo
del analista en tareas no automatizables como: el análisis de los requerimientos de los
usuarios en función a la realidad de la empresa y del sistema a realizar, describiendo
los objetos para posteriormente crear una base de conocimiento(GeneXus training,
2017b).
46
Características Generales de Genexus
El conocimiento es esencialmente incremental, igual que una persona: de una forma

incremental aprendemos y pensamos. La consecuencia de manejar el conocimiento es
un comportamiento inteligente de GeneXus automatizando tareas.
Entre las características que ofrece la herramienta podemos encontrar las

siguientes(Artech Consultores, 2012b, párr. xx):
 La base de conocimiento (denominada Kb) con solo ser descrita una vez, se
puede generar varios ambientes(base de datos y/o lenguajes) por
separados.(Gonda & Jodal, 2007)
 El modelado de la base de datos son de manera automática (Verástegui, 2010).
 El aplicativo (base de datos y programas) posee siempre independientemente
de las modificaciones sufridas, la mejor calidad en datos al aplicar la tercera
forma normal más óptima.
 Generar soluciones de reportes y Data Warehousing simples y potentes.
 Independencia de plataforma, lenguajes y arquitectura.(Gonda & Jodal, 2007)
 Simplicidad gracias a que:
“GeneXus utiliza los recursos más avanzados de la inteligencia artificial, para
que el analista y los usuarios, puedan aplicarlos de una forma muy
simple”(Artech Consultores, 2012b, párr. xx).
47
Desarrollo con Genexus
Figura 23. Desarrollo con Genexus (GeneXus training, 2017a)
La Figura 23, ilustra su metodología, el analista tiene como tarea principal representar
o describir la realidad, GeneXus emplea una metodología incremental aplicando
prototipos, bajo un desarrollo basado en conocimiento, este conocimiento es generado
por las visiones de los usuarios que parten de la percepción en función del ambiente y
la actividad de la empresa. En consecuencia la metodología usada por GeneXus tiene
como objetivo la evolución del producto(incrementos) por cada entregable, hasta cumplir
las expectativas amoldadas al requerimiento del usuario.(Artech Consultores, 2012b)
El desarrollo con la herramienta GeneXus tiene el siguiente ciclo de vida, se divide en

tres etapas: Diseño, Prototipo y Producción, ver Figura 24 (Artech Consultores, 2012b).
48
Figura 24. Ciclo de vida del desarrollo de aplicaciones (Artech Consultores, 2012b)
“Se comienza con un Diseño, luego se Prototipa, después se Implementa y en

cualquiera de los pasos anteriores se puede regresar al Diseño para realizar
modificaciones” (Artech Consultores, 2012b, párr. 8).
Etapa Diseño. La base de conocimiento de GeneXus es creada en la etapa de Diseño

y será descrita por medio de objetos soportados por GeneXus entre los objetos más
importantes tenemos: transacciones, reportes procedimientos, workpanels, web panels,
data Views(Artech Consultores, 2012b).
Artech Consultores (2012a) indica: En GeneXus cada objeto se especifica

en forma autocontenida sin nunca referirse a archivos ni a cualquier otro
elemento de bajo nivel. Una consecuencia de lo anterior, que será luego muy
importante, es que la base de conocimiento es neutra con relación al
ambiente: arquitectura, hardware, sistema operativo, sistema de gerencia de
base de datos, etc. (Artech Consultores, 2012a,p. 4)
Etapa Prototipo. GeneXus genera la estructura de la base de datos con sus datos y
las líneas de código para la creación del programa en el ambiente del prototipo, para
realizar pruebas con los usuarios. En caso que se detecten mejoras o corrección de la
aplicación se regresa a la etapa de Diseño(GeneXus training, 2017a). No existe
diferencia entre crear prototipos y ambiente de producción. El prototipo es la aplicación
que se generó para alguna plataforma determinada: ¡lo mismo que la aplicación final!
La diferencia radica en que los prototipos sirve para realizar pruebas (Márquez Daniel,
2009, p. 53).
49
Etapa Producción. Cuando las pruebas son concluidas, se inicia la siguiente etapa
denominada Implementación en donde la herramienta GeneXus automáticamente
genera la base de datos y programas que se emplearan en el ambiente de
producción.(Artech Consultores, 2012b).
Ambiente de Implementación multiplataforma

GeneXus crea aplicaciones para dispositivos móviles, Web, Windows y plataformas
heredadas. Genera y conecta automáticamente todas las funcionalidades, servicios y
bases de datos necesarios, y se encarga de todo, desde el lado del cliente hasta el lado
del servidor, Ver Tabla 3 (Genexus.com, 2018).
Tabla 3. Ambiente de Ejecución
Android y iOS
Windows Azure, Servicios Web de Amazon, SAP Hana Cloud Platform,

Plataforma en la nube de Google, IBM Bluemix.
IBM, Linux, UNIX, Windows
Cualquier navegador, cada plataforma
Adaptado de (Genexus.com, 2018)
50
Figura 25. Tecnologías compatibles con GeneXus
Fuente: http://www.genexus.com/technologies
Como podemos apreciar en la figura 25, GeneXus posee varias alternativas de

ambientes para el cliente y el servidor. Para bases de datos las alternativas son: IBM
DB2, DB2 Universal Database, DB2 UDB para iSeries, Informix, MySQL, Oracle,
PostgreSQL, SQL Server, SAP Hana DB, SQLite. También nos da la opción de utilizar
base de datos alojadas en la nube.
51
Características de Seguridad de Genexus
GeneXus ofrece de forma predeterminada remisiones a los riesgos que componen el

OWASP Top 10 como lo manifiestan los siguientes autores.
Genera de forma automática el acceso a la base de datos, tomando en cuenta las

mitigaciones de la industria para evitar ataques de inyecciones SQL. De igual forma,
sanitiza las entradas de datos y codifica sus salidas, evitando ataques de Cross Site
Scripting (Canedo, 2017).
El módulo de seguridad de GeneXus se denomina, GeneXus Access Manage (GAM), el

cual cuenta con los estándares más alto en seguridad, la restricción de usuarios a
funcionalidades de acuerdo al perfil del mismo. (GeneXus training, 2017c)
Los módulos establecidos en GeneXus aseguran que el desarrollador no malgaste

recursos en tareas automatizables de seguridad ni creación de módulos de seguridad
para la aplicación en desarrollo. Así mismos se consiguen detectar y corregir
vulnerabilidades en el ciclo de desarrollo. A su vez que el conjunto de código generado
por la herramienta permite que:
“Las aplicaciones creadas estén a prueba de las 10 vulnerabilidades más clásicas de la
OWASP o detectar código vulnerable a través de reportes” (Bachmann, 2012).
2.8.2 La herramienta Velneo.
Velneo V7 es una plataforma completa de desarrollo de aplicaciones empresariales.

“Está diseñada para hacer más rentable el desarrollo, implantación y mantenimiento de
aplicaciones empresariales gracias a su base de datos integrada y una programación
visual” (velneo, 2018a, párr. xx).
Características Generales de Velneo
Aguilar (2010) en su análisis de la plataforma, nos describe todos los elementos

necesarios para crear y ejecutar aplicaciones, se detallan a continuación:
52
Un componente cliente, llamado vClient, una especie navegador o runtime necesario

para ejecutar las aplicaciones.
Un componente servidor, vServer, que actúa como servidor de aplicaciones, datos y

otras tareas centralizadas. Este servidor puede estar instalado en infraestructura propia
del cliente, o bien utilizar la nube de Velneo para alojar sus servicios.
Un componente de administración, vAdmin, que permite gestionar aplicaciones,

usuarios, permisos y otros aspectos de un vServer.
Una herramienta de desarrollo, vDevelop, desde el que se crean las estructuras de datos
y aplicaciones para la plataforma.
Además, hay otros componentes destinados a tareas más específicas, como el acceso
directo desde cliente a orígenes de datos (vDataClient), un sistema para la localización
de aplicaciones (vTranslator), un driver ODBC propio, un cliente basado en web, y
muchos otros más.
Para comenzar a desarrollar aplicaciones, basta con registrarse en el sitio web de Velneo
facilitando una dirección de correo electrónico. Tras ello, tendremos acceso al Panel de
Control (en el propio sitio web), desde el que podemos crear e iniciar nuestra propia
instancia de servidor vServer en la nube (Aguilar, 2010).
Desarrollo con Velneo
Velneo tiene una propia arquitectura ya configurada, no es necesario elegir herramientas

de desarrollo genéricas. No se utiliza código fuente, la definición de todo lo necesario
como diseño de pantallas, modelo de datos, y funciones se realiza de manera visual
(Aguilar, 2010).
“Velneo es el entorno ágil para el desarrollo de aplicaciones empresariales” (velneo,

2018b). En la Figura 26 se ilustra las fases del desarrollo Velneo, basado del modelo
en cascada.
53
Figura 26. Fases de Desarrollo Velneo (velneo, 2016)
Velneo identifica las etapas:
¿Que? Centrarse en las necesidades del cliente (usuario) y no en programar.

El desarrollador Velneo identifica y se centra más en el qué hacer, representado en las
primeras dos fases: requisitos (flujo de los datos) y diseño (arquitectura de la aplicación).
¿Cómo? Implementar las necesidades, con desarrollo ágil (velneo, 2016).

Considerando que esta todo integrado permite un ahorro de tiempo y recursos evidente.
La propuesta de Velneo supera las características de las metodologías tradicinales
como cascada (velneo, 2016).
Ambiente de Implementación multiplataforma
Se trata de una herramienta multiplataforma, un solo esfuerzo de desarrollo puede

ejecutarse de: “Manera nativa en Windows, Linux, Mac y Android. Incluso podrás
embeber el software en cualquier página Web” (velneo, 2018c, párr. xx).
Ventajas:
 Velneo v7 es un conjunto de herramientas que posee una plataforma que las
integra para el desarrollo.
54
 “Permite un ahorro de tiempo y recursos evidente que, en otras plataformas

tradicionales, en las últimas tres fases: implementación, verificación y
mantenimiento”(velneo, 2016, párr. xx).
Desventajas:
 Los profesionales acostumbrados a programar “a mano”, no aceptan el cambio
de filosofía propuesto. Las cosas se realizan de manera simple en Velneo.
 Falta de profesionales capacitados en Velneo. Las universidades no forman en

Velneo, hay otras plataformas en los currículos.
55
3. Objetivos concretos y metodología de trabajo
3.1 Objetivo general
Proponer un método de desarrollo de software apoyado en las mejores prácticas de

Metodologías Agiles, utilizando la herramienta Case Genexus, para la creación de una
aplicación Web, que permita obtener información en un ambiente de organización
agropecuaria cumpliendo sus requerimientos principales.
3.2 Objetivos específicos
● Examinar las mejores prácticas utilizadas en las principales Metodologías Agiles

que aportan al desarrollo de software en las organizaciones a nivel mundial.
● Determinar las características y funcionalidades de la herramienta Case

Genexus como una herramienta ágil en el desarrollo de software para las
organizaciones reduciendo tiempos e incorporando seguridad.
● Validar la propuesta mediante un caso de estudio aplicado en un ambiente de

organización agropecuaria de la ciudad de Milagro- Ecuador.
3.3 Metodología del trabajo
Para realizar este trabajo se desarrollo la investigación Aplicada, considerando que

orienta la aplicación de conocimientos, con el propósito de implementarlos de forma
práctica para solucionar problemas.
La metodología aplicada en el desarrollo del método propuesto está basado en la

exploración y aplicación de los modelos de prototipos y modelo incremental con el apoyo
de una herramienta que implemente estos modelos. Además, la herramienta debe
considerar el desarrollo basado en conocimiento, enfocando los principios de las
metodologías ágiles, con el objetivo de construir el modelo de desarrollo de software
propuesto.
Se analiza y se toma como referencia lo que manifiestan en común las mejores

prácticas de las metodologías Scrum, Xp y Kanban que según lo expuesto en el capítulo
dos son las más utilizadas como metodologías agiles.
56
En base a la teoría explorada de las metodologías ágiles y la herramienta, se formula

un enfoque general del método a proponer, que tenga los siguientes pasos:
 Los usuarios crean los requerimientos en base a la técnica “historia de

usuarios”, estos se convierten en una lista filtrada y priorizada.
 El equipo de desarrollo aplicará desarrollo incremental a un grupo de

requerimientos que permiten crear una funcionabilidad que puede ser puesta en
producción en corto tiempo, con el uso de prototipos.
 La herramienta Case Genexus generará los programas y base de datos

automáticamente en base al desarrollo basado en conocimiento.
 El uso de ciclo interactivo e incremental permita construir el producto completo

por etapas, en cada etapa se realizarán pruebas.
Se definen varios roles para las personas que forman parte y ejecutan los pasos del
método propuesto. Estos roles permiten el trabajo en equipo, el equipo está formado
por profesionales de desarrollo de software y con la colaboración directa de los usuarios
finales.
Se definen elementos que constituyen resultados de las actividades, estos resultados

son los elementos que pasan por las diferentes etapas, actúan como entrada de un
proceso para permitir obtener una salida. En base a estos elementos se consigue la
construcción del software.
Se definen actividades que permiten poner en acción el método entre las personas que
forman el equipo de trabajo, estas actividades son reuniones.
57
4. Desarrollo de la Propuesta de Metodología
4.1 Identificación de requisitos
El método propuesto para desarrollo de software está basado en la aplicación de

prototipos, para un desarrollo incremental con iteraciones progresivas, hasta conseguir
un producto final de calidad, enfocando los principios de las metodologías ágiles; se
considera también la aplicación de un desarrollo basado en conocimiento.
Como parte fundamental del método que se propone es el apoyo de la herramienta Case
Genexus, versión XV, que implementa los requisitos planteados:
 Desarrollo de Prototipos. Generación automática de programas para

desarrollar un incremento (parte del producto total) para ser evaluados y
construido con los usuarios.
 Desarrollo incremental con Interacciones. Su filosofía es el desarrollo

incremental.
 Desarrollo basado en conocimiento. Construye una base de conocimiento

independiente del ambiente constituido por la base de datos y lenguajes de
programación.
4.1.1 Roles
Con el objetivo de construir un modelo de desarrollo de software identificamos los roles

necesarios:
Líder de Requerimiento. Es la persona que representa a los usuarios y su actividad

principal es definir un banco de requerimientos que debe cumplir el Producto, estos
requerimientos son las características que los usuarios finales detallan en su visión
como lista de deseos. Estos requerimientos tendrán prioridades a corto y largo plazo,
un grupo de estos requerimientos definen los diferentes ciclos que se desarrollarán en
la fase de Construcción.
Los requerimientos en el transcurso del desarrollo se incrementarán o eliminarán dando

flexibilidad a los requerimientos.
Líder de Equipo. Organiza las reuniones del Equipo de Desarrollo, y es quien se

encarga que el proceso del equipo sea ligero y efectivo. Se encarga que los miembros
58
del equipo tengan las herramientas necesarias para desarrollar sus actividades.
Participa en el desarrollo con su experiencia en la herramienta.
Equipo de Pruebas. Está conformado por usuarios y miembros del Equipo de

desarrollo
Analista Gx. Es el profesional de informática con conocimiento en la herramienta

Genexus quien desarrollara el Producto Software en conjunto con los usuarios
asignados.
Equipo de Desarrollo. Está conformado por los siguientes Roles como: Equipo de
desarrollo, Analistas Gx, líder de Requerimientos y Equipo de pruebas.
4.1.2 Elementos
Los elementos necesarios que permiten construir el método son:
CicloGx. Es el tiempo que se procesa la “lista de requerimientos del ciclo” tomada de

la “lista de requerimientos”, por parte del equipo de desarrollo. Tiempo promedio una o
dos semanas.
Estimación. Permite definir con cuantas actividades se puede comprometer el equipo

en un Ciclo. Se estima o mide el nivel de dificultad de las historias de usuarios que llegan
al equipo, no a una persona del equipo.
Historia de usuarios. Es la representación de los requisitos, visión o deseos del

usuario redactados por el mismo, el conjunto de estas historia definen una lista de
características..
Lista de requerimientos. Es el conjunto total de historia de usuarios filtrados y

priorizadas, esperando ser implementadas por el equipo de desarrollo en bloques
denominados ciclos.
Lista de requerimientos del ciclo. Es una porción de la lista de requerimiento que

el equipo de desarrollo está implementando en el ciclo como nuevo incremento,
aplicando prototipos, desarrollo incremental y basado en conocimiento.
Base de conocimiento. Es el repositorio de la herramienta Genexus, contiene la lista

de requerimientos que expresa la visión de los usuarios, permite la generación
automática de programas y base de datos.
59
Prototipo. Es el incremento formado por la implementación en producción, como

resultado de aplicar la lista de requerimiento del ciclo.
4.1.3 Actividades o Reuniones
Las actividades necesarias permiten el trabajo en equipo, realizar controles y tomar

medidas correctivas, estas son las siguientes:
Reunión Definir Producto. Sirve para establecer el alcance del proyecto y se solicita
definir los requerimientos por medio de “historias de usuarios” a los usuarios.
Reunión Planificar Producto. En base a las historias de usuarios se construye la

lista de requerimientos, esto genera la necesidad de planificar los ciclos de desarrollo
incrementales en base a priorizar estas historias de usuarios de la lista.
Reunión Diaria. Dura unos15 minutos que realiza el equipo de desarrollo para
autoevaluarse.
Reunión de Reflexión. Es una reunión que se realiza al final de cada ciclo para
evaluar y aplicar mejora continua al proceso.
Reunión Entrega Final. Se realiza la entrega final del producto a los usuarios por
parte del todo el equipo se realizan un demo.
Identificación del Problema a resolver. Para la validación de la propuesta se

definen las tareas específicas para la construcción de una aplicación Web para una
organización agropecuaria que nos permite la experimentación, partiendo de una
identificación formal de las personas y requerimientos aplicado al personal de la
Asociación de Productores Agropecuarios San Antonio, denominada APASA, como son
sus Directivos, personal administrativo y socios. Se desarrolla con el apoyo de un
equipo de Ingenieros y estudiantes del último semestre de la carrera de ingeniería de
Sistemas de la Universidad Estatal de Milagro-Ecuador.
4.2 Descripción de la Metodología propuesta
La propuesta que se desarrolla da un marco de trabajo para ser aplicado en el desarrollo

y mantenimiento de aplicaciones para manejo de información, ejecutado por los
interesados, tanto usuarios como integrantes de los equipos de desarrollo de software
de cualquier organización.
60
Para objeto del desarrollo de la metodología su aplicación está dentro del ámbito de
requerimientos para una aplicación del sector de una organización agropecuaria.
A continuación, en este capítulo se detalla la propuesta del trabajo de Fin de Máster

donde definimos la Metodología Ágil para desarrollo de aplicaciones, al que llamaremos
“Método Ágil con GeneXus “, lo referenciamos en el resto del documento como Magi-
GX. La figura 27 nos ilustra el proceso completo hasta llegar a construir el Producto
final de software.
4.2.1 Fases y Actividades.
El Método Magi-GX se compone de la siguiente estructura por Fases ver Tabla 4, y

cada fase define etapas detallando cada actividad, las fases son las siguientes:
Tabla 4. Fases del Método Magi-Gx
FASE DESCRIPCIÓN
Fase de Apertura Definición de Requerimientos y Alcance
Fase de Construcción Se describe, genera y prueba el Producto
Fase de Entrega Entrega del Producto Final
(elaboración propia)
61
FASE APERTURA
DEFINIR HISTORIA DE
USUARIO Todo el equipo con usuarios
Lista de requerimientos
PLANIFICAR HISTORIA DE
Líderes con equipo de
USUARIO desarrollo
FASE DE CONSTRUCCIÒN
Lista de requerimientos del

ciclo
Ciclos-Gx
Equipo de desarrollo y usuarios
DISEÑAR
Pruebas
GENERAR
Revisión diaria
IMPLEMENTA
R
Líder y equipo de
desarrollo
BASE DE
CONOCIMIENTO
PROTOTIPO
FASE DE ENTREGA
PRODUCTO
Líder y equipo
Todos FINAL
de desarrollo
ENTREGA FINAL REUNIÒN REFLEXIÒN
Figura 27: Método Magi-GX (elaboración propia)
62
4.3 Fase de Apertura
Aquí es donde se definen actividades que nos ayuden a capturar el conocimiento

(Requerimientos) del usuario, se utiliza la técnica de historias de usuarios (HU) para
construir la Lista de requerimientos que definen el producto Software.
Esta fase busca definir el alcance del proyecto, sus objetivos y planificación. Se define
en base a dos reuniones que se detalla a continuación.
Tabla 5. Reuniones de la Fase Apertura
REUNION OBJETIVO DE REUNION PARTICIPANTES
Definir el Producto Alcance y características Todos (Usuarios y Equipo)
Planificar el Producto Organizar los requerimientos Equipo y Lideres

(Elaboración propia)
4.3.1 Reunión para definir el alcance del Producto.
Se cita a las personas que tienen poder de decisión sobre los requisitos para el
desarrollo del Producto y las personas que desarrollarán el Producto. El Objetivo que
se persigue es que todos los interesados estén claros en el alcance del proyecto, que
debe tener y que no el producto de software. El producto tendrá lo que necesitamos no
lo que soñamos. El líder del producto junto con el líder del Equipo de desarrollo lidera
esta reunión.
La guía para esta reunión considera lo siguiente:
¿Para qué se hace el Producto?

La respuesta que se plantea a esta pregunta ayudará a que todos los participantes de
la reunión encuentren el Objetivo que se persigue. Esta respuesta debe ser simple, clara
y corta enfatizando en las características que permita entender que es alcanzable,
medible y relevante. Todos los participantes pueden y deben enfocar el proyecto.
Definir a que personas impactará el Producto. Los impactos negativos son los
riesgos del proyecto de desarrollo, por ejemplo, la resistencia al cambio. Los Impactos
positivos en las personas es lo que se busca resolver con la aplicación desarrollada.
63
Que se va hacer para construir el Producto. Una vez definido el Objetivo y el

impacto, se lista los requerimientos generales que se van a considerar para construir el
producto, mediante las historias de usuarios.
4.3.2 Historia de Usuario
Es la representación de los requisitos o funcionalidades que los usuarios solicitan para

cumplir con el objetivo del negocio mediante la creación de un producto software, nos
permite establecer los requisitos en un lenguaje natural de los usuarios, describiendo lo
que necesitan.
La historia de usuario se redacta en tarjetas y esta redacción responde a estas

preguntas relacionadas con sus necesidades, ver Tabla 6:
Tabla 6. Preguntas que responde la Historia de usuarios
PREGUNTA DESCRIPCION
¿Quién se beneficia? Actor, rol que desempeña el usuario
¿Qué se quiere hacer? Narrar la necesidad, ese algo
¿Cuál es el beneficio? Por Qué le da valor al negocio
El formato general de historia de usuario es el siguiente:
Rol-necesidad- Beneficio : Como (rol) quiero (algo) para (beneficiarme)
En la siguiente Figura 28 se muestra un ejemplo:
Como Director de Ventas, quiero revisar el desempeño histórico de ventas para

identificar los productos de mejor aceptación
Figura 28. Ejemplo de historia de usuario (elaboración propia)
Este formato para expresar historias de usuarios se inventa en Connextra en el Reino

Unido en 2001.
64
4.3.3 Evaluar La Calidad de la Historia de Usuario
Para evaluar la calidad de la historia se aplica el proceso de las “Tres C” creado por Ron
Jeffiers, se detalla a continuación:
Card (tarjeta). Se escribe la historia de usuario siguiendo el formato:

Rol-necesidad- Beneficio.
Conversation (Conversación). Es la acción de comunicarse usuarios y equipo de

desarrollo para definir los detalles con preguntas y respuestas sobre la historia escrita
en la tarjeta, se llega a un entendimiento.
Confirmation (Confirmación). Se define el criterio de aceptación del Producto

software, con un plan de pruebas que muestre escenarios y cómo se comportará. Se
escribe al reverso de la tarjeta
4.3.4 Reunión para planificar el desarrollo del producto
El líder del equipo concreta esta reunión. Los participantes de esta reunión son: El
equipo de desarrollo, el líder del equipo y el líder de requerimientos. Ellos analizan cada
requerimiento que permitirá paso a paso ir creando la lista de requerimientos agrupados
por funcionabilidad.
El líder de requerimientos tiene la lista de características del paso anterior denominado,

Reunión para definir el producto, estas características que se resumen por medio de
historia de usuarios debe ser priorizadas y organizadas por los asistentes a la reunión
en función a requerimientos comunes que permitan establecer su tiempo de ejecución.
Un subconjunto de esa gran lista de requerimiento, se denomina lista de requerimiento

del ciclo, será una funcionabilidad y esto permite crear ciclos en la etapa de construcción
para aplicar un desarrollo incremental por medio de la herramienta para conseguir los
objetivos planteados. La planificación se enfoca en poner fechas de desarrollo y tiempo
de entrega estimada por parte del Equipo de desarrollo.
El líder de requerimientos es el único responsable de esta lista de requerimientos y

será el enlace entre los usuarios y el analista Gx (desarrollador) que forma parte del
equipo de desarrollo.
65
4.4 Fase de Construcción.
Reunión Diaria. Se aplica reuniones diarias de 15 minutos al equipo de desarrollo

para autoevaluarse. Cada miembro informa al equipo: lo que hizo ayer, lo que va hacer
hoy y que queda para el siguiente día, manifiesta los inconvenientes.
Esta fase aplica un desarrollo incremental con prototipos basado en el conocimiento de

los usuarios, generando varios ciclos, y cada ciclo se desarrolla con las historias de
usuarios que están en la lista de requerimientos del ciclo, según se crean de la lista de
requerimientos general, hasta conseguir ciclo a ciclo el “Producto Software” final.
En resumen, esta fase aplica un diseño, luego se crea un prototipo, y como siguiente
paso se Implementa, permitiendo retornar al diseño para realizar modificaciones(Artech
Consultores, 2012b).
Se define el ciclo de desarrollo como Ciclo-Gx, porque incorporamos la herramienta

Genexus y su filosofía se adopta del artículo Visión General Gx, publicado por Artech
Consultores(2012). El conocimiento del usuario es el aporte principal que permite
generar el ciclo de trabajo incremental con las siguientes etapas.
 Diseñar: Se describe el sistema a desarrollar mediante los objetos Genexus,

esta descripción se almacena en la Base de conocimiento que se genera con la
herramienta.
 Generar: A partir de la descripción realizada en la fase Diseñar la herramienta
genera prototipos automáticamente para realizar pruebas.
 Pruebas: Se dividen en dos:
Pruebas del código: por parte del analista gx se puede apoyar utilizando la
herramienta gx test y,
Pruebas de aceptación: Se realiza con los usuarios según la validación de las
historias de usuarios.
 Implementar: A partir de la creación del prototipo y realizadas las pruebas en

el paso anterior, se procede a desplegar en producción. El equipo y usuarios
realizan la implementación de los incrementos realizando pruebas de
integración.
4.4.1 Etapa Diseñar
En las tareas de diseño se presentan problemas presentes en toda comunicación
66
humana:
 El usuario desconoce detalles.

 Las explicaciones de los usuarios son mal interpretadas por el analista.
Para solucionar el problema de comunicación, esta etapa considera el trabajo conjunto

entre el analista Gx y el usuario. Consiste en identificar y describir los datos a utilizar
guiados por las historias de usuarios, el usuario da los detalles. Esto permite definir los
detalles del “Producto Software”.
Se busca la participación activa del usuario, define lo que quiere y participará en las
pruebas, la calidad la evalúa hasta conseguirla.
De acuerdo a lo analizado, GeneXus nos brinda varios objetos para describir las
historias de usuarios, entre otros tenemos los siguientes: Data Views, Reportes, Web
Panels, Transacciones, Procedimientos.
A partir de las descripciones de los objetos Genexus, automáticamente va construyendo

en forma incremental la Base de Conocimiento.
La Base de Conocimiento es un repositorio único de la información del diseño, esta

sirve para crear el modelo de datos físico como tablas, atributos, e índices, y los
programas de la aplicación.
La descripción de los objetos GeneXus permite realizar el análisis y diseño de los

métodos convencionales en un solo paso. La especificación de la descripción es
totalmente independiente del ambiente objeto donde se ejecutará la aplicación.
A continuación se describe el objeto transacción:
Transacciones. Permiten modelar la aplicación, se define los datos que utilizan las
historias de usuarios, es el punto de entrada de la base de conocimiento. Se crean los
programas que permiten ingresar, editar, o borrar información de la base de datos. Las
transacciones definen las pantallas que interactúan con el usuario y crea la base de
datos.
4.4.2 Etapa Generar
A partir de la descripción realizada en la fase Diseñar la herramienta genera prototipos

automáticamente para realizar pruebas. En estas pruebas participan los usuarios, se
validan las historias de usuarios definidas en la fase Apertura. Esta generación va
67
acompañada de las siguientes acciones automáticas:
o Creación de la base de datos.

o Creación del código Fuente en el lenguaje seleccionado.
o Interfaz de usuario.
o Servicios en servidor.
Pruebas. El usuario dispone de los programas necesarios para probarlos, según su

historia de usuario. El objetivo de esta etapa es que el prototipo sea semejante al
sistema que utilizará en producción el usuario. El ambiente de producción es donde se
ejecuta la aplicación, está dado por el sistema operativo, lenguaje y base de datos
utilizados.
Antes de pasar a la etapa de implementar (producción), se realizan las respectivas

pruebas del prototipo de la aplicación.
La generación es dependiente del lenguaje y la base de datos que se utilice. Es decir el

mismo modelo de la etapa diseñar puede ejecutarse para probar los prototipos y luego
que se ha probado el mismo modelo diseñado sirve como entrada a la etapa
implementar para que el usuario lo utilice en producción. Esto se consigue porque la
herramienta está diseñada para diferentes ambientes de plataformas de ejecución.
4.4.3 Etapa Implementar
Una vez probado el prototipo en la etapa anterior denominada Generar, se procede a

construir la aplicación en el ambiente de producción de manera sucesiva incremento por
incremento.
Con la herramienta GeneXus se genera automáticamente el código en el ambiente de

producción necesario para:
 Crear y mantener la base de datos por incrementos;

 Manejar los objetos que el usuario describe según los incrementos a través de
programas.
4.5 Fase de Entrega
Se considera que se llegó a esta fase cuando el equipo indica que alcanzó los objetivos
planteados en la fase de apertura, los miembros del equipo conocen que alcanzaron el
acuerdo por escrito de los requerimientos propuestos por el usuario, en su historia de
68
usuario, es decir el equipo cumplió con los requerimientos y está a satisfacción del
usuario.
Esta fase tiene dos actividades: Reunión Entrega final del “Producto Software” y una
reunión de reflexión.
4.5.1 Reunión Entrega final del “Producto Software”
Esta reunión se caracteriza con una revisión tipo demo donde el equipo junto a los
usuarios prueba el “Producto Software” construido Finalizado. Se hace la entrega de la
documentación de usuario.
4.5.2 Reunión de reflexión
Esta etapa consiste en una reunión del equipo de desarrollo sin los usuarios con el
objetivo de revisar el proceso y mejorarlo. Se base en el análisis de los obstáculos
durante todo el proceso, realizando una retroalimentación de los fallos, para aprender
de ellos y mejorar la metodología en sus próximas implementaciones.
Presentación de la documentación técnica del producto: Esquema generado de base de

datos y transacciones.
69
4.6 Evaluación
4.6.1 Presentación del caso de estudio: Experiencia real en

APASA
Para ejecutar la validación de la propuesta del método Magi-Gx, se propone un caso

experimental de desarrollo. Conseguir un ambiente de pruebas para este proceso
empírico, en un departamento de Sistemas de alguna empresa de la localidad utilizando
sus recursos humanos y equipos es algo no posible, ninguna empresa de los
alrededores de Milagro nos brinda facilidades para esta experimentación, es razonable
su respuesta por su información sensible y tema de seguridad.
Para conseguir un ambiente de experimentación real y poder lograr la validación del

método Magi-Gx, se realizó un acercamiento a la Asociación de Productores
Agropecuarios San Antonio, denominada APASA, se seleccionó estudiantes del último
semestre y graduados de la carrera de ingeniería de Sistemas de la Universidad Estatal
de Milagro, ubicada en la ciudad de Milagro.
La asociación APASA, nos permite construir una aplicación Web para el proceso de su
información, fue constituida legalmente en el año 2013, con número resolución SEPS-
ROEPS-2013-002484 supervisada por la Superintendencia de Economía Popular de
Ecuador. Se encuentra situada en la Parroquia Manuel J. Calle del cantón la Troncal,
en una hacienda enfocada en el sector agrario, las actividades que realiza la asociación
se centran en la producción de caña de azúcar. La Hacienda cuenta con 138ha, donde
cada socio posee cierta cantidad de hectáreas.
Formamos un equipo de desarrollo liderado por el Ing. Felipe Arévalo, con experiencia
en la herramienta Genexus, y un grupo de dos estudiantes del último semestre de la
carrera de ingeniería de Sistemas de la Universidad Estatal de Milagro, este grupo fue
capacitado en el uso de la herramienta Genexus y el método Magi-Gx.
Durante la ejecución del desarrollo se brindó todo el soporte al equipo de desarrollo en

la aplicación del método, dando la libertad de su aplicación. A continuación se detalla la
experiencia del caso en un ambiente experimental real de desarrollo.
4.6.2 Organización y capacitación del Equipo de desarrollo
La experiencia empieza con dos pasos previos importantes:
70
 Capacitación en el método y la herramienta Genexus

 Una reunión de auto-organización del equipo.
A los miembros del equipo de desarrollo se los capacitó en el proceso y los diferentes
roles del método propuesto, así también en el uso de la herramienta. Se realizó en cuatro
semanas. Las personas involucradas mostraron predisposición y entusiasmo por
colaborar, hay que considerar que no tienen experiencia en métodos agiles.
Mediante una reunión de auto-organización se estableció los lineamientos a seguir

para poner en práctica la metodología ágil con Genexus (Magi-Gx) para el desarrollo de
la aplicación Web.
Los miembros del equipo definieron los siguientes roles:
 Líder de Requerimiento: Usuario secretaria de la asociación

 Líder de Equipo: Una persona, Profesional de Sistemas.
 Equipo de Pruebas: Conformado por usuarios y miembros del Equipo de
desarrollo
 Analista Gx: Dos personas, estudiantes
 Equipo de Desarrollo. Compuesto por los roles anteriores
Los miembros del Equipo definieron la estimación de desarrollo en función a la dificultad

que presente los requerimientos. Para la estimación de dificultad establecieron:
6 puntos de historia = 1 semana.
Resuelven los miembros utilizar Gxserver para consolidar la aplicación Web

desarrollada. Los miembros del equipo tienen la libertad de desarrollar y probar en sus
equipos, luego consolidan.
En la herramienta Genexus crean la base de conocimiento que servirá como el

repositorio de todo el diseño para generar las bases de datos y programas tanto para
prototipos y producción, ver anexo III Genexus, creación de base de conocimiento y
ambiente prototipo.
Configuran en la herramienta dos ambientes separados, el ambiente para prototipos y

producción. El ambiente de prototipos se creó en el paso anterior, sirvió para desarrollar
las historias de usuario y realizar las pruebas. El ambiente de producción servirá para
ubicar la aplicación real que utilizará APASA, ver anexo III Genexus, creación ambiente
producción y visualización de los dos ambientes.
71
4.6.3 Fase de Apertura para el Proyecto
Reunión para definir el alcance de la Aplicación Web.
Día: 1
Duración: 8 horas.
El líder del producto junto con el líder del Equipo de desarrollo, lideraron esta reunión.
Se citó a los interesados: los usuarios que forman parte de la Asociación APASA y las
personas que forman el equipo desarrollo. El Objetivo de la reunión fue que todos los
interesados estén claros en el alcance del proyecto, que debe tener la aplicación Web y
que se descarta.
La guía utilizada para esta reunión es la siguiente:
¿Para qué se hace el proyecto?
En el transcurso de la reunión participaron los usuarios pidiendo diferentes

funcionalidades, hasta que se concretó en lo más relevante. Se definió que el objetivo
del proyecto de software es crear una aplicación Web que permita a los miembros de la
asociación agropecuaria cumplir sus objetivos de información, entre lo que se destaca:
control de cuotas ordinarias y extraordinarias, pago de cuotas de terrenos, multas
generadas por inasistencia a las reuniones convocadas y control de las distintas
actividades económicas de la asociación.
Se definió el impacto:
Presidente de la Asociación: conocer los movimientos y pagos por cada socio activo.
Tesorero: llevar un control de los pagos realizados por cada socio, y así poder emitir
los respectivos informes económicos de manera sistemática.
Secretaria: realizar la convocatoria a los socios activos para las asambleas ordinarias,
asambleas extraordinarias e ingresar los movimientos de cada socio.
Socios en General: Consultar sus pagos, deudas.
72
Que se va hacer para construir la aplicación Web para uso de la Asociación.
Una vez definido el Objetivo y el impacto, se explicó a los usuarios como definir la lista
de requerimientos generales mediante el mecanismo de historias de usuarios. Los
miembros del equipo se encargaron de ayudar a los usuarios, no de escribir las historias.
El formato general de historia aplicado fue el siguiente, Rol-necesidad- Beneficio:

Como (rol) quiero (algo) para (beneficiarme)
Después se explicó el criterio de aceptación de cada historia, que permita realizar un

plan de pruebas que muestre escenarios y evaluar la aceptación por parte del usuario.
Se pide que lo escriban al reverso de la tarjeta.
Las historias fueron debatidas, analizadas y aprobadas por los asistentes a la reunión.
El resultado final fue tener una lista de características generales, denominada lista de
requerimientos, mediante historias de usuarios, el líder de producto fue el responsable
de administrar esta lista.
La tabla 7, muestra la lista de historia de usuarios con su criterio de aceptación escrita

por los usuarios. A continuación se detalla cada columna utilizada:
La columna CODIGO.TÍTULO, permitió identificar la historia en el desarrollo del

proceso.
La columna DESCRIPCION DE HISTORIA, permitió detallar el requerimiento en el

formato utilizado.
La columna Pri nos indica la prioridad en función a la importancia que le dan los
usuarios, la mayor prioridad se identifica con el número 1, mientras mayor es el número
menor la importancia.
Cada historia definida por el usuario nos permitió entender en forma general la
aplicación y estimar su complejidad. Esto facilita la fase de Construcción ya que se tiene
lo que se desea y como se probará.
73
Tabla 7. Lista de historia de Usuarios

CODIGO.TÍTULO DESCRIPCIÓN DE HISTORIA Pri.
Cfg.Organización Como Presidente quiero configurar múltiple 1

organizaciones para dar el servicio a otras
organizaciones.
Criterio de validación:
Un Identificador obligatorio, permitirá crear las distintas
asociaciones
Cfg.Parámetros Como Presidente quiero activar múltiple asociaciones 2
para dar el servicio a otras agrupaciones.
Un Identificador obligatorio, permitirá activar las
distintas asociaciones.
Con.Consultar Como socio quiero poder consultar y descargar las 4
convocatorios o resoluciones de las reuniones para
Convocatoria
estar informado
Poder filtrar
Exportar a archivo pdf o excel
Con.Consultar Pago Como tesorero quiero consultar la información de los 4

pagos realizados por los socios para revisiones.
Poder filtrar
Con.Consultar Pagos Como socio quiero poder consultar los pagos realizados
por los distintos rubros que maneja la asociación.
4
Poder filtrar
Con.Consultar Como tesorero quiero consultar toda la información 4
respecto a las ventas de la caña que ha realizado la
Ventas
Asociación para emitir informes.
Con.Consultar Socio Cómo secretaria, quiero visualizar la información de 4
cada socio, para trámites varios.
Def.Bancos Como Presidente quiero definir los bancos para 1

registros de los movimientos.
Secuencial auto numérico
Descripción obligatorio
Def.Titulo Como Secretaria quiero definir los titulos para 1
asignarlos al ingreso de usuario.
Secuencial auto numérico. Descripción obligatoria
74
Def.ProductoSerivicio Como Presidente quiero definir los Productos para 3

organizar el trabajo.
Secuencial auto numérico.
Def.Institución Como Secretaria quiero definir las Instituciones para 1
organizar el trabajo.
Mov.Pagos Como secretaria quiero ingresar la información de los 3

pagos realizados por los socios para revisiones.
El año y la fecha las tomará por defecto desde el
servidor.
Mov.Ventas Como secretaria quiero ingresar la información 1
respecto a las ventas de la caña.
Tendrá un identificador secuencial auto numérico.
El año y la fecha las tomará por defecto desde el
servidor, no serán modificables.
Guardará automáticamente registros de usuarios que
ingresan, modifican y eliminan información.
Mov.Multas Como secretaria quiero ingresar multas por distintos 3
conceptos que sean aprobados por la directiva para
consultas posteriores.
Tendrá un ID secuencial auto numérico,
La fecha será obligatoria.
Guardará automáticamente registro de auditoria.
Mov.Convocatoria Como secretaria quiero ingresar la información de las 2
reuniones convocadas para llevar sus registros y
control.
Tendrá un ID secuencial auto numérico.

La fecha será obligatoria.
Debe permitir subir archivo en formato .pdf, y .doc
Def.Persona Como Presidente necesito registrar las Personas: 1
usuarios y socios del sistema para control y seguridad
de las transacciones
Es obligatorio ingresar el número de cédula, apellidos,
nombres, contraseña, correo, fecha de nacimiento.
Debe ser configurable para asignar perfil de opciones
en el sistema.
Cuando es socio pide la información complementaria.
75
Seg.Menu Como Presidente quiero poder asignarles un menú de 2

opciones basados en el perfil de usuario a los cuales
tiene permiso.
Debe ser configurable
Seg.Perfil de usuario Como Presidente necesito configurar perfiles de los 2

usuarios para definir autorización en cada módulo.
Tendrá un ID secuencial.
La descripción será obligatoria.
Se podrá definir una política de seguridad.
Asignación de las opciones a las cuales tendrá acceso
según el perfil
Seg.Politicas Como Presidente quiero definir políticas de seguridad 2

para controlar los accesos
Tendrá un ID obligatorio.
Permitirá ingresar la descripción de la política.
Se dispondrà de configuración de tres tipo: Sesiones
Web, Sesiones SmartDevices y configuración de
contraseñas: se podrá configurar tiempo de expiración,
permisos múltiples, caducidad de la contraseña,
dificultad de la misma, cantidad de caracteres.
(Elaboración Propia)
Reunión para planificar el desarrollo
Día: 2 Duración: 8 horas
Los participantes de esta reunión son: El equipo de desarrollo, el líder del equipo y el
líder de requerimientos. El líder de requerimientos presentó la lista de requerimientos en
Excel, procesadas de las historias de usuario desarrolladas en el paso anterior, y con
una estimación de prioridad. Los asistentes analizaron y agruparon los requerimientos
considerando su funcionabilidad y su prioridad, para crear los ciclos de desarrollo con
su respectiva lista de requerimientos del ciclo. La lista se encuentra abierta a cualquier
modificación planteada por el Líder de Requerimiento mientras no se encuentre en
proceso de desarrollo.
76
Lista de Requerimientos de Ciclos
Se tomó un subconjunto de la lista de requerimientos, que se formó de las Historia de

usuarios para organizarla. Ver la tabla 8 para los detalles. El equipo formado por todos
los interesados decidió la agrupación y analizó su prioridad con el líder de
requerimiento. Se agruparon por: Seguridad, Movimiento, Configuración y Gestionar. El
equipo de desarrollo estima la dificultad de cada historia y planificó la primera versión
de la aplicación para desarrollar el primer ciclo. Luego sigue con las siguientes historias
y se planifican todas las historias en diferentes ciclos de desarrollo, se les pone un
número para identificar el ciclo.
Tabla 8. Planificación de historias por Ciclo
Modulo/Historia/Prioridad
Seguridad Movimiento Configuración Gestionar
Seg.Perfil de usuario 2 Mov.Convocatoria 3 Cfg. 1 Def.Bancos 1
(puesto) (actividad) Organización
(corporativo)
Seg.Politicas 2 Mov.Pagos 3 Cfg. 2 Def.Persona 1
Parámetros (usuario)
Seg.Menu 2 Mov.Ventas 3 Def.Titulo 1

Mov.Multas 3 Def.Producto 3
Servicio
Def.Institución 1
(Elaboraciòn Propia)
Planificación del desarrollo por cada Ciclo
El equipo de desarrollo se reúne y trabaja sobre la lista de requerimientos agrupados

por importancia, tomando las historias de usuarios definidas y aclaradas en el paso
anterior, ver tabla 8. Procedió a realizar la estimación de dificultad y estima realizar 3
ciclos, cada ciclo en una semana.
Se consideró 6 puntos de historia = 1 semana. Esto definido en la etapa de

entrenamiento, ayuda a la estimación de dificultad. El equipo aplicó la
estimación de dificultad a cada historia de usuario, y considera desarrollar 3
ciclos para construir la aplicación ver tabla 9, 10 y 11.
77
Ciclo 1
Duración Estimada: Una semana
Tabla 9 Lista de requerimientos Ciclo 1

Historia Estimación
Dificultad
Def.Bancos 1
Def.Persona (usuario) 2
Def.Titulo 1
Def.Institución 1
Cfg.Organización 1
TOTAL ESTIMACION PARA HISTORIAS 6
Ciclo 2
Tabla 10. Lista de requerimientos Ciclo 2

Dificultad
Seg.Perfil de usuario 2
Seg.Politicas 1
Seg.Menu 1
Cfg.Parámetros 1
1
(Elaboración propia).
Ciclo 3
Tabla 11. Lista de requerimientos ciclo 3

Dificultad
Mov.Convocatoria 1
Mov.Pagos 1
Mov.Ventas 2
Mov.Multas 1
Def.ProductoServicio 1
78
4.6.4 Fases de Construcción.
Ciclo a desarrollar: Ciclo 1
Se realizaron reuniones diarias de 15 minutos todos los días, para autoevaluarse el

equipo de desarrollo, mientras avanza la construcción del primer entregable parte del
modulo configuración y Gestionar. Se desarrollan las Etapas: Diseñar y Generar
utilizando la herramienta Genexus.
Se realizó la reunión diaria de 15 minutos. Un miembro llegó tarde a la reunión pidió

disculpas y tomando este ejemplo se solicitó puntualidad. El equipo dialoga sobre la
lista de requerimiento del ciclo 1 y se pone de acuerdo en las tareas a realizar en
Genexus.
El equipo procede y se dividen las historias de usuarios, ver tabla 9, para crear las
transacciones en la herramienta Genexus, el equipo cuenta con el líder del producto
para definir detalles, en Anexo I Pantalla de construcción, se muestran ejemplos: la
descripción de las historias se implementó por medio de estructura de la transacción y
las validaciones de las historias por medio de las reglas.
Se realizó la reunión diaria de 15 minutos. El equipo revisa lo realizado el día anterior

dialoga sobre lo realizado y lo que se construirá este día.
Se crean prototipos para realizar pruebas con los usuarios, ver a Anexo II Pantallas de
prototipos. Evaluaron las consultas automáticas que se generan en las transacciones
con lo solicitado por ciertos usuarios, se prueban y las aprueban.
Día 5 y día 6 Duración 8 horas
Se realizó la reunión diaria de 15 minutos. El equipo revisa lo realizado el día anterior

dialoga sobre lo realizado y lo que se construirá este día, ver anexo II Pantallas de
prototipos. Se resuelve dejar las consultas automáticas que se generan en las
transacciones. Se trabajan las transacciones se prueban con los prototipos.
79
Día: 7 Duraciòn 8 horas
Se realizó la reunión diaria de 15 minutos. El equipo revisa lo realizado y esta listo para
la primera entrega el modulo configuración y Gestionar.
Duración: 3 horas
Se realiza la Implementación de los modulo en Producción de lo correspondiente

al ciclo 1. Con la herramienta GeneXus se generò automáticamente el código necesario
para crear la base de datos y generar los programas para manejar los objetos descritos
por el usuario. Ver anexo IV Pantallas de Producción, donde se ubica el menú de la
primera versión, Menu del ciclo 1 y las pantallas de este ciclo.
Finaliza el ciclo con la entrega a los usuarios mediante un demo donde se muestra todo
funcionando.
Duración: 3 horas
Terminada esta primera tarea, el equipo desarrollo se reúne para realizar la Reunión
de Reflexión, una vez finalizado el primer ciclo evaluaron todo el trabajo realizado y
comentan mejoras. Se debe mejorar la comunicación del equipo para ser más
descriptivos, el líder de producto no está disponible el 100% de tiempo lo que dificultad
aclarar ciertos detalles. Se conversó de los problemas con el ciclo 1 y soluciones dadas
y con esta experiencia se preparan para desarrollar en los días siguientes los ciclos 2
y 3.
Desarrollo del ciclo 2
Del Día 8 al día 12
Se toma la lista de requerimientos del ciclo 2, ver tabla 10, se analiza y se trabajan las
siguientes historias para el nuevo incremento a desarrollar y se repite el proceso
desarrollado en el ciclo 1 hasta alcanzar el siguiente entregable las opciones de
seguridad y la configuración de parámetros. Es decir se regresa a la Fase de
construcción, se generó los programas hasta entregarlos en Producción.
El equipo tiene un ritmo de trabajo más armonioso que el primer ciclo.
Desarrollo del ciclo 3
Del día 13 al día 17
80
Se regresa a la fase de Construcción y se desarrolló el ciclo 3, en base a lista de

requerimientos del ciclo ver tabla 11, este proceso tomó una semana más.
El equipo se divide las tareas y aplica el proceso de reuniones diarias de 15 minutos

para autoevaluarse. Tienen la participación del líder de requerimiento para los detalles,
realizan las pruebas generando los prototipos para alcanzar el nuevo incremento. Se
repite el proceso desarrollado en el ciclo 1.
El equipo hace la entrega del nuevo compromiso, implementa el ciclo 3 en producción y

dejó todo listo para la entrega final del proyecto completo, es decir la siguiente fase.
4.6.5 Fase de Entrega
Día: 18 Duración 3 horas
4.6.6 Reunión Entrega final del “Producto Software”
El equipo muestra a los usuarios la construcción de la aplicación Web APASA,

realizando un demo de lo desarrollado con la participación activa de los usuarios. Los
usuarios están de acuerdo con lo desarrollado y se hace la entrega formal. Esto dura
120 minutos. Ver Anexo IV Pantallas de Producción.
4.6.7 Reunión de reflexión Final
Día: 18 Duración 2 horas
Terminada la entrega Final del proyecto, se reunió el equipo de desarrollo sin los
usuarios con el objetivo de revisar el proceso desarrollado y realizar comentarios para
mejorarlo. Se destaca la velocidad del desarrollo utilizando el método Magi-Gx al
compararlo con los proyectos desarrollados con método tradicional. Los estudiantes
que formaron parte del equipo resaltan como Genexus hace trasparente el desarrollo
Web desde un solo punto de diseño, comparándolo con lo tradicional de programar en
el cliente en ciertos lenguajes y en el servidor utilizar otros.
Las limitaciones presentadas fueron los momentos que no contaron con el líder del
producto por sus ocupaciones dentro de la asociación. Valoran la documentación
técnica que genera Genexus en su repositorio, pero mencionan que los analista Gx que
participaban no seguían las reglas de nomenclaturas en los atributos lo que dificultaba
la integración. Se muestra en el anexo IV Configuración Genexus y documentación
Genexus, listado de tablas en modelo Entidad Relación generado por la herramienta.
81
5. Conclusiones y trabajo futuro
5.1 Conclusiones
Este trabajo de fin de master, aporta para solucionar el problema de la no utilización de

metodologías por parte de los profesionales del software, con un método de desarrollo
ágil de software, basado en las mejores prácticas de las metodologías agiles. Se utilizó
la herramienta Case Genexus que enfoca la filosofía de los conceptos agiles para
automatizar las tareas rutinarias de desarrollo como son la programación,
documentación técnica y creación de base de datos. Esta automatización de tareas
redujo el tiempo del proyecto y le incorpora calidad y seguridad al producto software.
Se examinó las mejores prácticas utilizadas en las principales Metodologías Agiles, que
aportan al desarrollo de software en las organizaciones a nivel mundial como son:
Scrum, Kanban y Programación Extrema, para construir el método propuesto en este
trabajo denominado, “Método Ágil con Genexus” (Magi-Gx).
Se Validó la propuesta mediante un caso de estudio aplicado en un ambiente de

organización agropecuaria. Se construyó una aplicación Web para el sector
agropecuario, basado en los requerimientos de la asociación de productores
agropecuarios San Antonio (APASA), que se encuentra situada en la Parroquia Manuel
J. Calle del cantón la Troncal provincia del Cañar.
Este método ágil, Magi-Gx, en base a la experimentación realizada nos permitió

observar cómo se implementa y se concluye el siguiente logro:
Reducir tiempo de desarrollo, porque la aplicación se describe no se programa, existe

generación automática de base de datos y programas partiendo de la descripción
almacenada en la base de conocimiento de Genexus.
Alta participación del usuario en el proceso, garantizando la calidad en los resultados.

El método no elimina la documentación, la fomentó en línea por medio de Genexus en
todos los integrantes del equipo de desarrollo, porque se basa en las descripciones que
están almacenadas en la base de conocimiento y pueden ser consultadas en cualquier
momento, además hay varios reportes como la base de datos en tercera forma normal
para análisis si es necesario.
82
5.2 Líneas de trabajo futuro
Se plantean las siguientes propuestas como mejoras al método desarrollado en este

trabajo:
 Realizar un trabajo más amplio con la metodología desarrollada por ejemplo:
profundizar a nivel Ecuador sobre las tendencias de uso de metodologías para
realizar experimentos y sacar mejores conclusiones.
 Proponer Incorporar en la Universidad estatal de Milagro-Ecuador la utilización

del método como un proyecto integrador en los últimos niveles y compararlo con
otros métodos.
El método desarrollado puede aplicarse a cualquier proyecto donde se requiera

desarrollo de manejo de datos como aplicaciones en ambientes web, móviles y
ambientes de mainframe como As/400, con el objetivo de producir información.
Se puede profundizar en añadirle un método de pruebas con herramientas

automatizadas.
83
6. Bibliografía
Agile Alliance. (2001a). Manifiesto por el Desarrollo Ágil de Software. Recuperado 6 de

septiembre de 2018, de http://agilemanifesto.org/iso/es/manifesto.html
Agile Alliance. (2001b). Principios del Manifiesto Ágil. Recuperado 17 de julio de 2018,
de http://agilemanifesto.org/iso/es/principles.html
Aguilar, J. (2010). Velneo v7: Desarrollo de aplicaciones empresariales. Recuperado 10

de agosto de 2018, de https://www.variablenotfound.com/2010/11/velneo-v7-
desarrollo-de-aplicaciones.html
Anderson, D. J., & Carmichael, A. (2016). Essential Kanban condensed (Kanban

Esencial Condensado). (Lean Kanban University, Ed.). Washington:
leankanban.com. Recuperado de https://leankanban.com/wp-
content/uploads/2017/11/EssentialKanbanSpanishEversion.pdf
Artech Consultores. (2012a). GeneXus y el ciclo de vida de las aplicaciones.
Artech Consultores. (2012b). Visión General de GeneXus.
Bachmann, A. (2012). Seguridad en aplicaciones con conectividad. Recuperado 27 de

julio de 2018, de https://www.genexus.com/es/global/noticias/leer-
noticia/seguridad-en-aplicaciones-con-conectividad
Bahit, E. (2011). Desarrollo Ágil con Kanban. Recuperado 23 de agosto de 2018, de

https://desarrolloweb.com/articulos/desarrollo-agil-kanban.html
Beck, K., & Andres, C. (2004). Extreme Programming Explained:Embrace Change.

(Addison-Wesley, Ed.) (Second). Massachusetts.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., & Fowler, M.
(2001). Manifiesto por el Desarrollo Ágil de Software. Recuperado 2 de julio de
2018, de http://agilemanifesto.org/iso/es/manifesto.html
Canedo, G. (2017). GeneXus: aplicaciones seguras de forma eficiente - Opinión |

Prensario TI Latin America. Recuperado 27 de julio de 2018, de
http://www.prensariotila.com/19441-GeneXus-aplicaciones-seguras-de-forma-
eficiente.note.aspx
Canos, J., Letelier, P., & Penadés, M. C. (2003). Metodologías Ágiles en el Desarrollo
de Software. Recuperado de
84
https://ldc.usb.ve/~abianc/materias/ci4713/actasMetAgiles.pdf
Chikofsky, E. J., & Rubenstein, B. L. (1988). CASE: reliability engineering for information
systems. IEEE Software, 5(2), 11-16. https://doi.org/10.1109/52.2005
Cockburn, A. (2007). Agile software development : the cooperative game. (Pearson, Ed.)
(Second). Boston: Addison-Wesley.
CollabNet VersionOne. (2018). VersionOne 12th Annual State of Agile Report.

Recuperado 29 de mayo de 2018, de https://explore.versionone.com/state-of-
agile/versionone-12th-annual-state-of-agile-report
Cunningham, W. (2001). Principles behind the Agile Manifesto. Recuperado 2 de julio

de 2018, de http://agilemanifesto.org/principles.html
Figuerola, N. (2011). kanban. Recuperado de
https://articulosit.files.wordpress.com/2011/11/kanban.pdf
Fowler, M. (2005). La nueva metodología. Recuperado 28 de junio de 2018, de

https://martinfowler.com/articles/newMethodology.html
Funcionamiento - Metodología XP. (s. f.). Recuperado 29 de agosto de 2018, de

https://sites.google.com/site/xpmetodologia/marco-teorico/funcionamiento
Genexus.com. (2018). Supported technologies. Recuperado 9 de agosto de 2018, de

https://www.genexus.com/en/global/products/genexus/supported-technologies
GeneXus training. (2017a). Introducción Teórica Genexus. Recuperado de

https://training.genexus.com/genexus/materiales-curso-genexus-15?es
GeneXus training. (2017b). Que es GeneXus? Recuperado de

https://training.genexus.com/genexus/materiales-curso-genexus-15?es
GeneXus training. (2017c). Seguridad con GeneXus Access Manager. Recuperado 27

de julio de 2018, de https://training.genexus.com/files/introduccion-a-gam-pdf?es
Gonda, B., & Jodal, N. (2007). Desarrollo Basado en Conocimiento Filosofía y

Fundamentos Teóricos de Genexus. Artech, 1-17.
Herrera Uribe, E., & Valencia Ayala, L. E. (2007). Del manifiesto ágil sus valores y
principios. Scientia Et Technica, XIII(34). Recuperado de
http://www.redalyc.org/html/849/84934064/
85
Highsmith, J. (2001). History: The Agile Manifesto. Recuperado 2 de julio de 2018, de

http://agilemanifesto.org/history.html
Kendall, K., & Kendall, J. (2005). ANÁLISIS Y DISEÑO DE SISTEMAS. (Pearson, Ed.)
(Sexta). Mèxico. Recuperado de
https://luiscastellanos.files.wordpress.com/2014/02/analisis-y-disenio-de-sistemas-
kendall-kendall.pdf
Kniberg, H. (2007). Una historia de guerra Ágil Scrum y XP desde las trincheras. (InfoQ,
Ed.). C4Media. Recuperado de http://infoq.com/minibooks/scrum-xp-
fromthetrenches
Lawrence Shari. (2002). Ingenieria Del Software. Pearson Education S.A. Recuperado
de
http://ebookbit.com/book?k=Ingenieria+Del+Software&lang=es&isbn=9789879460
719&source=sites.google.com
León, R., Eberth, T., & Marco, Y. (2003). Criterios de selección de metodologías de
desarrollo de software. Industrial Data, 6(2), 82-87. Recuperado de
Leonardo De Seta. (2008). Cómo usar Kanban en el desarrollo de software. Recuperado

23 de agosto de 2018, de https://dosideas.com/noticias/metodologias/184-como-
usar-kanban-en-el-desarrollo-de-software
Lomprey, G., & Hernandez, S. (2008). LA IMPORTANCIA DE LA CALIDAD EN EL

DESARROLLO DE PRODUCTOS DE SOFTWARE. México. Recuperado de
http://fit.um.edu.mx/CI3/publicaciones/Technical Report COMP-018-2008.pdf
Márquez Daniel, F. C. (2009). Guía práctica GeneXus. Desarrollo basado en

conocimiento. (Segunda). Montevideo: Grupo Magro.
Melo, C., Katayama, E., Prikladnicki, R., Goldman, A., Melo, C. D. O., Santos, V., …
Kon, F. (2013). The evolution of agile software development in Brazil HELENA
SURVEY-Hybrid dEveLopmENt Approaches in software systems development
View project InterSCity-Enabling the Future Internet for Smart Cities View project
The Evolution of Agile Software Development in Brazil Education, Research, and
the State-of-the-Practice. Article in Journal of the Brazilian Computer Society.
https://doi.org/10.1007/s13173-013-0114-x
MendesCalo, K., Estevez, E., & Fillottrani, P. (2009). Un Framework para Evaluación de
Metodologías Ágiles. Recuperado 3 de julio de 2018, de
86
https://www.researchgate.net/publication/242584795_Un_Framework_para_Evalu
acion_de_Metodologias_Agiles
Monte, J. L. (2016). Implantar scrum con éxito. Barcelona: UOC. Recuperado de

https://ebookcentral.proquest.com/lib/unemisp/reader.action?docID=4795177&pp
g=1&query=scrum
Navarro Cadavid, A., Fernández Martínez, J. aniel, & Morales Vélez, J. (2013). Revisión
de metodologías ágiles para el desarrollo de software A review of agile
methodologies for software development. Recuperado de
http://www.redalyc.org/pdf/4962/496250736004.pdf
Palacios, J. (2017). Essential Scrum Guide. Recuperado 20 de agosto de 2018, de

https://jeronimopalacios.com/scrum/
Poole, D. (2009). Do It Yourself Agile: Do It Yourself Agile. Recuperado 2 de julio de

2018, de http://damonpoole.blogspot.com/2008/01/zero-to-hyper-agile-in-90-days-
or-less.html
Pressman, R. (2010). Ingeniería del software. Un enfoque práctico (septima). Mèxico:

McGram-Hill.
Robles, G., & Carlos, J. (2014). Programación eXtrema y Software Libre.

researchgate.net. Recuperado de
https://www.researchgate.net/publication/228593903_Programacion_eXtrema_y_
Software_Libre
Rodriguez, C. (2015). Metodologías Ágiles - XP - Scrum - Kanban. Recuperado 4 de

agosto de 2018, de
https://comunidad.iebschool.com/metodologiasagiles/general/concepto-
metodologias-agiles/
Royce, W. (1970). Managing The Development of Large Software Systems. Recuperado

de http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
Rua, C. (2017). (16) Kanban - Metodologías Ágiles - YouTube. Recuperado de

https://www.youtube.com/watch?v=DkeZYBRVfUQ
Saiz Jorge. (2017). Esquema-de-un-proyecto-Scrum(Figura). Recuperado 19 de agosto

de 2018, de https://jorgesaiz.com/wp-content/uploads/2017/02/141-Esquema-de-
un-proyecto-Scrum.jpg
87
Schwaber, K., & Sutherland, J. (2017). La Guía Definitiva de Scrum: Las Reglas del
Juego Español. Recuperado de
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-
Spanish-SouthAmerican.pdf
Sommervjlle, I. (2005). Ingeniería del software. (Pearson, Ed.) (Séptima edición).

Madrid.
Standish Group. (2014). The CHAOS report.
Sutherland, J. (2015). Scrum : el nuevo y revolucionario modelo organizativo que

cambiará tu vida(V. E. Gordo del Rey,Trad.). Barcelona: Planeta(Obra original
2014).
Sutherland, J., & Schwaber, K. (2011). The Scrum Papers: Nut, Bolts, and Origins of an
Agile Framework. Recuperado de http://34slpa7u66f159hfp1fhl9aur1-
wpengine.netdna-ssl.com/scrumpapers.pdf
Valencia Ayala, L. E. (1995). ScientiValencia Ayala, L. E. (1995). Scientia et technica.

Scientia Et Technica (Vol. XIII). Universidad Tecnológica de Pereira. Recuperado
a partir de http://www.redalyc.org/html/849/84934064/a et technica. Scientia Et
Technica (Vol. XIII). Universidad Tecnológica de Pereira. Recuperado de
velneo. (2016). Cinco fases claves en el desarrollo de software | Velneo. Recuperado

11 de agosto de 2018, de https://velneo.es/cinco-fases-claves-en-el-desarrollo-de-
software/
velneo. (2018a). ¿Qué es Velneo? Recuperado 10 de agosto de 2018, de

https://velneo.es/info/
velneo. (2018b). 5 formas de enseñar la metodología ágil a tu equipo de desarrollo |

Velneo. Recuperado 11 de agosto de 2018, de https://velneo.es/5-formas-ensenar-
la-metodologia-agil-equipo-desarrollo/
velneo. (2018c). Desarrollo de aplicaciones multiplataforma | Velneo. Recuperado 11 de

agosto de 2018, de https://velneo.es/desarrollo-aplicaciones-multiplataforma/
Verástegui, D. F. (2010). Especificación de metodología AGIL para desarrollo de

software, apoyada en la herramienta CASE GENEXUS. Recuperado de
http://cybertesis.uni.edu.pe/handle/uni/3228
88
Vinueza, M. (2012). Análisis de la aplicación de los modelos de calidad de software.

Ciencia Unemi, 5(8), 93-101. https://doi.org/10.29076/issn.2528-
7737vol5iss8.2012pp93-101p
Zavala Ruiz, J. (2004). ¿Por Qué Fracasan los Proyectos de Software? Un Enfoque
Organizacional February 2004. En Congreso. Mexico.
https://doi.org/10.13140/RG.2.1.4741.3206
Zelkowitz, M. V., Shaw, A. C., & Gannon, J. D. (1979). Principles of software engineering
and design. Prentice-Hall. Recuperado de
https://dl.acm.org/citation.cfm?id=578504&preflayout=flat
89
7. Anexos
7.1 Anexo I. Pantallas de Construcción, Etapa Diseñar
Tabla Ilustraciones
Desarrollo 1. Transacción Usuario ................................................................................... 91
Desarrollo 2. Reglas en Transacción Usuario ..................................................................... 92
Desarrollo 3. Transacción Perfil de usuario ....................................................................... 92
Desarrollo 4. Reglas en Transacción Perfil usuario ............................................................. 93
Desarrollo 5. Transacción Política de Seguridad ................................................................ 93
Desarrollo 6. Reglas en Transacción de Política de Seguridad .............................................. 94
Desarrollo 7. Transacción Organizaciònl ........................................................................... 95
Desarrollo 8. Reglas en Transacción Organizaciòn ............................................................. 95
Desarrollo 9. Transacción Banco...................................................................................... 96
Desarrollo 10. Reglas en Transacción Banco ..................................................................... 96
Desarrollo 11. Transacción Institución .............................................................................. 97
Desarrollo 12. Reglas en Transacción Institución ............................................................... 97
Desarrollo 13. Reglas en Transacción Título y/o Profesión .................................................. 98
Desarrollo 14. Reglas en Transacción Actividad ................................................................. 98
Desarrollo 15. Transacción Venta .................................................................................... 99
Desarrollo 16. Transacción Multa .................................................................................... 99
Desarrollo 17. Transacción Pago ................................................................................... 100
90
Desarrollo 1. Transacción Usuario
91
Desarrollo 2. Reglas en Transacción Usuario
Desarrollo 3. Transacción Perfil de usuario
92
Desarrollo 4. Reglas en Transacción Perfil usuario
Desarrollo 5. Transacción Política de Seguridad
93
Desarrollo 6. Reglas en Transacción de Política de Seguridad
94
Desarrollo 7. Transacción Organización
Desarrollo 8. Reglas en Transacción Organización
95
Desarrollo 9. Transacción Banco
Desarrollo 10. Reglas en Transacción Banco
96
Desarrollo 11. Transacción Institución
Desarrollo 12. Reglas en Transacción Institución
97
Desarrollo 13. Reglas en Transacción Título y/o Profesión
Desarrollo 14. Reglas en Transacción Actividad
98
Desarrollo 15. Transacción Venta
Desarrollo 16. Transacción Multa
99
Desarrollo 17. Transacción Pago
100
7.2 Anexo II. Pantallas de Prototipos
Tabla Ilustraciones
Prototipo 1. Inicio de Sesión ..................................................................................... 102
Prototipo 2. Página de Inicio ..................................................................................... 102
Prototipo 3. Persona del Sistema .............................................................................. 103
Prototipo 4. Ingreso de Usuario ................................................................................ 103
Prototipo 5. Puesto o Rol .......................................................................................... 104
Prototipo 6. Ingreso de Puesto o Rol ........................................................................ 104
Prototipo 7. Ingreso del Perfil del Puesto o Rol ......................................................... 105
Prototipo 8. Política de Seguridad ............................................................................. 105
Prototipo 9. Configuración de Política de Seguridad ................................................. 106
Prototipo 10. Organizaciones agricolas ..................................................................... 106
Prototipo 11. Ingreso de asociaciones ..................................................................... 107
Prototipo 12. Cargo ................................................................................................... 107
Prototipo 13. Ingreso de Cargo ................................................................................. 108
Prototipo 14. Banco .................................................................................................. 108
Prototipo 15. Institución ............................................................................................ 109
101
Inicio de Sesión
Esta pantalla solicita la información del usuario: el nombre de usuario y la contraseña.
Prototipo 1. Inicio de Sesión
Página de inicio
La página home, mostrará el menú con el perfil de usuario asignado por parte del
administrador del sistema.
Prototipo 2. Página de Inicio
102
Opción Persona
En esta opción se crea el usuario del sistema con toda la información general,
información solicitada en los requerimientos, perfil de usuario y configuración del
sistema.
Prototipo 3. Persona del Sistema
Prototipo 4. Ingreso de Usuario
103
Puesto o Rol
Permite ingresar información del perfil de usuario, asignar la política de seguridad y

asignar las opciones del menú a las cuales tendrá acceso
Prototipo 5. Puesto o Rol
Prototipo 6. Ingreso de Puesto o Rol
104
Luego de ingresada la información, tenemos la opción de agregar el perfil de puesto

asignando el permiso a la opción correspondiente.
Prototipo 7. Ingreso del Perfil del Puesto o Rol
Políticas de Seguridad
Las mismas permiten configurar opciones significativas de seguridad en los distintos

ambientes
Prototipo 8. Política de Seguridad
105
Prototipo 9. Configuración de Política de Seguridad
Organización
En esta opción permite crear varias asociaciones con sus datos generales
Prototipo 10. Organizaciones agrícolas
106
Prototipo 11. Ingreso de asociaciones
Cargo
Ingresamos la descripción de los cargos dentro de la asociación
Prototipo 12. Cargo
107
Prototipo 13. Ingreso de Cargo
Banco
Ingresamos la descripción de los bancos
Prototipo 14. Banco
108
Institución
Ingreso de instituciones educativas para asignarle a la hoja de vida de los distintos

usuarios del sistema
Prototipo 15. Institución
109
7.3 Anexo III. Configuración Genexus y Documentación
Creación de base de conocimiento en Genexus
Se configura el nombre de la misma, la ruta donde se almacenará, se selecciona el

lenguaje de programación la misma que creará el ambiente prototipo, cabe indicar que
los datos de configuración de la base de conocimiento que se almacena en una base de
datos SQL Express Edition.
Genexus 1. Creación de Base de Conocimiento y ambiente prototipo
110
Genexus 2. Creación ambiente producción
111
Genexus 3. Visualización de los ambientes de prototipo y producción
112
Diagrama entidad relación generado por la herramienta Genexus
Genexus 4. Diagrama Entidad Relación
113
7.4 Anexo IV. Pantallas de Producción
Se detalla Ejemplos de los programas en Producciòn
Menú de Ciclo 1 .......................................................................................................... 115
Producción 2 Menu final............................................................................................... 116
Producción 3. Consulta Bancos ...................................................................................... 116
Producción 4. Ingreso de Bancos ................................................................................... 117
Producción 5. Consulta Título ........................................................................................ 117
Producción 6. Ingreso de Títulos .................................................................................... 118
Producción 7. Consulta Personas ................................................................................... 118
Producción 8. Ingreso de Personas................................................................................. 119
Producción 9. Consulta Producto / Servicio ..................................................................... 119
Producción 10. Ingresa Producto / Servicio ..................................................................... 120
Producción 11. Consulta Institución ............................................................................... 120
Producción 12. Ingresa Institución ................................................................................. 121
114
Producción 16. Menú de Ciclo 1
115
Producción 17 Menú final
Producción 18. Consulta Bancos
116
Producción 19. Ingreso de Bancos
Producción 20. Consulta Título
117
Producción 21. Ingreso de Títulos
Producción 22. Consulta Personas
118
Producción 23. Ingreso de Personas
Producción 24. Consulta Producto / Servicio
119
Producción 25. Ingresa Producto / Servicio
Producción 26. Consulta Institución
120
Producción 27. Ingresa Institución
121
7.5 Anexo V. Artículo
Método ágil en el desarrollo de software

aplicando la herramienta Genexus
Ricauter López-Bermúdez
Resumen. — El trabajo de fin de master un producto de software que posea calidad
propone un método de desarrollo de y seguridad, para satisfacer todos los
software apoyado en las mejores prácticas requerimientos del usuario para alcanzar los
de Metodologías Agiles, utilizando la objetivos de la organización.
herramienta Case Genexus, se crea una
aplicación Web que permita validar la II. CONTEXTO Y ESTADO DEL ARTE
propuesta en una organización
agropecuaria. Ingeniería de software. - Es el estudio de
La propuesta del método toma como las partes y métodos para la elaboración y
referencia el análisis de las mejores mantenimiento de sistemas de software
prácticas de las metodologías agiles como (Zelckowitz,Shaw, & Gannon. 1979. La
Scrum, Xp y Kanban. Se aplica un desarrollo metodología da las técnicas para hacer
basado en conocimiento, incremental y aplicaciones que puedan desarrollar tareas
aplicando la técnica de prototipos. como: comunicación, análisis de los
requerimientos, modelación del diseño,
El método define roles para las personas construcción del programa, pruebas y
que forman parte del equipo y ejecutan los apoyo.
pasos del método propuesto. Se definen
elementos que constituyen resultados de las Enfoques de desarrollo de software en
actividades. Se definen actividades que las diferentes Metodologías. – Pressman
permiten poner en acción el método entre (2010) nos propone que todos los modelos
las personas que forman el equipo de para desarrollar software pueden incluir las
trabajo, estas actividades son reuniones actividades estructurales generales como
definidas. son: la comunicación, la planeación, el
modelado, la construcción y el despliegue,
El trabajo aporta para solucionar el pero cada modelo pone distinto énfasis en
problema de la no utilización de ellas y define en forma diferente el flujo de
metodologías por parte de los profesionales proceso que invoca cada actividad
del software, con un método de desarrollo estructural y sus enfoques son: modelo
ágil de software. Se utilizó la herramienta cascada, modelo prototipo, modelo
Case Genexus que enfoca la filosofía de los incremental, modelo espiral
conceptos agiles para automatizar las
tareas rutinarias de desarrollo como son la Metodologías ágiles. - En la época actual
programación, documentación técnica y se conoce una nueva metodología con el
creación de base de datos. Esta nombre de “métodos ágiles”. (Fowler, 2005)
automatización de tareas redujo el tiempo los cuales crean intereses en las industrias
del proyecto y le incorpora calidad y y son exaltadas en ambientes académicos y
seguridad al producto final, el software. de investigación”. Se origina como una
alternativa a metodologías tradicionales
I. INTRODUCCIÓN para mejorar la calidad del software.
El desarrollo del software ha cambiado con
las nuevas técnicas que se van Metodologías ágiles más usadas. -
desarrollando. según encuestas en el 2018 las
metodologías más usadas son: Scrum,
El uso adecuado de las metodologías de
Kanban, Programación extrema.
desarrollo permitirá optimizar recursos y
tiempo a las empresas y sobre todo proveer
122
Herramientas de Desarrollo. – GeneXus Examinar las mejores prácticas utilizadas

es una herramienta diseñada para el en las principales Metodologías Agiles que
desarrollo de aplicaciones informáticas en aportan al desarrollo de software en las
dispositivos móviles, Web, Windows y organizaciones.
plataformas heredadas, basada en la Determinar las características y
obtención del conocimiento general de la funcionalidades de la herramienta Genexus
como una herramienta ágil en el desarrollo
empresa partiendo de las visiones de los
de software en las organizaciones.
usuarios involucrados, llamado “realidad”,
Validar la propuesta mediante un caso de
de tal manera que nos permite un desarrollo estudio aplicado en un ambiente de
ágil y flexible por medio de una base de organización agropecuaria de la ciudad de
conocimiento, cumpliendo así el objetivo Milagro- Ecuador.
principal de GeneXus que es la
implementación en el menor tiempo posible C. Metodología
y con la mayor calidad posible(GeneXus La metodología a seguir en el desarrollo
training, 2017), Entre las características que del método propuesto está basada en el
ofrece la herramienta podemos encontrar estudio analítico de la aplicación de los
las siguientes(Artech Consultores, 2012): el modelos de prototipos y modelo incremental
diseño, creación y mantenimiento de la base con el apoyo de una herramienta que utilice
estos modelos y además considere el
de datos son totalmente automáticos,
desarrollo basado en conocimiento,
independencia de plataforma, lenguajes y
enfocando los principios de las
arquitectura.(Gonda & Jodal, 2007) entre metodologías ágiles, con el objetivo de
otros. construir un modelo de desarrollo de
software.
Velneo V7 es una plataforma completa
de desarrollo de aplicaciones empresariales
y está diseñada para hacer más rentable el IV. DESARROLLO DE LA PROPUESTA
desarrollo, implantación y mantenimiento de DE METODOLOGÍA
aplicaciones empresariales gracias a su Identificación de requisitos. - El método
base de datos integrada y una programación propuesto para desarrollo de software está
visual (velneo, 2018). Aguilar (2010) en su basado en la aplicación de prototipos y son
análisis de la plataforma, nos describe el desarrollo de prototipos el cual consisten
elementos necesarios para crear y ejecutar en generación automática de programas
aplicaciones entre los cuales están: un para desarrollar un incremento (parte del
componente cliente, llamado vClient, una producto total) para ser evaluados y
especie navegador o runtime necesario construido con los usuarios, el desarrollo
para ejecutar las aplicaciones, un incremental con Interacciones y el desarrollo
componente servidor, vServer, que actúa basado en conocimiento constituido por la
como servidor de aplicaciones, datos y otras base de datos y lenguajes de programación.
tareas centralizadas, un componente de
administración, vAdmin, que permite Roles. - Con el objetivo de construir un
gestionar aplicaciones, usuarios, permisos y modelo de desarrollo de software
otros aspectos de un vServer, una identificamos los roles necesarios:
herramienta de desarrollo, vDevelop, desde
 Líder de Requerimiento. Es la persona
el que se crean las estructuras de datos y
que representa a los usuarios y su
aplicaciones para la plataforma.
actividad principal es definir un banco
III. OBJETIVOS CONCRETOS Y de requerimientos que debe cumplir el
METODOLOGÍA DE TRABAJO Producto
A. Objetivo General  Líder de Equipo. Organiza las
Proponer un método de desarrollo de reuniones, se encarga que los
software apoyado en las mejores prácticas miembros del equipo tengan las
de Metodologías Agiles utilizando la herramientas necesarias para
herramienta Genexus para la creación de desarrollar sus actividades.
una aplicación Web, que permita obtener
 Equipo de Pruebas. Son usuarios y
información en un ambiente de organización
miembros del Equipo de desarrollo
agropecuaria cumpliendo sus
requerimientos principales.
B. Objetivo Especifico
123
 Analista Gx. Es el profesional Descripción de la Metodología

informático con conocimiento en la propuesta. - “Metodología Ágil con
herramienta Genexus. GeneXus”, lo referenciamos en el resto del
 Equipo de Desarrollo. Formado por documento como Magic-GX. La figura 31
Analistas Gx, líder de Requerimientos nos ilustra el proceso completo hasta llegar
y Equipo de pruebas. a construir el producto final de software.
Elementos. - Los elementos necesarios
Fases y Actividades. El Método Magic-GX
que permiten construir el método son:
se compone de:
 Ciclo. Tiempo promedio dos semanas.
Fase Descripción
 Historia de usuarios. Son los
Fase de Apertura Definición de
requisitos, visión o deseos del usuario, Requerimientos y
son redactados por el mismo. Alcance
 Lista de requerimientos. Es el conjunto Fase de Se describe, genera
total de historia de usuarios en Construcción y prueba el Producto
bloques denominados ciclos. Fase de Entrega Entrega del
 Lista de requerimientos del ciclo. Es Producto Final
una porción de la lista de
requerimiento aplicando prototipos,
desarrollo incremental y basado en Fase de Apertura Se elabora la Lista de
requerimientos que definen el producto
conocimiento.
Software. - Busca definir el alcance del
 Base de conocimiento. Contiene la proyecto, sus objetivos y planificación. Se
lista de requerimientos que expresa la define en base a dos reuniones que se
visión de los usuarios, permite la detalla a continuación
generación automática de programas y
base de datos. Objetivo de
Reunión Participantes
reunión
 Prototipo. Es el incremento como
Todos
resultado de aplicar la lista de Definir el Alcance y
(Usuarios y
requerimiento del ciclo Producto características
Equipo)
Actividades y reuniones. - Las Planificar
actividades necesarias permiten el trabajo Organizar los Equipo y
el
en equipo, realizar controles y tomar requerimientos Lideres
Producto
medidas correctivas, estas son las
Reunión para definir el Producto. - Se
siguientes:
cita a las personas que tienen poder de
 Reunión Definir Producto. Se define el decisión sobre los requisitos para el
desarrollo del Producto y las personas que
alcance del proyecto por medio de
desarrollarán el Producto. La guía para esta
“historias de usuarios” a los usuarios.
reunión considera lo siguiente:
 Reunión Planificar Producto. En base
a las historias de usuarios se  ¿Para qué se hace el Producto?
construye la lista de requerimientos,  Definir a que personas impactará el
Producto.
 Reunión Diaria. Es una reunión de 15
 Que se va hacer para construir el
minutos que realiza el equipo de Producto.
desarrollo para autoevaluarse. Historia de Usuario. - La historia de
 Reunión de Reflexión. Se realiza al usuario se redacta en tarjetas y esta
final de cada ciclo para evaluar y redacción responde a estas preguntas
aplicar mejora continua al proceso. relacionadas con sus necesidades.
 Reunión entrega Final. se realizan un
PREGUNTA DESCRIPCION
demo
¿Quién se Actor, rol que
 Identificación del Problema a resolver.
Se desarrolla con el apoyo de un
beneficia? desempeña el usuario
equipo de Ingenieros y estudiantes del ¿Qué se quiere Narrar la necesidad,
último semestre de la carrera de hacer? ese algo
ingeniería de Sistemas de la ¿Cuál es el Por Qué le da valor al
Universidad Estatal de Milagro- beneficio? negocio
Ecuador.
124
Evaluar La Calidad de la Historia de Etapa Implementar. -Con la herramienta

Usuario. - Para evaluar la calidad de la GeneXus se genera automáticamente el
historia se aplica el proceso de las “Tres C” código necesario para:
creado por Ron Jeffiers, se detalla a
 Crear y mantener la base de datos;
continuación:  Generar y mantener los programas para
 Card (tarjeta) manejar los objetos descritos por el
 Conversation (Conversación) usuario.
 Confirmation (Confirmación). Fase de Entrega. - El equipo indica que
Reunión para planificar el desarrollo del alcanzó los objetivos planteados en la fase
producto. - Los participantes de esta reunión de apertura. Esta fase tiene dos actividades:
son: El equipo de desarrollo, el líder del Reuniòn Entrega final del “Producto
equipo y el líder de requerimientos. Software” y una reunión de reflexión.
La planificación estará enfocada en poner Reunión Entrega final del “Producto
fechas de desarrollo y tiempo de entrega Software”. - Esta reunión se caracteriza con
estimada por parte del Equipo de desarrollo una revisión tipo demo donde el equipo junto
a los usuarios prueba el “Producto Software”
El líder de requerimientos es el único
construido Finalizado.
responsable de esta lista de requerimientos
y será el enlace entre los usuarios y el Reunión de reflexión. -Esta etapa
analista Gx (desarrollador) que forma parte consiste en una reunión del equipo de
del equipo de desarrollo. desarrollo sin los usuarios con el objetivo de
revisar el proceso y mejorarlo.
Fase de Construcción. - La captura del
conocimiento del usuario nos permite Evaluación. -La evaluación debería
generar el ciclo de trabajo con las siguientes centrarse en validar la metodología
etapas. propuesta y en asegurar su efectividad para
abordar el problema tratado.
 Diseñar: Se describe el sistema a
desarrollar, se representan los Fase de Apertura. -Se detalla todas las
requerimientos de los interesados fases de manera práctica y se procesa la
(usuarios), lo cual permite definir la encuesta para evaluar. Aquí es donde se
construcción del “Producto Software”. define como añadir actividades que nos
 Generar: A partir de la fase “Diseñar” se ayuden a capturar el conocimiento
generan prototipos automáticos esta va (Requerimientos) del usuario, mediante la
acompañada de las siguientes acciones: técnica de historias de usuarios (HU) para
Creación de la base de datos en la base construir la Lista de requerimientos que
de datos seleccionada, creación del definen el producto Software.
código Fuente en el lenguaje
V. CONCLUSIONES Y TRABAJO
seleccionado, interfaz de usuario,
FUTURO
servicios en servidor. A. Conclusión
 Implementar: A partir del paso anterior, el
prototipo, el equipo y usuarios realizan las Este trabajo de fin de master, aporta para
pruebas necesarias donde se validan las solucionar el problema de la no utilización de
historias de usuarios definidas en la fase metodologías por parte de los profesionales
Apertura. del software, con un método de desarrollo
Etapa Diseñar. - Esta tarea es realizada ágil de software, basado en las mejores
conjuntamente por el analista Gx y el prácticas de las metodologías agiles. Se
usuario, consiste en identificar y describir las utilizó la herramienta Case Genexus que
visiones de datos de los usuarios guiados enfoca la filosofía de los conceptos agiles
por las historias de usuarios. para automatizar las tareas rutinarias de
desarrollo como son la programación,
Etapa Generar. - En las tareas de diseño documentación técnica y creación de base
están implícitas las dificultades de toda
de datos. Esta automatización de tareas
comunicación humana:
redujo el tiempo del proyecto y le incorpora
 El usuario olvida ciertos detalles. calidad y seguridad al producto software.
 El analista no toma nota de algunos Se examinó las mejores prácticas
elementos.
utilizadas en las principales Metodologías
 El usuario se equivoca en algunas
Agiles, que aportan al desarrollo de software
apreciaciones.
en las organizaciones a nivel mundial como
 El analista interpreta mal algunas
son: Scrum, Kanban y Programación
explicaciones del usuario. Extrema, para construir el método propuesto
125
en este trabajo denominado, “Método Ágil base de conocimiento y pueden ser

con Genexus” (Magic-Gx). consultadas en cualquier momento, además
hay varios reportes como la base de datos
Se Validó la propuesta mediante un caso
en tercera forma normal para análisis si es
de estudio aplicado en un ambiente de
organización agropecuaria. Se construyó necesario.
una aplicación Web para el sector B. Líneas de trabajo futuro
agropecuario, basado en los requerimientos
Se plantean las siguientes propuestas
de la asociación de productores
como mejoras al método desarrollado en
agropecuarios San Antonio (APASA), que este trabajo:
se encuentra situada en la Parroquia Manuel
J. Calle del cantón la Troncal provincia del Realizar un trabajo más amplio con la
Cañar. metodología desarrollada, por ejemplo:
profundizar a nivel Ecuador sobre las
Este método ágil, Magic-Gx, en base a la tendencias de uso de metodologías para
experimentación realizada nos permitió realizar experimentos y sacar mejores
observar cómo se implementa y se concluye
conclusiones.
el siguiente logro:
Proponer Incorporar en la Universidad
Reducir tiempo de desarrollo, porque la estatal de Milagro-Ecuador la utilización del
aplicación se describe no se programa, método como un proyecto integrador en los
existe generación automática de base de
últimos niveles y compararlo con otros
datos y programas partiendo de la
métodos.
descripción almacenada en la base de
conocimiento de Genexus. El método desarrollado puede aplicarse
a cualquier proyecto donde se requiera
Alta participación del usuario en el
desarrollo de manejo de datos como
proceso, garantizando la calidad en los
aplicaciones en ambientes web, móviles y
resultados.
ambientes de mainframe como As/400, con
El método no elimina la documentación, el objetivo de producir información.
la fomentó en línea por medio de Genexus
Se puede profundizar en añadirle un
en todos los integrantes del equipo de
método de pruebas con herramientas
desarrollo, porque se basa en las
automatizadas.
descripciones que están almacenadas en la
Canos, J., Letelier, P., & Penadés, M. C. (2003).

Metodologías Ágiles en el Desarrollo de Software.
REFERENCIAS Recuperado de
https://ldc.usb.ve/~abianc/materias/ci4713/actasMetAg
Zelkowitz, M. V., Shaw, A. C., & Gannon, J. D. (1979). iles.pdf
Principles of software engineering and design. Prentice-
Hall. Recuperado de
https://dl.acm.org/citation.cfm?id=578504&preflayout=f GeneXus training. (2017a). Introducción Teórica
lat Genexus. Recuperado de
https://training.genexus.com/genexus/materiales-
Pressman, R. (2010). Ingeniería del software. Un curso-genexus-15?es
enfoque práctico (septima). Mèxico: McGram-Hill.
Fowler, M. (2005). La nueva metodología. Recuperado Artech Consultores. (2012b). Visión General de
28 de junio de 2018, de GeneXus.
https://martinfowler.com/articles/newMethodology.htm.
Gonda, B., & Jodal, N. (2007). Desarrollo Basado en

MendesCalo, K., Estevez, E., & Fillottrani, P. (2009). Conocimiento Filosofía y Fundamentos Teóricos de
Un Framework para Evaluación de Metodologías Genexus. Artech, 1-17.
Ágiles. Recuperado 3 de julio de 2018, de
https://www.researchgate.net/publication/242584795_
Un_Framework_para_Evaluacion_de_Metodologias_A
velneo. (2018a). ¿Qué es Velneo? Recuperado 10 de
giles
agosto de 2018, de https://velneo.es/info/
Beck, K. (2000). Extreme Programming Explained,

Aguilar, J. (2010). Velneo v7: Desarrollo de
Second Edition. Recuperado de
aplicaciones empresariales. Recuperado 10 de agosto
http://ptgmedia.pearsoncmg.com/images/9780321278
de 2018, de
654/samplepages/9780321278654.pdf
https://www.variablenotfound.com/2010/11/velneo-v7-
desarrollo-de-aplicaciones.html
126
127
View publication stats

TFM Moises Lopez Magic GXV 21

Cargado por

Información del documento

Descripción original:

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

TFM Moises Lopez Magic GXV 21

Cargado por

Copyright:

Formatos disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Método ágil en el desarrollo de software aplicando la herramienta Genexus

Thesis · November 2018

Metodo agil con Genexus View project

The user has requested enhancement of the downloaded file.

Método ágil en el desarrollo

Trabajo Fin de Máster

Tipo de trabajo: Desarrollo de metodología

Presentado por: López Bermúdez, Ricauter Moisés

Director: Dr. Bermejo Higuera, Juan Ramón

Ciudad: Milagro, Ecuador

El trabajo aporta para solucionar el problema de la no utilización de metodologías por

La experimentación realizada del método nos permitió observar la forma de

1) Reducir tiempo de desarrollo, porque la aplicación se describe no se programa, existe

Palabras Clave: Método Ágil, Genexus, Software

The work contributes to solve the problem of non-use of methodologies by software

1) Reduce development time, because the described application is not programmed,

Keywords: Agile Method, Genexus, Software

1.2 Planteamiento del trabajo .................................................................................. 11

1.3 Estructura de la memoria .................................................................................. 12

2. Contexto y estado del arte ................................................................................... 13

2.1 Ingeniería de software ....................................................................................... 13

2.2 Enfoques de Métodos desarrollo de software .................................................... 14

2.2.1 Modelo en cascada ..................................................................................... 14

2.2.2 Modelo de Prototipos .................................................................................. 15

2.2.3 Modelo Incremental .................................................................................... 17

2.2.4 Modelo Espiral ............................................................................................ 17

2.3 Metodologías Ágiles .......................................................................................... 18

2.3.1 Las Metodologías Agiles Aplican desarrollo iterativo e incremental ............ 19

2.3.2 El manifiesto ágil ......................................................................................... 19

2.3.3 Postulados del Manifiesto Ágil .................................................................... 20

2.3.4 Doce Principios del Manifiesto Ágil ............................................................. 22

2.3.5 Estado del Desarrollo Ágil ........................................................................... 23

2.4 Metodologías Agiles más usadas ...................................................................... 29

2.5 Metodología Scrum ........................................................................................... 29

2.5.1 Introducción ................................................................................................ 29

2.5.2 Roles en Scrum .......................................................................................... 31

2.5.3 Artefactos o Elementos de Scrum ............................................................... 31

2.5.4 Eventos o Actividades en Scrum................................................................. 33

2.6 Metodología Kanban ......................................................................................... 38

2.6.1 Introducción ................................................................................................ 38

2.6.2 Actividades principales de Kanban ............................................................. 38

2.6.3 Roles de Kanban ........................................................................................ 40

2.7 Metodología Programación eXtrema (XP) ......................................................... 41

2.7.1 Elementos de XP ........................................................................................ 41

2.7.2 Roles de XP ................................................................................................ 41

2.7.3 Proceso XP ................................................................................................. 42

2.8 Herramientas de Desarrollo ............................................................................... 45

2.8.1 La herramienta GeneXus ............................................................................ 45

2.8.2 La herramienta Velneo. ............................................................................... 52

3. Objetivos concretos y metodología de trabajo ..................................................... 56

3.1 Objetivo general ................................................................................................ 56

3.2 Objetivos específicos......................................................................................... 56

3.3 Metodología del trabajo ..................................................................................... 56

4. Desarrollo de la Propuesta de Metodología ......................................................... 58

4.1 Identificación de requisitos ................................................................................ 58

4.1.1 Roles .......................................................................................................... 58

4.1.2 Elementos ................................................................................................... 59

4.1.3 Actividades o Reuniones............................................................................. 60

4.2 Descripción de la Metodología propuesta .......................................................... 60

4.2.1 Fases y Actividades. ................................................................................... 61

4.3 Fase de Apertura............................................................................................... 63