Este documento resume cuatro métodos para evaluar la arquitectura de software de un atributo específico: ALMA, PASA, SALUTA y SNA. Explica brevemente cada método y proporciona una tabla comparativa de sus características. El objetivo general es estudiar el estado del arte de la evaluación de arquitecturas de software centrándose en un atributo en particular.
Métodos de evaluación de arquitectura a un atributo específicoTefa Gonzaga
Este documento resume cuatro métodos para evaluar la arquitectura de software de un atributo específico: ALMA (modificabilidad), PASA (desempeño), SALUTA (usabilidad) y SNA (supervivencia de redes). Describe cada método y explica cómo involucra escenarios y objetivos para evaluar cómo la arquitectura soporta el atributo correspondiente. El documento provee una guía útil para elegir el método apropiado dependiendo del atributo que se desea evaluar.
This document discusses different types of architecture views, including the module architecture view. It defines a view as a combination of structures that share common properties or perspectives. Architecture is described as the high-level structure of a software system that organizes its elements. The goals of architecture are to expose a system's structure while hiding implementation details and addressing requirements.
The module architecture view shows how key system elements are mapped to modules and subsystems, which are decomposed and assigned to layers based on dependencies. It defines the modules and their inherent relations without specifying a product configuration. Diagrams like package diagrams and class diagrams are used to depict subsystem decomposition and module use-dependencies.
El documento describe los conceptos clave de la Vista Lógica en el análisis y diseño orientado a objetos con UML, incluyendo clases, atributos, operaciones, relaciones, agregación, herencia y diagramas de clases. Explica cómo modelar el sistema mediante la identificación de clases y especificación de sus características y cómo representar la interacción entre clases a través de diferentes tipos de relaciones.
Este documento presenta información sobre técnicas estructuradas y orientadas a objetos para el análisis de requerimientos en el desarrollo de sistemas de información. Describe técnicas como el análisis estructurado, la especificación formal de datos y procesos, el uso de diagramas de flujo y diccionarios de datos, así como técnicas orientadas a objetos como casos de uso, modelado de clases, definición de atributos y servicios, y el uso de prototipos rápidos. Finalmente, presenta información sobre
El método SAAM (Software Architecture Analysis Method) es un método para evaluar la modificabilidad y otros atributos de calidad de una arquitectura de software. El procedimiento de SAAM implica describir la arquitectura, desarrollar escenarios de cambio futuros, evaluar cómo la arquitectura soportaría esos cambios, y generar una evaluación global. El objetivo final es mejorar la comunicación, reusabilidad y evolución del sistema.
El documento describe diferentes modelos y vistas para documentar la arquitectura de software, incluyendo el modelo de 4+1 vistas de Philippe Kruchten y las 4 vistas propuestas por Robert Nord para sistemas industriales. Se explican las vistas lógica, de procesos, de desarrollo, física y de escenarios, así como recomendaciones para seleccionar y documentar las vistas más útiles.
Vistas Arquitectonicas Ingenieria de SoftwareRoberth Loaiza
Este documento describe las vistas arquitectónicas y el modelo 4+1 de vistas. Explica que las vistas arquitectónicas representan aspectos parciales de una arquitectura de software desde diferentes perspectivas. Luego describe las cinco vistas del modelo 4+1: vista lógica, vista de procesos, vista de despliegue, vista física y vista de escenarios. Finalmente, ofrece recomendaciones para seleccionar y documentar las vistas más útiles.
Métodos de evaluación de arquitectura a un atributo específicoTefa Gonzaga
Este documento resume cuatro métodos para evaluar la arquitectura de software de un atributo específico: ALMA (modificabilidad), PASA (desempeño), SALUTA (usabilidad) y SNA (supervivencia de redes). Describe cada método y explica cómo involucra escenarios y objetivos para evaluar cómo la arquitectura soporta el atributo correspondiente. El documento provee una guía útil para elegir el método apropiado dependiendo del atributo que se desea evaluar.
This document discusses different types of architecture views, including the module architecture view. It defines a view as a combination of structures that share common properties or perspectives. Architecture is described as the high-level structure of a software system that organizes its elements. The goals of architecture are to expose a system's structure while hiding implementation details and addressing requirements.
The module architecture view shows how key system elements are mapped to modules and subsystems, which are decomposed and assigned to layers based on dependencies. It defines the modules and their inherent relations without specifying a product configuration. Diagrams like package diagrams and class diagrams are used to depict subsystem decomposition and module use-dependencies.
El documento describe los conceptos clave de la Vista Lógica en el análisis y diseño orientado a objetos con UML, incluyendo clases, atributos, operaciones, relaciones, agregación, herencia y diagramas de clases. Explica cómo modelar el sistema mediante la identificación de clases y especificación de sus características y cómo representar la interacción entre clases a través de diferentes tipos de relaciones.
Este documento presenta información sobre técnicas estructuradas y orientadas a objetos para el análisis de requerimientos en el desarrollo de sistemas de información. Describe técnicas como el análisis estructurado, la especificación formal de datos y procesos, el uso de diagramas de flujo y diccionarios de datos, así como técnicas orientadas a objetos como casos de uso, modelado de clases, definición de atributos y servicios, y el uso de prototipos rápidos. Finalmente, presenta información sobre
El método SAAM (Software Architecture Analysis Method) es un método para evaluar la modificabilidad y otros atributos de calidad de una arquitectura de software. El procedimiento de SAAM implica describir la arquitectura, desarrollar escenarios de cambio futuros, evaluar cómo la arquitectura soportaría esos cambios, y generar una evaluación global. El objetivo final es mejorar la comunicación, reusabilidad y evolución del sistema.
El documento describe diferentes modelos y vistas para documentar la arquitectura de software, incluyendo el modelo de 4+1 vistas de Philippe Kruchten y las 4 vistas propuestas por Robert Nord para sistemas industriales. Se explican las vistas lógica, de procesos, de desarrollo, física y de escenarios, así como recomendaciones para seleccionar y documentar las vistas más útiles.
Vistas Arquitectonicas Ingenieria de SoftwareRoberth Loaiza
Este documento describe las vistas arquitectónicas y el modelo 4+1 de vistas. Explica que las vistas arquitectónicas representan aspectos parciales de una arquitectura de software desde diferentes perspectivas. Luego describe las cinco vistas del modelo 4+1: vista lógica, vista de procesos, vista de despliegue, vista física y vista de escenarios. Finalmente, ofrece recomendaciones para seleccionar y documentar las vistas más útiles.
El documento presenta una introducción a las arquitecturas de software, definiendo conceptos básicos, los beneficios de una arquitectura de software y la arquitectura 4+1 vista. Proporciona una bibliografía de referencias y un mapa conceptual de tópicos de conocimiento sobre ingeniería de software.
Este documento presenta conceptos sobre arquitectura de software. Define arquitectura como el nivel conceptual más alto de un sistema y su organización fundamental descrita por sus componentes, relaciones y principios de diseño. Luego discute la importancia de definir la arquitectura en los proyectos, como puente entre requerimientos y implementación. Por último, contrasta arquitectura y diseño indicando que la arquitectura se enfoca en decisiones estratégicas de alto nivel que guían el diseño e implementación de un software.
Este documento resume los conceptos clave de las arquitecturas de software, incluyendo sus características generales, atributos de calidad y patrones/estilos de arquitectura. El documento también proporciona una bibliografía de referencias sobre el tema.
Análisis de riesgos de un proyecto de softwareAngel Reyes
Este documento describe el análisis de riesgos de un proyecto de software. Explica que el análisis de riesgos es un proceso para identificar los riesgos, su probabilidad de ocurrencia e impacto, y determinar los controles para mitigarlos. También define los tipos de riesgos como riesgos de proyecto, técnicos y de negocio, y métodos para identificarlos como listas de verificación. El objetivo final es cuantificar los riesgos y determinar acciones para controlarlos, eliminarlos, compartirlos o a
El documento describe diferentes metodologías para el desarrollo de software, incluyendo metodologías estructuradas, orientadas a objetos, tradicionales y ágiles. Explica conceptos como ciclo de vida de software, modelos de ciclo de vida como cascada y espiral, y metodologías específicas como RUP, Scrum y XP.
Este documento describe varias técnicas para estimar los costos de proyectos de software. Presenta métricas como líneas de código y puntos de función que pueden usarse para estimar el tamaño de un proyecto. También describe factores que afectan los costos como la capacidad de los programadores, la complejidad del producto y el tiempo disponible. Finalmente, resume técnicas como el juicio experto y Delphi para realizar estimaciones.
Descripción general de los 13 diagramas UML así como sus componentes y principales funciones, es útil para exponer o dar una clase introductoria de este tema.
Este documento describe los conceptos clave del diseño arquitectónico de sistemas de información. Explica diferentes estilos arquitectónicos como la arquitectura centrada en datos, en capas y distribuida. También cubre temas como la descomposición modular, estilos de control y documentación de la arquitectura.
RUP es un proceso de ingeniería de software orientado a disciplinas que busca asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios de manera predecible. Está diseñado para profesionales de desarrollo de software e incluye roles, disciplinas, actividades y artefactos. El ciclo de vida de RUP consta de cuatro fases secuenciales - Inicio, Elaboración, Construcción y Transición - cada una con un objetivo específico.
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
El documento describe el Proceso Unificado de Rational (RUP), incluyendo sus tres perspectivas (dinámica, estática y práctica), sus fases principales (inicio, elaboración, construcción y transición), sus flujos de trabajo clave y buenas prácticas recomendadas. RUP es un modelo iterativo e incremental con fases orientadas a objetivos de negocio en lugar de actividades técnicas, permitiendo que los flujos de trabajo como modelado y pruebas ocurran a lo largo de todo el ciclo de desarrollo.
Este documento describe el proceso GQM (Goal Question Metric) para definir métricas para proyectos. GQM involucra 6 pasos: 1) establecer metas, 2) generar preguntas, 3) especificar métricas, 4) preparar recolección de datos, 5) recolectar y analizar datos, y 6) analizar datos para lograr objetivos y aprendizaje. También describe los niveles conceptual, operacional y cuantitativo de GQM y las fases para su implementación.
El documento introduce el Proceso Unificado de Rational (RUP), describiendo que es un proceso iterativo, centrado en la arquitectura y dirigido por los casos de uso. Explica que el RUP es configurable, soporta técnicas orientadas a objetos y promueve un control de calidad y gestión de riesgos continuos. También presenta los conceptos clave de ciclo de vida del software, modelo de desarrollo, fases y flujos de trabajo del RUP.
El documento describe el diseño de la arquitectura de software. Explica que la arquitectura identifica los elementos e interacciones más importantes de un sistema y provee una visión global. También cubre estilos arquitectónicos como centrados en datos, flujo de datos, llamada y retorno, orientados a objetos y estratificados. El propósito de la arquitectura es facilitar la comunicación, reducir riesgos y considerar alternativas de diseño temprano.
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso RealesSergio Sanchez
El documento describe los contratos de operaciones en UML, incluyendo sus secciones, propósito y ejemplos. Explica que los contratos describen el comportamiento del sistema después de la ejecución de una operación y cómo las postcondiciones detallan los cambios en el estado de los objetos, como la creación, modificación de atributos y formación de asociaciones. También proporciona un ejemplo de contrato para la operación "IntroducirArticulo".
Este documento presenta una introducción a los patrones GRASP (General Responsibility Assignment Software Patterns). Explica que los patrones son descripciones de problemas y soluciones con nombre que pueden aplicarse en diferentes contextos. Describe los patrones GRASP, los cuales asignan responsabilidades a objetos de manera sistemática. Cubre patrones específicos como Experto, Creador, Bajo Acoplamiento y Alta Cohesión, explicando sus problemas, soluciones y ejemplos.
El documento habla sobre la arquitectura de software. Explica que la arquitectura de software describe los componentes de un sistema y cómo interactúan, y que su objetivo es satisfacer los requisitos funcionales y de rendimiento así como requisitos no funcionales como la mantenibilidad y flexibilidad. También menciona la norma ISO 9126 para la evaluación de la calidad del software, la cual clasifica atributos como la funcionalidad, fiabilidad, usabilidad, eficiencia y portabilidad.
Tabla comparativa- metodologías de desarrolloitsarellano
Este documento describe varios modelos de desarrollo de software, incluyendo cascada, incremental, prototipado evolutivo, RAD, RUP y XP. Explica las etapas, tipos de proyectos, relación con los usuarios y características de cada modelo.
Este documento presenta un resumen del modelo 4+1 para diagramas arquitectónicos. El modelo 4+1 incluye cinco vistas: la vista lógica, la vista de despliegue, la vista de procesos, la vista física y la vista +1 de escenarios. Cada vista se documenta con diagramas UML específicos como diagramas de clases, componentes y casos de uso. El modelo 4+1 es un estándar reconocido para la descripción de arquitecturas de sistemas de software.
Este documento describe métodos para evaluar arquitecturas de software, incluyendo ATAM, ALMA y ARID. Explica que la evaluación es importante para identificar problemas temprano, validar requisitos y tomar mejores decisiones de diseño. También cubre conceptos como escenarios, atributos de calidad, técnicas de evaluación y presentación de resultados.
El resumen del documento es el siguiente:
El documento describe el Método de Evaluación para Arquitecturas Basadas en Componentes (MECABIC), el cual consta de cuatro fases para evaluar y analizar la calidad requerida por los usuarios de arquitecturas de software basadas en componentes. La fase 1 presenta el método, las directrices del negocio y la arquitectura. La fase 2 identifica elementos de diseño y genera un árbol de utilidad para analizar la arquitectura. La fase 3 revisa los resultados. Y la fase 4 presenta los
El documento presenta una introducción a las arquitecturas de software, definiendo conceptos básicos, los beneficios de una arquitectura de software y la arquitectura 4+1 vista. Proporciona una bibliografía de referencias y un mapa conceptual de tópicos de conocimiento sobre ingeniería de software.
Este documento presenta conceptos sobre arquitectura de software. Define arquitectura como el nivel conceptual más alto de un sistema y su organización fundamental descrita por sus componentes, relaciones y principios de diseño. Luego discute la importancia de definir la arquitectura en los proyectos, como puente entre requerimientos y implementación. Por último, contrasta arquitectura y diseño indicando que la arquitectura se enfoca en decisiones estratégicas de alto nivel que guían el diseño e implementación de un software.
Este documento resume los conceptos clave de las arquitecturas de software, incluyendo sus características generales, atributos de calidad y patrones/estilos de arquitectura. El documento también proporciona una bibliografía de referencias sobre el tema.
Análisis de riesgos de un proyecto de softwareAngel Reyes
Este documento describe el análisis de riesgos de un proyecto de software. Explica que el análisis de riesgos es un proceso para identificar los riesgos, su probabilidad de ocurrencia e impacto, y determinar los controles para mitigarlos. También define los tipos de riesgos como riesgos de proyecto, técnicos y de negocio, y métodos para identificarlos como listas de verificación. El objetivo final es cuantificar los riesgos y determinar acciones para controlarlos, eliminarlos, compartirlos o a
El documento describe diferentes metodologías para el desarrollo de software, incluyendo metodologías estructuradas, orientadas a objetos, tradicionales y ágiles. Explica conceptos como ciclo de vida de software, modelos de ciclo de vida como cascada y espiral, y metodologías específicas como RUP, Scrum y XP.
Este documento describe varias técnicas para estimar los costos de proyectos de software. Presenta métricas como líneas de código y puntos de función que pueden usarse para estimar el tamaño de un proyecto. También describe factores que afectan los costos como la capacidad de los programadores, la complejidad del producto y el tiempo disponible. Finalmente, resume técnicas como el juicio experto y Delphi para realizar estimaciones.
Descripción general de los 13 diagramas UML así como sus componentes y principales funciones, es útil para exponer o dar una clase introductoria de este tema.
Este documento describe los conceptos clave del diseño arquitectónico de sistemas de información. Explica diferentes estilos arquitectónicos como la arquitectura centrada en datos, en capas y distribuida. También cubre temas como la descomposición modular, estilos de control y documentación de la arquitectura.
RUP es un proceso de ingeniería de software orientado a disciplinas que busca asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios de manera predecible. Está diseñado para profesionales de desarrollo de software e incluye roles, disciplinas, actividades y artefactos. El ciclo de vida de RUP consta de cuatro fases secuenciales - Inicio, Elaboración, Construcción y Transición - cada una con un objetivo específico.
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
El documento describe el Proceso Unificado de Rational (RUP), incluyendo sus tres perspectivas (dinámica, estática y práctica), sus fases principales (inicio, elaboración, construcción y transición), sus flujos de trabajo clave y buenas prácticas recomendadas. RUP es un modelo iterativo e incremental con fases orientadas a objetivos de negocio en lugar de actividades técnicas, permitiendo que los flujos de trabajo como modelado y pruebas ocurran a lo largo de todo el ciclo de desarrollo.
Este documento describe el proceso GQM (Goal Question Metric) para definir métricas para proyectos. GQM involucra 6 pasos: 1) establecer metas, 2) generar preguntas, 3) especificar métricas, 4) preparar recolección de datos, 5) recolectar y analizar datos, y 6) analizar datos para lograr objetivos y aprendizaje. También describe los niveles conceptual, operacional y cuantitativo de GQM y las fases para su implementación.
El documento introduce el Proceso Unificado de Rational (RUP), describiendo que es un proceso iterativo, centrado en la arquitectura y dirigido por los casos de uso. Explica que el RUP es configurable, soporta técnicas orientadas a objetos y promueve un control de calidad y gestión de riesgos continuos. También presenta los conceptos clave de ciclo de vida del software, modelo de desarrollo, fases y flujos de trabajo del RUP.
El documento describe el diseño de la arquitectura de software. Explica que la arquitectura identifica los elementos e interacciones más importantes de un sistema y provee una visión global. También cubre estilos arquitectónicos como centrados en datos, flujo de datos, llamada y retorno, orientados a objetos y estratificados. El propósito de la arquitectura es facilitar la comunicación, reducir riesgos y considerar alternativas de diseño temprano.
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso RealesSergio Sanchez
El documento describe los contratos de operaciones en UML, incluyendo sus secciones, propósito y ejemplos. Explica que los contratos describen el comportamiento del sistema después de la ejecución de una operación y cómo las postcondiciones detallan los cambios en el estado de los objetos, como la creación, modificación de atributos y formación de asociaciones. También proporciona un ejemplo de contrato para la operación "IntroducirArticulo".
Este documento presenta una introducción a los patrones GRASP (General Responsibility Assignment Software Patterns). Explica que los patrones son descripciones de problemas y soluciones con nombre que pueden aplicarse en diferentes contextos. Describe los patrones GRASP, los cuales asignan responsabilidades a objetos de manera sistemática. Cubre patrones específicos como Experto, Creador, Bajo Acoplamiento y Alta Cohesión, explicando sus problemas, soluciones y ejemplos.
El documento habla sobre la arquitectura de software. Explica que la arquitectura de software describe los componentes de un sistema y cómo interactúan, y que su objetivo es satisfacer los requisitos funcionales y de rendimiento así como requisitos no funcionales como la mantenibilidad y flexibilidad. También menciona la norma ISO 9126 para la evaluación de la calidad del software, la cual clasifica atributos como la funcionalidad, fiabilidad, usabilidad, eficiencia y portabilidad.
Tabla comparativa- metodologías de desarrolloitsarellano
Este documento describe varios modelos de desarrollo de software, incluyendo cascada, incremental, prototipado evolutivo, RAD, RUP y XP. Explica las etapas, tipos de proyectos, relación con los usuarios y características de cada modelo.
Este documento presenta un resumen del modelo 4+1 para diagramas arquitectónicos. El modelo 4+1 incluye cinco vistas: la vista lógica, la vista de despliegue, la vista de procesos, la vista física y la vista +1 de escenarios. Cada vista se documenta con diagramas UML específicos como diagramas de clases, componentes y casos de uso. El modelo 4+1 es un estándar reconocido para la descripción de arquitecturas de sistemas de software.
Este documento describe métodos para evaluar arquitecturas de software, incluyendo ATAM, ALMA y ARID. Explica que la evaluación es importante para identificar problemas temprano, validar requisitos y tomar mejores decisiones de diseño. También cubre conceptos como escenarios, atributos de calidad, técnicas de evaluación y presentación de resultados.
El resumen del documento es el siguiente:
El documento describe el Método de Evaluación para Arquitecturas Basadas en Componentes (MECABIC), el cual consta de cuatro fases para evaluar y analizar la calidad requerida por los usuarios de arquitecturas de software basadas en componentes. La fase 1 presenta el método, las directrices del negocio y la arquitectura. La fase 2 identifica elementos de diseño y genera un árbol de utilidad para analizar la arquitectura. La fase 3 revisa los resultados. Y la fase 4 presenta los
Este documento presenta los conceptos clave de la arquitectura de software. Explica que la arquitectura define la estructura básica de una solución considerando aspectos funcionales y no funcionales. También cubre principios de arquitectura de software, patrones y estilos arquitectónicos comunes, aspectos transversales y atributos de calidad que debe satisfacer la arquitectura. Finalmente, resume varios patrones de diseño comúnmente utilizados.
Este documento describe la fase de elaboración del Proceso Unificado Racional (RUP) para un proyecto de desarrollo de software. La fase de elaboración se enfoca en determinar la solución técnica del proyecto mediante la especificación de requisitos de diseño, el establecimiento de la arquitectura y el desarrollo de un plan de proyecto. Las actividades clave incluyen el desarrollo de casos de uso, la definición de la arquitectura del sistema, la creación de un prototipo funcional y la identificación de ries
Este documento presenta una introducción a la arquitectura de software, incluyendo definiciones de arquitectura, el rol del arquitecto, la diferencia entre arquitectura y diseño, métodos para definir arquitecturas, ejemplos de arquitecturas de sistemas, calidades sistémicas, y lecciones aprendidas en consultoría. Explica cómo la arquitectura ha evolucionado de modelos monolíticos a modelos distribuidos multi-nivel y orientados a servicios, y destaca la importancia de definir arquitecturas para satisf
Este documento presenta las perspectivas arquitecturales y cómo se pueden aplicar para garantizar que un sistema exhiba atributos de calidad específicos. Describe las perspectivas más relevantes como seguridad, desempeño y escalabilidad, y disponibilidad y recuperabilidad. Explica que las perspectivas se aplican a las vistas arquitectónicas para analizar cómo cumple la arquitectura con los atributos de calidad y encontrar posibles mejoras.
Este documento describe el modelo de prototipo para el desarrollo de software. Explica que el modelo de prototipo permite construir rápidamente parte o la totalidad de un sistema para aclarar los requisitos con los usuarios y el cliente. Detalla las etapas del modelo como identificar requisitos, desarrollar un prototipo inicial, probarlo y mejorarlo. También discute las ventajas de este modelo como minimizar riesgos e incertidumbres, y las desventajas como que los clientes pueden decepcionarse si no entienden que es un prototipo.
La metodología RUP (Rational Unified Process) es un proceso iterativo e incremental de desarrollo de software centrado en casos de uso y arquitectura. Se divide en cuatro fases (inicio, elaboración, construcción y transición) por ciclo. Cada fase se enfoca en actividades específicas como la definición de requisitos, análisis, diseño, implementación, pruebas y entrega del producto de software. El objetivo general es reducir riesgos y acelerar el desarrollo a través de iteraciones planificadas.
La metodología RUP (Rational Unified Process) es un proceso iterativo e incremental de desarrollo de software centrado en casos de uso y arquitectura. Se divide en cuatro fases (inicio, elaboración, construcción y transición) por ciclo, con el objetivo de entregar incrementos funcionales del producto. Los requerimientos son la base para la planificación, estimación, análisis, diseño, implementación, pruebas y producto final del sistema de software.
Este documento presenta una comparación de los modelos de calidad de software más importantes, incluyendo el Modelo de McCall, el Modelo de Boehm, el Modelo FURPS, el Modelo GQM y el Modelo SATC. Cada modelo se define por sus características, niveles de organización, ventajas y desventajas. El objetivo es analizar los diferentes enfoques para la evaluación de la calidad del software.
Este documento presenta un plan de pruebas de software que incluye objetivos, tipos de pruebas, métodos, herramientas y diseño de seguridad. El plan detalla la arquitectura jerárquica de las pruebas, los responsables, los objetivos y los recursos necesarios. Incluye secciones sobre tipos de pruebas como unidades, funcionales e integración, así como métodos, principios y herramientas de prueba.
Este documento describe un estudio sobre factores de calidad para medir el diseño de productos de software. El estudio identificó métricas existentes, clasificó proyectos de software según su tipo de desarrollo, desarrolló herramientas para evaluar la calidad usando listas de verificación, y propuso un protocolo de calidad para garantizar la calidad futura.
El documento proporciona una introducción al Proceso Racional Unificado (RUP), incluyendo su definición, historia, principios, ciclo de vida y etapas. RUP es una metodología para el desarrollo de software que se centra en la calidad, adaptación y colaboración. Se compone de cuatro fases iterativas: inicio, elaboración, construcción y transición. Cada fase tiene objetivos específicos como establecer requisitos, desarrollar la arquitectura y poner el producto final en manos de los usuarios.
El documento habla sobre los fundamentos del diseño de software. Explica que el diseño de software permite producir modelos del sistema que pueden evaluarse antes de codificar. También cubre conceptos como abstracción, modularidad, estructura de datos, procedimientos de software y arquitectura. Finalmente, discute técnicas para garantizar la calidad como pruebas estáticas, dinámicas, automatizadas y manuales.
Este documento resume la ingeniería de requisitos en menos de 3 oraciones. Explica que la ingeniería de requisitos comprende determinar las necesidades para un nuevo software o uno modificado, tomando en cuenta los requisitos de los inversionistas. El propósito es que los requisitos alcancen un estado óptimo antes del diseño a través de actividades como el análisis del problema, la especificación y validación de requisitos, y la evolución de los mismos.
El documento define las fases del ciclo de vida de un sistema de información, incluyendo la planificación, análisis de requisitos, diseño, implementación, pruebas, instalación y despliegue, uso y mantenimiento. Explica que la planificación determina el alcance del proyecto, costos estimados y asignación de recursos. El análisis identifica las necesidades del sistema y requisitos. El diseño selecciona la estructura general. La implementación construye el sistema. Las pruebas detectan errores. La instalación
El documento describe el ciclo de vida del desarrollo de software, incluyendo las fases de análisis, diseño, desarrollo, pruebas e implementación, y mantenimiento. También define los roles clave de analistas, diseñadores y otros durante el proceso. Finalmente, explica las responsabilidades y actividades de los analistas durante la fase de análisis de requisitos.
Este documento presenta un plan de pruebas de software que incluye objetivos, tipos de pruebas, métodos, herramientas y diseños. El plan describe la arquitectura jerárquica de las pruebas, los responsables, objetivos y recursos necesarios. Incluye secciones sobre tipos de pruebas como unitaria, funcional, integración y validación; métodos como caja negra y blanca; y herramientas de prueba. También cubre temas como diseño de seguridad, auditoría, recuperación de sistemas y diseño de
La metodología de desarrollo de software OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991. Más tarde, Rumbaugh se unió a Rational Software para desarrollar el Lenguaje Unificado de Modelado (UML) junto a Ivar Jacobson y Grady Booch, fusionando sus metodologías OMT, OOSE y Booch en el Proceso Unificado Racional (RUP). OMT se centra en tres modelos: el modelo de objetos, el modelo dinámico y el modelo funcional.
La metodología RUP (Proceso Unificado Racional) se basa en un conjunto de habilidades por equipo y modelos de documentos clave. Utiliza un proceso iterativo e incremental para el desarrollo de software, dividiendo el proyecto en fases de ingeniería de negocios, requerimientos, análisis y diseño, implementación, pruebas y disciplinas de soporte como gestión de proyectos y configuración. Los roles se distribuyen entre los miembros del proyecto para definir sus tareas y responsabilidades.
Similar a Métodos de evaluación de arquitectura a un atributo específico (20)
Métodos de evaluación de arquitectura a un atributo específico
1. PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR
SEDE IBARRA
ESCUELA DE INGENIERÍA
Métodos de evaluación de arquitectura de un atributo específico
Evaluación de Software
Autores: Gonzaga Martínez Evelyn Estefanía
Lema Males Leonel Efraín
Ibarra - Mayo 2014
2. Métodos de Evaluación de Arquitectura de un Atributo Específico
2
Resumen
En el presente documento se realiza un estudio del estado del arte de la evaluación de arquitecturas de
software de un atributo específico. Para ir introduciéndose en el tema se define que es la evaluación de
arquitecturas, sus características, objetivos que persigue. Se hace además un análisis de cuándo y por
qué una determinada arquitectura debe ser evaluada y los beneficios que reporta.
También se realiza un análisis acerca de los métodos de evaluación de arquitectura de software de un
atributo específico, los cuales son: Architecture Level Modifiability Analysis (ALMA), Performance
Assessment of Software Architecture (PASA), Scenario based Architecture Level UsabiliTy Analysis
(SALUTA) y Survivable Network Analysis (SNA).
Abstract
In this paper a study of the state of the art of assessing software architectures of a specific attribute is
performed. To be introduced in the field is defined to be the evaluation of architectures, characteristics,
aims. It also makes an analysis of when and why a particular architecture should be evaluated and the
benefits.
An analysis of the methods for evaluating software architecture of a specific attribute is also performed,
which are: Architecture Level Modifiability Analysis (ALMA), Performance Assessment of Software
Architecture (PASA), Scenario based Architecture Level Usability Analysis (SALUTA) and Survivable
Network Analysis (SNA).
3. Métodos de Evaluación de Arquitectura de un Atributo Específico
3
Índice de Contenidos
¿QUÉ ES UNA EVALUACIÓN?............................................................................................................. 4
OBJETIVOS DE EVALUAR ARQUITECTURAS.................................................................................... 4
CARACTERÍSTICAS DE UNA EVALUACIÓN DE ARQUITECTURA.................................................. 4
¿POR QUÉ EVALUAR UNA ARQUITECTURA? .................................................................................. 4
¿CUÁNDO UNA ARQUITECTURA PUEDE SER EVALUADA? .......................................................... 5
¿QUIÉNES PARTICIPAN EN UNA EVALUACIÓN? ............................................................................ 5
TÉCNICAS DE EVALUACIÓN............................................................................................................... 6
BENEFICIOS DE REALIZAR UNA EVALUACIÓN ARQUITECTÓNICA ............................................ 6
SALIDAS DE UNA EVALUACIÓN ARQUITECTÓNICA ...................................................................... 7
PASOS BÁSICOS PARA UNA EVALUACIÓN ....................................................................................... 7
ARCHITECTURE LEVEL MODIFIABILITY ANALYSIS (ALMA) ......................................................... 7
PERFORMANCE ASSESSMENT OF SOFTWARE ARCHITECTURE (PASA) ..................................... 9
SCENARIO BASED ARCHITECTURE LEVEL USABILITY ANALYSIS (SALUTA)............................ 12
SURVIVABLE NETWORK ANALYSIS (SNA) ....................................................................................... 14
REFERENCIAS ..................................................................................................................................... 18
Índice de Figuras
FIGURA 1: CLASIFICACIÓN DE LAS TÉCNICAS............................................................................... 6
FIGURA 2: MÉTODO ALMA................................................................................................................. 9
FIGURA 3: MÉTODO PASA ................................................................................................................ 12
FIGURA 4: MÉTODO SALUTA ........................................................................................................... 14
FIGURA 5: MÉTODO SNA .................................................................................................................. 16
Índice de Tablas
TABLA 1: CUADRO COMPARATIVO ENTRE MÉTODOS DE EVALUACIÓN ALMA, PASA,
SALUTA Y SNA ..................................................................................................................................... 17
4. Métodos de Evaluación de Arquitectura de un Atributo Específico
4
Marco Teórico
¿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. (Yoan Arlet Carrascoso Puebla,
2009)
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 stakeholders1
.
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
1
El término agrupa a trabajadores, organizaciones sociales, accionistas y proveedores, entre muchos otros actores clave que
se ven afectados por las decisiones de una empresa.
http://www.guioteca.com/rse/que-son-los-stakeholders/
5. Métodos de Evaluación de Arquitectura de un Atributo Específico
5
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 término “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
6. Métodos de Evaluación de Arquitectura de un Atributo Específico
6
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
o Cuestionarios. Abiertas. Temprana
o Checklists. Especifico del Dominio de la aplicación.
o Escenarios. Especificas del Sistema. Arquitectura avanzada.
Measuring techniques. Sugiere hacerle medidas cuantitativas a la arquitectura.
o Utiliza métricas arquitectónicas, como acoplamiento, cohesividad en los
módulos, profundidad en herencias, modificabilidad.
o Simulaciones, Prototipos, y Experimentos.
Figura 1: Clasificación de las Técnicas
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.
7. Métodos de Evaluación de Arquitectura de un Atributo Específico
7
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.
Architecture Level Modifiability Analysis (ALMA)
El atributo de calidad que analiza ALMA, es la facilidad de modificación. Esto se refiere a la
capacidad de un sistema para ser ajustado debido a cambios en requerimientos, o en el entorno,
8. Métodos de Evaluación de Arquitectura de un Atributo Específico
8
así como la adición de nueva funcionalidad. ALMA es el resultado de los trabajos de
investigación realizados por Bengtsson y Lassing. (Bengtsson, 2004)
ALMA es un método de evaluación orientado a metas. Existen tres para las que se puede usar:
Predicción del costo de mantenimiento. Consiste en estimar el esfuerzo requerido para
modificar la arquitectura a cambios requeridos en un futuro.
Evaluación de riesgos. Identifica los tipos de cambios que pueden ser complejos o que
sean inflexibles en la arquitectura de software.
Selección de un conjunto de arquitecturas. Compara dos o más arquitecturas propuestas
y selecciona aquella que proporcione mayor soporte a cambios.
ALMA puede utilizarse una vez que concluye la especificación de la arquitectura (evaluación
clásica), o aun cuando la arquitectura ya ha sido implementada (evaluación tardía). Este método
se apoya en el uso de escenarios de cambio, los cuales describen eventos posibles que
provocarían cambios al sistema, y cómo se llevarían a cabo éstos.
Este método se realiza a través de los siguientes pasos:
1. Definir la meta de evaluación. Dependiendo del objetivo de la evaluación, se selecciona
alguna de las tres metas.
2. Describir la arquitectura de software. Se colecta la información más relevante de la
arquitectura: sus principales componentes, las relaciones entre éstos, así como las
relaciones con el entorno del sistema.
3. Obtener escenarios. Se definen los escenarios de cambio y se agrupan en categorías. Se
eligen aquellos escenarios relacionados con el propósito de evaluación. Por ejemplo: si
la meta es estimar el esfuerzo de mantenimiento, se recomienda seleccionar aquellos
escenarios que corresponden a los cambios que tienen una alta probabilidad de que
ocurran durante la vida operacional del sistema.
9. Métodos de Evaluación de Arquitectura de un Atributo Específico
9
4. Evaluar escenarios. Se realiza un análisis de impacto, que consiste en identificar los
componentes afectados por los escenarios previamente definidos, determinar el efecto
del cambio sobre los componentes, así como determinar los efectos del cambio en otros
componentes. Los resultados de este análisis se deben expresar ya sea de manera
cuantitativa o cualitativa.
5. Interpretar resultados. Finalmente se interpretan los resultados, así como las
conclusiones del análisis dependiendo de la meta de evaluación seleccionada.
Figura 2: Método ALMA
Performance Assessment of Software Architecture (PASA)
El atributo de calidad que analiza PASA, es el desempeño. Que se interesa por conocer, qué
tanto tiempo le toma al sistema de software responder cuando uno o varios eventos ocurren, así
como determinar el número de eventos procesados en un intervalo de tiempo dado. PASA es el
trabajo resultante de Williams y Smith (Williams, 2002), y utiliza diversas técnicas para la
evaluación, tales como la aplicación de estilos arquitectónicos, anti-patrones, guías de diseño y
modelos.
10. Métodos de Evaluación de Arquitectura de un Atributo Específico
10
Al igual que ALMA, PASA se basa en escenarios. Asimismo, puede aplicarse una vez que la
arquitectura se ha especificado, o posteriormente, cuando ya ha sido implementada. Los
escenarios generados en este método proveen una medida de razonamiento con respecto al
desempeño del sistema. Si se requieren análisis más detallados, los escenarios sirven como
punto de partida para construir modelos de desempeño.
Para utilizar este método, la arquitectura de software debe estar previamente documentada. En
caso de que se encuentre parcialmente documentada, es necesario extraer la información
faltante de los miembros del equipo, así como de códigos fuente.
Los pasos para llevar a cabo este método son:
1. Presentar el método de evaluación. Se comunica al equipo y directivos el objetivo de la
evaluación, y se explica el método PASA.
2. Presentar la arquitectura. El equipo de desarrollo presenta la arquitectura actual de una
manera general y sin entrar en detalles.
3. Identificar casos de uso críticos. Se seleccionan los casos de uso que son importantes
para la operación del sistema, así como aquellos que demandan una respuesta de tiempo
rápida para el usuario, u otros que presentan algún riesgo de desempeño. Recordemos
que un caso de uso puede contener varios escenarios, que describen las diferentes formas
en que se puede realizar el caso de uso. Los escenarios se especifican en UML como
diagramas de secuencia.
4. Seleccionar los escenarios de desempeño principales. Por cada caso de uso crítico, se
debe identificar los escenarios significativos con respecto al desempeño.
5. Identificar objetivos de desempeño. Por cada escenario de desempeño principal, se debe
especificar al menos un objetivo de desempeño. Mismos que pueden ser expresados de
distintas maneras. Por ejemplo: expresarlos en tiempo de respuesta, capacidad de
respuesta, restricciones o utilización de recursos. Para poder medirlo, el objetivo de
desempeño debe ser cuantitativo.
11. Métodos de Evaluación de Arquitectura de un Atributo Específico
11
6. Clarificar la arquitectura y discutirla. En este paso se estudia más a detalle la
arquitectura, por lo que se tienen reuniones con el arquitecto y equipo de desarrollo para
aclarar dudas. Si existe información acerca del desempeño del sistema, se colectan
métricas.
7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para analizar el
desempeño de la arquitectura. Por ejemplo: se identifican estilos arquitectónicos, con la
finalidad de detectar efectos negativos en el desempeño, se identifican anti-patrones de
desempeño que documentan problemas comunes. Se elaboran modelos de desempeño
con el objetivo de identificar problemas en la arquitectura.
8. Identificar alternativas. Si se encontraron problemas de desempeño, se identifican
alternativas de solución. Estas pueden incluir el cambio de estilo arquitectónico,
modificar la arquitectura para eliminar anti-patrones de desempeño, o alternativas para
optimizar la interacción entre componentes.
9. Presentar resultados. Finalmente se elabora un documento con los resultados de la
evaluación que incluye los objetivos de la evaluación, hallazgos encontrados, pasos
específicos a seguir y recomendaciones.
12. Métodos de Evaluación de Arquitectura de un Atributo Específico
12
Figura 3: Método PASA
Las personas involucradas durante la evaluación son: el arquitecto, el equipo de desarrollo y en
algunos momentos, el gerente(s) de proyecto. Si se realiza de forma intensiva, la evaluación
completa se puede llevar acabo en una semana. PASA se considera un método de evaluación
maduro, ya que ha sido probado en varios dominios de aplicación como sistemas web,
aplicaciones financieras y sistemas en tiempo real.
Scenario based Architecture Level UsabiliTy Analysis (SALUTA)
SALUTA es el primer método desarrollado para evaluar la arquitectura desde la perspectiva de
la facilidad de uso del sistema. SALUTA es el resultado de los trabajos de investigación hechos
por Folmer y Gurp. (Folmer)
Este método hace uso de un marco de referencia elaborado por los mismos autores en el que se
expresan las relaciones que existen entre la facilidad de uso y la arquitectura de software. (Eelke
Folmer, 2003) Este marco de referencia incluye un conjunto integrado de soluciones de diseño
tales como patrones de diseño y propiedades que tienen un efecto positivo sobre la facilidad de
uso en un sistema de software. SALUTA analiza cuatro atributos que están directamente
relacionados con la facilidad de uso en un sistema de software, estos son: facilidad de
13. Métodos de Evaluación de Arquitectura de un Atributo Específico
13
aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Se recomienda efectuar la
evaluación una vez que la especificación de la arquitectura ha finalizado, pero antes de que se
implemente.
Este método se basa en escenarios de uso, los cuales se agrupan en uno o más perfiles de uso.
Cada uno representa la facilidad de uso requerida por el sistema de software.
SALUTA está compuesto por los siguientes pasos, que se ilustran en la figura 3.
1. Crear perfiles de uso. Se identifican los usuarios y se organizan en categorías. Luego se
identifican las tareas más significativas del sistema y el contexto donde será usado el
sistema, se determinan los valores para los atributos: facilidad de aprendizaje, eficiencia
de uso, confiabilidad y satisfacción. Para reflejar la diferencia en la prioridad de los
atributos, se asigna a cada uno un valor numérico no repetido entre 1 y 4. Por último, se
seleccionan los escenarios más representativos que tienen mayor prioridad con respecto
a sus atributos.
2. Describir la facilidad de uso proporcionada. Se colecta la información de la arquitectura
de software para determinar el nivel de soporte en los escenarios de uso. Esto se realiza
efectuando un análisis basado en patrones, o basado en propiedades. En ambos análisis
se utiliza el marco de referencia para determinar la presencia de patrones o propiedades
de facilidad de uso en la arquitectura a evaluar.
3. Evaluar escenarios. Se evalúa cada uno de los escenarios que forman parte del perfil de
uso. Por cada escenario se analizan los patrones y propiedades previamente
identificados. Se recomienda usar el marco de referencia para analizar cómo un patrón,
o propiedad particular afecta a un atributo específico en un escenario de uso.
Finalmente, se expresan de manera cuantitativa los resultados del análisis, que indican
el grado de soporte de facilidad de uso en cada uno de los escenarios.
4. Interpretar resultados. En este paso se obtienen los resultados de la evaluación, que
contienen el grado de facilidad de uso que soporta la arquitectura evaluada.
14. Métodos de Evaluación de Arquitectura de un Atributo Específico
14
Figura 4: Método SALUTA
Las personas involucradas durante la evaluación son el arquitecto de software, ingenieros de
requerimientos o ingenieros responsables por la facilidad de uso.
Survivable Network Analysis (SNA)
SNA es un método desarrollado por el CERT (Computer Emergency Response Team) que
forma parte del SEI. Este método ayuda a identificar la capacidad de supervivencia en un
sistema, analizando su arquitectura. La supervivencia, es la capacidad que tiene un sistema para
completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes. Un ejemplo de
la definición anterior es la siguiente: un cajero automático debe garantizar al usuario los
servicios esenciales aun cuando éste se encuentre en presencia de algún ataque externo o falla
interna. (Mead, 2000)
SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema:
Resistencia. Es la capacidad del sistema para repeler ataques, fallas o accidentes.
Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes, y si estos
ocurren, evaluar los daños.
15. Métodos de Evaluación de Arquitectura de un Atributo Específico
15
Recuperación. Es la capacidad de mantener en operación los servicios esenciales en
presencia de ataques, fallas o accidentes.
Este método puede ser aplicado después de la especificación de una arquitectura, durante la
implementación de ésta, o posteriormente.
SNA se basa en escenarios de uso, e identifica dos tipos de escenarios. El primer tipo son los
escenarios normales, que se componen de una serie de pasos donde los usuarios invocan a
servicios y obtienen acceso a activos, tales como bases de datos. El segundo tipo de escenarios
son los de intrusión, en los que se representan diferentes tipos de ataques al sistema.
SNA está compuesto por los siguientes pasos:
1. Definición del sistema. En este paso se obtiene la misión del sistema, se discute el
entorno de uso en términos de capacidades y ubicaciones de los usuarios, se analizan
posibles riesgos que el sistema pueda presentar en condiciones adversas, finalmente se
analiza la arquitectura de software.
2. Definición de las capacidades esenciales. A continuación se seleccionan los servicios
esenciales y los activos que usan. Se deben seleccionar aquellos servicios y activos que
sean críticos para garantizar en condiciones adversas, la misión del sistema. Una vez
seleccionados, estos se trazan a través de la arquitectura, para identificar los
componentes que participan en proporcionar los servicios esenciales.
3. Definición de las capacidades que comprometen al sistema. En este paso se selecciona
un conjunto representativo de posibles ataques, basados en el entorno de operación del
sistema. Se definen los escenarios de intrusión y se trazan a través de la arquitectura,
para identificar componentes que comprometan la supervivencia del sistema, logrando
así el acceso y daño a éste.
4. Analizar la supervivencia. Finalmente se identifican los escenarios de intrusión que
contienen los componentes esenciales y que comprometen la supervivencia del sistema.
Por cada componente identificado se procede a analizarlo en términos de las
capacidades de resistencia, reconocimiento y recuperación. Estos análisis se colocan en
una tabla llamada: mapa de supervivencia, que contiene por cada escenario de intrusión,
16. Métodos de Evaluación de Arquitectura de un Atributo Específico
16
las estrategias de supervivencia actuales y las recomendadas con respecto a cada una de
las capacidades.
Figura 5: Método SNA
El resultado que se obtiene al final de la evaluación, es un documento que incluye
modificaciones recomendadas a la arquitectura, acompañadas del mapa de supervivencia. Las
personas involucradas durante la evaluación son: el arquitecto de software, el diseñador
principal, los propietarios del sistema y usuarios del mismo.
17. Métodos de Evaluación de Arquitectura de un Atributo Específico
17
Tabla 1: Cuadro comparativo entre métodos de evaluación ALMA, PASA, SALUTA y SNA
18. Métodos de Evaluación de Arquitectura de un Atributo Específico
18
Conclusiones
En este documento el método de evaluación ALMA, que se interesa por predecir la facilidad de
modificación en una arquitectura. PASA, que analiza en la arquitectura el desempeño del
sistema. SALUTA, que analizando una serie de atributos de calidad predice la facilidad de uso;
y SNA, que analiza en la arquitectura, la supervivencia de un sistema ante la presencia de
ataques, fallas o accidentes. La Tabla 1 presenta a manera de resumen, un cuadro comparativo
entre estos cuatro métodos de evaluación.
Referencias
Bengtsson, P. N. (2004). The Journal of Systems and Software. En Architecture-Level
Modifiability Analysis (Alma). (págs. 129-147).
Eelke Folmer, J. v. (2003). Investigating the Relationship Between Usability and Software
Architecture, Software process improvement and practice. Wiley.
Folmer, E. J. (s.f.). Scenario-Based Assessment of Software Architecture Usability. Portland .
Mead, N. R. (2000). Survivable Network Analysis Method. CMU/SEI.
Williams, L. G. (2002). PASASM: A Method for the Performance Assessment of Software
Architecture. Roma.
Yoan Arlet Carrascoso Puebla, E. C. (07 de 05 de 2009). GestioPolis. Recuperado el 20 de 05
de 2014, de http://www.gestiopolis.com/administracion-estrategia/procedimiento-para-
la-evolucion-de-las-arquitecturas-de-software.htm