Concepto: Ingeniería de utilización
En esta directriz se trata la ingeniería de utilización. La ingeniería de utilización (también denominada Diseño centrado en el usuario) se centra en la creación de mejores sistemas mediante una mejor comprensión de los usuarios finales y la implicación de los usuarios en los requisitos, el diseño de la interfaz de usuario y los esfuerzos de prueba.
Descripción principal
Conceptos: 

Introducción

La ingeniería de utilización (también denominada Diseño centrado en el usuario) se centra en la creación de mejores sistemas mediante una mejor comprensión de los usuarios y la implicación de los usuarios en los requisitos, el diseño de la interfaz de usuario y los esfuerzos de prueba. Los conceptos básicos se describen en el Concepto: Diseño centrado en el usuario y debe leerse antes que este concepto. En esta página de concepto se explica cómo Rational Unified Process (RUP) aborda actualmente las técnicas de ingeniería de utilización.

Roles

RUP tiene varios roles que son responsables de las cuestiones de utilización. El analista de sistemas y el especificador de requisitos deben tener experiencia en la reunión y el análisis de información sobre los usuarios, sus tareas y su entorno, y en cómo capturar todo ello en los requisitos. El material lo revisa el revisor de requisitos. Los roles de verificador y de analista de pruebas son los principales responsables de la utilización de las pruebas. El diseñador de interfaz de usuario es responsable del diseño y del "modelado visual" de la interfaz de usuario. El implementador selecciona o desarrolla los componentes de la interfaz de usuario para construir la interfaz de usuario que funciona.

El gestor de proyectos tiene también un rol clave. Debe habilitar a los usuarios para que se impliquen en el proceso de desarrollo y debe garantizar que la empresa de desarrollo cuenta con un personal adecuadamente preparado para satisfacer los requisitos de experiencia y capaz de crear sistemas que funcionen. Otros roles, como gestor de despliegue, desarrollador de cursos y escritor técnico tienen también responsabilidades a la hora de garantizar que el sistema de despliegue es utilizable.

Disciplinas

En las secciones siguientes se describen las disciplinas de RUP en términos de las actividades y artefactos que son de más importancia de cara a la utilización.

Requisitos

Desde la perspectiva de la utilización, la disciplina de requisitos se centra en:

  • establecer unas bases claras de los usuarios y de sus necesidades
  • identificar los guiones de uso que son más beneficiosos para los usuarios.

Las actividades y artefactos específicos son como se indica a continuación.

Actividad Artefacto Contenido relacionado con la utilización
Obtener las solicitudes del interesado Solicitudes del interesado

Esta actividad implica entrevistar a los usuarios, realizar cuestionarios y celebrar talleres para comprender mejor al usuario y al entorno del usuario. Esto incluye lo siguiente:

La plantilla de Artefacto: Solicitud del interesado captura un perfil detallado del usuario, incluida la formación académica, la formación en informática, la experiencia, el entorno existente, las expectativas, los objetivos, etc. Asimismo captura una Descripción de los problemas y las prioridades desde la perspectiva del usuario. Las solicitudes del interesado son la materia prima a partir de la que se compila la visión.

Desarrollar la visión Visión

En la sección del entorno de usuario de la plantilla de visión se describe el entorno de trabajo de los usuarios, o lo que ISO denomina el contexto de entorno [ISO 13407].

En la sección de perfil de usuario de la plantilla visión se describe la especialidad del usuario, sus conocimientos técnicos, sus responsabilidades, sus criterios de éxito, sus entregables, etc. ISO lo denomina contexto de usuario [ISO 13407].

Buscar actores y guiones de uso, Estructurar el modelo de guión de uso, Detallar un guión de uso modelo de guión de uso

En el modelo de guión de uso se describen las tareas (guiones de uso) que llevan a cabo los usuarios (actores humanos). Captura las similitudes y las relaciones entre los actores, mediante las relaciones de generalización. Los actores se relacionan con los guiones de uso mediante ello. Esto es similar al "Role Model" de Constantine [CON99]. Los guiones de uso están estructurados y relacionados entre sí y con los actores mediante las relaciones asociación-comunicar, inclusión, generalización y ampliación.

Los talleres son una forma excelente de implicar al usuario. Véase: Taller de guión de uso

 

Actores

