Università degli Studi di Salerno

Università degli Studi di Salerno Corso di Gestione Dei Progetti Software Quality Report Versione 2.0 29/06/2009

Coordinatore del progetto: Nome Matricola Angelo D Amato Andrea De Lucia Rocco Uliveto Scritto da: Angelo D Amato Revision History Data # Versione Descrizione Autore 23/03/2009 1.0 Creazione e strutturazione del documento Angelo D Amato 03/04/2009 1.2 Definizione prima bozza delle metriche di qualità Angelo D Amato 21/05/2009 1.3 Aggiornamento per secondo quality report Angelo D Amato 29/06/2009 2.0 Calcolo di metriche di qualità sul codice Angelo D Amato Gestione dei progetti software,2009 Pagina 2 of 28

Indice 1. INTRODUZIONE... 4 1.1 OBIETTIVI DEL DOCUMENTO... 4 2. METRICHE DI PROCESSO... 5 2.1.1 DRE... 5 2.2 METRICHE DI PRODOTTO... 5 2.2.1 Structure101 XS metrics... 5 2.2.1.1 Report generato da structure101... 5 2.2.1.2 Gui Complexity... 9 2.2.2 Application Complexity... 10 2.2.3 Storage Complexity... 10 2.2.4 Conclusioni... 11 2.2.5 Sonar... 13 2.2.5.1 Indicatori di Sonar... 13 2.2.5.2 Valutazione con Sonar... 14 2.2.5.3 Conclusioni... 22 2.3 METRICHE SUI DOCUMENTI... 23 2.3.1 Specifici RAD... 23 2.3.1.1 SD/UC... 23 2.3.1.2 Gulpease Index... 24 Gestione dei progetti software,2009 Pagina 3 of 28

1. Introduzione 1.1 Obiettivi del documento Lo scopo principale del presente documento è quello di riportare i risultati ottenuti in data 28/06/2009 (giorno precedente alla data di consegna di questo documento) e gli obiettivi di qualità raggiunti. Le metriche proposte al interno del Quality Plan verranno applicate agli artefatti attualmente completati, in modo da poter misurare il grado di qualità effettivamente raggiunto. Definizione degli item sottoposti ad analisi di qualità, di seguito è riportato l elenco completo degli item sottoposti ad analisi di qualità: Requirement Analysys Document (RAD) System Design Document (SDD) Codice Gestione dei progetti software,2009 Pagina 4 of 28

2. Metriche di processo 2.1.1 DRE Metrica non applicabile per mancanza di tempo. 2.2 Metriche di prodotto 2.2.1 Structure101 XS metrics Ricordiamo il livello di XS calcolato per il sistema deve essere uguale a 0. Questo indicatore permette di essere sicuri di tenere l eccessiva complessità strutturale del sistema sotto controllo in modo da ridurre i costi di manutenzione e estensione delle funzionalità del sistema stesso. Non ci deve essere più di un tangle nel grafo delle dipendenze dei package di alto livello. 2.2.1.1 Report generato da structure101 Gestione dei progetti software,2009 Pagina 5 of 28

Gestione dei progetti software,2009 Pagina 6 of 28

2.2.1.2 Gui Complexity Gestione dei progetti software,2009 Pagina 9 of 28

2.2.2 Application Complexity 2.2.3 Storage Complexity Gestione dei progetti software,2009 Pagina 10 of 28

2.2.4 Conclusioni Dal report si evince che ci sono più di un tangle al livello di design. Esattamente notiamo che ci sono due di questa tipologia di violazione. Gestione dei progetti software,2009 Pagina 11 of 28

E di seguito vengono mostrate le classi e i metodi che aumentano la complessità eccessiva del sistema. Che bisogna andare ad analizzare per una diminuzione della complessità totale del sistema. Gestione dei progetti software,2009 Pagina 12 of 28

2.2.5 Sonar 2.2.5.1 Indicatori di Sonar Gestione dei progetti software,2009 Pagina 13 of 28

2.2.5.2 Valutazione con Sonar Il numero di commenti 22.9% è in linea con le metriche definito però c è di contro che sono state documentate soltanto il 73% delle api del sistema e questo non è consigliabile per l indice di modificabilità e comprensibilità del sistema. Il 3% di duplicazioni è un altro valore che dovrebbe essere corretto, codice duplicato comporta anch esso problemi di comprensibilità e modificabilità del sistema. Per quanto riguarda le violazioni esempi di violazioni sono : Gestione dei progetti software,2009 Pagina 14 of 28

La complessità per classe non dovrebbe superare in media nel progetto il valore 10. Gestione dei progetti software,2009 Pagina 16 of 28

Nella seguente pagina ci sono classi mostrate con rapporto Complessità/Rule compliance con una schermata sulle classi che comportano rischi al progetto. Gestione dei progetti software,2009 Pagina 20 of 28

2.2.5.3 Conclusioni INDICATORE VALORE SOGLIA VIOLAZIONE Code coverage 100% SI Test success 100% NO Rule Compliance 90% SI Commenti 20% - 30% NO Duplicazione del 0% SI codice Qualità totale 70% NO Gli altri indicatori sono segnalati con un simbolo rosso se il valore supera il threshold definiti nel quality plan che coincidono con i valori standard inclusi in Sonar Gestione dei progetti software,2009 Pagina 22 of 28

2.3 Metriche sui documenti 2.3.1 Specifici RAD 2.3.1.1 SD/UC Riepilogo METRICA Alta 0.8< SD/UC <= 1 Media 0.4<= SD/UC <= 0.8 Bassa SD/UC < 0.4 Per poter effettuare la misurazione sono stati effettuati i seguenti passi: Conteggio dei Sequence Diagram Risultato emerso: 80 Conteggio dei Casi d uso Risultato emerso: 124 Calcolo del rapporto SD/UC Risultato emerso: 0.65 Dunque, per quel che concerne la metrica in esame, il livello di qualità fatto registrare dal RAD può essere ritenuto: Medio. Gestione dei progetti software,2009 Pagina 23 of 28

2.3.1.2 Gulpease Index Riepilogo metrica Indice Valutazione >79 Molto comprensibile 60-79 Comprensibile 50-59 Difficile da comprendere 35-49 Molto difficile da comprendere <35 Incomprensibile 2.3.1.2.1 RAD Indice di gulpeace = 92,38 IL RAD NE RISULTA MOLTO COMPRENSIBILE Gestione dei progetti software,2009 Pagina 24 of 28

2.3.1.2.1 SDD Indice di gulpeace = 70,05 L SDD NE RISULTA COMPRENSIBILE Gestione dei progetti software,2009 Pagina 25 of 28

2.3.1.2.1 DB Specification Indice di gulpeace = 89,98 Il DB SPECIFICATION NE RISULTA MOLTO COMPRENSIBILE Gestione dei progetti software,2009 Pagina 26 of 28

2.3.1.2.1 TP Indice di gulpeace = 97,22 Il TP NE RISULTA MOLTO COMPRENSIBILE Gestione dei progetti software,2009 Pagina 27 of 28

2.3.1.2.1 Manuale utente Indice di gulpeace = 68,15 Il MANUALE UTENTE NE RISULTA COMPRENSIBILE Gestione dei progetti software,2009 Pagina 28 of 28