Sqm First Lecture
Transcript of Sqm First Lecture
-
8/16/2019 Sqm First Lecture
1/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1
Quality Management
-
8/16/2019 Sqm First Lecture
2/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 2
Objectives
To introduce the quality management process and
key quality management activities
To explain the role of standards in quality
management To explain the concept of a software metric,
predictor metrics and control metrics
To explain how measurement may be used in
assessing software quality and the limitations ofsoftware measurement
-
8/16/2019 Sqm First Lecture
3/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 3
Topics covered
rocess and product quality
Quality assurance and standards
Quality planning Quality control
-
8/16/2019 Sqm First Lecture
4/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 4
!oftware quality management
"oncerned with ensuring that the required
level of quality is achieved in a software
product#
$nvolves defining appropriate qualitystandards and procedures and ensuring that
these are followed#
!hould aim to develop a %quality culture&where quality is seen as everyone&s
responsibility#
-
8/16/2019 Sqm First Lecture
5/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 5
'hat is quality(
Quality, simplistically, means that a product should
meet its specification#
This is problematical for software systems
) There is a tension between customer qualityrequirements *efficiency, reliability, etc#+ and developer
quality requirements *maintainability, reusability, etc#+
) !ome quality requirements are difficult to specify in an
unambiguous way
) !oftware specifications are usually incomplete and often
inconsistent#
-
8/16/2019 Sqm First Lecture
6/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 6
The quality compromise
'e cannot wait for specifications to improve
before paying attention to quality
management#
'e must put quality managementprocedures into place to improve quality in
spite of imperfect specification#
-
8/16/2019 Sqm First Lecture
7/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 7
!cope of quality management
Quality management is particularly important
for large, complex systems# The quality
documentation is a record of progress and
supports continuity of development as thedevelopment team changes#
-or smaller systems, quality management
needs less documentation and should focus
on establishing a quality culture#
-
8/16/2019 Sqm First Lecture
8/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 8
Quality management activities
Quality assurance) .stablish organisational procedures and standards for
quality#
Quality planning) !elect applicable procedures and standards for a
particular project and modify these as required#
Quality control) .nsure that procedures and standards are followed by
the software development team#
Quality management should be separate fromproject management to ensure independence#
-
8/16/2019 Sqm First Lecture
9/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 9
The quality of a developed product is
influenced by the quality of the production
process#
This is important in software development assome product quality attributes are hard to
assess#
/owever, there is a very complex and poorlyunderstood relationship between software
processes and product quality#
rocess and product quality
-
8/16/2019 Sqm First Lecture
10/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 10
rocess0based quality
There is a straightforward link between process and
product in manufactured goods#
More complex for software because1
) The application of individual skills and experience isparticularly imporant in software development
) .xternal factors such as the novelty of an application or
the need for an accelerated development schedule may
impair product quality#
"are must be taken not to impose inappropriateprocess standards 0 these could reduce rather than
improve the product quality#
-
8/16/2019 Sqm First Lecture
11/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 11
2efine process standards such as howreviews should be conducted, configurationmanagement, etc#
Monitor the development process to ensurethat standards are being followed#
3eport on the process to projectmanagement and software procurer#
2on&t use inappropriate practices simplybecause standards have been established#
ractical process quality
-
8/16/2019 Sqm First Lecture
12/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 12
!tandards are the key to effective qualitymanagement#
They may be international, national,
organi4ational or project standards# roduct standards define characteristics that
all components should exhibit e#g# a commonprogramming style#
rocess standards define how the softwareprocess should be enacted#
Quality assurance and standards
-
8/16/2019 Sqm First Lecture
13/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 13
.ncapsulation of best practice0 avoids
repetition of past mistakes#
They are a framework for quality assurance
processes 0 they involve checkingcompliance to standards#
They provide continuity 0 new staff can
understand the organisation byunderstanding the standards that are used#
$mportance of standards
-
8/16/2019 Sqm First Lecture
14/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 14
roduct and process standards
-
8/16/2019 Sqm First Lecture
15/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 15
roblems with standards
They may not be seen as relevant and up0to0
date by software engineers#
They often involve too much bureaucratic
form filling# $f they are unsupported by software tools,
tedious manual work is often involved to
maintain the documentation associated withthe standards#
-
8/16/2019 Sqm First Lecture
16/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 16
$nvolve practitioners in development# .ngineers
should understand the rationale underlying a
standard#
3eview standards and their usage regularly#!tandards can quickly become outdated and this
reduces their credibility amongst practitioners#
2etailed standards should have associated tool
support# .xcessive clerical work is the most
significant complaint against standards#
!tandards development
-
8/16/2019 Sqm First Lecture
17/46©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 17
2ocumentation standards
articularly important 0 documents are the tangible
manifestation of the software#
2ocumentation process standards
) "oncerned with how documents should be developed,validated and maintained#
2ocument standards
) "oncerned with document contents, structure, and
appearance#
2ocument interchange standards
) "oncerned with the compatibility of electronic documents#
-
8/16/2019 Sqm First Lecture
18/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 18
2ocument standards
2ocument identification standards) /ow documents are uniquely identified#
2ocument structure standards
) !tandard structure for project documents# 2ocument presentation standards
) 2efine fonts and styles, use of logos, etc#
2ocument update standards) 2efine how changes from previous versions are
reflected in a document#
-
8/16/2019 Sqm First Lecture
19/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 19
2ocument interchange standards
$nterchange standards allow electronic documents tobe exchanged, mailed, etc#
2ocuments are produced using different systemsand on different computers# .ven when standard
tools are used, standards are needed to defineconventions for their use e#g# use of style sheets andmacros#
5eed for archiving# The lifetime of word processing
systems may be much less than the lifetime of thesoftware being documented# 6n archiving standardmay be defined to ensure that the document can beaccessed in future#
-
8/16/2019 Sqm First Lecture
20/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 20
Quality planning
6 quality plan sets out the desired product
qualities and how these are assessed and
defines the most significant quality attributes#
The quality plan should define the qualityassessment process#
$t should set out which organisational
standards should be applied and, wherenecessary, define new standards to be used#
-
8/16/2019 Sqm First Lecture
21/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 21
Quality plans
Quality plan structure
) roduct introduction
) roduct plans
) rocess descriptions
) Quality goals
) 3isks and risk management#
Quality plans should be short, succinctdocuments
) $f they are too long, no0one will read them#
-
8/16/2019 Sqm First Lecture
22/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 22
!oftware quality attributes
-
8/16/2019 Sqm First Lecture
23/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 23
Quality control
This involves checking the software
development process to ensure that
procedures and standards are being
followed# There are two approaches to quality control
) Quality reviews
) 6utomated software assessment and software
measurement#
-
8/16/2019 Sqm First Lecture
24/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 24
Quality reviews
This is the principal method of validating the quality
of a process or of a product#
6 group examines part or all of a process or system
and its documentation to find potential problems# There are different types of review with different
objectives
) $nspections for defect removal *product+
) 3eviews for progress assessment *product and process+
) Quality reviews *product and standards+#
-
8/16/2019 Sqm First Lecture
25/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 25
Types of review
Review type Principal purpose
Design or program
inspections
To detect detailed errors in te re!"irements# design or code$ % cec&list o'
possi(le errors so"ld drive te revie)$
*rogress revie)s To provide in'ormation 'or management a(o"t te overall progress o' te
pro+ect$ Tis is ( ot a process and a prod"ct revie) and is concerned )it
costs# plans and sced"les$
,"alit- revie)s To carr- o"t a t ecnical anal-sis o' prod"ct components or doc"mentation to
'ind mismatces (et)een te speci'ication and te component design# code or
doc"mentation and to ens"re tat de'ined !"alit- standards ave (een 'ollo)ed$
-
8/16/2019 Sqm First Lecture
26/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 26
6 group of people carefully examine part or all
of a software system and its associated
documentation#
"ode, designs, specifications, test plans,standards, etc# can all be reviewed#
!oftware or documents may be 7signed off7 at a
review which signifies that progress to the next
development stage has been approved by
management#
Quality reviews
-
8/16/2019 Sqm First Lecture
27/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 27
3eview functions
Quality function 0 they are part of the general
quality management process#
roject management function 0 they provide
information for project managers# Training and communication function 0
product knowledge is passed between
development team members#
-
8/16/2019 Sqm First Lecture
28/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 28
Quality reviews
The objective is the discovery of system
defects and inconsistencies#
6ny documents produced in the process may
be reviewed# 3eview teams should be relatively small and
reviews should be fairly short#
3ecords should always be maintained ofquality reviews#
-
8/16/2019 Sqm First Lecture
29/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 29
"omments made during the review should beclassified) 5o action# 5o change to the software or documentation is
required
) 3efer for repair# 2esigner or programmer should correctan identified fault
) 3econsider overall design# The problem identified in thereview impacts other parts of the design# !ome overall
judgement must be made about the most cost0effectiveway of solving the problem
3equirements and specification errors mayhave to be referred to the client#
3eview results
-
8/16/2019 Sqm First Lecture
30/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 30
!oftware measurement and metrics
!oftware measurement is concerned with deriving a
numeric value for an attribute of a software product
or process#
This allows for objective comparisons betweentechniques and processes#
6lthough some companies have introduced
measurement programmes, most organisations still
don&t make systematic use of software
measurement#
There are few established standards in this area#
-
8/16/2019 Sqm First Lecture
31/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 31
6ny type of measurement which relates to asoftware system, process or related documentation) 8ines of code in a program, the -og index, number of
person0days required to develop a component# 6llow the software and the software process to
be quantified# May be used to predict product attributes or to
control the software process# roduct metrics can be used for general predictions
or to identify anomalous components#
!oftware metric
-
8/16/2019 Sqm First Lecture
32/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 32
redictor and control metrics
Maedeoome
-
8/16/2019 Sqm First Lecture
33/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 33
6 software property can be measured#
The relationship exists between what we can
measure and what we want to know# 'e can only
measure internal attributes but are often more
interested in external software attributes#
This relationship has been formalised and
validated#
$t may be difficult to relate what can be measured todesirable external quality attributes#
Metrics assumptions
-
8/16/2019 Sqm First Lecture
34/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 34
$nternal and external attributes ograoNLtUsabilitPortabilit
-
8/16/2019 Sqm First Lecture
35/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 35
The measurement process
6 software measurement process may be
part of a quality control process#
2ata collected during this process should be
maintained as an organisational resource# Once a measurement database has been
established, comparisons across projects
become possible#
-
8/16/2019 Sqm First Lecture
36/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 36
roduct measurement process
ecochac
-
8/16/2019 Sqm First Lecture
37/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 37
2ata collection
6 metrics programme should be based on a
set of product and process data#
2ata should be collected immediately *not in
retrospect+ and, if possible, automatically# Three types of automatic data collection
) !tatic product analysis
) 2ynamic product analysis) rocess data collation#
-
8/16/2019 Sqm First Lecture
38/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 38
2ata accuracy
2on&t collect unnecessary data
) The questions to be answered should be
decided in advance and the required data
identified# Tell people why the data is being collected#
) $t should not be part of personnel evaluation#
2on&t rely on memory
) "ollect data when it is generated not after a
project has finished#
-
8/16/2019 Sqm First Lecture
39/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 39
6 quality metric should be a predictor of
product quality#
"lasses of product metric
) 2ynamic metrics which are collected by measurements
made of a program in execution
) !tatic metrics which are collected by measurements
made of the system representations
) 2ynamic metrics help assess efficiency and reliability
static metrics help assess complexity, understandabilityand maintainability#
roduct metrics
-
8/16/2019 Sqm First Lecture
40/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 40
2ynamic and static metrics
2ynamic metrics are closely related to software
quality attributes
) $t is relatively easy to measure the response time of a
system *performance attribute+ or the number of failures
*reliability attribute+# !tatic metrics have an indirect relationship with
quality attributes
) 9ou need to try and derive a relationship between these
metrics and properties such as complexity,understandability and maintainability#
-
8/16/2019 Sqm First Lecture
41/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 41
!oftware product metrics
Software metric Description
.an in/.an0o"t .an0in is a meas"re o' te n"m(er o' '"nctions or metods tat call some oter '"nction
or metod 1sa- 3$ .an0o"t is te n"m(er o' '"nctions tat are called (- '"nction $ %
ig val"e 'or 'an0in means tat i s tigtl- co"pled to te rest o' te design andcanges to )ill ave e4tensive &noc&0on e''ects$ % ig val"e 'or 'an0o"t s"ggests
tat te overall comple4it- o' m a- (e ig (eca"se o' te comple4it- o' te control
logic needed to coordinate te called components$
5engt o' code Tis is a meas"re o' te si6e o' a program$ 7enerall-# te larger te si6e o' te code o' a
component# te more comple4 and error0prone tat component is li&el- to (e$ 5engt o'
code as (een so)n to (e one o' te most relia(le metrics 'or predicting error0
proneness in components$
8-clomatic comple4it- Tis is a m eas"re o' te control comple4it- o' a p rogram$ Tis control comple4it- ma-
(e related to program "nderstanda(ilit-$ I disc"ss o) to comp"te c-clomatic
comple4it- in 8apter 22$
5engt o' identi'iers Tis is a meas"re o' te average lengt o' distinct identi'iers in a pr ogram$ Te longer
te identi'iers# te more li&el- te- are to (e m eaning'"l and ence te more
"nderstanda(le te program$
Dept o' conditional
nesting
Tis is a meas"re o' te dept o' nesting o' i'0statements in a program$ Deepl- nested i'
statements are ard to "nderstand and are potentiall- error0prone$
.og inde4 Tis is a meas"re o' te average lengt o' )ords and sentences in doc"ments$ Te iger
te val"e 'or te .og inde4# te more di''ic"lt te doc"ment is to "nderstand$
-
8/16/2019 Sqm First Lecture
42/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 42
Object0oriented metrics
Object-oriented
metric
Description
Depth of inheritancetree
This represents the number of discrete levels in the inheritance tree where sub-classes inherit attributes and operations (methods) from super-classes. The
deeper the inheritance tree, the more complex the design. Many different object
classes may have to be understood to understand the object classes at the leaves
of the tree.
Method fan-in/fan-out
This is directly related to fan-in and fan-out as described above and meansessentially the same thing. However, it may be appropriate to make a
distinction between calls from other methods within the object and calls fromexternal methods.
Weighted methods
per class
This is the number of methods that are included in a class weighted by the
complexity of each method. Therefore, a simple method may have a complexity
of 1 and a large and complex method a much higher value. The larger the value
for this metric, the more complex the object class. Complex objects are more
likely to be more difficult to understand. They may not be logically cohesive so
cannot be reused effectively as super-classes in an inheritance tree.
Number of overriding
operations
This is the number of operations in a super-class that are over-ridden in a sub-class. A high value for this metric indicates that the super-class used may not be
an appropriate parent for the sub-class.
-
8/16/2019 Sqm First Lecture
43/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 43
Measurement analysis
$t is not always obvious what data means
) 6nalysing collected data is very difficult#
rofessional statisticians should be
consulted if available# 2ata analysis must take local circumstances
into account#
-
8/16/2019 Sqm First Lecture
44/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 44
Measurement surprises
3educing the number of faults in a program
leads to an increased number of help desk
calls
) The program is now thought of as more reliableand so has a wider more diverse market# The
percentage of users who call the help desk may
have decreased but the total may increase
) 6 more reliable system is used in a different wayfrom a system where users work around the
faults# This leads to more help desk calls#
-
8/16/2019 Sqm First Lecture
45/46
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 45
:ey points
!oftware quality management is concernedwith ensuring that software meets its requiredstandards#
Quality assurance procedures should bedocumented in an organisational qualitymanual#
!oftware standards are an encapsulation of
best practice# 3eviews are the most widely used approach
for assessing software quality#
-
8/16/2019 Sqm First Lecture
46/46
:ey points
!oftware measurement gathers information
about both the software process and the
software product#
roduct quality metrics should be used toidentify potentially problematical
components#
There are no standardised and universally
applicable software metrics#