Project Proposals

For this class, you have a semester project. Now that you are somewhat familiar with the class, it is time to start thinking about your final project.

The project proposal is an initial write-up of what you are doing. The purpose is to make sure your group plans to do an appropriate amount of work. That is, it should not be too easy nor too ambitious. The project proposal should contain the following:

• Names of your group members. You need to identify who will be on your team. It may be possible to work by yourself under certain circumstances; see the professor for permission. Teams typically have 2 or 3 members. It may be possible to work with more than 3 people under certain circumstances; see the professor for permission. No matter how many people are on your team (even if you work by yourself), you must provide justification for why you need that number. Teams should include only graduate students, or only undergraduates, unless given permission.
• Who will do what. You need to assign roles to each teammate, e.g. coding, debugging. If your team has 3 or more members, you need to justify the need for this number of people.
• Other info. Include class name, professor's name, and due date of the project proposal.
• Introduction. Express what you plan to do. This should be a brief (not too technical) overview. What is your motivation?
• Tasks. Give details about what you plan to do. Break the project up into smaller sub-projects, and identify the steps that will accomplish each one. Set realistic goals.
• Equipment needed. List any hardware and software that you need to do the project. Do not assume that our department will purchase equipment! If you choose to use your own equipment, you do so at your own risk.
• Safety precautions. Identify any potential hazards, and how you will ensure that no one (including you) will get hurt. For example, if your project requires soldering, this must be done in a well-ventilated place.
• Supporting material. Include any graphs, equations, pictures, etc. to convey the idea of what you are trying to do. As always, cite where any material comes from if you did not create it yourself. This means including the reference in the caption, like "Figure 1 - Example system configuration [1]."
• Similarities and Differences. There are other projects like yours (e.g. YouTube videos, Make Magazine articles, previous class projects, etc.). What are they? How are they similar? How is yours going to be different?
• Timeline. For each sub-project, determine when you plan to have it completed. Keep in mind the semester schedule.
• Milestones. Include specific things to accomplish. These are unique to your project, and are not likely to be things that other projects do. You can include these with the timeline, but be sure to identify them. For example, "identify and review additional research papers" might be appropriate for the timeline, but this is not specific to your project, and is not a milestone. "Milestone 4: Get the green LED on the Duemilanove Arduino board to blink one, two, or three times within a 2 second interval when the user presses button one, two, or three, respectively" is specific to a project. Calling it "milestone 4" identifies that it is a milestone.
• References. Include the resources you plan to use. This should include books and papers that deal with the subject. Use a minimum of 2 books and 2 peer-reviewed papers per person. Include a brief rationale, such as "this book appears to be a good reference on ____". Graduate theses and dissertations can count as books.

The title page (project name, team members, class, etc.) should be on a page by itself. The other items above do not need to be on a separate page - just use your best judgment.

When writing, remember that we are looking for quality, not necessarily quantity.

Type your work. If you want to include a graph or drawing, these should also be done via a computer.

Turn in one copy of your proposal per team. This is a team effort, and it is up to you to make sure that the work is fairly distributed across your team. The professor reserves the right to replace team members if needed (e.g. if a team member fails to show up for team meetings, he may be replaced by someone who will). There are going to be group dynamics to consider, which is one of the reasons why this is a team project (and a valuable experience). For example, one member may be a strong programmer, but does not communicate well. Another person may be a good leader, while inept with hardware. Learning to overcome individual difficulties and challenges in building your team is an important part of the semester project.

The professor will let you know if your proposal needs to be revised. Go ahead with the project as planned unless you hear otherwise. If you find you need to change something major (e.g. you cannot obtain the software in time, so instead you want to solve a different problem), be sure to inform the professor.