Buscar en Gazafatonario IT

viernes, diciembre 22, 2006

Lecturas Fundamentales 5 (2 de 2)

Lectura Fundamental Anterior: “Casos de Uso: ¿Cuándo Están Terminados? ... ¿Y qué hacer con ellos a continuación?” Parte 1

Lectura # 5
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2
Previamente en Lecturas Fundamentales…

En la parte 1 de este artículo enunciaba mi Ley de la Terminación del Caso de Uso. Decía que un caso de uso está terminado cuando se cumplen al menos diez de trece condiciones. Las primeras seis condiciones a las que me refería son:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
5. ¿Los subflujos en el caso de uso están modelados con precisión?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Y aportaba algunos elementos de criterio para hacer la revisión con cada uno de esos puntos. Bien, estas son las demás:
¿Las interacciones del actor y la información intercambiada están claras?
¿Es comprensible la forma como el actor proporciona datos al sistema mediante el caso de uso y qué datos suministra? Esto es, establecer si el actor debe seleccionar de una lista o debe digitar el dato o debe escoger una de un conjunto de posibles opciones; o si debe especificar la ruta o la dirección de un archivo de datos o si debe autorizar la carga de información mediante un proceso.
También debe hacerse evidente el tipo y mecanismo de validación, si existe, para cada dato intercambiado con el sistema. En este contexto, “hacerse evidente” quiere decir “especificar o documentar”, que sea explícito en el caso de uso. No porque algo nos parezca evidente, como especificadores de requisitos, le parecerá evidente a los demás, hay que hacerlo incuestionable, axiomático.
¿La descripción breve ofrece un cuadro verdadero del caso de uso?
Aunque la descripción breve no hace parte de la funcionalidad establecida en el caso de uso, ésta debe brindar a los lectores del mismo una visión horizontal, concisa, que permita formar imágenes mentales precisas de lo que hace el caso de uso y hasta un bosquejo del mismo.
Durante la fase de exploración del proyecto, la fase de Concepción o Inicio, cuando se descubren los casos de uso, la descripción breve del caso de uso juega un papel muy importante no solo para los analistas y usuarios, sino para el Arquitecto del Software, que cuenta con que le facilitemos de estas descripciones para que comience a elaborar la arquitectura del producto, al menos, la arquitectura preliminar, o para que tome decisiones acerca de llevar a cabo pruebas de concepto o no.
¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (Menos de 20)
El límite puede ser 20, 15, 25, 17, 13, 23. “Pequeño” es un término relativo, eso lo sabemos de sobra. Puede haber casos de uso “grandes”, de 30, 50 ó 70 pasos; sin embargo, éstos deben ser la excepción. Además, el tamaño es un índice de complejidad, pero no es el único. Y siempre puede suceder que un caso de uso de 50 pasos sea sencillo y uno de 10 pasos sea complejo.
En cualquier caso, cuando el número de pasos de un caso de uso empieza a crecer, debemos también comenzar a pensar en que quizás se pueda dividir. De hecho una de los lineamientos a seguir para crear casos de uso incluidos es precisamente la máxima de “divide y vencerás” que, en esta oportunidad, podríamos traducir como “divide y entenderás.”
Definición 12. Un caso de uso incluido es aquel cuyo comportamiento (funcionalidad) puede ser insertado en el comportamiento definido para otro caso de uso, llamado caso de uso base.
La inclusión, junto con la extensión y la generalización, son las relaciones que pueden existir entre casos de uso. En una lectura fundamental posterior les hablaré en detalle de este tema de las relaciones entre casos de uso.
¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
En la lectura fundamental #1 anotaba que, desde el punto de vista del usuario, un caso de uso es una pieza indivisible de software, simple, con un objetivo exacto y único.
Siempre debemos buscar estas características en el caso de uso. Si observamos que el caso de uso hace varias tareas desacopladas, si la complejidad de algunas de sus acciones lo hace incomprensible para los usuarios o aún para los desarrolladores, si tiene un número excesivo de pasos o de secuencias alternativas, si la profundidad de las anidaciones (decisiones lógicas o ciclos) es mayor de dos (por ejemplo, si hay secuencias alternativas que se derivan no de la secuencia básica o principal, sino de otra secuencia alternativa), si parte de las acciones de un caso de uso se puede “ocultar” deliberadamente (en casos de uso incluidos) sin que se afecte el matiz que se obtenga de su lectura, si para entender el caso de uso se hace necesario acompañarlo de adjuntos como prototipos de usuario, manifiestos en prosa sobre la funcionalidad del caso de uso u otros elementos de diseño, entonces seguramente será necesario fraccionar la especificación en dos o más casos de uso.
Sí, otra vez, simplicidad es la clave.
¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
En términos generales, un caso de uso incluido no es autónomo en cuanto a que por sí solo no entrega un resultado de valor observable para el actor. Esto lo convierte en dependiente del caso de uso base.
A pesar de tal interdependencia, el comportamiento de un caso de uso incluido no debe verse sobre-influido por un cambio al caso de uso base, sobre todo, cuando la razón de la inclusión es una factorización en la funcionalidad de varios casos de uso, es decir, distintos casos de uso tenían una funcionalidad común que se eliminó de éstos y se incluyó en un único caso de uso incluido por todos los demás.
De esta forma, si al modificar la funcionalidad de uno de los casos de uso, se acomete contra la funcionalidad “incluida”, todos los casos de uso que la usan deben someterse a una minuciosa inspección con el fin de mantener la consistencia en el modelo funcional o de casos de uso.
¿Cada caso de uso es independiente del resto?
Es realmente necesario abordar este chequeo con un pensamiento sistémico que nos permita no sólo modelar el producto sino también obtener varias perspectivas del modelo.
En particular, al revisar las interrelaciones de los casos de uso en los distintos modelos del sistema, el resultado debe ser uno que exhiba bajo acoplamiento y alta cohesión. Bajo acoplamiento quiere decir que hay poca o ninguna interdependencia entre el caso de uso y su entorno (otros casos de uso u otros actores distintos al que ejecuta este caso de uso). Entre tanto, el principio de alta cohesión señala que el caso de uso ejecuta una tarea simple y precisa y alcanza un objetivo predeterminado. En este contexto, los casos de uso a los que me refiero son casos de uso concretos, ejecutados por actores del sistema; esto excluye, si me permiten la disfunción, a los casos de uso incluidos y a los abstractos o generalizados. Estos últimos son aquellos que no se implementan, pero que existan para estabilizar el modelo y entenderlo mejor.
Este, que es un patrón común de diseño heredado cuidadosamente de las técnicas estructuradas de programación de computadores, requiere tanto un enfoque de bajo nivel para verificar el acoplamiento, como un punto de vista más alto para cotejar la cohesión. De allí la necesidad de hacer cálculos holistas con los elementos funcionales del sistema, o sea, con los casos de uso.
¿Este caso de uso hace algo muy parecido a otro caso de uso?
De ser así, quizás deberían convertirse ambos en un único caso de uso.
Ocurre mucho con los casos de uso descompuestos funcionalmente, que deberíamos evitar. Estos tienden a parecerse, porque, por ejemplo, uno es para adicionar un elemento y el otro es para actualizar los datos de ese elemento, digamos un producto o un cliente.
Pero en casos de uso no descompuestos funcionalmente también suele suceder, sobre todo, cuando obtenemos la visión de un rango heterogéneo de usuarios y cada uno de ellos expresa sus necesidades de acuerdo a sus criterios y ambiente de trabajo. Reservar Vuelo y Comprar Tiquete quizás sean dos casos de uso distintos, pero también pueden llegar a convertirse en uno solo, dependiendo de la meta que se quiera alcanzar con uno u otro.
¿Y qué hacer con los casos de uso una vez están terminados?
Realmente no es necesario terminar un caso de uso para continuar con su ciclo de vida. Desde la descripción breve y el esbozo que se obtiene durante la fase de Inicio del proyecto, ya es posible empezar a hacer el análisis y diseño del caso de uso. En este punto ya también el arquitecto puede considerar distintas variables para seleccionar los casos de uso más críticos o complejos para la arquitectura del software, aquellos que definen las bases del producto a construir.
Más adelante, durante cada una de las iteraciones, al completar la secuencia básica es factible diseñar prototipos, “realizar” los casos de uso y comenzar a implementarlos. Y también es posible diseñar los casos de prueba.
Todos estos eventos subsiguientes a la especificación de un caso de uso, serán temas que ocuparán nuestras lecturas fundamentales durante 2007.
Hasta entonces y feliz navidad.

Lectura Fundamental Siguiente: De Procesos y de Humanos.

lucho.salazar@gmail.com

jueves, diciembre 07, 2006

Lecturas Fundamentales 4 (1 de 2)

Lectura Fundamental Anterior: “Casos de Uso: Del Todo y de Sus Partes”
Lectura # 4
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 1 de 2
Volvamos a considerar el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Frecuente
Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.
Objetivo: Proporcionar un mecanismo rápido y seguro a un Pasajero Frecuente para hacer reservas en vuelos nacionales o internacionales de ida y regreso. No se incluye la funcionalidad de pagar o cambiar el estado de la reserva.
Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).
Secuencia Básica:
1. El caso de uso inicia cuando el Pasajero decide Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso, incluyendo la hora de ambos viajes
6. El sistema valida que la fecha de regreso, incluyendo la hora, sea superior a la fecha de ida, incluyendo la hora, y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina
Secuencia Alternativa 1:
4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.”
4A2. El caso de uso termina
Secuencia Alternativa 2:
6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina
Secuencia Alternativa 3:
6B. La fecha/hora de regreso es inferior a la fecha/hora de ida
6A1. El sistema muestra el mensaje: “La fecha de regreso es inferior a la fecha de ida. Especifíquelas nuevamente.”
6A2. El caso de uso continúa en el paso 5 de la secuencia básica
Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.
Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.
Advertencia: todavía este continua siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso.
Voy a cerrar este primer ciclo de lecturas fundamentales sobre casos de uso basándome precisamente en una corta pero sustanciosa lista de chequeo para revisar casos de uso. Vale la pena decir que esta lista hace parte del proceso de Ingeniería de Requisitos institucionalizado en InterGrupo hace ya algún tiempo y que a su vez está cimentada en RUP.
Ley de la Terminación de un Caso de Uso
Un caso de uso está terminado cuando se cumplen al menos diez de las siguientes trece condiciones:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
5. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
7. ¿Las interacciones del actor y la información intercambiada están claras?
8. ¿La descripción breve ofrece un cuadro verdadero del caso de uso?
9. ¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (menos de 20)
10. ¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
11. ¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
12. ¿Cada caso de uso es independiente del resto?
13. ¿Este caso de uso hace algo muy parecido a otro caso de uso? De ser así, quizás deberían convertirse ambos en un único caso de uso.
¿El caso de uso tiene especificado el Actor que lo inicia?
No habría mucho que decir de este control si la búsqueda y posterior definición de los actores de un sistema no estuviera hoy tan desestimada. En principio tengo que decir que intentar definir un sistema sin conocer sus actores es un error bastante común. Antes que cualquier otra cosa es importante conocer para quien construimos el sistema, luego procedemos a documentar lo que hace cada uno de esos actores.
Debemos indagar por el perfil del actor y sus responsabilidades en el sistema. Recordemos que un actor bien podría ser alguien “abstracto” para el negocio, es decir, no equivale a un rol desempeñado por una persona o un grupo de personas dentro del negocio, razón por la cual, luego de hacer la abstracción, hay que mirarlo desde el punto de vista del sistema.
Con ese perfil, evaluamos si las actividades descritas en el caso de uso pueden ser ejecutadas por ese actor. Este es realmente el punto de chequeo, no simplemente asegurarnos de que haya un nombre cualquiera en la sección Actor del caso de uso.
Ahora bien, un caso de uso normalmente tiene un único actor que lo inicia; sin embargo, el caso de uso puede tener más actores. En este caso, los demás actores son pasivos, es decir, o simplemente reciben información, como en el caso de un sistema o un dispositivo externo, o son espectadores participes del proceso del negocio que envuelve el caso de uso, como en el caso de un cliente en un punto de venta. En cualquier caso, es importante enumerar a todos los actores que intervienen en el caso de uso por el horizonte que se extiende tanto para los analistas como para los desarrolladores y probadores del producto, en cuanto al entendimiento del mismo.
En el ejemplo, un “simple” Pasajero puede significar un cliente casual de la aerolínea, mientras que un Pasajero Frecuente es precisamente una persona que toma vuelos con una frecuencia uniforme o que, al menos, está registrado como tal ante la compañía.
¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
Los usuarios son la última línea de defensa del caso de uso, son quienes confirman que está terminado, son quienes lo aprueban. Es tarea del Especificador de Requisitos obtener de ellos la información suficiente y necesaria para terminar el caso de uso. Siempre tenemos a la mano el “¿Qué más debo saber acerca de esta funcionalidad?” Otras preguntas importantes son: ¿Quién más está interesado en este caso de uso? ¿Quién debería leerlo? ¿Quién debería aprobarlo?
Una vez se tiene esa información, el revisor del caso de uso, si existe, puede indagar sobre el número de personas que leyeron y aprobaron el caso de uso para establecer si eso constituye una muestra representativa para dar por terminado el caso de uso.
En el ejemplo, puesto que el Pasajero es un actor externo a la compañía, alguien dentro de ésta es quien lo representa, es decir, es quien decide cómo quiere que los clientes de la aerolínea perciban el sistema. Por ello es importante documentar desde el principio del proyecto, no solo quienes son los usuarios finales, sino quienes serán sus representantes a lo largo del ciclo de vida.
¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
Es más que evidente. Otra vez, es sólo el usuario y nadie más que el usuario, quien decreta la correcta finalización del caso de uso. Por ello el caso de uso no debe incluir aspectos técnicos o detalles del diseño o implementación del mismo.
Se evidencia la participación dinámica y constante del usuario o de un grupo de usuarios durante la Ingeniería de Requisitos (por supuesto, también durante el resto del ciclo de vida, pero sin duda es esta etapa donde se hace más evidente la necesidad de contar con el mayor número de usuarios del producto).
El usuario regular no está interesado en conocer lo que ocurre “detrás del telón” del sistema. Para él sólo es importante el grupo de acciones donde él participa activamente, donde interactúa con el software y finalmente es quien indica si está satisfecho con lo que está documentado en el caso de uso.
Si, por ejemplo en el paso 6, dijéramos que la lista de vuelos se busca haciendo una intercalación multivía seguida de una selección por reemplazamiento, estaríamos adicionando detalles que confundirían innecesariamente al usuario común y corriente. Es más, ni siquiera tendríamos que mencionar las tablas y mucho menos los componentes involucrados en dicha búsqueda y selección.
¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
Si mantenemos el caso de uso en su estado más simple, aunque con el suficiente detalle para pasar al siguiente estado, los momentos de inicio y finalización de cada secuencia de acciones deberían estar a la vista de todos.
Los errores más comunes se encuentran en las secuencias alternativas, al decidir si la acción retorna a la secuencia básica o si el caso de uso termina. También pasa que si el caso de uso tiene varios escenarios a partir de una misma acción, luego de escribir dos o tres de ellos perdamos el foco de la “horizontalidad” del caso de uso y empezamos a cubrir detalles que nos podrían llevar, desde el punto de vista del usuario, por caminos insubstanciales del caso de uso.
¿Los subflujos en el caso de uso están modelados con precisión?
Luego de mi lectura fundamental # 1 no volví a mencionar la palabra modelo. No es que cuando estamos documentando casos de uso no estamos modelando, es que precisamente a veces perdemos la conciencia de que es eso lo que estamos haciendo, aunque sea puramente texto lo que escribamos. De hecho, el modelo de casos de uso es mayormente texto.
Así que cuando hablo de modelar subflujos del caso de uso con precisión, me refiero a que proporcionemos toda la información necesaria al modelo: lugar donde se inicia el subflujo, motivo del subflujo, acciones del subflujo y método de terminación del subflujo.
Cabe decir que los subflujos no son sólo secuencias alternativas, también pueden ser “porciones” de la secuencia básica, normalmente, porciones pequeñas y extremadamente simples.
Sí, el concepto clave es simplicidad.
¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Una cosa es especificar un actor y otra es si ese actor representa adecuadamente al grupo de usuarios que ejecutará el caso de uso. Es posible que haya diferencias entre lo que piensa el representante de los usuarios asignado para proporcionar la información de, revisar y aprobar el caso de uso, y lo que finalmente quede documentado.
Un trabajo de campo, donde aseguremos que varios usuarios lean y acuerden el caso de uso ayuda mucho en estos casos. Así evitamos esa escena de terror que más de uno hemos vivido cuando mucho tiempo después de la especificación, probablemente durante las pruebas de certificación o ya en producción, nos preguntan “¿Quién dijo eso?”
De otro lado, el propósito puede estar implícito a lo largo y ancho de la declaración del caso de uso, o bien puede estar explícito en una sección inicial del mismo. Esta última opción es mi favorita porque permite verificar la consistencia del caso de uso lo mismo que medir su valor para el sistema y para los usuarios.
El propósito, si se especifica, debe escribirse a priori, quizás durante la etapa de descubrimiento del caso de uso, para que posea la menos subjetividad posible. Por supuesto, siempre podemos afinarla, aún antes de presentar el caso de uso para su última revisión.
El propósito debe incluir lo que el actor consigue del caso de uso y también lo que no consigue. Esto ayuda en las etapas posteriores al resto del equipo de desarrollo del proyecto a construir un sistema de alta usabilidad y gran aceptación.
Lo que Falta
Bien, hasta aquí la exploración a los primeros aspectos fundamentales que nos ayudan a decidir cuando un caso de uso está terminado. En la siguiente entrega volveré con el final de este artículo.
Esta lectura #4 continuará. Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”

jueves, noviembre 23, 2006

Lecturas Fundamentales 3

Lectura Fundamental Anterior: “Casos de Uso: Origen, Especificación y Evolución”

Lectura # 3

Casos de Uso: Del Todo y de sus Partes


Consideremos el siguiente caso de uso típico de un sistema de reservaciones:

Caso de Uso: Reservar Vuelo

Actor: Pasajero Aerolínea

Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.

Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).

Secuencia Básica:

1. El caso de uso inicia cuando el Pasajero opta por Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema valida que la fecha de regreso sea superior a la fecha de ida y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina


Secuencia Alternativa 1:

4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.” 4A2. El caso de uso termina


Secuencia Alternativa 2:

6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina


Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.

Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.

Advertencia: este sigue siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso. Además, no es un caso de uso “Terminado”.

Definición 6: La descripción breve o simplemente descripción del caso de uso es un compendio informativo –tres o cuatro líneas a lo sumo- sobre el caso de uso. Resume las principales características del caso de uso pero en ningún momento hace parte de la especificación funcional del mismo. En esta sección se pueden considerar algunas condiciones bajo y para las cuales se ejecuta el caso de uso, se pueden enumerar algunos requisitos no funcionales y otros detalles relevantes. Las descripciones breves surgen durante la fase de Concepción del proyecto, cuando se identifica el caso de uso y no reemplazan el bosquejo o borrador del caso de uso, que surge a continuación de ésta. Un indicador de que hemos entendido el caso de uso o la funcionalidad requerida es cuando escribimos esta descripción en menos de un minuto y a “lápiz alzado” como dicen los dibujantes. Sin embargo, esta es una práctica que toma tiempo y se puede lograr después de muchos casos de uso documentados.

Definición 7: Las precondiciones constituyen el estado en el que debe estar el sistema para que el caso de uso se ejecute. Esto quiere decir, lo que debe ocurrir en el sistema para que sea posible “habilitar” el caso de uso y que este se pueda ejecutar. Pensemos, por ejemplo, en una funcionalidad ampliamente usada por todos: Copiar y Pegar texto. Un prerrequisito de Copiar es Seleccionar el texto; y un prerrequisito de Pegar es Copiar el texto.

Una precondición se fija en prosa, como en nuestro caso de uso en demostración. O en términos de otros casos de uso, es decir, enumerando el o los casos de uso que deben ejecutarse para correr este. O usando una combinación de las dos. Esto último ocurre porque es posible que no hayamos identificado los casos de uso condicionantes, o porque no está claro de estos casos de uso cual es la precondición establecida y porque también hay un conjunto de especificaciones funcionales que no quedan escritas en términos de casos de uso y alguna de ellas puede ser un prerrequisito. Además, porque es mejor para el usuario que usemos su terminología y le evitemos leer un caso de uso completo para que entienda el estado final del mismo.

Las precondiciones son a la vez una forma de validación, ya que esas “condiciones” deben cumplirse antes de crear la instancia del caso de uso. Esto disminuye el número de validaciones que debe hacer dicho caso de uso una vez ha iniciado su secuencia de acciones.

La precondición del ejemplo se refiere al proceso o módulo donde el Pasajero se identifica ante el sistema: debe proporcionar su identificación y su número de pasajero frecuente para que el sistema conozca de quien se trata.

Las precondiciones además le hablan al desarrollador al oído. Le cuentan del mecanismo que debe usar o tener en cuenta para habilitar o deshabilitar opciones de la aplicación. En el ejemplo: si un pasajero no se ha identificado ante el sistema como Cliente o Pasajero Frecuente, la opción Hacer una Reserva Aérea estará deshabilitada o invisible al usuario.

Ahora bien, los tres errores más comunes que cometemos al definir una precondición son:

· Incluir una precondición “lejana en el contexto del proceso” al caso de uso, es decir, algo que no tiene relación directa con el caso de uso en cuestión. En el ejemplo, una precondición así sería “Las ciudades hacía y desde donde se originan los vuelos deben estar matriculadas en el sistema.” Ciertamente ésta podría ser una precondición del caso de uso, en cuyo caso lo afectaría indirectamente; En particular, ésta es una precondición de todo el sistema: sin las ciudades origen y destino registradas, el sistema no puede arrancar.

Aquí es importante precisar que una precondición no depende de esquemas temporales del proceso o del orden de ejecución en el tiempo. La precondición debería ser agnóstica de ello, desligándose del momento en que ocurre; lo que interesa es que se cumpla el estado, no el momento en que ese estado es establecido.

· Incluir una precondición que, en vez de serlo, es una condición que el sistema debe validar durante la ejecución del caso de uso. En el ejemplo, decir que “Debe haber vuelos disponibles” no es una precondición porque es algo que el caso de uso debe verificar a medida que se establecen las condiciones del vuelo. Tampoco lo es: “El Pasajero debe estar matriculado como Pasajero Frecuente en el sistema.” Esta es más bien una condición que se debe verificar en el caso de uso “Validar Pasajero”, el cual sí es una precondición del caso de uso.

Aquí también es importante aclarar que a veces una precondición puede convertirse en una validación en las primeras de cambio del caso de uso. Es decir, si no es compleja, entre otras características, la precondición bien podría incluirse como parte de las acciones del caso de uso.

· Incluir una precondición “no funcional”. Por ejemplo: “El Pasajero debe tener conexión a Internet” o “El Navegador debe soportar el protocolo SSL.” Aquí realmente estamos hablando de recursos físicos o de ciertas condiciones con las que el usuario no tiene que lidiar en lo absoluto.

Finalmente, las precondiciones son opcionales. Es posible, y ocurre muchas veces, que un caso de uso simplemente no tenga precondiciones.

Definición 8: La secuencia básica, llamada también Secuencia Principal, está formada por el conjunto de acciones que más ocurren en el caso de uso. Normalmente es la única que se describe por completo, es decir, de principio a fin.

Ahora bien, las acciones de un caso de uso, son acciones “planas” y, muchas veces, simples. En la Lectura 2 dije que no incluyen aspectos técnicos ni de diseño de pantallas ni otros detalles que pueden hacer difícil de leer y entender el caso de uso. Por lo general, un caso de uso inicia por una acción directa de un usuario o Actor del sistema. Esa acción casi siempre significa que el usuario decide u opta por hacer algo en el sistema para lo que tiene privilegios.

La elección de nombres, tanto de casos de uso como de otros elementos del proceso: Actores, datos y documentos, no debe hacerse a la ligera y mucho menos debe tomarse como algo sin importancia. Recuerden que eso afectará, al menos, la vida laboral de muchas personas. Como técnicos somos muy dados a seleccionar nombres ostentosos, adornados de tecnicismos innecesarios o incomprensibles para el usuario final; o, entre un grupo posible de nombres “del negocio” escogemos el menos usado en el entorno del usuario o alguno que tenga connotaciones distintas en el contexto de ese usuario: Reservar Vuelo, Hacer Reserva, Hacer una Reserva Aérea, Reservar, Hacer Reservación de Vuelo y Apartar un Viaje son algunos posibles nombres para el caso de uso.

Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve. En el caso de InterGrupo, con oficinas y clientes en varios países (aún en nuestro propio país un término puede llegar a tener connotación diferente en Bogotá que en Barranquilla), no está de más hacer este trabajo, no vaya a ser que usemos una expresión ofensiva para alguien. Quienes hemos viajado por distintas ciudades y países atendiendo clientes de la empresa somos testigo de ello.

Volviendo al nombre: Reservar y Hacer Reserva quizás sean muy cortos, sobre todo si hay distintos tipos de reserva; Reservar Vuelo quizás quiera decir un único trayecto, mientras que Hacer una Reserva Aérea puede significar reservar en ambos sentidos. En fin, las posibilidades pueden ser muchas. Por eso también es importante documentar el Glosario del sistema.

Para terminar, dos anécdotas: hace poco le preguntaba a un aspirante a Analista en InterGrupo que si sabía español. Evidentemente le llamó la atención y me dijo: “inglés, sí, a un 75%”. Yo le aclaré que no, y parafraseándolo le insistí que cuál era su porcentaje de español. Finalmente me dijo que no me entendía, creo que se ofendió, pero yo inmediatamente lo descarté.

Sí, es muy curioso que siempre nos exijan saber inglés sin siquiera indagar por nuestro nivel de español. Recuerdo que alguien, muy sincera, durante uno de los cursos que tomé de inglés hace muchos años me pidió ayuda cuando veíamos las distintas formas de conjugación en pasado. Ella me dijo que su problema era que no las dominaba en español y por eso se le dificultaba aprenderlas en inglés. Imagínense lo que pasó cuando llegamos al pretérito pluscuamperfecto: ese curso lo reprobó y nunca más la volví a ver.

De vuelta al caso de uso: las acciones no deben dar pie a ambigüedades, ni en el proceso del negocio ni en el del sistema. A primera vista, el paso 7 del caso de uso es anfibológico[i]. Seleccionar una opción de vuelo quizás quiera decir escoger un único trayecto y hasta bien podría sacarse de contexto y significar que el Pasajero seleccione un tipo de pasillo (Fumador, No Fumador, Ventana, No Ventana, entre otras); sin embargo, en la sección de Requisitos Especiales se aclara un poco el panorama.

Bueno, en otras lecturas volveremos a la secuencia básica.

Definición 9: Una secuencia alternativa está constituida por un conjunto de acciones que ocurren si se cumple una condición específica en el caso de uso, normalmente en la secuencia básica, aunque también puede ser en otra secuencia alternativa.

Cuando me refería a que la especificación de una acción o evento era más bien plana, hacía alusión a que la acción era una sentencia algorítmica básica, es decir, no era una decisión lógica o un ciclo predefinido, o una selección múltiple, que bien pueden existir en un caso de uso, pero que lo hacen complejo de entender.

El mecanismo que usamos para definir las decisiones en un caso de uso es precisamente el de las secuencias alternativas. Estas hacen más claro y preciso el caso de uso.

Una secuencia alternativa siempre debe iniciar detallando el paso o la acción en que se produce (el número del paso en la secuencia que la acarrea) y porqué se produce poniendo de manifiesto la condición que se cumplió para llegar a ese punto del caso de uso. A continuación se enumeran las acciones de la secuencia y por último se finaliza la secuencia bien sea retornando a la secuencia que la originó o terminando el caso de uso.

En nuestro ejemplo, es probable que falten algunas secuencias para terminar el caso de uso.
En conjunto, las secuencias básica y alternativas componen el cuerpo del caso de uso, la funcionalidad que el usuario requiere para resolver su problema de manejo de información: son lo implementable del caso de uso.

En general, un caso de uso se ejecuta para un elemento, en singular, del proceso. Por ejemplo, para un cliente decimos Registrar Cliente y no Registrar Clientes (a no ser que las condiciones así lo exijan); en nuestro caso, Reservar Vuelo: estamos reservando un vuelo de ida y regreso entre dos ciudades y fechas dadas, no son varios vuelos. El juego de palabras puede ser truculento, pero se debe aclarar lo mejor posible.

Definición 10: las poscondiciones describen el estado en el que queda el sistema una vez se ha ejecutado el caso de uso de manera exitosa, es decir, cuando no han surgido excepciones indeseables del sistema. Aquí, de manera exitosa quiere decir que se completó activamente un escenario del caso de uso sin que el sistema fallara por una caída de la base de datos, una sobrecarga de memoria o una mala implementación del caso de uso, entre otros.

Precisando, una poscondición no es el final de un caso de uso, está fuera del caso de uso. Por ejemplo, una poscondición no es que “la información del vuelo queda almacenada en la base de datos.” Esta es más bien una consecuencia lógica del caso de uso.

En el ejemplo, otra poscondición bien podría ser: “el pasajero puede Pagar su reservación con tarjeta de crédito, tarjeta débito o C.E.F.”

Como con las precondiciones, las poscondiciones pueden expresarse en términos de casos de uso o en prosa, si involucra a muchos casos de uso. Aunque la primera opción es la preferida porque no se deja espacio para malos entendidos, podría ocurrir lo mismo que expliqué sobre las precondiciones sentenciadas como casos de uso; por tal motivo, podría ser mejor usar la prosa: sí ven que es importante conocer mejor nuestro idioma.

Y al igual que las precondiciones, las poscondiciones son opcionales, aunque es difícil pensar en la ejecución de un caso de uso, que no sea la generación de un reporte o consulta, que no tenga un impacto directo sobre otro u otros casos de uso del sistema.

Definición 11: En principio, los requisitos especiales se refieren a requisitos de corte no funcional que deben tenerse en cuenta para la implementación de este caso de uso en particular y que no pueden ser descritas fácilmente en el flujo de eventos del caso de uso o lo convierten en un caso de uso enmarañado o sencillamente ilegible. Pero también pueden referirse a algunos requisitos funcionales si con ellos complementamos o precisamos el flujo del caso de uso, sobre todo, cuando no queremos adicionar detalles a ese flujo que también podrían hacerlo indescifrable.

Ahora bien, aunque los requisitos no funcionales se detallan en el documento de Especificaciones Suplementarias, si un requisito especial se refiere a una especificación previamente dictada, primará la que se encuentre en el caso de uso.

Para recordar, los requisitos no funcionales o el modelo URSP+ (por sus siglas en inglés): Usabilidad, Confiabilidad, Soportabilidad, Desempeño, Restricciones de diseño e implementación, Documentación, entre otros.

Bien, así son las piezas constituyentes de un caso de uso, al menos las más usadas. El grado de “adornamiento” de un caso de uso lo delimita el Analista de acuerdo a factores como complejidad, perfil del usuario, tiempo disponible para la especificación, experiencia de los equipos de diseño y de desarrollo, entre otros.

Escribir un caso de uso no es una tarea cándida, terminarlo puede llegar a ser extenuante. Pero ese será el tema de nuestra próxima lectura fundamental.

Hasta entonces.


Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación?”

[i]
anfibológico, ca.

1. adj. Que tiene o implica anfibología.

Real Academia Española © Todos los derechos reservados

anfibología.

(Del lat. amphibologĭa, y este del gr. ἀμφίβολος, ambiguo, equívoco).

1. f. Doble sentido, vicio de la palabra, cláusula o manera de hablar a que puede darse más de una interpretación.

2. f. Ret. Figura que consiste en emplear adrede voces o cláusulas de doble sentido.

Real Academia Española © Todos los derechos reservados

viernes, noviembre 17, 2006

Lecturas Fundamentales 2

Lectura Fundamental Anterior:Casos de Uso: De Vuelta a lo Fundamental

Lectura # 2
Casos de Uso: Origen, Especificación y Evolución

Los casos de uso detallan la funcionalidad del software en construcción. Aunque no tiene que usarse siempre, la técnica de casos de uso es una muy buena práctica a la hora de capturar, documentar, revisar y aprobar requisitos funcionales. Pero ¿a partir de qué elementos, en qué momento del ciclo de vida, surgen los casos de uso?


Los casos de uso, como la materia, no se crean ni se destruyen, se transforman. Están allí, esperando ingresar al conjunto de entidades que conforman un modelo, en este caso, como la materia prima fundamental de un producto de software.

En un principio están las necesidades, el espacio del problema. Aquí atendemos diligentemente la exposición del usuario, sus dificultades, la manera como las resuelve, si lo hace; escuchamos lo que necesita, las causas (el problema raíz o el problema detrás del problema), el impacto de convivir con esos inconvenientes, el costo asociado, entre otros aspectos.

