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