Técnicas de Evaluación de Arquitectura de Software - Historial de revisiones

Haydee ciget.stgo en 16:20 30 jul 2013

2013-07-30T16:20:52Z

Yoangel jc.scu en 18:05 29 jun 2011

2011-06-29T18:05:15Z

Alexeijccmg en 14:08 28 jun 2011

2011-06-28T14:08:42Z

Haydee ciget.stgo en 16:59 4 may 2011

2011-05-04T16:59:59Z

Yoangel jc.scu en 17:40 22 abr 2011

2011-04-22T17:40:42Z

Yoangel jc.scu en 17:33 22 abr 2011

2011-04-22T17:33:41Z

Yoangel jc.scu: Página creada con '{{Desarrollo}}Las '''Técnicas de Evaluación de Arquitectura de Software''', utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte ...'

2011-04-22T16:12:41Z

Página creada con '{{Desarrollo}}Las '''Técnicas de Evaluación de Arquitectura de Software''', utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte ...'

Página nueva

{{Desarrollo}}Las '''Técnicas de Evaluación de Arquitectura de Software''',  utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].

<br>

== Introducción ==

Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. (Bosch, 2000) <br>

En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las arquitecturas de software. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño. (Bosch, 2000)

Existen diferentes técnicas de evaluación de arquitecturas de software: evaluación basada en escenarios, evaluación basada en simulación, evaluación basada en modelos matemáticos y evaluación basada en experiencia. (Bosch, 2000)

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 (Gómez, 2007) A continuación algunas de las técnicas más usadas.

== Evaluación Basada en Escenarios ==

Primeramente un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución de una tarea; un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño. (Kazman, y otros, 2003)

Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto es el que describe qué sucede en el sistema al momento del estímulo. La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado. (Kazman, y otros, 2003)

Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad. Su uso, no sólo es de importancia para efectos de la evaluación de arquitecturas de software. (Kazman, y otros, 2003) y (Carriere, y otros, 2007)

Entre las ventajas de su uso están:

*Son simples de crear y entender.
*Son poco costosos y no requieren mucho entrenamiento.
*Son efectivos.

Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de evaluación relevantes, a saber: el árbol de utilidad (Utility Tree, UT) propuesto por (Kazman, y otros, 2003) y los Perfiles (Profiles), propuestos por (Bosch, 2000)

=== Árbol de Utilidad (Utility Tree) ===

Un UT 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. (Kazman, y otros, 2005)

La intención de su uso es la identificación de los atributos de calidad más importantes para un proyecto particular. No existe un conjunto preestablecido de atributos, sino que son definidos por los involucrados en el desarrollo del sistema al momento de la construcción del árbol. El UT contiene como nodo raíz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del árbol, los cuales se refinan hasta la obtención de un escenario lo suficientemente concreto para ser analizado y otorgarle prioridad a cada atributo considerado. (Kazman, y otros, 2005)

Cada atributo de calidad perteneciente al árbol contiene una serie de escenarios relacionados, y una escala de importancia y dificultad asociada, que será útil para efectos de la evaluación de la arquitectura.

=== Perfiles (Profiles) ===

Un perfil (Profile) 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. Los perfiles tienen asociados dos formas de especificación: perfiles completos y perfiles seleccionados. (Bosch, 2000)

Los perfiles completos definen todos los escenarios relevantes como parte del perfil. Esto permite al ingeniero de software realizar un análisis de la arquitectura para el atributo de calidad estudiado de una manera completa, puesto que incluye todos los casos posibles. Su uso se reduce a sistemas relativamente pequeños y sólo es posible predecir conjuntos de escenarios completos para algunos atributos de calidad. (Bosch, 2000)

Los perfiles seleccionados se asemejan a la selección de muestras sobre una población en los experimentos estadísticos. Se toma un conjunto de escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad no es totalmente cierta por limitaciones prácticas, por lo que se fuerza la realización de una selección estructurada de elementos para el conjunto de muestra. Si bien es informal, permite hacer proposiciones científicamente válidas. (Bosch, 2000)

A pesar de todos los elementos definidos alrededor de dicha técnica de evaluación, ésta presenta como desventaja que 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. Es importante destacar que la definición de los casos de uso debe ser independiente del perfil de uso, debido a que los casos de uso permiten optimizar el diseño arquitectónico, y puede resultar una muestra no representativa de la población de escenarios para la evaluación de cierto atributo de calidad. La evaluación basada en escenarios puede ser empleada para comparar dos arquitecturas y para la evaluación absoluta de una arquitectura. La diferencia está en que la evaluación absoluta requiere mayor cantidad de datos estimados y cuantitativos necesarios para la evaluación, factor que dificulta en gran medida este tipo de evaluación. (Bosch, 2000)

== Fuentes ==

'''Bosch, J. 2000.''' ''Design & Use of Software Architectures''. s.l. : Adison-Wesley, 2000.

'''Carriere, J, Kazman, R y Woods, S. 2007'''. ''Toward a Discipline of Scenario based Architectural Engineering''. s.l. : Software Engineering Institute, Carnegie Mellon University, 2007. págs. 5-33. ISSN: 1573-7489.

'''Gómez, Omar Salvador. 2007.''' E''valuando Arquitecturas de Software. Parte 1''. Panorama General. México : México: Brainworx S.A, 2007.

'''Kazman, R, Bass, L y Clements, P. 2003'''. ''Software Architecture in Practice. 2da Edición''. s.l. : Addison-Wesley Professional, 2003. pág. 560. ISSN: 0321154959 .

'''Kazman, R, Clements, Paul y Klain, M. 2005'''. ''Evaluating Software Architectures.Methods and case studies. 1ra Edicición.'' s.l. : Adison-Wesley Professional, 2005. pág. 368. ISSN: 978-0201704822 .

[[Category:Ciencias_informáticas_y_Telecomunicaciones]]

@@ Línea 1: / Línea 1: @@
 {{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
 |imagen=tecnicas_de_evaluación_de_arquitectura.JPG
-|descripcion=Álgunas de las Técnicas de Evaluación de Arquitectura de Software
+|descripcion=Proceso genérico de evaluación basada en escenarios.
-}}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. requieren grandes esfuerzos por parte de los [[ingenieros de software]] para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
+}}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. Requieren grandes esfuerzos por parte de los ingenieros de [[software]] para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del Software.
 == Introducción  ==
 Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para la [[Arquitectura de software]]. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño.
@@ Línea 47: / Línea 46: @@
 == Véase También  ==
-[[Análisis de Arquitecturas de Software (SAAM)]].
+* [[Análisis de Arquitecturas de Software (SAAM)]].
-[[Architecture Trade-off Analysis Method (ATAM)]].
+* [[Architecture Trade-off Analysis Method (ATAM)]].
-[[Active Reviews for Intermediate Designs (ARID)]].
+* [[Active Reviews for Intermediate Designs (ARID)]].
-[[Architecture Level Modifiability Analysis (ALMA)]].
+* [[Architecture Level Modifiability Analysis (ALMA)]].
-[[Performance Assessment of Software Architecture (PASA)]].
+* [[Performance Assessment of Software Architecture (PASA)]].
-[[Scenario Based Architecture Level Usability Analysis (SALUTA)]].
+* [[Scenario Based Architecture Level Usability Analysis (SALUTA)]].
-[[Survivable Network Analysis  (SNA)]].
+* [[Survivable Network Analysis  (SNA)]].
 == Fuentes  ==
-'''Bosch, J. 2000.''' ''Design &amp; Use of Software Architectures''. s.l.&nbsp;: Adison-Wesley, 2000.
+* '''Bosch, J. 2000.''' ''Design &amp; Use of Software Architectures''. s.l.&nbsp;: Adison-Wesley, [[2000]].
-'''Carriere, J, Kazman, R y Woods, S. 2007'''. ''Toward a Discipline of Scenario based Architectural Engineering''. s.l.&nbsp;: Software Engineering Institute, Carnegie Mellon University, 2007. págs. 5-33. ISSN: 1573-7489.
+* '''Carriere, J, Kazman, R y Woods, S. 2007'''. ''Toward a Discipline of Scenario based Architectural Engineering''. s.l.&nbsp;: Software Engineering Institute, Carnegie Mellon University, [[2007]]. págs. 5-33. ISSN: 1573-7489.
-'''Gómez, Omar Salvador. 2007.''' E''valuando Arquitecturas de Software. Parte 1''. Panorama General. México&nbsp;: México: Brainworx S.A, 2007.
+* '''Gómez, Omar Salvador. 2007.''' E''valuando Arquitecturas de Software. Parte 1''. Panorama General. México&nbsp;: México: Brainworx S.A, 2007.
-'''Kazman, R, Bass, L y Clements, P. 2003'''. ''Software Architecture in Practice. 2da Edición''. s.l.&nbsp;: Addison-Wesley Professional, 2003. pág. 560. ISSN: 0321154959 .
+* '''Kazman, R, Bass, L y Clements, P. 2003'''. ''Software Architecture in Practice. 2da Edición''. s.l.&nbsp;: Addison-Wesley Professional, [[2003]]. pág. 560. ISSN: 0321154959 .
-'''Kazman, R, Clements, Paul y Klain, M. 2005'''. ''Evaluating Software Architectures.Methods and case studies. 1ra Edicición.'' s.l.&nbsp;: Adison-Wesley Professional, 2005. pág. 368. ISSN: 978-0201704822 .
+* '''Kazman, R, Clements, Paul y Klain, M. 2005'''. ''Evaluating Software Architectures.Methods and case studies. 1ra Edicición.'' s.l.&nbsp;: Adison-Wesley Professional, [[2005]]. pág. 368. ISSN: 978-0201704822 .
 [[Category:Ciencias_informáticas_y_Telecomunicaciones]]

@@ Línea 2: / Línea 2: @@
 |imagen=tecnicas_de_evaluación_de_arquitectura.JPG
 |descripcion=Álgunas de las Técnicas de Evaluación de Arquitectura de Software
-}}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
+}}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. requieren grandes esfuerzos por parte de los [[ingenieros de software]] para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
 <br>

@@ Línea 1: / Línea 1: @@
-{{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
+{{Normalizar}}{{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
 |imagen=tecnicas_de_evaluación_de_arquitectura.JPG
 |descripcion=Álgunas de las Técnicas de Evaluación de Arquitectura de Software
-}} Las '''Técnicas de Evaluación de Arquitectura de Software''',&nbsp; utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
+}}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
 <br>

@@ Línea 1: / Línea 1: @@
-{{Desarrollo}}Las '''Técnicas de Evaluación de Arquitectura de Software''',&nbsp; utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
+{{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
 <br>
@@ Línea 7: / Línea 10: @@
 Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. (Bosch, 2000) <br>
-En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las arquitecturas de software. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño. (Bosch, 2000)
+En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las [[Arquitecturas de software]]. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño. (Bosch, 2000)
 Existen diferentes técnicas de evaluación de arquitecturas de software: evaluación basada en escenarios, evaluación basada en simulación, evaluación basada en modelos matemáticos y evaluación basada en experiencia. (Bosch, 2000)

@@ Línea 1: / Línea 1: @@
-{{Normalizar}}{{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
+{{Ficha_Software|nombre=Técnicas de Evaluación de Arquitectura de Software.
 |imagen=tecnicas_de_evaluación_de_arquitectura.JPG
 |descripcion=Álgunas de las Técnicas de Evaluación de Arquitectura de Software
 }}'''Técnicas de Evaluación de Arquitectura de Software'''. Se utilizan para la evaluación de atributos de calidad. requieren grandes esfuerzos por parte de los [[ingenieros de software]] para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del [[Software]].
 == Introducción  ==
-Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. (Bosch, 2000) En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para la [[Arquitectura de software]]. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño. (Bosch, 2000)
+Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para la [[Arquitectura de software]]. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño.
-Existen diferentes técnicas de evaluación de arquitecturas de software: evaluación basada en escenarios, evaluación basada en simulación, evaluación basada en modelos matemáticos y evaluación basada en experiencia. (Bosch, 2000)
+Existen diferentes técnicas de evaluación de arquitecturas de software: evaluación basada en escenarios, evaluación basada en simulación, evaluación basada en modelos matemáticos y evaluación basada en experiencia.
-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 (Gómez, 2007) A continuación algunas de las técnicas más usadas.
+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. A continuación algunas de las técnicas más usadas.
 == Evaluación Basada en Escenarios  ==
-Primeramente un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución de una tarea; un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño. (Kazman, y otros, 2003)
+Primeramente un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución de una tarea; un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño.
-Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto es el que describe qué sucede en el sistema al momento del estímulo. La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado. (Kazman, y otros, 2003)
+Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto es el que describe qué sucede en el sistema al momento del estímulo. La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado.
-Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad. Su uso, no sólo es de importancia para efectos de la evaluación de arquitecturas de software. (Kazman, y otros, 2003) y (Carriere, y otros, 2007)
+Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad. Su uso, no sólo es de importancia para efectos de la evaluación de arquitecturas de software.
 Entre las ventajas de su uso están:
@@ Línea 28: / Línea 26: @@
 *Son efectivos.
-Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de evaluación relevantes, a saber: el árbol de utilidad (Utility Tree, UT) propuesto por (Kazman, y otros, 2003) y los Perfiles (Profiles), propuestos por (Bosch, 2000)
+Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de evaluación relevantes, a saber: el árbol de utilidad (Utility Tree, UT) y los Perfiles (Profiles).
 === Árbol de Utilidad (Utility Tree)  ===
-Un UT 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. (Kazman, y otros, 2005)
+Un UT 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.
-La intención de su uso es la identificación de los atributos de calidad más importantes para un proyecto particular. No existe un conjunto preestablecido de atributos, sino que son definidos por los involucrados en el desarrollo del sistema al momento de la construcción del árbol. El UT contiene como nodo raíz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del árbol, los cuales se refinan hasta la obtención de un escenario lo suficientemente concreto para ser analizado y otorgarle prioridad a cada atributo considerado. (Kazman, y otros, 2005)
+La intención de su uso es la identificación de los atributos de calidad más importantes para un proyecto particular. No existe un conjunto preestablecido de atributos, sino que son definidos por los involucrados en el desarrollo del sistema al momento de la construcción del árbol. El UT contiene como nodo raíz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del árbol, los cuales se refinan hasta la obtención de un escenario lo suficientemente concreto para ser analizado y otorgarle prioridad a cada atributo considerado.
 Cada atributo de calidad perteneciente al árbol contiene una serie de escenarios relacionados, y una escala de importancia y dificultad asociada, que será útil para efectos de la evaluación de la arquitectura.
@@ Línea 40: / Línea 38: @@
 === Perfiles (Profiles)  ===
-Un perfil (Profile) 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. Los perfiles tienen asociados dos formas de especificación: perfiles completos y perfiles seleccionados. (Bosch, 2000)
+Un perfil (Profile) 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. Los perfiles tienen asociados dos formas de especificación: perfiles completos y perfiles seleccionados.
-Los perfiles completos definen todos los escenarios relevantes como parte del perfil. Esto permite al ingeniero de software realizar un análisis de la arquitectura para el atributo de calidad estudiado de una manera completa, puesto que incluye todos los casos posibles. Su uso se reduce a sistemas relativamente pequeños y sólo es posible predecir conjuntos de escenarios completos para algunos atributos de calidad. (Bosch, 2000)
+[[Performance Assessment of Software Architecture (PASA)]].
-Los perfiles seleccionados se asemejan a la selección de muestras sobre una población en los experimentos estadísticos. Se toma un conjunto de escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad no es totalmente cierta por limitaciones prácticas, por lo que se fuerza la realización de una selección estructurada de elementos para el conjunto de muestra. Si bien es informal, permite hacer proposiciones científicamente válidas. (Bosch, 2000)
+[[Scenario Based Architecture Level Usability Analysis (SALUTA)]].
-A pesar de todos los elementos definidos alrededor de dicha técnica de evaluación, ésta presenta como desventaja que 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. Es importante destacar que la definición de los casos de uso debe ser independiente del perfil de uso, debido a que los casos de uso permiten optimizar el diseño arquitectónico, y puede resultar una muestra no representativa de la población de escenarios para la evaluación de cierto atributo de calidad. La evaluación basada en escenarios puede ser empleada para comparar dos arquitecturas y para la evaluación absoluta de una arquitectura. La diferencia está en que la evaluación absoluta requiere mayor cantidad de datos estimados y cuantitativos necesarios para la evaluación, factor que dificulta en gran medida este tipo de evaluación. (Bosch, 2000)
+[[Survivable Network Analysis  (SNA)]].
 == Fuentes  ==