Proyecto financiado por la Xunta de Galicia (2004-2006)
(proyecto PGIDIT04PXIB32201PR)
El rápido desarrollo de la tecnología hardware, con microprocesadores cada vez más potentes y baratos y, en los últimos años, el vertiginoso crecimiento de la red Internet, ha dado lugar a una creciente complejidad de los sistemas de información y comunicaciones. La aplicación de metodologías de desarrollo tradicionales, eficaces para sistemas pequeños y de complejidad más reducida, ha dado lugar a numerosos problemas principalmente debidos a que muchos de los servicios y aplicaciones desarrollados no han llegado a tener el nivel de aceptación que se esperaba en un principio, al no satisfacer las expectativas de sus usuarios. La inadecuada metodología que se suele aplicar en la fase inicial de captura y análisis de requisitos es uno de los principales causantes de estas disfunciones. En el desarrollo de sistemas complejos, la dificultad para la obtención de una especificación de sus requisitos, al comienzo de su proceso de desarrollo, aumenta considerablemente ya que estos requisitos suelen evolucionar a lo largo del ciclo de vida por no disponerse inicialmente de un conocimiento detallado del sistema. El empleo de técnicas de desarrollo incremental permite construir modelos de ciclo de vida lo suficientemente flexibles como para poder incorporar los cambios, normalmente frecuentes en estas primeras fases. Por otra parte, existe un amplio consenso al considerar que, en el desarrollo de sistemas software grandes y complejos, se hace necesaria una mayor formalización de esta fase "como vehículo para detectar y eliminar inconsistencias e incompletitudes de la especificación de requisitos" y que la metodología empleada considere explícitamente la inevitable heterogeneidad de este tipo de sistemas, cuyo diseño exige la colaboración de diferentes grupos de trabajo (agentes), cada uno con su propia percepción (perspectiva) del sistema. La captura y análisis de requisitos en estos sistemas debe partir necesariamente de un conjunto de perspectivas (viewpoints) que, en general, contienen descripciones parciales del sistema y que pueden ser o no independientes: es posible que varias perspectivas describan una misma funcionalidad del sistema; pueden contener descripciones de partes del sistema a diferentes niveles de detalle; o, incluso, pueden contener visiones contradictorias o inconsistentes de algunas funcionalidades del sistema. Esta situación se deriva del hecho de que los agentes involucrados en este tipo de sistemas suelen ser muy diversos (gestores del sistema, usuarios finales, equipos de desarrollo, etc.) y con intereses distintos (algunas veces enfrentados).
Con estos antecedentes, parece necesario modificar la fase de captura y análisis de requisitos tradicional con el objeto de recoger y combinar todas las percepciones de estos agentes, obteniendo así una especificación formal de los requisitos del sistema consistente, no ambigua y completa que recoja todas sus expectativas. La división en diferentes perspectivas permite a cada uno de los agentes concentrarse en los aspectos del sistema que son de su interés, ignorando el resto que no son relevantes desde su punto de vista del sistema. Sin embargo, establecer y mantener la consistencia entre cada una de las diferentes perspectivas es una tarea compleja ya que éstas pueden desarrollarse en un nivel de abstracción diferente, pueden contener descripciones contradictorias y, además, mantener la consistencia entre un número elevado de perspectivas puede ser un problema computacionalmente costoso. La detección automática de inconsistencias exige disponer de especificaciones formales de las perspectivas, siendo ésta una tarea esencial para la obtención de sistemas software de calidad. Una vez detectadas las inconsistencias, es posible tomar dos alternativas: eliminarlas, lo que implica tomar decisiones relevantes en etapas iniciales del desarrollo del sistema con los consiguientes riesgos; o permitir que el sistema continúe su desarrollo hasta que el conocimiento sobre el sistema permita evaluar las alternativas disponibles y resolver las inconsistencias detectadas. La segunda solución supone la definición de nuevas metodologías de desarrollo que soporten inconsistencias, ya que en las metodologías tradicionales las inconsistencias son consideradas no-deseables y deben resolverse de manera inmediata para poder avanzar en el desarrollo del sistema.
Además, una metodología de este tipo debe complementarse con un mecanismo que automatice la generación de alternativas que permitan resolver las inconsistencias detectadas. Estas alternativas deberán generarse a medida que avanza el proceso de desarrollo, es decir, a medida que se obtiene el suficiente conocimiento para tomar decisiones. Por otra parte, la gran diversidad de alternativas que se pueden generar en un sistema software complejo aconseja el empleo de mecanismos de reutilización que permitan gestionar de manera eficiente y efectiva las diferentes alternativas.
Este proyecto propone la definición de una metodología formal, denominada ?-SCTL(T)/MUS(T), aplicable a sistemas complejos (incluyendo los de tiempo real) basada en un paradigma multi-perspectiva, que automatizará la detección, razonamiento y resolución de inconsistencias, permitiendo la toma de decisiones en el punto adecuado del proceso software. La complejidad de estas tareas justifica la incorporación de técnicas de reutilización para mejorar la eficiencia del proceso. La experiencia adquirida por el equipo solicitante en la definición de la metodología formal SCTL(T)/MUS(T), ha puesto de relieve la idoneidad de dicha metodología como punto de partida para la consecución de los objetivos planteados. Dicha idoneidad viene avalada por: (1) la naturaleza multivalorada de la lógica SCTL, que permite cuantificar en la especificación de requisitos el grado de acuerdo entre agentes y (2) la naturaleza incompleta del modelo de estados MUS, que permite especificaciones parciales del sistema reflejando las perspectivas de los diferentes agentes.