MANUTENZIONE GUI DEL PROGETTO ATOM FORMALIZZAZIONE DEL PROCESSO
INDICE INDICE... 2 1. BREVE DESCRIZIONE DEL PROGETTO ATOM... 5 1.1 SCOPO DEL PROGETTO...5 1.2 DIAGRAMMA DI CONTESTO...5 1.3 GUI...8 1.3.1 Funzionalità... 8 1.3.2 Profili del sistema... 8 1.3.3 Navigazione e funzionalità... 9 2. FORMALIZZAZIONE DEL PROCESSO... 11 2.1 WORKFLOW DIAGRAMS DEL PROCESSO...11 2.1.1 Analisi del problema... 12 2.1.2 Sviluppo in locale... 13 2.1.3 Test... 14 2.1.4 Rilascio... 15 2.2 DESCRIZIONE DEI MANUFATTI...16 2.3 SCENARI PROCEDURALI...18 2.3.1 Scenari Procedurali Fase 1: Analisi del problema... 18 2.3.2 Scenari Procedurali Fase 2: sviluppo in locale... 21 2.3.3 Scenari Procedurali Fase 3: test... 23 2.3.4 Scenari Procedurali Fase 4: rilascio... 25 2.4 VERIFICA & VALIDAZIONE...28 2.4.1 Verifica Statica dei manufatti... 28 2.4.2 Verifica Statica dei Work Flow Diagram... 30 2.4.3 Verifica Statica degli Scenari Procedurali... 36 2.4.3.1 Verifica Statica degli scenari procedurali: fase 1... 36 2.4.3.2 Verifica Statica degli scenari procedurali: fase 2... 37 2.4.3.3 Verifica Statica degli scenari procedurali: fase 3... 38 2.4.3.4 Verifica Statica degli scenari procedurali: fase 4... 39 2.4.4 Verifica Dinamica... 41 3. MODELLO DI QUALITÀ... 42 3.1 GOAL QUESTION METRIC...42 3.1.1 Definizione del Progetto... 42 3.1.2 Definizione dei Goals... 44 2/75
3.1.3 Definizione dei Quesiti... 46 3.1.3.1 Quesiti Goal 1: Analizzare il processo 1. Analisi del problema... 46 3.1.3.2 Quesiti Goal 2: Analizzare i processi 2. Sviluppo in locale e 3. Test... 47 3.1.3.3 Quesiti Goal 3: Analizzare il processo 3.Rilascio... 47 3.1.4 Definizione dei Metriche... 49 3.1.4.1 Metriche del goal 1... 49 3.1.4.2 Metriche del goal 2... 50 3.1.4.3 Metriche del goal 3... 50 3.2 FOGLI METRICI...52 3.2.1 Foglio metrico goal 1... 53 3.2.2 Foglio metrico goal 2... 54 3.2.3 Foglio metrico goal 3... 56 3.3 TAVOLE DI DECISIONE...57 3.3.1.1 Tavola di deciosione goal 1... 58 3.3.1.2 Tavola di deciosione goal 2... 60 3.3.1.3 Tavola di decisione goal 3... 61 3.4 PIANO DI MISURAZIONE...62 3.4.1 Misure osservate goal 1... 62 3.4.2 Misure osservate goal 2... 64 3.4.3 Misure osservate goal 3... 65 3.5 MODELLI DI CALCOLO...68 3.5.1 Metriche calcolate del goal 1... 68 3.5.2 Metriche calcolate del goal 2... 69 3.5.3 Metriche calcolate del goal 3... 70 4. APPLICAZIONE DEL MODELLO DI QUALITÀ... 71 4.1 MISURE RILEVATE...71 4.1.1 Misure rilevate goal 1... 71 4.1.2 Misure rilevate goal 2... 72 4.1.3 Misure rilevate goal 3... 73 4.2 INTERPRETAZIONE DEI RISULTATI ED IDENTIFICAZIONE DELLE EVENTUALI AZIONI DI MIGLIORAMENTO...74 4.2.1 Interpretazione dei risultati goal 1... 74 4.2.2 Interpretazione dei risultati goal 2... 74 4.2.3 Interpretazione dei risultati goal 3... 75 3/75
Indice delle figure Figura 1: ATOM e sistemi esterni...6 Figura 2: Work Flow Diagram... 11 Figura 3: WFD Analisi della documentazione... 12 Figura 4: WFD Sviluppo in locale... 13 Figura 5: WFD Rilascio... 15 Figura 6: Albero di decomposizione dei manufatto... 29 Figura 7: Analisi consistenza globale... 30 Figura 8: Analisi consistenza strutturale (Fase 1)... 32 Figura 9: Analisi consistenza strutturale (Fase 2)... 33 Figura 10: Analisi consistenza strutturale (Fase 3)... 34 Figura 11: Analisi consistenza strutturale (Fase 4)... 35 4/75
1. BREVE DESCRIZIONE DEL PROGETTO ATOM 1.1 Scopo del progetto Il progetto ATOM (Advanced Telecom Order Manager) è uno dei progetti più corposi dell azienda Telecom. L obbiettivo del progetto è gestire ogni tipo di ordinativo proveniente dai più diversi e disparati sistemi esterni. Il tool prevalentemente utilizzato è un EAI (Enterprise Application Integration), Tibco BW 5.2. I paragrafi che seguono (1.2 e 1.3) non sono essenziali ai fini della formalizzazione del processo, ma sono risportati per completezza. 1.2 Diagramma di contesto ATOM è un sistema di workflow di processo che riceve dal CRM i Service Order relativi alle lavorazioni da effettuare e gestisce il colloquio con tutti gli altri sistemi di rete per il completamento delle attività di delivery. Segue il diagramma di contesto che schematizza l interfacciamento di ATOM con tutti gli altri sistemi. 5/75
Figura 1: ATOM e sistemi esterni Diamo una macro descrizione del ruolo dei sistemi coinvolti nei processi di Delivery: ACL/RC: Network Inventory del dominio di commutazione (UNICA/RA): Network Inventory del dominio di accesso ADAS: sistema di gestione delle risorse per attivazione/comandi degli autocommutatori. A-TOM: sistema di workflow di processo. Riceve da CRM i Service Order relativi alle lavorazioni da effettuare e gestisce il colloquio con tutti gli altri sistemi di rete per il completamento delle attività di delivery. BRCS: sistema per il controllo delle frodi. CNCF: sistema per la gestione delle Frodi 6/75
CRM: sistema di front end commerciale per la gestione del contatto cliente e l emissione degli ordini di lavoro. DAI: sistema che gestisce le attività di provisioning sul prodotto (sola consegna, consegna ed installazione, recupero prodotti). Designer: sistema che gestisce le attività manuali relative al delivery dei servizi e prodotti Fonia. GEM: sistema utilizzato per la gestione dei materiali. Gestore delle Segnalazioni: Notifica l esecuzione dei servizi Chi è on line e Memotel on line al portale Broadband. GPRI: sistema per la gestione delle attività di delivery relative ai servizi VAD. INCONTRA LIDO fonia: DWH per processi di assurance. Magellano: sistema a supporto dei processi di fornitura dei servizi ISDN BRA, ISDN PRA e Business Packet su Canale D. Notificatore OLO: PACI: sistema per la gestione della morosità. Pitagora: sistema di Order entry per gli ordinativi Wholesale. TLD: sistema commerciale dal quale A-TOM riceve ordinativi da inviare esclusivamente a Designer Prodotti per la consegna/ritiro di prodotti presso la sede cliente relativamente ad impianti CDX. TGU: sistema di front end commerciale per la gestione del contatto cliente e l emissione degli ordini di lavoro (sistema in dismissione, attualmente operativo per la sola telefonia pubblica). UNICA/T: Network Inventory del dominio di trasporto WRAP-WFM: sistemi per la gestione della forza lavoro. 7/75
1.3 GUI 1.3.1 Funzionalità E messa a disposizione degli operatori una interfaccia grafica tramite la quale è possibile: ricercare un singolo o più ordinativi, visualizzarne il dettaglio ed eventialemente effettuare una o più lavorazioni sullo stesso. 1.3.2 Profili del sistema Il sistema prevede diverse tipologie di profilo di utenza e conseguentemente diverse funzionalià ad esso associate, quali: 1. Administrator 2. User 3. Operatore Nazionale 4. Help Desk 5. Guest In particolare di seguito sono riportate le funzionalità a disposizione di ogni profilo: Administrator: l utente accreditato di questo profilo ha la possibilità di funzionalità abilitate: consultazione e lavorazione degli OL; consultazione e lavorazione delle lavorazioni di interesse rete intelligente; gestione della data DAC; creazione, cancellazione e modifica utenze; modifica della propria password; gestione della release; selezione del territorio; User: funzionalità abilitate: consultazione e lavorazione degli OL; 8/75
consultazione delle lavorazioni di interesse rete intelligente; gestione della data DAC; modifica della propria password; selezione del territorio; Operatore nazionale: funzionalità abilitate: consultazione e lavorazione delle lavorazioni di interesse rete intelligente; modifica della propria password; Help Desk: funzionalità abilitate: gestione e visualizzazione dei Bad Task; gestione e visualizzazione delle funzionalità di sistema; modifica della propria password; Guest: funzionalità abilitate: visualizzazione degli OL; selezione del territorio; 1.3.3 Navigazione e funzionalità Per ogni ambito è definita una navigazione, si riporta a titolo di esempio quella relativa ad un particolare tipo di ordinativi: 9/75
Ogni tipo di richiesta, visualizzazione o lavorazione è effettuata utilizzando architettura AJAX (Asynchronous JavaScript and XML) e nello specifico il tool Tibco GI 4.1 che adotta questa nuova tecnologia. 10/75
2. FORMALIZZAZIONE DEL PROCESSO Con riferimento al progetto descritto nel paragrafo precedente, il processo che si intende analizzare è lo sviluppo e la manutenzione dell interfaccia utente. 2.1 Workflow Diagrams del Processo M7 Specifiche Architetturali M1 Descrizione Anomalie 1. Analisi del problema M9 Anomalie rigettate M10 Anomalie GUI non rigettate M13 Esempi Tibco GI 2. Sviluppo in locale M14 Codice soluzione anomalie (Client) M29 Processi M7 Database 3. Test M15 Codice soluzione anomalie M5 Soluzione non corretta M8 Soluzione corretta 4. M10 Info rilascio Rilascio M11 Pacchetto GUI testato e rilasciato Figura 2: Work Flow Diagram 11/75
I WF che seguono dettagliano le attività del WF precedente in attività elementari. 2.1.1 Analisi del problema M1 Descrizione Anomalie 1.1 Assegnazione anomalia M2 Anomalie assegnate 1.2 M4 Anomalie NON riscontrate a runtime Riscontro anomalia runtime M3 Anomalie riscontrate a runtime M7 Specifiche Funzionali 1.3 Riscontro anomalia doc M6 Anomalie NON riscontrate nel doc 1.4 Rigetto anomalie M5 Anomalie riscontrate nel doc 1.5 Analisi anomalia M8 Anomalie NON GUI M9 Anomalie rigettate M10 Anomalie GUI NON rigettate Figura 3: WFD Analisi della documentazione 12/75
2.1.2 Sviluppo in locale M10 Anomalie NON rigettate 2.1 Configurazione Ambiente di sviluppo M11 Ambiente di sviluppo Client configurato M12 Ambiente di sviluppo Server configurato M10 Anomalie NON rigettate 2.2 2.3 M10 Anomalie NON rigettate M13 Esempi Tibco GI Sviluppo codice Client Sviluppo codice Server M14 Modifica codice client M15 Modifica codice server Figura 4: WFD Sviluppo in locale 13/75
2.1.3 Test M15 Modifica codice server M14 Modifica codice client M28 Database 3.1 3.2 M28 Database M29 Processi M16 Codice server testato Test (processi server) in locale 3.3 Deploy EAR Test (client GI) in locale 3.4 Deploy JAR M29 Processi M17 Codice client testato M18 EAR deployato in sviluppo M19 JAR deployato in sviluppo 3.5 Test su macchina sviluppo M21 Soluzione Non corretta M20 Soluzione corretta 14/75
2.1.4 Rilascio M20 Soluzione corretta 4.1 Rilascio processi Tibco 4.2 Rilascio codice client M22 Processi modificati e rilasciati M23 Codice client modificato e rilasciato 4.3 Creazione JAR M24 Pacchetto JAR di rilascio 4.4 Creazione nota di rilascio M25 Nota di rilascio M26 Info rilascio 4.5 Rilascio M11 Pacchetto GUI testato e rilasciato Figura 5: WFD Rilascio 15/75
2.2 Descrizione dei manufatti Nome anomalia M1 Descrizione Anomalie M2 Anomalie assegnate Descrizione E-mail di descrizione dell anomalia: ID, Ambiente, problema, caso di test Anomalia assegnata ad una particolare risorsa M3 Anomalie riscontrate a runtime Anomalie effettivamente riscontrate nell ambiente indicato nelle descrizioni dell anomalie M4 Anomalie non riscontrate a runtime M5 Anomalie riscontrate nel doc M6 Anomalie non riscontrate nel doc Anomalie Non riscontrate nell ambiente indicato nelle descrizioni dell anomalie Anomalie coerenti al documento di analisi Anomalie Non coerenti al documento di analisi M7 Specifiche Funzionali Documento di analisi funzionali del progetto M8 Anomalie non GUI Anomalie da rigirare al gruppo dei processi o al DBA M9 Anomalie rigettate M10 Anomalie GUI non rigettate M12 Ambiente di sviluppo Server configurato M11 Ambiente di sviluppo Client configurato M13 Es.Tibco GI M14 Modifica codice client M15 Modifica codice server Anomalie rigettate per vari motivi Anomalie prese a carico del gruppo GUI Ambiente dei processi e DB Ambiente client GI e DB Esempi di applicazioni costruite con Tibco GI Progetto client (Tibco GI) modificato Progetto server (Tibco BW) modificato M16 Codice server testato Codice server (processi Tibco BW) modificato e testato M17 Codice client testato Codice client (component Tibco GI) modificato e testato M18 EAR deployato in sviluppo Pacchetto di rilascio del codice server 16/75
(processi Tibco BW) M19 JAR deployato in sviluppo M20 Soluzione corretta M21 Soluzione non corretta M22 Processi modificati e rilasciati M23 Codice client modificato e rilasciato M24 Pacchetto JAR di rilascio Pacchetto di rilascio del codice client (component Tibco GI) Modifica del codice (client e server) che rappresenta la corretta soluzione per le anomalie Modifica del codice (client e server) che Non rappresenta la corretta soluzione per le anomalie Pacchetto di rilascio del codice server (processi Tibco BW) rilasciato in ambiente di sviluppo Pacchetto di rilascio del codice client (component Tibco GI) rilasciato in ambiente di sviluppo Pacchetto di rilascio del codice client (component Tibco GI) rilasciato in ambiente di test M25 Nota di rilascio Nota di rilascio del JAR: eventuali configurazioni, variabili d ambiente, ambienti etc, ID anomalie chiuse etc. M26 Info di rilascio IP Macchina e Dir dove effettuare il rilascio M28 Database M29 Processi DB e parametri di connessione Librerie dei processi esterni (Tibco BW) 17/75
2.3 Scenari Procedurali Descriviamo ora, le attività elementari presenti nei Work Flow Diagram riportati nei precedenti paragrafi, attraverso le attività di base di cui si compongono e per ognuna di queste si indicheranno manufatti di input (I) e di output (O) nonchè le condizioni interne di ingresso (Isc) e di uscita (Iec) dall attività. 2.3.1 Scenari Procedurali Fase 1: Analisi del problema 1.1 Assegnazione anomalia I(1.1): M1 Descrizione Anomalie Isc: La descrizione di una o più anomalie è disponibile FOR EACH ( M1 Descrizione Anomalie ) k BEGIN 1.1.1 PRODURRE (M2 Anomalie assegnate) k END USANDO (M1 Descrizione Anomalie ) k O(1.1): Iec: M2 Anomalie assegnate nessuna 18/75
1.2 Riscontro anomalie runtime I(1.2): M2 Anomalie assegnate Isc: Sono disponibili una o più anomalie assegnate FOR EACH ( M2 Anomalie assegnate ) k BEGIN 1.2.1 DEFINIRE (M3 Anomalie riscontrate a runtime) k USANDO ( M2 Anomalie assegnate) k 1.2.2 DEFINIRE (M4 Anomalie NON riscontrate a runtime) k END USANDO ( M2 Anomalie assegnate) k O(1.2): M3 Anomalie riscontrate a runtime, runtime M4 Anomalie NON riscontrate a Iec: nessuna 1.3 Riscontro anomalie doc I(1.3): M3 Anomalie riscontrate a runtime, M7Specifiche funzionali Isc: Esistono anomalie riscontrate a runtime e sono disponibili le specifiche funzionali FOR EACH ( M2 Anomalie assegnate ) k BEGIN 1.3.1 DEFINIRE (M5 Anomalie riscontrate nel doc) k USANDO (M3 Anomalie riscontrate a runtime) k AND (M7Specifiche funzionali) 1.3.2 DEFINIRE (M6 Anomalie NON riscontrate nel doc) k USANDO (M3 Anomalie riscontrate a runtime) k AND (M7Specifiche funzionali) END O(1.3): Iec: M5 Anomalie riscontrate nel doc, M6 Anamalie NON riscontrate nel doc nessuna 19/75
1.4 Rigetto anomalie I(1.4): Isc: M6 Anomalie NON riscontrate nel doc, M4 Anomalie NON riscontrate a runtime, M8 Anomalie NON GUI Esistono anomalie da rigettare FOR EACH ((M6 Anomalie NON riscontrate nel doc) k AND (M4 Anomalie NON riscontrate a runtime) i AND (M8 Anomalie NON GUI) j ) BEGIN 1.4.1 DEFINIRE ( M9 Anomalie rigettate) h USANDO ((M6 Anomalie NON riscontrate nel doc) k AND (M4 Anomalie NON riscontrate a runtime) i AND (M8 Anomalie NON GUI) j ) END O(1.4): Iec: M9 Anomalie rigettate nessuna 20/75
1.5 Analisi anomalie I(1.5): M5 Anomalie riscontrate nel doc Isc: Esistono anomalie a carico del gruppo GUI FOR EACH (M5 Anomalie riscontrate nel doc) k BEGIN 1.5.1 DEFINIRE (M8 Anomalie NON GUI) h USANDO (M5 Anomalie riscontrate nel doc) k 1.5.2 DEFINIRE (M10 Anomalie GUI non rigettate) h END USANDO (M5 Anomalie riscontrate nel doc) k O(1.5): Iec: M8 Anomalie NON GUI, M10 Anomalie GUI non rigettate nessuna 2.3.2 Scenari Procedurali Fase 2: sviluppo in locale 2.1 Configurazione ambiente di sviluppo I(2.1): M10 Anomalie GUI non rigettate Isc: nessuna FOR EACH ( M10 Anomalie GUI non rigettate ) k BEGIN 2.1.1 PRODURRE (M11 Ambiente di sviluppo client configurato) h USANDO ( M10 Anomalie GUI non rigettate ) k 2.1.2 PRODURRE (M12 Ambiente di sviluppo server configurato) h END USANDO ( M10 Anomalie GUI non rigettate ) k O(2.1): Iec: M11 Ambiente di sviluppo client configurato, M12 Ambiente di sviluppo server configurato nessuna 21/75
2.2 Sviluppo codice client I(2.2): Isc: M10 Anomalie GUI non rigettate, M11 Ambiente di sviluppo client configurato, M13 Es. Tibco GI Esistono anomalie da risolvere e l ambiente (client Tibco GI) è configurato FOR EACH ( M10 Anomalie GUI non rigettate ) k BEGIN 2.2.1 PRODURRE ( M14 Modifica codice client) h USANDO (M11 Ambiente di sviluppo client configurato ) k (M13 Es. Tibco GI) AND END O(2.2): Iec: M14 Modifica codice client nessuna 2.3 Sviluppo codice server I(2.3): M12 Ambiente di sviluppo server configurato Isc: L ambiente server (processi Tibco BW) è configurato FOR EACH ( M10 Anomalie GUI non rigettate ) k BEGIN 2.3.1 PRODURRE (M15 Modifica codice server) h END USANDO (M12 Ambiente di sviluppo server configurato) k O(2.3): Iec: M15 Modifica codice server nessuna 22/75
2.3.3 Scenari Procedurali Fase 3: test 3.1 Test processi server in locale I(3.1): M15 Modifica codice server, M28 Processi, M29 Database Isc: Sono disponibili e startati i processi e configurati con DB esatto FOR EACH ( M15 Modifica codice server ) k BEGIN 3.1.1 PRODURRE (M16 Codice server testato) h USANDO (M15 Modifica codice server) k (M29 Database) AND (M28 Processi) AND END O(3.1): Iec: M16 Codice server testato nessuna 3.2 Test codice client il locale I(3.2): M14 Modifica codice client Isc: Il codice client modificato è disponibile FOR EACH ( M14 Modifica codice client ) k BEGIN 3.2.1 PRODURRE ( M17 Codice client testato ) h END USANDO ( M14 Modifica codice client ) k O(3.2): Iec: M17 Codice client testato nessuna 23/75
3.3 Deploy EAR I(3.3): M16 Codice server testato Isc: E disponibile il codice server con tutte le librerie aggiornate BEGIN 3.3.1 PRODURRE (M18 EAR deployato in sviluppo) USANDO (M16 Codice server testato) END O(3.3): Iec: M18 EAR deployato in sviluppo nessuna 3.4 Deploy JAR I(3.4): M17 Codice client testato Isc: E disponibile il codice client (Tibco GI) testato BEGIN 3.4.1 PRODURRE (M19 JAR deployato in sviluppo) USANDO (M17 Codice client testato) END O(3.4): Iec: M19 JAR deployato in sviluppo nessuna 24/75
3.5 Test sulla macchina di sviluppo I(3.5): M18 EAR deployato in sviluppo, M19 JAR deployato in sviluppo Isc: Sulla macchina di sviluppo devono essere deplorati il JAR (codice client) e l EAR (codice server) BEGIN 3.5.1 DEFINIRE (M20 Soluzione corretta) USANDO (M18 EAR deployato in sviluppo) AND (M19 JAR deployato in sviluppo) 3.5.2 DEFINIRE (M21 Soluzione NON corretta) USANDO (M18 EAR deployato in sviluppo) AND (M19 JAR deployato in sviluppo) END O(3.5): Iec: M20 Soluzione corretta, M21 Soluzione NON corretta nessuna 2.3.4 Scenari Procedurali Fase 4: rilascio 4.1 Rilascio processi Tibco I(4.1): M20 Soluzione corretta Isc: E disponibile la soluzione che risolve le anomalie BEGIN 4.1.1 PRODURRE ( M22 Processi modificati e rilasciati ) USANDO (M20 Soluzione corretta) END O(4.1): Iec: M22 Processi modificati e rilasciati nessuna 25/75
4.2 Rilascio codice client I(4.2): M20 Soluzione corretta Isc: E disponibile la soluzione che risolve le anomalie BEGIN 4.2.1 PRODURRE ( M23 Codice client modificato e rilasciato) USANDO (M20 Soluzione corretta) END O(4.2): Iec: M23 Codice client modificato e rilasciato nessuna 4.3 Creazione JAR I(4.3): Isc: M22 Processi modificati e rilasciati, M23 Codice client modificato e rilasciato Sono disponibili sulla macchina di sviluppo il codice client e server rilasciato BEGIN 4.3.1 PRODURRE (M24 Pacchetto JAR di rilascio) USANDO (M22 Processi modificati e rilasciati) AND (M23 Codice client modificato e rilasciato) END O(4.3): Iec: M24 Pacchetto JAR di rilascio nessuna 26/75
4.4 Creazione nota di rilascio I(4.4): M24 Pacchetto JAR di rilascio Isc: E disponibile un JAR da rilasciare BEGIN 4.4.1 PRODURRE (M25 Nota di rilascio) USANDO ( M24 Pacchetto JAR di rilascio ) END O(4.4): Iec: M25 Nota di rilascio nessuna 4.5 Rilascio I(4.5): M25 Nota di rilascio, M26 Info di rilascio Isc: Sono disponibili Info per il rilascio (macchina su cui rilasciare e directory) BEGIN 4.5.1 PRODURRE (M27 Pacchetto GUI modificato e testato) USANDO (M25 Nota di rilascio AND M26 Info di rilascio) END O(4.5): Iec: M27 Pacchetto GUI modificato e testato nessuna 27/75
2.4 Verifica & Validazione 2.4.1 Verifica Statica dei manufatti Un manufatto di definisce globalmente consistente se un componente non è presente più volte nella definizione della struttura, cioè se la definizione del manufatto non presenta, al suo interno, strutture ricorrenti. La definizione della struttura avviene mediante la creazione di un albero di decomposizione di un manufatto che è riportato sotto. Come si può notare dall albero di decomposizione, non sono emerse strutture ricorrenti e quindi è assicurata la consistenza globale dei manufatti. 28/75
M0 Manufatti di processo M1 Descrizione Anomalie M2 Anomalie assegnate M3 Anomalie riscontrate a runtime M4 Anomalie non riscontrate a runtime M5 Anomalie riscontrate nel doc M6 Anomalie non riscontrate nel doc M7 Specifiche Funzionali M8 Anomalie non GUI M9 Anomalie rigettate M10 Anomalie GUI non rigettate M11 Ambiente di sviluppo Server configurato M12 Ambiente di sviluppo Client configurato M13 Es.Tibco GI M14 Modifica codice client M15 Modifica codice server M16 Codice server testato M17 Codice client testato M18 EAR deployato in sviluppo M19 JAR deployato in sviluppo M20 Soluzione corretta M21 Soluzione non corretta M22 Processi modificati e rilasciati M23 Codice client modificato e rilasciato M24 Pacchetto JAR di rilascio M25 Nota di rilascio M26 Info rilascio M27 Pacchetto JAR di rilascio M28 Database M29 Processi Figura 6: Albero di decomposizione dei manufatto 29/75
2.4.2 Verifica Statica dei Work Flow Diagram Un work flow diagram si definisce globalmente consistente se è assicurata l assenza di ricorrenze di una fase a differenti livelli. Come emerge dal come dallo schema sottostante, i Work Flow Diagrams definiti per rappresentare il Processo di Manutenzione GUI gruppo ATOM sono globalmente consistenti, in quanto non vi sono fasi con ricorrenze a differenti livelli di dettaglio dei Work Flow Diagrams. Fase 1: Analisi del problema Assegnazione anomalia Riscontro anomalia runtime Riscontro anomalia doc Rigetto anomalie Analisi anomalia Fase 2: Sviluppo in locale Configurazione Ambiente di sviluppo Sviluppo codice client Svilupp codice server Fase 3: Test Test (processi server) in locale Test (client GI) in locale Deploy EAR Deploy JAR Test su macchina sviluppo Fase 4: Rilascio Rilascio processi Tibco Rilascio codice client Creazione JAR Creazione nota rilascio Figura 7: Analisi consistenza globale 30/75
Un Work Flow Diagram si definisce strutturalmente consistente se è assicurato il bilanciamento dei manufatti tra le fasi. Analizzando ogni singolo WF, si nota come ogni Work Flow utilizzi tutti e solo i manufatti della fase che dettaglia e tutti e soli gli output che sono generati dalla stessa fase, per cui è assicurata anche la consistenza strutturale. 31/75
M7 Specifiche Architetturali M1 Descrizione Anomalie 1. Analisi del problema M9 Anomalie rigettate M10 Anomalie GUI non rigettate M1 Descrizione Anomalie 1.1 Assegnazione anomalia M2 Anomalie assegnate M3 Anomalie riscontrate a runtime M7 Specifiche Funzionali 1.2 Riscontro anomalia 1.3 Riscontro anomalia doc M4 Anomalie NON riscontrate a M6 Anomalie NON riscontrate nel 1.4 Rigetto anomalie M5 Anomalie riscontrate nel d 1.3 M8 Anomalie NON GUI M9 Anomalie rigettate Analisi anomalia M10 Anomalie GUI NON rigettate Figura 8: Analisi consistenza strutturale (Fase 1) 32/75
M10 Anomalie GUI non rigettate M13 Esempi Tibco GI 2. Sviluppo in locale M5 Soluzione non corretta M14 Codice soluzione anomalie (Client) M15 Codice soluzione anomalie M10 Anomalie NON rigettate 2.1 Configurazione Ambiente di sviluppo M11 Ambiente di sviluppo Client configurato M12 Ambiente di sviluppo Server configurato 2.2 2.3 M13 Esempi Tibco GI Sviluppo codice Client Sviluppo codice Server M14 Codice soluzione anomalie (Client) M15 Codice soluzione anomalie (Server) Figura 9: Analisi consistenza strutturale (Fase 2) 33/75
M14 Codice soluzione anomalie (Client) M29 Processi M7 Database 3. Test M15 Codice soluzione anomalie (Server) M5 Soluzione non corretta M8 Soluzione corretta M15 Codice soluzione (Server) M14 Codice soluzione anomalie (Client) testati M28 Database 3.1 3.1 M28 Database Test (processi server) in locale M16 Config. processi testati 3.1 Deploy EAR Test (client GI) in locale M29 Processi M17 codice client testato 3.2 Deploy JAR M18 EAR deployato in sviluppo M19 JAR deployato in sviluppo 3.3 Test su macchina sviluppo M21 Soluzione Non corretta M20 Soluzione corretta Figura 10: Analisi consistenza strutturale (Fase 3) 34/75
M8 Soluzione corretta 4. Rilascio M10 Info rilascio M11 Pacchetto GUI testato e rilasciato M20 Soluzione corretta 4.1 Rilascio processi 4.2 Rilascio codice M22 Processi modificati e rilasciati 4.3 Creazione JAR M23 Codice client modificato e rilasciato M24 Pacchetto JAR di rilascio 4.4 Creazione nota di M25 Nota di rilascio M26 Info rilascio 4.5 Rilascio M27 Pacchetto GUI testato e rilasciato Figura 11: Analisi consistenza strutturale (Fase 4) 35/75
2.4.3 Verifica Statica degli Scenari Procedurali Un Work Flow è consistente rispetto ai manufatti se ogni manufatto è prodotto o è utilizzato come input da almeno una attività base, ed esistono un manufatto in input e uno in output per ogni attività base. Segue l analisi di tutti gli scenari in dettaglio, divisi fasi, da cui emerge che ogni attività base di ogni scenario produce e utilizza almeno un manufatto. Inoltre, data una attività elementare e lo scenario procedurale che la dettaglia, la consistenza isomorfica assicura che ci sia un isomorfismo tra la struttura dei manufatti di input e la struttura dello scenario e un isomorfismo tra la struttura dei manufatti di output e la struttura dello scenario. Analizzando le singole attività elementari del Work Flow Diagram e gli scenari procedurali che descrivono le attività elementari è risultato che la struttura di ogni manufatto, sia quelli in input che quelli in output, è isomorfa alla struttura dello scenario corrispondente e pertanto è assicurata anche la consistenza isomorfica. 2.4.3.1 Verifica Statica degli scenari procedurali: fase 1 SCENARIO PROCEDURALE 1.1 Elenco Manufatti utilizzati M1 Descrizione Anomalie M2 Anomalie assegnate Modalità di utilizzo M1 è utilizzato nell attività base 1.1.1 M2 è prodotto nell attività base 1.1.1 SCENARIO PROCEDURALE 1.2 Elenco Manufatti utilizzati M2 Anomalie assegnate M3 Anomalie riscontrate a runtime M4 Anomalie NON riscontrate a runtime Modalità di utilizzo M2 è utilizzato nell attività base 1.2.1 e in 1.2.2 M3 è prodotto nell attività base 1.2.1 M4 è prodotto nell attività base 1.2.2 36/75
SCENARIO PROCEDURALE 1.3 Elenco Manufatti utilizzati M3 Anomalie riscontrate a runtime M7Specifiche funzionali M5 Anomalie riscontrate nel doc M6 Anamalie NON riscontrate nel doc M9 Anomalie rigettate Modalità di utilizzo M3 è utilizzato nell attività base 1.3.1 e in 1.3.1 M7 è utilizzato nell attività base 1.3.1 e in 1.3.1 M5 è utilizzato nell attività base 1.3.1 e in 1.3.1 M9 è prodotto nell atività base 1.3.1 SCENARIO PROCEDURALE 1.4 Elenco Manufatti utilizzati M6 Anomalie NON riscontrate nel doc M4 Anomalie NON riscontrate a runtime M8 Anomalie NON GUI Modalità di utilizzo M6 è utilizzato nell attività base 1.4.1 M4 è utilizzato nell attività base 1.4.1 M8 è utilizzato nell attività base 1.1.1 M2 è prodotto nell atività base 1.4.1 2.4.3.2 Verifica Statica degli scenari procedurali: fase 2 SCENARIO PROCEDURALE 2.1 Elenco Manufatti utilizzati M10 Anomalie GUI non rigettate M11 Ambiente di sviluppo client configurato M12 Ambiente di sviluppo server configurato Modalità di utilizzo M10 è utilizzato nell attività base 2.1.1 ed in 2.1.2 M11 è utilizzato nell attività base 2.1.1 M12 è utilizzato nell attività base 2.1.2 37/75
SCENARIO PROCEDURALE 2.2 Elenco Manufatti utilizzati M10 Anomalie GUI non rigettate M11 Ambiente di sviluppo client configurato M13 Es. Tibco GI M14 Modifica codice client Modalità di utilizzo M10 è utilizzato nell attività base 2.2.1 M11 è utilizzato nell attività base 2.2.1 M13 è utilizzato nell attività base 2.2.1 M14 è prodotto nell attività base 2.2.1 SCENARIO PROCEDURALE 2.3 Elenco Manufatti utilizzati M12 Ambiente di sviluppo server configurato M15 Modifica codice server Modalità di utilizzo M12 è utilizzato nell attività base 2.3.1 M15 è prodotto nell attività base 2.2.1 2.4.3.3 Verifica Statica degli scenari procedurali: fase 3 SCENARIO PROCEDURALE 3.1 Elenco Manufatti utilizzati M15 Modifica codice server M28 Processi M29 Database M16 Codice server testato Modalità di utilizzo M15 è utilizzato nell attività base 3.1.1 M28 è utilizzato nell attività base 3.1.1 M29 è utilizzato nell attività base 3.1.1 M16 è prodotto nell attività base 3.1.1 SCENARIO PROCEDURALE 3.2 Elenco Manufatti utilizzati M14 Modifica codice client M17 Codice client testato Modalità di utilizzo M14 è utilizzato nell attività base 3.2.1 M17 è prodotto nell attività base 3.2.1 38/75
SCENARIO PROCEDURALE 3.3 Elenco Manufatti utilizzati M16 Codice server testato M18 EAR deployato in sviluppo Modalità di utilizzo M16 è utilizzato nell attività base 3.3.1 M18 è prodotto nell attività base 3.3.1 SCENARIO PROCEDURALE 3.4 Elenco Manufatti utilizzati M18 EAR deployato in sviluppo, M19 JAR deployato in sviluppo M20 Soluzione corretta M21 Soluzione NON corretta Modalità di utilizzo M18 è utilizzato nell attività base 3.4.1 ed in 3.4.2 M19 è utilizzato nell attività base 3.4.1 ed in 3.4.2 M20 è prodotto nell attività base 3.4.1 M21 è prodotto nell attività base 3.4.2 2.4.3.4 Verifica Statica degli scenari procedurali: fase 4 SCENARIO PROCEDURALE 4.1 Elenco Manufatti utilizzati M20 Soluzione corretta M22 Processi modificati e rilasciati Modalità di utilizzo M20 è utilizzato nell attività base 4.1.1 M22 è prodotto nell attività base 4.1.1 SCENARIO PROCEDURALE 4.2 Elenco Manufatti utilizzati M20 Soluzione corretta M23 Codice client modificato e rilasciato Modalità di utilizzo M20 è utilizzato nell attività base 4.2.1 M23 è prodotto nell attività base 4.2.1 39/75
SCENARIO PROCEDURALE 4.3 Elenco Manufatti utilizzati M22 Processi modificati e rilasciati M23 Codice client modificato e rilasciato Modalità di utilizzo M22 è utilizzato nell attività base 4.3.1 M23 è utilizzato nell attività base 4.3.1 M24 è prodotto nell attività base 4.3.1 M24 Pacchetto JAR di rilascio SCENARIO PROCEDURALE 4.4 Elenco Manufatti utilizzati M24 Pacchetto JAR di rilascio M25 Nota di rilascio Modalità di utilizzo M24 è utilizzato nell attività base 4.4.1 M25 è prodotto nell attività base 4.4.1 SCENARIO PROCEDURALE 4.5 Elenco Manufatti utilizzati M22 Processi modificati e rilasciati, M23 Codice client modificato e rilasciato Modalità di utilizzo M22 è utilizzato nell attività base 4.5.1 M23 è utilizzato nell attività base 4.5.1 M24 è prodotto nell attività base 4.5.1 M24 Pacchetto JAR di rilascio 40/75
2.4.4 Verifica Dinamica Per verificare eventuali inconsistenze comportamentali, occorre simulare l esecuzione del processo. La verifica dinamica, infatti, rende possibile la scoperta di inconsistenze dinamiche che nel controllo statico riescono a passare inosservate; ad esempio può essere rilevata l impossibilità di attivare un attività a causa di un input richiesto la cui produzione dipende dall attività stessa. La verifica è stata portata avanti esaminando gli scenari procedurali di ogni singola attività elementare e più precisamente analizzando le Internal Starting Conditions (Isc) e i manufatti disponibili all avvio del processo. Ed è risultata l assenza di inconsistenze comportamentali in quanto negli ISC sono presenti solo manufatti già disponibili o che sono stati prodotti dalle attività svolte in precedenza. 41/75
3. MODELLO DI QUALITÀ 3.1 Goal Question Metric Di seguito viene definito un piano di misurazione Goal-Oriented secondo l approccio Multiview Framework (rif. art. Comprehensibility and Efficiency of Multiview Framework for Measurement Plan Design M. T. Baldassarre, D. Caivano, G. Visaggio ). 3.1.1 Definizione del Progetto Il progetto che si desidera sviluppare, denominato ManutenzioneGUI è definito dalla seguente quadrupla: ManutenzioneGUI -GQM = { P, D, PM, FI } dove P = { insieme dei frammenti di processo eseguiti per ottenere i prodotti finali richiesti a partire dai dati in input } = { Assegnazione anomalia, Riscontro anomalia runtime, Riscontro anomalia doc,rigetto anomalie, Analisi anomalia, Configurazione Ambiente di sviluppo, Sviluppo codice Client, Sviluppo codice Server, Test (processi server) in locale, Test (client GI) in locale, Deploy EAR, Deploy JAR, Test su macchina sviluppo, Rilascio processi Tibco, Rilascio codice client, Creazione JAR, Creazione nota di rilascio, Rilascio} D = { insieme dei manufatti (sottoprodotti, prodotti intermedi ) } = { M1 Descrizione Anomalie, M2 Anomalie assegnate, M3 Anomalie riscontrate a runtime, M4 Anomalie non riscontrate a runtime, M5 Anomalie riscontrate nel doc, M6 Anomalie non riscontrate nel doc, M7 Specifiche Funzionali, M7 Specifiche Funzionali, M8 Anomalie non GUI, M9 Anomalie rigettate, M10 Anomalie GUI non rigettate, M11 Ambiente di sviluppo Server configurato, M12 Ambiente di sviluppo Client configurato, M13 Es.Tibco GI, M14 Modifica codice client, M15 Modifica codice server, M16 Codice server testato, M17 Codice client testato, 42/75
M18 EAR deployato in sviluppo, M19 JAR deployato in sviluppo, M20 Soluzione corretta, M21 Soluzione non corretta, M22 Processi modificati e rilasciati, M23 Codice client modificato e rilasciato, M24 Pacchetto JAR di rilascio, M25 Nota di rilascio, M27 Pacchetto JAR di rilascio, M28 Database} PM = { insieme delle attività di Project Management necessarie a pianificare e controllare l esecuzione del progetto } Le attività di Project Management necessarie a pianificare l esecuzione del progetto non sono visibili nell ambito del processo Manutenzione GUI del progetto ATOM formalizzato dal presente documento. Questo perché il processo formalizzato, è uno dei tanti sottoprocessi presenti in Telcom e l attività di pianificazione pertanto non è possibile contemplarla. = { } FI = { insieme delle attività di Fitness of Investment necessarie a controllare l adeguatezza degli investimenti } 1 = { } 1 Si tratta di attività Manageriali che non rientrano nella formalizzazione del presente processo, sebbene queste sicuramente interagiscano con il processo formalizzato. 43/75
3.1.2 Definizione dei Goals Un goal definisce concettualmente il fattore o i fattori che sono lo scopo del modello. I vari goals sono definiti secondo la formalizzazione del progetto descritta precedentemente; si hanno quindi i seguenti goals: Goals di Processo: i goals che includono metriche per valutare caratteristiche di qualità relative ad un processo. Goal 1 ANALIZZARE: il processo 1. Analisi del problema ALLO SCOPO: di valutarlo RISPETTO: alla capacità di analisi DAL PUNTO DI VISTA: del Team-Manager NEL CONTESTO: del progetto ManutenzioneGUI-GQM Goal 2 ANALIZZARE: i processi 2. Sviluppo in locale e 3. Test ALLO SCOPO: di valutarlo RISPETTO: alla capacità di implementazione e di test DAL PUNTO DI VISTA: dello sviluppatore NEL CONTESTO: del progetto ManutenzioneGUI-GQM Goal 3 ANALIZZARE: il processo 4. Rilascio ALLO SCOPO: di valutarlo RISPETTO: alla capacità di rilascio 44/75
DAL PUNTO DI VISTA: dello sviluppatore NEL CONTESTO: del progetto ManutenzioneGUI-GQM 45/75
3.1.3 Definizione dei Quesiti I quesiti esprimono le informazioni richieste per raggiungere l obiettivo specificato nei goals. Per ogni goal, sono stati individuati i quesiti esposti nei paragrafi che seguono. 3.1.3.1 Quesiti Goal 1: Analizzare il processo 1. Analisi del problema GOAL 1 Caratterizzazione del processo Conformità del processo Q1.1 L azienda mette a disposizione documenti di analisi? Modello primario Q1.2 Qual è la percentuale di anomalie che vengono rigettate perché non riscontrate a runtime? Q1.3 Qual è la percentuale di anomalie che vengono rigettate perché non conformi al documento di analisi? Qualità di interesse Q1.4 Qual è la percentuale di anomalie che vengono rigirate al gruppo processi o ai DBA? Q1.5 Qual è la percentuale di anomalie che vengono rigettate? Modello di conferma Q1.6 Qual era la percentuale di anomalie da rigettare perché non riscontrate a runtime prevista? Q1.7 Qual era la percentuale di anomalie da rigettare perché non conformi al documento prevista? Q1.8 Qual era la percentuale di anomalie da rigirare al DBA o al gruppo processi prevista? 46/75
3.1.3.2 Quesiti Goal 2: Analizzare i processi 2. Sviluppo in locale e 3. Test GOAL 2 Caratterizzazione del processo Conformità del processo Q2.1 E stato previsto un corso di formazione riguardante il tool Tibco GI utilizzato per lo sviluppo? Q2.2 E stato previsto un corso di formazione riguardante il tool Tibco Designer utilizzato per lo sviluppo? Modello primario Qualità di interesse Q2.3 Qual è il tempo di correzione di un anomalia? Q2.4 Qual è la percentuale di anomalie chiuse che vengono riaperte? Modello di conferma Q2.5 Qual era il tempo previsto per la correzione di un anomalia? Q2.6 Qual era la percentuale di anomalie chiuse che venivano riaperte prevista? 3.1.3.3 Quesiti Goal 3: Analizzare il processo 3.Rilascio GOAL 3 Caratterizzazione del processo Conformità del processo Q3.1 E fornito dall azienda un template per la nota di rilascio? Q u Modello primario 47/75
Q3.2 Qual è la media di JAR rilasciati non corretti? Q3.3 Qual è la media di note di rilascio non corrette (errate, non complete o poco dettagliate)? Modello di conferma Q3.4 Qual era la media prevista di JAR rilasciati non corretti? Q3.5 Qual era la media prevista di note di rilascio errate, non complete o poco dettagliate? 48/75
3.1.4 Definizione dei Metriche Le metriche sono i dati operativi che devono essere raccolti e interpretati per rispondere alle Questions. 3.1.4.1 Metriche del goal 1 Goal 1 Question Metrica Etichetta Descrizione Tipo Q 1.1 M 1.1.1 Esiste_Doc Presenza di documentazione di analisi fornita dall azienda Osservata Q 1.2 M 1.2.1 TOT_Perc_Anom_ Non_runtime Percentuale Totale di anomalie rigettate perché non riscontrate a runtime Osservata Q 1.3 M 1.3.1 TOT_Perc_Anom_ Non_Doc Percentuale Totale di anomalie rigettate perché non conformi al documento Osservata Percentuale Totale di Osservata Q 1.4 M 1.4.1 TOT_Perc_Anom_ Non_GUI anomalie rigettate perché da rigirare al DBA o al gruppo Processi M 1.5.1 TOT_Perc_Anom_ Rig Percentuale Totale di anomalie rigettate Calcolata SVIL_ Percentuale Totale di Calcolata Q 1.5 M 1.5.2 Perc_Anomalie_N on_runtime anomalie rigettate da uno sviluppatore Numero di sviluppatori che si Osservata M 1.5.3 Num_sviluppatori occupano di manutenzione GUI TOT_Perc_Anom_ Percentuale prevista di Calcolata Q 1.6 M 1.6.1 Non_ anomalie rigettate perché non RunTime_Prev riscontrate a runtime Q 1.7 M 1.7.1 TOT_Perc_Anom_ Non_Doc_Prev Percentuale prevista di anomalie rigettate perché non conformi al documento Calcolata 49/75
Q 1.8 M 1.8.1 TOT_Perc_Anom_ Non_GUI_Prev Percentuale prevista di anomalie rigirate al DBA o al gruppo processi Calcolata 3.1.4.2 Metriche del goal 2 Goal 2 Question Metrica Etichetta Descrizione Tipo Q 2.1 M 2.1.1 Form_TibcoGI Q 2.2 M 2.2.1 Form_TibcoBW Presenza di un corso di formazione riguardante il Tool Tibco GI Presenza di un corso di formazione riguardante il Tool Tibco Business Works Osservata Osservata Q 2.3 M 2.3.1 Tempo_corre_An om Tempo di correzione di una singola anomalia Osservata Q 2.4 M 2.4.1 TOT_Perc_Anom_ Riaper Percentuale Totale di anomalie rigettate che vengono riaperte Osservata Q 2.5 M 2.5.1 Tempo_corre_An om_prev Tempo di correzione previsto per una singola anomalia Calcolata Q 2.6 M 2.6.1 TOT_Perc_Anom_ Riaper_Prev Percentuale prevista di anomalie rigettate che vengono riaperte Calcolata 3.1.4.3 Metriche del goal 3 Goal 3 Question Metrica Etichetta Descrizione Tipo Q 3.1 M 3.1.1 Esiste_Template Esitenza di un template per la nota di rilascio fornito dall azienda Osservata Q 3.2 M 3.2.1 Perc_JAR_Non_Co rr Percentuale dei JAR rilasciati non corretti Osservata Q 3.3 M 3.3.1 Perc_Rilasci_Non_ Corr Percentuale delle note di rilascio non corrette Calcolata 50/75
M 3.3.2 Perc_Rilasci_Errat i Percentuale delle note di rilascio contententi dati errati Osservata M 3.3.3 Perc_Rilasci_Inco mpleti Percentuale delle note di rilascio incomplete Osservata Q 3.4 M 3.4.1 Perc_JAR_Non_Co rr_prev Percentuale prevista dei JAR rilasciati non corretti Calcolata Q 3.5 M 3.5.1 Perc_Rilasci_Non_ Corr_Prev Percentuale prevista delle note di rilascio non corrette Calcolata 51/75
3.2 Fogli Metrici I fogli metrici consentono di effettuare controlli per la verifica di un GQM circa le ipotesi su cui si basa il modello di qualità, sia rispetto al dominio di conoscenza, sia rispetto all utilizzatore e al progetto e circa i parametri indipendenti che possono essere gestiti per migliorare il modello. I fogli metrici si dividono in quattro quadranti: 1. quality factors (quadrante in alto a sinistra): contiene i quesiti e le metriche del modello primario; 2. baseline hypothesis (quadrante in basso a sinistra): contiene i quesiti e le metriche del modello di conferma e di validità; 3. variation factors (quadrante in alto a destra): contiene i quesiti e le metriche per la conformità del processo; 4. baseline impact (quadrante in basso a destra): descrive la relazione tra i variation factors e le metriche del quality factors E stato definito un foglio metrico per ogni goal precedentemente descritto. 52/75
3.2.1 Foglio metrico goal 1
Goal 1 Oggetto dello studio Scopo Prospettiva Punto di vista Contesto Processo 1. Analisi del problema Valutazione capacità di analisi Team- Manager Progetto ManuntenzioneGUI-GQM Quality Factors [Q1.2, Q1.3, Q1.4, Q, 5] M 1.2.1 (TOT_Perc_Anom_Non_runtime) Percentuale Totale di anomalie rigettate perché non riscontrate a runtime M 1.3.1 (TOT_Perc_Anom_Non_Doc) Percentuale Totale di anomalie rigettate perché non conformi al documento Variation Factors [Q1.1] M 1.1.1 (Esiste_Doc) Presenza di documentazione di analisi fornita dall azienda M 1.4.1 (TOT_Perc_Anom_Non_GUI) Percentuale Totale di anomalie rigettate perché da rigirare al DBA o al gruppo Processi M 1.5.1 (TOT_Perc_Anom_Rig) Percentuale Totale di anomalie rigettate Baselines Hypothesis [Q1.6, Q 1.7, Q 1.8] TOT_Perc_Anom_Non_Doc<=TOT_Perc_Anom_Non_Doc_Prev: Percentuale di anomalie rigettate perché non conformi al documento TOT_Perc_Anom_Non_runtime<=TOT_Perc_Anom_Non_runtime_Prev: Percentuale di anomalie rigettate perché non riscontrate a runtime TOT_Perc_Anom_Non_GUI<=TOT_Perc_Anom_Non_GUI_Prev: Percentuale di anomalie rigirate al DBA o al gruppo processi. Baselines Impacts L esistenza di un documento di analisi sempre aggionato, rende possibile il riscontro di ogni anomalia sul documento per cui incide sulla TOT_Perc_Anom_Non_Doc e dunque anche sulla TOT_Perc_Anom_Rig 54/75
3.2.2 Foglio metrico goal 2 Goal 1 Oggetto dello studio Scopo Prospettiva Punto di vista Contesto Processi 2. Sviluppo in locale e 3. Test Valutazione capacità di implementazione e di test Sviluppatore Progetto ManuntenzioneGUI-GQM Quality Factors [Q 2.3, Q 2.4] M 2.3.1 (Tempo_corre_Anom) Tempo di correzione di una singola anomalia Variation Factors [Q2.1, Q2.2] M 2.1.1 (Form_TibcoGI) Presenza di un corso di formazione riguardante il Tool Tibco GI M 2.2.1 (Form_TibcoBW) Presenza di un corso di formazione riguardante il Tool Tibco Business Works Baselines Hypothesis [Q2.5, Q 2.6] Tempo_corre_Anom<=Tempo_corre_Anom_Prev : Tempo di risoluzione anomalia TOT_Perc_Anom_Riaper<=TOT_Perc_Anom_Riaper_Prev: Percentuale anomalie riaperte Baselines Impacts La presenza di un corso di formazione riguardante uno od entrambi i tool prevalentemente utilizzati, può aumentare l efficienza della correzione, incidendo sul Tempo_corre_Anom 55/75
3.2.3 Foglio metrico goal 3 Goal 1 Oggetto dello studio Scopo Prospettiva Punto di vista Contesto Processo 4. Rilascio Valutazione capacità di rilascio Sviluppatore Progetto ManuntenzioneGUI-GQM Quality Factors [Q3.2, Q3.3] M 3.2.1(Perc_JAR_Non_Corr) Percentuale dei JAR rilasciati non corretti M 3.3.1 (Perc_Rilasci_Non_Corr) Percentuale delle note di rilascio non corrette M 3.3.2 (Perc_Rilasci_Errati) Percentuale delle note di rilascio contententi dati errati Variation Factors [Q3.1] M 3.1.1 (Esiste_Template) Esitenza di un template per la nota di rilascio fornito dall azienda M 3.3.3 (Perc_Rilasci_Incompleti) Percentuale delle note di rilascio incomplete Baselines Hypothesis [Q3.4, Q3.5] Perc_JAR_Non_Corr<=Perc_JAR_Non_Corr_Prev: Percentuale prevista dei JAR rilasciati non corretti Perc_Rilasci_Non_Corr<= Perc_Rilasci_Non_Corr_Prev: Percentuale prevista delle note di rilascio non corrette Baselines Impacts L esistenza di un template può abbassare notevolmente la percentuale di note di rilascio non corrette, ovvero incidere su Perc_Rilasci_Errati, Perc_Rilasci_Incompleti e dunque su Perc_Rilasci_Non_Corr. 56/75
3.3 Tavole di Decisione La tavola di decisione associa ad ogni condizione del foglio metrico una interpretazione. La tavola di decisione ha, quindi, lo scopo di esprimere l interpretazione delle metriche con completezza e correttezza. Una tavola di decisione ha la seguente struttura: - Quadrante in alto a sinistra: elenca tutte le condizioni che regolano il modello di decisione; - Quadrante in basso a sinistra: elenca tutte le possibili iniziative di miglioramento che possono essere apportate; - Quadrante in alto a destra: contiene tutte le combinazioni di valori che possono assumere le condizioni; ogni combinazione è una regola di decisione; - Quadrante in basso a destra: elenca le iniziative di miglioramento da effettuare rispetto ad ogni regola di decisione; Nei paragrafi che seguono sono riportate tutte le tavole di decisione, una per ogni goal precedentemente descritto e ad oguna sono anche descritte le eventuali iniziative di miglioramento.
3.3.1.1 Tavola di deciosione goal 1 1.TOT_Perc_Anom_Non_Doc <= TOT_Perc_Anom_Non_Doc_Pre 2.TOT_Perc_Anom_Non_RunTime <= TOT_Perc_Anom_Non_RunTime_Pre > TOT_Perc_Anom_Non_RunTime_Pre 3.TOT_Perc_Anom_Non_GUI <= > TOT_Perc_Anom_Non TOT_Perc_Anom_Non GUI_Pre GUI_Pre <= TOT_Perc_Anom_No n_gui_pre > TOT_Perc_Anom_No n_gui_pre 1. Obiettivo Raggiunto x... 2. Azione 1.1.. x 3. Azione 1.2.. x x 4. Azione 1.3 x 1.TOT_Perc_Anom_Non_Doc > TOT_Perc_Anom_Non_Doc_Pre 2.TOT_Perc_Anom_Non_RunTime <= TOT_Perc_Anom_Non_RunTime_Pre > TOT_Perc_Anom_Non_RunTime_Pre 3.TOT_Perc_Anom_Non_GUI <= > <= > TOT_Perc_Anom TOT_Perc_Anom_Non_ TOT_Perc_Anom_Non_ TOT_Perc_Anom_Non Non_GUI GUI GUI GUI 1. Obiettivo Raggiunto. 2. Azione 1.1 x x x x
3. Azione 1.2. x x 4. Azione 1.3 x x Dove le azioni di miglioramento indicate sono le seguenti: Azione 1.1: Rigettare molte anomalie perché non conformi al documento può accadere se non si è sincronizzati al massimo con il gruppo dei test e questo può essere risolto aumentando la frequenza di aggionamento dei documenti di analisi. Azione 1.2: Rigettare molte anomalie perché non riscontrate a runtime può accadere quando gli ambienti di test e di sviluppo non sono equivalenti e questo può avvenire perché uno dei due non è aggiornato, per cui è necessario un frequente aggiornamento degli ambienti (variabili globali, librerie ) Azione 1.3: Rigettare anomalie perché non risultano come problemi della GUI ma ad esempio dei processi oppure del DB è abbastanza normale data la natura stessa della GUI, nonstante questo potrebbe essere pensabile un nuova modalità di assegnazione delle anomalie, in modo da una sua più efficiente distribuzione 59/75
3.3.1.2 Tavola di deciosione goal 2 1. Tempo_corre_Anom <= Tempo_corre_Anom_Pre > Tempo_corre_Anom_Pre 2. TOT_Perc_Anom_Riaper <= > <= > TOT_Perc_Anom_Riaper_ TOT_Perc_Anom_Riaper TOT_Perc_Anom_Riaper_ TOT_Perc_Anom_Riaper Pre _Pre Pre _Pre 1. Obiettivo Raggiunto x... 2. Azione 2.1.. x x 3. Azione 2.2. x x Dove le azioni di miglioramento indicate sono le seguenti: Azione 2.1: Se il tempo di correzione di una anomalia è più alto della media possono essere necessari corsi di formazione mirati al tool usato oppure è necessario assumere risorse più skillate già a priori Azione 2.2: Maggiori attenzione e precisione nello sviluppo ma soprattutto maggiore effiecienza nei test fatti in locale prima dei rilasci 60/75
3.3.1.3 Tavola di decisione goal 3 1. Perc_JAR_Non_Corr <= Perc_JAR_Non_Corr_Prev > Perc_JAR_Non_Corr_Prev 2. Perc_Rilasci_Non_Corr <= > <= > Perc_Rilasci_Non_Corr_ Prev Perc_Rilasci_Non_Corr_ Prev Perc_Rilasci_Non_Corr_ Prev Perc_Rilasci_Non_Corr_ Pre 1. Obiettivo Raggiunto x 2. Azione 2.1 x x 3. Azione 2.2 x x Dove le azioni di miglioramento indicate sono le seguenti: Azione 2.1: Possono essere necessari corsi di formazione mirati al tool usato oppure è necessario assumere risorse più skillate già a priori Azione 2.2: Se non esiste sarebbe opportuno definire un template della nota di rilascio in modo da ridurre al minimo gli errori e/o incompletezze. 61/75
3.4 Piano di Misurazione In questa sezione sono riportate tutte le metriche osservate cioè quelle metriche misurate direttamente su un processo. Per ogni metrica sono specificate le caratteristiche e le modalità di esecuzione. 3.4.1 Misure osservate goal 1 M 1.1.1 (Esiste_Doc) Definizione: Presenza di documentazione di analisi fornita dall azienda. Tipo: Oggettiva Linee Guida: - Chi misura: Team Manager - Quando misura: prima di iniziare lo sviluppo/manutenzione GUI Specifiche: - Come misura: per valutare tale metrica è necessario analizzare il processo aziendale e scegliere uno dei seguenti valori: Si: La documentazione è disponibile No: La documentazione non è disponibile M 1.2.1 TOT_Perc_Anom_Non_runtime Definizione: Percentuale Totale di anomalie rigettate perché non riscontrate a runtime Tipo: Soggettiva Linee Guida: - Chi misura: Team Manager - Quando misura: in fase di analisi delle anomalie. Specifiche: - Come misura: per valutare tale metrica è necessario analizzare il manufatto M4 Anomalie non riscontrate a runtime : Molto bassa: Percentuale < 10 % Bassa: Percentuale [10%, 20 %] Media: Percentuale [20%, 30 %] Alta: Percentuale [30%, 50%] Molto Alta: Percentuale > 50%