Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.1 Ingeniería de...

Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas. 1

Ingeniería de Requerimientos

El Contexto de los Requerimientos


Temario

• Espacio del producto.

• Los casos de uso.

• Análisis de la empresa y su entorno.

• Diagramas de actividad.

• El Documento de Concepto de Operaciones.


Temario

Espacio del producto.

• Los casos de uso.





Espacio del Producto• Definición.

– Rango de soluciones del problema que cumplen todas las restricciones.

• Fuentes de restricciones.– Usuarios (quien usa el producto).– Clientes (quien paga por el producto).– Constructor.– Tecnología.– Leyes y disposiciones gubernamentales.– Estándares, etc.


Restricciones del Usuario

• Usuario: quien usa el sistema.

• Factores a considerar:– Funcionalidad.– Tiempo de respuesta.– Diálogo hombre-máquina.– Confiabilidad.– Etc.


Restricciones del Cliente

• Cliente: quien paga por el sistema.• Factores:

– Funcionalidad.

– Tiempo de respuesta.

– Diálogo hombre-máquina.

– Confiabilidad.

– Tiempo de desarrollo.

– Costo.

– Mantenibilidad.


Restricciones del Constructor• Constructor: políticas de una software house.• Factores:

– Costos.

– Calidad.

– Mantenibilidad.

– Modificabilidad.

– Reuso.

– Etc.


Restricciones de Tecnología

• Factores:– Capacidad de procesadores.– Sistemas operativos.– Compiladores.– Manejadores de datos.– Migración de viejos sistemas.


Restricciones gubernamentales

• Ejemplos:– Tipos de IVA y formas de cálculo.– Forma de liquidación de haberes.– Historia laboral.


Otras restricciones

• Estándares (documentos de especificación, diseño, etc.).

• Contratos.

• Servicios (mantenimiento, etc.).

• Etc.


Espacio del Productono

si

no

si

no

si

si

no

no

si p1 p2p3


Temario

Espacio del producto.Los casos de uso.





• Definición.– “Secuencia de transacciones en un sistema cuyas

tareas generan un resultado de valor medible para un actor individual del sistema.” Jacobson.

– Transacciones = actividades.

– Sistema: computarizado o no.

– Actor: cualquier individuo humano o no humano.

• Representación Gráfica.

Caso de Uso

ACTOR CASO DE USORELACIONAMIENTO


Caso de Uso (cont.)

• Descripción textual.– Nombre que lo identifica.

– Lista de actores que participan en el caso de uso.

– Curso de acciones: descripción del conjunto de actividades que delinean el curso de eventos del caso de uso.


Un ej. de Caso de Uso• Nombre: Retiro de caja de ahorro.

• Lista de actores: Cliente.

• Curso.1. El cliente busca la primera caja libre para realizar un retiro.

2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.

3. Posteriormente, el cajero solicita el monto del retiro.

4. El cajero solicita al sector cajas de ahorros el saldo.

5. El cajero entrega el dinero al cliente.

6. El cliente cuenta el dinero.

7. El cliente se retira.


Ej. Diagrama del Caso de Uso

Retiro deCaja deAhorro

Cliente


Otro ej. de Caso de Uso

• Nombre: Depósito de caja de ahorro.

• Lista de actores: Cliente.

• Curso.1. El cliente busca la primera caja libre para realizar un depósito.

2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.

3. Posteriormente, el cajero solicita el monto del depósito.

4. El cajero toma el dinero del cliente.

5. El cajero entrega el comprobante del depósito al cliente.

6. El cliente se retira.


Ej. Diagrama del Caso de Uso

Depósito deCaja deAhorro

Cliente


Modelo de Casos de Uso

Depósito deCaja deAhorro

Cliente

Retiro deCaja deAhorro

SISTEMA/EMPRESA


Caso de Uso Completo

• Descripción textual.– Nombre que lo identifica.

– Lista de actores que participan en el caso de uso.

– Curso básico: descripción del conjunto de actividades que delinean el curso natural de eventos del caso de uso.

