Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria

Las Metodologı́as Ágiles y las Arquitecturas de

Software
José Fidel Urquiza Yllescas
UAM-Iztapalapa
09340 Iztapalapa, México
jose.fidel.fuy@gmail.com
Alfonso Martı́nez M. Guadalupe Ibargüengoitia G.
UAM-Iztapalapa UNAM-Facultad de Ciencias
09340 Iztapalapa, México 04360 Coyoacán, México
almm@xanum.uam.mx gig@ciencias.unam.mx

Resumen—Las metodologı́as ágiles han ganado bilidad, funcionalidad, fiabilidad y productivilidad

bastante popularidad desde hace algunos años. Si
bien son una muy buena solución para proyectos a
corto plazo, en especial, aquellos proyectos en dónde
los requerimientos están cambiando constantemente,
en proyecto a largo plazo, el aplicar metodologı́as
ágiles no dan tan buenos resultados. El diseño de
la arquitectura de software es una práctica muy
importante para el desarrollo de software. Tener una
buena arquitectura implica que nuestro sistema tiene
atributos de calidad que nos van a dar un valor muy
importante en el software. Si se definen actividades
que fomenten el uso de métodos para el desarrollo
de la arquitectura, en un proceso de desarrollo de
software, se puede obtener muchos beneficios con
respecto al producto que se desarrolla. Sin embargo,
para las metodologı́as ágiles esas actividades no se
consideran en forma importante.
En este trabajo se plantea un avance en el intento
de incluir actividades de diseño de arquitecturas de
software en metodologı́as ágiles, desde una pers-
pectiva general que, se podrı́a particularizar a las
diferentes metodologı́as ágiles.
Lo que se expone en este artı́culo es un propuesta
de tesis de la maestrı́a en Ciencias y Tecnologı́as de
la Información que se imparte en la UAM Iztapalapa
y se encuentra bajo la dirección de la M. en C. Marı́a
Guadalupe Elena Ibargüengoitia González y el M. en
C. Alfonso Martı́nez Martı́nez.
Palabras clave—Procesos de Desarrollo de Softwa-
re, Arquitectura de Software, Metodologı́as Ágiles,
Scrum, eXtreme Programming (XP), Crystal
I. I NTRODUCCI ÓN
La ingenierı́a de software juega un papel muy
importante en el desarrollo, portabilidad, manteni-
del software. La arquitectura de software es una de
las partes importantes en la ingenierı́a de software
y se refiere a la estructura o estructuras que com-
ponen un sistema, la cual comprende elementos de
software, las propiedades externamente visibles de
aquellos elementos y las relaciones entre ellos[1].
La arquitectura de software se perfila en etapas
tempranas del desarrollo y tiene un papel funda-
mental para lograr la satisfacción de los atributos
de calidad del sistema y para guiar su desarrollo,
entre otras cosas. En los últimos años, la arqui-
tectura de software ha comenzado a cobrar una
mayor importancia dentro de la investigación en la
ingenierı́a de software, por lo que se han establecido
métodos para desarrollar arquitecturas robustas y de
calidad. Sin embargo el desarrollo de la arquitectu-
ra de software es una práctica poco común dentro
de la industria, en especial si se usan metodologı́as
de desarrollo ágiles[2].
Las metodologı́as ágiles son procesos para desa-
rrollar software de manera rápida. En febrero de
2001, en una reunión que se lleva a cabo en Utah-
EEUU, nace el término “ágil”. Un proceso “ágil”
es ligero y suficiente, en consecuencia, el término
“ágil” implica ser eficaz y fácil de manejar[3].
Los desarrolladores ven con buenos ojos a las
metodologı́as de desarrollo ágil, porque constituyen
soluciones a la medida a través del proyecto que
se pretende desarrollar, en especial, los proyectos
donde los requerimientos del sistema cambian cons-
tantemente.
En un desarrollo ágil, los clientes y desarro-
 Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria
lladores son libres de interactuar constantemente.
Los proyectos son construidos con las mejores
herramientas y el progreso es medido por la canti-
dad de código escrito por los desarrolladores para
contribuir a la entrega en tiempo de una versión del
sistema.
En la literatura se han documentado varias me-
todologı́as ágiles para el desarrollo de software:
scrum[4], eXtreme programming (XP)[5] y crys-
tal[6], entre otras.
En este trabajo se analiza la posibilidad de in-
corporar métodos de diseño de arquitecturas de
software a metodologı́as ágiles a nivel general, que
después se puedan adaptar a algunas metodologı́as
particulares. Este documento está dividido de la
siguiente manera. En la sección II se hace el
planteamiento del problema y se exponen algunos
trabajos que atacan de manera particular la arquitec-
tura de software en ciertas metodologı́as ágiles. En
la sección III se describe cuál será la metodologı́a
a seguir para obtener los mejores resultados. En
la sección IV se mencionará a grandes rasgos los
resultados que se esperan obtener. Finalmente en la
sección V se dará conclusiones parciales y trabajo
a futuro.
II. P LANTEAMIENTO DEL PROBLEMA
Las metodologı́as ágiles expresan en su
manifiesto[7] que se debe de valorar a los
individuos y sus interacciones sobre los procesos
y herramientas, al software funcionando sobre
documentación extensa, la colaboración del cliente
sobre la negociación del contrato y la respuesta al
cambio sobre el seguimiento de un plan. Además
de un conjunto de 12 principios[8] que describen
el enfoque que debe regir el desarrollo de software
bajo una metodologı́a ágil.
Hay una gran variedad de metodologı́as ágiles.
Cada una tiene sus caracterı́sticas y peculiaridades.
Se puede observar que cada metodologı́a ágil ma-
neja roles muy particulares. Además en cada meto-
dologı́a se parte del supuesto de que se cuenta con
expertos técnicos e individuos muy motivados. Es
decir, cada integrante debe de tener ciertas habili-
dades para resolver desde problemas técnicos, hasta
planteamientos de aspectos abstractos y complejos,
2
por lo que la experiencia debe de ser fundamental.
Por otro lado las metodologı́as definen ciclos, que
en algunos casos incluyen varias fases, de igual
forma que en los procesos de desarrollo de software
tradicionales, por ejemplo, el Proceso Unificado
Racional (Rational Unified Process, RUP)[9]. En
las metodologı́as ágiles, también se genera docu-
mentación, sin embargo, el proceso de documen-
tación es menos rı́gido, porque por lo general se
documenta únicamente lo indispensable[10], [11].
De los aspectos que más llaman la atención de las
metodologı́as ágiles es el hecho que están abiertas a
recibir cambios en los requerimientos, sin importar,
si estos cambios tienen un impacto negativo en
la arquitectura del sistema. Sin embargo, se ha
afirmado que en las metodologı́as ágiles, el diseño
de la arquitectura de software no es una actividad
importante[12]. Es decir, carece de importancia el
diseño de la arquitectura y, por lo tanto, existe la
tendencia a no tomarlo en cuenta. Explicitamente,
no hay una fase para el diseño de la arquitectura
como en el caso de los procesos tradicionales. Esto
implica que desde el momento en que se empieza
a escribir código la arquitectura se va creando en
la medida en que se va desarrollando el proyecto.
Cómo se mencionó anteriormente, los cambios
en los requerimientos a lo largo del proyecto es
algo natural e inevitable, por lo que puede tener un
gran impacto en la arquitectura. En este sentido,
pueden surgir nuevos requerimientos que podrı́an
necesitar de una nueva arquitectura o la realización
de cambios significativos de tal manera que los
atributos de calidad que se pudiesen tener en la
arquitectura original, se pierdan.
Anteriormente se ha mencionado que las me-
todologı́as ágiles comparten entre ellas ciertas ca-
racterı́sticas. Por tal motivo, la introducción de un
modelo que pueda integrar actividades de diseño
de aquitecturas de software tendrı́a un impacto
bastante positivo en las metodologı́as ágiles, consi-
derando que el modelo que se pretende integrar no
debe de contraponerse con los valores y principios
expuestos en el manifiesto ágil[7].
Los trabajos que se han realizado para atacar
el problema de la arquitectura de software en las
metodologı́as ágiles es escaso. En este sentido, se
 Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria

pueden encontrar propuestas documentadas muy

interesantes pero que son particulares para cierta
metodologı́a, que no pueden aplicarse directamente
a otra metodologı́a ágil.
El valor que aportan estos trabajos consiste en
proponer estrategias para el diseño de una buena ar-
quitectura. Por otro lado también hacen la propuesta
de hacer uso de métodos establecidos por el Institu-
to de Ingenierı́a de Software (Software Engineering
Institute, SEI)[13] para integrar la arquitectura de
Figura 1. Estructura de scrum[4]
software con las metodologı́as ágiles.
A continuación se hace un resumen de traba-
jos en dónde se exponen soluciones para atacar en la nueva arquitectura en conjunto con la ya
el problema de la arquitecuta de software en las existente. Si esto no funciona entonces cam-
metodologı́as ágiles. biamos de la nueva arquitectura a la antigua.
II-A. Trabajos realizados Al dar una idea de cómo deseamos el di-
seño final, no siempre es necesario que todos
En esta sección se muestra una recopilación muy
los componente sean refactorizados al mismo
breve sobre los trabajos en los cuales los autores ex-
tiempo. Por otro lado, elementos constitutivos
ponen propuestas que contemplan la arquitectura de
del diseno se dividen en iteraciones, usando
software en las metodologı́as ágiles. En la reseña de
plataformas temporales cuando sea apropiado
estos trabajos se conservan los términos empleados
o necesario: proxys, interfaces, etc. Lo ante-
por la metodologı́a particular, en su documentación
rior, para vincular los componentes viejos a
en el idioma inglés.
la nueva arquitectura. Cuando todos los sis-
II-A1. Arquitectura de software y Scrum:
temas viejos hayan sido convertidos, elimina-
Scrum es un marco de trabajo para el ágil desarrollo
mos todos los componentes en las plataformas
de software. El trabajo es estructurado en ciclos que
anteriores y continuamos con la nueva[14].
se llaman sprints1 . Durante cada sprint, el equipo
selecciona los requerimientos del cliente de una II-A2. Arquitectura de software y XP: XP,
lista priorizada llamada historia de usuarios. De tal es una de las metodologı́as más conocidas y
manera que los requerimientos que se desarrollarán utilizadas[15]. Su enfoque fue desarrollado utilizan-
en primer lugar son los de muy alto valor para do prácticas reconocidas, por ejemplo, el desarrollo
el cliente. De esta manera, al final de cada sprint iterativo. XP toma siempre la participación del
se entregará un producto funcional en base a los cliente en niveles extremos. En XP los requerimien-
requerimientos que se seleccionaron de la lista tos, parte fundamental de todo programa a desarro-
priorizada. La estructura de scrum se puede ver en llar, son tomados como escenarios y se les conoce
la figura 1. como historias del usuario, que posteriormente son
Para atacar la arquitectura de software en scrum divididas en una serie de tareas.
el autor del trabajo [14], plantea llevar a cabo una En XP los programadores trabajan en parejas y
serie de estrategias en base a su experiencia. Lo que desarrollan pruebas para cada tarea, para posterior-
propone se mencione a continuación: mente generar código nuevo que debe ejecutarse
satisfactoriamente. Una vez que las pruebas son
Por un lado extender la nueva arquitectura de
superadas, el código se integran al sistema.
manera invisible y en paralelo con la arqui-
Las prácticas de XP son basadas en cuatro valo-
tectura pasada. Hacer una prueba apoyándose
res: comunicación, simplicidad, retroalimentación y
1
Iteraciones de trabajo que normalmente duran de dos a coraje. El núcleo de estos cuatro valores es imple-
cuatro semanas mentado en 12 prácticas: Planning Gamme, Pair

3
 Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria

Método Tarea prima- Prácticas XP y arte-

Programming, System Metaphor, Simple Desing, ria factos que afecta
Coding Standards, Collective Code Ownewship, QAW Ayuda a enten- Planning Game, On-
Refactoring, On-Site Customer, Test-Driven Deve- der las preocu- Site Customer, Test-
lopment, Continuos Integration, Small Release y paciones de los Driven Development,
interesados pa- User Stories
Sustainable Pace[5]. ra los requeri-
En la figura se muestra el ciclo de entrega de XP: mientos de atri-
butos de cali-
dad
ADD Para definir una Planning Game, Me-
arquitectura taphor, Refactorization,
granular Simple Desing, Archi-
tecural Spike
ATAM/CBAM Para evaluar la Planning Game, On-
arquitectura Site Customer, Refac-
toring, Release Plan
Figura 2. Ciclo de entrega de XP[16] ARID Evaluar una Continuous Integration,
porción de la Small Releases, Test-
arquitectura Driven Development
No hay una especificación de tareas para el desa-
Cuadro I
rrollo “centrado en arquitectura” en la literatura de M ÉTODOS CENTRADOS EN LA ARQUITECTURA Y
XP. Para considerar la arquitectura de software en ACTIVIDADES DE XP[17]
la metodologı́a ágil XP, los autores del trabajo [17]
proponen utilizar los siguientes métodos del SEI:
Taller de Atributos de Calidad (Quality Attribute
Workshop, QAW)[18], Diseño Guiado por Atribu-
cremental, con incrementos de no más de
tos (Attribute-Driven Desing, ADD)[19], Método
cuatro meses.
de Análisis de Compromisos Arquitecturales (Ar-
El equipo debe mantener un pre- y pos- incre-
chitecture Tradeoff Analysis Method, ATAM)[20],
mento en el taller de reflexión.
Método de Análisis Costo-Beneficio (Cost Benefits
Analysis Method, CBAM)[21] y Diseños Interme- Para abordar la arquitectura de software en la
diarios para Revisiones Activas (Active Reviews for metodologı́a crystal los autores del trabajo [11]
Intermediate Designs, ARID)[22]. En el cuadro I proponen modificar el método ATAM, de tal ma-
se presenta un resumen de cómo especı́ficamente nera que se pueda mapear para poder adaptarlo
los métodos centrados en la arquitectura propuestos en crystal. Este mapeo es crucial para asegurar
por el SEI, pueden mejorar las actividades de XP. la calidad de los productos usando metodologı́as
II-A3. Arquitectura de software y Crystal: ágiles. En la figura 3 se muestra cómo se hace
Crystal es el nombre de una familia de metodo- el mapeo y los cuadros en rojo son las fases/pasos
logı́as. Cada metodologı́a crystal tiene diferentes del método ATAM que se eliminan para poderlo
colores y cierta dureza, que corresponden al tamaño adaptar.
del proyecto y su condición crı́tica. Algunos colo-
III. M ETODOLOG ÍA
res son: Clear, Yellow, Orange, Orange Web, Red,
Magenta, Blue, y ası́ sucesivamente. En cada color, La metodologı́a propuesta para el desarrollo del
en crystal, la comunicación se centra en la gente trabajo es la siguiente:
y se ajusta para adaptarse a su entorno particular. Investigación documental acerca de métodos
El núcleo de la filosofı́a crystal es el desarrollo para el diseño de la arquitectura de software.
de software visto de manera útil como un juego Investigación documental acerca de metodo-
cooperativo de invención y comunicación. Las dos logı́as ágiles para el desarrollo de software.
reglas comunes en la familia crystal son: Investigación documental acerca de trabajos
El proyecto debe desarrollarse de manera in- de integración/prácticas/estrategias para intro-

4
 Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria

Documentación
Reutilización

Ciclos/Fases
Habilidades
Agile

Más usados
Actividades
Architect Phase 0: Partnership & Preparation (Few weeks)
Principles
Phase 1: Initial Evaluation (1 or 2
Days)
Reflective

