Archivos para 26 agosto 2008

Casos de uso: preferir la amplitud a lo detallado

Un caso de uso es la descripción de un escenario de interacción -un uso- entre un actor y el sistema. Dicho escenario captura el requisito funcional que el sistema ha de cumplir y documenta lo que se ha discutido entre el equipo de desarrollo y el cliente en una forma simple, de fácil lectura y razonablemente exacta.

Todo bien hasta aquí.

En sistemas reales, es inevitable encontrarse con las siguientes dos situaciones:

  1. Algunos requisitos quedan sin descubrir y se convierten en riesgos.
  2. Algunos requisitos muy especificados jamás encuentran un lugar en el desarrollo.

O en otras palabras, si no tenemos cuidado, tendremos casos de uso que especifican en detalle algo que esta por fuera del alcance del proyecto en tanto uno o más puntos importantes habrán quedado en el anonimato y nos atacaran en castigo a nuestro olvido.

Ambas situaciones son peligrosas y aún si las controlamos representaran costos imprevistos que pueden hacer peligrar el proyecto.

¿Como podemos evitar estos problemas? Sin querer decir que es una receta mágica, lo que la experiencia nos enseña es que un modelo de casos de uso (y quizás todo sistema de requisitos) ha de preferir documentar primero a lo ancho, cubriendo áreas cuanto más amplias mejor, del sistema a desarrollar, antes de descender a los detalles de las partes de mayor interés.

Si suponemos un desarrollo cualquiera, este consejo de ir primero a lo amplio y luego a lo detallado, significa que tendremos muchos casos de uso apenas en estado de borrador, que delinean a grandes rasgos lo que se pretende del sistema en términos de su funcionalidad y el alcance del proyecto. Luego, según vayamos atendiendo los requisitos en nuestras iteraciones o fases, podremos dedicar algo de tiempo en obtener los detalles de cada caso de uso de manera de desarrollar el sistema correcto.

Esta aproximación es interesante también desde el punto de vista de la gestión del proyecto. Es posible crear un plan de proyecto que dedique algunas semanas a la creación de un modelo de casos de uso muy amplio pero sin mayores detalles, para luego decir cuales casos de uso van en cada una de las iteraciones.

Claro que al gestionar nuestros proyectos de esta forma hay que priorizar los casos de uso, según el riesgo y según su relevancia para establecer una arquitectura estable, conceptos que ahora si podemos entender sin mayores problemas: del total de casos de uso identificados, detallamos en las primeras iteraciones aquellos que sean identificados como de alto riesgo o como de mayor impacto en la arquitectura del software.

La otra vía es casi imposible de practicar: documentar en detalle los requisitos aún antes de comenzar a desarrollar la primera línea del código es decir que todo se puede saber de antemano, por lo que para aquellos de entre nosotros que carecemos de la omnisciencia vamos inevitablemente a cometer errores.

Entonces no tentemos al destino. Los requisitos cambian durante el tiempo de vida de los proyectos; no perdamos el tiempo capturando detalles que van a cambiar. Por otra parte, identificar a grandes rasgos las principales características que se nos piden es vital para tener una idea de la magnitud del desarrollo así como de los recursos que tendremos que invertir (tiempo, dinero, etc.) y finalmente, no tiene mucho sentido excluir a los requisitos de la planificación del proyecto, por lo que tenemos de una u otra forma que integrar a los casos de uso en el diseño del proceso de desarrollo.

Todo lo anterior nos obliga a todos quienes practicamos el desarrollo guiado por casos de uso a trabajar primero a lo ancho: prefiriendo lo amplio a lo detallado en tanto dichos detalles no sean impresindibles.

Anuncios

, , , , , , , ,

Deja un comentario

Casos de Uso: Herencia de Actores

La propiedad de mayor interés de los actores, más allá de su identidad, es la relación que estos guarden con los distintos casos de uso de nuestro sistema – las líneas que unen a unos con otros. Es decir que las dos partes más expresivas de un actor son el nombre propio y la activación de un caso de uso.

Aceptado lo anterior, la herencia de actores va a ser la distribución a lo largo de una jerarquía de roles, de las actividades a realizar, representadas estas como casos de uso. O lo que es lo mismo, la herencia nace como una forma de organizar los enlaces entre actores y casos de uso a fin de simplificar los diagramas y reducir la necesidad de presentar información repetida.

Nuevamente pero algo más técnico: a lo largo de la jerarquía de herencia lo que vamos a organizar son las activaciones de casos de uso de cada actor con ayuda de categorías intermedias o actores abstractos.

A diferencia de la herencia de casos de uso, considero que la herencia de actores es una práctica básica y que no tiene mayor problema en ser entendido por los stakeholders ni mucho menos, presenta problemas a los analistas. La razón es que la dificultad de la herencia de los casos de uso es la definición detallada de como los múltiples elementos de información de un caso de uso se comporta durante la herencia, dificultad esta que no existe en la herencia de actores por ser estos tan sencillos.

Como dije antes, la herencia de actores es una forma legible de mejorar la presentación de nuestros modelos, por lo que ejemplo que daré tiene por motivación el mejorar la legibilidad de un por lo demás, muy sencillo modelo de casos de uso.

A efectos del ejemplo, supongamos que trabajamos con un sistema de ventas, que permite tanto a los promotores como a los empleados del departamento de ventas el visualizar las existencias de productos así como la consignación de mercancía, pero que excluye a los promotores de la posibilidad de aceptar devoluciones. La situación es presentada en el siguiente diagrama de casos de uso:

Ejemplo de modelo de casos de uso sin herencia

Fig. 1 – Ejemplo de modelo de casos de uso sin herencia

