Sei sulla pagina 1di 125

Ingegneria del Software

(Ing.Informatica Nuovo Ord.)


Canale M-Z / A.A. 2005-06
Marco Cadoli
Universit di Roma La Sapienza
Dipartimento di Informatica e Sistemistica
www.dis.uniroma1.it/~cadoli

PRIMA PARTE

Il processo di produzione del SW


Sezione II: Qualit & standard
Versione definitiva
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

PRIMA PARTE
Il processo di produzione del software
I.
II.
III.
IV.

Introduzione, ciclo di vita del SW


Qualit, standard
Test del SW
Project Management

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

II. Qualit & standard


II.1. Modelli di qualit: primi esempi
II.2. Lo standard ISO 9000/Vision 2000
II.3. Qualit: definizioni
II.4. Qualit del prodotto: ISO 9126

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Standard
PRODOTTO

PROCESSO
CMM (SEI 87)

ISO/IEC 12207 (91)

IS0
14598

ISO/IEC 9126 (91)

ISO 9001 - UNI-EN 29001 (88)


revisionata nel 1994
revisionata nel 2000: Vision 2000
Ing. del SW: Prima parte Sez II

ISO/IEC 9126 (2001)

Marco Cadoli, Universit La Sapienza, ott 2005

II.1. Modelli di qualit: primi esempi


CMM
origine accademica
voluto dal ministero della difesa americano (DOD)
valuta le capacit di chi sviluppa

ISO 12207
prodotto da una organizzazione internazionale
razionalizza le attivit coinvolte
piuttosto obsoleto

ISO 9000
pensato per un qualunque processo produttivo
aggiornato recentemente (Vision 2000)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Modelli di maturit
Sono collezioni strutturate di elementi che descrivono
le caratteristiche dei processi efficaci
Forniscono un punto di partenza basato sullesperienza
pregressa di una comunit, ed uno schema per dare una
priorit alle azioni correttive
Possono essere usati per la valutazione (assessment,
appraisal) di organizzazioni differenti
I modelli di capacit e maturit forniscono un
riferimento per le pratiche mature di una specifica
disciplina, per il miglioramento e la valutazione

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (CMM)


Nel 1987 il SOFTWARE ENGINEERING INSTITUTE
(SEI), della Carnegie Mellon University, ha sviluppato un
modello per valutare i potenziali fornitori di sistemi software

Basato su cinque possibili valori, in grado di fornire al


committente un indicatore della capacit e grado di maturit di
una organizzazione
Ad ogni livello (successivo al primo) sono associate le aree di
processo chiave (KPA) su cui lorganizzazione deve insistere
per attestarsi su quel livello
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (2)


LIVELLO 1 - INIZIALE
Il SW prodotto caratterizzato dallessere
costruito seguendo strategie occasionali (ad
hoc) e caotiche
Solo alcuni processi produttivi sono ben definiti
I successi dipendono solo da sforzi individuali
Solo alcuni processi produttivi sono stabili
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (3)


LIVELLO 2 - RIPETIBILE
- I processi di gestione (project management) dei progetti
pi importanti sono definiti in modo da:
- Permettere la loro pianificazione
- Tenere traccia dei costi (tempo e denaro)
- Lobiettivo principale poter riprodurre le stesse
condizioni che hanno portato al successo in applicazioni
precedenti
continua...
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (4)


... LIVELLO 2 - RIPETIBILE
AREE DI PROCESSO CHIAVE:
GESTIONE DEI REQUISITI (RM)
PIANIFICAZIONE DEI PROGETTI SW (PP)
TRACCIABILIT E VISIBILIT DEI PROGETTI (PT)
GESTIONE DEI SUBAPPALTI (SM)
ASSICURAZIONE DELLA QUALIT DEL SW (QA)
GESTIONE DELLA CONFIGURAZIONE DEL SW (CM)
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

10

Capability Maturity Model (5)


LIVELLO 3 - DEFINITO
- Il processo di produzione del SW segue standard
ben precisi ed documentato ed integrato in una
visione aziendale unica.
- Tutti i progetti utilizzano una versione approvata
e documentata di processi organizzativi per lo
sviluppo e la manutenzione del software.
continua...
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

11

Capability Maturity Model (6)


... LIVELLO 3 - DEFINITO
AREE DI PROCESSO CHIAVE:
DEFINIZIONE

STANDARDIZZAZIONE

DEI

PROCESSI

ORGANIZZATIVI (PF + PD)


COORDINAMENTO INTERGRUPPO (IC)
INGEGNERIZZAZIONE DEI PRODOTTI SW (PE)
GESTIONE DELLE INTEGRAZIONI DEL SW (IM)
CONFRONTI E VERIFICHE (PR)
PROGRAMMI DI FORMAZIONE (TP)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

12

Capability Maturity Model (7)


LIVELLO 4 - GESTITO
Collezione di misure dettagliate sui processi di produzione e
sui prodotti

Aree di processo chiave:


MISURE E ANALISI DI PROCESSO (QP)
GESTIONE DELLA QUALIT DEL SOFTWARE (QM)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

13

Capability Maturity Model (8)


LIVELLO 5 - OTTIMIZZANTE
Miglioramento continuo del processo tramite:
feed-back quantitativi
introduzione di tecnologie innovative (sviluppo, test,
documentazione, ecc.)
Aree di processo chiave:
PREVENZIONE DEI DIFETTI (DP)
INNOVAZIONI TECNOLOGICHE (TM)
GESTIONE DEL PROCESSO DI CAMBIAMENTO (PC)
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

14

Capability Maturity Model: riassunto


Level

Characteristic

Optimizing

Managed

Continuous
Improvement
Predictable

Defined

Repeatable

Initial

Ing. del SW: Prima parte Sez II

Standard and
Consistent
Intuitive
Ad hoc and
Chaotic

Marco Cadoli, Universit La Sapienza, ott 2005

15

CMM: punti da ricordare


+

LA METRICA DEL LIVELLO DI MATURIT MOLTO ISTRUTTIVA:


SPIEGA COME UNORGANIZZAZIONE DOVREBBE MUOVERSI VERSO
LALTO

LA METRICA RICONOSCIUTA COME STANDARD INDUSTRIALE E


PERMETTE CONFRONTI

IL PROCESSO DI VALUTAZIONE (ASSESSMENT) PER DETERMINARE


IL LIVELLO DI MATURIT MISURA LESISTENZA DI CERTI
STANDARD E NON LA QUALIT O LEFFICACIA DI TALI STANDARD

NON PREVISTO UN PIANO IMPLEMENTATIVO PER OTTIMIZZARE


IL PASSAGGIO A LIVELLI PI ALTI

Problema: il SEI afferma che il 70% delle organizzazioni


che producono SW sono a livello 1
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

16

Capability Immaturity Model (CIMM)


0. Negligent (Indifference)
Failure to allow successful development process to succeed. All problems are
perceived to be technical problems. Managerial and quality assurance activities
are deemed to be overhead and superfluous to the task of software development
process. Reliance on silver pellets.
-1. Obstructive (Counter Productive)
Counterproductive processes are imposed. Processes are rigidly defined and
adherence to the form is stressed. Ritualistic ceremonies abound. Collective
management precludes assigning responsibility. Status quo ber alles.
-2. Contemptuous (Arrogance)
Disregard for good software engineering institutionalized. Complete schism
between software development activities and software process improvement
activities. Complete lack of a training program.
-3. Undermining (Sabotage)
Total neglect of own charter, conscious discrediting of peer organizations
software process improvement efforts. Rewarding failure and poor performance.
http://www.stsc.hill.af.mil/
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

17

Altri aspetti del CMM


Il successo del CMM, in termini di:

Miglioramento dei tempi di realizzazione


