Diagrama de flujo del proceso de desarrollo de software: pasos, símbolos, ejemplos y una plantilla gratuita

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Un diagrama de flujo del proceso de desarrollo de software convierte una secuencia que suele vivir en la cabeza de las personas en una imagen que cualquiera entiende en un minuto. Muestra qué paso va primero, quién es su responsable, dónde se toma una decisión y qué ocurre cuando falla una revisión o una prueba. A una nueva incorporación le explica cómo se trabaja. A un cliente le indica dónde tendrá que aprobar algo. A un responsable le revela los traspasos en los que el trabajo tiende a atascarse.

En los proyectos con clientes dibujamos este diagrama durante la primera semana, porque es la forma más rápida de acordar cómo funcionará el proceso de desarrollo de software a medida: cuándo se congelan los requisitos, quién aprueba los diseños, qué significa «terminado» en un sprint y cómo llega una versión a producción. Un diagrama de flujo del desarrollo de software es también el documento que todos consultan cuando algo sale mal, porque muestra qué control se saltó.

Esta guía explica qué es un diagrama de flujo del desarrollo de software, recorre las etapas estándar y los puntos de decisión, enumera los símbolos necesarios y muestra patrones listos para flujos por carriles, en cascada, ágiles, en V y DevOps. Termina con un método en seis pasos, una plantilla Mermaid lista para copiar, una comparativa de herramientas y respuestas a las preguntas más frecuentes.

¿Qué es un diagrama de flujo del proceso de desarrollo de software?

Un diagrama de flujo del proceso de desarrollo de software es un esquema que representa los pasos para crear software como formas conectadas: rectángulos para las actividades, rombos para las decisiones, flechas para el orden del trabajo y formas redondeadas para el inicio y el final. Describe el proceso, no el código, y responde a la pregunta «¿cómo pasa nuestro equipo de una idea a un software que funciona?».

El formato es antiguo. Los ingenieros industriales Frank y Lillian Gilbreth presentaron sus «process charts» a la American Society of Mechanical Engineers en 1921, y los símbolos de diagrama de flujo habituales en informática se normalizaron en la ISO 5807, publicada en 1985. Los equipos de software adoptaron el mismo lenguaje visual porque es sencillo: casi cualquiera sabe leer un esquema de cajas y flechas sin formación.

Un buen diagrama de flujo del desarrollo de software cumple tres funciones a la vez:

• Fija el orden del trabajo: requisitos antes del diseño, diseño antes de la construcción, pruebas antes del lanzamiento.
• Nombra a los responsables: cada paso tiene una sola persona o un solo rol que responde de él.
• Hace explícitas las decisiones: aprobaciones, controles de calidad y puntos go/no-go se dibujan como rombos con un camino «sí» y otro «no».

Diagrama de flujo vs diagrama de procesos vs diagrama de flujo de datos

Los tres términos están relacionados, pero describen cosas distintas, y confundirlos da lugar a esquemas que intentan mostrarlo todo y no explican nada.

Para representar cómo construye software su equipo, casi siempre basta con un diagrama de flujo o un diagrama de procesos por carriles. Recurra a BPMN, normalizado como ISO/IEC 19510 en 2013, solo cuando el esquema vaya a dirigir un motor de flujos de trabajo o deba seguir un estándar formal de la empresa.

El flujo estándar del proceso de desarrollo de software, paso a paso

La mayoría de los diagramas de flujo del proceso de desarrollo de software siguen la misma estructura de ocho etapas, sea cual sea la metodología del equipo: idea, requisitos, diseño, desarrollo, pruebas, aceptación, despliegue y mantenimiento. La metodología cambia cuántas veces se recorren estas etapas y lo grande que es cada pasada, no las etapas en sí. La tabla siguiente es el flujo de referencia del que partimos en los proyectos nuevos.

Cada «no» en un punto de control es una flecha hacia una etapa anterior, y dibujar esos bucles es lo que distingue un diagrama de flujo útil de una simple lista de fases. Una prueba fallida vuelve a desarrollo, un diseño rechazado vuelve a diseño y una incidencia en producción crea una nueva entrada en el backlog. Si quiere la teoría que hay detrás de estas etapas, nuestra guía del ciclo de vida del desarrollo de software trata en profundidad cada fase y los modelos SDLC clásicos.

Los puntos de decisión que todo diagrama de flujo debe mostrar

Los rombos de decisión contienen más información que las cajas, porque muestran dónde puede detenerse el trabajo. Cinco controles aparecen en casi todos los procesos de software sanos:

1. Aprobación de requisitos: el responsable de negocio confirma el alcance y los criterios de aceptación antes de que empiece el diseño.
2. Aprobación del diseño: la arquitectura y la UX se revisan para que los cambios costosos se hagan sobre el papel y no en el código.
3. Revisión de código y control de CI: ningún cambio se fusiona sin un segundo par de ojos y un build automatizado en verde.
4. Preparación para el lanzamiento: las pruebas han terminado, no quedan defectos críticos abiertos y existe un plan de reversión.
5. Control tras el lanzamiento: la monitorización confirma que la versión está estable; si no, el equipo revierte o aplica un hotfix.

La aceptación merece su propio rombo, porque es el único control que pertenece al cliente y no al equipo. Nuestro artículo sobre las pruebas de aceptación de usuario explica cómo realizarlas para que la aprobación sea un trámite y no una sorpresa.

¿Qué símbolos de diagrama de flujo necesita?

Solo necesita seis o siete símbolos para dibujar un diagrama de flujo claro del proceso de desarrollo de software; el resto del conjunto de la ISO 5807 rara vez es útil en mapas de procesos. Un vocabulario reducido mantiene el esquema legible para las partes interesadas no técnicas.

Las flechas siempre apuntan en la dirección del trabajo, y cada rombo de decisión necesita salidas etiquetadas. Una flecha sin etiqueta que sale de un rombo es el motivo más habitual por el que se malinterpreta un diagrama de flujo.

Diagrama de flujo por carriles: ¿quién hace qué en el desarrollo de software?

Un diagrama de flujo por carriles (swimlane) divide el esquema en franjas horizontales o verticales, una por rol, para ver quién es responsable de cada paso y dónde cambia de manos el trabajo. Es el formato más útil para los equipos de software, porque la mayoría de los retrasos se producen en los traspasos, no dentro de un paso.

Un diagrama por carriles típico del desarrollo de software tiene cinco o seis carriles:

Cada flecha que pasa de un carril a otro es un traspaso, y cada traspaso necesita un desencadenante claro («historia movida a Ready for QA») y un artefacto (un build, un ticket, un documento). Si gestiona el trabajo en Jira, haga coincidir carriles y estados con su tablero para que el diagrama y la herramienta cuenten la misma historia; nuestra guía del flujo de trabajo en Jira muestra una configuración que reproduce este flujo.

Ejemplos de diagrama de flujo del proceso de desarrollo de software por modelo

La forma del diagrama de flujo depende del modelo de desarrollo: la cascada es una línea recta con controles, el ágil es un bucle, el modelo en V enfrenta cada etapa de diseño con una etapa de pruebas y DevOps es un ciclo continuo. Elija el patrón que corresponda a cómo trabaja realmente su equipo, no el que mejor queda en una presentación.

Diagrama de flujo del modelo en cascada

Un diagrama de flujo en cascada es una sola línea vertical u horizontal: requisitos, diseño, implementación, verificación, despliegue y mantenimiento, cada uno seguido de un rombo de aprobación. Funciona cuando el alcance es cerrado y los cambios son caros, y facilita mostrar los hitos del contrato. Compárelo con el enfoque ágil en nuestra guía de ágil vs cascada.

Diagrama de flujo ágil y Scrum

Un diagrama de flujo ágil sitúa el sprint en el centro como un bucle: product backlog, sprint planning, desarrollo y pruebas dentro del sprint, sprint review con las partes interesadas y retrospectiva, y vuelta a la planificación. Las versiones salen del bucle en cuanto un incremento está listo. Los rombos de decisión son «¿cumple la definition of done?» y «¿listo para el lanzamiento?».

Diagrama de flujo del modelo en V

Un diagrama de flujo del modelo en V se dibuja como una V: requisitos, diseño del sistema, arquitectura y diseño de módulos bajan por el lado izquierdo, la programación queda en el vértice inferior y las pruebas unitarias, de integración, de sistema y de aceptación suben por el lado derecho. Unas líneas discontinuas unen cada etapa de diseño con la etapa de pruebas que la verifica, lo que hace visible la trazabilidad. Nuestra guía del modelo en V explica cuándo compensa esta estructura.

Diagrama de flujo de DevOps y CI/CD

Un diagrama de flujo de DevOps suele ser un bucle en forma de infinito o un pipeline: commit, build automatizado, pruebas automatizadas, análisis de seguridad, despliegue en staging, aprobación o promoción automática, despliegue en producción y monitorización, con comentarios que vuelven a la planificación. La mayoría de sus pasos están automatizados, así que las cajas representan etapas del pipeline más que personas. Consulte nuestra guía de CI/CD para ver cómo se implementa cada etapa.

Cómo crear un diagrama de flujo del proceso de desarrollo de software en 6 pasos

La forma más rápida de obtener un diagrama de flujo fiel es representar el proceso que realmente sigue hoy, con las personas que hacen el trabajo, y solo después mejorarlo. Dibujar primero el proceso ideal da como resultado un esquema que nadie sigue.

1. Defina el alcance y el nivel de detalle. Decida dónde empieza y dónde termina el diagrama (por ejemplo, de «solicitud de funcionalidad» a «entregada a los usuarios») y si muestra todo el ciclo de vida o una sola etapa, como las pruebas.
2. Enumere los pasos con quienes los realizan. Organice una sesión de 60 minutos con un desarrollador, un tester, un product owner y la persona que publica el código. Anote cada actividad en una tarjeta, en el orden en que realmente ocurre.
3. Añada decisiones y bucles. Para cada aprobación o control, añada un rombo con un camino «sí» y otro «no». Dibuje adónde vuelve el trabajo rechazado.
4. Asigne carriles y responsables. Agrupe los pasos en carriles por rol y asegúrese de que cada paso tenga exactamente un responsable.
5. Marque entradas, salidas y herramientas. Anote el artefacto que produce cada paso (ticket, build, informe de pruebas) y dónde se guarda, para que los traspasos sean verificables.
6. Valide, publique y revise. Recorra en el diagrama una funcionalidad real reciente, corrija lo que no coincida, guarde el esquema donde trabaja el equipo (wiki, repositorio, herramienta de proyectos) y revíselo cada trimestre o después de una incidencia importante.

Limite cada diagrama a una sola página. Si un paso necesita más detalle, conviértalo en un proceso predefinido y dibújelo en un diagrama aparte; una revisión de seguridad o un procedimiento de lanzamiento suelen merecer su propio diagrama.

Plantilla gratuita de diagrama de flujo del proceso de desarrollo de software (Mermaid)

La plantilla siguiente es un diagrama de flujo completo del proceso de desarrollo de software escrito en Mermaid, una sintaxis de diagramas en texto que se muestra automáticamente en el Markdown de GitHub y GitLab y en la mayoría de las herramientas de documentación. GitHub añadió la representación nativa de Mermaid en febrero de 2022, de modo que el diagrama puede vivir en su repositorio junto al código y cambiar mediante pull requests como cualquier otro archivo.

flowchart TD
    A([Feature requested]) --> B[Write user stories and acceptance criteria]
    B --> C{Requirements approved?}
    C -- No --> B
    C -- Yes --> D[Design: architecture, UX and UI]
    D --> E{Design approved?}
    E -- No --> D
    E -- Yes --> F[Develop and write unit tests]
    F --> G{Code review and CI passed?}
    G -- No --> F
    G -- Yes --> H[QA: integration, regression and performance tests]
    H --> I{Critical defects open?}
    I -- Yes --> F
    I -- No --> J[User acceptance testing]
    J --> K{Release accepted?}
    K -- No --> B
    K -- Yes --> L[Deploy to production]
    L --> M{Production healthy?}
    M -- No --> N[Roll back and fix]
    N --> F
    M -- Yes --> O([Released to users])
    O --> P[Monitor and collect feedback]
    P --> B

Cópiela en un bloque de código mermaid de cualquier archivo Markdown, cambie el nombre de los pasos para que coincidan con su equipo y añada carriles con bloques subgraph si necesita los roles. Para los documentos que rodean este diagrama, como la especificación, el plan de pruebas y la checklist de lanzamiento, consulte nuestra colección de plantillas para el desarrollo de software.

¿Con qué herramientas se puede dibujar un diagrama de flujo?

Cualquier herramienta de diagramas puede dibujar un diagrama de flujo del proceso de desarrollo de software; la elección adecuada depende de si el esquema es un resultado de taller, un documento vivo en el repositorio o un estándar de proceso formal. La comparativa siguiente recoge las opciones que más usan los equipos en 2026.

Una combinación práctica es usar una pizarra para el taller de mapeo y después una versión en Mermaid en el repositorio como fuente de verdad. Así el diagrama se revisa cada vez que cambia el proceso, igual que el código.

Errores frecuentes en los diagramas de flujo y cómo evitarlos

La mayoría de los diagramas de flujo de procesos de software fracasan por el mismo motivo: describen un ideal que nadie sigue, así que el equipo deja de mirarlos. Estos son los errores que vemos con más frecuencia en los diagramas de clientes y socios:

• Dibujar el ideal en lugar del proceso real: represente primero lo que ocurre hoy y marque después los cambios objetivo en otro color.
• Sin bucles de vuelta: un diagrama sin caminos «no» da a entender que las pruebas nunca fallan y que los diseños nunca se rechazan.
• Demasiado detalle en una página: más de 15 a 20 formas suele indicar que algunos pasos pertenecen a un diagrama de subproceso.
• Pasos sin responsable: una caja que pertenece «al equipo» no pertenece a nadie.
• Decisiones sin etiquetar: cada rombo necesita una pregunta y salidas etiquetadas.
• Mezclar flujo y datos: lleve el movimiento de los datos a un diagrama de flujo de datos aparte para que el proceso siga siendo legible.
• No actualizarlo nunca: revise el diagrama cada trimestre y después de cada incidencia grave o cambio de proceso.

¿Cómo debe ser el diagrama de procesos de un proveedor cuando externaliza?

Cuando externalice el desarrollo, pida al proveedor su diagrama de procesos antes de firmar y compruebe que muestra sus puntos de aprobación, los controles de calidad y cómo se gestionan los cambios. Un proveedor que no sabe dibujar su propio proceso en una página no suele tener uno repetible.

Busque estos elementos en el diagrama de un proveedor:

• Su carril: dónde aprueba los requisitos, revisa los diseños, asiste a las demos y acepta las versiones.
• Solicitudes de cambio: un camino claro para requisitos nuevos o modificados, con estimación y aprobación antes de empezar el trabajo.
• Controles de calidad: revisión de código, pruebas automatizadas y aprobación de QA antes de que nada le llegue para su aceptación.
• Lanzamiento y reversión: quién despliega, cómo se comprueba la estabilidad de producción y qué ocurre si falla una versión.
• Soporte tras el lanzamiento: cómo se notifican, priorizan y devuelven al backlog las incidencias y los errores.

Comparar en paralelo los diagramas de flujo de dos proveedores suele ser más revelador que comparar sus presentaciones. Los equipos que ofrecen ingeniería de producto de principio a fin deberían poder mostrar todo el ciclo, del descubrimiento a la monitorización, con roles designados en cada carril.

Preguntas frecuentes

Publicado el 4 de noviembre de 2026. Fuentes: ISO 5807:1985, documentation symbols and conventions for data, program and system flowcharts (en inglés); ISO/IEC 19510:2013, Business Process Model and Notation (BPMN) (en inglés); GitHub Blog, Include diagrams in your Markdown files with Mermaid (en inglés), febrero de 2022.