– Curso alternativo: descripción del conjunto de actividades alternativas si alguno de los eventos del curso básico no se puede cumplir. Manejo de excepciones.


Un ej. de Caso de Uso• Nombre: Retiro de caja de ahorro.• Lista de actores: Cliente.• Curso básico.

– 1. El cliente busca la primera caja libre para realizar un retiro.– 2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.– 3. Posteriormente, el cajero solicita el monto del retiro.– 4. El cajero solicita al sector cajas de ahorros el saldo.– 5. El cajero entrega el dinero al cliente.– 6. El cliente cuenta el dinero.– 7. El cliente se retira.

• Curso alternativo.– 1. Si no existe una caja libre, espera y retorna al punto 1. del curso básico o finaliza el caso de uso.– 2. Si el nro. de cuenta es incorrecto, se retorna al punto 2. del curso básico o finaliza el caso de uso.– 4. Si el monto del retiro supera el saldo, el cajero le comunica al cliente y se retorna al punto 3. del

curso básico o finaliza el caso de uso.– 5. Si el cajero no tiene fondos suficientes, solicita dinero a otro cajero.– 6. Si monto entregado no es correcto, retorna al punto 5. del curso básico.


El Modelo de Objetos

• Es el modelo interno del negocio.

• Describe la secuencia de transacciones de un caso de uso.

• Describe como son, como se ejecutan y por quien los procesos del negocio para obtener un resultado medible para un actor.

• Se basa en la teoría de objetos.


El Modelo de Objetos (Cont.)

• Los objetos encapsulan conocimiento y comportamiento.

• Representan cosas, roles, productos y tareas en el curso de eventos de un caso de uso.

• Entre ellos manejan diferentes tipos de relaciones: herencia, agregación / composición, comunicación y dependencia.


El Modelo de Objetos (Cont.)• Existen objetos de tres tipos:

– de Interfaz: representan roles o tareas que se comunican con el mundo exterior (actores).

– de Control: representan roles o tareas internas.

– de Entidad: representan cosas o productos internos.

• Representación gráfica de los 3 tipos:

OBJETOS DE INTERFAZ OBJETOS DE CONTROL OBJETOS DE ENTIDAD


Ejemplo de Modelo de Objetos

Cajero

Otro Cajero

Caja

Otra Caja

Ficha de Caja de Ahorro

Sector Cajas de AhorrosCLIENTE


Modelo de Objetos Reformulado

Cajero

Otro Cajero

Caja

Otra Caja

Cuenta

ComputadoraCLIENTE


Caso de Uso Reformulado• Nombre: Retiro de caja de ahorro.• Lista de actores: Cliente.• Curso básico.

– 1. El cliente busca la primera caja libre para realizar un retiro.– 2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.– 3. Posteriormente, el cajero solicita el monto del retiro.– 4. El cajero realiza la transacción en la computadora.– 5. El cajero entrega el dinero al cliente.– 6. El cliente cuenta el dinero.– 7. El cliente se retira.

• Curso alternativo.– 1. Si no existe una caja libre, espera y retorna al punto 1. del curso básico o finaliza el caso de uso.– 2. Si el nro. de cuenta es incorrecto, se retorna al punto 2. del curso básico o finaliza el caso de uso.– 4. Si el monto del retiro supera el saldo, el cajero le comunica al cliente y se retorna al punto 3. del

curso básico o finaliza el caso de uso.– 5. Si el cajero no tiene fondos suficientes, solicita dinero a otro cajero.– 6. Si monto entregado no es correcto, retorna al punto 5. del curso básico.


Modelo de Casos de Uso del Software

Retiro

DepósitoCajero


Un ej. de Caso de Uso del Software

• Nombre: Retiro de caja de ahorro.

• Lista de actores: Cajero.

• Curso básico.

– 1. El cajero ingresa el nro. de cuenta, el sistema verifica que exista.

– 2. El cajero ingresa el monto del retiro, el sistema verifica que sea correcto.

• Curso alternativo.

– 1. Si el nro. de cuenta es incorrecto, se retorna al punto 1. del curso básico o finaliza el caso de uso.

– 2. Si el monto ingresado no es correcto, retorna al punto 2. del curso básico o finaliza el caso de uso.


Caso de Uso Integrado• Nombre: Transacción sobre una cuenta.• Lista de actores: Cajero.• Curso básico.

– 1. El cajero ingresa el nro. de cuenta. El sistema verifica el nro. de cuenta, identificando a que cliente pertenece y a que producto pertenece, desplegando estos datos en pantalla.

– 2. Si el producto es una cuenta corriente, seguir el caso de uso de transacciones sobre cuenta corriente.

– 3. Si el producto es una caja de ahorro, seguir el caso de uso de transacciones sobre caja de ahorro.– 4. Si el producto es una cuenta de plazo fijo, seguir el caso de uso de transacciones sobre cuenta de

plazo fijo.– 5. Si el producto es un vale amortizable, seguir el caso de uso de transacciones sobre vale

amortizable.– 6. El sistema emite por impresora el comprobante y finaliza el caso de uso.

• Curso alternativo.– 1. Si el nro. de cuenta no existe, el sistema envía mensaje y se retorna al punto 1. del curso básico.– 6. Si la impresora no responde, el sistema envía mensaje y se retorna al punto 6. del curso básico o

al punto 1.


Transacción sobre una Cuenta

Caso de Uso Integrado

T. sobreCta. Cte.

T. sobreCaja Ahorro

T. sobrePlazo Fijo

T. sobreVale A.

Cajero

compuesto por


Transacción sobre Cta. Cte.

• Nombre: Transacción sobre una Cuenta Corriente.


• Curso básico.

– 1. El cajero selecciona, de la lista de operaciones (depósito, cobro de cheque, retiro en mostrador, etc.), la operación que desea realizar.

– 2. El el cajero ingresa el monto de la operación, el sistema verifica que esté correcto según el tipo de operación.

– 3. Finaliza el caso de uso.

• Curso alternativo.

– 2. Si el monto no es correcto, el sistema envía mensaje al cajero y se retorna el punto 2 del curso básico o finaliza el caso de uso.


Caso de Uso Integrado (Conversacional)

• Nombre: Transacción sobre una cuenta.


• Curso básico.

– Cajero: ingresa el nro. de cuenta.

– Sistema: verifica el nro. de cuenta [alternativa: Cuenta no existe], identificando a cliente pertenece y a que producto pertenece, desplegando estos datos en pantalla.

Si el producto es una cuenta corriente, sigue el caso de uso de transacciones sobre cuenta corriente. Si el producto es una caja de ahorro, sigue el caso de uso de transacciones sobre caja de ahorro. Si el producto es una cuenta de plazo fijo, sigue el caso de uso de transacciones sobre cuenta de plazo fijo. Si el producto es un vale amortizable, sigue el caso de uso de transacciones sobre vale amortizable.


Caso de Uso Integrado (Conversacional)

– Sistema:[Imprimir].Emite por impresora el comprobante[alternativa: Impresora no responde] y

finaliza el caso de uso.• Curso alternativo.

[Cuenta no existe].Sistema: envía mensaje, espera ACEPTAR.Cajero: oprime ACEPTAR.Sistema: reinicia curso básico.[Impresora no responde].Sistema: envía mensaje, espera REINTENTAR, CANCELAR.Cajero: clickea REINTENTAR o CANCELAR.Sistema:

Si clickeó REINTENTAR, va a [Imprimir].Si clickeó CANCELAR, reinicia el curso básico.


Caso de Uso Integrado (SDL)

ingresa cuenta (Nro_Cuenta)en espera

es correcta la cuenta

en impresión

SI NOdespliega error

reinicia y espera

impresora no respondeREINTENTAR, CANCELAR

en esperaselecciona (opción)

imprimir?

SIreinicia y espera

NO

terminó de imprimirreinicia y espera

estímulo respuestaestado alternativatareaSIMBOLOS:

CC CA PF VA

SDL: Specification and Description Language


