Modelli e metodi per la qualità del software (ITPS) di Serlab

Software Engineering Research

Modelli e Metodi per la Qualità del Software (ITPS) A.A. 2022 - 2023 Prof.ssa Baldassarre mariateresa.baldassarre @ uniba,it

Presentazione

Dipartimento di Informatica - Università degli Studi di Bari Via Orabona, 4 - 70125 - Bari Tel: +39.080.5443270 | Fax: +39.080.5442536 serlab.di.uniba.it

1

Cosa si intende per Qualità?

La qualità è un termine ambiguo, con molte interpretazioni. Ciò è dovuto alle seguenti ragioni

1. è un concetto che non è semplice, ma multidimensionale. Le dimensioni sono:
   • L'entità di interesse.
   • Il punto di vista che abbiamo di tale entità.
   • Attributi di qualità in grado di misurare più di tale entità
2. Per questo concetto, ci sono diversi livelli di astrazione:

   A volte si usa il concetto di qualità nel senso più ampio del termine. " In altri, viene usato per indicare un aspetto molto specifico di un prodotto

3. Si tratta di un concetto che spesso usiamo nella nostra vita quotidiana.
   • Il significato di questo termine è diverso se usato in un ambito popolare (quotidiano) o un professionale.

Qualità: prospettiva popolare

> Popolarmente, si intende che la qualità sia una caratteristica immateriale / non tangibile. Si possono esprimere opinioni, commenti, giudizi, ma non è possibile misurarla concretamente. › Diciamo che qualcosa è di "buona qualità"," cattiva qualità" o si parla di "qualità della vita" > In questo senso, la qualità non può essere quantificata o gestita. › A volte la qualità esprime anche un senso di "lusso", "classe" o "buon gusto" ed è riservata ai prodotti generalmente costosi, con funzionalità sofisticate. Prodotti semplici, che non sono costosi, raramente vengono definiti come prodotti di qualità

Qualità: prospettiva Professionale

Autori rilevanti nel campo della qualità professionale definiscono qualità rispetto a:

1. conformità con i requisiti. Ciò implica che i requisiti del prodotto devono essere chiaramente definiti. Durante lo sviluppo, è necessario verificare che il prodotto soddisfa tali requisiti. Non conformità con i requisiti, è considerato un difetto.
2. adeguatezza circa l'utilizzo. Ciò implica che le esigenze degli utenti e le aspettative sono note (riportate formalmente nei documenti di progetti) e che il prodotto li soddisfa (verificati attraverso test, collaudi etc).

Qualità del Software

Il significato più comune è che un software è di qualità quando non ha difetti (bug) di tipo generalmente funzionali A Per esprimere questa definizione di qualità, generalmente si adottano due misure/metriche:

• Tasso di difetti: No. difetti / PF, n difetti / KLOC
• Affidabilità: No. Fallimenti (operazioni nn andate a buon fine) / Nr. ore di funzionamento, tempo medio tra i fallimenti.
• Soddisfazione degli utenti:% di utenti soddisfatti (misurato attraverso indagini)

2

Definizione di Qualità del software

> (ISO) Insieme di proprietà e di caratteristiche desiderate per un processo, un prodotto, un servizio software allo scopo di:

• Soddisfare il committente, attraverso i requisiti impliciti od espliciti
• Realizzare il ritorno economico degli investitori
• Realizzare trade - off tra qualità tecnica, costo e tempo di esecuzione del processo.

La misurazione cattura informazioni sugli attributi delle entità. Un'entità è un oggetto o un evento del mondo reale (processo, prodotto, risorsa).

• L'entità è descritta attraverso caratteristiche specifiche
• Un attributo è un aspetto o una proprietà specifica di un'entità

• Qualità funzionali: grado di soddisfazione dei requisiti funzionali, valutato mediante testing
• Qualità strutturali: grado di soddisfazione dei requisiti non funzionali da parte dell'architettura, valutato mediante analisi architetturali

Quanto è importante misurare?

A chi interessano le misure del software

• Sviluppatori individuali:
  • Distribuzione dello sforzo
  • Durata e sforzo a preventivo (stimati) e a consuntivo
  • Codice coperto da testing di unità
  • Numero di difetti trovati dal test di unità
  • Complessità del progetto e del codice
• Team di progetto
  • Dimensione del prodotto
  • Distribuzione dello sforzo
  • Stato dei requisiti (#approvati, #implementati, #verificati)
  • % dei casi di test superati
  • Durata stimata e reale tra due milestone principali
  • Livelli di staff stimati e reali
  • #difetti trovati dai test di integrazione e di sistema
  • #difetti trovati dalle ispezioni
  • Stato dei difetti
  • Stabilità dei requisiti (#requisiti modificati durante lo sviluppo)
  • Numero di task pianificati e completati
• Organizzazione che sviluppa software
  • Livelli dei difetti rilasciati (critical, major, average, minor, exception)
  • Tempo di ciclo di sviluppo del prodotto
  • Accuratezza della pianificazione e dello sforzo stimati
  • Riuso effettivo
  • Costo preventivato e reale

3

Misurare la qualità

> In un qualsiasi ciclo di vita del software le entità visibili e misurabili sono i processi (le attività), le risorse impiegate e alcuni attributi dei prodotti

• Qualità di un prodotto software: la qualità di un prodotto software è la misura in cui il prodotto soddisfa la sua specifica
• Attributi di qualità interni ed eterni

• Attributi esterni: visibili all'utente
• Attributi interni: visibili agli sviluppatori

Esempi di misure usate in Software Engineering

Tipi di problemi nel software

• Failure: comportamento del software non previsto dalla sua specifica
• Fault: difetto del sorgente (detto anche bug), causa di un failure
• Error: causa di un difetto; esempio: un errore umano d'interpretazione della specifica o nell'uso di un metodo

Da IEEE Standard Glossary of SE Terminology

Perché il software è difettoso?

> Gli esseri umani commettono errori, specie quando eseguono compiti complessi; ciò è inevitabile > I programmatori esperti commettono in media un errore ogni 10 righe > Circa il 50% degli errori di codifica vengono catturati a tempo di compilazione > Altri errori vengono catturati col testing > Circa il 15% degli errori sono ancora nel sistema quando viene consegnato al cliente

4

Da dove arrivano i difetti?

defect insertion rate (per thousand lines of code) 46 2 5 25 2 residual defects after testing reqs design coding testing 4 20 26 24 defect removal rate (per thousand lines of code) Propagation of residual defects Figure 11. Defects are inserted and removed at different rates in each part of the development lifecycle. The difference between insertion and removal rates determines defect propagation rate. This example shows that 2 defects per thousand lines of code remain after testing. (S.G. Eick, C.R. Loader et al., Estimating software fault content before coding, Proc. 15th Int. Conf. on Software Eng., Melbourne, Australia, 1992, pp. 59-65)

Il problema della qualità del software

Assicurare la qualità di un prodotto o servizio è difficile. Nel caso del software valutarla o garantirla è particolarmente complesso Esistono:

• Attività legate alla qualità del software (es.testing)
• Metodi orientati alla qualità di prodotto (es. cleanroom)
• Metodi orientati alla qualità di processo (es. ISO9000)
• Metamodelli di processo orientati alla qualità (es.GQM)

Come introdurre la qualità

Qualsiasi valutazione di qualità inizia dallo scopo (goal) che ha chi la vuole valutare Chi valuta la qualità di una entità (processo, prodotto, servizio, risorsa ... ) dovrebbe:

• Avere chiari i propri obiettivi
• Legarli a domande specifiche sull'entità (prodotto o processo) oggetto di analisi
• Definire metriche capaci di analizzare e quantificare le qualità richieste ai prodotti rispetto agli obiettivi

Come introdurre la qualità: metriche

Le metriche che vengono definite debbono correlarsi agli obiettivi (goals) dell'organizzazione o Le misurazioni dovrebbero essere utili e costruttive, perché l'organizzazione deve imparare analizzandoli o Le metriche e le loro definizioni dovrebbero riflettere il punto di vista di diverse parti interessate (es. sviluppatori, utenti, progettisti etc).

5

Pianificazione di un Modello di Qualità: Passi da Seguire

1. Sviluppo dei goal e delle misure associate alla qualità
2. Generazione di domande che definiscono i goal quantificandoli
3. Specificare le misure da collezionare in conformità al goal
4. Sviluppare i meccanismi operativi di collezione delle misure
5. Raccogliere i dati e analizzarli onde sviluppare azioni correttive
6. Analizzare i dati post-mortem per raccomandazioni sul futuro.

Attività di sviluppo del software: la qualità in ogni fase

Raccolta dei requisiti Analisi dei requisiti System Design Object design Implemen- tazione Testing oki OK! ok! espressi mediante mappati su realizzati con definiti da verificati con Dirder Systom uses Inventory System Class A ... Class B ... Class C ... Modello dei casi d'uso Oggetti del dominio Sotto- sistemi Oggetti del sistema Sorgente Casi di test

Obiettivi di Verifica e Validazione

Verifica: confronto di un prodotto con la sua specifica (ovvero, confronto di un prodotto con i suoi requisiti) Validazione: accettazione del prodotto da parte del committente

Verifica

> L'attività di verifica, così come quella di documentazione, non è una fase separata del processo > Tuttavia, è opportuno che sia effettuata da persone diverse da quelle coinvolte nel design o nella codifica Ogni documento prodotto dovrebbe essere controllato (possibilmente da persone diverse dagli autori del documento) e sistematicamente documentato esso stesso A Esistono due tipi di verifica:

• Ispezione/Code Review: basata sull'analisi statica
• Testing: basata sull'analisi dinamica, esecuzione

6

Attività legate alla qualità

Test Run

• Testing: processo di investigazione sui rischi connessi all'esecuzione di un sistema software
• Misurazione: indicatori di qualità sia mediante ispezione che mediante esecuzione
• Verifica: analisi delle funzioni rispetto alla specifica
• Validazione: accettazione da parte degli stakeholder
• Certificazione: analisi delle funzioni rispetto ai requisiti di legge da certificare

Costo della qualità (ISO)

Due costi principali:

• Costo per fare bene le cose (conformità) q
• Costo per rimettere a posto le cose sbagliate (non conformità)

> I costi della qualità nel processo produttivo sono i costi che si sostengono per adeguare la qualità del prodotto alla qualità richiesta

Costo della conformità (COC) (per soddisfare tutte le esigenze espresse ed implicite)

• costi di prevenzione: oneri sostenuti per prevenire gli insuccessi
• costi di accertamento: oneri per controlli e collaudi

Costo della non conformità (CNC) (per insuccessi interni ed esterni)

• costi per insuccessi interni: oneri connessi ad un prodotto che non soddisfa i requisiti di qualità prima ancora della sua consegna
• costi per insuccessi esterni : oneri connessi ad un prodotto che non soddisfa i requisiti di qualità dopo la sua consegna (costi di manutenzione e riparazione, costi di garanzia e resi, costi per il richiamo dei prodotti, costi per la responsabilità da prodotto, ... )

Standardizzazione

Diversi enti di standardizzazione (eg ISO) hanno cercato di integrare vari approcci alla definizione della qualità, partendo dalla consapevolezza che la qualità è un attributo che varia in funzione del:

• Percettore
• Del contesto di percezione
• Dello scopo e costo del prodotto

• ISO/IEC 9126 (prodotti software)
• ISO 9000 - ISO 12207 - CMM (processi)

Settori vari

7