README.md: The root directory of your repo should contain a README.md that
Lists sub-directories and describes their meaning/content/use. For example, it may have an entry like:
* `ui` contains a Cordova user interface
If you completed any bonus items, you must also list them.
Working source code for all components:
Embedded system(s)
UIs
Developer Documentation in docs/developer/.
This is expected to include a README.md (there should be a docs/developer/README.md) and any other beneficial documentation (like Sequence Diagrams, circuit diagrams, etc.)
Your audience is a future CSE222 student. Assume that a student has taken the course and will be given your project and told to make a specific change (add a feature, fix an error, etc.).
What would they need to know to setup your project and get it running?
What would they need to know to modify it? (Assume that they don’t want to read through all your code - they want some sort of a quick start guide that will help them identify where they should start looking/working first)
Assume that the feature will be assigned to them. You can’t make any assumptions about how they may need to modify your work, so you should give a general overview of all aspects of it with sufficient detail for them to know where to look to make modifications.
Examples of modifications could include
Changing timing of some hardware feature
Adding a new sensor or output to the device that needs to be shown or controlled from the UI
Adding a new “page” to the UI.
User Documentation in docs/user/README.md.
Assume a non-technical person would like to use your project. What do they need to know to get started and to use specific features? (You can omit initial setup)
Submission & Checkout
Demos will take place in three phases:
A 15 minute demo with your TA during class time. This will test the major functionality of your project and do an initial review of your repo.
A 4 minute “elevator pitch demo” to the instructor (Bill) / 1 minute Q&A.
This should demonstrate the major functions of your project
Evaluation will be a subjective/competitive. It will take into consideration:
Overall merit of the project as an IoT “product” (is the project beneficial enough to be justified)
Thoroughness and quality of work demonstrated
You only have 4 minutes to demo and will be cut off. It would be best to rehearse and identify the most significant features to demo in the limited time.
Post-class review of your Repo & submission
A more thorough review of your submission
Rubrics
TA checkout / Demo
Successful demo of all major features (34 points)
Demos and tests of features by TA succeed (TA will be actively trying to find flaws/problems)
-1 point per each “minor” flaw (minor inconvenience or slight failure that doesn’t significantly undermine the product’s utility)
-5 points per each major flaw / failure (I.e., something that would be considered a significant failure or inconvenience by someone who bought, invested in, or had to use the product)
-5 points per significant omission (major features that were originally proposed but not implemented)
Repo appears complete (6 points)
Primary README.md: 2 point
User Documentation: 2 point
Developer Documentation: 2 points
Instructor Demo: 10% total
Rough rankings:
10 Exceptional project compared to peers
5 Average work compared to peers
1 Significantly below average
Final Repo Review: 20% total
Developer Documentation (8% of project)
Rating from 1-8.
8 Provides an excellent overview for future students resuming the work (sufficiently detailed and comprehensive, but not overwhelming. Easy-to-follow).
4 Average. Provides many details, but many omissions or overly detailed/difficult to follow.
1 Poor documentation. Not sufficient for future students.
User Documentation (5% of project)
Rating from 1-5.
5 Provides sufficient details for a user to operate the product and is easy to read/follow.
3 Significant omissions or confusing
1 Poor documentation / missing many details or very hard to follow