ES
Menú
Referencia del framework

Aplicabilidad y límites

Dónde encaja en la práctica el marco SHAPE, qué abarca y dónde se necesita gobernanza adicional.

Dónde resulta útil el marco

El marco SHAPE resulta más directo cuando una organización puede definir un producto acotado, poner a disposición componentes técnicos aprobados y obtener comentarios significativos de las partes interesadas sobre el comportamiento en funcionamiento. Las herramientas empresariales internas, las aplicaciones de flujos de trabajo, las interfaces administrativas, las aplicaciones orientadas a la integración y las aplicaciones nuevas sobre plataformas empresariales establecidas son candidatas habituales para su evaluación.

También puede aplicarse a mejoras de productos existentes cuando se conocen suficientemente su arquitectura, sus dependencias y sus restricciones operativas. El software existente con comportamiento no documentado o los sistemas heredados fuertemente acoplados pueden necesitar más investigación antes de que un agente pueda modificarlos de forma segura.

Condiciones para un piloto eficaz

Un piloto razonable cuenta con una parte interesada del negocio comprometida, un Product Engineer con suficiente criterio empresarial y técnico, un arquitecto disponible, acceso a recursos empresariales aprobados y una forma clara de revisar y verificar el comportamiento. Debe tener límites identificables y resolver un problema significativo de tamaño moderado.

El piloto inicial debe poner a prueba el modelo operativo completo, incluidas las especificaciones, las revisiones, la verificación independiente y las UAT. Una demostración de que un agente generó una pantalla rápidamente no demuestra que el marco SHAPE funcione como proceso empresarial.

Cuándo se necesitan controles adicionales

Los sistemas críticos para la seguridad, los flujos financieros o médicos con consecuencias importantes, la infraestructura sensible de identidad o seguridad y los productos muy regulados pueden imponer requisitos adicionales a los definidos aquí. Pueden ser necesarios un modelado formal de amenazas, revisión especializada, trazabilidad, evidencias de validación, segregación de funciones o procedimientos regulatorios. En algunas circunstancias, un enfoque de implementación con agentes puede no ser apropiado.

El marco no exime de esos requisitos. Las empresas deciden si aplican controles complementarios o eligen otro enfoque de entrega.

Qué está incluido

El modelo de desarrollo SHAPE comienza con el descubrimiento y la recepción de requisitos. Incluye la especificación del producto, la preparación aprobada del proyecto, la implementación asistida por IA, la revisión técnica y de las partes interesadas, las pruebas independientes basadas en especificaciones y la preparación para las pruebas de aceptación de usuarios establecidas. Los cambios iterativos siguen el ciclo de mejora más breve una vez que existen los fundamentos del producto.

Qué queda fuera del ciclo de desarrollo definido

Los procesos de despliegue, las operaciones de infraestructura, la monitorización de producción, la gestión de servicios, la respuesta a incidentes y la gobernanza de publicaciones no están especificados por el proceso de desarrollo SHAPE. Las empresas conservan sus obligaciones y controles existentes. Esto no elimina la responsabilidad del producto: el Product Engineer sigue manteniéndolo y coordinando los cambios futuros después de su publicación.

Cómo evaluar el éxito

La evaluación debe considerar si el equipo entrega el comportamiento que las partes interesadas realmente necesitan; mantiene especificaciones y código comprensibles; reutiliza recursos empresariales; respeta permisos y estándares; detecta defectos mediante pruebas y revisiones; y mantiene una cartera de productos manejable. La velocidad y el coste de entrega pueden ser medidas útiles, pero ninguno basta por sí solo.