Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Visión. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Visión. Mostrar todas las entradas

miércoles, abril 17, 2013

¿Es usted la persona correcta para responder mis preguntas? O el síndrome del sujeto equivocado



En los proyectos de software estamos llenos de personas que no son “las adecuadas para responder nuestras preguntas”, para establecer las verdaderas necesidades del negocio, para darnos a conocer el problema que tienen, el problema detrás del problema, la causa raíz, el impacto de ese problema y las áreas impactadas. Estamos llenos de personas que constantemente no toman decisiones, que tienen que consultar con alguien más, que no entienden lo que nos están contando durante un proceso típico de educción de requisitos, es decir, durante las entrevistas, al responder cuestionarios o al analizar prototipos, entre otras actividades.

Por eso es que nuestros proyectos están repletos de supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los supuestos le están haciendo mucho daño a la industria y conducen a la producción de software de baja calidad o que no satisface para nada las necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno, y si no se produce la respuesta que requiere, entonces la presume.

Esta necesidad de hacer supuestos es inherente al ser humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para llenar el vacío y la insatisfacción que sobreviene, es la única manera de sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de saber.

Debido a ello, cuando un interlocutor, un usuario u otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos dice que no está seguro, que va a confirmar tal o cual asunto, que debe reunirse la próxima semana con una o más personas para aclarar un tema, etcétera, nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos de trabajo tienen siempre una sección de Supuestos en la que registramos estas conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es eliminar esta sección de los documentos, son perjudiciales.

También es bien sabido que los usuarios típicamente no saben lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al preguntar porque somos propensos a creer que el problema de los usuarios es de índole tecnológica y no algo puramente del negocio. Incluso, antes de eso, fallamos al seleccionar y clasificar correctamente a los usuarios correctos o alguien más toma la decisión por nosotros, lo que deja el proyecto en una incertidumbre mayor que aquella con la que inició.

Los supuestos son atajos hacia la veracidad. El problema es que casi nunca acertamos al escoger el camino apropiado. Siempre que sea posible, reemplacemos esas hipótesis por hechos probados, por evidencias que soporten la toma de decisiones, seleccionando mejor nuestros usuarios, entrevistando al mayor número de personas en el menor tiempo posible, así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y de saber cuándo hemos llegado a la definición correcta del sistema. Invite a varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que una de ellas sea la adecuada aumenta.

Por eso, la siguiente ocasión que inicie un proyecto de software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien más puede tomar decisiones cuando usted no está?

¡Las posibilidades son infinitas!

jueves, diciembre 06, 2012

El extraño caso del caso de uso faltante

O de cómo nunca deberíamos aceptar especificaciones de software incompletas

Los productos de software de alta calidad dependen de la completitud de los requisitos. En general, la calidad de los requisitos de software afecta la calidad de los productos de software. Los Ingenieros de Requisitos o Analistas Funcionales intentamos llenar los vacíos en la especificación del software de manera distinta, dependiendo de nuestra experiencia y del proyecto en el que se encuentren, de factores como el tiempo, la relación con el usuario, la disponibilidad de este o del grado de estabilidad de los requisitos existentes.

