Desarrollo de software
Respuesta corta. Un desarrollo va de problema a mantenimiento pasando por análisis, diseño de solución, construcción, validación y puesta en producción. Lo que define el proceso no son las fases —son las mismas en todas partes— sino dos reglas: no se desarrolla antes de haber entendido, y no se pone en producción antes de que lo haya usado alguien real.
El ciclo, de principio a fin
Problema
↓
Análisis
↓
Diseño de solución
↓
Desarrollo
↓
Validación
↓
Puesta en producción
↓
Mantenimiento
1. Problema
El punto de partida no es una especificación, es un problema: horas que se van en algo, datos que no cuadran, algo que no se puede hacer hoy y hace falta poder hacer.
Lo que se busca aquí es el problema, no la solución que ya traes pensada. Es habitual llegar con una solución en la cabeza —«necesito una app que…»— y que el análisis descubra que el problema real era otro. Vale la pena dejar espacio a eso.
2. Análisis
Entender la operación: cómo funciona hoy, quién interviene, qué sistemas hay, qué restricciones existen y cuáles son negociables. Aquí se decide también qué no entra en el proyecto, que suele ser más importante que lo que entra.
De esta fase sale lo necesario para poder presupuestar con sentido. Si no se llega ahí, no se pasa a la siguiente.
→ Optimización de procesos cuando el análisis tiene entidad propia.
3. Diseño de solución
Qué se construye exactamente, cómo encaja con lo que ya hay, en qué orden se entrega y qué coste tiene. Se entrega como propuesta, con hoja de ruta, plazos y presupuesto cerrado.
El alcance queda fijado aquí, por escrito, antes de escribir la primera línea de código. Si cambia después, se vuelve a acordar: lo que no ocurre es que se mueva solo.
4. Desarrollo
Construcción por partes, con entregas incrementales. Cada entrega es algo que se puede ver y probar, no un informe de avance.
Es lo que hace que las correcciones lleguen cuando todavía son baratas. Un malentendido detectado en la semana tres cuesta una conversación; el mismo malentendido detectado al final cuesta rehacer lo que se construyó encima.
5. Validación
Lo prueba quien lo va a usar, haciendo su trabajo real, antes de que sea definitivo. No es una demo: es usarlo.
De aquí salen siempre dos tipos de cosas: fallos, que se corrigen, y detalles de uso que nadie podía anticipar sin tener el sistema delante. Los segundos son el motivo de que esta fase exista.
6. Puesta en producción
El sistema entra en funcionamiento real. Lo que se resuelve en esta fase:
- La migración de los datos que ya existen, que casi nunca es trivial y casi siempre se subestima.
- La convivencia con lo anterior, si hay que mantener los dos durante un tiempo.
- La formación del equipo, cuando el proyecto cambia la forma de trabajar de alguien. Un sistema que el equipo no sabe usar no está terminado.
- El plan de vuelta atrás, por si algo no sale como estaba previsto.
7. Mantenimiento
El software no se acaba: se mantiene. Los proyectos salen con un año de garantía y 3 meses de soporte incluido, y existe la opción de un plan de mantenimiento mensual.
Qué esperar en plazos
| Proyecto estándar | 4-8 semanas |
| Proyecto complejo | 3-6 meses |
| Primera entrega visible | Semanas, no meses |
| Cronograma detallado | En la propuesta, después del análisis |
Un plazo dado antes del análisis es una cifra inventada. Por eso el cronograma llega con la propuesta y no en la primera conversación.
Qué se entrega
- El sistema funcionando en producción.
- Documentación técnica de lo construido.
- Formación, cuando el proyecto lo requiere.
- Las condiciones de propiedad y licencia, fijadas por escrito en la propuesta.
Lo que no es evidente
El coste de un sistema no termina cuando se entrega. Un sistema propio es un activo, y los activos tienen coste de propiedad: mantenimiento, evolución, adaptación a cambios de fuera. Contarlo desde el principio evita la sorpresa del año dos.
La parte más difícil casi nunca es la técnica. Suele ser acotar el alcance, decidir qué queda fuera y conseguir que el equipo lo adopte. Un proyecto se tuerce mucho más a menudo por eso que por un problema de programación.
Qué leer después
- Cómo trabajamos — el mismo proceso, desde el punto de vista del cliente.
- Software a medida — cuándo compensa construir.
- Mantenimiento y soporte — qué pasa después.
Fuente: documentación oficial de R3ZON (R3ZON CONSULTING SL). Actualizado el 2026-09-16. https://docs.r3zon.com/consultoria/desarrollo-de-software