Está en la página 1de 24

INGENIERÍA DE REQUERIMIENTOS BAJO UN ENFOQUE ÁGIL INTEGRANDO TÉCNICAS DE

USABILIDAD

I. Introducción

En la actualidad, existe un incremento del uso de metodologías


ágiles en la gestión y desarrollo de proyectos por las
organizaciones de la industria del software. Su selección está
fundamentada en gran medida, a la facilidad de adaptabilidad que
proporcionan. Esto no implica que los proyectos estén siendo
gestionados de manera correcta, ni que dichas metodologías
proporcionen a los miembros de equipos de desarrollo todas las
facilidades que podrían tener para gestionar los proyectos
perfectamente y sin errores. Informes como CHAOS del proyecto,
indican precisamente que, a pesar de todo, aún se están
cometiendo errores fatales, que comprometen el correcto
desempeño del proyecto, y en algunos casos, su propia
continuidad.

Adicionalmente se ha demostrado que una cifra apreciable de los


inconvenientes que se tienen en los proyectos de software es en
gran medida en torno a los requerimientos. Una incorrecta
obtención, análisis, especificación, validación, y gestión de éstos,
aumenta los riesgos y podría volver inmanejable al proyecto, sin
importar si se esté utilizando metodologías ágiles o tradicionales.
Una Ingeniería de Requerimientos (IR) formal gasta mucho
tiempo, y con la creciente necesidad de un software adaptable a
cambios, las metodologías ágiles han obtenido gran popularidad.
En este tipo de metodologías, se considera que es mejor dedicar
más esfuerzos y recursos a la elaboración propia del producto, y
no sólo a las fases iniciales del proyecto. Por lo tanto, se asume
que la simplicidad en las tareas es un factor fundamental a la hora
de desarrollar software.

Parte de esta simplicidad consiste en la reducción de la formalidad


que implica el proceso de IR, dedicando más esfuerzo a la creación
de software funcional por medio de una fuerte comunicación con
el cliente. Sin embargo, al no ser este tipo de metodologías lo
suficientemente formal, algunos elementos no se encuentran
claramente separados e identificados, provocando dificultades en
el futuro cuando se necesite algún producto propio de estos
procesos (problemas con la trazabilidad de requerimientos y/o
subproductos generados).

Con el paso del tiempo se han observado algunos cambios y


tendencias en la forma de desarrollar software, y esto no solo
incluye metodologías de desarrollo, sino también todo lo referente
a la IR. Por otro lado, el avance tecnológico y la búsqueda por
cumplir las diferentes expectativas referentes a las comunicaciones
y a los nuevos mercados, hacen que el nuevo software a
desarrollar deba ser más competitivo.

Teniendo en cuenta este contexto de continuo cambio, se han


observado diferentes tendencias que cada vez son más fuertes.
Algunas se podrían relacionar con el fortalecimiento de las
Metodologías Ágiles por medio de un uso más amplio de la IR en
proyectos de desarrollo, lo que genera una mayor –y más fácil—
integración en proyectos futuros. Además, existe un creciente
interés de las organizaciones por la aplicación de métodos y
técnicas de usabilidad en el proceso de desarrollo de software. Es
por ello que seleccionar y poner en práctica aquellas técnicas que
más se adecuan a las características de un determinado proyecto
es una tarea compleja y con un soporte bajo.

En este artículo se presenta brevemente una guía desarrollada


para la Ingeniería de Requerimientos siguiendo un enfoque ágil
que contribuye a disminuir el tiempo y a aumentar la satisfacción
del cliente con la incorporación de técnicas de usabilidad desde
los inicios del desarrollo. Está fundamentada en la necesidad
existente de propuestas que posibiliten crear una visión holística
que contraste los métodos formales de la IR con las metodologías
ágiles y el Design Thinking, logrando ser eficaces en la
identificación y satisfacción de las necesidades de los clientes.

II. Marco teórico – metodológico

A. Ingeniería de Requerimientos

La Ingeniería de Requerimientos corresponde a un proceso


sistemático para el descubrimiento, desarrollo, trazabilidad,
análisis, clasificación, comunicación y Gestión de Requerimientos,
el cual define un sistema en niveles sucesivos de abstracción.
Dicho proceso busca fundamentalmente facilitar las tareas que
soporten los demás procesos de negocio al interior de una
organización, y como todo proceso, sirve de entrada y salida para
muchos otros.
B. SCRUM

