Ilustración 1. Manifiesto ágil

ARQUITECTURAS AGILES

Silvia Rivadeneira1, Gabriela Vilanova

2

Grupo de Investigación “Modelado de Requerimientos y Diseño de Sistemas Complejos”

Instituto de Tecnología Aplicada

Departamento de Ciencias Exactas y Naturales 1Unidad Académica Río Turbio,

2Unidad Académica Caleta Olivia

Universidad Nacional de la Patagonia Austral

CONTEXTO

El presente trabajo1 intenta convertirse en una

aproximación a la inserción de metodologías ágiles

en la arquitectura de software, un primer insumo a

modo de documento de trabajo en el marco del

proyecto de investigación PI 29/B176-1 denominado

“Modelado en Análisis y Diseño de Software, un

enfoque arquitectural” radicado en la Unidad

Académica Caleta Olivia (UACO) de la Universidad

Nacional de la Patagonia Austral (UNPA).

RESUMEN

Las metodologías ágiles han ido ganando bastante

popularidad en estos años, y últimamente, está

ganando más adeptos en los claustros académicos.

La comunidad ágil posee críticos y adeptos al uso de

arquitectura de software en este tipo de desarrollos.

Este trabajo intenta analizar los trabajos recientes

relacionados con esta área poco conocida en el

ambiente académico.

Palabras clave: arquitectura de software,

metodologías ágiles, proceso de desarrollo de

software

1. INTRODUCCION

En [4] establecen que la arquitectura es el conjunto

de decisiones significativas sobre la organización de

un sistema software, la selección de elementos

estructurales y sus interfaces, su comportamiento, la

composición de esos elementos estructurales y el

estilo arquitectónico que guía a la organización. Pero

también se relaciona con el uso, la funcionalidad, el

rendimiento, la capacidad de adaptación, la

reutilización, la capacidad de ser comprendido, las

restricciones económicas y tecnológicas y los

compromisos entre alternativas, así como aspectos

estéticos.

Coincidimos con [7] en que arquitectura de software

tiene que ver con la gran escala, las grandes

decisiones sobre la organización y estructura de los

elementos importantes del sistema, pero también es

parte investigación y parte trabajo de diseño, esto en

1 Financiado totalmente por la Universidad Nacional

de la Patagonia Austral, provincia de Santa Cruz,

Argentina.

UP (Unified Process) se denomina análisis

arquitectural.

Definir la arquitectura de un software de manera

temprana tiene como beneficios [1]:

Asignar tareas a los grupos de trabajo.

Facilitar la estimación.

Minimizar riesgos.

La SATI (Software Architecture Technology

Initiative) del SEI (Carnegie Mellon ® Software

Engineering Institute) viene desarrollando y

promulgando una serie de métodos centrados en

arquitectura, tales como SAAM, ATAM, QAW,

ADD, CBAM o ARID. Estos métodos predican los

axiomas que a continuación se detallan [9]:

1. Los requisitos de atributos de calidad

impulsan la arquitectura de software.

a. Los requisitos de atributos de

calidad se derivan de los objetivos

de negocio / misión.

b. Los escenarios son una poderosa

manera de caracterizar los

atributos de calidad y representar

opiniones de los interesados.

2. Las actividades centradas en la arquitectura

conducen el ciclo de vida del sistema de

software.

a. Estas actividades deben tener un

enfoque explícito en los atributos

de calidad.

b. Estas actividades deben involucrar

a los actores directamente.

El SEI trabaja integrando métodos centrados en

arquitectura en procesos populares de desarrollo de

software, tales como los ágiles [9].

A finales de los „90 surgen metodologías que

combinan ideas viejas, nuevas y variaciones de ellas,

pero con cosas en común, tales como: promover la

colaboración entre equipos de desarrollo y expertos

del negocio, privilegiar la comunicación cara a cara,

entrega frecuente de nuevas funcionalidades,

fomentar la mejora continua, equipos auto-

organizados, formas de estructurar el código con el

fin de que los requerimientos no provoquen crisis.

Ágil es un paradigma de desarrollo de software que

hace hincapié en el desarrollo rápido y flexible y

resta importancia del proyecto y la infraestructura de

proceso para su propio bien. En marzo de 2001, 17

representantes de estos cambios se reunieron,

utilizaron por primera vez el término ágil y crearon

lo que acordaron en llamar el Manifiesto por el

Desarrollo Ágil de Software [1], [3], [9], [10] (ver

Ilustración 1).

Hoy, existe una creciente discusión sobre utilizar los

términos metodologías ágiles, desarrollo ágil o

prácticas ágiles. Nosotros no nos detendremos en

esto, utilizaremos los términos indistintamente pero

en ellos englobaremos los principios y prácticas

mencionados en el Manifiesto.

Pero volvamos al desarrollo ágil, en este tipo de

desarrollo los clientes y los desarrolladores son

libres de interactuar constantemente, los proyectos

son construidos con las mejores herramientas y con

desarrolladores auto-motivados, el progreso es

medido por la cantidad de código escrito que

contribuye a la funcionalidad entregada, la agilidad

se refuerza con la excelencia técnica y el buen

diseño, simple, y, el equipo de proyecto es auto-

organizado [9], [11].

Una de las mayores críticas que sufren las

metodologías ágiles se relaciona con la carencia de

prácticas vinculadas con el diseño de software o su

falta de formalismo en la especificación, lo que,

habitualmente, se denomina “hacer todo lo posible

por hacer lo menos posible” [1], [9], [10], [11].

2. LÍNEAS DE INVESTIGACIÓN Y

DESARROLLO

Este artículo es parte del segundo proyecto de

investigación del grupo. Las líneas de investigación

que se vienen siguiendo están relacionadas con la

ingeniería de software, básicamente, las primeras

etapas en todo proceso de desarrollo de software, es

así, que nos interesa:

Modelado combinando BPMN y UML

Modelado aplicando metodologías ágiles

Integración de BPM y SOA

Arquitectura de Software

Y por otro lado, y no menos importante, nos interesa

la construcción del conocimiento en red, interesados

por las siguientes líneas de trabajo:

La interacción que se produce en entornos

colaborativos

La construcción colaborativa del

conocimiento

3. RESULTADOS OBTENIDOS/ ESPERADOS

En primera instancia, realizamos un análisis de la

bibliografía existente sobre arquitecturas ágiles, y,

en futuros trabajos buscaremos implementar algunas

prácticas en trabajos de campo, trabajos finales de

cátedra o casos reales.

Es bastante difícil encontrar trabajos académicos

relacionados con arquitectura de software en

metodologías ágiles [1] aunque se pueden encontrar

propuestas interesantes para metodologías

específicas o ideas que hacen uso de métodos

definidos por el SEI [2], [6], [11].

Autores como [1], [2] exponen la necesidad de

implementar prácticas tradicionales de Arquitectura

de Software con un enfoque ágil, en cualquier tipo

de metodologías.

Moreno [8] expresa, y nosotros acordamos, que las

bases de una arquitectura ágil deberían ser las

siguientes:

Estar orientada al negocio

Ser flexible

Ser colaborativa

No reinventar la rueda

El más claro ejemplo de la noción de diseño

arquitectural ágil es la actividad de identificar y

analizar las prioridades y dependencias entre las

historias de usuario [5].

La planificación de las iteraciones ágiles enfocada

en historias de usuario es la heurística típica

utilizada por la Comunidad Ágil, los requerimientos

deseados por los interesados son representados por

las historias de usuario y a éstas últimas se les asigna

la prioridad correspondiente según las necesidades

del usuario final [5], [10].

Es posible incorporar mejoras a la planificación de

entregas añadiendo arquitectura de software, por

ejemplo, al seleccionar las historias de usuario que

serán desarrolladas en cada iteración, el equipo debe

identificar elementos arquitecturales que deben ser

implementados para soportarlas. Algunas de las

herramientas sugeridas por [5] son:

Matriz de estructura de dependencias (DSM, Dependency Structure Matrix) que

muestra los subsistemas/actividades, la

información de intercambio y los patrones

de dependencia.

Matrices de mapeo de dominio (DMMs,

Domain Mapping Matrices) se puede usar

para representar las dependencias entre

capacidades y elementos arquitectónicos.

El análisis de opciones real, modelo de

análisis financiero que ayuda a determinar

si algún costo inicial debe ser pagado para

tener el derecho de realizar una acción en el

futuro.

La metáfora de la deuda técnica nos dice

que hacer las cosas rápidamente para un

beneficio a corto plazo nos llevará a una

deuda técnica.

Los autores [2], [13] agregan tres tácticas diferentes

para integrar el desarrollo arquitectónico incremental

al enfoque de desarrollo ágil, en este caso Scrum:

Ilustración 2. Método de arquitectura

ágil [14]

Alinear el desarrollo basado en funciones y

la descomposición del sistema.

Proporcionará flexibilidad a los equipos de

desarrollo, alineándolos en torno a historias

de usuario (función) y la descomposición

del sistema en relación a servicios comunes

y la reutilización.

Crear una ruta de arquitectura. Hacer

dependencias arquitectónicas visibles

permite su gestión y que los equipos se

alineen con ellas.

Utilizar equipos matriz. En su forma más

simple Scrum posee un único equipo

multifuncional, con habilidad, autoridad y

conocimiento necesario para especificar

requerimientos y arquitectura, diseñar,

codificar y probar el sistema. La

complejidad puede requerir replicar ese

equipo en varios equipos.

Fowler [12] enuncia que la naturaleza del diseño ha

cambiado ya que, el diseño ágil busca las siguientes

competencias o habilidades:

Un deseo constante de mantener el código

tan claro y simple como sea posible.

Habilidades de refactorización, para que

puedas confiadamente hacer mejoras

cuando veas la necesidad.

Un buen conocimiento de patrones: no sólo

las soluciones, sino también apreciar

cuándo usarlos y cuándo evolucionar hacia

ellos.

Saber cómo comunicar el diseño a la gente

que necesita entenderlo, usando código,

diagramas y, sobre todo, conversación”.

Ambler [15] esboza algunas ideas para ir en camino

a la arquitectura ágil, tales como:

No hay nada especial acerca de la

