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

5/15/2018 El rol de la arquitectura de software en las metodologías ágiles - slidepdf.com

http://slidepdf.com/reader/full/el-rol-de-la-arquitectura-de-software-en-las-metodologias-agiles 1/12

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 trabajo tiene como apo rtes: 1) Definir lineamientos para

implementar un proceso de arquitectura ágil capaz de implementarse dentro de cualquier metodología. 2) Se sientan las bases parala definición de un proceso de arquitectura ágil.

Índice

Tabla de contenidos

Índice

I ntroducción

Metodologías ágiles

¿Qué es desarrollo de software ágil (Agile Software Development)?

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

El código NO es el diseño

Aprehendiendo y tomando ideas

Las prácticas de Arquitectura de Software, el diseño y las metodologías ágiles

Definición de arquitectura

El doble rol de la arquitectura en un desarrollo de software

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

Toda decisión en ingeniería de software implica un compromiso (trade‐off)Hacia un proceso de arquitectura de software ágil

No jerarquizar el Rol

Un solo arquitecto para definir la arquitectura

Requerimientos de calidad

Usar SAAM

Requerimientos de calidad tratados como riesgos

Utilizar la categorización d e riesgos del SEI

Mantenga una ad ecuada administración de los riesgos del proyecto

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

1 de 12 3/31/2



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

Busque mejorar sus habilidades constantemente.

Aportes

Trabajo Futuro

Conclusiones

Referencias

I ntroducciónDesde 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


2 de 12 3/31/2



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}

I nteracción personal de individuos por sobre los procesos y las herramientas1.

Trabajar con el código por sobre do cumentación escrita2.

Colaboración del cliente por sobre negociación de co ntratos3.

Responder al cambio antes que seguir y mantener un p lan.4.

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

Un deseo constante de mantener el có digo tan claro y simple como sea posible.1.

Habilidades de refactoración, para que puedas confiadamente hacer mejoras cuando veas la necesidad.2.

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.

3.

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”.4.

Otra justificación, un poco menos formal, pero aún así de amplia aceptación, es la siguiente: “el código fuente es el diseño”{20}{21}. En

ésta se argumenta lo siguiente: puede verse al código fuente como el resultado final y visible del diseño, y en dónde quedan plasmados

todos los aspectos de éste. Esta idea, que es tomada de {21}, es llevada al extremo en algunas metodologías ágiles, en donde el diseño

no existe como etapa de desarrollo ni como generador de algún artefacto formal. Sólo se tiene en cuenta como algo informal, útil para


3 de 12 3/31/2



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, ladiná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 lasmetodologí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á, entreotros, 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


4 de 12 3/31/2



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


5 de 12 3/31/2



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 unacomponente á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 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 (talescomo 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 riesgosMuchos requerimientos de calidad, sobre todo aquellos que tienen que ver con la performance, la usabilidad, la carga, la disponibilidad,

etc. pueden ser tratados como riesgos. Es decir que, el hecho de que uno de ellos no se cumpla, implica un riesgo. A su vez, estos

requerimientos pueden categorizarse y administrarse de igual manera que un riesgo, utilizando una plantilla bastante simple, en la que

se detallen el impacto, el costo de mitigarlo, la probabilidad, etc. Esta misma plantilla puede ser tomada de cualquier plantilla de

administración de riesgos y deberá contar con una columna más, que indique la arquitectura seleccionada. Distintas arquitecturas

tendrán impactos diferentes sobre los requerimientos de calidad y éstos deben ser tenidos en cuenta. La plantilla realizada de esta

manera servirá como base para realizar un SAAM sobre las distintas arquitecturas candidatas.


6 de 12 3/31/2



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}


7 de 12 3/31/2



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


8 de 12 3/31/2



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 “elsistema debe tener un 99,99 de disponibilidad”, es un requerimiento testeable.

Releases I ncrementales

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


9 de 12 3/31/2



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 ambosdeberí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, sinotambién en la propuesta de varios lineamientos.

Referencias

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.

1.

Gamma E, Helm R, Johnson R, and Vlissides J, Design Patterns: Elements of Reusable Object Oriented Software, Addison‐

Wesley, 1995

2.

Fowler M. Analysis Patterns: Reusable Object Models, Addison‐Wesley?, 19973.