Conocer al detalle la dimensión del problema es el primer gran paso hacia el diseño e implementación de un sistema útil y lleno de bondades para los usuarios. Durante esta parte del proceso, identificamos, sino a todos, a la mayoría de las personas involucradas o impactadas por el proyecto o el producto objeto del proyecto; por supuesto, también a otros sistemas o herramientas con los que nuestro sistema tendrá algún tipo de comunicación directa o indirecta.

Todos estos son insumos para identificar luego las características, ya en el espacio de la solución, del software a construir. Si hemos sido juiciosos consignando las palabras del usuario y confrontándolas con él, podremos empezar, por ejemplo, haciendo un análisis gramatical, una técnica antiquísima que separa los verbos, o las frases verbales, de los sustantivos: los primeros son casos de uso potenciales, o partes de un caso de uso; los segundos son actores u otras entidades relacionadas con el proceso. Es probable, inclusive, que de este análisis, apenas podamos tener una aproximación a un modelo de casos de uso del negocio.

Definición 4: un caso de uso del negocio representa un macro-proceso, un proceso, un subproceso o una actividad del negocio que no necesariamente es llevada a cabo por herramientas automatizadas, en el que intervienen una o más personas (llamadas entonces Actores del Negocio) y en el que se intercambia información relativa al proceso. Como con un caso de uso “normal”, al que llamaremos entonces caso de uso del sistema, o simplemente, caso de uso, el caso de uso del negocio termina con un resultado de valor observable para los actores del negocio. Ahora bien, de un caso de uso del negocio se pueden derivar uno o más casos de uso del sistema. Sin embargo, en ocasiones, un caso de uso del negocio permanece en su estado natural, es decir, ninguna de sus partes es automatizada. Un ejemplo típico de un caso de uso del negocio es la Recepción de una Solicitud de “algo”: Aquí, un actor del negocio, El Cliente, entrega a otro Actor del negocio, Recepcionista, Archivador o Empleado, uno o más documentos; este último, revisa, pone un sello con fecha y número (opcional) y firma una copia que es devuelta al Cliente; este simplemente se retira con su copia y el proceso, el caso de uso del negocio, termina.

Un Actor del Negocio representa un papel “actuado” en relación al negocio por alguien o algo en el entorno de ese negocio. Los siguientes tipos de usuarios del negocio son ejemplos de actores potenciales del negocio
[1]:

  • Clientes
  • Proveedores
  • Socios de negocio
  • Clientes potenciales (el “mercado objetivo”)
  • Autoridades locales
  • Colegas

Un término íntimamente relacionado con el Actor del Negocio es el Trabajador del Negocio y muchas veces se confunde uno con otro, pero dejaré los detalles de este tema para una próxima entrega. Lo que nos interesa aquí es que los casos de uso del negocio son también fuentes de los casos de uso del sistema.

En este punto resolvamos más inquietudes:

¿Cómo nombramos un caso de uso? Con frases verbales simples. Verbos como Registrar, Generar, Consultar, Matricular, acompañados de expresiones sustantivadas de una sola parte son ampliamente usados. Y muchos otros. Algunos verbos que debemos evitar son Procesar, Hacer, Ejecutar, Establecer, Administrar o Gestionar, por lo genérico o ambiguo de los términos, al igual que el sustantivo Evento, que además para nosotros significa muchas otras cosas. Tampoco redundemos, como en Generar Reporte de Solicitudes Recibidas: Generar y Consultar normalmente se refieren a eso, a reportes y consultas, a no ser que se especifique otra cosa. El nombre de un caso de uso debe despedir cierto halito de grandeza, de verdad, de seguridad: en lo sucesivo, se convertirá en parte integral del vocabulario de muchas personas, quizás de toda una corporación, eso es motivo suficiente para que sea así.

El nombre, además de usar los verbos y sustantivos, debe dar a conocer la intención que tiene el actor al usarlo en el sistema.

En conclusión, Los nombres de los casos de uso traen orden y sentido a un proceso y a las personas involucradas en el mismo, allí radica su importancia.

¿Cómo especificamos un caso de uso? Cuáles son sus partes? Un caso de uso siempre es ejecutado por un Actor y eso es lo primero que debemos identificar del caso de uso.

Definición 5: un Actor es una entidad externa al sistema, normalmente una persona, pero también puede ser otro sistema o una máquina con la que nuestro sistema tenga algún tipo de contacto. Cuando se trata de personas, el Actor no identifica a alguien en particular; en cambio, señala un grupo o un perfil de usuarios del sistema. Todos los usuarios caracterizados por ese actor, ven el sistema de la misma forma, ninguno ve más o menos que otro. Eso sí, un individuo puede jugar a ser más de un actor en momentos distintos y en estados distintos de la aplicación. El mito más grande que hay con los Actores Personas es que representan cargos dentro de la compañía para la cual se construye el software, lo cual apenas sería una afortunada coincidencia. Hasta es probable que los actores del negocio, más cercanos a la compañía, no signifiquen cargos de trabajo. Ejemplos de actores son: Analista de Crédito, Vendedor de Licencias, Habilitador de Servicios de Salud, Supervisor de Producción, Administrador de Usuarios, entre muchos otros.

En estos ejemplos hay una constante: el contexto. Un actor lo es dentro de un contexto particular. Analista, Vendedor, Habilitador, Supervisor o Administrador son actores bastante genéricos y podrían representar a toda una compañía, que nunca se modela en un sistema. Siempre debemos limitar el alcance de las actividades de un actor (los casos de uso que ejecuta) vía contextualización. Un actor ampliamente usado en los sistemas punto com es el Cliente. Muchas veces, la sola denominación Cliente es bastante amplia y no permite delimitar el ámbito en el que se mueve. Podríamos bien decir: Pasajero Aerolínea, Tarjeta-Habiente, Comprador Minorista, Asegurado, Solicitante de Crédito, entre muchos otros apelativos.


Por supuesto, el otro componente importante de un caso de uso es el conjunto de secuencias, los flujos de tareas. Las tareas dicen qué hace el caso de uso, no cómo lo hace, es decir, no hay detalles técnicos en un caso de uso, al menos, no en principio, mientras se revisa y se aprueba con el usuario, quien es la última línea de defensa en materia de casos de uso. Tampoco hay referencias al diseño de la interfaz gráfica de usuario.

Además, en un caso de uso no se escribe el código fuente ni el manual de usuario. Para ello existen otros artefactos, tratados en otras disciplinas e instancias, que requieren de un conocimiento más profundo y detallado del adquirido durante el período de la especificación de requisitos.

Ejemplo, Ejemplo, Ejemplo.

Caso de Uso: Reservar Vuelo
Actor: Pasajero Aerolínea
Secuencia:
1. El caso de uso inicia cuando el Pasajero solicita una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema verifica que haya un asiento disponible para las condiciones establecidas y solicita las preferencias de silla al Pasajero
7. El Pasajero indica sus preferencias
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema genera y muestra un código de reserva
11. El caso de uso termina


Advertencia: este es un caso de uso en estado de especificación, no intente usarlo en ningún proyecto en curso.

Esta primerísima versión está medianamente lejos de la versión definitiva. Sin embargo, sirve para indicar varios aspectos:

1. La interacción Usuario-Sistema. El caso de uso siempre debe señalar lo que es obvio para el usuario, lo que él puede ver del sistema. Para el usuario es importante el estímulo que reciba del sistema, ya sea a través de solicitudes o de respuestas. El detalle del mecanismo algorítmico o técnico que use el sistema para enviar esas solicitudes o encontrar esas respuestas debe omitirse del caso de uso. En el ejemplo, el algoritmo de verificación del asiento disponible, si la búsqueda se hace secuencial o binaria, si se usan procedimientos almacenados o si se invoca a un Web Service para lograrlo, son especificaciones que están lejos del alcance del caso de uso (aún en la versión final del caso de uso, la que aprobará el usuario, no existirán).

2. Las formas lingüísticas, en este caso, los verbos y sustantivos usados deben ser un indicador de los mecanismos de implementación a usar: cuando el caso de uso especifica “el Pasajero selecciona
[2]…” está diciendo claramente: elegir, escoger de un grupo de posibles opciones. Es evidente que el sistema debe entonces utilizar los medios necesarios para mostrar la lista de opciones y permitir que el usuario decida entre ellas mediante la “Acción y efecto de elegir a una o varias personas o cosas entre otras, separándolas de ellas y prefiriéndolas.” (Significado de Selección, Diccionario de la RAE, XXII Edición).

Vamos un poco más allá: cuando el caso de uso dice: “5. El pasajero especifica…” igual está lejos de señalar el mecanismo de implementación; no obstante, dejamos una puerta abierta para que el Programador use uno o más elementos de interfase de usuario: un cuadro de texto para digitar, un control especializado que permita seleccionar la fecha, un calendario compuesto por listas de días, de meses y de años donde también el usuario pueda “armar” la fecha requerida o una combinación de algunos de ellos.

Por supuesto, es posible que más adelante, durante las fases de análisis y diseño, cuando se suplemente el caso de uso, los posibles medios de implementación se particularicen de acuerdo a otros aspectos como los estándares de diseño gráfico, aspectos de usabilidad, restricciones de la aplicación, entre otros.

3. El versionamiento y el involucramiento del usuario. Es importante tener una versión del caso de uso tan pronto como sea posible, empezar a discutirla con el usuario, refinar la versión y congelarla tan tarde como sea posible, eso sí, antes de que finalice la etapa de especificación de requisitos, ya sea para una iteración en particular o para una fase determinada del proceso. (De Iteraciones y de Fases será otro tema para una lectura fundamental futura).

Ahora bien, el usuario nunca especifica o documenta casos de uso, pero sí los revisa, propone cambios y los aprueba. Hay un tiempo para todo. Si el cambio propuesto ocurre después de finalizada la etapa de especificación, es tarea del Analista de reportarlo como lo que llamamos comúnmente un control de cambio.

¿Y sobre la evolución del caso de uso? Por evolución me refiero aquí a lo que sucede con un caso de uso una vez está aprobado (versión 1.0) por el usuario. Se trata del análisis, el diseño, la implementación, la integración, las pruebas, la puesta en operación del caso de uso. Son temas extensos, motivo de más lecturas fundamentales por hacer.

Lectura Fundamental Siguiente: “Casos de Uso: Del Todo y de Sus Partes”

[1] IBM Rational Unified Process –RUP
[2] seleccionar. tr. Elegir, escoger por medio de una selección. Real Academia Española © Todos los derechos reservados.

jueves, noviembre 09, 2006

Lecturas Fundamentales

Lectura # 1
Casos de Uso: De Vuelta a lo Fundamental

Volvamos a lo básico: un caso de uso es un conjunto de secuencias de actividades ejecutadas, normalmente por la interacción entre un ser Humano y una máquina. Las actividades son iniciadas por una entidad externa llamada Actor y las actividades terminan con un resultado de valor observable para ese Actor.

Desde otra perspectiva, la del usuario que usa el sistema, un caso de uso es una pieza de funcionalidad de software, casi siempre, una pieza indivisible, que tiene:

  • Uno o más datos de entrada, el estímulo
  • Uno o más datos de salida, la respuesta
  • Un número finito de pasos o tareas, el proceso
  • En principio, cada uno de esos pasos bien podría realizarse usando “sólo lápiz y papel”, la simplicidad
  • Un comienzo, la orientación
  • Un fin, el éxito.