arquitectura. Todos tienen el mismo valor

en el proyecto, la humildad es un factor de

éxito.

Cuidado con las arquitecturas torre de

marfil. Aquellas diseñadas en solitario por

un arquitecto o grupo de arquitectos.

Cada sistema tiene una arquitectura.

Aunque no necesariamente hay modelos

arquitectónicos que definen esa

arquitectura.

Arquitectura ágil a escala. Mantener

estrategias en cuanto a tamaño del equipo,

cumplimiento de normas, distribución de

equipos, complejidad técnica.

Pero ¿quién es responsable por la arquitectura? En

equipos pequeños, todo el equipo. Afirman que la

arquitectura es demasiado importante para dejarla en

manos de una sola persona, pero puede volverse en

contra si son varias las personas que participan en su

elaboración [1], [15].

Meier [14] define su propio método de arquitectura

ágil en cinco pasos (ver ilustración 2):

Identificar los objetivos de la arquitectura

Identificar los escenarios clave

Crear una visión general de la aplicación

Analizar los puntos clave

Crear soluciones candidatas

Los objetivos de un arquitecto ágil según [16] son:

Entregar soluciones de trabajo.

Maximizar el valor de los interesados

(stakeholders).

Encontrar soluciones que respondan a los

objetivos de todas las partes interesadas.

Habilitar el siguiente esfuerzo.

Gestionar cambios y complejidad.

Johnston [16] establece, también, siete principios o

reglas de oro para los arquitectos ágiles:

Valorizar a la gente.

Comunicar.

Menos es más.

Planificarlo, gestionarlo.

Seleccionar la solución correcta para la

empresa.

Entregar calidad.

Modelar y documentar de manera ágil.

Luego de analizar los distintos autores a los que

tuvimos acceso podemos concluir que es factible

implementar distintas prácticas ágiles al crear una

arquitectura de software, pero que también es un

campo en el que aún no hay nada cerrado o definido.

4. FORMACION DE RECURSOS HUMANOS

Los integrantes del proyecto pertenecen en su

mayoría a la UNPA, contamos con un asesor,

académico perteneciente a Universidad de

Magallanes (UMAG), quien es profesor visitante en

la Unidad Académica Río Turbio (UART), cuyo rol

además de formar auxiliares de docencia, es preparar

e instruir jóvenes investigadores en el área de

Ingeniería de Software.

Asimismo, un par de integrantes pertenecen a la

Maestría en Educación en Entornos Virtuales y se

encuentran en trabajo de tesis, uno de los integrantes

cursa la Maestría en Informática y Sistemas; y un

último integrante ha cursado y presentado su tesina

para la Especialización en Management

Tecnológico.

Contamos, además, con un alumno de pre-grado de

la carrera Analista de Sistemas quien se encuentra

realizando el trabajo final.

5. BIBLIOGRAFIA

[1] Anacleto, V. 2008. El rol de la arquitectura de

software en las metodologías ágiles. Epidata

Consulting.

[2] Bachmann, F., Nord, R., Ozkaya, I. 2012.

Architectural Tactics to Support Rapid and

Agile Stability. CrossTalk.

[3] Beck, K. et al.: The agile manifesto.

Manifesto for Agile Software Development.

En: http://www.agilemanifesto.org

[4] Booch, G., Rumbaugh, J., Jacobson, I. 2006.

El lenguaje unificado de modelado. Pearson

Educación. Madrid.

[5] Brown, N., Nord, R., Ozkaya, I. 2010.

Enabling Agility Through Architecture.

CrossTalk.

[6] Cañadillas, D. 2010. Implantación de

arquitectura de desarrollo ágil. Universidad

Carlos III de Madrid.

[7] Larman, C. 2003. UML y patrones. Pearson

Educación. Madrid.

[8] Moreno, J. Arquitectura ágil. ORACLE.

México.

[9] Nord, R., Tomayko, J., Wojcik, R. 2004.

Integrating Software-Architecture-Centric

Methods into Extreme Programming (XP).

Technical Note CMU/SEI-2004-TN-036.

[10] Rivadeneira, S. 2013. Metodologías ágiles

enfocadas al modelado de requerimientos.

ICT-UNPA-57-2012.

[11] Urquiza, F., Martínez, A., Ibargüengoitia, G.

2010. Las metodologías ágiles y las

arquitecturas de software. CONIIS.

[12] Fowler, M. 2000. ¿Is design dead? En:

http://martinfowler.com/articles/designDead.h

tml. Consultado 01/09/2014.

[13] Ozykaya, I. 2011. Agile development and

Software Achitecture: understanding scale

and risk. SEI.

[14] Meier, J. 2008. Agile Architecture Method.

En:

http://blogs.msdn.com/b/jmeier/archive/2008/

11/06/agile-architecture-method.aspx

[15] Ambler, S. 2012. Agile Architecture:

Strategies for Scaling Agile Development.

En:

http://www.agilemodeling.com/essays/agileA

rchitecture.htm

[16] Johnston, A. Bringing Agility to Architecture,

and Architecture to Agility. Agile Architect.

En:

http://www.agilearchitect.org/agile/index.asp