Product Catalog Editor

Project Plan


Draft 1.13

February 3, 2009

Team Spy Penguins




Primary Author(s)

Description of Version

Date Completed


Tom Sheppard

Phil Schmitte

Joe Plourde

Rob Marinaro

Mark Chadbourne

Initial Revision



Joe Plourde

Added Release Diagram



Phillip Schmitte

Added requirements plan, estimation information, WBS



Mark Chadbourne

Updated Project Lifecycle diagram



Tom Sheppard

Changes from the sponsor meeting



Tom Sheppard

Joe Plourde

Added metrics tracking descriptions and removed unnecessary supporting plans.



Phillip Schmitte

Added estimation information and WBS description.



Phillip Schmitte

Robert Marinaro

Updated overview and project lifecycle descriptions.



Phillip Schmitte

Added schedule section.



Phillip Schmitte

Robert Marinaro

Mark Chadbourne

Updated overview, project lifecycle, resources, environment, and project artifacts sections.



Phillip Schmitte

Updated stage 3 description and schedule.



Phillip Schmitte

Rob Marinaro

Removed any reference to functional points.



Phillip Schmitte

Tom Sheppard

Updated tracking and control to include requirements tracking.



Phillip Schmitte

Updated schedule section.





1 Introduction.. 1

1.1 Overview... 1

1.2 Major Deliverables. 1

1.3 Assumptions and Constraints. 1

1.4 Risks and Assets. 1

2 Management Structure.. 2

2.1 Project Lifecycle. 2

2.1.1 Diagram descriptions: 3

Software Concept and Definition: 3

Requirements Analysis: 3

Architectural Design Phase: 3

Stage Increments. 3

2.2 Project Organization.. 4

2.2.1 Roles and Responsibilities. 4

2.3 Risk and Asset Management. 5

2.4 Communication.. 5

3 Planning and Control.. 6

3.1 Estimate. 6

3.1.1 Estimation Process. 6

3.2 Resource Identification.. 6

3.2.1 Project Scope. 6

3.2.2 Team Effort 6

3.2.3 Physical Resources. 6

3.3 Resource Allocation.. 7

3.3.1 Work Breakdown Structure. 7

3.3.2 Schedule. 8

3.4 Tracking and Control. 8

4 Technical Process. 10

4.1 Engineering.. 10

4.1.1 Environment 10

4.1.2 Methods, Tools and Techniques. 10

4.2 Project Artifacts. 11


1 Introduction

This project plan is the top level controlling document for the Product Catalog Editor project.

1.1 Overview

Currently PAETEC uses spreadsheets and manual transcription to specify their products. This system is prone to human error and is difficult to maintain. PAETEC hopes to create a new system as the first step in reorganizing the way in which it specifies product catalogs.

The proposed system will be a tool to view and edit PAETEC's product catalog using a new master definition to describe new and existing products. It will have a graphical interface that will be designed to enable non-IT users to specify and edit products, and define business rules for entities. Product versioning will be managed by allowing comparison and grouping. The system will support exporting product definitions to XML and SQL. Each definition entity will have a unique ID to allow regression to legacy formats. The master definition must be designed in such a way as to allow reverse engineering from legacy definitions to be possible.

1.2 Major Deliverables

Listed in order of priority:

1.3 Assumptions and Constraints



1.4 Risks and Assets


2 Management Structure

2.1 Project Lifecycle

2.1.1 Diagram descriptions:

Software Concept and Definition:

This is the initial phase of the project where the team gets a high level understanding of the project. At the end of this phase the team should have an idea of the main points the customer is looking for and have a Project Charter defined. The team will also identify the main tasks and create the schedule in this phase.

Requirements Analysis:

Requirements will be gathered by the team through meetings with PAETEC and individual research. A Business Requirements Specification (BRS) document and a Software Requirements Specification (SRS) document will be created to contain all requirements for the project.

The BRS will contain the needs of PAETEC that the product will address. The SRS will translate the business requirements into detailed software requirements. The SRS will be separated into functional requirements and non-functional requirements. Functional requirements specify behaviors of a system. Non-functional requirements are criteria that judge the operation of a system. The functional requirements will be laid out in the SRS as use case diagrams. These diagrams will show how the system will flow based on user actions.

When defining requirements assertive language will be used and ambiguous words will be avoided. Requirements will be prioritized based on importance to PAETEC. Schedule and scope will be considered when defining requirements.

All requirements documentation will be done up front before implementation starts. At the beginning of each stage, the requirements will be reviewed and changes will be made if necessary.

Both documents will be submitted for approval by the RIT advisor and PAETEC. After approval, all changes to the requirements must be approved by PAETEC, the RIT advisor, and Team Spy Penguins on an individual basis. Change requests must be submitted to the other project stakeholders as a formal request. Both requirement changes and change requests will be documented in the BRS or SRS.

Architectural Design Phase:

This phase will have the majority of the project design work. The team will design the structure of the system, as well as how the system will be deployed. The Test Plan will also be defined in this phase. When this phase is complete, the team will have the System Architecture and Design Document completed with all design decisions and class diagrams.

Stage Increments

The project is broken down into stage deliverables. Each deliverable is based on business requirements specified by PAETEC. 


The following tasks will be common to all stages. 


2.2 Project Organization

2.2.1 Roles and Responsibilities



Staff Member

Project Manager

Primary contact with sponsors and coordinating with team members. Also responsible for quality assurance.

Phil Schmitte

Requirements Lead

Oversee requirements solicitation and verification.

Rob Marinaro

Design Lead

Oversee system design and ensure system complies with specifications

Joe Plourde

Implementation Lead