¿Alguien recuerda a qué se parece esa definición?

Un caso de uso es el primer peldaño en la conversión de las necesidades de los usuarios a un sistema automatizado. Es el primero, el cimiento: para llegar al cielo todavía se requieren muchos otros elementos (léase análisis, arquitectura, diseño, implementación…)

Un caso de uso es el componente primario del modelo dinámico de un sistema, ese que hace e intenta responder la pregunta: ¿qué hace el software? Ese que juzga (analiza) el sistema por sus acciones. Sí, ese del que se dice es una representación abstracta de lo que hace el software, el que define el comportamiento del sistema.

Ahora bien, habitualmente un caso de uso se escribe en el formato “el actor hace…, el sistema hace…” un diálogo, un guión, una escena, en este caso, de un sistema de software.

Con esto en mente, resolvamos varias preguntas que siempre llegan a mi buzón:

¿Cuántas secuencias forman el “conjunto de secuencias” del caso de uso? Una, dos, tres…, un número pequeño, contable de secuencias. Como en casi todos estos temas, no está escrita la última palabra. Depende del contexto, del proceso de negocio que implementa el caso de uso, del resultado esperado, de la cantidad y calidad de los datos de entrada, de la habilidad de los usuarios del caso de uso, de los escenarios de usabilidad, de…, la lista de es larga.

En breve, un caso de uso de una única secuencia puede ser mucho más complejo que un caso de uso de media docena de secuencias. El asunto es: el número de secuencias de pasos no es el único capricho de un caso de uso.

Entonces ¿cuántas actividades tiene una secuencia? La respuesta es la misma: un número pequeño. Las prácticas contextuales nos dicen que siempre habrá una secuencia “regular”, la que más ocurre, la principal, la básica; y también podrán existir cero, una, dos, tres…, secuencias de menor ocurrencia, secundarias, eventuales, cada una de ellas, quizás, con un número menor de pasos que la primera.

¿Una secuencia es lo mismo que un escenario? Ah, este es un error muy común que cometemos. Apenas es una feliz coincidencia que sean lo mismo; pero de una secuencia, principal o no, pueden surgir uno o más escenarios.

Definición 1: Un escenario es un “camino” de ejecución, una instancia, del caso de uso con datos reales, donde el actor tiene un nombre, los datos tienen un valor específico y donde efectivamente hay un resultado que se puede “ver”. Quienes alguna vez han diseñado casos de prueba conocen bien esta diferencia. De hecho, un escenario puede (y habitualmente lo hace) ir a través de varias secuencias, normalmente, la principal y una o más secundarias. En síntesis, los escenarios son hilos cohesivos de comportamiento del caso de uso ocasionados por el estímulo que este recibe desde el exterior.

¿Y esas actividades cómo se escriben? ¿Cuál es el alcance de las mismas? Se escriben en terminología del usuario, sin detalles técnicos; en términos lingüísticos, siempre deberían ser escritas como una expresión verbal simple, sin adornos, sin sinónimos, sin adjetivos, sin comentarios del autor: un caso de uso es “orientado-al-verbo” si quisiéramos parafrasear algunos de los términos más usados por quienes nos movemos por los vericuetos insondables del tratamiento sistémico de la información.

En eso se diferencia un caso de uso de un guión de teatro, por ejemplo. Este último es rico en emociones, en observaciones, en detalles analógicos y puntos de vista subjetivos tanto del autor como de los personajes que intervienen.

¿Y qué hay del nivel de granularidad? Aquí entramos en el dilema del CRUD[1] o no CRUD, esa es la cuestión. Por agilidad deberíamos escribir casos de uso esenciales, no descompuestos funcionalmente, es decir, casos de uso que no entren en el nivel de detalle de la “pantalla” o del “formulario”, de los botones y cuadros de texto. Un caso de uso esencial deja un margen de maniobra al Analista, al Programador, al Arquitecto y aún al Probador. Los detalles de usabilidad, colorido y presentación bien podrían ser consignados en documentos auxiliares, en estándares en los cuales basar su implementación. Escribir casos de uso CRUD y similares aumenta innecesariamente el número de casos de uso, el tiempo de especificación, el tiempo de revisión, el tiempo de aprobación. Sí, quizás disminuya el tiempo de programación, pero este es cada vez más reducido a la luz de las poderosas herramientas con las que contamos hoy para escribir código fuente.

Definición 2: un caso de uso esencial se caracteriza porque: la funcionalidad CRUD es una porción del caso de uso, el actor que lo inicia está bien generalizado, su secuencia básica completa una interacción mayor con el sistema, no está asociado con componentes arquitectónicos o del sistema, es completamente independiente de la implementación de la Interfaz de Usuario, contiene un número mayor de secuencias alternas (hummm, esto podría representar algún tipo de inconveniente a la hora de cualificar la legibilidad del caso de uso), representa muchos ejemplos concretos de interacción, es decir, deriva en muchos escenarios, es bastante útil para pruebas del sistema y de funcionalidad. Finalmente, un caso de uso esencial forma parte de un modelo de casos de uso cuyo número de extensiones e inclusiones es menor al 20% de todo el modelo.

Definición 3: un caso de uso descompuesto funcionalmente es aquel que aborda un solo elemento CRUD a la vez, está vinculado a usuarios concretos específicos, no a actores abstractos, su flujo básico no completa una interacción mayor con el sistema, en cambio, describe funciones primarias del mismo, está completamente ligado a un componente del sistema o a un componente arquitectónico específico, está vinculado a una pantalla o función de usuario determinada y contiene instrucciones concretas de diseño de IU, incluye de cero a dos flujos secundarios frecuentemente relacionados con datos, Los escenarios derivados casi siempre deben invocar varios casos de uso para completar un ejemplo integral y es útil para pruebas unitarias. Para terminar, en un modelo de casos de uso descompuestos funcionalmente más de la mitad de los casos de uso son inclusiones o extensiones.

Una práctica contextual beneficiosa es sacrificar el modelo de los casos de uso descompuestos funcionalmente en aras de un diseño arquitectónico robusto y estable, de un modelo estático consistente y resistente y de una especificación más limpia y clara para quien, en últimas, revisa y aprueba cada caso de uso: el usuario.

Ejemplo # 1: el caso de uso “Hola Mundo”

Este es un caso de uso simple:

  1. El caso de uso inicia cuando el Actor ejecuta la aplicación Hola Mundo
  2. El sistema muestra el mensaje “Hola Mundo.”
  3. El caso de uso termina

Ya tendremos la oportunidad de entrar en detalles acerca de como se escribe un caso de uso.

Lo que viene: bueno, habrá más de estas lecturas fundamentales. ¿De dónde surgen los casos de uso? ¿Y qué hay de los actores? ¿Cuándo un caso de uso está terminado? ¿Hay vida más allá de los casos de uso?

Estas y otras cuestiones nos aguardan en el universo binario de la técnica y la ciencia informática.

Lectura Fundamental Siguiente: “Casos de Uso: Origen, Especificación y Evolución

Hasta entonces.

[1] CRUD: Create Read Update Delete (Crear, Leer, Actualizar, Eliminar). Operaciones fundamentales de los sistemas de información.

martes, mayo 17, 2005

Problemancia y Solucionancia

De todas las preguntas, observaciones y similares que me llegan a diario y que desafortunadamente por razones de tiempo no puedo atender en su completitud, quiero referirme esta vez a algunos comentarios y cuestiones que un colega me hace, a raíz de mi artículo anterior sobre Iteraciones. Ya le respondí a él, pero luego pensé que era interesante ampliar mis respuestas y darlas a un público más amplio, porque además son una muestra representativa de los temas que siempre discuto en los grupos de trabajo.

Como siempre, los nombres y algunos datos fueron cambiados para proteger la identidad de los culpables.

Sobre RUP

Nuestro amigo empieza diciendo que “RUP no es una metodología, sino un Proceso y como tal tiene metodología y responsables de las actividades y artefactos.

Ciertamente. RUP es un proceso de ingeniería de software, ya había hecho una presentación al respecto en El Imperio de las Metodologías, así es que estoy de acuerdo con esa apreciación, sin embargo, en el contexto en el que lo uso, Proceso y Metodología son sinónimos. Ahora van a salir los puristas del idioma a decirme que eso no es cierto, que hay una diferencia bien marcada. Pero no se trata de eso, hablo de las situaciones en las que uso las palabras: metodología es un término más arraigado en nuestro medio informático que proceso, que nos suena más a algo químico. Hay que ser flexibles en ese sentido y eso me da pie para hablarles de algo más adelante sobre adaptación.

Formalmente, un proceso es un conjunto de pasos ordenados con los que se busca un objetivo; en ingeniería de software, el propósito es construir un producto de software; en el caso de RUP, esos pasos están organizados en Disciplinas que a su vez definen Flujos de Trabajo y otros elementos del proceso.

Nuestro colega sigue diciendo que “en este momento él y su equipo se encuentran desarrollando un proyecto bastante grande siguiendo los lineamentos de RUP, y por ser la primera experiencia ha sido difícil la aplicación (el proyecto es contratado con una empresa desarrolladora de Software). Están precisamente terminando la 4a iteración de la fase de Elaboración.

Ya he tenido experiencias con RUP (coincidencialmente, la primera de ellas hace algunos años, fue con un proyecto también muy grande, como el mencionado), y también ha sido complejo aplicarlo. Ha sido un proceso de adaptación y adopción, yo lo he llamado en mis conferencias “de tropicalización”. Este tipo de proyectos son escasos en nuestro medio (quiero decir, proyectos de software de varias docenas de personas y de varios años de duración), pero se dan algunas veces. La experiencia, en todo caso, ha sido enriquecedora (a veces ha sido dura, pero los resultados se han visto). En particular, celebro que estén involucrados en este tipo de procesos, creo que es la única forma de mejorar la calidad de lo que hacemos, productos de software.

Voy a hacer énfasis en esto de la adaptación y adopción. El Proceso Unificado tiene muchos “roles” responsables de esa gran cantidad de actividades y de ese enorme conjunto de artefactos que se pueden generar siguiendo el proceso al pie de la letra. Pero una de las grandes ventajas de RUP es que, aunque rígido, permite cierta flexibilización por parte de quienes lo siguen. Y aquí “seguir” es la palabra clave, como lo anotaba nuestro lector en su comentario anterior. Esto quiere decir que no debemos meternos de cabeza en el proceso, sino acomodar y aceptar muchos de sus delineamientos, teniendo en cuenta siempre las habilidades del equipo del proyecto, el tiempo de entrega y los recursos (no es lo mismo “RUPizar” con las herramientas que proporciona IBM Rational –RequisitePro, Rose, Robot, XDE, entre muchas otras, que hacerlo prácticamente con lápiz y papel, como ocurre en muchos lados a nuestro alrededor.)

