Esta es el
más debatible de todos los abusos. Está en una zona gris. En aras de la calidad
del producto, objetivo último de todo proyecto, siempre deberíamos hacer la
realización del caso de uso [3], sin tener en cuenta el grado de mayor o menor
complejidad del mismo. Sin embargo, siempre encontramos factores limitantes de
tiempo, de recursos y de costos que lo impiden.
Ya en el
primer abuso decía que mínimo debemos hacer la realización de los casos de uso
arquitectónicos. Seguramente, si hacemos bien nuestro trabajo de diseñadores de
software, de esta actividad surgirán la mayoría de las entidades del sistema, los objetos
controladores, las fachadas y las interfaces, entre otros tipos de objetos. El
número de casos de uso arquitectónicos varía de un proyecto a otro, pero
debería girar en torno a un 20% del total de casos de uso del producto. Es una
cifra un tanto arbitraria pero parece funcionar en la mayoría de los casos, al
grado de haberse convertido en una práctica generalizada.
¿Y el otro
80%? Yo siempre uso el precepto de “modelar para entender lo que vamos a
construir.” Si alguien en el equipo de desarrollo no entiende un caso de uso,
lo que hace o como lo implementa, entonces debemos apoyarnos en el modelado
para subsanar esta situación. Y la realización del caso de uso es un buen
comienzo para ello. ¿De cuántos diagramas preciso? Los que sean necesarios para
entender. Ni más ni menos.
Impacto en la calidad: Bajo.
PD. Sobre diseño de casos de
uso, más específicamente, sobre realización de casos de uso, los invito a leer
mi Lectura
Fundamental 10: Realización de Casos de Uso: De los Objetos y sus Interacciones
en mi Gazafatonario IT.
No hay comentarios.:
Publicar un comentario