Ejemplo de Caso de Uso con WORD• Nombre: Edición de archivo NUEVO con WORD.• Lista de actores: Usuario.• Precondición:• Curso básico.

– 1. El usuario clickea en el ícono de WORD. WORD se abre y se pone en modo de edición .– 2. WORD espera comando.– 3. Si el usuario digitó una tecla de caracteres válidos, WORD lo escribe y retorna al punto 2 del curso

básico.– 4. Si el usuario movió el mouse, WORD desplaza el puntero hacia la región de pantalla y retorna al

punto 2 del curso básico.– 5. Si el usuario clickeó sobre un ícono de la barra de herramientas, WORD ejecuta la acción asociada

y retorna al punto 2 del curso básico.– 6. Si el usuario clickeó dos veces sobre el menú de control, WORD se cierra y finaliza el caso de uso.

• Curso alternativo.– 1. Si la memoria no es suficiente, WORD avisa y finaliza el caso de uso.– 6. Si WORD detecta que el archivo no fue salvado, avisa al usuario. Si este eligió salvar, WORD

guarda el archivo en disco. Finaliza el caso de uso.• Poscondición:

– El Administrador de Programas retoma el comando.


LOGINCaso de uso: Ingreso al sistema.

Descripción: establecimiento de sesión (login).

Actores: todos los actores humanos.

Precondición:

Poscondición: la conexión se deshabilita. Ningún usuario puede entrar nuevamente sin su contraseña.

Especificación:

Curso básico.1. Al cargar el sistema se establece la conexión y se presenta la pantalla de ingreso al sistema.2. El usuario deberá digitar su identificación y su contraseña. 3. Seguidamente el usuario podrá presionar el botón ACEPTAR o CERRAR.4. Al presionar el botón ACEPTAR el sistema verificará la autenticidad de la identificación y la contraseña.

Si son válidos se inicia la sesión. El inicio de sesión implica desplegar el menú principal con la lista de servicios habilitados para ese usuario, lo cual determinará su perfil.

5. Al presionar el botón CERRAR finaliza el caso de uso.

Curso alternativo.

1. Si no se puede establecer conexión el sistema notificará al usuario.

4. Si la identificación de usuario o la contraseña no son válidas, el sistema desplegará mensaje de error y hará pedido de reintento. Al tercer reintento fallido se finalizará la conexión. Si la contraseña esta próxima a expirar (SE DEBERA DETERMINAR UN PERIODO PARA ESTO), el usuario será notificado. Si la contraseña expiró corre el caso de uso Cambio de contraseña.


LOGIN (Cont.)Pantallas.

P14.


Ej. de Caso de Uso de ImpresiónCaso de uso 50: Emisión de Recibos.

Curso básico.

1. El usuario seleccionará la lista de Recibos a emitir, según lo especificado en el caso de uso 51: Selección de Recibos.

2. A continuación el sistema presentará cuadro de diálogo para permitir realizar la emisión por pantalla, impresora o a disco.

3. Luego de seleccionada la opción, el sistema emitirá la lista seleccionada de recibos en formulario preimpreso. El orden de la emisión será por Cobrador y para cada Cobrador, por Ubicación en la Ruta en el caso de Personas Físicas, y por Grupo de Cobro en el caso de Personas Jurídicas.

Para cada recibo el sistema irá contando la cantidad de veces que fue emitido, indicando quien, cuando, etc. insertando un registro en la tabla historia_recibo.

4. Posteriormente se procederá al corte y entrega de Recibos.

Curso alternativo.

2. a. Si al disparar una emisión, el sistema detecta que esta ya fue efectuada anteriormente, le notificará esta situación al usuario y finalizará el proceso (mensaje: no hay ningún recibo a emitir).

b. En el caso que se trate de una emisión no haya sido concluida por alguna razón, el sistema la retomará a partir del punto en que se dejó, y emitirá solo los recibos faltantes.

3. Si en algún momento el sistema detecta que el dispositivo de salida no responde (impresora o disco) presentará un cuadro de diálogo para reintentar o cancelar. Si el usuario elige reintentar se retoma este caso de uso desde el punto 3 del curso básico. Si el usuario elige cancelar, finaliza el caso de uso (proceso).

