Software Project Management Plan (SPMP)

Preface

This document describes the plan for executing a student team project in CPE 309 Software Engineering at Cal Poly. The procedures described here are to be followed completely and precisely. Teams may suggest changes or improvements by following the Change Control Procedure for submitting Process Improvement Proposals.

1.0 Introduction

1.1 Project Overview

This project is the continuation of a project begun in CPE 308. During CPE 308 we completed the specification, prototyping, and design of a moderately large software system. During CPE 309 we will implement, test, and perform two releases of the system and then perform subsequent maintenance on the released product.

1.2 Project Deliverables

The deliverables for this quarter are two major releases of the software product and one maintenance release. The releases are graded according to this scoresheet. The major work products to be created (aside from the deliverables) are shown on the team project home page.

2.0 Project Organization

2.1 Process Model

The process model to be followed by student teams is the Staged Delivery Model explained in Software Project Survival Guide by Steve McConnell.

Since Analysis and Design were completed during the previous quarter, this quarter's process need only address implementation, testing, release, and maintenance. Some teams may need to do detailed design before implementation.

In brief, the process goes like this:

Steps 1 - 9 must be performed in sequence. Each step must be complete before proceeding.

  1. Perform review and repair of requirements and design from 308 (SRS, design diagrams, javadocs, pseudocode).
  2. Negotiate Stage 1 Delivery Plan and obtain Instructor (or customer) signoff.
  3. Write or verify method headers (if necessary) for Stage 1 modules.
  4. Write or verify detailed design (pseudocode) for Stage 1 modules.
  5. Internal review of Stage 1 detailed design.
  6. Write Stage 1 System Test Cases
  7. Implement Stage 1 modules (write source code).
  8. Internal Review of source code.
  9. Write and run unit tests (using JUnit) and correct any unit defects.
  1. Integrate Stage 1 modules, performing a daily build.
  2. Write and Run integration tests and track and repair any integration defects.
  3. Develop automated System Test Scripts for Stage 1 as appropriate.
  4. Run System Tests (manual and/or automated) and track and repair any defects.
  5. Release Stage 1 software when release criteria are met.

Repeat for Stage 2 with these additional steps:

  1. Formal white box unit test cases are documented.
  2. Unit tests are written (as JUnit tests) BEFORE modules are implemented.
  3. Public method javadoc comments include DBC or Error Checking comments.
  4. Formal Code Inspections instead of Internal Reviews.
  5. Coverage Testing

In parallel with the above Stage 2 tasks the team must also: Repair defects in Stage 1, respond to customer change requests in Stage 1, and release Stage 1 updates.

2.1.1 Staged Delivery Plan

The Staged Delivery Plan is 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. The Staged Delivery Plan is maintained by the analyst.

2.2 Organizational Structure

Each team consists of 5-10 students. The recommended internal management structure is called Controlled Decentralized (See Pressman, Ch 3). The team has a defined leader who coordinates activities and secondary leaders that have responsibilities for certain deliverables. The major roles are Manager, Designer, Implementation Manager, and Quality Assurance.

2.3 Organizational Boundaries and Interfaces

In CPE 309 there are two important interfaces:

  • The Analyst is the liaison with the Customer. (If there is no real Customer, the instructor may play this role).
  • The Team Manager reports to upper management (Course Instructor).

2.4 Project Responsibilities

The major responsibilities are described in the document: Job Descriptions.

3.0 Managerial Process

3.1 Management Objectives and Priorities

3.1.1 Objectives

  1. Carry out this project plan.
  2. There must be quantitative estimating, monitoring and controlling of the development process. Quantitative indicators of progress for cost, schedule, scope, and quality must be tracked and publicized on the team web page.
  3. Equitable distribution of work. All team members must share equally in all project tasks. In particular, System Test Scripts, module designs and implementation, and Unit Tests must be divided into clearly identifiable work units that are assigned to specific individuals.

3.1.2 Priorities

Since this project has a fixed schedule (the ten week quarter) Management's first priority must be to assure that the work is completed on time. Quality is next priority as it most directly represents student learning. When necessary, functionality must be sacrificed in order to meet the first two priorities.

Management should be on guard for the tendency of students to "gold plate" their work products with superficial "flash" such as clip art, graphics, or animation. Insist on clean, neat, organized work, but beyond that put effort into technical content and not cosmetic appearance.

Management should try to offer opportunities for all students to learn a variety of software engineering skills. Don't simply assign the most qualified student to a task. Consider assigning students to unfamiliar tasks from which they could benefit.

3.2 Assumptions, Dependencies, and Constraints

The schedule is fixed. All work must be submitted by 5p.m. the last day of classes. The budget (student hours worked) is not unlimited. Assume 9-15 hours per week per student outside of class. Assume the customer will reply to e-mail or return phone calls twice a week. Don't assume that work can be completed on student home computers. There may be certain equipment or software that is only available in the campus computing labs.

3.3 Risk Management

One person on the team will be identified as the Risk Manager. It is his/her duty to lead the team through the following Risk Management procedures. The Risk Manager's responsibilities are further explained in Stiller Chapter 9.7 - 9.10. or Pfleeger Chapter 3.4.

How to Identify and Retire Risks

  1. Each team member spends 10 minutes exploring his or her greatest fears for the project’s success.
  2. Each member specifies these risks in concrete language, weights them, writes suggestions for how to mitigate or retire the risk and e-mails to the risk manager.
  3. Risk manager integrates risks from team and performs calculations of risk priorities and creates a draft Risks List.
  4. Group spends 10 minutes reviewing Risks List, seeking additional risks and proposing other retirement plans.
  5. Team spends 10 minutes finalizing the Risks List and designates responsible risk retirement engineers for each item.
  6. The risk manager and posts the Risks List on the team web page.
  7. Responsible engineers do risk retirement work.
  8. Team reviews risks for 10 minutes at weekly meetings. Responsible engineers report progress. Team discusses newly perceived risks and adds them to risks list.

3.4 Monitoring and Controlling Mechanisms

This section explains how project cost, schedule, quality, and functionality will be tracked throughout the project.

3.4.1 Team Meetings

The team will meet twice a week during lab to organize and coordinate activities. Effective groups should find the designated lab time to be adequate for team meetings. Smaller working groups may meet outside of class to accomplish specific technical tasks.

Whenever the team (or part of the team) meets, a formal status meeting agenda is to be followed. This includes both scheduled lab periods and also outside of class meetings. The status meeting is NOT a problem solving session, it is a concise progress reporting meeting. It should take only 15 - 20 minutes. The meeting format is:

a) Report on tasks assigned at previous meeting

  1. Accomplishments
  2. Unfinished tasks

b) Identify problems encountered/solved (but don't discuss).

c) Compare estimated vs. actual progress data. Revise or update schedule, if necessary.

d) Risks discussion (see Risk Management Plan) (10 min/week) e) Assign tasks (action items) for next period.

The manager (or whoever is leading the meeting) is to document the status meeting by recording all the above items in the project journal (see Reporting Plan, below). Also record who was in attendance and if anyone was absent, excused, or tardy.

When the status meeting is finished, the team can proceed to their "working" meeting to discuss technical issues, solve problems, coordinate tasks, and carry out portions of the technical work that can not be done individually. Also the Change Board should meet to consider submitted change requests.

3.4.2 Required Reports

Team Home Page

Make a copy of the team home page template and install it on your team account. You may supply your own team logo, but do not waste any time with further cosmetic customizations. The home page template provides links to many other project document templates which do require customizing. Follow the italicized directions to tailor the templates for your team/project.

Trac tickets

  • Each developer's tasks will be tracked using the Trac ticket system. You should track every task that takes longer to complete than 15 minutes. It is essential that the ticket descriptions be complete, clear, and detailed. If there isn't a ticket for a task, then as far as the instructor knows, you didn't do it.
  • You should add two custom fields to your Trac tickets. Add a Due Date field and a Status field (with status codes as shown in the Action Item Template). Only one person on the team has the necessary privileges to login to a shell on wiki.csc.calpoly.edu and change the trac.ini file.

Weekly Timelog

  • Required by Monday 8:00 am to the manager
  • Report weekly time and activities

Progress Reports

  • The Progress Report is a summary of the team's progress for review by external stakeholders. Produced weekly, by project manager, submitted electronically to instructor by 5pm on Monday. Use as a subject line: Progress Report: team name
  • Follow the Progress Report Template.

Project Journal - OPTIONAL

  • Use a bound "composition book" for the journal. You can purchase one at the bookstore, they have a black and white speckled cover and a black binding. Do not use a three ring binder or spiral binder. Record all entries chronologically and leave no blank pages. You must write legibly as the instructor will be reviewing your journal on a weekly basis.
  • The purpose of the journal is to document the process the team went through in creating their product. It is a record of all team activities. It can be maintained by the manager or by a designated recorder. See Ch 14 pg 209.
  • The journal contains the complete minutes from every status meeting (see format above). Be sure to record all action items assigned and their priority. See these sample meeting notes.
  • Be sure to document significant management and technical decisions made during the meeting.
  • Document problems encountered, alternate solutions proposed, pros and cons, action plans, and results.
  • Alternatively you may choose to post meeting notes on the team web site; ask instructor for approval.

3.4.3 Project Visibility

The team home page is the primary place where the current team status will be made visible to project stakeholders. It is the team manager's responsibility to see that the home page status indicators are kept updated on a weekly basis. Action items and similar timely information will need to be updated daily. Follow the directions on this page of visibility calculations. Follow crontab directions or see change control.

3.4.4 Current Action Items

Use the Trac ticket system to track action items. You should consider modifying the fields in the Trac ticket to include the information in this recommended Action Item Template.

3.5 Staffing Plan

The "staff" for this project are the student team members. It is assumed the students have met the course prerequisites. List each team member's names and roles in the "Contact Info" section of the team home page.

3.5.1 Nametags

The team will create nametags as part of the first laboratory activity. Each team member is required to wear their team name tag at all team meetings and all customer meetings..

3.6 Training Plan

Developer's will carry out the activities in this Training Plan to gain the necessary skills for their tasks. The team may add other tasks as appropriate or necessary.

4.0 Technical Process

4.1 Methods, Tools, and Techniques

This section will be decided based on the specific project selected. In general, teams may choose the tools they prefer. Complete the "Tool" column of the table below with the names of specific tools you have selected for your project.

4.1.1 Team Tool List

Each team is required to specify a tool in each category ("none" might be OK) and have this list approved by their lab instructor. Consult Dr. Dalbey's tool list on the Resources page. If the tool is already filled in, a team will need to argue persuasively if they want to change it.

Category Tool Notes
Project Tracking Trac Sample Trac Project
Class Skeletons Javadoc
Design by Contract (DBC teams only) Javadoc or Java asserts and a strong human specification enforcer
Java Integrated Development Environment Eclipse 308 students are used to IDEs such as BlueJ. Eclipse is also available on lab machines.
Metrics Refer to QA plan to see what metrics we must gather. TimeLogger is recommended for time recording
HTML WYSIWYG editor Mozilla Composer Recommended.Must be viewable in Mozilla 1.4, IE 5.0 browsers. Don't use Microsoft word to generate HTML2.
Unit/Integration Testing JUnit
Coverage Measurement Emma Others: Brian McCain?'s CT, or Clover
System/GUI Testing SwingRobot or Abbot Also unix shell scripting language.
Defect Reporting / Tracking Elementool Teamatic if you have 5 or fewer team members.
Source code control CVS or Subversion Tortoise CVS/SVN is a suggested Windows client.
Build tool Ant
Source code formatter FixStyle Your Own Team's Formatter!
Code Standard Checker CheckStyle Here's the configuration file for our course: 308style.xml
Here are the custom checks for our course: 308checks.jar

2Prohibited tools: Microsoft Word, Rational Rose. (Any work product submitted as a Microsoft Word document will receive a zero, unless pre-approved by instructor.)

4.1.2 Email Standards

Occasionally the instructor will mail announcements to the entire class by using an alias which sends mail to your OracleMail account. If you don't use OracleMail regularly, you should setup your OracleMail account to forward your mail to your regular email account.

It is recommended that you use the Computer Science department machine "falcon" or Central Unix or OracleMail as your primary email account.

The instructor will not read email whose "Sender" field is not an actual student name. Don't use nicknames in mail you send to the instructor or it will be returned to you unread.

In general, do not send attachments to the instructor. Instead, put all your correspondence in the message body.

If the instructor is playing the role of customer for your team, any email intended for the customer must have "To Customer" in the Subject line.

4.3 Project Support Functions

4.3.1 Quality Assurance Plan

The QA manager is responsible for executing the Software Quality Assurance Plan (SQAP).

4.3.2 Configuration Management Plan

The Change Manager is responsible for customizing the Change Control Plan for your project. Read McConnell? Chapter 6 and Pressman Chapter 9. Some basic strategies are outlined in Change Control Considerations. 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.

For source code control the team will use CVS on Falcon. See the course resources page for directions on setup and use.

During Stage 2 the source code repository must maintain at least two branches: one for new development towards the next release and one for repairs on the current release. The branches are merged during integration testing for the new release. (See Branch and Merge Tutorial).

At some point during Stage 2 your team will be asked to demonstrate that your team is using both branches appropriately. At some random time during lab the instructor will check these items:

  • The cvs admin must show that the repository is indeed branched.
  • The web page for source code control includes directions to developers about how to use both branches of the repository.
  • A randomly selected developer will be asked to demonstrate making a fix to a stage 1 module in one branch of cvs, and making an enhancement to the same module in the stage 2 branch to verify they are indeed separate branches.
  • The daily build procedure web page has been modified to show how TWO builds are done, one in each branch. (Implementation Manager's job).
  • The daily build report shows BOTH build reports.
  • There is a link to download BOTH builds on the team home page.
  • The implementation manager will be asked to do a build on the spot and then a randomly selected developer will be asked to run each build and highlight the differences.

5.0 Work Packages, Schedule, and Budget

5.2 Schedule

5.2.2 Detailed Schedule

Each team maintains a detailed schedule as a separate document linked from their home page. The schedule is a chronological table showing due dates for all the milestones for the entire project. As a general starting point refer to the course schedule on the course home page. Then read Table 5-1 to see 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.

How "detailed" should the detailed schedule be? It doesn't need to show individual action items; those appear in the Current Action Items list. It should show every task that requires the coordination of efforts of two or more people. There are enough tasks in the project that the detailed schedule should probably show something due every day of the quarter.

The schedule should be extremely detailed for the immediate future (e.g., two weeks) and may be less detailed for the distant future.

5.2.2 Integration Plan

An important tool for scheduling is the Integration Plan, maintained by the Implementation Manger. It is a table which shows the order modules will be implemented and integrated into the build. This plan requires very careful planning and is crucial to getting your product completed on schedule. Use this recommended template.

5.3 Budget

A major management objective for CPE 309 is to have all schedules be driven by quantitative cost estimates. Perform the estimates below and show all calculations on your team web page.

The major tasks for which you should estimate effort are:

  • Developing New Product Features
  • Correcting Defects
  • Writing System Test Scripts
  • Writing Unit Tests

The manager will have to determine how resources should be allocated among these different taks. Use your judgement to include estimates for other significant tasks.

Budget Computation

Find the total of (Programmer 1's available hours / week) + (Programmer 2's available hours / week) + ... (Programmer n's available hours / week). Multiply by 10 weeks to find the total hours available in your budget for the project.

In order to maintain product quality at a level that will meet the Release Criteria and stay within budget you may have to be selective about product Scope, which is dictated in your Staged Delivery Plan. Bonus points will be awarded to teams that stay within their allocated budget.

Estimating new development costs

Create a table showing the names of all the new methods to be developed. For each one make an estimate of its size as lines of code.

To estimate the cost of new development, divide the total lines of code by your team productivity rate. For example, 350 LOC / 15 LOC/hr = 23 hours.

Your team productivity rate is determined from your historical data on Stage 1 (dividing total LOC by total implementation hours). If that is not available, use a number between 10 and 20 LOC/hr.

You may need to update your estimates several times as you gather more accurate productivity data. Include a link to all previous estimates.

Estimating testing and maintenance costs

In a similar manner, estimate the costs for writing system and unit tests. You may not have reliable historical data upon which to base your estimates. In that case, use a productivity rate of 1.5 hour per System Test Script and 2 hours per class Unit test.

In a similar manner, estimate maintenance costs. You may not have reliable historical data upon which to base your estimates. In that case, use a productivity rate of 1 hour per defect.

In order to predict how many defects you will have to repair, consult your project history data from Stage 1 or use a figure consistent with industry standard of 50-100 defects per KLOC.

Budget Summary Table

Stage Activity Est Hours Actual Hours

Stage 1

System Test Scripts 25 Unit Tests 35 Implementation 30

Defect Repair 25

other tasks ...

Stage 2

System Test Scripts 15

Unit Tests 25

Implementation 20

Inspections 10

Defect Repair 20

TOTAL n

Available hours x

Place a summary table like this one as well as all the above computations on your team web page. Release 2 Recalibration Project estimates are recalibrated at the end of Release 1 and posted on the team web site. (See pg 239).