Quick Guide

1. Planning Your MQP

Every MQP progresses somewhat differently depending on the individual student's needs, the advisor's interest, the student's motivation, team dynamics, and many other factors. While this looseness might be disquieting for some, it can be the MQP's biggest asset since it allows you to participate in a real engineering project that you have a hand in defining, thus allowing you to fully experience the thrill of solving a challenging problem and the agony of chasing false leads.

2. Important Dates

Since your choice of an MQP topic may influence your course selection and schedule for your senior year, you should plan to find an MQP as soon as possible in your junior year. Detailed information concerning the registration procedure for an MQP is available online through the Global Experience Office (for off-campus projects) and ECE department (for on-campus projects). 

3. How to Complete a Successful MQP

Generally, an MQP has five phases: Project Definition - Research - Design - Evaluation - Reporting. Since MQP is a multi-stage comprehensive project, you should meet regularly with your project advisor and follow the project schedule closely.  

Project Definition

During the project definition phase, you will begin to determine exactly what you will do for your MQP. The idea for the project might be something that you thought up on your own, or it might be one of the project ideas that have been presented by the faculty. The process of defining the project usually involves writing a project proposal. The proposal might be as short as three to five pages, and it generally includes the basic definition of the project along with the project goals, projected schedules and budgets, and the methodology you will use to satisfy the project objectives.

You should start the "project definition" phase before the registered project term takes place. This phase should also involve selecting a team to work with you. A typical project proposal has the following sections: introductions, literature review, methodology, schedule and budget, and project specification. During the first term of your MQP, you'll probably spend a lot of time refining this proposal.

Research

The research phase of a typical MQP begins in the first term. You’ll start refining the initial proposal that you wrote to get the project going. Based on your initial proposal, your advisor will probably have comments and suggestions for sources of specific information you will need and will identify areas you now need to explore. During this phase, you will start following up on all of these directions. Your biggest source of information for this phase will probably be your course notes, texts, and the library. Through the library, you can also gain access to many electronic books and journals.

Once you've completed the research phase, you will be fairly knowledgeable about the problem on which you are working. You will know what others before you have done, how well their approach worked, and how you can do better. You will fully understand the nuances of the problem and will know the tools and techniques needed to solve the problem better, faster, or less expensively than anyone else. If you've kept careful notes along the way, you will also have a significant store of information that will prove useful when you write your MQP report.

Design

The design phase of a project can take many forms, depending on the nature of your particular MQP. For example, in a theoretically oriented MQP, the design phase might consist of completing the proof of a new technique for calculating the effects associated with some physical phenomenon. In order to test this technique, you might have to develop a program that performs the necessary computations on a variety of examples for which theoretical or experimental results already exist. For hardware-oriented projects, the design phase normally involves taking the detailed specifications derived through your research and designing and building a circuit that you expect will satisfy them.

Although each MQP will have different kinds of design components, the design phase is really that time when the theoretical knowledge you have accumulated about the project, along with the skills you've learned in the classroom, are applied to solve a real problem. In engineering terms, design is when you take a theory and reduce it to practice. This means creating theoretically justifiable designs, not making guesses and creating a working design through trial and error during system debugging.

Evaluation

Proving that your design is correct can be difficult, but it is essential. For example, if you are designing a new heart rate controller for a pacemaker it's no good to tell the patient that it "should" work. You've got to demonstrate that it does work (and will continue working). Part of this proof is done in the design phase where you calculate the current flows, power dissipations, logic timings, and other design parameters. The rest of this proof is done when you take your constructed device into the laboratory and test it.

Again, the nature of the testing depends on the specific type of project. If you're building a board that will be launched on the Space Shuttle, you'll be putting your design in ovens and refrigerators (to test thermal cycling) and putting it on shaker tables (to verify mechanical stability). If you're testing theoretical results, you may be running experiments and taking measurements to correlate theory with observation. In either case, the purpose of the evaluation stage is to ensure your design meets the specifications you derived. Indeed, by the time you successfully complete the evaluation phase it's quite likely you will have done additional research, updated your design, and re-evaluated your results one or more times.

Reporting Results

The MQP report documents the entire project. In this report, you will present the project, the research you did, the details of your design, and the results of your evaluation. It would be difficult to overstate the importance of a quality report, and, even though it is the last thing you will turn in related to the project, you should start writing it when the project begins. Appendix B contains information describing the style of the report in detail.

