group 5 - project plan

8/3/2019 Group 5 - Project Plan

1/23

PROJECT PLAN

Group Five Design

Or de lAcadie British Side

Document Revision #: 1.0

Date of Issue: January 31, 2012

Project Manager:Ryan MacLeod


2/23

Project Plan Or de lAcadie British Side

Approval Signatures

Approved by: Business Project Leader Approved by: IM/IT Project Leader

Prepared by: Business Project Manager Prepared by: IM/IT Project Manager

Reviewed by: Quality Assurance Manager

Version 1.0 January 31, 2012 Page i


3/23


Table of Contents

1. Project Overview.....................................................................................1

1.1 Purpose, Scope, and Objectives............................................................................1

1.2 Assumptions, Constraints and Risks......................................................................1

1.3 Project Deliverables................................................................................................1

1.4 Schedule and Budget Summary.............................................................................2

1.5 Evolution of the Plan...............................................................................................2

1.6 References............................................................................................................ .2

1.7 Definitions and Acronyms.......................................................................................3

2. Project Organization...............................................................................4

2.1 External Interfaces..................................................................................................4

2.2 Internal Structure....................................................................................................4

2.3 Roles and Responsibilities.............................................................................. .......4

3. Managerial Process Plans......................................................................5

3.1 Start-up Plan.............................................................................................. ............5

3.1.1 Estimates....................................................................................................................5

3.1.2 Staffing.......................................................................................................................5

3.1.3 Resource Acquisition..................................................................................................6

3.1.4 Project Staff Training..................................................................................................7

3.2 Work Plan...............................................................................................................7

3.2.1 Work Breakdown Structure........................................................................................7

3.2.2 Schedule Allocation....................................................................................................8

3.2.3 Resource Allocation...................................................................................................9

3.3 Project Tracking Plan................................................................................... ........10

3.3.1 Requirements Management.....................................................................................10

3.3.2 Schedule Control......................................................................................................10

3.3.3 Quality Control..........................................................................................................10

3.3.4 Reporting..................................................................................................................10

3.3.5 Project Metrics..........................................................................................................10

3.4 Risk Management Plan.................................................................................. ......11

3.5 Project Closeout Plan...........................................................................................11

4. Technical Process Plans.....................................................................12

4.1 Process Model.....................................................................................................12

4.2 Methods, Tools, and Techniques.........................................................................12

4.3 Infrastructure.......................................................................................................12

OrganizationGroup Five Design

Title/SubjectOr de lAcadie British Side

Number1.0

Owner RM Approved by SP Date January 31, 2012 Version Page ii


4/23


4.4 Product Acceptance....................................................................................... .....12

5. Supporting Process Plans.................................................................14

5.1 Configuration Management........................................................................... ......14

5.2 Verification and Validation...................................................................................14

5.3 Documentation............................................................................................... .....14

5.4 Quality Assurance.............................................................................................. .15

5.5 Reviews and Audits.............................................................................................15

5.6 Problem Resolution.............................................................................................15

5.7 Process Improvement..........................................................................................16

6. Additional Plans..................................................................................17

7. Project Evolution.................................................................................18

7.1 Project support and maintenance........................................................................18

7.2 Follow-up projects............................................................................................ ...18

7.1 Project Support and Maintenance...................................................................................17

7.2 Follow-up Projects..........................................................................................................17



Number1.0

Owner RM Approved by SP Date January 31, 2012 Version Page iii


5/23


Document Change Control

This section provides control for the development and distribution of revisions to theProject Charter up to the point of approval. The Project Charter does not change

throughout the project life cycle, but rather is developed at the beginning of the project

(immediately following project initiation approval, and in the earliest stages of project

planning). The Project Charter provides an ongoing reference for all project stakeholders.The table below includes the revision number (defined within your Documentation Plan

Outline), the date of update/issue, the author responsible for the changes, and a briefdescription of the context and/or scope of the changes in that revision.

Revision Number Date of Issue Author(s) Brief Description of Change

1.0 Jan. 31, 2012 RM First Edition



Number1.0

Owner RM Approved by SP Date January 31, 2012 Version Page iv


6/23


1. Project Overview

