Unlock Unidad 4 de Planificacion y Modelado

7/27/2019 Unlock Unidad 4 de Planificacion y Modelado

1/14

UNIDAD 4

ANALISIS DE LOSREQUERIMIENTOS

Objetivo: Aplicar los requerimientos

correspondientes a su proyecto,

disear las interfaces de usuario y

los casos de uso del proyecto.


2/14

UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS.

65

4.1 REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES Un requerimiento es:

Una condicin o necesidad de un usuario para resolver un problema o alcanzar un

objetivo .

Una condicin o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estndar, especificacin u otro

documento formal.

Los requerimientos puedes dividirse: Requerimientos Funcionales y

Requerimientos No Funcionales.

Los requerimientos funcionales definen las funciones que el sistema sercapaz de realizar. Describen las transformaciones que el sistema realiza sobre las

entradas para producir salidas.

Los requerimientos no funcionales tienen que ver con caractersticas que deuna u otra forma puedan 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, estndares, etc.

4.2 CASOS DE USO

Un caso de uso es una tcnica para la captura de requisitos potenciales de un nuevosistema o una actualizacin de software.

Cada caso de uso proporciona uno o ms escenarios que indican cmo debera

interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo

especfico. Normalmente, en los casos de usos se evita el empleo de jergas tcnicas,

prefiriendo en su lugar un lenguaje ms cercano al usuario final. En ocasiones, se utiliza

a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

En otras palabras, un caso de uso es una secuencia de interacciones que se

desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un actor

principal sobre el propio sistema.

Los diagramas de casos de uso sirven para especificar la comunicacin y el

comportamiento de un sistema mediante su interaccin con los usuarios y/u otros

sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los

casos de uso en un sistema.


3/14


66

Una relacin es una conexin entre los elementos del modelo, por ejemplo la

especializacin y la generalizacin son relaciones. Los diagramas de casos de uso se

utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una

respuesta a eventos que se producen en el mismo.

Cada caso de uso se centra en describir cmo alcanzar una nica meta o tarea

de negocio. Desde una perspectiva tradicional de la ingeniera de software, un caso del

uso describe una caracterstica del sistema. Para la mayora de proyectos de software,

esto significa que quizs a veces es necesario especificar diez o centenares de casos de

uso para definir completamente el nuevo sistema. El grado de la formalidad de un

proyecto particular del software y de la etapa del proyecto influenciar el nivel del detalle

requerido en cada caso de uso.

Los casos de uso pretenden ser herramientas simples para describir elcomportamiento del software o de los sistemas. Un caso del uso contiene una

descripcin textual de todas las maneras que los actores previstos podran trabajar con

el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna

(oculta al exterior) del sistema, ni explican cmo se implementar. Simplemente

muestran los pasos que actor sigue para realizar una tarea.

Un caso de uso debe:

Describir una tarea del negocio que sirva a una meta de negocio tener un nivel

apropiado del detalle Ser bastante sencillo como que un desarrollador lo elabore en un nico

lanzamiento

Situaciones que pueden darse: Un actor se comunica con un caso de uso (si se trata de un actor primario la

comunicacin la iniciar el actor, en cambio si es secundario, el sistema ser el

que inicie la comunicacin). Un caso de uso extiende otro caso de uso.


4/14


5/14


68

En la siguiente figura, se muestra un ejemplo de Diagrama de Casos de Uso para un

cajero automtico.

A) Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores,

casos de uso y relaciones entre casos de uso.

B) Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un

sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el

sistema. Se representa mediante una figura humana dibujada con palotes. Estarepresentacin sirve tanto para actores que son personas como para otro tipo de

actores.

Casos de Uso

Un caso de uso es una descripcin de la secuencia de interacciones que se producen

entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea

especfica. Expresa una unidad coherente de funcionalidad, y se representa en el

Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en suinterior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea

llevar a cabo usando el sistema.

Relaciones entre Casos de Uso

Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo

para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin

con un alcance menor como caso de uso.


6/14


69

La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la

comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de

uso.

Para el caso de que queramos utilizar estos casos de uso ms pequeos, las

relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres

tipos: Incluye (): Un caso de uso base incorpora explcitamente a otro caso de uso en

un lugar especificado en dicho caso base. Se suele utilizar para encapsular un

