Revise and expand on your earlier proposal(s) (or start anew)
Devise a plan and schedule for completing your project
Review
Projects are intended to be a proof-of-concept. They should demonstrate that a concept is feasible, but they don’t necessarily have to be an accurate depiction of all aspects of the project. For example, an IoT based system to control home appliances could use a small DC motor or hobby servo or LEDs rather than actually controlling a real appliance.
Projects should use multiple elements of an IoT stack
There should be one or more embedded devices
There should be sensors and feedback
There should be some graphical user interface for some features
There should be some networking
Moreover, there should be a valid reason for networking (i.e., some substantial benefit of networking. Some thing that could be done that wouldn’t be possible without the network)
Groups
You can work in groups of two on the project. Work will need to be evenly shared. The proposal revision and plan (this phase) should be a project that each person is interested in pursuing.
Repositories
Before configuring a repository, decide if you will be working in a group or not. If you will be working in a group, decide who will create the GitHub group and who will join it.
Follow the same basic process used in studios and previous assignments to create/join a group, download the resulting repository (with GitHub Desktop), and import it using the Particle Desktop IDE.
Any services that provide webhooks (including Slack, GitHub, and probably many other services that you use regularly)
Other Embedded Platforms (non-Photon), including but not limited to:
Raspberry Pis
ESP 8266 based platforms (available from AdaFruit, SparkFun, Amazon, and others)
Hardware not used in class
Use of other transports not covered in class (Bluetooth, LoRa, Zigbee, Cellular, etc.).
Interesting designs (wearables, mechanical designs that exceed requirements, etc.)
Particular merit
You may want to carefully consider these to include them in your proposal. The actual bonus credit awarded will depend on:
The depth/breadth of the content you learned (that wasn’t part of class)
The merit of your addition (was it a valuable part of the project or an unnecessary afterthought?)
The quality of the additional work
Proposal Requirements
The proposal text and documents should be included in the docs/proposal directory of the repo. They docs/proposal/proposal.md should contain the full proposal.
proposal.md already has section headings. The descriptions below describe the expected content of each section.
1. Description
A written description of your project (approximately 1-2 written pages). Think of this as an elevator pitch — you have very little space and time to give a compelling overview of your project.
The description can be an expansion of your earlier proposals but, unlike the first proposals, this should be written narrative (not questions and corresponding answers). It should:
Describe the expected users/audience.
Describe the “problem” that your product will assist with.
Describe your solution.
Argue the merit and/or value of the project:
Why is use of IoT beneficial?
Is it worth the costs (financial, maintenance, installation, development)?
This can either be based on your earlier proposals or completely new (if there’s a compelling reason to select a different project)
2. Hardware and Cloud Infrastructure Needed
Give brief lists of the resources you’ll need. Provide both a list of hardware for the embedded system and any needed cloud services/infrastructure.
If you need hardware you don’t already have, either provide a link to a specific device(s) you plan to get/use or provide information about your requirements and Instructors/TAs may try to help find an appropriate solution.
Provide descriptions or links for any items/services that aren’t common knowledge.
3. Unknowns and Challenges
Provide a brief summary of any things that you don’t currently know or challenges you anticipate.
4. User Stories & Usage Scenarios
Provide a brief user story and corresponding usage scenario for all major features of your project. (These can be informal, but they should be easy to read)
5. Implementation: UI Paper Prototypes
Provide paper prototypes of the main screens of your UI.
These should be sufficient to cover major Usage Scenarios that require a user interface.
You are encouraged to use actual paper prototypes and just take pictures of them.
Please ensure the pictures are clear and any distractions are cropped out.
Include the pictures in the project/proposal/diagrams subdirectory.
Link to the images in the markdown (using the format described in GitHub’s Mastering Markdown
)
The images should be embedded in the markdown so they show up in-line when viewing the .md file on-line. I.e., they should show the actual image in the .md GitHub’s on-line preview rather than a link to the image. Check this after pushing your repo!
Each image should have a brief description or caption beneath it. It should provide sufficient detail to understand the diagram without referring to other parts of the proposal.
6. Implementation: Sequence Diagrams
Include sequence diagrams corresponding to all major interactions between elements of your system. Try to be as detailed and thorough as possible (at this stage). As with paper prototypes:
Images should be in the project/proposal/diagrams directory
These can be screenshots from WebSequenceDiagrams, but you’re welcome to use other tools.
The final project will require updates. You may want to save the “source” to any diagrams so you can quickly re-create them.
Again, link to the images in the markdown (using the format described in GitHub’s Mastering Markdown
)
The images should be embedded in the markdown so they show up in-line when viewing the .md file on-line. I.e., they should show the actual image in the .md GitHub’s on-line preview rather than a link to the image. Check this after pushing your repo!
Each image should have a brief description or caption beneath it. It should provide sufficient detail to understand the diagram without referring to other parts of the proposal.
7. Plan and Schedule
The complete project will be due Dec. 3rd by 11:59pm (the 4th is last day of CSE222). You will need to deliver:
Working, demo-able project
Completed, commented source code
User documentation (things a novice needs to know to use the work)
Developer documentation (updates to the components of this plan, like sequence diagrams and user stories, and details another student would need to know and understand if they were tasked with updating the work)
Based on this, propose a plan and schedule for your work:
Include a week-by-week breakdown of what work you will accomplish.
Include slack time and “fallbacks” if you fall behind
If you need additional hardware, include your best estimate of when you need to order it and when it will be delivered.
If you need to learn new skills or systems, budget time for learning/exploring.
Assume that there will be weekly reports. You should have at least one milestone for most weeks.
If working with a partner, clearly specify who will be responsible for what aspects of the project.
Include times that are reserved for you to work on the project. I.e., blocks of time over the coming weeks that you intend to use for project work. (This is especially important for teams that may need to identify times that both people are available)
8. (Optional) Bonus Credit
If you plan to pursue bonus credit, describe what advanced elements you’re including. (Add a heading to the proposal.md for “Bonus Credit” followed by the description)
Submission & Checkout
You must commit work to GitHub by 11:59pm (CDT) Monday, Nov. 11th.