Módulo 2 Captura y Modelado de Requerimientos.
3.1- Captura de requisitos, objetivo de la captura de requisitos Conceptos Básicos: Requerimiento: Un requerimiento es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del mismo.
Analizar requerimientos es mucho más que dejar escrito meramente lo que quieren los clientes. Es difícil saber exactamente lo que el sistema debe hacer. Los requerimientos son características que deben incluirse en un nuevo sistema considerando: •
•
•
descripciones de servicios o de aquello que el sistema es capaz de hacer, restricciones que el sistema deba considerar, contemplando las necesidades o condiciones establecidas por el usuario, los problemas observados y las mejoras posibles en relación al sistema actual.
Propósitos de los Requerimientos: 1. Permiten que los desarrolladores expliquen cómo han entendido lo que el cliente pretende del sistema. 2. Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante.
1
3. Indican al equipo de pruebas qué demostraciones llevar a cabo para convencer al cliente que el sistema que se le entrega es lo que había ordenado.
Características de los Requerimientos: Como plantea Shari Pleeger en su libro “Ingeniería de Software” (ver bibliografía), para asegurar que los desarrolladores y los clientes comprendan y utilicen correctamente los requerimientos es importante que estos últimos sean de alta calidad. Con este objetivo debe comprobarse que los requerimientos posean las siguientes características: • Correcto: Tanto los clientes como los desarrolladores deben revisar los
requerimientos definidos para asegurarse que no contengan errores. • Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento. Por ejemplo si un requerimiento dice que ‐ “Habrá un máximo de 10 puestos de trabajo simultáneos” y otro requerimiento expresa que ‐ “Para procesar los pagos en fecha de vencimiento se podrá trabajar con 12 puestos simultáneos”, estos requerimientos son inconsistentes. • Completo: Un requerimiento está completo si no necesita ampliar
detalles en su redacción para su comprensión. Un conjunto de requerimientos es completo si todos los estados posibles, cambios de estado, entradas, productos y restricciones están descriptos en alguno de los requerimientos. • Realista: Debe comprobarse que el sistema pueda hacer lo que el cliente
está pidiendo. A veces, cuando el tiempo de desarrollo es largo, el cliente intenta anticiparse a las mejoras en tecnologías disponibles e impone requerimientos sobre el estado del arte. Todos los requerimientos deben ser revisados para asegurar que son posibles. • Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir. En ocasiones, un requerimiento restringe innecesariamente a los desarrolladores o incluye funciones que no están directamente relacionadas con el problema que se está tratando. • Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de distintos métodos de verificación. Debemos poder preparar pruebas que demuestren que se han cumplimentado los requerimientos.
2
• Rastreable: Debe ser posible rastrear cada función del sistema hasta el
conjunto de requerimientos que la establece.
Tipos de Requerimientos: Una clasificación típica de los requerimientos de un sistema de software es la siguiente: 1. Requerimientos Funcionales 2. Requerimientos No Funcionales
1. Requerimientos Funcionales
Definen las funciones que el sistema será capaz de realizar y describen cómo debe comportarse el sistema ante determinado estímulo. Describen la funcionalidad o los servicios que se espera que el sistema provea, detallando las transformaciones que el sistema realiza sobre las entradas para producir salidas. Ejemplos: a) Para un Sistema de Procesamiento de Transacciones El sistema deberá: – Registrar los pedidos de los clientes. – Administrar datos de los clientes. – Generar facturas de venta. – Emitir Reportes de Ventas en un rango de fecha dado. – Administrar datos de los productos que se comercializan y su stock actual. – Registrar movimientos de stock de cada producto.
3
b) Para un Sistema de un Videojuego: ( Basado Basado en el ejemplo desarrollado en libro “Ingeniería de Software, una perspectiva orientada a Objetos” de Eric Braude, 2003). El sistema deberá: – Generar dos tipos de personajes: los que están bajo el control del jugador y personajes “extraños” bajo el control de la aplicación. – Permitir al jugador al jugador definir un personaje principal. – Mantener cualidades para cada personaje: fuerza, velocidad, paciencia. – Mantener un valor para cada cualidad de cada personaje. – Permitir que los personajes puedan “interactuar” cuando están en la misma área.
2. Requerimientos No Funcionales:
Son restricciones de los servicios o funciones sobre el sistema que limita la elección de alternativas en la etapa de diseño y construcción del sistema. Los requerimientos no funcionales son características que de una u otra forma pueden limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, entre otras. Ejemplos: a) Para un Sistema de Procesamiento de Transacciones El sistema deberá: – Operar en un entorno de red. – Definir distintos niveles de usuario y asignar permisos de acceso según el nivel de los mismos. – Almacenar los datos en una base de datos Relacional. b) Para un Sistema de un Videojuego: 1 El sistema deberá:
4
– Operar en una computadora con sistema operativo Windows 98 o superior. – Operar en un equipo con un mínimo de 512 Kb de memoria. – El lenguaje de implementación deberá ser JAVA.
Clasificación de Requerimientos No Funcionales La figura que se muestra a continuación contiene una clasificación de los requerimientos no funcionales presentada por Ian Sommerville (2002) en su libro “Ingeniería de Software” (ver bibliografía).
Fuente: Libro “Ingeniería de Software” – Ian Sommerville (2002), Pág. 102
Comentamos a continuación las características generales de los principales tipos de requerimientos no funcionales:
5
•
Requerimientos del Producto:
Estos requerimientos especifican el comportamiento del producto, como por ejemplo: ‐ Requerimientos de desempeño en la rapidez de ejecución. Por ejemplo: ‐ “La consulta de disponibilidad de habitaciones deberá realizarse en un tiempo menor de 20 segundos” ‐ Requerimientos de tamaño de memoria requerida, tamaño en disco necesario ‐ Requerimientos de fiabilidad que fijan la tasa de fallas para que el sistema sea considerado aceptable. ‐ Requerimientos de portabilidad, como por ejemplo: ‐ “La aplicación deberá poder accederse desde navegadores Web Internet Explorer 6.0 o superiores, y navegadores Mozilla Firefox a partir de la versión 4.0”
•
Requerimientos organizacionales:
Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos ejemplos son: ‐ Estándares en los procesos que deben utilizarse. ‐ Requerimientos de implementación como el lenguaje de programación o el método de diseño a utilizar. Por ejemplo: ‐ “El motor de base de datos a utilizar deberá ser SQL Server 2008, que es el utilizado para los otros aplicativos de la organización” ‐ Requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.
•
Requerimientos externos:
Este apartado cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Éstos incluyen: ‐ Requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con otros sistemas. Por ejemplo: ‐ “Se deberá generar un archivo con la información de las acreditaciones de sueldos respetando el formato establecido por el Banco Provincia de Córdoba.”
6
‐ Requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la Ley. Por ejemplo: ‐ “Las facturas generadas e impresas deben cumplimentar todas las reglamentaciones definas a tal efecto por la AFIP (Administración Federal de Ingresos Públicos) y la Ley de Facturación vigente”. ‐ Requerimientos éticos para asegurar que será aceptado por el usuario y por el público en general.
Categorías de los Requerimientos: En general, plantea Shari Pleeger, es útil separar los requerimientos en tres categorías: 1. Requerimientos que deben ser absolutamente satisfechos 2. Requerimientos que son muy deseables, pero no indispensables. 3. Requerimientos que son posibles, pero que podrían eliminarse Dependiendo del tiempo asignado al proyecto, los recursos, los costos, envergadura del proyecto, entre otros aspectos, el sistema a desarrollar debe considerar obligatoriamente los requerimientos de la categoría 1. Dependiendo de cuánto debe ajustarse el proyecto a las limitaciones pueden analizarse los de categoría 2 para su postergación o eliminación y los requerimientos de categoría 3 son los primeros a eliminarse del proyecto según la necesidad requerida. En análisis de requerimientos por categoría es útil para que todos los participantes comprendan lo que realmente se necesita.
Los problemas con los Requerimientos: Paul Bramble, uno de los autores del libro “Patrones de Casos de Uso”, plantea que existen una serie de problemas cuando trabajamos en la definición de los requerimientos: • Los requerimientos pueden ser tediosos (una extensa lista y/o documentos) • Los requerimientos pueden estar desorganizados
7
• Los requerimientos, como lo expresan los usuarios, pueden ser imprecisos, ambiguos o erróneos • La captura de requisitos es un proceso continuo (mientras más estudiamos el sistema, más aprendemos de él y más cambia). • Los clientes no siempre conocen sus verdaderas necesidades, en muchos casos “creen” estar seguros de las mismas. Es nuestro trabajo encontrarlas. • Un Analista/Desarrollador puede afirmar ‐ “Yo entiendo los requerimientos”, pero …… ¿Qué hace realmente el Sistema? Se necesita un proceso ordenado y sistemático para trabajar con los requerimientos, porque éstos son la base de todo proyecto y en gran medida los responsables de su éxito o fracaso.
Ingeniería de Requerimientos Concepto Es el proceso de descubrir, analizar, documentar y verificar los servicios y restricciones que debe considerar el sistema a desarrollar. En otras palabras, la ingeniería de requerimientos es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema.
Permite una especificación de los requerimientos completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema. La siguiente figura ilustra el esquema de procesos comprendidos por la Ingeniería de Requerimientos.
8
Fuente: Página Web del SIU (Consorcio de Universidades), artículo de Ricardo Williams (Coordinador general del SIU, Licenciado en Sistemas, Especialista en Ingeniería de Software) http://www.siu.edu.ar/infosiu/&edicion=12¬a=75 (fecha visita del sitio: 20‐ 09‐2013)
ELICITACIÓN • Concepto: Proceso en donde se adquiere el conocimiento del trabajo del cliente / usuario, se busca comprender sus necesidades y se detallan las restricciones medioambientales. • Resultado: el conjunto de los requerimientos de todas las partes involucradas. • Técnicas: Entrevistas, cuestionarios, observación, documentos, torbellino de ideas, JAD, entre las principales.
análisis
de
ESPECIFICACIÓN • Concepto: Esta etapa es un proceso de descripción del requerimiento durante el cual se producirá el documento de especificación de requerimientos del software (ERS). • Resultado: Una forma de contrato entre usuarios y desarrolladores que define el comportamiento funcional deseado del software (y otras propiedades como performance, confiabilidad, seguridad.) sin mostrar cómo será alcanzada tal funcionalidad. Existe una norma estándar para la
9
escritura del documento de especificación de requerimientos (ERS) que es la: IEEE Std. 830 (1998) ( IEEE = Institute of Electrical and Electronics Engineers ‐Instituto de Ingenieros en Electricidad y Electrónica‐) • Técnicas: La técnica más utilizada en el momento es la de Casos de Uso, con otras herramientas gráficas complementarias.
VALIDACIÓN • Concepto: Es el proceso que certifica que se ataca el problema correcto. Este proceso final se nutre de los anteriores y realiza la integración y validación final de lo obtenido en cada una de las etapas anteriores. • Resultado: Modelo de requerimientos en línea con las expectativas de los usuarios. • Técnicas: Revisiones de requerimientos, prototipos, generación de casos de prueba, análisis de consistencia automático.
La captura de requisitos en el PUD En el Proceso Unificado de Desarrollo, el propósito fundamental del flujo de trabajo de requisitos es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripción, suficientemente buena, de los requisitos del sistema como para que los desarrolladores lleguen a un acuerdo con el cliente sobre qué debe hacer y qué no debe hacer el sistema. Más allá de cuál sea el punto de partida para el descubrimiento de los requisitos (modelado del negocio, del dominio, especificación de requisitos hecha por el cliente), hay una serie de pasos que están siempre presentes: •
Enumerar los requisitos candidatos.
•
Comprender el contexto del sistema.
•
Encontrar requisitos funcionales
•
Encontrar requisitos no funcionales
10
Enumerar los requisitos candidatos Durante el desarrollo del sistema todos los involucrados en el proyecto (clientes, usuarios, analistas, desarrolladores y otros) presentan buenas ideas que pueden convertirse en requisitos verdaderos. Conviene entonces confeccionar una “lista de características” con estas ideas a las que consideramos requisitos candidatos. Esta lista se aumenta con la aparición de nuevas “ideas” y disminuye cuando algunas características se convierten en verdaderos requisitos y pasan a modelarse como casos de uso. El resto de los pasos se tratarán con más detalle en los puntos que siguen.
3.2- Comprensión del contexto del sistema mediante un modelo de negocio Comprender el contexto del sistema Para capturar los requisitos correctos, que nos lleven a construir el sistema correcto, se requiere un firme conocimiento del contexto en el que se emplaza el sistema. Hay, por lo menos, dos formas de expresar el contexto de un sistema en una forma que sea de utilidad para los desarrolladores del sistema: el modelado del dominio y el modelado del negocio. Un modelo de dominio (también conocido como “Modelo de Objetos del Dominio del Problema”) describe los conceptos importantes del contexto como objetos del dominio y enlaza estos objetos entre sí. Este tema se desarrolla a continuación en esta unidad.
11
El modelado del negocio se realiza para describir los procesos del negocio, con una visión orientada a objetos, con el objetivo de comprenderlos. El modelado de negocio es parte de la Ingeniería de Negocios, que es una técnica que tiene por objetivo mejorar los procesos de negocio de la organización.
Modelo de Negocio Un modelo de casos de uso del negocio describe procesos de un negocio y sus interacciones con el exterior. Su propósito principal es describir cómo es usado el negocio por sus usuarios, en este caso sus clientes y socios. Para nosotros, la principal motivación para confeccionar un modelo de negocio será la posibilidad de derivar, a partir de dicho modelo, los requerimientos del sistema de software que dará soporte a ese sistema de negocio. El modelado de negocio está soportado por dos tipos de modelos de UML (definidos en la extensión de UML relativa al Negocio): •
Modelo de Casos de Uso de Negocio: Presenta una vista externa
del negocio la cual define lo que es esencial que el negocio realice para entregar el resultado deseado a sus clientes (actores del negocio). •
Modelo de Objetos del Negocio: Es una vista interna del negocio
que describe cómo cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores de negocio que utilizan un conjunto de entidades de negocio.
Notación y elementos básicos del Modelado de Negocio Los elementos básicos que están presentes en el Modelado de Negocio son: ‐ Actor de Negocio (usuarios del negocio) ‐ Caso de Uso de Negocio (procesos del negocio) ‐ Trabajador de Negocio (en general: roles que juegan las personas en una organización)
12
‐ Entidad de Negocio (las “cosas” que un negocio administra, produce y/o utiliza) •
Actor De Negocio: Representa un rol en relación al negocio,
desempeñado por algo o alguien en el entorno del negocio. Un actor normalmente corresponde a un ser humano pero hay circunstancias en que un sistema de información juega el rol de un actor. Simbología:
•
Caso De Uso De Negocio: Es una secuencia de acciones que realiza
un negocio para producir un resultado observable de valor para un actor individual del Negocio. Los casos de uso de negocio captura y modelan los procesos de negocio. Simbología:
•
Trabajador De Negocio: Representa un rol o conjunto de roles en el
negocio. Un trabajador de negocio interactúa con otros trabajadores y manipula entidades de negocio mientras participa en las realizaciones de los casos de uso de negocio. Puede representar: ‐ Una abstracción de un humano que actúa dentro del negocio. ‐ Una abstracción del sistema de software que modelamos como trabajador automatizado cuando el Actor en vez de comunicarse con un trabajador de negocio humano accede directamente al sistema.
13
Simbología:
•
Entidad De Negocio: Representa una abstracción de algo que los
trabajadores de negocio toman, inspeccionan, producen o utilizan cuando ejecutan un caso de uso de negocio. Puede representar: a) Un documento b) Una parte esencial de un producto c) Algo menos tangible como el conocimiento o información acerca de un cliente, proveedor, artículos y otras abstracciones clave. (*1) Cuando el objetivo de realizar un modelo de negocio es fundamentalmente derivar el sistema de información de soporte nos concentraremos en modelar entidades de negocio del tipo c) y dejaremos de lado las que representan cosas más bien físicas. De esta manera las entidades de negocio se utilizan para representar los mismos tipos de conceptos que las clases del dominio (que podemos modelar mediante un diagrama de clases como ya se vio en la Unidad 1) Simbología:
14
•
Ejemplo de Modelo de Casos de Uso de Negocio
•
Ejemplos de Modelo de Objetos del Negocio
a) Diagrama de colaboración de negocio: Muestra una realización de caso de uso del negocio.
Ejemplo de diagrama de colaboración de negocio para el caso de uso de negocio “Atender Compra de discografía”
15
b) Diagrama de entidades de negocio: Es un diagrama de clases que modela las entidades de negocio.
En este diagrama pueden bosquejarse los atributos y responsabilidades de las entidades de negocio como clases del Dominio de Problema.
c) Diagrama de trabajadores de negocio: Es un diagrama de clases que modela los trabajadores de negocio, indicando sus atributos y responsabilidades.
16
Derivación del sistema de información a partir del sistema de negocio Un buen entendimiento de los procesos de negocio es importante para poder construir el sistema de soporte correcto. Es en la vista interna del negocio, capturada por el modelo de objetos, que se puede ver la conexión más estrecha con respecto a cómo deberían verse los modelos del sistema de información.
Los modelos de negocio podrían servir como entrada a la vista de casos de uso y a la vista lógica. (Recordar vistas de la arquitectura con UML que tratamos en la Unidad 2).
Modelo de Negocio y Modelo de casos de uso del sistema de información. Las reglas que enunciamos a continuación nos servirán para poder derivar los actores y casos de uso del sistema de información a partir del Modelo de Negocio realizado. 1. Para cada Trabajador del Negocio se deberá determinar si va a utilizar el sistema de información. Si la respuesta es sí, entonces: a) Se identificará un actor del sistema de información con el mismo nombre del actor de negocio.
17
b) Analizar sus responsabilidades: determinar cuáles implican el uso del sistema de información e identificar un caso de uso del sistema por cada una de ellas
2. Si en el modelo de negocio tenemos Trabajadores de Negocio automatizados, entonces: a) El actor de negocio pasará a ser actor del sistema de información.
b) Las responsabilidades del trabajador de negocio automatizado pasarán a ser casos de uso del sistema de información.
18
Modelo de Negocio y clases del Modelo de dominio y Modelo de análisis. Las reglas que enunciamos a continuación nos servirán para poder encontrar clases del Modelo de Dominio y del Modelo de Análisis del sistema de información a partir de las entidades de negocio. 1. Para cada Entidad de Negocio determinar si va a ser soportada por el sistema de información. En este caso: a) Se identificará una clase del Modelo de Objetos del Dominio de Problema con el mismo nombre que la entidad de Negocio b) Se identificará una clase de entidad del Modelo de Análisis. 2. Las relaciones entre Entidad de Negocio que serán soportadas por el sistema de información pasarán a ser relaciones entre clases del Dominio de Problema y del Modelo de Análisis.
Modelo de Dominio Otro de los elementos útiles a la hora de comprender el contexto del sistema, además del Modelo de Negocio, es contar con un modelo de dominio. El Modelo de Dominio (también llamado Modelo de Objetos del Dominio de Problema y frecuentemente encontrado por las siglas MODP) captura
19
los tipos de objetos más importantes en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los “eventos” que suceden en el entorno en el que se desenvuelve el sistema. Muchos de las clases del dominio del problema, pueden deducirse de la especificación de requisitos o mediante la entrevista con los expertos del dominio, o del Modelo de Objetos del Negocio (entidades de negocio) si se cuenta con dicho modelo. Las clases del dominio aparecen como: •
•
•
Entidades del negocio que representan cosas que se manipulan en el negocio como pedidos, cuentas, contratos. Entidades del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como artículos, vehículos. Sucesos que ocurrirán o han ocurrido, como la partida y/o llegada de un avión, un siniestro en una compañía de seguros.
El principal diagrama UML para describir el dominio es el Diagrama de clases.
Utilidad del modelo de dominio El modelado del dominio debe contribuir a la comprensión del problema que se supone que el sistema resuelve. Para desarrollar este modelo debe conformarse un equipo en el que estén presentes tanto los expertos del dominio (usuarios) como gente con experiencia en modelado, coordinado por los analistas del dominio. El modelo de dominio ayuda a los usuarios, clientes, desarrolladores y otros participantes del proyecto a utilizar un vocabulario común. La terminología común es necesaria para compartir el conocimiento con los otros. Las clases del dominio que aquí se encuentren se utilizarán al describir los casos de uso y diseñar el prototipo de interfaz de usuario (dentro del flujo de trabajo de Requisitos) y para sugerir clases internas al sistema en desarrollo durante el Análisis.
20
Diagrama de Clases del dominio de problema Como ya vimos en la Unidad 1, un diagrama de clases (en UML) es un diagrama que muestra un conjunto de clases, interfaces, sus colaboraciones y relaciones. Se utilizan para modelar la vista de diseño estática de un sistema. Con UML los diagramas de clases se emplean para visualizar el aspecto estático de los bloques de construcción básicos del sistema y sus relaciones, y para especificar los detalles para construirlos. Los componentes y simbología del diagrama de clases se trataron en la Unidad 1.
Pautas para su construcción Se enumeran a continuación algunas pautas, en forma de consejos a seguir cuando se está confeccionando un diagrama de clases: •
•
•
•
•
•
Debe comunicar un aspecto de la vista de diseño estática de un sistema. Debe contener sólo los elementos esenciales para comprender ese aspecto. Debe proporcionar detalles en forma consistente con el nivel de abstracción, mostrando sólo aquellos adornos que sean esenciales en dicho nivel. Se deben distribuir sus elementos de modo de minimizar los cruces de líneas. Organizar los elementos de modo que los que semánticamente cercanos lo estén también físicamente.
sean
Usar notas y colores sobre aspectos importantes que se quieran destacar.
Se muestra a continuación el Modelo de Objetos del Dominio de Problema de una empresa de venta de discografía, que se está utilizando para diversos ejemplos.
21
22
3.3- Captura de requerimientos Siguiendo con el proceso de captura de requerimientos, habiendo realizado ya la enumeración de requisitos candidatos y obtenido una comprensión del contexto del sistema (mediante un modelo de negocio y/o un modelo de dominio), continuamos con la identificación de requisitos funcionales y no funcionales, principalmente mediante la técnica de casos de uso.
Encontrar requisitos funcionales La técnica específica para identificar los requisitos funcionales del sistema se basa en los casos de uso. Los casos de uso capturan tanto los requisitos funcionales como los no funcionales, específicos de cada caso de uso. Cada usuario quiere que el sistema haga algo para él, es decir que tendrá distintos modos de utilizar el sistema. Cada una de estas formas de utilizar el sistema es un caso de uso. Entonces si se pueden describir todos los casos de uso que necesita el usuario, se podrá saber lo que debe hacer el sistema.
Encontrar requisitos no funcionales Los requisitos no funcionales especifican propiedades del sistema como restricciones del entorno o de la implementación, dependencias de la plataforma, consideraciones de rendimiento, seguridad, flexibilidad, facilidad de mantenimiento, entre otras. Algunos requisitos no funcionales serán aplicables a todos los casos de uso en general y algunos pueden ser específicos para un caso de uso o sólo un número determinado de ellos. Por ejemplo, el requisito no funcional: ‐ “Las facturas generadas e impresas deben cumplimentar todas las reglamentaciones definas a tal efecto por la AFIP y la Ley de Facturación vigente”, afectará únicamente al caso de uso “Generar facturación”, en cambio el siguiente requisito no funcional: “El sistema deberá funcional en un entorno de red contemplando un máximo
23
de 40 puestos de trabajo simultáneos”, es un requerimiento que afecta en general a todos los casos de uso y a ninguno en particular.
3.4- El modelo de caso de uso. Los casos de uso proporcionan un medio intuitivo y sistemático para capturar los requisitos funcionales poniendo énfasis en el valor agregado para cada usuario individual o para cada sistema externo. La utilización de los casos de uso hace que los analistas deben pensar en términos de quiénes son los usuarios y qué necesitad u objetivos de la empresa pueden cumplir. El principal esfuerzo de la etapa de requisitos es desarrollar un modelo del sistema que se va a construir y la utilización de los casos de uso es una forma adecuada para ello, debido a que los requisitos funcionales se estructuran naturalmente mediante los casos de uso y los requisitos no funcionales suelen ser específicos de un caso de uso y pueden tratarse en ese contexto.
Flujo de trabajo del modelado de casos de uso Dentro del PUD (Proceso Unificado de Desarrollo), el primer flujo de trabajo es el de requisitos. Para presentar este flujo de trabajo, al igual que se irá haciendo con los restantes en las siguientes unidades, mencionaremos los artefactos que se crean en este flujo de trabajo, los trabajadores participantes y las actividades a realizar: •
Artefactos: Los artefactos fundamentales que se utilizan en la
captura de requisitos son:
Modelo de Casos de Uso, que incluye los casos de uso y los actores.
Descripción de la arquitectura
24
•
Glosario
Prototipo de la interfaz del usuario
Trabajadores: Los trabajadores responsables por los artefactos que
se producen en el modelado de casos de uso son:
•
Analista de Sistemas.
Especificador de casos de uso.
Diseñador de interfaz de usuario.
Arquitecto.
Actividades: Las actividades a realizar por los trabajadores para
producir los distintos artefactos son:
Encontrar actores y casos de uso.
Priorizar casos de uso.
Detallar los casos de uso.
Prototipar la interfaz del usuario.
Estructurar el modelo de casos de uso.
El siguiente gráfico muestra los artefactos del modelado de casos de uso y los trabajadores responsables de cada uno:
Fuente: Libro “El Proceso Unificado de Desarrollo de Software”, Ivar Jacobson y otros, (2000), Pág. 127
25
La siguiente figura muestra un gráfico que indica el flujo de trabajo para la actividad de requisitos en el PUD, incluyendo los trabajadores participantes y sus actividades:
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, (2000) Pág. 136
A continuación se realizará una descripción de cada uno de los artefactos, poniendo énfasis en los principales y luego se describirán las actividades comprendidas en este Flujo de Trabajo de Requisitos.
Artefactos del Flujo de Trabajo de Requisitos Modelo de Casos de Uso El modelo de casos de uso permite que los desarrolladores y los clientes lleguen a un acuerdo sobre los requisitos, es decir, sobre lo que debe 26
cumplir el sistema y constituye la entrada principal para el análisis, el diseño y las pruebas. El modelo de casos de uso es un modelo que contiene actores, casos de uso y las relaciones entre éstos. Si el modelo de casos de uso es grande, es decir, si el número de ellos es elevado es útil introducir paquetes en el modelo para tratar su tamaño. Un paquete reunirá cierto número de casos de uso agrupados por algún criterio de homogeneidad (los que corresponden a un mismo actor, los que se refieren a un mismo proceso, son los principales criterios).
Actor Un actor es el rol que juega un usuario en un caso de uso. Normalmente, un actor representa un rol que es representado por una persona, un dispositivo de hardware o incluso otro sistema al interactuar con nuestro sistema. El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada usuario puede representarse por uno o más actores. De la misma forma cada sistema externo que interactúa con el sistema en desarrollo puede representarse por uno o más actores. Cada rol (actor) define lo que hace un trabajador del negocio en un proceso concreto. Cada vez que un usuario en concreto (un humano u otro sistema) interactúa con el sistema, la instancia correspondiente del actor está desarrollando ese papel. Una instancia de un actor es, por lo tanto, un usuario concreto que interactúa con el sistema. Podemos distinguir la siguiente clasificación de actores según el objetivo a cumplir en relación a los casos de uso: •
•
Actor Primario: Tiene un objetivo claro que debe ser tenido en cuenta y concretado con la ayuda del sistema de información. Actor Secundario: Es de quién el sistema necesita ayuda para cumplir con el objetivo del actor primario.
Simbología:
27
Glosario Se puede utilizar un glosario para definir términos comunes importantes que los analistas y otros desarrolladores utilizan al describir el sistema. Un glosario es muy útil para lograr consenso en la definición de distintos conceptos y para reducir el riesgo de confusiones.
Descripción de la arquitectura La descripción de la arquitectura contiene una vista del modelo de casos de uso, que representa los casos de uso significativos. La vista de la arquitectura del modelo de casos de uso debería incluir los casos de uso que describan alguna funcionalidad importante y crítica, o que impliquen algún requisito importante que deba desarrollarse pronto, dentro del ciclo de vida del software. Esta vista de la arquitectura se utiliza como entrada cuando se priorizan los casos de uso para su desarrollo dentro de cada iteración.
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, Pág. 133
28
Caso de Uso Un caso uso representa cada forma en que los actores usan el sistema. Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores. Por lo expresado, un caso de uso es una “especificación”. Especifica el comportamiento de “elementos” dinámicos, en este caso instancias de casos de uso. Una instancia de un caso de uso es la realización (o ejecución) de un caso de uso. Podemos establecer la categoría de los casos de uso como: •
Esenciales: Describen la funcionalidad principal o esencial que tiene
que cumplir el sistema. Comprenden los principales procesos que debe ejecutar el sistema de información. •
De Soporte: Comprenden la funcionalidad que surge a partir de
analizar aquello que se necesita para que puedan funcionar los casos de uso esenciales. También aquí se consideran los casos de uso del usuario, que comprenden la funcionalidad requerida para administrar los datos de los usuarios del sistema y los permisos asignados a los mismos.
Otra forma de clasificar los casos de uso es la siguiente: •
Concreto: Se le llama así al caso de uso que es iniciado por un actor
y que constituye un flujo de eventos completo. •
Abstracto: Es el caso de uso que no es iniciado nunca por un actor,
sino que únicamente es instanciado (iniciado) por otro caso de uso. Surgen a partir de relaciones de extensión, inclusión o generalización. La descripción de un caso de uso puede incluir: •
Diagramas de estados: Especifican el ciclo de vida de las instancias
de casos de uso.
29
•
Diagramas de actividad: Describe el ciclo de vida con más detalle
indicando la secuencia temporal de acciones que tienen lugar dentro de cada transición. •
Diagramas de colaboraciones y de secuencia: Describen las
interacciones entre una instancia típica de un actor y una instancia típica de un caso de uso. El diagrama UML que modela los casos de uso es el diagrama de casos de uso.
Prototipo de interfaz del usuario Los prototipos de interfaz del usuario nos ayudan a comprender y especificar las interacciones entre actores humanos y el sistema durante la captura de requisitos. No sólo nos ayuda a desarrollar una interfaz gráfica mejor, sino a comprender mejor los casos de uso. Para especificar la interfaz de usuario pueden utilizarse modelos de interfaz gráfica y esquemas de pantallas. El tema de los prototipos de interfaz se amplía en el punto 3.5 de esta unidad.
Diagrama de Casos de Uso Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema o un subsistema. Estos diagramas facilitan que los sistemas y subsistemas sean abordables y comprensibles, al presentar una vista externa de cómo pueden utilizarse estos elementos en un contexto dado. Los diagramas de casos de uso contienen: casos de uso, actores, relaciones de dependencia, generalización y asociación. Los actores se conectan a los casos de uso a través de asociaciones. Una asociación entre un actor y un caso de uso indica que el actor y el caso de uso se comunican entre sí y cada uno puede enviar y recibir mensajes. La relación de asociación entre un actor y un caso de uso se grafica para el caso en que el actor sea el responsable de instanciar (iniciar) el caso de uso.
30
Simbología del Diagrama de Casos de Uso En la siguiente figura se muestran los distintos elementos que pueden estar presentes en un diagrama de casos de uso.
Nombre de caso de uso Cada caso de uso debe tener un nombre que lo distinga de los demás. Puede ser un nombre simple (una simple cadena de texto) o un nombre de camino (path) en el caso de que esté precedido por el nombre del paquete en que está incluido el caso de uso. Los nombres de casos de uso son expresiones verbales que describen algún comportamiento del vocabulario del sistema que se está modelando. Se aconseja que el nombre del caso se uso comience con un verbo en infinitivo.
Nombre de actor El nombre del actor debe reflejar el rol que cumple un usuario al interactuar con el caso de uso al que está conectado y no debe reflejar a un usuario en particular.
Relación de Generalización entre actores Pueden definirse categorías generales de actores y especializarlos a través de relaciones de generalización. Los actores especializados (hijos) heredan el comportamiento del actor padre.
31
Si un caso de uso es instanciado por el actor “padre” puede ser instanciado por cualquiera de sus hijos. Ahora bien podría haber casos de uso que son instanciados por uno de los actores “hijo” en particular.
Relaciones entre casos de uso Los casos de uso pueden organizarse especificando relaciones de generalización, inclusión y extensión entre ellos. Estas relaciones se utilizan para: ‐ Factorizar el comportamiento común (extrayendo comportamiento de los casos de uso en los que se incluye)
ese
‐ Factorizar variantes (poniendo ese comportamiento en otros casos de uso que lo extienden). ‐ Simplificar un caso de uso extrayendo una parte compleja y ubicándola en otro caso de uso.
Relación de generalización entre casos de uso La generalización entre casos de uso es como la generalización entre clases. En este contexto significa que el caso de uso hijo hereda el comportamiento del caso de uso padre. El hijo puede modificar y/o agregar comportamiento al heredado. La generalización se emplea para simplificar la forma de trabajo y la comprensión del modelo de casos de uso y para reutilizar casos de uso
32
“semifabricados”. Un caso de uso “semifabricado” existe solamente para que otros lo reutilicen. Gráficamente se indica, al igual que la herencia entre clases, con una línea continua con punta de flecha vacía dirigida del caso de uso hijo hacia el padre. Ejemplos:
Relación de inclusión entre casos de uso Una relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. El caso de uso incluido nunca es instanciado por un actor, sino que es instanciado por el/los casos de uso que lo incluyen. Por ello, un caso de uso de inclusión es siempre un caso de uso abstracto. La secuencia de comportamiento y los atributos del caso de uso incluido se encapsulan y no pueden modificarse o accederse, solamente puede utilizarse el resultado (o función) del caso de uso incluido. El caso de uso base llama al caso de uso incluido el cual se ejecuta y luego el control vuelve al caso de uso base. 33
Una característica de la relación de inclusión es que el caso de uso base siempre deberá invocar la ejecución del caso de uso incluido para completar con su objetivo; es decir, el caso de uso base no está completa sino se ejecuta la funcionalidad del caso de uso de inclusión. La relación de inclusión se usa para abstraer el comportamiento común entre casos de uso, evitando describir el mismo flujo de eventos repetidas veces. También se utiliza para apartar del caso de uso base una porción de funcionalidad compleja o que complica la compresión de éste. La inclusión se representa como una dependencia estereotipada con la palabra include o en forma abreviada inc, dirigida desde el caso de uso base hacia el caso de uso incluido.
Relación de extensión entre casos de uso Una relación de extensión entre casos de uso significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso. El caso de uso base puede ejecutarse aisladamente, pero bajo ciertas condiciones su funcionalidad será extendida por la del caso de uso de extensión. La extensión puede verse como que el caso de uso de extensión incorpora su comportamiento en el caso de uso base. Una relación de extensión se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. También puede utilizarse para
34
modelar un subflujo separado que sólo se ejecuta bajo ciertas circunstancias. El hecho de que la llamada al caso de uso de extensión sea opcional se debe a que el caso de uso base es completo en sí mismo, es decir puede cumplir con su objetivo sin necesidad de llamar al caso de uso de extensión; sólo que a veces “extenderá” o “ampliará” su funcionalidad llamando a la ejecución del otro caso de uso. El caso de uso de extensión puede en algunos casos ser instanciado directamente por un actor (en este caso se considera un caso de uso concreto), además de instanciarse para extender el comportamiento de un caso de uso base. Si el caso de uso de extensión nunca es instanciado directamente por un actor, entonces es un caso de uso abstracto. La extensión se representa como una dependencia estereotipada con la palabra extend o en forma abreviada ext, dirigida desde el caso de uso de extensión hacia el caso de uso base.
Actividades del Flujo de Trabajo de Requisitos Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Describimos un flujo de trabajo como una secuencia de actividades que están ordenadas, de modo que una actividad produce una salida que sirve de entrada a la siguiente. A pesar de ello, en el mundo real
35
no siempre trabajamos estrictamente en secuencia. Se puede trabajar por múltiples vías que producen un resultado final equivalente. Una actividad puede ser retomada muchas veces (recordemos que estamos en un proceso de desarrollo iterativo) y cada una de éstas puede acarrear la ejecución de un solo fragmento de la actividad. Por ejemplo cuando retomamos la actividad “Encontrar actores y casos de uso”, el nuevo resultado puede ser solamente una identificación adicional de un caso de uso. Las distintas actividades en el modelado de casos de uso adoptan diferentes formas en diferentes fases del proyecto. Por ejemplo, cuando un analista de sistemas ejecuta la actividad de “Encontrar actores y casos de uso” durante la fase de inicio, identificará muchos actores y casos de uso nuevos. Pero cuando la actividad se realice durante la fase de construcción, el analista hará principalmente cambios secundarios en el conjunto de actores y casos de uso. Se describen a continuación las actividades que se realizan en el flujo de trabajo de requisitos.
ENCONTRAR ACTORES Y CASOS DE USO
La identificación de actores y casos de uso es la actividad más decisiva para obtener adecuadamente los requisitos y es responsabilidad del analista de sistemas. Para realizar esta actividad, si se dispone de un modelo de negocio, se puede obtener un borrador del modelo de casos de uso en forma bastante directa. Otras veces se puede partir del modelo de dominio o simplemente de una especificación de las características que se requieren del sistema. Esta actividad puede descomponerse en cuatro pasos: 1. Encontrar los actores 2. Encontrar los casos de uso 3. Describir brevemente los casos de uso 4. Describir el modelo de casos de uso completo
1. Encontrar los actores: Hay dos criterios útiles a la hora de elegir los candidatos a actores:
36
‐ Primero debe ser posible identificar al menos un usuario que pueda representar al actor candidato. ‐ Segundo, debe existir una coincidencia mínima entre los roles que desempeñan las instancias de los diferentes actores. No debemos tener dos o más actores que cumplan los mismos roles. O son el mismo actor o se realiza una generalización abstrayendo el comportamiento común.
Para encontrar actores, resulta útil preguntarse por ejemplo quién va a utilizar cierta información, quién va a usar una determinada funcionalidad, quién actualizará algún dato en el sistema, con qué otros sistemas va a interactuar el sistema que estamos modelando. El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor. La descripción de cada actor debe esbozar sus necesidades y responsabilidades. 2. Encontrar los casos de uso: El analista de sistemas identificará los casos de uso a través de los talleres con los clientes y los usuarios. El analista de sistemas va repasando los actores de a uno y piensa en qué forma pueden utilizar el sistema o qué necesitan del sistema, proponiendo así casos de uso, que se consideran en primera instancia “candidatos”. Algunos de los candidatos no llegarán a ser casos de uso por sí mismos, sino que serán partes de otro. Como ya mencionamos al hablar de las categorías de casos de uso (página 21 de esta material), habrá casos de uso a los que llamamos esenciales porque involucran actividades que constituyen el núcleo del negocio y suelen ser los primeros en ser descubiertos; y otros casos de uso a los que llamamos secundarios o de soporte, que permiten realizar tareas tales como: actualizar todas las clases que aparecieron en el dominio del problema y las que irán apareciendo, más adelante (en las últimas iteraciones) pueden aparecer casos de uso para administrar usuarios, sesión de usuario, entre otros. Se elige un nombre por cada caso de uso, que represente la secuencia de acciones concreta que añade valor a un actor (produce algo de valor para el actor). El nombre del caso de uso comienza con un verbo (preferentemente en infinitivo) y debe reflejar el objetivo de la interacción entre el actor y el sistema. 3. Describir brevemente cada caso de uso: A medida que se van descubriendo los casos de uso se suele ir registrando algunas palabras explicándolos. Luego se procede a describir más
37
formalmente el caso de uso, en primera instancia con unas pocas frases y más adelante se hará una descripción detallada. 4. Describir el modelo de casos de uso completo: Esta tarea consiste en elaborar diagramas y descripciones para explicar el modelo de casos de uso en totalidad. No hay una regla estricta que indique qué se debe incluir en un diagrama (considerando un sistema medianamente complejo en el que no se pueden incluir todos los casos de uso en solo diagrama). Podemos tener diagramas por cada proceso de negocio, o reunir todos los casos de uso en los que interviene un mismo actor. El modelo de casos de uso puede organizarse en conjuntos de casos de uso conformando paquetes de casos de uso.
PRIORIZAR CASOS DE USO
El propósito de esta actividad es determinar cuáles casos de uso son necesarios para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para más adelante. Los resultados de esta actividad conforman la vista de la arquitectura del modelo de casos de uso, que es revisada por el jefe de proyecto y se utiliza como base para la planificación de una iteración.
DETALLAR CASOS DE USO
El objetivo de esta actividad es detallar el flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactúan con los actores. Con el modelo de casos de uso como punto de partida el especificador de un caso de uso individual puede comenzar a describir cada caso de uso en detalle, especificando la secuencia precisa de acciones. Hay varias formas y herramientas con las que se puede realizar la descripción de un caso de uso. Independientemente de la forma elegida para describir el caso de uso, debe verificarse que la descripción siempre incluya lo siguiente: El estado inicial, como precondición. Cómo y cuándo comienza el caso de uso (es decir, la primera acción a ejecutar). El orden requerido en el que las acciones de deben ejecutar (determinado en forma de secuencia numerada).
38
Cómo y cuándo terminan los casos de uso. Los posibles estados finales, como postcondiciones. Los caminos de ejecución que no están permitidos. Las descripciones de caminos alternativos que están incluidos junto con la descripción del camino básico. Las descripciones de caminos alternativos que han sido extraídos de la descripción del camino básico. La interacción del sistema con los actores y qué cambios producen. La utilización de objetos, valores y recursos del sistema. La descripción explícita de lo que hace el sistema, separando las responsabilidades del sistema de las acciones de los actores.
A continuación de muestra una plantilla que cubre estos aspectos y resulta muy útil para realizar una descripción detallada de un caso de uso, incluyendo las referencias a los casos de uso con los que tiene relaciones de extensión, inclusión, generalización. Hay diferentes formatos que se pueden utilizar para una plantilla descriptiva de caso de uso, el siguiente es simplemente una propuesta; mientras se respeten los ítems esenciales que deben incluirse en la descripción, tal como se enunciaron en el párrafo anterior, se pueden agregar o quitar secciones según las necesidades o preferencias del equipo de especificación. Plantilla para la descripción de Casos de Uso
39
40
Otras herramientas que pueden ayudar a mejorar la comprensión de los casos de uso son: •
•
•
Diagramas de estado: Para describir los estados de los casos de uso y las transiciones entre esos estados. Diagramas de actividad: Para describir las transiciones entre estados con más detalle como secuencias de acciones. Diagramas de interacción: Para describir cómo interactúa una instancia de caso de uso con la instancia de un actor. En este caso el diagrama de interacción muestra sólo el caso de uso y el actor o actores participantes.
PROTOTIPAR LA INTERFAZ DEL USUARIO
Hasta aquí, se ha desarrollado el modelo de casos de uso que especifica qué usuarios hay y para qué necesitan usar el sistema. Ahora, hay que diseñar la interfaz de usuario que le permita llevar a cabo los casos de uso de manera eficiente. Se comienza con los casos de uso, intentando determinar qué se necesita de las interfaces de usuario para habilitar los casos de uso. Esto es hacer un diseño lógico de la interfaz. Luego se realiza un diseño físico y se desarrollan prototipos. Como ya mencionamos anteriormente, el tema de los prototipos de interfaz se amplía en el punto 3.5 de esta unidad.
ESTRUCTURAR EL MODELO DE CASOS DE USO
El modelo de casos de uso se estructura para:
41
•
•
Extraer descripciones de funcionalidades generales y compartidas que pueden ser utilizadas por descripciones más específicas (casos de uso de inclusión). Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones más específicas (casos de uso de extensión).
En esta actividad el analista de sistemas puede reestructurar el conjunto completo de casos de uso para hacer que el modelo sea más fácil de entender y de trabajar con él. El analista debe buscar comportamientos compartidos y extensiones. Esto se refleja en la determinación de relaciones de generalización, inclusión y extensión entre casos de uso. Cuando se trató el tema de “Relaciones entre casos de uso” se presentaron varios ejemplos de cada una. Se muestra en la siguiente figura un ejemplo de un caso de uso cuya funcionalidad fue extraída de los casos de uso base y es llamando por extensión o por inclusión según sea el caso de uso base llamador.
Ejemplo de diagrama de casos de uso de un Sistema de Comercialización de Discografía, del que se han ido dando algunos ejemplos sueltos.
42
43
3.5- Prototipos de Interfaz Concepto y propósito de los prototipos Un prototipo es una versión inicial de un sistema de software que se utiliza para demostrar los conceptos, probar opciones de diseño y, en general, conocer más acerca del problema y opciones de solución. Tal como lo plantea Ian Sommerville (2002), un prototipo de sirve de apoyo a dos actividades dentro del proceso de ingeniería de requerimientos: 1. Obtención de requerimientos: Los prototipos permiten a los usuarios experimentar para ver cómo el sistema ayudará a su trabajo. Les permite adquirir nuevas ideas para los requerimientos y proponer nuevos requerimientos. 2. Validación de requerimientos: Un prototipo puede revelar errores y omisiones en los requerimientos propuestos y especificados. Con el uso de prototipos los usuarios a menudo encuentran que su visión inicial fue incorrecta o incompleta, entonces la especificación del sistema puede modificarse para reflejar el cambio en la comprensión de los requerimientos. Además de permitir a los usuarios mejorar la especificación de requerimientos, el desarrollo de un prototipo del sistema tiene otras ventajas: •
•
•
•
Al demostrar las funciones del sistema se identifican las discrepancias entre los desarrolladores y los usuarios. Durante el desarrollo del prototipo, el personal de desarrollo puede darse cuenta de que los requerimientos son inconsistentes y/o están incompletos. Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar. El prototipo de utiliza como base para escribir la especificación para la producción de un sistema de calidad.
44
Por lo general el desarrollo del prototipo conduce a mejorar la especificación del sistema, pero una vez que el prototipo está disponible también se utiliza para otros propósitos: 1. Capacitar al usuario: El prototipo se puede utilizar par capacitar a los usuarios antes que el sistema final esté terminado. 2. Probar el sistema: Los mismos casos de prueba se introducen al prototipo y al sistema en prueba. Si ambos sistemas dan los mismos resultados el caso de prueba no detecta una falla. Pero si los resultados difieren significa que el sistema falla y hay que investigar las razones de las diferencias.
Construcción de prototipos de interfaz de usuario En la actualidad, las interfaces gráficas de usuario (GUI por sus siglas en inglés) se han convertido en las normas para los sistemas interactivos. El esfuerzo comprendido en la especificación, el diseño y la implementación de una interfaz de usuario representa una parte significativa de los costos de desarrollo de un sistema. Ian Sommerville (2002) nos plantea que los diseñadores no deben dar su opinión a los usuarios de lo que debería ser una interfaz de usuario y que el usuario debe tener una participación activa en el diseño de la misma. Desde el punto de vista de la Ingeniería de software, la construcción de prototipos es una parte esencial del proceso de diseño de la interfaz de usuario. La construcción de prototipos evolutivos con la participación del usuario final es la única manera sensible para desarrollar interfaces gráficas de usuario para los sistemas de software. La siguiente figura nos muestra el proceso de diseño de una interfaz de usuario, tal como lo presenta Ian Sommerville en su libro “Ingeniería de Software” (ver bibliografía).
45
Fuente: Libro “Ingeniería de Software” – Ian Sommerville, 2002, Pág. 329.
Ventajas del uso de Interfaz Gráfica de Usuario (GUI) Aunque las interfaces basadas en texto aún se utilizan, especialmente en los sistemas heredados, los usuarios actuales de sistemas informáticos esperan que las aplicaciones tengan algún tipo de interfaz gráfica de usuario. Este tipo de interfaces se caracterizan por el uso de los siguientes elementos: •
•
•
•
Ventanas: Las ventanas múltiples permiten que se despliegue simultáneamente información diversa en la pantalla del usuario. Íconos: Los íconos representan diferentes tipos de información. En algunos sistemas los íconos representan archivos y en otros representan procesos. Menús: Los comandos se seleccionan de un menú en lugar de teclearse en un lenguaje de órdenes. Apuntador : Para seleccionar las opciones de un menú, indicar elementos de interés en una ventana o dirigirse a alguna parte de la ventana se utiliza un dispositivo apuntador como el “mouse” (ratón).
46
•
Gráficos: Los elementos gráficos se pueden mezclar con texto en el mismo despliegue.
Entre las ventajas del uso de interfaces gráficas de usuario podemos mencionar: •
•
•
Son fáciles de aprender y utilizar. Para interactuar con el sistema los usuarios cuentan con pantalla múltiples (ventanas) por lo tanto es posible ir de una tarea a otra sin perder de vista la información generada durante la primer tarea. Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la pantalla.
Elementos de una interfaz gráfica de usuario Los diseñadores de interfaces de usuario deben tener en cuenta las capacidades físicas y mentales de la gente que utilizará el software. Las personas olvidan fácilmente y cometen varios errores cuando tienen que manejar demasiada información o están bajo presión, pero poseen un amplio rango de capacidades físicas. Las habilidades humanas son la base para los principios de diseño que se enuncian a continuación y que consisten en una serie de principios generales que se pueden aplicar a todos los diseños de interfaces de usuario. •
•
•
Familiaridad del usuario: La interfaz debe utilizar términos y conceptos que se toman de la experiencia de las personas que más utilizan el sistema. Por ejemplo, si en la organización utilizan el término “afiliado” para referirse a los clientes mantener esta denominación en las interfaces. Consistencia: La interfaz debe ser consistente en el sentido de que las operaciones comparables se activan de la misma forma. Por ejemplo todas las ventanas de registro de datos son similares (ventana para registrar nuevo disco, nuevo sello, nuevo género) Mínima sorpresa: El comportamiento del sistema no debe provocar sorpresa a los usuarios. Utilizar recursos como mostrar una barra de avance para indicar al usuario que el sistema está procesando algo, por ejemplo, para que no piense que se ha clavado el sistema.
47
•
•
•
Recuperabilidad : La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de los errores, como confirmación de acciones destructivas (siempre solicitar confirmación ante una acción “eliminar”), proveer un recurso para deshacer (incluir la opción “cancelar” en todas las ventanas) Guía al usuario: Cuando los errores ocurren, la interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto. Mostrar mensaje de error significativo para el usuario que le den indicación sobre cuál es el error y cómo subsanarlo o cómo continuar correctamente con la aplicación. Diversidad de usuarios: La interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios del sistema. Hay usuarios que tienen buena memoria y son ágiles con el teclado numérico de modo que prefieren ingresar por este medio los datos (como por ejemplo legajos de personal o código de artículos) en vez que tener que trasladar la mano al mouse para hacer la selección desde un combo o lista, lo cual se traduce en más tiempo empleado en la operación si hay que hacer muchos cambios de movimiento de la mano (del teclado al mouse y de éste al teclado sucesivamente). De modo que la interfaz debería permitir ambos tipos de acciones: ingreso de datos o selección de los mismos.
Interacción del usuario Los diseñadores de interfaces de usuario deben decidir cómo se va a introducir la información del usuario a la computadora y cómo se presentará al usuario la información del sistema. La interacción del usuario implica emitir comandos y datos asociados al sistema de software. En las primeras computadoras la única forma de hacer esto era a través de una interna de línea de comandos en la que se utilizaba un lenguaje de propósito específico. Sin embargo este enfoque sólo lo utilizaban los expertos por lo que fueron surgiendo otras posibilidades que les facilitaban las tareas. Ian Sommerville (2002) en el libro que hemos estado mencionando, cita a Shneiderman, quien clasificó las diversas formas de interacción del usuario con la computadora (es decir con la interfaz de usuario) en estos cinco estilos primarios: •
Manipulación directa: Cómo “arrastrar” para mover o eliminar un archivo. Es una interacción rápida e intuitiva además de fácil de
48
aprender pero puede ser difícil de implementar si no hay una representación visual clara para las tareas y objetos. •
•
•
•
Selección de menús: Seleccionar el archivo y luego seleccionar la acción “mover” o “eliminar” desde un menú. Evita errores del usuario y requiere teclear poco, pero puede parecer lenta a usuarios experimentados. Llenado de formularios: El usuario llena campos de un formulario (ventana de carga de datos), puede tener menús asociados, botones, íconos, entre otros elementos gráficos. Implica una forma de introducción de datos sencilla y fácil de aprender pero ocupa mucho espacio en pantalla. Lenguaje de comandos: El usuario indica un comando especial y parámetros necesarios (DEL nota.txt). Es una forma de interacción poderosa y flexible pero puede resultar difícil de aprender. Lenguaje natural: Emitir un comando en lenguaje natural (“borrar el archivo nota.txt”). Resulta accesible a usuarios casuales pero se requiere teclear más además que se debería disponer de sistemas de comprensión de lenguaje natural los cuales no siempre resultan fiables.
Respecto de la forma de presentación de la información a los usuarios en la interfaz, podemos mencionar brevemente. •
•
Presentación como texto: Utilizada generalmente cuando se requiere información numérica precisa y la información cambia relativamente lento. Presentación como gráfico: Utilizada generalmente cuando los datos cambian rápidamente o si las relaciones entre los datos son significantes (uso de gráficos de barra, curva, torta, por ejemplo).
Uso del color en el diseño de la interfaz de usuario En general, los sistemas interactivos permiten despliegues a color y los diseñadores de interfaces de usuario utilizan el color de diferentes formas. El uso del color en las interfaces puede resultar de utilidad ayudando a los usuarios a comprender y manejar la complejidad. Sin embargo, si el color
49
es utilizado de manera errónea puede conducir a interfaces poco atractivas, fatigosas para la vista y propensas a errores. A continuación se listan algunas recomendaciones respecto del uso del color en las interfaces:
Limitar el número de colores utilizados, ser conservador al momento de utilizarlos.
Utilizar un cambio de color para mostrar un cambio en el estado del sistema (por ejemplo en un listado de pedidos identificar con azul los cancelados).
Utilizar el código de colores para apoyar la tarea que los usuarios están tratando de llevar a cabo (identificar instancias anómalas o similitudes).
Utilizar el código de colores en forma consciente y consistente: Si en una parte se muestran mensajes de error en color rojo, hacerlo así en todas las interfaces.
Ser cuidadoso al utilizar pares de colores: Por la fisiología del ojo las personas no pueden enfocar el rojo y el azul simultáneamente. La vista cansada es consecuencia del despliegue de rojo sobre azul. Otras combinaciones también son perturbadoras o difíciles de leer (como amarillo sobre negro por ejemplo).
Soporte al usuario Las interfaces de usuario siempre deben proveer alguna forma de sistema de ayuda en línea, como mencionamos al enunciar los principios de diseño de interfaces de usuario. Los sistemas de ayuda en línea con una faceta de una parte general del diseño de interfaces de usuario. El soporte al usuario cubre tres áreas: •
Los mensajes producidos por el sistema en respuesta a las acciones del usuario
•
Ayuda en línea
•
La documentación suministrada con el sistema
50
Mensajes de error Los mensajes de error del sistema son la primera marca que reciben los usuarios de un sistema de software. Al hacer su trabajo los usuarios inexpertos pueden cometer errores y de manera inmediata debería poder comprender el mensaje de error resultante. Los mensajes de error deben tomar en cuenta el conocimiento y la experiencia de los usuarios. Podemos tener: •
•
Mensaje orientado al sistema: Como por ejemplo: “Error # 32 en línea 410” Es un mensaje negativo, no se ajusta a las habilidades y nivel de experiencia del usuario, tampoco sugiere cómo rectificar la situación. Mensaje orientado al usuario: Como por ejemplo “Cliente no registrado – utilice la opción: Registrar Nuevo Cliente”. Este tipo de mensajes son los que se deben utilizar. Deben ser amables, concisos, consistentes y constructivos.
Diseño del sistema de ayuda En el caso que el mensaje de error no sea suficiente para el usuario, éste se dirigirá inmediatamente al sistema de ayuda en busca de más información para solucionar el inconveniente o duda que se le presenta. Hay algunos aspectos interesantes a considerar al momento de diseñar la ayuda en línea: •
•
•
Niveles de entrada: Los sistema de ayuda proveen varios puntos diferentes de entrada a los usuarios. Navegación de la ayuda: Los usuarios pueden ingresar al sistema de ayuda en el punto de la jerarquía correspondiente al mensaje y luego navegar por la estructura de red del sistema de ayuda. Puede pasar que el usuario comience a navegar por la ayuda y al poco tiempo se encuentre “perdido”; desplegar la información de ayuda en múltiples ventanas puede aliviar esta situación. Contenido: El texto de un sistema de ayuda se prepara con la ayuda de especialistas en la aplicación. La ayuda en línea no debe ser simplemente una reproducción del manual del usuario ya que las personas leen en papel y en pantalla en forma diferente. El texto, su
51
exposición y estilo tienen que diseñarse cuidadosamente para permitir su despliegue legible en una ventana generalmente pequeña. •
Herramientas: Respecto de las herramientas que se pueden utilizar para confeccionar un sistema de ayuda en línea tenemos,
Conjunto de páginas vinculadas a Worl Wide Web que serán accedidas mediante un navegador: Son fáciles de implementar y no necesitan ningún software especial pero pueden ser difíciles de vincular con las aplicaciones.
Sistema de hipertexto integrado con las aplicaciones, utilizando herramientas como por ejemplo WinHelp que produce ayudas similares a las que están ampliamente difundidas en los sistemas operativos y aplicativos comerciales.
Documentación del usuario La documentación del usuario no es estrictamente parte del diseño de la interfaz de usuario, pero es recomendable diseñar el apoyo de ayuda en línea junto con la documentación en papel. Los manuales del sistema proveen información más detallada de la ayuda en línea y se diseña de tal forma que puedan ser utilizados por diferentes tipos de usuarios del sistema. Ian Sommerville (2002) nos recomienda al menos cinco documentos, o capítulos de un único documento, para entregar junto con el producto de software: •
•
•
Descripción funcional : Describe brevemente los servicios que provee el sistema. Documento de instalación: Provee los detalles de cómo instalar el sistema, los discos que se entregan con el sistema, los archivos de estos discos y la configuración de hardware mínima requerida para que funcione correctamente el sistema. Manual Introductorio: Presenta una introducción un tanto informal del sistema, describiendo su utilización normal. Describe como iniciar, cerrar sesión de usuarios y cómo utilizar los recursos comunes del sistema.
52
•
•
Manual de referencia: Describe todos los recursos del sistema; provee una lista de los mensajes de error, posibles causas y cómo recuperarse de los mismos. Guía del administrador: Describe los mensajes que se generan por la interacción del sistema con otros sistemas y cómo reaccionar en estas situaciones; también cuando el problema puede estar relacionado con algún elemento de hardware, indicando cómo reconocer y reparar el problema, de ser posible para el usuario. Este tipo de documentación sólo está presente en algunos tipos de sistemas, los que incluyen saturaciones como las que se describieron.
Evaluación de la interfaz La evaluación de la interfaz es el proceso de valorar la forma en que es utilizada una interfaz y verificar que cumple sus requerimientos. Idealmente, una evaluación se compara con la especificación de la usabilidad que se basa en los siguientes atributos: •
•
•
•
•
Aprendizaje: Se evalúa cuánto tiempo tarda un usuario nuevo en ser productivo con el sistema. Velocidad de operación: Se considera qué tan bien responde el sistema a las operaciones de trabajo del usuario. Robustez: Se evalúa qué tan tolerante es el sistema a los errores del usuario. Recuperación: Se observa qué tan bien se recupera el usuario de los errores del usuario. Adaptación: Se evalúa qué tan atado está el sistema a un solo modelo de trabajo.
Para realizar la evaluación de la interfaz de usuario se pueden aplicar las siguientes técnicas: •
Cuestionarios, que recolectan la opinión de los usuarios acerca de la interfaz.
•
Observación de los usuarios al momento de trabajar con el sistema.
•
Videos de sesiones de usuario.
53
•
Código incluido en el software que recolecte información sobre errores más comunes y recursos más utilizados.
Elementos de una interfaz gráfica de usuario Se muestran a continuación algunos elementos que están presentes en toda interfaz gráfica de usuario.
54
55
