Project Proposal
Overview
The first step is for each group to create a development plan for their semester-long project. This plan is not meant to be a hard contract, but rather a way for each group to start thinking about what problems they expect that they will need to solve and what components they will need to build prior to starting development. This plan must cover how the group will implement their project. This includes what existing libraries or systems the project will use as a reference implementation.
Each group must also desiginate a liason that is responsible with coordinating with the other group working on the same project topic. Both groups are required to support the same public API. Thus, the two liasons must collaborate together to define this API and then provide a joint API specification.
- Release Date: Jan 15, 2024
- Due Date: Jan 31, 2024
Deliverables
The following items are due at the start of beginning of class.
API Specification
Each group must provide a design document that describes their project implementation. This document should contain the following information:
-
Overview: What commands will the API expose.
-
Encoding: What encoding scheme will the API use for inputs / outputs
-
Error Handling: What errors can the service encounter and how will API handle them (e.g., status codes).
Students are free to ignore security and authentication concerns in their projects to limit the scope of their implementations. We also strongly encourage groups to reuse APIs from existing systems when appropriate. Please confer with the instructor if you have questions about feasibility of adopting existing protocols.
Design Document
Each group must provide a design document that describes their project implementation. This document should contain the following information:
-
Overview: A description of the problem that you are trying to solve with your project. That is, what are the high-level goals of the code that you are adding to the DBMS.
-
Architectural Design: An in-depth overview of how you implemented your project. Explain the input and output of the component, describe interactions and breakdown the smaller components if any. You should also describe what (if any) configuration knobs your component will need.
-
Design Rationale: An explanation on why you chose the given design. Your justification should discuss issues related to (1) correctness, (2) performance, (3) engineering complexity / maintainability, and (4) testing. It should also include a brief discussion of the other implementations that you considered and why they were deemed inferior.
-
Testing Plan: A detailed description of how you are going to determine that your implementation is both (1) correct and (2) performant. You should describe the short unit tests and long running regression tests. Some portion of your testing plan must also use your project's public API, thus you are allowed to share testing infrastructure with the other group implementing the same thing.
-
Trade-offs and Potential Problems: Describe any conscious trade-off you made in your implementation that could be problematic in the future, or any problems discovered during the design process that remain unaddressed (technical debts).
-
Glossary (Optional): List any new concepts or unintuitive/non-standard names that you have added to your system.
These design documents must be written Markdown using this template. This part of the project is meant to encourage each group to think through their implementation before they start making changes. They will also serve as guides for future students in helping them understand what you did after you have left CMU and are potentially dead.
Presentation
Each group will give a five minute presentation about their proposed project topic to the class. This proposal should contain the following information:
- An overview of what work must be done and how it will be divided amongst the group.
- The tests that you will write to validate that your project is correct and the experiments that you will use to measure its performance.
- The resources you will need to complete the project. This includes software, hardware, data sets, or workloads.
Your proposal should also provide three types of goals: 75% goals, 100% goals, and 125% goals. Think of these as the equivalent of a B grade, an A grade, and a "wow!" grade. The goals can be dependent or independent of the prior goals. Each group can meet individually with the instructor afterwards for additional discussion and clarification of the project idea.
Each group must email the instructor a PDF version of their proposal presentation before class.
Collaboration Policy
- Everyone has to work in a team of three people for this assignment.
- Groups are allowed to and strongly encouraged discuss the details about the project with others.