0.1 Title Page, including (1) the name that your team has given to the project and (2) all the names of the team members and their roles.
0.2 Table of Contents, set up as hyperlinks to bookmarks of each of the items below.
1.1 Problem statement. Provide one paragraph describing the problem you are solving with your product (the whole iTrust project).
1.2 Benefits. Provide one paragraph on the benefits of your proposed system (the whole iTrust project) to your customer. Why would your customer want your system?
2.1 Project Responsibilities: List who on the team is assuming which role. Since we would like each of these people to assume the roles we've outlined in the topic of "Working in Teams", you simply have to state who is assuming which role (team leader, development leader, planning leader, quality assurance leader)
2.2 Team Contract: Define and list the rules for team interaction and participation that all team members agree to for the duration of the team project. The guidelines below are inspired by http://math.arizona.edu/~kerimar/Team%20Contract.doc.
Team Procedures
Team meeting times
Communication mediums and frequency
Decision-making - who decides and do roles play a part?
Agendas for meetings
Record keeping
Work Quality
Project Standards - what are the standards of quality for the team for code, tests, documentation, bug reports, and other deliverables
Strategies - how will you ensure quality? Pair programming, inspection, peer-review, or something else?
Team Participation
Cooperation and equal distribution of tasks
Inclusiveness
Keeping on task
Leadership and roles
Accountability
What level of attendance and participation is expected for a team member?
What level of responsibility is expected for a team member?
What level of communication is expected for a team member?
What level of commitment is expected for a team member?
What actions should a team member take if they are unable to fulfill their committments for a given week (or longer)?
Consequences for non-Participation
How will the team handle initial incidents of non-participation?
How will the team handle multiple incidents of non-participation?
What type of point infractions should extended non-participation incur? (The teaching staff will use this section of the document as a basis for grade modifications if they become necessary.)
Make the point infractions as specific as possible. The teaching staff expect a least a half iteration/deliverable penalty (5-10 points) for non-participation. This is your chance to make it larger.
Agreement - Each team member should sign the following (and we want a real signature, a photo of a signed document would work nicely. This can be attached to the electronic SPMP).
I participated in defining the team contract as stated above.
I agree that I am obligated to fulfill the terms of the contract.
I understand that if I do not fulfill the stated terms that the consequences for non-participation will be applied.
2.3 Configuration Management Plan:
What artifacts will be under "configuration management" meaning that you will track versions? All your code should be included but you may want to have other documents as well.
What process must the group members follow to request that changes be made to the software?
How files will be maintained such that two individuals are not making changes to the same files without being aware of the other’s changes?
Who may access files and make changes?
High-level iteration plan. Make a plan which provides (1) an estimate of story points for each use case; (2) your expected team velocity; and (3) schedules each of the use cases fairly evenly into one of the three iterations (Iterations 1, 2 plus the final product). Justify any big variations in workload by iteration (such as team members having exams, etc.)
You high-level iteration plan should include a burn down chart that provides details about your estimates. This is a living chart, and should be updated for each RAF. The chart includes the data associated with your estimates, and then a graphical representation of those estimates. An Excel template is provided, though you are free to use any form of burndown chart you choose.
4.1-4.x Patterns. Each member (the name of the team member must appear near the pattern discussion) must submit a two-paragraph discussion of one pattern that might be able to be used in your project. Each team member must choose a different pattern. The document should also clearly indicate the pattern that was chosen by the team for the project implementation -- every team must use at least one pattern in their final product. Information on many patterns can be found all over the Internet searching on "Design Patterns.