: El rol de la arquitectura de software en las metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

El rol de la arquitectura de software en las metodologas giles

Por:Quirn en:Mar 27 de Dic, 2005 16:07 EST (16997 Lecturas)
El rol de la Arquitectura de Software en las metodologas giles no se encuentra lo suficientemente documentado ni formalizado a travs de un proceso acorde a la filosofa. El presente trabajo tiene como aportes: 1) Definir lineamientos para crear un proceso de arquitectura gil, capaz de implementarse dentro de cualquier metodologa. 2) Sentar las bases para la definicin de un proceso de arquitectura gil.

El rol de la arquitectura de software en las metodologas giles. Lineamientos para su implementacin Lic. Valerio Adrin 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 metodologas giles no se encuentra lo suficientemente documentado ni formalizado a travs de un proceso acorde a la filosofa. El presente trabajo tiene como aportes: 1) Definir lineamientos para implementar un proceso de arquitectura gil capaz de implementarse dentro de cualquier metodologa. 2) Se sientan las bases para la definicin de un proceso de arquitectura gil.

ndice
Tabla de contenidos
ndice I ntroduccin Metodologas giles Qu es desarrollo de software gil (Agile Software Development)? Las tcnicas de diseo en las metodologas giles El cdigo NO es el diseo Aprehendiendo y tomando ideas Las prcticas de Arquitectura de Software, el diseo y las metodologas giles Definicin de arquitectura El doble rol de la arquitectura en un desarrollo de software La arquitectura y su rol actual dentro de las metodologas giles Toda decisin en ingeniera de software implica un compromiso (tradeoff) 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 categorizacin de riesgos del SEI Mantenga una adecuada administracin de los riesgos del proyecto

1 de 12

3/31/2011 4:36 PM

: El rol de la arquitectura de software en las metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Dejar de lado la tentacin de la clarividencia (Resuelva el problema actual) Dejar de lado el mito del sentido comn 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 Slo involucrarse en las decisiones de mayor impacto arquitectnico Confianza en el equipo Testear los requerimientos de calidad Puntos de control y tests de integracin No transferir responsabilidades Realizar una arquitectura comprensible Arquitectura Simple Defina claramente los requerimientos Releases I ncrementales Busque mejorar sus habilidades constantemente. Aportes Trabajo Futuro Conclusiones Referencias

Introduccin
Desde sus comienzos a esta parte, las metodologas giles han logrado una gran conjunto de adeptos. Hoy en da, una considerable cantidad de proyectos se desarrollan siguiendo algn tipo de metodologa gil y una proporcin muy grande de las que no utilizan una metodologa gil formal, sigue, al menos, lineamientos e ideas provenientes de stas. I ncluso algunas metodologas consideradas poco giles, como RUP, ensayan nuevas aproximaciones que las hagan ver ms giles. Varios ejemplos y referencias pueden encontrarse en {28} En este contexto, la Arquitectura de Software como prctica de diseo no parece ser tratada con el detenimiento que se merece. Prueba de ello es la escasa informacin disponible sobre esta prctica en la documentacin de las distintas metodologas giles. Otro factor de influencia, es la falta de documentacin estandarizada; hoy por hoy, no existe un lenguaje DDL estndar para definir arquitecturas. Esto implica que no existe un formalismo estndar, como son los diagramas de clases de UML, para documentar arquitecturas. En estos momentos, UML an no decidi cul 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 ms riesgosos, con tareas y asignaciones distribuidas de manera incorrecta y, por sobre todas las cosas, se evidencia en la calidad final del producto

Metodologas giles
Qu es desarrollo de software gil (Agile Software Development)?
A finales de los 90, varias metodologas comenzaron a atraer la atencin del pblico en general. Cada una de estas metodologas era

2 de 12

3/31/2011 4:36 PM

: El rol de la arquitectura de software en las metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