Ej. de Caso de Uso de Impresión (Cont.)Caso de uso 51: Selección de Recibos.

Curso básico.

1. El usuario le indicará al sistema si desea trabajar con una consulta ya catalogada o si desea crear una nueva.

2. Si desea trabajar con una consulta ya catalogada la podrá leer de disco y adaptarla.

3. Si desea crear una nueva, tendrá la posibilidad de seleccionar para cada Cobrador, cuales Convenios desea emitir, para cada Convenio, cuales Grupos de Cobro, y para cada Grupo de Cobro cuales recibos.

4. El usuario podrá navegar en los cuatro niveles de la consulta (cobradores, convenios, grupos de cobro y recibos) seleccionando ítems. Considérese que en los cuatro niveles los ítems habilitados son aquellos para los cuales el atributo emite_recibo está en TRUE.

Navegación hacia adelante: cada vez que el usuario seleccione un ítem de mayor nivel el sistema seleccionará todos los ítems de menor nivel.

Navegación hacia atrás: cada vez que el usuario seleccione un ítem de menor nivel el sistema seleccionará el ítem correspondiente de mayor nivel.

Enlazar: cuando el usuario se posicione en uno de los niveles, y presione un botón (lazo) el sistema seleccionará todos los ítems de ese nivel (considerando las navegaciones en el sentido que corresponda). Además de enlazar el usuario tendrá las opciones de selección (marcado/desmarcado) según el estándar de Windows.

Cuando el usuario este posicionado en el nivel de recibos, el sistema mostrará la lista por defecto: solo los recibos a emitir de la última emisión.

5. Seguidamente el sistema le preguntará si desea guardar la consulta para utilizarla posteriormente. Si el usuario responde afirmativamente, el sistema permitirá catalogar la consulta (si no existe) y la guardará.

Curso alternativo.

4. Cuando el usuario este posicionado en el nivel de recibos, si el usuario desea seleccionar recibos ya emitidos, el sistema proporcionará las siguientes tres opciones: lista de recibos a emitir (ya considerada en el curso básico), o lista de recibos ya emitidos, o lista con todos los recibos. En cualquier caso el usuario podrá filtrar los recibos por mes.

En cualesquiera de las tres situaciones el sistema deberá hacer explícito la opción que eligió el usuario.

Para que pueda trabajar con cualesquiera de las listas mencionadas en las dos últimas situaciones el sistema pedirá clave de acceso (esto es válido solo para le emisión de recibos y no para la emisión del resumen de recibos).


Creación del Modelo de Casos de Uso• 1) Delimitar el alcance del sistema.

– Identificar las entidades externas que interactúan con el sistema.

– Identificar, para cada entidad, estímulos y respuestas del sistema.

• 2) Clasificar actores.– Identificar los roles de las entidades externas e identificarlas

con un actor.– Denominar a los actores.– Establecer el propósito de cada actor frente al sistema.– Identificar los actores primarios y secundarios.


Creación del Modelo de Casos de Uso (Cont.)

• 3) Identificar los casos de uso.– Determinar, para cada actor, las distintas formas en que

usa el sistema, a partir de los estímulos y las respuestas.• 4) Priorizar los casos de uso.

– Considerar primero los actores primarios y luego los secundarios.

– Considerar luego los que presentan mayores dificultades.– Considerar los que se pueden resolver fácil y rápidamente.– Considerar los restantes.



• 5) Identificar escenarios para los casos de uso.

– Especificar escenarios (instancias del caso de uso) para cada caso de uso.

– Estos escenarios deben ser ejemplos concretos y no generales.

– La generalización se debe postergar.

• 6) Determinar la secuencia de interacción.

– Para cada caso de uso, determinar cual es el actor que “dispara” el caso de uso.

– Determinar pre y poscondiciones.



• 7) Escribir cursos básicos.– Aplicar “Pareto”.

• 8) Agregar las alternativas.• 9) Refinar los casos de uso.

– Aplicar primitivas de análisis.– Abstraer.

