Pianificare e controllare progetti nel settore ICT

Transcript

1 Pianificare e controllare progetti nel settore ICT G.Raiss - 3 maggio Definizioni Dalla norma ISO Guidelines to quality in project (1997) Progetto un processo unico, composto da attività coordinate e controllate, con una data di inizio e di fine definite, finalizzate a raggiungere degli obiettivi conformi a degli specifici requisiti, incluso il rispetto di vincoli di tempo, costo ed utilizzo risorse G.Raiss - 3 maggio Definizioni ISO Project Management un processo continuo di pianificazione, organizzazione, monitoraggio e controllo di tutti gli aspetti di un progetto al fine di raggiungere determinati obiettivi definiti G.Raiss - 3 maggio

2 Compiti del Project Manager Prevedere costi/tempi/uso risorse/volume di software da sviluppare Pianificare le attività Allocare e gestire le risorse Avviare le attività Coordinare lo svolgimento dei lavori Controllare lo stato di avanzamento dei lavori Relazionare al cliente sul SAL Chiudere il progetto G.Raiss - 3 maggio ISO 9001: pianificare progetti Attività Descrizione Work Breakdown Structure Scomposizione del componente in una struttura (WBS) gerarchica di sottocomponenti Preventivi e controllo dei Preventivazione, mediante opportune metodologie, costi delle risorse necessarie e dei relativi costi per tutte le attività elementari Costruzione del gruppo di Definizione della struttura organizzativa del gruppo, progetto delle responsabilità e dei compiti Pianificazione temporale Pianificazione temporale delle attività elementari Analisi dei rischi Identificazione delle aree di potenziale rischio manageriale e/o tecnico Aspetti legali/contrattuali Identificazione e definizione degli aspetti legali e contrattuali relativi al progetto Piano di progetto/sviluppo Preparazione e aggiornamento del piano del progetto Controllo avanzamento Controllo dello stato di avanzamento del progetto a intervalli prestabiliti e preparazione dei relativi rapporti di avanzamento G.Raiss - 3 maggio Il principio W 5 HH Barry Boehm suggerisce al project manager di porsi queste domande: Why: perché si sviluppa il progetto (scopo) What: cosa deve essere fatto e quando Who: chi è responsabile di cosa Where: dove sono le responsabilità How: in che modo il lavoro verrà eseguito How much: in che quantità è richiesta ogni risorsa G.Raiss - 3 maggio

3 Domande per il Project Manager Altre domande cui bisogna rispondere: E possibile stimare i rischi di insuccesso di un progetto? Come si documenta lo stato delle attività? Vi sono aspetti legali da considerare? E possibile stimare costi e tenerli sotto controllo? G.Raiss - 3 maggio Il buon Project Manager Definizione del buon responsabile di un progetto chi sa cosa andrà male, prima che ciò avvenga realmente Al crescere della dimensione dei progetti, aumenta il numero di cose che possono andar male Validità della legge di Murphy: Se molte cose possono andar male in un progetto, lo faranno G.Raiss - 3 maggio Alcuni esempi di esito dei progetti Valori percentuali Dimensione progetto (FP) Esito finale < K 1K-5K >5K Soppresso Ritardo di almeno 1 anno Ritardo tra 6 e 12 mesi Ritardo inferiore a 6 mesi Anticipo Mesi Dimensione progetto (FP) Durata media < K 1K-5K >5K Pianificata Effettiva Ritardo G.Raiss - 3 maggio

4 Docmentare per non rischiare Documenti con cui descrivere il progetto Studio di fattibilità Capitolato tecnico / offerta tecnica Riesame dei requisiti Proposta progettuale Piano di progetto e piani correlati Rapporti di stato di avanzamento Proposte di revisione G.Raiss - 3 maggio Studio di fattibilità e fasi del progetto Pianificazione e individuazione progetti Elementi di definizione progetti Progetti individuati Studio di fattibilità Elementi per la gara Gestione approvvigionamento Progetto di massima Realizzazione Elementi per la valutazione di qualita Monitoraggio Valutazione costi/benefici Verifica dell investimento G.Raiss - 3 maggio Indice SF e fasi del progetto Situazione attuale Progetto di massima Requisiti, Specifiche, Modalità realizzative Analisi del rischio Analisi costi-benefici Piano di massima, raccomandazioni per fasi operative Gestione approvvigionamento Realizzazione Monitoraggio Verifica dell investimento G.Raiss - 3 maggio

5 La fonte dei requisiti I requisiti per il Project Manager vengono dal cliente In genere, attraverso atti formali che definiscono i termini di un rapporto contrattuale Molti requisiti possono essere impliciti Molti requisiti possono essere non chiari o non immediatamente traducibili in soluzioni tecniche Riesame dei requisiti G.Raiss - 3 maggio Riesame dei requisiti - ISO a) tra gli aspetti legati ai rapporti con l utenza: la terminologia utilizzata, che deve essere compresa ed accettata da tutte le parti coinvolte nel contratto; la capacità del Committente di soddisfare e gli impegni contrattuali, specie per quanto riguarda il coinvolgimento di proprie risorse nelle attività; le modalità di svolgimento di joint reviews per monitorare gli stati di avanzamento delle attività, che devono essere chiare e note (pianificate); le procedure per la gestione delle modifiche in corso d opera, anch esse da chiarire e stabilire a priori; la presenza di eventuali standards, di processo o di prodotto, presso il Committente, di cui viene chiesto il rispetto G.Raiss - 3 maggio Riesame dei requisiti (2) a) aspetti legati ai rapporti con l utenza (cont ): le modalità di gestione dei problemi rilevati in corso d opera, in particolare come devono essere segnalati, presi in carico, gestiti, archiviati; le responsabilità per la rimozione delle non conformità rilevate; le obbligazioni (per il Committente) circa il mantenimento in esercizio di versioni obsolete di prodotti che potrebbero penalizzare o danneggiare il sistema complessivo fornito e, specularmente, le obbligazioni per il fornitore a rendere disponibili le versioni aggiornate dei propri prodotti; le necessità di formazione per l utenza e le sue modalità; G.Raiss - 3 maggio

