Lista de comprobación: Documento de arquitectura de software
Esta lista de comprobación le ayuda a garantizar que el documento de arquitectura de software es estable, correcto y completo.
Relaciones
Elementos relacionados
Descripción principal

 

Elementos de comprobación
General

En general, el sistema está basado en una sólida arquitectura, porque:

  • La arquitectura parece estable.

    La necesidad de estabilidad viene dictada por la naturaleza de la fase de construcción: en la construcción, el proyecto suele crecer y añade desarrolladores que trabajan en paralelo y tienen una comunicación poco regulada con otros desarrolladores a medida que van avanzando en el producto. Es tan sencillo como que el grado de independencia y paralelismo que se necesita en la construcción no se puede alcanzar si la arquitectura no fuera estable.

    La importancia de una arquitectura estable nunca es excesiva. No caiga fácilmente en la idea de que 'bastante bien ya está bien', si es inestable es inestable, y es preferible hacer un buen trabajo con la arquitectura y retrasar el inicio de la construcción que continuar en caso contrario. Los problemas de coordinación que entraña el intentar reparar la arquitectura mientras los desarrolladores intentan construir sobre sus cimientos eliminarán fácilmente cualquier ventaja aparente derivada de la aceleración de la planificación. Los cambios de arquitectura durante la construcción tienen un gran impacto: tienden a ser costosos, destructivos y desmoralizantes.

    La verdadera dificultad a la hora de valorar la estabilidad arquitectónica es que "uno no sabe lo que no sabe"; la estabilidad se mide respecto al cambio previsto. En consecuencia, la estabilidad es esencialmente una medida subjetiva. Sin embargo, podemos basar esta subjetividad en algo más que conjeturas. La propia arquitectura se desarrolla mediante la consideración de casos de ejemplo que son 'arquitectónicamente significativos': subconjuntos de casos de uso que representan el comportamiento que supone el mayor reto tecnológico que debe soportar el sistema. Valorar la estabilidad de la arquitectura implica garantizar que la arquitectura tiene una cobertura amplia, para garantizar que no habrá 'sorpresas' en el avance de la arquitectura.

    Experiencias pasadas con la arquitectura también pueden ser un buen indicador: si el índice de cambio en la arquitectura es bajo, y continúa bajo a medida que se van cubriendo nuevos casos de ejemplo, hay buenas razones para creer que la arquitectura se está estabilizando. Por el contrario, si cada nuevo caso de ejemplo provoca cambios en la arquitectura, significa que sigue evolucionando y que todavía no se garantiza su línea base.

  • La complejidad del sistema coincide con la funcionalidad que proporciona.
  • La complejidad conceptual es adecuada si se considera las habilidades y la experiencia de sus:
    • usuarios
    • operadores
    • desarrolladores
  • El sistema tiene una única arquitectura y ésta es coherente
  • El número y el tipo de los componentes es razonable
  • El sistema tiene un recurso de seguridad para todo el sistema. Todos los componentes de seguridad funcionan como conjunto para salvaguardar el sistema.
  • El sistema cumple con sus objetivos de disponibilidad.
  • La arquitectura permite al sistema recuperarse en caso de anomalía en el periodo de tiempo requerido.
  • ¿Tienen los productos y técnicas en los que se basa el sistema una vida que coincide con la prevista?
    • Un sistema temporal (táctico) con una vida corta puede construirse sin problemas utilizando tecnología antigua porque se desechará pronto.
    • Un sistema con expectativas de vida duraderas (la mayoría) debe construirse con tecnología y métodos actualizados de forma que puede mantenerse y ampliarse para dar soporte a requisitos futuros.
  • La arquitectura define interfaces clara para habilitar la partición para un desarrollo de equipo paralelo.
  • El diseñador de un elemento de modelo puede comprender lo bastante a partir de la arquitectura como para diseñar y desarrollar el elemento de modelo.
  • El enfoque de empaquetado reduce la complejidad y mejora la comprensión.
  • Los paquetes se han definido para que sean muy coherentes dentro del paquete, mientras que los propios paquetes están emparejados de forma poco estricta.
  • Se han considerado soluciones similares en el dominio de aplicación común.
  • La solución sugerida puede entenderla fácilmente una persona que tenga conocimientos generales sobre el dominio del problema.
  • Todos los miembros del equipo comparten el punto de vista sobre la arquitectura que ha presentado el arquitecto de software.
  • El documento de arquitectura de software está actualizado.
  • Las directrices de diseño se han seguido.
  • Todos los riesgos se han mitigado o bien se han tratado mediante un plan de contingencia. Los riesgos nuevos que se han descubierto se han documentado y analizado para averiguar su impacto potencial.
  • Los requisitos clave para el rendimiento (en presupuestos establecidos) se han satisfecho.
  • Los guiones de prueba, los aprovechamientos de prueba y las configuraciones de prueba se han identificado.
  • La arquitectura no parece tener un "exceso de diseño".
    • Los mecanismos que están ya colocados parecen lo bastante simples como para utilizarse.
    • El número de mecanismos es modesto y coherente con el ámbito del sistema y las demandas del dominio del problema.
  • La arquitectura puede ejecutar todas las realizaciones de casos de uso definidas para la iteración actual, como queda demostrado en los diagramas que ilustran:
    • interacciones entre objetos,
    • interacciones entre tareas y procesos,
    • interacción entre los nodos físicos.
Modelos

Consideraciones sobre el análisis arquitectónico

Generales
  • La partición y las capas de los paquetes y los subsistemas tienen una coherencia lógica.
  • Todos los mecanismos de análisis se han identificado y descrito.
Subsistemas
  • Los servicios (interfaces) de los subsistemas en las capas de nivel alto se han definido.
  • Las dependencias entre los subsistemas y los paquetes corresponden a las relaciones de dependencia entre las clases contenidas.
  • Las clases de un subsistema dan soporte a los servicios identificados para el subsistema.
Clases
  • Las clases de entidades clave y sus relaciones se han identificado.
  • Las relaciones entre las clases de entidades clave se han definido.
  • El nombre y la descripción de cada clase refleja con claridad el rol que desempeña.
  • La descripción de cada clase captura con precisión las responsabilidades de esa clase.
  • Las clases de entidad se han correlacionado con los mecanismos de análisis si corresponde.
  • Los nombres de rol de las agregaciones y asociaciones describen con precisión la relación entre las clases relacionadas.
  • Las multiplicidades de las relaciones son correctas.
  • Las clases de entidades clave y sus relaciones son coherentes con el modelo empresarial (si existe), el dominio (si existe), los requisitos y las entradas del glosario.

Consideraciones de modelos generales

  • El modelo se encuentra en un nivel adecuado de detalle dados los objetivos del modelo.
  • Para el modelo empresarial, los modelos de requisitos o el modelo de diseño durante la fase de elaboración, no hay problemas implementación o un exceso de énfasis.
  • Para el modelo de diseño en la fase de construcción, hay un buen equilibrio en la funcionalidad entre los elementos del modelo, utilizando una composición de elementos relativamente sencillos para construir un diseño más complejo.
  • El modelo demuestra cierta familiaridad y competencia con la totalidad de conceptos sobre modelado aplicables al dominio del problema; las técnicas de modelado se utilizan adecuadamente para el problema en cuestión.
  • Los conceptos se modelan de la forma más sencilla posible.
  • El modelo ha evolucionado fácilmente; los cambios previstos pueden adaptarse con facilidad.
  • Asimismo, el modelo no se ha estructurado en exceso para manejar cambios improbables, en favor de su sencillez y inteligibilidad.
  • Las suposiciones clave que están detrás del modelo se han documentado y los revisores del modelo pueden consultarlas. Si las suposiciones son aplicables a una iteración determinada, el modelo debe ser capaz de evolucionar dentro de esas suposiciones, aunque no necesariamente fuera de ellas. La documentación de las suposiciones es una forma de compensar a los diseñadores por no considerar "todos" los requisitos posibles. En un proceso iterativo, es imposible analizar todos los requisitos posibles y definir un modelo que manejará todos los requisitos futuros.
Diagramas
  • La finalidad del diagrama está claramente expresada y es de fácil comprensión.
  • El diseño gráfico es limpio y transmite claramente la información prevista.
  • El diagrama transmite lo justo como para alcanzar su objetivo, pero no más.
  • La encapsulación se utiliza efectivamente para ocultar los detalles y mejorar la claridad.
  • La abstracción se utiliza efectivamente para ocultar los detalles y mejorar la claridad.
  • La colocación de los elementos de modelo transmite las relaciones de forma eficaz; los elementos similares o que estén emparejados se agrupan juntos.
  • Las relaciones entre los elementos de modelo son fáciles de comprender.
  • El etiquetado de los elementos de modelo contribuyen a su comprensión.
Documentación
  • Cada elemento de modelo tiene una finalidad diferenciada.
  • No hay elementos de modelo superfluos; cada uno desempeña un rol esencial en el sistema.
Recuperación de errores
  • Para cada error o excepción, una política define cómo se restaura el sistema a su estado "normal".
  • Para cada tipo posible de error de entrada por parte del usuario o de datos erróneos por parte de los sistemas externos, una política define cómo se restaura el sistema a su estado "normal".
  • Existe una política aplicada de forma coherente para el manejo de las situaciones excepcionales.
  • Existe una política aplicada de forma coherente para el manejo de los datos dañados en la base de datos.
  • Existe una política aplicada de forma coherente para el manejo de la no disponibilidad de la base de datos, incluido si los datos aún pueden entrarse en el sistema y almacenarse más tarde.
  • Si los datos se intercambian entre los sistemas, existe una política sobre cómo los sistemas sincronizan sus vistas de los datos.
  • Si el sistema utiliza procesadores o nodos redundantes para proporcionar tolerancia a errores o una gran disponibilidad, existe una estrategia para garantizar que no haya dos procesadores o nodos que puedan 'creer' que son el principal, o que no hay un procesador o nodo principal.
  • Los modos de fallo para un sistema distribuido se han identificado y se han definido estrategias para el manejo de las anomalías.
Transición e instalación
  • El proceso a seguir para la actualización de una sistema existente sin pérdida de datos o de capacidad operativa está definido y ha sido probado.
  • El proceso para la conversión de datos utilizados por los releases anteriores está definido y ha sido probado.
  • La cantidad de tiempo y de recursos necesarios para actualizar o instalar el producto se entiende bien y se ha documentado adecuadamente.
  • La funcionalidad del sistema puede activarse mediante casos de uso utilizados de uno en uno.
Administración
  • El espacio en disco puede reorganizarse o recuperarse mientras el sistema está ejecutándose.
  • Las responsabilidades y los procedimientos para la configuración del sistema se han identificado y documentado.
  • El acceso al sistema operativo o a las funciones de administración es restringido.
  • Se cumplen los requisitos de licencia.
  • Las rutinas de diagnóstico pueden ejecutarse mientras el sistema se está ejecutando.
  • El sistema supervisa el propio rendimiento operativo (por ejemplo, el umbral de capacidad, el umbral de rendimiento crítico o el agotamiento de los recursos).
    • Las acciones que deben emprenderse cuando se alcancen los umbrales se han definido.
    • La política de manejo de alarmas se ha definido.
    • El mecanismo de manejo de alarmas se ha definido y se ha realizado y probado un prototipo.
    • El mecanismo de manejo de alarmas puede 'ajustarse' para evitar alarmas falsas o redundantes.
  • Las políticas y procedimientos para la supervisión y la administración mediante la red (LAN, WAN) se han definido.
  • Los errores de la red pueden aislarse.
  • Existe un recurso de rastreo de sucesos que puede activarse para ayudar a solucionar problemas.
    • El coste total del recurso se entiende.
    • El personal de administración posee los conocimientos necesarios para el uso adecuado del recurso.
  • No es posible que un usuario malicioso pueda:
    • acceder al sistema
    • destruir datos críticos
    • consumir todos los recursos
Rendimiento
  • Los requisitos de rendimiento son razonables y son un reflejo de las restricciones reales del dominio del problema; su especificación no es arbitraria.
  • Los cálculos del rendimientos del sistema existen (modelados como sea preciso mediante un modelo de análisis de carga de trabajo) e indican que los requisitos de rendimiento no suponen riesgos significativos.
  • Los cálculo sobre el rendimiento del sistema se han validado utilizando prototipos arquitectónicos, especialmente para los requisitos en los que el rendimiento sea un factor crítico.
Utilización de la memoria
  • Los presupuestos de memoria para la aplicación se han definido.
  • Las acciones que deben detectar y evitar las fugas de memoria se han emprendido.
  • Existe una política de aplicación continuada que define cómo se utiliza, supervisa y ajusta el sistema de memoria virtual.
Coste y planificación
  • El número real de líneas de código desarrolladas hasta este punto concuerda con las previsiones de líneas de código en el objetivo actual.
  • Las suposiciones de cálculo se han revisado y siguen siendo válidas.
  • Los cálculos de coste y de planificación se han recalculado utilizando los valores reales de la experiencia en proyectos y del rendimiento para la productividad más recientes.
Portabilidad
  • Los requisitos de portabilidad se han alcanzado.
  • Las directrices de programación proporcionan una guía específica para la creación de código portable.
  • Las directrices de diseño proporcionan una guía específica para el diseño de aplicaciones portables.
  • Un 'puerto de prueba' se ha estipulado para verificar las solicitudes de portabilidad.
Fiabilidad
  • Las medidas de calidad (MTBF, el número de defectos pendientes, etc.) se han alcanzado.
  • La arquitectura proporciona la recuperación en caso de desastre o de anomalía del sistema
Seguridad
  • Los requisitos de seguridad se han alcanzado.
Cuestiones de organización
  • ¿Están los equipos bien estructurados? ¿Se han repartido adecuadamente las responsabilidades entre los equipos?
  • ¿Existen cuestiones políticas, organizativas o administrativas que restringen la eficacia de los equipos?
  • ¿Existen conflictos de personalidad?
La vista de caso de uso

La sección de la vista de caso de uso del documento de arquitectura de software:

  • cada caso de uso es significativo arquitectónicamente e identificado como tal porque:
    • es de vital importancia para el cliente
    • motiva los elementos clave en las otras vistas
    • es un controlador para mitigar uno o varios riesgos importantes, incluidos los requisitos complejos no funcionales.
  • no existen casos de uso cuyas preocupaciones arquitectónicas ya estén cubiertas por otro caso de uso
  • los aspectos arquitectónicamente significativos del caso de uso son claros y no se pierden en los detalles
  • el caso de uso es claro y es poco probable que cambie de forma que afecte a la arquitectura, o existe un plan preparado para alcanzar ese grado de claridad y de estabilidad
  • no falta ningún caso de uso arquitectónicamente significativo (puede precisar algún análisis de los casos de uso no seleccionados para esta vista).
La vista lógica

La sección de la vista lógica del documento de arquitectura de software:

  • presenta de forma precisa y completa una visión general de los elementos arquitectónicamente significativas del diseño.
  • presenta el conjunto completo de mecanismos de arquitectura utilizados en el diseño junto con los fundamentos utilizados en su selección.
  • presenta las capas del diseño, junto a los fundamentos utilizados para la partición de las capas.
  • presenta las infraestructuras o los patrones utilizados en el diseño, junto a los fundamentos utilizados para seleccionar los patrones o las infraestructuras.
  • El número de elementos de modelo arquitectónicamente significativos es proporcionado al tamaño y el ámbito del sistema, y tiene un tamaño que hace comprensibles los principales conceptos empleados en el sistema.
La vista de proceso
Utilización de recursos
  • Las condiciones de actualización potenciales (la condición de actualización para los recursos críticos) se han identificado y se han definido las estrategias de elusión y resolución.
  • Existe una estrategia definida para el manejo de las condiciones de "cola de E/S llena" o de "almacenamiento intermedio lleno".
  • El sistema se supervisa a sí mismo (el umbral de capacidad, el umbral de rendimiento crítico o el agotamiento de los recursos) y es capaz de emprender acciones correctivas cuando se detecta un problema.
Rendimiento
  • Los requisitos de tiempo de respuesta para cada mensaje se han identificado.
  • Existe un modo de diagnóstico para el sistema que permite medir los tiempos de respuesta de mensajes.
  • Los requisitos de rendimiento nominales y máximos para las operaciones importantes se han especificado.
  • Existe un conjunto de pruebas de rendimiento que pueden medir si los requisitos de rendimiento se han alcanzado.
  • Las pruebas de rendimiento cubren el comportamiento "extra-normal" del sistema (inicio y conclusión, flujos de sucesos alternativos y excepcionales de los casos de uso , modos de anomalía del sistema).
  • Debilidades arquitectónicas que pueden suponer cuellos de botella potenciales para el rendimiento se han identificado. Se ha concedido un énfasis concreto a los aspectos siguientes:
    • utilización de algún recurso compartido finito como (aunque no exclusivamente) los semáforos, los manejadores de archivo, los bloqueos, la memoria compartida, etc.
    • comunicación entre procesos. La comunicación entre límites de proceso es siempre más costosa que la comunicación dentro de un proceso.
    • comunicación entre procesadores. La comunicación entre límites de proceso es siempre más costosa que la comunicación entre procesos.
    • uso físico y virtual de la memoria; el punto en el que el sistema agota la memoria física y empieza a utilizar la memoria virtual es un punto en el que el rendimiento decae de forma muy notable.