Por ejemplo, es posible tener en un mismo documento (o Artefacto), La Visión del Sistema, la Especificación de Requisitos y la Especificación Suplementaria, y no en tres documentos separados como propone el proceso. Esto ahorra tiempo, esfuerzo y proporciona un mayor entendimiento del sistema en construcción: la idea es hacer encajar las partes comunes y no comunes de cada uno de esos elementos en uno solo de ellos. Es una propuesta, funciona bien, en proyectos pequeños y medianos, los que hacemos con la llegada de las lluvias.

Sobre Mecanismos de Análisis, Diseño e Implementación

Luego pasamos al tema de las preguntas, inquietudes razonables, a las que traté de dar respuesta desde mi punto de vista y soportado en mi experiencia. Aquí la primera:

Los Mecanismos de Análisis, Diseño e Implementación deben quedar en un artefacto o documento en la fase de Elaboración, necesariamente? O se pueden entregar en la fase de Construcción? Y cual sería la importancia de tenerlos en la fase de Elaboración?

Trataré de definir en palabras simples qué es esto de los Mecanismos de Análisis, Diseño e Implementación. Un mecanismo de análisis representa un patrón que constituye una solución común a un problema común. Afortunadamente para nosotros, en ingeniería de software ya existen muchos problemas documentados, y con la aparición de cada nueva plataforma o tecnología, se documenta la forma de solucionar esos problemas habituales. Puedo citar algunos ejemplos prácticos: Manejo de Errores o Fallas del Sistema, Sincronización de Procesos y Acceso a Datos. En general, los mecanismos de análisis nos permiten concentrarnos en el análisis de los requisitos funcionales, el problema propiamente dicho, y no sumergirnos en ciertas complejidades que nos pueden conducir a la llamada “parálisis del análisis”, muy temida por todos.

Entre tanto, un Mecanismo de Diseño es un refinamiento de un mecanismo de análisis correspondiente. Un mecanismo de diseño agrega detalles concretos al mecanismo de análisis conceptual, pero llega hasta justo antes de proponer una técnica particular de implementación. Tanto los mecanismos de diseño, como los de análisis pueden instanciar uno o más patrones, en este caso, patrones arquitectónicos o de diseño.

De manera similar, un Mecanismo de Implementación es un refinamiento de un mecanismo de diseño correspondiente, usando ya una plataforma o lenguaje de programación específicos. Por ejemplo, para cada uno de los problemas que mencioné arriba ya existen soluciones en una plataforma como Microsoft.Net (y supongo que en J2EE también existirán). De los siguientes enlaces pueden bajar la solución a esos problemas, cuando se trata de usar tecnología Microsoft:

Manejo de Errores o Fallas del Sistema
Sincronización de Procesos
Acceso a Datos
Y aquí pueden bajar otras soluciones comunes.

Y para responder la duda citada, los mecanismos de Análisis, Diseño e Implementación hacen parte de lo que yo llamo “documentación interna”. Efectivamente, pueden hacer parte, por ejemplo, del documento de arquitectura, en cuyo caso lo extenderían y lo harían más complejo, innecesariamente. Lo que sí debe quedar en este documento son las relaciones o el mapeo de los mecanismos de análisis con los mecanismos de diseño con los mecanismos de implementación. Estos, a su vez, sí pueden quedar en el documento de Guías de Diseño, que también es responsabilidad del Arquitecto y que hace parte del Modelo de Diseño. En cualquier caso, estos mecanismos siguen siendo un asunto “peliagudo” (no sé si entiendan el término –“complicado”), son temas algo abstractos y muchas veces prefiero evitarlos, al menos, presentarlos al cliente (aun al representante del área de tecnología), pues siempre sigo la premisa de que “modelamos para entender el sistema que luego vamos a construir”.

Ahora bien, estos mecanismos, muy tarde, deben estar para el refinamiento de la arquitectura, hacia el final de fase de Elaboración. La idea es que haya suficiente claridad al momento de enfrentar el gran grueso de Construcción y que las soluciones comunes estén quizás ya implementadas. Reusabilidad ante todo. Además de esto, son importantes en Elaboración porque son un indicador de que conocemos muy bien el sistema, su arquitectura, la forma como se va a construir e implantar y porque, precisamente, tenemos desde el inicio de la construcción un conjunto de soluciones preestablecidas.

Sobre el Modelo de Dominio

El Modelo de Dominio es indispensable como insumo del documento de arquitectura? Es decir, lo necesito como insumo para validar la vista Lógica?

De acuerdo al Proceso Unificado, un modelo de dominio es un modelo de objetos del negocio que se enfoca en “el producto, entregables o eventos que son importantes para el dominio del negocio.” Un modelo de dominio es un modelo del negocio “incompleto”, en tanto omite las responsabilidades de los individuos. El modelo de dominio típicamente muestra las entidades mayores del negocio, sus responsabilidades funcionales y las relaciones entre esas entidades.

Sin duda, el modelo de dominio es útil para validar la vista lógica de la arquitectura, pero no solo para eso, de hecho, es la base de dicha vista, creo que sin el modelo de dominio no podremos obtener la vista lógica completa y realmente tampoco estaríamos en capacidad de avanzar mucho, porque no tener el modelo de dominio indica que todavía no conocemos lo suficiente el sistema. Sin embargo, en la práctica, el modelo de dominio evoluciona hasta la fase de Construcción, cuando todavía desarrollamos casos de uso que no se trataron en Elaboración.

Sobre Casos de Uso Significativos

Cuántos casos de uso sería aconsejable desarrollar en la fase de Elaboración para definir la línea base de arquitectura?

Cuántos casos de uso? Muchos. Depende del número total de ellos. La última palabra sobre este tema no está dicha ni aceptada, pero podríamos estar hablando de más del 60% de los casos de uso, al terminar la fase de Elaboración. Los que sí deben estar terminados son los casos de uso significativos para la arquitectura, aquellos que tienen mayor impacto sobre la misma.

Con una docena de casos de uso seleccionados como arquitectónicamente significativos de más de mil casos de uso identificados hasta el momento (final de la fase de Elaboración), puedo decir que mi arquitectura es estable? Estos casos de uso arquitectónicamente significativos se escogieron teniendo en cuenta el riesgo tecnológico que representaban para su implementación desde el punto de vista técnico.

Una docena de casos de uso me parece un número muy pequeño comparado con más de mil de ellos. Desde el exterior, y desde mi perspectiva, no creo que podamos hablar de una arquitectura estable. Si seguimos los delineamientos de elaboración de casos de uso, por lo menos, deberíamos tener un centenar o más de ellos arquitectónicamente significativos. Ahora bien, mil casos de uso es un número muy grande para un sistema, yo diría que exageradamente grande, dado que los casos de uso son el medio a través del cual los usuarios (aunque no siempre es así) se comunican con el sistema. Estamos hablando entonces de que el sistema en construcción tiene más de mil maneras de acceder a el. Lo veo complejo desde aquí. Recordemos además que un caso de uso puede tener más de un escenario o secuencia alternativa, con lo que estaríamos hablando tal vez de miles de escenarios. Mucho, pienso yo.

Se debieron escoger Casos de Uso Arquitectónicamente significativos desde el punto de vista de los usuarios o stakeholders y que representen la funcionalidad de negocio? De no tenerse en cuenta estos casos de uso, qué riesgo presenta la definición de la línea base de arquitectura?

Sí, se debieron (se deben) escoger. Pero con mucho cuidado. Algunas veces los usuarios piensan que un caso de uso (una funcionalidad es compleja o significativa) porque simplemente hacen uso de miles o millones de registros en muy poco tiempo y resulta que quizás para nosotros el asunto se resuelve con un algoritmo implementado en un procedimiento almacenado, para lo que se supone somos expertos.

Si el usuario nos dice, por el contrario, que sin importar el sitio de origen, la transacción debe llegar al servidor central y responder al usuario en menos de cinco segundos, así la transacción sea traer unos datos básicos de un cliente dada su cédula, usando los canales existentes en la compañía, entonces sí que debemos preocuparnos. Y como este hay muchos casos que se deben tener en cuenta a la hora de seleccionar los “significativamente arquitectónicos”.

Sobre La Vista Lógica

La vista Lógica me debe mostrar el Core de mi negocio? O que esperaría ver en ella?

El “core” del negocio debe reflejarse de alguna forma en la vista lógica si el sistema Es para el “core” del negocio, de lo contrario no. En cualquier caso, la vista lógica muestra paquetes de alto nivel, subsistemas, clases y las realizaciones de casos de uso. Observemos que si el sistema es “core”, las clases del dominio reflejan precisamente el negocio.

Conclusiones

Y bueno, como recomendación adicional, les sugiero que traten de “platanizar” RUP, como dicen algunos de mis colegas, adoptarlo, sí, pero adaptarlo a nuestros recursos, a nuestras habilidades, a nuestro entorno, donde no tenemos el tiempo ni el presupuesto de los grandes proyectos de otros lados. Quizás combinarlo con prácticas ágiles y obtener una “metodología” acorde al medio.

Como siempre, los invito a que compartan conmigo y con todos sus comentarios acerca de este artículo. Me pueden escribir a luissalazar@usa.net o en http://gazafatonarioit.blogspot.com/.

Luis Antonio Salazar Caraballo

Medellín, Noviembre 4 de 2003

lunes, febrero 14, 2005

Desarrollo de Software por Iteraciones

