Evaluación Arquitectónica

Generalidades

Objetivos

Importancia

Técnicas de evaluación

Generalidades

Evaluar Verificar

La diferencia entre ambos es que la evaluación se realiza antes de la implantación mientras que la verificación es sobre el software ya construido

Pueden ser usados los términos evaluar y

verificar como sinónimos?

La evaluación arquitectónica demuestra si la decisiones estilos y patrones impactan positivamente los atributos de calidad del sistema.

Objetivos

Verificar que el software cumpla con los atributos de calidad y

restricciones planteadas por los colaboradores.

El arquitecto de software puede aplicar cualquiera de las

técnicas existentes, obteniendo objetivos, cualitativos,

cuantitativos y máximos y mínimos teóricos.

Objetivos

Medición Cualitativa

• Compara la arquitectura candidata para saber cual se adapta al atributo de calidad

Medición Cuantitativa

• Genera valores para tomar decisiones en cuanto a los atributos de calidad

Medición de Máximo y Mínimo Teórico

• Establece de manera clara el grado en que se cumplen los atributos de calidad

Mediciones sobre la Arquitectura del Software

Objetivos

Kazman• Propone un esquema general con

respecto a sus atributos de calidad, para determinar los riesgos de la arquitectura.

• Su enfoque se orienta hacia la mitigación de riesgos de los atributos de calidad que se puedenafectar por decisionesarquitectónicas .

• Presenta los metodos de evaluacion de: • ATAM Metodo de Analisis de

Acuerdos de Arquitectura• SAAM Metodo de Analisis de

Arquitectura de Software• ARID Evaluacion temprana de los

disenos de una arquitectura de software

Bosch

• Plantea la evaluación explícita de los atributos de calidad de la arquitectura durante el proceso de diseño.

• Considera las técnicas de evaluación: • Basada en escenarios

• Basada en simulación

• Basada en modelos matemáticos

• Basada en experiencia

Importancia

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

• Detectar problemas en un proyecto de software de manera prematura, para evitar desastres.

• Analizar y evaluar la calidad exigida por los usuarios.

Importancia

Según Kazman, el software puede evaluarse:

Temprano (Fases de Diseño y Desarrollo)

Tarde (Se aplica en software adquirido e implementado)

La evaluación de la arquitectura del software se puede realizar por:

Personas relacionadas (desarrolladores, diseñadores, arquitectos, clientes).

Personas Externas (Especialistas en el área)

Técnicas de Evaluación

Técnicas de Evaluación

Cualitativas

• Aplicada cuando la arquitectura está en proceso de construcción

Cuantitativas

• Solo se usa cuando la arquitectura está implantada

• Bosch(2000)

• Basada en Escenarios

• Basada en Simulación

• Basada en Modelos Matemáticos

• Basada en Experiencia

Técnicas de Evaluación

Atributos de Calidad, según BassAtributo de Calidad Descripción

Disponibilidad Es la medida de disponibilidad del sistema para el uso (Barbacci et al, 1995).

Confidencialidad Es la ausencia de acceso no autorizado a la información (Barbacci et al, 1995).

Funcionalidad Habilidad del sistema para realizar el trabajo para el cual fue concebido (Kazman

et al., 2001).

Desempeño Es el grado en el cual un sistema o componente cumple con sus funciones

designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o

uso de memoria. (IEEE 610.12).

Confiabilidad Es la medida de la habilidad de un sistema a mantenerse operativo a lo largo del

tiempo (Barbacci et al., 1995).

Seguridad externa Ausencia de consecuencias catastróficas en el ambiente. Es la medida de ausencia

de errores que generan pérdidas de información (Barbacci et al, 1995).

Seguridad interna Es la medida de la habilidad del sistema para resistir a intentos de uso no

autorizados y negación del servicio, mientras se sirve a usuarios legítimos

(Kazman et al., 2001).

Atributos de calidad observables vía ejecución

Atributo de Calidad Descripción

Configurabilidad Posibilidad que se otorga a un usuario experto a realizar ciertos cambios al sistema (Bosch et al., 1999).

Integrabilidad Es la medida en que trabajan correctamente componentes del sistema que fueron desarrollados

separadamente al ser integrados. (Bass et al. 1998)

Integridad Es la ausencia de alteraciones inapropiadas de la información (Barbacci et

al., 1995).

Interoperabilidad Es la medida de la habilidad de que un grupo de partes del sistema trabajen con otro sistema. Es un tipo

especial de integrabilidad (Bass et al. 1998)

Modificabilidad Es la habilidad de realizar cambios futuros al sistema. (Bosch et al. 1999).

Mantenibilidad Es la capacidad de someter a un sistema a reparaciones y evolución

