A A 2009 2010 Simone Brienza Daniele Giannetti

A. A. 2009 -2010 Simone Brienza Daniele Giannetti CBR RISK MANAGEMENT SYSTEM 1

Introduzione Sistema Intelligente avente lo scopo di assistere l’esperto aziendale nel processo di gestione e controllo dei rischi Il processo aziendale di gestione dei rischi è un processo complesso che viene in genere condotto dall’uomo in modo euristico, guidato fortemente dall’esperienza del personale che se ne occupa. Per gestire opportunamente i rischi dei progetti in azienda si usa la conoscenza acquisita grazie ai progetti passati. Il CBR (Case Based Reasoning) risulta allora il metodo di inferenza più adatto ad affrontare il problema, riproducendo fedelmente il modo in cui l’esperto umano ragiona per gestire opportunamente i rischi. 2

Introduzione Il sistema ha due funzioni principali: 1. Dato un nuovo progetto, sfruttando i casi passati presenti in una opportuna base di conoscenza, fornire i rischi che andrebbero gestiti nel progetto assieme alle azioni consigliate, costo potenziale dei rischi, efficacia prevista delle azioni consigliate, costo previsto delle azioni consigliate, ecc… 2. Durante lo svolgimento del progetto in azienda, tenere traccia dell’evoluzione dello stesso per assistere il personale nella gestione dei rischi. Inoltre conservare i dati relativi a tutti i progetti passati (anche se non significativi come casi per le future inferenze) allo scopo di sostituire interamente il precedente sistema di gestione delle informazioni sui progetti. 3

Introduzione Il sistema si divide in 3 moduli che interagiscono tra loro: Ø Modulo di Gestione della Conoscenza (Knowledge Module) Ø Modulo di Inferenza (Inference Module) Ø Modulo di Interfaccia (Interface Module) Ad alto livello la struttura risulta la seguente: 4