Manages code integration.

Tom Sheppard

QA Lead

Oversees testing plan and ensure proper test coverage.

Mark Chadbourne

Risk Management Lead

Tracks risks and develops mitigation strategies

Phil Schmitte

Configuration Management Lead

Oversees the versioning and maintenance of the project artifact and code repositories.

Joe Plourde


Keeps the website up to date                                        

Tom Sheppard

Note Taker

Take notes. If the note taker is unavailable to take notes, another team member will take the responsibility for that meeting.

Rob Marinaro

Development Engineer

Works on design and implementation.


2.3 Risk and Asset Management

A document will be created listing all risks to the project by priority, which will be determined by probability and severity. Risks will be assigned to a manager, and each will have a mitigation strategy. Risk managers will keep track of assigned risks to reduce their impact.

2.4 Communication

Communication will occur primarily through e-mail, as well as through IM or phone for more immediate responses.

3 Planning and Control

3.1 Estimate

3.1.1 Estimation Process

The project will be broken down into small components, and each point will be discussed using the Wideband Delphi method. This is a consensus based technique that helps remove individual bias from the estimation process. Each member of the team will make a three-point estimate of how much effort each component will take. The three-point estimate refers to an estimate for the best, worse, and average cases. After estimation the team will gather to discuss the variation in their estimates. The team will estimate again and do so repeatedly until a consensus is reached.

This process will be done during the Requirements and Analysis phase once a majority of the requirements have been agreed upon, but before final approval. The estimates made using this method will help design the project schedule. After each release, the estimates and schedule will be evaluated and changes will be made if deemed necessary. If changes are made to the schedule, the estimation process will be repeated for all component affected.

3.2 Resource Identification

3.2.1 Project Scope

This project will span roughly 20 weeks, aligned with the winter and spring quarters of the RIT 2008-2009 school year. Meetings with project sponsors will be held from 4:30-6:00 pm on Tuesdays. Other team meetings will be held on Thursday afternoons, and occasionally on weekends.

3.2.2 Team Effort

Each team member will spend an average of twelve hours per week. There are five members of team Spy Penguins, resulting in sixty hours per week. The time spent on tasks will be documented in the effort tracking document which can be found on the team website.

3.2.3 Physical Resources

The team will have twenty four accesses to RIT’s computers and team rooms. Each room contains whiteboards, a projector, a table, chairs, and a computer running Windows XP. The team also has access to RIT’s server space, which includes a virtual machine, subversion, and web space.









3.3 Resource Allocation

3.3.1 Work Breakdown Structure



























This Work Breakdown Structure breaks the project process down into activities and sub-activities. These activities are non-sequential and ongoing. The seven main activity classes are Planning, Risk Management, Requirements, Design, Implementation, Testing, and Deployment. This diagram will help with the scheduling process. It will also be useful in determining what activities need to be done at each stage of the project.

3.3.2 Schedule

These are the target dates for the major tasks and deliverables. Dates that are inflexible will be noted as fixed.


·         February

o        6th – Initial drafts of Business Requirements Specification and Software Requirements Specification are complete.

o        16th – (Fixed) Week 10 evaluations.

o        17th – (Fixed) Mid-project presentation.

o        19th – Completion of design phase. Major artifacts that will be completed are the Architecture Document, Design Document, and UI prototypes.

o        23rd – (Fixed) Reflections meeting and technical report.

·         March

o        9th – (Fixed) State of the project discussion.

o        22nd – Release 1 complete.

·         April

o        13th – (Fixed) Preliminary poster due.

o        15th – Release 2 complete.

·         May

o        4th – (Fixed) Final presentation and week 10 evaluations.

o        11th – (Fixed) Final deliverables including all project artifacts, a technical report, and post-mortem.

o        21st – Release 3 complete.


3.4 Tracking and Control

Project schedule will be tracked through a Gantt chart in Microsoft Project. The chart will be updated weekly with progress on each task.

The team will be tracking three project metrics. Team Effort is a metric required by RIT, and will be tracked by the weekly effort spreadsheets. RIT also requires two other process metrics of our own choosing. These metrics will be use cases satisfied and estimation accuracy. All metrics will be tracked on the team website.

Use cases and requirements satisfied will provide a method for tracking overall project completion. The number of use cases and requirements will be specified in the Requirement Analysis phase. This metric was chosen because it would be a way to show progress of the project. A use case will be considered satisfied when all steps are completed in implementation.

Estimation accuracy will help to track schedule slippage. The information collected from individual reports will be compiled and compared with the project scheduling estimations. This metric was chosen because it will allow us to improve our time estimation accuracy. Differences between estimates and actual time spent will be used to determine a more accurate estimation for other tasks that have not been implemented yet.

4 Technical Process

4.1 Engineering

4.1.1 Environment

The environment is everything necessary to develop, run and build the final release of this project.

Development environment:

Run-time environment:

4.1.2 Methods, Tools and Techniques

Methods, tools and techniques are items that are utilized during creation of the project, but are not necessary for either the development or run-time environments.

Subversion: This tool will be used for version control of project artifacts. It will also be used within the product, should it require version control.

Blueprint: This tool will be used to capture requirements, use cases, and will be used for UI prototyping.

Microsoft Project: This will be used for creating the project schedule and tracking progress.

Microsoft Visio: Used for modeling of class, package, sequence diagrams and as a tool for UI prototyping along with Blueprint.

4.2 Project Artifacts

Agendas will be created for all meetings with the project sponsors. Meeting minutes will also be taken at all sponsor meetings. Time/effort tracking spreadsheets will be updated weekly by all team members. All documents will be available on the team website.

Other documents include: