CS71 Project Overview

* In which, you can build something you've always wanted to implement!

Due May 10th, before midnight

Schedule:

• Project group formation and general project idea due (by email): April 5
• Lightning Talks 1: April 8, in lab
• Written proposals due: April 12
• Lightning Talks 2: April 15, in lab
• Sprint 1 due: April 21
• Lightning Talks 3: April 22, in lab
• Sprint 2 due: April 28
• Lightning Talks 4: May 2nd, in class (MODIFIED)
• Sprint 3 due: May 5
• Final report and application due: May 10th (No exceptions)

Projects

The goal of the project is to build a non-trivial application together with a group.

Groups should have 3-4 people. The scope of the application should be large enough for each person to be responsible for a significant piece of functionality. By significant, I mean approximately the same level of effort as an assignment.

You have complete freedom in what you choose to build: you may make a game, web application, desktop application, or phone application. Your application may provide functionality related to NLP, AI, graphics, processing and aggregating data, etc. A successful project must have a purpose. It may be a niche or abstract purpose, but it must be something that can be used.

Constraints: You must write your project using an language which supports object-oriented programming principles. A major goal of the course is to design your project with well-defined modules. Your final submission needs to build (ideally, this should be automated) and run on the Swarthmore lab machines.

Project ideas

Games and novelties

• PC roleplaying game engine in the style of 90s-era console games
• side-scrolling platformer (similar to Mario Brothers) with realistic physics
• an Android augmented reality zombie shooter
• surreptitious bingo game meant to be played during boring meetings
• Poetry or story generation website
• beatbox and midi music mixer

Social Networking

• video authoring platform similar to the now-defunct Vine but with a collaborative twist
• location-based commenting application
• textbook-sharing website
• movie rating and recommendation site with user-driven categorization
• website aggregation engines

Academic Software

• drag-and-drop DNA sequence editing website for use by a biomedical engineering laboratory
• teaching tool for automata in computational theory
• an image manipulation pipeline editor for a brain imaging laboratory
  
• an book analysis tool which shows plot developments over time

Work flow and team organization

We will use an Agile software development approach called Scrum.

From wikipedia:

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited.

Scrum aims to be a flexible and adaptive work flow. In Scrum, teams identify sets of features to complete within a short, time-boxed iteration. These iterations are called Sprints. Short iterations allow the team to re-evaluate their goals and assumptions, and to change plans if necessary.

For this project, sprints will last one week. Each sprint, the team identifies a set of goals to tackle. At the end the sprint, the team reviews what went well or poorly during the last sprint and sets a new set of goals to tackle in the next sprint.

A Scrum framework typically consists of three roles: a product owner, developers, and scrum master.

Your professor will the product owner. This role will represent the voice of potential users as well as future developers who may need to maintain and debug your projects. The product owner will be responsible for evaluating your progress as well as giving advice to help your project succeed.

The development team will be responsible for designing and building the product. The scrum master will be responsible for keeping track of progress during each sprint. For this project, team members will take turns being the scrum master.

You should create a wiki for your project. On the wiki, you will post your

• design document
• weekly progress and development backlog
• lightning talk presentations
• final design document
• post mortem: what went well, what didn't

Design document

In Week 1 and 2, you should write a design document with your team. This document should contain:

• Short description of project
• Features in the form of user stories. You should divide your features into "minimum viable product", "good to have", and "reach goals".
• UI sketches: if applicable, drawings of any interfaces you plan to build
• High-level design: list the key modules of your application as well as any databases, build tools, or frameworks your application will need. Include inheritance, containership, and interaction diagrams for the major modules you plan to build.
• Specifications: sketch the key public interfaces your main classes will have.
• Testing plan: how you plan to verify and test that your code is working
• Sprint plans: estimate the features to be completed each week for each person on your team. It will be important to make progress each week. So aim to under-promise and over-deliver. For example, week 1 should be focused on getting your development environment setup and a skeleton of your program. Week 2 should start tackling "minimum viable product" goals. Features are 'complete' only when they are both implemented and tested.

Each team should share a repository on github. Your project progress and documentation should all go on github as well.

Sprint deliverables

Each week, the scrum master should document your progress and set the list of goals for the next sprint on github. Check in your code. Ideally, I should be able to build and run all sprint deliverables. Feel free to use branches to save unfinished features which should not be part of a sprint.

Github has several features that will help you manage your progress for each sprint:

• Issues: You can keep track of enhancements and bugs here
• Projects: You can share an overview of "to do", "in progress" and "finished" features
• Wiki: You can consolodate your documentation and work plans here

Lightning talks

Each week, your team will give a 5-10 minute talk about your project. In week 1, you will summarize your project goals and plan. In subsequent weeks, you should demo any progress and talk about one interesting thing you solved or learned that week.

Ideally, every person on your team should be a primary speaker for at least one lightning talk.

Final deliverable

Your final deliverable should include:

• The record of your weekly progress (on the wiki -- this should mirror your project board)
• Your final report (on the wiki). Your final report should describe the completed features of your project along with instructions and/or videos to demonstrate them. Include at least one video to demo your project.
• Post-mortem (on the wiki). Your post-mortem should include two lists: one containing aspects of the project you felt went well and one containing aspects which you would do differently in the future.
• Source code and tests along with instructions of how to build and run them (instructions in README.md on your github page). Note that if your project requires dependencies that are not on the lab machine, you should include instructions on how and where to install them. For full credit, I must be able to build and run your project by following you rinstructions.
• Credits: Include references and links to all tutorials, assets, ad code resources you used for this project.
• Performance evaluation of your teammates. You should list the work you contributed to as well as the work your teammates contributed to. You may use this form or email this information to me.

Because we are working in teams, don't forget to be professional.

As part of your project submission, you will be asked to fill out a performance evaluation of your teammates. Note that it is possible for group members to receive different grades, depending on their contribution to the project.

Grade heuristics

• Weekly progress: was progress made each week? or rushed at the end? was the project managed well?
• Final deliverable: does it work? is it a significant development effort? can I build it?
• Documentation: does the project meet documentation requirements (e.g. all documents present)? is the design modular? does it define good interfaces? does it allow group members to work in parallel?
• Testing: did the team design and implement good tests? Did the team think about how to build their application incrementally?