Si está a punto de encargar un software, le pedirán que apruebe un proceso que usted nunca ha dirigido personalmente: una fase de descubrimiento, una serie de sprints, un ciclo de QA, un plan de lanzamiento. Saber qué cubren esas palabras es lo que le permite distinguir un plan realista de uno caro, y un equipo que ya ha hecho esto antes de uno que está improvisando.
El desarrollo de software es el proceso de planificar, diseñar, construir, probar, desplegar y mantener software. Funciona como ciclos que se repiten, no como una única pasada lineal, e implica a desarrolladores, ingenieros de QA, diseñadores y un responsable de producto o de proyecto. El término abarca desde una sola aplicación móvil hasta una plataforma empresarial de varios años.
Esta guía explica cómo es realmente ese proceso, quién hace qué, las metodologías que oirá nombrar, los principales tipos de software que se construyen, qué mueve el coste y los modelos de colaboración bajo los que puede contratarlo. Redwerk ha ejecutado este proceso en más de 170 proyectos desde 2005, en ingeniería de productos de software a medida para clientes de Norteamérica y Europa Occidental.
Qué es el desarrollo de software en la práctica
En esencia, el desarrollo de software es un ciclo con seis etapas: planificar, diseñar, construir, probar, desplegar y mantener.
Lo importante es que se repite. Un equipo planifica una pequeña parte del producto, la construye, aprende algo que cambia el plan y empieza la siguiente vuelta con lo que ya sabe.
Eso es lo más útil que puede interiorizar un responsable no técnico. Cuando un proveedor presenta un plan en el que cada fase ocurre exactamente una vez, en orden y sin retroalimentación entre ellas, está describiendo un documento, no un proceso de entrega.
Quién participa realmente
Un equipo de proyecto típico tiene cinco roles, y normalmente los conocerá a todos:
- Los desarrolladores escriben el código. En la mayoría de proyectos se reparten entre frontend (lo que ve el usuario) y backend (datos, lógica, integraciones).
- Los ingenieros de QA prueban el software de forma deliberada y sistemática, buscando cómo se rompe antes de que lo encuentren sus usuarios.
- Los diseñadores deciden cómo se ve el producto y cómo se mueve un usuario por él. En software de negocio esto importa más de lo que se suele pensar, porque una herramienta interna que nadie sabe navegar acaba sin usarse.
- Un responsable de producto o de proyecto es el dueño del alcance, la secuencia y el calendario, y suele ser su punto de contacto principal.
- Un responsable técnico de la cuenta, en trabajo externalizado, es la persona sénior responsable del conjunto de la colaboración, no de un sprint concreto.
Se busca mucho el “significado de desarrollador de software”, y la respuesta honesta es que un desarrollador es quien escribe y mantiene el código, pero entregar software que funcione requiere también los otros cuatro roles. Un equipo formado solo por desarrolladores, sin QA y sin nadie que sea dueño del alcance, es una forma de fracaso habitual y cara.
El proceso de desarrollo de software, paso a paso
Estas etapas no pesan lo mismo. Las primeras son baratas de hacer bien y caras de rehacer, mientras que las últimas son donde se ve el avance y donde se gasta la mayor parte del presupuesto. Cuánto tiempo dedica un proveedor a las dos primeras es una señal razonable de cómo trabaja.
Descubrimiento y definición del alcance
Este es el paso que más proyectos se saltan y luego lamentan. El descubrimiento es donde se establece qué tiene que hacer el software, quién lo usa, con qué se conecta y qué significa “terminado”. Produce un alcance sobre el que realmente se puede estimar.
Saltárselo no ahorra dinero. Traslada el coste a un momento peor, porque los requisitos se acaban descubriendo igualmente, solo que más tarde, en plena construcción, cuando cambiar de rumbo significa tirar trabajo hecho.
No necesita requisitos completos para empezar. La mayoría de clientes no los tiene. Lo que necesita es una forma estructurada de encontrarlos, que es para lo que sirve una fase de descubrimiento, y un resultado escrito que todos acepten, que es lo que producen los servicios de especificación funcional.
Diseño y arquitectura
Aquí ocurren dos cosas. Los diseñadores definen la interfaz y los flujos de usuario. Los ingenieros definen la arquitectura: el stack, el modelo de datos, cómo se divide el sistema en partes y cómo va a soportar el crecimiento.
Las decisiones de arquitectura son las caras de revertir. Elegir una estructura de base de datos equivocada o acoplar dos sistemas que deberían haber seguido separados es una decisión que seguirá pagando mucho después del lanzamiento. Un equipo que ya ha construido algo parecido sabe dónde suele romperse este tipo de diseño, que es exactamente para lo que le está pagando en esta etapa.
Construcción, pruebas y despliegue
La entrega moderna es iterativa. El equipo construye una porción funcional del producto, la prueba y la pone en algún sitio donde usted pueda hacer clic, y luego repite. Debería esperar ver algo funcional en semanas, no al final.
Las pruebas van en paralelo a la construcción, no después. QA escribe pruebas a medida que aterrizan las funcionalidades, así que un error encontrado el martes cuesta una hora en lugar de aparecer tres meses después, enredado en código construido encima.
El despliegue es una disciplina propia. Llevar código a los servidores de forma fiable, repetible y reversible es lo que separa un lanzamiento que puede hacer un jueves por la tarde de uno que necesita un fin de semana y un plan de reversión.
Para el desglose fase a fase del ciclo de vida completo, consulte la guía de Redwerk sobre mejores prácticas de SDLC. Si ya tiene un proceso y quiere saber si aguanta, la lista de comprobación de auditoría SDLC es la versión diagnóstica.
Mantenimiento e iteración
El software no está terminado cuando se lanza. Las dependencias envejecen, llegan parches de seguridad, los navegadores cambian y su negocio necesita cosas que el alcance original nunca imaginó. Presupuestar la construcción y no el mantenimiento es una de las formas más fiables de acabar con una aplicación que nadie puede tocar con seguridad dos años después.
Agile, waterfall e híbrido comparados
La metodología es cómo el equipo organiza el ciclo. Tres formas cubren casi todo lo que le van a ofrecer.
Agile
Ciclos cortos de dos a cuatro semanas, cada uno produciendo software funcional. El alcance se adapta a medida que se aprende.
Trabajo de producto donde los requisitos van a evolucionar, y la mayoría del software comercial
Más difícil de cotizar como una cifra fija de partida, y requiere su implicación a lo largo del proyecto
Waterfall
Las fases van en secuencia y cada una se aprueba antes de empezar la siguiente. El alcance se fija al inicio.
Trabajo de alcance cerrado, entornos regulados, proyectos donde la especificación es realmente completa y estable
El cambio es caro y los problemas aparecen tarde, porque las pruebas llegan casi al final
Híbrido
Alcance y presupuesto fijos a nivel de contrato, entrega ágil dentro de ellos
Clientes que necesitan certeza presupuestaria pero están construyendo algo realmente nuevo
Exige disciplina sobre qué cuenta como dentro de alcance, o se convierte en waterfall con sprints
El desarrollo de software agile es la opción por defecto para la mayoría del trabajo de producto moderno, y con razón. No es automáticamente la respuesta correcta. Si está construyendo contra una especificación regulatoria que no va a cambiar, la ceremonia de los ciclos de dos semanas añade sobrecarga sin añadir mucho aprendizaje.
Los principales tipos de desarrollo de software
La palabra “software” esconde mucha variedad, y el tipo determina las herramientas, el equipo, los plazos y las restricciones.
- El desarrollo web construye aplicaciones que se ejecutan en un navegador. Es la forma más común para software de negocio, porque no hay nada que instalar y las actualizaciones llegan a todos a la vez. Los stacks habituales incluyen React, Vue.js, Angular, .NET, Django y PHP.
- El desarrollo móvil construye para iOS y Android, ya sea de forma nativa (Swift, Kotlin) o multiplataforma (Flutter). Las restricciones son la revisión de las tiendas de aplicaciones, la fragmentación de dispositivos y el hecho de que los usuarios estarán con mala conexión.
- El desarrollo de escritorio construye software instalado en una máquina. Sigue siendo la respuesta correcta para procesamiento local intensivo, trabajo sin conexión e integración profunda con el sistema operativo.
- El desarrollo embebido e IoT construye software que se ejecuta sobre hardware, donde la memoria es escasa, las actualizaciones son difíciles de distribuir y un error puede significar un dispositivo físico comportándose mal sobre el terreno.
Software a medida frente a software estándar
Comprar un producto existente es más rápido y barato, y para un problema ya resuelto como nóminas o correo electrónico es casi siempre lo correcto. Construir a medida tiene sentido cuando el proceso que está automatizando es realmente específico de cómo funciona su negocio, cuando la carga de integrar varias herramientas estándar entre sí supera el coste de un único sistema que encaje, o cuando el software es el producto que vende.
Un camino intermedio útil es construir la versión más pequeña que demuestre la idea antes de comprometerse con el sistema completo. Cómo construir un MVP correctamente explica cómo acotarlo para que quede como base y no como algo desechable.
Qué determina realmente los costes del desarrollo de software
Nadie puede cotizar su proyecto a partir del nombre de una categoría. Lo que sí pueden hacer es decirle qué variables mueven la cifra, y estas son las que más importan:
- Claridad del alcance. El factor más importante con diferencia. Un sistema bien especificado se estima de forma ajustada. Uno difuso se acolcha, porque el equipo está poniendo precio a su incertidumbre.
- Integraciones. Cada sistema externo al que se conecta añade trabajo difícil de estimar, porque usted no controla el otro extremo. Tres integraciones es un proyecto distinto de cero integraciones.
- Requisitos de cumplimiento y seguridad. El trabajo en sanidad, finanzas y sector público conlleva obligaciones de auditoría, tratamiento de datos y documentación que son esfuerzo de ingeniería real.
- Migración de datos. Llevar años de registros existentes a un sistema nuevo, de forma limpia, se subestima sistemáticamente. Los datos heredados están más sucios de lo que nadie recuerda.
- Seniority y composición del equipo. Los ingenieros sénior cuestan más por hora y normalmente menos por resultado, porque los errores caros son arquitectónicos y se cometen pronto.
- Profundidad del diseño. Una interfaz de cara al cliente, pulida y muy usada, es una inversión distinta de una pantalla de administración interna que usan seis personas.
- La cola de mantenimiento. El soporte continuo, el alojamiento y las actualizaciones son una línea recurrente, no un redondeo sobre la construcción.
¿Quiere saber dónde encaja su proyecto? Redwerk ofrece estimaciones gratuitas. Cuéntenos qué está construyendo, aunque los detalles sigan siendo aproximados, y le devolveremos un rango realista y los supuestos que hay detrás.
Modelos de colaboración: cómo se contrata el desarrollo de software
El modelo de colaboración decide quién asume el riesgo de que las cosas tarden más de lo previsto. Esa es toda la cuestión, y conviene entenderla antes de comparar presupuestos.
Precio cerrado
Una suma acordada por un alcance acordado
Proyectos bien definidos, con requisitos estables y una meta clara
Cada cambio se convierte en una negociación, y el presupuesto lleva una prima de riesgo
Tiempo y materiales
Por las horas realmente trabajadas
Alcance cambiante, trabajo con mucho descubrimiento, desarrollo de producto continuo
Requiere confianza y visibilidad real sobre dónde van las horas
Equipo dedicado
Una tarifa mensual por un equipo que trabaja solo en su producto
Trabajo de larga duración, cubrir una carencia de capacidad o de perfiles que no puede contratar
Solo compensa a lo largo de meses, no para un encargo puntual y corto
Ampliación de equipo
Por cada especialista añadido a su equipo actual
Ya tiene un equipo y un proceso que funcionan y necesita una habilidad concreta
La gestión, la arquitectura y el resultado siguen siendo suyos
La elección suele derivarse de cuánta certeza tiene sobre el alcance. El precio cerrado premia la certeza. Tiempo y materiales y el equipo dedicado se adaptan a la realidad de que aprenderá cosas durante la construcción.
Para un tratamiento más extenso de dónde encaja un equipo de desarrollo dedicado frente a las alternativas, vea CTO fraccional frente a consultoría de desarrollo de software frente a ampliación de equipo, y para la pregunta de fondo sobre construir o contratar al equipo, desarrollo de software interno o externo.
Qué valorar antes de contratar a un equipo externo
Externalizar no siempre es lo correcto, y el proveedor que le diga lo contrario está vendiendo.
La objeción que la gente plantea primero es el conocimiento. Si lo construye un equipo externo, ¿se va el entendimiento cuando acaba el contrato? En realidad esa es una cuestión de documentación y traspaso. Un proveedor que deja las cosas por escrito, mantiene la especificación al día y entrega una base de código documentada le deja más conocimiento institucional utilizable que un equipo interno que lo guardaba todo en la cabeza de dos personas. Pregunte a cualquier proveedor qué documentación acompaña a la colaboración y de quién es al final. Una respuesta vaga ahí le dice más que cualquier presentación comercial.
Manténgalo internamente cuando ya tenga un equipo de ingeniería sólido con capacidad libre, porque añadir un grupo externo genera una sobrecarga de coordinación que no necesita.
Piénselo bien antes de externalizar si internamente no hay nadie que pueda tomar decisiones de producto. Un equipo externo puede trabajar sin requisitos completos, y uno bueno espera hacerlo. Con lo que ningún equipo puede trabajar es sin alguien de su lado con autoridad para responder preguntas y decidir. Sin eso, el proyecto se atasca sin importar quién escriba el código.
En cuanto a plazos, el desarrollo asistido por IA ha movido la línea. Trabajo que antes ocupaba un trimestre puede aterrizar en semanas cuando el problema está bien entendido y el código es convencional, y hoy es razonable preguntárselo a un proveedor. Lo que no ha comprimido es el tiempo necesario para acordar qué se está construyendo, ni para integrarse con sistemas que usted no controla. Para un plazo muy corto sobre un problema común, comprar un producto estándar y configurarlo para que encaje con su proceso sigue siendo a veces la vía más rápida.
Términos de desarrollo de software que va a escuchar
Sprint, backlog, deuda técnica, CI/CD, staging, refactorización, API. Los proveedores usan estas palabras constantemente y rara vez se paran a definirlas.
Redwerk mantiene un glosario en lenguaje llano precisamente para esto: términos de desarrollo de software, los 60 que conviene conocer. Merece la pena echarle un vistazo antes de su primera reunión de alcance, porque poder preguntar “¿eso está en este sprint o en el backlog?” cambia la conversación.
Cómo ejecuta Redwerk este proceso
Redwerk lleva construyendo software desde 2005, con más de 170 clientes en Norteamérica y Europa Occidental. Hay tres cosas sobre cómo ejecutamos el proceso que conviene conocer si está comparando equipos.
Empezamos con un descubrimiento estructurado, y no exigimos que llegue con los requisitos completos. La mayoría de clientes no los tiene. Trabajar la especificación juntos es parte del encargo, no un requisito previo para empezarlo.
Asignamos perfiles por stack, no solo por sector. Si su sistema corre sobre .NET y Azure, recibe ingenieros que han entregado sistemas .NET y Azure, que es lo que hace que una incorporación corta sea realista y no una aspiración.
Comunicamos de más a propósito. El tema más constante en los comentarios de nuestros clientes es que siempre supieron en qué punto estaba el proyecto. Para responsables no técnicos que dependen por completo del equipo que han contratado, esa es la diferencia entre un proyecto manejable y uno angustioso.
Si está al principio de todo esto y quiere definir el alcance y el enfoque correctos antes de que nadie escriba código, empiece por la consultoría de desarrollo de software.
Preguntas frecuentes
¿Qué es el desarrollo de software en términos sencillos?
El desarrollo de software es el trabajo de planificar, construir, probar y mantener programas informáticos. Implica a un equipo de desarrolladores, testers, diseñadores y un responsable trabajando en ciclos que se repiten, y no a una sola persona escribiendo código de principio a fin.
¿Cuál es la diferencia entre desarrollo de software e ingeniería de software?
Los términos se solapan mucho y a menudo se usan indistintamente. La ingeniería de software suele implicar un mayor énfasis en el proceso formal, la arquitectura y la mantenibilidad a largo plazo, mientras que el desarrollo de software es el término más amplio que cubre todo el trabajo de crear software.
¿Cuáles son las etapas del ciclo de vida del desarrollo de software?
El ciclo de vida del desarrollo de software tiene seis etapas: planificación, diseño, desarrollo, pruebas, despliegue y mantenimiento. En la práctica moderna estas se repiten en ciclos cortos en lugar de ejecutarse una sola vez en secuencia, de modo que un equipo vuelve a la planificación y al diseño muchas veces a lo largo de un proyecto.
¿Cuánto dura un proyecto de desarrollo de software?
Depende sobre todo del alcance y de la complejidad de las integraciones. Un producto mínimo viable que demuestre un único flujo central suele ser cuestión de meses, mientras que una plataforma completa con varias integraciones, migración de datos y requisitos de cumplimiento lleva bastante más. Una fase de descubrimiento es lo que convierte ese rango en un calendario real.
¿Necesito requisitos completos antes de contratar a un equipo de desarrollo?
No. La mayoría de clientes empieza sin ellos. Un buen equipo ejecuta una fase de descubrimiento estructurada para establecer el alcance de forma conjunta. Lo que sí necesita es a alguien de su lado con autoridad para tomar decisiones de producto durante la construcción.
Descubra cómo ayudamos a AWE Learning a migrar de las instalaciones a la nube y a llegar a usuarios fuera de EE. UU. implementando una solución SaaS escalable
