Charla GSAS: Enfoque pragmático de las métricas de arquitectura – Parte 1

Compartir esta publicación

En su presentación titulada «Pragmatic Approach to Architecture Metrics» (Enfoque pragmático de las métricas de arquitectura) en el GSAS’22 organizado por Apiumhub, Sonya Natanzon y Vlad Khononov aportaron valiosas ideas. Ofrecieron al público amplio material para la reflexión, haciendo hincapié en la importancia de considerar las métricas de arquitectura pertinentes y adoptar un enfoque pragmático que arroje luz sobre la comprensión de los objetivos de las métricas y la necesidad de tomar decisiones informadas sobre qué medir.

Enfoque pragmático de las métricas de arquitectura

La importancia de las métricas de arquitectura

Con las métricas, empezamos a pensar en términos de …

Lo que se mide, se gestiona -Peter Drucker

Pero quizá sea más apropiado reformularlo como…

Lo que se mide, se gestiona, incluso cuando es inútil medirlo y gestionarlo, e incluso si ello perjudica el propósito de la organización.

-Simon Caulkin sobre el artículo de V.F. Ridgeway «Dysfunctional Consequences of Performance Measurements», 1956

No todo lo que podemos medir tiene necesariamente una importancia significativa y, a la inversa, hay elementos cruciales que desafían una medición fácil. La clave está en encontrar un equilibrio entre los indicadores medibles y una comprensión global de la finalidad y los objetivos generales de la organización.

¿Qué queremos medir?

Queremos saber si la arquitectura de software tiene éxito

Todo el mundo quiere métricas cuantitativas que demuestren el éxito

La arquitectura de software es nebulosa y difícil de medir

Ralph Johnson afirma acertadamente: «La arquitectura trata de lo importante. Sea lo que sea».

El propósito de la arquitectura radica en su alineación con los objetivos empresariales, haciendo hincapié en que lo verdaderamente importante para la arquitectura es lo que apoya eficazmente esos objetivos

  Reflexiones sobre Software Crafters - 2ª parte

Determinar qué cualidades arquitectónicas son importantes para respaldar los objetivos empresariales.

A ver si puede medirlas. Éstas son sus métricas de arquitectura

Evolución (exitosa) del producto

El viaje de la arquitectura de software implica el inicio, la evolución, la adopción del mercado, la expansión y la ampliación. Es crucial reconocer que la Evolución y la Escala representan dimensiones distintas del cambio.

El éxito de la arquitectura de software depende de su capacidad de adaptación para satisfacer las necesidades cambiantes de la empresa. Por consiguiente, evaluamos la capacidad de la arquitectura para aceptar el cambio a través de diversas métricas. Es importante reconocer que las estrategias que nos han llevado a nuestro estado actual pueden no ser suficientes para el crecimiento futuro. Las métricas deben alinearse con la progresión de la empresa en lugar de estar sujetas a consideraciones arquitectónicas, lo que hace necesaria su evolución continua.

Pero ten mucho cuidado con las métricas, porque…

Cuando una medida se convierte en un objetivo, deja de ser una buena medida. – Ley de Goodhart

Por ejemplo:

1. Cobertura del código

2. Errores encontrados

3. Frecuencia de despliegue

4. Índice de colisiones

Algunas buenas métricas a tener en cuenta:

Cambiar Frecuencia

¿Con qué frecuencia podemos hacer cambios significativos?

Eficacia del cambio

¿El cambio ha aportado valor a los usuarios?

Cambio Coste

¿Qué hace falta para cambiar?

Del libro Accelerate

Complejidad

A medida que aumenta la complejidad, también lo hace el coste asociado al cambio. El coste del cambio está intrínsecamente ligado a la complejidad de las modificaciones necesarias. Por consiguiente, nuestro objetivo es comprender y evaluar la complejidad de la arquitectura. La complejidad, como bien dice Geoffrey West, «se conoce cuando se ve».

  Lecciones aprendidas del evento React Global Online Summit 22 - Senior Track

La complejidad en el modelo Cynefin

– Se caracteriza por la relación entre causa y efecto

– ¿Hasta qué punto es predecible el resultado de una acción?

– En situaciones complejas, el resultado sólo puede determinarse mediante la experimentación empírica.

Por ejemplo:

– ¿Qué pasará si cambio esta línea de código?

– Un cambio que rompe partes no relacionadas del sistema

– No saber a qué módulos afectan los nuevos requisitos empresariales

¿Qué causa la complejidad?

  • La complejidad surge de la interacción entre el diseño del sistema y nuestras capacidades cognitivas. En ella influyen los entresijos de la estructura y el comportamiento del sistema, así como nuestra capacidad para comprender y navegar por sus complejidades utilizando nuestras facultades cognitivas.

– Capacidad estimada de tratamiento de la información en la década de 1950: 7 +/- 2

Miller, G. A. (1994). El número mágico siete, más o menos dos: Algunos límites de nuestra capacidad para procesar información. Psychological Review, 101(2), 343-352

– Capacidad estimada de tratamiento de la información en la década de 2000: 4 +/- 1

Cowan, Nelson. «El número mágico 4 en la memoria a corto plazo: Una reconsideración de la capacidad de almacenamiento mental». Ciencias del comportamiento y del cerebro 24.1 (2001): 87-114.

Evaluación de la complejidad

Las métricas desempeñan un papel crucial a la hora de abordar la complejidad de los sistemas, ya que nos permiten cuantificar y evaluar los intrincados aspectos del diseño de sistemas y las capacidades cognitivas.

  • Métrica de abstracción

La relación entre el número de clases abstractas e interfaces en el paquete analizado y el número total de clases en el paquete analizado. (Wikipedia)

  3 conferencias organizadas por DevNetwork en agosto

Abstracción (A) = número de tipos abstractos/número de tipos concretos

  • Métrica de inestabilidad

Relación entre el acoplamiento eferente (Ce) y el acoplamiento total (Ce + Ca).

Esta métrica es un indicador de la resistencia del paquete al cambio.

I=0 indica un paquete completamente estable

I=1 indica un paquete completamente inestable.

Inestabilidad (I) = nº de tipos de los que depende / (nº de tipos de los que depende + nº de tipos de los que depende)

  • Distancia de la secuencia principal (D)

Distancia perpendicular de un paquete a la línea idealizada A + I = 1. Esta métrica es un indicador del equilibrio del paquete entre abstracción y estabilidad. Un paquete situado en la secuencia principal presenta un equilibrio óptimo entre abstracción y estabilidad. Los paquetes ideales son completamente abstractos y estables (I=0, A=1) o completamente concretos e inestables (I=1, A=0).

D=|A+I-1|

EL COSTE DEL CAMBIO ES PROPORCIONAL A LA DISTANCIA ENTRE LOS COMPONENTES

El objetivo

El objetivo de la evaluación de la complejidad es identificar las decisiones de diseño que contribuyen a una mayor carga cognitiva, lo que en última instancia conduce a mayores niveles de complejidad.

En esta primera parte, hemos explorado la importancia de las métricas y evaluado la complejidad dentro de una arquitectura de software. Sin embargo, aún queda mucho por descubrir. Permanece atento a la segunda parte, en la que profundizaremos en las métricas para el éxito y en el concepto de fuerza de integración. Acompáñanos en este interesante viaje hacia un enfoque pragmático de las métricas de arquitectura.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Suscríbete a nuestro boletín de noticias

Recibe actualizaciones de los últimos descubrimientos tecnológicos

¿Tienes un proyecto desafiante?

Podemos trabajar juntos

apiumhub software development projects barcelona
Secured By miniOrange