Los casos de abuso o de cómo hacer un mal uso de los casos de uso

Este fue un estudio de hace unos 5 años. Los resultados los publiqué entonces internamente como la Lectura Fundamental 13, que nunca vio la luz en este Gazafatonario. Solo ahora, revisando los temas que incluiré en mi próximo libro, decidí hacerlos público abiertamente como ustedes los han estado leyendo.

No obstante el tiempo que ha pasado desde entonces, el resultado de mi observación es que seguimos cometiendo estos errores incontables veces. Por eso no quise esperar a que el libro estuviera publicado.

Lo primero que se deriva de este análisis es que los casos de uso no son el único instrumento para especificar requisitos de software, algo que he llamado en otras instancias “el arquetipo de los envoltorios heterogéneos”.

Pero antes de ir a la conclusión de este estudio, revisemos los abusos que estamos cometiendo:

Caso de Abuso	Impacto en la Calidad
El caso de uso es la única documentación necesaria para construir el software.	Alto
El caso de uso se usa en todos los casos.	Bajo
Lo que no está documentado en los casos de uso no hace parte del sistema.	Medio
El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.	Medio
El caso de uso contiene detalles de formularios (pantallas) y otros aspectos técnicos (bases de datos, componentes, etc.)	Medio
Un escenario y un caso de uso es lo mismo	Alto
La realización o diseño de un caso de uso siempre se hace	Bajo
Precondiciones vs. Validaciones y Poscondiciones vs. Resultados	Alto
Todos los requisitos funcionales se documentan en casos de uso.	Bajo
Los flujos de eventos en los casos de uso son escritos en pseudocódigo	Alto
Cada caso de uso se diseña e implementa de manera independiente.	Alto
El Ingeniero de Requisitos es un psíquico	Medio

Hay muchos más: el problema es mucho más grave cuando no hay el entrenamiento y acompañamiento que todo Analista o Ingeniero novel necesita cuando emprende el viaje hacia lo que significa identificar, documentar, organizar y administrar requisitos de software.

Para No Cometer Más Abusos

En general, las personas creemos que el mejor proceso de aprendizaje es la lectura. Si bien es cierto que leer es fundamental, sobre todo en las etapas tempranas de la carrera de un buen profesional, pienso que la forma principal de aprendizaje es la introspección. Leer siempre ayuda, especialmente porque puede hacernos reflexionar sobre puntos que no habíamos analizado previamente, pero la mejoría como Analista de Requisitos en particular y como Ingeniero de Software en general, más allá de un ingeniero primitivo que hace su trabajo con las prácticas regulares transmitidas por instructores académicos que muchas veces nunca han estado en un proyecto de construcción de software, empieza siempre por el análisis profundo de cada situación. Conocer nuestras debilidades y saber por qué estamos haciendo en cada situación lo que estamos haciendo, es lo que nos acabará convirtiendo en mejores profesionales. Y para eso, aprender de los propios errores es algo esencial, tratando de evitar automatismos que pueden repercutir negativamente en nuestra profesión.

En particular, recomiendo leer a Cockburn [11] de quien ya he repetido es uno de los mejores autores de temas relacionados con la materia que nos ocupa: la escritura de casos de uso. El libro tiene un capitulo completo sobre errores cometidos al momento de escribir casos de uso. Pero también encuentro de mucha utilidad volver a leer y a releer los casos de uso que hemos escrito anteriormente. Y leer los casos de uso de nuestros compañeros. Someter los nuestros al escrutinio de nuestros pares y de otros expertos en el área, recibir con respeto las observaciones que nos hacen y discutirlas abiertamente. Leer las guías y listas de chequeos existentes y seguir las indicaciones de las plantillas ayuda profusamente. Para noveles, recomiendo las cinco primeras lecturas fundamentales de mi Gazafatonario IT [13] (Gazafatonario.Blogspot.com).

El artículo que motivó este estudio lo leí hace unos 13 años [14], lo encargo pródigamente. En [12] hay un compendio expedito sobre la cuestión, a manera de enumeración ejecutiva sobre lo malo y lo feo en las prácticas de casos de uso. De la misma forma, en [7] hay unas guías para cometer abusos, por supuesto, debemos usarlas a la inversa. Finalmente, en [15] y en [10] Ellen Gottesdiener identifica algunos patrones de abuso que siguen los equipos de desarrollo a la hora de crear casos de uso; no puede faltar en nuestra biblioteca digital de consulta. Por su parte, en [16] encontramos algunas sugerencias para aplicar durante el entrenamiento de estudiantes y profesionales en el área de Requisitos de Software, específicamente en modelado y especificación de casos de uso.

