Project

The project is an open-ended software development experience. Think of it as an activity that takes place instead of a final exam and that requires corresponding intensity. There will be four milestones in the project: Charter, Alpha, Beta, and Release. In the Charter phase you will form a team and propose the system you plan to build. In the remaining phases you will build out and evaluate some part of of your system, write a brief report on your progress toward your final goal, and submit your code for evaluation.

Deadlines

• Charter: October 9
• Alpha: November 13
• Beta: December 4
• Final: December 16

Requirements

The primary educational objective of this project is for you to gain experience with programming langauge ideas, either in a theoretical or application context. Potential projects include:

• Implementing an interpreter or a simple compiler
• Implementing a type checker or static analysis
• Implementing a verification tool
• Doing pencil-and-paper proofs of langauge metatheory
• Implementing a language or doing proofs in Coq (if you are familiar with interactive prover)
• Reproducing results from a published paper

Size: If you are doing an implementation-oriented project and working in OCaml, you should aim for several hundred to a few thousands lines of code. If you are doing a theoretical project, expect to submit a 5-10 page technical report containing any formalization and proofs.

Source control: You are required to use Git to manage your source code. You are welcome to make your work on this project public.

Teams

You are welcome to do the project solo or with a partner. However, if you have a partner, both members of the team must contribute to the project.

Grading

The project is worth 25% of the final grade, and will be broken down as follows:

• Charter: 2%
• Alpha: 5%
• Beta: 5%
• Final: 10%
• Peer evaluation: 3%

Why is the Final phase worth so much more than the Alpha and Beta phases? It’s not because you should do five times the work all at the end: it’s because we don’t want any initial stumbles to have too great of an impact. We encourage you to work at a consistent pace throughout the project.

Charter

Your task in this milestone is to form a team and decide what you want to build. There is only one deliverable: the project proposal. You may also include an optional team expectations agreement.

Team Formation

• If you plan to work with a partner, indicate your partnership on CMS.

• Use Campuswire if you are seeking a team.

Proposal

Submit a short (1-2 page) document containing the following information:

• [1 point] The members of your team, including their names and NetIDs.

• [1 point] Logistics plan, a brief description of how you plan to manage details like version control and communication with your team (if you have a partner).

• [3 points] A proposal for your system. Summarize the system you intend to build. Tell us what will be the most important functionality of your system. This summary should be about one page long. Provide:

  • A very short statement of the core vision or key idea for your system.

  • A short (no more than six items) bulleted list of the key features of the system.

  • A narrative description of the system you intend to build, prove, formalize, etc. Go into enough detail that, if your charter were given to another team, and that team were never allowed to talk to you, they would still understand more or less the functionality that you have in mind.

• [3 points, 1 for each milestone]A roadmap for your project. There are going to be three “sprints” (implementation phases) after this charter: alpha, beta, and final. Make a list of what features you plan to implement in each sprint.

• [3 points] A preliminary design sketch for your project. Spend some time thinking through what you are going to need to build, formalize, prove, etc. Of course, your plans will evolve throughout the project. But it’s good to have talked as a team up front about what seems necessary. In about one page, answer the following questions

  • What are the important systems that need to be formalized or modules that will be implemented? What is the purpose of each?

  • What data will your system maintain? What formats will be used for storage or communication? What data structures do you expect to use as part of your implementation?

  • What third-party libraries (if any) will you use?

  • How will you test your system throughout development? What kinds of unit tests will you write? How will you, as a team, commit to following your testing plan and holding each other accountable for writing correct code?

Team Expectations

Teamwork isn’t always easy. But when teams work and communicate well, the benefits more than compensate for the difficulties. One way to improve the chances that a team will work well is to agree beforehand on expectations. If you are working with a partner, we recommend creating a Team Expectations Agreement. On a single sheet of paper, put your names and list the rules and expectations you agree as a team to adopt. We suggest that you start with this:

• We all show equal commitment to our objective.
• We all take part in deciding how work should be allocated.
• We are committed to helping each other learn.
• We acknowledge good contributions from team members.
• We handle disagreements and conflicts constructively within the team.
• We are able to give constructive criticism to one another and to accept it ourselves.
• We all turn up to meetings and stay to the end.
• We are good at making sure that everyone knows what’s going on.
• When one of us is under pressure, others offer to help them.
• We trust each other.
• We remain united even when we disagree.
• We support each other to outsiders.
• We feel comfortable and relaxed with one another.

Feel free to modify as you wish. Make your expectations fairly thorough without being unrealistic. For example, “We will each solve every part of the assignment completely before we get together” or “We will get 100% on every assignment” are probably unrealistic. You might want to reference the section below on “Teamwork and Roles” as part of your expectations. There is no need to upload this agreement to CMS, although you’re free to include it in your charter if you like.

Alpha

Your task in this milestone is to complete a first coding sprint. That is, you should build some functionality, test it, submit your source code and a progress report, as well as a brief blog post, as described below.

Coding Sprint

For this Alpha phase, your technical goals can be extremely modest. However, you should aim to get some functionality running. In most cases, this will typically consist of an initial implementation of some piece of the overall system that has been prototyped, plus some tests for validation. If you are pursuing a language implementation, you could “subset” the system by building just one piece (e.g., ASTs, type checker, interpreter), or by considering only some of the constructs in the language (e.g., basic expressions but no top-level declarations yet). In any case, the key thing is to have something that runs.

You should submit your code as a Zip file named prototype.zip on CMS, and include instructions for how to build and run your code in a README file.

Progress Report

You’ll put together a self-evaluation of your progress at the end of the Alpha phase by writing a brief progress report. Your report should be approximately one or maybe two pages long. It should contain the following information:

• Vision: In one paragraph, what is your current vision for the system you are building? How has it evolved from previous sprints?

• Summary of progress: Write a one or two paragraph description of what your team accomplished during the previous sprint. What functionality did you work on? What did you show off in your demo?

• Activity breakdown: If you are working with a partner, give a bulleted list of the responsibilities that team member had and the activities in which they participated during the sprint.

• Productivity analysis: How productive were you? Did you accomplish what you planned? Were your estimates of what you could do accurate, or far off? Write a paragraph addressing those questions.

• Grade: Give your team a scope grade for this phase: Satisfactory, Good, or Excellent. Your grade should be based on your experience of those levels of scope in the assignments thus far in this course. Write a paragraph or two providing a detailed justification of why you gave yourself that grade. Please be honest: we want you to reflect candidly on your progress. Your grade for the Alpha phase is not going to be based on what you self-assign here.

• Goals for next phase: Set three goals for the Beta phase, corresponding to what you believe would constitute Satisfactory, Good, and Excellent scope for that sprint. (You may omit this section in your final report.)

You should submit your progress report as a PDF named report.pdf on CMS.

Blog Post

We’re also asking you to put together a brief blog post for the whole class to read. This post can be as short as a few hundred words. It should be written for a general audience familiar with CS 4110-style material. You may include accompanying graphics if helpful. Your blog post should cover:

• Vision: What are you trying to achieve? It’s fine to re-use text from your project report if helpful, but remember you are writing for a general audience, not the course staff!

• Status: What’s the status of your current prototype? Showing some test cases or a screenshot might be helpful.

• Next steps: What do you plan to do next?

You should format your blog post in Jekyll-flavored Markdown and submit a Zip file named blog.zip on CMS that contains a file alpha.md with your blog post, along with any other supporting files (e.g., images).

Rubric

The Alpha phase will be graded as follows:

• Prototype [5 points] submitted code compiles and can be run, as described in the README
• Report [3 points] project report includes each of the item mentioned above
• Blog Post [2 points] blog post is as described above

Beta

Your task in this milestone is to complete a second coding sprint. That is, you should build some additional functionality, test it, submit your source code and a progress report, as well as a blog post, as described below.

Coding Sprint

For this Beta phase, your technical goals can still be modest, but you should have some significant functionality running. Typically you would have enough done to be able to demonstrate the main features of your project.

You should submit your code as a Zip file named prototype.zip on CMS, and include instructions for how to build and run your code in a README file.

Progress Report

You’ll put together a self-evaluation of your progress at the end of the Beta phase by writing another brief progress report. Your report should be approximately one or maybe two pages long. It should contain the same information as for the Alpha phase. You should submit your progress report as a PDF named report.pdf on CMS.

Blog Post

We’re also asking you to put together another blog post for the whole class to read. Now that your project is more mature, the post should aim to be more thorough than for the Alpha phase. Again, it should be written for a general audience familiar with CS 4110-style material. You may include accompanying graphics if helpful. Your blog post should cover:

• Vision: What are you trying to achieve? It’s fine to re-use text from your project report if helpful, but remember you are writing for a general audience, not the course staff!

• Status: What’s the status of your current prototype? Showing some test cases or a screenshot might be helpful.

• Next steps: What do you plan to do next?

You should format your blog post in Jekyll-flavored Markdown and submit a Zip file named blog.zip on CMS that contains a file beta.md with your blog post, along with any other supporting files (e.g., images).

Rubric

The Beta phase will be graded as follows:

• Prototype [5 points] submitted code compiles and can be run, as described in the README
• Report [2 points] project report includes each of the items mentioned above
• Blog Post [3 points] blog post, as described above

Note that the blog post is worth slightly more in this phase, and the report is worth slightly less.

Peer Feedback

Your task here to provide feedback to two of your peers on their projects, based on their Beta blog posts. You’ll receive a CSV file on CMS with two NetIDs, as well as an alternate.

If one of the two NetIDs is a close friend or your project partner, please use the alternative. If more than one of the NetIDS is a close friend or your project partner, contact the instructor for a different assignment.

To find the blog posts, navigate to

https://www.cs.cornell.edu/courses/cs4110/2020fa/blog/<netid>

where you replace <netid> with a specific NetID. You’ll need to authenticate with your NetID.

Your feedback should be structured as a simple ASCII text file with the following sections.

• NetID The NetID of the project you’re providing feedback for.

• Summary Summarize (in your own words) what the project is about, trying to capture the key innovation.

• Strengths Discuss the aspects of the project you find most compelling.

• Suggestions Discuss any suggestions you have for improving the project.

It’s totally fine to be brief – e.g., giving 2-3 sentences for each section is fine, and you can provide a bulleted list rather than complete paragraphs. The main goal here is to convey helpful feedback.

Please keep the tone of your feedback positive and constructive, especially when it comes to suggestions. Keep in mind that the blog posts describe works-in-progress. Not all projects will be far along as others at this phase. Your goal here is to provide helpful assistance, not critical evaluation.

Please email your feedback to <netid>@cornell.edu, again replacing <netid> with a specific NetID. Note that in the case of group projects, just one NetID is listed in the CSV. The expectation is that this person will forward the feedback along to their partner.

Finally, upload your two feedback files to CMS for grading. Everyone who submits feedback as described above will receive full credit.

Final

Your task in this final milestone is to finish your project. You’ll complete any required coding, documentation, and testing, and write a brief report. Your sumbission must provide a README file that describes how to build and run your code.

Report

You’ll put together a self-evaluation of your progress at the end of the Beta phase by writing another brief progress report. Your report should be approximately one or maybe two pages long. It should contain the same information as for the Alpha and Beta phases. Instead of “Goals for next phase” please identify some possible next steps for this project, were you to continue it. You should submit your progress report as a PDF named report.pdf on CMS.

Demo

Design a demo for your system and put together clear instructions for how to run it. The demo does not need to be sophisticated (but it should be more than just running unit tests). It’s fine to have both positive and negative examples (e.g., here’s a program that does not pass the type checker). However, the demo should illustrate the main features of your system. Make sure that all required inputs are provided, including any interactive input from the user.

Rubric

The Final phase will be graded as follows:

• Implementation [10 points] submitted code compiles and can be run, as described in the README
• Report [5 points] project report includes each of the items mentioned above
• Demo [5 points] demo is well thought out and illustrates some interesting functionality
• Scale [5 points] project is of sufficient size or complexity (approximately 3-4 assignments)

Acknowledgment: The structure of this document is adapted from the CS 3110 project. The list of sample team expectations above is from the University of Waterloo Centre for Teaching Excellence, citing Levin and Kent (2001).