Modulo di Gestione della Conoscenza Interagisce con un database che mantiene tutte le informazioni necessarie al funzionamento del sistema, in particolare il database si divide in due componenti: a. Base di Conoscenza (Knowledge Base): Contenente tutte le informazioni relative ai casi passati che vengono usati dal sistema nel processo di inferenza per la gestione dei rischi dei nuovi progetti sottoposti al sistema. b. Progetti che non costituiscono casi: Contenente tutte le informazioni relative a progetti passati che non vengono usati dal sistema nel processo di inferenza, vengono conservati solamente per necessità aziendali e non perché utili in qualche modo al sistema. Le due componenti sono mescolate all’interno del database My. SQL relazionale che si è realizzato, vengono distinte tramite appositi flag presenti nel database come normali attributi. 5

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Ogni oggetto che viene conservato come un insieme di tuple nella base di dati ha una appropriata rappresentazione in memoria, essa viene utilizzata dal sistema per lavorare sull’oggetto stesso. Vediamo solamente i campi principali per ogni oggetto, evitando di evidenziare elementi utili solo a scopo implementativo. Specifiche di un rischio (tipo Risk) • risk_ID • risk_CL_code • category • description • causes • effects • rel_risk ID del rischio nel sistema ID nella checklist aziendale del rischio Nome di categoria Descrizione Lista di cause Lista di effetti Flag “rischio di impatto relativo al valore del progetto” 6

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Specifiche di un’azione di mitigazione (tipo Mit_Action) • mitigation_ID • action_CL_code • description • rel_act ID dell’azione di mitigazione nel sistema ID dell’azione nella checklist aziendale Descrizione Flag “azione di costo relativo al valore del progetto” Specifiche di un’azione di recovery (tipo Rec_Action) • recovery_ID • action_CL_code • description ID dell’azione di recovery nel sistema ID dell’azione nella checklist aziendale Descrizione 7

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Azione di mitigazione nell’ambito di un progetto (tipo Proj_Mit_Action) • mitigation_ID • cost • description • revision • state Stato dell’azione di mitigazione Lega l’azione alla sua specifica nel DB Costo dell’azione (percentuale o in euro) Descrizione dell’azione nello specifico progetto Revisione in cui l’azione ha avuto il suo effetto Stato dell’azione di mitigazione Pianificata (planned) In corso (active) Conclusa (closed) Azione di recovery nell’ambito di un progetto (tipo Proj_Rec_Action) • recovery_ID • description Lega l’azione alla sua specifica nel DB Descrizione dell’azione nello specifico progetto 8

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Legame rischio - azione di mitigazione nell’ambito di un progetto (tipo Proj_Mit_Bind) • action • imp_eff • prob_eff Proj_Mit_Action legata al rischio nel progetto Efficacia sul costo potenziale impatto del rischio Efficacia sulla probabilità del rischio Legame rischio - azione di recovery nell’ambito di un progetto (tipo Proj_Rec_Bind) • action • risk_cont • original_RI Proj_Rec_Action legata al rischio nel progetto Contingency per il recovery del rischio Valore originale di impact*probability del rischio 9

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Rischio nell’ambito di un progetto (tipo Proj_Risk) • risk_ID • company_risk_ID • strategy • state • revision • impact • probability • description • causes • effects • mit_actions • rec_action Lega il rischio alla sua specifica nel DB Identifica la coppia rischio – progetto in azienda Strategia da utilizzare per la gestione del rischio Stato del rischio Revisione in cui il rischio è stato inserito Storia del costo potenziale impatto del rischio Storia della probabilità del rischio Descrizione del rischio nello specifico progetto Cause del rischio nello specifico progetto Effetti del rischio nello specifico progetto Lista di Proj_Mit_Bind Oggetto di tipo Proj_Rec_Bind 10

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria • risk_ID • company_risk_ID • strategy • state • revision • impact • probability • description • causes • effects • mit_actions • rec_action Considerazioni: § Al massimo una azione di recovery per ogni rischio § Impact e Probability sono storie grazie alle azioni di mitigazione, per ogni elemento nella storia si tiene traccia della Proj_Mit_Action che ha modificato il valore (se la modifica non è stata fatta manualmente dall’utente) Strategia di gestione del rischio Spostamento (transfer) Mitigazione (mitigation) Accettazione (acceptance) Mitigazione e accettazione 11

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria • risk_ID • company_risk_ID • strategy • state • revision • impact • probability • description • causes • effects • mit_actions • rec_action Stato del rischio § § Monitoraggio (monitoring) Mitigazione (mitigation) Monitoraggio e Recovery Mitigazione e Recovery Chiuso e verificato Chiuso e non verificato Se si ha un’azione di recovery lo stato includerà sempre recovery. Monitoraggio o mitigazione dipende dallo stato delle azioni di mitigazione (se presenti). Lo stato closed_unverified (chiuso e non verificato) viene usato dall’utente per segnalare che la gestione del rischio si è conclusa anche se il rischio non si è verificato (qualunque sia il motivo). 12

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Progetto (tipo Project) • project_ID • revision • state • use_for_inference • features • risks • mit_actions • rec_actions Stato del progetto ID del progetto nel sistema Revisione attuale del progetto Stato del progetto Flag “progetto nella base di conoscenza” Insieme di attributi del progetto Lista di Proj_Risk nel progetto Lista di Proj_Mit_Action nel progetto Lista di Proj_Rec_Action nel progetto Attivo o aperto (active) Chiuso (closed) 13

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria Esempio di progetto completo in memoria: 14

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti in memoria L’insieme di attributi nei progetti (features) è configurabile tramite file di configurazione dall’utente che può allora decidere il numero e il tipo degli attributi oltre che, ovviamente, il loro valore per ogni particolare progetto. Tipi di attributi q Numerico [N] valore reale q Enumerato [E] valore letterale in uno specifico insieme q Stringa [S] valore stringa di caratteri q Percentuale [P] valore reale che indica una percentuale (es 5. 4 = 5. 4%) q Custom [C] valore letterale in uno specifico insieme dove vengono assegnate a discrezione dell’utente anche le somiglianze tra i possibili valori Attributi predefiniti sempre presenti • value [N] valore del progetto in euro • service_material [S] oggetto della fornitura • project_name [S] nome del progetto • customer_name [S] nome del cliente • company_ID [S] identificatore aziendale del progetto 15

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti nella base di dati Gli oggetti necessari al funzionamento del sistema vengono mantenuti dal modulo di gestione della conoscenza all’interno di un database relazionale My. SQL. Ogni oggetto viene rappresentato all’interno del database come un insieme opportuno di tuple dove ogni attributo corrisponde ad un campo dell’oggetto come rappresentato in memoria e ne contiene il valore. Opportuni vincoli di chiave esterna garantiscono che ogni transazione che altera il contenuto della base di dati in modo non significativo non venga accettata dal Database Management System (DBMS). Il DBMS utilizzato per il database del sistema è My. SQL, inoltre come storage engine si utilizza Inno. DB (motore completamente transaction oriented che consente di ottenere la robustezza desiderata) 16

Modulo di Gestione della Conoscenza Rappresentazione degli oggetti nella base di dati Vi sono oggetti mantenuti all’interno del database che non sono stati presentati nella parte relativa alla rappresentazione degli oggetti in memoria. In particolare: Ø Valori dei parametri utilizzati dal modulo di inferenza Ø Attributi configurati dall’utente per l’insieme features e relativi gruppi di appartenenza (contiene anche quelli predefiniti) Ø Copie dei progetti in stato attivo (usati dal modulo di inferenza) 17

File di Configurazione e Parsing Il sistema risulta completamente configurabile tramite l’utilizzo di opportuni file di configurazione. La configurazione avviene (trascurando guasti o casi eccezionali) solamente una volta al primo avvio del sistema. In questo processo si utilizzano 3 diversi file di configurazione che devono essere stati scritti dall’utente prima di lanciare il sistema. I File di configurazione sono: 1. init. conf contenente tutti gli attributi configurati dall’utente nell’insieme features, i gruppi di attributi decisi dall’utente e i valori dei parametri per l’inferenza 2. specs. conf contenente le specifiche di rischi, azioni di mitigazione e azioni di recovery disponibili inizialmente al sistema (se ne potranno aggiungere altre tramite interfaccia grafica) 3. projects. conf progetti che vengono forniti al sistema come conoscenza iniziale, vanno a formare l’insieme dei casi su cui applicare il CBR all’inizio dell’utilizzo del sistema. 18

Modulo di Inferenza Ha due funzioni fondamentali: 1. Case Based Reasoning sui nuovi progetti inseriti dall’utente Dato un nuovo progetto di cui sono noti gli attributi, il sistema fornisce i rischi significativi che affliggono il nuovo progetto con i relativi parametri, le azioni di mitigazione consigliate con la relativa efficacia prospettica e costo, e le azioni di recovery raccomandate. 2. Gestione della chiusura di un progetto Prima della chiusura di un progetto attivo, esso costituisce sempre un caso utile al CBR di cui sopra. Quando invece un progetto si chiude, dobbiamo decidere se il progetto risulta sufficientemente significativo da essere memorizzato definitivamente come caso utile al CBR. 19

Modulo di Inferenza Case Based Reasoning Il processo di inferenza si articola in 5 fasi distinte per associare ad un progetto di cui sono noti gli attributi i relativi rischi, azioni di mitigazione e di recovery. Il Case Based Reasoning viene influenzato da alcuni parametri configurabili tramite file di configurazione al primo avvio del sistema, e tramite interfaccia grafica nelle successive esecuzioni. Le fasi del processo di inferenza sono: Fase 1. Fase 2. Fase 3. Fase 4. Fase 5. Estrazione dei progetti simili Ranking dei progetti estratti Identificazione e adattamento dei rischi Identificazione e adattamento delle azioni di mitigazione e recovery Validazione dei risultati del sistema 20

