ARQUITECTURA DE SOFTWARE ENMARCADA EN DIFERENTES METODOLOGÍAS DE DESARROLLO

CESAR AUGUSTO GIRALDO NARANJOJHONATAN DANIEL ARCILA BELTRANPABLO ESTEBAN PELÁEZ GALLEGOJHOAN SEBASTIAN LARA PUENTES

UNIVERSIDAD DEL QUINDIOFACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA DE SISTEMAS Y COMPUTACIÓNARMENIA, QUINDIO

2012

ARQUITECTURA DE SOFTWARE ENMARCADA EN DIFERENTES METODOLOGÍAS DE DESARROLLO

PABLO ESTEBAN PELÁEZ GALLEGOJHOAN SEBASTIAN LARA PUENTES

JHONATAN DANIEL ARCILA BELTRANCESAR AUGUSTO GIRALDO NARANJO

Trabajo requisito para el espacio académico Arquitectura y Diseño de Software 2012-1

Docente ING. ALEJANDRO OCAMPO SABOGAL

UNIVERSIDAD DEL QUINDIOFACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA DE SISTEMAS Y COMPUTACIÓNARMENIA, QUINDIO

2012

Contenido

ARQUITECTURA DE SOFTWARE ENMARCADA EN EL RATIONAL UNIFIED PROCESS (RUP)....................................................................................................................................4

Arquitectura Basada en Componentes.............................................................................4CONCEPTO DE ARQUITECTURA DE SOFTWARE DENTRO DE XTREME PROGRAMMING..................................................................................................................8

Taller de Atributos de Calidad (Quality Attribute Workshop o QAW)................................8Diseño Guiado por Atributos (Attribute-Driven Design o ADD).........................................9Metodo de Analisis de Compromisos Arquitecturales ( Architecture Tradeoff Analysis Method o ATAM)...............................................................................................................9Revisiones Activas para Diseños Intermedios (Active Reviews for Intermediate Designs o ARID)............................................................................................................................10SEMAT (Software Engineering Method and Theory)......................................................12LEAN Software Architecture............................................................................................12

CONCEPTO DE ARQUITECTURA DE SOFTWARE DENTRO DE SCRUM....................14OPINIÓN GRUPAL.............................................................................................................17OPORTUNIDADES DE MEJORA.......................................................................................18CONCLUSION....................................................................................................................19BIBLIOGRAFIA...................................................................................................................20

ARQUITECTURA DE SOFTWARE ENMARCADA EN EL RATIONAL UNIFIED PROCESS (RUP)

Mantiene el concepto de arquitectura tradicional, que define los requerimientos no funcionales o atributos de calidad; con unos riesgos asociados a los mismos. Se debe tener en cuenta que la arquitectura evoluciona a través del progreso en el desarrollo del software y las fases planteadas (o workflows) dentro del mismo modelo. Para la definición de la arquitectura se usa una plantilla llamada “4+1” ilustrada en la siguiente imagen:

Tomada de Rational Unified Process

Arquitectura Basada en Componentes

El RUP tiende a ser muy complejo y robusto a la hora de su arquitectura ejecutable; al decir que la arquitectura está basada en componentes se refiere a que tiene gran resistencia a cambios posteriores gracias al gran uso de interfaces definidas, en la que tendrá una arquitectura altamente comprensible y que estará derivada a partir de los casos de uso que se consideren mas importantes. Dados los sistemas de software de la actualidad, no es posible hacer de manera secuencial la definición total del problema y la arquitectura en componentes, diseñar la solución completa, construir el software y por último probarlo; así como el descubrir defectos en fases posteriores de diseño que darán como resultado un aumento en los costos o la cancelación de los proyectos debido al alto riesgo de este tipo de proyectos.

Para eso entonces el RUP viene basado en un sistema de iteraciones donde se pretende aumentar la calidad del software y así mismo encontrar errores ya implementados previamente.

Encontramos las siguientes características en base a un sistema iterativo:

● Buena retroalimentación al usuario● El equipo se concentra en dar buenos resultados● Se permite un incremento del problema tanto de negocio como técnico a través de

las mejoras incorporadas.

El RUP entonces puede a través de su arquitectura y un modelamiento visual capturar la estructura y comportamiento de arquitecturas y componentes, mostrar cómo pueden encajar de forma conjunta los elementos del sistema, mantener la consistencia entre un diseño y su implementación y promover una comunicación no ambigua.

Tomadas de Rational Unified Process

Arquitectura y procesos de Desarrollo

En el Rational Unified Process se produce:

● Fase de Inicio: Con respecto a la arquitectura, en la fase de inicio de los proyectos se establece:

- Requerimientos no-funcionales - Lista de riesgos y restricciones

- Arquitectura inicial

● Fase de Elaboración: Con respecto a la arquitectura, en la fase de elaboración se establece:

- Arquitectura línea base - Arquitectura de Referencia - Documento de Descripción de arquitectura (SAD): * Subsistemas * Componentes * Arquitectura Runtime

● Entregables: - Documento de Definición de Arquitectura. - Prototipo evolutivo de arquitectura.

- Guías y Estándares de Diseño.

CONCEPTO DE ARQUITECTURA DE SOFTWARE DENTRO DE XTREME PROGRAMMING

Dentro de XP no existe un modelo que permita la creación de una arquitectura de software valida; pero considera la utilización de la llamada “Metáfora del Sistema” para incluir atributos o consideraciones dentro del proyecto que revelen cierto grado de importancia dentro del desarrollo tales como funcionalidades descritas; y que puedan ser entendidos ampliamente entre el equipo de desarrollo y los clientes por igual; tanto así a poder afirmar que dicha metáfora abarca una concepción “minimalista” de lo que normalmente se conoce como arquitectura.

Posiblemente este marco podría verse un poco transgresor para los más “puristas” dado que el entendimiento por medio de un modelo más descrito y más complejo afronta un pequeño juego de palabras que podría verse como exageradamente simple dentro de un desarrollo serio, pero gracias a eso y por fortuna de los desarrolladores regidos bajo principios de XP, existen ciertos métodos establecidos por el SEI que acompañan el procedimiento de construcción de la arquitectura de software desde su concepción hasta su posterior evaluación, así:

Taller de Atributos de Calidad (Quality Attribute Workshop o QAW)

Este método pretende determinar qué elementos dentro de los atributos de calidad son críticos o de vital importancia dentro del sistema a construir, buscando con esto evitar la construcción de elementos innecesarios y por ello perdida de dinero. En el transcurso de su ejecución busca responder los siguientes interrogantes:

● ¿Cómo puedo determinar que requerimientos de calidad son importantes antes de que un sistema sea construido?

● ¿Cómo puedo identificar las necesidades y expectativas de los “stakeholders” de una manera organizada y efectiva?

● ¿Cómo puedo mejorar e incrementar la comunicación entre los “stakeholders”?

Diseño Guiado por Atributos (Attribute-Driven Design o ADD)

La inclusión de este método busca definir una arquitectura, basándose en una intensiva descomposición de componentes que permita evidenciar de una manera muy fina y objetiva los atributos de calidad clave dentro del sistema a construir. Busca responder los siguientes interrogantes:

● ¿Como puedo diseñar la arquitectura de un sistema de modo que satisfaga de la mejor manera las necesidades de los usuarios?

● ¿Como puedo cumplir con los requisitos basados en atributos de calidad para un sistema previsto?

● ¿Como puedo determinar que estrategias arquitecturales son apropiadas o relacionadas con los atributos de calidad requeridos?

● ¿Como puedo entender el impacto que implica las ventajas y desventajas de cada atributo de calidad; dentro del diseño de una arquitectura de software?

Metodo de Analisis de Compromisos Arquitecturales ( Architecture Tradeoff Analysis Method o ATAM)

Pretende evaluar una arquitectura en base a unas metas establecidas respecto a los atributos de calidad identificados, donde no sólo se verifica el grado de cumplimiento de

dichas metas sino también el grado de cohesión entre los atributos (que tan bien relacionados están) y como se afectan entre sí. Para efectuar una buena evaluación se debe tener claro algunos aspectos como:

● ¿Cuál es la función exacta de cada uno de los atributos de calidad en el sistema?● ¿El sistema puede ser analizado para determinar los atributos de calidad

deseados?● ¿Cuál es el momento para efectuar un análisis de ese tipo?● ¿Cómo podría saber si una arquitectura de software definida es precisa y

adecuada sin necesidad de haber construido previamente el sistema?

La siguiente imagen aclara los conceptos anteriores

Tomada de http :// www . sei . cmu . edu / architecture / tools / evaluate / atam . cfm

Como se pudo evidenciar, dentro del analisis entra tanto los atributos de calidad identificados dentro del diseño de la arquitectura, como las aproximaciones a la misma; para determinar situaciones de potencial riesgo que impliquen una distorsion hacia la construccion de la arquitectura del software.

Revisiones Activas para Diseños Intermedios (Active Reviews for Intermediate Designs o ARID)

Este método pretende la evaluación de unas pequeñas porciones de la arquitectura diseñada, con el fin de asegurar la idoneidad de lo construido. Dicha evaluación se efectúa de acuerdo a unos escenarios planteados, donde se debe contar con una

participación activa y constante de los “stakeholders”, donde se debe justificar la inversión que se haría en el proyecto. Es importante tener en cuenta los siguientes aspectos:

● ¿Como determinar si el diseño de arquitectura esta en capacidad de justificar lo que constituye?

● ¿Como se debería revelar el diseño de la arquitectura al equipo de trabajo del proyecto que necesita cumplir con sus labores?

● ¿De que manera se deberían involucrar los “stakeholders” para poder efectuar el compromiso de compra del software?

● ¿Como se podría determinar que los servicios diseñados para que un elemento de la arquitectura preste, sean los correctos?

● ¿Como se podría asegurar la calidad y el detalle en los diseños elaborados?

Históricamente, XP ha intentado abordar la mayor cantidad de situaciones de contexto de los proyectos, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Ésta metodología ágil ofrece una solución a nivel de arquitectura casi a la medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo.

Obviamente se puede hablar entonces de estándares de programación, participación activa del cliente en los proyectos, máximo de trabajo por horas, integración de código en el sistema una vez que esté listo para tener un proceso de funcionalidades disciplinado y automatizado con un equipo de desarrollo, está más preparado para modificar el código cuando sea necesario, debido a la confianza en la identificación y corrección de los errores de integración (integración continua), una programación en parejas, una actividad constante de reestructuración del código con el objetivo mejorar su legibilidad, simplificarlo, hacerlo más flexible para facilitar los posteriores cambios y remover la duplicación de código; también podemos hablar de producción rápida de versiones del sistema y pruebas unitarias establecidas antes de escribir el código y ejecutadas constantemente ante cada modificación del sistema.

La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas por ingeniería del software para el uso el buen uso en las estructuras de arquitectura de los proyectos. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

SEMAT (Software Engineering Method and Theory)

Actualmente, existe una tendencia impulsada por varios personajes importantes en la fundamentación de la ingeniería de software la cual busca redefinir el proceso actual de la ingeniería de software, dicha tendencia es conocida como SEMAT, y se argumenta que la actual ingeniería de software se encuentra impedida por las malas practicas en todo su proceso ingenieril.

El objetivo de SEMAT es identificar y describir los elementos que son esenciales para todas las actividades de la ingeniería de software, centrándose en áreas como el trabajo en equipo, la gestión de proyectos y la mejora de procesos, además de integrar los conceptos actuales con otros conceptos de otras disciplinas de ingeniería con el fin de construir un proceso mas adaptable y flexible a los cambios, es decir, incorporar procesos de metodologías ágiles.

LEAN Software Architecture

Otro referente importante a la hora de hablar de arquitectura de software en la actualidad es el LEAN Software Architecture, el cual plantea que las arquitecturas ágiles no son arquitecturas débiles en un proyecto software.

Una buena arquitectura definida de forma ágil, siguiendo los principios planteados por LEAN, permiten trabajar con un mayor acercamiento con el usuario final, el modelo mental del usuario final, los requerimientos acoplados con la arquitectura del sistema, y lograr una trazabilidad adecuada hasta en el código real.

CONCEPTO DE ARQUITECTURA DE SOFTWARE DENTRO DE SCRUM

Como metodología desarrollo, sabemos que SCRUM es muy simple. El decir que es simple no refiere a trabajo fácil, por el contrario, se requiere de un gran trabajo porque se basa en la adaptación a las circunstancias de la evolución de un proyecto, se orienta más a personas que a los procesos empleando una estructura de desarrollo ágil incremental basada en iteraciones y revisiones.Se empieza por analizar el producto, especificando funcionalidades o componentes que tienen mayor prioridad de desarrollo y que se pueden llevar a cabo en un breve periodo (30 días normalmente).Cada uno de estos periodos de desarrollo es una iteración que aporta al incremento funcional del producto y son la base del desarrollo ágil, diariamente todo el equipo hace reuniones y revisa el trabajo realizado el día anterior y el que se viene para el día siguiente.

Al terminar cada iteración del proyecto se hace una revisión con todas las personas implicadas en el proyecto y sí el proyecto tuviera un desviamiento, este sería el momento justo de abarcarlo. Aquí encontramos una ventaja de esta metodología frente a las más

robustas como RUP, en donde no tenemos un plan establecido sino que trabajamos en la evolución del producto conforme los días pasan.

Para atacar la arquitectura de software en Scrum, se ha sugerido llevar a cabo una serie de estrategias. Interpretando lo propuesto por Mago & Alferez (2011); se debería adicionar un Sprint inicial llamado “Sprint 0″ al inicio del ciclo de desarrollo. El objetivo principal del arquitecto en el Sprint radica en llevar a cabo el análisis y diseño del sistema desde su punto de abstracción mas alto,. Un punto clave es reutilizar artefactos de software creados a partir de la arquitectura para ser más ágiles en el desarrollo de productos específicos

En el Sprint 0 como en cualquier otro Sprint de SCRUM se construye la arquitectura de forma iterativa mediante un previo análisis de los drivers de arquitectura (elementos que estén acordes a los elementos mas críticos de la estrategia de negocio), acompañado de un estudio de factibilidad del proyecto. Para poder pasar a la primera iteración del proyecto no es necesario concluir en totalidad con el diseño de la arquitectura

Para determinar los drivers de arquitectura, se debe identificar los objetivos del negocio de más alta prioridad, que deberían ser pocos. Estos objetivos del negocio se convierten en los escenarios de calidad o casos de uso. De esta lista, se deben escoger los que tendrán un mayor impacto sobre la arquitectura. El diseño arquitectónico puede comenzar una vez que se encuentran definidos los conductores arquitectónicos. El proceso de análisis de requisitos será entonces influenciado por las preguntas generadas durante el diseño arquitectónico.

El resultado del Sprint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attribute Driver Design) anteriormente definido en Xtreme Programming.

El documento inicial de la arquitectura se debe evaluar con el fin de saber que la arquitectura cumple con los requisitos de calidad. Para realizar esta evaluación, se propone el método ATAM (Architecture Tradeoff Analysis Method). Como ya es conocido ATAM revela cuán bien una arquitectura satisface los objetivos particulares de calidad y provee una aproximación de cómo los atributos de calidad interactúan.

Si la evaluación de la arquitectura se encuentra que se deben realizar cambios a la misma, entonces ésta se debe refinar hasta llegar a tener como resultado del Sprint 0 el documento público de la arquitectura junto con el sistema esqueleto. Finalmente, la arquitectura creada en el Sprint 0 beneficiará el desarrollo en los siguientes Sprints.

Igualmente, para los cambios existe un procedimiento. Basandonos en lo establecido por Isham (2008), el mismo propone que en el momento para el cual exista una necesidad de

cambio (priorización o cambio de atributos de calidad) se debe proceder con las siguientes directrices:

● Se debería extender la nueva arquitectura de manera invisible y en paralelo con la arquitectura pasada. Hacer una prueba apoyandose la nueva arquitectura en conjunto con la ya existente. Si esto no funciona entonces cambiamos de la nueva arquitectura a la antigua. Esto con el fin de asegurar la consistencia del diseño sin desechar un punto seguro o “Checkpoint”.

● Al dar una idea de como deseamos el diseño final, no siempre es necesario que todos los componentes sean refactorizados al mismo tiempo. Por otro lado, los elementos constitutivos del diseño se dividen en iteraciones, para brindar una perspectiva mas cerrada y evitar errores que podrían provocar un procedimiento mas global; proporcionando sustitutos de componentes de la arquitectura anterior hacia la nueva, esto con el fin de no desechar componentes valiosos en caso de tener que volver a un punto anterior . En pocas palabras la nueva arquitectura estaría hecha de componentes de la arquitectura vieja con algunas mejoras. Cuando todos los sistemas viejos hayan sido convertidos y consideremos que no existen elementos de valor en la “vieja arquitectura” se desecha y se toma como referencia la nueva arquitectura.

OPINIÓN GRUPAL

Como lo podemos notar, actualmente el mundo agilista esta tomando cada vez mayor fuerza y ventaja sobre el desarrollo clásico de aplicaciones software. La complejidad va cada vez mas en declive y la incorporación de nuevas y mejores practicas en la industria software hacen que cada vez se rompa más el mito de un proceso de desarrollo complejo y por ende, una arquitectura demasiado robusta y ambigua, la cual ya no se debe enmarcar en un documento misterioso y apartado al conocimiento de mismo por parte de todo el equipo del proyecto y los clientes.

Analizando las metodologías planteadas anteriormente, y sus notables mejoras al proceso de la construcción de la arquitectura de una aplicación, nos llama mucho la atención la forma en XP (Xtreme Programing) aborda el levantamiento de la arquitectura y su flexibilidad para múltiples tipos de proyectos, permitiendo la verificación de la mejor solución arquitectural para proyectos específicos y su devolución con respecto al avance del proyecto.

Una aspecto muy importante analizado en otra metodología, específicamente en SCRUM, es el énfasis hecho en las labores de acompañamiento del arquitecto o grupo de arquitectos en el proyecto, no solo en la parte de diseño y definición de la arquitectura, sino también involucrados en la parte inicial, validando requerimientos y los alcances del mismo; y en la parte de implementación, brindando constante asesoría al equipo desarrollador, con el fin de que todo el grupo hable el mismo idioma en pro de la arquitectura del proyecto y de los drivers de negocio definidos en ella.

Claro esta que no existe una metodología universal que cobije todos los proyectos software de diferentes tipos y tamaños, la cual oriente y de los pasos necesarios para definir una arquitectura óptima de la solución. Pero la unión de varios aspectos de las metodologías existentes y la utilización de mejores practicas en todo el proceso nos brindaran mayor seguridad para lograr un buen objetivo, acompañado del factor mas importante en estos casos: la experiencia del equipo de trabajo, especialmente de los arquitectos y sus colaboradores inmediatos.

OPORTUNIDADES DE MEJORA

Una gran oportunidad de mejora para los proyectos de software actuales y futuros con respecto a la arquitectura de la solución, es el fortalecimiento del rol de arquitecto dentro de cada proyecto, el acompañamiento con el gerente del proyecto, con el mismo cliente y con todos los coordinadores de los equipos de desarrollo.

Es de vital importancia que todo el personal involucrado y afectado con los proyectos, tengan conocimiento de los drivers de negocio y las restricciones definidas en la arquitectura y de como deben y no deben proceder para velar por dichos intereses. Para este fin, seria interesante programar reuniones para socializar la arquitectura inicial con todos los participantes del proyecto, explicando muy bien cada concepto y objetivo definido; la idea principal de dicha socialización es informar a todo el equipo, además de conocer la opinión de todo el grupo acerca de lo que se ha definido y analizar dichas experiencias para mejorar o adaptar la arquitectura planteada.

La relación entre el gerente del proyecto y el grupo de arquitectos no debe limitarse simplemente a la entrega de informes periódicos, que se conviertan en un documento mas. El gerente debe preocuparse por la labor de sus arquitectos y trabajar continuamente, para tomar decisiones administrativas adecuadas de acuerdo a las especificaciones técnicas definidas por los arquitectos a lo largo del proyecto.

CONCLUSION

Sin duda alguna, las metodologías ágiles son la mejor opción para el desarrollo de software moderno, sin dejarnos llevar por el impulso facilísta, ser ágil, no significa no llevar un control y seguimiento adecuado del proyecto ni carecer de documentación; significa simplificar el proceso riguroso en algo practico y verdaderamente útil para el proyecto, enfocándose en lo verdaderamente importante sin descuidar los demás aspectos generales del proyecto.

La ingeniería del software en un área en constante evolución, y por lo tanto las metodologías de desarrollo también están predispuestas a continuos cambios para adaptarse a las necesidades del cliente moderno. Gracias a dichos cambios, se ha logrado abrir brecha a un nuevo horizonte en la definición de modelos de procesos, impulsado inclusive por grandes exponentes de la ingenieria de software clásica, quienes han analizado las necesidades actuales y han manifestado la urgencia de redefinir el proceso que se ha venido llevando a cabo en los últimos años.

BIBLIOGRAFIA

Isham, M. (2008). Agile architecture is possible you first have to believe! Mago, E., & Alférez, G. (2011). El Papel de la Arquitectura de Software en

Scrum, ¿Como Incorporarla? Urquiza, J., Martinez, A., & Ibarguengoitia, G. (2011). Las Metodologias

Agiles y la Arquitectura de Software. IBM Rational. (1998). Rational Unified Process