¿Me cuentas la historia de caperucita roja?

Siempre hemos escuchado que los casos de uso deben de ser fáciles de leer, que deben de estar escritos en un lenguaje natural, y que nos narran historias que encapsulan una funcionalidad del sistema de una manera clara y comprensible. Nos encontramos con que resulta bastante fácil en ocasiones detectar los casos de uso críticos y los actores que interactúan con ellos, pero el verdadero problema viene al momento de escribir un caso de uso. La verdad nunca me explicaron a ciencia cierta cómo se debe de escribir un caso de uso, sabía como era su estructura, que debía tener pre-condiciones y post-condiciones, que debía tener un flujo principal el cual era el "happy path" y podía tener flujos alternos y excepciones por mencionar algunas cosas. El problema se me presentó al momento de redactar el caso de uso, no tenía ni la mínima idea de como iniciar. Me habían explicado que el flujo se debía describir como una conversación entre el actor y el sistema, que un actor siempre iniciaba la ejecución del caso de uso,etc. etc.

Me enfrentaba ante la difícil situación de redactar el primero de los flujos de una respetable lista de casos de uso pendientes. Me di cuenta que el escribir casos de uso no es tan fácil como la gente piensa. Me enfoqué en una de las principales recomendaciones de los casos de uso: debe ser comprensible para cualquier persona.

En un caso de uso un error común es pensar ya en el diseño de la interfaz del usuario y redactarlo como tal. Por ejemplo: 'El cliente hace click en el botón de seleccionar vuelo' o 'El sistema actualiza la ventana con un combobox que muestra la información de los vuelos disponibles'. Se supone que un caso de uso debe ser escrito en base a los requerimientos que el sistema debe satisfacer y por lo tanto, la interfaz no forma parte de dichos requerimientos, es mas bien una elección de diseño para después (normalmente al implementar un caso de uso aprobado). Otro error común es mencionar a la base de datos: 'El sistema guarda la información en la base de datos' o 'Se guardan los datos de la reservación en la tabla FLIGHTS'. Lo mas sano será mencionar: 'El sistema registra la reservación'.

Otra cosa muy importante a considerar es que un caso de uso debe describir un comportamiento, por lo tanto no podemos hacer 'todo' mediante casos de uso. Existen herramientas adecuadas para todo, no podríamos representar un requerimiento de desempeño mediante un caso de uso, o detallar estructuras de datos dentro de los casos de uso. Por ejemplo: ' El cliente introduce su nombre', El cliente introduce su apellido paterno' y así sucesivamente por cada campo que haga referencia a los datos del cliente. Lo mejor en este caso sería tener la estructura de datos detallada en un diagrama adecuado para ello y enunciar en el caso de uso algo así: 'El cliente proporciona sus datos generales'. Podríamos incluso hacer referencia como un anexo al documento de diseño que contiene los detalles de dicha estructura.

En las plantillas de casos de uso de Rational Rose me encontré con algo interesante: un caso de uso tiene una descripción breve, la cual nos resumirá la funcionalidad que se desea implementar, pero aún hay más... un caso de uso debe de ser breve, ya que los casos de uso demasiado largos y complicados serán más difíciles de entender. Por ejemplo, en el caso de uso 'reservar vuelo' de la aerolínea no deberíamos incluir los detalles de cómo se va a realizar el pago del boleto, lo mejor será crear un caso de uso específico para ello: 'pagar boleto'. Entonces utilizaremos el 'divide y vencerás' y el 'pequeño es mejor', y así enfocarnos a la verdadera funcionalidad del caso de uso que deseamos describir. No hay que olvidar que aunque sean casos de uso cortos debemos describir siempre el comportamiento para alcanzar la funcionalidad del caso de uso.

Tampoco debemos enfocarnos en casos de uso de bajo nivel, tales como 'establecer seguridad del sistema', o 'conectarse al servidor', ya que estos casos de uso son meramente técnicos y al usuario final no le interesan (recuerden la abstracción) y batallaría mucho para interpretarlos. Generalmente estos casos de uso se elaboran detalladamente por personas que a final de cuentas tendrán la responsabilidad de implementar esas funcionalidades y características en el sistema.

