Elaborato Picardi Massimo N46-025

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Programmazione
Valutazione della cooperazione durante lo
sviluppo cooperativo del software
nell'ambito del progetto ETCplus
Anno Accademico 2011/2012
Candidato:
Massimo Picardi
matr. N46/ 025
I
Alla mia famiglia,
sopratutto a mia Nonna.
II
Indice
Introduzione
5
Capitolo 1. Lo sviluppo cooperativo del software
7
1.1
1.2
1.3
1.4
1.5
La cooperazione, il coordinamento e la comunicazione
Servizi per lo sviluppo cooperativo
Il processo di sviluppo del software
La piattaforma Jazz IBM Rational
La metodologia Scrum su Jazz
8
9
11
13
16
Capitolo 2. Strumenti per la misurazione del grado di cooperazione
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.3
19
Il modello Goal Question Metric (GQM)
Il processo GQM per lo sviluppo cooperativo
Prestudio
Identificazione dei goal e GQM plan
Sviluppo del Measurement plan
Raccolta, validazione e analisi dei dati
Packaging dell'esperienza
Validazione del GQM Plan sviluppato
20
22
23
24
36
41
41
42
Capitolo 3. Considerazioni finali
3.1
3.2
43
Conclusioni
Sviluppi futuri
43
44
Bibliografia
45
III
Indice delle figure
Figura 1: Sviluppo Cooperativo ........................................................................................................... 8
Figura 2: Architettura di Jazz ............................................................................................................. 13
Figura 3: Jazz is Client-Server platform ............................................................................................ 14
Figura 4: La piattaforma Jazz............................................................................................................. 14
Figura 5: Prodotti Rational ................................................................................................................. 16
Figura 6:Scrum ................................................................................................................................... 17
Figura 7: Struttura gerarchica del GQM ............................................................................................ 21
Figura 8: Goal Selection Sheet........................................................................................................... 25
Figura 9: Coordination for Goal......................................................................................................... 25
Figura 10: Goal Template Sheet ........................................................................................................ 26
Figura 11: Goal Abstraction Sheet ( High Level) .............................................................................. 30
Figura 12: Ciclo di vita di un GQM ................................................................................................... 30
Figura 13: GQM Plan ......................................................................................................................... 34
Figura 14: Goal Abstraction Sheet (Low Level) ................................................................................ 35
Figura 15: Metrica del Measurement Plan ......................................................................................... 37
Figura 16: Descrizione metrica ValDoc............................................................................................. 40
Figura 17: Descrizione metrica PerGlob ............................................................................................ 40
IV
Introduzione
Negli ultimi anni, l'industria informatica ha subito una forte spinta verso la
globalizzazione organizzando, di conseguenza, lo sviluppo del software su base spazio
temporale. Questa suddivisione porta alla creazione di vari gruppi di lavoro, di veri e
propri team, all'interno dei quali ogni membro riveste un determinato ruolo al quale sono
associate diverse responsabilità e capability. Come si può facilmente dedurre, in un tale
scenario svolge un ruolo fondamentale la comunicazione tra i membri di un team (analisti,
sviluppatori, tester, ecc). La comunicazione è fondamentale in quanto consente il
coordinamento del lavoro tra i membri e avrà esito positivo se viene fatta in tempi
prestabiliti, attraverso i vari canali di comunicazione che sono messi a disposizione dalle
attuali tecnologie.
A tale fine, il progresso della tecnologia ha portato alla creazione di ambienti di sviluppo
idonei per lavorare in team, facilitando cosi l'attività globale di sviluppo di un sistema
informatico. Questi nuovi ambienti di sviluppo supportano sia gli aspetti tecnici sia quelli
organizzativi, come ad esempio la suddivisione dei compiti, rivelandosi un importante
prerequisito per la produzione di sistemi software di alta qualità. Poichè, come detto,
vengono supportati anche gli aspetti organizzativi, ogni membro del progetto, oltre alle
attività normali di produzione del software, dovrà avere una buona predisposizione al
lavoro in team e quindi alla cooperazione, definendo così un nuovo tipo di sviluppo: lo
sviluppo cooperativo. Questa modalità di sviluppo del software è un intenso processo di
cooperazione tra i membri del team di lavoro con ruoli diversi. Grazie alla suddetta
modalità, la qualità finale del sistema dipenderà dalle abilità di ogni membro di sviluppare,
5
Jazz e le sue tecnologie per lo sviluppo cooperativo.
condividere, coordinare e integrare le informazioni.
Nell'organizzazione e nella gestione di un progetto e/o di un team di lavoro, come
preannunciato, assumono particolare importanza i processi di divisione del lavoro, di
comunicazione, coordinamento e cooperazione della pianificazione, e i processi di
sviluppo e di manutenzione dei sistemi informatici.
A tale scopo, questo tipo di ambiente di sviluppo dovrebbe fornire una serie di strumenti e
convenzioni affinchè tutti lavorino conoscendo le specifiche del progetto da realizzare.
Inoltre, a causa della distribuzione spaziale e temporale di tale sviluppo, la cooperazione
tra i membri del progetto è spesso asincrona. Grazie a questo ambiente di sviluppo e
quindi grazie agli strumenti che mette a disposizione, come quelli per la sincronizzazione
delle attività, si abbattono tali barriere.
Ma come misurare il livello di cooperazione delle varie comunità all'interno di un
progetto? Nel seguito vedremo come applicare un approccio per lo sviluppo di un sistema
di misurazione. Questo approccio, chiamato Goal Question Metric, è basato
sulla
definizione di obiettivi da perseguire, sulle domande che bisogna porsi per caratterizzare
tali obiettivi e, infine, sulla definizione di metriche che utilizzeremo per effettuare tali
misurazioni e grazie alle quali è possibile trarre delle conclusioni dopo aver raccolto dati
utili.
6
Valutazione della collaborazione durante lo sviluppo cooperativo
del software nell'ambito del progetto ETCplus
Capitolo 1
Lo sviluppo cooperativo del software
Lo sviluppo cooperativo del software è un intenso processo di cooperazione che permette
di sviluppare un sistema software attraverso la definizione di uno o più team di lavoro, nel
quale ad ogni membro viene assegnato un determinato ruolo. In questo contesto, ogni
membro può trovarsi spazialmente distante anche migliaia di chilometri da un qualunque
altro membro del team di sviluppo. Di conseguenza, i prerequisiti per lo sviluppo di un
sistema informatico vanno oltre gli aspetti tecnici. Infatti, la qualità del target di un
prodotto, così sviluppato, sarà determinata in buona parte dall'aspetto organizzativo che
caratterizzerà proprio la fase di sviluppo del lavoro.
In questo scenario saranno due i fattori primari che devono essere assolutamente
considerati: gli individui che dovranno sviluppare il software e la tecnologia che sarà
utilizzata per sviluppare il lavoro futuro. Infatti, data la suddivisione su base spaziotemporale, occorre disporre di un insieme di tecniche e di tools che facilitano il
coordinamento e la comunicazione tra i membri dei team di sviluppo. Oltre alla tecnologia
usata, la predisposizione al lavoro in team è una caratteristica fondamentale che ogni
individuo dei team di lavoro deve avere, al fine da rendere la comunicazione e il
coordinamento con gli altri membri veloce ed efficiente.
7
1.1 La cooperazione, il coordinamento e la comunicazione.
La condivisione delle informazioni (vedi fig.1) durante lo sviluppo cooperativo del
software è fondamentale per avere un prodotto finale funzionante, efficiente e sopratutto
che rispecchia le specifiche imposte dal committente. Questo processo di condivisione
delle informazioni avviene attraverso il processo di comunicazione, che permette a due o
più membri di scambiarsi informazioni attraverso i mezzi di comunicazione forniti dalla
attuale tecnologia. Inoltre, il processo di comunicazione permette anche ad ogni membro
di condividere la propria conoscenza sul lavoro con gli altri membri che, in base al livello
di libertà nel progetto, può appartenere o meno allo stesso team di lavoro. Attraverso il
processo di comunicazione è possibile coordinare il lavoro dei membri dei team, al fine di
far svolgere ad ognuno di essi attività diverse ma che confluiscono in un obiettivo comune.
I team, che utilizzano questi processi, cooperano al fine di sviluppare un prodotto dal
target di qualità elevato.
Ricapitolando, i processi fondamentali che caratterizzano lo sviluppo cooperativo sono:

La comunicazione: è quel processo con cui un membro scambia e condivide
informazioni con un altro gettando le basi per il processo di coordinamento.

Il coordinamento: è l'insieme delle attività necessarie per accordarsi sul lavoro da
svolgere, ad esempio definire quali sono i task di ogni membro, quando saranno
svolti i meeting etc. , in quanto il lavoro di ognuno di essi risulta essere diverso.

La cooperazione: quel processo in cui i membri dei team operano insieme al fine di
raggiungere un obiettivo comune.
Figura 1: Sviluppo Cooperativo
8
Il coordinamento dei team per lo sviluppo di sistemi di grandi dimensioni è il lavoro più
difficile da compiere. Ogni ambiente di sviluppo cooperativo dovrebbe offrire servizi che
semplificano tale lavoro rendendolo più praticabile. Ad esempio, dovrebbero offrire
servizi per la definizione dei ruoli, per la formazione dei team, per l'analisi e la definizione
delle specifiche, servizi per lo sviluppo, il testing e il debugging del sistema informatico.
Questi servizi si basano sulla comunicazione che, grazie alla condivisione delle
informazioni, possono far interagire e confrontare i membri dei team, rendono il lavoro di
coordinamento tra i membri dei team, oppure tra i team stessi, intuitivo. Questo permette
ad ogni membro di poter svolgere il proprio lavoro autonomamente senza alcun vincolo,
se non quello delle specifiche dettate dal committente.
Una volta che vengono condivise le informazioni e si avvia il processo di sviluppo
cooperativo, si potrebbero formulare domande sulla validità di tale cooperazione. Avere un
alto livello di cooperazione tra i membri dei team permette di sviluppare un prodotto finale
di ottima qualità.
1.2 Servizi per lo sviluppo cooperativo.
Uno dei fattori principali dello sviluppo cooperativo è rappresentato dalla tecnologia
utilizzata durante tale processo. Per tecnologia si intende l'insieme di tecniche e tools che
permettono di facilitare i processi di cooperazione, coordinamento e di comunicazione tra i
membri dei team di lavoro. Di conseguenza, il tool che bisogna utilizzare per il processo di
sviluppo cooperativo è una piattaforma che deve offrire servizi riguardanti sia l'aspetto
tecnico sia quello organizzativo. Possiamo raggruppare questi servizi in varie categorie:

Servizi per la definizione dei team. Lo sviluppo cooperativo si basa sulla
suddivisione del lavoro tra i vari team di sviluppo che cooperano al fine di
9
raggiungere un obiettivo comune. Di conseguenza, un ambiente di sviluppo
cooperativo deve fornire servizi per la definizione e creazione dei team.

Servizi per la definizione delle politiche di sicurezza e responsabilità. Come
accennato, ad ogni membro di un team viene assegnato un ruolo all'interno del
team stesso. Un ruolo è un insieme di comportamenti attesi, di obblighi e di
aspettative che dovrebbe ricoprire un insieme di individui di una determinata
posizione all'interno del progetto. Quindi bisogna offrire servizi per la definizione
di politiche di sicurezza che caratterizzano i ruoli e che determinano le attività
consentite all'interno del progetto da un determinato insieme di individui.

Servizi per la gestione delle risorse umane. Questi servizi riguardano l'aspetto
organizzativo dello sviluppo cooperativo. Inizialmente bisogna accogliere
l'individuo in tale ambiente offrendogli la possibilità di fornire informazioni che,
condivise con gli altri membri, potrebbero sollecitare alla comunicazione tra gli
stessi, come ad esempio informazioni riguardanti la propria email, numero
telefonico, nome skype etc. In questo contesto, si offre la possibilità di condividere
anche informazioni circa il proprio ruolo all'interno del team di sviluppo.

Servizi per la comunicazione. Come detto, la comunicazione all'interno di questo
genere di sviluppo è un processo fondamentale. Di conseguenza, questi servizi
permettono di eseguire tale processo, definendo sia una comunicazione diretta sia
indiretta tra due o più membri. Ad esempio, un ambiente di sviluppo cooperativo
dovrebbe fornire una chat interna.

Servizi per la pianificazione delle attività. Sono servizi predisposti alla definizione
e gestione delle attività che ogni membro dovrebbe eseguire in un certo lasso
temporale, al fine di raggiungere gli obiettivi preposti. E' importante che tali
10
servizi, oltre ad offrire la possibilità di impostare una priorità per ogni attività,
offrano meccanismi che le coordinano in caso di imprevisti.

Servizi per la gestione delle modifiche, delle configurazioni e delle versioni.
Consentono di gestire l'accesso concorrente ai file che appartengono al progetto.
Ogni membro del progetto ha infatti la necessità di accedere a tali file e, nel caso
modificarli. In caso di accesso concorrente tali servizi permettono di prevenire la
perdita di eventuali modifiche realizzate contemporaneamente da due membri del
team, in questo modo non solo è possibile conservare ogni modifica ma anche i
dati di chi l'ha apportata.

Servizi per il tracciamento dei bug. Questi servizi consentono di tracciare e di
mantenere una descrizione sui bug riscontrati all'interno del sistema.

Servizi per la definizione di report. Consentono la visualizzazione grafica dello
stato di avanzamento di un attività o dell'intero progetto, il tempo impiegato da un
team in ogni fase e il suo carico di lavoro. Tali informazioni sono fondamentali
visto che il software è intangibile, infatti senza non si potrebbero aggiornare le
stime dei costi e la tempistica per lo sviluppo definitivo.
1.3. Il processo di sviluppo del software
Lo sviluppo cooperativo del software è un processo ciclico ed incrementale. Durante la
realizzazione di un sistema software possono nascere nuove esigenze o nuove specifiche
dettate dal committente che richiederebbero degli adattamenti. Di conseguenza, le attività
vengono ripetute ogni qual volta il sistema viene rielaborato in risposta ai cambiamenti
richiesti. Perciò questo tipo di processo non può essere unico bensì deve essere ciclico ed
11
incrementale [1]. Con questa tecnica, il committente inizialmente identifica i requisiti e le
funzionalità che il sistema dovrà fornire e li classificherà in base alla loro priorità.
Successivamente, viene definito il numero di incrementi, con i quali si vogliono
suddividere le attività di specifica, progettazione e implementazione del software. In
questo modo, alla fine di ogni incremento viene rilasciata al committente la funzionalità
sviluppata. I vantaggi di tale tecnica di sviluppo sono molteplici:
1.
Ogni incremento porta al rilascio parziale del sistema futuro. In questo
modo si permette al cliente di utilizzare e di provare il sistema fin dal primo
incremento;
2.
I clienti acquisiscono esperienza sui prototipi iniziali, potendo migliorare di
conseguenza i requisiti degli incrementi successivi;
3.
Diminuisce il rischio di fallimento dello sviluppo poichè si lavora a stretto
contatto con il cliente.
4.
Dato che le funzionalità da sviluppare verranno suddivise in base alla loro
priorità, quelle con più alta priorità saranno sviluppate e consegnate al
committente per prima e, di conseguenza, su di esse saranno effettuati un
gran numero di test. Questo ci garantisce che le funzionalità più importanti
del prodotto finale avranno una probabilità di fallimento molto piccola.
Su tale modalità di approccio allo sviluppo esistono però dei vincoli: gli incrementi
devono essere relativamente piccoli e devono aggiungere parti funzionanti al sistema.
Varianti di questo approccio sono l' Extreme Programming e il più famoso Scrum,
entrambi appartenenti alla famiglia dei metodi Agili.
12
1.4. La piattaforma Jazz IBM Rational
Nei paragrafi precedenti sono stati definiti una serie di servizi che permettono di
sviluppare un processo software attraverso un approccio cooperativo. Questo sarà
possibile se tali servizi potranno integrarsi in modo da condividere informazioni e dati. E'
evidente la necessità di avere piattaforme che rendono possibile tale integrazione e che
automatizzano quelle attività ripetitive semplificando la gestione dei sistemi collaborativi.
Un approccio che si basa su questi principi è il Collaborative Application Lifecycle
Management (C/ALM). Esso supporta anche le moderne metodologie per lo sviluppo,
come quelle Agili. Su tale approccio si basa l'architettura della piattaforma Jazz per lo
sviluppo cooperativo, prodotta da IBM.
Figura 2: Architettura di Jazz
La piattaforma Jazz [5] è stata progettata per supportare chiunque voglia migliorare lo
sviluppo del software. E' una piattaforma (vedi fig.2) che fornisce la base tecnica per
integrare, in un unica struttura, i diversi tipi di strumenti che fanno parte del ciclo di vita
del processo software. Di solito, questi strumenti utilizzati per acquisire e gestire i dati
sono offerti da fornitori diversi e molto spesso non esistono protocolli comuni. Jazz
abbatte tali barriere fornendo interfacce e metodi standard che stabiliscono i collegamenti
tra i dati ospitati, gestiti da altri strumenti e costruiti su tecnologie differenti. Le interfacce,
13
per la ricezione e la trasmissione dei dati, vengono definite dalla Jazz Integration
Architecture (JIA) che è un insieme di tecnologie e di specifiche interconnesse tra loro. La
sua più grande potenza è che comprende strumenti riutilizzabili che accelerano lo sviluppo
e l'adozione di strumenti già esistenti. Inoltre, offre anche specifiche per una migliore
integrazione di, e navigazione tra, le interfacce utenti dei vari strumenti interconnessi. Il
tutto implementato sul sistema software Jazz Team Server (JTS) (vedi fig.3) che fornisce
le funzionalità fondamentali, come Jazz Foundation Services,
che permettono a più
servizi di lavorare insieme creando un vero e proprio server logico, nonostante la loro
totale indipendenza.
Figura 3: Jazz is Client-Server platform
I client (vedi fig.3), per accedere al Server Jazz, possono assumere diverse forme: da un
ambiente di sviluppo integrato IDE, come il famoso Eclipse, a strumenti specifici di Jazz
da riga di comando, oppure tramite i Browsers Web.
La piattaforma Jazz è formata da un architettura e da una serie di framework, come
mostrato in figura (vedi fig.4):
Figura 4: La piattaforma Jazz
14
L'architettura di Jazz permette ai team di navigare nella rete collaborativa ed accedere
facilmente ai processi e/o agli artefatti.
I frameworks e toolkits, invece, sono utilizzati per semplificare e armonizzare
l'implementazione delle applicazioni che fanno uso della tecnologia di Jazz. Le
applicazioni utilizzate in tale ambito basate sulla tecnologia Jazz sono:

Rational Requirements Composer (RRC): permette ai team di definire, gestire e
documentare i requisiti di sviluppo del ciclo di vita di un sistema. E' un
applicazione basata sul web e supporta le più moderne tecniche di sviluppo del
software, come quelle agili, ma supporta anche la tecnica di sviluppo del software
a cascata. Utilizza processi leggeri per la gestione dei requisiti permettendo di
ridurre la rielaborazione dei costi e migliorare i risultati di business.

Rational Team Concert (RTC): fornisce svariate funzionalità integrate che
permettono ai team di collaborare per accelerare lo sviluppo del software. Infatti,
fornisce servizi per la pianificazione delle iterazioni, per la definizione del
processo, per la gestione delle versioni, per il monitoraggio dei bug, per il controllo
del codice sorgente e per il reporting. Tutti i membri dei team possono visualizzare
i progressi globali del progetto facilmente, poichè RTC offre una dashboard
multilivello che visualizza i progressi sia dei team che delle attività di un progetto,
a livelli molto alti.

Rational Quality Manager (RQM): è un software di gestione della qualità e per la
pianificazione e l'integrazione di strumenti per i test automatizzati. Inoltre, può
essere usato da tutti i team, di qualunque dimensione, addetti alla fase di testing e
da qualsiasi tipo di membro, come test manager, test architect ecc. Quando viene
rilevato un bug, grazie ai servizi di tracciabilità offerti dalla piattaforma, è
15
possibile risalire ai requisiti originari del difetto riscontrato durante l'esecuzione
del test.
Durante il ciclo di vita dello sviluppo cooperativo del software, questi tre prodotti Rational
formeranno l'orchestra che produrrà un prodotto finale di alta qualità (vedi fig.5).
Figura 5: Prodotti Rational
1.5. La metodologia di sviluppo Scrum su Jazz
In un ambiente di sviluppo cooperativo come Jazz esistono diversi processi di sviluppo del
software uno fra questi è Scrum (vedi fig.6).
Scrum [6] è una metodologia agile, molto simile all' Extreme Programming, utilizzata per
la pianificazione e la gestione dei progetti. Si può definire Scrum come un approccio:

Adattivo, poichè fornisce funzionalità per la gestione dei cambiamenti permettendo
quindi l'adattamento a nuove specifiche che possono presentarsi in sostituzione di
altre durante lo sviluppo del progetto.

Empirico. Il problema che bisogna risolvere non viene quasi mai capito
16
completamente. Per questo motivo, Scrum preferisce che i team producano
rapidamente release funzionanti, anche non complete, e di rispondere rapidamente
alle esigenze emergenti.

Iterativo e incrementale. Scrum, essendo una metodologia agile e di conseguenza
un' estensione dell'approccio incrementale, si basa sul rilascio di piccoli incrementi
come descritto nei paragrafi precedenti. Questo permette di giungere in maniera
incrementale alla rilascio del prodotto finale. Inoltre, alla fine di ogni incremento
sono previsti degli incontri tra le parti interessate dove è prevista la partecipazione
anche del committente in modo attivo.
Figura 6:Scrum
Quindi alla base di questa metodologia c'è un ciclo di processo ad incrementi, ognuno dei
quali è formato da blocchi rapidi di lavoro chiamati Sprint. Dato che Scrum è un approccio
empirico, per ogni Sprint vengono sviluppate porzioni di codice del prodotto finito, il
quale risulterà alla fine dello sviluppo funzionante ed efficiente. Le caratteristiche che
definiscono gli Sprint provengono dal Product Backlog. Questo artefatto è un elenco di
funzionalità e di requisiti, ordinati in base alla loro priorità, che dovrà possedere il
prodotto finale. Oltre a questo, si dispone di altri due tipi di artefatti, lo Sprint Backlog e il
Burn-Down Chart. Il primo deriva direttamente dal Product Backlog ed è un elenco di
17
requisiti e funzionalità che devono essere implementate in un determinato Sprint in modo
da trasformarli in un incremento del sistema, mentre il secondo è un grafico che mostra
come procede il lavoro nel corso dello Sprint. Questo può essere visionato anche dai
committenti che in questo modo controllano l'avanzamento e il rilascio del prodotto. Ogni
Sprint, inoltre, è preceduto da riunioni tecniche pianificate che sono la vera potenzialità di
questa metodologia. Questi incontri, detti Scrum Meeting, possono essere di vari tipi:
Daily Scrum, Sprint Review e Planning Review e Sprint Retrospective. Durante la Daily
Scrum vengono valutati i progressi del progetto, gli eventuali ostacoli riscontrati e viene
visionato il lavoro che bisogna affrontare nell'immediato futuro, coordinando in questo
modo i membri del team di lavoro ed è di breve durata per non sottrarre tempo allo
sviluppo. Lo Sprint Review e lo Sprint Planning Review sono incontri che permettono di
controllare lo stato di avanzamento verso il rilascio finale del prodotto e di pianificare lo
Sprint successivo. Infatti, durante tali incontri, a cui partecipano il Product Owner, il team
di sviluppo e i committenti, il Product Owner insieme al team decide quali requisiti o
funzionalità del Product Backlog dovranno essere completati nello Sprint seguente,
spostandoli di conseguenza nello Sprint Backlog in base alla loro priorità.
Successivamente, il team deciderà come organizzare il proprio lavoro vista la propria
autonomia. Lo Sprint Retrospective, infine, riguarda fondamentalmente i cambiamenti
delle specifiche iniziali e quindi stabilisce quali adattamenti saranno necessari negli Sprint
seguenti. Il Product Owner non è l'unico tipo di attore in questa metodologia di sviluppo,
infatti ci sono anche lo Scrum Master e il Team Member che compongono il team. Il ruolo
dello Scrum Master è quello di controllare che il processo di sviluppo sia rispettato ed
eseguito correttamente, mentre il Team Member è colui che svolge il lavoro richiesto dal
Product Owner.
I vantaggi di tale metodologia sono molteplici, ma il principale è rappresentato dal ruolo
attivo che assume il committente nello sviluppo del software, grazie alla sua presenza nei
meeting.
18
Capitolo 2
Strumenti per la misurazione del grado di cooperazione
Il grado di cooperazione determina la qualità del processo di cooperazione. Questo indica
come i team interessati allo sviluppo cooperativo di un sistema stanno cooperando al fine
di sviluppare il prodotto richiesto. Ottenere una misurazione in ritardo di questo grado di
cooperazione, potrebbe causare una pessima qualità del prodotto finale. Inoltre, non si
potrebbe intervenire con immediatezza sul processo di sviluppo per cercare di rivitalizzare
i team e di evitare la loro morte. Misurare questo grado di cooperazione aiuta, nel corso
del progetto, a valutare il progresso, ad intraprendere azioni correttive e, sulla base di tali
azioni, a valutare il loro impatto sul progetto stesso. Al fine di migliorare questo parametro
è necessario identificare, quantificare e valutare i fattori di qualità che lo determinano.
Esistono una varietà di approcci per la definizione di obiettivi misurabili, come ad
esempio la Quality Function Deployment, il Goal Question Metric e infine il Software
Quality Metrics. In questo elaborato si presenta l'approccio Goal Question Metric (GQM),
fornendo un applicazione di tale approccio su un progetto di sviluppo cooperativo,
chiamato Enforcing Team Cooperation (ETCplus), il quale vede coinvolti studenti di una
università italiana e una statunitense. Come preannunciato, l'obiettivo (Goal)
dell'applicazione sarà quello di misurare il grado di cooperazione interno a tale progetto.
L'analisi dei dati da cui ricavare tale parametro, verrà effettuata sui risultati ottenuti dalla
misurazione tratta utilizzando delle metriche (Metrics) in risposta ad alcune domande
(Questions) che caratterizzano l'obiettivo da perseguire.
19
2.1 Il modello Goal Question Metric (GQM)
Questo approccio fu sviluppato nei laboratori di ingegneria del software presso l'università
del Maryland da Victor Basili [2]. Originariamente fu definito per valutare i difetti dei
progetti della Nasa per poi essere ampliato. Questa sua evoluzione permette di poterlo
utilizzare anche in fase di impostazione, con l'obiettivo di migliorare la qualità evolutiva
di un organizzazione.
Il GQM permette di definire un sistema per la misurazione mirata ad un particolare
insieme di problemi. Per sviluppare tale sistema di misurazione si attraversano tre livelli di
specifica:
1. Conceptual Level (Goal). In questa fase concettuale si definiscono gli obiettivi,
rispetto ai vari punti di vista, che bisogna prendere in considerazione in un
particolare contesto per migliorare il business dell'organizzazione. Gli obiettivi
vanno definiti per ogni oggetto sul quale si desidera effettuare una misurazione.

Prodotti: artefatti o documenti prodotti durante il ciclo di vita del sistema;

Processi: attività del processo software, come ad esempio la progettazione,
lo sviluppo, le interviste ecc;

Risorse: oggetti utilizzati dai processi al fine di produrre risultati;
2. Operational Level (Question). Per caratterizzare la valutazione o il raggiungimento
di un obiettivo utilizzando un modello caratterizzante si formulano delle Questions.
Queste provvedono a caratterizzare l'oggetto (prodotto, processo o risorsa) in base
al problema di qualità e rispetto al punto di vista considerato.
3. Quantitative Level (Metric). Si definiscono delle metriche per la misurazione finale
che verrà effettuata dopo la raccolta dei dati significativi. Queste metriche
20
dovranno rispondere alle Question, sviluppate in precedenza, in modo completo ed
efficiente. Le metriche possono essere:

Oggettive: se i dati dipendono solo dall'oggetto che viene misurato e non
dal punto di vista.

Soggettive: se i dati dipendono sia dall'oggetto che viene misurato sia dal
punto di vista.
Ovviamente ci sarebbe un ulteriore fase, cioè quella di interpretazione dei dati raccolti per
definire il livello di qualità del goal sotto analisi.
Dal punto di vista strutturale, un modello GQM presenta un architettura gerarchica
costituita da un albero (vedi fig.7). La radice di questa gerarchia è il Goal, il quale si
suddivide in vari rami che convergono nelle Question che lo caratterizzano e da queste
vengono sviluppate le Metric, che lo caratterizzano in modo quantificabile. Ogni metrica
può anche essere utilizzata per rispondere a più Question di uno stesso goal, anche se
potrebbe assumere valori diversi in base ai punti di vista da cui si osserva.
Figura 7: Struttura gerarchica del GQM
Come si può dedurre dai livelli di specifica, questa metodologia utilizza un approccio topdown. La misurazione deve focalizzarsi su un obiettivo e solo successivamente analizzare
i dati raccolti attraverso le question e le metriche definite in precedenza. L'approccio
inverso, cioè quello bottom-up, non sarebbe idoneo in quanto si potrebbero raccogliere
dati superflui e si perderebbe chiarezza durante la fase di definizione delle metriche.
21
2.2 Il processo GQM per lo sviluppo cooperativo
Come si può ben immaginare, la corretta definizione degli obiettivi è fondamentale per la
corretta applicazione del metodo GQM. Possiamo suddividere il processo di tale approccio
in varie fasi metodologiche, che comprendono l'identificazione e la definizione dei Goal,
delle Question e delle Metric [3]:
1. Prestudio: in questa fase si considerano le precondizioni, i vincoli, i dati, le
caratteristiche del processo e gli obiettivi di business dell'azienda. Queste
caratteristiche di studio vengono acquisite tramite documenti, questionari,
interviste e raccolte di impressioni informali. In questa fase inoltre, sono presenti
anche le attività di brainstorming e brainwriting, ovvero quelle attività dedicate a
far emergere una lista di idee volte alla risoluzione dei problemi che potranno
essere riscontrati in futuro.
2. Identificazione degli obiettivi GQM: in questa fase vengono identificati una serie
di goals per il miglioramento dell'attività. L'identificazione degli obiettivi si basa
su tre fonti di informazioni fondamentali, che sono:

la politica e le strategie dell'organizzazione;

la descrizione dei processi e dei prodotti dell' organizzazione;

il modello dell'organizzazione.
3. Produzione di un GQM Plan:
partendo dagli obiettivi definiti nella fase
precedente, si definisce un documento nel quale si assocerà ad ogni question, che si
andrà a sviluppare, una o più metriche. Questo documento si chiama GQM plan.
4. Produzione di un Measurement Plan: Una volta sviluppato il GQM Plan, in cui
sono definite sommariamente le metriche, si sviluppa un ulteriore documento che
22
descrive nello specifico le caratteristiche di ogni metrica.
5. Raccolta e validazione dei dati: Una volta deciso come e quali dati raccogliere, si
passa alla raccolta e alla validazione degli stessi in accordo con il GQM plan e il
measurement plan.
6. Analisi dei dati: in questa fase, analizzando i dati raccolti, si estrae il grado di
corrispondenza di quest'ultimi con i goal a cui erano connessi.
7. Packaging dell'esperienza: tutta l'esperienza ricavata con l'applicazione di questa
metodologia, verrà conservata per riusi futuri.
Dall'ultima fase si può dedurre che per ognuna delle fasi descritte bisogna produrre una
documentazione. Inoltre si può capire che questo processo è riusabile ed è facilmente
modificabile grazie alla documentazione fornita.
2.2.1 Prestudio
Come detto in precedenza, l'obiettivo di questo elaborato è quello di applicare l'approccio
GQM nel contesto del progetto ETCplus che coinvolge gli studenti dell'università
Federico II di Napoli e della Kent State University di Stark (USA).
Nel progetto sotto esame, si vuole progettare e sviluppare un software per una Automated
Teller Machine (ATM) che permetterà agli utenti di una banca di eseguire le classiche
operazioni bancarie come quelle di prelievo, di visualizzazione del conto ecc.
Dato che gli sviluppatori, ovvero gli studenti delle due università, sono distanti migliaia di
chilometri, questo lavoro sarà effettuato attraverso l'utilizzo della piattaforma Jazz per lo
sviluppo cooperativo. Quindi saranno utilizzanti anche gli strumenti che ci mette a
23
disposizione, quali Rational Team Concert che sarà usato sia sottoforma di servizio web
sia sottoforma di IDE, costituito in questo caso da Eclipse.
Una prima osservazione da fare è che sicuramente gli studenti non hanno una grandissima
esperienza nel contesto dello sviluppo cooperativo, in quanto potrebbero avere una
conoscenza limitata non avendo mai partecipato a progetti dove si utilizzano le tecniche e i
tool tipiche del progetto ETCplus.
Queste informazioni sono importanti in quanto una loro gestione ottimale ci permetterà di
amministrare al meglio le risorse umane che si hanno e, di conseguenza, di pianificare al
meglio lo sviluppo cooperativo del software.
Questo genere di informazioni, e insieme a tante altre, creeranno una visione migliore del
contesto sul quale applicheremo il processo GQM formando, inoltre, una solida
documentazione sulla quale si baserà tale processo.
Infine, in questa fase attraverso attività di brainstorming e di brainwriting sono emerse
idee su come migliorare lo sviluppo cooperativo. L'idea principale è quella di migliorare il
processo di cooperazione tra i membri dei team e i team stessi, al fine di garantire un
prodotto finale di buona qualità.
2.2.2 Identificazione dei goal e GQM plan
Dopo la fase iniziale di prestudio, nasce la necessità di creare procedure per lo sviluppo
dei goal. Grazie al Goal Selection Sheet (vedi fig.8) è possibile identificare e definire
sommariamente gli obiettivi che si devono perseguire. Questo documento è così formato:
24
Important
Important
Not
Not Urgent
Urgent
Es. Obiettivi banali e
Es. Obiettivi che bisogna
semplici da svolgere
controllare anche se non
di alta priorità.
Es. Obiettivi di sviluppo di
Es. Obiettivi riguardanti
nuove attività che potrebbero
entità scadute o in crisi
potenziare il processo
globale
Figura 8: Goal Selection Sheet
Questo è un documento che identifica, definisce e cataloga gli obiettivi in base alla loro
priorità, ma li descrive in maniera astratta e complessa. Nel nostro caso, il Goal Selection
Sheet sarebbe inutile in quanto l'obiettivo da perseguire è unico e quindi con priorità
massima.
Per avere una descrizione più dettagliata dei Goal bisogna introdurre il Goal Template
Sheet che rende tali entità elementari e meno astratte. Come mostrato nella figura seguente
(vedi fig.9), gli attributi che troviamo all'interno di questo documento definiranno le
coordinate per la creazione del goal. Queste coordinate sono fondamentali, poichè
individuano in modo univoco il goal.
Figura 9: Coordination for Goal
25
Per identificare i Goal si analizzano i documenti ricavati durante la fase di prestudio.
Infatti, in questi documenti sono presenti informazioni che contribuiranno alla rilevazione
delle coordinate del goal. Queste sono state ricavate in precedenza da varie fonti come:
1. policy e strategie delle due università. Da questa fonte si ricava sia il problema,
che nel nostro caso rappresenta la cooperazione, sia lo scopo dell'obiettivo, ovvero
migliorare tale cooperazione;
2. descrizione dei processi e dei prodotti utilizzati, quali Scrum, RTC ed Eclipse. Le
informazioni ricavate da questa fonte forniscono chiarezza sull'oggetto del Goal
che nel nostro caso rappresenta un processo, ovvero lo sviluppo cooperativo del
software.
3. dal modello del progetto ETCplus. Studiando il modello, e quindi la struttura,
dell'organizzazione del progetto si ricava il punto di vista del Goal. La struttura
organizzativa del progetto ETCplus è formata da due Scrum Master e da 8 team di
lavoro ognuno formato da un Team Leader, un Vice Team Leader e due Team
Member. Quindi, come ultima coordinata per la definizione del nostro Goal,
selezioniamo il punto di vista dello Scrum Master.
A questo punto è possibile sviluppare il Goal Template Sheet seguente (vedi fig.10):
Goal Template Sheet
Purpose:
Issue:
Object:
Viewpoint:
Context:
Migliorare
Cooperazione
Sviluppo
Scrum Master
ETCplus
cooperativo del
Project
software
Figura 10: Goal Template Sheet
26
Per raffinare il Goal, questi attributi non bastano e quindi si utilizza un ulteriore
documento chiamato Goal Abstraction Sheet (vedi fig.11) che viene integrato con il
precedente. Questo nuovo documento ha il compito di migliorare la leggibilità e
monitorare nel migliore dei modi il processo GQM, caratterizzando i Goals che ne fanno
parte. Grazie a questo documento è possibile dettagliare le caratteristiche del Goals
ponendosi delle domande significative. In questo contesto, la conoscenza del dominio del
progetto è fondamentale per la definizione delle Question e delle Metric. Infatti, per
caratterizzare il Goal si inseriscono alcune domande fondamentali:
1. Come è possibile caratterizzare l'entità (prodotto, processo o risorsa) rispetto al
goal? (Quality Focus)
2. Quali sono i valori assunti dalle caratteristiche dell'entità che caratterizza il goal?
(Baselines Hypothesis)
3. Quali sono i fattori che influenzano il goal? (Variation Factors)
4. Al variare dei fattori di influenza, come si comportano le caratteristiche?
(Baselines Impacts)
Le informazioni, per rispondere a tali domande, vengono recuperate attraverso
l'interazione con chi utilizza l'entità da valutare e/o utilizzandola in prima persona. Dopo
aver caratterizzato il Goal, bisogna valutare il grado di qualità dello stesso.
27
Goal Abstraction Sheet (High Level)
Purpose:
Issue:
Object:
Viewpoint:
Context:
Migliorare
Cooperazione
Sviluppo
Scrum Master
ETC Project
cooperativo
del software
Quality Focus:
Variation Factors:
Comunicazione
VF1: Numero di informazioni condivise tra i
Coordinamento
membri dello stesso e di diversi team;
VF2: Numero di barriere linguistiche riscontrate
durante la comunicazione interna ed esterna a un
team;
VF3: Numero di task completati nel tempo stimato,
durante e nel tempo aggiuntivo;
VF4: Numero di persone esperte sulle tecniche e
sui tools all'interno di ogni team;
VF5:Qualità degli Sprint, in particolare dei Release
Backlog e Sprint Backlog;
Baselines Hypothesis:
Baselines Impacts:
BH1: Due valori di soglia che
BI1: Aumentare la percentuale di informazioni
definiscono il numero minimo di
scambiate e condivise tra i membri all'interno del
informazioni
team, facilità e migliora la comunicazione tra gli
che
dovrebbero
essere condivise tra i membri dello
stessi.
stesso team e di team diversi.
BI2: Diminuire la percentuale di membri che
riscontrano
definiscono il numero massimo di
comunicazione con altri membri all'interno del
barriere linguistiche che potrebbero
team, permette di incitare e di migliorare la
essere riscontrate dai membri dei
comunicazione, migliorando di conseguenza anche
barriere
linguistiche
nella
28
team durante la comunicazione
la cooperazione tra gli stessi.
interna e esterna al proprio team.
BI3:
scambiate e condivise tra i membri di team diversi,
rappresentano il numero massimo
facilità e migliora la comunicazione tra i team.
dei task che potrebbero ancora non
BI4: Diminuire la percentuale dei membri che
essere completati dopo il tempo
riscontrano
stimato e quello aggiuntivo.
comunicazione con altri membri di team diversi,
Aumentare la percentuale di informazioni
permette
barriere
di
incitare
linguistiche
e
di
migliorare
nella
la
comunicazione, migliorando di conseguenza anche
la cooperazione tra gli stessi.
BI5: Diminuire la percentuale di Sprint incompleti
migliora il coordinamento tra i team.
BI6: Migliorare la qualità dello Sprint Backlog,
permette di capire che la cooperazione nello
sviluppo di quell'incremento è stata di buona
qualità, migliorando inoltre il coordinamento con
gli altri team.
BI7: Migliorando la qualità del Release Backlog si
migliora il coordinamento con gli altri team.
BI8: Diminuire il numero di task che vengono
completati dopo il tempo stimato, permette di
migliorare il coordinamento tra i membri del team.
BI9:
Diminuire il numero di task che vengono
completati, o non, dopo il tempo aggiuntivo,
permette di migliorare il coordinamento tra i
membri del team.
BI10: Aumentare il numero di individui esperti
delle tecniche utilizzate all'interno del progetto,
29
migliora la qualità della cooperazione.
BI11: Aumentare il numero di individui esperti dei
tool utilizzati all'interno del progetto, migliora la
qualità della cooperazione tra i membri del
progetto.
Figura 11: Goal Abstraction Sheet ( High Level)
A questo punto si entra nell' operational level, ovvero quella fase operativa dedicata alla
formulazione delle Question. Successivamente, si procederà a definire un insieme di
metriche in modo da renderle misurabili, concludendo cosi il modello GQM (vedi fig.12).
Figura 12: Ciclo di vita di un GQM
Per la definizione delle Question si fa riferimento a tre domande:
1. Come possiamo caratterizzare lo sviluppo cooperativo del software rispetto al goal
generale?
Le principali caratteristiche di uno sviluppo cooperativo sono : il coordinamento e
la comunicazione tra i membri dei team. Domande su questi due temi
permetteranno di ottenere informazioni sullo stato della cooperazione. Di
conseguenza, possiamo descriverli formulando Question riguardanti la descrizione
del processo e dei prodotti che vengono usati nel contesto sotto osservazione. Ad
esempio, le Question sui processi potrebbero interessare il numero di informazioni
30
scambiate tra i membri di un team o il numero delle parti del lavoro che non
vengono completate durante un incremento, mentre le Question su i prodotti
potrebbero interessarsi di Scrum e di RTC.
2. Come possiamo caratterizzare gli attributi dello sviluppo cooperativo del software
che sono rilevanti rispetto alla cooperazione stessa?
E' possibile caratterizzarli comparando gli stessi con una stima derivata da dati
simili ricavati da progetti analoghi.
3. Come possiamo valutare le caratteristiche dello sviluppo cooperativo del software
che sono rilevanti rispetto alla cooperazione stessa?
Per valutarle rispetto alla cooperazione si considerano gli attributi precedentemente
menzionati e compararli con i valori guida definiti in fase di analisi.
Seguendo le domande appena descritte con le relative risposte, si può sviluppare il GQM
Plan (vedi fig.13).
Goal
Purpose
Issue
Object (process)
Viewpoint
Context
Migliorare
La cooperazione
Sviluppo cooperativo del
software
Dal punto di vista dello
Scrum Master
Nel progetto ETCplus
Label
Question Q1
Come avviene la comunicazione all'interno di
un team?
Metric
M1.1
NMesInT
Metric
Metric
M1.2
M1.3
DevSta
%TeamUndM
Numero medio di informazioni scambiate dai
membri di un team.
Deviazione standard.
% dei team il cui numero di informazioni
31
Metric
M1.4
InterMemBarIn
Metric
M1.5
NBarrLinTI
Metric
M1.6
%BarrLinTI
Question Q2
Metric
M2.1
Metric
M2.2
Metric
M2.3
Metric
M2.4
Metric
Metric
M1.2
M1.3
Question Q3
InterMemBarEx Valutazione soggettiva di ogni membro del team
riguardante le barriere linguistiche riscontrate
durante la comunicazione con membri di altri
team.
Numero di membri che hanno riscontrato barriere
NBarrLinTE
linguistiche durante la comunicazione con membri
di altri team.
% dei team il cui numero dei membri che ha
%BarrLinTE
incontrato barriere linguistiche durante la
comunicazione verso membri di altri team è al di
sopra della soglia prevista.
Numero medio di informazioni scambiate tra
NMesExT
membri di team diversi.
Deviazione standard.
DevSta
% dei team il cui numero di informazioni
%TeamUndM
scambiate dai propri membri è al di sotto del
limite inferiore.
Come procede il coordinamento all'interno di
un team?
Metric
Metric
Metric
Metric
Metric
M3.1
M3.2
M3.3
M3.4
M3.5
QuaRelBac
QuaSprBac
NSprintInco
NSprintCom
TSprintInco
Metric
Metric
M3.6
M3.7
%SprintInco
NMemTaskIn
Metric
M3.8
NMemTaskIAg
Metric
M3.9
%TaskComASt
Metric
M3.10 %TaskComAfA
Question Q4
scambiate dai propri membri è al di sotto del
limite inferiore (valore di soglia prestabilito).
Valutazione soggettiva, di ogni singolo membro
del team, riguardante le barriere linguistiche
riscontrate all'interno del proprio team.
Numero di membri che hanno riscontrato barriere
linguistiche all'interno del team.
% dei team il cui numero dei membri che ha
incontrato barriere linguistiche interne al proprio
team è al di sopra della soglia prevista.
Come avviene la comunicazione tra i membri di
team diversi?
Qualità del Release Backlog di ogni singolo team.
Qualità dello Sprint Backlog di ogni singolo team.
Numero di Sprint non completati per ogni team.
Numero di Sprint completati per ogni team.
Tempo medio richiesto per completare gli Sprint
incompleti per ogni team.
% degli Sprint incompleti per ogni team.
Numero dei task non completati all'interno di un
team nel tempo stimato.
Numero dei task non completati all'interno di un
team dopo il tempo aggiuntivo.
% dei task completati dopo il tempo stimato
all'interno di un team.
% dei task completati dopo il tempo aggiuntivo
all'interno di un team.
Come procede il coordinamento tra i team?
32
Metric
Metric
M3.1
M4.1
QuaRelBac
%QuaTeaUnL
Metric
Metric
M3.2
M4.2
QuaSprBac
%QuaSprBac
Metric
M4.3
%TeaTaskAfA
Metric
M4.4
%TeaTaskASt
Metric
Metric
M3.3
M3.4
NSprintInco
NSprintCom
Question Q5
Qualità del Release Backlog di ogni singolo team.
% dei team la cui qualità del Release Backlog è al
di sotto del limite inferiore.
Qualità dello Sprint Backlog di ogni singolo team
% dei team in cui qualità dello Sprint Backlog è al
di sotto del limite inferiore.
% dei team il cui numero di task completati dopo
il tempo aggiuntivo supera il limite superiore.
% dei team il cui numero di task completati dopo
il tempo stimato supera il limite superiore.
Numero di Sprint non completati per ogni team.
Numero di Sprint completati per ogni team.
Quale è l'esperienza dei membri?
Metric
M5.1
ConToolsUt
Metric
M5.2
ConTecnUt
Metric
M5.3
%MTecExp
Metric
M5.4
%MToolsExp
Question Q6
Metric
M6.1
DevNMesInTSti
Metric
M6.2
DevNMesExTSt
Metric
M6.3
ValDoc
Question Q7
Conoscenza di un individuo del team circa i tools
utilizzati durante lo sviluppo cooperativo.
Conoscenza di un individuo del team circa le
tecniche utilizzate durante lo sviluppo cooperativo.
% dei membri esperti delle tecniche utilizzate
durante lo sviluppo cooperativo.
% dei membri esperti dei tools utilizzati durante lo
sviluppo cooperativo.
Quale è la deviazione tra il numero corrente di
informazioni scambiate e quello stimato?
Valutazione soggettiva dello Scrum Master.
La performance del processo dei singoli team è
migliorata?
Metric
M7.1
PerMesTIn
Metric
M7.2
PerBarLinIn
Metric
M7.3
PerTaskAfA
Metric
M7.4
PerTaskIn
Metric
M7.5
PerfTotTeamIn
Valutazione soggettiva di ogni membro circa il
33
Metric
M7.6
livello di cooperazione interno al team.
ValMemIn
Metric
M6.3
Question Q8
ValDoc
Metric
M8.1
PerMesTEx
Metric
M8.2
PerBarLinEx
Metric
M8.3
PerfSpri
Metric
M8.4
PerTotTeamEx
Metric
M8.5
ValMemEx
Valutazione soggettiva di ogni membro circa il
livello di cooperazione con membri di altri team.
La corrente performance del processo globale è
soddisfacente dal punto di vista dello Scrum
Master?
La performance del processo tra i team è
migliorata?
Question Q9
Metric
M6.3
ValDoc
Metric
M9.1
PerGlob
Figura 13: GQM Plan
Durante la definizione delle Question e delle relative Metric, si sono caratterizzati i
processi di comunicazione e coordinamento che formano i fattori di qualità dell'obiettivo
da perseguire. Di conseguenza, è opportuno riportare delle modifiche al precedente Goal
Abstraction Template, aggiungendo le ultime informazioni ricavate e rendendolo quindi di
basso livello, poichè viene utilizzato un linguaggio più tecnico (vedi fig.14).
Goal Abstraction Sheet (Low Level)
Purpose:
Issue:
Object:
Viewpoint:
Context:
Migliorare
Cooperazione
Sviluppo
Scrum Master
ETC Project
cooperativo
del software
34
Quality Focus:
M1.1 (NMesInT)
M1.4 ( InterMemBarIn)
M1.5 ( NBarrLinTI)
M2.1 ( InterMemBarEx)
M2.2 ( NBarrLinTE)
M2.3 (NMesExT)
M3.1 ( QuaRelBac)
M3.2 ( QuaSprBac)
M3.3 (NSprintInco)
M3.4 (NSprintCom)
M3.5 (TSprintInco)
M3.7 (NMemTaskIn)
M3.7 (NMemTaskIAg)
M5.1 (ConToolsUt)
M5.2 (ConTecnUt)
Variation Factors:
M1.3(%TeamUndM)
M 1.5(%BarrLinTI)
M 2.2(%BarrLinTE)
M3.6(%SprintInco)
M4.1(%QuaTeaUnL)
M4.2(%QuaSprBac)
M4.3(%TeaTaskAfA)
M4.4(%TeaTaskASt)
M5.3(%MTecExp)
M5.4(%MToolsExp)
M6.1(DevNMesInTSti)
M6.2(DevNMesExTSt)
Baselines Hypothesis:
Baselines Impacts:
M7.1>1
BI1;
M7.2>1
BI2;
M7.3>1
BI3;
M7.4>1
BI4;
M7.5>1
BI5;
M8.1>1
BI6;
M8.2>1
BI7;
M8.3=1
BI8;
M8.4>1
BI9;
M9.1>1
BI10;
BI11;
Figura 14: Goal Abstraction Sheet (Low Level)
35
2.2.3 Sviluppo del Measurement Plan
Dopo aver sviluppato il GQM Plan, per la definizione dei Goals, delle Questions e delle
Metrics, bisogna sviluppare un Measurement Plan per descrivere nel dettaglio tutte le
metriche individuate.
Cosa si intende per metrica? Cosa e come si misura? In effetti si potrebbero effettuare
misurazioni su entità di vario genere, come ad esempio attributi, attività di processo
oppure si potrebbero misurare le risorse. Quindi si definisce:

Misura diretta: se la misura di un elemento non dipende da un altro elemento;

Misura indiretta: se la misura di un elemento dipende da quella di un altro;

Attributo semplice: quando è possibile misurare l'elemento direttamente;

Attributo complesso: quando la misurazione viene fatta in modo indiretto.
A questo punto,
prima di mostrare il Measurement Plan e le sue caratteristiche, è
opportuno evidenziare le differenze che intercorrono tra le metriche e le misure.
Una metrica viene effettuata se l'attributo è di tipo semplice e di conseguenza si effettua
una misurazione diretta. Una misura, a differenza di una metrica, viene effettuata su
attributi complessi quindi effettuando misurazioni indirette.
Si può concludere dicendo che una misura non è altro che funzione di una metrica e,
poichè un oggetto può contenere sia attributi semplici e/o sia attributi complessi, durante
una misurazione possiamo riscontrare una o più metriche.
Una metrica inoltre può essere:

Funzionale: quando riguarda le funzionalità del software;
36

Strutturale: quando riguarda la struttura del software.
Una volta capito il significato di metrica, si può definire il Measurement Plan (vedi
fig.15). Il Measurement Plan è un documento in cui si descrivono nel dettaglio le metriche
definite nel GQM Plan. Ogni metrica viene descritta attraverso la definizione di linee
guida e di specifiche.
Metrics
Definizione:
Tipo di metrica:
Linee guida:
Tipo di scala:
Specifiche:

Chi misura:


Quando misura:
Come misura:
Figura 15: Metrica del Measurement Plan
Come annunciato nei paragrafi precedenti, una metrica può essere di tue tipi:
1. Oggettiva: se l'oggetto di misura non dipende da chi effettua la misurazione;
2. Soggettiva: se l'oggetto di misura dipende da chi effettua la misurazione;
Le scale di valori sono l'insieme dei numeri/simboli, con le relative relazioni che
intercorrono tra di essi, da assegnare ad una entità. Una misurazione di tipo soggettiva può
generare due tipologie di scale di valori:

Nominale: questa tipologia è qualitativa e rileva l'attributo dell'entità
permettendo una classificazione degli oggetti della misurazione in accordo
con esso. In questo caso non abbiamo nessun ordinamento.
37

Ordinale: anche questa tipologia è di tipo qualitativo. In questo caso però si
introduce una relazione d'ordine fra gli oggetti, per cui sapremo determinare
la loro posizione anche se non sapremo quantificarli.
Una misurazione oggettiva, invece, può generare anche altre tipologie di scale di valori:

Intervallo: questa tipologia fornisce il concetto di distanza relativa ed è usata
quando la distanza è significativa;

Ratio: si utilizza se non esiste l'attributo che bisogna misurare dell'entità
sottoposta a misurazione. Questo tipo di scala fornisce il valore zero che ne
rappresenta la totale assenza;

Assoluta: fornisce una strategia di conteggio con la quale è possibile
assegnare un valore univoco ad un elemento.
Di seguito si riportano le ultime due metriche che permettono di ricavare il livello di
cooperazione globale nell'ambito del progetto ETCplus. La prima metrica (vedi fig.16) è
di tipo soggettiva e richiede il parere dello Scrum Master in merito alla cooperazione
interna al progetto.
Metric: M6.3 ( ValDoc)
Definizione:
Valutazione soggettiva
dello Scrum Master.
Tipo di metrica:
Soggettiva
Linee guida:
Tipo di scala:
Ordinale
Specifiche:

Chi misura: Lo Scrum Master


Quando misura: Alla fine di ogni
Una delle coordinate fondamentali del
Come misura:
38
iterazione.
goal è il punto di vista. Nel caso in
esame, il goal deve essere valutato dal
punto di vista dello Scrum Master, che
nel nostro caso è uno dei docenti dei
due corsi universitari. Lo Scrum
Master deve dare una valutazione
soggettiva
sulla
corrente
cooperazione, sia interna che esterna ai
team, che sta avvenendo durante lo
sviluppo cooperativo del progetto
ETCplus.
In particolare, lo Scrum Master,
osservando la qualità degli Sprint, il
numero
di
task
incompleti,
la
percentuale dei membri esperti delle
tecniche utilizzate in un team e i
risultati delle altre metriche definite,
può associare un valore soggettivo alla
cooperazione interna o esterna, a
seconda della question. In particolare:
Mediocre: Il livello di cooperazione
raggiunto non è soddisfacente e non
mostra segnali di miglioramento.
Sufficiente: il livello di cooperazione è
migliorato leggermente, ma dovrebbe
migliorare ancora per garantire un
prodotto finale di buona qualità.
Buono: il livello di cooperazione è
39
accettabile ed è migliorato in modo più
che
soddisfacente
rispetto
al
precedente.
Ottimo: il livello di cooperazione è
eccellente e porterà allo sviluppo di un
prodotto finale di altissima qualità.
Figura 16: Descrizione metrica ValDoc
Successivamente (vedi fig.17), viene calcolato un indice di valutazione del grado di
cooperazione in modo oggettivo, in base ai risultati rilevati da altre metriche e ad un
valore di soglia prestabilito in fase di analisi.
Metric : M9.1 (PerGlob)
Definizione:
Attuale performance della
cooperazione del processo
globale.
Tipo di metrica:
Oggettiva
Linee guida:


Specifiche:
Chi misura: Colui che deve
migliorare
Tipo di scala:
Assoluta
il
processo
di

Come misura: : per valutare tale
metrica si considerano i valori delle
cooperazione durante lo sviluppo
metriche
PerTotTeamIn,
cooperativo.
PerTotTeamEx e un valore di soglia
Quando misura: Alla fine di ogni
prestabilito, cioè ValoreSogliaGlob.
iterazione.
Successivamente, si applica la
formula seguente per comparare i
valori considerati:
Questa metrica permette di valutare
il livello di cooperazione globale
dello sviluppo cooperativo del
software.
Figura 17: Descrizione metrica PerGlob
40
2.2.4 Raccolta, validazione e analisi dei dati.
I dati da raccogliere per la misurazione dell'obiettivo definito nelle precedenti fasi, devono
essere in accordo con i documenti precedentemente sviluppati, ovvero con il GQM Plan e
il Measurement Plan. Si può facilmente dedurre che, grazie all'approccio Goal Question
Metric con il quale si è definito un sistema di misurazione, i dati verranno raccolti
agevolmente e in modo valido.
Il passo successivo alla raccolta e alla validazione dei dati è l'analisi degli stessi. Questa
fase permette di trarre delle conclusioni sull'obiettivo che si voleva perseguire, oltre a
valutare il progresso stesso oppure a intraprendere azioni correttive.
Nel progetto ETCplus, molti dati vengono rilevati semplicemente dai tool o da interviste ai
membri dei team di sviluppo. Infatti, grazie alla piattaforma per lo sviluppo cooperativo
utilizzata e ai servizi che questa integra, è possibile visualizzare il progresso dello sviluppo
cooperativo attraverso grafici e dati che, di conseguenza, verranno utilizzati per rispondere
a determinate Question.
2.2.5 Packaging dell'esperienza.
Durante ogni fase dello sviluppo dell'applicazione è opportuno produrre una
documentazione che risulterà utile per un riuso futuro del processo poichè potrebbe
nascere l'esigenza di estendere tale applicazione a valle di cambiamenti nelle specifiche
dettate dalle fonti protagoniste dell'identificazione dei Goal. Quindi, tutti i documenti che
si producono, come il Goal Selection Sheet, il Goal Template e Abstraction Sheet, il
Measurement Plan, dovranno essere scritti in modo semplice e diretto, facilitando il lavoro
futuro di chiunque abbia la necessità di riusare tale applicazione. L'applicazione sviluppata
per la misurazione del grado di qualità della cooperazione nell'ambito del progetto
41
ETCplus, contiene tre documenti in quanto è un applicazione semplice di un processo
GQM che comprende un solo Goal.
Tra questi documenti è presente l'intero Measurement Plan, in cui vengono descritte nel
dettaglio tutte le metriche utilizzate durante il processo GQM in modo chiaro e leggibile.
2.3 Validazione del GQM Plan sviluppato.
Una volta sviluppato il GQM Plan ci si chiede: " Si sta costruendo ( è stato costruito ) il
GQM Plan giusto?" [4]. Questo permette di verificare se è valido e ben formato. Questa
verifica viene fatta attraverso due tipi di analisi, una semantica e l'altra sintattica.
L'analisi sintattica consiste nel verificare se ogni attributo del modello GQM, ovvero se i
Goal, le Question e le Metric sono chiare, leggibili e complete.
L'analisi semantica consiste nel verificare se il ruolo di ogni attributo è significativo
rispetto all'attributo a cui è associato nella gerarchia ad albero. Ad esempio, ci si può
domandare se le Question sviluppate sono rilevanti rispetto ai Goal associati o se l'insieme
di metriche sviluppate rispondono in maniera completa alla Question a cui sono associate.
Una volta che si è costruito il GQM Plan giusto, si effettuano le misurazioni in base anche
ai valori di soglia derivati dalle indicazioni contrattuali.
42
Capitolo 3
Considerazioni finali
3.1 Conclusioni.
Nei capitoli precedenti si è visto come il processo di cooperazione sia fondamentale
durante lo sviluppo di un software. Tramite l'applicazione del paradigma Goal Question
Metric nell'ambito del progetto ETCplus, è stato possibile controllare il progresso della
cooperazione dello sviluppo cooperativo del software, principalmente attraverso la
definizione di tre documenti: Goal Abstraction Sheet, GQM Plan e Measurement Plan.
In conclusione, adottare il paradigma GQM porta a molteplici vantaggi:
1. Le relazioni tra gli attributi che bisogna misurare e l'obiettivo da raggiungere sono
esplicite;
2. E' possibile controllare e, nel caso servisse, diminuire agevolmente la complessità
del piano di misurazione;
3. Il significato operativo del modello progettato è esplicito e, di conseguenza, chi lo
utilizza per effettuare le misurazioni difficilmente lo interpreterà in modo errato;
4. Il risultato della misurazione è indipendente dal suo misuratore;
5. L'uso contemporaneo della piattaforma Jazz per lo sviluppo cooperativo e questo
approccio permette ad alcune metriche di avere dei risultati immediati;
6. Utilizzare tale paradigma e contemporaneamente il processo Scrum, permette di
effettuare la misurazione del grado di cooperazione alla fine di ogni iterazione,
43
migliorando nel caso servisse la cooperazione delle successive iterazioni.
3.2 Sviluppi futuri.
Durante lo sviluppo del sistema di misurazione attraverso l'applicazione dell'approccio
Goal Question Metric, ci si è concentrati solo su un obiettivo per migliorare la qualità
dello sviluppo cooperativo del software. Il grado di cooperazione tra i membri del team,
anche se è importante, non è l'unico fattore di qualità che caratterizza questo genere di
sviluppo. Individuare altri Goal, e quindi ampliare il sistema di misurazione già definito,
aiuterebbe a migliorare la qualità dello sviluppo e, di conseguenza, del prodotto finale. Per
individuare altri Goal, può bastare anche cambiare il punto di vista considerato nel Goal
sviluppato in questo elaborato. Infatti, se consideriamo ad esempio il punto di vista del
Team Member cambierebbero quasi tutte le metriche e il grado di cooperazione visto da
quest'ultimo assumerebbe una forma diversa.
Aumentando il numero di Goal, si aumenta indirettamente e in modo esponenziale anche il
lavoro che dovrà affrontare colui che dovrà effettuare tali misurazioni. Per facilitare le
attività di raccolta e analisi dei dati, di validazione del GQM Plan e successivamente anche
del Measurement Plan, sarebbe interessante sviluppare un tool ETC_GQM_Tool che aiuti
in tal senso il misuratore. Con questo tool, tali attività si automatizzerebbero fornendo al
misurare il parametro da misurare immediatamente.
44
Bibliografia
[1]
Ian Sormeville (Ottava edizione - 2007) “Ingegneria del software” ;
[2]
Victor Basili, Gianluigi Caldiera ( 1994 ), "Goal Question Metric Paradigm";
[3]
B.Fadini, P.Maresca ,P.Prinetto, C. Sanghez, G.Santiano ( 2006 ),
"The GQM for e-learning" ;
[4]
B.Fadini, P.Maresca, P.Prinetto, G.Santiano (2005 Si-El), "Validation criteria for a
GQM plan for e-learning platforms evaluation"
[5]
jazz.net/library/ , Articoli e documentazione sulla piattaforma Jazz e i suoi servizi
[6]
Ken Schwaber, Jeff Sutherland (2007), "The Scrum Papers"
[7]
Romrao Wagh (2012), "Using Scrum for Software Engineering Class Projects"
45
Ringraziamenti
Il primo ringraziamento va alla mia famiglia, da mia nonna a mio fratello passando per
mia madre, mio padre, mia zia e mia cognata . Durante lo studio sentirsi supportati ti dà la
forza di andare avanti e abbattere tutti gli ostacoli che si trovano lungo il percorso e voi mi
avete sempre dato questa forza, grazie!
Ancora grazie ai miei genitori che mi hanno permesso di studiare e che hanno formato
quell'uomo che sono oggi. Il saper ragionare, prima del sapere, è una caratteristica
fondamentale per ogni individuo e voi mi avete sempre incitato al ragionamento. Come
recita una canzone: "Non so' cosa pensavate quelle notti, ma grazie Mamma e grazie Papà
ne avete fatti due su due."
Un grazie speciale va a mio fratello. In questi anni oltre ad essere sempre presente, sei
stato, e sarai ancora, un punto di riferimento, un esempio da seguire. "Siamo cane e gatto
ma con lo stesso modo di camminare".
Ringrazio anche mio cugino Pasquale con il quale ho iniziato questo percorso e ho
superato molti momenti di difficoltà, ora manchi solo tu come ingegnere, muoviti!
Vorrei ringraziare anche tutti coloro che mi hanno accompagnato in questa avventura
universitaria come Fabio, Genny, Francesco e sopratutto Rosaria la quale veniva
minacciata se non mi inviava l'in bocca al lupo prima di ogni esame. A Fabio, Genny e
Francesco li ringrazio per aver sopportato le mie battute squallide e la mia "scemità"
durante questi anni di studio. Voi due cercate di muovervi eh!
46

Elaborato Picardi Massimo N46-025

Transcript

Documenti analoghi

2. SOSPENSIONE DEL PAGAMENTO DELLE RATE DI MUTUO

SERVIZI AGGIUNTIVI CARTA DI CREDITO COOPERATIVO

Cosa sono le funzioni di metrica (o "metric function")?

FIORDELISI Avv. Teresa, nata a Potenza il 08 luglio 1963 ed ivi

Scarica la scheda del prodotto

Modulo candidatura Consigliere di Amministrazione

49K 49 2011 Software di misura METRIC

Tele Radio Sciacca é una societá a responsabilitá limitata che