La gestione dei progetti informatici 1

1/38

G. Casadei A.G.B. Teolis

LA GESTIONE DEI PROGETTI INFORMATICI Prima parte: i progetti 1. La definizione

1.0 Introduzione 1.1 WBS, schema di progetto, piano di progetto e Gantt 1.2 Fasi di un progetto 1.3 Risorse costi vincoli e percorso critico 1.4 Verifica e controllo 1.5 CPM e Pert

1.6 La pianificazione come compromesso fra tempo e risorse REVISIONE DEL 10/11/2003

La gestione dei progetti informatici 1

2/38

Prima parte: i progetti In questa prima parte viene descritta lanatomia dei progetti, cio vengono illustrati, nei singoli ca-pitoli, i metodi per

- descrivere un progetto, - valutarne la fattibilit (anche dal punto di vista economico) e gestirlo temporalmente, - valutare quantitativamente gli elementi significativi, - organizzarne le attivit in maniera da raggiungere gli obiettivi fissati.

La capacit di costruire programmi si basa su due competenze: luna, acquisita bottom up, consiste nella conoscenza di linguaggi di programmazione e laltra, acquisita top down, consiste nel saper scomporre problemi in sottoproblemi. Analogamente, la capacit di gestire progetti (software) si ba-sa su due competenze: una bottom up che parte dalle attivit, ne valuta tempi e costi e le aggrega in un progetto; laltra top down parte dagli obiettivi del progetto, li scompone in sotto obiettivi forma-lizzando le fasi per raggiungerli sino a individuare le singole attivit (con i relativi tempi di svolgi-mento, risorse da impiegare e costi). Questa prima parte del libro si articola in quattro capitoli: la definizione, la gestione, le metriche e i modelli. Nel primo vengono illustrati i concetti, gli strumenti e i metodi necessari per costruire la documen-tazione relativa ai progetti e per la loro conduzione ottimale.. Nel secondo vengono esposte le azioni rilevanti per la gestione dei progetti, gli attori coinvolti (da parte del committente e da quella del fornitore) e i rispettivi ruoli. Nel terzo sono introdotte le tecniche quantitative per valutare analiticamente i parametri fondamen-tali in gioco (impegno, tempi, costi, etc). Nel quarto, infine, sono illustrati i principali modelli utilizzati per articolare un progetto in fasi ope-rative.

La gestione dei progetti informatici 1

3/38

1. La definizione In questo Capitolo viene data la definizione di progetto e vengono illustrati i metodi per costruire la documentazione relativa ai progetti e le operazioni formali connesse. Il primo argomento il con-cetto di attivit e gli attributi che consentono di organizzarle in un Gantt. Il secondo argomento con-siste nel descrivere un progetto come un insieme strutturato di attivit, mediante la scomposizione del progetto in fasi. Il terzo argomento illustra come attribuire risorse e costi alle singole attivit e come individuare il percorso critico. Il quarto argomento costituito dalla verifica e dal controllo dellavanzamento di un progetto e dai metodi per la ripianificazione. Il quinto argomento riguarda il Pert, un metodo alternativo al Gantt, per descrivere le attivit nel tempo. 1.0 Introduzione Nellambito degli argomenti trattati in questo testo, un insieme di attivit si chiama progetto quando sono soddisfatte tutte le seguenti caratteristiche

1. necessaria una pianificazione; 2. esiste un obiettivo specifico e raggiungibile; 3. si pu individuare una durata predeterminata (almeno in linea di principio); 4. esistono risorse disponibili (con vincoli predefiniti); 5. linsieme delle attivit sufficientemente complesso; 6. le attivit non siano la ripetizione (quasi esatta) di esperienze gi fatte.

Per esempio, il cos detto Progetto Apollo (il piano varato dal governo americano negli anni ses-santa per portare un uomo sulla luna) non in realt un progetto in questa accezione in quanto man-cano le condizioni 2, 3 e 4; infatti:

- non aveva un obiettivo specifico e raggiungibile al momento del suo varo (il piano aveva come scopo quello di rendere raggiungibile un obiettivo);

- non era possibile predeterminare la durata (esisteva solo lesigenza di carattere generale di raggiungere lobiettivo entro il decennio);

- non era possibile valutare le risorse in maniera analitica. Altro esempio che non soddisfa la definizione data in questo contesto il cosi detto Progetto Man-hattan che aveva come obiettivo la costruzione della prima bomba atomica. Daltra parte, neppure linsieme delle attivit svolte da una catena di montaggio un progetto (no-nostante soddisfi le prime cinque condizioni) perch consiste in una ripetizione seriale di azioni per raggiungere ripetutamente uno stesso obiettivo specifico. Questi esempi mostrano che il concetto di progetto, cosi come definito, richiede che siano soddisfat-ti dei vincoli abbastanza stringenti e non si adatta n alle imprese troppo grandi n a quelle troppo semplici. Si sottolinea comunque che non esiste progetto senza limiti temporali predefiniti e senza la disponi-bilit delle risorse finanziarie e tecnico-scientifiche necessarie. In particolare, non possono essere chiamati progetti le iniziative che prevedono attivit per la messa a punto di tecniche non ancora e-sistenti (o puramente sperimentali) o presuppongono di utilizzare uno strumento non ancora dispo-nibile sul mercato. Inoltre non costituiscono un progetto le attivit di una sola persona, oppure le attivit di pi persone che non interagiscono, oppure ancora fare la decimilionesima bottiglia, mentre costituisce un pro-getto fare la decima centrale elettrica o la quinta enciclopedia multimediale perch nessuna di que-ste pu essere la esatta ripetizione di una delle precedenti. In sintesi, supponendo che linsieme delle attivit sia sufficientemente complesso e non costituisca la ripetizione esatta di cose gi fatte e che esistano le risorse tecnologiche, economiche e di cono-scenza, un progetto caratterizzato da:

La gestione dei progetti informatici 1

4/38

1. obiettivo, 2. tempi e 3. costi

che devono essere integrati nella pianificazione. Nel resto del capitolo vengono esposti essenzialmente i metodi formali per svolgere la pianificazio-ne (e la ripianificazione) di un progetto, cio per redigere il piano (e mantenerlo aggiornato in corso dopera). 1.1 WBS, schema di progetto, piano di progetto e Gantt Sia P un insieme finito; una relazione binaria su P un sottoinsieme E P P; per indicare che due elementi x,yP stanno nelle relazione E si scrive sia E(x,y) (notazione prefissa) sia xEy (nota-zione infissa). Una relazione di preordine su P una relazione binaria E, che verr indicata con in forma infissa, che soddisfa le due propriet:

riflessivit xP: (x, x) E ovvero x x, transitivit x, y, z P: (x, y) E e (y, z) E (x, z)E ovvero x y, y z x z.

Un preordine si dice ordine (parziale) se gode della seguente propriet

antisimmetria x, y P: (x, y) E e (y, x) E x = y ovvero x y, y x x= y. Data una relazione qualunque E P P, si dice chiusura riflessiva il pi piccolo sottinsieme E P P che contiene E e gode della propriet riflessiva; facile vedere che E = E , dove linsieme delle coppie (x,x), xP. Data una relazione qualunque E P P, si dice chiusura transitiva il pi piccolo sottinsieme E P P che contiene E e gode della propriet transitiva. Esercizi E1. Dato un insieme finito P, scrivere lalgoritmo che per ogni relazione E su P costruisce la chiu-sura transitiva; mostrarne la terminazione. Le relazioni su insiemi finiti spesso si raffigurano con grafi orientati: i nodi del grafo sono gli ele-menti dellinsieme e le frecce rappresentano una coppia (ordinata) della relazione. Per esempio, la figura 1.1.a mostra una relazione la cui chiusura riflessiva e transitiva un preordi-ne che non un ordine (parziale) perch contiene un ciclo; la figura 1.1.b mostra una relazione la cui chiusura riflessiva e transitiva un ordine (parziale). Sia P un insieme ordinato (mediante E); un sottinsieme P P eredita una struttura dordine me-diante E = E P P. Sia P un insieme ordinato; P P si dice una catena se per ogni x, yP si ha o x y oppure y x.

La gestione dei progetti informatici 1

5/38

a a b f b c c d e d g e 1.1. a 1.1. b

Figura 1.1 Sia P un insieme ordinato e sia data una funzione P N (insieme dei numeri naturali) che sar det-ta durata; gli elementi di P preimmagini di 0 si dicono eventi e gli altri si dicono attivit. Una coppia (P, ) si dice WBS (Work Breakdown Structure); questa struttura rappresenta un ele-mento fondamentale nella descrizione di un progetto e cattura lidea dellelenco delle cose impor-tanti nel contesto considerato (gli eventi o le attivit, cio gli elementi dellinsieme P); caratteriz-zata dallordine , che cattura lidea della precedenza tra attivit ed eventi. Una terna (P, , d) si dice schema (di progetto) se in P esiste un primo e un ultimo elemento, tipi-camente indicati con e . Un qualunque WBS pu sempre essere completato aggiungendo e ( P) ed estendendo opportunamente lordine (ponendo per ogni x P, x e x ) e la funzione d (ponendo d()=d()=0). Dato uno schema (P, , d), una funzione t: P Z (insieme dei numeri interi) si dice assegnazione temporale se

x, y P, x y t(x) + d(x) t(y). La funzione t definisce il tempo in cui inizia una attivit o si verifica un evento ed esprime lidea in-tuitiva che una certa attivit o un evento successivi ad una attivit possono accadere solo quando questultima terminata. Si noti come due elementi x ed y non confrontabili nellordine (cio n (x, y), n (y, x) appartengono alla relazione) possono essere contemporanei: cio non esiste nessun vincolo tra t(x) e t(y). Uno schema con una assegnazione temporale si dice piano di progetto. Esiste un metodo grafico particolarmente efficace per descrivere gli schemi che abbiano una asse-gnazione temporale: i diagrammi di Gantt. Esempio. Dato P={a, b, c, d, e}, siano date le funzioni d e t definite dalle seguenti tabelle

d a 0 b 3 c 3 d 3 e 0

t a 3 b 4 c 5 d 8 e 12

e sia lordine su P quello mostrato in figura 1.2.

La gestione dei progetti informatici 1

6/38

b d a e c

Figura 1.2

a b c d e 3 4 5 6 7 8 9 10 11 12

Figura 1.3 Oltre alla rappresentazione della pura relazione dordine di figura 1.2, particolarmente significati-vo il diagramma di Gantt (riportato in figura 1.3) che descrive anche la particolare funzione t scelta. Come si vede, un diagramma di Gantt ha sulle ordinate tante righe quanti sono gli elementi del WBS (eventi e attivit); sulle ascisse viene riportato il range della funzione t (linizio di una attivit o listante in cui accade un evento); convenzionalmente lunit di tempo viene scelta in modo tale da avere a che fare solo con numeri interi (giorni settimane o mesi). Di norma, gli eventi sono con-trassegnati da un simbolo puntiforme (per esempio un triangolino) e le attivit da un segmento (la cui lunghezza ne indica la durata). In uno schema, la funzione d essenzialmente intrinseca (cio legata alle caratteristiche delle attivi-t da svolgere e alle risorse disponibili), mentre assegnare la funzione t in larga misura discrezio-nale (perch linizio delle attivit pu anche essere posposto a piacere).

La gestione dei progetti informatici 1

7/38

a b c d e 3 4 5 6 7 8 9 10 11 12

Figura 1.4 Come esempio si possono considerare i diagrammi di Gantt di figura 1.4 e figura 1.5 che utilizzano lordine di figura 1.2 e la durata della tabella precedente fanno riferimento rispettivamente alle due seguenti tabelle per t.

t a 3 b 5 c 4 d 8 e 12

t a 3 b 4 c 4 d 9 e 12

a b c d e 3 4 5 6 7 8 9 10 11 12

Figura 1.5 La tabella seguente mostra una funzione t che non una assegnazione temporale per lordine di fi-gura 1.2..

La gestione dei progetti informatici 1

8/38

t a 5 b 3 c 4 d 10 e 11

Infatti, per esempio, i tempi di inizio di b e di c non sono compatibili con lordine rispetto ad a e il tempo di inizio di e non compatibile con la durata di d. Dato un piano di progetto, si dice durata totale del progetto la quantit t() + d()- t(). Esercizi E2. Dato P={a, b, c, d, e, f, g}; lordine la chiusura riflessiva e transitiva di {(a, b), (a, g), (b, c), (g , f), (g, e), (f, d), (e, d), (c, d)} P2, le funzioni d e t sono date dalla seguente tabella:

d t a 3 3 b 5 6 c 7 12 d 2 25 e 8 15 f 4 12 g 6 6

a) verificare che i valori assegnati per la funzione t siano una assegnazione temporale; b) in caso positivo, disegnare il diagramma di Gantt; altrimenti correggerla in modo che lo sia e

disegnare il diagramma di Gantt. E3. Con riferimento ai dati dellesercizio precedente come esempio, costruire un programma per ri-spondere alle domande a) e b). Particolare cura deve essere posta nel determinare la struttura per rappresentare la conoscenza sul problema, in modo da ottenere una soluzione efficiente. E4. Con riferimento agli esercizi precedenti scrivere un programma che, partendo da uno schema di progetto, determini la funzione t che minimizza la durata complessiva del progetto. E5. Con riferimento agli esercizi precedenti scrivere un programma che, partendo da uno schema di progetto, determini una assegnazione temporale t che implica lo svolgimento di una sola attivit alla volta. Il tempo Lasse delle ascisse di un diagramma di Gantt misura il tempo. Nella schematizzazione vista (per la definizione della funzione t) il tempo essenzialmente riducibile allinsieme degli interi (con la sua struttura dordine); questo presuppone che possibile fissare un intervallo di tempo che sia ele-mentare nel contesto in considerazione, cio rappresenti il (massimo) potere risolutivo con cui si vogliono osservare i fenomeni (per quello che riguarda sia il tempo di inizio delle attivit, sia la loro durata); esempi sono: lora, il giorno, la settimana o il mese.

La gestione dei progetti informatici 1

9/38

Particolare attenzione va posta quando le unit temporali di lavoro effettivo devono essere sovrap-poste al calendario reale a causa della presenza in questultimo delle giornate festive (e prefestive) in uso nei paesi coinvolti nel progetto. Usualmente i prodotti commerciali che consentono di preparare, editare e mantenere i Gantt (e la documentazione di progetto) si prendono cura di questo problema. Il Tracking Il diagramma di Gantt, che presuppone il WBS e la valutazione delle funzioni d e t, uno dei do-cumenti fondamentali della pianificazione di un progetto. Oltre che nella fase preliminare di pianifi-cazione, ha anche un ruolo determinante nella gestione del progetto, in particolare in quella attivit che si chiama tracking. Il Gantt mostra le cose da fare e indica quando devono essere fatte; il tra-cking la registrazione delle cose che sono state effettivamente fatte riportando le date reali. Mentre il Gantt una descrizione a priori, il tracking una registrazione a posteriori (si veda la fi-gura 1.6) e, riportata sullo stesso grafico del Gantt, permette di valutare anche visivamente gli sco-stamenti fra previsione e attuazione e quindi costituisce uno strumento essenziale per mantenere il controllo del progetto. a b c d e 3 4 5 6 7 8 9 10 11 12 13

Figura 1.6

PROGETTO La parola progetto viene spesso usata in due accezioni diverse. Nella prima, progetto indica un insieme di attivit ordinate, dotate di durata e costo e sistemate op-portunamente nel tempo; caratterizzato anche da una durata e un costo totali. Un esempio duso di questa accezione per esempio la frase il progetto in ritardo che indica che la durata reale superiore a quella pianificata. Nella seconda accezione la parola progetto indica un documento che descrive linsieme delle attivi-t ordinate (v. accezione precedente) in vario modo (per esempio solo con un Gantt oppure con la documentazione di progetto che verr descritta successivamente). Un esempio duso la frase se-guente: il progetto deve essere preparato entro la settimana prossima. Gli ingegneri usano spesso questa accezione: il progetto di una casa indica quasi sempre un insieme di disegni e documenta-zione tecnica. Esistono anche delle frasi ancipiti come per esempio il progetto troppo costoso che pu riferirsi sia al documento che alla realizzazione. In linea di principio, nel presente contesto la parola progetto assume (quasi sempre solo) il primo significato.

La gestione dei progetti informatici 1

10/38

1.2 Fasi di un progetto Dato uno schema (P, , d), sia F P con

x, y F: zF : x z e z y. La terna (F, , d), con il che indica la restrizione a F, si dice sottoschema. Gli elementi x e y si dicono inizio e fine del sottoschema; in maniera informale un sottoschema F un insieme di attivit ed eventi che ha un primo e un ultimo elemento, quindi pu essere collassato (o contratto) in un solo punto; ci possono essere altri elementi di P non confrontabili con gli elementi di F. Se per F P oltre alla condizione precedente vale anche che

zP-F: zF :y z oppure z x, cio tutte le altre attivit o eventi sono precedenti o successivi, allora la terna (F, , d) si dice fase (di progetto). Pu accadere che linsieme P possa essere partizionato in fasi di progetto (disgiunte) F1, F2 che costituiscono una catena. Esercizi E6. Definire lordine rispetto cui le fasi di progetto costituiscono una catena. In ogni area disciplinare (ingegneria civile, informatica, ingegneria meccanica) si sono evoluti me-todi diversi per condurre con successo i vari progetti. In ciascuna di queste aree sono state poi indi-viduate metodologie diverse per specifiche classi. Le varie metodologie per condurre con successo i progetti nellarea informatica sono descritte nel quarto capitolo. Queste metodologie differiscono (intrinsecamente) non solo per gli obiettivi e i risultati che vogliono raggiungere, ma (formalmente) per le varie fasi in cui possono essere partizionati i diversi progetti. Ad esempio in un progetto di edilizia possono essere determinanti le fasi di prospezione geologica, scavo per le fondamenta o ap-provvigionamento dei materiali da costruzione; in progetti di ingegneria meccanica invece sono de-terminanti le fasi di indagine di mercato, localizzazione degli stabilimenti per la produzione e indi-viduazione delle catene di fornitura. Come si visto, per descrivere uno schema di progetto necessario elencare tutti gli eventi e le at-tivit coinvolti, con la indicazione delle rispettive relazioni di precedenza e le durate. Queste attivit sono spesso centinaia e per individuarle viene sfruttata la possibilit di ripartire il progetto in fasi, in modo che ogni fase del progetto abbia associato un insieme caratteristico di attivit che devono es-sere prese in considerazione (o per escluderle o per ripeterle opportunamente al fine di adeguarle al-le esigenze del progetto specifico). Per fissare le idee e per illustrare degli esempi, si fa riferimento ad uno dei modelli di progetto in-formatico, pi semplice e di uso pi frequente tra quelli che sono illustrati nel seguito (Capitolo 4), che si chiama a cascata o waterfall (Vedi figura 1.7). Poich attualmente gli scopi sono solo illustrativi, le fasi non sono esattamente quelle classiche, che verranno esaminate successivamente.

