COS 597E: Civic Technologies

Fall 2009

 General information
Schedule
Course Wiki

COS 597E: Civic Technologies

Princeton University
Fall 2009 semester

Project Plan

Due Monday, Oct. 19, in class

Your project plan is a more detailed (than your proposal) description of what your project is and how to plan to deliver it. Your plan is tentative, in the sense that you might make some adjustments later, but bear in mind that adjustments will be aggravating and time-consuming for you, so it's worth your while to think hard now about what you are going to do.

Your plan should be realistic about what you can accomplish given the available time and resources. Success requires that you ship your product on time!

Your plan should have the following sections:

Project Overview and Justification

Provide a brief description of what the project is and how it will provide civic value.

Existing Technologies

Talk about any existing systems that provide similar or related functionality. What will your system add that wasn't available before?

Functional Specification

Describe what your system will do, from a user's point of view. Don't talk about the innards of your system -- that's what the architectural spec is for. Talk only about things that typical users will notice.

A good way to structure the functional spec is to work through a set of user scenarios, involving hypothetical users who want to accomplish something with the system. For example, if you were writing a functional spec for YouTube, you might use three scenarios: (1) Alice has made a video on her laptop and wants to publish it to the world; (2) Bob has heard about Alice's video and wants to watch it; (3) Charlie likes Alice's video and wants to embed it in his web page.

You don't have to give every last detail of how the scenarios will play out. Anything that would be obvious to a reasonable person can be left out. For example, you can say "Alice sets up an account on the system. This works like on most websites."

Diagrams are often helpful in the functional spec.

Another useful trick in writing a functional spec is to list non-goals. These are things that you have explicitly decided not to do. For example, if you are designing a rice cooker, you might specify "non-goal: cook anything other than rice". Non-goals are important because they keep the project focused on what is essential, and they solidify agreement within your team about what you are doing.

Architectural Specification

Describe what you are going to build, what parts you're going to use, and how the parts will fit together. This is where you talk about which existing software packages and libraries you are going to use, what programs you will write, which programming language you intend to use (if it matters), and so on.

If your system will use interesting algorithms or data structures, talk about them here. Put in anything that a reasonably skilled engineer would need to know if you wanted them to build the system your way.

Diagrams are often helpful in the architectural spec.

Management Plan

Talk about who will be responsible for which parts of the system, and how you will make sure that the parts fit together.

Talk about any tools you will use for software development, testing, and version control. If you need advice on these, consult with other students who have experience developing larger class projects or commercial software.

Talk about any non-technology aspects of the system, such as documentation, help pages, FAQs, or privacy policy. What is your plan for producing these?

Schedule

Establish a series of milestones: dates by which certain things will be done. Each milestone should list a specific date and a specific, testable accomplishment that you want to have done by that date. You might say that a specific part of your system, or a specific function, will be working, or that a reduced-function version of your product will be functioning on a particular date.

It's best to spread your milestones through the semester, rather than putting them all near the end, so think creatively about how to define testable milestones with early dates. In general, it's good to get a simplified system working early, then add advanced functions -- this protects you against the disaster scenario where the parts don't fit together at the end, leaving you unable to deliver any working product.

Resource Requirements

Discuss the computational resources you'll need. Do you need your own web server? Your own database server? What level of computating, storage, and bandwidth resources will you need? (This might depend on how many users you attract, so you might want to create two or three scenarios reflecting different numbers of users, and estimate resources for each scenario.)

If you need to buy services from a hosting provider, Google AppEngine, Amazon EC2/S3 or the like, give cost estimates. Prof. Felten can help you find funding, if your costs are reasonable.