Análisis de requerimientos y trazabilidad en el modelo de objetos

Análisis de Requerimientos y
Trazabilidad en el Modelo de Objetos

Introducción

Las fases de captura y análisis de requisitos de usuario han recibido en general poca atención por parte de las metodologías de desarrollo de software. La transición a las fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la trazabilidad de los requisitos a lo largo de ésteproceso, son también aspectos poco soportados por éstas. El grupo de Integral Object, conjugando técnicas de modelización de dominios con otras habituales en orientación a objetos, ha desarrollado una serie de procedimientos sencillos y prácticos que permiten analizar y refinar requisitos de usuario, al mismo tiempo que sintetizar una especificación que enlaza directamente con los métodos deconstrucción de modelos de objetos, facilitando el seguimiento de los requisitos a lo largo del proceso.

Los Problemas del Análisis de Requisitos

El primer problema que se presenta es la captura de los requisitos del usuario. Para empezar, necesitamos recoger los requisitos de los usuarios o clientes de una manera sistemática y organizada. Para ello precisamos de unas directrices o líneas guía, yaque en general los usuarios expresan los requerimientos de la aplicación de forma muy variable, tanto en la forma como en el contenido. Nos interesa pues sistematizar la captura, con el fin de hacer los requisitos manejables y analizables.
Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin decomprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semiformal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, areas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes.Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el porqué.
Después de obtener una buena lista de requisitos, comenzaremos con el análisis y el diseño de la aplicación, y entonces nos surgen nuevos problemas: elprimero es la trazabilidad de los requisitos: cómo seguir un requisito de usuario por el análisis, el diseño y el código, que nos permita comprobar que el requisito ha sido tenido en cuenta y cómo lo ha sido. Y esto enlaza directamente con el problema de la mantenibilidad: cuando los requisitos comienzan a evolucionar -como sin duda lo harán-, cómo podemos ir evolucionando el diseño y el códigoconsistentemente con ello, y cómo seguir manteniendo la trazabilidad.

¿Cuál ha sido la posición de las Técnicas de Objetos?

La propuesta inicial de las metodologías de orientación a objetos es la que podríamos pensar: si con objetos podemos modelizar cualquier cosa, ¡construyamos un modelo de objetos de análisis! Eso nos simplificará el paso al diseño, ya que bastará con evolucionar el modelo, ynos mantendremos siempre en el mismo paradigma.
Sin embargo, esto tiene un problema: no hay una modelización automática o natural (por más que los objetos sean un estilo bastante natural de modelizar): modelizar implica siempre tomar decisiones, o sea, diseñar. Por eso, si construímos un modelo de objetos para analizar los requisitos y desarrollar una especificación, pueden ocurrir dos cosas: obien mantenemos este modelo en un nivel muy superficial para evitar tomar decisiones de diseño, o bien optamos por desarrollar un modelo completo y consistente.
Ante esta disyuntiva, la postura de buena parte de los expertos en Orientación a Objetos, ha sido quedarse en el primer nivel: construir un modelo somero de análisis, sin detallar excesivamente, y después meterse ya de lleno en el diseño....