Rischi, requisiti e stima di un progetto software

Transcript

1 Rischi, requisiti e stima di un progetto software Roberto Meli Abstract Lo scopo di questo lavoro è quello di fornire un contributo pratico a coloro che sono interessati a perseguire il successo di un progetto software, attraverso la riduzione consapevole e metodica dei principali rischi ad esso associati. Un rischio, per un progetto, può essere immaginato come la eventualità di non riuscire a raggiungere uno o più degli obiettivi specificati e concordati per esso, con i conseguenti danni che ne derivano. Tipiche aree di risultati attesi sono quelle dei requisiti funzionali, della qualità del prodotto, dell'impegno lavorativo, della durata e costo del progetto di sviluppo o manutenzione evolutiva. Una sistematica revisione delle reali motivazioni di fallimento dei progetti, mostra che la scarsa definizione degli obiettivi e la inadeguata allocazione delle risorse sono due tra i fattori più significativi in grado di influenzare negativamente il risultato progettuale. Per questo motivo, gestire i requisiti utente e stimare le risorse necessarie al progetto sono due processi di importanza strategica per qualunque organizzazione che desideri raggiungere risultati di qualità senza sprecare risorse umane ed economiche. Sfortunatamente entrambi i processi sono caratterizzati da grandi incertezze in quanto sono spesso basati su informazioni incomplete o sommarie. Gestire i requisiti in modo disciplinato può garantire che il sistema in sviluppo sia il sistema "giusto" richiesto dagli utenti. Allo stesso tempo, stimare accuratamente la taglia funzionale (size), l'impegno, la durata, lo staff ed i costi associati con lo sviluppo o la manutenzione evolutiva di un progetto, può permettere di ridurre gli sprechi determinati dal mancato rispetto di scadenze, dalla necessità di revisionare i budget, dall'esigenza di coinvolgere un numero maggiore di sviluppatori etc. Ogni miglioramento ottenuto in queste aree ripaga di gran lunga i costi di implementazione associati. Essere capaci di rilevare il più presto possibile un cambiamento dei requisiti e di derivare immediatamente una nuova stima dei relativi costi permette, quindi, di ridurre significativamente i rischi di progetto. Il presente lavoro illustra un quadro di riferimento integrato per i processi di gestione del rischio, di gestione dei requisiti e di stima del software supportato da metodi di pubblico dominio e tools commerciali. 1. Il rischio di un progetto software Il rischio è stato definito in molti modi e con sfumature diverse [1]. In questo lavoro riprendiamo l impostazione usata dal metodo SAFE [2] che definisce come rischio: il valore atteso del danno derivante al progetto dal verificarsi di una combinazione di condizioni incerte. Ricordiamo che per valore atteso di un fenomeno probabilistico in termini statistici semplificati si può intendere il prodotto della probabilità di un evento, espressa con un valore da 0 ad 1, per la quantificazione numerica collegata all evento stesso, esteso a tutti gli eventi possibili per quel fenomeno. Se, ad esempio, ogni volta che al lancio di una moneta perdessimo 1 euro per l evento croce e nulla per l evento testa, il valore atteso della perdita associata al lancio sarebbe 0.5 euro (0.5 x x 0). In realtà in ogni singola giocata non perderemmo mai esattamente 0.5 euro (infatti potremmo perdere o 1 euro oppure niente) ma se giocassimo un numero sufficientemente elevato di volte e dividessimo la perdita totale per il numero di giocate fatte, la perdita media sarebbe molto vicina se non coincidente con 0.5 euro. Infatti, per la legge dei grandi numeri, la quantità di eventi testa tende ad eguagliare quella degli eventi croce sul lungo periodo, per cui le perdite da 1 euro sarebbero all incirca la metà delle giocate fatte. La perdita media sarebbe, quindi, la metà della singola perdita possibile cioè, per l appunto, 0.5 euro. pag.1

2 Tornando al rischio, potremmo affermare che esso è tale se comporta un disagio, una sofferenza od una perdita, percepibile da determinati soggetti, conseguente al verificarsi di situazioni che sono possibili ma non certe. Perché vi sia rischio, dunque, occorre: che vi siano uno o più soggetti coinvolti, che vi sia un evento o una combinazione di eventi che abbia una probabilità non nulla di verificarsi, che vi sia una catena di cause-effetti in grado di determinare una situazione finale, che tale situazione sia considerata negativa in rapporto alle attese ed alla scala di valori dei soggetti coinvolti provocando loro, quindi, un danno. Questo approccio viene chiamato Condizione, Transizione, Conseguenza (CTC) ed è stato descritto dal Software Engineering Institute in [1]. La soggettività del punto di vista è fondamentale nella individuazione dei rischi, in quanto una stessa situazione può assumere una connotazione negativa per taluni e positiva per altri. La comprensione della scala di valori e delle attese degli stakeholder (portatori d interesse) di un progetto è essenziale, dunque, per un appropriata valutazione delle potenziali conseguenze negative di un evento, cioè dell entità del danno associato. Benchè la valutazione dell altra componente del rischio - la probabilità della catena di eventi negativi - dovrebbe essere più oggettiva della valutazione dell entità del danno, vi sono molte situazioni nelle quali tale probabilità è influenzata dal soggetto che la valuta. Affidare lo stesso progetto a due Project Manager diversi genera due diverse valutazioni del rischio non solo perché essi vedono le cose in modo diverso (aspetto negativo della soggettività) ma anche perché hanno personali capacità di influenza diverse sulle cose. Un Project Manger più esperto e potente potrebbe attribuire un rischio più basso alla eventualità di non ricevere risorse a sufficienza per il proprio progetto, rispetto ad un Project Manager alle prime armi e poco ascoltato dal top management. Il rischio, in questi casi, non solo è percepito come diverso ma lo è anche nei fatti! Per usare termini meno rigorosi ma più intuitivi, potremmo dire che c è un rischio tutte le volte in cui vi è il sospetto che non potranno essere raggiunti gli obiettivi posti al progetto in termini di quantità di prodotto (numero e tipo di funzionalità e dati), di qualità dei risultati (requisiti non funzionali), di costo o di durata delle attività Un primo fondamentale fattore di rischio L analisi delle motivazioni di insuccesso dei progetti, così come sono riportate dai Project Manager nell ambito di molte indagini informative, pone al primo posto la indeterminatezza, ambiguità, indefinizione o genericità degli obiettivi progettuali: in altri termini, la scarsa qualità della loro formulazione. In tale situazione un progetto si comporta come se avanzasse alla cieca, barcollando in cerca della giusta direzione in balia delle spinte che lo dirigono ora in un verso ora in un altro, a seconda dei capricci degli stakeholder, i quali cambiano continuamente idea su ciò che serve loro. Naturalmente se non è ben chiaro a priori dove si vuole andare è difficile cercare di convincere a posteriori i viaggiatori che il posto in cui si è giunti è esattamente quello dove si voleva arrivare. Ognuno sarà libero di pensare e sostenere che gli accordi erano diversi e tutti, paradossalmente, avrebbero ragione. Il fatto è che una formulazione ambigua di un obiettivo può nascondere una moltitudine di diverse formulazioni specifiche! Perché gli obiettivi svolgano, dunque, una funzione di guida e di traino del lavoro progettuale occorre che siano ben formulati e condivisi. Per formulare adeguatamente gli obiettivi, occorre che siano il più possibile chiari, cioè espressi in un linguaggio comprensibile ai diversi stakeholder, specifici e soprattutto misurabili. La misurabilità di un obiettivo, infatti, associata alla definizione dei valori attesi delle misure per esso, permetterà di riconoscerne il raggiungimento e, in definitiva, di garantire il successo stesso del progetto. pag.2

