SOFTWARE QUALITY

ASSURANCE
(BISE 3033)
SOFTWARE QUALITY ASSURANCE
METHOD
CAPABILITY MATURITY MODEL
(CMM)
What do you learn?
 History
 Definition
 Benefits
 Risk
 The Maturity Levels
 Criticism
 Key Process Area

| page no 2
HISTORY
 1986 - Effort started by SEI and MITRE Corporation
 Funded by the US DoD

 First version published in 1991

 SEI mission is to provide leadership in advancing the state of the
practice of software engineering to improve the quality of systems that
depend on software.
 SEI vision is to bring engineering discipline to the development and
maintenance of software.
 Process improvement is based on small steps, rather than
revolutionary innovation.
 CMM focuses on processes that are of value across the organization.
 Closely related to TQM (Total Quality Management)
 goal is customer satisfaction

| page no 3
TOTAL QUALITY MANAGEMENT
(TQM)
 Total Quality Management (TQM) is the application of
quantitative methods and human resources to improve:
 The material and services supplied to an
organization
 All the processes within an organization
 The degree to which the needs of the customer are
met, now and in the future

 Process improvement fits in

all overall business context
(Applying TQM concept
(CMM) into software)

| page no 4
DEFINITION OF CMM
 A model that contains the essentials elements of
effective processes for one or more areas of interest
 It describe an evolutionary improvement path from ad-
hoc, immature processes to disciplined, mature
processes with improved quality and effectiveness

 According to SEI “ the quality of a system or product is

highly influenced by the quality of the process used to
develop and maintain it

 In other word, CMM is a model for assessing

processes in organizations during software
development (CMM focus on improving processes in
organizations)
| page no 5
BENEFITS
 helps forge a shared vision of purpose of
process improvement within the organization
 establishes common language for the
software process
 defines a set of priorities for attacking
problems
 supports measurement
 via reliable appraisals

 objective

 supports industry-wide comparisons

| page no 6
RISK
 Not a silver bullet.
 Does not address all of the issues that are
important for successful projects.
 For example
 how to hire and retain good people
 expertise in the application domain
COMPONENTS/ASPECTS OF
CMM
• Each of the five CMM
levels is composed of
key process areas
• each key process area
is organized into five
sections called common
features
• common features
contain key practices

| page no 8
COMMAND FEATURES
1. Commitment to Perform
2. Ability to Perform
3. Activities Performed
4. Measurement and Analysis
5. Verifying Implementation

| page no 9
THE LEVELS OF MATURITY
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing

| page no 10
LEVEL 1: THE INITIAL LEVEL
• ad hoc, sometimes chaotic
• over commitment leads to a series of
crises
• during a crisis, projects abandon
plans
• capability is characteristic of
individuals, not the organization
• when a good manager leaves,

the success leaves with them

| page no 11
| page no 12
| page no 13
LEVEL 2: THE REPEATABLE
LEVEL
• Planning is based on experience
with similar projects
• past successes can be repeated

• Policies for Managing and

Implementation
• installed basic management
controls
• track costs and schedules
• notice and deal with problems
as they arise
MBA/HRM/LESSON1 | page no 14
MBA/HRM/LESSON1 | page no 15
LEVEL 3: THE DEFINED LEVEL
• Standard Processes defined across
the organization and used by all
projects
• standard set of roles,

activities, quality tracking, etc

• each project uses a tailored

version of this standard

process
• Training Program is in place to
ensure everyone has the skills
required for their assigned role
MBA/HRM/LESSON1 | page no 16
MBA/HRM/LESSON1 | page no 17
LEVEL 4: THE MANAGED LEVEL
• Quantitative Quality Goals
• for both Products and Processes

• Organization-wide Process Database

• meaningful variations in process
performance can be distinguished
from random noise
• actions are then taken to correct

the situation
• Products are of predictably high quality

MBA/HRM/LESSON1 | page no 18
MBA/HRM/LESSON1 | page no 19
LEVEL 5: THE OPTIMIZING LEVEL
• Organization has the means to
identify weaknesses and strengthen
the process proactively
• teams analyze defects to determine
their cause, and disseminate lessons
learned throughout the organization
• major focus on eliminating waste
• e.g. reduce amount of rework

MBA/HRM/LESSON1 | page no 20
MBA/HRM/LESSON1 | page no 21
CRITICISMS OF CMM
 CMM is well suited for bureaucratic
organizations such as government
agencies and large corporations.
 Its formality is a hindrance to projects where
time-to-market is more important than quality.

 Promotes process over substance.

 For example, emphasizing predictability over
service provided to end users.

MBA/HRM/LESSON1 | page no 22
WHO USES CMM?
 75% of organizations are probably Level One.
 To get to Level Two, you must have control

over the requirements documents. Hence,

shrink-wrap companies like Microsoft are Level
One.

 75% of Level Five organizations are in India.

MBA/HRM/LESSON1 | page no 23
Level Comparison - Risk
 Level 1
 Just do it

 Level 2
 problems are recognized and corrected as they

occur
 Level 3
 problems are anticipated and prevented, or

impacts minimized
 Levels 4 and 5
 sources of problems are understood and

eliminated
Level Comparison - People
 Level 1
 success depends on individual heroics
 fire fighting is the way of life
 Level 2
 people are trained and supported by management
 success depends on individuals
 Level 3
 people are trained for their role(s)
 groups work together
 Levels 4
 strong sense of teamwork in every project
 Level 5
 strong sense of teamwork across the organization
 everyone does process improvement
Level Comparison -
Measurement
 Level 1
 ad hoc data collection and analysis

 Level 2
 individual projects use planning data

 Level 3
 data collected for all processes

 data shared across projects

 Levels 4
 data standardized across the organization

 Level 5
 data used for process improvement
KEY PROCESS AREAS
 Identify a cluster of related activities that, when
performed collectively, achieve a set of goals
considered important for enhancing process
capability
 Defined to reside at a single maturity level
 Identify the issues that must be addressed to
achieve a maturity level

MBA/HRM/LESSON1 | page no 27
 Defect prevention
Technology change management

KEY PROCESS Process change management

AREAS BY Quantitative process management

MATURITY LEVEL Software Quality Management

Organization process focus

This is a Organization process definition
Training program
somewhat Integrated software management
handy Software product engineering
Intergroup coordination
hierarchy of Peer Reviews
activities.
Requirements management  Don’t SKIP levels!
Software project planning  For example, collecting
Software project tracking and oversight
detailed data (level 4) is
Software subcontract management
meaningless unless the
Software quality assurance
data is from projects that
Software Configuration management
use a consistent process
| page no 28
(level 3)
Objectives of Key Process
Areas
 Level Two
 Requirements Management
 necessary to build software that will satisfy the customer
 Software project planning
 reasonable plans of what to do and when
 Software project tracking and oversight
 visibility into project's progress
 Software subcontract management
 select and effectively manage subcontractors
 Software quality assurance
 process and product are reviewed to create visibility into the process
 Software Configuration management
 baselines and traceability
CMM-L2: Requirements Management
(RM)
CMM-L2: Software Project Planning
(PP, SPP)
CMM-L2: Software Project Tracking and
Oversight (PT, PTO)
CMM-L2: Software Subcontract
Management (SM)
CMM-L2: Software Quality Assurance (QA,
SQA)
CMM-L2: Software Configuration
Management (CM, SCM)
Objectives of Key Process
Areas
 Level Three
 Organization process focus
 coordinating and improving the
organization's process
 Organization process definition
 institutionalize process data, criteria,
training, etc
 Training program
 develop skills to perform roles
 Integrated software management
 integrate development and management
activities into a coherent software process
(followup to level 2 tracking)
 Software product engineering
 describe technical activities (e.g. write the
SRS, design, coding, etc)
 Intergroup coordination
 the development teams talks with
engineering, marketing, etc
 Peer Reviews
 remove defects