Considerado como el método ágil más popular, Scrum es un


framework iterativo e incremental para proyectos y productos o
desarrollo de aplicaciones, que se desarrolla en ciclos de trabajo
llamados Sprints. Scrum no es un proceso o técnica para construir
productos; sino un marco de trabajo dentro del cual se pueden
emplear varias técnicas y procesos. Por ello consta de 3 elementos
fundamentales para su desarrollo, el Scrum Team, los Eventos de
Scrum, y los Artefactos de Scrum.

C. Kanban

Si bien Kanban no es un método para el desarrollo de software,


sino para la gestión de proyectos, poco a poco se ha ido
adaptando a los proyectos de esta industria. Esta metodología de
gestión, tiene como base fundamental los principios de Lean, y
presenta su practicidad en el uso de tarjetas para modelar
actividades, las que se usan comúnmente para identificar
necesidades de material en la cadena de producción.

Kanban sugiere sistemas de producción altamente efectivos,


regidos por algunos principios — que reflejan que su origen viene
de Lean— y que, dependiendo el autor, pueden variar, pero aun
así, mantienen la esencia. Los principios Kanban son:

 Calidad garantizada.

 Reducción de desperdicio.

 Mejora continua.

 Flexibilidad.
Algo fundamental en este método es el uso de un tablero de
tareas para mejorar el flujo de trabajo durante el proyecto.

En la actualidad este “sistema de producción altamente eficiente y


efectivo”, se ha venido implementando para la gestión de
proyectos de desarrollo de software, teniendo principal afinidad
con las Metodologías Ágiles. Como se mencionó anteriormente,
permite gestionar de una manera general la forma en la que se
van completando las tareas, de una manera visual, permitiendo
facilidades a la hora de establecer el estado del proyecto.
Adicionalmente es de fácil utilización, actualización y apropiación
por parte del equipo, por lo que se convierte en una excelente
herramienta para complementar la metodología de desarrollo
seleccionada.

D. Design Thinking

El Design Thinking es un método de trabajo que sirve para generar


ideas disruptivas tomando en cuenta siempre las necesidades
explícitas y latentes del cliente o usuario final. Se trata de un
cambio del pensar a la acción y a diferencia de otros enfoques, el
Design Thinking invita al cliente a tener un rol más activo en el
diseño del producto o servicio. De esta forma se garantiza que
cada cambio que se haga a la idea sea basado en cumplir sus
necesidades. Esto implica que los involucrados dialoguen
mutuamente en empatía, con lo que espera recibir (el cliente) y lo
que se espera diseñar (equipo de proyecto).

Con el objetivo de determinar las necesidades del cliente, es


necesario conocerlo a profundidad, por lo que durante la
recopilación de la información necesaria pueden utilizarse
diferentes técnicas como grupos focales, observaciones y
entrevistas, de manera que se identifiquen de forma clara y precisa
sus necesidades concretas. Por ello el Design Thinking como su
traducción al español lo indica, se centra en el proceso de diseño,
más que en el producto final, e integra conocimientos técnicos del
diseño, las ciencias sociales, la empresa y la Ingeniería. Forma
sólidos equipos multidisciplinares para:

 Adquirir conocimientos básicos sobre los usuarios y


sobre la situación o el problema general (Entender).

 Lograr empatía con los usuarios mirándoles de cerca


(Observar).

 Crear un usuario típico para el cual se está diseñando una


solución o un producto (Definir).

 Generar todas las ideas posibles (Idear).

 Construir prototipos reales de algunas de las ideas más


prometedoras (Prototipar).

 Aprender a partir de las reacciones de los usuarios a los


distintos prototipos (Testear).

Mediante este proceso iterativo, los equipos pueden adquirir una


nueva percepción a partir de la observación continua y la
elaboración de prototipos, y en ocasiones pueden llegar a
replantearse el problema de una manera completamente nueva.
La riqueza del método del Design Thinking se muestra en la etapa
de validación ya que es en este punto donde el cliente, mediante
una participación activa, evalúa los prototipos exhibidos y acepta
aquellos aspectos positivos del mismo; además, rechaza aquellos
aspectos negativos y propone cambios que enriquecen el diseño.
Como resultado final, se obtiene un producto/servicio que
satisface las necesidades latentes del cliente de manera eficaz.