3 L esperienza consulenziale e formativa tende a mostrare che i gruppi di progetto sono generalmente capaci di affrontare sfide tecnologiche avanzate, di usare metodi e tecniche di lavoro complessi ma hanno scarsa capacità o possibilità di focalizzare i problemi reali e gli obiettivi da perseguire. E come se disponessero di un fucile ben oliato, carico e pronto a sparare ma il mirino fosse regolato in modo approssimativo, con il rischio di colpire se stessi anziché il bersaglio desiderato. Le motivazioni di questo fenomeno sono molteplici ed hanno a che fare con la scarsa attenzione dedicata nelle fasi iniziali di progetto, alla definizione di quali problematiche debbano essere affrontate, di chi siano gli stakeholder da coinvolgere, di quali siano le attese di tali stakeholder in merito ai risultati. La tendenza di molti gruppi di lavoro è quella di pensare che fino a che non si passa all azione operando attività pratiche - come la codifica del software - si stia sostanzialmente perdendo del tempo, giustificando così il detto che meno tempo si passa ad analizzare la situazione e più tempo si passerà a revisionare, testare e correggere i programmi software necessari. La prima domanda che si pone un gruppo di progetto di questo tipo è, spesso: cosa c è da fare? Quando sarebbe opportuno chiedersi prima: cosa vogliamo che resti quando questo progetto sarà finito? E comune abitudine, infatti, quella di confondere le attività con i risultati, i mezzi con i fini. Fare un indagine di mercato non è un buon obiettivo di progetto, è una possibile azione. Ottenere la conoscenza di un certo segmento di mercato è, invece, un obiettivo significativo. La soluzione più giusta potrebbe essere, magari, quella di acquisire un indagine già fatta anziché farne una nuova. Concentrarsi sulle attività, dunque, spesso porta a trascurare soluzioni alternative meno immediate ma talvolta più efficaci. Oltre alla cattiva abitudine di tralasciare la corretta definizione di problemi ed obiettivi di progetto, perché si pensa di non avere abbastanza tempo per farlo, esiste spesso una oggettiva difficoltà a produrre una visione comune a tutti gli stakeholder di cosa sia il progetto e di quali effetti debba produrre. Eppure la condivisione degli obiettivi è essenziale per non impegnarsi in missioni impossibili. Esistono tecniche molto efficaci che possono venirci in aiuto in questo ambito, come ad esempio il metodo GOPP (Goal Oriented Project Planning) [3] che si sta affermando sempre più in ambiti nei quali la concertazione tra soggetti distinti con interessi divergenti è un fattore critico di successo dei progetti. Un altra causa di scarsa qualità degli obiettivi è la percezione, da parte del gruppo incaricato di produrre un sistema software, di essere chiamato a realizzare solo uno strumento tecnologico che servirà ad altri per perseguire fini più elevati di cui non è concesso occuparsi. In altri termini si tende a concentrarsi sullo strumento che viene richiesto perdendo di vista lo scopo per il quale è richiesto. In molti casi questa tendenza è rinforzata dal cliente del progetto che spesso relega ad un ruolo di mero esecutore il fornitore (interno od esterno) di software non consentendogli di accedere alla percezione dei fini e restringendo il mandato ai soli mezzi. Sfortunatamente, una volta assegnato il mandato, capita che nessuno più si preoccupi di garantire l aderenza tra mezzi e fini ottenendo così dei magnifici prodotti software - dal punto di vista estetico e tecnologico - che nessuno, però, usa perché inadatti ai veri bisogni dell organizzazione. Si assiste spesso, allora, al noto fenomeno della cosiddetta soluzione assente : invece di analizzare i problemi nella loro reale natura si pensa ad una soluzione già disponibile, la si nega e si ritiene che la mancanza di tale soluzione sia il problema che attanaglia gli stakeholder. Ci si trova spesso, dunque, ad avere soluzioni in cerca dei loro problemi anziché il viceversa. pag.3

