Universidad Nacional Experimental Politécnica de la

Fuerza Armada Nacional Bolivariana

Núcleo Caracas
Ingeniería de Sistemas
Arquitectura del Software

METODOLOGÍA DE BOSCH Y ATAM

Profesor: Estudiante:
Nathalli Carrasquel David Azuaje
Deibis Contreras
Alexander López
Luis Meza

Caracas, noviembre de 2018

 CONTENIDO

INTRODUCCIÓN.......................................................................................................3
METODOLOGÍA BOSCH.........................................................................................4
1.1 CARACTERÍSTICAS DE LA METODOLOGÍA BOSCH..........................5
1.1.1 Técnicas de evaluación del modelo Bosch................................................5
1.1.2 Tipos de técnicas de evaluación del modelo Bosch..................................6
1.1.3 Definición de categorías de escenarios......................................................6
1.1.4 Los pasos de evaluación basada en simulación........................................7
1.1.5 Evaluación basada en modelos matemáticos............................................8
1.1.6 Evaluación basada en experiencia.............................................................9
METODOLOGÍA ATAM..........................................................................................9
2.1 Descripción de la metodología ATAM...........................................................10
2.1.1 Fase 1:........................................................................................................10
2.1.2 Fase 2:........................................................................................................10
2.1.3 Fase 3:........................................................................................................11
2.1.4 Fase 4.........................................................................................................11
2.2 Cuadro explicativo de las fases de la metodología ATAM...........................12
2.3 CARACTERÍSTICAS DE LA METODOLOGÍA ATAM..........................12
2.3.1 Las ideas básicas en las que se sustenta el método son las siguientes:. 13
CUADRO COMPARATIVO ENTRE METODOLOGÍA ATAM Y BOSCH....14
CONCLUSIONES.....................................................................................................15
REFERENCIAS BIBLIOGRÁFICAS....................................................................16
 INTRODUCCIÓN

Al momento de iniciar el desarrollo de un software se deben tomar en cuenta

diversos factores que contribuyen de forma directa e importante en la realización del
mismo, y a su vez, permiten la utilización efectiva de los recursos que están a
disposición para llevar a feliz término su materialización.

En el siguiente trabajo se va abordar la manera en que se realiza un software,

partiendo desde como incluye la valoración de los requisitos de calidad para una
arquitectura, que es la que se toman en cuenta durante la fase de diseño. Para este
tema se va tomar como medio de estudio la metodología de Bosch, quien muestra la
dificultad de especificar con detalle los requisitos de calidad, pero si encuentra que
los requisitos más importantes en la mayoría de las propuestas existentes presentan
alguna forma de lo que denomina perfil, y basándose en esa idea, propone perfiles de
los atributos de calidad y selecciona cinco atributos de calidad como los más
relevantes desde una perspectiva de ingeniería de sistemas software general.

Éste plantea, en su método de diseño de arquitecturas de software, que el

proceso de evaluación debe ser visto como una actividad iterativa, que forma parte
del proceso de diseño, también iterativo. Una vez que la arquitectura es evaluada,
pasa a una fase de transformación, asumiendo que no satisface todos los
requerimientos.
 METODOLOGÍA BOSCH

Un trabajo de gran interés en el ámbito de la arquitectura del software es el de

Jan Bosch, el cual, con su propuesta incluye la valoración de los requisitos de calidad
para una arquitectura, y no sólo la valoración de los requisitos funcionales. Estos
requisitos de calidad se deben valorar durante la fase de diseño de la arquitectura
software. Bosch muestra la dificultad de especificar con detalle los requisitos de
calidad, pero si encuentra que los requisitos más importantes en la mayoría de las
propuestas existentes presentan alguna forma de lo que denomina perfil (profile).
Basándose en esta idea, propone perfiles de los atributos de calidad y selecciona
cinco atributos de calidad como los más relevantes desde una perspectiva de
ingeniería de sistemas software general. Estos atributos son: Rendimiento,
Mantenibilidad, Fiabilidad, Seguridad Física y Seguridad de Acceso.

Este plantea, en su método de diseño de arquitecturas de software, que el

proceso de evaluación debe ser visto como una actividad iterativa, que forma parte
del proceso de diseño, también iterativo. Una vez que la arquitectura es evaluada,
pasa a una fase de transformación, asumiendo que no satisface todos los
requerimientos. Luego, la arquitectura transformada es evaluada de nuevo. El proceso
de evaluación propuesto por Bosch se divide en dos etapas, que son:

ETAPA I
Deben seleccionarse aquellos atributos que se consideran
1. Selección de cruciales para el éxito del sistema, y cuya satisfacción resulte
atributos de poco clara a nivel de arquitectura. Resulta necesario porque es
calidad. poco factible y poco útil evaluar todos los atributos de calidad,
dado que requiere una gran cantidad de tiempo.
2. Definición de Para cada atributo de calidad seleccionado, se definen los
los perfiles. perfiles respectivos para efectos de la evaluación.
3. Selección de Para la evaluación de los atributos de calidad dependientes del
una técnica de diseño de la arquitectura se recomienda utilizar la evaluación
evaluación. basada en escenarios, así como también los modelos basados en
métricas o modelos matemáticos.
 Los atributos de calidad operacionales (observables vía
ejecución) pueden evaluarse con técnicas de simulación o
modelos matemáticos. La selección de la técnica, y la
implementación concreta de ésta depende del objetivo y
exactitud de la evaluación.
ETAPA II
4. Ejecución de la Para cada atributo de calidad, las técnicas arrojan valores
evaluación cuantitativos.
Los resultados se resumen en una tabla que contiene el nivel
requerido, el nivel predicho, y un indicador, que puede tener
diversos significados: si el atributo se satisface o no, si necesita
ser negociado con el cliente, o existencia de alguna relación
5. Obtención de negativa con otro atributo de calidad. El arquitecto puede decidir
resultados. acerca de la realización de transformaciones sobre la arquitectura
actual, y efectuar una nueva evaluación. Una vez que concluye el
proceso de evaluación, con los resultados obtenidos es posible
decidir entre la continuación, renegociación o cancelación del
proyecto.

1.1 CARACTERÍSTICAS DE LA METODOLOGÍA BOSCH

1.1.1 Técnicas de evaluación del modelo Bosch

 1.1.2 Tipos de técnicas de evaluación del modelo Bosch
Técnica Instrumento de Evaluación
 Perfiles (profiles)
Basada en escenarios
 Utility Tree
 Lenguaje de descripción arquitectónica
Basada en simulación (ADL)
 Modelos de colas
Basadas en modelos  Cadenas de Markov
matemáticos  Reliability Block Diagram
 Intuición y experiencia
Basada en experiencia  Tradición
 Proyectos similares

1.1.3 Definición de categorías de escenarios

Bosch establece que la definición de categorías de escenarios divide la población
de escenarios en poblaciones más pequeñas, que cubren aspectos particulares del
sistema. La selección y definición de escenarios para cada categoría selecciona un
conjunto de escenarios representativo para la subpoblación. Luego, en la asignación
del peso a los escenarios, dependiendo del perfil, el peso de un escenario tiene
diferentes significados.

La técnica de evaluación basada en escenarios es dependiente de manera directa

del perfil definido para el atributo de calidad que va a ser evaluado. La efectividad de
la técnica es altamente dependiente de la representatividad de los escenarios. El autor
propone que existe la evaluación de funcionalidad basada en escenarios, y es utilizada
en el diseño orientado a objetos para especificar comportamiento del sistema. La
diferencia entre este tipo de evaluación y la evaluación arquitectónica basada en
escenarios radica en que la última utiliza los escenarios para evaluar atributos de
calidad, en lugar de verificar o describir funcionalidad.

Bosch explica que la técnica consiste en dos etapas: análisis de impacto y

predicción de atributos de calidad. El análisis de impacto toma como entrada el perfil
y la arquitectura de software. Para cada escenario del perfil, se evalúa el impacto de la
arquitectura y se obtienen los resultados que serán usados en la etapa de predicción de
atributos de calidad, donde se pronostica el valor del atributo de calidad estudiado de
acuerdo a las métricas existentes.

1.1.4 Los pasos de evaluación basada en simulación

