Project Management in Sanità - UNIMOREdidattica.agentgroup.unimore.it › didattica › cdl › Lab... · Gli strumenti a disposizione per l’analisi iniziale ! La fase iniziale

+

Project Management in Sanità

Una introduzione critica di Pierfrancesco Ghedini http://www.informaticasanitaria.it

+…

“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 (generale e filosofo cinese 544 a.C – 496 a.C.), “L’arte della guerra”, Economici Newton

12/11/14 http://www.informaticasanitaria.it

2

+ Spinte evolutive

Applicazioni Sanitarie

Internet Of Things

Medical Devices

Servizi applicativi Condivisi e Semantica

User Interface

e Usabilità

Modellazione Processi e Percorsi

Backbone – Infrastruttura di comunicazione

Requisiti utente e aspetti organizzativi Requisiti di integrazione e semantica Architettura di integrazione


3

+Un esempio: la cartella clinica informatizzata

Prendendo come esempio la cartella clinica informatizzata è possibile dire che:

n  l’interfaccia utente deve essere progettata a livello aziendale seguendo le esigenze degli stakeholders;

n  essa si deve integrare verso l’altro con moduli applicativi di rango sovra aziendale – anagrafe dei professionisti, anagrafe dei contatti, repository, servizi di gestione della terapia, ecc… -;

n  le ontologie a cui fa riferimento devono essere di rango sovra aziendale;

n  si deve integrare verso il basso con dispositivi medici e sensori;

n  le varie componenti vengono tenute solitamente insieme da un middleware di integrazione.


4

+Lo spirito del Project Management

n  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

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

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

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


5

+Che cosa è un progetto ?

n  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

n  Un progetto per poter essere portato termine necessità di risorse: capacità, talenti, attrezzature, strumenti ed equipaggiamento, informazioni, sistemi e tecniche, denaro, ecc…

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


6

+Il ciclo di vita di un progetto

n  Schematicamente si delinea il ciclo di vita di un progetto nel seguente modo: n  Concepimento e definizione del progetto; n  Programmazione del progetto; n  Realizzazione; n  Completamento e valutazione n  Trasversale ad ogni fase del progetto è l’azione costante di

informazione degli stakeholders e degli attori del progetto

n  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.


7

+Le metriche di un progetto

n  Le metriche in base alle quali misurare i risultati ottenuti da un progetto sono essenzialmente tre: n  Qualità; n  Costo; n  Tempo.

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

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

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


8

+La contrattazione iniziale dei tre parametri fondamentali, il controllo e la ricontrattazione

n  L’essenza del PM consiste nel: n  Definire un accordo di progetto con la committenza che stabilisca in

maniera chiara i vincoli di qualità, costo e tempo; n  Monitorare il progetto per verificare costantemente il rispetto dei

vincoli di qualità, costo e tempo; n  Eventualmente ricontrattare con la committenza vincoli di qualità,

costo e tempo con la committenza.

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

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


9

+Il Project Manager

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

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

n  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

n  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

n  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


10

+Esercitazione 1 1/2

n  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

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

n  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


11

+Esercitazione 1 2/2

n  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

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

n  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

n  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


12

Concepire e definire il progetto


13

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


14

+L’origine dei progetti

n  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à

n  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

n  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


15

+Le fasi di avvio del progetto

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

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

n  Scrivere una prima traccia del progetto

n  Delineare le principali finalità e i principali obiettivi

n  Elencare i vincoli e le principali possibili criticità

n  Valutare strategie alternative

n  Definire una modalità di azione


16

+Chi sono gli stakeholders del progetto

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

n  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

n  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


17

+Gli strumenti a disposizione per l’analisi iniziale

n  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

n  È 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


18

+Il Brainstorming

n  Elencare tutte le idee proposte dai membri del gruppo

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

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

n  Non essere ansiosi di chiudere il processo di raccolta


19

+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:

n  Deve avere un nome e una proposta di Project Manager

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

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

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

n  Deve proporre una macro schedulazione delle tempestiche

La proposta di progetto deve essere approvata dagli stakeholders


20

Programmazione del progetto


21

+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:

n  Dettagliare gli obiettivi di progetto;

n  Definire le strategie per giungere all’obiettivo;

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

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

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

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

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

n  Progettare l’eventuale formazione del team;

n  Definire le politiche e le procedure da adottare.


22

+Struttura di analisi del lavoro

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

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

n  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à


23

