I cicli di vita del software: dal modello waterfall all’agile

I cicli di vita del software: dal modello waterfall all’agile

Developer code

Sviluppare un software può essere considerata oramai una forma d’arte che richiede allo stesso tempo creatività e “manualità” per portarlo a termine. Sono differenti le metodologie che si possono applicare per sviluppare un software, ma a discapito di queste e della complessità del progetto, c’è sempre uno primo step di analisi, seguito dall’inizio dello sviluppo vero e proprio. Nel corso degli anni sono nate e si son sviluppate numerose metodologie, adattandosi soprattutto alle varie necessità del cliente finale, dividendosi in 3 grandi filoni:

  • Stile iterativo, vedi Waterfall
  • Stile incrementale, vedi Spiral
  • Stile evolutivo, vedi Agile

Waterfall

Questo modello, non ha una reale e conclamata data di ideazione o un padre, poiché è l’evoluzione di un modello di sviluppo dei cicli di vita dei sistemi già in utilizzo nell’industria dell’ingegneria del software, ma possiamo affermare che Winston Royce, nel 1970, portò su carta questo processo, avendo la necessità di comprendere come gestire al meglio lo sviluppo di software di una certa complessità e dimensione. Nella sua dissertazione, che potete leggere integralmente qui, Royce informa i suoi lettori che questo modello, così semplice, è “risky and invites failure” e suggerisce azioni per perfezionarlo e migliorarlo. La sua semplice discussione però sfuggi alla carta e il modello entrò gradualmente a far parte delle metodologie di lavoro adottate all’interno delle grande industrie, affermandosi come uno dei modelli più utilizzati, tanto che nel 1986 il Dipartimento della Difesa degli Stati Uniti definì delle linee guida, uno standard, che includevano le fasi del waterfall, da seguire al momento dello sviluppo di un software soprattutto se affidato a terzi.Analisi Waterfall

Nel metodo waterfall ogni fase del ciclo della vita del prodotto si sussegue in sequenza, facendo progredire lo sviluppo come, per l’appunto, una cascata. Ogni fase prevede la produzione di un output che viene successivamente utilizzato come input della fase successiva in una concatenazione fino all’output finale da consegnare al cliente. Particolarità e tratto distintivo di questo metodo son la definizione e la programmazione di tutti i dettagli del progetto, dalle fasi al design, stabiliti precedentemente all’inizio dello sviluppo vero e proprio.

Nel modello waterfall di Royce, le fasi previste sono:

  • Produzione di un documento dove vengono definiti nel dettaglio di tutti i requisiti del software e del sistema;
  • Analisi approfondita;
  • Definizione dell’architettura del software;
  • Programmazione: sviluppo, unit testing e l’integrazione del software;
  • Fase di test per scoprire e intervenire in caso di bug;
  • Fase di installazione, migrazione, supporto e mantenimento del software al cliente.

Ogni fase può procedere verso la successiva solo se la stessa è stata revisionata, verificata e approvata. Nel corso del tempo poi son state sviluppate numerose variazioni a questo metodo, più o meno significative come il ritorno alla fase di analisi iniziale dopo la scoperta di errori o difetti o se i passaggi stabiliti risultassero insufficienti.

Il metodo però è stato accusato di avere con sé numerosi limiti che nel corso del tempo hanno fatto sì che questo metodo fosse abbandonato del tutto o in parte, adottando al suo posto altre tipologie di sviluppo:

  • Assenza di flessibilità;
  • Problematicità nella risoluzione al momento dell’insorgenza di errori;
  • L’implementazione di nuove funzionalità richiede tempi elevati;
  • Aumento considerevole dei costi.

Spiral

Questo modello nasce, tra le varie esigenze, da quella di superare il modello waterfall. Per la prima volta descritto da Barry Boehm nel 1986, potete leggerlo integralmente qui, combina particolarità del modello waterfall, dell’incremental build e del prototyping. Sviluppato per gestire il processo di software di una certa grandezza e complessità, richiedenti un notevole sforzo in termini di tempo e denaro, si orienta verso un approccio al progetto teso alla gestione dei rischi, permettendo una più ampia flessibilità da parte del team nella gestione degli stessi alla loro insorgenza, consentendo di rimanere sempre reattivi ad affrontare le sfide qualvolta si presentino. Il metodo è definito da un gruppo di 6 invarianti per ogni progetto:

  • Definire simultaneamente gli artefatti (nella programmazione, l’artefatto è qualsiasi cosa prodotta da persone coinvolte nel processo di sviluppo di un software). Programmare ogni artefatto consente di ridurre il rischio di dimenticanze o altri contrattempi.
  • Considerare la presenza in ogni ciclo a spirale dei 5 elementi principali:
    • Definire gli oggetti critici e i limiti del progetto
    • Definire prodotti e processi alternativi
    • Identificare i rischi e la loro risoluzione
    • Revisione da parte dei soggetti coinvolti
    • Iniziare il processo
  • Considerando i rischi, determinare il livello di impegno da dedicare ad ogni attività;
  • Considerando i rischi, determinare il livello di dettaglio di ogni artefatto prodotto;
  • Gestione dell’impegno dei soggetti coinvolti nel ciclo con 3 definite milestones:

.1 Life Cycle Objectives (LCO)

.2 Life Cycle Architecture (LCA)

.3 Initial Operational Capability (IOC)

  • Porre l’accento sulle attività e sugli artefatti piuttosto che sul software e sull’inizio dello sviluppo.

Spiral development

Nonostante la volontà di scostarsi e offrire una alternativa performante al modello waterfall, anche questo modello, seppur di tipo incrementale vista la ciclicità che la spirale offre dando vita ad un loop, rimane ancora fin troppo vicino al modello iterativo precedente.

Pur essendo infatti un modello estremamente flessibile, semplice da gestire e che mette al primo posto i rischi, evitando così il più possibile l’insorgenza di spiacevoli contrattempi, emergono i suoi limiti nel tempo:

  • Può divenire costoso da implementare, soprattutto se la spirale continua all’infinito;
  • Non ideale per piccoli progetti o con un impatto basso di rischio;
  • Il successo può dipendere dalla corretta e precisa analisi dei rischi;
  • La fine del progetto può essere difficile da definire;
  • La documentazione può essere estremamente complessa.

Questo metodo si rivela quindi adatto per i progetti caratterizzati da un medio-alto rischio dove l’utente finale è ancora indeciso sulle necessità che gli sono necessarie grazie alla consegna, fase per fase, del prototipo per aiutarlo a comprenderle. Richiede al contempo tempi abbastanza lunghi causa necessità di implementazioni in corso di progetto.

Agile

Che cosa vuol dire? Agile diventa l’abilità di creare, rispondere ed adattarsi al cambiamento nell’ordine di riuscire in una situazione instabile.

Metodo AgileAgile è un termine definito da molti “Ombrella” perché non è un metodo di per se stesso, ma racchiude sotto di sé differenti “variazioni” al tema agile: Scrum, XP (Extreme programming), Crystal, FDD (Feature Driven Development) e DSDM (Dynamic Systems Development Method). Ognuna di queste pratiche ha un approccio leggermente diverso l’uno dall’altro, adattandosi anche a come funzionano e si comportano gli oggetti nei vari linguaggi di programmazione.

Il metodo nasce dall’esigenza di un gruppo di 17 ingegneri che iniziarono a riunirsi informalmente per discutere le problematiche che dovevano affrontare ogni giorno durante lo sviluppo dei software, per trovare un nuovo metodo che rendesse il progetto di sviluppo più flessibile, riducendo tempistiche e documentazione necessaria che erano soliti caratterizzare gli altri metodi. “We were looking for something that was more timely and responsive”, queste le parole di Jon Kern, un ingegnere aerospaziale facente parte del gruppo, agli inizi degli anni ’90.  Nel 2001 il gruppo si riunì in Utah (USA), l’obiettivo era trovare una soluzione che consentisse agli ingegneri di sviluppare più velocemente il software e consegnarlo nelle mani degli utenti finali per un feedback da cui prendere le direzioni e migliorare il prodotto. Stilarono per questo un manifesto in 12 punti (consultabile qui) che riassume al suo interno i valori e i principi sui quali si fonda il metodo: Agile è puntare ad avere massima priorità nello soddisfare il cliente rilasciando in modo continuativo un software efficiente sin da subito, accogliendo con intraprendenza i cambiamenti e lavorando fianco a fianco con i clienti per tutta la durata del progetto con continui incontri e discussioni, dove comunque la semplicità rimane il punto essenziale.Agile Development Software

Riassumendo per punti:

  • Le persone e le interazioni piuttosto che processi e strumenti;
  • Un software che funzioni piuttosto che una documentazione esaustiva;
  • Collaborazione con il cliente piuttosto che la negoziazione del contratto;
  • Rispondere ai cambiamenti invece che seguire un piano.

Il punto che rimane fisso è il cambiamento, mentre metodi come il waterfall prevedono l’applicazione di specifiche e passaggi rigidi, l’agile accoglie la possibilità, anzi la normalità, del subentro e dell’insorgenza di necessarie modifiche e cambiamenti in corso d’opera. Dare al cliente la possibilità al cliente, ma anche al team di sviluppo stesso, di accettare dei cambiamenti, può portare ad avere costi minori dell’assicurare e sviluppare dettagli e richieste che non sono state previste nel progetto iniziale.

Agile quindi porta a cambiare completamente il modo in cui si lavora, in cui i membri di un team si rapportano l’uno con l’altro e il modo in cui il cliente viene incluso nel progetto, perché grazie ad un costante feedback che provvede a fornire agli sviluppatori, lui stesso entra a far parte del team. Si passa infatti dalla gestione delle proprie attività e alla consegna di un software fatto e finito, al gestire le esigenze e le necessità che sorgono, potendo consegnare al cliente di volta in volta la versione del software più aggiornata e migliorata.

Da una ricerca del 2009 indetta da Forrester Research, mostra come le metodologie Agile si stiano affermando come le più adottate rispetto a quelle più propriamente iterative e tradizionali.

Forrester Research

Flessibilità e cambiamento si attestano quindi essere le parole chiave di uno sviluppo sempre più efficiente nel futuro dei software.

Per sviluppare MayAPP, il nostro software web dedicato alla gestione del tempo delle consulenze, abbiamo deciso di adottare una metodologia mista che ci consentisse di creare un software con delle solide e sicure basi, procedendo quindi con una iniziale fase di analisi delle necessarie implementazioni e delle funzionalità core del prodotto, ma allo stesso tempo lasciando lasco per le richieste e le necessità di miglioramento che provengono in primis dai nostri clienti.

Lascia una risposta

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *