February 2016 1

Business Skills

Fundamentals of Engineering Design

Carlisle Adams, David Knox

2

Design

“Scientists investigate that which already is; engineers create that which has never been.” Albert Einstein

Design distinguishes engineering from pure science and mathematics

Engineers need to apply their creative talents to improve or build new products, processes, devices, and systems

Design experience is an important part of every engineering program

February 2016

Presentation Overview

I will review a ‘traditional’, top-down, systematic design methodology: This method has been applied in the design of many

different things for many years and is used today

Other methods are possible and even encouraged, but this is an excellent default method (i.e. “a plan to deviate from”)

The approach described here will always work, but does not guarantee the best or even the fastest design (even great tools don’t guarantee great work!)

Other (e.g. software) design approaches have been defined

Engineering Design is an active research area

There are large financial rewards in the commercial sector, to improve the timeliness and quality of Engineering Design!

3 February 2016

4

Outline

Defining Engineering Design

Characteristics of Good Design Practice

The Engineering Design Process

Design Tips

Decision-Making

Design Documentation

System Life Cycle

Design Teams

Conclusions

February 2016

5

Definition

“Design” can be both an activity (verb) and the result of an activity (noun)

Text uses “design” for the activity and “solution” for the result

Engineering design:

Process of developing workable plans for the construction of devices, processes, etc., to satisfy some identified need

February 2016

6

Definition (cont’d)

More formal definition (CEAB):

Engineering design integrates mathematics, basic sciences, engineering sciences and complementary studies in developing elements, systems and processes to meet specific needs. It is a creative, iterative, and often open-ended process subject to constraints which may be governed by standards or legislation to varying degrees depending upon the discipline. These constraints may relate to economic, health, safety, environmental, social, or other pertinent interdisciplinary factors.

February 2016

7

Definition (cont’d)

Engineering design is as creative as artistic design, but it requires scientific, mathematical, and technical knowledge to carry it out properly

February 2016

8

Types of Engineering Design

Evolutionary/Incremental Design Improvements to existing solutions (primarily

because technology has improved or knowledge has expanded)

E.g., passenger car (braking, fuel, airbags, …)

Innovation New or original idea; novel way of solving a

problem (e.g., wheels on running shoes)

If the innovation applies to technology, it may be considered an invention (and may be patentable)

February 2016

9

Good Design Practices

Need more than just common sense, or common knowledge!

Seven-step process: 1. List criteria, requirements, and

constraints (in order of importance)

2. Identify users and their tasks Who will need to use this product (throughout

its entire life cycle) and what do they need to do with it?

February 2016

10

Good Design Practices

3. Identify effects on the environment

4. Generate multiple solutions (“brainstorming”)

5. Select optimal solutions

Try to maximize benefits while minimizing costs

6. Make defensible decisions

Engineer should be able to defend (in a court of law, if necessary) every design decision from scientific and other perspectives (e.g., economic, safety, etc.)

7. Use best practices

Base design on recognized methods, procedures, codes, and standards

February 2016

11

Design Terminology

Heuristic General rule of thumb (e.g., “product should be easy to use”)

Guideline More specific than a heuristic, but still general advice (e.g.,

“products to be operated by the general public should be designed to accommodate the 5th percentile female to the 95th percentile male”)

Standard / Code More specific than a guideline: states technical requirements

that must be met, but does not provide a complete solution

Specification Description of the technical requirements in sufficient detail

that someone else can build or implement what the designer has envisioned (sometimes requires interoperability)

February 2016

12

Engineering Design Process

Systematic approach to design (i.e., repeatable from one project to the next)

There is still room for creativity, but creativity is just one step in the process (along with info. gathering, analysis, testing, etc.)

Six main activities (each focused on answering specific questions)

February 2016

Basic System Design Process

February 2016 13

INFORMATION NEEDS ANALYSIS

PROBLEM STATEMENT

GENERATE SOLUTIONS

EVALUATE AND SELECT

SOLUTION(S)

GENERATE DESIGN CRITERIA

FEASIBILITY ANALYSIS

Process is iterative

!

What makes a good or a bad design solution?

Solutions are evaluated against the design criteria

Clear and simple statement of the problem

RECOMMENDATIONS

14

Design Stages

1. (Needs Analysis) Gather and Process information and analyze requirements to produce a…

