A.A.
2009-2010
Simone Brienza
Daniele Giannetti
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 MySQL
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
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
 Numerico [N]  valore reale
 Enumerato [E]  valore letterale in uno specifico insieme
 Stringa [S]  valore stringa di caratteri
 Percentuale [P]  valore reale che indica una percentuale (es 5.4 = 5.4%)
 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
MySQL.
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 è MySQL, inoltre come storage
engine si utilizza InnoDB (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 R1 e R2 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 V1 e V2 (e di conseguenza quelli di R1 e R2).
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) G1 e di
utilizzare peso unitario per entrambi gli attributi, abbiamo:
Nuovo Progetto  value = 2500 e enum = 4
Progetto 1  value = 5000 e enum = 2
GS11nn = 0.5 (enum) + 0.0 (value, R1 = R2 = 1250) = 0.5
Progetto 2  value = 2000 e enum = 5
GS21nn = 0.75 (enum) + 0.6 (value, R1 = R2 = 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”, 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  GS11nn rank = GS11nn = 0.5
GS11 = GS11nn/2 = 0.25
GS11 = 0.25
Progetto 2  GS21nn rank = GS21nn = 1.35
GS21 = GS21nn/2 = 0.675
GS21 = 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  GA1 = GS11 + GS21 = 0.675 + 0.25 = 0.925
Rischio 2  GA2 = GS21 = 0.675
Struttura rischio-progetto
b)
Rischio 1
Prob1 ≈ 34.6% (spostata verso il progetto 2)
Impa1 ≈ 28.1% (spostato verso il progetto 2)
Rischio 2
Prob2 = 50% (pari al caso 2, unico dato)
Impa2 = 50% (pari al caso 2, unico dato)
36
Modulo di Inferenza
Case Based Reasoning
Fase 3: Identificazione e adattamento dei rischi
c) RI1 = [value * Impa1/100] * Prob1/100 ≈ 243.06 euro
RI2 = [value * Impa2/100] * Prob2/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_eff11 ≈ 34.6% (spostata verso il progetto 2)
impa_eff11 ≈ 34.6% (spostata verso il progetto 2)
Legame azione 1 - rischio 2
prob_eff12 = 20% (pari al caso 2, unico dato)
impa_eff12 = 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:
cost1 ≈ 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_RI11 ≈ 9.72%
risk_cont11 ≈ 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 che 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).
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
Implementazione
 Schermata di inserimento di un nuovo progetto
56
Implementazione
 Schermata di scelta degli attributi per estrazione e ranking
57
Implementazione
 Schermata di avanzamento del processo di inferenza
58
Implementazione
 Schermata di validazione dei risultati dell’inferenza
59