Un proceso de software es una forma organizada de transformar una necesidad en una solución que pueda usarse, probarse, mantenerse y evolucionar. No se trata solo de programar: incluye entender el problema, definir requisitos, diseñar, construir, verificar, desplegar, operar y mejorar.
Distintos equipos pueden usar procesos diferentes. Algunos trabajan con etapas muy definidas, otros con ciclos cortos e iterativos, y otros combinan prácticas según el contexto. Sin embargo, muchas actividades aparecen en casi todos los proyectos de software.
En este tema veremos esas actividades principales sin atarlas todavía a un modelo específico. Más adelante estudiaremos modelos de proceso como cascada, iterativo, incremental y ágil.
Un proceso de software es el conjunto de actividades, prácticas, roles, artefactos y decisiones que permiten desarrollar y mantener un sistema. Su propósito es dar orden al trabajo para reducir improvisación, mejorar comunicación y aumentar la probabilidad de entregar valor.
Un proceso puede definir:
La primera actividad es entender el problema que se quiere resolver. Antes de hablar de pantallas, bases de datos o tecnologías, el equipo debe comprender qué necesidad existe, quién la tiene y qué impacto tendría resolverla.
Algunas preguntas iniciales son:
Si esta actividad se omite, el equipo puede construir una solución técnicamente correcta pero poco útil.
Los requisitos describen qué debe cumplir el sistema. Pueden referirse a funcionalidades, restricciones, reglas de negocio, rendimiento, seguridad, usabilidad, integración, operación o mantenimiento.
El relevamiento busca obtener información de usuarios, clientes, documentos, procesos existentes y sistemas relacionados. El análisis transforma esa información en requisitos más claros, consistentes y priorizados.
Esta actividad puede producir distintos artefactos:
El objetivo no es escribir documentos extensos sin utilidad, sino lograr acuerdos claros sobre lo que se necesita construir.
Una vez que se entienden las necesidades, el equipo debe decidir qué se hará primero, qué puede esperar y qué no forma parte del alcance actual. Esta decisión depende de valor, riesgo, costo, urgencia, dependencias y capacidad del equipo.
La planificación no consiste en adivinar el futuro con exactitud. Consiste en organizar el trabajo de manera razonable y revisar el plan cuando aparece nueva información.
Algunas actividades de planificación son:
El diseño define cómo se organizará la solución antes o durante la construcción. Incluye decisiones sobre estructura, módulos, interfaces, datos, flujos, responsabilidades, tecnologías y experiencia de usuario.
El diseño puede ser de distintos niveles:
| Nivel de diseño | Qué define | Ejemplo |
|---|---|---|
| Diseño de experiencia | Cómo interactúan los usuarios con el sistema. | Flujo para registrarse, pagar y recibir confirmación. |
| Diseño funcional | Cómo se comportan las funcionalidades. | Reglas para aprobar o rechazar una solicitud. |
| Diseño de datos | Cómo se organizan y relacionan los datos. | Entidades como cliente, pedido, producto y pago. |
| Diseño técnico | Cómo se estructuran componentes, servicios y módulos. | Separar interfaz, lógica de negocio y acceso a datos. |
| Arquitectura | Decisiones estructurales de alto impacto. | Aplicación monolítica, servicios, colas, APIs o nube. |
Diseñar no significa intentar prever cada detalle, sino tomar decisiones que guíen la construcción y reduzcan riesgos.
La construcción es la actividad en la que se implementa el software. Incluye escribir código, configurar herramientas, crear bases de datos, integrar servicios, construir interfaces, preparar scripts y resolver problemas técnicos.
Durante la construcción se aplican prácticas como:
La implementación no debe verse como una actividad aislada. Debe mantenerse conectada con requisitos, diseño, pruebas y objetivos del producto.
La verificación y la validación ayudan a comprobar que el software cumple lo esperado. Aunque suelen relacionarse con pruebas, también pueden incluir revisiones, inspecciones, prototipos, demostraciones y análisis de documentación.
| Concepto | Pregunta que responde | Ejemplo |
|---|---|---|
| Verificación | ¿Construimos correctamente lo especificado? | Revisar que una regla se implementó según el requisito. |
| Validación | ¿Construimos lo que el usuario realmente necesita? | Mostrar un prototipo al usuario y confirmar que resuelve su tarea. |
Ambas son necesarias. Un sistema puede cumplir la especificación y aun así no resolver bien el problema real si la especificación era incompleta o incorrecta.
Las pruebas son actividades orientadas a obtener información sobre la calidad del sistema. Ayudan a detectar defectos, reducir riesgos y generar confianza antes de entregar o publicar una versión.
Según el nivel y el objetivo, pueden existir:
Las pruebas no deberían quedar solamente para el final. Cuanto antes se detecta un problema, más fácil suele ser corregirlo.
La gestión de configuración permite controlar los elementos que forman parte del sistema: código, dependencias, scripts, parámetros, documentación, ambientes y versiones. Sin esta actividad, resulta difícil saber qué se entregó, qué cambió o cómo reproducir un comportamiento.
Incluye prácticas como:
Esta actividad es fundamental para trabajar en equipo y mantener trazabilidad entre cambios, entregas y problemas reportados.
Desplegar significa poner el software en un ambiente donde pueda ser usado o evaluado. Puede ser un ambiente de pruebas, preproducción, producción o una tienda de aplicaciones.
Una entrega puede incluir más que código:
Un despliegue bien gestionado reduce interrupciones, errores de configuración y sorpresas en producción.
Después de entregar el software, comienza su uso real. En esta etapa importa observar cómo se comporta el sistema en condiciones de producción: usuarios reales, datos reales, carga real e integraciones reales.
El monitoreo permite detectar problemas como:
Operar software significa asumir que el sistema debe mantenerse disponible, seguro y observable mientras genera valor.
El mantenimiento incluye correcciones, mejoras, adaptaciones y prevención de problemas futuros. Es una actividad normal y necesaria, no una señal de fracaso del desarrollo inicial.
Algunas tareas de mantenimiento son:
Gran parte del costo total de un sistema ocurre después de su primera entrega. Por eso, mantener bien el software es tan importante como construirlo.
La documentación y la comunicación atraviesan todo el proceso. No deberían considerarse una actividad final ni separada del trabajo real. Documentar bien significa conservar información útil para tomar decisiones, usar el sistema, mantenerlo y transferir conocimiento.
Puede documentarse:
La documentación debe ser proporcional al proyecto y mantenerse lo suficientemente actualizada para ser confiable.
Los equipos también deben revisar su forma de trabajar. Un proceso no es algo fijo que nunca cambia. Si una práctica no ayuda, debe ajustarse; si aparece un problema repetido, conviene analizarlo; si una herramienta mejora la colaboración, puede incorporarse.
La mejora continua puede incluir:
Un equipo maduro no solo mejora el producto; también mejora su manera de construirlo.
| Actividad | Pregunta principal | Resultado esperado |
|---|---|---|
| Comprensión del problema | ¿Qué necesidad debemos resolver? | Objetivos y contexto claros. |
| Requisitos | ¿Qué debe cumplir el sistema? | Acuerdos funcionales y no funcionales. |
| Planificación | ¿Cómo organizaremos el trabajo? | Prioridades, tareas, riesgos y entregas. |
| Diseño | ¿Cómo se organizará la solución? | Estructura, flujos, datos e interfaces definidos. |
| Construcción | ¿Cómo implementamos la solución? | Código, configuración e integraciones. |
| Pruebas | ¿El sistema cumple lo esperado? | Evidencia de calidad y defectos detectados. |
| Despliegue | ¿Cómo ponemos el software en uso? | Versión instalada o publicada correctamente. |
| Operación | ¿Cómo se comporta en uso real? | Servicio monitoreado y atendido. |
| Mantenimiento | ¿Cómo corregimos y evolucionamos? | Sistema adaptado a nuevas necesidades. |
Supongamos que se desarrolla un sistema de reservas para un centro deportivo. El proceso podría incluir:
Este ejemplo muestra que el desarrollo avanza mediante varias actividades conectadas, no mediante una sola tarea de programación.
Al gestionar el proceso de software suelen cometerse errores como:
El proceso de software permite ordenar actividades que, de otra manera, quedarían libradas a la improvisación. No existe un único proceso válido para todos los proyectos, pero sí existen actividades fundamentales que ayudan a transformar una necesidad en una solución útil, verificable y sostenible.
Para quien comienza, la idea principal es esta: desarrollar software profesionalmente implica recorrer un conjunto de actividades conectadas, donde cada una aporta información y reduce riesgos para las demás.
En el próximo tema veremos una introducción al ciclo de vida del software, para comprender cómo estas actividades se organizan desde la idea inicial hasta el retiro o reemplazo del sistema.