Design Progress Report
Every other Friday at midnight (or as noted on the syllabus), design subteams must hand in a single design progress report (only one per team) emailed to the Design Advisor. This is a formal report, so spelling, grammar, and sentence structure are taken into account in grading. All figures and tables should be numbered, and well-labeled. Figures and tables should not stand alone. Rather, they must have references and explanations in the text. Below is a suggestion on how to organize the report. The questions are generic questions that subteams should be thinking about during the design process, but not every question will be relevant to each team. Use your judgment to determine which aspects are relevant to your task and need to be addressed in the report.
Late reports will receive a penalty of 10% of the grade for each day late that they are submitted.
Part I: Problem Definition
The purpose of the first section is to describe the problem and solution process. When writing this section, your target audience should be someone with technical engineering knowledge who is not necessarily familiar with AguaClara technology. This will be the only part due for the first design report unless you have already made significant progress. Since most of the information in the Introduction and Design Details below (perhaps with the exception of the “solution approach” subsection, which may change as you delve deeper into your task) will not change from week to week, teams may resubmit these sections from the previous week unchanged. If any changes are made, they must be given in italicized font to distinguish from previously written material.
Introduction
Give a concise description of your task.
- What piece are you working on?
- What function will your piece provide? What problem are you trying to solve?
- Draw a well-labeled picture of any relevant pieces. Pictures should include relevant dimensions where appropriate. The drawing may be either by hand or in AutoCAD, SketchUp, Paint, or using some other drawing program. Specify different views if necessary.
Design Details
Explain the relationship of your task to the existing code.
- What are the dependencies of your code on other pieces? What variables do you need to know? Which of these variables are already calculated?
- Which ones do you have to calculate or assume yourself?
- How might your code affect design considerations for other parts of the plant?
Explain the relevant constraints on your design.
- Are you restricted to using integers? Even numbers? Is there a certain space requirement? Do we want a particular head loss to be limiting? Make sure you keep operator access in mind. People need to be able to easily remove things, reach into things, and clean things. This will affect the dimensions of many pieces.
Explain any assumptions you have to make.
- How did you arrive at a smart assumption? Are you trying to be conservative in your calculations? Are you using a typical or accepted assumption?
Explain your solution approach.
- Provide a step-by-step design (pseudo)algorithm. What are the major things you need to calculate? What equations will you use to calculate them?
- Assign a deadline to finish coding for each solution step or set of steps. You should also assign an additional week or so (depending on the size/complexity of your code) for debugging, testing, and documenting the code.As this report is resubmitted, highlight deadlines that have been met. If a deadline is not met, you must provide a reasonable explanation (details of coding or CADing problems you ran into; being too busy to work on the task is not an excuse) to justify putting off the deadline. Propose new deadlines (in bold) as necessary.
Part II: Documentation
This section is informal. The following sections may be in submitted bulleted list form. Each week, you must submit the documentation pieces of all of the preceding weeks in addition to that week. That means each documentation section must be headed with the appropriate date. List documentation sections in order from earliest to latest and be sure to include all previous documentation sections in every updated version of your report.
Problems Encountered
List specific questions you have.
- Do you need clarification on a particular concept? Are you struggling to understand a specific piece of code? Would you like more help with a particular capability in AutoCAD or Mathcad?
Document any unresolved errors or bugs you have run into.
- Did you notice an error in any existing code? Did you run into a specific bug or error when writing code? If you did, be as specific as possible about the error and when it arises.
Accomplishments
- Explain what parts of the task you completed. Did you complete the code necessary to calculate something? Did you debug a section of code that was causing errors? Did you finish an AutoCAD drawing? Did you work on wiki reports or presentations? Did you go back and document/comment the code you wrote? Did you test your code?
Goals to be reached before next report is due
- What do you anticipate you will have completed? Will you finish up research on a topic? Will you finish debugging your code? Will you finish testing your code? Will you finish drawing an AutoCAD image?
Updating the report
Teams will receive their reports back with comments on both parts. In the Problem Definition part, responses to comments (where appropriate) and corrections must be integrated seamlessly into the report, and they must be bolded to distinguish from previously written material. Do not delete the comments to which you are responding when submitting new reports. In the documentation part, the comments will include suggestions for overcoming problems. Do not delete these comments either so that we can keep track of what works and what doesn’t work.