Merge pull request #120 from ucudal/feature/analysis

Feature/analysis
ucudal · Dec 12, 2024 · 538c8ac · 538c8ac
2 parents ea671c4 + e2a7b83
commit 538c8ac
Show file tree

Hide file tree

Showing 19 changed files with 36 additions and 19 deletions.
diff --git a/2_Tecnicas_y_herramientas/2_5_1_Tacticas_disponibilidad.md b/2_Tecnicas_y_herramientas/2_5_1_Tacticas_disponibilidad.md
@@ -14,7 +14,7 @@ disponibilidad adecuadas y la combinación correcta de tácticas.
 
 La lista de tácticas está tomada de[^1]:
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 * **Monitoreo**. Refiere a la observación continua del estado de un componente

diff --git a/2_Tecnicas_y_herramientas/2_5_2_Tacticas_rendimiento.md b/2_Tecnicas_y_herramientas/2_5_2_Tacticas_rendimiento.md
@@ -11,7 +11,7 @@ restricción basada en el tiempo o en los recursos. El evento puede ser un event
 
 La lista de tácticas está tomada de[^1]:
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
       Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 * **Gestionar los pedidos de trabajo**. Esta táctica se refiere a cómo un

diff --git a/2_Tecnicas_y_herramientas/2_5_3_Tacticas_proteccion.md b/2_Tecnicas_y_herramientas/2_5_3_Tacticas_proteccion.md
@@ -8,7 +8,7 @@ Las tácticas para [protección](/4_Conceptos/4_Proteccion.md) pueden clasificar
 ampliamente como prevención de estados inseguros, detección de estados inseguros
 o remediación de estados inseguros[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
       Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Una condición previa lógica para evitar o detectar la entrada en un estado

diff --git a/2_Tecnicas_y_herramientas/2_5_4_Tacticas_seguridad.md b/2_Tecnicas_y_herramientas/2_5_4_Tacticas_seguridad.md
@@ -14,7 +14,7 @@ de alarmas— y disponen de mecanismos de recuperación —como sistemas de resp
 en ubicaciones remotas—. Estas medidas se agrupan en cuatro categorías de
 tácticas: detección, resistencia, reacción y recuperación[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 La lista de tácticas está tomada de [^1]:

diff --git a/2_Tecnicas_y_herramientas/2_5_5_Tacticas_facilidad_de_modificacion.md b/2_Tecnicas_y_herramientas/2_5_5_Tacticas_facilidad_de_modificacion.md
@@ -11,7 +11,7 @@ diferir el *binding*.
 
 La lista de tácticas está tomada de [^1]:
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 * **Separar módulos**. Consiste en dividir un componente de la arquitectura de

diff --git a/2_Tecnicas_y_herramientas/2_5_6_Tacticas_facilidad_de_despliegue.md b/2_Tecnicas_y_herramientas/2_5_6_Tacticas_facilidad_de_despliegue.md
@@ -11,7 +11,7 @@ gestionar el sistema desplegado.
 
 La lista de tácticas está tomada de [^1]:
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 * **Despliegue escalonado**. Consiste en desplegar nuevas versiones de

diff --git a/4_Conceptos/4_Atributos_de_calidad.md b/4_Conceptos/4_Atributos_de_calidad.md
@@ -8,7 +8,7 @@ sistema que se utilizan para indicar qué tan bien el sistema satisface las
 necesidades de los interesados más allá de la funcionalidad básica del
 sistema[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Algunos autores prefieren usar el término características arquitectónicas, en

diff --git a/4_Conceptos/4_Disponibilidad.md b/4_Conceptos/4_Disponibilidad.md
@@ -22,7 +22,7 @@ fallos](./4_Atributos_de_calidad.md#tolerancia-a-fallos) y [capacidad de
 recuperación](./4_Atributos_de_calidad.md#capacidad-de-recuperación)
 respectivamente.
 
-[^2]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^2]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Algo similar sucede en el Azure Well-Architected Framework[^3] donde el pilar es

diff --git a/4_Conceptos/4_Facilidad_de_despliegue.md b/4_Conceptos/4_Facilidad_de_despliegue.md
@@ -9,7 +9,7 @@ usuarios finales. Este proceso abarca desde la compilación y prueba del softwar
 hasta su configuración, instalación, y activación en un entorno de
 producción[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Las etapas principales del proceso de despliegue incluyen:

diff --git a/4_Conceptos/4_Facilidad_de_modificacion.md b/4_Conceptos/4_Facilidad_de_modificacion.md
@@ -6,7 +6,7 @@ La facilidad de modificación —o *modifiability* en inglés— es un atributo
 calidad de la arquitectura de software que baja el costo y el riesgo de hacer
 cambios[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 En ISO/IEC 25010 la facilidad de modificación es una sub-característica de la

diff --git a/4_Conceptos/4_Interaccion.md b/4_Conceptos/4_Interaccion.md
@@ -7,7 +7,7 @@ En el contexto de [componentes](./4_Componente.md) e
 relevantes son las transferencias de control —*calls*— o las transferencias de
 datos [^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Por ejemplo, la invocación local de procedimientos, funciones o métodos usando

diff --git a/4_Conceptos/4_Interfaz.md b/4_Conceptos/4_Interfaz.md
@@ -8,7 +8,7 @@ conectar [componentes](./4_Componente.md) en una arquitectura de software.
 Las definiciones y conceptos en este documento están tomados de [^1] a menos que
 se indique lo contrario.
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 ### Términos relacionados

diff --git a/4_Conceptos/4_Proteccion.md b/4_Conceptos/4_Proteccion.md
@@ -33,7 +33,7 @@ La definición de protección es similar en[^2], que la define como la capacidad
 de un sistema para evitar desviarse hacia estados que causen o conduzcan a
 daños, lesiones o pérdida de vidas a los actores de su entorno.
 
-[^2]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^2]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Estos estados inseguros pueden ser causados por una variedad de factores:

diff --git a/4_Conceptos/4_REST.md b/4_Conceptos/4_REST.md
@@ -9,7 +9,7 @@ seis restricciones impuestas sobre las [interacciones](./4_Interaccion.md) entre
 los [componentes](/4_Conceptos/4_Componente.md) de una arquitectura distribuida
 para un sistema de hipermedia a escala de Internet como el de la web[^1]:
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 * [Interfaz](/4_Conceptos/4_Interfaz.md) uniforme. Todas las interacciones son

diff --git a/4_Conceptos/4_Recurso.md b/4_Conceptos/4_Recurso.md
@@ -7,7 +7,7 @@ En el contexto de [componentes](./4_Componente.md) e
 construcciones que proveen puntos de interacción directa con un componente a
 través de una interfaz[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Más precisamente, en este contexto, son los datos u objetos que un componente

diff --git a/4_Conceptos/4_Rendimiento.md b/4_Conceptos/4_Rendimiento.md
@@ -7,7 +7,7 @@ arquitectura de software que define la capacidad de un sistema, producto o
 componente para cumplir con sus funciones dentro de los límites de tiempo
 aceptables[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Las operaciones en las computadoras llevan tiempo. Los cálculos en el procesador

diff --git a/4_Conceptos/4_Requerimiento_arquitectonicamente_significativo.md b/4_Conceptos/4_Requerimiento_arquitectonicamente_significativo.md
@@ -7,7 +7,7 @@ significant requirement* por sus siglas en inglés— es un requerimiento que
 tendrá un efecto profundo en la arquitectura, es decir, la arquitectura podría
 ser radicalmente diferente si no existiera ese requerimiento[^1].
 
-[^1]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Los requerimientos arquitectónicamente significativos a menudo —pero no siempre—

diff --git a/4_Conceptos/4_Seguridad.md b/4_Conceptos/4_Seguridad.md
@@ -33,7 +33,7 @@ la capacidad del sistema para proteger los datos y la información del acceso no
 autorizado y, al mismo tiempo, proporcionar acceso a las personas y los sistemas
 que están autorizados.
 
-[^2]: Bass, L., Clements, P., Kazman, R. (2022). Software Architecture in
+[^2]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
     Practice, 4<sup>th</sup> edition. Addison-Wesley.
 
 Un ataque, es decir, una acción que se lleva a cabo contra un sistema con la

diff --git a/5_Unidades_tematicas/5_2_7_Evaluacion_de_la_arquitectura.md b/5_Unidades_tematicas/5_2_7_Evaluacion_de_la_arquitectura.md
@@ -6,4 +6,21 @@
 
 #### Lecturas
 
-<!-- TBD. Incluir capítulo 21 de Bass-->
+<!-- TBD. Incluir capítulo 21 de Bass-->
+
+* Capítulo 21 de [^1].
+
+[^1]: Bass, L.; Clements, P.; Kazman, R. (2022). Software Architecture in
+    Practice, 4<sup>th</sup> edition. Addison-Wesley.
+
+* [Evaluación de la
+  arquitectura](/2_Tecnicas_y_herramientas/2_9__Evaluacion_arquitectura.md) como
+  introducción y los siguientes métodos de evaluación de la arquitectura:
+
+* [ATAM](/2_Tecnicas_y_herramientas/2_9_1_ATAM.md)
+
+* [Lightweight ATAM](/2_Tecnicas_y_herramientas/2_9_2_Lightweight_ATAM.md)
+
+* [ALMA](/2_Tecnicas_y_herramientas/2_9_3_ALMA.md)
+
+* [PASA](/2_Tecnicas_y_herramientas/2_9_4_PASA.md)