Published 15 years ago
(updated 12 years ago)
Antipatrones en la Concepción de CU
Mucho se ha escrito sobre los Casos de Uso, ¿qué son?, ¿para qué sirven?, ¿cómo se pueden identificar?, etcétera. Uno puede encontrar en cualquier biblioteca, navegando por Internet o en una tienda electrónica como Amazon, decenas de artículos y bibliografía especializada sobre el tema. De hecho, emplear casos de uso se ha vuelto la técnica de captura de requerimientos más popular.La facilidad de concepción y diagramado los ha vuelto algo así como un sinónimo de “que se tratan de hacer las cosas con calidad” o que se emplea “algo” de ingeniería o procesos de software. Ahora bien, quienes nos hemos dedicado a desarrollar software y empleado esta técnica de manera intensiva en algún proyecto mediano o grande, seguramente nos encontramos con particularidades donde claramente se perciben los beneficios y limitaciones de los casos de uso. El presente artículo está dedicado a describir varias de estas situaciones.
Para iniciar esta discusión, permítanme ser claro sobre lo que varios consultores, e incluso personal de nuestros clientes, observamos durante la ejecución de diferentes proyectos en los que hemos tenido la oportunidad de participar, y en otros que conocemos de manera indirecta, y esto es: La falta de conocimiento formal que predomina en nuestra industria sobre lo que es un caso de uso, cómo debe describirse, para qué sirve y para qué no sirve.
Podría parecer aventurada dicha afirmación (personalmente desearía que así lo fuera). Sin embargo, la cantidad de sistemas y proyectos que arrastran tal problema es bastante grande.
Este artículo no pretende explicar estos conceptos, ni tampoco desea exponer las razones de esta debilidad, sino sólo enumerar los problemas y antipatrones particulares. Algunos de los cuales citamos a continuación.
Errores y antipatrones comunes
• Considerar que la interacción/comunicación que se muestra en los diagramas de CU donde aparece algún CU vinculado a uno o varios actores es sinónimo de flujo de datos.
• Considerar un subflujo como un caso de uso.
Ejemplo:
· CU Alta de Cliente, CU Baja de Cliente, CU Consulta de Cliente
• Considerar la “regla de oro” para entidades: Un CU debe exhibir forzosamente una funcionalidad “ABC” completa (Altas, Bajas, Cambios ).
Ejemplo:
· CU Ventas:
- Subflujo Altas de Órdenes de Compra
- Subflujo Bajas de Órdenes de Compra
- Subflujo Cambios de Órdenes de Compra
• Para considerar qué es incorrecto o no, deben existir líneas con cabezas de flecha asociando a un Actor con un CU.
• Considerar a la sección de precondiciones dentro de la descripción del CU como útil para incluir cualquier situación o evento que deba existir antes para iniciar un CU.
Ejemplo:
· Para que se de el CU “Administrar Órdenes de Compra”, debe
tenerse como precondiciones:
- Que el vendedor esté autenticado en el sistema
- Que exista un catálogo de artículos
- Que exista una interfase con el sistema que maneja el catálo-
go de artículos
- Que exista la comunicación con el sistema que maneja el
catálogo de artículos
• Incluir detalles de diseño o de bajo nivel dentro de la especificación de CU.
Ejemplos:
· El sistema debe conectarse con el sistema de administración de
inventarios y obtener de la tabla “artículos” el artículo X utilizan-
do el articuloID como llave foránea...
· El usuario da click en el campo “Artículos de Oficina” y selecciona
la categoría del combo “categoría”
· El sistema debe actualizar la tabla tarjetahabiente utilizando
el query “select * from...”
• Considerar que el comportamiento de uno o varios de los elementos de la interfase gráfica asociada son reglas de negocio.
• Considerar como “regla de oro” que no es necesario incluir un documento de requerimientos no funcionales, si estos se pueden cubrir totalmente incluyendo una sección llamada “requerimientos no funcionales” en la descripción de los CU.
• Creer que los lineamientos que están descritos en un proceso sobre algún formato específico son inamovible (aún cuando sea muy difícil emplearlo, no tenga sentido, o simplemente existan maneras alternativas que pueden proporcionar mayores beneficios).
• Y finalmente, lo que desde mi punto de vista es uno de los más grandes errores: Creer que la única forma de capturar requerimientos funcionales es utilizar CU.
Seguramente para muchos lectores estas descripciones (y otras más) les resultarán familiares, y para otros más les será una sorpresa saber que muchos conceptos o prácticas que aplican tan vehemente en sus proyectos en realidad son errores, fallas o antipatrones comunes de concepción o aplicación.
Como éste artículo no pretende incendiar los ánimos para indicar si algo está bien o no, sino sólo realizar sugerencias para ampliar y enriquecer el conocimiento de los roles que capturan, analizan y administran requerimientos, a continuación se hacen las siguientes recomendaciones.
Sugerencias y recomendaciones
• Estudiar bibliografía de Ingeniería de Requerimientos y no sólo de casos de uso. Acceder también a bibliografía de diferentes autores.
· Al investigar, el lector podrá constatar que los CU no es la única técnica para capturar requerimientos, y que en diversas situaciones tales como cuando exista poca interacción actores-sistema o cuando se trata de interfases de usuarios ricas y complejas manejadas por una gran cantidad de eventos, el tratar de utilizar CU resultará en tareas improductivas o muy costosas.
• Asistir a entrenamiento formal.
· Es muy posible que muchos directores, gerentes y líderes, consideren que no es necesario si existe Internet. Hay libros sobre el tema y quizá con uno o dos recursos que asistan a un curso básico son más que suficientes, frente a esto solo hay un 2 puntos que también se invita a considerar:
1. Ni Internet ni ningún libro poseen todo el conocimiento. Muchas veces la exposición e intercambio de experiencias e ideas con otros consultores y asistentes puede proporcionar una mayor variedad, profundidad o enfoque de los temas y conceptos.
2. Al desear que un solo asistente pretenda dispersar internamente el conocimiento a otros miembros del equipo, puede ser contraproducente, sobre todo considerando que es posible que al intentar replicar la capacitación se reproduzcan también dudas, malas interpretaciones o conceptos aún no entendidos totalmente, esto es, se desvirtúan los conceptos al pasar de boca en boca sin un pleno dominio del tema.
• Pensar “out-of-the-box”: Muchas veces queremos, deseamos o prometemos capturar los requerimientos funcionales utilizando sólo CU, esto es lo mismo que pensar: porque tengo un coche puedo tomarlo e ir de vacaciones a cualquier parte en él. Ciertamente es posible ir a Cuernavaca, Pachuca, Toluca, Puebla, Querétaro y Guadalajara, sin embargo, si quiero tomar vacaciones en Tijuana, San Francisco, Bogotá o Río de Janeiro, quizá ir en coche no resulte la mejor o más inteligente opción; en términos de los tiempos costos y esfuerzo asociado.
• Tratar de tocar mas de un dominio, esto es, tratar de intervenir o conocer proyectos en dominios o industrias tradicionales donde existan diferentes conceptos y procesos que por su naturaleza resulten en un reto para su conceptualización, tratamiento y comprensión.
• Relacionarse con otros analistas con diverso background y experiencia.
Referencias
[ Leffingwell, Dean;Widrig, Don. “Managing Software
Requirements A Use Case Approach”. Addison Wesley ]
[ Adolph, Steve; et. al.”Patterns for Effective Use Cases”.
Addison Wesley ]
[ Palmkvist, Övergaard.“Use Case Patterns and Blueprints”.
Addison Wesley Professional]
Acerca del Autor
Carlos Ortega es consultor en metodologías y prácticas ágiles(XP,TDD, Refactoring, Pair programming) cuenta con certificaciones en RUP, OOAD, UML, etcétera. Certified Profesional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como el Banco de México, Banco Azteca, Fandelli, Oracle, IMSS,Heinson, Accenture,EDS.Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Cristal).
Mucho se ha escrito sobre los Casos de Uso, ¿qué son?, ¿para qué sirven?, ¿cómo se pueden identificar?, etcétera. Uno puede encontrar en cualquier biblioteca, navegando por Internet o en una tienda electrónica como Amazon, decenas de artículos y bibliografía especializada sobre el tema. De hecho, emplear casos de uso se ha vuelto la técnica de captura de requerimientos más popular.La facilidad de concepción y diagramado los ha vuelto algo así como un sinónimo de “que se tratan de hacer las cosas con calidad” o que se emplea “algo” de ingeniería o procesos de software. Ahora bien, quienes nos hemos dedicado a desarrollar software y empleado esta técnica de manera intensiva en algún proyecto mediano o grande, seguramente nos encontramos con particularidades donde claramente se perciben los beneficios y limitaciones de los casos de uso. El presente artículo está dedicado a describir varias de estas situaciones.
Para iniciar esta discusión, permítanme ser claro sobre lo que varios consultores, e incluso personal de nuestros clientes, observamos durante la ejecución de diferentes proyectos en los que hemos tenido la oportunidad de participar, y en otros que conocemos de manera indirecta, y esto es: La falta de conocimiento formal que predomina en nuestra industria sobre lo que es un caso de uso, cómo debe describirse, para qué sirve y para qué no sirve.
Podría parecer aventurada dicha afirmación (personalmente desearía que así lo fuera). Sin embargo, la cantidad de sistemas y proyectos que arrastran tal problema es bastante grande.
Este artículo no pretende explicar estos conceptos, ni tampoco desea exponer las razones de esta debilidad, sino sólo enumerar los problemas y antipatrones particulares. Algunos de los cuales citamos a continuación.
Errores y antipatrones comunes
• Considerar que la interacción/comunicación que se muestra en los diagramas de CU donde aparece algún CU vinculado a uno o varios actores es sinónimo de flujo de datos.
• Considerar un subflujo como un caso de uso.
Ejemplo:
· CU Alta de Cliente, CU Baja de Cliente, CU Consulta de Cliente
• Considerar la “regla de oro” para entidades: Un CU debe exhibir forzosamente una funcionalidad “ABC” completa (Altas, Bajas, Cambios ).
Ejemplo:
· CU Ventas:
- Subflujo Altas de Órdenes de Compra
- Subflujo Bajas de Órdenes de Compra
- Subflujo Cambios de Órdenes de Compra
• Para considerar qué es incorrecto o no, deben existir líneas con cabezas de flecha asociando a un Actor con un CU.
• Considerar a la sección de precondiciones dentro de la descripción del CU como útil para incluir cualquier situación o evento que deba existir antes para iniciar un CU.
Ejemplo:
· Para que se de el CU “Administrar Órdenes de Compra”, debe
tenerse como precondiciones:
- Que el vendedor esté autenticado en el sistema
- Que exista un catálogo de artículos
- Que exista una interfase con el sistema que maneja el catálo-
go de artículos
- Que exista la comunicación con el sistema que maneja el
catálogo de artículos
• Incluir detalles de diseño o de bajo nivel dentro de la especificación de CU.
Ejemplos:
· El sistema debe conectarse con el sistema de administración de
inventarios y obtener de la tabla “artículos” el artículo X utilizan-
do el articuloID como llave foránea...
· El usuario da click en el campo “Artículos de Oficina” y selecciona
la categoría del combo “categoría”
· El sistema debe actualizar la tabla tarjetahabiente utilizando
el query “select * from...”
• Considerar que el comportamiento de uno o varios de los elementos de la interfase gráfica asociada son reglas de negocio.
• Considerar como “regla de oro” que no es necesario incluir un documento de requerimientos no funcionales, si estos se pueden cubrir totalmente incluyendo una sección llamada “requerimientos no funcionales” en la descripción de los CU.
• Creer que los lineamientos que están descritos en un proceso sobre algún formato específico son inamovible (aún cuando sea muy difícil emplearlo, no tenga sentido, o simplemente existan maneras alternativas que pueden proporcionar mayores beneficios).
• Y finalmente, lo que desde mi punto de vista es uno de los más grandes errores: Creer que la única forma de capturar requerimientos funcionales es utilizar CU.
Seguramente para muchos lectores estas descripciones (y otras más) les resultarán familiares, y para otros más les será una sorpresa saber que muchos conceptos o prácticas que aplican tan vehemente en sus proyectos en realidad son errores, fallas o antipatrones comunes de concepción o aplicación.
Como éste artículo no pretende incendiar los ánimos para indicar si algo está bien o no, sino sólo realizar sugerencias para ampliar y enriquecer el conocimiento de los roles que capturan, analizan y administran requerimientos, a continuación se hacen las siguientes recomendaciones.
Sugerencias y recomendaciones
• Estudiar bibliografía de Ingeniería de Requerimientos y no sólo de casos de uso. Acceder también a bibliografía de diferentes autores.
· Al investigar, el lector podrá constatar que los CU no es la única técnica para capturar requerimientos, y que en diversas situaciones tales como cuando exista poca interacción actores-sistema o cuando se trata de interfases de usuarios ricas y complejas manejadas por una gran cantidad de eventos, el tratar de utilizar CU resultará en tareas improductivas o muy costosas.
• Asistir a entrenamiento formal.
· Es muy posible que muchos directores, gerentes y líderes, consideren que no es necesario si existe Internet. Hay libros sobre el tema y quizá con uno o dos recursos que asistan a un curso básico son más que suficientes, frente a esto solo hay un 2 puntos que también se invita a considerar:
1. Ni Internet ni ningún libro poseen todo el conocimiento. Muchas veces la exposición e intercambio de experiencias e ideas con otros consultores y asistentes puede proporcionar una mayor variedad, profundidad o enfoque de los temas y conceptos.
2. Al desear que un solo asistente pretenda dispersar internamente el conocimiento a otros miembros del equipo, puede ser contraproducente, sobre todo considerando que es posible que al intentar replicar la capacitación se reproduzcan también dudas, malas interpretaciones o conceptos aún no entendidos totalmente, esto es, se desvirtúan los conceptos al pasar de boca en boca sin un pleno dominio del tema.
• Pensar “out-of-the-box”: Muchas veces queremos, deseamos o prometemos capturar los requerimientos funcionales utilizando sólo CU, esto es lo mismo que pensar: porque tengo un coche puedo tomarlo e ir de vacaciones a cualquier parte en él. Ciertamente es posible ir a Cuernavaca, Pachuca, Toluca, Puebla, Querétaro y Guadalajara, sin embargo, si quiero tomar vacaciones en Tijuana, San Francisco, Bogotá o Río de Janeiro, quizá ir en coche no resulte la mejor o más inteligente opción; en términos de los tiempos costos y esfuerzo asociado.
• Tratar de tocar mas de un dominio, esto es, tratar de intervenir o conocer proyectos en dominios o industrias tradicionales donde existan diferentes conceptos y procesos que por su naturaleza resulten en un reto para su conceptualización, tratamiento y comprensión.
• Relacionarse con otros analistas con diverso background y experiencia.
Referencias
[ Leffingwell, Dean;Widrig, Don. “Managing Software
Requirements A Use Case Approach”. Addison Wesley ]
[ Adolph, Steve; et. al.”Patterns for Effective Use Cases”.
Addison Wesley ]
[ Palmkvist, Övergaard.“Use Case Patterns and Blueprints”.
Addison Wesley Professional]
Acerca del Autor
Carlos Ortega es consultor en metodologías y prácticas ágiles(XP,TDD, Refactoring, Pair programming) cuenta con certificaciones en RUP, OOAD, UML, etcétera. Certified Profesional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como el Banco de México, Banco Azteca, Fandelli, Oracle, IMSS,Heinson, Accenture,EDS.Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Cristal).
- Log in to post comments