Algunos Analistas, por ejemplo, intentamos obtener retroalimentación de los usuarios, mientras que otros acuden a distintos interesados o a fuentes alternas de los requisitos, pero cuando no tenemos ese privilegio, simplemente hacemos suposiciones. Estas últimas pueden ser implícitas o explícitas. Las suposiciones explícitas son preferibles a las implícitas porque podemos validar aquellas posteriormente, mientras que las implícitas llegan a las fases de diseño e implementación con una alta probabilidad de estar erradas.
Ya sabemos que los requisitos de software deben ser: correctos, precisos, completos, consistentes, clasificados, verificables, modificables y trazables. Las especificaciones de requisitos completas y correctas son las requeridas por los desarrolladores para saber qué construir y por los usuarios para saber qué esperar. Una especificación de requisitos de software completa debe incluir toda la información necesaria, incluyendo restricciones y condiciones.
Ahora bien, independientemente de las técnicas de recolección de requisitos, el involucramiento del usuario es un elemento importante, ya que los requisitos vienen principalmente de las personas, no de los documentos o los sistemas existentes. Los usuarios deben ser escuchados cuidadosamente y nunca debemos hacer suposiciones implícitas puesto que estas no se comparten con los interesados aumentando así la incertidumbre en los requisitos. 
De mi propia experiencia, de la de mis colegas, y de estudios en la materia, he llegado a la conclusión de que, nosotros, los Ingenieros de Requisitos, tendemos a ser más rigurosos en la especificación de requisitos cuando:

  • El cliente es de corte militar, es decir, es un cliente rígido, con un proceso formal bien definido o es vigilado por entidades internas o externas a su organización y a las que debe rendir cuentas sobre sus acciones.
  • El análisis de requisitos hace parte de la fase actual del ciclo de vida del software, por ejemplo, cuando estamos en las fases de Inicio (UP) o Visión (MSF) y en la fase de Elaboración (UP) o Planeación (MSF). Por razones obvias, a medida que el proyecto avanza, tenemos menos tiempo para encontrar y documentar requisitos y es cuando más suposiciones se hacen sobre lo que ya está identificado.
  • Utilizamos herramientas de apoyo para la especificación y el modelado de requisitos, sobre todo herramientas que permitan realizar diagramas de casos de uso, diagramas de actividad, tableros de historias, simulaciones y prototipos, entre otros instrumentos de este tipo.
  • Hemos asistido a entrenamiento en los días previos al proyecto o hemos estado involucrados en proyectos problemáticos recientemente. Cuando esto ocurre, muy seguramente hemos estado sometidos a mucha presión y estrés, además de una limpieza de cerebro sin antecedentes y no queremos volver a equivocarnos.
  • Simplemente tenemos la experiencia suficiente y necesaria, hemos aprendido de nuestros aciertos y fallas del pasado y de las lecciones aprendidas en proyectos anteriores. Sin contar con que hemos consultado la gran cantidad de material que encontramos en este Gazafatonario IT sobre el tema.
Si algunas de o todas estas premisas no se cumplen, es muy probable que no sepamos cómo enfrentar los principales problemas en ese proceso espinoso que es la identificación de requisitos. Estos problemas se manifiestan de forma distinta:
  • Los usuarios no pueden o no saben describir muchas de sus tareas
  • Mucha información importante no llega a verbalizarse. Ocurre con frecuencia que de tanto ejecutar el proceso, este “desaparece”, se vuelve algo implícito y nadie es capaz de relatarlo.
  • En sistemas orientados a miles de usuarios, como los sistemas de la Web 2.0, a veces hay que “inventar” los requisitos. En estos casos, las suposiciones están a la orden del día y muchas de ellas nunca llegan a documentarse.
  • En general, la educción (extracción) de requisitos es un proceso pasivo, en el que el usuario espera del Analista Funcional la solicitud de conocer algo para él intentar entonces explicárselo de alguna manera.
Sobre este último síntoma, todo el proceso de identificación, clasificación, documentación y administración de requisitos de software debería ser un proceso cooperativo, que cuente con la participación del equipo técnico y de todos los interesados en el proyecto y en el producto y no solo de algunos pocos usuarios.

Finalmente, algunas técnicas bien conocidas y que son de utilidad al momento de encontrar requisitos y de las que hablaremos en otros artículos, son:
Preliminares:

Utilizar preguntas libres de contexto.

Tormenta de ideas:

Seleccionar un grupo variado de participantes.

Eliminar críticas, juicios y evaluaciones mientras los participantes sugieren ideas.

Producir muchas ideas.

Recogerlas todas por escrito.

Otro día, en otra sesión, se evalúan las ideas (se puntúan).