Los pasos de evaluación basada en simulación según Bosch son los siguientes
1. Definición e implementación del contexto. Consiste en identificar las
interfaces de la arquitectura de software con su contexto, y decidir cómo será
simulado el comportamiento del contexto en tales interfaces.
2. Implementación de los componentes arquitectónicos. La descripción del
diseño arquitectónico debe definir, por lo menos, las interfaces y las
conexiones de los componentes, por lo que estas partes pueden ser tomadas
directamente de la descripción de diseño. El comportamiento de los
componentes en respuesta a eventos sobre sus interfaces puede no ser
especificado claramente, aunque generalmente existe un conocimiento común
y es necesario que el arquitecto lo interprete, por lo que éste decide el nivel de
detalle de la implementación.
3. Implementación del perfil. Dependiendo del atributo de calidad que el
arquitecto de software intenta evaluar usando simulación, el perfil asociado
necesitará ser implementado en el sistema.  El arquitecto de software debe ser
capaz de activar escenarios individuales, así como también ejecutar un perfil
completo usando selección aleatoria, basado en los pesos normalizados de los
mismos.
4. Simulación del sistema e inicio del perfil. El arquitecto de software ejecutará
la simulación y activará escenarios de forma manual o automática, y obtendrá
resultados de acuerdo al atributo de calidad que está siendo evaluado.
Predicción de atributos de calidad. Dependiendo del tipo de simulación y del
atributo de calidad evaluada, se puede disponer de cantidades excesivas de
 datos, que requieren ser condensados. Esto permite hacer conclusiones acerca
del comportamiento del sistema.
1.1.5 Evaluación basada en modelos matemáticos
Jan Bosch establece que la evaluación basada en modelos matemáticos se utiliza
para evaluar atributos de calidad operacionales. Permite una evaluación estática de
los modelos de diseño arquitectónico, y se presentan como alternativa a la
simulación, dado que evalúan el mismo tipo de atributos. Ambos enfoques pueden ser
combinados, utilizando los resultados de uno como entrada para el otro.
El proceso de evaluación basada en modelos matemáticos sigue los siguientes
pasos:
1. Selección y adaptación del modelo matemático. La mayoría de los centros de
investigación orientados a atributos de calidad han desarrollado modelos
matemáticos para medir sus atributos de calidad, los cuales tienden a ser muy
elaborados y detallados, así como también requieren de cierto tipo de datos y
análisis. Parte de estos datos requeridos no están disponibles a nivel de
arquitectura, y la técnica requiere mucho esfuerzo para la evaluación
arquitectónica, por lo que el arquitecto de software se ve obligado a adaptar el
modelo.
2. Representación de la arquitectura en términos del modelo. El modelo
matemático seleccionado y adaptado no asume necesariamente que el sistema
que intenta modelar consiste de componentes y conexiones.  Por lo tanto, la
arquitectura necesita ser representada en términos del modelo.
3. Estimación de los datos de entrada requeridos. El modelo matemático aun
cuando ha sido adaptado, requiere datos de entrada que no están incluidos en
la definición básica de la arquitectura. Es necesario estimar y deducir estos
datos de la especificación de requerimientos y de la arquitectura diseñada.
Predicción de atributos de calidad. Una vez que la arquitectura es expresada
en términos del modelo y se encuentran disponibles todos los datos de entrada
requeridos, el arquitecto está en capacidad de calcular la predicción resultante
del atributo de calidad evaluado. Entre las desventajas que presenta esta
 técnica se encuentra la inexistencia de modelos matemáticos apropiados para
los atributos de calidad relevantes y el hecho de que el desarrollo de un
modelo de simulación completo puede requerir esfuerzos sustanciales.
1.1.6 Evaluación basada en experiencia
En este tipo de evaluación establece que en muchas ocasiones los arquitectos e
ingenieros de software otorgan valiosas ideas que resultan de utilidad para la evasión
de decisiones erradas de diseño. Aunque todas estas experiencias se basan en
evidencia anecdótica; es decir, basada en factores subjetivos como la intuición y la
experiencia. Sin embargo, la mayoría de ellas puede ser justificada por una línea
lógica de razonamiento, y pueden ser la base de otros enfoques de evaluación.
Existen dos tipos de evaluación basada en experiencia: la evaluación informal, que
es realizada por los arquitectos de software durante el proceso de diseño, y la
realizada por equipos externos de evaluación de arquitecturas.

METODOLOGÍA ATAM

Según Kazman et al. (2001), el Método de Análisis de Acuerdos de

Arquitectura ATAM (Architecture Trade-off Analysis Method), está inspirado en tres
áreas distintas: los estilos arquitectónicos, el análisis de atributos de calidad y el
método de evaluación SAAM. El nombre del método ATAM 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;
esto es, los tipos de acuerdos que se establecen entre ellos.

El método se concentra en la identificación de los estilos arquitectónicos o

enfoques arquitectónicos utilizados. Kazman y su equipo proponen el término
enfoque arquitectónico dado que no todos los arquitectos están familiarizados con el
lenguaje de estilos arquitectónicos, aun haciendo uso indirecto de estos. De cualquier
forma, estos elementos representan los medios empleados por la arquitectura para
alcanzar los atributos de calidad, así como también permiten describir la forma en la
que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas,
entre otros.

El corazón de ATAM consiste en la ejecución de nueve pasos que se dividen en

cuatro grupos que su vez, se realizan en el tiempo en cuatro fases diferenciadas. Si
bien la numeración de pasos sugiere linealidad, la ejecución de los mismos no
necesariamente es un proceso en cascada estricto, ya que se podrá volver a pasos
anteriores o saltar hacia adelante a pasos posteriores, o inclusive iterar entre pasos
según sea necesario. Los cuatro grupos en que se dividen los nueve pasos definidos
consisten en un primer grupo de presentación, donde se intercambia información del
sistema, un segundo grupo de investigación y análisis, donde se valoran los atributos
de calidad claves uno a uno con las propuestas arquitectónicas, un tercer grupo de
pruebas donde se revisan los resultados obtenidos contra las necesidades relevantes
de los stakeholders, y un cuarto y último grupo donde se presentan los resultados del
ATAM.
2.1 Descripción de la metodología ATAM
2.1.1 Fase 1: Se realizan las actividades correspondientes a los grupos de
presentación e investigación y análisis. El grupo de presentación se compone de tres
pasos: 1. Presentar el ATAM, 2. Presentar las pautas del negocio y 3. Presentar la
Arquitectura. En el primer paso el equipo de ATAM presenta el método a los
stakeholders explicando el proceso a seguir y el involucramiento y responsabilidad de
cada uno en el proyecto. Se detallan los pasos a seguir, las técnicas a utilizar y los
resultados a obtener. En el segundo paso un director de proyecto o gerente presenta el
sistema desde el punto de vista del negocio, al equipo de ATAM y a los stakeholders,
detallando principales funcionalidades, restricciones y metas definidas para el
sistema. En el tercer paso el Arquitecto presenta la Arquitectura de Software definida
incluyendo por lo menos los estilos utilizados, otros sistemas con que se debe
interactuar, restricciones técnicas de software como por ejemplo uso de sistema
operativo. Si se cuenta con un documento de Software Architecture Description
(SAD) el Arquitecto debería basar su explicación en las distintas vistas contenidas en
el mismo.
2.1.2 Fase 2: El segundo grupo de investigación y análisis se compone también de
tres pasos: 4. Identificar las propuestas arquitectónicas, 5. Generar el árbol de utilidad
de los atributos de calidad y 6- Analizar las propuestas arquitectónicas. En el cuarto
paso el equipo de ATAM le pide al Arquitecto que identifique las propuestas
arquitectónicas o estilos de arquitectura utilizados, ya que éstos definirán las
estructuras importantes definidas para el sistema y las características implicadas. En
el quinto paso se genera el árbol de utilidad donde principalmente el Arquitecto pero
también los principales stakeholders, identifican, priorizan y refinan los
requerimientos de atributos de calidad más importantes del sistema, según se
mencionó previamente, identificando los escenarios en el árbol y su importancia en
las dos dimensiones definidas. En el sexto paso se analizan las propuestas
arquitectónicas según el árbol de utilidad generado, esto es, que tan adecuados son el
uno para el otro, evaluando como cada propuesta arquitectónica influye en la
obtención o no del atributo de calidad requerido, e identificando los riesgos, no
riesgos, puntos de sensibilidad y concesión asociados a dicha evaluación.

2.1.3 Fase 3: En la Fase 3 se realizan las actividades incluidas en el tercer grupo de

pruebas y el cuarto grupo de informes, que completan los tres pasos restantes. El
grupo de pruebas se compone de dos pasos: 7. Lluvia de ideas y 8. Analizar las
propuestas arquitectónicas. En el séptimo paso se confirman e identifican nuevos
escenarios según varios stakeholders involucrados, los que también se priorizan y se
comparan con los identificados en el árbol de utilidad. Pueden suceder tres casos: el
escenario ya está en el árbol de utilidad, no está pero encaja en alguna rama y se
convierte en una nueva hoja, no está y no encaja en ninguna rama, lo que significa
que no había sido considerado previamente. En el octavo paso se realiza lo mismo
que en el sexto paso para el nuevo árbol de utilidad con todos los escenarios
incluidos.
2.1.4 Fase 4: esta fase está compuesta por el grupo de Informenes finales y se
compone de un solo paso: 9. Presentar los resultados. En el noveno paso el equipo de
ATAM presenta los resultados a los stakeholders y entrega la documentación
correspondiente a las salidas del ATAM: documento de propuestas arquitectónicas,
conjunto de escenarios priorizados, conjunto de preguntas basadas en los atributos,
árbol de utilidad, los riesgos descubiertos, los no riesgos documentados, los puntos de
sensibilidad y de concesión encontrados, más la relación entre los riesgos encontrados
y su impacto en las pautas del negocio definidas.
2.2 Cuadro explicativo de las fases de la metodología ATAM

