Ch 7 - Quality Management
Learning Objectives
You should be able to:
 List and explain common principles of quality
management (QM)
 List, distinguish between, and describe the processes
and tools of Quality Planning, Assurance, and Control
 Apply QM principles to Project Management
 Apply QM principles to software development project
management
 Demonstrate how the CMM incorporates QM
principles
Quality:








is everyone’s job,
comes from prevention not inspection,
means meeting the needs of customers,
demands teamwork,
requires continuous improvement,
involves strategic planning,
means results,
requires clear measures of success.
History of QM/QC/QA




Deming: plan, do, check, act
Juran: improvement, planning, control
Crosby: zero defects, management commitment
Ishikawa

quality circles, root cause of problems
 Taguchi: prevention vs. inspection
 Feigenbaum: worker responsibility
Quality Management





Organization-wide commitment: culture
Results and measurement focus
Tools and technical support needed
Training and learning
Continuous improvement of each process


Is it necessary?
Can it be done better?
7 Malcolm Baldrige Award
Categories
Pre-production



leadership
information and
analysis
strategic quality
planning
Production


human resource
allocation
quality
assurance
Post-production


quality results
customer
satisfaction
ISO 9000 Standard:
5 Elements (500 points)





Quality Planning
Performance Information
Cost of Quality (economics)
Continuous Improvement
Customer Satisfaction
Quality in Project Management I
 ISO 9000, TQM, CQI principles
 Prevention over inspection

lower cost, higher productivity, more cust. satisfaction
 Management responsibility and team participation
 Plan-do-check-act (re: Deming, etc.) - PDCA
 Applied successfully in environments that have
well-defined processes and products
 More difficult in areas like software development
Quality in Project Management II
 Customer satisfaction

validation: “the right job done”
 Conformance to specifications

verification: “the job done right”
 Fitness for use

can be used as intended
 Satisfaction of implied or stated needs


All project stakeholders considered
Project Management: making implicit needs explicit
 Project Processes and Product

continuous improvement of both
Product
Description
Quality
Standards
Project
Scope
Quality
Planning
Checklists
Quality
Management
Plan
Work Results
Quality Policy
Quality
Assurance
Operational
Definitions
Quality
Improvement
Actions
Quality
Control
Quality Planning (QP)
 Identifying relevant quality standards
 Determining how to meet them
 QP inputs:



quality policy: adopted, disseminated
scope and product description
standards, regulations
Software Quality Planning
 Functionality

features: required and optional
 Outputs
 Performance


volume of data, number of users
response time, growth rate
 Reliability: MTBF (mean time between failures)
 Maintainability
QP Outputs
 Quality management plan



how team will implement quality policy
structure, responsibilities, resources, processes
(same as project plan?)
 Operational definitions

metrics: what it is and how it’s measured
 Checklists

industry-specific
Quality Assurance (QA)
 Evaluating project performance regularly to assure
progress towards meeting standards
 Inputs:



quality management plan
operational definitions
results of measurements
 Outputs:

quality improvement actions
 Tools: QP tools, quality audits
QP/QA Tools
 Cost / benefit analysis and tradeoffs

less rework = higher productivity, lower costs,
stakeholder satisfaction
 Design of Experiments

comparison of options, approaches
 Benchmarking

comparison of project practices to best practices
 Cause and effect (fishbone, etc., diagrams)
Quality Control (QC)





Monitoring project results
Measuring compliance with standards
Determining causes if not in compliance
Identifying ways to eliminate causes
Performed throughout project life cycle
QC Inputs and Outputs
Inputs:
 Work results
 Quality Management
Plan
 Operational
Definitions
 Checklists
Outputs:
 Quality Improvement
 Acceptance decisions
 Rework
 Process adjustments

corrective or
preventive actions
 Completed checklists

project records
QC Tools
 Inspection:

measuring, examining,
testing products
 Control Charts:



monitor output
variables
detect instability in
process
graphical display of
results
 Pareto analysis


80 / 20 rule
histogram: frequencies
 Statistical sampling



acceptable deviation
6-sigma
7-run rule
Statistical Quality Control
 Prevention

keeping errors out of the process
 Inspection

keeping defects from the customer
 Sampling: attributes and variables
 Tolerances: acceptable ranges
 Control limits: acceptable levels
Testing (Software)





During most phases of product development
Unit tests
Integration testing
System testing
User acceptance testing
Improving Software Quality
 Leadership

top management and organization-wide
commitment to quality
 Costs of quality


cost of non-conformance
costs: prevention, appraisal, failures, testing
 Work environment
PMI Maturity Model: 5 levels





Ad-hoc: chaotic, chronic cost & schedule delays
Abbreviated: processes in place, but not predictable
Organized: documented, standards that are used
Managed: measures are collected
Adaptive:


feedback enables continuous improvement
project success is norm
Capability Maturity Model
(CMM) - 5 levels
1. Initial: chaotic, heroic efforts, unpredictable
2. Repeatable: processes & standards established
3. Defined: documented standards, training, use
4. Managed: quantitative measures, predictable
5. Optimizing: defect-prevention, organizationwide continuous improvement
CMM and Quality
(see Appendix A: goals for key process areas)
Level 2:
 requirements management (customer focus)
 project planning (quality planning)
 project tracking and oversight (quality
control)
 software quality assurance
 configuration management (prevention)
CMM Level 3 and Quality
 organization process focus (commitment)
 organization process definition (operational
definitions)
 training program
 software product engineering (prevention)
 intergroup organization (teamwork)
 peer reviews (teamwork)
CMM Level 4 and Quality
 Quantitative process improvement
 Software quality management goals

planned and measured
CMM Level 5 and Quality
 Defect Prevention (prevention)
 Technology and Process Change
Management (continuous improvement)
Achieving Software Quality
 Focus on critical requirements early
 Use metrics early and continuously
 Provide development tools supporting:



configuration control, change control
test automation, self-documentation
abstraction, reliability, reuse
 Early and continuous demonstration-based
evaluations
 Major milestone demonstrations assessed against
critical requirements
Software Quality Measurement
 Software quality measured by ease of change
 Examples of data collected:




Number and types of changes
number of components / effort (FPs, SLOC, classes...)
number of change orders (SCOs)
number of defective and fixed components
 Baseline: total size (SLOC, FP, classes, etc.)
 Scrap: broken code, may or may not be fixed
 Rework: healthy early in project, should decrease
SCO: Software Change Order
1. rework a poor quality component (fix)
2. rework to improve quality (enhancement)
3. accommodate new customer requirement
(scope change)
Configured Baseline:


the set of products subject to change control
size of “completed” components
Software Quality Metrics
 Modularity:

breakage localization: extent of change re: baseline size
 Adaptability

cost of change (effort needed to resolve and retest)
 Maturity

number of SCO’s over time = MTBF during testing
 Each of above 3 should decrease over time
 Maintainability

productivity of rework / productivity of development
Operational Definitions
 Defects: measured by change orders SCOs
 Open rework (breakage)

broken components measured by SCOs
 Closed rework (fixes)

fixed SCOs
 Rework effort: effort expended fixing SCOs
 Usage time: baseline testing in normal use
Quantifying Quality Metrics
 Modularity:

breakage / SCOs
 Adaptability

rework effort / SCOs
 Maturity

usage time / SCOs (mean time between defects)
 Maintainability

(percent broken) / (percent rework vs. total effort)
 End-product and “over time” indicators
Peer inspections: pros and cons
Pros
Cons
 Team development
 Superficial
 Accountability
 Not cost effective
 Determine causes of
 Other QA activities
defects
are more effective
 20%: critical components