Elaboración de prototipos:

Útil cuando la incertidumbre es grande acerca del futuro sistema

Entrevistas:

Es el método “tradicional”,  pero debe usarse en complemento con otras técnicas, y no debe ser el primer paso de la educción. Es fundamental:

Entrevistar a la(s) persona(s) adecuadas.

Preparar las preguntas con antelación.

Utilizar diagramas, modelos, etc.

Observación y análisis de tareas:

Esta es una técnica tan antiquísima como la misma Ingeniería de Software. Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos.

Casos de uso

Requisitos en contexto de uso. Sobre este asunto he expuesto docenas de artículos en este Blog.

Finalmente, recordemos que el objetivo de la Ingeniería de Requisitos es asegurar que se defina y desarrolle un producto efectivo de alta calidad desde el punto de vista de los interesados, así que si una especificación de requisitos de software incompleta es inevitable, definitivamente deberíamos aceptarla como completa haciendo suposiciones implícitas.

jueves, octubre 11, 2012

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
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.
[11]Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 21 Feb. 2000
[17]Real Academia de la Lengua Española. RAE. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=abuso

martes, octubre 02, 2012

Casos de Abuso, Parte 11: Cada caso de uso se diseña e implementa de manera independiente


El diseñador y el desarrollador sólo ven el caso de uso en desarrollo sin importarles el sistema como un todo.  Cuando esto se hace así, y no por paquetes relacionados, corremos el riesgo de no armar el “rompecabezas” con facilidad al final de la operación.
Y lo que es peor, muchas veces durante el diseño e implementación del caso de uso no tenemos en cuenta los lineamientos arquitectónicos impuestos a la solución. El producto termina siendo una colcha de retazos mal cosidos. Esta situación convierte los hitos de integración del producto, iteración tras iteración, fase tras fase, en un serio dolor de cabeza para el arquitecto, los diseñadores y los mismos programadores. Entonces surgen los reprocesos, el desperdicio de código, rediseños, y el resultado final: un producto de mala calidad.
El tratamiento: la arquitectura del software. Una que sirva como una gran lista de chequeo para los diseñadores y para los implementadores del producto. La arquitectura de software es la organización fundamental de un sistema, formado por sus componentes, las relaciones entre ellos mismos y con el entorno, y los principios que gobiernan su diseño y evolución (IEEE 1471-2000). Según Booch, Kruchten y otros, la Arquitectura de Software incluye decisiones acerca de la organización de un sistema de software como:
·         La selección de los elementos estructurales que componen el sistema y sus interfaces
·         El comportamiento del sistema, especificado en las colaboraciones entre esos elementos
·         La composición de estos elementos estructurales y comportacionales en subsistemas más grandes
·         El estilo arquitectónico que guía esta organización
Toda arquitectura de software comienza por una arquitectura funcional o vista de casos de uso, un subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los así llamados casos de uso o requisitos arquitectónicos. Después están la vista lógica, que le habla a los analistas y diseñadores sobre la estructura del software. La vista de implementación, que les cuenta a los programadores detalles sobre el manejo del software. Por su parte, la vista de procesos habla de desempeño, escalabilidad y puesta en marcha a los integradores del sistema. Y también está la vista de despliegue que nos explica de manera lacónica la topología del sistema, aspectos de la entrega del mismo, de instalación y de comunicación subyacentes.
El diseño y la implementación de todo el producto de software debe obedecer a estas restricciones, casi leyes, impuestas por la arquitectura así descrita. Es lo que hace posible que los casos de uso se diseñen en grupos heterogéneos de paquetes o subsistemas diferentes.
Impacto en la calidad: Alto.

PD. Para saber sobre Arquitectura de Software, específicamente sobre el modelo de las 4 + 1 vistas expuesto por Krutchen, pueden tener en cuenta la siguiente referencia:
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
También la encuentran en:
Además, sobre análisis y diseño de casos de uso, en particular, sobre realización de casos de uso, pueden visitar mi Lectura Fundamental 10:
Y sobre programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

