Anexo:Arquitectura de Software (Evaluación)

Arquitectura de Software Organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. Creador Dewayne Perry y Alexander Wolf Lanzamiento inicial En 1960 Última versión estable Década de 1990

La Arquitectura de Software. Organización fundamental de un sistema encarnado en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. Factor de importancia para que el sistema tenga un alto nivel de calidad, es el centro de todo producto informático y determina cuáles serán los niveles de calidad asociados al sistema.

Introducción

La Arquitectura de Software es una práctica joven de apenas unos pocos años de trabajo constante. Tiene sus orígenes en la década de 1960, pero no fue hasta los años 90 que Dewayne Perry y Alexander Wolf, la exponen en el sentido que hoy se conoce. Esta década se consideró como la década de la arquitectura de software, según profetizaron Perry y Wolf. A partir de este momento la Arquitectura de Software comenzó a tener auge vertiginoso tanto en la academia como en la industria, desarrollándose los de estilos arquitectónicos, los ADL (Leguajes de Descripción Arquitectónica), aunque esto es algo que aún hoy está un poco virgen, entre otros. Todo esto dando al traste con la creación de diferentes tipos de arquitecturas como las basadas en componentes. No sirve de nada un sistema que no cumple con los atributos de calidad que se especificaron en los requerimientos no funcionales de los clientes. Por lo que diseñar una correcta arquitectura va a determinar el éxito o fracaso de un sistema de software, en la medida que esta cumpla o no con sus objetivos. Debido a esto “Para reducir tales riesgos, y como buena práctica de ingeniería, es recomendable realizar evaluaciones a la arquitectura”.

Conceptos sobre Arquitectura

• Arquitectura de Software: Según el estándar IEEE (Institute of Electrical and Electronics Engineers): “La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución”.

• Calidad de Software: La Calidad de Software es “la concordancia con los requisitos funcionales y de rendimiento establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado de forma profesional”.

• Componente: “Es una parte de una arquitectura de software claramente identificable, independiente a la aplicación en la que se utiliza y de otros componentes (partes), que describe y realiza funciones específicas y claras dentro del contexto de la arquitectura, puede ser modificado durante el diseño, posee una documentación clara que permite conocer sus características, atributos y comportamiento, reutilizable y su interoperabilidad con otros componentes (partes) no reduce el nivel de eficiencia de la arquitectura” .

• Escenario: Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto describe qué sucede en el sistema al momento del estímulo. La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado.

• Stakeholders: Aquellas personas que están relacionadas, de cierta forma, con el sistema, ya sea un desarrollador, usuario o gerente, etcétera.

Evaluación de Arquitectura

¿Qué es una Evaluación?

• Es un estudio de factibilidad que pretende detectar posibles riesgos, así como buscar recomendaciones para contenerlos. • La diferencia entre evaluar y verificar es que la evaluación se realiza antes de la implementación de la solución. La verificación es con el producto ya construido.

Objetivos de Evaluar Arquitecturas

El objetivo de evaluar una arquitectura es saber si puede habilitar los requerimientos, atributos de calidad y restricciones para asegurar que el sistema a ser construido cumple con las necesidades de los stakeholders.

Características de una Evaluación de Arquitectura

• Es uno de los principales puntos de evaluación dentro del proyecto, ya que errores en ella, pueden traer que el proyecto fracase. • Puede ser realizada por gente Interna o Externa al proyecto, aunque lo más interesante es que sea realizada por gente Externa (Mentores o Arquitectos del Área).

¿Por qué evaluar una Arquitectura?

“El propósito de realizar evaluaciones a la arquitectura, es para analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante, verificar que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar en qué grado se satisfacen los atributos de calidad. Cabe señalar que los requerimientos no funcionales también son llamados atributos de calidad”. Un atributo de calidad es una característica de calidad que afecta a un elemento. Donde el término “característica” se refiere a aspectos no funcionales y el termino “elemento” a componente.

• Cuanto más temprano se encuentre un problema en un proyecto de software, mejor.
• Realizar una evaluación de la arquitectura es la manera más económica de evitar desastres.
• Analizar y evaluar la calidad exigida por los usuarios.
• Decisiones de diseño

o Restricciones de Implementación. o Fija la estructura organizacional, tanto del desarrollo, construcción y ejecución del sistema. o Logra los atributos de calidad. o Permite el prototipado. o Permite estimaciones más certeras.

• Abstracción transferible entre sistemas

¿Cuándo una Arquitectura puede ser evaluada?

Es posible realizarla en cualquier momento según Kazman, pero propone dos variantes que agrupan dos etapas distintas: temprano y tarde.

• Temprana. No es necesario que la arquitectura esté completamente especificada para efectuar la evaluación, y esto abarca desde las fases tempranas de diseño y a lo largo del desarrollo.
• Tarde. Cuando ésta se encuentra establecida y la implementación se ha completado. Este es el caso general que se presenta al momento de la adquisición de un sistema ya desarrollado.

¿Quiénes participan en una Evaluación?

Generalmente las evaluaciones a la arquitectura se hacen por miembros del equipo de desarrollo, arquitecto, diseñador, entre otros. Sin embargo puede haber también situaciones en las que intervengan personas especialistas en el tema. Otro que también se interesa por los resultados de una evaluación es el cliente, ya que en dependencia de los resultados puede tomar decisiones de continuar o no con el proyecto

Técnicas de Evaluación

Existen un grupo de técnicas para evaluar que se clasifican en cualitativas y cuantitativas:

Técnicas de cuestionamiento o cualitativas. Utilizan preguntas cualitativas para preguntarle a la arquitectura

• Cuestionarios. Abiertas. Temprana
• Checklists. Especifico del Dominio de la aplicación.
• Escenarios. Especificas del Sistema. Arquitectura avanzada.

Measuring techniques. Sugiere hacerle medidas cuantitativas a la arquitectura.

• Utiliza métricas arquitectónicas, como acoplamiento, cohesividad en los módulos, profundidad en herencias, modificabilidad.
• Simulaciones, Prototipos, y Experimentos.

Por lo regular, las técnicas de evaluación cualitativas son utilizadas cuando la arquitectura está en construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada.

Beneficios de realizar una evaluación arquitectónica

• Financieros.
• Reúne a los stakeholders.
• Fuerza una articulación en las metas específicas de calidad.
• Fuerza una mejora a la documentación de la arquitectura.
• Mejora la arquitectura.
• Detección temprana de problemas.
• Valido requerimiento y los priorizo.
• Recolecta los fundamentos y las decisiones arquitectónicas tomadas.

Salidas de una evaluación arquitectónica

• Lista priorizada de los atributos de calidad requeridos para la arquitectura que está siendo evaluada.
• Riesgos y no riesgos.

Pasos Básicos para una Evaluación

• Preparación.

o Contexto. o Evaluador. o Alcance. o Representación de la Arquitectura.

• Realización.

o Presentar el problema de negocio a resolver y la arquitectura planteada. o Evalúa, el costo, la funcionalidad, los atributos de calidad. o Revisan requerimientos y posibles cambios. o Discuten problemas y observaciones.

• Generar y distribuir los resultados

o Issues y Recomendaciones. o Análisis de riesgo.

Métodos de Evaluación de Arquitecturas

• ATAM (Architecture Trade-off Analysis Method): está inspirado en tres áreas distintas: los estilos arquitectónicos, el análisis de atributos de calidad y el método de evaluación SAAM (Software Architecture Analysis Method). El nombre del método ATAM surge del hecho de que revela la forma en que una arquitectura específica satisface ciertos atributos de calidad, y provee una visión de cómo los atributos de calidad interactúan con otros.

El método se concentra en la identificación de los estilos arquitectónicos o enfoques arquitectónicos utilizados. Estos elementos representan los medios empleados por la arquitectura para alcanzar los atributos de calidad, así como también permiten describir la forma en la que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas, entre otros.

El método de evaluación ATAM comprende nueve pasos, agrupados en cuatro fases (Presentación, Investigación y Análisis, Pruebas y Reporte).

• Bosch (2000). Que plantea que: “El proceso de evaluación debe ser visto como una actividad iterativa, que forma parte del proceso de diseño, también iterativo. Una vez que la arquitectura es evaluada, pasa a una fase de transformación, asumiendo que no satisface todos los requerimientos. Luego, la arquitectura transformada es evaluada de nuevo”. Este método consta de 5 pasos divididos en dos etapas.

• ADR (Active Design Review). “ADR es utilizado para la evaluación de diseños detallados de unidades del software como los componentes o módulos. Las preguntas giran en torno a la calidad y completitud de la documentación y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseño propuesto”.

• ARID (Active Reviews for Intermediate Design). ARID es un método de bajo costo y gran beneficio, el mismo es conveniente para realizar la evaluación de diseños parciales en las etapas tempranas del desarrollo. ARID es un híbrido entre ADR y ATAM. Se basa en ensamblar el diseño de los stakeholders para articular los escenarios de usos importantes o significativos, y probar el diseño para ver si satisface los escenarios. Como resultado de la aplicación de dicho procedimiento se obtiene un diseño de alta fidelidad acompañado de una alta familiarización con el diseño de los stakeholders. Este método consta de 9 pasos agrupados en dos fases (Actividades Previas y Evaluación).

• Losavio (2003): Es un método para evaluar y comparar arquitecturas de software candidatas, que hace uso del modelo de especificación de atributos e calidad adaptado del modelo ISO/IEC 9126. La especificación de los atributos de calidad haciendo uso de un modelo basado en estándares internacionales ofrece una vista amplia y global de los atributos de calidad, tanto a usuarios como arquitectos del sistema, para efectos de la evaluación. El método contempla siete actividades.

Fuente

• Evaluando Arquitecturas de Software. Parte 1. Panorama General. Gómez, Omar Salvador Gómez. 01, México : Brainworx S.A, 2007. 1870-0888.
• Evaluando Arquitecturas de Software. Parte 2. Métodos de Evaluación. Gómez, Omar Salvador Gómez. 02, México : Brainworx S.A, 2007. 1870-0888.
• SEI (Software Ingenieering Institute). SEI (Software Ingenieering Institute). [En línea] Carnegie Mellon University. [Citado el: 21 de noviembre de 2007.] www.sei.cmu.edu/architecture/arid.html.