Integrando la Arquitectura al Ciclo de Desarrollo de Software

A lo largo de las últimas ediciones de esta sección hemos realizado un recorrido a través de las distintas actividades asociadas con el desarrollo de la arquitectura de software, a saber: la captura y especificación de requerimientos que influyen en la arquitectura, el diseño de la misma, su documentación y su evaluación. Aunque dichas actividades no están asociadas a una metodología particular de desarrollo, en este artículo veremos cómo se pueden incorporar a cualquier ciclo de desarrollo.

La arquitectura dentro del ciclo de desarrollo

Ya hemos comentado la importancia de la toma de decisiones de diseño arquitectónico de manera temprana. La arquitectura de software se enfoca en lograr la satisfacción de requerimientos guía, y particularmente de atributos de calidad tales como el desempeño, disponibilidad, seguridad y modificabilidad. A diferencia de los requerimientos funcionales típicos, el código que implementa aspectos relacionados con atributos de calidad generalmente se encuentra disperso en una gran cantidad de módulos del sistema. Por otro lado, ciertas decisiones de diseño que se toman para satisfacer un atributo de calidad, por ejemplo el desempeño o la disponibilidad, influyen de forma general sobre todo el código de la aplicación, incluso sobre cuestiones físicas (por ejemplo la elección de hardware). Es así que realizar cambios en atributos de calidad de forma tardía es una cuestión compleja y problemática. Por lo anterior, es conveniente que las actividades relacionadas con la arquitectura de software se realicen de manera temprana en el desarrollo. En particular es necesario:

• Identificar y especificar los requerimientos guía. Éstos incluyen a los atributos de calidad, los requerimientos funcionales primarios y las restricciones del sistema. La arquitectura se puede diseñar alrededor de estos.
• Diseñar la arquitectura e, idealmente, implementar una “arquitectura ejecutable” que permita materializar el diseño de la arquitectura.
• Documentar los aspectos fundamentales del diseño, teniendo especial cuidado en capturar las decisiones de diseño, para comunicarlas al equipo y que sirvan de guía.
• Realizar una evaluación poco después de que se ha terminado el diseño y antes de proceder a la construcción del sistema.

Es importante recalcar que diseñar la arquitectura de forma temprana no significa que se deba realizar el desarrollo siguiendo un enfoque secuencial (en cascada) de tal forma que primero se obtengan y especifiquen todos los requerimientos, luego se realice todo el diseño y luego se construya y pruebe la misma. El realizar un diseño completo de alto nivel conceptual (en documentación y no en código) que en inglés se conoce como “Big Design Up Front” (o BDUF), en raras ocasiones es exitoso.

Repasemos algunas metodologías de desarrollo populares, explicando cómo se pueden integrar en ellas las actividades arquitectónicas.

TSP

El proceso de desarrollo por equipos (TSP) promueve la creación de equipos auto-dirigidos y la mejora continua. TSP define cuatro fases: requerimientos, diseño de alto nivel, implementación y pruebas. Aunque la estructuración del sistema en base a componentes se considera en el diseño de alto nivel, no hay un énfasis particular en cuestiones de arquitectura. En TSP, un proyecto se estructura por ciclos que pueden o no estar enfocados a una fase específica. Un problema frecuente con TSP es que se utiliza un enfoque de ciclos asociados a fases específicas: uno o más ciclos enfocados a requerimientos seguidos de uno o más ciclos enfocados a diseño de alto nivel, seguidos de ciclos enfocados a la construcción y prueba del sistema. Lo anterior resulta en desarrollos en cascada.

La integración de actividades de arquitectura en TSP depende de la complejidad del proyecto y del contexto. Sin embargo, lo más recomendable es tener uno o más ciclos al inicio del proyecto enfocados específicamente al desarrollo de la arquitectura y dentro de los cuales se realicen actividades asociadas a las distintas fases de TSP. Un ciclo de arquitectura incluiría actividades de especificación de requerimientos guía, diseño de la arquitectura, desarrollo del prototipo y evaluación del diseño. Una vez que se termina la arquitectura, la construcción del sistema se realiza de forma incremental por encima de ésta [1, 2].

RUP