(Barbacci et al., 1995). Capacidad de modificar el sistema de manera rápida y a bajo costo (Bosch et al. 1999).

Portabilidad Es la habilidad del sistema para ser ejecutado en diferentes ambientes de computación. Estos ambientes

pueden ser hardware, software o una combinación de los dos (Kazman et al., 2001).

Reusabilidad Es la capacidad de diseñar un sistema de forma tal que su estructura o parte de sus componentes puedan ser

reutilizados en futuras aplicaciones (Bass et al. 1998).

Escalabilidad Es el grado con el que se pueden ampliar el diseño arquitectónico, de datos o procedimental (Pressman, 2002).

Capacidad de

Prueba

Es la medida de la facilidad con la que el software, al ser sometido a una serie de pruebas, puede demostrar

sus fallas. Es la probabilidad de que, asumiendo que tiene al menos una falla, el software fallará en su próxima

ejecución de prueba (Bass et al. 1998).

Atributos de calidad no observables vía ejecución

Atributos de Calidad, según Bass

Evaluación Basada en Escenarios

• Un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema. Kazman (2001)

Estimulo

Contexto

Respuesta

•Describe lo que el involucrado hace para interactuar con el sistema. Tareas, configuración, pruebas.

•Describe lo ocurrido en el sistema posterior al estimulo

•Describe de acuerdo a la arquitectura como debería responder el sistema posterior al estimulo, establece el atributo de calidad asociado.

Partes del EscenarioFuente: Kazman (2001)

• Los escenarios permiten concretar y entender los atributos de calidad presentes en un software.

• Su aplicación trae ventajas:

Simples de crear y entender

Bajo en costos

No es necesario capacitación para su aplicación

Resultados efectivos

Las técnicas basadas en escenario se apoyan en los instrumentos:

Utility Tree. Kazman (2001)

Profiles. Bosch (2000)

Evaluación Basada en Escenarios

• Es un esquema en forma de árbol que presenta los atributos de calidad de un sistema de software, refinados hasta el establecimiento de escenarios que especifican a detalle el nivel de prioridad de cada uno.

• Identifica los atributos de calidad que destacan en una arquitectura, estos son planteados por los involucrados en el desarrollo.

• Tiene un nodo raiz que es la utilidad general del sistema, el segundo nivel son los atributos de calidad que contiene una serie de escenarios, señalando la escala de importancia y dificultad asociada.

Evaluación Basada en Escenarios: Utility Tree

Nombre del Motivador

de Negocio

Descripción del Motivador de Negocio

MN_004

Mejorar tiempos de atención a

clientes internos y externos.

Mejorar tiempos de atención en un 60% mediante la

optimización de las herramientas administrativas del

ministerio.

Medida del Impacto

Reducción del tiempo de respuesta medido en el porcentaje de tiempo reducido en comparación con el

tiempo medio actual de respuesta.

Rangos Cota Mínima Cota Máxima

Ninguno 0 10

Bajo 11 20

Moderado 21 40

Fuerte 41 50

Muy Fuerte 51 60

Asociación del Motivador con

el Negocio

Definido Por: Dirección administrativa de recursos

de telecomunicaciones

Ejecutado Por: Dirección administrativa de recursos

de telecomunicaciones

Ubicación en el

Portafolio del negocio

Atención al ciudadano

Identificación de Motivadores de negocio

Mejorar tiempos de atención a clientes internos y externos

EficienciaTiempo de respuesta

Retorno ágil de resultados

Capacidad Concurrencia

Atención a usuarios

simultáneos

Fiabilidad

Tolerancia a fallas

Continuación de ejecución en caso de falla

Recuperabilidad Agilidad en recuperación a fallos

Disponbilidad Operacionalidadcontinua

Evaluación Basada en Escenarios: Utility Tree

Árbol de Utilidad para MN_004

Atributo de Calidad: Fiabilidad

Tolerancia a Fallas ID Descripción Prioridad

MN_004 AC_FIA_001 Habilidad del sistema para manejar los fallos en

procesamiento de información y continuar con la

ejecución.

AC_FIA_002 Habilidad del sistema para asegurar la consistencia

de la información en operaciones transaccionales

Recuperabilidad

MN_004 AC_FIA_003 Habilidad del sistema para recuperarse ágilmente a

fallos

Disponibilidad

MN_004 AC_FIA_004 Habilidad del sistema en línea para ser operacional

de modo continuo.

Atributo de Calidad - Fiabilidad

Evaluación Basada en Escenarios: Utility Tree

Escenario de Calidad

# EC_006 Stakeholder:

Atributo de Calidad AC_EFI_001 – Eficiencia

Justificación Aumentar satisfacción del cliente reduciendo tiempos de atención

Fuente Usuario

Estímulo Radicación de solicitudes