This section of the IM/IT Project Management Plan provides an overview of thepurpose, scope and objectives of the project for which the Plan has been written, the

project assumptions and constraints, a list of project deliverables, a summary of the

project schedule and budget, and the plan for evolving the IM/IT ProjectManagement Plan.

1.1 Purpose, Scope, and Objectives

The British characters currently have minimal interaction within the game. Toenhance game play for all characters, this project looks to increase the game play for

the British side characters by adding more interactions within the game world.

This will be accomplished by attempting to incorporate NPCs (Non Player

Characters) that will help in communication between British characters. As well as apuzzle system, that allows the players to translate French clues into English, which

helps the British characters find treasure. There will be a limited number of words

included in the translation system to make it less tedious for the players.

Weaponry and fighting will be left out of any of the enhancements as we try to add

to the British game play experience. The interaction between characters other thanBritish ones will be left for a different development team.

Upon completion of the project it will be integrated into the pre-existing frameworkfor Or de lAcadie. The project will be stand alone from additional add-ons being

developed by other teams. The success of the project will depend on the complete

integration of at least one of the planned features. Failure to have a workingenhancement will be considered a failure of the project.

1.2 Assumptions, Constraints and Risks

A key assumption is that the British characters in the game have basic movements,

such as walking around. Another assumption is that the current game is working and

easily modifiable. The assumption is that the game is robust and flexible to change.

A major constraint is the unfamiliarity with the openwonderland framework and with

only two months to become familiar with it. Also, the projects process could belonger than what was initially planned, so this may cause delays or possibly

incomplete parts. Also, working with the code that is already in place may cause

problems if it is not intuitive and robust.

1.3 Project Deliverables

The project will deliver software written in Java in conjunction with the framework

of openwonderland. The software will contain add-on enhancements for the Britishcharacters in the game. Hard copies of the following documents will be given to Dr.

Reilly:

OrganisationGroup Five Design

Project PlanOr de lAcadie British Side

Number1.0

Owner - RM Approved by Date - January 31, 2012 Version Page 1


7/23


Project Charter

SRS & Project Plan

Design sketches and evaluation notes

System Design & Detailed Design Docs

Documented Code Base

Test Plan

Test Reports

User Manual

Deployment Guide

Minutes of Project Meetings

All reviews (both given and received)

The list of items will be delivered no later than March 29, 2012 along with a working

demo of the project.

1.4 Schedule and Budget Summary

No money will be spent over the duration of the project.

1.5 Evolution of the Plan

Each stage of the process will come with a review of the plan to ensure that it

matches the current flow of the project. An unscheduled update will be done with theconsent and knowledge of the customer. If changes are made to the plan a new

version number will be issued, the original version starts at 1.0 and will increase

accordingly.

1.6 References

Project Charter Group Five Designs, Version 1.1, January 27 2012, Stu Penner,

Group Five Design



Number1.0


Milestone/Deliverable Planned Completion Date

Project charter January 20, 2012

Project plan, requirements document January 31, 2012

Prototype 1: throwaway February 14, 2012

Design documents February 28, 2012

Prototype 2: implementation steel thread March 13, 2012

Updated documents March 27, 2012

User manual March 27, 2012

Deployment guide March 27, 2012

Demo March 29, 2012


8/23


1.7 Definitions and Acronyms

openwonderland An open source virtual world. Written in Java, it comes with alarge support network of already created add-ons and features.

IM/IT Information Management/Information Technology

SRS Software Requirements Specification



Number1.0



9/23


2. Project Organization

2.1 External Interfaces

The customer, Dr. Derek Reilly, will be informed of any changes to the organizationthat occur over the course of the project. He will also contribute any suggestions for

changes he feels are necessary for a successful completion of the project.

2.2 Internal Structure

Given that our team consists only of four members, there will be a small portion of

separated tasks taken on by each team member. For example, the following tasks will

be handled by all members of the team; documentation, development, qualityassurance, testing, and validation of the final product. Project management will be

given to a specific individual.

2.3 Roles and Responsibilities



Number1.0


Role Responsibilities

Project ManagerEnsures project is on track, interacts with sponsor, delegates tasks to

software engineers

