Il processo collaborativo di sviluppo del software: Jazz e percorsi didattici di apprendimento

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Programmazione I Il processo collaborativo di sviluppo del software: Jazz e percorsi didattici di apprendimento Anno Accademico 2011/2012 Candidato: GRILLO ABELE Relatore: Prof. Paolo Maresca matr. N46/000774

2

3 Indice 1. Sviluppo cooperativo del software Introduzione Metodologie SCRUM Servizi e strumenti Piattaforma Jazz Rational Team Concert (RTC) Interfaccia Web-based Interfaccia Eclipse-based Rational Quality Manager (RQM) Rational Requirements Composer (RQM) Formazione degli studenti: e-learning L importanza del problema Sapere, fare, insegnare, diffondere Approccio ufficiale: materiale IBM Problematiche Approccio dinamico-visivo: le mappe Percorso di realizzazione Glossario e parole chiave Analisi comparativa Concetti Tempi di ricerca Tempi di apprendimento Considerazioni finali Conclusioni Sviluppi futuri Sitografia Bibliografia 38 Appendice 39 Intervista studente.39 Questionario di valutazione.41 III

4 IV

5 Capitolo 1 Sviluppo cooperativo del software 1.1 Introduzione Lo sviluppo del software è un argomento ormai di assoluta importanza nell informatica attuale: le richieste spasmodiche del mercato, l agguerrita concorrenza tra le case produttrici e il bisogno sempre più stringente di avere prodotti e materiale utilizzabile in tempi rapidi e in modo efficiente, spingono analisti ed ingegneri a ricercare le metodologie migliori per ottimizzare e personalizzare le numerose fasi che vanno dal lavoro commissionato dal cliente al rilascio della prima versione del software. Figura 1.1 Modello a cascata sequenziale dello sviluppo software Con il corso degli anni, l approccio basato su fasi sequenziali (Figura 1.1), senza ricicli per controllare meglio costi e tempi di lavoro, si è rivelato poco flessibile alle problematiche moderne 5

6 e troppo statico. L idea di fissare le cosiddette milestones alla fine di ogni passo e non poterle più modificare si scontra, infatti, pesantemente con la dinamicità dell idea di software: il prodotto di un processo di interscambio continuo, ricco e di confronto, tra cliente e team di sviluppo, un corpo plasmabile e modificabile in ogni momento del suo ciclo di vita in maniera sempre efficiente senza perdere di vista le funzionalità da seguire. Il concetto di base su cui poggia tutto lo sviluppo, infatti, è la condivisione di informazioni, dati e strumenti tra le persone dello stesso team di lavoro che, grazie alle ormai numerose tecnologie di comunicazione, possono interagire e confrontarsi anche da posizioni lontanissime tra loro, distanti migliaia di chilometri. Questo nuovo scenario rende la presenza di grandi sistemi di interazione all interno del processo di sviluppo software necessaria per poter realizzare nei migliori dei modi la cooperazione. Le operazioni di gestione e progettazione all interno del team diventano di importanza pari, e spesso anche superiore, alle effettive capacità tecniche di programmazione e creazione codice. Va così delineandosi un processo di sviluppo iterativo ed incrementale in cui i sottoprocessi di specifica, progettazione, testing e manutenzione viaggiano su binari paralleli. Questa tipologia di metodi viene definita agile o leggera in quanto punta ad adattarsi il più possibile ai cambiamenti dei requisiti utente. Questi ultimi, infatti, sono soggetti spesso ad una profonda evoluzione, dalla loro prima stesura all atto della commissione del lavoro fino alla sua conclusione, che non può essere predetta. L iterazione delle attività in parallelo renderà possibile il soddisfacimento delle richieste degli stakeholders: alla fine di ogni ciclo, infatti, gli artefatti realizzati dal team verranno discussi, analizzati e se necessario corretti per avere così nelle fasi successive un risultato ottimizzato alle loro esigenze. Trovando il giusto compromesso tra la tempistica delle fasi e la suddivisione del lavoro nei cicli, si potrà avere un prodotto finale efficiente, coerente al progetto iniziale ed in tempi molto più brevi rispetto all approccio sequenziale. Risulta evidente, infine, che la figura dello sviluppatore software cambia radicalmente rispetto all idea tradizionale: con lo sviluppo agile e cooperativo, esso dovrà essere competente anche e soprattutto in campi come il testing, l analisi e la progettazione, oltre che ad avere una necessaria predisposizione alla collaborazione ed al lavoro di gruppo Metodologie SCRUM Le prime metodologie agili hanno visto la luce tra la fine degli anni 80 e l inizio degli anni 90, ma è nell ultimo decennio che si è avuta una diffusione su ampia scala di questa tipologia di sviluppo software; in particolare, dopo la stipulazione del cosiddetto Manifesto agile che ha fissato i principi generali di tale approccio (2001). Da quel momento sono state presentate decine di metodologie agili come extreme Programming, Feature Driven Development, DSDM, Crystal e Lean Software Development che hanno trovato numerose applicazioni nell industria del software 6

