CISC 6597: Capstone Project in Computer Science (Fall 2020)

Instructor: Hailong Zhang

Lecture: Thursday 7:55–10:10 PM, Zoom link

Individual meeting: Calendar link, Zoom link

Discussion: Piazza link


Week Date Topic Reading Project
1 8/27 Introduction
[slides] [capture]
CACM articles  
2 9/3 Differential privacy for mobile analytics SCAM’19 paper  
3 9/10 Static analysis of Android apps    
4 9/17 Introduction to Fuzzing
[slides] [AFL]
  Proposal due
5 9/24 Individual Meetings    
6 10/1 Individual Meetings    
7 10/8 Midterm presentation    
8 10/15 Individual Meetings   Deliverable 1 due
9 10/22 David will lead the discussion
10 10/29 Chenkun will lead the discussion
11 11/5 Haoyu will lead the discussion
  Deliverable 2 due
12 11/12 Arlind and Danah will lead the discussion
[slides 1] [slides 2]
13 11/19 Jennifer will lead the discussion
14 11/26 No class:
15 12/3 Final presentation    
16 12/10     Deliverable 3 due

General course information


The goal of this class is to provide the practical opportunity for students to combine skills they have learned during their computer science program and use them to design and implement a capstone project. Students are required to address all design, implementation, testing, and evaluation aspects of a large capstone project. They are expected to present and write one or more research papers in class detailing this work. Through this class, students should gain a deep understanding of state-of-art computer science technologies and knowledge, how they can be deployed in a practical application, and how they can be professionally documented and communicated.


There is no required textbook, but readings will be assigned and posted on course website, e.g.,conference and journal papers.

Teaching mode

Students will meet with the instructor online via Zoom each week. Sychronized meetings will be used for lectures, discussion of projects and readings, and questions and answers. Besides the assigned time blocks for the course (Thu 7:55–10:10 PM), students may contact the instructor to schedule additional regular individual meetings if necessary.

Project selection

The capstone project should address one or more research or substantive real-world problems. It could be a research project, an applied project, or some combination of the two. Each project should be done by one student, except that complex ones may involve at most two students with permission from the instructor. Students will work with the instructor to identify an appropriate project. The student should complete a project proposal that includes the following items:

There is no page limit on the proposal. The purpose of the proposal is to make sure that the project is reasonable and enables the instructor to provide useful feedback.

The proposal is due by 11:59:59 PM on the due day.

Project deliverables

Once the instructor and the student reach agreement on the proposal, the student will work on the problem defined in the proposal and document their solving process. Given the wide range of projects, there is no one-size-fits-all definition for the deliverables.

For students exploring research-driven projects, the deliverables will be technical reports and/or papers that describe the work and results.

For students focusing on applied projects, the deliverables will depend on the development models. For example, for a traditional waterfall model, the deliverables will naturally follow a sequence of requirement and design document, an alpha/beta version of the software, and the final product with testing and validation.

Below are some specific examples:

Example research project deliverables

  1. Initial solution design. Students should submit a report describing the progress. The report should include the initial design of the solution and a discussion about the related work.
  2. Preliminary implementation and results. Students should have a preliminary implementation of the solution and some initial results indicating the feasibility of the solution. Students should submit a report including a brief description of the progress, the challenges they addressed and the adjustments they made for the initial design, and the preliminary results.
  3. The final paper. Students should write at least one final paper for the project based on the proposal and the two milestone reports. The final paper should be self-contained, and ideally, ready to be submitted to a workshop or conference for publication. It is expected to be between 7 and 10 pages, excluding references and appendices. The paper should generally adhere to the following outline, but minor variations are acceptable:
    • Abstract: Summarizes the paper, typically in 1–2 paragraphs.
    • Introduction: Introduces the project and summarizes the challenges and contributions.
    • Background: Introduces necessary background information about the problem and solution.
    • Problem Statement and Motivation: Describes in details the problem and why it is important and interesting.
    • Design and Implementation: Describes in details the design and implementation of the solution to the problem.
    • Experimental Evaluation: Describes the experimental setup, including the details of experimental subjects, evaluation metrics, and any other details related to the experiments. Presents and discusses the experimental results.
    • Related Work: Discusses the related work, with citations to relevant papers/books/projects.
    • Conclusion: Provides the conclusion and possible future directions.

Example waterfall development deliverables

  1. Requirement specification and design document. The requirement specification is a written document that clearly define the goals of the final product in terms of functionality, user interface, resource usage, and other such factors. This document should include a project overview, any necessary background knowledge, and an enumeration of requirements specification for the eventual product.

    The design document is a written document that describes a detailed design for achieving the requirements. It should include a description of the major components, their interfaces and how they interact to form the whole. Figures should be included for clarity. This document should also contain a discussion of any third-party technologies or software packages that will be used in meeting the project goals. Students should demonstrate software prototypes showing that they have already evaluated and familiarized themselves with key technologies and design choices. Finally, this document must include a proposed timeline for the remainder of the project life cycle, making sure to include specific sub-goals for the development, implementation, and testing phases of the project.

  2. Alpha Version. The alpha version of the project is a preliminary implementation that includes all major functionality of the final product, yet may lack some advanced features, have a less polished interface, and contain some known bugs. This alpha version is demoed to the class in open discussion meetings for feedback.

  3. Final Product. The final product must be submitted, including complete source code, documentation for deployment and usage, database schemas, analysis, and so on, as appropriate for the project.

Example agile development deliverables

  1. Conceptualization and Instantiation.
    • A non-technical background document that describes the target clients, the general problem, and a description of the expectations.
    • A set of user stories that clearly define the different end users of the product and the various ways that those users interact with the software. You can find the template and definition of user stories.
    • User stories are accompanied by an estimate of “business value” and “difficulty points.”
    • Each user story has a set of acceptance tests that define when the user story has a complete implementation.
    • User stories have been ordered into a tentative project backlog.
  2. Rapid prototyping and iteration.
    • The student selects and implements those user stories with the highest business value and lowest difficulty, with the goal of creating a basic but functional first iteration of every major system component.
    • An automatic testing methodology (e.g. Gitlab CI/CD, or simply a test script) is established.
    • This functional first iteration is demoed to the class for feedback in open discussion meetings.
    • The project backlog and existing user stories are refined (groomed, reviewed) to remove items no longer relevant, add items in response to newly discovered needs, split items that are too large, combine items that are too small, revise estimates of value and difficulty, and reassess the relative priority of each story.
  3. Iteration and release.
    • The student selects and implements those user stories that contain advanced features or optional components, that fix bugs, or polish and streamline the user experience.
    • The project is released to the whole class (as potential end users) for testing and feedback.
    • Post-release development focuses on stability, bug fixing, and user feedback, while also adding additional features as time permits.
    • Suitable end-user documentation exists for the end users, as well as documentation for future source code maintainers.


Students should prepare two oral presentations to the class. The midterm presentation should be within 15 minutes, introducing the problem, motivation, and possible challenges and solutions based on the project proposal. The final oral presentation for the project will generally take around 20 minutes, plus 3 minutes for questions. It will be based on the final paper/product, including a description of the problem and your contributions, an introduction of your design and implementation, and/or demo. Here are some general advices on how to give a technical presentation.


The percentages given below are guidelines for both the student and instructor and may be changed as needed to reflect circumstances in the course. Any changes that occur are likely to be minor.

Project proposal 10%
Deliverable #1 20%
Deliverable #2 20%
Deliverable #3 20%
Oral presentations 20%
Participation 10%


The course content is partially based on materials made by Gary Weiss and David Ferry.