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
|
Alto
|
|
Bajo
|
|
Medio
|
|
Medio
|
|
Medio
|
|
Alto
|
|
Bajo
|
|
Alto
|
|
Bajo
|
|
Alto
|
|
Alto
|
|
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.
[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
[15]http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/jun02/MisuseUseCasesJun02.pdf
[17]Real Academia de la
Lengua Española. RAE. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=abuso
No hay comentarios.:
Publicar un comentario