domingo, septiembre 30, 2012

Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo


Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.
El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.
Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.
Veamos con un caso de uso algo escueto un ejemplo típico:
Caso de uso: Retirar fondos
Actor: Cliente
Secuencia Básica:
1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático
2.    El sistema solicita la cantidad de dinero a retirar
3.    El Cliente ingresa la cantidad de dinero a retirar
4.    El sistema verifica el saldo del Cliente
5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”
6.    El caso de uso termina
Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:
4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.
5.    El caso de uso termina
Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.
Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

miércoles, septiembre 26, 2012

Casos de Abuso, Parte 9: Todos los requisitos funcionales se documentan en casos de uso


El que un proceso sea dirigido por casos de uso no quiere decir que toda la funcionalidad del software debe estar documentada en casos de uso. Hay requisitos que son transversales al producto, es decir, aplican en varias partes del sistema; también hay requisitos funcionales que se expresan mejor en prosa, siempre en términos del usuario, pero en narrativa; hay otras funcionalidades cuya complejidad amerita el uso de diagramas de actividad o de otro tipo de elementos gráficos o visuales para entenderse. En este último caso, siempre recomiendo el uso formal de UML como mecanismo de comunicación para no dar pie a malos entendidos o a concentración de ambigüedades.
Ya lo he expresado antes, los casos de uso apenas son uno de los mecanismos para identificar, organizar, documentar y administrar requisitos o, en el orden de ideas que estoy formulando, un receptáculo de requisitos, un depósito, un bote, una funda, un artilugio. De hecho, los casos de uso constituyen la práctica industrial más ampliamente usada en materia de requisitos de sistemas de información.
Lo digo de esta manera porque he notado que es muy fácil para las personas extraviar la noción y la práctica correcta de la Ingeniería de Requisitos y volverse “caso-de-uso-dependientes” y en ocasiones crean una especie de religión donde el acto de fe por los casos de uso toma tintes de devoción.
Como cualquier adicción, esta también va a ser difícil de desarraigar de nuestros modelos mentales. Sin embargo, vamos a intentarlo. Pero antes de eso, quiero reiterarles que soy entusiasta de los casos de uso, quienes han seguido mi Gazafatonario IT conocen las Lecturas Fundamentales, un esfuerzo medio modesto medio imponente por transmitir mi experiencia en el tema y que fueron la base de mi próximo libro, actualmente en etapa de edición.
En los últimos meses también he estado publicando sobre casos de uso 2.0, una estrategia que reúne las mejores prácticas tradicionales y ágiles para la documentación de requisitos de software, expuesta recientemente por el Dr. Ivar Jacobson y su equipo. Sobre este tema volveremos más adelante, cuando hayamos entendido, o hayamos vuelto a entender, el verdadero sentido del uso y el abuso de los casos de uso.
Este ha sido el principal objetivo de esta serie así llamada “Casos de Abuso”. En el capítulo 4 de la misma expongo las distintas formas y colores que pueden tomar los requisitos del software:
Impacto en la calidad: Bajo.
PD. Para saber más de ingeniería de requisitos, análisis de requisitos y el papel del Analista de Requisitos y de otros aspectos relacionados, pueden leer mi Lectura Fundamental 9:RUP: Fase de Concepción, Parte 2”, en mi Gazafatonario IT:

martes, septiembre 25, 2012

Casos de Abuso, Parte 8: Precondiciones vs. Validaciones y Poscondiciones vs. Resultados


