CS5430 Project: Phase V Deliverable (Spring 2013)

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 April 29. Use the "Project Phase V Demo Slots" assignment on CMS to schedule your demo.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting encompasses 30 minutes, and it 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 clarity of your presentation counts.

  Slides should contain short telegraphic phrases, figures, algorithms (in an easily understood pseudocode), and (where appropriate) performance numbers. Use the Powerpoint "speakers notes" feature to amplify what appears on a slide, so the course staff can review this when later deciding on a grade for your effort. 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" are 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 your project, (iii) describe the detailed design of your system, (iv) explain why your design is a good one (but include short-comings and trade-offs), and (v) explain why we should believe that your system is secure (i.e., what testing you did and any other support for an assurance argument). Hint: Structure your talk as 5 sections that parallel the 5 topics.

• 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 all manner of code vulnerabilities. But be candid about what works and doesn't work---the grade penalty is more significant if we discover problems that you didn't warn us about.

• A question/answer session [10 minutes]. We ask; you answer. Anything about your system---functionality, design choices, source code, 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.

What to Submit (and When). Prior to April 28 at 11:59pm you should submit to CMS:

TEAM.txt which contains the names (and net-ids) for all team members. Also, for each team member give a 1 or 2 paragraph description of the tasks this team member performed and the number of hours this required.

README.txt which contains the names and a description of the contents for the other files in the directory.

Source files that contain the source needed to compile and run your software. This should include any scaffolding used in the Demo you will give. We will look over excerpts of your code to see whether your project is based on clean design and was implemented using good software engineering practices (including secure coding practices). Projects containing code vulnerabilities will be severely penalized.

FUNCTIONALITY.txt, which should discuss the interface that your system implements. What operations does it export? What is the effect of each operation?

ASSURANCE.txt, which describes how and what you tested in the software being submitted. Also describe here any other means you used to increase assurance in correctness of the system and the absence of vulnerabilities.

PRESENTATION.pptx, which is a power-point file that you will use to make your presentation at the review.

Grading. The group's grade for this phase will be based on the following.

• 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%]
• does your implementation satisfy the functionality specified at Phase I [15%]
• testing and other means of establishing assurance [15%]