una combinacin de ideas viejas, ideas nuevas, y variaciones de ideas viejas. Pero todas tenan algo en comn: enfatizaban la colaboracin entre equipos de programadores y expertos de negocio; promovan la comunicacin cara a cara (como una manera ms eficiente que la documentacin escrita); realizaban entregas frecuentes de nueva funcionalidad de negocio; contaban con equipos de desarrollo auto organizados; tenan maneras de estructurar cdigo fuente y equipos de desarrollo con el fin de que los requerimientos ms importantes no entren en crisis. {18} A principios de 2001, los pioneros y creadores de estas metodologas reunieron, en una figura nica, todo lo que sus metodologas tenan en comn, utilizando el trmino gil como definicin comn 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 ms importantes definidos en este manifiesto son: {18} 1. I nteraccin personal de individuos por sobre los procesos y las herramientas 2. Trabajar con el cdigo por sobre documentacin escrita 3. Colaboracin del cliente por sobre negociacin de contratos 4. Responder al cambio antes que seguir y mantener un plan. El trmino gil no describe una metodologa particular, por el contrario, expresa la existencia de una familia de metodologas, las cuales comparten las bases y lineamientos entre los que se encuentran los enumerados anteriormente. Como ejemplo de metodologa gil, podemos citar, entre muchas otras, a Scrum, ))FeatureDriven Development((, DSDM, Crystal, XP. {29, 30, 31, 32 y 6} respectivamente.

Las tcnicas de diseo en las metodologas giles

Muchas de las crticas que reciben hoy da las metodologas giles tienen relacin con la aparente carencia de prcticas relacionadas con el diseo formal de la aplicacin o, en el caso de las metodologas que contemplan el diseo, su falta de formalismo en la especificacin. {13} Esta falta de formalismo se halla justificada, para algunos de los cultores de metodologas giles, por el siguiente razonamiento: el diseo detallado lleva una inversin de tiempo considerable en decisiones y aspectos, que son inciertos hasta el momento mismo en que se presentan. {6} En otras palabras, podramos decir que, tradicionalmente, el diseo trat de anticipar al cambio, pero cuanto ms tratemos de prever el cambio, ms tiempo tomar el diseo y habr ms clases en el modelo; lo que se traduce en un modelo ms complejo para mantener actualizado, con ms lneas de cdigo, y, lo que es peor, el hecho de que, al producirse un cambio no previsto, quizs tenga que realizarse an ms trabajo que si no se hubiese diseado para el cambio. Por tal motivo, muchas de las metodologas giles proponen realizar un diseo informal, en papel si es necesario. El diseo debe ser lo ms sencillo posible. Este estilo de prcticas es parte de algo que, en metodologas giles, se conoce con el ttulo de: hacer todo lo posible por hacer lo menos posible {5}

El cdigo NO es el diseo
Debido a las fuertes crticas recibidas por la carencia de diseo formal, se han escrito algunas contrapropuestas interesantes que defienden la postura de las metodologas giles. La mayora 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 diseo? De ninguna manera, pero la naturaleza del diseo ha cambiado. El diseo gil busca las siguientes habilidades: 1. Un deseo constante de mantener el cdigo tan claro y simple como sea posible. 2. Habilidades de refactoracin, para que puedas confiadamente hacer mejoras cuando veas la necesidad. 3. Un buen conocimiento de patrones: no slo las soluciones, sino tambin apreciar cundo usarlos y cundo evolucionar hacia ellos. 4. Saber cmo comunicar el diseo a la gente que necesita entenderlo, usando cdigo, diagramas y, sobre todo, conversacin. Otra justificacin, un poco menos formal, pero an as de amplia aceptacin, es la siguiente: el cdigo fuente es el diseo{20}{21}. En sta se argumenta lo siguiente: puede verse al cdigo fuente como el resultado final y visible del diseo, y en dnde quedan plasmados todos los aspectos de ste. Esta idea, que es tomada de {21}, es llevada al extremo en algunas metodologas giles, en donde el diseo no existe como etapa de desarrollo ni como generador de algn artefacto formal. Slo 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 metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

transmitir ideas entre desarrolladores. La justificacin es que con el refactoring continuo, el buen diseo se va encontrando de a poco. Estas ideas definen la opinin sobre el diseo de muchas de las metodologas 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 histricamente el diseo.

Aprehendiendo y tomando ideas

El cdigo no es el diseo, porque solamente nos muestra una vista de ste (la vista de cdigo), mientras tambin existe, entre otras, la dinmica. Tambin hay varios modelos, por ejemplo: el de componentes, el de anlisis, el de casos de uso, etc. Decir que el cdigo fuente es el diseo es como decir que el edificio terminado es su diseo. 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 visin, debido a la carencia de abstraccin. As como ver el ala de un ave en movimiento no hace que se entienda cmo puede volar el ave, tampoco puede analizarse su estructura interna o esqueleto. Necesitamos abstraernos del ser de plumas que vuela y analizar su diseo; no se entiende la aerodinmica de las plumas, no se ve cmo estn distribuidos los msculos, no tenemos nocin del aparato circulatorio. Es decir, no tenemos vistas. Algo similar ocurre con el cdigo fuente. Si bien podemos ver la estructura interna del cdigo y extraer informacin, no podemos ver la estructura interna de los componentes que usa, as como tampoco nos es prctico extraer informacin a partir de la estructura. La abstraccin es necesaria para comprender el todo paulatinamente y de manera efectiva. Si a esto le sumamos el factor comunicacin con los stakeholders del proyecto, tema que ser abordado ms adelante, la comunicacin se vuelve an ms complicada, en vez de simplificarse. Es complejo decirle a un gerente que mire el ave en el aire para entender por qu y cmo vuela el ave. Existen posiciones extremas, en algunos casos extremistas y hasta obtusas, entre las que se encuentran: por un lado, las metodologas giles, diciendo que el cdigo fuente es el diseo y, por otro, los puristas clsicos pregonando disear pensando en el cambio. A pesar de estas posturas, rescatamos algunas ideas, las cuales sern tenidas en cuenta en lo que resta del paper. Estas ideas son: no disear tanto para el cambio y s tener en cuenta qu es necesario disear, cundo y en qu nivel de detalle, aceptar que los requerimientos cambian y manejarlo de la manera ms gil, siempre dispuesto al cambio sin reticencia utilizar el enfoque iterativo e incremental, del cual se encuentran referencias en la bibliografa desde el ao 1977 (ver {10}).

Las prcticas de Arquitectura de Software, el diseo y las metodologas giles

Denicin de arquitectura
Se tomar como definicin de Arquitectura de Software la siguiente, ya que consideramos que, en la prctica, es la ms til de las mltiples 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 definicin de una arquitectura de software de manera temprana en un proceso de desarrollo brindar, entre

otros, los siguientes beneficios:{11} Work break down: la separacin y asignacin de tareas de grupos de trabajo. Principalmente, esto se debe a que, al identificarse los componentes principales de la aplicacin, se les pueden asignar grupos de trabajo. Facilita la estimacin: permite estimar componentes y conectores por separado, teniendo en cuenta, luego, tiempos de integracin, estabilizacin, 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 mdulo, como contexto y referencia. A la vez, define los lineamientos bsicos del proyecto dando un

4 de 12

3/31/2011 4:36 PM

: El rol de la arquitectura de software en las metodologas 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 estndares de trabajo, sin una sobrecarga de burocracia. Simultneamente, lo que podra considerarse sobrecarga de burocracia, debera quedar plasmado en documentos destinados a la gerencia del proyecto. Estos documentos son requeridos por la gerencia en la mayora 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 arquitectnicos durante todo el desarrollo. Al tomar en cuenta los lineamientos de arquitectura, el diseo interno del componente puede manejarse de manera gil, dejando la especificacin 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 metodologas giles

Resulta difcil encontrar documentacin sobre cmo definir una arquitectura en un proyecto de desarrollo de software guiado por una metodologa gil. La documentacin disponible en muchos casos es sobre algunos lineamientos mnimos, como el caso de la nocin de metfora de XP {6}. Originalmente, la arquitectura no era tenida en cuenta en las metodologas giles y, si se consideraba, se lo haca 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 slo dos pginas. Con el tiempo, el rol de la arquitectura como agente previsor y de orden fue surgiendo, en varios trabajos, en metodologas giles; pero, en muchos casos, con un cierto desdn y amplia diferenciacin de lo que es en la actualidad el perfil de Arquitecto de Software.

Toda decisin en ingeniera de software implica un compromiso (tradeo)

Los enfoques metodolgicos giles pueden tender a crear una pequea 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 estimacin del mismo se vuelve catico. Podemos ilustrar esto mediante una analoga sencilla: supongamos un algoritmo que trabaja por fuerza bruta. La lgica de este algoritmo funciona de la siguiente manera: ste va a avanzar hasta descubrir una solucin; chequea si la solucin es ptima y, si no lo es, contina buscando la siguiente solucin. Por otro lado, existen algoritmos que, si bien usan fuerza bruta, le brindan informacin de contexto (local) y ofrecen visin a futuro, de manera de poder anticiparse y llegar antes al objetivo deseado para hacer ms gil la bsqueda. Por ejemplo, teniendo en cuenta informacin local, el algoritmo podra darse cuenta, a mitad de camino, que el camino seleccionado no es el que busca y as comenzar a recorrer un nuevo camino (solucin) antes de llegar al final de ese. En estos casos, si se toma demasiada informacin de contexto, pretendiendo saber demasiado sobre el futuro, el algoritmo puede ser ms lento an que el algoritmo de fuerza bruta. En la metfora 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 metodologas giles y tradicionales. El algoritmo es la metodologa a implementar. El algoritmo de fuerza bruta puro es una metodologa gil mal aplicada, que no piensa ni mira ms all del mdulo y que slo tiene en cuenta informacin local (relativa al mdulo de un equipo de personas acotado) El algoritmo que trata de ver muy a futuro es la tpica sobreespecificacin, donde se tiende cambiar la documentacin de manera continua y repetitiva, porque la misma documentacin se repite. El algoritmo de fuerza bruta con la heurstica justa es el que utiliza informacin global, local y que prev el futuro, aunque sea a corto plazo. La heurstica justa, sin duda, depende del proyecto. Algunas ideas interesantes sobre adaptacin de metodologas basadas en el tipo de proyecto se pueden encontrar en {32}. Este tema tiene relacin con la necesidad de brindar un contexto a los trabajos de ingeniera de software basado en taxonomas de proyectos. {33} Con la utilizacin de la arquitectura, buscamos definir una heurstica que debera ser adaptada segn la taxonoma del proyecto que permita agilizar an ms la metodologa en cuestin y que aporte todos los beneficios, enumerados anteriormente, de la utilizacin de prcticas 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 metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

La Arquitectura de Software puede y debe desempear un rol fundamental, en un escenario donde el desarrollo de software tiende hacia formalizacin y automatizacin de procesos de ingeniera, que brinden la seguridad y capacidad de prediccin de otras disciplinas, como la ingeniera civil. Sera de gran importancia contar con un proceso de Arquitectura de Software capaz de acoplarse a cualquier metodologa 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 prcticas tiles para ser utilizados en cualquier proceso de desarrollo de software, independientemente de la metodologa 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 slo un Rol. Este rol puede ser desempeado por cualquiera que tenga las habilidades necesarias. Habra que considerar como muy importante no darle una concepcin divina al Rol. Quien lo desempea no se encuentra en una posicin superior, en el organigrama, a ningn otro miembro del equipo.

Un solo arquitecto para denir la arquitectura

La arquitectura debe ser el producto de un arquitecto solamente, o de un pequeo grupo con un nico lder claramente identificado {11}. La arquitectura macro y en una concepcin 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 abstraccin y puede apoyarse en otros integrantes del equipo de desarrollo para tomar las decisiones. Este Rol puede ser desempeado por cualquiera de los arquitectos del proyecto y, al Rol, le daremos el nombre de Arquitecto de Aplicacin. Es importante destacar que menor abstraccin no implica, bajo ningn punto de vista, menor importancia. Tambin es interesante destacar que, en una organizacin dedicada al desarrollo de software, el rol de arquitecto puede ser desempeado por cualquiera de los miembros, siempre y cuando se encuentre capacitado. 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, modificabilidad, etc). {11} Los atributos de calidad pueden estar categorizados y no deberan limitarse solamente a la calidad del producto final, sino tambin a los requerimientos de calidad de diseo, de cdigo, de testing, de performance, etc.

Usar SAAM
Usar el Software Architecture Analysis Method {11} para analizar distintas arquitecturas candidatas es un mtodo en extremo sencillo y es muy til para comunicar ideas. Se puede usar en lugar de mtodos ms complicados, como ATAM {23}, que deberan ser tenidos en cuenta slo 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 administracin de riesgos y deber contar con una columna ms, que indique la arquitectura seleccionada. Distintas arquitecturas tendrn 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 metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

Utilizar la categorizacin de riesgos del SEI

El Software Engineering I nstitute (SEI {36} ofrece una categorizacin de riesgos relativos a proyectos informticos; la misma se ) encuentra en {38}. Utilizando esta categorizacin, pueden descubrirse riesgos no contemplados, pero tambin puede ser utilizada para identificar requerimientos de calidad. Por ejemplo, en la taxonoma, figura disponibilidad. Que la aplicacin no cumpla con los requerimientos de disponibilidad que el cliente espera puede significar un riesgo. I dentificar cul 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 administracin de los riesgos del proyecto

Existen prcticas sencillas, algunas figuran en {40}. Tambin existen varios lineamientos dentro de muchas metodologas giles. Creemos que una de las mejores fuentes sobre administracin de riesgos y que todo arquitecto debera 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 tentacin 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 da la creacin de arquitecturas de aplicacin est evolucionando hacia la especificacin de servicios y la creacin de arquitecturas transversales (SOA). Esto plantea la creacin de arquitecturas transversales a los servicios y evolutivas en s mismas. Querer predecir el futuro de la compaa y cmo ser su negocio en el mediano plazo no es tarea del arquitecto ni de los desarrolladores. Lidiar mediante la adecuada adaptacin de la arquitectura, s lo es.

Dejar de lado el mito del sentido comn

Muchas veces se justifican las decisiones de ingeniera de software bajo el halo del sentido comn. Es claro que resulta necesario el sentido comn en la vida en general, pero si bien para el fsico puede ser una cuestin de sentido comn que E = MC2, pero para la mayora de los mortales no. Sucede que el hecho de entender por qu algo es de una determinada manera no lo transforma en una cuestin de sentido comn. De igual manera, no pertenece al sentido comn la creacin de un pattern y tampoco la estimacin de proyectos es una cuestin de sentido comn (valga la redundancia); de hecho, requiri aos desde que comenz la programacin, llegar a la nocin de pattern y lograr mtodos de estimacin serios y eso no quiere decir que los ingenieros de software que precedieron a estos conceptos carecieran de sentido comn. Las sentencias que suelen ser atribuidas al sentido comn estn 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 concepcin, la arquitectura debera dar soporte al negocio y debera poder evolucionar con ste. Desde este punto de vista, el carcter evolutivo o no de una arquitectura puede verse como un requerimiento de calidad.

Armar grupos de arquitectura transversales

Puede resultar una buena prctica armar grupos de arquitectura con gente de distintos mdulos, que se desempeen en tiempo parcial, haciendo tareas de arquitectura y compartiendo su opinin 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 metodologas 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 slo aquellos ms conocidos. Hoy por hoy, es difcil ver un desarrollador que no haya ledo un libro de patterns. La comunicacin es un factor principal en un equipo que pretende utilizar una metodologa gil. Resulta importante poder subir el nivel de abstraccin 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 diseo pueden tener implicancias sobre los atributos de calidad del diseo y de la aplicacin.{35}

Utilizar ABAS
Un ABAS (AttributeBased Architectural Style){24} puede pensarse como una parte preanalizada de una arquitectura de software. Un ABAS se encuentra conformado por: (1) un Architectural Pattern (Style); (2) la descripcin de los componentes de software y sus relaciones; (3) atributos de calidad relativos a estos componentes y cmo estos se conectan; (4) un framework analtico que permita razonar sobre los atributos de calidad. La utilizacin de ABAS permite la reutilizacin de partes de arquitecturas ya definidas. Adems, permite dar una aproximacin 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 tambin facilita la comunicacin, de igual manera que hablar patterns.

Crear Tracer Bullets

En la mayora 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 metodologas, el prototipo se tira una vez validados los requerimientos. Proponemos usar aqu una aproximacin como la definida en {40}, en la cual el prototipo llamado tracer bullet sirve para afinar los requerimientos, pero tambin debe utilizarse para validar la arquitectura y realizar tests. El tracer bullet es parte de la aplicacin final, es decir que no se tira y evoluciona, hasta la forma final de la aplicacin.

Denir un leguaje de alto nivel profesional

Utilizar un lenguaje altamente profesional, mediante el conocimiento comn de las tcnicas y herramientas utilizadas por el equipo de profesionales. Esta prctica agiliza el proceso de comunicacin entre las partes. Es cierto que existe una decisin de compromiso entre el lenguaje y el aprendizaje requerido por un nuevo miembro del equipo. Puede considerarse este aprendizaje como una inversin a mediano plazo.{35}

Compartir las decisiones conictivas

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 decisin es demasiado conflictiva.

Slo involucrarse en las decisiones de mayor impacto arquitectnico

Contar o seleccionar un arquitecto que: no disipe la atencin 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 ningn lado; deje de lado las discusiones por el uso de herramientas, I DEs y metodologa de trabajo, a menos que stas tengan algn impacto en la arquitectura; se mantenga pendiente de las implicancias y validacin del uso adecuado de la arquitectura definida.

Conanza en el equipo

8 de 12

3/31/2011 4:36 PM

: El rol de la arquitectura de software en las metodologas 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 confa en l para que defina la mejor arquitectura posible dentro del contexto del proyecto. Los lazos de confianza profesional son difciles de mantener si no hay un sentimiento recproco.

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

Auditar constantemente la arquitectura y su uso har que se tengan en cuenta los nuevos requerimientos. Puede resultar bastante til y prctico definir puntos de control en los test de integracin. Cada integracin plantea la necesidad de correr la batera de test de arquitectura que valida y certifica los requerimientos de calidad.

No transferir responsabilidades
El desempeo de un profesional en un determinado rol le confiere derechos y obligaciones. El rol de arquitecto tiene la obligacin 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 tambin un medio de comunicacin y el hecho de documentar la arquitectura de manera clara, sirve como nexo entre perfiles tcnicos y no tcnicos,. Utilizar stererotypes {41} de manera conveniente, puede resultar de gran ayuda.

Arquitectura Simple
Mantenga la arquitectura lo ms 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 tambin un requerimiento de calidad.

Dena claramente los requerimientos

Defina claramente los requerimientos de calidad. La arquitectura debe poder medirse sobre la base de una especificacin 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
I mplemente releases incrementales que sean certificadas por el grupo de arquitectura. Cada release debe ser arquitecturalmente vlida. 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 metodologas 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 profesin no est relacionada con el desarrollo de software, sino con la medicina. Si tuviramos que realizar una operacin, qu mtodos, tcnicas y herramientas utilizara? Sometera a una persona a una ciruga que le produzca una cicatriz por el resto de su vida, si sta es tratable mediante alguna tcnica moderna, como por ejemplo lser? Si usted fuera el paciente, le gustara que lo opere un cirujano actualizado o esto no tendra importancia? El desarrollo de software, al igual que la medicina, es una profesin basada en el conocimiento actualizado. Las habilidades de ambos deberan medirse por su conocimiento y el buen uso de ste. Por lo tanto, es factible pensar que mantenernos en constante aprendizaje y conocer cules son nuestras debilidades para mejorarlas nos permitir desempear mejor nuestra tarea. Algunas de las buenas caractersticas personales a buscar en un arquitecto de software gil podran ser: (1) Conocer el dominio del problema a resolver (2) Ser un buen comunicador (implica saber escuchar) (3) Saber persuadir (si se tiene razn) (4) Tener habilidades de Project Manager, pero no enredarse con estas tareas en su desempeo diario (5) Pensar que siempre se puede mejorar, tanto en los aspectos tcnicos como en los humanos.{43}

Aportes
En el presente artculo, se muestra la necesidad de implementar prcticas tradicionales de Arquitectura de Software con un enfoque gil, en proyectos que implementen cualquier tipo de metodologas. Se aportan lineamientos tiles para la implementacin de las prcticas de arquitectura de manera gil. En este trabajo no se discute cmo 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 metodologa y/o proceso de desarrollo.

Trabajo Futuro
Como extensin al trabajo realizado, podemos plantear la definicin de un proceso de desarrollo y especificacin de arquitecturas de software gil que pueda implementarse en el contexto de cualquier metodologa. Muchos de los lineamientos expuestos aqu pueden ser extendidos, mostrando ejemplos de uso, contextualizndolos en un dominio de problema adecuado.

Conclusiones
En este artculo se plantea la necesidad de definir un proceso de Arquitectura de Software que sea capaz de asociarse con cualquier metodologa de desarrollo existente. Se busc tambin, 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 aproximacin a la resolucin de este problema, se plantean algunos lineamientos que deberan 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 bibliografa existente sobre el tema y algunos otros son aportes originales del presente trabajo. Todos los lineamientos propuestos estn basados en estndares aceptados del mercado o de trabajos de reconocido nivel acadmico. La originalidad del planteo no slo radica en su utilizacin para agilizar un proceso arquitectnico, sino tambin en la propuesta de varios lineamientos.

Referencias
1. Anacleto, Valerio Adrin, Amandi Analia, Marisa Bauza, Perfiles de Usuario para Agentes de I nterfaz: Un anlisis de tcnicas de aprendizaje Tesis de licenciatura. Departamento de Computacin, 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, AddisonWesley?, 1997

10 de 12

3/31/2011 4:36 PM

: El rol de la arquitectura de software en las metodologas 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 ObjectOriented? Development (version 0.91) , Rational Software Corporation 6. Beck, Kent. Extreme Programming explained. Reading, Mass: AddisonWesley? Longman, I 2000. nc. 7. Beck, Kent and Martin Fowler. Planning Extreme Programming. Reading, Mass: AddisonWesley? Longman, I 2001. nc. 8. Jacobson, I var; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. AddisionWesley, 1999. 9. Sommerville, I Software Engineering. Addison Wesley. 5st ed. 1995. an. 10. Bass, Len. Clements, Paul. Kazman, Rick. Software Architecture in Practice. Addison Wesley. 1998. 11. Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software Architecture. AddisonWesley?. 1st edition 1999 s 12. Fowler, Martin I 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 The Design:http://c2.com/cgi/wiki?TheSourceCodeI s 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 Professional, T 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 FeatureDriven? Development (The Coad Series). Paperback 30. DSDM Consortium, Jennifer Stapleton. DSDM: Business Focused Development, Second Edition. Paperback 31. Alistair Cockburn. Crystal Clear : A HumanPowered? Methodology for Small Teams. Paperback. 32. Valerio Adrin Anacleto: http://www.epidataconsulting.com/tikiwiki/tikiread_article.php?articleI d=2 33. Valerio Adrin Anacleto. Asignacin catica de profesionales a proyectos. 34. Valerio Adrin Anacleto. Che Loco, alcnzame un Coso sobre ambigedades cosomtricas. http://www.epidataconsulting.com/tikiwiki/tikiread_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 of operational risk. http://www.sei.cmu.edu/risk/taxonomy.pdf 38. M. Carr et all. Taxonomy based risk I dentification. 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?articleI d=7 42. Eliyahu M Goldratt The Goal 3ra Edicin. Lic. Valerio Adrin 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 metodologas giles

http://www.epidataconsulting.com/tikiwiki/tiki-print_article.php?articleId=28

12 de 12

3/31/2011 4:36 PM