ARQUITECTURA DEL SOFTWARE: CRITERIOS PARA UNA ARQUITECTURA AGIL Luis Freddy Muñoz Sanabria Estudiante de Doctorado en Ciencias de la Electrónica Universidad del Cauca, Popayán lfreddyms@fup.edu.co Alvaro Alvarez losano Director Programa de Ingeniería de Sistemas Fundación Universitaria de Popayán liyyov@hotmail.com LOGICIEL RESEARCH GROUP Resumen Las arquitecturas en el desarrollo de software están cobrando cada vez mayor importancia como atributo de calidad en el desarrollo de software, y ello ha motivado a que las metodologías para el desarrollo de software, busquen la integración de actividades y técnicas de arquitectura en sus procesos de desarrollo. En este trabajo, se presentan algunas arquitecturas planteadas para metodologías ágiles, se hace un ligero análisis de ellas; y se describe también cuales deben ser los criterios mínimos para una arquitectura que sin salirse de los esquemas de rigurosidad, cumpla con los requerimientos del manifiesto ágil. Palabras claves: Arquitecturas, Manifiesto ágil, iso/iec, integración. Abstract The architectures in software development are becoming increasingly important as an attribute of quality in software development, and this has led to methodologies for software development, seeking the integration of activities and architecture techniques in their process of development. In this work, we have raised some architectures for agile methodologies, is a brief analysis of them, and also describes which should be the minimum criteria for an architecture without departing from the rigorous schedules, meets the requirements of the agile manifest. Keywords: Architecture, Agile Manifesto, ISO / IEC, integration.
INTRODUCCION La arquitectura definida como la estructura o estructuras de un sistema, que contiene unos elementos software, unas propiedades visibles al exterior y sus relaciones. [1], o también como la descripción de los subsistemas y componentes de un sistema software y las relaciones entre estos. Los subsistemas son especificados desde diversas vistas para mostrar las propiedades funcionales y no funcionales. Es un artefacto, resultado de la actividad de diseño de software [2]. Es así como la arquitectura, ha toma gran importancia en el desarrollo de software. Debido a que es en la arquitectura donde se negocian los grandes sucesos del desarrollo, y donde se plantean las estrategias parta la obtención de un producto cada vez mejor. Todo debido a que el arquitecto (actor principal en la arquitectura), obtiene la información sobre el problema y diseña una solución que satisfaga los requisitos funcionales y no funcionales manteniendo la flexibilidad cuando los requisitos cambien, apoyado en patrones y modelos y frameworks. Por otro lado, la arquitectura, participa activamente en todas las fases del desarrollo y establece lineamientos generales que debe ser tenidos en cuenta durante todo el proyecto. Lo que le permite alcanzar estándares de calidad fundamentados en las características que se definen para ello (IEEE 1471) (ver figura 1) Figura 1 tomado de Grupo de Investigación de software EAFIT) Para las metodologías prescriptivas o tradicionales, la arquitectura de software bajo los esquemas presentados, fortaleció el desarrollo de soluciones software, implementó y solidificó la documentación necesaria para soportar cada fase del desarrollo y permitió alcanzar altos niveles de flexibilidad y mejoramiento tendientes a promover nuevas estrategias que surgen desde el planteamiento de la misma arquitectura. El asunto se torna de otro color por así decirlo, cuando queremos someter a las metodologías bajo estos esquemas arquitecturales, que por el tiempo de diseño, y la efectividad con que se pinta cada artefacto, hecha a perder muchos de los beneficios que pregona el manifiesto ágil. Por tanto, este trabajo, intenta proponer deben ser los criterios que han de tenerse en cuenta para trazar una arquitectura ágil, que soporte los principios de las metodologías de desarrollo modernas.
1. EL PROBLEMA Dentro de un marco de proceso software, cómo consolidar una arquitectura que cumpla con las condiciones y requisitos del manifiesto ágil, sin perder los criterios de calidad designados por estándares internacionales como la norma ISO/IEC 9126? Aunque esta propuesta trata muy bien las técnicas de especificación arquitectónico, no trata con profundidad las tareas de análisis de sistemas, las cuales son comunes al desarrollo de la interacción con el usuario importante dentro de las metodologías ágiles y al desarrollo de la parte interna del sistema. 2. TRABAJOS RELACIONADOS 2.1 CICLO DE VIDA EN ESTRELLA Propuesto por Hix y Hartson [3] un procesos de desarrollo centrado en el usuario, y que establecen su propuesta, basado en criterios de Interacción Humano computador (IPO). Este ciclo (Representado en la Figura 2), se fundamenta en la evaluación de cada actividad. Igual que las metodologías en cascada [4], no se puede cambiar de actividad hasta tanto no se haya evaluado completamente la anterior. Ello no prescribe cual es el orden o secuencia de cada actividad. Esto destaca el nivel altamente interactivo de la propuesta. Las restricciones son reducidas al mínimo y con el objeto de cumplir con los tiempos estimados por el manifiesto ágil, es posible empezar con el diseño así no se haya terminado de especificar los requisitos. Esta propuesta, da mucha importancia al desarrollo de las IU (Interfaces de usuario) proponen incluso unos esquemas que debe tenerse en cuenta para el diseño de estas interfaces. Figura 2(Tomado de Hix y Hartson 2003) 2.2 DISEÑO CENTRADO EN EL USO (USAGE-CENTERED DESIGN) Constantine y Lockwood [5] proponen una metodología, basada en una colección de actividades coordinadas que contribuyen a la arquitectura, agrupadas en el método de Diseño Centrado en el Uso. El usuario es importante en estas tareas y para ello, el modelo de actividades de diseño centradas en el uso incluye algunas actividades que corresponden al proceso de desarrollo más amplio: diseño de Objetos, Construcción Concéntrica e Iteración Arquitectural, junto con actividades de usabilidad
puras, como Modelado de Tareas o Modelado del Contenido de la Interfaz. Estos modelos propuestos son bastante atractivos, y aunque pretenden ser muy cercanos al requerimiento de los usuarios, se basan en criterios Orientados a Objetos (RUP), lo que hace que la propuesta se aleje de toda posibilidad de tiempos, factor importante para la entrega del producto al cliente, fundamento del manifiesto ágil. En concreto, la técnica de casos de uso esenciales, que son un pilar del enfoque centrado en el uso, es una reinterpretación de la técnica de casos de uso, la cual es muy popular en el desarrollo orientado a objetos. Los casos de uso esenciales pueden, por tanto, servir de puente para la integración de la arquitectura en el proceso de desarrollo. Por otro lado, Constantine y Lockwood ofrecen una serie de consejos, admitiendo que no hay una única forma de enfocar una integración sólida de la metodlogía con la arquitectura. Por tanto, dejan el tema de la integración para ser resuelto de forma particular en cada caso. Indican que "buenas estrategias de integración de la arquitectura en el ciclo de vida acomodan de forma conjunta las nuevas prácticas con las antiguas, modificando las practicas actuales para incorporar la arquitectura en los procesos de diseño y análisis, al tiempo que se particulariza el diseño centrado en el uso a la organización y sus prácticas" [5]. 2.3 ARQUITECTURA PARA METODOLOGIAS AGILES: ESTRATEGIA DE LARGO PLAZO INTERCALADAS CON TACTICAS DE CORTO PLAZO Ethan Hadar & Gabriel M Silberman Proponen una arquitectura llamada también CA o C3A, basada fundamentalmente en tres niveles, aunque deja la inquietud al diseñador por si su nivel de complejidad es bastante grande poder incluir otros niveles, Ella esta diseñada bajo artefactos de UML [6] y cada nivel presenta su funcionalidad en el sistema: NIVEL 0: MODULOS (ver figura 4) Considerado como el nivel mas importante, en donde además de especificar los requerimientos, se plantea una esta de seguimiento y otra de reportes (en diagrama de paquetes de UML) se hace a través de API, SPI y API para GUI, es a través de este nivel que se escriben los contratos o documentación de una página, como soporte y seguimiento al proyecto Figura 4 (Tomado de Agile Architecture Methodology: Long Term Strategy Interleaved) NIVEL 1: COMPONENTES (ver Figura 5) Proporciona la misma estructura de información que el nivel 0, pero es mucho mas detallado. En este nivel se
conecta a través del contrato con el nivel 0, para llevar mas en detalle los requisitos del sistema incluso se tienen en cuenta los parámetros, protocolos y mensajes, los canales de comunicación y los puertos que usará la aplicación [7]. Lo importante en este nivel es tener en cuenta "lo que hay que hacer", seguido por "Lo que se requiere para lograrlo."[8] NIVEL 2: TECNOLOGIA Y DISEÑO Es el nivel mas alto de abstracción, incluso esta propuesto como opcional. Este nivel se ocupa de las interfaces de un componente, basado en los patrones en los cuales se este soportando la aplicación. Cumple con la función interactiva, hasta completar el código del sistema. En muchas ocasiones este nivel toma importancia, cuando es necesario especificar los componentes del nivel uno. Que puede ser posible, debido a la complejidad del sistema que incluso deba diseñarse un nivel tres y así sucesivamente. Figura 5 (Tomado de Agile Architecture Methodology: Long Term Strategy Interleaved 2.4 Propuesta de Costabile Costabile [9] Ingeniero de Sistemas Profesora en Oxford, propone una integración de las prácticas ágiles centradas en el usuario en el proceso software. En concreto, propone una modificación del ciclo de vida software para incluir las actividades relacionadas con la arquitectura, y toma como base para dicha modificación el ciclo de vida en cascada, al que denomina ciclo de vida estándar. La modificación consiste en dejar solo dos actividades puras: análisis de usuarios y de tareas por un lado, y escenarios y especificaciones de las Interfaces de Usuarios por el otro, y otra actividad intermedia: prototipado y pruebas. La interactividad y flexibilidad que proponen los métodos ágiles permiten poder devolverse en cada etapa si es
necesario, y estas vueltas hacia atrás junto con la actividad de prototipado y pruebas, son presentadas por Costabile como la forma de enfatizar el carácter iterativo del desarrollo. Así justifica la autora la condición de interactividad necesaria en cualquier enfoque centrado en el usuario. De todas formas, en la propuesta se pueden considerar dos errores: Por un lado, considerar el ciclo de vida en cascada como ciclo de vida estándar, riñe contra los paradigmas propuestos por la Ingeniería del software y tratados por muchas de las metodologías conocidas. De otro lado, el enfoque de la cascada está prácticamente superado dentro de las metodologías ágiles, ya que si bien es cierto es muy aplicado a proyectos complejos, no es posible con este paradigma controlar los tiempos de entrega propuestos por el manifiesto ágil. Por ejemplo Glass indica que "los requisitos frecuentemente cambiaban a medida que el desarrollo avanzaba [...] Los expertos sabían que la cascada era un ideal inalcanzable" [10], y afirma que el ciclo de vida en cascada está obsoleto. Larman identifica los siguientes problemas con el ciclo de vida en cascada [11]: Mitigación tardía de los riesgos, especulación e inflexibilidad de los requisitos y el diseño, alta complejidad y baja adaptabilidad. Se puede afirmar que en el desarrollo de software en dominios no conocidos y para sistemas de complejidad media/alta, el equipo de desarrollo va avanzando en la comprensión del problema según se avanza en el diseño de la solución y en su adecuación a la realidad mediante la implementación. Por tanto, no es posible, bajo los criterios de cascada, proponer un trabajo de usabilidad, que se equipare con los designios de las metodologías ágiles, puesto que a pesar de que Cascada ofrece una interactividad disciplinada, con fuertes enlaces de documentación, no permite en el paso de sus actividades dentro del ciclo, un verdadero encuentro con el usuario y sus historias de requisitos. 3. EL MANIFIESTO AGIL Kent Beck, quien había publicado Extreme Programming Explained, libro en el que exponía una nueva metodología denominada Programación extrema, se reunió en Salt Lake City con un grupo de críticos de las exigencias de las metodologías clásicas, y para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término Métodos Ágiles para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales o clásicas, a las que las consideraban excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. (Ver figura 6) En dicha reunión se manifestó: Estamos poniendo al descubierto mejores métodos para desarrollar software, y ayudando a otros a que lo hagan. Con este trabajo se llegó a valorar:
A los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan. Las metodologías ágiles, son estrategias de desarrollo de software que promueven prácticas que son adaptativas en vez de predictivas, centradas en la gente o en los equipos, iterativas, orientadas hacia prestaciones y hacia la entrega, de comunicación intensiva, y que requieren que el cliente se involucre en forma directa. Las metodologías ágiles constituyen una solución a la medida, con una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto [12] Figura 6: Procesos ágiles Tomado de Metodologías Ágiles en el Desarrollo de Software Tanto la tecnología como el dominio cambian, y mientras más tiempo tome el desarrollo, más cambiarán. Por lo tanto, intentar conocer todos los requisitos del producto al comienzo del proyecto no es factible a un costo razonable. Aquí surge entonces también el interrogante Cómo entonces establecer criterios arquitectónicos frente a esta situación con el cliente?. De ahí que muchas metodologías y entre ellas las metodologías ágiles se centran en la especificación de requisitos, intentando extraer al máximo los deseos del usuario para entregar un producto lo mas cercano a la realidad. Pero estas (las metodologías ágiles) imponen un ciclo de vida que es mucho mas exigente con el objeto de poder cumplir con los tiempos propuestos por el manifiesto ágil (ver figura 7) Por tanto, para las metodologías ágiles, es importante comprender los requisitos del cliente para ejecutar un desarrollo de software exitoso. Pero el poder comprenderlo surgen inesperadamente los siguientes problemas: Los usuarios raramente tienen la habilidad para articular lo que realmente necesitan Las necesidades de los usuarios cambian cuando ellos ven el potencial del sistema y comprenden lo que el sistema puede hacer por ellos. Figura 7: Aproximación al ciclo de vida ágil Ello llevará por defecto, a pensar, que los requisitos de usuario son siempre crecientes respecto a los desarrollos de software, porque respecto al primer criterio del manifiesto ágil centrado en el usuario, por la ambigüedad con que se tratan los requisitos en muchas ocasiones, estos (los requisitos) actúan de una forma exponencial ver figura 8
Figura 8 Tomado de Agile Shift System Engineering. Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes. Mejora en la calidad del producto: el diseño centrado en el usuario resulta en productos de mayor calidad de uso, más competitivos en un mercado que demanda productos de fácil uso. Por ello los requisitos deben ser claramente especificados y entendidos es decir, que los requisitos son para el analista y el desarrollador, lo que el producto debe ser para el usuario, una proporción que se juega con el criterio de todos los participantes en el desarrollo de la aplicación. Aquí es entonces donde se debe reflexionar: como desde las metodologías ágiles se puede implantar una arquitectura que por un lado sea ágil también y por otro, tenga en cuenta que los requisitos funcionales del sistema no estén bien clarificados. De otro lado, cual sería el paradigma mas efectivo para integrar la arquitectura al desarrollo del software desde este nuevo esquema metodológico. Ahora es necesario aclarar que una buena arquitectura pensada y diseña da en términos de calidad de los productos software, necesariamente debe tener en cuenta esos criterios, basados en la norma ISO/IEC 9126 en la que hay ciertos atributos que son usualmente importantes: Lista de estos requisitos de calidad debiera ser parte de una plantilla para una especificación de requisitos, de este modo se simplifica el proceso de desarrollo, se disminuye el riesgo por no especificar cosas obvias, es fácil acordarse de qué preguntar a o negociar con el cliente, los nuevos empleados pueden aprender de cómo hacemos aquí las cosas. (Ver figura 5) 4. PORQUE ES IMPORTANTE LA ARQUITECTURA El establecimiento de unos principios de diseño en ingeniería [13], han tenido como consecuencia probada: Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computador. Destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software. Figura 5 Tomado de Norma ISO/IEC 9126 Cabe anotar también que una arquitectura bien diseñada y que esta relacionado con el esfuerzo de uso y la
evaluación sobre el uso hecha por los usuarios, puede alcanzar características como: Entendibilidad posibilidad de que los usuarios reconozcan los conceptos y su aplicabilidad. Aprendibilidad esfuerzo necesario para adquirir un determinado nivel de destreza. Operabilidad esfuerzo necesario para operar y controlar la operación del software Agrado de uso evaluación subjetiva (encuesta) hecha por los usuarios [14] 5. PROPUESTA La Arquitectura de Software puede y debe desempeñar un rol fundamental, en un escenario donde el desarrollo de software tiende hacia formalización y automatización de procesos de ingeniería, que brinden la seguridad y capacidad de predicción de otras disciplinas. Sería de gran importancia contar con un proceso de Arquitectura de Software capaz de acoplarse a cualquier metodología de desarrollo de software, en el que se distingan claramente los beneficios de aplicarla en cada etapa y las consecuencias de no tenerla en cuenta. Se plantean aquí algunos lineamientos y prácticas útiles para ser utilizados en cualquier proceso de desarrollo de software: Pensar que siempre se puede mejorar, tanto en los aspectos técnicos como en los humano.[15] La arquitectura debe cumplir también con unos requisitos, pues la nemotecnia y la sintaxis son importantes estandarizar conceptos que podrán entender tanto usuarios como profesionales del diseño: La prestación de un "vocabulario de elementos de diseño", que son "los componentes y el conector de tipo". La definición de un "conjunto de reglas de configuración". La definición de una interpretación "semántica", que da algún significado bien definido a todas las configuraciones de diseño de elementos que cumplan las normas de configuración. La definición de "análisis" para las configuraciones de que estilo. Esto nos lleva a pensar en unos artefactos, que permitan representar tanto la estática como la dinámica del sistema, que si bien es cierto, y basado en los autores que se tomaron de reflexión para el presente artículo, dependen también de la complejidad del sistema a tratar (ver figura 6) Ante todo, el arquitecto debe: Conocer el dominio del problema a resolver. Ser un buen comunicador (implica saber escuchar) Saber persuadir (si se tiene razón) Tener habilidades de Project Manager, pero no enredarse con estas tareas en su desempeño diario. Figura 6 (Tomado de SERATIC - POPAYAN)
6. CONCLUSIONES Y TRABAJOS FUTUROS Las metodologías ágiles han tomado mucha importancia en nuestro tiempo. La mayoría de las casas desarrolladoras de software, sobre todo en nuestra región (sur occidente Colombiano), manifiesta usar métodos ágiles para la organización de sus productos. Por otra parte, las arquitecturas, han demostrado que su aplicación, ha permitido inmiscuir criterios de calidad, también para la obtención de un buen producto y ha sido muy bien aplicada en las metodologías prescriptivas o tradicionales. Pero el manifiesto ágil no es muy claro en su exposición frente a la arquitectura, dejando muchas veces a la codificación como uno de los elementos principales cuando se trata de diseño. Queda entonces la pregunta: bajo los principios de las metodologías ágiles, es posible realizar diseños arquitectónicos que cumplan con los estándares de calidad? Como trabajo futuro, queda el plantearse una arquitectura ágil, que basada en herramientas, patrones y componentes reutilizables, permita solidificar bajo un nuevo paradigma el desarrollo de software bajo las especificaciones y las exigencias del usuario de nuestro tiempo. 7. BIBLIOGRAFIA [1]Dick.Berry: http://www.ibm.com/developerworks/librar y/w-berry/. 2005 [2] Kent Beck. Embracing change with extreme programming. Ed Mc GRaw Hill. 2004. [3] D. Hix, H.R. Hartson. Developing User Interfaces. Ensuring usability trough. Product and Process. New York (USA). 2003 [4] Patricio Letelier y Mª Carmen Penadés. Metodologías ágiles para el desarrollo de software: Extreme Programming (XP). [5] Constantine, L. L., and Lockwood, L. A. D. Software for Use: A Practical Guide to the Models and Methods of Usage- Centered Design. 2004 [6] Booch G, Jacobson I, and Rumbaugh J. The Unified Modelling Language for Object- Oriented? Development (version 0.91) Rational Software Corporation [7] Beck, Kent. Extreme Programming explained. Reading, Mass: Addison- Wesley? Longman, Inc. 2003. [8] Highsmith J., Orr K. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House. 2004 [9] Costabile, M.F. Usability in the Software Life Cycle. Handbook of Software Engineering and Knowledge Engineering. ed. S. K. Chang. World Scientific Publishing, Singapore, 2004. [10] Glass, Robert L. Facts and Fallacies of Software Engineering. Boston, 2006. [11] Larman, C.: UML y Patrones, Segunda Edición: Prentice-Hall, 2004 [12] Desarrollo de Software Orientado a los Negocios con Métodos Ágiles. Pablo Straub. 2007 [13] Recopilación de Métodos de Usabilidad. Alejandro Floría Cortés (2005). [14] Desarrollo de Software Orientado a los Negocios con Métodos Ágiles. Pablo Straub. Presentación. 2007 [15] Valerio Adrián Anacleto. http://www.epidataconsulting.com/tikiwiki /tiki-read_article.php?articleid=16