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:
-
Valutazione della dimensione del prodotto.
-
Valutazione dell'impegno e costo totali del progetto.
-
Applicazione di vincoli e priorità (ad esempio, numero del personale, data di consegna, budget)
-
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.
|