Metodi e obiettivi di quantificazione

Transcript

1 Misurare Metodi e obiettivi di quantificazione Ingegneria del Software V. Ambriola, G.A. Cignoni, C. Montangero, L. Semini Aggiornamenti di: T. Vardanega (UNIPD) Un attività quotidiana Per grandezze fisiche: massa, lunghezza, velocità Per grandezze economiche: prezzi, indici, inflazione,... Per altri fattori immateriali: gradimento, reddito, caratteristiche fisiche, Si misura per conoscere Si misura per giudicare Semplificazione e imprecisione possono avere effetti distorsivi Dipartimento di Informatica, Università di Pisa 1/36 Dipartimento di Informatica, Università di Pisa 2/36 Scienza e misura Misura e metrica Finalità della misura Rendere oggettivi i risultati degli esperimenti effettuati Avere dati affidabili su cui basare modelli matematici L oggettività della misura implica ripetibilità, confrontabilità, confidenza Ogni misura ha limiti intrinseci Approssimazione nella misura di realtà fisiche Astrazione nella misura di valutazione o di stima di concetti Misurazione Processo che assegna numeri o simboli ad attributi di entità del mondo reale per descriverle secondo regole definite 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 fissare le entità da misurare, gli attributi rilevanti, l unità di misura, la procedura per assegnare e interpretare i valori Dipartimento di Informatica, Università di Pisa 3/36 Dipartimento di Informatica, Università di Pisa 4/36

2 Indicatori Le metriche nella produzione Per caratteristiche difficilmente misurabili La misura desiderata può essere ottenuta indirettamente a partire da altre misure ottenute tramite stime o predizioni Servono metriche per stimare caratteristiche Identificando gli attributi misurabili Determinando indicatori per le caratteristiche non misurabili Metrica secondo il glossario SWE di IEEE Misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, componente, processo Strumenti di valutazione e controllo Entità da misurare Processi insiemi correlati di procedure astratte Progetti attività concrete legate a tempo e risorse Prodotti beni e servizi in uscita dai progetti Risorse elementi impiegati e consumati dal progetto Categorie di attributi Interni misurabili rispetto alle entità Esterni misurabili rispetto all ambiente Dipartimento di Informatica, Università di Pisa 5/36 Dipartimento di Informatica, Università di Pisa 6/36 Obiettivi della misurazione nel SW Importanza della misurazione Valutare lo stato di Progetti stime, preventivi e consuntivi di costo e di tempo Prodotti qualità Processi qualità (capability, maturity), miglioramenti Risorse consumo Interpretare e cogliere tendenze In modo proattivo piuttosto che reattivo Decidere azioni correttive Magari privilegiando il maggiore effetto per il minor costo Misura ciò che è misurabile e rendi misurabile ciò che non lo è Galileo Galilei ( ) If you cannot measure it, you cannot improve it Lord William Thomson Kelvin ( ) You can't control what you can't measure Tom de Marco (1940, -) Dipartimento di Informatica, Università di Pisa 7/36 Dipartimento di Informatica, Università di Pisa 8/36

3 Processo di misurazione Visione globale di O/IEC Strategie e discipline (Come definire) Cosa misurare O/IEC Software Measurement Process Measurement Information Model: descrive i valori di misurazione da produrre e le relazioni tra loro Measurement Process Model: descrive il processo di misurazione Come misurare Linee guida (p.es. Practical Software Measurement) Cosa e perché CMMI Dipartimento di Informatica, Università di Pisa 9/36 Dipartimento di Informatica, Università di Pisa 10/36 Bisogni informativi Esempio 1 Secondo O the information needs are based on goals, constraints, risks, and problems which originate from the technical and mgmt processes CMMI suggerisce di determinarli nelle seguenti aree Requirements Management Design & Implementation Verification & Validation (V&V) Quality Assurance Configuration Management Project Management Risk analysis & decision analysis Training Dipartimento di Informatica, Università di Pisa 11/36 Per i responsabili di progetto Quale è il costo del processo? Quale è la produttività degli sviluppatori? Quale è la qualità dei prodotti? Per gli sviluppatori Quanto verificabili sono i requisiti? Abbiamo soddisfatto tutti i requisiti? Abbiamo rimosso tutti i difetti? Dipartimento di Informatica, Università di Pisa 12/36

4 Un semplice modello di produttività Esempio 2 (CMMI level 2) Quality Value Reliability Defects Size Quantity Productivity Time Functionality Cost Personnel Resources Complexity Money Dipartimento di Informatica, Università di Pisa 13/36 HW SW Environmental Constraints Problem difficulty Requirements Management Quanto le pratiche in uso aderiscono a quelle di riferimento Quanto i prodotti del progetto soddisfano i requisiti Risk analysis Quali rischi gravano attualmente sul progetto e quanto Configuration Management Quale è l impatto di una eventuale modifica Quale è il grado di integrità delle baseline di progetto Project Management Quanto sono affidabili i preventivi e quanto accurati i consuntivi Quanto efficaci sono le misure correttive quando concretamente adottate Quality Assurance Quanto le pratiche in uso aderiscono a quelle di riferimento Quanto i prodotti del progetto soddisfano le aspettative Dipartimento di Informatica, Università di Pisa 14/36 Lead time Metriche software Metrica di project management Misura il tempo di calendario che intercorre tra un ordine di sviluppo (ticket) e la relativa consegna Problema aperto Il software è difficile da misurare Il software ha caratteristiche multiformi Le tecnologie cambiano rapidamente L ambiente di esecuzione ha una grande influenza LT : lead time WiP : work in progress Tipi di metriche Del prodotto in sé Delle sue funzionalità Del suo comportamento quanto è grande cosa deve fare e come lo fa cosa succede e quando Dipartimento di Informatica, Università di Pisa 15/36 Dipartimento di Informatica, Università di Pisa 16/36

5 Metriche progettuali Metriche di programmazione Grado di coesione Bieman, IEEE TSE 20:8, 1994 Grado di accoppiamento Dhama, Elseview JSS 29:1, 1995 Complessità strutturale Funzione del fan-out Complessità del flusso dati Funzione del # di parametri di ingresso e uscita, e della CS Complessità del sistema Funzione di CS e CFD Software Metrics, Norman Fenton Dipartimento di Informatica, Università di Pisa 17/36 SLOC: 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à Rapportata alla densità di commenti Limiti Dipendente da sintassi e potenza espressiva del linguaggio Dipendente dallo stile di codifica Dipartimento di Informatica, Università di Pisa 18/36 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 Limiti 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 della procedura 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 calcolarlo usando strumenti automatici Dipartimento di Informatica, Università di Pisa 19/36 Dipartimento di Informatica, Università di Pisa 20/36

6 Complessità ciclomatica 3 Complessità ciclomatica 4 Definizione algebrica costruita sopra il grafo di controllo G che descrive una procedura 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: 1 predecessore, 1 successore) Esempio: sequenza, v(g) Errore in difetto La complessità reale è maggiore di quella misurata Esempio: decisione, v(g) 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 ); } Dipartimento di Informatica, Università di Pisa 21/36 Dipartimento di Informatica, Università di Pisa 22/36 Complessità ciclomatica 5 Esempio Errore in eccesso La complessità reale è inferiore a quella misurata Esempio, v(g) switch visto come una sequenza di if annidati v(g) C 1 Dove C è il numero dei casi Dipartimento di Informatica, Università di Pisa 23/36 public void isvalidsearchcriteria(searchcriteria s) { if(s!=null) { return true; } else { CC = 2 return false; } } Per approfondire: Dipartimento di Informatica, Università di Pisa 24/36

7 Osservazioni empiriche Standard per misure funzionali 1 Probabilità di malfunzionamento Complessità ciclomatica 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 Dipartimento di Informatica, Università di Pisa 25/36 Dipartimento di Informatica, Università di Pisa 26/36 Standard per misure funzionali 2 Misure interne ed esterne Le metriche tecniche dipendono dalla tecnologia Che è variabile nel tempo! Utili come vista interna per stimare il costo di produzione O/IEC (functional size measurement) 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 Esempi di misure interne Numero di requisiti, loro volatilità Function Points, Use Case Points Coesione, accoppiamento, fan-in / fan-out SLoC, complessità ciclomatica Grado di copertura delle prove Esempi di misure esterne O/IEC (confluito in 25010:2015): valutazione delle 6 caratteristiche di qualità di prodotto Dipartimento di Informatica, Università di Pisa 27/36 Dipartimento di Informatica, Università di Pisa 28/36

8 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) Conta le funzionalità differenziate per categorie e pesate in base ad attributi del prodotto Of-SCOPE/scope-viewer Misurazioni diverse possono dare risultati diversi Corrispondente interessante negli Use Case Points tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/ 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 29/36 Dipartimento di Informatica, Università di Pisa 30/36 Function Point 3 Metriche per software OO Complessità Componente Bassa Media Alta EI EO EQ ILF EIF Totale 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 31/36 Dipartimento di Informatica, Università di Pisa 32/36

9 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 complessità dell interfaccia del metodo complessità delle variabili locali complessità ciclomatica del codice peso determinato statisticamente Complessità di una classe complessità dell interfaccia della classe complessità locale complessità locale esterna complessità locale interna complessità degli attributi locali complessità dei metodi locali costante o CC di classe attributo peso determinato statisticamente Dipartimento di Informatica, Università di Pisa 33/36 Dipartimento di Informatica, Università di Pisa 34/36 Metrica per i sistemi Riferimenti 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 Metriche utilizzabili come fattori d influenza NC NRC NLC Numero totale di classi Numero di classi radice Numero di classi foglia Dipartimento di Informatica, Università di Pisa 35/36 T.J. McCabe, A Complexity Metric, IEEE Trans. on Software Engineering, 1976 A.J. Albrecht, J.E. Gaffney. Software Function, [ ]: A Software Science Validation, IEEE Trans. on Software Engineering, 1983 N.E. Fenton, S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, II Ed., Int. Thompson Computer Press, 1997 B. Boehm et al., Cost Models for Future Software Life Cycle Processes: CoCoMo II, Dipartimento di Informatica, Università di Pisa 36/36