Curso de Administración de Requerimientos con Casos de Uso

Los casos de uso se han convertido en la técnica más utilizada a nivel mundial para el levantamiento y la comunicación clara y eficiente de los requisitos (mejor conocidos como "requerimientos") para el desarrollo de sistemas. Los casos de uso son parte del Lenguaje Unificado de Modelado (UML®), que es el estándar más importante y más ampliamente reconocido para la especificación, diagramación y documentación de software de calidad. El UML es un estándar abierto (es decir, que no es propiedad de una empresa en particular), y es administrado por el Object Management Group (OMG®) con el acuerdo y participación de prácticamente todas las principales organizaciones dedicadas al desarrollo de software.
Asimismo, los casos de uso son un artefacto clave en el Proceso Unificado de desarrollo de software, ya que son el depósito principal de los requisitos funcionales que gobiernan el diseño, la construcción, las pruebas, y muchos otros aspectos de este proceso. El hecho que sean una parte fundamental de un proceso formal de ingeniería de software, permite su conexión y compatibilidad con las áreas de conocimiento de la Guía de los fundamentos de la dirección de proyectos (PMBOK® Guide), y con las áreas de proceso del modelo de capacidad y madurez conocido como CMMI®, del Software Engineering Institute (SEI).
Los conceptos explicados en los libros sobre casos de uso o en la especificación de UML no son suficientes para tener éxito en la aplicación del Proceso Unificado o en las áreas del PMBOK® Guide y del CMMI: es necesario incorporar la experiencia y el manejo de casos prácticos, tales como los que brinda este curso.

1. El Proceso Unificado: un proceso de ingeniería de software centrado en casos de uso.
2. El área de conocimiento de gestión de requisitos, del PMBOK® Guide.
3. El área de proceso de adminsitración de requerimientos del CMMI.

• 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

• 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

1. Cómo identificar casos de uso a partir de la visión del sistema
2. Las reglas de negocio y los casos de uso
3. Por qué los casos de uso cuestan tanto trabajo
4. Por qué los casos de uso son el punto de éxito del proyecto

1. Actores: Primarios y secundarios
2. Qué es un caso de uso
3. En qué caso uso el caso de uso
4. Por qué es tan difícil bautizar al caso de uso. Quién tiene la autoridad para validar el nombre del caso de uso
5. De qué tamaño debe ser el caso de uso ¿Grande, Pequeño, Mediano?
6. Casos de uso de alto nivel
7. Casos de uso reales
8. Granularidad de los casos de uso
9. ¿Por qué faltan casos de uso? Shadow use cases
10. ¿Un caso de uso se puede partir?
11. ¿Quién surge primero, el actor o el caso de uso?
12. Cómo identificar a los actores
13. Los actores y los stakeholders
14. La frontera del sistema

1. Relaciones entre actores y casos de uso
2. Casos de uso que incluyen más casos de uso: relación <<includes>>
3. Casos de uso que se extienden con otros casos de uso: relación <<extends>>
4. Dónde extender el caso de uso: Los puntos de extensión
5. ¿Conviene usar includes y extends? ¿Qué alternativa tenemos?
6. Los casos de uso también heredan: relación de generalización
7. Realización de casos de uso
8. Cómo organizar los casos de uso
9. Paquetes de casos de uso: recomendaciones para su organización

• 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

1. Lo más costoso de un caso de uso no es el escenario feliz: cómo fracasar identificando escenarios felices
2. Quién debe escribir los casos de uso ¿los desarrolladores o los usuarios?
3. A qué detalle redactar el caso de uso
4. 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?
5. ¿Hay expertos en casos de uso? ¿Por qué todos creen tener la razón respecto a cómo redactar los casos de uso?
6. Cómo fracasar en un proyecto con los casos de uso equivocados
7. Por qué el tester no puede diseñar sus pruebas si los casos de uso no son perfectos

1. Cómo perder a un cliente con los casos de uso equivocados
2. Por qué los clientes no entienden mis casos de uso
3. Por quién preocuparse al redactar un caso de uso: por el usuario o por el programador
4. Cuándo está suficientemente completo el caso de uso
5. Casos de uso para programadores
6. Los casos de uso evolucionan: control de versiones de casos de uso
7. Cómo controlar los cambios en los casos de uso
8. Por qué debo de comprender el dominio si quiero identificar los casos de uso correctos
9. El proceso es centrado en casos de uso o centrado en el dominio
10. Por qué los programadores somos malos escribiendo casos de uso

1. Qué viene después de los casos de uso
2. Ejemplos de artefactos generados a partir del caso de uso
3. Ejemplo sencillo de un modelado de negocio
4. Cómo identificar casos de uso a partir del proceso de negocio
5. Procesos, actividades y casos de uso
6. El diagrama de actividad y los casos de uso

1. Cómo modelar un caso de uso con un diagrama de actividad
2. Los carriles y su relación con los actores del caso de uso
3. Las actividades y el flujo de eventos del caso de uso
4. Representación gráfica de un flujo alterno de un caso de uso

1. Ejemplo sencillo de un diagrama de secuencia para representar un caso de uso

1. 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
2. EJERCICIO: Identificación y modelado del diagrama de casos de uso a partir de los requerimientos del sistema que el alumno/cliente proponga
3. EJERCICIO: Agrupación de los casos de uso en paquetes
4. EJERCICIO: Especificación de un caso de uso. Los alumno documentarán con ayuda del consultor uno de los casos de uso identificados
5. EJERCICIO:: Modelado de un diagrama de actividad para mostrar un flujo del caso de uso
6. EJERCICIO: Identificación de los escenarios del caso de uso

• 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:
• Analistas de sistemas.
• Responsables de identificar y redactar casos de uso y requerimientos que proporcionen valor al proyecto.
• Administradores de requerimientos responsables de controlar los requerimientos.
• Líderes de proyectos responsables de validar los casos de uso y de realizar su planeación y seguimiento con base en estos.
• Programadores responsables de implementar los casos de uso.
• Diseñadores y arquitectos de software responsables de elaborar la arquitectura del sistema que soporte los casos de uso del sistema.
• Responsables de calidad que valida los estándares y la calidad de los requerimientos y los casos de uso.
• Usuarios responsables de colaborar en la identificación y definición de casos de uso.
• Testers responsables de validar el funcionamiento del sistema y que requieren utilizar los casos de uso para diseñar y realizar sus pruebas