+Il progetto “Torta al cioccolato”


24

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

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

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

n  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

n  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à


25

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

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

n  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


26

+Il pert

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

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

n  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.


27

+Un modello matematico per la valutazione della durata delle attività n  Per valutare la durata di una attività si può usare uno strumento

matematico – distribuzione beta –

n  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

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

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

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


28

+Diagramma di Gantt

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

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

n  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

n  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


29

+Costruire diagrammi di Gantt

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

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


30

+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:

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

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

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

n  Inizio/Fine: che riproduce il primo tipo di vincolo, ma permette la scrittura specificando in ordine inverso le attività (sostanzialmente inutile)


31

+La definizione dei milestones

n  La fase di programmazione del progetto permette la progettazione dell’insieme delle attività che andranno svolte per giungere al completo raggiungimento degli obiettivi previsti

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

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

n  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


32

+La natura dei milestones

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

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

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

n  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…


33

+La WBS e i milestones

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

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

n  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


34

+Altri usi dei Milestones

n  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.


35

+Gestire la dimensione costo

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

n  Il costo del lavoro e gli oneri riflessi relativi

n  Il costo dei materiali impiegati e delle forniture necessarie

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

n  Le spese generali e amministrative

n  Il profitto d’impresa


36

+Gestire le risorse

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

n  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

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


37

+La gestione della risorsa lavoro


38

+Assegnazione delle responsabilità

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

n  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

n  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à


39

+La matrice delle responsabilità

Progetto ____________________

Attività Budget Termini Responsabilità


40

+Esercitazione 2

n  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

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


41

La definizione, il dimensionamento e la gestione del Team di progetto


42

Sunzi Disse:

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



43

+La definizione del Team di progetto

n  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

n  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

n  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…


44

+Il dimensionamento del Team di progetto


45

+La gestione del Team di progetto

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

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

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


46

+Gestire la qualità

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

n  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à

n  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…


47

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

n  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à

n  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…

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


48

+Analisi dei rischi

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

n  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

n  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


49

+La gestione del rischio

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

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

n  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)

n  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…


50

+Qualche cautela rispetto ai progetti software

n  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

n  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

n  Molto si discute sui vari modelli di ciclo di vita del software: n  Ciclo a cascata facile da concepire, sicuramente convergente, ma

con minori prob. di rispetto dei requisiti qualitativi n  Ciclo a spirale modello incrementale che può portare a

sforamenti di tempi e costi se non ben governato


51

+Cicli di vita a spirale nei progetti software

n  In un ciclo di vita a spirale si attraversano ciclicamente le fasi di n  Determinazione obiettivi, alternative e

vincoli

n  Valutazione alternative, identificazione e risoluzione dei rischi

n  Sviluppo e verifica del livello di prodotto studiato

n  Pianificazione della fase successiva1

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

(1) Ghezzi e altri, “Ingegneria del software”, Mondadori Informatica 12/11/14 http://www.informaticasanitaria.it

52

+Output della fase di programmazione del progetto

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

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

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

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

n  Matrice delle responsabilità delle varie fasi

n  Dettaglio dei costi


53

Attuazione del progetto


54

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.



55

+Le fasi di attuazione del progetto

n  Controllare il lavoro in corso – monitoraggio -

n  Dare un feedback e comunicare con gli stakeholders

n  Negoziare materiali forniture e servizi

n  Risolvere le divergenze

n  Gestire le variazioni di progetto


56

Il monitoraggio


57

+Controllare il lavoro in corso

n  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 –

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


58

+La baseline del progetto

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

n  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

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


59

+Il monitoraggio del progetto, le diverse metodologie

n  Verifica mediante pietre miliari

n  Verifica mediante stato d’avanzamento

n  Verifica mediante monitoraggio del budget


60

+Verifiche mediante pietre miliari

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

n  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

n  L’efficacia di queste verifiche sul progetto è strettamente dipendente dalla correttezza della progettazione dei milestones e dalla loro significatività

n  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


61

+Verifica mediante stato d’avanzamento

n  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

n  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: n  Ispezioni n  Verifiche dello stato d’avanzamento n  Test n  Audit


62

+L’ispezione

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

n  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

n  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


63

+Verifiche periodiche dello stato di avanzamento

n  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

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

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


64

+Test

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

n  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


65

+Gli audit

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

n  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

n  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

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


66

Le azioni correttive


67

+I diversi tipi di azioni correttive

