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.
Managing A Successful Team Offline VersionDrPaulHancock
A recent presentation given, highlighting two opposing management techniques {McGregors X-Y styles} with context given ranging from the father of modern economics, Adam Smith, to the highly respected Statistician William Deming. The general approach taken seems a simplification, with perhaps a hybrid model suiting some systems, therefore due to concision , caveats are attached. The presentation is an offline version as it links into local mind mapping software, so some visuals are included as thumbnail examples of RCA tools and mind-maps drawn up from my experience working in the pharmaceutical inhalation devices industry and literature sources .
Process Approach in Total Quality ManagementJess Henson
Process Approach in Total Quality Management
- ETX Model
- 6s of Process Improvement
- Customer-Supplier Chain
- Just-In-Time
- Lean Manufacturing
- Kanban System
- Cellular Manufacturing
- Zero Defects
Managing A Successful Team Offline VersionDrPaulHancock
A recent presentation given, highlighting two opposing management techniques {McGregors X-Y styles} with context given ranging from the father of modern economics, Adam Smith, to the highly respected Statistician William Deming. The general approach taken seems a simplification, with perhaps a hybrid model suiting some systems, therefore due to concision , caveats are attached. The presentation is an offline version as it links into local mind mapping software, so some visuals are included as thumbnail examples of RCA tools and mind-maps drawn up from my experience working in the pharmaceutical inhalation devices industry and literature sources .
Process Approach in Total Quality ManagementJess Henson
Process Approach in Total Quality Management
- ETX Model
- 6s of Process Improvement
- Customer-Supplier Chain
- Just-In-Time
- Lean Manufacturing
- Kanban System
- Cellular Manufacturing
- Zero Defects
Self Management
• Comply with the Health, Safety and Environmental Policies
• Assertive, resilient and welcomes change
• Engages interest and participation of others and has a collaborative
• approach to working together Actively committed to teams development
• Is optimistic and self aware, shows moral courage, openness and honesty in all dealings
• Self-motivated, flexible, proactive and committed, good communication and interpersonal skill.
Highlights the details of Origin Metrology Group's preventive and predictive maintenance support options as well as our engineering philosophies and methodologies associated with our services.
2012 Dept. of IT Quality Circle Presentation. Silver Medal Winner at Fiji National University Annual Quality Circle Convention 2012. By Team Leader: Sudhir Mudaliar
Self Management
• Comply with the Health, Safety and Environmental Policies
• Assertive, resilient and welcomes change
• Engages interest and participation of others and has a collaborative
• approach to working together Actively committed to teams development
• Is optimistic and self aware, shows moral courage, openness and honesty in all dealings
• Self-motivated, flexible, proactive and committed, good communication and interpersonal skill.
Highlights the details of Origin Metrology Group's preventive and predictive maintenance support options as well as our engineering philosophies and methodologies associated with our services.
2012 Dept. of IT Quality Circle Presentation. Silver Medal Winner at Fiji National University Annual Quality Circle Convention 2012. By Team Leader: Sudhir Mudaliar
Making Improvement Standard: Making Agile Practices Dynamic through Lean Stan...LitheSpeed
Continuous improvement and adaptation is practically the definition of agility, but teams have to start somewhere. This session will explore how common tools like agile practice self-assessments have been combined with lean “standard work” practices to provide early agile teams with focused guidance, while encouraging them to raise their own standards as they mature and learn.
We will describe a framework for management and coaching roles involved in driving and supporting agile development efforts, based upon our experiences in both small companies and large enterprises at various stages of adoption.
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
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
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
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
Editor's Notes
from Quality is Free Studies show that better than 25% of nonmanufacturing work is reoutinely done over before it is correct. We can look at our job of managing software engineering projects as one of managing data. We recive data from someone. We decide on the basis of that data, we gransmit something along the line, and we add our two cents worth to it. If we have not made certain about what we have done, then we can set the entire chain off in the wrong direction If we as individuals were electronic components, we would determine our systemic realibility as the product of the realiability of each of the components. If you have 100 components in a circuit and each one is 99% perfect, the probability that the circuite will perform is only 35%. Our goal is to raise the reliability of each part of the “circuit board” of software engineering to increase the overall reliability of the effort. If i t is possible to get every job done right the first time, then we will be able to reduce the amount of time we waste on rework, the number of customers we disappoint, and the amount of frustration we cause ourselves personnal. We will be able to do more of the purposeful things we really like to do. I ask each group to state your biggest problem -- the thing you regard as your biggest problem in getting your work done right the first time every time.
from Quality is Free Studies show that better than 25% of nonmanufacturing work is reoutinely done over before it is correct. We can look at our job of managing software engineering projects as one of managing data. We recive data from someone. We decide on the basis of that data, we gransmit something along the line, and we add our two cents worth to it. If we have not made certain about what we have done, then we can set the entire chain off in the wrong direction If we as individuals were electronic components, we would determine our systemic realibility as the product of the realiability of each of the components. If you have 100 components in a circuit and each one is 99% perfect, the probability that the circuite will perform is only 35%. Our goal is to raise the reliability of each part of the “circuit board” of software engineering to increase the overall reliability of the effort. If i t is possible to get every job done right the first time, then we will be able to reduce the amount of time we waste on rework, the number of customers we disappoint, and the amount of frustration we cause ourselves personnal. We will be able to do more of the purposeful things we really like to do. I ask each group to state your biggest problem -- the thing you regard as your biggest problem in getting your work done right the first time every time.
company-wide quality control all departments and all levels of personnel are engaged in systematic work guided by written quality policies from upper management top management quality control audit a quality control audit team of executives visits each department to uncover and eliminate any obstacles to the productivity and quality goals industrial education and training given to everyone quality circles a small group voluntarily meeting to resolve problems, improve performance statistical methods measuring and tracking indicators of quality. Empiricism! nationwide quality control promotional activities November in Japan is Quality Month, when the Deming Prize is awarded. Ask audience to name some US quality awards (Baldridge award)
quality assurance body SEPG (process) QA group (product)
“ Teach them correct principles and they will govern themselves” W. Edwards Deming (con’t) 14 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
Note that all the items listed above describe managerial processes. The first three are used for a different purpose than the last, but all share the common characteristic of noting what needs to be done in the production of software. The first three are prescriptive in nature, the last one is descriptive. SPICE: Software Process Improvement and Capability dEtermination. IEEE 12207 MIL-STD-498 replaced by IEEE/EIA Std 12207 in May 98 IEEE/EIA 12207 12207.0 – standard for information technology. software life cycle processes 12207.1 – ditto, life cycle data 12207.2 – ditto, implementation considerations (includes all of 12207.0 plus comments on implementation of processes)
PSP0 - you establish a measured performance baseline PSP1 - you make size, resource, and schedule plans PSP2 - you practice defect and yield management PSP3 - you scale up PSP methods to larger projects