Levantamiento de requerimientos

Agenda Objetivos Conceptos Claves Metodología de Levantamiento Modelamiento de Procesos Casos de Uso Entregables y Criterios de Aceptación Bibliografía

Objetivos Conocer las reglas de juego que se tendrán para llevar a cabo el levantamiento de requerimientos Conocer el proceso metodológico que será utilizado para llevar a cabo el levantamiento de requerimientos en TC Conocer en detalle el proceso de especificación de requerimientos funcionales utilizando casos de uso Identificar las características principales de los casos de uso

Conceptos claves Proceso: Es un conjunto de pasos parcialmente ordenados que buscan alcanzar una meta u objetivo Disciplina: Es una colección de actividades interrelacionadas asociadas a un área específica de trabajo Flujo de Trabajo: Un flujo de trabajo es una secuencia de actividades que produce un resultado significativo y es observable Actividad: Una actividad es algo que un rol hace para proveer un resultado significativo dentro del contexto de un proyecto

Conceptos claves RUP: Rational Unified Process (Proceso Unificado de Desarrollo). Metodología que integra mejores prácticas para la ejecución de las diferentes etapas de un proceso de desarrollo Diagrama de proceso: Modelo de procesos; también diagrama de actividades del proceso Caso de uso: Un caso de uso es un artefacto cuyo objetivo principal es capturar el comportamiento del sistema, a través de una secuencia de acciones (flujo de trabajo), que desde la perspectiva del usuario final permiten alcanzar los objetivos deseados

Metodología de levantamiento

Metodología Reunión Preliminar Planeación del ciclo de levantamiento Cliente Analista Líder Analista Convenciones Roles Reunión de Lanzamiento

Metodología Presentaciones generales del negocio Revisar documentación Reunión de Lanzamiento El cliente tiene sus Procesos modelados ? Presentaciones generales del negocio NO SI Revisar documentación entregada por el cliente Documentación suficiente ? Recolectar documentación adicional SI Cliente Analista Líder Analista Convenciones Roles NO Solicitar documentación adicional

Metodología Elaboración y ajustes del documento de Visión Revisión Documento de Visión Revisión OK ? Aprobación Documento de Visión SI NO Documento aprobado ? Preparación agenda de entrevistas Cliente Analista Líder Analista Convenciones Roles SI Notificar compromiso a entrevistados Preparación y ejecución de entrevistas

Metodología Elaboración del modelo Solicitar entrevistas Preparación y Ejecución de Entrevistas Elaboración del modelo de proceso propuesto Solicitar entrevistas adicionales Identificación de Reglas de Negocio Identificación y elaboración del Glosario Cliente Analista Líder Analista Convenciones Roles

Metodología Aprobación Modelo de Procesos Revisión Artefactos Procesos OK ? Revisión OK ? NO SI NO Ajuste Artefactos de Proceso SI Aprobación Definición Preliminar del Alcance Definición Preliminar del Alcance Ajustes Definición Preliminar del Alcance Definición Preliminar OK ? Cliente Analista Líder Analista Convenciones Roles NO SI Planeación detallada de especificaciones Aprobación planeación detallada

Metodología Aprobar ajustes a la definición del alcance Aprobación planeación detallada Aprobar ajustes a la definición del alcance Refinar definición del alcance Crear relaciones de trazabilidad Aprobación casos de uso terminados Especificar casos de uso Especificar Reglas de Negocio Casos de uso aprobados ? NO Refinar Glosario SI Solicitar y ejecutar Sesiones de aclaraciones Elaborar arquitectura de casos de uso

Metodología Especificar requerimientos No funcionales Aprobación planeación detallada Especificar requerimientos No funcionales Elaborar y documentar Prototipo / StoryBoards Aprobación Artefactos de Requerimientos Revisión Artefactos de Requerimientos Ajustes Artefactos de Requerimientos NO Artefactos OK ? SI Artefactos OK ? NO Cliente Analista Líder Analista Convenciones Roles NO SI Cambios en los requerimientos ? SI Cerrar fase de requerimientos Procedimiento de Control de Cambios

Modelamiento de procesos

Elementos Estados Inicial y Final: Todo proceso debe tener un inicio y un fin. Los elementos Inicio no reciben ninguna entrada y los elementos Final no generan ninguna salida Actividad: Representa un paso atómico de un proceso Inicio Final Actividad

Elementos Enlace: Los enlaces se utilizan para representar la transición de un estado a otro y el paso de una actividad a otra Decisión: Se utiliza para representar caminos alternativos en el flujo del proceso. Tiene una única entrada y puede tener dos o más salidas. Por cada salida se tiene una expresión booleana que será evaluada al llegar a la bifurcación. Las condiciones deben ser excluyentes y se deben contemplar todos los posibles casos que se puedan generar Enlace

Elementos Fork / Join: Para representar las tareas concurrentes que pueden formar parte de un proceso se utiliza el elemento Fork. En el diagrama de ejemplo las actividades 2 y 3 se pueden ejecutar concurrentemente. El elemento Join se utiliza para representar la unión al flujo de control secuencial del proceso

Elementos Signal Sending: Representa el envío de un mensaje Signal Receipt: Representa la recepción de un evento o mensaje

Casos de uso

¿Qué es un caso de uso? Artefacto cuyo objetivo principal es capturar el comportamiento del sistema, a través de una secuencia de acciones (flujo de trabajo), que desde la perspectiva del usuario final permiten alcanzar los objetivos deseados Un caso de uso describe lo QUE debe hacer el sistema para satisfacer un requisito, NO COMO debe hacerlo El caso esta compuesto por uno o más flujos (secuencia de acciones) y es invocado por un actor (usuario o sistema)

¿Qué es un caso de uso? Los casos de uso describen la interacción del usuario con el sistema La especificación de la interacción debe contemplar posibles flujos alternos ante distintas condiciones que se pueden dar en medio Sistema Acción 1 Acción 2 Acción 3 Actor

Elementos de Caso de Uso Actor: Es un rol que un usuario juega en el sistema. No necesariamente es una persona. Puede estar representado por un grupo de usuarios, otro sistemas o hardware Flujo Básico de Eventos: Corresponde al flujo de eventos cuando todas las circunstancias son ideales (todas las validaciones son cruzadas exitósamente). Se deben numerar cada uno de los pasos En cada paso hay que describir la acción efectuada por el actor o por el sistema

Elementos de Caso de Uso Flujos Alternos: Toda situación que impida que se pueda llevar a cabo el flujo normal como está presupuestado. Habitualmente validaciones. Tipos de validaciones: Sintácticas : Inherentes a la naturaleza del dato : Obligatoriedad, tipo de dato, rango y formato Semánticas : A partir del significado del dato o conjunto de datos (Reglas del Negocio) Se debe indicar el paso en el que se da la situación, la situación, la acción del sistema y a qué paso se retorna

Elementos de Caso de Uso Pre-condiciones: Preconcepciones acerca del sistema que deben darse para que se pueda llevar a cabo el caso de uso como esta concebido Post-condiciones: Especifica cual es el resultado de valor que genera el caso de uso (cómo modifica su entorno)

Ejemplo CASO DE ESTUDIO DEL RESTAURANTE “O SOLE MIO” El restaurante “O Sole Mío” desea construir una solución que le permita administrar la elaboración de los diversos platos que ofrece a sus clientes. Para esto, el administrador quiere que se maneje una relación de cada plato junto con los ingredientes necesarios para elaborarlo. Cada relación de ingrediente debe tener la cantidad y costo del mismo. De esta manera, también será posible establecer el costo del plato. El precio cobrado a los clientes siempre será un porcentaje fijo por encima de la suma de los costos de los ingredientes que se requieren para su elaboración. Con esta información registrada, Don Vittorio Corleogni (su gerente y dueño) desea obtener solo dos servicios: Que el cocinero, cuando lea una orden escrita por un mesero, consulte en el sistema el plato y conozca cómo elaborar el mismo, junto con sus ingredientes y cantidades. Que el cajero, al momento de elaborar la cuenta, consulte cada plato y el sistema le diga cuánto cobrar por él. Con ésta información, el cajero puede calcular (con calculadora) el costo total de la cuenta.

Ejemplo Casos de uso Asociaciones Roles

Ejemplo Consultar elaboración de un plato Breve Descripción: Permite la consulta de la elaboración e ingredientes de un plato Entradas: Código del plato. Es un campo alfanumérico. Es obligatorio Flujo Básico de Eventos El sistema solicita le sea ingresado el código del plato El actor digita el código del plato y acepta El sistema despliega la información del plato: nombre, elaboración y la lista de ingredientes con código, nombre y cantidad

Ejemplo Flujos alternativos Código del plato no ingresado Si en el paso 1, no se ingresa ningún codigo, el sistema informa del error y retorna al paso 1 (Obligatoriedad) Código del plato no existente Si en el paso 1 se ingresa un código de plato que no existe registrado en el sistema, el sistema informa del error y retorna al paso 1 (validación semántica)

Ejemplo Pre-condiciones Post-condiciones El sistema cuenta con todo el registro de los platos y sus elaboraciones Post-condiciones El sistema despliega los datos de la elaboración del plato junto con sus ingredientes

Relaciones de los casos de uso Herencia Relación entre actores en la cual los roles hijos heredan todos los casos de uso en los cuales interviene el padre

Relaciones de los casos de uso Inclusión Se factoriza una interacción en un conjunto de casos (al menos 2) El sistema solicita le sea ingresado el usuario y la palabra clave El actor digita los datos y acepta El sistema verifica el usuario y el password y genera un mensaje de éxito Los dos casos de uso incluyen en su narración la validación del usuario y password

Relaciones de los casos de uso Extensión Permite que se pueda extender un flujo de eventos de un caso hacia otro caso de uso bajo una situación excepcional Luego de consultar un pedido, el actor puede ir al caso de uso de Cancelar pedido

Malas prácticas El sistema solicita le sea ingresado el dato del plato El diseñador y el programador NO saben cuál es el dato. Debe enunciarse específicamente qué datos son ingresados en cada paso de un caso de uso. El sistema despliega la información del plato El diseñador y el programador no saben cuáles son los datos que se deben desplegar o contemplar en este caso de uso El sistema despliega la información del plato: nombre, elaboración y lista de ingredientes El diseñador y el programador NO saben qué datos desplegar para los ingredientes = información incompleta

Algunos entregables Documento de visión Cronograma y resumen del proyecto Definición preliminar de alcance Casos de uso suficientes que soportan el proceso Modelo de procesos Matriz de trazabilidad de Procesos vs. Casos de uso Especificaciones de casos de uso Glosario Reglas de negocio Solo las utilizadas por algún caso de uso

Algunos entregables Prototipo Especificación no funcional

Preguntas © 2008 HEINSOHN Corporation

Gracias Camilo Andrés Rivera Damelines crivera@heinsohn.com.co Consultor Junior crivera@heinsohn.com.co © 2008 HEINSOHN Corporation