Valutazione dello sviluppo cooperativo del software nell'ambito del progetto ETCplus

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Programmazione Valutazione dello sviluppo cooperativo del software nell'ambito del progetto ETCplus Anno Accademico / Relatore: Ch.mo Prof. Ing. Paolo Maresca Candidato: Antonio Daril Crispino matr. N6/7

2

3 Indice Indice delle immagini Capitolo. Lo sviluppo cooperativo del software 5. L'approccio tradizionale 5. L'approccio cooperativo 5. Il ruolo della comunicazione 6. Il Collaborative Application Lifecycle Management 7.5 La piattaforma Jazz 7.6 Il Rational Team Concert 9.7 La gestione cooperativa dei progetti.8 Le metodologie Agili.9 Il framework Scrum Capitolo. L'approccio GQM 5. Le metriche software 5. L'approccio GQM 6 Capitolo. L'applicazione dell'approccio GQM al progetto ETCplus. Il progetto ETCplus. L'applicazione dell'approccio GQM. Considerazioni finali Bibliografia III

4 Indice delle Immagini Figura : Sviluppo cooperativo...6 Figura : Architettura Jazz...8 Figura : Scrum Artifacts... Figura : Struttura gerarchica del GQM...6 Figura 5: Coordinations for Goal...8 Figura 6: Ciclo di vita del GQM...9 Figura 7: Gruppi del progetto ETCplus...

5 Capitolo Lo sviluppo cooperativo del software. L'approccio tradizionale. Lo sviluppo software è un intenso processo collaborativo in cui il successo dipende dall'abilità di creare, condividere ed integrare le informazioni. Il modo tradizionale di lavorare nello sviluppo del software, indipendentemente dalle specifiche tecnologie adottate, prevede diverse fasi di sviluppo separate tra loro ed eseguite in cascata, in contesti separati e, talvolta, con obiettivi contrastanti. Tale filosofia operativa prevede la separazione e l'isolamento dei ruoli, tra i quali la comunicazione avviene solo per via ufficiale e formale, in tempi prefissati e talvolta utilizzando linguaggi, cultura e rituali differenti. Il risultato che si ottiene è che per ogni ruolo e fase si vengono a creare team separati che lavorano ognuno secondo le proprie responsabilità ed in maniera autonoma, portando a conseguenze indesiderate quali reinterpretazioni e rielaborazioni, dovuti ai diversi contesti di sviluppo, e ai conseguenti sprechi di tempo e risorse. Seguendo questo approccio ci si rende subito conto che il rischio di fallimento del progetto è qualcosa di arbitrario, che non è possibile controllare se non al termine del complesso e duraturo processo comprendente tutte le varie fasi. Il progetto, infatti, ha successo solo se, al termine del processo totale, si supera il test di accettazione da parte del cliente nei tempi eventualmente concordati. Nel corso dello sviluppo, quindi, eventuali variazioni di priorità o addirittura eventuali aggiunte di requisiti non possono essere soddisfatti a causa del netto distacco tra team di sviluppo e cliente, portando a risultati poco adeguati o addirittura non accettabili e sprecando, di fatto, un intero processo di sviluppo.. L'approccio cooperativo. Lo sviluppo della tecnologia ha consentito nuove forme di comunicazione a supporto delle attività di sviluppo software, incentivando dei comportamenti di ampia collaborazione e facendo in modo che tutti i partecipanti al progetto formino un unico gruppo di lavoro con lo stesso piano di attività condiviso e con le stesse scadenze da rispettare, attraverso l'integrazione strutturata della informazioni e l'automazione delle procedure che non richiedono necessariamente l'intervento umano. Su tali indicazioni si basa l'approccio moderno allo sviluppo: lo sviluppo cooperativo. 5

6 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. La qualità di un prodotto, così sviluppato, sarà determinata in buona parte dall'aspetto organizzativo che caratterizza profondamente la fase di sviluppo. In questo modo uno dei grandi limiti dell'approccio tradizionale allo sviluppo del software, ovvero la distanza tra gli sviluppatori, viene superato attraverso una maggiore opportunità di interazione e comunicazione diretta. Secondo questa nuova filosofia di sviluppo, il software non è mai un prodotto finito, ma è un prodotto che bisogna migliorare e far evolvere di volta in volta, al variare dei requisiti, e rapidamente affinché possa rispondere alle esigenze per cui è realizzato ed essere quindi considerato utile. A tale scopo è necessario quindi che tutte le persone del gruppo di lavoro cooperino assieme in maniera agevole al fine di raggiungere gli stessi obiettivi e nel minor tempo possibile. 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 come supporto. 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. Inoltre, data la suddivisione su base spazio-temporale, occorre disporre di un insieme di tecniche e tools che facilitano il coordinamento e la comunicazione tra i membri dei team di sviluppo, affinché quanto prodotto da ogni componente sia comprensibile da tutti gli altri partecipanti e che quanto svolto si possa combinare ed integrare in maniera costruttiva e soprattutto coerente con il resto del progetto. L'attività di sviluppo richiede quindi sistemi di comunicazione efficaci che supportino, in ogni fase del progetto, diversi livelli di interazione e forniscano una sincronizzazione delle attività in maniera da rendere scalabile la dimensione e quindi la complessità del team anche al crescere del numero di membri. Figura : Sviluppo Cooperativo. Il ruolo della comunicazione. La condivisione delle informazioni durante lo sviluppo cooperativo del software è, quindi, di capitale importanza allo scopo di ottenere un prodotto finale funzionante, efficiente e che sopratutto rispecchi le specifiche imposte dal committente. Questo processo di condivisione delle informazioni deve basarsi su un efficiente processo di comunicazione, che permette a due o più membri di scambiarsi informazioni attraverso i mezzi forniti dalla attuale tecnologia. Nell'ambito informatico, IBM, da tempo azienda leader nel settore, ha fatto suo questo concetto e l'ha posto al centro dei suoi progetti, che hanno portato alla nascita e allo sviluppo di sistemi e piattaforme che fanno della comunicazione, appunto, il loro punto di forza. 6

7 Prendendo, ora, in considerazione il caso della comunicazione all interno di un gruppo di lavoro che si occupa dello sviluppo di progetti, si ha che un gruppo può esistere solo a condizione che tra i suoi membri ci sia reciprocità di comunicazione e di relazioni. In questo senso, la comunicazione che si sviluppa al suo interno, riveste un ruolo fondamentale ed è un requisito indispensabile per l'esistenza stessa del gruppo. 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. In conclusione, i processi fondamentali che caratterizzano lo sviluppo cooperativo sono: - la comunicazione: il 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, in quanto il lavoro di ognuno di essi risulta essere diverso. - la cooperazione: il processo in cui i membri dei team operano insieme al fine di raggiungere un obiettivo comune. 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. 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, e 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.. Il Collaborative Application Lifecycle Management. Il successo delle attività collaborative è strettamente collegato al modo in cui tutti i suddetti servizi siano in grado di integrarsi tra di loro e con il particolare processo di sviluppo. A tale scopo è necessario che tutti gli strumenti lavorino sulla stessa base di dati, tracciando ogni singola modifica che avviene all'interno di essa. In questo modo è più facile automatizzare ogni singola attività che non richiede l'intervento creativo umano, in modo da minimizzare la complessità della gestione dei sistemi collaborativi che altrimenti risulterebbe insostenibile all'aumentare della dimensione del gruppo di lavoro. Tale approccio prende il nome di Collaborative Application Lifecycle Management, C/ALM, e rende possibile l'applicazione delle nuove metodologie di sviluppo del software come quello Agile. IBM ha sviluppato innovativi software a supporto dell'approccio C/ALM, per facilitare la collaborazione tra le persone nelle imprese globali, e ha esaminato il modo in cui i mondi virtuali possono aiutare i team di sviluppo software ad abbattere le barriere dovute alla globalizzazione. Storicamente i tool di sviluppo sono sempre stati implementati soprattutto per rendere i programmatori più produttivi. Ma con l'aumento dei livelli di complessità, IBM, Microsoft e altre aziende hanno iniziato a pensare di rendere le loro soluzioni software totalmente compatibili con l'intero ciclo di sviluppo, dalle esigenze cooperative al testing..5 La piattaforma Jazz. Sui suddetti principi si basa la piattaforma Jazz, un progetto di IBM Rational e IBM Research che ha l obiettivo di promuovere strumenti di sviluppo software da utilizzare con team di lavoro distribuiti in più località, fornendo un' architettura sulla quale andare ad integrare tutti i servizi necessari alla collaborazione, quali: 7

8 capacità di integrazione dei dati e quindi un unico repository facilmente consultabile ed in grado di raccogliere tutte le informazioni relative ad un progetto; collaborazione avanzata per lo scambio di informazioni, richieste di modifiche e revisioni, in modo sia sincrono che asincrono; automazione di tutte le attività che non richiedano necessariamente l'intervento umano. Tutte queste caratteristiche sono incluse in IBM Rational Jazz, una piattaforma tecnologica grazie alla quale le organizzazioni hanno la possibilità di assemblare il proprio ambiente ideale di realizzazione software mediante l'utilizzo combinato di vari tools, i quali riflettono la convinzione che l'elemento centrale dello sviluppo software non è né l'individuo né il processo, bensì la collaborazione. Figura : Architettura di Jazz La piattaforma Jazz nasce come uno strumento innovativo, open source e gratuito, a supporto di applicazioni di gestione collaborativa del ciclo di vita del software (C/ALM). L'innovazione della tecnologia Jazz sta nel fatto che esso non si propone di integrare tutti i servizi C/ALM in un' unica applicazione monolitica e centralizzata, ma di creare una piattaforma sulla quale si possano integrare e far interagire diverse applicazioni. In tal modo ogni applicazione potrà continuare a gestire i dati di sua competenza in maniera autonoma ma sarà in grado anche di esporre e ricevere dati e servizi dalle altre applicazioni connesse alla piattaforma utilizzando le interfacce specializzate definite dalla JIA, Jazz Integration Architecture (fig. ). Tale architettura è stata implementata in un sistema software, il Jazz Team Server, che definisce ed implementa tutti quei servizi di comunicazione, essenziali allo sviluppo collaborativo, tra le applicazioni collegate alla piattaforma ed indipendenti dall'effettivo modello di sviluppo con il quale si intende lavorare. Jazz è un software, basato su Eclipse, pensato per migliorare i cicli di sviluppo del software. Esso facilita i contatti tra le persone e il loro modo di lavorare; in questo modo fa leva sul potenziale delle comunità e sull unione di diverse competenze per accelerare ed arricchire il processo di sviluppo del software. Quello che l IBM vuole fare di diverso con Jazz è aprire al cliente le porte del processo di sviluppo dando accesso a piani di gruppo, progetti e documenti tecnici, elementi di lavoro, codici sorgenti, discussioni per consentire una partecipazione quanto più ampia possibile allo sviluppo di Jazz. Jazz è stato concepito proprio per migliorare l'ingegnerizzazione dei software collaborativi, adattando di fatto i tool e i protocolli finalizzati allo sviluppo distribuito. 8

9 Le applicazioni utilizzate nell'ambito dello sviluppo cooperativo 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. Rational Team Concert (RTC): fornisce svariate funzionalità integrate che permettono ai team di collaborare per accelerare lo sviluppo del software. 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. 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à..6 Il Rational Team Concert. Rational Team Concert è un prodotto Jazz-based utilizzato da sviluppatori, architetti e project manager. Esso consiste essenzialmente in un ambiente di sviluppo che si propone come soluzione integrata dedicata allo sviluppo del software in ambiente collaborativo, che supporta la cooperazione tra i membri di uno stesso team e tra team diversi, sviluppata per agevolare l'applicazione delle best-practies in accordo con i principi del C/ALM. Il supporto è offerto attraverso una serie di funzionalità fondamentali nella gestione di un progetto, come pianificazione agile, definizione di processi, creazione di report, possibilità di condividere informazioni del team, tracciarne l attività e i difetti. Tali funzionalità sono presentate all'utente attraverso due modalità : attraverso un client web-based, e/o attraverso un client basato sull'ambiente di sviluppo integrato Eclipse. L'interfaccia web-based è particolarmente utile per le attività di project management, ovvero in tutti quei casi in cui è necessario accedere a Jazz Team Server per supervisionare e controllare lo stato dei lavori direttamente da internet. In questo modo è possibile estendere l'utilizzo della piattaforma anche a determinate tipologie di utenti quali supervisori e stakeholders i quali potrebbero essere poco interessati ai dettagli implementativi. Il client basato sull'ambiente di sviluppo integrato Eclipse è invece particolarmente utile ai progettisti ed ai programmatori perché rende possibile l'integrazione dei servizi collaborativi con gli strumenti di sviluppo classici. Attraverso esso, è infatti possibile accedere a tutte le funzionalità di Rational Team Concert senza la necessità per lo sviluppatore di cambiare ambiente di lavoro per gestire le attività di collaborazione. L inizializzazione di un nuovo progetto avviene con la creazione, da parte di un amministratore di progetto di un area di progetto ed eventuali team area. Per progetti di piccole dimensioni, i membri del team possono essere aggiunti direttamente all area di progetto, per quelli di grandi dimensioni, contenenti più componenti o più timelines, si definiscono generalmente più aree team. Tutto ciò consente di attribuire al team specifici compiti, consentendo di realizzare una pianificazione ad un livello più granulare. Da ciò si evince la orizzontalità dell organizzazione su cui verte il framework. Sviluppatori appartenenti a contesti diversi ma con medesimi obiettivi, collaboreranno al raggiungimento di un obiettivo comune, condividendo conoscenze abilità, e, 9

10 soprattutto, si confronteranno acquisendo, oltre alla capacità di lavorare in gruppo, maggiori nozioni e abilità. Un area di progetto è la rappresentazione di un progetto software; al suo interno vanno specificate alcune caratteristiche relative al progetto stesso, come il nome, la sua descrizione, i ruoli, le categorie di work item, le timelines di progetto e le iterazioni. All interno dell area di progetto, come accennato in precedenza, va definito il processo di progetto. Esso tipicamente è basato su un modello di processo predefinito; in alternativa i modelli di processo possono essere creati a partire da zero o importati da altre aree di progetto. All interno di un processo esistono diversi elementi configurabili, tra cui: - Timelines e Iterazioni: una timeline rappresenta un settore di attività all interno di un progetto; le iterazioni rappresentano i periodi di sviluppo in cui sono organizzati i progetti, ossia delle fasi definite all interno di una timeline. Ogni timeline contiene una gerarchia di iterazioni e un piano di iterazione che consente di visualizzare gli obiettivi da raggiungere in una singola iterazione. - Ruoli: identificano le funzioni dei membri dei team. In ogni area si può definire un insieme di ruoli di processo. Gli utenti possono avere ruoli diversi in diverse aree di progetto o aree team e, questi, possono essere ordinati per priorità. - Permessi: gli utenti possono eseguire azioni concesse a tutti i ruoli ad essi assegnati. Possono essere definiti permessi a livello progetto, a livello team o in relazione ad ogni iterazione relativa ad una timeline. È possibile creare una team area all interno di un area di progetto o in una team area esistente stabilendo in questo modo una gerarchia di team. Ad ogni area team corrispondono specifici work items del progetto in base alla categoria di work items ad essa assegnata. Un work item non è altro che una modalità per tenere traccia delle attività e dei problemi che devono essere affrontati durante il ciclo di sviluppo. Essi essenzialmente catturano il lavoro pianificato per un progetto e sono caratterizzati da status, allegati, descrizione, priorità. È possibile stabilire relazioni tra i vari work items in termini di dipendenze, riferimenti, padre/figlio ed associarli ai piani e alle iterazioni. Un workflow definisce stati, azioni e risoluzioni che rappresentano il ciclo di vita di un work item. Il meccanismo principale per la ricerca dei work items è dato dalle query. È possibile adoperare sia query predefinite, sia query create in base alle proprie esigenze e scegliere di condividerle con specifici utenti o con tutti i membri del team. I risultati delle query, la storia dei work items, tutte le modifiche effettuate ad un work item e la storia dei work items aperti, vengono memorizzati in automatico da Jazz. Ogni team area può avere uno o più flussi di attività di sviluppo. Il lavoro svolto nelle aree di lavoro dagli utenti viene consegnato al flusso del team e da qui può essere accettato dagli altri membri del team. I rapporti sono tutti uno a molti: un area di progetto può avere molte team area, ogni team area può avere numerosi flussi e ogni flusso può avere molte aree di lavoro. Un flusso o stream è una collezione di uno o più componenti che, a loro volta, rappresentano il concetto di più alto livello per definire e classificare le risorse di progetto. Esso, inoltre, fornisce un meccanismo semplice per la condivisione controllata tra membri di uno stesso team e team diversi. Gli stream aiutano ad organizzare il lavoro svolto su di un progetto grazie ad un meccanismo che consente l integrazione del lavoro basato su una relazione tra flusso e aree di lavoro o workspace. La relazione consiste nel fatto che i workspace mantengono il lavoro e lo consegnano al proprio flusso genitore solo a seguito di sottomissione esplicita da parte dell utente. Ci sono due tipi di workspace : workspace locale e repository workspace. Il workspace locale risiede sulla workstation locale dell utente e contiene copia di versioni specifiche di artefatti; il repository workspace risiede sul server Jazz e consente di registrare versioni del proprio lavoro.

11 In definitiva, le modifiche apportate dagli utenti vengono effettuate nei workspace locali inviate ai repository workspace e successivamente agli stream del team da cui si propagano al resto del team attraverso i repository workspaces e quindi giungono ai workspaces locali. Un aspetto molto importante, da non sottovalutare, è il monitoraggio dell andamento dell intero progetto o di un particolare team. È possibile valutare il progresso del proprio team in relazione ad una release o una iterazione, utilizzando un report di progresso per confrontare il lavoro completato e quello stimato all interno di un team o analizzando lo stato dei work items assegnati ai vari membri di un team. In particolare, Jazz, mediante il Jazz Team Report, abilita a creare, sviluppare e generare report che forniscono un meccanismo per visualizzare lo status, le azioni e il progresso di un team o di un progetto. Grazie ai report è possibile monitorare l andamento di tutto il progetto, di singole aree team o addirittura singoli individui. In questo modo è possibile agire sul sistema per migliorarne le prestazioni..7 La gestione cooperativa dei progetti. Il project management è l'insieme delle attività volte a dirigere e coordinare il processo di progetto al fine di conseguirne gli obiettivi. Tali attività richiedono la gestione di un costante flusso di informazioni riguardanti lo stato delle attività e delle risorse umane del gruppo di lavoro e la disponibilità di mezzi e strumenti. Avere a disposizione più informazioni dettagliate significa aumentare la precisione dell'ottimizzazione del processo di sviluppo. D'altro canto però senza adeguati strumenti, la quantità di tempo legata alla loro raccolta, elaborazione e sintesi potrebbe non consentire risposte tempestive alle esigenze del team e dei committenti. Attraverso gli strumenti offerti dalle applicazioni su esposte, basate sulla piattaforma Jazz, ogni membro del team concorre alla gestione delle informazioni di progetto, in un "concerto collaborativo", attraverso la tracciabilità automatica delle attività e l'immissione di informazioni strutturate durante il processo di sviluppo. Con le funzionalità di integrazione dei dati è quindi possibile automatizzare l'elaborazione e la produzione di informazioni sintetiche aggiornate necessarie ad un'efficace azione di pianificazione e coordinamento scalabile anche in team di grosse dimensioni. L'organizzazione del lavoro è l'attività centrale del Project Management e consiste nel definire e formalizzare il lavoro nell'ambito del progetto tenendo conto delle finestre temporali e delle persone a disposizione nei vari gruppi di lavoro. La scelta della tipologia di processo deve essere effettuata valutando le caratteristiche del progetto e la loro applicabilità. Tali caratteristiche variano dalla dimensione del progetto alla quantità risorse a disposizione, dalla valutazione costante del rischio al grado di partecipazione da parte del cliente al processo di sviluppo. In merito a quest'ultima questione, è possibile che il progetto sia solo parzialmente definito a priori e che sia quindi dipendente dalle singole richieste degli effettivi utilizzatori. In questi casi sono necessari processi che reagiscano in maniera veloce ai cambiamenti. Per processi di questo tipo si adottano delle metodologie di sviluppo che, appunto, supportano la volubilità dei requisiti, delle risorse e degli obiettivi caratterizzanti il processo di sviluppo. Tali metodologia sono dette Agili..8 Le metodologie Agili. Le metodologie agili per lo sviluppo del software nascono in contrapposizione all'eccessiva pesantezza dei processi tradizionali in cui la rigida separazione di attività e responsabilità ostacola la comunicazione tra le persone e scoraggia la collaborazione tra i ruoli del team.

12 I principi sui quali questi nuovi metodi si basano sono stati esposti nel "Manifesto for Agile Software Development" ed hanno portato alla creazione dei nuovi modelli di processo leggeri. Essi sono caratterizzati dal fatto di dare maggiore peso a particolari fattori piuttosto che ad altri : - agli individui partecipanti al progetto ed alla loro interazione piuttosto che ai processi ed agli - strumenti; - al buon funzionamento del software piuttosto che alla produzione di documentazione esaustiva; - alla collaborazione con il cliente piuttosto che alla negoziazione di un contratto; - ad una efficace risposta ai cambiamenti piuttosto che al seguire un piano rigido e prefissato. Lo scopo di uno sviluppo agile è quello di poter massimizzare l'efficienza di un team di sviluppatori, minimizzando i costi e gli sprechi di tempo, concentrando lo sviluppo verso il soddisfacimento delle esigenze del cliente e delle richieste di cambiamenti al fine di produrre in breve tempo sistemi che siano sempre coerenti con le esigenze del mercato e che costituiscano, quindi, opportunità di business. I metodi agili raggiungono nuove forme di collaborazione nelle quali ogni membro del team contribuisce alle decisioni di progetto ed al miglioramento del processo di sviluppo. In questo senso si considera membro del team chiunque abbia interesse al buon esito del progetto, ovvero sviluppatori, stakeholders e utenti. Caratteristica peculiare, dal punto di vista dell'organizzazione delle risorse umane, è la necessità di un team di sviluppatori piccolo ed attivamente coeso. Nel caso di progetti più complessi e di dimensioni maggiori, è necessario comunque organizzare il lavoro suddividendo gli sviluppatori in team, ognuno dei quali si occuperà di un particolare componente software in modo da rendere scalabile la complessità. Tale suddivisione non è effettuata a partire dai ruoli e dalle attività svolte all'interno del processo, ma in base alle funzionalità richieste per lo scopo del singolo progetto. A differenza delle metodologie tradizionali, inoltre, non è prevista alcuna gerarchia tra le aree team, in quanto ognuna di essere è in grado di procedere autonomamente allo sviluppo di una intera funzionalità. Sono però necessari quei meccanismi, ampiamente esposti precedentemente che rendono possibile una comunicazione ed una sincronizzazione costruttiva e quindi una cooperazione efficiente. Tali meccanismi variano con la metodologia usata, ma derivano tutti dai principi dello sviluppo agile. Un processo di sviluppo agile è iterativo ed incrementale. L'intero sistema viene realizzato attraverso piccoli incrementi corrispondenti a brevi e periodiche iterazioni del processo. Ad ogni iterazione corrisponde il rilascio di un sistema potenzialmente vendibile al fine di ottenere dal cliente un feedback che influenzerà le attività da svolgere nella successiva iterazione. In questo modo si riduce la possibilità di fallimento alla durata di una singola iterazione, garantendo al tempo stesso una maggiore soddisfazione del cliente ed una maggiore affidabilità. E' prevista un'attività di planning all'inizio di ogni iterazione, nella quale si raccolgono le richieste degli stakeholders e le si classificano in base alla priorità. Da queste si seleziona poi una serie di funzionalità che rispondono alle caratteristiche di maggior interesse, come quelle che saranno più utilizzate o comportano maggiori opportunità di business. La fase di sviluppo avviene in maniera cooperativa, a supporto della partecipazione degli stakeholders e dei possibili cambiamenti, mantenendo però una buona qualità del software. Lo sviluppo avviene quindi in modo evolutivo, guidato dai casi di test.

13 .9 Il framework Scrum Scrum è un framework per la creazione ed il controllo di un processo di sviluppo agile creato da Ken Schwaber e Jeff Sutherland. Il termine Scrum è mutuato dal termine del rugby che indica il pacchetto di mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un'unica entità coordinata. Esso ha riscosso un considerevole successo grazie alle sue caratteristiche flessibili che sono applicabili in una vasta gamma di progetti, talvolta anche fuori dell'ambito informatico. Lo scopo principale è dare la massima priorità all'effettiva creazione di prodotti software eseguibili, aggirando eventualmente le lunghe ed estenuanti fasi caratterizzanti i tradizionali metodi di sviluppo quali documentazioni dettagliate ed elencazioni rigide dei requisiti da soddisfare. La necessità impellente è realizzare qualcosa anche di piccole dimensioni ma quanto prima distribuibile al cliente. Come afferma Robert Karlsson della Scrum Alliance, infatti, "The marketers, business, sales, and production staff usually need things to be done now, because, well, now is now and tomorrow is tomorrow". L'obiettivo di un processo Scrum è quello di concretizzare i principi dello sviluppo agile attraverso un insieme di pratiche e regole che ottimizzano l'ambiente di sviluppo, riducendo l'overhead dovuto alle procedure organizzative. Praticamente, fissato il numero delle risorse disponibili e concordati una qualità minima del prodotto ed i tempi di rilascio, lo Scrum offre un modo per raggiungere la produzione del miglior prodotto ottenibile, nel rispetto di tali requisiti. L'approccio Scrum può essere definito: - Adattivo: poiché fornisce funzionalità per la gestione dei cambiamenti permettendo quindi 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 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 al 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. Il processo consiste nel dividere il progetto in blocchi rapidi di lavoro, detti Sprint, alla fine dei quali presentare una versione del sistema al cliente. L'organizzazione del lavoro si basa sul planning delle attività da svolgere nell'immediato futuro attraverso la produzione di documenti di piano, detti Backlog, i quali concorrono ad ottenere una definizione estesa del sistema che si sta sviluppando. A supporto di queste fasi, sono previste dal processo frequenti riunioni del team di sviluppo, dette Scrum, per la verifica e il controllo di quanto sviluppato e per la definizione delle attività future. I ruoli definiti da Scrum sono lo Scrum Master, il Product owner ed il Team Member. Lo Scrum Master gestisce e controlla il processo, ma non gestisce il progetto ne i team. Il Product Owner rappresenta i committenti o più in generale i responsabili di business. Un Team Member è il generico partecipante al progetto che svolge un ruolo nell'ambito di un team di sviluppo. Secondo il framework, inoltre, un Team è un gruppo autogestito al più da 7 persone. Seppur vero che l'evoluzione di un processo Scrum è guidata dalle decisioni del team che variano quindi da progetto a progetto, il framework stabilisce un insieme di documenti da produrre,

14 denominati Artefatti, una serie di pratiche da seguire, come le Riunioni, ed una suddivisione delle tipologie di partecipanti allo sviluppo in vari Ruoli, al fine di garantire l'efficienza del lavoro cooperativo e minimizzare i rischi. I principali Artefatti in Scrum sono il Product Backlog, lo Sprint Backlog ed il Burn-down Chart. Il Product Backlog è un documento di alto livello, relativo all'intero progetto, che contiene i cosiddetti Backlog Item, ovvero le descrizioni di tutte le caratteristiche richieste dal committente, presentate sotto forma di "Wish List", con relative priorità assegnate in base al valore di business. Lo Sprint Backlog è un documento che contiene informazioni su come il team intende procedere o sta già procedendo nell'implementazione delle funzionalità della Sprint corrente. Il Burn-down Chart è un grafico che deve essere disponibile ad ogni membro del team e rappresenta il lavoro che deve essere ancora completato nell'ambito dello Sprint Backlog corrente. Tali Artefatti devono essere prodotti durante delle riunioni periodiche che si differenziano per le categorie di partecipanti, la frequenza e gli scopi. Figura :Scrum Artifacts E' possibile tracciare un quadro generale delle attività che devono avvenire nel corso di ogni iterazione. Inizializzato il Product Backlog con i requisiti iniziali richiesti dal committente, bisogna procedere alla pianificazione della successiva sprint attraverso lo Sprint Planning Meeting. Durante quest'ultimo, il Product Owner informa il team circa gli elementi che vorrebbe veder completati nel corso della Sprint e si produce una versione iniziale dello Sprint Backlog contenente quelli che possono essere realizzati durante la prossima Sprint. La lista di tali componenti viene bloccata fino al termine della prossima iterazione. Durante la fase di Sprint, attraverso le Daily Scrum e le Scrum of Scrums, gli elementi contenuti nello Sprint Backlog vengono dettagliati con le descrizoni del modo di procedere relativo al loro sviluppo. Al termine di ogni Sprint, il team illustra agli stakeholders ed al Product Owner, attraverso la Sprint Review, il software realizzato presentando tutti i Backlog Item completati, al fine di poter raccogliere feedback sui possibili miglioramenti da inserire nel Product Backlog. Infine, si tiene la Sprint Restrospective nella quale si analizzano i dati del processo e si pianificano eventuali ottimizzazioni per lo svolgimento della successiva iterazione. 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.

15 Capitolo L'approccio GQM. Le metriche software. La gestione della qualità è rappresentata da tutte le attività realizzate all'interno di una realtà produttiva e dal personale impegnato al conseguimento degli obiettivi della politica della qualità. La locuzione Quality Control è sostanzialmente un sinonimo molto utilizzato per identificare, nell'ambito di una impresa industriale, il comparto delegato a gestire la qualità dei prodotti realizzati, cioè a mettere in atto tutte quelle azioni ed iniziative che consentono di definire e tenere sotto controllo gli standard qualitativi richiesti dalla direzione aziendale. I metodi quantitativi si sono dimostrati strumenti potenti in altri campi della scienza, per questo motivo pratici e teorici del campo informatico si sono impegnati a fondo per mettere a punto un simile approccio nello sviluppo di software. La letteratura informatica delle ultime tre decadi è, di fatto, ricca di articoli su come gli sviluppatori possano misurare i vari aspetti dell' uso e dello sviluppo del software dalla produttività dei programmatori al grado di soddisfacimento dei requisiti richiesti dai clienti. Il problema nella misurazione e valutazione della qualità e delle performance del software è legato ovviamente alla sua complessità, rispetto ai componenti hardware sui quali gira. Per questo, nella gestione e valutazione della complessità è necessario andare oltre la semplice stima del numero di linee di codice e del numero di bug riscontrati, strada che negli ultimi anni, invece, non è stata precisamente percorsa, limitandosi ad associare ad un basso numero di questi un buon livello di qualità. Tali difficoltà sono dovute al fatto che la qualità del software è un concetto multidimensionale. Da un punto di vista professionale, infatti, la qualità può essere molto diversa rispetto ad un punto di vista "popolare" e non specializzato. Inoltre, essa può avere livelli d'astrazione che vanno oltre punti i di vista dello sviluppatore e del cliente. Una metrica software è uno standard per la misura di alcune proprietà del software o delle sue specifiche. La necessità dell'utilizzo di metriche software può essere facilmente riassunta citando l'ingegnere del software Tom DeMarco il quale ha affermato che "non puoi controllare ciò che non sai misurare". Un programma di misura è costituito dall insieme di informazioni che specificano quali dati raccogliere e secondo quali modalità operative tale raccolta deve essere condotta. Il principale problema da affrontare è in quest ambito la scelta delle metriche. 5

16 Le metriche software comunemente adottate sono: linee di codice sorgente; complessità ciclomatica; punti funzione; errori per linee di codice; copertura di codice; numero di linee richieste dal cliente; numero di classi e interfacce. Le metriche software possono essere utilizzate per: stimare il budget per il progetto e la codifica; stimare la produttività individuale e la qualità; stimare la produttività del progetto e la qualità; stimare la qualità del software. Allo scopo di implementare le metriche per il progetto sotto osservazione, devono essere determinati i dati da collezionare. Inoltre, devono essere definiti i vari tool utilizzati, e descritte tutte le organizzazioni coinvolte. Risulta conveniente testare tali metriche su software noti e perfezionare il loro uso, la accuratezza e il costo d'utilizzo. La validazione delle metriche è un processo continuo. Affinché le metriche individuate risultino utili, esse devono indicare accuratamente quali requisiti di qualità sono stati raggiunti o permetteranno di raggiungere durante lo sviluppo. Una metrica, inoltre, deve essere validata ad ogni suo utilizzo, in quanto una maggiore fiducia in una metrica porterà ad una maggiore esperienza in vista degli usi futuri. Ottenere una misurazione in ritardo delle caratteristiche di interesse, 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. Misurare 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 un generico 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 Software Quality Metrics,e infine il Goal Question Metric.. L'approccio GQM. GQM è un approccio sviluppato negli anni '8, promosso da Victor Basili dell' Università del Maryland, dal College Park e dal Software Engineering Laboratory presso il Goddard Space Flight Center della Nasa. Esso, infatti, fu inizialmente usato per valutare i difetti in una serie di progetti della NASA. Successivamente, grazie alla sua duttilità, fu ampliato allo scopo di poter essere applicato a più vasti campi di interesse. GQM è diventato un tema di grande interesse nei corsi avanzati di ingegneria del software, ricerca metodologica e gestione dei progetti software. I professionisti ritengono GQM utile sia nel guidare le iniziative di miglioramento che nello sviluppo di metriche per la gestione continua dei progetti software. Il GQM è un paradigma di misura che parte dalla definizione degli obiettivi che si intende raggiungere, dai quali si fanno discendere una serie di domande per definire dei dati o metriche. Tale approccio fa uso delle metriche trovate allo scopo di migliorare il processo di sviluppo software, rispettando allo stesso tempo i requisiti di business e gli obiettivi tecnici. Il risultato dell'applicazione del modello GQM è la specifica di un sistema di misura che mira 6

17 all'interpretazione dei dati raccolti attraverso l'applicazione di determinate regole a un insieme di problemi. Il modello di misura risultante presenta tre livelli : livello concettuale (Goal) : un obiettivo viene definito per un oggetto, relativamente ad un problema, in un particolare ambiente e da un determinato punto di vista. L'oggetto della misura può essere un prodotto, un processo o una risorsa. livello operativo (Question) : viene specificato un insieme di domande che definisce il modo con il quale vengono valutati o ottenuti gli obiettivi del livello superiore. Le domande caratterizzano l'oggetto della misura rispetto ad un problema di qualità e ad un preciso punto di vista. livello quantitativo (Metric) : un insieme di dati viene associato a ogni domanda al fine di rispondere in modo quantitativo. I suddetti dati possono essere oggettivi, se dipendono solo dall'oggetto e non dal punto di vista; o soggettivi, se dipendono sia dall'oggetto che dal punto di vista dal quale si sta osservando. L'approccio si sviluppa identificando una serie di obiettivi di qualità o di produttività. Successivamente deriva una serie di domande che definiscono tali obiettivi nel modo più preciso possibile e cerca di specificare quelle misure che si devono raccogliere per rispondere a queste domande. Il metodo è stato proposto ed applicato come tecnica sistematica per quantificare e sviluppare programmi di misura per processi e prodotti software, tuttavia è stato dimostrato che il paradigma di quantificazione degli obiettivi è applicabile ad ogni tipo di programma di misura, non solo software. Combinando la maggior parte dei moderni approcci alle misure e generalizzandoli in modo da incorporare processi, risorse e prodotti, esso è applicabile a una vasta tipologia di ambienti. Figura : Struttura gerarchica del GQM Dal punto di vista strutturale, un modello GQM presenta un architettura gerarchica, top-down, costituita da un albero (fig. ). 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. Le idee di fondo che caratterizzano il metodo GQM sono sostanzialmente due: ) La definizione di un processo di misura deve essere guidato dagli obiettivi dell utente del programma. Non esistono, ovvero, programmi standard di misura. ) La creazione di un programma di misura è esso stesso un processo complesso che richiede pianificazione, organizzazione e utilizzo di risorse adeguate. GQM identifica innanzi tutto un processo che indica le fasi secondo le quali procedere per definire il programma di misura e i prodotti intermedi che tale processo deve generare. Esse sono: 7

18 Prestudy: caratterizza il dominio della misurazione, identificandone le informazioni essenziali come le precondizioni e i vincoli, gli obiettivi strategici della azienda e le esperienze esistenti. Identificazione dei GOAL GQM: definisce ed organizza un set di obiettivi per il miglioramento della attività sulla base della descrizione del contesto, attribuendone una priorità in relazione alla rilevanza ed all impatto nella strategia della organizzazione. Produzione del GQM Plan: il GQM Plan è un documento strutturato nel quale ogni obiettivo è associato ad un set di metriche i cui valori, una volta rilevati, forniscono la misura del grado con il quale l obiettivo in questione è stato raggiunto. Produzione del Measurement Plan: indica quali dati si desidera raccogliere, a differenza della precedente la quale indica come deve avvenire il processo di raccolta dei dati. Collezione e validazione dei dati: raccolta e valutazione dei dati di processo e di prodotto in accordo al GQM Plan ed al Measurement Plan. Analisi dei dati: analisi dei dati raccolti al fine di comprendere e valutare il livello di corrispondenza tra valore ottenuto e valore atteso relativamente ad ogni goal. Packaging of experiences: tutta l esperienza che è stata accumulata durante la organizzazione ed esecuzione del processo di misura viene conservata in opportuni documenti per il riuso in futuri progetti. Lo sviluppo di un obiettivo è basato su tre fonti fondamentali di informazione. La prima è la policy dell'organizzazione che applica l'approccio GQM, da cui vengono dedotti sia il problema che lo scopo dell'obiettivo. La seconda è la descrizione del processo, risorsa o prodotto sotto misura, da cui si ricava l'oggetto del goal. La terza fonte di informazione è il modello dell'organizzazione, che fornisce il punto di vista del goal. Fondamentalmente quindi ogni goal può essere visto come un punto nello spazio individuato dalle tre coordinate corrispondenti alle tre fonti di informazioni suddette (fig. 5). Figura 5: Coordination for Goal Come detto, dalla specifica di ogni obiettivo derivano domande che caratterizzano il goal in modo qualificabile. In generale, le Questions appartengono a tre macrogruppi : Gruppo : come possiamo caratterizzare l'oggetto rispetto al goal generale? Gruppo : come possiamo caratterizzare gli attributi dell'oggetto che sono rilevanti rispetto al problema? Gruppo : come possiamo valutare le caratteristiche dell'oggetto che sono rilevanti rispetto al problema? Una volta sviluppate le domande, si procede ad associarle a metriche appropriate. A tale scopo i fattori da considerare sono tanti, tra cui quantità e qualità dei dati esistenti e maturità degli oggetti di misura. 8

19 Notiamo che le Questions, l insieme di domande, deve essere rivolto a coprire tutti gli aspetti caratteristici del Goal in esame. Inoltre, attraverso le risposte alle Questions, deve essere possibile ricavare misure (le cosiddette Metriche) sulle grandezze osservabili dei prodotti intermedi e dei prodotti finiti del progetto. Dette Metriche, confrontate con i rispettivi Valori di soglia, forniscono la valutazione di quanto si stiano raggiungendo gli obiettivi prefissati. Figura 6: Ciclo di vita di un GQM In conclusione, GQM rende realizzabile la misurazione e la validazione del software. Esso incarna la filosofia di misurazione di Basili secondo cui le metriche derivano dai Goal, limitando la collezione dei dati a ciò che è realmente necessario per rispondere alle Questions, utilizzando un modello chiaro per l'interpretazione dei risultati. La tecnica GQM è sì basata su un modello, ma presenta una metodologia di applicazione essenzialmente libera da rigide regole. Lo stesso Basili, nel suo articolo "GQM approach has involved to include models", consiglia una serie di euristiche da seguire. Ad esempio, è difficile dire quando terminare l'approccio, non esiste una regola precisa che indica quando farlo. Il problema diventa quello di limitare il numero di Goal. Bisogna fermarsi quando si raggiunge un numero di informazioni sufficienti a valutare il Goal con il grado di fiducia desiderato. E' necessario dunque farsi guidare dal buon senso. Inoltre, bisogna scegliere le domande in modo che esse abbiano due scopi principali: soddisfare i Goal, e aiutare a definire le metriche e i dati raccolti. E' necessario non complicare più del dovuto l'approccio, ma semplificarlo quanto più possibile. Differenziare i "measurament goals" dagli "organizational goals", dai quali derivano, per evitare inutili confusioni. Infine è molto importante controllare continuamente la validità e l'accuratezza dei dati collezionati. In sintesi, il metodo GQM fornisce una serie di indicazioni metodologiche che guidano il progettista di un programma di misurazione nella definizione delle metriche da raccogliere e delle modalità di raccolta. Ciò avviene attraverso uno studio dettagliato delle motivazioni e degli obiettivi del programma di misura. Questa focalizzazione centrata sugli obiettivi permette di ottenere informazioni che sono coerenti con le aspettative e i bisogni di chi ha avviato il programma di misurazione. Inoltre, permette di minimizzare il numero di dati da raccogliere, facilitando il lavoro di chi dovrà collezionare le informazioni e riducendo i costi del processo di raccolta. 9

20 Capitolo L'applicazione dell'approccio GQM al progetto ETCplus. Il progetto ETCplus. La disponibilità di architetture mutuate all esperienza Internet per il mondo dello sviluppo software, veicolate in particolare dall architettura Jazz, ha fatto nascere l idea di un progetto sperimentale di utilizzo delle discipline dell ingegneria del software in un ambito collaborativo universitario che consenta agli studenti e ai docenti la migliore fruizione delle modalità di insegnamento nelle università, coniugata alle nuove possibilità di collaborazione e condivisione intrauniversitaria. Tale progetto è denominato Enforcing Team Cooperation using Rational software tools, ETC per brevità. Allo stato attuale, ETC annovera 7 università e circa 8 studenti in cooperazione per l apprendimento. Il progetto è supportato da IBM Academic Initiative, IBM Rational ed è in cooperazione con la comunità Eclipse Italiana. Come accennato, la motivazione di fondo del progetto ETC è quella di supportare la didattica dell informatica nelle università, e allo stesso tempo: consentire agli studenti di sperimentare da subito un contesto di lavoro industriale per lo sviluppo del software; fornire a docenti e a studenti strumenti di lavoro moderni e di mercato; utilizzare strumenti e metodologie abilitanti a future opportunità di lavoro, conoscenza e professionalità. L Application Life-Cycle Management tocca e coinvolge tutte le discipline dello sviluppo del software, quindi la maggior parte delle materie non teoriche insegnate nei corsi di laurea di informatica. Lo studente durante il susseguirsi dei corsi sperimenta queste discipline soltanto una alla volta, a differenza del contesto industriale dove c è la percezione evidente di un progetto. Il progetto ETC attraverso i giusti strumenti inserisce nel contesto didattico la possibilità di creare progetti su cui gli studenti collaborano come succede nelle industrie, percependo profondamente il ciclo di vita del software e preparandosi alla vita professionale futura. Il progetto ETC si compone di : un architettura fisica costituita da un server blade IBM serie X quadriprocessore;

21 strumenti software di IBM basati su Jazz quali Rational Team Concert, Rational Quality Manager, Rational Requirement Composer e DB; la rete che unisce le università partecipanti. Il progetto coinvolge le seguenti università: offrendo le sue capability ad oltre 5 studenti e docenti. I ruoli impattati dal progetto ETC sono molti, tra i quali : progettisti; analisti di sistema e di business; sviluppatori; architetti software; tester; project manager; stakeholders; responsabili di configurazione. Come noto, le fasi fondamentali nel processo di sviluppo di un progetto C/ALM sono la coordinazione delle attività di sviluppo allo scopo di produrre applicazioni e prodotti software, e la gestione del ciclo di vita degli assets e delle loro relazioni. In ETC tali fasi vengono eseguite attraverso quelli che possono essere definiti veri e propri criteri di successo per l'esperienza C/ALM : collaborazione: connessione tra stakeholders e sviluppatori; tracciabilità: gestione delle dipendenze e degli impatti; distribuzione: connessione della catena di fornitura software; automatizzazione: miglioramento della conformità, delle performance e della qualità; sviluppo e perfezionamento continui: valutazione continua dei progressi e dei risultati. I gruppi di lavoro partecipanti al progetto sono divisi in più Project Area, ognuna delle quali si occupa di un particolare progetto di sviluppo, detto "programming project". Quello di nostro interesse è il programming project # cui partecipano studenti, 6 appartenenti alla facoltà di ingegneria dell' Università Federico II di Napoli, e 6 della Kent State University, USA. Gli studenti sono coordinati da più professori, appartenenti ad entrambe le Università, e dispongono di un sito di riferimento per il coordinamento di attività, riunioni, novità e ogni altra cosa correlata al progetto. Essi inoltre, trattandosi di sviluppo collaborativo, dispongono dei servizi offerti da Jazz quale, Rational Team Concert, e ne possono trarre, di conseguenza, tutti i relativi vantaggi. La metodologia di sviluppo usata è il framework Scrum, un metodo Agile, iterativo ed incrementale già trattato nei precedenti capitoli. Gli studenti sono organizzati in 8 gruppi o team da membri ciascuno (fig. 7). Ogni team è costituito da un Team Leader, un Vice Team Leader e due Team Member. Le figure caratterizzanti il progetto sono:

22 il Product Owner: si occupa di ottimizzare il lavoro del team, decide ed assegna i compiti ai membri. Nel contesto del progetto, esso coincide con il Team Leader; lo Scrum Master: il cui ruolo è quello di fare in modo che il processo di sviluppo sia rispettato e correttamente eseguito. Nel contesto del progetto coincide con i docenti ed i loro collaboratori; il Team Member: lo studente che esegue il lavoro assegnatogli. Ogni team deve avere le competenze necessarie a trasformare le richieste del Product Owner in parti rilasciabili del prodotto finale. Figura 7: Gruppi del progetto ETCplus Lo scopo del gruppo di lavoro è lo sviluppo collaborativo di 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 versamento e di visualizzazione del conto.. L'applicazione dell'approccio GQM. L'obiettivo di questa esposizione è quello di applicare il già citato approccio GQM al progetto ETC relativamente al programming project # allo scopo di conseguire determinati obiettivi. Come ampiamente discusso nel precedente capitolo, l'approccio GQM prevede più fasi secondo le quali procedere per definire il programma di misura e i prodotti intermedi che tale processo deve generare. La prima fase è quella di Prestudy. Essa caratterizza il dominio della misurazione, identificandone le informazioni essenziali come precondizioni e vincoli, obiettivi strategici della azienda ed esperienze esistenti. Queste informazioni sono importanti in quanto una loro gestione ottimale permette di amministrare al meglio le risorse umane che si hanno, creando una visione migliore del contesto sul è applicato il processo GQM, e permettendo di raggiungere gli obiettivi fissati contestualmente al reale stato delle cose, e non in base ad indicazioni di carattere generale. Esse infine costituiscono una solida documentazione sulla quale si baserà tale processo. Una prima osservazione da fare è che sicuramente gli studenti non hanno una grandissima esperienza nel contesto dello sviluppo cooperativo, non avendo mai partecipato a progetti di questo tipo ed essendo per lo più studenti del secondo anno di università. Essi inoltre non hanno una grande esperienza nemmeno con gli strumenti usati, ovvero Eclipse e Jazz.

23 Gli studenti, infine, appartengono a Paesi diversi e hanno quindi potuto incontrare delle barriere linguistiche che possono aver portato ad incomprensioni, ad una scarsa sincronizzazione e quindi ad una cooperazione al di sotto dei livelli desiderati. La seconda fase consiste nell' Identificazione dei Goal, ovvero nel definire ed organizzare un set di obiettivi per il miglioramento dell'attività di sviluppo sulla base della descrizione del contesto, attribuendone una priorità in relazione alla rilevanza ed all impatto nella strategia della organizzazione. Gli obiettivi che ci si propone di raggiungere sono tre :. migliorare l'uso degli strumenti adoperati nel contesto dello sviluppo collaborativo;. migliorare l' efficienza della collaborazione tra membri e team nell'ambito dello sviluppo collaborativo;. migliorare l'efficienza dello sviluppo nel contesto dello sviluppo collaborativo. Allo scopo di avere una descrizione più dettagliata e schematica dei Goal si introduce il Goal Template Sheet che definisce i vari Goal in termini di cinque determinati attributi: lo scopo, il problema, l'oggetto, il punto di vista ed il contesto. Come già accennato nel precedente capitolo, tali attributi definiscono le coordinate per la creazione dei Goal che risultano fondamentali nell'identificazione univoca degli stessi. I Goal Template Sheet relativi ai tre Goal individuati sono i seguenti: Goal Template Sheet - Goal Purpose: Issue: Object: Viewpoint: Context: Migliorare Uso Strumenti Scrum Master ETCplus Project Goal Template Sheet - Goal Purpose: Issue: Object: Viewpoint: Context: Migliorare Efficienza Collaborazione Scrum Master ETCplus Project Goal Template Sheet - Goal Purpose: Issue: Object: Viewpoint: Context: Migliorare Efficienza Sviluppo Scrum Master ETCplus Project Le relazioni tra i Goal e quindi le loro rispettive priorità possono essere ricavate da un altro documento GQM, il Goal Selection Sheet, che permette di classificare i Goal individuati in termini di importanza ed urgenza. In questo caso, i tre Goal individuati sono tra loro correlati, ovvero ognuno di essi può essere raggiunto solo grazie al soddisfacimento dei precedenti. In altri termini, è possibile migliorare lo sviluppo solo attraverso un miglioramento della collaborazione il quale è raggiungibile attraverso un buon uso ed una buona comprensione degli strumenti messi a disposizione per la realizzazione del progetto.

24 Allo scopo di raffinare i Goal individuati si utilizza un ulteriore documento chiamato Goal Abstraction Sheet che viene integrato con il precedente. Questo nuovo documento ha il compito di migliorare la leggibilità e monitorare il processo GQM, caratterizzando i Goals che ne fanno parte. Grazie a questo documento è infatti possibile, ponendosi delle domande significative, ottenere degli attributi che caratterizzano i Goal ad un più basso livello. Tra queste si evidenziano:. "Come è possibile caratterizzare l'entità (prodotto, processo o risorsa) rispetto al goal?", da cui si ottengono i Quality Focus;. "Quali sono i valori assunti dalle caratteristiche dell'entità che caratterizza il goal?", da cui si ottengono le Baselines Hypothesis;. "Quali sono i fattori che influenzano il goal?" da cui si ricavano i Variation Factors;. "Al variare dei fattori di influenza, come si comportano le caratteristiche?" dalla quale si ricavano i Baselines Impacts. Le informazioni in grado di rispondere efficacemente a tali domande, vengono recuperate attraverso l'interazione con chi utilizza l'entità da valutare o interagendo direttamente con essa. In questo caso, esse sono state ottenute attraverso tutti i materiali ricavabili sull'esperienza come i diversi forum, l'interfaccia web-based di Rational Team Concert, e i vari sondaggi proposti dai coordinatori ai partecipanti. I Goal Abstraction Sheet relativi ai tre Goal individuati (in cui si omettono per semplicità le Baseline Hypothesis e i Baseline Impacts) sono i seguenti: Goal - Goal Abstraction Sheet: QUALITY FOCUS tempo necessario alla configurazione & installazione difficoltà riscontrata nella configurazione & installazione livello di esperienza dei partecipanti livello materiali di supporto agli strumenti VARIATION FACTORS ) % di membri per cui il tempo richiesto in generale per imparare l'uso degli strumenti è maggiore della media ) % di membri per cui il tempo richiesto per imparare ad usare eclipse è maggiore della media ) % di membri per cui il tempo richiesto per imparare ad usare jazz è maggiore della media ) % team per cui il Tempo richiesto in generale per imparare ad utilizzare gli strumenti è superiore alla media 5) % team per cui il Tempo richiesto per imparare ad utilizzare Eclipse è superiore alla media 6) % team per cui il Tempo richiesto per imparare ad utilizzare Jazz è superiore alla media 7) % membri per cui sono state necessarie ricerche personali 8) % team per cui sono state necessarie ricerche personali 9) % team con membri che hanno incontrato difficoltà con gli strumenti ) % membri con difficoltà strumenti ) % di membri a conoscenza di Jazz prima del progetto ) % di membri a conoscenza di Eclipse prima del progetto ) % team con una Conoscenza precedente di eclipse ) % team con una conoscenza precedente di jazz 5) % membri dichiaratisi esperti 6) % membri con esperienza originale nulla o limitata 7) % team con membri dichiaratisi esperti 8) % team con esperienza originale minore della media 9) # di tutorials & video per strumento ) % membri che ritengono buona la quantità del materiale riguardo jazz ) % membri che ritengono buona la Qualità del materiale riguardo jazz ) % membri che ritengono buoni organizzazione e uso materiali

25 ) % membri che ritengono buona la quantità del materiale riguardo Eclipse ) % membri che ritengono buona la qualità del materiale riguardo Eclipse 5) % team per cui la qualità del materiale relativo ad Elipse è ritenuta buona 6) % team per cui la quantità del materiale relativo ad Elipse è ritenuta buona 7) % team per cui la qualità del materiale relativo ad jazz è ritenuta buona 8) % team per cui la quantità del materiale relativo ad jazz è ritenuta 9) % team per cui organizzazione e uso materiali è superiore alla media livello di esperienza generale acquisito ) % membri che hanno acquisito una buona esperienza generale Goal - Goal Abstraction Sheet: QUALITY FOCUS comunicazione a livello membro comunicazione a livello team cooperazione a livello membro cooperazione a livello team partecipazione e comunicazione membri con team Coordinator & Wheatsteeler partecipazione e comunicazione team con team Coordinator & Wheatsteeler grado di collaborazione raggiunto VARIATION FACTORS ) % membri che hanno incontrato barriere linguistiche ) % team con comunicazione perfettamente corrisposta ) % team che hanno incontrato Barriere linguistiche ) % membri che hanno presentato un contatto Skype 5) % membri che hanno raggiunto un buon livello di cooperazione 6) % team con membri che hanno presentato un contatto Skype 7) % team che hanno raggiunto un buon livello di cooperazione 8) % membri partecipanti alla presentazione 9) % membri partecipanti al survey ) % membri che hanno partecipato alla votazione team leader ) % membri che ritengono buona la velocità di assistenza ) % membri che ritengono buona la chiarezza delle istruzioni ) differenza di partecipazione tra studenti italiani e americani ) % team con membri partecipanti alla presentazione 5) % team con membri partecipanti al survey 6) % team per cui la velocità di assistenza è risultata soddisfacente 7) % team per cui le istruzioni sono risultate chiare 8) % team che hanno acquisito una buona esperienza collaborativa 9) % membri che hanno acquisito una buona esperienza collaborativa Goal - Goal Abstraction Sheet: QUALITY FOCUS livello di produttività a livello membro VARIATION FACTORS ) % membri che hanno completato almeno work item ) % membri che hanno completato tutti work item ) % di task completati nel tempo di consegna ) % membri che hanno acquisito una buona esperienza nello sviluppo collaborativo livello di produttività a livello team 5) % team aventi membri che hanno completato completato work item 6) % team aventi membri che hanno completato tutti work item 7) % di team con almeno un work item closed 5

26 8) % di team con work item in progress 9)% di team con una buona Quality of Planning ) % team che hanno acquisito una buona esperienza nello sviluppo collaborativo livello di organizzazione e gestione di team e progetti livello di affidabilità a livello membro livello di affidabilità a livello team differenze stili di vita tra i membri valutazione complessiva del progetto ETC ) % membri che lavorano ) % team con almeno un membro lavoratore ) % team con una distribuzione di work item per team inferiore alla media ) % di team con # work item superiore alla media 5) % di team con una buona distribuzione di work item per membro 6) % membri che hanno trovato difetti 7) % membri che hanno prodotto change set 8) % team che hanno trovato difetti 9) % team che hanno prodotto change set ) differenza # di lavoratori italiani e americani ) % membri che danno una buona valutazione al progetto ETC ) % membri che ritengono utile il progetto ETC ) % membri che si ritengono soddisfatti del progetto ETC ) % team che danno una buona valutazione al progetto ETC 5) % team che ritengono utile il progetto ETC 6) % team che si ritengono soddisfatti del progetto ETC A questo punto si entra nell' operational level, ovvero quella fase operativa dedicata alla formulazione delle Question usate per descrivere e raffinare al meglio i Goal individuati. Relativamente ad ogni Goal, esse sono: Goal - Questions: HIGH LEVEL Quanto tempo è stato necessario per installare e configurare gli strumenti? Qual è il grado di difficoltà riscontrato nell'utilizzo degli strumenti? LOW LEVEL - quanto per Eclipse? - quanto per Jazz? - quanti membri hanno incontrato difficoltà nell'utilizzo degli strumenti? - quanti team hanno incontrato difficoltà nell'utilizzo degli strumenti? Qual è l'esperienza dei partecipanti? - qual è l'esperienza dei membri? - qual è l'esperienza media dei team? Come sono considerati i materiali a supporto dell'installazione e della configurazione degli strumenti? - relativamente ad Eclipse? - relativamente a Jazz? - come sono organizzati tali materiali? - quanto sono state necessarie ulteriori ricerche personali? Qual è il livello di esperienza generale acquisito? - qual è il livello di esperienza acquisito dai membri? - qual è il livello di esperienza acquisito dai team? Goal - Questions: HIGH LEVEL Come avviene la comunicazione a livello membro? Come avviene la comunicazione a livello team? Come avviene la comunicazione tra membri e coordinatori? LOW LEVEL - quanti sono i membri che hanno riscontrato barriere linguistiche? - quanti sono i team che presentano una comunicazione perfettamente corrisposta? - quanti sono i team che hanno riscontrato barriere linguistiche? - qual è il grado di partecipazione dei membri alle iniziative dei coordinatori? - qual è il grado di partecipazione dei team alle iniziative dei coordinatori? 6

27 Qual è il grado di cooperazione raggiunto a livello membro? Qual è il grado di cooperazione raggiunto a livello team? Qual è il livello di collaborazione raggiunto? - quanto è considerata soddisfacente la velocità di assistenza? - quanto sono risultate chiare le istruzioni sul progetto? - quanti membri hanno presentato un contatto Skype? - qual è la differenza di partecipazione tra studenti italiani e americani? - quanti membri hanno raggiunto un buon livello di cooperazione? - quanti team hanno un buon numero di membri contattabili tramite Skype? - quanti team hanno raggiunto un buon livello di cooperazione? - quanti team hanno acquisito una buona esperienza collaborativa? - quanti membri hanno acquisito una buona esperienza collaborativa? Goal - Questions: HIGH LEVEL LOW LEVEL Qual è il grado di produttività dei team? - quanti team hanno almeno un work item closed? - quanti team hanno work item in progress? - quanti team hanno membri che hanno completato almeno un work item? - quanti team hanno membri che hanno completato tutti i work item a loro assegnati? Qual è il grado di produttività dei membri? - quanti sono i membri che hanno completato almeno un work item? - quanti sono i membri che hanno completato tutti i work item a loro assegnati? - quanti sono i membri che lavorano? Qual è il livello di organizzazione raggiunto? - qual è il livello di Quality of Planning raggiunto dai team? - a quanti team sono assegnati un numero di work item superiore alla media? - quanti team hanno work item con una difficoltà media superiore alla media? - quanti team presentano un buon equilibrio tra membri e work item a loro assegnati? - quanti team hanno almeno un membro lavoratore? - qual è la percentuale di task completati nel tempo di consegna? Qual è il livello di affidabilità a livello team? - quanti team hanno prodotto almeno un change set? - quanti team hanno riscontrato almeno un difetto? Qual è il livello di affidabilità a livello membro? - quanti membri hanno prodotto almeno un change set? Qual è la differenza negli stili di vita tra membri italiani ed americani? Qual è la valutazione complessiva del progetto ETCplus? - quanti membri hanno riscontrato difetti? - qual è la differenza nel numero di lavoratori tra gli studenti italiani e quelli americani? - quali sono l'utilità, la soddisfazione e la valutazione complessiva date dai team? - quali sono l'utilità, la soddisfazione e la valutazione complessiva date dai membri? - qual è il livello di esperienza nello sviluppo collaborativo raggiunto a livello team? - qual è il livello di esperienza nello sviluppo collaborativo raggiunto a livello team? Definite le Question e gli attributi che descrivono i Goal, è possibile passare alla successiva fase di Produzione del GQM Plan. Il GQM Plan è un documento strutturato nel quale ogni obiettivo è associato ad un set di metriche i cui valori, una volta rilevati, forniscono la misura del grado con il quale l obiettivo in questione è stato raggiunto. Successivamente, bisogna sviluppare un Measurement Plan per descrivere nel dettaglio tutte le metriche individuate nel GQM Plan. Ogni metrica viene descritta attraverso la definizione di linee guida e di specifiche. Tali metriche, in questo caso, corrispondono ai Variation Factors, associati ai Quality Focus di ogni Goal individuato, già precedentemente elencati. 7

28 La fase successiva prevede la Collezione e Validazione dei dati, ovvero la raccolta e la valutazione dei dati di processo e di prodotto. I dati da raccogliere per la misurazione degli obiettivi 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. 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 verranno utilizzati per rispondere a determinate Question. Raccolti i dati di interesse è possibile ora analizzarli al fine di comprendere e valutare il grado di corrispondenza tra valore ottenuto e valore atteso relativamente ad ogni Goal. A tale scopo sono state realizzate le seguenti tabelle in cui, per ciascun Goal, ad ogni dato raccolto sono associati: un valore effettivo, una metrica, un peso, una risposta (relativa al valore rilevato) ed un valore atteso. In particolare, il peso associato ad ogni metrica ed il valore atteso sono ricavati dalle Baseline Hypothesis e dai Baseline Impact che risultano in questa fase fondamentali per la veridicità del risultato fondamentale. Goal - Calcolo Percentuale di Corrispondenza: DOMANDA VALORE METRICHE PESO RISPOSTA ATTESO % team con membri che hanno incontrato difficoltà con gli strumenti 5 <x<5 75<x< % team con membri dichiaratisi esperti % team con esperienza originale minore della media % team con almeno un membro avente una conoscenza precedente di Eclipse % team con almeno un membro avente una conoscenza precedente di jazz % membri con difficoltà strumenti % membri dichiaratisi esperti % membri con esperienza originale nulla o limitata Tempo richiesto in media per imparare l'uso degli strumenti Tempo richiesto in media per imparare ad usare Eclipse Tempo richiesto in media per imparare ad usare Jazz.5 <x<5 75<x< 5 <x<5 75<x< 5 <x<5 75<x< <x<5 75<x< 9.75 <x<5 75<x< <x<5 75<x< 9 <x<5 75<x< / settimane > mesi / mesi / settimane / settimane / settimane > mesi / mesi / settimane / settimane / settimane > mesi / mesi / settimane / settimane % membri che 77 <x<5 8

29 ritengono buona la quantità del materiale riguardo Eclipse % membri che ritengono buona la qualità del materiale riguardo Eclipse 75<x< 85 <x<5 75<x< % membri che ritengono buona la quantità del materiale riguardo Jazz % membri che ritengono buona la qualità del materiale riguardo Jazz % membri che ritengono insufficiente organizzazione e uso materiali % membri per cui sono state necessarie poche o nulle ricerche personali % di membri a conoscenza di Eclipse prima del progetto % di membri a Conoscenza di jazz prima del progetto # di tutorials & video per strumento % membri che hanno acquisito una buona esperienza generale % team per cui il tempo richiesto in generale per imparare ad utilizzare gli strumenti è superiore alla media % team per cui il tempo richiesto per imparare ad utilizzare Eclipse è superiore alla media % team per cui il Tempo richiesto per imparare ad utilizzare Jazz è superiore alla media % team per cui la qualità del materiale relativo ad Eclipse è ritenuta buona % team per cui la quantità del materiale relativo ad Eclipse è ritenuta buona % team per cui la qualità del materiale relativo ad jazz è ritenuta buona % team per cui la quantità del materiale relativo ad jazz è ritenuta 6 <x<5 75<x< 58 <x<5 75<x< <x<5 75<x< 6 <x<5 75<x< 7 <x<5 75<x<.8 <x<5 75<x< Meno di per strumento Almeno per strumento Più di per strumento <x<5 75<x<.5 <x<5 75<x< 5 <x<5 75<x< 5 <x<5 75<x< 87.5 <x<5 75<x< <x<5 75<x< 87.5 <x<5 75<x< 75 <x<5 75<x<

30 % team Che ritengono insufficienti organizzazione e uso dei materiali % team per cui sono state necessarie poche o nulle ricerche personali <x<5 75<x< 75 <x<5 75<x< TOT 68 9 PERCENTUALE DI 7,8 CORRISPONDENZA Goal - Calcolo Percentuale di Corrispondenza: DOMANDA VALORE METRICHE PESO RISPOSTA ATTESO % team con comunicazione perfettamente corrisposta (commenti con risposta) 5 <x<5 75<x< 8 8 % team con almeno membri partecipanti alla presentazione 5 <x<5 75<x< % team con almeno membri partecipanti al survey <x<5 75<x< % team con almeno membri che hanno presentato un contatto Skype % team per cui le barriere linguistiche riscontrate sono risultate poche o nulle % team per cui le istruzioni sono risultate chiare % team per cui la velocità di assistenza è risultata soddisfacente 6.5 <x<5 75<x< 87.5 <x<5 75<x< <x<5 75<x< 67.5 <x<5 75<x< % membri partecipanti alla presentazione % membri partecipanti al survey % membri che hanno presentato un contatto Skype % membri per cui le barriere linguistiche riscontrate sono risultate poche o nulle % membri che ritengono insufficiente la chiarezza delle 7 <x<5 75<x< 8 <x<5 75<x< 7 <x<5 75<x< 8 <x<5 75<x< 7 <x<5 75<x<

31 istruzioni % membri che ritengono buona la velocità di assistenza differenza di partecipazione tra studenti italiani e americani 57 <x<5 75<x< ~5 Poca Nella norma molta 5 5 % membri che hanno partecipato alla votazione team leader 6 <x<5 75<x< % membri che hanno acquisito una buona esperienza collaborativa 8 <x<5 75<x< 8 % membri che hanno raggiunto un buon livello di cooperazione 7.7 <x<5 75<x< 8 % team che hanno acquisito una buona esperienza collaborativa % team che hanno raggiunto un buon livello di cooperazione.5 <x<5 75<x<.5 <x<5 75<x< 8 8 TOT 5 8 PERCENTUALE DI 6,9 CORRISPONDENZA Goal - Calcolo Percentuale di Corrispondenza: DOMANDA VALORE METRICHE PESO RISPOSTA ATTESO % di team con una buona Quality of Planning 6.5 <x<5 % di team con # work item superiore alla media % di team con almeno un work item closed % di team con work item in progress % di team con una buona distribuzione di work item per membro % team con una distribuzione di work item per team inferiore alla media % team aventi membri che hanno completato work item % team aventi membri che hanno completato tutti 75<x<.5 <x<5 75<x< 6.5 <x<5 75<x< 6.5 <x<5 75<x< 75 <x<5 75<x<.5 <x<5 75<x< 6.5 <x<5 75<x< 7.5 <x<

32 work item 75<x< % team con difetti nei work item % team con almeno un membro lavoratore % team che hanno prodotto change set % membri che hanno completato almeno work item % membri che hanno completato tutti work item % membri che hanno trovato difetti % membri che lavorano % di task completati nel tempo di consegna differenza # di lavoratori tra studenti italiani e americani % membri che danno una buona valutazione al progetto ETC % membri che ritengono utile il progetto ETC % membri che si ritengono soddisfatti del progetto ETC % team che danno una buona valutazione al progetto ETC % team che ritengono utile il progetto ETC % team che si ritengono soddisfatti del progetto ETC % membri che hanno acquisito una buona esperienza nello sviluppo collaborativo % team che hanno acquisito una buona esperienza nello sviluppo collaborativo.5 <x<5 75<x< 5 <x<5 75<x< 7 <x<5 75<x< 5 <x<5 75<x<.5 <x<5 75<x<.5 <x<5 75<x< 5~ <x<5 75<x< <x<5 75<x< ~ Poca Nella norma molta 5 <x<5 75<x< 5 <x<5 75<x< 5 <x<5 75<x< 75~ <x<5 75<x< 7.5 <x<5 75<x< 7.5 <x<5 75<x< 6 <x<5 75<x<.5 <x<5 75<x< TOT PERCENTUALE DI 67,86 CORRISPONDENZA

33 . Considerazioni finali. Dalle precedenti tabelle si evince che la percentuale di corrispondenza tra il valore atteso e quello riscontrato relativi ai tre Goal non è molto alta ma, anzi, necessita di essere sensibilmente migliorata. Nel dettaglio si ha: Goals Valore Riscontrato Valore Atteso Percentuale di corrispondenza Goal , Goal 5 8 6,9 Goal ,8 In particolare, quindi, è da migliorare tutto ciò che riguarda la collaborazione all'interno del progetto ETCplus, componente di fondamentale importanza data la metodologia di sviluppo. In particolare, deve aumentare la partecipazione degli studenti alle iniziative proposte dai coordinatori, quali presentazioni e sondaggi, che possono aiutare considerevolmente nelle valutazione di questo tipo. Da migliorare sono anche gli aspetti legati allo sviluppo, nel senso di produzione di codice e completamento di work item assegnati nel tempo di consegna stabilito. Infine, per quanto riguarda gli strumenti utilizzati, il buon lavoro dei coordinatori, con la qualità e la quantità dei materiali di supporto offerti, ha parzialmente compensato la scarsa esperienza dei partecipanti. 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. A tale scopo, oltre ai già citati documenti, sono stati realizzati fogli di calcolo, uno per ogni Goal, in ambiente Microsoft Excel. Si è ricorso a tale metodo per una migliore gestione delle metriche individuate e raccolte, allo scopo di automatizzare i calcoli relativi alle corrispondenze tra valori riscontrati e attesi, tramite semplici linee di codice.

34 Bibliografia [] Ian Sommerville - 8a edizione 7 - Ingegneria del software [] jazz.net/projects/jazz-foundation/ - Jazz Integration Architecture [] publib.boulder.ibm.com/infocenter/rtc/vrm - IBM Rational Team Concert Documentation [] jazz.net/library/article/ - Getting Started with Planning in RTC [5] jazz.net/library/article/ - Getting Started with Jazz Source Control [6] agilemanifesto.org - Manifesto for Agile Software Development [7] scumalliance.org/articles/6-key-arguments-to-sell-scrum-to-your-boss [8] en.wikipedia.org/wiki/scrum_(development) - Scrum development [9] - "Gestione della qualità" [] - "Metriche software" [] [] Victor Basili, Gianluigi Caldiera ( 99 ), "Goal Question Metric Paradigm" [] Forrest Shull, Carolyn Seaman, Marvin Zelkowitz, "Basili's contributions to Software Quality" [] Victor Basili, "GQM approach has involved to include models" [5] - Ferdinando Gorga, Paolo Maresca, Carla Milani, Giorgio Galli, "Enforcing Team Cooperation using Rational software tools: merging universities and IBM effort together"