+ Che cosa è un progetto ?

+

Project Management

Una introduzione critica di Pierfrancesco Ghedini

+ …

“Tutto è finalizzato alla vittoria, perché è l’unica cosa che conti in caso di guerra, e vince veramente solo chi sappia imporsi ottenendo il massimo profitto nel minor tempo possibile (possibilmente senza combattere) e col minimo delle perdite. Un tale obiettivo si può raggiungere con una meticolosa valutazione iniziale atta ad evitare le situazioni potenzialmente svantaggiose…”

Dalla introduzione a SUN TZU, “L’arte della guerra”, Economici Newton

+ Lo spirito del Project Management

! L’essenza del Project Management – nel seguito abbreviato in PM – è portare a termine gli obiettivi assegnati nel rispetto dei tempi convenuti, del budget stabilito e nel rispetto dei criteri di qualità necessari

! Un progetto, se accettato, deve essere portato a termine non è contemplata la possibilità di non raggiungere l’obiettivo

! Se esistono vincoli ostativi che precludano il raggiungimento dell’obiettivo di progetto, questi devono essere messi in luce prima della accettazione

! L’accettazione di un progetto implica la sua realizzabilità, nei tempi, nei costi convenuti ed entro i limiti di qualità stabiliti

+ Che cosa è un progetto ?

! Un progetto è una attività che ha un inizio e una fine ed è svolta per conseguire obiettivi stabiliti e definiti, nel rispetto di vincoli di tempo, di costo e nel rispetto di regole

qualitative

! Un progetto per poter essere portato termine necessità di risorse: capacità, talenti, attrezzature, strumenti ed

equipaggiamento, informazioni, sistemi e tecniche, denaro, ecc…

! La gestione di un progetto differisce dalle altre attività manageriali che normalmente hanno carattere ripetitivo essendo legate alla continuità dell’attività aziendale

+ Il ciclo di vita di un progetto

!  Schematicamente si delinea il ciclo di vita di un progetto nel seguente modo:

!  Concepimento e definizione del progetto;

!  Programmazione del progetto;

!  Realizzazione;

!  Completamento e valutazione

!  Trasversale ad ogni fase del progetto è l’azione costante di informazione degli stakeholders e degli attori del progetto

!  Lo schema lineare che va dal concepimento al completamento è una schematizzazione ideale del percorso di progetto che in alcuni ambiti – soprattutto la progettazione software – appare troppo schematica e irrealistica. A modelli cosiddetti a cascata – quale quello sopra delineato – si associano modelli cosiddetti iterativi che prevedono più cicli di programmazione/

realizzazione/valutazione per giungere al risultato finale.

+ Le metriche di un progetto

!  Le metriche in base alle quali misurare i risultati ottenuti da un progetto sono essenzialmente tre:

!  Qualità;

!  Costo;

!  Tempo.

!  La qualità indica l’insieme di caratteristiche minime che deve possedere quanto prodotto per soddisfare i bisogni del cliente;

!  Il costo indica la quantità di risorse impiegate per il raggiungimento degli obiettivi di progetto;

!  Il tempo è la misura del tempo intercorso fra l’inizio del progetto e il suo completamento.

+ La contrattazione iniziale dei tre parametri fondamentali, il

controllo e la ricontrattazione

!  L’essenza del PM consiste nel:

!  Definire un accordo di progetto con la committenza che stabilisca in maniera chiara i vincoli di qualità, costo e tempo;

!  Monitorare il progetto per verificare costantemente il rispetto dei vincoli di qualità, costo e tempo;

!  Eventualmente ricontrattare con la committenza vincoli di qualità, costo e tempo con la committenza.

!  L’insieme iniziale di vincoli di progetto vengono cristallizzati nella cosiddetta “baseline” sulla quale vengono basate le azioni di monitoraggio

!  La baseline viene eventualmente ricontrattata in corso di progetto se essa si dimostra non rispettabile.

+ Il Project Manager

Le principali abilità che il Project Manager deve esercitare sono:

!  Essere un leader: il PM deve catalizzare l’impegno di tutti verso il raggiungimento degli obiettivi, coordinando, stimolando, trainando …

!  Capacità di contribuire: il PM deve contribuire alla soluzione dei problemi e deve mettere in comune con tutto il team la propria esperienza e la propria competenza tecnica

!  Capacità di ascoltare: il PM deve ascoltare e cercare di capire il punto di vista di ognuno, il problema di qualcuno, può diventare un problema del progetto su cui il PM deve intervenire

!  Capacità di integrare i diversi punti di vista: il PM deve integrare il punto di vista puntuale dei singoli con la visione generale di progetto

+ Esercitazione 1 1/2

! A Mr. Smith, dirigente dell’azienda ACME operante nel settore delle attrezzature per la trivellazione petrolifera, viene proposto di dirigere un nuovo progetto per lo sviluppo di una innovativa piattaforma offshore che dovrebbe

proiettare la ditta nell’empireo di questo settore se avrà successo

! Mr. Smith accetta con entusiasmo e si trasferisce nella sede dove si sta sviluppando il progetto

! Mr. Smith pochissimo tempo dopo aver preso le redini del progetto, capisce che si tratta di un progetto velleitario, privo di un reale fondamento scientifico e privo delle risorse

necessarie per poter realmente riuscire

+ Esercitazione 1 2/2

!  Mr. Smith, come Pm del progetto, compila una dettagliata

relazione nella quale descrive, con dovizia di particolari perché il progetto non ha speranze di riuscire

!  Al ricevimento della relazione i vertici della ditta ACME convocano Mr. Smith per discutere del rapporto

!  Al termine della concitata riunione i vertici della ditta ACME convengono che il progetto non ha speranze di riuscita, tagliano i finanziamenti, stoppano le attività e come ultimo atto

licenziamo Mr. Smith

!  Per gruppi: discutere il caso proposto e mettere in luce eventuali problemi e limiti del comportamento di Mr. Smith e dei vertici della ditta ACME

Concepire e definire il progetto

Sunzi Disse:

Il meglio del meglio non è vincere cento battaglie su cento, ma bensì sottomettere il nemico senza

combattere.

Sun Tzu, “L’arte della guerra”, Economici Newton

+ L’origine dei progetti

! Le principali ragioni che portano al varo di un nuovo progetto sono da ricercarsi nella necessità di risolvere problemi o dall’esigenza di cogliere opportunità

! Un progetto nasce sempre dall’entusiasmo e dalla voglia di fare di qualcuno, questa spinta propulsiva va incanalata in una rigorosa analisi che porti ad una valutazione dei vincoli di fattibilità del progetto e dei rischi insiti nella attuazione dello stesso

! Le posizioni personali e le opinioni in merito al progetto vanno supportate da fatti ed analisi che tendano a

confermare l’opportunità di perseguire il progetto

+ Le fasi di avvio del progetto

Schematicamente il percorso di formulazione di un progetto può essere così delineato:

!  Individuare gli stakeholders del progetto e con questi studiare, discutere e analizzare l’idea iniziale di progetto

!  Scrivere una prima traccia del progetto

!  Delineare le principali finalità e i principali obiettivi

!  Elencare i vincoli e le principali possibili criticità

!  Valutare strategie alternative

!  Definire una modalità di azione

+ Chi sono gli stakeholders del progetto

!  Gli stakeholders del progetto sono i “portatori di interesse” cioè coloro che trarranno beneficio dal fatto che il progetto riesca

!  Il concetto di “portatore di interesse” può essere più ampio del committente di progetto, infatti se da un lato il committente è certamente un portatore di interesse, un portatore di interesse può essere colui che può beneficiare dalla riuscita del progetto, ma non avere la possibilità di commissionare un progetto

!  In ogni caso tutti i portatori di interesse hanno un duplice ruolo:

possono determinare vincoli e caratteristiche di qualità, ma possono anche essere i motori che spingono verso al riuscita del progetto

+ Gli strumenti a disposizione per l’analisi iniziale

! La fase iniziale di un progetto è una fase creativa in cui è necessario – a fronte di obiettivi che si vanno definendo e a fronte di vincoli e rischi che cominciano ad emergere – delineare un macro piano di azione

! È indispensabile, in questa prima analisi, essere aperti a tutti i contributi ed analizzare ogni possibile alternativa, viene pertanto spesso consigliato lo strumento del BrainStorming come tecnica che il gruppo di lavoro potrà utilizzare per raccogliere una serie di spunti da vagliare per definire l’ipotesi di strategia iniziale

+ Il Brainstorming

! Elencare tutte le idee proposte dai membri del gruppo

! Non valutare, né giudicare le idee proposte, non preoccuparsi eccessivamente di eventuali doppioni

! Incoraggiare la quantità, tante più idee vengono proposte quanto più sarà probabile che fra queste ve ne sia una buona

! Non essere ansiosi di chiudere il processo di raccolta

+ Output della fase di ideazione del progetto

L’output della fase di ideazione del progetto è una “proposta di progetto” che deve avere le seguenti caratteristiche:

!  Deve avere un nome e una proposta di Project Manager

!  Deve elencare gli obiettivi del progetto e sinteticamente descrivere problemi, ostacoli, rischi e opportunità

!  Deve riportare una analisi costo beneficio (benefici tangibili, benefici intangibili, costi, ricavi)

!  Deve descrivere sinteticamente l’ambito in cui si collocherà il progetto

!  Deve proporre una macro schedulazione delle tempestiche La proposta di progetto deve essere approvata dagli stakeholders

Programmazione del progetto

+ Programmazione del progetto

La programmazione del progetto consiste nel pianificare ciò che è necessario a garantire il rispetto dei vincoli di tempo, di costo e di qualità. Per garantire ciò è necessario:

!  Dettagliare gli obiettivi di progetto;

!  Definire le strategie per giungere all’obiettivo;

!  Scomporre il progetto in sub-unità e fasi;

!  Determinare la sequenza di sub unità e fasi, i vincoli, i tempi;

!  Determinare i costi di ogni sub unità e fase e indicarli nel budget di progetto;

!  Determinare le caratteristiche di qualità di ogni singola sub unità e fase e indicarli nel documento della qualità;

!  Progettare l’allocazione delle risorse su ogni singola sub unità o fase;

!  Progettare l’eventuale formazione del team;

!  Definire le politiche e le procedure da adottare.

+ Struttura di analisi del lavoro

!  Una tipica tecnica per affrontare compiti complessi è quella che consiste nel dividere il problema in sub-unità o pacchetti di lavoro

!  Nel Project Management questa tecnica prende il nome di WBS – Work Breakdown Structure –

!  Al fine di mantenere il controllo del progetto è bene procedere a suddividere le unità di lavoro in sottounità via via più

dettagliate procedendo per gradi e secondo necessità, un

progetto con un numero minore di sotto unità è preferibile ad un progetto eccessivamente dettagliato in cui la suddivisione in sotto unità non risponda ad esigenze di propedeuticità di attività, ad una migliore mappatura delle risorse o di individuazione di costi o di vincoli di qualità

+ Il progetto “Torta al cioccolato”

+ Perché strutturare il progetto in questo modo ? 1/2

!  Si individuano due macro attività: la preparazione della pasta e la preparazione della glassa di copertura;

!  Perché ? Perché nel nostro laboratorio di pasticceria si alternano due persone una delle quali si occupa della pasta e una delle glassature

!  La macro attività di preparazione della pasta è suddivisa nelle sotto attività di preparazione della base, di preparazione della farcia, di riposo della pasta in abbattitore di temperature e di assemblaggio del tutto per dare conto delle diverse

propedeuticità fra le varie azioni

!  Viene definito un “milestone” che corrisponde alla produzione di un output della prima macro attività che corrisponde ad un input per la seconda macro attività

+ Perché strutturare il progetto in questo modo ? 2/2

! La seconda macro attività, la glassatura e decorazione viene strettamente subordinata al completamento della base

! Ciò crea una diseconomia nell’ottica del completamento tempestivo del progetto: sarebbe stato possibile suddividere l’attività “Preparare la glassa di copertura al cioccolato e glassare la base” in due sotto unità del tipo “Preparare la glassa di copertura al cioccolato” e “Glassare la base”, di cui la prima avrebbe potuto essere anticipata rispetto al

completamento della base

+ Il pert

! Il diagramma PERT permette di modellare i vincoli di propedeuticità fra le varie attività

! Nella sua forma più semplice ogni nodo rappresenta una attività e ogni arco un vincolo di propedeuticità

! In ogni nodo è indicato nome dell’attività e durata

Att.1 4 g.

Att.2 3 g.

Att.3 1 g.

Att.4 6 g.

+ Un modello matematico per la valutazione della durata delle attività

!  Per valutare la durata di una attività si può usare uno strumento matematico – distribuzione beta –

!  Utilizzando il tempo più probabile Tm, il tempo più ottimistico To, il tempo pessimistico Tp, il tempo si può stimare con Tv = (To + 4Tm + Tp)/6

!  La deviazione standard si calcola con (Tp- To)/6

!  L’attività sarà completata il 68,26% delle volte entro il range Tv + o – la deviazione standard

!  L’attività sarà completata il 95,44% delle volte entro il range Tv + o – 2 volte la deviazione standard

+ Diagramma di Gantt

! Un diagramma di Gantt è un grafico a barre orizzontali che evidenzia le relazioni temporali delle fasi di un progetto

! È lo strumento principe per la programmazione della dimensione tempo di un progetto

!  Un diagramma di Gantt addizionato di vincoli di

propedeuticità fra le attività è lo strumento più espressivo che si possa usare per gestire il tempo di un progetto

