Anteriormente hemos hablado sobre la importancia de saber valorar y definir nuestros recursos y lo que cuesta nuestro tiempo a la hora de acometer cualquier proyecto de autoempleo. También hemos hablado sobre la importancia de las metodologías en el trabajo autoempleado. Pero aún no hemos hablado de ¿Por qué es importante definir y validar casos de uso?.
En mayor o menor medida, todos conocemos lo que es un caso de uso y para que se utiliza. Muchos profesionales ven la tarea de definir casos de uso como algo tedioso y aburrido que al final, no vale para nada. No voy a entrar a valorar la magnitud del error que creo que comete ese tipo de profesional con ese tipo de aseveración. Definir un documento de especificación funcional es tarea fundamental a la hora de defender nuestros proyectos y legitimar los cambios facturables a los mismos.
El Objetivo
El objetivo de perder una mañana (o una tarde) escribiendo una especificación funcional no es la de colaborar a la tala de árboles para fabricar papel. El objetivo primario y fundamental de la definición de un documento de especificación funcional es el de cerrar la funcionalidad y el diseño de una aplicación con el suficiente detalle como para crear un marco de trabajo donde vayamos desarrollando y cerrando casos de uso o escenarios, y el cliente vaya revisándolos y enviando tickets si encuentra algún tipo de bug o error en el comportamiento de la aplicación.
El documento de especificación funcional ha de servir como guía tanto al desarrollo como al testeo de la aplicación. Nosotros escribiremos código que cumpla con las especificaciones de los casos de uso o escenarios y el cliente deberá de ejecutar esos casos de uso o escenarios y comprobar que la aplicación se comporta como se espera y sin errores según el enunciado del mismo. Si no disponemos de un documento guía validado por el cliente en el que apoyarnos, ¿cómo pretendemos huir de los temidos poyaques?
El método
El método es muy sencillo. Escribimos un documento que deberá incluir una cabecera de Control Documental donde se especifiquen:
Nombre del documento
Resumen
Autor
Revisado por (que incluirá el nombre de la persona que revisa el documento si la hubiera)
Aprobado por (que incluirá el nombre de la persona que lo valida en la organización del cliente)
Además el documento debe de incluir una sección de control de versiones donde se incluirá:
Versión
Fecha de modificación
Nombre de la persona que edita
Una breve descripción de la versión
¿Que no lo visualizas dices?, para eso estamos nosotros. A continuación un sencillo ejemplo:
| Nombre | Módulo yustaposicionador de condensadores de forlayos para Drupal |
|---|---|
| Resumen | Descripción de la funcionalidad e interfaz del Módulo |
| Autor | Perico de los palotes |
| Revisado por | El jefe de Perico de los palotes |
| Aprobado por | El señor de los Poyaques (el cliente) |
| Versión | Fecha | Editor | Descripción |
|---|---|---|---|
| 0.1 | 01/06/11 | Perico de los palotes | Primera versión del documento. Escenarios del 1 al 6 |
| 0.2 | 10/06/11 | Perico de los palotes | Modificado escenario 6. Añadidos escenarios 7, 8 y 9 |
Como puedes comprobar, es una cosa muy sencilla.
Utilidad del Documento
El documento tiene diferentes utilidades (además de esa que pasa por ir al baño en la que estás pensando).
Legitimación de facturabilidad y protección anti poyaques
Ahora fíjate en la tabla de versiones en la segunda fila. Hay una modificación del documento de especificación funcional (ojo, las versiones 0.1 y 0.2 se refieren al documento y no a la aplicación) donde se modifica el escenario seis y se añaden tres nuevos escenarios. Como el documento ha sido validado por El Señor de los Poyaques, que es el nombre ficticio de nuestro cliente ficticio, esas modificaciones suponen un cambio en el plan de desarrollo y por lo tanto requieren de un nuevo presupuesto que acompañe a las descripciones de estos nuevos escenarios. El cliente deberá validar entonces los nuevos escenarios y el nuevo presupuesto antes de acometer ni una sola línea de código.
Si el cliente no valida la nueva versión del documento de especificación funcional, entonces no se acometen los cambios introducidos a la misma. Nuestra defensa para legitimar ese comportamiento es muy sencilla:
Verá Señor de los Poyaques, estos cambios han sido introducidos diez días después de que validáramos los escenarios en la primera versión del documento de especificación funcional. Por lo tanto, estos cambios están fuera de presupuesto ya que son debidos a que ustedes han introducido elementos nuevos o han modificado los existentes al marco de desarrollo. Como usted comprenderá Señor de los Poyaques el coste de esos cambios no pueden ni deben ser asumidos por <mi/nosotros/nombre empresa> puesto que no representan un error de diseño o de programación y por lo tanto, están fuera del presupuesto aprobado el día 1 de Junio como usted puede comprobar en el control de versiones del documento.
Es muy sencillo defender la postura de “un cambio no es un bug, error o descuido” cuando disponemos de un documento validado y firmado por el cliente donde da su visto bueno y aprueba un plan de desarrollo basado en escenarios de uso. Además, de esta manera hacemos entender al cliente que no somos una ONG y que el trabajo extra se paga. Yo siempre uso analogías referentes a dos profesiones, o a los mecánicos o a los fontaneros, puesto que esas dos profesiones son temidas y necesitadas por todo hijo de vecino y es muy fácil extrapolar y que se entienda. Por ejemplo:
Si usted va al mecánico Señor de los poyaques para que le cambien el filtro del inyector, y una vez está allí le da a usted por que le cambien también el tubo de escape y le dice al mecánico; Poyaque estamos, vamos a ponerle también un tubo de escape nuevo. ¿Se lo hace a usted gratis el mecánico?. Pues nosotros seguimos la misma política.
Esto no es una ciencia exacta pero te aseguro que tiene casi la misma efectividad que la medida campofutbolera en el periodismo. Palabrita.
Guía de desarrollo y pruebas de la aplicación
Los escenarios de uso nos dan una estupenda guía para no perdernos en detalles (que somos programadores y nos distraemos del objetivo principal con facilidad) e implementar lo que el caso de uso define en su cuerpo. En todo escenario o caso de uso hay que definir uno o varios actores que interpretan un rol y utilizan una interfaz para proveer de una entrada de datos y reciben una salida, eso define lo que se espera que haga el sistema ante una situación determinada. No te sorprendas si tu documento acaba con 20 o 30 escenarios, es habitual.
También sirve de guía al cliente a la hora de comprobar que la aplicación se comporta como se espera de ella, que es como está definido en el escenario o caso de uso. Si el cliente detecta que la aplicación se comporta de forma extraña o no concuerda la salida de datos con lo que se definió en el caso de uso, podrá abrir un ticket y reportar un bug que deberemos solucionar de forma gratuita claro.
Observaciones
Según la “Ingeniería del Software“, un documento de especificación funcional también especifica otro tipo de datos de carácter técnico como modelos de datos y análisis. Yo prefiero no añadir nada más que escenarios o casos de uso a éste documento y guiarme por la metodología de gestión de proyectos que se acuerde usar para documentar ese tipo de cosas. Habrá gente que este completamente en desacuerdo con esa práctica, es cuestión de gustos. Hay que recordar que el objetivo de este post es remarcar la importancia de definir escenarios.
Conclusión
Queda de manifiesto la importancia de definir y validar escenarios y casos de uso. Los profesionales TIC tenemos la fea costumbre de comer tres veces al día todos los días, y claro, para eso hace falta cobrar por nuestro trabajo. En otras profesiones se da por sentado que un cambio o una ampliación va a suponer un coste adicional, pero la gente no lo da por sentado en nuestro sector. Es nuestro deber como profesionales hacer cambiar esa tendencia dejando claro y sin lugar a equívocos cuales son los parámetros con los que vamos a trabajar y van a marcar nuestra relación con el cliente. De esta manera y una vez más, estaremos construyendo la excelencia.
En Genbeta Dev | Autoempleo no es prostitución, La importancia de las metodologías…
Más Información | Peopleware.