Archivo

Archivo de la etiqueta: casos de uso

Cuando traté sobre el área de proceso de verificación, comenté su estrecha relación con este área de proceso del nivel 3 de CMMI.

La verificación comprueba que cada artefacto se ha obtenido/construido como debe y en la validación se comprueba si es correcto, por ejemplo, si un artefacto son las historias de usuario o los casos de uso, la verificación constata si se ha seguido el procedimiento y técnica definida para la obtención de los mismos, lo cual no quiere decir que sean correctos o que realmente vayan alineados con las expectativas del usuario en el sistema que se está construyendo.

Por tanto en este proceso se define, qué se valida, cómo realizar las validaciones, dónde se realizan, qué técnicas aplicar, quienes participan y qué hacer con los resultados obtenidos de la misma.

En el último artículo que publiqué sobre la temática de los casos de uso, un lector me dejó el siguiente enlace (en inglés): Cómo implementar operaciones CRUD en UML, en el que como respuesta se indica que si la representación en los diagramas/modelos no aportaba valor, tal vez la mejor solución pasaba por no representarlos.

Y me parece una buena propuesta, ¿por qué no?, sin embargo sí que soy partidario que cómo mínimo, en el caso de los casos de uso se estereotipen los que se correspondan a gestiones CRUD y que se haga referencia a un guía, libro blanco, etc…, de la organización en la que se especifique cómo debería ser el comportamiento en este caso, en los maestros/detalle o en cualquier otro tipo de figura que se quiera estandarizar.

Los generadores de código suelen resolver la problemática del CRUD, sin embargo, no todos la resuelven de la misma manera. Si existen diversas empresas que desarrollan para tu organización, te encontrarás con que utilizan diversos generadores y la solución de salida será distinta, algo que en la medida de lo posible resulta interesante evitar.

Las pruebas de aceptación son aquellas realizadas por los usuarios con carácter previo al paso a producción de una nueva versión del producto. Se trata de pruebas de caja negra en un entorno de preproducción en la que se verifican si las funcionalidades pactadas para la entrega y recogidas en catálogos de requisitos, casos de uso, historias de usuario u otro hito documental, cumplen las expectativas del usuario.

El problema de este tipo de pruebas es que en demasiadas ocasiones los usuarios (o sus jefes) rechazan invertir tiempo suficiente para realizar estas tareas de testing y en otras, los equipos de desarrollo tampoco ponen demasiado interés en ello.

En desarrollos siguiendo metodologías clásicas o en cascada si no se ha hecho participar al usuario en fases posteriores al análisis y no se han hecho ajustes, las pruebas de aceptación servirán para poco porque probablemente, salvo que el desarrollo sea de poco alcance, habrán variado las condiciones iniciales o bien el usuario se encontrará con una implementación que aún respetando los requisitos (que está por ver) será complicado que verifique lo que se imaginaba que iba a hacer el sistema.

Sin embargo en mantenimiento evolutivos o correctivos pequeños, ciclos de vida iterativos incrementales (con sprints de corta duración) o mediante la aplicación de metodologías ágiles, este tipo de pruebas sí que tendrían una gran utilidad porque se evita pasar evoluciones a producción que pueden afectar a un trabajo eficiente de los usuarios con la aplicación.

Hace unas semanas comenté una posible solución para la representación de la gestión CRUD a través de casos de uso (es muy recomendable la lectura de los dos artículos que le dedico a esa solución porque la que planteo en este no es más que una adaptación o continuación de la misma y tal vez algún aspecto que exponga no se entienda de manera adecuada si no se toman como referencia ambos artículos).

En esta ocasión voy a realizar una propuesta para representar las relaciones maestro/detalle. De igual forma que en el caso anterior, no pretende dar una solución académica u ortodoxa, sino una solución que pretende ser práctica, sencilla y repetible que pueda ser adaptada a las características de la aplicación que se quiere representar o incluso al nivel de detalle al que queramos llegar en la definición de los casos de uso.

Como en el caso de la gestión CRUD, todo gira alrededor de los casos de uso de negocio y a través de ellos se orquestan las operaciones que se pueden hacer sobre el caso de uso.

En este caso creamos un caso de uso genérico al que podemos denominar Gestionar Maestro.

Sobre el maestro se realizarán normalmente las operación de consulta, inserción de nuevos registros, borrar registros (siempre y cuando no tengan registros asociados, salvo que se admita el borrado en cascada, cualquiera de las dos alternativas se tendrá que tener en cuenta en la definición del caso de uso que extiende al caso de uso principal y que representa a la operación de borrado) y actualizarlo.

