Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali

Transcript

1 Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Tecnologie per la Società dell Informazione Implementazione del Modello QEST nd in Spago4Q RELATORE: Prof. Ernesto Damiani CORRELATORE Ing. Sergio Oltolina TESI DI LAUREA DI: Mauro Regoli Matr Anno Accademico 2008/2009

2 Ai miei genitori

3 Ringraziamenti Desidero innanzitutto ringraziare il Prof. Ernesto Damiani per la fiducia dimostratami nell aver accettato la mia proposta e per i preziosi insegnamenti impartiti durante questi anni di carriera universitaria. Inoltre, ringrazio Engineering Ingegneria Informatica S.p.A. per avermi dato la possibilità di svolgere questo lavoro; il mio pensiero è rivolto in particolare all Ing. Davide Dalle Carbonare, a cui va la mia maggiore gratitudine per essere stato un costante punto di riferimento durante tutte le fasi del progetto e per la pazienza dedicatami, all Ing. Sergio Oltolina per avermi fornito materiale e dati indispensabili e al Dott. Nicola Bertazzo per il supporto durante la realizzazione dei report e dei grafici. Un ringraziamento sentito anche al Dr. Fulvio Frati per la continua disponibilità e prontezza nella rilettura di tutti i capitoli della tesi e per i suggerimenti sulla stesura della stessa. Infine, non posso dimenticarmi dei miei compagni di Università, nonché amici, Marco, Domenico e Andrea per i numerosi consigli durante l elaborato. Un grazie anche a Carlo per i suggerimenti su Latex. ii

4 Indice Elenco delle Figure vi Introduzione 1 1 Misurare il Software Il Ciclo del Miglioramento Introduzione La Scelta di un Approccio: il Framework Based La Realizzazione del Modello Il Processo di Misura Generalità Il Ciclo PDCA Il Modello ISO Requisiti Generali Monitoraggio e Misurazione Gestione delle Non Conformità Analisi dei Dati per il Miglioramento Miglioramento Il Modello CMMI Generalità La Rappresentazione Scalare Le Macro Aree di Applicazione Measurement and Analysis Process [24] Il Modello Goal Question Metric Caratteristiche Elaborazione del GQM: un Esempio I Modelli Multidimensionali: la Famiglia QEST L Importanza di un Valore di Performance Unico Il Modello QEST Introduzione Implementazione dei Requisiti Il Modello LIME Il Modello QEST nd Perché n-dimensioni La Rappresentazione Geometrica iii

5 2 SpagoWorld SpagoWorld Spago Caratteristiche L Architettura Il Modulo Controller Il Modulo View I Metodi Action e Module Lo Svolgimento del Processo Altri Servizi per Spago SpagoBI Il Modello L Architettura SpagoBI Server SpagoBI Studio SpagoBI Meta SpagoBI SDK Spago4Q Il Meta-modello L Approccio MOF Il Meta-modello del Processo Il Meta-modello di Misurazione Il Meta-modello di Valutazione Il Meta-modello del Trigger L Architettura di Spago4Q Il Processo Il Modello del Data Warehouse Spago4Q Implementazione di Qest nd Strumenti Utilizzati Apache Tomcat MySQL MySQL Administrator MySQL Query Browser Eclipse BIRT Un Esempio di Implementazione Step 1 - Definizione del Modello e dei KPI Step 2 - Definizione dei Pesi e delle Soglie Step 3 - Definizione del Quality Factor Step 4 - Raccolta delle Misure Step 5 - Calcolo dei Valori delle Metriche Step 6 - Calcolo del Valore delle Dimensioni Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Step 8 - Calcolo del Valore di Performance

6 3.2.9 Step 9 - Realizzazione dei Report Esecuzione e Visualizzazione Due Esempi di implementazione Primo Caso d Uso Step 1 - Definizione del Modello e dei KPI Step 2 - Definizione dei Pesi e delle Soglie Step 3 - Definizione del Quality Factor Step 4 - Raccolta delle Misure Step 5 - Calcolo dei Valori delle Metriche Step 6 - Calcolo del Valore delle Dimensioni Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Step 8 - Calcolo del Valore di Performance Step 9 - Realizzazione dei Report Esecuzione e Visualizzazione Secondo Caso d Uso Step 1 - Definizione del Modello e dei KPI Step 2 - Definizione dei Pesi e delle Soglie Prima Istanza Seconda Istanza Step 3 - Definizione del Quality Factor Step 4 - Raccolta delle Misure Step 5 - Calcolo dei Valori delle Metriche Step 6 - Calcolo del Valore delle Dimensioni Prima Istanza Seconda Istanza Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Step 8 - Calcolo del Valore di Performance Step 9 - Realizzazione dei Report Esecuzione e Visualizzazione Prima Istanza Seconda Istanza Bibliografia 127

7 Elenco delle figure 1 Il modello di Business del gruppo Engineering La presenza internazionale del gruppo Engineering I clienti più importanti su tutti i mercati Ciclo del miglioramento aziendale Rappresentazione di un generico processo di misura Rappresentazione del Ciclo di Shewhart/Deming La scala di maturità di un organizzazione nel CMMI [24] L architettura del modello CMMI staged [24] Confronto tra rappresentazioni del CMMI [24] CMMI Process Areas Measurement and Analysis process (fonte CMMI / SEI) I ruoli ed i flussi in gioco nella realizzazione di un GQM [1] Struttura gerarchica del modello GQM [1] Rappresentazione grafica delle coordinate e dello scopo di un goal [1] Il quadro completo del GQM di esempio [1] Rappresentazione geometrica di QEST con le dimensioni E, S, T come base degli assi e la performance P come vertice [3] I piani (Qe, Qs, Qt) e (Qe, Qs, Qt ) da cui è possibile esprimere QF e RP [3] Performance dal punto di vista della distanza HH [3] Performance dal punto di vista dell area (Qe, Qs, Qt ) [3] Performance dal punto di vista del volume (la sezione bianca del solido) [3] Il ciclo PMAI usato da QEST [4] Il modello Goal Question Measure Ratio [4] La matrice di posizionamento aziendale Il modello LIME applicato ad un ciclo waterfall [5] Input ed output secondo l approccio ETVX [5] Il modello LIME ed il ciclo PMAI [5] Un esempio di diagramma di Kiviat [8] Grafi di simplex da 2 a 7 dimensioni [9] Lo stack di SpagoWorld [11] L architettura di Spago [11] Le funzionalità disponibili in SpagoBI [15] La piattaforma di integrazione di SpagoBI [13] vi

8 2.5 L architettura di SpagoBI Server [12] Il modello analitico di SpagoBI [12] Le tecnologie utilizzate da SpagoBI [15] Il meta-modello modulare di Spago4Q: i colori distinguono i meta-modelli di Processo (giallo), Misurazione (verde), Rilevamento (azzurro) e Trigger (rosso) [19] Il meta-modello del Processo di sviluppo [17] Il meta-modello del Processo di Misurazione [18] Il meta-modello Trigger e le relazioni con gli altri livelli [18] La visione d insieme del modello architetturale di Spago4Q [17] Il modello di misurazione nel DWH Spago4Q Il modello di valutazione nel DWH Spago4Q La struttura del DWH Spago4Q L interfaccia per la definizione di un nuovo modello Un modello definito comprensivo di KPI L interfaccia per la definizione dei KPI L interfaccia per la creazione di una soglia L interfaccia per la definizione degli intervalli Un esempio di soglie a tre e due intervalli L interfaccia Source Type Detail L interfaccia Interface Type Detail L interfaccia Interface Field Detail L interfaccia Extraction Process Detail L interfaccia Operation Detail L associazione tra i campi della fact table e della sorgente dati L interfaccia per avviare il caricamento dei dati L interfaccia Data Set Detail I parametri richiesti per la connessione al Data Source L interfaccia per la definizione di un report in Spago4Q Visualizzazione di valori e soglie di ciascuna dimensione Visualizzazione di valori e soglie dell intero progetto Il quadro delle variazioni dei valori di una metrica nel relativo progetto Il modello generico di GQM-QEST L istanza di modello di GQM-QEST I KPI utilizzati in GQM-QEST I pesi e le soglie di ciascun KPI nel modello GQM-QEST La tabella ft qest direct metrics Query SQL per il report del primo caso d uso Il grafico della performance di progetto Driver analitici per l esecuzione del documento I risultati della dimensione economica I risultati della dimensione sociale I risultati della dimensione tecnica Il risultato di performance globale

9 4.13 Il modello Business-Service-Model e la sua istanza I pesi e le soglie di ciascun KPI del modello Business-Service-Model I dati del primo mese I dati del secondo mese I dati del terzo mese La tabella ft qest business service Query SQL per il primo report Query SQL per il secondo report Il grafico raffigurante il trend mensile del progetto Query SQL per il terzo report Il grafico rappresentante il trend mensile del progetto con le sue dimensioni Query SQL per il quarto report Il grafico di confronto tra le performance dei progetti Query SQL per il quinto report Il grafico di confronto tra le performance di progetti e dimensioni Prima istanza: i tre progetti dopo il primo mese Prima istanza: i tre progetti dopo il secondo mese Prima istanza: i tre progetti dopo il terzo mese Seconda istanza: i tre progetti dopo il primo mese Seconda istanza: i tre progetti dopo il secondo mese Seconda istanza: i tre progetti dopo il terzo mese

10 Introduzione In un settore complesso ed imprevedibile come quello informatico, dove le tecnologie ed i prodotti subiscono una continua e rapida evoluzione, è di fondamentale importanza per le Aziende acquisire informazioni strategiche per conservare la loro competitività e continuare ad operare nei nuovi scenari di mercato. Il termine coniato per racchiudere in un unico concetto l insieme dei processi aziendali e degli strumenti utilizzati per l acquisizione delle risorse è Business Intelligence. All interno di questo settore esiste un ampia varietà di modelli strutturati e di software che, adottati secondo il contesto operativo e la dimensione aziendale, aiutano ad arricchire le conoscenze sui processi di sviluppo per potenziare sia i prodotti che il modus operandi da un punto di vista qualitativo e di efficienza. Lo scopo di questa tesi è mostrare in modo pratico come utilizzare un modello, QEST nd, mediante un software, Spago4Q. QEST nd (Quality factor + dimensione Economica, Sociale e Tecnica) è un modello multidimensionale proposto da Luigi Buglione [7] per la misurazione della performance di progetti software. La multidimensionalità racchiude tre concetti molto importanti: gli obiettivi da misurare sono ricavati da diverse aree aziendali (dette anche dimensioni, punti di vista o prospettive) oltre a quelle economica, sociale e tecnica; il numero di aree aziendali coinvolte è variabile in ogni progetto e non è previsto un limite massimo (da qui l acronimo nd - varie Dimensioni); consente alle organizzazioni di scegliere le componenti di ciascuna prospettiva in base ai loro bisogni. Tenendo sotto osservazione più punti di vista, si eleva la qualità della raccolta dei dati e si evita la perdita di controllo sull analisi per mancanza di informazioni. Inoltre, si riesce a rappresentare la realtà più approfonditamente potendo includere numerosi aspetti. Questa filosofia rende QEST un modello aperto, non legato ad un processo specifico ed adattabile a qualsiasi sviluppo; è in casi come questo che si può parlare di misurazioni multi-processo e multi-progetto. L obiettivo finale è esprimere la performance (p) come una combinazione delle misure selezionate per ognuna delle prospettive presenti. Il valore di ciascuna dimensione sarà poi dato dalla somma pesata delle misure normalizzate sottostanti. L approccio comprendente l indicatore di performance globale non è stato finora incontrato in altre strutture di misurazione ed è ben presto divenuto il vero punto di forza di QEST 1

11 2 e di tutti quei modelli basati su di esso. Questa misura aggiuntiva semplifica notevolmente le cose: fornisce un impatto immediato sull andamento complessivo di un progetto, sia visivo che concettuale, consentendo un ottimale comprensione ed un idea istantanea della situazione; permette un analisi di tipo top-down, partendo dall indicatore unico, nel quale convergono tutte le misure, fino ad arrivare alla valutazione delle singole misure di base dopo aver esaminato i valori di ogni prospettiva. L indicatore di performance è dato dall integrazione di una parte di misurazione basata sugli strumenti (espressa nel modello tramite la componente RP - Rough Productivity) con una parte basata sulla percezione soggettiva della qualità (espressa nel modello come QF - Quality Factor). Questo concetto è sintetizzabile con la formula Performance = Produttività + Qualità e dimostrabile anche mediante calcoli geometrici. L originalità di QEST, unita al fatto che oggi molte Organizzazioni dimostrano un interesse crescente verso i modelli di misurazione con un numero elevato ed estendibile di prospettive, è stata l occasione per affrontare questo argomento attraverso delle dimostrazioni pratiche che potranno risultare utili a chi in futuro vorrà sperimentare questo metodo. Nonostante tutti questi aspetti positivi, un problema ha fino ad ora caratterizzato QEST impedendogli quello slancio nel mondo della Business Intelligence che sicuramente meritava per la sua novità: l assenza di un ambiente dove poter essere sviluppato in maniera flessibile e dove sfruttarne appieno le sue potenzialità. La soluzione è arrivata grazie a Spago4Q (SpagoBI for Quality), un software open source promosso e supportato da Engineering Ingegneria Informatica S.p.A., il cui scopo è di valutare l adeguata maturità ed efficacia dei processi di sviluppo del software e dei prodotti realizzati. L obiettivo è ottenuto analizzando i dati e le misure raccolte con gli strumenti utilizzati in fase di sviluppo. Il programma si adatta facilmente a differenti contesti organizzativi ed è indipendente dal processo di sviluppo adottato; queste due caratteristiche combaciano perfettamente con la multi-progettualità e la multi-processualità di QEST nd. La visione iniziale di Spago4Q era focalizzata sul processo di sviluppo del software; l implementazione del modello QEST e quindi di un indicatore di performance multi-dimensionale può consentire di estendere le valutazioni di performance e qualità anche a servizi tipici delle attività di Application Manegement erogate da un Azienda come Engineering. L integrazione in Spago4Q del modello QEST permette quindi di coniugare la visione operativa con la visione di business del servizio erogato all utente finale fornendo così un monitoraggio su differenti dimensioni o aspetti maggiormente orientato alla governance. Avendo notato la complementarità delle esigenze delle due entità, è stato pensato di realizzare questa tesi con lo scopo di unire QEST e Spago4Q in un accoppiata eccellente nel calcolo delle performance dei prodotti che possa finalmente dare dei vantaggi sia alle organizzazioni, tramite l utilizzo di un modello potente ed affidabile, sia ai due strumenti coinvolti, accrescendone il singolo livello del valore percepito dagli utenti.

12 3 L attività descritta in questo elaborato è stata realizzata grazie al costante supporto di Engineering Ingegneria Informatica S.p.A. Nel primo capitolo si introducono alcuni concetti di Ingegneria del Software con lo scopo di calare gradualmente il lettore nel cuore del progetto e fornire al tempo stesso le nozioni necessarie alla comprensione di quanto sarà discusso nei capitoli successivi. Nello specifico, vengono descritti il ciclo del miglioramento di un prodotto, il processo di misurazione dei dati chiave per l incremento della qualità ed alcuni modelli per la raccolta dei dati. Per il fine dell elaborato risultano di particolare interesse i modelli di misurazione multidimensionali (tra cui si annovera QEST nd) con una caratteristica particolare: un unico indicatore di performance globale per indicare lo stato di salute dell intero progetto. Il secondo capitolo è dedicato a Spago, un iniziativa di Engineering S.p.A. per la realizzazione di software libero/open source composta da diversi progetti tra cui la piattaforma di Business Intelligence da cui deriva Spago4Q (di cui verranno illustrati l architettura ed il particolare meta-modello). Il terzo capitolo descrive il processo di implementazione di Qest nd, introducendo brevemente alcuni strumenti di supporto necessari ed illustrando poi una ad una le fasi (e le attività che le compongono) necessarie alla realizzazione del modello. Nel quarto ed ultimo capitolo è visibile lo sviluppo di due casi d uso: il primo più semplice e limitato ad un unico rilevamento, il secondo più complesso (per quantità di dati e di settori aziendali coinvolti) ed attuato per misurazioni costanti allo scopo di fornire il quadro dell andamento del progetto nel tempo. Engineering Ingegneria Informatica S.p.A. Costituita a Padova il 6 giugno 1980, Engineering Ingegneria Informatica è oggi uno dei player di riferimento nel panorama nazionale dell Information Technology ed una società a forte vocazione internazionale, per dimensioni raggiunte, posizionamento dell offerta e portafoglio clienti. La società fa capo ai soci fondatori ed è quotata in Borsa a Milano, nel segmento AllStar dedicato ai titoli con i più alti requisiti industriali e patrimoniali. Con un offerta integrata e completa di consulenza, servizi, progetti e prodotti lungo l intera catena del valore del software, Engineering Ingegneria Informatica ha un modello di business articolato per divisioni di mercato: Finanza, Pubblica Amministrazione Centrale, Pubblica Amministrazione Locale e Sanità, Energy & Utility, Formazione. La sua organizzazione è articolata in sette business unit facenti riferimento alla direzione Ricerca & Innovazione e specializzate in: Outsourcing, SAP, Open Source e Business Intelligence, Sicurezza logica e profilazione dei ruoli, ECM (Enterprise Content Management), Automazione e Controllo, Broadband media services. La società, direttamente e indirettamente, ha una capacità produttiva globale in 52 Paesi e una presenza commerciale diretta in Irlanda a Dublino, in Belgio a Bruxelles ed a San Paolo del Brasile.

13 4 Figura 1: Il modello di Business del gruppo Engineering Certificazioni di Qualità Engineering Ingegneria Informatica S.p.A. è stata tra le prime società in Italia ad adottare agli inizi degli anni 90 la certificazione dei processi di produzione a norma ISO Il track storico dei riconoscimenti è il seguente: ISO 9000 (1994) AQAP 2110/160, standard NATO (1996) ISO (2002) SW-CMM level 2 (2005) ISO (2006) CMMI (Capability Maturity Model Integration, version 1.2) level 3 nell ambito dello sviluppo software (2007) Il Portafoglio Clienti Progettare e realizzare architetture informative per clienti di medio-grandi dimensioni è la mission di Engineering Ingegneria Informatica S.p.A. Il portafoglio della capogruppo comprende oltre 800 clienti. Competenze di processo, tecnologiche e di business degli specialisti di settore presidiano le varie fasi di analisi, design e delivery dei progetti:

14 5 Figura 2: La presenza internazionale del gruppo Engineering progettazione e realizzazione degli interventi architetturali metodologie di progettazione ad elevati standard di performance modelli tecnico-architetturali utilizzo di tecnologie innovative grazie al ciclo produttivo dalla Ricerca al mercato e dal mercato nuovamente ai laboratori di ricerca know-how tecnico su prodotti e soluzioni proprietari e di terzi Figura 3: I clienti più importanti su tutti i mercati

15 Capitolo 1 Misurare il Software In questo capitolo verranno introdotti alcuni concetti di Ingegneria del Software con lo scopo di rendere più chiare le fasi di realizzazione dei casi d uso presentati nei capitoli successivi. Nello specifico, la prima parte descriverà il ciclo del miglioramento di un prodotto ed il processo di misurazione dei dati chiave per l incremento della qualità; saranno presentati, anche con esempi, due modelli finalizzati a quest ultimo scopo: il CMMI (Capability Maturity Model Integration) e l ISO La sezione centrale del capitolo sarà dedicata al GQM (Goal Question Metric), un modello per la raccolta dei dati tra i più noti ed utilizzati. La terza ed ultima parte introdurrà i modelli di misurazione multidimensionali aventi una caratteristica particolare: un unico indicatore di performance globale per indicare lo stato di salute dell intero progetto. Nell ordine, sarà discusso il modello QEST, adatto per lavorare su tre dimensioni, LIME, un approccio basato sul precedente per effettuare rilievi al termine di ogni fase del ciclo di sviluppo, e QEST nd, una variante di QEST per lavorare su progetti aventi anche più di tre dimensioni. Sarà proprio attorno a quest ultimo modello che si svilupperà l intero elaborato, con tanto di implementazione a scopo dimostrativo nel capitolo Il Ciclo del Miglioramento Introduzione Il Software Process Improvement (SPI - miglioramento dei processi software) è un aspetto critico per le organizzazioni che sviluppano software. Vi è sufficiente evidenza in letteratura [24] che lo SPI fornisce sostanziali miglioramenti alla qualità, alla produttività ed ai tempi di sviluppo, ma rimane una difficoltà di fondo: la capacità o volontà di impostare un effettivo ciclo di miglioramento che renda evidenti tali vantaggi. Prima di arrivare ad una definizione del ciclo del miglioramento è opportuno precisare cosa si intende per SPI. 6

16 1.1. Il Ciclo del Miglioramento 7 Un qualsiasi processo prevede una sequenza di passi da seguire per svolgere una determinata attività. Un processo di sviluppo software per un organizzazione IT è invece qualcosa di più complesso: è un insieme di processi che prevedono l esecuzione delle diverse attività coinvolte nella realizzazione di un sistema software, includono la conoscenza di cosa è accaduto nello sviluppo di precedenti progetti e contengono le informazioni o le consuetudini che hanno portato al successo e/o che consentono di evitare gli errori connessi alle attività di realizzazione. Tali processi hanno inoltre la caratteristica di evolvere nel tempo in conseguenza dell evoluzione della tecnologia, della conoscenza, degli skill delle persone e, in generale, di altre modifiche di contesto (esigenze del mercato, altri attori coinvolti, ecc.). Sulla base della conoscenza e dell esperienza i processi possono, o meglio, devono essere messi a punto per ottenere migliori performance; questa messa a punto è ciò che costituisce il Software Process Improvement. Bisogna, quindi, istanziare un processo di sviluppo, tenerlo sotto controllo ed associarlo a delle misure che, per risultare efficaci, devono essere raccolte in base agli obiettivi definiti (questo perché il raggiungimento del risultato sarà poi verificato tramite l analisi delle misure stesse). Le organizzazioni che sviluppano un progetto di Software Process Improvement hanno la necessità di eseguire una serie di attività nel seguente ordine (Figura 1.1): Figura 1.1: Ciclo del miglioramento aziendale

17 1.1. Il Ciclo del Miglioramento 8 a livello aziendale, caratterizzazione dell azienda, dei suoi obiettivi e la definizione dei modelli di sviluppo. Si tratta di procedure inserite nella Politica per la Qualità di un azienda che consistono nella definizione degli obiettivi e dei modelli di supporto allo sviluppo che consentano di raccogliere dati per la valutazione del sistema. per ogni singolo processo, poi: - caratterizzazione e definizione di obiettivi misurabili, per individuare le caratteristiche da cui raccogliere dati utilizzabili come feedback; - scelta di un modello per il processo di sviluppo e di metodi, tecniche e strumenti utili per inserirlo nei modelli di sviluppo aziendali; - esecuzione del processo di sviluppo con conseguente realizzazione del prodotto e parallela raccolta dei dati (di processo e di prodotto) per fornire immediati feedback al processo attraverso un analisi in tempo reale; ancora a livello aziendale, durante o al termine dello sviluppo dei progetti: - analisi dei dati raccolti al fine di valutare i modelli utilizzati; - consolidamento della conoscenza tramite immissione dei dati, raffinati con metodi specifici, in un opportuno raccoglitore da utilizzare per la calibratura dei modelli aziendali. I modelli di processo ed i loro risultati non devono mai essere riutilizzabili a scatola chiusa ma vanno adattati ogni volta a diversi fattori tra cui contesto ed obiettivi. Concludendo si può affermare che: la valutazione del processo di produzione è prerequisito per il miglioramento delle organizzazioni e supporto per una loro maggiore competitività; il miglioramento di un azienda software e dei suoi prodotti passa attraverso il miglioramento del suo processo di sviluppo; il processo di sviluppo deve perfezionarsi in maniera incrementale e continua La Scelta di un Approccio: il Framework Based Un progetto di Software Process Improvement può seguire due diversi approcci: SPI interno; il framework based SPI; Con l approccio a SPI interno vengono analizzati esclusivamente i processi realizzati dall organizzazione ed i miglioramenti da apportare vengono decisi in base al divario tra i risultati ottenuti e gli obiettivi fissati. Nell approccio framework based invece, per analizzare i processi aziendali viene utilizzato un framework esterno che funge da guida per individuare le azioni da intraprendere nel programma di miglioramento. I framework più utilizzati, definiti anche come sistemi conformi ad un insieme di regole, sono l ISO ed il Capability Maturity Model (CMM) del SEI (Software Engineering Institute).

