Home Project Ideas Project Guide Ask An Expert Blog Careers Teachers Parents Students

Engineering & Programming Project Tips

Outline

Comparing the Scientific Method and the Engineering Process

Scientists study how nature works; engineers and computer programmers create new things such as machines, programs, and techniques. Because engineers and computer programmers have different objectives than those of scientists, they follow a different process in their work.

Comparison of the Scientific Method and the Engineering Design Process

The Scientific Method The Engineering Process
State your question Define a need
Do background research Do background research
Formulate your hypothesis, identify variables Establish design criteria
Design experiment, establish procedure Prepare preliminary designs
Test your hypothesis by doing an experiment Build and test a prototype
Analyze your results & draw conclusions Test & redesign as necessary
Present results Present results

This guide will describe the engineering process in detail and highlight how it can be applied to a science fair project in many areas of engineering and computer science. Note: If you are doing an engineering or programming project, it's still important for you to read the other "how-to" material for non-engineering projects. It contains a lot of important information that we do not repeat in this document.

Overview of the Engineering Process

Big Array Hearing Aid

One important concept comes up again and again in the engineering process; it's called iteration. Iteration is a procedure in which you repeat a sequence of steps, each time coming closer to your goal. While it would be nice to do everything once and have a perfect design, there are actually some pretty good reasons why iteration is the norm. We will be iterating our description of the engineering process (see, we can't even describe the process without iterating), and by the end of this document you should have a good understanding of why iteration is a normal and in fact desirable part of engineering design!

Let's look at the engineering process in more detail:

  1. Define a Need: What do users of your product need? Is it a new version of an existing product that has more speed, lighter weight, or lower cost? Or, is it a product with an entirely new combination of features never before seen, like the first light bulb invented by Edison in the 1800's.
  2. Do Background Research: Investigate what others have already learned about your idea. Gather information that will help you design your invention. Don't reinvent the wheel.
  3. Establish Design Criteria: Design criteria are requirements you specify for your design that will be used to make decisions about how to build the resulting product. For example, you might set out to design a baseball bat that has design criteria calling for the same strength and size as an aluminum bat, but half the weight. These criteria would rule out making the bat from balsa wood (not strong enough) or steel (too heavy). They would lead you to look at materials like carbon fiber composites (very cool stuff, but expensive).
  4. Prepare Preliminary Designs: Good engineers look at a variety of different possible designs before moving forward. It's much faster and cheaper to look at alternatives on paper before actually building something. At the same time, a good set of plans will uncover problems that are expensive and time consuming to fix once you're actually building something. Each preliminary design is likely to have some good points and some bad. As you continue to generate new designs you incorporate more and more of your best ideas. You guessed it -- you iterate your designs!
  5. Build and Test a Prototype: A prototype is the first full-scale and functional model of your invention. You build it from what you think is the preliminary design that best meets your design criteria. Sometimes it is impossible to meet all your design criteria and you need to choose a compromise.
  6. Redesign & Retest as Necessary: Almost every prototype has unanticipated flaws, things you overlooked or design features that did not work the way you intended. Engineers redesign their products to "get the bugs out," and retest them until everything is as it should be. This process of redesign and retest is another example of iteration.
  7. Present Results: In a science fair you present your results as with any other science fair project, by showing your work on a display board and by demonstrating your invention if possible. Of course, engineers working in industry present their results by putting the product into manufacturing so that others can buy it.

Who Should Use the Engineering Process for Their Science Fair Project?

In real life, the distinction between science and engineering is not always clear. Scientists often do some engineering work, and engineers frequently apply scientific principles, including the scientific method. Much of what we often call "computer science" is actually engineering -- programmers creating new products. Your project may fall in the gray area between science and engineering, and that's OK. Many such projects can and should use the scientific method.

However, if the objective of your project is to invent a new device, procedure, computer program, or algorithm, then it may make sense to follow the engineering process.

Below we highlight some things you would do differently for the steps or assignments of completing a science fair project if you follow the engineering process.

Important Note: Most but not all science fairs accept engineering projects completed using the engineering process. Some even encourage it. However, if in doubt, you should check with your fair before you follow the engineering process instead of the scientific method.

Define a Need Instead of Asking a Question

Instead of stating a question, engineers state a customer need. What is it that you think customers want? Later you'll have an opportunity to refine what you believe are the customer needs when you specify the design criteria.

Background Research Plan & Bibliography