7 mondiale. Quella, però, più utilizzata ad oggi resta la SCRUM ormai largamente alla base dei processi di sviluppo di aziende del calibro della IBM, Nokia, Google e Yahoo. Ideata e sviluppata da Ken Schwaber e Mike Beedle e distribuita da Advanced Development Methods, tale metodologia prende il nome dall omonimo termine utilizzato nel rugby: scrum, infatti, letteralmente vuol dire mischia ed in ambito sportivo indica il pacchetto di otto giocatori che si contrappone a quello avversario per conquistare il possesso della palla ovale. E chiara la metafora tra questa situazione di gioco e lo scenario agile, in particolare, tra lo scrum e il 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. Grazie infatti ad una serie di regole, metodi e ruoli ben prefissati, lo SCRUM si pone l obiettivo di sfruttare nella maniera più efficiente e corretta possibile le risorse strumentali ed umane a disposizione del team di lavoro per poter arrivare al risultato finale nella maniera più rapida e funzionale possibile. Il concetto alla base di questa metodologia è l iterazione: il processo di sviluppo infatti viene suddiviso in cicli scrupolosamente pianificati all atto dell analisi del lavoro (i cosiddetti Sprint) che permettono di giungere in maniera incrementale al rilascio del prodotto finale. Proprio questa natura dello SCRUM ha permesso il suo utilizzo non solo in ambito informatico, ma anche in molti altri settori dell industria. Al termine di ogni Sprint verrà controllato il lavoro fatto da ogni singolo membro del team e confrontato con i programmi prestabiliti in modo da poter in breve tempo adattare il lavoro futuro all evolversi in tempo reale dello sviluppo (Figura 1.2). Figura 1.2 L iterazione nello SCRUM Un punto fondamentale infatti è rappresentato dalle riunioni che scandiscono la fine di ogni iterazione e l inizio della successiva. A seconda del momento e dei problemi affrontati possono distinguersi varie tipologie di incontro: il Daily Scrum in cui si valutano i progressi e si stabilisce il lavoro fino al prossimo Daily; gli Sprint Review e gli Sprint Planning Review in cui si controlla l avanzamento verso il rilascio del prodotto e si organizza il prossimo Sprint; lo Sprint Retrospective in cui si studiano gli adattamenti da introdurre nel prossimo Sprint. Le 7

8 considerazioni fatte durante questi meeting vertono sull analisi di tre principali artefatti, che aiutano il team a tenere sempre un rapporto chiaro su ciò che è stato fatto e su ciò che va fatto. Il concetto di backlog svolge un ruolo considerevole all interno dello sviluppo come strumento essenziale per la gestione dei carichi di lavoro: il Product Backlog elenca per priorità tutti i requisiti del prodotto da realizzare; lo Sprint Backlog tiene traccia di ciò che si deve implementare durante un preciso Sprint. Per avere, invece, un sunto grafico del lavoro mancante al rilascio vengono utilizzati i cosiddetti Burn-Down Charts. L organizzazione all interno dello stesso team, invece, avviene affidando a ciascun membro un ruolo ben preciso che fissa univocamente le funzioni che gli spettano: il Product Owner ottimizza il lavoro del team ed assegna i compiti a tutti; lo Scrum Master risolve le problematiche affinché il programma di lavoro fissato nelle riunioni sia rispettato; il Team Member è colui che compie praticamente il lavoro assegnatogli. Una struttura così rigorosa e precisa (Figura 1.3), porta a vantaggi notevolissimi se confrontata con le vecchie metodologie. In primo luogo il rapporto tra cliente e team di sviluppo ne esce rafforzato e rinnovato: il primo può controllare il lavoro che finanzia giornalmente e scrupolosamente apprezzandone da subito, già dopo pochissimi giorni, l avanzamento e la qualità e potrà intervenire in ogni istante del processo indicandone modifiche da apportare e miglioramenti. Il cliente è il primo progettista e gestore del software ed effettuerà il primissimo testing ancor prima del rilascio del prodotto: risulta evidente l attenzione rivolta alla tempistica del tutto. Inoltre, grazie alle interazioni cicliche, ogni problematica viene subito identificata, isolata e risolta entro la fine dello Sprint e ciò rende il fallimento globale del sistema molto raro. Figura 1.3 Schema riassuntivo struttura SCRUM 8

9 1.2 Servizi e strumenti In un ambiente di sviluppo collaborativo del software la presenza di una infrastruttura di strumenti che permette la condivisione delle informazioni e dei dati risulta necessaria. La diffusione di Internet ormai in ogni angolo del pianeta ha certamente aiutato le metodologie agili e il loro concetto di cooperazione tra persone anche a migliaia di chilometri di distanza: non è un caso che questo tipo di sviluppo si è evoluto in maniera sostanziale soprattutto con la nascita e la crescita del Web e delle reti di calcolatori (inizi anni 90). Essendo numerose le attività di gestione e di controllo dell intero sistema, infatti, sono altrettanto numerosi i servizi che devono essere forniti dall insieme di strumenti utilizzati: Dovrà essere possibile gestire facilmente i membri all interno del team attraverso l utilizzo di ruoli che specificano in maniera precisa le mansioni di ciascuno e le proprie qualifiche. Ogni compito all interno dello sviluppo deve poter essere pianificato con chiarezza sia nel breve che nel lungo termine in modo da avere sempre ben fissato l obiettivo parziale e finale. La comunicazione nel team deve essere immediata, in tempo reale ed efficiente per poter permettere lo scambio di informazioni e la condivisione di prodotti. Tutto deve potersi svolgere in completa sicurezza e regolato attraverso diritti di accesso diversi per ogni ruolo di ogni membro. Data la ovvia concorrenza con cui si avrà accesso agli artefatti ed ai prodotti di ogni fase dello sviluppo, dovranno essere presenti sistemi di controllo di versione, i cosiddetti CVS (Concurrent Versioning Systems), che regolano e tengono traccia di ogni rilascio di ogni prodotto e che gestiscono e risolvono gli eventuali conflitti tra modifiche contemporanee dello stesso file. In questo modo è possibile tenere sempre una visione chiara dell evoluzione delle modifiche di uno specifico prodotto e poter quindi programmare al meglio gli sviluppi futuri. Dovranno essere gestiti, catalogati ed identificati tutti i tipi di bug che possono fare la loro comparsa durante una qualsiasi delle iterazioni. Ogni difetto deve essere memorizzato e descritto dettagliatamente per aiutare il team alla sua risoluzione anche in tempi successivi. Per un corretto bilanciamento dei carichi di lavoro da assegnare ad ogni membro e per una valida gestione delle attività da svolgere, si dovranno avere sempre a disposizione strumenti in grado di dare un idea immediata del lavoro svolto e da svolgere; grafici, tempi di sviluppo, percentuali di attività concluse e dati simili dovranno accompagnare gli sviluppatori durante tutto il processo in modo che abbiano sempre tutte le informazioni utili a portata di mano. 9

10 1.3 Piattaforma Jazz Il nuovo approccio collaborativo ed iterativo introdotto dalle metodologie agili, come ad esempio quella SCRUM, ha permesso un riutilizzo ottimizzato di tutto ciò che in ambito di sviluppo software era già stato ampiamente regolarizzato nei decenni precedenti: cambia ora il modo di svolgere quelle stesse attività in nome dell integrazione, della condivisione e della cooperazione. L approccio cosiddetto C/ALM (Collaborative Application Lifecycle Management) punta ad automatizzare tutte le operazioni di processo ripetitive e che non hanno necessità dell intervento diretto dell uomo, al fine di snellire considerevolmente la gestione delle attività che altrimenti crescerebbe in maniera esponenziale con l aumento del numero di membri nel team. Ciò permette in sostanza l impiego efficiente delle metodologie agili e su questi stessi concetti si basa la piattaforma Jazz: un infrastruttura solida, monolitica e soprattutto accentrante in grado di racchiudere in un unica architettura tutte le applicazioni e le attività automatizzate dello sviluppo software (platform) con la possibilità di operare in ingresso ed in uscita per integrazioni e condivisioni su ampissima scala attraverso l utilizzo della rete e delle interfacce definite dalla Jazz Integration Architecture (JIA), il tutto implementato sul sistema software Jazz Team Server che fornisce i primi servizi agli utenti. La piattaforma Jazz punta all innovazione dello sviluppo software e ad assumere una funzione d avanguardia per il futuro, il tutto open source e completamente gratuito: da qui il nome per richiamare lo stesso spirito che spinse la comunità afroamericana ad introdurre sonorità nuove e variegate negli Stati Uniti di inizio ventesimo secolo. Jazz introduce concetti chiari e ambiziosi: separa l implementazione degli strumenti dall accesso ai dati; condivide questi ultimi su database indipendenti usando protocolli Internet, non ammettendo quindi la presenza di tutti i dati in un unico luogo fisico; permette l accesso a qualsiasi informazione direttamente nel luogo in cui si risiede; utilizza strumenti progettati e realizzati in codice fruibile facilmente ed efficacemente dalla rete Web; supporta molteplici tecnologie client (Web-based, Eclipse-based, Visual Studio-based) permettendo così un uso vasto e semplificato delle proprie funzionalità; in tre semplici parole Jazz introduce un modello aperto, flessibile e distribuito. Con esso vengono poste le fondamenta per l integrazione di molti tipi di applicazioni lifecycle: oltre, infatti, al lato architetturale della piattaforma, Jazz introduce anche un ampio set di frameworks e toolkits che permettono un utilizzo più efficace, semplice ed armonico degli strumenti che andranno a lavorare in questo ambiente e di cui parleremo a breve. La prima applicazione che lavora sulla piattaforma è la Jazz Foundation che realizza i primi servizi riguardanti la gestione del server e la regolazione degli accessi ad esso attraverso un interfaccia web. E proprio attraverso questa prima application che l utente può visionare i dati effettivi del database condiviso ed il loro livello di memorizzazione e, da tale interfaccia, utilizzare lo specifico strumento da uno dei tipi di client accettato dall architettura. Inoltre è seguita la norma di realizzare ogni applicazione utilizzante Jazz con il framework Jazz Foundation Application SDK in 10

11 modo da rendere la variegatissima famiglia di tools esistenti più omogenea agli occhi dell utente (Figura 1.4). Figura 1.4 Piattaforma Jazz (da Rational Team Concert (RTC) Tra le numerose applicazioni jazz-based in commercio, IBM Rational Team Concert è ormai quella maggiormente diffusa nel mondo dello sviluppo agile. Essa racchiude in un unico ambiente di lavoro i concetti principali delle metodologie agili puntando sulla semplificazione, gestione, ottimizzazione, visibilità e trasparenza delle attività C/ALM e dei processi finalizzati alla produzione del software. Inoltre completa le funzionalità di regolazione dell accesso ai dati già introdotte dalla Jazz Foundation con precise ed efficienti politiche di sicurezza che però non vanno ad appesantire oltremodo il complesso sistema. RTC introduce una serie di funzionalità che vanno a toccare tutti gli aspetti dello sviluppo software moderno: dal concetto di tempo reale nella collaborazione tra membri e nella valutazione dell avanzamento del processo, alla flessibilità dell utilizzo della piattaforma, dalla qualità del software all incremento della produttività globale. L utente che andrà ad agire in questo ambiente può facilmente andare a svolgere tutte queste attività grazie agli strumenti che mette a disposizione l RTC (Figura 1.5). Infatti è possibile creare i propri progetti collaborativi ex novo o utilizzare i vari modelli presenti nell ambiente e configurarli a seconda delle proprie esigenze; inoltre è possibile pianificare il lavoro (work items) e controllarlo attraverso degli specifici obiettivi dati ad ogni membro del team (task). I prodotti e le release parziali saranno poi condivisi su particolari spazi di lavoro 11

12 (repository) messi a disposizione dell intero team e su cui potranno realizzarsi facilmente analisi di ogni tipo e creare i primi report del lavoro svolto. Figura 1.5 Funzionalità del Rational Team Concert Le procedure per gestire il tutto sono lineari ed intuitive grazie alle varie viste grafiche disponibili in RTC che aiutano il cliente ad avere sempre chiara la sua posizione all interno del processo e ad agire di conseguenza: innanzitutto l utente dovrà scaricare una versione client del programma IBM specifica per l utilizzo che vuole farne (Visual Studio o Eclipse per esempio) ed installarla sul suo terminale. Dopo questa operazione dovrà registrarsi presso la community di Jazz in modo da poter accedere a tutte le funzionalità dell RTC. Avute tutte le credenziali e con la propria copia del programma già installata e pronta per l uso, l utente potrà aggregarsi ad un progetto già esistente, accettando uno specifico invito, o crearne uno nuovo per le proprie esigenze. In entrambi i casi potrà creare in poche mosse il proprio repository, che può essere pubblico, privato o ambito, per essere sempre aggiornato e sincronizzato in tempo reale con le modifiche apportate da qualsiasi membro del suo progetto a qualsiasi file. Grazie poi al gioco di viste e schermate del client RTC, lo stesso utente può addirittura modificare nella pratica il codice in formato java, o in qualunque altro formato di programmazione, nello stesso ambiente di sviluppo del software. La conferma della modifica viene ufficializzata dall operazione di check-in che avverte il team dell avvenuto salvataggio. Un ambiente così complesso, ma allo stesso tempo completo, può essere inevitabilmente soggetto a conflitti di vario genere, soprattutto in ambito di modifiche ai file: può capitare, infatti, che una modifica in locale da parte di un membro risulti all atto del check-in più vecchia di un altra effettuata da un altro membro. E possibile a questo punto seguire varie scelte sul da farsi, ma si preferisce attuare la cosiddetta unione delle modifiche, un accorgimento tanto semplice quanto funzionale. In caso di conflitti l RTC unirà, nel senso letterale del termine, la copia locale del file del membro con la copia presente nel repository pubblico del progetto in modo da non buttare via niente che potrebbe compromettere il lavoro futuro. Solo in un secondo momento, dall analisi di tale nuova risorsa, si deciderà se confermarla e quindi salvarla nello spazio di lavoro (commit) o scartarla. 12

13 Tra i vari client supportati dalla piattaforma Jazz, ad oggi, quello più utilizzato è quello basato su Eclipse, molto efficiente per operazioni di programmazione pura e progettazione, che così va ad accompagnarsi all altra interfaccia messa a disposizione degli utenti e spesso preferita per operazioni di project management e di valutazione del lavoro: la web-based Interfaccia Web-based L interfaccia Web-based nasce per venire incontro alle esigenze dell utente di gestire e controllare il proprio progetto. Con essa è possibile avere sempre una panoramica facile da visionare e semplice da utilizzare per avere ogni sezione del processo software sempre a portata di mano. Tramite essa si può accedere al Jazz Team Server attraverso il normale browser web presente sul proprio terminale senza dover installare del software aggiuntivo. Tale vista è rivolta soprattutto agli stakeholders, non interessati ai dettagli dell implementazione, ma che invece hanno tutte le intenzioni e gli interessi a seguire passo passo l evoluzione del proprio prodotto ed a verificare che le richieste siano di volta in volta seguite e soddisfatte. La pagina web principale di questo tipo di interfaccia permette all utente di inserire i propri dati per effettuare il login e poter così avere accesso al Jazz Team Server ed entrare nell area progetto di interesse. Si aprirà così una prima dashboard di progetto (Figura 1.6), un contenitore che presenterà informazioni globali riguardanti i singoli membri del team, i compiti a loro assegnati e lo stato d avanzamento del lavoro. Tutta la pagina sarà personalizzabile a seconda delle proprie esigenze: sarà possibile aggiungere o eliminare campi ed oggetti (widgets). Ogni componente presente sulla dashboard è il risultato di precise richieste query effettuate dall utente in cerca di un particolare aspetto riguardante il progetto: l interazione tra il visionatore e le informazioni è massima e, con essa, anche la snellezza delle procedure. Figura 1.6 Dashboard interfaccia web RTC 13

14 In alto alla dashboard un menù permette l accesso ad ulteriori viste di controllo in base ai permessi che si hanno per quel particolare progetto. Cliccando su Work Items sarà possibile osservare e gestire le attività del processo ed accedere a singoli elementi di lavoro attraverso specifiche richieste; oppure aggiungere nuovi items, catalogarli e completarli con file uml, grafici ed altro codice. Sempre dallo stesso menù è possibile visionare anche i piani (Plans) che regolano il lavoro assegnato, raccolgono informazioni su percentuali di sviluppo e stabiliscono collegamenti tra i singoli items. Nella sezione Report si potranno analizzare tutti i progressi del progetto. Si può tenere sotto controllo anche il repository comune contenente i dati e i prodotti realizzati nel corso delle attività attraverso la voce Source Control e gestirli invece nell area Build Interfaccia Eclipse-based L ambiente di sviluppo di programmazione Eclipse fornisce agli utenti vari plugin per poter lavorare con le funzionalità di Rational Team Concert direttamente al suo interno, unendo così le attività di realizzazione software con quelle di gestione e controllo. Il gioco di prospettive di questo client permette di lavorare su diversi livelli in base alle attività da svolgere. In questo modo è possibile configurare il proprio plugin Eclipse e i propri strumenti per ottimizzare il lavoro di particolari aspetti del processo come il testing, la progettazione, il debugging o l implementazione. Oltre alle viste e prospettive già intrinseche nell ambiente, il Rational Team Concert per Eclipse IDE ne introduce altre per gestire operazioni come il planning, l accesso in concorrenza ai repository condivisi, la gestione del server e molte altre (Figura 1.7). Figura 1.7 Prospettive in RTC per Eclipse IDE Dall interfaccia, infatti, è possibile scegliere tra varie schede procedendo da sinistra a destra: la Package Explorer mostra cartelle e sottocartelle caricate sul server e contenenti i files; la My Work tiene traccia dell avanzamento del lavoro personale; la Team Artifacts visualizza tutti i dati presenti sul server ed appartenenti a quel progetto attraverso i vari flussi a livelli; la Process 14

15 Templates mostra i vari modelli di processo utilizzabili dall ambiente per il proprio progetto; la Team Organization elenca tutti i membri costituenti il team di lavoro di quel progetto. Ogni vista, inoltre, presenterà ulteriori sottoschede (Problems, Javadoc, Declaration, Work Items, Team Advisor, Pending Changes, Builds, Repository Files, Change Explorer) contenenti altre informazioni sui singoli files, il codice, i componenti realizzati e bug riscontrati nel corso dello sviluppo. 1.5 Rational Quality Manager (RQM) IBM Rational Quality Manager permette la gestione facilitata delle fasi di testing e delle problematiche relative alla individuazione dei rischi durante la fase di sviluppo ed alle conseguenze che questi ultimi possono portare. RQM, come il già citato RTC, sfrutta le enormi potenzialità della piattaforma Jazz per realizzare un ambiente di lavoro per la creazione di report di controllo, gruppi di lavoro, piani di testing finalizzati ad un completo e continuo monitoraggio del processo software. E possibile provare le versioni demo e trial di durata 60 giorni, scaricandole direttamente dal sito ufficiale Jazz e così testare con le proprie mani le potenzialità di questo strumento che si integra ottimamente con gli altri tool della grande famiglia delle applicazioni jazz-based IBM Rational. Come prevedibile, l entità centrale di un istanza RQM è il test. Esso può riferirsi ad un particolare artifact o all intero progetto e dovrà, in entrambi i casi, essere superato bene dal software per far si che le proprietà di qualità e incorruttibilità del software siano rispettate a dovere. L organizzazione gerarchica dei test introdotta dall applicazione RQM, permette di agglomerare i singoli controlli in veri e propri piani di test spesso anche complessi ed incrociati tra loro, in modo da verificare ogni aspetto, anche il più nascosto, del prodotto che si sta realizzando. Sarà possibile, naturalmente, pianificare i testing durante tutto il corso della produzione o farli scorrere in cascata seguendo rapporti di ereditarietà di tipo padre-figlio. Di enorme importanza sarà gestire e valutare i risultati di tali test in modo da poter apportare modifiche giuste e coerenti al sistema. RQM valuta il risultato di un singolo test in base ad operazioni matematiche di media tra tre specifici valori: Verosimiglianza, Impatto e Impatto corrente. Nel conto finale del risultato di un intero piano di test entra in gioco anche la cosiddetta Gravity (tra 1 e 5), che definisce il peso in termini di importanza per il committente di quello specifico artifact: lo stesso rischio, e quindi lo stesso test, può avere, infatti, conseguenze diverse a seconda di cosa si sta analizzando. Negli ultimi tempi la IBM, in integrazione all RQM, ha introdotto la suite Worksoft Certify che punta ad ottimizzare le funzionalità già introdotte dallo strumento Rational e soprattutto ad automatizzare tutto il ciclo di vita del testing, così da velocizzare i tempi di valutazione dei rischi e di rilascio del software finale (si parla di un incremento fino al 60%) e ridurre notevolmente i costi. 15

16 1.6 Rational Requirements Composer (RRC) L applicazione jazz-based IBM Rational Requirements Composer fornisce numerose funzionalità per la gestione dei requisti di progetto. Grazie ad essa il team di sviluppo può definire, gestire e documentare ogni requisito ricavato dai vari confronti tra l analizzatore ed il committente. Come i precedenti strumenti Rational, anche l RRC sfrutta ampiamente il Web per realizzare e soddisfare le caratteristiche delle metodologie agili. Utilizza processi leggeri ed iterativi riducendo costi ed inutili rielaborazioni delle analisi delle specifiche. Rational Requirements Composer consente di gestire: I rapporti tra interlocutori molteplici (per esempio utenti, responsabili marketing, sponsor, legali, analizzatori, stakeholders) distribuiti in aree geografiche lontanissime tra loro attraverso la rete Internet. Il ciclo di vita dei requisiti che ora, grazie alla flessibilità del sistema, è più chiaro ed immediato; con questo approccio sarà possibile una maggiore collaborazione tra domanda e team e in tempi brevi si potranno fissare precisamente i requisiti. L intero processo software che risulta ottimizzato in ogni suo aspetto, dallo studio dei requisiti allo sviluppo codice, dalla gestione della qualità al testing, tutto in un ambiente integrato. 16

17 Capitolo 2 Formazione degli studenti: e-learning 2.1 L importanza del problema Con un panorama di strumenti così ampio ed articolato, di cui le tre applicazioni Rational appena viste rappresentano solo la punta dell iceberg, risulta di notevole importanza fornire allo studente, interessato a conoscere il mondo agile, una guida chiara per assimilare i concetti base ed una certa manualità con i tools. Come accennato anche in precedenza, lo sviluppo cooperativo del software è un argomento relativamente recente rispetto all evoluzione dello sviluppo del software, quindi non è stata formalizzata ancora una documentazione completa, in termini di manuali, libri o siti internet, in grado di trattarlo a dovere. Oltre a qualche articolo scientifico pubblicato in rete c è poco altro a riguardo e questo non aiuta lo studente alle prime armi a capire sia gli aspetti generali che quelli più dettagliati. In particolare tutta la parte tecnica del nuovo processo software, dalla piattaforma Jazz ai singoli strumenti di lavoro, è trattata essenzialmente solo dai siti ufficiali (come e in generale da materiale IBM, l azienda informatica che in prima persona si occupa dello sviluppo dell intera piattaforma e del rilascio periodico dei toolkits da applicare in questo ambiente. Essendo così ancora scarno il materiale da studiare ed analizzare, lo studente può trovarsi in chiara difficoltà nel ricercare i testi che possono essergli utili per una ricerca personale sull argomento. Quello che stiamo vivendo, in ambito di sviluppo informatico, è un periodo di transizione: è chiaro infatti ormai da tempo che lo sviluppo cooperativo assumerà sempre maggiori consensi con il passare del tempo e sarà sempre più adoperato nei vari settori industriali; dall altro lato, però, ci troviamo di fronte ad una documentazione la cui realizzazione è ancora in corso e che procede di 17