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:
- Perform review and repair
of requirements and design from 308 (SRS/prototype, design diagrams,
javadocs,
pseudocode,system tests).
- Negotiate
Stage
1 Delivery
Plan and obtain Instructor (or customer) signoff.
- Write or verify method
headers (if necessary) for Stage 1 modules.
- Write or verify detailed
design (pseudocode) for Stage 1 modules.
- Internal review /
walkthrough of Stage
1
detailed design.
- Commit pseudocode to
repository.
- Begin automatic daily
build, including coverage test report.
- (Recommended) Create an "executing architecture."
- Write Stage 1 System Test
Cases
- Write unit (isolation)
testing scaffolding.
- Implement Stage 1 modules
(write but do not test source code).
- Internal Review (Stage 1)
or Code Inspection (Stage 2) of source
code.
- Run unit tests
(isolation tests) and correct any unit defects.
- Write integration tests.
- Integrate Stage 1 modules
during lab, following Integration Plan, track defects.
- Run integration
tests and track and repair any integration defects.
- Develop automated System
Test Scripts for Stage 1 as appropriate.
- Run System Tests (manual and/or automated) and track
and repair any defects.
- Release Stage 1 software
when release criteria are met.
- Acceptance Testing by
Customer
Repeat for Stage 2 with these
additional steps:
- Formal white box unit
test
cases (Basis Path
tests) are
documented .
Public method
javadoc
comments include DBC or Error Checking comments.
- 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:
- 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 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
- Carry out this project
plan.
- 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.
- 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
- Each team member spends
10
minutes
exploring his or her greatest fears for the project’s success.
- 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.
- Risk manager integrates
risks
from
team and performs calculations
of risk priorities and creates a draft Risks
List.
- Group spends 10 minutes
reviewing Risks
List, seeking additional risks and proposing other retirement plans.
- Team spends 10 minutes
finalizing the
Risks List and designates responsible risk retirement engineers for
each
item.
- The risk manager and
posts
the Risks
List on the team web page.
- Responsible engineers do
risk
retirement
work.
- 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
- Accomplishments
- 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
- 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. If it takes longer than
2 hours it should be decomposed into multiple tickets. 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.
- Each developer will log all time spent on
the project using the Time Accounting
Process.
Individual
Status Reports
- The status report is where each person
documents
their accomplishments for the week. It includes a time log of hours
spent
and what activity they were engaged in. Submitted every week (Suggested
Due: Monday 8:00 a.m.). Submitted to quality assurance (see QA plan)
and
to the team leader. (Electronic submission is fine).
- Follow the Status
Report Template.
- If developers use Trac effectively, the manager may find that the
Trac Timeline feature is an adequate substitute for status reports.
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
posted to team web page
by 9am on
Monday. Use as a subject line: Progress Report: team name
- Follow the Progress
Report Template.
-
In a separate message, forward
all the individual
status reports (including your own). Use as a subject line: Status
Reports: team name
Project Journal
- 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.
- The journal contains the complete minutes
from every
status meeting (see format above). Be sure all action
items
have a Trac ticket created. 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.
- 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.
- You may negotiate any alternate format for
the Project Journal -- see the instructor.
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 Template. The
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:
- "Browse Source" 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 svn, 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.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:
- Writing Source Code
- Unit and Integration Testing
- System Testing
- Maintenance (defects found by customer)
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.