🏛️ Diseño arquitectónico de software

1. En el estilo arquitectónico en capas (layered), cada capa se comunica únicamente con las capas adyacentes y sólo puede acceder a los servicios que éstas exponen. Esta organización jerárquica tiene como principal compromiso (trade-off) de calidad...

1. Una reducción del desempeño debido al paso de las peticiones a través de varias capas
2. Una reducción de la seguridad por la exposición directa de la base de datos
3. Un aumento del acoplamiento entre los módulos de presentación y de datos
4. Una pérdida de la capacidad de realizar pruebas unitarias de cada componente

El estilo en capas mejora la mantenibilidad y la portabilidad al aislar responsabilidades por nivel, pero cada petición debe atravesar varias capas, lo que reduce el desempeño. (Bass, L., Clements, P. & Kazman, R. (2012). Software Architecture in Practice, 3a ed., Addison-Wesley.)

2. Un equipo de desarrollo está diseñando el software administrativo de una universidad. El requerimiento prioritario del cliente es que el sistema sea fácil de mantener y que el módulo de acceso a datos pueda sustituirse por otro motor de base de datos en el futuro, sin modificar la lógica de negocio. ¿Qué estilo arquitectónico conviene seleccionar, aceptando como compromiso una posible pérdida de desempeño?

1. Arquitectura de microservicios
2. Arquitectura en capas
3. Arquitectura orientada a eventos
4. Estilo de tubos y filtros

Aislar el acceso a datos en un nivel independiente favorece la mantenibilidad y la portabilidad, a costa de un posible menor desempeño; microservicios y eventos añadirían complejidad distribuida innecesaria para este requerimiento. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed.)

3. En la arquitectura cliente-servidor de tres capas (3-tier), la presentación, la lógica de negocio y el acceso a datos se despliegan en niveles separados. ¿Cuál es la principal ventaja de esta separación frente al modelo cliente-servidor de dos capas (2-tier)?

1. Permite que el cliente acceda directamente a la base de datos sin pasar por un servidor de aplicaciones
2. Concentra la lógica de negocio en el cliente para reducir la carga del servidor
3. Permite escalar y modificar la lógica de negocio sin afectar directamente al cliente ni a la base de datos
4. Elimina la necesidad de comunicación en red entre el cliente y el servidor

Al ubicar la lógica de negocio en un nivel intermedio, ésta puede escalar y modificarse sin afectar al cliente ni a la base de datos, a diferencia del modelo de dos capas. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed.; concepto estándar de arquitectura cliente-servidor de n niveles.)

4. Una empresa requiere que las computadoras cliente de sus sucursales remotas, con hardware limitado, ejecuten el mínimo de lógica posible y deleguen el procesamiento y las reglas de negocio a un servidor central. ¿Qué configuración cliente-servidor corresponde a este requerimiento?

1. Cliente pesado (fat client)
2. Arquitectura entre pares (peer-to-peer)
3. Arquitectura de microkernel
4. Cliente ligero (thin client)

Un cliente ligero delega el procesamiento y las reglas de negocio al servidor y sólo maneja la presentación, lo que resulta apropiado para hardware limitado; el cliente pesado ejecuta buena parte de la lógica de forma local. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed.; concepto estándar de cliente ligero/pesado.)

5. ¿Cuál de las siguientes afirmaciones sobre el estilo arquitectónico en capas es INCORRECTA?

1. Cada capa sólo puede comunicarse con capas no adyacentes para reducir el número de saltos
2. Una capa puede sustituirse por otra implementación sin afectar a las capas que no dependen directamente de su interfaz
3. El aislamiento de responsabilidades por nivel favorece la portabilidad del sistema
4. El paso de una petición a través de varias capas puede introducir sobrecarga de desempeño

En el estilo en capas, cada capa debe comunicarse sólo con las capas adyacentes, no con capas no adyacentes; esta afirmación invierte la regla real del estilo, por lo que es la incorrecta. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed.)

6. En el patrón Modelo-Vista-Controlador (MVC), el componente responsable de mantener la lógica de negocio y el estado del sistema, independientemente de cómo se presente al usuario, es...

1. La vista
2. El modelo
3. El controlador
4. El adaptador

El modelo encapsula la lógica de negocio y el estado del sistema; la vista sólo presenta datos y el controlador gestiona la entrada del usuario. (Buschmann, F. et al. (1996), Pattern-Oriented Software Architecture (POSA), Vol. 1, patrón Modelo-Vista-Controlador.)

7. Un sistema de reportes debe mostrar la misma información de ventas en un panel web y en una aplicación de escritorio, sin duplicar la lógica de cálculo de totales. El equipo busca un patrón que separe la lógica de negocio de la presentación y permita varias representaciones simultáneas del mismo dato. ¿Qué patrón conviene aplicar, aceptando como costo una mayor complejidad estructural?

1. Tubos y filtros
2. Publicar-suscribir
3. Modelo-Vista-Controlador
4. Broker

MVC permite tener múltiples vistas del mismo modelo sin duplicar la lógica de negocio, a costa de una mayor complejidad estructural. (Buschmann et al. (1996), POSA Vol. 1, patrón MVC.)

8. Durante una revisión arquitectónica, un interesado señala que el sistema actual permite que la interfaz de usuario invoque directamente a los procedimientos almacenados de la base de datos, sin pasar por un componente que contenga las reglas de negocio. Esto dificulta portar la aplicación a otro motor de base de datos. ¿Qué decisión de diseño corrige este problema conforme al estilo en capas?

1. Sustituir la base de datos relacional por un sistema de mensajería publicar-suscribir
2. Duplicar la interfaz de usuario en un cliente pesado y un cliente ligero
3. Reemplazar los procedimientos almacenados por una pizarra (blackboard) compartida
4. Insertar un componente de lógica de negocio que aísle la interfaz del acceso directo a los datos

El estilo en capas exige que la interfaz de usuario no acceda directamente a los datos; intercalar un componente de lógica de negocio aísla esa dependencia y mejora la portabilidad. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed.)

9. En el estilo publicar-suscribir (publish-subscribe) orientado a eventos, los productores de eventos no conocen directamente a los consumidores. Esta característica proporciona principalmente...

1. Bajo acoplamiento y escalabilidad
2. Orden garantizado en el procesamiento de los eventos
3. Garantía de entrega exactamente una vez para cada evento
4. Un flujo de control fácil de rastrear durante la depuración

Al desconocerse productores y consumidores entre sí se logra bajo acoplamiento y escalabilidad, pero se pierde control sobre el orden y la garantía de entrega, y es difícil razonar el flujo de control. (Buschmann et al. (1996), POSA Vol. 1 (Publisher-Subscriber); Bass, Clements & Kazman (2012).)

10. Una plataforma de comercio electrónico necesita que, al confirmarse un pedido, se notifique de manera independiente a los módulos de facturación, envíos y notificación al cliente, sin que el módulo de pedidos tenga que conocer ni invocar directamente a cada uno de ellos. ¿Qué estilo arquitectónico satisface mejor este requerimiento?

1. Arquitectura en capas estricta
2. Arquitectura orientada a eventos con publicar-suscribir
3. Arquitectura cliente-servidor de dos capas
4. Patrón Modelo-Vista-Controlador

El estilo publicar-suscribir permite que el productor (pedidos) publique un evento sin conocer a los consumidores (facturación, envíos, notificaciones), logrando bajo acoplamiento. (Buschmann et al. (1996), POSA Vol. 1; Bass, Clements & Kazman (2012).)

11. Un equipo migró su sistema de procesamiento de pagos a una arquitectura orientada a eventos para desacoplar los servicios. Meses después detecta que es difícil determinar la secuencia exacta en que se procesaron ciertos eventos relacionados con un mismo pago, lo que complica la auditoría. ¿A qué compromiso (trade-off) inherente al estilo corresponde este problema?

1. Sobrecarga de desempeño por el paso de peticiones a través de múltiples capas
2. Acoplamiento excesivo entre el productor y los consumidores del evento
3. Pérdida de control sobre el orden y la garantía de entrega de los eventos
4. Imposibilidad de escalar horizontalmente los servicios consumidores

Es un compromiso documentado del estilo publicar-suscribir: el desacoplamiento entre productores y consumidores dificulta garantizar y razonar el orden de procesamiento de los eventos. (Buschmann et al. (1996), POSA Vol. 1; Bass, Clements & Kazman (2012).)

12. El patrón Broker coordina la comunicación entre clientes y servidores remotos en un sistema distribuido y oculta la ubicación física de estos últimos. Su implementación de referencia clásica, basada en un estándar de objetos distribuidos, es...

1. SOAP
2. REST
3. gRPC
4. CORBA

El patrón Broker se asocia clásicamente con CORBA (Common Object Request Broker Architecture), que provee transparencia de ubicación entre clientes y objetos remotos. (Buschmann et al. (1996), POSA Vol. 1, patrón Broker.)

13. Una organización con oficinas en distintas ciudades necesita que sus aplicaciones cliente invoquen servicios remotos sin conocer en qué computadora física ni en qué ciudad se ejecuta cada servicio, delegando esa resolución a un componente intermediario. ¿Qué patrón arquitectónico describe mejor esta necesidad de transparencia de ubicación?

1. Broker
2. Tubos y filtros
3. Modelo-Vista-Controlador
4. Capas estrictas

El patrón Broker coordina la comunicación cliente-servidor remoto y provee transparencia de ubicación mediante un componente intermediario. (Buschmann et al. (1996), POSA Vol. 1, patrón Broker.)

14. Conforme al teorema CAP de Brewer, cuando ocurre una partición de red en un sistema de datos distribuido, el arquitecto debe sacrificar...

1. La tolerancia a particiones o la seguridad de los datos
2. La consistencia o la disponibilidad del sistema
3. El desempeño o la escalabilidad horizontal
4. La disponibilidad o la portabilidad del sistema

El teorema CAP establece que ante una partición de red debe sacrificarse consistencia o disponibilidad, ya que la tolerancia a particiones es indispensable en un sistema distribuido. (Brewer, E. (2000), PODC keynote; Gilbert, S. & Lynch, N. (2002), ACM SIGACT News 33(2).)

15. Un sistema de inventario distribuido geográficamente debe seguir aceptando ventas en cada sucursal incluso si se pierde la conexión de red entre centros de datos, aunque temporalmente los totales de inventario mostrados difieran entre sucursales. Conforme al teorema CAP, ¿qué combinación de propiedades privilegia este diseño ante una partición de red?

1. Consistencia y tolerancia a particiones, sacrificando disponibilidad
2. Consistencia y disponibilidad, sacrificando tolerancia a particiones
3. Disponibilidad y tolerancia a particiones, sacrificando consistencia inmediata
4. Desempeño y consistencia, sacrificando escalabilidad

Al seguir aceptando ventas pese a la partición de red, el sistema prioriza disponibilidad y tolerancia a particiones, aceptando consistencia eventual entre sucursales. (Brewer, E. (2000); Gilbert, S. & Lynch, N. (2002), ACM SIGACT News 33(2).)

16. El estilo de microservicios favorece el despliegue independiente de cada servicio y la escalabilidad selectiva por componente. ¿Cuál es el principal compromiso (trade-off) que introduce frente a una arquitectura monolítica?

1. Una reducción de la escalabilidad al concentrar toda la carga en un solo componente
2. Una mayor dificultad para desplegar nuevas versiones sin detener el sistema completo
3. Una menor cobertura de pruebas de integración entre los servicios
4. La complejidad de un sistema distribuido, con latencia de red y consistencia eventual de los datos

Microservicios ganan autonomía de despliegue y escalabilidad selectiva, pero suman la complejidad propia de un sistema distribuido: latencia de red y consistencia eventual de los datos. (Newman, S. (2015), Building Microservices, O'Reilly; Richardson, C. (2018), Microservices Patterns, Manning.)

17. Un arquitecto necesita que un servicio distribuido detecte automáticamente cuándo un nodo remoto deja de responder, antes de poder activar un mecanismo de recuperación. ¿Qué táctica de disponibilidad corresponde específicamente a la etapa de detección de fallas?

1. Latido (heartbeat) entre los nodos
2. Redundancia activa con votación
3. Redundancia pasiva con repuesto (spare)
4. Manejo de excepciones (exception handling)

La detección de fallas emplea tácticas como ping/echo y heartbeat (latido); la redundancia activa o pasiva corresponde a la etapa de recuperación, no de detección. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed., cap. de Disponibilidad.)

18. En un sistema distribuido de alta disponibilidad, dos réplicas activas procesan las mismas peticiones en paralelo y un componente vota entre sus resultados para tolerar fallas. ¿A qué táctica de disponibilidad corresponde este mecanismo?

1. Latido (heartbeat) entre nodos
2. Redundancia activa (votación entre réplicas)
3. Ping/echo entre componentes
4. Redundancia pasiva (repuesto o spare)

La redundancia activa mantiene réplicas procesando en paralelo y decide por votación entre sus resultados, a diferencia de la redundancia pasiva, donde el repuesto se activa sólo después de la falla. (Bass, Clements & Kazman (2012), Software Architecture in Practice, 3a ed., cap. de Disponibilidad.)

19. El modelo de vistas 4+1 de Kruchten organiza la descripción de una arquitectura de software en cuatro vistas principales más una vista adicional que integra y valida a las demás. ¿Cuál es esta vista adicional?

1. Vista de implementación (desarrollo)
2. Vista de proceso
3. Vista de escenarios (casos de uso)
4. Vista física (despliegue)

La vista de escenarios (casos de uso) es el '+1' que integra y valida las vistas lógica, de proceso, de desarrollo y física del modelo. (Kruchten, P. (1995). 'Architectural Blueprints—The 4+1 View Model of Software Architecture'. IEEE Software 12(6).)

20. Un interesado del proyecto necesita entender cómo se distribuirán los procesos del sistema entre los distintos servidores físicos y cómo se comunicarán en red durante el despliegue. ¿Qué vista del modelo 4+1 responde directamente a esta preocupación?

1. Vista lógica
2. Vista de desarrollo (implementación)
3. Vista de escenarios
4. Vista física (despliegue)

La vista física describe la asignación de los elementos de software al hardware y la topología de red, atendiendo preocupaciones de despliegue. (Kruchten, P. (1995), IEEE Software 12(6).)

21. Un arquitecto debe documentar cómo se organizará el código fuente en módulos, paquetes y bibliotecas, así como las dependencias de compilación entre ellos, para que el equipo administre el trabajo en paralelo. ¿Qué vista del modelo 4+1 corresponde a esta preocupación?

1. Vista de desarrollo (implementación)
2. Vista lógica
3. Vista de proceso
4. Vista física

La vista de desarrollo (implementación) describe la organización estática del código en módulos y sus dependencias de compilación; la vista lógica se enfoca en la funcionalidad orientada al usuario final. (Kruchten, P. (1995), IEEE Software 12(6).)

22. Conforme a la norma ISO/IEC/IEEE 42010, una preocupación (concern) de los interesados que resulta clave para justificar la selección de un estilo arquitectónico es...

1. El lenguaje de programación empleado por el equipo
2. Un atributo de calidad del sistema
3. El nombre comercial del producto de software
4. La fecha de entrega contractual del proyecto

La norma ISO/IEC/IEEE 42010 define las preocupaciones como los intereses de los interesados respecto al sistema; los atributos de calidad son una preocupación central para decidir la arquitectura. (ISO/IEC/IEEE 42010:2011 — Systems and software engineering: Architecture description.)

23. En la norma ISO/IEC/IEEE 42010, un punto de vista (viewpoint) se define como...

1. La representación concreta de un sistema particular desde una perspectiva
2. El documento final que entrega el arquitecto al cliente
3. Un conjunto de convenciones para construir un tipo de vista que atiende una o más preocupaciones de los interesados
4. El conjunto de requerimientos funcionales del sistema

El punto de vista (viewpoint) son las convenciones para construir un tipo de vista; la vista (view) es la representación concreta resultante de aplicar un punto de vista a un sistema particular. (ISO/IEC/IEEE 42010:2011.)

24. El modelo C4 para documentar arquitectura de software propone representar el sistema en niveles progresivos de detalle: contexto, contenedores, componentes y...

1. Clases
2. Casos de uso
3. Clústeres
4. Código

El modelo C4 (Simon Brown) define cuatro niveles jerárquicos de abstracción: contexto, contenedores, componentes y código, cada uno con mayor detalle técnico. (Brown, S., 'The C4 model for visualising software architecture' (c4model.com).)

25. Un arquitecto debe presentar a los directivos de una empresa, sin formación técnica, un diagrama que muestre el sistema como una sola caja y sus relaciones con los usuarios y otros sistemas externos, sin detallar su estructura interna. ¿Qué nivel del modelo C4 es adecuado para esta audiencia?

1. Diagrama de contexto
2. Diagrama de contenedores
3. Diagrama de componentes
4. Diagrama de código

El diagrama de contexto del modelo C4 muestra el sistema como una caja única y sus interacciones externas, sin detalle interno, lo que resulta apropiado para audiencias no técnicas. (Brown, S., 'The C4 model for visualising software architecture' (c4model.com).)

26. Un equipo de arquitectura necesita mostrar a los desarrolladores cómo se divide internamente una aplicación web en unidades desplegables por separado —por ejemplo, la aplicación web, la base de datos y un servicio de procesamiento en segundo plano— sin llegar todavía al detalle de las clases o módulos internos de cada una. ¿Qué nivel del modelo C4 corresponde a esta necesidad?

1. Diagrama de contexto
2. Diagrama de contenedores
3. Diagrama de componentes
4. Diagrama de código

El nivel de contenedores del modelo C4 muestra las unidades de despliegue (aplicaciones, bases de datos, servicios) y su comunicación, con más detalle que el contexto pero sin llegar a los componentes internos. (Brown, S., 'The C4 model for visualising software architecture' (c4model.com).)

27. Entre las ventajas principales que ofrece un estilo de microservicios frente a una aplicación monolítica se encuentra la posibilidad de...

1. Desplegar y escalar cada servicio de manera independiente, según la demanda específica de cada uno.
2. Reducir la latencia de comunicación entre módulos al ejecutarlos dentro de un mismo proceso.
3. Compartir una única base de datos entre todos los módulos para simplificar las transacciones.
4. Eliminar la necesidad de definir contratos o interfaces entre los componentes del sistema.

Los microservicios permiten desplegar y escalar cada servicio de forma independiente según su propia demanda; las otras opciones describen rasgos propios de un monolito o ideas erróneas. (Newman, S. (2015), Building Microservices, O'Reilly; Richardson, C. (2018), Microservices Patterns, Manning.)

28. El principal compromiso (trade-off) que se asume al adoptar una arquitectura de microservicios, en comparación con un monolito, es...

1. Un incremento en la complejidad operativa, con latencia de red y consistencia eventual entre servicios.
2. Una disminución en la capacidad de escalar los módulos de manera independiente.
3. Una reducción en la autonomía de los equipos responsables de cada servicio.
4. Una dependencia obligatoria de un único lenguaje de programación para todos los servicios.

Newman y Richardson señalan que el costo de los microservicios es la complejidad distribuida (latencia, consistencia eventual, sobrecarga operativa); las otras opciones contradicen los beneficios reales del estilo. (Newman, S. (2015), Building Microservices, O'Reilly; Richardson, C. (2018), Microservices Patterns, Manning.)

29. Un equipo de cuatro desarrolladores debe construir, en un plazo corto, una aplicación administrativa interna con un dominio de negocio simple y sin previsión de picos de carga diferenciados entre sus módulos. Desde el punto de vista de atributos de calidad y costo operativo, ¿qué estilo arquitectónico es más adecuado para este escenario?

1. Un monolito modular con separación interna de responsabilidades por capa o módulo.
2. Una arquitectura de microservicios con un servicio independiente por cada módulo de negocio.
3. Una arquitectura de microkernel con un núcleo mínimo y plug-ins para cada módulo.
4. Una malla de servicios (service mesh) con proxies dedicados para cada módulo de negocio.

Con un equipo pequeño, dominio simple y sin necesidad de escalado diferenciado, un monolito modular minimiza la complejidad operativa sin sacrificar la separación interna de responsabilidades. (Newman, S. (2015), Building Microservices, O'Reilly.)

30. Una empresa cuenta con seis equipos autónomos, cada uno responsable de un módulo de negocio distinto, que necesitan desplegar sus cambios en fechas independientes, usar distintas tecnologías según el caso y escalar únicamente el módulo de pagos durante campañas de alto tráfico. ¿Qué estilo arquitectónico responde mejor a estos requerimientos?

1. Microservicios, con un servicio independiente por módulo de negocio y despliegue autónomo por equipo.
2. Monolito en capas, con módulos separados internamente pero desplegados como una sola unidad.
3. Tubos y filtros, con cada módulo de negocio implementado como un filtro secuencial.
4. Pizarra (blackboard), con los módulos de negocio colaborando sobre una estructura de datos compartida.

Despliegue independiente por equipo, heterogeneidad tecnológica y escalado selectivo son justamente los factores que motivan la adopción de microservicios; el monolito no permite desplegar módulos por separado. (Newman, S. (2015), Building Microservices; Richardson, C. (2018), Microservices Patterns.)

31. ¿Cuál de las siguientes afirmaciones sobre la migración de un monolito hacia microservicios NO es correcta?

1. Permite escalar de manera independiente los servicios con mayor demanda.
2. Introduce consistencia eventual entre los datos de distintos servicios, en lugar de consistencia inmediata.
3. Facilita que distintos equipos desplieguen sus servicios sin coordinar un único ciclo de versión.
4. Garantiza una consistencia transaccional inmediata entre todos los servicios, igual o mejor que en el monolito.

Al tener cada microservicio su propia base de datos, la consistencia entre servicios suele ser eventual, no inmediata; afirmar lo contrario es un error conceptual frecuente. (Richardson, C. (2018), Microservices Patterns, Manning.)

32. Una plataforma de comercio electrónico tiene un monolito estable que atiende bien la mayoría de sus módulos, pero el módulo de procesamiento de pagos sufre picos de tráfico diez veces mayores durante campañas específicas y requiere cumplir con un esquema de seguridad y auditoría distinto al resto del sistema. El equipo de arquitectura busca resolver este cuello de botella con el menor impacto posible sobre el resto del sistema. ¿Cuál es la decisión de diseño arquitectónico más adecuada?

1. Extraer el módulo de pagos como un microservicio independiente, conservando el resto del sistema como monolito.
2. Migrar la totalidad del monolito a microservicios para homogeneizar la arquitectura de todos los módulos.
3. Aumentar los recursos de cómputo asignados a todo el monolito durante las campañas de alto tráfico.
4. Duplicar el monolito completo en un segundo servidor y balancear la carga entre ambas copias.

Extraer selectivamente el módulo con requerimientos distintos de escalado y seguridad hacia su propio servicio (patrón strangler) resuelve el problema puntual sin el costo y riesgo de migrar todo el sistema. (Newman, S. (2015), Building Microservices, O'Reilly (patrón strangler fig application).)

33. De acuerdo con el modelo de calidad del producto de software de la norma ISO/IEC 25010:2011, ¿cuántas características principales de calidad se definen para guiar, entre otras cosas, la selección de un estilo arquitectónico?

1. Seis características.
2. Siete características.
3. Ocho características.
4. Nueve características.

ISO/IEC 25010:2011 define ocho características (adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad); nueve corresponde a la revisión de 2023. (ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE).)

34. ¿Cuál de las siguientes características NO forma parte del modelo de calidad del producto de software de la norma ISO/IEC 25010:2011?

1. Mantenibilidad.
2. Seguridad.
3. Portabilidad.
4. Escalabilidad.

Las ocho características de ISO/IEC 25010:2011 son adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad; la escalabilidad no aparece como característica principal. (ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE).)

35. La revisión ISO/IEC 25010:2023 del modelo de calidad del producto de software amplió el número de características principales de ocho a nueve, al incorporar como característica independiente a...

1. La inocuidad/seguridad física (Safety).
2. La interoperabilidad.
3. La confiabilidad.
4. La eficiencia de desempeño.

ISO/IEC 25010:2023 agregó Safety como una novena característica independiente del modelo de calidad del producto. (ISO/IEC 25010:2023 — Systems and software engineering (SQuaRE): Product quality model.)