Si se prefiere no sería necesario definir los casos de uso que representan a las operaciones de inserción y consulta, salvo que presenten alguna modificación respecto a las definidas en el caso de uso genérico del CRUD (Gestionar Entidad). Si se opta por esta opción, se tendría que poner el caso de uso Gestionar Maestro heredando de Gestionar Entidad.

Pues bien, sobre el caso de uso de actualización es donde extenderán los distintos casos de uso que se encargan de la gestión de los detalles. En la definición de este caso de uso genérico, valdrá con una relación de extend a otro caso de uso genérico que será Gestionar Detalle y que será el que se “sobreescribirá”, mediante una relación extend con el Maestro en cada representación particular de Maestro/Detalle.

Como estos casos de uso de detalle son mayoritariamente a su vez gestión CRUD o gestión maestro/detalle, también es posible simplificar su representación. Los que sean de gestión CRUD no será necesario definirlos, simplemente especificarlos y en todo caso lo único que habrá que hacer será reflejar las operaciones que se añaden o las que varían su comportamiento respecto a la definición inicial que se haga del CRUD (todo ello vendrá dado por la relación de herencia que habrá entre esta caso de uso y el caso de uso genérico “Gestionar Entidad”) y los que sean gestión de Maestro/Detalle podrán heredar a su vez del caso de uso “Gestionar Maestro”.

La precondición está formada por el conjunto de condiciones que se tienen que cumplir para que se pueda iniciar un caso de uso. En muchos casos supone la ejecución de casos de uso previos.

La postcondición refleja el estado en que se queda el sistema una vez ejecutado el caso de uso.

En ambos casos lo que se representa es un estado y no la ejecución de una serie de acciones (previas o posteriores al caso de uso).

Si te preguntas si debes cumplimentarlo en la ficha de descripción del caso de uso, no te puedo dar una respuesta general (aunque personalmente piense que cuesta poco trabajo ponerlos), ya que no se debe tratar de una decisión de carácter formal sino de una decisión basada en criterios prácticos, así que lo mejor es que para cada caso de uso te hagas la siguiente pregunta ¿aporta una mayor claridad para el usuario y para el equipo de desarrollo que para un caso de uso concreto ponga precondición y/o postcondición o éstas se sobreentienden?.

En el artículo anterior vimos una posible forma de enfocar la gestión CRUD en los casos de uso. En este voy a añadir un par de posibles soluciones a circunstancias que se pueden dar en la definición de los casos de uso de un sistema de información:

1) Puede haber alguna tabla maestra que tenga alguna operación expecial como por ejemplo el duplicado de un registro (puede ser útil sobre todo en aquellos casos donde cada registro tengo un número elevado de atributos).

¿Cómo podemos llevar esto al modelo de casos de uso?

Seguiriamos teniendo la entidad donde se realiza esta operación con una relación de herencia sobre el caso de uso “Gestionar Entidad”. Al hacerlo entendemos que se hereda el comportamiento del mismo, así como las relaciones que tenga. Como se trata de una operación más, pues a nivel de diagrama de casos de uso bastará con incluir un nuevo caso de uso en el que se describa la interacción sistema/actores para la realización de la operación que extenderá al caso de uso de la entidad, el cual no será necesario describir ya que en nada varía su funcionamiento.

2) ¿Y si alguna operación tiene un comportamiento especial en la gestión de una entidad?

Una posible solución consiste en que se describa esa operación en un caso de uso y extienda al caso de uso de la entidad (que a su vez tiene una relación de herencia con el caso de uso genérico “Gestionar Entidad”).

Se entenderá que ese caso de uso “sobreescribe” al caso de uso definido para dicha operación en el caso de uso genérico.

3) A veces hay entidades más complejas que comparten parte del funcionamiento de una gestión CRUD (como por ejemplo el alta o la consulta), ¿cómo representarlo?.

Una posible solución sería aplicar una solución similar a la que he expuesto en el caso anterior, todo lo nuevo tendría relaciones extend con respecto al caso de uso de gestión de la entidad (no confundir con el caso de uso genérico).

Quiero dejar claro que estas soluciones o estratégicas no buscan una aplicación purista de UML o de la estrategia de diseños de caso de uso, se trata de una forma de aplicar los mismos con el objeto de no que los casos de uso no representen repetición de comportamientos y así poder invertir el esfuerzo en describir aquellas interacciones actores/sistema que tienen un comportamiento específico y que sí resultan interesantes ser descritas de la manera más exacta posible.