Modulo di Inferenza Case Based Reasoning Per comprendere le varie fasi facciamo riferimento ad un esempio, ipotizzando che nella base di conoscenza siano presenti solamente i due progetti seguenti Progetto 1 Progetto 2 Nuovo progetto Dove enum assume valori naturali da 1 a 5 21

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili • L’utente seleziona un’insieme di attributi da utilizzare per effettuare l’estrazione e assegna loro dei pesi. • Gli attributi selezionati vengono divisi nei gruppi configurati dall’utente nei file di configurazione. • Per ogni progetto, si calcola un grado di somiglianza col nuovo progetto per ogni gruppo di cui è stato selezionato almeno un attributo. Grado di somiglianza del progetto i-esimo per il gruppo j-esimo = GSijnn • GSijnn viene calcolato come somma di vari contributi, uno per ogni attributo selezionato nel gruppo j. Questi vengono chiamati livelli di somiglianza (LS) e si pesano nella sommatoria con il peso specificato dall’utente per l’attributo. • Si scelgono dunque per ogni gruppo i progetti più simili, troncando le liste ottenute grazie al parametro MAX_PROJ_PER_GROUP configurato dall’utente. 22

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili La formula utilizzata per il calcolo del grado di somiglianza in questo contesto è: Il modo in cui si ricava LSki dipende dal tipo dell’attributo k-esimo: Ø Attributo stringa [S]: 1 se la stringa è la stessa, 0 altrimenti Ø Attributo enumerato [E]: LSki = 1 - LDki Ø Attributo percentuale [P]: LSki = 1 - LDki Ø Attributo custom [C]: si legge dalla matrice di somiglianza M fornita dall’utente 23

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili Ø Attributo numerico [N]: LSki = 1 - LDki (0 minimo) La differenza tra il valore dell’attributo nell’i-esimo progetto estratto dalla base di dati e il nuovo progetto è la seguente: Dove R 1 e R 2 sono configurabili dall’utente al lancio dell’inferenza direttamente da interfaccia grafica. 24

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili In pratica allora per un attributo numerico è possibile dare il seguente andamento di LSki, dove l’utente è in grado di alterare la forma del triangolo fissando i valori di V 1 e V 2 (e di conseguenza quelli di R 1 e R 2). 25

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili Considerando il nostro esempio con due soli progetti, supponendo che i due attributi value ed enum facciano parte dello stesso gruppo (unico) G 1 e di utilizzare peso unitario per entrambi gli attributi, abbiamo: Nuovo Progetto value = 2500 e enum = 4 Progetto 1 value = 5000 e enum = 2 GS 11 nn = 0. 5 (enum) + 0. 0 (value, R 1 = R 2 = 1250) = 0. 5 Progetto 2 value = 2000 e enum = 5 GS 21 nn = 0. 75 (enum) + 0. 6 (value, R 1 = R 2 = 1250) = 1. 35 Il progetto 2 risulta allora più simile considerando gli attributi per l’estrazione, e viene scelto per primo per entrare a far parte della tabella dei progetti estratti 26

Modulo di Inferenza Case Based Reasoning Fase 1: Estrazione dei progetti simili In generale al termine della fase di estrazione avremo organizzato i progetti estratti in una tabella dei progetti estratti, avente la seguente forma: Nel nostro esempio in particolare la struttura sarà la seguente: 27

Modulo di Inferenza Case Based Reasoning Fase 2: Ranking dei progetti estratti • Il ranking dei progetti estratti avviene (logicamente) solo dopo che si è completata l’estrazione, esso avviene sempre attraverso un confronto su vari attributi. • L’utente può decidere di effettuare un ranking usando anche la somiglianza che è stata ricavata in fase di estrazione (extraction based ranking), oppure può ignorare la somiglianza calcolata nella fase precedente. • Si possono scegliere nuovi attributi (eventualmente già usati in fase di estrazione) e nuovi pesi con cui si vuole fare ranking dei progetti estratti. • Usando i nuovi attributi selezionati e, se si sta facendo extraction based ranking, anche quelli usati in fase di estrazione, si calcola un nuovo grado di somiglianza in fase di ranking Grado di somiglianza per il ranking del progetto i-esimo nel gruppo j-esimo = GSijnn rank Dal punto di vista implementativo la fase 2 avviene nello stesso momento della fase 1: si calcolano i due gradi di somiglianza in parallelo. 28

