ARQUITECTURAS AGILES
Click here to load reader
-
Upload
silvia-rivadeneira -
Category
Documents
-
view
230 -
download
1
description
Transcript of ARQUITECTURAS AGILES
Ilustración 1. Manifiesto ágil
ARQUITECTURAS AGILES
Silvia Rivadeneira1, Gabriela Vilanova
2
Grupo de Investigación “Modelado de Requerimientos y Diseño de Sistemas Complejos”
Instituto de Tecnología Aplicada
Departamento de Ciencias Exactas y Naturales 1Unidad Académica Río Turbio,
2Unidad Académica Caleta Olivia
Universidad Nacional de la Patagonia Austral
CONTEXTO
El presente trabajo1 intenta convertirse en una
aproximación a la inserción de metodologías ágiles
en la arquitectura de software, un primer insumo a
modo de documento de trabajo en el marco del
proyecto de investigación PI 29/B176-1 denominado
“Modelado en Análisis y Diseño de Software, un
enfoque arquitectural” radicado en la Unidad
Académica Caleta Olivia (UACO) de la Universidad
Nacional de la Patagonia Austral (UNPA).
RESUMEN
Las metodologías ágiles han ido ganando bastante
popularidad en estos años, y últimamente, está
ganando más adeptos en los claustros académicos.
La comunidad ágil posee críticos y adeptos al uso de
arquitectura de software en este tipo de desarrollos.
Este trabajo intenta analizar los trabajos recientes
relacionados con esta área poco conocida en el
ambiente académico.
Palabras clave: arquitectura de software,
metodologías ágiles, proceso de desarrollo de
software
1. INTRODUCCION
En [4] establecen que la arquitectura es el conjunto
de decisiones significativas sobre la organización de
un sistema software, la selección de elementos
estructurales y sus interfaces, su comportamiento, la
composición de esos elementos estructurales y el
estilo arquitectónico que guía a la organización. Pero
también se relaciona con el uso, la funcionalidad, el
rendimiento, la capacidad de adaptación, la
reutilización, la capacidad de ser comprendido, las
restricciones económicas y tecnológicas y los
compromisos entre alternativas, así como aspectos
estéticos.
Coincidimos con [7] en que arquitectura de software
tiene que ver con la gran escala, las grandes
decisiones sobre la organización y estructura de los
elementos importantes del sistema, pero también es
parte investigación y parte trabajo de diseño, esto en
1 Financiado totalmente por la Universidad Nacional
de la Patagonia Austral, provincia de Santa Cruz,
Argentina.
UP (Unified Process) se denomina análisis
arquitectural.
Definir la arquitectura de un software de manera
temprana tiene como beneficios [1]:
Asignar tareas a los grupos de trabajo.
Facilitar la estimación.
Minimizar riesgos.
La SATI (Software Architecture Technology
Initiative) del SEI (Carnegie Mellon ® Software
Engineering Institute) viene desarrollando y
promulgando una serie de métodos centrados en
arquitectura, tales como SAAM, ATAM, QAW,
ADD, CBAM o ARID. Estos métodos predican los
axiomas que a continuación se detallan [9]:
1. Los requisitos de atributos de calidad
impulsan la arquitectura de software.
a. Los requisitos de atributos de
calidad se derivan de los objetivos
de negocio / misión.
b. Los escenarios son una poderosa
manera de caracterizar los
atributos de calidad y representar
opiniones de los interesados.
2. Las actividades centradas en la arquitectura
conducen el ciclo de vida del sistema de
software.
a. Estas actividades deben tener un
enfoque explícito en los atributos
de calidad.
b. Estas actividades deben involucrar
a los actores directamente.
El SEI trabaja integrando métodos centrados en
arquitectura en procesos populares de desarrollo de
software, tales como los ágiles [9].
A finales de los „90 surgen metodologías que
combinan ideas viejas, nuevas y variaciones de ellas,
pero con cosas en común, tales como: promover la
colaboración entre equipos de desarrollo y expertos
del negocio, privilegiar la comunicación cara a cara,
entrega frecuente de nuevas funcionalidades,
fomentar la mejora continua, equipos auto-
organizados, formas de estructurar el código con el
fin de que los requerimientos no provoquen crisis.
Ágil es un paradigma de desarrollo de software que
hace hincapié en el desarrollo rápido y flexible y
resta importancia del proyecto y la infraestructura de
proceso para su propio bien. En marzo de 2001, 17
representantes de estos cambios se reunieron,
utilizaron por primera vez el término ágil y crearon
lo que acordaron en llamar el Manifiesto por el
Desarrollo Ágil de Software [1], [3], [9], [10] (ver
Ilustración 1).
Hoy, existe una creciente discusión sobre utilizar los
términos metodologías ágiles, desarrollo ágil o
prácticas ágiles. Nosotros no nos detendremos en
esto, utilizaremos los términos indistintamente pero
en ellos englobaremos los principios y prácticas
mencionados en el Manifiesto.
Pero volvamos al desarrollo ágil, en este tipo de
desarrollo los clientes y los desarrolladores son
libres de interactuar constantemente, los proyectos
son construidos con las mejores herramientas y con
desarrolladores auto-motivados, el progreso es
medido por la cantidad de código escrito que
contribuye a la funcionalidad entregada, la agilidad
se refuerza con la excelencia técnica y el buen
diseño, simple, y, el equipo de proyecto es auto-
organizado [9], [11].
Una de las mayores críticas que sufren las
metodologías ágiles se relaciona con la carencia de
prácticas vinculadas con el diseño de software o su
falta de formalismo en la especificación, lo que,
habitualmente, se denomina “hacer todo lo posible
por hacer lo menos posible” [1], [9], [10], [11].
2. LÍNEAS DE INVESTIGACIÓN Y
DESARROLLO
Este artículo es parte del segundo proyecto de
investigación del grupo. Las líneas de investigación
que se vienen siguiendo están relacionadas con la
ingeniería de software, básicamente, las primeras
etapas en todo proceso de desarrollo de software, es
así, que nos interesa:
Modelado combinando BPMN y UML
Modelado aplicando metodologías ágiles
Integración de BPM y SOA
Arquitectura de Software
Y por otro lado, y no menos importante, nos interesa
la construcción del conocimiento en red, interesados
por las siguientes líneas de trabajo:
La interacción que se produce en entornos
colaborativos
La construcción colaborativa del
conocimiento
3. RESULTADOS OBTENIDOS/ ESPERADOS
En primera instancia, realizamos un análisis de la
bibliografía existente sobre arquitecturas ágiles, y,
en futuros trabajos buscaremos implementar algunas
prácticas en trabajos de campo, trabajos finales de
cátedra o casos reales.
Es bastante difícil encontrar trabajos académicos
relacionados con arquitectura de software en
metodologías ágiles [1] aunque se pueden encontrar
propuestas interesantes para metodologías
específicas o ideas que hacen uso de métodos
definidos por el SEI [2], [6], [11].
Autores como [1], [2] exponen la necesidad de
implementar prácticas tradicionales de Arquitectura
de Software con un enfoque ágil, en cualquier tipo
de metodologías.
Moreno [8] expresa, y nosotros acordamos, que las
bases de una arquitectura ágil deberían ser las
siguientes:
Estar orientada al negocio
Ser flexible
Ser colaborativa
No reinventar la rueda
El más claro ejemplo de la noción de diseño
arquitectural ágil es la actividad de identificar y
analizar las prioridades y dependencias entre las
historias de usuario [5].
La planificación de las iteraciones ágiles enfocada
en historias de usuario es la heurística típica
utilizada por la Comunidad Ágil, los requerimientos
deseados por los interesados son representados por
las historias de usuario y a éstas últimas se les asigna
la prioridad correspondiente según las necesidades
del usuario final [5], [10].
Es posible incorporar mejoras a la planificación de
entregas añadiendo arquitectura de software, por
ejemplo, al seleccionar las historias de usuario que
serán desarrolladas en cada iteración, el equipo debe
identificar elementos arquitecturales que deben ser
implementados para soportarlas. Algunas de las
herramientas sugeridas por [5] son:
Matriz de estructura de dependencias (DSM, Dependency Structure Matrix) que
muestra los subsistemas/actividades, la
información de intercambio y los patrones
de dependencia.
Matrices de mapeo de dominio (DMMs,
Domain Mapping Matrices) se puede usar
para representar las dependencias entre
capacidades y elementos arquitectónicos.
El análisis de opciones real, modelo de
análisis financiero que ayuda a determinar
si algún costo inicial debe ser pagado para
tener el derecho de realizar una acción en el
futuro.
La metáfora de la deuda técnica nos dice
que hacer las cosas rápidamente para un
beneficio a corto plazo nos llevará a una
deuda técnica.
Los autores [2], [13] agregan tres tácticas diferentes
para integrar el desarrollo arquitectónico incremental
al enfoque de desarrollo ágil, en este caso Scrum:
Ilustración 2. Método de arquitectura
ágil [14]
Alinear el desarrollo basado en funciones y
la descomposición del sistema.
Proporcionará flexibilidad a los equipos de
desarrollo, alineándolos en torno a historias
de usuario (función) y la descomposición
del sistema en relación a servicios comunes
y la reutilización.
Crear una ruta de arquitectura. Hacer
dependencias arquitectónicas visibles
permite su gestión y que los equipos se
alineen con ellas.
Utilizar equipos matriz. En su forma más
simple Scrum posee un único equipo
multifuncional, con habilidad, autoridad y
conocimiento necesario para especificar
requerimientos y arquitectura, diseñar,
codificar y probar el sistema. La
complejidad puede requerir replicar ese
equipo en varios equipos.
Fowler [12] enuncia que la naturaleza del diseño ha
cambiado ya que, el diseño ágil busca las siguientes
competencias o habilidades:
Un deseo constante de mantener el código
tan claro y simple como sea posible.
Habilidades de refactorización, para que
puedas confiadamente hacer mejoras
cuando veas la necesidad.
Un buen conocimiento de patrones: no sólo
las soluciones, sino también apreciar
cuándo usarlos y cuándo evolucionar hacia
ellos.
Saber cómo comunicar el diseño a la gente
que necesita entenderlo, usando código,
diagramas y, sobre todo, conversación”.
Ambler [15] esboza algunas ideas para ir en camino
a la arquitectura ágil, tales como:
No hay nada especial acerca de la
arquitectura. Todos tienen el mismo valor
en el proyecto, la humildad es un factor de
éxito.
Cuidado con las arquitecturas torre de
marfil. Aquellas diseñadas en solitario por
un arquitecto o grupo de arquitectos.
Cada sistema tiene una arquitectura.
Aunque no necesariamente hay modelos
arquitectónicos que definen esa
arquitectura.
Arquitectura ágil a escala. Mantener
estrategias en cuanto a tamaño del equipo,
cumplimiento de normas, distribución de
equipos, complejidad técnica.
Pero ¿quién es responsable por la arquitectura? En
equipos pequeños, todo el equipo. Afirman que la
arquitectura es demasiado importante para dejarla en
manos de una sola persona, pero puede volverse en
contra si son varias las personas que participan en su
elaboración [1], [15].
Meier [14] define su propio método de arquitectura
ágil en cinco pasos (ver ilustración 2):
Identificar los objetivos de la arquitectura
Identificar los escenarios clave
Crear una visión general de la aplicación
Analizar los puntos clave
Crear soluciones candidatas
Los objetivos de un arquitecto ágil según [16] son:
Entregar soluciones de trabajo.
Maximizar el valor de los interesados
(stakeholders).
Encontrar soluciones que respondan a los
objetivos de todas las partes interesadas.
Habilitar el siguiente esfuerzo.
Gestionar cambios y complejidad.
Johnston [16] establece, también, siete principios o
reglas de oro para los arquitectos ágiles:
Valorizar a la gente.
Comunicar.
Menos es más.
Planificarlo, gestionarlo.
Seleccionar la solución correcta para la
empresa.
Entregar calidad.
Modelar y documentar de manera ágil.
Luego de analizar los distintos autores a los que
tuvimos acceso podemos concluir que es factible
implementar distintas prácticas ágiles al crear una
arquitectura de software, pero que también es un
campo en el que aún no hay nada cerrado o definido.
4. FORMACION DE RECURSOS HUMANOS
Los integrantes del proyecto pertenecen en su
mayoría a la UNPA, contamos con un asesor,
académico perteneciente a Universidad de
Magallanes (UMAG), quien es profesor visitante en
la Unidad Académica Río Turbio (UART), cuyo rol
además de formar auxiliares de docencia, es preparar
e instruir jóvenes investigadores en el área de
Ingeniería de Software.
Asimismo, un par de integrantes pertenecen a la
Maestría en Educación en Entornos Virtuales y se
encuentran en trabajo de tesis, uno de los integrantes
cursa la Maestría en Informática y Sistemas; y un
último integrante ha cursado y presentado su tesina
para la Especialización en Management
Tecnológico.
Contamos, además, con un alumno de pre-grado de
la carrera Analista de Sistemas quien se encuentra
realizando el trabajo final.
5. BIBLIOGRAFIA
[1] Anacleto, V. 2008. El rol de la arquitectura de
software en las metodologías ágiles. Epidata
Consulting.
[2] Bachmann, F., Nord, R., Ozkaya, I. 2012.
Architectural Tactics to Support Rapid and
Agile Stability. CrossTalk.
[3] Beck, K. et al.: The agile manifesto.
Manifesto for Agile Software Development.
En: http://www.agilemanifesto.org
[4] Booch, G., Rumbaugh, J., Jacobson, I. 2006.
El lenguaje unificado de modelado. Pearson
Educación. Madrid.
[5] Brown, N., Nord, R., Ozkaya, I. 2010.
Enabling Agility Through Architecture.
CrossTalk.
[6] Cañadillas, D. 2010. Implantación de
arquitectura de desarrollo ágil. Universidad
Carlos III de Madrid.
[7] Larman, C. 2003. UML y patrones. Pearson
Educación. Madrid.
[8] Moreno, J. Arquitectura ágil. ORACLE.
México.
[9] Nord, R., Tomayko, J., Wojcik, R. 2004.
Integrating Software-Architecture-Centric
Methods into Extreme Programming (XP).
Technical Note CMU/SEI-2004-TN-036.
[10] Rivadeneira, S. 2013. Metodologías ágiles
enfocadas al modelado de requerimientos.
ICT-UNPA-57-2012.
[11] Urquiza, F., Martínez, A., Ibargüengoitia, G.
2010. Las metodologías ágiles y las
arquitecturas de software. CONIIS.
[12] Fowler, M. 2000. ¿Is design dead? En:
http://martinfowler.com/articles/designDead.h
tml. Consultado 01/09/2014.
[13] Ozykaya, I. 2011. Agile development and
Software Achitecture: understanding scale
and risk. SEI.
[14] Meier, J. 2008. Agile Architecture Method.
En:
http://blogs.msdn.com/b/jmeier/archive/2008/
11/06/agile-architecture-method.aspx
[15] Ambler, S. 2012. Agile Architecture:
Strategies for Scaling Agile Development.
En:
http://www.agilemodeling.com/essays/agileA
rchitecture.htm
[16] Johnston, A. Bringing Agility to Architecture,
and Architecture to Agility. Agile Architect.
En:
http://www.agilearchitect.org/agile/index.asp