comportamiento parcial comn a varios casos de uso. En la siguiente figura se muestra

cmo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso

Autorizacin.

4.3 DISEO DE INTERFAZ DE USUARIOEl propsito de la interfaz es muy simple: recoger de los usuarios la informacin del

sistema y ponerla a disposicin de otros usuarios. La informacin recogida se llama

entrada del sistema y se almacena en la base de datos para ponerla a disposicin de los

dems usuarios. La informacin suministrada se llama salida del sistema. Es decir, el

diseo de interfaces cubre tanto las entradas como las salidas.

Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz

interactiva, el usuario se comunica directamente con el ordenador y la salida se obtiene

muy poco tiempo despus de la entrada. En el caso de entradas o salidas no

interactivas, es decir, por lotes, las transacciones se renen en formularios en el punto

de recepcin y despus se introducen en el ordenador al mismo tiempo.

Estas transacciones se procesan y un tiempo despus se producen las salidas,

las cuales se pasan al usuario. As, el tiempo transcurrido desde la introduccin de los

datos hasta que se obtiene una respuesta puede ser considerable.

El diseo de interfaz interactivo provoca un dilogo hombre-mquina que permite

un intercambio rpido de informacin entre los ordenadores y sus usuarios humanos,

mientras que la interfaz no interactiva utiliza un soporte de papel para contener la

informacin en el que las entradas normalmente se realizan en formularios

especialmente diseados y las salidas se producen en un listado impreso.

Ser necesario definir los formatos individuales de las pantallas utilizadas. En el

caso de utilizar un paquete estndar, habr que evaluar la posibilidad de adoptar el tipo

de formato del producto.


7/14


70

Entre los aspectos a considerar en los formatos de pantalla se destacan:

encabezamiento, cuerpo principal, pie, teclas de funcin, teclas de ayuda y lneas de

visualizacin de los mensajes de ayuda.

Tambin hay que describir, de forma detallada, los dilogos entre pantallas y su

encadenamiento. Para ello, es til representarlas jerrquicamente, de forma que en los

niveles superiores se representen los mens, y en los niveles inferiores las pantallas de

dilogos, representativas de funciones o procesos concretos del sistema. En esta

representacin jerrquica nos interesa identificar los mens o dilogos concretos en

funcin de los grupos de usuarios que los utilicen.

Ser tambin necesario determinar los dilogos que se consideran crticos para un

funcionamiento correcto del nuevo sistema. Los dilogos crticos se determinan en

funcin de factores como: tipo de proyecto, grado de cambio con respecto al sistema

actual, complejidad de los trabajos del sistema.

Para ello, es til tener en cuenta los siguientes criterios: frecuencia de uso de estos

dilogos, acceso a gran nmero de entidades de datos del sistema, gran nmero de

elementos de datos asociados con el dilogo, cambio en el modo habitual de trabajo en

el sistema actual, dilogos comunes a diferentes grupos de usuarios, dilogos que

contienen opciones complejas de navegacin, etc.

Por ltimo, habr que realizar un prototipo dinmico que permita la simulacin

(introduccin y validacin de datos por pantalla) para los dilogos considerados como

crticos.

Como recomendaciones para realizar este prototipo se tendr en cuenta: la

determinacin del punto de entrada a cada pantalla y sus posibilidades de navegacin a

otras, la especificacin de los datos asociados a cada pantalla (longitud, reglas de

validacin, mensajes de ayuda, etc.), la evaluacin de la consistencia del diseo,

asegurando que toda la informacin necesaria para el usuario est contemplada en laspantallas, y la confirmacin con el usuario de la validez de los diseos de pantalla

realizados

Entre las consideraciones a tener cuenta a la hora de disear pantallas se

encuentran las siguientes:

Caractersticas deseadas: simplicidad, claridad y fcil de comprender. Sernecesario tener claridad visual, de forma que los elementos estn agrupados de

forma comprensible y con significado en vez de al azar y de forma confusa.


8/14


71

Saber dnde situar la informacin en la pantalla. Ser necesario indicar unpunto de partida obvio en la esquina superior izquierda de la pantalla, reservar

reas especficas de pantalla para diferentes tipos de informacin (como, por

ejemplo, mandatos, mensajes de error, ttulos y campos de datos, de forma queesta consistencia se mantenga en todas las pantallas) y proporcionar una