! Costruire un diagramma di Gantt significa determinare per ogni attività la durata, la data di inizio e/o i vincoli di

propedeuticità che legano l’attività alle altre

+ Costruire diagrammi di Gantt

! Il diagramma di Gantt può essere costruito con un semplice foglio di calcolo

! Se si vogliono gestire vincoli fra attività è comunque utile usare gli appositi edito grafici, alcuni dei quali disponibili gratuitamente

+ I quattro tipi di legame fra le attività

I cosiddetti vincoli di propedeuticità servono a rappresentare i vincoli che intercorrono fra una attività e l’altra, sono

essenzialmente di quattro tipi:

!  Fine/Inizio: di gran lunga quello più frequente ed utile serve ad indicare che una attività non può iniziare prima di un’altra

!  Fine/Fine: che indica che due attività devono concludersi insieme

!  Inizio/inizio: che indica che due attività devono iniziare in contemporanea

!  Inizio/Fine: che riproduce il primo tipo di vincolo, ma permette la scrittura specificando in ordine inverso le attività

(sostanzialmente inutile)

+ La definizione dei milestones

!  La fase di programmazione del progetto permette la

progettazione dell’insieme delle attività che andranno svolte per giungere al completo raggiungimento degli obiettivi previsti

!  Consiste anche nella progettazione dei presupposti per il controllo di progetto

!  Una delle tecniche di controllo di progetto è quella basata sulle pietre miliari o milestones

!  Così come le pietre miliari al bordo delle strade consolari romane identificavano quanta strada era stata compiuta, così le pietre miliari di un progetto devono aiutare o monitorare lo stato di avanzamento

+ La natura dei milestones

!  Un progetto, per sua natura, è una sequenza continua di azioni che portano al raggiungimento di una serie di obiettivi

!  Stante ciò, può essere difficile “in corsa” misurare lo stato di avanzamento

!  Si definiscono quindi, già dalla fase di progettazione, dei “punti fermi” che consentano di misurare con maggiore facilità e oggettività i risultati effettivamente conseguiti

!  I milestones è auspicabile coincidano con la produzione di un qualche risultato concreto intermedio del progetto, ad esempio possono coincidere con la stesura finale di un documento – la conclusione dell’analisi di progetto validata dal committente, ecc… -, o con la produzione di un semilavorato…

+ La WBS e i milestones

! I milestones pur non essendo attività del progetto, ma prodotti delle attività di progetto, vengono normalmente inseriti nella WBS

! Ciò consente una loro agevole collocazione nel tempo e permette di specificarne le diverse propedeuticità

! Nel nostro progetto di confezionamento di torta al cioccolato il milestone “inizio attività di copertura” prevede che la base della torta sia stata completata e raffreddata

+ Altri usi dei Milestones

! I vincoli esterni al progetto possono essere sintetizzati nei milestones che diventano quindi punti di verifica della compatibilità fra i vincoli esterni al progetto e lo stato di avanzamento delle attività interne.

+ Gestire la dimensione costo

Al fine di determinare il costo del progetto è normalmente necessario definire:

! Il costo del lavoro e gli oneri riflessi relativi

! Il costo dei materiali impiegati e delle forniture necessarie

! Il costo di affitto delle attrezzature, dei locali e in generale gli oneri relativi alle locazioni e ai noleggi

! Le spese generali e amministrative

! Il profitto d’impresa

+ Gestire le risorse

! Per ogni sotto unità o fase di progetto è necessario definire le risorse necessarie

! Attraverso l’articolazione nel tempo delle attività è possibile verificare se vi siano problemi, ad esempio nell’impiego massimo contemporaneo di risorse critiche, nell’impiego eccessivo di risorse particolarmente costose durante tutta la durata del progetto

! Alcuni strumenti informatizzati di gestione della WBS permettono anche la gestione delle risorse e facilitano le verifiche sopra accennate

+ La gestione della risorsa lavoro

+ Assegnazione delle responsabilità

! Una volta definite le attività e assegnate le risorse alle diverse attività, occorre assegnare le responsabilità delle varie componenti progettuali

! Non necessariamente le risorse a cui è assegnata una sub- unità coincidono con le figure alle quali viene assegnata la responsabilità di una sub-unità o di una fase di progetto

! Per questa ragione e anche per ragioni di chiarezza comunicativa, si è soliti definire le responsabilità di un progetto con una matrice di di responsabilità che è solitamente un documento distinto dal documento di assegnazione delle risorse alle diverse sub-unità

+ La matrice delle responsabilità

Progetto ____________________

Attività Budget Termini Responsabilità

+ Esercitazione 2

! Definire una WBS rappresentante le principali attività che è necessario mettere in campo, da parte di una grande catena di articoli per ferramenta, per allestire un sito per la vendita On Line degli articoli commercializzati

! Ci si suddivida in due gruppi e in mezz’ora di tempo si faccia una proposta di WBS.

La definizione, il dimensionamento

e la gestione del Team di progetto

Sunzi Disse:

Reggere una moltitudine è come reggere un gruppo sparuto: una questione di suddivisioni.

Sun Tzu, “L’arte della guerra”, Economici Newton

+ La definizione del Team di progetto

!  Ogni progetto, si di dimensioni non minimali, per poter essere portato a termine, necessita di un gruppo articolato di persone che devono lavorare in gruppo

!  La definizione di un Team di progetto adeguato è spesso il primo e più importante compito affidato al progettista: senza un efficace gruppo a supporto nessun Project Manager, per quanto capace e dotato di esperienza, è in grado di portare a termine il lavoro

!  Il Team di progetto, quando le dimensioni della realizzazione siano rilevanti, varia nel tempo seguendo il ciclo di vita del progetto: quindi è plausibile che prima il team sia

prevalentemente formato da progettisti, poi da tecnici preposti alla realizzazione, ecc…

+ Il dimensionamento del Team di progetto

+ La gestione del Team di progetto

! Una corretta gestione del Team è un fattore chiave per la riuscita dell’intero progetto

! Occorre prevenire personalismi e occorre evitare che visioni eccessivamente personali confliggano con lo “spirito del progetto”

! Il Project manager attraverso la relazione personale con tutti i componenti del Team deve fare prevalere le logiche del progetto sopra le logiche personalistiche

+ Gestire la qualità

! Uno dei tre pilastri del PM, assieme alla gestione dei tempi e dei costi è la gestione della qualità

! Gestire la qualità significa, per ogni sotto unità o fase del progetto e per il progetto nella sua complessità, specificare requisiti minimi (e spesso anche massimi o opportuni) di qualità

! La qualità del prodotto può essere ottenuta in diversi modi, attraverso la garanzia di qualità dei materiali componenti, attraverso la garanzia di corretta applicazioni di protocolli e procedure realizzative, attraverso la sistematica messa in atto della verifica dei parametri qualitativi, ecc…

+ Il manuale della qualità del progetto come documento trasversale al progetto

! La definizione delle caratteristiche di qualità di quanto prodotto dal progetto e la gestione delle pratiche tese a garantire la qualità durante tutte le fasi del progetto, prendono spesso la forma di un manuale della qualità

! Il manuale della qualità è un documento prezioso anche per le fasi successive alla fine del progetto, quando i prodotti sono finiti, quando quanto si è prodotto è entrato in

produzione, ecc…

! Il manuale della qualità dovrebbe essere sempre richiesto da un committente, nel caso di progetti di dimensioni

considerevoli

+ Analisi dei rischi

! Se tutti i progetti andassero sempre secondo previsione non ci sarebbe la necessità di adottare tecniche di PM

! Nella realtà ogni progetto, piccolo o grande che sia, è soggetto a rischi che se non correttamente gestiti possono farne aumentare i costi, dilatare i tempi di realizzazione, pregiudicare la qualità del risultato

! L’analisi dei rischi tende a mettere in relazione le diverse minacce alle quali è esposto il progetto con la probabilità di ciascuna di potersi verificare, tanto più sarà alto questo connubio quanto più il rischio sarà rilevante quindi meriterà di essere gestito in maniera appropriata

+ La gestione del rischio

!  Data la formula Rischio = Probabilità della minaccia * Entità della minaccia

!  Occorre ordinare i diversi rischi per entità e per ogni rischio che superi una certa soglia definita specificare la modalità di gestione

!  Esempio: in un progetto software è frequente (alta probabilità) che cambino le specifiche che inizialmente erano state date per lo sviluppo con esiti rilevanti per la produzione (grande entità degli effetti)

!  Modalità di gestione: 1) adottare momenti formali di approvazione delle specifiche di analisi; 2) adottare un

approccio di sviluppo che prevede la costruzione di prototipi funzionanti; 3) ecc…

+ Qualche cautela rispetto ai progetti software

! Quella che precedentemente è stata illustrata è la tipica programmazione di un progetto il cui ciclo di sviluppo è a cascata, procede cioè in maniera lineare da un punto di inizio fino al raggiungimento degli obiettivi prefissati

! A seconda della dimensione del progetto, e spesso della natura del progetto, può essere indispensabile usare un altro modello di ciclo di vita, ad esempio a spirale

! Molto si discute sui vari modelli di ciclo di vita del software:

! Ciclo a cascata facile da concepire, sicuramente convergente, ma con minori prob. di rispetto dei requisiti qualitativi

! Ciclo a spirale modello incrementale che può portare a sforamenti di tempi e costi se non ben governato

+ Cicli di vita a spirale nei progetti software

! In un ciclo di vita a spirale si

attraversano ciclicamente le fasi di

! Determinazione obiettivi, alternative e vincoli

! Valutazione alternative, identificazione e risoluzione dei rischi

! Sviluppo e verifica del livello di prodotto studiato

! Pianificazione della fase successiva¹

! Occorre nella programmazione del progetto tenere conto delle diverse iterazioni necessarie

(1) Ghezzi e altri, “Ingegneria del software”, Mondadori Informatica

+ Output della fase di

programmazione del progetto

L’output della fase di programmazione del progetto è la cosiddetta BASELINE, comprensiva di:

! Elenco dettagliato delle fasi e delle attività progettuali collocate nel tempo e complete dei rispettivi vincoli di propedeuticità

! Ogni attività deve essere comprensiva dei requisiti di qualità

! Previsione delle risorse necessarie alla esecuzione del progetto relative alla diverse attività e fasi

! Matrice delle responsabilità delle varie fasi

! Dettaglio dei costi

Attuazione del progetto

Sunzi Disse:

Chi si attesta per primo sul campo di battaglia e ivi attende l’avversario è più fresco; chi vi giunge per ultimo e si affretta all’attacco è invece

affaticato. L’abile guerriero fa quindi in modo che gli altri vengano a lui ed evita il contrario.

Sun Tzu, “L’arte della guerra”, Economici Newton

+ Le fasi di attuazione del progetto

! Controllare il lavoro in corso – monitoraggio -

! Dare un feedback e comunicare con gli stakeholders

! Negoziare materiali forniture e servizi

! Risolvere le divergenze

! Gestire le variazioni di progetto

Il monitoraggio

+ Controllare il lavoro in corso

! Controllare il lavoro in corso presuppone l’aver determinato un riferimento in fase di programmazione del progetto – vedremo che ciò consiste nell’aver definito la baseline del progetto –

! Oltre al controllo, nel caso si evidenzino, differenze rispetto al programmato occorrerà attuare le necessarie misure

correttive

+ La baseline del progetto

! La fase di monitoraggio del progetto prende l’avvio dall’output della precedente fase di progetto la programmazione

! La programmazione di progetto produce una WBS completa di una pianificazione dei tempi, della pianificazione di

impiego delle risorse e una definizione dei requisiti di qualità richiesti che vengono cristallizzati nella cosiddetta baseline

! Il monitoraggio del progetto consiste nel rilevare e gestire opportunamente gli scostamenti dalla baseline

+ Il monitoraggio del progetto, le diverse metodologie

! Verifica mediante pietre miliari

! Verifica mediante stato d’avanzamento

! Verifica mediante monitoraggio del budget

+ Verifiche mediante pietre miliari

!  La verifica mediante pietre miliari prevede di confrontare se, alle scadenze previste, sono stati raggiunti i rispettivi milestones

!  In altri termini occorre verificare se quanto era stato previsto come pietra miliare è stato ottenuto, nei tempi convenuti, ai costi convenuti e con le caratteristiche di qualità necessarie

!  L’efficacia di queste verifiche sul progetto è strettamente

dipendente dalla correttezza della progettazione dei milestones e dalla loro significatività

!  La verifica mediante milestones è infatti discontinua e solo su una parte di quanto prodotto dal progetto per cui viene

solitamente integrata da altri tipi di verifiche

+ Verifica mediante stato d’avanzamento

! La verifica dello stato d’avanzamento di un progetto è una tipica tecnica di verifica “in continuo” in quanto, almeno in teoria, è possibile monitorare istante dopo istante eventuali scostamenti dalla baseline progettuale

! Nelle realtà questo, almeno per progetti di dimensione non banali, è impossibile e la verifica dello stato di avanzamento si attua attraverso momenti di verifica che possono prendere la forma di:

! Ispezioni

! Verifiche dello stato d’avanzamento

! Test

! Audit

+ L’ispezione

! L’ispezione è normalmente effettuata da tecnici qualificati o dal project manager consente nel verificare di persona lo stato d’avanzamento delle diverse attività

! Le ispezioni non dovrebbero essere annunciate e dovrebbero essere programmate a caso, ma devono svolgersi in un clima sereno e con modalità orientate alla massima trasparenza e obiettività nella raccolta degli elementi