Tolerancia a errores
  • Donde existen procesos principales y de reserva, la posibilidad de que un proceso pueda creer que es el principal (o de que ningún proceso crea que es el principal) se ha considerado y se han emprendido acciones de diseño específicas para resolver ese conflicto.
  • Existen varios procesos externos que restauran el sistema a un estado coherente cuando un suceso como una anomalía en el proceso deja el sistema en un estado incoherente.
  • Si el sistema es tolerante a errores y excepciones, cuando se produce un error o una excepción, el sistema es capaz de regresar a un estado coherente.
  • Las pruebas de diagnóstico puede ejecutarse mientras el sistema se está ejecutando.
  • El sistema puede actualizarse (hardware, software) mientras se está ejecutando, si es necesario.
  • Existe una política de manejo de alarmas en el sistema, y la política se ha aplicado de forma coherente. La política sobre alarmas trata:
    • la "sensibilidad" del mecanismo que informa de las alarmas;
    • la prevención de falsas alarmas o alarmas redundantes;
    • los requisitos de formación y de la interfaz de usuario del personal que va a utilizar el mecanismo que informa de las alarmas.
  • El rendimiento del mecanismo que informa de las alarmas se ha evaluado y actúa dentro de umbrales aceptables de rendimiento según se establece en los requisitos de rendimiento.
  • Los requisitos de carga de trabajo/rendimiento se han examinado y se han satisfecho. En caso de que los requisitos de rendimiento fueran poco realistas, se han renegociado.
  • Los presupuestos de memoria, en la medida en que existan, se han identificado y se ha verificado que el software cumple esos requisitos. Las medidas que deben detectar y evitar las fugas de memoria se ha tomado.
  • Existe una política para el uso del sistema de memoria virtual, incluido cómo supervisar y utilizar su uso.
Modularidad
  • Los procesos son suficientemente independientes entre sí, por lo que pueden distribuirse entre los procesadores o los nodos cuando sea necesario.
  • Los procesos que deben permanecer en ubicaciones próximas (por razones de requisitos de rendimiento y de producción, o el mecanismo de comunicación entre procesos (por ejemplo, los semáforos o la memoria compartida) se han identificado, y el impacto que supone no poder distribuir esta carga de trabajo se ha tenido en cuenta.
  • Los mensajes que pueden ser asíncronos, de forma que pueden procesarse cuando hay una mayor disponibilidad de recursos, se han identificado.
La vista de despliegue
  • Los requisitos de rendimiento se han satisfecho mediante la distribución de los procesos ente los nodos, y se han abordado los posibles cuellos de botella de rendimiento.
  • Cuando se distribuye la información y se replica potencialmente entre varios nodos, se garantiza la integridad de la información.
  • Los requisitos para un transporte fiable de mensajes, si existen, se han satisfecho.
  • Los requisitos para un transporte seguro de mensajes, si existen, se han satisfecho.
  • El proceso se ha distribuido entre los nodos de forma que el tráfico en la red y el tiempo de respuesta se ha minimizado, sujeto a la coherencia y a las restricciones de los recursos. 
  • Los requisitos de disponibilidad del sistema, si existen, se han satisfecho.
    • El máximo de tiempo de inactividad del sistema en caso de una anomalía en el servidor o en el sistema se ha determinado y se encuentra en límites aceptables según se define en los requisitos.
    • Los servidores redundantes y en espera se han definido de forma que no es posible designar más de un servidor como servidor "principal".
  • Todos los modos de anomalía potenciales se han documentado.
  • Los errores de la red pueden aislarse, diagnosticarse y resolverse.
  • La cantidad de "espacio útil" en la utilización de la CPU se ha identificado y el método de medición se ha definido
  • Existe una política establecida para las acciones que llevar a cabo cuando se excede el máximo de utilización de la CPU.