Be Software Architecture Wise
Be Wise Apps

Read in English · Lire en français · Auf Deutsch lesen

Capítulo 2 de 12 · Intermedio

Atributos de calidad y requisitos arquitectónicamente significativos

La arquitectura existe para lograr cualidades: velocidad bajo carga, seguir funcionando cuando fallan algunas partes, poder cambiarse con seguridad, mantener los datos en secreto. Este capítulo muestra cómo convertir deseos vagos como 'rápido', 'fiable' y 'seguro' en requisitos precisos y comprobables que puedan guiar las decisiones de diseño. Trata la diferencia entre requisitos funcionales, atributos de calidad y restricciones, el modelo de calidad ISO/IEC 25010, los escenarios de atributos de calidad, la aritmética del rendimiento y de la disponibilidad, el diseño para el cambio, la seguridad, la usabilidad y el costo como cualidades, y cómo elicitarlas, priorizarlas y establecer compromisos entre ellas. Es adecuado para desarrolladores que se acercan a la arquitectura y para cualquiera que redacte o revise requisitos.

Introducción en video al capítulo 2

6 min · narrado en inglés, con subtítulos
Solo escuchar (audio)
Leer la transcripción

Te damos la bienvenida al Capítulo 2: Atributos de calidad y requisitos arquitectónicamente significativos. La arquitectura existe para lograr cualidades: velocidad bajo carga, seguir funcionando cuando fallan algunas partes, poder cambiarse con seguridad, mantener los datos en secreto. Este capítulo muestra cómo convertir deseos vagos como rápido, fiable y seguro en requisitos precisos y comprobables que puedan guiar las decisiones de diseño.

Pregunta a cualquier grupo de partes interesadas qué debe hacer un sistema y obtendrás una lista de funcionalidades: buscar un vuelo, pagar un carrito, reservar una cita. Pregunta con qué calidad debe hacerlo y las respuestas son más vagas: debe ser rápido, no debe caerse, debe ser seguro. Esas segundas respuestas son atributos de calidad, y son de lo que trata principalmente la arquitectura. Un requisito que tiene un efecto medible en la estructura de un sistema se llama requisito arquitectónicamente significativo. La mayoría de ellos resultan ser atributos de calidad o restricciones, más que funciones.

Este diagrama de la sección dos punto uno lo deja claro. Dos sistemas de venta de entradas tienen funcionalidades idénticas: explorar eventos, reservar asientos y pagar. Uno vende entradas para un salón local de trescientas plazas. Su momento de más actividad trae unas pocas solicitudes por segundo, así que una aplicación web con una base de datos es la respuesta correcta: barata, sencilla y fácil de cambiar. El otro vende una gira por estadios de sesenta mil plazas. Debe absorber una ráfaga miles de veces mayor y no vender nunca el mismo asiento dos veces. Por eso necesita una caché de páginas, una sala de espera virtual, un inventario de asientos cuidadosamente diseñado, un almacenamiento particionado y una cola de pagos. Las mismas funciones, arquitecturas completamente distintas. La diferencia procede por completo de los atributos de calidad y las restricciones.

Este capítulo es adecuado para desarrolladores que se están acercando a la arquitectura. También es adecuado para cualquiera que redacte o revise requisitos. Necesitarás cierta soltura con la aritmética sencilla: porcentajes, multiplicación y división. Se basa en la idea del Capítulo 1 de que la arquitectura existe para satisfacer las inquietudes de las partes interesadas mediante compromisos. Este capítulo precisa esas inquietudes. Y lleva al Capítulo 3, que presenta los principios de diseño que usan los arquitectos para lograr estas cualidades.

Hay ocho secciones. La sección dos punto uno separa los requisitos funcionales, los atributos de calidad y las restricciones, y analiza un sistema de venta de entradas para conciertos el día en que sale a la venta una gran gira. La sección dos punto dos presenta la norma internacional de calidad del producto, con sus nueve características, y muestra cómo usarla como recordatorio y no como un formulario que rellenar. La sección dos punto tres enseña la técnica más útil del capítulo: el escenario de atributo de calidad de seis partes, que convierte debe ser rápido en un enunciado que se puede probar.

Esta es su forma. Un escenario cuenta una breve historia, de izquierda a derecha. Una fuente, alguien o algo, produce un estímulo: un evento al que el sistema debe responder, como una ráfaga de solicitudes o la caída de un servidor. El estímulo llega a un artefacto, el sistema completo o una parte de él, dentro de un entorno: funcionamiento normal, un pico, un estado degradado o un ataque. El artefacto responde, y la respuesta se juzga con una medida de la respuesta: el número. El estímulo y la medida de la respuesta son las dos partes que más a menudo se omiten, y las dos que más importan. El ejemplo de debajo lo junta todo: quinientos compradores por segundo llegan al proceso de pago el Black Friday, y los pedidos se confirman en un segundo y medio en el percentil noventa y nueve, sin pedidos perdidos.

Las secciones dos punto cuatro a dos punto siete recorren las cualidades que con más frecuencia dan forma a las arquitecturas. La sección dos punto cuatro trata el rendimiento y la escalabilidad, con aritmética real: latencia y throughput, percentiles, encolamiento y los límites de añadir más procesadores. La sección dos punto cinco hace lo mismo con la disponibilidad y la fiabilidad: los nueves, el tiempo entre fallos y el tiempo de reparación, y cómo se combinan los componentes en serie y en paralelo. La sección dos punto seis trata las cualidades del cambio: modificabilidad, capacidad de prueba y desplegabilidad. La sección dos punto siete reúne la seguridad, la usabilidad y la accesibilidad, la interoperabilidad, el costo, la eficiencia energética, la seguridad física y las cualidades regulatorias.

Este es el capítulo en el que el curso empieza a calcular. Verás por qué una solicitud a un servidor ocupado al noventa por ciento tarda, de media, diez veces su tiempo de servicio. Nada de las matemáticas es más difícil que la aritmética escolar. Los números también desenmascaran la falsa tranquilidad. Un tiempo de respuesta medio de ciento veinte milisegundos puede ocultar que una de cada cincuenta solicitudes tarda más de un segundo. Por eso los profesionales especifican percentiles. La sección dos punto ocho cierra el círculo. Ningún sistema puede ser rápido, disponible, seguro, barato y fácil de cambiar, todo a la vez. Muestra cómo un taller y un árbol de utilidad convierten un montón de opiniones en una lista ordenada, y qué cualidades entran en conflicto.

Si recuerdas una sola cosa de este capítulo, que sea esta: una cualidad no es un requisito hasta que tiene un estímulo, un contexto y una medida. El proceso de pago debe ser rápido es un deseo. Cuando dos mil clientes por minuto envían pedidos durante el pico del viernes por la noche, el noventa y nueve por ciento de los pagos se completa en un segundo y medio: eso es un requisito. Se puede diseñar para él, probar, monitorizar y discutir con pruebas.

Lo mejor es leer en orden las secciones dos punto uno a dos punto tres, porque el resto del capítulo usa su vocabulario. Después, puedes ir directamente a las cualidades que necesites. Leer todo el capítulo lleva unas tres horas. Cuando una sección haga cálculos, resuelve tú mismo los números. Así es como se convierten en herramientas que puedes usar en una conversación real. Cada sección termina con unas cuantas preguntas de autoevaluación. Respóndelas mentalmente antes de mirar. Cuando estés listo, haz la prueba opcional del capítulo: veinte preguntas de opción múltiple y dos respuestas escritas, en unos cuarenta y cinco minutos. La nota de aprobado es el ochenta por ciento.

Ese es el mapa del Capítulo 2. Empieza por la sección dos punto uno, donde separamos los requisitos funcionales, los atributos de calidad y las restricciones, y conocemos un sistema de venta de entradas en su día de más actividad. Nos vemos allí.

Descargar el capítulo (PDF)Leer en la app

De un vistazo

Aprenderás a

  • Distinguir los requisitos funcionales, los atributos de calidad y las restricciones, y reconocer un requisito arquitectónicamente significativo.
  • Usar el modelo de calidad del producto de ISO/IEC 25010:2023 como lista de comprobación sin dejar que se convierta en papeleo.
  • Escribir escenarios de atributos de calidad de seis partes con medidas de la respuesta medibles, y convertir enunciados vagos en enunciados comprobables.
  • Calcular con percentiles, la ley de Little, fórmulas sencillas de colas y la ley de Amdahl para razonar sobre el rendimiento y la escalabilidad.
  • Calcular la disponibilidad a partir de los nueves, a partir del MTBF y el MTTR, y para componentes en serie y en paralelo.
  • Explicar cómo se especifican y se logran la modificabilidad, la capacidad de prueba, la desplegabilidad, la seguridad, la usabilidad, el costo y la sostenibilidad.
  • Elicitar y priorizar requisitos de calidad con un árbol de utilidad, y explicar los compromisos entre cualidades que compiten entre sí.

Antes de empezar

El Capítulo 1, en especial las secciones sobre las partes interesadas y sus inquietudes y sobre las decisiones y los compromisos. Cierta soltura con la aritmética sencilla (porcentajes, multiplicación y división).

Tiempo

Unas 3 horas de lectura; 45 minutos para la prueba.

Términos clave

atributo de calidad · restricción · requisito arquitectónicamente significativo · ISO/IEC 25010 · escenario de atributo de calidad · medida de la respuesta · latencia y rendimiento (throughput) · percentil · Ley de Little · disponibilidad · MTTR · táctica · árbol de utilidad · función de aptitud (fitness function)

Por qué son las cualidades, y no las funcionalidades, las que deciden la arquitectura

Pregunta a cualquier grupo de partes interesadas qué debe hacer un sistema y obtendrás una lista de funcionalidades: buscar un vuelo, pagar un carrito, reservar una cita. Pregunta con qué calidad debe hacerlo y las respuestas suelen ser más vagas: debe ser rápido, no debe caerse, debe ser seguro, debe ser fácil de cambiar. Esas segundas respuestas son atributos de calidad, y son de lo que trata principalmente la arquitectura. La misma lista de funcionalidades puede ofrecerla un único programa en un servidor o cuarenta servicios repartidos por tres continentes. Lo que separa esos diseños no es lo que hace el sistema, sino a cuántas personas debe atender a la vez, cuánto tiempo de inactividad puede tolerar el negocio, con qué frecuencia cambiará el código y lo sensibles que son los datos.

El Capítulo 1 describió la arquitectura como el conjunto de decisiones significativas que satisfacen las inquietudes de las partes interesadas mediante compromisos. Este capítulo precisa esas inquietudes. Un requisito que tiene un efecto medible en la estructura de un sistema es un requisito arquitectónicamente significativo, y la mayoría de ellos resultan ser atributos de calidad o restricciones más que funciones. Encontrarlos pronto, y enunciarlos de forma que se puedan probar, es una de las cosas más valiosas que hace un arquitecto.

Cómo encaja el capítulo

La Sección 2.1 separa los requisitos funcionales, los atributos de calidad y las restricciones, explica por qué muchos arquitectos evitan el término 'requisitos no funcionales' y analiza un sistema de venta de entradas para conciertos el día en que sale a la venta una gran gira. La Sección 2.2 presenta el modelo de calidad del producto de ISO/IEC 25010:2023, con sus nueve características, y muestra cómo usarlo como recordatorio y no como un formulario que rellenar. La Sección 2.3 enseña la técnica más útil del capítulo: el escenario de atributo de calidad de seis partes, que convierte 'debe ser rápido' en un enunciado que se puede probar.

Las Secciones 2.4 a 2.7 recorren después las cualidades que con más frecuencia dan forma a las arquitecturas. La Sección 2.4 trata el rendimiento y la escalabilidad con aritmética real: latencia y rendimiento (throughput), percentiles, latencia de cola, la ley de Little, el encolamiento y la ley de Amdahl. La Sección 2.5 hace lo mismo con la disponibilidad y la fiabilidad: los nueves, el tiempo medio entre fallos y el tiempo medio de reparación, y la disponibilidad de componentes en serie y en paralelo. La Sección 2.6 trata las cualidades del cambio (modificabilidad, capacidad de prueba y desplegabilidad), y la Sección 2.7 reúne la seguridad, la usabilidad y la accesibilidad, la interoperabilidad, el costo, la eficiencia energética, la seguridad (safety) y las cualidades regulatorias.

La Sección 2.8 cierra el círculo. Muestra de dónde salen los requisitos de calidad, cómo un taller de atributos de calidad y un árbol de utilidad convierten un montón de opiniones en una lista ordenada, qué cualidades entran en conflicto con cuáles, y cómo las funciones de aptitud siguen comprobando automáticamente las cualidades importantes una vez construida la arquitectura.

De los deseos vagos a los números

Este es el capítulo en el que el curso empieza a calcular. Calcularás cuántas solicitudes están en curso a la vez a partir de una tasa de llegada y un tiempo de respuesta, por qué una solicitud a un servidor ocupado al 90% tarda, de media, diez veces su tiempo de servicio, por qué repartir un trabajo que es un 10% secuencial entre dieciséis procesadores solo da una aceleración de 6.4 veces, y cuántos minutos de inactividad al año permite realmente una promesa de 'cuatro nueves'. Nada de las matemáticas es más difícil que la aritmética escolar, pero cambia las conversaciones: 'la base de datos es lenta' se convierte en 'el pool de conexiones está dimensionado para 100 solicitudes simultáneas y la ley de Little dice que necesitamos 400 durante el pico de la noche'.

Los números también desenmascaran la falsa tranquilidad. Un tiempo de respuesta medio de 120 milisegundos puede ocultar que una de cada cincuenta solicitudes tarda más de un segundo, y por eso los profesionales especifican el percentil 95 o 99. Un requisito sin medida de la respuesta no se puede probar, y un requisito que no se puede probar se sacrificará discretamente cuando se acerque una fecha límite.

Los compromisos son el trabajo

Ningún sistema puede ser a la vez lo más rápido, disponible, seguro, barato y fácil de cambiar posible. La caché mejora la velocidad pero complica la consistencia; el cifrado y las comprobaciones adicionales protegen los datos pero añaden latencia; la redundancia aumenta a la vez la disponibilidad y el costo; los diseños flexibles con plug-ins facilitan el cambio y hacen el rendimiento más difícil de predecir. Por eso el capítulo trata las cualidades como objetivos que compiten entre sí y que hay que ordenar según el contexto, no como casillas que marcar. La habilidad del arquitecto consiste en saber qué dos o tres cualidades importan más para este sistema, enunciarlas con precisión y elegir diseños cuyas debilidades caigan donde el negocio pueda permitírselas.

Las técnicas de diseño que logran cada cualidad, llamadas tácticas, solo se presentan aquí a grandes rasgos. Los capítulos posteriores las desarrollan: los principios de diseño en el Capítulo 3, los estilos arquitectónicos en los Capítulos 5 y 6, las prácticas de datos, seguridad, resiliencia y nube en los Capítulos 7 a 10, y los métodos de evaluación, como ATAM y las funciones de aptitud, en el Capítulo 11.

La idea que debes llevarte

Si recuerdas una sola cosa de este capítulo, que sea esta: una cualidad no es un requisito hasta que tiene un estímulo, un contexto y una medida. 'El proceso de pago debe ser rápido' es un deseo. 'Cuando 2000 clientes por minuto envían pedidos durante el pico del viernes por la noche, el 99% de los pagos se completa en 1.5 segundos' es un requisito. Se puede diseñar para él, probar, monitorizar y discutir con pruebas, y le dice a todos, desde el product owner hasta el equipo de operaciones, cómo es el éxito.

Las 8 secciones

2.1 · Intermedio · 18 minRequisitos funcionales y de calidadQué debe hacer un sistema, con qué calidad debe hacerlo y qué decisiones ya están fijadas. Aprende a detectar los requisitos arquitectónicamente significativos que realmente determinan un diseño.Leer →2.2 · Intermedio · 18 minModelos de calidadEl modelo de calidad del producto de ISO/IEC 25010:2023 y sus nueve características, qué ha cambiado desde 2011, otras listas como FURPS+ y cómo usar un modelo como lista de comprobación sin ahogarse en papeleo.Leer →2.3 · Intermedio · 18 minEscenarios de calidadEl escenario de seis partes que convierte 'rápido', 'seguro' y 'fácil de cambiar' en requisitos comprobables, con ejemplos para seis cualidades, los errores comunes y el camino del escenario a la función de aptitud.Leer →2.4 · Intermedio · 24 minRendimiento y escalabilidadLa latencia y el rendimiento (throughput), los percentiles y la latencia de cola, la ley de Little, el encolamiento y el abismo de la utilización, la ley de Amdahl y la Ley de escalabilidad universal, con cálculos desarrollados y un panorama de las tácticas de rendimiento.Leer →2.5 · Intermedio · 22 minDisponibilidad y fiabilidadQué significan realmente la disponibilidad, la fiabilidad y la tolerancia a fallos, cómo calcular los nueves, el MTBF y el MTTR, cómo se combinan los componentes en serie y en paralelo, y las tácticas, el RTO y el RPO que las hacen posibles.Leer →2.6 · Intermedio · 22 minModificabilidad y desplegabilidadCómo especificar el cambio y diseñar para él: qué cambia, quién lo cambia y cuándo, las tácticas que limitan los efectos en cadena, la capacidad de prueba mediante la controlabilidad y la observabilidad, la desplegabilidad y las métricas de entrega de DORA.Leer →2.7 · Intermedio · 22 minSeguridad, usabilidad y másLa seguridad como cualidad medible, las subcaracterísticas y tácticas de seguridad de ISO/IEC 25010, la usabilidad y la accesibilidad según WCAG 2.2, la interoperabilidad, el costo por transacción, la intensidad de carbono del software, la seguridad (safety), la observabilidad y las cualidades regulatorias.Leer →2.8 · Intermedio · 22 minElicitar y priorizarDe dónde salen los requisitos de calidad, cómo el Quality Attribute Workshop del SEI y el árbol de utilidad de ATAM los descubren y los clasifican, cómo gestionar los conflictos entre cualidades y cómo las funciones de aptitud los mantienen vigentes.Leer →

Prueba del capítulo

Comprueba lo que has entendido del capítulo 2

Opcional: 20 preguntas de opción múltiple y 2 respuestas escritas breves, elegidas de nuevo cada vez de un banco de 72 preguntas. Nota de aprobado: 80%. Superar todas las pruebas de capítulo y después la evaluación final da derecho al Certificado de Finalización Be Wise.

Haz la prueba del capítulo 2 en la app

Lecturas recomendadas