El Proceso Unificado de Rational (RUP) es un marco enfocado a desarrollo iterativo e incremental. Su estructura general se compone de 4 fases y 9 disciplinas. Las 4 fases son: inicio, elaboración, construcción y transición y se llevan a cabo en ese orden. Las disciplinas son conjuntos de actividades que abordan un aspecto del proyecto, tales como: modelado de negocios, gestión de requerimientos, análisis y diseño, implementación, pruebas, implantación, administración de la configuración y cambios, administración de proyectos y entorno. Dentro de cada fase se realizan actividades asociadas a las distintas disciplinas a lo largo de un número variable de iteraciones. Estas actividades se realizan con mayor o menor énfasis, dependiendo de la fase en la que se encuentre el proyecto.

Para RUP, la arquitectura de software es una cuestión fundamental y, de hecho, la fase de elaboración tiene como objetivo producir y validar la arquitectura del sistema que se materializa como una arquitectura ejecutable. La arquitectura ejecutable es “una implementación parcial del sistema construida para demostrar funcionalidades y propiedades específicas del sistema, en particular aquellas que permiten satisfacer los atributos de calidad”. RUP promueve que la arquitectura se diseñe, valide y codifique de forma temprana, antes de iniciar la construcción del sistema, con el fin de mitigar riesgos técnicos. RUP también promueve un esquema de documentación del diseño de la arquitectura, que es el modelo 4+1 vistas.

A pesar del énfasis que pone RUP en la arquitectura de software, no entra en detalles muy finos relativos a la especificación de atributos de calidad, el diseño de la arquitectura y su evaluación. Sin embargo, los métodos que hemos presentado ateriormente en esta sección se pueden integrar de forma natural dentro de RUP.

Métodos ágiles

El desarrollo de software ágil engloba una serie de metodologías cuya esencia se encuentra definida en el “Manifiesto para el desarrollo de software ágil“ (www.agilemanifesto.org). Esta filosofía se basa en el enfoque en factores humanos como cooperación, comunicación y confianza, el desarrollo iterativo, la simplicidad y la adaptabilidad. Extreme Programming y Scrum son dos métodos ágiles populares.

En general, en las metodologías ágiles no es común encontrar actividades específicas para desarrollar la arquitectura. Esto se puede asociar a diversos factores tales como:

• El enfoque en actividades que contribuyen al desarrollo y entrega de un producto funcional, en vez de actividades orientadas al diseño y documentación del sistema. El tiempo requerido para la generación y documentación de la arquitectura suele verse como una actividad secundaria que no forma parte del producto final.
• La mayoría de las metodologías ágiles funcionan con equipos pequeños y sistemas de tamaño medio. La importancia de la definición de la arquitectura puede no ser tan evidente en dichos escenarios, en los cuales pueden funcionar prácticas tales como la simplicidad, que sugiere enfocarse en los elementos del sistema identificados actualmente y posponer la adición de complejidad hasta el momento que se necesite (mediante la reestructuración de código o “refactoring”).

A pesar de esto, algunos métodos ya están incorporando adaptaciones a sus prácticas a fin de incluir actividades relacionadas con la definición de la arquitectura de software. Por ejemplo, algunos equipos que utilizan Scrum han incluido una iteración inicial llamada “Sprint cero”. En esta iteración, se genera una arquitectura de alto nivel que establece la forma en la que serán implementadas las características del sistema. Otro ejemplo es la recomendación de incluir y manejar los requerimientos no funcionales como historias de usuario.

Más información respecto a metodologías ágiles y arquitectura de software se puede encontrar en [5].

Conclusión

Las actividades arquitectónicas se pueden integrar dentro de cualquier metodología de desarrollo. A menos que se desarrollen sistemas muy simples, estas actividades son indispensables.

Un aspecto que se debe cuidar, particularmente en organizaciones medianas a grandes es que la incorporación de actividades arquitectónicas dentro de la metodología de la empresa es un proyecto de mejora que requiere de una cuidadosa implantación. Además de considerar los ajustes a la metodología propia de la organización, se debe considerar la documentación de los métodos y la capacitación de los arquitectos e ingenieros. La realización de evaluaciones de arquitectura también debe considerar cuestiones de logística que incluyen la conformación de los equipos de evaluación. Finalmente, es conveniente disponer de algún promotor (o “champion”) de la arquitectura que impulse la adopción del desarrollo de arquitectura de software dentro de la organización.