desarrollo del front-end de un portal de autogestiÓn...

DESARROLLO DEL FRONT-END DE UN PORTAL DE AUTOGESTIÓN EN EL PRODUCTO OPENSMARTFLEX PARA EMPRESAS DEL SECTOR UTILITIES

ANDRÉS FELIPE ECHAVARRÍA HERNÁNDEZ JOHNATHAN SEBASTIAN ANGARITA ROMERO

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE

FACULTAD DE INGENIERÍA DEPARTAMENTO DE OPERACIONES Y SISTEMAS

PROGRAMA INGENIERÍA MULTIMEDIA SANTIAGO DE CALI

2017

DESARROLLO DEL FRONT-END DE UN PORTAL DE AUTOGESTIÓN EN EL PRODUCTO OPENSMARTFLEX PARA EMPRESAS DEL SECTOR

UTILITIES

ANDRÉS FELIPE ECHAVARRÍA HERNÁNDEZ JOHNATHAN SEBASTIAN ANGARITA ROMERO

Pasantía institucional para optar al título de Ingeniero Multimedia

ANDRÉS FERNANDO SOLANO ALEGRÍA Doctor en Ciencias de la Electrónica de la Universidad del Cauca

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA INGENIERÍA MULTIMEDIA

SANTIAGO DE CALI 2017

3

Nota de aceptación:

Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero Multimedia ANDRES FELIPE GALLEGO

Jurado

Santiago de Cali, 31 de marzo de 2017

4

Dedicamos este trabajo a nuestros padres y familiares quienes han sido un apoyo incondicional para nosotros, brindándonos la posibilidad de alcanzar esta meta y concretar exitosamente este capítulo de nuestra formación profesional; sus enseñanzas, ejemplos de vida y consejos nos han formado de la mejor manera posible, y los tenemos en nuestro más alto grado de gratitud, respeto y admiración. Gracias por todo.

5

AGRADECIMIENTOS

Agradecemos a todas las personas que de una u otra manera nos apoyaron en el proceso de desarrollo de este trabajo, a todos aquellos que nos dieron sus opiniones, que nos aconsejaron, que nos escucharon y que nos corrigieron, ya que sin ellos nada de esto pudo haberse hecho realidad. A nuestros padres, hermanos, familiares y seres queridos, que nos formaron, motivaron, apoyaron e impulsaron en cada proceso y propósito de nuestras vidas, que nunca dejaron de creer en nuestras capacidades, y que están a nuestro lado en los buenos y malos momentos. Gracias a nuestros profesores, que dispusieron de su tiempo para guiarnos en este proceso académico y darnos sus mejores consejos; todos ustedes hicieron posible alcanzar este logro sin que la meta se desvaneciera… muchas gracias.

6

CONTENIDO

pág.

GLOSARIO 14

RESUMEN 15

INTRODUCCIÓN 16

1. PLANTEAMIENTO DEL PROBLEMA 18

2. ANTECEDENTES 20

3. OBJETIVOS 22

3.1 OBJETIVO GENERAL 22

3.2 OBJETIVOS ESPECÍFICOS 22

4. MARCO DE REFERENCIA 23

4.1 PORTAL DE AUTOGESTIÓN 23

4.2 DISEÑO CENTRADO EN EL USUARIO 24

4.3 EXPERIENCIA DE USUARIO (UX) 26

7

4.3.1 Usabilidad. 27

5. METODOLOGÍA 29

5.1 ETAPA DE PRE-INICIACIÓN 29

5.2 ETAPA DE DEFINICIÓN 29

5.3 ETAPA DE EVALUACIÓN O ANÁLISIS 30

5.4 ETAPA DE DISEÑO 30

5.5 ETAPA DE IMPLEMENTACIÓN 30

6. DESARROLLO PORTAL DE AUTOGESTIÓN 31

6.1 PRE-INICIALIZACIÓN DEL PROYECTO 31

6.2 ANÁLISIS DE REQUISITOS 31

6.2.1 Descripción inicial. 31

6.2.2 Definición de usuarios. 32

6.2.2.1 Perfil de usuario. 33

6.2.2.2 Descripción de la experiencia de usuario. 33

6.2.2.3 Storyboard. 35

6.2.3 Definición de requisitos. 36

6.2.3.1 Requisitos Funcionales 37

6.2.3.2 Requisitos No Funcionales 38

6.3 DISEÑO DEL PORTAL DE AUTOGESTIÓN 38

6.3.1 Casos de uso. 40

6.3.1.1 Definición del actor. 40

8

6.3.1.2 Identificación de los casos de uso. 40

6.3.1.3 Casos de uso detallados. 42

6.3.2 Arquitectura de información. 45

6.3.2.1 Información en mini-aplicaciones. 45

6.3.2.2 Mapa navegacional. 47

6.3.3 Diseño de interfaces. 48

6.3.3.1 Sketches. 48

6.3.3.2 Mockups. 51

6.4 IMPLEMENTACION DEL FRONT-END 52

6.4.1 Framework de desarrollo. 52

6.4.2 Base de datos. 53

6.4.3 Front-End. 55

6.4.3.1 Componentes de interfaz. 55

6.4.3.2 Arquitectura. 57

7. EVALUACIÓN DE USABILIDAD 60

7.1 EVALUACIÓN CON USUARIOS POTENCIALES 60

7.1.1 Evaluación de Sketches. 60

7.1.1.1 Planeación. 60

7.1.1.2 Ejecución. 61

7.1.1.3 Resultados obtenidos. 62

7.1.1.4 Conclusiones de la evaluación. 65

7.1.2 Evaluación de prototipo funcional. 66

7.1.2.1 Planeación. 66

9

7.1.2.2 Ejecución. 67

7.1.2.3 Resultados obtenidos. 68

7.1.2.4 Conclusiones de la evaluación. 68

7.2 EVALUACIÓN DE EXPERTOS 69

7.2.1 Planeación. 69

7.2.2 Ejecución. 70

7.2.3 Análisis de resultados. 71

7.2.3.1 Problemas por principio heurístico. 71

7.2.3.1.1 Ranking de criticidad. 71

7.2.3.1.2 Ranking de severidad. 73

7.2.3.1.3 Ranking de frecuencia. 73

7.2.3.2 Análisis e interpretación de los resultados. 75

7.2.3.3 Identificar elementos positivos del sistema. 76

8. CONCLUSIONES 78

9. RECOMENDACIONES 81

10. TRABAJOS FUTUROS 82

BIBLIOGRAFÍA 83

10

ANEXOS 88

11

LISTA DE CUADROS

pág.

Cuadro 1. Análisis de usuarios 32

Cuadro 2. Aplicaciones del portal vs requisitos 39

Cuadro 3. Caso de uso extendido CU _15 43

Cuadro 4. Caso de uso extendido CU _16 44

Cuadro 5. Información desplegada y solicitada por aplicación 46

Cuadro 6. Métodos de BD por aplicación 54

Cuadro 7. Descripción evaluación Sketches 61

Cuadro 8. Descripción evaluación prototipo funcional 67

Cuadro 9. Perfiles evaluadores 70

Cuadro 10. Cantidad de problemas por principio heurístico 71

Cuadro 11. Problemas con mayor ranking de criticidad 72

Cuadro 12. Problemas con mayor ranking de severidad 73

Cuadro 13. Problemas con mayor ranking de frecuencia 74

12

LISTA DE FIGURAS

pág.

Figura 1. Storyboard de registro de quejas y/o reclamos 36

Figura 2. Diagrama de casos de uso 42

Figura 3. Mapa navegacional – Menú y Simulador de consumos 48

Figura 4. Sketches Menú - Portal de Autogestión 49

Figura 5. Sketches Simulador de Consumos - Portal de Autogestión 50

Figura 6. Mockups Menú (login) - Portal de Autogestión 51

Figura 7. Mockups Menú (home) - Portal de Autogestión 52

Figura 8. Mockups Simulador de Consumos - Portal de Autogestión 52

Figura 9. Identificación elementos base en interfaces 55

Figura 10. Identificación elementos similares entre interfaces 56

Figura 11. Jerarquía de Carpetas del Portal de Autogestión 58

Figura 12. Resultados Pregunta 1 del cuestionario 63





13

LISTA DE ANEXOS

pág.

Anexo A. Storyboards 88

Anexo B. Sketches 88

Anexo C. Mockups 88

Anexo D. Casos de uso 88

Anexo E. Mapa navegacional 88

Anexo F. Encuestas de Sketches 89

Anexo G. Evaluación heurística 89

14

GLOSARIO

EMPRESAS DE UTILITIES: son aquellas prestadoras de servicios públicos tales como electrificadoras, gaseras y acueductos. Algunos ejemplos en Colombia pueden ser Emcali y Gases de Occidente. FRONT-END: se denomina Front-End al desarrollo de la parte del software que interactúa directamente con el usuario final, lo cual incluye interfaces gráficas y métodos de entrada de datos. LOOK AND FEEL: aspecto que es representado en una interfaz donde se miran características como forma, color, tamaño, distribución de elementos, etc. MOCKUP: representación estática o dinámica en media o alta calidad de un diseño. PQR: acrónimo que hace referencia a las peticiones (solicitudes), quejas y reclamos que se realizan a una compañía. SKETCH: representación estática en baja calidad de un diseño (boceto). STORYBOARD: guion gráfico que se muestra de forma secuencial con el fin de servir de guía para entender el contexto y las actividades que se desarrollan en una historia de usuario.

15

RESUMEN

Los portales de autogestión actualmente se presentan como una solución a la forma en que se realiza la atención al cliente, desde un acercamiento por medio de software a los principales usuarios de las empresas prestadoras de servicios (en este caso sector utilities); es una tendencia que toma fuerza y se globaliza principalmente en el campo de los sistemas de gestión y atención al cliente. El éxito de este tipo de soluciones radica en la facilidad de los usuarios finales de realizar consultas y gestionar sus productos o servicios de forma sencilla.

Este documento describe el proceso que se llevó a cabo para el diseño y la implementación de un Portal de Autogestión para las empresas del sector utilities, cuyas principales plataformas de despliegue son los dispositivos móviles, aunque se brinda soporte para dispositivos de escritorio, debido a que se desarrolló como una aplicación web. El Portal de Autogestión proporciona un conjunto de funcionalidades que permiten realizar gestión de los diferentes servicios y productos que se tienen contratados con la empresa prestadora de servicio, que desde un principio fue concebido como una herramienta de aprovechamiento para los usuarios finales.

En éste documento se presenta información relativa al tema de estudio, antecedentes y desarrollos relevantes que fueron tomados como referencia durante el proceso de identificación de funcionalidades del Portal de Autogestión, y las diferentes etapas del proceso: evaluación de las necesidades de la empresa sin olvidar al usuario final (principal), caracterización de usuarios, evaluación de requisitos, evaluación de funcionalidades, diseño de interfaces, entre otras, que fueron llevadas a cabo mediante la aplicación de prácticas y metodologías de ingeniería, garantizando un flujo de trabajo efectivo y eficiente que permitiera dar respuesta a las necesidades surgidas en la marcha.

Palabras clave: Portal de autogestión, sector utilities, aplicación web.

16

INTRODUCCIÓN

Open International Systems1 provee soluciones de software especializado para los sectores de las Telecomunicaciones y los Servicios Públicos Domiciliarios (Telco & Utilities). Esta una empresa líder en tecnología y con operación internacional. El producto que ofrece la empresa Open, OpenSmartflex™2, es un sistema de información BOSS (Business and Operations Support Systems) dirigido a compañías de telecomunicaciones y servicios públicos, el cual por medio de alta tecnología basada en reglas, integra funcionalidades y componentes del núcleo principal de gestión en dichas compañías, tales como: atención al cliente, facturación y operaciones de campo relacionadas con la infraestructura para la prestación de los servicios.

Aunque Open International Systems brinda una herramienta completamente funcional que involucra las diversas fases del ciclo productivo de una empresa del sector utilities, no cuenta con una herramienta que permita el acercamiento entre el usuario final y la empresa prestadora de servicio. Para suplir esta necesidad, Open requiere implementar un Portal de Autogestión que pueda ser entregado como producto para el uso comercial de las diferentes empresas del sector utilities. Dichas empresas podrán ofrecer esta herramienta como parte de su servicio, cuya principal característica será la aplicación de buenas prácticas de usabilidad, soportando los patrones de diseño actualmente definidos por Open.

Gracias a que los sistemas interactivos están dirigidos a un público cada vez más amplio, a usuarios cada vez menos expertos en el manejo de los mismos, la Experiencia de Usuario (UX, por sus siglas en inglés User eXperience) es un aspecto fundamental para el éxito de sistemas, como el requerido por la empresa Open. La UX se refiere a “cómo se sienten las personas acerca de un producto y su satisfacción cuando lo usan, lo miran, lo sostienen, lo abren o cierran” 3. Según Masip4, la UX abarca diferentes facetas relacionadas a la calidad de un producto software como: usabilidad, accesibilidad, emotividad, multiculturalidad, jugabilidad, entre otras. Sin embargo, el presente trabajo se enfoca exclusivamente en la faceta usabilidad de la UX.

1 OPEN INTERNATIONAL SYSTEMS [en línea]: Acerca de nosotros. Cali: Open International

Systems, 1987 [consultado el 16 de Julio de 2015]. Disponible en Internet: http://www.openinternational.com/es/index.html 2 OPEN INTERNATIONAL SYSTEMS [en línea]: Open Smartflex. Cali: Open International Systems,

1987 [consultado el 20 de Julio de 2015]. Disponible en Internet: http://openinternational.com/es/product.html 3 SHARP, H. ROGERS, Y. y PREECE J., Interaction Design Beyond Human - Computer

Interaction. 2 ed. Wiley, John & Sons, Incorporated, 2007. p.103. 4 MASIP, L., OLIVA, M. y GRANOLLERS, T., "User experience specification through quality

attributes". En: Human-Computer Interaction–INTERACT 2011. New York: 2011, p. 656-660.

17

La usabilidad es un atributo de calidad del software que conlleva una serie de métricas y métodos con el objetivo de obtener sistemas fáciles de usar y de aprender, además influye directamente en el éxito de cualquier nueva aplicación o sistema interactivo5. La usabilidad es la característica de calidad más visible, puesto que determina la satisfacción del usuario con el sistema, lo que a su vez determina que éste quiera volver a utilizarlo en el futuro6.

Es importante destacar que los usuarios y sus necesidades toman la mayor importancia en este trabajo y alrededor de ellos gira el desarrollo del Portal de Autogestión, ya que finalmente son ellos quienes utilizan el portal para alcanzar un objetivo determinado. Lo buscado es que ellos alcancen dichos objetivos de manera fácil y eficiente, lo que contribuye directamente a su satisfacción.

