Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
UNIDAD DE POSGRADO
PROYECTO DE TESIS
MODELO DE GESTIÓN DE REQUERMIENTOS (REQM) BASADO EN CMMI-DEV Y EXPERIENCIA USUARIA (UX) PARA MEJORAR LA GESTIÓN DE REQUERIMIENTOS DE DESARROLLO DE
SOFTWARE EN EMPRESAS DE MICRO FINANZAS
TESIS PARA OBTAR EL GRADO ACADÉMICO DE MAGÍSTER EN INGENIERÍA DE SISTEMA E INFORMÁTICA CON MENCIÓN EN GESTIÓN DE
TECNOLOGÍA DE INFORMACIÓN Y COMUNICACIONES
AUTOR:
Iván Hinostroza Cahuana
ASESOR:
Dr. Hugo Froilán Vega Huerta
Lima - Perú
2019
DEDICATORIAA mis padres, por su amor, apoyo, enseñanzas y por desear lo mejor para mi vida.
AGRADECIMIENTOSA mi madre por su apoyo incondicional y motivación.
EPÍGRAFELa experiencia del usuario abarca todos los aspectos de la interacción del usuario final con la empresa, sus servicios y sus productos (Jakob Nielsen y Donald Norman).
El diseño no es solo lo que parece y se siente. El diseño es como funciona (Steve Jobs).
RESUMEN
Titulo : Modelo de Gestión de Requerimientos (REQM) basado CMMI-DEV y Experiencia Usuaria (UX) para mejorar la gestión de requerimientos de desarrollo de Software en empresas de Micro Finanzas
Autor : Iván Hinostroza Cahuana
Asesor de Tesis : Dr. Hugo Froilán Vega Huerta
Fecha : Noviembre 2019
En la actualidad los proyectos de software gestionados por empresas del sector financiero muestran una alta tasa de fracasos. Es decir solo el 29% de los proyectos son exitosos, se realizaron en plazo, costes y con todas la funcionalidad definidas por el usuario.
Tal es el caso de las organizaciones del país dedicadas a otorgar financiamiento y captación de ahorros principalmente a las pequeñas y micro empresas, vienen incumplimiento los objetivos del proyecto.
El presente trabajo de investigación, propone un modelo de trabajo que ayude a mejorar la gestión de requerimientos de desarrollo de software y cumplir con los objetivos del proyecto. Esta propuesta se ha construido basándose en las buenas prácticas de CMMi DEV (Modelo de Madurez de Capacidades Integrado) en combinación con Experiencia Usuaria.
Pablaras Clave: Modelo de Madurez de Capacidades Integrado (CMMi Dev) y Experiencia Usuaria (UX)
ABSTRACT
Title : Requirements (REQM) Management Model based on CMMI-DEV and User Experience (UX) to improve the management of Software development requirements in Micro Finance companies
Author : Iván Hinostroza Cahuana
Thesis Advisor : Dr. Hugo Froilán Vega Huerta
Date : Noviembre 2019
Currently, software projects managed by companies in the financial sector show a high failure rate. In other words, only 29% of the projects are successful, they were carried out in time, costs and with all the functionality defined by the user.
Such is the case of organizations in the country dedicated to granting financing and attracting savings mainly to small and micro businesses, the objectives of the project are not being met.
This research work proposes a work model that helps improve the management of software development requirements and meet the project objectives. This proposal has been built based on CMMi DEV (Capability Maturity Model Integration) good practices in combination with User Experience.
KEYWORDS:
Integrated Capability Maturity Model (CMMi Dev) and User Experience (UX)
ÍNDICE
DEDICATORIA--------------------------------------------------------------------------------------------------2
AGRADECIMIENTOS-----------------------------------------------------------------------------------------3
EPÍGRAFE-------------------------------------------------------------------------------------------------------4
RESUMEN--------------------------------------------------------------------------------------------------------5
ABSTRACT------------------------------------------------------------------------------------------------------6
ÍNDICE-------------------------------------------------------------------------------------------------------------7
INTRODUCCIÓN-----------------------------------------------------------------------------------------------9
CAPITULO I: VISIÓN DEL PROYECTO---------------------------------------------------------------10
1.1. Antecedentes del Problema---------------------------------------------------------------------10
1.1.1. El Negocio-----------------------------------------------------------------------------------10
1.1.2. Proceso del Negocio---------------------------------------------------------------------11
1.2 Formulación del Problema-----------------------------------------------------------------------13
1.2.1 Realidad Problemática-------------------------------------------------------------------13
1.2.2. Descripción del Problema--------------------------------------------------------------14
1.2.2.1. Problema Principal--------------------------------------------------------------------14
1.2.2.2. Problema Secundario-----------------------------------------------------------------15
1.3. Objetivos de Proyecto----------------------------------------------------------------------------15
1.3.1. Marco Lógico-------------------------------------------------------------------------------15
1.3.1.1. Árbol de Problema:---------------------------------------------------------------------15
1.3.1.2. Árbol de Objetivos:---------------------------------------------------------------------17
1.3.2. Objetivo General---------------------------------------------------------------------------18
1.3.3. Objetivos Específicos--------------------------------------------------------------------18
1.4. Justificación del Proyecto-----------------------------------------------------------------------19
1.4.1. Justificación Académica----------------------------------------------------------------19
1.4.2. Beneficios tangibles----------------------------------------------------------------------19
1.4.3. Beneficios Intangibles-------------------------------------------------------------------19
1.5. Alcance del Proyecto-----------------------------------------------------------------------------19
CAPÍTULO II: MARCO TEÓRICO-----------------------------------------------------------------------20
2.1. CMMI para Desarrollo----------------------------------------------------------------------------20
2.1.1. Según (Mukund Chaudhary & Abhishek Chopra) (ISBN: 978-0-13-427671-7)----------------------------------------------------------------------------------------------20
El autor describe conceptos de que es CMMI, su evolución, cuando se puede utilizarse, quién lo puede utilizar, niveles de madurez, áreas de proceso.----20
2.2 Experiencia Usuaria (UX)-------------------------------------------------------------------------26
2.2.1. Según (Westley Knight) (ISBN: 978-1-4842-4227-8)---------------------------26
2.3 Requerimiento/Requisito-------------------------------------------------------------------------30
2.3.1. Según (Klauss Pohl and Chris Rupp) (ISBN: 978-1-937538-77-4)---------30
2.3.2. Según (Karl Wiegers and Joy Beatty) (ISBN: 978-0-7356-7966-5)---------35
INTRODUCCIÓN
En la última década con la llegada de nueva tecnologías, las empresas se enfrentan a nuevo escenarios y retos, el aumento de la exigencia de los clientes. Esto ocasiono que las empresas se adapten a estos escenarios y desarrollen nuevas estrategias, apoyándose en las tecnologías de información para el logro de sus objetivos estratégicos y comerciales.
En la actualidad las tecnologías de la información tienen un gran impacto en las empresas, indistintamente del tamaño o giro de negocio.
Los proyectos de software gestionados por empresas del sector financiero muestran una alta tasa de fracasos, donde:
El 29% de los proyectos son exitosos, se realizaron en plazo, costes y con todas la funcionalidad definidas por el usuario.
El 56% de los proyectos son cuestionados, finalizan pero no satisfacen por completo en plazo, costes y/o funcionalidades definidas.
El 15% de los proyectos fracasan, no llegan a finalizar y son cancelados. Resultado del Informe del CAOS 2015 de la investigación de “The Standish Group”.
El presente documento desarrolla la propuesta de un modelo de trabajo para empresas de Micro Finanzas para mejorar la gestión de requerimientos de desarrollo de software, cumplir los objetivos del proyecto, basado en las buenas prácticas de CMMI DEV y Experiencia Usuaria (UX). El documento se realiza en cuatro capítulos los cuales se detallan a continuación:
En el capítulo I, contiene la visión del proyecto que describe y detalla los antecedentes, análisis de la problemática, presenta los objetivos generales y específicos, seguidamente de una justificación del tema y el alcance a desarrollarse.
En el capítulo II, contiene el desarrollo del marco teórico
CAPITULO I: VISIÓN DEL PROYECTO
1.1. Antecedentes del Problema
1.1.1. El Negocio
Las tecnologías de información mantienen una relación con el sector banca y financiero desde la aparición de los sistemas de información, a mediados del siglo XX.
Las entidades financieras hacen uso estratégico de la tecnología para obtener ventajas competitivas en un mercado donde los productos están estandarizados y son fácilmente replicables.
El trabajo de investigación analiza a organizaciones dedicadas a otorgar financiamiento y captación de ahorros principalmente a las pequeñas y micro empresas del país.
De acuerdo a un reciente estudio, el fracaso de los proyectos de software tiene un porcentaje alto, la consultora especializa en gestión de proyectos de software “Standish Group”, realizo una investigación cuantitativa sobre el éxito de los proyectos llevado a cabo en todo el mundo (años 2011 a 2015) desde mantenimiento pequeños hasta grandes proyectos, el resultado fue el reporte de CHAOS (Fig. 1 y 2).
El 44% de proyectos finalizaron en plazo (OnTime), 40% en presupuesto OnBudget) y el 56% en alcance (OnTarget). El cumplimiento de las variables significa que el proyecto se resolvió dentro de un tiempo estimado razonable, se mantuvo dentro del presupuesto, y contenía un buen número de las características y funciones estimadas
Figura 1: Porcentaje de proyectos en Presupuesto (onBudget), en Plazo (onTime), en Alcance (onTarget).
Fuentes: Standish Group, Chaos Report 2015
Successful o exitoso. El proyecto se completa en plazo, costes y con todas la funcionalidad definidas por el usuario.
Challenged o cuestionado. El proyecto se completa, pero sin satisfacer por completo las expectativas de plazo, costes y/o funcionalidad definidas por el usuario.
Failed o fracasado. El proyecto no llega finalizarse y es cancelado.
Figura 2: Tradicional resolución para todos los proyectos, 2011 - 2015Fuentes: Standish Group, Chaos Report 2015
1.1.2. Proceso del Negocio
Para la construcción de un sistema de información, se tiene un ciclo de vida del desarrollo de software.
El Modelo de Cascada
Se refiere a un modelo de desarrollo con fases secuenciales claramente definidas y objetivos de fases. Esto requiere revisiones intermedias del trabajo en progreso para asegurar que los requerimientos de cada fase se cumplan completamente antes de comenzar la siguiente
Figura 3: Modelo de Cascada para el desarrollo de softwareFuentes: https://www.ionos.es/digitalguide/paginas-web/desarrollo-
web/el-modelo-en-cascada/
Ágil
En este método, el progreso se logra en pequeñas partes y etapas tal como en el modelo de iteración. Mejora la colaboración y la flexibilidad en el proceso de desarrollo.
Figura 4: Modelo de Cascada para el desarrollo de softwareFuentes: https://openwebinars.net/blog/que-es-un-sprint-scrum/
1.2 Formulación del Problema
1.2.1 Realidad Problemática
Un reciente estudio de “The Standish Group”, selecciona 5, 140 proyectos de transformación digital (DTP) y proyectos de TI tradicionales, dentro de la base de datos CAOS. A continuación se detalla los resultados sobre el éxito de los proyectos.
DTPs utilizando la definición tradicional de OnTime, OnBudget y OnTarget tienen una tasa de éxito ligeramente inferior a los proyectos generales en la base de datos. Nuestra investigación muestra 37% de los 50.000 proyectos en la base de datos CAOS tuvieron éxito, mientras que el 34% de los proyectos DTP tuvieron éxito. (Fig. 3)
Figura 5: La resolución tradicional de todos los proyectos y proyectos de DTP
Fuentes: Standish Group, Chaos Report 2016
En cuanto a la resolución del proyecto por la industria ofrece otra vista de la base de datos de CAOS. La tabla de esta página muestra la resolución de DTPs por la industria de FY2007-2016 dentro de la base de datos de CAOS.
Los resultados muestran que los proyectos comerciales tuvieron la mayor tasa de éxito del 35% utilizando la definición moderna de éxito. (Fig. 4)
Los resultados también muestran que los proyectos gubernamentales y financieras tenían menor índice de éxito del 14%, y los proyectos del gobierno tuvo la mayor tasa de fracaso del 25%. (Fig. 4)
Figura 6: La resolución de DTPs por la industriaFuentes: Standish Group, Chaos Report 2016
1.2.2. Descripción del Problema
1.2.2.1. Problema Principal
En la actualidad en organizaciones dedicadas a otorgar financiamiento y captación de ahorros principalmente a las pequeñas y micro empresas de los diversos sectores económicos del país, en sus áreas de tecnología se observa deficiencias en las especificaciones y gestión de los requisitos, inadecuada gestión de riesgos, carencia de patrocinio de la Gerencia/Jefatura en la mejora del proceso de desarrollo de software, falta de control y evaluación del cumplimiento y eficacia del proceso de desarrollo. Los cuales conllevan a incumplir con los objetivos de sus proyectos. Afectando el alcance, tiempo, calidad y costes, debido a la ineficiencia en la gestión de los requerimientos de desarrollo de software en empresas de micro finanzas. Generando el fracaso del proyecto y no entrega del software, Incumplimiento de requisitos, falta de estrategias y guías de integración del producto, proyecto fuera presupuesto y tiempo e insatisfacción del área usuaria.
(Variable 1: Porcentaje de proyectos que finalizan en presupuesto según investigación de STANDISH GROUP, valor: 44%Variable 2: Porcentaje de proyectos que finalizan en plazo según investigación de STANDISH GROUP, valor: 40%Variable 3: Porcentaje de proyectos que finalizan en alcance según investigación de STANDISH GROUP, valor: 56%)
1.2.2.2. Problema Secundario
El usuario no tiene claro lo que necesita, si es viable y cuál es su complejidad.
Errores introducidos durante las actividades de requisitos. El aumento de la compresión, generan nuevos requisitos. Dificultad y desconocimiento del usuario para introducir mejoras
y cambios en el software existente. Alta tasa de cambio y evolución de la tecnología.
1.3. Objetivos de Proyecto
1.3.1. Marco Lógico
1.3.1.1. Árbol de Problema:
Figura 7: Árbol de ProblemasFuentes: Elaboración Propia, 2019
1.3.1.2. Árbol de Objetivos:
Figura 8: Árbol de ObjetivosFuentes: Elaboración Propia, 2019
1.3.2. Objetivo General
Proponer un modelo para la gestión de requerimientos basado en las buenas prácticas del CMMI Dev (Modelo de Madurez de Capacidades de Integración) y en la experiencia de usuario (UX - User Experience), mejorar el patrocinio (gobierno) de Gerencia/Jefatura del área de tecnología en la mejora de los procesos de desarrollo software, definir objetivos de calidad y desempeño en los procesos importantes de desarrollo del software. Logrando que las organizaciones de micro finanzas, mejoren la Eficiencia en la gestión de requerimientos de desarrollo de software. Con los cuales se lograra definir procedimiento estándares para compartir lecciones aprendidas, medir la demanda y priorizar la atención de requisitos, mejorar los criterios para identificar y gestionar los riesgos. Todo ello en conjunto permitir disminuir el fracaso de los proyectos, entrega del producto dentro presupuesto y tiempo y mejorar la satisfacción del usuario.
(Variable 1: Porcentaje de proyectos que finalizan en presupuesto según investigación en empresa Micro finanza, valor: 54%Variable 2: Porcentaje de proyectos que finalizan en plazo según investigación en empresa Micro finanza, valor: 50%Variable 3: Porcentaje de proyectos que finalizan en alcance según investigación en empresa Micro finanza, valor: 66%)
1.3.3. Objetivos Específicos
Mejorar procesos de requerimientos de desarrollo de software. Cumplir con los objetivos de proyectos de software Cumplir las necesidades del usuario final. Mejorar la satisfacción al conseguir que la User Experience (UX) sea
una buena experiencia, cuando el usuario interactué con el producto.
1.4. Justificación del Proyecto
1.4.1. Justificación Académica
Los proyectos de software muestran un alto porcentaje de fracasos, según el reporte “Resumen de Caos 2015” elaborado por The Grupo Standish International, consultora especializada en gestión de proyectos de software, indica que solo el 36% de los proyectos evaluados fueron exitosos, cumpliendo los objetivos del proyecto (Tiempo, Alcance, Coste).
Mientras que el 45% finalizaron con algún tipo de problema, no cumplieron los objetivos del proyecto (Tiempo, Alcance, Coste) y el 19% de los proyectos no finalizaron.
En el presente trabajo de investigación, tiene como objetivo proponer un modelo de gestión de requerimientos en el proceso de desarrollo de software.
1.4.2. Beneficios tangibles
Reducir el sobre coste en los proyectos a través de la mejora de procesos en el desarrollo de software.
Mejorar la productividad del equipo. Entregar valor a los clientes. Involucrarse en un proceso de mejoramiento continuo.
1.4.3. Beneficios Intangibles
Equipos de desarrollo de alto rendimiento. Construir equipos autosuficientes que planifiquen y documenten su
trabajo, estableciendo metas además de sus progresos y planificaciones.
1.5. Alcance del ProyectoEl presente modelo de gestión de requerimientos (REQM), propuesto, será aplicado al proceso de desarrollo de software de empresas del sector Micro Finanzas de la región Lima.
Estará asociado a la buena práctica de los procesos del nivel de madurez 2 y 3 del modelo CMMi Dev y experiencia usuaria (UX) que permitan que los proyectos cumplan los objetivos. Es decir finalicen en el plazo, costes y con todas la funcionalidad definidas por el usuario.
CAPÍTULO II: MARCO TEÓRICO
2.1. CMMI para Desarrollo
2.1.1. Según (Mukund Chaudhary & Abhishek Chopra) (ISBN: 978-0-13-427671-7)
El autor describe conceptos de que es CMMI, su evolución, cuando se puede utilizarse, quién lo puede utilizar, niveles de madurez, áreas de proceso.
2.1.1.1. ¿Qué es CMMI?
CMMI recopila información de los procesos y en base a ello, mejorar los procesos de una organización, es un modelo que nos dice que hacer. Su objetivo es facilitar a la organización a qué desarrolle productos o soluciones mejorando la gestión de desarrollo, adquisición y mantenimiento de los productos o servicios.
Actualmente se ocupa de tres áreas importantes:
Desarrollo de productos y servicios (CMMI DEV). Gestión de servicios (CMMI SVC). Adquisición de productos y servicios (CMMI ACQ).
Figura 2.1.1. Áreas de interés del CMMIFuentes: CMMI Institute
“El Capability Maturity Model Integración (CMMI), es un modelo de mejora de la capacidad que se puede adaptar para resolver cualquier problema de rendimiento en cualquier nivel de la organización e industria. El modelo proporciona directrices y recomendaciones para ayudar a su organización a diagnosticar problemas y mejorar el rendimiento.
Utilizado por más de 5.000 organizaciones en más de 70 países de todo el mundo, CMMI ayuda a identificar y alcanzar los objetivos de negocio medibles”. (CMMI Institute)
2.1.1.2. La evolución del CMMI
CMMI fue creado por el SEI (Software Engineering Institute) y patrocinado por el departamento de defensa los EE.UU. (Departamento de Defensa).
Capability Maturity Model (CMM) fue desarrollado sobre la base del estudio y los datos recopilado de diversas organizaciones que habían trabajado con el Departamento de Defensa de los Estados Unidos.
A petición de la Fuerza Aérea de Estados Unidos (USAF), Humphrey y SEI, crearon el marco de procesos de madurez para ayudar al departamento de defensa de Estados Unidos, evaluar la capacidad de los procesos de desarrollo de software de sus proveedores.
La representación completa de Capability Maturity Model (CMM) fue desarrollada en el año 1991 y actualizada en el año 1993 como la versión 1.1.
En el año 2000, el equipo de CMMI publicó el Modelo CMMI como método de capacitación y evaluación, que incorporaba software e ingeniería de sistemas.
La versión actual del modelo es CMMI V1.3, lanzado en el año 2010. La figura 2.1.3 representa su evolución.
Figura 2.1.3. La evolución del CMMIFuentes: Mukund Chaudhary/Abhishek Chopr, CMMI for
Development
2.1.1.3. ¿Por qué utilizar CMMI?
El objetivo principal de CMMI es mejorar el rendimiento de los estándares, procesos y procedimientos de la organización.
CMMI también es muy útil en organizaciones que desean mejorar su capacidad para entregar de manera consistente y previsible los productos, servicios y bienes que desean sus clientes. Por lo tanto, también ayuda a las organizaciones a alcanzar sus objetivos de rendimiento.
a. Desarrollo: Para mejorar el desarrollo de solucionesb. Adquisición: Para mejorar la compra de productos, servicios
y / o solucionesc. Servicios: Para mejorar la prestación de servicios y la
creación de sistemas de servicios para operar una solución
2.1.1.4. ¿Dónde se utilizar CMMI?
CMMI puede ser utilizado por cualquier organización, grande o pequeño, que quiere mejorar sus capacidades y el rendimiento.
En estos días, CMMI se utiliza en toda la organización y en campos tan diversos como la aviación y aeroespacial, las redes de computadoras, software, tecnología de la información, defensa y espacio, hospitalario y sanitario, la administración del gobierno, seguros, consultoría de gestión y otros.
Los resultados publicados por CMMI Institute muestran que el año 2015 se realizaron más de 1,900 evaluaciones en 61 países, lo que lo convierte en el cuarto año consecutivo para un número récord de evaluaciones. (ver figura 2.1.4).
Figura 2.1.4. El crecimiento de las evaluaciones de CMMIFuentes: Mukund Chaudhary/Abhishek Chopr, CMMI for
Development2.1.1.5. Niveles de CMMI
En CMMI, cada nivel describe la madurez del proceso. Cada nivel consta de áreas de proceso, los cuales se logran de manera progresiva.
La capacidad y la madurez están asociadas a los niveles de capacidad y madurez, respectivamente. Describen la trayectoria de mejora para iniciar la implantación del CMMI.
2.1.1.5.1. Niveles de capacidad
Un nivel de capacidad es una ruta que asegura que una organización mejorará un área de proceso individual o grupo de áreas de proceso de forma incremental.
Enfocarse en los detalles de un proceso, ayudará a la organización a mejorar su nivel de capacidad en esa área del proceso.
Existen cuatro niveles de capacidad (ver figura 2.1.5):
i. Nivel 0: Incompletoii. Nivel 1: Realizadoiii. Nivel 2: Gestionadoiv. Nivel 3: Definido
Figura 2.1.5. Niveles de capacidad CMMIFuentes: Mukund Chaudhary/Abhishek Chopr, CMMI for
Development
2.1.1.5.1. Niveles de madurez
Un nivel de madurez es una ruta que garantiza a las organizaciones mejorar sus áreas de procesos de manera incremental. Cada nivel de madurez tiene un conjunto de procesos que, de aplicarse juntos, le ayudarán a alcanzar un nivel de madurez completa (por ejemplo, pasar del nivel 1 al nivel 2).
Los cinco niveles de madurez progresan desde el nivel 1 al nivel 5 en etapas incrementales (ver la figura 2.1.6):
i. Nivel 1: Inicialii. Nivel 2: Gestionadoiii. Nivel 3: Definidoiv. Nivel 4: Cuantitativamente gestionadov. Nivel 5: Optimización
Figura 2.1.6. Niveles de madurez CMMIFuentes: Mukund Chaudhary/Abhishek Chopr, CMMI for
Development
2.2 Experiencia Usuaria (UX)
2.2.1. Según (Westley Knight) (ISBN: 978-1-4842-4227-8)
El autor describe qué es la experiencia del usuario, UX no es UI, UX no es usabilidad, UX no es solo parte del proceso, UX no es solo sobre el usuario
2.2.1.1. ¿Qué es experiencia del usuario?
La experiencia del usuario abarcar toda la experiencia que un individuo tiene, a través de todos y cada uno de los medios, en torno a un producto o servicio.
El concepto central de UX perdura; independientemente del tipo de producto digital con el que interactúe el usuario, ya sea un sitio web, una aplicación o cualquier otra pieza de software, UX todavía trata sobre la experiencia que una persona tiene con ese producto.
2.2.1.2. UX no es UI
El diseño de la interfaz de usuario (UI) no es el diseño de la experiencia del usuario (UX). Los profesionales de UX buscarán influenciar a otros sobre el alcance del diseño de UX que va mucho más allá de la disciplina del diseño de UI, mientras buscan evitar disminuir su importancia para la experiencia general del usuario.
La figura 2.2.1 muestra las disciplinas de diseño de la experiencia del usuario, según lo previsto por Dan Saffer.
Figura 2.2.1. Disciplinas de la experiencia del usuarioFuentes: Westley Knight, UX for
Development
De la figura 2.2.1, aunque esta no es una lista exhaustiva de todas las facetas que podrían considerarse parte del diseño de la experiencia del usuario (user experience design), a partir de esto puede ver cómo el diseño de la interfaz de usuario (User Interface Design) se encuentra dentro de la esfera más amplia del diseño de interacción (Interaction Design), que a su vez pertenece a la esfera del diseño de la experiencia del usuario (User Experience Design).
Dependiendo de la estructura o estrategia de la organización, cada una de estas disciplinas podría ser responsabilidad de individuos separados. Quizás cada una es una disciplina compartida entre varias personas, o puede haber un individuo que cubra múltiples, o tal vez incluso todas estas disciplinas.
Puede haber un equipo completo de personas que se especializan en cada una de estas disciplinas trabajando juntas, o puede haber una sola persona que cubra todos los aspectos del Diseño de experiencia del usuario: el legendario UX Unicorn.
Debemos ser conscientes de no restringir nuestra comprensión de la experiencia del usuario simplemente a la del diseño visual o la interfaz gráfica de usuario. Debemos ampliar nuestra comprensión de las conexiones físicas que tenemos con los productos que estamos utilizando; entrada a través de periféricos como el mouse y el teclado, interacciones físicas directas con pantallas táctiles y las respuestas físicas que recibimos de esas interacciones a través de retroalimentación háptica y kinestésica.
2.2.1.3. UX no es usabilidad
Es común que la usabilidad se considere como la experiencia del usuario, ya que el término se usa para describir lo que un usuario piensa y siente acerca de una interfaz; lo intuitivo que es, lo fácil que es usarlo, lo fácil que es aprender.
Una vez más, la usabilidad es solo una pequeña parte del conjunto de la experiencia del usuario. Cuando examinamos qué significa usabilidad, qué tan fácil es usar y aprender, se hace evidente que es un atributo de la interfaz de usuario.
A menudo se piensa que hacer qué, un producto sea utilizable crea una buena experiencia de usuario. Si bien la usabilidad es definitivamente un factor importante que contribuye a la experiencia del usuario, solo concentrarse en la usabilidad descuida otros aspectos de la experiencia.
El UX Honeycomb en la figura 2.2.2, ilustra las otras facetas que debemos tener en cuenta en una visión más integral de la experiencia del usuario.
Figura 2.2.2. El UX HoneycombFuentes: Westley Knight, UX for
Development
El UX Honeycomb fue creado por Peter Morville para ayudar a sus clientes a comprender que la experiencia del usuario era más que solo usabilidad. Cada faceta es representativa de una parte de la experiencia del usuario:
a. Útil (Useful): Si su producto no resuelve un problema o no satisface una necesidad que tiene su usuario, entonces la necesidad de ese producto se evapora rápidamente. Siempre debemos estar conscientes de nuestros usuarios y sus necesidades y comportamientos cambiantes para que nuestro trabajo siga siendo relevante y útil.
b. Utilizable (Usable): La facilidad de uso y la capacidad de aprendizaje son clave para retener a aquellos que ya usan su producto y, sin embargo, solo se relaciona con la interfaz de usuario. Aunque es importante, no abarca todas las consideraciones requeridas para un buen diseño de experiencia de usuario.
c. Deseable (Desirable): Aunque esto es bastante intangible, la importancia y el valor de los elementos de las conexiones emocionales con una marca, una identidad o un producto
pueden tener una influencia significativa en la experiencia general.
d. Localizable (Findable): Un usuario debe poder encontrar lo que necesita para poder hacer el trabajo.
e. Accesible (Accessible): Debemos esforzarnos para que las cosas que construimos estén disponibles para todos, independientemente de los impedimentos físicos o cognitivos.
f. Creíble (Credible): El producto debe ser confiable, debe permitir al usuario creer lo que le decimos.
g. Valioso (Valuable): El producto debe ofrecer valor, no solo para la satisfacción del usuario, también para los stakeholders y para el resultado final del negocio.
2.3 Requerimiento/Requisito
2.3.1. Según (Klauss Pohl and Chris Rupp) (ISBN: 978-1-937538-77-4)
El autor describe los conceptos de la ingeniería de requisito, tipo de requisito, procedimiento para realizar una documentación de requerimientos, técnicas para la obtención y validación de requisitos.
2.3.1.1. Ingeniería de requisitos
En la ingeniería de requisitos para que un proyecto de desarrollo de software logre éxito, es indispensable conocer los requisitos del sistema y deben ser documentados adecuadamente.
Es un enfoque sistemático para la especificación y gestión de los requisitos con los siguientes objetivos:
Conocer e identificar los requisitos relevantes y lograr un consenso entre los interesados.
Comprender, documentar las necesidades de los interesados, especificar y gestionar los requisitos para minimizar el riesgo de entregar un sistema que no cumpla con las necesidades de los interesados.
2.3.1.2. Requisito
Define como una condición o capacidad que necesita un usuario para lograr un objetivo o resolver un problema. El sistema o componente del sistema debe cumplir con la especificación definida para satisfacer y cumplir con el contrato.
Una restricción es un requisito que limita la solución para cumplir con los requisitos funcionales y requisitos de calidad
2.3.1.3. Tipos de requisitos
Los requisitos funcionales definen la funcionalidad del sistema a desarrollar.
Los requisitos de calidad definen las cualidades deseadas del sistema a desarrollar, incluye la arquitectura. Se clasifican como requisitos no funcionales (rendimiento, disponibilidad, fiabilidad, escalabilidad, portabilidad).
2.3.1.4. Categorización de requisitos según el modelo de Kano
Se debe tener en cuenta la importancia de conocer un requisito y las propiedades de un producto para la satisfacción de los Stakeholders.
La satisfacción se clasifica en tres categorías (según Kano, 1984):
i. Los Insatisfactores son propiedades del sistema que son evidentes (conocimiento subconsciente).
ii. Los Satisfactores son propiedades explícitamente demandadas del sistema (conocimiento consciente).
iii. Los Deleitadores son propiedades del sistema que los Stakeholders no conocen, lo descubre cuando usan el sistema (conocimiento inconsciente).
Figura 2.3.1 Representación Gráfica del modelo KanoFuentes: Klauss Pohl – Chris Rupp,
Requirements Engineering Fundamentals
a. Insatisfactores:Los insatisfactores son requisitos subconscientes que deben ser cumplidos por el sistema. En caso contrario habrá insatisfacción por parte de los Stakeholders. La observación y las técnicas centradas en documentos son adecuadas para cumplir los requisitos.
b. Satisfactores:Los satisfactores son requisitos conscientes, propiedades de los Stakeholders conocen conscientemente y demandan explícitamente.
Cuando se cumplen estas propiedades, los Stakeholders estarán contentos y satisfechos. Su satisfacción disminuye por cada requisito que no se cumpla.Los satisfactores se pueden obtener utilizando técnicas de encuestas.
c. DeleitadoresLos Deleitadores son requisitos conscientes, son propiedades de un sistema que son reconocidos cuando los Stakeholders pueden usar el sistema.Las técnicas de creatividad son las adecuadas para provocar deleites.
2.3.1.5. Importancia y categorización de los requisitos de calidad
Los requisitos de calidad de un sistema por lo general no son documentados y negociados de manera inadecuada, lo cual puede afectar el éxito del proyecto o la aceptación del sistema en desarrollo. Por lo tanto, el ingeniero de requisito debe poner énfasis en la documentación y negociación de los requisitos de calidad del sistema durante el proceso de desarrollo.
Para poder tratar los requisitos de calidad de forma estructurada, se tiene varios esquemas de clasificación para los requisitos de calidad. El estándar ISO/IEC 25010:2011, propone una estructura estándar de documentación de requisitos, una lista de verificación para la obtención y validación de requisitos:
i. Define el rendimiento del sistema, al comportamiento del tiempo de respuesta y la utilización de los recursos.
ii. Define la seguridad del sistema a los aspectos de autenticidad, confidencialidad e integridad.
iii. Define la confiabilidad de las funcionalidades a los aspectos de disponibilidad, tolerancia a fallas y capacidad de recuperación.
iv. Define la usabilidad del sistema a los aspectos de accesibilidad de aprendizaje y facilidad de uso.
v. Define capacidad de mantenimiento a la reutilización, capacidad de cambio y capacidad de prueba.
vi. Define portabilidad de un sistema a los aspectos de adaptabilidad, instalabilidad y reemplazabilidad.
Los requisitos de calidad deben mantenerse separados de los requisitos funcionales y deben documentarse por separado.
2.3.1.6. Obtención de requisitos
Una de las actividades importantes de la ingeniería de requisitos es la obtención de requisitos para el sistema a desarrollar. La base para obtención de requisitos es el conocimiento.
Existen tres tipos de fuente de requisitos:
a. Los Stakeholders son personas u organizaciones que directa o indirectamente influyen en los requisitos de un sistema.
b. Los documentos contienen información importante que proporciona requisitos.
c. Los sistemas en operación pueden ser sistemas heredados o predecesores.
2.3.1.7. Técnicas Obtención de requisitos
El objetivo de todas las técnicas de obtención es apoyar al ingeniero de requisitos en la generación de los requisitos de los Stakeholders.
Permite adaptar el proceso de obtención de requisitos para que puedan obtenerse de manera completa y comprensible posible.
2.3.1.7.1. Tipos de técnicas de obtención
Las técnicas de obtención sirven para identificar los requisitos conscientes, inconscientes y subconscientes de los Stakeholders. Cada proyecto tiene restricciones y características únicas, estas técnicas son:
i. Técnicas de encuestaii. Técnicas de creatividadiii. Técnicas centradas en documentosiv. Técnicas de observaciónv. Técnicas de soporte
Para seleccionar una adecuada técnica de obtención, se debe realizar un análisis de las restricciones del proyecto, identificar los factores de riesgo
Los factores de influencia para elegir las técnicas de obtención son las siguientes:
a. La diferencia entre requisitos conscientes, inconscientes y subconscientes que se deben obtener.
b. Las limitaciones de tiempo y presupuesto y la disponibilidad de los Stakeholders.
c. La experiencia del ingeniero de requisitos y la aplicación de una técnica de obtención para determinar los posibles cambios y riesgos del proyecto.
2.3.2. Según (Karl Wiegers and Joy Beatty) (ISBN: 978-0-7356-7966-5)
El autor describe los requisitos de software, requisitos desde la perspectiva del cliente, las buenas prácticas para la ingeniera de requisitos, obtención, validación y herramientas para la gestión de requisitos.
2.3.2.1. Ingeniería de requisitos
Muchos de problemas en el mundo del software tienen origen en las deficiencias de cómo las personas aprenden, documentan, acuerdan y modifican los requisitos del producto.
Las áreas problemáticas es la recopilación informar de información, los requisitos más especificados.
Varios estudios indican que los errores introducidos durante las actividades de requisitos, generan el 40% a 50% de los defectos encontrados en un producto de software (Davis 2005). La aportación inadecuada del usuario y las deficiencias en las especificaciones y gestión de los requisitos del cliente, conllevan que los proyectos no tengan éxito.
Los requisitos son especificaciones de lo que se debe implementar, son descripciones de cómo debe comportarse el sistema, una propiedad o atributo del sistema. Pueden ser limitaciones en el proceso de desarrollo del sistema.
2.3.2.2. Niveles y tipo de requerimientos
Algunos tipos de información de requisitos:
i.Requisito de negocio.- Objetivo comercial de alto nivel de la organización que construye un producto.
ii. Reglas de negocio.- Políticas, normas o regulación que define o restringe algún aspecto del negocio
iii.Restricción.- Restricción para el desarrollador en las opciones del diseño y construcción del producto.
iv.Requisito de interfaz externa.- Descripción de una conexión entre un sistema de software y un usuario, otro sistema de software o un dispositivo de hardware.
v. Característica.- Una o más capacidades del sistema que proporcionan valor a un usuario, descritas en los requisitos funcionales.
vi.Requerimiento funcional.- Descripción del comportamiento del sistema, bajo condiciones específicas.
vii. Requisito no funcional.- Descripción de una propiedad o característica del sistema.
viii.Atributo de calidad.- Tipo de requisito no funcional que describe un servicio o característica de rendimiento de un producto.
ix.Requisitos del sistema.- Requisito de nivel superior para un producto que contiene múltiples subsistemas.
x. Requisitos de usuario.- Especificación de usuario que debe realizar el sistema o un atributo de producto deseado
Los requisitos de software incluyen tres niveles distintos: requisitos comerciales, requisitos de usuario y requisitos funcionales. Además de los requisitos no funcionales.
El modelo de la Figura 2.3.1 ilustra una forma de pensar sobre estos diversos tipos de requisitos.
Los óvalos en la Figura 2.3.1 representan tipos de información de requisitos, y los rectángulos indican documentos en los que se
almacena la información. Las flechas continuas indican que un cierto tipo de información generalmente se almacena en el documento indicado (Las reglas comerciales y los requisitos del sistema se almacenan por separado de los requisitos de software, como en un catálogo de reglas comerciales o una especificación de requisitos del sistema).
Las flechas punteadas indican que un tipo de información es el origen o influye en otro tipo de requisito.
Figura 2.3.1 Relaciones entre varios tipos de información de requisitos
Fuentes: Karl Wiegers and Joy Beatty, Software_Requirements_3_3rd_Edition
La Figura 2.3.1, se ilustra un árbol de características, un modelo de análisis que muestra cómo una característica puede descomponerse jerárquicamente en un conjunto de características más pequeñas, que se relacionan con los requisitos específicos del usuario y conducen a la especificación de conjuntos de requisitos funcionales (Beatty y Chen 2012).
Figura 2.3.1 Relaciones entre características, requisitos del usuario y requisitos funcionales.
Fuentes: Karl Wiegers and Joy Beatty, Software_Requirements_3_3rd_Edition
2.3.2.3. Buenas prácticas para la ingeniería de requisitos
El desarrollo de requisitos implica obtención, análisis, especificación y validación. Sin embargo, no espere realizar estas actividades en una secuencia lineal simple de una pasada. En la práctica, estas actividades son entrelazadas, incrementales e iterativas, como se muestra en la Figura 2.3.4
Figura 2.3.4 El desarrollo de requisitos es un proceso iterativoFuentes: Karl Wiegers and Joy Beatty, Software_Requirements_3_3rd_Edition
2.3.2.4. Buenas prácticas: obtención de requisitos
Las siguientes son algunas prácticas que pueden ayudar a obtener la gran cantidad de información sobre requisitos:
a. Defina la visión del producto y el alcance del proyecto: El documento de visión y alcance contiene los requisitos comerciales del producto. La declaración de visión brinda a todos los stakeholders una comprensión común del resultado del producto. La visión debe permanecer relativamente estable durante el proyecto, pero cada iteración planificada necesita su propia declaración de alcance.
b. Identifique las clases de usuarios y sus características:Para evitar pasar por alto las necesidades de cualquier comunidad de usuarios, identifique los distintos grupos de usuarios para su producto. Pueden diferir en la frecuencia de uso, las características utilizadas, los niveles de privilegio o la experiencia.
c. Seleccione un defensor del producto para cada clase de usuario Identifique a una persona que pueda servir con precisión como la voz literal del cliente para cada clase de usuario. El defensor del producto presenta las necesidades de la clase de usuario y toma decisiones en su nombre.
d. Realice grupos focales con usuarios típicos: Convocar a grupos de usuarios representativos de productos anteriores o similares. Recopile sus comentarios sobre las características de funcionalidad y calidad para el producto en desarrollo.
e. Trabajar con representantes de usuarios para identificar los requisitos de los usuarios
Explore con sus representantes de usuario las tareas que necesitan realizar con el software y el valor que intentan lograr. Los requisitos del usuario pueden expresarse en forma de casos de uso, historias de usuarios o escenarios.
f. Trabajar con representantes de usuarios para identificar los requisitos de los usuariosExplore con sus representantes de usuario las tareas que necesitan realizar con el software y el valor que intenta lograr. Los requisitos del usuario pueden expresarse en forma de casos de uso, historias de usuarios o situaciones.
g. Identificar eventos y respuestas del sistemaEnumere los eventos externos que el sistema puede experimentar y su respuesta esperada a cada evento. Los eventos de señal son señales de control o datos recibidos de dispositivos de hardware externos. Los eventos temporales o basados en el tiempo desencadenan una respuesta. Los eventos empresariales desencadenan casos de uso en aplicaciones empresariales.
h. Realizar entrevistas de obtención EntrevistasPuede realizarse individualmente o mediante un grupo, forma efectiva de obtener requisitos sin tomar demasiado tiempo de los stakeholder, reúne personas (entrevistas) para discutir solo los requisitos específicos que son importantes para ellos.
i. Organice talleres de obtención facilitadosLos talleres facilitan la obtención de requisitos, permiten la colaboración entre analistas y clientes, es una forma para explorar las necesidades de los usuarios y redactar documentos de requisitos (Gottesdiener 2002).
j. Observe a los usuarios que realizan sus trabajosObservar a los usuarios realizar sus tareas diarias y elaborar diagramas de flujo de procesos simples, que representen los pasos, las decisiones y mostrar cómo interactúan los diferentes grupos de usuarios. Documentar el flujo del proceso de negocio lo ayudará a identificar los requisitos.
k. Distribuir cuestionariosLos cuestionarios son una forma de encuestar a los usuarios para determinar qué necesitan. Si las preguntas están bien escritas, los cuestionarios pueden ayudarlo a determinar rápidamente la información analítica sobre las necesidades.
l. Realizar análisis de documentosLa documentación ayuda a revelar cómo funcionan actualmente los sistemas, identificar la funcionalidad que debe permanecer, la funcionalidad que no se usa, cómo las personas hacen su trabajo actualmente. La documentación incluye cualquier información escrita sobre los sistemas actuales, procesos comerciales, especificaciones de requisitos, investigación de la competencia y manuales de usuario.
m. Examine los informes de problemas de los sistemas actuales para ideas de requisitosLos informes de problemas y las solicitudes de mejora de los usuarios proporcionan una fuente de ideas para incluir en una versión posterior o en un nuevo producto.
n. Reutilice los requisitos existentesSi los clientes solicitan una funcionalidad similar a la presente en un producto existente, verifique si los requisitos (y los clientes) son flexibles para permitir la reutilización o la adaptación de los componentes de software existentes.
CAPÍTULO III: ESTADO DEL ARTE
3.1 Artículos
3.1.1. Un modelo de gestión de requerimientos para minimizar el porcentaje de incumplimiento (Victor Alfaro, ISBN: 1994-7224)
En el presente artículo plantea un modelo de gestión de requerimientos para minimizar el porcentaje de incumplimiento, el problema que identifica en la presente artículo de investigación es la re-planificación de los requerimientos en la fase de Planificación de desarrollo de software, como consecuencia se produce un alto índice de re-planificaciones.
Se realiza una crítica a la falta de artefactos que garanticen la viabilidad del proyecto desde la fase de Planificación. Como propuesta en su investigación se presentan filtros, entregables en cada etapa de Planificación, de tal manera que se garanticen la calidad de reuniones, entendimiento, checklists.
a). Referentes Teóricos
El autor del artículo hace referencia a los marcos teóricos:
i. Metodología en CascadaTambién llamado modelo en cascada, es un enfoque metodológico que ordena rigurosamente las etapas en el proceso de desarrollo de software.El inicio de cada etapa debe esperar a la finalización de la etapa anterior (Ian Sommerville, 1997).Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida, metodología de desarrollo en cascada es:
Análisis de requisitos. Diseño del Sistema. Diseño del Programa. Codificación. Pruebas. Verificación. Mantenimiento.
ii. Norma Técnica Peruana ISO 12207: 2008
La norma menciona principalmente el proceso de Adquisición donde conviene que los requisitos del sistema incluyan requisitos de negocio, organizativos, de usuario, así como de seguridad física y de acceso y otros requisitos críticos.
B). Metodología
El modelo propuesto por autor, propone que en las dos primeras etapas que son Requerimientos y Diseño, son las fases que contempla el artículo de la investigación en cuanto a su alcance. Siendo la etapas donde se presenta los requerimientos y el diseño de la solución.
