PAETEC

Product Catalog Editor

Project Plan

ProjectPlan.doc

Draft 1.13

February 3, 2009

Team Spy Penguins

Revisions

Version	Primary Author(s)	Description of Version	Date Completed
1.0	Tom Sheppard Phil Schmitte Joe Plourde Rob Marinaro Mark Chadbourne	Initial Revision	12/11/08
1.1	Joe Plourde	Added Release Diagram	12/11/08
1.2	Phillip Schmitte	Added requirements plan, estimation information, WBS	12/16/08
1.3	Mark Chadbourne	Updated Project Lifecycle diagram	12/17/08
1.4	Tom Sheppard	Changes from the sponsor meeting	12/17/08
1.5	Tom Sheppard Joe Plourde	Added metrics tracking descriptions and removed unnecessary supporting plans.	12/18/08
1.6	Phillip Schmitte	Added estimation information and WBS description.	12/24/08
1.7	Phillip Schmitte Robert Marinaro	Updated overview and project lifecycle descriptions.	1/4/09
1.8	Phillip Schmitte	Added schedule section.	1/6/09
1.9	Phillip Schmitte Robert Marinaro Mark Chadbourne	Updated overview, project lifecycle, resources, environment, and project artifacts sections.	1/8/09
1.10	Phillip Schmitte	Updated stage 3 description and schedule.	1/13/09
1.11	Phillip Schmitte Rob Marinaro	Removed any reference to functional points.	1/14/09
1.12	Phillip Schmitte Tom Sheppard	Updated tracking and control to include requirements tracking.	1/22/09
1.13	Phillip Schmitte	Updated schedule section.	2/3/09

Contents

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:

• A master data definition to describe products in general.
• A product definition editor.
• A product catalog export tool.

1.3 Assumptions and Constraints

Assumptions:

• Java will be the primary coding language.

Constraints

• Blueprint will be used to edit requirements and use cases
• Subversion should be used wherever a version control system is required (for both team artifacts and if used within the application).
• Master data definition may be an XML schema or a collection of DB tables.

1.4 Risks and Assets

Assets:

• Blueprint licenses

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.

• Stage 1: In stage one the master product definition will be defined. The goal of this stage is to deliver the underlying functionality of the system, with all the controls implemented that are needed to specify a new product.
• Stage 2: The second stage will implement a web based graphical user interface that accesses the controls implemented in stage one. It will allow non-IT users to add and edit products. There will be a method for capturing all possible values and business rules of an attribute. Users will be able to version and group products into product catalogs, as well as compare between versions.
• Stage 3: Stage three is considered low priority for this project, but the project will be planned and designed to allow the functionality to be implemented if the schedule allows. It is also possible to scale down stage three and deliver only the highest priority items, as an alternative to cutting it completely. In this stage the tools for mapping a product definition to a legacy format will be implemented. Users will be able to output the converted product definitions as either SQL or XML. A unique identifier for each definition entity will be contained in the mappings. These mappings can be saved and reused. Legacy formats will be able to be converted to our new product definitions through the use of these mappings.

The following tasks will be common to all stages.

• Revise requirements: any changes necessary in the requirements will be made at this point. Requirements changes could arise from previous stages or from changes from stakeholders. All changes must be reviewed and accepted by all stakeholders.
• Revise design: changes to the system design stemming from previous phases will be integrated into the design document at this point.
• Implement: All code will be written during this phase. Unit tests will be written as code is implemented, which will assist with regression testing.
• Test: Unit and Integration testing will occur at the end of each increment. The tests will be based on the previously defined Test Plan, but will be geared specifically to the current release. A Test Results document will be created after testing is complete.
• Deliver: All necessary release notes and deployment instructions, along with all source code, will be delivered to the customers.

2.2 Project Organization

2.2.1 Roles and Responsibilities

Role	Responsibility	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
Webmaster	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.	All

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 6^th – Initial drafts of Business Requirements Specification and Software Requirements Specification are complete.

o 16^th – (Fixed) Week 10 evaluations.

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

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

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

· March

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

o 22^nd – Release 1 complete.

· April

o 13^th – (Fixed) Preliminary poster due.

o 15^th – Release 2 complete.

· May

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

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

o 21^st – 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:

• Windows XP/Vista and/or Mac OS X

• Eclipse IDE 3.4 with djUnit 0.8.2 and gwt 1.0 plug-ins
• Java EE 4 SDK
• GWT 1.5
• Tortoise SVN 1.5.6
• ANTLR v3.1.1
• Apache Tomcat 6.0.18
• Internet Explorer 6.0 and/or Mozilla Firefox 3.0

Run-time environment:

• Windows XP/Vista and/or Mac OS X
• Java 4 JRE and Java Virtual Machine
• Internet Explorer 6.0

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:

• Project Charter – this is a general overview of what the product will be and what PAETEC and RIT requires of the project team.
• Project Plan – this document will specify the process the project will follow. It will also define the major schedule items and team roles.

• Risk Management Document – this document will be used to track project risks. Risks will be listed by priority with a manager and mitigation strategy assigned to each.
• Business Requirements Specification – this will contain what PAETEC requires of the project. There will be no software specific requirements defined.
• Software Requirements Specification – this document will extend the business requirements already defined into detailed software requirements.
• System Architecture Document – this document will provide an overview of the system as a whole, listing architectural drivers and other requirements that have driven its design. Multiple architectural views will be included to further describe the system and its goals.
• Design Document – this document will specify the detailed design of the product. This includes class and sequence diagrams.

• Test Plan – each stage will have its own test plan that specifies testing procedures, what will be tested and define the point in the testing process at which completion is achieved.
• Test Results – each stage will have its own test results document that will contain the results and analysis of system tests for each phase of testing.
• Release Notes – each phase will have a release notes document will contain any information specific to the release as well as deployment instructions.
• Post-Mortem – this will be used to reflect on the project to see what could have been better and what the future of the product will be.
• Final Deliverable – a CD(s) containing all project artifacts discussed above along with a final release version of the software and all source code.