The MQP Oral Presentation is similar to the written report, but is presented in a more abbreviated format. Details on the oral presentation are contained in Appendix C. In brief, the oral presentation will briefly introduce the project, describe the major innovations that made the project succeed, present an evaluation or demonstration of the project, and then will conclude by assessing the project status and prospects.

4. Contacts for Further Information

For general information about MQPs contact Professor Ted Clancy x5778

For information about the MQP Project Laboratory, contact James O’Rourke x5233.

For information about the ECE Shop, contact William Appleyard x5869.

Appendix B

Written Report Guidelines

Introduction

This appendix is intended to provide guidelines for preparing the written MQP report which is submitted at the conclusion of the project. Most of these guidelines are based on common sense. They are offered to help improve the overall quality of the MQP report and should be used in conjunction with other campus resources to prepare a quality project report.

As with everyone else, an engineer's primary means of communication is through spoken and written English (in this country). Do not subscribe to the stereotype that engineers have a poorer command of English than other professionals.

A high-quality report is an essential element in the evaluation of the project by your advisor. In addition, the project report is the vehicle by which the results of your work are disseminated. It must be structured correctly and written precisely if it is going to be of any use to the intended audience. There is no excuse for misspelled words, incomplete sentences, or poor punctuation in a report.

Writing should not be left until all of the work has been completed. The ``write as you go'' method of report generation often saves time and headaches in the end. By writing the report in installments, you will avoid omitting an important measurement before the equipment has been taken down. The process of report writing often results in the need for more technical work in order to make the project complete. In addition, it is a lot easier to write about things when the work is still fresh in your memory.

Remember the ideas, the findings, and the conclusions put forth are the primary purpose for the report. Following these guidelines will help ensure that the reader is presented with a report that follows an orderly presentation, is well documented, and is free of mechanical flaws. The content is up to you.

Format and Style Issues

The format and style of the report are the first things the reader will see. Attention paid to details of the report format and structure will complement the written content. These issues are dealt with by Turabian[1]. Your report must be typed.

Report Format

Any technical report can be broken down into three main components:

• Front matter
• Body
• Reference material

The physical formatting of each page should be according to the specifications published by the archival body, generally in a library. In the absence of these, a good rule of thumb is to allow one inch on the top, the bottom, and the unbound side. A margin of at least one and one quarter inches should be allowed on the side of the page that goes into the binding.

The front matter consists of the following:

• Title page.
• Abstract. This is a short, stand-alone description of the project that conveys the problem, the approach, the solution, the results, and the conclusion(s). An abstract is often the first thing to be read and will determine whether the reader decides to go further. The abstract should contain the maximum amount of specific information. For an MQP, the abstract should be limited to about 80 words.
• Acknowledgments (optional).
• Table of contents. This list of page numbers indicates where to find each section in the report. Major and minor section divisions should be listed in the table of contents.
• List of figures, captions, and page numbers.
• List of tables (patterned after the list of figures).
• Executive summary. This can be thought of as an extended abstract. It should contain a terse discussion of all significant goals, work, and results of the project. Limit it to no more than five pages.

The body of the report is where you put the substance. Generally speaking, it should contain an introduction to the problem, your objectives, a review of pertinent literature, and the details of your approach to the problem. It should end with a summary of what you have done and your conclusions. It should be constructed of well defined divisions such as chapters, sections, and subsections. Each division should be numbered, with each section numbered to reflect the chapter. Each subsection should reflect the section.

The reference material consists of the material you referred to in the body of the report. If you point the reader to any books, technical papers, reports, or manufacturer's information for more details regarding something you discuss, your reference material would include a list of technical references. The style of these references is discussed in Section C.2.2.4 below. Other appropriate reference material would be included through the use of appendices. Material appropriate for inclusion in appendices include experimental data, computer programs, detailed schematics, device data sheets, and anything else that adds to the report's completeness but is not appropriate for inclusion in the report body. Copies of readily available material should not be included in the appendices; reference to the material is sufficient.

For many engineering design projects, the report should contain a maintenance and/or user manual. This manual should be a stand-alone section and included as an appendix that is referred to in the body of the report.

Report Style

