CPE 308 Project Plan

Software Project Management Plan (SPMP)

WINTER 2010

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

Deliverable

Author

SRS (Software Requirements Specification)
   Vision & Scope
   Functional Requirements
   Behavioral Requirements (Annotated Scripted Storyboard)
   Quality Attributes (Non-functional requirements)
   Analysis Model (E.g., State Transition Diagram, ERD, Data Flow Diagram)
   Data Dictionary
   Appendix

Functional Prototype

High Level Design
   Design Overview
   UML Class Diagram
   Class Skeletons (Javadocs)
   Data Structures
   Appendix

Analyst
developer A
UI Designer
QA
developer B
developer C
Analyst

Prototyper &
developers A-F

Designer
Designer
developers A-F
developers A-F
Designer

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

Requirements Elicitation

Estimation Process

Write Project Plan (schedule and budget)

User Interface Prototyping Process

Write SRS

SRS Formal Technical Review. FTR process

Design Phase

Create Preliminary Design

Develop fully functioning prototype

Write High Level Design (Object Oriented Design: How-To)

Design Formal Technical Review. FTR process

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

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

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

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. Action Item Tips

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.

The journal should be kept on the Trac wiki.

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

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, OpenOffice Draw, etc.
Java Integrated Development Environment	NetBeans
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	NetBeans has a UML plugin that integrates modeling with code. Other tools: 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 HTML².

²Prohibited 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

Unit/Integration Testing	JUnit	Also unix shell scripting language, or Ant
Line of Code Counting	LOC counter
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 based on these recommendations.

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.

4.3.3 Deployment Plan

This section to be written by the Configuration manager based on these recommendations.

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 and Scheduling Process

Revision Chart

1/12/2010 Revised for Winter 2010
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.