CS513 Project

CS513 students are expected to participate in a group project that has non-trivial security content. There is some flexibility in what you do and how you do it. This note outlines what is expected.


Deliverables for Each Phase

The project is divided into 3 phases. This division into phases provides well defined points for us to give you feedback (and facilitate mid-course adjustments in your group's effort). Here are details of what is expected for each phase.

All submissions should be made through CMS. CMS provides a way for you to define your group. Be advised that each group member must take an action in creating a group, and your group cannot submit anything through CMS until the group has been created.

Grading. The project accounts for 50% of the CS513 final course grade, allocated as follows among the three phases: Phase I (10%), Phase II (15%), Phase III (25%).

Phase I: Problem and Group Definition [Due 9/12 (10:10am)]
Submit a typeset document (.doc or .txt are best, so that we can easily add comments in-line) of at most 4 sides long (11 point type, 8.5 x 11 inch pages) that includes the following information. We will assess the proposed effort, and if we believe it to have suitable scope and difficulty, then we will give a go-ahead for the next phase. If we deem the proposed system unusable as a CS513 course project then we will try to suggest modifications that would make it usable; you may then be required to resubmit a revised document.

Phase II: Functional Specification and Design Discussion [Due 10/3 (10:10am)]
Submit two files, as follows.

Phase III: Implement, Test, and Document [Due 11/19 (10:10am)]
Sign-up. Decide where (CSUG or MEng Lab) you want to conduct your final presentation and when. Then, schedule a Presentation/Demo meeting slot for the week of Nov 26. Use the sign-up sheet posted on the door of Upson 4115 to schedule your meeting.
The sign-up sheet will be available, starting Wednesday, Nov 14, 11:30am.
Your group must sign-up before Monday, Nov 19, 9:00am.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting encompasses an hour, and will be structured as follows.

  • An uninterrupted presentation that one or more members of your group give using Powerpoint slides [10 minutes]. Plan to display the slides using the same computer screen that you use later to demo your system. Rehearse the presentation well---the time limit will be strictly enforced, and the quality of your presentation counts.

    Slides should contain short telegraphic phrases, figures, algorithms (in an easily understood pseudocode), and performance numbers. Use the Powerpoint "speakers notes" feature to amplify what appears on a slide. The "speakers notes" should be prose (i.e., sentences and paragraphs) that is complete enough so that anyone can read them and understand the crux of the slide they accompany. What is said when presenting a slide and what is written in the "speakers notes" is unlikely to be the same---spoken language is less efficient and therefore requires repetition that written notes don't.

    Your presentation should: (i) remind us what your system does, (ii) discuss the "security content" of this effort, (iii) describe what (if any) design or implementation innovations were required to complete the project, (iv) explain why your design is a good one, and (v) explain why we should believe that your system is secure.

  • A demo of your system [8 minutes]. Make sure you have an easy way to transition from the Powerpoint presentation to your demo. The demo itself should show that your system works and should convey a sense of what functionality your system implements. A fancy GUI will not impress us; a robust system will impress us since lack of robustness implies the presence of code vulnerabilities.

  • A question/answer session [10 minutes]. We ask; you answer. Anything about your system---functionality, design choices, related work---is fair game. Plan to convince us that you are truly the experts on subject matter concerning your system. Questions may be directed to any member of the group.

  • Evaluation of the source code with a TA [30 minutes]. Be prepared to help a TA take a "guided tour" of portions of your code that interest him. Code that you have written should be clearly identified so that it is quickly located and cannot be confused with other code that is used in your system. We will look over excerpts of your code to see whether your project is based on a clean design and was implemented using good software engineering practices (including secure coding practices). Projects containing code vulnerabilities will be severely penalized.

What to Submit. You need not submit anything until the start of your Presentation/Demo meeting. At that time, you should provide us with:

  • Two printed (either black and white or color is fine) copies of your power point presentation, where each page contains a slide image and associated speakers notes. (This is called "notes pages" on the Powerpoint Print menu.)
  • A CD containing
    • the ppt file used for your Presentation/Demo meeting,
    • all the code and other files for your system and demo, and
    • a README file that explains how to install your system and how to run the demo.

Grading for Phase III. Your grade for Phase III will be computed as follows:

  • presentation content (slides and "speakers notes"), delivery, and adhering to time limit [15%]
  • demo---does the demo and underlying system work [10%] and does it illustrate the security functionality [15%]
  • performance during the question/answer session [10%]
  • code and design review [20%]
  • how difficult an undertaking was this project [15%]
  • other subject factors about project goals, implementation, and presentation [15%]

Some Project Idea Suggestions

Here are some suggestions for projects. Don't feel compelled to choose one of these. In fact, we encourage you to devise your own project idea---reading this list might provide inspiration that leads to a project idea that excites you. However, avoid projects that (i) involve card games or other forms of gambling or (ii) involve implementing e-cash or other forms of electronic currency.