Taller Práctico basado en UML 2.1; Administración de Requerimientos con Casos de Uso - Tlalpan - Distrito Federal

Comprender la importancia de la definición de administración de requerimientos de acuerdo al Proceso Unificado (UP) de Desarrollo de Software, el PMBOK® del Project Management Institute y el CMMI® del Software Engineering Institute (SEI). Haber desarrollado o actualizar las habilidades necesarias para realizar el levantamiento de requisitos. Comprender qué es un modelo de caso de uso y cuáles son los diferentes elementos de este modelo. Ser capaces de elaborar casos de uso que cumplan con el estándar UML (versión 2.1), pero que además se acoplen a las mejores prácticas y recomendaciones de los expertos a nivel mundial. El alumno aprenderá desde los conceptos más básicos del modelo de casos de uso hasta los \\\"secretos\\\" que sólo la experiencia puede brindar.

Taller práctico basado en UML® 2.1, PMBOK® y CMMI®

Este curso está dirigido a todas aquellas personas que necesiten administrar, coordinar, supervisar o participar en proyectos de software, y más especificamente en el levantamiento y administración de requerimientos, así como en el diseño de pruebas

Diplomado de Modelado de Negocios con UML y BPMN Certificado por OMG, UML, y PMI Project Managment Institute

Este curso se imparte en las siguientes sedes de Milestone Consulting:
Ciudad de México
Guadalajara
Monterrey

El papel de los requerimientos en el éxito y el fracaso de los proyectos
La administración de requerimientos es un aspecto crucial de los proyectos: un levantamiento mal realizado o una administración deficiente de requisitos son unas de las causas más comunes para el fracaso de los proyectos.

En este módulo se introducen, también, los fundamentos metodológicos:
- El Proceso Unificado: un proceso de ingeniería de software centrado en casos de uso.
- El área de conocimiento de gestión de requisitos, del PMBOK.
- El área de proceso de adminsitración de requerimientos del CMMI.
Se realiza un breve ejercicio en el que los participantes identifican causas de retrasos en sus proyectos, problemas o bien de éxitos en aquellas experiencias que deseen compartir con el grupo.
Levantamiento de requisitos
- Alineación de las perspectivas de los interesados (stakeholders)
Técnicas de levantamiento de requerimientos:
- Entrevistas
- Prototipos
- Sesiones JAD
- Introducción a la documentación de alcances
Entremos en materia
- Organización del Proceso Unificado
- Requerimientos: funcionales, no funcionales y no técnicos
- Qué es el UML
- Qué son los casos de uso: introducción y breve ejemplo
- Los casos de uso no son DFDs
- Cómo identificar casos de uso a partir de los requerimientos del sistema
- Trazabilidad entre requerimientos y casos de uso para cumplir con requisitos de modelos como CMMI

EJERCICIO: Los alumnos identificarán un subconjunto de la lista de los requerimientos de un sistema.
1. La organización y los casos de uso
- Cómo identificar casos de uso a partir de la visión del sistema
- Las reglas de negocio y los casos de uso
- Por qué los casos de uso cuestan tanto trabajo
- Por qué los casos de uso son el punto de éxito del proyecto
2. Conceptos de casos de uso
- Actores: Primarios y secundarios
- Qué es un caso de uso
- En qué caso uso el caso de uso
- Por qué es tan difícil bautizar al caso de uso. Quién tiene la autoridad para validar el nombre del caso de uso
- De qué tamaño debe ser el caso de uso  ¿Grande, Pequeño, Mediano?
- Casos de uso de alto nivel
- Casos de uso reales
- Granularidad de los casos de uso
- ¿Por qué faltan casos de uso? Shadow use cases
- ¿Un caso de uso se puede partir?
- ¿Quién surge primero, el actor o el caso de uso?
- Cómo identificar a los actores
- Los actores y los stakeholders
- La frontera del sistema
EJERCICIO: A partir de una lista de requerimientos de un sistema los alumnos modelarán un diagrama de casos de uso con sus actores.
3. Relaciones del modelo de casos de uso
- Relaciones entre actores y casos de uso
- Casos de uso que incluyen más casos de uso: relación <<includes>>
- Casos de uso que se extienden con otros casos de uso: relación <<extends>>
- Dónde extender el caso de uso: Los puntos de extensión
- ¿Conviene usar includes y extends? ¿Qué alternativa tenemos?
- Los casos de uso también heredan: relación de generalización
- Realización de casos de uso
- Cómo organizar los casos de uso
- Paquetes de casos de uso: recomendaciones para su organización
EJERCICIO: Organización de los diferentes casos de uso en paquetes para representar módulos o subsistemas
4. Redactando los casos de uso: Especificando el caso de uso
- Estructura de la especificación del caso de uso: ¿cuál usar? simple o compleja
- ¿Existe una fórmula única para redactar los casos de uso?
- Precondiciones y postcondiciones
- Flujos de eventos
- El Happy Path del caso de uso
- Flujos alternos y excepcionales
EJERCICIO: Entre todos los alumnos documentarán un caso de uso con la guía del instructor
5. Identificando los escenarios en un caso de uso
- Lo más costoso de un caso de uso no es el escenario feliz: cómo fracasar identificando escenarios felices
- Quién debe escribir los casos de uso ¿los desarrolladores o los usuarios?
- A qué detalle redactar el caso de uso
- El prototipo gráfico y los casos de uso: ¿conviene diseñar un prototipo antes de los casos de uso o los casos de uso antes del prototipo?
- ¿Hay expertos en casos de uso?  ¿Por qué todos creen tener la razón respecto a cómo redactar los casos de uso?
- Cómo fracasar en un proyecto con los casos de uso equivocados
- Por qué el tester no puede diseñar sus pruebas si los casos de uso no son perfectos
EJERCICIO: Identificación de los casos de prueba a partir de un caso de uso y sus escenarios
6. Recomendaciones sobre casos de uso
- Cómo perder a un cliente con los casos de uso equivocados
- Por qué los clientes no entienden mis casos de uso
- Por quién preocuparse al redactar un caso de uso: por el usuario o por el programador
- Cuándo está suficientemente completo el caso de uso
- Casos de uso para programadores
- Los casos de uso evolucionan: control de versiones de casos de uso
- Cómo controlar los cambios en los casos de uso
- Por qué debo de comprender el dominio si quiero identificar los casos de uso correctos
- El proceso es centrado en casos de uso o centrado en el dominio
- Por qué los programadores somos malos escribiendo casos de uso
7. Artefactos relacionados a los Casos de Uso
- Qué viene después de los casos de uso
- Ejemplos de artefactos generados a partir del caso de uso
- Ejemplo sencillo de un modelado de negocio
- Cómo identificar casos de uso a partir del proceso de negocio
- Procesos, actividades y casos de uso
- El diagrama de actividad y los casos de uso
EJERCICIO: Los alumnos desarrollarán un pequeño diagrama de un proceso para usar como base para la identificación de casos de uso
- Cómo modelar un caso de uso con un diagrama de actividad
- Los carriles y su relación con los actores del caso de uso
- Las actividades y el flujo de eventos del caso de uso
- Representación gráfica de un flujo alterno de un caso de uso
EJERCICIO: Modelado de un diagrama de actividad para mostrar el flujo de un caso de uso
- Ejemplo sencillo de un diagrama de secuencia para representar un caso de uso
8. SEGUNDO CASO PRÁCTICO COMPLETO: PROYECTO DEL ALUMNO (uno para todo el grupo).  Se lleva a cabo una secuencia completa para reforzar los conocimientos y las buenas prácticas en relación a los casos de uso.
EJERCICIO: Modelado de un flujo de un proceso de negocio para usar como base en la identificación de los casos de uso del caso práctico
EJERCICIO: Identificación y modelado del diagrama de casos de uso a partir de los requerimientos del sistema que el alumno/cliente proponga
EJERCICIO: Agrupación de los casos de uso en paquetes
EJERCICIO: Especificación de un caso de uso.  Los alumno documentarán con ayuda del consultor uno de los casos de uso identificados
EJERCICIO: Modelado de un diagrama de actividad para mostrar un flujo del caso de uso
EJERCICIO: Identificación de los escenarios del caso de uso