A este caso de abuso originalmente lo titulé:
Las precondiciones son validaciones que hace el caso de uso al comienzo del mismo o en algún paso siguiente. Las poscondiciones y el resultado del caso de uso son una misma cosa.
Este es quizás el mayor de los abusos. Las precondiciones no ocurren dentro del caso de uso, es justamente lo contrario. Las precondiciones representan el estado en el que debe estar el sistema para que se ejecute el caso de uso a la que pertenecen. Son acciones que ocurren antes, en algún momento del tiempo, de la ejecución (o de la necesidad de ejecución) del caso de uso. Y cuando digo “en algún momento del tiempo” no me refiero a que tiene que ser inmediatamente antes del caso de uso, puede ser en cualquier instante, mientras sea antes de la ejecución del caso de uso. Para usar términos bastante reconocidos por nosotros, si un caso de uso tiene precondiciones, se encuentra deshabilitado hasta tanto todas las precondiciones no se hayan ejecutado y hayan producido los resultados necesarios para que el caso de uso se habilite y pueda ejecutarse.
Figura 2: Representación Visual de las Precondiciones y las poscondiciones de un caso de uso. Fuente: Adaptado de IBM Rational Unified Process
El error más común ocurre cuando confundimos una precondición con la validación a un elemento específico del negocio, por ejemplo, que el Cliente debe tener una cuenta corriente para solicitar aumento de cupo de sobregiro. Esta, a todas luces, es una verificación que debe ocurrir en el caso de uso “solicitar aumento de cupo de sobregiro” después de que el cliente se haya identificado, antes no es posible.
Un análisis similar puede hacerse para las poscondiciones, confundidas casi siempre con los resultados del caso de uso. Por ejemplo, es frecuente leer en la especificación de un caso de uso: “el sistema almacena los datos de la solicitud.”, “el sistema muestra el mensaje ‘no se pudo realizar la operación’.”, “el sistema cancela la ejecución del proceso.” Todas estos detalles corresponden a eventos que ocurren (deben ocurrir) dentro del caso de uso, no después de su ejecución, que es el terreno donde se mueven las poscondiciones.
Una poscondición típica puede ser: “el cliente puede consultar el estado de sus facturas.” Otra puede ser: “la cuenta del usuario queda deshabilitada.” Una más: “el cliente VIP puede modificar el estado de su reserva.” Todas estas son acciones que los usuarios pueden hacer después de que un determinado caso de uso se haya ejecutado, satisfactoriamente o no. El momento en el que se haga tampoco tiene que ser inmediatamente después, casi siempre depende de las necesidades de los usuarios particulares de cada funcionalidad.
Una situación adicional que ocurre en muchas oportunidades es que nos quedamos buscando precondiciones y poscondiciones del caso de uso durante un tiempo considerablemente extenso. Siempre recomiendo a los neófitos que si no las encuentran en las primeras de cambio pueden estar sucediendo dos cosas importantes:
  • No tenemos información suficiente del caso de uso (o no lo hemos entendido bien)

O
  • No tenemos la experiencia práctica o el conocimiento teórico suficiente para lidiar con estos dos aspectos de los casos de uso.

En el primer caso, debemos siempre buscar la información que nos hace falta con las personas involucradas, los usuarios; en el segundo caso es un poco más difícil, pero mientras este tema se nos vuelve una costumbre, recomiendo no quedarnos mucho tiempo paralizados por ello y seguir adelante. Las precondiciones y las poscondiciones son aspecto importantes para el diseño y la implementación del caso de uso, pero si no las encontramos, existen otras formas de llegar a la misma solución, quizás tome un poco más de tiempo a los diseñadores, pero este será mucho menos que si los analistas se quedan horas o días buscando algo que no conocen.
Otra cosa más, tanto las precondiciones como las poscondiciones son opcionales: no siempre son un elemento adherido al caso de uso. Es posible que haya casos de uso que no tengan unas o las otras, o ambas.
Impacto en la calidad: Alto.
PD. Para saber más de precondiciones y poscondiciones y de otras características de los casos de uso pueden leer mi Lectura Fundamental 3: “Casos de Uso: del todo y de sus partes”, en mi Gazafatonario IT: