Cómo un evaluador trata la trazabilidad de los requisitos

El vínculo entre la calidad y los requisitos

La calidad es el centro de masas y el pilar de cualquier industria, y uno de los elementos claves para atraer y retener al cliente. En la industria del software, la calidad se define en términos de la usabilidad y la realización que se establecen mediante los requisitos que se derivan de las expectativas del cliente. Finalmente, la calidad mide la diferencia que existe entre los requisitos realmente desarrollados y los que se espera desarrollar.

Si la calidad estará definida por la exactitud de los requisitos, entonces la eficacia se definirá en términos de proceso, producto, costo y repetición del trabajo. El costo que implica encontrar un defecto en una etapa posterior del ciclo de desarrollo de sistemas (SDLC) es muy alto comparado con la detección temprana. Asimismo, el costo del defecto es doble, como lo indica William E. Perry en su libro Effective Methods for Software Testing (Second Edition): “El primero por identificarlo y el segundo por corregirlo”. Esto quiere decir que una vez que el defecto se hace presente en otras etapas del SDLC, se vuelve mucho más costoso rastrearlo e identificarlo, así como determinar en qué etapa se inició. Una vez que se ha detectado el defecto, el otro aspecto del costo es la cantidad de horas de mano de obra necesarias para corregirlo y asegurarse de que no se modifica o se pierde algún requisito correcto.

En este artículo examinaremos la forma para garantizar la integridad de los requisitos mediante la trazabilidad, y la forma en que ésta se aplica al SDLC.

La trazabilidad de los requisitos como medio para controlar la variabilidad

La variabilidad siempre ha sido un enemigo de la calidad. Cuando viola los límites predefinidos provoca que el sistema se comporte de manera descontrolada. Por otro lado, los procesos controlados presentan una estabilidad que permite predecir los resultados. Así, si se controla la variabilidad desde la etapa inicial es posible reducir al mínimo el riesgo de alejarse de los requisitos reales.

La mejor forma para medir la variabilidad es mediante métodos estadísticos. Es más, el control de la variabilidad en los procesos es una actividad constante. Las mejores medidas para controlar la variabilidad son (1) identificar los procesos, (2) identificar los atributos de los procesos que se pueden medir y (3) dar seguimiento a la variación que sufren los procesos (mediante tablas de control). Cuando el proceso está bajo control, es necesario seguir sondeando la situación (es decir, revisar el proceso en intervalos regulares). Sin embargo, si el proceso no está bajo control, puede ser necesario seguir los pasos siguientes:

• Identificar la causa (usando análisis de la causa raíz, diagramas de fases o diagramas de dispersión)
• Eliminar la causa raíz (usando análisis de Pareto, tormenta de ideas o diagramas Ishikawa)
• Mantener el seguimiento de las variaciones en los procesos

La matriz de trazabilidad de los requisitos (RTM) es de gran ayuda para revisar cada uno de los requisitos y supervisar si alguno de ellos se ha incorporado al producto. La RTM es una matriz que sirve para asegurarse de que no se pierde o altera alguno de los requisitos, y que estos se desarrollan de acuerdo a la funcionalidad requerida. Esta matriz también garantiza que los requisitos del usuario se convierten y mapean a los requisitos funcionales correctos, y que se entrega lo que desea el cliente.

Por otro lado, la RTM tiene muchas ventajas desde el punto de vista de mantenimiento o mejoras. Si es necesario hacer cambios al producto, entonces es posible rastrear y modificar el requisito específico que debe cambiar. Esto facilita el enfoque en el mapeo hacia adelante y hacia atrás entre los requisitos (consulte la figura 1). Los requisitos tienden a cambiar con el tiempo, por ello, mantener la RTM ayuda a rastrear los requisitos y modificarlos como sea necesario. Asimismo, la RTM garantiza que al cambiar un requisito en particular no se dañarán los demás. Ayuda a evitar la repetición de los mismos. Si los requisitos son redundantes -cuando están “escondidos” detrás de otros requisitos- existe el riesgo de ocultar la función que debe desarrollarse. Por ello, es muy importante excluir estos requisitos repetitivos para ahorrar tanto tiempo como dinero.

Figura 1. Trazabilidad de los requisitos: trazabilidad hacia adelante y trazabilidad hacia atrás.

En uno de los proyectos críticos en que participe, específicamente para un sistema de compras electrónicas, se determinó que los requisitos reunidos eran correctos después de realizar un análisis completo de alto nivel y un borrador final de casos de uso en el nivel de base. Sin embargo, conforme los requisitos iban avanzando en las etapas del SDLC, nos fuimos dando cuenta de que estaban corrompidos.

