1
Firenze, 15 Novembre 2004
La Qualità del Software:modelli e tecniche per la valutazione - parte I
Giuseppe LamiI.S.T.I. – C.N.R.Pisa
www.iei.pi.cnr.it/~glami/LIS
Firenze, 15 Novembre 2004
Scaletta
La qualità e il softwaresoftware quality e quality softwareil processo softwarela valutazione del processo softwarel’approccio SPICEL’approccio CMM
Firenze, 15 Novembre 2004
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 purposeFitness for purposeConformance to Conformance to SpecificationSpecificationDegree of excellenceDegree of excellence
2
Firenze, 15 Novembre 2004
Qualità del Software
E’ un concetto complesso e multiforme con 5 diversi punti di vista? punto di vista Trascendentale? punto di vista dell’Utente? punto di vista del Costruttore? punto di vista del Prodotto? punto di vista basato sul Valore
Firenze, 15 Novembre 2004
Qualità del SoftwarePunto di vista Trascendentale:? 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
Punto di vista dell’Utente:? 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, 15 Novembre 2004
Qualità del SoftwarePunto di vista del Costruttore:? il grado con cui il SW package
soddisfa i requisiti formali? prevalente nel SW testing
? qualità definita in termini di numero di difetti e costi di correzione
? chiamata anche external quality (ISO9126)
? moltissimi cattivi SW fanno esattamente ciò che si prevede che facciano
Punto di vista del Prodotto:? la qualità deriva da
proprietà inerenti il prodotto SW (affidabilità, portabilità, testabilità,..)
? la qualità è misurata indirettamente attraverso il calcolo di metriche che si assume misurino le proprietà sopra
? chiamata anche internal quality (ISO9126)
3
Firenze, 15 Novembre 2004
Qualità del SoftwarePunto 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, 15 Novembre 2004
Qualità del software: definizioneE’ 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
sistemi interattivi, giochi elettroniciusabilità, attrattivitàcritico per la salute dell’utente
sistemi di produzione, database dei clientiefficacia, efficienza, manutenibilità
Critico per l’azienda
sistemi bancari, sistemi di controllo e gestione delle linee telefoniche
affidabilità, sicurezza (security)
Critico per l’ambiente sociale
sistemi medicali, sistemi di controllo di mezzi di trasporto
correttezza, sicurezza (safety)
Critico per la vita umana
Sistemi militari di difesaaffidabilità e sicurezza (security)
Critico per la sicurezza nazionale
esempi di applicazioniproprietà richiestecriticità
Qualità = a1Q1 + a2Q2+ … anQnQi = obiettiva misura della qualità della proprietà iai = peso relativo al contesto
Firenze, 15 Novembre 2004
Qualità del SoftwareQualità del prodotto
softwareQualità del processo
software
QUALITY SOFTWARE
SOFTWARE QUALITY
4
Firenze, 15 Novembre 2004
Qualità del SoftwareValutazione del prodotto SW:PRO:? ciò che si
compra/vende è il prodotto
CONTRO? ex-post
Valutazione del Processo SWPRO:? ex-ante? non riferibile ad un
singolo prodotto
CONTRO? quale garanzia sul
prodotto se il processo è buono?
Firenze, 15 Novembre 2004
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, 15 Novembre 2004
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
5
Firenze, 15 Novembre 2004
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]processa set of interrelated activities, which transform inputs into outputs [ISO 12207]
Firenze, 15 Novembre 2004
Software Quality ManagementGoal 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.
SQM
SW
Qua
lity
Qua
lity
SW
Firenze, 15 Novembre 2004
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
6
Firenze, 15 Novembre 2004
Software Quality System
Definizione: “The organizational structure,responsibilities, procedures,processes and resources for implementing software qualitymanagement” [ISO 9001]
SW
Qua
lity
Qua
lity
SW
SQM
SQS
Firenze, 15 Novembre 2004
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, 15 Novembre 2004
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à
7
Firenze, 15 Novembre 2004
…. 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, 15 Novembre 2004
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 finaleLe tecnologie e la capacità dei singoli sono distribuite in modo omogeneo: ciò che fa la differenza è COME si costruisce il software
Firenze, 15 Novembre 2004
L’approccio SPICE alla valutazione del processo SWIl processo di sviluppo SW visto come composto da diversi processiOgni 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 praticheLe pratiche vengono valutate sulla base dei documenti di lavoro (WP)
8
Firenze, 15 Novembre 2004
BootStrap(Bootstrap Institute)
SQPA(HP)
ISO 9001ISO 12207
(ISO)
TRILLIUM(Bell/BNR/NT)
CMM(SEI)
STD(Scottish Development
Agency)
SAM(BT)
HealthCheck(BT)
Origini del ISO/IEC 15504
Firenze, 15 Novembre 2004
Campo di ApplicazioneISO/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 adattiper un particolare contratto o classi di contratti.
Firenze, 15 Novembre 2004
Software ProcessAssessment
Process
ProcessAssessment
CapabilityDetermination
ProcessImprovement
leadsto
Identifieschanges to
leadsto
Isexamined
by
motivates
Identifies
and risks ofcapability
9
Firenze, 15 Novembre 2004
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, 15 Novembre 2004
Architettura del modello di riferimentoIl modello di riferimento è bi-dimensionale? Process dimension
(strettamente legato a ISO/IEC 12207)
?Contiene processi in gruppi
? Capability dimension
?Permette di misurare indipendentemente la capability di ogni processo
Processes
Capability
Firenze, 15 Novembre 2004
E N G .2 S y st e m a n d s o f tw a r e m ain te n a nc e
P ri m a ry l i f e c y c le p ro c e s s e s S up p or ti n g l i f e c y c l e p ro c e ss e s
S U P. 1 D oc u me n ta tio n
S U P. 2 C on f ig ur a tio n m an a g em e nt
S U P. 3 Q u alit y a ss u r an c e
S U P. 4 V e r if ic a tio n
S U P. 5 V a lida tio n
S U P. 6 J oin t r ev ie w
S U P. 7 A u dit
S U P. 8 P r o ble m r e so lu tio n
O rg a ni z a t i on a l l i f e c y c le p ro c e s s e s OR G .1 Or g a niz a tio n al alig n me n t
OR G .4 Inf r a s tr u ct ur e
OR G . 2 Im pr o v em e ntPr o c e s s e s ta b l i s h m e n tPr o c e s s a s s e s s m e n tPr o c e s s im p r o v e m e n t
OR G .3 H u ma n r e s ou r c e ma n a ge m en t
Sy s te m re q u i re m e n tsa n a ly s i s a n d d e s ig nSo ftw a re re q u i r e m e n tsa n a ly s i sSo ftw a re d e s ig n
E N G. 1 D ev e lop m en tS o ft wa r e c o n s t ru c ti o n
S o ft wa r e i n t e g r a ti o nS o ft wa r e t e s t in g
S y s t e m in te g ra ti o n a n dte s ti n g
A c q u is i ti o n p r e p a ra t i o nS u p p l i e r s e le c ti o nS u p p l i e r m o n i to r i n g
C U S . 1 A c qu is itio n C U S .2 S up p ly
C U S . 3R e q uir e me n ts e lic ita tio n
C U S .4 Op e r a tio n
O p e ra ti o n a l u s e
C u s to m e r s u p p o rt
MA N .3 Q ua lity m a n ag e me n t
MA N .4 R is k m a n ag e m en t
C u s to m e r a c c e p ta n c e
MA N .1 M an a ge m e nt
MA N .2 P ro je c t m a n ag e me n t
O R G .5 M e a su r e me n t
O R G .6 R eu s e
ISO
/IEC
15
50
4P
rocess D
imen
sion
(co
nfo
rme a IS
O 1
22
07
)
10
Firenze, 15 Novembre 2004
Process capabilityProcess capability:? Il range di risultati
attesi che possono essere ottenuti seguendo un processo
Process of High Capability
Pro
babi
lity
Outcome
Planned outcome
Process of Low Capability
Pro
babi
lity
Outcome
Planned outcome
Firenze, 15 Novembre 2004
Misurare la process capability (1)
La process capability misurata per mezzo dei process attributes.Gli Attributes misurano un particolare aspetto della process capability.
Firenze, 15 Novembre 2004
Measuring process capability (2)
? Process improvement
? Process change
? Process measurement
? Process control
? Process resource? Process definition? Work product
management? Performance management
? Process performance
Increasing
capability
The process attributes are:
11
Firenze, 15 Novembre 2004
Not Partially Largely Fully
0 15 50 85 10016 51 86
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.
Sound systematic approach to and significant achievement of the defined attribute. Performance of the process may vary in some areas.
Complete and systematic approach to and full achievement of the defined attribute. No significant weaknesses exist.
Attribute rating
Each attribute is rated is against the following rating scale.
Firenze, 15 Novembre 2004
La capability di ogni processo è caratterizzata dal rating di nove attributi chiamato process profile:
Process profile
Continuous changeProcess improvement
Process measurementProcess control
Process definitionProcess resource
Performance managementWork product management
Process performance
Not achievedNot achieved
Partially achievedPartially achieved
Largely achievedFully achieved
Fully achievedLargely achieved
Fully achieved 100%
80%90%
90%60%
30%20%
0%10%
Firenze, 15 Novembre 2004
Capability levels
Process performance
Performance managementWork product management
Process definitionProcess resource
Process controlProcess measurement
Optimising
Predictable
Established
Managed
Performed
Incomplete
Continuous improvementProcess change
12
Firenze, 15 Novembre 2004
Capability dimension -capability levelsSi può calcolare il capability level del processo dal process profile:
F/L FF/L
FFF/L
FFFF/L
FFFFF/L
1 2 3
4 5
Firenze, 15 Novembre 2004
Typical assessment output
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. E
NG
.1.1
EN
G.1
.2
EN
G.1
.3
EN
G.1
.4
EN
G.1
.5
PA .2.2
PA .2.1
PA .1.1
PA .3.1
PA .3.2
PA .4.1
PA .4.2
FF
F
F
F FFF
L
LL
L
L
L
L
P
L
LLL
L PPP
PPP
P
NNN
NNNN
Firenze, 15 Novembre 2004
Come si conduce un Assessment SPICE
The ESCAPE The ESCAPE (Electronics Software (Electronics Software CAPability Evaluation) CAPability Evaluation) ProjectProject
13
Firenze, 15 Novembre 2004
Assessment PreparationAssessment PreparationPlanning the Assessment? On-site visit? Time/Cost constraints? Technical constraints? Assessment risk identificationDefining 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, 15 Novembre 2004
Project implementationProject implementationprepre--assessment activitiesassessment 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
Pre-assessment questionnaire?To gather preliminary
information on the projects to be used as process instances
• sw lifecycle• sw requirements• test reports• test plan• quality requirements
• sw lifecycle• sw requirements• test reports• test plan• quality requirements
Firenze, 15 Novembre 2004
Project implementationProject implementationonon--site activitiessite activities
Briefing? Assessment purpose,
scope, constraints and model
? Confidentiality policy? Assessment scheduleData Acquisition & Validation? Presentations? Document analysis? InterviewsProcess rating (provisional)Debriefing
} Checklist-based
14
Firenze, 15 Novembre 2004
The Rating DilemmaThe Rating Dilemma
Different rating methods can be appliedranging from the mere processing of measured indicators up to the unaided assessor’s judgementNeed to establish the requirements to be satisfied for a rating method to be validTrade-off: assessor’s judgement driven by checklists
Firenze, 15 Novembre 2004
Project implementationProject implementationpostpost--assessment activitiesassessment 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
Project resultsProject resultsCUS3: Requirements Elicitation Process
0
1
2
3
4
P1 P 2 P3 P4 P5 P 6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.1: System Requirement Analysis and Design Process
0
1
2
3
4
P1 P 2 P3 P4 P 5 P 6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.3: Software Design Process
0
1
2
3
4
P1 P2 P3 P4 P 5 P6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.7: System Integration and Testing Process
0
1
2
3
4
P 1 P2 P 3 P4 P 5 P6 P7 P8 P9 P10
Project
cap
abil
ity
leve
l
MAN2: Project Management Process
0
1
2
3
4
P1 P2 P3 P 4 P5 P6 P7 P8 P 9 P10
Project
ca
pa
bil
ity
le
ve
l
Synthetic Results
0
1
2
3
4
CUS.3 ENG.1.1 ENG.1.3 ENG.1.7 MAN.2
process
cap
abil
ity
leve
l
mean value
median
CUS3: Requirements Elicitation Process
0
1
2
3
4
P1 P 2 P3 P4 P5 P 6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.1: System Requirement Analysis and Design Process
0
1
2
3
4
P1 P 2 P3 P4 P 5 P 6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.3: Software Design Process
0
1
2
3
4
P1 P2 P3 P4 P 5 P6 P7 P8 P 9 P10
Project
cap
abil
ity
leve
l
ENG1.7: System Integration and Testing Process
0
1
2
3
4
P 1 P2 P 3 P4 P 5 P6 P7 P8 P9 P10
Project
cap
abil
ity
leve
l
MAN2: Project Management Process
0
1
2
3
4
P1 P2 P3 P 4 P5 P6 P7 P8 P 9 P10
Project
ca
pa
bil
ity
le
ve
l
Synthetic Results
0
1
2
3
4
CUS.3 ENG.1.1 ENG.1.3 ENG.1.7 MAN.2
process
cap
abil
ity
leve
l
mean value
median
15
Firenze, 15 Novembre 2004
Capability Maturity Model - CMMThe 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, 15 Novembre 2004
CMM
Initial(1)
Repeatable(2)
Defined(3)
Managed(4)
Optimising(5)
Disciplined
Standard,consistent
Predictable
Continuouslyimproving
Firenze, 15 Novembre 2004
CMMLev. 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
16
Firenze, 15 Novembre 2004
CMMLev. 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, 15 Novembre 2004
CMM
Lev. 5 - Optimizing:? continuous improvement of the processes based
on quantitative feedback and on new ideas and technologies inserted within the organization
Firenze, 15 Novembre 2004
CMM - the FrameworkCiascun 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 durevoleOgni CF raggruppa le Key Practices, che rappresentano “che cosa” deve essere fatto.
17
Firenze, 15 Novembre 2004
CMM
Firenze, 15 Novembre 2004
CMM
KPAs by Maturity Level
Firenze, 15 Novembre 2004
CMM - Common FeaturesCommitment 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 delmangement e una SQA (sw quality assurance)
18
Firenze, 15 Novembre 2004
CMM
KPA CTP ATP AP MA VILEVEL 2
RM 1 4 3 1 3SPP 2 4 15 1 3
SPPO 2 5 13 1 3SSM 2 3 13 1 3
SQA 1 4 8 1 3SCM 1 5 10 1 4
LEVEL 3OPF 3 4 7 1 1OPD 1 2 6 1 1TP 1 4 6 2 3
ISM 1 3 11 1 3SPE 1 4 10 2 3IC 1 5 7 1 3PR 1 3 3 1 1
LEVEL 4
QPM 2 3 7 1 3SQM 1 5 5 1 3
LEVEL 5DP 2 4 8 1 3
TCM 3 5 8 1 2PCM 2 4 10 1 2
Common Features
Number of related Key Practices
Firenze, 15 Novembre 2004
CMM
Firenze, 15 Novembre 2004
SPICE vs. CMM? Different scope: acquisition, provision and support
activities are in the SPICE scope. SPICE has broader coverage.
? Different granularity in theevaluation of the MaturityLevel (F, L, P, N). SPICEis a continuous model,
CMM a staged one.? Targeting process capability rather than organizational
capability.? Standard for Models / Standard for Improvement? Ready-t o-elaborate / Ready-to-use
19
Firenze, 15 Novembre 2004
ISO 9000 - 3
ISO 9000-3
Guidelines for theapplication ofISO9001 to thedevelopment,supply, installationand maintenance of software
ISO 9001:
Quality Systems -
Model for Quality
Assurance in Design
Development,
Production,
Installation and
Servicing
Firenze, 15 Novembre 2004
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.