La Qualità del Software: modelli e tecniche per la valutazione

La Qualità del Software:
modelli e tecniche per la
valutazione - parte I
Giuseppe Lami
I.S.T.I. – C.N.R., Pisa
[email protected]
Firenze, 25 Ottobre 2005
Scaletta
La qualità e il software
software quality e quality software
il processo software
la valutazione del processo software
l’approccio SPICE
L’approccio CMM
Firenze, 25 Ottobre 2005
1
Qualità: definizione
Quality: the totality of
characteristics of an
entity that bear on its
ability to satisfy
stated and implied
needs [ISO 8402]
Fitness for purpose
Conformance to
Specification
Degree of excellence
Firenze, 25 Ottobre 2005
Qualità del Software
E’ un concetto complesso e multiforme
con 5 diversi punti di vista
punto
punto
punto
punto
punto
di
di
di
di
di
vista
vista
vista
vista
vista
Trascendentale
dell’Utente
del Costruttore
del Prodotto
basato sul Valore
Firenze, 25 Ottobre 2005
2
Qualità del Software
Punto di vista
Trascendentale:
Punto di vista
dell’Utente:
non è definibile ma
ciascuno la può
riconoscere quando la
vede
non è decomponibile ma
è una proprietà
complessiva
non è possibile misurare
niente secondo questo
punto di vista
il grado con cui il SW
package soddisfa le
esigenze dell’utente
basato su che cosa si
deve fare
chiamata anche quality
in use (ISO9126)
misurata in base a
profili operazionali
Firenze, 25 Ottobre 2005
Qualità del Software
Punto di vista del
Costruttore:
Punto di vista del
Prodotto:
il grado con cui il SW package la qualità deriva da
soddisfa i requisiti formali
proprietà inerenti il
prodotto SW (affidabilità,
prevalente nel SW testing
portabilità, testabilità,..)
qualità definita in termini di
la qualità è misurata
numero di difetti e costi di
indirettamente attraverso il
correzione
calcolo di metriche che si
chiamata anche external
assume misurino le
quality (ISO9126)
proprietà sopra
moltissimi cattivi SW fanno
esattamente ciò che si prevede chiamata anche internal
quality (ISO9126)
che facciano
Firenze, 25 Ottobre 2005
3
Qualità del Software
Punto di vista basato sul
Valore:
qualità definita in termini di
compromesso fra benefici e
costi
punto di vista usato spesso da
chi acquisisce SW:
quanto fa per me e quanto
devo investirci?
Firenze, 25 Ottobre 2005
Qualità del software: definizione
E’ soprattutto il contesto di uso di un prodotto software che determina
le criticità che esso ha e le proprietà che ci si aspetta esso abbia
criticità
proprietà richieste
esempi di applicazioni
Critico per la sicurezza
nazionale
affidabilità e sicurezza
(security)
Sistemi militari di difesa
Critico per la vita umana
correttezza, sicurezza
(safety)
sistemi medicali, sistemi di controllo di
mezzi di trasporto
Critico per l’ambiente sociale
affidabilità, sicurezza
(security)
sistemi bancari, sistemi di controllo e
gestione delle linee telefoniche
Critico per l’azienda
efficacia, efficienza,
manutenibilità
sistemi di produzione, database dei clienti
critico per la salute dell’utente
usabilità, attrattività
sistemi interattivi, giochi elettronici
Qualità = a1Q1 + a2Q2+ … anQn
Qi = obiettiva misura della qualità della proprietà i
ai = peso relativo al contesto
Firenze, 25 Ottobre 2005
4
Qualità del Software
Qualità del prodotto
software
Qualità del processo
software
QUALITY
SOFTWARE
SOFTWARE
QUALITY
Firenze, 25 Ottobre 2005
Qualità del Software
Valutazione del
prodotto SW:
PRO:
ciò che si
compra/vende è il
prodotto
CONTRO
ex-post
Valutazione del
Processo SW
PRO:
ex-ante
non riferibile ad un
singolo prodotto
CONTRO
quale garanzia sul
prodotto se il
processo è buono?
Firenze, 25 Ottobre 2005
5
Software Quality
A livello più alto software quality è un “body
of knowledge” che descrive:
Che cosa deve essere fatto, e
Come deve essere fatto.
Il campo del software quality incorpora una
specifica e una implementazione di un
processo per realizzare quality software
(product).
Firenze, 25 Ottobre 2005
Software Quality: idee chiave
Processo
è generalmente accettato che il processo impiegato
nello sviluppo di un prodotto è determinante
(quanto?) per la qualità del prodotto
Principio Costruttivo
la qualità deve essere construita nel prodotto
dall’inizio. Non può essere inserita dopo
Le Persone
innanzi tutto sono le persone che determinano
l’ottenimento di un quality product
Firenze, 25 Ottobre 2005
6
Il Processo Software
software process:
the process or set of processes used by an
organization or project to plan, manage,
execute, monitor, control and improve its
software related activities [ISO 15504]
process
a set of interrelated activities, which transform
inputs into outputs [ISO 12207]
Firenze, 25 Ottobre 2005
Software Quality Management
Quality SW
SQM
SW Quality
Goal 1: Le attività di gestione
della qualità del software del
progetto sono pianificate.
Goal 2: Obiettivi misurabili per la
qualità del prodotto software
sono definiti insieme alle loro
priorità.
Goal 3: I progressi effettivi verso
l’ottenimento degli obiettivi di
qualità per i prodotti software
sono quantificati e gestiti.
Firenze, 25 Ottobre 2005
7
Software Quality Management
Quality Assurance:
Attività volte a
individuare,
documentare,
analizzare e
correggere difetti di
processo e a gestire
le modifiche al
processo stesso
Quality Control
Attività volte a
individuare,
documentare,
analizzare e
correggere difetti di
prodotto e a gestire
le modifiche al
prodotto stesso
Firenze, 25 Ottobre 2005
Software Quality System
Definizione:
“The organizational structure,
responsibilities, procedures,
processes and resources for
implementing software quality
SQM
SQS
Quality SW
SW Quality
management” [ISO 9001]
Firenze, 25 Ottobre 2005
8
Software Quality:Obiettivi
Gli obiettivi del software quality
management e del software quality
system sono:
costruire la qualità dall’inizio
mantenere la qualità del software
attraverso il Software Development
Lifecycle
Firenze, 25 Ottobre 2005
I nemici della Qualità del
Software
Fede nelle nuove tecnologie, metodi etc. visti come una
panacea (the Quick Fix)
La qualità è proporzionale allo sforzo fatto
perottenere la qualità
Carenza di impegno verso la qualità a tutti i liveli
dell’organizzazione
sistemi qualità e standard prodotti e ignorati
cultura
approccio alla produzione guidato della deadline
Incapacità di identificare e gestire i rischi per la qualità
Firenze, 25 Ottobre 2005
9
…. ma la situazione è davvero
così tragica?
Some facts and statistics:
US companies and government agencies spent
$81 billion for cancelled software projects in 1995.
31.1% projects - cancelled before completed
52.7% projects - cost 189% of original estimates
9.0% projects - in on time within budget
On average, over 50% of effort of producing
software goes into testing.
Over 50% of the costs associated with software
are incurred after delivery
Software failure can be extremely costly (eg.
Ariane 5) and even life threatening
Firenze, 25 Ottobre 2005
Perchè valutare il Processo
Software?
Negli ultimi anni si è consolidata l’idea che
concentrarsi sul processo di sviluppo software
sia il modo migliore per migliorare la qualità
del prodotto finale
Le tecnologie e la capacità dei singoli sono
distribuite in modo omogeneo: ciò che fa la
differenza è COME si costruisce il software
Firenze, 25 Ottobre 2005
10
L’approccio SPICE alla
valutazione del processo SW
Il processo di sviluppo SW visto come composto
da diversi processi
Ogni processo è valutato in termini di capability
attraverso attributi ai quali viene assegnato un
punteggio
process capability: the ability of a process to achieve
a required goal (ISO/IEC 155904-9)
Il punteggio di ciascun attributo è stabilito
andando ad osservare e valutare le pratiche
Le pratiche vengono valutate sulla base dei
documenti di lavoro (WP)
Firenze, 25 Ottobre 2005
Origini del ISO/IEC 15504
STD
(Scottish Development
Agency)
CMM
(SEI)
TRILLIUM
(Bell/BNR/NT)
SQPA
(HP)
SAM
(BT)
ISO 9001
ISO 12207
(ISO)
HealthCheck
(BT)
BootStrap
(Bootstrap Institute)
Firenze, 25 Ottobre 2005
11
Campo di Applicazione
ISO/IEC 15504 fornisce un approccio strutturato per
l ’assessment di processi software per le seguenti
finalità:
da o per conto di un’organizzazione con lo scopo di
comprendere lo stato dei propri processi per migliorarli;
da o per conto di un’organizzazione con lo scopo di
determinare quanto i propri processi sono adatti per
particolari requisiti o classi di requisiti;
da o per conto di un’organizzazione con lo scopo di
determinare quanto i processi di un ’altra organizzazione
sono adatti per un particolare contratto o classi di contratti.
Firenze, 25 Ottobre 2005
Software Process
Assessment
Process
Is
examined
by
Identifies
changes to
Identifies
capability
and risks of
Process
Assessment
leads
to
Process
Improvement
leads
to
motivates
Capability
Determination
Firenze, 25 Ottobre 2005
12
Finalità del modello di
riferimento
“...to provide a common basis for
different models and methods for
software process assessment, ensuring
that results of assessments can be
reported in a common context…”
Firenze, 25 Ottobre 2005
Architettura del modello di
riferimento
Capability
Il modello di
riferimento è bidimensionale
Process dimension
(strettamente legato a
ISO/IEC 12207)
Contiene processi in
gruppi
Capability dimension
Permette di misurare
indipendentemente la
capability di ogni
processo
Firenze, 25 Ottobre 2005
Processes
13
P r i m a r y l i fe c y c l e p r o c e sse s
A c q u is it io n
C U S .2
S u p p ly
S U P. 1
D o c u m e n t a t io n
S U P. 2
C o n f ig u r a t io n m a n a g e m e n t
S U P. 3
Q u a lit y a s s u r a n c e
S U P. 4
V e r if ic a t io n
S U P. 5
V a lid a t io n
S U P. 6
J o in t r e v ie w
S U P. 7
A u d it
S U P. 8
P r o b le m r e s o lu t io n
A c q u is it io n p r e p a r a t io n
S u p p lie r s e le c t i o n
S u p p lie r m o n it o r in g
C U S .4
O p e r a t io n
C u s tom er ac c e ptan c e
O p e ra t io n a l u s e
C u s to m e r s u p p o rt
C U S .3
R e q u ir e m e n t s e lic it a t io n
EN G .1
D e v e lo p m e n t
S y s t e m r e q u ir e m e n t s
a n a l y s is a n d d e s ig n
S o f t wa r e c o n s t r u c t io n
S o f t wa r e r e q u ir e m e n t s
a n a l y s is
S o f t wa r e t e s t in g
S o f t wa r e in t e g r a t io n
S y s t e m in t e g r a t io n a n d
t e s t in g
S o f t wa r e d e s ig n
ENG .2
S y s t e m a n d s o f t w a r e m a in t e n a n c e
O r g a n i z a t i o n a l l i fe c y c l e p r o c e ss e s
M A N .1
Management
M A N .2
P r o je c t m a n a g e m e n t
M A N .3
Q u a lit y m a n a g e m e n t
M A N .4
R is k m a n a g e m e n t
O R G .1
O R G .2
O r g a n iz a t io n a l a lig n m e n t
Im p r o v e m e n t
P r o c e s s e s t a b l is h m e n t
P roc es s as s es s m e nt
P r o c e s s im p ro v e m e n t
O R G .3
Hum an res ourc e m an age men t
O R G .4
In f r a s t r u c t u r e
O R G .5
Mea s ureme nt
O R G .6
Re u s e
ISO/IEC 15504
Process Dimension
(conforme a ISO 12207)
C U S .1
S u p p o r t i n g l i fe c y c l e p r o c e ss e s
Firenze, 25 Ottobre 2005
Process capability
Process of High Capability
Process of Low Capability
Planned
outcome
Probability
Planned
outcome
Probability
Process capability:
Il range di risultati
attesi che possono
essere ottenuti
seguendo un processo
Outcome
Outcome
Firenze, 25 Ottobre 2005
14
Misurare la process
capability (1)
La process capability misurata per mezzo
dei process attributes.
Gli Attributes misurano un particolare
aspetto della process capability.
Firenze, 25 Ottobre 2005
Measuring process
capability (2)
The process attributes are:
Process improvement
Process change
Process measurement
Process control
Process resource
Process definition
Work product
management
Performance management
Process performance
Increasing
capability
Firenze, 25 Ottobre 2005
15
Attribute rating
Each attribute is rated is against the
following rating scale.
There is little
or no
evidence of
achievement
of the
defined
attribute
Sound systematic
approach to and
achievement of the
defined attribute.
Some aspects of
achievement may
be unpredictable.
Not
Partially
0
15 16
Complete and
systematic
approach to and
full achievement
of the defined
attribute. No
significant
weaknesses exist.
Sound systematic
approach to and
significant
achievement of the
defined attribute.
Performance of the
process may vary in
some areas.
Largely
50 51
Fully
85 86
100
Firenze, 25 Ottobre 2005
Process profile
La capability di ogni processo è caratterizzata
dal rating di nove attributi chiamato process
profile:
Continuous change
Process improvement
Not achieved
Not achieved
10%
0%
Process measurement
Process control
Partially achieved
Partially achieved
20%
30%
Process definition
Process resource
Largely achieved
Fully achieved
60%
90%
Performance management
Work product management
Fully achieved
Largely achieved
90%
80%
Process performance
Fully achieved
100%
Firenze, 25 Ottobre 2005
16
Capability levels
Continuous
improvement
Process change
Optimising
Predictable
Established
Managed
Process control
Process measurement
Process definition
Process resource
Performance management
Work product management
Performed
Process performance
Incomplete
Firenze, 25 Ottobre 2005
Capability dimension capability levels
Si può calcolare il capability level del processo
dal process profile:
4
1
F/L
F
F
F
5
2
F/L
F/L
F
F/L
F
F
F
F
3
F/L
F
F
Firenze, 25 Ottobre 2005
17
PA .4.2
P
N N N N
PA .4.1
P
N L
N N
PA .3.2
L
P
L
P
P
PA .3.1
L
P
L
L
P
PA .2.2
F
L
F
L
L
PA .2.1
F
L
F
L
P
PA .1.1
F
F
F
F
L
ENG.1.2
ENG.1.3
ENG.1.4
ENG.1.5
Un tipico output di un
assessment potrebbe
assomigliare a
questo:
Un rating per ogni
attributo per i
processi
Un rating del
capability level per
ogni processo.
ENG.1.1
Typical assessment
output
Firenze, 25 Ottobre 2005
Come si conduce un
Assessment SPICE
The ESCAPE
(Electronics Software
CAPability Evaluation)
Project
Firenze, 25 Ottobre 2005
18
Assessment Preparation
Planning the Assessment
OnOn-site visit
Time/Cost constraints
Technical constraints
Assessment risk identification
Defining the Assessment Purpose
Capability Determination
[Process Improvement]
Defining the Assessment Scope
Requirements elicitation process (CUS.3)
System requirements analysis and design process
(ENG.1.1)
Software design process (ENG.1.3)
System integration and testing process (ENG.1.7)
Project management process (MAN.2)
Firenze, 25 Ottobre 2005
Project implementation
pre-assessment activities
Introductory meeting
To introduce the SPICE
(ISO15504) approach
To review the assessment
purpose, scope and constraints
To introduce the assessment
activities and the provisional
assessment plan
PrePre-assessment
questionnaire
To gather preliminary
information on the projects to be
used as process instances
• sw life cycle
• sw life cycle
• sw
• sw
requirements
requirements
• test reports
• test reports
• test plan
• test plan
• quality
• quality
requirements
requirements
Firenze, 25 Ottobre 2005
19
Project implementation
on-site activities
Briefing
Assessment purpose,
scope, constraints and
model
Confidentiality policy
Assessment schedule
Data Acquisition &
Validation
Presentations
Document analysis Checklist-based
Interviews
Process rating
(provisional))
Debriefing
}
Firenze, 25 Ottobre 2005
The Rating Dilemma
Different rating methods can be
applied
ranging from the mere
processing of measured
indicators up to the unaided
assessor’s judgement
Need to establish the
requirements to be satisfied for
a rating method to be valid
Trade-off: assessor’s judgement
driven by checklists
Firenze, 25 Ottobre 2005
20
Project implementation
post-assessment activities
Process rating (final)
For each process assessed,
assign a rating to each process
attribute
Record the set of process
attribute ratings as the process
profile and calculate the
capability level rating
Reporting the results
Prepare the assessment report
Present the assessment results
Finalize and distribute the
assessment report
Firenze, 25 Ottobre 2005
Project results
CUS3: Requirements Elicitation Process
ENG1.1: System Requirement Analysis and
Design Process
4
capability level
capability level
4
3
2
1
0
3
2
1
0
P1
P2
P3
P4
P5
P6
P7
P8
P9
P10
P1
P2
P3
P4
Project
P7
P8
P9
P10
ENG1.7: System Integration and Testing Process
ENG1.3: Software Design Process
4
capability level
3
2
1
3
2
1
0
0
P1
P2
P3
P4
P5
P6
P7
P8
P9
P1
P10
P2
P3
P4
P5
P6
P7
P8
P9
P10
Project
Project
Synthetic Results
MAN2: Project Management Process
4
4
capability level
capability level
P6
Project
4
capability level
P5
3
2
1
0
3
mean value
2
median
1
0
P1
P2
P3
P4
P5
P6
Project
P7
P8
P9
P10
CUS.3
ENG.1.1 ENG.1.3 ENG.1.7
MAN.2
process
21
Capability Maturity Model - CMM
The CMM for SW (CMM) is a framework that
describes the key elements of an effective SW
process. The CMM describes an evolutionary
improvement path from an ad-hoc , immature
process to a mature, disciplined process.
The CMM covers practices for planning, engineering,
and managing SW development and maintenance.
When followed, these key practices improve the
ability of organizations to meet goals for cost,
schedule, functionality, and product quality.
The CMM can be also used by an organization to plan
improvements to its SW process
Firenze, 25 Ottobre 2005
CMM
Continuously
improving
Predictable
Standard,
consistent
Disciplined
Optimising
(5)
Managed
(4)
Defined
(3)
Repeatable
(2)
Initial
(1)
Firenze, 25 Ottobre 2005
22
CMM
Lev. 1 - Initial:
ad hoc
chaotic
absence of defined processes
success depending on individual effort
Lev. 2 - Repeatable:
established process
cost, time, schedules, and functionalities
management
repeatability on projects with similar application
Firenze, 25 Ottobre 2005
CMM
Lev. 3 - Defined:
processes are documented, stadardizated and
integrated
all the projects use an approved version of the
development and maintenance process
Lev. 4 - Managed:
collection of measurement of the product quality
collection of measurement of the process quality
product and process control and management by
means of quantitative techniques
Firenze, 25 Ottobre 2005
23
CMM
Lev. 5 - Optimizing:
continuous improvement of the processes based
on quantitative feedback and on new ideas and
technologies inserted within the organization
Firenze, 25 Ottobre 2005
CMM - the Framework
Ciascun livello di capability è composto da Key
Process Areas (KPA), cioè gruppi di attività
che, se eseguite, permettono di soddisfare
l’obiettivo relativo al livello di maturità.
Ogni KPA è strutturata in Common Features
(CF), cioè attributi che indicano se
l’implementazione e l’istituzionalizzazione delle
attività è efficace, ripetibile e durevole
Ogni CF raggruppa le Key Practices, che
rappresentano “che cosa” deve essere fatto.
Firenze, 25 Ottobre 2005
24
CMM
Firenze, 25 Ottobre 2005
CMM
KPAs by
Maturity
Level
Firenze, 25 Ottobre 2005
25
CMM - Common Features
Commitment to Perform (CTP):
descrive le azioni da intraprendere per
assicurare stabilità nel tempo ai processi e riguarda in genere politiche
organizzative e la sponsorship del management
Ability to Perform (ATP): descrive i presupposti di progetto ed
organizzativi necessari per implementare in maniera corretta un processo sw e
coinvolge in genere le strutture organizzative, le risorse e il training
Activities Performed (AP): descrive i ruoli e le procedure necessarie per
implementare una KPA e riguarda normalmente piani e procedure, l’esecuzione e
monitoraggio del lavoro e la presa di azioni correttive laddove necessario
Measurement and Analysis (MA):descrive la necessità di misurare il
processo ed analizzare i risultati, e proporre in genere esempi di misurazioni
pertinenti
Verifying Implementation (VI): descrive i passi necessari ad assicurare
un’esecuzione delle attività in linea con il processo, attraverso reviews, audit del
mangement e una SQA (sw quality assurance)
Firenze, 25 Ottobre 2005
CMM
Common
Features
Number of
related Key
Practices
KPA
LEVEL 2
RM
SPP
SPPO
SSM
SQA
SCM
LEVEL 3
OPF
OPD
TP
ISM
SPE
IC
PR
LEVEL 4
QPM
SQM
LEVEL 5
DP
TCM
PCM
CTP
ATP
AP
MA
VI
1
2
2
2
1
1
4
4
5
3
4
5
3
15
13
13
8
10
1
1
1
1
1
1
3
3
3
3
3
4
3
1
1
1
1
1
1
4
2
4
3
4
5
3
7
6
6
11
10
7
3
1
1
2
1
2
1
1
1
1
3
3
3
3
1
2
1
3
5
7
5
1
1
3
3
2
3
2
4
5
4
8
8
10
1
1
1
3
2
2
Firenze, 25 Ottobre 2005
26
CMM
Firenze, 25 Ottobre 2005
SPICE vs. CMM
Different scope: acquisition, provision and support
activities are in the SPICE scope. SPICE has broader
coverage.
Different granularity in the
evaluation of the Maturity
Level (F, L, P, N). SPICE
is a continuous model,
CMM a staged one.
Targeting process capability rather than organizational
capability.
Ready-to-elaborate / Ready-to-use
Firenze, 25 Ottobre 2005
27
ISO 9000 - 3
ISO 9001:
Quality Systems -
ISO 9000-3
Model for Quality
Assurance in Design
Development,
Production,
Installation and
Servicing
Guidelines for the
application of
ISO9001 to the
development,
supply, installation
and maintenance
of software
Firenze, 25 Ottobre 2005
SPICE vs. ISO 9000
= Confidence in a supplier's quality management
=+ Providing acquirers with a framework for
assessing whether potential suppliers have the
capability to meet their needs.
+ Ability to evaluate process capability on a
continuous scale in a comparable and repeatable
way, rather than using the pass/fail characteristic
of quality audits based on ISO 9001
+ Adjust the scope of assessment to cover specific
processes of interest, rather than all of the
processes used by an organizational unit.
Firenze, 25 Ottobre 2005
28