• 10) Construir el modelo de objetos.


Casos de Uso: Problema vs. Producto

• Definir los casos de uso del negocio.• Definir el modelo de objetos del negocio.• Identificar áreas a informatizar.• Convertir el modelo de objetos del negocio en

modelo de casos de uso del sistema.– Cada objeto de interfaz del modelo de objetos del

negocio, convertirlo en actor del modelo de casos de uso del sistema.

• Definir el modelo de objetos del sistema.


Ejercicio 1

• Realizar los puntos 1 al 6 del ejercicio de la universidad.


Temario

Espacio del producto.Los casos de uso.Análisis de la empresa y su entorno.




Diagrama contextual de la empresa

EMPRESA

CLIENTESPROVEEDORES

INSUMOS PRODUCTOS/SERVICIOS

AMBIENTE


Acotaciones al Diagrama contextual

• La empresa es vista como un sistema que: – Recibe insumos del actor proveedor.– Los procesa (transforma).– Genera productos y servicios para el actor

cliente.


Proceso Abstracto del Negocio


Administración y Control

• Proceso controlador de los otros procesos del ABP.

• Intercambia información con:– Otros procesos internos.

– Otros procesos fuera de la organización y ambiente general.

• Objetivos.– Definir metas y planes de los restantes procesos en el mismo ABP

(mismo nivel).

– Administrar y controlar esas metas y planes.


Mercadotecnia• Otro proceso controlador del ABP.• Intercambia información con:

– Mercado y clientes finales de la empresa (externos).

– Clientes del ABP (internos).

• Objetivos.– Monitoreo de los procesos básicos del ABP.

– Indicaciones de mejora de productos, actividades o tecnología de los procesos básicos.


Logística de Entrada• Es un proceso básico.

• Intercambia información, productos y servicios con:– Proveedores de la empresa (externos) y

– Proveedores del ABP (internos).

– Los otros procesos del ABP.

• Objetivos.– Recepción y almacenamiento de insumos.

– Administración de insumos.

– Selección y pagos a proveedores.

– Selección de políticas de compra.


Operaciones

• Es un proceso básico.

• Intercambia información, productos y servicios con:– Logística de entrada.– Logística de salida.

• Objetivos.– Transformar insumos en productos.


Ventas y Servicios

• Es un proceso básico.• Intercambia información, productos y servicios con:

– Clientes de la empresa (externos) ó– Clientes del ABP (internos).– Operaciones.– Logística de salida.

• Objetivos.– Venta de productos y servicios.– Recepción de pagos.– Mantenimiento y servicios posventa.– Planificación y directivas a logística de salida para entregas.


Logística de Salida

• Es un proceso básico.

• Intercambia información, productos y servicios con:– Clientes de la empresa (externos) ó

– Clientes del ABP (internos).

– Ventas y Servicios.

• Objetivos.– Recepcionar y almacenar productos terminados.

– Administrar productos terminados.

– Entregar productos terminados y servicios.


Casos de Uso Genéricos


Escenarios con Proveedores

• Registración del Proveedor (interface).

• Negociación con el Proveedor (interface).

• Recepción de productos/servicios (product).

• Evaluación del Proveedor.

• Pago al Proveedor (payment).

• Recepción de servicios posventa (service).


Escenarios con Clientes

• Registración del Cliente (interface).

• Negociación con el Cliente (interface).

• Entrega de productos/servicios (product).

• Evaluación del Cliente.

• Cobro al Cliente (payment).

• Brindar servicios posventa (service).


Escenarios de Mercadotecnia

• Monitoreo del mercado.

• Monitoreo de clientes finales.

• Monitoreo de otros procesos.


Escenarios de Administración y Control

• Recolección de información del ambiente.

• Distribución de información a restantes procesos.


Proceso Abstracto del Negocio

• El ABP abstrae los atributos y comportamiento esenciales de los procesos del negocio.

• Permite recursivamente modelar la empresa en sus distintos niveles.

• ABP puede ser considerada una clase abstracta.

• Es el punto de partida de la jerarquía de clases de la empresa.


