Design for Quality Design for Quality and Safety Design Improvement Assessing Design Quality

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

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.

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

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.)

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

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

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.

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

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).

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.