Evolucionando los paradigmas del desarrollo de software

Los sistemas de información son de gran importancia para el soporte de los procesos de una organización. El disponer de un sistema que ayude a mejorar su desempeño, reducir errores, automatizar tareas y que además, proporcione en tiempo y forma la información necesaria para la correcta toma de decisiones, se convierte en una estrategia útil para que las organizaciones hagan frente a sus diversos competidores.

Para desarrollar un sistema, se requiere llevar a cabo el análisis de los requisitos (que corresponde a la primera etapa del proceso de desarrollo de software), para definir las actividades que se desempeñan dentro de la organización y obtener las funcionalidades de software que el sistema debe cubrir. El análisis de requisitos es probablemente la etapa más importante del proceso de desarrollo, puesto que de las decisiones tomadas en esta etapa dependerán las funcionalidades que el sistema a desarrollar deberá cumplir o no. Una correcta definición de los requisitos permite que el sistema llegue finalmente a ser exitoso desde los puntos de vista de los objetivos de la organización, costos, funcionalidad, sencillez y capacidad de soporte.

Problemáticas relacionadas.

El análisis de requisitos se puede llevar a cabo mediante técnicas tradicionales como entrevistas, talleres, prototipos etc. Sin embargo, existen un sin número de dificultades que se pueden presentar en este proceso ocasionando que a pesar de los esfuerzos realizados por los analistas un alto porcentaje de los sistemas no llegan a cubrir al 100% las necesidades de la organización. En primera instancia se requiere de la habilidad de los analistas para especificar correctamente los requisitos de un sistema, puesto que las metas de la organización pueden no ser explícitas, difíciles de comprender y presentar contradicciones o ambigüedades. Asimismo, el analista tiene la tarea de involucrar en el análisis a todas las partes interesadas (la organización en sí, directivos y usuarios finales por ejemplo) y sus necesidades para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. De manera general, la baja eficiencia del sistema final es causado ya sea por no llevar a cabo el análisis de requisitos adecuadamente, o porque las técnicas tradicionales no permiten profundizar lo suficiente para determinar las funcionalidades que el sistema debe cubrir.

Partiendo en dos

Grupos de investigación en el área de la ingeniería de software han propuesto dividir la etapa de análisis de requisitos en dos sub etapas: la etapa de requisitos tempranos (requisitos relacionados con la organización) y la etapa de requisitos tardíos (requisitos relacionados con el sistema). La etapa de requisitos tardíos tiene el objetivo de producir el documento de especificación de requisitos que se entrega a los desarrolladores para que el sistema entre en producción. Por otro lado, la etapa de requisitos tempranos tiene como objetivo entender el contexto organizacional (entendimiento profundo de la organización) y fundamentar los ¿por qué? que conducen a los requisitos del sistema, antes que contar con una especificación detallada de lo que el sistema deberá hacer. Se basa en actividades que consideran ¿cómo el sistema a desarrollar podrá satisfacer las metas de la organización?, ¿por qué se necesita el sistema?, ¿qué alternativas existen?, ¿cuáles son las implicaciones de las alternativas para las partes interesadas? y ¿cómo pueden abordarse los intereses de las partes involucradas?. El estudio del contexto organizacional en el que se implantará el sistema ha sido reconocido como una parte fundamental de la ingeniería de requisitos debido a que se buscan mecanismos que permitan establecer la relación entre la funcionalidad esperada de un sistema de software y los procesos organizacionales a los que éste dará soporte.

Metodologías

Mediante la puesta en marcha de esta etapa, se reduce la brecha conceptual entre lo que el sistema debe hacer y por qué, y lo que los usuarios que interactúan con el sistema deben hacer y por qué, proporcionando así (en parte) la flexibilidad adicional necesaria para hacer frente a la complejidad de los sistemas de software actuales. El conocimiento obtenido de la etapa de análisis de requisitos tempranos puede ser representado mediante el uso de técnicas de modelo organizacional. El Framework i* [1] (i estrella) es una de las técnicas de modelado organizacional  mejor fundamentada y utilizada que hace uso de relaciones estratégicas para modelar el contexto social e intencional de una organización y proporciona un lenguaje que soporta la descripción de redes organizacionales formadas de actores sociales con libertad de acción, pero que también dependen de otros actores para alcanzar sus objetivos y metas. Además de técnicas de modelado, se han propuesto metodologías que ofrecen enfoques para relacionar los conceptos del dominio de la organización (modelos organizacionales) a los correspondientes conceptos del dominio de la solución (modelos conceptuales, como diagramas de clases de UML, ontologías) de manera que se mapeen correctamente las necesidades de la organización con las funcionalidades a cubrir por el sistema. Estas metodologías propician la unión del modelado organizacional con las especificaciones de software mejorando el proceso de desarrollo. Por ejemplo:

• Tropos [2] es una metodología para el desarrollo de sistemas orientados a agentes basada en i*. Se enfoca particularmente en el análisis del ambiente en el que operará el sistema a desarrollar, apoyándose en la idea de construir un modelo del ambiente organizacional y del sistema. La metodología guía la construcción de un modelo conceptual, mismo que es refinado y extendido durante las distintas etapas de desarrollo, desde la etapa de requisitos tempranos hasta la implementación.
• Conceptual Schemas Generation from Organizational Models in an Automatic Software Production Process [3] es una metodología para la construcción de modelos conceptuales (casos de uso y diagramas de clases UML) a partir de modelos organizacionales representados con Tropos. Presenta un proceso de desarrollo de software automático mediante el uso del OO-Method (un método de producción de software que genera automáticamente un sistema orientado a objetos completo a partir de modelos de casos de uso y diagramas de clases UML).
• TAGOOn [4] es una metodología basada en una herramienta de software que permite la transformación automática de modelos organizacionales en ontologías organizacionales mismas que pueden ser adaptadas a plataformas de desarrollo de software automático como SemanticWebBuilder [5], una plataforma para la generación automática de aplicaciones y portales web semánticos a partir de modelos ontológicos desarrollada en INFOTEC (Centro de Investigación en TICs del CONACYT).

En conclusión, el desarrollo de software ha pasado de ser una actividad solamente de los analistas de requisitos de sistemas a ser un trabajo en conjunto con los analistas organizacionales y los usuarios y operadores de los sistemas mismos.  Esta práctica se encuentra en aumento, gracias a las ventajas que ofrece en el ámbito de análisis de requisitos, como la generación de especificaciones coherentes y sin ambigüedades o contradicciones que reflejan las necesidades de la organización.

Referencias

[1] Eric S.-K. Yu, “Modelling strategic relationships for process reengineering,” Ph.D. dissertation, University of Toronto, Toronto, Ont., Canada, 1996.
[2] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopoulos, “Tropos: An agent oriented software development methodology,” Autonomous Agents and Multi-Agent Systems, vol. 8, no. 3, pp. 203–236, 2004.
[3] Alicia Martinez, “Conceptual Schemas Generation from Organizational Models in an Automatic Software Production Process” Ph.D. dissertation, Valencia University of Technology, Valencia, Spain, 2008.
[4] Karen Najera, Anna Perini, Alicia Martinez, Hugo Estrada. “Supporting i* model integration through an ontology-based approach”. In fifth international i* workshop (iStar’11), ser. LNCS, 2011, pp. 43–48. August, 2011.
[5] SemanticWebBuilder. http://www.semanticwebbuilder.org.mx