Las características de los actores humanos se capturan como atributos de los actores. Son los siguientes:

  • El ámbito de responsabilidad del actor.
  • El entorno físico en qué el actor utilizará el sistema.
  • El número de usuarios representados por este actor.
  • La frecuencia con que el actor utilizará el sistema.
  • El nivel de conocimiento de dominio del actor.
  • El nivel de experiencia informática general del actor.
  • Las características generales de los actores, como el nivel de experiencia (formación), las implicaciones sociales (idioma) y la edad.
 

Guiones de uso

Pueden incluir guiones de uso esenciales como describe Constantine [CON99] (consulte Concepto: Diseño centrado en el usuario donde encontrará una discusión sobre los guiones de uso esenciales). Los requisitos de utilización específicos para un uso determinado pueden capturarse como "requisitos especiales" en la especificación del guión de uso.
Detallar los requisitos de software

Especificaciones suplementarias

Las especificaciones adicionales capturan requisitos que no están especificados en los guiones de uso. Esto incluye los requisitos de disponibilidad y de rendimiento que pueden estar muy relacionados con la utilización. Los requisitos de utilización general que son aplicables a varios guiones de uso se capturan aquí, junto a la legislación y los estándares de utilización aplicables (consulte Concepto: Diseño centrado en el usuario si desea información detallada sobre la legislación sobre utilización y estándares.
Gestionar las dependencias Atributos de requisitos A medida que los guiones de uso y los requisitos de utilización se van "descubriendo", deben empezar a notarse su importancia o las ventajas de utilizarlos. Esto precisa consultar a los usuarios y a otros interesados. Otros atributos, como la frecuencia con la que se ejecuta un guión de uso, también pueden capturase en este artefacto.
Revisar los requisitos Solicitud de cambio Un esfuerzo de desarrollo centrado en el usuario implica tanto como sea posible a los usuarios en todas las revisiones de requisitos.
Crear un vocabulario común Glosario Capture términos de vocabulario comunes que son específicos del dominio de los usuarios para facilitar la comunicación y la comprensión entre los usuarios y el resto del equipo de desarrollo.

Hay otras técnicas que pueden ser adiciones útiles para las actividades de requisitos descritas anteriormente.

  • Los diagramas de afinidad "Affinity Diagramming" [HOL96, BEY98] son una técnica en la que cada dato reunido acerca de los usuarios y sus tareas se coloca en una nota adhesiva. Los usuarios y los analistas colaboran para agrupar las notas relacionadas en grupos conceptuales o "afinidades". Esta actividad ayuda a promocionar una comprensión compartida de las cuestiones, de su importancia relativa y de sus relaciones.
  • La clasificación de tarjetas (Card Sorting) [CON99] es una actividad similar en la que la información de las tarjetas de índice se organiza en grupos. Las tarjetas también pueden clasificarse por importancia, frecuencia, etc.
  • El modelado jerárquico de tareas (Hierarchical Task Modeling) [MAY99, CON99] analiza las tareas que realizan los usuarios actualmente y las organiza en una jerarquía. La jerarquía debe reflejar cómo comprenden actualmente los usuarios la organización de sus tareas.

Análisis y diseño

Algunas otras actividades de esta disciplina se centran en el modelado y el diseño de la interfaz de usuario. Son las siguientes:

Actividad

Artefacto

Contenido relacionado con la utilización

Diseñar la interfaz de usuario

Guión gráfico

Mapa de navegación

Esta actividad crea lo que suele denominarse el diseño conceptual [FER01]. Es la abstracción inicial de la propia interfaz de usuario, que captura las ventanas principales y las vías de acceso de navegación que se presentan al usuario. Esta actividad se centra en los guiones de uso que dirigen el diseño de la interfaz de usuario.

Los mapas de navegación (Navigation Maps), como se explica en [CON99] proporcionan una visión general de las vías de navegación que hay entre los espacios de interacción (pantallas, ventanas y recuadros de diálogo).

Crear el prototipo de la interfaz de usuario Prototipo de interfaz de usuario

Puede crear tres tipos básicos de prototipos:

Dibujos (en papel)
Mapas de bits (mediante una herramienta de dibujo)
Ejecutables (interactivos)
En la mayoría de proyectos, debe utilizar los tres tipos de prototipo, en el orden que se ha listado anteriormente.

El objetivo principal de la creación de un prototipo de interfaz de usuario es poder exponer y probar la funcionalidad y la utilización del sistema antes de que empiecen el diseño y el desarrollo reales. De este modo, puede garantizar que está construyendo el sistema correcto, antes de dedicar demasiado tiempo y recursos al desarrollo.


Las técnicas siguientes también pueden ser útiles como parte del diseño de la interfaz de usuario:

  • La clasificación de tarjetas (Card Sorting) [CON99], descrita anteriormente, es también útil para diseñar la interfaz de usuario. Cada elemento del menú o del contenido se representa mediante una tarjeta y, a continuación, los usuarios organizan las tarjetas en grupos lógicos.

Además de las actividades descritas anteriormente, las siguientes actividades de análisis y diseño son complementarias al diseño de la interfaz de usuario:

Actividad

Artefacto

Contenido relacionado con la utilización

Análisis de guiones de uso Clase de análisis,
Ejecución de guiones de uso

Consulte también lo siguiente:

Diseño de clase

Esta actividad utiliza los resultados del diseño y del prototipo de la interfaz de usuario y diseña las clases. A diferencia de los prototipos, este no es un trabajo desechable de interfaz de usuario conceptual, sino que intenta representar el diseño del sistema entregado.

Consulte también las siguientes directrices:

Directriz: Creación de aplicaciones web con el UML


Implementación

La implementación de la interfaz de usuario sigue el flujo general de trabajo de implementación. Tenga en cuenta que la implementación de la interfaz de usuario suele hacerse como parte de la actividad de diseño.

Prueba

Pruebas de utilización, incluidas las pruebas de rendimiento relacionadas con la utilización, deben iniciarse tan pronto haya maquetas o prototipos ejecutables de la interfaz de usuario. Las pruebas deben incluir la verificación de los requisitos de utilización y rendimiento capturados en las especificaciones suplementarias o en los "requisitos especiales" del guión de uso.

Despliegue

Los usuarios deben estar muy implicados en la Actividad: Producto de prueba de versión beta, así como en la prueba de utilización final durante la Actividad: Gestionar la prueba de aceptación.

La Actividad: Desarrollar materiales de soporte incluye el desarrollo de materiales de formación y materiales de soporte para el sistema con el fin de garantizar que los usuarios pueden utilizar satisfactoriamente el producto de software que se ha entregado.

Gestión de proyectos

La gestión de proyectos es el arte de equilibrar los objetivos competitivos, gestionar los riesgos y superar las restricciones para entregar con éxito un producto que cumpla las necesidades tanto de los clientes (los que pagan la factura) como de los usuarios. Desde la perspectiva de la ingeniería de utilización, la actividad más importante es la Tarea: Definir la organización y el personal del proyecto. Esta actividad define la estructura empresarial, las interfaces externas y los roles y responsabilidades. Esto incluye la definición de la extensión de la implicación de los usuarios en el proceso de desarrollo y determina si los desarrolladores deben tener experiencia con los métodos de ingeniería de utilización.

Entorno

La Disciplina de entorno incluye la definición del proceso de desarrollo que debe seguir un proceso o una empresa. La Tarea: Desarrollar el guión de desarrollo (el Producto de trabajo: Guión de desarrollo) define las técnicas de ingeniería de utilización que se van a aplicar, y cómo los distintos artefactos de RUP y las actividades se van a personalizar para incorporar estas técnicas.

Otra actividad importante es la Tarea: Desarrollar directrices específicas del proyecto, que crea el Producto de trabajo: Directrices del proyecto, que incluye las directrices para la interfaz de usuario. Estas directrices le ayudan a garantizar la coherencia de la interfaz de usuario, que resulta de gran ayuda para la utilización. También capturan los principios de utilización que deben utilizarse, como las directrices para los métodos abreviados, "deshacer" funciones, salidas reconocibles, interacción sin modalidad, etc.

Desarrollo iterativo y fases

El ciclo vital del software de RUP se descompone en cuatro fases secuenciales, cada una concluida por uno de los objetivos principales; cada fase es esencialmente un periodo de tiempo entre dos objetivos importantes. Al final de cada fase se lleva a cabo una valoración (Tarea: Revisión de los objetivos del ciclo vital) para determinar si los objetivos de la fase se han alcanzado. Una valoración satisfactoria permite que el proyecto continúe a la fase siguiente.

En cada fase puede haber varias iteraciones. Una iteración es un bucle de desarrollo completo que tiene como resultado un release (interno o externo) de un producto ejecutable, un subconjunto del producto final que se desarrolla, que tiene una evolución creciente de una iteración a otra hasta que llega a ser el sistema final. La utilización se beneficia en gran medida de este enfoque iterativo. Permite a los usuarios proporcionar una información temprana de retorno sobre la utilización y evita que se avance demasiado en una dirección que no vaya a satisfacer las necesidades del usuario.

El usuario debe implicarse en cada iteración, para seguir perfeccionando los requisitos, para evaluar los conceptos de diseño y probar y evaluar la utilización de los prototipos de prueba de concepto así como del sistema que se está desarrollando.

En las secciones siguientes se describen los criterios de finalización de las fases relacionadas con la utilización y las principales actividades para cada fase.

Principio

Dos de los objetivos principales de la Fase inicial son Inicio :

  • Establecer el ámbito de software y las condiciones de los límites del proyecto, incluidas una visión operativa, criterios de aceptación y lo que debe contener el producto y lo que no.
  • Discriminar los guiones de uso más importantes del sistema, los principales casos de ejemplo de las operaciones de los que dependerán las principales concesiones del diseño.

Desde la perspectiva de la ingeniería de utilización, esto significa enfatizar las actividades relacionadas con los requisitos y el modelado empresarial (si se ha realizado):

  • establecer unas bases claras de los usuarios y de sus necesidades
  • identificar los guiones de uso que son más beneficiosos para los usuarios.

La Fase inicial también suele ser el momento de explorar un poco el diseño de conceptos y los prototipos de "prueba de concepto". Esto es particularmente cierto cuando los principales riesgos del proyecto están relacionados con la interfaz de usuario y los problemas de utilización. La prueba de utilización, incluida la prueba de rendimiento relacionada con la utilización, debe iniciarse tan pronto como haya maquetas o prototipos ejecutables de la interfaz de usuario.

Elaboración

Como RUP es un proceso iterativo, los artefactos creados en la fase inicial se repasan y revisan con los usuarios para gestionar el ámbito y garantizar que la evolución que se está desarrollando satisface las necesidades del usuario.

En la elaboración, la atención se centra en la arquitectura de software, incluida la arquitectura de la interfaz de usuario. Se define la interfaz de usuario conceptual y se implementan los elementos críticos o arriesgados del diseño de la interfaz de usuario. Las actividades relacionadas con la arquitectura de software son en general aplicables a la interfaz de usuario, hay que evaluar productos estándar, considerar las reutilizaciones, seleccionar los mecanismos y patrones, etc.

Esta fase enfatiza las actividades de diseño de la interfaz de usuario y da soporte a las actividades de la disciplina de análisis y diseño. También están implicados la implementación y las pruebas, puesto que la finalización de la elaboración precisa que se construya un sistema ejecutable que pueda evaluarse.

Las pruebas de utilización y las pruebas de rendimiento que están relacionadas con la utilización, deben centrarse en los requisitos de riesgo que se han capturado en las especificaciones suplementarias o en los "requisitos especiales" del caso de uso.

Construcción

En la construcción, la atención se centra en la implementación de más guiones de uso. Esto implica añadir más elementos a la interfaz de usuario, a la vez que se permanece fiel al modelo conceptual de la interfaz de usuario y a las directrices de la interfaz de usuario que se han capturado en las directrices específicas del proyecto. Las pruebas de utilización siguen siendo muy importantes a medida que se añaden nuevas funciones.

La selección de las funciones que colocar en cada iteración se basa en el valor que tienen para los usuarios.

Transición

El aspecto principal de la fase de transición empieza a cambiar hacia la disciplina de despliegue. En un esfuerzo de desarrollo centrado en el usuario, no se debe esperar hasta la fase de transición para implicar al usuario. Sin embargo, el usuario sigue implicado, fundamentalmente para proporcionar información de retorno. Cuando un usuario ha estado implicado a lo largo de todo el desarrollo, las pruebas de versión beta y de aceptación suelen minimizarse significativa o no hacerse. Por el contrario, se genera información detallada de retorno y aprobación durante todo el esfuerzo de desarrollo.

El desarrollo del material de formación y el material de soporte del sistema finaliza con la transición, pero deberá reiniciarse en fases anteriores, si es posible, para permitir la información de retorno de los usuarios.

En la transición, hay un sistema en funcionamiento que pueden utilizar los usuarios. Es una buena idea planificar al menos un par de iteraciones durante la transición, para que los problemas con el release inicial se puedan corregir, de forma que pueda incorporarse la información de retorno de los usuarios.