Software Project Management Plan (SPMP)
Fall 2008
Preface
This document describes the plan
for
executing a student team project in CPE 308 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, release, and
maintenance.
1.2 Project Deliverables
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.
Written system test case documentation including test case matrix
(online).
High Level Design
Design Overview
UML Class Diagram
Class Skeletons (Javadocs)
Interaction Diagrams (as needed)
Data Structures
Detailed Design
Pseudocode (as comments added to class skeletons).
Integration Plan (Implementation Mgr)
Source code for the finished application, documented according to the
class coding standard. Checkstyle reports that each class has less than
2 minor violations per 100 LOC.
Submit: Printed source code (monospaced 10pt font) and the printed
Checkstyle report. Clipped or bound as appropriate. Include a Credits
Page if the @author tags don't tell the whole story.
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 and optionally LOC count. 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
The process model to be followed
by
student teams during Fall 2008 is the Evolutionary model with
Prototyping.
Analysis Phase
Design Phase
Implementation Phase
- Write Integration Plan
- Write unit tests
- Write fakes and drivers
as needed
- Write source code
- Code Inspection
- Unit Testing
Integration Phase
- Submit passing units to
repository according to Integration Plan
- Perform daily build
- Integration Testing
- System Testing
- Acceptance Testing by
Customer
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.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.) The major roles are shown in the Job
Descriptions.
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
[Refer to Job
Descriptions].
3.0 Managerial Process
3.1 Management Objectives and 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 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
- 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 Required Reports
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. (See
Visiblity Calculations).
Action items and similar timely information will need to
be updated daily. It is recommended that you model your home page after
this team
home page template. You may supply your own team logo, but do not
waste any time with further
cosmetic customizations.
Individual Status Reports
- The status report is where each person
documents
their accomplishments for the week. It includes a timecard 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.
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 5pm 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.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.
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.
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 |
| Analysis Model Drawing |
team choice
|
Visio, SmartDraw, Dia, etc. |
| Java Integrated Development Environment |
team choice |
308 students are used to IDEs such as BlueJ. Eclipse
& NetBeans are
also available on lab machines.
|
| 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 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, Together
Spend some serious time deciding on this issue. |
| 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. |
2Prohibited tools:
Microsoft Word,
Rational Rose. (Any work product submitted
as a Microsoft Word document will receive a zero, unless pre-approved
by instructor.)
CPE 206 Tools
(Optional for CPE 308)
Unit/Integration Testing
|
JUnit |
Also unix shell scripting language, or Ant |
Coverage Measurement
|
Emma |
Others: Brian McCain's CT,
or Clover
|
System/GUI Testing
|
SwingRobot
or Costello
|
Also unix shell scripting language.
|
| 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
|
|
Astyle
recommended. |
Code Standard Checker
|
CheckStyle |
Here's the configuration file for our course: 308style.xml
Here are the custom checks for our course: 308checks.jar
|
4.1.2 Email Standards
Occasionally the instructor will mail
announcements to the entire class by using an alias which sends mail to
your OpenMail account. If you don't use OpenMail regularly, you should
setup your OpenMail 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 Configuration Management Plan
This section to be written by the
Configuration manager.
We will have a very simplified
Configuration
Management
plan: Each document produced will have a table at the bottom showing
Change
History. The history shows the Date, Person, and Description of Change.
Whenever you make a change to a document you must update the change
history.
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.4 Budget
Your "budget" in this course
is the amount of available hours each student can commit to the
project (Not the course) Recommended 10-15 hours per week.
Include a table here showing student commitments and the total hours
per week and for the entire quarter.
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/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.