: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?

articleId=28

El rol de la arquitectura de software en las metodologías ágiles

Por:Quirón en:Mar 27 de Dic, 2005 16:07 EST (16997 Lecturas)

El rol de la Arquitectura de Software en las metodologías ágiles no se encuentra lo

suficientemente documentado ni formalizado a través de un proceso acorde a la filosofía. El
presente trabajo tiene como aportes: 1) Definir lineamientos para crear un proceso de
arquitectura ágil, capaz de implementarse dentro de cualquier metodología. 2) Sentar las bases
para la definición de un proceso de arquitectura ágil.

El rol de la arquitectura de software en las metodologías ágiles. Lineamientos para su implementación

Lic. Valerio Adrián Anacleto
Epidata Consulting S.R.L.‐ Buenos Aires, Argentina
adrian@epidataconsulting.com
Diciembre de 2005

Abstract. El rol de la arquitectura de software en las metodologías ágiles no se encuentra lo suficientemente documentado ni
formalizado a través de un proceso acorde a la filosofía. El presente trabajo tiene como aportes: 1) Definir lineamientos para
implementar un proceso de arquitectura ágil capaz de implementarse dentro de cualquier metodología. 2) Se sientan las bases para
la definición de un proceso de arquitectura ágil.

Índice
Tabla de contenidos

Índice
Introducción
Metodologías ágiles
¿Qué es desarrollo de software ágil (Agile Software Development)?
Las técnicas de diseño en las metodologías ágiles
El código NO es el diseño
Aprehendiendo y tomando ideas
Las prácticas de Arquitectura de Software, el diseño y las metodologías ágiles
Definición de arquitectura
El doble rol de la arquitectura en un desarrollo de software
La arquitectura y su rol actual dentro de las metodologías ágiles
Toda decisión en ingeniería de software implica un compromiso (trade‐off)
Hacia un proceso de arquitectura de software ágil
No jerarquizar el Rol
Un solo arquitecto para definir la arquitectura
Requerimientos de calidad
Usar SAAM
Requerimientos de calidad tratados como riesgos
Utilizar la categorización de riesgos del SEI
Mantenga una adecuada administración de los riesgos del proyecto

1 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Dejar de lado la tentación de la clarividencia (Resuelva el problema actual)

Dejar de lado el mito del sentido común
Plantear la arquitectura como un servicio
Armar grupos de arquitectura transversales
Hablar Patterns
Utilizar ABAS
Crear Tracer Bullets
Definir un leguaje de alto nivel profesional
Compartir las decisiones conflictivas
Sólo involucrarse en las decisiones de mayor impacto arquitectónico
Confianza en el equipo
Testear los requerimientos de calidad
Puntos de control y tests de integración
No transferir responsabilidades
Realizar una arquitectura comprensible
Arquitectura Simple
Defina claramente los requerimientos
Releases Incrementales
Busque mejorar sus habilidades constantemente.
Aportes
Trabajo Futuro
Conclusiones
Referencias

Introducción
Desde sus comienzos a esta parte, las metodologías ágiles han logrado una gran conjunto de adeptos. Hoy en día, una considerable
cantidad de proyectos se desarrollan siguiendo algún tipo de metodología ágil y una proporción muy grande de las que no utilizan una
metodología ágil formal, sigue, al menos, lineamientos e ideas provenientes de éstas. Incluso algunas metodologías consideradas poco
ágiles, como RUP, ensayan nuevas aproximaciones que las hagan ver “más ágiles”. Varios ejemplos y referencias pueden encontrarse
en {28} En este contexto, la Arquitectura de Software como práctica de diseño no parece ser tratada con el detenimiento que se
merece. Prueba de ello es la escasa información disponible sobre esta práctica en la documentación de las distintas metodologías
ágiles. Otro factor de influencia, es la falta de documentación estandarizada; hoy por hoy, no existe un lenguaje DDL estándar para
definir arquitecturas. Esto implica que no existe un formalismo estándar, como son los diagramas de clases de UML, para documentar
arquitecturas. En estos momentos, UML aún no decidió cuál será, de los muchos lenguajes DDL existentes, el que se incluya en sus
futuras versiones. Creemos que el hecho de no tener debidamente en cuenta la Arquitectura de Software como un proceso en sí
mismo, dentro de cualquier proceso de desarrollo de software, repercute en proyectos más riesgosos, con tareas y asignaciones
distribuidas de manera incorrecta y, por sobre todas las cosas, se evidencia en la calidad final del producto

Metodologías ágiles
¿Qué es desarrollo de software ágil (Agile Software Development)?
A finales de los 90, varias metodologías comenzaron a atraer la atención del público en general. Cada una de estas metodologías era

2 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

una combinación de ideas viejas, ideas nuevas, y variaciones de ideas viejas. Pero todas tenían algo en común: enfatizaban la
colaboración entre equipos de programadores y expertos de negocio; promovían la comunicación cara a cara (como una manera más
eficiente que la documentación escrita); realizaban entregas frecuentes de nueva funcionalidad de negocio; contaban con equipos de
desarrollo auto organizados; tenían maneras de estructurar código fuente y equipos de desarrollo con el fin de que los requerimientos
más importantes no entren en crisis. {18} A principios de 2001, los pioneros y creadores de estas metodologías reunieron, en una figura
única, todo lo que sus metodologías tenían en común, utilizando el término “Ágil” como definición común a todas ellas. De esta forma,
crearon lo que acordaron se en llamar: el manifiesto para desarrollo de software ágil {19}. Algunos de los principios más importantes
definidos en este manifiesto son: {18}

1. Interacción personal de individuos por sobre los procesos y las herramientas

2. Trabajar con el código por sobre documentación escrita
3. Colaboración del cliente por sobre negociación de contratos
4. Responder al cambio antes que seguir y mantener un plan.

El término ‘ágil’ no describe una metodología particular, por el contrario, expresa la existencia de una familia de metodologías, las
cuales comparten las bases y lineamientos entre los que se encuentran los enumerados anteriormente. Como ejemplo de metodología
ágil, podemos citar, entre muchas otras, a Scrum, ))Feature‐Driven Development((, DSDM, Crystal, XP. {29, 30, 31, 32 y 6}
respectivamente.

Las técnicas de diseño en las metodologías ágiles

Muchas de las críticas que reciben hoy día las metodologías ágiles tienen relación con la aparente carencia de prácticas relacionadas
con el diseño formal de la aplicación o, en el caso de las metodologías que contemplan el diseño, su falta de formalismo en la
especificación. {13} Esta falta de formalismo se halla justificada, para algunos de los cultores de metodologías ágiles, por el siguiente
razonamiento: el diseño detallado lleva una inversión de tiempo considerable en decisiones y aspectos, que son inciertos hasta el
momento mismo en que se presentan. {6} En otras palabras, podríamos decir que, tradicionalmente, el diseño trató de anticipar al
cambio, pero cuanto más tratemos de prever el cambio, más tiempo tomará el diseño y habrá más clases en el modelo; lo que se
traduce en un modelo más complejo para mantener actualizado, con más líneas de código, y, lo que es peor, el hecho de que, al
producirse un cambio no previsto, quizás tenga que realizarse aún más trabajo que si no se hubiese diseñado para el cambio. Por tal
motivo, muchas de las metodologías ágiles proponen realizar un diseño informal, en papel si es necesario. El diseño debe ser lo más
sencillo posible. Este estilo de prácticas es parte de algo que, en metodologías ágiles, se conoce con el título de: “hacer todo lo posible
por hacer lo menos posible” {5}

El código NO es el diseño
Debido a las fuertes críticas recibidas por la carencia de diseño formal, se han escrito algunas contrapropuestas interesantes que
defienden la postura de las metodologías ágiles. La mayoría de las respuestas giran en torno al siguiente planteo, realizado por Fowler,
el cual puede encontrarse en {13}. El planteo dice lo siguiente: “¿Así que ha muerto el diseño? De ninguna manera, pero la naturaleza
del diseño ha cambiado. El diseño ágil busca las siguientes habilidades:

1. Un deseo constante de mantener el código tan claro y simple como sea posible.
2. Habilidades de refactoración, para que puedas confiadamente hacer mejoras cuando veas la necesidad.
3. Un buen conocimiento de patrones: no sólo las soluciones, sino también apreciar cuándo usarlos y cuándo evolucionar hacia
ellos.
4. Saber cómo comunicar el diseño a la gente que necesita entenderlo, usando código, diagramas y, sobre todo, conversación”.

Otra justificación, un poco menos formal, pero aún así de amplia aceptación, es la siguiente: “el código fuente es el diseño”{20}{21}. En
ésta se argumenta lo siguiente: puede verse al código fuente como el resultado final y visible del diseño, y en dónde quedan plasmados
todos los aspectos de éste. Esta idea, que es tomada de {21}, es llevada al extremo en algunas metodologías ágiles, en donde el diseño
no existe como etapa de desarrollo ni como generador de algún artefacto formal. Sólo se tiene en cuenta como algo informal, útil para

3 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

transmitir ideas entre desarrolladores. La justificación es que con el refactoring continuo, el buen diseño se va “encontrando” de a
poco. Estas ideas definen la opinión sobre el diseño de muchas de las metodologías ágiles y, sobre todo, de muchos de sus cultores. Si
bien estas opiniones son un tanto controversiales, es interesante rescatar su enfoque evolutivo, en contra de la postura predictiva que
tuvo históricamente el diseño.

Aprehendiendo y tomando ideas

El código no es el diseño, porque solamente nos muestra una vista de éste (la vista de código), mientras también existe, entre otras, la
dinámica. También hay varios modelos, por ejemplo: el de componentes, el de análisis, el de casos de uso, etc. Decir que el código
fuente es el diseño es como decir que el edificio terminado es su diseño. Hay cosas que no pueden verse. La sinergia que generan las
partes como un todo evita ver ciertos aspectos (vistas y modelos); el todo hace obtusa la visión, debido a la carencia de abstracción. Así
como ver el ala de un ave en movimiento no hace que se entienda cómo puede volar el ave, tampoco puede analizarse su estructura
interna o esqueleto. Necesitamos abstraernos del ser de plumas que vuela y analizar su diseño; no se entiende la aerodinámica de las
plumas, no se ve cómo están distribuidos los músculos, no tenemos noción del aparato circulatorio. Es decir, no tenemos vistas. Algo
similar ocurre con el código fuente. Si bien podemos ver la estructura interna del código y extraer información, no podemos ver la
estructura interna de los componentes que usa, así como tampoco nos es práctico extraer información a partir de la estructura. La
abstracción es necesaria para comprender el todo paulatinamente y de manera efectiva. Si a esto le sumamos el factor comunicación
con los stakeholders del proyecto, tema que será abordado más adelante, la comunicación se vuelve aún más complicada, en vez de
simplificarse. Es complejo decirle a un gerente que mire el ave en el aire para entender por qué y cómo vuela el ave.

Existen posiciones extremas, en algunos casos extremistas y hasta obtusas, entre las que se encuentran: por un lado, las metodologías
ágiles, diciendo que el código fuente es el diseño y, por otro, los puristas clásicos pregonando diseñar pensando en el cambio. A pesar
de estas posturas, rescatamos algunas ideas, las cuales serán tenidas en cuenta en lo que resta del paper. Estas ideas son:

no diseñar tanto para el cambio y sí tener en cuenta qué es necesario diseñar, cuándo y en qué nivel de detalle,
aceptar que los requerimientos cambian y manejarlo de la manera más ágil, siempre dispuesto al cambio sin reticencia
utilizar el enfoque iterativo e incremental, del cual se encuentran referencias en la bibliografía desde el año 1977 (ver {10}).

Las prácticas de Arquitectura de Software, el diseño y las

metodologías ágiles
Definición de arquitectura
Se tomará como definición de Arquitectura de Software la siguiente, ya que consideramos que, en la práctica, es la más útil de las
múltiples definiciones de arquitectura existentes:

“La Arquitectura de Software de un programa o sistema es la estructura o estructuras del sistema, la cual
comprende los componentes de software, las propiedades externas visibles de estos elementos y las relaciones
entre ellos” {11}. La definición de una arquitectura de software de manera temprana en un proceso de desarrollo brindará, entre
otros, los siguientes beneficios:{11} Work break down: la separación y asignación de tareas de grupos de trabajo. Principalmente, esto
se debe a que, al identificarse los componentes principales de la aplicación, se les pueden asignar grupos de trabajo. Facilita la
estimación: permite estimar componentes y conectores por separado, teniendo en cuenta, luego, tiempos de integración,
estabilización, etc. Look ahead: minimizar riesgos: Lidia con los requerimientos no funcionales:

El doble rol de la arquitectura en un desarrollo de software

A nuestro entender, la arquitectura juega un doble rol. Por un lado, contar con una arquitectura sirve, al desarrollador o grupo de
desarrolladores dedicados a un módulo, como contexto y referencia. A la vez, define los lineamientos básicos del proyecto dando un

4 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

marco de trabajo fuerte, permitiendo el intercambio de profesionales entre grupos de trabajo y definiendo estándares de trabajo, sin
una sobrecarga de burocracia. Simultáneamente, lo que podría considerarse sobrecarga de burocracia, debería quedar plasmado en
documentos destinados a la gerencia del proyecto. Estos documentos son requeridos por la gerencia en la mayoría de los casos. En
este trabajo, se propone realizar estos documentos en las etapas adecuadas del proyecto y beneficiarse de contar con fuertes (fuerte
no implica inflexible) lineamientos arquitectónicos durante todo el desarrollo. Al tomar en cuenta los lineamientos de arquitectura, el
diseño interno del componente puede manejarse de manera ágil, dejando la especificación formal (si la complejidad y/o el contexto de
éste lo requiere) para el momento en que ésta sea necesaria.

La arquitectura y su rol actual dentro de las metodologías ágiles

Resulta difícil encontrar documentación sobre cómo definir una arquitectura en un proyecto de desarrollo de software guiado por una
metodología ágil. La documentación disponible en muchos casos es sobre algunos lineamientos mínimos, como el caso de la noción
de metáfora de XP {6}. Originalmente, la arquitectura no era tenida en cuenta en las metodologías ágiles y, si se consideraba, se lo
hacía de un modo tangencial y superficial. Como ejemplo, podemos citar el libro {6} de Kent Beck, en el cual se le dedican a la
arquitectura tan sólo dos páginas. Con el tiempo, el rol de la arquitectura como agente previsor y de orden fue surgiendo, en varios
trabajos, en metodologías ágiles; pero, en muchos casos, con un cierto desdén y amplia diferenciación de lo que es en la actualidad el
perfil de Arquitecto de Software.

Toda decisión en ingeniería de software implica un compromiso

(trade‐off)
Los enfoques metodológicos ágiles pueden tender a crear una pequeña trampa. Ésta consiste en agilizar de tal manera el desarrollo de
un proyecto, que el proyecto en sí termina siendo una suerte de refactoring continuo, en la que el control y estimación del mismo se
vuelve caótico. Podemos ilustrar esto mediante una analogía sencilla: supongamos un algoritmo que trabaja por fuerza bruta. La lógica
de este algoritmo funciona de la siguiente manera: éste va a avanzar hasta descubrir una solución; chequea si la solución es óptima y, si
no lo es, continúa buscando la siguiente solución. Por otro lado, existen algoritmos que, si bien usan fuerza bruta, le brindan
información de contexto (local) y ofrecen visión a futuro, de manera de poder anticiparse y llegar antes al objetivo deseado para hacer
más ágil la búsqueda. Por ejemplo, teniendo en cuenta información local, el algoritmo podría darse cuenta, a mitad de camino, que el
camino seleccionado no es el que busca y así comenzar a recorrer un nuevo camino (solución) antes de llegar al final de ese. En estos
casos, si se toma demasiada información de contexto, pretendiendo saber demasiado sobre el futuro, el algoritmo puede ser más lento
aún que el algoritmo de fuerza bruta.

En la metáfora que planteamos, el camino que supone desarrollar el proyecto es el camino a descubrir con el algoritmo. De hecho, el
camino, en ambos casos, es desconocido, ya que no sabremos sino hasta el final si las decisiones tomadas fueron las correctas. En eso
se basan buena parte de las suposiciones de las metodologías ágiles y tradicionales. El algoritmo es la metodología a implementar. El
algoritmo de fuerza bruta puro es una metodología ágil mal aplicada, que no piensa ni mira más allá del módulo y que sólo tiene en
cuenta información local (relativa al módulo de un equipo de personas acotado) El algoritmo que trata de ver muy a futuro es la típica
sobre‐especificación, donde se tiende cambiar la documentación de manera continua y repetitiva, porque la misma documentación se
repite.

El algoritmo de fuerza bruta con la heurística justa es el que utiliza información global, local y que prevé el futuro, aunque sea a corto
plazo. La heurística justa, sin duda, depende del proyecto. Algunas ideas interesantes sobre adaptación de metodologías basadas en el
tipo de proyecto se pueden encontrar en {32}. Este tema tiene relación con la necesidad de brindar un contexto a los trabajos de
ingeniería de software basado en taxonomías de proyectos. {33} Con la utilización de la arquitectura, buscamos definir una heurística
‐que debería ser adaptada según la taxonomía del proyecto‐ que permita agilizar aún más la metodología en cuestión y que aporte
todos los beneficios, enumerados anteriormente, de la utilización de prácticas de arquitectura en un proyecto de software.

Hacia un proceso de arquitectura de software ágil

5 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

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, como la ingeniería civil. 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 aplicarlo en cada etapa y las
consecuencias de no tenerlo en cuenta. Se plantean aquí algunos lineamientos y prácticas útiles para ser utilizados en cualquier proceso
de desarrollo de software, independientemente de la metodología utilizada. Algunos de estos lineamientos son tomados de otros
autores, en cuyo caso se hace referencia a la fuente.

No jerarquizar el Rol
Ser arquitecto es sólo un Rol. Este rol puede ser desempeñado por cualquiera que tenga las habilidades necesarias. Habría que
considerar como muy importante no darle una concepción divina al Rol. Quien lo desempeña no se encuentra en una posición
superior, en el organigrama, a ningún otro miembro del equipo.

Un solo arquitecto para definir la arquitectura

La arquitectura debe ser el producto de un arquitecto solamente, o de un pequeño grupo con un único líder claramente identificado
{11}. La arquitectura macro y en una concepción abstracta debe, en lo posible, ser realizada por un solo arquitecto. Esto brinda una
componente ágil, evitando largas discusiones. El arquitecto debe, por su parte, compartir, delegar y comunicar cuestiones de menor
abstracción y puede apoyarse en otros integrantes del equipo de desarrollo para tomar las decisiones. Este Rol puede ser
desempeñado por cualquiera de los arquitectos del proyecto y, al Rol, le daremos el nombre de Arquitecto de Aplicación. Es importante
destacar que menor abstracción no implica, bajo ningún punto de vista, menor importancia. También es interesante destacar que, en
una organización dedicada al desarrollo de software, el rol de arquitecto puede ser desempeñado por cualquiera de los miembros,
siempre y cuando se encuentre capacitado. Incluso resulta interesante el intercambio de estos roles en distintos proyectos. {34}

Requerimientos de calidad
Los arquitectos deben tener una lista de requerimientos funcionales para el sistema y una lista priorizada de atributos de calidad (tales
como modularidad, modificabilidad, etc). {11} Los atributos de calidad pueden estar categorizados y no deberían limitarse solamente a
la calidad del producto final, sino también a los requerimientos de calidad de diseño, de código, de testing, de performance, etc.

Usar SAAM
Usar el Software Architecture Analysis Method {11} para analizar distintas arquitecturas candidatas es un método en extremo sencillo y
es muy útil para comunicar ideas. Se puede usar en lugar de métodos más complicados, como ATAM {23}, que deberían ser tenidos en
cuenta sólo para determinados casos.

Requerimientos de calidad tratados como riesgos

Muchos requerimientos de calidad, sobre todo aquellos que tienen que ver con la performance, la usabilidad, la carga, la disponibilidad,
etc. pueden ser tratados como riesgos. Es decir que, el hecho de que uno de ellos no se cumpla, implica un riesgo. A su vez, estos
requerimientos pueden categorizarse y administrarse de igual manera que un riesgo, utilizando una plantilla bastante simple, en la que
se detallen el impacto, el costo de mitigarlo, la probabilidad, etc. Esta misma plantilla puede ser tomada de cualquier plantilla de
administración de riesgos y deberá contar con una columna más, que indique la arquitectura seleccionada. Distintas arquitecturas
tendrán impactos diferentes sobre los requerimientos de calidad y éstos deben ser tenidos en cuenta. La plantilla realizada de esta
manera servirá como base para realizar un SAAM sobre las distintas arquitecturas candidatas.

6 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Utilizar la categorización de riesgos del SEI

El Software Engineering Institute (SEI) {36} ofrece una categorización de riesgos relativos a proyectos informáticos; la misma se
encuentra en {38}. Utilizando esta categorización, pueden descubrirse riesgos no contemplados, pero también puede ser utilizada para
identificar requerimientos de calidad. Por ejemplo, en la taxonomía, figura “disponibilidad”. Que la aplicación no cumpla con los
requerimientos de disponibilidad que el cliente espera puede significar un riesgo. Identificar cuál es el requerimiento de calidad que el
cliente espera y escribirlo formalmente, es un requerimiento de calidad. De igual manera, pueden identificarse requerimientos de
calidad relativos a: interfaces, performance, testeabilidad, ambiente, schedule y staff, entre otros.

Mantenga una adecuada administración de los riesgos del proyecto

Existen prácticas sencillas, algunas figuran en {40}. También existen varios lineamientos dentro de muchas metodologías ágiles.
Creemos que una de las mejores fuentes sobre administración de riesgos ‐y que todo arquitecto debería leer‐ se encuentra en {37}. Si
bien implementar todo el conjunto de recomendaciones puede resultar muy poco ágil, tener en cuenta su existencia sin duda ahorrará
dolores de cabeza.

Dejar de lado la tentación de la clarividencia (Resuelva el problema actual)

No intentar predecir el futuro. Realizar solamente la arquitectura de lo que se sabe no va cambiar en el corto plazo. Hoy día la creación
de arquitecturas de aplicación está evolucionando hacia la especificación de servicios y la creación de arquitecturas transversales (SOA).
Esto plantea la creación de arquitecturas transversales a los servicios y evolutivas en sí mismas. Querer predecir el futuro de la compañía
y cómo será su negocio en el mediano plazo no es tarea del arquitecto ni de los desarrolladores. Lidiar mediante la adecuada
adaptación de la arquitectura, sí lo es.

Dejar de lado el mito del sentido común

Muchas veces se justifican las decisiones de ingeniería de software bajo el halo del sentido común. Es claro que resulta necesario el
sentido común en la vida en general, pero si bien para el físico puede ser una cuestión de sentido común que E = MC2, pero para la
mayoría de los mortales no. Sucede que el hecho de entender por qué algo es de una determinada manera no lo transforma en una
cuestión de sentido común. De igual manera, no pertenece al sentido común la creación de un pattern y tampoco la estimación de
proyectos es una cuestión de sentido común (valga la redundancia); de hecho, requirió años desde que comenzó la programación,
llegar a la noción de pattern y lograr métodos de estimación serios y eso no quiere decir que los ingenieros de software que
precedieron a estos conceptos carecieran de sentido común. Las sentencias que suelen ser atribuidas al sentido común están basadas
en conocimiento preconcebido y todas las afirmaciones y juicios realizados se basan en ese conocimiento previamente adquirido. {43}

Plantear la arquitectura como un servicio

La arquitectura puede verse como un servicio que da soporte a los procesos de negocios. Bajo esta concepción, la arquitectura debería
dar soporte al negocio y debería poder evolucionar con éste. Desde este punto de vista, el carácter evolutivo o no de una arquitectura
puede verse como un requerimiento de calidad.

Armar grupos de arquitectura transversales

Puede resultar una buena práctica armar grupos de arquitectura con gente de distintos módulos, que se desempeñen en tiempo parcial,
haciendo tareas de arquitectura y compartiendo su opinión respecto a ésta. Este enfoque brinda la oportunidad de dar a conocer mejor
la arquitectura a todo el equipo de desarrollo e involucrar a todos, mejorando la arquitectura gracias al feedback de los involucrados.
{34}

7 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Hablar Patterns
Utilizar como parte del lenguaje cotidiano de trabajo los patterns, aunque sea sólo aquellos más conocidos. Hoy por hoy, es difícil ver
un desarrollador que no haya leído un libro de patterns. La comunicación es un factor principal en un equipo que pretende utilizar una
metodología ágil. Resulta importante poder subir el nivel de abstracción y saber que todos los miembros del equipo de desarrollo
entienden cuando alguien dice: ‘esto es un composite, un delegate o un DAO’. Algunas decisiones de diseño pueden tener implicancias
sobre los atributos de calidad del diseño y de la aplicación.{35}

Utilizar ABAS
Un ABAS (Attribute‐Based Architectural Style){24} puede pensarse como una parte pre‐analizada de una arquitectura de software. Un
ABAS se encuentra conformado por: (1) un Architectural Pattern (Style); (2) la descripción de los componentes de software y sus
relaciones; (3) atributos de calidad relativos a estos componentes y cómo estos se conectan; (4) un framework analítico que permita
razonar sobre los atributos de calidad. La utilización de ABAS permite la reutilización de partes de arquitecturas ya definidas. Además,
permite dar una aproximación segura, comprobada y medible a los atributos de calidad relacionados con el architectural style. Es
factible pensar que el correcto uso de architectural styles agilizará y facilitará la toma de decisiones sobre arquitecturas. El uso de ABAS
también facilita la comunicación, de igual manera que “hablar patterns”.

Crear Tracer Bullets

En la mayoría de los casos en los que hay una interfaz de usuario, suele ser muy útil armar un prototipo. Este prototipo suele utilizarse
para validar los requerimientos junto al usuario. Ahora bien, en muchas metodologías, el prototipo se tira una vez validados los
requerimientos. Proponemos usar aquí una aproximación como la definida en {40}, en la cual el prototipo llamado “tracer bullet” sirve
para afinar los requerimientos, pero también debe utilizarse para validar la arquitectura y realizar tests. El “tracer bullet” es parte de la
aplicación final, es decir que no se tira y evoluciona, hasta la forma final de la aplicación.

Definir un leguaje de alto nivel profesional

Utilizar un lenguaje altamente profesional, mediante el conocimiento común de las técnicas y herramientas utilizadas por el equipo de
profesionales. Esta práctica agiliza el proceso de comunicación entre las partes. Es cierto que existe una decisión de compromiso entre
el lenguaje y el aprendizaje requerido por un nuevo miembro del equipo. Puede considerarse este aprendizaje como una inversión a
mediano plazo.{35}

Compartir las decisiones conflictivas

Contar con un arquitecto que comparta las decisiones conflictivas con los miembros del equipo de arquitectura e incluso con el resto del
equipo, si la decisión es demasiado conflictiva.

Sólo involucrarse en las decisiones de mayor impacto arquitectónico

Contar o seleccionar un arquitecto que: no disipe la atención de las decisiones que tienen mayor impacto en la arquitectura; no se
transforme en un factor de retraso; no se involucre en discusiones absurdas que no llevan a ningún lado; deje de lado las discusiones
por el uso de herramientas, IDEs y metodología de trabajo, a menos que éstas tengan algún impacto en la arquitectura; se mantenga
pendiente de las implicancias y validación del uso adecuado de la arquitectura definida.

Confianza en el equipo

8 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

El arquitecto debe conocer a su equipo de trabajo, de manera que pueda generarse en él la confianza necesaria. De esta manera, el
arquitecto podrá y deberá confiar en el equipo, debido a que éste confía en él para que defina la mejor arquitectura posible dentro del
contexto del proyecto. Los lazos de confianza profesional son difíciles de mantener si no hay un sentimiento recíproco.

Testear los requerimientos de calidad

La arquitectura debe velar por los requerimientos de calidad. De igual manera que existen los tests de unidad, puede resultar útil definir
baterías de test, que validen los requerimientos de calidad, por ejemplo, el tiempo de respuesta promedio, cantidad de usuarios
concurrentes, etc. Los tests pueden automatizarse e incluirse dentro del proceso normal de SCM.

Puntos de control y tests de integración

Auditar constantemente la arquitectura y su uso hará que se tengan en cuenta los nuevos requerimientos. Puede resultar bastante útil y
práctico definir puntos de control en los test de integración. Cada integración plantea la necesidad de correr la batería de test de
arquitectura que valida y certifica los requerimientos de calidad.

No transferir responsabilidades
El desempeño de un profesional en un determinado rol le confiere derechos y obligaciones. El rol de arquitecto tiene la obligación de
no transferir la responsabilidad por las decisiones tomadas y por el resultado final de la arquitectura. Si la arquitectura no cumple con
los requerimientos especificados, es pura y exclusivamente responsabilidad del arquitecto.

Realizar una arquitectura comprensible

La arquitectura es también un medio de comunicación y el hecho de documentar la arquitectura de manera clara, sirve como nexo
entre perfiles técnicos y no técnicos,. Utilizar stererotypes {41} de manera conveniente, puede resultar de gran ayuda.

Arquitectura Simple
Mantenga la arquitectura lo más simple posible. Si la simpleza se traduce en facilidad de uso de la arquitectura, facilidad para entender
los conceptos involucrados y está bien documentada, es muy probable que el nivel de productividad aumente. La simpleza de la
arquitectura es también un requerimiento de calidad.

Defina claramente los requerimientos

Defina claramente los requerimientos de calidad. La arquitectura debe poder medirse sobre la base de una especificación de
requerimientos de calidad bien documentada. El requerimiento de calidad debe ser testeable. Por ejemplo, decir “el sistema debe ser
estable”, relativo al requerimiento de calidad ‘estabilidad’, no es formal ni testeable; pero un requerimiento de calidad que diga “el
sistema debe tener un 99,99 de disponibilidad”, es un requerimiento testeable.

Releases Incrementales
Implemente releases incrementales que sean certificadas por el grupo de arquitectura. Cada release debe ser arquitecturalmente válida.
Esto quiere decir que la release debe respetar la arquitectura actual. Es necesario tener en cuenta que la arquitectura, por estar
comprendida dentro de un entorno ágil, muy posiblemente evolucione y cambie, pero siempre deberá respetar los requerimientos de
calidad.

9 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Busque mejorar sus habilidades constantemente.

Es un buen ejercicio suponer, por un momento, que nuestra profesión no está relacionada con el desarrollo de software, sino con la
medicina. Si tuviéramos que realizar una operación, ¿qué métodos, técnicas y herramientas utilizaría? ¿Sometería a una persona a una
cirugía que le produzca una cicatriz por el resto de su vida, si ésta es tratable mediante alguna técnica moderna, como por ejemplo
láser? Si usted fuera el paciente, ¿le gustaría que lo opere un cirujano actualizado o esto no tendría importancia?

El desarrollo de software, al igual que la medicina, es una profesión basada en el conocimiento actualizado. Las habilidades de ambos
deberían medirse por su conocimiento y el buen uso de éste. Por lo tanto, es factible pensar que mantenernos en constante
aprendizaje y conocer cuáles son nuestras debilidades para mejorarlas nos permitirá desempeñar mejor nuestra tarea. Algunas de las
buenas características personales a buscar en un arquitecto de software ágil podrían ser: (1) Conocer el dominio del problema a resolver
(2) Ser un buen comunicador (implica saber escuchar) (3) Saber persuadir (si se tiene razón) (4) Tener habilidades de Project Manager,
pero no enredarse con estas tareas en su desempeño diario (5) Pensar que siempre se puede mejorar, tanto en los aspectos técnicos
como en los humanos.{43}

Aportes
En el presente artículo, se muestra la necesidad de implementar prácticas tradicionales de Arquitectura de Software con un enfoque
ágil, en proyectos que implementen cualquier tipo de metodologías. Se aportan lineamientos útiles para la implementación de las
prácticas de arquitectura de manera ágil. En este trabajo no se discute cómo deben aplicarse estos lineamientos, ni en qué estadio del
proceso. Se sientan las bases para desarrollar un proceso de arquitectura ágil, que sea posible implementar dentro del contexto de
cualquier metodología y/o proceso de desarrollo.

Trabajo Futuro
Como extensión al trabajo realizado, podemos plantear la definición de un proceso de desarrollo y especificación de arquitecturas de
software ágil que pueda implementarse en el contexto de cualquier metodología. Muchos de los lineamientos expuestos aquí pueden
ser extendidos, mostrando ejemplos de uso, contextualizándolos en un dominio de problema adecuado.

Conclusiones
En este artículo se plantea la necesidad de definir un proceso de Arquitectura de Software que sea capaz de asociarse con cualquier
metodología de desarrollo existente. Se buscó también, cubrir la necesidad de que este proceso sea ágil, de manera tal que pueda ser
utilizado tanto en procesos ágiles como tradicionales. Como una primera aproximación a la resolución de este problema, se plantean
algunos lineamientos que deberían ser tenidos en cuenta al momento de realizar una arquitectura para cualquier proyecto de desarrollo
de software. Algunos de los lineamientos fueron recopilados de la bibliografía existente sobre el tema y algunos otros son aportes
originales del presente trabajo. Todos los lineamientos propuestos están basados en estándares aceptados del mercado o de trabajos
de reconocido nivel académico. La originalidad del planteo no sólo radica en su utilización para agilizar un proceso arquitectónico, sino
también en la propuesta de varios lineamientos.

Referencias
1. Anacleto, Valerio Adrián, Amandi Analia, Marisa Bauza, “Perfiles de Usuario para Agentes de Interfaz: Un análisis de técnicas de
aprendizaje” Tesis de licenciatura. Departamento de Computación, Universidad de Buenos Aires. 2003.
2. Gamma E, Helm R, Johnson R, and Vlissides J, Design Patterns: Elements of Reusable Object Oriented Software, Addison‐
Wesley, 1995
3. Fowler M. Analysis Patterns: Reusable Object Models, Addison‐Wesley?, 1997

10 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

4. Fowler M, UML Distilled: Applying the Standard Object Modeling Language, Addison‐ Wesley, 1997.
5. Booch G, Jacobson I, and Rumbaugh J. The Unified Modelling Language for Object‐Oriented? Development (version 0.91)
Rational Software Corporation
6. Beck, Kent. Extreme Programming explained. Reading, Mass: Addison‐Wesley? Longman, Inc. 2000.
7. Beck, Kent and Martin Fowler. Planning Extreme Programming. Reading, Mass: Addison‐Wesley? Longman, Inc. 2001.
8. Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addision‐Wesley, 1999.
9. Sommerville, Ian. Software Engineering. Addison Wesley. 5st ed. 1995.
10. Bass, Len. Clements, Paul. Kazman, Rick. Software Architecture in Practice. Addison Wesley. 1998.
11. Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software Architecture. Addison‐Wesley?. 1st edition 1999
12. Fowler, Martin ¿Is Design Dead? http://www.programacionextrema.org/articulos/designdead.es.html . 2000.
13. http://www.june19th.com/ili/xp/index.html
14. Extreme Programming Practices, http://www.ootips.org/xp.html
15. History Of Extreme Programming, http://www.cs.wm.edu/~noonan/ExtremeProgramming
/HistoryOfExtremeProgramming.html
16. http://www.xprogramming.com/index.htm
17. http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm
18. Manifesto for Agile Software Development: http://www.agilemanifesto.org/
19. The Source Code Is The Design:http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign
20. Code as Desgin, Jack W. Reeves, 1992 http://www.developerdotstar.com/mag/articles/reeves_design_main.html
21. Malan, Ruth, and Dana Bredemeyer, "Less is More with Minimalist Architecture", published in IEEE's IT Professional,
September/October 2002.
22. Rick Kazman et all: “Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis”
23. http://www.sei.cmu.edu/publications/documents/97.reports/97tr029/97tr029title.htm
24. Extreme Programming Myths: http://c2.com/cgi/wiki?ExtremeProgrammingMyths
25. Alistair Cockburn; “The Methodology Space”: http://alistair.cockburn.us/crystal/articles/ms/methodologyspace.htm
26. Agile Modeling, http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
27. Martin Fowler; “The New Methodology”: http://www.martinfowler.com/articles/newMethodology.html
28. Ken Schwaber, Mike Beedle. Agile Software Development with SCRUM. Paperback.
29. Stephen R Palmer, John M. Felsing. A Practical Guide to Feature‐Driven? Development (The Coad Series). Paperback
30. DSDM Consortium, Jennifer Stapleton. DSDM: Business Focused Development, Second Edition. Paperback
31. Alistair Cockburn. Crystal Clear : A Human‐Powered? Methodology for Small Teams. Paperback.
32. Valerio Adrián Anacleto: http://www.epidataconsulting.com/tikiwiki/tiki‐read_article.php?articleId=2
33. Valerio Adrián Anacleto. Asignación caótica de profesionales a proyectos.
34. Valerio Adrián Anacleto. Che Loco, alcánzame un Coso ó sobre ambigüedades cosométricas.
http://www.epidataconsulting.com/tikiwiki/tiki‐read_article.php?articleId=16
35. Software Engineering Institute (SEI). http://www.sei.cmu.edu/
36. http://www.sei.cmu.edu/risk/main.html
37. Brian Gallagher. Taxonomy of operational risk. http://www.sei.cmu.edu/risk/taxonomy.pdf
38. M. Carr et all. Taxonomy based risk Identification. SEI1993 http://www.sei.cmu.edu/publications/documents/93.reports
/93.tr.006.html
39. Andrew Hunt, David Thomas: “The pragmatic programmer“ ‐ (Paperback)
40. Dan Pilone y Neil Pitman, “UML 2.0 in a Nutshell” ‐ First Edition June 2005
41. Emilio Rasic, ”El rol de los Arquitectos de Software” ‐ http://www.epidataconsulting.com/tikiwiki/tiki‐
read_article.php?articleId=7
42. Eliyahu M Goldratt “The Goal” 3ra Edición.

Lic. Valerio Adrián Anacleto

- Deploying ideas Epidata Consulting Maipú 521 1er piso Of. A Ofi: 5031 0060 / 61 www.epidataconsulting.com

11 de 12 3/31/2011 4:36 PM
: El rol de la arquitectura de software en las metodologías ágiles http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

12 de 12 3/31/2011 4:36 PM