composicin que guste visualmente (es decir, que est balanceada, sea

simtrica, sea predecible, secuencial, simple, con agrupamientos, etc.).

Saber qu informacin situar en la pantalla. Para ello, hay que poner slo lainformacin que es esencial para la toma de una decisin o para la ejecucin de

una accin (No inundar al usuario con informacin!) y poner todos los datos

relacionados con una tarea en una nica pantalla (as el usuario no tiene que

recordar datos de una pantalla a otra).

Saber cmo situar la informacin en la pantalla. As, en cuanto a las fuentesde letras, se recomienda utilizar minsculas para el texto con la letra inicial de la

frase en maysculas; para las etiquetas, encabezamientos o subttulos utilizar

maysculas. En cuanto a las palabras, se recomienda no usar jerga, sino utilizar

palabras cortas, familiares, etc.

La interfaz de entrada debe recoger todos los datos necesarios, sinintroducir errores, para el sistema. De esta forma, la interfaz contiene unaproteccin contra errores de entrada. As mismo, tambin debe recoger los datos

minimizando el nmero de teclas pulsadas por el usuario. Las entradas deben

estar bien estructuradas y ser fciles de comprender y utilizar. Se deben usar

nombres precisos y permitir abreviaturas cuando se necesiten introducciones

rpidas de datos.

Se deben evitar las entradas repetitivas . Igualmente, el diseo de la salidaasegura que se extraen todos los datos suministrados por el sistema y que esas

salidas estn estructuradas de forma que sean fciles de leer.

El color aade una nueva dimensin a la facilidad de uso de la pantalla, yaque atrae la atencin del usuario. Si se utiliza de forma adecuada, puederesaltar la organizacin lgica de una pantalla, facilitar la separacin de

componentes y acentuar las diferencias. Por el contrario, si se usa

inadecuadamente, puede distraer y fatigar la visin debilitando la facilidad de uso

del sistema. Por ejemplo, en las pantallas grficas se recomienda no utilizar ms

de seis colores a la vez, evitar colores extremos (rojo y azul, amarillo y prpura),

evitar colores que no tengan contraste (blanco y amarillo, rojos, azules).


9/14


72

Existen tres enfoques principales para el diseo de casos:

1. El enfoque estructural o de caja blanca . Consiste en centrarse en laestructura interna (implementacin) del programa para elegir los casos

de prueba. En este caso, la prueba ideal (exhaustiva) del software

consistira en probar todos los posibles caminos de ejecucin, a travs

de las instrucciones del cdigo, que puedan trazarse.

2. El enfoque funcional o de caja negra . Consiste en estudiar laespecificacin de las funciones, la entrada y la salida para derivar los

casos. Aqu, la prueba ideal del software consistira en probar todas las

posibles entradas y salidas del programa.

3. El enfoque aleatorio consiste en utilizar modelos (en muchas ocasionesestadsticos) que representen las posibles entradas al programa paracrear a partir de ellos los casos de prueba. La prueba exhaustiva

consistira en probar todas las posibles entradas al programa.

Estos enfoques no son excluyentes entre s, ya que se pueden combinar para

conseguir una deteccin de defectos ms eficaz. Veremos a continuacin una

presentacin de cada uno de ellos.

4.3.1 REGLAS EN EL DISEO DE INTERFAZ DE USUARIO

PRINCIPIOS A SEGUIR EN EL DESARROLLO DE INTERFACES DE USUARIO:

A) Dar control al usuario

B) Reducir la carga de memoria del usuario

C) Consistencia

Dar control al usuario

Permitir a los usuarios utilizar teclado o ratn.

Permitir al usuario interrumpir su tarea y continuarla ms tarde.

Utilizar mensajes y textos descriptivos.

Permitir deshacer las acciones, e informar de sus resultados.

Permitir una cmoda navegacin dentro del producto y una fcil salida del

mismo.


10/14


73

Permitir distintos niveles de uso del producto para usuarios con distintos niveles

de experiencia.

Hacer transparente la interfaz del usuario (este debe creer que trabaja

directamente con los objetos).

Permitir al usuario personalizar la interfaz.

Permitir al usuario manipular directamente los objetos de la interfaz.