Artefacto Dirección de Administración de Recursos de Comunicación (DARC)

Ambiente Bajo operación normal

Respuesta Solicitud radicada en el sistema

Medida de la

RespuestaRespuesta de radicación inferior a 1 minuto

Evaluación Basada en Escenarios: Utility Tree

Escenario de Calidad - Eficiencia

Título del Escenario Operacional

Registro y estudio de Solicitud

Stakeholder Asociado Director DARC ID EO-01Consideración Operacional Respuesta del Stakeholder

Descripción general de la

funcionalidad

Describe la administración de los servicios del control de las concesiones y actividades de

los servicios de telecomunicaciones con la finalidad de habilitar, vigilar y controlar el

espectro radioeléctrico y los otros recursos.

Describa lo que el Stakeholder hace

ahora o le gustaría poder hacer

Lo esperado por el Stakeholder es poder llevar a cabo el seguimiento y control de las

solicitudes.

Describa cualquier entrada provista

o disponible al momento del inicio

Peticiones, quejas, reclamos: corresponde a las solicitudes que llegan al Ministerio a las

diferentes áreas.

Describa el contexto de la operación El flujo comienza el curso con la radicación de la solicitud la cual es direccionada al Área o

Coordinación encargada de su solución, con la finalidad de analizar en detalle la solicitud,

revisando si existen o no solicitudes repetidas o asociadas contemplado en el estudio de

las condiciones de la solicitud para generar su respectivo tramite y gestión para cerrar la

solicitud.

Describa cómo el sistema debe

responder

Se debe generar un flujo de información entre las dependencias encargadas de dar trámite

a la solicitud, con el fin de dar respuestas acertadas y agiles.

Describa las salidas que el sistema

produce como resultado de la acción

Se debe de dar por finalizada tanto las solicitudes radicadas como las solicitudes

respondidas por el Área o Coordinación.

Describa quién o qué usa la salida y

para que es utilizada

La DARC utilizará la información de los trámites a los concesionarios y operadores para

proveer información de seguimiento de las peticiones, quejas y reclamos a los

concesionarios y operadores que ayudará a determinar los tiempos de servicios

adecuados para la ejecución de una funcionalidad.

Evaluación Basada en Escenarios: Utility Tree

Escenario 01 - Registro y estudio de SolicitudEscenario Operacional EO-01

Evaluación Basada en Escenarios: Profiles

• Es un conjunto de escenarios, generalmente con alguna importancia relativa asociada a cada uno de ellos.

• Su uso permite hacer especificaciones más precisas del requerimiento para un atributo de calidad. Estos pueden ser completos y seleccionados.

• Perfiles Completos, parte del hecho de que todos los escenarios son relevantes. Solo es beneficioso en arquitecturas pequeñas donde se puede predecir escenarios completos para algunos atributos de calidad. Bosch (2000).

• Perfiles Seleccionados, se basa en escenarios aleatorios de acuerdo a requerimientos específicos.

• Para definir un perfil se debe:

• Precisar la categoría del Escenario (calidad u operacional)

• Selección y definición de los escenarios para la categoría

• Asignación del peso a los escenarios, son escalas cuantificables para luego convertir es pesos relativos

Evaluación Basada en Escenarios: Profiles

Evaluación Basada en Escenarios: Profiles

Atributos de Calidad y Perfiles Asociados, según Bosch(2000)

• Emplea una implementación de alto nivel de la arquitectura del software. Bosch(2000). Es decir, implementa componentes de la arquitectura y del contexto del sistema donde se desempeñará.

Evaluación Basada en Simulación

Evaluación Basada en Simulación

Definición e Implementación del Contexto

Identifica GUI de la AS y decide como será su comportamiento

Implementación de los Componentes Arquitectónicos

Define l a GUI y las conexiones de los componentes, según lo descrito en el diseño

Implementación del Perfil

El atributo de calidad determinara el perfil a ser implantado en el sistema

Simulación e Inicio del Perfil

Cada atributo de calidad genera un resultado por escenario activo

Predicción de los Atributos de Calidad

Permite hacer conclusiones sobre el comportamiento del sistema

Modelo de Evaluación de ATAM

• Las siglas en ingles ATAM, significa Método de Análisis de Acuerdosde Arquitectura.

• Minimiza los riesgos en las fases iniciales del ciclo de desarrollo desoftware cuando el costo de cambiar las arquitecturas es pocosignificativo.

• La versión más reciente del método ATAM está descrita enKazman(2000), pudiendo consultarse ejemplos de aplicación enBarbacci (1997), Woods(1999) y por supuesto en el SEI(2002).

• Fue desarrollado por el Instituto de Desarrollo de Software de laUniversidad Carnegie Mellon, en Pittsburgh-Pennsylvania, paraayudar a elegir una arquitectura adecuada mediante eldescubrimiento de compensaciones y puntos de sensibilidad.

