Team Project - Project Plan and Teams
CS 420 - Spring 2006 - Ms. Katz

Goals
- to get acquainted with your group
- to develop a project plan
- to get started on the team project

Overview
You're going to be working on a team project throughout this term. Team organization, collaboration, and communication will be major factors in your success. Your first task as a team is to decide on a project plan and especially a schedule.

You will use iterative enhancement to develop the project in at least three full iterations through the project life cycle. The first iteration will be somewhat informal as we will not have covered particular software development techniques. However, the later iterations will involve appropriate formalisms.

Project Plan Document
The project plan you turn in on January 30th should contain firm dates you plan to deliver specifications, high-level-design, low-level design, and the remainder of the deliverables for the first iteration. It should also contain proposed dates for some of those items for the second and third iterations. Because you are learning how to do such planning, you'll have an opportunity later in the term to revise this project plan document for those iterations.

In chapter 11 of the text (p. 453), there is a list of the items that should be included in the project plan. We will study some of these, such as the cost estimates, later. For now, include as many portions as you can. Use the creation of this document as a tool for guiding your discussion within your team of what you're developing and how.

purpose

describe the problem to be solved

background information

describe brief history of the project, references to related projects, any existing documents

processes to be used

list overall development model, tools and techniques to be used

subsystems and planned releases

show division of project into parts such as roughly what each iteration will include

risks and challenges

describe any constraints (such as learning to use the language and development environment)

tasks

list tasks that will be completed for each iteration

cost estimates

give current cost estimates (not in initial plan)

team

list who is on team, skills team members have, skills team members need, who will do what

schedule and milestones

give deadlines for completion of tasks (using Gantt or PERT charts later)

This document, as all documents for this course, should be an editable document available to all team members. Turn in a printed copy and retain a printed copy for your team records.

Other Project Documents
Remember that the documents should be helping you communicate with each other as well as with me. For each iteration, you will deliver at least the following documents.

specification

This defines what your software will do. For the early iterations, this should indicate which portion of the system you will develop for this iteration.

high-level design

This graphical depiction of the system architecture shows which components will be developed and how they interact. In the first iteration, this should show the objects to be developed. Later iteration will have more detail and be in UML notation.

low-level design

This view of the design is more detailed and a combination of text and pictures. In the first iteration, for each class, give a short class description, list the member functions including the parameters, and list the instance variables. A diagram should show how the classes are related and especially any inheritance and dependencies. In later iterations, this will be more detailed and formal.

source code

The source code itself should be well-documented. This should not be printed as long as I can see it electronically. Each function should have a header describing its purpose, its inputs, its outputs, its primary author(s), and its modification history. The deliverable document is a short description of how to access your code and execute it. Be sure to backup your code to a different computer frequently.

test plan

This document describes what tests and testing techniques you used and what the results were. Try to break your program.

team project evaluation

This describes your group experiences, what you plan to change in the next iteration, and what you learned as a team.

individual evaluation

This describes how you contributed to this iteration and any comments that will help me evaluate your project or help your team in the next iteration.

Teams
I've divided you into teams of three or four members. Each member is expected to contribute substantially to the team effort. See me as soon as problems arise.

Each team member should be the team leader throughout one iteration. The team leader is responsible for setting meeting times, settling disputes, asking for clarification of requirements, and enforcing deadlines agreed upon by the team. Otherwise, the team should be a democracy (egoless teams) with each person's opinion considered. Let me know at the beginning of each iteration who will be the leader of your team. That person will be my contact for any team business. However, any of you can talk with me about your project.

You should meet frequently as a group. I will set aside some classtime for this activity, but it won't be frequently enough to complete all your discussions and collaborative work. This project will take time. I've tried to keep the problem complexity manageable, but you will need to work outside class as a whole team, in pairs, and individually.

Although this is a team project, I will consider individual efforts (including facilitating team interactions, presentations, cooperation, irresponsibility, and violation of team agreements) in assigning grades. Doing the project yourself rather than as part of the team will lower your grade. Note that each iteration has an individual contribution portion. Normally, everyone in the team will receive the same grade on a delivered portion of the project.

Remember that you are team members sharing a project. Treat it as a job. Be professional. Don't let your ego get caught up in the programming. Criticisms of your code are criticisms of the code, not you. Be open to new ways of viewing the problem. Respect other people's egos, opinions, and feelings. You have to work with each other.

Be responsible. Attend team meetings and be ready to work on the project. Pull your fair share and let others pull theirs. This project should take priority over elective activities; it is classwork. See me early if you have problems with team members not sharing the work.