4 1.2. Un secondo fondamentale fattore di rischio E esperienza comune che i progetti finiscano mediamente fuori dai budget assegnati e oltre le scadenze previste. L inadeguata allocazione di risorse per l esecuzione delle attività del piano di progetto è considerata anch essa, dunque, una fondamentale causa di fallimento dei progetti. Essa può derivare da due motivi diversi ma ugualmente importanti: il progetto riceve le giuste risorse ma viene gestito impropriamente e ne spreca una buona parte rendendo necessaria un ulteriore assegnazione; il progetto riceve meno risorse di quante ne servirebbero, per scarsa capacità di stima iniziale. Spesso è difficile capire se una inadeguata allocazione di risorse dipenda da una cattiva gestione o da una cattiva stima. Nel dubbio, occorre agire su entrambi i fronti, migliorando sia le capacità di gestione che quelle di stima delle risorse fondamentali di progetto. Le due questioni trattate fino a questo momento la scarsa qualità degli obiettivi/requisiti e la scarsa capacità di stima delle risorse sono fortemente interrelate perché la seconda dipende in grande misura dalla prima. Se in un progetto non sono definiti adeguatamente gli obiettivi ed i requisiti funzionali e non funzionali del prodotto software richiesto, anche le risorse necessarie allo sviluppo saranno imprecise ed inadeguate, spesso insufficienti. A questo c è da aggiungere che, molto frequentemente, nel momento in cui sono necessarie le stime cioè ad inizio progetto le informazioni in base alle quali fare le proprie scommesse sono carenti di dettaglio, imprecise e necessariamente generiche. Ecco che un qualsiasi miglioramento nel processo di definizione dei requisiti e soprattutto della conseguente valorizzazione delle risorse necessarie riveste particolare importanza per ridurre le due cause maggiori di rischio per i progetti Una strategia di riduzione del rischio Dopo quanto scritto appare chiaro che, al fine di ridurre significativamente i rischi di progetto, un buon piano d azione potrebbe essere: rendere esplicito e metodico il processo di gestione dei rischi migliorare la gestione dei requisiti migliorare la capacità di stima dei progetti pag.4

5 1.4. Il metodo SAFE per la gestione del rischio Nel lavoro citato in precedenza [2] si è introdotto il metodo SAFE (Safe Activities For Enhancement) che descrive un processo di gestione del rischio che è sintetizzato nella figura seguente. Identificazione del rischio Risk Management Database Quantificazione del rischio Risk Assessment Report Progettazione interventi Risk Management Plan Esecuzione interventi Strumenti di Pianificazione e Controllo Progetto Verifica efficacia interventi Risk Management Evaluation Report Secondo questo approccio, la gestione del rischio è un processo iterativo che si svolge durante tutta la durata del progetto, anche se assume particolare rilevanza nelle fasi iniziali di lavoro. Alla fase diagnostica di indagine sulle specifiche cause di rischio segue una fase di valutazione della sua entità quantificata attraverso opportune tecniche di lavoro. Al termine della diagnosi seguirà una prognosi consistente in un piano di gestione del rischio contenente azioni di prevenzione, sorveglianza e contrasto dei singoli fattori di rischio individuati. Il metodo SAFE permette di effettuare una valutazione ex-ante della bontà del piano di gestione dei rischi quantificata in un indice di efficacia nella rimozione del rischio. L adozione di questo, come di altri possibili processi di gestione del rischio, contribuisce a rendere evidenti, comunicabili e influenzabili i fattori da cui dipende il successo degli interventi progettuali e costituisce, quindi, la base per ogni iniziativa di maturazione del processo di sviluppo software dell organizzazione. Nel seguito concentreremo la nostra attenzione sui processi di gestione dei requisiti e di stima del software presentando successivamente un quadro di riferimento integrato per la efficace interrelazione tra i due aspetti. pag.5

6 2. I requisiti di un progetto software Molti studi hanno evidenziato che la percentuale di progetti che non riescono a rispettare i limiti previsti di budget o di tempo, oppure che non rilasciano i risultati attesi dagli stakeholder, è elevatissima. Secondo un rapporto dello Standish Group del 1997, le prime 1000 imprese dell elenco Fortune hanno speso nel 1996 il 53 % delle risorse dedicate allo sviluppo di applicazioni, in progetti che sono falliti tecnicamente o che hanno richiesto molte più risorse di quelle a disposizione inizialmente. Altre ricerche mostrano che gli errori nei requisiti non solo sono i più costosi ma anche i più frequenti. Rimuovere un errore commesso in fase di definizione delle specifiche utente può costare fino a 20 volte di più della rimozione di un errore commesso in fase di realizzazione del software. Il ri-lavoro necessario a compensare una imprecisa definizione dei requisiti occupa spesso più del 40% del budget di progetto. Da questi dati emerge un drammatico problema che si può, però, trasformare in una opportunità eccezionale: operando un miglioramento delle attività di gestione dei requisiti si può ridurre drasticamente i fallimenti ed anche i costi associati ai progetti di sviluppo software delle proprie organizzazioni La natura dei requisiti Ma cosa si intende per requisito? E come si possono gestire, al meglio, i requisiti? Un requisito è, essenzialmente, una richiesta espressa ed accettata dal progetto circa il funzionamento del sistema oggetto di sviluppo o circa il comportamento del progetto stesso. Nel primo caso abbiamo un requisito di tipo tecnico, nel secondo un requisito di tipo gestionale. Il requisito tecnico può essere di tipo funzionale riguardando i comportamenti espressi dal software o i dati su cui esso opera - o non funzionale riguardando la qualità o le prestazioni a cui i requisiti funzionali devono essere vincolati. I requisiti gestionali, invece, possono riguardare il processo di lavoro, gli strumenti, le tecnologie o le risorse da impiegare. La maggior parte dei problemi dei progetti deriva dalla carenza di definizione dei requisiti tecnici. La parola requisito viene spesso adoperata per indicare livelli di dettaglio delle specifiche di progetto molto diversi. Si passa dai requisiti puramente testuali di livello molto generale ai requisiti espressi in modo grafico nell ambito di modelli semiformali di rappresentazione, dai requisiti strutturati formulati mediante l uso di linguaggi formali procedurali o non procedurali fino ai prototipi realizzati mediante linguaggi visuali. Nella letteratura tecnica, però, nella maggior parte dei casi per requisito utente si intende una formulazione in linguaggio naturale delle caratteristiche funzionali e non funzionali che il sistema dovrà dimostrare di possedere per soddisfare le esigenze espresse ed implicite degli stakeholder. I requisiti per un progetto software potranno essere rintracciati in ogni tipo di documento come i manuali organizzativi, i documenti di marketing, le specifiche di prodotto, le regole di business, le specifiche funzionali, i piani di qualità etc. Essi saranno, in genere, numerosi e difficili da trattare, con molte interrelazioni reciproche e soprattutto instabili nel tempo. Benchè soffrano di svariati difetti, i requisiti rappresentano il patrimonio di progetto più importante perché costituiscono l anello di congiunzione tra i bisogni e le percezioni degli stakeholder e le soluzioni tecnologiche progettate dagli esperti software. Gestire i requisiti significa operare in modo sistematico per identificare, organizzare, documentare, comunicare e mantenere nel tempo i mutevoli requisiti di un applicazione software. Usare strumenti e metodi standard per la gestione dei requisiti permette di aumentare l efficacia e l efficienza del processo, migliorando la capacità di stabilire i giusti traguardi per l organizzazione progettuale e riducendo l impatto dei cambiamenti richiesti in corso d opera per via della facilità di comprensione delle conseguenze che tali cambiamenti comportano sul disegno generale. pag.6

