[IT-51]Software Testing And

Quality Assurance
Chapter 4
Software Quality Assurance
Plan:

Chapter 4
Software Quality Assurance Plan:

4.1 Steps to develop and implement a

Software
Quality Assurance
4.2 Plan Quality Standards: ISO 9000 and
Companion
ISO Standards
4.3 CMM, CMMI, PCMM, Malcom Balridge
4.4 Six Sigma

SEI
The SEI model classifies software processes as

initial, repeatable, defined, managed and

optimising. It identifies key processes which
should be used at each of these levels
The SEI model is appropriate for large systems
developed by large teams of engineers. It
cannot be applied without modification in other
situations
Processes can be classified as informal,
managed, methodical and improving. This
classification can be used to identify process
tool support

History of SEI & CMM

The Software Engineering Institute (SEI) was

established to improve the capabilities of the

US software industry. In the mid-1980s,
Other organisations: SPICE approach
Software CMM and allows an organisation's
system development and management
processes to be assessed and assigned a
maturity level from 1 t0 5.
Rates 24 process areas (see Figure 28.10) on
a scale from 1 to 6.

The Software Engineering

Institute
US Defense Dept. funded institute associated

with Carnegie Mellon

Mission is to promote software technology
transfer particularly to defense contractors
Maturity model proposed in mid-1980s,
refined in early 1990s.
Work has been very influential in process
improvement

The SEI process maturity model

Maturity model levels

1. Initial
Essentially uncontrolled

2. Repeatable
Product management procedures defined and used

3. Defined
Process management procedures and strategies

defined
and used
4. Managed
Quality management strategies defined and used

5. Optimising
Process improvement strategies defined and used

Key process areas

Capability assessment process

An important role of the SEI is to use the CMM

to assess the capabilities of contractors

bidding for US government defence contracts
The model is intended to represent
organisational capability not the practices
used in particular projects
Within the same organisation, there are often
wide variations in processes used
Capability assessment is questionnaire-based

The Software Engineering Institute (SEI) sets software

engineering capabilities that should be present as

organizations
Reach different levels of process maturity.
Level 1: Initial. The software process is
characterized as ad hoc and occasionally
even chaotic. Few processes are defined, and success
depends on individual effort.
Level 2: Repeatable. Basic project management
processes are established
to track cost, schedule, and functionality. The necessary
process discipline is in place to repeat earlier successes
on projects with similar applications.

Level 3: Defined. The software process for both

management and engineering
activities is documented, standardized, and integrated into an
organizationwide software process. All projects use a
documented and approved version of the organization's
process for developing and supporting software. This level
includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software
process and product
quality are collected. Both the software process and
products are quantitatively understood and controlled using
detailed measures. This level includes all characteristics
defined for level 3.
Level 5: Optimizing. Continuous process improvement
is enabled by quantitative
feedback from the process and from testing innovative

SEI model problems

It focuses on project management rather than

product development.
It ignores the use of technologies such as
rapid prototyping.
It does not incorporate risk analysis as a key
process area
It does not define its domain of applicability

KPAs
KPAs : Must be present to satisfy good practice at a particular level.
Goalsthe overall objectives that the KPA must achieve.
Commitmentsrequirements (imposed on the organization) that

must be met to achieve the goals or provide proof of intent to

comply with the goals.
Abilitiesthose things that must be in place (organizationally and
technically) to enable the organization to meet the commitments.
Activitiesthe specific tasks required to achieve the KPA function.
Methods for monitoring implementationthe manner in which
the activities are monitored as they are put into place.
Methods for verifying implementationthe manner in which
proper practice for the KPA can be verified.
Eighteen KPAs: mapped into different levels of process maturity

Process maturity level 1:

No KPA

Process maturity level 2

1. Software configuration management
2. Software quality assurance
3. Software subcontract management
4. Software project tracking and oversight
5. Software project planning
6. Requirements management

Process maturity level 3

7. Peer reviews
8. Intergroup coordination
9. Software product engineering
10. Integrated software management
11. Training program
12. Organization process definition
13. Organization process focus

Process maturity level 4

14. Software quality management
15. Quantitative process management

Process maturity level 5

16. Process change management
17. Technology change management
18. Defect prevention

CMMI Structure
one Model, Two Representations
Appendixes
Appendixes
Support
CM, PPQA, MA,
CAR, DAR

Maturity Level 5
OID, CAR
Maturity Level 4
OPP, QPM

Engineering
REQM, REQD, TS,
PI, VER, VAL

Maturity Level 3
REQD, TS, PI, VER,
VAL, OPF, OPD, OT,
IPM, RSKM, DAR

Project Management
PP, PMC, SAM
IPM, RSKM, QPM

Maturity Level 2
REQM, PP, PMC,
SAM, MA, PPQA, CM

Process Management
OPF, OPD, OT,
OPP, OID

Overview
Introduction
Structure of the Model
Model Terminology
Maturity Levels, Common Features, and Generic Practices
Understanding the Model
Using the Model

Overview
Process Management
Introduction
PAs
Structure of
the Model
Goals
Model Terminology
Practices
Capability- Levels
and Generic Model Components
Understanding the Model
Using the Model

CMMI-SE/SW
Staged

CMMI-SE/SW
Continuous
17

SQAM Course,
Proficience, IISc

Six Sigma 1
Statisticians use to represent the standard deviation of a

population
-The fewer the defects, the higher the sigma level, and the
better the quality.
The Six Sigma philosophy can be captured as a
methodology that allows companies to:
1.
Consistently meet customer requirements
2.
Use data to drive all decision making
3.
Do everything with quality

19

Chapter 4. Software Quality Assurance

Fundamentals
Pune Rahul P.

12/27/16

Six Sigma (continued)

All of these steps need to be performed so that you can manage the

process to accomplish something

You cannot effectively manage and improve a process until you first
do these steps (in this order):

20

Six-Sigma for Software Engineering

The term six sigma is derived from six standard

deviations3.4 instances (defects) per million

occurrencesimplying an extremely high quality
standard.
The Six Sigma methodology defines three core steps:
Define customer requirements and deliverables and project

goals via well-defined methods of customer communication

Measure the existing process and its output to determine
current quality performance (collect defect metrics)
Analyze defect metrics and determine the vital few causes.
Improve the process by eliminating the root causes of
defects.
Control the process to ensure that future work does not
reintroduce the causes of defects.
21

Six Sigma 2
- Internal customers: referred to as process partners
-External customers: voice of the customer
Ex:Motorola
Defect : Total Slides 100

Defect i.e label is not present on slide :15 slides.

DPMO = Total defects/total opportunities x1,000,000\

(15/100) x 1,000,000 = 150,000 DPMO

Steps:
1>Identify and define customer requirements,project goals and deliverables
2>Measure the o/p of applied process
3>Analyse defect if any and detgermine vital cause
If existing s/w process is already using
4>Eliminated defects
5>Control process

Use of Six sigma

1. Statistical quality control
2. finding number of defects
3. eliminating in the next process
4. reliably and consistently meet customer and business

requirements