Linea guida: Piano di sviluppo software
Queste linee guida forniscono un aiuto nella creazione del Piano di sviluppo software per un ciclo iterativo dello sviluppo. Inoltre illustrano il modo in cui una sequenza di analisi waterfall tradizionale si allinea con un approccio iterativo.
Relazioni
Descrizione principale

Determinazione della lunghezza di ciascuna iterazione

L'iterazione è stata definita come un mini progetto abbastanza completo, che spazia attraverso tutte le maggiori discipline e che, nella maggior parte dei casi, ha come risultato un sistema eseguibile, ancora incompleto, cioè una versione. Sebbene il ciclo [modifica, compilazione, verifica, debug] sembri simile ad un'iterazione, non è ciò che si intende in questo documento. Anche i build giornalieri o settimanali, che integrano in modo incrementale e verificano sempre più elementi del sistema, potrebbero sembrare un'integrazione, ma questa è solo una parte di un'iterazione, così come viene intesa in questo documento.

Un'iterazione inizia con la pianificazione e i requisiti, e termina con una versione, interna o esterna.

La velocità con cui è possibile realizzare un'iterazione dipende principalmente dalla dimensione dell'organizzazione dello sviluppo.

Per esempio:

  • Cinque persone possono stabilire una pianificazione il lunedì mattina, pranzare insieme ogni giorno per discutere e controllare l'avanzamento, riallocare i compiti, eseguire dei build il giovedì e completare l'iterazione il venerdì sera.
  • Tutto questo, però, può diventare molto difficile da raggiungere con venti persone. Occorre più tempo per distribuire il lavoro, sincronizzarlo tra i gruppi secondari, etc... Per un'iterazione possono essere necessarie dalle tre alle quattro settimane.
  • Con quaranta persone, occorre già una settimana per passare dalla pianificazione alla realizzazione effettiva dei piani. Esistono livelli di gestione intermedi, la comprensione comune dell'obiettivo richiederà una documentazione e relazioni più formali. In una tale situazione è più probabile che l'iterazione duri tre mesi.

Entrano in gioco altri fattori: il grado di familiarità dell'organizzazione con l'approccio iterativo, compreso l'avere un'organizzazione stabile e matura, il livello di automazione utilizzato dal team per la gestione del codice (ad esempio, il CM distribuito), le informazioni distribuite (ad esempio, la rete interna), la verifica automatica, etc...

Essere anche consapevoli del fatto che esistono delle spese fisse in un'iterazione, nella pianificazione, sincronizzazione, analisi dei risultati, etc...

Pertanto, se da un lato si è convinti degli enormi vantaggi dell'approccio iterativo e quindi si potrebbe essere tentati dall'effettuare iterazioni accanitamente, dall'altro i limiti umani dell'organizzazione, che si ha disposizione, potrebbero far diminuire tanto entusiasmo.

Alcuni dati empirici:

SLOC Numero di sviluppatori Durata di un'iterazione
10.000 5 1 settimana
50.000 15 1 mese
500.000 45 6 mesi
1.000.000 100 1 anno

  • Le iterazioni superiori ai 6 mesi probabilmente devono avere dei punti cardine intermedi incorporati per mantenere i progetto nell'ambito previsto. Ridurre l'ambito dell'iterazione per ridurne la lunghezza ed assicurare un punto chiaro.
  • Le iterazioni superiori ai 12 mesi creano dei rischi, poiché l'iterazione abbraccia il ciclo di fondi annuale. Un progetto, che non ha prodotto nulla di tangibile in 12 mesi, rappresenta un rischio di perdita dei fondi.
  • Le iterazioni inferiori ad 1 mese devono essere definite con cautela. In genere, le iterazioni brevi sono più adatte alla fase di costruzione, dove il grado di nuove funzionalità da aggiungere e il grado di novità è basso. In iterazioni brevi è possibile che si effettui un'analisi formale o una progettazione scarsa o nulla, e che si effettui semplicemente un miglioramento incrementale della funzionalità già chiare.
  • Le iterazioni non devono essere della stessa lunghezza: la loro lunghezza varierà in base agli obiettivi. In genere, le iterazioni di elaborazione saranno più lunghe delle iterazioni di costruzione. All'interno di una fase, le iterazioni hanno in genere la stessa lunghezza (ciò rende più semplice la pianificazione).