Introducción
Una de las prácticas que más inquieta a los productores de software, una de las llamadas Mejores Prácticas, es esta de las Iteraciones en un proyecto. Una Iteración, para empezar, puede ser vista como un mini-proyecto, sin que el prefijo “mini” quiera decir que el proyecto está inconcluso o es de mala calidad, No. De hecho, esta práctica ha demostrado que el producto final es de mejor calidad que el elaborado mediante metodologías tradicionales como Cascada.
Formalmente, una Iteración abarca el desarrollo de actividades que conducen a la liberación de un producto –una versión ejecutable y estable de un producto, junto con cualquier otro elemento periférico necesario para usar esta versión, como la documentación respectiva, para citar un caso. Desde este punto de vista, en una Iteración se hace un paso completo por todas las etapas del desarrollo de software, desde el análisis de requisitos, hasta la programación y, quizás, puesta en producción, pasando por análisis y diseño, pruebas y control de cambios. Si se quiere es como un proyecto pequeño realizado “en cascada”.
Pero alrededor del concepto de las Iteraciones hay involucrados muchos aspectos de relevancia: cuántas iteraciones tiene un proyecto? Cuánto tarda una iteración? Todas las iteraciones tardan lo mismo? Qué es la Liberación de un producto? Cómo se seleccionan los requisitos a implementar en una iteración? Y muchas otras.
Beneficios
Antes de tratar algunas de esas cuestiones, insistiré en los motivos por los cuales debemos iterar:
Ø Puesto que una iteración es un proyecto pequeño completo, hay un mejor control de los recursos, el talento humano asignado al proyecto, la calidad del producto implantado y los cambios en requisitos que se puedan producir durante el tiempo total del proyecto.
Ø Disminución en los riesgos de un proyecto. Hablo de riesgos tecnológicos, de riesgos administrativos y hasta del entorno. Por ejemplo, es posible que para implementar un requisito, o un conjunto de ellos, un equipo seleccione las herramientas y/o la técnica y/o la plataforma equivocada. Y de esto no se dan cuenta hasta que el producto (la versión a liberar en esa iteración) no está listo o casi listo. Por ejemplo, los tiempos de respuesta no son adecuados, la seguridad de los datos no se puede garantizar, el manejo de concurrencia no es aceptable, entre muchos otros aspectos. En un proyecto tradicional, estos hechos solo se ven al final del mismo, cuando ya no hay tiempo de hacer correcciones, de buscar alternativas, cuando se perdió la oportunidad (el costo de oportunidad), etc. Sin embargo, en un proyecto iterativo, muy probablemente todavía habrá tiempo (luego de buscar a los culpables y de elogiar a los no participantes!) de hacer algo. Cómo qué? Se define otra iteración, con otra técnica, con otras herramientas, con otra plataforma, lo que sea necesario, para asegurar que esta vez el requisito sí va a ser bien implantado.
Ø Las iteraciones relajan los nervios. Hablo de las expectativas que tienen los usuarios, los patrocinadores (llamados en lenguaje metodológico stakeholders), los desarrolladores; hablo también del producto que se libera o entrega en cada iteración. Cuando aquellos ven este, verifican la funcionalidad (los casos de uso), la calidad (desempeño, seguridad, estándares, entre otros), se forjan nuevas ideas de lo que ha sido, es y será el producto final (por supuesto están los “yaques” –ya que hiciste el cálculo de la retefuente, por qué no generas un informe que se envíe por Mail en formato Excel al gobierno?) En mi caso, validan la capacidad (de respuesta) del proveedor, comprueban que obtuvieron lo que compraron y los usuarios comienzan a hablar de las siguientes fases del proyecto, sin haber terminado esta. Recuerden, se terminó una iteración, no el proyecto. En cualquier instancia, los usuarios, sobre todo, no tienen que esperar meses o años para ver su producto, preguntándose todo el tiempo si estos chicos de Sistemas van a entregar y cuándo y que será lo que están haciendo y si habrán entendido lo que querían decir.
Ø Hay otros beneficios técnicos, como que la reusabilidad se facilita y se mejora. Esto es claro, porque una vez terminado un producto, o parte de el, sus componentes ya están ampliamente probados y documentados y se podrán usar en las iteraciones sucesivas donde seguramente serán sometidos a incrementos graduales. También se puede aprender en el camino: me refiero a que los desarrolladores pueden no solo aprender de sus errores pasados, sino de las nuevas técnicas a utilizar durante la iteración; también, las competencias y especialidades que se necesitan para una iteración específica son mejor utilizadas, es decir, es posible emplear desarrolladores diferentes en cada una de las iteraciones del proyecto.
Cómo Iterar
Ahora sí, trataré de resolver algunos de los temas que planteé antes.
Ya sabemos que el desarrollo de un proyecto debe hacerse teniendo como punto de partida y como conductor los casos de uso. Una vez que hayamos elaborado el documento de Especificación de Requisitos (Funcionales y No Funcionales), se escriben las descripciones de todos los casos de uso del sistema (hablo de Nombre del Caso de Uso, Actor, Descripción General y cualquier otra información que se tenga al momento de elaborar las Especificaciones.)
Con esta lista, procedemos a “calificar” los casos de uso. Esta calificación la hacemos de acuerdo al grado de importancia y de criticidad, en cuanto a riesgo de implementación se refiere, de cada caso de uso.
Respecto a su importancia, un caso de uso, como veremos en un artículo próximo sobre el tema, puede clasificarse en: Requerido, Importante o Adicional. Los primeros son aquellos sin los cuales el sistema no puede funcionar. Los casos de uso Importantes son aquellos sin los cuales el sistema puede funcionar, al menos, durante algún tiempo, pero que debemos implementar tan pronto como sea posible. Mientras tanto, los casos de uso Adicionales son aquellos no obligatorios para el sistema (los “yaques” que mencionaba antes), los Buenos, Bonitos y Baratos, como decimos popularmente. Por supuesto, la implementación de estos últimos debe hacerse siguiendo los mismos delineamientos metodológicos y técnicos que los demás; el que sean Adicionales, no los hace de menos calidad o incompletos o no sujetos al mismo proceso de pruebas que los otros.
En relación a su Criticidad, los casos de uso se califican de 1 a 5, por ejemplo, donde 1 es de menor riesgo, 3 es de riesgo aceptable y 5 es de riesgo muy alto. Este riesgo se refiere a la implementación del caso de uso y se debe medir a la luz de varios criterios:
Ø Conocimiento del tema (del negocio) por parte de los usuarios y de los desarrolladores. Hay usuarios que desconocen parte de lo que quieren resolver a través de un sistema (porque la legislación o las políticas son nuevas, o porque son nuevos en la compañía, etc.) También hay desarrolladores que creyeron entender algo del usuario pero no fue así, sobre todo los noveles que, al momento de una entrevista con el usuario, están pendientes de cómo resolver el problema y no de escuchar y comprender todo lo que les quisieron decir.
Ø Habilidad y/o experiencia de los desarrolladores en el uso de la plataforma, herramientas y técnicas utilizadas para llevar a cabo la implementación. Qué se requieren Web Services, que la plataforma .Net, que XML, que UML, que C# (léase C Sharp), que J2EE, que…, en fin, un gran universo de siglas de las que les hablaré en otra ocasión. En todo caso, estos son apenas los medios, algo en lo que se supone somos especialistas, sin embargo, algunas veces no es así. Visto así, un caso de uso que en la práctica es fácil de programar, podría tener un alto riesgo de implementación debido a la poca experiencia del programador.
Ø Y otras como Tiempo de Desarrollo, Número de Analistas y de Programadores, calidad de los requisitos en cuanto a su precisión, compromiso del personal externo necesario para llevar a cabo una implantación (que la gente de Seguridad, que la gente de Calidad, que la gente de Capacitación).
Ya con los casos de uso listados y clasificados, con el tiempo límite del proyecto en mente, con el número de desarrolladores establecido, podemos hacer un Plan de Iteraciones. Este es un conjunto de actividades y tareas secuenciadas en el tiempo, con talento humano asignado y con el conocimiento de las dependencias entre tareas, para cada iteración; un plan bien detallado. Normalmente, siempre hay dos planes activos: uno para la iteración actual y uno en construcción para la siguiente iteración. El plan incluye actividades de Análisis de Requisitos, Análisis y Diseño, Programación, Pruebas y Afinación, y Puesta en Marcha; también, control de cambios, documentación y capacitación.
Las primeras iteraciones deben planearse para implementar los casos de uso Requeridos y de Criticidad Máxima (5). Les dejo una inquietud: existen sistemas que no tengan casos de uso de criticidad 5?
Cuántos casos de uso por iteración? Depende del número total de casos de uso y del número de casos de uso Requeridos y Más Críticos, y además del número de desarrolladores dispuestos para la implementación. Una iteración podría implementar solo un par de casos de uso, o 10 de ellos, o quizás 20 o más. En el artículo de casos de uso exploraré más este tema.
El tiempo, la duración, de las iteraciones es otro factor importante. No está dicha la última palabra a este respecto. En un proyecto pequeño (de pocos meses –dos o tres, quizás), con pocos desarrolladores (dos o tres tal vez–o hasta uno), iteraciones de dos semanas son aceptables. En un proyecto mediano (seis meses, hasta cinco desarrolladores), iteraciones de tres o cuatro semanas son bienvenidas. En un proyecto grande (más de seis meses, más de seis desarrolladores), iteraciones de hasta seis semanas son bien vistas.
Debo anotar que esta clasificación del tamaño de los proyectos de acuerdo a la duración y al número de desarrolladores es un poco arbitraria, soportada en la trayectoria de quien les escribe y de algunos colegas con quienes he discutido el tema. Hablo de nuestro medio. La literatura que nos llega de otras latitudes se refiere a algo totalmente distinto, donde un proyecto pequeño tarda un año y tiene 10 desarrolladores, por ejemplo.
En mi columna anterior decía que una iteración no debería tardar más de un mes. Este asunto de las iteraciones de mes y medio que menciono arriba también es viable si se tiene un buen control del proyecto. Recuerden que este es uno de los grandes beneficios del desarrollo iterativo, el control del proyecto, obtención rápida de resultados, mitigación de riesgos.
Ahora bien, aunque es bueno que todas las iteraciones tarden lo mismo, en la práctica es posible que esto no se dé. Hay iteraciones que por su simplicidad pueden tardar dos semanas, otras pueden tardar cuatro. Lo importante es que los recursos estén disponibles al momento de iniciar cada iteración y se tenga claridad sobre los requisitos que se van a implementar.
Sobre Versiones y Entregas
La Liberación de un producto puede ser Interna o Externa. Es Interna cuando solo será usada por el grupo de desarrolladores durante la ejecución de otras iteraciones en las que se completará un producto propiamente dicho. Y es Externa cuando se trata de un producto de software completo, funcional, que se puede poner en producción.
Ambos tipos de entrega van acompañados de pruebas y afinación, documentación, capacitación y todos los artefactos necesarios para que el proyecto pueda seguir su marcha. Si es un entregable externo, debe tratarse como el mismísimo producto final.
También, las dos especies de producto están sujetos a versionamiento. Sea un componente, la base de datos o una porción de la misma, un grupo de páginas ASP.NET o el producto de software en su completitud, incluyendo los documentos asociados, siempre debemos conocer su versión. Les recomiendo un versionamiento simple: Versión Mayor y Versión Menor; por ejemplo: 1.1, 2.5, 4.0. Creo que no es necesario utilizar las convenciones de las grandes casas productoras (que 8.04.003.185 Build 4321 o cosas así.)
Lo que sí deberíamos incluir, cuando sea del caso, son las Revisiones. Estas son pequeñas modificaciones o ajustes que quizás exigieron compilar y empaquetar de nuevo el software, pero nada más: la documentación es la misma, la funcionalidad no cambió, el impacto no se notó. Las cosas así, podríamos tener una versión 2.5 revisión 3 o una versión 4.0 revisión 2. Por supuesto, el número de revisiones es pequeño (máximo 5). De hecho, un conjunto de revisiones pequeñas quizás dan pie a una nueva versión menor (de la 2.5 a la 2.6).
Conclusión
Las Iteraciones constituyen una técnica apropiada, una mejor práctica, para la construcción de software. Se requieren nuevas habilidades en el manejo de proyectos, coordinación de equipos, documentación de software, desarrollos en tiempos más pequeños pero más especializados, equipos multidisciplinarios y compromiso de parte de todos los involucrados en el proyecto. Pero funciona, sin duda, en cualquier tipo de proyecto, con cualquier número de desarrolladores, sea cual fuere su complejidad.
Los invito entonces a que pongan en práctica este nuevo “arte” de Iterar, sin importar si usan o no una metodología estricta como RUP o una ágil. Seguramente, muy pronto verán los beneficios.
Y también los invito a que compartan conmigo y con todos en AAII sus comentarios acerca de este artículo. Me pueden escribir a lucho.salazar@gmail.com.
Luis Antonio Salazar Caraballo
Medellín, Octubre 15 de 2003

Las Seis Mejores Prácticas

En cuatro de las cinco últimas columnas he hablado de una u otra forma sobre modelado de software, en particular, y sobre desarrollo de aplicaciones, en general. En “El Papel del Modelado en la Transformación de los Requisitos en Software”, por ejemplo, decía que debemos elaborar modelos simples, a partir de cada porción significativa de requerimientos del software.
En “Qué Diagramas Usar?”, expresé mi opinión de que todas las técnicas y elementos en un proceso como RUP tienen múltiples propósitos y que realmente, no hay una “forma corta”, de decidir lo que es apropiado en cada situación (de modelado). Y en “El Imperio de las Metodologías” decía que era práctico dividir un proyecto en pequeñas piezas o mini-proyectos, donde cada mini-proyecto es una iteración.
Estas y otras ideas al respecto son la base de esta nueva entrega, sobre lo que debemos y no debemos hacer al emprender un proyecto de desarrollo de software, en especial sobre lo que sí debemos hacer, las prácticas que quienes nos enfrentamos día a día al reto de construir software de alta calidad consideramos como mejores, como soporte para el éxito anunciado en los proyectos.
Combinadas unas con otras y orientadas a la raíz de los problemas cotidianos de la construcción de software, estas prácticas permiten desarrollar y mantener aplicaciones en forma repetible y predecible. Ellas son:
1. Modelar Visualmente
2. Manejar Requisitos
3. Verificar la Calidad Continuamente
4. Usar Arquitecturas Basadas en Componentes
5. Desarrollar por Iteraciones
6. Controlar los Cambios
Modelar Visualmente
Para Modelar Visualmente, es necesario usar un lenguaje de diseño con una semántica extendida que permita mejorar la comunicación en el equipo de trabajo que elabora y revisa el diseño de la aplicación. Además de los textos gramaticales, el lenguaje debe proporcionar una sintaxis gráfica predominante y rigurosa con la cual expresemos las decisiones tomadas que luego servirán como base para la implementación del sistema. De esta forma, podremos entender mejor el sistema en construcción y razonar acerca de el con precisión. Hablo, por supuesto, de aplicaciones multi-desarrollador, aquellas en las cuales se invierte una cantidad considerable de talento humano, de tiempo y, claro, de recursos.
El Lenguaje de Modelado Unificado –UML cumple con estas características. Y sobre el ya hice una presentación que pueden encontrar en: http://b.1asphost.com/LuchoSalazar/GazafatonarioIT/Prolegmenos%20Sobre%20el%20Lenguaje%20de%20Modelado%20Unificado.pdf. También en el boletín No. 5, en esta misma columna, presenté una breve discusión sobre los distintos tipos de diagramas que usamos para hacer modelado visual. La columna está en: http://gazafatonarioit.blogspot.com/2005/02/qu-diagramas-usar.html.
En resumen, el modelado visual es un requisito porque muestra la esencia del sistema desde una perspectiva particular y oculta los detalles no esenciales. Los modelos, en general, pueden ayudar a:
Ø Entender sistemas complejos
Ø Explorar y comparar alternativas de diseño
Ø Formar una base sólida para la implementación
Ø Capturar los requisitos con precisión
Ø Comunicar decisiones inequívocamente
Manejar Requisitos
El Proceso Unificado define el Manejo de Requisitos como un enfoque sistemático para encontrar, documentar, organizar y hacer seguimiento a los cambios de los requisitos de un sistema.
En este punto sería interesante que hicieran el siguiente ejercicio que les propongo: Definir que es un “requisito”, un requisito de software, ciertamente. No se imaginan ustedes las sorpresas que me he llevado cuando le digo a los asistentes a mis cursos y conferencias que hagan esa tarea, al parecer, simple para muchos. Pues bien, desde el punto de vista de RUP, un requisito es una “condición o capacidad que el sistema debe cumplir o tener”.
Mientras escribo esta columna, John Alexander López prepara un artículo introductorio sobre manejo de requisitos de software. Esperemos a ver lo que tiene que decirnos al respecto. Lo que sí quiero dejar claro desde ya es que la recolección de requisitos puede sonar como una tarea simple y, sin embargo, puede causar estragos significativos en un proyecto porque los requisitos:
Ø no siempre son obvios y pueden venir de muchas fuentes
Ø no siempre son fácilmente expresables en palabras
Ø son de muchos tipos y de distintos niveles de detalle
Ø si no son controlados desde el comienzo del proyecto, su número puede crecer hasta límites inmanejables
Ø están sujetos a cambios “sin previo aviso”
Ahora bien, para manejar requisitos exitosamente, se requiere:
Ø Analizar el problema
Ø Entender las necesidades tanto de los patrocinadores del proyecto, como de los usuarios y demás responsables del mismo
Ø Definir el sistema
Ø Manejar el alcance del proyecto
Ø Refinar la definición del sistema
Ø Manejar los cambios
Cada una de estas actividades requiere de talento y, evidentemente, de tiempo y recursos compartidos en el equipo de desarrollo. En las próximas entregas les hablaré más del asunto.
Verificar Calidad Continuamente
Una vez me dijeron acerca de la Calidad: “yo no sé como describirla, pero soy capaz de reconocerla cuando la veo”. Les dejo una vez más la tarea de definir lo que es Calidad, concretamente, Calidad de Software.
Lo que sí quiero ilustrar en esta columna es que se debe evaluar la calidad de todos los artefactos en distintos puntos del ciclo de vida del proyecto, a medida que este crece. Estos artefactos deben ser validados al término de cada actividad o etapa que los produce (más adelante les hablaré de Iteraciones y de los resultados que se esperan en cada una de ellas). Específicamente, a medida que se producen componentes ejecutables del sistema, estos se deben someter a un proceso de pruebas que abarque los distintos escenarios para los cuales fueron construidos (todos los escenarios, hasta aquel que solo va a acontecer una vez en la vida útil del sistema y quizás hasta el que nunca va a suceder pero que es posible que ocurra).
Este proceso de pruebas conduce a la depuración del sistema y a la eliminación de los defectos arquitectónicos de la aplicación.
Usar Arquitecturas Basadas en Componentes
En ocasiones pienso acerca de cada ser humano como un imperio y acerca de la humanidad como una summa de imperios. Y una característica común a todos los imperios es que poseen tecnología y estrategias de guerra superiores a las de los conquistados, entre las que se encuentra la famosa “divide y vencerás”, utilizada por Julio César o Hernán Cortés y adoptada hoy como herramienta guerrera por las compañías multinacionales simplemente porque los imperios buscan el control puro y escueto de los conquistados.
Esta analogía me sirve para mostrarles que siempre hay que tener control (nosotros, el imperio) sobre lo que hacemos (soluciones de software). La estrategia de Julio César o Cortés se ha aplicado desde siempre en el desarrollo de software y se seguirá aplicando sin importar la metodología, el proceso, los avances tecnológicos o la cantidad y calidad de talento humano utilizado para crear un producto.
Y cuando dividimos ese producto en piezas más pequeñas, controlables, ajustables, intercambiables, lo que nos queda son grupos cohesivos de código, fuente o ejecutable, con interfaces y comportamiento bien definidos que proporcionan un fuerte encapsulamiento de su contenido. Estos grupos forman la arquitectura basada en componentes de nuestro sistema. Una arquitectura así tiende a reducir el tamaño y la complejidad de la solución y, por supuesto, es más robusta y resistente.
Hoy, las plataformas .Net o J2EE suministran las referencias arquitectónicas que necesitamos para diseñar y construir soluciones basadas en componentes. Como antes, ya se encuentra en preparación un artículo sobre la plataforma .Net que será publicado en el sitio Web de la Asociación.
Desarrollar por Iteraciones
Pero la arquitectura y el producto no es lo único que dividimos al ejecutar un proyecto. El mismo proyecto está sujeto a un fraccionamiento que ha mostrado ser muy efectivo.
La división de un proyecto en grupos continuos de proyectos más pequeños, sujetos a incesante revisión, dinámicos y evaluables, hace posible que tengamos completo control de todo el proyecto.
En El Proceso Unificado - Episodio IV, de hace un mes, expuse las razones por las cuales deberíamos adoptar esta práctica sin reparos. Antes de que volvamos a leerla, quisiera dejarlos con estas tres leyes que escribí hace pocos meses, luego de una discusión amena sobre manejo de proyectos:
Ø Todo proyecto de menos de dos semanas, tarda dos semanas
Ø Todo proyecto de entre dos semanas y un mes, tarda un mes
Ø No hay tal cosa como un proyecto que tarde más de un mes
Por supuesto, me refería a las iteraciones, que realmente pueden tardar más tiempo, algunos dicen que entre tres y nueve semanas, otros que entre dos y seis semanas. Bueno, esa fue mi conclusión, quince años de experiencia la soportan.
La última de estas tres leyes también se puede leer así:
Ø Todo proyecto que tarde más de un mes nunca termina
Y el que esté libre de culpa que lance la primera piedra.
Controlar los Cambios
Ya les dije antes que los requisitos de un sistema están sujetos a cambios “sin previo aviso”, sobre todo en proyectos a mediano y largo plazo. Pero primero lo primero, aclaración # 1: me refiero aquí a los cambios que sufren los requisitos luego de haber sido aprobados por los usuarios y de que posiblemente hayan sido implementados en alguna iteración, concluida o en ejecución, del proyecto.
Los desarrolladores noveles son muy dados a engancharse en una carrera contra el tiempo, contra los recursos, contra el contrato, contra el producto, cuando de llevar a cabo una modificación se trata. Y permítanme decirles, damas y caballeros, que antes de hacerlo es necesario estudiar en detalle el impacto que un cambio tendrá sobre todo nuestro sistema.
Un cambio en un requisito puede causar una dispersión de proporciones descomunales en un producto de software si no es definido claramente, evaluado y puesto a consideración de todo el equipo del proyecto. Por supuesto, el desarrollo iterativo y los componentes ayudan a mitigar los efectos ocasionados por los cambios en los requisitos y a que la implantación de estos se haga acorde a un plan establecido de manejo de cambios que no perturbe la ejecución del proyecto.
En el Final
Bueno, es realmente el final de una presentación efímera sobre estas prácticas. Como siempre, sostengo que los problemas más serios que he encontrado en los proyectos son de talento humano, en este caso, de comunicación entre quienes intervienen en un proyecto.
La conclusión es que cada una de estas prácticas debe tener una buena comunicación como prerrequisito. Sin una buena comunicación, todas fallarán al tratar de alcanzar su objetivo, todos fracasaremos sin duda, y seguramente recibiremos una dosis adictiva de apremio para caer en los métodos tradicionales de cascada donde la comunicación real es substituida por montones de documentos que no contribuyen mucho a producir valor para nuestros usuarios.
Ustedes qué creen? Compartan sus opiniones conmigo y con todos en AAII sobre este y otros temas. Pueden escribirme a lucho.salazar@gmail.com.
Referencias
http://www.rational.com/corpinfo/practices.jsp
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=11
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=24
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=11
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=18
El Proceso Unificado de Rational –RUP:
http://www.rational.com/products/rup/prodinfo.jsp
http://www.rational.com/tryit/rup/index.jsp
Luis Antonio Salazar Caraballo
Medellín, Septiembre 29 de 2003