La gestione dei progetti informatici 1

11/38

1. Preprogetto 1.0 Pianificazione del preprogetto 1.1 Requisiti dellutente 1.2 Preanalisi 1.2.1 Modello di utente 1.2.2 Modello funzionale e modello dei dati 1.2.3 Modello tecnologico 1.2.4 Valutazione dei rischi I 1.3 Valutazione dei costi

1.4 Validazione

1.5 Pianificazione del progetto 1.5.1 Determinazione del WBS 1.5.2 Determinazione delle risorse necessarie e determinazione di d per ogni attivit 1.5.3 Determinazione dei costi delle singole attivit 1.5.4 Pianificazione: disponibilit delle risorse, determinazione di t e diagramma Gantt 1.5.5 Valutazione dei rischi II 1.6 Validazione 2. Progetto

2.0 Preparazione (finanziamenti, attivit amministrativa, gare, contratti, ecc.) 2.1 (Requisiti dellutente) 2.2 Analisi 2.3 Validazione 2.4 Realizzazione 2.5 Test e accettazione 2.6 Avviamento della gestione (o esercizio) 2.7 Post completamento 2.8 Avvio della manutenzione

Figura 1.7 La (macro)fase di preprogetto abbastanza indipendente dal modello di progetto adottato; sostan-zialmente divisa in due parti: nella prima (da 1.1 a 1.4) occorre fare una preanalisi, cio una descri-zione, a livello alto, delle caratteristiche generali della realizzazione; questa parte, che in altri conte-sti chiamata studio di fattibilit (vedi capitolo 2), deve raccogliere in maniera organica i requisiti degli utenti e conseguentemente trattare almeno i seguenti punti:

1. gli utenti (che spesso sono anche migliaia) classificati per tipologie ed esigenze logistiche, 2. le funzioni (come percepite dalle varie tipologie utenti) e i dati, come usuale in questo con-

testo, 3. le apparecchiature presumibilmente necessarie per lesercizio dellapplicazione, 4. i punti critici e i rischi prevedibili.

Questa prima parte termina con la produzione di un documento formale che contiene le quattro parti (relative ai punti precedenti) e una prima valutazione (anche approssimata) dei costi: il documento deve essere approvato esplicitamente (validazione). La seconda parte di questa prima fase, sostanzialmente la pianificazione del progetto che consi-ste in:

1.5.1 fare lelenco delle attivit del progetto con la struttura delle precedenze (cio definire il WBS),

La gestione dei progetti informatici 1

12/38

1.5.2 valutare, per ogni attivit, limpegno necessario per portarla a termine e quindi la dura-ta,

1.5.3 stimare le risorse disponibili e definire, per ogni attivit, il costo, 1.5.4 in base alla disponibilit globale delle risorse e dei vincoli (per quanto pu essere no-

to), definire una funzione t (provvisoria) e quindi un primo Gantt, 1.5.5 valutare i punti critici e rideterminare i rischi con riferimento anche allo sviluppo tem-

porale e al costo (analitico) del progetto. Anche questa seconda parte deve terminare con una approvazione esplicita dei documenti prodotti (validazione). Nel punto 1.5.1 si deve utilizzare la scomposizione del progetto in fasi; ogni modello di progetto ha una propria partizione in fasi e ciascuna di queste prevede un elenco di possibili attivit ed eventi che sono caratteristici della fase; un modello di progetto (come si vedra nei capitoli 2 e 4) si carat-terizza con un WBS tipo, che una sorta di menu da cui si scelgono gli elementi da includere (alcuni opportunamente ripetuti) nel WBS del progetto. Il progetto vero e proprio inizia con una fase che raggruppa tutte le attivit (di carattere amministra-tivo e finanziario) che sono necessarie per rendere disponibili le risorse (ricerca di finanziamenti, espletamento di gare, stipula di contratti, ecc.). Quindi segue una serie di fasi che richiamano il ci-clo di vita del software. La raccolta dei requisiti dellutente (che deve essere rifatta se nel preproget-to non stata portata a termine in maniera dettagliata) e lanalisi sono quelle classiche e termina-no con un documento che, per le realizzazioni di cui si parla in questo contesto, di dimensioni no-tevoli (anche parecchie centinaia di pagine). La validazione un punto critico perch richiede la comprensione, da parte di chi la effettua, di tutti i documenti dellanalisi: per questo sono necessarie parecchie competenze diverse1. La realizzazione (di quanto individuato dallanalisi) viene condotta con la metodologia classica che si studia in ingegneria del software e presenta due difficolt principali: il coordinamento di parecchi sviluppatori che lavorano in parallelo (talvolta parecchie decine) e il vincolo di terminare entro un tempo prestabilito. Naturalmente, questa fase comprende, oltre la programmazione, anche il system design, il program design e il debugging (unit test). La fase di test e accettazione pu essere anche molto complessa perch comporta il controllo della funzionalit del prodotto (che pu coinvolgere anche decine di tipi di utenti diversi) e il controllo delle prestazioni; questi controlli sono difficili da eseguire perch presuppongono la ricostruzione esatta dellambiente in cui il sistema sar utilizzato (che talvolta prevede migliaia di utenti contem-poranei). Lavviamento in gestione una fase delicata e cruciale per il successo del progetto; la sua natura, pi che informatica o tecnica, di carattere logistico e organizzativo; comporta, per esempio, laddestramento di parecchie centinaia di utenti con durate che vanno da una a parecchie giornate, linstallazione di nuove stazioni di lavoro o lupgrade delle vecchie, linstallazione del software prodotto (spesso in pi server geograficamente distribuiti) e infine lassistenza agli utenti per lo startup (che pu avvenire in varie strategie che vanno dallavvio contemporaneo allora zero per tutte le funzionalit e per tutti gli utenti coinvolti alla partenza incrementale per gruppi di utenti di-stinti geograficamente o per funzionalit).

1 La difficolt di realizzare le condizioni per effettuare una affidabile validazione dellanalisi giustifica la criticit di questa fase e ha favorito la nascita di strategie alternative per la strutturazione in fasi e quindi per i modelli (vedi capito-lo 4).

La gestione dei progetti informatici 1

13/38

Il postcompletamento gioca un ruolo essenziale nellarricchimento culturale sia del fornitore sia del committente. Questa fase comporta la valutazione critica dei parametri del progetto (ritardi, costi aggiuntivi ed errori di previsione in genere), il confronto fra la valutazione dei rischi e ci che si effettivamente verificato e la valutazione dei parametri di successo; questi possono essere la soddisfazione del cliente (gli utenti e il committente) e del fornitore (margini e impatto sul mercato). Successivamente occorre realizzare le azioni che consentono lavvio della manutenzione del siste-ma prodotto. 1.3 Risorse costi vincoli e percorso critico Risorse Una volta determinato linsieme P, per un progetto, occorre determinare la durata di ogni attivit. Per fare ci essenziale il concetto di risorsa: in linea di principio, la durata della maggior parte delle attivit dipende dai mezzi (strumentali, finanziari, umani, ecc.) che possono essere impiegati per il loro svolgimento. Esistono essenzialmente due classi di risorse: quelle cosiddette a consumo e quelle dette individuali o stabili. Le risorse del primo tipo (come per esempio carburanti, carta, energia elettrica) sono caratterizzate dalla ennupla

(, , , , , ) quelle del secondo tipo (come per esempio le persone, le attrezzature, i siti) dalla ennupla

(, , , , , ). Il nome un identificativo univoco della risorsa (per esempio il nome di una persona o il numero di inventario di una apparecchiatura; il tipo la classe della risorsa come per esempio programmatore, capo progetto oppure router o server. In questo contesto vengono prese in considerazione solo risorse individuali (che sono le pi impor-tanti per i progetti software). necessario ed essenziale tener conto delle risorse quando si definisce lo schema e poi il piano di progetto (e si traccia il Gantt) sia per valutare la funzione d sia, successivamente, per valutare la funzione t. Ad ogni attivit associata (con metodi che saranno visti successivamente) una misura (che ne e-sprime in qualche modo la quantit) chiamata impegno dellattivit; lunit di misura dellimpegno come per esempio giorno sviluppatore, mese sistemista o an-no operatore. La durata di una singola attivit, cio la funzione d, dipende (almeno in prima approssimazione) dallimpegno associato a quella attivit e dalla quantit di risorse ad essa specificamente assegnate, cio

d(x) = impegno(x) / quantit di risorse(x), come per esempio

d = 15 giorni sviluppatore / 3 sviluppatori = 5 giorni. Calcolare la funzione d significa, in maniera implicita o esplicita, attribuire le risorse alle singole at-tivit (che nascono in modo naturale misurate in impegno). Inoltre, per semplicit, le risorse si ri-tengono fisse e disponibili per quella attivit; in caso contrario si spezza lattivit in parti in ciascu-na delle quali si pu assegnare una quantit costante di risorse.

La gestione dei progetti informatici 1

14/38

durata

costo

attivit

esterno

} impegno

+ risorse

Costi Ad ogni attivit sono associati dei costi che sono di due tipi: - i costi variabili generati dalle risorse attribuite alla attivit e dipendono dallimpegno associato

alla attivit; - i costi fissi che sono indipendenti dallimpegno. Per esempio, in una attivit (della fase di) di realizzazione, esistono spesso dei considerevoli costi fissi che riguardano lacquisizione di strumenti e la preparazione degli ambienti di sviluppo. Il costo (totale) C di un progetto si calcola semplicemente sommando il costo delle singole attivit: C = j (costo variabile(attivitj) + costo fisso(attivitj) ) = = j (impegno(attivitj) tariffa risorse(attivitj) + costo fisso(attivitj)). Occorre osservare che, mentre semplice e naturale calcolare il costo totale del progetto come somma dei costi delle singole attivit, non lo per la durata totale e per limpegno totale. La prima non affatto la somma delle durate delle attivit, ma si deduce dal Gantt (cio dalla funzione t) che tiene conto del parallelismo, dei vincoli, ecc. Per limpegno totale si noti che, in generale, ogni atti-vit ha una sua unit di misura, a seconda del tipo di risorse che richiede e quindi, a rigore, gli im-pegni parziali non si possono sommare per dare origine a un impegno totale associato al progetto, nozione che, appunto, non possibile definire. La figura 1.8 illustra il rapporto logico tra le entit viste: a una attivit associato un impegno; se ad essa si assegnano delle risorse se ne pu calcolare la durata e il costo Figura 1.8 Tipi di attivit Ricapitolando, tra limpegno I associato a un attivit, la sua durata d, e la quantit di risorse asse-gnate r esiste la relazione

I = d r. Finora sono state considerate solamente attivit a impegno fisso, cio quelle in cui dato I, vengono assegnate le risorse e viene calcolato d; questo il tipo pi comune nei progetti informatici. Esistono anche attivit a durata fissa e attivit a risorse fisse. Un esempio di attivit a durata fissa il calcolo del tasso di errori del funzionamento di un impianto complesso; questo si ottiene per esempio controllando limpianto per un periodo predeterminato (per esempio un settimana) con un numero opportuno di operatori. In questo caso il numero di ope-ratori da impegnare dipende dalla accuratezza con cui si vuole valutare il fenomeno: assegnato d, vengono allocate le persone e viene calcolato I.

La gestione dei progetti informatici 1

15/38

Un esempio di attivit a risorse fisse il test di stress di un sistema online che pu richiedere 5 ope-ratori (reali e non simulati) che adoperano a pieno ritmo il sistema. In questo caso lattivit nasce con r assegnato, si alloca d (per esempio 2 giorni) e si calcola I. In condizioni molto particolari, che possono tuttavia presentarsi negli esempi di progetti che saran-no presi in considerazione, si presentano altri due tipi di attivit: le attivit condizionate e le attivit non valutabili. Le prime sono quelle la cui necessit condizionata al verificarsi di eventi di cui si conosce solo la possibilit di accadere; le seconde sono quelle per cui non possibile determinare, neppure in modo approssimato, limpegno e quindi il valore della funzione d. Esempio tipico sono attivit relative al-la realizzazione di quei moduli software che, per la difficolt o la novit, sono praticamente impre-vedibili2. In questi casi sono possibili due atteggiamenti: - fare una valutazione provvisoria e trattare gli scostamenti durante il controllo, - usare attivit con parametri a valore in un intervallo e che determinano quindi durate totali e co-

sti totali collocati in intervalli. In pratica, il calcolo per intervalli relativamente poco utilizzato per i progetti trattati in questo con-testo e si preferisce usare un valore stimato. Vincoli Sono stati proposti come esercizio la scrittura di programmi per allocare le attivit nel tempo, cio per calcolare t, tenendo conto della relazione di precedenza fra le attivit e con durata totale minima (esercizio E4) o con una sola attivit alla volta (esercizio E5). In realt, nelle applicazioni esistono altre condizioni di cui tener conto: - la disponibilit delle risorse, - i vincoli sulle attivit. La prima condizione potrebbe imporre di spostare in avanti (rispetto alla soluzione standard delle-sercizio E4) linizio di una attivit fino a quando non sono disponibili tutte le risorse necessarie per effettuarla. Per descrivere la seconda condizione si associano ad alcune attivit dei vincoli, che possono essere di tre tipi: flessibili, deboli e forti. Vincoli flessibili: si riferiscono alla direzione del tempo;

- il pi presto possibile: ASAP (as soon as possible), - il pi tardi possibile: ALAP (as late as possible); Vincoli deboli: si riferiscono a intervalli aperti;

- iniziare non prima di t0, - iniziare non oltre t0, - finire non prima di t1, - finire non oltre t1;

Vincoli forti: si riferiscono a punti o intervalli chiusi; - iniziare a t0 (o tra t1 e t2), - finire a t1 (o tra t3 e t4). Naturalmente, in prima assegnazione, possono verificarsi incompatibilit tra vincoli o tra questi e le disponibilit delle risorse. In generale, queste incompatibilit non possono essere trattate da un pro-gramma, ma devono essere discusse e risolte con compromessi dai responsabili del progetto.

2 Naturalmente limprevedibilit solo locale, cio si riferisce al risultato di una singola attivit e non ha influenza ri-levante sul progetto nel suo insieme.

La gestione dei progetti informatici 1

16/38

Esercizi E7. Costruire un programma che partendo dalla soluzione standard (dellesercizio E4) prende in considerazione i vincoli su (alcune del)le attivit e termina o con la segnalazione vincoli incompa-tibili o con una nuova funzione t che rispetta i vincoli. Esplicitare la struttura dei dati che descrive i vincoli associati agli elementi dellinsieme P. Macroattivit (o attivit di riepilogo) Un Gantt reale pu essere composto anche da parecchie centinaia di attivit; per dominare questa complessit e rendere il diagramma maneggiabile e comprensibile si adotta il metodo di riassume-re alcune attivit in macroattivit. Dato uno schema di progetto (P, , d), un insieme di attivit A = {a1, a2, an} pu essere riassun-to in una macroattivit se per ogni b P: - se j tale che b aj allora anche b ai, per ogni i, - se j tale che aj b allora anche ai b, per ogni i. In questo caso si introduce una macroattivit a {a1, a2, an} detta anche attivit di riepilogo. Si confronti questa definizione con quelle di sottoschema e fase.

Figura 1.9 Un esempio riportato in figura 1.9, in cui la freccia A non ammessa perch le quattro attivit a1, a2, a3, a4 possano costituire una macroattivit; in figura 1.10a 1.10b sono riportati due differenti piani di progetto relativi a queste attivit.

a1

a2

a3

a4

A

La gestione dei progetti informatici 1

17/38

durata della macroattivit riepilogo a a1 a2 a3 a4 3 4 5 6 7 8 9 10 11

Figura 1.10a durata della macroattivit riepilogo a a1 a2 a3 a4 3 4 5 6 7 8 9 10 11

Figura 1.10b Particolare attenzione deve essere posta per valutare la funzione d di una macroattivit; nel caso particolare che le aj formino una catena, una scelta possibile (ma non necessaria)

d(a) = j d(aj) Esercizi E8. Determinare tutte le informazioni necessarie per il calcolo della durata di una macroattivit. E9. Date tutte le informazioni necessarie per calcolare la durata di una macro attivit, scrivere un programma per eseguire il calcolo. Luso delle macroattivit (insieme alle fasi) offre un metodo fondamentale per derivare top down il WBS completo di un progetto complesso. Questa possibilit conseguenza del fatto che possono essere costruite gerarchie di macro attivit in analogia alla scomposizione di problemi complessi in sottoproblemi via via pi semplici.

La gestione dei progetti informatici 1

18/38

Percorso critico Riprendendo quanto finora detto, per ottenere il Gantt di un progetto bene partire costruendo lin-sieme delle fasi del progetto che si intende attuare. Ciascuna fase del progetto pu essere esplosa in attivit descritte da un WBS; ogni attivit pu (anche, a sua volta) essere trattata come una macroattivit che deve essere opportunamente scompo-sta per la fattispecie in esame. Il processo di scomposizione successiva va avanti (almeno) fino a quando possibile, per ogni atti-vit, determinare (con buona approssimazione) limpegno corrispondente, il tipo di risorse necessa-rie e gli eventuali vincoli. Parallelamente occorre descrivere le risorse a disposizione e la loro effettiva disponibilit. Da ulti-mo occorre calcolare la durata e il costo di tutte le attivit e la loro allocazione nel tempo (la fun-zione t). In questo modo rimangono determinati il costo e la durata totale del progetto che vengono indicati con Cb e Tb per sottolineare che si in fase previsionale (lindice b sta per budget). Se in un Gantt si sposta la fine di una attivit a dal tempo tf(a) = t(a) + d(a) al tempo tf(a) + a, per-ch per esempio cambiato d(a) diventato d(a) + a, pu succedere che occorre o no cambiare (globalmente) la funzione t (che deve tener conto dellordine tra le attivit). Si danno essenzialmen-te tre casi: - non occorre cambiare t; si chiama fa, flessibilit libera associata in quel Gantt allattivit a,

