Misurazione del software

Transcript

1 Misurare Misurazione del software Corso di Ingegneria del Software V. Ambriola, G.A. Cignoni, C. Montangero, L. Semini Con aggiornamenti di: T. Vardanega Un attività quotidiana Grandezze fisiche: massa, lunghezza, velocità Grandezze economiche: prezzi, inflazione, PIL, AEX, Di tutto di più: gradimento, reddito, caratteristiche fisiche, Misurare per conoscere Misurare per giudicare L effetto di semplificazione e imprecisione Dipartimento di Informatica, Università di Pisa 1/33 Dipartimento di Informatica, Università di Pisa 2/33 Scienza e misura Misurazione Finalità della misura Rendere oggettivi i risultati degli esperimenti Oggettività implica ripetibilità, confronto, confidenza Avere dati da cui ricavare modelli matematici Limiti intrinseci della misura È una approssimazione misure di realtà fisiche È una astrazione misure per valutare o stimare Misurazione Processo che assegna numeri o simboli ad attributi di entità del mondo reale, per descriverle secondo regole definite Concetti rilevanti (esempi) Entità Attributo Valore Persona Età 18 (anni) Semaforo Stato rosso Programma Dimensione 75 (LoC) Dipartimento di Informatica, Università di Pisa 3/33 Dipartimento di Informatica, Università di Pisa 4/33 Processo di misurazione 1 Processo di misurazione 2 Obiettivo Caratterizzare la prestazione di un prodotto o di un processo Valutare la prestazione a posteriori Per distanza rispetto a valori attesi Fare previsioni di prestazione a priori Quantificare i miglioramenti prestazionali Per fini di Software Process Improvement Strategie e discipline Cosa misurare: O/IEC Software Measurement Process Measurement Information Model: descrizione dei valori di misurazione da produrre e delle relazioni tra loro Measurement Process Model: descrizione del processo di misurazione (in conformità con O/IEC 12207) Come misurare: linee guida (p.es. Practical Software Measurement) Con quale accuratezza: CMMI Dipartimento di Informatica, Università di Pisa 5/33 Dipartimento di Informatica, Università di Pisa 6/ Corso di Ingegneria del Software 1

2 Visione globale di O/IEC Misura e metrica Misura Risultato della misurazione Assegnazione empirica e oggettiva di un valore (numerico o simbolo) a un entità, per caratterizzarne un attributo specifico Metrica = insieme di regole Per stabilire le entità da misurare Per definire gli attributi rilevanti Per definire l unità di misura Per definire una procedura per assegnare e interpretare numeri e simboli Dipartimento di Informatica, Università di Pisa 7/33 Dipartimento di Informatica, Università di Pisa 8/33 Indicatori Le metriche nella produzione Per caratteristiche difficilmente misurabili La misura desiderata può essere ottenuta indirettamente a partire da altre misure trattate tramite stime o predizioni Metriche usate per stimare caratteristiche Identificare attributi misurabili Stimare (con incertezza) caratteristiche non misurabili Esempio La dimensione del software è un attributo misurabile La manutenibilità è un attributo stimato tramite indicatori Strumenti di valutazione e controllo Entità da misurare Processi Progetti Prodotti Risorse insiemi correlati di procedure astratte attività concrete legate a tempo e risorse beni e servizi in uscita dai progetti elementi impiegati (e consumati) dal progetto per produrre prodotti Categorie di attributi Attributi interni misurabili rispetto alle entità Attributi esterni misurabili rispetto all ambiente Dipartimento di Informatica, Università di Pisa 9/33 Dipartimento di Informatica, Università di Pisa 10/33 Metriche software Linee di codice sorgente (SLOC) Problema aperto Il software è difficile da misurare Il software ha caratteristiche multiformi Le tecnologie cambiano rapidamente L ambiente di esecuzione ha una grande influenza Tipi di metriche Del prodotto in sé Delle sue funzionalità Del suo comportamento quanto è grande cosa deve fare cosa succede e quando La metrica più intuitiva e più usata Conteggio dei costrutti / comandi Semplificato e adattato alle funzionalità degli editor Usata per derivare informazioni di costo e produttività Dipendente da sintassi e potenza espressiva del linguaggio Dipendente dallo stile di codifica Dipartimento di Informatica, Università di Pisa 11/33 Dipartimento di Informatica, Università di Pisa 12/ Corso di Ingegneria del Software 2

