Milestone Consulting
 

Información general
Novedades
Capacítate con Milestone
Calendario de cursos
Promociones
Artículos
Adquiere Enterprise Architect

Cursos UML
Bootcamp de UML
Modelado con SysML
Modelado de Negocios /BPMN
Arquitectura de software /UML
Casos de Uso

Cursos Admin. de Proyectos.
Admin. de proyectos /CMMI
Certificación PMP
Estimación de Proyectos
Seguimiento de Proyectos
Taller preparación PMP

Otros cursos
Curso Java
Curso de ASP.NET/C#
Fundamentos de Pruebas

Milestone Consulting
Experiencia
Consultoría
Bolsa de trabajo

Base de conocimiento
UML y Arquitecturas
Administración de Proyectos
Procesos de Software

Administración de Requerimientos con Casos de Uso
Taller práctico basado en UML® 2.1, PMBOK® y CMMI®



Antecedentes

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®), 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 y del CMMI: es necesario incorporar la experiencia y el manejo de casos prácticos, tales como los que brinda este curso.

Objetivo

Al terminar el curso, los participantes deberán:

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

Estrategia

Un consultor experto en el uso de UML y del Proceso Unificado en proyectos reales, guiará a los alumnos en el análisis de los conceptos de los casos de uso. Para facilitar la comprensión, se utiliza primero un ejemplo que los mismos alumnos, desde el principio del curso, tendrán que ir resolviendo mediante el uso de una herramienta de ingeniería de software (como lo es Enterprise Architect, de Sparx Systems).  Posteriormente, los participantes profundizarán en un caso práctico expuesto por el instructor, y en otro caso que los mismos alumnos elaborarán de acuerdo a los proyectos en los que ellos participan, con el objeto de experimentar en el curso la realidad de los problemas que enfrentan en proyectos de la vida real.  La presencia del consultor experto en casos de uso permitirá resolver las dudas, no únicamente del tipo conceptual sino también de casos de aplicación reales.

A quién está dirigido

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

Cumplimiento de requisitos para aspirantes a la credencial PMP®

Este curso permite al alumno acreditar 16 horas de educación mediante instrucción directa en materia de manejo de proyectos, especificadas en el manual Project Management Professional (PMP®) Credential Handbook, del Project Management Institute (PMI®).

PDUs

Asimismo, permite a quienes ya cuenten con la credencial de PMP acreditar 16 PDUs (Professional Development Units), categoría 3, conforme a lo descrito en el manual Continuing Certification Requirements Program (CCR) Handbook, del PMI.

Marco Metodológico

El curso está basado en el área de conocimiento de administración de requisitos del PMBOK del PMI, en el modelo de mejora de procesos del Software Engineering Institute (SEI) y en el Proceso Unificado de desarrollo de software (es decir, la versión pública del modelo de procesos de ingeniería de software, expuesta por I. Jacobson, G. Booch y J. Rumbaugh en su obra El proceso unificado de desarrollo de software).

Por supuesto, el curso recoge ideas y prácticas de muchas otras fuentes y autores, y muy especialmente de las décadas de experiencia vividas por los instructores.


El curso incluye:
 
Manual impreso del curso
Constancia de participación.

Temario

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

Habilidades previas recomendadas

El alumno deberá tener un manejo elemental de Microsoft® Office.

Información adicional

Duración: 2 días, 16 horas


Contáctanos y aparta tu lugar:
México D.F: +52 (55) 3548 0740 Monterrey:+52 (81) 8300 4036
Guadalajara: (0133) 8421 8417 Email: cursos@milestone.com.mx
. Consulta el calendario de cursos
I
©2000-2008 Milestone Consulting. UML, el logo de UML y OMG son marcas registradas de The Object Management Group.
El logo de PMI es una marca registrada de Project Management Institute..