This document discusses software engineering processes and quality. It covers the contemporary quality movement which emphasized top management buy-in, education, and statistical methods. It also discusses how manufacturing quality processes were applied to software development through defined processes, standards, and quality assurance organizations. The goal of processes is to determine the quality of software through the quality of the development and maintenance process used. Classical software development saw it as a technical activity while contemporary views see it as requiring defined processes.

1. CPSC4175
Intro to Software Engineering
Neal Rogers
Process Foundations

2. • Lesson: Process Raison d’être
• Strategic Objective: understand the rationale of
using processes
• Tactical Objectives:
– know the work of the contemporary quality movement
– Know how manufacturing processes have been applied
to software
– Know the contemporary and classical schools of SwE
– Understand the purpose and benefits of processes
– Be able to identify “ingredients” of a process
– Know the common processes currently in use
– Understand the difference between a process model and
a model process
– Understand the Capability Maturity Model (Integrated) for
Software; know the model’s key processes

3. • Support material:
– Text 2, 3
– Readings 2, 3, and 4
– References 1, 2, 3, 8, and 9
• Immediate-use skills provided
– interview buzzwords
• References:
– CMMI Product Team 2002. Capability Maturity Model Integration
(CMMISM), Version 1.1. CMU/SEI-02-TR-01, 02-TR-28, 02-TR-29.
Software Engineering Institute.
– IEEE. 1997. IEEE Standard for Developing Software Life Cycle
Processes. IEEE Std 1074-1997.
– Paulk, M. et al. 1993. Capability Maturity Model for Software,
Version 1.1. CMU/SEI-93-TR-24. Software Engineering Institute.
– Schmauch, C. 1995. ISO 9000 for Software Developers. Revised
edition. ASQC Quality Press.
– Schulmeyer, G. G. 1987. Software quality lessons from the quality
experts. From Handbook of Software Quality Assurance. Van
Nostrand Reinhold. pp. 25-45.

4. Syllabus
• Software engineering raison d’être
• Process foundations  Process foundations
• Common process elements  Industrial quality movement
• Conceptual design  Software quality movement
• Size estimation
 Processes a la SwE
 Classical school
• Task decomposition  Contemporary school
• Scheduling  Processes explored further
• Measurements  Processes rationale
• Reviews  Function of processes
• Technical templates  Process model
• Scaling up  Process Models
 Introduction
• Misc processes  Sample models
• Process descriptions
• Infrastructure
• Retrospective

5. Discussion point …
How do we ensure the quality* of
software?
quality = software meeting customer needs, known
*
software characteristics (e.g., defects, performance,
content)

6. Follow-up point …
What stands in the way of your
achieving “quality” the first time, every
time?

7. Contemporary Quality Movement
• Kaoru Ishikawa
– company-wide quality control
– top management buy-in
– industrial education and training
– application of statistical methods
• Joseph Juran
– structured approach to manufacturing:
• study the symptoms of the defects and failures
• develop a theory on the causes of these symptoms
– specifically, examine worker-controllable vs management-
controllable aspects
• test the theory until the causes are known
• stimulate remedial action

8. Contemporary Quality Movement
• W. Edwards Deming
– statistical control
– common method of attacking and describing problems
• P-D-C-A approach
– plan
– do
– check A C
– analyze
P D

9. Contemporary Quality Movement
• W. Edwards Deming (con’t)
– 13 pts
• create constancy of purpose for improvement
• adopt the new philosophy
• cease dependence on mass inspection
• end the practice of awarding business on price tag alone
• improve constantly the system of production and service
• institute training and retraining
• institute leadership
• drive out fear
• break down barriers between staff areas
• eliminate slogans, exhortations, and targets
• remove barriers to pride of workmanship
• institute a vigorous program of education and retraining
• take action to accomplish transformation

10. Contemporary Quality Movement
• Philip Crosby
– guiding principles:
• “quality is conformance to requirements”
• “quality is free, but only to those who are willing to pay heavily
for it.”
– Quality management maturity grid
• 5 levels of maturity: uncertainty, awakening, enlightenment,
wisdom, certainty
• 6 measurement categories
– management understanding
– quality organization status
– problem handling
– cost of quality as % of sales
– quality improvement actions
– summation of company quality posture

