Evaluación Arquitectónica

 Generalidades
 Objetivos
 Importancia
 Técnicas de evaluación
Generalidades

La evaluación arquitectónica demuestra si la decisiones estilos y patrones impactan

positivamente los atributos de calidad del sistema.

Pueden ser usados los términos evaluar y

verificar como sinónimos?

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

Mediciones sobre la Arquitectura del Software

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
Objetivos
Kazman Bosch
• Propone un esquema general con • Plantea la evaluación explícita de
respecto a sus atributos de calidad,
para determinar los riesgos de la los atributos de calidad de la
arquitectura. arquitectura durante el proceso
• Su enfoque se orienta hacia la de diseño.
mitigación de riesgos de los
atributos de calidad que se pueden • Considera las técnicas de
afectar por decisiones evaluación:
arquitectónicas . • Basada en escenarios
• Presenta los metodos de • Basada en simulación
evaluacion de: • Basada en modelos matemáticos
• ATAM Metodo de Analisis de
Acuerdos de Arquitectura • Basada en experiencia
• SAAM Metodo de Analisis de
Arquitectura de Software
• ARID Evaluacion temprana de los
disenos de una arquitectura de
software
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
Técnicas de Evaluación
• Bosch(2000)
• Basada en Escenarios
• Basada en Simulación
• Basada en Modelos Matemáticos
• Basada en Experiencia
 Atributos de Calidad, según Bass
Atributo 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
 Atributos de Calidad, según Bass
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 Es la medida de la facilidad con la que el software, al ser sometido a una serie de pruebas, puede demostrar
Prueba 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

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)
• Describe lo que el involucrado hace para
Estimulo interactuar con el sistema. Tareas,
configuración, pruebas.

Contexto • Describe lo ocurrido en el sistema

posterior al estimulo

• Describe de acuerdo a la arquitectura como

Respuesta debería responder el sistema posterior al

estimulo, establece el atributo de calidad
asociado.

Partes del Escenario

Fuente: Kazman (2001)
 Evaluación Basada en Escenarios
• 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:
Utility Tree
• 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.
 Identificación de Motivadores de negocio
Nombre del Motivador Descripción del Motivador de Negocio
de Negocio MN_004
Mejorar tiempos de atención a Mejorar tiempos de atención en un 60% mediante la
clientes internos y externos. 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
Definido Por: Dirección administrativa de recursos
Asociación del Motivador con de telecomunicaciones
el Negocio Ejecutado Por: Dirección administrativa de recursos
de telecomunicaciones
Ubicación en el Atención al ciudadano
Portafolio del negocio
 Evaluación Basada en Escenarios:
Utility Tree
Tiempo de
Eficiencia Retorno ágil de resultados
respuesta

Atención a
Capacidad Concurrencia usuarios
Mejorar tiempos de
atención a clientes simultáneos
internos y externos
Tolerancia a Continuación de ejecución
fallas en caso de falla

Recuperabilidad Agilidad en
Fiabilidad recuperación a fallos

Disponbilidad Operacionalidad
continua

Árbol de Utilidad para MN_004

 Evaluación Basada en Escenarios:
Utility Tree
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
Respuesta de radicación inferior a 1 minuto
Respuesta

Escenario de Calidad - Eficiencia

 Evaluación Basada en Escenarios:
Utility Tree
Título del Escenario Operacional
Registro y estudio de Solicitud
Stakeholder Asociado Director DARC ID EO-01
Consideración Operacional Respuesta del Stakeholder
Descripción general de la Describe la administración de los servicios del control de las concesiones y actividades de
funcionalidad 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 Lo esperado por el Stakeholder es poder llevar a cabo el seguimiento y control de las
ahora o le gustaría poder hacer solicitudes.
Describa cualquier entrada provista Peticiones, quejas, reclamos: corresponde a las solicitudes que llegan al Ministerio a las
o disponible al momento del inicio 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 Se debe generar un flujo de información entre las dependencias encargadas de dar trámite
responder a la solicitud, con el fin de dar respuestas acertadas y agiles.
Describa las salidas que el sistema Se debe de dar por finalizada tanto las solicitudes radicadas como las solicitudes
produce como resultado de la acción respondidas por el Área o Coordinación.
Describa quién o qué usa la salida y La DARC utilizará la información de los trámites a los concesionarios y operadores para
para que es utilizada 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.
Escenario 01 - Registro y estudio de Solicitud
Escenario 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.
Evaluación Basada en Escenarios:
Profiles
• 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

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

Evaluación Basada en Simulación
• 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

Definición e Implementación del Contexto

Implementación de los Componentes Arquitectónicos

Identifica GUI de la AS
y decide como será su
comportamiento Implementación del Perfil
Define l a GUI y las
conexiones de los
componentes, según Simulación e Inicio del Perfil
El atributo de calidad
lo descrito en el diseño
determinara el perfil a Predicción de los
ser implantado en el Atributos de Calidad
Cada atributo de
sistema
calidad genera un
resultado por
Permite hacer
escenario activo
conclusiones sobre el
comportamiento del
sistema
Modelo de Evaluación de ATAM
• Las siglas en ingles ATAM, significa Método de Análisis de Acuerdos
de Arquitectura.
• Minimiza los riesgos en las fases iniciales del ciclo de desarrollo de
software cuando el costo de cambiar las arquitecturas es poco
significativo.
• La versión más reciente del método ATAM está descrita en
Kazman(2000), pudiendo consultarse ejemplos de aplicación en
Barbacci (1997), Woods(1999) y por supuesto en el SEI(2002).
• Fue desarrollado por el Instituto de Desarrollo de Software de la
Universidad Carnegie Mellon, en Pittsburgh-Pennsylvania, para
ayudar a elegir una arquitectura adecuada mediante el
descubrimiento de compensaciones y puntos de sensibilidad.
Modelo de Evaluación de ATAM
• 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 Puntos Sensibles Puntos de

• Elegir un diseño
arquitectónico
• Asociados a la gestión del
proyecto
• A la comunicación entre
las partes
(sensitivity points) Compromiso (tradeoff
• Propiedades de los points)
componentes y relaciones • Puntos sensibles que
que impidan cumplir con afectan más de un atributo
un atributo de calidad de calidad
• Puntos en los que los
atributos interaccionan y
no pueden considerarse
por separado
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

Modelo de Evaluación de 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

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

Pruebas

Reportes
Presentación

Investigación y Análisis
Presentación Identificación Lluvia de ideas Presentación de
del ATAM de los enfoques y los resultados
Presentación de arquitectónicos establecimiento
las Metas de Generación del de prioridad de
Negocio UtilityTree escenarios
Presentación de Análisis de los Análisis de los
la Arquitectura enfoques enfoques
arquitectónicos arquitectónicos
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.