Project Plan
Software Project Management Plan (SPMP)
Spring 2008
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
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 6 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 CPE 309 we will do the implementation, testing, release, and maintenance.
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.
Perform review and repair of requirements and design from 308 (SRS, design diagrams, javadocs, pseudocode). 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 of Stage 1 detailed design. Write Stage 1 System Test Cases Implement Stage 1 modules (write source code). Internal Review of source code. Write and run unit tests (using JUnit) and correct any unit defects. Integrate Stage 1 modules, performing a daily build. Write and 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. Repeat for Stage 2 with these additional steps: Formal white box unit test cases are documented. Unit tests are written (as JUnit tests) BEFORE modules are implemented. Public method javadoc comments include DBC or Error Checking comments.
Formal Code Inspections instead of Internal Reviews. 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
Our team consists of six people.
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
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 10-12 hours per week per student outside of class.
Assume the customer will reply to e-mail 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
The team manager on the team will be identified as the Risk Manager. It is 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 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.
The manager (or whoever is leading the meeting) is to document the status meeting by recording all the above items
in the Meeting Notes (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. 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. 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.
Status Reports - OPTIONAL
Each team manager may require a weekly status report. The status report is where each individual documents their
accomplishments for the week. It includes a timecard of hours spent and what activity they were engaged in.
Follow the Status Report Template.
Weekly Hourly Reports - Luna Mandatory
Each team member must report the amount of time they contributed to the project for the prior week by no later than 8pm on Sundays.
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 Friday. Use as a subject
line: Progress Report: team name
Follow the Progress Report Template.
Project Journal - OPTIONAL
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 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.
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.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. Specific names and roles are shown on the team home page.
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.
A tutorial for help with TortoiseSVN is available.
4.0 Technical Process
4.1 Methods, Tools, and Techniques
4.1.1 Team Tool List
| 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 | Visio, SmartDraw?, etc | |
| Java Integrated Development Environment | team choice | 308 students are used to IDEs such as BlueJ. Eclipse is also available on lab machines |
| User Interface | rototyping defer until prototyping lecture | storyboards recommended |
| Metrics | Refer to QA plan to see what metrics we must gather. TimeLogger? is recommended for time recording | |
| Project Schedule | Use Microsoft Project only if you have a trained teammember | |
| Class Diagram drawing | 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 | 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 309 Tools
(Optional for CPE 308)
| 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 | 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
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.4 Budget
We will budget between 10 to 12 hours per week of the project, more if needed, less if not.
