Diseño de sistemas a medida: qué definir antes de programar

El diseño comienza por el resultado que necesita el equipo

Diseñar un sistema a medida consiste en definir cómo personas, procesos, información y tecnología colaboran para producir un resultado. Antes de elegir un framework o una base de datos, conviene acordar qué problema se resuelve, quién lo usa, qué decisiones toma y cómo se sabrá que la solución funciona.

Esa definición evita que una lista inicial de funciones se convierta en un proyecto sin límites. También permite comparar una aplicación nueva con alternativas más simples, como ajustar un procedimiento, configurar una herramienta existente o automatizar solo una parte del flujo.

Esta guía propone un método práctico para preparar ese diseño. Los ejemplos son didácticos: no describen un cliente, una implementación ni resultados de Elaine System.

1. Escribe el problema y el resultado esperado

Empieza con una frase que conecte una situación actual con un resultado observable. Evita abrir el proyecto con una tecnología elegida de antemano. “Necesitamos una aplicación en React” describe una solución propuesta; “el equipo consolida solicitudes recibidas por distintos canales y no sabe cuánto tarda en responder” describe una condición que primero hay que entender.

Para formular el problema, documenta qué tarea inicia el proceso y quién la realiza; qué pasos, revisiones y aprobaciones ocurren hoy; qué errores, esperas o duplicaciones se quieren reducir; qué resultado concreto se espera y cómo podrá observarse; y qué queda fuera del primer alcance.

Registra una línea base si existe evidencia disponible, por ejemplo el número de pasos manuales o el tiempo entre recepción y respuesta. Si no hay medición, indícalo como pendiente y define cómo recogerla. No conviertas una estimación en un resultado garantizado.

2. Mapea usuarios, decisiones y excepciones

Dibuja el recorrido actual y el propuesto. Incluye a quien solicita, revisa, aprueba, administra y recibe el resultado. Para cada paso anota la entrada, la decisión, el responsable y la salida. El flujo también debe mostrar qué ocurre si falta información, una aprobación se rechaza o un sistema externo no responde.

Un proceso nominal suele ser sencillo; las excepciones revelan reglas que no deben quedar implícitas. Un ejemplo didáctico para una solicitud de servicio podría distinguir entre recibida, incompleta, en revisión, aprobada y cerrada. Cada transición necesita un actor autorizado y una condición verificable.

Valida el mapa con las personas que realizan el trabajo. Una entrevista breve con ejemplos reales suele detectar diferencias entre el procedimiento escrito y el flujo diario. No incluyas en una demo nombres, expedientes ni datos reales si no hacen falta para comprender el proceso.

3. Define datos y responsabilidades

Haz un inventario de la información que cada paso crea, consulta o modifica. Para cada dato identifica su propósito, quién lo proporciona, quién es responsable de mantenerlo correcto, qué sistemas lo reciben y cuándo deja de ser necesario.

• Fuente de verdad: decide cuál sistema mantiene el dato autoritativo cuando existen hojas, correos y aplicaciones duplicadas.
• Validación: establece formato, campos obligatorios, valores permitidos y reglas para corregir errores.
• Historial: determina qué cambios requieren una bitácora, quién los hizo y si se necesita motivo o marca de tiempo.
• Retención: acuerda cuánto tiempo se conserva cada categoría, cómo se elimina y qué excepción legal o contractual podría requerir conservarla.
• Minimización: evita recoger información personal, financiera o confidencial que no sea necesaria para el propósito.

Si el sistema procesa datos personales, alinea el modelo con el aviso de privacidad, los permisos y las obligaciones de cada rol. La política general del sitio está en el aviso de privacidad de Elaine System; cada proyecto de cliente puede necesitar su propio análisis, contrato y medidas.

4. Separa roles y permisos por tarea

Un rol útil refleja responsabilidades reales, no solo el nombre del puesto. Lista las acciones sobre cada tipo de información: consultar, crear, editar, aprobar, exportar y administrar. Después asigna cada acción a los grupos que realmente la necesitan y define quién puede cambiar esos permisos.

Considera por separado cuentas administrativas, soporte técnico y usuarios operativos. Usa cuentas individuales donde la trazabilidad sea necesaria; documenta el proceso para altas, cambios de puesto y bajas. El acceso de soporte debe tener un propósito y un periodo definidos. Las contraseñas, claves API y certificados no deben aparecer en el código, capturas o registros de actividad.

Convierte estas decisiones en una matriz sencilla antes de programar. Así el equipo puede revisar una pantalla y preguntar qué muestra, qué permite hacer y si esa acción queda registrada.

5. Dibuja el contexto y las piezas principales

Un diagrama de contexto muestra el sistema como una unidad, rodeado por sus usuarios y por las aplicaciones externas con las que intercambia información. Es una primera vista para negocio y tecnología: ayuda a acordar los límites y evita presentar una integración externa como si estuviera bajo control del equipo.

Cuando el contexto está claro, un diagrama de contenedores puede mostrar las aplicaciones y almacenes de datos que componen la solución, sus responsabilidades y las relaciones entre ellas. En el modelo C4, “contenedor” significa una aplicación o almacén de datos que debe ejecutarse; no significa necesariamente un contenedor Docker. No todas las propuestas necesitan llegar al nivel de componentes o código: usa solo el detalle que ayude a tomar una decisión. Si el diseño incluye infraestructura OpenStack, separa los requisitos de producción de lo que un laboratorio puede demostrar; esta guía sobre alcance de pruebas explica esa diferencia.

Elige tecnología después de conocer requisitos, capacidades del equipo, integraciones, alojamiento, costos operativos y restricciones del proveedor. Si el sistema depende de Linux, Kubernetes, OpenStack, un servicio administrado o una cuenta de tercero, registra qué equipo opera cada parte y qué ocurre cuando esa dependencia falla.

6. Convierte calidad y seguridad en requisitos comprobables

“Rápido”, “seguro” o “disponible” no son criterios suficientes para aprobar un sistema. Describe qué se medirá, en qué escenario y con qué límite aceptable. Entre los requisitos que suelen necesitar acuerdo están:

• Tiempo máximo para completar una operación representativa, con la carga esperada y el entorno de referencia.
• Qué parte del servicio debe recuperarse primero y cuánto dato puede perderse como máximo, si el negocio define objetivos RTO y RPO.
• Cómo se autentican usuarios, se protegen secretos, se revisan permisos y se registran acciones sensibles.
• Qué navegadores, dispositivos, navegación por teclado y tecnologías de apoyo deben funcionar para los recorridos prioritarios; el servicio de diseño web debe tener criterios propios de interfaz y accesibilidad.
• Qué mantenimiento, actualización, soporte y responsabilidades quedan a cargo del cliente o del proveedor.

La guía NIST SSDF recomienda integrar prácticas de desarrollo seguro al ciclo de vida del software. OWASP ASVS puede servir como catálogo para convertir controles de seguridad de aplicaciones en requisitos y verificaciones acordados. Estos marcos orientan el diseño; citarlos no demuestra que una aplicación los cumpla.

7. Define cómo se acepta cada entrega

Un criterio de aceptación expresa una condición observable para que negocio y desarrollo puedan revisar el mismo resultado. Por ejemplo: “Cuando una persona autorizada aprueba una solicitud completa, el sistema registra quién la aprobó, cuándo ocurrió y cuál fue el estado anterior”. La formulación es ilustrativa; cada proyecto necesita sus reglas y datos de prueba.

Para cada entrega, deja por escrito:

1. El escenario y el rol que se probará.
2. Los datos de prueba y el estado inicial del sistema.
3. La acción que debe completar la persona.
4. El resultado esperado y la evidencia que se conservará.
5. Los casos de error, permisos y recuperación incluidos en la revisión.

Aceptar una pantalla no equivale a validar respaldo, seguridad, rendimiento o recuperación. Separa los criterios funcionales de los operativos y acuerda quién autoriza cada uno.

Plantilla breve para iniciar el diseño

La primera propuesta puede ser pequeña. El objetivo del diseño inicial es reducir incertidumbre, ordenar prioridades y acordar un resultado que pueda revisarse; los detalles que dependan de pruebas deben quedar identificados como tales.

Qué debe quedar antes de empezar a construir

Antes de programar, el equipo debería poder explicar el problema, recorrer el proceso, identificar usuarios y permisos, reconocer los datos y sus responsables, mostrar límites e integraciones, y probar los criterios de aceptación. Con esa base, la tecnología se elige por ajuste al contexto y el alcance se puede estimar con supuestos visibles.

Elaine System ofrece diseño y desarrollo de sistemas a medida. Para revisar una necesidad, comparte el proceso que quieres ordenar, el equipo que lo usa y el resultado esperado. No incluyas accesos, contraseñas ni datos confidenciales en la consulta inicial.