Buscar en Gazafatonario IT

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.