Design Thinking ha sido adoptado por diversos tipos de


organizaciones. Entre los casos de éxitos más citados se
encuentran cómo Intercorp implementó Desgin Thinking a través
de la agencia Ideo para rediseñar los espacios de atención al
cliente de las agencias de Interbank y el diseño y metodología de
enseñanza de Innova Schools.

E. Usabilidad e Interacción Persona Ordenador (IPO)

La Interacción Persona Ordenador (IPO) según la Association for


Computer Machinery (ACM), es la disciplina relacionada con el
diseño, evaluación e implementación de sistemas informáticos
interactivos para el uso de seres humanos, su importancia radica
en la mejora del uso de la computadora como herramienta de
trabajo, ocio y aprendizaje. A través de la IPO se busca
incrementar la satisfacción de los usuarios finales y reducir su
esfuerzo para construir tareas que deben realizar en la
computadora, sin que esto disminuya la capacidad de los usuarios
para desarrollar sus actividades y sus procesos interactivos con el
sistema.

Según la IPO, la interfaz es el punto en el que seres humanos y


computadoras se ponen en contacto, se transfieren mutuamente
tanto información, órdenes y datos como sensaciones, intuiciones
y nuevas formas de ver las cosas. Para el caso, si la interfaz
presenta alguna limitación, esto afectará directamente al usuario
ya que aquello que no sea posible expresar a través de ella
permanecerá fuera del espacio relacional.
Desde esta perspectiva, aunque se tengan en cuenta las
cualidades del "usuario promedio" en muchos casos la interfaz se
convierte en una barrera debido a un pobre proceso de
elaboración del software y una escasa atención a los detalles de la
tarea a realizar. Como resultado, aunque un diseño no puede ser
nunca completamente "libre de barreras", las IPO tratan de
minimizar esta situación colocando sus procesos y herramientas a
favor del usuario.

Iniciando 1998, Diaper indicaba que la usabilidad constituía una de


las principales preocupaciones de las IPO, ya que a través de ella
se integraban los aspectos sociológicos, psicológicos,
ergonómicos, culturales y sociales que debían interactuar para
producir un software de calidad. En la misma línea de
pensamiento, Bevan afirma que las técnicas IPO tienen como
objetivo incrementar el nivel de usabilidad a través de todo el
proceso de creación de un nuevo software, ya que solo de esta
manera se logra que dicho producto sea comprendido, aprendido,
usado y a la vez, sea atractivo para el usuario.

No obstante, aunque todos coinciden en la importancia de la


usabilidad todavía existe un gran desconocimiento entre los
desarrolladores de software sobre estas técnicas, y muchos de
ellos no tienen una percepción clara de cómo y cuándo aplicarlas;
es más, no les resulta cómodo hablar de usabilidad en el campo
de la Ingeniería de Software (ISW). De hecho; para muchos, la
usabilidad solo tiene sentido en la fase funcional, cuando la parte
interna del sistema ya ha sido diseñada.

La dicotomía existente entre pensamiento y ejecución son las que


han mantenido separados por tanto tiempo procesos que desde el
sentido común debían permanecer unidos. Por tanto, buscar
puntos de encuentro entre la ISW y la IPO ha sido el principal
objetivo de muchas organizaciones de desarrollo de software que
quieren aumentar el nivel de usabilidad de sus productos, pero no
están dispuestas a cambiar completamente su proceso de
desarrollo.

Por otra parte, el advenimiento de nuevas tecnologías demanda


también de diseños de sistemas interactivos, donde el usuario se
transforma en parte esencial del proceso, llegando incluso a
proponer al usuario como parte fundamental del equipo de
trabajo. Como era de esperarse, con estas tecnologías emergen
también nuevas necesidades, obligando a la ISW a percatarse de la
importancia de la usabilidad; pues la masificación de los productos
software de alguna manera implica trabajar a favor de un grupo
cada vez más grande de usuarios, con un grupo también cada vez
más amplio de necesidades.

II. Estado actual de la IR en métodologías ágiles