Como punto final, un caso de uso es una historia que describe una funcionalidad, siempre debemos especificar quien ejecuta que acción, y redactar de manera comprensible cada paso, sin ambigüedades, y de una manera simple y breve.... mmm creo que quedé como al principio, en fin. Mejor les dejo esto para pensar un rato... ¿Cual sería el diagrama de casos de uso del cuento de caperucita roja?

This is like a flashback!

Uno de mis temas favoritos es Flashback de Calvin Harris. El hecho de que a veces sentimos que una situación ya la habíamos vivido, o el hecho de tener un recuerdo muy borroso sobre algo que probablemente fue traumático, pero que no alcanzamos a recordar a detalle lo ocurrido. En un proyecto de software en muchas ocasiones ocurren estos 'flashbacks' y a continuación les daré algunos ejemplos.

El primer flashback lo asocio con la corrección de errores de software, cuantas veces nos hemos enfrentado a un error de codificación difícil de corregir (si los famosos bugs) y le invertimos bastante tiempo, incluso días en detectar donde está el error. Muchas veces al final nos encontramos que lo que está provocando semejante error es una insignificancia, la cual nos ha costado bastante esfuerzo en depuración y un buen dolor de cabeza. Una vez corregido el error nos olvidamos de él... hasta que tiempo después vuelve a ocurrir nuevamente, y ¡ahí es donde viene el flashback! nos encontramos con un error de software que no tiene una explicación lógica, algo que funcionaba y de la noche a la mañana dejó de hacerlo, y lo peor del caso, un error similar (bueno, igual pero en otro proyecto) a uno que ya había ocurrido anteriormente y ya le habíamos dado solución. Y nos ponemos a pensar... ¡si esto ya me había pasado!, ¡si recuerdo que batalle tres días para corregirlo!, ¿alguien recuerda cómo lo solucionamos la vez pasada? Y por mas que intentamos recordar no lo logramos, entonces viene nuevamente el arduo proceso de depuración hasta llegar nuevamente a la solución, si en el camino logramos recordar cual era evitaremos seguir desperdiciando tiempo. Pero, ¿cómo llegamos a este flashback? simple, por la mala costumbre de no documentar los errores de codificación, y sobre todo las soluciones que les dimos a dichos errores. Que fácil sería abrir un libro (en el mas modesto de los casos) y localizar el error que nos acaba de ocurrir nuevamente y al que en otras ocasiones ya habíamos dado solución. El flashback sería simplemente una reunión entre los miembros del equipo para si alguien vagamente recuerde de un caso similar y proceder a revisar nuestro 'libro de registro de posibles flashbacks'. Recuerdo un proyecto en el debido a su importancia tuvimos que invertir algo de tiempo para implementar un software para seguimiento de errores, lo llamamos 'Bug Tracker' y nos fue de mucha utilidad. Si no tenemos el tiempo para diseñar un software para registro de errores bastará con llevar un registro manual de los errores en una libreta.

El segundo flashback que voy a mencionar es el que se encuentra relacionado al proceso de desarrollo de un proyecto de software, y se presenta cuando cometemos un error durante el mismo, ya sea administrativo o de ingeniería. Muchas veces nos encontramos con actividades que en vez de beneficiar al desarrollo del proceso lo complican, ya sea burocracia, detalles excesivos en el diseño, una mala planeación, omisión de tareas críticas, etc. y simplemente las vamos resolviendo 'al vuelo' y con bastantes presiones de tiempo. Una vez finalizado el proyecto nos apresuramos a darle cierre y olvidarnos para siempre de él. Mal hecho, el no realizar una reunión post-mortem del proyectos en donde documentemos las lecciones aprendidas provocará que mas adelante se puedan repetir los mismos problemas en otros proyectos, y al igual que en el primero consumirá tiempo, dinero y esfuerzo (siempre quise usar esa frase, es todo un clásico). Por lo tanto para evitar un 'esto ya lo había vivido' lo mejor será documentar nuestros éxitos y nuestros fracasos para cada proyecto de software y sobre todo ir retroalimentando nuestro proceso de desarrollo de software con el fin de evitar repetir los mismos problemas en un futuro (y tener otro flashback).

