¿Cómo evalúa la arquitectura de un sistema?

La respuesta no es fácil, ya que no es la definición de Sistema. La evaluación dependerá del proyecto y las partes interesadas de la Arquitectura del Sistema (SA).

¿Por qué se necesita su SA en su situación específica?
La SA probablemente debería ser más formal en caso de que sea una documentación oficial del proyecto, o podría ser más específica si solo se usa internamente. ¿Se utilizará como medio de comunicación entre las partes interesadas? ¿Será la base para el análisis y el desarrollo o una mera descripción de un sistema existente? Dependiendo de la situación, la SA puede tener varios usos, y estos usos deben ser claros y descritos desde el principio, si queremos usarlos (por ejemplo, como una lista de verificación) para una mejor evaluación.

¿La SA proporciona un buen diseño para los requisitos del sistema?
A pesar de que la respuesta a esta pregunta a veces puede ser subjetiva, hay formas de evaluar los resultados de la SA de manera más objetiva. Por ejemplo, un análisis de requisitos correcto y una asignación de ellos desde la arquitectura del sistema puede ayudar a evaluar la SA.

¿Quiénes son las partes interesadas en su SA? ¿Cuáles son sus necesidades? ¿Las SA les están dando soluciones?
Las partes interesadas pueden ser diferentes y también nosotros de la SA. Por ejemplo, las empresas subcontratadas podrían utilizar la SA como documento contractual, mejorando la comunicación y reduciendo los riesgos de integración. Un desarrollador puede usar la SA para comprender las limitaciones y explotar la libertad de desarrollo. Analista, Gerente de Proyecto, Integrador, Mantenedor, Probador, Usuario y muchos otros interesados ​​potenciales deben ser identificados y la evaluación de la SA debe considerar su uso de la arquitectura.

Lamentablemente, este tema es demasiado abstracto para ser discutido en unas pocas oraciones. Pero hay algunos libros y documentos que puede usar como referencia:

  • Documenting Software Architectures (http://www.sei.cmu.edu/library/a…) es un buen libro.
  • Un enfoque estructurado para revisar la documentación de arquitectura (http://www.sei.cmu.edu/reports/0…) podría ser lo que está buscando.

Primero, comprenda la arquitectura de sistemas: es el patrón formado por los subsistemas interactivos e interdependientes que forman un sistema de interés. Este patrón también se conoce como la configuración.

Un enfoque razonado para evaluar la arquitectura de los sistemas es representar el sistema en un gráfico N2, que mostrará cada uno de los subsistemas en la diagonal principal y las interconexiones entre los subsistemas en los cuadrados de interfaz apropiados. Este patrón puede ser ‘medido’, por su entropía de configuración o grado de desorden. También se puede reorganizar para minimizar la entropía de configuración, lo que genera una arquitectura ideal. El valor de minimizar la arquitectura es que el sistema es capaz de transferir al máximo su energía interna como trabajo útil, de acuerdo con la Segunda Ley de la Termodinámica.

Hay que decir que evaluar la arquitectura de los sistemas en sí misma tiene un valor limitado. La forma en que se configuran los sistemas se ve de manera más útil en la forma en que funcionan. Por lo tanto, los sistemas defensivos pueden ser “multicapa”, lo que requiere que un enemigo supere varias capas para penetrar en el corazón del sistema, como en un castillo o un sistema de seguridad. Los sistemas de justicia forman arquitecturas de tuberías circulares, con delincuentes que son detenidos, procesados, condenados, encarcelados, puestos en libertad condicional … detenidos de nuevo, y pueden ir y venir continuamente dentro y fuera de la cárcel. Los sistemas de carreteras, sistemas de transporte, sistemas logísticos, sistemas de comunicación, sistemas informáticos, etc., a menudo forman una arquitectura circular, que no tiene principio ni fin.

Evaluar si el sistema cumple con sus requisitos no funcionales . Tenga en cuenta que la arquitectura de cualquier sistema debe ser un reflejo de ellos.

Los requisitos no funcionales incluían los relacionados con seguridad, mantenibilidad, confiabilidad, cumplimiento, escalabilidad, accesibilidad, extensibilidad, rendimiento, usabilidad, etc.

Los cuantifica explícitamente en todos los proyectos no triviales, ¿no?