1/XX Outline Parte 1: La Qualità del Software- Modelli di Qualità- McCall e ISO 9126 Parte 2: Metriche del Software 2/XX 1
Riferimenti I. Sommerville Ingegneria del Software 8a edizione Cap. 27 R. Pressman Principi di Ingegneria del Software 5a edizione italiana - Cap. 17 Ghezzi, Jazayeri, Mandrioli, Ingegneria del Software, 2a edizione, Capitolo 2 International Standard ISO/IEC 9126 3/XX Che cos è la Qualità del Software? La qualità del software può essere definita come: conformità ai requisiti funzionali e prestazionali enunciati esplicitamente, agli standard di sviluppo esplicitamente documentati, a caratteristiche implicite che è lecito aspettarsi da un prodotto professionale [Pressman] Tre punti fondamentali: I requisiti sono il fondamento su cui misurare la qualità; Gli standard di qualità definiscono I criteri da seguire nello sviluppo software; Esistono requisiti impliciti (spesso taciuti) la cui assenza compromette la qualità del software. 4/XX 2
Che cos è la Qualità del Software? Alcuni problemi nella definizione di qualità introdotta... Le specifiche software sono in genere incomplete e spesso inconsistenti; Alcuni requisiti di qualità sono difficili da specificare in maniera non ambigua; Può esistere contrapposizione fra i requisitidi qualità attesidal cliente (efficienza, affidabilità, etc.) e quelli dello sviluppatore (manutenibilità, riusabilità, etc.); Alcuni requisiti di qualità sono difficili da valutare: non possiamo valutarli direttamente, ma soltanto indirettamente 5/XX Il problema fondamentale della qualità del software Non possiamo valutare la qualità del software in assoluto, ma solo alcune sue manifestazioni! Ciò equivale a dire che non possiamo valutare direttamente la qualità del software, ma indirettamente, attraverso la valutazione di attributi che si correlano a questa, supponendo che la relazione tra la qualità e questi attributi sia valida! Ad esempio: non posso misurare l usabilità e la manutenibilità in assoluto, ma debbo riferirmi ad altri attributi misurabili correlati ad esse. Abbiamo dunque bisogno di modelli di qualità condivisi! 6/XX 3
Come caratterizzare la Qualità del Software? La qualità di un prodotto software si caratterizza attraverso un insieme finito e definito di attributi ragionevolmente esaustivi in modo che per una qualsiasi richiesta di caratteristica di qualità sia possibile associarvi un sottoinsieme degli attributi definiti in modo da poterla valutare privi di reciproche sovrapposizioni: per evitare che più attributi riguardino la stessa caratteristica del software 7/XX Modello di Qualità (MQ) del software E un insieme di attributi del software che fornisce uno schema di riferimento che, con una opportuna distribuzione di pesi per ciascun attributo, va adeguato e tarato per la rappresentazione dei requisiti di qualità desiderati dal committente o posseduti dal software. 8/XX 4
Struttura dei modelli di qualità I modelli di qualità del software pubblicati in letteratura sono tipicamente gerarchici, a n livelli. Il primo livello descrive un insieme di caratteristiche (proprietà), che, nel loro complesso, rappresentano la qualità del prodotto software, eventualmente secondo diversi punti di vista. Le proprietà (in genere qualitative, astratte) sono precisate attraverso degli attributi misurabili, quantitativi (in genere da una combinazione di attributi). Il grado di possesso che il software ha di questi attributi può essere valutato su una scala di riferimento, facendo ricorso ad opportune metriche ed a meccanismi di rating. 9/XX Esempio: I Modelli di McCall e Boehm I primi modelli di qualità del software sono stati sviluppati negli anni 70 da McCall (Factor-Criteria- Model, 1977) e da B. Boehm (1978). Hanno un architettura a più livelli. Ad es. McCall prevede: Fattori, che descrivono il software da un punto di vista esterno, quello degli utenti; i fattori corrispondono a requisiti specificati dal cliente. Criteri, che descrivono gli elementi su cui agiscono gli sviluppatori per soddisfare i requisiti del cliente. Metriche, che servono a controllare che i criteri sviluppati corrispondano ai fattori specificati. Vengono utilizzate dagli auditors e/o dagli addetti alle verifiche. 10/XX 5
Modello di McCall (1977) 3 settori e 11 fattori: Manutenibilità Flessibilità Testabilità PRODUCT REVISION Portabilità Riusabilità Interoperabilità PRODUCT TRANSITION PRODUCT OPERATION Correttezza Usabilità Efficienza Affidabilità Integrità 11/XX I Fattori di Qualità nel Modello di McCall Uso del prodotto Correttezza Affidabilità Usabilità Integrità Efficienza Revisione del prodotto Manutenibilità Flessibilità Testabilità Transizione del prodotto Portabilità Riusabilità Interoperabilità 12/XX 6
Modello di McCall (1977) Uso del Prodotto: ciò che emerge quando si tiene il software in esercizio; i fattori di qualità che riguardano questo punto sono: correctness (does it do what I want?): correttezza, almeno come la vede l utente; reliability (does it do accurately all the time?): affidabilità; efficiency (will it run on my hardware as well as it can?):effic ienza; integrity (is it secure?): integrità, sicurezza; è una novità rispetto al modello di Boehm; non ha nulla a che fare con l affidabilità, pensiamo all integrità dei dati, delle business rules, etc.; usability (can I run it?): usabilità; 13/XX Modello di McCall (1977) Revisione del Prodotto: ciò che emerge quando si modifica il software; i fattori di qualità che riguardano questo punto sono: maintainability (can I fix it?): manutenibilità; flexibility (can I change it?): flessibilità; testability (can I test it?): testabilità; Transizione del Prodotto: ciò che emerge quando si cambia piattaforma tecnologica; i fattori di qualità che riguardano questo punto sono: portability (is it possible to use it on another machine?): portabilità; reusability (is it possible to reuse some of the software?): riusabilità; interoperability (is it possible to interface it with another system?): interoperabilità. 14/XX 7
Fattori di Qualità come funzioni di Criteri I fattori del Modello sono espressi in funzione di ulteriori caratteristiche di più basso livello (dette Criteri). Ad esempio: Correttezza = f (tracciabilità, coerenza, completezza) Affidabilità = f (tolleranza all errore, coerenza, accuratezza, semplicità) Usabilità=f(operabilità, addestramento, comunicabilità) 15/XX Fattori di Qualità come funzioni di Criteri CORRETTEZZA La correttezza del software è definibile come il grado di adesione alle sue specifiche e agli standard definiti sia nel processo produttivo che nel suo dominio di applicazione. Correttezza = f (tracciabilità, coerenza, completezza) Tracciabilità: il grado di reperibilità delle varie specifiche richieste dal software all interno del codice, sia nell ambiente di sviluppo che in fase di esercizio; Coerenza: quegli attributi che si riferiscono all uniformità delle tecniche utilizzate e delle notazioni adottate nei diversi componenti software, dai requisiti al codice (pensiamo a grandi sistemi, sviluppati da più gruppi oppure alle successive evoluzioni o operazioni di modifica); Completezza: è la capacità del software di soddisfare tutti i requisiti per cui è stato sviluppato. 16/XX 8
Fattori di qualità come funzioni di criteri AFFIDABILITA L affidabilità è definibile come la capacità del software di eseguire le sue funzioni senza insuccessi in uno specificato periodo di tempo (per insuccesso si intende anche il venir meno a livelli di precisione desiderati). Affidabilità = f (tolleranza all errore, coerenza, accuratezza, semplicità) Tolleranza all errore: il grado di affidabilità dei risultati ottenuti dal software in presenza di condizioni non normali; Accuratezza: attributi che si riferiscono alla precisione nei calcoli e nei risultati in output; Semplicità: se il software implementa le sue funzioni in maniera chiara e comprensibile. 17/XX Fattori di qualità come funzioni di criteri EFFICIENZA È il livello di utilizzo di risorse da parte del software (es. tempi di elaborazione e di comunicazione, spazio di memoria, ecc.); Efficienza = f (efficienza di esecuzione, efficienza di memorizzazione) Efficienza di esecuzione: il tempo impiegato per svolgere il compito richiesto; Efficienza di memorizzazione: la quantità di spazio occupato in memoria dai dati. 18/XX 9
Fattori di qualità come funzioni di criteri INTEGRITA è il livello di capacità del software di operare senza insuccessi dovuti ad accessi non autorizzati a codice e/o dati in uno specificato periodo di tempo. Integrità = f(controllo accessi, revisione accessi) Controllo Accessi: quegli attributi del software che si riferiscono al controllo degli accessi ai dati ed al software; Revisione Accessi: quegli attributi del software che consentono la revisione (riorganizzazione) degli accessi ai dati ed al software. 19/XX Fattori di qualità come funzioni di criteri USABILITA =f(operabilità, addestramento, comunicabilità) è lo sforzo necessario per usare il software (addestramento ed esecuzione) (ad esempio familiarizzazione, preparazione degli input, esecuzione,interpretazione degli output). Operabilità: quegli attributi del software che si riferiscono alla semplicità delle operazioni e delle procedure necessarie al controllo dell attivazione ed esecuzione del software; Addestramento: quegli attributi del software che ne consentono la familiarizzazione e ne supportano la transizione dal vecchio ambiente al nuovo sistema; Comunicabilità: quegli attributi del software che supportano una agevole assimilazione degli inputs e degli outputs utili (interazione uomo macchina). 20/XX 10
Fattori di qualità come funzioni di criteri MANUTENIBILITA E definita come lo sforzo necessario per trovare e correggere un errore all interno del codice dopo il rilascio in esercizio al cliente; Manutenibilità = f (coerenza, semplicità, concisione, modularità, auto documentazione) Concisione: la quantità di codice necessaria per adempiere ad una certa funzione; Modularità: il grado di indipendenza dei vari moduli operanti all interno del software; Auto documentazione: la capacità del codice di spiegare le funzioni implementate. 21/XX Fattori di qualità come funzioni di criteri PORTABILITA E la capacità di adattamento del software ad operare su nuovi ambienti di lavoro (nuovo hardware, software, configurazioni) Portabilità = f (modularità, auto documentazione, indipendenza dalla macchina, indipendenza dal software) Indipendenza dalla macchina: gli attributi che definiscono l indipendenza del software dalla piattaforma hardware. Indipendenza dal software: gli attributi che definiscono il grado di indipendenza del software dall ambiente software in cui opera, quindi indipendenza dal sistema operativo, dai drivers, utility, ecc.. 22/XX 11
Fattori di qualità come funzioni di criteri Testabilità E la facilità con cui è possibile effettuare il testing sull applicazione; Testabilità = f (semplicità,modularità, strumentazione, auto documentazione) Strumentazione E la facilità con cui è possibile monitorare il funzionamento del software e quindi verificarne possibili errori. 23/XX Le metriche nel Modello di McCall McCall completò il quadro con un numero incredibile di metriche: 25 per le specifiche, 108 per la progettazione, 157 per la codifica. ed associando ad ogni fattore di qualità una valutazione data da una funzione lineare delle metriche interessate: F i = a 0 + a 1 m 1 + + a k m k gli aiesprimono la rilevanza (peso) di ciascuna metrica ai fini della valutazione del fattore (sono ottenuti per analogia con altri progetti di caratteristiche simili) ogni mi è normalizzato sull intervallo [0,1]. 24/XX 12
Sinergie e Conflitti fra Fattori di Qualità Esistono sinergie e conflitti fra i diversi fattori di qualità, da tenere in considerazione in sede di definizione dei requisiti di qualità e di sviluppo di un sistema software. 25/XX Le Viste Logiche nel Modello di McCall 26/XX 13
I Livelli nel Modello di Boehm 27/XX Limiti dei modelli di McCall e Boehm le caratteristiche sono in genere proprietà astratte misurabili solo attraverso indicatori e metriche. Non sempre l andamento di queste grandezze è in correlazione perfettamente lineare con le caratteristiche che devono stimare, è difficile che le caratteristiche e sottocaratteristiche siano sempre prive di sovrapposizioni, manca in ogni caso il legame esplicito tra il modello qualitativo e come fare poi del buon software. 28/XX 14
Modelli di Qualità La difficoltà principale nell adozione di un modello di qualità consiste nel riuscire a dare un valore (o un giudizio) a tutti gli attributi di qualità (esterni) proposti, in funzione di attributi di qualità che siano direttamente misurabili La cui relazione reciproca sia stata empiricamente validata In cui gli attributi misurabili siano supportati da strumenti efficaci per la misurazione (non dimentichiamo I costi della misurazione)! Affinchè un modello possa essere affidabile e possa essere accettato, è auspicabile che esso provenga da un ente di standardizzazione. Al momento, il modello più comunemente adottato è lo standard ISO 9126 29/XX LO STANDARD ISO ISO/IEC 9126- Software engineering-product Quality 30/XX 15
Standard ISO/IEC 9126- Software engineering- Product Quality È suddiviso in 4 parti: 1. Quality Model un insieme di caratteristiche di qualità che possano essere in grado di descrivere I principali fattori di qualità di un prodotto software 2. External Metrics Un insieme di metriche indirette attraverso le quali sia possibile valutare la conformità di un prodotto software al modello di qualità 3. Internal Metrics Un insieme di metriche direttamente misurabili che possano essere utilizzate allo scopo di valutare le External Metrics 4. Quality In Use Metrics Metriche dirette rivolte alla valutazione del sottoinsiemedi caratteristiche di qualità legate all utente 31/XX I punti di vista sulla qualità A determinare la qualità complessiva di un prodotto software concorrono 3 punti di vista. ESTERNA Esprime il comportamento dinamico del software, nell ambiente d uso. INTERNA (intrinseca) Esprime la misura in cui il codice software possiede una serie di attributi statici, indipendentemente dall ambiente di utilizzo e dall utente. PERCEPITA (in uso) Esprime l efficacia ed efficienza con cui il software serve le esigenze dell utente, ed è correlata alla percezione diretta dell utente. 32/XX 16
La qualità esterna La qualità esterna è quella rappresentata dalle prestazioni del prodotto e dalle funzionalità che offre (il prodotto è visto come una black box da testare). In sostanza, riguarda il comportamento dinamico del software in un dato ambiente operativo. Va ricordato che il software non funziona mai da solo, ma è sempre parte di un ambiente (environment) che può contenere hardware, persone, processi etc Le caratteristiche di qualità esterne del software lo qualificano in relazione a questo ambiente e permettono di osservarne il comportamento mentre è utilizzato operativamente. 33/XX La qualità interna La qualità interna rappresenta le proprietà intrinseche del prodotto (quelle misurabili direttamente sul codice sorgente, sul suo flusso di controllo). Si realizza a partire da: I requisiti di qualità dell'utente (External Quality Requirements), che rappresentano le specifiche di qualità così come le dà l utente, fornendo il primo input alla progettazione, Le specifiche tecniche (Internal Quality Requirements), che rappresentano la qualità richiesta dall utente tradotta dallo sviluppatore nell architettura del software, nella struttura del programma, nelle interfacce del software verso l utente. 34/XX 17
La qualità in uso La qualità in uso riguarda il livello con cui il prodotto si dimostra utile all utente nel suo effettivo contesto d utilizzo, in particolare la capacità del prodotto di dare efficacia ed efficienza al lavoro dell utente, a fronte di una sicurezza di utilizzo e di una soddisfazione nel far uso del prodotto. In sostanza, è una misura della interazione tra utente e prodotto, in un determinato contesto d uso. I tre punti di vista sulla qualità si influenzano a vicenda: è chiaro che non può esservi qualità percepita positivamente dall utente senza che vi sia una buona qualità intrinseca del codice e buone prestazioni! 35/XX Approccio ISO alla qualità La qualità del processo contribuisce a migliorare la qualità del prodotto, influenzando direttamente i valori degli attributi interni di qualità. Gli attributi di qualità interni influenzano insiemi di attributi di qualità esterni. Gli attributi di qualità esterni influenzano gli attributi di qualità in uso (percepiti dall utente) In definitiva, migliorare la qualità del processo di sviluppo software e del prodotto software fa migliorare la qualità percepita dall utilizzatore. 36/XX 18
Qualità del software nel ciclo di vita La qualità del software, come percepita dall utente, si determina progressivamente attraverso una sequenza logica di azioni, lungo il ciclo di vita. 37/XX I Modelli di Qualità dello standard ISO Per descrivere le tre viste sulla qualità, lo standard propone due modelli, uno per la qualità interna ed esterna, ed uno per la qualità in uso. Entrambi i modelli definiscono la qualità in termini di un insieme di caratteristiche di primo livello a cui sono associati insieme di sottocaratteristiche di secondo livello che meglio descrivono ciascuna caratteristica. Le caratteristiche di secondo livello saranno valutate in funzione di un ampio insieme di metriche sia interne che esterne. 38/XX 19
Il Modello di Qualità ISO- 9126 per la qualità interna ed esterna 6 Caratteristiche e 27 Sotto-caratteristiche le sub-caratteristiche possono essere misurate con metriche interne o esterne 39/XX 1a Caratteristica: Funzionalità (functionality) La capacità del prodotto software di fornire funzioni che soddisfano esigenze stabilite ed implicite quando il software è usato sotto condizioni specificate Appropriatezza (suitability): la capacità del prodotto software di fornire un appropriato insieme di funzioni all utente per i compiti e gli obiettivi specificati. Accuratezza (accuracy): la capacità del prodotto software di fornire i giusti o concordati risultati o effetti, con la precisione richiesta. Interoperabilità (interoperability): la capacità del prodotto software di interagire con uno o più sistemi specificati Sicurezza (security): la capacità del prodotto software di proteggere informazioni e dati in modo che persone o sistemi non autorizzati non possano leggere o modificarli e che a persone o sistemi autorizzati non sia negato l accesso ad essi Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni o regolamentazioni in leggi e prescrizioni relative alla funzionalità. 40/XX 20
2a Caratteristica: Affidabilità (reliability) La capacità del prodotto software dimantenere uno specificato livello di prestazioniquando usato sotto condizionispecificate Maturità (maturity): la capacità del prodotto software di evitare malfunzionamenti, quali risultati di anomalie nel software. Tolleranza all errore (fault tolerance): la capacità del prodotto software di mantenere uno specificato livello di prestazioni in caso di anomalie software o di violazione delle sue specificate interfacce. Recuperabilità (recoverability): la capacità del prodotto software di ristabilire uno specificato livello di prestazioni e di ripristinare i dati direttamente intaccati in casodi malfunzionamenti. Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni o regolamentazioni relativamente all'affidabilità. 41/XX 3a Caratteristica: Usabilità (usability) La capacità del prodotto software di essere capito, appreso, usato e gradito all'utente, quando usato sotto condizioni specificate Comprensibilità (understandability): la capacità del prodotto software di mettere in grado l'utente di comprendere se il software è appropriato, e come esso possa essere usato per particolari compiti e condizioni d'uso. Apprendibilità (learnability): la capacità del prodotto software di permettere all'utente di imparare ad usare l applicazione. Operabilità (operability): la capacità del prodotto software di permettere all'utente di operare con esso e di controllarlo. Attrattività (attactiveness): la capacità del prodotto software di essere attraente all'utente (cioè avere un livello di gradimento nell utilizzo). Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni, stili guida o regolamentazioni relativamente all'usabilità. 42/XX 21
4a Caratteristica: Efficienza (efficiency) La capacità del prodotto software di fornire appropriate prestazioni relativamente alla quantità dirisorse usate, sotto condizioni stabilite Comportamento rispetto al tempo (time behaviour): la capacità del prodotto software di fornire un appropriato responso e tempi di elaborazione e velocità di attraversamento nell'eseguire le sue funzioni sotto specificate condizioni. Utilizzo di risorse (resource utilisation): la capacità del prodotto software di usare appropriate quantità e tipo di risorse quando il software esegue le sue funzioni sotto specificate condizioni. Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni o regolamentazioni relativamente all'efficienza. 43/XX 5a Caratteristica: Manutenibilità (maintainability) La capacità del prodotto software di essere modificato. Le modifiche possono includere correzioni, miglioramenti o adattamenti del software per cambiamenti nell'ambiente operativo, nei requisiti e nelle specifiche funzionali. Analizzabilità (analysability): la capacità del prodotto software ad essere diagnosticato per deficienze o cause di malfunzionamenti nel software o per l'identificazione delle parti da modificare. Modificabilità (changeability): la capacità del prodotto software di permettere l'implementazione di una specificata modifica Stabilità (stability): la capacità del prodotto software di evitare effetti inaspettati derivanti da modifiche ad esso Testabilità (testability): la capacità del prodotto software di permettere a software modificato di essere validato Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni o regolamentazioni relativamente alla manutenibilità. 44/XX 22
6a Caratteristica: Portabilità (portability) La capacità del prodotto software di essere trasferito da un ambiente ad un altro. Adattabilità (adaptability): la capacità del prodotto software di essere adattato per differenti e specificati ambienti senza dover applicare altre azioni o mezzi diversi da quelli forniti per tale scopo per il software considerato. Installabilità (installability): la capacità del prodotto software di essere installato in uno specificato ambiente. Coesistenza (co-existence): la capacità del prodotto software di coesistere con altri software indipendenti in un ambiente comune condividendo risorse comuni. Sostituibilità (replaceability): la capacità del prodotto software di essere usato al posto di un altro specificato prodotto software per gli stessi scopi e nello stesso ambiente Conformità (compliance): la capacità del prodotto software di aderire a standard, convenzioni o regolamentazioni relativamente alla portabilità. 45/XX Il Modello di Qualità per la Qualità in uso La qualità in uso è rappresentata da 4 caratteristiche, che rappresentano il punto di vista dell utente sulla qualità del software. Rappresenta la capacità del software di supportare specifici utenti a raggiungere determinati obiettivi, con efficacia, produttività, soddisfazione e sicurezza personale, in determinati contesti d uso. 46/XX 23
Caratteristiche della qualità in uso Efficacia, la capacità di supportare un utente nel raggiungere i suoi obiettivi con accuratezza e completezza in un dato contesto. Produttività, la capacità di supportare un utente nello spendere l appropriata quantità di risorse in relazione all efficacia dei risultati da raggiungere. Soddisfazione, la capacità di soddisfare un utente in un dato contesto d uso. Sicurezza, la capacità di raggiungere accettabili livelli di rischio di danni a persone, al software, ad apparecchiature, o all ambiente operativo in un dato contesto d uso. 47/XX Riepilogo modello 9126 48/XX 24
Caratteristiche Interne Sono collegate alle caratteristiche esterne di 2 livello. Alcune caratteristiche interne vanno ad influenzare più di una caratteristica esterna di 2 livello. Completeness Access control Informativeness Self-descriptiveness Instrumentability Expressiveness Data-commonality Self-containedness Communication-commonality Well-equipmentness Traceability Timeliness Robustness Integrity Modularity Simplicity Coherency Accessibility Uniformity Accuracy Hierarchieness Consistency Metaphorability Attractiveness Access audit Memorability Conciseness Choosability Guideability 49/XX Caratteristiche Interne ad esempio, per la funzionalità: suitability = f(completeness, traceability, consistency, selfdescriptiveness, coherency) accurateness = f(completeness, traceablity, consistency, selfdescriptiveness, coherency) inter-operability = f(data-commonality, communicationcommonality, accessibility) compliance =f(accuracy, data-commonality, accessibility) security =f (access control, access audit, robustness) 50/XX 25
Metriche nello standard ISO 9126 Per valutare le caratteristiche di qualità, la ISO/IEC 9126 fornisce 3 insiemi di metriche, rispettivamente le metriche esterne (nella 9126-2), quelle interne (nella 9126-3), quelle in uso (nella 9126-4). Metrica Interna: è applicabile ad un prodotto software non eseguibile (es. Specifica, codice sorgente) Metrica Esterna: misura aspettidel software relativi al suo comportamento, osservabili testando il software in esecuzione. Metrica diqualità in Uso: misura fino a che punto un prodotto soddisfa I bisogni utente per raggiungere specificiscopi con efficacia, produttività, sicurezza, soddisfazione, in un determinato contesto d uso. 51/XX Descrizione delle Metriche nello standard 52/XX 26
Parte 2: Metriche Software 53/XX Misurare il software: una premessa L Ingegneria del Software non studia le leggi quantitative della fisica, ma processi e prodotti legati ad attività umane. Non è possibile effettuare misure assolute, ma è necessario ricorrere a misure indirette. Negli ultimi trent anni molti studiosi hanno tentato di sviluppare una singola metrica che offrisse una misura globale della complessità del software Fenton paragona questi tentativi alla ricerca del sacro Graal 54/XX 27
Misurare il software La misurazione del software ha lo scopo di assegnare un valore ad un attributo caratterizzante un processo o prodotto software consente una comparazione obiettiva tra prodotti/processi rende misurabili processi, risorse, prodotti rilevanti della Ingegneria del Sw Sebbene molte aziende produttrici di software utilizzino procedure di misurazione, l uso sistematico della misurazione del software non è ancora una pratica comune Ancora pochi standard in questa area 55/XX Metrica Metrica: misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, un componente, o un processo [IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology] Es: numero di linee di codice di un modulo, numero di casi d uso di un applicazione,... Molto spesso, metrica è usato come sinonimo di misura o misurazione la definizione di metrica include procedure e modalità di misurazione. 56/XX 28
Misurazione e Misura La Misurazione è il processo mediante il quale si assegnano numeri o simboli ad attributidi entità del mondo reale in modo tale da descriverle secondo regole chiaramente definite [Fenton] L entità rappresenta l oggetto che si vuole sottoporre a misurazione. L attributo dell entità, invece, è l aspetto di tale oggetto che interessa descrivere o rappresentare. L insieme dei simboli o valori che si possono assegnare all attributo costituisce la forma di rappresentazione dell attributo, o scala dei valori Una misura è una funzione che mappa un insieme dioggetti in un altro insieme dioggetti (tipicamente numerio insiemidi numeri, ma anche simboli) La Misurazione è l attività generale, una Misura è l effettiva assegnazione di valori. 57/XX Un esempio di Misura di attributi Entità= persone; Attributo= Altezza; Pino Luca Giorgio 180 170 176 Misura dell altezza di persone come funzione di mapping fra due insiemi 58/XX 29
Misura e Metrica Spesso i termini metrica e misura (e anche misurazione) sono usati come sinonimi Dai testi classicidella misura Una misura è una empirica oggettiva assegnazione di un numero (o simbolo) ad una entità al fine di caratterizzarne uno specifico attributo Un tentativo di distinzione: Una metrica caratterizza con valori (numericamente o con simboli) attributi semplici Una misura è una funzione di metriche che può essere usata per valutare o predire attributi più complessi 59/XX Attributi Attributi esterni: attributi di un entità che sono visibili e di interesse per l utente del prodotto software; descrivono l aspetto esterno di un entità e il loro rapporto con l ambiente in cui vengono usate, indipendentemente dalla implementazione; ad esempio: facilità d uso; portabilità, efficienza, affidabilità Attributi interni: attributi di un entità che sono visibili e di interesse del produttore, i cui valori dipendono dalla implementazione; ad esempio: modularità, strutturazione, tracciabilità, testabilità, dimensione, complessità 60/XX 30
Misure e metriche Misura diretta: la misura di un attributo che non dipende da quella di altri attributi Misura indiretta: la misura di un attributo che dipende da quella di almeno un altroattributo Metriche: tutto ciò per cui possiamo fare misure dirette Misure dirette? Metriche Misure: tutto ciò per cui dobbiamo fare misure indirette Misure indirette? f(metriche) - ad attributi semplicisono associate le metriche - ad attributi complessi sono associate le misure 61/XX Internal and external attributes Maintaina bility Number of procedur e par ameters Cyclomatic complexity Relia bility Portability Usability Program size in lines of code Number of error messages Length of user manual 62/XX 31
Entità Entità di interesse per la misurazione nella IS sono: Prodotti: tutto ciò che viene prodotto nel CVS (documentazione, software, test data, ); Processi (attività) produzione specifiche, progettazione, codifica, testing, manutenzione, quality assurance, riuso, reengineering, ; Risorse: hardware, software, documentazione (della risorsa), risorse umane, banche dati, conoscenza,. 63/XX Esempi di Entità e attributi 64/XX 32
Scale di valori Una Scala di valori è l insieme: dei numeri / simboli da assegnare ad un attributo di un entità delle relazioni tra tali numeri / simboli Esistono 5 tipologie di scala: 1. Nominale La relazione tra i valori consente una semplice classificazione degli oggetti della misurazione, ma non ci indica nulla sulla relazione fra di essi Esempio: la classificazione degli errori di programmazione in lessicali, sintattici e semantici ci consente di suddividerli ma non di sapere se un errore sia più o meno grave di un altro; in termini più analitici questo tipo di scala coincide con l introduzione nell insieme di partenza di classi di equivalenza 65/XX Scale di valori 2. Ordinale si introduce una relazione d ordine fra gli oggetti, per cui siè in grado di determinare le posizioni relative degli oggetti (cioè dire se uno venga prima di un altro); non si è però in grado di quantificare la distanza fra gli oggetti Esempio: in una scala di valutazione (sufficiente, buono, ottimo) possiamo dire che buono è peggiore di ottimo ma non di sufficiente 66/XX 33
Scale di valori 3. Intervalli: Si è in grado di misurare la distanza fra gli oggetti del dominio, e non solo posizionarli tra di loro come con le scale ordinali Esempio: la classificazione del rendimento scolastico con 6, 8 e 10 in sostituzione di sufficiente, buono e ottimo, rispettivamente, consente non solo di dire che 6 precede 8, ma anche di quanto 4. Ratio introduce l elemento zero che rappresenta l assenza totale dell attributo che si sta misurando nell entità sottoposta a misurazione. L introduzione dello zero, inoltre, conferisce al valore di un attributo il senso di positività, negatività o nullità. Esempio: la misura di una temperatura, quantificata con un numero maggiore, minore, o uguale a zero. 67/XX Scale di valori 5. Assoluta esiste una strategia di conteggio per la quale possiamo assegnare ad ogni oggetto un numero univocamente determinato. La scala assoluta è usata per quegli attributi di un oggetto che richiedono un semplice conteggio di elementi. Esempio: si consideri l entità studente e si voglia quantificare il suo attributo numero di esami superati. La misura in questo caso consiste nel semplice conteggio degli esami superati da uno studente; il totale conteggiato rappresenta lo studente in esame, visto attraverso l attributo numero di esami superati. 68/XX 34
Caratteristiche di metriche software efficaci Semplici e Calcolabili Convincenti a livello empirico ed intuitivo. Coerenti e obiettive. Coerenti nell uso di unità e dimensioni. Indipendenti dal linguaggio di programmazione. Devono essere un meccanismo efficace per un feedback sulla qualità. L esperienza insegna che la metrica di un prodotto viene utilizzata solo se è intuitiva e facile da calcolare. Se occorre svolgere decine di calcoli complessi, è improbabile che tale metrica venga largamente adottata [Pressman] Non tutte le metriche soddisfano tutte le caratteristiche di qualità indicate. 69/XX Una Classificazione di Metriche software relative al prodotto Metriche per il Modello di Analisi : Funzionalità fornita Dimensioni del sistema (in termini di informazioni presenti sul modello di analisi) Qualità delle specifiche Metriche per il Modello di Design: Metriche dell architettura Metriche a livello dei componenti Metriche della progettazione dell interfaccia Metriche specializzate relative al design object-oriented Metriche relative al codice sorgente Metriche di Halstead Metriche di complessità Metriche di lunghezza Metriche di testing Metriche sulle istruzioni e ramificazioni Metriche relative aidifetti Test dell efficacia Metriche sul processo 70/XX 35
Metriche per il Modello di Analisi Che tipo di metriche si possono usare in fase di analisi? Metriche che consentono al management di monitorare e controllare Costi, Scheduling, Qualità Ad esempio: Metriche aventi lo scopo di poter prevedere quale sarà la taglia del processo software all inizio del suo ciclo di vita, in modo da poter dimensionare le risorse umane e temporali da dedicare ad esso. Metriche basate sulle funzionalità Function Points (FP) Metriche per la qualità delle specifiche 71/XX Function Point Analysis Tecnica proposta da Albrecht [Measuring Application Development Productivity, 1979] Approccio indipendente dal linguaggio di programmazione per misurare le funzionalità del sistema. Può essere usata per: Stimare il costo richiesto per programmare, testare il software Prevedere il numero di erroriche si rileveranno durante il testing Prevedere il numero dicomponentio diloc del sistema 72/XX 36
Cosa sono i Function Point (FP) I FP sono una misura di funzionalità basata su entità logico-funzionali che l'utente facilmente comprende (es. Input, output,etc.) I FP sono pertanto indipendenti dal linguaggio di programmazione, quindi la produttività può essere confrontata tra diversi linguaggi Un FP non è una singola caratteristica ma una combinazione di caratteristiche del sistema Destinati a supportare stime, pianificazioni relative a sistemi Sw Nati per essere applicati a Sistemi Swdi tipo Business Misura che può essere effettuata presto nel CVS 73/XX Utilizzi dei FP Per stimare la dimensione finale del codice: Studi hanno rilevato una correlazione tra FP e numero di LOC, variabile a seconda del linguaggio di programmazione. Es. COBOL: 1 FP -> 100 LOC PL1 : 1FP -> 80 LOC OO lang : 1 FP ->60 LOC Per stimare lo sforzo (in ore/uomo) di sviluppo: Es. se 1 mese/uomo ->12 FP, allora Per valutare la completezza del testing studi hanno misurato la correlazione fra FP e numero di difetti scoperti durante il testing 86/XX 37
Vantaggi e svantaggi dei FP Vantaggi: Indipendenti dal linguaggio Ottime indicazioni per applicazioni di elaborazione dati, che usano linguaggi convenzionali o non procedurali Basati su quei dati che hanno la maggior probabilità di essere noti all'inizio di un progetto Svantaggi Soggettività nell'assegnazione dei pesi Dati sul dominio delle informazioni possono essere difficili da reperire Nessuna valutazione della complessità dell'algoritmo (a parità di pochi input e output potrebbe essere banale ed estremamente complicato) I FP non hanno un diretto significato fisico 87/XX Metriche per la qualità delle specifiche Sono stati proposti alcuni attributi di qualità dello SRS (non ambiguità, completezza, correttezza, comprensibilità,verificabilità, coerenza interna ed esterna, realizzabilità, concisione, tracciabilità, modificabilità, precisione e riusabilità) Un metodo per valutare tali attributi: n R requisiti, di cui n f funzionali e n nf non funzionali : n R =n f +n nf Unametrica proposta per ognuno degli attributi di qualità: Ad esempio, per l assenza di ambiguità: Q 1 = n ui /n R Rapporto tra il numero di requisiti che non risultano ambigui (secondo i revisori dell SRS) e il numero di requisiti funzionali Metriche analoghe sono proposte per tutti gli altri attributi di qualità dell SRS 88/XX 38
Metriche di progetto architetturale Si concentrano sulle caratteristiche dell architettura del software, non tenendo conto della struttura interna dei singoli moduli. Si basano sull analisi di modelli di progetto nei quali si evidenziano i moduli del sistema (qualora esso sia scomponibile) e i dati che vengono scambiati tra essi. Molto semplici da misurare, ma poco affidabili in quanto a legame con lo sforzo effettivo legato allo sviluppo del sistema. 89/XX Esempi di Metriche di Progetto Architetturale Architectural design metrics (applicabili a moduli di architetture gerarchiche) Structural complexity = f(fan-out) Data complexity(mi) = f(input & output variables, fanout) System complexity = f(structural & data complexity) Henry e Kafura (HK) metric: complessità architetturale vista come funzione del fan-in e fan-out dei moduli Morphology metrics (Fenton): una funzione del numero dei moduli e del numero delle interfacce tra i moduli 90/XX 39
Metriche per il Design Object Oriented Peculiarità Sistemi O-O Localizzazione: il modo con cui le informazioni e loro elaborazioni sono confinate in un sistema Nei sistemi Function oriented le informazioni sono localizzate intorno alle funzioni (moduli procedurali) Nei sistemi Object Oriented sono concentrate incapsulando dati e procedure che li elaborano Incapsulamento: una delle conseguenze sulle metriche è che l unità da considerare è l oggetto piuttosto che il sotto-programma Information hiding: influisce sull accoppiamento fra oggetti Inheritance: varie forme di influenza sul progetto Abstraction: possibilità di considerare gli oggetti da vari livelli di astrazione 91/XX Metriche orientate alle classi Metriche di Chidamber and Kemerer [A Metrics Suite for Object-Oriented Design, 1994]: weighted methods per class (WMC) depth of the inheritance tree (DIT) number of children (NOC) coupling between object classes (CBO) response for a class (RFC) lack of cohesion in methods (LCOM) 92/XX 40
Weighted Method per Class (WMC) WMC è la somma pesata dei metodi di una classe Il peso di un metodo è dato da un fattore di complessità a scelta. Il fattore di complessità dei metodi può essere una metrica di complessità proposta per le funzioni (ad esempio la complessità di Mc Cabe) Al crescere di WMC aumenta la complessità della classe e diminuisce la speranza di poterla riusare. Problema: come tener conto della complessità dei metodi ereditati? 93/XX Profondità dell albero di ereditarietà di una classe- DIT Distanza massima di un nodo (una classe) dalla radice dell albero rappresentante la struttura ereditaria Maggiore è la profondità della classe nella gerarchia, maggiore è il numero di metodi che essa può ereditare, rendendo più complesso predire il suo comportamento. Alberi di ereditarietà con elevata profondità possono aumentare la complessità del progetto (più classi e metodi sono coinvolti) Maggiore è la profondità di una classe in una gerarchia, maggiore è il riuso potenziale deimetodi ereditati. Ma i metodi della superclasse devono essere nuovamente testati per ciascuna sottoclasse. 94/XX 41
Numero di figli - NOC Numero di sottoclassi, figlie di una super-classe Al crescere del NOC, cresce il livello di riuso (NOC è dunque un indicatore di Riuso) ma tende ad evaporare l astrazione della Classe madre. aumentala possibilità che una Classe figlia non sia membro appropriato della madre Al crescere del NOC, cresce la quantità di test case necessari a testare ogni figlia. 95/XX Risposte per classe RFC Insieme dei metodi che possono essere potenzialmente eseguiti in risposta ad un messaggio ricevuto da un oggetto della Classe Include l insieme dei metodi della classe e di tutte le classi a cui essa invia messaggi. RFC è un indicatore del volume di interazione fra classi A valori elevati di RFC: aumenta la complessità progettuale della classe cresce lo sforzo per il testing 96/XX 42
Accoppiamento tra le classi - CBO Numero di collaborazioni di una classe, ovvero numero di altre classi cui essa è accoppiata L accoppiamento può avvenirea seguito di lettura/modifica attributi, chiamata metodi, instanziazione oggetti Eccessivo accoppiamento è negativo per la modularità ed il riuso; Maggiormente indipendente è una classe più facilmente è riusabile; Per migliorare la modularità, l accoppiamento va tenuto al minimo; esso influisce sull impatto di modifiche in altri moduli Valori elevati del CBO complicano testing e modifiche. 97/XX Mancanza di coesione nei metodi - LCOM La coesione di un metodo esprime la proprietà di un metodo di accedere in maniera esclusiva ad attributi della classe. La Mancanza di Coesione deriva dalla presenza di più metodi che accedono ad attributi comuni. Se ogni attributo è acceduto da un solo metodo, allora LCOM=0 (massima coesione dei metodi). Altrimenti, LCOM >0 ed aumenta quanto più I metodi vanno ad operare sugli stessi attributi, rendendo quindi difficile il controllo di tutte le interazioni tra i metodi dovuti all uso degli attributi comuni. Quindi se LCOM è elevato, I metodi potrebbero essere molto accoppiati tra loro attraverso gli attributi, ed aumenta la complessità del design della classe. 98/XX 43
Metriche di design a livello dei componenti Metriche che valutano caratteristiche interne dei moduli, quali coesione, coupling e complessità. Ad esempio: Le metriche di coesione di Bieman [Measuring Functional Cohesion, 1994] si basano sull analisidelle funzioni e deidati elaborati da un modulo, cercando di stabilire se il modulo svolge funzioni che operano sugli stessi dati (buona coesione), oppure su dati disgiunti (scarsa coesione) La Metrica di accoppiamento proposta da Dhama [Quantitative Models of Cohesion and Coupling in Software, 1995] tiene conto del flusso di dati e di controllo fra i moduli, dell accoppiamento a variabili globali, e dell accoppiamento ambientale (mediante fan-in e fan-out) fra moduli. Le metriche di complessità misurano in vario modo la complessità del CFG. 99/XX Metrica di McCabe Metrica strutturale relativa al Control Flow diun programma G E detta anche numero ciclomatico V(G) Rappresenta la complessità logica del programma e quindi lo sforzo per realizzarlo (o per comprenderlo) per programmi strutturati V(G) è uguale al n.ro di predicati aumentato di uno: V(G) = P + 1 P: n.ro di predicati (semplici ed a due vie) in G Predicati: decisioni - semplici, ovvero non composte con connettivi logici - in strutture di controllo (if-then-else, repeat-until, whiledo, ); 100/XX 44
Metrica di McCabe Rappresentando un programma con il Control Flow Graph, il numero ciclomatico V(G) può essere calcolato nel seguente modo: V(G) = E - N + 2P N è il n.ro di nodi, E è il n.ro di archi, P è il n.ro di componenti connesse (per una sola unità di programma P è pari ad 1); Un altro modo per calcolare V(G) è: V(G) = numero di aree chiuse del CfG + 1 101/XX Complessità ciclomatica di un programma 0 1 Dato un grafo G di n nodi ed e archi il numero ciclomatico è dato da: true true 2 false false V(G) = e- n+ 2 oppure: V(G)= d + 1 d= # nodi branch 3 4 V(G)= 3 =>3 cammini indipendenti Complessità ciclomatica del programma è 3 5 c1= 0-1-2-4-5 c2= 0-1-2-3-2-4-5 c3= 0-1-5 102/XX 45
Cammini linearmente indipendenti V(G) rappresenta il n di cammini linearmente indipendenti del Control Flow Graph nella teoria deigrafi V(G) rappresenta il numero di circuiti linearmente indipendenti che congiungono il nodo iniziale con quello finale Un cammino si dice indipendente se introduce almeno un nuovo insieme di istruzioni o una nuova decisione, rispetto ad un altro; In un CfG un cammino è indipendente se attraversa almeno un arco non ancora percorso dagli altri già considerati. L insieme di tutti i cammini linearmente indipendenti di un programma formano i cammini di base; Tutti gli altripossibili cammininelcfg sono generati da una combinazione lineare di quelli di base. Dato un programma, l insieme dei cammini di base non è unico. 103/XX Metriche per il Codice Sorgente Linee di Codice Metriche di Halstead 104/XX 46
Lines of Code (LOC) E una metrica dimensionale Misura la lunghezza di un programma con il numero di linee di codice Esistono diverse possibili definizioni qualsiasi linea di codice, inclusi i commenti; tutte le linee di codice, esclusi i commenti (in questo caso si distinguono in Non Comment LOC (NCLOC) e Effective LOC (ELOC) solo le istruzioni eseguibili (EXLOC), con anche le Data Declaration LOC (DDLOC), cioè le istruzioni dichiarative dei dati. La definizione più accettata è la seguente: Una linea di codice è ogni linea di testo di un programma che non sia bianca o un commento, indipendentemente dal numero di istruzioni in essa inclusa. In particolare, tali linee di codice possono contenere intestazioni di unità di programma, dichiarazioni ed istruzioni esecutive 105/XX Osservazioni sulle LOC I commenti sono una parte importante del processo di sviluppo di un programma, per cui ignorarle, e quindi non invogliare il programmatore ad inserirle, può essere deleterio; ovviamente vanno prodotti in modo consistente (e non inseriti all ultimo solo per motivi di tariffazione). Le Comment LOC (CLOC) possono essere valutate in base alla loro importanza differenza fra commenti inseriti utilizzando metodi formali ( per cui, utilizzando appositi tool, si possa effettuare un testing automatico del programma) e commenti inseriti all ultimomomento prima della consegna. Alcune misure derivate dalle LOC sono: Densità di commento = CLOC/LOC Effort = 5.2*KLOC 0.91 con Effort misurato in mesi/uomo 106/XX 47
Vantaggi e svantaggi Vantaggi: Molto semplici da calcolare automaticamente Molto intuitive Svantaggi Dipendenti dal linguaggio di programmazione Studi empirici sono stati svolti per valutare la dipendenza del numero di LOC dal linguaggio, a parità di algoritmo Dipendenti dallo stile di programmazione Bisogna definire uno standard di formattazione del testo sorgente cui conformarsi, oppure uno strumento di formattazione automatica Facilmente falsificabili! Diventano una misura inconsistente in presenza di generatori automatici di codice 107/XX Altri usi delle LOC Le LOC sono utilizzate per misurare indirettamente altri attributi Esempi: la probabilità di presenza di errori nel programma (cresce con la lunghezza) il tempo per produrlo la produttività (o il compenso) di un programmatore. stimadei costi di un progetto SW Nelle LOC bisognerebbe contare anche tutte le linee di codice non direttamente legate ai prodotti consegnati, ad esempio: Codice per il testing Codice per I prototipi 108/XX 48
Metriche di Halstead (1977) Halstead [ Elements of Software Science, 1977] ha proposto un insieme di metriche per la lunghezza ed il volume di un programma. Basate su: n1 = numero di operatori distinti che compaiono in un programma Ad esempio costrutti di controllo, condizionali, assegnazioni, etc. n2 = numero di operandi distinti che compaiono in un programma Ad esempio variabili e costanti di un programma N1 = numero totale delle occorrenze di operatori N2 = numero totale delle occorrenze di operandi Si definiscono: Vocabolario: n=n1+n2 Lunghezza: N=N1+N2 (è una lunghezza concettuale) Volume: V=N*log 2 n 109/XX Metriche di Halstead Volume V=N*log 2 n log 2 n è il numero di bit necessari per rappresentare il vocabolario V è il numero di bit necessari per rappresentare il programma nella sua forma minima, cioè indipendentemente dalla lunghezza dei nomi dei token; il concetto di Volume è legato quindi al contenuto di informazione del programma e dovrebbe dipendere unicamente dall algoritmo scelto, non dall espressività del linguaggio di programmazione. Il Volume è usato come una metrica dimensionale del software. Alcuni esperimenti hanno mostrato la correlazione fra il volume e le LOC, così come tra V e la difettosità deimoduli 110/XX 49
Stima della lunghezza di un programma Halstead propose la seguente formula per stimare la lunghezza di un programma in base solo a n1 e n2: N^=n1 log 2 n1 + n2 log 2 n2 Le statistiche effettuate su algoritmipubblicati sembrano indicare un valore medio dell errore relativo della stima pari a: (N-N^)/ N < 10% 111/XX Volume Potenziale Molte altre metriche sono state derivate da Halstead: Volume potenziale: in un caso ideale N1= n1 = 2 (solo due operatori: nome funzione e parentesi) N2 = n2 (tutti operandi distinti) V* = (2+n 2 ) log 2 (2+n 2 ) É il volume del programma più sintetico nelquale può essere codificato un algoritmo. Viene usato per introdurre il concetto di Livello di Implementazione. 112/XX 50