01 / El código es una parte del sistema, no el sistema completo
Una función puede estar correctamente programada y, aun así, resultar difícil de utilizar, comprobar, desplegar o modificar. En un proyecto real importa tanto lo que hace una pantalla como la regla que ejecuta, los datos que modifica, el entorno donde funciona y la persona que tendrá que cambiarla después.
Pensemos en una aplicación que calcula el presupuesto de una reparación. El cálculo puede devolver hoy el importe correcto. Pero ¿qué pasa si cambia una tarifa, si un trabajador no tiene permiso para aprobar un descuento o si hay que conservar el precio de reparaciones anteriores? El problema ya no se resuelve mirando una sola función. Hay que relacionar comportamiento, datos, responsabilidades, pruebas y entrega.
La ingeniería de software organiza esas decisiones a lo largo de la vida del sistema:
| Dimensión | Pregunta que debe responder |
|---|---|
| Comportamiento | ¿Qué tiene que ocurrir para el usuario y para el negocio? |
| Estructura | ¿Dónde reside cada responsabilidad y de qué depende? |
| Implementación | ¿Cómo construimos el cambio sin perder de vista su propósito? |
| Evidencia | ¿Cómo sabemos que conserva lo importante? |
| Entrega | ¿Cómo llega una versión al entorno donde se utilizará? |
| Operación | ¿Cómo detectamos y resolvemos lo que sucede después? |
| Evolución | ¿Cómo incorporamos nuevas reglas sin empezar de cero cada vez? |
Esta página muestra cómo conectamos esas dimensiones en dev2bit. Cada disciplina tiene su propia profundidad: aquí interesa entender la relación entre ellas y poder seguir hacia la explicación específica cuando sea necesaria.
02 / Más ingeniería no significa más herramientas ni más arquitectura
El proceso debe tener la profundidad que el proyecto necesita. Una pequeña herramienta interna, con pocos usuarios y una vida limitada, puede funcionar bien con una estructura sencilla y unas comprobaciones concretas. Un sistema que gestiona información crítica, integra varios proveedores y cambia cada semana necesita más evidencias, más control de entregas y mejores procedimientos de recuperación.
Antes de añadir capas, valoramos el impacto de un fallo, la frecuencia de cambio, el volumen de datos y usuarios, las integraciones, quién mantendrá la aplicación y cuánto tiempo se espera que siga activa. Esas condiciones importan más que el prestigio de una arquitectura con nombre.
La pregunta no es cuántos pipelines, servicios, tests o documentos tiene un proyecto. Es qué necesita para cumplir su función y evolucionar con un coste y un riesgo razonables.
Por eso tampoco imponemos una metodología universal. Podemos trabajar por fases, iteraciones o dentro del proceso de un cliente. Lo esencial es que una necesidad se convierta en una decisión comprensible, que el cambio pueda comprobarse y que otra persona tenga una vía razonable para continuarlo.
Del problema al software en funcionamiento
Una petición como «necesitamos gestionar reparaciones» todavía deja muchas preguntas abiertas. ¿Quién registra la incidencia? ¿Quién la asigna? ¿Puede cambiar de estado cualquier persona? ¿Qué ocurre si faltan piezas? ¿Quién ve el resultado? Aclarar el comportamiento precede a elegir tecnología.
Cuando esas respuestas existen, el trabajo puede organizarse. Se delimitan responsabilidades y datos, se construyen recorridos reconocibles, se comprueba el comportamiento que entraña más riesgo y se prepara una entrega que pueda repetirse. Tras publicar, la operación aporta información nueva: errores, uso real, dependencias que fallan o reglas que ya no sirven. Esa información vuelve a alimentar el siguiente cambio.
El recorrido es cíclico. No significa que cada encargo tenga que completar una lista rígida de etapas antes de mostrar un resultado. Significa que ninguna de esas decisiones debería quedar aislada del problema que intenta resolver.
03 / Antes de diseñar software, definimos qué comportamiento tiene valor
«Necesitamos gestionar reparaciones» puede significar cosas distintas para quien recibe el equipo, quien diagnostica la avería y quien autoriza el presupuesto. Si sólo anotamos esa frase, las decisiones pendientes acabarán apareciendo durante la programación, cuando ya condicionen pantallas y datos.
En este punto preguntamos quién participa, qué puede hacer cada persona, qué información necesita, por qué estados pasa una reparación y qué ocurre en las excepciones. Por ejemplo: ¿se puede modificar un presupuesto aceptado?, ¿debe conservarse la tarifa con la que se calculó?, ¿qué ve el cliente cuando falta una pieza? Responder no exige diseñar toda la aplicación de una vez. Permite que negocio y desarrollo hablen del mismo comportamiento.
La relación útil es necesidad → requisito → criterio de aceptación. «Avisar al cliente» expresa una necesidad; «enviar una notificación cuando se apruebe el presupuesto» delimita un comportamiento; acordar qué sucede si el envío falla permite comprobarlo. El criterio de aceptación describe el resultado esperado. Las pruebas que aportarán evidencia de ese resultado son una decisión posterior.
Nuestro servicio de análisis de requisitos de software desarrolla cómo convertimos usuarios, procesos, reglas y excepciones en una base de trabajo compartida. Aquí basta una idea: la ingeniería empieza antes del código.
04 / Organizamos responsabilidades antes de elegir tecnologías
Con el comportamiento más claro, decidimos dónde debe vivir cada responsabilidad y qué datos necesita. En el ejemplo de reparaciones, una pantalla puede mostrar el importe, pero la regla que lo calcula no debería depender de cómo se dibuja esa pantalla. Si más adelante hay una aplicación móvil o una integración con facturación, esa decisión afectará a la facilidad de reutilizar el cálculo.
La arquitectura relaciona funciones, datos y dependencias. Preguntamos qué cambia conjuntamente, qué partes necesitan comunicarse, qué pasa si una integración no responde y quién tendrá que operar el sistema. Algunas respuestas permiten una aplicación sencilla. Otras justifican separar componentes. Microservicios, una API independiente o una infraestructura determinada son posibles soluciones a restricciones concretas; no son el punto de partida.
Laravel, React, Docker o AWS son tecnologías. La arquitectura explica qué responsabilidades existen y cómo se relacionan. Dos sistemas con el mismo stack pueden estar organizados de maneras completamente distintas.
La página de arquitectura de software profundiza en escenarios, componentes, datos, alternativas y evolución. Este hub sólo establece el puente: los requisitos dicen qué debe ocurrir; la arquitectura decide cómo organizar el sistema para hacerlo posible.
05 / Construimos cambios que se puedan utilizar y comprobar
Una funcionalidad puede atravesar base de datos, servidor, interfaz e integración, pero para quien la necesita sigue siendo una sola tarea: registrar una reparación, asignarla o consultar su estado. Trabajar con cambios de propósito reconocible permite mostrar un recorrido real y descubrir antes si las decisiones anteriores sirven.
Esto no impone Scrum ni una cadencia universal de entregas. En un proyecto puede convenir completar primero un recorrido pequeño; en otro, resolver antes una integración incierta. Lo importante es poder relacionar el trabajo realizado con una necesidad y saber qué parte está preparada para comprobarse.
La construcción de soluciones específicas para empresas tiene su página comercial en programación y software a medida. Aquí explicamos cómo conectamos ese desarrollo con las decisiones previas y con la comprobación y entrega posteriores.
El código necesita historia
El repositorio conserva más que la última versión. Ayuda a saber qué cambió, por qué se modificaron varias piezas juntas, qué versión está en uso y dónde pudo introducirse una regresión. También proporciona un punto de partida para que otra persona continúe el trabajo.
Las condiciones de acceso, propiedad y entrega del repositorio se acuerdan según el proyecto. La continuidad no debería depender de una única copia local ni de decisiones que sólo conoce quien escribió el código.
06 / La mantenibilidad controla cuánto cuesta el siguiente cambio
En cuanto una aplicación empieza a utilizarse aparecen reglas nuevas, correcciones, otros usuarios, integraciones y cambios de proveedor. La estructura que facilitó la primera entrega puede dejar de ayudar cuando esas modificaciones se acumulan.
Volvamos al presupuesto de una reparación. Si la tarifa está duplicada en la pantalla, el correo de confirmación y la factura, cambiarla obliga a encontrar y coordinar tres lugares. Si existe una responsabilidad clara para calcularla y las otras partes consumen su resultado, el cambio tiene un límite más comprensible. No significa que sea trivial: hay que considerar datos anteriores y usos que quizá no estaban previstos. Significa que podemos localizar el impacto antes de tocar el código.
Mantenibilidad es precisamente esa capacidad de entender responsabilidades, dependencias, datos, configuración y contexto para modificar el sistema con un coste y un riesgo proporcionados. No promete código perfecto ni deuda técnica cero.
Una aplicación mantenible no es la que nunca necesita refactorización. Es la que permite reconocer cuándo una estructura empieza a encarecer los cambios y actuar con suficiente contexto.
La guía de calidad y mantenibilidad del software desarrolla los criterios para decidir qué reorganizar, qué deuda priorizar y qué información conservar para que el trabajo pueda continuar.
07 / Las pruebas aportan evidencia sobre lo que debe seguir funcionando
Probar no es sólo abrir una página y comprobar que carga. Si cambia la tarifa de una reparación, interesa saber si el importe se calcula correctamente, si se mantienen presupuestos ya aprobados y si los permisos impiden modificaciones indebidas. Esos comportamientos tienen riesgos distintos, por lo que tampoco necesitan exactamente la misma comprobación.
Elegimos qué proteger según el impacto de una regresión, la frecuencia con que cambia esa parte y el coste de repetir la prueba. A veces interesa una prueba pequeña sobre una regla; otras, un recorrido completo con datos e integraciones. No todo merece automatización y una cifra de cobertura, por sí sola, no demuestra que estén protegidos los comportamientos relevantes.
La secuencia es comportamiento → riesgo → tipo de prueba → evidencia. La guía de testing de software explica cómo tomamos esas decisiones y qué límites tiene cada nivel de comprobación.
Requisito, test y pipeline cumplen funciones diferentes
Un criterio de aceptación no es un test, y un test no es un pipeline. El pipeline tampoco decide por sí mismo qué comportamiento merece protección. Separar esas responsabilidades evita automatizar comprobaciones que no responden a ninguna pregunta importante.
08 / Un cambio correcto todavía necesita llegar bien al entorno
Entre terminar una modificación y que una persona la utilice pueden existir pasos decisivos: preparar dependencias, ejecutar comprobaciones, construir componentes, actualizar datos o configuración, publicar una versión y verificar que el servicio responde. Un fallo en esa secuencia puede inutilizar un cambio cuyo código era correcto.
La automatización hace repetibles los pasos que conviene ejecutar de forma consistente, especialmente cuando hay entregas frecuentes o varios entornos. No implica enviar cada cambio automáticamente a producción. Puede haber aprobación del cliente, ventanas de publicación o controles manuales por motivos de negocio o riesgo.
El flujo conceptual es código → comprobaciones → construcción → entorno → despliegue → validación. Sus pasos concretos dependen del proyecto. El servicio de automatización de despliegues y CI/CD explica cómo representamos el proceso real y cuándo merece la pena automatizarlo.
09 / El software sigue existiendo después de publicarlo
En producción aparecen hechos que ningún entorno de desarrollo anticipa completamente: carga real, errores poco frecuentes, datos que crecen, credenciales que caducan o servicios externos indisponibles. Por eso la ingeniería tiene que conectar el cambio de software con la infraestructura que lo ejecuta.
Una operación razonable permite ejecutar, observar, proteger, actualizar y recuperar el sistema. La amplitud depende de su importancia: la caída de una herramienta de prueba y la interrupción de una aplicación que sostiene ventas no tienen la misma consecuencia. El servicio de administración de sistemas sitúa esas decisiones respecto a aplicaciones, usuarios y datos.
Dentro de operación distinguimos cuatro preguntas que requieren intervenciones diferentes:
10 / Producción aporta información para la siguiente decisión
Un error repetido, una operación lenta, una función poco utilizada o una petición nueva pueden cambiar las prioridades iniciales. Esa información puede venir de usuarios, soporte, incidencias, métricas o mantenimiento; no exige implantar la misma telemetría en todos los proyectos.
Así se cierra el ciclo del mapa inicial: producción → observación → nueva evidencia → nueva decisión. A veces esa decisión modifica un requisito; otras obliga a revisar una dependencia, una comprobación o la capacidad del entorno. El objetivo no es perseguir cambios por sistema, sino saber qué hemos aprendido y qué conviene hacer con ello.
11 / Conservar decisiones ayuda a continuar
Meses después de una entrega, una regla puede parecer extraña. Tal vez responde a una excepción comercial; quizá una integración exige enviar los datos en un orden concreto. Sin ese contexto, alguien podría «simplificar» el código y recuperar un problema que ya se había resuelto.
No concentramos todo el conocimiento en un documento maestro. Según el proyecto, el motivo de una decisión puede estar en un requisito, una prueba, el historial del repositorio, un contrato de integración, una nota de arquitectura o un procedimiento de despliegue. Lo importante es poder recuperarlo cuando vuelva a necesitarse.
Un README correcto y unas pocas decisiones explicadas pueden ser más útiles que muchas páginas desactualizadas. Nos preguntamos: ¿qué necesitará saber la próxima persona para tomar o revisar esta decisión? Documentamos especialmente aquello que no podrá deducirse con seguridad del código.
Esto también afecta a la continuidad. Otro profesional siempre necesitará tiempo para conocer un sistema complejo, pero debería disponer de una vía razonable para encontrar código, entorno, accesos acordados, decisiones y forma de entrega. La mantenibilidad depende además de quién controla repositorios, infraestructura, dominios y servicios externos; esas condiciones deben quedar claras para el cliente.
12 / Un sistema existente puede empezar por otro punto del mapa
Cuando recibimos software ya construido no imponemos nuestra estructura preferida ni recomendamos reescribirlo por su edad. Primero averiguamos qué utiliza realmente la empresa, cómo se ejecuta, qué dependencias tiene, cómo se publica y dónde aparece el obstáculo para el siguiente cambio.
La auditoría de software, código y deuda técnica es una entrada alternativa cuando falta información, no una fase obligatoria de cada proyecto. Puede concluir que conviene conservar una parte, aislar una dependencia, actualizar otra o refactorizar una zona concreta. Después, la ingeniería organiza el cambio elegido.
La deuda técnica tampoco equivale automáticamente a un error. Una solución provisional puede ser una decisión consciente para llegar a una fecha. Se convierte en un problema cuando cada modificación posterior sigue pagando ese coste sin que nadie lo revise.
13 / El contexto determina cuánta estructura hace falta
Diseñar para cambiar no significa construir hoy todas las posibilidades futuras. Distinguimos un cambio ya solicitado de otro probable, para el que hay señales, y de uno meramente imaginado. Preparar una frontera para el segundo puede tener sentido; construir una plataforma entera para el tercero puede introducir más dificultad que la que evita.
Son orientaciones, no una fórmula: una herramienta pequeña puede tener una regla crítica que merece pruebas cuidadosas; una aplicación grande puede contener zonas estables donde no compensa añadir más mecanismos. El mismo criterio rige al elegir Laravel, React, Docker, AWS o cualquier otra tecnología: primero comportamiento, datos, integraciones, mantenimiento y operación; después, herramientas.
Principios como DRY, TDD o los microservicios ayudan cuando resuelven un problema concreto. Reducir duplicación puede evitar reglas divergentes, pero una abstracción prematura puede acoplar conceptos distintos. Separar servicios puede responder a límites reales, pero también añade despliegues, red y fallos parciales. No utilizamos una lista de prácticas como puntuación automática de calidad.
La seguridad atraviesa estas decisiones: permisos, exposición de componentes, secretos, dependencias y accesos de despliegue. Su profundidad depende del proyecto; la especialidad de seguridad de servidores desarrolla la parte operativa.
14 / Tres proyectos, tres dimensiones del mismo proceso
Los casos completos muestran decisiones que no se aprecian en una lista de herramientas:
- Renovatio: un ERP para relacionar expedientes, personas, documentos y gestión económica en reparaciones y siniestros. Ilustra cómo las reglas y los estados crecen con la operación, y por qué software y soporte deben poder evolucionar juntos.
- W2C: un editor visual conectado a un motor de reglas comerciales y al proceso de pedido. Muestra por qué interfaz, cálculo e integración necesitan responsabilidades distintas y comprobaciones sobre el presupuesto resultante.
- Arquitectura escalable en AWS: aplicaciones, contenedores, acceso web y datos forman una arquitectura operativa. Muestra cómo despliegue e infraestructura condicionan la continuidad del software.
Estos casos no representan una receta única. Cada uno pone a prueba una parte distinta del ciclo y conserva el detalle técnico en su ficha.
Profundiza en cada etapa
El esquema marca responsabilidades, no una secuencia que deba ejecutarse una única vez. Una regla descubierta durante el desarrollo puede devolvernos a requisitos y modificar la arquitectura. Testing y mantenibilidad acompañan continuamente a la construcción; la auditoría entra por otra vía cuando el estado de un sistema existente es incierto.
Preguntas habituales
¿Ingeniería de software y programación son lo mismo?
Programar convierte decisiones en código. La ingeniería incluye además definir el comportamiento, organizar el sistema, comprobarlo, entregarlo y sostenerlo en funcionamiento.
¿Todos los proyectos necesitan todas estas etapas?
No con la misma profundidad ni en el mismo orden. El alcance, el riesgo y la vida prevista determinan qué trabajo aporta valor.
¿Trabajáis siempre con Scrum o una metodología concreta?
No imponemos una metodología universal. Nos coordinamos con el proceso del cliente y conservamos suficiente relación entre necesidad, cambio y comprobación.
¿Utilizáis siempre la misma arquitectura?
No. Responsabilidades, datos, integraciones, carga, equipo y operación condicionan la estructura adecuada.
¿Un microservicio es más avanzado que un monolito?
No por sí mismo. Separar servicios sólo compensa cuando sus beneficios superan el coste de comunicación, despliegue y operación que introduce.
¿Todas las funciones necesitan tests automatizados?
No. Priorizamos comportamientos cuyo fallo y repetición de comprobaciones justifican una prueba automatizada; otras comprobaciones pueden ser manuales.
¿Qué diferencia hay entre testing y CI/CD?
Testing decide qué comprobar y cómo obtener evidencia. CI/CD organiza cuándo ejecutar controles y cómo integrar y entregar cambios.
¿Una aplicación mantenible carece de deuda técnica?
Puede tenerla. Lo importante es reconocer dónde encarece cambios o aumenta riesgos y decidir cuándo actuar.
¿Hay que documentarlo todo?
No. Conservamos sobre todo decisiones, configuraciones, integraciones y procedimientos que no pueden recuperarse con seguridad leyendo el código.
¿Recomendáis reescribir el software antiguo?
No por defecto. Antes estudiamos qué impide evolucionarlo y qué partes pueden conservarse.
¿Puede continuar otro equipo?
Buscamos que repositorio, entorno, accesos y contexto acordados permitan una continuidad razonable. Un equipo nuevo tendrá que aprender el sistema.
¿Cómo se relaciona esta página con el servicio de programación a medida?
Este hub explica cómo organizamos técnicamente el trabajo. Programación a medida explica qué soluciones podemos construir o ampliar para una empresa.
Francisco Javier Bohórquez Ogalla · Desarrollo de software y dirección técnica en dev2bit. Perfil profesional.