This page explains the items listed on the Team Home Page Template.
Indicated in italics is the team member responsible for this item.

Project Planning

Project Plan  (Mgr)

This is an updated version of the project plan we created in CSc 205. Review last quarter's project plan and update it for this quarter's activities. Last quarter's template.

McConnell has a  template on his web site for a "Software Development Plan" which is his term for our "project plan."  Read over his template and select the sections which seem relevant to our project this quarter.  If specific sections are mentioned elsewhere on the team home page, they do NOT need to be duplicated here.  For example, there is already a link to "change control plan" on the home page, so you don't need to put that in the project plan.  Read Ch 4 about Project Planning.

Detailed Schedule (Mgr)

The schedule is a chronological table showing due dates for all the milestones for the entire project.  Table 5-1 has a good set of milestones from which you can select the ones relevant to your project. Then add in the details for the activities for the current stage. That is, schedule all the team meetings for this stage and specify what tasks should be completed on each of those dates.  Read Ch 12 for a discussion of the tasks which occur in each stage.

Lines of code (Estimated) (Mgr & Design)

A table showing the names of all the modules in your application and estimated lines of code for each. At the bottom, show the computations for an "effort estimate" of how many LOC your team can be expected to produce.  For example:  (Number of programmers) * (productivity rate) * 10 hrs/ week * 8 weeks.  Ideally, productivity rate is determined from your historical data on Stage 1.  If that is not available, use a number between 25 and 50 LOC/hr.

Staged Delivery Plan (Analyst)

A description of all features that will be included in each release. Each feature needs to be precisely described. Ideally, it will refer to a requirement number from the specification document. However, if you didn't number your requirements, then you have to explain them with narrative.

If a feature is going to be partially implemented, you need to describe the character of the functionality you plan to implement. One of the most common sources of confusion on student projects is uncertainty about whether a certain feature is supposed to be working yet. It is the job of this document, along with the Integration Plan, to eliminate that confusion.

Staged Delivery is discussed throughout the text and a simplistic example is shown on page 165.  An example Staged Delivery Plan from a student project is available.

Change Control Plan (CM)

Read McConnell Chapter 6 and Pressman Chapter 9. You need to list all the work products you intend to place under change control (see list in table 6-1). Then for each work product, specify the procedures which will control changes to the document.  Some basic strategies are outlined in Change Control Considerations.  You can follow these recommended templates.

Quality Assurance Plan (QA)

Update the QA plan from 205 to describe the QA activities during this course.  Read McConnell Chapter 9 and Pressman Chapter 8.  This document should be a comprehensive explanation of how all the QA activities will be carried out.  For each  QA activity, describe: Some of the subsections of the QA plan are entire documents on their own.  Just include links to more detailed plans, for example: Software Inspection Plan, Software Test Plan, Configuration Management Plan, Risk Management plan.

Training Plan (training coordinator)

Place all your developer training plans and information here.  Recommend following the Training Plan Template.

Integration Plan (Integration)

A table which shows the order modules will be implemented and integrated into the build.  You can follow this recommended template.

Test Plans (Test)

A software project test plan describes the objectives, scope, approach, activities, and procedures your team will use for software verification. It explains who is responsible for each kind of testing, how it is to be carried out, how it will be documented and tracked, and what criteria are used to assess that it has been done properly.
This is a comprehensive and important document!  There are many resources to help you write a test plan.  Read the textbook and reserve room references and consult the course Resources page for starters.

Release 2 Recalibration (Mgr)

Recalibration of project estimates which occurs at the end of Release 2. (See pg 239).

Software Project History Document (Mgr)

Read Ch 18 in McConnell about Project History Document.  If you have been keeping your team web site current throughout the project then your web site itself is your project history document.

Project Tracking

Project Visibility(Mgr)

Follow the directions on this page of visibility calculations.

Current Action Items (Mgr)

A list of outstanding Action Items assigned, preferably in table format.  Include: Should also include (or link to) a historical record of previously completed items. Update after every team meeting.

Current Defect List (QA)

A link to the team's defect tracking system. See pg 129-130.  Dr. Dalbey recommends Teamatic, but you may use an alternative if you have a preference. Note that defects during unit development are NOT tracked by the team, only integration and test defects.

Software Inspection Report (QA)

A summary report of results from the software inspections.

Daily Build Report (Integration)

Refer to Ch 14. You may want to create a list of chronological links to a separate page for each build report.
A build report contains Here is an example from a previous student project.

Daily Smoke Test Report (Test)

Refer to Ch 14. You may want to create a list of chronological links to a separate page for each smoke test report.
A smoke test report contains Here is an example from a previous student project.

Top 10 Risks List and Risk Management Plan (Risk)

Described in detail in McConnell Pg 93 - 101.  Read also Pressman Chapter 6. See McConnell's checklists for Risk Management.

Submitted Change Requests (CM)

A list of formal Change Requests that have been proposed and their status. See Change Control Plan for an example.

Team Meeting Notes (Mgr)

Minutes from team meetings, both in lab and out of class. (Action Items are posted separately). Optionally, the meeting notes may be kept in a project journal.

Project Manager's Progress Reports (Mgr)

A weekly summary of project status.  See Ch 14 pg 209.

Software Project Log (Mgr)

Described in McConnell pg 243-244.

Requirements Traceability (Design)

See McConnell page 151. Each requirement in the specification is traced to which module(s) in design implements it.  Table format works fine for this.

Test Matrix (Test)

A matrix showing which test cases are used to verify each requirement.  McConnell Ch 9 page 134 describes a test matrix, but he uses the term Requirements Traceability.  Please note that Dr. Dalbey defines Requirements Traceability as in the previous item.

Unit Tests and Unit Test Results

Each developer writes JUnit test cases for their assigned classes (or modules).  The unit tests must demonstrate that every method in the class works correctly.  When completed, you will post your unit tests and results on your web page.  See the recommended directions for unit test results.

System Test Cases and Scripts (Test)

Follow the directions for producing system test cases provided by the instructor.

Download Page

Create a download page for people to obtain the current release and build of your executable system.  Example download page. Be sure to provide any necessary installation directions.

Implementation

Place a link to a zip file containing the source for your most recent release (not build).

System Test Results (Test)

Documentation of the results of running the system tests.

Release Criteria (Dalbey)

Discussed in Chapter 16.  Here are the instructor's release criteria. (negotiable).

Release Checklist (Integration)

Discussed in Chapter 16.  See McConnell's template.

Release Approval (QA)

Discussed in Chapter 16.  See McConnell's template.
 

Our Software Process Definitions (TBD)

Coding Standard (Dalbey)

The source code you develop must adhere to an established coding standard.  Dr. Dalbey's coding standard is the "default" standard.  You may alter or customize this standard with approval from Dr. Dalbey.  Note that your deliverable will be penalized for violations of the coding standard (See Instructor Release Checklist).

Source Code Control Procedures (CM)

Provide a complete user guide to using your source code control system. Here is an example cvs quick reference guide.

Unit Development Procedure (Integration and QA)

Describe every step that a developer undertakes in producing a single module (unit).  Table 14-1 pg 203 is an example, but will need to be modified for our project. (Note that McConnell calls this an "integration" procedure, but we will call it a Unit Development Procedure).

Software Inspection Procedure (QA)

The QA manager must create a software inspection process for your team.  Read these guidelines to Software Inspections for Software Engineering Student Teams.

Unit Testing Procedure (Test)

Describe all the unit testing that a developer is required to carry out on individual modules during unit development.  Include requirements for documenting and submitting unit tests to the test team.

Build Procedure (Integration)

Page 205-206 has an example that will need to be modified for our project.  Also include specific technical instructions for how to run the build on your development platform.  Include the schedule for when the build will be run.
Here is an example build procedure from a previous student project.

Defect Tracking Procedure (QA)

Describe how your team will track and report defects found during integration (not unit development). See pg 129-130.  You are required to use an automated defect tracking tool (Teamatic recommended, but see also Resources). Provide a link to documentation of how to use your tool.  (If it isn't in your QA plan, here would be the place to describe how defects get assigned for repair and how open defects are tracked and resolved).

Individual Status Reporting Procedure (QA & Mgr)

There are many project metrics whose collection starts at an individual level: hours of effort, LOC developed, PSP data, etc. Describe all metrics and status information to be gathered, due dates, forms, procedures, etc.  This could include weekly status reports of action items assigned, completed, problems, etc.

LOC Counting Procedure (QA)

Describe the procedure a unit developer uses to count Lines of Code.  If you have a metrics tools, include directions how to use it.  Dr. Dalbey recommends the tool he provided on the Resources page.  If you are using a manual counting procedure, provide all the details/rules for its use.

Time Recording Procedure (Mgr)

Refer to Ch 7.  Describe how individuals record and report their time spent on the project.  Provide any forms, due dates, procedures, etc.

Email and Web Standards and Procedures (QA)

Describe any standards or procedures for using email or posting to your web site.  For example, Dr. Dalbey has some email requirements in the syllabus. You may want to enhance these with your own internal standards for Subject lines, etc.  You could include alternate communication strategies and expectations your team has for communicating.

PSP Submission Procedure (Dalbey & QA)

The course Resources page has a section for PSP Scripts and Forms. As you are doing unit development you must follow the PSP script.  This script has been painstakingly prepared for you.  Read the directions completely, carefully, and be sure you understand every word.  There is also a FAQ.  If there is anything in these directions about which you have the slightest question, ask for clarification!  You are expected to complete the PSP forms accurately and precisely. For CSc 206 Wtr 2002 you do NOT need to complete the Project Summary Form.

The PSP forms for a unit you develop are to be submitted to the QA manager during the first class session after the unit has been submitted to the build.  The QA manager gathers all the PSP forms and may publicize which have been completed (but do not publicize individual data).  The QA manager submits all the PSP forms to the instructor with the Release.

About Our Team (TBD)

Contact Information (Mgr)

Provide a link to a page (or include at bottom of page) which lists how to contact your team members, for example:
 
Student Position Phone e-mail
Kevin Design & Integration 786-4329 kblomset@calpoly.edu
Josh Testing 756-8986 jnthomps@calpoly.edu
Antony Configuration Managment 784-9045 ageorge03@hotmail.com
Kamil  Quality Assurance & Web 489-7560 kbaranow@calpoly.edu
Sean Manager 542-0455 smpinto@calpoly.edu
       
Entire Team     luckystrikesoftware@hotmail.com

Project Vision (Mgr)

To expand the existing single player game, "Sokoban" into a cooperative multiplayer experience while at the same time improving upon existing single player game play.

Team Expectations (Mgr)

Describe or list the norms or standards that everyone agrees will meet their individual needs while also leading to a successful project.  For example, "The maximum time spent on this class each week is 15 hours,"  "No work meeting continues past 2a.m."

Team Photo


 
 

Anonymous Feedback (Mgr)

Provide an HTML form to allow anyone to post anonymous feedback about the project. You can modify McConnell's  anonymous feedback Template.  Or you can find a "bulletin board" from many places on the web.
Alternatively, the instructor has provided an anonymous feedback from on the course home page, and you can have your team added to this form my simply informing the instructor of the e-mail address for your team.

Course Home Page