6 Riesame dei requisiti (3) b) aspetti tecnici: l applicabilità (al contesto del contratto e dell utenza) del ciclo di vita di sviluppo del prodotto proposto e degli strumenti (tools, piattaforme hardware e software di base) utilizzati; i requisiti per le interfacce da prevedere nel prodotto; i requisiti per la replicazione e la distribuzione del codice realizzato; G.Raiss - 3 maggio Riesame dei requisiti (4) c) aspetti organizzativi: i rischi connessi alla commessa ed i loro possibili impatti; le responsabilità del fornitore verso eventuali sub appaltatori; la pianificazione delle consegne e delle verifiche degli stati di avanzamento; i requisiti per le installazioni e per le attività di manutenzione ed assistenza da svolgere dopo il rilascio in esercizio del prodotto fornito; la pianificazione della disponibilità delle risorse umane, tecniche e finanziarie necessarie al progetto; G.Raiss - 3 maggio Riesame dei requisiti (5) d) aspetti legali e riguardanti la sicurezza: il livello di protezione e divulgabilità delle informazioni maneggiate durante lo svolgimento delle attività previste dal contratto; le condizioni riguardanti la proprietà intellettuale di quanto realizzato; i termini della garanzia su quanto consegnato; le penali associate al contratto. Offerta Discussione e ridefinizione offerta Ordine del cliente, contratto Eventuali modifiche all ordine - contratto G.Raiss - 3 maggio

7 Dalla ISO 90001, i motivi dell importanza di una buona progettazione : Nella fase di progettazione - sviluppo: Riesame della progettazione Vengono definite quasi tutte le caratteristiche che contrastano la qualità negativa collegato al punto 1): viene determinato circa il 90% del costo totale di utilizzo del prodotto/servizio(manutenibilità, affidabilità, sicurezza ecc.) vengono definite molte delle caratteristiche specifiche che aumentano la qualità positiva (i plus di prodotto) G.Raiss - 3 maggio Riesame della progettazione (2) si possono contenere i costi di prodotto progettando prodotti servizi facilmente producibili, installabili, standardizzabili si possono apportare modifiche al prodotto servizio con costi da 10 a 1000 volte inferiori rispetto alle modifiche apportate in produzione erogazione ( per non parlare di quelle apportate a prodotto/servizio venduto) G.Raiss - 3 maggio Riesame della progettazione (3) Clausola 4.4.1: Generale La clausola richiede che le procedure dell azienda assicurino che le attività di progetto siano propriamente condotte, registrate e riesaminate; Clausola 4.4.2: Pianificazione del progetto e dello sviluppo Prima di iniziare con la progettazione, devono essere preparati dei piani che coprano tutte le attività di progetto, i piani devono definire le responsabilità per ciascuno stadio del progetto, il piano deve essere aggiornato ogni qualvolta che il progetto evolve; in pratica, il progetto sarà spesso condotto da una persona in particolare, la quale dovrebbe essere identificata nel piano di progetto; se richiesto inoltre, la società deve poter dimostrare che tutte le persone coinvolte nel progetto possiedono la qualifica/esperienza adeguate; G.Raiss - 3 maggio

8 Riesame della progettazione (4) Clausola 4.4.3: Organizzazione & Interfacce tecniche Il piano di progettazione deve identificare i differenti gruppi di persone coinvolte nel progetto (ad esempio: team di sviluppo, ufficio disegni, reparto produzione ecc.), inoltre devono essere definite le modalità di comunicazione tra tali gruppi (ad esempio riunioni settimanali ecc.); le interfacce tra i gruppi possono cambiare durante lo svolgimento del lavoro di progettazione, tali cambiamenti devono essere documentati e sottoposti a riesame; G.Raiss - 3 maggio Riesame della progettazione (5) Clausola 4.4.4: Input del progetto Tutte le informazioni richieste per produrre il progetto devono essere fornite, tra le quali: Dati tecnici (manuali, standards ecc.) Requisiti, esigenze dei clienti (possono provenire ad es. dalla sezione Marketing) Requisiti di legge (leggi locali, direttive comunitarie ecc.) Requisiti di produzione (processi disponibili, metodi efficienti ecc.) Questi inputs dovrebbero essere riesaminati prima dell inizio e durante lo sviluppo del progetto, ogni informazione ambigua o incompleta deve essere risolta in base alla fonte di ciascuna informazione o con la persona responsabile del rispetto del requisito. G.Raiss - 3 maggio Riesame della progettazione (6) Clausola : Output del progetto L output del progetto deve essere documentato, il contenuto della documentazione deve essere espresso in termini quantificabili in modo da poterli verificare e validare in funzione dei requisiti richiesti; l output deve: Rispettare i requisiti di progetto Specificare il modo in cui è stato collaudato per essere accettabile Specificare gli aspetti importanti per ciò che concerne la sicurezza ed il corretto funzionamento del prodotto (ad esempio: requisiti di manutenzione, operativi) G.Raiss - 3 maggio

9 Riesame della progettazione (7) Clausola : Riesame del progetto Il progetto deve essere riesaminato dai rappresentanti delle varie interfacce tecniche interessate dalla fase di riesame; dove richiesto, altro personale tecnico o il cliente può essere coinvolto nel riesame, la revisione deve essere registrata; Clausola : Verifica del progetto Il progetto, durante il suo sviluppo, deve essere verificato negli stadi appropriati. La verifica del progetto include : Controllo dei calcoli tramite l utilizzo di metodi alternativi Comparazione con progetti precedenti ed analoghi che hanno avuto successo Revisione dei documenti G.Raiss - 3 maggio Riesame della progettazione (8) Clausola : Validazione del progetto La validazione è simile alla verifica, ma mentre la verifica è il processo mediante il quale si controlla che il progetto sia conforme ai requisiti di progetto, la validazione è il processo mediante il quale si assicura che il progetto sia conforme alle aspettative del cliente. Clausola : Cambiamenti nel progetto Ogni cambiamento del progetto deve essere documentato, riesaminato ed approvato, poi notificato a tutte le persone interessate, tra le quali il cliente o gli altri dipartimenti dell azienda G.Raiss - 3 maggio Costruire la proposta progettuale Il project manager deve produrre una previsione rispetto a tempi, costi, impegno, dimensioni del progetto Metodi Analogia: basarsi su progetti con caratteristiche simili (empirici) Analitici: Scomposizione del problema Statistici: definire una funzione che descrive il fenomeno, ed usare tecniche di regressione lineare per stimare i parametri a partire da dati reali Compositi G.Raiss - 3 maggio

10 Grandezze stimate Sforzo (Effort, Cost) Il numero di mesi-uomo (MM) o anni-uomo (MY) necessari per realizzare il progetto, ed il costo. Durata dello sviluppo (Delivery Time) Tempo che intercorre dall inizio del progetto al momento in cui la prima versione operativa del prodotto è disponibile. Impegno (Manpower) Sforzo sviluppato nell unità di tempo; è la derivata di MM rispetto al tempo. Corrisponde al numero di persone che lavorano contemporaneamente al progetto. G.Raiss - 3 maggio Previsioni di volume - LOC Line Of Code (LOC) Metrica dipendente dal linguaggio utilizzato e dalle tecniche di sviluppo Problemi: non tiene conto della diversa potenza dei linguaggi Difficile definire esattamente cosa è una LOC (istruzioni spezzate su più righe, o più istruzioni su una stessa riga, ruolo dei commenti.) Non c è una relazione tra produttività e qualità G.Raiss - 3 maggio Previsioni di volume - FP Function Points Metrica che conta le funzionalità sviluppate, indipendente dal linguaggio e dalle tecniche di sviluppo Le regole del conteggio sono stabilite da una organizzazione inernazionale (IFPUG, GUFPI in Italia, Problemi: Banalizza la definizione di complessità, che dipende sostanzialmente dallo I/O e non dalle caratteristiche dell algoritmo G.Raiss - 3 maggio

11 Modelli statistici/empirici I modelli statistici/empirici si basano sulla correlazione tra la grandezza da stimare E ed una funzione f, secondo la forma seguente: E = f (V i ) dove V i sono variabili indipendenti (ad es. LOC e FP) La struttura di questi modelli è di solito: E = a + b x (V i ) C dove a, b e c sono costanti ricavate empiricamente G.Raiss - 3 maggio Modelli statistici/empirici I modelli sono ottenuti attraverso una analisi di regressione su dati dei progetti passati. Ad esempio, sono modelli basati sulle LOC E = 5.2 x (KLOC) 0.91 Walston - Felix E = x (KLOC) 1.16 Bailey - Basile E = 3.2 x (KLOC) 1.05 Boehm semplice E = x (KLOC) Doty (per Kloc >9) Sono basati sui FP E = ,0545 FP Albrecht - Gaffey E = x x 10-8 FP 3 Kemerer E = FP Mattson-Barnett G.Raiss - 3 maggio Obiettivo delle previsioni I modelli statistici/empirici funzionano come delle black box che calcolano delle grandezze a partire da dati in ingresso Specifiche Determinazione dello sforzo Costo Tempo G.Raiss - 3 maggio

12 Modelli statistici/empirici - limiti I modelli statistici/empirici hanno in genere dei fattori di aggiustamento e regolazione per adattare i valori risultanti al contesto (alle specifiche del progetto). L esame dei diversi modelli proposti mostra che portano a risultati sempre diversi tra loro! E necessario quindi calibrarli. G.Raiss - 3 maggio Famiglie di metodologie Metodologie per la determinazione dello sforzo in mesi uomo e del tempo di sviluppo a partire dalle linee di codice Il metodo Cocomo Metodologie per la determinazione dello sforzo (in termini di funzioni da sviluppare) a partire dalle specifiche Il metodo dei punti funzione Metodologie per passare dai punti funzione alle linee di codice Backfiring G.Raiss - 3 maggio Critiche ai Function Points Non rispondono ai requisiti della teoria della rappresentazione, secondo la quale: va definita l entità da misurare (i.e. una persona) va definito l attributo da misurare (i.e. l altezza) va definita la corrispondenza tra l osservazione diretta e la misura raccolta (i.e. una persona più alta ha una misura in cm maggiore di una persona più bassa e la differenza tra le due misure è proporzionale alla differenza tra le loro altezze) Nel caso dei FP l entità da misurare è la specifica di alto livello della applicazione, l attributo (ma non chiaramente identificato) sono le funzionalità a disposizione dell utente, la misura si ricava conteggiando attributi più elementari G.Raiss - 3 maggio

13 Critiche ai Function Points (2) Manca una correlazione tra la conoscenza empirica che abbiamo dell attributo funzionalità ed il conteggio in FP Come si può dire che una specifica descrive esattamente una funzionalità x volte maggiore o minore di un altra? Come si può dire che x file interni logici, x file esterni logici, x input esterni, x output esterni, x query contribuiscono tutti allo stesso modo al conteggio finale? Come è possibile dire che un input di bassa complessità contribuisce al conteggio finale esattamente la metà di uno di elevata complessità, meno di un terzo di una interfaccia di alta complessità, meno del doppio di un output di media complessità? G.Raiss - 3 maggio Critiche ai Function Points (3) Inoltre, usare fattori di aggiustamento per correggere il conteggio è irragionevole dal punto di vista della teoria della rappresentazione è come se per calcolare più precisamente l altezza di una persona si usasse una sua correlazione con la lunghezza dei piedi, o la superficie delle orecchie etc.. I fattori di aggiustamento non sono tra l altro di validità universale: talvolta sono troppi, altre volte ne andrebbero aggiunti altri In ogni caso i fattori di aggiustamento hanno validità limitata (al massimo ognuno modifica del 5% il valore dei FP grezzi, e l influenza massima è uguale per tutti) G.Raiss - 3 maggio Critiche ai Function Points (4) Non viene considerata la complessità dell algoritmo che realizza la funzionalità Non tengono conto dei requisiti non funzionali, non meno importanti per un utente (v. ISO/IEC 9126) Non è logico affermare che lo sforzo è indipendente dalla tecnologia e dal linguaggio di sviluppo G.Raiss - 3 maggio

14 Backfiring La tecnica per passare dal calcolo in in FP a quello in LOC si chiama Backfiring Usa un coefficiente di trasposizione proprio dei diversi linguaggi di sviluppo Usa un coefficiente correttivo che tiene conto del contesto LINGUAGGIO LOC/FP ASSEMBLER 320 JCL 220 C 128 ANSI COBOL CICS 46 Fonte Capers Jones Visual Basic 40 C++ 29 SQL 12 G.Raiss - 3 maggio Coefficienti di backfiring Linguaggio Livello nominale LOC per Function Point Minimo Media Massimo 1st Generation Basic assembly Macro assembly C BASIC (interpreted) Fortran Cobol C SmallTalk SQL G.Raiss - 3 maggio Correzione del backfiring Si tiene conto di tre aspetti (valutazioni da 1 a 5) Complessità del problema 1: Solo algoritmi e calcoli semplici.. 5: Molti algoritmi e calcoli complessi Complessità delle strutture dati 1: Poche variabili scarsamente correlate tra di loro 5: Struttura dei file complessa con molte interrelazioni tra file G.Raiss - 3 maggio

15 Correzione del backfiring (2) Complessità del codice 1: Non Procedurale 2: Molto strutturato, con moduli riusabili 5: Scarsamente strutturato Il coefficiente di aggiustamento è determinato con la formula: 0,7 + 0,05 (Ct - 3) dove Ct è la somma dei tre livelli di complessità G.Raiss - 3 maggio Esempio backfiring Applicazione di 45 Fp Assumiamo di scrivere il programma in C Complessità Problema: Semplice Complessità Dati: Struttura semplice Complessità programma: Molto strutturato G.Raiss - 3 maggio Esempio backfiring (2) Coefficiente di backfiring del linguaggio ( C ) = 128 Correzione del coefficiente: PROBLEMA DATI CODICE TOTALE COMPLESSITA BAF = 0,7 + 0,05 (5-3) = 0,8 Coefficiente applicazione: 128 x 0,8 = 102 Dimensione applicazione: 45 x 102= 4590 LOC G.Raiss - 3 maggio

16 Produttività Unità di misura: Giorni persona (GP) Mesi/persona LOC/GP (o LOC/MP) FP/GP (o FP/MP) WARNING Aggiungere personale, oltre un certo limite, non abbrevia i tempi La produttività complessiva di un team non è proporzionale al numero di persone che vi lavorano La produttività varia tra individui anche da 1 a 10 G.Raiss - 3 maggio Rapporto produttività - dimensioni La produttività può variare in modo rilevante a seconda della dimensione dell applicazione Fonte Capers Jones DIMENSIONI (Valore in FP) PRODUTTIVITA MEDIA (FP/MP) , , , , , , , , , , , , ,64 5 5,64 G.Raiss - 3 maggio Stima durata progetto Bottom UP Sistema da sviluppare = D acquisizione dati elaborazione uscita risultati input convalida calcolo gestione sintesi errori risultati output Dati noti: Dimensione progetto (D) produttività mese-persona (P) Risorse allocate = R M = D/P/R (M= durata in mesi del progetto) Irrealistico: Non tiene conto delle relazioni esistenti tra le attività che compongono il progetto e tra i compiti distribuiti in un team G.Raiss - 3 maggio

17 Modelli di previsione empirici Wolverton Basato sul divide et impera della decomposizione funzionale Assume che il ciclo di sviluppo sia a cascata Usa una matrice predittiva 25x7 Ogni modulo è classificato in base a: Appartenenza ad uno tra 6 tipi (control, I/O ) Nuovo modulo (SI/NO) Livello di difficoltà del progetto (basso, medio, alto) Viene stimata la dimensione di ogni modulo Il costo è valutato in confronto con progetti dalle caratteristiche simili G.Raiss - 3 maggio Modelli di previsione statistici Walston e Feli Relaziona lo sforzo (E) richiesto per sviluppare il software, espresso in mesi/uomo, al numero di KLOC da sviluppare (L) E = al b Per determinare a e b si usano tecniche di regressione lineare Walston e Feli propongono a=5.2 e b=0.91 La produttività è calcolata come E/L G.Raiss - 3 maggio Modelli di previsione analitici Putnam Assume che l utilizzazione delle risorse umane sia descritta da una curva (di Raylegh-Norden) Dove Y = numero di persone assegnate al progetto al tempo t T = tempo di sviluppo E = sforzo complessivo espresso in anni uomo G.Raiss - 3 maggio

18 ..Putnam. Putnam (segue) Il modello propone questa relazione per legare la dimensione del sistema da sviluppare (in LOC) con il tempo necessario a sviluppare L = ce 1/3 T 4/3 Dove L = numero di LOC T = tempo di sviluppo E = area sottostante (integrale) alla curva di Raylegh (sforzo in anni uomo) c = costante dipendente dalla tecnologia G.Raiss - 3 maggio Putnam. La relazione tra dimensione del sistema da sviluppare (in LOC) e tempo necessario allo sviluppo, può essere espressa come E = (LOC x B 1/3 / P) 3 x (1 / t 4 ) Dove T = durata del progetto (in anni) E = impegno in anni uomo B = fattore di aggiustamento (di competenza ) P = produttività (si basa su diversi elementi, come maturità processo, conoscenze di dominio e tecniche, tipo linguaggi, complessità progetto) G.Raiss - 3 maggio Putnam... Valori tipici di P sono 2000 per software embedded per software per TLC per software gestionale E importante notare che Putnam prevede due variabili indipendenti, le Loc e la durata del progetto Tempo minimo di sviluppo (in mesi): t min = 8.14 (LOC / P) 0.43 G.Raiss - 3 maggio

19 Modelli di previsione analitici Halstead (software science) Numeri - base n 1 = numero di operatori distinti in un programma n 2 = numero di operandi distinti in un programma N 1 = numero delle occorrenze di operatori in un programma N 2 = numero delle occorrenze di operatori in un programma Lunghezza del programma N = N 1 + N 2 Vocabolario del programma n = n 1 + n 2 G.Raiss - 3 maggio Modelli di previsione analitici.halstead (segue) Stima della lunghezza del programma N = n 1 log 2 n 1 + n 2 log 2 n 2 Volume del programma (in bit) V = N log 2 n Difficoltà del programma D = (n 1 / 2) x (N 2 / n 2 ) Livello del programma L = 1/D Sforzo e tempo di sviluppo E = V/L T = E/C dove C=18 di solito (ma 5<C<20) G.Raiss - 3 maggio Modelli di previsione compositi COCOMO (COnstructive COst Model), sviluppato da B.Boehm, 1981 Assume un ciclo di vita a cascata Stima lo sforzo M ed il tempo di sviluppo T più probabili Basato su statistiche Fornisce una indicazione percentuale della distribuzione di M e T su 4 fasi del ciclo di vita (Analisi, Progettazione, Sviluppo, Test) G.Raiss - 3 maggio

20 COCOMO I - Caratteristiche Definisce 3 livelli di stima (in base alla quantità di infomazioni disponibili) Basic Intermediate Detailed Identifica 3 tipi di progetto cui si applica (in base alla complessità del progetto): Organic Semi-detached Embedded G.Raiss - 3 maggio COCOMO Classi di difficoltà Organic Applicazioni semplici e di limitate dimensioni, requisiti poco stringenti, ambiente di sviluppo noto Semi-detached Complessità e dimensioni medie Embedded Applicazioni complesse, con attento controllo del processo e rigidi vincoli sulla qualità (i.e. sistemi real time, applicazioni militari o per il volo) G.Raiss - 3 maggio COCOMO - Assunzioni La stima considera come variabili indipendente la dimensione S (KLOC di linee di codice sviluppate per il progetto) T (tempo in mesi) è stimato dalla fase di progetto a quella di integrazione e test. La raccolta dei requisiti non viene considerata Il mese di lavoro M è composto da: 19 giorni 152 ore di lavoro I requisiti devono essere abbastanza stabili G.Raiss - 3 maggio

21 COCOMO Modello base M = a S b T = c M d dove: M = mesi persona T = durata totale progetto in mesi a, b, c, d sono costanti che dipendono dal tipo di progetto tipo di applicazione a b c d Semplice 2,4 1,05 2,5 0,38 Intermedia 3 1,12 2,5 0,35 Complessa 3,6 1,2 2,5 0,32 G.Raiss - 3 maggio COCOMO Modello intermedio Come il modello base, ma si considera l influenza di 15 fattori correttivi (cost drivers). L equazione diventa: M = a S b m dove: 15 m = C i C sono i 15 fattori correttivi i=1 Ogni fattore può assumere 6 diversi valori G.Raiss - 3 maggio COCOMO Modelli - Sinottico Tipo di modello Base Intermedio Dettagliato Caratteristiche generali progetto Semplice (organic) Intermedio (semi-detached) Solo dimensione complessiva coefficienti di correzione globali 1, 05 M = 2, 4 S 15 k M = M c Nom i 0, 38 1 T = 2, 5 M MNom = 3 2S 1,, 05 k M = 3 0 S 1,, 12 k 15 0, 35 T = 2, 5 M M = M c Nom i 1 MNom = 3 0S 1,, 12 k coefficienti di correzione per ciascuna fase idem idem Complesso (embedded) M = 36 Sk 1,, 20 M = M 0, 32 Nom ci T = 2, 5 M 1, M = 2, 8S Nom 15 k 1 20 idem G.Raiss - 3 maggio

22 Distribuzione % per fasi - Organic Dimensione (in KDSI) Modo Fasi Organic Pian. e requis Progetto Sviluppo M Integ. e test Pian. e requis Progetto Sviluppo Integ. e test T G.Raiss - 3 maggio Distribuzione % per fasi - Semidetached Dimensione (in KDSI) Modo Fasi Semidetach. Pian. e an.requis Progetto Sviluppo Integ. e test Pian. e an.requis Progetto Sviluppo Integ. e test M T G.Raiss - 3 maggio Distribuzione % per fasi - Embedded Dimensione (in KDSI) Modo Fasi Embedded Pian. e requis Progetto Sviluppo Integ. e test Pian. e requis Progetto Sviluppo Integ. e test M T G.Raiss - 3 maggio

23 Esempio (1) Modello base - progetto semplice (organic) S=32K M=2.4(32) 1.05 =91 Mesi/persona T=2.5(91) 0.38 =14 mesi di durata N Persone da impiegare = 91/14= 6.5 Produttività=32K/91=0.352 kloc/mese! 18.5 loc / giorno!!!! G.Raiss - 3 maggio Esempio (continua) Quanti mesi/uomo di programmazione? Quanto dura (T) la programmazione? Quanti programmatori servono? Mprog=0.55*91=50 Mprog Tprog=0.62*14= 8.7 mesi Programmatori=50/8.7=5.7 Se S non è in tabella: interpolazione lineare G.Raiss - 3 maggio Cocomo - Fattori di complessità (1) Prodotto RELY: REquired software reliability( n/a) Affidabilità richiesta intesa come difettosità residua DATA: DATA base size (n/a n/a) Dimensione relativa al programma dei dati gestiti CPLX: product ComPLeXity ( ) Complessità globale del prodotto G.Raiss - 3 maggio

24 Sistema Cocomo - Fattori di complessità (2) TIME: execution TIME constraint (n/a n/a) Requisiti di efficienza STOR: main STORage constraint (n/a n/a) Requisiti di memoria centrale VIRT - VIRTual machine volatility (n/a n/a) Frequenza con cui le caratteristiche del sistema target vengono modificate durante lo sviluppo TURN - computer TURNaround time ( n/a-n/a) Tempo di risposta accettabile G.Raiss - 3 maggio Cocomo - Fattori di complessità (3) Personale ACAP - Analyst CAPability ( n/a) Efficienza del personale di analisi AEXP - Application EXPerience ( n/a) Esperienza nello sviluppo di sw simile PCAP - Programmer CAPability ( n/a) Efficienza del personale di programmazione VEXP - Virtual machine EXPerience ( n/an/a) Disponibilità di esperienza nell uso della macchina target LEXP: Program. Language EXPer. ( n/an/a) Esperienza nell uso del linguaggio di programmazione G.Raiss - 3 maggio Cocomo - Fattori di complessità (4) Progetto MODP: MODern Program. practices ( n/a) Uso di tecniche di programmazione efficienti TOOL - use of software TOOLs ( n/a) Uso di strumenti automatizzati SCED - SChEDule constraints ( n/a) Vincoli sul tempo di conclusione del progetto G.Raiss - 3 maggio

25 Modello intermedio fattori Modifica di M mediante 15 coefficienti correttivi ESEMPI Coefficiente correttivo M. Ba. Basso Nom. Alto M. Alto E.Alto Attributi del progetto Affidabilità richiesta 0,75 0,88 1,0 1,15 1,40 Complessità prodotto 0,70 0,85 1,0 1,15 1,30 1,65 Attributi del personale Esperienza analisiti 1,40 1,19 1,0 0,86 0,71 Esper. applicativa 1,29 1,13 1,0 0,91 0,82 Esperienza progr. 1,42 1,17 1,0 0,86 0,70 Attributi del progetto Vincolo tempo svilup. 1,23 1,08 1,0 1,04 1,10 G.Raiss - 3 maggio Considerazioni su COCOMO I Modello base - errore<20% nel 25% dei casi Modello intermedio - errore<20% nel 68% dei casi Modello avanzato - errore<20% nel 70% dei casi Usare le LOC come unità di misura premia la inefficienza Poco utilizzabile a scopi previsionali nelle fasi alte del CVS Inadeguato per I linguaggi avanzati G.Raiss - 3 maggio COCOMO I alla NASA Per fare qualche prova. html G.Raiss - 3 maggio

26 COCOMO II Motivazioni Nuovi modelli per il ciclo di vita Diffusione del Riuso Considerare differenti granularità nella conoscenza del problema 4X Incertezza stima Impegno X 0.25 X Ciclo di vita Accettazione G.Raiss - 3 maggio COCOMO II I tipi di software Differenzia 3 tipologie di software: End-User Programming (programmi piccoli e flessibili, sviluppati dagli stessi utenti attraverso degli Application Generators, >98% del mercato) Application Composition (applicazioni diversificate, da sviluppare ad hoc) Application Generators & Composition Aids (prepackaged capabilities), Systems Integration (embedded), Infrastructure (sistemi operativi, DBMS, networking systems, user interface management systems) Non si applica agli end user programs G.Raiss - 3 maggio COCOMO II I modelli Prevede 3 differenti modelli Application Composition Model (da usare nelle fasi iniziali o nei primi cicli di spirale, mentre si fa analisi dei requisiti e specifica della soluzione di massima, usando in genere prototipi) Early Design (da usare quando si è nella fase iniziale di disegno della architettura) Post Architecture (da usare quando l architettura è definita ed è definito il piano di sviluppo. Questo modello corrisponde come granularità al precedente modello COCOMO I) G.Raiss - 3 maggio

27 COCOMO II Unità di misura Prevede 3 unità di misura della dimensione: Object Points (da usare per Application Composition) Function Points (solo gli Unadjusted, secondo la definizione IFPUG, da usare per Early Design e Post Architecture) SLOC (Source Lines of Code secondo la definizione del SEI, da usare per Post Architecture) G.Raiss - 3 maggio COCOMO II Volatilità requisiti Viene considerata la volatilità dei requisiti BRAK = % di LOC di codice che vengono scartate dopo lo sviluppo a causa della volatilità dei requisiti (breakage) G.Raiss - 3 maggio COCOMO II Calcolo dello sforzo La formula per calcolare l impegno (in mesi persona) è la seguente: PM nom = A x SIZE B Dove A = costante (usualmente pari a 2,94) B = esponente del fattore di scala, che tiene conto di alcuni elementi di complessit à del progetto che provocano diseconomie di scala SIZE = Dimensione in KSLOC del codice G.Raiss - 3 maggio

28 COCOMO II Calcolo dello sforzo B si calcola solo per i modelli Early Design e Post Architecture, per i quali varia tra 1.01 e 1.26 secondo la formula B = W i Dove W i sono i punteggi assegnati a 5 fattori di scala Per il modello Application Composition B vale sempre 1.0 G.Raiss - 3 maggio COCOMO II Fattori di scala I 5 fattori di scala sono: Precedenti, flessibilità dello sviluppo, architettura, coesione dei team, maturità del processo (secondo il CMM) I possibili livelli assegnati ai fattori sono 6, e considerano le economie di scala che potrebbero introdurre, da molto bassa (=5), a extra alta (=0) Questi fattori di scala sostituiscono le 3 classi di difficoltà Organic, Semi-Detached ed Embedded del COCOMO I G.Raiss - 3 maggio COCOMO II Fattori di scala G.Raiss - 3 maggio

29 Fattore basato sul CMM Analisi livello di possesso % delle 18 aree di processo chiave (KPAs) G.Raiss - 3 maggio Checklist per l analisi delle KPAs G.Raiss - 3 maggio COCOMO II - Esempi Un progetto di 100 KSLOC con una valutazione di influenza molto alta (=0) per tutti i 5 fattori, avrà (considerando la costante A pari a 1): W i = 0 B = 1.01 Effort relativo = = 105 PM Un progetto di 100 KSLOC con una valutazione di influenza molto bassa (=5) per tutti i 5 fattori, avrà: W i = 25 B = 1.26 Effort relativo = = 331 PM G.Raiss - 3 maggio

30 COCOMO II moltiplicatori sforzo E possibile considerare alcuni ulteriori fattori di aggiustamento, che sono definiti moltiplicatori di sforzo (EM), per aggiustare la stima dei mesi/persona in funzione della natura specifica del progetto La formula per calcolare l impegno (in mesi persona) se si considerano i fattori di agiustamento è la seguente: PM adj = (P i EM i ) x A x SIZE B G.Raiss - 3 maggio COCOMO II Moltiplicatori di sforzo 7 da usare nel Early Design model 17 da usare nel Post Architecture model Divisi in 4 categorie: Prodotto, Piattaforma, Personale, Progetto Per ognuno dei fattori bisogna valutare il livello di influenza nel progetto, tra questi 6: molto basso, basso, nominale, alto, molto alto, extra alto Una valutazione di influenza nominale corrisponde ad un punteggio = 1 G.Raiss - 3 maggio COCOMO II Aggiustamento di PM nom Early Design Post Architecture G.Raiss - 3 maggio

31 COCOMO II 7 vs 17 fattori G.Raiss - 3 maggio COCOMO II - Esempio Un progetto di 8 KLoc ha tutti i cost drivers con influenza valutata nominale (=1). Si ha: P i Em i = 1 Se gli Scale Factors sono ugualmente tutti nominali (=3x5), si ha W i = 15 B = x 15 = 1.16 PM = 2.94 x (1.0) x (8) 1.16 = 32.8 Mesi/persona Se i cost drivers fossero tutti molto alti (=1.34) e gli Scale Factors tutti molto bassi (=5x5), si avrebbe PM = 2.94 x (1.34) x (8) 1.26 = 54 Mesi/persona G.Raiss - 3 maggio COCOMO II - Il riuso Il riuso viene considerato attraverso 3 fattori: SU : Software Understanding AA : Assessment and Assimilation UNFM : Programmer Unfamiliarity G.Raiss - 3 maggio

32 SU - Software understanding Se non c è modifica nel codice, SU non va calcolato G.Raiss - 3 maggio AA & UNFM G.Raiss - 3 maggio Calcolo Equivalent SLOC DM : % Design Modified CM : % Code Modified IM : % Integration Required For Modified SW G.Raiss - 3 maggio

33 Stima dei Tempi G.Raiss - 3 maggio Progetto - Previsione dei costi La prima fonte è lo studio di fattibilità piano triennale studio di fattibilità Sezione analisi costi/benefici Valutazione dei benefici attesi Individuazione e descrizione dei benefici attesi Individuazione ed esplicitazione delle metriche e dei valori attesi Correlazione obiettivibenefici Stima dei costi Individuazione delle principali voci di costo Esplicitazione delle metriche utilizzate Stima dell impegno di risorse umane Stima dei costi di impianto e di esercizio Analisi dell investimento obiettivi del progetto e quadro generale dei costi/benefici benefici monetizzabili (utilizzabili nell analisi costi-benefici) e benefici comunque misurabili ha poco senso parlare di benefici intangibili (non misurabili) esplicitare modalità di stima adottate, per consentire ai centri decisionali una valutazione dell attendibilità della stima effettuata. giustificazione economica all investimento necessario sintesi degli elementi per la decisione sull avvio del progetto G.Raiss - 3 maggio Studio di fattibilità - Analisi Costi 10 - Investimento e Sviluppo 10 Hardware 10 Elaboratori mainframe 20 Elaboratori intermedi 30 PC e workstation 40 Apparecchiature di rete 50 Altro hardware 20 Software 10 Sw di base e d'ambiente 20 Pacchetti applicativi 30 Pacchetti office 30 Servizio di sviluppo 10 Studi e consulenze 20 Sviluppo sw e manut. evolutiva 30 Avviamento e messa in produz. 40 Monitoraggio 50 Formazione 40 Altre voci 10 Altri costi di invest. e sviluppo 20 - Manutenzione e gestione 10 Manutenzione Hardware 10 Manut. Elaboratori mainframe 20 Manut. Elaboratori intermedi 30 Manut. PC e workstation 40 Manut. Apparecchiature di rete 50 Manut. Altro hardware 20 Manutenzione software 10 Manut. sw di base, d'ambiente 20 Manut. Pacchetti applicativi 30 Manut. Pacchetti office 40 Manut.corr.,adatt.,migl.(MAC) 30 Servizi di gestione 10 Servizi di telecomuicazione 20 Conduz. tecnico-operativa sist. 30 Assistenza sistemistica 40 Elabor. dati ed acc. BD est. 50 Aquisizione dati 60 Assistenza utenti 40 Altre voci 10 Altri costi di manut. e gestione Ciascuna delle precedenti voci di costo può essere dettagliata fino ad individuare gli elementi atomici oggetto della fornitura G.Raiss - 3 maggio

34 Previsione dei costi - fattori di costo Fattori che influenzano il costo: Dimensioni del problema Complessità tecnica ed applicativa Competenze sui domini Fattori umani (capacità, motivazioni degli sviluppatori) Stabilità dei requisiti Possibilità di riuso G.Raiss - 3 maggio Modalità di stima Le principali modalità utilizzate per la stima dei costi sono: l esperienza personale di uno o più esperti la stima per analogia la stima per mezzo di procedure ingegneristiche la stima con tecniche statistiche G.Raiss - 3 maggio Vantaggi e svantaggi dei metodi Utilizzare esperienza di esperti o confronti per analogia appare di immediata applicabilità e comprensibilità. Per utilizzare questi metodi occorre però notevole esperienza e professionalità, per identificare e utilizzare le analogie appropriate e per fare gli aggiustamenti per le differenze evidenziate Tuttavia, poiché il costo della stima per analogia è basso, questa può essere impiegata per controllare gli altri metodi e, d altra parte, è l unico metodo che si può impiegare in uno stadio preliminare di sviluppo G.Raiss - 3 maggio

35 Vantaggi e svantaggi dei metodi (2) Le procedure di tipo tecnico - ingegneristico, simili a quelle con cui si preventivano i costi in una produzione industriale, si basano sulla scomposizione delle attività da svolgere e dei materiali richiesti in singoli elementi ai quali vengono assegnati i costi sulla base di tempi e costi standard. E possibile calcolare molti elementi di costo, come quelli per la manutenzione e il controllo, come percentuali del lavoro di produzione richiesto G.Raiss - 3 maggio Vantaggi e svantaggi dei metodi (3) Il metodo statistico di stima del costo può utilizzare diverse tecniche, che vanno dal semplice tracciato grafico di curve alla analisi complessa di correlazione multipla. In ogni caso, l obiettivo consiste nel trovare una relazione funzionale tra i mutamenti nei costi e il fattore, o i fattori, dai quali il costo stesso dipende G.Raiss - 3 maggio Previsioni di costi Voci di costo Voci di costo Managers Personale tecnico Personale di supporto (segreterie, supporto amministrativo, supporto tecnico) Risorse tecnologiche (costi di ammortamento e manutenzione hardware e software di base e tools vari) Materiali di consumo (carta, nastri, CD ) Costi strutturali (locazione uffici, telefonia, energia elettrica) G.Raiss - 3 maggio

36 Costi di un prodotto software Tipologie di costi Costo fasi iniziali (analisi, ricerche di mercato, studio di fattibilità) + Costo risorse utilizzate per lo sviluppo + Costi manutenzione e supporto G.Raiss - 3 maggio Distribuzione Beta Per calcolare il valore stimato del costo (ma anche di altre variabili come tempo, sforzo), si può usare la distribuzione beta di probabilità: Valore atteso = (a + 4m + b) / 6 Dove a = valore ottimistico b = valore pessimistico m = valore verosimile G.Raiss - 3 maggio Distribuzione Una tipica distribuzione dell impegno nelle diverse fasi è: Analisi = 40% Codifica = 20% Test = 40% Ma è solo indicativa! G.Raiss - 3 maggio

37 Strategia di stima dei costi Si possono stimare i costi con 2 approcci: Top Down Si valuta il costo complessivo del progetto e lo si decompone attraverso iterazioni sulle varie componenti Bottom UP Si parte dai costi delle singole attività e si costruiscono per aggregazione i costi globali G.Raiss - 3 maggio Costi su base produttività in FP linguaggio senza impiego di metodi strutturati senza CASE Con CASE con impiego di metodi strutturati senza CASE con CASE basso livello (*) alto livello (+) La relazione tra dimensione e impegno, e quindi costo di produzione, non è un rapporto costante espresso da un valore di produttività media. Il legame tra dimensione e impegno è legato ad una serie di fattori che possono mutare in modo estremamente significativo il rapporto di produttività. I principali fattori sono il linguaggio di programmazione, la piattaforma tecnologica, la classe di rischio dell applicazione, la qualità attesa, la complessità e novità del problema da risolvere, l esperienza del gruppo di sviluppo, la metodologia di lavoro, l utilizzo di strumenti CASE, il grado di riuso di funzionalità già esistenti G.Raiss - 3 maggio Relazione produttività - linguaggi Relazione tra produttività e linguaggio (Fonte ISBSG) min. mediana max. Mainframe totale 0,9 8,7 68,9 3GL (terza generazione) 0,9 11,0 48,1 4GL (quarta generazione) 0,9 7,4 39,8 ApG (generatore) 0,9 7,4 39,8 Midrange totale 0,7 5,5 23,0 3GL 0,8 6,9 21,9 4GL 0,7 4,6 23,0 ApG 1,3 2,4 5,8 PC totale 0,2 2,9 59,4 3GL 0,9 7,5 59,4 4GL 0,2 2,3 3,2 G.Raiss - 3 maggio

38 Relazione produttività - Dimensione L analisi dei dati storici ha dimostrato che, benché sia vero che le dimensioni del progetto introducano un fattore di complessità più che proporzionale alle dimensioni del progetto, è anche vero però che le attività di processo sono ammortizzate meglio sui progetti medio-grandi che su quelli piccoli. Alcune analisi di benchmarking hanno evidenziato che la curva di produttività ha in realtà una forma ad U con un massimo corrispondente ad una dimensione intermedia. Esiste cioè una dimensione ottimale dei progetti, tale che i progetti più piccoli sono meno produttivi per l incidenza delle spese fisse di processo, mentre i progetti più grandi sono meno produttivi per il fattore esponenziale dovuto alla complessità G.Raiss - 3 maggio MIX di professionalità Gli impegni delle risorse si calcolano di solito in funzione di un mix di professionalità impegante nel progetto A 9% B 28% C 63% A = Direttore/ Consulente senior B = Progettista C = Specialista / Tecnico senior G.Raiss - 3 maggio Stima costo progetto Bottom UP Sistema da sviluppare = D acquisizione dati elaborazione uscita risultati input convalida calcolo gestione sintesi errori risultati Dati noti: costo x istruzione (C) produttività mese-persona (P) output $ = C x D G.Raiss - 3 maggio

39 Stima costo progetto Top Down Si basa sull analogia Tipo di problema, vincoli, ambiente di sviluppo, personale tecnico e sulla conoscenza di costi e gestione dei progetti passati Tempo, risorse usate nelle diverse fasi, costi Possono essere usati fattori di aggiustamento Il costo totale calcolato va poi ripartito sulle fasi ed attività del progetto G.Raiss - 3 maggio Piano di progetto Contenuti del Piano di progetto Organizzazione al servizio del progetto Risorse hardware e software Analisi dei rischi Milestones e deliverables Scheduling Modalità Reporting Referenziamento Piani correlati G.Raiss - 3 maggio PdP Organizzazione Tradizionalmente gerarchiche Resp.Sw Area Mgr. Area Mgr. Area Mgr. Prog.Mgr. Prog. Mgr. Prog. Mgr. Team Mgr. Team Mgr. Team Mgr. G.Raiss - 3 maggio

40 Altre strutture organizzative Per Funzione Direz. Generale Risorse umane Amministraz. Progettazione Pianificazione Produzione Acquisti Controllo prog. A Matrice Direzione Generale Progettazione Pianificazione Produzione Acquisti Controllo progetti Progetto A Progetto B Risorse Progetto C G.Raiss - 3 maggio Applicabilità strutture organizzative Quale struttura scegliere: Struttura per progetti - progetti complessi o molto grandi Struttura funzionale - progetti semplici che richiedono elevata specializzazione del personale Struttura a matrice - progetti mediamente complessi G.Raiss - 3 maggio Caratteristiche delle strutture Tipo di organizzazione Caratteristiche Pregi Difetti Funzionale Gerarchica A matrice - Compiti e ruoli rigidi - Un solo diretto superiore - Specializzazione professionale - Risorse allocate al team fino a conclusione del progetto - Centralità del progetto - partecipazione al progetto delle diverse funzioni aziendali - due superiori diretti - centralizzazione di risorse simili - Buon coordinamento e comunicazione all'interno del team - elevata autorità del project manager - Ottimizzazione delle risorse - Scarso coordinamento nell'ambito del progetto, - scarso coinvolgimento delle risorse (il progetto transita in più aree) - Poco efficiente utilizzo delle risorse - Conflitti tra project manager e Functional manager G.Raiss - 3 maggio

41 PdP Organizzazione - Team Tipologie di team Democratico Centralizzato Assenza di leader permanente Consenso di gruppo sulle soluzioni e sulla organizzazione del lavoro Comunicazione orizzontale Controllato Decentralizzato Un leader riconosciuto che coordina il lavoro La risoluzione dei problemi è di gruppo, ma i lavori sono poi assegnati dal leader a sottogruppi G.Raiss - 3 maggio PdP Organizzazione - Team Controllato Decentralizzato (segue) Comunicazione orizzontale tra sottogruppi e verticale con il leader Controllato Centralizzato il leader decide sulle soluzioni e sulla organizzazione del lavoro Comunicazione solo verticale tra team leader e gli altri membri dello staff G.Raiss - 3 maggio PdP Organizzazione - Team Tipo Team Contesto Difficoltà Alta Bassa Dimensione problema Grande piccola Modularità Alta bassa Affidabilità Alta bassa Coesione Team Alta bassa Scadenza Stretta lasca DD X X X X X X CD X X X X X X CC X X X X X X G.Raiss - 3 maggio

42 PdP Analisi dei rischi Passi della analisi Individuazione dei fattori di rischio Definizione delle conseguenze dell avverarsi di questi fattori sull andamento del progetto Si calcola la probabilità che il rischio si avveri Si ordinano i rischi per probabilità di avverarsi e per conseguenze Si predispongono le contromisure per mitigare i rischi più rilevanti G.Raiss - 3 maggio Fattori di rischio Va predisposto un catalogo dei principali fattori di rischio Due principali famiglie Rischi connessi alla complessità Rischi connessi alla incertezza G.Raiss - 3 maggio Fattori di rischio - complessità Rischi legati alla complessità rilevanza e criticità del progetto interconnessione con altri progetti eterogeneità degli attori profondità delle modifiche che il progetto apporta ad organizzazioni, ruoli, procedure dimensione del contesto (applicazioni, dati, utenti, apparecchiature) durata del progetto, impegno richiesto volume di prodotto da sviluppare implicazioni legali e normative G.Raiss - 3 maggio

43 Fattori di rischio - incertezza Rischi legati alla incertezza (1) Incertezza del contesto budget inadeguato grado di stabilità dell ambiente e dei processi interconnessione con altri progetti disponibilità, chiarezza e stabilità dei requisiti esperienza, disponibilità e partecipazione delle risorse del cliente G.Raiss - 3 maggio Fattori di rischio - incertezza Rischi legati alla incertezza (2) Incertezza sulle risorse e competenze disponibilità e caratteristiche risorse umane competenza nel dominio applicativo e tecnico utilizzo di nuove tecnologie utilizzo di nuove metodologie e linguaggi necessità di integrazione di tecnologie e metodologie/tecniche eterogenee approvvigionamenti/sub forniture G.Raiss - 3 maggio PdP Analisi dei rischi - Staff Esempio: Rischi sullo staff Gli sviluppatori sono esperti a sufficienza? Hanno le competenze tecniche adatte? Lo staff è disponibile per tutta la durata del progetto? Lavorano tutti a tempo pieno su questo progetto?.. G.Raiss - 3 maggio