Ciclo di sviluppo del software a cascata

Il modello a cascata è un approccio classico, diffuso e lineare al ciclo di sviluppo del software. Definisce una sequenza di fasi, ciascuna con obiettivi chiari. Come l’acqua che scende lungo un pendio, il modello prevede di procedere sempre in avanti.

L’approccio a cascata è rigido e lascia poco spazio alle revisioni. I test costituiscono una fase separata, anziché accompagnare lo sviluppo in modo continuo. Di conseguenza, il modello non permette di rilevare i difetti nelle prime fasi dello sviluppo.

Apri il diagramma a grandezza naturale ↗

Ciclo di sviluppo del software a cascata

Le fasi seguono questo ordine:

1. Raccolta dei requisiti. Raccogliete i requisiti del cliente e preparate la documentazione necessaria.
2. Progettazione del sistema. Partite dai requisiti per definire l’architettura e le esigenze hardware e software del sistema.
3. Implementazione. Iniziate a scrivere il codice in base al progetto. Dividete il programma in unità piccole e indipendenti, verificate ciascuna in base alle sue specifiche e poi integratele per ottenere il sistema completo.
4. Test di integrazione. Riunite le unità già testate e verificate l’intero sistema per individuare eventuali difetti.
5. Distribuzione. Correggete i difetti emersi durante i test di integrazione e ripetete i test per verificare che siano risolti. A quel punto il sistema è pronto per il lancio sul mercato e per la distribuzione nell’ambiente del cliente.
6. Manutenzione. Pubblicate correzioni o nuove versioni per risolvere i difetti e i problemi rilevati dopo la consegna.

Le fasi si susseguono a cascata. Una fase inizia solo quando la precedente si è conclusa con successo.

Usate il modello a cascata quando i requisiti sono chiari, il prodotto è stabile e ogni fase dispone di risorse sufficienti. In pratica, riservatelo ai progetti piccoli e facili da gestire. Evitatelo quando i requisiti comportano un rischio medio o alto.

Specifica e analisi dei requisiti

Lo sviluppo del software dipende dalla qualità con cui si raccolgono e documentano i requisiti. Il lavoro di individuazione e documentazione prende il nome di specifica e analisi dei requisiti.

Il cliente, il gruppo di gestione e il supporto tecnico discutono i requisiti in dettaglio. Li analizzano, li riesaminano e li documentano fino a renderli chiari e completi.

Apri il diagramma a grandezza naturale ↗

Specifica dei requisiti utente

Usate il formato richiesto dall’azienda, per esempio documenti Word, diagrammi di flusso o disegni. Il risultato descrive nel dettaglio ciò che il cliente desidera e aiuta il team a comprenderlo correttamente. Un difetto è qualsiasi difformità rispetto ai requisiti del cliente. Raccogliere requisiti sbagliati porta il progetto fuori strada fin dall’inizio.

Specifica dei requisiti utente

Questo documento non tecnico descrive le aspettative degli utenti e le loro esigenze aziendali. Lo redigono gli utenti finali e i requisiti in esso contenuti vengono verificati durante i test di accettazione utente. Il documento costituisce la base per le attività successive sui requisiti e per la progettazione del sistema.

Specifica dei requisiti software

La specifica dei requisiti software (SRS) definisce come gli utenti vogliono che funzioni il software. Serve a:

• Registrare l’accordo tra cliente e fornitore sulle funzionalità dettagliate del software.
• Fornire la base per la progettazione del software.
• Semplificare lo sviluppo e i test grazie a requisiti chiari.
• Agevolare la pianificazione delle attività e la stima dei costi.
• Fornire la base per la verifica e la convalida.

Apri il diagramma a grandezza naturale ↗

Specifica dei requisiti software

Progettazione del software

La progettazione del software si articola su due livelli:

• Progettazione software di alto livello
• Progettazione software di dettaglio

Apri il diagramma a grandezza naturale ↗

Progettazione del software

Progettazione software di alto livello

La progettazione di alto livello (HLD) descrive la struttura della base di dati e l’architettura funzionale. Orienta gli sviluppatori e risponde alle loro domande sulla struttura del progetto. Prima di preparare la HLD occorre una SRS chiara.

Progettazione software di dettaglio

La progettazione di dettaglio, o di basso livello (LLD), divide la HLD in parti più piccole e registra la logica che costituisce la specifica del programma. Fornisce informazioni dettagliate sul sistema e richiede che la HLD sia pronta.

Metodi di progettazione del software

La progettazione può seguire uno dei due approcci:

• Progettazione top-down
• Progettazione bottom-up

Approccio di progettazione top-down

La progettazione top-down parte da una visione d’insieme del sistema e rimanda i dettagli dei sottosistemi. Passate in rassegna ciascun sottosistema e definitelo in modo sempre più preciso, fino a raggiungere gli elementi di base.

Approccio di progettazione bottom-up

La progettazione bottom-up parte da elementi di base definiti in ogni dettaglio. Uniteli in sottosistemi e poi combinate i sottosistemi fino a formare il sistema completo. Immaginate di piantare un seme che a poco a poco diventa un albero.