Software Engineer Planning through all stages, software development, software testing

Sponsor Provides guidance and direction to ensure project is on track.

Sponsor

Project Manager

SoftwareEngineer

SoftwareEngineer

SoftwareEngineer

Software

Engineer


10/23


3. Managerial Process Plans

This section of the IM/IT Project Management Plan specifies the projectmanagement processes for the project. This section defines the plans for project

start-up, risk management, project work, project tracking and project close-out.

3.1 Start-up Plan

3.1.1 Estimates

The estimate of time required for each stage is based on the time given to

complete the stage and on the description of the stage itself. The confidencelevel ranges from low-high and is high for completed documents simple updates.

The total estimated time scheduled for the project is: 45 person-days.

The re-estimation of effort will be done on the project milestones. This will be

done based on project description and from an estimate given by the customer,

as they will expect a certain task completed in a specific time frame.

3.1.2 Staffing

The project will require four staffed individuals, including the project manager.

The skill level of each individual is equivalent, since the framework being used

is unfamiliar to all staff at the moment. The personnel are required to be on handready to take on tasks from January 2, 2012 to March 29, 2012.



Number1.0


Milestone/DeliverableEstimated Time

(person-days)Confidence Level Planned Completion Date

Project charter 2 High January 20, 2012

Project plan, requirements document 5 High January 31, 2012

Prototype 1: throwaway 5 Low February 14, 2012

Design documents 4 Low February 28, 2012

Prototype 2: implementation steel

thread8 Low March 13, 2012

Updated documents 3 High March 27, 2012

User manual 4 Medium March 27, 2012

Deployment guide 4 Medium March 27, 2012

Demo 10 Low March 29, 2012


11/23


3.1.3 Resource Acquisition

All personnel are already acquired as part of the Group Five Design team. There

are no other projects currently on the go that require attention from any of the

staff.

Any software or hardware resources are available free of cost courtesy of the

Dalhousie Computer Science Department. Personal computers will also be usedfor work from the home or at any time an employee is out of the office.

Facilities to work on the project have been supplied by the customer Dr. Reillyand in conjunction with Dalhousie University.

Software and hardware will not be required until the coding stage of the project

and will involve the following:

Eclipse IDE, Java SDK



Number1.0


Milestone/DeliverableNumber of Staff

RequiredPlanned Completion Date

Project charter 2 January 20, 2012

Project plan, requirements document 3 January 31, 2012

Prototype 1: throwaway 4 February 14, 2012

Design documents 3 February 28, 2012

Prototype 2: implementation steel

thread4 March 13, 2012

Updated documents 2 March 27, 2012

User manual 2 March 27, 2012

Deployment guide 3 March 27, 2012

Demo 4 March 29, 2012


12/23


Openwonderland Server

OSX, Linux or Windows Operating System

Computer with 3D graphics card and a minimum of 128MB of videomemory

3.1.4 Project Staff TrainingEach staff member on the project (all four) will be required to go through theopenwonderland tutorials provided at openwonderland.org. This will be all the

training necessary to ensure that the team is up to speed. Any specific problems

that arise after this initial training will be looked at on a case-by-case basis. Thisapproach is being implemented since it is a very large framework to learn and

only specific parts are necessary for the success of the project.

The project manager will specify any training necessary well ahead of the

required date to ensure ample time for completion.

3.2 Work Plan

3.2.1 Work Breakdown Structure

The project charter requires group input and approval by the customer. This

section has been completed and will be updated as the project moves forward.The resources necessary will be small, one-person hour every two weeks or

when required.

The project plan and requirement documents will identify the requirements and

plan for the entire project. This milestone requires three staff and to have the

fourth on standby for editing and consultation. This portion will be completed

within a week and will provide the customer with insight into our view of theproject. The project plan builds off of the project charter.

Design documents will describe the details of the build structure for the project;

along will the resources and frameworks needed. This document should validate

the SRS. This is one of the last steps before the project moves into the codingphase and is a chance to analyze the design to prevent delays in the future. This

section requires seventy-five percent of the teams man-power and will require

four-person days.

The first prototype (Throwaway) will build off the requirements to create anoverall design for the project. This prototype will attempt to meet the

