Brief History of QualityHere are some notes on the basics I think its good to know to get a feeling for where concepts of Quality came from, were developed and refined, and gave Quality its credibility. A key attraction to me towards Quality was that it came about progressively "in the field", "at the coalface", and "out of the school of hard knocks" rather than in any "hallowed halls of academia".
American Civil WarA significant early example of fundamental seeds of quality lay in firearms production by Union factories for the American Civil War (1860-64). A new system was devised where specifications for parts of rifles and tolerances for critical dimensions were defined and conveyed to remotely located manufacturers. The parts were separately assembled by other parties. As long as parts were within the defined tolerances, assembly was successful, and the value of the finished product was assured. Defective parts were defined as those not built within the specified tolerances. Many aspects of quality control and inspection were refined and made an integral part of production line manufacturing, eg in ... Henry Ford's vehicle assembly lines"Until Ford, a car's components always had to be fitted or reshaped by a
skilled engineer at the point of use, so that they would connect
properly. By enforcing very strict specification and quality criteria
on component manufacture, he eliminated this work almost entirely,
reducing manufacturing effort by between 60-90%". ( David A. Hounshell, From the American System to Mass Production, 1800-1932 (John Hopkins University Press, 1984)) Deming and Japan Post WWII- "Dr Deming has a worldwide reputation for his work in establishing statistical process control techniques for quality as the route to competitive success in the new economic age." ("Out of the Crisis - Quality, Productivity, and Competitive Position" W Edwards Deming, ISBN 0-521-30553-5)
- "Deming is widely credited with improving production in the United States during World War II, although he is perhaps best known for his work in Japan."
"While working under Gen. Douglas MacArthur as a census consultant to
the Japanese government, he famously taught statistical process control
methods to Japanese business leaders, returning to Japan for many years
to consult and to witness economic growth that he had predicted as a
result of application of techniques learned from Walter Shewhart at Bell Laboratories."
"He is regarded as having had more impact upon Japanese manufacturing and business than any other individual not of Japanese heritage."
(Wikipedia)
Beyond the mid 20th-century, Quality principles had developed and matured into ... Total Quality Management SystemsIn which Quality is defined as an all-pervading set of values and practices to permeate throughout an organisation. As an adjunct to this, the adoption of "Industry Best Practices" and formal certification to Quality Standards are usually seen as desirable. My "Four Plus One" Cornerstones of QualityThis lists five key concepts within Total Quality Management.
I believe that this is a small iterative improvement on the "Four Cornerstones" as defined in literature in the 1980's. ( Full details here ...) | Quality in Software DevelopmentThe Cornerstones defined previously can be mapped into a quality software development process by adopting such concepts as: - Customer Focus: Focus and develop around functional requirements as defined by the customer
- Zero Defect: Incorporate an issue, enhancement and bug tracking system
- Continuous Iterative Improvement: In development, replace the "waterfall" style of development by an iterative approach (beyond then as per "Zero Defect").
- Improve the Process: Adopt a flexible system development method
- Universal Responsibility: Communicate their responsibilities and empower them with appropriate authority and empowerment, eliminate bureaucracy.
Quality can be realised in
the adoption of flexible development methods (erroneously termed
"methodologies"). The method that particularly impressed me in by the mid 1990's is now known as the Open Unified Process. It was then marketed as the "Rational Unified Process". Unfortunately I saw scant evidence of this being
adopted beyond lipservice in the many large companies that I was
contracted into during the years I was most involved in software
development in Australia in 1985 through 2001. I believe that this was
one key reason why development tailed off here after the end of the
huge maintenance contracts in 2000. Companies had spent enormous
amounts of money on software development projects, of which a massive
85% were judged to be failures. Why did they fail? - One of
the keys for this failure was that projects were not actually run to
any commonly understood and adopted method, even when a method had been
sold into a project, sometimes at considerable expense.
- Another
key reason was poor definition of customer requirements, which could be
also described as lack of clear focus on actual customers' needs. Many
projects were started on budgets that were totally out of touch with
reality, as real requirements were not defined, and then ...
- no
concept of "universal responsibility" existed. Instead people actively
(and immorally) took steps to avoid responsibility for impending
problems.
- Essentially, dishonesty prevailed, in environments where good honest open leadership was often non-existent. In I.T. one of the greatest failings people exhibit is failure to declare that they do not have knowledge or an understanding of a concept, technology or issue, etc, and/or (possibly based on their lack of knowledge at the time) that they made an incorrect decision, then spend real time trying to cover this up.
Quality concepts seem never to flourish, and in fact are squashed, in this sort of environment. Both the successful adoption of Quality, and the success of otherwise of system development projects, depend on human qualities, and have little to do with the software technology used.It
is interesting to see that my findings, as expressed above, relate to a
period in time ending nearly ten years ago. However, human nature still
being what it is, I feel sure that the same problems are seen to exist
today. For instance, while the "method-du-jour" might be called
"Agile", or "Scrum", their use in software development projects have
led to no different result than occurred ten years ago in this case at least. Comparison with Vehicle Manufacture
Software development is the production of software just as car plants
are places for the production of cars. I believe that the key Quality
concepts and issues are as relevant to software production as to car
production.
Similarities
- Financial - The Business Case: What percentage of effort is to
be spent on Quality? What is the cost of the defects vs the cost of
Quality? What is the optimum ROI? How to measure this?
- People are the key resource. Machinery and support systems are all
themselves conceptualised, designed, developed, built, deployed, and
ultimately used/controlled and managed by people.
- The snake-oil
factor: Like many areas of study, methods and terminlogy can become
unnecessarily complicated and obscured by 'experts' creating ways to
differentiate themselves and justify their titles, but in doing so
they inadvertently ensure that the entire discipline and its benefits are lost on the
general working population. I apply to KISS principle to everything,
including Quality.
Differences?
Pace of improvement? While the pace of change and improvement
to many software development concepts and technologies has seemed to be
frenetic since 1982 when I have been involved, I wonder how much faster
this really has been compared to a similar period in the early
commercialisation of the motor vehicle, say from 1890 to 1930. We have
had the benefit of being able to use the computers and communications
technologies themselves to transmit new knowledge far more quickly,
than possible 100 years ago. However both events have been constrained
by the ability or otherwise of the general population to want, need or
be able to understand the new concepts, adopt the new technologies and
buy the new products.
C.A.S.E. in I.T. CASE tools could be seen a method of promoting Quality in software development by automating software code generation... ( To do: complete this section) |