18 1.1. Il Ciclo del Miglioramento 9 Il SW-CMM è una metodologia per modellare, definire e misurare la maturità (intesa come capacità di controllare, prevedere, garantire la qualità dei prodotti in uscita) dei processi usati dalle organizzazioni che sviluppano sistemi software (a differenza di ISO 9001 che è un modello specifico per aziende che operano nell ambito IT). Sviluppato ad inizio degli anni 90 (dal SEI della Carnegie Mellon University su richiesta del Dipartimento della Difesa degli Stati Uniti d America) con lo scopo di valutare e certificare le aziende fornitrici di servizi e prodotti software, il CMM presenta una struttura che descrive i punti chiave di un processo (funzionante) di produzione del software secondo 5 livelli di maturità, partendo da un processo immaturo e ad hoc per arrivare ad uno maturo e disciplinato. CMM e ISO sono in alcuni tratti complementari: ISO 9001 definisce uno stadio cui tendere, senza indicare il percorso; CMM definisce anche i passi del percorso di miglioramento. Un approccio framework based è comunque carico di insidie che possono essere superate solo se si considerano attentamente alcuni aspetti: non lavorare per il framework, ma lasciare che il framework lavori per l Azienda - tutti i modelli, compreso il CMM, consentono di operare con sufficiente flessibilità: è riduttivo adottare il modello alla lettera dimenticandosi di considerare quello che è l obiettivo primario. Standard e modelli come il SW-CMM possono aiutare le organizzazioni a migliorare i propri processi software, ma è pericoloso concentrarsi sul raggiungere un livello di maturità, piuttosto che sul migliorare concretamente il processo. I livelli di maturità possono essere una misura del miglioramento, non l obiettivo del miglioramento; una volta che un framework è stato individuato, non criticarlo - è meglio orientare i propri sforzi ad utilizzare al meglio il framework, piuttosto che cercare di modificarlo; La definizione del processo può seguire questi semplici principi: realizzare processi semplici - ogni processo deve dare la possibilità di essere seguito realmente e di verificarne la sua esecuzione in maniera efficace; il processo deve essere definito da chi lo esegue - la standardizzazione di un processo deve raccogliere l esperienza dell organizzazione e deve essere effettuata con il contributo di chi esegue il processo. Tale standardizzazione, inoltre, deve consentire un adeguata messa a punto che sarà tanto più approfondita quanto saranno note le caratteristiche del processo. individuare misure semplici da raccogliere e che diano valore alla gestione del progetto - il processo può migliorare se può essere valutato; le metriche, in genere riguardanti lo sforzo, i difetti, il piano e la dimensione, devono fornire un valore immediato sia perché vi sia un incentivo alla loro raccolta, sia per consentire che un primo miglioramento sia visibile da subito.

19 1.2. Il Processo di Misura La Realizzazione del Modello Il modello scelto viene utilizzato dall organizzazione per ottenere, sfruttandone al massimo le potenzialità, valori utili alla procedura di miglioramento del software. Tale modello deve evidenziare soprattutto i risultati ottenuti in termini di miglioramento delle performance (maggiore qualità associata alla riduzione dei tempi di sviluppo), di minor sforzo (giorni/uomo) di sviluppo e di supporto (gestione della configurazione, assicurazione qualità, ecc). Dopo aver individuato gli obiettivi primari del nuovo modello di sviluppo, da cui discendono i requisiti sopra esposti, è opportuno stabilirne altri di dettaglio che saranno alla base della definizione dei singoli processi produttivi: individuare i requisiti, le feature, i rischi, i necessari trade-off e gestirli nell intero processo di sviluppo; ottimizzare il rapporto con il Committente; valorizzare capacità e conoscenze individuali e dell organizzazione; riutilizzare ed integrare conoscenza, componenti, prodotti; 1.2 Il Processo di Misura Generalità Per realizzare il ciclo di miglioramento dei processi aziendali è necessario prima di tutto avviare un processo di misura. Come illustrato in Figura 1.2, in un processo generico il lavoro può essere svolto in tre fasi: Pianificazione - definizione degli obiettivi di misura, delle procedure organizzative e dei tool di infrastruttura che rendano possibile la raccolta dei dati; Realizzazione - esecuzione del processo, a cui segue: la raccolta dei dati, la storicizzazione in un database aziendale e l analisi dei dati raccolti; Miglioramento - valutazione delle misure associate agli obiettivi e attivazione delle azioni correttive necessarie ai fini del miglioramento del processo analizzato. L Azienda deve inoltre disporre di un organizzazione a supporto delle attività in termini di: definizione di procedure, linee guida e criteri di definizione delle misure; tool e metodi per raccogliere le misure; database di raccolta delle misure, strumenti di analisi;

20 1.2. Il Processo di Misura 11 Figura 1.2: Rappresentazione di un generico processo di misura Il Ciclo PDCA Sono stati sviluppati vari processi di misura ispirati al ciclo appena descritto; tra i più importanti c è il Ciclo di Shewhart/Deming (Figura 1.3). Tale ciclo, denominato PDCA, (dall acronimo delle quattro attività Plan, Do, Check, Act), compie gli stessi step del modello generico ripartendoli però in quattro attività anziché tre: Plan - corrisponde alla fase di pianificazione (definizione degli obiettivi e delle procedure); Do - corrisponde alla fase di realizzazione (raccolta dei dati di misura); Check - corrisponde all ultima parte della fase di realizzazione (analisi dei dati); Act - corrisponde alla fase di miglioramento (valutazione delle misure e del processo); La caratteristica che ha reso importante questo processo di misura è la linearità con quanto richiesto dai framework di qualità ISO e CMMI descritti nei successivi paragrafi.

21 1.2. Il Processo di Misura 12 Figura 1.3: Rappresentazione del Ciclo di Shewhart/Deming Il Modello ISO ISO 9000 identifica una serie di norme e linee guida sviluppate dall ISO, che propongono un sistema di gestione per la qualità, pensato per gestire i processi aziendali affinché siano indirizzati al miglioramento dell efficacia e dell efficienza dell organizzazione oltre che alla soddisfazione del cliente. ISO 9001, in particolare, consiste in un insieme di norme per la definizione dei requisiti dei sistemi qualità; prevede, inoltre, un approccio globale e completo di certificazione per cui non è possibile escludere alcuni settori o processi aziendali, se presenti nell organizzazione. In base alle norme UNI EN ISO , un processo di raccolta dati, misura ed analisi finalizzato al miglioramento delle prestazioni deve comprendere: Requisiti generali; Monitoraggi e misurazioni; Gestione delle non conformità; Analisi dei dati; Miglioramento.

22 1.2. Il Processo di Misura Requisiti Generali L organizzazione deve definire, pianificare ed attuare i processi di misura, di monitoraggio, di analisi e di miglioramento in modo formale, al fine di garantire che il sistema di gestione della qualità, i processi di realizzazione ed i prodotti finali siano conformi ai requisiti dettati da leggi, norme, richieste del cliente e specifiche definite internamente. In particolare occorre: definire le misure da effettuare, con relative modalità di rilevazione; valutare l efficacia delle misure rilevate; identificare ed adottare appropriati metodi e tecniche statistiche. I risultati di questo macro-processo serviranno per il riesame della direzione e per l eventuale pianificazione di azioni correttive o di miglioramento del sistema Monitoraggio e Misurazione La norma suddivide le attività di monitoraggio, misura e controllo tra: soddisfazione del cliente; verifiche ispettive interne; monitoraggio e misurazione dei processi; monitoraggio e misurazione dei prodotti; Gestione delle Non Conformità Oltre alla misurazione ed al monitoraggio delle prestazioni, dei processi e dei prodotti, la norma richiede la valutazione della soddisfazione del cliente e l effettuazione di verifiche ispettive interne per valutare la conformità nel tempo del sistema stesso (Gestione delle non conformità). La customer satisfaction è meglio specificata nella norma UNI EN ISO , che propone alcune metodologie di valutazione quali: reclami dei clienti - di norma è il cliente a manifestare il proprio grado di soddisfazione attraverso rapporti di valutazione del fornitore od in di altre forme. Questionari di customer satisfaction - i questionari richiedono spesso uno sforzo non indifferente per la preparazione e la gestione, per l invio e per l eventuale intervista, per la raccolta dei dati e l analisi. Come se non bastasse può succedere che presentino percentuali di risposta non soddisfacenti. Studi industriali - la soddisfazione del Cliente può essere valutata adottando metodi di misura e di controllo dei processi aziendali al fine di soddisfare i requisiti del cliente e dimostrare l adeguatezza del processo. Questo controllo può, o meglio,

23 1.2. Il Processo di Misura 14 deve essere applicato in particolare al processo di realizzazione del prodotto e/o servizio. Alcuni degli strumenti elencati sono già in uso nelle grandi aziende e nelle piccole-medie imprese italiane distributrici di servizi Analisi dei Dati per il Miglioramento La norma richiede la definizione di una procedura che stabilisca come analizzare i dati raccolti relativamente a: non conformità, indici di misura dei processi, indici di misurazione e monitoraggio dei prodotti, valutazioni della soddisfazione del cliente, ecc. Tali dati devono essere analizzati al fine di valutare: idoneità, efficacia e adeguatezza del sistema di gestione della qualità; andamenti delle operazioni dei processi; grado di soddisfazione del cliente; raggiungimento della conformità ai requisiti del cliente; adeguatezza delle caratteristiche dei prodotti e/o servizi a quanto pianificato Miglioramento Definisce il processo di individuazione ed attuazione di: azioni correttive che sono conseguenza di non conformità effettive; azioni preventive che sono conseguenza di potenziali non conformità Il Modello CMMI Generalità CMMI (Capability Maturity Model Integration) è un modello di riferimento per i processi che possono essere utilizzati per l acquisizione, lo sviluppo e la manutenzione di prodotti software. È l evoluzione del CMM for Software, pubblicato la prima volta nel 1993 dal SEI. Nella versione attuale integra e completa tre precedenti e distinti modelli: Capability Maturity Model for Software (SW-CMM) v2.0 draft C; Systems Engineering Capability Model (SECM); Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98;

24 1.2. Il Processo di Misura 15 CMMI è un insieme di regole ben definite e di best practice utilizzabili per scopi diversi: dall Azienda, per definire una baseline di modalità operative e/o per migliorare l efficienza ed efficacia dei propri processi lavorativi, dal Cliente per valutare la capacità potenziale di un fornitore di rispettare dei requisiti. Alla base del modello ci sono alcuni concetti chiave da illustrare: Process Area - insieme di attività (practice) e/o procedure tra loro correlate, eseguite collettivamente per raggiungere un obiettivo specifico (ad es. la gestione dei requisiti o la gestione della configurazione) chiamato goal. Process Capability - è la capacità di uno specifico processo di assicurare con continuità ed affidabilità il livello di qualità atteso nei prodotti in uscita. Il livello di capability di un processo corrisponde: - al grado di accuratezza con il quale un organizzazione definisce il processo, lo mette in atto, lo controlla e lo misura nella sua efficienza ed efficacia (capacità di produrre software con caratteristiche conformi alle aspettative); - al livello di padronanza che l organizzazione ha sul processo, al livello con cui questa padronanza è diffusa e consolidata e permette di predire con affidabilità il risultato del processo lavorativo; Maturity Level - la maturità di un organizzazione è il livello di capability raggiunto in un insieme predefinito di processi. Nel CMMI, per determinare il livello di maturità complessivo dell organizzazione, non vengono considerati tutti i processi ma solo quelli considerati chiave ai fini di esprimere un giudizio sulla capacità lavorativa dell organizzazione. I livelli di maturità definiti dal CMMI sono 5 (Figura 1.4). Ogni livello rappresenta uno stato di maturità raggiunto, traducibile come la capacità di attuare in modo controllato determinate pratiche. Process Performance - si intende la misura dei risultati effettivamente raggiunti da un determinato processo attuato in uno specifico progetto. Le performance di un organizzazione in uno specifico progetto non sempre rappresentano quelle potenzialmente raggiungibili a livello aziendale (la capability). Un progetto, ad esempio, può avere dei vincoli di contesto che limitano le capacità dell organizzazione (budget, risorse, obiettivi...) La Rappresentazione Scalare Il CMMI offre due possibilità per rappresentare la qualità dei processi: staged e continous (per le differenze tra i due metodi si veda la Figura 1.6). La rappresentazione staged (scalare, Figura 1.4) valuta il livello di maturità complessivo di un organizzazione, calcolato sulla base della capacità di gestire un insieme di processi (le 25 process area del modello). L architettura di questo approccio è visibile in Figura 1.5. I livelli del modello staged sono: Livello 1 (Iniziale) - i processi non sono predefiniti e i risultati non sono prevedibili. Il processo di produzione è instabile e disorganizzato, implicitamente definito di volta

25 1.2. Il Processo di Misura 16 Figura 1.4: La scala di maturità di un organizzazione nel CMMI [24] in volta da chi lo realizza, il flusso delle attività è caotico. Solo l eroismo delle singole persone è in grado di portare al successo i progetti. Livello 2 (Gestito) - rappresenta un processo di produzione caratterizzato da performance ripetibili. Il processo di produzione è preventivamente pianificato, realizzato, monitorato, e controllato rispetto ad obiettivi di business predefiniti. Livello 3 (Definito) - il lavoro è effettuato applicando processi standardizzati dell Azienda. Il processo di produzione è fondato su ben definite metodologie, tecniche e tecnologie, sia per ciò che riguarda gli aspetti gestionali che per ciò che riguarda gli aspetti operativi; esiste un unico modello di riferimento per l organizzazione, la gestione e la realizzazione di progetti; Livello 4 (Gestito quantitativamente) - Il processo viene controllato usando tecniche quantitative e statistiche. Gli obiettivi di business dell organizzazione sono controllati attraverso una loro comprensione in termini statistici; Livello 5 (Ottimizzato) - E istituzionalizzata una politica di gestione della qualità, ovvero l uso di metodi quantitativi, fondati su dati e misure ottenute per feedback dai processi realizzati, per il miglioramento del processo stesso, anche attraverso l introduzione controllata di nuove metodologie, tecniche e tecnologie Le Macro Aree di Applicazione Nella Figura 1.7 è rappresentata la corrispondenza tra le process area CMMI e le quattro grandi categorie in cui si suddividono i processi coinvolti in un progetto SW, indipendentemente dallo specifico ciclo di vita adottato per lo stesso.

26 1.2. Il Processo di Misura 17 Figura 1.5: L architettura del modello CMMI staged [24] I processi hanno come riferimento gli obiettivi e le pratiche definite nel modello CMMI for development v1.2, Maturity Level 3, Staged Measurement and Analysis Process [24] In questo paragrafo viene presentato, a scopo esemplificativo, un processo di analisi e misura secondo l approccio CMMI. E opportuno, prima di entrare nel dettaglio, presentare brevemente il contenuto del paragrafo. Un processo di analisi e misura ha l obiettivo di sviluppare un sistema di misura che supporterà il management durante le fasi di controllo e di messa in atto di azioni per il miglioramento dei processi aziendali. Tale processo comprende, l esecuzione dei seguenti punti chiave: specificare gli obiettivi affinché siano coerenti con le esigenze informative e gli obiettivi dell organizzazione; specificare misure, rilevazione di dati e sistemi di registrazione, tecniche di analisi e sistemi di reporting; implementare la rilevazione, la memorizzazione, l analisi ed il reporting dei dati; fornire risultati oggettivi, che possano essere usati per prendere decisioni informali, ed intraprendere appropriate azioni correttive.

27 1.2. Il Processo di Misura 18 Figura 1.6: Confronto tra rappresentazioni del CMMI [24] Come raffigurato in Figura 1.8, queste attività (rappresentate dagli ovali) possono essere utilizzate per ottenere due obiettivi distinti e molto importanti (le aree tratteggiate): l allineamento tra obiettivi di analisi ed attività di misura e, per secondo, la presentazione dei risultati. Questo processo, tradotto in procedura CMMI, si presenta con la seguente struttura (dove SG sta per Specific Goal, l obiettivo, e SP per Specific Practice, le attività da compiere per raggiungerlo): Specific Goal SG1 Le attività di misura devono essere correlate agli obiettivi di analisi. - Specific practice SP 1.1 Definire gli obiettivi delle misure - Specific practice SP 1.2 Specificare le misure - Specific practice SP 1.3 Specificare le modalità di rilevazione dei dati e le procedure di memorizzazione - Specific practice SP 1.4 Specificare le Procedure di Analisi Specific Goal SG2 Fornire i risultati delle misure - Specific practice SP 2.1 Raccogliere le misure - Specific practice SP 2.2 Analizzare le misure

28 1.2. Il Processo di Misura 19 Figura 1.7: CMMI Process Areas - Specific practice SP 2.3 Memorizzare dati e risultati - Specific practice SP 2.4 Comunicare i risultati.

29 1.2. Il Processo di Misura 20 Figura 1.8: Measurement and Analysis process (fonte CMMI / SEI) Per ogni specific practice sono presenti una o più sub-practice che descrivono l attività in modo ancora più specifico. La descrizione completa della procedura è presentata di seguito: SG 1 - Le attività di misura devono essere correlate agli obiettivi di analisi Gli obiettivi e le attività di misurazione devono essere coerenti con i bisogni informativi e gli obiettivi aziendali identificati. E opportuno definire prima gli obiettivi aziendali di analisi, poi le specifiche di dettaglio delle misure, la rilevazione dei dati e la memorizzazione. SP Definire gli obiettivi delle misure Scopo della practice è stabilire e mantenere gli obiettivi delle misure derivanti dai bisogni informativi e dagli obiettivi dell organizzazione. Gli obiettivi delle misure specificano il tipo di azioni che possono essere intraprese a fronte dei risultati delle analisi dei dati. Sub-practice: 1. Documentare le necessità informative e gli obiettivi (per consentire la tracciabilità delle successive attività di misura e analisi). 2. Stabilire una priorità delle necessità informative e degli obiettivi. 3. Documentare, riesaminare ed aggiornare gli obiettivi delle misure (è importante considerare gli scopi e l uso che si intende fare delle misure e analisi). 4. Fornire feedback per raffinare e chiarire i bisogni informativi e gli obiettivi, secondo

30 1.2. Il Processo di Misura 21 necessità. 5. Mantenere traccia degli obiettivi delle misure. SP Specificare le Misure Scopo della practice è specificare le misure (parametri da misurare) a fronte degli obiettivi di misura. Sub-practice: 1. Identificare le misure candidate sulla base degli obiettivi di misura documentati. Gli obiettivi di misura sono concretizzati in misure specifiche. Le misure candidate vengono categorizzate e specificate, con il nome e l unità di misura. 2. Identificare le misure esistenti che soddisfano già gli obiettivi di misura. Alcune misure possono già esistere, magari stabilite per altri scopi dell organizzazione. 3. Specificare le definizioni operative per le misure. Le definizioni operative devono essere precise e non ambigue. Devono soddisfare due importanti criteri: - comunicazione: cosa è stato misurato e come, qual è l unità di misura, cosa è stato incluso o escluso; - ripetibilità: la misura può essere ripetuta, date le stesse definizioni, e dare gli stessi risultati? 4. Stabilire una priorità, riesaminare ed aggiornare le misure. SP Specificare le modalità di rilevazione dei dati e le procedure di memorizzazione Scopo della practice è specificare come i dati delle misure sono ottenuti e memorizzati. Tipici work product sono: - procedure di rilevazione dei dati e memorizzazione; - strumenti per la rilevazione dei dati. Sub-practice: 1. Identificare le fonti di dati esistenti, generati da work product, processi o transazioni. 2. Identificare le misure per cui sono necessari i dati non ancora disponibili. 3. Specificare le modalità di rilevazione e memorizzazione dei dati per ogni misura richiesta (come, dove e quando i dati devono essere rilevati e memorizzati). 4. Creare i sistemi di rilevazione dei dati e le procedure guida. 5. Disporre in modo appropriato dei supporti per la rilevazione automatica dei dati (esempi di supporti automatici: log di attività, analisi statiche o dinamiche di manufatti). Tuttavia alcuni dati non possono essere rilevati senza l intervento umano (ad esempio la soddisfazione del cliente), e l allestimento di infrastrutture per la loro rilevazione automatica potrebbe essere troppo costoso.

31 1.2. Il Processo di Misura Stabilire la priorità, riesaminare e aggiornare le procedure di rilevazione dei dati e di memorizzazione. 7. Aggiornare le misure e gli obiettivi di misura secondo necessità. SP Specificare le Procedure di Analisi Scopo della practice è specificare e documentare le modalità di analisi e di reporting delle misure. La definizione anticipata delle procedure di analisi assicura che vengano fatte e documentate appropriate analisi che soddisfino gli obiettivi di misura stabiliti (e quindi i bisogni informativi). Questo approccio (di definire le procedure di analisi) è anche un modo per testare che i dati necessari verranno effettivamente rilevati. Work Product tipici: - Specifiche di analisi dei dati e procedure; - Strumenti per l analisi dei dati. Sub-practice: 1. Specificare (eventualmente assegnando delle priorità) le analisi che verranno condotte sui dati e i report da allestire. 2. Scegliere appropriati strumenti e metodi di analisi dei dati. 3. Specificare le procedure amministrative per analizzare i dati e comunicare i risultati. Argomenti da considerare: - identificare persone e gruppi responsabili dell analisi dei dati e della presentazione dei risultati; - determinare il tempo limite per l analisi dei dati e la presentazione dei risultati; - definire modalità e luogo di presentazione dei risultati (report di avanzamento, trasmissione di memo, documenti scritti, riunioni di staff). 4. Riesaminare e aggiornare contenuti e formato delle analisi specificate e dei report. 5. Aggiornare le misure e gli obiettivi di misura secondo necessità. 6. Specificare i criteri per valutare l utilità dei risultati. SG2 - Fornire i risultati delle misure I risultati delle misure vengono presentati. L obiettivo principale è soddisfare i bisogni informativi e gli obiettivi stabiliti. I risultati delle misure basati su evidenze oggettive possono aiutare nel monitoraggio delle performance, nel rispetto degli obblighi contrattuali, nel prendere decisioni di management, e nel rendere possibile l adozione di azioni correttive. SP Raccogliere le misure La practice ha lo scopo di specificare i dati delle misure da rilevare. I dati necessari per l analisi vengono rilevati e testati in termini di integrità e completezza. Work Product tipici: - Specifiche di analisi dei dati e procedure. - Strumenti per l analisi dei dati.

32 1.2. Il Processo di Misura 23 Sub-practice: 1. Specificare i dati di base (misure di base); 2. Generare i dati per le misure derivate (vengono calcolati i valori per le misure derivate); 3. Eseguire un test sull integrità dei dati. Tutte le misure sono soggette a errori nella registrazione dei dati. E meglio identificare al più presto tali errori e le rispettive cause. SP Analizzare le misure Scopo della practice è l analisi e l interpretazione dei dati rilevati. I dati raccolti vengono analizzati come pianificato, eseguendo analisi aggiuntive se necessario. I risultati sono esaminati con i relativi interessati e si prende nota di eventuali revisioni necessarie per le analisi successive. Work Product tipici: - Risultati delle analisi e report. Sub-practice: 1. Eseguire un analisi preliminare, interpretare i risultati e preparare le conclusioni. I risultati delle analisi sui dati raramente sono auto-evidenti. Occorre stabilire esplicitamente i criteri di interpretazione dei risultati per trarre le conclusioni. 2. Eseguire eventuali analisi aggiuntive secondo necessità e preparare i risultati per la presentazione. I risultati delle analisi pianificate possono richiederne alcune aggiuntive non previste. Può essere necessario raffinare le misure, per calcolare ulteriori misure derivate, oppure raccogliere dati aggiuntivi per completare l analisi pianificata inizialmente. Anche durante la preparazione dei risultati da presentare può essere necessario svolgere analisi aggiuntive non previste. 3. Riesaminare i risultati con le persone interessate. Può essere opportuno rivedere l interpretazione iniziale dei risultati ed il modo in cui vengono presentati, prima di diffonderli ulteriormente. Il riesame dei risultati iniziali prima del loro rilascio può evitare incomprensioni e suggerire miglioramenti nell analisi e nella presentazione dei dati. Le persone interessate con cui condurre i riesami comprendono gli utenti finali e gli sponsor, ma anche gli analisti e coloro che hanno fornito i dati. 4. Rivedere e raffinare i criteri per le analisi successive. L attività di analisi dei dati e di preparazione dei risultati può fornire utili lezioni per migliorare nel futuro. Possono emergere nuovi metodi, per migliorare le specifiche delle misure e le procedure di rilevazione dei dati, e nuove idee per raffinare i bisogni informativi e gli obiettivi. SP Memorizzare i dati e i risultati Scopo della practice è la conservazione delle misure e delle informazioni. Le informazioni (collegate ai dati) sono necessarie per fornire un contesto adeguato all interpretazione dei dati, dei criteri di misura e dei risultati delle analisi.

33 1.2. Il Processo di Misura 24 Le informazioni memorizzate riguardano di solito: piani di misurazione, specifiche delle misure, set di dati rilevati, report di analisi e presentazioni; inoltre, verificano la ragionevolezza e l applicabilità delle misure (ad esempio mettendo a confronto specifiche di misura usate su progetti diversi). I dati relativi alle misure derivate possono essere ricalcolati in qualsiasi momento, quindi non sarebbe necessario memorizzarli. Comunque, può essere opportuno creare dei sommari basati sulle misure derivate (diagrammi, tabelle, testi). I risultati delle analisi intermedie non hanno bisogno di essere memorizzati separatamente se si può facilmente risalire ad essi. I dati e i risultati specifici di progetto possono essere immagazzinati in un proprio repository. Quando i dati vengono condivisi a livello più ampio, gli stessi dati possono risiedere su un repository aziendale. Sub-practice: 1. Riesaminare i dati per assicurare la loro completezza, integrità, accuratezza e attualità. 2. Rendere i dati disponibili solo alle persone appropriate. 3. Prevenire l uso inadeguato delle informazioni memorizzate (mediante controlli sull accesso ai dati e formazione sul loro uso). SP Comunicare i risultati Scopo della practice è la comunicazione a tutti gli interessati dei risultati delle misure e delle analisi. I risultati del processo di misura e analisi sono comunicati in tempo utile in modo da supportare l adozione di azioni correttive ove necessario. Work Product tipici: - Report dei dati e risultati delle analisi. - Informazioni di contesto e guida alla interpretazione dei risultati delle analisi. Sub-practice: 1. Informare periodicamente gli interessati sulle misure e risultati delle analisi. I risultati delle misure devono essere comunicati in tempo utile al loro adeguato utilizzo. 2. Dare supporto agli interessati per la comprensione dei risultati Il Modello Goal Question Metric Come spiegato in precedenza, la misurazione, per essere efficace, deve essere focalizzata su obiettivi specifici (goal) ed applicata a tutti i prodotti, ai processi ed alle risorse del ciclo di vita. Si può quindi affermare che l attività segue un approccio top-down; il modello GQM (Goal Question Metric) ne è la conferma.

34 1.2. Il Processo di Misura Caratteristiche Il Goal Question Metric è un meccanismo per la definizione e l interpretazione di software funzionante e quindi misurabile. Può essere usato da solo, o ancora meglio, come parte integrante in un contesto più generale di miglioramento della qualità del software. In quest ultimo caso lo sviluppo del modello potrà contare sull esperienza aziendale che disporrà, come input, sia degli obiettivi di business forniti dal management sia delle caratteristiche di contesto fornite dal team di progetto (Figura 1.9). L approccio si basa sull assunzione che un Azienda, per misurare il software, deve dap- Figura 1.9: I ruoli ed i flussi in gioco nella realizzazione di un GQM [1] prima specificare gli obiettivi da raggiungere, sia a livello aziendale che di progetto, poi associarli ai dati stabiliti per la misurazione, infine sviluppare un framework per l interpretazione dei valori relativi a ciascun obiettivo. Il risultato sarà un sistema composto da un set ben preciso di punti misurabili ed un insieme di regole per l interpretazione dei dati ottenuti. Il modello si sviluppa su 3 livelli: 1. Livello concettuale (GOAL): viene definito un goal per ogni oggetto. Sono oggetti misurabili: Prodotti: prodotti, servizi e documenti redatti durante il ciclo di vita del sistema (ad esempio: specifiche, modelli, programmi, test); Processi: attività relative al software e normalmente associate al tempo (ad esempio: fase di progettazione, fase di testing, fase delle interviste, raccolta dei pareri); Risorse: oggetti usati dai processi per produrre i loro output (ad esempio: personale, hardware, software).

35 1.2. Il Processo di Misura Livello operativo (QUESTION): viene creato un set di domande da usare per la valutazione di un goal. Attraverso le question, l oggetto da misurare avrà dei punti per il rilevamento della qualità ben precisi che lo caratterizzeranno rispetto ad altri. 3. Livello quantitativo (METRIC): un set di dati è associato ad ogni question per rispondere in modo quantitativo con dei risultati. I dati possono essere: Oggettivi: se dipendono solo dall oggetto da misurare e non dal contesto da cui sono presi o dal punto di vista di attori esterni (sono dati oggettivi, ad esempio: il numero di versioni di un documento, le ore spese su un processo, la dimensione di un programma); Soggettivi: se dipendono anche dal contesto da cui sono presi o dal punto di vista di attori esterni (sono dati soggettivi, ad esempio: la leggibilità di un testo od il livello di soddisfazione degli utenti). I livelli sono disposti secondo una struttura gerarchica (Figura 1.10) della quale i goal ne sono al vertice. A ciascun goal sono associate delle question che hanno lo scopo di scomporre l obiettivo nelle sue maggiori componenti da misurare. Sotto ogni question si trovano infine le metric, che sono alla base del modello. Una metrica può essere usata per rispondere a più domande all interno dello stesso goal. Alcuni modelli GQM possono avere metriche e question in comune; bisogna perciò fare attenzione che le misure, una volta ottenute, vengano posizionate nel rispettivo contesto di origine. E molto probabile, infatti, che la stessa metrica assuma valori diversi per ogni progetto ed un associazione misura-modello sbagliata genererà quasi certamente un errore. Figura 1.10: Struttura gerarchica del modello GQM [1] Elaborazione del GQM: un Esempio E possibile comprendere meglio il funzionamento del GQM con un esempio. In questo caso d uso l Azienda intende migliorare la reattività del processo di gestione dei cambiamenti durante la fase di manutenzione di un progetto. Questo sarà il goal a cui verranno associate le question. Le domande possono essere poste a livello aziendale, divisionale o di progetto. In ognuno di questi casi è indispensabile che si definisca il goal nel modo più completo possibile e

36 1.2. Il Processo di Misura 27 che le question siano compatibili con quanto si intende veramente misurare. Lo step successivo consiste nello specificare le misure da acquisire per rispondere alle domande e per tracciare la conformità dei prodotti e dei processi al goal. Infine, bisogna definire il meccanismo di raccolta dati, validazione ed analisi. Il processo di definizione degli obiettivi è la fase più critica perché determinerà il successo dell intero modello. Per questo è supportato da specifiche operazioni metodologiche. Un goal ha tre coordinate ed uno scopo, come illustrato in Figura 1.11 ed elencate di seguito: 1. Oggetto (processo) Gestione dei cambiamenti durante la fase di manutenzione 2. Issue Puntualità 3. Punto di vista Project Manager 4. Scopo Miglioramento Figura 1.11: Rappresentazione grafica delle coordinate e dello scopo di un goal [1] Lo sviluppo di un goal è basato su tre basilari sorgenti di informazione. La prima coordinata è la politica e la strategia dell organizzazione che adotta il modello GQM. Analizzando la politica aziendale, i piani strategici ed intervistando i soggetti aventi un ruolo rilevante nell organizzazione, si ricavano sia l issue (il problema) che lo scopo del goal. La seconda sorgente di informazione è la descrizione del processo è dei prodotti dell Azienda, od almeno, di quelli che interessa misurare. Queste informazioni sono recuperabili soprattutto dai modelli descrittivi formali. Se ad esempio si vuole valutare un processo, servirà un modello di questo processo e dei sotto-processi che lo compongono. Da questa fonte si ricava l oggetto del goal. La terza ed ultima sorgente è il modello di organizzazione, che fornisce la coordinata relativa al punto di osservazione del goal. Dato che non tutti i processi e le operazioni hanno la stessa importanza per ogni prospettiva dell Azienda, l analisi per la definizione degli obiettivi deve essere molto accurata per assicurarsi che i goal stabiliti siano quelli

37 1.2. Il Processo di Misura 28 veramente rilevanti ai fini della misurazione. In questo modo, si arriva all individuazione degli obiettivi. Dalle specifiche di ogni goal derivano le domande che rendono quell obiettivo quantificabile. In generale, le question vengono raggruppate in gruppi tematici; nell esempio ne sono stati definiti tre: Gruppo 1. Come si può caratterizzare l oggetto rispetto all obiettivo complessivo del modello GQM? Domande 1. Qual è la velocità attuale dell elaborazione della richiesta di cambio? 2. Il processo è attualmente in funzione? Gruppo 2. Come si possono caratterizzare gli attributi dell oggetto che sono rilevanti per il risultato del GQM? Domande 1. Qual è la deviazione della performance attuale rispetto a quella stimata? 2. La performance del processo è migliorata? Gruppo 3. Come si possono valutare le caratteristiche dell obiettivo rilevanti per il risultato del modello GQM? Domande 1. La performance attuale è soddisfacente secondo il punto di vista dei project manager? 2. La performance è visibilmente migliorata? Le domande vengono poi associate alle metriche appropriate. Per lo svolgimento di questa operazione ci sono molteplici fattori da considerare: la quantità e qualità dei dati esistenti: è importante massimizzare l uso delle sorgenti dati se queste sono disponibili ed affidabili; la maturità degli oggetti da misurare; verranno applicate misure obiettive agli oggetti più maturi e misure più soggettive agli oggetti più informali ed instabili; apprendimento del processo: i modelli GQM hanno sempre bisogno di essere migliorati e riadattati e le misure che definiamo possono aiutare anche per questo compito oltre alla misurazione degli oggetti. Terminato anche questo passo, il GQM raggiunge la sua struttura definitiva (Figura 1.12) ed è pronto ad operare, previa decisione su tecniche, tool e procedure da utilizzare per

38 1.3. I Modelli Multidimensionali: la Famiglia QEST 29 Figura 1.12: Il quadro completo del GQM di esempio [1] l immagazzinamento dei dati. 1.3 I Modelli Multidimensionali: la Famiglia QEST L Importanza di un Valore di Performance Unico Con questa breve premessa, si è voluto mettere l accento su un aspetto finora non incontrato in altri approcci e che, ben presto, è divenuto il vero punto di forza di QEST e di tutti quei modelli basati su di esso: l indicatore di performance globale. Questa misura aggiuntiva semplifica notevolmente le cose: fornisce un impatto immediato sull andamento complessivo di un progetto, sia visivo che concettuale, consentendo un ottimale comprensione ed un idea istantanea della

39 1.3. I Modelli Multidimensionali: la Famiglia QEST 30 situazione; permette un analisi di tipo top-down, partendo dall indicatore unico, nel quale convergono tutte le misure, fino ad arrivare alla valutazione delle singole misure di base dopo aver esaminato i valori di ogni prospettiva Il Modello QEST Introduzione QEST (Quality factor + dimensione Economica, Sociale e Tecnica) è un modello multidimensionale per la misurazione delle performance dei progetti software, concepito usando dei concetti geometrici. La struttura a più dimensioni consente alle organizzazioni di scegliere le componenti di ciascuna prospettiva in base ai loro bisogni, rendendo QEST un modello aperto. L obiettivo principale è esprimere la performance (p) come una combinazione delle misure selezionate per ognuna delle tre dimensioni. Il valore di ciascuna dimensione sarà poi dato dalla somma pesata delle misure normalizzate sottostanti. L indicatore di performance è dato dall integrazione di una parte di misurazione basata sugli strumenti (espressa nel modello tramite la componente RP - Rough Productivity) con una parte basata sulla percezione soggettiva della qualità (espressa nel modello come QF - Quality Factor). Questo concetto è sintetizzabile con la seguente formula: Performance = Produttività + Qualità. La qualità può essere definita come le caratteristiche di un prodotto o servizio che incidono sulla sua capacità di soddisfare i bisogni di un utente. In questo contesto la qualità è vista anche come: il punto di vista dell utente, secondo il quale è data da tutto ciò che è necessario per soddisfare correttamente ed efficientemente i reali bisogni di chi compra e usa il software; il punto di vista dello sviluppatore, per il quale la qualità deriva dalla conformità del funzionamento e dai requisiti di performance definiti esplicitamente; il punto di vista del management, che sono interessati alla qualità generale. Dal punto di vista geometrico, QEST può essere rappresentato da un tetraedro regolare tridimensionale come illustrato in Figura Nel dettaglio, le tre dimensioni (E, S, T) corrispondono agli angoli della base della piramide e la convergenza con il vertice P descrive il livello di performance. Quando i tre lati sono della stessa lunghezza il solido assume la forma di una piramide regolare. La lunghezza dei lati dipende dal peso che si attribuisce ad ogni dimensione; peso che dovrà essere uguale per tutte le dimensioni affinché si ottenga una piramide regolare. La misura di una prospettiva è espressa per mezzo di un valore normalizzato compreso tra 0 ed 1; la stessa cosa vale per l indicatore unico.

40 1.3. I Modelli Multidimensionali: la Famiglia QEST 31 Figura 1.13: Rappresentazione geometrica di QEST con le dimensioni E, S, T come base degli assi e la performance P come vertice [3] Grazie a questa rappresentazione è possibile esprimere la performance per mezzo di concetti geometrici quali distanza, area e volume, oltre che ad avere un quadro istantaneo della qualità del progetto. Il Quality factor (QF) è esprimibile come la distanza tra il piano (Qe, Qs, Qt) descritto dagli angoli e la sua traslazione (Qe, Qs, Qt ). RP invece corrisponde alla distanza tra un angolo e la sua rispettiva Q (ad esempio, per la dimensione economica RP è uguale alla distanza tra il punto E ed il punto Qe). La Figura 1.14 aiuta a capire i concetti appena descritti. Il rapporto tra il volume della parte più bassa del tetraedro troncato ed il volume totale del solido rappresenta il livello di performance normalizzato. Il vertice del solido rappresenta, da un punto di vista concettuale, la convergenza delle valutazioni delle diverse dimensioni in un unico valore finale. Un ultimo aspetto geometrico interessante da vedere è come la performance complessiva può essere rappresentata e determinata in tre modi distinti: considerando la distanza tra il centro di gravità della base del tetraedro ed il centro della sezione piana: più la distanza è lontana da 0, più è elevata la performance (Figura 1.15). considerando l area del piano traslato (Qe, Qs, Qt ) : più è piccola l area della sezione, maggiore è il livello di performance (Figura 1.16); considerando il volume della parte inferiore del tetraedro troncato: maggiore è il volume, maggiore sarà il livello di performance (Figura 1.17). E importante sottolineare che QEST, nonostante possa sembrare un modello fuori dalle righe, adotta gli standard (de jure e de facto) di raccolta delle varie misure:

41 1.3. I Modelli Multidimensionali: la Famiglia QEST 32 Figura 1.14: I piani (Qe, Qs, Qt) e (Qe, Qs, Qt ) da cui è possibile esprimere QF e RP [3] Figura 1.15: Performance dal punto di vista della distanza HH [3] ISO/IEC 9126 per la raccolta di dati relativi alla qualità del prodotto software, utile in QEST per il QF e la dimensione sociale; Function Point Analysis (FPA), utilizzabile per la dimensione economica e tecnica. Tornando alla parte pratica, per calcolare la performance globale basta sommare il QF al valore di ogni dimensione (ottenuto dalla somma pesata dei valori normalizzati delle misure) ed applicare la formula generale: n+1 P = 1 (1 p i ) i i=1

42 1.3. I Modelli Multidimensionali: la Famiglia QEST 33 Figura 1.16: Performance dal punto di vista dell area (Qe, Qs, Qt ) [3] Figura 1.17: Performance dal punto di vista del volume (la sezione bianca del solido) [3] dove p i è il valore di ogni dimensione (comprensiva del QF) ed i il numero delle dimensioni Implementazione dei Requisiti La procedura di implementazione del modello QEST segue il ciclo PMAI (Plan-Measure- Assess-Improve, Figura 1.18), conforme al ciclo PDCA discusso nel Paragrafo Le quattro fasi, composte a loro volta da dodici passi, sono di seguito descritte:

43 1.3. I Modelli Multidimensionali: la Famiglia QEST 34 Figura 1.18: Il ciclo PMAI usato da QEST [4] PLAN 1. Determinazione delle linee guida di misurazione Vengono scelti gli standard de jure e de facto per la costruzione dei ratio (per ratio si intende una metrica, ossia una misura indiretta), quali ISO/IEC 9126 (utilizzata per la dimensione Sociale e per il calcolo del QF), Function Point Analysis (utilizzati per le dimensioni Economica e Tecnica), PSM (manuale di riferimento per la misurazione delle performance nell organizzazione). 2. Selezione delle misure rilevanti per ciascuna dimensione Si crea una lista di ratio usando un modello derivante dal GQM e denominato GQM(R) (Goal-Question-Measure-Ratio, Figura 1.19). Si specificano, per ogni dimensione aziendale, gli obiettivi, le domande connesse e Figura 1.19: Il modello Goal Question Measure Ratio [4] le misure più adatte. I ratio si ottengono partendo da un elenco di tutte le misure di progetto; alcune persone scelte per rappresentare le tre dimensioni selezionano quelle ritenute più rilevanti e le assegnano alle dimensioni. Infine si determinano

44 1.3. I Modelli Multidimensionali: la Famiglia QEST 35 i valori di minimo e massimo (utili per la fase di normalizzazione) che ogni ratio potrebbe raggiungere e si associa ad una process area. 3. Determinazione del bilanciamento tra valori di progetto quantitativi e qualitativi Alla qualità viene attribuito un valore atteso pari alla metà del valore qualitativo massimo raggiungibile. Questo punto di soglia viene definito Mean Quality Level (MQL). 4. Determinazione dei pesi dei ratio per ogni dimensione Il peso sarà un valore compreso tra 0 e Determinazione dei valori di soglia accettabili I valori di soglia sono utili per segnalare immediatamente se una dimensione sia soddisfacente o meno. Una generica soglia di accettabilità è un valore compreso tra 0 ed 1. MEASURE 6. Raccolta dei dati I dati raccolti sono inseriti in appositi moduli. 7. Applicazione delle regole di assegnamento dei valori I valori raccolti devono essere utilizzati per comporre i ratio e calcolare in seguito i valori di E, S, T. 8. Normalizzazione dei ratio La normalizzazione è il processo di conversione dei dati di partenza in una differente unità di misura per permetterne la comparazione o la combinazione con altri dati. Questo procedimento è necessario per motivi geometrici: QEST deve presentare tutti i lati di lunghezza unitaria per rendere i valori comprensibili e di facile lettura. Per normalizzare un ratio R è richiesto un valore minimo (R min ) ed uno massimo (R max ) da inserire nella formula: 0 r = R R min R max R min 1 9. Calcolo del QF, delle dimensioni e della Performance globale Conoscendo il valore del QF è possibile calcolare le coordinate dei punti (Qe, Qs, Qt ) ed il volume della piramide delimitata dai punti [P, Qe, Qs, Qt ] per determinare il valore di performance. ASSESS 10. Presentazione dei risultati della misurazione Per essere presentati, i dati vengono immessi negli opportuni moduli documentali. 11. Analisi dei valori osservati L analisi può essere di due tipi: sintetica ed analitica. Per la prima bisogna usufruire della matrice di posizionamento aziendale (Figura 1.20), dove sull asse delle ascisse è rappresentato il valore di performance del

45 1.3. I Modelli Multidimensionali: la Famiglia QEST 36 progetto e sull asse delle ordinate il tempo. Il quadrante numero 4 rappresenta la situazione migliore. E possibile fare un analisi sul singolo progetto o sul portafoglio Figura 1.20: La matrice di posizionamento aziendale dei progetti. Nel primo caso si ottiene il trend di un progetto mediante l acquisizione dei valori di performance rilevati in un dato arco di tempo. Nel secondo, invece, è possibile osservare la situazione complessiva dell intero portafoglio e, sovrapponendo idealmente le matrici ottenute in un periodo, si identifica il tipo di strategia che l organizzazione ha adottato per raggiungere il quarto quadrante. L analisi analitica considera semplicemente il riassunto dell analisi quantitativa; si focalizza sulla differenza tra valori osservati ed attesi con lo scopo di individuare le sottocaratteristiche che non hanno avuto successo e vedere in quale dei tre gruppi di interesse sono allocate. IMPROVE 12. Processo di miglioramento Per ogni ratio con valore negativo si mira ad ottenere un miglioramento; le aree di processo precedentemente selezionate dal framework di SPI preferito (CMM, SPICE,...) o le linee guida aziendali forniscono il supporto necessario per questa attività. In questo modo si avrà una riduzione dei costi dando attenzione solo alle aree di processo utilizzate o identificate come critiche Il Modello LIME In un mercato così competitivo come quello corrente, dove la capacità di una compagnia di reagire all istante alle richieste dei consumatori e di minimizzare i costi dei servizi offerti è una condizione necessaria per la sopravvivenza, monitorare i livelli di performance durante tutte le fasi del ciclo di vita del software diventa una componente chiave per il

46 1.3. I Modelli Multidimensionali: la Famiglia QEST 37 miglioramento della progettazione e del rilascio dei servizi. I costi per l individuazione e la correzione dei difetti nelle fasi finali sono molto più elevati che nelle fasi iniziali; per questo motivo i problemi dovrebbero essere rimossi il prima possibile, preferibilmente prima della fase di test, anche per migliorare la qualità. I modelli multidimensionali dinamici per la qualità possono fornire un importante contributo mediante l analisi costante del ciclo di vita del progetto. Il modello LIME (LIfecycle MEasurement) è stato sviluppato per maneggiare simultaneamente le tre dimensioni e per analizzare i risultati delle misurazioni di fase in fase durante lo sviluppo del software. Questo funzionamento è reso possibile estendendo il modello QEST in un contesto dinamico come quello di un ciclo di vita e facendone uso in ogni step. A scopo illustrativo, e solamente in questo esempio, si può prendere in considerazione un modello LIME avente la struttura di un generico ciclo di vita a cascata a sei fasi (noto come waterfall, Figura 1.21) e la notazione ETVX (Entry-Task-Validation-eXit). In pratica, l output della (n-1) fase è l input della n fase e l output di questa sarà l input della (n+1) fase (Figura 1.22). I risultati delle misurazioni (I1,..., I6, O1,..., O6) possono essere aggiunti nel modello QEST dopo essere stati normalizzati per i motivi di cui sopra. La definizione, la raccolta e l analisi delle misure multidimensionali in ogni fase del ciclo Figura 1.21: Il modello LIME applicato ad un ciclo waterfall [5] Figura 1.22: Input ed output secondo l approccio ETVX [5] di vita offre, dunque, il feedback necessario per fare aggiustamenti ai processi del progetto; questo è utile sia per migliorare la fase corrente sia per i processi futuri. Ogni stadio si affida al ciclo PMAI per la realizzazione e sul modello QEST per la valutazione. L utilizzo del PMAI nel modello LIME (Figura 1.23) comporta un piccolo aggiustamento rispetto all originale: lo step 1 rappresenta un passaggio preliminare da eseguire soltanto una volta all inizio del processo di misurazione e non ogni volta che si passa ad una nuova fase. Riassumendo, gli aspetti principali aggiunti nel modello LIME sono:

47 1.3. I Modelli Multidimensionali: la Famiglia QEST 38 Figura 1.23: Il modello LIME ed il ciclo PMAI [5] La flessibilità ottenuta dal contributo distinto delle tre dimensioni (E, S, T) in ogni fase: ad esempio, gli utenti non sono presenti nella fase di implementazione così come i manager non sono coinvolti in quella di test; i tecnici invece sono presenti in entrambe le fasi. Il relativo contributo dei tre gruppi in ogni fase deve essere determinato quantitativamente usando i criteri appropriati (basandosi sui dati storici di precedenti progetti e su quelli del progetto corrente). La flessibilità ottenuta dal contributo delle valutazioni in ogni fase, grazie alla distribuzione delle valutazioni soggettive e di quelle basate sui rilevamenti lungo l intero ciclo di vita. La flessibilità nella scelta di misure e ratio in ogni fase: il trattamento di ogni singola fase del ciclo di vita rende possibile selezionare, per ogni dimensione dell organizzazione, le misure ed i ratio necessari per ogni passo. Per minimizzare la manipolazione dei dati in ogni fase, è possibile ricorrere al supporto di prodotti software per semplificare le procedure di raccolta dati ed automatizzare la rappresentazione dei dati multidimensionali Il Modello QEST nd Perché n-dimensioni I modelli descritti nei precedenti paragrafi tengono in considerazione tre prospettive. Questo è già un buon livello se si considera che molti approcci presenti nel mondo dell Ingegneria del Software sono troppo semplificati per rappresentare la natura di una misurazione multidimensionale; addirittura, alcuni di essi prevedono un approccio basato su un unica dimensione. Esistono tuttavia dei framework di performance management, come il Balanced Scorecard, l Intangible Asset Monitor e lo Skandia Navigator, che prevedono l utilizzo di un numero di dimensioni maggiore delle tre concesse da QEST. Molte organizzazioni, inoltre, stanno dimostrando un interesse sempre più forte verso i modelli di misurazione che prendono in considerazione un numero più grande di prospet-

48 1.3. I Modelli Multidimensionali: la Famiglia QEST 39 tive. Tenendo sotto osservazione più punti di vista, si eleva la qualità della raccolta dei dati e si evita la perdita di controllo sull analisi per mancanza di dati. Inoltre, si riesce a rappresentare la realtà più approfonditamente potendo includere numerosi aspetti. Questa situazione ha reso necessario lo studio di una soluzione per mantenere QEST al passo col tempo: il risultato è QEST nd, un estensione che trasforma l originale modello (a tre dimensioni) in uno ad n dimensioni (dove per n si intende il numero di dimensioni, ad esempio quattro, cinque, ecc.) La Rappresentazione Geometrica Questo approccio apre a nuove possibilità di utilizzo anche se con un piccolo prezzo da pagare: l impossibilità di usufruire ancora di una rappresentazione visuale per misurazioni con più di tre dimensioni. Non è infatti sufficiente estendere, rispetto a QEST, il numero dei lati della base della piramide (base quadrata per quattro dimensioni, base pentagonale per cinque dimensioni, e così via) in quanto è geometricamente scorretto. Non è invece inesatta, ma povera di informazioni e quindi sconsigliata, una rappresentazione per mezzo di tecniche già note, come i diagrammi di Kiviat. Questi grafi sono composti da un certo numero di semiassi aventi origine in un punto chiamato polo. Dopo aver effettuato la misurazione della performance vengono individuati, seguendo determinati criteri, dei punti lungo i semiassi che poi saranno uniti tra loro per formare un poligono (Figura 1.24). Grazie all esistenza di tecniche per assegnare valori numerici al pattern, sfruttando i Figura 1.24: Un esempio di diagramma di Kiviat [8] concetti di area e distanza, è stato ipotizzato un uso dei diagrammi per la parte visuale di

49 1.3. I Modelli Multidimensionali: la Famiglia QEST 40 QEST nd. L idea era quella di sovrapporre, al termine di ogni fase, il poligono ottenuto a quello precedente e calcolare il rapporto tra le due aree per verificarne i miglioramenti. Questo metodo fornisce un ottima informazione visuale ad impatto ma ha un difetto notevole: la sua rappresentazione a sole due dimensioni è molto limitante per un processo che prevede un elaborazione di dati provenienti da molte prospettive. La soluzione definitiva si chiama simplex, una sorta di triangolo n-dimensionale ottenuto grazie alla geometria computazionale (Figura 1.25). In questo modo i concetti geometrici Figura 1.25: Grafi di simplex da 2 a 7 dimensioni [9] di distanza, area e volume vengono preservati; tuttavia è dimostrato che l approccio basato sul volume è quello decisamente più valido dei tre. Ottenuti n punti (i valori pesati provenienti dalle n dimensioni) è possibile calcolare le misure della parte superiore e inferiore del simplex; il loro rapporto rappresenterà il valore della performance del progetto. Come nel precedente modello a tre dimensioni non mancano le eccezioni: se almeno un punto ha valore uguale ad 1, l iperpiano assume una forma tale per cui non è più possibile determinare le misure delle due parti del simplex. La formula generica per il calcolo del valore unico di performance è la stessa del modello QEST essendone stata dimostrata la validità per qualsiasi numero di dimensioni: n+1 P = 1 (1 p i ) i i=1 dove p i è il valore di ogni dimensione (comprensiva del QF) ed i il numero delle dimensioni. QEST nd è il modello scelto per implementare il caso d uso oggetto della Tesi presentato nel Capitolo 3.

50 Capitolo 2 SpagoWorld Questo capitolo è dedicato a Spago World, un iniziativa di software libero/open/source promossa da Engineering S.p.A. Dopo una breve presentazione generale, saranno descritti dettagliatamente i progetti che insieme costituiscono l ambiente e cooperano in esso. Nella prima parte del capitolo si parlerà di Spago e della sua architettura MVC (Model View Controller). Si passerà poi alla presentazione di SpagoBI, descrivendone le funzionalità ed i moduli che lo compongono. In questa sezione sarà dato ampio spazio al modulo SpagoBI Server ed in particolare alle tecnologie ed alla sua architettura multilivello. Alla piattaforma Spago4Q è dedicata la terza ed ultima parte. Come in precedenza, anche qui verrà illustrata l architettura (modulare); il vero punto forte, però, sarà l approfondimento sul meta-modello alla base di questa piattaforma. Verranno analizzate tutte le sue meta-classi e le loro relazioni. 2.1 SpagoWorld SpagoWorld [11] (Figura 2.1) è un iniziativa di software libero/open source promossa da Engineering S.p.A. e composta da quattro progetti principali: Spago: il framework Java EE per lo sviluppo di applicazioni web e multicanale in ambienti SOA. SpagoBI: la piattaforma per lo sviluppo di progetti di Business Intelligence in un ambiente integrato. Spagic: la piattaforma libera per lo sviluppo e la gestione di soluzioni in architettura SOA/BPM. Spago4Q: la verticalizzazione di SpagoBI per le misure e l analisi di prodotti e processi software. 41

51 2.1. SpagoWorld 42 Il progetto ha inizio nel 2001 quando la Direzione Architetture e Consulenza di Engineering ha necessità di realizzare un framework Java Enterprise per lo sviluppo dei propri progetti interni, concretizzato poi nel tool Spago. Alla fine del 2004, tale framework viene re-ingegnerizzato e rilasciato come open source. Nel 2005 viene lanciato SpagoBI; nel 2007 vedono la luce Spagic e Spago4Q. Tutti i progetti hanno delle caratteristiche comuni: software libero: distribuiti secondo la licenza GNU/GPL, quindi nessuna versione è a pagamento. soluzioni adattabili: integrano componenti esistenti e sviluppano nuovi moduli secondo le esigenze degli utenti; non sono dunque le persone a doversi adattare. livello industriale: soluzioni che nascono dall esperienza di progetti di livello industriale dove le applicazioni sono mission-critical e devono garantire funzionalità ed alte prestazioni. Figura 2.1: Lo stack di SpagoWorld [11] utilizzo commerciale: categorie di prodotti. è possibile utilizzare le soluzioni SpagoWorld con diverse servizi di supporto: forniti a richiesta e disponibili per ogni progetto. attenzione alla comunità ed alla ricerca: SpagoWorld segue le esigenze della comunità e recepisce le innovazioni provenienti dal mondo accademico e della ricerca. SpagoWorld [10] non è solo una cooperazione tecnologica, il suo obiettivo principale è promuovere le comunità di progetto per consolidare un modello di business diversificato

52 2.2. Spago 43 basato sullo sviluppo e la promozione di soluzioni singole. Il pacchetto è distribuito attraverso la piattaforma OW2 Forge [20] per permettere la partecipazione della comunità mediante vari strumenti (mailing lists, forum, contenitori, area di download), garantendo al tempo stesso la disponibilità continua ed immediata del software rilasciato. Questa collaborazione rappresenta un esempio di comunità di software open source di terza generazione. SpagoWorld fornisce un contesto nel quale tutti gli attori coinvolti (società, venditori, consulenti di Business Intelligence, istituzioni governative, clienti, accademie e singoli utenti) cooperano per sviluppare soluzioni mature ed affidabili e si confrontano per fare incontrare i loro obiettivi, creando così un ambiente stimolante ed attivo. In questo modo, chi aderisce all iniziativa può trovare un riferimento per le proprie strategie da adottare ed un opportunità di contribuire alla crescita del progetto. 2.2 Spago Caratteristiche Spago [11] è un framework J2EE: un infrastruttura software riutilizzabile che può essere specializzata per produrre soluzioni verticali. Include alcuni servizi per applicazioni generiche, linee guida per lo sviluppo, possibilità di seguire gli standard, strumenti per la manutenzione e l implementazione. Realizzato per progetti mission-critical, è una soluzione per l erogazione di servizi applicativi multicanale e l integrazione verso infrastrutture esterne. Spago implementa il pattern architetturale MVC (Model-View-Controller): impone una netta divisione tra layer di pubblicazione, logica applicativa ed accesso ai dati. L infrastruttura abilita la comunicazione tra i diversi processi intra ed extra aziendali. In più, è fortemente orientata agli sviluppi in ambienti SOA: è possibile richiamare servizi come i Web Services attraverso messaggi JMS o chiamate EJB. Spago [11] ha le seguenti caratteristiche di base: Servizi multicanale/multiprotocollo: permette di implementare i servizi applicativi in modo indipendente dal canale su cui verranno distribuiti. E possibile erogare i servizi su diversi canali (HTTP, WAP, Portlet) e tramite diversi protocolli (HTTP, SOAP, EJB, JMS, JBI). Dispatching a moduli: l implementazione dei servizi è molto flessibile e consente un alto livello di riuso del codice. Introduce il concetto di pagina come composizione logica di moduli: diversi business object cooperano per soddisfare la richiesta di un servizio. Un grafo specifica la sequenza con cui invocare i vari moduli e definisce i parametri scambiati.

53 2.2. Spago 44 Pubblicazione su Portlet Container: pubblicazione configurabile di servizi su portali aderenti allo standard JSR 168. I servizi possono essere distribuiti come applicazione web o Portlet. Pubblicazione: pubblicazione scelta in accordo con il canale su cui viene erogato il servizio. A queste, si aggiungono le caratteristiche avanzate: Integrazione JBI: un adapter JBI permette di esporre i servizi come componenti JBI. Integrazione AJAX: semplifica la costruzione di interfacce utente complesse durante lo sviluppo dei servizi applicativi. Distribuzione logica di business: è possibile scegliere dove eseguire i servizi applicativi: web container o EJB container. La modalità di esecuzione può essere decisa in fase di deploy, senza impatto sul codice. Integrazione CMS: è disponibile un plug-in per l integrazione di sistemi di Content Management che implementano le specifiche JSR 170. Integrazione Workflow: per consentire l implementazione di processi complessi. Piattaforme eterogenee: è possibile integrare servizi sviluppati su piattaforme eterogenee tramite SOAP; Sicurezza: è possibile limitare l esecuzione di un modulo di business solamente agli utenti con determinate credenziali definite in sistemi esterni come LDAP, database o file XML. Integrazione BPEL: I servizi scritti con Spago possono essere invocati da qualunque motore BPEL tramite SOAP L Architettura Come detto in precedenza, Spago [11] implementa il modello Model-View-Controller e supporta diversi canali e protocolli di interazione. Il quadro completo dell architettura è visibile in Figura Il Modulo Controller Il modulo Controller [11] agisce grazie alla collaborazione dei seguenti oggetti: Adapter: si occupa dell acquisizione dei dati in arrivo con la request proveniente da uno specifico canale, trasformando i parametri in un formato compatibile con il modulo Model (accesso ai dati). Gli adapter disponibili sono:

54 2.2. Spago AdapterHTTP (HTML/HTTP) - una servlet per gestire le richieste HTTP del client, provenienti da un browser o da un servizio WAP. 2. AdapterSOAP (XML/HTTP) - una componente per gestire le richieste provenienti da un client SOAP. 3. AdapterEJB (XML/IOOP) - una sessione per gestire le richieste provenienti da un client IIOP. 4. AdapterJMS (XML/JMS) - un messaggio guidato per gestire le richieste spedite come messaggi JMS. Dispatcher: responsabile dell identificazione della modalità in uso, tra quelle supportate, per estrarre la logica dell applicazione ed allocare il coordinatore adatto. I dispatcher disponibili di default sono: 1. ActionDispatcher - verifica che la logica dell applicazione si basi sulle azioni: ogni oggetto corrisponde ad una richiesta. In questo caso si attiva il coordinatore ActionCoordinator, che ottiene le referenze da ActionFactory. 2. ModuleDispatcher - verifica che la logica dell applicazione si basi sui moduli: più oggetti cooperanti corrispondono ad una richiesta. In questo caso si attiva il coordinatore ModuleCoordinator, che ottiene le referenze da ModuleFactory. Coordinator: gestisce l esecuzione della logica dell applicazione. Business Factory: ha la responsabilità di riportare le referenze esatte agli oggetti applicativi cooperanti nell esecuzione della richiesta. Figura 2.2: L architettura di Spago [11]

55 2.2. Spago Il Modulo View Il modulo View [11] può essere configurato in modo che sia compatibile al canale, ai parametri di richiesta ed allo stato dell applicazione. Le informazioni possono essere presentate via JSP e Servlet (per i canali web) od applicando la trasformazione XML/XSLT dei dati. Quest ultima soluzione è l unica adottabile su tutti i canali supportati I Metodi Action e Module Una Action [11] è un oggetto che estrae la richiesta in arrivo da un servizio applicativo. Un servizio corrisponde ad un oggetto (ma lo stesso oggetto può estrarre diverse richieste). Una Action fa la sua apparizione in ciascuno dei seguenti contesti: Request - per ogni richiesta si attiva una nuova Action. Session - la stessa Action estrae il servizio corrispondente a tutte le richieste della sessione. Applicazione - la Action estrae il servizio corrispondente a tutte le richieste dello stesso container (JVM). Anche un Module [11] è un oggetto dell applicazione. Può cooperare con altri moduli per soddisfare una richiesta di servizio. Più moduli cooperanti per lo stesso servizio costituiscono un unita logica detta page. La risposta finale deriva dall unione delle risposte di tutti i moduli. Il framework individua l ordine di esecuzione di ciascun componente del page. Le regole che verificano il corretto esito di una transizione tra un modulo ed un altro sono dette condizioni; quelle per definire i parametri della richiesta di un modulo sono chiamate conseguenze Lo Svolgimento del Processo Gli step [11] che Spago deve eseguire per spedire una richiesta sono, nell ordine: 1. Adattare la richiesta - la struttura contenente i parametri della richiesta è convertita dal formato originale del canale a quello interno. 2. Creare una sessione. 3. Realizzare il contesto della richiesta - necessario per contenere i parametri di input, il contesto della sessione, un gestore di errori ed altri parametri specifici del canale. 4. Trovare il Dispatcher - si definisce il Dispatcher corrispondente alla logica di esecuzione. 5. Inoltrare la logica di applicazione - il Dispatcher recupera il Coordinator che estrarrà la logica di esecuzione. Il Coordinator a sua volta delegherà uno o più oggetti addetti

56 2.3. SpagoBI 47 al servizio di implementazione, in base al metodo scelto per la richiesta corrente. Si possono definire nuovi metodi od utilizzare i due già presenti (Action o Module). 6. Inoltrare i dati di output - I dati vengono reindirizzati al modulo View. Se le modalità di configurazione non sono dichiarate, la risposta al client sarà di default in formato XML Altri Servizi per Spago I servizi operativi [11] per tutto il framework, considerando tutti i moduli contemporaneamente, sono: Tracer - per memorizzare in un file i messaggi scambiati durante l elaborazione. Gestore degli errori - inserisce gli errori in uno stack; per ciascun errore è specificato l origine (interno o lato utente). Request Container - conserva i dati relativi ad una determinata richiesta. Session Container - conserva i dati relativi ad una determinata sessione. Application Container - conserva i dati dell applicazione agendo come una cache (il cui periodo di attività è definito dall utente). Configurazione - tiene traccia dei dati di configurazione dell applicazione in un file XML. InitializerManager - conserva in uno stack tutte le richieste relative a servizi non più attivi e permette di rieseguire il servizio precedente alle stesse condizioni (rintracciabili nei Container Request e Session). 2.3 SpagoBI Il Modello Le piattaforme di Business Intelligence [12] aiutano gli utenti e le organizzazioni a costruire applicazioni a supporto dei loro processi decisionali. Tali software, normalmente, coprono tutti gli step di un processo (modellazione e lettura dei dati, presentazione analitica, elaborazioni statistiche, navigabilità tra le informazioni, rilascio, sicurezza) e tutti i requisiti analitici (Query e reporting, analisi OLAP, dashboard, data mining). Anche SpagoBI, disponendo di tutti i servizi necessari (Figura 2.3), appartiene a questa categoria. Il suo approccio, però, è differente: innanzitutto, è un prodotto che adotta totalmente la filosofia open source; poi, adotta un modello del tutto diverso che può essere definito

57 2.3. SpagoBI 48 progetto-centrico [13] anziché prodotto-centrico: il progetto è l elemento su cui si focalizza la piattaforma, prima ancora del prodotto, per offrire una raccolta di dati ed una tecnologia adeguate ai reali bisogni dei committenti ed alle loro disponibilità finanziarie. La comunità [12] è la risorsa principale per l evoluzione della piattaforma: SpagoBI condivide con imprese, accademie e gruppi di ricerca, un percorso unico di ricerca e sviluppo per poter riflettere i veri bisogni di chi ne farà uso e per trovare nuove soluzioni mediante l esperienza dei progetti, seppur diversificati. Figura 2.3: Le funzionalità disponibili in SpagoBI [15] L Architettura SpagoBI [13] è una piattaforma di integrazione (Figura 2.4): offre molteplici motori per la stessa area analitica, lasciando all utente la possibilità di scegliere come comporre il proprio ambiente di sviluppo. Tali motori sono sviluppati da zero o integrando tool open

58 2.3. SpagoBI 49 source o proprietari già esistenti. Il numero dei motori disponibili e le loro caratteristiche crescono nel tempo in base alle necessità di sviluppo. Da un punto di vista funzionale, l architettura di SpagoBI può essere divisa in diversi moduli: SpagoBI Server, la piattaforma di Business Intelligence. SpagoBI Studio, l ambiente di sviluppo integrato. SpagoBI Meta, l ambiente per i metadati. Figura 2.4: La piattaforma di integrazione di SpagoBI [13] SpagoBI SDK, il layer di integrazione per utilizzare SpagoBI da applicativi esterni. SpagoBI Applications, che accoglie tutti i modelli analitici verticali sviluppati con SpagoBI SpagoBI Server SpagoBI Server [12] [13] [14] è costruito su tre modelli concettuali (Figura 2.5): modello analitico, modello comportamentale e modello tecnico. Il modello analitico (Figura 2.6) dispone di tutte le componenti necessarie per costruire

59 2.3. SpagoBI 50 una buona soluzione analitica. Basato su un ricco modello di metadati, il modello è composto da: processi ETL (Extract, Transform, Load) / EII (Enterprise Information Integration) per raccogliere dati da diverse sorgenti. Report per presentare i dati strutturati in modalità pixel-perfect (perfetto allineamento tra i pixel dell immagine e quelli del monitor, a vantaggio della qualità dell immagine). Analisi OLAP per navigare attraverso i dati. Cruscotti in tempo reale (dashboard) per monitorare gli indicatori di performance (KPI). Processi di data mining per scoprire informazioni nascoste. Analisi geografiche per pubblicare dati attraverso una rappresentazione geografica e navigarli. Figura 2.5: L architettura di SpagoBI Server [12] Free Inquiry (QbE) per comporre liberamente le proprie query, esportare i dati in fogli Excel e generare il primo template di reportistica. Dossier analitici per condividere dati pubblici e privati prima di una riunione o per archiviare una collezione tematica di documenti. Documenti Office per pubblicare i risultati sotto il controllo del modello comportamentale. Grafici per rappresentazioni intuitive e semplici. Documenti composti per combinare diversi documenti di base (report, mappe, grafici, tachimetri) in un unica vista con una propria logica di navigazione.

60 2.3. SpagoBI 51 Le tecnologie alla base di queste soluzioni sono visibili in Figura 2.7. Il modello comportamentale è il cuore di SpagoBI, quello che rende utilizzabile la piattaforma a livello aziendale. Gli amministratori e gli sviluppatori possono regolare la visibilità sui documenti e sui dati in relazione ai ruoli dell utente finale. In particolare è possibile specificare: A quali documenti analitici ha accesso l utente. Come presentare ciascun documento. Figura 2.6: Il modello analitico di SpagoBI [12] Quali parametri sono richiesti. Quali sono i valori ammessi predefiniti. Come validare il valore scelto. Quali dati mostrare. Grazie al modello, l amministratore riduce il numero di documenti analitici da sviluppare. In più, è garantita la sicurezza e la conservazione: ogni concetto analitico è codificato solo una volta per mezzo delle regole comportamentali e successivamente condiviso da ogni motore analitico della piattaforma, indipendentemente dalla sua natura e scopo. Il modello tecnico, infine, fornisce tutte le funzionalità analitiche che semplificano la gestione della piattaforma da parte di sviluppatori, tester ed amministratori: schedulatore

61 2.3. SpagoBI 52 import/export audit & monitoring iter di approvazione sincronizzazione dei ruoli Figura 2.7: Le tecnologie utilizzate da SpagoBI [15] configurazione dei data source e dei motori impostazione delle politiche di visibilità

62 2.4. Spago4Q SpagoBI Studio SpagoBi Studio [13] è l ambiente di sviluppo integrato, basato su Eclipse [23], che permette allo sviluppatore di disegnare e mantenere tutti i documenti analitici. Può essere inoltre utilizzato per testare e rilasciare i documenti in SpagoBI Server SpagoBI Meta E il modulo [13] per la gestione e l interrogazione dei meta-dati, tecnici e di business; permette all utente di modificarli ed importarli da tool esterni come ETL. I metadati di business aiutano gli utenti a conoscere meglio, con ulteriori dettagli, i dati sotto osservazione; quelli tecnici invece, rendono nota all amministratore la provenienza dei dati, generare documentazione automatica od effettuare analisi di impatto SpagoBI SDK E il modulo [13] che offre alcune API standard per richiamare funzionalità di SpagoBI da tool ed ambienti esterni; fornisce inoltre alcuni tag per fare riferimenti diretti ad un documento dall interno di una semplice applicazione web. 2.4 Spago4Q Spago4Q (SpagoBI for Quality) [16] è una piattaforma sviluppata per misurare la qualità del software. Adattabile ai contesti più complessi delle organizzazioni, indipendentemente dai processi di sviluppo software adottati, dai tool e dai framework di misurazione e valutazione, è utile anche per verificare la maturità e l efficacia del processo. La valutazione dei dati e delle misure adottate dal management avviene per mezzo di tecniche non invasive (non coinvolgono lo sviluppatore, che non deve quindi modificare lo svolgimento delle sue normali attività). La piattaforma è una verticalizzazione di SpagoBI: aggiunge un generico meta-modello per il processo di sviluppo, per il framework di misura e di valutazione, per gestire i dati relativi alla qualità del software, e degli estrattori per immagazzinarli. E proprio grazie a questa sua struttura avanzata che Spago4Q [17] supporta pienamente il framework di valutazione CMMI. Spago4Q può essere utilizzato da organizzazioni e aziende durante il processo di certificazione della qualità e nel monitoraggio dei processi formali. Può anche supportare i manager ed il team di sviluppo fornendo informazioni sull andamento del progetto in corso. Un set configurabile di cruscotti (dashboard), report e documenti OLAP permette di monitorare vari aspetti dei processi, tra i quali: gestione dei requisiti, bugs, test, e gestione del rischio.

63 2.4. Spago4Q Il Meta-modello Per meta-modello [18] si intende un insieme composto dalla logica e dal vocabolario dei concetti necessari a costruire, rifinire e rappresentare, famiglie ed istanze di processi in termini di oggetti quali classi, attributi, relazioni, vincoli, controllo del flusso, regole e metodi computazionali. Lo scopo del meta-modello [19] di Spago4Q è triplice: Supportare la raccolta dei dati tra vari processi. Supportare framework come Goal Question Metric (GQM), Balanced Scorecard (BSc), ISO 9000 e CMMI (Capability Maturity Model Integration). Analizzare i processi ed i dati a differenti livelli di granularità, supportando ogni dimensione aziendale. Il modello di Spago4Q segue l approccio Meta Object Facility (MOF) L Approccio MOF Il MOF [17] [18] definisce i concetti per creare un meta-modello a blocchi che generalmente descrive un sistema od un meccanismo di istanziazione per produrre un modello generico. Questo approccio può essere descritto come una struttura a strati composta dai seguenti quattro livelli (partendo dal più alto): Definizione di tutti i concetti e degli attributi per il modello da utilizzare. Realizzazione del meta-modello che definisce la struttura e la semantica dei metadati per la descrizione un ambiente generico. Creazione del modello che descrive la struttura. Rappresentare e conservare i dati secondo il modello definito al livello precedente. Lo standard MOF supporta lo scambio e la fusione di dati provenienti da differenti risorse; questo contribuisce all indipendenza di Spago4Q dall infrastruttura sottostante. Per garantire un livello uniforme del processo e della qualità dei prodotti attraverso tutti i progetti, in Spago4Q il meta-modello è suddiviso in tre ulteriori modelli: processo, misurazione e rilevamento (Figura 2.8) Il Meta-modello del Processo Il meta-modello del processo [17] [18] è stato definito partendo da una versione semplificata di SPEM (Software Process Engineering Meta-model), che descrive lo schema di un concreto processo di sviluppo software. Il meta-modello è stato realizzato per essere il più generico possibile; graficamente (Figura 2.9), descrive l ambiente di sviluppo di un organizzazione mediante dei riquadri (le

64 2.4. Spago4Q 55 meta-classi) correlati tra loro per mezzo di frecce (le relazioni). Figura 2.8: Il meta-modello modulare di Spago4Q: i colori distinguono i meta-modelli di Processo (giallo), Misurazione (verde), Rilevamento (azzurro) e Trigger (rosso) [19] L elemento al top del meta-modello è la classe Organization, che raccoglie tutti i nodi di Project e supporta le analisi di ogni dimensione aziendale trasversalmente, di progetto in progetto. La classe Project rappresenta un singolo progetto dell organizzazione; ciascuno, poi, è associato ad uno specifico processo di sviluppo, composto da un set (mai vuoto) di Phase. Ogni fase può essere linkata ad altre fasi ed è composta da una serie di classi di Activity;

65 2.4. Spago4Q 56 in base al grado di granularità scelto, ogni attività potrebbe essere decomposta in Task o Sottoattività. Inoltre, ogni Activity è in relazione (molti a molti) con le seguenti classi: Figura 2.9: Il meta-modello del Processo di sviluppo [17] WorkProduct, che rappresenta il set dei prodotti che le attività si aspettano di produrre. Role, che definisce i ruoli che cooperano per portare avanti una specifica attività e produrre un set di work-product. Tool, che indica gli strumenti necessari per usare e produrre i work-product tramite le attività. In questo livello, due sono gli scopi principali: definire una struttura generica per ogni processo di sviluppo specifico, e formalizzare le relazioni tra entità del meta-modello di misurazione e valutazione Il Meta-modello di Misurazione Il meta-modello per il framework di misurazione di un progetto [17] [18] è stato definito seguendo il paradigma Goal Question Metric (GQM). L obiettivo è quello di fornire uno schema generico per prelevare misure da qualsiasi tipo di processo di sviluppo. La sua struttura è presentata in Figura Le entità principali sono tre: measurableconcept, che definisce gli obiettivi dell analisi. measurableattribute, che definisce quali attributi vanno misurati per valutare uno specifico obiettivo.

66 2.4. Spago4Q 57 Metric (e KPI), che definisce le operazioni da applicare sugli attributi misurati per restituire indicatori coerenti. Figura 2.10: Il meta-modello del Processo di Misurazione [18] Nello specifico, ogni progetto ha bisogno di varie informationneed. Tale meta-classe, come facilmente intuibile dal nome, identifica le informazioni necessarie per misurare le azioni previste. Questo nodo, inoltre, è usato come link concettuale tra i meta-modelli di processo e misurazione. Seguendo il modello GQM, ogni InformationNeed ha il suo MeasurableConcept a sua volta legato alla meta-classe MeasurableAttribute. Questo nodo ha uno stretto legame con il WorkProduct del meta-modello di processo in quanto specifica in quale WorkProduct (requisiti, classe sorgente, test, ecc...) l attributo deve essere misurato. La classe Measure definisce la struttura che i valori risultanti dalla misurazione devono osservare. Per questo motivo Measure è strettamente collegata alle meta-classi Unit e scaletype che definiscono, rispettivamente, l unità di misura usata ed il tipo di scala adottato (nominale,

67 2.4. Spago4Q 58 ordinale, ecc...). Una misura è in correlazione anche con la classe Metric, descritta sopra. Per finire, la metrica è in correlazione con Threshold, che specifica le soglie entro le quali il valore di ciascuna metrica dovrebbe posizionarsi, in caso di misurazioni quantitative Il Meta-modello di Valutazione Questo framework [17] viene adottato dalle organizzazioni per valutare la qualità del lavoro eseguito, che equivale molto spesso alla qualità dei prodotti risultanti. In Spago4Q è riassunto da un meta-modello composto da tre entità: Category, il nodo che raccoglie in categorie gli obiettivi della valutazione. Target, che indica l obiettivo da esaminare. Practice, che indica la pratica associata alle metriche specifiche. Questo nodo è connesso con la meta-classe Metric del livello di misurazione, a sottolineare il concetto che la valutazione di un set di metriche può mostrare il reale andamento della pratica. Il meta-modello supporta tutti i tipi di frame work di valutazione (ISO, CMMI, etc.); Spago4Q, nello specifico, implementa il modello CMMI Il Meta-modello del Trigger Il meta-modello trigger [18] definisce la struttura di un livello intermedio che connette il processo di sviluppo con il framework di misurazione. Il suo obiettivo [19] è formalizzare e definire gli estrattori che verranno usati per estrapolare i dati dal modulo di processo e fornirli a quello di misurazione, ottenendo l indipendenza tra i due livelli. Tutte le relazioni sono visibili in Figura Il meta-modello è composto da due entità: Trigger e TriggerData. Trigger [18] è la meta-classe che rappresenta, secondo la situazione, una specifica domanda od un componente; lo scopo è quello di restituire un attributo specifico in un determinato momento del processo di sviluppo. Trigger è in relazione con la classe MeasurableAttribute, per conoscere quali attributi devono essere misurati, e con le entità Organization, Project, Phase e Activity per ricevere la locazione fisica e logica degli attributi da misurare. Infine, la classe TriggerData [18] identifica il risultato di un azione di misurazione effettuata da un istanza dell entità Trigger. E in relazione con la meta-classe Measure. I trigger sono a stretto contatto con gli strumenti software attraverso i quali avviene l uso degli estrattori. Sono queste componenti che consentono l interazione con lo strumento che genera i work-product da misurare. Tutte le configurazioni relative alla misurazione sono, ovviamente, preparate ad-hoc dai

68 2.4. Spago4Q 59 Figura 2.11: Il meta-modello Trigger e le relazioni con gli altri livelli [18] manager; grazie alla rigidità dei settaggi, è possibile applicare lo stesso framework di misurazione a molteplici istanze di processo L Architettura di Spago4Q Il modello architetturale [17] soddisfa i seguenti requisiti: Sistema aperto e conforme agli standard de-facto. Può essere utilizzato in applicazioni web. Alta adattabilità ai diversi contesti dell organizzazione. Processo di misurazione indipendente dai processi di sviluppo software adottati e dai tool utilizzati. Raccolta automatica dei dati da un set di strumenti. Supporto per un sistema complesso di valutazione. Accesso sicuro e protezione della privacy del management. Disponibilità di un set di librerie per la misurazione ed istanze del meta-modello per soddisfare i bisogni dell utente finale. L architettura completa di Spago4Q (Figura 2.12) è composta da quattro moduli [17]: Project repositories. DWH Spago4Q Analytical tool Configuration & Administration

69 2.4. Spago4Q 60 Figura 2.12: La visione d insieme del modello architetturale di Spago4Q [17] Il Processo Il flusso delle operazioni [17] ha inizio con la raccolta dei dati necessari per i KPI e le metriche scelte. I componenti dell estrattore devono essere opportunamente correlati ai differenti contenitori di dati adottati nel processo di sviluppo. La procedura ETL (Extract, Transform, Load) [17] [19], grazie ad un set di estrattori predefiniti, istanze della meta classe Trigger, prende i dati dai contenitori utilizzati dai manager (ad esempio documenti Office, OpenOffice, o tool di sviluppo come Eclipse) e li carica nel Data warehouse di Spago4Q. All interno di questo modulo è presente un interfaccia che, per ogni misurazione, standardizza il formato dei dati in input e determina le regole specifiche da applicare. Il DWH Spago4Q è il cuore del sistema, una particolare istanza del meta-modello che ingloba i processi di sviluppo, misurazione e valutazione (Paragrafo ). La struttura del data warehouse [17] è disegnata per soddisfare le seguenti proprietà: schema a fiocco di neve (architettura in cui è presente una tabella dei fatti e varie tabelle di dimensioni normalizzate, con conseguente risparmio di spazio ma aumento di relazioni e di join);

70 2.4. Spago4Q 61 tabella dei fatti: per associare un record di ogni evento accaduto su un attributo misurabile ad un work-product; dimensioni delle tabelle: dimensioni uniformi e interscambiabili tra i vari workproduct; dati storici; tracciabilità dei dati non accettati. SpagoBI, infine, analizza i dati e rappresenta le metriche, mentre il modulo Configuration & Administration permette di configurare il sistema. Grazie all elasticità dei meta-modelli definiti in Spago4Q, è possibile implementare un buon numero di modelli formali seguendo le strutture di questi framework. Tra questi si possono citare: UP, SCRUM e waterfall (per processi di sviluppo specifici); CMMI (come framework di valutazione); Modelli per misurare requisiti, bug, test e rischi (aree di misura delle attività); Estrattori specializzati per collezionare dati. Per completare il processo di valutazione, i dati inseriti nel DWH devono essere analizzati dalla componente analitica di Spago4Q. La piattaforma SpagoBI, oltre all analisi, facilita la rappresentazione dei KPI, delle metriche e delle soglie relative, riducendole come istanze di un particolare tipo di documento analitico offerto da SpagoBI stesso (report, OLAP, data mining, cruscotti, ecc...). Infine, tutti i moduli sopra descritti possono essere configurati opportunamente con il modulo di configurazione ed amministrazione che fornisce le seguenti possibilità: definizione delle connessioni ai contenitori di dati ed agli strumenti; lista di controllo degli accessi; dgstione dei valori delle soglie; gestione della protezione della privacy Il Modello del Data Warehouse Spago4Q Data la sua importanza nel sistema, è opportuno esplicare la relazione tra il modello adottato ed il meta-modello generale da cui è nato. Come detto in precedenza, DWH Spago4Q racchiude i meta-modelli di sviluppo, misurazione e valutazione. Il modello di misurazione segue l approccio GQM: i goal sono contenuti nella classe InformationNeed, le question in MeasurableConcept e le metriche nel nodo MeasurableAttribute. La struttura di quest ultime è definita nella meta-classe Measure, strettamente collegata alle meta-classi Unit e scaletype che definiscono, rispettivamente, l unità di misura usata

71 2.4. Spago4Q 62 ed il tipo di scala adottato (nominale, ordinale, ecc...). Una misura è legata alla classe Metric, a sua volta in correlazione con Threshold, che specifica le soglie entro le quali il valore di ciascuna metrica dovrebbe posizionarsi. Il data warehouse raggruppa i nodi di questo meta-modello nella tabella dt measure model kpi. Le prime colonne contengono i dati relativi alla struttura del modello GQM, le altre ospitano i valori delle metriche e delle soglie (Figura 2.13). Il modello di valutazione implementa il framework CMMI classificando i concetti di categoria, obiettivi, ed attività nei rispettivi nodi Category, Target e Practice. Il nodo Practice è connesso con la classe Metric del modello di misurazione. La tabella dt model assess kpi, similmente a quella descritta nel modello di misurazione, rappresenta i tre livelli della struttura CMMI con le relative metriche e soglie (Figura 2.14). Infine, il DWH include tutte le entità necessarie al sistema in altre apposite tabelle: dt project per i dati di progetto (nome dell organizzazione, prodotto da sviluppare, tecnologie da utilizzare, ecc.); dt process per i dati di processo (data di inizio e fine, ruoli coinvolti, area di business interessata, ecc.); ft requirement per i dati relativi ai requisiti (priorità, momento in cui si richiedono, ecc.); ft bug per i dati sui malfunzionamenti (data di scoperta, tipo di bug, area di localizzazione, ecc.); ft test per i dati sui risultati dei test (data di inizio e fine test, tipo di test, priorità, ecc.); L overview del Data warehouse con la sua struttura a fiocco di neve è raffigurata in Figura 2.15.

72 2.4. Spago4Q 63 Figura 2.13: Il modello di misurazione nel DWH Spago4Q

73 2.4. Spago4Q 64 Figura 2.14: Il modello di valutazione nel DWH Spago4Q

74 2.4. Spago4Q 65 Figura 2.15: La struttura del DWH Spago4Q

75 Capitolo 3 Implementazione di Qest nd In questo capitolo si descriverà il procedimento per implementare Qest nd. Dapprima, saranno presentati i software necessari per il lavoro, poi verranno discusse una ad una tutte le fasi e le attività di un progetto generico con l obiettivo di anticipare quanto sarà fatto nella parte successiva (la presentazione di due casi d uso) e chiarire alcuni concetti. 3.1 Strumenti Utilizzati Come in ogni progetto di informatizzazione, anche per implementare il modello QEST nd è necessario disporre di alcuni software specifici. Utilizzando Spago4Q come piattaforma di supporto per la misurazione e considerando la sua architettura (Paragrafo 2.4.2), la prima operazione da compiere è installare SpagoBI; solo in seguito si procederà con l aggiunta di Spago4Q. Alle due piattaforme si affiancano altri strumenti software: alcuni di essi, come Apache Tomcat e MySQL, sono indispensabili, altri invece non sempre necessari (è il caso di Eclipse). E importante sottolineare che tutti i software utilizzati sono completamente open source e quindi gratuiti Apache Tomcat Apache Tomcat [21] è un software open source che implementa le tecnologie Java Servlet e Java Server Pages (JSP). Il suo ambiente di sviluppo è aperto e punta sulla collaborazione di programmatori di tutto il mondo. Il software è rilasciato sotto la Apache Software License. Chiamato più comunemente Tomcat, è in grado di supportare qualsiasi tipo di organizzazione grazie alla sua propensione mission-critical per i progetti web. 66

76 3.1. Strumenti Utilizzati 67 Applicato a Spago4Q, svolge la funzione di server dell intera applicazione, essendo questa di tipo web-based MySQL MySQL [22] è un sistema per la gestione di database relazionali basati su SQL. Completamente open source, è sviluppato, distribuito (sotto licenza GPL/GNU) e supportato dalla Sun Microsystems Inc. Il server permette di aggiungere, modificare e, più in generale, accedere ai dati contenuti all interno di un computer. Trattandosi di un database relazionale, tali dati sono riposti in tabelle separate. In Spago, MySQL svolge la funzione di Data warehouse contenente, tra gli altri, i dati necessari all implementazione del modello QEST nd. In particolare: dati relativi alla struttura del modello; dati relativi agli obiettivi da misurare; dati relativi alle metriche; dati relativi al range di valori ammessi (soglie). MySQL può lavorare sia in sistemi client/server che in sistemi chiusi grazie alla sua architettura multi-processo che supporta vari tipi di interfacce, librerie e programmi lato utente. Anche per amministrare il database la scelta tra i software è ampia; per questo progetto ne sono stati utilizzati due, sviluppati sempre dalla Sun per lavorare più comodamente con MySQL: MySQL Administrator e MySQL Query Browser MySQL Administrator MySQL Administrator [22] è un programma per compiere operazioni di amministrazione, come configurare il server MySQL, verificare il suo stato e le performance, avviarlo e fermarlo, effettuare backup ed una serie di altri compiti di gestione. Pur essendo possibile realizzare la maggior parte di queste operazioni usando un interfaccia a riga di comando, MySQL Administrator è un valido aiuto in quanto la sua interfaccia grafica lo rende più intuitivo e facile da usare (in una parola, user-friendly). Inoltre, funziona su qualsiasi sistema operativo MySQL Query Browser MySQL Query Browser [22] è uno strumento per creare, eseguire ed ottimizzare query in ambiente grafico. In sostanza è progettato per eseguire query ed analizzare i dati memorizzati nel database MySQL.

77 3.1. Strumenti Utilizzati 68 Come nel caso di MySQL Administrator, un buon motivo per utilizzare questo software è rendere più facile la vita dell utente attraverso l utilizzo dell interfaccia grafica anziché operare da riga di comando Eclipse Eclipse [23] è una piattaforma open source di sviluppo software. Pensata inizialmente ad uso esclusivo di Java, è stata in seguito estesa per ospitare altri linguaggi tra cui C++, XML, PHP ed UML. La piattaforma è personalizzabile (grazie alla disponibilità di framework, strumenti e plugin scaricabili) e può supportare gli sviluppatori in ogni fase del ciclo di vita di un prodotto. Tutte le tecnologie ed i codici sorgenti sono disponibili sotto licenza EPL (Eclipse Public License). Eclipse, in questo progetto, è stato utile per implementare dataset (le query che restituiscono i valori delle misure) caratterizzati da calcoli particolarmente complessi, in quanto con SQL, a differenza di Java, non è possibile eseguire le operazioni matematiche che richiedono una certa flessibilità (sommatorie, produttorie, etc.) BIRT BIRT (Business Intelligence and Reporting Tools) [25] è un sistema fondato su Eclipse per la realizzazione di report per applicazioni web, specialmente per quelle basate su Java e J2EE. BIRT ha due componenti principali: una per disegnare i report con Eclipse, l altra per generarli in runtime all interno dell ambiente Java. BIRT offre anche un motore per creare grafici da inserire nel programma. Con BIRT si possono realizzare vari tipi di report: Liste - un elenco di dati organizzabili secondo varie metodologie (ordini raggruppati per clienti, prodotti raggruppati per fornitori,...) e sui quali si possono effettuare operazioni matematiche (somma, media,...); Grafici - per interpretare più facilmente i dati numerici. BIRT offre grafici a torta, istogrammi, grafici lineari e molti altri che possono essere trattati in formato SVG per una migliore qualità e supportano l interattività con l utente; Matrici (o Crosstabs) - per mostrare dati in due dimensioni; Lettere e documenti - si possono realizzare notifiche, lettere ed altri tipi di documenti testuali includendovi testo, formattazione, liste, grafici e quant altro; Report composti - per combinare tutte le possibilità sopraelencate in un singolo documento (utile soprattutto per report di tipo finanziario).

78 3.2. Un Esempio di Implementazione Un Esempio di Implementazione Dopo aver installato e configurato i software si può procedere con la realizzazione del modello QEST nd. Le attività, tutte realizzabili attraverso l interfaccia di Spago4Q, sono coerenti all approccio PMAI (Paragrafo ) ed in linea con il ciclo PDCA (Paragrafo ). In questo caso, per semplicità e per coerenza con l organizzazione del software, si è suddiviso il procedimento in nove fasi Step 1 - Definizione del Modello e dei KPI Si definisce il modello GQM(R), con le relative metriche, che verrà utilizzato come caso d uso. Il modello può essere creato con le funzioni Model Definition, inizializzandolo con nome, codice (un acronimo per identificare più rapidamente sia un modello che i suoi nodi) e descrizione (Figura 3.1). Dalla scheda KPI si specifica quale metrica dovrà essere associata a tale nodo. Si compone poi la vera e propria struttura ad albero partendo dalla radice ed aggiun- Figura 3.1: L interfaccia per la definizione di un nuovo modello gendo i nodi figli. Dal modello generico si crea un istanza selezionando i nodi di interesse per la misurazione (dalla funzione Model Instance Detail), che sarà la struttura effettivamente utilizzata per ospitare i risultati delle misurazioni. Il risultato finale è visibile in Figura 3.2. In Spago4Q il GQM non ha vincoli specifici: si possono creare per la stessa question n

79 3.2. Un Esempio di Implementazione 70 Figura 3.2: Un modello definito comprensivo di KPI metriche a cui associare un KPI (Key Performance Indicator - Indicatore di Prestazione Chiave). Il KPI viene creato con la funzione KPI Definition (Figura 3.3) e ha, tra i vari attributi, le opzioni Calculation Rule per indicare l algoritmo di calcolo del valore (che verrà implementato con il dataset) e Kpi Type per classificare il tipo di KPI (diretto od indiretto). Non bisogna dimenticare, infatti, che in QEST viene specificata la distinzione tra la M (misura diretta) e la R (ratio o misura di tipo indiretto) Step 2 - Definizione dei Pesi e delle Soglie Per prima cosa si definisce il bilanciamento tra valori qualitativi e quantitativi; in parole povere, si attribuisce un peso a ciascun KPI. Il peso indica l importanza rivestita da un determinato Indicatore all interno della dimensione aziendale in cui è situato e può assumere un valore tra 0 ed 1 compresi. In Spago4Q è presente la voce Weight Default Value (Figura 3.3) che permette di inserire il valore numerico da assegnare per default ad ogni misura. Fatto questo, si passa alla definizione dei valori di soglia.

80 3.2. Un Esempio di Implementazione 71 Figura 3.3: L interfaccia per la definizione dei KPI Le soglie devono essere congruenti con la normalizzazione delle metriche (effettuata negli step successivi): una generica soglia di accettabilità assume di norma valori compresi tra 0 ed 1. Mediante la funzione Threshold Detail si assegnano il nome ed il codice alfanumerico identificativo (Figura 3.4). Per ogni soglia creata si stabiliscono dei sotto-intervalli con lo scopo di indicare se il valore del KPI calcolato, a seconda del range in cui si posizionerà, sarà in linea con le previsioni, sotto le aspettative ma accettabile oppure completamente negativo. Gli intervalli si realizzano attraverso la funzione Threshold Value Detail. In Figura 3.5 sono visibili gli attributi per definire ciascun range. In particolare, Min Value e Max Value indicano i valori che delimitano l intervallo, Colour propone una tavolozza da cui scegliere il colore che quella parte di soglia dovrà avere al momento della visualizzazione del modello. Convenzionalmente, l intervallo negativo ha il colore rosso mentre quello che rappresenta l andamento positivo il colore verde. Non esiste un numero standard di intervalli per una soglia; in genere si opta per tre, ma possono essere anche in numero maggiore o più semplicemente due, come si vede in Figura 3.6.

81 3.2. Un Esempio di Implementazione 72 Figura 3.4: L interfaccia per la creazione di una soglia Figura 3.5: L interfaccia per la definizione degli intervalli Step 3 - Definizione del Quality Factor Il Quality Factor (QF) è un Indicatore di qualità del software, ricavato dal parere congiunto dei gruppi di interesse dell organizzazione coinvolti nella definizione del modello.

82 3.2. Un Esempio di Implementazione 73 Figura 3.6: Un esempio di soglie a tre e due intervalli Il QF può essere tralasciato qualora si decida di optare per una misurazione esclusivamente quantitativa. Il suo inserimento avviene allo stesso modo delle altre misure, come sarà descritto nella prossima fase. Il suo ruolo sarà invece visibile nello Step 7, quando verranno calcolati i valori di ciascuna dimensione Step 4 - Raccolta delle Misure Completata la definizione di modelli, KPI, soglie e istanze dei modelli devono essere raccolti i dati necessari a calcolare le misure dirette ed indirette tramite gli estrattori. Per realizzare un estrattore si deve innanzitutto specificare la sorgente delle misure; questo è possibile con la funzione Source Type Detail (Figura 3.7). Si costruisce poi la tabella dei fatti (fact table) che dovrà ospitare le misure estratte e, Figura 3.7: L interfaccia Source Type Detail tramite la funzione Interface Type Detail (Figura 3.8), la si istanzia nel Data warehouse; da notare l attributo Table Name, che serve ad assegnarle il nome all interno del database con il quale verrà richiamata nelle successive fasi. Fatto questo, si creano i campi della tabella con la funzione Interface Field Detail (Figura 3.9); per ognuno si dichiara il nome, il tipo di dati che dovrà contenere e se accetta valori ripetuti. Infine si configura il processo di estrazione: da Extraction Process Detail (Figura 3.10) si inseriscono le informazioni generali come il nome e la periodicità del processo, da Operation Detail (Figura 3.11) si indica la sorgente dati, la tabella dei fatti nella quale andranno

83 3.2. Un Esempio di Implementazione 74 immagazzinati i valori estratti e si associa ciascun campo della fact table al punto della sorgente dati (con struttura identica a quella della tabella) da cui andranno prese le misure da inserire (figura 3.12). Per l alimentazione di una tabella dei fatti specifica per misure di tipo diretto può Figura 3.8: L interfaccia Interface Type Detail Figura 3.9: L interfaccia Interface Field Detail essere creato manualmente un file (in formato.xml o.xls o.csv) su cui realizzare l estrattore. La struttura ideale del documento può essere composta dalle seguenti voci: Codice progetto Codice metrica Valore metrica Rmin Rmax In un esempio relativo ad un file.xml tali voci possono essere organizzate così:

84 3.2. Un Esempio di Implementazione 75 Figura 3.10: L interfaccia Extraction Process Detail Figura 3.11: L interfaccia Operation Detail Figura 3.12: L associazione tra i campi della fact table e della sorgente dati <GenericItem>

85 3.2. Un Esempio di Implementazione 76 <resource>progetto PRJ01</resource> <metric>qus</metric> <value>100</value> <Rmin>0,0000</Rmin> <Rmax>1000,0000</Rmax> </GenericItem> Un GenericItem racchiude i dati relativi ad una singola misura e corrisponde ad un futuro record della tabella. Nel documento sorgente saranno presenti tanti GenericItem quanto le misure da inserire. Resource indica il nome del progetto (modello) al quale appartiene Metric. Rmin ed Rmax sono i valori minimi e massimi da inserire nella formula per normalizzare il Value. Tutte queste configurazioni saranno chiamate in causa all esecuzione dell operazione Data Import (Figura 3.13), nella quale si indica il file sorgente (File to Import), il percorso all interno del quale trovare i dati (XPath) ed il processo di estrazione che dovrà eseguire l operazione (Operation). Figura 3.13: L interfaccia per avviare il caricamento dei dati Step 5 - Calcolo dei Valori delle Metriche Per ogni nodo del modello a cui è collegata una metrica indiretta devono essere implementati i dataset necessari al calcolo della misura, sia in valore assoluto che in valore normalizzato (vedere Paragrafo per approfondimenti). Per dataset si intende un algoritmo per estrarre i valori dalla fact table al fine di eseguire i calcoli previsti da ogni KPI. Tale algoritmo è realizzabile mediante diverse tecnologie (Query, Script, Web Services o classi Java) selezionabili dalla funzione Data Set Detail (Figura 3.14). Come si vede dalla Figura 3.14, ad un dataset vanno associati dei driver analitici: questi sono dei parametri, contenenti informazioni sulla risorsa, l istanza del modello e la data, che saranno inseriti nell algoritmo per specificare a quale progetto ci si riferisce ed evitare che vengano presi valori appartenenti ad altri. Una volta implementato il dataset, sarà poi assegnato al KPI dall interfaccia Kpi Defi-

86 3.2. Un Esempio di Implementazione 77 Figura 3.14: L interfaccia Data Set Detail nition (Figura 3.3) e restituirà il valore per quel determinato nodo Step 6 - Calcolo del Valore delle Dimensioni In corrispondenza dei nodi relativi alle dimensioni del modello deve essere definita una KPI e sviluppato il corrispondente dataset per calcolare il valore di ciascun punto di vista. Il risultato si ottiene dalla somma di tutti i valori pesati delle KPI indirette appartenenti alla dimensione. Più concretamente, il dataset dovrà implementare la seguente formula algebrica: n+1 D = (V p i ) i i=1 dove D è il valore della dimensione, V il valore di ogni KPI e p il relativo peso.

87 3.2. Un Esempio di Implementazione Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Se nel modello è stato preso in considerazione anche il Quality Factor, al valore della dimensione calcolato nello step precedente si somma il QF. Il dataset, quindi, implementa la formula D I = D + QF che in termini più formali è esprimibile come n+1 D = ( (V p i ) i ) + QF i= Step 8 - Calcolo del Valore di Performance Si realizza un dataset che calcola la formula (valida per qualsiasi numero di dimensioni): n+1 P = 1 (1 p i ) i dove p i corrisponde ai valori finali di ciascuna dimensione calcolati in precedenza. Questo dataset sarà associato al nodo radice del progetto. i= Step 9 - Realizzazione dei Report In BIRT, la prima cosa da fare è creare un nuovo progetto di lavoro (in questo caso un report) e scegliere uno dei diversi modelli di base disponibili. I passi successivi prevedono la scelta di una sorgente dati, la creazione di un Data Set, l eventuale dichiarazione dei parametri da associare allo stesso ed il collegamento dei dati agli elementi che compongono il report. Tutte queste operazioni sono selezionabili e monitorabili dalla finestra sulla sinistra dello schermo, nel tab Data Explorer. Per quanto riguarda la sorgente dati, utilizzando appositi driver JDBC è possibile creare report a partire dai dati memorizzati nei formati più disparati. In questo caso, la fonte è il data warehouse di Spago4Q (realizzato in MySQL). Per configurarla si inseriscono i dati della Figura I Data Set di BIRT possono essere considerati come una rappresentazione dei dati memorizzati all interno di una o più tabelle componenti la sorgente dati. All interno di un Data Set può essere memorizzato il risultato di una query SQL oppure di una stored procedure (generalmente si tratta di query scritte in SQL oppure in linguaggi di programmazione specifici memorizzate direttamente all interno di un database). Una volta digitata la query SQL che dovrà essere eseguita per ottenere i dati da presentare nel report, si ottiene un elenco dei vari campi restituiti e si specificano parametri,

88 3.2. Un Esempio di Implementazione 79 Figura 3.15: I parametri richiesti per la connessione al Data Source se necessari, da inserire nell interrogazione. I parametri da inserire in questo caso possono riguardare il nome delle risorse (ParKpiResource), il numero identificativo dei KPI (KPI VALUE ID), la data (ParKpiDate). Cliccando su Previews Results, è possibile testare la query e visualizzare, prima di inserire qualsiasi cosa all interno del report, i dati che sono stati estrapolati dal database. Una volta ottenuti i risultati desiderati, si passa alla stesura del report. La struttura del foglio è quella selezionata al momento della creazione dello stesso; è comunque modificabile in qualsiasi momento inserendo gli elementi disponibili dalla finestra alla sinistra dello schermo, nel tab Palette. Tra i tanti oggetti trascinabili sulla pagina vi sono griglie, tabelle, matrici, grafici, intestazione, piè di pagina ed immagini. La sezione Detail row è sostanzialmente il fulcro del report in corso di creazione: tutto ciò che viene inserito all interno di quest area, sarà ripetuto tante volte quanti sono i record recuperati dalla sorgente dati. Trascinando nella sezione Detail row una colonna presente nel nostro Data Set, ossia un campo dati del database collegato, BIRT provvede ad aggiungerla immediatamente al report creando anche la relativa intestazione. La scheda Properties a fondo pagina consente di intervenire sui font di carattere, sui colori del testo e di sfondo, sul formato dei dati. In questo caso, oltre alla suddetta sezione è stato inserito il relativo grafico per il quale è possibile specificare quali dati importare, su quali assi disporli ed in che modo (scala, formattazione numerica, colori,...). Per associare un report ad un KPI del modello, da Spago4Q si crea un nuovo oggetto nella sezione Sviluppo Documenti e si inseriscono i dati come nell esempio in Figura Dalla voce Template si carica il documento precedentemente realizzato in BIRT, a fondo pagina si aggiungono i parametri necessari (driver analitici). L operazione si conclude selezionando il KPI di interesse (dalla voce di menù KPI) ed associandolo al documento mediante l opzione Document Label presente nella propria pagina di dettaglio.

89 3.2. Un Esempio di Implementazione 80 Figura 3.16: L interfaccia per la definizione di un report in Spago4Q Esecuzione e Visualizzazione Dopo aver svolto tutte le fasi precedenti, avviando la funzione di sviluppo del documento, sarà visualizzato il modello della risorsa con tanto di risultati calcolati in runtime e posizionati sulle soglie. Nelle Figure 3.17 e 3.18 è possibile vedere come si presenta il documento al termine dell implementazione. Un ultimo aspetto interessante è la possibilità di visualizzare il trend per qualsiasi metrica cliccando sulla freccia a destra delle soglie. Un grafico mostrerà le variazioni subite nel tempo da un KPI in seguito alle misurazioni (Figura 3.19). Lo stesso discorso è valido per i report, esclusivamente per le metriche a cui sono stati associati.

90 3.2. Un Esempio di Implementazione 81 Figura 3.17: Visualizzazione di valori e soglie di ciascuna dimensione Figura 3.18: Visualizzazione di valori e soglie dell intero progetto

91 3.2. Un Esempio di Implementazione 82 Figura 3.19: Il quadro delle variazioni dei valori di una metrica nel relativo progetto

92 Capitolo 4 Due Esempi di implementazione In quest ultima sezione saranno messi in pratica gli step descritti al Capitolo 3 per l implementazione del modello QEST nd. In particolare sarà descritta passo per passo la realizzazione di due casi d uso, diversi tra loro ma dalla struttura e dagli obiettivi del tutto simili a quelli riscontrabili nella misurazione dei progetti reali. 4.1 Primo Caso d Uso Il primo modello è stato utilizzato per misurare la performance di un progetto di piccole dimensioni. Proprio per la sua semplicità, si è ipotizzato che al momento è necessaria una sola misurazione; ne seguiranno altre solo nel caso in cui i risultati analizzati suggeriscano sostanziali interventi di miglioramento in determinate aree di sviluppo Step 1 - Definizione del Modello e dei KPI Il modello generico, denominato GQM-QEST, è visibile in Figura 4.1. Il suo scopo è fornire la struttura di partenza da cui creare istanze specifiche, attraverso la selezione dei nodi corrispondenti alle aree ed alle misure da coinvolgere nella valutazione della performance. Per questo progetto, l istanza realizzata coinvolge tutte le tre dimensioni proposte e tutte le misure indirette, escludendo quelle dirette. Questa scelta è dovuta dal fatto che le misure indirette sono ottenute dal rapporto tra quelle dirette incluse nel modello; i valori di quest ultime sono pertanto recuperabili partendo dal risultato finale, senza la necessità di coinvolgerle ulteriormente. Così facendo si elimina la ridondanza di informazioni. Il risultato dell operazione e le differenze rispetto al modello generico sono in Figura 4.2. Nelle due strutture sono presenti anche i KPI, debitamente associati a tutti i rami del livello measure. 83

93 4.1. Primo Caso d Uso 84 L elenco degli indicatori (diretti ed indiretti) definiti per il modello è consultabile in Figura 4.3; la descrizione alla destra del loro codice fornisce le informazioni sul tipo di misura che dovranno immagazzinare Step 2 - Definizione dei Pesi e delle Soglie I pesi e le soglie sono stati definiti solamente per le metriche incluse nell istanza del modello. Non avrebbe senso, infatti, attribuire queste caratteristiche a dei KPI che non verranno mai utilizzati nel progetto. La lista completa, con tanto di corrispondenze tra pesi, soglie e misure, è visibile in Figura 4.4. Come si può notare, agli indicatori di performance delle dimensioni (QEST-E-KPI per quella economica, QEST-S-KPI per quella sociale, QEST-T-KPI per quella tecnica) è stato attribuito un peso di Questo significa che, in una scala percentuale da 0 a 100, i valori quantitativi assumono un peso del 75% sul calcolo del valore finale di prestazione. Analizzando le varie prospettive si osserva, inoltre, che i KPI che contribuiscono maggiormente al raggiungimento dello 0.75 complessivo sono: per l area economica, QEST-TPR e QEST-TDU (rispettivamente con un peso di 0.25 e 0.3); per l area sociale, QEST-AS e QEST-TTE (con rispettivi pesi di 0.25 e 0.3); per l area tecnica, QEST-IDR e QEST-TDU (con peso di 0.4 e 0.2). Tutte le soglie hanno due intervalli ad eccezione di quella per il QEST-KPI che è suddivisa in tre. Il numero posto vicino il confine di ogni sezione indica il valore minimo che il KPI deve assumere per posizionarsi in quel determinato intervallo (giallo o verde nel caso dell indicatore unico, QEST-KPI, verde nelle restanti misure). Tali cifre sono state inserite sulle soglie per dare più informazioni possibili in modo compatto; in Spago4Q si possono visualizzare soltanto attraverso la funzione Threshold Value List. Dai dati relativi a questo step si possono constatare due aspetti ulteriori: gli indicatori presenti in più dimensioni, ossia QEST-TRI, QEST-TST e QEST- TDU, hanno pesi e soglie differenti all interno di ogni area. Benché l obiettivo misurabile sia lo stesso, l importanza che assumono in ciascun punto di vista non è identico; dagli indicatori con un peso maggiore ci si attende quasi sempre un valore minimo di accettabilità più elevato rispetto a quelli meno influenti. I goal più importanti devono assolutamente raggiungere un livello di qualità in linea con quella attesa.

94 4.1. Primo Caso d Uso 85 Figura 4.1: Il modello generico di GQM-QEST

95 4.1. Primo Caso d Uso 86 Figura 4.2: L istanza di modello di GQM-QEST Step 3 - Definizione del Quality Factor Se ai KPI quantitativi è stato attributo un peso del 75%, il restante 25% è appannaggio del Quality Factor che, opportunamente normalizzato, equivale ad un valore di 0,008.

96 4.1. Primo Caso d Uso 87 Figura 4.3: I KPI utilizzati in GQM-QEST Step 4 - Raccolta delle Misure Le misure, compresa quella del Quality Factor, sono state estratte da un file.xml dove erano strutturate nel seguente modo: <?xml version="1.0" encoding="utf-8"?> <GenericItems> <GenericItem> <resource>qest-prj01</resource> <metric>qest-quality factor</metric> <value>0.008</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-tpr</metric> <value> </value> </GenericItem>

97 4.1. Primo Caso d Uso 88 Figura 4.4: I pesi e le soglie di ciascun KPI nel modello GQM-QEST <GenericItem> <resource>qest-prj01</resource> <metric>qest-tri</metric> <value>0.25</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-teri</metric> <value>0.0909</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-tdu</metric> <value>0.8401</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-ex</metric> <value>0.400</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource>

98 4.1. Primo Caso d Uso 89 <metric>qest-sc</metric> <value>0.4300</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-eta</metric> <value>0.3000</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-as</metric> <value>0.6000</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-tte</metric> <value>0.7500</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-tst</metric> <value>0.6176</value> </GenericItem> <GenericItem> <resource>qest-prj01</resource> <metric>qest-idr</metric> <value>0.0880</value> </GenericItem> </GenericItems> Il tag Resource contiene il nome fittizio assegnato al progetto con lo scopo di non mischiare le misure di altre risorse presenti nel data warehouse durante i calcoli. Da questo momento quindi, si può affermare che il modello misura le prestazioni del progetto QEST-PRJ01. Per realizzare il processo di estrazione è stata inizializzata la sorgente DS-XML che prevede il recupero manuale dei dati dal documento XML. Con il termine manuale si vuole specificare che tale operazione non avviene automaticamente a scadenze prestabilite ma è compito dell amministratore eseguirla quando necessario. Questa scelta è stata fatta esclusivamente per gli esempi. In Spago4Q è altrimenti disponibile una sorta di refresh automatico dei dati che può essere impostato ad intervalli adatti alle proprie esigenze (ad esempio, una settimana, un mese,...). Successivamente è stata realizzata la tabella dei fatti (denominata ft qest direct metrics); per essere idonea all immagazzinamento dei valori estratti dalla sorgente, i suoi campi

99 4.1. Primo Caso d Uso 90 aggiuntivi devono essere in rapporto 1:1 con i figli del tag GenericItem e congruenti come tipo di dati. Per chiarezza, alle colonne della tabella è stato dato lo stesso nome dei tag. Dopo aver creato le corrispondenze tra i nodi del file.xml ed i campi della tabella, il risultato ottenuto è mostrato in Figura 4.5. I campi Begin Time ed End Time indicano il periodo di validità della misura inserita. Figura 4.5: La tabella ft qest direct metrics Non avendo fatto ulteriori estrazioni, la data finale non è presente ed i valori non hanno una scadenza. Qualora si inseriscano nuovi valori, verrà aggiunta la data relativa al giorno precedente l operazione nel campo End Time e sarà inserito un nuovo record con il Begin Time avente data odierna e valore aggiornato Step 5 - Calcolo dei Valori delle Metriche Per il calcolo dei valori delle metriche è stata realizzata una query in linguaggio MySQL: SELECT FT.VALUE as value FROM FT_QEST_DIRECT_METRICS FT WHERE FT.RESOURCE = $P{ParKpiResource} AND FT.METRIC = (SELECT kpi.code FROM SBI_KPI_INSTANCE inst, SBI_KPI kpi WHERE inst.id_kpi_instance = $P{ParKpiInstance} AND kpi.kpi_id = inst.kpi_id) AND (FT.BEGIN_TIME <= str_to_date(concat($p{parkpidate}, 23:59:59 ), %d/%m/%y %H:%i:%s ) AND (str_to_date(concat($p{parkpidate}, 23:59:59 ), %d/%m/%y %H:%i:%s ) < FT.END_TIME or FT.END_TIME is null));

100 4.1. Primo Caso d Uso 91 Tradotto in linguaggio naturale, il dataset preleva da ft qest direct metrics il valore, alla data stabilita, della metrica avente il codice presente nella risorsa QEST-PRJ01. Il nome della risorsa e la data sono parametri da inserire, scegliendo tra le opzioni disponibili, prima dell esecuzione del documento, come si vedrà più avanti. Questi parametri sono poi catturati dai driver analitici $P {P arkpiresource} e $P {P arkpidate} che si occupano di istanziarli nella query. Il valore prelevato è relativo alla metrica a cui viene associato il dataset. Al codice si giunge prelevando il suo id dalla tabella sbi kpi e facendo un join con la sbi kpi instance. Ovviamente, per una metrica possono corrispondere più valori per via delle molteplici misurazioni effettuate. Questo problema si aggira con la data. Il valore restituito deve essere esattamente quello valido al giorno inserito mediante il driver; in altre parole, la sua data di inizio validità deve essere minore od uguale di quella immessa dall utente, a sua volta antecedente alla data di fine validità Step 6 - Calcolo del Valore delle Dimensioni Per calcolare il valore delle dimensioni sono state utilizzate tre classi Java, una per ogni prospettiva. MySQL, infatti, non è sufficientemente flessibile per eseguire l espressione vista nel Paragrafo Tralasciando il codice relativo all import delle librerie e ad altre funzionalità, la parte relativa alla mera implementazione della formula è la seguente: Double totaldimensionvalue = 0.0; Double value = 0.0; double[] weight = {0.25, 0.15, 0.05, 0.3}; Integer nweight = 0; List<KpiValue> values = getkpivalueofmodelinstancechildren(map); for (KpiValue kpivalue : values) { if (kpivalue.getvalue()!= null){ value = new Double(kpiValue.getValue()); totaldimensionvalue += value * weight[nweight]; } nweight++; } Le variabili totaldimensionvalue e value devono contenere rispettivamente il valore finale della dimensione ed il valore di ciascuna metrica calcolata nello step precendente. Nell array weight invece sono stati inseriti i pesi delle misure. Il metodo getkpivalueofmodelinstancechildren() preleva i valori delle metriche figlie e li

101 4.1. Primo Caso d Uso 92 immette nella List values. Tramite il ciclo for vengono scandite la lista e l array e, ad ogni valore trovato, se ne moltiplica la misura con il suo peso (value * array[posizionearray]). Al termine di ogni iterazione viene aggiornata la variabile totaldimensionvalue; questo meccanismo si ripete fino al termine dell iterazione, dopodiché la classe restituisce il risultato finale per la dimensione. Il codice mostrato sopra si riferisce alla classe QestDimensionEcon.java, che si differenzia dalle classi QestDimensionTecn.java e QestDimensionSoc.java solo per i pesi contenuti nell array Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Il calcolo delle dimensioni con il Quality Factor è stato implementato direttamente nello step successivo, all interno del dataset per il calcolo della performance, con il seguente codice: totaldimensionsvalue *= 1 - (dimensionvalue + qualityfactor). Prima di moltiplicare il complemento ad 1 di ciascun punto di vista, avviene la somma tra il valore ed il QF. Inglobando questi due passaggi il codice sarà più compatto e performante con risparmio di tempo di realizzazione, di configurazione del modello e di esecuzione dello stesso Step 8 - Calcolo del Valore di Performance Il valore di performance è stato computato con la classe QestKpiDataset.java, correlata all indicatore QEST-KPI. La parte più importante del codice è la seguente: Double totaldimensionsvalue = 1.0; Double dimensionvalue = 0.0; List<KpiValue> values = getkpivalueofmodelinstancechildren(map); String DSLabel = "SpagoBI"; String statement = "SELECT value FROM ft_qest_direct_metrics f WHERE metric = QEST-Quality factor "; String value = ""; Double qualityfactor = 0.0; if (value.isempty() == false) qualityfactor = Double.parseDouble(value);

102 4.1. Primo Caso d Uso 93 for (KpiValue kpivalue : values) { if (kpivalue.getvalue()!= null){ dimensionvalue = new Double(kpiValue.getValue()); totaldimensionsvalue *= 1 - (dimensionvalue + qualityfactor); numberofchildren ++; } } Il funzionamento dell algoritmo è del tutto simile al dataset visto nello step 6. Le uniche differenze sono: l estrazione del QF mediante la query contenuta nella variabile statement - come già anticipato, la somma tra i valori del Quality Factor e delle dimensioni avviene dentro questa classe. Il risultato della query si inserisce nella variabile value e con il metodo isempty() viene accertato che sia stato effettivamente trovato il valore del QF. Nel caso quest ultimo non sia presente, la variabile qualityfactor varrà 0 ed il KPI finale sarà al 100% costituito da indicatori quantitativi; La formula di calcolo: totaldimensionsvalue *= 1 - (dimensionvalue + qualityfactor) Step 9 - Realizzazione dei Report Il report realizzato riporta i valori dell indicatore globale e delle dimensioni ed è associato alla metrica QEST-KPI, l indicatore di performance. I risultati sono visibili sia testualmente che graficamente in un istogramma. Per estrarre i dati di interesse è stata implementata la query in Figura 4.6. In sostanza, si prelevano il codice ed i valori di indicatore globale e dimensioni dalla tabella sbi kpi value con il vincolo che siano tutti appartenenti alla stessa istanza di modello ed abbiano la stessa data di calcolo. I parametri, rappresentati dal punto interrogativo, sono tre e ricevono sempre lo stesso valore, ossia il numero identificativo, o id, che QEST-KPI ha in questa istanza del modello. Il grafico che ne deriva è visualizzabile in Figura 4.7. Sull asse dell ascissa è disposta la scala dei valori, sull ordinata il codice delle metriche rappresentate; il loro valore effettivo è all interno della barra che ne sancisce il posizionamento nell istogramma Esecuzione e Visualizzazione Dopo aver avviato la funzione di sviluppo del documento ed aver selezionato la data di interesse dal menù dei parametri in Figura 4.8, si ottiene il modello completo di risultati, posizionamento sulle soglie ed informazioni sull andamento storico dei KPI.

103 4.1. Primo Caso d Uso 94 SELECT kpi.code, CAST(kpi_value.value AS decimal(10,4)) AS VALUE FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi WHERE kpi_value.id_kpi_instance_value =? AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance UNION SELECT kpi.code, CAST(kpi_value.value AS decimal(10,4)) AS VALUE FROM sbi_kpi_model_inst model_inst, sbi_kpi_model model, sbi_kpi_instance kpi_inst, sbi_kpi kpi, sbi_kpi_value kpi_value WHERE model_inst.kpi_model_inst_parent = (SELECT model_inst.kpi_model_inst FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst WHERE kpi_value.id_kpi_instance_value =? AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance) AND model.kpi_model_id = model_inst.kpi_model_id AND kpi_inst.id_kpi_instance = model_inst.id_kpi_instance AND kpi_inst.kpi_id = kpi.kpi_id AND kpi_value.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.begin_dt = ( SELECT kpi_value.begin_dt FROM sbi_kpi_value kpi_value WHERE kpi_value.id_kpi_instance_value =?) Figura 4.6: Query SQL per il report del primo caso d uso

104 4.1. Primo Caso d Uso 95 Figura 4.7: Il grafico della performance di progetto Figura 4.8: Driver analitici per l esecuzione del documento La dimensione economica è riportata in Figura 4.9. L andamento di questa prospettiva è purtroppo insufficiente: il valore (della metrica QEST-E-KPI) non raggiunge infatti il valore minimo richiesto. La causa di questo fallimento è riconducibile al valore, decisamente negativo, del tasso di produzione; il suo peso elevato, poi, aumenta l impatto avverso sulla qualità totale della dimensione. Gli altri risultati, tutti positivi, rendono comunque il passivo meno pesante: basterà migliorare il tasso di produzione nel prossimo ciclo per arrivare, con ogni probabilità, immediatamente alla soglia accettabile. In Figura 4.10 è presentato l andamento della dimensione sociale. Il risultato di quest area è decisamente positivo: tutte le misure hanno ottenuto dei valori

105 4.1. Primo Caso d Uso 96 Figura 4.9: I risultati della dimensione economica di soglia accettabili; di conseguenza anche l indicatore di dimensione è in salute. Stando a questi dati, il progetto avrà sicuramente un impatto positivo sulla maggioranza degli utenti finali: piccole difficoltà si potrebbero presentare solamente a persone con bassa istruzione ed assoluta mancanza di esperienza. Come da Figura 4.11, anche per la dimensione tecnica sono stati riscontrati risultati Figura 4.10: I risultati della dimensione sociale incoraggianti. Tutte le misure hanno ottenuto dei valori di soglia accettabili; di conseguenza anche l indicatore di dimensione. A differenza della dimensione sociale, però, la positività non è così netta. Il motivo è una presenza, comunque positiva ma da rivedere, del numero di difetti rilevati nel codice. Come nel caso del tasso di produzione, anche il peso di questa misura gioca un ruolo fondamentale nel calcolo del valore di dimensione: con lo 0.4 infatti, influisce oltre il 50% sul risultato finale. Pertanto, nel prossimo ciclo si dovrebbero diminuire ancora i difetti riscontrati in fase di

106 4.2. Secondo Caso d Uso 97 scrittura del codice. La convergenza delle tre dimensioni nell indicatore unico produce il risultato della Figura Figura 4.11: I risultati della dimensione tecnica Il valore 0,7282 si posiziona nell intervallo intermedio (colore giallo): l andamento dell intero progetto è accettabile ma migliorabile. Il risultato ideale dovrebbe essere almeno di E evidente che la qualità generale è frenata dall area economica, che in base alla precedente analisi, è ben sotto le aspettative. Riassumendo, aumentando il numero di funzioni implementate in un determinato arco Figura 4.12: Il risultato di performance globale temporale e diminuendo i difetti del codice, nel prossimo ciclo di miglioramento si potrà rafforzare la qualità della dimensione tecnica e capovolgere quella dell area economica da negativa a positiva per aggiungere quei 0.13 punti mancanti per raggiungere l obiettivo prefissato: un buon valore di qualità per il progetto. 4.2 Secondo Caso d Uso Il secondo modello è stato utilizzato per misurare la performance di tre progetti di Business Service di medio-grandi dimensioni. Proprio per il loro protrarsi nel tempo, è stato necessario effettuare diverse misurazioni per monitorare costantemente l evolversi della situazione ed intervenire sulla qualità passo dopo passo, anziché a progetto concluso. In questo modo si risparmiano risorse economiche e temporali: correggere i difetti nella fase finale dello sviluppo è infatti più svantaggioso. La realizzazione dei progetti ha avuto una durata di tre mesi e per ognuno sono stati

107 4.2. Secondo Caso d Uso 98 eseguiti rilevamenti mensili. In questo caso d uso è stato inoltre sperimentato, parallelamente a quello tradizionale, un processo di misurazione che non prevede la definizione di pesi per le misure ma soltanto per gli indicatori di dimensione. Pertanto alcuni step saranno ulteriormente ramificati, se necessario, per descrivere l andamento di entrambi e confrontare le differenze tra i due approcci Step 1 - Definizione del Modello e dei KPI Il modello generico, denominato Business-Service-Model, è visibile in Figura Il suo scopo è fornire la struttura di partenza da cui creare istanze specifiche, attraverso la selezione dei nodi corrispondenti alle aree ed alle misure da coinvolgere nella valutazione della performance. Per tutti e tre i progetti vale ovviamente questo modello e le istanze relative (una per la misurazione standard, l altra per quella senza pesi) sono un esatta replica dello stesso (Figura 4.14). Il motivo di questa scelta è dovuto al fatto che, non essendo presenti calcoli incrociati tra metriche, non si crea nessuna ridondanza di informazioni ma, al contrario, è necessario includere tutti i nodi per non causare perdite di dati necessari alla misurazione. Come si può vedere, sono presenti anche i KPI, debitamente associati a tutti i rami del livello measure. Di seguito l elenco completo degli indicatori impiegati (con il loro scopo): QEST-KPI-BS (indicatore globale di performance) QEST-EC (indicatore di performance economica) QEST-RS (indicatore di performance delle risorse) QEST-TE (indicatore di performance tecnica) QEST-CS (indicatore di performance della soddisfazione utenti) QEST-EC-1 (Tasso di utilizzo per servizio/prodotto) QEST-EC-2 (Tasso costo dei servizi di supporto per servizio di business) QEST-EC-3 (Tasso costo dei servizi di sviluppo CR per servizio di business) QEST-RS-1 (Tasso di disponibilità per servizio/prodotto) QEST-RS-2 (Tasso turnover risorse) QEST-RS-3 (Tasso issue su risorse non risolte nei tempi previsti) QEST-TE-1 (Complessità ciclomatica media) QEST-TE-2 (Tasso rilievi gravi su qualità documentazione) QEST-TE-3 (Tasso non conformità regole di coding) QEST-TE-4 (Tasso non conformità regolo object-oriented)

108 4.2. Secondo Caso d Uso 99 Figura 4.13: Il modello Business-Service-Model e la sua istanza

109 4.2. Secondo Caso d Uso 100 QEST-TE-5 (Difettosità applicazioni in esercizio) QEST-TE-6 (Tempestività di ripristino) QEST-TE-7 (Tasso di slittamento delle milestones) QEST-TE-8 (Tasso di produttività) QEST-TE-9 (Tasso di variabilità dell applicazione) QEST-TE-10 (Tasso di copertura dei test vs. requisiti) QEST-TE-11 (Difettosità nel deploy) QEST-TE-12 (Frequenza installazione patch o release) QEST-CS-1 (Tasso di training) QEST-CS-2 (Tasso di soddisfazione utenti (supporto tecnico, help,...) QEST-CS-3 (Tasso di usabilità) Step 2 - Definizione dei Pesi e delle Soglie Prima Istanza In Figura 4.14 è visibile la lista completa di pesi, soglie e misure con le rispettive corrispondenze. Come si può notare, agli indicatori di performance delle dimensioni (QEST-EC per quella economica, QEST-RS per quella delle risorse, QEST-TE per quella tecnica, QEST-CS per quella della soddisfazione utenti) è stato attribuito un peso pari a 1. Questo significa che, in una scala percentuale da 0 a 100, i valori quantitativi assumono un peso del 100% sul calcolo del valore finale di prestazione escludendo di fatto la valutazione qualitativa. Analizzando le varie prospettive si osserva, inoltre, che i KPI che contribuiscono maggiormente al raggiungimento del peso complessivo sono: per l area economica, QEST-EC-2 e QEST-EC-3 (entrambe con un peso di 0.4); per l area delle risorse, QEST-RS-1 (con peso di 0.7); per l area utenti, QEST-CS-2 e QEST-CS-3 (con peso di 0.6 e 0.3). per l area tecnica, QEST-TE-5 (con peso di 0.15). Obiettivamente, non è un valore importante ma nello specifico è quello che spicca sugli altri, seppur di poco. I pesi degli indicatori dell area tecnica sono infatti molto omogenei. Tutte le soglie hanno tre intervalli ad eccezione di quella usata in QEST-TE-6 che ne ha due. Il numero posto vicino il confine di ogni sezione indica il valore minimo che il KPI deve assumere per posizionarsi in quel determinato intervallo (giallo o verde).

110 4.2. Secondo Caso d Uso 101 Tali cifre sono state inserite sulle soglie per dare più informazioni possibili in modo compatto; in Spago4Q si possono visualizzare soltanto attraverso la funzione Threshold Value List. Dai dati relativi a questo step si può constatare che, a differenza del primo esempio, dagli indicatori con un peso maggiore non si attende sempre un valore minimo di accettabilità più elevato rispetto a quelli meno influenti. Questo aspetto si nota soprattutto nella dimensione tecnica ed in quella utenti, dove la metrica QEST-CS-3, con peso 0.3, ha un valore minimo positivo più alto di QEST-CS-2, con peso Seconda Istanza Come anticipato nell introduzione, alle metriche di questa istanza non sono stati attribuiti pesi se non agli indicatori globali di dimensione. Rispetto alla Figura 4.14 si avranno quindi le stesse soglie per tutte le metriche ed il peso pari ad 1 per QEST-EC, QEST-RS, QEST-TE e QEST-CS Step 3 - Definizione del Quality Factor Se ai KPI quantitativi è stato attributo un peso del 100%, è facile dedurre che il Quality Factor non è stato preso in considerazione in questo secondo caso d uso. Da un punto di vista matematico il suo valore sarà quindi pari a 0.0, con un peso dello 0% nel calcolo del valore di performance Step 4 - Raccolta delle Misure Le misure sono state estratte da un file.xml dove erano strutturate nel seguente modo: <?xml version="1.0" encoding="utf-8"?> <GenericItems> <GenericItem> <resource>nome_risorsa</resource> <metric>codice_metrica</metric> <value>valore</value> <Rmin>valore_minimo_normalizzazione</Rmin> <Rmax>valore_massimo_normalizzazione</Rmax> </GenericItem> <GenericItem>... </GenericItem>... </GenericItems>

111 4.2. Secondo Caso d Uso 102 Figura 4.14: I pesi e le soglie di ciascun KPI del modello Business-Service-Model Il tag Resource contiene il nome fittizio assegnato al progetto con lo scopo di non mischiare le misure di altre risorse presenti nel data warehouse durante i calcoli. Da questo momento quindi, si può affermare che il modello misura le prestazioni dei progetti PRJ01, PRJ02 e PRJ03. Rmin e Rmax contengono invece la soglia minima e massima da inserire nella formula per normalizzare i valori delle metriche. Data l enorme quantità di dati raccolti (un estrazione al mese, per tre mesi, per tre progetti) si è preferito riassumerli in tabelle invece di mostrare la lunga e ripetitiva sequenza della struttura del file.xml. Il riepilogo è consultabile nelle Figure 4.15, 4.16 e Per realizzare il processo di estrazione è stata utilizzata la sorgente DS-XML già istanziata per il primo caso d uso. Successivamente è stata realizzata la tabella dei fatti (denominata ft qest business service); per essere idonea all immagazzinamento dei valori estratti dalla sorgente, i suoi campi aggiuntivi devono essere in rapporto 1:1 con i figli del tag GenericItem e congruenti come tipo di dati. Per chiarezza, alle colonne della tabella è stato dato lo stesso nome dei tag. Dopo aver creato le corrispondenze tra i nodi del file.xml ed i campi della tabella, il risultato otte-

112 4.2. Secondo Caso d Uso 103 Figura 4.15: I dati del primo mese nuto è mostrato in Figura I campi Begin Time ed End Time indicano il periodo di validità della misura inserita. Ad ogni inserimento, verrà aggiunta la data relativa al giorno precedente l operazione nel campo End Time e sarà inserito un nuovo record con il Begin Time avente data odierna e valore aggiornato Step 5 - Calcolo dei Valori delle Metriche Il calcolo dei valori delle metriche si basa sulla query scritta in linguaggio MySQL usata nel precedente caso d uso e ripresentata di seguito: SELECT FT.VALUE as value FROM FT_QEST_BUSINESS_SERVICE FT WHERE FT.RESOURCE = $P{ParKpiResource} AND FT.METRIC = (SELECT kpi.code FROM SBI_KPI_INSTANCE inst, SBI_KPI kpi WHERE inst.id_kpi_instance = $P{ParKpiInstance} AND kpi.kpi_id = inst.kpi_id) AND (FT.BEGIN_TIME <= str_to_date(concat($p{parkpidate}, 23:59:59 ), %d/%m/%y %H:%i:%s ) AND (str_to_date(concat($p{parkpidate}, 23:59:59 ), %d/%m/%y %H:%i:%s ) < FT.END_TIME or FT.END_TIME is null));

113 4.2. Secondo Caso d Uso 104 Figura 4.16: I dati del secondo mese Traducendo in linguaggio naturale, il dataset preleva da ft qest business service il valore, alla data stabilita, della metrica avente il codice presente nella risorsa stabilita. Il nome della risorsa e la data sono parametri da inserire, scegliendo tra le opzioni disponibili, prima dell esecuzione del documento, come si vedrà più avanti. Questi parametri sono poi catturati dai driver analitici $P {P arkpiresource} e $P {P ar KpiDate} che si occupano di istanziarli nella query. Il valore che restituisce è relativo alla metrica a cui viene associato il dataset. Al codice si giunge prelevando il suo ID dalla tabella SBI KPI e facendo un join con la SBI KPI INSTANCE. Ovviamente, per una metrica possono corrispondere più valori per via delle molteplici misurazioni effettuate. Questo problema si aggira con la data. Il valore restituito deve essere esattamente quello valido al giorno selezionato mediante il driver; in altre parole, la sua data di inizio validità deve essere minore od uguale di quella immessa dall utente, a sua volta antecedente la data di fine validità. Mentre nel primo esempio è stato sufficiente il codice visto sopra, in questo caso d uso il dataset subisce una variazione: dopo la parola privata SELECT, FT.VALUE non viene solamente estratto, ma incluso dentro la formula di normalizzazione dei valori vista nei capitoli precedenti (Paragrafo ). Ora, non tutte le metriche qui presenti hanno gli stessi range da immettere; sono stati quindi realizzati tanti dataset quanti i valori differenti di minimo e massimo individuati. Alcuni indicatori inoltre, per essere normalizzati correttamente, sono stati anche convertiti nel proprio complemento ad 1 per far sì che il risultato accettabile fosse verso il limite

114 4.2. Secondo Caso d Uso 105 Figura 4.17: I dati del terzo mese Figura 4.18: La tabella ft qest business service 1 della soglia e non verso lo 0 (come nel loro valore assoluto). Tutte queste combinazioni hanno portato alla creazione di otto query di cui è riportata solo la parte comprensiva di FT.VALUE essendo l unica che varia rispetto all algoritmo visto sopra: SELECT 1 - (FT.VALUE - 0) / (100-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 100, poi ne fa il complemento ad 1. Questo dataset è usato dalle metriche QEST-EC-2,

115 4.2. Secondo Caso d Uso 106 QEST-EC-3, QEST-TE-1, QEST-TE-8 e QEST-TE-9. SELECT 1 - (FT.VALUE - 0) / (12-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 12, poi ne fa il complemento ad 1. Questo dataset è usato dalla metrica QEST-TE-2. SELECT 1 - (FT.VALUE - 0) / (24-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 24, poi ne fa il complemento ad 1. Questo dataset è usato dalla metrica QEST-TE-6. SELECT 1 - (FT.VALUE - 0) / (30-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 30, poi ne fa il complemento ad 1. Questo dataset è usato dalla metrica QEST-TE-12. SELECT 1 - (FT.VALUE - 0) / (5-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 5, poi ne fa il complemento ad 1. Questo dataset è usato dalla metrica QEST-TE-5. SELECT 1 - (FT.VALUE - 0) / (8-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 8, poi ne fa il complemento ad 1. Questo dataset è usato dalla metrica QEST-TE-11. SELECT (FT.VALUE - 0) / (100-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 100. Questo dataset è usato dalle metriche QEST-EC-1, QEST-RS-1, QEST-RS-2, QEST-RS-3, QEST-TE-3, QEST-TE-4, QEST-TE-7, QEST-CS-1, QEST-CS2 e QEST-CS-3. SELECT (FT.VALUE - 0) / (500-0) as value normalizza un valore con range minimo pari a 0 e range massimo pari a 500. Questo dataset è usato dalla metrica QEST-TE Step 6 - Calcolo del Valore delle Dimensioni Prima Istanza Per calcolare il valore delle dimensioni sono state utilizzate quattro classi Java, una per ogni prospettiva. MySQL, infatti, non è sufficientemente flessibile per eseguire l espressione vista nel Paragrafo Tralasciando il codice relativo all import delle librerie e ad altre funzionalità, la parte relativa all implementazione della formula è la seguente: Double totaldimensionvalue = 0.0; Double value = 0.0;

116 4.2. Secondo Caso d Uso 107 double[] weight = {0.1, 0.6, 0.3}; Integer nweight = 0; List<KpiValue> values = getkpivalueofmodelinstancechildren(map); for (KpiValue kpivalue : values) { if (kpivalue.getvalue()!= null){ value = new Double(kpiValue.getValue()); totaldimensionvalue += value * weight[nweight]; } nweight++; } Le variabili totaldimensionvalue e value devono contenere rispettivamente il valore finale della dimensione ed il valore di ciascuna metrica calcolata nello step precendente. Nell array weight invece sono stati inseriti i pesi delle misure. Il metodo getkpivalueofmodelinstancechildren() preleva i valori delle metriche figlie e li immette nella List values. Tramite il ciclo for vengono scandite la lista e l array e, ad ogni valore trovato, se ne moltiplica la misura con il suo peso (value * weight[nweight]). Al termine di ogni iterazione viene aggiornata la variabile totaldimensionvalue; questo meccanismo si ripete per tutti gli elementi estratti, dopodiché la classe restituisce il risultato finale per la dimensione. Il codice mostrato sopra si riferisce alla classe QestDimensionCS.java, che si differenzia dalle classi QestDimensionEC.java, QestDimensionRS.java e QestDimensionTE.java solo per i pesi contenuti nell array. Questi dataset sono stati associati rispettivamente alle metriche QEST-CS, QEST-EC, QEST-RS e QEST-TE Seconda Istanza Per la seconda istanza è stata implementata la classe QestDimensionBS.java. La differenza sostanziale con le classi della prima istanza sta nell assenza dell array contenente i pesi delle metriche. Il valore della dimensione non è infatti una somma pesata bensì una media aritmetica. E proprio questo approccio che rende questo esempio sperimentale. Di seguito è riportata la parte di codice che esegue il calcolo: Integer numberofchildren = 0; Double totaldimensionvalue = 0.0; Double goalvalue = 0.0; Double toreturn = 0.0; List<KpiValue> values = getkpivalueofmodelinstancechildren(map);

117 4.2. Secondo Caso d Uso 108 for (KpiValue kpivalue : values) { if (kpivalue.getvalue()!= null){ goalvalue = new Double (kpivalue.getvalue()); totaldimensionvalue += goalvalue; numberofchildren ++; } } if (numberofchildren!= 0) toreturn = totaldimensionvalue / numberofchildren; Le variabili totaldimensionvalue e goalvalue devono contenere rispettivamente il valore finale della dimensione ed il valore di ciascuna metrica calcolata nello step precendente. toreturn include il risultato finale che viene visualizzato nel modello. Il metodo getkpivalueofmodelinstancechildren() preleva i valori delle metriche figlie e li immette nella List values. Tramite il ciclo for viene scandita la lista ed ogni valore trovato si aggiunge in totaldimensionvalue (totaldimensionvalue += goalvalue). Al termine di ogni iterazione viene aggiornata la variabile numberofchildren, che immagazzina il numero dei KPI figli; questo meccanismo si ripete fino al termine del ciclo, dopodiché viene calcolata la media dividendo il valore finale della dimensione per il numero di metriche sottostanti (totaldimensionvalue / numberofchildren). Il risultato finale è memorizzato in toreturn e restituito al modello. Usufruiscono di questo dataset le metriche QEST-CS, QEST-EC, QEST-RS e QEST-TE Step 7 - Calcolo del Valore delle Dimensioni con Quality Factor Il calcolo delle dimensioni con il Quality Factor è stato omesso in entrambe le istanze, non essendo stato considerato in questo caso d uso. Si sarebbe comunque potuto effettuare un controllo sul database per cercarne il valore ed assegnare 0.0 alla variabile qualityfactor se non si fosse trovata nessuna corrispondenza. Conoscendo in anticipo il risultato dell operazione, è stato tralasciato questo passaggio per non gravare sul tempo di esecuzione dei calcoli Step 8 - Calcolo del Valore di Performance Il valore di performance è stato computato con la classe QestKpiBS.java, correlata all indicatore QEST-KPI-BS. La parte più importante del codice è la seguente: Double totaldimensionsvalue = 1.0; Double dimensionvalue = 0.0;

118 4.2. Secondo Caso d Uso 109 List<KpiValue> values = getkpivalueofmodelinstancechildren(map); for (KpiValue kpivalue : values) { if (kpivalue.getvalue()!= null){ dimensionvalue = new Double(kpiValue.getValue()); totaldimensionsvalue *= (1 - dimensionvalue); } } Il funzionamento dell algoritmo è del tutto simile al dataset visto nello step 6 (Paragrafo ). L unica differenza è nella formula di calcolo totaldimensionsvalue *= (1 - dimensionvalue), nella quale manca la somma tra il valore della dimensione ed il Quality Factor Step 9 - Realizzazione dei Report Per le due istanze di questo caso d uso sono stati realizzati cinque report per presentare la situazione dei progetti in modo più ampio e permettere una valutazione più dettagliata. Tutti i documenti sono associati all indicatore globale di performance QEST-KPI-BS. a) Performance di progetto e dimensioni Questo report restituisce le stesse informazioni di quello presentato nel primo caso d uso. Visto il numero di progetti valutabili coesistenti e le molteplici misurazioni effettuate nel tempo, la query ha subito alcune modifiche. Alle condizioni già viste se ne aggiunge una per controllare che i dati estratti siano effettivamente relativi alla risorsa in fase di osservazione. I parametri salgono a cinque: ai tre che ricevono l id della metrica QEST-KPI-BS se ne uniscono due per acquisire il nome del progetto (denominate ParKpiResource). La query implementata è mostrata in Figura 4.19: b) Trend mensile del progetto Obiettivo di questo report è mostrare un quadro riepilogativo dei valori di performance che un progetto ha fatto registrare nell arco del suo sviluppo, al termine di ciascun mese. Sul documento sono presentati la data dell ultima misurazione mensile, il codice dell indicatore globale ed il suo valore, ottenuti mediante la query in Figura La funzione max() serve ad individuare, all interno di un mese, il giorno più recente in cui sono stati immagazzinati i risultati nel data warehouse. I parametri inseriti sono due: il primo per passare l id della metrica QEST-KPI-BS all interrogazione, il secondo per acquisire il nome del progetto. Il grafico che ne deriva è visualizzabile in Figura 4.21 e fornisce un impatto immediato sui progressi (o regressi) della risorsa. Sull ascissa sono disposte le date significative per ogni mese di sviluppo, sull ordinata la scala dei valori; il loro valore effettivo è all interno delle barre dell istogramma.

119 4.2. Secondo Caso d Uso 110 SELECT kpi.code, CAST(kpi_value.value AS decimal(10,4)) AS VALUE FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi WHERE kpi_value.id_kpi_instance_value =? AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.resource_id = ( SELECT resource_id FROM sbi_resources WHERE resource_name =? ) UNION SELECT kpi.code, CAST(kpi_value.value AS decimal(10,4)) AS VALUE FROM sbi_kpi_model_inst model_inst, sbi_kpi_model model, sbi_kpi_instance kpi_inst, sbi_kpi kpi, sbi_kpi_value kpi_value WHERE model_inst.kpi_model_inst_parent = ( SELECT model_inst.kpi_model_inst FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst WHERE kpi_value.id_kpi_instance_value =? AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance ) AND model.kpi_model_id = model_inst.kpi_model_id AND kpi_inst.id_kpi_instance = model_inst.id_kpi_instance AND kpi_inst.kpi_id = kpi.kpi_id AND kpi_value.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.begin_dt = ( SELECT kpi_value.begin_dt FROM sbi_kpi_value kpi_value WHERE kpi_value.id_kpi_instance_value =? ) AND kpi_value.resource_id = ( SELECT resource_id FROM sbi_resources WHERE resource_name =? ) GROUP BY kpi.code Figura 4.19: Query SQL per il primo report

120 4.2. Secondo Caso d Uso 111 SELECT kpi.code, cast(kpi_value.value AS decimal(10,4)), max(kpi_value.begin_dt), month(kpi_value.begin_dt) month FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi WHERE kpi_inst.id_kpi_instance = ( SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =? ) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.resource_id = ( SELECT resource_id FROM sbi_resources WHERE resource_name =? ) GROUP BY month Figura 4.20: Query SQL per il secondo report Figura 4.21: Il grafico raffigurante il trend mensile del progetto

121 4.2. Secondo Caso d Uso 112 c) Trend mensile del progetto e delle rispettive dimensioni In questo report, oltre al trend del progetto è possibile visualizzare anche quello delle dimensioni. Alla query vista nel punto b si unisce quella per estrarre i valori dei nodi figli corrispondenti alle prospettive. A questi si arriva attraverso delle interrogazioni annidate che, partendo dall id del nodo padre (l indicatore globale), scandagliano l istanza fino a trovare le metriche ad esso collegate e ne restituiscono il numero identificativo. I parametri sono quattro: ai due della prima parte della query esplicata nel punto precedente, si uniscono altri due identici per la seconda parte. Il codice completo è visibile in Figura Il grafico relativo è visualizzabile in Figura 4.23; vista la considerevole quantità di dati da rappresentare è stato utilizzato un diagramma lineare. Sull ascissa sono disposti i mesi (espressi in numeri), sull ordinata la scala dei valori. I punti indicano il valore di ciascuna metrica (ognuna rappresentata da un colore diverso); le linee di collegamento mettono in risalto l andamento nel tempo. d) Confronto tra performance di progetti Con questo report si possono confrontare le performance dei progetti per vedere quale dei tre ha la migliore qualità. Nel documento sono presenti il nome della risorsa, quello dell indicatore globale ed il valore, recuperabili con la query in Figura Al suo interno, il parametro KPI VALUE ID è utilizzato due volte: la prima per trovare l id dell istanza in cui è presente l indicatore globale, la seconda per trovare la data in cui la metrica è stata misurata. Il grafico allegato è l istogramma in Figura Il nome dei progetti è posizionato sull asse x, la scala dei valori sull asse y; i valori effettivi sono visibili all interno delle barre. e) Confronto tra performance di progetti e dimensioni In questo report, il confronto coinvolge anche le dimensioni. Alla query vista nel punto d si unisce quella per estrarre i valori dei nodi figli corrispondenti alle prospettive. A questi si arriva attraverso delle interrogazioni annidate che, partendo dall id del nodo padre (l indicatore globale), scandagliano l istanza fino a trovare le metriche ad esso collegate e ne restituiscono il numero identificativo. I parametri sono quattro: ai due della prima parte della query si uniscono altri due identici per la seconda parte. Il codice SQL è in Figura Per lo stesso motivo presentato nel punto c, anche in questo report è stato utilizzato un grafico lineare (Figura 4.27). Il nome dei progetti è posizionato sull asse x, la scala dei valori sull asse y; i valori effettivi sono rappresentati dai punti colorati.

122 4.2. Secondo Caso d Uso 113 SELECT kpi.code, cast(kpi_value.value AS decimal(10,4)), kpi_inst.id_kpi_instance, max(kpi_value.begin_dt), month(kpi_value.begin_dt) month FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi WHERE kpi_inst.id_kpi_instance = ( SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =?) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND resource_id = (SELECT resource_id FROM sbi_resources WHERE resource_name =?) GROUP BY month UNION SELECT kpi.code, cast(kpi_value.value AS decimal(10,4)), kpi_inst.id_kpi_instance, max(kpi_value.begin_dt), month(kpi_value.begin_dt) month FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi WHERE kpi_inst.id_kpi_instance IN ( SELECT s.id_kpi_instance FROM sbi_kpi_model_inst s WHERE s.kpi_model_inst_parent = (SELECT kpi_model_inst FROM sbi_kpi_model_inst s WHERE id_kpi_instance = (SELECT kpi_inst.id_kpi_instance FROM sbi_kpi_instance kpi_inst WHERE kpi_inst.id_kpi_instance = (SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =? )))) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND resource_id = (SELECT resource_id FROM sbi_resources WHERE resource_name =?) GROUP BY month, kpi.code ORDER BY month, id_kpi_instance Figura 4.22: Query SQL per il terzo report

123 4.2. Secondo Caso d Uso 114 Figura 4.23: Il grafico rappresentante il trend mensile del progetto con le sue dimensioni Esecuzione e Visualizzazione Prima Istanza Dopo aver avviato la funzione di sviluppo del documento ed aver selezionato la data di interesse dal menù dei parametri in Figura 4.8, si ottiene il modello completo di risultati, posizionamento sulle soglie ed informazioni sull andamento storico dei KPI. Di seguito sono riportati e discussi gli esiti relativi ai tre progetti, mese per mese. a) Primo mese Dopo i primi trenta giorni i rispettivi indicatori globali restituiscono dei valori già molto alti, come si può vedere in Figura Tuttavia, analizzando le dimensioni, non mancano le imperfezioni. La risorsa PRJ01 ha lo di qualità ma la prospettiva economica è insufficiente. La causa è individuabile soprattutto nella metrica QEST-EC-3 (Tasso costo dei servizi di sviluppo CR per servizio di business) che con il suo 0.5 è lontana di ben 0.35 punti dalla soglia di accettabilità. Anche la metrica QEST-EC-2 (Tasso Costo dei servizi di supporto per servizio di business) influisce negativamente, ma in modo minore: il suo 0.75 può ritenersi comunque soddisfacente ma può essere migliorato. Di poco sotto la soglia di accettabilità è la dimensione tecnica: il motivo è riconducibile ad un leggero slittamento dalle milestone (QEST-TE-7).

124 4.2. Secondo Caso d Uso 115 SELECT sbi_resources.resource_name, kpi.code, cast(kpi_value.value as decimal(10,4)) FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi, sbi_resources WHERE kpi_inst.id_kpi_instance = (SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =?) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.begin_dt = (SELECT begin_dt FROM sbi_kpi_value WHERE id_kpi_instance_value =?) AND kpi_value.resource_id = sbi_resources.resource_id ORDER BY sbi_resources.resource_name Figura 4.24: Query SQL per il quarto report Figura 4.25: Il grafico di confronto tra le performance dei progetti

125 4.2. Secondo Caso d Uso 116 SELECT kpi.code, cast(kpi_value.value AS decimal(10,4)), sbi_resources.resource_name, kpi_inst.id_kpi_instance, kpi_value.resource_id FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi, sbi_resources WHERE kpi_inst.id_kpi_instance = (SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =? ) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.begin_dt = ( SELECT begin_dt FROM sbi_kpi_value WHERE id_kpi_instance_value =? ) AND kpi_value.resource_id = sbi_resources.resource_id GROUP BY sbi_resources.resource_name UNION SELECT kpi.code, cast(kpi_value.value AS decimal(10,4)), sbi_resources.resource_name, kpi_inst.id_kpi_instance, kpi_value.resource_id FROM sbi_kpi_value kpi_value, sbi_kpi_instance kpi_inst, sbi_kpi_model_inst model_inst, sbi_kpi kpi, sbi_resources WHERE kpi_inst.id_kpi_instance IN (SELECT s.id_kpi_instance FROM sbi_kpi_model_inst s WHERE s.kpi_model_inst_parent = (SELECT kpi_model_inst FROM sbi_kpi_model_inst s WHERE id_kpi_instance = (SELECT kpi_inst.id_kpi_instance FROM sbi_kpi_instance kpi_inst WHERE kpi_inst.id_kpi_instance = (SELECT id_kpi_instance FROM sbi_kpi_value WHERE id_kpi_instance_value =?)))) AND kpi.kpi_id = kpi_inst.kpi_id AND kpi_inst.id_kpi_instance = kpi_value.id_kpi_instance AND model_inst.id_kpi_instance = kpi_inst.id_kpi_instance AND kpi_value.resource_id = sbi_resources.resource_id AND kpi_value.begin_dt = ( SELECT kpi_value.begin_dt FROM sbi_kpi_value kpi_value WHERE kpi_value.id_kpi_instance_value =?) GROUP BY resource_name, kpi.code ORDER BY resource_name, id_kpi_instance Figura 4.26: Query SQL per il quinto report

126 4.2. Secondo Caso d Uso 117 Figura 4.27: Il grafico di confronto tra le performance di progetti e dimensioni Decisamente particolare è infine la situazione della prospettiva utenti: nonostante abbia tutti e tre gli indicatori al di sotto dell intervallo positivo (due sono comunque accettabili ed uno, il tasso di training, insufficiente) il suo risultato globale è in linea con le aspettative, probabilmente perché le stesse non sono molto alte. Dopo quest analisi, si può affermare che per il secondo mese gli obiettivi per PRJ01 saranno l abbattimento dei costi dei servizi, il rispetto delle scadenze di sviluppo e l innalzamento del tasso di training. La risorsa PRJ02 restituisce lo di qualità risultando di fatto la più in salute delle tre. Nel dettaglio però si può vedere che necessita addirittura di un numero di miglioramenti maggiore rispetto al primo progetto (Figura 4.28). Delle quattro dimensioni, solo quella utenti è pienamente in linea; le altre, comunque accettabili, devono migliorare nei prossimi mesi. Il GQM economico è di poco sotto il range positivo per via del tasso di utilizzo per servizio-prodotto (QEST-EC-1) che restituisce uno 0.5 accettabile ma da incrementare. Discorso analogo per il GQM tecnico: tuttavia la distanza dall intervallo verde è più netta per la maggior presenza di metriche sufficienti (tasso di slittamento dalle milestone, tasso di produttività, difettosità nel deploy, tasso di copertura dei test, tasso di variabilità dell applicazione) e di una pesantemente negativa, QEST-TE-4 (tasso di non conformità alle regole object oriented), che con il suo gap di 0.6 punti (0.3 ottenuti contro i 0.9 ottimali) è senza ombra di dubbio la peggiore dei tre progetti.

127 4.2. Secondo Caso d Uso 118 La dimensione risorse è quella che forse richiede i maggiori sforzi per il prossimo mese dato che presenta ben due indicatori insufficienti; se il tasso di incidenza delle issue sulle risorse (QEST-RS-3) non è comunque lontano dalla sufficienza, il tasso di disponibilità delle risorse hardware per servizio-prodotto (QEST-RS-1) deve recuperare almeno 0.3 punti per considerarsi decente. E quindi sui punti di vista tecnico e delle risorse che si dovrà provvedere maggiormente. Il terzo progetto, PRJ03, è quello peggiore seppure pienamente positivo con il suo Figura 4.28: Prima istanza: i tre progetti dopo il primo mese (Figura 4.28). Il motivo è da ricercare nella presenza dei molti valori insufficienti: è l unica risorsa, tra le tre, ad averne almeno uno per dimensione (nella dimensione tecnica ne ha ben quattro). Nonostante tutto, le dimensioni utenti e risorse hanno ottenuto dei risultati molto buoni: nel primo caso l insufficienza del tasso di usabilità (QEST-CS-3) non intacca il buon valore della prospettiva in quanto minima (appena 0.05 punti), nel secondo caso l incidenza delle issue sulle risorse (QEST-RS-3), benché abbia appena lo 0.1 di qualità, è ben compensato dalla positività delle risorse disponibili e dell incidenza del turnover. La stessa cosa non è però riuscita nella dimensione economica: lo 0.25 di tasso di utilizzo (QEST-EC-1) è decisamente difficile da compensare nonostante gli ottimi riscontri delle altre metriche di questa prospettiva. Il risultato finale per l aspetto economico è uno tuttavia accettabile. Ben più grave la situazione tecnica: di dodici indicatori, solo quattro raggiungono la positività; i restanti sono equamente suddivisi tra accettabili ed insufficienti. Rientrano in quest ultimo giudizio: il tasso di rilievi gravi sulla qualità della documentazione con lo 0.25 (QEST-TE-2), la tempestività di ripristino con lo 0.33 (QEST-TE-6), il tasso di slittamento delle milestone (QEST-TE-7), che con lo 0.5 è quello che tra i quattro si discosta di più dalla soglia di accettabilità, la difettosità nel deploy (QEST-TE-11) con lo

128 4.2. Secondo Caso d Uso 119 Inutile dire che il valore globale della dimensione è negativa (0.5887) ma non molto distante dalla sufficienza, grazie al poco peso di queste metriche. b) Secondo mese In Figura 4.29 sono riportati i risultati dei tre progetti al termine del secondo mese di lavoro. La risorsa PRJ03, che dopo i rilevamenti dei primi trenta giorni era la peggiore, Figura 4.29: Prima istanza: i tre progetti dopo il secondo mese risulta ora quella più performante con il suo I valori globali degli altri progetti sono invariati; tutti e tre sono comunque positivi. Il PRJ01 ha avuto un incremento della qualità delle dimensioni già positive ma un decremento di quelle che sarebbero dovute migliorare. Questa regressione è evidente soprattutto nella dimensione economica: dallo 0.66 del primo mese si è passati allo 0.51, segno evidente di una errata strategia. L incidenza dei costi dei servizi di supporto (QEST-EC-2) è scesa di 0.2 punti; se prima il valore era accettabile, ora è decisamente insufficiente. Anche i costi dei servizi di sviluppo CR per i servizi di business (QEST-EC-3) hanno continuato a crescere. La metrica ora registra lo 0.35 contro lo 0.5 del mese scorso. I valori negativi su cui provvedere il prossimo mese saranno ora due. Nella dimensione tecnica è peggiorato il rispetto delle scadenze dei milestone. Lo 0.78 registrato spinge nell intervallo cattivo la metrica QEST-TE-7. Complessivamente però, la prospettiva mantiene un giudizio accettabile scendendo di appena 0.05 punti. La situazione particolare vista il primo mese nella dimensione utenti, con la positività raggiunta attraverso due metriche sufficienti ed una insufficiente, si è verificata anche questa volta. La differenza però è nell indicatore negativo: non è più il tasso di training (QEST-CS-1), che è riuscito a raggiungere la soglia di accettabilità, ma il tasso di usabilità (QEST-CS-3) che con lo 0.83 ha perso quasi un decimo della qualità divenendo non buono.

129 4.2. Secondo Caso d Uso 120 Il PRJ02 ha mantenuto le sue dimensioni negli stessi intervalli, con variazioni minime. E importante però segnalare il miglioramento della prospettiva risorse, che ha reagito piuttosto bene ai risultati precedenti con un incremento della qualità dello Le metriche QEST-RS-1 e QEST-RS-3, anche se ancora insufficienti, si stanno avvicinando alla soglia di accettabilità. La prima delle due, in particolare, (tasso della disponibilità di risorse hardware per servizio-prodotto) è migliorata di 0.1. Nella dimensione tecnica ha fatto registrare un eccezionale progressione il tasso di conformità alle regole object oriented (QEST-TE-4): ancora negativo, ma con un incremento dello La maggioranza delle metriche tecniche ha fatto registrare un trend positivo, portando un globale. Queste erano comunque in una buona posizione anche il mese prima. Il PRJ03 ha fatto registrare le prestazioni migliori: la dimensione tecnica, negativa alla prima misurazione, ha ora raggiunto l accettabilità riducendo le metriche negative da quattro a tre e registrando un valore di (+ 0.07). La difettosità del deploy (QEST- TE-11) ha raggiunto una qualità accettabile, migliorando di punti. Le metriche QEST-TE-6 e QEST-TE-7 sono ancora negative ma progredite, mentre QEST-TE-2 ha perso 0.04 di qualità restando in zona rossa. Nella dimensione utente, l indicatore QEST-CS-3 guadagna 0.03 punti avvicinandosi ulteriormente alla sufficienza: ora ne mancano soltanto Per quanto riguarda il GQM economico, il tasso di utilizzo del servizio ha recuperato alla grande, raddoppiando il suo valore di qualità: da 0.25 a Grazie a questo risultato la metrica QEST-EC-1 esce dall elenco dei valori negativi, che scendono da sette del primo mese a cinque del secondo, e contribuisce all aumento della performance economica ( ). L ultimo indicatore insufficiente è QEST-RS-3, presente nella dimensione risorse; la sua posizione è comunque migliorata passando da 0.1 a 0.35, un perfezionamento notevole che la porta a sfiorare la sufficienza. c) Terzo mese Dopo il terzo rilevamento, coincidente con la fine dello sviluppo dei tre progetti, si hanno finalmente i risultati definitivi (Figura 4.30). Il PRJ01 ha concluso con una performance di , migliorando nettamente. Delle sue quattro dimensioni ha perso qualche centesimo soltanto quella tecnica, all interno della quale il rispetto della scadenza delle milestone (QEST-TE-3) è migliorata di 0.05 ma non è riuscita ad ottenere la sufficienza per un soffio. Altri piccole variazioni e la grossa perdita di qualità (0.2 punti) della metrica QEST-TE- 5, passata da un giudizio ottimo ad uno accettabile, hanno restituito un risultato finale di dimensione di ; valore tutto sommato buono, ma che ha registrato una perdita costante fin dal primo mese. La prospettiva risorse è l unica a chiudere con tutte le sue metriche in positivo; chiude ottimamente anche l area utenti con un incremento di 0.07 rispetto al secondo mese. Nonostante i grandi sforzi per recuperare la situazione poco rosea della dimensione economica, l aumento di 0.11 punti della propria qualità, di per sé molto buono, non è bastato

130 4.2. Secondo Caso d Uso 121 Figura 4.30: Prima istanza: i tre progetti dopo il terzo mese a raggiungere la sufficienza. I costi per i servizi di supporto hanno raggiunto l accettabilità con un , mentre il per la metrica QEST-EC-3 non ha prodotto lo stesso risultato, che è rimasta di fatto l unica negativa in questa dimensione e molto probabilmente ha trascinato con sé l intera area economica a causa del suo peso. Anche il progetto PRJ02 chiude con un miglioramento del raggiungendo lo Delle tre risorse è quella che ha ottenuto i maggiori progressi a livello di dimensione, chiudendo con tre giudizi positivi ed uno accettabile (dopo il secondo mese vi era solo un valore positivo e tre accettabili). La dimensione economica è riuscita a concludere con tutte le sue metriche in regola con i valori attesi, passando da un livello accettabile ad uno positivo. Anche la prospettiva risorse ha compiuto la stessa impresa, guadagnando uno straordinario nell ultimo mese. Nello specifico, la metrica QEST-RS-1 chiude ancora in negativo ma è migliorata di 0.17 punti. La qualità di QEST-RS-3, poi, ha terminato con un balzo in avanti consistente grazie ad un che ha ribaltato il giudizio della metrica addirittura da negativo a positivo. E invece rimasta pressoché invariata la prospettiva utenti, anche lei positiva. L ultima dimensione, quella tecnica, ha visto migliorare la sua qualità grazie ad un progresso di gran parte delle metriche. Tuttavia l indicatore QEST-TE-4 non è riuscito a raggiungere l accettabilità: la non conformità alle regole object oriented non è stata risolta nonostante sia comunque meno grave dei mesi precedenti. Il PRJ03 ha ottenuto l indicatore globale migliore tra le tre risorse: Tutte le dimensioni hanno fatto registrare un incremento della qualità, senza tuttavia spostarsi da un range ad un altro rispetto ai trenta giorni scorsi. La dimensione utenti conclude con un trend positivo. QEST-CS-1 è passato, nell arco dei tre mesi, da una qualità insoddisfacente ad una in

131 4.2. Secondo Caso d Uso 122 linea con le aspettative. QEST-CS-3, dopo essere sceso in zona rossa nel secondo periodo, è riuscito a recuperare ottenendo un valore finale tutto sommato accettabile. Anche la dimensione risorse chiude positivamente. Da notare come, in un mese soltanto, la qualità di QEST-RS-3 sia salita da 0.35 a 0.88 ottenendo una misura positiva. L area economica chiude in maniera accettabile. E curioso osservare che i valori delle tre metriche figlie sono tutte in linea con le aspettative (compreso QEST-EC-1, che al precedente rilevamento era ancora nel range migliorabile). Per pochi centesimi però, questo non è bastato ad ottenere il posizionamento migliore. Nell area tecnica, infine, sono state salvate quasi tutte le metriche, facendogli raggiungere un livello di qualità accettabile. Il numero di indicatori negativi è sceso così da tre ad uno: soltanto la tempestività di ripristino (QEST-TE-6) non è riuscita in questo obiettivo. In conclusione si può affermare che tutti e tre i progetti hanno raggiunto un ottima performance globale; tutti hanno avuto delle difficoltà nella dimensione tecnica ed un riscontro positivo nelle aree risorse ed utenti. Per quello che riguarda la prospettiva economica, l unico progetto in linea con i costi è stato PRJ02. Un po meno bene, ma comunque accettabile, la situazione per la risorsa PRJ03; decisamente troppe invece, le risorse finanziarie impiegate per lo sviluppo del progetto PRJ01 che, non a caso, chiude con valore insufficiente Seconda Istanza a) Primo mese In Figura 4.31 è raffigurato l andamento dei tre progetti dopo il primo mese. Senza pesi, le performance globali risultato leggermente inferiori rispetto a quelle della prima istanza. Le dimensioni, pur avendo delle differenze rispetto a quelle pesate, mantengono lo stesso intervallo di qualità nelle prime due risorse. Il progetto PRJ03 invece è penalizzato: due delle quattro prospettive ricevono un giudizio più basso. Il PRJ01 ha una performance di La dimensione utenti è positiva pur non avendo nessuna delle sue metriche dentro la soglia di positività. Il tasso di training (QEST-EC-3), con il suo valore di 0.6, è insoddisfacente; gli altri due indicatori sono accettabili. Anche la dimensione risorse è in linea con le aspettative. La prospettiva tecnica è accettabile e dista dalla soglia di positività di appena punti. Su questo mezzo successo influisce molto la qualità sufficiente del ritardo rispetto alle milestone (QEST-TE-7), essendo la metrica con il risultato più alto. L aspetto economico invece è non adeguato e deve subire interventi migliorativi, soprattutto sulla metrica QEST-EC-3 che ha ricevuto appena lo 0.5 di qualità. Il PRJ02 si presenta con la dimensione utenti in linea con le aspettative, le restanti tre

132 4.2. Secondo Caso d Uso 123 Figura 4.31: Seconda istanza: i tre progetti dopo il primo mese accettabili ma migliorabili. In particolare, la dimensione risorse è da seguire con particolare attenzione per via di due metriche insoddisfacenti su tre. Di queste, il tasso di issue sulle risorse non risolte nei tempi previsti (QEST-RS-3) fa registrare lo 0.35 mentre il tasso di disponibilità di risorse hardware per servizio-prodotto (QEST-RS-1) restituisce uno 0.6 piuttosto lontano dalla soglia di accettabilità e quindi preoccupante. Nella dimensione tecnica spicca la parità tra metriche in intervallo positivo e quelle accettabili. L unico indicatore su cui bisogna intervenire drasticamente è QEST-TE-4 (tasso di non conformità alle regole object oriented): il valore 0.3 che ne risulta è molto inferiore alle aspettative. Il PRJ03 è quello che manifesta la qualità più bassa (0.9951). La dimensione utenti è l unica che rientra nell intervallo di accettabilità, nonostante un tasso di usabilità (QEST-CS-3) di poco sotto la sufficienza. Dal punto di vista economico, l indice globale è negativo. La media è abbassata dal tasso di utilizzo per servizio-prodotto (QEST-EC-1) con lo La dimensione tuttavia è ad appena punti dall accettabilità. Il tasso di issue sulle risorse non risolte nei tempi previsti (QEST-RS-3), nell area risorse, ha ottenuto un punteggio così basso, 0.1, da aver rovinato l andamento dell intera prospettiva. Gli alti punteggi delle altre due metriche (0.97 e 0.98) tengono comunque questa dimensione nei limiti dell accettabilità. Queste ultime due dimensioni, pesate, sono risultate nella prima istanza rispettivamente sufficiente ed in linea con le aspettative; quindi, un intervallo sopra quello attuale. La prospettiva tecnica è la più disastrata e porta a due le aree negative del PRJ03.

133 4.2. Secondo Caso d Uso 124 Su dodici metriche, solo quattro sono positive; altrettante sono accettabili ed insufficienti. Tra queste appena citate compaiono QEST-TE-2, QEST-TE-11, QEST-TE-6 e QEST- TE-7. Le ultime due elencate sono quelle da trattare con più attenzione, essendo i loro valori ben lungi dalla decenza (devono recuperare almeno 0.33 e 0.35 punti). b) Secondo mese In Figura 4.32 sono visibili i valori di performance ottenuti dopo la seconda misurazione. Mentre a livello di performance e di dimensioni, i progetti PRJ01 e PRJ02 sono invariati, PRJ03 fa registrare un buon incremento della qualità passando da a , diventando in soli trenta giorni la risorsa migliore ed addirittura facendo salire di un intervallo tre dimensioni su quattro, ottenendone così due in linea con le aspettative e due accettabili. Riguardo il PRJ01, nella prospettiva utenti ha recuperato qualità il tasso di training, raggiungendo l accettabilità a discapito del tasso di usabilità. Le energie spese sulla prima metrica hanno causato il trascuramento dell altra con conseguente perdita di punti e posizionamento nella soglia negativa. Continua ad avere problemi l area economica, che regredisce ed aggiunge un altra metrica nella zona rossa (QEST-EC-2) facendole così salire a due su tre. Nel complesso migliora Figura 4.32: Seconda istanza: i tre progetti dopo il secondo mese anche la dimensione tecnica, pur non riuscendo a risolvere il problema del rispetto delle scadenze (QEST-TE-7) che, anzi, perde ancora qualche centesimo e si allontana leggermente dalla soglia di accettabilità. Nel progetto PRJ02 tutti i valori sono pressoché invariati. Si può segnalare una buona progressione della metrica QEST-TE-4 che, seppur negativa, passa da 0.3 a 0.49 lasciando ben sperare per il terzo mese.

134 4.2. Secondo Caso d Uso 125 All interno della risorsa PRJ03 si sono invece verificati molti movimenti, ad eccezione della dimensione utenti. Quella economica ha raggiunto un indice di qualità sufficiente grazie al raddoppio del valore di QEST-EC-1 (da 0.25 a 0.49) che allo stesso tempo si tira fuori dalla zona rossa. La prospettiva risorse vede la metrica QEST-RS-3 avvicinarsi notevolmente alla sufficienza per mezzo di un incremento del suo valore di 0.25 punti. Questo progresso ha innalzato la media di quest area, insediandola nel range dei valori in linea con le aspettative. Infine, nell area tecnica le metriche non accettabili scendono da quattro a tre. A lasciare il gruppo è la difettosità nel deploy (QEST-TE-11). Migliorano anche le altre, soprattutto le più critiche QEST-TE-6 e QEST-TE-7 che sono ora in una posizione decisamente meno grave rispetto al mese precedente. d) Terzo mese In Figura 4.33 vengono presentati i risultati della misurazione finale. Tutti i progetti sono Figura 4.33: Seconda istanza: i tre progetti dopo il terzo mese riusciti a chiudere con una performance globale migliorata e pressoché uniforme tra loro. Il ciclo di miglioramento ha quindi portato i suoi frutti. Rispetto ai progetti della prima istanza però, l indice di qualità è appena più basso. A livello di dimensioni è rimasto tutto invariato nei progetti PRJ01 e PRJ03; in PRJ02 invece, la prospettiva delle risorse ha raggiunto i valori attesi. Confrontando anche le dimensioni con la prima istanza, si nota che tutte, eccetto quella economica della seconda risorsa, hanno raggiunto lo stesso intervallo. Quest unica eccezione penalizza PRJ02: con le metriche pesate, aveva ottenuto tre aree su quattro positive, contro le due attuali.