Diagrama Contextual General de una Empresa

Cliente

Proveedor

Usuario

Cliente Potencial

Beta Usuario

Tercero

EMPRESA

Ambiente


Temario

Espacio del producto.Los casos de uso.Análisis de la empresa y su entorno.Diagramas de actividad.



Ejercicio 2

• Realizar el punto 7 del ejercicio de la universidad.


Diagramas de Actividad

• Diagrama de Actividad (notación UML).– Son diagramas que muestran el flujo secuencial (y/o

concurrente) de actividades para llevar a cabo un proceso u operación.

– Son útiles para representar procesos de negocio, flujos de trabajo, o modelar aspectos dinámicos de sistemas.


Actividad

• Representa conjuntos de tareas necesarios realizar para lograr un resultado.

• Cada actividad normalmente es seguida de otra actividad.

• Para representar estos conjuntos de tareas se utilizan estados de acción o de actividad.


Estados de Acción

• Representan la ejecución de una acción atómica.• No se pueden descomponer.• Ej.:

– calcular un total.

– Autorizar un documento. Autorizar


Estados de Actividad• Son estados que se pueden descomponer y representar en otro

diagrama de actividad.

• No son atómicos.

• Ej.:– Responder un llamado.

– Diseñar una solución.

• En un diagrama de actividad existe un estado inicial, y uno o más estados finales.

Responder Llamado

Inicial Final


Transiciones• Indican el camino entre un estado (de actividad o

acción) y el siguiente.• Cuando un estado de acción o de actividad termina, se

pasa inmediatamente al siguiente estado.

E1 E2


Transiciones (cont.)• Las transiciones pueden incluir condiciones [cond].

Atender llamado Respuesta rápida

Respuesta normal

[urgente]


Andariveles

• Permiten particionar las actividades de un diagrama en grupos, e indicar quién es responsable por las actividades.

• Cada andarivel debe tener un nombre.• Una actividad solo puede pertenecer a un

sólo andarivel.• Las transiciones pueden cruzar los

andariveles.


Encargar Producto

ProcesarOrden

Enviar Orden

Cliente Ventas Entregas



Caminos Concurrentes (o Concomitantes)

• Fork:– Permite dividir un flujo de control en dos o más

flujos concurrentes.

• Join:– Permite sincronizar dos o más flujos de control.



Completar Pedido

Facturar Preparar Embarque

Verificar Ítems

Entregar Pedido



Proceso

para

preparar

un café

[No hay café]

[No hay refrescos]


Flujo de Objetos

• En un diagrama de actividad es posible indicar objetos (documentos, registros, etc.) afectados por los estados.

• Se indica mediante una dependencia (flecha punteada) entre el estado y el objeto afectado.

• Se puede reflejar en el objeto su nombre, y cambios en su estado.– Se denota el estado entre [].



Encargar Producto

ProcesarOrden

Enviar Orden

Cliente Ventas Entregas

Orden[en proceso]

Orden[completada]


Recomendaciones• Para construir los diagramas es más sencillo si primero se

identifican los responsables y luego sus actividades.

• Si lo anterior no es posible, también resulta útil identificar grupos de actividades que están relacionadas.

• Si el diagrama resulta difícil de comprender considerar la posibilidad de utilizar estados de actividad para simplificarlo.

• Si existen conjuntos de actividades relacionadas que se repiten en varios diagramas, considerar la posibilidad de utilizar estados de actividad.

• Utilizar el menor número posible de objetos para que el diagrama quede claro.


Temario

Espacio del producto.Los casos de uso.Análisis de la empresa y su entorno.Diagramas de actividad.El Documento de Concepto de

Operaciones.


Ejercicio 3

• Realizar el punto 8 del ejercicio de la universidad.


Proceso Típico de Desarrollo

Análisis DiseñoImplementa-

ciónIng. Req.

ESRE ESDIFUENTES

+EXESESANNEUS

...

NEUS = Necesidades del Usuario (mercado)

ESRE = Especificación de Requerimientos

ESAN = Especificación de Análisis

ESDI = Especificación de Diseño


Problemas de un ESRE1) El cliente no esta de acuerdo con todas las necesidades del

usuario => conflicto de intereses.2) Falta de conocimiento del dominio por parte del constructor =>

distorsión de la comunicación.3) Los usuarios y clientes tienen dificultades para entender el ESRE

=> más distorsión de la comunicación.4) El ESRE especifica requerimientos del sistema (funciones,

eficiencia, restricciones de diseño, interfaces, atributos de calidad, etc.) pero no especifica las características del ambiente operativo del sistema.

• Consecuencias del GAP entre los requerimientos del cliente y las necesidades del usuario y la especificación de requerimientos.


Intentos de Solución• Métodos:

– Manual del usuario.

– Prototipo.

• Resuelven:– El entendimiento del ESRE por parte del usuario.(3).

• No resuelven:– Falta de entendimiento de las necesidades del usuario y

requerimientos del cliente (1, 2 y 4).

– Demostración del mapeo entre manual del usuario/prototipo y necesidades del usuario y requerimientos del cliente (1, 2 y 4).


Solución

• Análisis de Conceptos de Operaciones.

• Documento de Concepto de Operaciones.

– Cubre aspectos más generales del sistema y no

solamente del software.

– Información sobre el dominio del sistema.


Análisis de Conceptos de Operaciones

• Analizar un dominio y su ambiente operativo con el propósito de especificar las características de un sistema desde la perspectiva de los usuarios. [Fairley y Thayer].

• Objetivos.– Identificar usuarios.

– Necesidades de los usuarios.

– Identificar modos de operación del sistema (Mantenimiento, Emergencia, Respaldo, etc.).

– Identificar requerimientos del cliente (comprador).


Documento de Concepto de Operaciones

• Descripción de la situación actual (y el sistema si existe).

• Motivación del nuevo sistema o las modificaciones al existente.

• Modos de operación para el nuevo sistema.

• Clases y características de los usuarios.

• Características operativas.

• Escenarios de Operación para cada modo de operación y cada clase de usuario.

• Limitaciones del nuevo sistema.

• Análisis de Impacto.


Guía para Creación de un DCO

• Utilizar lenguaje del usuario y no lenguaje técnico.• Explicitar las necesidades del usuario sin

cuantificarlas (la cuantificación se realiza en el ESRE).

• Utilizar, en lo posible, herramientas gráficas.• Manejar un correcto nivel de detalle.• Valerse de algún estándar de especificación de

DCO.


Utilidades del DCO• Cuando el autor es el cliente.

– Para comunicar al constructor las necesidades de los usuarios.

• Cuando el autor es el usuario.– Para comunicar al cliente y al constructor las necesidades de los

usuarios.

• Cuando el autor es el desarrollador.– Para comunicar al cliente y usuarios la comprensión de sus

requerimientos/necesidades de los usuarios.

• Cuando los autores son el cliente y el usuario en forma separada.– Para llegar a un consenso en como deben ser las operaciones y luego

comunicárselo al desarrollador.


¿Cuándo usar un DCO?• Antes de adquirir un sistema o contratar el

desarrollo a un tercero.– El cliente y usuarios establecen requerimientos y

necesidades y realizan llamado, si es necesario.

• Antes de decidir desarrollar un sistema.– El cliente determina la oportunidad y dispara el desarrollo

o desiste.

• Antes de comenzar la fase de IR.– El constructor lo desarrolla para determinar con claridad

el ambiente del sistema.


Bibliografía• Capítulo 3, Requirements Engineering, Gerald Kotonya

and Ian Sommerville.

• Capítulo 1, Software Requirements: Objects, Functions and States, Alan Davis.

• Capítulos 5 y 7, The Object Advantage, Ivar Jacobson.

• The Abstract Business Process, Thornton Gale And James Eldred, Object Magazine, January 1997.

• The Concept of Operations, Capítulo 2, Software Requirements Engineering, Richard Thayer and Merlin Dorfman.

Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.1 Ingeniería de...

Documents

Transcript of Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.1 Ingeniería de...