What Is Architecture Evaluation?

En este capítulo, presentaremos qué es la evaluación de la arquitectura y en qué consiste.

Desglosaremos el método general de evaluación de la arquitectura en cinco controles claramente
definidos: (1) comprobación de la integridad de los controladores, (2) comprobación de la idoneidad
de la solución de una arquitectura, (3) comprobación de la calidad de la documentación de la
arquitectura, (4) comprobación el cumplimiento de la implementación con la arquitectura, y (5)
verificar la calidad del código en general. Introduciremos los niveles de confianza como respuesta a
la idea de evaluación de la arquitectura impulsada por el riesgo: solo queremos invertir tanto como
sea necesario para obtener la suficiente confianza. Mostraremos cómo los resultados de la
evaluación pueden ser interpretados, agregados y representados a la alta gerencia asignándolos a
una escala de calificación codificada por colores.

3.1 ¿Cuál es el punto?

Q.014. ¿Cuál es la misión de la evaluación de la arquitectura?

La misión de la evaluación de la arquitectura es determinar la calidad del sistema de software

(previsto) y la calidad de los artefactos (auxiliares) creados durante la arquitectura o derivados de
la arquitectura. La evaluación de la arquitectura tiene como objetivo lograr la confianza en las
decisiones de diseño (arquitectónicas) tomadas sobre el sistema de software con respecto a una
pregunta de evaluación. Resume todas las actividades dirigidas a responder inquietudes críticas
relacionadas con el sistema de software, su entorno, su evolución (deudas del pasado y necesidades
anticipadas para el futuro) y sus artefactos que documentan y manifiestan las decisiones de diseño.

La evaluación de la calidad del sistema (prevista) analiza las siguientes preguntas:

• ¿Qué tan bien se comprenden y acuerdan los requisitos de los interesados (que impulsan la
arquitectura)? • ¿Qué tan bien se adaptan los conceptos de solución y las decisiones de diseño de
la arquitectura para abordar adecuadamente los requisitos? • ¿Qué tan bien se manifiestan los
conceptos de solución en la implementación?

La evaluación de la calidad del artefacto (documentación, modelos, código fuente) analiza las
siguientes preguntas:

• ¿Qué tan bien está estructurada la documentación de la arquitectura y qué tan consistente es? •
¿Qué tan bien está estructurado el código fuente del sistema de software y qué tan legible es?

Por lo tanto, la evaluación de la arquitectura requiere varias comprobaciones y rangos desde los
requisitos a través de la arquitectura hasta el nivel de implementación / sistema:

• Verifique ambigüedades, disparidades o desviaciones en las inquietudes de las partes interesadas

y los factores derivados de la arquitectura. • Verifique fallas y problemas en los conceptos de
solución e identifique decisiones de arquitectura inadecuadas. • Compruebe si existen deficiencias
e inconsistencias problemáticas en la documentación de la arquitectura del sistema. • Verifique la
deriva entre la arquitectura prevista de un sistema y la arquitectura realizada en la implementación.
• Compruebe si hay anomalías en el código fuente con respecto a las mejores prácticas, modelos de
calidad, guías de estilo y pautas de formato.
Q.015. ¿En qué consiste nuestro método de evaluación de la arquitectura?

Nuestro enfoque de la evaluación de la arquitectura aplica un conjunto de verificaciones

(verificación de la integridad del conductor, verificación de la adecuación de la solución, verificación
de la calidad de la documentación, verificación de la conformidad de la arquitectura y verificación
de la calidad del código) para brindar respuestas con un cierto nivel de confianza a las inquietudes
de las partes interesadas. La Figura 3.1 proporciona una descripción conceptual de nuestro enfoque
para la evaluación de la arquitectura, que se denomina RATE (evaluación rápida de arquitectura).
No pretende ser otro método de evaluación de la arquitectura. Más bien, es una recopilación y
recopilación de las mejores prácticas de los enfoques de evaluación existentes adaptados a la
aplicación pragmática (o rápida) en la industria. Derivamos este enfoque de

experiencias en proyectos con clientes de la industria (Knodel y Naab 2014a, b) y lecciones

