PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INTEGRACIÓN DEL DISEÑO CENTRADO EN USUARIO CON METODOLOGÍAS ÁGILES EN EL DESARROLLO DE UN CATÁLOGO DE PLANTAS. UN ESTUDIO DE INVESTIGACIÓN - ACCIÓN Tesis para optar el Título de Ingeniera Informática, que presenta la alumna: María del Carmen Aguilar Vélez 20090212 ASESORA: Mag. Claudia María Del Pilar Zapata Del Rio Lima, Julio de 2015 1 DEDICATORIA A mis padres que siempre me han dado todo para que pueda lograr este gran paso, ustedes son mi mayor inspiración para alcanzar mis metas. Mil palabras no bastarían para agradecer todo lo que me dan. A mis hermanos Rafael y Claudia, que con todo su apoyo, cariño y consejos que me dan, me inspiran a esforzarme mucho para llegar a ser como ustedes. Espero algún día superarlos y este es solo el primer paso para lograrlo. A mis sobrinos Camila y Davin, que con solo dos años, sus sonrisas y abrazos me dan las mayores alegrías y reconfortan en momentos difíciles. Espero ser un ejemplo a seguir para ustedes, así como mis hermanos lo son para mí. A las personas especiales que conocí en PUCP y en Ingeniería Informática, amigos y profesores que hicieron que esta etapa de la vida universitaria sea muy buena. Gracias a esas personas que siempre estuvieron listas para brindarme toda su ayuda. Con todo mi cariño está tesis se la dedico a ustedes. 2 RESUMEN Una de las principales características de la calidad de un producto de software es la usabilidad. Según el estándar ISO 9241, el término usabilidad está definido como “el grado en que un producto puede ser utilizado por usuarios específicos para alcanzar metas específicas con eficiencia, eficacia y satisfacción en un contexto de uso específico”. Por esta razón son de gran ayuda las metodologías encaminadas a lograr la usabilidad como el Diseño Centrado en Usuario (UCD, del inglés User – Centered Design). Por otro lado, las metodologías de desarrollo de software ágil surgen como respuesta a uno de los problemas de la ingeniería de software que se ha discutido por muchos años, sobre cómo deben realizarse las actividades del desarrollo de software con el fin de agilizar las entregas, reducir costos y obtener mejores soluciones. Puede parecer natural incluir métodos de UCD en proyectos de desarrollo ágil; sin embargo, la integración de estos dos métodos no está bien definida. Mientras UCD está enfocado al diseño de la interacción, las metodologías ágiles cubren todo el proceso de construcción de software. Una similitud importante entre ambas es que buscan satisfacer las necesidades y metas de los usuarios como seres humanos, lo cual favorece a su integración para lograr productos con mayor grado de usabilidad. En el presente proyecto de fin de carrera se presenta el análisis del proceso de integración de una metodología de desarrollo de software ágil con métodos de UCD. Para ello, se llevó a cabo una investigación – acción en la que se propuso la integración de Extreme Programming y algunos métodos de UCD, la cual fue aplicada a la construcción de una aplicación móvil sobre un catálogo de plantas para la PUCP. Con el producto software obtenido, se realizaron evaluaciones de usuarios para evaluar su usabilidad y, de esta manera, se pudo analizar las ventajas y el proceso de integración de los métodos propuestos. 3 4 5 6 Tabla de contenido ÍNDICE DE TABLAS _________________________________________________ 9 ÍNDICE DE FIGURAS ______________________________________________ 10 CAPÍTULO 1 GENERALIDADES _______________________________11 1.1 OBJETIVO GENERAL ___________________________________________ 13 1.2 OBJETIVOS ESPECÍFICOS________________________________________ 13 1.3 RESULTADOS ESPERADOS_______________________________________ 13 1.4 HERRAMIENTAS, MÉTODOS, METODOLOGÍAS Y PROCEDIMIENTOS __________ 14 1.4.1 DESCRIPCIÓN DE LOS MÉTODOS, HERRAMIENTAS Y PROCEDIMIENTOS ______ 15 1.4.2 ALCANCE Y LIMITACIONES______________________________________ 19 1.4.3 RIESGOS __________________________________________________ 20 1.5 JUSTIFICACIÓN Y VIABILIDAD _____________________________________ 20 1.5.1 ANÁLISIS DE VIABILIDAD _______________________________________ 21 1.6 MARCO CONCEPTUAL __________________________________________ 21 1.6.1 DISEÑO CENTRADO EN EL USUARIO (UCD) _________________________ 22 1.6.2 METODOLOGÍAS ÁGILES _______________________________________ 26 1.6.3 RESUMEN _________________________________________________ 29 1.7 ESTADO DEL ARTE ____________________________________________ 30 1.7.1 OBJETIVOS DE LA REVISIÓN DEL ESTADO DEL ARTE ___________________ 30 1.7.2 DISCUSIÓN SOBRE EL ESTADO DEL ARTE ___________________________ 30 1.7.3 CONCLUSIONES SOBRE EL ESTADO DEL ARTE________________________ 35 CAPÍTULO 2 LEVANTAMIENTO DE REQUISITOS _________ 37 2.1 CASO A DESARROLLAR EN LA INVESTIGACIÓN - ACCIÓN _________________ 38 2.2 INTEGRACIÓN PROPUESTA _______________________________________ 38 2.3 APLICACIÓN DE LA INTEGRACIÓN PROPUESTA PARA EL LEVANTAMIENTO DE REQUISITOS _____________________________________________________ 40 2.3.1 ENTREVISTAS ______________________________________________ 40 2.3.2 PERSONAS ________________________________________________ 43 2.3.3 ESCENARIOS _______________________________________________ 44 7 CAPÍTULO 3 ITERACIONES __________________________________ 45 3.1 ELABORACIÓN DEL PROTOTIPO ___________________________________ 46 3.1.1 RESULTADOS DE LA EVALUACIÓN DEL PROTOTIPO ____________________ 46 3.2 DISEÑO DE LA EVALUACIÓN DE CADA ITERACIÓN ______________________ 50 3.2.1 PENSAMIENTO EN VOZ ALTA ____________________________________ 50 3.3 ITERACIÓN 1 _________________________________________________ 51 3.3.1 RESULTADOS DE LA EVALUACIÓN DE LA ITERACIÓN 1 __________________ 53 3.4 ITERACIÓN 2 _________________________________________________ 56 3.4.1 RESULTADOS DE LA EVALUACIÓN DE LA ITERACIÓN 2 __________________ 57 3.5 ITERACIÓN 3 _________________________________________________ 58 3.5.1 RESULTADOS DE LA EVALUACIÓN DE LA ITERACIÓN 3 __________________ 59 3.6 ITERACIÓN 4 _________________________________________________ 61 3.6.1 RESULTADOS DE LA EVALUACIÓN DE LA ITERACIÓN 4 __________________ 62 3.7 CONCLUSIONES Y ANÁLISIS DE USO DE GUÍAS DE AYUDA INTERACTIVA ______ 63 3.7.1 ANÁLISIS DEL USO DE GUÍAS DE AYUDA INTERACTIVA __________________ 64 CAPÍTULO 4 EVALUACIÓN DE USUARIOS DEL PRODUCTO FINAL ________________________________________________ 66 4.1 DISEÑO DE LA EVALUACIÓN DE USUARIOS ___________________________ 66 4.1.1 OBJETIVOS DE LA PRUEBA: _____________________________________ 66 4.1.2 PREGUNTAS DE INVESTIGACIÓN _________________________________ 67 4.1.3 ENTORNO DE PRUEBAS, EQUIPOS Y LOGÍSTICA _______________________ 67 4.1.4 CARACTERÍSTICAS DE LOS PARTICIPANTES _________________________ 67 4.1.5 DESCRIPCIÓN DEL MÉTODO ____________________________________ 68 4.1.6 DATOS A SER RECOGIDOS Y MEDIDAS DE EVALUACIÓN _________________ 69 4.2 DESARROLLO DE LA EVALUACIÓN DE USUARIOS _______________________ 69 4.3 RESULTADOS DE LA EVALUACIÓN DE USUARIOS _______________________ 70 4.4 CONCLUSIONES Y ANÁLISIS DE USO DE GUÍAS DE AYUDA INTERACTIVA ______ 72 4.4.1 ANÁLISIS DEL USO DE GUÍAS DE AYUDA INTERACTIVA __________________ 73 CAPÍTULO 5 DISCUSIÓN DE RESULTADOS ________________ 74 8 CAPÍTULO 6 OBSERVACIONES, CONCLUSIONES Y TRABAJOS FUTUROS ______________________________________________ 79 6.1 OBSERVACIONES _____________________________________________ 79 6.2 CONCLUSIONES ______________________________________________ 79 6.3 TRABAJOS FUTUROS ___________________________________________ 81 REFERENCIAS BIBLIOGRÁFICAS ________________________________ 82 9 Índice de Tablas Tabla 1. Resumen de las herramientas, métodos y metodologías a usarse. [Elaboración propia] ............................................................................................... 15 Tabla 2. Riesgos del proyecto. [Elaboración propia] .............................................. 20 Tabla 3. Resumen de los proyectos observados. Imagen adaptada de Chamberlain, Sharp, & Maiden, 2006 .......................................................................................... 32 Tabla 4. Resultados encontrados en los 4 artículos presentados. [Elaboración propia] ................................................................................................................... 35 Tabla 5. Aplicaciones móviles presentadas a los entrevistados. [Elaboración propia] .............................................................................................................................. 42 Tabla 6. Resultados de la evaluación de la primera iteración. [Elaboración propia] 54 Tabla 7. Resultados de la evaluación de la segunda iteración. [Elaboración propia] .............................................................................................................................. 57 Tabla 8. Resultados de la evaluación de la tercera iteración. [Elaboración propia] 60 Tabla 9. Resultados de la evaluación de la cuarta iteración. [Elaboración propia] . 62 Tabla 10. Uso de guías de ayuda interactiva en las iteraciones. [Elaboración propia] .............................................................................................................................. 65 Tabla 11. Distribución para el orden de evaluación de las aplicaciones. [Elaboración propia] ................................................................................................................... 69 Tabla 12. Comparación de los resultados de las pruebas de las 2 aplicaciones. [Elaboración propia] ............................................................................................... 71 Tabla 13. Resumen de las iteraciones desarrolladas. [Elaboración propia] ............ 77 Tabla 14. Ventajas de integrar XP con UCD en el presente proyecto. [Elaboración propia] ................................................................................................................... 78 10 Índice de Figuras Figura 1. Proceso Básico de XP. Imagen adaptada de Wolkerstorfer, Peter, et al (2008) .................................................................................................................... 37 Figura 2. Proceso de XP integrado con herramientas de UCD para el presente proyecto. [Elaboración propia] ............................................................................... 39 Figura 3. Tab Bar en iOS. [Elaboración propia] ...................................................... 47 Figura 4. Ejemplo taxonomía de plantas. [Elaboración propia] ............................... 48 Figura 5. Scope Bar en iOS. [Elaboración propia] .................................................. 48 Figura 6. Index list en iOS [Elaboración propia]. .................................................... 49 Figura 7. Modelo de Datos físico. [Elaboración propia] .......................................... 52 Figura 8. Vistas de la primera iteración. [Elaboración propia]................................. 53 Figura 9. Vistas de la segunda iteración. [Elaboración propia] ............................... 57 Figura 10. Vistas de la tercera iteración. [Elaboración propia] ................................ 59 Figura 11. Vista de la cuarta iteración. [Elaboración propia]................................... 61 Figura 12. Comparación de los cuestionarios post - prueba de las 2 aplicaciones. [Elaboración propia] ............................................................................................... 71 11 Capítulo 1 GENERALIDADES El diseño de los productos de software con los que se interactúa a diario muchas veces no está enfocado en el usuario como ser humano sino sólo en necesidades técnicas. Las funcionalidades pueden ser muy intuitivas para los desarrolladores, pero no lo son para sus usuarios finales[1]. Una de las características de la calidad de un producto software es la usabilidad que este tenga [2] y, por consiguiente, el nivel de satisfacción que tenga el usuario al interactuar con él, puede ser un factor determinante para su éxito o fracaso. Según el estándar ISO 9241, el término usabilidad está definido como “el grado en que un producto puede ser utilizado por usuarios específicos para alcanzar metas específicas con eficiencia, eficacia y satisfacción en un contexto de uso específico” [3]. Las metodologías de desarrollo de software ágil surgen como respuesta a uno de los problemas de la ingeniería de software que se ha discutido por muchos años, sobre cómo deben realizarse las actividades del desarrollo de software con el fin de agilizar las entregas, reducir costos y obtener mejores soluciones [4]. A fines de la década de 1990, surgen diversas metodologías que enfatizan la comunicación y colaboración constante entre los programadores y los expertos del negocio, originado así innovaciones y cambios en las metodologías tradicionales del desarrollo de software [5]. Generalmente es necesario incluir métodos de Diseño Centrado en Usuario (UCD, del inglés User - Centered Design) en proyectos de desarrollo ágil; sin embargo, la integración del diseño interactivo en metodologías ágiles no está bien definida [6]. Si bien es cierto que ambos se basan en iteraciones, el desarrollo ágil de software considera iteraciones que pueden durar semanas para evaluar el código; en cambio, el diseño interactivo itera sólo en la interfaz del producto, utilizando prototipos de baja fidelidad con iteraciones que pueden durar solamente horas o días [6]. Además, las pruebas también son un aspecto muy importante tanto en el diseño interactivo como en el desarrollo ágil, pero en este último se deben desarrollar pruebas automatizadas para evaluar el código, mientras que en el diseño interactivo las pruebas deben hacerse, idealmente, por los potenciales usuarios finales [6]. Aunque uno de los problemas para integrar estas metodologías es que usan tradicionalmente diferentes enfoques y los recursos son asignados de diferente manera en el proyecto, ambas tienen una similitud, que es buscar 12 satisfacer las necesidades y metas de los usuarios y por tanto están centradas en el cliente [7]. Según estudios en los que se hace una revisión sistemática de usabilidad en metodologías ágiles [4, 7, 8], donde uno de sus objetivos es evaluar los estudios empíricos de técnicas de usabilidad y desarrollo de software ágil, se llega a la conclusión de que existen muy pocos experimentos controlados en los que se pueda mostrar las ventajas y el enfoque de integrar ambas metodologías. Se resalta también que para evitar problemas de usabilidad en el producto final, es importante que las técnicas de evaluación de usabilidad se den tanto en etapas tempranas como a lo largo del desarrollo iterativo de este, haciendo evaluaciones con la misma frecuencia de tiempo a lo largo del ciclo de vida del producto. La obtención de un software usable sigue siendo uno de los mayores problemas que deben afrontar, hoy en día, los equipos de desarrollo [9]. Por esta razón una metodología encaminada a lograr un producto usable sería de gran ayuda [9]. Dado el gran impacto de las metodologías ágiles se busca que éstas se complementen con las mejores técnicas de usabilidad. Por tal motivo, en el presente trabajo se analizará la aplicación de una metodología de desarrollo de software ágil integrada con UCD en el desarrollo de una aplicación móvil sobre un catálogo de plantas para la Pontificia Universidad Católica del Perú, el cual podrá ser utilizado no solo por los estudiantes, sino también por docentes y cualquier persona interesada en fomentar o conocer la diversidad de plantas de la Universidad. 13 1.1 Objetivo general Analizar las ventajas de integrar Metodologías Ágiles con el Diseño Centrado en el Usuario, aplicado a la construcción de una interfaz para una aplicación móvil sobre un catálogo de plantas de la PUCP. 1.2 Objetivos específicos Los objetivos específicos del presente proyecto son: O 1. Integrar herramientas que ofrecen las Metodologías Ágiles y UCD para el levantamiento de requisitos durante la etapa de análisis en el ciclo de vida del desarrollo de software. O 2. Aplicar las buenas prácticas que ofrece UCD en la fase del diseño de interfaces a lo largo de todo el desarrollo ágil del software. O 3. Construir, a partir del diseño planteado, el catálogo de plantas siguiendo las iteraciones de las metodologías ágiles. O 4. Aplicar evaluaciones de usabilidad en cada iteración del desarrollo para complementar la evaluación de calidad del software. O 5. En cada iteración, evaluar la integración de guías interactivas de ayuda y soporte como medio para mejorar la usabilidad del software. 1.3 Resultados esperados  Resultado 1 para el Objetivo específico 1: Propuesta de integración de herramientas de UCD y metodologías ágiles al elaborar la lista de requisitos  Resultado 2 para el Objetivo específico 1: Una lista de requisitos para el catálogo de plantas utilizando la propuesta de integración de las herramientas de UCD y las metodologías ágiles. 14  Resultado 3 para el Objetivo específico 2: Prototipo de la interfaz basado en las buenas prácticas que ofrece UCD y evaluado en cada iteración según el desarrollo ágil del software, utilizando un historial de modificaciones por cada transición.  Resultado 4 para el Objetivo específico 3: Producto software usable, el cual será verificado con evaluaciones de usuarios y utilizando un checklist de requisitos.  Resultado 5 para el Objetivo específico 4: Informe de las evaluaciones de usabilidad del producto durante cada iteración y del producto final.  Resultado 6 para el Objetivo específico 4: Documento del análisis de la integración de las evaluaciones de usabilidad y las pruebas planteadas por las metodologías ágiles.  Resultado 7 para el Objetivo específico 5: Documento de la clasificación y evaluación de la lista de requisitos según el nivel de dificultad para los usuarios.  Resultado 8 para el Objetivo específico 5: Recomendaciones de uso de ayudas interactivas para incluir en el producto. 1.4 Herramientas, métodos, metodologías y procedimientos A continuación, en la Tabla 1, se puede observar el resumen de las herramientas a usar para lograr los resultados esperados. Resultados esperados Herramientas a usarse RE1: Propuesta de integración de herramientas de UCD y metodologías ágiles al elaborar la lista de requisitos. - Revisión de la literatura. 15 Resultados esperados Herramientas a usarse RE2: Lista de requisitos para la construcción del catálogo de plantas, utilizando la propuesta de integración de las herramientas de UCD y las metodologías ágiles. - Entrevistas semi- estructuradas con los usuarios. - Observación de campo a través de la evaluación de casos existentes. - Escenarios - Extreme Programming (XP) RE3: Prototipo de la interfaz basado en las buenas prácticas que ofrece UCD y evaluado en cada iteración según el desarrollo ágil del software, utilizando un historial de modificaciones por cada transición. - Storyboard de Xcode 6 - Escenarios RE4: Producto software usable, el cual será verificado con evaluaciones de usuarios y utilizando un checklist de requisitos. - Xcode6 RE5: Informe de las evaluaciones de usabilidad del producto durante cada iteración y del producto final. - Evaluación de usuarios según Jeff Rubin y Dana Chisnell RE7: Clasificación y evaluación de la lista de requisitos según el nivel de dificultad para los usuarios. - Evaluación de usuarios según Jeff Rubin y Dana Chisnell. Tabla 1. Resumen de las herramientas, métodos y metodologías a usarse. [Elaboración propia] 1.4.1 Descripción de los métodos, herramientas y procedimientos Los métodos, herramientas y procedimientos a usarse son los siguientes: Investigación – Acción La investigación-acción es un enfoque sistemático para la investigación que permite encontrar soluciones eficaces a los problemas que surgen en la vida cotidiana. A 16 diferencia de la investigación tradicional experimental / científica, que busca explicaciones que se puedan generalizar y aplicar a todos los contextos, la investigación acción se centra en situaciones específicas y soluciones localizadas [10]. La rutina básica de investigación-acción proporciona un marco sencillo pero potente - observar, pensar, actuar - que permite comenzar las investigaciones de una manera directa y construir con mayor detalle los procedimientos a medida que aumenta la complejidad de las tareas [10]. En el presente proyecto se desarrolló una investigación-acción participativa, en la que se construyó una interfaz sobre un catálogo de plantas de la PUCP para obtener información cualitativa sobre el proceso de integración de UCD con una metodología ágil. En este tipo de investigación, los participantes pueden desempeñar el rol de coinvestigadores ya que necesitan interactuar de manera constante con los datos [11]. Dado que además de construir la interfaz, se evaluó el proceso de integración, este estudio se encuentra dentro de este tipo de investigación. Entrevistas semi-estructuradas con los usuarios En la etapa de establecimiento de requisitos, es igual de importante para el equipo de desarrollo conocer a los stakeholders, como para los usuarios sentirse involucrados en el proyecto [1]. Este es un motivo muy importante por el que se elige el uso de entrevistas. En el presente proyecto, al involucrar los principios de UCD, fue necesario el trabajo conjunto con los posibles usuarios de la aplicación, por lo que, para involucrarlos en el trabajo, se realizaron entrevistas semi-estructuradas en las que se pueda conocer sus intereses y expectativas para el uso de la aplicación y junto con ellos establecer los requisitos. Esta herramienta permitió, sobre todo, obtener datos cualitativos y sirvió, también, para definir los diferentes grupos de usuarios. Un buen uso de las entrevistas semi-estructuradas sirvió para poder establecer un esquema base y obtener información necesaria para el desarrollo de la interfaz. Escenarios Los escenarios son descritos como historias informales sobre las tareas y actividades de los usuarios y son, además, un mecanismo muy poderoso para la 17 comunicación entre los miembros del equipo de desarrollo con los usuarios [1]. Pueden ser utilizados para explicar las situaciones de trabajo existentes, pero se usan, comúnmente, para expresar propuestas o situaciones imaginarias que ayudarán con el diseño conceptual [1]. En este caso, con la información obtenida en las entrevistas con los usuarios, el desarrollo de escenarios permitió discutir el contexto, las necesidades y los requisitos de la interfaz. Además, siguiendo los principios de UCD, los escenarios fueron planteados y modificados con ayuda y recomendaciones de los usuarios. Observación de campo a través de la evaluación de casos existentes Los escenarios y entrevistas ayudan a los usuarios a ser más precisos en sus descripciones; sin embargo, la observación proporciona una visión más amplia de lo que requiere en la interfaz [1]. En la etapa de la elaboración de requisitos, la observación es buena para la comprensión de la naturaleza de las tareas y el contexto en el que se realizan [1]. Aunque se requiere más tiempo y compromiso, esta técnica puede dar lugar a una enorme cantidad de datos [1]. En este caso, además de observar las tareas que realizan día a día los usuarios, se identificaron casos existentes sobre aplicaciones de catálogos de plantas y fueron evaluados por los usuarios para poder definir requisitos adicionales para el desarrollo de la interfaz. Extreme Programming (XP) XP es una metodología de desarrollo de software ágil, la cual está basada en 4 valores que guían todo el proyecto: simplicidad, comunicación, retroalimentación y coraje [12]. Se utiliza una forma de planificación y seguimiento para decidir qué hacer a continuación y para predecir cuando algún conjunto de funcionalidades deseadas será entregado [12]. Básicamente, el desarrollo del software está basado en una serie de pequeñas versiones totalmente integradas que pasan todas las pruebas que se han definido [12]. Esta metodología es idónea para el presente proyecto ya que propone que el desarrollo del software puede ser afectado por posibles cambios que surgen dentro del ciclo de vida del desarrollo de un proyecto y describe una serie de prácticas para reducir los costos del software cambiante [13]. Cabe destacar que solo se utilizaron algunos métodos y herramientas que se definen en esta metodología, 18 excluyendo una de las prácticas de XP que es el trabajo en parejas, ya que el trabajo fue desarrollado de manera individual y el principal objetivo es la observación de integrar esta herramienta con método de UCD. Xcode6 Xcode es un IDE que contiene un conjunto de herramientas de desarrollo de software diseñados por Apple para el desarrollo de software para OS X y iOS, el cual permite trabajar con el lenguaje ObjectiveC. Este IDE fue utilizado para el desarrollo de la aplicación del catálogo de plantas para dispositivos con plataforma iOS. Storyboard de Xcode6 Los prototipos son una ayuda útil al momento de discutir las ideas con los stakeholders, sirven como dispositivos de comunicación entre los miembros del equipo y son una manera eficaz de poner a prueba todas las ideas que se presentan, ayudando a los diseñadores a elegir entre diversas alternativas [1]. Una herramienta muy útil que ofrece el Xcode es el Storyboard, el cual permite construir un prototipo funcional en muy poco tiempo. El propósito de la creación de prototipos en Xcode es ser capaz de crear un prototipo de alta fidelidad utilizando el mismo software que construye iOS Apps. En el Storyboard se trabaja con múltiples pantallas que son conectadas a través de un “segue” y permite además arrastrar elementos en cada una de ellas para representar diferentes funcionalidades. De esta manera, al diseñar se enfrentan problemas reales y se puede obtener una vista previa y evaluaciones de la interfaz en cada etapa del desarrollo. Evaluación de usuarios según Jeff Rubin y Dana Chisnell Uno de los métodos de UCD son las pruebas de usabilidad, las cuales pueden ser formales, realizadas como verdaderos experimentos con el fin de afirmar o rechazar hipótesis, o evaluaciones menos formales, las cuales implican identificar deficiencias en la usabilidad a través de ciclos iterativos de pruebas [14]. Jeff Rubin y Dana Chisnell [14] proponen pruebas de usabilidad con un enfoque menos formal y evaluaciones iterativas del producto software. Ellos se refieren a las pruebas de usabilidad como un proceso que emplea participantes de prueba, quienes son representativos de un público objetivo, para evaluar el grado en que un producto cumple ciertos criterios específicos de usabilidad. Esta herramienta sirvió, 19 además, para clasificar y evaluar la lista de requisitos según el nivel de dificultad para los usuarios y obtener así una lista de recomendaciones para integrar en la interfaz de la aplicación. Esta evaluación está basada en: - Desarrollo de preguntas de investigación o pruebas de los objetivos, en lugar de plantear hipótesis. - Uso de una muestra representativa de usuarios finales que podría o no ser elegida de manera aleatoria. - Representación del actual ambiente de trabajo. - Observación de los usuarios finales que utilizan o revisan una representación del producto software. - Entrevistas controladas con los usuarios para probar la funcionalidad del producto. - Recolección de medidas cuantitativas y cualitativas de desempeño y de preferencias. - Recomendaciones de mejoras en el diseño del producto. 1.4.2 Alcance y Limitaciones En el presente trabajo se evaluó la aplicación de una metodología de desarrollo de software ágil integrada con métodos del Diseño Centrado en Usuario, aplicado al diseño y desarrollo de una interfaz para un catálogo de plantas, limitado a la variedad de flora de la PUCP. La metodología ágil a usar es Extreme Programming y las herramientas a integrar en la fase de inicialización del proyecto son entrevistas y el planteamiento de personas y escenarios. Luego, en el desarrollo de cada una de las iteraciones, se utilizó un método de evaluación de usabilidad conocido como Pensamiento en voz alta. Finalmente, al tener la interfaz de la aplicación completa, se realizó la evaluación de usuarios propuesta por Jeff Rubin y Dana Chisnell, la cual permitió evaluar el resultado y analizar el enfoque de integrar estas herramientas. El producto final fue una aplicación para dispositivos móviles con plataforma iOS, por lo que se debió seguir, en todo momento, las recomendaciones propuestas por Apple para el prototipo de la interfaz. Debido a que se trata de un proyecto sobre usabilidad y metodologías de desarrollo del software, la construcción de la aplicación para el catálogo de plantas se centró básicamente en la interfaz, por lo que se usó un algoritmo de aprendizaje ya desarrollado que permitió el manejo de las imágenes. Dicho algoritmo fue una red 20 neuronal desarrollada por el Grupo de Reconocimiento de Patrones e Inteligencia Artificial Aplicada (GRPIAA) de la PUCP. Se debe tener en cuenta que lo que se busca, principalmente, es la observación del proceso de integración de herramientas y no el producto final de la aplicación. 1.4.3 Riesgos Los riesgos identificados para el presente proyecto se observan en la Tabla 2. Riesgo identificado Impacto en el proyecto Medidas correctivas para mitigar Falta de disposición de tiempo de cierta cantidad de personas para llevar a cabo las evaluaciones con usuarios. El trabajo constante con los usuarios es imprescindible para el desarrollo del proyecto, por lo que podría causar atrasos con los resultados. Tener una lista adicional de personas que podrían colaborar con el proyecto. Dependencia de personas que desarrollen algoritmos que permitan el manejo de imágenes. La falta o los resultados de los algoritmos que se desarrollen por personas externas al proyecto podrían tener un impacto en la interfaz que se desarrollará. Tener conocimiento de los algoritmos que se desarrollarán con anticipación. Tabla 2. Riesgos del proyecto. [Elaboración propia] 1.5 Justificación y Viabilidad El presente proyecto servirá para obtener información cualitativa sobre la integración de métodos del diseño centrado en el usuario con las prácticas de una metodología ágil. Si bien es cierto, existen estudios sobre esta integración, como se mostrará en el estado del arte, no es muy común el desarrollo de casos de estudios en dispositivos móviles. Por lo general, se han aplicado estudios para el desarrollo 21 de sistemas web [15]. Durante la ejecución del proyecto, se obtendrán los beneficios de analizar, no solo el seguimiento de una serie de procesos, sino la integración de ellos con temas transaccionales. Toda esta información obtenida incluyendo ventajas, desventajas y rescatando las buenas prácticas de ambas metodologías, podrá ser analizada y aplicada a proyectos más grandes de desarrollo y asegurar la usabilidad de los productos. Otro beneficio es que debido a que la interfaz que se construirá no es muy compleja, ya que se utilizarán algoritmos de reconocimiento de imágenes ya desarrollados, permitirá utilizar todas las herramientas propuestas adecuadamente, sin afectar el desarrollo del producto. Adicionalmente, al obtener el catálogo de plantas en un dispositivo móvil, cualquier persona podrá acceder a la información de este. 1.5.1 Análisis de viabilidad Los aspectos tomados en cuenta para analizar la viabilidad del presente Proyecto son: Viabilidad Técnica Para el desarrollo del proyecto se requerirá conocimiento sobre Xcode6, con el cual se desarrolló la interfaz para el aplicativo móvil en iOS. Además se hizo uso de métodos del Diseño Centrado en Usuario y de algunos principios de Extreme Programming. Para ello se ha fue investigando previamente sobre estas herramientas y métodos. Viabilidad Económica Para poder instalar la aplicación en algún dispositivo móvil, fue necesario adquirir una licencia de desarrollador de programas, la cual tiene un costo de 99 dólares al año. Todas las otras herramientas que se utilizaron son de uso gratuito. 1.6 Marco conceptual El objetivo de esta sección es introducir el concepto del Diseño Centrado en el Usuario, lo que conlleva a poner al usuario como el centro durante el desarrollo de un producto software; para ello, será necesario definir, primero, el concepto de usabilidad. Además, se introduce el concepto de Metodologías Ágiles y la 22 descripción de las más relevantes, lo que permitirá elegir, posteriormente, la más apropiada para el presente proyecto. 1.6.1 Diseño Centrado en el Usuario (UCD) El diseño basado en la experiencia de los usuarios es una de las tendencias que viene creciendo rápidamente en los últimos años [16]. El éxito de los productos depende de cuánto satisfagan las necesidades y metas de las personas que interactúan con ellos [16]. Esto conlleva a poner al usuario como el centro del proceso de diseño de un producto [16]. El Diseño Centrado en el Usuario (UCD, del inglés User - Centered Design) es un enfoque que representa las técnicas, procesos, métodos y procedimientos para diseñar productos y sistemas usables, poniendo al usuario como el centro del proceso [14]. El valor de UCD es conseguir un mayor grado de usabilidad en el software [14].  Usabilidad La usabilidad es una cualidad del software que no solo facilita el uso del mismo, sino que también implica que los usuarios puedan cumplir sus objetivos específicos con eficiencia y eficacia [4]. Se dice que un producto es verdaderamente usable cuando el usuario es capaz de hacer lo que desea, de la manera que espera y sin ningún obstáculo, ni duda ni pregunta [14]. Según el estándar internacional ISO/DIS 9241-11, la usabilidad está definida como “el grado en que un producto puede ser utilizado por usuarios específicos para alcanzar metas específicas con eficiencia, eficacia y satisfacción en un contexto de uso específico” [3]. Esta norma permite identificar características esenciales de la usabilidad y definir así sus atributos. Según J. Rubin, D. Chisnell [14], para que un producto sea usable, debe incluir los siguientes atributos: - Utilidad: Se refiere al grado en el que un usuario puede alcanzar sus objetivos, es una evaluación de la buena disposición que éste tenga para usar el producto en su totalidad [14] . - Eficacia: Se refiere a la rapidez con la que un usuario puede alcanzar un objetivo en específico por completo y con precisión. Generalmente es una medida de tiempo [14]. 23 - Eficiencia: Se refiere a la medida en la que los productos se comportan en la forma en que los usuarios esperan [14]. - Facilidad de aprendizaje: Es una parte de la eficiencia, se refiere a la capacidad del producto para permitir que los usuarios puedan aprender a operar con facilidad el sistema [14]. - Satisfacción: Se refiere a la percepción del usuario, sus sentimientos y opiniones del producto [14]. Hacer los productos más usables es parte de la disciplina de UCD. La norma ISO 9241-210:2010 provee requisitos y recomendaciones para el Diseño Centrado en Usuarios y las actividades que se desarrollan a lo largo del ciclo de vida de los sistemas interactivos basados en computadoras [17]. Según la Norma, UCD es un enfoque para el desarrollo y diseño de sistemas cuyo objetivo es hacer que los sistemas interactivos sean más usables, enfocándose en el uso del sistema, aplicando factores humanos o ergonómicos, técnicas y conocimientos de usabilidad [17]. J. Rubin, D. Chisnell [14] proponen una serie de principios y método de UCD que serán descritos a continuación:  Principios de UCD - Enfoque inicial en los usuarios y las tareas: Además de identificar y categorizar a los usuarios, se recomienda que los usuarios y el equipo de diseño tengan un contacto directo a lo largo del ciclo de vida del desarrollo del producto. Por otro lado, los diseñadores deben ser entrenados por un grupo de expertos antes de llevar a cabo alguna actividad de recolección de datos para garantizar resultados exitosos. - Evaluación y medición de uso del producto: Se pone especial énfasis en la facilidad de aprendizaje y facilidad de uso, a través de pruebas de prototipos con usuarios reales. - Diseño iterativo y pruebas: El diseño, la modificación y prueba del producto debe ser un proceso iterativo, lo cual permitirá la revisión completa y el replanteamiento de las primeras muestras e ideas del diseño del producto. 24  Métodos de UCD UCD ofrece una serie de métodos y técnicas que pueden ser adoptadas en diferentes partes del proceso de desarrollo de software, ya sea en la etapa del análisis, implementación o evaluación. Por lo general no solo se utiliza una sola técnica, sino un conjunto de las más apropiadas según sea el caso. J. Rubin, D. Chisnell [14] proponen algunos de los métodos más relevantes: Investigación etnográfica Consiste en observar a los usuarios en el campo, en el lugar donde ellos normalmente usan el producto. Esto ayuda a identificar i) los usuarios objetivo, ii) tareas y objetivos relacionados al producto planeado y iii) el contexto en el que se planea alcanzar el objetivo. A partir de esta investigación cualitativa se puede desarrollar: - Perfiles: Colección de atributos para un típico usuario. - Personas: Descripción de un usuario ejemplo y los objetivos que desea realizar. - Escenarios: Narración informal que describe actividades o tareas humanas en una historia y permite explorar y discutir contextos, necesidades y requerimientos [1] . Diseño participativo Implica involucrar a uno o más usuarios representativos dentro del equipo de diseño desde etapas tempranas de este proceso, para aprovechar sus conocimientos, habilidades e incluso reacciones emocionales que tengan respecto al diseño del software. Una variación de esta técnica es llevar a cabo pequeños talleres en los que usuarios, diseñadores y desarrolladores trabajan juntos en un aspecto específico del diseño. Grupos especiales de investigación Se caracteriza por la participación simultánea de más de un participante y permite obtener información cualitativa con diferentes puntos de vista acerca del rendimiento y comportamiento del software. Los conceptos que evalúan los participantes en estas sesiones de grupo pueden ser plasmados en algunas formas preliminares como storyboards, prototipos 25 hechos en papel y lápiz, o también en modelos más elaborados como prototipos de alta fidelidad. Generalmente es usado en etapas tempranas del proceso de diseño. Encuestas El objetivo de emplear encuestas es entender las preferencias de un amplio grupo de usuarios acerca de un producto existente o por desarrollar. Un aspecto importante de las encuestas es que el lenguaje empleado debe ser claro y preciso para que sea entendido de la misma manera por todos los participantes. Recorrido Cognitivo Los diseñadores realizan un prototipo sobre el software y otorgan a los usuarios una serie de acciones que deben seguir para que interactúen con él y completen una serie de objetivos. Una parte del equipo de diseñadores se encarga de guiar a los usuarios durante la ejecución de las tareas, mientras que la otra parte del equipo se encarga de documentar las dificultades e inconvenientes que van encontrando los usuarios sobre el producto. Ordenamiento de tarjetas Es un método que sirve para obtener información de los usuarios sobre la organización de contenido, vocabulario y etiquetado del diseño del producto. Prototipado en papel Es una técnica en la que se representa el modelado del producto final hecho en papel, permitiendo realizar preguntas a los usuarios sobre determinados aspectos del producto. Su valor está en que se puede obtener información crítica de una manera rápida y a un bajo costo. Evaluación Heurística Es una técnica en la que expertos y especialistas en usabilidad se encargan de la evaluación de un producto, siguiendo una serie de principios o heurísticas establecidos en la usabilidad. Pruebas de usabilidad Implican técnicas para recolectar información empírica a través de la observación de usuarios finales interactuando con el producto final y desarrollando tareas específicas. Se tiene dos enfoques: i) pruebas formales realizadas como 26 verdaderos experimentos con el fin de afirmar o rechazar hipótesis específicas, y ii) evaluaciones menos formales que implican ciclos iterativos de pruebas para identificar deficiencias en la usabilidad e ir modificando gradualmente el producto. Estudios de seguimiento Se llevan a cabo después del primer lanzamiento oficial del producto final. Su objetivo es recolectar información para el siguiente lanzamiento usando encuestas, entrevistas y observaciones. 1.6.2 Metodologías Ágiles Los enfoques ágiles se utilizan normalmente en el desarrollo de software para ayudar a las empresas a responder a la imprevisibilidad, proponen alternativas a la gestión tradicional de proyectos y ofrecen oportunidades para evaluar la dirección en todo el ciclo de vida de desarrollo [18]. Las metodologías ágiles se caracterizan por ser iterativas e incrementales, ya que se centran en la repetición de los ciclos de trabajo abreviados así como del producto funcional [18]. Los principios de las metodologías ágiles son [19]: - Satisfacción del cliente por la entrega de software útil. - Bienvenidos cambios en los requisitos, incluso en etapas tardías de la programación. - El software funcional es entregado con frecuencia (semanas en lugar de meses). - El software funcional es la principal medida de progreso. - Desarrollo sostenible, capaz de mantener un ritmo constante. - Cooperación diaria y cercana entre los encargados de negocios y desarrolladores. - Conversación cara a cara es la mejor forma de comunicación. - Los proyectos se construyen en torno a individuos motivados, en los cuales se debe confiar. - Atención constante a la excelencia técnica y al buen diseño. - Simplicidad. - Equipos auto-organizados. - Adaptación regular a circunstancias cambiantes. Algunas de las metodologías ágiles más relevantes son: 27  SCRUM Scrum es un marco de trabajo que se centra en la gestión de proyectos, ofrece algunas técnicas y procesos para mostrar la eficacia de las prácticas de gestión de producto y las prácticas de desarrollo de software [20]. Scrum empieza cuando el dueño del producto gestiona las prioridades de la lista del producto o product backlog y a partir de este el equipo plantea su planificación de iteraciones. Cada una de estas iteraciones es conocida como sprint, la cual consta de dos a cuatro semanas de duración, considerando reuniones diarias para evaluar el progreso. Cada sprint comienza con la planificación y termina con una revisión y retroalimentación. Luego el equipo y el dueño del producto deciden qué se tomará en cuenta para la siguiente iteración [21]. Los tres roles fundamentales de Scrum son [20]: - Dueño del producto (Product Owner), es el responsable de maximizar el valor del producto y del trabajo del equipo de desarrollo. Es el rol con más poder de decisión en el proyecto. - Scrum Master, es el responsable de asegurar que Scrum es entendido y adoptado, actúa como un facilitador entre el dueño del producto y el equipo de desarrollo. - Equipo de desarrollo (Team Member), está conformado por las personas encargadas de entregar un incremento de producto funcional, que potencialmente se pueda poner en producción, al final de cada sprint.  Extreme Programming (XP) XP es una metodología que está centrada en las mejores prácticas de programación, las cuales se describen a continuación [13]: - Planificación del juego. El cliente decide el alcance y el calendario de versiones basados en tiempos estimados por los programadores. - Pequeñas versiones, que se realizan diaria o mensualmente, lo que permite poner el sistema en producción en pocos meses. - La metáfora. La forma del sistema está definida por una metáfora o un conjunto de metáforas compartidas entre el cliente y los programadores. - Diseño simple. En cada momento el diseño ejecuta todas las pruebas, comunica todo lo que los programadores quieren comunicar, no contiene código duplicado y tiene el menor número de clases y métodos posibles. - Las pruebas. Los programadores escriben pruebas unitarias minuto a minuto, y todas deben ser ejecutadas correctamente. 28 - La refactorización. El diseño del sistema está desarrollado a través de transformaciones del diseño existente que mantiene todas las pruebas en funcionamiento. - Programación en pares. Todo el código de producción está escrito por dos personas en una pantalla/teclado/mouse. - Integración continua, lo que permite que nuevo código sea integrado al sistema actual en unas pocas horas. - Propiedad colectiva. Todos los programadores pueden mejorar cualquier código en cualquier lugar del sistema en cualquier momento si tienen la oportunidad. - El cliente en su lugar, lo que implica tener al cliente todo el tiempo con el equipo. - 40 horas semanales. Nadie puede trabajar una segunda semana de sobretiempo pues sino sería una señal de problemas que deben ser resueltos. - Espacio de trabajo abierto. El equipo trabaja en una amplia sala con pequeños cubículos. - Solo reglas. El equipo puede cambiar las reglas en cualquier momento siempre y cuando estén de acuerdo en la forma en que evaluarán los efectos de la variación.  Feature Driven Development (FDD) FDD es una metodología de desarrollo ágil que se centra principalmente en dos grandes etapas. La primera etapa es descubrir la lista de características que serán implementadas, y por lo tanto es la etapa crucial, ya que la precisión del seguimiento de proyectos y la capacidad de mantenimiento y extensión del código depende, sobre todo, de la calidad de trabajo realizado en esta etapa. La segunda etapa consiste en la implementación de característica por característica. Las características comunes son agrupadas en un paquete de trabajo y este debe ser desarrollado en una iteración, la cual tiene una duración de una a tres semanas y al finalizar debe ser entregada al cliente para sus respectivas pruebas [22] .  Adaptative Software Development Esta metodología empieza con la fase de iniciación del proyecto, donde se definen los ciclos de desarrollo y la programación de ellos. Varios componentes están en desarrollo concurrente en la fase de colaboración; sin embargo, los componentes son redefinidos constantemente y es por eso que la planificación del ciclo de desarrollo es una parte del proceso iterativo. En la etapa final se recopilan las lecciones aprendidas sobre la perspectiva del cliente, calidad de resultados desde una perspectiva técnica y las prácticas y funciones desarrolladas en el equipo durante la ejecución del proyecto [22]. 29  Dynamic Software Development Method (DSDM) DSDM es una metodología que exige la obediencia estricta de los siguientes 9 principios [23] : - La participación activa del usuario es imperativa, ya que al involucrarlo en el proyecto se reducen errores de percepción y por lo tanto se reducen costos de error. - Los equipos deben estar autorizados para tomar decisiones acerca de los requerimiento en práctica, qué funcionalidades se incluirán en un incremento, priorización de requisitos y características y pequeños detalles acerca de las soluciones técnicas. - Las entregas frecuentes aseguran que los errores sean detectados rápidamente y su corrección sea más fácil por estar cerca a la fuente de error. - El principal esfuerzo es ofrecer software suficientemente bueno como para resolver las necesidades actuales del negocio y plantear mejoras para una iteración posterior. - El desarrollo iterativo e incremental permite manejar la complejidad de los proyectos y aceptar el hecho de que cualquier sistema está sujeto a cambios. - Todos los cambios deben ser reversibles, ya que el cambio en las prioridades de los requisitos implican cambios en la configuración del sistema durante el desarrollo de cualquier incremento. - Requisitos de alto nivel definidos como línea base, los cuales serán invariables durante todo el proyecto. - Las pruebas son integradas a lo largo del ciclo de vida. - Enfoque colaborativo y cooperativo entre el personal de desarrollo y el personal de negocios. 1.6.3 Resumen Se puede observar que el diseño centrado en el usuario tiene como principal objetivo conseguir el mayor grado de usabilidad de un producto software. Entiéndase por usabilidad a la calidad del software que permite que usuarios específicos realicen tareas específicas en un contexto específico. Con este fin, UCD plantea una serie de principios que se deben aplicar en todo proyecto y se propone, además, algunas técnicas y métodos que se pueden utilizar a lo largo del proceso de desarrollo, ya sea en la fase de análisis, implementación o evaluación. Si bien es cierto que UCD se enfoca, sobre todo, en etapas tempranas del proceso, es decir, en la parte del diseño, las metodologías ágiles ofrecen una serie de principios y actividades como alternativa a las metodologías tradicionales para 30 llevarlas a cabo durante la etapa de implementación del software. Las metodologías ágiles se caracterizan por ser iterativas e incrementales. Se proponen las más relevantes y según su enfoque se puede aplicar a diferentes proyectos según sea su necesidad. 1.7 Estado del arte En esta sección se presentarán estudios realizados que ayudarán a contextualizar la problemática planteada. De tal manera, se describirán estudios sobre la integración de Metodologías de Desarrollo Ágil con el Diseño Centrado en el Usuario, donde se podrá observar evaluaciones de los beneficios y problemas que surgen al integrar estos dos enfoques, además de describir algunos casos en los que se experimentó esta forma de trabajo. 1.7.1 Objetivos de la revisión del estado del arte El objetivo de este capítulo es describir casos en los que se integraron metodologías ágiles con UCD para evaluar su comportamiento y detectar beneficios, problemas y recomendaciones sobre este enfoque de trabajo. A continuación se presentan cuatro estudios realizados que ilustrarán la integración de Metodologías Ágiles con el Diseño Centrado en el Usuario. El primer estudio permite determinar los beneficios de integrar ambas metodologías y los siguientes tres fueron elegidos basados en la revisión sistemática existente sobre usabilidad en metodologías ágiles [4]. Dicha revisión tiene como objetivo investigar cuáles son las técnicas, patrones y principios de usabilidad aplicados al desarrollo de software ágil y cómo han sido empleados. Debido a que el presente Proyecto consistirá en la realización de un caso práctico sobre el uso de este enfoque, solo se consideró el resultado de los artículos seleccionados donde se describen casos en los que se usaron técnicas de usabilidad y desarrollo de software ágil. 1.7.2 Discusión sobre el estado del arte  Investigating agile user-centered design in practice: A grounded theory perspective [24] Es un estudio cualitativo que busca determinar la forma en la que se lleva a cabo la integración de metodologías ágiles con métodos de UCD. Los datos fueron recolectados por medio de entrevistas semi-estructuradas y la observación de los 31 profesionales que ya trabajaron con el enfoque ágil y UCD integrados en otras oportunidades. La investigación consiste en determinar una pequeña muestra de 5 participantes: - El participante número 1 es un experto en usabilidad que ofrece consultoría en proyectos ágiles y tradicionales, asume el rol de especialista. - El participante número 2 es un desarrollador que tiene interés en usabilidad, por lo que desempeña el rol de generalista. En sus proyectos usa una combinación de XP y Scrum, modificando sus prácticas de acuerdo al contexto. - El participante número 3 es un administrador de programas que trabaja en proyectos con Scrum y asume también el rol de especialista. - El participante número 4 es un entrenador de metodologías ágiles, consultor y Máster certificado en Scrum. En sus equipos de proyectos, suele trabajar con especialistas en Interacción con el Usuario, por lo que, al desarrollar sus proyectos, los conceptos generales de usabilidad son discutidos por todo el equipo, incluyendo la administración. En este caso, el participante asume el rol híbrido, pues tiene experiencia en metodologías ágiles y también en el Diseño Centrado en el Usuario. - El participante número 5 es un desarrollador y gerente de proyecto que también tiene experiencia en usabilidad, entonces asume el rol híbrido. Los temas emergentes que se encontraron en este estudio muestran que los miembros de equipos ágiles toman cada vez más conciencia sobre la importancia de la usabilidad en el desarrollo de software, mientras que los métodos ágiles también ofrecen ventajas al enfoque UCD para su integración. Los participantes también mencionan que la integración de UCD en el desarrollo ágil ha mejorado la calidad y facilidad de uso del software que desarrollan y el aumento de la satisfacción de los usuarios. Algunos también señalan que esta integración ha añadido valor al equipo de desarrollo y sus procesos.  Towards a framework for integrating agile development and user- centred design [25] Se presenta un estudio de campo diseñado para investigar el uso de metodologías ágiles junto con UCD, su objetivo es encontrar los problemas que enfrenta un equipo de proyecto al aplicar Scrum, XP y UCD en una organización en particular. 32 La investigación consiste en la observación de tres equipos de proyecto de 2 a 4 horas por semana en un periodo de 6 meses. La organización en la que se lleva a cabo la experimentación es una empresa caracterizada por el uso del enfoque centrado en el usuario para el desarrollo de software. Se generaron 3 equipos referidos como Proyecto I, Proyecto S y Proyecto M, y cada uno está integrado por desarrolladores y diseñadores. En la Tabla 1, se muestra un resumen de los proyectos observados durante el estudio. Características Proyecto I Proyecto M Proyecto S Aplicación del proyecto Página web para involucrar a las personas en la vida cívica local, incluyendo la comunidad en línea para promover e involucrarse en el público político. Aplicación de TV interactiva: un cuestionario interactivo diseñado para complementar un programa de TV. Página web basada en un tablero de mensajes para la organización del estudio. Metodología UCD y Scrum UCD y XP UCD y Scrum Principal grupo de usuarios Miembros del público. Miembros del público. Miembros del público. Otros Usuarios Editores de contenido para la página web. Administradores y editores. Administradores. Tabla 3. Resumen de los proyectos observados. Imagen adaptada de Chamberlain, Sharp, & Maiden, 2006 Como resultado del estudio y la observación de estos tres proyectos se obtienen algunos principios para considerar al evaluar la integración de UCD con metodologías ágiles: - Participación de los Usuarios. - Colaboración y cultura. 33 - Prototipado. - Ciclo de vida del proyecto. En estos trabajos se observa que existe un problema fundamental en la comunicación entre los diseñadores y desarrolladores dentro de cada equipo. Los diseñadores dentro de un proyecto defienden su disciplina en respuesta a las decisiones tomadas por los desarrolladores, y viceversa; por lo tanto, se debe encontrar un punto de equilibrio para garantizar que esta lucha por el poder sea controlada en un proyecto. El prototipado también parece ser una problemática debido a las escalas de tiempo implicadas en el desarrollo de una aplicación en comparación con el diseño de un prototipo de papel. Sin embargo, esto puede ser mejorado si los diseñadores gestionan de manera que se evite el retraso entre la retroalimentación y la implementación.  The impact of agile on user-centered design [26] En este estudio se plantea el caso de una empresa vendedora de soluciones de software para la industria de Tecnologías de Información que contrata al Centro de Usabilidad de la Universidad Estatal Politécnica del Sur para aplicar evaluaciones de usabilidad en los productos que desarrollan. Ambos trabajaron juntos por un periodo de 2 años, tiempo en el cual el Centro de Usabilidad ayudó a la empresa a implantar evaluaciones iterativas de prototipos e interacciones tempranas con los productos en varias etapas del desarrollo. Sin embargo, pasado este tiempo, se empezó a restar importancia a las técnicas de usabilidad formales y la empresa siguió trabajando con su enfoque inicial de metodologías ágiles pero adicionando técnicas informales de usabilidad. Después de analizar este caso, se puede apreciar la importancia que la empresa le da a la usabilidad, la complejidad de la integración de técnicas formales al proceso de construcción y la necesidad de técnicas de usabilidad tan flexibles como el desarrollo ágil.  Little design up-front: a design science approach to integrating usability into agile requirements engineering [27] Este estudio consiste en el desarrollo de dos proyectos ágiles con equipos diferentes. El primero servirá como línea base para el segundo, el cual incluirá el enfoque del Diseño Centrado en el Usuario. 34 En el primer proyecto se definieron 3 roles, Product Owner, Agile Coach y el equipo de trabajo. El Product Owner proveerá los requisitos a nivel abstracto de ambos proyectos y participará en las tareas relacionadas al análisis del backlog. El Agile Coach será el encargado de proveer direcciones para el proyecto y es el responsable de solucionar los impedimentos del proceso. El equipo de trabajo tomará las decisiones necesarias para alcanzar las metas de cada iteración y se encargará además del desarrollo del software. En el segundo proyecto se trabajó con un Agile Coach diferente y dos diseñadores centrados en el usuario que trabajaron con un equipo de desarrollo diferente. El objetivo de este estudio es validar la proposición de que incorporando la perspectiva de UCD en el desarrollo de software ágil se incrementa la calidad del diseño del software. Los resultados después de evaluar estos dos proyectos, coinciden con esta proposición y muestran que los usuarios encuentran los productos desarrollados bajo este enfoque más fácil de aprender y usar. En la Tabla 5 se puede observar las principales observaciones de cada uno de los artículos seleccionados. Investigating agile user-centered design in practice: A grounded theory perspective Beneficios de integrar metodologías ágiles con UCD: - Los miembros de equipos ágiles toman cada vez más conciencia sobre la importancia de la usabilidad en el desarrollo de software - Se mejora la calidad y facilidad de uso del software que se desarrolla. - Aumento de la satisfacción de los usuarios. - Se añade valor al equipo de desarrollo y sus procesos. 35 Towards a framework for integrating agile development and user- centred design Inconvenientes al integrar metodologías ágiles con UCD: - Problema fundamental en la comunicación entre los diseñadores y desarrolladores dentro de cada equipo. - Los diseñadores y desarrolladores defienden su disciplina en respuesta a las decisiones tomadas respectivamente. Solución: Encontrar un punto de equilibrio para garantizar que esta lucha por el poder sea controlada en un proyecto. - El prototipado, debido a las escalas de tiempo implicadas en el desarrollo, en comparación con el diseño de un prototipo de papel. Solución: Gestionar con los diseñadores de manera que se evite el retraso entre la retroalimentación y la implementación. The impact of agile on user-centered design Las evaluaciones informales de usabilidad y otros métodos informales para la recolección de requerimientos del usuario son percibidos por muchos por encajar mejor con el proceso de desarrollo ágil y son potencialmente tan efectivos como las evaluaciones formales. Little design up-front: a design science approach to integrating usability into agile requirements engineering Se valida la proposición de que incorporando la perspectiva de UCD en el desarrollo de software ágil se incrementa la calidad del diseño del software. Tabla 4. Resultados encontrados en los 4 artículos presentados. [Elaboración propia] 1.7.3 Conclusiones sobre el estado del arte Según lo analizado, en estos trabajos se observa que no hay alguna metodología completa que incluya los principios de las Metodologías Ágiles con los conceptos del Diseño Centrado en el Usuario; sin embargo, la integración de ambas metodologías tiene muchos beneficios en los casos prácticos, tanto para el software que se desarrolla como para el equipo de trabajo. Se mejora la calidad y facilidad de uso del software y también añade valor al equipo de desarrollo y sus procesos. Además el resultado del producto que se obtiene después de utilizar estos dos enfoques, sirve para que los usuarios finales encuentren el producto más fácil de aprender y usar, cumpliendo las características de usabilidad del software. Por otro lado, se puede observar también que se encuentran algunas dificultades al integrar estas dos metodologías, como la falta de comunicación entre diseñadores y desarrolladores, lo que puede causar retrasos en el proyecto o conflictos porque 36 cada equipo defiende su disciplina. Sin embargo, en base a esto se plantean algunas recomendaciones como encontrar un punto de equilibrio para garantizar que tanto diseñadores como desarrolladores tengan una buena comunicación o gestionar de manera que se evite el retraso entre la retroalimentación y la implementación. También se menciona el uso de evaluaciones y métodos informales de usabilidad que encajan mejor con el proceso de desarrollo ágil y son tan efectivas como las evaluaciones formales. 37 Capítulo 2 Levantamiento de requisitos El presente capítulo pretende alcanzar el primer objetivo respecto a la integración de herramientas que ofrecen las Metodología Ágiles y UCD para el levantamiento de requisitos. En primer lugar, se define la metodología ágil a usar y se describe el caso que se desarrolló en el presente Proyecto como parte de la investigación - acción. A continuación se explica la propuesta de integración de la metodología ágil con las herramientas de UCD elegidas. Finalmente, se aplica esta integración para el levantamiento de requisitos y, de esta manera, obtener la lista de requisitos definida para el desarrollo de la aplicación. La metodología ágil elegida para desarrollar la investigación – acción del presente proyecto es Extreme Programming (XP). XP es un proceso de desarrollo de software, el cual busca resolver frecuentes problemas de la ingeniería del software [28]. La palabra “extreme” en el nombre se refiere al hecho de que las mejores prácticas en el desarrollo del software son llevadas al extremo: si las pruebas son buenas, se hacen pruebas todo el tiempo, incluyendo pruebas de integración y funcionalidad; si las revisiones del código son buenas, se revisa el código todo el tiempo; si las iteraciones cortas son buenas, se hace las iteraciones realmente cortas; si el diseño es bueno, se convierte en el trabajo diario de todos; etc. [28] Los ciclos de planificación muy cortos son característicos de XP así como la concentración en lo que es factible y en lo que es más importante para el cliente [28]. En la Figura 1 se observa el proceso básico de XP [29]. Figura 1. Proceso Básico de XP. Imagen adaptada de Wolkerstorfer, Peter, et al (2008) Inicialización del Proyecto Desarrollo de Iteraciones Pruebas Unitarias Lanzamiento del Producto Producción 38 En XP, el proceso de desarrollo está dividido en iteraciones, las cuales duran aproximadamente de 1 a 4 semanas y cuyo fin es entregar software útil con funcionalidades adicionales al cliente. Al principio de cada iteración, se lleva a cabo una etapa de “Planificación del Juego” en el que se plantean los requisitos de los clientes y las historias de usuarios, que serán elegidos e implementados en la siguiente iteración. Después de ello, se llevan a cabo pruebas de aceptación para cada historia de usuario y asegurarse de que todas las historias han sido implementadas correctamente [30]. Cabe mencionar, que en el presente Proyecto no se cubrirán las etapas de Lanzamiento del producto ni la Producción. 2.1 Caso a desarrollar en la investigación - acción “Las áreas verdes de la PUCP constituyen un importante patrimonio natural, así como un particular sistema de difusión externo de biodiversidad; por ello, resulta necesaria una adecuada gestión técnica de las mismas” [31]. La PUCP cuenta con una Oficina de Servicios Generales, que forma parte de la Dirección de Administración y Finanzas, y busca establecer un Sistema de Gestión Ambiental, considerando un plan del manejo de la biodiversidad. Como resultado de este plan se cuenta con un registro de plantas existentes en el campus, las cuales fueron censadas, por última vez, a mediados del año 2013. Además, se vienen realizando otros proyectos como el Proyecto Jardín Botánico PUCP [32], el cual busca también fomentar la biodiversidad de la flora en el campus. Por esta razón, el caso a desarrollar en la investigación – acción del presente proyecto consistirá en el diseño y desarrollo de una aplicación para dispositivos móviles para un catálogo de plantas de la PUCP, el cual podrá ser utilizado no solo por los estudiantes, sino también por docentes y cualquier persona interesada en fomentar o conocer la diversidad de plantas de la Universidad. 2.2 Integración propuesta En la Figura 2 se observa el proceso básico de XP con la integración de las herramientas de UCD que se propone como parte del plan de la investigación – acción del presente proyecto. Esta integración está basada en un caso de estudio desarrollado por Wolkerstorfer, Peter, et al. [29] en el que se usan herramientas para combinar las ventajas de XP con las ventajas del proceso de Diseño Centrado en Usuario. El enfoque utilizado en dicho caso es un proceso ágil de usabilidad, en el que se identifican algunas falencias del proceso básico de XP y para resolverlas se propone usar 5 herramientas de UCD: Pruebas unitarias extendidas para la 39 evaluación automatizada de usabilidad; Extreme Personas, una variación del clásico método de Personas para extender las típicas historia de usuarios de XP; estudio de usuarios, a través de grupos de investigación, entrevistas y diarios para conocer a los usuarios finales; evaluaciones de expertos de usabilidad y pruebas unitarias de usabilidad. Teniendo ello en cuenta, se decidió usar entrevistas, para el estudio de usuarios; el planteamiento de Personas; y evaluaciones de usabilidad en cada iteración y en la última fase, cuando se obtuvo el producto final. Sin embargo, se decidió usar también Escenarios, en lugar de usar historias de usuarios que es la típica herramienta utilizada en XP. Si bien es cierto la ingeniería de usabilidad y XP comparten algunos métodos similares para alcanzar sus objetivos, las historias de usuarios podrían no ser suficientes desde la perspectiva de la usabilidad [30]. Obendorf & Finck [33] proponen un método que utiliza la técnica de Escenarios en XP mediante la presentación de casos de estudio que muestran que las técnicas de usabilidad tienen un mayor impacto en los procesos de software ágil. Se considera que al usar Escenarios se podrá involucrar de mejor manera a los usuarios y obtener mejores resultados ya que este método se centra en las necesidades de los usuarios y no en el software funcional como en las historias de usuarios [33]. Figura 2. Proceso de XP integrado con herramientas de UCD para el presente proyecto. [Elaboración propia] Inicialización del Proyecto Desarrollo de iteraciones Pruebas Unitaria Lanzamiento del Producto Producción Entrevistas semi estructuradas Escenarios Evaluaciones de usuarios Evaluaciones de usuarios Personas 40 2.3 Aplicación de la integración propuesta para el levantamiento de requisitos En primer lugar, la idea básica acerca de lo que la aplicación debería hacer fue planteada a través de entrevistas semi-estructuradas que se realizaron con posibles usuarios finales de la aplicación. Después de ello, se realizó el planteamiento de Personas con el fin de establecer los grupos de personas que interactuarán con el producto. Finalmente se crearon los Escenarios con el fin de dar soporte y llevar las Personas a la vida. La transición de la fase inicial al proceso de las iteraciones de XP se desarrolló con el uso de los Escenarios, los cuales son una salida de la fase inicial y son un prerrequisito para el desarrollo futuro. 2.3.1 Entrevistas El objetivo de las entrevistas no es obtener respuestas correctas o incorrectas, sino que fueron planteadas con el fin de obtener nuevas ideas para la creación del producto. Para la investigación, se empleó el tipo de entrevista semi – estructurada, en la que se planteó un grupo de preguntas específicas sobre la cual el entrevistador tenía la posibilidad de introducir libremente preguntas adicionales para obtener mayor información sobre los usuarios y las características de la aplicación. Los entrevistados seleccionados fueron 3 investigadores de la PUCP del área de Ciencias de la Computación, integrantes del Grupo de Reconocimiento de Patrones e Inteligencia Artificial Aplicada (GRPIAA) que actualmente trabajan con el proyecto “Aplicación de visión computacional en la generación de un catálogo para la conservación de la biodiversidad de plantas endémicas”. Ellos fueron catalogados como los usuarios expertos de la aplicación. Se debe tener en cuenta, que se pretende que la aplicación sea desarrollada para ser fácilmente adaptable a otros proyectos cobre catálogos de plantas. Por esta razón y debido a que el uso de aplicaciones móviles sobre catálogos de plantas no es muy común, se pudo observar que los usuarios no tenían una idea clara de la funcionalidad de la aplicación; por consiguiente, se vio la necesidad de incluir evaluaciones de casos existentes sobre aplicaciones de catálogos de plantas, con el fin de incentivar a los usuarios a plasmar ideas concretas sobre los usos de la aplicación a desarrollar. 41 La entrevista planteada, que se puede observar en el Anexo A del presente documento, fue estructurada de la siguiente manera: una introducción en la que se plantea el objetivo de la entrevista, una sección en la que se recopila información básica sobre el entrevistado y sobre el uso de aplicaciones en dispositivos móviles y una sección en la que se recoge información cualitativa sobre el uso de aplicaciones de catálogos de plantas existentes. En esta última sección, se recurre a un modelo teórico conocido como Technology Aceptance Model (TAM), el cual intenta explicar y predecir la aceptación de herramientas tecnológicas por parte de un determinado grupo de usuarios en contextos específicos [34]. Según este modelo, se plantearon preguntas para evaluar las aplicaciones existentes a través de 3 variables: - Facilidad de uso: Grado en que una persona considera que el uso de un método en particular está libre de esfuerzo. - Utilidad percibida: grado en que una persona considera que el uso de un método en particular alcanzará sus objetivos previstos. - Intención de Uso: Variable para predecir la adopción en la práctica, definida como el grado en que una persona tiene intenciones de usar un método específico.  Resultados de las entrevistas Se realizó una entrevista previa, la cual formó parte de la etapa piloto para así lograr afinar y verificar el cuestionario, garantizando que se podrá obtener la información deseada. Debido a que esta etapa mostró que dichas preguntas estaban correctamente encaminadas, se continuó realizando las siguientes entrevistas. Todos los entrevistados tenían conocimiento sobre el uso de aplicaciones en dispositivos móviles; sin embargo, sólo uno de ellos había interactuado con una aplicación de catálogo de plantas previamente. La mayoría estaba más familiarizado con el Sistema Operativo Android pero no tuvieron inconvenientes al interactuar con aplicaciones en dispositivos móviles con iOS. Se evaluaron 5 aplicaciones sobre catálogos de plantas que se encuentran en las tiendas online de dispositivos móviles, 3 de ellas desarrolladas en plataforma Android y las otras 2 en plataforma iOS. Para ello, se otorgó a los usuarios 42 dispositivos móviles que tenían instaladas las 5 aplicaciones y se observó la interacción con ellas. En la Tabla 6 se puede observar la lista de aplicaciones móviles que fueron presentadas a los entrevistados. Nombre de la aplicación Plataforma (A1) Garden Plant Growing Guide Google play: https://play.google.com/store/apps/details?id=com.pb agardenplants Android (A2) Pl@ntNet Identificación Planta Google play: https://play.google.com/store/apps/details?id=org.plan tnet Android (A3) Plants Google play: https://play.google.com/store/apps/details?id=com.bi m.plant Android (A4) Plant Finder Lite App Store: https://itunes.apple.com/us/app/plant-finder- lite/id709804498?mt=8 iOS (A5) Biology Plant Handbook App Store: https://itunes.apple.com/gb/app/biology-plant- handbook/id539994995?mt=8&ign-mpt=uo%3D4 iOS Tabla 5. Aplicaciones móviles presentadas a los entrevistados. [Elaboración propia] Siguiendo las 3 variables de TAM, se obtuvieron los siguientes resultados: - Facilidad de uso: La aplicación (A1) es considerada la más intuitiva, ya que los pasos para llegar a la búsqueda son muy rápidos y toda la información se muestra en una sola pantalla. Sin embargo, el usuario que ya tenía conocimiento previo sobre aplicaciones similares, indicó que la aplicación (A2) era muy intuitiva y que, si bien, se requerían más pasos para hacer búsquedas, estos se podían realizar de manera fácil y rápida. 43 - Utilidad percibida: Todos los usuarios coincidieron en que la aplicación (A3) muestra información más útil y detallada, ya que se especifica además de las características básicas de las plantas, los usos de ellas. Algunas funcionalidades que se destacan de las aplicaciones son las búsquedas de imágenes, el reconocimiento de una imagen a través de fotos subidas con el dispositivo móvil, la información sobre la localización de las plantas, agregar notas personales acerca de las plantas y agruparlas según la necesidad de cada usuario. La aplicación (A5) fue percibida como la menos útil de todas las aplicaciones presentadas debido a que su fin era educativo y no coincidía con el fin del proyecto. - Intención de Uso: Todos los usuarios mencionan, en primer lugar, la forma de búsqueda de las plantas como la principal característica para usar la aplicación. Uno de ellos menciona la importancia de que en la aplicación (A2) la información está constantemente actualizada debido a que recibe la información a través de servicios web. Se indica, además, que la principal forma de ordenar las plantas para este proyecto será siguiendo las últimas 3 categorías de una planta, es decir por familia, género y especie. Se considera también que se debe mostrar información adicional como uso de las plantas, lugar y entorno de crecimiento, tamaño, si tiene frutos o si es comestible. Se menciona también que la mejor forma de mostrar esta información es que esté acompañada de una imagen y el texto sea resumido, con opciones adicionales para ampliar la información. Con los resultados obtenidos de las entrevistas, se procedió a definir la lista de requisitos para la aplicación. Esta fue analizada y corregida junto con los usuarios expertos de la aplicación. Dichos requisitos se encuentran en el Anexo B del documento. 2.3.2 Personas El método de Personas fue desarrollado como una herramienta para aumentar la empatía con los usuarios finales en los equipos de desarrollo y donde una Persona representa a un típico grupo de usuarios [29]. Con los resultados de las entrevistas realizadas, se identificaron 4 Personas, las cuales representan los 4 grupos de usuarios que interactuarán con la aplicación. Al igual que con la lista de requisitos, estos grupos de usuarios fueron diseñados y revisados con los usuarios expertos. 44 2.3.3 Escenarios Los escenarios son desarrollados como historias informales acerca de las tareas y actividades que realizarán los usuarios, estos son usados, comúnmente, para expresar situaciones propuestas o imaginarias que ayudarán a diseñar el concepto de la aplicación. Los usuarios están activamente involucrados en la creación de estos escenarios [1]. Por esta razón, con las Personas definidas, se procedió a crear los escenarios e involucrar a los usuarios expertos para la refinación de ellos. En el Anexo C se puede observar las Personas y escenarios planteados. Con los resultados obtenidos de las Personas y Escenarios, se pudo definir los siguientes 4 grupos de usuarios que interactuarán con la aplicación: - Expertos que conocen sobre el tema de plantas. Saben exactamente lo que quieren buscar y se pueden referir a ellas según su taxonomía (Familia, género y especie) - Alumnos o personal de la Universidad que buscan información sobre una planta. Se pueden referir a ellas por su nombre común. - Alumnos o personal de la Universidad que quiere conocer sobre una planta a través de una fotografía. - Alumnos o personal de la Universidad que buscan plantas visualizando el mapa del campus de la PUCP. 45 Capítulo 3 Iteraciones El presente capítulo pretende alcanzar el segundo, tercer y cuarto objetivo respecto a la aplicación de las buenas prácticas que ofrece UCD en la fase del diseño de interfaces a lo largo de todo el desarrollo ágil del software. A partir del diseño planteado, se construyó el catálogo de plantas y se aplicaron evaluaciones de usabilidad en cada iteración del desarrollo para complementar la evaluación de calidad del software. Adicionalmente, se pretende alcanzar el quinto objetivo sobre el análisis del uso de guías de ayuda interactiva en cada una de las iteraciones. En primer lugar, se explica la planificación de las iteraciones para la construcción del producto software según XP. En segundo lugar, se presentan los resultados del uso de la herramienta conocida como prototipado para la construcción de la interfaz. Después de ello, se describe el método para las evaluaciones de usuarios que se desarrollará en cada iteración y así, finalmente, proceder a presentar los resultados de cada iteración. En el Anexo G, se puede observar una lista de comprobación de cada una de las funcionalidades que fueron implementadas en cada iteración según el catálogo de requisitos, junto con el detalle de las vistas de la interfaz y las modificaciones que hay entre cada una de ellas. Como se mencionó previamente, los escenarios son una salida de la fase inicial y un prerrequisito para comenzar con la implementación del aplicativo móvil. Por ello, con lo escenarios planteados se planificó realizar 4 iteraciones para la construcción de la aplicación y, siguiendo con el proceso de XP, al finalizar cada una de las iteraciones, se realizaron pruebas de funcionalidad para asegurar el correcto funcionamiento de los requisitos. Junto con los usuarios, se priorizaron los requisitos planteados para proceder a planificar las funcionalidades que fueron implementadas progresivamente en cada iteración. En el Anexo D se puede observar el catálogo de requisitos con la priorización que se dio a cada uno de los requisitos funcionales y la iteración en la que se desarrollaron. Respecto al tiempo de duración para cada iteración, se dio 1 semana para las dos primeras iteraciones, 2 semanas para la tercera y 1 semana para la última iteración. Cabe mencionar que la priorización y el tiempo que se dio a cada iteración están basados, no solo en la disponibilidad y necesidad de los usuarios, sino que también se tomó en cuenta la necesidad del desarrollador del software. Por ejemplo, la funcionalidad de capturar la foto de la hoja de una planta con el dispositivo móvil para obtener información sobre ella, se programó para la iteración 3. Esta iteración será la única que tendrá una mayor duración debido a que en esta etapa se integrará el algoritmo 46 de reconocimiento de imágenes con el aplicativo móvil, lo cual podría ocasionar retrasos en el desarrollo. Dicho algoritmo está siendo desarrollado por los integrantes del grupo de investigación GRPIAA, quienes a la vez están asumiendo el rol de usuarios expertos de la aplicación. Ellos planificaron que, aproximadamente, en un mes, contando desde que se inició dicho proyecto, tendrán listo el algoritmo, por lo que se hizo coincidir esta fecha con el inicio de la iteración 3. 3.1 Elaboración del Prototipo En función a las entrevistas y los grupos de usuarios ya definidos, se planteó el desarrollo de un prototipo de la aplicación. Para ello, se usó, en primer lugar, una herramienta conocida como prototipado en papel (Ver Anexo E) para que los usuarios tengan una mejor idea de las funcionalidades que tendrá la aplicación. Un prototipo en papel o de baja fidelidad es solo una representación de lo que podría ser implementado. La evaluación del prototipo se hace en la etapa inicial del proceso de diseño y normalmente se plantea para evaluar el concepto que se está pensando desarrollar y para determinar su utilidad y factibilidad antes de hacer mayores gastos en el diseño y desarrollo [14]. El prototipo se presentó a los mismos usuarios que fueron catalogados previamente como usuarios expertos de la aplicación y fue construido tomando en cuenta las opiniones que se obtuvieron después de evaluar las aplicaciones existentes sobre catálogos de plantas. 3.1.1 Resultados de la evaluación del prototipo Se pudo observar que el prototipo en papel fue una herramienta muy útil para incentivar e involucrar a los usuarios con la aplicación. A diferencia de la etapa en la que solo se evaluaron los requisitos, al presentar el prototipo a los usuarios, se obtuvo mayores comentarios y recomendaciones sobre la interfaz del catálogo de plantas. El prototipo en papel sirvió, también, como base para elaborar el prototipo de la aplicación en el Storyboard del Xcode, por lo que permitió evaluar el uso de algunas herramientas que proporciona Xcode para el desarrollo de aplicaciones en iOS. Entre las observaciones obtenidas resaltan los siguientes puntos: - Para cubrir las funcionalidades definidas en la lista de requisitos, la aplicación contará con 4 pestañas principales que se encontrarán en el Tab Bar de la aplicación (Ver Figura 3). Estas pestañas representarán las 4 funcionalidades principales de la aplicación: Un explorador, para buscar información sobre 47 una planta en particular; un mapa del Campus de la PUCP, que permitirá buscar las plantas que se encuentran en él; una cámara, que permitirá tomar la foto de una hoja y obtener información sobre las posibles plantas que podrían contener esa hoja; y un manual de usuario, que permitirá obtener información general sobre la aplicación, como su funcionamiento y el equipo de personas que trabajó en su desarrollo. Figura 3. Tab Bar en iOS. [Elaboración propia] - Se evaluó la inclusión de una herramienta conocida como scope bar (Ver Figura 5) en la primera página del buscador de plantas, para dar la opción a los usuarios de buscar directamente una planta en Familias, en Géneros o en Especies, sin la necesidad de pasar por cada una de las ventanas para llegar a lo que está buscado. Sin embargo, durante la evaluación del prototipo, se aclaró que una familia puede tener varios géneros con el mismo nombre, o un género puede tener varias especies con el mismo nombre. Por ejemplo, en la Figura 4 se puede observar que el nombre de la especie “Virginiana” pertenece a varios géneros diferentes, entonces si un usuario busca este nombre de especie en la aplicación, no sabría diferenciar a cuál de los tres géneros pertenece. 48 Por esta razón se indicó que para diferenciar a una planta se debe especificar una familia, un género y una especie y solo tendrá un nombre común, por lo que para buscar una planta en específico, se observó que el usuario siempre tendrá que seguir todo el flujo (Es decir buscar por familia, luego género y luego especie). En lugar de usar el scope bar con las opciones para buscar por género y especie, se incluirá una sola opción para buscar una planta directamente por nombre común. Figura 5. Scope Bar en iOS. [Elaboración propia] Figura 4. Ejemplo taxonomía de plantas. [Elaboración propia] Familia Fagaceae Familia Magnoliaceae Familia Cupressaceae Género Quercus Género Magnolia Especie Virginiana Especie Virginiana Género Juniperus Especie Virginiana 49 - El Uso de un index list con el abecedario en la parte lateral de la ventana del explorador (Ver Figura 6), para ayudar a la búsqueda, fue una funcionalidad que se sugirió en respuesta a la observación de las aplicaciones existentes, ya que los usuarios consideraron tedioso tener que bajar continuamente una página para buscar algún dato por la letra de inicio, sobre todo cuando la lista de datos era larga. Por ello se vio necesario incluir esta herramienta en las ventanas en las que se mostrará una lista de datos ordenada en una tabla. Figura 6. Index list en iOS [Elaboración propia]. - En cuanto a la ventana en la que se muestra la foto de una planta con la información básica sobre ella, los usuarios sugirieron incluir un enlace a algún sitio web, al que se pueda acceder y obtener mayor información sobre esa planta. - Respecto al mapa del campus de la PUCP, se observó que, por la misma razón que en el segundo punto, la búsqueda solo se hará por el nombre común de las plantas y ya no por familia, ni por género ni por especie. 50 Con el prototipo en papel planteado y las observaciones hechas se procedió a elaborar el prototipo de la aplicación en el Storyboard de Xcode6 (Ver Anexo E). Con este segundo prototipo, se pudo evaluar las necesidades desde el punto de vista del desarrollador de la aplicación, para definir el patrón de la arquitectura y estructuras de datos que se utilizarán para la construcción del software. 3.2 Diseño de la evaluación de cada iteración Se realizaron evaluaciones de usabilidad en cada una de las iteraciones y al final del desarrollo con el producto final. Debido a que las actividades y funcionalidades a evaluar en cada una de las iteraciones son pocas, se eligió usar un método rápido y fácil de usar, conocido como Pensamiento en voz alta. Cuando se tenga el producto final, al terminar las 4 iteraciones, se realizó la evaluación de usuarios propuesta por Jeff Rubin y Dana Chisnell con usuarios que representan cada uno de los grupos de usuarios definidos y, de esta manera, verificar que se ha obtenido una herramienta usable. 3.2.1 Pensamiento en voz alta La evaluación de usabilidad que se utilizó en cada una de las iteraciones es el Pensamiento en voz alta. Este método permitió entender el enfoque que tienen los usuarios de la interfaz y las consideraciones que tienen en mente al momento de interactuar con ella [30]. Esta evaluación se llevó a cabo con los 3 usuarios que fueron catalogados como usuarios expertos, los mismos que participaron en las entrevistas en la etapa inicial del proyecto. Cada autor tiene diferentes maneras de llevar a cabo este método, desde solo instrucciones hasta expectativas de gestos, es poco usual que el protocolo del esquema, ya sea el propuesto por Ericsson y Simon, o por Boren y Ramey, se siga estrictamente [35]. A continuación, se listan las principales etapas que se siguieron para llevar a cabo esta evaluación en el presente proyecto:  Preparación del entorno Las evaluaciones se llevaron a cabo en los laboratorios de la sección de Ingeniería Informática de la PUCP de manera presencial. Se brindó a los usuarios un dispositivo con plataforma iOS en el que está instalada la aplicación para que puedan interactuar con ella. Los comentarios y respuestas de los participantes fueron grabados con un dispositivo de grabación de audio. Las actitudes y reacciones que tuvieron fueron observadas y anotadas por el moderador. Es importante considerar que el moderador trate de no influir en el participante a través 51 del lenguaje corporal o el tono de voz, lo cual fue más fácil de lograr al sentarse ligeramente detrás del participante [35].  Antes de llevar a cabo el estudio El moderador explicó al participante en qué consistía la evaluación, explicándole la importancia de que exprese sus pensamientos en voz alta en todo momento y dándole algún ejemplo de ello para asegurarse de que haya entendido correctamente. Se debe recalcar a los participantes que el estudio busca evaluar la interfaz y no evaluar a los participantes, por lo que no hay respuestas correctas o incorrectas durante la evaluación.  Durante el estudio Se realizó la evaluación con cada usuario de manera individual y se le brindó una serie de tareas a realizar según la iteración que se está evaluando. Debido a que las funcionalidades fueron implementadas progresivamente en cada iteración, en cada una de las evaluaciones se consideró nuevamente la lista de tareas de la iteración anterior, para asegurar que se corrigieron las observaciones de la última evaluación. En esta etapa se debe tener en cuenta que cuando el participante hace alguna pregunta, el moderador debe considerar cuidadosamente cómo responderla de manera que se anime al usuario a seguir hablando y trabajar en el problema [35].  Después del estudio Después de que el participante completó todas las tareas propuestas, se preguntó si es que tiene algún comentario adicional o alguna duda sobre la interfaz. Además, después de realizar la prueba con cada uno de los 3 participantes, se les invitó a reunirse para compartir sus opiniones sobre las tareas evaluadas. Una vez que la sesión con los participantes terminó, se procedió a escuchar las grabaciones y anotar las observaciones y problemas que se dieron para solucionarlos en la siguiente iteración. 3.3 Iteración 1 Para la iteración 1 del aplicativo móvil, fue necesario desarrollar la base de datos con la que se maneja la información de la aplicación. Es importante mencionar, que se pretende usar una base de datos genérica, para que pueda ser fácilmente adaptable a otro tipo de proyectos. En la Figura 7 se puede observar el modelo de 52 datos planteado, el cual fue implementado en MySQL y subido a un servidor público de la PUCP. Figura 7. Modelo de Datos físico. [Elaboración propia] Con la base de datos definida, se procedió a elaborar los servicios web para poder intercambiar la información de la base de datos con el aplicativo móvil. La razón por la que se coloca la base de datos en un servidor y el desarrollo de los servicios es para que, posteriormente, en las evaluaciones con los usuarios se pueda simular el ambiente real con el que trabajarán, considerando los tiempos de carga de la información y de las imágenes cuando son actualizadas desde Internet. Posteriormente se procedió a desarrollar el primer escenario definido, el cual consiste en la búsqueda de la información de una planta. A continuación, en la Figura 8, se puede observar las vistas que fueron implementadas para esta iteración y el flujo que siguen. En el Anexo G se puede encontrar la información detallada sobre cada una de las vistas implementadas. Al finalizar la implementación de esta iteración, se procedió a llevar a cabo las pruebas funcionales respectivas, las cuales se encuentran en el Anexo F. 53 Figura 8. Vistas de la primera iteración. [Elaboración propia] 3.3.1 Resultados de la evaluación de la Iteración 1 Para la iteración 1 se evaluaron las siguientes actividades: - Buscar la información de una planta en específico siguiendo su taxonomía, es decir por Familia, Género y Especie - Buscar la información de una planta en específico por su nombre común. Siguiendo el diseño de la evaluación planteada, se brindó a los usuarios un iPad con la aplicación instalada y las actividades a realizar fueron las mencionadas previamente. 54 Después de transcribir los audios de las opiniones y comentarios de los participantes y de la observación de la interacción con la aplicación, se procedió al análisis e interpretación. En la Tabla 7, se puede observar una lista de características recopiladas durante la evaluación y el resultado de cada usuario, indicando con un check (✔) si se realizó con éxito o un aspa (✖) si ocurrió algún error o inconveniente. Posteriormente, los aspectos que tienen un aspa serán analizados con los comentarios y sugerencias de los usuarios para buscar alternativas de solución. N° Características Usuario 1 Usuario 2 Usuario 3 1 Actividades solicitadas completadas de manera satisfactoria. ✔ ✔ ✔ 2 Actividades solicitadas completadas sin ningún tipo de ayuda. ✔ ✔ ✔ 3 Reconocimiento y utilización adecuada de la barra de búsqueda en la parte superior de las ventanas de “Familias”, “Géneros” y “Especies”. ✔ ✔ ✔ 4 Reconocimiento y utilización de la barra lateral con el abecedario para la búsqueda por letra inicial en las ventanas de “Familias”, “Géneros” y “Especies”. ✔ ✖ ✖ 5 Considera que la información mostrada en el detalle de cada planta es suficiente. ✔ ✔ ✖ 6 Reconocimiento rápido del botón ubicado en la ventana del detalle de una planta para obtener más información sobre ella. ✔ ✔ ✔ 7 El tiempo requerido para realizar cada actividad se encuentra dentro del rango normal. ✔ ✔ ✔ 8 Colores de la interfaz utilizados adecuadamente. ✖ ✖ ✖ Tabla 6. Resultados de la evaluación de la primera iteración. [Elaboración propia] 55 - En el punto 4, se vio que solo un usuario utilizó la barra lateral con el abecedario para realizar búsquedas, los otros usuarios se percataron de este elemento recién al ver la ventana más de una vez. Sin embargo, consideraron que es un elemento importante que debe permanecer y sugirieron no incluir todo el abecedario, sino solo las letras de los elementos que se encuentran en la lista para no dar lugar a confusiones. - En cuanto al punto 5, sobre la ventana en la que se muestra el detalle de cada planta, los tres usuarios percibieron que no se mostraba la familia, género y especie de la planta, por lo que se apuntó como una mejora para la siguiente iteración. Respecto a la información mostrada, un usuario sugirió incluir algunos datos adicionales, como época de florecimiento y formas de cuidado de las plantas. - En el punto 7, sobre el tiempo que utilizaron los usuarios para realizar las actividades, se observó que completaron las tareas dentro del rango normal, pero cuando las imágenes demoraban un poco para ser mostradas y descargadas, los usuarios pensaban que había algún error, razón por la cual será necesario considerar una solución para la reducción de este tiempo de carga. - Sobre el punto 8, se pudo observar que los colores usados en la interfaz distraían la atención de los usuarios, por lo que se decidió usar colores más neutrales. El uso de esta evaluación para la primera iteración fue muy útil ya que permitió comprobar que los elementos de la aplicación estaban distribuidos adecuadamente. También se pudo observar que los usuarios perdían fácilmente la noción del flujo que estaban realizando, por lo que es una buena práctica mostrar en la cabecera de cada ventana el título de la categoría en la que se encuentra el usuario en todo momento. Si bien es cierto, se desarrollaron pruebas funcionales para asegurar el correcto funcionamiento del software, muchas veces no se cubren todos los casos que podrían suceder, por lo que utilizar este método de evaluación fue una forma muy rápida y confiable de obtener los errores de programación que tenía la aplicación. 56 3.4 Iteración 2 Para esta iteración, en primer lugar, se corrigieron los errores y observaciones encontradas después de la evaluación de la primera iteración, además de realizar algunos cambios en la interfaz de la aplicación. Posteriormente, se continuó con la implementación del segundo escenario, sobre la búsqueda de plantas por nombre común en el mapa del campus de la PUCP. Para ello, se integró la vista del mapa del campus desde Google Maps, para mostrar las ubicaciones de las diferentes plantas de la Universidad, y se implementó una vista de búsqueda para encontrar las plantas por nombre común. En el Anexo G, se puede visualizar los cambios realizados, comparados con las vistas de la primera interfaz, y la información detallada de las nuevas vistas implementadas. A continuación, en la Figura 9, se puede observar el flujo de la segunda iteración. 57 Figura 9. Vistas de la segunda iteración. [Elaboración propia] Siguiendo con la metodología XP, al finalizar esta iteración se desarrollaron las pruebas funcionales respectivas (Anexo F) para, posteriormente, continuar con las evaluaciones de usabilidad. 3.4.1 Resultados de la evaluación de la Iteración 2 Para la evaluación de esta iteración, se volvió a considerar las actividades evaluadas en la iteración 1 y se añadieron las siguientes: - Buscar una planta por su nombre común y ubicarla dentro del mapa del campus de la PUCP. - Acceder al detalle del ícono de una planta ubicada en el mapa. De igual manera, se procedió a transcribir los audios de las opiniones y comentarios de los participantes y se obtuvieron los siguientes resultados. N° Características Usuario 1 Usuario 2 Usuario 3 1 Actividades solicitadas completadas de manera satisfactoria. ✔ ✔ ✔ 2 Actividades solicitadas completadas sin ningún tipo de ayuda. ✔ ✔ ✔ 3 Reconocimiento y utilización adecuada del ícono de búsqueda ubicado en la parte superior de la vista del mapa. ✔ ✖ ✖ 4 El tiempo requerido para realizar cada actividad se encuentra dentro del rango normal. ✔ ✔ ✔ 5 Colores de la interfaz utilizados adecuadamente. ✔ ✔ ✔ Tabla 7. Resultados de la evaluación de la segunda iteración. [Elaboración propia] Dado que los usuarios ya habían interactuado previamente con la aplicación, esta vez realizaron las actividades mucho más rápido y de manera más natural. Respecto a las actividades de la primera iteración, sobre la búsqueda de 58 información de plantas, los tres usuarios se encontraron conformes con la funcionalidad y respondieron muy bien ante el cambio del diseño de la interfaz. En cuanto a las funcionalidades sobre el mapa, como se indica en el punto 3 de la Tabla 8, dos usuarios tuvieron inconvenientes para reconocer el botón de búsqueda ubicado en la parte superior de la ventana, por lo que se considerará cambiar su tamaño o color. Adicionalmente, algunas recomendaciones de los usuarios fueron que se incluya una opción en los marcadores de las plantas para acceder a mayor detalle sobre ellas. La evaluación en esta segunda iteración fue llevada a cabo de manera mucho más rápida ya que los participantes ya sabían en qué consistía y de qué manera debían llevarse a cabo las actividades. A diferencia de la primera iteración, se encontraron menos observaciones sobre la aplicación, dado que los usuarios ya estaban más familiarizados con la interfaz y comprendían de qué manera se estaban desarrollando las funcionalidades para cumplir con sus objetivos. Cabe recalcar que esta prueba sigue siendo muy útil para encontrar algunos errores que no se consideraron en las pruebas funcionales. 3.5 Iteración 3 Después de realizar las modificaciones correspondientes a los resultados de la evaluación de la segunda iteración, los cuales son detallados en el Anexo G, se procedió a desarrollar la funcionalidad sobre el reconocimiento de la foto de la hoja de una planta. Para ello, se integró una versión inicial del algoritmo de reconocimiento de imágenes que está siendo desarrollado por miembros del Grupo de Reconocimiento de Patrones e Inteligencia Artificial Aplicada (GRPIAA) de la PUCP, quienes a la vez están asumiendo el rol de usuarios expertos de la aplicación. Esta funcionalidad consiste en capturar una foto de la hoja de una planta a través de la cámara del dispositivo móvil, enviarla para ser evaluada y recibir una lista de plantas que podrían contener esa hoja. A continuación en la Figura 10, se puede observar el flujo de las vistas que fueron implementadas. 59 Figura 10. Vistas de la tercera iteración. [Elaboración propia] 3.5.1 Resultados de la evaluación de la Iteración 3 Para la evaluación de esta iteración, se consideraron todas las actividades indicadas en las iteraciones 1 y 2 y se añadieron las siguientes: - Buscar una planta en el mapa del campus de la PUCP y acceder al detalle de dicha planta. 60 - Tomar la foto de la hoja de una planta y obtener la lista de plantas que podrían contener esa hoja. - Utilizar una foto guardada en el dispositivo de la hoja de una planta y obtener la lista de plantas que podrían contener esa hoja. - Acceder al detalle de cada planta recibida en la lista de sugerencias de las plantas. Después de transcribir los audios y comentarios de los participantes durante la evaluación, se obtuvieron los siguientes resultados: N° Características Usuario 1 Usuario 2 Usuario 3 1 Actividades solicitadas completadas de manera satisfactoria. ✔ ✔ ✔ 2 Actividades solicitadas completadas sin ningún tipo de ayuda. ✔ ✔ ✔ 3 Reconocimiento de la funcionalidad para acceder al detalle de una planta después de ubicarla en el mapa del campus de la PUCP. ✔ ✖ ✖ 4 Reconocimiento adecuado del botón para tomar la foto. ✔ ✖ ✔ 5 El tiempo requerido para realizar cada actividad se encuentra dentro del rango normal. ✔ ✔ ✔ 6 Colores y distribución de los elementos de la interfaz utilizados adecuadamente. ✔ ✔ ✔ Tabla 8. Resultados de la evaluación de la tercera iteración. [Elaboración propia] Respecto a la evaluación de las actividades de la primera y segunda iteración, los usuarios estuvieron conformes con las modificaciones hechas. Sin embargo, respecto al punto 3, se pudo observar que los usuarios no percibían la imagen que se incluyó en la parte superior del mapa para presionar sobre ella y acceder a más información sobre dicha planta, por lo que se tendrá que hacer más visible la imagen y agregar información a los marcadores del mapa. Sobre la funcionalidad de descubrir hojas a través de la captura de una imagen, todos los usuarios completaron la actividad de manera satisfactoria, pero se sugirió hacer más visible 61 el botón para tomar una foto. Cabe mencionar que, inicialmente, se consideró utilizar un proceso de segmentación semi automática para enviar las imágenes y ser procesadas con el algoritmo; sin embargo, se vio que el algoritmo puede procesar, también, imágenes de la hoja con un fondo ligeramente claro, por lo que se decidió incluir una vista que llame rápidamente la atención del usuario y le dé indicaciones para tomar dicha foto sobre un fondo blanco para así obtener resultados con mayor porcentaje de semejanza. La evaluación en esta tercera iteración fue mucho más intuitiva y rápida de desarrollar con los usuarios pues ya sabían en qué consistía; sin embargo, a diferencia de la segunda iteración, al ver más funcionalidades integradas en la aplicación, sugirieron más ideas e incluso algunas funcionalidades, que, junto con el desarrollador, fueron evaluadas para ser o no implementadas. De igual manera, esta evaluación fue muy útil para encontrar errores que no fueron percibidos en las pruebas funcionales. 3.6 Iteración 4 Para esta última iteración, se realizaron las modificaciones correspondientes a los resultados de la evaluación de la tercera iteración detallados en el Anexo G y luego se procedió a desarrollar la vista sobre la información del grupo de personas que se están a cargo del proyecto de plantas de la Amazonía. En este caso, se incluyó la descripción y los contactos del Grupo de Reconocimiento de Patrones e Inteligencia Artificial Aplicada (GRPIAA) de la PUCP. A continuación en la Figura 11 se puede observar la vista implementada. Figura 11. Vista de la cuarta iteración. [Elaboración propia] 62 3.6.1 Resultados de la evaluación de la Iteración 4 Para la evaluación de esta iteración, se consideraron todas las actividades indicadas en las iteraciones 1, 2 y 3 y se añadieron las siguientes: - Acceder a cada uno de los contactos (Página web, facebook, twitter, correo) e información sobre el equipo que desarrolló la aplicación. - Guardar la imagen que se observa en el detalle de una planta. - Tomar la foto de una hoja y usarla posteriormente de la galería de imágenes del dispositivo para enviarla y ser evaluada por el algoritmo de reconocimiento de imágenes. Después de transcribir los audios y comentarios de los participantes durante la evaluación, se obtuvieron los siguientes resultados: N° Características Usuario 1 Usuario 2 Usuario 3 1 Actividades solicitadas completadas de manera satisfactoria. ✔ ✔ ✔ 2 Actividades solicitadas completadas sin ningún tipo de ayuda. ✔ ✔ ✔ 3 Reconocimiento y uso adecuado de la funcionalidad para acceder la información y contactos del equipo encargado de la aplicación. ✔ ✔ ✔ 4 Reconocimiento intuitivo del mecanismo para guardar una imagen. ✔ ✔ ✔ 5 El tiempo requerido para realizar cada actividad se encuentra dentro del rango normal. ✔ ✔ ✔ 6 Colores y distribución de los elementos de la interfaz utilizados adecuadamente. ✔ ✖ ✖ Tabla 9. Resultados de la evaluación de la cuarta iteración. [Elaboración propia] 63 Respecto a la evaluación de las modificaciones que se hicieron en las iteraciones 1, 2 y 3, todas fueron percibidas de manera muy buena por los usuarios y estaban conformes con ellas. En una evaluación previa los usuarios sugirieron agregar la posibilidad de guardar la imagen de una planta al observar el detalle de ella, por lo que se siguió un estándar de iOS que consiste en presionar la imagen por unos segundos y luego visualizar la opción para guardarla; sin embargo, esta funcionalidad no fue percibida rápidamente por algunos usuarios, pero después de unos segundos pudieron lograrlo sin ningún tipo de ayuda. Cabe resaltar que se debe incluir un mensaje de confirmación al guardar exitosamente la foto pues los usuarios no recibían ningún tipo de retroalimentación sobre la actividad realizada. Sobre el punto 6, se modificará la vista sobre la información y contactos del equipo, de manera que sea más atractiva para los usuarios. Finalmente, se sugirió la inclusión de mensajes de confirmación y de error adecuados para dar una retroalimentación a los usuarios. Al ser esta la última iteración, se indicó a los usuarios prestar mayor atención a los detalles y dar una retroalimentación sobre el producto total. Aunque hubo algunas sugerencias menores para mejorar la interfaz, todos los usuarios estuvieron conformes con el producto final de la aplicación, se pudo comprobar que con este tipo de evaluación periódica se obtuvo un producto adecuado a los usuarios con los que se trabajó y se evitaron hacer mayores cambios que pudieron ser costosos durante el desarrollo. 3.7 Conclusiones y análisis de uso de guías de ayuda interactiva En el Anexo H se pueden observar las pantallas del producto software obtenido después de llevar a cabo las 4 iteraciones planificadas. Finalmente, al analizar el proceso de integración en esta etapa se llega a las siguientes conclusiones: - Las pruebas de usabilidad, en este caso, pensamiento en voz alta, que se llevaron a cabo en cada una de las iteraciones se integraron muy bien con las pruebas funcionales que propone XP ya que permitieron encontrar errores que no se encontraron inicialmente al hacer las pruebas, lo cual contribuirá a asegurar que se está construyendo un producto funcionalmente aceptable. 64 - Adicionalmente, el pensamiento en voz alta es una herramienta muy útil para integrar con XP dado que no es muy compleja y permite que los usuarios se adapten fácilmente a la técnica. A medida que se desarrollan las iteraciones, los usuarios empiezan a expresar sus opiniones y pensamientos de manera más natural, lo que contribuye a obtener mejores críticas y observaciones acerca de la interfaz que se evalúa. - Al término de la evaluación de la segunda iteración, se pudo observar que se empezó a lograr un lenguaje común mejorando la comunicabilidad entre el desarrollador de la aplicación y los usuarios, pues la interacción de los usuarios con la aplicación fue mucho más natural. Esto debido a que el desarrollador empezó a conocer de mejor manera las expectativas y objetivos de los usuarios con los que estaba trabajando, mientras que los usuarios empezaron a comprender la manera en la que se estaba construyendo el software para alcanzar sus metas. - Inicialmente se pensó que el número de observaciones sobre la interfaz empezó a reducir a partir de la segunda iteración; sin embargo, se percibió que la cantidad de observaciones que se obtiene en cada iteración no depende del número de iteración o de la etapa en la que está el desarrollo del software, sino que depende del nivel de detalle con el que analizan los usuarios en cada una de las evaluaciones. Por esta razón, se llega a la conclusión de que una condición muy importante para que esta integración funcione, es que los usuarios y programadores encargados de la aplicación deben estar comprometidos con el proyecto y dispuestos a dedicar un tiempo para evaluar correctamente. 3.7.1 Análisis del uso de guías de ayuda interactiva A continuación, en la Tabla 10 se puede observar un análisis sobre la inclusión de guías de ayuda interactiva en cada una de las iteraciones: Uso de guías de ayuda interactiva Primera iteración Todos los usuarios reconocieron fácilmente las funcionalidades evaluadas en esta iteración, por lo que no se consideró necesario el uso de ninguna guía de ayuda interactiva. Segunda iteración En la vista del mapa del campus PUCP, se vio la necesidad de incluir un elemento de iluminación sobre la imagen de la planta que se está mostrando para llamar 65 la atención del usuario e incentivarlo a seleccionar la imagen para obtener mayor información. Tercera iteración Dado que la funcionalidad para tomar una foto de la hoja de una planta se integrará con un algoritmo de reconocimiento de imágenes, es necesario que el usuario capture una imagen sin contaminación, por lo que se vio necesario incluir una guía que sugiera al usuario cómo tomar la foto. Para ello, se incluyó una breve descripción que sea rápida de reconocer para guiar al usuario en la vista principal de esta funcionalidad. Cuarta iteración Todos los usuarios reconocieron fácilmente las funcionalidades evaluadas en esta iteración, por lo que no se consideró necesario el uso de ninguna guía de ayuda interactiva. Tabla 10. Uso de guías de ayuda interactiva en las iteraciones. [Elaboración propia] 66 Capítulo 4 Evaluación de Usuarios del producto final El presente capítulo pretende complementar el cuarto y quinto objetivo sobre aplicar evaluaciones de usabilidad de la interfaz construida en el presente proyecto, a través de una evaluación de usuarios que permita analizar la usabilidad del producto software obtenido. Adicionalmente, se analiza la inclusión de guías de ayuda interactiva para mejorar la experiencia del usuario. Se utilizó la evaluación de usuarios propuesta por Jeff Rubin y Dana Chisnell, la cual propone un enfoque menos formal y permite, sobre todo, obtener información cualitativa de la interfaz a evaluar. Dado que la construcción de la aplicación móvil formó parte de la investigación - acción del proyecto, para la evaluación, se vio la necesidad de comparar esta interfaz con otra aplicación con funcionalidades similares y, de esta manera, analizar si es que realmente se obtuvo un producto usable. Por esta razón, se evaluó el catálogo de plantas de la PUCP y una aplicación ya existente en el App Store, llamada Plant Finder. Si bien es cierto no se pueden comparar todas las funcionalidades pues no existe otra aplicación similar en el mercado, se decidió usar Plant Finder debido a que, además de ser desarrollada para la misma tecnología iOS, es la que tiene mayor semejanza con la aplicación construida. 4.1 Diseño de la evaluación de usuarios 4.1.1 Objetivos de la prueba: A continuación se presentan los objetivos de la evaluación de usuarios: - La prueba pretende evaluar la usabilidad de la aplicación para el catálogo de plantas de la PUCP, el cual fue desarrollado con la integración propuesta en el presente proyecto, comparado con otra aplicación existente sobre un catálogo de plantas con algunas características funcionales similares. - Identificar los obstáculos para completar correctamente las actividades de la aplicación para el catálogo de plantas de la PUCP. - La prueba verificará si la aplicación para el catálogo de plantas de la PUCP cuenta con las ayudas adecuadas para que el usuario pueda utilizarla sin requerir ayuda adicional. 67 4.1.2 Preguntas de investigación - Respecto al catálogo de plantas de la PUCP: ¿Cuán fácil es para los usuarios reconocer los componentes que permiten lanzar acciones? (Por ejemplo: botones, enlaces, íconos, etc.) - Respecto al catálogo de plantas de la PUCP: ¿Cuán fácil y exitosamente los usuarios encuentran la información que buscan? - ¿Cuál de las dos aplicaciones presenta componentes que permite que el usuario pueda lograr sus objetivos de manera más fácil? - ¿Cómo se sienten los usuarios al utilizar cada una de las aplicaciones? 4.1.3 Entorno de pruebas, equipos y logística Todas las pruebas se llevaron a cabo en los laboratorios de la sección de Ing. Informática de la PUCP. Se brindó a los participantes un dispositivo con plataforma iOS en el que se instalaron las dos aplicaciones y se observó su interacción cuando realizaron la lista de tareas. Además se utilizó una grabadora de video para tener un registro de la interacción y de los comentarios que tuvieron los participantes durante la evaluación para tenerlos como backup. 4.1.4 Características de los participantes Los usuarios de la aplicación del catálogo de plantas de la PUCP son los miembros de la comunidad PUCP que desarrollan sus labores principales en el campus San Miguel: alumnos de pregrado y posgrado, personal docente y no docente. Características Número deseado Piloto 1 Prueba 8 Backup 2 Número Total de Participantes 8 Grupos de usuarios Grupo de usuarios 1 2 Grupo de usuarios 2 2 Grupo de usuarios 3 2 Grupo de usuarios 4 2 Total 8 Alumnos de pregrado 4 Alumnos de posgrado 1 Docentes de la Universidad 2 68 Administrativos 1 Total 8 Hombres 3 a 5 Mujeres 3 a 5 Total 8 4.1.5 Descripción del método Para la evaluación, los participantes pertenecen a uno de los 4 grupos de usuarios definidos en la fase del planteamiento de personas y escenarios, los cuales son los siguientes: - Grupo de usuarios 1: Expertos que conocen sobre el tema de plantas. Saben exactamente lo que quieren buscar y se pueden referir a ellas según su taxonomía (Familia, género y especie) - Grupo de usuarios 2: Alumnos o personal de la Universidad que buscan información sobre una planta. Se pueden referir a ellas por su nombre común. - Grupo de usuarios 3: Alumnos o personal de la Universidad que quiere conocer sobre una planta a través de una fotografía. - Grupo de usuarios 4: Alumnos o personal de la Universidad que buscan plantas visualizando el mapa del campus de la PUCP. Dado que se evaluarán y compararán 2 aplicaciones, se utilizará la distribución para el orden de evaluación de las aplicaciones mostrada en la Tabla 11. Grupo de Usuarios Orden de Aplicaciones Grupo de Usuarios 1 Usuario 1 1,2 Usuario 2 2,1 Grupo de Usuarios 2 Usuario 1 1,2 Usuario 2 2,1 Grupo de Usuarios 3 Usuario 1 1,2 Usuario 2 2,1 69 Grupo de Usuarios 4 Usuario 1 1,2 Usuario 2 2,1 Tabla 11. Distribución para el orden de evaluación de las aplicaciones. [Elaboración propia] Donde 1 es la aplicación sobre el catálogo de plantas para la PUCP y 2 es una aplicación existente sobre un catálogo de plantas que se encuentra en el App Store, llamada Plant Finder, la cual puede ser descargada de manera gratuita en el siguiente enlace https://itunes.apple.com/us/app/plant-finder- lite/id709804498?mt=8. Esta distribución se hace para tener un equilibrio entre ambas aplicaciones, pues los participantes podrían acostumbrarse a usar la primera aplicación y luego encontrar dificultares para usar la segunda. Cada sesión contó con un moderador, rol que fue asumido por la autora del presente proyecto, quien se encargó de hacer la introducción, el cierre y guió la prueba. 4.1.6 Datos a ser recogidos y medidas de evaluación Para el rendimiento, se utilizaron las siguientes medidas de evaluación: - Número de tareas a realizar. - Número de tareas completadas correctamente sin asistencia. - Número de tareas completas correctamente después de pedir asistencia. - Número de tareas completadas de manera incorrecta. - Tiempo requerido para acceder a la información de cada tarea. En cuanto a la información cualitativa, se anotaron las opiniones y comentarios de los participantes sobre la interfaz mientras realizan las tareas. 4.2 Desarrollo de la evaluación de usuarios La evaluación fue llevada a cabo de manera individual y constó de 3 etapas: - Pre – prueba: Se busca información relativa a la experiencia y contexto habitual del uso de aplicaciones móviles y de interfaces sobre catálogos de plantas. 70 - Prueba: Se proporciona un conjunto de tareas que se deben realizar a través de las 2 aplicaciones móviles. - Post – prueba: Se busca obtener la percepción general sobre la experiencia del participante al interactuar con las aplicaciones móviles. En el Anexo I se puede observar el formato de evaluación que se entregó a los participantes durante las evaluaciones, así como los cuestionarios para cada una de las etapas y el formato de observación que se usó para registrar las observaciones del moderador. 4.3 Resultados de la evaluación de usuarios Siguiendo el diseño planteado, se procedió a llevar a cabo las evaluaciones y a registrar los respectivos resultados, los cuales se encuentran en el Anexo J del presente documento. En la Tabla 12 se muestra la comparación de las dos aplicaciones según las medidas de rendimiento planteadas en el diseño de la evaluación y en la Figura 12 se observa el resumen de los cuestionarios post – prueba en donde se muestra el promedio que tuvo cada una de las aplicaciones por cada pregunta a través de una escala de puntuación en donde 5 significa estar totalmente de acuerdo, muy satisfactorio o muy fácil y 1, totalmente en desacuerdo, insatisfactorio o muy difícil. Medidas de rendimiento Aplicación 1: Catálogo de Plantas PUCP Aplicación 2: Plant Finder Número de tareas a realizar. 5 2 Número de tareas completadas correctamente sin asistencia. 7 usuarios pudieron completar todas las tareas correctamente sin asistencia. 6 usuarios completaron todas las tareas correctamente sin asistencia. Número de tareas completadas correctamente Solo 1 usuario pidió asistencia para poder completar una tarea debido a que no estaba familiarizado con los estándares de interfaz Ninguno de los usuarios pidió asistencia para completar las tareas. 71 después de pedir asistencia. de iOS. Número de tareas completadas de manera incorrecta. Ningún usuario completó alguna tarea de manera incorrecta. 2 usuarios completaron una actividad de manera incorrecta, debido a que no percibieron que debían borrar los filtros de búsqueda antes de realizar nuevas búsquedas. Tiempo requerido para acceder a la información de cada tarea. A 2 usuarios les tomó más del tiempo máximo para completar una tarea, pero esto ocurrió debido a la conexión de Internet, lo que causó demora en las cargas de imágenes. Todos los usuarios utilizaron el tiempo apropiado para acceder a la información de cada tarea. Tabla 12. Comparación de los resultados de las pruebas de las 2 aplicaciones. [Elaboración propia] Figura 12. Comparación de los cuestionarios post - prueba de las 2 aplicaciones. [Elaboración propia] 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 ¿Pudo completar las tareas? ¿Considera que la información disponible en el portal es completa (suficiente)? ¿Considera que la aplicación es fácil de navegar? Usted califica su grado de satisfacción en la aplicación como: Volverá a utilizar la Aplicación Catálogo de plantas PUCP Plant Finder 72 Después de analizar estos resultados, se procede a responder las preguntas de investigación planteadas en el diseño de la evaluación: - Respecto al catálogo de plantas de la PUCP, todos los usuarios pudieron reconocer de manera fácil los componentes utilizados en la interfaz, como los botones, enlaces, e íconos que permiten lanzar acciones. Sin embargo, una sugerencia de parte de algunos usuarios fue colocar la opción para buscar plantas por nombre común en un lugar más rápido de reconocer a primera vista. - Respecto al catálogo de plantas de la PUCP, todos los usuarios pudieron reconocer de manera fácil y exitosa la información que buscaban. Después de analizar los comentarios de los participantes, se observa que este es un punto que les agradó mucho sobre la interfaz por la sencillez de las actividades para obtener información. - Debido a que la mayoría de los usuarios pudieron realizar la lista de tareas propuesta para ambas aplicaciones sin problemas, se pudo observar que las dos aplicaciones son sencillez de usar y permiten que el usuario pueda lograr sus objetivos de manera fácil; sin embargo, en la segunda aplicación, a algunos usuarios les tomaba un poco más de tiempo reconocer que los filtros de búsquedas anteriores debían ser borrados para realizar nuevas búsquedas. - Se puede observar que todos los usuarios se sienten satisfechos con ambas aplicaciones y estarían dispuestos a usarlas nuevamente; sin embargo, los resultados y los comentarios obtenidos muestran también que hay una leve preferencia por la aplicación del catálogo de plantas de la PUCP, lo cual ayuda a confirmar la idea de que la aplicación construida en el proyecto realmente contiene elementos más atractivos e intuitivos para los usuarios. 4.4 Conclusiones y análisis de uso de guías de ayuda interactiva SI bien es cierto, al comparar el producto software obtenido con una aplicación similar, se encontraron resultados que demuestran que realmente se construyó un producto usable, la evaluación de usuarios permitió también encontrar algunos elementos o funcionalidades que no son muy intuitivas para los usuarios y que se pueden mejorar en la interfaz. Esto demuestra que, como medio para asegurar la usabilidad del software, no basta con realizar evaluaciones en cada una de las iteraciones, sino que se debe complementar con una evaluación final, ya que los 73 usuarios con los que se evalúa inicialmente se van familiarizando con las funcionalidades de la aplicación y podrían no reconocer si algún elemento no es intuitivo para cualquier otro usuario. 4.4.1 Análisis del uso de guías de ayuda interactiva Al analizar los resultados obtenidos en la evaluación de usuarios, se ordenaron de la siguiente manera las funcionalidades de la aplicación de menos a mayor, según el nivel de dificultad para los usuarios: - Ingresar a la vista de contactos de la aplicación. - Búsqueda de la información de una planta siguiendo su taxonomía o nombre común. - Ingresar al mapa del campus de la PUCP y ubicar una planta por nombre común. - Tomar la imagen de la hoja de una planta y enviarla para ser procesada por un algoritmo de reconocimiento de imágenes. Teniendo ello en cuenta, se consideró la opción de incluir una guía de ayuda interactiva para la funcionalidad de capturar la imagen de la hoja de una planta, porque, si bien es cierto, se incluyó una sugerencia en la vista principal para tomar la imagen, se vio que la mayoría de los usuarios solo procede a capturar la foto y no lee las instrucciones, por lo que posiblemente si se incluyeran instrucciones más interactivas, los usuarios se informarían mejor y obtendrían resultados más precisos. 74 Capítulo 5 Discusión de Resultados En el presente capítulo se analizarán los resultados obtenidos al desarrollar la aplicación móvil y las ventajas de la integración de Extreme Programming con UCD en el presente proyecto. Cabe mencionar que, como parte del proyecto, se llevó a cabo una investigación – acción participativa en la que se construyó una interfaz sobre un catálogo de plantas de la PUCP para obtener información cualitativa sobre el proceso de integración de UCD con Extreme Programming. En este tipo de investigación, los participantes pueden desempeñar el rol de coinvestigadores ya que necesitan interactuar de manera constante con los datos [11]. Dado que, además de construir la interfaz, se evaluó el proceso de integración, este estudio se encuentra dentro de este tipo de investigación. Según Susman Evered [36], la investigación - acción participativa es un proceso cíclico con 5 fases. En el presente proyecto se desarrolló un ciclo en el que se identificaron las siguientes fases:  Diagnóstico o identificación del problema: Según la problemática planteada inicialmente en el proyecto, existen muy pocos experimentos controlados en los que se pueda mostrar las ventajas de integrar las metodologías ágiles con el Diseño Centrado en el Usuario [4 , 7 , 8]. La obtención de un software usable sigue siendo uno de los mayores problemas que deben afrontar, hoy en día, los equipos de desarrollo [9]. Por esta razón una metodología encaminada a lograr un producto usable sería de gran ayuda [9]. Dado el gran impacto de las metodologías ágiles se busca que éstas se complementen con las mejores técnicas de usabilidad.  Planificación de la acción: Se planteó una integración de una metodologia ágil, en este caso Extreme Programming, con métodos del Diseño Centrado en el Usuario para la construcción de una aplicación móvil. Dicha integración se encuentra detallada en capítulos anteriores.  Toma de acción: Se desarrolló la aplicación móvil sobre un Catálogo de Plantas de la PUCP siguiendo la integración propuesta. 75  Evaluación: Siguiendo el concepto de las metodologías ágiles y UCD, la interfaz se desarrolló en 4 iteraciones. Al finalizar cada una de ellas se realizó una evaluación de usuarios, asi como cuando se obtuvo el producto final. En la tabla 13 se presentan las principales observaciones de cada iteración, se debe tener en cuenta que al ser iteraciones incrementales, en cada una se evaluaron las mismas actividades de la iteración anterior junto con nuevas actividades que pertenecían a la funcionalidad implementada.  Especificación del aprendizaje: En la Tabla 14 se puede observar las ventajas de integrar XP con UCD en la aplicación móvil desarrollada. Dicho análisis se obtuvo después de cumplir con cada uno de los objetivos específicos planteados, los cuales contribuyeron a cumplir con el objetivo general del presente proyecto. PRIMERA ITERACIÓN SEGUNDA ITERACIÓN TERCERA ITERACIÓN CUARTA ITERACIÓN Funcionalidad implementada Búsqueda de la información de una planta por su taxonomía o por nombre común. Búsqueda de una planta por su nombre común en el mapa del Campus de la PUCP. Utilizar la cámara del dispositivo para capturar la imagen de la hoja de una planta y obtener una lista de plantas que podrían contener esa hoja. Acceder a la información de contacto de las personas que desarrollaron la aplicación. Número de actividades a realizar 2 4 8 11 Observaciones  Los usuarios empezaron a navegar y descubrir la aplicación. Permitió evaluar la distribución de los elementos de la interfaz y se obtuvieron varias observaciones para cambiar.  Los usuarios encontraron errores funcionales de la aplicación que no se  Se evaluaron 2 actividades nuevas sobre las cuales se obtuvieron algunas observaciones para cambiar. Respecto a las actividades de la iteración 1, el 100% de los usuarios estuvo de acuerdo con su funcionalidad.  Se evaluaron 4 actividades nuevas y se encontró que, al ser la nueva funcionalidad más compleja que las anteriores, el número de observaciones y comentarios aumentó.  Se pudo notar que se logró un lenguaje común entre el desarrollador y  Se evaluaron 3 actividades nuevas y no se obtuvieron muchas observaciones sobre estas.  Al ser la última iteración, se pidió a los usuarios, evaluar toda la aplicación completa y prestar mucha atención a cada detalle. Si bien es cierto, 77 PRIMERA ITERACIÓN SEGUNDA ITERACIÓN TERCERA ITERACIÓN CUARTA ITERACIÓN detectaron con las pruebas funcionales de XP.  La evaluación fue llevada a cabo de manera más rápida respecto a la iteración 1 pues los usuarios ya sabían en qué consistía. los usuarios, pues los usuarios comprendieron la forma de desarrollar la aplicación y el desarrollador empezó a entender las expectativas de los usuarios. se obtuvieron algunas observaciones para cambiar, se pudo observar que no se pidieron cambios mayores en la aplicación y los usuarios estaban satisfechos con el producto obtenido. Tabla 13. Resumen de las iteraciones desarrolladas. [Elaboración propia] VENTAJAS DE INTEGRAR XP CON UCD EN LA APLICACIÓN DESARROLLADA Levantamiento de requisitos Uso de métodos sencillos que fueron fáciles de adaptar al proyecto pequeño. El uso de entrevistas permitió conocer a los usuarios y que los requisitos sean entendidos tanto por los usuarios como por el desarrollador. Junto con los usuarios se desarrollaron los escenarios y personas, lo que permitió involucrarlos en el proyecto y generar mayor cohesión entre el equipo. Desarrollo del software Pruebas constantes que permitieron evaluar el desarrollo de los requisitos y asegurar la calidad del producto final. En cada iteración se pudo reconocer errores de desarrollo que no se identificaron en las pruebas funcionales de XP. Se logró un lenguaje común entre los usuarios y los desarrolladores, lo que permitió el entendimiento entre el equipo del proyecto. Evaluación del producto final Comparando la aplicación desarrollada en el proyecto con una aplicación para dispositivos móviles con funcionalidades similares, se obtuvo lo siguiente:  El 87.5% pudo completar correctamente todas las tareas sin asistencia, mientras que en el catálogo de plantas existente fue un 75%.  El 87.5% de los usuarios pudo reconocer los elementos de la interfaz para realizar las actividades, mientras que en el catálogo de plantas fue un 75%.  En la escala del 1 al 5, en promedio los usuarios pusieron un 4.1 si volverían a utilizar la aplicación, mientras en que en el catálogo existente fue 3.6, donde 3 es Neutral y 4 es De acuerdo. Con los resultados obtenidos, se considera que, después de aplicar la integración propuesta en el proyecto, se obtuvo una aplicación orientada a los usuarios y que se logró cubrir todos los requisitos especificados inicialmente. Tabla 14. Ventajas de integrar XP con UCD en el presente proyecto. [Elaboración propia] Capítulo 6 Observaciones, Conclusiones y Trabajos Futuros En el presente capítulo se presentan las observaciones, conclusiones y recomendaciones encontradas después del desarrollo e implementación del presente proyecto. 6.1 Observaciones Se pudo observar que sí hubo colaboración por parte de los usuarios para la definición de los requisitos de la aplicación; sin embargo, al no tener una idea clara de las funcionalidades que querían que fueran implementadas, fue necesario utilizar una técnica para motivarlos e incentivar a que concreten sus ideas. Por ello, durante las entrevistas en la etapa del levantamiento de requisitos, se tuvo que incluir la observación de la interacción sobre aplicaciones existentes de catálogos de plantas en dispositivos móviles. Con el fin de realizar evaluaciones con usuarios y obtener resultados más cercanos a la realidad, se vio la necesidad de implementar una base de datos genérica, que pueda ser fácilmente adaptable a otros proyectos similares, y la utilización de servicios web para simular la interacción real que tendrían los usuarios con la aplicación, incluyendo los tiempos de carga de las imágenes. Inicialmente, se planteó la idea de utilizar la evaluación de usuarios propuesta por Jeff Rubin y Dana Chisnell en cada una de las iteraciones y al final del producto; sin embargo, al iniciar el desarrollo de la aplicación, se vio por conveniente utilizar un método de evaluación de usabilidad más rápido y menos costoso para evaluar cada iteración y, posteriormente, llevar a cabo la evaluación de usuarios recién al tener la aplicación completa. Por esta razón, se decidió utilizar la técnica del Pensamiento en voz alta, que permitió obtener resultados rápidos y confiables en cada iteración. 6.2 Conclusiones Como parte del análisis de la investigación - acción que se llevó a cabo en el presente proyecto, se llega a las siguientes conclusiones: - Las técnicas utilizadas durante la etapa de análisis del proyecto fueron integradas de manera satisfactoria con XP. El uso de entrevistas permitió conocer a los usuarios y entender sus expectativas para desarrollar un 80 software hecho a su medida. El planteamiento de personas y escenarios permitió reforzar la idea de desarrollar un software centrado en el cliente y planificar adecuadamente las iteraciones antes de comenzar con la construcción del producto. Cabe mencionar que en todo este proceso es muy importante la retroalimentación con los usuarios, si bien es cierto, al inicio se obtuvo una lista de requisitos, fue importante revisarla con los usuarios y asegurarse de que todos estén de acuerdo para no hacer cambios que podrían ser más costosos en el futuro. - La fase de la construcción del prototipo es una etapa a la que normalmente no se le dedica mucho tiempo; sin embargo, se pudo observar que, además de ser una herramienta muy útil para plasmar las ideas de los usuarios y poco costosa para realizar cambios, permitió también que el desarrollador del software pueda concretar las funcionalidades a ser implementadas, considerando las limitaciones de los recursos del proyecto (como el hardware o el tiempo) y analizando lo que es o no factible para desarrollar un producto que satisfaga las necesidades de los usuarios. - Un aspecto muy importante que se analizó en el presente proyecto es la relación de las iteraciones con las evaluaciones de usabilidad, las cuales son una parte primordial del Diseño Centrado en el Usuario. Realizar evaluaciones con usuarios al finalizar cada iteración, permitió probar la usabilidad del software funcional en etapas tempranas, en las que todavía es posible hacer cambios. Es importante mencionar que para que esta integración resulte exitosa, los usuarios deben estar muy involucrados con el proyecto, ya que uno de los inconvenientes que se presentó al realizar estas evaluaciones es que las fechas de cumplimiento dependían de la disponibilidad de los usuarios. A pesar de ello, se observó que las pruebas de usabilidad se integraron muy bien con las pruebas de aceptación de las metodologías ágiles. - Finalmente, es importante realizar una evaluación final de usabilidad para complementar las evaluaciones realizadas en cada iteración y así, asegurar que el producto software construido está orientado a los clientes. En este caso, se pudo comprobar que, siguiendo todo el proceso de integración propuesto, se obtuvo una aplicación usable y, además, se obtuvieron 81 sugerencias muy valiosas por parte de los usuarios que podrían asegurar la obtención de un producto realmente útil. 6.3 Trabajos futuros El presente proyecto de fin de carrera sirvió para evaluar el proceso de integración de una metodología ágil con UCD en un caso de investigación – acción en el que se construyó una aplicación para dispositivos móviles con plataforma iOS. Sin embargo, a continuación se mencionan algunos proyectos que podrían mejorar y contribuir con el estudio: - Desarrollar un caso de estudio en el que el grupo de desarrolladores no sea el mismo que el equipo de evaluadores y, de esta manera, observar el proceso de integración de ambas metodologías. - Aplicar una investigación – acción similar a la desarrollada en el presente proyecto para la construcción de una interfaz en otra tecnología, como un sistema web o una aplicación móvil en una plataforma diferente a iOS lo que permitirá comparar las observaciones obtenidas sobre la integración de ambas metodologías para diferentes tecnologías. - Tomando como base la integración propuesta en el presente trabajo, se podría aplicar a un proyecto más grande de desarrollo y evaluar si se obtienen los mismos resultados. 82 REFERENCIAS BIBLIOGRÁFICAS 1. Sharp, H., Rogers, Y., Preece, J.: Interaction design: beyond human- computer interaction. 2002 (2007) 2. IEC, I.: ISO/IEC 25000 software engineering software product quality requirements and evaluation (SQuaRE) guide to SQuaRE. Systems Engineering 41 (2005) 3. ISO, W.: 9241-11. Ergonomic requirements for office work with visual display terminals (VDTs). The international organization for standardization (1998) 4. Salvador Ortiz, C.S.: Una revisión sistemática de usabilidad en metodologías ágiles. (2013) 5. Agile Alliance, http://www.agilealliance.org 6. Ferreira, J., Noble, J., Biddle, R.: Agile development iterations and UI design. In: Agile Conference (AGILE), 2007, pp. 50-58. IEEE, (Year) 7. Da Silva, T.S., Martin, A., Maurer, F., Silveira, M.S.: User-Centered Design and Agile Methods: A Systematic Review. In: AGILE, pp. 77-86. (Year) 8. Jurca, G., Hellmann, T.D., Maurer, F.: Integrating agile and user-centered design: a systematic mapping and review of evaluation and validation studies of agile-ux. In: Agile Conference (AGILE), 2014, pp. 24-32. IEEE, (Year) 9. Nielsen, J.: Usability engineering. Elsevier (1994) 10. Stringer, E.T.: Action research. Sage (2007) 11. Hernández Sampieri, R., Fernández Collado, C., Baptista Lucio, P.: Metodología de la investigación. México: Editorial Mc Graw Hill (2010) 12. Lindstrom, L., Jeffries, R.: Extreme programming and agile software development methodologies. Information Systems Management 21, 41-52 (2004) 13. Beck, K.: Embracing change with extreme programming. Computer 32, 70-77 (1999) 14. Rubin, J., Chisnell, D.: Handbook of usability testing: howto plan, design, and conduct effective tests. John Wiley & Sons (2008) 15. Zapata, C.: Integration of Usability and Agile Methodologies: A Systematic Review. SpringerLink (2015) 16. Pratt, A., Nunes, J.: Interactive design: An introduction to the theory and application of user-centered design. Rockport Pub (2012) 17. ISO, W.: 9241-210: 2010. Ergonomics of human system interaction-Part 210: Human-centred design for interactive systems. The international organization for standardization (2010) 18. The Agile Methodology, http://agilemethodology.org 83 19. Fowler, M., Highsmith, J.: The agile manifesto. Software Development 9, 28- 35 (2001) 20. Schwaber, K., Sutherland, J.: The scrum guide. Scrum. org, October (2011) 21. Scrum Alliance, https://www.scrumalliance.org. 22. Chowdhury, A.F., Huda, M.N.: Comparison between adaptive software development and feature driven development. In: Computer Science and Network Technology (ICCSNT), 2011 International Conference on, pp. 363-367. IEEE, (Year) 23. Voigt, B.J., Glinz, M., Seybold, D.-I.C.: Dynamic system development method. Department of Information Technology, University of Zurich, Zurich20 January (2004) 24. Hussain, Z., Slany, W., Holzinger, A.: Investigating agile user-centered design in practice: A grounded theory perspective. Springer (2009) 25. Chamberlain, S., Sharp, H., Maiden, N.: Towards a framework for integrating agile development and user-centred design. Extreme programming and agile processes in software engineering, pp. 143-153. Springer (2006) 26. Dayton, D., Barnum, C.: The impact of agile on user-centered design. Technical Communication 56, 219-234 (2009) 27. Adikari, S., McDonald, C., Campbell, J.: Little design up-front: a design science approach to integrating usability into agile requirements engineering. Human-computer interaction. New trends, pp. 549-558. Springer (2009) 28. Holzinger, A., Errath, M., Searle, G., Thurnher, B., Slany, W.: From extreme programming and usability engineering to extreme usability in software engineering education (XP+ UE→ XU). In: Computer Software and Applications Conference, 2005. COMPSAC 2005. 29th Annual International, pp. 169-172. IEEE, (Year) 29. Wolkerstorfer, P., Tscheligi, M., Sefelin, R., Milchrahm, H., Hussain, Z., Lechner, M., Shahzad, S.: Probing an agile usability process. In: CHI'08 Extended Abstracts on Human Factors in Computing Systems, pp. 2151-2158. ACM, (Year) 30. Sohaib, O., Khan, K.: Incorporating discount usability in extreme programming. International Journal of Software Engineering and Its Applications 5, 51-62 (2011) 31. Nuestra mira es establecer un Sistema de Gestión Ambiental en la PUCP, http://vicerrectorado.pucp.edu.pe/administrativo/opinion/contamos-con-un-registro- de-plantas-en-el-campus/ 32. INTE-PUCP, http://inte.pucp.edu.pe 84 33. Obendorf, H., Finck, M.: Scenario-based usability engineering techniques in agile development processes. In: CHI'08 Extended Abstracts on Human Factors in Computing Systems, pp. 2159-2166. ACM, (Year) 34. Davis, F.D.: Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS quarterly 319-340 (1989) 35. Janna Weber, http://www.jannaweber.com/wp- content/uploads/2009/09/WT06_Think_Aloud.pdf 36. Susman, G.I., Evered, R.D.: An assessment of the scientific merits of action research. Administrative science quarterly 582-603 (1978)