This document discusses definitions of software quality from Deming, Feigenbaum, and Juran. It also discusses different types of quality like external/functional quality which is compliance to requirements/specifications, and internal/structural quality like robustness and maintainability. Motivations for quality include risk and cost management. Improving quality involves choosing standards, defining metrics to measure against them, testing, analyzing, reviewing code, refactoring, and automating processes. Simplicity is important for reliability according to Dijkstra. Quality is an ongoing effort not a one-time thing.

1. “Does quality software exist?”
ronald@nforza.nl
@ronaldharmsen

2. Software development professional
 17 yrs
Roles:
Consultant
Code quality inspector
IfSQ board member
Trainer
Coach
Developer
Architect
Support engineer
Team lead
Projectmanager
Product owner
Operational manager

3. • Definition
• Measurement
• Improving

4. definition

5. Software quality according to Deming
"The problem inherent in attempts to define the quality of a product, almost any product, were stated
by the master Walter A. Shewhart. The difficulty in defining quality is to translate future needs of the
user into measurable characteristics, so that a product can be designed and turned out to give
satisfaction at a price that the user will pay. This is not easy, and as soon as one feels fairly successful in
the endeavor, he finds that the needs of the consumer have changed, competitors have moved in, etc.”
Software quality according to Feigenbaum
"Quality is a customer determination, not an engineer's determination, not a marketing determination,
nor a general management determination. It is based on upon the customer's actual experience with
the product or service, measured against his or her requirements -- stated or unstated, conscious or
merely sensed, technically operational or entirely subjective -- and always representing a moving target
in a competitive market”.
Software quality according to Juran
"The word quality has multiple meanings. Two of these meanings dominate the use of the word: 1.
Quality consists of those product features which meet the need of customers and thereby provide
product satisfaction. 2. Quality consists of freedom from deficiencies. Nevertheless, in a handbook such
as this it is convenient to standardize on a short definition of the word quality as "fitness for use".”
Source: Wikipedia

6. External or functional quality
Complience or conformancy to a given design,
based on functional requirements or specifications.
Internal or structural quality
Non-functional requirements that support the
delivery of the functional requirements, such as
robustness or maintainability, the degree to which
the software was produced correctly.

9. Motivations:
• Risk Management
• Cost Management

10. “Making Promises you can Keep”, is all about:

11. • Testing
• Code-based analysis
• Assesments
• Interviews
• But also: run-time metrics

12. “Testing shows the presence,
not the absence of bugs”
Edsger Dijkstra (1969 !)

13. • Tooling / metrics
• Manual reviewing

14. • Cyclomatic redundancy, Thomas McGabe
M = E − N + 2P
9 – 8 + (2*1) = 3

15. Cyclomatic Complexity != Cyclomatic Complexity

17. • Why?
– Testing only shows results of code
– Finding defects
– Check compliancy to (company) standards
– Verify architecture
– Learning and sharing

21. Improving software quality or…

22. • Hard-to-read code
• Specialization
• Bad design
• Technical debt
• Complexity
• Catalyst: Deadline pressure

24. Simplicity is a great virtue but it requires hard
work to achieve it and education to appreciate
it. And to make matters worse: complexity sells
better.
Edsger Dijkstra (1984)

25. How do we convince people that in
programming simplicity and clarity —in short:
what mathematicians call "elegance"— are not a
dispensable luxury, but a crucial matter that
decides between success and failure?
Edsger Dijkstra (1977/78)

26. Simplicity is prerequisite for reliability
Edsger Dijkstra (1975)

28. • Choose your standards and keep to them
– Coding guidelines
– Naming conventions
– Architecture

29. • Define metrics to measure them
– KPIs for quality, i.e.:
• Number of defects reported by users
• Review score (IfSQ or SIG ratings)
• Code coverage
• Team velocity
• # Technical debt list changes
– Is quality improving? Or decaying?

30. Remember:
“Testing shows the presence, not the absence
of bugs”
The same applies to metrics & reviews

31. • Test
• Analyse
• Review
• Refactor
• Automate what you can
– Continuous integration / deployment / automated
testing / checkin analysis / code generation etc.