Diminuzione dei difetti pre-rilascio
Diminuzione dei difetti post-rilascio
Tempi di completamento di una richiesta di servizio
Produttivit
Riuso del software
Soddisfazione dei lavoratori

ampiamente documentato. Si veda ad es.:


studio (2001) della Boeing su 216 organizzazioni interne
(livelli 1-5)
studio (2002) della General Dynamics Decision Systems su 3
organizzazioni interne (livello 5)
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

18

Altri aspetti del CMM (2)


% del tempo
di sviluppo
del progetto
speso in
rilavorazione

Difetti latenti
(Customer
Reported
Unique
Defects) per
1000 linee di
codice
sorgente

% dei difetti
scoperti nella
fase in cui
sono creati

Lavoro per
unit di
tempo
(ad es.,
LOC/giorno)

Da How CMM Impacts Quality, Productivity,Rework, and the


Bottom Line, Crosstalk, Marzo 2002
http://www.stsc.hill.af.mil/crosstalk/2002/03/diaz.html
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

19

Altri aspetti del CMM (3)


Abbiamo visto le idee fondamentali del SW-CMM
Esistono modelli per le persone (P-CMM), per
lacquisizione del Software (SA-CMM),
Dal 2002 il CMM non viene pi manutenuto
(aggiornato, venduto, )
Viene sostituito dal CMMI (Integration): visione
strutturata del miglioramento del processo, integrando
organizzazioni tradizionalmente separate

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

20

Standardizzazioni
Le idee del SEI hanno influenzato lo sviluppo di
alcuni standard ISO (proposti e/o ancora in
analisi) allinterno del progetto SPICE (Software
Process Improvement and Capability
dEtermination).
Framework ISO/IEC 12207 (1991)
definisce e sistematizza tutte le attivit convolte nel
processo di produzione del sw
approccio funzionale ai processi produttivi : insieme
di attivit coordinate che trasformano un ingresso in
una uscita

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

21

I processi ISO 12207

Cinque processi primari (primary) che


riguardano i cinque agenti primari ovvero:
1. acquirente,
2. fornitore,
3. chi sviluppa il prodotto sw,
4. chi eroga il servizio di gestione,
5. chi eroga il servizio di manutenzione.

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

22

I processi ISO 12207 (2)

Otto processi di supporto (supporting) agli altri


processi (documentazione, configurazione, qualit,
ecc.), che contribuiscono al successo ed alla qualit
del progetto sw.
Quattro processi organizzativi (organizational),
usati:

per stabilire e implementare una struttura costituita da


processi e personale, e
migliorare in modo continuo sia la struttura sia i processi.

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

23

I processi ISO 12207 (3)

I processi si dividono in attivit (activities)


e queste ultime in compiti (tasks).

Oltre ai processi suddetti vi quello di


personalizzazione (tailoring), che fornisce i
requisiti per adattare le indicazioni della
12207, in funzione del contesto duso.

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

24

I processi ISO 12207 (4)


Processi primari del ciclo di vita

Processi di supporto
1 Documentazione

1 Acquisizione

2 Gestione della Configurazione


2 Fornitura

3 Assicurazione di qualit
4 Verifiche

4
Esercizio

3 Sviluppo

5
Manutenzione

5 Validazioni
6 Riesami congiunti
7 Ispezioni
8 Risoluzione dei problemi

Processi organizzativi del ciclo di vita


1 Management

2 Infrastrutture

3 Miglioramenti

4 Addestramento

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

25

Processo primario 3: le 13 attivit


Processi primari del ciclo di vita

3 Sviluppo

Ing. del SW: Prima parte Sez II

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

Implementazione del processo


Analisi dei requisiti del S.I.
Progettazione dellarchitettura del S.I.
Analisi dei requisiti del sw
Progettazione dellarchitettura del sw
Progettazione di dettaglio del sw
Codifica e testing del sw
Integrazione del sw
Test sulla qualit del sw
Integrazione del sistema (hw + sw)
Test sulla qualit del sistema
Installazione del sw
Supporto per il collaudo di accettazione
del sw
Marco Cadoli, Universit La Sapienza, ott 2005

26

12207: Processi di supporto


1.

2.

3.

4.

Documentazione (documentation) - le attivit di


registrazione delle informazioni prodotte durante un
(qualunque) processo.
Gestione della configurazione (configuration
management) - le attivit di identificazione e controllo
delle modifiche del software in via di costruzione.
Assicurazione della qualit (quality assurance) - le
attivit per garantire in modo obiettivo che processi e
prodotti siano conformi ai requisiti e rispettino i piani.
Verifica (verification) - controllo della corrispondenza tra i
requisiti e le caratteristiche del sistema (condotto
dallacquirente, dal fornitore o da una terza parte
indipendente).
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

27

12207: Processi di supporto (2)


5. Validazione (validation) - controllo delleffettivo
raggiungimento degli obiettivi (condotto dallacquirente,
dal fornitore o da una terza parte indipendente).
6. Riesame congiunto (joint review) - le attivit per
valutare lo stato e i prodotti di unattivit.
7. Audit - le attivit per determinare la conformit con i
requisiti, i piani ed il contratto (coinvolgimento di un
ente esterno al sistema).
8. Soluzione dei problemi (problem resolution) - le
attivit per analizzare e rimuovere i problemi (incluse le
non conformit).

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

28

12207: Processi organizzativi


1.

Management - le attivit basilari del management


(incluso il project management).

2.

Ambiente (infrastructure) - le attivit basilari atte a


fornire lambiente (hw, sw e logistica) per un
processo.

3.

Miglioramento (improvement) - le attivit basilari di


unorganizzazione per stabilire, misurare, controllare
e migliorare i propri processi.

4.

Addestramento (training) - le attivit atte a fornire


personale adeguatamente formato.

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

29

II.2. Standard ISO 9000 (2000)

Motivazioni
Obiettivi
Confronto con CMM
Vision 2000

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

30

Motivazioni per la stesura della


normativa ISO 9000
La famiglia di norme ISO 9000 fornisce le regole
manageriali/organizzative e di processo che le
organizzazioni operanti nel settore manifatturiero e/o dei
servizi dovrebbero seguire per rendere razionali, efficienti,
efficaci ed affidabili le attivit del loro ciclo produttivo.
La ISO 9000 stata emessa dallo International
Organization for Standardization (ISO) (www.iso.ch) fin
dalla met degli 80 (nella sua prima versione). Lultima
versione del 2000, la precedente era del 1994.

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

31

Obiettivi principali della ISO 9000


Tecnico-organizzativo: fornire un insieme di
regole (concettuali) per migliorare e
razionalizzare i processi produttivi
Diffondere una cultura della qualit
Marketing: creare nei clienti fiducia nei confronti
delle organizzazioni che dimostrano di applicare
bene queste regole
Questultimo obiettivo si raggiunge attraverso la
certificazione di conformit alle regole ISO 9000
rilasciata da terze parti abilitate a farlo
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

32

Livello di astrazione della ISO 9000


I requisiti ISO 9000 sono ad un livello di
astrazione piuttosto alto, in quanto pensati per
essere applicabili da qualsiasi organizzazione,
indipendentemente dal settore merceologico o di
servizi in cui opera
Perci, la ISO 9000:
non entra nel merito di come vanno svolte, dal
punto di vista tecnico, le attivit previste dai vari
processi lavorativi,
definisce per ogni processo preso in considerazione
quegli accorgimenti di natura
manageriale/organizzativa che hanno maggiore
influenza sul risultato finale del processo
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

33

Riassunto dei concetti ISO 9000


Qualit
caratteristiche volte a soddisfare esigenze
Controllo qualit
attivit tese a soddisfare i requisiti qualit
Assicurazione qualit
azioni pianificate a dare confidenza che un prodotto soddisfi
determinati requisiti qualit
Sistema qualit
struttura organizzativa
regole
procedure

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

