Operazione: Fasi del piano e iterazioni
Questo compito descrive come pianificare le fasi del progetto e le iterazioni: gli obiettivi, la durata, il numero di iterazioni e così via.
Discipline: Gestione del progetto
Scopo

Lo scopo di questo compito è di:

  • Stimare l'ambito complessivo, l'impegno ed il costo del progetto.
  • Sviluppare un piano dettagliato del progetto, concentrandosi sui punti fermi e sui componenti distribuibili chiave nel ciclo del prodotto.
  • Definire una serie di iterazioni all'interno delle fasi del progetto, ed identificare gli obiettivi per ciascuna di esse.
  • Definire un piano ed un budget del progetto.
  • Sviluppare un piano delle risorse del progetto.
  • Definire un compito per il completamento ordinato del progetto.
Relazioni
Passi
Stima del progetto
Scopo Stimare la quantità di lavoro richiesto per produrre il progetto.
Effettuare una pianificazione ottimale che soddisfi i vincoli del progetto. 

Durante la fase di inizio validità, si devono preparare delle stime del lavoro previsto per il progetto (per una descrizione generale della valutazione di un progetto software, consultare [BOE81], [PUT92], e [MCO96]). La valutazione di un progetto software si base su alcuni meccanismi complessi, aspetti talmente tecnici non vengono affrontati in questa guida. La valutazione segue un processo in quattro fasi:

  1. Valutazione della dimensione del prodotto.
  2. Valutazione dell'impegno e costo totali del progetto.
  3. Applicazione di vincoli e priorità (ad esempio, numero del personale, data di consegna, budget)
  4. Definizione della pianificazione ottimale, dell'impegno e delle stime di costo.

Valutazione della dimensione del prodotto

Questa è una informazione chiave per il processo di valutazione. Se non è possibile stimare la quantità di lavoro da effettuare, qualsiasi pianificazione rischia di essere lontana dalla realtà. Vi sono due approcci per la stima della dimensione del prodotto software che possono essere utilizzati all'inizio del progetto: Dimensionamento per analogia e per analisi. Chiaramente più avanti nel progetto (durante la fase di elaborazione) si potrà preparare una stima più rigorosa basata su una struttura di suddivisione del lavoro dettagliata.

Dimensionamento per analogia

Quando si valuta l'ambito del progetto utilizzando l'approccio di dimensionamento per analogia, si confrontano il prodotto nuovo che si andrà a sviluppare con prodotti (di dimensioni note) sviluppati in progetti precedenti. È necessario confrontare diverse caratteristiche dei prodotti, quali il numero di casi d'uso di business, numero di actor, dimensione/complessità del database ed il numero approssimato di programmi in linea e batch.

Tramite il confronto di queste caratteristiche sarà possibile stimare la dimensione relativa del nuovo progetto, quindi si utilizzerà la dimensione nota dei progetti vecchi per stimare quella del nuovo. Non dimenticare che è necessario confrontare prodotti dello stesso livello di complessità, prodotti utilizzando approcci simili, siccome delle differenze in cose quali il livello di dettaglio nelle descrizioni dei casi d'uso possono rendere inaffidabile il confronto.

Dimensionamento per analisi

Più avanti durante la fase di inizio validità è probabile che si saranno raccolte abbastanza informazioni sul nuovo prodotto da permettere l'uso di tecniche analitiche per stimare la dimensione del progetto. Queste tecniche si affidano alla disponibilità di una descrizione funzionale del prodotto software (ad esempio, specifiche di requisiti software, documento dell'architettura software) ed applicano regole di calcolo standard per determinare una misurazione della dimensione. Probabilmente la più conosciuta tra queste tecniche è quella del Calcolo del Function Point, per quanto un serie di altre misurazioni sono state sviluppate comprese quelle Feature Point (una variazione della Function Point per l'applicazione ai sistemi real-time) e Predictive Object Points (una misurazione per sistemi object-oriented basata sull'analisi della complessità delle classi e gerarchie). 

Vi è documentazione disponibile sul sito web IBM, che descrive metodi per la valutazione della dimensione basata su casi d'uso. Consultando questa documentazione è necessario avere chiaro che per effettuare delle valutazioni di dimensione iniziali basandosi su casi d'uso, li si deve adattare allo stile dei casi d'uso della propria organizzazione, perché questi possono variare enormemente per livello di astrazione e modalità di espressione tra un'organizzazione ed un'altra ed anche nella stessa. Una volta adattati, è importante mantenere costante lo stile per la scrittura del casi d'uso, altrimenti le stime di dimensione saranno ampiamente errate.

Valutazione dell'impegno e dei costi totali di un progetto

L'impegno del personale e la pianificazione totali di un progetto possono essere calcolati prendendo come riferimento la dimensione stimata del progetto utilizzando modelli scientifici stabiliti. I due modelli in uso sono il COCOMO (Constructive Cost Model) sviluppato da Barry Boehm e la Metodologia Putman di Larry Putnam. entrambi sono stati convalidati su dati industriali. Per maggiori informazioni sulla versione più recente di COCOMO, consultare il sito web COCOMOII.

Oltre al dato della dimensione l'altro parametro chiave è la misurazione della produttività del team. Questo valore determina l'impegno globale per il progetto. La pianificazione totale del progetto è collegata in modo non lineare all'impegno totale. Sfortunatamente questi modelli sono matematicamente complessi, è quindi consigliabile fare uso di prodotti software per essere assistiti con questi calcoli.

Applicazione di vincoli e priorità

In pratica tutti i progetti sono sottoposti a vincoli (ad esempio, deve essere rilasciato per una certa data, oppure i costi non devono superare gli 850.000 €) o priorità (ad esempio, prodotto necessario appena possibile). Data una dimensione di un prodotto, esso potrà essere sottoposto ad un ridimensionamento della dimensione del team. Ciò significa quindi che la relazione tra la dimensione del team e la pianificazione non è lineare, è perciò necessario utilizzare modelli scientifici per generare una serie di scenari basati sulla variazione delle dimensioni del team. Un software di valutazione automatica torna quindi molto utile in questa fase.

Definizione della pianificazione ottimale, dell'impegno e delle stime di costo

Adesso che si posseggono una serie di scenari, li si esamina e si seleziona quello che meglio si adatta alle necessità del progetto. Ciò offre un'immagine iniziale della durata globale del progetto ed indica la dimensione necessaria del team ed i costi.

Definizione delle fasi fondamentali del progetto
Scopo Definire i punti in cui si valuta formalmente l'avanzamento del progetto.
Allocare l'impegno stimato ed i costi a ciascuna fase. 

Il Piano di sviluppo software definisce in un primo momento le date e la natura dei punti cardine principali (consultare Fasi). Questa parte del Piano di sviluppo software serve da strategia evolutiva globale del progetto e viene create al suo avvio (fase di inizio validità).

Per pianificare le fasi di un progetto nel ciclo di sviluppo iniziale potrà essere necessario effettuare delle stime pilotate sui punti cardine in base a:

  • Esperienze su progetti di natura e dominio simili.
  • Il grado di inesperienza.
  • Vincoli di ambiente specifici, quali il tempo di risposta, la distribuzione e la sicurezza.
  • L'esperienza dell'organizzazione.

Utilizzando le valutazioni basate sulla propria esperienza, si definisce il budget iniziale del progetto, assegnando le porzioni adeguate di impegno e costi totali stimati a ciascuna fase.

Per ulteriori informazioni su come definire la durata delle iterazioni ed il loro numero, consultare  Linee guida: Piano di sviluppo software.

Definizione degli obiettivi dei punti cardine
Scopo Definire i criteri di valutazione delle fasi. 

Ciascun punto cardine punta ad uno specifico componente distribuibile; ciascun fornisce un ben definito punto di transizione ala fase successiva.

Fase 
Punto cardine 
Scopo 
Inizio validità  Punti cardine degli obiettivi del ciclo Dedicare risorse al progetto 
Elaborazione  Punti cardine dell'architettura del ciclo Stabilire l'architettura del prodotto 
Costruzione  Punto cardine delle capacità operative iniziali Completare lo sviluppo del prodotto 
Punto cardine di rilascio del prodotto Riuscire a mettere a disposizione il prodotto 

Ciascun punto cardine rappresenta un ostacolo critico che il progetto deve riuscire a superare; in ciascun punto cardine il progetto deve affrontare la decisione di procedere o meno.

Definizione del numero, della durata e degli obiettivi delle iterazioni in una fase
Scopo Determinare quante iterazioni pianificare per ciascuna fase.
Determinare l'assegnazione del lavoro per ciascuna iterazione.
Determinare gli obiettivi di ciascuna iterazione. 

Una volta determinata la durata delle fasi di un progetto, deve essere definito il numero di iterazioni e la loro durata. Per ulteriori informazioni su come definire la durata delle iterazioni ed il loro numero, consultare   Linee guida: Piano di sviluppo software. Vi sono una serie di modelli di iterazione applicabili, in base al tipo di progetto, al dominio del problema ed al suo grado di novità (consultare inoltre Concetto: Iterazioni).

Ciascuna iterazione produce un componente distribuibile, un rilascio che è un prodotto eseguibile utilizzato per valutarne l'avanzamento e la qualità. Poiché ciascuna iterazione si concentra si qualcosa di diverso, la funzionalità ed il livello di completezza del componente distribuibile dell'iterazione potrà variare. L'obiettivo dell'iterazione deve essere ben definito per poi poter valutare, al termine dell'iterazione, se è stato raggiunto o meno. Nelle prime iterazioni, gli obiettivi sono solitamente espressi in termini di attenuazione del rischio; in quelle successive vengono espressi con misurazioni del completamento funzionale e della qualità.

Perfezionamento delle date dei punti cardine e dell'ambito
Scopo Perfezionare le stime sulla base delle informazioni al termine della fase di inizio validità 

Verso la fine della fase di inizio validità, sarà possibile pianificare con maggiore dettaglio le fasi successive prendendo in considerazione:

  • Il numero di casi d'uso identificati.
  • Livello di complessità dei casi d'uso già studiati.
  • I rischi identificati, sia tecnici che commerciali.
  • Function-point o metrica del caso d'uso.
  • Il risultato di qualsiasi prototipo.

Questo piano molto grezzo viene aggiornato durante la fase di elaborazione. Serve come base per la costruzione del rimante piano del progetto.

Determinazione dei requisiti di risorse del progetto
Scopo Determinare il numero ed il tipo di risorse richieste per questa fase del progetto, assegnate per fase/iterazione.  

Sulla base delle proprie stime di impegno e sui tempi del progetto da queste derivati sarà possibile definire le risorse necessarie per completare il progetto. Per ciascuna fase/iterazione, identificare quali ruoli coinvolgere e quanti di ognuno.

Sviluppo del piano di chiusura del progetto
Scopo Sviluppo di un piano per una terminazione ordinata del progetto. 

Il piano di chiusura del progetto è descritto nella Sezione 5.6 Piano di chiusura del Piano di sviluppo software. Il piano di chiusura consiste dell'insieme di compiti da completare per eseguire una chiusura ordinata del progetto, accertandosi che qualsiasi metrica ed insegnamento venga registrato per riferimenti futuri.

Il processo di chiusura parte quando le seguenti condizioni sono soddisfatte:

  • Tutti i componenti distribuibili sono stati completati ed archiviati con il controllo della configurazione
  • I test di accettazione sono stati completati ed il prodotto è stato accettato formalmente dal cliente
  • Il prodotto è stato formalmente consegnato al cliente

Definizione del compito di chiusura

In primo luogo, elencare nel proprio piano i compiti che verranno eseguiti durante la chiusura del progetto. Solitamente questa operazione comprende quanto segue:

  • Una riunione successiva alla fine del progetto
  • Sviluppo di un report successivo al fine del progetto
  • Termine delle analisi del personale del progetto
  • Archiviazione dei prodotti di lavoro del progetto
  • Riassegnazione del personale del progetto
  • Aggiunta di matrici del progetto alle proprio database di matrici cronologiche dell'organizzazione per valutazioni di progetti futuri.

Identificazione dei partecipanti al compito di chiusura

Successivamente, identificare nel proprio piano chi sarà coinvolto in ciascuno dei compiti di chiusura.

Definizione dei tempi del compito di chiusura

Definire quindi i tempi del compito di chiusura. Solitamente questo dettaglio viene aggiunto nel Piano di sviluppo software verso la fine del progetto.



Considerazioni chiave

La pianificazione del progetto è la fase in cui il responsabile progetto definisce (e di successivamente ne gestisce l'esecuzione) un processo di produzione specifico (consultare Prodotto di lavoro: Processo di sviluppo) del progetto. Ciò viene spesso definito come promulgazione del processo.

Un processo "istanziato" è un piano di progettazione/iterazione/attività promulgabile (include le attività ed i prodotti di lavoro effettivi per un progetto effettivo).  È possibile creare l'istanza di un processo di produzione mediante importazione di un Processo di produzione da Rational Method Composer in RPM (Rational Portfolio Manager) e quindi eseguendo dei lavori di creazione istanze duplicando le attività e operazioni che sono impostate su isRepeatable o hasMultipleOccurences, creando prodotti di lavoro reali con assegnazione di risorse reali ai ruoli, e così via. 

Ulteriori informazioni