Sentimet Project
Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.
Milestones and meetings
An important part of managing a long-term team project is effective time management. The purpose of the milestones and deliverables is to keep you on track to avoid a heroic effort right before reviews.
What's a milestone? What's a deliverable?
A milestone is accomplishing a particular task in the evolution of the project. A deliverable is how you demonstrate that you have accomplished that task.
For example, one requirement of the term project is to measure the local weather, let's say through temperature and relative humidity measurement.
From that requirement comes as set of specifications, for example you may decide that you need to measure temperature in the range of -20 deg C to 50 deg C, with +/- 2 deg C accuracy (note, these are probably not going to be your actual specs!).
Next, you have to figure out how to implement that functionality, and then test it. So you may decide that it will take you one week to get the temperature sensing up-and-running, and then you will spend a week testing that outdoors.
So already you have a set of steps, and sample milestones and deliverables for this part of the project could be:
Milestone | Deliverable |
Get T sensing up-and-running | Demonstrate T measurement in lab w/ ESP32 by output to serial monitor |
T sensing across range of -20 deg C to 50 deg C with +/- 2 deg C accuracy | Show plots of T measured across this range, compared to reference sensor. |
You can see that some tasks depend on prior tasks. For example, you can't test the temperature sensing until you have the sensor up-and-running, which in turn requires some hardware (ESP32 + temp sensor, maybe battery) and some code. Think about staging milestones and deliverables based on dependencies.
Also not displayed up here is how you actually run the testing plan. That aspect will be in your specifications document. But the testing plan is critical. For example:
Will you measure this indoors or outdoors? In either case, how will you generate all these temperatures? If you decide to put in a fridge or freezer, will you run the ESP32 battery-powered or not? And will you store the data on the ESP32 or send it to the cloud? If you send it to the cloud, what happens if wifi does not work inside the fridge?
Lots of details to work through!
Think also about what each team member will do each week. What prior tasks does that person depend on? Make sure that everyone has something to do. In fact, each milestone and deliverable should list who's responsible for the milestone and Deliverable.
Creating milestones and Deliverables
As part of your proposal, you will create a Milestones spreadsheet. We've provided a template here. Copy that template into your team folder and then fill it out. You sheet will include a list of milestones and associated deliverables to hit for each Wednesday lab. Well-written milestones and deliverables are easy to interpret. For example, here is a poorly written milestone and deliverable:
BAD
Milestone | Deliverable |
February 21: Research non-contact IR sensor | ? |
This is not a useful milestone because it is really a task (what you'll be doing) rather than a milestone (what you'll accomplish). One could "do some" research for various amounts of time and make various amounts of progress. In addition, no deliverable is proposed. Looking at some web pages is not a good deliverable! Here is a better-written milestone and deliverable:
GOOD
Milestone | Deliverable |
February 21: Specify a non-contact IR sensor that meets specifications. | Show part number, cost, and relevant specifications of identified part. |
Your project will need to have several milestones and deliverables each week. This is because you'll want to break down your system development into parts that each teammate can work on, and you want each teammate to have responsibilities each week.
Here are some more examples:
BAD
Milestone | Deliverable |
Test environmental resistance in shower. | Show video to staff. |
GOOD
Milestone | Deliverable |
Implement environmental test as outlined in section 2.3 of specifications document. | Demonstrate succesful passing of test, i.e., images verifying zero water infiltration and logs demonstrating continual WiFi POSTing before, during, and after the test. |
BAD
Milestone | Deliverable |
Demonstrate BLE occupancy sensing. | Show script code to staff. |
GOOD
Milestone | Deliverable |
Write code to implement occupancy sensing via BLE, test using known BLE beacons as described in section 1.7 of specifications document. | Show plots comparing ground truth and measured number of devices as number of beacons varies from 0 to 5. |
Each week's milestone and Deliverable will be graded by your mentors.
Revising milestones and Deliverables
Your initial set of milestones will be a best guess as to how the project will proceed. You'll find that your best guess is not very good. Some things will be easier than anticipated. Some will be harder, and will either take longer than anticipated or will need to be re-evaluated (for example, midway through the term you may decide to change your housing or assembly procedure).
We want to allow you to revise milestones and deliverables. After each Wed meeting, you will have until Friday evening (two days) to propose any revisions to your milestone and deliverable table. Alert staff as to any proposed changes via email. They will approve, disapprove, or revise by end of Sunday. Then the milestones stay fixed until the next Wed meeting. Editing milestones after Sunday will result in a zero for that week's milestone/deliverable grade.