Desarrollo e implementación

De la especificación a la integración: OTOKO® desarrolla aplicaciones y las conecta con sus sistemas y procesos existentes.

Ya sea una aplicación de negocio, un producto digital o una herramienta interna: desarrollamos software para procesos que no se pueden representar de forma razonable con los sistemas existentes.

Análisis de requisitos con el área de negocio, modelo de amenazas y arquitectura objetivo según el modelo C4 Modelo de dominio, modelo de datos y contratos de interfaz antes de la primera línea de código Desarrollo en iteraciones cortas con revisiones de código y aceptaciones por parte del área de negocio Desarrollo seguro según OWASP ASVS, dependencias verificadas y builds firmados Traspaso con código fuente, documentación de arquitectura y manual de operación

Aplicación operativa con código fuente y pipeline de build Documentación de arquitectura con modelo de amenazas Manual de operación con runbooks y plan de emergencia

Ejemplos de los flujos de trabajo actuales y sus excepciones Responsables de las decisiones de negocio Sistemas existentes, fuentes de datos y requisitos de operación

Hasta ahora, la planificación del mantenimiento se lleva en hojas de cálculo. Una aplicación de negocio reúne instalaciones, fechas, responsabilidades y aprobaciones. La primera fase abarca un emplazamiento; otros emplazamientos se incorporan solo después de una revisión del proceso por parte del área de negocio.

.NET C# Go Rust TypeScript PostgreSQL

Se empieza por el flujo de trabajo para el que debe merecer la pena la inversión. Modelamos conceptos, estados y reglas de negocio junto con las personas que después trabajarán con ellos. Una aprobación, por ejemplo, no es solo un botón: la sustitución del responsable, los permisos, los plazos y la posibilidad de revocar una decisión deben encajar entre sí. Estas reglas pasan a formar parte del modelo de datos y de las pruebas. La primera versión se concentra en un proceso completo y utilizable. Añadimos más funciones según la retroalimentación del uso real. Así se obtiene un producto con un beneficio verificable, y no una gran colección de pantallas inacabadas.

Para el backend, la interfaz de usuario y el almacenamiento de datos, elegimos tecnologías según su panorama de sistemas actual y la evolución prevista. Las competencias existentes, las interfaces y los requisitos de operación pesan más que una tendencia tecnológica pasajera. La oferta disponible incluye, entre otros, .NET, Go y TypeScript; los componentes cercanos al sistema se evalúan de forma independiente. Definimos los límites de los módulos y las responsabilidades de forma que los cambios sigan siendo trazables. Las credenciales de acceso no pertenecen al código fuente, ni las reglas de negocio exclusivamente a la interfaz de usuario. Las revisiones, las verificaciones automatizadas y los cambios versionados de la base de datos acompañan la implementación desde el principio.

Cada iteración muestra funciones utilizables con limitaciones conocidas. La aceptación de negocio y la aprobación técnica se consideran por separado: un pedido bien calculado puede ser correcto desde el punto de vista de negocio, mientras que el comportamiento bajo carga o el manejo de errores todavía no están listos para producción. Juntos determinamos qué evidencias son necesarias para cada fase de ampliación. El alcance de entrega acordado incluye el código fuente, builds reproducibles y documentación. Para el inicio en producción, aclaramos la migración de datos, la formación, las responsabilidades y el manejo de las incidencias. Los derechos de uso, los componentes de terceros y el mantenimiento posterior los regulamos antes del traspaso.

Una aplicación debe funcionar correctamente también cuando varias personas modifican al mismo tiempo el mismo inventario. Dos reservas no deben asignar el mismo último artículo sin que nadie lo advierta. Por eso determinamos qué cambios deben tener éxito conjuntamente y qué conflictos necesitan una respuesta de negocio. Las restricciones de la base de datos, las transacciones y las comprobaciones de versión pueden resolver distintas partes de esta tarea; la interfaz de usuario por sí sola no puede garantizar estas reglas. Los procesos de negocio más largos, en cambio, a menudo no caben en una única transacción. Un pedido, un servicio de pago externo y una aprobación de envío tienen sus propios estados de error. Modelamos el proceso con estados claramente definidos y transiciones permitidas. Las solicitudes repetidas reciben un identificador de operación adecuado, para que un corte de conexión no desencadene automáticamente una acción duplicada. Ante errores parciales se necesita una corrección definida a nivel de negocio, por ejemplo la revocación de una aprobación, en lugar de un reinicio técnico generalizado.

Para productos SaaS y plataformas internas, diferenciamos la identidad de un usuario de sus permisos sobre un conjunto de datos concreto. Un empleado que ha iniciado sesión no tiene automáticamente permiso para leer cualquier factura o cualquier pedido. Verificamos los accesos en el backend a nivel de organización, rol y proceso. También las exportaciones, los índices de búsqueda, las tareas en segundo plano y los resultados en caché deben respetar estos límites. Las tablas compartidas con un identificador de inquilino, los esquemas de base de datos separados o las bases de datos propias conllevan requisitos distintos de aislamiento, migración y recuperación. Elegimos el modelo según la separación necesaria y su organización de operación. Las pruebas con varios inquilinos verifican en particular los accesos no autorizados. Un registro de auditoría documenta los cambios relevantes para el negocio con el contexto adecuado; qué datos contiene y cuánto tiempo permanecen disponibles se define de forma expresa.

La estructura de datos sigue a las consultas y a las reglas de negocio. Analizamos los filtros, las ordenaciones, los análisis y las operaciones de escritura típicos antes de introducir tecnologías de almacenamiento adicionales. Las listas de resultados sin límite, las consultas individuales repetidas y las grandes transferencias de datos pueden frenar una aplicación, aunque el servidor parezca apenas cargado. Las mediciones con volúmenes de datos realistas muestran si los índices, los cambios en las consultas, la paginación u otro reparto de tareas ayudan. El caching es una decisión consciente sobre el grado de actualización de los datos: debe quedar establecido cuándo un resultado almacenado deja de ser válido y qué usuarios pueden verlo. Los cálculos extensos pueden ejecutarse como tareas en segundo plano, pero entonces necesitan indicador de progreso, reanudación y estados de error. Para las ampliaciones, separamos las reglas de negocio de los adaptadores técnicos. Las pruebas automatizadas y los cambios versionados de la base de datos protegen estos límites, de modo que un nuevo canal u otro proveedor no tenga que modificar cada módulo.

Panorama de aplicaciones, requisitos, riesgos Área de negocio, TI, seguridad de la información, arquitecto de software de OTOKO® Proyectos evaluados, inventario, requisitos de seguridad y de operación

Arquitectura, tecnología, modelo de operación Área de negocio, arquitectura, protección de datos, seguridad de la información Arquitectura objetivo, modelo de amenazas, estrategia de pruebas, modelo de operación, hitos