Cómo se desarrolla un sistema a medida: las 7 etapas, qué entrega cada una y cuánto dura

En este artículo

1. ¿Cómo se desarrolla un software a medida?
2. Etapa 1: diagnóstico del proceso
3. Etapa 2: requerimientos
4. Etapa 3: diseño de pantallas y prototipo
5. Etapa 4: desarrollo por módulos
6. Etapa 5: pruebas y aceptación
7. Etapa 6: puesta en marcha
8. Etapa 7: mantenimiento y mejoras
9. ¿Cómo pagar un desarrollo por etapas?
10. ¿Qué hace que un proyecto se retrase?
11. En resumen
12. Preguntas frecuentes

Cuando una empresa decide hacer un sistema, lo primero que quiere saber es cuánto tiempo va a tomar y qué va a recibir en el camino. La respuesta depende del proyecto, pero el camino es casi siempre el mismo: siete etapas, cada una con algo concreto que puedes revisar antes de seguir.

Esta guía explica esas siete etapas con lenguaje de negocio, no de programador: qué se hace en cada una, qué te entregan, cuánto suele durar y qué te toca hacer a ti como dueño o gerente. En CONIT trabajamos así en los sistemas que desarrollamos para empresas e instituciones de distintos rubros, y es la forma más segura que conocemos de llegar a un sistema que se use de verdad.

¿Cómo se desarrolla un software a medida?

Un software a medida se desarrolla en siete etapas: diagnóstico, requerimientos, diseño, desarrollo, pruebas, puesta en marcha y mantenimiento. Las primeras tres definen qué se va a construir; las tres siguientes lo construyen y lo ponen a funcionar; la última lo mantiene vivo.

El estándar internacional que describe los procesos del ciclo de vida del software, ISO/IEC/IEEE 12207, los ordena de forma parecida. No necesitas conocer la norma: lo que necesitas saber es que un proveedor serio no empieza a programar el primer día, y que tú deberías poder ver un avance concreto al final de cada etapa.

Duraciones orientativas para un sistema de 1 a 3 módulos. Las agencias peruanas publican plazos totales de 1 a 2 meses para sistemas básicos y de 2 a 4 meses para intermedios (Adratech, Alaz, revisados el 10 de octubre de 2026).

Etapa 1: diagnóstico del proceso

El diagnóstico responde una pregunta: ¿qué problema queremos resolver y vale la pena programar para resolverlo? Es una conversación, no un documento técnico, y su resultado es un alcance inicial.

Aquí el proveedor debería preguntarte cómo trabajas hoy, quién interviene, qué herramientas usas, dónde se pierden horas o dinero y qué esperas que cambie. También debería decirte si una herramienta existente resolvería el problema sin programar. Si en esta etapa nadie te pregunta por tu proceso y solo te hablan de tecnología, desconfía.

Qué te toca: contar el proceso con ejemplos reales (un pedido, una venta, un reclamo de principio a fin) y mostrar los Excel, formularios o mensajes que usan hoy.

Etapa 2: requerimientos

Los requerimientos son la lista de lo que el sistema debe hacer, escrita de forma que tú y el programador entiendan lo mismo. Es la etapa más importante: un error aquí se arrastra a todo el proyecto.

Se suelen escribir como «historias de usuario»: «Como vendedor, quiero registrar un pedido con el RUC del cliente para que se emita su factura». Cada historia dice quién, qué y para qué, y viene con criterios para saber cuándo está terminada. También se definen los perfiles de usuario, las reglas del negocio, los reportes y las integraciones (pasarela de pagos, facturación electrónica, WhatsApp).

Si no sabes cómo empezar, tenemos una guía con plantilla para escribir los requerimientos de tu sistema sin ser técnico.

Qué te toca: revisar el documento línea por línea y preguntar todo lo que no entiendas. Lo que no está escrito, no está incluido.

Etapa 3: diseño de pantallas y prototipo

El diseño convierte los requerimientos en pantallas que puedes ver y recorrer antes de que se programe nada. Es la forma más barata de detectar errores: mover un botón en un dibujo cuesta minutos; cambiarlo en un sistema terminado, días.