CMM-L3: Organization Process Focus (PF,
OPF)
CMM-L3: Organization Process Focus (PF,
OPF) (cont..)
CMM-L3: Organization Process Definition
(PD, OPD)
CMM-L3: Training Program (TP)
CMM-L3: Integrated Software Management
(IM, ISM)
CMM-L3: Software product Engineering (PE,
SPE)
CMM-L3: Intergroup Coordination (IC)
CMM-L3: Peer Reviews (PR)
Objectives of Key Process
Areas
 Level Four
 Quantitative process management
 notice when performance falls outside of
expected bounds
 Software Quality Management
 quality goals, supported by plans
CMM-L4: Quantitative Process Management

(QP, QPM)
CMM-L4: Software Quality Management
(QM, SQM)
Objectives of Key Process
Areas
 Level Five
 Defect prevention
 identify causes of defects and
prevent them from recurring
 Technology change
management
 identify, evaluate, and
integrate beneficial
technologies
 Process change management
 continuous process
improvement
CMM-L5: Defect Prevention (DP)
CMM-L5: Technology Change Management
(TM, TCM)
CMM-L5: Process Change Management (PC,
PCM)
 Defect prevention
Examples of Key Technology change management
Process change management
Process Areas
by maturity level Quantitative process management
Software Quality Management

Organization process focus

Organization process definition
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer Reviews

Requirements management
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software Configuration management
 Process Area: Software Quality
Assurance
Goals
Goal 1 - Software quality assurance activities are planned.
Goal 2 - Adherence of software products and activities to the
applicable standards, procedures, and requirements is
verified objectively.
Goal 3 - Affected groups and individuals are informed of
software quality assurance activities and results.
Goal 4 - Noncompliance issues that cannot be resolved within
the software project are addressed by senior
management.
 Process Area: Software Quality
Assurance
1. Commitment to Perform
Commitment 1 - The project follows a written organizational policy
for implementing software quality assurance
(SQA).

This policy typically specifies that:

1. The SQA function is in place on all software projects.
2. The SQA group has a reporting channel to senior
management…
3. Senior management periodically reviews the SQA activities
and results.
 Process Area: Software Quality
Assurance
2. Ability to Perform
Ability 1 - A group that is responsible for coordinating and
implementing SQA for the project exists.
 The group can be one person.

Ability 2 - Adequate resources and funding are provided for

performing the SQA activities.
Ability 3 - Members of the SQA group are trained to perform
their SQA activities.
Ability 4 - The members of the software project receive
orientation on the role, responsibilities, authority,
and value of the SQA group.
 Process Area: Software Quality
Assurance
3. Activities Performed
Activity 1 -- A SQA plan is prepared for the software project according to a
documented procedure.
Activity 2 -- The SQA group's activities are performed in accordance with the SQA
plan.
Activity 3 -- The SQA group participates in the preparation and review of the project's
software development plan, standards, and procedures.
Activity 4 -- The SQA group reviews the software engineering activities to verify
compliance.
Activity 5 -- The SQA group audits designated software work products to verify
compliance.
Activity 6 -- The SQA group periodically reports the results of its activities to the
software engineering group.
Activity 7 -- Deviations identified in the software activities and software work products
are documented and handled according to a documented procedure.
Activity 8 -- The SQA group conducts periodic reviews of its activities and findings with
the customer's SQA personnel, as appropriate.
 Process Area: Software Quality
Assurance
4. Measurement and Analysis
Measurement 1 - Measurements are made and used to
determine the cost and schedule status of
the SQA activities.
 Process Area: Software Quality
Assurance
5. Verifying Implementation
Verification 1 - The SQA activities are reviewed with senior
management on a periodic basis.
Verification 2 - The SQA activities are reviewed with the
project manager on both a periodic and event-
driven basis.
Verification 3 - Experts independent of the SQA group
periodically review the activities and software
work products of the project's SQA group.
Examples of Key Defect prevention
Technology change management
Process change management
Process Areas
by maturity level Quantitative process management
Software Quality Management

Organization process focus

Organization process definition
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer Reviews

Requirements management
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software Configuration management
Thank You