Diagramma di flusso del processo di sviluppo software: fasi, simboli, esempi e un modello gratuito

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Un diagramma di flusso del processo di sviluppo software trasforma una sequenza che di solito vive nella testa delle persone in un’immagine che chiunque capisce in un minuto. Mostra quale passo viene prima, chi ne è responsabile, dove si prende una decisione e cosa succede quando una revisione o un test fallisce. A un nuovo collega spiega come si lavora. A un cliente indica dove dovrà approvare qualcosa. A un manager rivela i passaggi di consegne in cui il lavoro tende a bloccarsi.

Nei progetti per i clienti disegniamo questo diagramma nella prima settimana, perché è il modo più rapido per concordare come si svolgerà il processo di sviluppo software su misura: quando i requisiti vengono congelati, chi approva i design, cosa significa «completato» per uno sprint e come un rilascio arriva in produzione. Un diagramma di flusso dello sviluppo software è anche il documento che tutti guardano quando qualcosa va storto, perché mostra quale gate è stato saltato.

Questa guida spiega cos’è un diagramma di flusso dello sviluppo software, ripercorre le fasi standard e i punti di decisione, elenca i simboli necessari e mostra schemi pronti per flussi a corsie, a cascata, agili, a V e DevOps. Si chiude con un metodo in sei passi, un modello Mermaid pronto da copiare, un confronto tra strumenti e le risposte alle domande più frequenti.

Che cos’è un diagramma di flusso del processo di sviluppo software?

Un diagramma di flusso del processo di sviluppo software è uno schema che rappresenta le fasi di realizzazione di un software come forme collegate: rettangoli per le attività, rombi per le decisioni, frecce per l’ordine del lavoro e forme arrotondate per l’inizio e la fine. Descrive il processo, non il codice, e risponde quindi alla domanda: «come passa il nostro team da un’idea a un software funzionante?».

Il formato è antico. Gli ingegneri industriali Frank e Lillian Gilbreth presentarono i loro «process charts» all’American Society of Mechanical Engineers nel 1921, e i simboli dei diagrammi di flusso usati in informatica sono stati standardizzati nella norma ISO 5807, pubblicata nel 1985. I team software hanno adottato questo linguaggio visivo perché è semplice: quasi chiunque sa leggere uno schema a riquadri e frecce senza formazione.

Un buon diagramma di flusso dello sviluppo software svolge tre compiti contemporaneamente:

• Stabilisce l’ordine del lavoro: requisiti prima della progettazione, progettazione prima della realizzazione, test prima del rilascio.
• Nomina i responsabili: ogni passo ha una sola persona o un solo ruolo che ne risponde.
• Rende esplicite le decisioni: approvazioni, controlli di qualità e punti go/no-go sono disegnati come rombi con un percorso «sì» e uno «no».

Diagramma di flusso, diagramma di processo e diagramma di flusso dei dati

I tre termini sono collegati ma descrivono cose diverse, e confonderli porta a schemi che vogliono mostrare tutto e non spiegano niente.

Per rappresentare il modo in cui il vostro team costruisce software basta quasi sempre un diagramma di flusso o un diagramma di processo a corsie. Ricorrete al BPMN, standardizzato come ISO/IEC 19510 nel 2013, solo quando lo schema deve guidare un motore di workflow o seguire uno standard aziendale formale.

Il flusso standard del processo di sviluppo software, passo dopo passo

La maggior parte dei diagrammi di flusso del processo di sviluppo software segue la stessa ossatura di otto fasi, qualunque sia la metodologia: idea, requisiti, progettazione, sviluppo, test, collaudo, rilascio e manutenzione. La metodologia cambia quante volte si percorrono queste fasi e quanto è grande ogni passaggio, non le fasi stesse. La tabella seguente è il flusso di riferimento da cui partiamo nei nuovi progetti.

