Abusar.
(De abuso).
1. intr. Usar
mal, excesiva, injusta, impropia o indebidamente de algo o de alguien. Abusaba DE su autoridad.
Real Academia Española ©
Todos los derechos reservados
Caso
de Abuso 3: El caso de uso es la única documentación necesaria para construir
el software.
Quizás esta
idea surge de la premisa de que el proceso de desarrollo de software es
dirigido por casos de uso [1], que es algo mucho más amplio y totalmente
distinto. Además, está el factor tiempo que siempre hace falta en los proyectos
de desarrollo de software.
Un caso de
uso es el primer repositorio de documentación en un proyecto, puesto que es el
artefacto que legitima los requisitos funcionales del software. Sin embargo,
después del caso de uso y antes del código fuente hay un abismo sobre el que
debemos construir un puente para ir desde la solicitud del usuario, su problema
y sus necesidades, hasta un sistema de software que soporte su proceso, que
resuelva su problema y cubra sus necesidades.
Ahora bien,
hay casos de casos: están los llamados casos de uso arquitectónicos o más
complejos, que bien podrían representar alrededor del 20% del total de casos de
uso de un proyecto. A estos casos de uso debemos aplicarles rigurosamente el
proceso: Análisis, Diseño, Implementación, Pruebas, Despliegue y vuelta a
empezar. Y durante el Análisis y el Diseño se construyen una serie de
artefactos que van desde documentos anexos hasta diagramas (de UML) de casos de
uso, de secuencia, de comunicación, de clases, de estados, de actividad y de
entidad-relación, entre otros. También están los requisitos no funcionales o
especiales que aplican a cada uno de esos casos de uso, el pseudocódigo y los
prototipos; asimismo, están los casos y procedimientos de prueba.
Es
principalmente durante el período de Análisis y Diseño del caso de uso cuando
ocurre la suplementación del mismo, es decir, la adición de detalles técnicos y
no funcionales al caso de uso. Y en todas estas actividades intervienen todos
los miembros del equipo del proyecto: unos elaboran y presentan, otros
retroalimentan, complementan, realizan el siguiente paso y también lo
presentan, y así, en una espiral en la que el producto se va gestando hasta
quedar terminado.
Luego están
los demás casos de uso del proyecto, el otro 80%. Unos son más complejos que
otros desde el punto de vista de diseño, mientras que algunos son más críticos
que otros desde la perspectiva del usuario. Muchos de estos casos de uso, sino
todos, también deben someterse al mismo proceso que los anteriores. Lo que
varía es la severidad o formalidad con que se elaboren todos esos artefactos.
Dependiendo
del tipo de proyecto, de los aspectos legales del mismo y de otras variables
del entorno, será necesario realizar cada documento siguiendo plantillas
formales del proceso de desarrollo, casi con rigurosidad científica: diagramas
de UML bien construidos y detallados, tantos como sean necesarios para entender
el producto, documentos sujetos al escrutinio de revisiones técnicas y de
estilo, con listas de chequeo formales y con todas las excepciones
consideradas. Algunos casos de uso requerirán de tres, cinco o más diagramas de
interacción, por ejemplo; otros necesitarán sólo uno de estos diagramas.
En otros
proyectos, menos formales desde el punto de vista legal (aunque es difícil
imaginar tal cosa), será suficiente con que estos artefactos se elaboren en
reuniones de análisis y diseño en un tablero donde todo el equipo de desarrollo
pueda verlos, opinar, tomar nota y entenderlos, que es el objetivo último del
modelado.
La categoría
de las herramientas a usar también depende de la complejidad técnica y de la
formalidad legal: para unos proyectos basta lápiz y papel, o tiza y tablero,
mientras que para otros serán necesarias herramientas sofisticadas de
Ingeniería de Software.
En cualquier
caso, nunca hay que perder de vista que el software, por naturaleza, es
complejo; y que construir software, por naturaleza, es una actividad compleja.
También, que las herramientas con las que se construye software (que
casualmente están hechas de software) también son complejas. Y con este nivel
de complejidad, no es posible que algo simple, como el caso de uso, sea capaz
de resolver nuestro problema sin más colaboración.
Impacto en
la calidad: Alto.
Referencias
[1]
Luis
Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html,
08 mar. 2007.
La Parte 1 de este análisis lo encuentras en: http://gazafatonarioit.blogspot.com/2012/09/casos-de-abuso-parte-1.html
Sobre abecés, anatomía y prácticas de casos de uso y requisitos en general, puedes visitar mi
Sección Lecturas Fundamentales en este mismo Gazafatonario IT.
No hay comentarios.:
Publicar un comentario