CS340 Final Project

For the remainder of the semester^[1], we'll be working on open-ended final projects!

Projects should be substantially more complex than the weekly assignment you've completed up to this point–to give you a general idea, think:

• Around 3X the complexity and workload of Modeling 5 or PBT.
• Around 4X the complexity and workload of a lighter assignment.

Final project proposal

The topic of your final project is intentionally open-ended. The topic can be anything substantial that touches on modeling computer systems, as long as it has sufficient scope.

Examples:

1. Modeling systems algorithms and verifying correctness (up to some scope) in Alloy. This likely will also include showing incorrect versions fail to verify.
2. Implementing a property-based-testing system for existing software or a new systems implementation.
3. Using an SMT solver to verify systems-related topics, potentially related to Alexa's research (talk to me if you are interested in this option)!

Final project presentations

We will have final project presentations on Tuesday, May 9 from 9-11:30am in Sci L037.

Each presentation should be 15-20 minutes. We have 7 presentations total, so 20 minutes is a hard cutoff; you should practice your presentation to make sure the timing is correct. Each group member should speak for a roughly proportional amount of time.

Most presentations will be slides as well as a demo component; you are also welcome to use the chalkboard.

Components your presentation should likely include (does not necessarily need to be in this order):

1. Motivation and description of the specific problem you have chosen to model. Include diagrams and pseudocode as appropriate. This might take up to half of your presentation time.
2. Which tool did you use to model your chosen systems problem? Why?
3. Describe your model, showing either a live demonstration or screenshots of a demonstration.
4. Describe what tradeoffs you made in choosing your representation. What else did you try that didn’t work as well?
5. What assumptions did you make about scope? What are the limits of your model?

Project partners

Final projects will be completed in groups of 2-3, or solo with prior instructor permission^[2]. I will help with assigning groups, including potentially adding a 3rd person to already formed groups of 2.

Everyone in the group should have some creative control over the project direction. You can either opt to pair-program together, divide responsibilities up within the project, or some combination of the two. See the section below on using GitHub for collaboration.

We want this class to be a supportive community. You are expected to abide by standards of professional behavior when working with your group members. Every group member must:

1. Remain in regular communication with your group and me.
2. Contribute meaningfully to the proposal and the project itself.
3. Allow all other group members to contribute meaningfully (e.g., not rewriting others’ work or taking charge of a piece of the project without discussing first).
4. Conduct themselves professionally (e.g., arriving reasonably on time for meetings, provide thoughtful feedback on others' work, etc).

Project goals

Your project proposal will include a description of your project (what the problem you will model and what technique(s) you will use) and a foundation, target, and reach goal. My evaluation of your project will be partially based on your own stated criteria, although you may pivot throughout development (this is a feature, not a bug, of open-ended projects!).

1. Foundation. This should describe the basic functionality you plan on completing, the component(s) and property(s) you are confident that you will be able to accomplish in the project time frame. (You will want to discover potential problems with this goal ASAP, and seek advice from if this scope is not working). Completing just this goal roughly maps to an 80%.
2. Target. This should describe the project you plan on handing in (that is, the scope you think you will mostly likely be able to cover). It should include some interesting component(s) and property(s) that you are fairly sure you will be able to complete. Completing this roughly maps to a 90%.
3. Reach. This should be something extra that you may attempt after your target goal is reached. It can be something that you aren't sure is possible! A 100% or above requires at least attempting to address your reach goal, or at least describing why the reach goal was not achievable in the project time frame.

GitHub

I strongly encourage you to make your project public, but in any case you must add my account (avanhatt) as a collaborator.

GitHub best practices, in general:

1. You should commit frequently, both to save your work and to document design decisions as you go. Commits should have informative descriptions.
2. Your README should document how to install and run your project. I suggest you write your README in GitHub-flavored Markdown. More on the README below.

Some policies specific to CS340:

README

You should maintain an up-to-date README for your project. Write such that a hypothetical CS major could follow the installation steps and basic ideas, even if they have not taken CS340. Here are some examples of points you might cover:

The final README should also include:

Your final writeup (due May 8) can share much of the text from this README; but I encourage you to develop the README incrementally as you go. The final writeup may include additional private components:

Reflection

Please complete this reflection, individually (completely separately from your project partner(s)), by 4:00pm on Thursday, May 9.

GitHub issue tracking

I encourage you to organize your project into small, actionable steps, and to track these as GitHub issues on the project. You can use Project Tracking to help organize issues.

Attribution

Some final project structure borrowed from Tim Nelson's Logic for Systems at Brown University.