Table of Contents
Si recuerdas mi artículo sobre Atributos de Calidad de la Arquitectura de Software, sabes que hemos estado realizando una encuesta para averiguar las métricas clave de la arquitectura de software que utilizan las empresas líderes y los arquitectos de software. Como la calidad de la arquitectura de un software es esencial, es todavía muy difícil de aprender y medir. Y las características de calidad de una arquitectura no son obvias ya que las relaciones y dependencias pueden extenderse mucho. Así que, ¡hoy es el día! Hoy me gustaría compartir con vosotros los resultados, pero por favor, tengan en cuenta que esta es una experiencia positiva de empresas específicas, pero no significa que estas métricas sean transferibles a todos los entornos. Algunas pueden ser útiles para su proyecto, otras tal vez no. Pero aquí van los resultados gracias a las siguientes empresas que ponen un especial énfasis en la arquitectura de software: Apiumhub, Endava, Codurance, Thoughtworks, Mittelabs, DoItinternational, Developertoarchitect, wps, Xebia, Hello2morrow, Rollbar, Roche, ABB, Hoxell, Vidactive, CodingSans.
Como todos sabemos, en el desarrollo de software, la detección temprana de problemas de arquitectura de software es clave. Ayuda a mitigar el riesgo de un mal rendimiento, y reduce el coste de reparación de éstos problemas. Así que, analicemos las métricas de la arquitectura de software que se mencionaron en la encuesta para construir proyectos escalables.
Resultados: Métricas clave de la arquitectura de software
- Métricas de la arquitectura de software por Andrew Hamel Law – Director Técnico @ThoughtWorks
Las cuatro métricas clave de Nicole Forsgren, descritas en el libro Accelerate, y denominadas «Adopt» en el Thoughtworks Radar, diferencian entre organizaciones de tecnología de bajo, medio y alto rendimiento: plazo de entrega, frecuencia de despliegue, tiempo medio de restablecimiento (MTTR) y porcentaje de fallo de cambio. De hecho, hemos descubierto que estas cuatro métricas clave son una herramienta sencilla y a la vez poderosa para ayudar tanto a los líderes como a los equipos a centrarse en la medición y la mejora de lo que importa. Un buen lugar para empezar es instrumentar los oleoductos y gasoductos ya construidos para poder capturar las cuatro métricas clave y hacer visible el flujo de valor de la entrega de software. Los oleoductos del GoCD, por ejemplo, proporcionan la capacidad de medir estas cuatro métricas clave como un ciudadano de primera clase del análisis del GoCD.
Hay otros, factores cualitativos (es decir, el número de diagramas que se ven en los dibujos del desarrollo, el número de ADR, la participación en actividades arquitectónicas, el compromiso con los procesos de gobierno de datos, etc.), así como la retroalimentación de las diversas funciones de aptitud que se pueden ejecutar, pero las cuatro métricas clave, respaldadas por una investigación increíblemente sólida y el trabajo estadístico son el lugar para empezar.
- Alvaro Garcia – Ingeniero Principal @Apiumhub
Fitness Functions para validar que la configuración es correcta ( por ejemplo la base de datos en el momento de la compilación )
- Hadil Abukwaik – Arquitecto de Software @ABB
Lógica fan-in, fan-out, dependencia circular, # componentes, tamaño de los componentes, función de aptitud, tiempo de respuesta, complejidad ciclomática, métricas técnicas específicas de la deuda.
- Sandro Mancuso – Director General @Codurance
Las 4 métricas clave descritas en Acelerar: Frecuencia de despliegue, tiempo de espera para los cambios, MTTR, tasa de fallo de los cambios.
También utilizamos algunas métricas específicas del proyecto relacionadas con el rendimiento.
Acoplamiento y Cohesión a través de los módulos.
- Eoin Woods – CTO @Endava
La gente usa algunas métricas de estructura de código y tenemos herramientas bastante sofisticadas para derivar patrones y anti-patrones, pero estos son sólo sobre estructura de código, no realmente la arquitectura.
Algunos arquitectos también usan medidas estructurales en las estructuras arquitectónicas (por ejemplo, la complejidad de las dependencias de los módulos funcionales).
La mayoría de los arquitectos pasan más tiempo mirando «métricas» relacionadas con las cualidades (transacciones por segundo, tiempo medio de recuperación, esfuerzo para añadir una característica de un determinado tipo). Sin embargo, estas no son mediciones de la arquitectura en sí, sino del efecto de la arquitectura».
Creo que esta es realmente un área de investigación activa (o podría serlo). Algunos académicos lo están estudiando.
Sería bueno obtener formas fiables para medir o estimar el acoplamiento, la cohesión, la propagación del cambio, las interacciones entre módulos, el cumplimiento de los patrones o estilos y así sucesivamente.
El problema práctico es cómo medir estas cosas. Eso implica un modelo de arquitectura completo y preciso. Que normalmente no existe (en parte porque es demasiado caro de justificar en base a sus beneficios). Así que te quedas con la medición del código, lo cual ya hacemos. Pero eso significa que no puedes medir hasta está construido y algunas de las cosas que sugiero no se encuentran en el código. Así que creo que este es un problema muy difícil (y muy interesante).
- Alexander von Zitzewitz – CEO @Hello2morrow
- Promedio de dependencia de los componentes
- Ciclicidad relativa
- Tamaño del grupo de ciclo más grande
- Índice de deuda estructural
- Nivel de mantenimiento
- Complejidad Ciclomática
- Profundidad máxima de anidación
Creo que las métricas de las dependencias cíclicas y el acoplamiento son muy buenos indicadores de la erosión arquitectónica. Dado que esta es la forma más tóxica de deuda técnica, el uso de estas mediciones tendrá un muy buen retorno de la inversión (ROI).
- Mark Richards – Consultor Independiente @developertoarchitect y arquitecto de software
Actualmente mido el rendimiento y la escalabilidad mediante el uso de funciones automatizadas de acondicionamiento físico continuo que funcionan en la producción. Cuando se identifica una tendencia negativa a través de la función de aptitud física, me lo notificó por correo electrónico.
También hago un seguimiento del acoplamiento de los componentes (entrante, saliente y total), el tamaño del componente (número de declaraciones en todas las clases del componente) y el porcentaje de código que el componente representa en toda la base de código. Un componente aquí es un espacio de nombres o un paquete Java.
Los que impactan la modularidad y la cohesión del sistema. La complejidad del componente (complejidad ciclomática) es una buena métrica que apunta a la sostenibilidad general del código. Recomiendo seguir las siguientes métricas desde un punto de vista estructural:
– Tamaño del componente (número de declaraciones)
– Acoplamiento de componentes
– Cohesión de los componentes
– Complejidad de los componentes (WMC o complejidad media)
- Dr. Carola Lilienthal – Directora General @WPS
MMI (Índice de Madurez de la Modularidad) – este índice comprende muchas otras métricas y da una buena indicación de si un sistema es modular o no.
- Cobertura de pruebas
- Métricas de tamaño en todos los niveles
- Métricas de dependencia en todos los niveles
- Vlad Khononov – Arquitecto Senior Cloud @DoiT International
- Complejidad ciclomática
- Coherencia
De DORA:
- Tiempo de espera para los cambios
- Frecuencia de despliegue
- Es hora de restaurar el servicio
- Cambiar la tasa de fallos
Además, uso el tiempo medio para detectar.
Bajo el capó, podemos usar métricas más técnicas, como la complejidad ciclomática, el número de CVS, la seguridad, etc.
Pero lo más importante es vincular las 5 primeras métricas con los KPI del negocio del software. Esa es la razón más importante. Cualquier cosa que tenga sentido desde una perspectiva de negocios. Por ejemplo, si estás en una industria altamente regulada, como la de los pagos, necesitas ver las transacciones como un todo. Puede implicar una tasa de latencia o de fallos.
Por otro lado, si estás en un negocio de pronóstico, la precisión de los datos es importante. Por lo tanto, las métricas que pueden ser aproximadas al estado de los negocios.
Por último, pero no menos importante, las métricas del equipo. Sin gente, no tenemos una arquitectura de sistemas completa. La felicidad, la autonomía, el trabajo en equipo son las cosas que más me interesan para tener un ambiente de trabajo saludable.
- Alberto Capellini – Cofundador & CTO @Hoxell
Probando la cobertura es la métrica que encuentro más útil, ya que puede ser comprobada, mejorada y puede añadir valor al producto final.
Prefiero añadir métricas de procesos ágiles, como el tiempo de ciclo y la velocidad del equipo.
- Alberto Villar – Director @Vidactive
- Tiempo de espera, para entender cuánto tiempo toma desde una idea hasta un producto
- Tiempo de ciclo relacionado con el MTTR, la tasa de accidentes y las nuevas características
- La velocidad del equipo
- Tasa de caída de la aplicación
- Incidentes de seguridad
- Edwin Maldonado – Arquitecto de Soluciones @Mittelabs
Resistencia, mantenimiento, escalabilidad, comprobabilidad, asequibilidad (mide con números no sólo los costes de la tecnología sino también las personas que necesitas para mantenerla en funcionamiento).
- Christian Ciceri – Arquitecto de Software @Apiumhub
Como una visión general: todas las -ilidades, tratando de cuantificarlas, y cuando no puedo, cualitativamente (pero usando el razonamiento matemático). También es importante cuantificar los errores y defectos, ya que la calidad externa es un buen indicador de la calidad interna del proceso, las automatizaciones y las metodologías, e indirectamente de la modificabilidad, que es (IMHO) quizás el atributo más importante. También, la frecuencia de los despliegues (exitosos).
- Théo Coulin, Maxence Detante, William Mouchère, Fabio Petrillo – Département de génie informatique et génie logiciel Polytechnique Montréal
La métrica más utilizada es el acoplamiento, y su complementaria, la cohesión. Es importante tener una alta cohesión en los módulos, y un bajo acoplamiento en toda la arquitectura. El bajo acoplamiento es muy importante porque disminuye el riesgo de efecto dominó al hacer cambios en el programa. Por lo tanto, el bajo acoplamiento es muy importante para mantener la arquitectura sostenible. La mantenibilidad es la cualidad más importante que muestra un bajo acoplamiento.
Otro enfoque muy interesante es, en lugar de medir el acoplamiento, medir el desacoplamiento, es decir, la modularidad de la arquitectura. Una buena modularidad significa fácil mantenimiento y reutilización.
Otra métrica muy importante es la complejidad. Afecta a la comprensibilidad de la arquitectura y posiblemente al rendimiento. Puede expresarse por el número de clases en la arquitectura, o el número de enlaces entre clases en la arquitectura.
La Propagación del Cambio evalúa la mantenibilidad de una arquitectura basada en la probabilidad de que un cambio en una clase tenga un impacto en otras clases.
Otra es la matriz de probabilidades de propagación del cambio entre componentes, para que el arquitecto pueda, de un vistazo, evaluar la dificultad y analizar el costo de las operaciones de mantenimiento.
La densidad del patrón de diseño mide el porcentaje de clases en la arquitectura que forman parte de un patrón de diseño. Ayuda al diseñador a evaluar la madurez de una arquitectura. Cuanto más madura es una arquitectura, más patrones de diseño se ponen en ella, y más alta es la densidad del patrón de diseño. Es muy bueno cuando se aplica en marcos, que deben ser muy densos en patrones de diseño. Un marco con alta densidad de patrones es más comprensible y probablemente más eficaz. Esta métrica parece ser bastante difícil de usar ya que no expresa en una escala fija la madurez del diseño, sino más bien en una escala que depende del problema con el que el software trata.
Las métricas como la utilización y el trabajo de rendimiento evalúan el rendimiento de una solución basada en componentes y alojada en un contenedor. Requiere la modelización previa de varias partes críticas del futuro sistema, como la herramienta que recibe todas las solicitudes y las redirige al servicio correspondiente, o la actividad de la base de datos. Por lo tanto, requiere esfuerzos adicionales, pero parece proporcionar un perfil preciso del rendimiento de la plataforma mediante la predicción del tiempo de respuesta.
Para la modularización se utilizan métricas para medir el acoplamiento entre los módulos, métricas para contar el número de llamadas entre módulos que no se realizan a través de la API definida, métricas para detectar la herencia entre clases de diferentes módulos, métricas para evaluar que el nivel de abstracción más alto es el que utilizan las clases que no pertenecen al módulo, métricas para evaluar que las interfaces tienen realmente una única responsabilidad.
Hay tres métricas para evaluar diferentes aspectos de los diagramas UML. La primera métrica propuesta es el Contenido de Información (CI). Se basa en la jerarquía y el peso de los diferentes elementos de los diagramas UML. Define la cantidad de información que pasa un diagrama o la arquitectura. Cuanto mayor sea el IC, mayor será la cantidad de información entregada. El segundo es más interesante ya que es original, y ayuda a evaluar la calidad de la arquitectura en términos de capacidad de comprensión. Se llama Efecto Visual. Cuanto más alto es el efecto visual, más complejo es para un ser humano comprender el diagrama de un vistazo. La tercera métrica está cerca de ser una métrica de acoplamiento: el grado de conectividad mide el número de asociaciones w.r.t. el número de entidades en el diagrama. Los diferentes tipos de asociaciones tienen diferentes pesos.
Otra cosa interesante que hay que mencionar es la técnica de Garantía de Calidad del Software arquitectónico (aSQA) para proporcionar una técnica ligera, cuyo objetivo es evaluar la calidad de la arquitectura del software así como priorizar las cosas en las que trabajar. También permite equilibrar los atributos de calidad de la arquitectura. Además, esta técnica necesita tener una arquitectura basada en componentes o en servicios para ser fácil de usar. El siguiente paso es definir un mapeo de las mediciones de calidad a niveles aSQA. Dado que la técnica aSQA pone énfasis en el equilibrio y la priorización entre las cualidades, es necesario utilizar la misma escala para todas las métricas.
Además, hay cuatro métricas específicas de SO para satisfacer las necesidades específicas de un diseño. Cada métrica evalúa respectivamente: Granularidad del servicio, Acoplamiento del servicio, Cohesión del servicio y Convergencia de la entidad comercial. El modelo propuesto se lleva a cabo en tres pasos: 1) Modelado, identificar los servicios en el proceso de negocio y modelar la estructura de la cartera identificada; 2) Medición, utilizar el modelo para medir las características de calidad de los servicios en la cartera con la ayuda de las correspondientes métricas de diseño; 3) Evaluación: evaluación general de los servicios establecidos mediante la normalización de las métricas y la adición de algunos pesos, que cualquier diseñador puede personalizar para adaptar el modelo a sus necesidades.
- Dave Farley – Director @Continuous Delivery
- Estabilidad: cuán estable es nuestro código. Mide la calidad de la producción y detecta la tasa y el tiempo de recuperación.
- Rendimiento: mide la eficiencia de nuestro enfoque y rastrea el tiempo de entrega y la frecuencia de despliegue
- Métricas clave de la arquitectura de software por otros expertos anónimos en arquitectura de software
- Lean Time
- La vida media de las aplicaciones y servicios de software entre los despliegues, es decir, la frecuencia con la que se producen los cambios.
- Cobertura de código
- Tiempo de respuesta
- Rendimiento
- Mtbf
- Up-time
- Requisitos de documentación de arquitectura
- Aferencia/eferencia
- Número de prueba de la unidad en el código existente y en el nuevo código
- Cobertura de pruebas en el código existente y en el nuevo código
- Número de módulo / paquete / tipo de clientes afectados por un error o un cambio de requisitos
- Medir la calidad de las interfaces
- DDD + Microservicios
- Acoplamiento, Complejidad
- Cobertura, métodos ponderados
- Mantenibilidad, extensibilidad, reutilización, complejidad, densidad de patrones de diseño, modularización
- Evaluación de los diagramas UML, rendimiento, simplicidad
- Número de nuevos bugs por sprint
- Número de bugs arreglados por sprint
- Funciones Fitness
- Cobertura de código, sesiones libres de accidentes…
- Uso de la CPU, latencia, uso de la batería, consumo de datos, uso de la memoria
- El dominio del proyecto, el volumen de usuarios, la complejidad de la lógica de negocio, la capacidad de extensibilidad o escalabilidad, entre otros
- El cliente utiliza los flujos de casos, podría decirnos si podemos dividir los servicios o no
- Cohesión
- Número de componentes
- Código muerto
- Código no probado
- Nivel de automatización
- Extensibilidad
- El costo de agregar nuevas características
- Cobertura de pruebas de integración
- JSP+bootstrap+jQuery
- Sin servidor
También se han mencionado varias herramientas útiles:
- Google lighthouse
- Datadog
- Rollbar
- Prometheus
Tener tales métricas clave de la arquitectura de software y herramientas puede hacer que la revisión de la arquitectura sea mucho más rápida y menos costosa. Esto puede hacer posible que los arquitectos de software ejecuten comprobaciones desde el inicio del proyecto y durante toda la vida del proyecto de software. Además, la arquitectura de software puede ser evaluada en cada sprint para asegurarse de que no se está desviando para convertirse en algo imposible de mantener. También puede permitir la comparación entre las arquitecturas para elegir la que mejor se adapte a los requisitos del proyecto.
Espero que este artículo te haya sido útil! Si deseas añadir algo, por favor, siéntete libre de compartirlo en la sección de comentarios a continuación o contactándonos directamente: [email protected]