Y mi última recomendación: ¡Lanzarnos! Es decir, escribir casos de uso.

(Aclaración)

A propósito de todos estos trabajos relacionados que especifico en la sección anterior, cuando hacía la labor de investigación de fondo sobre este tema (paso 2 del método científico), me encontré inexorablemente en Google buscando por los términos “abuse cases” y “misuse cases” y Oh sorpresa mayor cuando me topé con [8] y [9] y el contexto es totalmente distinto al que deseaba: resulta que un caso de abuso (“abuse case”) es una especificación de un tipo de interacción completa entre un sistema y uno o más actores, donde los resultados de la interacción son dañinos para el sistema, para uno de los actores o para uno de los involucrados (stakeholders) en el sistema. Seguí este hilo y encontré todo un sumario que habla de modelos de casos de abuso para hacer análisis de requisitos de seguridad y de casos de uso con intención hostil (hacia los sistemas de software), no sólo en cuanto a la seguridad de las aplicaciones se refiere sino a los demás requisitos “ilidad” (confiabilidad, mantenibilidad, soportabilidad, funcionalidad y otras “ilidades” conocidas).

Así es que me pareció pertinente contarles el cuento por si llegan al punto o por si llegan a necesitar el dato. No es más.

Conclusiones

Errores se cometen en cualquier actividad, incluso he llegado a creer que la propia Naturaleza se equivocó al seleccionarnos como especie dominante durante este período cuaternario de la era Cenozoica, pero ese es otro asunto. Sin embargo, de los errores se aprende y, al parecer, estamos preparados para aprender muy rápido de nuestros propios sofismas. Es por eso que quise traerles este vademécum que espero se convierta en material de consulta regular y que apoye al elemento sorpresa asociado al descubrimiento de que estamos equivocados, para que así podamos formarnos en el difícil oficio de la Ingeniería de Requisitos y afines.

Sin duda, la lista de faltas puede ser mayor, pero lo que hacemos no define quienes somos, lo que nos define es qué tan bien nos levantamos después de caernos; es decir, lo que hacemos después de cometer la infracción. Algunos de estos abusos son más graves que otros, no tanto para nosotros, individuos reemplazables, sino para nuestros receptores principales: los usuarios.

Referencias

Algunas de estas referencias “bibliowebgráficas” ya las he mencionado en cada uno de los casos de abuso. Aquí están todas en conjunto para su consulta:

[1]  P.B. Kruchten, “The 4 + 1 View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910

[2]   Luis Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html, 08 mar. 2007.

[3]  Luis Antonio Salazar Caraballo, “Realización de Casos de Uso: de los Objetos y sus Interacciones”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html, 23 oct. 2006.

[4]  Luis Antonio Salazar Caraballo, “Casos de Uso: Del Todo y de Sus Partes”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-3.html, 23 nov. 2006.

[5]  Así conocen al célebre trío de metodólogos que lideraron la creación de RUP y UML: Ivar Jacobson, James Rumbaugh y Grady Booch.

[6]  Luis Antonio Salazar Caraballo, “Casos de Uso: Origen, Especificación y Evolución”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-2.html, 17 nov. 2006.

[7]  http://ebgconsulting.com/Pubs/Articles/Abuse%20Case%20Guidelines.pdf

[8]  http://www.sreis.org/old/2001/papers/sreis012.pdf

[9]  http://easyweb.easynet.co.uk/~iany/consultancy/misuse_cases_hostile_intent/misuse_cases_hostile_intent.htm

[10]http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jul02/TopTenWaysJul02.pdf

[11]Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 21 Feb. 2000

[12]http://www.isr.uci.edu/events/Research-Forum-2004/presentations/ziv.pdf

[13]Gazafatonario.Blogspot.com

[14]http://martinfowler.com/distributedComputing/abuse.pdf

[15]http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/jun02/MisuseUseCasesJun02.pdf

[16]http://re.cti.depaul.edu/REET05/F4_BeusDeukic.pdf