2. (Problem Statement) Clear definition of problem

State the problem in a single sentence format: Design a (type of solution: product, device, or system) to be used by (potential target users) to (carry out a particular task or set of tasks) that (meets a specific set of benchmarks).

Example: “Design a low-cost water-purifying system for remote areas to be used by adults and children with limited education that will convert 2L of ground water into drinkable water within 10 minutes.”

Example: “Design a software program to be used by bank customers to allow online banking transactions with the following security and privacy features: …”

February 2016

15

3. (Generating Design Criteria)

Explain the problem clearly and succinctly enough to define ‘good’ and ‘bad’ solutions

4. (Generate Solutions)

Brainstorming: generate as many solutions/ideas as possible (without evaluation or criticism!) for a fixed period of time

Challenge assumptions and presuppositions

5. (Evaluate and Select Solutions) Select solution(s) worthy of further feasibility analysis

6. (Feasibility Analysis) Build models, simulations, prototypes

Quickly test feasibility of one/more proposed solutions

The simpler, the better (must answer the feasibility question)

Design Stages (cont’d.)

February 2016

16

Tasks and Questions Asked

1. (Needs Analysis) Assessment What is the problem? What are existing solutions

(and why are they inadequate?)? What are the requirements and constraints on the desired solution?

2. (Problem Statement) Summary / Focus Is this a complete, but succinct statement of the

problem that can be ‘kept in mind’?

3. (Generate Design Criteria) Synthesis Which specific aspects should be given what priority?

4. (Generate Solutions) Synthesis What ideas are there for solving the problem?

February 2016

17

Tasks and Questions Asked (cont’d)

5. (Evaluation and Selection) Design Analysis Does the proposed solution incorporate best practices?

What is the predicted performance? Does it meet all of the required design criteria?

6. (Feasibility Analysis) Analysis, prototyping, testing Implementation Considerations: How will the solution

be built? Do we need to develop a prototype or simulation to confirm feasibility?

Testing / Validation Considerations: How will we objectively evaluate the solution to ensure that it will meet the requirements? How will the results be measured?

(Recommendations) Are we ready to clearly state the design specifications for

construction or manufacture? February 2016

18

Engineering Design Process (cont’d)

May do these six activities in a Cyclic/Spiral approach or using a Waterfall model

Cyclic/Spiral: All activities involved cyclically, first in feasibility study, then again in preliminary design, then again in detailed design

Useful for environments with short development times and uncertain solutions

Not the same as a risk-driven process model generator for software design that has a similar name*

Waterfall: Each activity done once

Useful when solution is well understood or when developing lots of prototypes is not useful (e.g., wheelchair ramp)

Sometimes a combination is used: Appropriate approach used for each subsystem

February 2016 * "A Spiral Model of Software Development and Enhancement", B. Boehm, ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986

15 min. Timed Design Exercise – Make longest Pinocchio “Nose”

Group size: 4 or 5 people sitting “next” to each other (don’t

move around and please join one group only)

Material: Two campus newspapers and a maximum of a quarter of a roll of masking tape

Requirements and Deliverables: One group member (the subject ) must wear the nose, which must be completely self-supporting Specifically, the subject can't use his/her hands or arms to hold up

or to otherwise touch the nose structure

Nose structure can rest on other body parts but must be attached to the subject’s nose

5 Minutes (or less!) : Review Requirements and choose your group’s subject

5 Minutes : Generate Ideas and build long “nose” structure

5 Minutes : Iteration and final clean-up (clean up and measure final nose length from tip of subject’s nose before time is up)

19 February 2016

Exercise Questions

Q: What worked?

Q: What didn’t work?

Q: What would you do differently, if you were doing it again?

Q: Did you document any of your work or decisions?

Q: What would you do differently, if you’d had more time or more resources?

Q: Did everyone understand the requirements?

Q: Did everyone participate ‘fruitfully’?

Q: What would the optimum group size be?

Q: Did you learn anything from watching or listening to the other design teams?

20 February 2016

Exercise Questions (cont’d.)

Q: How long do you think your group would need to design a

better structure?

Q: Could you upgrade or modify your design if the requirements changed or evolved (e.g. the structure needs to support a small weight for an hour)?

Q: What is the longest structure that you think you could build given a day or even given a week to do it?

2m, 3m, 4m, more than 4m?

Q: What type of expertise would have allowed you to do a better job than you did?

Q: How would you change your design if you had to tell someone else how to build 100 more identical structures?

21 February 2016

Lessons I’ve Learned

Trust your instincts and your current expertise You often know more than you think you know

While you don’t know what you don’t know, you can fill in the ‘gaps’ in your knowledge as you proceed... even when time seems too tight to do so… Q: How?

You may not be an expert in a design area (yet) but you will be, if you can learn from others and perhaps also from your own experience too Latter point assumes your designs work well enough to

give you the opportunity to learn from your own mistakes and successes (i.e. you are still in business!)

February 2016 22

Solutions to Common Design Errors

Delay Design decisions until the design problem is understood well enough and until you have enough information and/or appreciate fully the significant design constraints and design criteria

Develop models and ideas that actually ‘do the job’ (i.e. not overly-simplified or superficial ones). G.I.G.O.!

Test prototypes/models well enough and carefully enough to learn the maximum amount during the time available for prototyping

Pay attention(!) during testing and use structured troubleshooting methods to avoid missing important issues or problems

Generate multiple solutions so that you have real alternatives and better final results

Base your decisions on data and consider all of the pros and cons

Do your initial research properly and also document and organize what you have learned so that you remember it and so that others can use the information too Example: Keep a lab book to record your thoughts and insights!

February 2016 23 “Design Practices and Misconceptions: Helping Beginners in Engineering Design”, David Crismond, Science Teacher, v80 n1 p50-54 Jan 2013

Non-Traditional Design Processes

Design Processes evolve as time-to-market pressures increase and designer staffing levels are reduced, especially true for software development

Software development increasingly less based on ‘classic’ systematic waterfall method, in favour of ones which:

Attempt to include the customer in an ongoing basis in the design process (development costs shared too?)

Place higher emphasis on the constant delivery of functional and stable software (i.e. “show as you go”)

Have time-to-market advantages that increase the probability of a final product that customers will still want

Have also been criticized as being less ‘professional’ or ‘predictable’/ repeatable than traditional design approaches

February 2016 24

Current Software Design Methodologies

Adaptive and change-driven rather than plan-driven

Can involve a customer more closely in an iterative type of development approaches:

Example 1: Agile (see basic principles for the approach at http://www.agilemanifesto.org/) accepts requirements change and their evolution is more the rule than the exception, using “just enough” planning and documentation to produce useful code regularly

Example 2: Test-driven sotware development emphasizes creation of test cases or use cases before the functional code to pass the test has been created, followed by “refactoring”/neatening-up step

February 2016 25

26

Outline

Defining Engineering Design

Characteristics of Good Design Practice

The Engineering Design Process

Design Tips

Decision-Making

Design Documentation

System Life Cycle

Design Teams

Conclusions

February 2016

27

Systematic Decision-Making

List all courses of action

List all factors that could affect the design

List advantages and disadvantages for each course of action

Then, choose randomly for a tie, or use a computational decision-making technique (maximizing or minimizing a quantitative function; example taken from Andrews, et al., text, Section 15.5.1)

February 2016

Computational Decision Making

A tabular decision-making method that finds the best choice(s) among several alternatives by maximizing or minimizing a quantitative function

Can help to force a thorough comparative evaluation of the alternatives

Can help to increase the objectivity of a decision (and, therefore, of a report)

28 February 2016

Method

Suppose there are m alternative solutions

Choose n selection criteria for judging the m solutions (each solution already satisfies the design requirements and constraints, so these are criteria that further distinguish between the solutions)

Each criterion is assigned a relative importance, or weight, wi, for i = 1, …, n, such that the sum of the weights is 1 (or 100%)

29 February 2016

Method (cont’d)

30 February 2016

Example

A student lives 2 km from the university and wants to choose the best travel option. There is no bus service, so the alternatives are walking, riding a bike, buying a motorcycle, and buying a car.

Criteria are cost, time, and safety, which are rated at 30%, 40%, and 30%, respectively.

31 February 2016

Example (cont’d)

Operating cost:

Walking has zero cost

A bicycle is estimated to cost $100

A motorcycle is estimated to cost $500

A car is estimated to cost $1000

Thus, the (normalized) ratings are

r11 = 0/1000 = 0; r12 = 100/1000 = 0.1

r13 = 500/1000 = 0.5; r14 = 1000/1000 = 1

32 February 2016

Example (cont’d)

Time:

Walking takes 35 minutes

A bicycle takes 20 minutes

A motorcycle takes 8 minutes

A car takes 8 minutes

Thus, the (normalized) ratings are

r21 = 35/35 = 1; r22 = 20/35 = 0.57

r23 = 8/35 = 0.23; r24 = 8/35 = 0.23

33 February 2016

Example (cont’d)

Safety (somewhat arbitrary safety estimate):

Walking is neutral (0)

A bicycle has a safety level of 1

A motorcycle is 5 times as dangerous as a bicycle

A car is 2 times as dangerous as a bicycle

Thus, the (normalized) ratings are

r31 = 0/5 = 0; r32 = 1/5 = 0.2

r33 = 5/5 = 1; r34 = 2/5 = 0.4

34 February 2016

Example (cont’d)

Each of the 12 ratings is multiplied by its weighting factor, and the results are summed for each alternative

The sums can then be compared to determine the best alternative overall

35 February 2016

Results

36 February 2016

Notes regarding this technique

Determining reasonable weights and precise ratings can be difficult

Example: perhaps the safety rating for the bicycle in winter weather would not be “neutral”

Example: A decrease in a given quantity may be subjectively more important than an increase of the same magnitude

Reasons for the choice of all numerical values should be carefully recorded

37 February 2016

Notes (cont’d)

Weights and ratings should be varied, or additional criterial added, to see how they affect the outcome

A decision that stands up to reasonable changes is said to be robust A robust decision will be the preferred choice because it

will still be the best decision even if some of the numerical estimates (weights, ratings) turn out to be incorrect

38 February 2016

39

Design “Deliverables”

What the designer must give to someone else so that the design can move from abstract ideal to a useful product or system

Usually due on specific dates (“project milestones”)

The timeliness of your design work will be determined by the date of your deliverables

February 2016

40

Design Deliverables (cont’d)

Typical deliverables include: Project plan/ milestones (estimate & multiply by 3) Project budget (estimate, then add 10-20%) Functional specification (critical functions first) Test and validation plan (ensure solution will meet

quantitative benchmarks) Progress reports (how is it going; unanticipated

obstacles) Design logbook (your record of your contributions to

the project [may be useful years later]) Design reviews (external review by clients or

superiors) Design specification (buildable by someone else) Final report (overview, literature review, project

significance, rationale, final outcome, recommendations)

February 2016

41

System Life Cycle

After the feasibility study, the preliminary design, and the detailed design, there is:

Production and deployment Possibly including a pre-production or “beta” version to

correct design issues prior to full deployment

Operation and Maintenance Designers can learn what worked well and what may

need to be changed in the next version

System retirement Occurs when the product needs to be replaced with a

new or redesigned product

Decommissioning may require awareness of environmental regulations for recycling or disposal

February 2016

42

Design Teams

“Design is not just a creative process; it is a social process.” … so it is important to:

Clearly define the team’s goals

Establish and perform the assigned tasks

Create and maintain a supportive team culture

Plan and manage time effectively

Ensure effective team interactions (e.g., team-building activities and exercises; http://teambuildersplus.com/)

The loudest designers are not necessarily the best designers

Establish incentives and rewards for both team and individual achievement

Most design work is done in teams that are not made up of individuals of the same ability or experience level

February 2016

43

Outline

Defining Engineering Design

Characteristics of Good Design Practice

The Engineering Design Process

Design Skills

Decision-Making

Design Documentation

System Life Cycle

Design Teams

Conclusions

February 2016

44

Conclusions

Creativity is a key ingredient in engineering design

At least one study has shown that:

“Creative people think that they are creative, and less creative people do not think that they are creative” (!)

However, it is still essential to practice and so develop your creative skills

there is significant opportunity to do this throughout your degree program

February 2016

45

Creativity is not enough…

Creativity must be coupled with scientific knowledge and technical knowledge, as well as discipline, organization, and social skills if you wish to excel at engineering design.

February 2016

46

Fundamentals of Engineering Design

Bibliography

ELG/SEG/CSI 2911 textbook (Chap. 15)

H. Petroski, Invention by Design, Harvard University Press, Cambridge, MA, 1996

M. Asimow, Introduction to Design, Prentice Hall, New York, 1962

February 2016