1. Design for Quality Design for Quality and Safety Design Improvement
Assessing Design Quality

2. Design for Quality and Safety
Although there are many ways to detect faults, remove faults, and improve the general quality of the design, we must assume that there may be some undetected error made and faults left not found.
For systems such as medical, aero-space, or any with potential life threatening situations, we may need to “design-in” (place into the design) a certain amount of fault processing :
fault detection
fault correction
fault tolerance

3. Fault Processing and Safety
Fault Detection:
Passive fault detection
“run the design” (in this case design inspection or prototype), wait for the failure and then correct it
Active fault detection “placed in” the design
include in the design, functions that will check inputs instead of assuming its correctness
use some amount of redundant processing and compare the results (e.g. sum of a spreadsheet may be checked by adding the sum all the rows against the sum of all columns instead of depending on just one of them assume its correctness.)
use special algorithms such as checksum.

4. Fault Correction
Assume that fault detection in the design actually detects a fault, depending on the requirements the fault correction design may be of the following :
report on the fault and “automatically” terminate the system and restart which is a “fix” --- automatic correction regardless of fault ( e.g. a telephone system )
“attempt to correct” the fault and terminate if not successful (e.g. process control )
“assess the criticality” of the fault and take different degree of correction (e.g. in hospital patient care system may include the sounding of some alarm to get human intervention).
assess the type of fault, report, and terminate (& no fix)
(e.g. hazardous product processing - may terminate first then assess and report)
may
jump to

5. Fault Tolerance
Fault tolerating design is one such that the system is not terminated, but carried on with:
assessment of the fault
report on the detected fault
bypass or branch around (as opposed to fault correction) the faulty area
continue to process
Fault Tolerance assumes that failures may be predicted and by passed (note: failure is a result of a fault which is in turn a result of a human “design” error.)

6. A Design Technique for Fault Processing
Fault-Tree analysis is based on a method developed by the US government defense system
identify a possible failure of the system that’s critical
identify all the failures that will contribute to or cause this critical failure
continue this for each of level of the failures identified until one arrives at a “basic” failure
With a Fault-tree, we can determine how we may want to design our fault processing

7. A Fault-Tree Example Critical Failure event Z OR Failure event A
event B OR
AND
Failure
event C
Failure
event D
Failure
event E

8. Fault Tree Example (cont.)
Note that critical failure Z is caused by either event A or event B
Event A , in turn, is caused by either event C or event D
Event B , in turn, is caused by event D and event E
Therefore the following set of events need to be viewed as the potential causes of critical failure Z that we must decide on what type of fault processing we must design:
{Event C}
{Event D}
{Event D , Event E}
This set is called the Cut-Set
As a designer, you may choose to only design fault correction/tolerance for Event C and Event D, noting that {Event D and Event E} must occur for Event B failure.

9. There are several techniques for further improving our design
Improving Design
There are several techniques for further improving our design
use more prototyping to improve the design
use Boolean algebra to reduce the complexity of logic where possible
Clearly identify and assert for each designed component :
the pre-conditions,
the post-conditions, and
the invariants

10. Assess Design Quality Via Design Inspection or Review
Completeness (components and functionalities)
Consistency (structure and interfaces)
Clarity and Correctness (functionalities, behavior, interactions)
Complexity in the form of:
levels of cohesion,
degree of coupling,
amount of fan-ins and fan-outs.
Compare the amount of and the severity of errors found during reviews with past history, if available.
Compare the size of the artifacts and the time required to complete the design activities (needs lots of experience to make sense).

11. Notes on Design Activities
Design activities may lead to modifications of requirements
Design will also be influenced by the programming facilities like programming language
Most design is not completed with one approach; it also requires several iterations (but do not get stuck in analysis-paralysis)
Errors found during design phase are still easier and cheaper to fix than design errors found in later phases.