• Se basa en los estilos arquitectónicos, el análisis de atributos de calidad y el método de evaluación SAAM (Software Architecture Analysis Method).

• 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:

• Identificar los estilos arquitectónicos o enfoques arquitectónicos utilizados.

• Reconocer los atributos de calidad alcanzados en la arquitectura.

• Describir como el sistema puede crecer, responder a cambiar, e integrarse con otros sistemas.

Modelo de Evaluación de ATAM

• Las ideas básicas en las que se sustenta el método son las siguientes:

• Es un método conducido por escenarios.

• No evalúa la arquitectura respecto de atributos de calidad abstractos, sino respecto de requisitos concretos.

• Requiere de una descripción de las estructuras del sistema tanto más elaborada cuanto mayor sea su influencia en los atributos de calidad que se pretenden evaluar.

• Su ejecución debe consumir pocos recursos y realizarse en un lapso de tiempo relativamente corto.

• Toma en consideración tanto los requisitos técnicos, como aspectos sociales y de negocio.

Modelo de Evaluación de ATAM

• Bien puede decirse que este método es similar al SAAM solo que se diferencia en que ATAM incorpora:• La caracterización de los atributos de calidad.

• La noción de estilo arquitectónico.

• El proceso de evaluación permitirá descubrir los riesgos, puntos sensibles (sensitivity points) y puntos de compromiso (tradeoff points) asociados a las decisiones arquitectónicos.

• ATAM utiliza tres elementos: los escenarios de alta prioridad, las cuestiones específicas de atributo y los estilos arquitectónicos.

Modelo de Evaluación de ATAM

Riesgos

• Elegir un diseño arquitectónico

• Asociados a la gestión del proyecto

• A la comunicación entre las partes

Puntos Sensibles (sensitivity points)

• Propiedades de los componentes y relaciones que impidan cumplir con un atributo de calidad

Puntos de Compromiso (tradeoffpoints)

• Puntos sensibles que afectan más de un atributo de calidad

• Puntos en los que los atributos interaccionan y no pueden considerarse por separado

Modelo de Evaluación de ATAM

Modelo de Evaluación de ATAM

Flujo conceptual del método ATAM

Modelo de Evaluación de ATAM

Entradas/Salidas del método ATAM

Modelo de Evaluación de ATAM

Caracterización de los Atributos de Calidad en el Método ATAM

Escenarios de Casos de Uso

• Describen la interacción de los usuarios con el sistema en ejecución.

Escenarios de Crecimiento

• Representan probables futuros usos del sistema.

• Este tipo de escenario está ligado a las características de modificabilidad del sistema, pero sus efectos se extienden por todos los atributos.

Escenarios Exploratorios

• Representan situaciones extremas.

• Establecer los límites del diseño y revelar las suposiciones que implícitamente puedan hacerse las diferentes partes implicadas sobre el mismo.

Modelo de Evaluación de ATAM

Modelo de Evaluación de ATAM

Obtención de Escenarios: Árboles de utilidad y Tormenta de ideas en ATAM

Modelo de Evaluación de ATAM

Ejemplo de árbol de utilidad

Pasos del Modelo de Evaluación de ATAM

Pre

sen

taci

ón Presentación

del ATAM

Presentación de las Metas de Negocio

Presentación de la Arquitectura In

vest

igac

ión

y A

nál

isis Identificación

de los enfoques arquitectónicos

Generación del UtilityTree

Análisis de los enfoques arquitectónicos

Pru

eb

as Lluvia de ideas y establecimiento de prioridad de escenarios

Análisis de los enfoques arquitectónicos

Re

po

rte

s Presentación de los resultados

Pasos de ATAM e Involucrados

Pasos del Modelo de Evaluación de ATAM

Presentación de los Factores de Negocio

El sistema en cuyo desarrollo se va a utilizar la arquitectura debe ser perfectamente entendido por todas las partes. El cliente describe el sistema desde la perspectiva de negocio.

Presentación de la Arquitectura

Presentación de la Arquitectura

Pasos del Modelo de Evaluación de ATAM

Pasos del Modelo de Evaluación de ATAM

Pasos del Modelo de Evaluación de ATAM

Presentación de los Resultados

• Para terminar, la información generada durante la ejecución del método se organiza, resume y presenta a todas las partes implicadas. Esta presentación debe incluir:

• Documentación de los estilos arquitectónicos.

• Conjunto de escenarios y su orden de prioridad.

• El conjunto de cuestiones específicas de atributo formuladas y sus respuestas.

• El árbol de utilidad.

• Los riesgos y no-riesgos descubiertos.

• Los puntos sensibles y los puntos de compromiso.