definition backgroundWaterfall model: i segreti della metodologia di project software

Waterfall model: i segreti della metodologia di project software

Da Giorgia Frezza
Il 11/02/21

Ogni progetto può essere diviso in due fasi chiave: pianificazione ed esecuzione. Tuttavia, durante queste due fasi, la metodologia di project management impiegata gioca un ruolo chiave sul risultato finale.

Il waterfall model, un metodo per gestire i progetti in modo lineare, è una delle opzioni che le aziende hanno per elaborare e organizzare il lavoro. Anche se rispetto ad altre metodologie, come quella Scrum, il waterfall model si rivela più datato la verità, presenta, tuttavia, ancora vantaggi innegabili.

In questo articolo, Appvizer esamina i principi di questo metodo e i vantaggi che possono derivare dalla sua corretta applicazione.

Cos’è il waterfall model?

Origini

Il waterfall model (il modello a cascata), documentato nel 1970 da Royce, è stato il primo modello di product life cycle documentato pubblicamente. Il modello a cascata è una versione divenuta popolare del modello del ciclo di vita di sviluppo dei sistemi alla base dell'ingegneria del software.

Definizione

Il waterfall process è stato il primo process model ad essere introdotto. Si riferisce anche a un modello di product life cycle lineare/sequenziale. È molto semplice da capire e usare. In un waterfall approach, ogni fase deve essere completata completamente prima che la fase successiva possa iniziare. Questo tipo di modello di sviluppo del prodotto è usato fondamentalmente per un progetto piccolo o con requisiti certi.

Alla fine di ogni fase, ha luogo una revisione per determinare se il progetto è sulla strada giusta o ha bisogna di essere corretto.

In questo modello il test del prodotto inizia solo dopo che lo sviluppo è completo. Nel waterfall approach le fasi non si sovrappongono.

Le fasi del waterfall model

Il waterfall model è strutturato in diversi fasi.

waterfall-model©labs.sogeti.com

Cercheremo di capire il concetto di waterfall process con l'esempio di un’applicazione bancaria per illustrare l'argomento.

Supponiamo che la Citibank stia pianificando lo sviluppo di una nuova applicazione bancaria e che si sia rivolta alla vostra organizzazione.

Raccolta e analysis requirements (analisi dei requisiti)

In questa fase i requirements sono raccolti dal business analyst e sono analizzati dal team. I requirements sono documentati durante questa fase e possono essere richiesti chiarimenti.

I business analyst documentano i requirements in base alla loro discussione con il cliente.

Nel nostro caso, dopo un’attenta analisi, si è scoperto che il project team ha bisogno di risposte alle seguenti domande:

  • La nuova applicazione bancaria sarà usata in più di un paese?
  • Dobbiamo supportare più lingue?
  • Quanti utenti ci si aspetta che usino l'applicazione? ecc.

System design (progettazione del sistema)

L'architetto e i membri senior del team lavorano sul product modelling (l’architettura del prodotto), sul design di alto/basso livello del progetto.

Si decide che l'applicazione bancaria deve avere capacità di backup e failover in modo che il sistema sia accessibile in ogni momento.

L'architetto crea i diagrammi dell'architettura e i documenti di progettazione di alto / basso livello.

Implementazione

Il development team (team di sviluppo) lavora alla codifica del progetto, prendendo come riferimento i design models (i documenti di design) e assicurandosi che la loro soluzione segua il design finalizzato dall'architetto.

Poiché si tratta di un'applicazione bancaria e la sicurezza è un'alta priorità nei suoi requisiti, il development team implementa diversi controlli di sicurezza e audit logging features nell'applicazione.

Eseguono anche diverse altre attività: per esempio, uno sviluppatore senior che rivede il codice degli altri sviluppatori per qualsiasi problema. Alcuni sviluppatori eseguono anche l'analisi statica del codice.

Testing phase

Il team di test testa l'applicazione completa e identifica qualsiasi difetto nell'applicazione.

Questi difetti sono corretti dagli sviluppatori e il team di test controllo di nuovo le correzioni per assicurarsi che il difetto sia stato corretto.

Eseguono anche test di regressione dell'applicazione per vedere se sono stati introdotti nuovi difetti.

Anche i tester con conoscenza del settore bancario sono stati assunti per il progetto in modo da poter testare l'applicazione che opererà nell’ambito bancario.

I security testing teams vengono chiamati a testare la sicurezza dell'applicazione bancaria.

Deployment

Il team costruisce e installa l'applicazione sui server che sono stati procurati per l'applicazione bancaria.

Alcune delle attività di alto livello includono l'installazione del sistema operativo sui server, l'installazione delle patch di sicurezza, l'irrigidimento dei server, l'installazione dei server web e dei server applicativi, l'installazione del database ecc.

Si coordinano anche con i team amministrativi di rete e IT ecc. per ottenere finalmente l'applicazione attiva e funzionante sui server di produzione.

Manutenzione

Durante la fase di manutenzione, il team si assicura che l'applicazione funzioni sui server senza problemi e senza alcun tempo di inattività.

I problemi che vengono segnalati dopo la messa in funzione vengono risolti dal development team e testati dal team di test.

Esempi di waterfall model

Agli inizi, il waterfall model era usato per sviluppare applicazioni aziendali come software di customer relation management (gestione delle relazioni con i clienti), software di human resource management, software di gestione della supply chain, sistema di gestione dell'inventario, sistema di punti vendita (POS) per catene di vendita al dettaglio, ecc.

Il waterfall model è stato usato significativamente nello sviluppo dei product fino all'anno 2000. Anche dopo la pubblicazione del manifesto Agile nel 2001, il modello Waterfall ha continuato ad essere usato da molte organizzazioni fino all'ultimo decennio.

In questi giorni la maggior parte dei progetti segue la metodologia Agile o qualche altra forma di modello iterativo a seconda del requisito specifico del progetto.

Tuttavia, ci sono alcune aree in cui il waterfall model ha continuato ad essere preferito:

  • il settore development del Dipartimento della Difesa (DOD), dei programmi militari e aerei,a causa dei severi standard e requisiti che devono essere seguiti. In tali industrie, i requisiti sono noti con largo anticipo e i contratti sono molto specifici sulla delivery del progetto.
  • il settore bancario, come abbiamo visto nell’esempio
  • la sanità
  • il sistema di controllo degli impianti nucleari

Waterfall model: i vantaggi

Applicare ai vostri progetti software di pianificazione e project management come il Waterfall model comporta diversi vantaggi.

1. Strutturare il lavoro

Il waterfall model si concentra su un insieme preciso e definito di fasi, che porta alla realizzazione di una chiara struttura di lavoro. I team devono completare un'intera fase prima di passare a quella successiva. Quindi, se ci sono ostacoli al completamento, sono immediatamente visibili.

2. Follow-up semplificato

Questo metodo permette di visualizzare la progressione del progetto in modo chiaro e intuitivo. Questo significa anche che non è richiesta alcuna certificazione o formazione specifica a livello di Project Management.

3. Chiarezza degli obiettivi

La chiara determinazione degli obiettivi da raggiungere fin dall'inizio è una delle caratteristiche del waterfall model. Questo fornisce chiarezza ai team e permette loro di lavorare in modo mirato, avendo sempre presente in ogni momento l'obiettivo finale.

4. Migliore comunicazione e tracciabilità

L'approccio Waterfall è, per definizione, metodico. Questo significa che si basa su processi standardizzati, che promuovono una comunicazione efficiente e accurata delle informazioni. Per il corretto sviluppo di ogni fase del progetto, il trasferimento di informazioni deve essere fatto in modo preciso e documentato.

Waterfall model: gli svantaggi

Nonostante i benefici di questo processo, questo metodo è stato messo in discussione a causa di aspetti che potrebbero causare problemi di conformità come:

  • Difficoltà nell’apportare cambiamenti. La metodologia, nella sua forma tradizionale, non lascia quasi mai spazio a cambiamenti o revisioni inaspettate. Un cambiamento improvviso dei parametri del progetto potrebbe rendere inutile gran parte del lavoro che avete fatto fino a quel punto, con un conseguente ritardo delle deadline.
  • Esclusione del cliente o dell’utente finale. Essendo un processo interno, la metodologia Waterfall si concentra poco sull'utente finale o sul cliente coinvolto in un progetto. I clienti spesso vogliono essere coinvolti durante un progetto, aggiungendo opinioni e chiarendo ciò che vogliono.
  • Testing phase alla fine del progetto. Lasciare la fase di test per ultima è rischioso. Il progetto ha probabilmente richiesto molto tempo per essere completato, quindi grandi revisioni potrebbero causare ritardi significativi.

Ora che conoscete nel dettaglio il funzionamento del waterfall model, potrete confrontarle con le altre metodologie e stabilire quale può essere più utile per gestire la vostra azienda e i vostri progetti. Diteci quale preferite nei commenti.

La trasparenza è un valore fondamentale per Appvizer. Come media company, il nostro obiettivo è quello di fornire ai nostri lettori un contenuto utile e di qualità, che al tempo stesso permetta ad Appvizer di vivere di questo contenuto. Ecco perché ti invitiamo a scoprire il nostro business model.   Per saperne di più