Las fases del desarrollo de software son seis: análisis de requisitos, diseño, programación, pruebas, implantación y mantenimiento. Cada una produce un resultado que alimenta a la siguiente, desde la lista de requisitos hasta el programa en uso. En los proyectos ágiles las fases no desaparecen, sino que se repiten en ciclos cortos.
Las fases en una tabla.
| Fase | Pregunta que responde | Qué se entrega | Qué te toca a ti |
|---|---|---|---|
| Análisis de requisitos | ¿Qué problema resolvemos y para quién? | Lista de requisitos priorizada | Explicar cómo trabajáis y qué falla hoy |
| Diseño | ¿Cómo se organiza el programa y cómo se verá? | Arquitectura, modelo de datos y prototipos de pantallas | Revisar los prototipos con quien usará el programa |
| Programación | ¿Funciona lo que hemos diseñado? | Código en un repositorio y versiones de prueba | Probar cada versión que se te enseñe |
| Pruebas | ¿Hace lo que debe y sin errores graves? | Informe de pruebas y errores corregidos | Validar con casos reales de tu empresa |
| Implantación | ¿Está en uso con los datos reales? | Programa instalado, datos migrados y formación | Organizar al equipo para el cambio |
| Mantenimiento | ¿Sigue sirviendo cuando algo cambia? | Correcciones, actualizaciones y mejoras | Avisar de errores y de cambios en tu negocio |
La administración española recoge un recorrido muy parecido en Métrica versión 3. Divide el ciclo de vida en procesos que van de la planificación y el estudio de viabilidad hasta la implantación, la aceptación y el mantenimiento.
1. Análisis de requisitos.
Es la fase que más errores evita y la que más se tiende a recortar. Consiste en entender qué necesita la empresa, no en apuntar lo que pide. Decir «quiero una app» no es lo mismo que decir «los técnicos pierden una hora diaria rellenando partes en papel».
El resultado es una lista de requisitos ordenada por prioridad. Cada requisito debe poder comprobarse después. «El programa será rápido» no sirve; «la ficha del cliente se abre en menos de dos segundos», sí.
2. Diseño.
Aquí se decide cómo será el programa. Por un lado, la tecnología y la forma de guardar los datos. Por otro, el aspecto de las pantallas y el orden en que se recorren.
Si el programa trata datos personales, el diseño es el momento de pensar en ellos. El RGPD pide aplicar las medidas de protección desde que se deciden los medios del tratamiento, no después. Añadirlas con el programa ya hecho cuesta mucho más.
Los prototipos de pantallas son la mejor herramienta de esta fase. Enseñar un dibujo navegable cuesta poco y destapa malentendidos que, ya programados, costarían semanas.
3. Programación.
Es la fase que todo el mundo imagina al pensar en software. El equipo escribe el código, lo guarda en un sistema de control de versiones y lo integra poco a poco. Cada cambio debería pasar la revisión de otra persona antes de entrar.
La calidad del código no se ve desde fuera, pero decide cuánto costará cambiar el programa dentro de unos años. Lo contamos en calidad del código fuente.
Documentar forma parte del trabajo. La Ley de Propiedad Intelectual incluye la documentación preparatoria dentro del propio concepto de programa de ordenador. Un programa sin documentación queda atado a quien lo escribió.
4. Pruebas.
Las pruebas comprueban que el programa cumple los requisitos. Hay pruebas automáticas, que el ordenador repite con cada cambio, y pruebas manuales, en las que una persona recorre el programa como lo haría un usuario.
Si el programa guarda datos personales, las pruebas también deben cubrir la seguridad. El RGPD incluye entre sus medidas un proceso de verificación regular de la eficacia de las medidas de seguridad. Es decir, no basta con ponerlas; hay que comprobar que funcionan.
La prueba más valiosa la haces tú. Nadie detecta mejor un caso raro que quien lo vive cada semana en el día a día.
5. Implantación.
El programa pasa a usarse de verdad. Hay que instalarlo en el servidor definitivo, migrar los datos del sistema anterior y formar a quienes lo usarán.
Conviene elegir bien el momento. Arrancar en plena temporada alta multiplica los problemas. Lo prudente es empezar en una época tranquila y mantener el sistema anterior en modo consulta unas semanas.
6. Mantenimiento.
Un programa en uso nunca está terminado del todo. Aparecen errores que las pruebas no vieron, cambian las leyes y la empresa pide mejoras. El mantenimiento cubre esas tres cosas y puede durar más años que el propio desarrollo.
Un programa de facturación, por ejemplo, tiene que adaptarse cada vez que cambian las normas de facturación. Por eso conviene acordar desde el principio quién hará ese mantenimiento y cómo se pedirán los cambios.
Fases en cascada o en ciclos.
En un proyecto en cascada, cada fase se hace una sola vez y en orden. En un proyecto ágil, las seis fases se repiten en cada ciclo corto sobre una parte pequeña del programa. Lo explicamos en metodologías de desarrollo de software y, para Scrum, en Scrum en el desarrollo de software.
Quién coordina todo esto, y cómo, lo tratamos en gestión de proyectos de software. En OverFuture llevamos más de 100 proyectos, con un fundador que programa desde 2013. Si tienes uno en mente, cuéntanoslo desde desarrollo de software a medida.
Preguntas frecuentes.
El análisis de requisitos. Un error ahí se arrastra a todas las demás y es el más caro de corregir al final.
Depende del tamaño del proyecto. Lo que no varía es que el mantenimiento continúa mientras el programa se use.
No. Lo que no se prueba antes se prueba después, con clientes reales y con más coste.