7 2.2. Il metodo ASK per la gestione dei requisiti Così come la gestione del rischio, anche la gestione dei requisiti è un processo che accompagna tutta la durata del progetto, benché esso sia di importanza decisiva soprattutto nelle fasi iniziali della vita dello stesso. I requisiti si arricchiscono di dettagli mano a mano che si procede nel ciclo di vita e nello stesso tempo si precisano meglio sviluppandosi in direzioni Ambiente operativo Specifica dei Requisiti Progettazione funzionale Feedback di Analisi Specifiche Funzionali Gestione dei Requisiti Esigenze degli Stakeholders Feedback di Design Progettazione tecnica Specifiche Tecniche Feedback di utilizzo Feedback di Realizzazione Realizzazione del sistema Utilizzo del sistema spesso solo accennate inizialmente. Essi possono essere affiancati da nuovi requisiti, sostanzialmente modificati o addirittura abbandonati, se è il caso. La figura accanto mostra le relazioni tra le fasi principali di un progetto ed il processo di gestione dei requisiti. Dal momento che i requisiti possono influenzare le risorse necessarie allo sviluppo del progetto, la gestione dei requisiti è un processo che ha una doppia natura: tecnica e gestionale. Variare i requisiti porterà, in genere, non solo a variare la natura tecnica del sistema in sviluppo ma anche l allocazione di risorse necessarie a portare a termine il progetto. Il metodo ASK (Applying Stakeholder s Knowledge) è un modello di processo di gestione dei requisiti che contempla le seguenti attività: 1. Individuazione degli stakeholder 2. Raccolta dei problemi e dei bisogni 3. Stesura e documentazione dei requisiti 4. Verifica dei requisiti 5. Negoziazione dei requisiti 6. Accettazione dei requisiti Prodotto 1 2 La figura accanto mostra il flusso di lavoro tra le 4 attività citate. I collegamenti tratteggiati indicano le transizioni possibili, anche se non frequenti, mentre 6 quelli a linea continua rappresentano le transizioni più probabili ed i punti di innesco del processo. Ognuna di queste attività è descritta più approfonditamente in termini di input, output, metodi e tecniche di lavoro. Le competenze che occorre sviluppare per gestire in modo adeguato i requisiti di progetto, appartengono sia al dominio tecnico che a quello comportamentale. Esse spaziano dalle capacità di conduzione di problem solving e brain storming a quelle di sviluppo di indagini statistiche, dalle capacità comunicative a quelle psicologiche, dalla abilità nella conduzione dei role play a quella di gestione dei questionari ed interviste. Nella corretta definizione dei requisiti, è fondamentale riconoscere e coinvolgere fin dalle prime fasi gli stakeholder che trarranno vantaggi o svantaggi dall esito progettuale. In questo modo si ridurrà il rischio di dover rimettere in discussione, ad ogni nuova entrata di persone nel progetto, gli scopi ed i risultati attesi dello stesso evitando, inoltre, i ricicli di lavoro dovuti ad incomprensioni o semplicemente al distacco psicologico percepito dagli esclusi dal gruppo di progetto. Tipici stakeholder da considerare sono i committenti, gli utilizzatori diretti ed indiretti, i partecipanti allo sviluppo, i rappresentanti dell esercizio dei sistemi, il management 5 3 pag.7

8 ed i regolatori esterni (autorità di vario tipo non partecipanti al progetto ma interessate al rispetto di vincoli esterni predeterminati). Una tecnica di supporto alla raccolta e verifica dei requisiti molto efficace è denominata Viewpoint ovvero prospettiva ed è descritta in [4]. Per la stesura e documentazione dei requisiti può rivelarsi determinante l uso di un tool software in grado di automatizzare le parti più ripetitive delle attività e di permettere raggruppamenti, estrazioni ed incroci dei più vari tipi sui requisiti stessi. Le matrici di interrelazione serviranno, infatti, a rilevare inconsistenze e ridondanze tra i requisiti permettendone così la loro risoluzione prima che influenzino la realizzazione del software con i relativi ricicli di lavoro. Una gestione metodica dei requisiti potrà, dunque, permettere di incidere in modo rilevante sui rischi di progetto, riducendoli significativamente. 3. La stima di un progetto software Come si è già scritto, quando un progetto software non rispetta budget e tempi assegnati per fornire i risultati attesi, il problema potrebbe essere nella inadeguatezza del processo di gestione oppure nella inadeguatezza del processo di assegnazione delle risorse. Stabilire quale delle due ipotesi sia quella giusta o se lo siano entrambe, è una operazione sempre molto difficile. Indubbiamente vi sono indicatori collaterali che possono dare suggerimenti utili sia sulla qualità del processo di gestione che della capacità di stima. Ad esempio l utilizzo di metodi e tecniche avanzate di Project Management, l uso di standard o il livello di motivazione del gruppo potrebbero dare indicazioni sulla qualità della gestione, mentre l uso di modellistica consolidata in letteratura tecnica o di tool di provata efficacia tarati su data base di benchmarking affidabili potrebbero suggerire il livello di qualità del processo di stima. Tali indicatori possono far propendere l ago della bilancia da una parte o dall altra, ma la questione su quale possa essere la causa e quale l effetto del non rispetto dei vincoli di risorsa tende ad assomigliare troppo ad un loop circolare: un progetto che ha poche risorse allocate, tende a surriscaldarsi proprio come un motore in fuori giri e questo tende a portare all abbandono di pratiche di lavoro mature e di standards in favore di attivismi approssimativi e atteggiamenti ansiosi che, a loro volta, tendono a far disperdere le poche risorse rimaste. Il progetto si porta sempre più vicino al punto di non ritorno nel quale tutti cercano di abbandonare la barca finché c è tempo per farlo onorevolmente. La stessa cosa può capitare se, viceversa, le risorse sarebbero sufficienti ma il progetto viene gestito male. La stessa spirale di surriscaldamento descritta precedentemente si viene ad innescare non appena le riserve di grasso del progetto vengono consumate senza produrre un risultato apprezzabile. Questo comportamento è fin troppo frequente, come ci dicono le cronache di progetto raccontate dalle statistiche raccolte sul campo. Per ridurre i rischi di fallimento dovuti a queste cause occorre, dunque, agire sul fronte del miglioramento sia delle capacità e dei sistemi di Project Management sia della capacità e dei sistemi di stima quantitativa, che dei primi sono un sottoinsieme importante Cosa stimare? Per assegnare correttamente le risorse ad un progetto software, le principali variabili da stimare sono i costi, gli impegni lavorativi, le scadenze e la quantità di software da realizzare. Quelle citate non sono variabili indipendenti ma, anzi, sono fortemente collegate tra loro. I costi di un progetto software, infatti, sono essenzialmente costi di lavoro e quindi fortemente dipendenti dal costo unitario delle figure professionali utilizzate e dalla quantità di impegno lavorativo necessario per ogni figura professionale. Anche le scadenze temporali sono dipendenti dalla quantità di lavoro da erogare e dal numero di risorse impiegabili in parallelo. Infine, l impegno di lavoro per ogni figura professionale è dipendente dalla quantità di prodotto da realizzare e, naturalmente, dalla capacità produttiva che il gruppo di progetto riesce a mettere in campo. Alla base di tutta questa catena, quindi, vi è una valutazione della pag.8