Fase 1: Presentación
El líder de evaluación describe el método a los participantes, trata
1. Presentación del ATAM
de establecer las expectativas y responde a las preguntas propuestas.
2. Presentación de las metas del Se realiza la descripción de las metas del negocio que motivan el
negocio esfuerzo, y aclara que se persiguen objetivos de tipo arquitectónico.
3. Presentación de la El arquitecto describe la arquitectura, enfocándose en cómo ésta
arquitectura cumple con los objetivos del negocio.
Fase 2: Investigación y análisis
4. Identificación de los
Estos elementos son detectados, pero no analizados.
enfoques arquitectónicos
Se solicitan los atributos de calidad que engloban la “utilidad” del
sistema como desempeño, disponibilidad, seguridad,
[Link]ón del Utility Tree modificabilidad, usabilidad, etc., especificados en forma de
escenarios. Se anotan los estímulos y respuestas, así como se
establece la prioridad entre ellos.
Con base en los resultados del establecimiento de prioridades del
6. Análisis de los enfoques paso anterior, se analizan los elementos del paso 4. En este paso se
arquitectónicos identifican riesgos arquitectónicos, puntos de sensibilidad y puntos
de balance.
Fase 3: Pruebas
7. Lluvia de ideas y
Con la colaboración de todos los involucrados, se complementa el
establecimiento de prioridad de
conjunto de escenarios.
escenarios.
Este paso repite las actividades del paso 6, haciendo uso de los
8. Análisis de los enfoques
resultados del paso 7. Los escenarios son considerados como casos
arquitectónicos
de prueba para confirmar el análisis realizado hasta el momento.
Fase 4: Reporte
9. Presentación de los Basado en la información recolectada a los largo de la evaluación
resultados ATAM, se presentan los hallazgos a los participantes.
2.3 CARACTERÍSTICAS DE LA METODOLOGÍA 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: a) Identificar los estilos arquitectónicos o enfoques
arquitectónicos utilizados. b) Reconocer los atributos de calidad alcanzados en
la arquitectura. c) Describir como el sistema puede crecer, responder a
cambiar, e integrarse con otros sistemas.
 Bien puede decirse que este método es similar al SAAM solo que se
diferencia en que ATAM incorpora: a) La caracterización de los atributos de
calidad. b) 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.

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

CUADRO COMPARATIVO ENTRE METODOLOGÍA ATAM Y

BOSCH
ATAM BOSCH
Atributos de calidad Modificabilidad  Seleccionados por el
contemplados Seguridad arquitecto, de acuerdo a la
Confiabilidad importancia sobre el sistema
Desempeño
Objetos analizados Estilos arquitectónicos Vistas arquitectónicas
Documentación Estilos arquitectónicos
Flujo de datos Patrones arquitectónicos
Vistas Arquitectónicas Patrones de diseño
Patrones de idioma
Etapas del proyecto Luego de que el diseño de la Luego de que el diseño de la
en las que se aplica arquitectura ha sido establecido arquitectura ha sido establecido
Enfoques utilizados Utility Tree y lluvia de ideas
para articular los requerimientos de Análisis de perfiles (profiles)
calidad.
Análisis arquitectónico que
detecta puntos sensibles, puntos de
balance y riesgos.

SEMEJANZAS ENTRE METODOLOGÍAS (ATAM/BOSCH)

En líneas generales, las metodologías tienen la necesidad de construir

herramientas que permitan hacer del diseño y el análisis de las arquitecturas de
software, una actividad más confiable y mejor documentada.

El proceso de recolección, mantenimiento y validación de la información

arquitectónica es tedioso y altamente propenso a errores. Estos son precisamente los
candidatos a ser cubiertos por herramientas de esta índole.

Independientemente de la metodología implementada, la intención es obtener una