Si se observa con atención el diagrama 1, se ve como las líneas de activación se cruzan entre actores. Claro que podemos tratar de organizar un poco mejor el diagrama para evitar esto, pero hemos de reconocer que esto solo será una solución temporal. Conforme se incremente la cantidad de casos de uso nos encontraremos una y otra vez en esta situación. No es solo una cuestión de estética, de utilizar líneas segmentadas bien podríamos llegar a hacer el diagrama por completo ilegible. Es entonces necesario un enfoque alternativo.

Dicho enfoque alternativo naturalmente va a ser la herencia. En el segundo diagrama se ven exactamente los mismos casos de uso y los mismos actores, pero se ha establecido una relación de herencia con respecto a un actor abstracto u operador como estrategia para presentar la información sin tanto barullo de líneas.

Ejemplo de modelo de casos de uso con relación de herencia entre actores

Fig. 2 – Ejemplo de modelo de casos de uso con herencia entre actores

En este segundo diagrama hemos indicado que el operador puede realizar las dos tareas comunes, en tanto que por herencia hemos dicho que los empleados del departamento de ventas son los únicos autorizados a aceptar devoluciones de mercancías. Aquí hay que notar que no he establecido una relación de herencia entre promotor y ventas, sino que por el contrario he introducido un actor abstracto nuevo, que articula la presentación del modelo sin correr el riesgo de equivoco: promotor no es ventas y ventas no es promotor. El hecho que compartan dos casos de uso si es algo digno de mención pero sus identidades siguen por completo desligadas.

La presencia de un actor abstracto puede ser considerada una fuente de ruido a la hora de explicar el modelo, pero dado que es solo para simplificar las líneas de activación encuentro que la sobrecarga de información no es nociva. Por otra parte lo que hemos ganado en claridad es en mi opinión, mucho mayor a lo que hemos sacrificado al utilizar una notación un poco más técnica.

, , , , , , , , , ,

13 comentarios

Un buen requisito debe ser atómico

“Un buen requisito debe ser atómico” lo digo y lo repito: Un buen requisito debe ser atómico. Sin embargo esto no significa que debe guardar alguna relación con la industria militar o la energía atómica. Si bien el átomo es un concepto de la ciencia moderna, el adjetivo atómico significa indivisible o dicho en otras palabras: único, singular, no susceptible a ser dividido.

Claro que eventualmente lo vamos a analizar y de ahí, que propongamos una relación de objetos que al colaborar den a lugar la funcionalidad requerida; pero el requisito en si mismo ha de describir un único requisito.

Y es que ocurre que en ocasiones un analista despistado, construye un cuerpo de requisitos donde uno o más de estos, contiene alguna forma de declaración compuesta, de forma que se refiere sin querer, a más de una característica.

La misma necesidad de atomicidad es requerida en los casos de uso. Un buen caso de uso debe hablarnos de un escenario de interacción completo y singular de manera que pueda ser tomado como una unidad indivisible.

Varios trucos se pueden dar para lograr este criterio de atomicidad: evitar las declaraciones compuestas y referirse en todo momento a una única característica son solo las dos primeras que me vienen a la mente. Sin embargo, como las recetas universales siempre tienen casos en que fallan, me limitaré a solo indicar lo que queremos: un requisito de buena calidad siempre ha de ser atómico.

El como lo logre el analista de requisitos es más cosa de habilidad que de consejos leídos por ahí.

, , , , , , , , , ,

5 comentarios

Un buen caso de uso captura valor de negocio

Una de las principales dificultades a la hora de desarrollar un cuerpo de requisitos para un sistema es el hecho innegable de la diferencia de formación entre los profesionales del desarrollo de software y los clientes de estos.

En tanto los desarrolladores cuentan con experiencia en algoritmia, análisis o modelado, los clientes suelen tener formación en contabilidad, finanzas, construcción o quien sabe en qué. Esta diferencia se extrapola a los puntos de vista de cada lado de la mesa, por lo que a la hora de definir el sistema que se desea es inevitable que el desarrollador note vacíos o faltas en la especificación (puntos como: seguridad, gestión de datos y otros aspectos técnicos) a la vez que el cliente puede hacer mucho hincapié en aspectos que a primera vista y desde el punto de vista del desarrollador son menos urgentes o se explicaron ya con unas pocas palabras.

Un poco por lo anterior es la muy conocida queja contra los clientes “no saben lo que quieren” pero en verdad la queja es debida a un fallo en el análisis del profesional de computación: los clientes especifican lo que les preocupa y esto no es ni de lejos, una especificación completa para una aplicación.

Paradójico quizás, en el sentido en que es contrario a la intuición de algunos, pero es que los clientes deben ver que los sistemas que solicitan responden a sus necesidades y aspectos técnicos que son del conocimiento del desarrollador los ven como parte de la solución técnica propuesta por este; lo que el cliente especifica es de valor para él y lo que no especifica es el margen de maniobra que se usa en la busqueda de la mejor solución técnica posible.

De todo lo anterior se desprende una regla básica para obtener un buen requisito y de ahí, un buen caso de uso: todo caso de uso ha de capturar valor de negocio. No hacemos casos de uso para especificar el comportamiento técnico del sistema, por lo que no tenemos casos de uso para indicar el ingreso al sistema o la generación de copias de seguridad. Si tales cosas no son del interés directo del cliente lo mejor es dejarlas por fuera del modelo de casos de uso. En cambio, aspectos quizás irrelevantes como la generación de un reporte o la aprobación de un supervisor a un paso del flujo de trabajo de la aplicación ha de representarse como caso de uso ya que es de interés para el cliente y le ayuda a decir lo que quiere decir sobre el sistema.

, , , , , ,

Deja un comentario