El cliente necesitaba un carrito de compras electrónicas que tuviera todas las funcionalidades básicas: registrar el usuario, agregar y eliminar artículos del carrito y efectuar el pago. Sin embargo, a medida que pasábamos de las situaciones de alto nivel a las de bajo nivel (dicho de otro modo, desde los requisitos a cada una de las funciones y variables usadas para realizar este requisito), perdíamos algunos requisitos que debían formar parte de la funcionalidad.

Por ejemplo, al tratarse de la función “agregar y eliminar artículos del carrito”, los desarrolladores olvidaron implementar el requisito que necesitaba el usuario para que al volverse a registrar pudiera encontrar los artículos que había agregado a su carrito de compras durante la interacción anterior. Este es sólo un ejemplo de cómo se pueden perder los requisitos al pasar la información de un nivel alto a un nivel de base. Lo que los desarrolladores habían hecho era bueno y funcional, pero seguía faltando uno de los requisitos necesarios para satisfacer las necesidades del cliente. Nos dimos cuenta de ello durante la etapa de evaluaciones, al mapear los requisitos y la funcionalidad. Entonces llevamos a cabo una trazabilidad hacia atrás para identificar el eslabón roto. Con ello pudimos convertir los requisitos correctos en la funcionalidad deseada.

No sólo hay que utilizar la trazabilidad de los requisitos, sino que hay que administrarlos. Si no se mantiene RTM alguna, teóricamente es posible que el requisito se corroa en la etapa de evaluación, lo que haría que el sitio inicie su funcionamiento en vivo sin contar con la funcionalidad pertinente. Imagínese cuántas pérdidas podría ocasionarle al cliente la falta de un requisito.

La rueda del SDLC

Los requisitos tienen un papel muy importante en todo el SDLC, ya que juntos forman un enunciado de lo que el producto debe ser capaz de hacer. La funcionalidad principal se determina de acuerdo a la información reunida durante la obtención de requisitos del cliente.

Figura 2: La rueda de SDLC.

Los requisitos que entran en el SDLC son los de los usuarios, que se mapean a los requisitos tanto funcionales como no funcionales. Muchas veces se convierten en diseño y avanzan así en la rueda. Posteriormente, los requisitos pasan a la etapa de desarrollo y después a la etapa de evaluación. El cliente recibe los requisitos del usuario que se han moldeado para formar el producto final (consulte la figura 2).

Es necesario mantener la RTM en toda la rueda para asegurarse de que no se rompe con los requisitos. Los requisitos del usuario cambian para convertirse en requisitos funcionales (y viceversa) desde la etapa de reunión y congelación hasta la etapa de entrega final (producción). Este proceso ayuda a rastrear, a través de todas las etapas, cada uno de los requisitos que son importantes para el cliente y evitar la pérdida de información. En la aplicación en compras electrónicas que mencionamos, la falta de un eslabón se debía a archivos cuyos nombres se habían duplicado y que se estaban usando para sustituir los archivos divididos en la ubicación de destino. No se puso atención alguna a este requisito (que estaba implícito); también tenía que haber sido manejado, pero por alguna razón se había perdido en el proceso.

Ejemplo práctico

Hace algún tiempo trabajé para una empresa (de servicios), donde participé en proyectos a corto y largo plazo. Uno de los proyectos pequeños involucraba un seleccionador y divisor de archivos, que seleccionaba periódicamente los archivos que tenían las extensiones específicas que se habían predefinido, y los dividía en partes en una ubicación predefinida también. Ahora, el requisito funcional era dividir estos archivos y mantenerlos en una ruta específica que tenía una convención de denominación particular: TargetFilename[n].ext.

La figura 3 contiene un mapa de las funciones y los requisitos del usuario.

Figura 3: Relación uno a uno entre los requisitos mapeados del usuario y los requisitos funcionales.

Este proceso de mapeo también evitará que los requisitos irrelevantes y dañinos penetren en el sistema sigilosamente. La conversión y el mapeo de los requisitos del usuario a las funciones (trazabilidad hacia adelante), y también de las funciones a los requisitos del usuario (trazabilidad hacia atrás), subraya la importancia de la RTM en el flujo del proceso. Además, este proceso ilustra con claridad la viabilidad de los requisitos del usuario y lo que se desarrollará como funciones. Asimismo da una idea de los requisitos que no se cubren.