arquitectura con la documentación necesaria, y asegurar que el sistema cumple con
los servicios y la funcionalidad que espera el usuario, además de los atributos de
calidad asociados que deben cumplirse, y que dirigen las decisiones al momento de la
construcción de la arquitectura del sistema (Bredemeyer et al., 2002).
 CONCLUSIONES

Del trabajo realizado se extraen múltiples herramientas que se pueden utilizar

al momento de iniciar con el desarrollo de un software, todo ello tomando en cuenta
la secuencia de pasos de pasos que se deben cumplir para su buena utilización.

Utilizando ambas metodologías se puede determinar que dentro de las

bondades y limitaciones que poseen cada una de ellas, se puede efectuar el desarrollo
de los softwares partiendo desde las ideas ahí propuestas, sin embargo, cualquiera que
sea la elección para la realización; es decir, el proceso de recolección, mantenimiento
y validación de la información arquitectónica es tedioso y altamente propenso a
errores.

Es oportuno indicar, que independientemente de la metodología

implementada, la intención es obtener una arquitectura con la documentación
necesaria, y asegurar que el sistema cumple con los servicios y la funcionalidad que
espera el usuario, además de los atributos de calidad asociados que deben cumplirse,
y que dirigen las decisiones al momento de la construcción de la arquitectura del
sistema
 REFERENCIAS BIBLIOGRÁFICAS

H., Kazman, R., y Olson, D. (2001). From Requirements Negotiation to Software

Architectural Decisions. Software Engineering Institute, Carnegie Mellon
University. Obtenido el 15-08-2002 de:
[Link]
Herrera B. Ernesto A. (2011). “Jan Bosch” Extraído de:
[Link]
Camacho E., Cardeso F., y Nuñez G. (2004) “Arquitectura del Software – Guía de
Estudio”. Extraído en: [Link]
%20Arquitectura%[Link]
Delgado A., Castro A., y Germán M. (sin fecha de publicación) “Evaluación de
Arquitecturas de Software con ATAM (Architecture Tradeoff Analysis
Method): un caso de estudio” Extraído en: [Link]
2007/ponencias/CAL/[Link]
De autor desconocido (2016) “Método de Diseño de Arquitecturas de
Software Bosch” Extraído desde: [Link]
Bosch, J. (2000). “Design & Use of Software Architectures. Addison-Wesley”.
Extraído de:
[Link]
are_Architectures
Bredemeyer, D., & Malan, R. (2002). The Visual Architecting Process. White Paper.
Obtenido el 10-05-2002 de: [Link]
[Link]
 GLOSARIO

SAAM: Según Kazman et al. (2001), el Método de Análisis de Arquitecturas de

Software (Software Architecture Analysis Method, SAAM) es el primero que fue
ampliamente promulgado y documentado. El método fue originalmente creado para el
análisis de la modificabilidad de una arquitectura, pero en la práctica ha demostrado
ser muy útil para evaluar de forma rápida distintos atributos de calidad, tales como
modificabilidad, portabilidad, escalabilidad e integrabilidad.
Cadenas de Markov: En la teoría de la probabilidad, se conoce como cadena de
Márkov o modelo de Márkov a un tipo especial de proceso estocástico discreto en el
que la probabilidad de que ocurra un evento depende solamente del evento
inmediatamente anterior. Esta característica de falta de memoria recibe el nombre de
propiedad de Markov.
Perfiles (Profiles): Un perfil es un conjunto de escenarios, generalmente con alguna
importancia relativa asociada a cada uno de ellos. El uso de perfiles permite hacer
especificaciones más precisas del requerimiento para un atributo de calidad (Bosch,
2000). Los perfiles tienen asociados dos formas de especificación: perfiles completos
y perfiles seleccionados.
Reliability Block Diagram: Un diagrama de bloques de confiabilidad (RBD) es un
método esquemático para mostrar cómo la confiabilidad de los componentes
contribuye al éxito o fracaso de un sistema complejo. RBD también se conoce como
un diagrama de dependencia (DD).
Utility Tree: Según Kazman et al. (2001), un 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 con suficiente detalle el nivel de
prioridad de cada uno.
Stakeholders: Involucrados, parte interesada o interesados (del inglés stakeholder)
hace referencia a una persona, organización o empresa que tiene interés en una
empresa u organización dada. Desde un punto de vista simplista, los stakeholders se
pueden considerar participantes del sistema tratado, comprendiendo a los usuarios,
clientes, sistemas externos, etc.