La qualità del software può essere definita come:
Tre punti fondamentali:
Alcuni problemi nella definizione di qualità introdotta…
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!
La qualità di un prodotto software si caratterizza attraverso un insieme finito e definito di attributi:
È 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.
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.
I primi modelli di qualità del software sono stati sviluppati negli anni ‘70 da McCall [McCall, J. A., Richards, P. K., and Walters, G. F., "Factors in Software Quality", Nat'l Tech. Information Service, no. Vol. 1, 2 and 3, 1977] e da B. Boehm [Boehm, Barry W., Brown, J. R, and Lipow, M.: Quantitative evaluation of software quality, International Conference on Software Engineering, Proceedings of the 2nd international conference on Software engineering, 1976]. Hanno un’architettura a più livelli. Ad es. McCall prevede:
Uso del prodotto
Revisione del prodotto
Transizione del prodotto
Uso del Prodotto: ciò che emerge quando si tiene il software in esercizio; i fattori di qualità che riguardano questo punto sono:
Revisione del Prodotto: ciò che emerge quando si modifica il software; i fattori di qualità che riguardano questo punto sono:
Transizione del Prodotto: ciò che emerge quando si cambia piattaforma tecnologica; i fattori di qualità che riguardano questo punto sono:
I fattori del Modello sono espressi in funzione di ulteriori caratteristiche di più basso livello (dette Criteri).
Ad esempio:
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.
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.
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.
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.
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).
MANUTENIBILITA’
È 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.
PORTABILITA’
È 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..
TESTABILITA’
E’ la facilità con cui è possibile effettuare il testing sull’applicazione;
Testabilità = f (semplicità,modularità, strumentazione, auto documentazione).
Strumentazione
È la facilità con cui è possibile monitorare il funzionamento del software e quindi verificarne possibili errori.
McCall completò il quadro con un numero incredibile di metriche:
ed associando ad ogni fattore di qualità una valutazione data da una funzione lineare delle metriche interessate:
Fi= a0+ a1m1+ … + akmk
gli ai esprimono 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].
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.
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.
2. Ciclo di Vita e Processi Software
3. Processi per lo sviluppo rapido del software
4. Sviluppo Agile del Software
5. Test Driven Development (TDD)
7. Component Based Software Engineering (CBSE): Generalità
8. Component Based Software Engineering (CBSE): Il processo di svi...
9. Ingegneria del Software orientato ai Servizi
10. Ingegnerizzazione dei Servizi
11. I Processi di Manutenzione del Software
12. Reengineering, Refactoring e Reverse Engineering del Software
13. Verifica e Convalida del Software. Richiami e concetti di base ...
14. Tecniche di Testing Dinamico
15. Testing di Sistemi Object Oriented
16. Automazione del testing e Analisi Mutazionale
17. Tecniche di Analisi Statica del codice e il Debugging
18. Stima dei costi nei progetti Software
19. Il Modello COCOMO per la stima dei costi Software – La gestio...
20. Gestione e Miglioramento dei Processi di Produzione del Softwar...
21. La Valutazione della Qualità dei Processi Software – Il Capa...