/Home/References/

References

  1. Project Submission Form (PSF)
  2. List of various faculty suggested projects. (directory)
  3. Introduction To Senior Design - Lecture #1
  4. SD Writing Style, Generic Report Format & Academic Dishonesty
  5. Laboratory Logbook
  6. Guidlines to the content and formatting of the ECE156 PoP Report
  7. Formatting and Procedures for deliverables in ECE156
  8. Formatting and Procedures for deliverables in ECE157 & 158
  9. Context Diagrams (short presentation)
  10. Graphical Representations of Design (lecture)
  11. Design vs. Implementation (lecture)
  12. Economic Analysis for Senior Design Projects (misc. files)
  13. Gantt Charts
  14. Modules/Matrices
  15. Building a Typical Senior Design Electronic Project (lecture)
  16. AutoCAD and MS-Project (short training lectures & other files)
  17. Mechanical Design and Fabrication - Guidelines and Procedures (notes)
  18. Circuit Design Verification Using PSpice/Cadence (lecture)
  19. Design of Software for Embedded Systems (lecture)
  20. Using OrCAD for Printed Circuit Board Design (lecture)
  21. Example BOM (Bill of Materials) for PCB project (spreadsheet)
  22. Example BFD (Board Fabrication Details) for PCB project (zip containing BOM spreadsheet, all product data sheets, OrCAD files, notes, etc.)
  23. Engineering Change Notices (ECN)
  24. Helpful Information on ADC and DAC
  25. Helpful Information PIC micro Controller code development
  26. Test Strategy
  27. Recommended procedure when your first power up your PCB or other circuit
  28. Tips and Tricks For Senior Design Projects (document to be added)
  29. More examples of SD reports - use at your own risk ;-)
  30. Preparing the course evaluation for the multi-instructor SD courses.
  31. Grading worksheet used by faculty reviewers at each of the major project reviews.
  32. Glossary of terms used in PCB design and fabrication (courtesy Sunstone).

Engineering Change Notices

R & D designs are by their very nature developmental. This being the case it is expected that there will, by necessity, be changes that must be made after the final design has been approved. To insure that changes do not negatively affect either the technical or cost of the basic system, these proposed changes must be reviewed. To achieve this end any modifications to the specifications and/or design after the student's final design has been accepted will require review and acceptance by the instructor. This will require submission of what is commonly called engineering change notices. These notices must outline the technical impacts both positive and negative as well as any schedule or cost impacts. The format and mandatory content of the ECN is as follows:

ENGINEERING CHANGE NOTICE

  1. Name of student
  2. Class/Section
  3. Title of Project
  4. Requested Change
  5. Reason for requesting this change
  6. Impact of proposed change on meeting requirements and specifications
  7. Impact of proposed change on interactions and interface of your system with the end user, other systems, etc.
  8. Impact of proposed change on cost
  9. Impact of proposed change on schedule
  10. Impact of proposed change on design and/or implementation details
  11. Approval Section - Approved/Disapproved and Reason

Gantt Charts

Another important technique for charting the schedule progress of a project is through the use of a technique called Gantt (or "waterfall") Charts. This technique allows a graphical representation of the length of time an event requires and its relationship to other events that are also occurring. It allows the manager to review critical dependent events and also to quickly see where scheduled items are not on schedule. A variety of Gantt Chart examples are provided in the sample reports on this web site.

For each report, the following Gantt Charts are required:

  1. An overall Gantt Chart showing all deliverable items over the academic year.
  2. A detailed Gantt Chart for the present reporting period.
  3. A detailed Gantt Chart for the next reporting period.

When incorporating your Gantt Charts into your reports (Microsoft Word) and presentations (Microsoft PowerPoint):

  1. Use the export command in Microsoft Project. Do not try to use a screen shot. It will be blurry, and one will not be able to zoom in adequately to see detail in the chart.
  2. If you, as you should, have a Gantt with many tasks and sub-tasks, do not try to fit the entire chart on one page of your report. Break it up into logical groups of tasks and put each on a separate page or figure, as appropriate.
  3. When breaking up a large Gantt chart into smaller pieces, NEVER EVER separate the left side of the chart (ie, which contains the names of the tasks) from the right hand side of the chart (ie, which shows the bars). The latter is absolutely meaningless without the former.

There are numerous, easy-to-find, good on-line references to constructing Gantt charts. These include (in rough order of increasing level of detail and sophistication):

  1. 1 - Elementary introduction to Gantt charts based on a particular SW product (not Microsoft Project).
  2. 2 - Good, multi-section tutorial for MS Project
  3. 3 - Essentially the same as reference #2. Formatted a bit differently. Included for redundancy should the link to ref. #2 eventually fail.
  4. 4 - In this example, there is a "who" column, but it simply describes the people responsible for the task, not when they actually are scheduled to work on the task.
  5. 5 - In the next-to-last example on that page, they want to show who is working on a task, but they specifically note the fraction of effort of this individual on this task. This is an important distinction between their example and many of the Gantt charts created for the CDRs in which (for example), the project manager is show as if he/she was working at 100% simultaneously on several tasks.
  6. 6 - This page contains links to a series of advanced topics on project management including resource allocation and leveling.

Note: In most projects, there is rarely a simple a one-to-one mapping between tasks and people, and one should not suggest this on your Gantt charts by putting a single name or job title next to each bar in the chart. For example, consider a subtask named, "Integration of mechanical and optical components". One could easily envision one or more mechanical engineers, one or more optical engineers, and one or more integration and test engineers all working on this task, PLUS the project manager overseeing this task, but at a less-than-full-time level.

In addition, the level of effort (ie, hours per day) of each individual working on a task rises and falls during the execution of the task unless you have decomposed the task list to such a fine level that the tasks for each individual are named separately. Even then an individual (eg, 'the' hardware engineer) will almost always be dividing his time between multiple simultaneous tasks. Thus the Gantt chart is a “waterfall” of tasks, not individuals.

Unfortunately, one of the example documents (Paul Gunia's CDR) shows Gantt charts with a single job title next to each bar, and many students seem to copy his formatting and organization without questioning it. Unfortunately, it's virtually impossible to find an example of a deliverable that is absolutely perfect. Every SD document, including this one, has some errors, and this is precisely the reason that there at least three separate cautions on the SD website about using old reports mindlessly:

  1. "...As always, we are not certifying an example document such as this would receive a perfect grade as a PDR if submitted now. For example, there are many subtle and not-so-subtle differences between what was required then, and what is required now.";
  2. " ... However, realize that there is no perfect CDR or FDR. One report may have a great "Theory of Operation" section and not list the citations properly. Another may have done an excellent job on the formatting and organization, but have a poor section on testing. A third may have excellent technical content, but the sections are arranged differently because it was from several years ago, etc. etc. Use the examples provided for general guidance, not for specifics. ..."
  3. "... Here is an example of a Critical Design Report from several years ago. The same caveats about slight changes in the formatting and content over time apply to this report as to all other example documents provided. ..."

Finally, we expect you to use the parts of MS Project that deal with resources and cost estimation to generate a more accurate estimate for the overall labor cost and number of hours in your project. You should compare the estimate from MS Project with the estimate you made before using MS Project as a management tool, and put this information into your report and presentation.

Laboratory Logbook

THE LOGBOOK IS TO BE CONSIDERED REPRESENTATIVE OF A LEGAL AND WITNESSED DOCUMENT AND AS SUCH IS THE PRIMARY REPOSITORY OF ALL DATA TAKEN DURING THE PROJECT. Should there be any infringements or future arguments concerning patent rights, the logbook may be used as evidence of the work. It, therefore, requires the owner to keep accurate and legible records at all times.

Required Information: All the information you obtain and all the work you do is to be recorded in your logbook. It is a continuing history of the work. The information is to be recorded in ink and is to be neat. Any errors or repeats are to be single-lined out or "X'ed out neatly. If for any reason the material must be reanalyzed, it will still be legible.

Any amount of information required before the project starts may be inserted in the logbook. Any material required to complete the project or data in the logbook such as information from standard guidelines (texts, reports, periodicals, meetings, etc.), may be added as the project progresses. The data for a given project must contain the circuit diagrams, software codes and a list of all unique equipment used. If for any reason the project must be repeated, the experimental apparatus can be reassembled from the same material.

The data you enter into your logbook must be of such completeness, WITH ALL DATA RELEVANT TO THE EXPERIMENT INCLUDED, such that you or any other person can write a formal report using the data and using standard guidelines. It is to be further mentioned that all reports are to be written based on the material in your logbook. The logbook is not to be completed using the material from your report. It, therefore, again requires the logbook to be complete and accurate. Be sure to conclude each session with the concluding statement. To summarize, the logbook should be clear and understandable such that a third party will understand:

At the end of each presentation and/or deliverable, the logbook must be presented to the instructor and pages used for recording the progress of the project will be signed by the instructor to verify your work.

Modules/Matrices

Continuing oversight of the status of a project are essential functions of project management To this end project managers use a variety of tools and techniques to determine the current status of the different portions of the work being performed. One of these tools require the "breaking" down of the work into a group of modules or matrices. These modules then are "fleshed " out during the early phases of the project with best estimates of the amount of time that it is anticipated that each particular sub task will take. At each status report the actual times spent on these sub tasks is provided and an estimation made as to what percentage of work has been done.

These modules are written in top down manner showing either one or both of the software modules and hardware subsystems that comprise your product. For each of the modules at the lowest level of the design, the report shows the status of the module. The possible state of each module is;

  1. Outlined
  2. Designed
  3. Constructed
  4. Tested
  5. Documented
  6. Integrated
  7. Redesign

As you move up the tree of your design modules, you can specify the status of the module based upon the status of its component modules. Of course, the state of a module is the same as the least completed sub module of which it is comprised. Thus if each module in the top down design is identified, a tree diagram specifying the state of each module can be drawn to show the status of the entire project.

Another key part of developing the modules is an estimation of the amount of time it will take to bring each module to the integrated state and the time to complete the testing and documentation of the completed product. The report should give a clear picture of the amount of the project which has been completed and the state of the modules that are not yet complete. It should also tell how much time has been spent to get this far in the project and how much more time will be needed for completion of a tested, documented and working product.

A matrix should be shown with each module of the project listed on the x direction. For each of the possible seven states of the module, indicate estimated time, the actual time spent and the percentage of completion.

Using the data shown in modules 1-7, an economic analysis of the project should be given. This analysis should be compared with pervious economic analysis and an explanation given for any changes in the projected cost of the product. Be very clear to describe any changes in the specifications in the product from those that were in effect when the original economic study was made.

Test Strategy

An important part of your product development is a test strategy and plan. This plan must specify how you will test each part and software module of the project as it is being developed and built. In addition, you must show how this will be done while the different hardware and software components are integrated together. You must specify:

  1. Exactly how the tests are to be run
  2. The test set-ups
  3. The inputs for each test
  4. The expected outputs for each test.

Your project must be constructed in a modular manner and each module must be tested. This may require that you build some test software and/or hardware that is not part of the product but is needed for testing. You should have enough tests to exhaust every possible input for the module under test. When you finish the testing of the module, you should know that it works. Please note that you may need to purchase test parts/components in addition to what you are required to submit to the instructors.

After the module has been thoroughly tested it should be integrated with the previously tested modules. These integrated modules should then be completely tested so that you know that the product is working correctly as of this part of the integration. Using this technique, any problem which occurs can only be due to the new module which you just added. It is not due to the previously tested and working modules. All of the tests must be recorded in your laboratory notebook and of course the results of the tests must be recorded.

Writing Style

An engineer should not only be able to design and test systems. He or she should also be able to accurately describe the design and test results of that system. This description usually is in the form of a formal report that is subject to peer and/or customer review. Reports can be presented in oral or written form, sometimes both are required.

Formal written reports must adhere to a specific format and should be typewritten using a word processor taking full advantage of spell checkers, etc. A general outline of a formal report is given below. The specific outline for each class deliverable is given in the corresponding deliverable descriptions. Each student must write and submit his or her own report. The report can not be someone else's verbatim work. PLAGIARISM IS AN ACT OF ACADEMIC DISHONESTY AND WILL NOT BE TOLERATED! Quotes and other information from outside sources must be acknowledged by detailed citations.

To avoid any suspicion of plagairism, you not only need to provide appropriately detailed citations / endnotes, but you must also have your intellectual contribution to the project and/or report clearly delineated from quoted material. For short passages (written by others) that you want to incorporate in the body of your report, the standard means is to use some combination of italics, quotation marks, and/or indentation. See any of the standard style manuals for a longer discussion of this. If you don't do this, a reader simply has no way to tell where your writing ends and where the copied material begins.

If you wish to include more lengthy passages (ie, more than a paragraph or two) from other authors, it is usually not appropriate to have such material in the body of your report. Doing so could reduce your fraction of the body of the report to an inappropriately small value, even if you had written quite a bit of material (in absolute terms). In such cases, the standard approach is to place the quoted passages in a series of separate appendices, clearly stating the source, page number, and paragraph number (or figure number) of the original document.

For extremely lengthy quotes, you should simply provide the entire source document(s) (in electronic form) as "supporting documentation". This should be emailed to us at the time of electronic submission, as well as burned onto the required CD for each deliverable.

Liberal use of text and figures from other sources should generally be discouraged. The overall effect of the liberal use of text and figures from other sources in the main body of a report dilutes the student's intellectual contribution to the report. Limiting the use of text and figures that are not produced by the student should be encouraged. Place supporting text and figures from other sources in an appendix where the source, page number, and paragraph number (or figure number) of the source information is clearly indicated.

It is unnecessary to burden the reader with background information that is not essential to the design of the project. Include only specific background information that is necessary to support a design decision or to understand the theory of operation of the device.

You can use Wikipedia as a quick introduction to a topic, but you should only use it sparingly as primary reference in your report. Peer reviewed journals, IEEE technical documents, and textbooks serve as much more reputable sources and thereby provide more credibility to your report.

Basic circuits, components, and simple devices that are of the public domain (ie: simple circuits such as voltage dividers, amps, comparators, etc.) should be drawn by the student instead of cutting and pasting a figure from another source. Not only does this prevent the dilution of a student's intellectual content in the report but it could eliminate the work of referencing an external source. Having figures that are easily edited also makes it a simple task to modify figures in future versions of the report as a design evolves.

Use an equation editor to typeset formulas into the body of a report. Number the equations and refer to the equation numbers in the text. Please do not cut formulas from other sources and paste them as bitmaps into your report. The Microsoft Equation Editor is simple to use, formulas will be easier to read, and the formula font will match the surrounding text. A report will appear much more professional if the equations are typeset.

Major sections of a formal report are:

The report is to be written in your own words, use single space typing, and be prepared with word processing software. No handwritten material is allowed. The report is to be written in the third person.

DETAILED EXPLANATIONS OF MAJOR SECTIONS: