33.4 DELIVERABLES
The following items are to be submitted at various stages of the project.
33.4.1 Conceptual Design
Concepts are normally communicated with sketches that make the overall design clear. Components that would be expected for this type of design are,
- Sketches should be done using normal drafting practices. A good set of sketches will include 2-D, isometric and pictorial views.
33.4.2 EGR 345/101 Contract
This project involves participants from EGR 101 and 345. Although the students are at different points in their academic careers they are all considered peers, and should have equal voices in the team. To help clarify issues of differences between the EGR 101 and 345 students, a 'contract' will be written that formalizes the responsibilities of the students in EGR 101. As with most contracts, it outlines a process that is mutually beneficial. In this case both parties are expected to benefit in an educational sense. The contract will be written in such a manner that if all requirements are satisfied work will be marked 'as-is'. In the event of a failure, marks will be deducted to hold the responsible party(s) accountable.
33.4.3 Progress Reports
Teams are expected to submit progress reports on a weekly basis. These reports will include the following elements divided into sections with a heading for each. Point form is preferred, but complete sentences must be used. (Note: 'Parts purchased' should be 'Parts were purchased for the cart assembly.') Each section should include items completed since the last report, and current action items. If there is nothing to be said about a category use 'no changes', 'nothing done', or 'complete' as appropriate.
Cover Page - a cover sheet indicating the course, project and tema numbers. The names of all team members should be listed on the cover, including the EGR 101 team members.
Design - Design changes should be indicated. Appropriate drawings, schematics, or equivalent should be included. When appropriate, these should normally be accompanied by a new set of models, calculations and/or simulations to verify the new design.
Software - The current status of software development should be indicated, including major accomplishments and issues.
Early in the semester, other items will be requested, such as a combined timetable for all team members, and a skills inventory. These should only be included in the reports the weeks they are requested.
33.4.4 Design Proposal
The design proposal is used to present all of the design details in a single document. The focus of this document is a MINIMAL AMOUNT OF TEXT, but a thorough presentation of the design details. Typical elements are listed below in a typical sequence;
- a budget listing each of the parts that must be purchased/acquired. Catalog pages and quotes can be used to validate the budget. In the final report, copies of receipts, or catalog pages will be required.
- additional calculations for mechanical design issues, such as stress that may result in failure. Normally these result in a factor of safety.
33.4.5 The Final Report
The final design will follow the same structure as the Design Proposal, with the addition of the following elements.
- the drawings, calculations, etc. should be based upon the final design. It is reasonable to write a page or less about the modifications that were required, but it is a minimal/optional part of the report.
The report should concisely and clearly describe the design, as shown in the diagrams, drawings, calculations, etc. In general the format of the report is as outlined below. Sections and subsections should be numbered.
Design description - this section should describe the mechanical, electrical and software design aspects. Subsections should focus on the following elements;
The tests that were done to describe the overall performance. There should be a comparison of the device with and without sway compensation.
Conclusions - A brief description of the overall results indicating what the strengths and weaknesses of the design.
Final reports will be evaluated on numerous factors inculding the clarity for the design documentation (i.e., how clear is what has been done?), theory to backup the design (does the theory match the actual design?), did the theory and actual match?