5 ISO, "International Standard ISO/IEC 9241," in Ergonomic requirements for office work with visual

display terminals, ed, 1998. 6 GRANOLLERS, T., "MPIu+a una metodología que integra la ingeniería del software, la interacción

persona-ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares". Tesis Doctoral. Lleida: Universidad de Lleida. Departamento de Sistemas Informáticos, 2004. p. 204.

18

1. PLANTEAMIENTO DEL PROBLEMA

Actualmente, las empresas de utilities, por lo general, cuentan con dos canales de atención: vía telefónica y presencial. En muchas ocasiones la atención telefónica puede llegar a ser desesperante para los usuarios debido a las demoras en el tiempo de respuesta, pues es requerida una gran cantidad de datos y, en ocasiones, sólo llega a ser resuelta una solicitud.

Por otro lado, la atención presencial es aún más compleja. Las empresas de utilities presentan una gran congestión en sus establecimientos, asegura ADN7, que puede ser ocasionada por la gran cantidad de solicitudes que tienen los usuarios, la escasez de centros de atención, la poca cantidad de operarios que atienden en las instalaciones o incluso la ubicación de dichos centros. Además, las empresas proporcionan un horario que puede no ser accesible para todos los usuarios y muchos de los procedimientos que realizan los usuarios requieren el diligenciamiento de muchos formatos y pueden contar con fechas de respuesta demasiado largas a sus solicitudes. Todo esto ocasiona inconformidad con el servicio que prestan dichas empresas.

Ahora bien, las empresas de utilities para poder prestar el servicio de atención al cliente deben incurrir en gastos de activos y pasivos como son la contratación de funcionarios y el mantenimiento de sus instalaciones. Los gastos que deben cubrir estas empresas pueden a veces parecer excesivos en comparación con la atención que los usuarios finales perciben, causando la desvinculación de los usuarios o, incluso, el inicio de procesos legales en contra de las empresas de utilities. Esto ocasionaría una reducción en las ganancias de dichas empresas y finalmente podría afectar económicamente a Open Systems, empresa que provee una solución suficientemente robusta para soportar todos los procesos del ciclo productivo de estas empresas llamada OpenSmartflex, la cual no cuenta con una herramienta que permita el acercamiento entre las empresas y sus usuarios, además de tener una oferta limitada entre sus clientes.

Con base en lo anterior, la problemática se presenta al momento en que el usuario desea realizar algún tipo de trámite o consulta de productos o servicios que ofrecen las empresas de utilities sin tener que acudir a los canales de atención antes mencionados. Esto considerando las restricciones de disponibilidad que presentan los usuarios para desplazarse a la empresa prestadora del servicio. Así,

7 ADN. Con sanciones, intentan acabar con filas en la vía pública [en línea]. Junio 29, 2015

[consultado el 20 de Julio de 2015]. Disponible en Internet: http://diarioadn.co/bogota/mi-ciudad/proyecto-para-acabar-las-filas-afuera-de-las-entidades-1.22362

19

surge la pregunta: ¿Qué mecanismo puede tenerse, aprovechando los dispositivos electrónicos a los que se tiene acceso, para que los usuarios puedan realizar fácilmente trámites y consultas de los productos o servicios ofrecidos por las empresas de utilities? Teniendo en cuenta este interrogante, el propósito del presente trabajo es diseñar e implementar el Front-End de un Portal de Autogestión haciendo uso de buenas prácticas en usabilidad, considerando los patrones de diseño definidos por la empresa Open International Systems para el desarrollo de aplicaciones web.

20

2. ANTECEDENTES

A través de los años las empresas prestadoras de servicios se han empeñado en generar mecanismos que los acerquen más a sus clientes, esto con el fin de conocer sus necesidades y finalmente brindar un mejor servicio, además, en muchas ocasiones permiten disminuir tiempos y gastos en procesos de atención al cliente. Las aplicaciones presentadas en esta sección tienen como objetivo generar un acercamiento entre el cliente y la empresa ofreciendo diferentes funcionalidades, brindando una experiencia de usuario adaptable a las demandas actuales de sus clientes por medio de funcionalidades básicas que anteriormente llevaban mucho tiempo o que únicamente se podían realizar de forma presencial. A continuación se presentan una serie de trabajos relacionados con los temas base de la propuesta.

Bancolombia App8: es una aplicación que puede descargarse gratis desde cualquier Smartphone para realizar consultas y transacciones, así como identificar puntos de atención, solicitar productos y documentos, simular créditos y obtener información sobre el mercado financiero en Colombia. Bancolombia App logra reunir varias aplicaciones útiles para que sus clientes puedan consultar su estado de cuenta, utilizando la misma seguridad de su página web. Han conseguido brindar la mayor cantidad de información en pantallas reducidas como la de los Smartphone y además, tiene como valor agregado la simulación de alguno de sus productos. Estos elementos pueden ser de utilidad al diseñar el Portal de Autogestión usando pocas pantallas para presentar información de una forma eficiente, como también, hacer uso de un simulador para que los usuarios finales puedan contar con un consumo y valor aproximado de sus servicios y así poder reducirlos.

Banco de Bogotá App9: ofrece una aplicación con la cual el cliente podrá hacer el pago mínimo, total o parcial de sus obligaciones, consultar certificados y reportes anuales de costos totales. Para poder acceder a la aplicación del banco de Bogotá se necesita haber creado una cuenta previamente que le permitirá al cliente consultar sus movimientos bancarios, de manera rápida y segura. En ese sentido, el Portal de Autogestión puede, inclusive, permitir la consulta de movimientos tal como lo permite hacer esta aplicación, para presentar mayor detalle en la información de transacciones realizadas con la empresa de utilities.

8 GRUPO BANCOLOMBIA. Bancolombia App [aplicación] Play Store, Mayo, 2015.

9 BANCO DE BOGOTÁ. Banco de Bogotá [aplicación] Play Store, Mayo, 2015.

21

Adicionalmente, como lo muestra la aplicación de Banco de Bogotá, es necesario que los usuarios tengan una cuenta creada o el sistema permita que se cree una para poder acceder a las funcionalidades del Portal de Autogestión.

Chilquinta App10: es la aplicación web ofrecida por una de las más grandes electrificadoras de Chile para poder estar más cerca a sus clientes. Debido a que esta aplicación está relacionada al proceso de investigación del presente proyecto, fue considerada para poder definir cuáles son las funcionalidades que ofrecen a sus clientes. En esta se puede observar que una conexión con las redes sociales es indispensable para la masificación de la aplicación y poder generar ventas. Además, una funcionalidad que es vital para el desarrollo del Portal de Autogestión y que también ofrece esta aplicación se refiere a la generación de Reporte de Daños. Sin embargo, el alcance se puede ampliar al registro de solicitudes, quejas y reclamos que el usuario tenga sobre algún servicio.

Movistar App11: ofrece una aplicación para sus clientes mediante la cual se puede actualizar los datos de la cuenta, consulta saldos de recarga, recargar saldo, pagar facturas y comunicarse con un funcionario mediante un chat de servicio al cliente. Movistar app utiliza los colores corporativos brindándole una identidad definida a su aplicación. Una de las principales transacciones que se realizan en los centro de atención de las empresas de utilites es el pago de facturas. Para facilitar este trámite, se podría implementar esta funcionalidad en el Portal de Autogestión como lo presenta dicha aplicación.

El Portal de Autogestión también podría beneficiarse de la funcionalidad de administración de la cuenta que ofrece la aplicación Movistar App. La capacidad de gestionar los datos de usuario y poder ver los productos que se tienen asociados, podría llegar a ser un atractivo para los usuarios que constantemente cambian de dirección o correo electrónico, o deseen cambiar la forma en que la factura se les es entregada (vía email o correo físico).

10

CHILQUINTA. Chilquinta Móvil [en línea]. Chile, 2015 [consultado 28 de Abril de 2015] Disponible en Internet: http://m.chilquinta.cl/

11 COLOMBIA TELECOMUNICACIONES S.A. Movistar CO [aplicación] Play Store, Mayo, 2015.

22

3. OBJETIVOS

3.1 OBJETIVO GENERAL

Diseñar e implementar el Front-End de un Portal de Autogestión haciendo uso de buenas prácticas en usabilidad, considerando los patrones de diseño definidos por la empresa Open International Systems para el desarrollo de aplicaciones web.

3.2 OBJETIVOS ESPECÍFICOS

Analizar los requisitos proporcionados por la empresa Open Systems.

Diseñar el front-end del Portal de Autogestión haciendo uso de webcomponents.

Implementar los componentes requeridos asociados al Portal de Autogestión.

Evaluar el Portal de Autogestión mediante métodos de evaluación de usabilidad con expertos y usuarios representativos del sistema.

23

4. MARCO DE REFERENCIA

4.1 PORTAL DE AUTOGESTIÓN

Un portal es “un sitio o aplicación en Internet que provee al usuario un punto de acceso a una variedad de recursos y servicios”12. Estos portales generalmente están enfocados en las diferentes industrias a los que pertenecen, por ejemplo, el portal de una entidad financiera ofrecerá información de las cuentas de los usuarios, así como servicios de transferencias y pagos. Sin embargo, el portal de una empresa de servicios públicos o utilities (las cuales son primordiales en este proyecto) deberá contar con información de cuentas, productos, consumos, facturas, etc.

Ahora bien, el concepto “autogestión”, según Arnoletto13, viene del ámbito económico el cual la define como un sistema de una organización en el que las actividades y toma de decisiones son desarrolladas por todas las partes involucradas como: empleados de diferentes áreas, sistemas inteligentes e incluso por clientes de estas organizaciones.

Así, el Portal de Autogestión surge gracias a la unión de los dos conceptos antes mencionados como una herramienta que provee una variedad de servicios, con los cuales los usuarios pueden gestionar directamente sus productos o servicios brindados por una empresa perteneciente a una industria especifica.

Open Systems14 lo define de la siguiente forma:

Un Portal de Autogestión es un canal de acceso central e integrador de información, servicios y aplicaciones que se encuentran a disposición de un público muy diverso; a diferencia de una página web tradicional que sólo

12

WACHHOLZ-PRILL, Andre y KUPKE, Markus. Displaying information from a portal website [en linea]. Minneapolis: Octubre, 2005 [consultado el 26 de Diciembre de 2016]. Disponible en Internet: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20050223310.pdf

13 ARNOLETTO, E.J. Glosario de Conceptos Políticos Usuales [en línea]: Autogestión, 2007

[consultado el 05 de Septiembre de 2015]. Disponible en Internet: http://www.eumed.net/diccionario/definicion.php?dic=3&def=163

14 OPEN INTERNATIONAL SYSTEMS. Portal de Autogestión, Definición. vol. 14. 2015. 1 archivo

de computador.

24

ofrece información particular de una empresa. La administración de la visibilidad del contenido del portal está determinada por el usuario que la utilice para ingresar al mismo. Los permisos de los usuarios están determinados por los roles que tengan asignados.

4.2 DISEÑO CENTRADO EN EL USUARIO

El Diseño Centrado en el Usuario (DCU) es definido por Abras. et al. como un enfoque de diseño cuyo proceso está dirigido por información sobre las personas que van a hacer uso del producto final15. El DCU, como filosofía de diseño, engloba o se relaciona con un heterogéneo conjunto de metodologías y técnicas que comparten un objetivo común: conocer y comprender las necesidades, limitaciones, comportamiento y características del usuario, involucrando en muchos casos a usuarios potenciales o reales en el proceso16.

Con base en lo anterior, el enfoque del DCU persigue asegurar la consecución de un producto con la funcionalidad adecuada para usuarios concretos. El objetivo de esta filosofía es ofrecer respuesta a preguntas como ¿quién usará este sistema?, ¿qué es lo que va a hacer con él? o ¿qué información necesitará para alcanzar sus objetivos?17. El objetivo final del DCU es, por tanto, lograr la satisfacción de las necesidades de todos sus usuarios potenciales, adaptar la tecnología utilizada a sus expectativas y crear interfaces que faciliten la consecución de sus objetivos.

15

ABRAS, Chadia; MALONEY-KRICHMAR, Diane y PREECE, Jenny. User-Centered Design [en línea]. Pensilvania: The Pennsylvania State University, 2009 [consultado el 19 de Agosto de 2015]. Disponible en Internet: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.381&rep=rep1&type=pdf

16 GRANOLLERS, T., LORÉS, J., & PERDRIX, F. Modelo de proceso de la Ingeniería de la

Usabilidad [en línea]: integración de la ingeniería del Software y de la Usabilidad. Granada: Universidad de Granada, 2012 [consultado 03 de abril de 2017]. Disponible en internet: http://lsi.ugr.es/~mgea/workshops/coline02/Articulos/toni.pdf

17 HASSAN, Y., MARTÍN FERNÁNDEZ, F. J., y IAZZA, G. Diseño web centrado en el usuario [en

línea]: usabilidad y arquitectura de la información. Barcelona: Universitat Pompeu Fabra, 2004 [consultado el 08 de octubre de 2015]. Disponible en Internet: https://www.upf.edu/hipertextnet/numero-2/diseno_web.html#4

25

El estándar ISO 13407:199918 describe al diseño centrado en el usuario como una actividad multidisciplinar y propone 4 actividades que se deben realizar en las primeras etapas del proceso de desarrollo:

Especificación del contexto de usuario.

Especificación de las necesidades del usuario.

Producción de soluciones de diseño.

Evaluación de las soluciones basadas en las necesidades del usuario.

La ISO 9241-210:201019 (evolución de la ISO 13407:1999), añade 6 principios primordiales al hacer uso del enfoque del diseño centrado en el usuario.

El diseño está basado en una comprensión explícita de usuarios, tareas y entornos.

Los usuarios están involucrados durante el diseño y el desarrollo.

El diseño está dirigido y refinado por evaluaciones centradas en usuarios.

El proceso es iterativo.

18

ISO. Human-centred design processes for interactive systems [en línea]: ISO 13407, 1999 [consultado el 16 de Junio de 2015]. Disponible en Internet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=21197

19 ISO. Ergonomics of human-system interaction [en línea]: Part 210: Human-centred design for

interactive systems. ISO 9241-210, 2010 [consultado el 16 de Junio de 2015]. Disponible en Internet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075http://url/

26

El diseño está dirigido a toda la experiencia del usuario.

El equipo de diseño incluye habilidades y perspectivas multidisciplinares.

4.3 EXPERIENCIA DE USUARIO (UX)

