Avistar
Sabías qué...

Nuestros cursos de Certificación PMP® y CAPM® incluyen 40 y 24 horas respectivamente de capacitación presencial más un programa integral en línea para complementar tu preparación desde la comodidad de tu casa, y garantizar tu certificación.

17 módulos en video (80 videos)
60 contact hours / PDUs
Simulador de examen
Autoevaluaciones por cada video
Acceso al foro No. 1 de PM en español
Libro digital de Pablo Lledó
60 plantillas de PM
PMBOK® Guide con descuento

Entre otros beneficios...

Ver aquí


Información general
Novedades
Conoce la Póliza Abiztar Plus
Nuestros clientes
Recomendaciones de capacitación
Calendario de cursos

Cursos de Ingeniería de software
Bootcamp de UML
Modelado con SysML
Modelado de Negocios /BPMN
Patrones de Diseño
Casos de Uso
TOGAF
Desarrollo automatizado de software con MDA
Grails
Java 6
Fundamentos de Pruebas

Cursos de Dirección de proyectos
Certificación PMI-RMP®
Certificación PMI-SP®
Certificación PMP®
Certificación CAPM®
SCRUM
Estimación de Proyectos
Seguimiento de Proyectos
Simulacro en proyectos de SW
Calendarización con MS Project y PMBOK®

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

Especificaciones de Casos de Uso:
Lo que Bien Comienza, bien Acaba


Por Sergio Orozco

Si entra basura, sale basura... una gran verdad en cualquier proceso, a menos te dediques al reciclaje de desechos (lo cual es poco probable dado el tema de la revista que tiene en sus manos). Los proyectos de software no son la excepción; si no iniciamos el desarrollo partiendo de requerimientos correctamente establecidos tendremos muchos problemas para lograr que al final todos los involucrados queden satisfechos.

Evitando Malentendidos

Como lo comentamos en la edicion anterior, la mayoría de los proyectos de software que fallan tienen como causa principal una mala administración de requerimientos. Un ejemplo en este sentido suele ser un mal entendimiento de los requerimientos entre usuarios y desarrolladores.

Aún y cuando el equipo de desarrollo cree comprender lo que el cliente le está solicitando, existe una buena probabilidad de que no sea así. Incluso me atrevo a decir que en la mayoría de las ocasiones lo que yo he visto es que en las primeras etapas ni siquiera el cliente está totalmente conciente de qué es lo que quiere o necesita.

Ahí es donde el analista entra al rescate, pues debe facilitarle al usuario expresar sus necesidades para validarlas posteriormente mediante mecanismos eficientes de comunicación que ambos entiendan. Un ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.

Aclarando el Panorama

Partiendo de la premisa que ya se identificaron los actores y casos de uso apropiados del sistema (ver número anterior: Casos de Uso y el Valor del Sistema) lo que corresponde es detallar los pasos necesarios para cumplir con dicho caso de uso.

Para especificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos:

  1. Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina.

  2. Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, etc.)

  3. Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.
  4. Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.

  5. Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar con éste que lo documentado en las espceificaciones de los casos de uso es lo que requiere para su sistema, así que si no los entiende no cumplirán su propósito principal.

Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de forma escrita.

Flujo principal del caso de uso “Registrar Venta”

  • El vendedor solicita el registro de una nueva venta.
  • El sistema solicita los datos de cada uno de los productos de la venta.
  • El vendedor registra la cantidad y clave de cada uno de los productos.
  • El sistema muestra la lista de productos con su cantidad, clave, descripción, subtotal, IVA y total.
  • El sistema solicita el tipo de pago.
  • El vendedor indica pago al contado o con tarjeta de crédito.
  • Dependiendo de la selección comienza el flujo alterno “Pago al contado” o “Pago con tarjeta de crédito”.
  • Una vez realizado el pago se registra la venta, se actualiza el inventario e imprime el ticket correspondiente.
  • Termina el caso de uso.

Flujo Alterno: Pago al Contado

  • El vendedor registra el monto recibido por el cliente.
  • El sistema calcula y muestra el cambio a devolver.
  • El vendedor devuelve el cambio al cliente.

El ejemplo que mostramos es una versión simplificada de la especificación de un caso de uso con el flujo principal y uno de los flujos alternos.

Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero, puedo asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuación se mencionan algunos de esos elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso.

  • Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso.
  • Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con otro sistema, el usuario debe estar conectado con cierto perfil específico)
  • Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Imagina que eres un tester y quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema.
  • Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado.
  • Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.

En los cursos prácticos que impartimos de UML una de las inquietudes que nos expresan más frecuentemente los analistas es el hecho de que el cliente no está dispuesto a pagar el esfuerzo requerido para realizar la “documentación” que implica especificar los casos de uso.

El error, en primer lugar, es que no lo deberíamos de ver como “la documentación” del sistema, sino como una herramienta para esclarecer lo que quiere que le construyamos. Si no se especifica claramente qué es lo que quiere/desea/necesita el cliente entonces resulta una adivinanza saber cuánto nos vamos a tardar, y por lo tanto cuánto nos va a costar desarrollarlo.

En este sentido dependerá del contexto del proyecto el nivel de detalle a realizar, y por lo tanto la cantidad de “documentación” generada para especificar los casos de uso. Sólo hay que tomar en cuenta que entre menos precisión y detalle haya mayor será el riesgo de no tener un proyecto exitoso. Así que no nos debe de sorprender que si entra basura, con bastante probabilidad, saldrá basura.

Por Sergio Orozco.

 

<< Regresar a artículos



Contacto
.
.
México D.F. - +52 (55) 5594 6411
  Envíanos un E-mail a:
cursos@abiztar.com.mx
.
O si lo prefieres:
Llena nuestro formulario de contacto
  [ Aviso de privacidad ]

© Abiztar. PMI, PMBOK, OPM3, CAPM, PMP, PMI-SP y PMI-RMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. Capability Maturity Model y CMM son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. CMM, IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp."