Project Milestone 2: Prototype
Due: Wednesday, March 9, 10:00 pm
through CMS.
Presentation: Friday, March 11.
All the remaining milestones for the project involve the same essential work. You will engage in a sprint, which is a fixed length of time during which you build a "shippable" increment of your system. Your sprints will last about three weeks each. At the end of each sprint, you will ship the latest increment of your system to the course staff and demo it for us. You have four sprint cycles—named prototype, alpha, beta, and final—to implement your project.
Read the project sprint overview to find out more.
Advice on when to implement what. Based on our knowledge of the class schedules for CS 5430 and CS 5431, we suggest the following guidelines for the earliest you could plan to implement particular security functionality:
| Milestone | Delivered security functionality |
|---|---|
| Prototype | Authorization, Audit |
| Alpha | Confidentiality and integrity of storage and network |
| Beta | Authentication |
Don't try to implement the details of password-based authentication, for example, before your beta release, because that material won't be covered until later in the semester.
Note that not all groups and projects are the same. In the prototype milestone, you might need to spend more time just getting some basic features working and less time on authorization. Ultimately, you are empowered to decide what features you will deliver as part of each sprint. But make sure that you finish the security functionality by the end of the semester!
Personnel
You should now identify two new roles, an Architecture Lead and a QA Lead. These people shouldn't overlap with your Project Manager or Requirements Lead.
The Architecture Lead is responsible for the overall architecture and integration of your system. That doesn't mean that the Architecture Lead should be doing all of the architecting and integrating alone; your entire group should contribute. But it's helpful to have one person as a designated expert on how the whole implementation fits together.
The Quality Assurance (QA) Lead is responsible for the quality of your system and source code. The QA Lead ensures that the system is free of bugs, and that the source code adheres to good style, is well-documented, and is readable. That doesn't mean that the QA Lead writes all the test cases, or all the documentation; rather, each group member should be testing and documenting their own code. The QA Lead identifies problems and gets the original authors of code to solve those problems.
Source Control
We strongly recommend that you keep your project in a source control system. Cornell provides forge.cornell.edu, which offers version control (through SVN), trackers, task managers, document storage, discussion forums, and wikis.
Submission
Submit a PDF containing your updated Requirements Document. It should contain your personnel, system purpose, threat analysis, security goals, and essential security elements, all of which should continue to be updated throughout the project. You do not need to include the rest of the analysis from your Milestone 1 Requirements Document, in particular the asset, stakeholder, harm, or feasibility analyses—their purpose was to get you to security goals, which you now have.
The Functional Requirements section of your Requirements Document should now be renamed to the "System Backlog" section. You will continue to update it throughout the project. When you complete items, mark them completed and move them to a "Completed" part of the backlog. This section of your document is especially important, because we will use it to evaluate your progress. Make sure you are entering security requirements in your backlog as you proceed through development.
Also submit a zip file containing the source of your system. Include a plain text file named "README" in root of your source detailing how to compile and execute your system on our own machines.
Presentation
Your group will present your prototype to the course staff on Friday, March 11. All members of your group should plan to be present. Details on times and locations will be announced later.
Your presentation will proceed in three phases. In the first phase, you will present your progress in this milestone. Give an uninterrupted talk of about 5 to 10 minutes using Powerpoint slides. (All the criteria for talks from Milestone 1 apply here.) Your talk should give us an overview of the system backlog items you delivered in this milestone. You must describe in detail any security functionality you implemented.
In the second phase, you will demo your system. Plan to do this on a laptop that you bring with you. You should demo only completed (= working and tested) functionality. We will be especially unimpressed by any bugs we see during your demo, if those bugs relate to functionality that you claim to have completed. We will expect to play with the system ourselves during your demo.
In the third phase, we will hold a question and answer session. We ask; you answer. Anything about your system is fair game. We may direct questions to any member of your group.
Finally, you should submit your sprint report (through CMS) on the same day as your presentation.