University Homepage School Homepage School Contacts School Search

SEOC2: Assignment 3

NOTE: Only undergraduate students need to turn in this assignment; MSc students submit a literature review instead. Even so, MSc students may want to do something like the CVS and make tutorials, and should be aware of the types of tasks described here.

This project is a continuation of the team-based task from Assignment 2, based on the Parent Magic email, keeping the same teams of about six people. The goals of this assignment are to focus on longer-term project planning: anticipating and addressing potential risks, making a measurement plan, and making a testing plan. Just as for the first assignment, your mark will be based on how well you have considered and anticipated the important issues, how feasible your plans seem to be, and how well you present your work and express yourselves. You will not be judged on how closely you match some pre-determined correct answers.

As before, the team leader will be responsible for submitting the final assignment, and for notifying me (as a last resort) if a team member has been entirely unavailable or has done no work or preparation. Also as before, how you divide the work is entirely up to each team, although you should discuss all of the issues together at least once.

The assignment

Assume that one month has gone by since your email to the customer in Assignment 2, and by some miracle your team has actually delivered a package with the features you promised the customer in Assignment 2, developed with the architecture pattern you chose. Congratulations!

Your customer has given you feedback that several of the features were right on the mark, and have been useful, but that a few will need revising. For instance, to those teams who promised pop-up messages, the customer has indicated that the messages were too irritating. Instead, it is now clear that messages should be delivered only when the user clicks on a "messages available" indicator in the Parent Magic software. Various other minor changes were suggested.

Based on this initial version and the feedback, upper management has decided to go ahead with this project, developing a much more ambitious and polished version to ship to the general public in one year. However, the team has also just been assigned to maintain several unrelated existing projects written by other teams, which require less work but do need attention each month in sporadic bursts of a few days or weeks. Your team members are otherwise planning to be working full time on this project for the coming year.

1. Write, in the form of an email message of about 600 words to your technologically adept manager, a very brief listing of what you propose the first public release of the software in one year will do. You should acknowledge that the set of features is likely to change as development proceeds, because it is difficult to estimate the feasibility of some of the larger items. Summarize the most significant risks to the success of this project, including how you plan to address the risk, and how to decide if your "cure" is in fact an overdose. Examples of such risks are listed in Cockburn's Risk Catalog, but you should also mention others.
   
   
2. Develop a measurement plan for your project --- What issues do you plan to track over time? How will you measure those? Who will be using the data? What will they be using it for? Discuss these issues in a .txt file of about 600 words, emphasizing why your choices are the most appropriate ones for this project.
   
   
3. If your team has five or more members, develop a verification and validation plan for your project --- What are your V & V goals? What types of tests will you focus on? What strategies will you use for each type? Discuss these issues in a .txt file of about 600 words, emphasizing why your choices are the most appropriate ones for this project.
   
   
4. As in Assignment 2, once the assignment is nearly complete, the team will need to come to a consensus estimate of how much effort each person put in. The estimated effort, expressed as a fraction of the total, should be submitted as an additional .txt file. By default this would simply be 1/6 for each member of a 6-person team, but if there is agreement that some have done substantially more or less, you may report different fractions. The team grade will be multiplied by each fraction to get the individual grades. Since this is an exercise in working as a team, it is expected that you will be able to handle the credit allocation yourselves. However, in extreme and unusual cases where the team is unable to decide on an allocation, the team leader can email me the particulars of the dispute, and ask that I make the final allocation.

To facilitate working together on these answers, your team leader should set up a shared CVS repository for your team, to be used by each member of the team to contribute to the final product. A list of basic CVS commands is provided, along with an example of starting a new repository and a new project using a set of existing files (which could be empty at first). Each team member should add his or her own .txt files and edits to the team's shared repository using CVS commands.

Each file should declare its CVS version number by starting with a line containing "$ID$" (where ID will be filled in with the file's name and version by CVS). Apart from letting you see the revision number for the file, this data allows me to verify that CVS was used properly.

Each member of the team should also read through the gmake tutorial. Of course, gmake is not likely to be useful for this project because I am asking for plain .txt files only, and nothing is to be compiled.

Submission

Your work must be submitted by 10am Tuesday, 15 March, using the submit command on Informatics DICE machines (type man submit for more details). Your work should be in the form of plain ASCII text files named 1.txt, 2.txt, 3.txt, and 4.txt. Late submissions will not be accepted without good reason, and will be penalized according to the standard university policy of 5% penalty per working day or part of a day.

Example of submit command:

submit cs4 seoc2-4 cw3 1.txt 2.txt 3.txt 4.txt