|
Software Quality Function Deployment (SQFD)
Quality Function Deployment (QFD) originated
in Japan in 1966 when Yoji Akao introduced it there. It crossed to North America in the early 1980s. QFD is
a visual planning tool that supports concurrent engineering. It provides a systematic, measured approach to
determining what is of value to customers and how customers perceive and rate important aspects of competing
products. It determines how different engineered features contribute to overall customer satisfaction. It is
a concurrent engineering method that can be used to simultaneously solve multi-dimensioned problems in an
objective way with group input and consensus.
Kobe shipyards in Japan, Toyota Autobody, Ford, Proctor and Gamble, Chrysler, General Electric (Aircraft Engines)
are some of the big names that have used QFD to good effect. In 1984 companies began using QFD methods in software
development thus introducing Software Quality Function Deployment (SQFD) to the world. When SQFD is used to focus
on customer needs early in the Software Development Life Cycle, it results in fewer changes to an application during
the design, coding and maintenance phases. The quality of the product is enhanced over other methods of specification,
as SQFD ensures, by customer focus and technical feature optimisation, that the right product is specified. SQFD creates
a closed loop when implemented properly that lowers costs, and improves timeliness, productivity and quality. These factors
often in turn, lead to increased market share and profitability.
|
|
Toyota Autobody
- 430, 000 units produced at $71 per unit in 1974. This equalled an annual cost of $30,530,000
or 1.5 times their annual profit.
- QFD was introduced into process planning and production planning to utilise ideas and participation
of plant workers.
- QFD activities from January 1977 through April 1984 resulted in:
- A 61% reduction in product launch costs.
- Time to market was reduced by 33%.
- Measured quality was improved by 30%.
(Kliewer, Liu, Stephen, Weening, University of Calgary, Canada, web site 1998)
|
|
The success of a software organisation stems from customer satisfaction. This satisfaction comes from concentrating on
building a quality product, and this is where SQFD has been found to add value.
|
|
The Japanese Experience
Japanese companies using QFD have:
- Reduced design cycle time by 30 to 50%.
- Reduced engineering changes by 30 to 50%.
- Reduced start-up costs by 20 to 60%.
(Shores A.R., A TQM Approach to Achieving Manufacturing Excellence, ASQC Quality Press, 1990)
|
|
Software quality has two important aspects:
- Maximising the value of software (SQFD). Value is designed in at requirements stage, where so many errors normally
occur. The software engineer needs to concentrate the teams' best efforts on those technical design requirements that
will maximise overall customer value and priorities.
- Minimisation of defects in software (software inspections, validation testing). This traditional view is more common,
however technically good software that does not meet customer expectations, may be of low value.
SQFD helps to overcome three major problems in development of products, namely:
- Disregard for customer requirements (the voice of the customer).
- Loss of information (inherent in sequential processes, because of a broken telephone effect).
- Different individuals and functions working to different requirements.
SQFD makes an important transition from reactive to preventative quality control. SQFD avoids many problems
caused by differences in language, perceptions, knowledge, experiences and values of parties, by using teams
representing all relevant stakeholders in a given project. This allows projects using SQFD to respond quickly
and accurately to changing customer requirements, technology and competitor moves.
The SQFD method is both systematic and quantifiable. It is a front-end requirements elicitation technique,
which can precede any software development life cycle. SQFD documentation is concise and binds all decisions
back to customer requirements and priorities in the face of competing products and available technical solutions
in a traceable way. A knowledge base is built up and ideas can often be re-used in other projects. The process does
cost more in the requirements elicitation, prioritisation and specification stages, but products benefit from designing
quality in. These benefits include fewer requirements changes, less rework, and a direct and measured documented link
to customers needs, competing products, and technical solution elements.
SQFD
has been used successfully by many IT organisations such as AT&T, Hewlett Packard, IBM, Texas Instruments and Digital.
SQFD improves communication between departments since
teams are cross functional, involving customers, sales people, managers, developers, system architects, engineers,
business analysts, testers and other stake holders. The communications are systematised and well documented in a succinct
way for traceability and process integrity through the design and development process. This also gives benefits when new
or changed customer or design requirements are involved. The process offers some reuse possibilities.
|
|
Building a House of Quality
The SQFD process ends up with what is known in the
industry a "House of Quality", a term derived from the general shape of the relevant constituent areas comprising
the related areas under study. Figure 1 on page 8 illustrates the main component areas of a typical House of Quality.
Hearing The Voice of the Customer
Here the customer requirements are collected by the
various requirements elicitation techniques. They can be stated in a vague sense, such as "The system must be fast",
but are better clarified to more specific statements such as, "No responses should take more than eight seconds".
Each of the requirements in the list must be of the same level, so that high level and more detailed requirements are
not be mixed. Thirty requirements in each house of quality is the recommended maximum. Non-customer requirements of the
same level should be included in the list (for example legal, management or marketing requirements).
Customer Competitor Rating
The customer rates competitor products
against the requirements that were set out in the step above, "Hearing the Voice of the Customer". Once
again a Likert scale of 1 to 5 is filled in for each requirement/competitor cell.
Setting Target Values
Here the team sets target values for each requirement.
Customer competitor ratings and the customer importance of each desired requirement are taken into account.
Technical Design Specifications
The individual design requirements specifications that
form the "Voice of the Developer" are now determined. Understanding what the customer rates highly in the competing
products can be used to select solution components and to set measurable levels for the technical design requirements.
Relationship Matrix
For each requirement and technical design function,
relationship strength is determined. Strong relationships are indicated by filling in the value nine, moderate
relationships get a three and weak relationships get a one. Blank implies no significant relationship, and negative
values imply a negative correlation between technical requirement and customer requirement.
Overall Importance Values
These values determine the requirements overall
importance, or relative importance rankings for the completed product. The "Overall Importance" values are mathematically
calculated by multiplying the "Customer Importance" value with the "Set Target Value" to give a result. These values may
be visually recognised by placing them into a histogram format.
Design Requirement Contribution
The relative importance of each technical design
requirement is calculated as the sum of the weighted relationship values in each technical design requirements column,
with each value being weighted by (multiplied by) the "Customer Importance" value. These values can be expressed as
actual values or given as a percentage of the total. If the cost of each technical design requirement is known or can
be reasonably approximated, it may be possible and desirable to calculate a benefit-to-cost-ratio, which may suggest
technical requirements which can give quick or significant gains.
Once again a histogram of these values will give a
quick visual indication of the relative importance or contribution of each technical design requirement.
Correlation Matrix
Here positive or negative relationships
are considered, with strong reinforcing relationships between technical design requirements receiving a value
of 2. Placing a 1 in the correlation block indicates weaker relationships, and negative trade-offs have the same
magnitudes but are preceded by a negative sign. To deliver two solutions with a negative trade-off, more effort
and cost are normally required. If two solutions have a positive correlation, then working on either solution will
simultaneously contribute to the other solution.
Wayne Mallinson
|