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 administració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:

- 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

1.1. Cómo identificar casos de uso a partir de la visión del sistema
1.2. Las reglas de negocio y los casos de uso
1.3. Por qué los casos de uso cuestan tanto trabajo
1.4. Por qué los casos de uso son el punto de éxito del proyecto

2. Conceptos de casos de uso

2.1. Actores: Primarios y secundarios
2.2. Qué es un caso de uso
2.3. En qué caso uso el caso de uso
2.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
2.5. De qué tamaño debe ser el caso de uso  ¿Grande, Pequeño, Mediano?
2.6. Casos de uso de alto nivel
2.7. Casos de uso reales
2.8. Granularidad de los casos de uso
2.9. ¿Por qué faltan casos de uso? Shadow use cases
2.10. ¿Un caso de uso se puede partir?
2.11. ¿Quién surge primero, el actor o el caso de uso?
2.12. Cómo identificar a los actores
2.13. Los actores y los stakeholders
2.14. 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

3.1. Relaciones entre actores y casos de uso
3.2. Casos de uso que incluyen más casos de uso: relación <<includes>>
3.3. Casos de uso que se extienden con otros casos de uso: relación <<extends>>
3.4. Dónde extender el caso de uso: Los puntos de extensión
3.5. ¿Conviene usar includes y extends? ¿Qué alternativa tenemos?
3.6. Los casos de uso también heredan: relación de generalización
3.7. Realización de casos de uso
3.8. Cómo organizar los casos de uso
3.9. 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

4.1. Estructura de la especificación del caso de uso: ¿cuál usar? simple o compleja
4.2. ¿Existe una fórmula única para redactar los casos de uso?
4.3. Precondiciones y postcondiciones
4.4. Flujos de eventos
4.5. El Happy Path del caso de uso
4.6. 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

5.1. Lo más costoso de un caso de uso no es el escenario feliz: cómo fracasar identificando escenarios felices
5.2. Quién debe escribir los casos de uso ¿los desarrolladores o los usuarios?
5.3. A qué detalle redactar el caso de uso
5.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.5. ¿Hay expertos en casos de uso?  ¿Por qué todos creen tener la razón respecto a cómo redactar los casos de uso?
5.6. Cómo fracasar en un proyecto con los casos de uso equivocados
5.7. 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

6.1. Cómo perder a un cliente con los casos de uso equivocados
6.2. Por qué los clientes no entienden mis casos de uso
6.3. Por quién preocuparse al redactar un caso de uso: por el usuario o por el programador
6.4. Cuándo está suficientemente completo el caso de uso
6.5. Casos de uso para programadores
6.6. Los casos de uso evolucionan: control de versiones de casos de uso
6.7. Cómo controlar los cambios en los casos de uso
6.8. Por qué debo de comprender el dominio si quiero identificar los casos de uso correctos
6.9. El proceso es centrado en casos de uso o centrado en el dominio
6.10. Por qué los programadores somos malos escribiendo casos de uso

7. Artefactos relacionados a los Casos de Uso

7.1. Qué viene después de los casos de uso
7.2. Ejemplos de artefactos generados a partir del caso de uso
7.3. Ejemplo sencillo de un modelado de negocio
7.4. Cómo identificar casos de uso a partir del proceso de negocio
7.5. Procesos, actividades y casos de uso
7.6. 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

7.7. Cómo modelar un caso de uso con un diagrama de actividad
7.8. Los carriles y su relación con los actores del caso de uso
7.9. Las actividades y el flujo de eventos del caso de uso
7.10. 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

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

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

8.2. EJERCICIO: Identificación y modelado del diagrama de casos de uso a partir de los requerimientos del sistema que el alumno/cliente proponga.

8.3. EJERCICIO: Agrupación de los casos de uso en paquetes.

8.4. EJERCICIO: Especificación de un caso de uso.  Los alumno documentarán con ayuda del consultor uno de los casos de uso identificados.

8.5. EJERCICIO: Modelado de un diagrama de actividad para mostrar un flujo del caso de uso.

8.6. EJERCICIO: Identificación de los escenarios del caso de uso