aprendidas consolidadas y sugerencias concretas. Para obtener más información sobre los métodos
de evaluación de la arquitectura subyacente, nos referimos a las publicaciones (académicas)
respectivas, por ejemplo (Clements et al. 2001). La TASA comprende cinco cheques, y cada cheque
tiene un propósito distinto. Todos los controles siguen el mismo principio de trabajo: revelar
hallazgos destinados a confirmar / mejorar la calidad del sistema y / o la calidad del artefacto. Los
controles siempre se aplican para las preocupaciones concretas de los interesados.
Las partes interesadas tienen preocupaciones sobre un sistema de software. El DIC analiza la
integridad de estas inquietudes y verifica si hay acuerdo sobre las inquietudes de las partes
interesadas. Establece los objetivos para otras comprobaciones de evaluación de la arquitectura (y
determina si se deben realizar verificaciones adicionales o no). Equilibra y negocia estas
preocupaciones potencialmente conflictivas con respecto a los objetivos comerciales, las
restricciones, la calidad externa (tiempo de ejecución), la calidad interna (tiempo de desarrollo) y la
preparación para los cambios anticipados. Por lo tanto, la verificación de la integridad del conductor
consolida las diferentes preocupaciones de los interesados en los controladores de la arquitectura.
Además, se estructura y formaliza el conjunto de controladores para la arquitectura (a veces
también se denominan requisitos de arquitectura significativa) con la ayuda de plantillas y requiere
la aprobación explícita de los interesados (por ejemplo, un acuerdo y la firma del controlador) antes
de continuar con otras comprobaciones.

El SAC determina si una arquitectura permite o excluye el logro de requisitos funcionales específicos
y, en particular, requisitos de calidad [para obtener una descripción general de los atributos de
calidad comprobados con frecuencia, consulte (Bellomo et al. 2015)]. Sin embargo, no garantiza los
logros, ya que las actividades que siguen río abajo obviamente tienen un impacto. El Control de
Adecuación de la Solución permite razonar sobre las ventajas, inconvenientes y compensaciones de
un concepto de solución (o conceptos de solución alternativos) para satisfacer los requisitos o
cambiar las solicitudes disponibles. Por lo tanto, proporciona información valiosa para la toma de
decisiones al crear conciencia de los errores en el diseño. Permite la identificación de decisiones de
diseño potencialmente problemáticas, la predicción temprana basada en la abstracción y la
comparación entre alternativas, y puede ser el punto de partida para respuestas oportunas y
correcciones para mejorar la arquitectura. La Comprobación de la Adecuación de la Solución se
aplica específicamente para el producto de software bajo evaluación y tiene el inconveniente de
que es una tarea en gran parte manual que genera un esfuerzo importante y conduce a resultados
principalmente cualitativos.
El DQC asegura que la documentación de la arquitectura hace posible comprender los conceptos de
la solución. Determina si los lectores encontrarán o no la información correcta para adquirir
conocimientos, entender el contexto, realizar tareas de resolución de problemas y compartir
información sobre las decisiones de diseño tomadas. Además, la documentación (informes,
presentaciones, modelos) se inspecciona con respecto a criterios como la coherencia, la legibilidad,
la estructura, la integridad, la corrección, la extensibilidad y la trazabilidad.

El objetivo del ACC es asegurar el cumplimiento de una implementación (con la llamada arquitectura
implementada) o del sistema en ejecución con la arquitectura prevista y sus reglas sobre la
estructura del código y el comportamiento del sistema. Sólo si los conceptos arquitectónicos se
implementan de manera acorde, la arquitectura tiene valor como instrumento predictivo y
descriptivo en el proceso de desarrollo. Verificación de cumplimiento [ver Knodel et al. 2006; Knodel
y Popescu 2007, o Knodel 2011] generalmente requieren la reconstrucción de la arquitectura
(ingeniería inversa del código o instrumentación de las trazas en tiempo de ejecución) para recopilar
datos sobre el sistema, tanto del código fuente como del sistema en ejecución. Al asignar la
arquitectura real y la arquitectura deseada entre sí, se puede evaluar este cumplimiento. Esta es
una tarea que se beneficia enormemente del soporte de herramientas debido a la gran cantidad de
hechos que normalmente se extraen.

El objetivo de CQC es cuantificar numéricamente las propiedades de calidad del código fuente.
Muchos entornos de desarrollo integrado (IDE) admiten una amplia gama de métricas de calidad de
código, ya sea de forma nativa o mediante complementos o herramientas externas. Estas
herramientas incluyen ciertos umbrales o corredores que se recomienda que no se superen como
mejores prácticas. Las violaciones se reportan para los elementos de código ofensivos. La agregación
por estos entornos de métricas a nivel de código en métricas a nivel de sistema a menudo no es más
sofisticada que proporcionar estadísticas descriptivas (es decir, promedio, promedio, máximo,
mínimo, total). Los evaluadores generalmente necesitan crear sus propias agregaciones o usar
opiniones de expertos para proporcionar evaluaciones precisas o establecer modelos de calidad
para uno o más atributos de calidad. Esto se hace normalmente mediante la asignación de una
selección de métricas de bajo nivel a los atributos de calidad utilizando técnicas sofisticadas de
agregación. El control de calidad del código no es realmente una técnica de evaluación de la
arquitectura. Sin embargo, lo integramos en nuestro método general, ya que a lo largo del tiempo
descubrimos que es necesario responder a fondo las preguntas de evaluación planteadas por las
partes interesadas.

Q.016. ¿Qué determina el alcance de una evaluación de arquitectura?

Cualquier decisión que tomemos durante el diseño y la evolución de un sistema de software conlleva
el riesgo de estar equivocados o ser inadecuados para el propósito previsto. Para cada decisión de
diseño, tenemos un presentimiento acerca de nuestra confianza con respecto a qué tan bien la
decisión de diseño satisfará los objetivos de la arquitectura en su contexto. Más a menudo que no,
este sentimiento puede estar mal. Además, los requisitos cambiantes y la desviación a lo largo del
tiempo, como se discutió anteriormente, cuestionan las decisiones de diseño tomadas en el pasado.
La evaluación de la arquitectura puede aumentar la confianza en tales casos al identificar riesgos y
fallas en los requisitos de manejo, los conceptos de solución de la arquitectura o la implementación
resultante. Sin embargo, no todas las decisiones de diseño son igualmente importantes; Algunos
son más cruciales para el éxito que otros. En aquellos casos en que el nivel de confianza como tal no
es (todavía) aceptable o cuando necesitamos más pruebas para convencer a los interesados,
realizamos una evaluación de la arquitectura. Esto conducirá a una mayor confianza en las
decisiones tomadas o a hallazgos sobre fallas que requieren un nuevo diseño de la arquitectura. El
Capítulo 1 presentó muchas inquietudes y preguntas que pueden responderse con la evaluación de
la arquitectura: dependiendo de la criticidad de las preguntas, el nivel de confianza difiere dentro
de una evaluación de la arquitectura. Para algunas decisiones de diseño, es bastante fácil marcarlas,
mientras que otras requieren un análisis exhaustivo de la arquitectura del software y su
implementación subyacente o incluso el sistema en ejecución para llegar a una respuesta
concluyente. En consecuencia, la evaluación de la arquitectura se desencadena por las
preocupaciones de las partes interesadas respecto de las cuales se verifican los conceptos de la
solución arquitectónica y su implementación (si está disponible). La criticidad de la preocupación
determina la profundidad a la que se analizarán las inquietudes (es decir, el nivel de confianza).

Q.017. ¿Cuáles son los niveles básicos de confianza en la evaluación de la arquitectura?

El nivel de confianza indica la calidad del análisis para cada una de las cinco verificaciones
introducidas anteriormente. Expresa, por ejemplo, el grado en que los requisitos que impulsan la
arquitectura se han entendido claramente, el grado en que la arquitectura aborda adecuadamente
los requisitos, o el grado en que la implementación realiza la arquitectura de manera consistente.
Por lo tanto, cuanto mayor sea la confianza, menor será el riesgo de haber tomado una decisión de
diseño incorrecta. Usamos distintos niveles para expresar confianza (ver la Fig. 3.2 para una
descripción general). Cada nivel de confianza tiene ciertas características (aplicabilidad, entrada,
esfuerzo), que difieren para las cinco verificaciones introducidas anteriormente (ver capítulos 5–9,
respectivamente). Los niveles de confianza básicos para la calidad del artefacto son los siguientes:

• Creído: el nivel más bajo de confianza es la creencia pura. Esto significa que la calidad del artefacto
se acepta sin más análisis. Ningún esfuerzo dedicado es

gastado en presentar hallazgos e investigar su impacto (que abarca preocupaciones, controlador,

concepto de solución y código fuente). El trabajo del arquitecto con respecto a estas decisiones de
diseño es de confianza. Este nivel de confianza se aplica a la gran mayoría de las decisiones de
diseño. En la mayoría de los casos, será justo porque las inquietudes eran bien conocidas, los
conceptos de solución se adaptaron a los controladores de arquitectura y la implementación cumple
con el diseño previsto. Aprovechar los conocimientos, habilidades, competencias y experiencias del
arquitecto produce decisiones de diseño adecuadas. • Inspeccionado: la calidad del artefacto se
inspecciona en cada una de las verificaciones para revelar hallazgos (positivos y / o negativos). Las
inspecciones generalmente siguen un proceso estructurado y bien definido con roles y actividades
definidas para examinar el grado en que la manifestación satisface el objetivo. Los inspectores
pueden ser los arquitectos que realmente son responsables del diseño, los pares internos que no
participan directamente en el diseño arquitectónico (por ejemplo, tableros de arquitectura, otros
arquitectos, grupos de garantía de calidad o grupos de métodos dentro de la misma organización)
o un tercero externo independiente. fiesta (consultores, organismos de investigación, etc.). •
Medido: Las mediciones proporcionan números cuantitativos y datos al calcular ciertas
características de los artefactos del sistema de software bajo evaluación. Las mediciones aplican
fórmulas definidas formalmente para realizar los cálculos (por ejemplo, métricas, guías de estilo,
pautas de formato, etc.).

Los niveles básicos de con fi anza para la calidad del sistema son los siguientes:

• Creído: el nivel más bajo de confianza es nuevamente una creencia pura, lo que significa que se
supone que el sistema de software resultante será adecuado; No se realiza ningún análisis adicional.

• Predicción: Predicción significa usar el conocimiento existente, la información actual y los datos
históricos para razonar sobre el futuro. La confianza se logra utilizando los recursos disponibles para
predecir las propiedades del sistema de software. Cuanto mejor se apliquen los datos y el modelo
subyacente para la predicción, mayor será el nivel de confianza alcanzado. Las predicciones
comprenden estimaciones realizadas por expertos en temas (adivinanzas basadas en experiencias y
experiencia individuales), simulaciones basadas en la ejecución de un modelo descrito formalmente
(a menudo dejando espacio para cierta incertidumbre en los parámetros o en el conjunto de datos
del modelo), o heurísticas basado en datos y reglas basadas en hechos (conjuntos de) donde se
proporciona evidencia de otros sistemas de software que son relevantes para algún tipo de (Debido
a su naturaleza general, es probable que las heurísticas también sean válidas para los sistemas de
software bajo evaluación).

• Probado: una sonda indica una acción exploratoria para probar técnicamente y crear una solución
(o un concepto de solución potencial en evaluación). Una investigación detallada y exhaustiva sirve
para estudiar los factores de contexto, examinar los supuestos sobre el entorno, los conceptos y las
tecnologías, y explorar los factores de escala. En definitiva, sirve para mitigar los riesgos. Las sondas
pueden utilizar maquetas para explorar una idea o un concepto con poco esfuerzo de manera
simplificada o simplificada, representantes del sistema de software real (por ejemplo, versiones
anteriores o variantes, o partes similares de otros sistemas que comparten el diseño o la misma
tecnología). pila), o prototipos para aprender por ejemplo, proporcionando la implementación de
una parte o aspecto crucial del concepto de solución. Las sondas proporcionan una alta confianza,
ya que el concepto de solución realizado se puede explorar en detalle, con la tecnología objetivo y
se puede probar su adecuación.

• tested: las pruebas ejecutan el sistema de software para evaluar ciertos aspectos de interés. Se
verifica si una funcionalidad dada funciona correctamente con una calidad aceptable. Además, se
pueden tomar medidas sobre el sistema de software en ejecución. El acto sistemático y reproducible
de las pruebas se puede realizar en un entorno de laboratorio o en el campo (entorno de
producción). Los entornos de laboratorio proporcionan un campo de juego para probar con datos
(artificiales) y una infraestructura (similar o idéntica) como en el campo. Las pruebas en el campo
proporcionan la máxima confianza al analizar la calidad del sistema de software en el entorno de
producción.

Q.018. ¿Cuál es el resultado de una evaluación de arquitectura?

La aplicación de cada uno de los cinco controles (ver arriba) producirá un conjunto de hallazgos en
el objeto bajo evaluación con respecto a la pregunta de evaluación. Los hallazgos representan
resultados positivos y negativos revelados por la verificación realizada. Pueden incluir riesgos
identificados, suposiciones, factores de escala, limitaciones, concesiones, violaciones, etc. Todos los
hallazgos se pueden identificar en una parte concreta del objeto que se está evaluando. Los
resultados de cada verificación siempre deben interpretarse a la luz de las preguntas generales que
activan la evaluación de la arquitectura, y en el contexto y el entorno del sistema de software bajo
evaluación. Esta interpretación generalmente no es fácil y directa y, por lo tanto, requiere
experiencia en arquitectura. En consecuencia, el resultado de cada verificación es una lista de
hallazgos.

Q.019. ¿Cómo interpretar los hallazgos de una evaluación de arquitectura?

La interpretación de los hallazgos es crucial para beneficiarse de los resultados generales de la

evaluación de la arquitectura. La evaluación de la arquitectura revela positiva y resultados negativos
sobre la calidad del sistema y la calidad del artefacto. La interpretación de los hallazgos depende del
contexto, según la pregunta de evaluación subyacente, el sistema de software bajo evaluación y la
naturaleza del hallazgo. En particular, en caso de resultados negativos, es el punto de partida para
derivar acciones de mejora. La naturaleza de los hallazgos (ver Fig. 3.3) se caracteriza por dos
dimensiones: la causa del hallazgo y la línea de base en la que se basa el hallazgo. Las causas pueden
basarse en las propiedades del producto, como las fallas o debilidades inherentes del sistema de
software o la tecnología y su uso indebido, o en las capacidades y limitaciones humanas en términos
de afrontar la complejidad (es decir, la comprensibilidad) y tratar el cambio continuo en el evolución
del sistema de software (que es la característica inevitable de cualquier sistema exitoso). La línea de
base describe los criterios que son la base para establecer el hallazgo. Estos pueden abarcar desde
criterios universales (aplicables en la misma forma a cualquier otro sistema de software, por
ejemplo, estándares o métricas ISO) hasta criterios individuales (ajustados específicamente al
sistema de software bajo evaluación, por ejemplo, que cumplen con los requisitos de rendimiento
específicos del producto). Entre ellos puede haber criterios específicos de dominio o criterios
específicos de organización, que tienen una aplicabilidad limitada en comparación con los criterios
universales. Las evaluaciones de arquitectura pueden revelar una serie de hallazgos cuya naturaleza
difiere (consulte la pregunta Q.096 para ver un ejemplo de la naturaleza de los hallazgos para
mantenimiento). Es posible que algunas preguntas de evaluación deban evaluarse individualmente
para el sistema de software bajo evaluación, mientras que otras pueden usar reglas de propósito
general (por lo tanto, estas reglas tienen una aplicabilidad más amplia y pueden verificarse en
muchos sistemas de software). Por lo general, los hallazgos causados por las tecnologías en uso y
las limitaciones de las capacidades humanas son más generales. Sirven para detectar riesgos con
respecto a las mejores prácticas, pautas, usos indebidos o dificultades conocidas en las tecnologías.
En la práctica, es mucho más fácil apuntar a estas causas porque se pueden comprar herramientas
que vienen, por ejemplo, con reglas predefinidas o umbrales y corredores estándar para las
métricas. Son fáciles de aplicar y hacen que las personas estén seguras de que están haciendo lo
correcto para mitigar

riesgos El inconveniente es que estos medios de propósito general a menudo no se ajustan a las
preguntas de evaluación que impulsan la evaluación de la arquitectura, pero esto no se descubre.
Las técnicas específicas de la organización tienen en cuenta las pautas específicas del dominio, la
organización de desarrollo, el proceso de desarrollo específico o la cultura de la empresa. Sin
embargo, no tienen en cuenta las propiedades del producto concreto. En casos simples, las técnicas
específicas de la organización se podrían adaptar a partir de instrumentos para detectar causas
universales basadas en las experiencias realizadas en la empresa. Ser específico del producto implica
preocuparse por todos los aspectos que hacen que el sistema de software sea único y, por lo tanto,
deben aplicarse al producto. Lo que es de sentido común para las pruebas (nadie solo ejecutaría
casos de prueba relacionados con la tecnología sin probar la lógica específica del producto del
sistema de software) no es el caso de las evaluaciones de arquitectura y las verificaciones de calidad
del código fuente. Aquí, muchas organizaciones de desarrollo, proveedores de herramientas e
incluso algunos investigadores afirman ser específicos del producto con una técnica de propósito
general realizada en una herramienta de control de calidad que se puede descargar de Internet. Sin
embargo, estas técnicas de propósito general pueden simplemente conducir a la confianza con
respecto a evitar riesgos con respecto a la tecnología o las limitaciones de las capacidades humanas.
Si se realiza correctamente, la evaluación de la arquitectura de hecho combina aspectos específicos
del producto y de propósito general y, por lo tanto, permite el razonamiento sobre la pregunta de
evaluación en cuestión. Esto es lo que hace que la evaluación de la arquitectura sea un instrumento
extremadamente valioso para mitigar los riesgos en el ciclo de vida de un sistema de software.

Q.020. ¿Cómo agregar los hallazgos de una evaluación de arquitectura?

Si bien los hallazgos se detallan por su naturaleza, también es importante proporcionar una visión
general y permitir la comparabilidad de los controles a lo largo del tiempo y de varios candidatos
que se someten a los mismos controles. Recomendamos calificar cada resultado de verificación en
dos escalas simples de cuatro puntos. Se considera que todos los hallazgos en resumen
proporcionan la calificación agregada. Cuanto mayor sea la puntuación, mejor será la calificación
del objeto de manifestación y menos críticos serán los riesgos.

• La gravedad de los hallazgos expresa la importancia de los hallazgos agregados sobre todos los
hallazgos por meta. La importancia oscila entre (1) crítica, (2) dañina, (3) menor y (4) inofensiva /
ventajosa.

• Balance de hallazgos expresa la proporción de resultados positivos frente a negativos agregados

por meta. Tiene un rango de (1) hallazgos solo o principalmente negativos, (2) predominan los
hallazgos negativos (3) predominan los hallazgos positivos, y (4) los hallazgos únicos o
principalmente positivos.

La combinación de ambas escalas (es decir, el producto matemático de los dos factores, ver Fig. 3.4)
determina la puntuación general para la expresión basada en la verificación del logro objetivo del
objeto de manifestación
N / A No se aplica (GRIS): Esto significa que el logro de la meta aún no se ha verificado. Es posible
que la verificación se haya aplazado o descartado debido a la información faltante, a las limitaciones
de esfuerzo y tiempo, o a partes interesadas no disponibles.

• NO logro de objetivos (RED): Esto significa que hay problemas, fallas o fuertes argumentos en
contra del logro de la meta. Arreglar estas debilidades principales causará un gran esfuerzo para
reparar o requerirá un replanteamiento fundamental.

• Logro objetivo parcial (NARANJA): Esto significa que se han identificado fallas o riesgos
significativos, pero esperamos que se puedan eliminar con un esfuerzo modesto.

• GRAN logro de objetivos (AMARILLO): Esto significa que no hay objeciones importantes al logro
de objetivos. Sin embargo, algunos detalles pueden requerir un mayor refinamiento o elaboración.
• Logro de objetivo completo (VERDE): Esto significa que hay un logro de objetivo completo. No se
han revelado hallazgos o solo hallazgos inofensivos o ventajosos.

Si bien una escala tan simple, inspirada en el tránsito de luz es importante para resumir los
resultados de la evaluación y para presentar los resultados de la evaluación a la gerencia y otras
partes interesadas, siempre existe la necesidad de mantener los resultados más detallados a la
mano. La calificación debe basarse y justificarse en una explicación detallada y diferenciada de los
hallazgos. Esto es necesario para justificar la calificación en situaciones críticas y para hacer que la
lógica de la calificación sea persistente. Además, sirve para derivar elementos de acción para iniciar
acciones de mejora.
Q.021. ¿Cuáles son las limitaciones de la evaluación de la arquitectura?

A pesar de ser un instrumento poderoso, la evaluación de la arquitectura también tiene limitaciones.

• La arquitectura solo puede evaluarse indirectamente: la arquitectura que es realmente

interesante es la que se implementa. Sin embargo, esto no es realmente tangible y, por lo tanto, se
utilizan abstracciones y sus documentaciones. Sin embargo, siempre existe el riesgo de información
inadecuada.

• La arquitectura es una abstracción: esa arquitectura es una abstracción que tiene ventajas y
desventajas al mismo tiempo. Tiene ventajas en el sentido de que la complejidad solo puede
manejarse a través de abstracciones. Tiene desventajas en el sentido de que cada vez que dejamos
algo, esto todavía tiene un impacto en el sistema fi nal, que simplemente no puede ser evaluado.

• La evaluación absoluta de la arquitectura generalmente no es posible: el resultado de una

evaluación de la arquitectura no es, en su mayoría, una medida cuantificada o el grado de logro de
la meta. Más bien, es un conjunto de hallazgos que requieren interpretación.

• La evaluación de la arquitectura requiere cooperación: es muy difícil e ineficaz evaluar una

arquitectura sin arquitectos colaboradores, ya que toda la información se debe recopilar y
reconstruir a partir de la documentación y el código.

• La evaluación de la arquitectura no puede garantizar la calidad: los detalles de la

implementación, por ejemplo, Los algoritmos especí fi cos también tienen un fuerte impacto en el
logro de atributos de calidad.

Q.022. ¿Qué es una buena metáfora para la evaluación de la arquitectura?

Considere un sistema de guía de ruta como una metáfora para una evaluación de arquitectura.
Imagine que después de conducir en la carretera durante tres horas consecutivas (un proyecto en
ejecución), está casi a mitad de camino para llegar a su destino (la versión). El sistema de guía de
ruta (la evaluación de la arquitectura) puede indicarle si llegará al destino a tiempo (dentro del
presupuesto) o no. Le proporciona un plan sobre qué caminos seguir (información estática) y conoce
los trabajos de construcción y los atascos de tráfico (información dinámica). Pero al final, el sistema
de guía de ruta solo puede dar recomendaciones y hacer que el conductor esté al tanto de los riesgos
(advertencias). El resultado final sobre si llegará o no a la hora programada depende
significativamente de sus decisiones como conductor (tomar un descanso, ignorar las
recomendaciones) y de su automóvil (la tecnología subyacente)

3.2 ¿Qué errores se cometen con frecuencia en la práctica?

No hacer ninguna evaluación de la arquitectura en absoluto.

Aunque la evaluación de la arquitectura se ha abierto camino en la industria (Babar y Gorton 2009;

Knodel y Naab 2014a, b; Bellomo et al. 2015), aún se están tomando muchas decisiones cruciales
con respecto al software sin obtener los datos arquitectónicos relevantes de una evaluación de
arquitectura. . Y todavía hay muchos ingenieros y gerentes de software que no han oído hablar de
la evaluación de la arquitectura como un medio para identificar y mitigar los riesgos. ! Preguntas
Q.003, Q.004, Q.014.
Reduciendo los resultados de la evaluación a las luces de tráfico solamente.

Es necesario proporcionar agregaciones de los resultados de la evaluación, en particular para la

comunicación y la presentación. Sin embargo, estas agregaciones solo ofrecen una vista limitada y
siempre hay resultados complejos y detallados detrás de los resultados agregados que deben
considerarse. La esencia de la evaluación de la arquitectura es proporcionar una guía para la toma
de decisiones y para el próximo trabajo. Por lo tanto, la correcta interpretación de los hallazgos es
importante pero también desafiante. ! Pregunta Q.018, Q.019, Q.020.

Centrándose únicamente en métricas de arquitectura o métricas de código.

La evaluación de la arquitectura con un fuerte enfoque en el cumplimiento de los requisitos es un

esfuerzo intensivo. Evaluar solo las métricas con una herramienta es bastante fácil. Por lo tanto, los
profesionales a menudo tienden a medir las propiedades generales de una arquitectura (como las
métricas de acoplamiento), que son un indicador aproximado de las propiedades de calidad internas
como la capacidad de mantenimiento, pero no logran evaluar la idoneidad de la mayoría de los
controladores de arquitectura. ! Preguntas Q.015, Q.017, Q.096, Q.097.

Evaluando únicamente la calidad de la documentación.

La arquitectura es más que un montón de diagramas y documentos. A veces, la evaluación de la

arquitectura se reduce a la revisión de los documentos de arquitectura con un enfoque en las
propiedades del documento, como la legibilidad, la coherencia o la trazabilidad.

Si bien es importante contar con documentación de alta calidad, no es suficiente verificar la calidad
de la documentación de forma aislada. ! Pregunta Q.015.

Evaluar si la arquitectura es "de vanguardia".

El uso de tecnologías de vanguardia parece ser un objetivo prometedor para muchos profesionales.
Por lo tanto, el objetivo de una evaluación de la arquitectura es, a veces, verificar si la arquitectura
es "de vanguardia". En tales casos, generalmente falta una evaluación de los controladores de
arquitectura. ! Pregunta Q.014, Q.046.