Propósito
Las revisiones del arquitecto protegen la calidad de ingeniería sin convertir al arquitecto en autor de cada decisión de implementación. La revisión identifica problemas importantes de estructura, seguridad, integración, mantenibilidad y cumplimiento del uso de recursos empresariales aprobados.
Rol responsable: Arquitecto / Ingeniero sénior.
Participantes: Product Engineer; otros especialistas cuando lo requieran el riesgo o la política.
Entradas: Cambios implementados, instrucciones permanentes aplicables, decisiones arquitectónicas, especificaciones relacionadas, pruebas habituales, problemas conocidos; resultados de verificación independiente para la revisión final.
Resultados: Hallazgos con gravedad y tratamiento, correcciones acordadas y aprobación técnica cuando sea necesaria.
Las dos revisiones de implementación del ciclo inicial
El trabajo de fundamentos técnicos de la etapa 2 prepara el entorno aprobado y la orientación arquitectónica. El Ciclo 1 incluye dos revisiones planificadas de software implementado, en las etapas 4 y 7; la preparación no añade una revisión obligatoria separada.
Revisión inicial, etapa 4 del Ciclo 1. Evalúe la primera implementación sustancial antes de que el equipo invierta más en iteraciones dirigidas por el cliente. Esta revisión se centra en si los fundamentos arquitectónicos, las decisiones de reutilización, el enfoque de integración, los límites de seguridad y la mantenibilidad son sólidos. Los hallazgos importantes se corrigen antes de una revisión sustancial de las partes interesadas.
Revisión final, etapa 7 del Ciclo 1. Evalúe la implementación después de los cambios de las partes interesadas y las pruebas basadas en especificaciones. Confirme que los hallazgos anteriores siguen resueltos; examine los riesgos nuevos introducidos durante la iteración; considere los fallos o las limitaciones de verificación; y establezca la preparación técnica para las UAT según la política empresarial.
Procedimiento de revisión
1. Comprender qué cambió y por qué. Lea las especificaciones pertinentes y el contexto del cambio. Revisar únicamente el código fuente sin conocer el comportamiento previsto puede hacer que se pase por alto el fallo más importante.
2. Examinar el encaje arquitectónico. Confirme que las responsabilidades están adecuadamente separadas, se utilizan plataformas y recursos aprobados, las dependencias están justificadas, los límites de integración siguen siendo comprensibles y el Product Engineer puede mantener el código a lo largo del tiempo.
3. Examinar los problemas importantes de seguridad y protección. Considere los límites de autorización, la exposición de secretos, el acceso a datos, las integraciones externas, el tratamiento de entradas y otros riesgos específicos de la aplicación. Coordine revisiones especializadas cuando la política empresarial las exija.
4. Revisar las pruebas y las limitaciones conocidas. Busque una cobertura automatizada creíble y comportamiento observable, y revise las evidencias de verificación independiente durante la aprobación final. Un comando de pruebas satisfactorio es una evidencia, pero no una prueba de corrección o idoneidad.
5. Registrar hallazgos accionables. Explique cada problema significativo, su consecuencia, la corrección o decisión esperada y su responsable. Distinga los hallazgos que bloquean el avance de las mejoras que razonablemente pueden abordarse después.
6. Verificar la corrección y concluir. El Product Engineer dirige los cambios necesarios y proporciona evidencias de su resolución. El arquitecto confirma el tratamiento y toma la decisión técnica requerida.
Revisiones del ciclo de mejora
Las revisiones del arquitecto en el Ciclo 2 se realizan cuando las exigen el riesgo y la política empresarial. Los criterios pertinentes pueden incluir cambios en permisos, integraciones, flujos de datos, bibliotecas compartidas o arquitectura. Un cambio habitual que utiliza patrones aprobados existentes no debe someterse automáticamente al mismo proceso que un nuevo límite de seguridad.
Criterios de finalización
Se ha realizado la revisión requerida; los hallazgos importantes tienen un tratamiento explícito; los problemas que bloquean el avance están resueltos o escalados conforme a la política aplicable; y la decisión técnica se registra por separado de la aceptación empresarial en las UAT.
Problemas habituales que conviene evitar
Reducir la revisión a preferencias de estilo; descubrir problemas arquitectónicos solo después de extensas iteraciones con el cliente; tratar cada cambio habitual como un proyecto formal de arquitectura; y presentar la aprobación técnica como prueba de que el producto resuelve el problema empresarial.