If you follow the engineering process your bibliography will be the same as for other projects, but you need to ask additional questions in your background research plan. In addition to understanding the science of how your invention will work, you also need to:

  1. Define your target user or customer. Everything man designs is ultimately for the use of another human. (Think about it, even products designed for animals or plants are first purchased by another human being!) Your choice of target user will sometimes have a big impact on your design criteria. For example, let's think about our baseball bat example. Imagine you want to design a bat with the same strength and size as an aluminum bat, but half the weight. If your target user is a child, then cost would also be very important. If your target is a professional baseball player, cost might be less important, but league rules about what materials can be used for bats would be very important. You might specify your target user in any number of ways. Here are some examples:
        - Age (old, young, infant)
        - Gender (in America you wouldn't sell many dresses made for boys!)
        - Occupation
        - Hobby interests
        - Amateur or professional
        - Disabled or not disabled
        - First time user or experienced user
  2. Research what already exists to fill the need you defined, or needs that are very similar. No one wants to go to all the trouble of designing something they think is new, only to find that several people have already done it. Jeeez, would that be depressing? So, you want to investigate what's already out there, only then can you be sure that you're making something that better fills a need. And, keep in mind that what is "better" depends on your criteria. You might want to build something that's been around for hundreds of years, but do it with recycled materials from around the house. The device might be old, but the construction materials new (or used!).
  3. Do research that will help you establish your design criteria. Defining your target user and researching other products set the stage for your next step -- researching possible design criteria.

Now let's look at how to generate actual research questions.

Generate your keyword list the same way as described in the how-to page entitled Background Research Plan.

These are some example questions that will help you understand the science needed for your design.

After you clarify the definition of your target user, you'll want to ask questions like this:

Then, ask questions to help you understand products or programs that fill similar needs to the need you identified:

All the above questions seem fairly straightforward, don't they? Now things get a little trickier when we start thinking about possible design criteria to research. Anything that can be measured or perceived by your senses can be a design criteria for an invention, the possibilities are truly limitless. Limitless! That probably reminds you of that bad dream you had with your teacher asking you to write a 500-page paper by tomorrow morning. But, don't panic. Only a handful of potential design criteria are likely to be important for your project; the trick is deciding which ones.

A good place to start is your need statement. In your need statement you probably called out a need that either specifies or at least suggests some design criteria. For example, if we want to design a bat with the same strength and size as an aluminum bat, but half the weight, then likely research questions would be:

You'll probably want to do part of your research plan and part of your research, then iterate. Understanding the science, customer needs, and products or programs that fill similar needs will give you more ideas for design criteria that you should research.

Nonetheless, just to help you brainstorm, here are several lists of possible design criteria. It would be rare if all the ones important to you were here; it would be equally rare (but still possible) that none of yours are here.

Sample Design Criteria

Cost is almost always a design criteria
- Cost to purchase
- Cost to use
- Cost to repair
How does it look (we call this aesthetics)
- Style (art deco, Victorian, modern, medieval)
- "Fit and finish" (is it built with care and attention to detail)
Geometry
- Size, overall dimensions
- Curvature
Capacity (how many and how big are the things it can work with)
Physical characteristics
- Weight
- Density
- Melting, boiling point
- Color- Transparency
- Reflectance
- Surface texture (polished, rough)
- Elasticity
- Hardness
- Ductility (capable of being drawn out or hammered thin)
- Magnetic properties
- Electrical properties (resistance, impedance, etc.)
- Impact resistance
- Bending strength
- Viscosity
Performance characteristics
- Accuracy
- Strength
- Reproducibility, repeatability (does it always do the same thing given the same input)
- Speed
- Acceleration
- Deceleration, braking
- Rolling resistance
- Friction
- Adhesion
- Absorbency
- Permeability (do things leak through it)
- Resolution
- Flammability
- Insulation value
Inputs
- Energy consumption
- Fuel consumption
- Labor
Outputs
- Product produced
- Power
- Pollution
- Undesirable side effects ___________
Manufacturing considerations
- Difficulty of making
- Equipment or manufacturing techniques required to build the invention (you don't want to build something from metal if all you have is a woodworking shop)
- Number of component parts
- Labor requirements
- Means of shipping or delivery
Environmental requirements
- Operating temperature range
- Storage temperature range
- Water resistance
- Resistance to corrosion
- Compatibility with ___________
- Ability to withstand radiation (called radiation hardness)
User requirements
- Ease of learning
- Ease of use
- Operator training
Regulatory & licensing considerations
- Meets government rules
- Meets league rules (a sporting product)
- Does it require paying a patent or license fee
How does it hold up?
- Service requirements
- Ease of repair
- Reliability
- Lifespan
- Disposability
Acoustic characteristics
- Pitch
- Sound transmission
- Resonance

Sample Design Criteria for Software Programs

Software Products & Programs The Computer Environment for Software Products & Programs
- Functionality or feature set
- Capacity (how many and how big are the things it can work with)
- Type of user interface (command line, standard Windows or Mac look & feel, totally unique)
- Customizability
- Speed, responsiveness (be specific: speed of what)
- Ability to communicate with other programs (data import / export)
- Type of error handling (none -- not recommended!, error number, messages with help)
- Programming language written in
- Portability (ability to move to another operating system)
- Ability to modify to work in other spoken languages (this is often called localization)
- Operating system
- CPU speed
- Memory size
- Display size and number of colors supported
- Single user or network environment
- Peripherals required (scanners, printers, disk drives)
- Other software required (language interpreters, browsers, etc.)

Every product area has some of its own criteria; these are just a few examples:

Clothing
- Comfort, wearability
- Fabric
- How to clean (dry clean or throw it in the wash)
- Iron or permanent press
Aircraft & Rockets
- Lift
- Drag
- Thrust
Food Products
- Taste
- Nutrition value
- Perishability (how and how long can it be stored)
Genetically Engineered Bacteria
- Gene to be added or deleted
- Characteristics of gene expression

Summary

For a project in engineering or programming, follow these steps to complete your background research plan:

  1. Identify the keywords in the needs statement (question) for your science fair project.
  2. Generate questions to help you understand the science needed for your design.
  3. Define your target user or customer.
  4. Ask questions to help you understand products or programs that fill similar needs to the need you are trying to fill.
  5. Use your needs statement to identify some likely design criteria to research, and review the above list of design criteria to see if some apply to your project.
  6. Iterate!

Review of Literature

For an engineering or programming project, the Review of Literature should include:

  1. The definition of your target user
  2. Answers to research questions about the science behind your design area
  3. Answers to research questions about user needs
  4. Answers to research questions about products that meet similar needs
  5. Answers to research questions about design criteria
  6. And, a brief discussion of any important design tradeoffs

What's a design tradeoff? Sometimes you will have design criteria that "fight each other" or tend to move in opposite directions. For example, materials to make our baseball bat lighter in weight are probably more expensive the lighter they are. You can't have the lowest weight and the lowest cost at the same time; therefore, when we design our bat we will have to make a tradeoff between cost and weight.

Design tradeoffs are very, very common. Almost every project has some.

Establish Design Criteria Instead of Variables and Hypothesis

As we mentioned in the beginning, engineering projects (at least the ones involving the invention of a new product or program) don't really have variables and a hypothesis, instead the next step is to establish design criteria.

We already discussed design criteria a couple times, so we must be iterating. Yup, we are. Hopefully, by now you have a much better understanding of what the most important design criteria are to successfully meet the need called out in your question.

How many criteria should you have? That's a really good question, without a good answer. You should have neither too many nor too few. (Oh, that's a big help!)

The reality is that experience is very important in deciding how many design criteria are important. It's another good time to ask your mentors, parents, and teachers for advice, but do so by asking specific questions. Tell them the design criteria you are considering and ask them which ones you might be able to do without.

Here are some other thoughts to help you. If you have too many design criteria, it can become very difficult to actually design and build a product. Imagine having a friend whose parents have set ten times as many rules as your parents. (Wow, scary thought.) Such an imaginary friend might have difficulty doing things because he or she would always be violating one of the rules. Having too many design criteria (criteria are a type of "rule") creates a similar situation. With too many criteria, design tradeoffs increase and many design decisions become unnecessarily complex.

What is "too many" depends on the product. An airliner might have thousands of design criteria and that could be just right. For a project that you have time to complete for the science fair, two or three, maybe five design criteria are appropriate.

Why might too few design criteria be a problem? If you have too few criteria you might get a result that you don't really want. Let's say we built our lightweight, high-strength baseball bat, but it cost $10,000 for the prototype. When your parent gets the bill, you would experience a very bad result! The baseball bat should have at least one more criteria, one for its cost. So, don't be a slacker on your design criteria.

By the way, professional engineers call a design with too many criteria over constrained (as if it had too many rules) and one with too few criteria under constrained (as if it had too few rules).

Do a Materials List & Preliminary Designs Instead of Materials List & Experimental Procedure

Engineering projects have a materials list, programming projects probably don't. While both engineering and programming projects could have a procedure, it makes more sense to prepare preliminary designs at this stage of the process.

You might be asking why you need a design, let alone need to iterate your designs. Iterate, schmiterate; you might think you've got it all in your head. You wouldn't be the first person to feel this way. In a book he wrote, here's what the founder of Science Buddies said about building things during his youth:

"Being extremely impatient, I hated to draw plans before I started building--it took too much time! My dad was an excellent draftsman and he always drew a sketch before building anything. He tried to teach me to do the same, but instead I liked to just visualize everything in my head, then hammer away. As the things I built became more and more complex, the lack of adequate plans became troublesome. I remember when I first tried a telescope mount I was building. As I swung it around the polar axis, it clanged into another part of the mount and I had to rebuild it so I could look at the whole sky. Eventually, I learned what my father had been trying to teach me: it's important to have a plan" (Hess 2001, 3).

Rarely is your first design the best (often it won't even work). Iterate until you have a good plan.

And, just in case it's not obvious, you need to put your designs on paper (or type them into a computer). You'll see things you wouldn't see in your head, and you'll be able to refer back to your plans to remember details you would otherwise forget. Written or printed designs and plans also let you share your ideas and get feedback from other people.

Build & Test a Prototype Instead of Conducting an Experiment

When others are conducting their experiment, Investigators doing an engineering or programming project should be building and testing a prototype of their best design.

Important tip: Make sure you involve some of your targeted users in your testing. It's vital to get their feedback about your design.

Redesign & Retest versus Data Analysis & Graph

When engineers and programmers test and retest their creations, they too are doing data analysis. For example, they might measure the performance or improvement of their creation. So, even though we call this step "Redesign and Retest," it usually involves data analysis, just like for a project using the scientific method. Almost always, you will want to present the results of your testing and retesting in a graph.


Reference List

Hess, Kenneth L. Bootstrap: Lessons Learned Building a Successful Company from Scratch. Carmel, California: S-Curve Press, 2001.