Software Process Improvement


Software quality and process
improvement with ISO-9000 and SEI
CMM


Kemerer-1997, Paulk-1996

Ali Arya, 2003 Software Project Management, Process Improvement Slide 1

Software Development Process

Process: A set of partially ordered steps intended
to reach a goal with supporting inputs, outputs,
constraints and resources (agents and tools), and
possibly multiple levels of abstraction.

Software development process goals
• High quality
• Low cost
• On-time delivery
• Other political/technological or market considerations

IEEE 1074, ISO 12207, and IEEE/EIA 12207

Ali Arya, 2003 Software Project Management, Process Improvement Slide 2

Ideal Software Process

Predictable
• Consistency in cost/schedule estimates
• Meeting quality and functionality requirements

Defined/Standardized
• Independent of individuals
• Repeatable

Statistically Controlled
• Measurement
• Insight
• Optimization

Ali Arya, 2003 Software Project Management, Process Improvement Slide 3

Quality and Process Standards

ISO 9000 (general)
• Family of Quality Management standards from International
Standardization Organization

TQM (general)
• Total Quality Management
• Canada's CAE, Europe's BEA, and USA's MBNQA

SEI CMM (software-specific)
• Software Engineering Institute set of Capability Maturity Models

ISO 15504, SPICE (unofficial, software-specific)
• Common base for process improvement models like CMM

Others (software-specific)
• Trillium, Bootstrap, …

Ali Arya, 2003 Software Project Management, Process Improvement Slide 4

ISO 9000 Principles

Customer focus

Leadership

Involvement of people

Process approach

System approach to management

Continual improvement

Factual approach to decision making

Mutually beneficial supplier relationships

Ali Arya, 2003 Software Project Management, Process Improvement Slide 5

ISO 9000 Family

ISO 9000
• Fundamentals and vocabulary

ISO 9001
• Requirements
• The only standard in the ISO 9000 family against which third-party
certification can be carried.

ISO 9002
• Models for quality assurance in production, installation, and servicing

ISO 9003
• Models for quality assurance in final specification and test

ISO 9004
• Guidelines for performance improvements

Ali Arya, 2003 Software Project Management, Process Improvement Slide 6

ISO 9000-3: Software

Guidelines for the application of ISO 9001 to
development, supply, and maintenance of
software
• ISO 9000-1 is the basic concepts
• ISO 9000-2 is Guidelines for application of 9001/2/3

Translating ISO 9001 guidelines to software
development with specific considerations

Sections do not always correspond to ISO 9001
in a one-to-one way but cross references are
available

Ali Arya, 2003 Software Project Management, Process Improvement Slide 7

ISO 9000-3 Outline
4. Framework 5. Life-cycle Activities
Management responsibility Contract
Quality system Planning
Internal quality audits Design and development
Corrective actions Testing and acceptance

6. Supporting Activities Maintenance

QA, Document Control 1. Scope

Training, Tools 2. References

Measurement, Purchasing 3. Definitions

Ali Arya, 2003 Software Project Management, Process Improvement Slide 8

ISO 9000-3 Excerpts

5.4.2.1 Development Phases
• The development plan should define a disciplined process or
methodology for transforming the purchaser’s requirements
specification into a software product. …

5.6.2 Design
• In addition to the requirements common to all the development
phases, the following aspects inherent to the design activities
should be examined:
» Identification of design considerations, …
» Design methodology, …
» Use of past design experiences, …
» Subsequent processes, …

Ali Arya, 2003 Software Project Management, Process Improvement Slide 9

Total Quality Management

Started in 80s and became popular in 90s

Considered a superset of ISO 9001 with a process
model/approach

Total
• Quality involves everyone and all activities in the company.

Quality
• Conformance to Requirements (meeting customer requirements).

Management
• Quality can and must be managed.

TQM
• A process for managing quality; a philosophy of perpetual
improvement in everything organization does.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 10

TQM Principles

Quality can and must be managed.

Everyone has a customer and is a supplier.

Processes, not people are the problem.

Every employee is responsible for quality.

Problems must be prevented, not just fixed.

Quality must be measured.

Quality improvements must be continuous.

Life cycle costs, not front end costs.

Management must be involved and lead.

Plan and organize for quality improvement.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 11

CMM History

1982, US DoD joint task force to review the software
problems

One of the resulting initiatives was the Software
Engineering Institute (SEI)

1984, SEI was established at Carnegie Mellon University
• Its purpose; to address the need for improved software in DoD
operations

SEI developed the Software Process Maturity Model for
DoD and industry

1991, the Capability Maturity Model (CMM) was created

Ali Arya, 2003 Software Project Management, Process Improvement Slide 12

CMM/TQM Alignment

Ali Arya, 2003 Software Project Management, Process Improvement Slide 13

Deming Chain Reaction

Ali Arya, 2003 Software Project Management, Process Improvement Slide 14

Capability Maturity Models

CMMI, Capability Maturity Model Integration

SW-CMM, Capability Maturity Model for Software

P-CMM, People Capability Maturity Model

SA-CMM, Software Acquisition Capability Maturity
Model

SE-CMM, Systems Engineering Capability Maturity
Model

IPD-CMM, Integrated Product Development Capability
Maturity Model

Ali Arya, 2003 Software Project Management, Process Improvement Slide 15

Maturity Concepts

Software process
• a set of activities, methods, practices, and transformations that people
use to develop and maintain software and the associated products

Software process capability
• the range of expected results that can be achieved by following a
software process

Software process performance
• the actual results achieved by following a software process.

Software process maturity
• the extent to which a specific process is explicitly defined, managed,
measured, controlled, and effective (implies a potential for growth in
capability and indicates both the richness of process and the
consistency with which it is applied

Ali Arya, 2003 Software Project Management, Process Improvement Slide 16

Institutionalization

As a software organization gains in software
process maturity, it institutionalizes its software
process via policies, standards, and organizational
structures.

Institutionalization entails building an
infrastructure and a corporate culture that
supports the methods, practices, and procedures
of the business so that they endure after those
who originally defined them have gone.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 17

SW-CMM Levels

Software
Process
Maturity
Levels

Ali Arya, 2003 Software Project Management, Process Improvement Slide 18

SW-CMM Levels

Initial
• The software process is characterized as ad hoc, and occasionally even
chaotic. Few processes are defined, and success depends on individual
effort and heroics.

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.

Defined
• Management and engineering activities are documented, standardized,
and integrated into a family of standard software processes for the
organization. Projects use a tailored version of the organization’s
standard software processes for developing and maintaining software.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 19

SW-CMM Levels

Managed
• Detailed measures of the software process and product quality
are collected. Software processes and products are
quantitatively understood and controlled.

Optimizing
• Continuous process improvement is facilitated by quantitative
feedback from the process and from piloting innovative ideas
and technologies.

Level 4 and 5 are usually considered “high
maturity” levels
• 9% in SEI database of 1012 organizations, as of March 2001.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 20

Process Capability vs. Maturity

Ali Arya, 2003 Software Project Management, Process Improvement Slide 21

Key Process Areas

Ali Arya, 2003 Software Project Management, Process Improvement Slide 22

CMM Structure

Ali Arya, 2003 Software Project Management, Process Improvement Slide 23

KPA Goals

L-2, requirements management
• Controlled requirements as baseline for activities
• Consistent plans, procedures, and activities

L-2, project planning
• Documented estimates
• Planned activities
• Agreed commitments

L-2, software tracking and oversight
• Results tracked against plans
• Corrective actions
• Agreed changes to commitments

Ali Arya, 2003 Software Project Management, Process Improvement Slide 24

KPA Goals

L-2, subcontract management
• Qualified subcontractors selected by prime contractor
• Agreed commitments
• Ongoing communications
• Performance tracking

L-2, quality assurance
• Planned QA activities
• Verified adherence to procedures
• Informed groups and individuals
• Noncompliant issues addressed by project members or senior management

L-2, configuration management
• CM activities planned
• Identified, controlled, and available items
• Change control
• Groups informed of status and content of baselines

Ali Arya, 2003 Software Project Management, Process Improvement Slide 25

KPA Goals

L-3, organization process definition
• Standard software process
• Available information

L-3, organization process focus
• Coordinated development and improvement activities
• Process standard used to identify strengths and weaknesses
• Planned organization-level improvement activities

L-3, Training
• Planned training activities
• Necessary trainings received

Ali Arya, 2003 Software Project Management, Process Improvement Slide 26

KPA Goals

L-3, integrated software management
• Tailored process for each project
• Projects planned and managed based on their process

L-3, software product engineering
• Defined and integrated tasks
• Consistent work products

L-3, inter-group coordination
• Agreed customer's requirements
• Agreed commitments
• Identified, tracked, and resolved inter-group issues.

L-3, peer review
• Planned activities
• Identified and removed defects

Ali Arya, 2003 Software Project Management, Process Improvement Slide 27

KPA Goals

L-4, quantitative process management
• Planned activities
• Quantitative performance control for project processes
• Quantitative identification of standard process capabilities

L-4, software quality management
• Planned activities
• Measurable quality goals
• Quantified and managed progress

Ali Arya, 2003 Software Project Management, Process Improvement Slide 28

KPA Goals

L-5, defect prevention
• Planned activities
• Identified common causes of defects
• Prioritized and removed causes

L-5, technology change management
• Planned activities
• Evaluated effect on quality
• Transferred into normal practice if appropriate

L-5, process change management
• Planned activities
• Organization wide participation in process improvement
• Standard and project processes continuously improved

Ali Arya, 2003 Software Project Management, Process Improvement Slide 29

KPA Common Features

Commitment to perform
• Senior management policies

Ability to perform
• Training, special skills & tools

Activities performed
• Plans and procedures

Monitoring
• Measurement and analysis

Verification
• Reviews and audits

Ali Arya, 2003 Software Project Management, Process Improvement Slide 30

Examining Maturity Level

CMM Assessment
• Voluntary and confidential
• Inspects the organization-wide capability/maturity
• Done by senior professionals and one or two coach
» Coaches are from SEI or an SEI-licensed assessment vendor

CMM Evaluation
• Open to external inspecting body
• Usually for getting a contract
• Done by external contractor
• Very judgemental and stressful

Ali Arya, 2003 Software Project Management, Process Improvement Slide 31

CMM Assessment

Procedure
• Obtain commitment of organization
• Preparation
• Assessment conduct (interview, data collection, analysis)
» Usually in 3 or 4 days
• Briefing and reporting
• Action plan development
• Follow-up

Teams/Personnel
• Assessment team
• Senior management
• Software project managers (SPMs)
• Functional area representatives (FARs)
» Developers, QA and CM engineers, members of Software Engineering
Process Group (SEPG)

Ali Arya, 2003 Software Project Management, Process Improvement Slide 32

Maturity Levels in Industry

Late 90s, US software sites
• 75% at level 1
• 15% at level 2
• 9% at level 3
• 1% at levels 4 or 5

Oct. 2002 SEI list (# sites at level 4/5)
• Australia, 2/0
• Canada, 0/1
• China, 0/2
• India, 27/50
• USA, 39/20
• …

Ali Arya, 2003 Software Project Management, Process Improvement Slide 33

CMM Criticism

Subjective, binary, and intrusive evaluation

Different approached for different organizations
• Answer: CMM does not specify methods, just criteria

No proper integration with TQM

Unrealistic and skewed levels

Cost of moving from one level to another

Large companies with traditional process model
• See CMM-XP paper !

Ali Arya, 2003 Software Project Management, Process Improvement Slide 34

Quality Assurance Techniques

Audits, evaluations, and corrective actions by
SQA (CMM L-2)

Error detection and defect removal via testing and
peer reviews (CMM L-3)

Fault tolerance and error recovery (CMM L-3)
• Repeatable and effective software engineering processes

Measurement, and defect prevention (CMM L-4
and L-5)
• Analysis of defect trends for needed improvements

Ali Arya, 2003 Software Project Management, Process Improvement Slide 35

Software Review

Data shows that it is much more efficient to find defects
in reviews than in testing
• Unit test: ~ 2 to 4 defects / hour
• Code review: ~ 10 defects / hour
• Experienced reviewers: can yield 70% or more

Typical time to find and fix defects
• Integration & test: 10 to 40 hrs / defect
• Inspection: typically less than 1 hr / defect

Review does not have to be inspection
• Informal vs. formal

Record time, defects found, and material reviewed
• Metrics: defect density, detection rate, average time, …

Ali Arya, 2003 Software Project Management, Process Improvement Slide 36

CMM and ISO-9000

Different structure but strong correlation

CMM emphasizes on continuous process
improvement.

ISO 9000 defines minimum requirement for an
acceptable quality system.

Documentation and meeting quality requirements
are important similarities.

Cross references exist.
• See comparison article !

Ali Arya, 2003 Software Project Management, Process Improvement Slide 37

CMM and Extreme Programming

Extreme Programming (XP) is a methodology
based on the concept of evolutionary software
development.

XP is mainly initiated and used for the high-
speed, volatile world of Internet and Web
software development.

XP is used in arguments against “rigorous”
software process improvement models like
CMM.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 38

XP Basics

Small to medium-sized teams
• Fewer than 10

Vague and/or rapidly changing requirements

Iterative life cycle with short cycles
• Activities: coding, testing, listening, and designing.

Delivery of very small increments of functionality, a.k.a
“stories”

continual communication
• With the customer and within the team;

Simplicity (minimalist solutions)

Ali Arya, 2003 Software Project Management, Process Improvement Slide 39

XP Practices

Planning game

Small releases

Metaphor
• simple shared view of system

Simple design

Continuous integration and testing

Refactoring
• Restructure the system without changing its behavior

Pair programming and Coding standards

Collective ownership

Onsite customer

Ali Arya, 2003 Software Project Management, Process Improvement Slide 40

XP and Level-2 KPAs

Largely addressed by XP
• Requirement management (stories, on-site customer, and
continuous integration)
• Planning (planning game and small releases)
• Tracking and oversight (project velocity and small releases)

Partially addressed by XP
• Quality assurance (pair programming)
• Configuration management (collective ownership, small
releases, and continuous integration)

Not addressed by XP
• Subcontracting

Ali Arya, 2003 Software Project Management, Process Improvement Slide 41

XP and Level-3 KPAs

Largely addressed by XP
• Software product engineering (metaphor, simple design,
refactoring, coding standards, and testing)
• Intergroup coordination (on-site customer, pair programming)
• Peer reviews (pair programming)

Partially addressed by XP
• Organization process focus (team level)
• Organization process definition (life cycle)

Not addressed by XP
• Training program
• Integrated software management

Ali Arya, 2003 Software Project Management, Process Improvement Slide 42

XP-CMM Interplay

XP is complementary to CMM concepts, even if
they do not completely address them.
• CMM: what-to-do in general terms,
• XP: how-to for some specific cases

XP generally focuses on technical work, whereas
the CMM generally focuses on management
issues.

Lack of “institutionalization” in XP

XP is hard to implement when project size grows.

Ali Arya, 2003 Software Project Management, Process Improvement Slide 43