La conversión y el mapeo determinan la trazabilidad y el desarrollo de los requisitos correctos durante el SDLC. La RTM se mantiene en el SDLC desde la etapa de congelación de los requisitos. En esta etapa se reúnen los requisitos y se analiza su viabilidad. Entonces el cliente autoriza su paso a la siguiente etapa mediante un documento de autorización que se usa en la etapa de desarrollo, donde estos requisitos se codifican para convertirlos en funcionalidad. Este sistema desarrollado llega a la etapa de evaluación, donde una vez más se revisan estos requisitos (evaluados contra lo que se ha desarrollado) y se asegura que cada uno de ellos se haya desarrollado correctamente. Finalmente, se entregan al cliente para que lleve a cabo las evaluaciones finales y los apruebe.

Quiero tratar un poco más a fondo el ejemplo del divisor de archivos que presentamos antes. En la etapa de congelación, el requisito de negocios que se había obtenido del cliente era un divisor que seleccionaba archivos y los dividía en partes. Ahora, como este requisito se congeló después de que el cliente lo autorizó, pasó a la etapa siguiente del SDLC: la etapa de desarrollo. Aquí se dividieron estos requisitos de nivel alto en situaciones de nivel bajo. Los requisitos nos llevaban específicamente a los pasos siguientes: (1) seleccionar ciertos archivos, (2) dividirlos en formatos específicos y (3) mantenerlos en la ruta especificada. Después de codificar estas funciones, pasaron a la etapa de evaluación -una evaluación del subsistema (que puede llevar a cabo un grupo de desarrolladores o un grupo de evaluación independiente) y posteriormente a una etapa de evaluación por el sistema (un grupo de evaluación) que se asegurara de su flujo. Finalmente, el sistema pasó a la prueba de aceptación de usuario (UAT) -la aceptación final por parte del cliente y su aprobación para fabricar el producto desarrollado.

Como dijimos antes, el grupo de evaluación es responsable de mantener la integridad de la RTM en todo el SDLC. Además, el grupo de evaluación debe garantizar la integridad de los requisitos al terminar cada etapa del SDLC, y debe evitar que los requisitos innecesarios penetren en el sistema sigilosamente. Los requisitos innecesarios son aquellos que penetran en el sistema cuando no se ha definido la forma en que se espera que se comporte un objeto. Por ejemplo, si usamos el ejemplo anterior, los archivos que se seleccionaron y dividieron se borraron también de la ruta objetivo, y eso no era exactamente lo que debía hacer el sistema. Por lo tanto, esos requisitos penetraron el el sistema y pasaron inadvertidos hasta que el cliente los detectó. Así, el hecho de mantener la trazabilidad de los requisitos en cada etapa ayuda a retroceder en caso de que se registre una divergencia en los requisitos.

Conclusión

En la prueba de evaluación, la trazabilidad da una imagen clara que sirve para validar el requisito de negocios y la función que se desarrollaron. Desde el punto de vista del evaluador, es muy importante responder a las preguntas siguientes:

• ¿Qué se evalúa o contra qué se valida?
• ¿Cómo se evalúa?
• ¿El diseño de la evaluación garantiza la cobertura de los requisitos?
• ¿Las revisiones resultan provechosas desde el punto de vista de las evaluaciones y el desarrollo?
• ¿Qué técnicas se han incorporado en las evaluaciones?
• ¿Se cubren las regresiones?

Si un evaluador es capaz de responder a estas preguntas, quiere decir que el producto satisface las medidas de calidad desde el punto de vista del cliente, y por lo tanto, se puede usar. Además, cuando se trata de mantenimiento o mejoras, la trazabilidad hacia atrás resulta de gran utilidad, ya que se asegura de que no se ha dañado la funcionalidad actual y que sólo se ha modificado el requisito correcto.

Desde el punto de vista del costo, como dijimos antes, los defectos que se detectan en las etapas posteriores del SDLC resultan costosos. Por eso es vital detectarlos al principio del SDLC. Esto elimina la diferencia entre los requisitos que especifica el cliente y el producto que se entrega en realidad. A su vez, esto genera tasas de variabilidad bajas y mantiene la uniformidad en el proceso y el producto, logrando reducir dramáticamente los defectos en la etapa de evaluación.

Acerca de la autora

Neha Grover cuenta con más de dos años de experiencia como ingeniero de pruebas y experta en la materia, y tiene un amplio conocimiento de la evaluación de software y el análisis de requisitos. Ha trabajado como ingeniero de pruebas en BMC Software, donde estuvo involucrada en las áreas de rastreo de requisitos, pruebas funcionales y pruebas de desempeño. Actualmente es la experta en materia de pruebas en Amdocs y participa en las evaluaciones del sistema. Tiene una maestría en tecnología de la información de la universidad Veer Narmad South Gujarat de Surat, India. También tiene la certificación de evaluadora de software del Instituto de Aseguramiento de la Calidad (QAI), CSTE.