Piano di progetto È un documento versionato, redatto dal project manager per poter stimare realisticamente le risorse, i costi e i tempi necessari alla realizzazione del progetto. Il piano di progetto si divide in due parti, pianificazione e consuntivazione, per rendere possibile la pianificazione delle attività future e il riscontro tangibile tra le attività effettuate e quelle previste. Il piano di progetto è un documento che varia nel tempo a seconda delle situazioni e dell evolversi delle attività portate avanti dai membri. Una parte del documento, il diario delle modifiche, tiene traccia delle variazioni apportate al piano, registrando la data delle modifiche e la versione del piano. Il piano del progetto contiene la descrizione delle attività pianificate 1. Definizione degli obiettivi 2. Analisi dei rischi (piano gestione rischi, sintesi rischi individuati e strategie di prevenzione) 3. Descrizione del modello di processo di sviluppo Descrizione fasi (milestones) del processo 4. Stima dei costi 5. Attività di progetto (Work Breakdown Structure, Diagramma di Gantt) 6. Consuntivo attività 7. Strumenti utilizzati La documentazione inerente il controllo del progetto prevede almeno (1) una tabella nella quale per ogni attività si evincano i partecipanti con i rispettivi monte ore, (2) una tabella nella quale per ogni membro del gruppo si evincano le attività a cui egli ha preso parte ed il totale numero di ore di lavoro.
Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali di rischio in un ambiente di sviluppo del software
Rischi 2 All interno del processo di sviluppo del software ci sono molte aree di rischio Gli ingegneri software devono sviluppare dei modi e dei mezzi per assicurare che una possibile occorrenza di un evento indesiderato possa essere determinata presto In questo modo sarà possibile applicare un piano correttivo per evitare conseguenze disastrose senza che ciò abbia un forte impatto sui costi
Rischi 3 Un rischio nello sviluppo del software può essere definito in termini generali come la probabilità che un evento dannoso per il processo di sviluppo del software possa occorrere Il rischio viene misurato come l effetto combinato della probabilità che l evento indesiderato occorra e la possibilità che una particolare conseguenza quantificata, misurata o accertata possa scaturire dall occorrere dell evento indesiderato
Gestione del rischio Identificare le aree di rischio Quantificare il rischio Sviluppare dei modi per predire l occorrenza di eventi indesiderati (attraverso delle misure) Controllare le misurazioni più volte durante lo sviluppo del progetto Pianificare azioni alternative o correttive nel caso occorra qualche evento indesiderato
Perché fare l analisi dei rischi? La gestione senior la chiede frequentemente Anche se il rischio associato al processo di sviluppo del software è stato accettato, non si vuole arrivare impreparati nel caso in cui l evento indesiderato si presenti Eseguendo l analisi dei rischi è possibile avvertire la gestione riguardo a zone di possibile difficoltà relativamente presto Nel processo di sviluppo del software l analisi del rischio e lo sviluppo di un piano di contenimento è spesso respnsabilità dell ingegnere del software
Alcune aree di rischio per lo sviluppo software 1 1. Insufficienza di personale Gestione: assunzione di personale adeguato, subappalto,... 2. Pianificazione e budget non realistico Gestione: stima dettagliata dei costi e del programma, modello di sviluppo incrementale, riuso del software, rinegoziazione con il cliente, 3. Sviluppo delle funzioni software sbagliate Gestione: sondaggi degli utenti, costruzione prototipi, sviluppo di un primo manuale utente, sviluppo di e accordo su dei criteri di accettazione,.. 4. Sviluppo dell Interfaccia utente sbagliata Gestione: costruzione prototipo, analisi casi d uso,..
Alcune aree di rischio per lo sviluppo software 2 5. Instabilità dei requisiti Gestione: information hiding, modello di sviluppo incrementale e rinvio dei cambiamenti a un incremento successivo, controllo stretto dei cambiamenti, accordo su dei criteri di accettazione,.. 6. Inadeguatezza delle componenti fornite Gestione: benchmarking, analisi di compatibilità, test di accettazione, 7. Gold Plating Gestione: scrubbing dei requisiti, analisi costi benefici, 8. Inadeguatezza dei compiti forniti dall esterno Gestione: prototipizzazione o design competitivo, costruzione di un team,.. 9. Performance requisiti real-time inadeguati Gestione: simulazione, benchmarking, modellazione, prototipizzazione, analisi della messa a punto della strumentazione 10. Difficoltà nell uso di tecnologie complesse Gestione: analisi tecnica, analisi costi benefici, analisi della performance, analisi delle dimensioni
Instabilità dei requisiti Se l analista riconosce che questo è potenzialmente un rischio alto nello sviluppo del software, esaminerà i requisiti funzionali e non funzionali per vedere se: 1. Ci sono requisiti non ancora specificati 2. La definizione dell interfaccia è inadeguata 3. I requisiti sono dichiarati in maniera vaga e inconsistente 4. Si fa poco uso del linguaggio di specifica 5. C è poca documentazione e di cattiva qualità 6. C è una definizione inadeguata dei bisogni e dei desideri del cliente
Un modello per il rischio I rischi possono essere modellati come l interazione di due variabili: PF: probabilità di fallimento CF: conseguenze del fallimento FATTORE DI RISCHIO RF = PF + CF PF*CF
Approccio generale all analisi dei rischi Identificare aree di potenziale rischio Suddividere ogni area di rischio in fattori critici Esaminare le conseguenze di un fallimento
Tre fattori che riguardano il rischio sui requisiti Valore Qualità della specifica Controllo dei cambiamenti Concorrenza del cliente 0.1 Sono necessarie poche correzioni Forte disciplina E d accordo con il criterio di accettazione 0.3 0.5 Alcuni problemi nella spec. richiedono un certo lavoro per essere risolte.i problemi vengono risolti. Il Piano non viene toccato Restano problemi rilevanti. Qualche attività non terminata per risolvere problemi gravi Il controllo è a posto. Tendenza ad una disciplina rilassata L attività di cambiamento non segue procedure formali stabilite Comprende il bisogno di stabilire dei criteri di accettazione. Gli operatori introducono nuovi requisiti 0.7 0.9 Ci sono problemi gravi nella spec. Risorse insufficienti per occuparsi dei problemi e risolverli Problemi gravi nella spec. Nessun piano di soluzione Le procedure informali non funzionano bene (quelle formali vengono ignorate) Non c è un processo di controllo formale Gli operatori non si preoccupano del costo e dello schedule Il cliente non vuole controllare richieste di cambio operatore/utente
Risultato atteso per ciascuno di questi fattori probabilità di fallimento Facendo la media: PF = (somma dei valori assegnati a ciascun fattore)/(numero dei fattori) Pesando ogni fattore PF = (0.5 * valore fattore 1) + (0.3 * valore fattore 2) + + (0.2 * valore fattore 3) Arrivare a un valore per ogni fattore richiede una analisi completa del fattore e una solida base di esperienza
Fattori correlati alle conseguenze di fallimento (rischio requisiti) Valore Costo Schedule Performance 0.1 Nel budget Nel piano Conseguenze minime, gestibile 0.3 Incremento dell 1-5% Slittamento minimo: 1 mese Piccola riduzione nel prodotto, performance e funzione 0.5 Incremento del 5-20% Slittamento di 1-3 mesi Qualche riduzione nel prodotto, performance e funzione 0.7 Incremento del 20-40% Slittamento maggiore di 3 mesi Significativa riduzione nel prodotto, performance e funzione 0.9 Incremento maggiore del 40% Slittamento maggiore di 6 mesi Il prodotto è inutilizzabile e rigettato dal cliente
Risultato atteso per ciascuno di questi fattori conseguenze del fallimento Facendo la media CF = (somma dei valori per le conseguenze dei fattori di fallimento)/(numero dei fattori) Pesando ogni fattore CF = (0.6 * valore fattore costo) + (0.2 * valore fattore schedule) + + (0.2 * valore fattore performance) Anche in questo caso l assegnamento dei pesi è altamente soggettivo e deve essere analizzato attentamente
Valutazioni I valori di PF e CF vengono utilizzati per stabilire la gravità del rischio Valori più piccoli di 0.3 sono considerati minimali (rischio minimale) Valori fra 0.3 e 0.7 sono considerati moderati (rischio moderato) Valori superiori a 0.7 sono considerati valori di rischio alto
Critica all approccio Metodo altamente soggettivo per analizzare e quantificare i rischi SOLUZIONE: Fare sondaggi fra persone esperte e fare una media delle loro risposte produrrà una quantificazione del rischio più obiettiva
Come gestire un rischio? Evitarlo Prevenirlo (controllo) Assunzione (riconoscere un rischio e accettarne le conseguenze) Trasferimento Conoscenza attraverso la ricerca
Misurazioni di performance tecnica TPM: Misurazione continuativa di un attributo quantificabile del prodotto software 1. Fornire una misura del valore attuale di un attributo rispetto a quello pianificato 2. Fornire un rilevamento prematuro di problemi che richiedono attenzione tecnica o amministrativa 3. Fare da indicatore dell effetto dei cambiamenti nei prodotti software
Alcune tipiche TPM Utilizzo di memoria e CPU Capacità di I/O Affidabilità/disponibilità/manutenibilità Tempo di risposta Costo e schedule Completamento dei casi di test
Esempio rischi della specifica dei requisiti Il capo di Ray Luciani, Fred Shepherd, chiama Ray a rapporto per discutere un problema. Fred ha saputo che la specifica dei requisiti di un prodotto critico non è adeguata. Pare che: 1. Ci siano troppi requisiti TBD, 2. La qualità globale della specifica è povera, e si è progredito poco per rispondere alle deficienze della documentazione 3. Molti dei requisiti di interfaccia sono vaghi ed incompleti 4. Alcuni requisiti funzionali e non sono parte di un lite fra il cliente e l organizzazione 5. Il cliente si lamenta che gli ingegneri del software non hanno capito molte cose riguardo all area di applicazione e come gli operatori lavoravano Molti, nella comunità di sviluppo del software pensavano che la specifica si sarebbe dovuta rifare e ridistribuire con un conseguente slittamento nello schedule del software
Esempio rischi della specifica dei requisiti Ray individuò cinque fattori di rischio specifici che, riteneva, si sarebbero direttamente associati con l occorrenza dell evento indesiderato: Che la specifica dei requisiti software avrebbe fallito di compiere la sua ragione d essere, quella cioè di definire accuratamente e completamente i requisiti funzionali e non del software da sviluppare. Un fallimento nella specifica porterebbe sicuramente delle gravi perdite in termini di costi, di piano del lavoro, di performance del prodotto
Esempio rischi della specifica dei requisiti Le cinque aree sono: 1. La chiusura dei requisiti TBD (completamento della definizione dei requisiti) 2. Considerate le preoccupazioni degli operatori 3. Dettagli migliorati (specialmente quelli di input/output) 4. Qualità del documento migliorata 5. Risoluzione dei problemi nel contratto riguardanti i requisiti Ray stabilisce che a meno che queste 5 aree non vengano migliorate significativamente, saranno inevitabili notevoli conseguenze negative
Esempio rischi della specifica dei requisiti Conseguenze negative specifiche associate a questi fattori includono 1. Inizio tardivo del design del software 2. Alto livello di cambiamento nelle attività 3. Cambiamenti tardivi ai requisiti (nel processo di sviluppo sw) 4. Compromessi nelle funzionalità e performance del prodotto
Esempio rischi della specifica dei requisiti Per ciascuno di queste componenti di rischio Ray ha costruito, con l aiuto dei colleghi, un range di possibili occorrenze Situazione best-case: Tutti i TBD vengono chiusi in modo soddisfacente in un mese Il problema operatore viene sistemato presto La specifica viene rivista e redistribuita con un miglioramento sostanziale in dettaglio e qualità I problemi riguardanti il contratto vengono risolti con successo Situazione worst-case: Non si fa nulla, ci si disinteressa dei fattori critici evidenziati
Esempio rischi della specifica dei requisiti Successivamente Ray passa a stimare la probabilità di fallimento associata a ciascuno dei possibili risultati Esempio: Se tutti i TBD vengono chiusi in un mese, gli operatori soddisfatti, la qualità della specifica migliorata, il problema del contratto risolto, la probabilità di fallimento nello sviluppo (in termini di costo, schedule e performance) è approssimativamente 0.1 Se non viene fatta nessuna azione, la probabilità di fallimento è 0.9 Ora si tratta di riempire il resto del modello. Ray dovrà stimare l occorrenza più probabile o più attesa per ogni fattore
Esempio rischi della specifica dei requisiti Il primo fattore di rischio di cui Ray si occupa è quello dei TBD non risolti 1. Accertamento del grado di interesse e impegno del manager di chiudere i TBD (ottiene la lista intera dei TBD) 2. Revisiona questa informazione con il team di sviluppo 3. Considerata la serietà e la reputazione delle persone con cui ha parlato, la natura dei problemi tecnici, il grado di impegno pensa che ci sono buone probabilità che i TBD vengano chiusi in tempo (cioè che vengano inclusi nella corrente fase di design)
Esempio rischi della specifica dei requisiti Evento Tutti i TBD vengono chiusi in un mese 75% dei TBD vengono chiusi in 6 settimane Metà dei TBD vengono chiusi in 3 mesi 25% dei TBD vengono chiusi in 4 mesi Solo pochi TBD vengono in modo soddisfacente in 6-9 mesi Probabilità di fallimento 0.1 0.3 0.5 0.7 0.9
Esempio rischi della specifica dei requisiti Che probabilità di fallimento associare a questo fattore? Malgrado le garanzie e promesse fatte dal manager e malgrado il grado di impegno, Ray percepisce che più probabilmente solo il 75% si sarebbe completato in un mese, un mese e mezzo. A causa di questa conclusione assegna al fattore probabilità di fallimento 0.3 I TBD sono troppi, nello schedule non c è margine di errore, ogni TBD dovrà essere rigorosamente risolto in tempo Nello schedule c è poco tempo per la revisione
Esempio rischi della specifica dei requisiti PF ChiusuraTBD Operatori soddisfatti Dettagli migliorati Qualità migliorata Problema contratto 0.1 Tutti in un mese In gran parte soddisfatti Redistribuzione specifica Sì Sì 0.3 ¾ in 1.5 mesi ¾ soddisfatti Miglioramento significativo 75% 75% 0.5 ½ in 3 mesi ½ soddisfatti Qualche miglioramento 50% 50% 0.7 ¼ in 4 mesi ¼ soddisfatti Piccoli cambiamenti 25% 25% 0.9 Pochi in 6-9 mesi Ancora scontenti Nessun cambiamento No No
Esempio rischi della specifica dei requisiti CF Costo Schedule Performance 0.1 Impatto minimo Minimo Preoccupazione minima 0.3 Incremento del 5% Slittamento di 1 mese Piccola riduzione nella performance 0.5 Incremento del 10% Slittamento di 1-3 mese Qualche riduzione nella performance 0.7 Incremento del 25% Slittamento di 3 mesi Riduzione significativa nella performance 0.9 Incremento del 50% Slittamento di più di 3 mesi Performance insoddisfacente
Esempio rischi della specifica dei requisiti Ray stima che PF = (0.3 + 0.5 + 0.3 + 0.5 + 0.1)/ 5 = 0.34 CF = (0.5 + 0.7 + 0.3)/3 = 0.5 RF = PF + CF (PF * CF) = 0.34 + 0.50 (0.34 * 0.50) = 0.67 Un fattore di rischio di 0.67 è moderato, ma vicino al limite 0.7, e sebbene accettabile, non può essere ignorato
Esempio rischi della specifica dei requisiti Lista di alcune idee per il piano di contenimento 1. Assegnare alcuni degli migliori ingegneri del software esperti in quell area per assistere gli ingegneri del team nel chiudere i TBD 2. Coinvolgere operatori di esperienza nel lavoro di design 3. Incoraggiare il manager a redistribuire la specifica 4. Rendere noto al cliente del problema potenziale e che cosa si sta facendo per correggere la situazione 5. Negoziare un cambiamento dello schedule 6. Dividere la specifica in due moduli separati e produrli sequenzialmente