El término Experiencia de Usuario (o UX, por sus siglas en inglés User eXperience) se refiere a “cómo se sienten las personas acerca de un producto y su satisfacción cuando lo usan, lo miran, lo sostienen, lo abren o cierran”20. Actualmente, existen diferentes definiciones de la UX utilizadas por profesionales en el área de HCI, siendo una de las más destacadas la presentada en el estándar ISO 9241-21021: “Percepciones y respuestas de una persona que resultan de la utilización y/o uso anticipado de un producto, sistema o servicio”.

Law et al.22 recopilan una serie de definiciones de UX, sin embargo, estas son válidas en contextos de uso específicos y no abarcan todos los aspectos que deberían considerarse para evaluar la UX que se obtiene al interactuar con un sistema interactivo. Así, Masip et. al proponen una definición más general tal que cubre todos los aspectos requeridos: “La experiencia de usuario atiende a todos los factores, tanto internos como externos del usuario y del sistema interactivo, que causen alguna sensación a quien esté utilizando un sistema interactivo concreto en un determinado contexto de uso” 23.

20

SHARP, H. ROGERS, Y. y PREECE J., Interaction Design Beyond Human - Computer Interaction. 2 ed. Wiley, John & Sons, Incorporated, 2007. p. 99.

21 ISO, "9241-210:2008," in Ergonomics of human system interaction - Part 210: Human-centred

design for interactive systems, ed, 2008.

22 LAW, E. L.-C; ROTO, V.; HASSENZAHL, M; VERMEEREN, A. P. y KORT, J., "Understanding,

scoping and defining user experience: a survey approach". En: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. 2009, p. 719-728.

23 MASIP, L., OLIVA, M. y GRANOLLERS, T. "Concreción de la Experiencia de Usuario mediante

Atributos de Calidad" [en línea]. En: XII Congreso Internacional de Interacción Persona-Ordenador. Lisboa: Septiembre, 2011. 393 p. [consultado el 23 de Abril de 2015]. Disponible en Internet: http://aipo.es/files/actas/Interaccion2011.pdf

27

La UX abarca diferentes facetas relacionadas a la calidad de un producto software. El estándar ISO/IEC 2501024 considera de forma general las siguientes facetas de la UX: accesibilidad, emotividad, jugabilidad, usabilidad, entre otras. Así pues, el presente trabajo está enfocado exclusivamente en la faceta usabilidad de la UX. La selección de la faceta usabilidad obedece a que es la más directamente relacionada con la calidad en uso. Además, porque al momento de su evaluación, esta permite obtener información indirectamente sobre otras de las facetas.

4.3.1 Usabilidad. El término usabilidad coloquialmente es definido como “facilidad de uso” ya sea de una página web, una aplicación informática o cualquier otro sistema que interactúe con un usuario. En la actualidad existe una serie de definiciones formales, aunque no existe una definición consensuada de este término. Por esta razón, serán presentadas una serie de definiciones formales y dadas por autores prominentes del área con el objetivo de establecer la idea general del concepto.

Según la norma ISO 924125, “Usabilidad es el grado en el que un producto software puede ser utilizado por usuarios específicos para alcanzar objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso específico”. Es una definición centrada en el concepto de calidad en uso, es decir, se refiere a cómo el usuario realiza tareas específicas en escenarios específicos con efectividad. La efectividad se refiere al nivel de exactitud con que el usuario cumple los objetivos; la eficiencia se refiere a los recursos usados para la concreción de estos objetivos por parte del usuario, mientras que la satisfacción se relaciona con la comodidad del usuario durante la interacción con el producto.

La definición de usabilidad dada por Bevan26 es: “La facilidad de uso y aceptabilidad de un sistema o producto para una clase particular de usuarios que llevan a cabo tareas específicas en un ambiente específico, donde la facilidad de uso afecta el rendimiento y satisfacción del usuario y la aceptabilidad afecta si el producto es utilizado o no”. Esta definición es bastante completa y pretende integrar las dos definiciones dadas por la ISO.

24

ISO, "International Software Quality Standard, ISO/IEC 25010," in Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Systems and software quality models, ed, 2011.

25ISO, "International Standard ISO/IEC 9241," in Ergonomic requirements for office work with visual

display terminals, ed, 1998.

26 BEVAN, N., KIRAKOWSKI, J. y MAISSEL, J., Human Aspects in Computing: Design and Use of

Interactive Systems with Terminals. Amsterdam: Elsevier, 1991, p. 405.

28

Por otro lado, Jakob Nielsen, define la usabilidad con base en el siguiente comentario27: “La utilidad de un sistema en cuanto a medio para conseguir un objetivo, tiene un componente de funcionalidad (utilidad funcional) y otro basado en el modo en que los usuarios pueden usar esta funcionalidad”. Asimismo, define la usabilidad en torno a componentes medibles: facilidad de aprendizaje, eficiencia, facilidad de recordar, errores y satisfacción subjetiva.

Finalmente, para el presente trabajo será adoptada la definición dada por la ISO 9241, puesto que es ampliamente conocida y representa completamente el sentido del término en cuestión, tal como menciona Otaiza28.

27

NIELSEN, J. Usability engineering. San Francisco: Morgan Kaufmann Publishers, 1993. p. 205.

28 OTAIZA, R., "Metodología de evaluación de usabilidad para aplicaciones web transaccionales,"

Tesis de Maestría Ingeniería Informática, Escuela de Ingeniería Informática. Valparaíso, Chile: Pontificia Universidad Católica de Valparaíso, 2008. p. 135-137.

29

5. METODOLOGÍA

La metodología a utilizar en el proyecto fue determinada por Open International Systems, la cual consiste en el ciclo de desarrollo de software convencional, pero bajo un proceso en espiral (iterativo e incremental) que caracteriza a los proyectos de sistemas multimedia.

Como entregables de las etapas básicas del proceso de desarrollo convencional (definición, evaluación y diseño), la organización exige un formato denominado DAA en el cual se documentan las decisiones y observaciones de cada una de las etapas. El entregable de la fase de implementación será el Front-End del Portal de Autogestión en sí. Finalmente se obtendrán los resultados de las pruebas de usabilidad y funcionalidad.

Transversal a todas las etapas se realiza un proceso de verificación con funcionarios de Open International System validando procedimientos y funcionalidades, y a su vez con usuarios finales que puedan dar una retroalimentación del proceso que se lleva.

A continuación son descritas las etapas de desarrollo del proyecto:

5.1 ETAPA DE PRE-INICIACIÓN

Esta etapa permitirá realizar las diferentes actividades de familiarización, tanto con el producto como con la compañía. Se concretarán en primera instancia una serie de reuniones con el personal para conocer los estándares y patrones de diseño con los cuales trabajan. También, es necesaria una etapa de autoformación donde cada estudiante bajo la tutoría de un desarrollador de Open, aprenderá a usar las herramientas de desarrollo de la empresa y las técnicas utilizadas, las cuales servirán como guía en la implementación del proyecto.

5.2 ETAPA DE DEFINICIÓN

Teniendo en cuenta que la empresa Open International Systems donde los estudiantes realizarán la pasantía es una casa desarrolladora de software, se tienen ya definidos los requisitos del sistema, que a su vez dieron lugar al desarrollo de esta pasantía. Por lo tanto los estudiantes no se encargarán de realizar esta etapa.

30

5.3 ETAPA DE EVALUACIÓN O ANÁLISIS

Se definen las principales funcionalidades de la aplicación y los usuarios del portal. Se hace un bosquejo a grandes rasgos de las operaciones, componentes del sistema e interfaces en prototipado de baja calidad (wireframe).

5.4 ETAPA DE DISEÑO

Se mejora la definición del resultante en la etapa de evaluación. Son diseñadas las interfaces gráficas de usuario con prototipos de alta calidad (mockups). Se especifican detalles de cómo será el software a implementar como la estructura de contenidos, la arquitectura de la aplicación, la conexión a plataformas externas (si es necesario) y el manejo de los tipos de usuarios dentro del portal.

5.5 ETAPA DE IMPLEMENTACIÓN

Fase en la cual se desarrolla el código fuente de la aplicación basándose en los documentos obtenidos del diseño. Debido al alcance del proyecto solo se implementará el Front-End.

31

6. DESARROLLO PORTAL DE AUTOGESTIÓN

6.1 PRE-INICIALIZACIÓN DEL PROYECTO

El proceso de pre-inicialización del proyecto comienza con el conocimiento básico del producto Open Smartflex, único producto que maneja la empresa Open Systems. Continúa con los estándares y metodologías que se usan en el desarrollo de aplicaciones web. Finalmente, se realiza el proceso de autoformación en los formatos y dichas metodologías, además de las herramientas internas de la empresa para el desarrollo de las aplicaciones. Por motivos de confidencialidad los estándares que maneja Open Systems no pueden ser mostrados en este documento, pero es necesario destacar ciertos componentes de estos que son importantes para el proceso de desarrollo.

En cuanto al desarrollo de interfaces web, Open Systems tomó la decisión de desarrollar interfaces con las que los usuarios finales estén familiarizados y que se asemejen a la plataforma que usan para acceder al producto. Es decir, si la persona ingresa desde un dispositivo iOS puede estar familiarizado con los comportamientos y ubicaciones de diferentes opciones, así como en dispositivos Android y Windows.

En ese sentido, las interfaces se trabajarán bajo las guías de diseño de cada una de las plataformas de despliegue y serán la base para el desarrollo de todas las pantallas, tanto en su comportamiento, como en su estética (colores y distribución de componentes), pero, adaptando las guías a las funcionalidades que los usuarios requieren.

Teniendo en cuenta lo anterior, al tratar de asemejar la interfaz dependiendo del dispositivo en el que se visualice el producto, se decidió que las aplicaciones fueran adaptativas, por lo que el tamaño de pantalla y el dispositivo son factores que la interfaz tiene en cuenta para mostrarse, cambiando el comportamiento de algunos componentes.

6.2 ANÁLISIS DE REQUISITOS

6.2.1 Descripción inicial. La definición de los requisitos que se pretenden analizar en este apartado fueron dados por OpenSystems mediante la siguiente descripción:

32

Se requiere construir un Portal de Autogestión “plantilla” para las empresas de Utilities del mercado masivo; con aplicaciones predefinidas, es decir, que se encuentren listas para usar. Dicha plantilla podrá ser parametrizada por el cliente, para adaptarla a sus necesidades propias de negocio. Se requiere entonces contar con aplicaciones de negocio, las cuales serán interfaces intuitivas que le permitirán al usuario final ejecutar procesos y consultas29.

Debido a que el énfasis del proyecto está en el desarrollo de un sistema que incluya al usuario final, la definición de requisitos y el diseño de cada una de las funcionalidades son realizados con base en sus necesidades. Sin embargo, es necesario definir esos requisitos en colaboración con las empresas del sector utilities para definir a qué información y procesos tienen acceso los usuarios.

6.2.2 Definición de usuarios. Es necesario aclarar que existen dos individuos que hacen parte del proceso de definición de los requisitos: Open Systems, empresa encargada de definir los requisitos para sus clientes (empresas de utilities), y usuarios finales, quienes serán los que usen el Portal de Autogestión.

Así, es realizado un análisis de usuarios para identificar el perfil de un usuario potencial del Portal de Autogestión. El Cuadro 1 presenta aspectos representativos del usuario para poder definir un perfil más completo del mismo.

Cuadro 1. Análisis de usuarios

Aspecto Descripción

Demográfico Entre los 14 y los 50 años de edad, con acceso a internet, con acceso a servicios públicos básicos como agua y luz.

Psicográfico Familiarizados con smartphones y tablets, con conocimientos para navegar en internet, con servicios públicos contratados.

Conductual Usan smartphones, tablets o equipos para acceder a internet, presenta inconvenientes al momento de realizar algún trámite en las oficinas de atención de una empresa del sector utilities, confía en procesos administrativos y económicos en línea.

29

OPEN INTERNATIONAL SYSTEMS. Portal de Autogestión, Definición. vol. 14. 2015. 1 archivo de computador.

33

6.2.2.1 Perfil de usuario. El Portal de Autogestión está orientado a usuarios que se ajustan al siguiente perfil:

Edad: de 14 a 50 años.

Experiencia en el uso de tecnologías de la información (Internet).

Experiencia previa en el uso de dispositivos electrónicos que cuentan con conexión a internet.

Contratación de servicios públicos.

Disponibilidad limitada para asistir a centros de atención de las empresas prestadoras de servicios.

6.2.2.2 Descripción de la experiencia de usuario. A continuación se especifica un guion de la posible experiencia que los usuarios pueden tener con el Portal de Autogestión. Debido a la extensa cantidad de funcionalidades que el Portal de Autogestión ofrece, son presentados los siguientes ejemplos:

Ejemplo 1:

El usuario requiere realizar el pago de su factura de agua y luz de Emcali, pero su jornada laboral es hasta las 6:00 PM y las oficinas cierran a las 5:00 PM.

El usuario usa su teléfono e ingresa al Portal de Autogestión de Emcali.

El usuario ingresa su clave y contraseña.

34

El usuario verifica cuánto debe pagar basado en las facturas anteriores.

El usuario presiona el botón de pago.

El sistema se conecta a la pasarela de pagos para manejar la transferencia.

El usuario proporciona los datos de la cuenta bancaria y se realiza la transacción con éxito.

El sistema informa cual fue el estado de la transacción y muestra el estado final de sus facturas.

Ejemplo 2:

El usuario necesita hacer un reclamo en Emcali porque no está de acuerdo con su última factura y no quiere realizar papeleo en la oficina de atención.



El usuario ingresa al formulario de solicitud.

El sistema muestra las opciones que se deben diligenciar para hacer el trámite correctamente.

35

El usuario diligencia los campos solicitados.

El sistema informa del éxito del registro de la solicitud y el radicado que identifica el proceso en la empresa.

Ejemplo 3:

El usuario desea cambiar la forma en que recibe su factura y no desea esperar en la línea telefónica a que alguien lo atienda.



El usuario realiza una actualización de sus datos de correspondencia.

El sistema confirma que la información ha sido actualizada y se realizarán los ajustes para que reciba su factura de la forma deseada.

6.2.2.3 Storyboard. El storyboard permite visualizar el curso de eventos en los diferentes procesos que los usuarios pueden realizar en el Portal de Autogestión. La Figura 1 presenta el storyboard de la funcionalidad registro de quejas y/ reclamos, descrita en el Ejemplo 2 de la sección anterior. El Anexo A incluye los storyboard de los ejemplos restantes.

36

Figura 1. Storyboard de registro de quejas y/o reclamos

6.2.3 Definición de requisitos. Con base en lo planteado en la descripción inicial de las necesidades de Open Systems (ver sección 6.2.1) para el Portal de Autogestión, la definición del perfil de usuario realizada por los autores de este documento en compañía con Open Systems y los estudios realizados con prospectos de usuarios del sistema, fue elaborada una lista de requerimientos que el sistema debe cumplir. El proceso de definición de requisitos inició con las necesidades de las empresas del sector utilities, que fueron identificadas y presentadas por Open Systems en un documento con requisitos ya establecidos. Estos fueron cotejados y filtrados con el objetivo de dar solución a las necesidades de los usuarios finales del sistema. Luego, se especificaron los requerimientos funcionales y no funcionales del Portal de Autogestión.

La nomenclatura utilizada para identificar los requerimientos es:

RF#, donde RF se refiere a Requerimiento Funcional y el caracter # corresponde al número de secuencia del requerimiento.

RFN#, donde RNF se refiere a Requerimiento No Funcional y el caracter # se refiere al número de secuencia del requerimiento.

De los requisitos incluidos en la siguiente sección, dos fueron agregados después de tener conversaciones con 10 potenciales usuarios del Portal de Autogestión. Durante este proceso fue identificada una necesidad que pocas empresas habían tenido en cuenta y que los usuarios experimentan en ocasiones, asociada a los

37

costos de los consumos mensuales en una residencia. Así surgen los requerimientos: RF14 y RF15. Las conversaciones antes mencionadas fueron realizadas por el área de Soluciones de Industria de Open Systems, con lo cual, no resultó posible tener acceso a los registros de los usuarios implicados.

6.2.3.1 Requisitos Funcionales

RF01. El sistema debe permitir registrar nuevos usuarios. Para ello, se debe ingresar la siguiente información: nombre, apellido, correo electrónico y contraseña de ingreso al sistema.

RF02. El sistema debe permitir actualizar los datos de los usuarios, incluyendo la dirección de correspondencia (electrónica o física).

RF03. El sistema debe permitir recuperar la contraseña asignada a un usuario.

RF04. El sistema debe permitir iniciar y cerrar sesión a los usuarios.

RF05. El sistema debe permitir consultar la información básica de la cuenta de usuario.

RF06. El sistema debe permitir consultar la información de los productos (agua, energía y gas) y servicios asociados a la cuenta de usuario.

RF07. El sistema debe permitir consultar los PQRs relacionados a la cuenta de usuario.

RF08. El sistema debe permitir consultar las facturas asociadas a la cuenta de usuario.

RF09. El sistema debe permitir consultar los pagos realizados asociados a una cuenta de usuario.

RF10. El sistema debe permitir consultar los consumos de los productos asociados a la cuenta de usuario.

RF11. El sistema debe permitir realizar pago de facturas.

RF12. El sistema debe permitir registrar PQRs.

RF13. El sistema debe permitir consultar los movimientos y estado financiero asociados a la cuenta del usuario.

RF14. El sistema debe permitir realizar una simulación de consumo.

38

RF15. El sistema debe permitir realizar una simulación de facturación.

RF16. El sistema debe incluir las redes sociales para obtener datos de los usuarios.

6.2.3.2 Requisitos No Funcionales

RNF01. El sistema debe ser seguro (maneja información sensible).

RNF02. El sistema debe ser escalable.

RNF03. El sistema debe manejar múltiples sesiones.

RNF04. El sistema debe ser usable y familiar para el usuario.

RNF05. El sistema debe estar disponible las 24 horas al día y los 7 días a la semana.

6.3 DISEÑO DEL PORTAL DE AUTOGESTIÓN

Para el proceso de diseño fue necesario realizar una serie de prototipos que fueron evaluados con diferentes usuarios, para identificar fallas y realizar los respectivos ajustes (ver sección 7.1). Estos prototipos se hicieron de baja y alta fidelidad: los de baja fidelidad fueron realizados en papel (ver Anexo B) y fueron acondicionados para mostrar interactividad haciendo uso de la aplicación POP30; mientras que los prototipos de alta fidelidad (ver Anexo C) fueron realizados en Adobe Illustrator31 donde fue utilizada la aplicación InVision32 para agregar interactividad. Las herramientas mencionadas fueron seleccionadas dependiendo el tipo de prototipo que se deseaba desarrollar (de baja o alta fidelidad), haciendo que el proceso de prototipado y la experiencia de las pruebas fuera lo más fluida posible. Adicionalmente, Open Systems contaba con licencias de la suite de

30

POP [en línea] POP Prototyping on Paper [consultado el 20 de Abril de 2015]. Disponible en Internet: https://popapp.in/

31 ADOBE SYSTEMS INCORPORATED [en línea]: Adobe Illustrator CC. California: Adobe Systems

Incorporated, 1997 [consultado el 19 de Junio de 2015]. Disponible en Internet: http://www.adobe.com/la/products/illustrator.html

32 INVISION [en línea] InvisionApp [consultado el 02 de Julio de 2015]. Disponible en Internet:

https://www.invisionapp.com/

39

Adobe CC, por lo que la elección de Adobe Illustrator fue tomada bajo la premisa de la calidad del prototipo y la facilidad de uso de la herramienta.

Gracias a que el portal es un conjunto de herramientas que se le proporcionarán al usuario final para que las consultas y procesos en empresas del sector utilities sean más fáciles y ágiles, se decidió realizar el proceso de diseño basado en aplicaciones, es decir, el portal es una aplicación que contendrá otras mini-aplicaciones y cada una de ellas permitirán cumplir con las funcionalidades requeridas. Además, la división en mini-aplicaciones permite que el producto pueda escalarse en el futuro, ya que si se requiere agregar una nueva funcionalidad, simplemente debe de hacerse una mini-aplicación que debe añadirse al listado de aplicaciones del Portal de Autogestión.

Con la premisa del uso de mini-aplicaciones y debido a que el Portal de Autogestión será usado por diferentes usuarios, es necesario manejar un lenguaje familiar para ellos. Open Systems pretende que el usuario adquiriera sentido de pertinencia de las diferentes funcionalidades del sistema, por lo que los nombres de las aplicaciones usan verbos posesivos.

En Open Systems fue definido un sistema de nomenclatura para las aplicaciones a desarrollar, así:

CCPXX, donde CC indica el modulo del ciclo productivo de una empresa a la que pertenece la aplicación (Customer Care), la tercer letra indica el nombre del sistema que se desarrolla (Portal de Autogestión) y las 2 últimas letras indican la descripción principal de la aplicación.

El Cuadro 2 presenta las mini-aplicaciones que hacen parte del portal y los requisitos que cada una cubre:

Cuadro 2. Aplicaciones del portal vs requisitos

Aplicación Requisitos

Mis Solicitudes e Inconvenientes (CCPSL) RF07,RF12

Mis Facturas (CCPFA) RF08, RF11

Mis Pagos (CCPPA) RF09

Mis Consumos (CCPCO) RF10

Mi Cuenta (CCPCU) RF05, RF06

Mi Estado de cuenta (CCPEC) RF13

Simulador de Consumos (CCPSI) RF14, RF15

Portal de Autogestión (CCPAG) RF01, RF02, RF03, RF04, RF16

40

6.3.1 Casos de uso. Para especificar las interacciones del sistema con los usuarios se realizó un diagrama de casos de uso (ver Figura 2). Fueron especificados 19 casos de uso en respuesta a los requerimientos del sistema (ver Anexo D), de los cuales son presentadas las plantillas extendidas de aquellos más relevantes para los usuarios finales (ver 6.3.1.3).

6.3.1.1 Definición del actor. Individuo que hará uso del Portal de Autogestión, el cual no podrá realizar modificaciones de ningún tipo a los componentes del software, no requiere conocimientos avanzados sobre manejo de software y no podrá ver información sensible o confidencial de la empresa de utilities.

6.3.1.2 Identificación de los casos de uso. De acuerdo a los requerimientos definidos en la sección 6.2.3.1 y teniendo en cuenta las tareas que los usuarios realizarán en el Portal de Autogestión se definieron los siguientes casos de uso. La nomenclatura utilizada para identificar los casos de uso es:

CU_#, donde CU se refiere a “Caso de Uso” y el caracter # corresponde al número de secuencia.

Con base en lo anterior, los casos de uso son los siguientes:

CU_01: Ingresar al Portal de Autogestión.

CU_02: Ingresar nombre de usuario y contraseña.

CU_03: Registrar nuevo usuario en el sistema.

CU_04: Ingresar al sistema mediante uso de redes sociales.

CU_05: Vincular el cliente con el usuario del Portal de Autogestión.

CU_06: Actualizar datos de usuario.

CU_07: Consultar las últimas facturas.

CU_08: Pagar la última factura registrada en el sistema.

CU_09: Consultar las últimas solicitudes registradas en el sistema.

CU_10: Registrar nuevas quejas.

CU_11: Registrar nuevos daños.

41

CU_12: Solicitar un nuevo servicio.

CU_13: Consultar últimos movimientos.

CU_14: Consultar los últimos pagos realizados.

CU_15: Simular consumos.

CU_16: Simular factura.

CU_17: Consultar últimos consumos registrados en el sistema.

CU_18: Actualizar datos de recepción de correspondencia.

CU_19: Recuperar contraseña.

A continuación, la Figura 2 presenta el diagrama de casos de uso.

42

Figura 2. Diagrama de casos de uso

A la izquierda se visualiza la Parte 1 y a la derecha la Parte 2

6.3.1.3 Casos de uso detallados. Los casos de uso detallados o guion del caso de uso es un formato utilizado para describir paso a paso la interacción del actor con el sistema en un caso de uso especificado. Este formato permite a los miembros del equipo de trabajo tener un entendimiento de la funcionalidad del sistema sin lugar a ambigüedades y queda como registro de lo

43

que se debe programar. El formato de caso de uso detallado utilizado corresponde al descrito por Lund et. al33 y contiene los siguientes elementos: identificador, nombre, descripción, actores y el guion a desarrollar.

Los Cuadros 3 y 4 presentan la plantilla extendida de los casos de uso CU_15: Simular consumos, y CU_16: Simular factura, respectivamente, los cuales están relacionados con el caso de uso CU_1. Por cuestiones de extensión del documento, las plantillas extendidas de los demás casos de uso son incluidas en el Anexo D.

Cuadro 3. Caso de uso extendido CU _15

Caso de uso N° CU _15

Nombre Simular consumos.

Descripción Proceso para simular los consumos que un usuario podría tener en su hogar.

Actores Usuario

Guion

Actores Software

1. El usuario hace clic sobre el icono de la aplicación "Simulador".

2. El sistema despliega la pantalla donde podrá seleccionar los electrodomésticos con los cuales desea hacer la simulación.

3. El usuario selecciona cada uno de los electrodomésticos que tiene en su hogar, indicando la cantidad y el uso promedio de cada uno de ellos.

4. El sistema despliega una barra indicado el consumo mensual de todos los electrodomésticos seleccionados.

5. El usuario hace clic sobre el botón "Simular".

33

LUND, María Inés; FERRARINI, Cintia; ABALLAY, Laura; ROMAGNANO, María G; y MENI, Ernesto. CUPIDo - Plantilla para Documentar Casos de Uso [en línea]. San Juan, Argentina: Universidad Nacional de San Juan, 2010. [Consultado 14 de Junio, 2016]. Disponible en Internet: http://sedici.unlp.edu.ar/bitstream/handle/10915/18410/Documento_completo.pdf?sequence=1

44

Cuadro 3. (Continuación)

6. El sistema validará la información ingresada.

7. El sistema muestra el resultado de la simulación de consumo.

8. Termina el caso de uso.

Excepciones 1. Tipo de excepción presentada en la actividad 1

Actores Software

usuario 6. No es posible hacer la simulación con los datos ingresados.

CU relacionados CU_01, CU _02, CU _04.

Precondición El usuario debe estar registrado en el Portal de Autogestión.

Post Condición Sistema en espera de una nueva consulta.

Cuadro 4. Caso de uso extendido CU _16

Caso de uso N° CU _16

Nombre Simular factura. CU _01: Ingresar al Portal de Autogestión

Descripción Proceso para ingresar el nombre de usuario y la contraseña

Actores Usuario

Guion

Actores Software

1. El usuario completa los datos que encuentran en el formulario que se despliega al simular consumos.

2. El sistema validará que los datos ingresados estén correctamente diligenciados.

3. El usuario hace clic sobre el botón "Finalizar"

4. El sistema genera la factura dependiendo de los datos que el usuario haya seleccionado.

5. El sistema despliega al usuario la simulación de su factura.

45


6. Termina el caso de uso

Excepciones 1. Tipo de excepción presentada en la actividad 1

Actores Software

usuario 4. los datos ingresados no están correctamente diligenciados.

CU relacionados CU _15

Precondición El usuario debe haber hecho la simulación de consumos antes de hacer la simulación de facturación.

Post Condición Sistema en espera de una nueva consulta.

6.3.2 Arquitectura de información. Durante el proceso de prototipado (ver sección 6.3.3); evaluación y análisis de resultados (ver sección 7.1), pudo identificarse la información que requería el usuario, así como la ubicación y distribución de la misma. El objetivo de este proceso es identificar la información relevante que debe ser presentada y solicitada al usuario en el Portal de Autogestión, aportando a la distribución de dicha información y al aprovechamiento del espacio en pantalla del dispositivo móvil. Para ello, fue necesario reunir la información que las empresas de utilities podían prestar y la que los usuarios necesariamente debían tener acceso, tal como se indica en la sección 6.3.2.1.

6.3.2.1 Información en mini-aplicaciones. El Cuadro 5 presenta la información que se solicita y despliega en cada una de las aplicaciones del Portal de Autogestión, como resultado de la unión entre los requisitos de las empresas de utilities para realizar procesos y la información relevante para el usuario. Con esta información es posible identificar las entradas y salidas que puede tener cada proceso por aplicación.

46

Cuadro 5. Información desplegada y solicitada por aplicación

Aplicación Información Desplegada Información Solicitada Mis Solicitudes e Inconvenientes

Número de solicitud Fecha de registro Comentario inicial Estado Fecha de atención Respuesta

Comentario inicial Dirección de instalación Tipo de trámite: registro de queja, registro de daño y registro de nuevo servicio Producto Tipo de irregularidad

Mis Facturas Nombre del usuario Estado Valor pagado Fecha límite de pago Valor a pagar Numero de pago electrónico Mes facturado Recibo PDF

Numero de cupón de pago o factura Medio de pago Número de la cuenta Valor a pagar

Mis Pagos Fecha de pago Valor pagado

Mis Consumos Productos asociados a la cuenta Equipo de medición Tipo de consumo asociado al producto Consumo total en el mes Mes de consumo

Producto a detallar

