My view of the Senior Design class may vary slightly from what you hear in class and hear from other students. In fact, all project advisors have different views and expectations -- just like different bosses you may work for will all have different views and expectations of you. No big deal. You have to adjust. But we have a common view of what design is.

To me, this class is not just about getting something to work -- although your grade will suffer severely if your project doesn't work in the end. To me, this class is about the design process. The point of doing a significant design project is to demonstrate that you understand what design is all about. I expect you to not only produce a working project, but to demonstrate that you have learned something about the process of design.

Design is a process of compromise. You take competing requirements, specifications, and constraints and you produce a novel artifact that meets the specifications within the constraints. Time and money are always constraints and that is particularly true of this class. But the constraints of time and money are no different from the constraints of Newton's Laws or the laws of thermodynamics -- if you don't properly consider all the important constraints of your design problem, you have failed to some degree. There may be some negotiation on requirements and specifications -- often, the customer doesn't really know what they want or need -- and that is part of the design process that engineers must master. But this, too, must be mastered in a rational and methodical way.

What Do I Expect?

• Brainstorm - you must consider a wide range of solutions for every problem and you must be able to show (through documentation) that range of ideas you considered.
• Refine - your design should evolve. Ideas should appear and disappear as problems are resolved and compromises are made.
• Assess - as you make compromises, you must continually consider the impacts on requirements and constraints. You must have a documentable history of how this evolution continuously improves the design product.
• Implement - test your designs. Prototype. Verify your assumptions and calculations are correct. You must produce a documentable history of supporting computations, experiments, and data on which your design is based.
• Nurture - a design group is like a marriage -- if you don't put effort into the relationship it will fall apart to the detriment of its offspring. It is your responsibility to manage your group and its offspring (the project).

I am the project advisor. I am not the project leader or the project manager. Those are your jobs. I strongly suggest you select a project leader to manage the overall project and act as chief liason between me and the group. You must trust and respect this person's authority as he/she will also be responsible for ensuring you all deliver on your respective contributions and work constructively to iron out inevitable misunderstandings and incompatibilities. If you don't take control of your own group, I will let you fail.

Fortunately, this is a year-long class that properly respects the importance and difficulty of the design process. University guidelines suggest that an average student should expect to spend about 3 hours per credit hour per week to receive an average grade. University guidelines also suggest that a C is an average grade. So, for a group of 4 students, it is reasonable to expect that the group put forth over one thousand hours of productive effort outside of class, just to get a C.

The phrase "productive effort" is important here. Project courses are notorious for being time-intensive because students can easily fall into unproductive traps - hours wasted debugging a memory leak, lost orders for parts that cause delays, design oversights that lead to unexpected behavior. You are not graded on your effort expended but on the results achieved. If you do not produce an impressive project demonstration with an impressive design portfolio you do not deserve an impressive grade. Furthermore, not all group members will put in equal effort. If you dutifully put in 8 productive hours per week on the project, you may be only compensating for the 4 hours per week one of your lab partners expended. The team must collectively produce impressive results to be rewarded with an impressive grade.

On one hand, this is a daunting challenge. If you colletively want an A from this class, you must be willing to spend about two thousand hours (some productive, some not-so-productive). On the other hand, think of the exciting things you can accomplish with 2000 hours of engineering effort!!

Dos and Don'ts

• Do come to me when you need advice.
• Do ask clear intelligent questions - I may be able to save you a lot of time
• Do be persistent...I am busy and may not respond to e-mail
• Don't ask for a design review by e-mail. If you have a clear question, ask it. If you're not sure what to ask, plan to go over the design in person.
• Don't expect a time-critical response by e-mail. E-mail is valuable, but very limited in expressivity and easy to overlook.
• Don't expect your designs to work first time. Plan to overcome obstacles.
• Do follow-up on everything. An ounce of prevention is worth a pound of cure.
• TAKE NOTES when you meet with me and others! (electronically or on paper) It will help with your follow-through.
• Do maintain high expectations of yourself and your team mates.
• Do have fun and enjoy the process! (despite the occasional setbacks)

Engineers are Precise

I expect you to be precise in your questions, in your answers, in your code, in your writing, and in your work in general. This is something to practice, to strive to improve. But it is something you must commit to do actively, as it is not always a natural trait. I may frequently ask, "what do you mean by that?" Think deeply about your assumptions and how your "audience" can misinterpret your words or thoughts. Read my Coding Style Webpage for Dos and Don'ts specific to software and writing. Use good coding and commenting style from day-one! ...on every single piece of code or document your create or use! Do NOT comment-after-the-fact or you will lose points!

---

Copyright: © 2005, 2016, 2019, 2021, 2023 by Richard M. Voyles. All rights reserved.

---

rvoyles [at] purdue [dot] edu