EVALUACION ARQUITECTONICA
Anuncio
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.
