ANALISIS Y DISEÑO DE SISTEMAS I

GUIA LABORATORIO 07: MODELO DE REQUERIMIENTOS

DOCENTE: ING. LUIS ALBERTO SOTA ORELLANAING. MONICA MARCA AIMAING. NOVA ACUÑA

SEMESTRE: 2011– II

1. MARCO TEORICO

Del modelo de negocios al modelo de requerimientos

Los actores del negocio son candidatos a ser actores en éste modelo. Los trabajadores del negocio también son candidatos a ser actores en éste

modelo.

¿Cuál es el Propósito de la captura de requerimientos?

El esfuerzo principal de este flujo es desarrollar un modelo del sistema que se va a construir y la utilización de los casos de uso en una forma adecuada para crear este modelo.

Es establecer un acuerdo con el cliente y usuarios en lo que el sistema debe hacer.

Permite definir los límites del sistema. Ayuda a entender al diseñador los requerimientos del sistema. Permite definir la interfaz de acuerdo a las necesidades y metas de los usuarios.

Trabajadores en la captura de requisitos

El analista de sistemas ejecuta la actividad de desarrollar modelos de casos de uso capturando todos los requisitos que son entradas del flujo de trabajo, es decir: la lista de características de los casos de uso, y también realiza el diagrama de clases de análisis.

El arquitecto identifica los casos de uso relevantes arquitectónicamente hablando, para proporcionar entradas a la priorización de los casos de uso.

Los especificadores de casos de uso describen todos los casos de uso priorizados.

Los diseñadores sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.

Pasos para realizar éste modelo

Definir a los actores candidatos: Serán extraídos del modelo de negocio. Debe ser creado en Use Case Model como paquete.Definir los casos de uso candidatos: Serán extraídos del modelo de negocio. Debe ser creado en Use Case Model como paquete.Obtener una lista de requerimientos candidatos llamada también lista de características: son los requerimientos candidatos que podemos elegir implementar en la versión actual o ha desarrollar en una versión futura.

La lista de características debe indicar:

a. El nombre del requerimiento que no es otra cosa que los CASOS DE USO funcionales,

b. Una explicación o descripción breve de dicho requerimiento, c. La prioridad (crítica, importante o accesoria),d. El nivel de riesgo asociado a la implementación (crítico, significativo u

ordinario),e. El estado (declarado, aprobado, incorporado o validado),f. El costo estimado de implementación (en términos de tipos de recursos y

horas hombre)(antes 150 soles y demora 3 horas y con el software costara 100 soles y demora 1 hora).

El glosario: es la captura de vocabulario común del sistema, y es importante definir con claridad los términos utilizados en el sistema de manera propia. Por ejemplo a lo mismo le pueden llamar de diferentes modos: item o producto o mercadería o artículo se pueden referir a lo mismo como no.

Realizar la descripción a detalle de los casos de uso identificados como prioritarios: Los especificadores de requerimientos o de casos de uso describen todos los casos de uso priorizados a detalle.

Realizar el prototipo de la interfaz de usuario: de acuerdo a los requerimientos capturados y el interés de los usuarios. Los diseñadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.

Obtener los casos de uso arquitecturalmente significativos: es un subconjunto de casos de uso que influyen fuertemente en la arquitectura. El arquitecto identifica los casos de uso relevantes arquitectónicamente hablando, para proporcionar entradas a la priorización de los casos de uso expresado en un diagrama de C.U

Revisar los requerimientos: El revisor de requerimientos es el encargado de revisar todos los artefactos producidos durante la captura de requisitos.

Diagrama de casos de uso

Un Diagrama de Casos de Uso representa lo que hace el sistema y como se relaciona con su entorno. Representa los distintos requerimientos que hacen los usuarios de un sistema. Un diagrama de casos de uso esta compuesto por:

Casos de uso. Actores. Relaciones entre ellos

Caso de Uso (Use Case) Es una secuencia de acciones realizadas por el sistema que producen un resultado observable y valioso para alguien en particular.

Nombre de caso de uso

Actor: Un actor es un conjunto externo uniforme de personas, sistemas, o cosas que solicita un servicio al sistema que estamos modelando.

Relaciones entre los elementos Relaciones entre actores La única relación permitida entre los actores es la Relación de Generalización.

El actor A hereda el comportamiento de B