Roles
1: Present ATAM
Workshop
XXX Carac.
2: Present Business Drivers
Osmotic XXX
Communicati
on 3: Present Architecture
Mét. XX X
4: Identify Arc. Approaches / Styles
Scrum 4 5 5 5 2 5
Information
Radiators
5: Generate Quality Atr. Utility Tree
XP 5 5 1 5 5 2 5
Crystal 5 5 2 3 5 5 3
Ambassador 6: Analyze Architectural
F
Approaches
User

Phase 2: Complete Eval. (2 Days)

Cuadro II
Early Victory C ARACTER ÍSTICAS DE LAS METODOLOG ÍAS ÁGILES .
7: Brainstorm and Prioritize Scenarios

8: Analyze Architectural Approaches

Walking
Skeleton
9: Present Results / Report Writting

Estrategias
Incremental

Roles Arq.
Re-
Architecture

Tácticas

CBAM
Phase 3: Follow Up (1 Week)

ATAM
QAW

ADD
Daily Stand
XXX
XXAsp.Arq.
Ups

Mét. XXX
X
Scrum 3 4 4
Figura 3. ATAM modificado para el modelo ágil crystal[11] XP 3 3 3 3
Crystal 3
Kanban

ducir diseño de arquitectura de software en Cuadro III

A SPECTOS ARQUITECT ÓNICOS .
metodologı́as ágiles.
Realizar tablas comparativas de metodologı́as
ágiles.
Selección de métodos para el diseño de la
arquitectura de software. V. C ONCLUSIONES Y TRABAJO A FUTURO
Selección de metodologı́as ágiles. La finalidad de este trabajo es hacer una investi-
Plantear y desarrollar un modelo genérico que gación sobre las metodologı́as ágiles y métodos que
integre diseño de arquitectura de software en se han desarrollado en años pasados para diseñar
metodologı́as ágiles, en general. arquitectura de software. De esta investigación pre-
Crear una instancia del modelo para cada tendemos integrar tácticas y estrategias de diseño
metodologı́a ágil seleccionada. de la arquitectura de software en metodologı́as
Probar las instancias de las metodologı́as se- ágiles, planteando un modelo bien definido que no
leccionadas. se contraponga, en gran medida, con los valores
y principios que son expuestos en el manifiesto
ágil[7].
IV. R ESULTADOS De esta investigación encontramos puntos ende-
blez como la carencia de artefactos reutilizables, la
Los resultados que se han obtenido en la inves- aplicación de metodologı́as ágiles a grandes pro-
tigación se ven reflejados en los cuadros II y III. yectos y, el uso de estas metodologı́as en software
Los valores están dandos de la siguiente manera: 5 complejo. También observamos que los trabajos que
Muy alto, 4 Alto, 3 Medio, 2 Bajo y 1 Muy bajo. se han realizado como los expuestos en la sección
El cuadro II, muestra varias metodologı́as ágiles II-A y, que se ven reflejados en el cuadro III,
y sus caracterı́sticas. El cuadro III, muestra una realizan el trabajo de contemplar la arquitectura de
lista de metodologı́as ágiles con los trabajos que se software, en las metodologı́as ágiles presentadas en
expusieron en las secciones II-A1, II-A2 y II-A3; este trabajo.
en los que se introducen aspectos arquitectónicos. Esta investigación será de mucha utilidad para

5
 Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria
desarrolladores practicantes de metodologı́as ágiles.
De tal manera que podrán producir un producto de
software, que tome en cuenta elementos de diseño
para la obtención de una arquitectura robusta con
atributos de calidad.
Como trabajo a futuro de la tesis, se debe
plantear y desarrollar el modelo genérico. A su
vez este modelo debe de poder ser instanciado
por metodologı́as ágiles en particular, es decir, el
modelo no será exclusivo de una metodologı́a en
particular. Además, se puede hacer un estudio de
la efectividad del modelo con una metodologı́a ágil
en particular; ası́ como dar seguimiento a proyectos
de software haciendo uso del modelo que preten-
demos proponer. En la figura 4 podemos observar
elementos que tendrá el modelo que se desarrollará.
Figura 4. Modelo a desarrollar.
R EFERENCIAS
[1] L. Bass, P. Clements, and R. Kazman, Chapter 1 The
architecture Business Cycle Software Architecture in
Practice, Second Edition, pp3. Addison-Wesley.
[2] P. Abrahamsson, M. A. Babar, and P. Kruchten, “Agility
and architecture: Can they coexist?,” IEEE Software,
vol. 27, pp. 16–22, 2010.
[3] J. Canós, P. Letelier, and C. Penadés, “Metodologı́as
Ágiles en el desarrollo de software,” 2003. Universidad
Politécnica de Valencia.
[4] K. Schwaber, Agile Project Management With Scrum.
Redmond, WA, USA: Microsoft Press, 2004.
[5] K. Beck, Extreme Programming Explained: Embrace
Change. Addison-Wesley Professional, first ed., 1999.
[6] A. Cockburn, Agile software development. Boston, MA,
USA: Addison-Wesley Longman Publishing Co., Inc.,
2002.
[7] K. Beck, J. Grenning, and R. C. Martin, “Manifes-
to for agile software development.” Internet: http://
agilemanifesto.org/ Consultado Mayo 10, 2010.
[8] K. Beck, J. Grenning, and R. C. Martin, “Manifes-
to for agile software development.” Internet: http://
agilemanifesto.org/principles.html Consultado Mayo 10,
2010.
[9] P. Kruchten, The Rational Unified Process: An Intro-
duction. Boston, MA, USA: Addison-Wesley Longman
Publishing Co., Inc., 2003.
[10] S. Ambler, “Modeling and documentation
practices on it projects survey,” July 2008.
Internet: http://www.ambysoft.com/surveys/
modelingDocumentation2008.html Consultado: Julio 7,
2010.
[11] S. Farhan, H. Tauseef, and M. A. Fahiem, “Adding agility
to architecture tradeoff analysis method for mapping
on crystal,” Software Engineering, World Congress on,
vol. 4, pp. 121–125, 2009.
[12] M. A. Babar, “An exploratory study of architectural prac-
tices and challenges in using agile software development
approaches,” in WICSA/ECSA, pp. 81–90, IEEE, 2009.
[13] S. E. Institute, “Software engineering institute.” Internet:
http://www.sei.cmu.edu Consultado: Junio, 2010.
[14] M. Isham, “Agile architecture is possible you first have
to believe!,” pp. 484 –489, 4-8 2008.
[15] S. Ambler, “Agile adoption rate survey results: March
2006,” Marzo 2006. Internet: http://www.ambysoft.
com/surveys/agileMarch2006.html Consultado: Mayo 10,
2010.
[16] I. Sommerville, Parte IV. Desarrollo. Ingenierı́a del soft-
ware, pp 364. séptima ed., 2006.
[17] R. W. Robert L. Nord, James E. Tomayko, “Integra-
ting software-architecture-centric methods into extrem-
me programming (xp),” tech. rep., Software Engineering
Institue, 2004. Technical Note CMU/SEI-2004-TN-036
September 2004.
[18] M. R. Barbacci, R. Ellison, A. J. Lattanze, J. A. Stafford,
C. B. Weinstock, and W. G. Wood, “Quality attribute
workshops (qaws), third edition,” 2003.
[19] R. Wojcik, F. Bachmann, L. Bass, P. C. Clements, P. Mer-
son, R. Nord, and W. G. Wood, “Attribute-driven design
(add), version 2.0,” tech. rep., Software Engineering
Institute, November 2006.
[20] J. D. Mcgregor, “The architecture tradeoff analysis met-
hod (atam),” tech. rep., 2004.
[21] R. Kazman, J. Asundi, M. Klein, N. L. Compton, and
L. Col, “Making architecture design decisions: An eco-
nomic approach,” 2002.
[22] P. Clements, R. Kazman, and M. Klein, Evaluating Soft-
ware Architectures: Methods and Case Studies. Addison-
Wesley, 2001.