requirements and will be delivered to the client to critique. This stage will

require the full team resources and will take approximately 5 person-days to

complete. Upon completion and receiving the customer review, the SRS will beupdated to match the new set of requirements if necessary.

Prototype (Steel Thread) is a direct implementation of the design documents.

This prototype is a means to validate each of the design choices made in the



Number1.0



13/23


previous step. This stage will ideally show the customer that the design processwe choose is correct and that the team is ready to move forward to completion.

Test cases will in drawn up in conjunction with this prototype.

Final documentation, presentation, and demo are the final deliverables for the

project. This section is used to gather all the appropriate documents and topresent the final product to the customer. The requirements need to be traced

through each of the design stages to see where they are implemented in the finalproduct. This will require the longest amount of time to create and will require

the full team working at near capacity to ensure that this section is completed ontime. This stage will be the final gauge of if the project was successful or not.

3.2.2 Schedule Allocation

Each milestone must be completed before the project is able to continue to the

next stage.

Milestone/Deliverable Planned Completion Date

Project charter January 20, 2012

Project plan, requirements document January 31, 2012

Prototype 1: throwaway February 14, 2012

Design documents February 28, 2012

Prototype 2: implementation steel thread March 13, 2012

Updated documents March 27, 2012

User manual March 27, 2012

Deployment guide March 27, 2012

Demo March 29, 2012



Number1.0



14/23


3.2.3 Resource Allocation



Number1.0


Milestone/Deliverable

Number of

Staff

Required

Computer

ResourcesOther Requirements

Planned Completion

Date

Project charter 2 Microsoft Word Approval by Customer January 20, 2012

Project plan,

requirements

document

3 Microsoft Word Approval by Customer January 31, 2012

Prototype 1:

throwaway4 Microsoft Word Approval by Customer February 14, 2012

Design documents 2 Microsoft Word Approval by Customer February 28, 2012

Prototype 2:

implementation steel

thread

4

Eclipse

Open wonderland

Microsoft Word

Simulation Facilities

Administrative Support

Approval by Customer

March 13, 2012

Updated documents 1 Microsoft Word Approval by Customer March 27, 2012User manual 2 Microsoft Word Approval by Customer March 27, 2012

Deployment guide 2 Microsoft Word Approval by Customer March 27, 2012

Demo 4

Eclipse

Open wonderland

Microsoft PP

Microsoft Word

Simulation Facilities

Administrative Support

Approval by Customer

March 29, 2012


15/23


3.3 Project Tracking Plan

3.3.1 Requirements Management

Requirements will be managed through the SRS (Software Requirements

Specification) document. The changes to the requirements can be traced throughthe version control implemented on each document.

Assessing the impact of requirement changes will be done on a case-by-case

basis during development. Risk management will be applied at the start of the

project to help identify any potentially high-risk changes that could occur.

3.3.2 Schedule Control

The schedule will be controlled by the progress that has been completed at eachmilestone. If the schedule is off at a particular milestone the customer will becontacted and a meeting will be called to discuss how to move the project

forward.

The calendar system will be set up to mark the days to the next milestone

depending on the stage of the project. This will be compared to the person-dayson the milestone completed and those still remaining against the amount of time

left to complete that section.

3.3.3 Quality Control

Quality control will be measured by the completion of the project with zerocritical errors. Minor bugs will be allowed but anything that causes a system

failure will be studied and corrected. Portions of the requirements and designwill be reviewed by a third party and by the customer to ensure the best

implementation.

3.3.4 Reporting

E-mail and two weekly meetings with the customer will be used to communicate

any changes that will occur to the project. Any project critical communicationmay take on both forms of communication to get the issue resolved. Otherwise

communication will be kept to the weekly meetings if possible. The detail of

these communications will depend on the size and scope of the issue.

3.3.5 Project Metrics

Weekly group meetings will be used to track progress within the group on each

individual task. These will be stored in the weekly minutes with concerns andideas about the project. Milestones will be used as a baseline for tracking the

progress of the overall completion of the project. Discussion with other groups



Number1.0



16/23


working on similar projects will be used to roughly analyze our own progressdata to see where we stand. The customer throughout the project will validate

