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

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 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 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:

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 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

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.

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}

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

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.

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
  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 (external link). 2000.
  13. http://www.june19th.com/ili/xp/index.html (external link)
  14. Extreme Programming Practices, http://www.ootips.org/xp.html (external link)
  15. History Of Extreme Programming, http://www.cs.wm.edu/~noonan/ExtremeProgramming/HistoryOfExtremeProgramming.html (external link)
  16. http://www.xprogramming.com/index.htm (external link)
  17. http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm (external link)
  18. Manifesto for Agile Software Development: http://www.agilemanifesto.org/ (external link)
  19. The Source Code Is The Design:http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign (external link)
  20. Code as Desgin, Jack W. Reeves, 1992 http://www.developerdotstar.com/mag/articles/reeves_design_main.html (external link)
  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 (external link)
  24. Extreme Programming Myths: http://c2.com/cgi/wiki?ExtremeProgrammingMyths (external link)
  25. Alistair Cockburn; “The Methodology Space”: http://alistair.cockburn.us/crystal/articles/ms/methodologyspace.htm (external link)
  26. Agile Modeling, http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm (external link)
  27. Martin Fowler; “The New Methodology”: http://www.martinfowler.com/articles/newMethodology.html (external link)
  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/ (external link)
  36. http://www.sei.cmu.edu/risk/main.html (external link)
  37. Brian Gallagher. Taxonomy of operational risk. http://www.sei.cmu.edu/risk/taxonomy.pdf (external link)
  38. M. Carr et all. Taxonomy based risk Identification. SEI 1993 http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html (external link)
  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