Un Método de Elicitación de Requisitos Para SCRUM Compuesto...

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.




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




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




Í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




Í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




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.




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.




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].




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%




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.




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




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




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]




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.




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.




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




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




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.




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.




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:




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.




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].




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

https://www.youtube.com/watch?v=IWUG29VPhUA&t=78s




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.




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




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




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.




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.




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




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




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




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.




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.




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.




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]




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:




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




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




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




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




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.




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.




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.




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


Requisitos refinados Corresponde a la comprobación de la


Requisitos no identificados Corresponde a la comprobación de la


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




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




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




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.




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




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.




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.




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




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




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.




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




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.




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.




[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.

Un Método de Elicitación de Requisitos Para SCRUM Compuesto...

Documents

Transcript of Un Método de Elicitación de Requisitos Para SCRUM Compuesto...