>>Speaker: Hello.
Today we're going to talk about
the engineering design process.
All engineers design things at some point in their career.
They could be designing a physical object;
they could be designing a piece of software or a process.
But engineers design things;
it's one of the ways that they solve problems.
And as an engineer, it can be a little overwhelming
when you first encounter a major design project.
So what we want to show you
today is a process that you can use to
help break that design project down into
little bits, and be more successful than
you would be if you just sat down and
started designing just offhand.
So you've seen this slide before; this is the
problem categorization slide,
and it shows the various types of problems that
you can encounter.
And you can have anywhere
from not enough information,
to just enough information to access information,
and your problems may have no answer,
one answer or more than one answer.
When you're in the classroom,
typically you encounter classroom
problems that have one answer,
and you're given just enough information.
And we talked about on the problem-solving
methodology day, how the problems you
encounter can fit into any of these categories.
Well, typically with engineering design,
you are encountering problems
that have more than one answer.
You may be given not enough information,
you may be given just enough information,
or you may be given way too much information.
But typically the problems that you encounter have
more than one answer,
and so part of the engineering
design process is determining which of these answers
is best for your product
and for your application.
So here we have a slide that shows you
the combination of problem-solving and design.
And so you can compare the two of them.
so you can see the DRPIE, the define, represent,
plan, implement and evaluate cycle on the
left hand side in the gray.
You can also see the engineering design process
over here on the right,
and you'll see that there are
some aspects of them that are very similar.
So some of the -- the obvious one is define;
it appears in both places, so I have
define, and I'm defining my problem.
Represent will often take place in a couple of places;
one of them may be when you're
creating the specifications and requirements.
It may also appear over in
creating the design concepts,
and possibly over in designing of the solution.
So represent kind of is all throughout there.
Planning tends to occur over here
in the designing of the solution.
Implement tends to appear over here,
in creating the prototype and to
an extent in designing the solution.
And evaluate tends to happen over here with
testing and validating the design.
So it's not quite a one-to-one comparison,
but you do see a lot of similarities
between problem-solving methodology
and the engineering design process.
So we shouldn't be venturing too far from
stuff that you're at least familiar with
in a cursory fashion.
So this is the engineering design process,
and we are going to go through and talk about
each of these aspects or each of these stages
one at a time here in the next few slides.
But I just want to give you the overall picture.
And one of the things that I want you to keep in mind
as we're going through each of these stages is
that this is not necessarily a linear process.
Just like problem-solving methodology,
you may be halfway through your evaluate,
and you realize that something was wrong
with your implementation.
And so you have to go back
to one of the earlier stages.
Similarly, in the engineering design process,
you may have be in the middle of
creating a prototype and realized that
you wanted two parts to occupy the same space.
We know that that can't really happen,
so maybe you're stepping back
over here into designing the solution.
Or maybe you're designing the solution and
you realize that your design is not
sufficiently constrained.
So you have to go all the way back over here
-- to creating specifications and requirements.
So at any point in this process,
you can jump back to any of the
previous stages as needed during the
design process.
Where does this design process
fit in the general lifecycle of a product?
Well, you start out with somebody needing something,
and then you design the product.
This is separate, for our purposes,
from implementing the project.
So you notice if you look back
at the engineering design process that
we stopped over here in testing and
validating the design;
we don't actually
go through to creating and releasing the
final product that's for our purposes
considered to be a separate step.
Once you've implemented the project, you're not done.
A lot of engineers think,
I've implemented the project, I'm done,
I can walk away and enjoy my beautiful product.
That's not what happens;
people break your products;
they will use anything as a hammer.
And in the process
your product breaks and you're going to
have to find a way to fix it,
or to modify the product so that it makes a
better hammer.
And then eventually your product is supported,
it's maintained and eventually it's used up and it's
disposed of or recycled in some fashion.
The rest of this presentation focuses
here on the engineering design process;
although the rest of the product
lifecycle is important, that's not what
we're going to be focusing on today.
So here we're in the stage where we are
just beginning out, and we need to define
what our problem is.
So we want to understand what the problem is
in some level of detail;
we're not necessarily
going to need every little specification,
every little requirement, but we want to
really get a good grasp on what's going
on with the project.
So you start out
with a general project needs statement
of what basically you need out of this
product that you're creating.
And the product -- again it doesn't have to be a
physical product; it could be a process;
it could be a software package,
lots of things it could be --
but you start out with some rough idea of what you want,
and then the goal of defining the
problem is narrowing this down into a
defined set of projects needs.
So this is going from saying that I need a phone
that is better than the other phones.
This is the stage where I define what
exactly it is I want better about that phone.
So am I looking for improved
coverage; is the wireless capabilities
supposed to improve, is it going to take
better photos, is it meant to be more
user friendly.
So you come down and you
figure out exactly what the project
needs are.
Then once I figured out roughly what the project needs are,
I then get down into the more nitty-gritty
specifications and requirements.
And this is a really important stage in the
engineering design process, because this
is really what lets me know when I'm done.
As an engineer you can design and
design and design and put more and more
time into your product,
but this specification and requirement stage
gives me an endpoint, so that, when I've
met these specifications and
requirements,
I know that I've reached my desired goal.
So this may be, I want to be
able to talk on my phone in this
specific location that tends to have
trouble with reception,
or I want to be
able to take a photo in, you know,
half a second without delay from when I press
the shutter button.
So these are my specifications,
and they really give me
my goals and my endpoints for my design.
And so once I have these specifications
and requirements,
I can also plan out a high-level project plan.
What are the components to my
project, how am I going to progress
through those stages, and design each of
those stages.
I can plan out my project
and it's really important that I give
myself milestones.
And some of them will be really being milestones,
some of them will be small milestones,
but my goal should really be
to break up what I'm doing into small
manageable pieces and give myself some
sort of deadlines along the way so that
I don't reach two days before the
project is due and realize that I have nothing done.
If I had milestones along
the way I probably could have prevented that.
Phase three involves creating the
design concepts.
So I now have my
specifications and requirements,
I have my high-level project plan,
and now I'm
going to think about all of the
different ways that I could approach
this problem and all of the different
solutions that I can come up with.
And there are lots of different methods that
are used in the stage.
A lot of people use brainstorming,
where you come up with
as many ideas as you can as quickly as
you can, there's no judgment,
so some really silly ideas sometimes come out,
but you end up with a good variety of
ideas from which to choose and build and
they can grow on each other.
I also want to create some sort of method by which
I'm going to evaluate these design
concepts that I've developed.
One method that is often used is called a design matrix,
where I have different criteria
that I plan on evaluating for my
different designs and I give each of
those a weight, so that I can evaluate
each idea based on these criteria, end up
with a total score, and from that total
score I can determine what my best
design is going to be.
Somehow through
some combination of coming up with
different ideas, thinking through them
evaluating them, I come up, then, with a
best solution.
And best solution can be a
little bit of a misnomer here because
it's what I think at this stage is the
best solution.
Chances are the first time you go
through this stage, the best solution
that you come up with is not going to be
the solution that you end up using,
But it's based on what you know so far, what
you think the best solution is going to be.
Once I've chosen this best so I then design the solution,
and so this is where I really sit down and plan
everything out and sketch out my design,
if it's a physical system or plan out my
algorithm; if it's software --
-- something like that,
this is where I get down into
the nitty-gritty design;
I spec components and I determine what the flow
of my code is going to be.
All of those things go on in this design solution stage.
Now I want you to realize that we
are now in stage 4 of 6 and we still
haven't built anything and that's
intentional.
This has all been preparation and planning and thinking
and designing.
This allows us to to save
money and not go down rabbit trails on
designs that we don't end up choosing as
our best design or designs that we
haven't thoroughly thought out.
Actually building things and going all the way
through that process is a fairly
labor-intensive process, so my goal
should be to have a well designed system
before I ever start actually building anything.
If I just sit down with a bunch
of materials and start putting them
together without a lot of forethought,
chances are I'm not going to end up with
a very good design.
And we want to avoid that,
and so we do spend a lot of time
here planning before we physically start
touching materials and building things.
Phase 5 is where we actually create the prototype.
So this may be code that's intended
to work with a subset of data,
or to perform a subset of the desired
processes, or work under very controlled
circumstances, or maybe this is a
mechanism that I build out of cardboard,
or rapidly prototype it, so this is a not
my final product.
This is a prototype
where I haven't spent all the time to
make it perfect and pretty.
It's just something that gives me a good
proof-of-concept to show that this
design that I've created is actually
going to work.
So then once I create this
prototype, I can test and validate my
design, and I can run my prototype
through all of my different
specifications and requirements and see
whether it meets those specifications
and requirements.
Once it meets the
specifications and requirements,
I have a validated design and I'm done and I can
I'm done with the design process.
Chances are the first time I reach this
stage, probably the second and third time
I reach this stage, the design that I've
created is going to fail my
specifications somehow.
And so at this stage,
it's fairly likely that I'm going
to have to run back to designing the
solution and maybe improving it somehow,
or even choosing an entirely different
design concept.
So in summary, engineers use the
engineering design process as a proven
way to make sure that you're meeting the
project's specifications and
requirements in regards to functionality,
on time and within budget.
And it seems like a somewhat cumbersome process when
you first sit down and start it, but this
is how experienced, expert engineers go
through this process in order to design things.
And the reason they do that is
because it works.
And so in class, we are
going to be going through an exercise
that helps step you through each of
these, so you have a more practical
understanding of what is entailed in
each of these stages.