11. Stage I: Uncertainty
• Management understanding and attitude
– No comprehension of quality as a management tools. Tend to
blame quality dept for “quality problems”
• Quality organization status
– Quality is hidden in manufacturing or engineering departments.
Inspection probably not part of organization.
• Problem handling
– Problems are fought as they occur; no resolution; inadequate
definition; lots of yelling and accusations.
• Cost of quality as % of sales
– Reported: unknown
– Actual: 20%
• Quality improvement actions
– No organized activities. No understanding of such activities
• Summation of company quality posture
– “We don’t know why we have problems with quality.”

12. Stage II: Awakening
• Management understanding and attitude
– Recognizing that quality mgmt may be of value but not willing to
provide money or time to make it happen
• Quality organization status
– A stronger quality leader is appointed but main emphasis is still
on appraisal and moving the product. Still part of manufacturing
or other
• Problem handling
– Teams are set up to attack major problems. Long-range
solutions are not solicited.
• Cost of quality as % of sales
– Reported: 3%
– Actual: 18%
• Quality improvement actions
– Trying obvious “motivational” short-range efforts
• Summation of company quality posture
– “Is it absolutely necessary to always have problems with
quality?””

13. Stage III: Enlightenment
• Management understanding and attitude
– While going thru quality improvement program learn more about
quality management
• Quality organization status
– Quality dept reports to top management
• Problem handling
– Corrective action communication established. Problems are
faced openly and resolved in an orderly way.
• Cost of quality as % of sales
– Reported: 8%
– Actual: 12%
• Quality improvement actions
– Implementation of a specified quality program with thorough
understanding of each step
• Summation of company quality posture
– “Through management commitment and quality improvement we
are identifying and resolving our problems.”

14. Stage IV: Wisdom
• Management understanding and attitude
– Participating. Recognize their personal role in continuing
emphasis
• Quality organization status
– Quality manager is officer of company
• Problem handling
– Problems identified early in their development. All functions open
to suggestion and improvement
• Cost of quality as % of sales
– Reported: 6.5%
– Actual: 8%
• Quality improvement actions
– Continuing specific quality program
• Summation of company quality posture
– “Defect prevention is a routine part of our operation.”

15. Stage V: Certainty
• Management understanding and attitude
– Consider quality management an essential part of company
system
• Quality organization status
– Quality manager on board of directors. Prevention is main
concern. Quality is a thought leader.
• Problem handling
– Except in the most unusual cases, problems are prevented.
• Cost of quality as % of sales
– Reported: 2.5%
– Actual: 2.5%
• Quality improvement actions
– Quality improvement is a normal and continued activity
• Summation of company quality posture
– “We know why we do not have problems with quality.”

16. Quality Movement wrt Software
• Lennart Sandholm
– quality policy
• statement of corporate-wide commitment to quality
• promulgated by senior software executive
– quality objectives
• statements of measurable improvements
• e.g., number of errors per thousand LOC
– quality system
• used to achieve the quality objectives
• e.g., standards, procedures, etc.
– quality assurance organization
• facilitating body
• may process and/or product oriented

17. Premise that has evolved:
• The quality of a product is largely determined
by the quality of the process that is used to
develop and maintain it.

18. Ghost of SwE Past
• Classical software development philosophy
– tenets:
• software engineering = building software = technical activity
• grab-bag of disjoint technical actions
• software projects can be orchestrated no differently than
other projects in other fields
Technical Identify Synthesize Articulate Interpret T
=
O
+ O
L
S
Product
People Plan Organize Staff Direct Control

19. Ghost of SwE Present (sorta)
• Contemporary software development philosophy
– tenets
• software engineering = technical facets + managerial facets
orchestrated by process
• focus on process activities
– teach the troops correct principles and they will govern
themselves
– Humphrey [1995]:
» “The quality of software is governed by the quality of
its worst components.”
» “The quality of a software component is governed by
the individuals who developed it.”
– teams with comprehensive processes are more likely to
contain cost and ensure quality than those without
– processes can exist on a project-by-project basis, but are
leveraged best on an organization-wide basis

20. SwE now (sorta)
• Contemporary software development philosophy
(con’t)
– hence
Technical Identify Synthesize Articulate Interpret
T
Product
=
O
People Plan Organize Staff Direct Control
+ O
L
S
with
known
“quality”
Process Lifecycle Product Property Success Infra

21. Processes Explored Further
• Process
– ... is the set of all enterprise tasks needed to produce
software
– ... “sets out the technical and management framework
for applying methods, tools, and people.”
[Humphrey 1995]
– our goal: use process measurements and controls to
guide production
Consider: Example: % of PROJECT
requirements allocated to
software: *
Process 1
Process 2
Process 3
Process 4
Process n
• B-2 -- 65%
• F-22 -- 80%

