Upload
others
View
12
Download
0
Embed Size (px)
Citation preview
Un Método de Elicitación de Requisitos Para SCRUM Compuesto
Por Inception Deck y Modelos de Proceso de Negocios (BPMN).
MANUEL ALEJANDRO PASTRANA PARDO, Esp
Director HUGO ARMANDO ORDOÑEZ ERAZO, PhD
Universidad San Buenaventura de Cali Facultad de Ingeniería Sistemas
Maestría en Ingeniería de Software Cali, Septiembre de 2017
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
1 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
AGRADECIMIENTOS
A mis padres por su infinito apoyo, paciencia y comprensión aún en mis
momentos más difíciles, al Doctor Hugo Ordoñez por su orientación cuando
más lo necesité y a todos aquellos que creyeron en mí desde el inicio.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
2 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Contenido
AGRADECIMIENTOS .................................................................................................................. 1
1. PLANTEAMIENTO DEL PROBLEMA .................................................................................. 8
2. JUSTIFICACIÓN ............................................................................................................ 12
3. OBJETIVOS .................................................................................................................. 14
3.1 OBJETIVO GENERAL ..................................................................................................... 14
3.2 OBJETIVOS ESPECÍFICOS. .................................................................................................... 14
4. RESULTADOS OBTENIDOS ............................................................................................ 15
5. ORGANIZACIÓN DEL DOCUMENTO ............................................................................... 17
6. INGENIERÍA DE REQUISITOS TRADICIONAL ................................................................... 18
7. INGENIERÍA DE REQUISITOS EN MÉTODO LOGÍAS Y FRAMEWORKS AGILES ................... 20
8. MODELADO DE PROCESOS BP EN FRAMEWORKS AGILE SCRUM .................................... 22
9. ESTRATEGÍA PROPUESTA ............................................................................................. 34
9.1 IDENTIFICADOR O ID .................................................................................................... 35
9.2 YO COMO [ROL] ........................................................................................................... 35
9.3 REQUIERO [FUNCIONALIDAD] ...................................................................................... 35
9.4 PARA [MOTIVO U OBJETIVO DE LA FUNCIONALIDAD] .................................................... 36
9.5 CRITERIOS DE ACEPTACIÓN .......................................................................................... 36
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
3 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
10. INCLUSION DE MODELOS BP EN SCRUM ....................................................................... 40
10.1 ANALISIS DE SOFTWARE Y UNIFICACION DE LA VISION DEL PRODUCTO .......................... 40
10.2 PLANIFICACION BASADA EN LOS MODELOS DE NEGOCIO............................................... 41
11. HIPÓTESIS ................................................................................................................... 43
12. DISEÑO DE LA INVESTIGACIÓN ..................................................................................... 44
13. PROYECTOS ANALIZADOS ............................................................................................ 45
14. MUESTRA Y RESULTADOS ............................................................................................ 45
15. VALIDACIÓN DE HIPÓTESIS .......................................................................................... 50
16. CONCLUSIONES ........................................................................................................... 53
17. REFERENCIAS BIBLIOGRÁFICAS ..................................................................................... 56
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
4 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
ÍNDICE DE FIGURAS
Figura 1 Factores de éxito tomada de [1] ........................................................................................................... 9
Figura 2 Evolución de la industria en los últimos 5 años tomada de [1] .......................................................... 10
Figura 3 REBPM Ciclo de vida tomado de [10] ................................................................................................. 13
Figura 4 Formato de historia de usuario, [14]. ................................................................................................. 21
Figura 5 Ciclo de desarrollo de SCRUM- Facilitación gráfica tomada de las charlas ágiles de Martin Alaimo.
https://www.youtube.com/watch?v=IWUG29VPhUA&t=78s ......................................................................... 23
Figura 6 Facilitación gráfica realizada por el autor sobre el proceso de análisis de software y gestión de
requisitos en SCRUM ........................................................................................................................................ 25
Figura 7 Bandeja de revisión de propuestas proyecto Engine .......................................................................... 31
Figura 8 registro y recepción solicitudes del contratante, proyecto Engine. .................................................... 39
Figura 9 Proceso de solicitud del servicio de taxis desde el stand por parte del usuario. ................................. 48
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
5 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
ÍNDICE DE TABLAS
Tabla 1Generación de nuevos conocimientos y desarrollos tecnológicos - Fuente: elaboración propia .......... 15
Tabla 2 Fortalecimiento de la comunidad científica. - Fuente: elaboración propia ......................................... 16
Tabla 3 Apropiación social del conocimiento involucrado en el desarrollo de la investigación - Fuente:
elaboración ....................................................................................................................................................... 17
Tabla 4 Riesgos del proyecto, Riesgo (R), Probabilidad de que ocurra (Po), Impacto (I), Prioridad (P),
Responsable (Rs), Acción (A), Product Owner(PO), ST (Scrum Team) .............................................................. 30
Tabla 5 Comparación entre historias de usuario y modelos BP ........................................................................ 38
Tabla 6 Descomposición de actividades de desarrollo tarea login a partir de modelo BP ............................... 42
Tabla 7 Correlación métricas e hipotesis de la investigación ........................................................................... 44
Tabla 8 Requisitos Elicitados, modificados y adicionados por proyecto ........................................................... 51
Tabla 9 . Reporte consolidado de no conformes por proyecto evaluado.......................................................... 53
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
6 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SECCIÓN I – INTRODUCCIÓN
De acuerdo al análisis realizado en [1], tradicionalmente una problemática que
aqueja a los proyectos de software es el análisis de las necesidades reales de los
proyectos, lo que conlleva a que el proceso de elicitación de requisitos refleje una
percepción superficial de lo que realmente es necesario para solucionar un
problema. Lo anterior hace que finalmente los proyectos se atrasen, requieran
cambios drásticos incurriendo en sobrecostos o finalmente sean cancelados.
En respuesta a la necesidad de mejora de la etapa de elicitación, específicamente
del pre-análisis y el análisis de software aparece Inception deck [2]. La técnica se
centra en crear una visión unificada del proyecto en todos sus aspectos a partir del
consenso de las opiniones de todos los involucrados en una única reunión de
elicitación de requisitos, siendo guiados a través de 10 preguntas (No es
obligatorio utilizarlas todas, pero si es recomendable). Esto permite de manera
objetiva dimensionar qué se requiere hacer, los riesgos inherentes del proyecto,
las estrategias para resolverlos, qué personas son relevantes para lograr con éxito
el proyecto, qué no es el proyecto, qué arquitectura se debe llevar a cabo y cuánto
puede costar en tamaño y costo. Además permite unificar las necesidades para
definir la visión del producto, saber cómo se llama, porque haría ese producto una
diferencia en su entorno y qué frase representa o explica al producto. Todo esto se
consolida mediante la generación de un mapa de historias, que luego se traduce
en un product backlog (Artefacto fundamental del proceso de análisis de software
para el framework ágil SCRUM) compuesto por historias de usuario listas para ser
refinadas, estimadas y priorizadas.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
7 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Como lo menciona [3], esta reunión es bastante costosa dado que involucra a
todos las personas del cliente y el proveedor que tengan alguna interacción
relevante con el proyecto y/o el proceso. Sin embargo, este costo es equilibrado
con los resultados que se obtienen de un buen análisis sobre la calidad del
producto y la velocidad con la que se desarrolla. Es importante aclarar que entre
[2] y [3] se mantiene una esencia pura del agilísimo por lo que ambos conllevan a
interpretar la técnica de la misma manera, por lo que siguen los mismos pasos.
El llegar a un consenso en la mayoría de los puntos de vista y unificar la visión del
producto resulta en una optimización palpable del proceso de elicitación de
requisitos. Adicionalmente detectar los riesgos en una etapa inicial del proyecto
acarrea estar preparado para posibles eventualidades. Sin embargo, esto no
conlleva a eliminar la ambigüedad del product backlog compuesto por historias de
usuario que contiene la información recopilada dado que está escrito en lenguaje
natural.
Por lo anterior y pese a que la técnica converge en resultados exitosos para los
proyectos. Se requiere una manera de poder optimizar el proceso reduciendo la
ambigüedad que recae sobre el artefacto final, sin eliminar el insumo base del
framework SCRUM. Es aquí donde se plantea el uso de modelos de procesos de
negocio o modelos de BP como una estrategia para disminuir la ambigüedad del
lenguaje natural a través de una herramienta visual que permite interpretar de un
único modo el proceso, sus variables, contexto y necesidades de acuerdo a la
representación gráfica de la solución.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
8 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
1. PLANTEAMIENTO DEL PROBLEMA
Durante la evolución de la ingeniería de software distintas entidades se han preocupado
por determinar la tasa de éxito y fracaso de los proyectos, buscando así identificar
factores claves que permitan encontrar la causa raíz y dar soluciones definitivas a los
problemas de esta área. Es así como en [1], el standish group realiza un análisis meticuloso
de la evolución de la industria. Esto lo vienen realizando desde 1994. En los últimos
reportes se presentan una serie de resultados comparativos entre las metodologías ágiles
y las tradicionales, indicando para diversos tamaños de proyectos (pequeños, medianos y
grandes) cuantos proyectos en porcentaje han sido exitosos, cuantos presentan cambios y
cuantos han fallado. Para los proyectos pequeños se obtiene un 58% de éxito y sólo un 4%
de fracaso en los proyectos que utilizaron metodologías agiles para su ejecución frente a
una tasa de éxito del 44% y una de fallo de 11% en los tradicionales. Este mismo
comportamiento que refleja una mejora en los resultados al utilizar metodologías agiles,
se identifica al revisar los casos de éxito de los proyectos medios donde la tasa de éxito en
agiles es del 27%, frente al 7% de éxito al utilizar metodologías tradicionales. La tasa de
fallo en los proyectos medios es del 11% en agiles versus el 25% en tradicionales. En los
proyectos grandes la tasa de éxito para los realizados bajo metodologías agiles es de 18%
en comparación con el 3% de éxito de los proyectos desarrollados bajo el enfoque cascada
tradicional. Así mismo la tasa de resultados de fallo es de 9% para proyectos agiles, frente
a un 29% para tradicionales. Estas mediciones permiten identificar en la industria el
impacto que tiene el uso de las metodologías ágiles para el desarrollo de los proyectos de
software en comparación con las metodologías tradicionales. Lo anterior puede ser
interpretado en dicho reporte a partir de la figura 1, [1].
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
9 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Figura 1 Factores de éxito tomada de [1]
Lo anterior permite identificar que el enfoque ágil centrado en los individuos y sus
interacciones, la colaboración con el cliente, la respuesta al cambio, el software
funcionando rápidamente para su evaluación, retroalimentación y ajuste continuo como
indica [4] ha cambiado el resultado final y la percepción de éxito de estos proyectos.
Aunque los resultados obtenidos para las tasas de éxito y fracaso son más favorables para
las metodologías agiles que para las tradicionales, aún quedan aspectos por mejorar dado
al alto porcentaje de cambios que se presentan dentro de los proyectos. Lo que puede
generar que un proyecto exitoso se convierta en un fracaso.
En general las tasas de éxito, fracaso y cambio mantienen una medida estable durante los
últimos años como se observa en la figura 2. Los valores para la tase de éxito en proyectos
de cualquier tamaño bajo el enfoque ágil, presentan una medida inicial para el año 2011
de 29% y final para el 2015 del mismo valor, siendo su pico más alto en el año 2013
donde obtienen un 31 % de éxito. Los cambios presentan una tasa de entre 49% y 56%
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
10 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
que evidencia que las mejoras implementadas al proceso de desarrollo bajo el enfoque
ágil, no han logrado disminuir los cambios presentes dentro de un proyecto.
Figura 2 Evolución de la industria en los últimos 5 años tomada de [1]
Esto sucede por dos razones identificadas desde los inicios de la investigación en el año
1994 y presentes aún en los últimos reportes. La primera razón es el no involucramiento
de los usuarios en todo momento durante el proceso, pese a que la tendencia agilista
notablemente se enfoca en incluir activamente a los stakeholders o interesados a través
del rol del product owner (rol de SCRUM denominado dueño del producto quien vela
porque la visión del proyecto se lleve a cabo manteniendo la calidad del mismo y
apoyando al equipo para alcanzar los objetivos propuestos), esto no implica que la
industria lo esté haciendo en la realidad. Lo anterior resolvería muchos problemas dado
que permite la verificación y retroalimentación constante sobre el avance del proyecto.
También, permite la mejora continua como lo sugiere [5]. Adicionalmente la
especificación de las entregas de valor, caracterizadas en el product backlog, pueden ser
propensas a ser refinadas y revisadas junto con el usuario optimizando los resultados del
sprint (denominación de un periodo de tiempo de desarrollo de una entrega parcial del
producto 100% funcional y con calidad, que va de 1 a 4 semanas) para el caso de SCRUM.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
11 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Por otra parte la segunda razón está relacionada con el proceso de elicitación de
requisitos. Este proceso sufre constantemente de un problema clave para el éxito o
fracaso de un proyecto y es la ambigüedad resultante de la documentación. Durante el
proceso de elicitación de requisitos se realiza una recopilación de la información a través
de preguntas. Estas son puestas en lenguaje natural en un artefacto (Historias de usuario
en SCRUM, casos de uso en RUP) y finalmente son interpretadas de la misma manera por
quien las lee, dejando brechas de conocimiento que probablemente se queden en el
pensamiento del cliente y del analista pero que no se hallan aterrizado para ser utilizadas
por el equipo de desarrollo. Esto significa que finalmente no se tiene claro en su totalidad
el quién quiere hacer, el qué se quiere hacer y para qué se quiere hacer, [6].
Por lo tanto el enfoque a la hora de ejecutar una técnica de elicitación de requisitos
repercute de manera negativa dado que el cliente y el equipo que desarrolla el proyecto
no pueden determinar la visión del producto de manera adecuada, no pueden definir los
objetivos del sistema y finalmente puede suceder que sus puntos de vista y necesidades
terminen entrando en conflicto con los de otros stakeholders [7].
Con motivo de esta preocupación sobre las técnicas tradicionales de elicitación de
requisitos, dentro del mundo del ágil se orientan otras técnicas que permiten obtener
resultados diferentes a los presentados por las técnicas tradicionales, todas ellas
enfocadas en solucionar los factores de variabilidad o cambios implícitos en los proyectos
y evitando superar el escenario actual de casos de falla que está en un rango entre 17% y
22%, [1].
Investigaciones como [8], han tratado de solucionar los problemas identificados y
mencionados en los párrafos anteriores, combinando la elicitación tradicional con el
modelado de proceso de negocios o BP, especificando que un proceso de análisis de
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
12 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
software puede culminar exitosamente si el resultado final es un modelo BP. Esto sucede
debido a que la representación de la información del proceso se realiza por medio gráfico
y su interpretación es única debido al estándar de notación BPMN. Este estándar permite
eliminar así la ambigüedad presente en el lenguaje natural con el que se escriben las
historias de usuario, ya que los elementos que componen el modelo bajo la notación solo
pueden ser interpretados de una sola manera. El enfoque de este documento fusiona las
ventajas de unificar la visión del producto como lo hace la técnica del inception deck y
mantener esta visión para el equipo mediante una documentación no ambigua por medio
de los modelos de BP, permitiendo así proponer un nuevo método de elicitación de
requisitos que permita mejorar de manera significativa el análisis de software de los
proyectos.
2. JUSTIFICACIÓN
La adopción actual de la industria del modelo ágil por encima del tradicional radica en los
resultados de éxito obtenidos en esta forma de trabajo [1]. El enfoque sobre equipos
auto-organizados y multidisciplinarios en SCRUM exige un mayor nivel de eficiencia y
calidad, la inclusión de los interesados de manera continua dentro del proyecto reduce el
impacto de posibles brechas entre lo que los stakeholders intentan trasmitir y los
miembros del equipo mejorando así la calidad del resultado [5], pero de alguna manera el
enfoque logrado mediante el análisis de software sin importar si es tradicional o ágil, se
difumina al paso del tiempo. Lo anterior se presenta debido a que al ser escrito en
lenguaje natural no mantiene una imagen común para todos y por el contrario puede
interpretarse de varias maneras.
Dentro del análisis de requisitos y el Bussines Process Modeling (BP) existe una estrecha
relación en su forma de trabajo tal y como lo explica en detalle [9]. En [10], se propone un
framework con el objetivo de maximizar el resultado obtenido en el proceso de elicitación
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
13 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
mediante la combinación de las técnicas tradicionales donde se realizan las actividades de
elicitación, especificación y validación de la información y el modelado de negocios donde
la información transformada desde el análisis de requisitos puede ser modelada,
propendiendo este resultado a que el refinamiento necesario innato de todo proceso sea
mínimo. La Figura 3 describe lo anterior:
Adicionalmente se interpreta del mismo trabajo que tanto [9] como [10], buscan como
objetivo principal la consolidación de la información en un medio lo bastante sólido como
para mantener dicha información a través del tiempo, pero el alcance de los modelos BP
llega mucho más lejos porque es posible que a partir de los modelos generados pueda
realizarse la implementación de un BPMS (business process management software), lo que
abre una gama de posibilidades tanto a la academia como a la industria bastante amplia.
Elicitación Especificación
Validación
Ingeniería de requisitos - Ciclo de vida
Análisis
Diseño
Configuració
n
Ejecución
SBPM - Ciclo de vida
Transformación
Figura 3 REBPM Ciclo de vida tomado de [10]
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
14 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Complementando lo anterior, [11] revisa detenidamente SCRUM, como funciona, sus
artefactos principales y sus ceremonias para lograr adaptar este proceso con la inclusión
del uso de modelos BP (sin remplazar las historias de usuario) . Así mismo, se compara la
relación presente entre los roles, sus actividades y las ceremonias. Siempre desde la
recepción del Product Backlog no desde antes (pre-análisis).
Este trabajo propende utilizar la técnica inception deck desde el pre-análisis para resolver
la pregunta de investigación central de este documento: ¿Cómo realizar la construcción
del product backlog y el refinamiento del mismo a partir de modelos BP que permitan que
el reproceso producto del lenguaje natural con el que se escriben las historias de usuario
se minimice en gran parte?
3. OBJETIVOS
3.1 OBJETIVO GENERAL
Definir un método de elicitación de requisitos para SCRUM compuesto por inception
deck y modelos de proceso de negocio.
3.2 OBJETIVOS ESPECÍFICOS.
Determinar una forma de identificar las preguntas adecuadas de la actividad
elevator pitch (dinámica que permite identificar factores diferenciadores del
sistema, beneficios y visión del producto) del inception deck son las adecuadas
en la fase de pre-análisis.
Establecer una representación gráfica de los requisitos, a través de BPMN del
walking skeleton (estructura dinámica dividida en módulos y funcionalidades
que sirve de base para identificar todo el sistema) posterior a la fase de pre-
requisitos de SCRUM. Evaluar la calidad de los requisitos consolidados en el mapa de historias y
modelados a través de BPMN con una métrica de comprensión.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
15 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
4. RESULTADOS OBTENIDOS
A continuación se describe los resultados obtenidos en esta investigación con relación a:
Tabla 1. Generación de nuevos conocimientos y desarrollos tecnológicos.
Tabla 2. Fortalecimiento de la comunidad científica nacional.
Tabla 3. Apropiación social del conocimiento involucrado en el desarrollo de la
investigación.
En cada uno de los tipos de resultados obtenidos se definen los resultados, el indicador o
los beneficiarios de los mismos.
Resultados Indicador
Un nuevo modelo de elicitación de
requisitos basado en inception
deck y modelos de procesos de
negocio BP.
Documento de tesis de maestría, trabajos en
eventos nacionales e internacionales y revistas.
Mapeo de componentes para la
elaboración de los modelos BP de
un proyecto basado en la técnica
de inception deck
Detalla del procedimiento realizado para la
ejecución de la técnica inception deck, mapeando
los componentes obtenidos a modelos BP.
Tabla 1Generación de nuevos conocimientos y desarrollos tecnológicos - Fuente: elaboración propia
Resultados Beneficiarios
Formación de talento humano a nivel
profesional
Dirección de artículo, total de estudiantes
participantes (4). Universidad Antonio José
Camacho, Cali.
Formación de talento humano a nivel
de educación continua
Diplomado de ingeniería de software bajo el
enfoque de la calidad en las metodologías
agiles, universidad del pacifico, Buenaventura.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
16 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Diplomado de ingeniería de software un
enfoque ágil, universidad Antonio José
Camacho, Cali.
Formación de los estudiantes de
pregrado en ingeniería de software
bajo el enfoque de SCRUM, utilizando
en la etapa de análisis de requisitos la
técnica propuesta.
Se orientaron los cursos de ingeniería de
software III y seminario de actualización en el
programa de Ingeniera de sistemas de la
Universidad Antonio José Camacho.
Tabla 2 Fortalecimiento de la comunidad científica. - Fuente: elaboración propia
Resultados Indicador
Dos artículos en eventos
internacionales en temáticas
directamente relacionadas con
la tesis
1. M. Pastrana, H. Ordoñez, A. Ordoñez. L.
Merchan. “Requirements elicitation based on
Inception deck and business processes models in
Scrum”. XII Congreso Colombiano de
Computación. 19-22 Septiembre 2017, Cali –
Colombia. Artículo publicado en Springer como
capítulo en el libro Communications in Computer
and Information Science, SSN: 1865-0929: http://
2. M. Pastrana, H. Ordoñez, A. Ordoñez, L. Thom, L.
Merchan. ”Optimization of the Inception Deck
technique for eliciting requirements in SCRUM
through business process models”.
15th International Conference on Business
Process Management (BPM 2017) y
3rd International Workshop on the Interrelations
between
Requirements Engineering & Business Process
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
17 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Management (REBPM). Http://
Tabla 3 Apropiación social del conocimiento involucrado en el desarrollo de la investigación - Fuente: elaboración
5. ORGANIZACIÓN DEL DOCUMENTO
En la Sección II del presente documento se describe todo el marco conceptual y teórico
que soporta la investigación realizada. Se detallan los temas de SCRUM, construcción de
historias de usuario (HU) basado en el modelo de [6], BP y BPMN, BP como complemento
de las HU en la ingeniería de requisitos y BP como remplazo de las HU. En la Sección III se
presenta la estrategia propuesta donde se decide si se complementan las historias de
usuario o se remplazan y que tanto esto afecta al framework SCRUM. En la Sección IV se
detalla el planteamiento de la hipótesis del trabajo investigativo, cómo se evalúa dicha
hipótesis, cómo se realiza la investigación y cómo se evalúan sus resultados. En la Sección
V se presentan los resultados obtenidos. En la Sección VI se presentan las conclusiones a
las que se llega después de la investigación realizada, además de posibles trabajo futuros.
En la Sección VII se presenta la bibliografía
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
18 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SECCIÓN II – MARCO TEÓRICO
En esta sección se presenta la revisión del marco teórico en el que se abordan 3 temas
principales: como primera instancia se revisa la ingeniería de requisitos tradicional, en
segunda instancia se aborda la ingeniería de requisitos en las metodologías y frameworks
ágiles, en tercera instancia se estudia el modelado de procesos de negocio BP y su
inclusión en SCRUM.
6. INGENIERÍA DE REQUISITOS TRADICIONAL
La ingeniería de requisitos pertenece a la ingeniería de software y comprende todas las
actividades de análisis de un proyecto. Para entender en mayor detalle lo anterior,
debemos partir de la definición formal de que es un requisito. Según [12] se define como:
1. Una condición o capacidad requerida por un usuario para resolver un problema.
2. Una condición o capacidad que debe alcanzar o poseer un sistema o componente para
satisfacer un contrato, un estándar, una especificación o un documento formalmente
impuesto.
3. Una forma documentada de 1 o 2
Por lo anterior se interpreta que las actividades de análisis que realiza la ingeniería de
requisitos dependen de las necesidades y decisiones humanas y lo que busca esta área es
poder consolidar dichas necesidades en lenguaje natural de manera que estas puedan ser
estimadas, priorizadas, organizadas y recopiladas en algún formato para posteriormente
ser transformadas mediante un producto de software que dé respuesta a esas
necesidades.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
19 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Para las metodologías tradicionales como RUP se define un estándar de cómo realizar
dicha especificación de requisitos en [13]. Bajo esta especificación se detalla que los
requisitos constan de:
Descripción general
Perspectivas del producto
Funciones del producto
Características de los usuarios
Restricciones
Requisitos específicos
Requisitos no funcionales (rendimiento, restricciones de diseño y atributos del
sistema)
De esta manera los requisitos quedan correctamente definidos bajo una la restricción de
que no sean ambiguos (hasta cierto punto), que sean correctos, es decir que trasmiten
una necesidad real, son completos, consistentes, clasificables, modificables, trazables y
verificables.
Según [7], la metodología tradicional RUP cuyo ciclo de vida es en cascada, abarca la
ingeniería de requisitos dentro de la denominada fase de análisis. La primera actividad
que se realiza dentro de este proceso es la elicitación de requisitos bajo la definición
anteriormente mencionada en [13]. Posteriormente, transforma estos requisitos en un
conjunto de artefactos denominados casos de uso, que cumplen como función generar
una ficha estandarizada que contempla toda la información y descripción funcional de
como interactuará el sistema con el usuario en una descripción del escenario a modo de
guion, que será complementado con prototipos de pantalla o mocks, y que a su vez
describen a nivel grafico cómo será la organización de los componentes en pantalla
(descripción de las pantallas del sistema). Una vez esta información está aprobada por el
usuario se finaliza la fase de análisis y se procede a continuar con la fase de diseño,
terminando el proceso formal de análisis de requisitos.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
20 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
7. INGENIERÍA DE REQUISITOS EN MÉTODO LOGÍAS Y FRAMEWORKS AGILES
Dentro de la ingeniería de requisitos para las metodologías y frameworks agiles no existe
un estándar o modelo único a seguir, ni una especificación como en tradicionales bajo una
norma que expresa cómo deberían ser escritos los artefactos que recopilan la información
elicitada, aunque algunos autores han trabajado en el tema formando un estándar
implícito en el mismo.
Dentro de las diversas formas que existen para consolidar la información se encuentra la
detallada por [6] y por[14].
Para la definición de [14], las historias de usuario como artefacto principal de recopilación
de la información se interpretan como tarjetas donde el usuario final describe en sus
propias palabras de manera corta y concisa las características que el sistema debe poseer
sean de tipo funcional o no. Estas historias de usuario deben ser lo suficientemente claras
y detalladas para poder ser implementadas en un tiempo de 1 a 4 semanas que es la
duración de sprint (tiempo máximo para la entrega parcial de un proyecto). Estas
historias de usuario finalmente se descomponen en tareas de programación o task cards
que los desarrolladores implementan. De esta manera el formato planteado se resumen
en la siguiente ficha:
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
21 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Figura 4 Formato de historia de usuario, [14].
En concordancia con lo expresado en la figura 4 se observa que [14] describe un formato
divido en dos partes, la parte superior consta de la descripción de la historia de usuario y
la parte inferior del seguimiento de la tarea (Task card) proponiendo así un modelo
hibrido entre seguimiento y elicitación de requisitos.
Aunque este formato da un punto de partida algunos autores prefieren utilizar las
historias de usuario basados en su división fundamental y no mezclando las dos tarjetas
en una sola. Esto conlleva a una redefinición planteada por [15] donde se utiliza el
nombre de la historia de usuario, un enunciado y sus criterios de aceptación, en especial
es XP (Extreme Programming).
Por otra parte [6], prefiere describir las historias de usuario en una forma narrativa bajo la
estructura “yo [como rol], requiero [funcionalidad], para [motivo o beneficio]”. Ejemplo yo
[usuario], requiero [una pantalla de acceso por login y password], para [acceder a las
funcionalidades disponibles según mi rol en el sistema]. Adicionalmente a esta descripción
se le adicionan los criterios de aceptación que permiten tener el detalle de que se
requiere en la construcción de la historia de usuario para poder construirla.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
22 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
8. MODELADO DE PROCESOS BP EN FRAMEWORKS AGILE SCRUM
Basado en el trabajo realizado por [4], se puede expresar que las metodologías agiles
surgen como respuesta a las necesidades de mejora de los distintos procesos de la
industria de software, a los requisitos tan cambiantes del mercado y a la inconformidad
expresada por quienes cansados de la manera tradicional de realizar los proyectos,
proponen nuevas maneras de afrontarlos. También, [4] identifica que la forma de trabajar
tradicionalmente las distintas etapas de los procesos de desarrollo de software conlleva a
una mayor probabilidad de fracaso, como lo corrobora desde el año 1994 hasta su versión
actual del 2016 los reportes elaborados por [1]. La forma de trabajo bajo un ciclo iterativo
incremental como el que plantean los frameworks y metodologías ágiles en contra
posición con las metodologías tradicionales, permite no solamente que los clientes
reciban entregas de valor tempranas sino un retorno de su inversión (ROI) de manera muy
rápida, en el tiempo que demore un sprint (de una a cuatro semanas). Frameworks como
XP y SCRUM se centran en la comunicación constante con el cliente, [16]. La
retroalimentación temprana de la información y la participación activa del cliente como
parte del equipo por medio de un representante denominado Product Owner quien
defiende la visión del proyecto de manera constante para evitar perder el foco de lo que
se está construyendo. Estos procesos de desarrollo trabajan bajo un cronograma flexible y
adaptable al cambio, manteniendo la calidad como eje transversal y obligatorio de todo el
proceso. Lo anterior conlleva a que la mejora continua sea un valor agregado de esta
forma de trabajo y aumentando de la probabilidad de éxito de los proyectos.
Los frameworks agiles como SCRUM y XP se centran en potenciar el trabajo colaborativo
entre el equipo de desarrollo, denominado en SCRUM como SCRUM TEAM y el cliente, de
esta manera la construcción de las historias de usuario se realiza en conjunto para
garantizar la calidad del mismo como lo explica [16].
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
23 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SCRUM propone un ciclo de desarrollo iterativo incremental con las fases tradicionales de
análisis, diseño, desarrollo, calidad y despliegue por cada sprint como lo describe Martin
Alaimo de la empresa Kleer en la figura 5, en una de sus capacitaciones.
Figura 5 Ciclo de desarrollo de SCRUM- Facilitación gráfica tomada de las charlas ágiles de Martin Alaimo.
https://www.youtube.com/watch?v=IWUG29VPhUA&t=78s
Dentro de este ciclo de desarrollo de SCRUM la elicitación de requisitos es una etapa
transversal y siempre se realiza al inicio de la iteración aunque esta presente durante todo
el proyecto en la refinación de las historias que poco a poco se van dando durante el
proceso.
Como punto de partida para poder construir el product backlog se requiere de un análisis
formal de requisitos. Esto se plantea mediante diversas técnicas como son la entrevista, la
encuesta y las listas de revisión bajo el enfoque tradicional o de manera más innovadora
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
24 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
con la técnica inception, descrita por [2,3]. Esta tecnica que funciona como juego serio,
propone una dinámica muy facil de seguir donde se plantean unas preguntas que permite
consolidar la visión, levantar insumos del proyecto, identificar riesgos de manera
temprana, definir el minimo producto viable a partir de un walking skeleton y finalmente
construir las historias de usuario que componen el product backlog. Esto a modo de
recopilación permite durante el planning meeting definir por sprint el ¿qué se hará?
(¿Qué?) y ¿el cómo se hara? (¿Cómo?) fijando así un compromiso. Dicho compromiso es
trazable mediante el informe diario presentado por el scrum team, quien realiza una
ceremonia diaria denominada daily scrum. En esta ceremonia se realiza frente al tablero
SCRUM (el corazón de SCRUM) respondiendo 3 preguntas:
¿Qué hice ayer?
¿Qué impedimentos se han presentado?
¿Qué haré hoy?
Los resultados de esta información permiten definir la medida de seguimiento del avance
del proyecto en la gráfica de la velocidad del equipo (burndown chart) que mide el avance
y cumplimiento de las metas del sprint por parte del equipo diariamente durante todo el
sprint lo anterior se resume en la figura 6.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
25 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Figura 6 Facilitación gráfica realizada por el autor sobre el proceso de análisis de software y gestión de requisitos en
SCRUM
Bajo este enfoque se mantiene la constante de que el proceso de elicitación es el
producto de la interacción colaborativa entre el scrum team y el cliente, mapeada en
lenguaje natural en las historias de usuario. El lenguaje natural siempre ha presentado
una ambigüedad intrinseca en la interpretación que cada persona da a lo que lee, por lo
mismo el refinamiento se hace constante y necesario para aumentar las posiblidades de
éxito de un proyecto.
[17] plantea una comparación entre casos de uso y BPMN (Business Process Modeling
Notation). En este estudio se determina que la interpretación de los casos de uso son
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
26 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
diferentes entre cliente y equipo de desarrollo de acuerdo a la perspectiva y enfoque que
cada uno tiene y por tanto su visión del proceso de negocio varia considerablemente. La
investigación arroja como resultado que la asimilación de las necesidades y el
entendimiento del proceso en que el producto de software interactua como factor de
optimización, es mucho mas intuitivo en el modelado de proceso, la visión se mantiene
unificada y finalmente solo hay un modo de interpretar dicha información, a diferencia de
los relatados en lenguaje natural dentro de los casos de uso.
Pero lo anterior aun se queda corto en terminos de mejora continua, pues las tecnicas
tradicionales, no han sido evolucionadas enfocadas a las problematicas ya mencionadas
anteriormente en este documento. Por otra parte, las metodologias y framewrks agiles
como scrum si han visualizado la posibilidad de obtener resultados diferentes a partir de
la ejecución de la tecnica inception deck, cuyo resultado final no son casos de uso sino
historias de usuario mediante la unificación de la visión del producto entre equipo y
cliente como indica [3] a traves de unas dinámicas objetivas que encaminan a obtener un
detalle completo de la solución a elaborar.
Para poder iniciar las dinámicas sugeridas por [3] debemos realizar una revisión de que
personas estan en la reunión y que papel jugaran. Por este motivo se realiza la pregunta
¿Quién esta en el auditorio?, estan pregunta conlleva a conocernos un poco, saber
quienes estan en el auditorio, identificar influencia y poder de sus opiniones.
Para realizar esta dinámica previa se requiere que se agrupen por parejas y se diligencie
en uno o varios post it lo siguiente:
Nombre
Datos de contacto
Que le gusta a la persona
Que le disgusta a la persona
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
27 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Dibuja una imagen que te represente.
El tiempo máximo asignado a esta actividad son 30 minutos dependiendo del tamaño del
equipo.
Una vez la actividad a culminado le pedimos a cada pareja que presente a su compañero,
de esta manera se rompe la tensión en el auditorio y se entra poco a poco en una zona de
confianza.
Despues de realizar esta dinámica previa se procede a explicar las reglas del juego, esto se
traduce como las normas a seguir en la reunión. Un ejemplo de esto es:
Cada actividad tiene un tiempo máximo para ser realizada y este tiempo no debe
ser excedido por lo que se cronometrara.
Para maximizar la productividad de la reunión las personas que estan en esa
reunión no deben atender otro asunto distinto.
No se utilizarán celulares a menos que sea para una presentación de algún tipo de
información relevante.
Todos los participantes de la reunión deben opinar.
Todas las opiniones son validas y respetadas.
El foco del proyecto es lo más relevante y por tanto todas las opiniones expresadas
sobre los planteamientos son validas y tomadas en cuenta por el equipo de
trabajo.
Una vez se han explicado las reglas del juego se realiza la primera pregunta de la tecnica
¿por qué estamos aquí?, esta pregunta enfoca la visión del producto, permite identificar
el contexto inicial y que puede aportar a esta visión quien contesta dicha pregunta. El
tiempo sugerido es de máximo 15 minutos. Una vez todas las opiones son puestas en el
tablero que las mantiene visibles al auditorio, se procede a compartirlas con las personas
presentes en la reunión.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
28 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Continuando con la técnica , se procede a generar un elevator pitch, esta dinámica
consiste en identificar rapidamente cual es la escencia del proyecto. Un buen proceso de
elevator pitch toma en cuenta que los auditorios pierden rapidamente interes si no saben
quien esta hablando, de que esta hablando y porque tiene un valor agregado. De esta
manera en un tiempo prudencial de alrededor de 20 minutos, cada integrante del equipo
intenta contestar lo siguiente:
¿Para quién está dirigida la solución?
¿Quién está identificando que necesidad u oportunidad?
Nombre del producto.
Categoria del producto.
Que beneficio trae la construcción de este proyecto.
Que no gusta del producto y que alternativas se plantea.
Factor diferenciador del producto.
Siguiendo con la dinámica le pedimos a los participantes del inception que diseñen su
caja del producto. Se plantea al auditorio que se imaginen que su proyecto esta
disponible en algun catálogo de venta de productos de software, de este modo para poder
imaginar esto deberian responder a:
Nombre del producto
Frase que lo identifica
Beneficios del producto que lo diferencia de los demas.
Este paso puede tomar de 20 a 60 minutos.
Una vez se ha realizado esto, es claro que hasta este punto las preguntas enfocan en crear
la visión de que es el proyecto, porque se debe realizar, que beneficios presentan y como
este proyecto trasnforma el proceso que mejora.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
29 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Posteriormente se procede a realizar una lista del no, lo que corresponde a explicar todo
lo que no es el producto delimitando claramente factores de proceso, tecnicos y legales.
Lo anterior delimita el alcance de lo que será construido. Tiempo estimado de 20 a 40
minutos.
Para poder lograr el éxito del proyecto y basado en la filosofia de agiles que plantea que la
interacción entre personas conlleva al éxito de los procesos, se hace relavante que la
dinámica prosiga con una pregunta denominada conoce el vecindario. Esta pregunta
permite identificar como las personas que estan en el auditorio interactuan e interacturan
y como potenciar esas relaciones para permitir el éxito del proyecto. La duración de esta
pregunta es de unos 30 a 60 minutos. Lo anterior determina los roles del producto, cuales
son las necesidades a satisfacer y las interaccioines con el proceso y la solución.
Luego de completar lo anterior, se continua con la pregunta ¿Qué te impide dormir en las
noches?. Esta pregunta se enfoca en identificar de manera temprana los posibles riesgos
del proyecto y las estrategias que debemos seguir para impedir que se materialicen o en
caso de materializarse que se debe hacer para minimizar el impacto. El tiempo estimado
para este paso es de 30 minutos hasta 2 horas. En la Tabla 4. Se expone un ejemplo de la
identificación de riesgos de uno de los proyectos evaluados.
R P
o
I P Rs A
Estrategia comercial no es clara aún 3 4 1
2
PO Definir estrategia comercial
en detalle
El proyecto debe estar terminado
por costos en 5 meses.
5 5 2
5
ST Los compromisos no son
negociables, por lo que la
calidad preventiva es
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
30 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
necesaria para cumplir con
la planeación
El equipo no tiene experiencia en
algunas de las tecnologias
implicadas. (Curva de aprendizaje)
5 2 1
0
ST Realizar pruebas de
concepto durante el sprint 0,
esto disminuye la curva de
aprendizaje
Tabla 4 Riesgos del proyecto, Riesgo (R), Probabilidad de que ocurra (Po), Impacto (I), Prioridad (P), Responsable (Rs), Acción (A), Product Owner(PO), ST (Scrum Team)
En este punto se procede a realizar la siguiente actividad que se denomin mostrar la
solución. Este punto tiene varias dinámicas a ejecutar dependiendo de la necesidad y el
auditorio:
Dar a la app una personalidad o give your app some personality:
Esta dinámica busca tratar la aplicación como una persona, detallando como se comporta
desde el aspecto emocional. Es algo complicada de aplicar y en algunos caso no se
recomienda usarla si el aspecto emocional de la interacción no es una guia relevante para
el sistema.
Hagamoslo fluir o let’s make it flow.
Se detalla el flujo de interacción del sistema desde el primer contacto del usuario con el
aplicativo hasta su salida de el.
Prototipado o Wireframing :
En esta dinámica se pretende bosquejar las pantallas del sistema, su flujo de interacción,
las acciones permitidas, que pantallas se mostraran por rol y que aspectos son relevantes
para el correcto desempeño del sistema. El wireframing toma mayor relevancia cuando el
cliente tiene muchas ideas pero no logra visualizar cómo se verían, por lo anterior se invita
a todos los participantes a realizar bosquejos de las pantallas del sistema. La figura 7
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
31 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
expone como ejemplo una de los prototipos de pantalla de uno de los proyectos
evaluados.
Figura 7 Bandeja de revisión de propuestas proyecto Engine
Mapa de historias o Story Maping:
Plantea la generación de un walking skeleton (estructura dinámica dividida en modulos y
funcionalidades que sirve de base para identificar todo el sistema), en este se define de
manera epica los modulos e historias de usuario de la solución a fin de encontrar de
manera rápida un mínimo producto viable. Esto permite definir claramente las
funcionlidades requeridas sin entrar aun en el detalle completo de su compisición lo que
permite rápida y felxiblemente modificarlo de acuerdo al alcance del producto.
Una vez concertado lo anterio se procede a definir ¿Lo qué hay que dar?, el objetivo de
esta pregunta es que todas las personas involucradas tengan claro que compromisos de
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
32 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
parte y parte se deben asumir para el éxito del proyecto. El tiempo para este paso varia de
10 a 30 minutos.
Despues del paso anterior se procede a definir ¿Lo qué costara hacerlo?, el objetivo de
esta pregunta es que el equipo realice sus apreciaciones sobre que costara hacerlo, no en
terminos economicos sino en aspectos técnicos, de proceso y de riesgos. El tiempo para
este paso varia de 10 a 30 minutos.
Resumen, es el paso final, es un buena practica hacer un resumen de los resultados antes
de concluir la actividad.
Una vez se ha concluido la actividad el scrum team se reune y consolida la información
elicitada en el documento formal de scrum denominado product backlog. Lo anterior
ayuda a mantener la visión del producto completa hasta la etapa de análisis.
Pese a que el trabajo realizado con esta técnica aumenta la probabilidad de éxito del
proyecto dado que mantiene la visión del proyecto de una manera muy clara, el resultado
final sigue siendo escrito en leguaje natural por lo que la problemática de interpretación
de lo que esta escrito no se ha eliminado completamente. En complemento con lo
anterior, el enfoque que da la pregunta mostrar la solución evoca a que el resultado sea
uno o varios graficos que permiten identificar de manera unica las necesidades a resolver
y su solución. Por este motivo los modelos visuales BP planteados como complento y
mejora en la tecnica pueden ayudar de alguna manera a facilitar la comunicación, el
entendimiento y a explorar distintas maneras de atacar el problema.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
33 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Dentro del trabajo a realizar en esta investigación se explora la manera de optimizar este
proceso manteniendo la visión alcanzada en el inception deck mediante artefactos de
unica interpretación como son los modelos BP bajo su notación estandar BPMN.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
34 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SECCIÓN III – ESTRATEGIA PROPUESTA
En esta sección se presenta la descripción de la estrategia propuesta mediante la que se
propende remplazar en SCRUM las historias de usuario, resultantes de la aplicación de la
técnica inception deck, por modelos de proceso de negocio BP.
La técnica de inception deck, como se ha mostrado en secciones anteriores de este
documento, es una técnica muy completa que permite elicitar requisitos de manera clara
y concisa mediante la unficiación de los puntos de vista de todos los interesados en una
presentación esquematica detallada de la solución. En este punto, es donde la inclusión
de modelos de porcesos de negocio tiene mayor relevancia. Por tanto lo que busca este
trabajo es mejorar la calidad de la información elicitada y para ello se deben aplicar
métricas que permitan medir el reproceso, número de requisitos aprobados e incremento
de la velocidad del equipo, todo ello en comparación de proyectos que utilizan
unicamente las historias de usuario en lugar de modelos de proceso BP.
9. ESTRATEGÍA PROPUESTA
La propuesta enfocada en este documento, intenta mantener la unificación de la visión
del producto, recopilada durante el inception deck, a través de una representación visual
con una única forma de interpretación, permitiendo la eliminación de la ambigüedad
inherente a las historias de usuario escritas en lenguaje natural. De esta manera se logra
no solamente mantener la visión completa de la técnica inception deck en un medio de
persistencia de la información más claro sino que también se mejora el nivel de
comunicación de todos los participantes del proyecto propendiendo esto a una mejora
directamente proporcional de la calidad del producto.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
35 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Para poder lograr la definición de la propuesta se hace necesario establecer en la dinámica
7 del Inception deck (mostrar la solución) cuál de las opciones presentadas por [3] será
utilizada. En el caso de ser story mapping la dinámica elegida, se debe establecer la
relación entre y la notación BPMN y cada componente de las historias de usuario, basado
en el modelo propuesto en [6], que está compuesto por la estructura Yo como [Rol], que
permite identificar quien ejecuta la acción, Requiero [una funcionalidad], que permite
identificar el nombre de la funcionalidad de manera clara y diciente a fin de poder
reconocer rápidamente la necesidad a resolver, Para [un motivo], que denota la razón e
importancia de las historias de usuario especificando el valor que trae para el negocio y
los criterios de aceptación de la historia de usuario. A continuación se explica en más
detalle los componentes del modelo expuesto por [6].
9.1 IDENTIFICADOR O ID
Permite enumerar las historias de usuario con un consecutivo que las identifique. Ejemplo
HU-005.
9.2 YO COMO [ROL]
Esta sección de la historia de usuario permite identificar quien ejecuta la acción. Bajo este
enfoque se detalla siempre el rol que realiza la historia de usuario y es obligatorio
indicarlo. Ejemplo Yo, como [Taxista].
9.3 REQUIERO [FUNCIONALIDAD]
En esta sección se detalla el nombre de la funcionalidad requerida, ejemplo autenticación
del sistema. La función principal de esta columna es identificar el nombre de la
funcionalidad de manera clara y diciente a fin de poder reconocer rápidamente que se
requiere. Ejemplo Necesito [Enturnar me en la pista inteligente]
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
36 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
9.4 PARA [MOTIVO U OBJETIVO DE LA FUNCIONALIDAD]
Esta sección permite identificar la razón e importancia de la historia de usuarios
especificando el valor que trae para el negocio. Ejemplo Con la Finalidad de [Poder
prestar el servicio de trasporte].
9.5 CRITERIOS DE ACEPTACIÓN
Describe el contexto del escenario que define un comportamiento detallando lo necesario
para cumplir con la historia de usuario. Ejemplo:
1. El sistema debe permitir al taxista realizar el cambio de estado
2. El sistema debe notificar al taxista de que se encuentra listo para tomar el turno.
3. El sistema debe validar el saldo del taxista y descontar el valor parametrizado.
Entrando ya en detalle, la Tabla 5. Hace una mapeo entre los componentes mencionados
de las Historias de Usuario y los componentes de un modelo de BP en su notación
estándar BPMN:
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
37 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Historia de usuario Notación BP
Yo como [rol] Determina quien
ejecuta la o las
acciones en el
sistema[6]
Determinan las
líneas de división de
las actividades
realizadas por un rol
dentro de un
proceso (Lanes)
Requiero
[funcionalidad]
Describe que
funcionalidad es
requerida.[6]
Son las tareas o
funcionalidades de
programación que
se deben realizar.
teniendo presente la
semántica que viene
dada por el tipo de
elemento ejemplo
tipo de tarea de
usuario, lo que
denota que
involucra interacción
del usuario con el
sistema
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
38 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Para [motivo]
Razón o
justificación del
valor que entrega
la historia.[6]
No aplica
Criterios de
aceptación
Detalla lo
requerido para
construir la historia
de usuario.
Detalla las reglas de
negocio del sistema
Tabla 5 Comparación entre historias de usuario y modelos BP
Aunque Story Mapping es la dinámica más utilizada para construcción de historias de
usuario, cabe aclarar que existen otras actividades posibles a utilizar por el equipo. En el
caso del proyecto Engine, se utilizó la dinámica wireframing, que consiste en un
prototipado base que identifica que pantallas serán utilizadas por que roles y que
funcionalidades hay por pantalla, esto va acompañado de la explicación de quien está
diagramando la pantalla. Lo anterior no requiere ninguna preparación extra, dado que en
ambos casos el equipo construye los modelos de BP para ser expuestos al cliente,
explicando en la lectura los símbolos utilizados de acuerdo al estándar BPMN, lo que es
también a otra de las dinámicas expuestas por la técnica de inception deck que se
denomina let’s make it flow.
A modo explicativo se toma como referencia el proyecto Engine. De acuerdo a la
descripción entregada por la empresa, la plataforma Engine, es un intermediario entre
empresas que tienen necesidades de contratar desarrollo de productos de software a la
medida, este rol se le denomina contratante y empresas que ofrecen los servicios de
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
39 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
desarrollo a la medida denominados proveedores. Por lo anterior los tres procesos
principales de la plataforma son: publicar una necesidad del contratante para recibir
ofertas de los proveedores, revisar la necesidad del contratante por parte del consultor
comercial para hacer el empalme con los proveedores y enviar una propuesta al
proveedor. De acuerdo a lo expuesto en la dinámica 7 del inception deck, que recibe el
nombre de mostrar la solución; utilizando wireframing, se determinó todas las pantallas
del sistema, la interacción entre las mismas y los roles que tienen acceso a la pantalla, por
lo que con esta información se puede de manera más ágil construir los modelos de
proceso o BP. Por lo anterior, se expone en la Figura 8 uno de los procesos del aplicativo a
modo de detallar los resultados obtenidos al aplicar la técnica.
Figura 8 registro y recepción solicitudes del contratante, proyecto Engine.
Cada actividad propia del modelo de BP fue identificada de acuerdo a las actividades
principales del proceso mediante el wireframing expresado por los involucrados en la
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
40 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
técnica. Posterior a esto el equipo tiene 2 días para realizar los BP, exponerlos al cliente e
iniciar las etapas siguientes del proceso de desarrollo.
10. INCLUSION DE MODELOS BP EN SCRUM
Las metodologías y frameworks agiles en general, presentan un ciclo de vida iterativo
incremental [7]. Dentro de este ciclo las etapas están definidas como: análisis, diseño,
construcción, pruebas y finalmente despliegue. De lo anterior es importante recalcar que
tanto el análisis, como la calidad son transversales a todo el proceso y constantemente
hacen parte del proceso de mejora continua.
Tomando en cuenta lo mencionado, y el mapeo a la notación de los modelos BP expuesto
anteriormente, es necesario detallar como está inclusión puede presentar mejoras
significativas al framework de desarrollo ágil SCRUM incrementando la eficiencia del
análisis de requisitos, lo que será expuesto en este documento a continuación.
10.1 ANALISIS DE SOFTWARE Y UNIFICACION DE LA VISION DEL PRODUCTO
Durante el proceso de elicitación de requisitos realizado en la técnica inception deck, los
interesados del proyecto, junto al equipo de desarrollo, modelan de manera genérica todo
lo necesario para realizar su proyecto. Este modelado casi siempre termina en un mapa de
historias de usuario. El objetivo de este mapa de historias responde a la necesidad de
plasmar en algún medio la unificación de la visión del producto realizada durante la
aplicación de la técnica. El nivel de detalle a este punto es mínimo. Las historias
recopiladas se denominan épicas, debido a que su amplitud en los criterios de aceptación
es poco. Al incluir los modelos de procesos en lugar de las historias de usuario en esta
etapa de consolidación de la información en un medio formal, se obtiene un detalle
mucho más alto, debido a que el modelamiento requiere una comprensión global del
proceso más detallada, permitiendo ver la priorización de historias de acuerdo a su
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
41 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
dependencia, la posibilidad de la eliminación de dependencias anexas a los procesos, la
independencia de ciertos casos, la necesidad real de las funcionalidades. Todo esto
adicionalmente permite delimitar lo que se puede lograr dentro de un sprint.
10.2 PLANIFICACION BASADA EN LOS MODELOS DE NEGOCIO
Como se mencionó en el punto anterior, el tener una visión global del proceso que detalla
el uso de la solución tecnológica y sus distintas funcionalidades permite identificar
rápidamente las relaciones de dependencia, tomar decisiones sobre que funcionalidades
requiere el cliente afrontar con mayor prioridad, que se hará en caso de tener relaciones
de superposición, de composición o de orden, además de poder identificar de manera
muy rápida que se alcanza a realizar en un sprint de acuerdo al compromiso del equipo y
la estimación de las actividades. Adicionalmente los riesgos son más fáciles de identificar y
darles un seguimiento temprano.
Una vez el equipo tiene los modelos de proceso, se procede a realizar la descomposición
de actividades de desarrollo por cada uno de los diagramas obtenidos para ser puestas en
el tablero SCRUM y generando la planeación a ejecutar por sprint. Esto se realiza sin la
necesidad de creación de historias de usuario gracias a que los modelos BP permiten
visualizar todas las funcionalidades a realizar, los roles que interactúan entre
funcionalidades, las dependencias y las reglas de negocio, por lo que el equipo de
desarrollo puede identificar todas las actividades a realizar entorno a una tarea del
modelo. Tomando como muestra la tarea login del modelo BP de la Figura 8, la
descomposición de las actividades de desarrollo para esta tarea se ve reflejada en la tabla
3. Esto facilita al equipo de desarrollo detectar todo el trabajo a realizar durante el
proyecto. De la misma manera se realizó la descomposición para cada una de las
actividades presentes en el modelo de la figura indicada.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
42 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Tarea Actividades de desarrollo
Login 1. La pantalla deberá contar con el título (Agile Illusions) 2. La pantalla deberá contar con un campo para Ingresar el Nombre
del Usuario 3. La pantalla deberá contar con un campo para Ingresar la
Contraseña 3.1. La información del campo de contraseña deberá ser visible solo
con el carácter (•) 4. La pantalla deberá contar con un botón para acceder al sistema,
una vez el usuario presione este botón el sistema deberá realizar las siguientes validaciones: 4.1. El campo Usuario debe estar diligenciado (No puede ser vacío)
en caso de que no se cumpla el sistema debe generar el siguiente mensaje (Intento de conexión no exitoso. Por favor ingrese el usuario)
4.2. El campo Contraseña debe estar diligenciado (No puede ser vacío) en caso de que no se cumpla el sistema debe generar el siguiente mensaje (Intento de conexión no exitoso. Por favor ingrese la contraseña)
4.3. El Usuario y la Contraseña deben corresponder a un registro válido en la BD en caso de que no se cumpla el sistema debe generar el siguiente mensaje (Intento de conexión no exitoso. Usuario o Contraseña inválido).
5. Los campos de texto y botón deberán contar con los tooltips correspondientes.
Tabla 6 Descomposición de actividades de desarrollo tarea login a partir de modelo BP
Lo anterior no afecta la estimación por poker scrum dado que ahora los equipos estimaran
todas las actividades puntuales de cada tarea del modelo BP lo que se asemeja a conocer
los criterios de aceptación de la historia de usuario una vez la historia este plenamente
refinada. Esto presenta una mejora en la información requerida para la estimación y
presenta una menor posibilidad de generar desfase en los compromisos adquiridos con
quien solicita el proyecto.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
43 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SECCIÓN IV. MÉTODO DE INVESTIGACIÓN
PARA DEFINIR LA ESTRATEGIA PROPUESTA
En esta sección se realiza el planteamiento del método de investigación seguido,
mediante la formulación de hipotesis y métricas que permitan evaluar los resultados
obtenidos y realizar conclusiones al respecto.
11. HIPÓTESIS
Para lograr realizar una comparación adecuada entre el proceso de elicitación de
requisitos sin modelado de procesos de negocio y con su inclusión dentro del uso del
framework SCRUM, se plantearon las siguientes hipótesis, lo que permite constatar si la
investigación encuentra resultados favorables o no:
1. El número de requisitos finales aprobados por el cliente en primera revisión de
refinamiento es mayor con la inclusión de modelos BP.
2. El número de requisitos finales aprobados por el cliente en primera revisión de
refinamiento es menor con las historias de usuario.
3. La aparición de nuevos requisitos disminuye cuando el proceso de elicitación se
consolida a través de modelos BP.
4. La aparición de nuevos requisitos aumenta cuando el proceso de elicitación se
consolida a través de modelos historias de usuario.
5. El porcentaje de modificaciones a las actividades planeadas durante el sprint planning
es menor con la inclusión de modelos BP.
6. El porcentaje de modificaciones a las actividades planeadas durante el sprint planning
es mayor con la inclusión de modelos BP.
7. El porcentaje de tareas de desarrollo realizadas que cumple con los criterios de
aceptación del cliente, es mayor con la implementación de BP en comparación a las
desarrolladas con historias de usuario.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
44 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
12. DISEÑO DE LA INVESTIGACIÓN
Para comprobar las hipótesis planteadas sobre la eliminación de la ambigüedad en el
resultado obtenido por un proceso de elicitación bajo la técnica inception deck,
remplazando las historias de usuario por modelos de BP, se aplica el planteamiento de
[18] y de [7] definiendo de esta manera las siguientes métricas a ser comparadas en el
desarrollo de varios proyectos:
1. Nuevos requisitos: Número de requisitos que surgieron en etapas posteriores a
la elicitación, en las etapas de análisis, especificación o validación de los
mismos[18].
2. Reproceso en la elicitación: Cantidad de veces que se tuvo que relevar requisitos
del mismo stakeholders [18].
3. Requisitos refinados: Número de requisitos modificados después de elicitados.
[18].
4. Requisitos no identificados: Cantidad de requisitos no identificados durante el
proceso de elicitación [18] .
5. Calidad de los requisitos: Incidencias, defectos encontrados por el cliente o
usuarios del producto según criticidad [7].
A continuación la Tabla 7. Muestra la correlación existente entre las metricas planteadas y
las hipotesis de la investigación
Metrica Hipotesis relacionadas
Nuevos requisitos Corresponde a la comprobación de la
hipótesis 1, 2, 3 y 4.
Reproceso en la elicitación Corresponde a la comprobación de la
hipótesis 3, 4, 5 y 6.
Requisitos refinados Corresponde a la comprobación de la
hipótesis 3, 4, 5 y 6.
Requisitos no identificados Corresponde a la comprobación de la
hipótesis 3, 4, 5 y 6.
Calidad de los requisitos corresponde a la comprobación de la
hipótesis 7 Tabla 7 Correlación métricas e hipotesis de la investigación
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
45 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
13. PROYECTOS ANALIZADOS
Para la realización de la investigación y la comprobación de los resultados, se revisaron los
sigueintes proyectos: Pistas inteligentes sistema de automatización del servicio solicitudes
de taxis en centros comerciales, eps y universidades en la ciudad de Cali con una
compañía reconocida del mercado, GesDos Web, Sistema de gestión documental y
recepción de placas para medición de impacto radiológico, Escalafón Docente sistema
para la clasificación del perfil del docente dentro de la escala laboral de las universidades,
Reserva de Espacios Físicos y Recursos-REF sistema en el que se permite a través de una
aplicación móvil solicitar la reserva de salones, salas de sistema e implementos necesarios
para las clases a nivel universitario y el proyecto Engine, que es una plataforma para
impulsar la industria de software a nivel nacional.
14. MUESTRA Y RESULTADOS
Para la explicación de la técnica, se toma como referentes principal el proceso de
elicitación de requisito en el proyecto de pistas inteligentes.
De acuerdo a la descripción entregada por la empresa, las pistas son lugares donde los
vehículos se parquean para recoger pasajeros que soliciten el servicio. En estas pistas, hay
personal coordinando esta actividad dado el alto tráfico de usuarios, estas personas
reciben el nombre de despachadores. La labor de los despachadores es registrar la placa
del vehículo que brinda el servicio de transporte, la hora y la dirección destino para
brindar seguridad el usuario del servicio.
Como parte de la mejora continua, característica fundamental del servicio de la compañía,
se busca realizar la optimización de este proceso mediante la implementación de un stand
o modulo físico que contenga una tablet en la que mediante una aplicación se pueda
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
46 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
realizar de manera sistematizada la solicitud de turnos directamente por parte del
usuario, como refleja el modelo de la Figura 7. En complemento, para poder realizar la
sistematización completa del proceso de las pistas inteligentes, se debe tener una
aplicación móvil de turnos que permita a los conductores recibir la notificación de
asignación de un servicio a su vehículo y que al recoger al pasajero, el conductor pueda
indicar que sale de la pista porque su estado pasa a ser en carrera (dado que está
atendiendo una solicitud), así mismo al terminar la carrera y retornar a la pista podrá
regresar a su estado inicial de disponible para recibir solicitudes de servicio.
Finalmente se consideró necesario un módulo que permita realizar cierto tipo de
administración propia de las reglas de negocio del proceso de la empresa como es el
manejo de históricos, las sanciones a los conductores y el manejo de anomalías, a través
de una aplicación Web.
Por lo anterior, se aplicó la técnica inception deck con el product owner designado y un
líder técnico de la empresa, además de contar con la participación del equipo SCRUM de
manera que se pudiera unificar la visión del producto y realizar un desarrollo a la medida,
práctico y ajustado a las necesidades de la empresa.
La técnica se ejecutó como indica [3], en el paso de mostrar la solución se realizó la
actividad hagámoslo fluir, donde se modelo cada uno de los procesos e iteraciones del
usuario con la herramienta, identificando cambios potenciales, mejoras e incluso puntos
que no se habían detectado que presentaban inconvenientes desde el análisis inicial por
parte del cliente y previo al inicio de este proyecto, que ahora son susceptibles de ser
optimizados. Una vez esto fue realizado, se persiste la información recopilada no en el
artefacto denominado historias de usuario sino en los modelos de procesos de negocio
(BP) a través de la notación BPMN, lo que al equipo le permite que no sea necesario
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
47 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
generar historias de usuario para realizar la descomposición en actividades de desarrollo,
sino directamente pasar a generar estas actividades por cada flujo y ponerlas en el tablero
scrum para iniciará actividades.
Para realizar el modelamiento inicial con el cliente durante la reunión de Inception deck,
no es necesario un conocimiento previo en BMPN, basta con que los usuarios puedan
diagramar un flujo de trabajo básico en un tablero, de manera que el equipo se encarga
de la transcripción de los modelos resultantes a la notación estándar de modelado de
procesos BPMN, la cual es una notación que facilita describir los pasos lógicos de un
proceso por medio de un estándar visual ya definido.
Posterior a la explicación, se procedió a identificar los roles, los procesos y finalmente las
actividades que más adelante serán detallas. Los roles definidos para este proyecto son
sólo tres, el primero es el usuario quien interactuará en un proceso de solicitud de
servicio, el segundo es el taxi para quien se diseña el sistema que permite asignar turno,
recibir servicio e iniciar servicio y el tercero es el administrador a quien se le genera una
interface web que permite gestionar los datos históricos, las configuraciones base para el
aplicativo y el seguimiento a todos los servicios, como se muestra en la Figura 7 a
continuación.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
48 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Figura 9 Proceso de solicitud del servicio de taxis desde el stand por parte del usuario.
Como paso siguiente, se detallan los procesos de solicitud de servicio por parte del
usuario, recepción de la solicitud por parte del taxista y finalmente el proceso que realiza
el administrador frente a las configuraciones básicas del sistema y manejo de anomalías
del proceso de solicitud de taxis. Todo esto de la mano del cliente quien valida en el
mismo momento si el flujo del proceso es el adecuado para cada caso.
El tiempo total del inception deck fueron 4 horas (para este proyecto). De este tiempo se
dedicaron 2 horas completamente al tema de modelado. Cada actividad propia del
modelo BP fue identificada de acuerdo a las actividades principales del proceso.
Una vez el equipo tiene todos los modelos de proceso del proyecto, procede a realizar la
descomposición de actividades de desarrollo por cada uno de los diagramas obtenidos
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
49 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
para ser puestas en el tablero SCRUM y reflejar la planeación a ejecutar por sprint. Esto se
realiza sin la necesidad de creación de historias de usuario. Lo anterior se justifica en que
los modelos de proceso de negocio me permiten visualizar todos los procesos,
interacciones, roles y reglas de negocio del sistema, por lo que directamente el equipo
puede entrar a identificar qué actividades debe realizar para construir las funcionalidades
requeridas.
Cuando se preguntó al equipo de trabajo de cada proyecto, la percepción de todos sus
integrantes es que fue mucho más claro el detalle sobre que había que realizar para
cumplir los compromisos por cada sprint al contar con la ayuda de los modelos de proceso
de negocio (BP) construidos, en comparación con su experiencia en trabajos previos sobre
la información detallada a nivel de historias de usuario, por la facilidad de interpretar la
información, ver las validaciones implícitas en el proceso y las acciones a seguir por
funcionalidad de acuerdo al flujo del proceso.
Lo anterior apunta a que al remplazar el lenguaje natural por lenguaje de notación gráfica,
debido a que a atreves de los modelos de BP solamente existe un modo de interpretar
dicha información, evitando confusiones en la transferencia de conocimiento del cliente al
equipo y mejorando la comunicación entre todos los involucrados.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
50 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
PARTE V – RESULTADOS Y ANÁLISIS
Para poder determinar si la propuesta tiene un impacto relevante en los procesos de
desarrollo de software, específicamente en la elicitación de requisitos, se hace necesario
confrontar las métricas estipuladas en el capítulo anterior versus los resultados obtenidos
al aplicarlas sobre los proyectos de estudio.
A continuación se expondrán los resultados y su interpretación.
15. VALIDACIÓN DE HIPÓTESIS
Las métricas de identificación de nuevos requisitos, reproceso en la elicitación, requisitos
refinados y requisitos no identificados fueron aplicadas a los siguientes proyectos:
Pistas Inteligentes, con un total de 26 requisitos elicitados.
GesDos, con un total de 160 requisitos elicitados.
Escalafón docente, con un total de 41 requisitos elicitados.
Ref, con un total de 15 requisitos elicitados.
Engine, con un total de 20 requisitos elicitados.
El detalle de estos resultados se presenta en la tabla 4.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
51 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Métrica Pistas
………. Inteligentes
GesDos Escalafón Docente REF Engine
Nuevos requisitos 1 20 0 2 0
Reproceso en la
elicitación
0 0 0 0 0
Requisitos refinados 0 10 0 0 0
Requisitos no
identificados
0 0 0 0 0
Tabla 8 Requisitos Elicitados, modificados y adicionados por proyecto
La Tabla 4 muestra el impacto de la aplicación de la técnica para los proyectos evaluados
en comparación con las técnicas tradicionales (en las que el refinamiento de los requisitos
elicitados es evidenciado constantemente). Aquí, los resultados indican que el
refinamiento innato de la elicitación tiende a ser nulo y solamente en un caso particular,
proyecto GesDos que es una migración de un aplicativo de escritorio a entorno web y no
un desarrollo desde cero como en los otros casos, se presenta refinamientos de 10
requisitos en total. Hasta antes de la migración de esta aplicación, GesDos esta soportado
por un proceso desactualizado que no responde a todas las necesidades del proceso
actual de la compañía que contrata la migración, delegando así muchas labores a
actividades manuales, que generan perdida de información valiosa para los reportes de la
compañía a entidades reguladoras del servicio. Con el uso del inception deck + BP, se logra
identificar mejoras no solo del proceso, sino también del aplicativo, no tomadas en cuenta
en el momento en que se construyó la primera aplicación.
Estas mejoras del aplicativo y del proceso son reflejadas en 20 nuevos requisitos que
optimizan la operación de la compañía y en la actualización de 10 requisitos
desactualizados que ya no respondían a las necesidades operativas de la empresa, como
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
52 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
se mencionó anteriormente. Por otra parte, de los resultados obtenidos entiende que el
surgimiento de nuevos requerimientos es mínima para los demás proyectos y surgen por
necesidades nuevas del negocio (factores de ley como en taxis libres o factores de normas
internas de la empresa que han cambiado como en el caso de REF)
Por último, en la Tabla 4. Se indica que no hay requisitos sin ser identificados para ningún
proyecto, demostrando la efectividad de la técnica para recopilar la información.
Lo anterior permite reflejar el impacto de la elicitación de requisitos a través de la
combinación de los modelos BP con la técnica de inception deck cumpliendo el objetivo
fundamental de realizar entregas de valor a los clientes como expresa [4], además de
cumplir con la resolución de la pregunta de investigación y poder elaborar un método
para la elicitación de requisitos basado en Inception deck y modelos BP, que mejore el
proceso de elicitación.
Por otra parte, al revisar la métrica 5, referente a la calidad presente en los proyectos, se
evidencia que el reporte de no conformes con respecto a los requisitos elicitados presenta
valores mínimos. Estos valores son recopilados en la fase de pruebas de aceptación sprint
a sprint hasta terminar el proyecto. Lo anterior permite identificar el alto impacto que
tiene la elicitación de requisitos a través de modelos de PB sobre la calidad del producto
durante cada uno de los sprints que conforman el producto final, cumpliendo así, con el
objetivo propuesto por [14] de hacer entregas de valor a los clientes.
Es importante resaltar que además de los beneficios mencionados anteriormente, la
mejora del proceso de análisis de requisitos repercute directamente en la calidad de los
proyectos de software, incrementándola significativamente. La tabla 9, hace una
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
53 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
representación de la medición de calidad obtenida posterior a la finalización de cada
proyecto.
No Conformes
por Tipo
Pistas
Inteligentes
GesDos Escalafón
Docente
REF Engine
Bajo 2 7 3 2 0
Medio 0 1 0 3 0
Alto 0 0 0 0 0
Total NCs 2. 8 3 5 0
Tabla 9 . Reporte consolidado de no conformes por proyecto evaluado
Esta medición permite identificar en una escala de alto, medio y bajo impacto, la
ocurrencia de no conformes en cada proyecto, siendo GesDos el que más no conformes
presenta con un total de 8, clasificados en 7 de bajo impacto y 1 medio. La tendencia de
no conformes de tipo alto, que normalmente son errores de tipo bloqueante, en todos los
proyectos es de cero y en los casos de no conformes de tipo medio solamente en dos
proyectos se presentan con un índice muy bajo. Lo anterior se relaciona directamente con
la capacidad del equipo de desarrollo de asimilar las necesidades del proyecto expresadas
por el cliente a través del método propuesto.
16. CONCLUSIONES
La utilización de la técnica inception deck permite generar una visión unificada del
proyecto, orientada a las entregas de valor. Los modelos de BP son un complemento para
mantener la información recopilada por la técnica en un artefacto cuya interpretación es
única, disminuyendo así la posibilidad de que queden requisitos sin elicitar, o que el
porcentaje de requisitos modificados o adicionados posterior a la ejecución de la técnica
sea alto.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
54 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
Es importante resaltar que la propuesta pone en evidencia de manera rápida si el proceso
que será apoyado por la herramienta está o no lo suficientemente actualizado o si
requiere mejoras de algún tipo para ser implementadas mejorando la operación de la
empresa. Tal es el caso del proyecto GesDos web cuyos requisitos ya existen y requieren
ser trasladados de tecnología y en donde la técnica ayuda a evaluar las necesidades de
optimización a las funcionalidades que se han desactualizado por el avance del proceso de
la empresa sin hacer ajustes nivel del aplicativo. Gracias a la propuesta de inception deck
con modelos de BP, el equipo apoya al cliente en la identificación de la inclusión y
modificaciones de funcionalidades.
Adicionalmente el método propuesto apoya el ciclo de desarrollo y la labor que realizan
los equipos al disminuir considerablemente el reproceso producto de la ambigüedad
innata de las historias de usuario, al remplazar dicho artefacto por modelos BP. Al realizar
una mejor consolidación de la información elicitada, es más claro para el equipo el
referente de que hay que hacer hablando en términos funcionales, como esto afecta a la
relación con otras funcionalidades, que roles interactúan y que restricciones hay, todo
esto gracias a que los modelos BP, muestran el contexto completo del proceso y no solo
las funcionalidades requeridas. Adicionalmente el impacto sobre la calidad es
directamente proporcional a la mejora del proceso de elictación, lo que incrementa las
posiblidades de éxito de los proyectos. Adicionalmente esto impacta de manera
significativa la inversión realizada para la construcción de cada proyecto, debido a que
entre menos reproceso y refinamiento sea necesario, menor será el tiempo y dinero
involucrado en el proceso de desarrollo.
Es importante resaltar que dentro del aporte realizado por esta investigación, el perfil
profesional del autor se incrementa considerablemente no solo al incluir este método en
la industria a través de su proyecto de emprendimiento, sino también al poder compartir
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
55 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
con la comunidad internacional los resultados de la misma, obteniendo reconocimiento
por parte de eventos de renombre y publicación en revistas indexadas.
Por otra parte, la planeación y estimación en SCRUM, que es realizada con el método
póker scrum, no presenta ningún cambio drástico, la única diferencia es que ya no se
estiman historias de usuario sino actividades de desarrollo, por lo que no requiere ser
remplazada por otra técnica.
Para trabajos futuros es posible profundizar en el tema de estimación en SCRUM bajo la
técnica POKER SCRUM revisando la variación en la exactitud de la estimación cuando se
presenta el cambio de historias de usuario por modelos de procesos de negocio y sin el
cambio.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
56 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
SECCIÓN IV – BIBLIOGRAFÍA
17. REFERENCIAS BIBLIOGRÁFICAS
[1] S. Hastie and S. Wojewoda, “Standish Group 2015 Chaos Report - Q&A with Jennifer
Lynch,” http://www.infoq.com/articles/standish-chaos-2015, 2015. [Online].
Available: http://www.infoq.com/articles/standish-chaos-2015.
[2] J. Rasmusson, The Agile Samurai–How Agile Masters Deliver Great Software. 2010.
[3] Enrique Comba Riepenhausen, “Inception Starting a New Project.” .
[4] M. Fowler and J. Highsmith, “The agile manifesto,” Softw. Dev., vol. 9, pp. 28–35,
2001.
[5] Á. Medinilla, “Retrospectives and Kaizen Events,” in Agile Kaizen: Managing
Continuous Improvement Far Beyond Retrospectives, 2014, pp. 37–58.
[6] M. Cohn, User Stories Applied: For Agile Software Development (Addison Wesley
Signature Series), vol. 1, no. 0. 2004.
[7] R. S. Pressman and D. Ph, Ingeniería del software. .
[8] T. Arao, E. Goto, and T. Nagata, “‘Business process’ oriented requirements
engineering process,” 13th IEEE Int. Conf. Requir. Eng., pp. 395–399, 2005.
[9] K. Decreus, G. Poels, M. El Kharbili, and E. Pulvermueller, “Policy-enabled goal-
oriented requirements engineering for semantic business process management,”
Int. J. Intell. Syst., vol. 25, no. 8, pp. 784–812, 2010.
[10] K. Decreus, M. El Kharbili, G. Poels, and E. Pulvermueller, “Bridging requirements
engineering and business process management,” Gi-Edition. Proceedings-Lecture
Notes in Informatics, p. 215, 2009.
[11] R. S. Kenett, “Implementing SCRUM using Business Process Management and
Pattern Analysis Methodologies,” Dyn. Relationships Manag. J., vol. 2, no. 2, pp. 29–
48, 2013.
Maestría en Ingeniería de Software Facultad de Ingeniería Universidad San Buenaventura de Cali
57 Un Método de Elicitación de Requisitos Para SCRUM Compuesto Por Inception Deck y Modelos de Proceso de Negocios
(BPMN). Manuel Alejandro Pastrana Pardo, Hugo Armando Ordoñez Erazo (Director)
[12] IEEE, “IEEE 24765-2017 - ISO/IEC/IEEE International Standard - Systems and
software engineering--Vocabulary” IEEE 24765-2017 - ISO/IEC/IEEE International
Standard - Systems and software engineering--Vocabulary, 2017.
[13] IEEE, “IEEE Std 830-1998, revisión 22 de Octubre de 2008,” Especificación Requisitos
Softw. según el estándar IEEE 830, p. 19, 2000.
[14] K. Beck, Extreme Programming Explained: Embrace Change, no. c. 1999.
[15] R. Jeffries, A. Anderson, and C. Hendrickson, Extreme Programming Installed. 2001.
[16] M. Blom, “Is scrum and XP suitable for CSE development?,” in Procedia Computer
Science, 2010, vol. 1, no. 1, pp. 1511–1517.
[17] A. Ottensooser, A. Fekete, H. A. Reijers, J. Mendling, and C. Menictas, “Making
sense of business process descriptions: An experimental comparison of graphical
and textual notations,” J. Syst. Softw., vol. 85, no. 3, pp. 596–606, 2012.
[18] N. Andriano, “Comparación del Proceso de Elicitación de Requerimientos en el
desarrollo de Software a Medida y Empaquetado . Propuesta de métricas para la
elicitación .,”
http://postgrado.info.unlp.edu.ar/Carreras/Magisters/Ingenieria_de_Software/Tesi
s/Andriano_Natalia.pdf, 2006.