La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Levantamiento de requerimientos

Presentaciones similares


Presentación del tema: "Levantamiento de requerimientos"— Transcripción de la presentación:

1 Levantamiento de requerimientos

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

3 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

4 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

5 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

6 Metodología de levantamiento

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

8 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

9 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

10 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

11 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

12 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

13 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

14 Modelamiento de procesos

15 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

16 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

17 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

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

19 Casos de uso

20 ¿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)

21 ¿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

22 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

23 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

24 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)

25 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.

26 Ejemplo Casos de uso Asociaciones Roles

27 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

28 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)

29 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

30 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

31 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

32 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

33 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

34 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

35 Algunos entregables Prototipo Especificación no funcional

36 Preguntas © 2008 HEINSOHN Corporation

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


Descargar ppt "Levantamiento de requerimientos"

Presentaciones similares


Anuncios Google