10 de 12 3/31/2



Fowler M, UML Distilled: Applying the Standard Object Modeling Language, Addison‐ Wesley, 1997.4.

Booch G, Jacobson I , and Rumbaugh J. The Unified Modelling Language for Object‐Oriented? Development (version 0.91)

Rational Software Corporation

5.

Beck, Kent. Extreme Programming explained. Read ing, Mass: Addison‐Wesley? Longman, I nc. 2000.6.

Beck, Kent and Martin Fowler. Planning Extreme Programming. Reading, Mass: Addison‐Wesley? Longman, I nc. 2001.7.

Jacobson, I var; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addision‐Wesley, 1999.8.

Sommerville, I an. Software Engineering. Addison Wesley. 5st ed. 1995.9.

Bass, Len. Clements, Paul. Kazman, Rick. Software Architecture in Practice. Addison Wesley. 1998.10.

Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software Architecture. Addison‐Wesley?. 1st edition 199911.

Fowler, Martin ¿I s Design Dead? http://www.programacionextrema.org/articulos/designdead.es.html . 2000.12.

http://www.june19th.com/ili/xp/index.html13.

Extreme Programming Practices, http://www.ootips.org/xp.html14.

History Of Extreme Programming, http://www.cs.wm.edu/~noonan/ExtremeProgramming

/HistoryOfExtremeProgramming.html

15.

http://www.xprogramming.com/index.htm16.

http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm17.

Manifesto for Agile Software Development: http://www.agilemanifesto.org/18.

The Source Code I s The Design:http://c2.com/cgi/wiki?TheSourceCodeI sTheDesign19.

Code as Desgin, Jack W. Reeves, 1992 http://www.developerdotstar.com/mag/articles/reeves_design_main.html20.Malan, Ruth, and Dana Bredemeyer, "Less is More with Minimalist Architecture", published in I EEE's I T Professional,

September/October 2002.

21.

Rick Kazman et all: “Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis”22.

http://www.sei.cmu.edu/publications/documents/97.reports/97tr029/97tr029title.htm23.

Extreme Programming Myths: http://c2.com/cgi/wiki?ExtremeProgrammingMyths24.

Alistair Cockburn; “The Methodology Space”: http://alistair.cockburn.us/crystal/articles/ms/methodologyspace.htm25.

Agile Modeling, http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm26.

Martin Fowler; “The New Methodology”: http://www.martinfowler.com/articles/newMethodology.html27.

Ken Schwaber, M ike Beedle. Agile Software Development with SCRUM. Paperback.28.

Stephen R Palmer, John M. Felsing. A Practical Guide to Feature‐Driven? Development (The Coad Series). Paperback29.

DSDM Consortium, Jennifer Stapleton. DSDM: Business Focused Development, Second Edition. Paperback30.

Alistair Cockburn. Crystal Clear : A Human‐Powered? Methodology for Small Teams. Paperback.31.

Valerio Adrián Anacleto: http://www.epidataconsulting.com/tikiwiki/tiki‐read_article.php?articleI d=232.

Valerio Adrián Anacleto. Asignación ca ótica de prof esionales a proyectos.33.

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

34.

Software Engineering I nstitute (SEI ). http://www.sei.cmu.edu/35.

http://www.sei.cmu.edu/risk/main.html36.

Brian Gallagher. Taxonomy o f operational risk. http://www.sei.cmu.edu/risk/taxonomy.pdf 37.

M. Carr et all. Taxonomy based risk I dentification. SEI 1993 http://www.sei.cmu.edu/publications/documents/93.reports

/93.tr.006.html

38.

Andrew Hunt, David Thomas: “The pragmatic programmer“ ‐ (Paperback)39.

Dan Pilone y Neil Pitman, “UML 2.0 in a Nutshell” ‐ First Edition June 200540.

Emilio Rasic, ”El rol de los Arquitectos de Software” ‐ http://www.epidataconsulting.com/tikiwiki/tiki‐

read_article.php?articleI d=7

41.

Eliyahu M Goldratt “The Goal” 3ra Edición.42.

Lic. Valerio Adrián Anacleto

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


11 de 12 3/31/2




12 de 12 3/31/2

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

Documents