Programvare og produktkvalitet
Frode Høgberg
CONNO 690 Systems & Software
DNV Consulting
Det Norske Veritas
§ +47 67 57 90 95
} Frode.Hogberg@dnv.com
Þ http://www.dnv.com/consulting/systemsandsoftware/
Disposisjon
•
•
•
•
Hvorfor er programvarekvalitet viktig?
Hvorfor er programvarekvalitet vanskelig?
Hva er produktkvalitet?
Hvordan kan man evaluere kvaliteten på et
produkt?
• Et eksempel på en evaluering
• Litteratur
1
Hva er DNVs interesse i programvare?
• DNVs mål er å sikre liv, eiendom og miljø
• Vår visjon er å være ledende på
risikostyringstjenester
• Sikker og effektiv operasjon av skip, anlegg,
systemer og tjenester er i økende grad avhengig
av pålitelig programvare
• DNVs fremtidige evne til å vurdere og håndtere
programkvalitet er viktig for å oppnå mål og
visjon
Systems & Software
•
Risk Management
–
–
–
•
Information Security
–
–
–
•
Security management system and product assessment
Information security risk analysis
Information security process improvement
Systems & Software Safety
–
–
–
–
–
–
•
Evaluation of Enterprise/Project Risk Management systems
Risk analysis
Implementation & improvement of Risk Management systems
Safety management process assessment and consulting
Software product assessment (RAMS incl.)
Supplier audit and assessment
Independent Verification & Validation
Safety Manager role
Software safety Product & Process consulting
Business Critical Systems
–
–
–
–
–
Software Process & Product assessment and improvement
Systems Risk & reliability analysis
Software Product Evaluation
Independent Verification & Validation
Supplier audit and assessment
2
Bilindustrien
• Programvare vil i løpet av 3 år
utgjøre ca. 70% av utviklingskostnadene av en bil (det er 40% i
dag)
• 60 % av programvarekostnadene er
knyttet til feilretting
• 1/3 av lanseringsproblemene er
knyttet til programvare
• En produsent måtte tilbakekalle
57.000 biler pga. et dataproblem
knyttet til frontlyktene.
Telekommunikasjon
• Sony måtte tilbakekalle 420.000 telefoner på
grunn av programvarefeil.
• SO503i er en I-mode-telefon som gir tilgang til
WWW via mobiltelefonnettet.
• Som et resultat av dette sank verdien av Sonys
aksjer med 2,5 % på børsen i Tokyo.
3
Sikkerhetskritisk programvare
• Programmeringsfeil i Therac-25, et system for
strålingsterapi: 3 drept
• Datafeil resulterte i feil diagnose for 12.000
pasienter
• Et fly fra Air New Zealand styrtet pga en
datafeil: 257 drept
• Kanadiske tog kolliderte på tross av “sikre”
datasystemer: 26 drept
Kompleksitet og konsekvenser øker
Software Content and
System Complexity
Safety and Business
Consequences of Software
Failures
Time
4
Essensiell kompleksitet
• [Brooks 1987] nevner fire
essensielle egenskaper ved
programvare som gjør
programvareutvikling vanskelig:
– Komplekst - ingen deler er like
– Kulturelt/konvensjonelt - følger
ingen naturlover, må forholde seg
til standarder
– “Lett” å endre - ihvertfall virker det
slik
– Usynlig - bare forsøksvise visuelle
representasjoner
Bibliotheca Alexandria
Andre faktorer
• Måleteorien innenfor programvare er et
umodent felt
• Programvare kan ikke testes uttømmende
• Programvare feiler ikke gradvis
• Metoder, verktøy og språk er ikke særlig
standardisert
• Praksis ligger ofte langt bak teori
5
Prosesskvalitet og produktkvalitet
• Man har de siste årene fokusert mye på prosesskvalitet:
– Capability Maturity Model
– SPICE
– BOOTSTRAP
• Men: “Can clean pipes produce dirty water?”
[Voas 1997].
• Svaret er selvfølgelig: Ja!
• Til syvende og sist er det ikke kvaliteten på prosessen
man er interessert i, men kvaliteten på produktet.
• Produktevaluering og -sertifisering er likevel ikke noe
alternativ, men et komplement til gode prosesser.
Hva gjør man i flyindustrien?
• Flyindustrien har noen av de strengeste kravene
som finnes til programvarekvalitet
• Det er også en av de industriene som har lengst
erfaring med sikkerhetskritisk programvare og
med sertifisering av programvarebaserte
systemer
• Sertifisering er basert på DO178-B
• Det er hele systemer som sertifiseres, ikke
frittstående programvare
6
DO-178B
• 5 kritikalitetsklasser: A-E
• Tilsammen 66 mål (eller krav) må oppfylles i de 10
definerte prosessene (utviklings- og verifikasjonsprosesser). For hvert mål defineres det også hva slags
resultater man forventer.
• Et eksempel:
– I “Verification of verification process results” er det et mål at
“Test coverage of software structure (statement coverage) is
achieved”. Dette gjelder for klassene A-C og må for A og B
også være uavhengig verifisert.
• DO-178B ser ikke noe om hvordan målene skal oppnås,
men stiller krav til evidens fra utviklingsprosessen.
• Dette krever tett samarbeid mellom utvikler og
sertifiseringsorgan gjennom hele prosessen.
Produktevaluering - definisjon
Technical operation that consists of
producing an assessment of one or more
characteristics of a software product
according to a specified procedure.
ISO/IEC 14598-5:1998
7
VV&T og Produktevaluering
• Aktiviteter som inngår i utviklingsprosessen som og
hvis mål er å sikre kvaliteten på produktet omtales
gjerne som verifikasjon, validering og testing.
• Produktevaluering kan være både verifikasjon og
validering (testing betegnes ofte som en type
validering).
• Det finnes mange VV&T teknikker. De fleste av disse
er anvendelige i en produktevalueringssammenheng.
• Validering krever innsyn i applikasjonsområdet på en
helt annen måte enn verifikasjon og er derfor
vanskeligere å utføre for en tredjepart.
• Man kan likevel få nyttige resultater fra en
produktevaluering.
ISO/IEC 14598 - Process for evaluators
Requester's
Requirements
Establishment
of Evaluation
Requirements
Evaluation
Requirements
Specification
of the
Evaluation
Product
Description
Evaluator's
Input
Pre-defined
Evaluation
Specifications
Evaluation
Methods
Product
Components
Requester's
Input
Evaluation
Specification
Design of
the
Evaluation
Evaluation Tools
Evaluation
Records
Evaluation
Plan
Record of
Evaluation
Actions
Execution
of the
Evaluation
Synthetised
Evaluation
Results
Draft Evaluation
Report
Conclusion
of the
Evaluation
Reviewed
Evaluation
Report
8
Kvalitetsmodeller
• En kvalitetsmodell beskriver hvordan man
definerer kvalitet for en gitt kontekst
• Det finnes flere kvalitetsmodeller for software:
McCall, Boehm og ISO 9126 [ISO 9126].
• En kvalitetsmodell er utgangspunktet for å
definere kravene til en produktevaluering.
ISO/IEC 9126
FUNCTIONALITY
Suitability, Accuracy,
Interoperability, Compliance,
Security
USABILITY
Understandability, Learnability,
Operability,
MAINTAINABILITY
Analysability, Changeability,
Stability, Testability
RELIABILITY
Maturity, Fault tolerance,
Recoverability
EFFICIENCY
Time behaviour, Resource
behaviour
PORTABILITY
Adaptability, Installability,
Conformance, Replaceability
9
Eksempler på evalueringsmoduler
For « FUNCTIONALITY » characteristic
evaluation :
For « MAINTAINABILITY » characteristic evaluation :
Source Code Complexity Measurement
Functionality test coverage analysis
Programming rules checking
Security policy inspection (ITSEC compliance)
Source code autodescription analysis
User survey
Inheritance relations evaluation (for OO applications)
Accuracy requirements analysis ...
Control flow analysis
For « RELIABILITY » characteristic evaluation :
Architectural relations analysis
Programming rules checking
Software configuration analysis
Memory allocation checking
Test environment analysis
Fault tolerance mechanism evaluation
Maintainance documentation inspection ...
Test coverage measurement
For « PORTABILITY » characteristic evaluation :
Recovery mechanism assessment
Reliability growth modelling ...
For « USABILITY » characteristic evaluation :
MMI (Motif, MFC, ...) style guide compliance
MMI inspection
User survey
User documentation inspection ...
Standard compiler compliance
Operating system dependency analysis
Programming rule checking
Installation procedure inspection ...
For « EFFICIENCY » characteristic evaluation :
Performance profiling analysis
Execution time measurement
Load requirement analysis
Memory allocation checking ...
Hvorfor gjøre en evaluering?
• Før man tar en beslutning om kjøp eller integrasjon av
programvare
• Før man overtar vedlikeholdsansvar for et produkt
• Som del av akseptansekrav i en utviklingskontrakt
• Som et beslutningsgrunnlag før man foretar ytterligere
investeringer i programvare eller utviklingsselskap
• Når programvaren ikke når kvalitetsmål eller mål
knyttet til vedlikeholdskostnader
• For å sikre produktkvalitet, kontrollere kostnader, unngå
forsinkelser og begrense ansvar
• For å minimalisere forretningsrisiko
10
Verktøybasert evaluering av kode
• Statisk analyse
–
–
–
–
Målinger (kompleksitet osv.)
Regelsjekk
Kontrollflytanalyse
Dataflytanalyse
• Dynamisk analyse
– Testdekningsgrad
– Minneadministrasjon
– Tidsstudier (profiling)
Eksempel på en evaluering
Product information
C source code
C header files
(".h" extension)
C source files
(".c" extension)
Number
Total size
COMP-1
116
14,023 lines
124
44,923 lines
COMP-2
607
100,934 lines
554
602,747 lines
723
114,957 lines
678
647,670 lines
Product components
Total
Number
Total size
11
Evalueringsmoduler
•
•
•
•
•
•
•
SPV - Structured Programming Verification
MAV - Modular Approach Verification
CSV - Coding Standard Verification
SCM - Software Complexity Metrics
CFA - Control Flow Analysis
DFA - Data Flow Analysis
SDM - Self-Descriptiveness Measurement
Teknikker brukt ved evaluering
• Verktøybasert
– Regelsjekk
– Målinger
• Manuelt
– Inspeksjon av regelbrudd
– Analyse av kontrollflytgraf
12
Verktøy
•
•
•
•
Logiscope C CodeChecker by Telelogic
Logiscope C RuleChecker by Telelogic
Logiscope Audit by Telelogic
CodeCheck C/C++ V7 by Abraxas
Vurdering av regelbrudd
• Klassifisering:
Excellent
Good
Fair
Poor
• Vurdering basert på:
– frekvens / tetthet av regelbrudd
– potensiell konsekvens av regelbrudd
– faktisk konsekvens av regelbrudd
13
MAV - Modular Approach Principles
• software module size limit;
• information hiding/encapsulation;
• parameter number limit;
• one entry/one exit point in subroutine and
functions;
• fully defined interface.
MAV - Overall Results
Id.
Programming conventions
STMT
The size of a file shall be limited to 1000 statements.
-
#include statements shall only be used to include header file.
-
Duplicating components (file, function) shall be avoided.
-
Declarations of objects should be at function scope unless a wider
scope is necessary (no global identifiers).
-
All declaration at file scope should be static where possible.
-
The storage class attribute (extern or static) shall be explicitly defined
when declaring a variable.
-
External objects should not be declared in more than one file.
-
COMP-1
COMP-2
2 (1,6%)
60 (10,1%)
1
0
some
some
294
579
External resource shall not be declared at function scope.
0
11
A function shall be declared with prototypes.
2
0
RU12
Functions with no parameters shall be declared with parameter type
void.
53
130
RU13
A function shall not have a variable number of parameters.
4
8
RU11
A function shall have an explicit return type.
0
0
CF05
A function shall have a single exit point.
125 (15,5%)
507 (8,3%)
RC09
A non void function shall return a value.
2
6
PARA
The number of function formal parameters shall be limited to 7.
6 (0,7%)
95 (1,6%)
CALD
The number of functions called shall be limited to 15.
6 (0,7%)
186 (3,0%)
14
MAV - Declaration at Function Scope
<filename>
int LowMem = LOW_MEM_WARNING_LEVEL_A;
word8_a
long int
int ldelay
int lwait
int cwait
int step
PrinterDebugLevel = 0;
MaxDelay=5;
=
=
=
=
1;
10;
100;
10;
if (ldelay==1)
{
if (pchar == 0x0D)
{
taskDelay(lwait);
}
}
else
{
taskDelay(lwait);
}
Dead code?
}
MAV - Functions with No Parameters: void
<filename>: 29
extern void FeedWatchdog ();
extern void ResetSystemFault (void);
<filename>: 756
void TyemmTest (viod)
{
#define INT_NUM_IRQ0
#define INT_LVL
STATUS
0x20
0xD
Res;
15
CSV - Typical Rules of Coding Standard
• details of modularisation;
• limited use or avoidance of certain language
constructs;
• restriction on interrupt enabled
execution of safety-critical code;
during
the
• lay out of the code;
• no unconditional jumps.
CSV - Use of Dynamic Memory Allocation
in
Use of reall callo mallo MemAllo MemReallo AcMall AcCallo
Total
oc
c
c
c
c
oc
c
COMP-1
ac_lib
libraries
vxworks_targe
t
COMP-2
as_main
audrive
<file>
blc
blceq
blceqdum
bsrlib
cc
domain
dz
….
0
4
4
99
5
93
1
0
0
38
38
49
49
190
96
93
1
1
1
1
134
1
110
14
1269
2
4
0
1413
2
110
28
15
121
33
2
65
51
35
1
2
10
15
121
33
1
63
51
35
4
16
CSV - No more than one statement per line
<filename> (401) LoggerKeyboardHandler
void
LoggerKeyboardHandler(
eventtype_a type,
val_a instance,
val_a user
)
{
Empty statement
char buffer[256];
AcConsoleInput(buffer);
if (buffer[0] == 'q');
{
ExitLogger();
Always executed
}
} /* LoggerKeyboardHandler */
CSV - Use symbolic constants
<filename> (601) InitP11UartAndTimer
/* Set up buffer size for rx and tx */
Retval &= (bool_a)SetupComm(ComHandle,1024,1024);
/*BUFF_SIZE,BUFF_SIZE);*/
17
SCM - Typical Metrics
• graph theoretic complexity: based of the
complexity of the program control flow
represented by its cyclomatic number,
• Halstead type metrics: based on the counting of
the number of operators and operands,
• calling relationship: based on the number of
ways to activate a certain software module.
SCM - Measurement Approach Taken
• Measuring complexity attributes on each function
• Comparing the values with threshold
• Rating the functions according to the number of
measures exceeding the thresholds
18
SCM - Complexity Metrics and Rating
Id.
Metrics
Thresholds
50
STMT
Number of executable statements
AVGS
Average size of statements
CYCL
Cyclomatic number
10
CALD
Number of called functions
7
LEVL
Maximum nesting level
5
DOPD
Number of local variables
7
PARA
Number of formal parameters
5
100 %
9.00
Excellent
Good
75 %
Fair
50 %
Poor
SCM - Overall Results
454 functions
16,5
67,3
SYSTEM (6939)
9,7
6,5
Excellent
Good
Fair
Poor
83,3
COMP-1(806)
65,2
COMP-2 (6133)
0%
20%
17,4
40%
60%
80%
9,6
4,8 2,4
10,3
7,1
100%
19
SCM - COMP-1 sub-component (I)
COMP-1 (6133)
f_lib (31)
0,0
25,8
61,3
eaclib (10)
7,1
10,3
17,4
65,2
12,9
100,0
dz (119)
cc (147)
bsrtest (55)
bsrlib (84)
blceqdum (85)
blceq (665)
14,5
70,6
as_main (6)
20%
40%
8,6
6,2
16,7
83,3
0%
7,5
7,4
14,1
13,7
64,8
audrive (337)
3,8
17,0
71,7
<FILE> (270)
10,7
22,6
11,9
54,9
blc (53)
Poor
8,2
15,3
15,3
61,2
Fair
2,4 1,2
22,6
73,8
Excellent
Good
7,3
7,3
32,7
52,7
4,1
17,0
17,0
61,9
6,5
14,0
19,6
59,8
12,6
9,2
16,8
61,3
domain (107)
60%
80%
100%
CFA - Analysis Points
• lack of processing hierarchy,
• code duplication,
• knotted code (use of unconditional branching
statement),
• inaccessible statement,
• lack of code parameterisation,
• auxiliary exit point.
20
CFA - Lack of Processing Hierarchy
~ 2000 statements
> 50 local variables
<file>.c <function>
CFA - Lack of Processing Factorisation
<file>.c <function>
21
CFA - Unknotted Flow
<file>.c <function>
DFA - Data Flow Analysis
• The aim of data flow analysis is to detect poor and
potentially incorrect program structures
• Static analysis (tool-based) of source code based
on information from control flow analysis and
determination of when variables are written and
read:
– read before write
– multiple writes with no intermediate read
– written, but never read
22
DFA - Overall Results
Id.
Programming conventions
COMP-1
COMP-2
-
All local variables shall be initialised.
0
0
RU03
A pointer shall always be initialised.
27
50
Declaration and initialisation shall be done separately.
513
5831
RU15
All formal parameters shall be used.
164
266
RU04
All local variables shall be used.
147
66
-
The value of an expression shall be the same under any
order of evaluation.
0
0
RC03
Floating point variables shall not be tested for exact
equality or inequality.
0
0
RC05
A for counter shall not be modified inside a loop.
14
8
RU06
Floating point variables shall not be used as loop
counters.
0
0
RU10
The result of a function shall always be used
1280
5953
DFA - Modifying for counter in loop
<file>.c (1355)
<function>
for (inx ...)
{
for (Inx ...
{}
inx = b + 1;
}
Also, the same name is used
with different capitalisation
23
SDM - Self-Descriptiveness Measurement
• Approach:
# lines of comments
– Measure the Comment Rate of each function= # executable statements
– Compare Comment Rate with thresholds according to
the size:
Function Size
Minimum
Satisfactory
Optimal
Less or equal to 1 statement
0.00
0.00
0.50
Between 2 and 4 statements
0.00
0.25
0.50
Between 5 and 50 statements
0.25
0.25
0.50
More than 50 statements
0.25
0.50
0.50
– Rate the functions:
Minimum
Poor
Satisfactory
Fair
Optimal
Good
Excellent
SDM - Overall Results
39,7
<SYSTEM> (6939)
26,2
25,2
8,9
Excellent
Good
Fair
Poor
58,6
COMP-1(806)
15,6
37,2
COMP-2 (6133)
0%
20%
27,6
40%
6,7
26,0
9,1
60%
19,1
80%
100%
24
Evaluation Conclusion - Strong points
• A regular usage of function prototypes
• A systematic initialisation of variables
Evaluation Conclusion - Weak points
• A poorly structured control flow
• Extensive and inconsistent use of dynamic
memory allocation
• Some bugs / risky constructions
• Little evidence of standardised coding practices
• A significant percentage of complex components
in the COMP-2 component
• Some duplication of components
• Some unnecessary data visibility
• A poor self descriptiveness of some functions
25
Recommended Actions
• Define a coding standard for new code
• Bring old code in line with coding standard
– gradually
– based on criticality (e.g. from SFMEA)
•
•
•
•
•
•
correct bugs
ensure consistent use of memory allocation
move duplicated components to common library
improve encapsulation
improve structuredness
simplify extremely complex functions
Litteratur
[Brooks 1987] F.P.Brooks, No silver bullet, IEEE Computer 20(4): 10-19,
1987.
[DO 178-B] RTCA/EUROCAE, Software Considerations in Airborne Systems
and Equipment Certification, DO-178B/ED-12B.
[Fenton 1997] N.Fenton and S.L.Pfleeger, Software Metrics: A Rigorous and
Practical Approach, International Thomson Computer Press, 1997.
[IEC 61508] IEC, Functional Safety of Electrical/Electronic/Programmable
Electronic Safety-Related Systems, IEC 61508, Parts 1 to 7.
[ISO 9126] ISO/IEC, Software Engineering - Product quality - Part 1:Quality
Model, ISO/IEC 9126-1, 2001.
[ISO 14598-5] ISO/IEC JTC1, Software Product Evaluation - Part 5:Process
for evaluations, ISO/IEC 14598-5, 1998.
[Voas 1997] J.Voas, Can Clean Pipes Produce Dirty Water, IEEE Software
14(4), pp. 93-95, July /August 1997.
26
SLUTT
på foredraget
27