El usuario debe sentir que tiene el control del sistema.

Reducir la carga de memoria del usuario

9 Aliviar carga memoria corto plazo (deshacer, copiar y pegar, mantener los

ltimos datos introducidos).

9 Reconocimiento antes que recuerdo (elegir de listas mejor que teclear).9 Dar indicaciones visuales de donde est el usuario, que est haciendo y que

puede hacer a continuacin9 Proporcionar funciones de deshacer, rehacer y acciones por defecto..9 Proporcionar atajos de teclado (iniciales en mens, teclas rpidas).

9 Asociar acciones a los objetos (men contextual). 9 Utilizar metforas del mundo real (sistema telefnico, agenda).

Iconos de Lotus Organizer

Ejemplo de mala metfora

Metfora de la agenda


11/14


74

9 Presentar al usuario solo la informacin que necesita.9 Hacer la presentacin visual clara (colocacin/agrupacin de objetos, excesiva

informacin, ...).

Ejemplo de mal (izquierda) y buen diseo (derecha)

Consistencia Permite al usuario utilizar conocimiento adquirido en otros programas

consistentes (P .e. Mostrar siempre el mismo mensaje ante un mismo tipo de

situacin aunque se produzca en distintos lugares). Consistencia en la realizacin de tareas: proporcionar al usuario indicaciones

sobre el proceso que esta siguiendo. Consistencia dentro de un producto y de un producto a otro.

Presentacin

Comportamiento

Interaccin Ejemplo consistencia en la mejora de la interfaz: Botones de las ventanas de

Windows (3.11 y 95/98). Consistencia en los resultados de las acciones: misma respuesta ante misma

accin. Consistencia en la apariencia esttica (iconos, fuentes, colores, distribucin de

pantallas, ...) Fomentar la libre exploracin de la interfaz, sin miedo a consecuencias

negativas.


12/14


75

4.3.2 INTEGRACION DE LA INTERFAZ AL CASO DE USOAunque se han propuesto modelos diferentes para el diseo de la interfaz de usuario

(Por ejemplo, NOR86, NIE00), todos sugieren alguna combinacin de los siguientes

pasos:

1.- Con base en la informacin desarrollada durante el anlisis de la informacin, definir

los objetos y las acciones de la interfaz (operaciones).

2.- Definir eventos (acciones del usuario) que cambiarn el estado de la interfaz Modelar

este comportamiento.

3.- Representar cada estado de la interfaz tal como lo vera el usuario final.

4.- Indicar como interpreta el usuario el estado del sistema a partir de la interfaz

proporcionada mediante la interfaz.

En algunos casos, el diseador de la interfaz puede empezar con borradores de cada

estado de la interfaz (es decir, el aspecto de la interfaz en distintas circunstancias) y

luego trabajar hacia atrs para definir objetos, acciones y otra informacin importante

para el diseo. Independientemente de la secuencia de las tareas del diseo, ste debe:

A) Seguir siempre las reglas de oro analizadas.

B) Modelar la manera en que se implementar la interfaz

C) Tomar en cuenta el entorno (por ejemplo, la tecnologa de despliegue, el

sistema operativo, las herramientas de desarrollo) en que habr de

usarse.

APLICACIN DE LOS PASOS DEL DISEO DE LA INTERFAZ

Un paso importante en el diseo de la interfaz es la definicin de los objetos que esta

tendr y las acciones que se les aplicarn. Para realizarlo se analizan los casos de uso.

Es decir, se escribe una descripcin de un caso de uso. Luego se aslan los nombres

(objetos) y los verbos (acciones) para crear una lista de objetos y acciones.

Una vez definidos los objetos y las acciones, que se han elaborado de manera iterativa,

se organizan por tipo. Se identifican objetos de destino, origen y aplicacin. Un objeto

origen (como el icono de un informe) se arrastra y coloca en un objeto de destino (por

ejemplo, un icono de impresora). La implicacin de esta accin es crear un informe

impreso. Un objeto de aplicacin representa datos especficos de la aplicacin que n ose

manipulan directamente como parte de la interaccin con la pantalla. Por ejemplo, en

una lista de correo se almacenan nombres para un envo de correspondencia.


13/14


76

La propia lista podra ordenarse, combinarse o purgarse (acciones de men), pero no

arrastrarse ni colocarse mediante interaccin del usuario. Una vez que el diseador

queda satisfecho con un objeto importante y que se han definido las acciones (para una

iteracin de diseo) se realiza el formato de la pantalla. Como otras actividades de

diseo de la interfaz, el formato de la pantalla es un proceso interactivo; en el se elabora

el diseo grfico y se colocan los iconos, la definicin de texto descriptivo en pantalla, la

especificacin y la asignacin de nombres a las ventanas, adems de la definicin de los

elementos primarios y secundarios de los mens. Si un metfora de la realidad es

apropiada para la aplicacin, se especifica en este momento, y el diseo se organiza de

manera tal que satisfaga la metfora. A continuacin se presenta un caso de estudio

preliminar (escrito por el propietario) para la interfaz.

Caso de uso preliminar: Quiero tener acceso a mi sistema HogarSeguro desdecualquier lugar remoto va internet. Empleando software de navegador que opera en mi

notebook (mientras estoy trabajando o viajando) puedo determinar el estado del sistema

de alarmas, armar o desarmar el sistema, reconfigurar zonas de seguridad y ver

diferentes habitaciones de la casa con las cmaras de video preinstaladas.

Para tener acceso a HogarSeguro desde un lugar remoto proporciono una

identificacin y una contrasea. Estos elementos definen los niveles de acceso (por

ejemplo, no todos los usuarios pueden reconfigurar el sistema ni proporcionarseguridad). Una vez validado, puedo revisar el estatus del sistema y cambiarlo al armar o

desarmar HogarSeguro. Puedo reconfigurar el sistema al desplegar un plano de la casa,

ver cada uno de los sensores de seguridad, desplegar cada zona configurada

actualmente y modificar zonas de acuerdo con las necesidades. Puedo ver el interior de

la casa con las cmaras de video colocadas de manera estratgica. Puedo hacer

acercamientos y desplazamientos con las cmaras para proporcionar diferentes vistas

del interior.

Con base en este caso de uso se identifican las tareas del propietario, los

objetos y los elementos siguientes:

Tiene acceso al sistema HogarSeguro Ingresa un IDy una contrasea para acceso remoto Revisa el estatus del sistema Arma o desarma el sistema HogarSeguro Despliega el plano de la casa y las ubicaciones de los sensores Despliega zonas en el plano de la casa

Cambia zonas en el plano de la casa


14/14


77

Despliega ubicaciones de las cmaras de video o el plano de la casa Selecciona visualmente una cmara de video Ve imgenes de video Desplaza o acerca las cmaras de video

Los objetos (en negritas) y las acciones (en cursivas) se extraen de la lista de

tareas del propietario. La mayor parte de los objetos indicados son objetos de la

aplicacin. Sin embargo, ubicacin de las cmaras de video (un objeto de origen)se arrastra y coloca en cmara de video (un objeto de destino) para crear unaimagen de video (una ventana que contiene el desplegu de video).

Se crea un boceto preliminar del formato de la pantalla para el monitoreo de

video. La imagen de video se solicita seleccionando un icono de ubicacin de las

cmaras de video, C, localizado en el plano de la casa desplegado en la ventana de

monitoreo. En este caso, se arrastra la ubicacin de una cmara de video en la sala,

SA, y se coloca sobre el icono de cmara de video ubicado en la parte superior

izquierda de la pantalla. Aparecer la ventana de imagen de video, desplegando

video de flujo continuo proveniente de la cmara ubicada en la sala (SA). Los

controles deslizables de acercamiento y desplazamiento se emplean para controlar

la ampliacin y la direccin de la imagen del video. Para seleccionar una vista deotra cmara, el usuario simplemente arrastra y coloca un icono de ubicacin de

cmara diferente en el icono de la cmara emplazado en la esquina superior

izquierda de la pantalla.

El boceto del formato que se muestra tendra que complementarse con una

expansin de cada elemento de men dentro de la barra de mens, indicando cuales

acciones estn disponibles para el modo de monitoreo de video (estado). Durante la

etapa de diseo de la interfaz se creara un conjunto completo de bocetos para cada

tarea de propietario anotada en el escenario del usuario.

Documents

Unlock Unidad 4 de Planificacion y Modelado