PrimaParte 2

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
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
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
ISO/IEC 9126 (2001)
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)
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
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
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

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...

... 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)
10

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...
11

... 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)
12

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)
13

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)
14
Capability Maturity Model: riassunto

Level
Characteristic
Optimizing
Managed
Continuous
Improvement
Predictable
Defined
Repeatable
Initial
Standard and
Consistent
Intuitive
Ad hoc and
Chaotic
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
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/
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)
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
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
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
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.
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.
23
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.
24

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
25
Processo primario 3: le 13 attivit

Processi primari del ciclo di vita
3 Sviluppo
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
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).
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).
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.
29
II.2. Standard ISO 9000 (2000)
Motivazioni
Obiettivi
Confronto con CMM
Vision 2000
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.
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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.
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
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.
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
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
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
55
Flusso della documentazione

Contesto
Lavorativo
Risorse
ISO 9000
MdQ
ISO 10005
PdQ
ISO 10013
Cliente
Obiettivi
progetto
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
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
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,
...
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
Alto
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)
61
ISO e altre organizzazioni

Settori
vari
Settore
elettrotecnico
A livello internazionale
ISO
IEC
A livello europeo
CEN
CENELEC
A livello nazionale
UNI
CEI
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.
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
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!
65
i > 0
invece di
i >= 0

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
66
Si noti che i malfunzionamenti del SW possono apparire dopo anni di

funzionamento corretto (caso famoso: problema dellanno 2000)
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
68

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
69

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
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
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
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
$
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
...
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
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
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,
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
78
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
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
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)
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
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)
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 %
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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)
102
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
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
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
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
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
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
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
108
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
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
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
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
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
113
Caratteristiche della qualit in uso

La qualit in uso rappresentata da quattro
caratteristiche
quality in
use
effectiveness
productivity
safety
satisfaction
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
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
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
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
118
Caratteristiche e punti di vista

Rilevanza delle caratteristiche per i vari punti di vista
Vista
Caratteristica
Funzionalit
Affidabilit
Usabilit
Efficienza
Manutenibilit
Portabilit
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
119
Relazioni nella 9126
effectiveness
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
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
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
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
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.
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
125

PrimaParte 2

Caricato da

Informazioni sul documento

Descrizione:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

PrimaParte 2

Titolo originale:

Caricato da

Descrizione:

Copyright:

Formati disponibili

Ingegneria del Software

(Ing.Informatica Nuovo Ord.)

Il processo di produzione del SW

Marco Cadoli, Universit La Sapienza, ott 2005

Introduzione, ciclo di vita del SW

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

II. Qualit & standard

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

ISO/IEC 12207 (91)

ISO/IEC 9126 (91)

ISO 9001 - UNI-EN 29001 (88)

ISO/IEC 9126 (2001)

Marco Cadoli, Universit La Sapienza, ott 2005

II.1. Modelli di qualit: primi esempi

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (CMM)

Basato su cinque possibili valori, in grado di fornire al

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (2)

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (3)

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (4)

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (5)

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (6)

ORGANIZZATIVI (PF + PD)

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (7)

Aree di processo chiave:

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model (8)

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Maturity Model: riassunto

Ing. del SW: Prima parte Sez II

Marco Cadoli, Universit La Sapienza, ott 2005

CMM: punti da ricordare

LA METRICA DEL LIVELLO DI MATURIT MOLTO ISTRUTTIVA:

LA METRICA RICONOSCIUTA COME STANDARD INDUSTRIALE E

IL PROCESSO DI VALUTAZIONE (ASSESSMENT) PER DETERMINARE

NON PREVISTO UN PIANO IMPLEMENTATIVO PER OTTIMIZZARE

Problema: il SEI afferma che il 70% delle organizzazioni

Marco Cadoli, Universit La Sapienza, ott 2005

Capability Immaturity Model (CIMM)

Marco Cadoli, Universit La Sapienza, ott 2005

Altri aspetti del CMM

Miglioramento dei tempi di realizzazione

ampiamente documentato. Si veda ad es.:

Marco Cadoli, Universit La Sapienza, ott 2005

Altri aspetti del CMM (2)

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