Ingeniería de Requerimientos

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

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Espacio del Producto Definición. Fuentes de restricciones.
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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Restricciones del Usuario
Usuario: quien usa el sistema. Factores a considerar: Funcionalidad. Tiempo de respuesta. Diálogo hombre-máquina. Confiabilidad. Etc. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Restricciones del Constructor
Constructor: políticas de una software house. Factores: Costos. Calidad. Mantenibilidad. Modificabilidad. Reuso. Etc. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Restricciones de Tecnología
Factores: Capacidad de procesadores. Sistemas operativos. Compiladores. Manejadores de datos. Migración de viejos sistemas. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Restricciones gubernamentales
Ejemplos: Tipos de IVA y formas de cálculo. Forma de liquidación de haberes. Historia laboral. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Otras restricciones Estándares (documentos de especificación, diseño, etc.). Contratos. Servicios (mantenimiento, etc.). Etc. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Espacio del Producto no no no si si si p1 p2 p3 si si no no
Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Caso de Uso Definición. Representación Gráfica.
“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. ACTOR RELACIONAMIENTO CASO DE USO Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Ej. Diagrama del Caso de Uso
Retiro de Caja de Ahorro Cliente Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Ej. Diagrama del Caso de Uso
Depósito de Caja de Ahorro Cliente Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Modelo de Casos de Uso SISTEMA/EMPRESA Cliente Retiro de Caja de
Ahorro Depósito de Caja de Ahorro Cliente Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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 Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Ejemplo de Modelo de Objetos
Otro Cajero Cajero CLIENTE Sector Cajas de Ahorros Otra Caja Ficha de Caja de Ahorro Caja Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Modelo de Objetos Reformulado
Otro Cajero Cajero CLIENTE Computadora Otra Caja Cuenta Caja Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Modelo de Casos de Uso del Software
Retiro Depósito Cajero Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Caso de Uso Integrado Cajero compuesto por Transacción
sobre una Cuenta Cajero compuesto por T. sobre Cta. Cte. T. sobre Caja Ahorro T. sobre Plazo Fijo T. sobre Vale A. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Transacción sobre Cta. Cte.
Nombre: Transacción sobre una Cuenta Corriente. Lista de actores: Cajero. 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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Caso de Uso Integrado (Conversacional)
Nombre: Transacción sobre una cuenta. Lista de actores: Cajero. 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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Si clickeó REINTENTAR, va a [Imprimir]. Si clickeó CANCELAR, reinicia el curso básico. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Caso de Uso Integrado (SDL)
SDL: Specification and Description Language en espera ingresa cuenta (Nro_Cuenta) es correcta la cuenta NO SI despliega error CC CA PF VA reinicia y espera en impresión impresora no responde terminó de imprimir REINTENTAR, CANCELAR reinicia y espera en espera selecciona (opción) imprimir? NO SI reinicia y espera SIMBOLOS: estado estímulo respuesta tarea alternativa Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

LOGIN Caso 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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

LOGIN (Cont.) P14. Pantallas.
Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas. P14.

Ej. de Caso de Uso de Impresión
Caso 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). Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Ejercicio 1 Realizar los puntos 1 al 6 del ejercicio de la universidad. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Diagrama contextual de la empresa
AMBIENTE INSUMOS PRODUCTOS/SERVICIOS EMPRESA PROVEEDORES CLIENTES Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Casos de Uso Genéricos Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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). Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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). Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Escenarios de Mercadotecnia
Monitoreo del mercado. Monitoreo de clientes finales. Monitoreo de otros procesos. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Escenarios de Administración y Control
Recolección de información del ambiente. Distribución de información a restantes procesos. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Diagrama Contextual General de una Empresa
Cliente Proveedor Usuario Cliente Potencial Beta Usuario Tercero EMPRESA Ambiente Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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 Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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 Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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 Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Transiciones (cont.) Las transiciones pueden incluir condiciones [cond]. Atender llamado Respuesta rápida Respuesta normal [urgente] Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Encargar Producto Procesar Orden Enviar Orden Cliente Ventas Entregas Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Completar Pedido Facturar Preparar Embarque Verificar Ítems Entregar Pedido Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

[No hay café] Proceso para preparar un café [No hay refrescos] Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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 []. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Cliente Ventas Entregas Encargar Producto Orden [en proceso] Orden [completada] Procesar Orden Enviar Orden Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Ejercicio 3 Realizar el punto 8 del ejercicio de la universidad.

Proceso Típico de Desarrollo
Análisis Diseño Implementa- ción Ing. Req. ESRE ESDI FUENTES + EXES ESAN NEUS ... NEUS = Necesidades del Usuario (mercado) ESRE = Especificación de Requerimientos ESAN = Especificación de Análisis ESDI = Especificación de Diseño Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Problemas de un ESRE 1) 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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

Intentos de Solución Métodos: Resuelven: No resuelven:
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). Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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). Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

¿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. Ingeniería de Requerimientos. El contexto de los requerimientos. Alvaro Ortas.

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.

Ingeniería de Requerimientos

Presentaciones similares

Presentación del tema: "Ingeniería de Requerimientos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Requerimientos

Presentaciones similares

Presentación del tema: "Ingeniería de Requerimientos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback