Chapter14 quality

The University of New South Wales
School of Electrical Engineering and Telecommunications

ELEC3017 ELECTRICAL ENGINEERING DESIGN

CHAPTER 14:
DESIGN FOR QUALITY

Lecture Notes Prepared by

Mr Leon Dearden
CLD Quality Services Pty Ltd
[with minor edits by D. Taubman]

ELEC3017 Electrical Engineering Design -1- Design for Quality

1. INTRODUCTION
Throughout the industrialised world, more and more organisations are embracing a
Total Quality Management (TQM) philosophy in their operations. A significant and
early step in this process is, usually, to achieve certification of their Quality
Management Systems (QMS) to one of the series of international quality standards
included in the ISO 9000 series.

As future designers in electronics or software, you may well end up working in one of
these organisations, thus you will need to understand the impact that QMS will have on
your design activities. Even if you work for yourself or in a “quality unaware”
organisation, you will benefit from knowledge of the valuable contributions to the
design process that can be made by applying quality management principles and
applying them whenever you can.

The purpose of this chapter is to explore the treatment of design activities as one of a
number of “quality processes” included in a Quality Management System and to define
the attendant benefits.

The subject matters discussed in general refer equally well to hardware and software
design and development activities. Where there may be particular differences in
application then such distinctions will be indicated.

2. WHAT IS MEANT BY QUALITY
There are many definitions of quality, e.g. [1]; for myself, I prefer the following
definition:

“The totality of product (or service) features and characteristics
which satisfy customer needs at an affordable cost”

This definition was constructed to show the important relationship between “Customer
Needs”, “Product (or Service) Features” and “Cost”.

There can be a difference between what the customer says they want (“the
Requirement”) and what they really expect to get (the often unstated “expectations”).

The “quality aware” designer needs to ensure that they understand and define the
customer’s “needs” as the sum of stated “requirements” and unstated “expectations”.

Unstated expectations can be as simple as screen layouts or fonts in software designs,
adherence to corporate colour schemes for hardware items etc. or as important as
graceful degradation under failure conditions for safety critical systems such as aircraft
or nuclear reactors.

In other words the quality of the product is judged (by the customer ) in accordance
with the degree to which it meets their real needs (however poorly or inappropriately
they may specify them). The aware designer looks beyond the written specification of
requirements and seeks to understand the nature of the customer’s “reality”.


If you want examples of how important this factor can be, then I recommend you read
Prof. Nancy Leveson’s paper [2].

Note also that we do not want to confuse “reliability” with “quality”. A product can be
highly reliable in performing functions that a customer does not want or value.

In all of the above, we must not lose sight of costs. The product or service must be
provided to the customer at a price they can afford and will regard as “value for
money”, while at the same time offering an acceptable profit to the supplier.

3. QUALITY ASSURANCE STANDARDS
Of the range of standards in the ISO 9000 series, one is of immediate interest to
designers:- AS/NZS ISO 9001:1994-Quality Systems- Model for design, development,
production, installation and servicing.”.

It is interesting to look at the scope and field of application stated for this standard.

In its scope statement, the standard talks about:
• “specifying quality system requirements for use where a supplier’s capability
to design and supply conforming product needs to be demonstrated”
• “The requirements specified are aimed primarily at achieving customer
satisfaction by preventing nonconformity at all stages of design through to
servicing”

The standard goes on to define its applicability where:
• “design is required and the product requirements are stated principally in
performance terms, or they need to be established”
• “confidence in product conformance can be obtained by adequate
demonstration of a supplier’s capabilities in design, development,
production, installation and servicing”

There are significant differences in some aspects of design between software and
hardware.

In 1987, Australia initiated its own standard AS 3563 for Software Quality Management
Systems (subsequently updated in 1991) in order to achieve the same aims as for
hardware with the original 1987 version of AS 3901/ISO 9001(subsequently updated in
1994). For a software development environment AS 3563 competently replaced AS
3901/ISO 9001. This standard was adopted by the IEEE in the USA and was offered for
adoption internationally by the ISO.

However, with the revision made to ISO 9001 in 1994, it became more suitable for
software developers, so that software developers are now being certified to ISO 9001
and AS 3563 has been relegated to a guidance role. In 1996, a further guidance
standard AS 3905.8 (Ref. B7) was released to assist software developers interpret ISO
9001 and this is tending to take precedence over AS 3563.


The underlying philosophy is that by analysing, understanding, defining and controlling
the organisational processes involved in design, development, production, installation
and servicing, then quality is designed in and built in to the product (hardware or
software). No longer are we so reliant, as in the past, on inspection and testing to try to
eliminate faulty product (or software).

These standards also emphasize design requirements. Reference is again made to
Nancy Leveson’s paper [2] on the difficulty, if not impossibility, of fully testing more
than very elementary software and hardware systems. Thus the definition and
management of design processes as a tool to enhance software and hardware quality
(i.e. freedom from undesired performance modes) assumes a major importance.

4. UNDERSTANDING THE DESIGN ACTIVITY AS A PROCESS
It is instructive to look at the elements of ISO 9001 as interpreted using AS 3905.8
(AS 3563 used for background guidance):

Clause ISO 9001 covers: AS 3905.8 covers:

4.1 Management responsibility Management responsibility

4.2 Quality system Quality system

4.3 Contract review Contract review, planning and requirements
control

4.4 Design control Design, programming and user
documentation control

4.5 Document and data control Document and data control

4.6 Purchasing Purchasing

4.7 Customer supplied product Customer supplied information and
material

4.8 Product identification and Configuration management (including
traceability product identification and traceability)

4.9 Process control Usually covered by Clauses 4.4; 4.14 &
4.19, however

‘Control of development environment’ can
be covered here

4.10 Inspection and testing Inspection and testing


4.11 Inspection, measuring and test No direct equivalent unless associated
equipment hardware is involved, however -may apply
to Test Software if used

4.12 Inspection and test status Usually covered by Clauses 4.8; 4.10 &
4.15

4.13 Control of non conforming Usually covered by Clauses 4.8; 4.10 &
product 4.14

4.14 Corrective and preventive action Corrective and preventive action

4.15 Handling, storage, packaging Handling, storage, packaging preservation
preservation and delivery and delivery

4.16 Quality records Quality records

4.17 Internal quality audits Internal quality audits

4.18 Training Training

4.19 Servicing Software maintenance

4.20 Statistical techniques Statistical techniques

While we are going to concentrate on those elements of the process that most
particularly represent design activities, it is important to realise that design activities
impact on or are impacted by almost all other organisational processes.

For example:
• Limitations of the production/inspection/testing process. Manufacturing
engineers will want to constrain the design so that it can be economically
manufactured using existing production tooling and work force capability.
Alternatively, if the design requirements preclude this, then they will need time
and resources to upgrade production capabilities and acquire and train staff.
• Limitations of engineering resources or know-how. It may be necessary for
Personnel to recruit more designers or arrange specialist training.
• Requirements for special components or other materials. Purchasing may need
to be involved at an early stage to source required materiel or negotiate
acceptable alternatives.
• Impact on service/maintenance operations. Training of service technicians
and/or new equipment may be required. If ease of service/maintenance is a
vital factor then such requirements may constrain the design process.


4.1. DESIGN AS A “SPECIAL PROCESS”

Special processes are specifically mentioned in the standards. Special processes are
characterised by:
• performance which is unable to be completely verified by inspection and
testing of the product after it is completed;
• performance defects which may become apparent only after the product has
been in service for some time; or
• the need for continuous monitoring of the process, or compliance with
documented procedures, or both, in order to ensure that the desired product
performance is “built in”

When you think about it, some mechanical design, most electronic design and nearly all
software design fits this definition of a special process.

This is why in a well managed design environment there are such things as:
• Design methodologies
• Design Standards
• Design procedures
• Design documentation standards
• Test methodologies etc. etc.

Based on the collective wisdom and experience of the designers, past and present, the
organisation has developed design techniques that minimise the chance of error in
meeting requirements. What the Quality Management System does in responding to the
appropriate quality standards is ensure that this hard won knowledge is documented in
procedures so that conformance to the required processes can be verified. Also, with
this knowledge available in printed form, training of new employees is facilitated.

5. ELEMENTS OF THE DESIGN PROCESS
Let us now look at what the Standard (ISO 9001) says about design control.

Requirement for procedures

An organisation is required to establish and maintain documented procedures to
control and verify the design of the product in order to ensure that the specified
requirements are met.

In view of our past discussion, this is reasonable. You verify where you can control the
process and its methodologies to minimise the risk of error where verification is
difficult or even impossible.

Remember, however, to check that the “specified requirements” are complete, and
augment them as necessary to specify the context of operations or assumptions being
made by the writer of the requirements document. Also note that the writer of the


specifications document may not be the end-user but only his agent, so that another
layer of assumptions may need to be identified.

The process of requirements specification for minor design tasks can be as simple as
visiting with the customer to observe his environment and getting him to state what he
wants to achieve in terms of outcomes. You the designer, can then create your own
“design requirement” document, perhaps as simple as a page of notes, secure in the
knowledge that you have a good understanding of the customer’s real “needs”.

For extremely large and complex design tasks, with critical reliability and safety issues,
creating a requirement specification (and in fact the whole design activity) is a much
more demanding process.

For moderately sized and moderately complex design activities, direct access to the
end-user may not be possible for all members of a design team so that a reasonable
amount of effort should be expended in creating requirements documents in order to
provide a credible and realistic definition of desired design outcomes in performance
terms.

The requirements definition activity is often accomplished under the umbrella of an
overall design project management program. A very readable document covering this
topic as part of project management is the IEEE Standard for “Software Project
Management Plans” 1 . While this document is aimed at software design, its
methodology is almost wholly applicable to hardware design as well. At the minimum
level it can be used as a check list to ensure as a designer that you ask all the right
questions before you start your design; in its intended application it provides a
methodology for managing the whole design process.

This phase of the design process, before any actual design work is done is perhaps the
most critical of all. If the “requirement specification,” however expressed, is flawed or
incomplete, then the design outcome must surely fail to meet the end-user’s requirement
and will again just as surely cost an excessive amount of time and money to put right
(assuming that recovery is possible!).

There have been numerous studies done to quantify such penalties, one of these
illustrated in Figure 1, relates to software in which the cost to correct an error is related
to the phase in a project that the error is found. Similar considerations apply to
hardware.

1 See the list of quality standards at the end of this document.


Relative
Cost
($)

Preliminary Detailed Code & Integrate Acceptance Operation
Design Design Debug Phase Error Detected

Figure 1. Relative Cost to Correct Errors-Software Testing.

6. REQUIREMENT FOR DESIGN AND DEVELOPMENT
PLANNING
• required are plans that identify the responsibility for each design and
development activity
• these plans are to define all design activities and must be updated where
necessary as changes are made to the design
• design and verification activities are planned
• these tasks are assigned to qualified personnel
• adequate resources are provided to designers.
• organisational and technical interfaces between different groups are to be
identified
• required design information is to be documented, transmitted and regularly
reviewed

What the Standard is trying to achieve here in terms of making sure that the design
process is under control and given the best possible chance to succeed in achieving its
goals, is:
• plan the activities so that nothing is overlooked
• assign qualified designers to individual tasks
• give them the tools and support to do the job
• make sure that interfaces with other designers are clearly defined
• make sure that inter-group communications are effective


7. REQUIREMENTS FOR DESIGN INPUT
• design input requirements are to be identified and documented
• they must be reviewed by the supplier for completeness.
• any incomplete, ambiguous or conflicting requirements must be resolved at
this stage

We have already discussed this in some detail in Section 5 above.