the metrics.

3.4 Risk Management Plan

Risk management will be done at the start of the project and before major

milestones. It will involve identifying, analyzing, management planning, andreviewing the risk.

Looking at the weak areas of the project will identify the risks and what is critical tomake the project successful. An analysis will give a detailed list of the weak areas

and critical success elements. Management planning will look at the specific ways to

minimize the impact if any of the defined risks occur. This process will be reviewedthroughout the project to ensure the progression of the project. Staff members will be

responsible for alerting the group of any risk factors that may be occurring or have

not mentioned.

Each milestone might bring with it a different set of risks and upon completion thoserisks may no longer be relevant to the project. Each weekly meeting the group willrun through the risks, make additions and changes as necessary. Emergency issues

can be brought to the attention of the project manager at any point.

Some of the major risks of the project revolve around the technology and time

constraints that have been put of the project. The fact that unfamiliar software is

being used by each of the staff member increases the chance of an extendeddevelopment time. Since the project is on a strict timeline this could cause

unsatisfactory deliverables. Since the complexity of the tasks is unknown there could

bring a change to the scope of the project at a later date.

3.5 Project Closeout Plan

Upon completion of the project, hard copies of all communications and projectdocuments will be handed over to the customer, Dr. Reilly. They may also be stored

electronically on each of the staff members personal computers for use in their

portfolios. Each staff member is required to provide a post-mortem analysis of the

project and their experiences. The staff members do not need to be reassigned to afuture project, as there is none currently in the works. The customer will do analysis

of the completion of project objectives.



Number1.0



17/23


4. Technical Process Plans

4.1 Process Model

The customer will dictate information and work products whenever a section of theproject is due. This is outlined in the project timeline on the basis of milestones.

Information within the group will be shared via e-mail and weekly meetings.

The major milestones are project plan and requirements, design documents,

prototyping, final product documents, and a live demonstration of completed British

enhancements. These will all be in the form of deliverables to the customer who willapprove them based on their set of defined criteria for success.

Minor reviews will be conducted weekly to ensure up to date information in

documents. A major review will take place before starting to work on the final demo

product and after completion of all milestones. The standard by which we reviewwill be based on the expectation and criteria set out by the customer.

Project initiation occurred when Dr. Reilly awarded us a contract to develop asection of Or de lAcadie. This process will terminate upon successful completion of

the project, or at the end of the timeline for the project, whichever comes first.

4.2 Methods, Tools, and Techniques

Development will be done using Java in the IDE Eclipse. This will be integrated with

subversion software to track and document changes to the deliverable. The coding

will be broken down to allow each member of the team the ability to work onsections most suited to their strengths. Group input through all steps will keep the

ideas flowing so no one person gets stuck on a specific implementation.

4.3 Infrastructure

Eclipse, Java, and openwonderland are compatible with all operating systems and

network setups. Testing will be done across OSX, Linux and Windows operatingsystems to ensure this assumption holds. Dalhousies computer science department is

equipped with hardware that implements all of these operating systems. Dalhousie

also has a free to access network that openwonderland can be tested on during the

verification stages. Each staff member is responsible for there own working area ifthey do not wish to use that provided by Dalhousie University.

4.4 Product Acceptance

The customer will receive the final deliverables on March 29, 2012. They will bereviewed by the customer and critiqued on the following basis as defined by the

customer in the project details:

Completeness

Consistency

Correctness



Number1.0



18/23


Level of specificity

Clarity

Organization

Format, spelling, grammar

Use of diagrams

These criteria will be used along with meeting of critical success factors outlined inthe project charter.



Number1.0



19/23


5. Supporting Process Plans

5.1 Configuration Management

Any changes to internal documentation will be met with a signature, time stamp, andcomments on why the changes were made. This requires approval of the customer.

Progress will be tracked weekly at the groups meeting and will be built into theminutes for each meeting. Any changes required to the project will be communicated

via e-mail or in person to the customer whenever the need arises.

5.2 Verification and Validation

Analyzing the finished product against the scope stated in the project character will

be the verification for the project. Creating a more realized gameplay experience inthe opinion of the players will validate the process. Demoing the final product will

