Project Design Lab in Electrical & Computer Engineering

Documentation

We require two forms of documentation—a log and a report.

The Log

The purpose of a log is to record the design as it unfolds. Thus it is process based. It is also a legal document. All students are expected to keep individual logbooks in which to record all ongoing project activity. This would include design ideas, design notes, discussion of alternatives, lab measurements, schematics, etc. Basically, any activity you undertake on the project should result in a log entry.

Logs are legal documents and must adhere to legal standards. Traditional logs are in the form of permanently bound notebooks (not looseleaf) with numbered pages. Entries must be dated and signed and should be made in ink. Pages may not be torn out nor may erasures be made. Instead errors should be lighlty lined out (so the original is still legible) and a correction made in the margin (or a notation giving the page number of a longer correction).

We have an experimental web based logging system and computer engineering students are required to use it to keep soft logs. Electrical students may use either the traditional bound logbook or the webLog. Your log is worth 5% of your mark. Instructors may ask to see it at any time.

The Report

The report is in the form of a live document. A live document is one that is constantly updated. It is not intended to capture the design process but rather the current state of the project. There is only one report required per team.

To promote the goal of keeping live documents up to date we will be using the CVS repository to archive the document. Each team will have their own repository and all team members (as well as the instructors) will be able to access it. Because CVS does not deal well with word documents, we will be using HTML. Everyone will adhere to a common format. Drawings will be stored in the document as .gifs or jpegs as appropriate. To prevent constant recreation of drawings, original source drawing documents (e.g. pspice) will be stored in the repository as well.

Format

The skeletal report format hs been zipped and may be downloaded here. It includes a readMe.htm file in its root. Please don't alter the format. Also, do not use word-processors to automatically generate HTML as they do a very poor job.

The project report template is now ready. It has been designed to include a degree of automation, not all of which is implemented yet, so it is important that you use it correctly.

The template does two things for us.

  1. It provides you with a guide as to how to structure your project report. This should save you time in the long run since all you have to do is worry about content.
  2. It also separates content from appearance, which will allow us to create a uniform look across the course, leveling the playing field and making it easier for us to focus on your content and not your style (except of course for writing style).

This is the mark I version. Being designers, we have focused on the structure of the site, not the appearance, so you may well think the documents you produce are ugly. That's fine. We'll work on appearance plus the embedded scaffold on the mark II version. Meantime, so long as you structure your documents properly, they should work just fine with either Mark I or Mark II.

The template is in the form of a skeleton web site that has been zipped up. We recommend that one member of your group download, unzip and install it in their own system, then read the readMe.htm file in the root, then edit the variables in the constants.js file to tailor them for your team and finally upload the resultant files and folders to CVS.