A pesar de los beneficios que brindan las metodologías ágiles, su


proceso de adopción implica grandes retos y según la literatura
revisada también se han presentado varios problemas. En el caso
del desarrollo de software se debe tener mayor cuidado en las
etapas iniciales del proyecto, fundamentalmente durante la IR.

Según Dubakow como principales problemas pueden destacarse:

1) iniciar con una herramienta o un proceso en lugar de conocer


bien la metodología ágil seleccionada, 2) aplicar las prácticas sólo
en actividades de desarrollo, 3) usarla sin considerar además las
técnicas, 4) no solicitar información del cliente, siendo necesario
para la afinación del producto, 5) errores en la especificación de
requerimientos que conllevan a no contar con objetivos claros.
En este sentido se han identificado un conjunto de elementos a
suplir en el desarrollo de nuevas propuestas para la IR entre los
que se destacan: la falta de información como inhibidor principal
de la innovación organizacional, errores en la planificación
adecuada de las actividades de la IR, el no contar con objetivos
claros, la falta de entrenamiento para aprender nuevos métodos y
técnicas, la falta de medición para evidenciar el éxito de la
adopción de las técnicas empleadas, no priorizar conflictos de
requerimientos de usuario, deficiencias en el control y
seguimiento.

Como se puede apreciar, el proceso de adopción de una


metodología de desarrollo de software y fundamentalmente
durante la IR está sujeto a una serie de factores que influyen en los
resultados obtenidos e inciden en el éxito o fracaso de los
proyectos de software.

III. Propuesta de solución

Con el objetivo de contribuir a la solución de los problemas


mencionados anteriormente, la guía que propone el presente
trabajo se basa en la combinación de metodologías ágiles y
activas como SCRUM, Kanban y Design Thinking. Mediante esta
interrelación de actividades se ha logrado plantear la propuesta de
solución que facilita la realización de la IR mediante las iteraciones
de SCRUM, el prototipado del Design Thinking y el control y
seguimiento a través de Kanban.

Para una mejor comprensión, se agrupan las actividades a realizar


en tres procesos fundamentales basado en mejores prácticas
como muestra la Figura 1.
A continuación, serán descritos cada uno de los procesos
propuestos integrando diferentes técnicas de usabilidad. Para
facilitar el proceso de inclusión, Ferre y Baver diseñaron “Usability
planner” una herramienta web para la planificación de técnicas de
usabilidad en el ciclo de vida del software. Su objetivo es dar
soporte a la selección de técnicas y métodos de usabilidad en el
proceso de desarrollo de software minimizando riesgos y
maximizando beneficios.

Definir y Priorizar tareas: En este proceso mediante entrevistas con


el cliente se describen sus necesidades que luego son
transformadas en requerimientos de software. Es importante en
esta etapa identificar elementos propios del entorno, así como
características de los usuarios potenciales del software a
desarrollar. Estos elementos contribuirán a ejecutar
satisfactoriamente el proceso siguiente. En resumen, se propone
identificar las necesidades del usuario y comprender el problema
(Entender).

Seguidamente este listado de necesidades identificadas es


transformado a requerimientos, los cuales serán redactados de
una forma clara y precisa evitando ambigüedades. La lista con los
requerimientos obtenidos, es priorizada teniendo en cuenta cada
una de las tareas propuestas, las cuales conforman el producto de
trabajo comúnmente conocido como Product Backlog.

Diseño y Prototipado: Se puede aseverar que este es uno de los


procesos más importantes, ya que luego de contar con la lista de
los requerimientos, éstos se deben comenzar a diseñar. La etapa
de diseño es una etapa que se compone de varias actividades
importantes. En primer lugar, es necesario clasificar los
requerimientos identificados, así como otorgarles un grado de
prioridad como parte de su proceso de evaluación.

Normalmente para el diseño no existe un patrón a seguir ni una


forma específica de realizarlo. En el caso de la guía que se
propone y aprovechando las ventajas del Design Thinking se
utilizan inicialmente bocetos en papel los que luego son
transformados en mockups, que representan el diseño de las
funcionalidades y son utilizados para la demostración, evaluación
del diseño, promoción, y para otros fines.

Para realizar los bocetos iniciales se recomienda el uso de lápiz y


papel, pues facilita mucho la definición inicial de los bocetos. Es
importante recalcar que cuando se obtienen los requerimientos,
éstos se orientan a pantallas con el objetivo de visualizar la forma
en cómo se verán los diseños, identificando datos de entrada que
luego serán implementados en el front-end del software.
Luego estos bocetos son transformados haciendo uso de
herramientas que facilitan el proceso de prototipado. En el caso de
la guía que se propone, se recomienda utilizar el Balsmiq Mockup
por ser una herramienta ideal para equipos ágiles,
multiplataforma, muy sencilla y utilizada para crear su software por
más de 500000 compañías, entre las que se destacan Apple, Cisco,
Adobe, Tesla, Skype, Sony, entre otras. Además, cuenta con un
portal de soporte y una comunidad de usuarios activa.

Los prototipos generados con esta herramienta son fáciles de


entender y muy atractivos para el usuario. Este último elemento
ayuda mucho durante la validación de los requerimientos. La
salida de este proceso constituye el punto de partida para la
implementación de los prototipos por el Analista-Programador en
la tecnología seleccionada.

Control y Seguimiento: En este proceso se desarrolla un tablero de


Kanban. Este tablero se compone inicialmente de todos los
elementos que se quieren revisar o evaluar. Dentro de estos
tenemos Pendiente, donde se ubica la lista de actividades
definidas a realizar en la etapa inicial y a la cual se desea trazear.
Se agregan tarjetas de cada necesidad y se establecen listas de
chequeo para garantizar su cumplimiento. Posteriormente aparece
otro tablero llamado Haciendo que contiene las actividades en las
que se estén trabajando en el momento.

Seguidamente los participantes o involucrados del proyecto,


pasan sus tarjetas cuando consideran que están listas para la
revisión respectiva a Revisiones, que contiene las que se están
revisando para darlas por aceptadas. En Re-hacer se ubican todas
aquellas que requieren mejora y por último el Done, es lo que ya
pasó por las etapas anteriores y está listo para ponerlo a
producción. En la siguiente figura se ilustra el tablero de Kanban
descrito anteriormente.

Además, en este proceso se realiza de forma iterativa la evaluación


de usabilidad del producto con el uso de diferentes técnicas.

Con la ejecución de cada uno de los procesos descritos se


garantiza la mejora continua como parte del conjunto de acciones
dirigidas a obtener productos de software más usables con la
calidad requerida.

IV. Resultados y discución

El principal resultado de este trabajo es el desarrollo de una guía


para la Ingeniería de Requerimientos siguiendo un enfoque ágil e
incorporando técnicas de usabilidad. Con el fin de comprobar las
bondades que ofrece y para demostrar su aplicación, se
implementó en un proyecto de software real.

Como parte del desarrollo de cada uno de los procesos


propuestos y después de varias reuniones con los clientes para
conocer a fondo sus necesidades se identificaron un total de 45
requerimientos funcionales. En esta fase del proceso fue muy útil
la ayuda de la aplicación “Usability Planner”, con esta herramienta
se construyó la estructura de integración.

Después de procesar la información obtenida se incluyeron dos


grandes actividades: contexto de uso y especificaciones de
usabilidad, identificadas en la parte inferior de la figura siguiente
con los números 1 y 2 respectivamente. A su vez, para el contexto
de uso se tuvo en cuenta tres aspectos, 1) los usuarios, incluyendo
sus conocimientos, experiencia, actitudes, aptitudes, y
necesidades; 2) las tareas, con el fin de conocer qué hace el
usuario y qué dificultades tiene y, 3) el entorno, desde la
perspectiva de lo social-laboral, físico-emocional, y locativo.

Estas actividades podían a su vez ser fácilmente realizadas con la


ayuda de las 4 técnicas de usabilidad señaladas en la parte
superior de la figura: Personas, especificaciones de usabilidad,
escenario de tareas, y perfiles de usuario.

Como parte del proceso de desarrollo se planificaron las


reuniones con frecuencia semanales con la siguiente dinámica:

1. Inicialmente se determina mediante una lluvia de ideas la lista


de actividades que se requieren.

2. Luego se prioriza las actividades para determinar los


requerimientos que, según cronograma se abordarán primero y
cuales después.
3. Se empieza a diseñar el prototipo de como ese requerimiento
se vería, mediante los bocetos en papel.

4. Ese prototipo se valida con todos los participantes y los


acuerdos se documentan mediante una minuta. El prototipado
permitió analizar la relación entre: 1) diseñador/usuario; 2)
Usuario/sistema; 3) recursos /tiempo (costo); y 4) todo/parte, ver
el comportamiento del sistema como un conjunto de partes (sub-
módulos), pero al mismo tiempo ver cada una esas partes de
forma independiente

5. El boceto aprobado, es desarrollado en la herramienta


Balsamiq Mockup por el analista y el prototipo resultando es
entregado al programador para su implementación.

Los prototipos creados sirvieron también de insumo para


seleccionar las técnicas y actividades IPO que mejor se ajustaban a
los requisitos del software. En el proceso de diseño relacionado
con la usabilidad, se incluyeron además del prototipado
actividades asociadas al diseño de interacción que permitió
conocer los entornos de interacción usuario/sistema (parte del
prototipado) y la interfaz gráfica.

Para el desarrollo del producto se tuvo en cuenta tres aspectos: 1)


modelos mentales del usuario, para especular sobre cómo
funciona el sistema; 2) modelos mentales del diseñador, para tener
una imagen lógica del funcionamiento del sistema; y 3) el
concepto del producto, que permite la definición clara del mismo.
6. El programador presenta el prototipo funcional del
requerimiento.

7. Informe resumen de estado del desarrollo.

Para dar cumplimiento al proceso de Control y seguimiento y con


ello al punto siete de las reuniones con el equipo de trabajo, se
asignó un especialista en QA quien le dio seguimiento a los
requerimientos en la herramienta Trello, que utiliza la metodología
Kanban. Este seguimiento se inicia con las listas de chequeo de lo
que debe contener cada una de las tareas descritas y los
responsables de éstas.

Por otra parte, para la evaluación de la usabilidad, se incluyeron


dos grandes actividades: valoración del sistema, y toma de
decisiones sobre el producto, identificadas en la Figura 3 con los
números 6 y 7 respectivamente. La valoración del sistema fue
utilizada para saber si satisface las necesidades del usuario y para
saber si encaja en el contexto de uso y la toma de decisiones
sobre el diseño ayudó a retroalimentar el proceso; a evaluar los
objetivos alcanzados por el usuario; y a monitorear el uso del
sistema a largo plazo. El informe resumen contiene los principales
resultados de los avances, lo pendiente y en lo que se está
trabajando.

Como principales resultados alcanzados se tiene una disminución


constatada de tiempo (duración de 12 semanas de 15 semanas
planificadas teniendo como referente desarrollos anteriores) y un
aumento considerable de la productividad y de la usabilidad de las
interfaces de usuarios resultantes. Respecto al aumento de la
productividad puede mencionarse que, con el diseño de los
mockups, además de requerir poco tiempo, se posibilita recoger
de una forma atractiva para el usuario los elementos del diseño
que dan cumplimiento a cada requerimiento planteado. Así se
disminuyen la probabilidad de ocurrencia de peticiones de cambio
durante el ciclo de vida del proyecto, que al final se reflejan en
inversión de tiempo.

Se aprecia también una mejora considerable en la usabilidad


resultante, pues al aplicar en la guía diferentes técnicas y
elementos del diseño centrado en el usuario y del diseño de la
experiencia de usuario, se crea un estado emocional placentero en
la interacción con el sistema. Por ejemplo, realizar un análisis de
tareas posibilitó que la interfaz que se modele sea lo más similar
posible a como se realizan en la práctica las tareas que se
informatizaron. Con respecto a la mantenibilidad, se obtienen
resultados alentadores pues las interfaces que se obtienen son
menos complejas y más modulares.
V. Conclusiones

La revisión de los principales elementos asociados a la IR, a la


Usabilidad desde la IPO, así como de SCRUM, Design Thinking y
Kanban permitió valorar la importancia y necesidad de su
integración en el desarrollo de software ágil para la implantación
exitosa y satisfacción de los usuarios finales. Además, se pudo
constatar que, si bien las metodologías tradicionales proponen un
proceso formal para la IR, resulta complejo adoptar estas prácticas
en proyectos que se desarrollen siguiendo un enfoque ágil que
integre diferentes técnicas de usabilidad.