3 Software Science 1 Maurice H. Halstead, Elements of Software Science, Elsevier, 1977 Complessità del codice Misura a posteriori (molto più facile che a priori!) Controversa Basata sul numero e sul tipo dei costrutti Basata su elementi di psicologia cognitiva e statistica Adatta solo ai primi linguaggi di programmazione Oggi è statisticamente inefficace Dipartimento di Informatica, Università di Pisa 13/33 Software Science 2 Unità di misura n1 = numero di operatori distinti usati dal programma n2 = numero di operandi distinti usati dal programma N1 = numero di occorrenze degli operatori N2 = numero di occorrenze degli operandi Per determinare (tra l altro) * La dimensione N di un programma N = n1 log 2 n1 + n2 log 2 n2 tipicamente si ha N = (N1+N2) * Il volume V di un programma V = (N1+N2) log 2 (n1+n2) V varia al variare del linguaggio di programmazione Halstead assegna un valore (livello) I come costante di linguaggio ma la ricerca ha mostrato che essa dipende anche dal programmatore Dipartimento di Informatica, Università di Pisa 14/33 Complessità ciclomatica 1 Complessità ciclomatica 2 Proposta da Thomas McCabe nel 1976 Indipendente dal linguaggio di programmazione Complessità del flusso di controllo Funzione dei possibili cammini indipendenti all interno di un singolo sottoprogramma Misurazione astratta di un attributo significativo del codice Fallibilità dimostrata Nonostante ciò ancora largamente usata Costosa da applicare prima di progettare il codice in dettaglio Il valore rilevato va confrontato con soglie prefissate P.es.: [1, 10] complessità bassa; [21, 50] complessità elevata; [51, ) complessità inaccettabile Corrisponde al numero di casi di prova necessari per verificare ogni possibile esito di ogni ramo di decisione all interno del sottoprogramma Misura la complessità del flusso di controllo ma non la complessità del flusso dei dati Il grado di fan-in e fan-out applicato ai dati può aiutare a stimare la complessità del flusso dei dati Meglio usare strumenti automatici Dipartimento di Informatica, Università di Pisa 15/33 Dipartimento di Informatica, Università di Pisa 16/33 Fan-in e Fan-out Complessità ciclomatica 3 Fan-in e fan-out strutturale SFIN è indice di uso Misura di utilità SFOUT è indice di accoppiamento M Misura di dipendenza Allo stesso livello di astrazione! Fan-out Analogo per il flusso dei dati Indice di utilità Fan-in Indice di dipendenza Definizione algebrica v(g) = e n + p e n p numero di percorsi lineari in G numero degli archi (flusso) numero dei nodi (espressioni o comandi) numero delle componenti connesse da ogni arco (p = 2 per esecuzione sequenziale) Esempio, una sequenza, v(g) = = 1 Dipartimento di Informatica, Università di Pisa 17/33 Dipartimento di Informatica, Università di Pisa 18/ Corso di Ingegneria del Software 3

4 Complessità ciclomatica 4 Complessità ciclomatica 5 Errore in difetto La complessità reale è maggiore di quella misurata Esempio, v(g) = = 3 Ma il codice sorgente è offuscato! int _INT = 1 ; int INT_ = 0; int Int_ ( int _int ) { if (_int == INT_) return _INT ; else return _int * Int_ ( _int _INT ) ; } Errore in eccesso La complessità reale è inferiore a quella misurata Esempio, v(g) = = 4 switch visto come una sequenza di if annidati v(g) = C + 1 C numero dei casi (= 3) Dipartimento di Informatica, Università di Pisa 19/33 Dipartimento di Informatica, Università di Pisa 20/33 Function Point 1 Function Point 2 Allan J. Albrecht e John E. Gaffney, IEEE TSE 1983 Non misura il software ma le sue entità logico-funzionali Dimensione di progetto e di produttività in relazione ai requisiti funzionali Indipendente dal linguaggio di programmazione International Function Point User Group (IFPUG) Conteggio dei punti funzione Funzionalità differenziate per categorie Pesate in base ad attributi del prodotto Misurazioni diverse possono dare risultati leggermente diversi Risultati ottimali per sistemi gestionali Ha un corrispondente in UML negli Use Case Points Componenti misurate External Input (EI) External Output (EO) External Inquiry (EQ) Internal Logical File (ILF) External Interface File (EIF) Definizione Processo elementare a seguito del quale dati entrano nella componente misurata Processo elementare a seguito del quale dati escono dalla componente Processo elementare per il quale specifici dati interni sono richiesti alla componente e da essa emessi Gruppo di dati correlati interni alla componente e alimentati tramite EI Gruppo di dati correlati esterni alla componente e usati come riferimento Dipartimento di Informatica, Università di Pisa 21/33 Dipartimento di Informatica, Università di Pisa 22/33 Function Point 3 Punti oggetto Unadjusted FP (grezzo) Ciascuna componente viene associata a uno specifico grado di complessità Ogni componente pesa quanto il suo grado di complessità Adjusted FP (raffinato) 14 fattori d influenza (IF) Ciascuno con peso da 0.00 a 0.05 AFP = UFP ( Σ IF) Componente EI EO EQ ILF EIF Bassa Complessità Media Alta Totale Boehm et al., 1995, insieme a COCOMO 2.0 Conteggio delle componenti Tipo semplice medio difficile Screen Report GL Component Fattore di aggiustamento rispetto alla percentuale di riuso Dipartimento di Informatica, Università di Pisa 23/33 Dipartimento di Informatica, Università di Pisa 24/ Corso di Ingegneria del Software 4