n  Qualora i progressi effettivi non coincidano con il programmato può esservi necessità di un azione correttiva

n  È 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

n  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


68

+Azione correttive sulla qualità

n  Quando la qualità non è conforme alle specifiche occorre intraprendere una azione correttiva: n  Qualora la qualità si esuberante rispetto alle specifiche se questo

comporta costi eccessivi

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

n  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…


69

+Azione correttive sui tempi

n  Quando un progetto comincia a rimanere indietro sui tempi programmati: n  Occorre valutare se questo rientra comunque nei margini di

progetto o se possa essere recuperato senza particolari azioni correttive nelle rimanenti fasi;

n  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à

n  È 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


70

+Azione correttive sui costi

n  Quando un progetto comincia ad eccedere i costi previsti: n  Occorre valutare se ciò possa essere recuperato nelle fasi

successive di lavorazione con opportune economie

n  Se ciò non è possibile

n  Si può solo ridurre la portata del progetto – e questo normalmente richiede una ricontrattazione con il committente –

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


71

+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:

n  Il diagramma di Pareto

n  i diagrammi causa-effetto o di Ishikawa


72

+Diagramma di Pareto

n  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

n  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


73

+Diagramma Causa-Effetto

n  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

Materiali Manodopera

(Ambiente) Metodi Macchine

Effetto


74

La comunicazione


75

+La comunicazione attività chiave nella riuscita dei progetti

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

n  Qui schematicamente e succintamente vengono prese in esame le due principali forme di comunicazione che il il PM deve mettere in atto: n  Il feedback dato ai diversi attori del progetto

n  La comunicazione verso gli stakeholders


76

+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

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

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

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


77

+Esempi di feedback comunicativo

n  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”

n  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.”


78

+Stili di feedback

n  Occorre descrivere più che valutare

n  È bene essere specifici nella contestazione

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

n  È bene essere tempestivi – una contestazione deve intervenire su un aspetto che è ancora possibile correggere, altrimenti è inutile –

n  Occorre comunicare chiaramente

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


79

+Esercitazione 3

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

n  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.


80

+Problemi di comunicazione rilevati n  Poca chiarezza su quali sono i progetti in corso e chi sono i PM

n  Poca chiarezza sugli obiettivi di progetto e sulle variazioni di progetto

n  Comunicazione esclusivamente fatta attraverso e/mail e poche riunioni di team di progetto, poca comunicazione fra i vari attori del progetto

n  Poca chiarezza dei ruoli nei progetti e poca chiarezza del legame fra le singole attività e l’intero progetto

n  Tenere modalità di comunicazione mirate senza fare spam, con chiarezza se la comunicazione è per competenza o per conoscenza

n  Differenze di stili comunicativi a seconda delle aree del servizio, problemi di comunicazione fra servizi tecnici dell’azienda

n  Tenere un linguaggio che sia adeguato al destinatario

n  Pochi feedback positivi


81

+Comunicazione verso gli stakeholders

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

n  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

n  È 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 –

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


82

+Sintesi delle necessità di comunicazione

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


83

La negoziazione


84

+Le dieci regole della negoziazione 1/2

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

n  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)

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

n  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)

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


85

+Le dieci regole della negoziazione 2/2

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

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

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

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

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


86

+Esercitazione: la negoziazione

n  Ci si suddivida in due gruppi;

n  Il primo gruppo rappresenterà le tesi del project manager che intende ottenere un dilazionamento dei tempi di due mesi rispetto alla base line di un anno e un aumento del finanziamento del 20% del costo rispetto ad una stanziato di 1.000.000 €

n  Il secondo gruppo rappresenterà la committenza che intende ottenere un tempo di realizzazione più breve di un mese rispetto alla baseline di un anno e uno sconto del 5% rispetto ai costi preventivati

n  Dieci minuti per impostare la strategia di comunicazione e dieci minuti per effettuare la trattativa.


87

Le variazioni di progetto


88

+Le varianti

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

n  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


89

+I motivi che portano alla nascita di varianti

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

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

n  Si è verificato un progresso tecnologico

n  Si è verificato un cambiamento nella strategia del committente

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


90

+Il processo di gestione delle varianti

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

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

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

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

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


91

+Output della fase di esecuzione del progetto

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

n  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

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


92

La conclusione del progetto


93

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…



94

+Quando è finito ?

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

n  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à

n  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


95

+Lista di controllo del completamento del progetto 1/3

n  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 –

n  Redigere il manuale operativo

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

n  Consegnare il risultato del progetto al cliente

n  Addestrare il personale del cliente

n  Riassegnare il personale del progetto


96


n  Disporre di attrezzature, materiali e forniture avanzate

n  Restituire le attrezzature noleggiate

n  Riepilogare i maggiori problemi incontrati e le loro soluzioni

n  Documentare i progressi tecnologici compiuti

n  Riepilogare le raccomandazioni per le future ricerche e sviluppi

n  Sintetizzare le lezioni apprese nel trattare con i problemi affrontati

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


97


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

n  Completare la revisione finale dei conti

n  Scrivere il rapporto finale

n  Eseguire una revisione del progetto con l’alta direzione

n  Dichiarare il progetto completato


98

+Esercitazione 4

n  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: n  a causa delle infiltrazioni di acqua causate dalle piogge monsoniche; n  a causa della scarsa quantità di manodopera reperita delle ditte che si occupano di

escavazione n  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à

n  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.

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


99

Gestione del ciclo di vita di un software ad uso sanitario con specifici requisiti di sicurezza


100

Concepimento e definizione del progetto


101

+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:

n  Analisi marketing

n  Analisi della fattibilità tecnica

n  Stima preliminare dei costi e dei tempi necessari

n  Ecc…


102

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

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

n Ma sono usati per supportare processi clinici, in virtù di ciò: n Possono essere sorgente di rischi per la

“sicurezza” dei pazienti (safety critical) n Possono non essere strumenti appropriati per

una determinata destinazione d’uso (Health Tech. Assessment)


103

+ Definizione delle caratteristiche di sicurezza come parte delle caratteristiche qualitative

n  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

n  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”

n  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”


104

+Safety e Reliability due dimensioni indipendenti

n  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)

n  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)


105

+Analisi del rischio

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

n  Accurata specificazione della destinazione d’uso del prodotto

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

n  È 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)


106

La programmazione del progetto


107

+La programmazione del progetto di sviluppo

n  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

n  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

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

n  In fase quindi di programmazione del progetto andranno gestiti i milestones del progetto che dovranno necessariamente comprendere le verifiche di sicurezza


108

+Documentazione dei controlli di sicurezza in fase di produzione

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

n  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


109

+Il piano di comunicazione

n  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

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

n  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

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


110

La realizzazione del progetto


111

+ La realizzazione del progetto come monitoraggio degli scostamenti dalla baseline

n  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

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

n  Nel seguito vengono presi in esame i due diversi aspetti


112

+Gestione di una non conformità di sicurezza

n  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 n  Occorre fare una analisi del problema tesa a mettere in luce i

motivi che abbiano portato alla non conformità

n  Occorre correggere le cause che determinano la non conformità

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

n  Occorre verificare se il piano d’azione ha sortito gli effetti sperati ed effettivamente ha condotto alla minimizzazione delle probabilità di non conformità


113

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

n  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à

n  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

n  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


114

+Il software come parte di un contesto

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

n  Non avremmo infatti garanzia di buon funzionamento se: n  Non è garantito il funzionamento dell’hardware n  Non è garantito il funzionamento del sistema di telecomunicazioni n  Non è garantito il funzionamento del software di base n  Non è garantito il funzionamento delle interfacce software – quindi

non è garantito il software di contorno con il quale occorre interoperare –

n  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


115

+Impatto delle personalizzazioni sulla qualità del software

n  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 –

n  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

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


116

I test della sicurezza in fase di realizzazione


117

+Il test della reliability

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

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

n  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

n  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…


118

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

n  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.


119

+La verifica della safety

n  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

n  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


120

+Limiti del controllo della safety

n  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

n  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


121

+Documento che attesti la safety di un prodotto

n  Il documento relativo alla safety del prodotto “A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment” [Bishop and Bloomfield 1998]

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

n  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)


122

+Di chi è la responsabilità del controllo

n  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à

n  Le verifiche di collaudo saranno tanto più semplici e con basso livello di contenzioso quanto più saranno state seguite alcune regole: n  Aver definito specifiche chiare in fase di ordine e di analisi n  Aver utilizzato specifiche oggettivabili e misurabili

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


123

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

n  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…

n  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


124

+Test di regressione in caso di sostituzione del sistema

n  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


125

Attività successive al rilascio del prodotto e al collaudo


126

+La gestione dei guasti e dei malfunzionamenti

n  Già in fase di progettazione occorre tenere conto che, qualora il software sia impiegato in contesti mission critical – e il software ad uso sanitario può esserlo nel caso sia safety critical -, sarà indispensabile progettare le strategie di backup in caso di completo blocco e le strategie di gestione in caso di funzionamento parziale o degradato

n  La definizione degli scenari di contingenza e delle strategie conseguenti, avendo quasi sempre delle implicazioni organizzative va gestita con chi utilizza il prodotto

n  Ogni strategia progettata va verificata in termini di sostenibilità organizzativa


127

+La gestione delle modifiche del contesto

n  Come accennato precedentemente il buon funzionamento del software dipende fortemente dal contesto nel quale il software è annegato

n  Qualora il contesto cambi, possono non essere più rispettati i criteri di sicurezza stabiliti in fase di progettazione, quindi il software va riverificato

n  La verifica è una attività lenta ed onerosa – in termini di competenze da mettere in campo e quindi di risorse economiche da impiegare – per cui va ridotta allo stretto indispensabile, ciò è possibile solo se il software è stato concepito in maniera modulare e se non esistono o esiste una probabilità molto bassa di “side effects” fra i diversi moduli


128

+ Documentazione delle misure di contingenza e backup

n  È necessario disporre del manuale delle misure di contingenza e di backup da attuare in caso di guasti e malfunzionamenti

n  I manuali devono essere approvati dalla direzione che in questo modo ne attesta l’adozione e la sostenibilità organizzativa

n  È necessario disporre delle evidenze che attestino che il personale è stato addestrato alla procedure di backup e alle manovre di contingenza


129

+Documentazione relativa alla sicurezza

Si propone di seguito una check list di documentazione minima che l’utilizzatore di un software ad uso sanitario con criticità di safety è tenuto ad avere:

n  Documento che attesti la safety del prodotto in condizione di produzione – che può recepire tutte le considerazioni relative al test sulla safety fatto dal produttore, ma che non si può limitare a questo –

n  Documento che attesti la reliabitiy del prodotto in condizioni di produzione

n  Documento che attesti l’addestramento degli operatori all’uso del programma e la loro informazione sulla destinazione d’uso dell’applicativo

n  I test sopra elencati sono i classici test in grande in cui si verificano le integrazioni dei vari moduli e le caratteristiche di sistema complessive e comprensive del contesto di produzione, ogni test presso il produttore non può essere considerato un test in grande definitivo a causa dell’importanza del contesto finale in cui si opera.


130

+L’aggiornamento della documentazione di sicurezza

n  I documenti che l’utilizzatore è tenuto ad avere, relativi alla sicurezza del software e le procedure di backup e di contingenza, devono essere aggiornati relativamente alle varie modifiche applicative e di contesto

n  L’aggiornamento della documentazione è una attività assai onerosa se è da condurre su originali cartacei, per cui è auspicabile che la documentazione sia tenuta in formato elettronico e che siano gestite le liste di distribuzione delle varie revisioni conformemente alla gestione delle abilitazioni applicative


131

+Audit ordinati dal committente

n  Il committente che voglia dimostrare una piena diligenza nella conduzione di attività pericolose quale l’utilizzo di applicativi sanitari che possono presentare pericoli per la safety del paziente, potrà periodicamente ordinare controlli da parte di terze parti – audit – che, partendo dalla documentazione precedentemente descritta, verificheranno la rispondenza di quanto dichiarato con l’assetto organizzativo e l’effettiva safety e reliability del sistema con controlli a campione o con analisi dei log di sistema


132

L’anima del guerriero…


133

Sunzi Disse:

Gli abili guerrieri dell’antichità agivano innanzitutto in modo da non poter essere vinti, e attendevano il momento in cui poter vincere il nemico. Dal momento che l’invincibilità dipende da noi stessi e che il suo opposto dipende dall’avversario, gli abili guerrieri possono rendersi invincibili ma non possono far sì che il nemico sia sicuramente sconfiggibile.



134

Grazie Quest'opera è stata rilasciata con licenza Creative Commons Attribuzione 3.0 Italia. Per leggere una copia della licenza visita il sito web http://creativecommons.org/licenses/by/3.0/it/ o spedisci una lettera a Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.


135

Documents

Project Management in Sanità - UNIMOREdidattica.agentgroup.unimore.it › didattica › cdl › Lab... · Gli strumenti a disposizione per l’analisi iniziale ! La fase iniziale