A partir de los elementos estudiados se elaboró una guía para la


Ingeniería de Requerimientos que integra técnicas de usabilidad
siguiendo un enfoque ágil. Entre los elementos fundamentales que
la guía incluye se encuentran la definición de cada uno de los
procesos a realizar, así como una propuesta de tecnologías y
técnicas de usabilidad a emplear para alcanzar mejores resultados.

Para demostrar su nivel de aplicabilidad se describieron los


resultados alcanzados luego de su aplicación en el desarrollo de
un proyecto real, que demuestra una disminución del tiempo y
mejoras en la productividad y usabilidad del sistema desarrollado.
En este sentido, constituye un atractivo para diferentes
organizaciones desarrolladoras de software.

VI. Referencias

[1] J. Johnson, L. Gesmer, J. Poort, and H. Mulder, "Chaos Report


2016," Special Chaos Report on Digital Transformation
Project, 2016.
[2] R. E. D. Fairley, P. Bourque, and J. Keppler, "The impact of
SWEBOK Version 3 on software engineering education and
training," in 2014 IEEE 27th Conference on Software Engineering
Education and Training (CSEE&T), 2014, pp. 192-200.

[3] K. Wiegers and J. Beatty, Software requirements: Pearson


Education, 2013.

[4] I. Sommerville, "Software engineering 9th Edition," ISBN-


10, vol. 137035152, 2011.

[5] K. Beck, M. Beedle, A. v. Bennekum, A. Cockburn, W.


Cunningham, M. Fowler, et al., "Agile software development
manifesto," ed, 2001.

[6] I. Inayat, S. S. Salim, S. Marczak, M. Daneva, and S.


Shamshirband, "A systematic literature review on agile
requirements engineering practices and challenges," Computers in
human behavior, vol. 51, pp. 915-929, 2015.

[7] J. Dick, E. Hull, and K. Jackson, Requirements engineering:


Springer, 2017.

[8] P. A. Laplante, Requirements engineering for software and


systems: Auerbach Publications, 2017.

[9] J. Sutherland and K. Schwaber, "The scrum papers: Nut, bolts,


and origins of an Agile framework (2011)," SCRUM Training
Institute, 2014.

[10] K. Schwaber, Agile project management with Scrum: Microsoft


press, 2004.

[11] K. Schwaber and J. Sutherland, "La guía de


Scrum," Scrumguides. Org, vol. 1, p. 21, 2013.
[12] D. J. Anderson, Kanban: successful evolutionary change for
your technology business: Blue Hole Press, 2010.

[13] L. Gilibets. (2013). Comunidad IeBS.


Available: http://comunidad.iebschool.com/iebs/general/meto
dologia-kanban/

[14] C. Hofmann, S. Lauber, B. Haefner, and G. Lanza,


"Development of an agile development method based on Kanban
for distributed part-time teams and an introduction
framework," Procedia Manufacturing, vol. 23, pp. 45-50, 2018.

[15] K. D. Elsbach and I. Stigliani, "Design thinking and


organizational culture: A review and framework for future
research," Journal of Management, vol. 44, pp. 2274-2306, 2018.

[16] P. Micheli, S. J. Wilner, S. H. Bhatti, M. Mura, and M. B.


Beverland, "Doing Design Thinking: conceptual review, synthesis,
and research agenda," Journal of Product Innovation
Management, vol. 36, pp. 124-148, 2019.

[17] T. Brown and J. Wyatt, "Design thinking for social


innovation," Development Outreach, vol. 12, pp. 29-43, 2010.

[18] R. Steinbeck, "Building creative competence in globally


distributed courses through design thinking," Revista
Comunicar, vol. 19, pp. 27-34, 2011.

[19] L. C. Degrossi, B. B. Abe, J. P. de Albuquerque, and R. P. de


Mattos Fortes, "Enhancing usability of a Citizen Observatory based
on User-centered Design," in Proceedings of the 8th International
Conference on Software Development and Technologies for
Enhancing Accessibility and Fighting Info-exclusion, 2018, pp. 294-
301.
[20] A. M. Mithun and W. M. Yafooz, "Extended User Centered
Design (UCD) Process in the Aspect of Human Computer
Interaction," in 2018 International Conference on Smart Computing
and Electronic Enterprise (ICSCEE), 2018, pp. 1-6.