Virtually every technical report uses figures, tables, equations, and references to aid with clarity, succinctness, and completeness. This section addresses how these items should be included in the report.

Figures and Tables

A figure or table is used to better illustrate a point.

A well-designed figure or table can save you a lot of writing while doing a better job of getting your message across. An important example would be the use of timing diagrams to describe the operation of a microprocessor system.

A figure is located as close as practical to, and preferably after, the first place it is referenced, but it should not split up paragraphs. The figure is accompanied by a number and caption, both of which go below the figure. Use the number when you refer to a specific figure.

An example of a correct figure reference: "The basic algorithm for performing integrity monitoring is illustrated in Figure 1." Proper figure format is shown in Figure 1. Figures should be numbered consecutively within each major division of the report, that is, if your report is broken down into chapters, number each figure consecutively within that chapter. Each figure number should reflect the major division. For example, the first figure in Chapter 2 would be referred to as "Figure 2.1."

         Figure 1: Generic RAIM Algorithm

The caption associated with the figure should be able to convey some understanding of the figure to the reader without reference to the report text. Proper sentence structure and punctuation should be used in the caption, complete with a final period.

Figures should be in black and white only. This makes mass reproduction possible because not all photocopiers reproduce all colors. In addition, color figures may become ambiguous when photocopied into black and white. Figures should not be drawn freehand.

Drawing packages such as Corel-Draw are available on the department PCs and tools such as Xfig are available on workstations that you may use to create proper figures. Similarly, a variety of tools are available for creating graphs.

Also, a figure does not substitute for clearly written text. Every figure should be both referenced and explained in the supporting text.

A table is just like a figure with two exceptions:

The number and caption go above the table. When referring to a specific table, the word table is capitalized and never abbreviated. Figures and tables should be numbered separately but with the same numbering convention. A sample table is given in Table 1.

Table 1: The design summary for the 8/14 VRM

8

14

0.169 rad

0.195 rad

outer diameter:     146 mm

rotor slot diameter: 133 mm

stator diameter: 112 mm

air gap: 0.127 mm

stator trunk diameter: 52 mm

shaft diameter: 40 mm

N: 276 turns

Equations

Equations are a natural component of technical reports. Each significant equation should be displayed. That is, it should not be buried in the text. If the equation is ever referred to in the text, the equation should be numbered to facilitate the reference. The number should be in parenthesis at the right margin of the equation.

This format is shown with the definition of the total harmonic distortion (THD):

(1)  A sample equation reference would be "As noted in Equation 1, the THD ..." Notice that references to equations take the same form as references to figures. Also note that equations should include proper punctuation. Punctuate an equation just as you would a sentence.

If any calculations are presented in the report, the SI system of units should be employed. The only exception to this would be when the use of SI units deviates from the accepted set of units for that field. For example, the semiconductor devices field usually uses centimeters, not meters, as its fundamental length. In any case, the units being used should be stated explicitly.

Abbreviations and Acronyms

Define abbreviations and acronyms the first time they are used. Acronyms that will be recognized by any practicing electrical engineer do not have to be defined. Acronyms that do not need to be defined include IEEE, SI, MKS, CGS, ac, dc and rms. Redefine acronyms when first used in the text even if they have been defined in the abstract. Avoid using acronyms in titles. Accepted unit abbreviations may be found in most introductory texts for your subject area.

References and Bibliography

References are used to direct the reader to more explicit information about a topic. You need not include a direct quote from the source in order to justify your reference. The following text is an example of how you might use a reference.

Thus, the basic requirement of a GPS integrity monitoring system is to alert the user if their reported position is outside of the accuracy requirements for the current phase of flight. Furthermore, the user must be alerted in a timely fashion so an alternate source of navigation information can be used. Table 1 lists the typical integrity monitoring requirements for various phases of flight[3].

The reference number is enclosed in square brackets.

Example:

[3] "Minimum Operational Performance Specification for Airborne Supplemental Navigation Using Global Positioning System (GPS)," RTCA Document RTCA/DO-208, July 1991.

It is important that references be complete.

A typical reference should provide the following:

• Names of authors
• Title of paper
• Full title of journal
• Year of publication and volume number
• First and last page numbers

For a book, the author, book title, publisher, and year of publication should be stated, along with the chapters to which you refer. For other types of documents check a style guide for the appropriate reference format.

Some Common Mistakes

The word data is plural, not singular. The subscript for the permeability of free space is zero, not a lower case o. In American English, periods and commas are within quotation marks, like the period at the end of "this sentence." A parenthetical statement at the end of a sentence is punctuated outside of the closing parenthesis (like this). (A parenthetical sentence is punctuated within the parentheses.) A graph within a graph is an inset, not an insert.

The word alternatively is preferred to the word alternately (unless you really mean something that alternates). There is no period after the et in the Latin abbreviation et al. The abbreviation i.e., means that is and the abbreviation e.g., means for example (note comma with each). These and other foreign language phrases should be set in italics.

When expressing volumes, use either of these forms: "" or ";" do not use "." In the text, tables and figures, use a zero before decimal points: "0.25," not ".25."

Do not mix complete spellings and abbreviations of units. Use "" or "Webers per square meter," not "." Spell units when they appear in text: ". . . a few centimeters," instead of ". . . a few cm."

Report Content

The report is intended to be complete documentation for your project and it should reflect that. It should be detailed, complete, concise, and precise. Don't waste your time and the readers' time with extra words. Completeness and precision do not imply a lot of words. Technical papers are a good example of this.

The precision of your words is very important. Just as in the legal profession, many technical words have precise concepts associated with them. Loose usage of these words may seem like a way of avoiding the usage of the same words over and over again. The more likely result is a confused reader; be consistent with your choice of words. For example, electric motors and electric machines are not necessarily the same. While every electric motor is an electric machine, not every electric machine is an electric motor.

Also, do not use an imprecise word (such as several) when a precise word (such as three) is possible. It is usually apparent when vague language is being used as a substitute for the technical work that would enable precision. This is damaging to the quality of the report and the overall quality of the project.

You should view the project report as a document that reflects your learning experience. Dead ends should not necessarily be omitted from the report. If they were significant, put them in. Having said this, it is also important to realize that the report is not a diary. The organization of the report deserves careful thought over and beyond how the project was executed.

The level of the report should match the intended audience. An MQP report should be written so that any junior electrical engineering student can understand it. This is particularly true of any user's or maintenance manuals that are included with the report.

If the project report has multiple authors, you have a little more work ahead of you. Care must be taken to be sure that notation is consistent between authors. In addition, it is very easy for multiple authors to repeat each other. Outlining the report before the writing begins will help eliminate redundancy.

Strunk and White[2] do an excellent job of illustrating and then describing ways around common writing problems. It is a short book and the time invested in reading it before you begin writing in earnest will be repaid in reduced revision time and improved readability of your report.

Your advisor's job is to make sure your report is technically correct. Everything else is your responsibility. You should not expect your advisor to spend his or her time correcting your English. If the writing is poor, don't be surprised if your advisor refuses to read it. If your advisor must help you with your English, don't be surprised if your grade reflects this fact. By this point in your career, you should be competent in written communication. If you are not, take advantage of the writing resources offered on campus. The Writing Resource Center may be able to help you understand the types of writing mistakes you are making so that you may become a better writer. Don't hesitate to use its services. The Projects Office also has handouts on how to write a project report.

It is vital to allow for multiple drafts, with time to critically read each draft and make all necessary changes in content an organization. It is unreasonable for you to expect your advisor to be able to turn your drafts around in 24 hours. Plan your time accordingly.

Summary

This appendix has provided a brief overview of what is expected in an MQP report. Most of these guidelines have dealt with the mechanical features of the document. While these are easier to take care of than the actual report content, their importance cannot be overstressed. Following these guidelines will result in a report that has the essential components of a professional-quality report.

References

1. L. Turabian, A Manual for Writers of Term Papers, Theses, and Dissertations, The University of Chicago Press, 1973.
2. Strunk and White, The Elements of Style, 3rd ed., Macmillan Publishing Company, 1979.

Appendix C

Oral Presentation Guidelines

Introduction

This appendix is intended to provide some general guidelines for the content and style of oral MQP presentations. The ability to give effective oral presentations is one of the most important skills a technical professional can possess. No matter how good your work is, if you cannot effectively communicate its results and significance in both written and oral formats, you and your work will not be fully appreciated.

Fortunately, the MQP provides an opportunity for you to gain experience giving an oral technical presentation. This presentation is a requirement in the Department of Electrical and Computer Engineering.

While some of the guidelines refer specifically to MQP presentations, and others to technical presentations, many of them are common to all presentations. No matter where your career path leads, it is highly likely that you will need to develop effective presentation skills to be successful.

You will be called upon to give presentations to supervisors, managers, prospective employers, clients, customers, research sponsors, colleagues, conference attendees, and so on. You will be judged not only by what you have to say, but also by how well you say it, and even how you look while you are saying it. This document will try to address some of the concerns resulting from this fact of professional life.

Designing Your Presentation

A presentation must be carefully tailored to the specific format, audience, presentation media, and level of formality associated with the presentation forum. In this section, the appropriate form and content for an MQP presentation will be discussed.

Format

The format for MQP presentations is very brief; typically five minutes per project plus five minutes per project student is budgeted. (Thus, a two-person team gets 15 minutes, etc.) This time also includes questions from the audience, so the actual presentation time is less. The brevity of this format may please you at first, but it is one of the most difficult things about the format. Simply put, there is not nearly enough time for you to give a detailed description of your project.

Your overview must give the audience a general appreciation for these points:

• What you did
• Why it’s worth doing
• How you did it
• How well it worked

More specifically, an outline of your talk should be like the outline of a written report:

• An introduction that describes the problem and motivates its solution
• A brief background section that describes such things as special theory or devices you used, or previous work done on the same problem by others
• An approach that gives a broad overview of your solution to the problem, preferably at the macroscopic level
• The results of your work, including (when appropriate) a demonstration
• A conclusion, perhaps touching upon improvements or future work that could be done

It is extremely unprofessional to exceed the allocated time for a presentation. Focus on the "big picture" at the expense of technical details. There simply isn't enough time to talk about everything you've done. Tailoring your talk to the right length and level of detail might require several tries.

A demonstration of your project is nice, if

• It is brief and to the point
• There is something that can be easily seen or heard by everyone in the room
• You are sure that it will work

Audience

The audience for MQP presentations generally consists of junior and senior ECE students and ECE faculty, plus assorted family and friends. The level to which you should gear your talk is that of a competent junior or senior ECE student, i.e., assume that the listener understands basic ECE concepts. The talk should be accessible to the students without boring the faculty to tears.

Presentation Media

It is said that a picture is worth a thousand words; depending upon the image resolution and the richness of your vocabulary, it may even be worth more, from an information theoretic viewpoint. The visual aids you use for your talk can make a deep impression (good or bad) on your audience. The best visual aid for this type of presentation is a set of viewgraphs (also known as overhead slides or transparencies). These can be easily generated by a photocopier from any clear original with good contrast. Every major point in your presentation should be represented in some form on a viewgraph. They convey information to the audience and help to prompt the speaker.

Some guidelines for using viewgraphs:

• A horizontal format is somewhat better than vertical; it is easier for the eye to scan horizontally than vertically.
• Use typeset material; MS Word or some other document preparation system is recommended.
• All viewgraphs should be easily readable from anywhere in the room, so large type (14-16 point) should be used to generate them.
• Do not overload your slides. It is better to keep them simple and use a few extra than to cram them full of information.
• On the other hand, each slide should contain more than just a few words. Try to achieve a balance.
• Data, such as tables, graphs, etc., should be particularly clear, uncluttered, well-labeled, and easy to understand.
• Don't put up a slide unless you're going to give the audience enough time to look at it. If you're rushing through them, you have too many.
• On the other hand, if a slide is up too long, it is either too detailed or irrelevant to what is being said. A good balance is usually achieved by a rate between 0.5 and 1 slide per minute.
• A block diagram describing your system or procedure is usually a good way to describe the project. Make sure that any block diagrams are kept simple by combining subsystems into systems, etc., until the diagram is easily understandable.
• You might want to have a felt-tip marker with you in case you need to write on your viewgraphs during the presentation to clarify or emphasize something.
• Take care not to stand near the projector, where you will block the view for a large segment of the audience. It is best to stand near the screen. If you wish to point out details on your slides, use a pointer at the screen.

Remember that your viewgraphs don't have to tell the whole story—that's what you're there for. They should, rather, focus the attention of the audience to key points and provide a basic understanding of how any pieces of the project fit together.

Level of Formality

The word that best describes the impression that you should try to give the audience is "professional." This applies to your appearance, manner of speech, and visual aids. You should dress as if you are going on a job interview. Speak in clear and complete sentences, avoiding slang and obscure technical jargon.

Your viewgraphs should be typeset using some sort of package designed for the presentation of technical materials; the one you are using for your report will probably do nicely, as long as you can select an appropriate font size (or enlarge it on a photocopier). If hand drawings must be used, they should be very carefully prepared.

Presentation Style

Once you have determined the content of your talk and visual aids, you must pull it together into a presentation. This will require practice—it’s easy to find yourself tongue-tied the first time you attempt to describe or explain something, even if you understand it well. Here are some pointers for preparing the presentation.

• Introduce yourselves, give the title of your project, and indicate who the advisor is. This information should be presented on a title slide.
• Don't jump into the details of your project until you have given the audience enough introductory and background information to understand what your project is all about.
• If possible, try not to read from your viewgraphs. It is better to use them as cue cards with brief phrases or lists serving to remind you of the topics you wish to discuss. If you find that you absolutely have to read from the viewgraphs, at least try to ad lib a bit of introduction, insight, and/or summary.
• Practice, practice, practice. The first run might be just among the project partners, or in front of some close friends. Then, recruit some ECEs to listen and give you feedback and questions. Ask them to be brutally honest. After a few tries, you should have the length of the presentation down to within a few minutes. Now you are ready to give the presentation for your advisor, who may suggest that you change the whole thing. Do so, for this person will be grading you. Then go back to the beginning of this paragraph and start over.
• Don't go too fast. This is a common problem for nervous presenters. People would rather be a little bored than completely lost; remember that most of your audience may have never even thought about your project before. Make sure that important ideas have time to sink in; give enough time to look at any figures, equations, etc. that may appear in your viewgraphs.
• For multiperson presentations, transitions should be smooth. Lead into the following section ("Now that the problem has been defined, Joan will describe our approach..."); tie into the previous section ("As we have mentioned, verifying Ohm's Law will require some resistors...").
• Try to make your conclusion as upbeat as possible while still being honest. Even a project which does not produce a working system can have educational merit. Be sure to acknowledge anyone who has contributed significantly to the project other than the project team and advisor. Welcome questions.
• Look at the audience. A person speaking from behind a pile of notes is incredibly boring.

Handling Questions

The best way to handle questions from the audience is to be prepared. Elicit questions from the practice audiences. Try to anticipate anything that might confuse or intrigue people. Be aware of anything you have done that is unconventional or impractical, and be ready to discuss why. Your advisor may be of some help here.

It is a good idea, if you can anticipate certain questions, to prepare "backup slides" for answering them. For example, there may be derivations, data, circuit diagrams, or whatever that were too detailed for the main body of your presentation, but would serve to answer a tough question quickly and painlessly.

Don't try to snow anyone; if you don't know the answer to a question, say so. Perhaps someone in the audience can provide an answer; ask for a little help if you need it.

Logistics

Each presentation will be assigned a specific time slot and room; multiple parallel sessions will be held throughout the day. You should attend the entire session; don't just come in for your presentation. One reason is that any canceled presentations will change the time of yours; another is courtesy to the other presenters.

Be sure to contact your advisor immediately if you cannot give your presentation at the assigned time. If your MQP schedule makes a D-Term presentation impossible (e.g. if you finish and graduate in B-Term), see your advisor to schedule a presentation during your final term.

An overhead projector and screen will be available for your use in the presentation rooms; you are responsible for any other equipment you might need for a demonstration (extension cords, etc.) If you plan to do a demonstration, be sure to arrange your apparatus so that it is easily moved into place for your presentation and out of the way when you are done without causing disruption to the proceedings.

You may make your overhead slides in the ECE department office. Transparencies are quite costly, so each group is limited to 15 without charge. Make draft viewgraphs on paper to use in rehearsals; practice with the final versions (and show them to your advisor) before making the actual transparencies.

Plan ahead; there will most likely be a long line on the last few days before presentation day.

Summary

Effective presentation skills come with practice; as your career progresses, you will gain more confidence in expressing your ideas to others. This MQP presentation is not meant to be a traumatic experience, but rather a chance to share the results of your work with the WPI community. Be sure to take full advantage of this opportunity by preparing a high-quality presentation.