Lo sviluppo di nuovi software rappresenta una grande sfida per tutti i soggetti coinvolti. Più è complessa l'applicazione da sviluppare, più è difficile rendere chiaro e controllabile il processo di sviluppo nella sua complessità. Per questo, di solito ci si affida a speciali piani passo per passo, noti anche come modelli procedurali. Essi suddividono l'intero processo di sviluppo in diverse fasi chiare, che sono limitate nel tempo e nel contenuto. Uno dei modelli più noti, concepito soprattutto per ridurre i rischi, è il cosiddetto modello a spirale del 1986.
Dopo aver esposto per la prima volta il suo concetto per lo sviluppo di applicazioni complesse nel 1986, nel 1988 l'ingegnere di software americano Barry W. Boehm con il libro A Spiral Model of Software Development and Enhancement pubblicò il suo modello collocandolo in un contesto più ampio. Nella pubblicazione descrive il modello a spirale come una possibile alternativa al modello a cascata affermato fino a quel momento e che è servito anche come base di esperienza. Diversamente da quanto avviene nel modello a cascata, il modello a spirale non presuppone che le operazioni per lo sviluppo di software siano lineari, ma le intende come operazioni iterative. Nel modello a spirale, quindi, le fasi non vengono eseguite passo dopo passo, ma più volte, a spirale, appunto. Sebbene con questa ripetizione ciclica il progetto sia relativamente lento ad avvicinarsi agli obiettivi fissati, i controlli regolari riducono al minimo il rischio di fallimento del processo di sviluppo.
Modello a spirale: il modello a spirale è un modello procedurale per lo sviluppo di software concepito da Barry W. Boehm nel 1986. Esso presuppone che lo sviluppo di applicazioni sia un ciclo iterativo che viene ripetuto fino al raggiungimento dell'obiettivo prefissato. Valutando regolarmente i rischi e ispezionando periodicamente il prodotto intermedio, il modello a spirale riduce al minimo il rischio di fallimento dei grandi progetti software.
I problemi nel processo di sviluppo possono avere effetti molto diversi sul progetto complessivo. Bisogna sempre fare i conti con costi che crescono, impegno maggiore del previsto e ritardi nella release: fattori che possono presto trasformarsi in un problema di sostentamento, soprattutto per le piccole imprese. Con il suo approccio incrementale e iterativo, che include anche la valutazione periodica dei rischi sotto forma dibozze di prototipi, analisi o simulazioni, il modello a spirale dovrebbe prevenire tali scenari o almeno mitigarne le conseguenze negative. Fino allo stato finale, il progetto di software viene sottoposto continuamente al ciclo del modello a spirale, che comprende sostanzialmente i seguenti quattro passaggi:
Un ciclo tipico nel modello a spirale inizia con la valutazione di quali obiettivi devono essere associati ai singoli passaggi dello sviluppo del software. Può trattarsi, ad esempio, del miglioramento delle prestazioni o dello sviluppo di funzionalità. Allo stesso tempo, è importante definire alternative per l'implementazione (ad esempio progetto A vs progetto B) e determinare le condizioni generali, i costi o il dispendio in termini di tempo.
Il passaggio successivo consiste nella valutazione delle alternative: in questa fase la definizione degli obiettivi e le condizioni fungono da punti di riferimento cruciali. In questa fase del ciclo del modello a spirale, vengono identificati i dubbi che rappresentano un rischio significativo per l'avanzamento del progetto di software. Si passa quindi allo sviluppo della strategia più a basso rischio e più economica, utilizzando metodi come prototipazione, simulazioni, test di riferimento, modelli di analisi e sondaggi tra gli utenti.
Dopo l'analisi dei rischi, si prosegue con l'effettivo sviluppo del software, sebbene questa fase sia sempre caratterizzata dai relativi rischi residui. Se, ad esempio, i rischi relativi alle prestazioni o all'interfaccia utente o al controllo dell'interfaccia interna hanno un peso molto importante sul processo di sviluppo, l'opzione da prediligere è una strategia di sviluppo evolutiva che specifichi il progetto in modo più preciso e ottimizzi i prototipi. Il codice effettivo viene scritto e testato più volte fino a raggiungere il risultato desiderato, che serve quindi come base a basso rischio per le ulteriori fasi di sviluppo.
Concluso un ciclo, inizia già la pianificazione del ciclo successivo. Da un lato, se l'obiettivo di un ciclo è stato raggiunto, può trattarsi della normale continuazione del progetto con il passaggio all'obiettivo successivo. Dall'altro, se il precedente passaggio di sviluppo fosse risultatodifettoso, può anche trattarsi della ricerca di soluzioni. Così, ad esempio, la strategia precedente può essere sostituita da una delle alternative definite precedentemente o da una nuova alternativa. A questo punto è quindi possibile fare un nuovo tentativo per raggiungere l'obiettivo specificato.
Il modello a spirale (sviluppo di software) è un modello procedurale generico. Le quattro fasi forniscono semplicemente gli obiettivi di base di un ciclo, ma non devono riflettersi in ogni iterazione dello stesso. Il loro ordine non è sostanzialmente dettato in modo rigido dal modello a spirale. Per questo, è sempre possibile la combinazione con altri metodi procedurali.
La pubblicazione del 1988 proponeva, tra le altre cose, una rappresentazione grafica del modello a spirale che esemplifica come si presenta il processo a spirale dello sviluppo di software, basato su cicli. In questo schizzo, ogni curva della spirale incarna un ciclo chiuso, con un ordine che passa sempre attraverso quattro diversi quadranti, che in questo caso rappresentano le quattro possibili fasi del modello. All'aumentare della dimensione della spirale, aumentano anche i progressi fatti e l'approvazione mediante controllo (asse X) e costi di sviluppo (asse Y).
Lo sviluppo di software basato sul modello a spirale è particolarmente apprezzato per progetti grandi e complessi, in cui il controllo del budget per clienti e sviluppatori ha una priorità particolarmente elevata. In questo caso, tutti i partecipanti beneficiano del ruolo centrale dell'analisi dei rischi, che è probabilmente il più grande vantaggio del modello a spirale rispetto ad altri modelli procedurali. La valutazione regolare dei rischi paga, in particolare, quando vengono utilizzati nuovi ambienti tecnici, che solitamente implicano un particolare potenziale di rischio per via della mancanza di valori empirici.
Anche la struttura ciclica è uno dei maggiori punti di forza del modello: i conflitti tra il progetto e i requisiti tecnici che il software deve soddisfare sono praticamente eliminati grazie ai controlli regolari. Inoltre, i progressi a spirale consentono di raccogliere e valutare costantemente i feedback. In questo modo, sia il committente che gli utenti possono essere coinvolti nel processo di sviluppo fin dall'inizio. Il presupposto per poter godere di questi benefici è, tuttavia, una gestione molto attiva e laboriosa del progetto, in cui i singoli cicli sono costantemente e attentamente controllati e documentati.
Tuttavia, che i tanti piccoli passaggi dello sviluppo del software secondo il modello a spirale non siano sempre vantaggiosi è dimostrato dal fatto che non di rado, nonostante i test, nel sistema produttivo si inseriscano parti di programma non finite. Di conseguenza, sussiste sempre il pericolo che eventuali errori o lacune concettuali finiscano anche nel prodotto finale. Inoltre, possono sempre verificarsi ritardi nello sviluppo se, all'interno di un ciclo o durante la pianificazione del ciclo successivo, devono essere prese decisioni importanti in merito a come procedere.
Di seguito vi mostriamo in una tabella i vantaggi e gli svantaggi del modello a spirale:
| Vantaggi | Svantaggi |
|---|---|
| modello generico, flessibile | gestione elaborata |
| possibilità di coinvolgimento tempestivo di clienti e utenti | le decisioni ripetute possono ritardare il processo di sviluppo |
| controllo periodico mirato dei rischi | Per via della suddivisione del processo di sviluppo, errori e incongruenze concettuali possono facilmente finire nel prodotto finale |
| perfetto coordinamento tra requisiti tecnici e progetto | Know-how nell'analisi e nella gestione dei rischi essenziale, ma spesso mancante |
| massimo controllo su costi, risorse e qualità del progetto di software | inadatto per progetti più piccoli con rischio gestibile |
| molto indicato per nuovi ambienti tecnici |
Praticamente ogni decisione aziendale presenta dei rischi. Quello che conta è sapere quando i dirigenti possono sostenere in modo responsabile un rischio e quando invece sarebbe avventato. La gestione del rischio mette a disposizione dei metodi che consentono di individuare i possibili rischi derivanti dalle vostre decisioni, ma anche le possibilità di contenere il rischio presente.
Offri ai tuoi clienti servizi professionali e affidabili con l'hosting di IONOS.
Dominio omaggio per un anno