Software a medida

El desarrollo de software a medida empieza por el trabajo, no por una lista de funcionalidades. Observamos quién actúa, qué inicia el proceso, qué información necesita, dónde se toma una decisión, qué cambia de estado, quién resuelve una excepción y cómo se reconoce que la tarea ha terminado. Un mismo problema puede desaparecer al eliminar un paso, corregir los datos, configurar una plataforma o conectar bien dos sistemas. Escribir código es una opción; no debe ser la respuesta automática.

La decisión entre comprar y construir compara productos disponibles, condiciones de licencia y salida, capacidad de configuración, acceso a integraciones, seguridad, accesibilidad, portabilidad de los datos, dependencia del proveedor y coste total de operación. Comprar suele ser sensato cuando el proceso es común. Ampliar puede conservar una plataforma útil y resolver un recorrido concreto. El desarrollo propio merece su carga de mantenimiento cuando un flujo probado, un modelo de dominio, una frontera de integración o una experiencia de producto no caben de forma limpia en las alternativas disponibles.

El límite escrito nombra usuarios, funciones, recorridos, prestaciones, datos, informes, integraciones, entornos, dispositivos, idiomas, objetivo de accesibilidad, migración, formación, aceptación, publicación, propiedad intelectual y responsable después del lanzamiento. También separa descubrimiento, prototipo, producto mínimo viable, versión de producción y operación continua. Un MVP es el producto coherente más pequeño que permite comprobar un riesgo definido; no es la ambición completa a precio reducido ni una excusa para omitir controles esenciales de seguridad y recuperación.

No prometemos adopción, ingresos, ahorro, compatibilidad, seguridad, disponibilidad ni una fecha cerrada antes de verificar alcance y dependencias. Sí podemos aceptar comportamientos observables: un usuario concreto completa una tarea, la regla correcta cambia el estado previsto, los datos cuadran, una acción no autorizada se rechaza y el equipo de operación detecta y recupera un fallo acordado. El efecto empresarial se mide después del lanzamiento frente a una línea de base documentada; no se atribuye por defecto a la mera existencia de una aplicación.

Un sistema mantenible habla el idioma real de la organización. Con las personas responsables definimos actores, registros, eventos, reglas, estados e invariantes. Separamos términos parecidos cuando implican obligaciones distintas: un lead, un cliente, una cuenta, un contrato y un usuario no son equivalentes. Cada transición de estado indica quién puede autorizarla y qué rastro deja. Ese modelo de dominio se convierte en referencia compartida para la interfaz, los datos, las API, las pruebas, los informes y las decisiones operativas.

Para cada campo relevante identificamos la fuente maestra, el propietario, la sensibilidad, la vigencia, la validación, quién puede editarlo, cuánto se conserva y cómo se resuelve un conflicto. Los valores derivados conservan una fórmula y una hora de origen trazables. Importaciones y migraciones incluyen correspondencia, transformación, registros rechazados, conciliación y vía de retorno. Que un archivo se cargue sin error no demuestra que los datos sean correctos. Tampoco copiamos información de producción a desarrollo sin un plan autorizado y proporcional de protección.

La arquitectura nace de restricciones comprobadas: límites transaccionales, carga esperada, latencia, trabajo sin conexión, condiciones geográficas o contractuales, objetivos de recuperación, capacidad del equipo, modelo de despliegue y coste del cambio. Una aplicación modular puede ser más segura y gobernable que unos microservicios prematuros. En ciertos componentes, un servicio gestionado es más responsable que fabricarlo todo. Dejamos constancia de la opción elegida y de las descartadas para que un equipo futuro sepa qué cambio de contexto justificaría revisar la decisión.

Cada integración es un contrato. Una API, webhook, cola o intercambio de ficheros debe especificar sentido, identidad, versión, esquema, validación, autorización, idempotencia, límites, demora prevista, reintentos, orden, tratamiento del error, observabilidad y propietario. OpenAPI ayuda a describir una interfaz HTTP, pero no resuelve por sí sola el significado de negocio ni el compromiso de fiabilidad. El comportamiento de proveedor y consumidor se prueba en la frontera, incluidos el fallo parcial, la entrega duplicada, los datos atrasados y una dependencia no disponible.

El plan de entrega ordena el trabajo por riesgo y resultado útil. Un corte vertical une interfaz, regla, datos e integración en un recorrido real, de modo que las hipótesis débiles aparezcan antes que en pilas separadas de pantallas y tareas de servidor. El backlog conserva propósito, aceptación, dependencias y decisiones pendientes. Un prototipo responde preguntas de interacción y una exploración técnica reduce incertidumbre; ninguno se presenta como software listo para producción. Las demostraciones incluyen permisos, errores y recuperación, no solo el camino ideal.

El código fuente vive en el repositorio acordado con revisión, cambios trazables y reglas de publicación protegidas. La combinación de pruebas responde al riesgo del producto: unitarias y de componentes para reglas, de contrato para interfaces, de integración para fronteras, de extremo a extremo para recorridos críticos, y de migración o rendimiento cuando proceda. Una prueba superada aporta evidencia sobre la versión y el entorno examinados; no demuestra que no exista ningún defecto o vulnerabilidad.

La ruta de compilación y publicación separa el código de la configuración de cada entorno. Los secretos no se guardan en el repositorio; se definen permisos, rotación y acceso de emergencia. Las dependencias se eligen de forma deliberada, se fijan o limitan según convenga, se analizan y se actualizan por un cauce controlado. Quedan documentadas las diferencias entre desarrollo, pruebas, preproducción y producción. La integración y el despliegue continuos reducen variación manual solo si también están claros la aprobación, el origen del artefacto, la protección del entorno y la reversión.

Los cambios se mantienen lo bastante pequeños como para revisarlos y recuperarlos. La evolución de una base de datos contempla versiones antiguas y nuevas de la aplicación, relleno de datos, validación y límites de reversión. Se usan controles de funcionalidad, exposición gradual o convivencia cuando reducen un riesgo concreto. El rendimiento parte de recorridos representativos e indicadores de servicio, no únicamente de puntuaciones sintéticas. Decisiones, excepciones, deuda conocida y riesgo residual siguen visibles en la aceptación.

Los requisitos de seguridad se derivan de usuarios, datos, acciones, límites de confianza y formas plausibles de abuso. El modelo de amenazas recorre identidad, autorización, entradas, lógica de negocio, almacenamiento, comunicaciones, administración, dependencias y recuperación. El Secure Software Development Framework de NIST ofrece una estructura común para incorporar prácticas seguras a distintos ciclos de desarrollo. Indicamos qué prácticas y evidencias se aplican; citar el marco no equivale a certificar de forma independiente todas sus tareas o resultados.

En aplicaciones web, una versión, nivel y alcance acordados de OWASP ASVS pueden convertir la palabra seguridad en requisitos comprobables. Vinculamos los controles aplicables con diseño, implementación y pruebas; registramos qué se examinó, qué hallazgos relevantes se corrigieron, qué quedó fuera y cuál es el riesgo residual. La prueba de penetración independiente, certificación, evaluación regulatoria, vigilancia continua y respuesta a incidentes son trabajos separados si la propuesta no los incluye expresamente. No calificamos ningún sistema como absolutamente seguro.

Privacidad, accesibilidad y uso internacional forman parte del producto. Minimización, conservación, borrado, auditoría, datos de prueba, analítica y acceso de soporte se deciden con el cliente responsable y sus asesores. El objetivo WCAG 2.2 acordado se refleja en estructura, teclado, foco, errores, estados, contraste, reflujo, autenticación y tareas representativas; un escáner automático cubre solo una parte. Cada idioma se prueba como interfaz real, incluido el diseño de derecha a izquierda, fechas, nombres, números y contenido bidireccional.

La fiabilidad se define con indicadores vinculados a la experiencia del usuario. Disponibilidad, latencia, procesamiento correcto, vigencia del dato, edad de una cola o recuperación pueden tener distinto peso según el recorrido. Un SLI mide un aspecto observado; un SLO fija un objetivo interno; un SLA establece un compromiso contractual y sus consecuencias. No son intercambiables. Modos de fallo, cobertura de monitorización, copia, restauración, capacidad y límites de dependencias acompañan al objetivo.

La aceptación utiliza funciones, datos y entornos representativos. Según el producto, cubre el recorrido previsto, entrada no válida, acción denegada, solicitud duplicada, integración caída, tarea retrasada, migración parcial, uso móvil y con teclado, localización, degradación y recuperación. La evidencia enlaza el requisito con el artefacto probado y el resultado. La lista de defectos distingue bloqueos de publicación, limitaciones aceptadas y mejoras posteriores. Una demostración es útil, pero no sustituye la aceptación escrita.

El plan de lanzamiento nombra artefacto, entorno, configuración, secretos, movimiento de datos, cambios de dominio y certificados, comunicación, ventana de mantenimiento, autoridad de decisión y reversión. Ensayamos los pasos capaces de dañar datos o interrumpir tareas importantes. Se concilian totales de migración y se observan trabajos en segundo plano e integraciones. El límite de reversión es explícito: una acción enviada a un tercero o un cambio irreversible puede exigir compensación funcional, no un simple rollback técnico.

La entrega comprende acceso al repositorio y las fuentes, términos de propiedad intelectual, registros de arquitectura y decisiones, modelo de dominio, diccionario de datos, contratos de interfaz, inventario de entornos y dependencias, ruta de compilación y publicación, pruebas, riesgos conocidos, manuales operativos y procedimientos de administración. La propiedad se rige por la propuesta firmada; los derechos de código abierto y terceros conservan sus licencias. Una carpeta de fuentes sin compilación reproducible, titularidad de cuentas ni contexto de operación no es una transferencia completa.

La operación continua es una responsabilidad escrita aparte. Puede incluir monitorización, gestión de incidentes y problemas, mantenimiento de dependencias, respuesta a vulnerabilidades, copias, pruebas de restauración, capacidad, revisión de costes y una bolsa de cambios definida. Horario, canales, expectativas de respuesta, escalado y exclusiones quedan claros. El encargo de desarrollo no implica por sí solo cobertura 24/7, respuesta fija, compromiso de disponibilidad, cambios ilimitados ni soporte indefinido.

Las funciones de IA reciben un límite propio. Definimos modelo y fuentes de conocimiento, recorrido de datos, permisos, casos de evaluación, autoridad humana, rechazo y alternativa, registros, coste y control de cambios. Un modelo puede ayudar a buscar, clasificar, extraer o preparar un borrador; no se convierte en fuente maestra invisible ni adopta por defecto una decisión irreversible y de gran impacto. Precisión, disponibilidad y conducta del proveedor se miden en el contexto acordado, sin promesas universales.