El entregable puede ser un prototipo navegable (pantallas enlazadas que se recorren con clics) o maquetas estáticas. Aquí se decide cómo se ve el formulario de registro, qué columnas tiene la lista de pedidos, cómo se ve el sistema en el celular y qué muestra el panel del gerente. También se definen detalles de seguridad desde el diseño: qué ve cada perfil y qué acciones quedan registradas.

Qué te toca: mostrar el prototipo a quienes usarán el sistema todos los días. Ellos detectan lo que un gerente no ve.

Etapa 4: desarrollo por módulos

En el desarrollo se programa el sistema, pero no de una sola vez: se construye por partes y cada parte se entrega funcionando para que la revises. Es la etapa más larga y la que más pesa en el presupuesto.

Muchos equipos trabajan con métodos ágiles como Scrum, en ciclos de un mes o menos llamados sprints. Según la Guía de Scrum, al final de cada ciclo debe haber un incremento que cumpla una definición de «terminado» acordada. En la práctica significa que cada dos o tres semanas ves algo nuevo funcionando en un entorno de prueba, no un informe de avance.

Para dar una idea del peso de cada etapa, una agencia peruana estima que el análisis y diseño se lleva entre el 15 % y el 20 % del costo, el desarrollo entre el 50 % y el 60 %, el diseño visual entre el 10 % y el 15 %, las pruebas entre el 10 % y el 15 % y la capacitación entre el 5 % y el 10 % (Adratech).

Qué te toca: revisar cada entrega con datos reales en el entorno de prueba y anotar los cambios. Si un cambio no estaba en los requerimientos, va a la siguiente etapa o se cotiza aparte.

Lo que hacemos en CONIT

Construimos sistemas a medida y páginas web para empresas de todo el Perú con entregas por módulos que el cliente revisa en un entorno de prueba antes de salir a producción. Así trabajamos el catálogo, las fichas y los pagos de Adventur y la consulta de cuotas por DNI de ESEIT. Conoce el servicio de sistemas a medida.

Etapa 5: pruebas y aceptación

Las pruebas verifican que el sistema hace lo que dicen los requerimientos y que no falla en los casos difíciles. Terminan con un acta de aceptación: tu conformidad por escrito.

Hay dos tipos de pruebas. Las del equipo de desarrollo, que revisan que cada función trabaje y que nada se rompa al agregar otra. Y las de aceptación, que haces tú con tu equipo usando casos reales: el cliente que paga con Yape, el pedido que se anula, el usuario que se equivoca de contraseña tres veces, la factura con un RUC inválido.

Aquí también se revisa la seguridad. La categoría de riesgo número uno en aplicaciones web, según el OWASP Top 10 2025, es el control de acceso roto: que un usuario pueda ver o hacer algo que no le corresponde. Prueba que cada perfil vea solo lo suyo.

Qué te toca: preparar una lista de casos reales, probarlos y firmar la aceptación solo cuando estén resueltos los errores importantes.

Etapa 6: puesta en marcha

La puesta en marcha es el día en que el sistema empieza a usarse de verdad. Incluye instalarlo en el servidor definitivo, cargar los datos iniciales, capacitar a los usuarios y acompañar las primeras semanas.

Tres decisiones conviene tomar con anticipación:

• Qué datos se cargan. Clientes, productos, saldos pendientes. Si vienen de un Excel, hay que limpiarlos antes.
• Cuándo se deja el método anterior. Lo más seguro es trabajar unos días en paralelo y después cortar.
• Quién atiende las dudas en la primera semana, que es cuando aparecen.

Qué te toca: asegurar que los usuarios asistan a la capacitación y que alguien de tu equipo sea el punto de contacto con el proveedor.

Etapa 7: mantenimiento y mejoras

El mantenimiento empieza el día que el sistema sale a producción y no termina mientras se use. Incluye corregir errores, aplicar actualizaciones de seguridad, mantener el servidor y las copias de seguridad, y agregar mejoras.

Las tecnologías sobre las que se construye un sistema tienen fecha de caducidad. Por ejemplo, la versión 8.2 de PHP deja de recibir parches de seguridad el 31 de diciembre de 2026 (php.net, revisado el 10 de octubre de 2026). Un sistema sin mantenimiento no deja de funcionar de un día para otro, pero se vuelve cada vez más vulnerable. Lo explicamos en la guía de mantenimiento de software.

Qué te toca: contratar el mantenimiento por escrito, con tiempos de respuesta y alcance definidos.

¿Cómo pagar un desarrollo por etapas?

Lo más sano es pagar por hitos: cada pago se libera cuando recibes y apruebas un entregable. Así pagas por avance comprobado y no por promesas.

Un esquema habitual, que se ajusta según el proyecto:

Esquema ilustrativo, no una tarifa: los porcentajes se pactan en cada contrato.

Pide que el contrato diga qué entregable libera cada pago, qué pasa si hay retrasos y quién es el dueño del código al terminar. Las cláusulas que debes exigir están en contrato de desarrollo de software.

¿Qué hace que un proyecto se retrase?

Los retrasos casi nunca vienen de la programación. Vienen de decisiones que se demoran y de requisitos que cambian. Estas son las causas que más vemos:

1. Requerimientos vagos. «Que tenga reportes» no es un requerimiento; «reporte de ventas por vendedor y por mes, exportable a Excel», sí.
2. Aprobaciones lentas. Si cada revisión tarda dos semanas, el proyecto se duplica.
3. Cambios a mitad de módulo. Cada cambio obliga a rehacer trabajo ya hecho.
4. Accesos que no llegan. La cuenta de la pasarela de pagos, las credenciales del proveedor de facturación o el dominio.
5. Querer todo en la primera versión. Empezar con un MVP pequeño reduce el riesgo y el plazo.

En resumen

• Un sistema a medida se desarrolla en siete etapas: diagnóstico, requerimientos, diseño, desarrollo, pruebas, puesta en marcha y mantenimiento.
• Cada etapa debe terminar con un entregable que puedas revisar: un documento, un prototipo, un módulo funcionando o un acta de aceptación.
• Un sistema básico toma de 1 a 2 meses y uno intermedio de 2 a 4, según agencias peruanas que publican plazos.
• Los requerimientos son la etapa más importante: lo que no está escrito, no está incluido.
• Paga por hitos, ligando cada pago a un entregable aprobado.
• Los retrasos vienen de requisitos vagos, aprobaciones lentas y cambios a mitad de camino, no de la programación.

Preguntas frecuentes

¿Cuáles son las etapas del desarrollo de un software?

Las más comunes son siete: diagnóstico del proceso, levantamiento de requerimientos, diseño de pantallas o prototipo, desarrollo por módulos, pruebas y aceptación, puesta en marcha con capacitación y mantenimiento. Los nombres cambian según el proveedor, pero cada etapa debe tener un entregable concreto.

¿Cuánto demora desarrollar un sistema a medida?

Según agencias peruanas que publican plazos, un sistema básico de 1 a 3 módulos toma de 1 a 2 meses, uno intermedio de 2 a 4 meses y un ERP a medida de 4 a 9 meses o más. El plazo real depende del alcance y de qué tan rápido tu equipo revisa y aprueba cada entrega.

¿Qué etapa del desarrollo es la más importante?

La de requerimientos. Un error en esa etapa se arrastra a todas las demás y corregirlo después cuesta mucho más. Por eso conviene invertir tiempo en describir bien el proceso, con ejemplos reales, antes de que se escriba una línea de código.

¿Cómo se paga un desarrollo a medida?

Lo recomendable es pagar por hitos: un adelanto al iniciar, un pago al aprobar el diseño, uno por cada módulo entregado y el saldo al pasar a producción. Así pagas por avance comprobado y el riesgo queda repartido entre tú y el proveedor.

¿Qué es la metodología ágil o Scrum?

Es una forma de trabajar en ciclos cortos, llamados sprints, de un mes o menos, al final de los cuales se entrega una parte del sistema funcionando. Tú la revisas, das tu opinión y se ajusta el plan del siguiente ciclo, en lugar de esperar meses para ver el resultado completo.

¿Qué tengo que hacer yo como cliente durante el desarrollo?

Nombrar a una persona que conozca el proceso, responder dudas a tiempo, revisar cada entrega con casos reales y aprobarla por escrito. También conseguir los accesos que el sistema necesite, como la cuenta de la pasarela de pagos o del proveedor de facturación electrónica.