Mi Cuenta Contrato: Número de contrato Dirección de cobro Entidad de recaudo Sucursal Tipo de tarjeta Tipo de cuenta bancaria Número de cuenta / tarjeta Productos: Plan comercial Estado Dirección Tipo de Componente Clase de servicio Estado Fecha de toma de lecturas y lectura

Dirección de cobro Cambio modalidad de envío

Mi Estado de cuenta Saldos vencidos Saldos de reclamo Saldos de financiaciones Saldo de facturas Número de cuenta Saldo pendiente

47


Aplicación Información Desplegada Información Solicitada

Simulador de Consumo

Plan comercial Periodo de facturación Valor de facturación simulada Elementos por área del hogar Consumo promedio por hora de cada elemento Consumo total aproximado mensual

Cantidad de tiempo Número de elementos por área del hogar Tipo de rango temporal Plan comercial

Portal de Autogestión Nombres y Apellidos Tipo de identificación Identificación * Número de teléfono celular y/o fijo Correo electrónico Usuario Dirección

Nombres y Apellidos Tipo de identificación Identificación * Número de teléfono celular y/o fijo Correo electrónico Usuario Dirección Contraseña

6.3.2.2 Mapa navegacional. Para entender cómo el usuario puede navegar por el Portal de Autogestión y comprender los diferentes procesos que puede realizar en él, fueron creados mapas navegacionales para las mini-aplicaciones (ver Anexo E). Para los mapas se hizo uso del lenguaje visual definido por Garret34, el cual que permite representar la interacción, jerarquía y agrupación entre las vistas del sistema. A continuación, la Figura 6 presenta el mapa navegacional de las mini-aplicaciones más representativas del sistema Menú y Simulador de Consumos (definidas en Cuadro 2).

34

GARRET, Jesse James. Un vocabulario visual para describir arquitectura de información y diseño de interacción [en línea]. Marzo, 2002 [consultado 28 de abril de 2015]. Disponible en Internet: http://www.jjg.net/ia/visvocab/spanish.html

48

Figura 3. Mapa navegacional – Menú y Simulador de consumos

6.3.3 Diseño de interfaces. El diseño de las interfaces de usuario pretende tomar como insumo las etapas anteriormente mencionadas para poder plasmar en una representación gráfica las funcionalidades a las que se tienen acceso desde el Portal de Autogestión. En el diseño fueron utilizados dos tipos de representaciones gráficas: Sketches (bocetos) y Mockups (prototipos de alta fidelidad o maquetas digitales); cada una acorde a las evaluaciones presentadas en la sección 7.1.

6.3.3.1 Sketches. Como primer acercamiento a las interfaces fueron elaborados sketches por cada una de las mini-aplicaciones (definidas en 6.3) del Portal de Autogestión. Estos sketches fueron realizados bajo las guías de diseño proporcionadas por Open Systems, considerando además la jerarquía en la información, el despliegue de la misma y la premisa de crear una serie de componentes posibles de reutilizar en todas las mini-aplicaciones. La totalidad de

49

las interfaces en baja calidad son presentadas en el Anexo B. Las Figuras 7 y 8 presentan 2 de las mini-aplicaciones que hacen parte del Portal de Autogestión.

Figura 4. Sketches Menú - Portal de Autogestión

50

Figura 5. Sketches Simulador de Consumos - Portal de Autogestión

En esta fase de diseño se trabajó con el objetivo de obtener una serie de componentes de las interfaces, sin embargo, no fue posible definir todos los componentes necesarios para el desarrollo del sistema. En términos generales, fue posible definir la estructura en el despliegue de la información para dispositivos móviles y tablets, jerarquizar la información teniendo en cuenta el contexto de la funcionalidad y verificar con posibles usuarios las interacciones básicas de las mini-aplicaciones.

51

6.3.3.2 Mockups. La segunda etapa de diseño de interfaces para el Portal de Autogestión inició una vez fueron validados los sketches de las mini-aplicaciones. Esta etapa fue realizada con el objetivo de terminar de definir los componentes a usar en las interfaces, definir el look and feel del Portal de Autogestión y aplicar los cambios que fueron solicitados en la etapa anterior. La evaluación de estos prototipos permitió la identificación de inconvenientes en la navegación, distribución e información innecesaria en las interfaces.

Para los mockups diseñados (ver Anexo C), fueron usados colores y estilos propios de iOS7 por órdenes de la empresa Open Systems. Algunos de los elementos de las guías de diseño iOS7 fueron redefinidos en estilos y comportamientos para su uso como componentes. Las Figuras 9 a 11 presentan los mockups realizados para el Portal de Autogestión.

Figura 6. Mockups Menú (login) - Portal de Autogestión

52

Figura 7. Mockups Menú (home) - Portal de Autogestión

Figura 8. Mockups Simulador de Consumos - Portal de Autogestión

6.4 IMPLEMENTACION DEL FRONT-END

6.4.1 Framework de desarrollo. Para la implementación del Portal de Autogestión se utilizó un framework de desarrollo que minimizó los tiempos de

53

desarrollo, Sencha ExtJs635, el cual usa: JS (JavaScript) como lenguaje de programación; HTML (HyperText Markup Language) para lenguaje de marcado y templates; y SASS (Syntactically Awesome Style Sheets) como preprocesador de CSS (Cascading Style Sheets), que maneja la estética visual de todas las aplicaciones y componentes.

El framework Sencha ExtJs6 tiene como premisa el uso de webcomponents para la elaboración de aplicaciones, lo cual contribuye a minimizar el desarrollo de aplicaciones individuales. Además, está basado en el paradigma MVC (Modelo Vista-Controlador), lo que proporciona flexibilidad en el control de la aplicación desde el lado del cliente.

El paradigma MVC que Sencha proporciona fue utilizado de la siguiente manera: el modelo se usó como la estructura de la información que llega de base de datos; la vista es la representación visual de esos datos que también permite la interacción con el usuario final; y por último, el controlador realiza los llamados a base de datos y controla las interacciones más complejas que se tienen en la vista. Esta forma de uso fue definida por los lineamientos de Open Systems para el desarrollo de aplicaciones web.

Es importante aclarar que, aunque el Portal de Autogestión se trate como una aplicación web, en realidad está conformado por una biblioteca de aplicaciones (mini-aplicaciones) que representan las funcionalidades del portal. Los componentes se diseñaron y crearon en un repositorio compartido por todas las mini-aplicaciones, con el objetivo de usar un componente sin tener que volverse a crear desde cero en cada aplicación.

6.4.2 Base de datos. Aunque el desarrollo del Back-End del Portal de Autogestión no corresponde al alcance del proyecto, a continuación se describe de forma general el proceso realizado.

Debido a la arquitectura del producto Open Smartflex, que está construido bajo lenguaje PL/SQL y usa una base de datos Oracle del lado del back, Open Systems decidió realizar la conexión desde el cliente web por medio de una pasarela llamada DAD (Database Access Descriptor) de la suite de herramientas Oracle.

35

SENCHA. Sencha ExtJS [en línea].California: Sencha, 2007 [consultado el 14 de Abril de 2015]. Disponible en Internet: https://www.sencha.com/products/extjs/#overview

54

Esta arquitectura permite que realizar una conexión desde un servidor de aplicaciones con la base de datos resulte sencillo, seria necesario realizar una petición por AJAX (Asynchronous JavaScript And XML) al DAD con los datos necesarios enmascarados en un formato JSON (JavaScript Object Notation). En el JSON se debe especificar el método que se ejecutará en base de datos, ya sea para realizar una consulta o ejecutar un proceso.

Con base en lo anterior, cada aplicación debe realizar las peticiones correspondientes mediante AJAX a la base de datos, por lo que se decidió centralizar todas las peticiones en un Singletone (archivo de ejecución independiente accedido desde cualquier mini-aplicación), que contiene la lógica para enviar parámetros de entrada y salida de los métodos que se ejecutarán. El Cuadro 6 presenta la lista de métodos (consultas y procesos en PL/SQL) que están asignados para cada aplicación.

Cuadro 6. Métodos de BD por aplicación

Aplicación Método DB (paquete/procedimiento)

Mis Solicitudes e Inconvenientes (CCPSL)

Requests.GetLastNPackageBySusb

Mis Facturas (CCPFA) Bills.GetLastNBillBySusc PrintMgr.GetBillPDFDocument OnlinePayment.RegisterPaymentProcess OnlinePayment.RegisterPaymentParams

Mis Pagos (CCPPA) Payments.GetBillsPayments

Mis Consumos (CCPCO) Consumptions.GetMetersConsuptionsByContract Consumptions.GetConsSlotsByPeriod Consumptions.GetTraditionalConsumption

Mi Cuenta (CCPCU) Accounts.GetAccountInfo Accounts.GetProdInfoBySusc Accounts.UPDAccountInfo

Mi Estado de cuenta (CCPEC) AccountStatus.GetStatusAcc MovAccStat.CarteraCronologicaContrato AccountStatus.GetInfoPay AccountStatus.GetInfoNote AccountStatus.GetInfoDeferred PrintMgr.GetBillPDFDocument AccountStatus.GetInfoAnullPay

Simulador de Consumo (CCPSI)

BillingSimulator.GetSimulatorParams BillingSimulator.ProcessSimulatorParams

Portal de Autogestión (CCPAG) Sa_boR.CPU Sa_boR.LPU Sa_boR.RPU

55

Nota: Por razones de confidencialidad son cambiados los nombres de los paquetes usados en la base de datos para el Portal de Autogestión.

6.4.3 Front-End. Para que el proceso de la implementación del Front-End del Portal de Autogestión iniciara, fue necesario realizar evaluaciones de los prototipos de baja y alta fidelidad (ver 6.3.3.1 y 6.3.3.2). Esto inicialmente ocasionó un reproceso con los hallazgos encontrados, pero gracias a este proceso de evaluación fue posible definir los componentes a desarrollar en el sistema, lo que minimizó el tiempo de desarrollo y la cantidad de archivos con código repetido.

6.4.3.1 Componentes de interfaz. Uno de los objetivos del desarrollo de este proyecto es aprovechar las ventajas que tiene el trabajo de webcomponents en aplicaciones de gran escala. Con base en esto y con los insumos proporcionados por el diseño de interfaces (ver 6.3.3), se lograron definir ciertos elementos similares en su forma y comportamiento (algunos con variaciones mínimas). La Figura 12 presenta un ejemplo de definición de componentes base por aplicación individual, y en la Figura 13 se presenta una comparativa entre dos interfaces que permitían definir elementos en común.

Figura 9. Identificación elementos base en interfaces

Componente “Barra de herramientas”

Componente “Aplicación”

56

Figura 10. Identificación elementos similares entre interfaces

Elementos base de las interfaces como: botones, barras, contenedores, visualizadores de información, etc., fueron definidos como componentes, con la posibilidad de añadir una configuración para soportar cada una de las variaciones

Componente “Barra de título”

(Botón atrás)

Componente “Vista de detalle”

Componente “Barra de título”

(Botón atrás)

Componente “Vista de detalle”

57

que presentaban. Es decir, para el componente barra de herramientas, por ejemplo, se definieron propiedades de configuración como título, botón izquierdo y botón derecho. Esta posibilidad de configurar los componentes permitió realizar los ajustes que cada mini-aplicación del portal necesitara.

Para cada uno de los componentes se definió un estilo que permitiera tener consistencia en todo el Portal de Autogestión. Además, cada una de las mini-aplicaciones que hacían uso de estos componentes también contaban con un archivo de estilos que podrían, según la necesidad, sobre-escribir los estilos de algunos componentes o añadir estilos propios de cada una.

Gracias a esta estética compartida entre todos los componentes y la diagramación de las aplicaciones, se crea un ambiente consistente. Adicionalmente, la implementación de nuevas aplicaciones se facilita, ya que si se quiere es posible crear una aplicación a partir del uso de componentes simples sin lógica extra.

Para todos los componentes, dependiendo de su función, se definieron eventos (change, focus, blur), clases identificadoras de CSS, comportamiento de despliegue y configuraciones (sólo lectura, requerido, placeholder, etc.) que posibilitaban su creación y uso externo.

6.4.3.2 Arquitectura. El modelo de componentes no sólo permite el reúso de estos en diferentes aplicaciones, también posibilita que sean usados entre ellos mismos, es decir, un componente contenedor puede contener un componente barra de herramientas, lo que lo convierte en un nuevo componente.

Los componentes fueron categorizados por la función que cumplen en las interfaces, así: los componentes que permiten el ingreso de datos (ingreso de texto, direcciones, fecha, número, checkbox, listas de valores, etc) fueron categorizados en campos; componentes que permiten definir el layout de las aplicaciones fueron categorizados como contenedores (paneles, contenedores y contenedores compuestos); los componentes de despliegue de información (como listas, vistas de detalle y gráficas) fueron categorizados como interfaces de representación de datos; y por último, la categoría formulario reúne los componentes que contienen campos de ingreso de información.

Todos los componentes pertenecen a un paquete requerido por cada aplicación. Este paquete tiene las referencias a los componentes que serán usados y gracias a este es posible definir instancias de ellos. En la definición de la aplicación sólo se hace el requerimiento al (los) componente (s) a usar y se especifica la

58

configuración de estos. El compilador se encarga de resolver a qué paquete pertenece ese componente y lo requiere para que sea posible usarlo.

Cada aplicación cuenta con uno o varios archivos de vistas, un controlador principal que sirve como pasarela para la comunicación entre la base de datos y la vista, manejo de rutas, colecciones de datos (generalmente cargadas con la información que retorna la base de datos) y modelos que definen la estructura de la información (formatos, organización y definición de información relevante). La Figura 14 presenta el esquema en jerarquía de carpetas para realizar la implementación.

Figura 11. Jerarquía de Carpetas del Portal de Autogestión

59

Cabe resaltar que todo el código creado es luego compilado y minificado para su uso en un navegador web (dependiendo de la plataforma de acceso), manteniendo así: las fuentes para el desarrollo y los archivos compilados para producción. También, por cada una de las aplicaciones creadas, sin importar que en las fuentes se tengan varios archivos SASS y JS, es generado: un archivo index.html, un archivo app.js y un archivo app.css. Esto con el fin de mejorar el rendimiento de la aplicación y facilitar el proceso de distribución.

60

7. EVALUACIÓN DE USABILIDAD

Esta sección presenta las interacciones que se tuvieron con usuarios del Portal de Autogestión con el fin de evaluar su usabilidad. El apartado 7.1 describe las evaluaciones realizadas con usuarios potenciales, mientras que el apartado 7.2 describe la evaluación realizada con expertos.

7.1 EVALUACIÓN CON USUARIOS POTENCIALES

7.1.1 Evaluación de Sketches. El objetivo de la evaluación de sketches es verificar si los usuarios pueden realizar una serie de tareas con la interfaz propuesta, teniendo en cuenta la cantidad de información, el tipo de información presentada y la forma de despliegue. La utilización de esta técnica de prototipado no precisa incorporar avances tecnológicos, sólo es necesario que simule a grandes rasgos la funcionalidad del sistema y que comunique la información adecuadamente. Las siguientes secciones presentan la planeación, ejecución y análisis de resultados obtenidos.

7.1.1.1 Planeación. Dado que el sistema apunta a un público objetivo amplio, se decidió realizar la evaluación inicial de los sketches con personal de Open Systems que alguna vez haya interactuado con un sistema de gestión, además, debido al perfil del usuario definido en la sección 6.2.2, estos califican como potenciales usuarios del sistema. El objetivo era poder obtener la mayor cantidad de observaciones a partir de la evaluación que se llevó a cabo, con el modelo de evaluación empírica como lo menciona Peishan36. El Cuadro 7 describe las condiciones de las evaluaciones que se realizaron a los Sketches.

36

PEISHAN, Tsai. A survey of empirical usability evaluation methods [en línea]: GSLIS Independent

Study. Boston: Simmons Collegue, 2005 [consultado 07 de agosto de 2016]. Disponible en Internet: http://web.simmons.edu/~tsai/Papers/PBartley-empirical-usability-eval.pdf

61

Cuadro 7. Descripción evaluación Sketches

Lugar Open Systems S.A.S, Cali

Duración Total (Minutos)

90

Muestra (Cantidad Usuarios)

10

Perfil de usuario

Ingenieros desarrolladores de software de la empresa Open Systems S.A.S con una edad promedio de 25 años, de diversas áreas de la empresa aunque el área con mayor cantidad de usuarios fue interfaces gráficas.

Obtención de usuarios

Los usuarios fueron seleccionados aleatoriamente entre las personas que se encontraban trabajando al momento de iniciar las pruebas en la empresa Open Systems S.A.S. Previamente fue consultado si estaban de acuerdo y posteriormente los que respondieron afirmativamente se les proporcionó los prototipos en papel para su respectiva evaluación.

7.1.1.2 Ejecución. A cada usuario que aceptó realizar las pruebas con el prototipo en papel, se le asignaron las siguientes tareas:

Consultar la última factura generada.

Realizar cambios en su información personal.

Solicitar un nuevo servicio.

Consultar los productos que tiene contratados.

El cumplimiento exitoso de las tareas propuestas contribuye a determinar si los usuarios logran comprender la funcionalidad del sistema y finalmente comprobar que las interfaces comunican la información adecuadamente.

62

El proceso de evaluación fue realizado mediante la ejecución del método del conductor en complemento con una encuesta. El método del conductor, como lo explican Reyes y Libreros37, consiste en que el usuario es guiado por el evaluador, y éste aprovecha para hacerle preguntas acerca de los elementos de la Interfaz de usuario e infiere por qué este usuario no comprende ciertos lenguajes que lo llevan a interactuar con la información. Al finalizar la evaluación era realizada una encuesta la cual permitió obtener información complementaria al método del conductor. Las preguntas que conformaron la encuesta son las siguientes:

¿Comprendió la funcionalidad del sistema?

¿Fue clara la relación existente entre cada una de las interfaces?

¿Se le facilitó hacer las tareas propuestas para la evaluación de las interfaces?

¿Las interfaces comunicaron la información de cada una de las aplicaciones de Portal de Autogestión adecuadamente?

¿Las interacciones en cada una de las interfaces fueron adecuadas?

7.1.1.3 Resultados obtenidos. El orden de las tareas según la dificultad que presentaron los usuarios al realizarlas con ayuda del método del conductor, donde 1 es la tarea más fácil, y 4 es la más difícil es:

Consultar la última factura generada.

Consultar los productos que tiene contratados.

37

REYES VERA, Javier M. y LIBREROS GIRALDO, Freddy Alejandro. Método para la evaluación integral de la usabilidad en sistemas e-learning [en línea]. Santiago de Cali: Universidad del Valle, 2011 [consultado 05 de Mayo de 2016]. Disponible en Internet: http://www.educacioneningenieria.org/index.php/edi/article/viewFile/126/113

63

Realizar cambios en su información personal.

Solicitar un nuevo servicio.

De los 10 usuarios, 7 mostraron facilidad al realizar la consulta de la última factura generada, 6 mostraron facilidad en la realización de la tarea de consulta de productos contratados y realizar cambios de información personal, y 3 mostraron facilidad para realizar la solicitud de un nuevo servicio.

Los resultados obtenidos a partir de la encuesta realizada al grupo de 10 individuos y aplicando la escala de Likert38, pueden visualizarse en el Anexo F. Las Figuras 7 a 11 presentan los resultados obtenidos en la encuesta aplicada, mientras que el análisis es presentado en la sección 7.1.1.4.

Figura 12. Resultados Pregunta 1 del cuestionario

38

ANTZ. Escala de Likert [en línea] Instituto Cultural Tampico [consultado 10 de Agosto de 2016]. Disponible en Internet: http://www.ict.edu.mx/acervo_bibliotecologia_escalas_Escala%20de%20Likert.pdf

9% 0%

18%

0%

73%

¿Comprendió la funcionalidad del sistema?

1 2 3 4 5

64



70%

30%

¿Fue clara la conexión existente entre cada una de

las interfaces?

si no

80%

20%

¿Se le facilitó hacer las tareas propuestas para la

evaluación de las interfaces?

Si Inicialmente no

65



7.1.1.4 Conclusiones de la evaluación. Después de analizar los resultados obtenidos y las observaciones dadas por los usuarios se llegó a las siguientes conclusiones:

Los usuarios mostraron mayor facilidad para realizar consultas de facturas ya que el nombre de la aplicación y el despliegue inicial de la información no daba pie a equivocaciones y era clara. Se presentó cierta dificultad para solicitar un nuevo

90%

10%

¿Las interfaces comunicaron la información de cada una

de las aplicaciones de Portal de Autogestión …

Si Puede mejorar

60%

40%

¿Las interacciones de cada una de las interfaces fueron

adecuadas?

si no

66

servicio, esto debido a la cantidad de información que se mostraba y era pedida para poder realizar el proceso.

La información del cliente, como el correo electrónico y el nombre, no debería visualizarse siempre en todas las pantallas, conviene ubicarla en un sólo lugar para que cuando el cliente la necesite pueda consultarla. Esto, debido a que dicha información es redundante y ocupa espacio en algunas pantallas donde puede presentarse otro tipo de contenido.

Conviene no utilizar menús que se encuentren “escondidos”, esto significa que la aparición de las opciones no dependa de la interacción directa con un elemento de la interfaz, garantizando que el usuario identifique rápidamente las opciones disponibles en la aplicación.

Para el simulador de consumos sería adecuado que se utilizaran iconos representativos de cada uno de los electrodomésticos en vez de colocar el nombre de cada uno de ellos.

En lugar de utilizar un botón para agregar los electrodomésticos, conviene utilizar la pantalla para mostrarlos todos y darle la posibilidad al usuario de ir agregándolos uno a uno y mostrar en tipo real el consumo y el valor que pagaría.

7.1.2 Evaluación de prototipo funcional. El objetivo de la evaluación del prototipo funcional es demostrar cómo son manejadas las interacciones y cómo son presentadas las diferentes funcionalidades que ofrece el sistema. Con base en los Mockups que corresponden a un prototipo de alta fidelidad, incluyendo también la evaluación de aspectos estéticos del sistema, se realizó un prototipo funcional con datos e información ficticios, pero que pueden llegar a presentarse en un caso real. Las siguientes secciones presentan la planeación, ejecución y análisis de resultados obtenidos.

7.1.2.1 Planeación. Se decidió realizar la evaluación del prototipo funcional con miembros de la compañía que fueron voluntarios para probar el sistema luego de haber realizado su promoción en la empresa Open Systems. En esta evaluación fue utilizado el método interacción constructiva, el cual consiste en que dos usuarios interactúan conjuntamente, descubriendo las características del sistema en evaluación, mientras verbalizan sus impresiones mutuamente, como

67

una conversación39. El Cuadro 8 describe las condiciones de las evaluaciones que se realizaron a los Sketches.

Cuadro 8. Descripción evaluación prototipo funcional

Lugar Open Systems S.A.S, Cali

Duración (Minutos)

30

Muestra (Cantidad Usuarios)

24

Perfil de usuario

Ingenieros desarrolladores de software de la empresa Open Systems S.A.S con una edad promedio de 25 años, de diversas áreas de la empresa. Además, se pudo realizar un acercamiento con trabajadores de compañías del sector utilities.

Obtención de usuarios

Los usuarios fueron seleccionados aleatoriamente entre las diferentes áreas de la empresa Open Systems, los cuales querían probar cómo funcionaba el sistema después de una conferencia pública al interior de la compañía.

7.1.2.2 Ejecución. Al momento de ejecutar el método, a cada pareja de usuarios les fueron presentadas 3 funcionalidades del Portal de Autogestión para que las exploraran, esas son:

Simulador de Consumos

39

ECUSI, Evaluación Colaborativa de la Usabilidad de Sistemas Interactivos, Interacción constructiva [en línea]: Métodos de evaluación de usabilidad [consultado 18 de Agosto de 2016]. Disponible en Internet: http://www.ecusi.com/method-list#eval6

68

Mis Facturas

Mis Consumos

Luego, se les informó a grandes rasgos el objetivo del Portal de Autogestión y las funcionalidades a explorar. Posteriormente, se fue tomando nota de cada una de las observaciones que hacían. Al final, luego de explorar las funcionalidades sugeridas, fueron realizadas las siguientes preguntas:

¿Qué mejoraría del Portal de Autogestión?

¿Qué elementos considera que le hacen falta al Portal de Autogestión?

Las preguntas realizadas obedecen al objetivo de identificar si existe alguna funcionalidad que ya estuviera contemplada en el alcance pero no hubiera sido totalmente clara; alguna que exista pero tenga falencias o alguna que se pasó por alto en los encuentros anteriores con usuarios. Con base en las observaciones registradas por los moderadores, fue posible analizar los casos que presentan más relevancia para los posibles usuarios del sistema.

7.1.2.3 Resultados obtenidos. Las observaciones que fueron tomadas por parte de los usuarios fueron clasificadas en dos categorías: estéticas y funcionales. Las estéticas hacen referencia a colores, tamaños, formas, etc. Las funcionales corresponden a las tareas específicas que se realizaban, la forma de hacerlas y los resultados esperados. La ejecución de este método de prueba permitió recopilar 20 observaciones funcionales y 50 estéticas, para un total de 70 observaciones, donde el número de comentarios similares, fueron 10 y 15, respectivamente.

7.1.2.4 Conclusiones de la evaluación. Después de analizar los resultados de la evaluación se llegó a las siguientes conclusiones:

La mini-aplicación Simulador de Consumos fue la más popular entre las 3 presentadas, debido a que a partir de las observaciones realizadas pudo

69

identificarse que más del 50% de los usuarios presentaron interés en esta funcionalidad.

El comentario más frecuente que realizaron los participantes de la prueba está relacionado con la similitud de la interfaz del Portal de Autogestión y las interfaces de las aplicaciones iOS.

Más del 60% de los usuarios expresaron inconformidad por el tiempo de respuesta de las aplicaciones. Esto pudo ser evaluado y se detectó que era debido a la carga de recursos y a la cantidad de peticiones que se hacían a base de datos.

Existen aplicaciones que aunque tienen una funcionalidad independiente comparten gran parte de información, por lo tanto es posible que puedan ser agrupadas, por ejemplo: Mis Movimientos y Mis Pagos.

La mayoría de los usuarios expresaron la similitud que existe entre las interfaces de las diferentes mini-aplicaciones. Esto debido a la apariencia de los elementos que conforman la interfaz con la que interactúa el usuario, como lo son formularios, barras de herramientas, presentación de información, etc.

7.2 EVALUACIÓN DE EXPERTOS

Adicional a las evaluaciones realizadas con usuarios potenciales del sistema, se contó con la colaboración de 5 expertos para realizar una evaluación heurística del sistema. El Anexo G describe el proceso de evaluación en su totalidad. Las siguientes secciones presentan la planeación, ejecución y análisis de resultados obtenidos mediante este método de inspección.

7.2.1 Planeación. Para llevar a cabo la evaluación heurística fue elaborado un documento guía para informar a los evaluadores sobre el sistema a evaluar y heurísticas a utilizar. Adicionalmente, dicho documento guía incluye una plantilla para que los evaluadores anoten los problemas de usabilidad detectados en el sistema. En la evaluación fueron utilizados 11 principios heurísticos los cuales fueron desarrollados para evaluar aplicaciones móviles (soportadas en dispositivos

70

móviles con tecnología táctil), como los plantea Rusu40. El documento guía puede ser consultado en el Anexo G.

El Cuadro 9 presenta información relacionada al grupo de evaluadores que participaron en la evaluación de usabilidad. Por razones de confidencialidad, la identificación de los evaluadores no es revelada.

Cuadro 9. Perfiles evaluadores

Evaluador Experiencia previa Organización

Evaluador 1 Experiencia y conocimiento en el tema de usabilidad y evaluaciones heurísticas. Años de experiencia: más de 5.

Universidad del Cauca, Colombia





Evaluador 4 Experiencia y conocimiento en el tema de usabilidad y evaluaciones heurísticas. Años de experiencia: 2.

Universidad Autónoma de Occidente, Colombia

Evaluador 5 Experiencia y conocimiento en el tema de usabilidad y evaluaciones heurísticas. Años de experiencia: 2.

Universidad Autónoma de Occidente, Colombia

7.2.2 Ejecución. El documento guía de evaluación fue enviado mediante correo electrónico con las instrucciones para ingresar y usar el Portal de Autogestión. A los evaluadores les fue proporcionada la URL del sistema para que accedieran e inspeccionaran la versión funcional del sistema, la cual contenía datos de prueba que la empresa Open Systems configuró.

40

INOSTROZA, R.; RUSU, C.; RONCAGLIOLO, S.; JIMÉNEZ, C. y RUSU, V. Usability Heuristics for Touchscreen-based Mobile Devices. En: Information Technology: New Generations (ITNG), 2012 Ninth International Conference, 2012, p. 653.

71

7.2.3 Análisis de resultados. A continuación, es presentado el proceso y resultados obtenidos en las actividades que conforman la etapa de análisis de resultados.

7.2.3.1 Problemas por principio heurístico. Mediante la realización de la evaluación heurística fueron detectados 50 problemas de usabilidad. El Cuadro 10 presenta la cantidad de problemas de usabilidad identificados, los cuales están agrupados según el principio de usabilidad que incumplen.