Relaciones entre un actor y un caso de uso La única relación permitida es una Asociación y se le conoce como Relación de Comunicación o <<comunicates>>.

El actor A participa en el caso de uso

Relaciones entre casos de uso: Pueden ser de tres tipos:a. Relación de generalización: El Caso de Uso de A hereda la especificación del

Caso de Uso B.

Nombre

A B

ACaso de uso

<<communicate>>

BA

b. Relación <<include>>: El caso de uso A siempre incluye (o usa) el comportamiento de B.

c. Relación <<extend>>: El caso de uso B, extiende al caso de uso A. B ocurre en casos especiales para extender A.

2.

2. FLUJO DE TRABAJO

PRIMER PASO: DEFINIR LOS ACTORES CANDIDATOS

Los actores del negocio son candidatos a ser actores en éste modelo. Los trabajadores del negocio también son candidatos a ser actores en éste

modelo.

SEGUNDO PASO: DEFINIR LOS CASOS DE USO CANDIDATOS Según el procedimiento, las actividades del diagrama de proceso tienen el nivel

de granularidad adecuado para ser asociadas a un caso de uso del sistema. De esta manera, crearemos un caso de uso del sistema por cada actividad del diagrama de proceso que deba ser soportada por el sistema software. Por tanto, el rol que lleva a cabo la actividad será el actor principal del caso de uso. Nótese que, de acuerdo con la definición de caso de uso, no todas las actividades del diagrama de proceso serán consideradas como casos de uso, sino solamente aquellas que sean de valor para algún actor.

TERCER PASO: OBTENER UNA LISTA DE REQUERIMIENTOS CANDIDATOS.

Son los requerimientos candidatos que podemos elegir implementar en la versión actual o ha desarrollar en una versión futura.

La lista de características debe indicar: El nombre del requerimiento que no es otra cosa que los CASOS DE USO. Una explicación o descripción breve de dicho requerimiento. La prioridad (crítica, importante o accesoria). El nivel de riesgo asociado a la implementación (crítico, significativo u

ordinario). El estado (declarado, aprobado, incorporado o validado). El costo estimado de implementación (en términos de tipos de recursos y

horas hombre).

BA

<<include>>

BA

<<extend>>

CUARTO PASO: REALIZAR LA DESCRIPCION A DETALLE DE LOS CASOS DE USOS IDENTIFICADOS COMO PRIORITARIOS – FORMATO EXTENDIDO.

CASO DE USO DE ALTO NIVELNombre:

Actores:  

Propósito:

Resumen:  

La prioridad: crítica, importante o accesoria

Nivel de riesgo: crítico, significativo u ordinario

Estado: declarado, aprobado, incorporado o validado

CASO DE USO EXTENDIDO

Nombre:  

Actores:

Propósito:

Resumen:

Curso normal de los eventos

Acción de los actores Respuesta del Sistema

   

Cursos Alternos

 

QUINTO PASO: REALIZAR EL PROTOTIPO DE LA INTERFAZ DEL USUARIO.

De acuerdo a los requerimientos capturados y el interés de los usuarios. Los diseñadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.

SEXTO PASO: OBETENER LOS CASOS DE USO ARQUITECTURALMENTE SIGNIFICATIVOS.

Es un subconjunto de casos de uso que influyen fuertemente en la arquitectura. El arquitecto identifica los casos de uso relevantes (FUNCIONALES)arquitectónicamente hablando, para proporcionar entradas a la priorización de los casos de uso expresado en un diagrama de Casos de Uso.

SETIMO PASO: REVISAR LOS REQUERIMIENTOS.

El revisor de requerimientos es el encargado de revisar todos los artefactos producidos durante la captura de requisitos.

3. DESARROLLO DE LA PRACTICA

a. I ITERACIÓN DE LA FASE DE INICIO

i. DIAGRAMA DE CASOS DE USO DEL NEGOCIO DE LA FABRICA DE PRENDAS DEPORTIVAS WALON

ii. FORMATO DE DESCRIPCION DEL CASO DE USO DEL NEGOCIO

ii. DIAGRAMA DE ACTIVIDAD DEL CASO DE USO DEL NEGOCIO

iii. DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS

EJERCICIO:

1. MODELAR EL DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS DEL SISTEMA DE MATRICULAS DE LA UAC.