EVALUACION ARQUITECTONICA

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
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 pueden
afectar por decisiones
arquitectónicas .
• Presenta los metodos de
evaluacion de:
• 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:
• 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
•
•
•
•
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
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)
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 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
de Negocio
Mejorar tiempos de atención a
clientes internos y externos.
Descripción del Motivador de Negocio
MN_004
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
Ninguno
Bajo
Moderado
Fuerte
Muy Fuerte
Asociación del Motivador con
el Negocio
Cota Mínima
0
11
21
41
51
Definido Por:
Ejecutado Por:
Ubicación en el
Portafolio del negocio
Cota Máxima
10
20
40
50
60
Dirección administrativa de recursos
de telecomunicaciones
Dirección administrativa de recursos
de telecomunicaciones
Atención al ciudadano
Evaluación Basada en Escenarios:
Utility Tree
Eficiencia
Mejorar tiempos de
atención a clientes
internos y externos
Capacidad
Tiempo de
respuesta
Concurrencia
Tolerancia a
fallas
Recuperabilidad
Fiabilidad
Disponbilidad
Árbol de Utilidad para MN_004
Retorno ágil de resultados
Atención a
usuarios
simultáneos
Continuación de ejecución
en caso de falla
Agilidad en
recuperación a fallos
Operacionalidad
continua
Evaluación Basada en Escenarios:
Utility Tree
Atributo de Calidad:
Fiabilidad
Tolerancia a Fallas
ID
Descripción
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
AC_FIA_003
Habilidad del sistema para recuperarse ágilmente a
fallos
AC_FIA_004
Habilidad del sistema en línea para ser operacional
de modo continuo.
Recuperabilidad
MN_004
Disponibilidad
MN_004
Atributo de Calidad - Fiabilidad
Prioridad
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
Respuesta de radicación inferior a 1 minuto
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
Consideración Operacional
Descripción general de la
funcionalidad
EO-01
Respuesta del Stakeholder
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 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
Identifica GUI de la AS
y decide como será su
comportamiento
Implementación de los Componentes Arquitectónicos
Implementación del Perfil
Define l a GUI y las
conexiones de los
componentes, según
El atributo de calidad
lo descrito en el diseño
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 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
• 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 (tradeoff
points)
• 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
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
Presentación de
la Arquitectura
Generación del
UtilityTree
Lluvia de ideas
y
establecimiento
de prioridad de
escenarios
Análisis de los
enfoques
arquitectónicos
Análisis de los
enfoques
arquitectónicos
Reportes
Presentación de
las Metas de
Negocio
Identificación
de los enfoques
arquitectónicos
Pruebas
Presentación
del ATAM
Investigación y Análisis
Presentación
Pasos del Modelo de Evaluación de ATAM
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.