il massimo cambiamento che permette di non cambiare t; - se a > fa occorre ricalcolare la t, cio determinare una funzione t che coincide con t sulle at-

tivit che precedono lattivit a; - si chiama ma, flessibilit massima associata in quel Gantt allattivit a, il massimo a per

cui si ha t() =t(). Una attivit a in un Gantt si dice attivit critica quando ma = 0; quindi, per una attivit critica un a > 0 sposterebbe una qualche altra attivit che a sua volta ne sposta unaltra e cos via fino a spostare , cio a cambiare t(). Esiste quindi un percorso critico cio una catena

= a0, a1, , an = con t(aj) = t(aj-1) + d(a j-1), con j=1, , n., per cui cio maj= 0. Esercizi E9. Dato uno schema di progetto, determinare la struttura dati che rende facile il disegno effettivo del Gantt. E10. Dato uno schema di progetto e la struttura dati determinata con lesercizio precedente, trovare tutti i percorsi critici. 1.4 Verifica e controllo Lattivit finora descritta di pianificazione del progetto che porta al documento di previsione e rende conto dei tempi e dei costi previsti. Tale documento contiene (almeno) i seguenti dati:

a) linsieme delle attivit e degli eventi con la loro relazione dordine (WBS), b) la valutazione dellimpegno, dei vincoli e del tipo di risorse per ogni attivit, c) le risorse utilizzabili per il progetto, le tariffe e la disponibilit nel tempo, d) lassegnazione delle risorse alle attivit e la determinazione della durata e del costo,

La gestione dei progetti informatici 1

19/38

e) allocazione delle attivit nel tempo nel rispetto della disponibilit delle risorse e dei vincoli (piano di progetto o Gantt),

f) la durata e il costo totali e i cammini critici. Preparato il piano, inizia il vero e proprio project management che consiste essenzialmente nelle seguenti azioni (spesso da condurre in parallelo): - verifica dellavanzamento, - controllo, - valutazione dei rischi ed expediting. 1.4.1 Verifica dellavanzamento Si cominci con losservare che in fase di pianificazione, in generale, non si pu porre t() = 0 e spo-stare lorigine a un t0 data effettiva di inizio del progetto, a causa della presenza (possibile) di vin-coli forti, che di solito sono date assolute e non relative allinizio del progetto. La verifica del progetto (da confrontare con il tracking visto precedentemente) consiste nel

- determinare le funzioni d e t che associano i valori sperimentali alle attivit gi iniziate al-la data della verifica (t e d sono funzioni parziali),

- riallocare le risorse se necessario, - ricalcolare t e d da quella data in poi.

Si pongono almeno due problemi: il primo legato alla determinazione della funzione d sperimen-tale relativa alle attivit iniziate ma non ancora terminate nel momento della verifica; il secondo legato alla frequenza con cui si devono effettuare le verifiche. Per il primo problema occorre sostanzialmente prevedere la durata delle attivit iniziate ma non an-cora terminate; questo in generale un processo soggetto ad errore e comporta il suggerimento pressante di utilizzare un WBS con attivit brevi (spezzando quelle che hanno una durata ecces-siva3). La risposta al secondo problema si riduce alla regola empirica di fare le verifiche a interval-li di durata pari al 5% della durata totale del progetto; per i progetti pi piccoli o pi grandi di quelli oggetto di questa trattazione, questa indicazione pu non essere applicabile. Detta Vj la j-esima verifica, indichiamo con dj e tj le funzioni durata e i tempo di inizio conseguenti alla verifica. Per le attivit gi terminate, dj e tj sono i valori constatati sperimentalmente; per le at-tivit in corso, devono essere stimate le dj, mentre le tj sono quelle effettive; per le attivit rimanen-ti, si devono ricalcolare le tj, mentre le dj vanno ricalcolate solo se variata lallocazione delle ri-sorse. Si ricorda che alla verifica Vj per lattivit a, se tj(a) tj-1(a), allora viene calcolato lo spo-stamento

a = tj(a) - tj-1(a) + dj(a) - dj-1(a) e, indicati con f a e ma le flessibilit libera e massima della attivit a nel Gantt successivo alla ve-rifica Vj-1, si hanno i seguenti casi: - a < f a : lo spostamento non influisce sulle attivit successive; - f a < a < m a : lo spostamento influisce su alcune attivit successive, ma viene riassorbito,

cio non influisce su ; - m a < a : lo spostamento influisce su , cio tj() > tj-1(). Ad ogni verifica Vj si ricalcola anche la funzione costo determinando Cj; il costo di una attivit pu variare per due motivi: - perch lattivit ha avuto una durata diversa da quella preventivata precedentemente, a parit di

risorse assegnate; 3 Naturalmente la compilazione del documento di previsione di un progetto un processo iterativo: compiuto un passo, ad esempio il calcolo di d, spesso occorre tornare indietro per modificare decisioni o parametri gi fissati.

La gestione dei progetti informatici 1

20/38

- perch alla verifica variata lassegnazione delle risorse. Durante la realizzazione di un progetto, normalmente in occasione delle verifiche, pu anche acca-dere che occorra rivedere i WBS, cio inserire, cancellare e scomporre attivit e questo comporta una variazione (anche sostanziale) del piano del progetto. Inoltre pu succedere che i costi e i tempi totali variano (in genere in aumento) perch le attivit previste prendono pi tempo e/o costano di pi e qualche volta devono essere inserite nuove attivit anche di elevata consistenza. Riassumendo: la verifica registra ci che accaduto e, in generale, ricalcola un nuovo piano, ma non genera una previsione ragionata; quindi non si usa ci che realmente accaduto per migliora-re la conoscenza del futuro. Dopo ogni verifica consuetudine creare i seguenti documenti: - il Gantt riaggiornato (che pu essere ridisegnato sovrapposto al precedente); - lelenco delle attivit iniziate o terminate in ritardo; - lelenco delle attivit che hanno assorbito un quantit di risorse superiore al previsto (o perch

era stata sbagliata la stima dellimpegno o perch si sono verificati eventi imprevisti); - la lista delle attivit pianificate che non sono state svolte; - lelenco dei costi reali delle attivit completate. 1.4.2 Controllo Il controllo viene effettuato periodicamente e di norma dopo una verifica; consiste nel prevedere come sar landamento finale del progetto se non vengono presi provvedimenti e suggerisce anche cosa deve essere fatto per modificare questa previsione. La verifica consente di prendere atto degli scostamenti constatati e di calcolarne la ovvia conseguenza sulla parte di progetto ancora da rea-lizzare, mentre il controllo, tenuto conto di quanto avvenuto fino a quel momento, consente di effet-tuare previsioni sui reali scostamenti futuri. Per quanti sforzi si facciano durante la pianificazione del progetto, difficilmente sar possibile ri-spettare completamente tutti gli impegni e le scadenze previsti. Una tecnica ampiamente usata quella di pianificare tempi e costi con un margine di sicurezza in modo da costruirsi una riserva da usare opportunamente per fare fronte agli imprevisti e non rendere necessaria (se non in casi e-stremi) la ripianificazione del progetto. Metodo del controllo con la riserva Il committente (chi paga ed interessato al progetto) fissa (in generale mediante un contratto) due parametri: - Td che il termine entro cui richiede che il progetto sia terminato; - Cd che il costo totale che non disposto a superare. Il metodo del controllo con la riserva consiste nel pianificare il progetto in modo che i seguenti pa-rametri: - Tb che lintervallo di tempo entro cui si prevede di terminare il progetto Tb = t() t(), - Cb che il costo totale previsto per il progetto, siano minori dei corrispondenti fissati dal committente. Si chiamano indici di riserva i rapporti (maggiori di 1)

Cr = Cd/Cb e Sr = Td/Tb La riserva illustrata nella figura 1.11. Con riferimento alla figura 1.12, supponiamo di fare il con-trollo di un progetto in un certo momento, che in figura indicato con T; le previsioni riguardo al costo possono non essersi avverate per due motivi: o si svolta una quantit di lavoro diversa (pro-babilmente minore) di quella preventivata oppure il costo del lavoro fatto risultato diverso (proba-bilmente superiore) a quello preventivato.

La gestione dei progetti informatici 1

21/38

Cd riserva di costi Cb riserva di tempi Tb Td

Figura 1.11 Si calcolano i seguenti parametri - Cbb che il costo a piano per il lavoro a piano alla data in cui si effettua il controllo; - Cbf che il costo a piano per il lavoro effettivamente fatto al momento del controllo (prevedi-

bilmente si fatto un lavoro minore del previsto e quindi la spesa pianificata per tale lavoro bassa) ;

- Cff che il costo reale del lavoro fatto fino al momento del controllo (prevedibilmente si fatto meno lavoro del previsto che, comunque, costato pi di quanto messo a piano).

Con questi parametri (vedi figura 1.12) si costruiscono i due indici che stimano approssimativamen-te landamento dei costi e dei tempi: Cd extracosto Cb P Cbb Cff slittamento Cbf O T Tb Td

Figura 1.12 - CI = Cbf/Cff misura approssimativamente landamento dei costi,

La gestione dei progetti informatici 1

22/38

- SI = Cbf/Cbb misura approssimativamente landamento dei tempi. Quando lo stato davanzamento del progetto in accordo con il piano gli indici sono maggiori o uguali a 1; unosservazione empirica, ma fortemente cogente, che CI e SI sono poco significativi nei primi (due o tre) controlli e variano fortemente da controllo a controllo. Successivamente, quan-do passato un intervallo di tempo compreso fra il 15 e il 20% del tempo preventivato per lintero progetto, oppure quando si speso una quantit di denaro compresa fra il 15 e il 20% del costo complessivo, i due rapporti tendono a stabilizzarsi o variano lentamente, a meno che non vengano prese decisioni per apportare qualche modifica sostanziale alla conduzione del progetto. Quando i valori sono stabilizzati danno una indicazione attendibile su come sta andando il progetto: un valore maggiore di 1 indica che il progetto sar completato senza intaccare la riserva, mentre un valore minore di 1 indica che la riserva pu non bastare per portare a termine il progetto. La figura 1.12 stata ottenuta dalla precedente 1.11 nella seguente maniera; si disegnata la linea verticale al tempo T; su tale linea si sono riportati i tre valori Cbb, Cff, Cbf che, presumibilmente so-no nelle reciproche posizioni mostrate in figura. Le tre rette che passano per lorigine O e per cia-scuno dei tre punti tracciati hanno come pendenza le velocit di spesa rispettivamente prevista, effettiva e virtuale. Si poi costruito il punto P intersezione tra la retta (O, Cbf) e la orizzontale per Cb; la ascissa di questa intersezione d una previsione ragionevole del tempo di fine del progetto: si noti come si prevede tale tempo considerando la velocit di spesa virtuale al tempo T e utilizzando tale velocit per esaurire il budget, cio per raggiungere il costo previsto. La intersezione tra la retta (O, Cff) e la verticale per il punto P ha come ordinata una previsione ragionevole per la spesa totale del progetto: questo equivale a supporre la velocit di spesa futura eguale a quella effettiva per tutta la durata prevista del progetto. Le linee guida per suggerire le decisioni pi appropriate da prendere durante le fasi di controllo (af-finch il progetto rispetti i vincoli imposti dal committente) fanno uso del cos detto metodo dei se-mafori. Questo consiste nel considerare due segnali (semafori), uno per i costi e uno per i tempi, che possono assumere i valori verde, giallo e rosso. Il valore verde del semaforo indica che la pianifica-zione viene rispettata, il valore giallo indica che si sta intaccando la riserva e il valore rosso segnala che, se non si interviene, non verranno rispettati i vincoli imposti dal committente.

Semaforo dei costi

condizioni

verde CI-1 1 Cr giallo 1 CI-1 Cr rosso 1 Cr CI-1

Semaforo dei tempi

condizioni

verde SI-1 1 Sr giallo 1 SI-1 Sr rosso 1 Sr SI-1

Costo Tempo Azioni raccomandate verde verde tempi e costi sono in linea, o migliori, delle previsioni; probabilmente il progetto

terminer con una riserva non utilizzata di tempi e costi. verde giallo si sta intaccando la riserva dei tempi; bene introdurre o aumentare il lavoro stra-

La gestione dei progetti informatici 1

23/38

ordinario. verde rosso la riserva di tempo non sufficiente per terminare il Progetto; occorre aumentare

ancora lo straordinario o il personale. giallo verde si sta intaccando la riserva dei costi; si deve diminuire lo straordinario. giallo giallo si sta intaccando sia la riserva dei costi sia quella dei tempi; si deve riaggiustare

lassegnazione del personale sulle varie attivit. giallo rosso migliorare lassegnazione del personale e prendere in considerazione lidea di

rinegoziare Td. rosso verde diminuire il lavoro straordinario e/o le persone assegnate al progetto. rosso giallo migliorare lassegnazione delle persone e prendere in considerazione lidea di

rinegoziare Cd. rosso rosso rinegoziare Td e Cd; riconsiderare gli obiettivi del progetto; cambiare il capo pro-

getto. 1.4.3 Valutazione dei rischi ed Expediting La valutazione dei rischi e lo expediting sono azioni volte a minimizzare lo scostamento fra ci che accade e ci che era stato pianificato. La prima cerca di risolvere i problemi, qualora questi si siano presentati; la seconda serve e viene attivata per evitare che i problemi si presentino. Queste azioni hanno a che fare con il problema pi generale di trattare i rischi insiti in progetti impegnativi. In generale si possono classificare tre tipi di rischi.

a. difficolt di prevedere e stimare, b. ipotesi e assunzioni, fatte durante la pianificazione, che possono non verificarsi, c. eventi imprevisti.

Le aree di rischio (cio le aree dove prevedibile che nascano problemi che impediscono il rispetto della pianificazione) per i progetti informatici sono essenzialmente le seguenti. 1. Applicazione; relativa ai problemi che nascono dalle difficolt insite nel tipo di applicazione

informatica che si deve realizzare: costruire un software per il controllo di processo di un im-pianto completamente nuovo non ancora in esercizio pone dei rischi decisamente maggiori che realizzare un sistema di contabilit con regole definite da una normativa ben nota.

2. Personale; relativa ai problemi delle persone coinvolte nel progetto connessi con lesperienza, le competenze, gli aspetti caratteriali, il turnover, la disomogeneit culturale, ecc.

3. Progetto; relativa ai problemi (molto pi frequenti di quanto ci si pu aspettare) dovuti alla non chiarezza riguardo agli obiettivi e a vincoli non enunciati sui tempi di realizzazione e sui costi (in relazione allintero progetto o a fasi significative).

4. Metodologie; comprende i rischi connessi alla non completa comprensione e condivisione (da parte delle persone coinvolte) delle varie metodologie impiegate nel progetto (di sviluppo, di test, di management, ecc); particolarmente elevato in caso di nuove tecnologie.

5. Hw e Sw di base; si riferisce ai rischi connessi con la presenza di errori nel software usato, alla disomogeneit degli ambienti (tra sviluppo, test e gestione), alla mancanza di specifiche formali, ecc.

6. Changeover; riguarda le difficolt (che sono estremamente rilevanti per la classe di progetti trattati) connesse con la messa in opera del sistema informatico realizzato (tipicamente un si-stema informativo aziendale) che induce cambiamenti organizzativi, procedurali o di compor-tamento.

7. Forniture; si riferisce ai ritardi o alle non conformit dei prodotti che devono essere acquisiti durante il progetto.

La gestione dei progetti informatici 1

24/38

8. Fattori esterni; questarea comprende le cose pi varie: la disponibilit dei locali nei quali vie-ne effettuato lo sviluppo, il cambiamento di legislazione o di normative che influenzano le ma-terie coinvolte nel progetto, landamento dei mercati che influiscono sui costi, ecc.

9. Sicurezza e salute; tiene conto di malattie e incidenti: per esempio se il progetto occupa i mesi da novembre ad aprile di cinque persone quasi certa la perdita di uno/due mesi uomo per malattie da raffreddamento.

Per ogni piano, occorre produrre una lista di rischi dei tipi a) e b) (cio dovuti alla difficolt di pre-vedere e a ipotesi non sicure), per ciascuna delle nove aree, con le relative valutazioni. La valutazione del rischio si fa usualmente con una formula euristica del tipo

valutazione = probabilit impatto. In questo contesto per le probabilit e per limpatto consuetudine usare una valutazione sogget-tiva su una scala da 1 a 10. La tabella che segue un esempio di lista dei rischi.

rischio prob. imp. val. 1 cambio delle specifiche durante la codifica 1 9 9 2 lanalisi richiede pi tempo del previsto 3 6 18 3 malattie del personale lungo il percorso critico 4 10 40 4 malattie del personale su attivit non critiche 10 3 30 5 la codifica richiede pi tempo del previsto 4 4 16 6 la fase di test evidenzia errori di analisi 3 9 27 7 la fase di test evidenzia errori di architettura 2 10 20

Nei casi reali la lista dei rischi comprende spesso centinaia di righe. Nellesempio visto, i rischi 3, 4 e 6 sono particolarmente gravi; occorre mettere in campo azioni specifiche per affrontarli. In generale ci sono tre maniere per affrontare i rischi:

- ridurre la probabilit o limpatto; - approntare un contingency plan; - trasferire il rischio.

Per esempio, per il rischio 3 si pu aumentare il personale assegnato alle attivit del percorso critico (compatibilmente con i vincoli economici) per diminuirne la probabilit o si pu pianificare la pos-sibilit di trasferimento momentaneo di personale da altra attivit, dello stesso progetto o di altri progetti (contingency plan), o fare un contratto-assicurazione con una ditta di servizi che offra per-sonale con le caratteristiche richieste con piccolo preavviso (trasferimento del rischio). Per il rischio 6 si pu rafforzare lattivit di analisi o prevedere in vari momenti prima del test forme di controllo che evidenzino il pi tempestivamente possibile difetti o non conformit. Lo expediting quellinsieme di attivit di carattere logistico e organizzativo che servono ad accor-gersi che le attivit del piano possono svolgersi nella maniera prevista e a prendere tutti i provvedi-menti (di carattere economico ed organizzativo) che possono contribuire al rispetto delle previsioni. 1.5 CPM e Pert Dato uno schema di progetto, per esempio P = {, a, b, c, d, e, f, g, h, }, con la relazione dordine che la chiusura riflessiva e transitiva della seguente {(, a), (, b), (, f), (a, c), (b, d), (b, e), (e, g), (f, g), (c, h), (d, h), (h,), (g,)}; le durate delle attivit sono mostrate dalla seguente tabella

Attivit Durata

La gestione dei progetti informatici 1

25/38

a 6 b 4 c 3 d 4 e 3 f 10 g 3 h 2

Il grafo delle precedenze mostrato nella figura 1.13; a c h b d e g f

Figura 1.13 Il piano di progetto (quindi la funzione t) standard (cio senza vincoli sulle attivit e che permette di svolgere il progetto nel tempo minore) mostrato dal Gantt di figura 1.14.

La gestione dei progetti informatici 1

26/38

a b c d e f g h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Figura 1.14 Come si (ampiamente) visto, il grafo orientato delle precedenze mostra, mediante frecce, la rela-zione dordine tra le attivit, rappresentate da punti; mentre il Gantt standard mostra la medesima relazione collocando opportunamente nel tempo le attivit stesse, rappresentate da segmenti la cui lunghezza proporzionale alla rispettiva durata. (Si noti che un Gantt qualunque, in generale, non permette di recuperare la relazione di precedenza.) 1.5.1 CPM (Critical Path Method) Il grafo (orientato) CPM una tecnica per rappresentare le stesse informazioni volta ad individuare rapidamente il o i percorsi critici. In tale grafo, i nodi rappresentano eventi; sono sempre presenti , , cio linizio e la fine del progetto; gli archi rappresentano le attivit. Questo grafo pu essere ot-tenuto dal grafo delle precedenze utilizzando il seguente algoritmo, di cui vengono elencati i passi.

1. Si disegna il grafo delle precedenze. 2. Si indeboliscono le frecce (facendole diventare tratteggiate). 3. Si sdoppiano tutti i nodi (le attivit) mediante due nodi eventi uniti tra loro da una frecce

forte che ha come etichetta quella del nodo originale (con due attributi: il nome e la dura-ta).

4. Si cancellano (ove possibile) le frecce deboli, fondendo i loro nodi estremi usando le se-guenti due regole: - un nodo che ha un solo predecessore debole, cio unito da una freccia debole, si fonde

con esso, - un nodo che ha due o pi predecessori deboli, ciascuno dei quali non abbia altri succes-

sori, si fonde con tutti questi. 5. Le frecce deboli rimaste vengono trasformate in frecce forti dette attivit dummy (ciascuna

con un proprio nome e durata uguale a zero). 6. I nodi sono etichettati con (una struttura dati che ha) 4 attributi.

La gestione dei progetti informatici 1

27/38

Gli stadi intermedi, dopo il passo 2 e dopo il passo 4, e quello finale della trasformazione del grafo delle precedenze di figura 1.13 sono riportati in figura 1.15 (a e b) e in figura 1.16, rispet-tivamente.

a c h b d a e g f c a b d b h e f g

Figura 1.15 a; 6 c; 3 b; 4 d; 4 h; 1 f; 10 e; 3 g; 3

Figura 1.16 Esercizi E11. Definire la struttura dati appropriata per rappresentare il grafo delle precedenze e scrivere un programma che lo disegna.

4 2 9 12

3 0 10 10

2 3 4 7

1 2 6 8

0 13 13

0 0 0

La gestione dei progetti informatici 1

28/38

E12. Definire la struttura dati appropriata per rappresentare il grafo CPM e scrivere un programma che lo disegna. E13. Implementare lalgoritmo che trasforma il grafo delle precedenze nel relativo grafo CPM. Ricapitolando, in un grafo CPM i nodi rappresentano gli eventi e le frecce rappresentano le attivit. La struttura dati per descrivere i nodi ha quattro etichette, come mostrato in figura 1.17: il nome, Tm (tempo minimo entro cui pu accadere levento senza dover cambiare t()), TM (tempo massimo entro cui pu accadere levento senza dover cambiare t()) e S (intervallo di tolleranza, o slack); gli archi hanno come etichetta il nome e la durata dellattivit (che data). Per riempire i tre campi (di-versi dal nome) delletichetta dei nodi si usano i seguenti tre algoritmi.

Figura 1.17 Passo forward, per calcolare il tempo minimo Tm. Si esplora il grafo in avanti, partendo dal nodo iniziale ; in Tm() si mette il valore t0, cio il tem-po di inizio del progetto; per ogni altro nodo x che ha tutti i suoi k predecessori immediati yj (j = 1, 2, ... k) con Tm(yj) valutata, si pone Tm(x) = max {Tm(yj) + durata(yj, x), j = 1, 2, ... k }, dove j nu-mera le frecce in entrata per il nodo x. Passo backward per calcolare il tempo massimo TM. Si esplora il grafo allindietro, partendo dal nodo finale ; in TM() si copia il valore Tm(), cio il tempo di fine del progetto; per ogni altro nodo x che ha tutti i suoi k successori immediati yj (j = 1, 2, ... k) con TM(yj) valutata, si pone TM(x) = min {TM(yj) - durata(x, yj) , j = 1, 2, ... k }, dove j nu-mera le frecce in uscita per il nodo x. Passo slack per calcolare lintervallo di tolleranza. Per ogni nodo x si pone S(x) = TM(x) - Tm(x). Le catene di nodi per cui S(x) risulta nullo sono i per-corsi critici, cio quelli che contengono gli eventi che non possono subire ritardi, pena laumento della durata del progetto. Esercizi E14. Implementare lalgoritmo forward. E15. Implementare lalgoritmo backward. E16. Dimostrare che S(x) sempre non negativa. E 17. Usare gli slack per ridurre i costi

nome S Tm TM

La gestione dei progetti informatici 1

29/38

E 18. Sia dato un grafo CPM con i seguenti 8 nodi: , B, C, D, E, F, G, . Le frecce (cio le attivi-t) e la loro durata (per esempio in settimane) sono date dalla seguente tabella

Nodo di inizio Nodo di fine Durata dellattivit B 4 D 3 B D 5 B E 8 B C 5 C E 6 C G 4 D E 7 D F 9 E F 10 E G 7 E 3 F 3 G 5

Disegnare il grafo e trovare il cammino critico e lo slack (totale) di ogni attivit. 1.5.2 Pert Il metodo CPM, come si visto serve a determinare facilmente il percorso critico di un progetto e a individuare lintervallo di tolleranza (o slack) in cui i vari eventi possono accadere senza ritardare la fine del progetto. Lassunzione di fondo che la durata delle attivit sia determinabile con precisio-ne; questa assunzione abbastanza ben verificata quando le attivit sono semplici e ben indivi-duabili e quindi lincertezza sulla loro durata trascurabile: il metodo CPM utilizza le durate delle singole attivit (e la relazione di precedenza tra di esse) per calcolare in maniera deterministica la durata del progetto. Quando le attivit sono qualche migliaio oppure non se ne pu determinare con sufficiente certezza la durata, questo schema per calcolare la durata del progetto non pi applicabile e si devono usare metodi probabilistici. Il metodo Pert (Program evaluation and review technique) fu introdotto nel 1957 per la gestione del progetto Polaris (la costruzione di un missile che potesse essere lanciato da un sommergibile in im-mersione) che era composto da migliaia di attivit, molte delle quali erano programmi di ricerca e quindi di durata non esattamente prevedibile. Questo metodo si usa principalmente in caso di grandi progetti con attivit non omogenee (per e-sempio non solamente di sviluppo software), alcune delle quali ad alto rischio (come per esempio lo sviluppo di hardware custom, cio progettato e realizzato ad hoc, oppure la individuazione di un nuovo combustibile solido, come nel caso del Polaris), quindi applicabile alla fascia alta dei progetti qui considerati. Il Pert fa riferimento a un grafo in cui, come in quelli del CPM, i nodi rap-presentano degli eventi (o stati parziali) e le frecce le attivit. Riguardo alle attivit, si fanno le seguenti (molto ragionevoli) ipotesi:

- le durate delle attivit sono statisticamente indipendenti; - la durata di una attivit segue una distribuzione beta; - la durata complessiva del progetto segue la distribuzione normale.

Il cammino critico in questo caso ha il significato del cammino per il quale il valore atteso della du-rata (totale del progetto) massima. Per ogni attivit vengono stimate tre durate (che in casi particolari possono coincidere):

La gestione dei progetti informatici 1

30/38

dp, che la durata pessimistica, dm, durata stimata pi probabile, do, la durata pi ottimistica.

Si suppone inoltre che la differenza fra dp e do sia equivalente a 6 deviazioni standard. Quanto detto, viene illustrato con un esempio che riprende (e generalizza) lesempio precedente ed composto dalle medesime 8 attivit con la stessa relazione di precedenza; esso descritto dalla seguente tabella (nella quale la colonna dm riporta i medesimi valori della colonna durata del caso CPM).

Attivit do dm dp de a 5 6 8 6.17 .50 b 3 4 5 4 .33 c 2 3 3 2.83 .17 d 3.5 4 5 4.08 .25 e 1 3 4 2.83 .50 f 8 10 15 10.5 1.17 g 2 3 4 3 .33 h 2 2 2.5 2.08 .08

Assegnati i valori delle prime tre colonne, si calcolano per ciascuna attivit il valore aspettato de e la deviazione standard con le seguenti formule

de = (dp + 4dm + do )/6

= (dp - do)/6 Nei grafi tipo Pert, le frecce hanno una etichetta con tre attributi che sono: il nome, la durata attesa de e la deviazione standard (che sono dati). I nodi hanno una etichetta con cinque attributi: il no-me, il tempo atteso per il verificarsi dellevento Te, la deviazione standard , il target T e la proba-bilit di rispettarlo. Il target rappresenta il tempo massimo entro cui levento deve accadere per ri-spettare i vincoli posti (dal committente, dalla disponibilit delle risorse, ecc.); naturalmente questo attributo pu essere indicato solo per alcuni nodi e non per altri. Per semplicit spesso i nodi sono disegnati solo con i primi quattro attributi, come mostrato in figu-ra 1.18

Figura 1.18 Dai dati riportati nella precedente tabella (e dalla relazione di ordine fra le attivit) si deriva il grafo mostrato in Figura 1.19.

nome T Te

La gestione dei progetti informatici 1

31/38

Nel disegnare il grafo Pert, vengono immediatamente riempite le etichette di ogni freccia (nome, durata attesa e deviazione standard) perch sono dati iniziali assegnati. Per i nodi dato il nome e, per alcuni di essi, il target; gli altri attributi (tempo atteso, deviazione standard e la probabilit) de-vono essere calcolati. Esiste tuttavia una differenza fondamentale fra gli algoritmi per calcolare questi attributi rispetto a quelli usati nel caso CPM; in questultimo caso si calcolano nodo per nodo gli intervalli di tempo entro i quali levento deve accadere (descritti dagli estremi e dallampiezza dellintervallo). Nel caso Pert invece si propaga con metodi probabilistici il valore del tempo atte-so per levento insieme con la sua deviazione standard. a; 6.17; .5 c; 2.83; .17 b; 4; .33 d; 4.08; .25 h; 2.08; .08 f; 10.5; 1.17 e; 2.83; .50 g; 3; .33

Figura 1.19 Algoritmo (forward), per calcolare il tempo atteso. Occorre esplorare il grafo (in avanti) partendo dal nodo iniziale ; in Te() si mette il valore t0, cio il tempo di partenza del progetto; per ogni altro nodo x che ha tutti i suoi k predecessori immediati yj (j = 1, 2, , k) con Te(yj) valutata, si pone Te(x) = maxj(Te(yj) + durata attesa(yj, x)), dove (yj, x) la frecce tra il nodo yj e il nodo x. Algoritmo (forward), per calcolare la deviazione standard. Per calcolare, come illustrato in Appendice B, la deviazione standard della somma c di due variabili aleatorie a e b si utilizza la regola pitagorica

(c) = sqrt((a)2 + (b)2).

15 13.5 1.22

1 6.17 .50

3 10 10.5 1.17

4 10 9 .53

2 4 .33

0 0

La gestione dei progetti informatici 1

32/38

Quindi, per calcolare la deviazione standard di un evento (nodo del grafo) che ha un solo predeces-sore occorre comporre con la regola pitagorica sopra vista la deviazione standard del nodo prece-dente con quella della freccia che li unisce; nel caso di pi predecessori si sceglie il massimo fra questi valori. Quindi, per calcolare la deviazione standard di ogni nodo, occorre esplorare il grafo (in avanti) partendo dal nodo iniziale ; in () si mette il valore 0, cio la data di partenza del pro-getto si considera certa; per ogni altro nodo x che ha tutti i suoi k predecessori immediati yj (j = 1, 2, , k) con (yj) valutata, si pone (x) = maxj(sqrt((yj) 2 + (yj, x) 2)), dove j numera le frecce in entrata per il nodo x. Algoritmo per calcolare la probabilit dei nodi con target. Nei grafi tipo CPM il percorso critico serve per individuare le attivit da tenere sotto controllo per la loro importanza al fine di assicurare la terminazione del progetto nei tempi prefissati. Nei grafi di tipo Pert non esiste pi il concetto di percorso critico, nel senso che tutte le valutazioni sono proba-bilistiche e quindi lo anche il valore atteso per il completamento dellintero progetto (evento ); lesigenza di individuare le attivit critiche, cio da tenere sotto controllo perch determinanti per il rispetto del tempo finale, viene risolta, per ogni evento per cui dato il target, calcolando la pro-babilit di non rispettarlo. Per ogni nodo x cui stato assegnato un target, si calcola il valore z(x) = (T(x) - Te(x))/ (x), cio il numero di deviazioni standard che separano il target dal valore atteso. Come illustrato nellAppen-dice A, ad ogni valore di z (da - a +) corrisponde un valore di probabilit che in pratica si ottiene per interpolazione (o approssimazione numerica). Nellesempio che si sta considerando, sono dati tre target: target() = 15, vincolo posto dal committente per lintero progetto; target(4) = 10, vincolo imposto dalla disponibilit delle risorse per lattivit c; target(3) = 10, vincolo posto dal committente come milestone intermedio. Per i tre nodi si ottiene: z() = 1.89, cui corrisponde una probabilit di non rispettare il target di circa il 3%; z(4) = 1.23, cui corrisponde una probabilit di non rispettare il target di circa il 11%; z(3) = -0.43, cui corrisponde una probabilit di non rispettare il target di circa il 65%. Esercizi E18. Sia dato un grafo Pert come mostrato in figura 1.20.

La gestione dei progetti informatici 1

33/38

l 5 10 q e f m r 2 6 11 15 b s v a c g n z 1 3 7 12 17 d x h o t 4 8 13 16 i u p 9 14

Figura 1.20 Le durate delle attivit, assegnate in giorni, sono riportate dalla seguente tabella (quando indicata una sola durata vuol dire che lattivit ha una durata fissa ed esattamente prevedibile). attivit do dm dp attivit do dm dp a 10 n 10 b 7 9 13 o 20 22 30 c 6 8 15 p 18 25 30 d 5 6 7 q 3 3 4 e 10 r 3 3 4 f 8 9 10 s 2 g 15 17 25 t 3 4 5 h 3 3 5 u 2 3 6 i 4 7 8 v 15 l 5 x 5 m 6 7 9 z 10 Si supponga che lobbiettivo sia di finire il progetto in 70 giorni (target() = 70): calcolare la pro-babilit che ci avvenga.

La gestione dei progetti informatici 1

34/38

1.6 La pianificazione come compromesso fra tempo e risorse In questo paragrafo vengono brevemente discussi due problemi.

1. Dato uno schema di progetto, rappresentato da un Gantt o da un grafo CPM, cio supponen-do assegnate le attivit, la struttura di precedenza, la loro durata e le risorse necessarie per portarle a termine (nella durata stabilita), utilizzando gli eventuali slack, risistemare la attivi-t nel tempo in modo da diminuire i picchi di impiego delle risorse, supponendo,inoltre, che tutte le risorse siano equivalenti.

2. Dato uno schema di progetto, rappresentato da un Gantt o da un grafo CPM, cio supponen-

do assegnate le attivit, la struttura di precedenza, la loro durata e le risorse necessarie per portarle a termine (nella durata stabilita), riassegnare le risorse alle attivit in modo che il numero di risorse impegnate in ogni momento del progetto non superi un valore assegnato: naturalmente pu variare la durata totale del progetto.

Problema 1. Nella soluzione del problema 1 di fondamentale importanza riferirsi al cammino cri-tico, quindi conviene partire dal CPM e dalla determinazione del cammino critico. La prima cosa da costruire un Gantt la cui prima attivit il cammino critico, che una catena connessa di attivit che nel complesso iniziano al tempo t() e terminano al tempo t(); le altre righe del Gantt portano le altre attivit singolarmente, riportando per ciascuna lintervallo completo di variabilit (cio la sua durata preceduta dallo slack). Corrispondentemente, nellintervallo di tempo [t(), t()] si co-struisce listogramma del numero di risorse utilizzate. La soluzione del problema si ottiene euristi-camente per tentativi, spostando la durata delle attivit che non sono sul cammino critico nel loro intervallo di variabilit in modo che il corrispondente istogramma abbia le propriet richieste (sia tutto al di sotto del livello corrispondente al numero massimo di risorse prefissato, senza natural-mente cambiare le risorse assegnate alle singole attivit). Si consideri per esempio lo schema di progetto descritto dal grafo CPM descritto dalla seguente ta-bella.

Nodo di inizio Nodo di fine Durata dellattivit Risorse assegnate B 4 3 D 3 4 B C 5 2 B D 5 2 B 8 3 D 7 3 C 6 2

Si verifica facilmente che il cammino critico dato dalla seguente catena: (,B,D,). Si verifica i-noltre che gli slack sono dati dalla seguente tabella

Nodo di inizio Nodo di fine Slack totale Slack libero D 6 6 B C 1 0 B 4 4 C 1 1

La gestione dei progetti informatici 1

35/38

Il Gantt corrispondente (costruito come descritto sopra), in cui tutte le attivit sono allocate il pi tardi possibile, mostrato in figura 1.21. D B B C C 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Figura 1.21

Costruendo listogramma sopra definito si nota un picco di 11 risorse tra lottava e la nona settima-na nella quale si sovrappongono 4 attivit (B-D con 2, -D con 4, B- con 3 e B-C con 2). Una diversa distribuzione temporale delle attivit, in cui ognuna di esse viene allocata prima possi-bile, come mostrato in figura 1.22, porta ad un picco di 8 risorse nellintervallo fra la nona e la do-dicesima settimana (D- con 3, B- con 3 e C- con 2).

D B B C C 0 1 2 3 4 5 6