Cuadro 10. Cantidad de problemas por principio heurístico

Id Principio Heurístico Problemas que incumplen el principio Total

H1 Visibilidad del estado del sistema P4, P6, P7, P8, P10, P25, P42 7

H2 Coincidencia entre el sistema y el mundo real P5, P7, P9, P10, P11, P12, P25, P29, P35 9

H3 Control y libertad del usuario P3, P33, P47 3

H4 Consistencia y estándares P13, P14, P23, P24, P26, P31, P32, P37 8

H5 Prevención de errores P15, P16, P17, P27, P43, P44, P46 7

H6 Minimizar la carga de memoria del usuario P28, P38, P40 3

H7 Personalización y atajos P1 1

H8 Eficacia de uso y rendimiento P18, P26, P27, P29, P45, P48 6

H9 Diseño estético y minimalista P19, P20, P30, P34, P35, P36, P37 7

H10 Ayuda al usuario para recuperarse de errores P2, P21, P22, P29 4

H11 Ayuda y Documentación P39, P41 2

Total 50

7.2.3.1.1 Ranking de criticidad. Luego de obtener una lista integrada de problemas por parte de los evaluadores expertos, se solicitó a cada uno de ellos asignar calificaciones (de 0 a 4) respecto a la severidad y frecuencia de los problemas, para luego calcular los respectivos promedios. Los problemas fueron ordenados descendentemente según el valor obtenido en la criticidad (severidad + frecuencia) promedio, lo que permite estudiar cuáles son los problemas más críticos según la evaluación heurística. Dado que el valor de la criticidad está acotado en el rango de 0 a 8, se ha tomado como punto de corte para este ranking el valor 5. Dicho valor de corte obedece a la necesidad de identificar los problemas de usabilidad mayores que son importantes para corregir y que se les debe dar alta prioridad. El cuadro 11 presenta los problemas de usabilidad que están por encima del valor de corte.

72

Cuadro 11. Problemas con mayor ranking de criticidad

Comentarios/Explicaciones S F C

En el caso de formularios con errores puedo borrar y actualizar información, pero no puedo devolverme a mi estado inicial.

3 2.8 5.6

En Mi cuenta, No es posible saber cuál es el tipo de servicio que el usuario tiene registrado.

3 3 6

En Mis solicitudes e inconvenientes, el usuario no se entera a simple vista cuáles solicitudes que han sido atendidas (mediante colores, por ejemplo).

3.6 4 7.6

En Mi plan de pagos, no resulta clara la información presentada al usuario. ¿Total, pagado vs Total planeado?

2.6 3 5.8

En Mis facturas, al pagar aparece el mensaje: “Enviando datos a pasarela de pagos”.

2.6 3 5.6

En Mi estado de cuenta, el texto azul (saldo pendiente, saldo vencido) parece vínculos. Esto puede confundir al usuario.

3 2.6 5.6

En Mis facturas, en Problemas con tu factura. El usuario no recibe realimentación de que un campo está incompleto al oprimir el botón “Ejecutar”.

2.8 3 5.6

Verificación de los números de cuenta. 3 2.6 5.6

No funciona el recordar la contraseña. Adicionalmente se genera un error, que es imposible de leer.

3 3.4 6.4

Debería aparecer el nombre del usuario que ingresa visible 4 3.6 7.4

Falta validar cuando se hace una simulación que retornan valores con más de 5 dígitos.

3.6 3.2 6.6

En la aplicación Nuevo servicio, existen problemas de funcionalidad. No es posible generar un nuevo servicio.

4 3.6 7.4

No reconoce el número de contrato asignado o sugerido para registrar una cuenta y no se encuentra ayuda a la mano para obtenerlo.

3 2.6 5.4

La solicitud de nuevos servicios no genera información o formatos adicionales. Es decir, no funciona.

2.4 3.2 6

El simulador de consumo no funciona, no permite realizar los cálculos, y por ende no presenta la información solicitada.

3 2.6 5.6

73

7.2.3.1.2 Ranking de severidad. En este ranking se optó por utilizar como valor de corte una severidad de 3, dado que ésta varía entre 0 y 4. Dicho valor de corte obedece a la necesidad de identificar las funcionalidades que presentan problemas de usabilidad con alto grado de severidad y que deben ser atendidas lo más pronto posible. Así, el Cuadro 12 presenta los resultados.

Cuadro 12. Problemas con mayor ranking de severidad


En el caso de formularios con errores puedo borrar y actualizar información, pero no puedo devolverme a mi estado inicial.

3 2.8 5.6

En Solicitar nuevo servicio, cuando es seleccionada la opción “Ejecutar”, no se presenta realimentación al usuario. No se menciona al usuario que los campos son obligatorios (a pesar de incluir los asteriscos).

3 2.8 5.6


3 3 6


3.6 4 7.6

En Mi estado de cuenta, el texto azul (saldo pendiente, saldo vencido) parece vínculos. Esto puede confundir al usuario.

3 2.6 5.6

En Mis Consumos, el mecanismo para la selección del producto no es claro. Además, la flecha que apunta a la derecha no funciona.

3 2.6 5.4

Verificación de los números de cuenta. 3 2.6 5.6


3 3.4 6.4

Debería aparecer el nombre del usuario que ingresa visible 3 3 6


3.6 3.2 6.6


4 3.6 7.4

No reconoce el número de contrato asignado o sugerido para registrar una cuenta y no se encuentra ayuda a la mano para obtenerlo.

3 2.6 5.4

El simulador de consumo no funciona, no permite realizar los cálculos, y por ende no presenta la información solicitada.

3 2.6 5.6

7.2.3.1.3 Ranking de frecuencia. En este ranking se optó por utilizar como valor de corte una frecuencia de 3, dado que ésta varía entre 0 y 4. Dicho valor de corte obedece a la necesidad de identificar los problemas que presentan una frecuencia importante y deben ser corregidos prioritariamente. Así, el Cuadro 13 presenta los resultados.

74

Cuadro 13. Problemas con mayor ranking de frecuencia



3 3 6


4 4 8

En Mi plan de pagos, no resulta clara la información presentada al usuario. ¿Total, pagado vs Total planeado?

2.6 3 5.8

En Mis facturas, al pagar aparece el mensaje: “Enviando datos a pasarela de pagos”

2.6 3 5.6

No hay consistencia entre el texto de las opciones del menú principal (solo la primera mayúscula) y los títulos en cada opción (las primeras mayúsculas).

2.4 3 5.4

En Mis facturas, en Problemas con tu factura. El usuario no recibe realimentación de que un campo está incompleto al oprimir el botón “Ejecutar”.

2.8 3 5.6


3 3.4 6.4

No pude ingresar el número de contrato ya que los mensajes eran poco claros. 2 3 5

Debería aparecer el nombre del usuario que ingresa visible 3 3 6


3.6 3.2 6.6


2.4 3.2 6

75

7.2.3.2 Análisis e interpretación de los resultados. A partir de los resultados presentados en la Cuadro 10 (Cantidad de problemas por principio heurístico), es evidente la supremacía en cuanto a cantidad de problemas de usabilidad que incumplen con el principio H2 y H4, Coincidencia entre el sistema y el mundo real y Consistencia y estándares, respectivamente, ya que “el sistema presenta una serie de elementos que no son familiares y fáciles de entender para los usuarios” (P5, P7, P9, P10, P11, P12, P25, P29, P35). Además, “en algunos casos el sistema no hace una validación apropiada de la información ingresada por los usuarios”. “La aplicación debe permitirle al usuario la capacidad de obtener resultados de una manera familiar, estándar y consistente” (P13, P14, P23, P24, P26, P31, P32, P37).

Por otro lado, otro principio de usabilidad con un número representativo de problemas es H1, Visibilidad del estado del sistema, el cual tiene asociados 7 problemas. Básicamente, “los problemas asociados a este principio (así como también al principio H5) indican que el sistema no sigue algunos estándares que han sido establecidos para el diseño web”. Además, “el sistema presenta deficiencias en el diseño puesto que existen secciones y/o funcionalidades donde no se conoce el estado en que se encuentra el sistema al igual que no advierte a los usuarios acerca de acciones importantes”.

Mediante la ejecución de la evaluación heurística no fueron detectados problemas de usabilidad catastróficos que pusieran en riesgo el funcionamiento del sistema, sin embargo, los problemas mayores identificados afectan la facilidad de uso de algunas funcionalidades que ofrece la aplicación móvil, en especial, “Mis solicitudes e inconvenientes”, puesto que el usuario no se entera a simple vista cuáles solicitudes han sido atendidas mediante colores (uno de los principales objetivos de esta aplicación)”. En general, el nivel de criticidad de los problemas es bajo, debido a que los problemas con notas mayores a 6 representan menos de la mitad del total de problemas encontrados, 16 de los 49 problemas fueron calificados, en promedio, con notas mayores a 5 (en una escala de 0 a 8), y 32 de los 49 problemas detectados fueron calificados con notas inferiores a 5.

Dado el punto de corte, valor de criticidad 5, se obtuvieron 16 problemas con un alto nivel de criticidad. Los problemas con mayor criticidad corresponden a los principios: Visibilidad del estado del sistema (H1), Diseño estético y minimalista (H9) y Coincidencia entre el sistema y el mundo real (H2)”. Un problema obtuvo el valor de criticidad más alto que es 8. “En la aplicación Nuevo servicio, existen problemas de funcionalidad. No es posible generar un nuevo servicio”. Esto indica que, debido a una falla de funcionamiento, la aplicación no permite crear solicitudes de nuevos servicios. Este problema, al igual que P36 (con criticidad 7), limitan el sistema, debido al mal funcionamiento del mismo.

76

Otro de los problemas con alta criticidad está relacionado con el principio Visibilidad del estado del sistema. En la opción “Mis solicitudes e inconvenientes”, el usuario no se entera a simple vista cuáles solicitudes han sido atendidas. Debido a que los colores de la interfaz de usuario son uniformes no hay posibilidad de ver rápidamente si una solicitud e inconveniente ha sido atendida o no, sería conveniente que para cada solicitud e inconveniente nuevo se utilice un color diferente, esto con el fin de mejorar la navegabilidad de la aplicación.

Varios problemas obtuvieron el valor de criticidad 6. Uno de ellos se refiere a que al realizar algún cambio en información no es posible volver al estado anterior (P2), esto es indispensable cuando se están llenando formularios o información importante, debido a que normalmente existen equivocaciones por parte del usuario. También, no es posible que los usuarios personalicen elementos del sistema de acuerdo a sus necesidades, características, preferencias personales, etc. (P22). En la aplicación “Solicitar nuevo servicio”, cuando es seleccionada la opción “Ejecutar”, no se presenta realimentación al usuario. No se menciona al usuario que los campos son obligatorios (a pesar de incluir los asteriscos) (P23), además el nombre del usuario que ingresa a la aplicación no se presenta visible en ninguna parte de la aplicación (P24).

Respecto al ranking de severidad, siendo el valor de corte 3, fueron detectados 16 problemas con un valor igual o mayor a este. En este ranking la cantidad de problemas coinciden con los que han sido resultado del ranking de criticidad (P3, P4, P6, P8, P9, P10, P14, P16, P26, P27, P35, P36, P41, P42, P43, P44). Además, estos problemas tienen el mayor valor en la frecuencia, lo que evidencia su alta criticidad. Dentro del ranking de frecuencia los problemas que no coincidieron en los rankings de severidad y criticidad son P13 y P29.

7.2.3.3 Identificar elementos positivos del sistema. Los elementos positivos identificados en el sistema son:

Son claras las funcionalidades que tiene el sistema, ya que cada aplicación las representa.

Las interfaces son consistentes en su diseño.

Siempre es posible saber qué proceso estoy realizando.

77

La aplicación tiene un diseño orientado en un sistema minimalista y orientado en un sistema común para una gran cantidad de personas.

En general, el sistema presenta adecuada organización de los elementos.

Uso de iconos acertados en las diferentes opciones.

En general respeta las reglas y estándares de inicio de sesión por medio de un correo electrónico y/o redes sociales.

Los colores utilizados hacen ver a la interfaz seria pero no aburrida.

En cada una de las aplicaciones dentro del portal de autogestión se presenta una ayuda que da una noción acertada de que es lo que se puede hacer.

La interface en general es intuitiva.

78

8. CONCLUSIONES

La metodología definida por Open International Systems, consiste en el ciclo de desarrollo de software convencional bajo un proceso en espiral (iterativo e incremental), dicha metodología facilitó el desarrollo del Portal de Autogestión. Adicionalmente, al proceso establecido por la empresa fueron incluidos lineamientos que permiten involucrar al usuario en el proceso de desarrollo. Si bien el usuario no fue incluido desde una etapa inicial, debido a que los requisitos fueron proporcionados por Open Systems, fue construido un producto en el que los usuarios tuvieron una participación activa en las etapas de desarrollo y pruebas.

El proceso de análisis de requerimientos fue una etapa crucial para el desarrollo del Portal de Autogestión, ya que permitió sentar bases sólidas que soportaron el direccionamiento del sistema. Cabe mencionar que el análisis realizado a los requisitos iniciales permitió definir posteriormente funcionalidades adicionales que no había considerado la empresa y que en la actualidad son vistas como valor agregado al producto.

Involucrar al usuario en el proceso de diseño y desarrollo del producto permitió que los cambios realizados al final del proceso de desarrollo del sistema fueran menores, ya que los aspectos que manifestaban los usuarios (como, por ejemplo: recomendaciones de diseño) fueron considerados e incluidos en el sistema. Esto con el objetivo de maximizar el potencial de uso del Portal de Autogestión, así como la facilidad de uso del mismo.

El uso del modelo de webcomponents para el diseño del Front-End permitió definir de mejor manera la agrupación de elementos visuales y funcionales de las diferentes mini-aplicaciones. Esto permitió también mantener la consistencia entre cada una de las funcionalidades a cubrir por el Portal de Autogestión y mejorar el proceso de impacto en todas las mini-aplicaciones, ya que se modifica el componente directamente para que sus cambios se reflejen en todo el portal.

En la etapa de implementación se agilizó el proceso gracias al modelo de webcomponents, ya que se debían crear los diferentes componentes base que se usaban en cada aplicación, para luego ser añadidos y distribuidos en cada aplicación como fuera necesario. Además, dicho modelo permitió incluso que fuera más sencillo modificar algún aspecto estético o funcional de un componente, ya que al modificarse el componente base, el cambio se ve reflejado en cada una de las aplicaciones que lo utilizan, sin tener que realizar algún tipo de compilación o cambios en su código fuente.

79

Durante la etapa de implementación, también se identificaron problemas en el rendimiento de las aplicaciones cuando los componentes eran requeridos de forma externa. Si se requerían de forma interna donde el resultado fuera un solo código minificado el tiempo de carga disminuía en un 30%, en comparación con la carga de diferentes archivos por componente.

Aplicar diferentes métodos de evaluación de usabilidad permitió identificar gran variedad de aspectos relevantes, relacionados tanto con el componente estético como funcional. En el caso de haber usado sólo un método, es posible pasar por alto algunos aspectos concretos. Adicionalmente, el momento para aplicar estas evaluaciones también juega un papel importante al momento de identificar problemas de usabilidad, por eso, es recomendable la aplicación de estas evaluaciones en las diferentes fases del proceso de desarrollo.

La evaluación realizada al Portal de Autogestión mediante métodos de evaluación de usabilidad con usuarios representativos y evaluadores expertos, fue determinante para identificar la percepción de los usuarios frente a las funcionalidades del sistema, así como para detectar problemas de usabilidad severos y frecuentes que pueden afectar el uso del sistema. Ahora bien, se considera que las evaluaciones realizadas son un soporte adecuado para lanzar el sistema implementado, y que éste sea aprobado por los usuarios. La evaluación con expertos fue relevante ya que los usuarios, pese a ser quienes utilizarán el sistema en su entorno real, no tienen los conocimientos necesarios para dar un juicio objetivo sobre aspectos relacionados a la usabilidad del sistema. Por lo tanto, al evaluar el sistema con expertos en temas de usabilidad fue posible que cada detalle fuera examinado con detenimiento.

Cabe destacar que los usuarios participaron en casi todas las etapas del proyecto, sintiéndose comprometidos con este. Esta fue una experiencia gratificante, ya que la intención fue generar un sistema que pueda utilizarse en el contexto real del usuario final, y con la participación de ellos, fue posible desarrollar las mini-aplicaciones que se espera sean de utilidad tanto para el público objetivo como para las empresas del sector utilities. La participación de los usuarios durante cada evaluación a los prototipos iniciales, generó una evolución continua en cuanto a ajustes de las interfaces del sistema, logrando satisfacer las sugerencias de los mismos. De esta manera, se podría garantizar que el Portal de Autogestión resulta familiar para los usuarios potenciales y reales.

Con base en los resultados obtenidos en las evaluaciones a usuarios del Portal de Autogestión, puede concluirse que el desarrollo de una plataforma usando guías de diseño de otro sistema provoca una pérdida de identidad. Por lo tanto, es

80

recomendable rediseñar o modificar la apariencia del sistema, dándole así una identidad que es fundamental al momento de construir un producto.

81

9. RECOMENDACIONES

El cliente no es necesariamente el mismo usuario, por lo tanto es necesario definirlo correctamente. Conviene recordar que si se está trabajando bajo diseño centrado en el usuario, ellos serán los principales usuarios y así poder llegar a un equilibrio entre las necesidades de las dos partes involucradas.

Definir correctamente los componentes a usar en el desarrollo de aplicaciones web, puede disminuir drásticamente los tiempos de desarrollo. Se debe pensar en las potenciales funcionalidades que puedan tener los componentes base y explorar las similitudes entre las interfaces para definir el mayor número de componentes que puedan compartir.

Al momento de desarrollar software para diferentes plataformas y que éste sea escalable, se recomienda usar la metodología Mobile First, debido a que iniciar el proceso de desarrollo orientado a dispositivos móviles facilita la definición de la información vital para el correcto funcionamiento de la aplicación.

El uso de frameworks para el desarrollo de aplicaciones web permite que los programadores sean más productivos, la aplicación sea más mantenible y no se invierta tanto tiempo en la implementación. Sin embargo, al decidirse por un framework en particular debe tenerse en cuenta que, si en un futuro se quiere migrar a otro, esto no resulte costoso y complejo.

Las guías de diseño, como su nombre lo indica, son guías o recomendaciones, por lo cual siempre no pueden tomarse como una regla o una camisa de fuerza, ya que en ocasiones es necesario considerar alternativas por fuera de las guías para poder cubrir las necesidades del usuario.

82

10. TRABAJOS FUTUROS

Como principales actividades futuras se encuentran las mejoras a realizar al Portal de Autogestión según los resultados de la evaluación heurística, pero que Open Systems aún no ha aprobado para su implementación. Además, es conveniente explorar el proceso de desarrollo en las otras plataformas móviles que se pretenden cubrir (Windows y Android). Por otro lado, resulta importante añadir una capa de personalización, que le permita a las empresas de utilities alinear su identidad corporativa con la plataforma, garantizando el respeto a la marca y al manejo de su imagen sin afectar el funcionamiento del portal.

83

BIBLIOGRAFÍA

ADN. Con sanciones, intentan acabar con filas en la vía pública [en línea]. Junio 29, 2015 [consultado el 20 de Julio de 2015]. Disponible en Internet: http://diarioadn.co/bogota/mi-ciudad/proyecto-para-acabar-las-filas-afuera-de-las-entidades-1.22362

ABRAS, Chadia; MALONEY-KRICHMAR, Diane y PREECE, Jenny. User-Centered Design [en línea]. Pensilvania: The Pennsylvania State University, 2009 [consultado el 19 de Agosto de 2015]. Disponible en Internet: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.381&rep=rep1&type=pdf

ADOBE SYSTEMS INCORPORATED [en línea]: Adobe Illustrator CC. California: Adobe Systems Incorporated, 1997 [consultado el 19 de Junio de 2015]. Disponible en Internet: http://www.adobe.com/la/products/illustrator.html

ANTZ. Escala de Likert [en línea]. Tampico, México: Instituto Cultural Tampico [consultado 10 de Agosto de 2016]. Disponible en Internet: http://www.ict.edu.mx/acervo_bibliotecologia_escalas_Escala%20de%20Likert.pdf

ARNOLETTO, E.J. Glosario de Conceptos Políticos Usuales [en línea]: Autogestión, 2007 [consultado el 05 de Septiembre de 2015]. Disponible en Internet: http://www.eumed.net/diccionario/definicion.php?dic=3&def=163

BANCO DE BOGOTÁ. Banco de Bogotá [aplicación] Play Store, Mayo, 2015.

BEVAN, N., KIRAKOWSKI, J. y MAISSEL, J., Human Aspects in Computing: Design and Use of Interactive Systems with Terminals. Amsterdam: Elsevier, 1991, 577 p.

COLOMBIA TELECOMUNICACIONES S.A. Movistar CO [aplicación] Play Store, Mayo, 2015.

CHILQUINTA. Chilquinta Móvil [en línea]. Chile, 2015 [consultado 28 de Abril de 2015] Disponible en Internet: http://m.chilquinta.cl/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.381&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.381&rep=rep1&type=pdf

http://www.adobe.com/la/products/illustrator.html

http://www.eumed.net/diccionario/definicion.php?dic=3&def=163

http://m.chilquinta.cl/

84

ECUSI, Evaluación Colaborativa de la Usabilidad de Sistemas Interactivos, Interacción constructiva [en línea]: Métodos de evaluación de usabilidad [consultado 18 de Agosto de 2016]. Disponible en Internet: http://www.ecusi.com/method-list#eval6

GARRET, Jesse James. Un vocabulario visual para describir arquitectura de información y diseño de interacción [en línea]. Marzo, 2002 [consultado 28 de abril de 2015]. Disponible en Internet: http://www.jjg.net/ia/visvocab/spanish.html

GRANOLLERS, T., "MPIu+a una metodología que integra la ingeniería del software, la interacción persona-ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares". Tesis Doctoral. Lleida: Universidad de Lleida. Departamento de Sistemas Informáticos, 2004. 280 p.

GRANOLLERS, T., LORÉS, J., & PERDRIX, F. Modelo de proceso de la Ingeniería de la Usabilidad [en línea]: integración de la ingeniería del Software y de la Usabilidad. Granada: Universidad de Granada, 2012 [consultado 03 de abril de 2017]. Disponible en internet: http://lsi.ugr.es/~mgea/workshops/coline02/Articulos/toni.pdf

GRUPO BANCOLOMBIA. Bancolombia App [aplicación] Play Store, Mayo, 2015.

HASSAN MONTERO, Yusef y MARTÍN FERNÁNDEZ, Francisco J. Guía de Evaluación Heurística de Sitios Web [en línea]. En: No Solo Usabilidad. 2003, no. 2 [consultado el 08 de octubre de 2015]. Disponible en Internet: http://www.nosolousabilidad.com/articulos/heuristica.htm

HASSAN, Y., MARTÍN FERNÁNDEZ, F. J., y IAZZA, G. Diseño web centrado en el usuario [en línea]: usabilidad y arquitectura de la información. Barcelona: Universitat Pompeu Fabra, 2004 [consultado el 08 de octubre de 2015]. Disponible en Internet: https://www.upf.edu/hipertextnet/numero-2/diseno_web.html#4

INOSTROZA, R.; RUSU, C.; RONCAGLIOLO, S.; JIMÉNEZ, C. y RUSU, V. Usability Heuristics for Touchscreen-based Mobile Devices. En: Information Technology: New Generations (ITNG), 2012 Ninth International Conference, 2012, 667 p.

INVISION [en línea] InvisionApp [consultado el 02 de Julio de 2015]. Disponible en Internet: https://www.invisionapp.com/

http://www.jjg.net/ia/visvocab/spanish.html

http://lsi.ugr.es/~mgea/workshops/coline02/Articulos/toni.pdf

https://www.upf.edu/hipertextnet/numero-2/diseno_web.html#4

85

ISO. Human-centred design processes for interactive systems [en línea]: ISO 13407, 1999 [consultado el 16 de Junio de 2015]. Disponible en Internet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=21197

ISO. Ergonomics of human-system interaction [en línea]: Part 210: Human-centred design for interactive systems. ISO 9241-210, 2010 [consultado el 16 de Junio de 2015]. Disponible en Internet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075http://url/

ISO, "9241-210:2008," in Ergonomics of human system interaction - Part 210: Human-centred design for interactive systems, ed, 2008.

ISO, "International Software Quality Standard, ISO/IEC 25010," in Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Systems and software quality models, ed, 2011.

ISO, "International Standard ISO/IEC 9241," in Ergonomic requirements for office work with visual display terminals, ed, 1998.

LAW, E. L.-C; ROTO, V.; HASSENZAHL, M; VERMEEREN, A. P. y KORT, J., "Understanding, scoping and defining user experience: a survey approach". En: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. 2009, 803 p.

LUND, María Inés; FERRARINI, Cintia; ABALLAY, Laura; ROMAGNANO, María G; y MENI, Ernesto. CUPIDo - Plantilla para Documentar Casos de Uso [en línea]. San Juan, Argentina: Universidad Nacional de San Juan, 2010. [consultado 14 de Junio, 2016]. Disponible en Internet: http://sedici.unlp.edu.ar/bitstream/handle/10915/18410/Documento_completo.pdf?sequence=1

MASIP, L., OLIVA, M. y GRANOLLERS, T. "Concreción de la Experiencia de Usuario mediante Atributos de Calidad" [en línea]. En: XII Congreso Internacional de Interacción Persona-Ordenador. Lisboa: Septiembre, 2011. 393 p. [consultado el 23 de Abril de 2015]. Disponible en Internet: http://aipo.es/files/actas/Interaccion2011.pdf

86

MASIP, L., OLIVA, M. y GRANOLLERS, T., "User experience specification through quality attributes". En: Human-Computer Interaction–INTERACT 2011. New York: 2011, 660 p.

NIELSEN, J. Usability engineering. San Francisco: Morgan Kaufmann Publishers, 1993. 403 p.

OPEN INTERNATIONAL SYSTEMS [en línea]: Acerca de nosotros. Cali: Open International Systems, 1987 [consultado el 16 de Julio de 2015]. Disponible en Internet: http://www.openinternational.com/es/index.html

OPEN INTERNATIONAL SYSTEMS. Portal de Autogestión, Definición. vol. 14. 2015. 1 archivo de computador.

OPEN INTERNATIONAL SYSTEMS [en línea]: Open Smartflex. Cali: Open International Systems, 1987 [consultado el 20 de Julio de 2015]. Disponible en Internet: http://openinternational.com/es/product.html

OTAIZA, R., "Metodología de evaluación de usabilidad para aplicaciones web transaccionales," Tesis de Maestría Ingeniería Informática, Escuela de Ingeniería Informática. Valparaíso, Chile: Pontificia Universidad Católica de Valparaíso, 2008. 230 p.

PEISHAN, Tsai. A survey of empirical usability evaluation methods [en línea]: GSLIS Independent Study. Boston: Simmons Collegue, 2005 [consultado 07 de agosto de 2016]. Disponible en Internet: http://web.simmons.edu/~tsai/Papers/PBartley-empirical-usability-eval.pdf

POP [en línea] POP Prototyping on Paper [consultado el 20 de Abril de 2015]. Disponible en Internet: https://popapp.in/

REYES VERA, Javier M. y LIBREROS GIRALDO, Freddy Alejandro. MÉTODO para la evaluación integral de la usabilidad en sistemas e-learning [en línea]. Santiago de Cali: Universidad del Valle, 2011 [consultado 05 de Mayo de 2016]. Disponible en Internet: http://www.educacioneningenieria.org/index.php/edi/article/viewFile/126/113

http://openinternational.com/es/product.html

https://popapp.in/

87

SENCHA. Sencha ExtJS [en línea].California: Sencha, 2007 [consultado el 14 de Abril de 2015]. Disponible en Internet: https://www.sencha.com/products/extjs/#overview

SHARP, H. ROGERS, Y. y PREECE J., Interaction Design Beyond Human - Computer Interaction. 2 ed. Wiley, John & Sons, Incorporated, 2007. 120 p.

WACHHOLZ-PRILL, Andre y KUPKE, Markus. Displaying information from a portal website [en linea]. Minneapolis: Octubre, 2005 [consultado el 26 de Diciembre de 2016]. Disponible en Internet: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20050223310.pdf

https://www.sencha.com/products/extjs/#overview

88

ANEXOS

Anexo A. Storyboards

Se encuentra como archivo adjunto en el CD.

Anexo B. Sketches


Anexo C. Mockups


Anexo D. Casos de uso


Anexo E. Mapa navegacional


89

Anexo F. Encuestas de Sketches

Se presenta a continuación la plantilla que se usó para la encuesta realizada en la etapa de evaluación prototipos de baja fidelidad (Sketches). Figura 17. Plantilla encuesta Sketches

90

Anexo G. Evaluación heurística


desarrollo del front-end de un portal de autogestiÓn...

Documents