[17]Real Academia de la Lengua Española. RAE. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=abuso

Todavía Otro Cuerpo de Conocimiento Más (BABOK 2.0)

El Business Analysis Body of Knowledge (BABOK) es una colección de conocimiento dentro de la profesión del Análisis de Negocio y refleja unas mejores prácticas generalmente aceptadas. Como con otras profesiones, el cuerpo de conocimiento es definido y mejorado por profesionales Analistas de Negocios quienes lo aplican en su trabajo diario. El BABOK  describe las áreas de conocimiento del Análisis de Negocio, sus actividades asociadas y las tareas y habilidades necesarias para ser efectivo en su ejecución.

Como todo cuerpo de conocimiento (PMBOK, SWEBOK, entre otros), el BABOK tiene varias áreas de Conocimiento. Cada una de estas áreas se enfoca en una parte del análisis del negocio. Estas áreas son:

·         Planeación y Monitoreo del Análisis de Negocio

·         Obtención de Requisitos

·         Gestión y Comunicación de Requisitos

·         Análisis Empresarial

·         Análisis de Requisitos

·         Evaluación y Validación de la Solución

·         Competencias Subyacentes 

·         Dinámica de Análisis de Negocios 

Me parece importante anotar que esto no es más que eso, una propuesta de prácticas que funcionan en ciertos contextos, en muchos realmente, pero no es una solución definitiva a todos los posibles escenarios que nos encontramos en la “vida real” del análisis y modelado de negocios en los proyectos actuales.

Cuando se trata de estándares siempre recomiendo darles el beneficio de la duda. Lo primero que debemos hacer es estudiarlo profusamente y entenderlo, apoyándonos en expertos que lo hayan puesto en prácticas en diversas situaciones. A partir de allí, podemos iniciar un proceso de adopción y adaptación. A esto último yo lo llamo “tropicalización”.

Lo adaptamos a nuestras necesidades, a nuestra forma de hacer las cosas, a nuestro presupuesto y economía, a nuestra experiencia (que siempre nos va a faltar), a nuestra idiosincrasia, a nuestra forma de ver el mundo y de interpretarlo, a la agenda tan apretada que tenemos en los proyectos. Esto es importante, porque este tipo de estándares son definidos por organizaciones o grupos de organizaciones que tienen otra filosofía, existen en otras economías (generalmente mejores que las nuestras), la gente que los práctica allá piensa diferente, los proyectos tienen otros presupuestos y otras agendas, los equipos de trabajo son más grandes, tienen más recursos y más experiencia, tienen más expertos, etc.

¿A quiénes les interesa este estándar?

Principalmente a los Analistas del Negocio, pero también a los Ingenieros de Requisitos o Analistas de Requisitos.

“El Analista de Negocios es el responsable de identificar las necesidades de negocios de sus clientes y usuarios interesándose en ayudarlos a determinar las soluciones a sus problemas”.

·         El Analista de Negocios es responsable del:

o    Desarrollo y Administración de Requisitos de sistemas

o    Validación de requisitos para re-ingeniería de Procesos

o    Análisis y recomendación de soluciones de mejora continua

o    Validación y documentación de problemas y oportunidades de negocio

o    Análisis de requisitos Organizacionales u Operacionales

·         Las Soluciones NO son predeterminadas por el Analista- de Negocios- y son manejadas solamente a través del requerimiento de negocios.

·         Las Soluciones frecuentemente incluyen componentes de desarrollo de sistemas- pero pueden también consistir en mejoramiento de procesos o cambios organizacionales.

·         El Analista de Negocios es el facilitador clave dentro de una organización, el cual actúa como puente entre el cliente, el usuario interesado y el equipo de solución.

·         El Análisis de Negocios es distinto al análisis financiero, a la administración de proyectos, al aseguramiento de calidad, al desarrollo organizacional, a la ejecución de pruebas, a la capacitación y al desarrollo de documentación.

Sin embargo dependiendo de la organización, un Analista de Negocios puede ejecutar alguna o todas estas funciones relacionadas.

Estándares Relacionados

Relacionado estrechamente con el BABOK encontramos el SWEBOK (Software Engineering Book of Knowledge), sobre todo en el capítulo 2 que tiene que ver con Ingeniería de Requisitos. Este estándar es soportado por la IEEE.