9 quantità di software da realizzare. Un errore in questa stima si trasmette a macchia d olio in tutte le altre. Attualmente, nel mondo, si è diffusa in modo significativo la scelta di misurare il software in base alle funzionalità che esso offre ai suoi utilizzatori cioè, in definitiva, al suo valore d uso. La metrica funzionale più diffusa è sicuramente quella dei Function Point IFPUG [5] il cui documento di riferimento fornisce una serie di regole per il conteggio delle applicazioni software sia di nuovo sviluppo che soggette a manutenzione evolutiva. Il problema principale della Function Point Analysis è che, per poter applicare le regole standard previste nel manuale di riferimento, devono essere state chiarite e documentate le Specifiche Funzionali di dettaglio dell applicazione software interessata alla misura. In altri termini devono essere noti tutti i tracciati di output, le maschere di input, la struttura degli archivi logici fino a livello di campi elementari. Quasi sempre questo dettaglio è inesistente al momento della decisione sull assegnazione delle risorse ad un progetto che, in casi fortunati, è effettuata a seguito di uno studio di fattibilità più o meno accurato. Si verifica, quindi, il cosiddetto paradosso della stima: Una stima serve molto quando non si hanno abbastanza elementi per farla (avvio del progetto) e quando si è in grado di farla con assoluta precisione (rilascio del progetto) ormai non serve più. Per risolvere questo problema è nata la tecnica denominata Early Function Point Analysis (EFPA) Early Function Point Analysis Il metodo di stima degli Early Function Point è stato sviluppato con il preciso vincolo progettuale di mantenere la piena compatibilità con le regole standard dell IFPUG: gli EFP non sono una metrica alternativa ai Function Point (una variante), bensì una indicazione precoce del numero di Function Point che si otterrebbe per il progetto o l applicazione misurata, se si avesse a disposizione il giusto livello di dettaglio (o il tempo necessario) per effettuare un conteggio standard. La Early Function Point Analysis [6] [7] [8] è un metodo di pubblico dominio presentato nell ambito di diverse conferenze internazionali ed utilizzato con successo in molte organizzazioni. Esso è centrato su alcuni principi fondamentali: la classificazione analogica: basata sulla somiglianza tra oggetti software nuovi e oggetti software già noti; l aggregazione strutturata: basata sulla unione di un certo numero di oggetti di un livello in un oggetto di livello superiore; l approccio funzioni/dati: non sono necessarie ipotesi sul rapporto empirico tra dati e funzionalità (quanti processi elementari ci sono in media per ogni archivio) perché entrambe le componenti possono essere valutate autonomamente; l approccio multilivello: Se hai dettagli non devi buttarli via, se non ne hai non devi inventarli!. l uso di una tabella di derivazione: ad ogni oggetto software ai vari livelli di dettaglio della tassonomia classificativa, è assegnato un valore in FP che costituisce il suo contributo alla stima, sulla base di una tabella derivata analiticamente. Il metodo ha, quindi, una base analogica ed una analitica. La prima spinge l estimatore a scoprire somiglianze tra un nuovo pezzo di applicazione software e pezzi simili incontrati in altre applicazioni software e già classificati rispetto alle forme di aggregazione delle funzionalità o dei dati previste dal metodo. La seconda garantisce un fondamento certo alla stima in quanto i pesi dei diversi oggetti software non sono assegnati in base a considerazioni empiriche sui dati raccolti da progetti reali (e quindi soggetti a calibrazione e variazione), ma sono stabiliti in via concettuale, essendo legati al modo con cui sono stati costruiti i diversi oggetti software della struttura classificativa. I Gruppi di Dati Logici (LDG o semplicemente LD) corrispondono ai logical files della Function Point Analysis IFPUG, ma senza distinzione tra dati logici interni ed esterni (ILF ed pag.9

10 EIF) e con due livelli di complessità aggiuntivi. Quando le informazioni hanno un basso grado di dettaglio, infatti, è possibile che un archivio logico in prima istanza identificato come unico possa poi, successivamente suddividersi in due o più archivi logici distinti. Anche le funzionalità possono essere identificate a diversi livelli di dettaglio o di aggregazione. Una primitiva funzionale è il più piccolo insieme correlato di azioni autonomo e significativo per un utente esperto. Le primitive funzionali, se correttamente individuate, corrispondono alle Funzioni di Tipo Transazione della FPA (EI,EO,EQ). Esse si dividono in: Primitive di solo ingresso, Primitive di sola uscita, Primitive di solo colloquio. Le microfunzioni e le funzioni sono aggregati di primitive. Le macrofunzioni, Applicazione Macrofunzione Funzione Microfunzione Primitiva funzionale invece, sono aggregati di più funzioni. Il metodo fornisce i criteri per la classificazione appropriata degli aggregati funzionali in base alla loro numerosità interna prevista. Per ottenere una stima del numero di FP dell applicazione software da sviluppare o da mantenere in modo evolutivo è sufficiente disporre di una lista di funzionalità e dati da implementare che può contenere livelli di dettaglio anche disomogenei tra loro. La conoscenza di oggetti software (funzioni e dati) analoghi permetterà di attribuire ad ogni elemento della lista il suo giusto livello classificativo e di derivarne, quindi il contributo in FP. Ad ogni contributo fornito da strutture aggregate di livello superiore è associato un margine di incertezza che tiene conto della forzata mancanza di dettaglio. L incertezza sarà maggiore per i livelli più alti di aggregazione e sarà espressa attraverso la terna di valori: minimo più probabile massimo riferiti alla stima in FP. Se sulla base dell analisi storica di una serie sufficientemente lunga di stime si riscontrasse un errore sistematico (sovrastima o sottostima), è possibile prendere in considerazione un aggiustamento moltiplicativo ulteriore per prevedere il corretto numero di FP. In estrema sintesi, l idea innovativa del metodo è quella di lavorare sul riconoscimento non solo dei mattoni elementari alla base della costruzione (EI,EO,EQ,ILF ed EIF) ma anche delle strutture prefabbricate di livello superiore (macrofunzioni, funzioni, microfunzioni, archivi multipli). Le rilevazioni disponibili fino a questo momento indicano che la precisione del metodo è buona e l errore medio si mantiene al di sotto del 10%, permettendo oltretutto un risparmio di impegno, rispetto ad un conteggio standard, che può giungere fino ai 4/5. Il metodo EFPA, infatti, può essere utilizzato non solo quando mancano i dettagli per il conteggio standard ma anche quando, semplicemente, non si può o vuole impegnare sufficienti risorse per l applicazione del metodo completo. pag.10

11 4. Un processo integrato di gestione del rischio, dei requisiti e delle stime Se un azione di miglioramento compiuta separatamente sugli ambiti indicati in precedenza garantisce già significativi risultati per la riduzione del rischio progettuale, un azione combinata, che veda sinergicamente coinvolti i due aspetti, permette ancora maggiori benefici. L influenza reciproca esistente tra la qualità del processo di definizione dei requisiti progettuali e la stima delle risorse necessarie è, infatti, molto stretta, come è stato mostrato in precedenza. Quest ultima parte del documento è, dunque, dedicata alla descrizione di un quadro di riferimento per l integrazione dei processi di gestione del rischio SAFE, di gestione dei requisiti ASK e di stima anticipata EFPA, sperimentata operativamente attraverso l uso dei tool commerciali Requisite Pro della Rational Corporation e SFERA della D.P.O. Srl. L idea di base è stata quella di fare in modo che una corretta definizione e gestione dei requisiti operata fin dalle prime fasi di progetto, associata alla capacità di stimare rapidamente le risorse in base ai requisiti stessi, possa permettere un governo più efficace e rapido della rotta, operando le opportune manovre per evitare le secche che potrebbero far incagliare il progetto per mancanza di risorse. Il legame tra i processi indicati è semplice ed immediato. Se ad ogni requisito funzionale associamo la sua classificazione in base alla tassonomia prevista nel metodo EFPA, potremo facilmente utilizzare queste informazioni per generare una stima in FP dell applicazione richiesta e da qui procedere alla valorizzazione di tempi e costi necessari al progetto. Questo permetterà di allocare le risorse in modo coerente con le cose da fare riducendo, quindi, il rischio di non rispettare i vincoli stabiliti. D altra parte, una variazione dei requisiti richiesti potrà essere analizzata rapidamente rispetto all impatto che ha sul progetto evidenziando la necessità di destinare ad esso, ad esempio, ulteriori risorse. Nel caso in cui, nonostante le indicazioni sulla necessità di espandere il budget o le scadenze, si decida di mantenere quelli originari, le tecniche indicate permetteranno di fare una valutazione ragionata dell incremento di rischio. Questo è quello che descriveremo nell ultimo paragrafo Valutazione d impatto delle modifiche ai requisiti Come si può effettuare una valutazione ragionevole dell impatto che provocano le modifiche ai requisiti di un progetto quando vengono richieste in corso d opera? L uso congiunto delle tecniche esposte in questo lavoro insieme ad una tecnica di valutazione dello stato di avanzamento lavori tipica del Project Management, denominata Earned Value (Valore Assorbito), può dare, e ha già dato, risultati interessanti. Innanzitutto occorre precisare che non è dei risvolti tecnici riguardanti i cambiamenti della struttura o del funzionamento dell applicazione software che intendiamo occuparci in questo lavoro, bensì delle conseguenze in termini di uso di risorse e di rischio progettuale che le richieste di variazione possono determinare. Supponiamo, allora, che a seguito di una definizione iniziale di requisiti per un progetto software venga effettuata una classificazione delle funzionalità e dei dati in base al metodo EFPA. Il risultato dell applicazione di questa tecnica è, quindi, una stima in Function Point della dimensione funzionale dell applicazione software da sviluppare. Utilizzando modelli di produttività e di costo opportuni, legati all ambiente specifico di sviluppo, siamo in grado di ottenere una previsione dell impegno, durata e costo di progetto. Il budget e le scadenze possono, quindi, essere allocati in modo coerente con le richieste ed il progetto può iniziare il suo percorso. Dopo un certo periodo di tempo, però, gli stakeholder richiedono dei cambiamenti di rilievo ai requisiti che implicano la necessità di revisionare sia il disegno funzionale e tecnico che il piano di lavoro progettuale. Come valutare, a questo punto, la correttezza dell allocazione delle risorse o, in caso di mantenimento del budget originario, l aumento o diminuzione del rischio associato? pag.11

12 4.2. Revisione del budget Avendo stabilito un collegamento automatico tra requisiti e metodo EFPA sarà semplice ottenere una nuova stima di Function Point relativa alla nuova configurazione dei requisiti. Usando tale stima con gli stessi modelli di produttività usati in precedenza otterremo delle nuove previsioni di tempi, impegni e costi. Tali previsioni, però, saranno relative ad un progetto come se questo partisse da zero. In realtà essendo la modifica dei requisiti giunta in corso d opera, il progetto ha già impegnato una parte di quelle risorse ed ha prodotto una parte di risultati. Il problema, quindi, è quello di ottenere una valutazione delle cosiddette previsioni a finire per il progetto, una stima, cioè, delle sole risorse necessarie dal momento della variazione in poi. Per ottenere questo risultato possiamo ricorrere alla tecnica dell Earned Value (EV) detto anche Valore Assorbito. L Earned Value è un valore che può essere calcolato in qualsiasi momento della vita progettuale ed è un indicatore di tipo cumulativo, tiene, cioè, traccia in sé della storia passata del progetto. Esso integra le misure di scopo, costo e schedulazione. Per poter utilizzare proficuamente l Earned Value occorre introdurre i seguenti termini [9], tutti relativi ad una certa data di riferimento delle rilevazioni (generalmente detta Time Now TN): Il costo di budget del lavoro schedulato (budgeted cost of work scheduled: BCWS), pari al costo stabilito a budget per le attività la cui esecuzione era prevista, nel piano di lavoro originario, fino alla data indicata TN. Il costo consuntivo del lavoro svolto (actual cost of work performed: ACWP), corrispondente al costo reale sostenuto per le attività effettivamente svolte alla data TN, che potrebbero essere eventualmente diverse da quelle previste nel piano originale. L earned value (budgeted cost of work performed: BCWP) pari al valore di budget delle attività effettivamente svolte alla data TN. Questi tre valori sono usati in combinazione tra loro per fornire risposte alle domande circa la corrispondenza delle attività svolte rispetto a quelle pianificate. Comuni misure derivate sono: cost variance (CV = BCWP ACWP), schedule variance (SV = BCWP BCWS), cost performance index (CPI = BCWP / ACWP) e schedule performance index (SPI = BCWP / BCWS). Il CPI cumulativo (la somma di tutti i singoli BCWP divisi per la somma di tutti i singoli ACWP) è comunemente usato per predire i costi a finire del progetto mentre lo SPI cumulativo è usato, talvolta, per predire la data di completamento delle operazioni. L EV o BCWP rappresenta, in sostanza, la quantità di risorse del piano originario che sono state teoricamente consumate perché relative ad attività già svolte o in corso, indipendentemente da quante risorse sono state consumate realmente, cioè dai dati consuntivi rilevati. Il confronto tra BCWP e consuntivi alla data (ACWP) può permetterci di sapere, in sintesi, se il progetto sta spendendo di più o di meno del previsto a parità di cose realizzate. Il confronto tra BCWP e preventivo alla data (BCWS), invece, può permetterci di sapere, in sintesi, se il progetto è in anticipo o in ritardo rispetto ai piani originari. Non è nostro scopo di illustrare nel dettaglio la tecnica che può essere approfondita altrove, la cosa importante è osservare che se alla nuova stima che abbiamo ottenuto a seguito della variazione dei requisiti (New Budget At Completion: NBAC) togliamo proprio il BCWP calcolato al momento della revisione, avremo una previsione a finire delle risorse necessarie al progetto che può essere corretta con un indicatore del grado di efficienza raggiunto fino a quel momento (ACWP/BCWP). In effetti occorre anche considerare che del lavoro già svolto (BCWP), una parte può essere ancora valida anche dopo il cambiamento di requisiti richiesto, mentre un altra sarà stata del tutto inutile perché relativa a requisiti che sono stati abbandonati o modificati. Per tenere conto di questo occorrerà moltiplicare il BCWP per una percentuale R che indichi il grado possibile di riuso del lavoro già svolto. Per stimare R possiamo porci la seguente domanda: quanta parte del lavoro già fatto è riutilizzabile anche dopo il cambiamento di requisiti? Se riusciamo a attribuire un valore percentuale a questa domanda (ad esempio si pag.12

13 ritiene che il lavoro fatto sia recuperabile all 80%) allora il valore da sottrarre alla nuova previsione totale per ottenere la previsione a finire sarà l 80% del BCWP. Il grafico seguente può essere di aiuto per illustrare il giusto procedimento di analisi. Ecco la spiegazione delle sigle usate nel grafico stesso: Sia a la curva relativa all assorbimento di risorse previsto nel piano originario, b la curva dell earned value, c la curva relativa alla nuova valutazione di budget a seguito del cambiamento di requisiti ed infine d la cost curva relativa ai consuntivi ed alle previsioni a finire. ACWP rappresenta il consuntivo delle spese fatte fino al momento TN. NBCWS (New Budgeted Cost of Work Scheduled) è la nuova previsione di uso delle risorse alla data TN dopo cioè la revisione dei requisiti. BCWP rappresenta l Earned Value calcolato all istante TN e riferito al piano originario. OBCWS (Old Budgeted Cost of Work Scheduled) è la previsione originaria di uso delle risorse alla data TN. OBAC (Old Budget At Completion) è la previsione di spesa totale del budget originario. NCD(New Completion Date) rappresenta la nuova data prevista di fine progetto. OCD (Old Completion Date) rappresenta la vecchia data prevista di fine progetto. In definitiva, allora, si avrà che la previsione finale (Budget Estimated At Completion: BEAC) sarà data dalla seguente formula: BEAC = ACWP + (NBAC BCWP*R) * (ACWP/BCWP) Il budget potrà così essere rivisto in modo adeguato sia alla implementazione dei nuovi requisiti che al comportamento produttivo manifestato fino a quel momento dal progetto Revisione del rischio Cosa succede, invece, se il budget o le scadenze non possono essere ritoccate e si vuole mantenere valida la previsione iniziale di costo (OBAC) pur accettando la variazione di requisiti? Pensiamo, ad esempio, ad una gara a corrispettivo fisso. In questo caso dovremmo considerare in che modo venga influenzato il rischio di progetto da questa circostanza. In effetti la quantità (BEAC-OBAC) rappresenta la quota del nuovo budget previsionale che dovrebbe essere compressa attraverso una richiesta di maggior efficienza (rispetto alla produttività media) al gruppo di lavoro. Potremo, allora, valutare la rischiosità legata al mancato rispetto del budget originario nel modo seguente. Per prima cosa valutiamo il danno relativo al mancato rispetto del budget di progetto in una scala da 1 a 10, dove 10 rappresenta il fallimento del progetto ed 1 un lieve inconveniente. Tale valutazione è variabile in quanto vi sono progetti che si devono realizzare obbligatoriamente e per i quali mantenersi nel budget è importante ma non vitale, mentre vi sono altri progetti che sarebbero cancellati in caso di eccessivo consumo di risorse. Valutiamo, poi, per semplicità, la probabilità che il progetto riesca a rispettare il budget considerando che essa è: d c b ACWP a NBCWS BCWP OBCWS OBAC NBAC TN OCD NCD BEAC time pag.13

14 direttamente proporzionale alla durata residua del progetto P1=((NCD-TN)/NCD) più tempo c è a disposizione per recuperare, più alta sarà la probabilità di farcela; direttamente proporzionale al rapporto tra il budget vincolato e quello previsto P2=(OBAC/EAC) più alto è il rapporto e meno costi sono da recuperare e, quindi, più facile sarà farlo; direttamente proporzionale al Cost Performance Index (CPI) più alto è il CPI e più efficiente è stato il progetto fino a quel momento e, quindi, la probabilità che recuperi è più alta. Nel caso che gli indici introdotti precedentemente siano tutti inferiori all unità, si potrebbe pensare di utilizzare come valore della probabilità di riuscire a mantenere il budget, il loro prodotto numerico Pyes=P1*P2*CPI. L evento opposto, cioè il mancato rispetto del budget, sarà allora il complemento ad uno di tale probabilità Pno= 1 Pyes. Il rischio associato all evento budget non rispettato è dunque il prodotto tra il voto in scala 10 attribuito al danno e la probabilità Pno. A seguito di questa valorizzazione si potrà decidere un opportuno piano di azione consistente in prevenzione, sorveglianza e contrasto, come previsto dal metodo SAFE. 5. Conclusioni In questo lavoro abbiamo esaminato tre processi fondamentali che possono dare un contributo molto elevato alla riduzione del rischio di progetto, specie se vengono fatti interagire in modo coordinato tra loro. Sono stati presentati i metodi SAFE per la gestione del rischio, ASK per la gestione dei requisiti ed EFPA per la stima dei Function Point mostrando, infine, un esempio di utilizzo delle tecniche stesse per la valutazione d impatto delle modifiche ai requisiti sul budget e sul rischio di progetto. 6. Referenze Alcuni dei lavori citati possono essere recuperati su internet agli indirizzi: oppure [1] Gluch, David P., A construct for describing software development risks, Technical Report CMU/SEI-94-TR-14, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 1994 [2] Meli, Roberto SAFE: a method to understand, reduce, and accept project risk, ESCOM- ENCRESS 98 - Project Control for 2000 and Beyond - May 27-29, Rome, Italy. [3] [4] Sommerville, Ian and Sawyer, Pete, Requirement Engineering: A good practice guide, John Wiley & Sons, 1997 Baffins Lane, Chichester, West Sussex England [5] International Function Point Users Group: "Function Point Counting Practices Manual", Release 4.0, 1994 [6] R. Meli, Early Function Points: a new estimation method for software projects, ESCOM 97, Maggio 1997, Berlino [7] R. Meli, Early and Extended Function Point: a new method for Function Points Estimation, IFPUG Fall Conference, settembre 1997, Scottsdale, Arizona USA [8] L. Santillo, R. Meli, Early Function Points: some practical experiences of use, ESCOM- ENCRESS 98, Maggio 1998, Roma [9] PMI Standards Committee, A Guide to the Project Management Body of Knowledge, Project Management Institute, Upper Darby, PA USA pag.14