El que un
proceso sea dirigido por casos de uso no quiere decir que toda la funcionalidad
del software debe estar documentada en casos de uso. Hay requisitos que son
transversales al producto, es decir, aplican en varias partes del sistema;
también hay requisitos funcionales que se expresan mejor en prosa, siempre en
términos del usuario, pero en narrativa; hay otras funcionalidades cuya
complejidad amerita el uso de diagramas de actividad o de otro tipo de
elementos gráficos o visuales para entenderse. En este último caso, siempre
recomiendo el uso formal de UML como mecanismo de comunicación para no dar pie
a malos entendidos o a concentración de ambigüedades.
Ya lo he expresado antes,
los casos de uso apenas son uno de los mecanismos para identificar, organizar,
documentar y administrar requisitos o, en el orden de ideas que estoy
formulando, un receptáculo de requisitos, un depósito, un bote, una funda, un
artilugio. De hecho, los casos de uso constituyen la práctica industrial más
ampliamente usada en materia de requisitos de sistemas de información.
Lo digo de esta manera
porque he notado que es muy fácil para las personas extraviar la noción y la
práctica correcta de la Ingeniería de Requisitos y volverse “caso-de-uso-dependientes” y en
ocasiones crean una especie de religión donde el acto de fe por los casos de
uso toma tintes de devoción.
Como cualquier adicción,
esta también va a ser difícil de desarraigar de nuestros modelos mentales. Sin
embargo, vamos a intentarlo. Pero antes de eso, quiero reiterarles que soy
entusiasta de los casos de uso, quienes han seguido mi Gazafatonario IT conocen las Lecturas Fundamentales, un esfuerzo medio modesto
medio imponente por transmitir mi experiencia en el tema y que fueron la base
de mi próximo libro, actualmente en etapa de edición.
En los últimos meses también
he estado publicando sobre casos de uso 2.0, una estrategia que reúne
las mejores prácticas tradicionales y ágiles para la documentación de
requisitos de software, expuesta recientemente por el Dr. Ivar Jacobson y su
equipo. Sobre este tema volveremos más adelante, cuando hayamos entendido, o
hayamos vuelto a entender, el verdadero sentido del uso y el abuso de los casos
de uso.
Este ha sido
el principal objetivo de esta serie así llamada “Casos de Abuso”. En el capítulo 4 de la misma expongo las
distintas formas y colores que pueden tomar los requisitos del software:
Impacto en la calidad: Bajo.
PD. Para
saber más de ingeniería de requisitos, análisis de requisitos y el papel del Analista
de Requisitos y de otros aspectos relacionados, pueden leer mi Lectura
Fundamental 9: “RUP:
Fase de Concepción, Parte 2”, en mi Gazafatonario IT:
No hay comentarios.:
Publicar un comentario