Supongamos que una aplicación gestiona 40 tablas maestras, ¿qué aportan los casos de uso de esas 40 entidades si el comportamiento será el mismo, teniendo en cuenta que lo más probable es que su gestión CRUD haya sido codificada por un generador de código? (variarán los atributos que componen las entidades, tal vez alguna requiera de algún tipo de tratamiento especial, pero serán excepciones).

Soy de la opinión de que en estos casos no hay que ser purista y sí práctico.

Una posible solución es crear un caso de uso genérico (por ejemplo denominado Gestionar Entidad) y que se relacionen con él en modo extend un caso de uso por cada operación CRUD. Después del caso de uso genérico heredarían un caso de uso por cada entidad que tenga gestión CRUD (estos casos de uso solo aparecerían en el diagrama de casos de uso y no se describirían).

Las relaciones extend aportan funcionalidad al comportamiento definido en el caso de uso al que extiende cuando se verifica una determinada condición (que “activaría” el punto de extensión).

Una vez finalizado el caso de uso que extiende se vuelve al punto de extensión y continua la secuencia definida en el escenario, es decir, el viaje del extend es de ida y vuelta, como también lo es el de include, la diferencia es que el primero es opcional (se tiene que cumplir una condición) y el segundo se ejecuta siempre.

Es importante diferenciar los extend de los escenarios de error o de excepción donde se interrumpe el flujo del escenario que se está ejecutando y se pasa a un nuevo escenario donde se ejecuta otra secuencia de pasos que no tienen por qué volver al escenario que llevó a él.

Hace poco leí que de la misma manera que el mapa de una ciudad no es la ciudad, un diagrama de casos de uso no pueden sustituir a la descripción de los mismos.

La descripción de sus escenarios es lo realmente importante, aunque los diagramas proporcionan un apoyo importante para entenderlos.

Los casos de uso van un paso más allá de los requisitos, ya que representa interacciones entre el sistema y los actores y si se quiere que sean de utilidad deben poder ser entendidos por usuarios, aunque estos necesiten el apoyo de personal técnico, de los diagramas de casos de uso y de los diagramas de flujo que se puedan obtener a partir de la definición de las secuencias de pasos de sus escenarios.

Si la definición de casos de uso no se entiende, no sirve. Mucho esfuerzo para nada.

Cuando nos planteamos una estrategia de desarrollo basada en ciclos de vida iterativos e incrementales, como tenemos por ejemplo en las metodologías ágiles, se suele plantear la entrega de evoluciones del producto en períodos constantes de tiempo. Esto es lo que en algunas metodologías se conoce con el nombre de sprint.

La cantidad de trabajo que cabe en una entrega no deja de ser una combinación de estimaciones, ya que por un lado tenemos el parámetro velocity, que constituye la cantidad de unidades de trabajo que puede asumir el equipo de proyecto en una iteración (y que no podemos considerar estable, hasta que se hayan completado algunas de ellas) y por otro la estimación de esfuerzo de las diferentes historias de usuario o casos de uso que se van a implementar en este ciclo, pudiéndose utilizar para ello diferentes técnicas, como por ejemplo Planning Poker.

Contingencias en un proyecto de desarrollo de sofware puede haber muchas, así como errores en las estimaciones, por lo que no siempre será posible implementar lo previsto en cada iteración. Ante esto, hay diferentes opciones, por un lado está el overtime y será el equipo de proyecto en consenso con el cliente el que determine si merece la pena invertir ese tiempo extra, debiéndose tener en cuenta si se ha acudido recientemente al mismo.

Kent Beck cuando describe los principios y recomendaciones de la programación extrema indica que el overtime es un recurso que se debe utilizar solo en causas muy justificadas y de manera muy espaciada y yo estoy totalmente de acuerdo con él.

Otra opción será replanificar la fecha de entrega o entregar los hitos cerrados a la fecha de finalización del ciclo. La metodología en unos casos determinará qué camino utilizar. Soy de la opinión de que si las iteraciones se producen en períodos constantes de tiempo, no se debe romper el ritmo, sin embargo si no lo son, sí que se puede abrir la puerta a la replanificación.

También habrá que tener en cuenta las demandas del proyecto y el tiempo entre iteraciones. Por ejemplo, si no ha dado tiempo de corregir una incidencia y la siguiente iteración no es hasta dentro de cinco semanas, tal vez sí que habría que plantear un cierto retraso en la entrega.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.195 seguidores