Fase 1: ¿Qué estamos haciendo?

En la generación previa de diseño de programas (llamadodiseño procedural), esto se llamaba «crear elanálisis de requisitosyespecificación del sistema». Éstos, por supues- to, eran lugares donde perderse; documentos con nombres intimidantes que podrían llegar a ser grandes proyectos en sí mismos. Sin embargo, su intención era buena. El análisis de requisitos dice: «Haga una lista de las directrices que usará para saber cuándo ha hecho su trabajo y el cliente estará satisfecho». La especificación del siste- ma dice: «Hay una descripción delo quehará el programa (nocómo) por satisfacer los requisitos». El análisis de requisitos es realmente un contrato entre usted y el cliente (incluso si el cliente trabaja dentro de su compañía o es algún otro objeto o sistema). Las especificaciones del sistema son una exploración de alto nivel del problema y en algún sentido un descubrimiento de si se puede hacer y cuánto se tardará. Dado que ambos requerirán consenso entre la gente (y porque suelen cambiar todo el tiempo), creo que es mejor mantenerlos todo lo escueto posible -en el mejor de los casos, lis- tas y diagramas básicos- para ahorrar tiempo. Podría tener otras restricciones que le exijan ampliarla en documentos más grandes, pero manteniendo el documento inicial pequeño y conciso, puede crearse en algunas sesiones de tormentas de ideas de grupo con un líder que cree la descripción dinámicamente. Esto no sólo solicita participación de todos, también fomenta aprobación inicial y llegar a acuerdos entre todos. Quizá lo más importante sea empezar el proyecto con mucho entusiasmo.

Es necesario no perder de vista lo que está intentando conseguir en esta fase: determinar el sistema que se supone que quiere hacer. La herramienta más valiosa para eso es una colección de los llamados «casos de uso». Los casos de uso iden- tifican características clave en el sistema que pueden revelar algunas de las clases fundamentales que se usarán. En esencia son respuestas descriptivas a preguntas como:9_:

1. «¿Quién usará el sistema?»

2. «¿Qué pueden hacer estos actores con el sistema?»

3. «¿Cómo puede este actor hacer eso con este sistema?»

4. «¿Cómo podría alguien más hacer este trabajo si alguien más estuviera hacién- dolo, o si el mismo actor tuviera un objetivo diferente?» (para revelar variacio- nes).

5. «¿Qué problemas podrían ocurrir mientras hace esto con el sistema?» (para revelar excepciones).

Si está diseñando un cajero automático, por ejemplo, el caso de uso para un aspec- to particular de la funcionalidad del sistema es poder describir qué hace el contes- tador automático en todas las situaciones posibles. Cada una de esas «situaciones» se denominaescenario, y se puede considerar que un caso de uso es una colección de escenarios. Puede pensar en un escenario como una pregunta que comienza con: «¿Qué hace el sistema si...?» Por ejemplo, «¿Qué hace el cajero automático si un clien- te ingresa un cheque dentro de las 24 horas y no hay suficiente en la cuenta para proporcionar la nota para satisfacer el cargo?»

Los diagramas de caso de uso son intencionadamente simples para impedir que se atasque con los detalles de implementación del sistema demasiado pronto:

Banco

Hacer

Depósito

Retirar

Fondos

Pedir Balance

de cuenta

Transferir

entre cuentas

Cajero

Cajero

automático

Figura 1.10: Diagramas de casos de uso

Cada monigote representa un «actor», que típicamente es un humano o algún otro tipo de agente libre. (Incluso puede ser otro sistema de computación, como es el caso del «ATM»). La caja representa el límite del sistema. Las elipses representan los casos de uso, los cuales son descripciones de trabajo válido que se puede llevar a cabo con el sistema. Las líneas entre los actores y los casos de uso representan las interacciones.

No importa cómo está implementado realmente el sistema, mientras se lo parezca al usuario.

Un caso de uso no necesita ser terriblemente complejo, incluso si el sistema sub- yacente es complejo. Lo único que se persigue es mostrar el sistema tal como aparece ante el usuario. Por ejemplo:

1.9. Análisis y diseño

Mantener

temperatura

Invernadero

Figura 1.11: Un ejemplo de caso de uso

Los casos de uso producen las especificaciones de requisitos determinando todas las interacciones que el usuario puede tener con el sistema. Intente descubrir una serie completa de casos de uso para su sistema, y una vez que lo haya hecho tendrá lo esencial sobre lo que se supone que hace su sistema. Lo bueno de centrarse en casos de uso es que siempre le lleva de vuelta a lo esencial y le mantiene alejado de los asuntos no críticos para conseguir terminar el trabajo. Es decir, si tiene una serie completa de casos de uso puede describir su sistema y pasar a la siguiente fase. Probablemente no lo hará todo perfectamente en el primer intento, pero no pasa nada. Todo le será revelado en su momento, y si pide una especificación del sistema perfecta en este punto se atascará.

Si se ha atascado, puede reactivar esta fase usando una herramienta tosca de aproximación: describir el sistema en pocos párrafos y después buscar sustantivos y verbos. Los nombres pueden sugerir actores, contexto del caso de uso (ej. «lobby»), o artefactos manipulados en el caso de uso. Los verbos pueden sugerir interacción entre actores y casos de uso, y pasos específicos dentro del caso de uso. Además descubrirá que nombres y verbos producen objetos y mensajes durante la fase de diseño (y observe que los casos de uso describen interacciones entre subsistemas, así que la técnica «nombre y verbo» sólo se puede usar como una herramienta de lluvia de ideas puesto que no genera casos de uso)10.

El límite entre un caso de uso y un actor puede mostrar la existencia de una interfaz de usuario, pero no la define. Si le interesa el proceso de definición y creación de interfaces de usuario, veaSoftware for Usede Larry Constantine y Lucy Lockwood, (Addison Wesley Longman, 1999) o vaya awww.ForUse.com.

Aunque es un arte oscuro, en este punto es importante hacer algún tipo de esti- mación de tiempo básica. Ahora tiene una visión general de qué está construyendo así que probablemente será capaz de tener alguna idea de cuánto tiempo llevará. Aquí entran en juego muchos factores. Si hace una estimación a largo plazo entonces la compañía puede decidir no construirlo (y usar sus recursos en algo más razonable -eso es bueno). O un gerente puede tener ya decidido cuánto puede durar un pro- yecto e intentar influir en su estimación. Pero es mejor tener una estimación honesta desde el principio y afrontar pronto las decisiones difíciles. Ha habido un montón de intentos de crear técnicas de estimación precisas (como técnicas para predecir la bolsa), pero probablemente la mejor aproximación es confiar en su experiencia e in- tuición. Utilice su instinto para predecir cuánto tiempo llevará tenerlo terminado, entonces multiplique por dos y añada un 10 %. Su instinto visceral probablemente sea correcto;puedeconseguir algo contando con este tiempo. El «doble» le permitirá convertirlo en algo decente, y el 10 % es para tratar los refinamientos y detalles fi-

10_{Puede encontar más información sobre casos de uso enApplying Use Casesde Schneider & Winters}

nales11. Sin embargo, usted quiere explicarlo, y a pesar de quejas y manipulaciones que ocurren cuando publique la estimación, parece que esta regla funciona.