Ogni «no» a un gate è una freccia verso una fase precedente, ed è proprio disegnare questi cicli che distingue un diagramma utile da un semplice elenco di fasi. Un test fallito torna allo sviluppo, un design respinto torna alla progettazione e un incidente in produzione crea una nuova voce nel backlog. Per la teoria dietro queste fasi, la nostra guida al ciclo di vita dello sviluppo software approfondisce ogni fase e i modelli SDLC classici.

I punti di decisione che ogni diagramma dovrebbe mostrare

I rombi decisionali contengono più informazioni dei riquadri, perché mostrano dove il lavoro può fermarsi. Cinque gate compaiono in quasi tutti i processi software sani:

1. Approvazione dei requisiti: il referente di business conferma perimetro e criteri di accettazione prima che inizi la progettazione.
2. Approvazione del design: architettura e UX vengono riviste perché le modifiche costose avvengano sulla carta e non nel codice.
3. Code review e controllo CI: nessuna modifica viene integrata senza un secondo paio d’occhi e una build automatica verde.
4. Prontezza al rilascio: i test sono completati, non restano difetti critici aperti ed esiste un piano di rollback.
5. Verifica dopo il rilascio: il monitoraggio conferma che il rilascio è stabile; in caso contrario il team esegue il rollback o un hotfix.

Il collaudo merita un rombo a sé, perché è l’unico gate che appartiene al cliente e non al team. Il nostro approfondimento sullo user acceptance testing spiega come condurlo perché l’approvazione sia una formalità e non una sorpresa.

Quali simboli servono in un diagramma di flusso?

Per disegnare un diagramma di flusso chiaro del processo di sviluppo software bastano sei o sette simboli; il resto del set ISO 5807 è raramente utile per le mappe di processo. Un vocabolario ridotto mantiene lo schema leggibile anche per chi non è tecnico.

Le frecce puntano sempre nella direzione del lavoro e ogni rombo decisionale ha bisogno di uscite etichettate. Una freccia senza etichetta che esce da un rombo è il motivo più comune per cui un diagramma di flusso viene letto male.

Diagramma di flusso a corsie: chi fa cosa nello sviluppo software?

Un diagramma di flusso a corsie (swimlane) divide lo schema in fasce orizzontali o verticali, una per ruolo, così si vede chi è responsabile di ogni passo e dove il lavoro passa di mano. È il formato più utile per i team software, perché la maggior parte dei ritardi avviene nei passaggi di consegne, non all’interno di un passo.

Un tipico diagramma a corsie dello sviluppo software ha cinque o sei corsie:

Ogni freccia che passa da una corsia all’altra è un passaggio di consegne, e ognuno ha bisogno di un innesco chiaro («story spostata in Ready for QA») e di un artefatto (una build, un ticket, un documento). Se gestite il lavoro in Jira, fate corrispondere corsie e stati alla vostra board, così schema e strumento raccontano la stessa storia; la nostra guida al workflow Jira mostra una configurazione che rispecchia questo flusso.

Esempi di diagramma di flusso del processo di sviluppo software per modello

La forma del diagramma dipende dal modello di sviluppo: la cascata è una linea retta con gate, l’agile è un ciclo, il modello a V affianca a ogni fase di progettazione una fase di test e il DevOps è un ciclo continuo. Scegliete lo schema che corrisponde al modo in cui il vostro team lavora davvero, non quello che rende meglio su una slide.

Diagramma di flusso a cascata

Un diagramma a cascata è un’unica linea verticale o orizzontale: requisiti, progettazione, implementazione, verifica, rilascio e manutenzione, ciascuna seguita da un rombo di approvazione. Funziona quando il perimetro è fisso e le modifiche sono costose, e rende facili da mostrare le milestone contrattuali. La nostra guida allo sviluppo software a cascata spiega quando questo modello è adatto.

Diagramma di flusso agile e Scrum

Un diagramma agile mette lo sprint al centro come ciclo: product backlog, sprint planning, sviluppo e test durante lo sprint, sprint review con gli stakeholder e retrospettiva, poi di nuovo la pianificazione. I rilasci escono dal ciclo appena un incremento è pronto. I rombi decisionali sono «rispetta la definition of done?» e «pronto per il rilascio?».

Diagramma di flusso del modello a V

Un diagramma del modello a V si disegna come una V: requisiti, progettazione di sistema, architettura e progettazione dei moduli scendono lungo il braccio sinistro, la programmazione sta in basso e i test unitari, di integrazione, di sistema e di accettazione risalgono il braccio destro. Linee tratteggiate collegano ogni fase di progettazione alla fase di test che la verifica, rendendo visibile la tracciabilità. La nostra guida al modello a V spiega quando questa struttura conviene.

Diagramma di flusso DevOps e CI/CD

Un diagramma DevOps è di solito un ciclo a forma di infinito o una pipeline: commit, build automatica, test automatici, scansione di sicurezza, rilascio in staging, approvazione o promozione automatica, rilascio in produzione e monitoraggio, con il feedback che torna alla pianificazione. Quasi tutti i passi sono automatizzati, quindi i riquadri rappresentano fasi della pipeline più che persone. Consultate la nostra guida CI/CD per l’implementazione di ogni fase.

Come creare un diagramma di flusso del processo di sviluppo software in 6 passi

Il modo più rapido per ottenere un diagramma accurato è mappare il processo che seguite davvero oggi, insieme a chi fa il lavoro, e solo dopo migliorarlo. Disegnare prima il processo ideale produce uno schema che nessuno segue.

1. Definite perimetro e livello di dettaglio. Decidete dove inizia e finisce lo schema (ad esempio da «richiesta di funzionalità» a «rilasciata agli utenti») e se copre l’intero ciclo di vita o una sola fase, come i test.
2. Elencate i passi con chi li svolge. Organizzate una sessione di 60 minuti con uno sviluppatore, un tester, un product owner e chi rilascia il codice. Scrivete ogni attività su una scheda, nell’ordine in cui avviene davvero.
3. Aggiungete decisioni e cicli. Per ogni approvazione o controllo aggiungete un rombo con un percorso «sì» e uno «no». Disegnate dove torna il lavoro respinto.
4. Assegnate corsie e responsabili. Raggruppate i passi in corsie per ruolo e verificate che ogni passo abbia esattamente un responsabile.
5. Segnate input, output e strumenti. Annotate l’artefatto prodotto da ogni passo (ticket, build, report di test) e dove si trova, così i passaggi di consegne sono verificabili.
6. Validate, pubblicate e rivedete. Ripercorrete sullo schema una funzionalità recente, correggete ciò che non torna, conservate il diagramma dove lavora il team (wiki, repository, strumento di progetto) e rivedetelo ogni trimestre o dopo un incidente importante.

Limitate ogni schema a una sola pagina. Se un passo richiede più dettaglio, trasformatelo in un processo predefinito e disegnatelo in uno schema separato; una revisione di sicurezza o una procedura di rilascio meritano di solito un diagramma proprio.

Modello gratuito di diagramma di flusso dello sviluppo software (Mermaid)

Il modello qui sotto è un diagramma completo del processo di sviluppo software scritto in Mermaid, una sintassi testuale per diagrammi che viene visualizzata automaticamente nel Markdown di GitHub e GitLab e nella maggior parte degli strumenti di documentazione. GitHub ha introdotto il rendering nativo di Mermaid nel febbraio 2022, quindi il diagramma può vivere nel repository accanto al codice ed evolvere tramite pull request come qualsiasi altro file.

flowchart TD
    A([Funzionalità richiesta]) --> B[Scrivere user story e criteri di accettazione]
    B --> C{Requisiti approvati?}
    C -- No --> B
    C -- Sì --> D[Progettazione: architettura, UX e UI]
    D --> E{Design approvato?}
    E -- No --> D
    E -- Sì --> F[Sviluppare e scrivere i test unitari]
    F --> G{Code review e CI superate?}
    G -- No --> F
    G -- Sì --> H[QA: test di integrazione, regressione e prestazioni]
    H --> I{Difetti critici aperti?}
    I -- Sì --> F
    I -- No --> J[User acceptance testing]
    J --> K{Rilascio accettato?}
    K -- No --> B
    K -- Sì --> L[Rilascio in produzione]
    L --> M{Produzione stabile?}
    M -- No --> N[Rollback e correzione]
    N --> F
    M -- Sì --> O([Rilasciata agli utenti])
    O --> P[Monitorare e raccogliere feedback]
    P --> B

Copiatelo in un blocco di codice mermaid di qualsiasi file Markdown, rinominate i passi in base al vostro team e aggiungete le corsie con blocchi subgraph se vi servono i ruoli. Per i documenti che accompagnano questo schema, come specifica, piano di test e checklist di rilascio, consultate la nostra raccolta di modelli per lo sviluppo software.

Con quali strumenti disegnare un diagramma di flusso?

Qualsiasi strumento di diagrammi può disegnare un diagramma di flusso del processo di sviluppo software; la scelta giusta dipende dal fatto che lo schema sia il risultato di un workshop, un documento vivo nel repository o uno standard di processo formale. Il confronto copre le opzioni più usate dai team nel 2026.

Una combinazione pratica è una lavagna per il workshop di mappatura e poi una versione Mermaid nel repository come fonte di verità. Così lo schema viene rivisto a ogni modifica del processo, esattamente come il codice.

Errori comuni nei diagrammi di flusso e come evitarli

La maggior parte dei diagrammi di processo software fallisce per lo stesso motivo: descrive un ideale che nessuno segue, quindi il team smette di guardarli. Questi sono gli errori che vediamo più spesso negli schemi di clienti e partner:

• Disegnare l’ideale invece del processo reale: mappate prima ciò che succede oggi, poi segnate le modifiche desiderate in un altro colore.
• Nessun ciclo di ritorno: uno schema senza percorsi «no» lascia intendere che i test non falliscano mai e che i design non vengano mai respinti.
• Troppi dettagli in una pagina: oltre 15-20 forme di solito significa che alcuni passi appartengono a un sottoprocesso.
• Passi senza responsabile: un riquadro che appartiene «al team» non appartiene a nessuno.
• Decisioni senza etichette: ogni rombo ha bisogno di una domanda e di uscite etichettate.
• Mescolare flusso e dati: mettete il movimento dei dati in un diagramma di flusso dei dati separato, così il processo resta leggibile.
• Non aggiornarlo mai: rivedete lo schema ogni trimestre e dopo ogni incidente serio o cambio di processo.

Come dovrebbe essere il diagramma di processo di un fornitore quando esternalizzate?

Quando esternalizzate lo sviluppo, chiedete al fornitore il suo diagramma di processo prima di firmare e verificate che mostri i vostri punti di approvazione, i gate di qualità e la gestione delle modifiche. Un fornitore che non sa disegnare il proprio processo in una pagina di solito non ne ha uno ripetibile.

Cercate questi elementi nello schema di un fornitore:

• La vostra corsia: dove approvate i requisiti, rivedete i design, partecipate alle demo e accettate i rilasci.
• Richieste di modifica: un percorso chiaro per requisiti nuovi o modificati, con stima e approvazione prima dell’inizio del lavoro.
• Gate di qualità: code review, test automatici e approvazione QA prima che qualcosa vi arrivi per il collaudo.
• Rilascio e rollback: chi rilascia, come si verifica la stabilità della produzione e cosa succede se un rilascio fallisce.
• Supporto dopo il lancio: come incidenti e bug vengono segnalati, prioritizzati e reinseriti nel backlog.

Confrontare fianco a fianco i diagrammi di due fornitori è spesso più rivelatore che confrontare le loro presentazioni. I team che offrono product engineering end-to-end dovrebbero poter mostrare l’intero ciclo, dalla discovery al monitoraggio, con ruoli nominati in ogni corsia.

Domande frequenti

Pubblicato il 4 novembre 2026. Fonti: ISO 5807:1985, simboli e convenzioni per diagrammi di flusso di dati, programmi e sistemi; ISO/IEC 19510:2013, Business Process Model and Notation (BPMN); GitHub Blog, Include diagrams in your Markdown files with Mermaid (febbraio 2022).