report tecnico - SERLab

Transcript

Prof. Giuseppe Visaggio
Università degli Studi di Bari - Dipartimento di Informatica
SERLAB (Software Engineering Research Laboratory) - Università degli Studi di Bari
SER & Practices s.r.l. - Spin off dell’Università degli Studi di Bari
Introduzione
KNOWLEDGE-EXPERIENCE BASE AND EXPERIENCE FACTORYERRORE. IL SEGNALIBRO NON È
DEFINITO.
1.
INTRODUZIONE ........................................................................................................3
2.
DATI, INFORMAZIONI, CONOSCENZA ED ESPERIENZA...........................................6
3.
3.1
3.2
3.3
3.4
STATO DELL’ARTE SULLA EB E LA EF .................................................................12
SCOPO E RAPPRESENTAZIONE DELLA EB ...................................................................12
SCOPO E RAPPRESENTAZIONE DELLA EXPERIENCE FACTORY ......................................13
INTERAZIONE TRA QIP ED EF. ..................................................................................15
EB ED EF NEI CONTESTI INDUSTRIALI .......................................................................17
4.
4.1
4.2
4.3
4.4
4.5
4.6
IMPLEMENTAZIONE DELLA EB IN KEB ...............................................................18
TIPI DI KEP .............................................................................................................19
STRUTTURA DEI CONTENUTI DEI KEP. ......................................................................19
CONTENUTI DEI KEP ...............................................................................................21
COMPONENTI DEL KEP............................................................................................22
RISORSE DEL KEP....................................................................................................25
I METADATI .............................................................................................................25
5.
5.1
5.2
5.3
5.4
PROMETHEUS ...................................................................................................26
PROJECT COMPONENT .............................................................................................29
TOOL COMPONENT ..................................................................................................31
EVIDENCE COMPONENT. ..........................................................................................32
COMPETENCE COMPONENT ......................................................................................34
6.
6.1
6.2
6.3
6.4
6.5
6.6
LINEE GUIDA PER LA PRODUZIONE.......................................................................35
PRODUZIONE E PUBBLICAZIONE. ..............................................................................35
TECNICA DI PRODUZIONE DI UN NUOVO KEP. ...........................................................36
ESPRESSIONI IDENTIFICATIVE ...................................................................................37
VERIFICA E VALIDAZIONE DEI PACCHETTI ..................................................................37
EVOLUZIONE DEI KEP. ............................................................................................38
COOPERAZIONE NELLO SVILUPPO. ............................................................................38
7.
7.1
7.2
VALORI DI PROMETHEUS .................................................................................39
SOGGETTI FISICI.......................................................................................................39
ORGANIZZAZIONI......................................................................................................40
8.
CONCLUSIONE .......................................................................................................42
9.
BIBLIOGRAFIA .......................................................................................................43
UNIBA - SERLAB – SER&PRACTICES
Software Engineering Research Universita degli Studi di
Bari Via Orabona, 4 c/o Dipartimento di informatica 70126 – Bari
http://serlab.di.uniba.it http://www.serandpractices.com
2/3
Introduzione
Sommario
Com’è noto, sempre più al centro dell’economia delle imprese e dei paesi c’è lo
sfruttamento della conoscenza. In questo capitolo sono esaminati alcuni modelli abilitanti per
la società della conoscenza: la produzione distribuita, l’open innovation ed i digital business
ecosystems. La trattazione pone particolare attenzione alle piccole e medie imprese; ma è
sufficientemente generale perché tutti i concetti possano essere adeguati anche alle grandi.
Per supportare tali modelli comportamentali si ipotizza l’uso della Fabbrica delle Esperienze
che raccoglie esperienze empiriche sottoforma di Pacchetti di Esperienza-Conoscenza.
L’innovazione più rilevante del capitolo sta proprio nella strutturazione di questi pacchetti
che si differenzia da altre già reperibili in letteratura. Le modifiche apportate alla
strutturazione hanno lo scopo di convincere i potenziali destinatari ad utilizzare i contenuti
dei pacchetti e favorirne l’adozione senza l’ausilio dell’autore o degli autori del pacchetto. La
strutturazione proposta ha come effetto collaterale, la possibilità di produrre il pacchetto
incrementalmente e cooperativamente. Le modifiche proposte sono derivate dalle lezioni
apprese in esperienze precedenti di trasferimento tecnologico. Tali lezioni apprese, nella
maggior parte, sono rilevate dalla letteratura ma sono anche derivate da esperienze
dell’autore. Nel capitolo è presentata la piattaforma PROMETHEUS che implementa tutte le
richieste per la raccolta e la distribuzione dei Knowledge-Experience Package.
1. INTRODUZIONE
La pressione competitiva per le imprese o per i paesi ha spostato il baricentro
dell’economia dal patrimonio (assets) materiale a quello immateriale. Acquisire vantaggio
comparativo su fattori immateriali richiede il rafforzamento della capacità di raccolta,
miglioramento continuo ed estensione del proprio patrimonio immateriale attraverso la filiera
della conoscenza. Il vantaggio comparativo di un ente pubblico, di un’impresa o di un
soggetto fisico (generalmente chiamato organismo, nel seguito del presente capitolo) basato
su fattori immateriali è più duraturo di quello basato sui fattori materiali. Infatti, è difficoltoso
colmare il gap di conoscenza che costituisce il vantaggio. Perciò, l’organismo che detiene il
vantaggio ha una più ampia finestra temporale per rafforzarlo e migliorarlo attraverso la
filiera di produzione della conoscenza prima che i concorrenti colmino lo svantaggio. Questo
ciclo virtuoso è alla base della società della conoscenza e dello sviluppo dei nuovi paradigmi
economici, scientifici e tecnologici richiesti da quest’ultima. Essa è caratterizzata dallo
sfruttamento della conoscenza come fattore predominante nella generazione della ricchezza
[16].
Per la limitatezza dello spazio disponibile in questo capitolo e per conferirgli una buona
leggibilità e comprensione è opportuno limitare il contesto che esso deve trattare all’interno
di questo vasto scenario. Perciò, questo capitolo considera gli aspetti di economia della
conoscenza nella prospettiva delle imprese. Più specificatamente, delle imprese produttrici ed
utilizzatrici di Information Technology (IT). Il capitolo tratta gli argomenti in modo generale
così che la maggior parte dei concetti e delle tecnologie esposte in questo capitolo possano
essere applicate in tutti i settori ad alta intensità di conoscenza; ma, di seguito si pone
particolare attenzione alle piccole e medie imprese (SME) perché esse hanno maggiori
difficoltà nel transitare verso l’economia della conoscenza e devono essere supportate perché
3/3
Introduzione
almeno nell’IT rappresentano non meno del 90% delle imprese operanti sull’intero globo
[18].
Tra i fattori abilitanti all’utilizzazione economicamente efficace della conoscenza in questo
capitolo si prende come guida l’acquisizione ed il rafforzamento delle capacità ad alto
contenuto tecnologico che costituiscono l’eccellenza e la diversità dell’organismo detentore
nel suo settore di business [17]. Infatti, la diversità dà il vantaggio comparativo, l’eccellenza
consente di trasformare tale vantaggio in opportunità di mercato. Per costituire e mantenere il
vantaggio comparativo e per trasformare questo in ritorni economici i modelli
comportamentali degli organismi interessati possono essere diversi e non esclusivi tra loro.
A causa delle dinamicità dei mercati sia nell’offerta che nella domanda, tali capacità
devono essere continuamente adeguate attraverso l’innovazione che deve essere frequente e
rapida. L’innovazione frequente richiede che l’organismo disponga di risultati di ricerca
originali nel suo dominio di business, sia capace di trasformarli tempestivamente in
innovazione tecnologica da adottare nei suoi processi di business e socializzi rapidamente la
nuova conoscenza prodotta in modo che le sue capacità restino eccellenti e distintive. Per
raggiungere questi obiettivi sono necessari notevoli investimenti. Ne segue l’opportunità per
ogni organismo di limitare il numero di capacità su cui puntare per realizzare l’eccellenza e la
diversità. L’estensione delle capacità di impresa eccellenti per ogni organismo si può regolare
sulla base della capacità di investimento e del numero di risorse umane di cui esso può
disporre. A minore estensione delle capacità di impresa eccellenti corrisponde minore
richiesta di risorse, umane e finanziarie, per sostenere la costituzione, il mantenimento ed il
continuo aggiornamento delle competenze che le supportano.
I risultati di ricerca sono prodotti da processi non prevedibili sia in termini economici che
di tempo, così come la loro trasformazione in innovazione.
Inoltre, le competenze specialistiche che con la ricerca e la conseguente socializzazione si
costituiscono all’interno di un organismo diventano attrattive per il mercato del lavoro e,
quindi, creano un rilevante rischio di turnover. Questi fatti rendono ad alto rischio gli
investimenti in ricerca e sviluppo. Per esempio, la perdita di un ricercatore implica la perdita
del patrimonio di conoscenza tacita che egli ha acquisito durante i processi di ricerca e
sviluppo a cui ha partecipato; oppure, l’imprevedibilità dei processi di ricerca rendono
rilevante il rischio di sbagliare la previsione degli investimenti e del tempo necessario per
ottenere risultati di ricerca soddisfacenti. Perciò, è opportuno passare dal modello di Closed
Innovation a quello di Open Innovation [11]. Nella Closed Innovation tutta la filiera della
conoscenza, dalla ricerca all’innovazione, è svolta all’interno di un organismo; invece, nella
Open Innovation ogni organismo mette a disposizione di altri i risultati di ricerca o le
tecnologie, prodotti con progetti di ricerca e sviluppo eseguiti e finanziati in proprio, che non
sono sfruttabili immediatamente per i suoi obiettivi strategici; invece, usa quelli messi a
disposizione da altri organismi per creare più rapidamente le innovazioni di cui necessita.
Rendere disponibili per altri la conoscenza prodotta con le proprie ricerche dà, all’organismo
conferente, la possibilità di un più rapido rientro degli investimenti effettuati in ricerca;
invece, sfruttare i risultati di ricerca di altri organismi rende maggiormente prevedibili i tempi
ed i costi dell’innovazione. Avendo la necessità di formalizzare i propri risultati di ricerca,
l’organismo deve mettere in atto accorgimenti per l’esplicitazione della conoscenza appresa
durante il lavoro (near-the-job learning). Inoltre, scambiando conoscenza con altri organismi
4/4
Introduzione
aumenta il numero di portata della stessa conoscenza; pertanto, diminuisce il rischio di
perdita del patrimonio di conoscenza.
Nonostante le economie realizzabili, grazie all’Open Innovation, l’acquisizione ed il
rafforzamento di capacità eccellenti risulta molto costoso. Questo si ripercuote nei costi delle
risorse che sostengono tali capacità e, quindi, nei costi dei progetti in cui queste risorse
operano. Per far fronte alla competizione è necessario diminuire i costi dei progetti, perciò si
adotta la distribuzione dei progetti, in particolare, si trasferiscono ad imprese con minore
costo del personale le attività con meno valore aggiunto (outsourcing o offshoring) e si
intrattengono all’interno del proprio organismo le attività che necessitano delle capacità di
eccellenza e che sono le più critiche e producono maggiore valore aggiunto. Con questo
modello comportamentale è anche possibile accelerare i processi di produzione e
manutenzione e, quindi, far fronte al time-to-market che per turbolenza del mercato deve
rispettare finestre temporali sempre più strette. Per adottare questo approccio gli organismi
interessati devono avere buone capacità di pianificazione e monitoraggio dei progetti. Inoltre,
devono avere strumenti per valutare le capacità dei fornitori oltre che di se stessi. Infine, nei
progetti distribuiti il rischio di turnover delle risorse umane aumenta e, quindi, l’adozione di
questo modello richiede la capacità di colmare rapidamente le competenze che dovessero
venire meno.
Qualche volta l’organismo titolare di un progetto non ha tutte le capacità eccellenti che
servono allo stesso progetto. In questi casi è necessario che esso cooperi alla pari con altri
organismi costituendo i, così detti, Digital Business Ecosystem [15]. In questo caso
l’organismo titolare del progetto è il committente e gli altri organismi che cooperano sono i
fornitori. E’ evidente che l’organismo committente in un BDE deve avere le capacità di
gestione dei progetti distribuiti. Per completezza, le grandi imprese adottano un paradigma
alternativo al DBE, senza escludere quest’ultimo, per acquisire capacità eccellenti
complementari a quelle che hanno al loro interno, attraverso processi di Merge &
Acquisition.
Nei modelli di comportamento precedenti, il comune denominatore che vuole analizzare
questo capitolo è la gestione della conoscenza. Attualmente è noto un modello di Experience
Factory (EF) che raccoglie conoscenza sperimentale in un repository denominato Experience
Base (EB) [10]. La EF mira a comprendere, pianificare e prevedere, controllare e verificare,
migliorare i processi di business. La raccolta della conoscenza sperimentale nell’Experience
Package (EP) ha lo scopo di ridurre le conseguenze della perdita di conoscenza per turn-over
delle persone che la possiedono in forma tacita, di migliorare prodotti e processi e di
apprendere dal lavoro eseguito per svolgere meglio i lavori da eseguire.
Questo capitolo propone un modello per la strutturazione del contenuto del Package,
riproducibile sistematicamente, con particolare orientamento alla esplicitazione delle pratiche
per l’adozione della conoscenza (sta per acquisizione o sfruttamento in un processo di
business) nell’organismo produttore oppure in organismi diversi da questo. L’organismo a cui
si fa riferimento può essere di ricerca oppure di produzione di prodotti o servizi. La struttura
è adeguabile a diversi tipi di contenuto e prevede che in uno stesso Package possano essere
espressi contenuti di diverso tipo, quali: risultati di ricerca, esperienza, strumenti, tecnologie
5/5
Dati, Informazioni, Conoscenza ed Esperienza
innovative. La struttura del Package è modulare ed esprime la relazione tra lo stato dell’arte a
cui le pratiche del package fanno riferimento, i risultati di ricerca, le pratiche, le esperienze di
adozione nei processi di business. L’esplicitazione dell’esperienza ha caratteristiche idonee a
convincere i potenziali utilizzatori dei valori generabili dalla adozione del Package. La
struttura del Knowledge-Experience Package prevede componenti utili all’accompagnamento
(drive) degli organismi utilizzatori nell’adozione dello stesso. Per evidenziare quanto detto
circa il suo contenuto, la conoscenza espressa secondo questa struttura si chiamerà di seguito
KEP. Il repository che conterrà i KEP si chiamerà, per simmetria, Knowledge-Experience
Base (KEB).
La proposta di questo capitolo è innovativa, rispetto alla letteratura ed alle altre basi di
conoscenza note, oltre che per la struttura del KEP anche perché le componenti di
quest’ultimo derivano dalle lezioni apprese, in parte pubblicate ed in parte rilevate
dall’esperienza dell’autore, circa la gestione della conoscenza ed il suo sfruttamento nei
processi di business. Infatti, il capitolo mostra che grazie alla struttura prospettata, la KEB
proposta, insieme con le attività convenzionali della EF, è un buon supporto per ogni
organismo che voglia operare nell’economia della conoscenza con i modelli comportamentali
descritti prima.
Il presente capitolo continua con il capitolo 2 che definisce rigorosamente i concetti di dati,
informazioni, conoscenza ed esperienza secondo una prospettiva adeguata allo scopo di
questo stesso capitolo. Il successivo capitolo descrive lo stato dell’arte circa la EB e la EF. Il
capitolo 4 descrive la proposta dell’autore di estensione della EB in KEB per renderla più
efficace per lo scopo del presente capitolo. Il capitolo 5 descrive la piattaforma
PROMETHEUS che è un prototipo di sperimentazione della KEB con le caratteristiche
presentate nel precedente paragrafo. Nel capitolo 6 sono descritte le linee guida per la
produzione e l’evoluzione dei contenuti della KEB. Dopo questi capitoli è possibile
analizzare, nel settimo, i valori di PROMETHEUS per gli stakeholders per sostenere come
l’estensione della KEB proposta in questo capitolo possa contribuire a soddisfare i requisiti,
descritti nell’introduzione, in corrispondenza dei modelli di relazioni e di business, descritti
nella stessa introduzione come fattori abilitanti l’Economia della Conoscenza. Infine, le
conclusioni chiudono il capitolo. Per gli approfondimenti degli argomenti trattati nel capitolo
sono disponibili diverse citazioni nella bibliografia.
2. DATI, INFORMAZIONI, CONOSCENZA ED ESPERIENZA
Per il modello di strutturazione del KEP sono necessarie le definizioni rigorose di Dati,
Informazioni, Conoscenza ed Esperienza. In letteratura ci sono molte definizioni di questi
concetti che sono adeguate al contesto in cui sono definite, ma non sono efficaci per gli scopi
di questo capitolo. Perciò, è necessario che per ognuno dei precedenti concetti siano riviste le
definizioni e siano formalizzate per assicurare una comune comprensione degli stessi concetti
tra l’autore ed i lettori. Tali definizioni sono diverse dalle stesse espresse in letteratura e dal
significato tacito che hanno nel linguaggio comune.
6/6
La conoscenza nella IT è nella maggior parte dei casi è prodotta per induzione empirica;
perciò è opportuno che la definizione di dato, sia: il valore di uno degli attributi richiesti per
descrivere un fatto (F); ogni attributo corrisponde a un aspetto di un fatto ed è attinente al
punto di vista da cui è considerato. Formalmente un fatto è descritto da un set di dati che può
essere espresso come nell’esempio (1) dove: K è il numero di attributi, il generico dij è un
dato che rappresenta il j-th attributo del i-th fatto.
Fi = (< di1, di2, di3,… diK>) (1).
# Maintenance
Request for S
1
2
3
4
5
6
7
8
…
29
Maintenance
Type
C (Corrective)
E (Evolutive)
C
C
C
C
P (Perfective)
C
…
C
Effort Spent
(Man/days)
2
4
4
4
5
6
15
2
…
6
Components
Involved
1
35
7
8
10
8
43
2
…
8
Tabella 1: Esempio di dati
In tabella 1 sono riportati i fatti, nell’ordine cronologico, verificatisi per un Software System
S. Ogni fatto è descritto con gli attribuiti <# Maintenance Request (richieste di assistenza),
Maintenance Type (tipo di assistenza), Effort Spent (lavoro umano speso), Components
Involved (componenti coinvolte)>.
L’informazione è un concetto che assume molti significati. Nel linguaggio comune essa
descrive qualcosa di materiale (i.e.: prodotto; tool…) o di immateriale (i.e.: evento storico, di
cronaca, televisiva, radiofonica, …); questo tipo di informazione può essere chiamato
Informazione Descrittiva. In molti contesti scientifici l’informazione è il contenuto codificato
in un messaggio trasmesso da una sorgente (i.e.: codici da trasmettitori elettronici; geni in un
DNA, dati immessi in un sistema informatico, …), questa può essere detta Informazione
Entropica. Alcune volte questo concetto è utilizzato per indicare modelli di classificazione di
dati che servono per confermare o contraddire nozioni utili a qualcosa oppure a qualcuno (i.e:
sondaggi, exit pool, …); si potrebbe indicare questa come Informazione Nozionistica.
In questo capitolo, avendo come obiettivo l’induzione empirica, siamo interessati
all’informazione che può essere estratta dai dati che descrivono i fatti. Chiameremo questa
Informazione Estratta (Information Mining) per distinguerla dagli altri tipi elencati prima. Il
generico termine Informazione (INF) nel contesto di questo capitolo si riferirà a quest’ultimo
tipo, salvo indicazione diversa. Essa è l‘interpretazione di un set di fatti o di relazioni tra loro.
L’informazione rivela il vero significato dei fatti e lo rende utilizzabile per gli utenti che
devono eseguire compiti o prendere decisioni. Può essere rappresentata formalmente come
una funzione M (Mining) applicata su un insieme di fatti:
INFl = Ml{F1, F2, F3,…, Fn}= Ml ({dij}: i =1,…N; J =1,…,K(i)) (2)
7/7
Ml è una funzione che scopre ed interpreta pattern nei dati che descrivono fatti, classificati
nel modo più opportuno per derivare informazioni utili.
Effort Spent (Man/days)
40
35
30
25
20
15
10
5
0
Effort Spent (Man/days)
C
E
C
C
C
C
P
C
C
E
C
C
C
C
C
C
C
E
C
C
C
C
C
C
C
P
C
C
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figura 1. Effort spent vs Maintenance Requests
Per esempio, alcune informazioni estratte dai fatti della tabella 1, ma con funzioni M diverse
per estrarre pattern ed interpretarli, sono elencati di seguito. Per facilitare la lettura, sono stati
utilizzati codici mnemonici piuttosto che i generici INF.
Ec: lo sforzo per il mantenimento correttivo aumenta nel tempo, come risulta dalla Figura1
che presenta graficamente, lo sforzo speso nel corso di tempo per soddisfare ogni richiesta
per manutenzione correttiva. Se fosse disponibile una seria adeguatamente lunga di fatti si
potrebbero trovare in questi dati altre informazioni, quali il modello di previsione del trend
del numero di richieste di manutenzione e del lavoro uomo per soddisfarle.
Ne: le richieste di manutenzione evolutiva sono meno frequenti delle correttive e delle
perfettive;
Ee: L’impegno uomo richiesto per far evolvere il software tende ad aumentare col tempo e,
comunque è più grande di quanto speso per le correttive;
Np: le richieste di manutenzione perfettiva sono meno frequenti delle correttive ma sono più
frequenti delle evolutive;
EP: l’impegno uomo richiesto per la manutenzione perfettiva è, in generale, maggiore di
quanto speso per le correttive e minore di quanto speso per le evolutive;
Re: Dopo un evento di manutenzione evolutiva, il numero di richieste di manutenzione
correttive tende ad aumentare;
Rp: Dopo un evento di manutenzione perfettiva il numero delle richieste di manutenzione
correttiva, tende a diminuire.
Un ulteriore estratto degli indici presenti nella tabella, mostrando il numero dei componenti
coinvolti in ogni richiesta di assistenza è presente in figura 2. Di quì è possibile estrapolare
altre informazioni:
Involved Components
50
45
40
35
30
25
20
15
10
5
0
Involved Components
C
E
C
C
C
C
P
C
C
E
C
C
C
C
C
C
C
E
C
C
C
C
C
C
C
P
C
C
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figura 2. Maintenance Request vs Components Involved
Ce. I cambiamenti di manutenzione correttiva ed evolutiva gradualmente incrementano il
numero delle componenti coinvolte.
8/8
Cp. La manutenzione perfettiva cambia diminuisce di componenti software coinvolti.
La conoscenza sia nel linguaggio comune sia in gran parte della letteratura è definita come
una o più relazioni tra molte nozioni, estratte dai dati e dai fatti che questi descrivono, e che
l’uomo riesce a costruire con la sua mente.
In questo capitolo, sempre per favorire l’induzione empirica, è necessaria una definizione che
evidenzi la conoscenza come indotta dall’informazione e che prevede la sua formalizzazione
in modo che possa essere riusata indipendentemente dalla mente che l’ha generata. Per
distinguere il concetto di conoscenza trattato in questo capitolo da quelli citati si definisce la
Knowledge Mined, ossia un concetto più ampio di dato ed informazione e che richiede la
comprensione dell’informazione e delle relazioni tra le possibili informazioni mined (estratte)
dai dati. Per rendere la sua definizione più chiara, si assume che: le relazioni tra gli elementi
di informazioni sono molto complessi; perciò, per interpretare loro è opportuno adottare un
punto di vista che riduca gli aspetti rilevanti della relazione tra loro e, quindi, renda più facile
la loro interpretazione. Il punto di vista dal quale interpretare le parti di informazioni e le sue
interrelazioni è espresso da un problema che l‘applicazione della conoscenza deve contribuire
a risolvere, genericamente indicato con Pi.
Per chiarezza, un problema, nel seguito di questo capitolo, è un quesito, semplice o
composito, di rilevante interesse in un dominio di conoscenza che presenta difficoltà e può
generare inconvenienti: la sua soluzione consiste in una soluzione ricavata da elementi
informativi noti sotto condizioni prefissate; potrebbe dare adito a soluzioni diverse.
Dipendentemente dallo scopo del quesito il Problema può dirsi: di decisione se la soluzione
deve supportare decisioni per superare eventi negativi verificatisi o che si possono verificare
durante l’esecuzione di un processo; di ottimizzazione se trattasi di migliorare le prestazioni
di una o più risorse; trascendentale se richiede ragionamenti deduttivi, anche formali,basati
su tesi dimostrate o provate in precedenza.
Per Pi sono necessari i contenuti di un set di parti di informazione:
{INF}:{ < INF1, INF2, INF3,…. INFi>}
e le informazioni tra le parti stesse
{R({INF})}:{ R1{ INF1}; R2{ INF2} R3{ INF3}… Rl{ INFl}};
(3)
(4)
dove qualunque {INFk}è una combinazione degli elementi in {INFi} . Si conviene, per
semplicità, che nel resto del capitolo la Knowledge Mined si chiami Knowledge (KW).
Formalmente, KW può essere rappresentata da una funzione G (Generates):
KWi = Gi (Pi, {R({INF})})
(5)
La funzione Gi seleziona le componenti di informazioni e le relazioni tra esse, tra tutte quelle
rese disponibili dai dati e dalle funzioni M, applicate su questi ultimi, e generalizza
l’interpretazione delle informazioni e delle loro relazioni.
La generica funzione Gi è prodotta da un competente che grazie alle sue conoscenze, abilità
ed esperienza riesce a: individuare quali informazioni e quali relazioni, tra tutte quelle
9/9
disponibili, sono efficaci per dare soluzione al problema Pi, ad interpretare tali relazioni ed a
generalizzarle. Una volta espressa la, generica, KWi può essere utilizzata da tutti senza avere
l’esperienza del suo autore. Inoltre, data l’induzione di KW da un insieme di dati un altro
esperto del livello di quello che ha estratto l’informazione può empiricamente confermare o
contraddire KW.
Esempio: si supponga di avere il problema P < come rallentare il decadimento della qualità
del sistema software durante la sua manutenzione ?>. Il dominio del problema è la
manutenzione del software. Le informazioni che descrivono il contesto in cui è eseguito il
processo di manutenzione sono quelle estratte dalla tavola 2.1. Le relazioni essenziali, tra le
informazioni estraibili, per risolvere il problema posto sono: dopo la manutenzione correttiva
o evolutiva aumenta il numero di componenti impattate (Ce), questo implica che la
manutenzione correttiva tende ad aumentare la coesione interna del sistema; pertanto, è
necessario effettuare la manutenzione perfettiva per mitigare tale complessità (Rp); dopo la
manutenzione perfettiva il numero di richieste di manutenzione correttiva diminuisce (Cp)
rallentando, così, il trend di peggioramento delle qualità. Pertanto, in questo caso
l’applicazione della (5) dà il seguente risultato:
KW= < per rallentare il decadimento della qualità del sistema software, quando la qualità di
un sistema degrada per effetto della manutenzione correttiva od evolutiva è opportuno
effettuare una manutenzione perfettiva per rallentare il degrado del sistema > = G (P, R(Ce,
Rp, Cp)).
L’esperienza sia nel linguaggio comune sia in letteratura è tacita, sta nella mente di un uomo
che l’ha acquisita con la continua applicazione delle sue conoscenze ed abilità e che gli serve
per produrre altra conoscenza. Anche la esperienza può avere diverse classificazioni. Ad
esempio: Esperienza Comune, Esperienza Critica, Esperienza Religiosa e così via.
In questo capitolo interessa la Empirical Experience (EXP); ovvero, quella che si acquisisce
applicando la conoscenza in vari contesti ed estraendo da ogni applicazione i dati ed i fatti
che confermano o contraddicono la conoscenza estratta dalle applicazioni precedenti. Per
completezza, l’applicazione della conoscenza può essere richiesta da un progetto oppure da
un esperimento artificialmente creato da un ricercatore proprio per confermare o contraddire
una congettura od un principio.
Posto che per progetto, in questo capitolo, si intende l’esecuzione in uno specifico contesto di
un processo che ha acquisito o sfruttato tecnologicamente la conoscenza di cui si vuole
verificarne l’efficacia nella pratica. Anche un esperimento controllato eseguito in laboratorio
è un progetto in cui si prova l’efficacia dell’innovazione se acquisita o sfruttata in un
processo.
Le applicazioni di interesse dei precedenti concetti per questo capitolo sono l’acquisizione e
lo sfruttamento di conoscenza per migliorare lo scopo di un processo di business, qualità del
prodotto o del servizio generati da esso, oppure le performance, la velocità di esecuzione,
costi, conformità, stabilità e capacità. Per favorire tali applicazioni della conoscenza sono
necessari indici che consentano di fare un bilancio costi-benefici riscontarti in ogni
acquisizione o sfruttamento realizzati. Tali indici devono essere validati empiricamente in
10/10
contesti diversi. Più numerose saranno le repliche della esperienza, tanto maggiore sarà la
fiducia che i manager o i ricercatori avranno nell’acquisire o sfruttare una conoscenza.
La EXP è critica per lo scopo del presente capitolo. Infatti, la conoscenza acquisita o sfruttata
in un processo di business passa dallo stato dell’arte allo stato della pratica e diventa una
tecnologia a supporto del miglioramento dello scopo o delle performance dello stesso
processo. Se la conoscenza che si trasforma in tecnologia è un insieme di risultati di ricerca
allora si è realizzata una innovazione che aumenta il vantaggio comparativo di chi la usa. Per
completezza se il risultato di ricerca è utilizzato per lo scopo del processo di business si tratta
di innovazione di prodotto se lo è per le performance si tratta di innovazione di processo.
Formalmente EXP è una funzione EE (Evidenza Empirica) di un elemento di conoscenza
usata in progetti di Acquisizione o Sfruttamento (A/E) da dove si rilevano un insieme di
indicatori (I) di scopo o di performance del processo di business. Formalmente:
EXP(KWi) = EE ( KWi, {A/Ei1,{Ii1}, A/Ei2,{Ii2}, A/Ei3,{Ii3},…, A/EiN,{IiN}}) (6)
KWi è la conoscenza che si intende acquisire può essere descrittiva e/o formalmente espressa,
come è stato definito sopra;
A/Eij, descrive il progetto in cui KWi è stata applicata la Jma volta;
{Iij} è l’insieme degli indicatori misurati sul processo di business durante l’applicazione Jma
dell'elemento di conoscenza KWi.
Il numero di applicazione N varia nel tempo perché l’applicazione di KWi potrebbe essere
replicata in un numero di progetti crescente con il passare del tempo.
Il set di indicatori {Iij} potrebbe essere diverso dal set {Iik} perché dalle esperienze
precedenti alla kma potrebbe essere stato deciso che per validare meglio l’efficacia di KWi è
necessario introdurre nuovi indicatori o modificare quelli che si sono misurati
precedentemente.
EE è una funzione che astrae in principi i risultati delle applicazioni di KWi.
Esempio: si supponga di avere un problema P < migliorare la manutenibilità di un sistema
software> e di avere un KW < La manutenibilità di un sistema software è migliorabile
attraverso un processo RE di Reverse Engineering e di Restauro; con il restauro pilotato da
alcuni indicatori di qualità del software>. KW includerebbe anche la descrizione formale del
processo, delle tecniche e dei tool utilizzabili per la sua esecuzione che qui si omette per
brevità.
N.
1
T
20
2
12
Acquisizione
Staff EA
C
I.H.; 600 630
D.K.
I.H.
280 336
Ultimo Trimestre Senza RE
M.U.
E
E.R IM. I.R.
60
2520 92
7
85
Primo trimestre senza RE
M.U.
E.
E.R. IM I.R.
42
1272 22
2
15
72
45
2870
91
6,3
83
1356
5
2
8
Tabella 2: Esempio di EXP
Legenda
T = tempo necessario per acquisire RE in gg lavorativi
Staff = competenze che non sono presenti nell’impresa e che devono essere
messe dall’esterno;
EA = impegno lavorativo di acquisizione in ore uomo; questo comprende sia
l’impegno speso dai trasferitori che quello speso dagli acquisitori e se ci fosse
11/11
Stato dell’arte sulla EB e la EF
necessità di formazione è incluso anche l’impegno speso per quest’ultima
attività;
C = costo in migliaia di euro
M.U. = numero di Maintenance Unit (M.U.) eseguite; la M.U. è un insieme di
richieste di manutenzione che sono assegnate ad un unico sviluppatore e si
prevede che richiedano 30 ore uomo di impegno lavorativo per essere
soddisfatte; nelle 30 ore sono incluse anche i cambiamenti alla
documentazione del software;
E = Effort, in ore uomo, spese mediamente per le M.U. eseguite;
E.R. = Effort Risk in punti percentuali = Ni/M.U. *100 dove Ni è il numero di
M.U. che risultano avere un E>( 30 ± 0,05*30);
IM = numero di componenti impattate in media dalle M.U. eseguite;
I.R. = Impact Risk in punti percentuali = Ni/M.U. *100 dove Ni è il numero di
M.U. che risultano avere un IM > (IMprevisto ± 0,05*30).
I.H. = conoscenza dell’Information Hiding e delle pratiche per realizzarla
D.K. = conoscenza del dominio applicativo
Per misurare l’efficacia di RE si definisce un set di misure che nell’esempio corrispondono a
{M.U., E, E.R., IM, I.R.}. Sono anche rilevate alcune misure che esprimono il contesto in cui
i progetti sono eseguiti {T, EA, Staff, IM, I.R.}. E’ opportuno evidenziare che gli indicatori, i
progetti ed i valori delle misure sono del tutto immaginari e servono solo a chiarire il concetto
di EXP. I due progetti in cui è applicato RE mostrati in tavola 2, i contesti sono diversi:
hanno competenze diverse, nel secondo progetto esiste già la competenza IH, le dimensioni
del problema sono diverse perché nel secondo progetto ci sono più UM ma il software è più
manutenibile. L’applicazione di RE genera la seguente EE < RE rende il sistema software più
manutenibile diminuendo sia l’impatto delle modifiche sia il rischio di erronee previsioni
sull’impatto, migliora la qualità del software facendo diminuire le richieste di manutenzione e
con esse le MU; diminuisce l’Effort ed i rischi di previsione dell’Effort, rendendo più stabile
il processo di manutenzione, creando economie tali da far rientrare in poco tempo i costi di
acquisizione>.
3. STATO DELL’ARTE SULLA EB E LA EF
3.1 Scopo e rappresentazione della EB
Lo scopo della EB è quello di supportare la competitività delle imprese che la utilizzano.
Per vincere nella competizione è necessario avere un ben definito insieme di prodotti per
soddisfare i fabbisogni dei customers, pertanto la EB deve contenere modelli di prodotto e
relazione delle loro caratteristiche con le aspettative di specifici segmenti di mercato. Inoltre,
è necessario avere un insieme di modelli di processi che consentano di migliorare
continuamente prodotti e servizi compresi nell’offerta dell’impresa. Infine, deve contenere
modelli di qualità di prodotti e di processi che consentano di valutare il posizionamento
dell’impresa rispetto agli obiettivi strategici, in questo caso i modelli devono contenere le
iniziative di miglioramento nel caso che le misure previste facciano prevedere uno
scostamento tra gli obiettivi raggiungibili e quelli che richiede la strategia.
12/12
La rappresentazione del contenuto di un Experience Package (EP) presente in letteratura,
cui l’autore fa riferimento, è mostrata in figura 3 [8]. In essa sono rappresentati modelli di
prodotto, di processo o di qualità. Ed i dettagli del processo necessari per l’adozione del
package. Tra l’altro, questa componente potrebbe avere anche materiale didattico per
l’addestramento all’uso della conoscenza da applicare. Una seconda vista copre i processi dei
modelli di controllo; per esempio, modelli per analizzare la qualità dello scopo e delle
prestazioni del processo prima e dopo la applicazione dell’Experience Package. La terza vista
copre l'esperienza empirica nell'uso del Knowledge Package. Nella costruzione di un
Experience Package secondo [8] sono basilari: il paradigma Goal Question Metrics per la
misura ed il controllo della qualità; il Quality Improvement Paradigm (QIP) e l’Experience
Factory.
Figura 3 Experience Package
3.2 Scopo e rappresentazione della Experience Factory
La EF costituisce un ciclo virtuoso per apprendere dall’esecuzione dei progetti le esigenze
di miglioramento continuo delle esperienze raccolte in EB. L’apprendimento si snoda in un
ciclo di controllo della qualità ed uno di assicurazione della qualità. Il primo prevede la
raccolta delle misure con le quali valutare, secondo predefiniti modelli di qualità, il
raggiungimento degli obiettivi del progetto in esecuzione e le iniziative di miglioramento. Il
secondo prevede la raccolta delle informazioni dai progetti eseguiti ed il miglioramento degli
EP per assicurare che la loro adozione riesca a diminuire gli scostamenti tra gli obiettivi
raggiunti dai progetti futuri e quelli strategici dell’impresa.
Alla base del ciclo di controllo c’è il paradigma del Goal Questions Metrics (GQM).
Invece, per l’assicurazione di qualità si utilizza il Quality Improvement Paradigm (QIP).
Il GQM è un paradigma per costruire modelli orientati agli obiettivi di qualità desiderati;
perciò modelli di qualità flessibili. Esso è un approccio sistematico per specializzare gli
obiettivi sulla base di: specifiche esigenze del progetto e dell’organizzazione che lo esegue;
modello di processo e di prodotto; aspetti d’interesse o valori della qualità [24].
13/13
L’operatività dei risultati delle misurazioni dei Modelli di Qualità prodotti con il GQM è
sistematica: alla stessa combinazione dei valori di misure si associa una interpretazione
indipendente da chi l’effettua da quando e da come è effettuata. Lo schema del GQM è
rappresentabile come in figura 4.
Figura 4 Rappresentazione del modello GQM
Il Quality Improvement Paradigm è un paradigma per il miglioramento sistematico della
qualità [8]. Come tale, esso è una guida per il continuo miglioramento delle organizzazioni.
Si basa, essenzialmente, su un'appropriata caratterizzazione dell'ambiente. Il paradigma
fornisce un contesto per la definizione dell'obiettivo ed è essenzialmente basato sul riutilizzo
sistematico di esperienze estratte dalla loro formalizzazione in pacchetti di conoscenza. Il
processo di miglioramento realizzato dal QIP è definito come un processo iterativo che
esegue ripetutamente una sequenza di attività di base. Il QIP si compone di due diversi cicli.
Un ciclo ha l’obiettivo del miglioramento dei progetti durante la loro esecuzione. Al tempo
stesso, questo è parte di un altro ciclo di apprendimento e di miglioramento di lungo periodo
che mira a migliorare un'organizzazione (a livello strategico). Spesso, il primo ciclo è
indicato come il ciclo di controllo della qualità mentre il secondo è quello di assicurazione
della qualità. Il processo del QIP è sintetizzato in figura 5. Il processo di miglioramento del
livello del progetto è integrato nel processo del livello strategico di miglioramento.
Nel corso degli ultimi 25 anni, il tema del trasferimento di conoscenze, del suo reimpiego e
della relativa conservazione è stato ampiamente discusso in letteratura. Nel 1989, H.D.
Rombach e V.R. Basili [8], proposero Experience Factory (EF) [23]. Il concetto di EF è stato
poi sviluppato e raffinato in contesti di ricerca ed industriali (http://www.esernet.org/).
Un’indagine su tali sviluppi e sulle diverse specializzazioni che la EF ha avuto negli anni
sono leggibili, rispettivamente, in [17], ed in [1, 2, 11, 12, 16, 19, 22, 23]. EF è una
organizzazione logica con una sua corrispondente implementazione fisica [23].
14/14
Figura 5 Quality Improvement Paradigm.
La EF interagisce con i processi di business come mostrato in Figura 5.
3.3 Interazione tra QIP ed EF.
QIP ed Experience Factory sono strettamente collegate alle pratiche proprio perché i due
approcci sono nati in un contesto di collaborazione dell’atra comunità di ricerca e comunità
industriale (http://bpch.dau.mil/; http://ccs.mit.edu/tel/).
Con riferimento alla figura 6, il ciclo a livello strategico astrae ed impacchetta l’esperienza
empirica estratta dai dati rilevati nel ciclo a livello di progetto. Quest’ultimo ciclo utilizza
l’esperienza raccolta nella EB per annullare od, almeno, mitigare lo scostamento degli
obiettivi previsti per il singolo progetto con quelli realizzati con la sua esecuzione.
15/15
Plan
Data, Informations, Knowledge,
Experience
Support
Selected KEP, Competences
Characterize
Package
Set Goals
Formalize
KnowledgeExperience
Base
Choose
Process
Generalize
Execute
Process
Collect Data
Tailor
KEP for improvement, Competences
Analyze
Execute
Data or Quality Indicators
Product, lessons learned, data,..
Figura 6: Experience Factory Model
Più dettagliatamente, in tabella 3 sono descritte le attività che si eseguono secondo il QIP e
come queste alimentano la EF.
Passi del QIP
Caratterizzare
Definire i
goals
Scegliere i
modelli
Eseguire
Analizzare
Attività a Livello di Progetto
Caratterizzare il progetto ed
identificare i modelli rilevanti per il
riuso.
Definire gli obiettivi del progetto in
termini misurabili e definire le
relative misure
Attività a livello strategico
Caratterizzare l’organizzazione ed
identificare gli sviluppi futuri
Definire
gli
obiettivi
di
miglioramento e le ipotesi per
realizzarli, in modo che siano
misurabili
Scegliere i modelli di processi Identificare progetti o piloti per
appropriati e sviluppare il relativo eseguire indagini sulle ipotesi
piano di progetto
Eseguire il progetto secondo il Eseguire progetti e piloti e
piano, raccogliere i dati e fornire raccogliere i relativi dati
guide in linea per eseguire
efficacemente il progetto
Analizzare i dati raccolti ed il Analizzare i dati raccolti e validare
progetto
e
suggerire
i le ipotesi
16/16
Impacchettare
miglioramenti; ovvero minimizzare
lo scostamento tra la qualità attesa e
quella realizzata dei processi e dei
prodotti implicati nel progetto
Formalizzare in Pacchetti di
Esperienza i risultati dell’analisi
con modelli che favoriscano il
riuso.
Formalizzare in Pacchetti di
Esperienza i risultati dell’analisi
con modelli che favoriscano il
riuso.
Tabella 3: descrizioni delle attività del QIP
3.4 EB ed EF nei contesti industriali
Molte EF ed EB sono sviluppate in contesti industriali. Una fonte utilizzabile per una
interessante analisi è il sito (http://ccs.mit.edu/ph/). In esso c’e una lista delle EB sviluppate e
sperimentate. Nella tabella 4 vi è un elenco delle più comuni ed utilizzate EB. L'analisi delle
varie EB elencate nella tabella mostra che i contenuti, gli obiettivi e le parti interessate delle
EB elencate sono molto diverse. Nessuna può soddisfare le motivazioni e gli obiettivi che
costituiscono lo scopo di questo capitolo dettagliato nell’introduzione.
Perciò, l’autore ha ritenuto opportuno definire la struttura ed i contenuti di una EB che siano
adeguati allo scopo del presente capitolo.
Nome
Organizzazione
CeBase
National Science
Foundation(NSF): Center
of Empirically Based
Software Engineering
VSEK
ESERNET
German BMBF (Ministero
per la Didattica e la
Ricerca) sviluppato da un
consorzio di
organizzazioni di ricerca
Fraunhofer IESE
Obiettivo
Raccogliere modelli
empirici per fornire linee
guida validate per:
selezionare tecniche e
modelli; raccomandare
aree di ricerca; supportare
la formazione di ingegneri
del software
Mira a soddisfare i
fabbisogni delle imprese
che devono ingegnerizzare
efficacemente software
incrementalmente
complessi attraverso
scambi di esperienza via
un portale-web,
presentazioni e workshop
e collaborazione in
progetti
Coordinare l’astrazione di
studi empirici, supportare
la loro esplicitazione in
pacchetti così che essi
possano essere riusati
all’interno e fuori
dall’impresa che li ha
prodotti, fornire
addestramento ed
accompagnamento per
rafforzare nelle persone l’
esperienza estratta dagli
studi empirici. Essa perciò
stabilisce una rete di
eccellenza nell’Empirical
(ESE) a livello mondiale.
Contenuti
Una varietà di dati
empirici su topiche come
COTS, tecniche di
reading: FAQ, lezioni
apprese, pubblicazioni,
paper
Argomenti di Ingegneria
del Software:
Body of Knowledge
SWEBOK
Domini applicativi dei
sistemi
Esteso glossario di termini
Le aree di interesse attuali
sono:
Test ed ispezioni
Progettazione object
oriented ed
implementazione
Ingegneria del software
basata sulle componenti
Processi Agili di Sviluppo
software
Utilizzatori
Ricercatori empirici
Comunità Aperta
Organizzazioni europee
che utilizzano
intensivamente software.
17/17
Implementazione della EB in KEB
The MIT
Process
Handbook
HPCBugBase
Software
Program
Mangers
Networks
Acquisition
Best Practices
Clearinghouse
Le aree di interesse sono i
modelli di Business:
attività dei processi;
elementi dei processi;
esempi di processi;
applicazioni di processi
Pattern di
Difetti funzionali
Colli di bottiglia nelle
prestazioni
Problemi di portabilità
Cattive Pratiche
MIT
Libreria in linea per
condividere e governare la
conoscenza circa i
processi di business.
Experimental Software
Engineering Group
(ESEG) della “University
of Maryland”
Raccogliere conoscenza
empirica circa i difetti
comunemente riscontrati
nel High Performance
Code usando un approccio
incrementale
Assistant Secretary of the
Navy
Identificare le buone
pratiche nello sviluppo
software per l’industria e
le pubbliche
amministrazione; provare
e convogliare loro sulla
gestione di grandi progetti
di enti che usano
intensivamente i sistemi
software
Buone Pratiche
Modelli di acquisizione di
buone pratiche
Fornire un repertorio
centralizzato di
informazioni validate e
utilizzabili praticamente
che sono state approvate e
ritenute utili.
Descrizioni/caratterizzazio
ni di pratiche:
Applicabili in contesti
descritti;
Informazioni
costi/benefici;
Informazioni di validità;
Rapporti circa le
applicazioni e studi
empirici circa le pratiche;
Punti di contatto per
gruppi di esperti e di
discussione
US Department of
Defense (DoD)
Persone di Ricerca e di
Business
Sviluppatori professionali
Manager di organizzazioni
ed esperti di dei domini
inerenti al software
interessati a migliorare le
pratiche di gestione dei
processi di produzione e
manutenzione del
software.
Tabella 4: Caratterizzazioni delle più noti EB
4. IMPLEMENTAZIONE DELLA EB IN KEB
Lo scopo della KEB è, come per la EB, quello di supportare la competitività delle imprese.
Ma la KEB intende farlo tenendo conto che per raggiungere questo obiettivo le imprese
devono transitare verso l’economia della conoscenza e che per farlo possono utilizzare uno o
più dei modelli comportamentali descritti nell’introduzione. Pertanto, i contenuti della KEB
sono orientati ad esplicitare le pratiche per l’adozione dei risultati di ricerca o delle
innovazioni derivate da questi. Inoltre, la KEB aggiunge ai contenuti della EB tutte le
componenti che si rivelano utili per accompagnare (drive) un organismo nell’adottare i KEP.
Di seguito si indicherà genericamente come KEP sia il pacchetto contenente solo conoscenza
sia quello contenente conoscenza ed esperienza, ma il lettore deve avere ben presente che un
KEP, in assenza di esperienza, è più propriamente un KP.
La relazione tra la KEB, GQM, QIP ed EF è esattamente la stessa descritta perla EB.
18/18
4.1 Tipi di KEP
I KEP si classificano per il loro contenuto. Di seguito si elencano un insieme di tipi che non
deve essere considerata una check-list perché l’esperienza potrebbe far rilevare la necessità di
definire altri tipi di KEP.
Prodotto. Informazioni descrittive od informazioni entropiche di tools, componenti software
di qualsiasi livello di stazione che utilizzati in una o più attività di un processo possono
migliorare quest’ultimo. Il KEP, oltre alla loro eventuale descrizione, deve esprimere
informazioni che esplicitino come specializzarli nei vari contesti d’uso, come e quando usarli
o riusarli e le esperienze rilevate con il loro sfruttamento in uno o più progetti.
Processo. Paradigmi o modelli di parti di processo, dettagli di procedure, tecniche od
algoritmi da utilizzare nei processi di sviluppo per migliorarli. Le modalità di
personalizzazione della conoscenza descritta nei diversi contesti d’uso. L’esperienza rilevata
in progetti di sviluppo grazie alla loro acquisizione o sfruttamento negli stessi.
Connessioni. Relazioni tra le osservabili di un prodotto o di un processo e gli effetti dello
sfruttamento di talune tecnologie. Possono contenere anche relazioni tra le competenze
(conoscenze ed abilità) e le capacità di impresa e tra le competenze ed i test necessari per la
loro valutazione. Questi contenuti sono sempre derivati dalle esperienze empiriche rilevate
nei progetti in cui le tecnologie sono state sfruttate.
Governance. Modelli e misure per il governo dei progetti co-locati e distribuiti. In particolare
conoscenze necessarie e monitorare e mitigare i rischi in progetti che usano diversi paradigmi
di processo (es.: sviluppo per linee di prodotto; sviluppo per componenti, inclusi i COTS
(Components Off-The-Shelf); sviluppo OSS (Open Source Software); sviluppo per servizi).
Le esperienze collegate contengono gli indicatori di efficacia dell’applicazione della
conoscenza in progetti reali.
Intelligence. Conoscenze derivate dall’analisi statistica di dati raccolti per vari scopi. Ad
esempio, log di uso di strumenti o di software; estrazione semantica di messaggi raccolti da
strumenti di assistenza degli utilizzatori di un prodotto o di un servizio. Essenzialmente,
questo tipo di pacchetto esplicita conoscenze delle parti interessate di un processo o di un
prodotto. Le esperienze collegate servono a confermare o contraddire la stessa conoscenza in
diversi contesti ed in diversi progetti.
È giusto il caso di ribadire che un KEP può essere ibrido, ovvero il suo contenuto può essere
composto da pezzi che appartengono a tipi diversi di pacchetti. In ogni caso si deve
salvaguardare la leggibilità e la comprensibilità del KEP. Per comprendere un KEP,
nell’accezione del presente capitolo, si deve sia capire la semantica del contenuto sia essere
in grado di applicarlo.
4.2 Struttura dei Contenuti dei KEP.
La presentazione delle informazioni, delle relazioni tra esse che costituiscono la conoscenza e
degli indicatori che esprimono l’esperienza di applicazioni o sfruttamento della conoscenza
19/19
può essere effettuata attraverso Report Formali oppure Storie Narrative [14]. I primi sono
economici da produrre e minimizzano le ambiguità nella descrizione dei contenuti; ma la loro
comprensione risulta, in genere, complessa. Le seconde richiedono un rilevante impegno di
produzione e possono avere molte ambiguità; ma sono più semplici da comprendere.
La proposta dell’autore è la presentazione in forma strutturata, utilizzando diversi modi di
espressione anche combinati tra loro, dipendentemente da quello che si vuole esprimere:
grafici, algoritmi, meccanismi per impacchettare esperienza (es.: Tavole di Decisione,
Modelli dinamici di previsione), testo ed ogni altra forma di descrizione si dovesse rendere
necessaria. Lo schema del contenuto è rappresentato in figura 7.
Root
Nodi
intermedi
Nodi
foglia
Nodi
foglia
Nodi
intermedi
Nodi
intermedi
Nodi
foglia
Figura 7: Schema gerarchico del contenuto di un KEP
La descrizione è logicamente strutturata ad albero. Il contenuto di ogni nodo deve entrare
in un video per facilitarne la lettura. Il nodo radice descrive i problemi a cui si riferisce il
KEP e l’indice ragionato dei nodi sottostanti. L’indice ragionato spiega al lettore quale parte
della soluzione al problema è esposta in ognuno dei nodi sottostanti. Nel caso di un problema
complesso è possibile individuare sottoproblemi, ognuno dei quali è affrontato in una delle
sezioni del KEP. I nodi intermedi descrivono un sottoproblema oppure un aspetto della
soluzione, del problema principale, a cui fanno riferimento e l’indice ragionato dei nodi
sottostanti. I nodi intermedi contengono le informazioni e le relazioni tra esse che
costituiscono la conoscenza che si vuole esprimere. Se tra i nodi intermedi ci sono nodi che
attengono a conoscenza estratta dall’acquisizione o dallo sfruttamento della conoscenza in
uno o più progetti, il package è, propriamente, un KEP. I nodi foglia contengono i dettagli
della conoscenza o della esperienza a cui fa riferimento il nodo intermedio da cui dipendono.
Ed in particolare espongono le informazioni e le relazioni tra esse che compongono la
conoscenza descritta. E’ giusto il caso di evidenziare che grazie all’indice ragionato il lettore
di un package può selezionare le parti a cui è interessato oppure può decidere la sequenza di
lettura dei nodi che meglio si adegua alla sua conoscenza pregressa ed ai suoi interessi di
lettura. In breve, questo migliora la leggibilità del KEP.
20/20
Per una buona leggibilità, si consiglia che da ogni nodo dipendano non più di otto nodi.
Inoltre, l’albero logico sottostante ad un KEP non deve superare i tre livelli. Nel caso che la
descrizione di un KEP necessiti di superare queste soglie consigliate, è opportuno dividere il
KEP in più KEP che siano collegati tra loro. La divisione può essere effettuata per
sottoproblemi, per esperienze di acquisizione e sfruttamento della conoscenza o per una
combinazione qualsiasi di questi due tipi di divisione. La scelta non può che essere lasciata
all’autore del KEP che è responsabile della comprensibilità di quest’ultimo.
4.3
Contenuti dei KEP
Un KEP deve contenere i problemi a cui si intende dare risposte. Quindi tutte le
informazioni che derivano da risultati di ricerca o da precedenti progetti con le relative
relazioni che riescono a rispondere o danno un contributo significativo alla risposta dei
problemi. I contenuti specifici della conoscenza possono essere lasciati alla letteratura ed alle
altre fonti convenzionali in cui la specifica conoscenza è descritta. Invece, il contenuto di
KEP deve porre molta attenzione ad esprimere le relazioni tra i risultati di ricerca e tra le
informazioni estratte attraverso le quali è possibile sostenere che esse insieme possono
rispondere al problema. Inoltre, e soprattutto, il KEP deve esprimere come la conoscenza si
trasformi in pratica; ovvero, i processi e le attività che essa deve innovare e come deve essere
applicata per fornire la risposta efficace ai problemi enunciati.
Per favorire la candidatura di un KEP al suo riuso è opportuno che i suoi contenuti specifici
di pratiche siano arricchiti delle conoscenze di cui necessitano i potenziali utilizzatori per
convincersi a riutilizzarli. A tale proposito, di seguito si riporta una lista di indicazioni che
sarà possibile migliorare con le lezioni che si apprenderanno con l’applicazione del KEP.
I prerequisiti necessari per l’acquisizione o lo sfruttamento efficace dei risultati di ricerca
o dell’innovazione proposta dal KEP; questi includerebbero: capacità di impresa,
competenze, risorse economiche e strumentali. Sarebbe, inoltre, opportuno che siano elencati
i rischi di adozione del KEP. Tra questi, gli esperti del dominio dei problemi trattati dal KEP
devono trovare le barriere che essi percepiscono nella soluzione dei problemi a cui risponde il
KEP. Se essi non trovassero questa corrispondenza scarterebbero il KEP come poco
significativo per il dominio dei problemi di interesse [5, 13, 20]. In corrispondenza di ogni
rischio deve essere prevista una o più iniziative di mitigazione che rendano confidenti gli
utilizzatori di poter superare le barriere che percepiscono nel riuso della conoscenza
contenuta in KEP e, quindi, di poter raggiungere, attraverso l’adozione di quest’ultimo gli
obiettivi su cui essi sono commessi [5, 20]. Un altro aspetto da esplicitare è la pianificazione
per l’adozione che deve esplicitare le attività, i tempi, le risorse e le competenze necessarie
per l’adozione. Il piano dà le informazioni per valutare i costi di adozione; per poter fare un
esatto bilancio dell’adozione è necessario descrivere l’impatto sui processi o sui prodotti
collegati a quello in cui la conoscenza è acquisita o sfruttata e sui problemi a cui il KEP
intende dare risposta. La descrizione dell’impatto deve essere, possibilmente formale, almeno
rigorosa in modo che si possa fare il bilancio costi-benefici dell’acquisizione o dello
sfruttamento della conoscenza contenuta nel KEP. Per favorire l’adozione del KEP è
necessario che tutti gli stakeholders partecipino a questo processo e per indurre tale
partecipazione è opportuno che si spieghino i valori che l’adozione genera, classificati per
ogni stakeholder [2, 14, 20].
21/21
Tra le esperienze che devono essere aggiunte alle conoscenze, sono necessarie quelle per
dimostrare che l’applicazione del KEP è risultata efficace in uno o più progetti. Per chiarire
quali siano gli obiettivi di efficacia che si sono rilevati nei progetti pregressi si può utilizzare
il GQM per descrivere il modello metrico per valutare l’efficacia e per monitorare il processo
di adozione. Il modello metrico deve valutare ogni aspetto del business e perciò deve
prevedere le prospettive di interesse, dal punto di vista di tutti gli stakeholders, ovvero deve
esprimere quantitativamente i valori per gli stakeholders. Inoltre, esso deve prevedere
l’espressione di tutti gli indicatori statistici che dimostrano la validità dei risultati ricavati con
il riuso del KEP. Gli indicatori previsti dal modello metrico devono servire per rafforzare la
validità empirica del riuso del KEP. In particolare devono mostrare il successo o gli
insuccessi realizzati nei progetti di riuso del KEP negli aspetti di interesse: obiettivi previsti e
raggiunti; realizzazione dei ritorni economico finanziario, controllo e mitigazione dei rischi
ed adeguatezza delle iniziative di mitigazione. Affiancato al GQM deve essere eseguito il
miglioramento continuo del KEP. A questo scopo, si consiglia l’uso del paradigma QIP, a cui
si è fatto riferimento prima.
Per mostrare la maturità del KEP e per rendere sempre leggibile le sue evoluzioni, le
motivazioni che hanno richiesto i cambiamenti e le decisioni adottate per ogni cambiamento è
necessario descrivere la storia del KEP. Le decisioni devono essere avvallate dalle evidenze
empiriche, estratte dal riuso del KEP nei progetti, di ognuno degli indicatori precedenti. Essa
deve descrivere le iniziative realizzate per il miglioramento del KEP, dei processi di
acquisizione e sfruttamento dello stesso e del modello metrico corrispondenti agli insuccessi
rilevati attraverso il monitoraggio del processo di adozione. Per evidenziare meglio la storia
del KEP è opportuno dividere il suo contenuto in due sezioni: il KEP attuale e la storia della
sua evoluzione con tutte le decisioni adottate. Per completezza, si evidenzia che il
miglioramento da evidenziare deve riguardare tutte le componenti del KEP, descritte di
seguito.
Il contenuto di KEP deve essere adeguabile ai vari contesti d’uso [5, 8, 20]. Pertanto, la sua
presentazione deve individuare tutti i punti di adeguabilità dello stesso ai vari contesti. In
dettaglio, è opportuno che l’autore descriva le parti invarianti e varianti del processo di
acquisizione o sfruttamento che consentano di descrivere la portabilità, scalabilità ed usabilità
nei diversi contesti d’uso. Di conseguenza, l’autore del KEP deve descrivere come adeguare
lo stesso ai diversi contesti d’uso previsti dai parametri che assicurano la flessibilità.
Se un KEP è complesso la sua acquisizione avviene incrementalmente [20]. Sarebbe perciò
opportuno che l’autore di un KEP che dovesse risultare complesso (i.e. lungo processo di
acquisizione, alti costi di acquisizione, considerevole numero di rischi e costose iniziative di
mitigazione) lo scomponga in KEP più semplici, collegati tra loro che si possano acquisire
con una predefinita sequenza.
4.4 Componenti del KEP
La rapidità di acquisizione dei KEP nei progetti di ricerca o di produzione è favorita
dall’esistenza di tools che automatizzino le attività ripetitive dei processi di acquisizione [3,
5]. Perciò è opportuno prevedere, quando è possibile, i tools che supportino il riuso del KEP e
per ognuno di essi un corso di addestramento che acceleri la curva di apprendimento dello
22/22
stesso. Inoltre, è opportuna la disponibilità di portatori di competenze che siano in grado di
supportare, potenziandoli, i ricercatori ed i professionisti che intendano acquisire o sfruttare il
KEP. A tale scopo si raccolgono in competenze le persone che abbiano le conoscenze e le
abilità per poter dare tale supporto oppure le imprese che dispongono di risorse umane che
abbiano tali competenze.
Per favorire l’accettazione di un KEP è opportuno descrivere i progetti in cui esso è stato
usato ed i risultati che ha prodotto. La descrizione del progetto deve contenere il contesto
d’uso, le specializzazioni effettuate del KEP e, sarebbe opportuno, avere anche i valori delle
misure effettuate per monitorare il progetto. Queste possono essere utilizzate sia per la
verifica dell’efficacia del KEP secondo il modello metrico che deve essere descritto nello
stesso KEP sia per rilevare altre osservazioni che possono essere utili per definire il
miglioramento del KEP in una o più delle sue componenti.
I dati di dettaglio dei progetti potrebbero anche non essere disponibili, per riservatezza
imposta dall’organismo in cui il progetto si è svolto. E’, comunque, necessario conoscere le
caratteristiche dell’indagine sperimentale che è stata eseguita con i dati del progetto ed i
risultati dell’indagine, sulla base dei quali si possa dimostrare la relazione causa-effetto tra
l’applicazione del KEP ed i valori espressi negli indicatori che caratterizzano il KEP [5, 20].
Queste informazioni costituiscono i contenuti della componente evidenze.
In progetti ed in evidenze i dati riportati devono essere controllati per aumentare il livello
di confidenza che il potenziale utilizzatore del KEP ripone nel suo uso [20]. Pertanto è
opportuno che nei contenuti di queste due componenti sia descritto il processo e gli strumenti
per il controllo dei dati ed i risultati della loro applicazione durante l’esecuzione dei rispettivi
processi. Nella descrizione dei progetti è opportuno fare riferimento ai tools ed alle risorse
utilizzate nell’esecuzione degli stessi, presenti nelle rispettive componenti. Questa relazione
tra competenze, tool, progetti ed evidenze assicura l’adeguatezza dei tools e delle competenze
disponibili per il KEP.
A causa dell’adozione incrementale del KEP i tempi per completare questo processo
tendono ad allungarsi [20]. Per mitigare il rischio di volatilità delle competenze durante
l’adozione del KEP, tanto più elevato quanto più lungo è la durata del processo, è opportuno
che per ogni KEP si abbia un consistente numero di portatori di conoscenza nella componente
competenze . Infatti, questo assicura che anche se l’adozione dovesse durare per un lungo
tempo la probabilità di trovare risorse disponibili per il supporto sarebbe alta.
Una buona comprensione di un KEP favorisce il consenso degli stakeholders per
l’applicazione dello stesso [20]. Questo induce ad arricchire un KEP di: e-learning formativo
con cui è possibile erogare seminari e lezioni, in asincrono, circa il contenuto del KEP e di elearning addestrativo per erogare lezioni di approfondimento sul processo di acquisizione o
sfruttamento del KEP.
Per decidere di riusare un KEP è necessario che l’utilizzatore abbia assicurazione
dell’adeguatezza delle risorse disponibili [5]. Per le risorse diverse da quelle professionali, in
genere, l’organismo utilizzatore è in grado di effettuare tale valutazione; più difficile è la
valutazione dell’adeguatezza delle risorse professionali. Perciò, le risorse che sono nella
23/23
componente competenze, precedentemente citata, devono essere certificate per dimostrare la
loro adeguatezza. Inoltre, le competenze disponibili nello stesso organismo o formate ed
addestrate dall’e-learning devono poter essere valutate per adeguatezza. Per soddisfare questa
esigenza i pacchetti di e-learning devono essere completi di test di valutazione per ognuna
delle competenze o abilità di cui trattano. Particolare attenzione deve essere posta durante il
monitoraggio dell’efficacia del KEP circa l’efficacia delle unità didattiche incluse nell’elearning e dei relativi test di valutazione. Infatti, le risorse umane sono critiche nell’adozione
e nella gestione dei KEP perciò la loro formazione e valutazione sono cruciali per l’efficacia
dell’adozione degli stessi.
Con riferimento al precedente schema di EP (figura 3), il KEP proposto in questo capitolo
si può rappresentare come in figura 8 in cui è evidenziato che il modello di processo e di
controllo è sostituita dalla componente Art & Practices per mettere in evidenza che il suo
contenuto può esprimere solo risultati di ricerca (Art) oppure sia questi sia i modelli di
processo per la sua adozione (Practices). Inoltre, sono evidenziate anche le altre componenti
previste dalla struttura del KEP presentata in questo capitolo.
Figura 8: Knowledge-Experience Package
24/24
4.5 Risorse del KEP
Com’è stato detto il contenuto del KEP è orientato alle pratiche per la sua adozione nei
processi di business; pertanto è necessario allegare ad esso alla Documentazione che descrive
il Dominio di conoscenza scientifica e tecnologica da cui derivano le pratiche di cui tratta
[13, 20].
Nonostante l’impegno alla rigorosità di ogni autore è prevedibile che in ogni KEP ci siano
ambiguità ed incompletezze che un potenziale utilizzatore ha bisogno di chiarire. Perciò è
opportuno che per ogni KEP sia possibile avere contatti con i portatori di conoscenza del
KEP. Questi ultimi possono essere gli stessi autori oppure persone che hanno compreso i
contenuti KEP per averlo riutilizzato più volte.
4.6 I Metadati
In una KEB pubblica o privata il numero di KEP raccolti tenderanno ad aumentare. Perciò
è necessario dotare la KEB di strumenti necessari per la ricerca rapida dei KEP candidati alla
soluzione del problema di un suo utilizzatore e per consentire a quest’ultimo di valutare se
uno o più dei KEP candidati sono adeguati al suo contesto e, quindi, sono candidati per
l’adozione. In particolare, i ricercatori devono trovare tutti i risultati di ricerca disponibili
nella KEB che possono facilitare la realizzazione degli obiettivi previsti nella sua agenda di
ricerca [20]. I professionisti devono trovare tutte le soluzioni disponibili per dare una risposta
consistente e convincente ai problemi che si riscontrano nei progetti in cui sono impegnati
[14].
Se ad un ricercatore sfugge un risultato di ricerca disponibile egli utilizzerà la sua creatività
per raggiungere l’obiettivo su cui è commesso. Questo implicherebbe uno spreco di risorse
con la conseguente diseconomia [20].
I professionisti che non trovano KEP disponibili che rispondono ai problemi presentati dai
progetti su cui essi si sono impegnati si comportano in modo diverso, dipendentemente dalla
loro esperienza. Infatti, un esperto, in genere, tende a risolvere un problema con la propria
esperienza e non con quella degli altri; pertanto, se non trova una soluzione pronta per il suo
problema, egli si sente autorizzato a risolverlo con il proprio repertorio di conoscenze ed
esperienza. Tale repertorio è, in genere, tacito, pertanto, costoso nella sua applicazione e
povero nell’assicurazione di qualità. In breve, questo crea, come prima, diseconomie. I
professionisti neofiti o che sono commessi su un problema solo temporaneamente (buy-out)
lavorano con maggiore conformità se trovano il KEP adeguato al loro problema, seguendo
quanto espresso nel KEP; altrimenti, sono disorientati, non assicurano un buon livello di
qualità e frequentemente sono costretti a fare molti tentativi prima di raggiungere un obiettivo
soddisfacente [14].
Per facilitare la ricerca dei KEP nel KEB si utilizzano i metadati. La proposta dell’autore è
l’uso di due insiemi di metadati. Il primo insieme risponde al quesito: esiste nel KEB almeno
una soluzione utilizzabile per predefiniti problemi? Questo insieme contiene: il tipo di KEP,
25/25
PROMETHEUS
come è stato descritto prima; l’area di dominio di conoscenza, per l’Ingegneria del Software
possono essere: tecniche, metodi, processi, modelli di qualità, validazione empirica; parole
chiavi; problemi, descritti sinteticamente, a cui il KEP dà risposta. Il secondo insieme
risponde al quesito: tra i KEB candidati quali sono quelli che hanno i contenuti più
soddisfacenti per il contesto di destinazione? Questo secondo insieme di metadati contiene la
descrizione sintetica dei seguenti contenuti, tutti citati precedentemente: prerequisiti, rischi,
pianificazione, bilancio, valori, storia.
5. PROMETHEUS
Practices pROcess and Methods Evolution THrough Experience Unfolded Systematically,
in breve PROMETHEUS, è una piattaforma prodotta in SERLAB, laboratorio di Ingegneria
del Software presso il Dipartimento di Informatica dell’Università di Bari. Essa è costruita
con un framework che consente di specializzare la KEB con le componenti e con le relazioni
tra le componenti adeguabili alle richieste dalla organizzazione che usa la piattaforma.
Pertanto, essa può assumere configurazioni diverse.
PROMETHEUS è concepita come una piattaforma pubblica perché ha lo scopo di
supportare il trasferimento della conoscenza tra tutti gli organismi che possono contribuire ad
accumulare conoscenza trasferibile nei processi di business come innovazione ed ad
accumulare esperienza che aumenti la confidenza circa l’efficacia della conoscenza
disponibile. Ciò nonostante, PROMETHEUS consente di limitare l’accesso alla conoscenza
depositata in essa. Pertanto, un Ente, pubblico o privato, utilizzatore di PROMETHEUS, può
rendere pubblica una parte dei suoi KEP e riservarne un’altra parte come accessibile solo al
suo interno.
Di seguito è descritta la piattaforma che include tutte le componenti e le relazioni che sono
state descritte precedentemente in questo capitolo.
La KEB è costituita da diverse sezioni, una per ogni componente prevista dalla struttura del
KEP. La scomposizione in sezioni della KEB consente la pubblicazione di un KEP
incrementalmente e facilita la sua consultazione. Lo schema della KEB è riportato in figura 9.
Tutte le componenti hanno i contenuti strutturati ad albero (figura 7), quando devono
esprimere conoscenza. I metadati descritti prima sono quelli associati alla componente AP
che è quella principale nel KEP; le altre componenti hanno metadati che rispondono agli
stessi quesiti, ma i loro attributi sono, in genere, diversi.
I legami tra le componenti della KEB rappresentano tutti i percorsi che un utilizzatore può
seguire nella piattaforma. Per esempio: un utilizzatore può cercare una Knowledge
Experience Content e dopo averlo letto può voler conoscere uno o più tools citati nei
contenuti e/o le competenze che possono essere utilizzate a supporto dell’adozione dello
KEP.
Ogni sezione del KEP può essere popolata indipendentemente dalle altre. Questo consente
di arricchire la KEB con i percorsi più vari. Ad esempio, un professionista può inserire il suo
26/26
PROMETHEUS
profilo in CM anche se non è l’autore di un KEP ma se ha le competenze per supportare
l’adozione di un KEP in un processo di business può essere collegato ad esso; inoltre, se egli
ha nel suo portafoglio di esperienze certificanti le sue competenze un insieme di progetti a cui
ha partecipato con il profilo professionale che ha dichiarato può descrivere questi in PR.
Oppure, si può esporre un Tool in TO che può supportare l’adozione di un KEP o comunque
può contribuire a rispondere ad un qualche problema per il quale non esiste alcun KEP in
PROMETHEUS; in questo caso si possono collegare ad esso alcuni progetti in cui esso è
stato utilizzato e possono essere estrarre evidenze in EV che dimostrano quali siano gli effetti
positivi rilevati nel progetto che sono causati dal suo uso.
Nell’interfaccia di consultazione di ogni sezione sono presenti i collegamenti alle risorse
ed alle relazioni della componente con il resto del KEP. Gli attributes puntano ai metadati
della componente. Contents restituisce il contenuto della sezione. E’ possibile attraverso il
link E-Learning consultare seminari, corsi di approfondimento del contenuto o corsi di
addestramento sull’uso degli stessi contenuti. Le Relations collegano la sezione del KEP alle
omologhe sezioni di altri KEP che hanno un qualche collegamento con quello che si sta
consultando oppure ad altre componenti inerenti lo stesso KEP. Questo è di particolare
interesse quando l’autore ha partizionato un KEP per renderlo meno complesso. Gli
attachments contengono articoli, libri, report od altre fonti convenzionali in cui si possono
approfondire le motivazioni del KEP o della specifica sezione che si sta consultando ed il
contenuto dello stesso. Il Knowledge Supplier consente di accedere ai soggetti contenuti nelle
competenze e che sono autori o portatori di conoscenza del KEP o della specifica sezione che
si sta consultando. L’Help Supply consente di comunicare con il o gli autori del KEP per
chiedere chiarimenti o fare osservazioni circa il KEP; oppure, con gli amministratori di
PROMETHEUS per fare osservazioni, reclami ed altro tipo di comunicazione circa la
usabilità ed il livello di soddisfazione della piattaforma. Sulla sinistra c’è l’albero in cui sono
elencati tutte le altre sezioni del KEP che si sta consultando, puntando su una specifica
cartella il sistema passa a esporre il contenuto della corrispondente sezione.
Figura 9: Schema di Prometheus Art and Practices Component
27/27
PROMETHEUS
Il componente Art and Practices (AP) è il componente principale di un KEP. Esso ha il
contenuto di KEP come è stato descritto precedentemente. Un esempio del suo contenuto è
mostrato in figura 10 nella quale si possono rilevare il nodo radice ed i puntatori ai nodi
intermedi, evidenziati come puntatori attivi. Nella figura 11 sono invece mostrati i metadati
corrispondenti allo stesso KEP.
Figura 10: Esempio di contenuto di un AP
28/28
PROMETHEUS
Figura 11: Attributi AP
5.1 Project Component
Nel Project Components ci sono tutte le informazioni usabili per la caratterizzazione, la
descrizione del Progetto e la descrizione del contesto in cui si è svolto lo stesso progetto; le
risorse utilizzate dal progetto; risultati del progetto; eventi accaduti durante l’esecuzione del
progetto stesso.
Vi sono molti fattori che caratterizzano i contesti. Una lista tentativa per l’Ingegneria del
Software è la seguente:
o Fattori umani: numero di persone; livelli di competenza con riferimento ad uno o più
standard; propensione al lavoro di gruppo delle risorse; integrazione dei gruppi attivi
nel progetto; esperienza delle risorse circa i problemi a cui il progetto vuole dare
risposte; esperienza delle risorse circa il processo , le tecniche e gli strumenti da
utilizzare; volatilità delle risorse.
o
Caratterizzazione dei problemi: dominio applicativo; novità rispetto allo stato
dell’arte; volatilità delle regole di dominio; vincoli imposti dal problema.
o Caratterizzazione del processo: ciclo utilizzato; metodi integrati nel processo;
tecniche orchestrate nei metodi da utilizzare; tools; linguaggi di programmazione;
altre notazioni da utilizzare nel ciclo.
29/29
PROMETHEUS
o Caratterizzazione del prodotto: macchine di sviluppo e di esercizio; tempi e budget
disponibili; software esistenti.
E’ opportuno prevedere nel progetto la descrizione degli eventi critici che si sono verificati
e che hanno fatto avvertire rischi. Inoltre, è opportuno mettere in rilievo tutti gli scostamenti
che si sono verificati tra quanto era atteso nella pianificazione e quanto si è verificato. Per
ogni scostamento è utile conoscerne la causa e le iniziative che sono state prese per il
miglioramento.
Ogni progetto dovrebbe includere il modello metrico che è stato utilizzato nel suo
monitoraggio e quindi i valori rilevati dalle misure. Di particolare interesse sono gli indici
economici : (costo preventivato del lavoro programmato (BCWS); costo effettivo del lavoro
eseguito (ACWP); costo preventivato del lavoro eseguito ( BCWP)).
Ad un progetto potrebbero essere acclusi i dati di dettaglio del progetto, se l’Ente che li
deve fornire non li considera strettamente riservati. L’organismo fornitore dei dati potrebbe
decidere di fornirli alla piattaforma ma renderli consultabili solo a coloro che hanno
specifiche credenziali di accesso. La presenza dei dati di dettaglio nella piattaforma dà la
possibilità di utilizzarli per estrarre evidenze empiriche diverse da quelle per cui sono state
rilevate. Quindi potrebbero costituire una fonte per la produzione di un notevole patrimonio
di informazioni. Nel caso di disponibilità dei dati di dettaglio, questi devono essere
accessibili attraverso il pulsante attachment.
Per completezza, chi prende dati di dettaglio dalla piattaforma deve spiegarne la
motivazione; nella comunità degli stakeholders di PROMETHEUS la motivazione accettata è
solo: esecuzione di una indagine empirica. L’organismo che preleva i dati con questa
motivazione, deve garantire il livello di riservatezza desiderato dai fornitori degli stessi e
deve impegnarsi a descrivere l’indagine effettuata ed a restituire i risultati dell’indagine che
saranno resi pubblici come evidenza empirica.
I metadati di questa componente sono: Brief Description un breve sommario del progetto
che contiene il progetto obiettivo; Project Keywords, parole chiave che sintetizzano il
progetto; Project Domain, area tematica in cui la esperienza del Progetto può essere situata e
applicata; Starting Data, data prevista di partenza per il progetto e data reale di partenza;
Ending Data, data prevista di fine progetto e reale data di fine progetto; Applied Competence,
Competenze applicate nel corso della esecuzione del progetto; Project Effort, numero di
ore/uomo totali previste e usate durante l’esecuzione del progetto per ogni competenza
applicata, i rischi previsti e quelli verificatisi.
30/30
PROMETHEUS
Figura 12: Project Component
5.2 Tool Component
Questa componente contiene una breve descrizione del tool di supporto ad uno o più KEP,
rimandando agli attachments la descrizione approfondita dello stesso, e la conoscenza che il
proponente può mettere in campo per convincere il potenziale utilizzatore ad adottarlo. E’
necessario esporre le competenze che necessitano per un’efficace adozione dello stesso, i
rischi che possono essere riscontarti nell’adozione e le iniziative per mitigarli, quindi la
pianificazione più opportuna per l’adozione. Ovviamente questi saranno sottoinsiemi delle
corrispondenti conoscenze espresse nei KEP che supportano questo tool. Per accelerare
l’adozione, anche in questo caso è necessario coinvolgere tutti gli stakeholder potenzialmente
coinvolti nella stessa adozione e, quindi, descrivere i valori per essi. Infine, è necessario
mostrare la maturità del tool esplicitando il numero di versioni che sono state rilasciate, le
motivazioni che hanno indotto ogni cambiamento di versione e le modifiche effettuate in
ognuno dei precedenti cambiamenti. E’, in genere, il caso di prevedere corsi di addestramento
all’uso del tool.
I metadati descriveranno in sintesi il contenuto e sono: breve descrizione, le aree del
dominio tecnico coperte dal tool, parole chiavi, data di prima release, problemi di cui
31/31
PROMETHEUS
supporta la risposta; prerequisiti e rischi per la sua adozione, competenze e pianificazione per
la sua adozione, valori classificati per tipo di stakeholders; numero di versioni e storia.
Figura 13: Tool Component
5.3 Evidence Component.
La EV contiene la descrizione di tutte le indagini empiriche che rendono valida la
relazione causa effetto tra i risultati di ricerca e le innovazioni proposte e le risposte ai
problemi che costituiscono il loro obiettivo. In particolare, in questa componente devono
essere descritti i dati utilizzati, i controlli effettuati su di essi per assicurare la loro
accuratezza ed i meccanismi per effettuarli, lo schema di indagine utilizzato, le analisi
statistiche effettuate ed i risultati ottenuti come evidenza.
In alcune indagini è necessario produrre materiali per preparare i soggetti sperimentali a
comportarsi correttamente durante le indagini e/o materiali utili per la esecuzione della stessa
indagine. In questo caso i materiali necessari possono essere accumulati in un repository
accessibile attraverso il tasto attachments. Qualche volta potrebbe essere opportuno anche
associare corsi di addestramento ai processi di sperimentazione.
32/32
PROMETHEUS
Per chiarezza, in EV sarebbe opportuno che siano espresse le evidenze empiriche di tutte le
decisioni prese nei cambiamenti effettuati nel KEP ed in tutte le sue componenti. Per esempio
devono essere validate per ogni iniziativa di mitigazione dei rischi la loro efficacia nel
controllare il corrispondente rischio. Inoltre, sono descritte le evidenze empiriche di tutti gli
indicatori sintetici che sono nei metadati di AP e delle altre componenti, quali: i valori per gli
stakeholders, gli indicatori quantitativi del piano di adozione, i rischi di adozione e l’efficacia
delle corrispondenti iniziative di mitigazione, l’impatto sui processi di business in cui sono
adottati.
La descrizione dell’indagine deve avere tutti i dettagli che convincono il suo lettore sulla
sua accuratezza e che consentono allo stesso di replicare l’indagine per confermare le
conclusioni o per contraddirle. E’ ovvio che in entrambi i casi la comunità di
PROMETHEUS si aspetta che tali repliche siano registrate nella piattaforma per dare
maggiore forza all’evidenza. Una possibile guida per la schematizzazione delle indagini
empiriche replicabili è il report in [7].
Il contenuto di EV sono strettamente collegati a quelli delle componenti PR ed AP. I
metadati sintetizzanti i contenuti sono: Brief Evidence Description, brief abstract
synthesizing the Evidence Content; Evidence Kind, Empirical evidence, Industrial contest
application, case study. etc.;
Figura 14: Evidence Component
33/33
PROMETHEUS
5.4 Competence Component
La Competence Component (CM) raccoglie soggetti fisici o organizzazioni che hanno
competenze, i primi, e capacità, i secondi, che consentono di supportare l’adozione di un KEP
oppure di un Tool oppure di supportare attività collaterali alle precedenti attività. Ogni
soggetto iscritto in questa componente è caratterizzato dalla descrizione della combinazione
di conoscenze, abilità e comportamento che fa parte del suo patrimonio professionale. In CM
un soggetto può essere nominato esplicitamente o con un nome fittizio, dipendentemente
dalla scelta dello stesso soggetto.
Ogni soggetto ha un portafoglio di esperienze che certificano il suo profilo professionale.
Spesso nel portafoglio di esperienze sono inclusi progetti, in tal caso sarebbe opportuno che
questi ultimi siano descritti nella componente PR. Nel caso che questo non sia possibile in
CM è prevista una sintesi dei progetti a cui il soggetto ha partecipato che mostra il tipo e
dimensione del progetto: dominio applicativo, ore uomo totali impegnate nel progetto, ore
uomo di lavoro svolte dal soggetto dichiarante nel o nei ruoli che richiedono il profilo
professionale per cui è presente in CM.
E’ opportuno evidenziare che nell’e-learning collegato a questa componente è possibile
trovare corsi che approfondiscono le competenze e gli skill di cui si compone la stessa
competenza. Inoltre l’e-learning prevede anche il test specifico per ogni item di conoscenza e
di skill previsto. Questo serve a validare le competenze di soggetti che non hanno altri tipi di
certificazioni. Nel piano di miglioramento continuo della KEB sono anche migliorati i
contenuti sia dei corsi sia dei test. Il miglioramento è attivato ogni volta che una competenza
preparata con il corso disponibile o certificata con i test disponibili, dovesse risultare non
perfettamente adeguata nei progetti in cui è utilizzata con tale competenza.
I metadati per questa competenza sono costituiti dall’elenco dei profili professionali
secondo gli standard scelti dall’utilizzatori. PROMETHEUS mette a disposizione i seguenti
sillabi per la definizione delle competenze: EUCIP (EUropean Certification of Informatics
Professionals; http://www.www.cepis.org/), SFIA (Skills For the Information Age;
http://www.sfia.org.uk/), CIGREF (Nomenclature of ICT Job Profiles; http://www.cigref.fr/),
AITTS (Advanced IT Training System; http://www.kibnet.org/).
Il curriculum vitae e/o eventuali certificazioni di competenze che il soggetto volesse
produrre possono essere consultate attraverso il pulsante di attachments.
34/34
Linee Guida per la produzione.
Figura 15: Competence Component
6. LINEE GUIDA PER LA PRODUZIONE.
6.1 Produzione e pubblicazione.
Prima di tutto è necessario chiarire che la strutturazione dei KEP, descritta nella precedente
sezione, consente il miglioramento continuo di PROMETHEUS. Infatti se tutta la comunità
attorno alla piattaforma usa lo stesso standard nei contenuti è possibile verificare con un
unico modello se questi riscuotono gradimento da parte degli utilizzatori, qualunque sia il
KEP utilizzato. Dall’uso della KEB potrebbe risultare la necessità di modificare tale standard
per migliorare il gradimento di tutti i KEP.
Il contenuto di un KEP richiede un rilevante impegno per la sua produzione e, spesso, un
lungo tempo per il suo completamento. L’impegno per la produzione è richiesto per la mole
di conoscenze che deve essere formalizzata in un KEP. Il periodo di produzione risulta lungo
perché è necessario raccogliere esperienza nell’applicazione della conoscenza.
Per mitigare il primo problema è possibile produrre il KEP per incrementi successivi.
Quando è pronta la parte di conoscenza della componente AP, una prima versione del KEP è
già pubblicabile nella piattaforma. Se ci dovessero essere state evoluzioni del package nel
tempo, è possibile pubblicare prima la versione attuale e successivamente si possono
pubblicare le modifiche effettuate sul contenuto, iniziando dalle più recenti ed andando a
ritroso fino alle prime.
Le altre componenti del KEP possono essere pubblicate successivamente. Si consiglia però
di pubblicare subito le risorse disponibili che completino la descrizione della conoscenza e
che indichino i portatori di conoscenza che possono supportare la comprensione del KEP. E’
opportuno che la produzione delle altre parti del KEP sia pianificata in modo che gli
eventuali interessati sappiano quando potranno avere a disposizione le altre parti del KEP.
35/35
Qualche volta la schedulazione degli incrementi potrebbe essere pilotata, almeno
parzialmente, dalle richieste di uno o più utilizzatori interessati ad applicarle. Questo è uno
degli effetti collaterali di una comunità aperta, come quella auspicata dai progettisti di
PROMETHEUS, che rende la produzione del KEP cooperativa.
Per quanto riguarda l’evidenza empirica circa l’esperienza del KEP, questa è chiaramente
accumulabile con l’adozione del KEP in progetti eseguiti in differenti contesti. L’accumulo di
esperienza, chiaramente, è un altro effetto dell’apertura della comunità che insiste su
PROMETHEUS e della cooperazione interna a tale comunità. Per favorire il contributo a
rafforzare l’evidenza di vari soggetti che adottano il KEP è indispensabile che l’indagine
empirica che genera l’evidenza debba essere descritta rigorosamente in modo che essa sia
chiaramente paragonabile a tutte le altre indagini eseguite con lo stesso KEP. In particolare, è
indispensabile che le indagini empiriche eseguite sullo stesso KEP costituiscano una famiglia
di esperimenti [9]. Nel caso di un progetto di produzione è opportuno estrarre da tutti i dati
disponibili quelli essenziali per la descrizione dell’indagine sperimentale che esso esprime
nella evidenza empirica per un KEP.
All’autore di un KEP deve essere chiaro che un pacchetto pubblicato con contenuti parziali
restringe il bacino di potenziali interessati. Per chiarire questo concetto si analizzano, di
seguito, alcuni possibili scenari. Un pacchetto che contiene solo conoscenza può essere
interessante solo a ricercatori che vogliono applicare l’Open Innovation per accelerare la loro
ricerca. Un KEP che come esperienza ha solo un esperimento controllato effettuato con
studenti può essere di interesse per ricercatori che, interessati dai risultati di ricerca esposti
nello stesso KEP, intendano replicare l’esperimento. In questo caso è importante che le
indagini effettuate siano descritte in modo che siano accuratamente replicabili per far crescere
l’esperienza con alta consistenza interna. Altresì un KEP che ha poca esperienza applicativa
sarà preso in considerazione da un’ impresa se esso dà risposte a problemi che per l’impresa
costituiscono un rischio molto più grande dei rischi previsti per l’adozione del pacchetto
stesso.
6.2 Tecnica di produzione di un nuovo KEP.
Per la produzione di un nuovo AP l’autore spesso deve sintetizzare rilevanti volumi di
informazioni o di conoscenza, sullo stesso dominio di problemi del producendo KEP, che
sono state già formalizzate, in genere, su più tipi di fonti. L’autore del KEP deve trovare le
informazioni e le conoscenze più accreditate sia perché può essere utile esporle nel KEP sia
perché conoscendo lo stato dell’arte può mettere meglio in evidenza l’innovazione del KEP
che sta producendo e, quindi, renderlo più attrattivo per i suoi consultatori.
Per quanto detto, la prima attività da fare è la individuazione delle fonti da consultare. Nel
caso che trattasi di risultati di ricerca le fonti devono essere scientifiche. Per l’ingegneria del
software, per esempio, un possibile elenco delle fonti più accreditate puo essere: IEEExplore,
ACM Digital Library, Google Scholar (http://scholar.google.com/), Citeseer Library
(citeser.ist.psu.edu),
Inspec
(www.iee.org/Publish/INSPEC/),
Science
Direct
(www.sciencedirect.com),
EI
Compendex
(www.engineeringvillage2.org/Controller/Servlet/AthensService). Nel caso di conoscenza di
36/36
natura industriale si possono consultare fonti di conoscenza implicite o esplicite quali:
sviluppatori, analisti di mercato, venditori, personale di supporto, report, utilizzatori,
customers.
Un mezzo utile per la sintesi della letteratura è il Systematic Literature Review [21]. In
breve, questo processo prevede tre fasi. Il Planning and Review in cui si identificano i
fabbisogni, si definisce la recensione desiderata, si specificano i quesiti di ricerca che
definiscono il od i problemi a cui intende rispondere il KEP, si formalizza il protocollo per la
recensione, si verifica e si valida il protocollo di recensione. La Recensione in cui si
estraggono tutti gli item disponibili tra i quali si selezionano quelli di interesse, si valuta la
qualità dei documenti selezionati filtrando ulteriormente la documentazione, quindi si
estraggono le informazioni che sono collegate al problema a cui si vuole dare risposta e le
relazioni tra esse che possono configurare la o le risposta/e al problema. Infine con questa
ultime si produce la componente AP.
Durante la sintesi effettuata per produrre AP, l’autore individua anche, se ci sono, evidenze
empiriche circa l’applicazione della conoscenza che si sta estraendo. Queste consentirebbero
di produrre la componente EV. Lo stesso dicasi di eventuali materiale formativo che potrebbe
consentire di produrre le risorse di e-learning di una o più componenti.
Il processo di sintesi consente di individuare possibili portatori di conoscenza circa il KEP
che si sta producendo. Se adeguatamente autorizzato dai soggetti portatori di conoscenza,
l’autore potrebbe anche produrre un primo nucleo della componente CM.
6.3 Espressioni identificative
Nel contenuto di ogni componente di un KEP i nodi sottostanti quello che è visualizzato e
le altre componenti dello stesso KEP collegate sono indicati con i puntatori. Per distinguere i
puntatori ai nodi da quelli alle altre componenti si conviene che questi ultimi siano espressi
con il seguente standard: [Nome del puntatore]-[Tipo di Componente]. [Nome del puntatore]
è scelto dall’autore del pacchetto ed identifica l’elemento a cui fa riferimento il puntatore.
[Tipo di Componente] indica la componente alla quale si riferisce il puntatore. Pertanto:
[Tipo di Componente] є {Art&Practices, Learning, Tool, Evidence, Project, Competence}
6.4 Verifica e validazione dei pacchetti
La verifica dei KEP è eseguita dallo stesso autore. Attualmente, la check list utilizzata per la
verifica è la seguente:
I. I nomi delle componenti non devono presentare sinonimi od omonimi;
II. Tutti i puntatori citati in un nodo devono essere raggiungibili.
III. Non sono costituiti riferimenti circolari con i puntatori;
IV. Esiste tracciabilità tra i contenuti della componente e la conoscenza prevista nel
contenuto della medesima componente, secondo le convenzioni della piattaforma
PROMETHEUS.
37/37
Questa potrebbe essere migliorata con l’esperienza di produzione e modifica dei KEP.
La validazione è eseguita principalmente con l’uso dei KEP da parte degli utilizzatori.
Pertanto, la validazione sarà effettuata in differita rispetto alla pubblicazione e sarà tanto più
accurata quanto maggiore sarà stato l’uso del KEP. Gli utilizzatori valideranno il KEP
comunicando la loro soddisfazione/insoddisfazione e le motivazioni della stessa, attraverso
l’Help Supply.
6.5 Evoluzione dei KEP.
Durante la verifica e la validazione dei KEP potrebbero essere evidenziati uno o più rilievi
circa la completezza, la correttezza, la congruità e l’ambiguità del KEP. In tal caso il
pacchetto subisce modifiche correttive. Queste non richiedono la descrizione di decisioni di
evoluzioni. Si suppone che più lungo è il periodo di esistenza del KEP maggiore sarà la sua
accuratezza.
Grazie all’applicazione del QIP nella EF, si possono rilevare failure negli indicatori
caratterizzanti il KEP oppure nei contenuti di una o più componenti del KEP. In questo caso
si eseguono modifiche perfettive. Queste richiedono l’esplicitazione delle decisioni che si
assumono nei cambiamenti e di conseguenza deve essere descritto in KP una nuova versione
del contenuto attuale ed un ulteriore elemento nella storia del KEP.
Attraverso l’interazione con gli utilizzatori, l’autore di un KEP può avere suggerimenti di
modifiche che migliorino la comprensione e l’attrattività del KEP. In questo caso si creano
spunti per modifiche adattative. Per queste ultime devono, come per le precedenti e con le
stesse motivazioni, esplicitare le decisioni assunte nel cambiamento del contenuto e registrare
un nuovo elemento nella storia del KEP.
E’ opportuno ribadire che l’esplicitazione delle decisioni e le riedizioni dei contenuti
dimostrano la maturità del pacchetto, pertanto è opportuno esplicitare le prime e far leggere
esplicitamente le seconde.
6.6 Cooperazione nello sviluppo.
Le organizzazioni di produzione conferiscono alla KEB conoscenze circa: vari modelli
(risorse, qualità, prodotti e processi), eventuali componenti di prodotto e di processi e dati da
cui poter ricavare esperienza circa l’applicazioni di tali conoscenze. Prelevano da KEB
conoscenza ed esperienza per supportare progetti in essere o in divenire. Trasferiscono le
innovazioni contenute nei KEP nei processi di business, rilevando ulteriori esperienze che
conferiscono alla KEB.
Le organizzazione di ricerca o i singoli ricercatori interni od esterni alle imprese:
conferiscono risultati di ricerca, anche se senza esperienza; producono dai risultati di ricerca,
rilevati da diverse fonti, innovazioni tecnologiche; ricavano conferme o smentite della
conoscenza contenuta in un KEP attraverso indagini empiriche di diverso tipo; prelevano da
KEB risultati di ricerca provenienti da diverse fonti per produrre nuovi risultati di ricerca.
38/38
Valori di PROMETHEUS
Gli organismi che hanno capacità, validate attraverso i progetti a cui hanno partecipato,
possono esplicitare queste nel CM. La stesse informazioni possono essere conferite alla KEB
dai soggetti fisici che hanno competenze esplicitabili in CM e validabili con progetti in PR.
Se alcune di queste competenze possono essere utili per l’adozione di uno o più KEP, esse
sono messe in relazione con questi ultimi. Gli organismi che cercano competenze
specialistiche, per un progetto o per l’adozione di un KEP, trovano nella KEB quelle
disponibili con la relativa certificazione. Quando le competenze sono incluse in ulteriori
progetti dagli organismi che le hanno selezionate, la loro certificazione si rinforza a
beneficio di altri organismi che successivamente dovessero cercare le stesse competenze.
Gli organismi di formazione e ricerca mettono a disposizione della KEB, oltre al materiale
di formazione ed addestramento, i test per valutare le competenze utili per l’adozione dei
KEP di cui essi sono i promotori ed, eventualmente, i modelli di decisione per ipotizzare le
iniziative di formazione per recuperare gli eventuali gap di competenza che gli stessi test
dovessero rilevare. Gli organismi utilizzatori della KEB possono utilizzare il materiale
didattico per costituire o migliorare le capacità e le competenze di cui sono già in possesso, i
test per valutare le competenze in essere e le iniziative di recupero per colmare, eventuali,
gap riscontrati. Gli organismi che utilizzano nei propri progetti competenze preparate e
valutate con l’e-learning ed i test disponibili, valutano l’adeguatezza delle competenze. In
caso di carenza, questi organismi conferiscono agli autori dei KEP suggerimenti per il
miglioramento di queste risorse.
7. VALORI DI PROMETHEUS
Per attrarre i soggetti che possono costituire una o più comunità di stakeholders di
PROMETHEUS è opportuno elencare i valori che l’appartenenza a tali comunità genera per
ogni tipo di stakeholders. La lista che segue è esemplificativa e non esaustiva. Alcuni dei
valori elencati sono tipici delle basi di conoscenza altri sono specifici di PROMETHEUS per
i servizi che differenziano questa piattaforma dalle concorrenti note all’autore, attraverso le
fonti pubbliche.
7.1 Soggetti fisici
I soggetti fisici sono knowledge worker non strutturati in alcuna organizzazione. Possono
essere professionisti o ricercatori, dipendentemente dallo scopo del loro lavoro,
rispettivamente: realizzare obiettivi produttivi oppure creare nuova conoscenza e diffondere
l’innovazione tecnologica. Essi possono utilizzare PROMETHEUS per prelevare conoscenze
o pratiche disponibili e possono conferire alla stessa piattaforma esperienze e contributi per il
suo miglioramento. Inoltre, possono rendere disponibili ad altri stakeholders il proprio tempo
e la propria competenza. In questo caso PROMETHEUS rappresenta per loro un marketplace
esteso sull’intero globo.
Un portatore di conoscenza ha ritorni economici non dalla sua conoscenza ma dalla
applicazione della sua conoscenza a scopi produttivi. Inoltre, la conoscenza mantenuta
39/39
inespressa nella mente del portatore è perduta anche da quest’ultimo a causa della volatilità
della conoscenza tacita. Perciò è opportuno che un portatore di conoscenza espliciti le
pratiche per applicarle ed, eventualmente, le sue esperienze nell’applicazione. Conoscenze ed
esperienza esplicitate e pubblicate su PROMETHEUS aumentano la reputazione del loro
portatore e, quindi, la probabilità che egli sia selezionato per essere incluso in nuovi progetti
da altri stakeholders. Questa partecipazione, a sua volta, rafforza la certificazione delle
competenze dichiarate e, quindi, aumenta la probabilità che il soggetto sia selezionato per
ulteriori nuovi progetti.
I soggetti presenti in PROMETHEUS possono certificare la loro competenza attraverso i
progetti a cui hanno partecipato ed i KEP che può produrre e pubblicare. Inoltre, essi possono
far crescere la loro reputazione partecipando al supporto on-line per gli stakeholders previsto
in PROMETHEUS. Questa interazione, inoltre, consente ad ogni soggetto di comunicare con
altri pari ed attraverso lo scambio di informazioni, conoscenze ed esperienze sono favoriti gli
stimoli alla crescita delle proprie competenze [14].
La particolare attenzione alla rigorosa definizione dei contenuti del KEP, utilizzata da
PROMETHEUS, consente di standardizzare i contenuti e quindi di rendere agevole la
comprensione dei KEP. Questo facilità l’acquisizione e minimizza la specializzazione del
KEP. In ogni caso quando si rende necessaria la specializzazione, la standardizzazione dei
contenuti rende più semplice il processo di specializzazione. Quanto detto supporta la
comprensibilità dei KEP da parte degli utilizzatori di PROMETHEUS. Per dare evidenza a
quest’ultima affermazione è stato fatto un primo esperimento che mostra come il KEP è uno
strumento più efficiente ed efficace delle fonti convenzionali per il trasferimento di
conoscenza e delle pratiche di applicazione. Per ragioni di spazio, tale esperimento non è
stato descritto in questo capitolo, ma i lettori interessati possono consultare [4].
7.2 Organizzazioni
Le organizzazioni sono un insieme strutturato di knowledge workers. Sono interessate agli
stessi servizi di questi ultimi con la specificità di intensificazione della relazione e
cooperazione tra i soggetti appartenenti ad ognuna di essa onde patrimonializzare la
conoscenza e l’esperienza di tutti i soggetti fisici appartenenti ad ognuna di loro. In
particolare, qui, interessa la relazione e la cooperazione basato sull’uso di PROMETHEUS e
consistente nello scambio di conoscenza e di tempo tra i soggetti dell’organizzazione e tra
questi ed i soggetti appartenenti ad altre organizzazione. Nella prospettiva di PROMETHEUS
le organizzazioni che interagiscono si comportano come un unico organismo operativo
complesso. Si possono distinguere le organizzazioni produttive e quelle di ricerca. Le prime
hanno particolare interesse nell’accrescere il business, le seconde nell’accrescere la
conoscenza, nell’innovazione e nel trasferire quest’ultima nei processi di business.
La possibilità di utilizzare e specializzare i KEB per lo specifico contesto
dell’organizzazione utilizzatrice preserva la identità di quest’ultima, nonostante la
collaborazione con una comunità basata sulla stessa KEB [5].
40/40
Le conoscenze che costituiscono il KEP rispondono a problemi da diverse prospettive per
uno stesso package ma grazie al modello di strutturazione descritto in questo capitolo, esse
sono partizionate e localizzate nelle varie componenti dello stesso KEP. Inoltre, la struttura
dei contenuti consente al suo lettore di definire un percorso di lettura adeguato al suo stato di
conoscenza pregresso ed alla sua modalità di acquisizione. Per le conoscenze su cui ha meno
informazione, il lettore ha accesso alle fonti di base del KEP. In caso di carenza di
conoscenze o di abilità per una o più parti del KEP, sono disponibili corsi di formazione e di
addestramento e test di valutazione delle competenze. Queste caratteristiche e risorse del
KEP assicurano una rapida socializzazione della conoscenza contenuta in KEP.
L’organismo utilizzatore trova nella KEB risultati di ricerca che possono essere usati per
raggiungere più rapidamente gli obiettivi aperti dell’agenda di ricerca o di rispondere ai
problemi aperti per l’innovazione richiesta per il proprio vantaggio comparativo. Il KEP ha
tra le altre conoscenze disponibili il processo di adozione, i rischi presentati da tale processo e
le modalità per moderarli. Tutto questo consente all’organismo adottante da un lato un
significativo benchmark che favorisce l’adesione all’adozione da parte dei knowledge-worker
interni allo stesso organismo. Inoltre la rapida socializzazione dei KEP lo rende uno
strumento che favorisce la produzione rapida di nuova conoscenza o la tempestiva
innovazione dei processi di business.
La EF consente di accumulare dati rilevati nei progetti eseguiti che elaborati diventano
evidenza empirica della validità di un KEP. Queste stesse analisi consentono di migliorare
continuamente i KEP in tutte le loro componenti con conoscenza appresa durante il lavoro
(near the job learning) che dà maggiore confidenza nell’uso del KEP da parte di tutti gli
organismi interessati.
Nei KEP, grazie alla conoscenza appresa durante il lavoro, sono esplicitate conoscenze che
normalmente sono tacitamente accumulate nella mente di project manager o espresse in
documenti vari distribuiti nell’organizzazione di un organismo e difficilmente localizzabili.
Se i contenuti di KEP riguardano problemi della gestione dei progetti, l’acquisizione di
conoscenza migliora le pratiche di gestione dei progetti contenuti in essi. Se, invece, il
contenuto dei KEP riguarda altri problemi aperti del processo di business le sue componenti
ed il loro miglioramento indicano il processo più adeguato per l’adozione dell’innovazione i
rischi che si possono presentare e come mitigarli. In ogni caso, il KEP consente una migliore
gestione dei progetti da eseguire per tutti gli organismi che utilizzano la KEB.
Nella gestione della cooperazione, la rapidità di socializzazione dei KEP, in tutti gli aspetti
analizzati prima, può essere utilizzata nella omogeneizzazione delle competenze tra tutti gli
organismi cooperanti. PROMETHEUS offre risorse per la validazione empirica delle capacità
degli organismi che sono candidati alla cooperazione. In caso di turnover delle risorse umane,
PROMETHEUS offre risorse rintracciare soggetti fisici che hanno le competenze che si
cercano; oppure per formare rapidamente nuove risorse su uno o più KEP e valutarne
l’adeguatezza.
Nella delocalizzazione della produzione, PROMETHEUS offre risorse per cercare
organismi disponibili a cui commettere i lavori che sono valicati empiricamente. Oppure,
offre risorse per la valutazione delle competenze degli organismi che si candidano per
41/41
Conclusione
l’outsourcing o l’offshoring. In caso di piccoli scostamenti delle competenze degli organismi
selezionati da quelle ritenute necessarie, PROMETHEUS offre risorse utili per la formazione
e l’addestramento e, quindi per il superamento delle eventuali carenze riscontrate nella
valutazione.
E’ il caso di evidenziare che quando un’organizzazione ha bisogno di difendere il proprio
vantaggio comparativo in presenza di rapidi cambiamenti di mercato può trovare supporto
nella comunità che ruota attorno a PROMETHEUS. Infatti, la produzione rapida di nuova
conoscenza ed il supporto nella gestione dei progetti anche quando questi sono distribuiti,
supporta l’organizzazione utilizzatrice nel cooperare con altri organismi o nel delocalizzare la
produzione in modo da accorciare il time-to-market.
Le organizzazioni che partecipano a comunità di scambio di conoscenza ed esperienza,
minimizzano i costi ed i rischi della produzione della conoscenza e dell’esperienza contenuta
nella KEB. Questa minimizzazione costituisce un ritorno; questo ritorno è tanto più elevato
quanto maggiore è l’uso di KEP. In sintesi, PROMETHEUS favorisce l’ economia di scopo
nel mercato interno alla comunità che si crea attorno ad essa.
L’organizzazione che mette a disposizione conoscenza o esperienza definisce anche le
condizioni con cui metterle a disposizione, secondo un suo riservato modello di business,
generando un ritorno sugli investimenti effettuati per creare tali conoscenze.
L’organizzazione che l’acquisisce ha a disposizione risultati di ricerca immediatamente
utilizzabili con costi esattamente definiti, contro la ben nota imprevedibilità dei progetti di
ricerca, che accelera ed economizza. Pertanto, il mercato interno alla comunità che ruota
attorno a PROMETHEUS è in grado anche di creare economia di scala ai fornitori ed agli
utilizzatori di KEP.
8. CONCLUSIONE
In questo capitolo sono state proposte le definizioni di conoscenza e di esperienza
orientate all’adozione dei risultati di ricerca nei processi di business od in progetti di ricerca
che le utilizzino come base di partenza per realizzare nuovi obiettivi di ricerca. Queste
definizioni sono incentrate sul problema a cui la conoscenza vuole dare risposta e
sull’evidenza empirica che i risultati di ricerca piuttosto che le tecnologie derivate da essi
causino la risoluzione dello stesso problema.
Partendo da tali definizioni, tenendo conto delle lezioni apprese, sia quelle note in
letteratura sia quelle apprese dall’autore, si è proposta una struttura di Knowledge-Experience
Package che sia in grado di superare o di contribuire a superare le barriere previste
nell’adozione di nuova conoscenza nei processi di business e nello scambio di risultati di
ricerca. Il contenuto del KEP è complementare alla conoscenza che per lo stesso problema
sono rilevabili dalle fonti convenzionali, perché esso si orienta alle pratiche per l’adozione
efficace della conoscenza. Grazie alla strutturazione il KEP risulta avere un buon livello di
leggibilità e comprensibilità. Di contro, la sua produzione richiede un rilevante impegno
uomo, perciò, si prevede che la produzione sia incrementale ed anche cooperativa, con il
contributo di tutti gli stakeholders di uno stesso KEP.
42/42
Bibliografia
Il capitolo descrive anche una piattaforma, PROMETHEUS, che realizza la gestione della
KEB che raccoglie i KEP che mettono a disposizione la/le comunità che si costituiscono
attorno ad essa. PROMETHEUS prevede che i contenuti dei KEP abbiano la strutturazione,
le componenti e le risorse proposte nello stesso capitolo.
Nell’analisi dei valori producibili da PROMETHEUS per i diversi tipi di suoi stakeholders
si evince che tra gli altri c’è il contributo nel supportare gli organismi utilizzatori a transitare
nell’Economia della Conoscenza. Ed in particolare, nel supportare modelli comportamentali
quali: diversità e vantaggio comparativo basati su competenze ad alto contenuto tecnologico;
Open Innovation, produzione distribuita, Digital Business Ecosystem.
Gran parte delle asserzioni fatte in questo capitolo hanno bisogno di evidenza empirica per
poter diventare patrimonio universalmente accreditato oppure, addirittura, riconosciuto.
Pertanto, c’è da fare molto lavoro per produrre tale evidenza empirica. L’esecuzione di
questo lavoro è un impegno dell’autore che invita tutti i ricercatori, i professionisti e gli
organismi interessati a questi argomenti a collaborare anche attraverso la partecipazione alle
costituende comunità di PROMETHEUS.
9. BIBLIOGRAFIA
1. A.Aamodt, M.Nygard. Different roles and mutual dependencies of data, information and
knowledge - An AI perspective on their integration. Data and Knowledge Engineering, 1995,
vol. 16, pp.191–222.
2. K.Althoff, B.Decker, S.Hartkopf, A.Jedlitschka. Experience Management: The Fraunhofer
IESE Experience Factory. Proceedings of Industrial Conference Data Mining, Leipzig, July
2001.
3. P.Ardimento, M.T.Baldassarre, D.Caivano, G.Visaggio. Innovation Diffusion through
Empirical Studies. In: Proceedings of the 17th International conference on Software
Engineering and Knowledge Engineering (SEKE), Taipei China, July 2005.
4. P.Ardimento, D.Caivano, M.Cimitile, G.Visaggio. “Empirical Investigation of the Efficacy
and Efficiency of tools for transferring software engineering knowledge”, Journal of
Information & Knowledge Management, Volume 7, ISSUE 3, September 2008.
5. P.Ardimento, M.T.Baldassarre, D.Caivano, M.Cimitile, G.Visaggio. “Controlled Experiment
On Search Engine Knowledge Extraction Capabilities”, proceedings of 3rd International
Conference on Software and Data Technologies (ICSOFT), ISBN: 978-989-8111-57-9, pp.
388-395, INSTIC Press, Porto Portugal, 5-8 July 2008.
6. P.Ardimento, M.T.Baldassarre, M.Cimitile, G.Visaggio. “Empirical Experimentation for
Validating the Usability of Knowledge Packages in the Innovation Transfer”,
Communications in Computer and Information Science, ISSN: 1865-0929 (Print) 1865-0937
(Online), ISBN: 978-3-540-88654-9 (Print) 978-3-540-88655-6 (Online), volume 22, pp. 357370, November 2008, Springer Berlin Heidelberg.
7. M.T.Baldassarre, G.Visaggio. Report on Empirical Investigations. White paper:
http://serlab.di.uniba.it/about_us_it/people_it/TBaldassarre_it/.
8. V.R.Basili, C.Caldiera, H.D.Rombach. Experience Factory, Encyclopedia of Software
Engineering. vol.2, pp 469 – 476, John Wiley &Sons, 1994.
9. V.R.Basili et al.: Building Knowledge through Families of Experiments. IEEE Transactions
on Software Engineering, July 1999.
10. V.R.Basili, C.Caldiera, H.D.Rombach. Experience Factory concepts as a set of Experiences
Bases. In: Proceedings of Thirteenth Conference on Software Engineering and Knowledge
engineering (SEKE), pp 102-109, Buenos Aires, Argentina, June 2001.
43/43
Bibliografia
11. H.Chesbrough. Open innovation. Harvard Business School Press, Harvard, 2002.
12. H.Chesbrough. Open Platform Innovation: Creating Value from Internal and External
Innovation. Intel Technology Journal, August 2003.
13. R.Conradi, T.Dingsøyr. Software Experience Bases: A Consolidated Evaluation and Status
Report, PROFES 2000, pp. 391-406.
14. K.C.Desouza, Y.Awazu, P.Baloh. Managing Knowledge in Global software Development
Efforts: Issues and Practices. IEEE Software September/October 2006.
15. P.Dini et alter. The Digital Ecosystems Research Vision: 2010 and Beyond. Creative
Commons, Stanford, California, 2005.
16. Great Britain, Department of Trade and Industry (DTI). Our Competitive futures: building the
knowledge driven economy, DTI, London 1998.
17. Economic and Social Research Council, Annual Report, 2004-2005 Published by The
Stationery
Office
(TSO)
(http://www.officialdocuments.gov.uk/document/hc0506/hc00/0092/0092.asp).
18. R.G.M.Kemp, M.Mosselman, J.Blees, J.Maas (2003), Barriers to entry , Research report by
EIM,
Business
&
Policy
Research,
number
H200301,
153
pages,
http://www.entrepreneurship-sme.eu/pdf-ez/H200301.pdf.
19. D.Foray. The Economics of Knowledge. Cambridge, Mass, London, ISBN 0-262-06239-9,
MIT Press 2006.
20. T.Gorschek, C.Wohlin, P.Garre, S.Larsson. A Model For Technology Transfer in Practice.
IEEE Software November/December 2006.
21. B.Kitchenham et alter. Guidelines for performing Systematic Literature Reviews in Software
Engineering. EBSE Technical Report (2007).
22. D.J.Reifer. Is the Software Engineering State of the Practice Getting Closer to the State of the
Art? IEEE Software, vol. 20, n. 6, pp. 78-83 (2003).
23. K.Schneider, T.Schwinn. Maturing Experience Base Concepts at DaimlerChrysler. Software
Process Improvement and Practice. vol. 6, pp. 85–96, (2001).
24. R.V.Solingen, E.Berghout. The Goal/Question/Metric Method: a Practical Guide for Quality
Improvement of Software Development. McGraw Hill, London, (1999).
44/44

report tecnico - SERLab

Transcript

Documenti analoghi

Determina a Contrarre N.15 2016 - Scuola di Medicina

Provincia di Bari - Città Metropolitana di Bari

Configurazione Outlook express

Ing. Lorenzo Ranieri Vice Presidente vicario È nato a Bari il 7 luglio

WHAT ACTUALLY HAPPENS WHEN GRANULAR MATERIALS

Scheda SEAP - Città Metropolitana di Bari

GYROTONIC® Pre-training liv 1

27.28 MAGGIO 2016 | BARI, Hotel Oriente

Azadi Giada Dottoranda di Ricerca - Ph.D