fundamentals of engineering designcadams/courses/2911/week04(03feb16...* "a spiral model of...
TRANSCRIPT
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
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
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