22. Process Rationale
• Processes help ...
[Humphrey1995]
– ... identify the principal activities of doing a job
– ... separate routine from complex tasks
– ... establish starting and stopping criteria
– ... facilitate tracking progress and measuring
performance
– ... judge accuracy of work projections
– ... provide orderly mechanism for learning
– ... establish corporate memory of necessary activities
– ... create a defined baseline for improvement

23. Example Process
• PSP0 process script
• Problem description
Entry • Defect standard type
• Produce a requirements statement
Planning • Estimate and record the required development time
• Record time spent planning
T
a • Design the program
s • Implement the design
k Development • Compile program; fix and log all defects found
s • Test the program and fix and log all defects found.
• Record time spent in development
Postmortem • Calculate and record performance statistics
• Tested program
Exit • Completed plan, defect log, time log

24. Processes Explored Further
• Function of processes: engineering insight
IN OUT
OUT
increasing sophistication
IN
    
OUT
IN
        
OUT
IN
        
OUT
IN
        
[Paulk et al 1993a]

25. Processes Explored Further
• Function of processes: enhance predictability
planned delivery
Well-defined processes
Ad hoc processes
probability
time
[Paulk et al 1993a]

26. Empirical evidence
140% Before After
Over/Under Percentage
0%
.
. . . . . . . .. . . ..... ..................... ................ .
. . . ... . . . .. .. .. .... . . .
. . . .
. ... . . . .
. . . .. .. . ...
. .. .. .
. . ..... ... .. . .
. ... . . . . . .
.
. . .... . .. . . . .
.. . . . ..... ... .
. .
. . .. .. .... .. . . . .
-140% .. ... .
Without Historical Data With Historical Data
Variance between + 20% to - 145% Variance between - 20% to + 20%
(Mostly Level 1 & 2) (Level 3)
(Based on 120 projects in Boeing Information Systems)
Reference: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.”
7th SEPG Conference, San Jose, March 1997.

27. Historical Perspective certification (i.e.,
physical rigorous examination of
laws end product)
codes
Software
X* Engineering
Engineering
guarantors of
guarantors of
quality
quality
mathematical analysis process (i.e., the way in
which we build the
* where X = civil, mechanical, electrical, etc.
software)
Traditional engineering focuses on the product; software
engineering focuses on the process of building the product

28. Historical Perspective
?
No process Process

29. Process Darwinism
Heavy-weight Light-weight
processes processes
IEEE 1074, CMM, ISO 9001 XP, Scrum, ASD, FDD
requirements containment vs
requirements adaptation
design-oriented vs
construction-oriented
predictive vs
adaptive

30. Common Processes
• Pre-defined processes (a.k.a. model processes)
– MIL-STD 2167A
– MIL-STD-498 -> IEEE 12207.0
– IEEE 1074
– XP
– NASA xxx, Boeing xxx, etc., etc.
• Process model
– “a structured collection of elements that describe
characteristics of effective processes” - SEI
– Examples
• ISO 9001
• CMMI (Capability Maturity Model – Integrated)
• SPICE (Software Process Improvement and Capability
dEtermination … ISO/IEC TR 15504)

31. Common Process Model Ingredients
• life cycle model
– sequence of technical tasks required to produce a
product (e.g., analysis, design, code, test, etc.)
• product model
– tasks needed to produce an artifact in a specific form
• property model
– tasks needed to attain desired cost, schedule,
security, reuse, etc.
• success model
– tasks needed to assure and assess correctness
• infrastructure model
– administrative tasks needed to ensure day-to-day
activities are carried out

32. Samples
• MIL-STD-2167A
– Planning, management, engineering procedures,
standards, quality, configuration management
req
design code test
analysis
interface preliminary detailed
design design design

33. Samples
• MIL-STD-2167A (con’t)
Preliminary design process
• develop prelim design
• develop interface design
• document rationale
• establish test requirements
• allocate/document FQT
• evaluate design docs
• baseline design docs
• conduct PDR

34. Samples
• IEEE Std 1074-1997
– … “provides a set of Activities that constitute the
Processes that are mandatory for the development
and maintenance of software” [IEEE 1997]
– Processes:
• Software life cycle model process • Post-development processes
Software life cycle model installation
• Project management processes operation and support
project initiation maintenance
project monitoring and control
retirement
software quality management
• Pre-development processes • Integral processes
concept exploration verification and validation
system allocation software configuration
• Development processes management
requirements documentation development
design training
implementation

35. Samples
• Extreme Programming (XP)
De
lue Customer f in
va e
va
ild lu
Bu user es
test first, storie
sds, CM s
Developer Developer
spike estimation
solution via risk,
priority
st
Ch
co
oo
e
se
at
tim
Customer
va
Es
lue

36. Samples
• ISO 9000 [Schmauch 1995]
– … defines minimum process requirements that must
be met to ensure quality
– … is a framework: states what, not how
– written originally for manufacturing, but also applied to
software

37. Samples
• ISO 9000 (con’t)
– collection of individual, but related standards
• 9000-1 Guidelines for selection and use
• 9000-3 Guidelines for application of 9001 to software
• 9001 Model for quality assurance in design,
development, production, installation, servicing
• 9002 Model for QA in production, installation, servicing
• 9003 Model for QA in final inspection and test
• 9004 Guidelines for interpretation of 9001, 9002, 9003
9003
9002
9001
Req Design Code Test Install Maint

38. Samples
• ISO 9000 (con’t)
– 9001 Processes (interpreted through 9000-3)
• Framework
management responsibility • Supporting activities
quality system config management
internal quality system audits document control
corrective action
quality records
• Life cycle activities
measurement
contract review
purchaser’s requirements spec rules, practices, and
development planning conventions
quality planning tools and techniques
design and implementation purchasing
testing and validation included software
acceptance product training
replication, delivery, and installation
maintenance

39. Samples
• Capability Maturity Model (Integrated)
– Basics
• … gauges organizations’ ability to predict and control software
activities
• identifies processes necessary for software production
• provides a framework for measuring production
capability
– Views
• continuous
– Q: how well am I performing software functions?
• staged
– Q: how well can I control cost, schedule, performance?
– Misc
• is called “integrated” because it is integrated with other CMMs

40. CMMI – Process Areas
Category Process Area
Project Planning
Project Project Monitoring and Control
Management Supplier Agreement Management
Integrated Project Management
Integrated Supplier Management
Integrated Teaming
Risk Management
Quantitative Project Management
Support Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Causal Analysis and Resolution
Decision Analysis and Resolution
Organizational Environment for Integration
Engineering Requirements Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Process Organizational Process Focus
Management Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment

41. capability
0
1
2
3
4
5
Samples
process area 1
• CMMI (con’t)
process area 2
process area 3
process area 4
– continuous representation
process areas
…
process area n

42. CMMI process areas – staged
Level Focus Process Areas
Continuous Organizational Innovation and Deployment
5 Optimizing process Causal Analysis and Resolution
improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed management Quantitative Project Management
Requirements Development
Technical Solution
Product Integration
Verification
Process Validation
3 Defined standardization Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Integrated Supplier Management
Risk Management
Decision Analysis and Resolution
Organizational Environment for Integration
Integrated Teaming
Basic Requirements Management
2 Managed project Project Planning
management Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
1 Performed

43. Samples
• CMMI (con’t)
– staged representation
Focus on process
is k
en ity; 5 Optimized improvement
tr
em bil
ag cta
4 Quantitatively
an di
Process matured
m pre
Managed and controlled
sin ing
ea as
g
c r re
3 Defined Process at org level
de inc
Process at project
2 Managed level
1 Performed Process ad hoc
0 Not Performed No process

44. Empirical Data

45. Samples
• PSP
– instantiation of CMMI for small organizations
– includes:
• measurement and analyses framework to help characterize
processes
• defined procedure to help improve performance
– CPSC4175 approach
• introduce PSP in several upwardly compatible steps
• write small programs at each step
• gather and analyze data on work
• use data and analyses to gain insight into process
management
• scale up to multiple person efforts (CPSC4176)

46. TSP
Samples Team coordination
• PSP (con’t)
PSP3
Cyclic development
PSP2
Code reviews
Design reviews
PSP1 PSP1.1
Size estimating Task planning
Test report Schedule planning
PSP0
Current process PSP0.1
Time recording Coding standard
Defect recording Size measurement
Defect type standard

47. Summary Key Points
Topics • The manufacturing community
• Process foundations discovered processes long ago
• Processes a la SwE • SwE then = technical activities
• Processes explored SwE now = process orientation
• Process Models
• A process is a set of enterprise
tasks
• Processes have benefits: most
notable is management
containment
• Process models describe what to
do; model processes describe
Next time: Common how to do it. Many exist
process
elements