Software Project Management Plan (SPMP)

[Process Model ]  [Tools]  [QA Plan]  [Test Plan]  [Integration Plan]  [Change Control Plan]

Preface

This document describes the plan for executing a student team project in CPE 308/309 Software Engineering at Cal Poly.

1.0 Introduction

1.1 Project Overview

The purpose of the lab component of the course is to apply software engineering methods to carrying out a software development project. Each team of 5-7 students will be assigned to a produce a particular piece of software. The project will take two quarters to complete. During CPE 308 we will complete the specification, prototyping, and design.  During CSc 309 we will do the implementation, testing, and perform two releases of the system and then perform subsequent maintenance on the released product.

1.2 Project Deliverables

1.2.1 CPE 308

SRS (Software Requirements Specification)
   Vision & Scope
   UI Prototype (Annotated Scripted Storyboard with screenshots)
   Quality Attributes (Non-functional requirements)
   Analysis Model (if needed)
   Data Dictionary
   Appendix

(Optional) User Manual (in HTML or Wiki). Each person takes a section of the manual. Analyst ensures a common style is used.

High Level Design
   Design Overview
   UML Class Diagram
   Class Skeletons (Javadocs)
   Interaction Diagrams (as needed)
   Data Structures
   Appendix

Detailed Design
   Pseudocode (as comments added to class skeletons).

1.2.2 CPE 309

Integration Plan (Implementation Mgr)

Source code for the finished application, documented according to the class coding standard. Checkstyle reports 0 errors and warnings.  Each student must contribute some significant portion of the source code.  Use @author tags to identify code ownership.  The source code exists in the Subversion repository as a NetBeans project.

Written system test case documentation including test case matrix (online).  The tests must be evenly assigned to all developers.

Automated Unit Tests. Passing JUnit tests for all non-gui classes along with test scaffolding that exercises the target class in isolation. Each team member writes the Fakes and JUnit tests for their class, and the QA or Test manager writes a shell script (optionally, Ant script) that runs all the unit tests.
Demo: Checkout source repository, navigate to "tests" folder, run the unit test shell or Ant script that runs the JUnit tests. The console user interface is tested with a script that redirects test keystrokes from a data file.
Post on team web site: A written set of directions for what actions the human tester should manually perform on the GUI, and the expected output from the Fake underneath it. (Optionally, write a Costello script for automated GUI testing).

An integration testing shell script that demonstrate 95% statement coverage using Emma or other coverage tool. Each person converts their unit test script into an integration test. For lowest level classes, the unit test is the integration test. For intermediate level classes, replace the lower fakes with the real classes and change the oracle to expect real output. May still require fake UI. For the top level (application class) run with no fakes and a console ui. Use input data from a file (redirection). Oracle expects real output. The GUI can be tested separately as it will require manual input and a written test plan with expected output. Coverage testing is not required for GUI classes.

Daily build script (using Ant) that includes Checkstyle, Javadoc, and optionally LOC count, test coverage, etc.. Daily build reports are updated after each build. (Implementation Mgr)

Deployment script (may be integrated with daily build script) (Implementation Mgr)

Released product that passes all System Tests and customer Acceptance Test.

This deliverables resource page has required document formats and quality standards.

2.0 Project Organization

2.1 Process Model

2.1.1 CPE 308
The process model to be followed by student teams during CPE 308 is the Evolutionary model with Prototyping.
Analysis Phase Design Phase
The steps in this process do not have to be strictly sequential.  For example, the ui prototype draft can begin while the project plan is being  written, designers may begin creating a preliminary design before every last requirement has been specified. 

2.1.2 CPE 309
The process model to be followed by student teams during CPE 309 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.

Process Diagram (PDF)

In brief, the process goes like this:

  1. Perform review and repair of requirements and design from 308 (SRS/prototype, design diagrams, javadocs, pseudocode,system tests).
  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 / walkthrough of Stage 1 detailed design.
  6. Commit pseudocode to repository.
  7. Begin automatic daily build, including coverage test report.
  8. (Recommended) Create an "executing architecture."
  9. Write Stage 1 System Test Cases
  10. Write unit (isolation) testing scaffolding.
  11. Implement Stage 1 modules (write but do not test source code).
  12. Internal Review (Stage 1) or Code Inspection (Stage 2) of source code.
  13. Run unit tests (isolation tests) and correct any unit defects.
  14. Write integration tests.
  15. Integrate Stage 1 modules during lab, following Integration Plan, track defects. 
  16. Run integration tests and track and repair any integration defects.
  17. Develop automated System Test Scripts for Stage 1 as appropriate.
  18. Run System Tests (manual and/or automated) and track and repair any defects.
  19. Release Stage 1 software when release criteria are met.
  20. Acceptance Testing by Customer
Repeat for Stage 2 with these additional steps:
  1. Formal white box unit test cases (Basis Path tests) are documented .
  2. Public method javadoc comments include DBC or Error Checking comments.
  3. Formal Code Inspections instead of Internal Reviews.
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.2 Organizational Structure

Each team consists of 5-7 students.  The recommended internal management structure is called Controlled Decentralized   The team has a defined leader who coordinates activities and secondary leaders that have responsibilities for certain deliverables. (learn more about team structures.) 

2.3 Organizational Boundaries and Interfaces

In CPE 308 there are two important interfaces:

2.4 Project Responsibilities

The major responsibilities shown in the Job Descriptions are divided among the team members so that each student has a significant role.  In CPE 309 each student will have a different role than they performed in CPE 308.  

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 the last class meeting.
The budget (student hours worked) is not unlimited.  Assume 9-12 hours per week per student outside of class.
Assume the customer will reply to e-mail or return phone calls once a day.
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.

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 during regularly scheduled lab periods 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) Problems encountered/solved.

c) Revise or update schedule, if necessary.

d) Assign tasks (action items) for next period and create Trac tickets.

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 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.

3.4.2 Project Visibility

Team Home Page

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.
 
Trac tickets and time logging
Individual Status Reports Progress Reports Project Journal

3.5 Staffing Plan

The "staff" for this project are the student team members.  It is assumed the students have met the course prerequisites.  Specific names and roles are shown on the team home page.

3.5.1 Nametags

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

3.6 Training Plan (optional for 308)

If the staff are lacking in any technical skills needed to complete the project a training plan is a useful tool for ensuring that training needs get met.  Refer to the Training Plan TemplateThe instructor will assign specific activities in this Training Plan to gain the necessary skills for the project.  The team may add other tasks as appropriate or necessary. 

4.0 Technical Process

4.1 Methods, Tools, and Techniques

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.  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 Home page template.
Class Skeletons Javadoc
 
Design by Contract (DBC teams only)  Javadoc
or Java asserts
and a strong human specification enforcer 
Analysis Model Drawing team choice
 Open Office Draw, SmartDraw, Dia, etc.
Java Integrated Development Environment    NetBeans The software must build and execute using NetBeans on the CSL lab machines running Linux.
User Interface prototyping paper & pencil, HTML,
Netbeans GUI builder
storyboards recommended.
Metrics    Refer to QA plan to see what metrics we must gather. 
TimeLogger is recommended for time recording
Project Schedule   ASCII table
Optional: Fedora "Planner" is installed on lab machines under "Applications -> Office -> Project Management".
Also, GanttProject or Gnome Planner. Use Microsoft Project only if you have a trained teammember. 
Class Diagram drawing  team choice
Tools can draw clean diagrams and some can generate code from UML. 
Suggestions:  Violet, ArgoUML, NetBeans UML module
HTML WYSIWYG editor   team choice
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
HttpUnit
Also unix shell scripting language, or Ant
Coverage Measurement
Emma Others: Brian McCain's CT, or Clover
System/GUI Testing
Costello

Selenium
Costello is used for desktop apps.
Selenium for web apps (browser-based).
Also unix shell scripting language.
SwingRobot may be useful in some situations.
Defect Reporting / Tracking Trac

Source code control
 Subversion
(integrated in Trac)
Tortoise CVS/SVN is a suggested Windows client.
RapidSVN available in lab.
Build tool
Ant

Source code formatter
NetBeans formatter
Astyle is a quick stand-alone tool.
Code Standard Checker
CheckStyle Here's the configuration file for our course: 308style.xml
Here are the custom checks for our course:  308checks.jar
Web Server
Tomcat
Available in instructor account.
Database
SQLite
Available on CSL lab machines.
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 Cal Poly mail account. If you don't use Cal Poly mail regularly, you should setup your account to forward your mail to your regular 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 Change Control Plan (309)

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 Subversion, integrated with Trac.

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:


5.0 Work Packages, Schedule, and Budget

5.1 Work Breakdown

A work breakdown statement (WBS) is a categorized list of tasks with an estimate of resources required to complete the task. 
Sample Work Breakdown Statement

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 (e.g., day to day) for the immediate future (e.g., two weeks) and may be less detailed (lab to lab) for the distant future.

5.2.3 Integration Plan

The Integration Plan is maintained and administered by the Implementation Manager.

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:

The manager will have to determine how resources should be allocated among these different taks. Consult the project deliverables (sec 1.2) and process model (sec 2.1) for sources of other significant tasks. Use your best judgement to include effort estimates for these 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.
 

Estimating new development costs

You may use an estimation procedure similar to what you used in CSc 308.  However, now you have detailed designs on which to base your LOC estimates, so your estimates should be more accurate.

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.  (This table is the beginning of the Integration Plan).

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 Testing
25
  Unit Testing 35
  Implementation 30

Defect Repair 25

other tasks ...

Stage 2 


  System Testing 15

Unit Testing 25
  Implementation 20

Inspections  10

Defect Repair 20

other tasks ...

  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).


5.5 Schedule

Each team maintains a detailed schedule as a separate document linked to from their home page.  Refer to the textbook to find out what a schedule should contain. As a general starting point refer to the course schedule on the course home page.

Importantly, each team must decide the date each major deliverable is due.  Once they commit to these dates, there will be significant penalty for late submission.

Estimation Process



Revision Chart

11/24/2008 Added "appendix" to High level design deliverable
11/17/2008 Added "appendix" to SRS deliverable
11/2/2008 Revised for Fall 2008

The above template is based on IEEE 1058.1-1987.
This material is copied and/or adapted from the Survival Guide Website at www.construx.com/survivalguide/. This material is copyright © 1993-1998 Steven C. McConnell. Permission is hereby given to copy, adapt, and distribute this material as long as this notice is included on all such materials and the materials are not sold, licensed, or otherwise distributed for commercial gain.