! Gli ispettori porgono domande e rilevano fatti in maniera diretta e oggettiva senza formulare o proporre giudizi rispetto all’operato dei vari attori dei processi esaminati

+ Verifiche periodiche dello stato di avanzamento

! Le verifiche hanno un carattere di routinarietà, devono essere programmate in anticipo e sono i momenti in cui i

responsabili delle varie fasi o sotto unità relazionano sullo stato di avanzamento del progetto

! Le verifiche sono condotte dal Project Manager e/o da tecnici qualificati

! Le verifiche possono essere svolte attraverso colloqui diretti o mediante analisi di relazioni scritte o mediante l’analisi di materiali convenuti

+ Test

! Nell’ambito della progettazione del progetto vengono spesso programmati test sui semilavorati, sui prototipi, sulle singole componenti finite

! Se i test vengono fatti coincidere con determinate milestones i risultati dei test possono essere un utile strumento per monitorare lo stato di avanzamento del progetto

+ Gli audit

! Gli audit, o revisioni, possono essere programmati nel corso del progetto o alla fine dello stesso

! Sono tipicamente oggetto di revisione i rendiconti

economici, le pratiche di acquisto, i sistemi di sicurezza, le procedure di manutenzione e le procedure di pagamento

! L’audit è tipicamente una “verifica di terza parte” ciò viene svolta da esperti che non fanno parte del team di progetto e viene richiesta dal committente come verifica sull’operato del team di progetto

! Il rapporto preparato dagli auditor viene utilizzato per progettare le azioni correttive da parte del team

Le azioni correttive

+ I diversi tipi di azioni correttive

! Qualora i progressi effettivi non coincidano con il

programmato può esservi necessità di un azione correttiva

! È comunque bene dire che non tutti i disallineamenti fra programmato e realizzato necessitano di una correzione, una normale e fisiologica discrepanza – per eccesso o per difetto – fra quanto previsto e quanto realmente realizzato è nella natura delle cose che procedono per passi e solo nella teoria hanno un andamento continuo

! In generale si richiedono azioni correttive quando le

specifiche di qualità realizzate non sono sufficienti, quando si rischia di sforare i limiti di tempo o i limiti di budget

+ Azione correttive sulla qualità

! Quando la qualità non è conforme alle specifiche occorre intraprendere una azione correttiva:

! Qualora la qualità si esuberante rispetto alle specifiche se questo comporta costi eccessivi

! Qualora la qualità sia scadente rispetto alle specifiche se questo comporterà una non conformità del progetto complessivo

! Agire sulla qualità delle singole sotto attività è comunque normalmente assai difficile in quanto comporta intervenire, spesso pesantemente, sui processi produttivi, oppure sulle competenze delle persone, sule attrezzature utilizzate, ecc…

+ Azione correttive sui tempi

! Quando un progetto comincia a rimanere indietro sui tempi programmati:

! Occorre valutare se questo rientra comunque nei margini di progetto o se possa essere recuperato senza particolari azioni correttive nelle rimanenti fasi;

! Se ciò non è fattibile è possibile offrire un incentivo per

accelerare le attività, sicuramente questo aumenterà i costi, ma è da valutare in rapporto alle possibili penali per ritardo o

comunque ai costi indotti da un eccessivo prolungamento delle attività

! È poi possibile aumentare le risorse impiegate, tenendo comunque conto che il numero di risorse impiegate non è

linearmente in relazione con il lavoro prodotto, anzi in taluni casi, l’aumento di risorse in fasi critiche può non sortire effetti positivi

+ Azione correttive sui costi

! Quando un progetto comincia ad eccedere i costi previsti:

! Occorre valutare se ciò possa essere recuperato nelle fasi successive di lavorazione con opportune economie

! Se ciò non è possibile

!  Si può solo ridurre la portata del progetto – e questo

normalmente richiede una ricontrattazione con il committente –

!  o comporta il chiedere ulteriori fondi al committente – e questo sicuramente comporta una ricontrattazione con la committenza -

+ Il “problem solving” come metodo per affrontare gli imprevisti

Gli imprevisti vanno affrontati e risolti al fine di minimizzarne gli effetti negativi sul progetto, può essere utile in questo contesto richiamare alcune tecniche del problem solving come utili strumenti per affrontare la gestione degli imprevisti

In particolare verranno illustrati:

! Il diagramma di Pareto

! i diagrammi causa-effetto o di Ishikawa

+ Diagramma di Pareto

!  Secondo la schematizzazione di Pareto, spesso, il 20% delle cause determina l’80% degli effetti, quindi affrontando anche solo il 20% delle cause – se ben scelte – è possibile eliminare la gran parte dei problemi

!  Il diagramma di Pareto aiuta quindi a scegliere le priorità di intervento

0 5 10 15 20 25 30 35 40 45 50

Causa 1 causa 2 causa 3 causa 4 causa 5

Frequenza

+ Diagramma Causa-Effetto

! Il diagramma Causa-Effetto o a lisca di pesce o di Ishikawa permette di visualizzare la relazione fra un effetto e le diverse cause che possono concorrere a determinarlo

Misure Materiali Persone

Ambiente Metodi Macchine

Effetto

La comunicazione

+ La comunicazione attività chiave nella riuscita dei progetti

! La comunicazione, nelle sue varie forme e fini, è una attività chiave nella riuscita dei progetti

! Qui schematicamente e succintamente vengono prese in esame le due principali forme di comunicazione che il il PM deve mettere in atto:

! Il feedback dato ai diversi attori del progetto

! La comunicazione verso gli stakeholders

+ Feedback verso gli attori del progetto

La comunicazione operata dal PM nei confronti dei vari attori che partecipano al progetto ha lo scopo di mantenere buona la performance di coloro che già stanno operando

correttamente e di migliorare la prestazione di coloro che non stanno dando il meglio

! Per poter essere efficace occorre parlare di ciò che si osserva

! quando il feedback è di tipo positivo occorre descrivere quanto di buono si è visto – azioni- e relativi risultati

! Quando il feedback è di tipo negativo occorre anche aggiungere una proposta di correzione

+ Esempi di feedback comunicativo

!  Esempio di un feedback positivo: ”Completando il programma di attività secondo i piani previsti ci ha permesso di rispettare le scadenze. Apprezzo quanto ha fatto”

!  Esempio di feedback negativo:”I componenti prodotti nelle ultime due giornate settimana, in qualche caso, dimostrano eccessivi difetti di produzione, questo comporta la necessità di ricontrollare la produzione già pacchettizzata di questa

settimana. Chiediamo la sua collaborazione per operare un maggiore controllo sui pezzi che saranno a lei assegnati. Se ritiene che sia indispensabile che le vengano illustrate di nuovo le procedure di controllo dei prodotti o che le vengano

rispiegate le fasi di lavorazione faccia riferimento all’istruttore Rossi. Non si faccia scrupolo di chiedere, Rossi è a sua

disposizione.”

+ Stili di feedback

! Occorre descrivere più che valutare

! È bene essere specifici nella contestazione

! La contestazione deve includere anche il suggerimento di quanto va cambiato

! È bene essere tempestivi – una contestazione deve

intervenire su un aspetto che è ancora possibile correggere, altrimenti è inutile –

! Occorre comunicare chiaramente

! La comunicazione non è mai unidirezionale, anche quando si comunica qualcosa occorre saper ascoltare

+ Esercitazione 3

! Per gruppi che non siano espressione di afferenza gerarchica discutere se, nell’ambito lavorativo reale, vengono adottate strategie comunicative che comportino un feedback

! Discutere se le tecniche di feedback adottate sono coerenti con le indicazioni date nel corso e nel caso non lo siano proporre modalità di adozione di migliori strategie comunicative.

+ Comunicazione verso gli stakeholders

!  La comunicazione verso i portatori di interesse è indispensabile per mantenere le condizioni al contorno del progetto favorevoli

!  Coloro che non hanno informazioni, a seconda delle propensioni personali, tendono ad enfatizzare le aspettative negative o

quelle positive, entrambi gli atteggiamenti danneggiano la conduzione di progetto

!  È bene quindi mantenere i diversi interlocutori esterni aggiornati rispetto all’andamento del progetto con cadenze opportune – che sarebbe bene predefinire in maniera tale che non vi siano false aspettative –

!  L’informazione può essere fornita con relazioni, ma possibilmente anche con visite dirette o partecipazioni a riunioni sullo stato d’avanzamento

+ Sintesi delle necessità di comunicazione

! Può facilitare la sistematicità della comunicazione l’adozione di uno schema quale quello sotto riportato

La negoziazione

+ Le dieci regole della negoziazione 1/2

!  Prepararsi (essere perfettamente padroni di quanto si dovrà discutere)

!  Minimizzare le differenze percettive (la controparte può avere una percezione diversa di un certo aspetto che quindi va descritto in maniera tale che possa essere accettato o rigettato, ma in ogni caso chiarito)

!  Ascoltare (se si parla più del 50% del tempo di certo non si è ascoltato a sufficienza)

!  Prendere appunti sullo stato d’avanzamento della discussione (occorre appuntarsi quali sono gli aspetti su cui ci si trova d’accordo e quelli su cui non si è trovato un accordo per sapere a che punto si è della discussione)

!  Essere creativi ( una soluzione è a volte frutto di un cambio di prospettiva verso la quale occorre rimanere costantemente aperti)

+ Le dieci regole della negoziazione 2/2

! Aiutare l’altra parte (i buoni negoziatori riconoscono che il problema della loro controparte è anche il loro problema)

! Fare scambi (evitate di dare qualcosa per nulla, ma per ottenere qualcosa di importante siate disposti a dare qualcosa)

! Essere pronti nel ringraziare (un ringraziamento è il modo più sicuro e rapido per dissipare sentimenti negativi)

! Evitate gli ultimatum (un ultimatum richiede che l’altro si arrenda o risolva la situazione combattendo)

! Ponete scadenze realistiche (molte negoziazioni non hanno termine perché non esistono scadenze alla discussione)

Le variazioni di progetto

+ Le varianti

! Vengono indicate come varianti le variazioni apportate alle caratteristiche qualitative o quantitative del progetto in corso d’opera

! Ogni variante introdotta in corso d’opera finisce

inevitabilmente per incidere sia sui tempi di realizzazione che sui costi e costituisce normalmente un notevole fattore di stress per i team di progetto

+ I motivi che portano alla nascita di varianti

! Gli obiettivi e i requisiti non sono stati definiti con sufficiente precisione e con sufficiente dettaglio

! Il progetto si è protratto nel tempo e durante tale periodo sono cambiati gli scenari di contesto e le esigenze del cliente

! Si è verificato un progresso tecnologico

! Si è verificato un cambiamento nella strategia del committente

! Il committente ha meglio compreso le finalità e le implicazioni del progetto

+ Il processo di gestione delle varianti

! Definire gli obiettivi della variante, il contenuto, i diversi requisiti, ecc…

! Studiare cosa comporta realizzare la variante in termini di soluzione tecnica adottata

! Determinare le variazioni al progetto in termini di tempi, di costi, di risorse necessarie, ecc…

! Presentare al committente la soluzione e le implicazioni per il progetto e ottenere l’autorizzazione a procedere

! Aggiornare il piano esecutivo e presentare al Team di progetto la variante

+ Output della fase di esecuzione del progetto

L’output della fase di esecuzione del progetto è il raggiungimento degli obiettivi di progetto:

! Gli obiettivi di progetto, oltre alle diverse varianti approvate, devono essere stati raggiunti nei tempi convenuti, con i requisiti di qualità richiesti e nel limite di costo convenuto

! Deve essere avvenuta una corretta comunicazione verso gli stakeholders in merito agli obiettivi raggiunti

La conclusione del progetto

Sunzi Disse:

In guerra conta vincere; lunghe operazioni spuntano le armi e

abbattono il morale, e l’assedio d’una città esaurisce le forze. Se l’esercito è impegnato troppo a lungo, le risorse statali

risultano insufficienti. Se le armi sono rovinate, il morale è basso, le forze cedono e le finanze sono in via di esaurimento…

Sun Tzu, “L’arte della guerra”, Economici Newton

+ Quando è finito ?

! L’obiettivo del PM è di ottenere l’accettazione da parte del cliente del risultato del progetto

! Questo significa che il cliente concorda che quanto

convenuto è stato ottenuto, sia in termini di quantità di quanto è stato prodotto, sia in termini di qualità

! Sarà più semplice ottenere l’accettazione da parte del committente se i risultati del progetto sono misurabili e presentati in maniera obiettivamente valutabile, affinché questo sia possibile occorre che tutto il progetto sia stato teso a rendere misurabili ed evidenti i risultati di quanto prodotto

+ Lista di controllo del

completamento del progetto 1/3

! Testare il risultato del progetto – il cosiddetto test in grande di quanto prodotto non è semplicemente la somma dei test fatti sui vari componenti, ma un test complessivo che verifica se i risultati complessivi di qualità sono stati raggiunti –

! Redigere il manuale operativo

! Completare la documentazione – disegni, schemi di procedure operative, ecc… -

! Consegnare il risultato del progetto al cliente

! Addestrare il personale del cliente

! Riassegnare il personale del progetto

+ Lista di controllo del

completamento del progetto 2/3

!  Disporre di attrezzature, materiali e forniture avanzate

!  Restituire le attrezzature noleggiate

!  Riepilogare i maggiori problemi incontrati e le loro soluzioni

!  Documentare i progressi tecnologici compiuti

!  Riepilogare le raccomandazioni per le future ricerche e sviluppi

!  Sintetizzare le lezioni apprese nel trattare con i problemi affrontati