Quando è chiaro il numero di iterazioni del piano abbozzato, occorre definire il contenuto di ciascuna iterazione. È anche una buona idea trovare un nome o un titolo per qualificare il prodotto, che verrà realizzato alla fine di ogni iterazione, per aiutare le persone a mettere meglio a fuoco il processo.

Esempio Iterazioni per uno switch telefonico privato

  • Iterazione 1: telefonate locali.
  • Iterazione 2: aggiunta di telefonate esterne e di gestione degli abbonati telefonici.
  • Iterazione 3: aggiunta di posta vocale e di teleconferenze.

Determinazione della lunghezza del numero di iterazioni

Un progetto molto semplice può avere solo un'iterazione per fase:

  • Un'iterazione nella fase di inizio, che produce forse un prototipo proof-of-concept, oppure interfacce utente fittizie, oppure nessuna iterazione, nel caso, ad esempio, di un ciclo di evoluzione.
  • Un'iterazione nella fase di elaborazione per produrre un prototipo strutturale.
  • Un'iterazione nella fase di costruzione per effettuare il build del prodotto (fino ad una versione "beta").
  • Un'iterazione nella transizione per terminare il prodotto (versione completa del prodotto).

Per progetti più sostanziosi, nel ciclo di sviluppo iniziale la norma sarebbe:

  • Un'iterazione nella fase di inizio (possibilmente producendo un prototipo).
  • Due iterazioni nella fase di elaborazione; una per un prototipo strutturale e una per la linea di base strutturale.
  • Due iterazioni nella fase di costruzione per esporre un sistema parziale e per maturarlo.
  • Una iterazione nella fase di transizione per passare dalla capacità operativa iniziale al versione del prodotto completa.

Per progetti ampi, con molte nuove tecnologie sconosciute, etc.., potrebbe essere il caso per:

  • Un'iterazione aggiuntiva nella fase di inizio, per consentire la creazione di più prototipi.
  • Un'iterazione aggiuntiva nella fase di elaborazione, per consentire di esplorare differenti tecnologie.
  • Un'iterazione aggiuntiva nella fase di costruzione a causa della dimensione del prodotto.
  • Un'iterazione aggiuntiva nella fase di transizione, per consentire feedback operativo.

Pertanto, in un ciclo di sviluppo, si hanno:

  • Basso: 3 iterazioni [0,1,1,1]
  • Tipico: 6 [1, 2, 2, 1]
  • Elevato: 9 [1, 3, 3, 2]
  • Molto elevato: 10 [2, 3, 3, 2]

Pertanto, in generale, si pianifichino dalle tre alle dieci iterazioni. Tuttavia si noti che i due valori estremi connotano circostanze inusuali, pertanto la maggior parte degli sviluppi utilizzeranno dalle sei alle otto iterazioni.

Sono possibili molte variazioni a seconda dei rischi, della dimensione e della complessità:

  • Se il prodotto è previsto per un dominio totalmente nuovo, occorre aggiungere delle iterazioni nella fase di inizio per consolidare i concetti, per mostrare vari oggetti fittizi in una sezione incrociata di clienti o utenti, oppure per rispondere in modo sostanzioso ad una richiesta di proposte.
  • Se occorre sviluppare una nuova architettura oppure esiste una grande quantità di modelli di casi d'uso, oppure esistono rischi reali, occorre pianificare almeno due o tre iterazioni nella fase di elaborazione.
  • Se un prodotto è ampio e complesso e sviluppato durante un lungo periodo, occorre pianificare tre o più iterazioni nella fase di costruzione.
  • Occorre pianificare varie iterazioni nella fase di transizione se occorre distribuire il prodotto con una serie di funzionalità ridotte, poiché è necessario ridurre al minimo i tempi di commercializzazione, oppure se si ritiene che occorrano molti piccoli adattamenti per l'utente finale dopo un periodo di utilizzo.

Allineamento della sequenza di analisi waterfall tradizionale con un approccio iterativo

La sequenza di analisi predefinita per un progetto con un ciclo di vita waterfall possiede una sola analisi principale al completamento dei prodotti di lavoro importanti, ad esempio:

  • SRR (System Requirements Review), al completamento della specifica del sistema;
  • SSR (Software Specification Review), al completamento della specifica dei requisiti software;
  • PDR (Preliminary Design Review), al completamento delle sezioni di progettazione strutturale della descrizione di progettazione software;
  • CDR (Critical Design Review), al completamento delle sezioni di progettazione dettagliata della descrizione di progettazione software;

Nel RUP (Rational Unified Process), parti di prodotti di lavoro equivalenti vengono analizzate come se fosse complete in ciascuna iterazione, ma i punti cardine principali (e pertanto le analisi) sono allineati al completamento delle fasi di inizio, elaborazione, costruzione e transizione. Un responsabile progetto, che desideri adottare RUP potrebbe trovare un modo di far quadrare questo conflitto apparente, a causa di obblighi contrattuali. Idealmente, il responsabile progetto deve convincere il cliente che l'approccio, basato su fasi e iterazioni, fornisce una maggiore e reale visibilità all'interno del progetto e riduce i rischi, per cui non sono necessari SRR, SSR, etc... Tuttavia, ciò non è sempre possibile e il responsabile progetto deve pianificare queste analisi in punti appropriati. Nel RUP è possibile individuare i punti dove questi prodotti di lavoro importanti (i loro equivalenti in RUP) sono sostanzialmente completi, sebbene ciò non si allinei sempre in modo ordinato con le fasi e le iterazioni.

Pertanto qui si presuppone che lo sforzo relativo, che verrà impiegato sui requisiti, la progettazione, etc..., sarà nel RUP approssimativamente uguale a quello nel ciclo di vita waterfall (ideale), ma lo sforzo verrà distribuito in modo differente. Il risultato è il seguente:

  • L'SRR (che si occupa principalmente della Visione) può essere pianificato al termine della fase di inizio;
  • L'SSR (che si occupa principalmente della Specifica di requisiti software) può essere pianificato a circa un terzo della fase di elaborazione;
  • Il PDR (che si occupa principalmente del Documento dell'architettura software) può essere pianificato al termine della fase di elaborazione;
  • Il CDR (che si occupa principalmente del Modello di progettazione) può essere pianificato a circa un terzo della fase di costruzione.

Per efficienza, il responsabile progetto, nelle consultazioni con il cliente, deve cercare di combinare queste analisi con le analisi RUP proposte. Ciò è chiaramente possibile per l'SRR e il PDR, poiché possono essere combinati rispettivamente con l'Analisi del Punto cardine Obiettivi del ciclo di vita  e con l'Analisi dell'Architettura del ciclo di vita .

Organizzazione del progetto

Come il processo software viene influenzato dalle caratteristiche del progetto, così accade per l'organizzazione del progetto. La struttura predefinita presentata qui (consultare la seguente figura) deve essere adattata per riflettere gli effetti dei fattori quali quelli elencati:

  • Il contesto del business
  • La dimensione dell'impegno lavorativo per lo sviluppo software
  • Il grado di novità
  • Il tipo di applicazione
  • Il processo di sviluppo corrente
  • I fattori organizzativi
  • La complessità tecnica e manageriale

Questi sono i fattori caratteristici quando si analizza il modo in cui un'organizzazione, nel complesso, adotta un nuovo processo di sviluppo; in questo documento se ne analizzano gli effetti sulla scelta della struttura del progetto. La figura qui di seguito presenta un'organizzazione predefinita del progetto, che illustra il modo in cui le responsabilità vengono assegnate alla struttura del team.

Diagramma, sensibile al contesto, che mostra il modo in cui le responsabilità vengono assegnate ai membri del team.

Figura che illustra l'organizzazione predefinita del progetto. Si noti che l'orine dei ruoli non dipende dall'anzianità o dall'autorità.

La figura rappresenta un punto di partenza per considerare il modo in cui i ruoli e le responsabilità a livello di progetto devono essere mappati ad una struttura di team. Inoltre la figura serve ad enfatizzare che i ruoli (mostrati nelle caselle gialle) non sono individui, ma "cappelli" che possono indossare gli individui (o un team) nel progetto. Per questo motivo alcuni ruoli (ad esempio, il responsabile progetto) sono presenti più di una volta. In tal modo si indica che, in un certo momento, il comportamento del responsabile progetto, come definito in RUP, può essere presente in più team. Ad esempio, in un progetto di ampie dimensioni, il compito di preparare un report sullo stato, basato su un WBS (Work Breakdown Structure), potrebbe essere delegato ad un individuo nel team di gestione. Tuttavia, questa è una responsabilità che RUP assegna al ruolo chiamato responsabile progetto.

In un progetto di piccole dimensioni, è probabile che un individuo, nominato responsabile progetto, eseguirà tutti i compiti del ruolo chiamato responsabile progetto, nel qual caso il team di gestione si mescola con il team di gestione software. La selezione della struttura del team verrà influenzata dalla natura e dalla dimensione del progetto, ma deve essere moderata da alcuni ruoli di ampio senso comune:

  • Piccoli team sono di solito più produttivi; tuttavia, in un progetto di ampie dimensioni, occorre che vi sia un bilanciamento con le iterazioni incrociate tra team.
  • Forti gerarchie sono da evitare
  • La portata del controllo di qualsiasi responsabile o leader del team deve essere limitata a più sette o meno due
  • la struttura del team dello sviluppo software deve essere guidata dall'architettura software; una buona architettura, con un'elevata coesione e con una bassa dipendenza tra sistemi secondari, consentirà ai team di lavorare in parallelo
  • Una verifica, diversa dal test di unità, deve idealmente essere effettuata da un team separato dal team di sviluppo. Si noti, tuttavia, che ciò non ha senso, da un punto di vista economico, in un progetto di piccole dimensioni
  • La struttura deve consentire a tutti i team e agli individui di avere autorità e responsabilità chiaramente definite. Questo è particolarmente importante se la gerarchia supera tre livelli. I responsabili e i leader del team in questo tipo di strutture devono comprendere cosa gli viene richiesto nel bilanciamento dei compiti tecnici e manageriali.
  • La struttura deve supportare le capacità, l'esperienza e le motivazioni dello staff; ad esempio, se un singolo team deve effettuare analisi, progettazione e implementazione senza alcun passaggio di mani intermedio, occorreranno tutte le competenze intermedie. Gli analisti esperti non sono necessariamente dei buoi implementatori;
  • Le strutture del team non devono essere rigide; gli individui devono migrare tra team durante la durata del progetto e le responsabilità del team cambieranno appena l'enfasi del progetto passerà da una fase ad un'altra.

Il fondamento logico dell'organizzazione predefinita viene discussa ampiamente in [ROY98]. In particolare, nell'assegnazione delle responsabilità per la distribuzione al team di valutazione del software viene riconosciuto che, tra tutti i team di un progetto di sviluppo, il team di valutazione del software ha la maggiore esposizione al software poiché questo viene sottoposto all'utente.

Durante la vita di un progetto, l'organizzazione evolverà in un supporto alla struttura di partizionamento del lavoro, catturata nel piano del progetto. Ciò viene illustrato nella figura qui di seguito, che viene tratta da [ROY98].

Diagramma che mostra l'evoluzione del team durante il ciclo di vita del progetto.

Questa evoluzione enfatizza una serie differente di compiti in ciascuna fase:

  • Il team di inizio: un'organizzazione focalizzata sulla pianificazione, con sufficiente supporto, proveniente dagli altri team, per assicurare che i piani rappresentino un consenso a tutte le prospettive;
  • Il team di elaborazione: un'organizzazione basata sulla struttura, in cui le forze portanti del progetto sono presenti nel team di architettura software e vengono supportate dallo sviluppo software e dai team di valutazione del software come necessario per acquisire una linea di base strutturale stabile;
  • Il team di costruzione: un'organizzazione bilanciata in cui la maggior parte dei compiti è nello sviluppo software e nei team di valutazione del software;
  • Il team di transizione: un'organizzazione, focalizzata sul cliente, in cui il feedback degli utenti conduce i compiti dello sviluppo.

La migrazione tra team durante questa evoluzione assicurerà che vengano conservate conoscenza e capacità. Ad esempio, una volta completata l'elaborazione, alcuni membri del team dell'architettura potrebbero essere suddivisi nei vari team di sviluppo, forse per agire come leader del team, oppure per realizzare la 'visione' strutturale. In seguito, verso il termine della fase di costruzione, l'attenzione passa al team di valutazione e viene spostato lo staff dal team di sviluppo a quello di valutazione. Inoltre, è importante, a questo punto, che, per evitare una perdita strutturale durante costruzione, non si consenta il calo d'influenza del team dell'architettura appena viene spostato il 'centro di gravità' del progetto. Un modo per fare questo è quello di spostare alcuni membri del team dell'architettura al team di valutazione.