Un approccio comparativo per la scelta del modello di gestione dello sviluppo software

Table 1 Riepilogo Caratteristiche dei Software Development Method

Modello Vantaggi Svantaggi Applicabilità

Waterfall (Modelli

lineari)

Facile da implementare Costoso

I requisiti e il contesto sono stabili il progetto software non è troppo grande o troppo complesso, tecnologie e strumenti sono noti le risorse sono disponibili e competenti,

in organizzazioni molto gerarchizzate e burocratizzate Fasi e attività ben

definite

Richiede tempistiche lunghe

Controllo della qualità di processo e prodotto

Rigido: non gestisce i cambiamenti

Monitoraggio Richiede che i requisiti siano stabili

Documentazione accurata per

tracciamento attività

Le iterazioni di attività generano confusione e ritardi

Iterativi Incrementali

Modello flessibile, adatto a requisiti instabili

Non è adatto a piccoli progetti

i requisiti sono complessi o incerti il progetto è un progetto di lungo termine

il team è strutturato

il progetto ha un elevato grado di rischio

Raccoglie i feedback degli utenti

anticipatamente

Modello complesso, difficile da implementare

Consente di sviluppare rapidamente e ridurre i tempi

Comporta costi elevati e lunghe tempistiche

il progetto è ampio e

caratterizzato da frequenti release

Abilita l’aggiunta di nuove funzionalità durante lo sviluppo

Richiede competenze specifiche per gestire i rischi o per l'adozione di specifici linguaggi (UML)

Gestisce il rischio (spirale)

Agile

Modello flessibile si adatta ai cambiamenti

Team di progetto piccoli, riuniti in un'unica location

Il progetto è piccolo

Sono richiesti molte modifiche e cambiamenti

I requisiti non sono definiti Il prodotto è adatto ad un’architettura flessibile

L’utente può esser coinvolto nelle fasi di sviluppo

Errori scoperti nelle

prime fasi

Poca documentazione e pianificazione, basso monitoraggio Sviluppo iterativo e

incrementale

Non consente di affidare parte del lavoro a fornitori

Ampio coinvolgimento utenti nel processo

In caso di progetti ampi è difficile definire l’effort richiesto sin da subito Validazione continua da

parte degli utenti

Necessari sviluppatori con esperienza Migliora le

comunicazioni fra sviluppatori, tester e utenti

In caso di requisiti iniziali poco chiari non si ha certezza del risultato finale

Se si guarda alla tabella in alto è evidente che non esiste un modello che possa essere applicato per tutte le tipologie di progetto. Ma la scelta del modello da adottare è una determinante per il successo di un progetto.

Alcuni metodi di processo possono adattarsi a un particolare tipo di progetto, altri no e possono rivelarsi più adatti per progetti differenti.

I metodi agili e i modelli iterativi sono utili nel caso sia necessario sviluppare un prodotto software velocemente, il progetto non sia particolarmente ampio e possano essere utilizzati team piccoli che consenta l’adozione di metodologie agili. Se il progetto è ampio infatti, il ridotto numero di sviluppatori che abilita i team agili comporterebbe tempistiche lunghe.

Nel caso di progetti più ampi e complessi che richiedono un numero di sviluppatori maggiore di 50 possono essere utilizzati modelli iterativi, come il Rational Unified Process.

Oppure in caso di un progetto ampio e complesso e necessità di un delivery rapido può essere utilizzato un approccio di tipo concurrent.

Nel caso i requisiti progettuali non siano chiari fin da subito, può esser difficile valutare la grandezza del progetto ed è necessario un approccio cautelativo, abilitato da metodi agili.

Se invece il progetto riguarda un prodotto noto ma ci si pone come obiettivo quello di migliorare in termini di performance di processo, di aumentare la produttività oppure la qualità, gli approcci tradizionali plan drive hanno la meglio sui metodi agili.

Per usufruire dei vantaggi di entrambi i metodi si potrebbe utilizzare un approccio ibrido, introducendo nel modello a cascata driven plan delle logiche agili legati alla gestione di alcune fasi

o l’introduzione di iterazioni fra di esse, o viceversa inserendo componenti della pianificazione all’interno dei modelli agili. Tale approccio non è raro nei casi reali, in seguito se ne vedrà un’applicazione. (Ahmed, 2011)

Alistair Cockburn, nel suo articolo: “Selecting a Project’s Methodology” afferma che utilizzare differenti metodologie è appropriato e necessario. Cockburn in seguito alle sue analisi ha sviluppato un framework per la selezione della metodologia da adottare. Il suo approccio si basa su 4 principi che egli deriva dalle sue ricerche e su due fattori, che egli identifica come driver principali che guidano la scelta metodologica. (Cockburn, 2000)

I 4 principi:

1. Team più ampi richiedono una metodologia più ampia (cioè una metodologia che comprensiva di più elementi, ruoli, standard, linguaggi)

2. I sistemi più critici (ovvero i sistemi i cui difetti comportano maggiori più gravi) necessitano di una maggiore visibile correttezza nel loro sviluppo. Ovvero per progetti i cui difetti potrebbero causare perdite in termini di vite umane, si investirà maggiormente nella qualità dei loro strumenti rispetto al progetto di un e-commerce.

3. Esiste una relazione fra: numerosità del team, tipo di metodologia e dimensione del problema. Se un team piccolo è in grado di portare a termine il progetto, allora si utilizzerà una metodologia più leggera (ad esempio una metodologia agile), se il problema diventa più ampio sarà necessario un team ampio per rilasciare nei tempi previsti e conseguentemente una metodologia più “pesante”, ovvero più strutturata.

Figure 19 La metodologia e la dimensione del problema impattano sulla numerosità dello staff

4. La forma di comunicazione più efficace per la condivisione di idee) è quella face to face

Figure 20 Efficacia delle varie forme di Comunicazione

Altri due fattori determinano quale sia il metodo appropriato:

• le priorità progettuali, se è necessario che il software venga consegnato presto che piuttosto sia privo di difetti o che i costi siano contenuti. Le priorità progettuali definite dagli stakeholder possono essere diverse

• l’esperienza dei progettisti. Le esperienze passate dei progettisti sono una forte determinate della scelta del metodo da utilizzare.

Cockburn ha sviluppato un framework tridimensionale per la scelta del modello con dimensioni:

Criticità, Numero di persone dei team, Priorità.

Diversi sono i metodi e i framework presenti in letteratura che si vogliono proporre come strumento di supporto alla decisione. Negli studi più recenti sembra comunque prevalere l’idea di avvalersi di un approccio misto fra metodi tradizionali e metodi agili che gestisca le varie fasi progettuali in base alle loro peculiarità, adottando il metodo ad esse più appropriato.

In particolare, Apoorva e Deepty nel 2013 attraverso uno studio comparativo, concludono che un modello ibrido, opportunamente modificato e appropriato possono essere utili per migliorare la qualità del software. (Deepty, 2013)