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

: El El rol de la arquit arquitect ectu ura de soft software en en las metod etodolog ologías ías ágil ágiles es

http http://www. ://www.epid epidata atacon consu sult ltin ing. g.com com/tik /tikiwik iwiki/t i/tik iki-pr i-prin int_ t_art article icle.p .php hp?art ?article icleId Id=28 =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 [email protected] 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 p resente resente trabajo tiene como apo rtes: rtes: 1) Definir lineamientos 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 ntroducción ntrodu cció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) (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 Utili zar la categorizaci categorización ón d e riesgos del SEI Mantenga una ad ecuada administración administración de los riesgos riesgos del proyecto

: 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 ncrementales Busque mejorar sus habilidades constantemente. Aportes Trabajo Futuro Conclusiones Referencias

ntroducció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 pro yectos se desarrollan siguiendo algún tipo de metodología ágil y una proporción muy grand e de las que no utilizan una metodología ágil formal, sigue, al menos, lineamientos e ideas provenientes de éstas. I ncluso 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 p or 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 c ualquier proceso de d esarrollo de software, repercute en p royectos más riesgosos, con tareas y asignaciones distribuidas de manera incorrecta y, po r 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 g eneral. 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 programado res y expertos de negocio; promovían la co municación cara a cara (como una manera más eficiente que la d ocumentación escrita); realizaban entregas frecuentes de nueva f uncionalidad de n egocio; contaban con equipos de desarrollo auto o rganizados; tenían maneras de estructurar códig o 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 acord aron 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. nteracción personal de individuos por sobre los procesos y las herramientas 2. Trabajar con el código por sobre do cumentación escrita 3. Colaboración del cliente por sobre negociación de co ntratos 4. Responder al cambio antes que seguir y mantener un p lan. El término ‘ágil’ no d escribe una metodología particular, por el contrario, expresa la existencia de una f amilia de metodologías, las cuales comparten las ba ses 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 h oy d ía las metodologías ágiles tienen relación con la aparente carencia d e prácticas relacionadas con el diseño fo rmal de la ap licación o, en el caso de las metodologías que contemplan el diseño, su falta de fo rmalismo 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 co nsiderable 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 po stura 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 ca mbiado. El d iseño ág il 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 co nocimiento de patrones: no sólo las soluciones, sino también ap reciar cuándo usarlos y cuándo evolucionar hacia ellos. 4. Saber cómo co municar el diseño a la g ente que necesita entenderlo, usando código, d iagramas 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 op inión sobre el diseño d e 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, po r ejemplo: el de compon entes, 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, n o pod emos 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 n ecesaria pa ra 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 a delante, 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, p or otro, los p uristas 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 d e 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 id entificarse 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 d e 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 p uede manejarse de manera ágil, dejando la especificación formal (si la complejidad y/o el co ntexto 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 p or una metodología ágil. La do cumentació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 do s páginas. Con el tiempo, el rol de la arquitectura como agente previsor y de orden fue surgiendo, en varios trabajos, en m etodologí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 ag ilizar 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 o bjetivo deseado p ara hacer más ágil la búsqueda. Por ejemplo, teniendo en cuenta información local, el algoritmo po dría darse cuenta, a mitad de camino, que el camino seleccionado no es el que busca y a sí 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 ág il mal aplicada, que no p iensa 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, d epende del proyecto. Algunas ideas interesantes sobre adaptación d e 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 d esarrollo de software tiende hacia formalización y automatización d e procesos de ingeniería, que brinden la seguridad y capacidad de predicción de otras disciplinas, como la ingeniería civil. Sería de g ran importancia contar con un proceso de Arquitectura de Software capaz de acoplarse a cualquier metodología d e 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 o tros 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 d el 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 pa rte, compartir, delegar y co municar 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 a rquitectos del proyecto y, al Rol, le daremos el n ombre de Arquitecto de Aplicación. Es importante destacar que menor a bstracción n o implica, b ajo 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 a rquitecto puede ser desempeñado por cualquiera de los miembros, siempre y cuando se encuentre capacitad o. I ncluso 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, mod ificabilidad, etc). {11} Los atributos de calidad pueden estar categorizados y no deberían limitarse solamente a la calidad del prod ucto final, sino también a los requerimientos de calidad d e diseño, de código, d e 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 I nstitute (SEI ) {36} ofrece una categorización de riesgos relativos a proyectos informáticos; la misma se encuentra en {38}. Utilizando esta categorización, pueden d escubrirse 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 co n los requerimientos de disponibilid ad que el cliente espera puede significar un riesgo. I dentificar 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 co mú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 pro gramació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 o portunidad 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 h oy, 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 lo s miembros del equipo de desarrollo entienden cuando alguien d ice: ‘esto es un compo site, un delegate o un DAO’. Algunas decisiones de diseño pueden tener implicancias sobre los atributos de calidad d el 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, h asta 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, I DEs y metodología d e 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 gen erarse en él la confianza n ecesaria. De esta manera, el arquitecto po drá 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 b aterí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 d e 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 p roductividad 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 ncrementales mplemente 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, m uy posiblemente evolucione y ca mbie, pero siempre deberá respetar los requerimientos de calidad.



Busque mejorar sus habilidades constantemente. Es un buen ejercicio suponer, po r un momento, que nuestra profesión no está relacionada co n 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 d efinición de un p roceso 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 d esarrollo existente. Se buscó también, cubrir la necesidad d e que este proceso sea ágil, d e manera tal que pueda ser utilizado tanto en p rocesos á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 n ivel académico. La originalidad del planteo no sólo radica en su utilización p ara 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 I nterfaz: 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. Read ing, Mass: Addison‐Wesley? Longman, I nc. 2000. 7. Beck, Kent and Martin Fowler. Planning Extreme Programming. Reading, Mass: Addison‐Wesley? Longman, I nc. 2001. 8. Jacobson, I var; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addision‐Wesley, 1999. 9. Sommerville, I an. 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 ¿I s 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 I s The Design:http://c2.com/cgi/wiki?TheSourceCodeI sTheDesign 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 I EEE's I T 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, M ike 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?articleI d=2 33. Valerio Adrián Anacleto. Asignación ca ótica de prof esionales a proyectos. 34. Valerio Adrián Anacleto. Ch e Loco, alcánzame un Coso ó sob re ambigüedades cosométricas. http://www.epidataconsulting.com/tikiwiki/tiki‐read_article.php?articleI d=16 35. Software Engineering I nstitute (SEI ). http://www.sei.cmu.edu/ 36. http://www.sei.cmu.edu/risk/main.html 37. Brian Gallagher. Taxonomy o f operational risk. http://www.sei.cmu.edu/risk/taxonomy.pdf 38. M. Carr et all. Taxonomy based risk I dentification. SEI 1993 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?articleI d=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



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

Recommend Documents