!  Compilare i rapporti di valutazione sulle performances di tutto lo staff di progetto

+ Lista di controllo del

completamento del progetto 3/3

! Fornire un feedback sulle performances a tutto lo staff del progetto

! Completare la revisione finale dei conti

! Scrivere il rapporto finale

! Eseguire una revisione del progetto con l’alta direzione

! Dichiarare il progetto completato

+ Esercitazione 4

!  Mr. Smith a capo progetto “attivazione nuova miniera aurifera nella zona delle Alti Valli” della ditta ACME riferisce alla direzione che il progetto sta subendo cospicui ritardi:

!  a causa delle infiltrazioni di acqua causate dalle piogge monsoniche;

!  a causa della scarsa quantità di manodopera reperita delle ditte che si occupano di escavazione

!  a causa della natura delle macchine che hanno garantito una minore produttività di scavo prevista, probabilmente a causa delle prospezioni geologiche imprecise iniziali che avevano preventivato terreni meno compatti di quanto si siano rivelati nella realtà

!  Discute con la direzione di ciò e la direzione decide di tagliare i premi di produzione per il PM e per il personale dell’azienda coinvolto nel progetto.

!  Discutere per gruppi il caso ed evidenziare pecche nel comportamento dell’Azienda e del PM

Gestione del ciclo di vita di un

software ad uso sanitario con

specifici requisiti di sicurezza

Concepimento e definizione del progetto

+ Lo sviluppo di software… come un qualsiasi altro prodotto

In questo contesto non si prenderanno in esame gli aspetti che accomunano lo sviluppo di software alla produzione di prodotti in altri ambiti merceologici:

! Analisi marketing

! Analisi della fattibilità tecnica

! Stima preliminare dei costi e dei tempi necessari

! Ecc…

+ Ciò che distingue il software ad uso sanitario da altri prodotti

! 

I sistemi informativi ad uso sanitario, tipicamente, hanno la stessa architettura dei sistemi informativi amministrativi

! 

Ma sono usati per supportare processi clinici, in virtù di ciò:

! 

Possono essere sorgente di rischi per la

“sicurezza” dei pazienti (safety critical)

! 

Possono non essere strumenti appropriati per una determinata destinazione d’uso (Health Tech.

Assessment)

+ Definizione delle caratteristiche di sicurezza come parte delle caratteristiche qualitative

!  Fra le varie caratteristiche di qualità del prodotto andranno definite anche le caratteristiche di sicurezza. Essendo in italiano il termine sicurezza un termine dai molti significati si preferisce usare i termini inglesi safety e reliability

!  Un applicativo è reliable se

"  “fa ciò che deve fare”

"  “the probability of failure-free software operation for a

specified period of time in a specified environment”

!  Un applicativo è safe se

"  “NON fa ciò che NON DEVE fare”

"  “the software property of avoiding the introduction into a

system of hazardous conditions that could result in death or personal injury”

+ Safety e Reliability due dimensioni indipendenti

! Un applicativo può essere in uso a 800 utenti che lo utilizzano 365 giorni all’anno e presentare solo rarissimi

malfunzionamenti, ma quando questo rarissimamente accade, si provocano gravissimi danni ai pazienti (molto Reliable, poco Safe)

! Un applicativo ha pessimi valori di uptime, spesso non è utilizzabile, ma non presenta mai anomalie tali da mettere in pericolo il paziente (poco Reliable, ma Safe)

+ Analisi del rischio

In un prodotto che deve avere stringenti caratteristiche di sicurezza va condotta una accurata analisi del rischio mediante:

! Accurata specificazione della destinazione d’uso del prodotto

! In base alla destinazione d’uso vengono delineati i casi d’uso su cui verificare le caratteristiche di safety e reliability

! È auspicabile che per gli applicativi che possono avere problemi di safety si proceda ad effettuare l’analisi del rischio avvalendosi di tecniche formali di specifica (UML)

La programmazione del progetto

+ La programmazione del progetto di sviluppo

!  Normalmente per un progetto software di dimensioni non banali, per il quale le caratteristiche di qualità siano imprescindibili, si adotta un ciclo di vita a spirale

!  Preferibilmente – se il tipo di ambito lo consente – si utilizza una metodologia basata su prototipi evolutivi – piuttosto che

prototipi trow away – che ad ogni iterazione del ciclo di vita approssimeranno sempre più da vicino l’insieme di specifiche definitive

!  Ad ogni ciclo dovrà essere verificata la rispondenza ai criteri di qualità stabiliti e di sicurezza (safety e reliability)

!  In fase quindi di programmazione del progetto andranno gestiti i milestones del progetto che dovranno necessariamente

comprendere le verifiche di sicurezza

+ Documentazione dei controlli di sicurezza in fase di produzione

! È auspicabile che il produttore metta a disposizione dell’utilizzatore finale la documentazione sui controlli di sicurezza effettuati in fase di produzione

! In base alla documentazione prodotta, l’utilizzatore deciderà se fare affidamento in tutto o in parte sui controlli già

effettuati dal produttore o se rifare una parte dei controlli per tenere conto del diverso contesto nel quale l’applicativo sarà utilizzato rispetto al contesto di sviluppo

+ Il piano di comunicazione

!  In un progetto che adotta un ciclo di vita a spirale la necessità di una corretta comunicazione fra gli attori del progetto è una necessità fondamentale

!  Una non corretta comunicazione è causa frequente di una più lenta convergenza del progetto e quindi di costi elevati

!  Stante questa importanza è indispensabile progettare un

adeguato piano di comunicazione fin dalla stesura della WBS al fine di garantire opportuni momenti di scambio informativo e opportuni strumenti di interazione fra i diversi attori

!  Altrettanto importante è la comunicazione con gli stakeholders che possono essere messi in difficoltà dalla natura ciclica delle attività condotte

La realizzazione del progetto

+ La realizzazione del progetto come monitoraggio degli scostamenti dalla baseline

! Un ciclo di vita iterativo, se da un lato permette un controllo molto accurato della qualità prodotta dal progetto rischia, se non ben monitorato e se non vengono costantemente attuate le misure correttive necessarie, consistenti sforamenti di tempi e di costi a causa di una convergenza lenta sugli obiettivi

! La gestione risulta ancora più complicata se alle complessità proprie del progetto si aggiungono anche frequenti e non preventivate richieste di personalizzazioni – customizzazioni –

! Nel seguito vengono presi in esame i due diversi aspetti

+ Gestione di una non conformità di sicurezza

! Il momento in cui si rileva una non conformità del prodotto rispetto ad un requisito di sicurezza, ha profonde

ripercussioni sulle azioni che devono essere condotte e sui costi conseguenti, ma le modalità di gestione sono nelle linee essenziali assai simili

! Occorre fare una analisi del problema tesa a mettere in luce i motivi che abbiano portato alla non conformità

! Occorre correggere le cause che determinano la non conformità