5 Standard per misure funzionali 1 Standard per misure funzionali 2 O/IEC Functional size measurement Definire la terminologia del settore Definire i criteri per valutare le metriche funzionali Definire i criteri per accreditare i professionisti che le usano Concetti definiti Accuratezza di una misura funzionale Accuratezza di una metrica funzionale Ripetibilità e riproducibilità di una metrica funzionale Soglia di sensibilità di una metrica funzionale Applicabilità a un dominio funzionale Le metriche tecniche dipendono dalla tecnologia Che è variabile nel tempo! Utili come vista interna per stimare il costo di produzione O/IEC aiuta a orientarsi verso metriche funzionali Che possono fornire valori di misura più significativi Utili come vista esterna per stimare il prezzo di vendita La misurazione è resa indipendente dalla fase del progetto A meno delle richieste esplicite di cambiamento Dipartimento di Informatica, Università di Pisa 25/33 Dipartimento di Informatica, Università di Pisa 26/33 Misure interne ed esterne Metriche per software OO Misure interne (esempi) Numero di requisiti, loro volatilità Function Points, Use Case Points Coesione, accoppiamento, fan-in / fan-out SLoC, complessità ciclomatica Livello di copertura delle prove Misure esterne (esempio) O/IEC Occorrono metriche dedicate Le metriche tradizionali non sono accurate Complessità funzionale e complessità strutturale Non linearità del codice La misura SLOC non funziona! Uso di strutture e funzioni complesse McCabe non funziona come misura assoluta! Metriche per i metodi Metriche per le classi Metriche per i sistemi Dipartimento di Informatica, Università di Pisa 27/33 Dipartimento di Informatica, Università di Pisa 28/33 Metrica per i metodi Metrica per le classi Un metodo è sostanzialmente procedurale Si può usare McCabe come metrica di base Corretta per tenere conto di interfacce e variabili locali Complessità di un metodo MC = w 1 MIC + w 2 MLVC + w 3 MCC MIC complessità dell interfaccia del metodo MLVC complessità delle variabili locali MCC complessità ciclomatica del codice w i pesi determinati statisticamente Complessità di una classe CC = w 3 CCL + w 4 CCI CCI complessità dell interfaccia della classe CCL = w 5 ECCL + w 6 ICCL complessità locale ECCL = Σ j MIC j complessità locale esterna ICCL = w 7 CACL + w 8 CMCL complessità locale interna CACL = Σ h CA h complessità degli attributi locali CMCL = Σ k MC k complessità dei metodi locali CA costante o CC di classe attributo w i pesi determinati statisticamente Dipartimento di Informatica, Università di Pisa 29/33 Dipartimento di Informatica, Università di Pisa 30/ Corso di Ingegneria del Software 5

6 Metrica per i sistemi Qualità delle metriche Proprietà della metrica per le classi Considera solo la parte locale della classe Considera la complessità dell uso delle classi negli attributi Complessità del sistema SC = Σ n CC n Metriche utilizzabili come fattori d influenza NC NRC NLC Numero totale di classi Numero di classi radice Numero di classi foglia Precisione In termini di esattezza e ripetibilità rispetto ai valori prodotti SLOC e McCabe sì FP no (questione di maturità) Aderenza alla realtà La misura corrisponde all evidenza sperimentale Quando le metriche sono usate come indicatori Accuratezza Corrispondenza con la percezione o la realtà effettiva Dipartimento di Informatica, Università di Pisa 31/33 Dipartimento di Informatica, Università di Pisa 32/33 Riferimenti N.E. Fenton, S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, II Ed., Int. Thompson Computer Press, 1997 A.J. Albrecht, J.E. Gaffney. Software Function, [ ]: A Software Science Validation, IEEE Trans. on Software Engineering, 1983 A. Alessandroni, La stima dei costi dei sistemi informativi automatizzati, CNIPA, B. Boehm e altri, Cost Models for Future Software Life Cycle Processes: CoCoMo II, Centre for Software Engineering, P. Nesi, T. Querci, Stima della complessità e analisi di sistemi object oriented, De qualitate, 1996 Dipartimento di Informatica, Università di Pisa 33/ Corso di Ingegneria del Software 6