SDPM - Lecture 8 - Software quality assurance

Leiden Institute of Advanced Computer Science

System s Development and Project
Management –
Software quality assurance

Prof. dr. Thomas Bäck

1

Leiden Institute of Advanced Computer Science Dates

Feb. 1 14:45 – 17:30 Introduction, Project Description
Feb. 2 13:45 – 16:30 STEP WISE Approach to Project Planning
Feb. 9 13:10 – 15:45 STEP WISE Approach to Project Planning,
SAVE ENERGY Case
Feb. 15 14:45 – 17:30 Selecting an Appropriate Software Dev.
Approach
Feb. 16 15:15 – 18:00 Activity Planning and Resource Allocation
Feb. 22 14:45 – 17:30 Software Effort Estimation
Feb. 23 13:15 – 15:45 Risk management, project escalation
Mar. 1 14:45 – 17:00 Exam
Mar. 2 13:45 – 16:30 Risk Management, Project monitoring and
control
Mar. 8 14:45 – 17:30 Software Quality Assurance
Mar. 9 13:45 – 16:30 Managing People; Contract Management
Mar. 18 15:00 – 17:00 Trade Fair
2


STEP WISE overview
0.Select
Some relate to qualities 1. Identify project 2. Identify project
project objectives infrastructure
Installation standards,
3. Analyze procedures.
pr. characteristics Special quality requirements ?

Review 4. Identify products Entry, exit, process requirements ?
Lower and activities
level 5. Estimate effort
detail for activity For each
6. Identify activity activity
risks
10. Lower level 7. Allocate
planning resources
8. Review/ publicize Review of overall quality aspects.
9. Execute plan plan
3


Software quality

!   Of increasing concern
!  E.g. safety critical systems, dependence on core
IS
!   Project control concerns:
!  Need to make project progress visible
!  Every task has a deliverable
!  Errors accumulate with each stage
!  Errors become more expensive to remove the
later they are found
!  It is difficult to control the error removal process
(e.g. testing)
4


Software quality

!   Three Specifications:
!  Functional: What the system is to do.
!  Quality: How well the functions are to operate.
!  Resource: How much is to be spend on the system.

5


ISO 9126 software qualities

Functionality Does it satisfy user needs?

Reliability Can the software maintain its
level of performance?
Usability How easy is it to use?

Efficiency Relates to the physical resources
used during execution
Maintainability Relates to the effort needed to
make changes to the software
Portability How easy can it be moved to a
new environment?

6


ISO 9216

!   Defined in 1991
!   To tackle the question of definition of software
quality
!   Also suggests sub-characteristics of the main
ones outlined here (outside main standard)
!   See next slides

7


Functionality sub-characteristics

!   Suitability
!   Accuracy
!   Interoperability
!  Ability of software to interact with other software components
!   Compliance
!  Degree to which software adheres to application-related
standards or legal requirements, e.g. audit
!   Security
!  Control of access to the system

8


Reliability sub-characteristics

!   Maturity
!  Frequency of failure due to faults - the more the
software has been used, the more faults will have
been uncovered and removed
!   Fault-tolerance
!   Recoverability
!  Note that this is distinguished from security -
see above

9


Further quality sub-characteristics

!   Usability sub-characteristics:
!  Understandability: easy to understand?
!  Learnability: easy to learn?
!  Operability: easy to use?
!   Efficiency sub-characteristics:
!  Time behavior, e.g. response time
!  Resource behavior, e.g. memory usage

10


Further quality sub-characteristics
(cont d)
!   Maintainability sub-characteristics:
!  Analyzability: ease with which the cause of a
failure can be found
!  Changeability: how easy is software to change?
!  Stability: low risk of modification having
unexpected effects
!  Testability

11


Quality sub-characteristics (cont d)

!   Portability sub-characteristics:
!  Adaptability
!  Installability
!  Conformance: standards that have bearing on
portability (compare to compliance ) - e.g. use of
high-level language
!  Replaceability: factors giving upwards
compatibility - downwards compatibility is
excluded

12


Quality relationships

!   Indifferent
!  One has no effect on the other
!   Competitive
!  A system can only be good in respect to one
quality at the expense of another
!   Complementary
!  A system which is good in respect to one quality is
likely to be also good in respect to the other

13


Internal vs. external qualities
Translate into

External qualities: Internal qualities (SQCs):
!   Changeability !   Modularity
!   Generality
!   Expandability
!   Self-descriptiveness

!   Testability !   Simplicity
!   Modularity
!   Instrumentation

14


Internal vs. external qualities (cont d)

External qualities: Internal qualities (SQCs):
!   Portability !   Modularity
!   Machine independence
!   Software system
independence

15


Using ISO 9126 quality standards

!   Judge the importance of each quality for the
application
!  E.g. safety critical systems - reliability very
important
!  Real-time systems - efficiency important
!   Work out ways of measuring quality
!  E.g. mean-time between failures for reliability
!  Response-time for efficiency

16


(cont d)
!   Map measurement onto Response
Ratings
( 0-‐
ratings scale to show (sec.)
5)

degree of satisfaction: < 2
5

2-‐5
4

6-‐10
3

11-‐15
2

16-‐20
1

> 20
0

17


(cont d)
!   Work out how ratings are to be combined
!   ISO 9126 does not specify how to do that – only that
some method must be devised

Quality
Importance
( a)
Rating
( b)
Score
( a
x
b)

Reliability
5
3
15

Efficiency
2
5
10

Usability
4
4
16

T otal

41

18


Software measurement

!   May apply to:
!  Final products
!  Intermediate products (predictive metrics)
!   May be:
!  Relative or binary (does it/does it not exist?)
!  Direct or indirect
!  Tightly or loosely coupled

19


Quality specification

!   Each project has three sets of requirements
!  Functional requirements: what the system is to do
!  Quality requirements: how well it is to do it
!  Resource requirements: how much it is going to
cost


Quality specification, e.g. ease of
installation
!   Definition of attribute
!  The amount of effort needed to install the package
for a new customer
!   Measurement scale
!  Hours
!   How tested
!  Time needed to install system at three different
sites

21


Quality specification, e.g. ease of
installation (cont d)
!   Worst acceptable limit
!  4 hours
!   Planned limit
!  1 hours
!   Best achievable
!  30 minutes

Define these for ‘user-friendliness’!

22


How do we achieve product quality?

!   The problem: quality attributes tend to be
retrospectively measurable
!   Need to be able to examine processes by
which product is created beforehand
!   The production process is a network of sub-
processes
!   Output from one process forms the input to
the next
!   Errors can enter the process at any stage

23


Product vs. process quality management

!   Errors are more expensive to correct at later
stages
!  Need to rework more stages
!  Later stages are more detailed and less able to
absorb change
!   Barry Boehm
!  Error typically 10 times more expensive to correct
at coding stage than at requirements stage
!  100 times more expensive at maintenance stage

24


For each activity, define…

!   Entry requirements
!  These have to be in place before an activity can
be started
!  Example: a comprehensive set of test data and
expected results be prepared and independently
reviewed against the system requirement before
program testing can commence

25


For each activity, define… (cont d)

!   Implementation requirements
!  These define how the process is to be conducted
!  Example: whenever an error is found and
corrected, all test runs must be completed,
including those previously successfully passed

26


For each activity, define… (cont d)

!   Exit requirements
!  An activity will not be completed until these
requirements have been met
!  Example: the testing phase is finished only when
all tests have been run in succession with no
outstanding errors
!   Software quality plan
!  These requirements may be laid down in site
standards, or a quality plan may be drawn up for a
specific project

27


Inspections – general principles

!   When a piece of work is completed, copies
are distributed to co-workers
!   Time is spent individually going through the
work noting defects
!   A meeting is held where the work is then
discussed
!   A list of defects requiring re-work is produced

28


Inspections – advantages of approach

!   An effective way of removing superficial
errors from a piece of software
!   Motivates the software developer to produce
better structured and self-descriptive code
!   Spreads good programming practice
!   Enhances team-spirit
!   The main problem maintaining the
commitment of participants

29


General movement to give software more
quality
!   Increase the visibility of software
!   Put method into processes of development
!   Check intermediate stages

30


External standards – ISO 9001:2000

!   Ensure that a monitoring and control system to check
quality is in place
!   Only certification of development process
!   Not software development-specific
!   Main activities:
!  Determine customer needs and expectation
!  Establish quality policy
!  Design product creation process with responsibilities
!  Measure effectiveness and efficiency
!  Take corrective action

31


ISO 9001:2000 (Criticism)

!   Expensive, time consuming
!   Putting smaller firms at a disadvantage
!   Preoccupation with certification
!   Can distract attention from real problems of
producing quality products

32


External standards – Capability Maturity
Model
!   Levels of Process Maturity:
!  Level 1 – Initial: haphazard procedures followed
•  Any organization at this level by default …
!  Level 2 – Repeatable: basic project management
procedures
•  The way individual tasks are carried out will depend
largely on person doing it.

33


Model
!   Levels of Process Maturity:
!  Level 3 – Defined: how should each task in the
softw. Development life cycle be done
!  Level 4 – Managed: products and processes are
subject to measurement and control
!  Level 5 – Optimizing: improvements based on
measurement data

34


Model (cont d)

Level Key Process Areas

Initial Not applicable Software Configs,
Repeatable Configuration management, i.e., Version Control
quality
assurance, project planning, etc.
Defined Peer reviews, integrated software
management, training program, etc.
Managed Quality management, process
measurement and analysis
Optimizing Process change management,
technology innovation, defect prevention

35


Summary

!   Quality = vague concept. Requirements have to be
carefully defined.
!   There have to be practical ways to test relative
presence / absence of a quality.
!   Most qualities can only be tested when system is
completed.
!   We need ways of checking during development.
!   Some procedures focus on testing products, others on
evaluating quality of the development process.

36

SDPM - Lecture 8 - Software quality assurance

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to SDPM - Lecture 8 - Software quality assurance

Similar to SDPM - Lecture 8 - Software quality assurance (20)

More from OpenLearningLab

More from OpenLearningLab (20)

Recently uploaded

Recently uploaded (20)

SDPM - Lecture 8 - Software quality assurance