Conceptos:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
|