Sqm First Lecture

8/16/2019 Sqm First Lecture

1/46

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1

Quality Management


2/46


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


3/46


Topics covered

rocess and product quality

Quality assurance and standards

Quality planning Quality control


4/46


!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#


5/46


'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#


6/46


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#


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#



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#



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



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#



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



!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



.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



roduct and process standards



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#



$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



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#


18/46


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#


19/46


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#


20/46


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#


21/46


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#


22/46


!oftware quality attributes


23/46


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#


24/46


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+#


25/46


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$


26/46


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


27/46


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#


28/46


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#


29/46


"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


30/46


!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#


31/46


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


32/46


redictor and control metrics

Maedeoome


33/46


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


34/46


$nternal and external attributes ograoNLtUsabilitPortabilit


35/46


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#


36/46


roduct measurement process

ecochac


37/46


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#


38/46


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#


39/46


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


40/46


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#


41/46


!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$


42/46


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.


43/46


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#


44/46


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#


45/46


: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#


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#

Date post:	06-Jul-2018
Category:	Documents
Upload:	dinesh
View:	220 times
Download:	0 times

Sqm First Lecture

Documents