CIS 542 - Summer 2013
Group Project Final Deliverables
All deliverables are due by Friday, June 28, 12:00 noon. Late submissions will be penalized by 10% per day, and may result in a delay in posting your final grade.
Your final deliverables should consist of the following:
Submit all source code, configuration files, etc. If you use third-party libraries (which have been approved by the instructor!), only submit those in compiled form. Please be sure that all of your code is well-commented so it is easy for the grader to find where different features are implemented. Remember: happy graders give higher grades!
You must use the following tools to analyze your C code:
To get meaningful results out of the analysis tools, run your system for a reasonable amount of time (maybe about 10 minutes) with each tool and exercise the middleware either by actually using your front-end app or -- to reduce insanity levels -- by writing a small Java program to simulate "normal" usage.
Note that for many of the tools, you will only get meaningful output if the program terminates normally, so make sure there is some way to quit the program (i.e., don't just kill it with Ctrl-C).
In your analysis writeup, include all outputs of the different tools and analyze the results. In particular, answer the following questions:
You can, of course, include "before and after" results of the tools if you use their output in order to improve your system.
- Did Helgrind or Memcheck report any errors? If so, did you do anything to fix it? If you didn't fix it, how is the error mitigated/avoided?
- Does Massif reveal anything unexpected, for instance wasted (un-"useful") memory or potential memory leaks? If so, how did you fix it, or how can the problem be mitigated?
- Did Splint reveal any issues? If so, did you fix them? If not, why not?
- Does gcov reveal any unexpected execution traces, e.g. error code that you did not realize was being called, or perhaps dead code that is not used?
This document should explain how your system "works". It is suggested that you organize your report as follows:
- general system architecture: what are the major pieces and what's connected to what
- description of the functionality implemented by each component of your system (sensor, middleware/server, user interface): this should entail all of your functional requirements
- communication protocols between components (give specific info about the messages that are sent)
- algorithms and data structures used to analyze and store data (particularly in your middleware/server)
- error handling and robustness (i.e., how did you deal with the non-functional requirements?)
- techniques you used to attempt to reduce power consumption, network bandwidth, memory, and CPU utilization in your Android application
Materials from in-class presentation
Please submit any PowerPoint, PDF, etc. that you used during your in-class presentation.
Return all hardware
You must return any equipment before you can receive a grade for this project. It is okay if you return the hardware after the deadline, though.
Each functional requirement that you have identified along with your TA is equally weighted. You may not change the functional requirements without the approval of your TA. Once you have done your final in-class demo, the TA will determine the extent to which each functional requirement has been met; if the TA is not satisfied, then you have the option of continuing to improve your project up until the submission date (June 28).
If there is a disagreement between you and the TAs as to whether a requirement has been satisfied, please notify the instructor.
Non-functional requirements and reliability/robustness (20%)
Your system is also graded based on the extent to which it satisfies its non-functional requirements, as agreed upon with the TA and instructor. Additionally, during your demo you will be asked to demonstrate the robustness of the system, in particular that it gracefully handles situations in which one or more components are unavailable or unreachable.
You are expected to perform the analysis described above, using all identified tools (Helgrind, Memcheck, massif, splint, and gcov). If you are somehow not using threads, you do not have to use Helgrind, of course.
If you have trouble using the tools, please contact a member of the instruction staff.
You should submit a single PDF that sufficiently addresses all of the topics described above (both the technical documentation and user documentation should be in the same PDF).
In-class Presentation (5%)
Described here. Don't worry about making it amazing. Just don't be terrible.
Please create a single PDF containing the names of your group members, the documentation (technical doc and user guide), and the analysis. Then combine the Eclipse project containing all Android source code, configuration, data, etc. into a single tar and/or zip file. Also put all your server-side C code into a separate tar/zip file, and lastly include all your Arduino code into a third file. Submit the PDF and all three zip/tar files via Blackboard; only one member of your group needs to submit this.
Updated: Wed 19 June 2013, 1:33pm