Modulo di Inferenza Case Based Reasoning Fase 2: Ranking dei progetti estratti Il grado di somiglianza per il ranking si calcola dunque come segue: Ø Extraction based ranking Ø Altrimenti Dove i livelli di somiglianza si calcolano esattamente come visto in precedenza. Al termine della fase di ranking allora si memorizza nella tabella dei progetti estratti un grado di somiglianza. Questo grado di somiglianza è quello che verrà utilizzato fino al termine dell’inferenza per un progetto nell’ambito di un particolare gruppo, e influenza dunque tutte le decisioni che verranno svolte dal sistema a valle della fase 2. 29

Modulo di Inferenza Case Based Reasoning Fase 2: Ranking dei progetti estratti Il grado di somiglianza che viene memorizzato è esattamente il grado di somiglianza per il ranking, il quale viene però prima normalizzato tra 0 ed 1. Ø Extraction based ranking Ø Altrimenti Questo numero tra 0 ed 1 è quello a cui ci riferiamo da ora in avanti con “grado di somiglianza”, somiglianza indicato con l’espressione GSij. 30

Modulo di Inferenza Case Based Reasoning Fase 2: Ranking dei progetti estratti Per quanto riguarda l’esempio in esame, si assume di non selezionare alcun nuovo attributo per il ranking. Si utilizza invece l’extraction based ranking solamente con gli attributi specificati per l’estrazione. Progetto 1 GS 11 nn rank = GS 11 nn = 0. 5 GS 11 = GS 11 nn/2 = 0. 25 GS 11 = 0. 25 Progetto 2 GS 21 nn rank = GS 21 nn = 1. 35 GS 21 = GS 21 nn/2 = 0. 675 GS 21 = 0. 675 Forma finale della tabella dei progetti estratti 31

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi Ci proponiamo ora di identificare i rischi che affliggono il nuovo progetto a partire dai progetti che risultano simili allo stesso, adattandone i parametri. a) Si scorrono tutti i progetti nella tabella dei progetti estratti, gruppo per gruppo. Per ogni rischio incontrato all’interno dei progetti si conserva un contatore che mantiene la cumulata dei valori dei GSij dei progetti incontrati nella tabella contenenti tale rischio. • Un progetto può essere incontrato diverse volte se presente nelle liste di diversi gruppi. • Il contatore che accumula i GSij si dice grado di appartenenza del rischio al nuovo progetto e si indica GAh (rischio h-esimo). Maggiore è il valore finale di GAh e maggiore è la misura in cui il rischio si può presentare nel nuovo progetto. 32

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi • Durante lo scorrimento si costruisce una struttura che lega ogni rischio incontrato ai progetti nella tabella dei progetti estratti in cui compare (con il relativo grado di appartenenza). La struttura prende il nome di struttura rischio - progetto. Nell’esempio presentato la struttura avrà la seguente forma Questa struttura è utile per adattare in modo semplice ed efficace i parametri dei rischi recuperati al nuovo progetto 33

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi b) Si adattano la probabilità e l’impatto dei rischi recuperati al nuovo progetto. Si prendono in considerazione solamente i valori iniziali negli storici perché si cercano appunto i valori iniziali prima dell’effetto di qualunque azione di mitigazione. Per farlo si scorre per ogni rischio la lista contenuta nella struttura precedente e, considerando il rischio in esame all’interno di ogni elemento, si applicano le seguenti formule: Probabilità e impatto iniziali del rischio h-esimo all’interno del nuovo progetto 34

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi c) Si calcola adesso per ogni rischio recuperato l’Indice di Rischio (RI) ad esso associato nel nuovo progetto come segue (rischio h-esimo, impatto in euro): Si scartano tutti i rischi aventi indice di rischio inferiore ad una soglia predeterminata MIN_RI_THRESHOLD configurabile dall’utente. In questo modo si eliminano subito tutti i rischi poco rilevanti anche se magari molto affini al progetto in esame. d) Si scelgono a questo punto i primi MAX_RISKS_PER_PROJ rischi con GAh più elevato, dove comunque si da libertà all’utente di scremare ancora di più l’insieme dei rischi utilizzando una semplice ed intuitiva interfaccia grafica. Si ripulisce inoltre la struttura rischio - progetto da tutti i rischi scartati. 35

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi Eseguiamo allora la procedura per il semplice esempio in esame. a) Rischio 1 GA 1 = GS 11 + GS 21 = 0. 675 + 0. 25 = 0. 925 Rischio 2 GA 2 = GS 21 = 0. 675 Struttura rischio-progetto b) Rischio 1 Prob 1 ≈ 34. 6% (spostata verso il progetto 2) Impa 1 ≈ 28. 1% (spostato verso il progetto 2) Rischio 2 Prob 2 = 50% (pari al caso 2, unico dato) Impa 2 = 50% (pari al caso 2, unico dato) 36

Modulo di Inferenza Case Based Reasoning Fase 3: Identificazione e adattamento dei rischi c) RI 1 = [value * Impa 1/100] * Prob 1/100 ≈ 243. 06 euro RI 2 = [value * Impa 2/100] * Prob 2/100 = 625. 00 euro Ipotizziamo che nessun rischio venga filtrato grazie al valore di MIN_RI_THRESHOLD. d) Ipotizziamo che entrambi I rischi vengano scelti dall’utente come rischi nel nuovo progetto. La struttura che il nuovo progetto assume al termine della terza fase risulta in definitiva: Lo stato e la strategia di gestione dei rischi sono ignote fintanto che non si conoscono le azioni ad essi associate. 37

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Azioni di mitigazione a) Per ogni rischio nel nuovo progetto si scorre la relativa lista nella struttura rischio - progetto esaminando le azioni di mitigazione che vengono usate per gestire il rischio. Si scelgono per l’inserimento nel nuovo progetto: • Azioni aventi efficacia media su probabilità ed impatto superiore ad una certa soglia e stato chiuso, tali inoltre che il rischio a cui sono collegate soddisfa opportune condizioni (vedere documentazione). • Azioni che non soddisfano il criterio sopra, ma che hanno un peso (derivante dal numero di volte in cui vengono incontrate, dall’efficacia dell’azione, dallo stato dell’azione, dal grado di somiglianza del progetto e dall’indice del rischio che l’azione mitiga) sufficientemente alto (vedere documentazione). Il peso minimo per il quale l’azione viene effettivamente inserita nel nuovo progetto dipende dall’utente, che opera intuitivamente su questo parametro tramite un’opportuna interfaccia grafica. 38

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Durante lo scorrimento si costruisce una struttura azione di mitigazione - rischio che collega ogni azione infine scelta per l’inserimento nel nuovo progetto con i rischi che è in grado di mitigare e per ognuno di essi con tutti gli elementi nella tabella dei progetti estratti in cui effettivamente ciò avviene. Per il caso scelto come esempio tale struttura avrà la seguente forma (con una sola azione di mitigazione) 39

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. b) Si calcola l’efficacia prospettica in termini di probabilità ed impatto delle azioni che si inseriscono nel nuovo progetto per ognuno dei rischi a cui esse vengono legate (tutti quelli che sono in grado di mitigare). Per fare questa operazione si scorre ogni lista di ogni sottoalbero della struttura azione di mitigazione – rischio. Considerando in ogni elemento il Proj_Mit_Bind che lega il rischio in testa alla lista all’azione radice del sottoalbero, si applicano le seguenti formule per ricavare l’efficacia prospettica sull’impatto e sulla probabilità nel nuovo progetto. Efficacia prospettica sulla probabilità Efficacia prospettica sull’impatto 40

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. c) Si calcola il costo stimato di ogni azione di mitigazione nel nuovo progetto basandoci al solito sul costo osservato nei casi passati. Questa operazione viene fatta in modo semplice recuperando e facendo la media pesata di tutti i costi che l’azione ha avuto in passato, i quali si recuperano dalla tabella dei progetti estratti. Come peso per la media al solito si utilizza il grado di somiglianza, come evidenziato nella formula a destra. 41

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Nell’esempio considerato si hanno i seguenti passi a) Supponiamo che l’efficacia media dell’unica azione venga trovata maggiore della soglia: l’azione viene aggiunta direttamente al nuovo progetto senza calcolare pesi. Struttura azione di mitigazione - rischio b) Legame azione 1 - rischio 1 prob_eff 11 ≈ 34. 6% (spostata verso il progetto 2) impa_eff 11 ≈ 34. 6% (spostata verso il progetto 2) Legame azione 1 - rischio 2 prob_eff 12 = 20% (pari al caso 2, unico dato) impa_eff 12 = 60% (pari al caso 2, unico dato) 42

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. c) Per comodità riportiamo la tabella dei progetti estratti: cost 1 ≈ 691. 89€ La situazione del nuovo progetto a questo punto è la seguente 43

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Azioni di recovery a) Per ogni rischio nel nuovo progetto si scorre la relativa lista nella struttura rischio - progetto esaminando le azioni di recovery che sono state usate per gestire il rischio. Ad ogni azione di recovery incontrata si associa un peso per ogni rischio che essa in passato è stata in grado di recuperare. Il peso viene calcolato durante lo scorrimento della struttura rischio - progetto e dipende da quante volte l’azione risulta recuperare il rischio, dal grado di somiglianza del progetto dove ciò accade, e da quanto l’azione risulta avere una contingency piccola rispetto al valore di partenza per essa, ricavabile a partire da original_RI come segue: Dove K è un parametro di inferenza configurabile dall’utente. Vedere la documentazione per maggiori dettagli. 44

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Durante lo scorrimento si costruisce una struttura azione di recovery - rischio che collega ogni azione con i rischi che è in grado di recuperare e per ognuno di essi con tutti gli elementi nella tabella dei progetti estratti in cui effettivamente ciò avviene. b) Per ogni rischio nel nuovo progetto si sceglie l’azione di recovery avente peso maggiore per il suo recupero, in questo modo può anche accadere che diversi rischi siano legati alla stessa azione di recovery. In questa fase si eliminano anche tutti i legami azione di recovery rischio presenti nella struttura azione di recovery - rischio che non vengono aggiunti al nuovo progetto Struttura azione di recovery rischio finale per l’esempio in esame (una sola azione di recovery in un unico caso): 45

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. c) Si calcola la contingency che ogni azione di recovery comporta per ciascun rischio a cui essa è legata. Per fare questa operazione si scorre ogni lista di ogni sottoalbero della struttura azione di recovery - rischio residua. Considerando in ogni elemento il Proj_Rec_Bind che lega il rischio in testa alla lista all’azione radice del sottoalbero, si applica la seguente formula per ricavare la risk_contingency: Si lavora dunque in modo differenziale mediando la distanza dal valore di partenza, pesata con i gradi di somiglianza, dove: 46

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Nel caso preso come esempio allora si hanno i seguenti passi a-b) l’unica azione di recovery presente nella struttura rischio – progetto è la Rec_Action 1, essa sarà l’unica a venire inserita nel nuovo progetto per recuperare il rischio 1 Struttura azione di recovery – rischio finale c) Ipotizziamo K = 1. 0 Legame azione 1 - rischio 1 original_RI 11 ≈ 9. 72% risk_cont 11 ≈ 4. 72% 47

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Stato dei rischi Per ogni rischio nel nuovo progetto si può adesso fissare lo stato e la strategia, sono infatti note le azioni di mitigazione e recovery ad esso legate. Per l’esempio in esame abbiamo: • rischio 1 strategia = mitigation and acceptance stato = monitoring and recovery • rischio 2 strategia = mitigation stato = monitoring 48

Modulo di Inferenza Case Based Reasoning Fase 4: Identificazione e adattamento delle azioni di mit. e rec. Nuovo progetto al termine dell’inferenza di esempio: 49

Modulo di Inferenza Case Based Reasoning Fase 5: Validazione dei risultati del sistema In questa fase si presentano all’utente i risultati dell’inferenza tramite interfaccia grafica. All’utente sono adesso concesse modifiche arbitrarie ai risultati dell’inferenza, in particolare le modifiche si possono apportare si dividono in tre diverse categorie: A. Eliminazione di componenti B. Modifica di componenti C. Aggiunta di componenti Una lista completa delle correzioni facenti parte di ogni categoria è disponibile nella documentazione del CBR Risk Management System. Molte modifiche sono possibili anche post-validazione, anche se vengono trattate dal sistema in modo leggermente diverso. 50

Modulo di Inferenza Chiusura di progetti Il modulo di inferenza si occupa anche di gestire opportunamente la chiusura di un progetto in stato attivo. Al termine della fase 4 (prima della validazione) si memorizza nella base di dati il risultato dell’inferenza esattamente come restituito dal processo di inferenza. Questo progetto “copia” non fa parte della base di conoscenza e non verrà usato come caso nelle future inferenze. Il progetto, una volta validato, viene poi inserito normalmente nella base di conoscenza come caso significativo per le future inferenze. Il progetto copia viene utilizzato dal modulo di inferenza in fase di chiusura per valutare quali cambiamenti ha subito il progetto durante la sua attività (sia in fase di validazione che post-validazione). Se il progetto in chiusura risulta troppo simile al progetto copia allora si rimuove dalla base di conoscenza (tenendolo comunque nella base di dati). 51

Modulo di Inferenza Chiusura di progetti In particolare, si esaminano tutte le differenze tra il progetto in chiusura e il progetto copia presente nella base di dati, dando un peso a ciascuna di esse e calcolando allora una cumulata (sia essa mod_count). mod_count Al termine del confronto: Ø mod_count ≥ MOD_THRESHOLD Si lascia nella base di conoscenza il progetto, dopo averlo chiuso. Ø mod_count < MOD_THRESHOLD Si rimuove il progetto in chiusura dalla base di conoscenza, lasciandolo comunque nella base di dati (non è più un caso). In ogni caso il progetto copia è rimosso dalla base di dati una volta terminata la chiusura. MOD_THRESHOLD è un parametro di inferenza configurabile dall’utente tramite file di configurazione o interfaccia grafica. Vedere la documentazione per maggiori dettagli su come viene effettivamente calcolata la cumulata che poi viene confrontata con MOD_THRESHOLD 52

Modulo di Inferenza Chiusura di progetti Dato il particolare modo in cui il sistema decide se creare o meno dei nuovi casi alla chiusura dei progetti, è ovvio che se l’utente non modifica mai il risultato del sistema allora non si avrà mai apprendimento del sistema. L’apprendimento del CBR Risk Management System avviene grazie all’esperto umano che, operando sulla risposta del sistema adattandola alla sua esperienza, produce nuova conoscenza che viene memorizzata dal sistema stesso. Il sistema ha la capacità di produrre dei nuovi risultati dati progetti lontani da tutti i casi nella base di casi. E’ inutile memorizzare i suddetti risultati se l’utente non apporta alcuna modifica in quanto comunque essi non rappresentano nuova conoscenza utile all’inferenza: una seconda presentazione dello stesso caso o un caso simile produce comunque una risposta simile per la conoscenza già nota al sistema. 53

Modulo di Interfaccia Interagisce con l’utente allo scopo di consentire un facile utilizzo di tutte le funzionalità del CBR Risk Management System, inoltre dialoga con il modulo di inferenza e col modulo di gestione della conoscenza allo scopo di soddisfare le richieste dell’utente. Le funzionalità di questo modulo sono molteplici e solamente alcune sono state realizzate nell’implementazione proposta. Le funzionalità previste si possono dividere in alcuni blocchi: A. Funzionalità relative a modifiche post-validazione di progetti aperti B. Aggiunta di specifiche di azioni e rischi C. Presentazione di un nuovo progetto al sistema e gestione dell’interazione durante il processo di inferenza CBR D. Recupero e gestione di progetti in corso E. Browsing e cancellazione di progetti chiusi F. Rebuild della base di dati G. Configurazione dei parametri di inferenza (che dunque può avvenire anche tramite interfaccia grafica oltre che grazie ai file di configurazione al primo avvio del sistema) Fare riferimento alla documentazione fornita per una lista completa delle funzionalità del modulo di interfaccia. 54

Implementazione Il modulo di gestione della conoscenza ed il modulo di inferenza sono stati implementati in modo completo. Solo alcune funzionalità del modulo di interfaccia sono state implementate. In particolare, sono disponibili sono alcune schermate. Ø Schermata principale della GUI 55