[21] M. F. L. Pazmiño, "Evaluación de Usabilidad aplicada a Visores


Geográficos Web," University of Salzburg, 2018.

[22] Q. Jin, "Design of a virtual community based interactive


learning environment," Information Sciences, vol. 140, pp. 171-191,
2002.

[23] T. Dyba, "An empirical investigation of the key factors for


success in software process improvement," IEEE Transactions on
Software Engineering, vol. 31, pp. 410-424, 2005.

[24] M. A. Almomani, S. Basri, and A. R. Gilal, "Empirical study of


software process improvement in Malaysian small and medium
enterprises: The human aspects," Journal of Software: Evolution and
Process, vol. 30, p. e1953, 2018.

[25] D. Pagrut, "The Impact of an Agile Scrum on Software Testing:


A Case Study of Tech Mahindra Limited," in 5th International
Conference On Software Testing. STeP-IN SUMMIT, 2008.

[26] M. Dubakow. (2010). 10 Most Common Mistakes in Agile


Adoption.
Available: http://www.targetprocess.com/blog/2010/10/10-
most-common-mistakes-in-agileadoption-part-i.html

[27] M. Sihuay, A. D. Ramón, and M. Pessoa, "Factors Models of


Scrum Adoption in the Software Development Process: A
Systematic Literature Review-Modelos de Factores en la Adopción
de Scrum in el Proceso de Desarrollo de Software. Una Revisión
Sistemática de la Literatura," ReCIBE, Revista electrónica de
Computación, Informática, Biomédica y Electrónica, vol. 7, pp. 23-
44, 2018.

[28] J. López-Martínez, R. Juárez-Ramírez, C. Huertas, S. Jiménez,


and C. Guerra-García, "Problems in the adoption of Agile-Scrum
methodologies: A systematic literature review," in 2016 4th
International Conference in Software Engineering Research and
Innovation (CONISOFT), 2016, pp. 141-148.

[29] I. Kroener, D. Barnard-Wills, and J. Muraszkiewicz, "Agile


ethics: an iterative and flexible approach to assessing ethical, legal
and social issues in the agile development of crisis management
information systems," Ethics and Information Technology, pp. 1-12,
2019.

[30] M. E. K. Säisä, K. Tiura, and R. Matikainen, "Agile Project


Management in University-Industry Collaboration
Projects," International Journal of Information Technology Project
Management (IJITPM), vol. 10, pp. 8-15, 2019.

[31] K. El Emam, D. Goldenson, J. McCurley, and J. Herbsleb,


"Success or failure? Modeling the likelihood of software process
improvement," 1998.

[32] S. Bayona, J. A. Calvo-Manzano, and T. San Feliu, "Critical


success factors in software process improvement: A systematic
review," in International Conference on Software Process
Improvement and Capability Determination, 2012, pp. 1-12.

[33] J.-C. Lee and C.-Y. Chen, "Exploring the determinants of


software process improvement success: A dynamic capability
view," Information Development, vol. 35, pp. 6-20, 2019.
[34] T. C. Powell, "Total quality management as competitive
advantage: a review and empirical study," Strategic management
journal, vol. 16, pp. 15-37, 1995.

[35] N. Baddoo and T. Hall, "De-motivators for software process


improvement: an analysis of practitioners’ views," Journal of
Systems and Software, vol. 66, pp. 23-33, 2003.

[36] M. Chugh, N. Chanderwal, R. Upadhyay, and D. K. Punia,


"Effect of knowledge management on software product
experience with mediating effect of perceived software process
improvement: An empirical study for Indian software
industry," Journal of Information Science, p. 0165551519833610,
2019.

[37] X. Ferre and N. Bevan, "Usability planner: a tool to support the


process of selecting usability methods," in IFIP Conference on
Human-Computer Interaction, 2011, pp. 652-655.

[38] L. B. Studios. (2008, 01-03). Balsamiq Mockups. Available:


https://balsamiq.com/products/mockups

[39] F. C. Software. (2016, 25-01). Trello. Available:


https://trello.com

También podría gustarte