8. REQUIREMENTS FOR DESIGN OUTPUT
• design output requirements are to be documented
• they should be expressed as far as possible in terms of the original design
input requirements
∗ design outputs should contain or reference acceptance criteria;
∗ they should conform to appropriate regulatory requirements
∗ they should identify any design characteristics affecting the safe use of
the product

To meet this requirement it is important to ensure that the outcomes of the design
process are expressed in a quantifiable fashion, i.e. :
• number of requirement features met
• number of calculations/analyses performed
• number of defined acceptance criteria met
• number of regulatory requirements identified and met
• number of design characteristics or limitations) crucial to safe or proper
functioning identified

In other words if you can tick off the lists as complete (and get your customer/end-user
to agree) then the design task is complete! In order to achieve this desirable result then
the required design outputs must have been defined at the beginning or at least early in
the design process and managed along with all the other activities.

9. REQUIREMENTS FOR DESIGN VERIFICATION
• verification activities should be planned and documented
• competent people should be assigned to the verification task
• design verification is required to establish that design output meets the
design input requirement
• this can be done using design control measures like:
a) undertaking design reviews and documenting the results


b) undertaking qualification tests as appropriate
c) making design comparisons with similar proven designs

Understand that design verification is more that just seeing if it works and running a
few tests. For the reasons outlined before, it is often impractical or impossible to fully
test a design i.e. prove it is fully competent by testing alone.

For that reason control of the design process is important and one element in achieving
that control is assessing the state of “soundness” of the process through design reviews.

Design reviews for major projects can involve a significant amount of time and effort
involving teams of independent experts. For minor design tasks it can be as simple as
reviewing the design process and results to date with a colleague or supervisor. The
important thing is that it should be a planned activity that occurs at regular intervals so
that if problems are identified, they can be overcome or alternative courses of action
planned and accomplished so as not to compromise the desired outcome of the overall
design project.

For more information on ways of conducting the design review process read BS7000 2 .

10. REQUIREMENTS FOR DESIGN CHANGES
• the requirement is to create and maintain procedures for the identification,
documentation, review and approval of all changes and modifications

Change is an integral part of the design process and as such has to be managed.

For the most part, particularly in electronics or software, each new design attempts to
create something that has not been achieved before. While new designs may be similar
to what has been done before, there is usually no exact step by step plan that will
guarantee the outcome is correct at the first try.

So at points along the design path, the designer will realise that the design is not
performing as required and that changes are necessary. Because human memory is so
imperfect, it is vital to be systematic in making changes to designs and to record the
change details in some appropriate fashion. Without this the probability of performance
errors being built into the design is very high. A systematic process to minimise the
chance of errors when making design changes is even more vital when more than one
person or group is involved in the design process.

The change management process can vary from the simple to very complex depending
upon the nature and scale of the design project.

2 See the list of quality standards at the end of this document.

ELEC3017 Electrical Engineering Design - 10 - Design for Quality

11. DESIGN PROGRAM MANAGEMENT
We have touched on the need to manage the design process closely in order to achieve
desired outcomes, technically, timewise and financially. Program Management is a
subject in itself and beyond the scope of this paper.

12. COSTS
ISO 9001 does not explicitly deal with costs and this is perhaps a failing. Cost and time
scale are vital factors in all design activities; ultimately to a significant extent, time
scale problems can also be related to costs.

Unless a designer is independently wealthy and undertaking design activities for the joy
of it, he is ultimately responsible to the financier of the project for achieving a desired
amount of product performance for a defined overall cost. This measure of the design
outcome can also be more crudely defined as “bangs per buck”.

Thus financial limitations are an ever-present constraining influence on the design,
production, installation, operational, servicing and where relevant, retirement processes
for any product.

The actions of the designer have an influence on all these costs. In the real world,
technical performance is evaluated against these costs. Trade-offs or compromises are
made to achieve, hopefully an optimum, but at least an acceptable balance between
these conflicting requirements.

Ideally at the requirements stage, cost specifications for all phases of a products life are
set as design goals e.g.:
• Design must complete within budget and time scale or the project may become
financially non viable or miss its market opportunity.
• The designed product must be able to be manufactured for less than a defined
amount; otherwise sales, and hence profits, or adequate return on investment
will not be realised.
• Installation and servicing/maintenance costs should be designed to be low so as
not to erode profitability.
• Operating costs to the customer should be designed to be at acceptable levels
so as to maintain customer satisfaction and hence sales.
• Increasingly with the “greening” of industry, products must not degrade the
environment and may need to be economically recycled or disposed of at the
end of their useful life.

These “Life-Cycle Costs” can be modelled and monitored prior to, throughout and
beyond the design stage. While the modelling relies on a lot of economic, technical,
environmental and political factors which abound with assumption difficulties, the
output of the process is a useful indicator of the overall cost-effectiveness or worth of a
product or project. If the cost effectiveness becomes doubtful at any stage during the
design process then the project may be cancelled or may need to be severely


restructured to align design goals with the perceived fiscal and political realities of the
time.

13. CONCLUSION
In presenting this paper on “Quality in Design” I hope I have achieved the goal of
demonstrating that there is a lot more to the process of achieving quality in design than
undertaking the core design processes themselves, important though they may be.

It is important to understand that:
• There must be a clearly defined starting point for the design process. The
“Design Requirement” must be established and understood: not only what is
written, but what is unwritten (i.e. assumed to be known by the end-user).
• For other than the most trivial of designs, complete testability is almost always
impossible or at least uneconomical; therefore, control of the design processes
and its methodologies is also vital to ensure the best possible chance of
meeting design requirements.
• Planning of design activities and clear allocation of responsibilities for
activities is required. Designer capabilities must be equal to the tasks to be
performed.
• Organisational and technical interfaces must be recognised and systems set up
to control interaction and communication.
• Progress on design activities and technical outcomes should be formally
reviewed at planned intervals during the design phase. Planned changes
(involving re-design, alternative studies, additional resources etc.) may need to
be put into effect to overcome any technical difficulties that become evident
through the review process.
• Desired design outcomes should be quantified i.e. there should be a countable
number of defined outcomes established to delineate the completion of the
design task.
• The inevitability of change should be recognised and a competent system set
up to manage design changes.
• Above all this in, order to survive, the design or project must be managed to
remain viable in terms of overall long term costs and time scales.


REFERENCES
[1] W.R. (Bill) Chestnut, Quality Assurance: An Australian Guide to ISO9000
Certification. Melbourne: Addison Wesley Longman, 1997.
[2] N.G. Leveson, Software Safety: Why, What, and How. University Of California.

STANDARDS
1. AS/NZS ISO 9001:1994 “Quality systems- Model for quality assurance in
design, development, production, installation and servicing”
2. “AS3904.1/ISO 9004 -1987 -Quality management and quality system elements
- Guidelines”
3. “AS 3563.1 -1991 -Software Quality Management System Part 1:
Requirements”
4. “AS 3563.2 -1991 -Software Quality Management System Part 2:
Implementation Guide”
5. “British Standard BS 7000:1989 - Guide to managing product design”
6. “IEEE Standard for Software Project Management Plans -Std 1058.1-1987”
7. “AS/NZS 3905.8:1996” Quality system guidelines Part 8: Guide to AS/NZS
ISO 9001:1994 for the software industry.


SUMMARY

A coordinated program for the achievement of quality involves
all phases of a product’s life cycle, from the initial concept
through to design, development, pilot production, full
production, transport, installation and ultimate use. Quality can
be achieved only if management is actively involved in all
phases.

This chapter lists the many tasks which form part of such a
coordinated program during the concept, design, development
and pilot production phases, with major emphasis on the
achievement of a product of high reliability.

The importance of formal design reviews, of developmental
testing of prototypes and of having an efficient Failure
Reporting, Analysis and Corrective Action System (FRACAS) is
stressed.


Chapter14 quality

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to Chapter14 quality (20)

More from Vin Voro (20)

Recently uploaded (20)

Chapter14 quality