! Occorre adottare un piano di azione che minimizzi la probabilità che la non conformità si ripresenti

! Occorre verificare se il piano d’azione ha sortito gli effetti sperati ed effettivamente ha condotto alla minimizzazione delle

probabilità di non conformità

+ Le non conformità nelle varie fasi del ciclo di vita

!  Una non conformità di sicurezza, come ogni altra deficienza nelle caratteristiche qualitative, tanto prima viene rilevata nel processo produttivo, tanto più sarà di facile gestione e meno costi comporterà

!  Se una grave non conformità viene rilevata dopo la consegna del prodotto, si può arrivare fino al ritiro del prodotto dal mercato, con conseguenti gravi ricadute per l’azienda produttrice

!  Molto diverso è il caso in cui la non conformità venga rilevata nel corso del ciclo di produzione, in questo caso gli

accorgimenti adottati, le tecniche impiegate, ecc… entreranno a fare parte della documentazione del progetto e saranno

auspicabilmente formalizzate in una procedura che eviti il ripetersi del problema

+ Il software come parte di un contesto

!  Il buon funzionamento del software, per poter essere garantito, non può prescindere dalla certezza del contesto

!  Non avremmo infatti garanzia di buon funzionamento se:

!  Non è garantito il funzionamento dell’hardware

!  Non è garantito il funzionamento del sistema di telecomunicazioni

!  Non è garantito il funzionamento del software di base

!  Non è garantito il funzionamento delle interfacce software – quindi non è garantito il software di contorno con il quale occorre

interoperare –

!  Questo, aspetto peraltro evidente e banale, pone una serie di problemi e limiti al test del software in ambiente di sviluppo e costituisce una seria minaccia da gestire nell’arco della vita dell’applicativo

+ Impatto delle personalizzazioni sulla qualità del software

! Da stime effettuate, alcuni ad uso sanitario vengono

fortemente personalizzati al momento dell’acquisizione e durante tutto il ciclo di vita – fino al 60% del valore, per i progetti di dimensioni maggiori e in misura potenzialmente anche maggiore per i progetti più piccoli –

! Le personalizzazioni sono le parti di un applicativo nelle quali si massimizza la probabilità di errori e

malfunzionamenti, tipicamente perché sono le parti meno testate

! Inoltre la messa in linea di nuove versioni minimizza la disponibilità complessiva del sistema e la probabilità di errate configurazioni

I test della sicurezza in fase di realizzazione

+ Il test della reliability

!  Secondo quanto programmato, o in base ad esigenze che si evidenzino, occorre condurre test di reliability

!  Il test effettuato sarà tanto più efficace quanto più elevato sarà il grado di copertura ottenuto

!  Il test sarà tanto più efficace quanto più sarà condotto in

condizioni simili alla realtà, quindi tanto più le condizioni di test saranno simili a quelle di produzione

!  Nota Bene: in ingegneria del software il grado di copertura di un test indica la percentuale di test effettuati rispetto a quelli

teoricamente necessari perché il test sia esaustivo, ad esempio il criterio di copertura dei comandi è il rapporto fra i comandi eseguiti in un test e il numero totale di test eseguibili, ecc…

+ La verifica della reliability mediante l’esecuzione di test funzionali

!  Il test della affidabilità si conduce verificando che le funzionalità messe a disposizione siano conformi alle specifiche ciò

comporta la verifica:

–  Di tutte le funzioni (voci di menu)

–  Di tutti i processi gestionali eseguiti dagli utilizzatori attraverso più voci di menù

–  Dei possibili cambi di stato di entità applicative, verifica che

l’applicativo transiti solo da stati concessi, nel rispetto dei vincoli di progetto

"  Affinché il test possa essere effettuato occorre che siano definiti:

"  Il modello funzionale di base, gerarchia dei menu

"  Il modello dei processi

"  Il modello a stati e transazioni delle entità applicative.

+ La verifica della safety

! La verifica della safety consiste nell’aggiungere al piano di test definito per la reliability alcuni test aggiuntivi pensati per verificare se - eventualmente in particolari condizioni – il software possa presentare comportamenti che rappresentino una minaccia della sicurezza

! Stante che questa attività è particolarmente onerosa, può essere condotta solo su aspetti specifici che gli esperti del dominio applicativo – cioè utilizzatori esperti del processo – abbiano identificato come particolarmente critici

+ Limiti del controllo della safety

! La safety è una proprietà di sistema e non una proprietà del software in quanto tale, verificare che un applicativo abbia tale caratteristica non esclude, almeno in termini generali, che un sistema che impiega un tale software non sia insicuro

! Non è tuttavia detto che il fornitore sia in grado di fare

qualcosa di più che certificare ciò e consigliare – o imporre, a seconda dei casi – un certo contesto all’interno del quale il software applicativo debba essere fatto funzionare

+ Documento che attesti la safety di un prodotto

! 

Il documento relativo alla safety del prodotto “

” [Bishop and

Bloomfield 1998]

!  O prova che il software NON è safe (quando si verifica che un evento pericoloso può accadere)

!  O fornisce una difendibile evidenza che il software ha resistito ad un ben progettato insieme di casi di test il cui scopo è dimostrare che il prodotto non è safe (quando non si verifica che un evento pericoloso può accadere)

+ Di chi è la responsabilità del controllo

!  La gran parte di verifiche sul prodotto è in capo al fornitore, ma la verifica del sistema in produzione è un dovere dell’acquirente – verifica di accettazione del prodotto o collaudo -, anche solo per verificarne la liquidabilità

!  Le verifiche di collaudo saranno tanto più semplici e con basso livello di contenzioso quanto più saranno state seguite alcune regole:

!  Aver definito specifiche chiare in fase di ordine e di analisi

!  Aver utilizzato specifiche oggettivabili e misurabili

!  Dovranno essere evitate specifiche vaghe del tipo: il sistema deve essere sicuro, ma elencare e dettagliare le specifiche richieste

+ Dimostrabilità della reliability e della safety da parte dell’utilizzatore

! L’utilizzatore può avere la necessità di dare evidenza in maniera difendibile che il prodotto è affidabile (reliable), che il prodotto è sicuro (safe), che il prodotto è stato testato come privo di deficienze e può essere esposto in rete

(tamper proof, secure), ecc…

! Questa necessità è imprescindibile qualora il produttore non abbia eseguito questi controlli o non abbia la possibilità di eseguirli in maniera significativa, ad esempio perché solo nel contesto reale di funzionamento si possa condurre un test significativo

+ Test di regressione in caso di sostituzione del sistema

! Nel caso l’applicativo fornito vada a sostituire un applicativo in uso, riveste una particolare importanza il cosiddetto test di regressione, cioè il confronto sistematico fra gli output

prodotti dal vecchio programma e quelli del nuovo programma a partire dai medesimi input

Attività successive al rilascio del

prodotto e al collaudo