This document discusses quality management concepts as they relate to software engineering. It defines quality using perspectives from Juran and Weinberg, and discusses the three goals of projects - time, cost, and quality. It also discusses concepts like total quality management (TQM), the costs of poor quality, and factors that contribute to project success or failure based on the Standish Chaos reports. Key aspects of TQM discussed include focusing on customers and processes, basing decisions on facts, continuous improvement, and leadership commitment.

1. Software Quality Management
PA2557
Quality basics
Conny Johansson
cjh@bth.se

3. So.. What did you see?
• Young woman?
• Old woman?
• Nothing?
• Anything else?

4. Experiment on Quality 1

5. Experiment on Quality 1
• Consider some sort of text processor
• Part 1:
– Identify
• Quality characteristics
• Stakeholders

6. Editor…
End user
- User friendly

7. Editor: Quality characteristics and Stakeholders
End user Marketing
Department
Project
Manager
Developers CS
Professors
- User friendly
- Compatible with competitors
- Many features
- High performance
- 0 Defects
- Rapid development
- Low development cost
- Elegant code

8. Editor: Quality characteristics and Stakeholders –
possible answers
End user Marketing
Department
Project
Manager
Developers CS
Professors
- User friendly
- Compatible with competitors
- Many features
- High performance
- 0 Defects
- Rapid development
- Low development cost
- Elegant code
x
x
x
x x
x x x x
x
x
x
x
x
x x
x x
?
?

9. Quality!
• Juran: Quality is fitness for intended use
– Who defines fitness?
– Consider our Word processor, will it fit to
• Typical user
• Software engineer
• Sales personnel
– Users change as users grow in experience
• Consider “advanced” word processor features vs. “ease
of use”
– The “pleasant surprise” concept
• User gets more than they expected “They really knew
what we wanted”

10. Quality – Cont.
• Weinberg: Quality is value to some person
– Whose opinion counts?
• “What is adequate quality for one person may even be lack of
quality to another.”
• Quality decisions are political and emotional … hidden from
public view … not even conscious
• Cicero (dead 43 B.C)
– It is the peculiar quality of a fool to perceive the faults
of others and to forget his own

11. Quality – contradictions?
View 1 View 2
Quality will save money Quality cost money
Do it right the first time Quality takes time
We need quality to sell.. It sells without quality
People will pay more for quality Can we afford quality?

12. The Idea of Quality
• By improving the quality of the development
process the product quality is improved, and at
the same time the cost is reduced, and the
development time is decreased.
• Product quality vs. Process quality
• The three goals of a project, product and service
development, need to be balanced:
Time/Cost/Quality

13. The three goals of a project
Performance (Quality)
Cost Time

14. If there is imbalance, e.g. requirements too high
Performance (Quality)
Cost Time
The probability that
the project fails increase

15. Quality through Product
• Assemble products with defects rather
than stopping the assembly line assuming
it is an accidental problem. Consider
repairs later.
• Force/control worker not to repeat
mistakes
– In return individuals may hide problems,
avoiding reporting problems
– Management against workers?

16. Quality through Process
• Stop assembly line when defects are
detected assuming it is an inherent
process problem. Find the source and
correct the essential problem.
• Process engineers find problems and
improve processes.

17. Quality through Process: Roots
• The focus on quality through processes
dates to 1930:s [Shewhart].
• It is based on the concepts of statistical
process control:
– variability is a fact of industrial life, and it can be understood [and
managed] using the principles of statistics and probability.
– variation is the enemy of quality.

18. Variation Example: Soda Factory
• Test whether the machinery is pouring the
required amount of soda into the bottles
– Two bottles have never the same amount.
– Should be close enough to the required
amount
• Testing the amount in each bottle
(inspection) is not possible
– Sample a few bottles in every 100 and plot the results on a chart
against time.
• Determine the boundaries of the system

19. • Find what is causing the variation:
– Acceptable variation - special causes
• For example, caused by the wear of machinery product of
special circumstances
• A temporary misfit
• Can be identified and eliminated by experienced workers
– Unacceptable variation - common causes
• For example, caused by inferior parts purchased after cost
reduction plan
• Inherent in the system
• Is this applicable to Software Development?
Variation Example – Soda Factory – Cont.

20. Bergman/Klefsjö
• It is not enough to fulfil the customer needs.
• Our aim must be to exceed the customers
expectations
• Quality is when the customers choose you as a
supplier in the future as well (a common
measurement of Quality)

21. Customer needs and
expectations
• As customers, it is difficult to express your
needs
• Expectations includes most probably
elements that we, in the end, don’t need
• As customers, we have needs that we do
not expect to be fulfilled
• As customers, we sometimes do not
realize our own needs

22. Who is the customer?
• The one who pays for the project?
• For those who we create value for.
• Stakeholders and Interested parties
– Customers, users, suppliers, shareholders,
employers, unions, partners, loan giver’s,
subject matter experts, other sub-teams in the
project.

24. Quality of Goods (Bergman/Klefsjö)
• Product Quality
– Reliability
• How often do problems occur and how serious are they?
– Performance
• Speed, capacity, size, throughput
– Maintainability
• How hard is it to detect, localize and correct a problem
– Environmental impact
• How the product affect its environment, recyclability and the production
process
– Appearance
• Views, colours, visualizations

25. Quality of Goods (Bergman/Klefsjö)
• Product Quality, cont.
– Flawlessness
• Defects and flaws at the delivery, at the time of purchase
– Safety
• Any causes to personal injury or damage to property
– Durability
• The product can be used without being damaged, provides protection
against damage
• There are more qualities - Software Engineering related:
Robustness, Portability, Testability, Security, etc.

26. ISO25010 (Software products)

27. ISTQB definitions of Software Quality
Characteristics – Products (Examples)
• Reliability: The degree to which a component or system performs specified
functions under specified conditions for a specified period of time.
• Performance efficiency: The degree to which a component or system uses
time, resources and capacity when accomplishing its designated functions.
• Maintainability: The degree to which a component or system can be
modified by the intended maintainers.
• Robustness: The degree to which a component or system can function
correctly in the presence of invalid inputs or stressful environmental
conditions.
• Fault tolerance: The degree to which a component or system operates as
intended despite the presence of hardware or software faults.
• Interoperability: The degree to which two or more components or systems
can exchange information and use the information that has been
exchanged.
https://glossary.istqb.org/en/

29. Quality of Services (Bergman/Klefsjö)
• Service Quality
– Reliability
• Do what you have promised to do, consistency, punctuality
– Credibility
• Being able to trust the supplier
– Access
• How easy it is to come into contact with the supplier, availability
– Communication
• How easy it is to communicate with, and understand the supplier
– Responsiveness
• Willingness to help

30. Quality of Services (Bergman/Klefsjö)
• Service Quality, cont.
– Courtesy
• Behaviour, e.g. politeness and kindness
– Empathy
• To understand the customer situation
– Tangibles
• Appearance of premises and equipment, the physical environment where
the service is executed

31. Alternative model: SERVQUAL
• 5 dimensions of service quality
• Not all dimensions are of equal importance
(Zeithaml, Parasuraman and Berry)
serviceperformance.com

32. SERVQUAL
• Reliability - Do what you say you’re going to do when you said you
were going to do it.
• Responsiveness – Respond quickly, promptly, rapidly, immediately,
instantly.
• Tangibles – Look sharp! Even though this is the least important
dimension, appearance matters. Just not as much as the other
dimensions.
• Assurance - Service providers are expected to be the experts of the
service they’re delivering. It’s a given.
• Empathy - Services can be performed completely to specifications.
Yet customers may not feel provider employees care about them
during delivery. And this hurts customers’ assessments of providers’
service quality.

33. Green Software Engineering
• Carbon: Build applications that are carbon efficient.
• Electricity: Build applications that are energy efficient.
• Carbon Intensity: Consume electricity with the lowest carbon
intensity.
• Embodied Carbon: Build applications that are hardware efficient.
• Energy Proportionality: Maximize the energy efficiency of hardware.
• Networking: Reduce the amount of data and distance it must travel
across the network.
• Demand Shaping: Build carbon-aware applications.
• Measurement & Optimization: Focus on step-by-step optimizations
that increase the overall carbon efficiency.

34. Examples of Goal areas for
Green Software
• Optimize your network traffic
• Increase your computer utilization
• Optimize your database
• Understand your latency limits
• Web-Queue-worker, N-tier and Microservices
are examples of software architectures to be
used for improving measurements
https://principles.green

35. Green Coding
• Programming code that has been produced and
written in a way that minimises the energy
consumption of software, thereby limiting the
potential environmental impact, e.g.:
– Decrease the CPU usage
– Reduce memory usage
– Reduce the amount of code
– Optimize configurations
– Use Lean methods, reduce waste
– Use energy efficient computers

36. Characteristics of Software
• Software development requires integration of
knowledge work. [different expertise]
• Software is intangible: Software has no natural
physical laws.
• Software is expected to solve ill-structured
problems. [poor requirements]
• Software products are increasingly more complex.
• Change is constant in software development.

37. Characteristics of Software Culture
• Conformance to requirements is not enough
– Requirements for software are never complete nor correct
– Requirements are a means to an end (providing value to
someone)
– We must manage parallel development of software and
requirements
• Software development is mostly design, not
manufacturing
– The manufacturing part is very suitable for traditional
quality improvement techniques
– The development part is not
– Development is a clear focus for software quality
engineering

38. Crosby’s Quality Myths
• “Quality means goodness, or luxury, or shininess, or
weight”
– Conformance to explicit and implicit requirements. Fulfilling
customer needs
• “Quality is intangible and therefore not measurable”
– Measured by the expense of nonconformance, identify trends
• “There is an economics of quality”
– It is the absence of quality that costs money
• “Poor quality problems are originated by the workers”
– More than 90% of times, poor quality depends on the managers
• “Quality originates in the quality department”
– Quality must start at the top. Top management support is
needed.

39. Cost of Quality
• Philip Crosby
• “Quality is free. It is not a gift, but it is free. What costs money
are non-quality things -- all the actions that involve not doing jobs
right the first time.”
• A high degree of the cost in a SE projects is commonly related to
after-delivery corrections – unnecessary work, re-work, waste.
• Someone in the organization gets heavily paid for
doing things wrongly, and for correcting faults over
and over again…

40. Ref: Standish Chaos report (1994-2020)

41. Chaos report Cont.

42. Chaos report Cont.

43. Success factors (Chaos 2015)
• Executive sponsorship (15)
• Emotional maturity (15)
• User involvement (15)
• Optimization (15)
• Skilled resources (10)
• Standard architecture (8)
• Agile process (7)
• Modest execution (6)
• Project management expertise (5)
• Clear business objectives (4)

44. Success factors (Chaos 2020)
• Three factors! All of them are people issues.
1. The Good Sponsor is the soul of the project. The
sponsor breathes life into a project, and without
the sponsor there is no project.
2. The Good Team is the project’s workhorse. The
team takes that breath and uses it to create a
viable product.
3. The Good Place is where the sponsor and team
work to create the product.

45. The 10 laws of Chaos, 1 (2)
1. The law of the Two Faces - Users are both your best and worst
enemy.
2. Cheetah’s law - Swift decisions are typically better than long,
drawn-out analysis.
3. Law of the Roads - It does not matter which road everyone
comes from as long as they end up in the same place.
4. The Law of the Five Deadly Sins - You will encounter them in all
projects.
5. The Law of the Long-Tailed Monster - You will always build too
much of what you don’t need and not enough of what you do
need

46. The 10 laws of Chaos, 2 (2)
6. The Law of the Edible Elephant - The only way to eat an
elephant is one bite at a time.
7. The Law of the Mad Hatter - Complexity causes confusion and
cost.
8. The Law of the Empty Chair - Your best person will leave at the
worst possible time.
9. The Panda’s Law - Inaction is the purest form of failure.
10. The Law of the Fools - A fool with a tool is still a fool

47. Ref: ESSU research project No 3
• Total value of contracts is £29.5 billion
• Cost overruns totaled £9.0 billion
• 57% of contracts experienced cost overruns
• The average percentage cost overrun is 30.5%
• 33% of contracts suffered major delays
• 30% of contracts were terminated
• 12.5% of Strategic Service Delivery Partnerships have failed
Note: 105 outsourced public sector IT contracts

48. TQM – Total Quality Management
Focus on processes
Base decisions on
fact
Improve continuously
Let everybody be
commited
Focus on customers
Commited Leadership

49. Total Quality Management,
TQM
• A Business Philosophy
– Quality is an organization-wide process
– Quality is what the customer says it is
– Quality and cost are a sum, not a difference
– Quality requires both individual and teamwork zealotry
– Quality is a way of managing
– Quality and innovation are mutually dependent
– Quality is an ethic
– Quality requires continuous improvement
– Quality is the most cost-effective, least capital intensive route to
productivity
– Quality is implemented with a total system connected with
customers and suppliers

50. TQM Principles (Jacobs)
• 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
• Goals are based on requirements
• Life cycle costs, not front end costs
• Management must be involved and lead
• Plan and organize for quality improvement

51. Ten steps to TQM (Jacobs)
• Pursue new strategic thinking
• Know your customers
• Set true customer requirements
• Concentrate on prevention, not correction
• Reduce chronic waste
• Pursue a continuous improvement strategy
• Use structured methodology for process improvement
• Reduce variation
• Use a balanced approach
• Apply to all functions

52. Ten steps to “TQM Plus”
• It is not enough to “Do things right”
• We must also do “The right things”
• We must deliver things that are good for
the society as a whole.
• Compare with DDT, asbestos, cigarettes
(?), plastic.
• The ideal vision defines a safe and
satisfying world

53. Ten steps to “TQM Plus”
1. Be ready for a challenge.
2. Create and use a quality system that will
collect performance data.
3. Define the ideal vision.
4. Determine gaps.
5. Based on the ideal vision, agree on how
satisfaction will be measured.
See Kaufman/Hirumi

54. Ten steps to “TQM Plus”
6. Identify results that would demonstrate achievement of
steps 3 and 4
7. Define the activities that would deliver such results.
8. Identify what is required to deliver the required results.
9. Specify what each person must do and accomplish to
make certain that quality results and activities happen
continuously.
10. Continue to use the data-based quality system, which
objectively and accurately tracks and reports progress,
problems, and opportunities.

55. TQM Cornerstones
Focus on processes
Base decisions on
fact
Improve continuously
Let everybody be
commited
Focus on customers
Commited Leadership

56. TQM Cornerstones
• Focus on customers
– Needs and expectations
– Trying to fulfil the needs
– Be competitive – be prepared for competition
– Internal customers, stakeholders!
• Base decisions on facts
– Knowledge about variation is needed
– Facts about what the customer wants
– Are estimations/judgments not applicable?

57. TQM Cornerstones, cont.
• Focus on processes
– Data, measurements should be put in the context of the whole
process
– Consider data over time – variation regarding trends
– Management processes
– Main processes
– Support processes
• Improve continuously
– New technologies, new methods
– PDCA
– It is always possible to improve product and processes using
less resources!?

58. TQM Cornerstones, cont.
• Commitment – leaders and workers
– Should see the whole picture – “What are we building?”
– Workers must feel they are needed
– Commitment ensures better productivity
– If leaders are not committed – no one else will
– Leaders at all levels must be committed
– Buy-in is not easy – but necessary

59. TQM, Quality models and
standards recognizes
• Customer satisfaction
• Prevention over inspection (Preventive
over Re-active activities)
• Continuous improvement
• Management responsibility
• Cost of Quality (COQ) – including cost for
conformance work and non-conformance
work

60. Quality-Related Costs
• The cost of quality is divided into:
– Cost of Conformance – Activities that improve
quality
• Prevention costs - Prevent poor quality
• Appraisal costs - Detect poor quality
– Cost of Non-Conformance - The price you pay
when you fail to achieve quality
• Internal failures - Costs before product shipment
• External failures - Costs after product shipment

61. Software Cost of Conformance
• Typical prevention costs for software:
– Training
– Tools and methods
– Standards, policies and procedures
– Consulting
– Quality planning
– Fast prototyping
– Quality data gathering, analysis and use
– Root cause analysis

62. Software Cost of Conformance
• Typical appraisal costs for software:
– Review, walkthrough or inspection of code, design,
specifications
– Tests, Alpha tests, Beta tests, field trials
– Product and process audits

63. Software Cost of Non-Conformance
• Typical failure costs for software:
– Fix a problem within released systems
– Re-review code, design, requirements
– Re-test
– Expediting fixes (overnight mail, overtime etc.)

64. What is a Process?
• Humphrey: A process is a set of tools,
methods and practices used to produce a
product.
• Feiler: A set of partially ordered steps
intended to reach a goal.
• Pfleeger: A series of steps involving
activities, constraints, and resources that
produce an intended output of some kind.

65. Definitions of Process
• CMMI: Consists of activities that can be recognized as
implementations of practices (in CMMI)
• IEEE: A sequence of steps performed for a given purpose
• PMBOK: A series of actions bringing about a result
• ISO: A process is a set of activities that are interrelated or
that interact with one another. Processes use resources to
transform inputs into outputs. Processes are
interconnected because the output from one process
becomes the input for another process. In effect,
processes are “glued” together by means of such input
output relationships.

66. ... Process
• It is dynamic
– If it happens twice, they are two different
instances of the same process model
• It can be described in words, pictures,
diagrams, etc.
– The description is called a process model or
process description or process representation

67. Why is Process Important?
• Methods tell you how to drive (as giving driving
lessons)
• Methods without processes are like a good driver who
doesn’t know where he is and where he is going
– You may eventually get there
– And you may go fast
– Most probably, you won’t get to the right place at the right
time
• Tools without processes and methods are like a fast
car with an inexperienced driver
– You may drive fast
– But who knows where you will end up?
– Wrecks are likely

69. Process: a Type of Knowledge
• Where to go
• How to get there
• Which shortcuts will work
• Which shortcuts will NOT work
• Risks of each option
• Why, not just what
• Who will do it