be a part of the validation.

Peer reviews will be done to ensure the requirements and project details are complete

and outline all the parts necessary to have a successful project. The customer will bereviewing each milestone and giving the group feedback based on a numerical score.This along with comments will verify any choices we made and allow us to change

them if necessary before reaching any critical points. There will be multiple

implementations in the form of a throwaway model and a steel thread model. Eachdocument created will be reviewed as part of a milestone to ensure they are correct

and up to date.

Automated tools such as SVN, wiki, and Dropbox give version control and will give

each group member, as well as the customer, access to the latest version.

5.3 Documentation

Documentation is will be generated as part of the milestones, reviews, and during the

weekly meetings. Generating and reviewing the project documents is theresponsibility of all the members of the group. The reviews for a specific week will

be designated at the beginning of that week and are to be completed by the same

time the following week. The customer has the responsibility to give input into the

project documentation and provide guidance in areas that are incorrect.

The following table contains information about all the documents that will bepresented at the end of the project.



Number1.0



20/23


5.4 Quality Assurance

The product must in its final form implement at least one of the features stated in thescope of the project. This implementation must have a workable demonstration that

can be repeated on multiple occasions. During the course of the project the

milestones must be completed by the date that they are due.

The customer may decide to deem the project a success or a failure depending on his

or her own criteria even if the project does not match the scope initially stated. Aneffort will be made to communicate with the customer to ensure quality is

maintained. Constant review of the documentation and project plan and design will

ensure the project is in the green zone each step of the way.

5.5 Reviews and Audits

Reviews will be performed after the deliverables have been handed in at eachmilestone stated in section 2.1 of the project charter. The customer can retain the

right to review and make changes, as he or she seems fit during any point of the

process.

In house reviews will be done in respect to the documentation processes highlightedin section 4.3 of this document.

5.6 Problem Resolution

Emergency meetings can be called in the event of a major problem that needs to beresolved. These will be done in conjunction with communication to and from the



Number1.0


Document Creation Date Review DatePerson(s)

Responsible

Project charter January 20, 2012 January 27, 2012 Stu Penner

Project plan, requirements document January 27, 2012 February 7, 2012Ryan MacLeod

Travis Russell

Design Sketches and Evaluation

NotesFebruary 28, 2012 TBD Stu Penner

System Design & Detailed Design

DocsFebruary 28, 2012 TBD TBD

Documented Code Base March 27, 2012 March 29, 2012 All Group Members

Test Plan March 12, 2012 March 29, 2012 All Group Members

Test Reports March 27, 2012 March 29, 2012 TBD

User Manual March 27, 2012 March 29, 2012 TBD

Deployment Guide March 27, 2012 March 29, 2012 TBD

Meeting Minutes March 27, 2012 March 29, 2012 Ryan MacLeod

All Reviews TBD March 29, 2012 All Group Members


21/23


customer. The project manager will be in charge of contacting the customer andfinding an appropriate time for the team to meet.

Problems will be tracked during the weekly meetings and stored in the minutes.

These can be reviewed and analyzed at a later point and time. More effort should be

placed on solving the problems rather than on the reporting of them.

5.7 Process Improvement

The project will be assessed at each milestone. This will allow the group to decide if

the method in which they handled the last section was appropriate. Since the group issmall, implementation of process improvement will require little upfront planning.

In the case of a problem, a processed improvement assessment will occur to

minimize the chance of the same problem reoccurring during the project. In the case

of uneven workload distribution the project manager must decide how to divide the

work more evenly.



Number1.0



22/23


6. Additional Plans

No additional plans are required to fulfil contractual obligations.



Number1.0



23/23


7. Project Evolution

7.1 Project support and maintenance

Openwonderland has an assortment of online resources that can be used totroubleshoot and debug any future issues with the software. This can be found at

openwonderland.org. Java also has an online help center that can be found online at

www.java.com.

7.2 Follow-up projects

There will be no follow-up projects that will use this project. The customer however

may decide to overwrite this project with an implementation of his or her own.

OrganisationG Fi D i

Project PlanO d lA di B iti h Sid

Number1 0
http://www.java.com/http://www.java.com/

group 5 - project plan

Documents