El tercer flashback del que les quiero hablar es uno que siempre debe estar presente en nuestros proyectos, las pruebas de regresión. Este flashback consiste en repetir con cada integración todas las pruebas realizadas sobre dicho software (si... TODAS). De ahí la importancia de diseñar nuestros casos de prueba y utilizar herramientas automatizadas para su ejecución. Pero ¿porqué es necesario probar todo nuevamente?, pues simple, para garantizar que todo lo que ya funcionaba siga funcionando. La integración es un proceso delicado, puede ser que entre las distintas configuraciones de software existentes se introduzca y propague un error, y podemos quizás dar por hecho de que una funcionalidad previamente probada siga cumpliendo con su cometido, y no probarla nuevamente, hasta el momento en que llegue a manos del usuario y entonces surja el error, y nuestra respuesta será... ¡si eso ya funcionaba! (vaya 2 flashbacks a la vez).

Como siempre, tomen mis opiniones para crear un caos de su proyecto, ya que nuestro objetivo del blog es desadministrar proyectos (creo que tuve un flashback).

Caminito de la escuela

Hace unos momentos me encontraba fuera de una escuela primaria platicando con una persona, eran las 7:40 A.M. y todo parecía muy tranquilo, poco tráfico, escasos alumnos ingresando al plantel, los padres de familia y alumnos se miraban muy contentos, relajados y 'platicadores'. Es mas, el oficial de tránsito que vigila que se respete el cruce de los alumnos ni siquiera tenía que intervenir, ya que los conductores cordialmente cedían el paso. Así pasaron 10 minutos más y aún todo se miraba tranquilo. La plática se alargó y por un momento hasta dudé de que hubiera actividades en dicho plantel educativo. De repente todo dio un cambio radical, a las 7:55 se desató el caos, por una parte veía llegar a los padres de familia muy tranquilos con sus hijos y sus caritas de desesperación, y por otra lo contrario, los padres muy molestos y regañando a sus hijos de que se apurasen que ya era muy tarde. El tráfico para que les cuento, había una fila inmensa de carros, todo mundo tocando el claxon y ahora si nuestro oficial de tránsito ni buscaba que hacer ya que nadie cedía el paso a los estudiantes. Por cierto, ya me ha tocado con anterioridad ver que entre esa fila de carros hay un 'profesor' que imparte clases en dicha escuela pero por las tardes, y en la mañana imparte clases en una escuela cercana, pues me ha tocado ver como este profesor casi le pasa encima a los alumnos, como toca como desesperado el claxon, y no respeta en lo mínimo la cortesía de ceder el paso, claro me imagino que entra a las 8:00 a su trabajo. Bueno la historia no acaba ahí, a las 8:05 aún seguía el tráfico, ya en menor afluencia, uno que otro alumno llegaba, algunos con prisas, algunos con toda la tranquilidad del mundo, digo, para que apurarse si ya de todas formas llegaste tarde. Echo un vistazo por dentro de la escuela y veo la formación de alumnos y a un grupo de niños separados de los demás notablemente nerviosos y mirando hacía el suelo mientras eran reprendidos por el director... eran los retardados. ¿cómo llegaron allí?, ¿fue por culpa directa de ellos?, ¿no saben que tienen que llegar a la hora indicada? ¿pudieron haber evitado el llegar tarde? ¿dependía de ellos? ¿se levantaron tarde? ¿no tenían listas sus cosas? ¿se tardan mucho en sus actividades para salir a la escuela? ¿hacen cosas que no deberían como ver TV por las mañanas? y me pregunto a cuantos de ellos les habrá dado tiempo de desayunar.

Al menos en este caso el castigo por llegar tarde fue sólo eso, que todos te vean que llegaste tarde y que el director los regañe en público. Pero en el caso de un proyecto de software... ¿cual es el castigo? ¿cómo evitar llegar tarde? después de todo para que preocuparnos por la fecha de entrega si buscamos desadministrar y que nuestro proyecto sea un fracaso costoso.

Por cierto, al ver que eran las 8:07 me despedí con un 'ya se me hizo tarde' y salí volando a mi oficina faltando a no se cuantas leyes de tránsito.