Project Phase I — CSC207H: Summer 2009
                 June 2009     
            Su Mo Tu We Th Fr Sa
                1  2  3  4  5  6
             7  8  9 10 11 12 13
            14 15 16 17 18 19 20
            21 22 23 24 25 26 27
            28 29 30            
            
        

Due Friday, June 19nd, 2009 at 10:00am sharp.

Visit your project wiki and acquaint yourself with drproject. After your team has chosen a name, please have one person from your team send me an e-mail (see main course page for my contact information) with the subject "CSC207: Project Team Name". The contents of the message should contain the name your team has chosen. After this is done, I will create your team's drproject page which will then be listed as one of your projects (top right part of the drproject screen).

Phase I of the project is worth 5%, Phase II will be worth 5%, and Phase III will be worth 10%.

Overview

Phase I of the project has you review a client request for a software program in order to start to clarify their needs. As part of this, you will produce a list of user stories, a small set of further questions for the client, and an accompanying email message. You will also work with a wiki and a team repository, and set up an Eclipse project containing a working program that includes at least some of the goals of the project.

Learning Goals

By the end of this phase, you should have:

  1. practiced soliciting specifications from a non-technical client,
  2. used tools to support collaborative software development such as a wiki and a shared version control repository,
  3. learned and practiced expressing technical content in a professional written context such as email to a client, supervisor, or co-worker,
  4. experienced some of the joys (and frustrations) of working with others and consequently developed some strategies to facilitate productive team interaction.

Team member evaluations

You will be filling out and submitting a form for each of your team members, including yourself. This form will rate team members on citizenship: did they attend meetings, did they participate, did they do what they said they were going to do, and so on. We will post a final version before the deadline. Your Phase I will receive a grade, and these evaluations will be used to make individual adjustments to that grade. These are meant to be private: each team member will hand these in separately, and you are not required to show each other your forms. In the case of serious disagreement, or if you request it, we will hold a team meeting to discuss the results, but we will never reveal individual ratings.

The Client Request

A company has contacted you about building a program for them. Here is the description.

We'd like you to write a program for a cell phone that lets users play text adventure games that are in the style of Colossal Cave Adventure, Zork, and The Hitchhiker's Guide to the Galaxy.

Text adventure games are made up of a series of areas — rooms, trees, caves, castles, and so on — that are populated with puzzles and creatures, items such as swords and torches, medical kits and light sabers, and more. Colossal Cave was the first such adventure game.

Players type commands like "get lamp" and "go west" to pick things up and move around. The game will keep track of where the player is and what they have and so on. Sometimes players will want to save.

We'd like to be able to run different adventures, and even let people who download the program to be able to write their own adventures and share them.

Please feel free to send us any questions you have.

Part 1: Communicating with the client

The first step is to clarify what the client is asking for.

Clarifications: user stories and further questions

This description is vague in places and incomplete in others. You'll need to clarify it: with your team, spend some time writing no more than 15 user stories in order to help you figure out what the client is asking for. Some user stories you'll be certain about, but many will need feedback from the client. Don't worry about distinguishing the ones you're sure about from the ones you're not; the client would want to read all of them anyway, in case there are misunderstandings. Create the user stories on your team's wiki.

Also make a list of the five most important questions you need to ask before you can start implementing the program. Create the list of questions on your team's wiki. Grammar, clarity, and spelling are important.

Email message to the client

Create a plain-text file in your team's repository called email.txt. This should contain the body of an email message that you are preparing to send to the client. (Assume that you'd send the user stories and questions as attachments for the email.) The message should thank the client for their request and ask the client to review the user stories (which would be included as an attachment). It should then ask two of the questions from the list you have prepared on your wiki. Pick the two you consider to be the most important in order for you to get started. Create the email in a plain-text file in your team's repository, and assume that you'll ask the other three questions in a later email.

Suggestions on writing

Read the U of T E-mail Etiquette page.

You should use correct English, writing complete sentences with correct spelling and grammar. Remember that you are writing in a professional context, but try not to sound stuffy. Be careful not to use technical language that the client will not understand (assume they don't know anything about programming) and don't include details that are not important from the client's perspective. Use a spell checker and have each member of your team edit all the documents. Everyone should proofread the final submission.

Some technical requirements

Because one of the project goals is to have each student experience using a wiki and a version control tool in a collaborative context, this phase has an extra requirement. Every member of your team must commit a change to the email document (use meaningful log messages!), and every member must contribute to or edit either the user stories list or the questions list. The svn log command is useful to see if you have met this requirement.

Part 2: Starting a project

In your team repository, create a project and make sure everyone in the team can check it out, compile it, and run it.

Your program must accomplish something related to the client request: there is plenty there to start with that isn't vague or incomplete, and you'll be getting feedback in lecture and on the discussion board. It doesn't have to do much, but it has to do something relevant.