34

I differenti standard ISO 9000


Prima della versione 2000 della ISO 9001, la norma era
tripartita.
Requisiti Sviluppo del Produzione Ispezione Installazione Manutenzione
e servizio
del cliente
prodotto
e test

ISO 9003
ISO 9002
ISO 9001
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

35

Modello dei requisiti ISO 9001: 1994


4.1 Responsabilit della direzione
4.2 Sistema Qualit
4.3 Riesame del contratto
(no 9003)
4.4 Controllo della progettazione
(no 9002, 9003)
4.5 Controllo dei documenti e dei dati
4.6 Approvvigionamento
(no 9003)
4.7 Controllo dei prodotti forniti da terzi
(no 9003)
4.8 Identificazione e tracciabilit del prodotto
4.9 Controllo del processo
(no 9003)
4.10 Prove, controlli, collaudi
4.11 Controllo delle apparecchiature per prove, misurazione e collaudo
4.12 Stato delle prove, controlli e collaudi
4.13 Controllo dei prodotti non conformi
4.14 Azioni preventive e correttive
(no 9003)
4.15 Movimentazione, immagazzinamento, imballaggio, conservazione e consegna
4.16 Controllo delle registrazioni della qualit
4.17 Verifiche ispettive interne della qualit
(no 9003)
4.18 Addestramento
4.19 Assistenza
(no 9002, 9003)
4.20 Tecniche statistiche
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

36

ISO 9001 - 4.4 Controllo del progetto


1. Il fornitore deve avere uno standard per controllare e
verificare che i requisiti utente siano rispettati
2. Le interfacce tra i vari gruppi di lavoro devono essere
chiare e ben documentate
3. Le specifiche di progetto devono essere adeguatamente
documentate
4. Il progetto del software deve rispecchiare i requisiti
iniziali
5. I progettisti devono in modo esplicito pianificare attivit
di verifica su quanto progettato
6. Cambiamenti e differenti configurazioni devono essere
opportunamente documentati
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

37

Confronto CMM ISO 9001


Cambiamenti di tecnologia
Prevenzione dei problemi
Misure di processo
Analisi di processo
Piani di qualit quantitativi
Formazione
Revisioni e test sistematici
Standard
Project management
Controllo della configurazione
Assicurazione di qualit

5.Ottimizzante

4.Gestito

3.Definito

2.Ripetibile

4 . 20 (Statistiche)
4 . 14 (Azioni Preventive)

4 . 18 (Addestramento)
4 . 17 (Verifiche ispettive interne qualit)

4 . 4 (Controllo Progetto)
4 . 5 / 4 . 8 (Controllo Document./Ident. rintr. prod.)
4 . 2 (Sistema Qualit)

1.Iniziale

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

38

Confronto CMM ISO 9001:


domande tipiche
A che livello CMM corrisponde una certificazione
ISO?
Un livello CMM 2 o 3 pu essere considerato
equivalente ad una certificazione ISO?
Quele standard per la gestione della qualit ed il
miglioramento del processo produttivo dovrebbe
essere seguito?

http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr12.94.pdf

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

39

Confronto CMM ISO 9001: prima


analisi
Due standard per la qualit e la gestione del processo
ISO 9000 del tutto generale
CMM specifico per la produzione del software

Coprono aspetti mutuamente esclusivi


Prevedono entrambi un processo di certificazione
Unico per ISO 9000
Cinque livelli per CMM

Differente livello di dettaglio:


Capitolo 4 di ISO 9001: 4 pagine
CMM: 500 pagine
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

40

ISO 9001 - 4.4 Controllo del progetto


ISO 9001 Controllo del progetto
pianificazione delle attivit di progetto
identificazione degli ingressi e uscite
controllo dei cambiamenti di progetto
CMM PE: Software Product Engineering livello 3
(Definito)
analisi dei requisiti-progetto-codifica-test

CMM PP: Software Project Planning livello 2


(Ripetibile)
pianificazione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

41

ISO 9001 - CMM


Cosa c in pi in ISO 9001
4.7 Controllo di prodotti forniti da terzi
4.15 Movimentazione, immagazzinamento, imballaggio,
conservazione e consegna

Spesso le corrispondenze non sono 1:1


Spesso il livello di dettaglio differente
CMM enfatizza il processo di miglioramento
Principale punto di contatto:
dire cosa si vuol fare (say what you do)
fare quello che si detto (do what you say)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

42

Dalla ISO 9001:1994 alla Vision 2000


Il sistema attuale della famiglia ISO 9000 stato
ridefinito nel dicembre 2000, attraverso il progetto
denominato Vision 2000
Obiettivo della revisione: passare dalla cultura
della conformit e delle evidenze a quella del
continuo miglioramento, reale e misurabile dal
cliente
La revisione rientra nel programma
quinquennale di revisione periodica delle norme
emesse che la ISO persegue come politica di
gestione della normativa
Procedure di valutazione strettamente collegate al
marchio europeo CE
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

43

Il sistema Vision 2000

Lattuale sistema di norme composto da circa 10 documenti (erano 20 nel


1994) e le norme chiave sono:
1.

2.

3.

ISO 9000 "Sistemi di gestione per la qualit - Fondamenti e terminologia" che


descrive i concetti e i fondamenti dei sistemi di gestione per la qualit e la
terminologia. Sostituisce la norma ISO 8402, il dizionario della qualit.
ISO 9001 "Sistemi di gestione per la qualit - Requisiti" che specifica i requisiti
dei sistemi di gestione per la qualit che unazienda/organizzazione deve
soddisfare per dimostrare la sua capacit di fornire prodotti che soddisfino i
requisiti del cliente e di ambiti regolamentati
ISO 9004 "Sistemi di gestione per la qualit - Linee guida per il
miglioramento delle prestazioni" che fornisce una guida sui sistemi di gestione
per la qualit, inclusi i processi per il miglioramento continuativo, ai fini della
soddisfazione dei clienti dell'azienda/organizzazione e delle altre parti
interessate. NON oggetto di certificazione. Sostituisce la ISO 9004-1

Tutte le rimanenti norme della famiglia ISO 9000 pre-2000, sono


attualmente in corso di riesame e sottoposte ad una valutazione per diventare
dei rapporti tecnici
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

44

Elementi innovativi Vision 2000 (1)


1. Impostazione della qualit aziendale orientata ai
processi
2. Ritagliabilit (tailoring) ovvero la possibilit di
personalizzazione dei requisiti in funzione di specifici
obiettivi aziendali, o la non applicazione se non trovano
riscontro nelle attivit reali dell'azienda/organizzazione
(n.b., la nuova normativa dice chiaramente cosa si pu e
cosa NON si pu escludere relativamente alle attivit
svolte dalla organizzazione)
3. Maggiore facilit duso del modello, in modo da
estendere la possibilit di valutazione del grado di
applicazione dei requisiti della norma anche ai non addetti
ai lavori
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

45

Elementi innovativi Vision 2000 (2)


4. Allargamento delle linee aziendali interessate al Sistema
Qualit, con particolare riferimento a chi gestisce gli
aspetti finanziari, manageriali, amministrativi,
commerciali, di relazione con la clientela, limpatto
sullambiente etc.
5. Valutazione del Sistema Qualit legata a risultati di
efficacia oltre che di efficienza
6. Specifici punti del modello dedicati alla rilevazione e
gestione della soddisfazione del cliente
7. Orientamento ai fatti ed ai dati come fattori di
pianificazione degli interventi
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

46

Come cambia la ISO 9001 (1)


1. Riduzione dei modelli di sistemi qualit da tre (ISO 9001,
ISO 9002, ISO 9003) ad uno solo
2. La struttura prevede solo quattro elementi fondamentali di
sistema (punti da 5, 6, 7 e 8) rispetto ai venti elementi di
sistema di gestione (punti da 4.1 a 4.20) dell'edizione
1994
3. Maggiore enfasi alla gestione per processi, alle esigenze e
alla soddisfazione dei clienti
4. Minore enfasi alle procedure documentate
5. Maggiori prescrizioni per il miglioramento continuativo
6. Maggiore chiarezza sul ruolo dell'alta direzione o dei
vertici dell'organizzazione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

47

Come cambia la ISO 9001 (2)


7.

Inserimento di considerazioni sui requisiti legislativi e


regolamentari

8.

richiesta la definizione di obiettivi misurabili

9.

previsto il monitoraggio delle informazioni sulla


soddisfazione del cliente

10. Maggiori indicazioni sulla gestione delle risorse


11. Indicazioni sulla determinazione dellefficacia
delladdestramento
12. Misurazioni estese al sistema di gestione, ai processi e
al prodotto e/o servizio
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

48

I 4 processi base
1. Responsabilit della direzione, in 6 punti, tra cui
rilevante il secondo, attenzione focalizzata al cliente,
che introduce specifici elementi per guidare nella corretta
analisi delle necessit dei clienti.
2. Gestione delle risorse. Tra le novit, va segnalata la voce
relativa alla Formazione e Qualificazione.
3. Realizzazione del prodotto e/o del servizio, dove si
addensano probabilmente le novit pi importanti,
introducendo una particolare attenzione alla qualit dei
processi
4. Misure, analisi, miglioramenti. Anche qui una novit
rilevante la misura della soddisfazione utente
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

49

I requisiti vanno adattati


I requisiti di processo definiti nella ISO 9000 devono
essere adattati e personalizzati dalle organizzazioni
secondo i diversi contesti in cui operano.
Questa contestualizzazione produce un insieme di requisiti
di processo e di risorse propri di ogni organizzazione, che
ne definiscono, nel loro insieme, il sistema di gestione per
la qualit (sistema qualit)
Il sistema qualit di una organizzazione definisce la
politica per la qualit che essa persegue, in termini di
struttura organizzativa, attivit, controlli, risorse, a
prescindere dalle esigenze di specifiche commesse o
richieste di clienti.
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

50

Assicurazione della qualit


Assicurazione della qualit: linsieme delle
attivit pianificate e sistematicamente attuate
in una organizzazione per dimostrare (ai
potenziali clienti) la capacit di fornire un
prodotto conforme ai requisiti
NB: questa dimostrazione pu essere rivolta da
una azienda verso i potenziali clienti cos
come da una unit organizzativa aziendale nei
riguardi della propria Direzione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

51

Gestione della qualit


La UNI ISO 9004:2000 (Sistemi di gestione per la
qualit. Linee guida per il miglioramento della
qualit) descrive come sviluppare e gestire un
Sistema di gestione della Qualit conforme ai
requisiti ISO 9001:2000.
La norma di carattere generale, con regole valide
per ogni ambito di applicazione (qualsiasi settore
merceologico o di servizi).
Le due norme ISO 9001 e ISO 9004 hanno una
struttura (indice) comune.
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

52

ISO 9001: certificazione e


documentazione
Le organizzazioni possono richiedere a organismi specializzati di
rilasciare loro (dopo aver compiuto delle verifiche) una
certificazione di conformit al sistema ISO 9001.
Nella visione 2000 della norma, si prevede che le verifiche
debbano riguardare anche la efficacia dei processi, eventualmente
a fronte di specifici obiettivi aziendali e di settore
Il sistema ISO 9000 prevede che i processi svolti vengano
descritti in documenti specifici, dei quali vengono forniti indice e
sommario dei contenuti, nonch guide alla loro compilazione in
vari contesti
Questi documenti sono:
Manuale della qualit
Piano della qualit
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

53

Il manuale della qualit


Le organizzazioni devono descrivere il proprio
sistema qualit nel documento chiamato manuale
della qualit
Il manuale della qualit, secondo la ISO9000/ISO
8402, il documento che enuncia la politica per
la qualit e descrive il sistema qualit di una
organizzazione
La ISO ha emesso a supporto della stesura del
manuale della qualit una guida, contenuta nella
norma ISO 10013
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

54

Il piano della qualit


Non sempre la qualit potenzialmente raggiungibile
quella effettivamente necessaria
Ladattamento della politica generale per la qualit a
specifiche esigenze viene descritta, di volta in volta, in
piani della qualit, dove vengono definiti, in termini
quantitativi, gli obiettivi da raggiungere, i controlli
previsti, le risorse impiegate, le responsabilit, la
pianificazione delle attivit, la documentazione di riscontro
che verr prodotta ad uso del cliente
Il Piano della qualit, secondo la ISO 9000/ISO 8402, il
documento che precisa le particolari modalit operative,
le risorse e le sequenze delle attivit relative alla qualit di
un determinato prodotto, progetto o contratto
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

55

Flusso della documentazione


Contesto
Lavorativo

Risorse

ISO 9000
MdQ

ISO 10005

PdQ
ISO 10013

Cliente

Ing. del SW: Prima parte Sez II

Obiettivi
progetto

Marco Cadoli, Universit La Sapienza, ott 2005

56

II.3. Qualit: definizioni

Costo della qualit


Organizzazioni internazionali
Errori, difetti e malfunzionamenti
Cause di errori
Fattori di qualit
Attivit per lassicurazione della qualit

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

57

Il costo della qualit (fonte ISO 9004-1)


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

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

58

Il costo della qualit (2)


Costo della non conformit (CNC)

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,
...
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

59

Il costo della qualit (3)


CNC
Costo della
non conformit

CNC+COC

COC

Costo della
conformit

costo

Punto di costo minimo

Basso

impegno in attivit di prevenzione e verifica

Ing. del SW: Prima parte Sez II

Alto

Marco Cadoli, Universit La Sapienza, ott 2005

60

Chi pu dire cosa sia la qualit?


Diversi enti di standardizzazione (ad es. 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
del costo del prodotto.
ISO 9000 - ISO 12207 - CMM (SEI) (Processi)
ISO/IEC 9126 (Prodotti informatici)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

61

ISO e altre organizzazioni


Settori
vari

Settore
elettrotecnico

A livello internazionale

ISO

IEC

A livello europeo

CEN

CENELEC

A livello nazionale

UNI

CEI

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

62

Sigle
lSO
IEC
CEN
CENELEC
UNI
CEI

International Organization for Standardization


International Electrotechnical Commission
Comitato Europeo di Normazione (sigla sui documenti EN)
Comitato Europeo di Normazione Elettrotecnica (sigla sui documenti
EN HD)
Ente Nazionale Italiano di Unificazione
Comitato Elettrotecnico Italiano

Tra gli organismi ISO a livello nazionale non europeo:


ANSI
JISC
SA
SCC

American National Standard Institute, per gli Stati Uniti;


Japan Industrial Standards Committee, per il Giappone;
Standards Australia, per l'Australia;
Standard Council of Canada, per il Canada.

I 18 organismi National Standard Bodies del CEN rappresentano tutti i paesi


europei, con laggiunta di 7 affiliati di cui 5 paesi limitrofi, pi Cipro e
Turchia (tra questi rientra lUNINFO - Ente di normazione Federato all'UNI
per le Tecniche Informatiche e le loro applicazioni - per lltalia.
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

63

Definizioni di Software
Definizioni ISO 12207 e IEEE:
Prodotto sw: insieme di programmi, procedure, e
della documentazione e dei dati associati
Elemento sw: parte identificabile di un prodotto
sw, ad uno stadio intermedio o allo stadio finale di
sviluppo

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

64

I quattro componenti
1. Codice
2. Procedure: tutte le informazioni necessarie alla corretta
esecuzione del codice (sequenza di esecuzione, persone, ecc.)

Precedenze tra attivit


Persone coinvolte, ruoli

3. Documentazione

Sviluppatori (requisiti, progetto, descrizione codice)


Utenti (manuale utente/help in linea)
Manutentori (documentazione ad alto livello del codice per cercare le
cause di errori / punti per cambiamenti)

4. Dati associati (file di configurazione, file dati (DBMS), test


report)
La qualit del codice solo 1 di 4 fattori!
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

65

i > 0
invece di
i >= 0

Errori, difetti e malfunzionamenti


viene
eseguita
uniterazione
in pi

Lerrore commesso da un essere umano (errore


nel codice, nella documentazione, ecc.)
Il difetto una caratteristica fisica di una porzione
di codice o di una sezione di un testo di
documentazione che PU manifestarsi a causa di
un errore
Il malfunzionamento la conseguenza di un
difetto che PU manifestarsi durante lutilizzo del
prodotto software (e lutente se ne accorge)
viene stampata una
media errata
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

66

Errori, difetti e malfunzionamenti

Si noti che i malfunzionamenti del SW possono apparire dopo anni di


funzionamento corretto (caso famoso: problema dellanno 2000)
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

67

Cause di errori (1,2)


1 - Requisiti difettosi
Errati
Mancanti (requisiti fondamentali)
Incompleti
Inutili
2 - Incomprensioni cliente-sviluppatore
Mancata comprensione:
dei requisiti ufficiali
dei cambiamenti ufficiali
dei cambiamenti verbali
delle risposte del cliente a problemi di progetto
evidenziati dallo sviluppatore
Mancata attenzione a richieste di cambiamenti del cliente o
a risposte dello stesso
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

68

Cause di errori (3,4)


3 - Deviazioni deliberate dai requisiti
Riuso effettuato senza una corretta analisi
Omissioni ufficiali (per motivi di tempo o denaro) di
alcune funzionalit
Omissioni non ufficiali di requisiti valutati meno
importanti
4 - Errori di progetto
Errori algoritmici
Errori di processo (tipicamente sulle sequenze degli
avvenimenti), spesso legati alla differenti culture
analista/cliente
Errori di condizioni al contorno (valori estremi)
Mancata definizione del comportamento del sistema a
fronte di operazioni/input errati
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

69

Cause di errori (5,6)


5 - Errori di codifica
...

6 - Non aderenza agli standard di codifica e


documentazione
Non sono veri e propri errori ma inducono un tasso pi alto
di errori nei seguenti casi:
Integrazione di moduli standard con moduli non
standard
Riuso di codice o sostituzione di personale
Revisioni formali
Test
Manutenzione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

70

Cause di errori (7,8,9)


7 - Processo di test affrettato (soldi, tempo, pianificazione
errata)
Piano di test incompleto
Mancata o inadeguata notifica di errori scoperti durante il test
Correzione incompleta di errori (negligenza o vincoli stringenti)

8 - Errori nelle procedure


Nascono nei sistemi software complessi, dove le attivit vengono
effettuate per passi successivi

9 - Errori di documentazione
Omissioni, descrizione di funzionalit inesistenti, mancato
allineamento con la versione corrente
Errori nei documenti di progetto e documentazione del sw
Errori nella documentazione utente

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

71

Qualit del software


IEEE:
Il livello con cui un sistema, componente o processo
soddisfa i requisiti
Il livello con cui un sistema, componente o processo
soddisfa le esigenze o aspettative di un utente

PRESSMAN:
Conformit con requisiti funzionali e non funzionali,
con espliciti standard di sviluppo e caratteristiche
implicite di un software sviluppato professionalmente

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

72

SW quality assurance (SQA):


Assicurazione della qualit del sw
IEEE
un insieme pianificato e strutturato di azioni necessarie
a fornire la confidenza che un prodotto sia conforme ad
un insieme di requisiti tecnici
un insieme di attivit pensate per valutare il processo
con cui sviluppato il prodotto software

Daniel Galin SW Quality Assurance (2004)


IEEE + conforme a vincoli su:
manutenzione
tempo
$
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

73

Fattori di qualit
Alla base di un qualunque tentativo di produrre sw
di qualit c la necessit di avere unottima
documentazione dei requisiti (se non noto cosa
occorre fare difficile farlo bene...)
In particolare, oltre alla definizione corretta di
specifiche funzionali e non, occorre includere tutti
gli aspetti di qualit ritenuti essenziali per
lapplicazione, quali, ad esempio:

usabilit
manutenibilit
affidabilit
...

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

74

Fattori di qualit (2)


nata, quindi, lesigenza di classificare quali siano gli
aspetti di qualit da includere nei requisiti o, pi in
generale, attribuibili ad un applicativo software (inteso nei
suoi quattro componenti)
La prima, ed estremamente attuale proposta di McCall
(1977) e prevede 11 fattori di qualit. Ulteriori estensioni
hanno aumentato e ridenominato i fattori da considerare (lo
standard 9126 del 2001 prevede 21 sottocaratteristiche)
La proposta di McCall divide i fattori di qualit in 3 gruppi
Fattori relativi al funzionamento
Fattori relativi alle attivit di revisione
Fattori relativi alle attivit di transizione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

75

Attivit per lassicurazione della


qualit del SW (SQA)
1. Definizione del processo di produzione e sue
relazioni con gli standard
2. Effettuazione di misure sul sw
3. Pianificazione dei test
4. Revisioni tecniche formali

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

76

Revisioni tecniche formali (FTR)


Una revisione tecnica formale :
una valutazione tecnica di un artefatto (codice,
documento di analisi, ) prodotto durante il
processo di produzione
una riunione a cui partecipano tecnici (fra cui
lautore)
un meccanismo per assicurare la qualit del sw
una maniera per addestrare le persone meno
esperte
Non una riunione per valutare il budget, modificare
la pianificazione,
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

77

Obiettivi di una revisione tecnica


formale
1.
2.
3.
4.
5.

Scoprire errori
Verificare il soddisfacimento dei requisiti
Verificare se si stanno rispettando gli standard
Verificare il grado di uniformit del prodotto
Rendere pi governabili i progetti

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

78

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

79

Alcune regole per le FTR


Riunioni:

Poche persone (3-5)


Preparazione veloce (~2 ore)
Durata corta (~2 ore)

Documentazione: relazione comprendente

Oggetto della revisione


Persone coinvolte
Conclusioni

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

80

Qualit su base statistica


Slogan: Dedica il tuo tempo alle cose che contano,
ma prima stabilisci quali siano
Metodologia:
1. Stilare una lista di cause di errore nel sw
2. Durante un periodo di tempo sufficientemente
lungo, attribuire una di tali cause ad ogni errore
nel sw scoperto
3. Individuare unazione correttiva

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

81

Cause tipiche di errori nel sw

Specifiche incomplete/errate (IES)


Fraintendimento comunicazione col cliente (MCC)
Deviazione intenzionale dalle specifiche (IDS)
Violazione di standard di programmazione (VPS)
Errori nella rappresentazione dei dati (EDR)
Inconsistenza nellinterfaccia fra componenti (ICI)
Errore logico nella progettazione (EDL)
Test incompleti/errati (ICI)
Errore nella traduzione in ling. di progr. (PLT)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

82

Tipologie di errori pi frequenti


Su base statistica, si rilevato che gli errori pi
frequenti sono nelle seguenti categorie:
Specifiche incomplete/errate (IES)
Fraintendimento comunicazione col cliente (MCC)
Errori nella rappresentazione dei dati (EDR)
Errore nella traduzione in ling. di progr. (PLT)
Errore logico nella progettazione (EDL)
Lazione correttiva dipender della tipologia di errore
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

83

Misure di affidabilit
Sulla base di dati storici, possibile valutare
laffidabilit di un prodotto sw.
Vengono prese in considerazione due grandezze:
MTTF (mean time to failure, tempo medio prima di
un guasto quando il programma in esercizio)
MTTR (mean time to repair, tempo medio di
riparazione quando il programma non in
esercizio)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

84

Affidabilit e disponibilit

MTBF = MTTF + MTTR


(mean time between failure)
Disponibilit = 100 MTTF/MTBF %

Esempio:
MTTF = 90 giorni
MTTR = 3 giorni
MTBF = 93 giorni
Disponibilit = 100 * 90/93 % = 96,8 %
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

85

II.4. Qualit del prodotto:


ISO/IEC 9126

Definizioni
La revisione del 2001
Qualit interna, esterna, in uso
Caratteristiche e sottocaratteristiche
Metriche
Punti di vista

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

86

La norma ISO/IEC 9126

Dai modelli di McCall e B.Boehm derivata la norma


ISO/IEC 9126 Software engineering - Product quality,
pubblicata una prima volta nel 1991 e revisionata e
ripubblicata nel 2001
La qualit del software definita come linsieme delle
caratteristiche che incidono sulla capacit del prodotto
di soddisfare requisiti espliciti o impliciti. (definizione
molto vicina a quella riportata nella ISO 9004/ISO
8402, il dizionario della qualit ISO)
Il prodotto software definito come linsieme di
programmi, procedure, regole, documenti, pertinenti
allutilizzo di un sistema informatico
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

87

Contenuti della ISO/IEC 9126


La 9126 definisce:
tre tipologie di qualit del software (interna,
esterna, in uso) che qualsiasi progetto di
sviluppo (eventualmente in misura
differenziata) deve cercare di realizzare
le principali carateristiche (requisiti astratti)
che caratterizzano un software di qualit,
secondo le 3 tipologie
per ogni caratteristica, le sottocaratteristiche
che la caratterizzano in dettaglio e che dovranno
essere misurate per valutare il livello di qualit
effettivamente raggiunto nel software
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

88

ISO 9126 - definizioni


Caratteristica (o attributo): propriet di
unentit che pu essere percepita in modo
quantitativo o qualitativo da una persona o uno
strumento. Le caratteristiche sono dettagliate in
sottocaratteristiche
Indicatore: una misura che fornisce una stima o
una valutazione di un attributo sulla base di
specifiche regole di misurazione
Contesto duso: linsieme di utenti, procedure,
risorse hardware, software o daltra natura,
lambiente fisico e sociale nel quale il prodotto
utilizzato
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

89

ISO 9126 definizioni (2)


Misura: valore risultante da unoperazione di
misurazione
Misura base (elementare): una misura
funzionalmente indipendente da altre
Misura derivata: una misura calcolata a partire
da altre misure, utilizzando un algoritmo o una
funzione
Misurazione: insieme di operazioni finalizzate a
rilevare una misura
Metrica: un metodo di misura (una sequenza di
operazioni per quantificare una misura) e una
scala di misura
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

90

Struttura del modello


La struttura del modello quindi definita su 3
livelli:
1. le caratteristiche base che definiscono la
qualit dei prodotti, espresse secondo una
prospettiva abbastanza vicina a quella
dellutente finale
2. le sottocaratteristiche che per ogni
caratteristica base ne dettagliano maggiormente
alcuni aspetti
3. le misure da rilevare tramite gli indicatori per
valutare il livello di possesso delle
caratteristiche e sottocaratteristiche, secondo una
prospettiva pi tecnica
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

91

Limiti del modello di qualit


Questo modello ha dei limiti intrinseci:
difficile che le caratteristiche e
sottocaratteristiche siano sempre tra loro
perfettamente indipendenti
le caratteristiche sono propriet astratte che
vanno correlate ad uno o pi indicatori che
vanno misurati attraverso metriche. Non sempre
queste sono in correlazione lineare con le
caratteristiche che devono stimare
manca in ogni caso il legame tra il modello
qualitativo e come fare poi del buon software
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

92

Gli obiettivi della 9126-1


La norma si propone come supporto a chi
definisce la qualit dei prodotti software secondo
differenti prospettive:
acquisizione, definizione dei requisiti, sviluppo, uso,
valutazione, assistenza, manutenzione, verifica

Destinatari della norma sono:

Utenti
Sviluppatori/manutentori
Gestori del sistema
Committenti

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

93

Gli utilizzi della 9126-1


Esempi proposti di utilizzo sono:

identificare i requisiti
validare la completezza dei requisiti
identificare gli obiettivi della fase di progetto
identificare i criteri di assicurazione della qualit
identificare i criteri di accettazione dei prodotti
fornire un quadro di riferimento per la definizione della
qualit del software in un documento contrattuale
fornire un supporto per le revisioni, verifiche,
validazioni, valutazioni

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

94

Revisione del 2001


La ISO/IEC 9126 (2001) si compone di 4 parti:
1. il modello delle caratteristiche e sottocaratteristiche di
qualit del software (Part 1: Quality model, 2001)
2. le metriche per la misura della qualit esterna (ISO/IEC
TR 9126-2, 2003)
3. le metriche per la misura della qualit interna (ISO/IEC
TR 9126-3, 2003)
4. le metriche per la misura della qualit in uso (In
preparazione)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

95

I nuovi concetti base


La revisione della 9126 introduce alcuni
importanti innovazioni:
Il concetto di qualit si modifica sia durante lo sviluppo
del ciclo di vita del software sia a seconda del prevalere
dei diversi punti di vista
La qualit finale il risultato della progressiva
integrazione di pi punti di vista, al termine del ciclo di
sviluppo

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

96

Tipologie di qualit dei prodotti

A determinare la qualit complessiva di un


software concorrono tre diverse tipologie di
qualit.
1. Interna (intrinseca)
Esprime la misura in cui il software possiede una serie
di attributi, indipendentemente dallambiente di utilizzo
e dallutente
2. Esterna
Esprime le prestazioni e le funzionalit del software
3. Percepita (in uso)
Esprime lefficacia ed efficienza con cui il software
serve le esigenze dellutente, ed correlata allusabilit
del prodotto

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

97

La qualit interna
La qualit interna rappresenta le propriet
intrinseche del prodotto (misurabili direttamente sul
codice sorgente). Si realizza a partire da:
i requisiti dellutente, che rappresentano le specifiche di
qualit cos come date dallutente, fornendo il primo
input alla progettazione
le specifiche tecniche, che rappresentano la qualit
richiesta dallutente tradotta dallo sviluppatore
nellarchitettura del software, nella struttura del
programma, nella interfaccia verso lutente

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

98

La qualit esterna ed in uso


La qualit esterna, quella rappresentata dalle
prestazioni del prodotto e dalle sue funzionalit (il
prodotto visto come una scatola nera da testare)
La qualit in uso, quanto lutente percepisce nel
servirsi del prodotto nel suo effettivo contesto
dutilizzo, in particolare la capacit di tale
prodotto di supportarlo con efficacia ed efficienza
nel proprio lavoro, a fronte di una buona usabilit.
Questa tipologia di qualit quella a cui,
soprattutto, deve tendere lo sviluppatore
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

99

Caratteristiche e sottocaratteristiche per le


qualit interna ed esterna
external and
internal
quality

functionality

reliability

usability

efficiency

maintainability

portability

suitability
accuracy
interoperability
security

maturity
fault tolerance
recoverability

understandability
learnability
operability
attractiveness

time behaviour
resource
utilisation

analysability
changeability
stability
testability

adaptability
installability
co-existence
replaceability

usability
compliance

efficiency
compliance

maintainability
compliance

portability
compliance

functionality
compliance

reliability
compliance

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

100

Le caratteristiche 9126-1:
Funzionalit...

Funzionalit: capacit di fornire funzioni tali da


soddisfare, in determinate condizioni, requisiti funzionali
espliciti o impliciti (il software fa ci per fare il quale
stato sviluppato). Le sottocaratteristiche sono:
Adeguatezza: presenza di funzioni appropriate per
compiti specifici
Accuratezza: capacit di fornire risultati o effetti in
accordo con i requisiti
Interoperabilit: capacit di interagire con altri
sistemi.
Sicurezza: capacit di evitare accessi non autorizzati a
programmi e dati

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

101

...Funzionalit: metriche
Adeguatezza: presenza di funzioni appropriate per compiti
specifici
numero di funzionalit implementate/numero di funzionalit richieste

Accuratezza: capacit di fornire risultati od effetti in accordo


con i requisiti
numero di risultati corretti/numero di risultati
media e varianza dell'errore

Interoperabilit: capacit di interagire con altri sistemi


numero di funzioni di import/export
numero di dati salvati in formato standard/numero di dati memorizzati

Sicurezza: capacit di evitare accessi non autorizzati probabilit


di accesso non autorizzato (difficile la definizione operativa)
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

102

Le caratteristiche 9126-1:
Affidabilit...
Affidabilit: capacit di mantenere le prestazioni
stabilite nelle condizioni e nei tempi fissati (il
software reagisce bene a variazioni esterne); le
sottocaratteristiche sono:
Maturit (robustezza): capacit di evitare fermi della
applicazione a seguito di errori nel software
Tolleranza errori: capacit di mantenere determinati
livelli di prestazione in caso di errori
Recuperabilit: capacit di ripristinare livelli di
prestazione predeterminati e di recuperare i dati a
seguito di errori
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

103

...Affidabilit: metriche
Maturit (robustezza): capacit di evitare fermi della
applicazione a seguito di errori nel software
mtbf (mean time between failures)
tempo di funzionamento corretto/tempo di utilizzo

Tolleranza errori: capacit di mantenere determinati


livelli di prestazione in caso di errori
numero di funzioni ancora disponibili dopo un errore/numero di
funzioni totali
media e varianza di quanto indicato sopra

Recuperabilit: capacit di ripristinare livelli di


prestazione predeterminati e di recuperare i dati a seguito di
errori
tempo medio e varianza di ripristino del sistema dopo una
interruzione
% media e varianza di dati persi in seguito ad una interruzione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

104

Le caratteristiche 9126-1:Usabilit...
Usabilit: capacit del sw di essere compreso, appreso,
usato con soddisfazione dallutente in determinate
condizioni duso (il software gestisce bene linterazione con
gli utenti); le sottocaratteristiche sono:
Comprensibilit: impegno richiesto agli utenti per
capire il funzionamento del software e la sua
applicabilit,
Apprendibilit: impegno richiesto agli utenti per
imparare a usare il software.
Operabilit: disponibilit delle funzioni essenziali per
utilizzare correttamente il SW.
Attrattivit/Piacevolezza: capacit del software di
essere piacevole per lutente che ne fa uso
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

105

Usabilit: metriche
Comprensibilit: impegno richiesto agli utenti per capire il
funzionamento del software e la sua applicabilit
tempo medio di comprensione della finalit del software
scala di Likert + questionari

Apprendibilit: impegno richiesto agli utenti per imparare a


usare il software
tempo medio di comprensione del funzionamento del software
scala di Likert + questionari

Operabilit: disponibilit delle funzioni essenziali per


utilizzare correttamente il SW
numero di funzioni disponibili con un massimo di tre
passaggi/numero di funzioni

Attrattivit/Piacevolezza: capacit del software di essere


piacevole per lutente che ne fa uso
scala di Likert + questionari
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

106

Le caratteristiche 9126-: Efficienza...


Efficienza: rapporto fra prestazioni e quantit di
risorse utilizzate, in condizioni normali di
funzionamento (il software usa bene le risorse
disponibili); le sottocaratteristiche sono:
Comportamento rispetto al tempo: tempi di risposta e
di elaborazione richiesti per eseguire le funzioni
richieste in determinate condizioni
Uso di risorse: quantit e tipo di risorse usate per
eseguire le funzioni richieste in determinate condizioni

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

107

...Efficienza: metriche
Comportamento rispetto al tempo: tempi di
risposta e di elaborazione richiesti per eseguire le
funzioni richieste in determinate condizioni
tempo medio di risposta (varianza)
su singole funzioni (pi significative)
su tutte le funzioni (eventualmente pesate)

Uso di risorse: quantit e tipo di risorse usate per


eseguire le funzioni richieste in determinate
condizioni
occupazione media (e varianza) CPU
occupazione media (e varianza) memoria
numero medio (e varianza) di file aperti
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

108

Le caratteristiche 9126-1:
Manutenibilit...
Manutenibilit: capacit del software di essere
modificato con un impegno contenuto (il software
segue levoluzione dellorganizzazione); le
sottocaratteristiche sono:
Analizzabilit: impegno richiesto per diagnosticare
carenze o cause di fallimento, o per identificare parti da
modificare
Modificabilit: impegno richiesto per modificare,
rimuovere errori o sostituire componenti
Stabilit: capacit di ridurre il rischio di
comportamenti inaspettati a seguito di modifiche
Provabilit: impegno richiesto per validare le
modifiche apportate al software
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

109

...Manutenibilit: metriche
Analizzabilit: impegno richiesto per diagnosticare carenze o
cause di fallimento, o per identificare parti da modificare
numero di errori diagnosticati durante il test/impegno in giorni uomo

Modificabilit: impegno richiesto per modificare, rimuovere


errori o sostituire componenti
numero di errori risolti/impegno in giorni uomo

Stabilit: capacit di ridurre il rischio di comportamenti


inaspettati a seguito di modifiche
numero di errori scoperti da un test di regressione/FP

Provabilit: impegno richiesto per validare le modifiche


apportate al software
numero di modifiche validate apportate/impegno in giorni uomo

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

110

Le caratteristiche 9126-1: Portabilit...


Portabilit: facilit con cui il software pu essere
trasferito da un ambiente operativo ad un altro (il
software segue levoluzione tecnologica); attributi:
Adattabilit: capacit da parte del software di adattarsi
a nuovi ambienti operativi applicando le sole azioni
previste per questo motivo da parte del software stesso
Installabilit: impegno richiesto per installare il
software in un particolare ambiente
Coesistenza: capacit del software di coesistere con altri
software nel medesimo ambiente, condividendo risorse
Sostituibilit: capacit di essere utilizzato al posto di un
altro software per svolgere gli stessi compiti nello stesso
ambiente
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

111

...Portabilit: metriche
Adattabilit: capacit da parte del software di adattarsi a nuovi
ambienti operativi applicando le sole azioni previste per questo
motivo da parte del software stesso
numero di cambiamenti effettuati cambiando l'ambiente operativo
giorni uomo necessari

Installabilit: impegno richiesto per installare il software in un


particolare ambiente
tempo medio (e varianza) di installazione
numero problemi riscontrati/numero di installazioni

Coesistenza: capacit del software di coesistere con altri software


nel medesimo ambiente, condividendo risorse
occupazione media (e varianza) CPU /memoria /file aperti

Sostituibilit: capacit di essere utilizzato al posto di un altro


software per svolgere gli stessi compiti nello stesso ambiente
numero di cambiamenti effettuati/FP
giorni uomo necessari per i cambiamenti/FP
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

112

Ogni software ha proprie caratteristiche


Le caratteristiche di
qualit che un software
deve possedere sono in
genere diverse da
prodotto a prodotto.

Stock management
software
management
of the cash registers
stocking of articles
to orders to the
suppliers
to elaborate a
customers data

Embedded software
in a satellite
data acquisition
transmission of data
to the
real time constraints

SELECTED
SELECTED CHARACTERISTICS
CHARACTERISTICS

Un software gestionale, che


organizza le attivit di un
magazzino, ed un software di
gestione di un satellite,
hanno esigenze di qualit ben
diverse.

Functionnality

Reliability

Usability

Efficiency

Maintainability

Portability

Relevant Characteristic

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

113

Caratteristiche della qualit in uso


La qualit in uso rappresentata da quattro
caratteristiche
quality in
use

effectiveness

productivity

Ing. del SW: Prima parte Sez II

safety

satisfaction

Marco Cadoli, Universit La Sapienza, ott 2005

114

Caratteristiche della qualit in uso (2)


Efficacia, laccuratezza e la completezza con la
quale lutente raggiunge i suoi obiettivi
Produttivit, limpegno di risorse in relazione
allefficacia
Soddisfazione, la soddisfazione utente
nellutilizzare il prodotto
Sicurezza per lutente che fa uso del software

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

115

Caratteristiche della qualit in uso:


metriche
Efficacia, la completezza e laccuratezza con la quale lutente
raggiunge i suoi obiettivi
numero di obiettivi raggiunti/numero di obiettivi da
raggiungere
numero di obiettivi raggiunti in modo corretto/numero di
obiettivi raggiunti
Produttivit, limpegno di risorse in relazione allefficacia
numero di obiettivi raggiunti/numero ore uomo necessarie
Soddisfazione, la soddisfazione utente nellutilizzare il prodotto
scala di Likert
Sicurezza per lutente che fa uso del software
andamento degli "incidenti di sicurezza"/FP nei primi 2 anni
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

116

La ISO 9126: applicabilit


Le caratteristiche 9126 possono essere valutate in
ogni tipo di software, incluso il "firmware"
La valutazione possibile in ogni momento del
ciclo di vita, dalla acquisizione, allo sviluppo
(progettazione, codifica), alla manutenzione
Destinatari sono quindi tutti gli attori del ciclo di
vita del software, utenti, sviluppatori, gestori ed
addetti alla manutenzione, valutatori, ognuno
secondo le proprie esigenze

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

117

I soggetti interessati alla qualit


Utente: interessato alla QUALIT ESTERNA e a quella
IN USO, relativa alle modalit duso, alle prestazioni e agli
effetti derivanti dalluso del software
Sviluppatore: interessato alla QUALIT INTERNA,
relativa agli aspetti tecnici legati allo sviluppo e alla
manutenzione del software
Gestore del sistema: interessato agli aspetti di qualit
relativi ad installazione, configurazione ed esercizio del
sistema
Committente: interessato alla QUALIT GLOBALE,
considerata come media pesata dei diversi aspetti di qualit.
Il sistema di pesatura dipende dal tipo di sistema e dal tipo
di organizzazione
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

118

Caratteristiche e punti di vista


Rilevanza delle caratteristiche per i vari punti di vista
Vista
Caratteristica
Funzionalit
Affidabilit
Usabilit
Efficienza
Manutenibilit
Portabilit

Ing. del SW: Prima parte Sez II

Utente

Sviluppatore

Gestore

Committente

Alta

Bassa

Bassa

Media

Media

Media

Alta

Media

Alta

Bassa

Media

Media

Media

Media

Alta

Media

Bassa

Alta

Media

Media

Bassa

Alta

Alta

Media

Marco Cadoli, Universit La Sapienza, ott 2005

119

Relazioni nella 9126

effectiveness

Ing. del SW: Prima parte Sez II

Qualit
esterna

Qualit
interna

Dipende da

La qualit in uso
quella cui deve tendere
un prodotto software

Influenza

Influenza

Influenza

Qualit
dei processi

Risultati

Prodotto

Processo

Dipende da

Qualit
in uso
Dipende da

quality in
use

productivity

safety

Marco Cadoli, Universit La Sapienza, ott 2005

satisfaction

120

Sintetizzando
Required Product Quality (RPQ), che rappresenta le
specifiche di qualit cos come date dallutente, e fornisce
linput da utilizzare per iniziare la progettazione
Design Quality (DQ), la qualit RPQ tradotta
nellarchitettura del sw, nella struttura del programma,
nella interfaccia verso lutente, che riflette il confronto tra
la filosofia e la competenza del disegnatore del sistema
applicativo ed il punto di vista dellutente
Delivered Product Quality (DPQ), la qualit del prodotto
effettivamente consegnato

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

121

I tre tipi di misure (ISO 9126)


1) misure dirette - Rilevabili senza l'influenza di fattori esterni, come
l'ambiente (hw e sw) nel quale il software "gira" il comportamento e le
caratteristiche degli utenti etc...
Esempio di queste misure sono quelle rilevabili sul codice sorgente (analisi
statica e lettura del codice) e quelle rilevabili da una lettura dei documenti di
specifica

2) misure indirette - Derivate da misure di uno o pi attributi. Per esempio, le


misure relative ai tempi di risposta non dipendono solo dal comportamento
del software in s, ma anche da quello dellambiente operativo nel quale gira
il software (hw e sw di base)
Perci, i tempi di risposta mostrati da un prodotto software contengono anche i
tempi di risposta dei componenti hw e sw di base

3) indicatori Alcune misure possono essere stimate da altre misure (utile nel
caso di misure che non possono essere rilevate direttamente)
Ad es., il tempo di risposta del software non misurabile quando il sw stesso
ancora allo stato di non eseguibile. Cos, pu essere utilizzata la misura della
semplice lunghezza del codice stesso come indicatore di quello che sar il tempo
di risposta del prodotto nellambiente duso
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

122

Il Rating delle misure


I valori quantitativi rilevati attraverso le metriche non
corrispondono di per s ad una valutazione qualitativa.
necessario effettuare un rating, ovvero mappare
questi dati quantitativi su una scala qualitativa.
Oltre i requisiti
Livello atteso
Livello
misurato

Eccellente
Ottimo
Buono
Discreto

Intervallo di
accettabilit

Sufficiente
Soglia accettabilit
Non accettabile

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

123

Metriche interne, esterne o in uso


Le misure possono essere interne (misure dirette
sul codice sorgente, come analisi statiche, code
reading etc..), od esterne (misure del
comportamento del codice in esecuzione), od in
uso (relative alla capacit complessiva di
soddisfare le esigenze utente in un dato contesto e
per certi scopi).
In genere, la combinazione delle tre misure la
pi raccomandata per definire il profilo qualitativo
di un prodotto.
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

124

Scopo delle metriche


Scopo delle metriche interne:
rappresentare la qualit di un prodotto software, nei suoi stati di
lavorazione intermedi e finale (anche non eseguibili), rispetto alle
caratteristiche e sottocaratteristiche
validare laderenza rispetto ai requisiti di qualit interna
predire il livello di qualit esterno del prodotto
prevenire problemi nel prodotto in uso, scoprendo in anticipo i potenziali
difetti

Scopo delle metriche esterne:


rappresentare e validare la qualit di un prodotto software rispetto alle
caratteristiche e sottocaratteristiche, durante le fasi di test
validare laderenza del software rispetto ai requisiti di qualit esterna
espliciti ed impliciti dellutenza
predire il livello di qualit in uso del prodotto

Scopo delle metriche in uso:


verificare la capacit di un prodotto di soddisfare le esigenze dellutente in
un dato contesto, in relazione a specifici obiettivi
Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

125