Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Presentación levantamiento y análisis de requerimientos

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 37 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Presentación levantamiento y análisis de requerimientos (20)

Anzeige

Presentación levantamiento y análisis de requerimientos

  1. 1. Levantamiento de requerimientos HEINSOHN Software House | Grupo de Ingeniería © 2008 HEINSOHN Corporation HEINSOHN Software House | | Fábrica software Software House Fábrica software
  2. 2. Agenda ► Objetivos ► Conceptos Claves ► Metodología de Levantamiento ► Modelamiento de Procesos ► Casos de Uso ► Entregables y Criterios de Aceptación ► Bibliografía HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  3. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  4. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  5. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  6. 6. Metodología de levantamiento HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  7. 7. Metodología Reunión Preliminar Planeación del ciclo de levantamiento Convenciones Roles Reunión de Lanzamiento Cliente Analista Líder Analista HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  8. 8. Metodología 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 Convenciones Roles NO Solicitar documentación adicional Cliente Analista Líder Analista HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  9. 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 NO SI Documento aprobado ? SI Preparación agenda de entrevistas Convenciones Roles Cliente Notificar compromiso a entrevistados HEINSOHN Software House | Preparación y ejecución de entrevistas Analista Líder Analista HEINSOHN Software House | Fábrica software
  10. 10. Metodología 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 Convenciones Roles Cliente Analista Líder Analista HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  11. 11. Metodología Aprobación Modelo de Procesos Modelo de Procesos OK ? Revisión Artefactos de Proceso Revisión OK ? NO Ajuste Artefactos de Proceso NO SI SI Aprobación Definición Preliminar del Alcance Definición Preliminar del Alcance Ajustes Definición Preliminar del Alcance Definición Preliminar OK ? Convenciones Roles NO Cliente SI Planeación detallada de especificaciones HEINSOHN Software House | Aprobación planeación detallada Analista Líder Analista HEINSOHN Software House | Fábrica software
  12. 12. Metodología Aprobación planeación detallada Aprobar ajustes a la definición del alcance Refinar definición del alcance Aprobación casos de uso terminados Especificar casos de uso Crear relaciones de trazabilidad Especificar Reglas de Negocio Casos de uso aprobados ? NO Refinar Glosario SI Solicitar y ejecutar Sesiones de aclaraciones HEINSOHN Software House | Elaborar arquitectura de casos de uso HEINSOHN Software House | Fábrica software
  13. 13. Metodología Aprobación planeación detallada Especificar requerimientos No funcionales Aprobación Artefactos de Requerimientos Elaborar y documentar Prototipo / StoryBoards Revisión Artefactos de Requerimientos Artefactos OK ? NO Ajustes Artefactos de Requerimientos SI NO Artefactos OK ? NO SI Cerrar fase de requerimientos HEINSOHN Software House | Cambios en los requerimientos ? Convenciones Roles SI Cliente Procedimiento de Control de Cambios Analista Líder Analista HEINSOHN Software House | Fábrica software
  14. 14. Modelamiento de procesos HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  15. 15. Elementos Inicio Final cd Due Diligence pre para ... «ROL Analista de DD» Pr0074 Seleccionar archiv os planos ► 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 Actividad HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  16. 16. Elementos Enlace ► 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  17. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  18. 18. Elementos ► Signal Sending: Representa el envío de un mensaje ► Signal Receipt: Representa la recepción de un evento o mensaje HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  19. 19. Casos de uso HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  20. 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) HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  21. 21. ¿Qué es un caso de uso? ► Los casos de uso describen la interacción del usuario con el sistema Acción 1 Acción 2 Actor Acción 3 Sistema ► La especificación de la interacción debe contemplar posibles flujos alternos ante distintas condiciones que se pueden dar en medio HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  22. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  23. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  24. 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) HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  25. 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. HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  26. 26. Ejemplo Casos de uso Asociaciones uc Primary Use Cases System Boundary Consultar elaboración de plato Roles Cocinero Consultar plato Caj ero HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  27. 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 1. El sistema solicita le sea ingresado el código del plato 2. El actor digita el código del plato y acepta 3. El sistema despliega la información del plato: nombre, elaboración y la lista de ingredientes con código, nombre y cantidad HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  28. 28. Ejemplo ► Flujos alternativos ● Código del plato no ingresado 1. 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 2. 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) HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  29. 29. Ejemplo ► Pre-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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  30. 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 uc Primary Use Cases System Boundary Consultar estado de cartera Funcionario de Pedidos (from Actors) Registrar pedidos personas naturales Funcionario de pedidos de personas naturales (from Actors) Registrar pedidos personas j urídicas Funcionario de pedido de personas j urídicas (from Actors) HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  31. 31. Relaciones de los casos de uso ► Inclusión ● Se factoriza una interacción en un conjunto de casos (al menos 2) uc Primary Use Cases Consultar estado cartera «include» «include» Administrador Cancelar pedido (from Actors) Los dos casos de uso incluyen en su narración la validación del usuario y password HEINSOHN Software House | Validar usuario y passw ord 1. 2. 3. 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 HEINSOHN Software House | Fábrica software
  32. 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 uc Primary Use Cases Consultar pedido «extend» Cancelar pedido Administrador (from Actors) Luego de consultar un pedido, el actor puede ir al caso de uso de Cancelar pedido HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  33. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  34. 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 HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  35. 35. Algunos entregables ► Prototipo ► Especificación no funcional HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  36. 36. © 2008 HEINSOHN Corporation Preguntas HEINSOHN Software House | HEINSOHN Software House | Fábrica software
  37. 37. © 2008 HEINSOHN Corporation Gracias Camilo Andrés Rivera Damelines Consultor Junior crivera@heinsohn.com.co HEINSOHN Software House | HEINSOHN Software House | Fábrica software

×