Cómo hacer un preproyecto Revisión de arquitectura

Question

Relativility es fácil de ver un error de arquitectura cuando termina el proyecto. X nos dio problemas de seguridad, o Y nos dio mucho trabajo extra. Estos están atrapados en las retrospectivas, pero sería bueno atraparlos antes.

Estamos planeando llevar a cabo revisiones de arquitectura antes de que comience la codificación.

Una forma es simplemente lograr que el arquitecto presente el proyecto y ver si podemos encontrar defectos en el diseño.

¿Alguien tiene un enfoque más estructurado, tal vez con una lista de verificación "¿Has pensado en" o "cómo vas a hacer"?

Estaba pensando en algo como:

• Seguridad
• registro
• de acceso a datos
• despliegue
• Actualización

Answer 1

artículos adicionales para añadir a su lista, en ningún orden en particular:

• Rendimiento - ya sea la latencia, ancho de banda, la escala o de otros factores relacionados con su entrega
• Compatibilidad - Ya tienen el registro, pero lo acerca de la plomería en otras medidas de diagnóstico (Java-JMX, Windows-WMI/Contadores de rendimiento o algo personalizado)
• Flexibilidad: dificultad para cambiar la arquitectura más tarde (esta suele ser una de esas cosas que se hace demasiado y causa más problemas de los necesarios , pero la discusión debería estar presente cuando se evalúe ting a design)
• modelo de enhebrado/modelo de enclavamiento: ¿está claro cómo se protegerán los datos? ¿Cómo se manejará la contención de recursos?
• Requisitos de recursos: consumo de memoria en varios niveles de uso.¿Encaja en tus limitaciones?
• Manejo de errores: cuando algo en el producto falla, ¿la arquitectura admite un manejo limpio y la notificación de problemas?
• Comprensible: las arquitecturas demasiado complicadas tienden a olvidarse durante la implementación. Si la mayoría del equipo, y en particular los clientes potenciales, no pueden mantener la arquitectura, sus filosofías y reglas, en su opinión, la arquitectura no tendrá importancia.
• Consistencia. ¿Intenta utilizar todos los patrones posibles o centrarse en patrones regulares y repetidos? No es que escoger el patrón correcto para cada problema no sea una buena cosa, pero tener muchos patrones puede afectar la comprensibilidad y conducir a errores de implementación. Un arquitecto debe tratar de demostrar todo lo que sabe (o lo más reciente) en cada proyecto.
• Disponible - El diseño ayuda o daña los esfuerzos de prueba (sistema e integración). ¿Se pueden automatizar las pruebas o dependerá de un ejército de probadores para repetir continuamente las pruebas de regresión para que sepa que su equipo no ha roto el producto?
• ¿La arquitectura realmente resuelve el problema que está tratando de resolver y dentro del alcance del problema? No cree un rascacielos cuando el dúplex sea suficiente.

Answer 2

Debe utilizar patrones bien conocidos y tal vez incluso marcos de arquitectura para reducir los "y si".

Es relativamente fácil ver errores de arquitectura cuando finaliza el proyecto, pero eso radica en la naturaleza de lo que estamos haciendo.

Creo que es una buena práctica hacer continuamente revisiones de arquitectura. No es un paso que simplemente 'completas'.

Answer 3

Para proyectos importantes, una cosa que hacemos es un documento de opciones de solución. Haces una tormenta de ideas, reúnes información existente, hablas con las pymes, hablas con quien sea que lo requiera y creas una tabla para varias opciones con pros, contras, costos aproximados y estimaciones. Sí, este ejercicio es una carga general, pero muchos de los problemas que usted describe se conocerán si hace esto.

Al final, se recomienda una solución a la administración con motivos y posiblemente un diagrama de arquitectura de alto nivel para visualizar la solución.

Answer 4

Obviamente hay una gran cantidad de libros sobre el tema (por ej., 97 cosas que un arquitecto debería saber). Puede encontrar una lista completa de axiomas here y le sugiero que elija los que tengan sentido para sus proyectos en su lista de verificación.

Answer 5

El cambio es constante, asegúrese de que su arquitectura sea adaptable.
La interfaz de usuario es lo que mejora la experiencia de los usuarios.
Comparta su conocimiento sobre la arquitectura con todos completamente.
Pruebe antes de implementar.
No use patrones de diseño en exceso.