Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 21 — #59
✐
1.9. Análisis y diseño
Invernadero
Mantener
temperatura
Jardinero
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, vea Software for Use de Larry Constantine y Lucy Lockwood,
(Addison Wesley Longman, 1999) o vaya a www.ForUse.com.
Aunque es un arte oscuro, en este punto es importante hacer algún tipo de estimació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 proyecto
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 intuició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; puede conseguir 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 en Applying Use Cases de Schneider & Winters
(Addison-Wesley 1998) y Use Case Driven Object Modeling with UML de Rosenberg (Addison-Wesley 1999).
21
✐
✐
✐
✐