Department of Computer Science and Engineering The...

Breaking Bat 1 Project Charter

Department of Computer Science and Engineering

The University of Texas at Arlington

Breaking Bat

Virtual Slugger

Team Members:

Sean Gibeault

Brandon Auwaerter

Ehidiamen Ojielu

Roshan Lamichhane

Geoff Graham

Last Updated: 8/22/2014 @ 6:00 PM


Table of Contents

1__GENERAL ORGANIZATION 4

1.1 PROJECT MANAGER 4 1.2 PROJECT OVERSIGHT 4 1.3 ROLES AND RESPONSIBILITIES 5 1.4 PROJECT CONSTRAINTS 6 1.5 PROJECT ASSUMPTIONS 7 1.6 PRELIMINARY SCHEDULE AND COST ESTIMATES 8

2__SCOPE STATEMENT 9

3__COST MANAGEMENT PLAN 10

4__EARNED VALUE MANAGEMENT 11

5__SCOPE MANAGEMENT PLAN 12

6__WORK BREAKDOWN STRUCTURE 14

7__QUALITY MANAGEMENT PLAN 19

7.1 INTRODUCTION 19 7.2 DOCUMENTATION 19 7.3 SOFTWARE 19 7.4 HARDWARE 19 7.5 TEST PLAN 19

8__COMMUNICATIONS PLAN 20

8.1 INTRODUCTION 20 8.2 INTERNAL COMMUNICATION 20 8.3 EXTERNAL COMMUNICATION 20

9__CHANGE MANAGEMENT PLAN 22


9.1 PURPOSE OF INTEGRATED CHANGE MANAGEMENT PLAN 22 9.2 ROLES AND RESPONSIBILITIES 22 9.3 REVIEW AND APPROVAL PROCESS 23 9.4 CHANGE IDENTIFICATION, DOCUMENTATION, IMPLEMENTATION AND REPORTING 24

10 RISK MANAGEMENT PLAN 26

10.1 PURPOSE OF RISK MANAGEMENT PLAN 26 10.2 ROLES AND RESPONSIBILITIES 26 10.3 RISK IDENTIFICATION 26 10.4 RISK TRIGGERS 26 10.4 RISK ANALYSIS 27 10.5 RISK SEVERITY 28 10.6 RISK RESPONSE PLANNING 29 10.7 RISK DOCUMENTATION AND REPORTING 29 10.8 RISK CONTROL 29

11__PROCUREMENT MANAGEMENT PLAN 30

11.1 PURPOSE OF THE PROCUREMENT MANAGEMENT PLAN 30 11.2 ROLES AND RESPONSIBILITIES 30 11.3 REQUIRED PROJECT PROCUREMENTS AND TIMING 30 11.4 DESCRIPTION OF ITEMS/ SERVICES TO BE ACQUIRED 31

12__PROJECT CLOSEOUT REPORT 32

12.1 PURPOSE OF CLOSEOUT REPORT 32 12.2 ADMINISTRATIVE CLOSURE 32 12.2.3 LESSONS LEARNED 32


1 General Organization

1.1 Project Manager

The Project Manager for team Breaking Bat is Sean Gibeault. He is currently pursuing an

undergraduate Computer Science degree from the University of Texas at Arlington. He has real

world management experience in several different career fields. The team selected him based on

these qualities.

The Project Manager’s duties will include maintaining the project plan, organizing meetings,

assigning roles and responsibilities to team members, and keeping the team on track to complete

the objectives by the end of the semester.

1.2 Project Oversight

1.2.1 Internal Controls

The Project Manager will control the internal structure of the team by delegating roles and

responsibilities to his fellow teammates as well as providing a set of standards that indicate what

is expected of each member. Team members will formally report to the Project Manager weekly

at minimum to update him on the status of individually assigned tasks. The standards by which

our team will uphold all assignments will be clearly communicated during the duration of the

project.

Informal team meetings will officially be held Tuesday and Thursday of every week after class.

The Project Manager will set the agenda for each meeting and will be updated on the status of all

individual and team deliverables. The purpose of these meetings is to provide consistent

communication throughout the group to influence optimal cohesion. Along with these meetings,

Sunday evenings will consist of formal meetings either in person or via Google Hangouts. The

purpose of these meetings is to formally finish any deliverables that need to be looked over

before being turned in, updating the Project Manager of individual statuses, and assigning new

tasks. The days listed above are the projected meeting days, but are subject to change

.

1.2.2 External Controls

The team will adhere to various forms of external control measures put in place by the project

supervisor. These measures are put in place to ensure that our team is following the course

guidelines and to provide a way for the progress of the team to be reported to the supervisor. The

following are the most relevant forms of external control that affect the team.


Team Status Reports: The team status reports are presented at the times stated in the course

calendar. These reports include any and all completed tasks, relevant team updates, and other

important information that the team wishes to share with the project supervisor. A PowerPoint

presentation will be created for each status report and all team members will present the report to

our colleagues and the project supervisor.

Individual Status Reports: Individual status reports will also be completed at the times stated in

the course calendar. These reports are completed on an individual basis by all members of the

team and turned in during the course lab period. The reports are to include any tasks that an

individual member of the team has worked on since the previous individual status report.

Gate Reviews: Throughout the course of the semester, several team gate reviews will be

submitted. These reviews provide our team the opportunity to present our latest major team

deliverables to our peers and the project supervisor. The purpose of these reviews is to

demonstrate that our team is prepared to move on to the next phase of the development model.

The project supervisor will decide if our team is ready to continue to the next phase.

1.3 Roles and Responsibilities

Role Member Description

Project Manager, Risk

Manager

Sean Gibeault Assigns Tasks, provides

direction, Maintains risk

management plan

Project Planner Roshan Lamichhane Maintains project plan.

Hardware Specialist Geoff Graham Provides hardware expertise

and research.

Secretary Brandon Auwaerter Records minutes of team

meetings and cost

management

Document Master Ehidiamen Ojielu Handles document review

Sponsor Mr. Smith Provides requirements and

advice

Project Supervisor Mr. O’Dell Oversees the project and

provides guidance to the

team.


In addition to the roles above, all team members will take part in common tasks such as

documentation, presentation, research, etc.

1.4 Project Constraints

The team has identified and documented several constraints that could potentially influence the

timing, cost, resources, and/or the quality of the product. These constraints, along with their

potential impact, are described in detail below:

Limited Time: The project duration will be limited to approximately 7 months. This

limited amount of time could negatively influence the team’s ability to stay within the

allotted time frame.

Limited Budget: The project consists of a maximum of $800 to spend on any necessary

resources or equipment. Along with this our team was able to acquire $300 from an

outside sponsor, allowing us to have a maximum spending amount of $1100. This

constraint limits the scope of the types of resources that the team can purchase and

impacts important implementation decisions.

Other Course Work: Every member on the team is taking at least two summer classes

and plan on taking at least four classes in the fall. Along with this, most of the team

members are working for outside companies 20+ hours a week. This limits our ability to

dedicate larger amounts of time to the product we are developing. Team members may

become unavailable due to the magnitude of the work for other courses and jobs.

Limited Knowledge: The team has limited knowledge in several technologies associated

with our product. Many of us have not worked with sensor integration, virtual reality

technology, and graphic design that are necessary to the success of our project. This

constraint could hinder the team’s ability to complete the product in the most efficient

way possible.


1.5 Project Assumptions

The team has identified several assumptions that could have future implications on the successful

development of the product. These assumptions are enumerated below:

Team Effort: All team members will provide their best effort in completed assigned

tasks and will complete their tasks in a timely manner. The quality of the individual

deliverables to the team will meet the minimum standards set by the team beforehand.

Member Retention: All current team members will remain a part of the team throughout

the course of both Senior Design I and Senior Design II. In other words, no team member

will drop either of these courses.

Technology: We assume that there are methods to interface the various hardware and

software components necessarily to successfully complete the project. These assumptions

pose the greatest risk to our project and will be elaborated in more detail in the risk

management section of this document.

Team Meetings: We assume that we will be able to informally meet at least twice a

week and formally meet for an hour or more at least once a week. We also assume we

will not lose our focus in these meetings in order to optimize the time spent during the

meetings.

Good Communication: The team assumes that there will be good communication

between all team members, the project sponsor, and the project supervisor. We assume

that all voices will be heard when needing any help or providing information to other

team members.


1.6 Preliminary Schedule and Cost Estimates

Project Schedule (Phase I: Senior Design 1)

Project Milestone Due Date

SRS Initial Draft 07/03/14

Project Charter Initial Draft 07/10/14

Project Plan Initial Draft 07/10/14

Requirements Gate Review 07/18/14

Architecture Design

Specification Draft

08/07/14

Baseline Project Charter 08/08/14

Baseline Project Plan 08/08/14

Architecture Design Gate

Review

08/12/14

Project Schedule (Phase III: Senior

Design II)

Project Milestone Due Date

Baseline Architecture Design 09/05/14

Detailed Design First Draft 09/22/14

System Test Plan Final Draft 10/17/14


2 Scope Statement

2.1 Introduction

The purpose of Virtual Slugger is to provide any enthusiastic baseball hitter with an interactive

virtual batting practice session and offer tips in order to improve the user’s hitting skills. The

user will be placed inside a virtual environment where he/she will face off against a virtual

pitcher. The pitcher will throw a virtual baseball and the user will try to hit the ball. The user will

be swinging a real bat and our system will keep track of the bat location and bat speed in order to

offer feedback to the system.

2.2 Product Definition

The system will be built with several pieces of hardware including an Oculus Rift, Kinect, and

bat sensors. The Oculus Rift is a virtual reality headset the user will wear while attempting a hit.

The Kinect and the bat sensors are sensors that will track the user’s swing and analyze the data to

offer tips. The users of this system will choose what type of hitter they want to become, such as a

power hitter, an on base percentage hitter, or a mixture of both. After the user makes their

selection, the system will track their swing and where they are hitting the baseball and offer

unique tips based on the given input.

2.3 Intended Audience

The intended audience of this product is anyone who wants to gain or improve their skills in

hitting a baseball. The situation in which this system is useful is for high school, college, or

professional recruiting. This system will alleviate the need to have a pitcher on-call in order to

have a live batting practice to determine if the prospective player is a good hitter. This will also

be useful for players wanting to improve their skills and do not have any experience with hitting

a baseball.


3 Cost Management Plan

3.1 Introduction

This section discusses how the team will manage the allotted budget to purchase the materials

needed to complete the project. The cost management plan will focus on maintaining our budget

outlined in the System Requirements Specifications as well as the Project Plan.

3.2 Financial Costs

This project will use a majority if not all of our $800 budget. Most of our budget will be used for

the hardware needed to create the project. The hardware includes the Oculus Rift, Kinect, and a

bat sensors which accumulates to around $650. The team will also need to spend $80 for the

Unreal game engine, which brings the total to $730. The project manager will be responsible for

making sure the team stays within budget and documenting any changes that may arise as the

project progresses.

3.3 Labor Costs

Using COCOMO, the project is estimated to require approximately 8.0 man-months or 1520

man-hours for completion. The total project time is estimated to be completed in 7.1 months. If

we divide the work evenly amongst 5 team members, each member will have 304 hours of work

that needs to be completed. This can be accomplished if each team member performs 15-20

hours of work each week. The team will have meetings at least twice a week to make sure

project deliverables are on schedule. The meetings will consist of analyzing where we are and

where we should be, and also analyzing any new risk that arises. The team leader will be

responsible for making sure the project stays on schedule.


4 Earned Value Management

4.1 Introduction

This section will discuss the importance of Earned Value Management and how the team will be

tracking the performance as a team and as an individual throughout the process of completion of

project in 5 months period.

4.2 Purpose and Measurement

Effectiveness and performance of the team as well as an individual will be based on Earned

Value Management technique. The Earned Values are based on the following criteria:

● BCWP - Budgeted Cost of Work Performed.

● BCWS- Budgeted Cost of Work Scheduled.

● ACWP- Actual Cost of Work Performed.

● WBS- Work Breakdown Structure

● % Completion

Earned Value will be calculated based on completion of tasks. Task completion will be

calculated as 0% or 100%. If the task is completed, it will be given 100% and if the task is not

complete it will be given 0% even though only a part of task is needed to be completed. Each

task has an initial budgeted cost (BCWS) which may be less than, equal to or greater than the

actual budget cost (ACWP) to complete the specific task.

4.3 Purpose and Measurement

The team will be using two performance indices, namely, Cost Performance Index (CPI) and

Schedule Performance Index (SPI). The CPI will be used to analyze if the project is within our

budget, in this case, Person-hours and SPI will be used to analyze the performance of the team.

Mathematically,

CPI = BCWP

ACWP

If CPI >=1, it is implied that the project is within budgeted time. Good Performance

If CPI <1, it is implied that the task has exceeded budgeted time. Poor Performance

Similarly,

SPI= BCWP

BCWS

If SPI >= 1, it is implied that the team performance is good.

If SPI < 1, it is implied that the team performance is poor.


5 Scope Management Plan

5.1 Introduction

This section discusses the scope management plan which outlines how the team will manage

changes to the scope of the project and how they will be integrated into our overall project plan.

The scope management plan will also aid in avoiding feature creep and adding features that

might not be feasible given the time and budget constraints.

5.2 Definition

The team has compiled a list of various requirements that are necessary to complete the project

on time and to the desired level. These requirements are listed in the System Requirements

Specification document and are ranked based on how critical they are to the system. Given the

difficulty of the project and the lack of experience the team has with the current technology

stack, the team has decided to be cautious of feature creep. The project will be broken down into

four different stages that will assist in avoiding feature creep. Below are the four stages:

Stage Hardware Software

Stage 1 Get accelerometer and

gyroscope readings from

baseball bat and integrate

Oculus Rift into game engine.

Create baseball environment

with a pitcher and a menu

system

Stage 2 Integrate sensor readings into

the game engine.

Develop pitcher throwing

baseball

Stage 3 Integrate the Kinect into the

game engine

Offer tips based on swing

Stage 4 Baseball Bat Calibration Keep track of user statistics


5.3 Management

The project manager will ultimately be responsible for the team on track. However, every team

member should also be aware of the specifications assigned to them and not get off task. If the

team needs to add/edit/remove requirements, the team will discuss potential risk, feasibility and

potential dependencies. The project manager will have the authority on making the final

decision. If a requirement is changed the team will account for this in the project plan. The team

plans on handling the most critical requirements first and gradually working our way down to the

least critical requirements.


6 Work Breakdown Structure

6.1 Purpose

Our Work Breakdown Structure is divided into four broad parts namely Senior Design 1, Senior

Design 2, meetings, and research. Senior Design 1 will focus on the documentation of Virtual

Slugger and Senior Design 2 phase will focus on the implementation of Virtual Slugger. The

meetings will catch up all the team members as well help with development. The research is

allocated so that the team can find out which hardware and software combination will meet our

requirements for the project.

In Phase 1, we have the System Requirements Specification, Project Plan Documentation and

Architecture Design Specification. It starts on June 16, 2014 and ends on August, 25, 2014.

In Phase 2, we have Architecture Design Specification continued which includes Detail Design

Specification, Test Plan and Prototype. It starts on August 25, 2014 and ends on December 11,

2014 with the completion of the Fall Semester.


6.2 Work Breakdown Table

WBS Task Name %

Complete

Planned

Start

Planned

Finish

Actual

Finished

Date

ACWP BCWS BCWP CPI SPI

1 Phase 1 (Senior

Design 1) 84%

Thu

6/19/14

Mon

8/25/14 NA

226.5

hrs

263

hrs 241 hrs 0.00 0.00

1.1

System

Requirements

Specifications

100% Thu

6/26/14 Tue 7/22/14

Mon

7/21/14 177 hrs

179

hrs 179 hrs 1.03 0.00

1.1.1 First Draft 100% Thu

6/26/14 Thu 7/3/14

Thu

7/3/14 114 hrs

118

hrs 118 hrs 1.22 1.00

1.1.1.1 Project Concept 100% Thu

6/26/14 Thu 7/3/14

Sun

6/29/14 10 hrs 10 hrs 10 hrs 1.00 1.00

1.1.1.2

Product Description

and Functional

Overview

100% Mon

6/30/14 Thu 7/3/14

Tue

7/1/14 10 hrs 10 hrs 10 hrs 1.00 1.00

1.1.1.3 Customer

Overview 100%

Fri

6/27/14 Thu 7/3/14

Sun

6/29/14 15 hrs 10 hrs 10 hrs 0.67 1.00

1.1.1.4 Packaging

Requirements 100%

Mon

6/30/14 Thu 7/3/14

Tue

7/1/14 8 hrs 10 hrs 10 hrs 1.25 1.00

1.1.1.5 Performance

Requirements 100%

Tue

7/1/14 Thu 7/3/14

Wed

7/2/14 14 hrs 10 hrs 10 hrs 0.71 1.00

1.1.1.6 Safety

Requirements 100%

Sat

6/28/14 Thu 7/3/14

Sun

6/29/14 9 hrs 10 hrs 10 hrs 1.11 1.00

1.1.1.7 Maintenance and

Support 100%

Mon

6/30/14 Thu 7/3/14

Tue

7/1/14 10 hrs 10 hrs 10 hrs 1.00 1.00

1.1.1.8 Other

Requirements 100%

Tue

7/1/14 Thu 7/3/14

Wed

7/2/14 7 hrs 10 hrs 10 hrs 1.43 1.00

1.1.1.9 Acceptance Criteria 100% Sat

6/28/14 Thu 7/3/14

Sun

6/29/14 10 hrs 10 hrs 10 hrs 1.00 1.00

1.1.1.10 Use Cases 100% Sun

6/29/14 Thu 7/3/14

Mon

6/30/14 10 hrs 10 hrs 10 hrs 1.00 1.00

1.1.1.11 Feasibility

Assessment 100%

Thu

6/26/14 Thu 7/3/14

Sun

6/29/14 8 hrs 8 hrs 8 hrs 1.00 1.00

1.1.1.12 Future Items 100% Tue

7/1/14 Thu 7/3/14

Tue

7/1/14 3 hrs 10 hrs 10 hrs 3.33 1.00

1.1.2 Gate Review 100% Tue

7/8/14 Tue 7/15/14

Tue

7/15/14 51 hrs 49 hrs 49 hrs 0.00 0.00


1.1.3

Baseline System

Requirements

Specifications

100% Wed

7/16/14 Fri 7/18/14

Mon

7/21/14 12 hrs 12 hrs 12 hrs 0.00 0.00

1.2 Project Plan

Documentation 65%

Thu

7/3/14 Fri 8/8/14 NA 20 hrs 28 hrs 28 hrs 0.00 0.00

1.2.1 First Draft 100% Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 20 hrs 28 hrs 28 hrs 1.08 1.00

1.2.1.1 General

Organization 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.1.2 Scope Statement 100% Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.1.3 Cost Management

Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 2 hrs 3 hrs 3 hrs 1.50 1.00

1.2.1.4 Earned Value

Management 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 2 hrs 2 hrs 2 hrs 1.00 1.00

1.2.1.5 Scope Management

Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 2 hrs 3 hrs 3 hrs 1.50 1.00

1.2.1.6 Work Breakdown

Structure 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 3 hrs 4 hrs 4 hrs 1.33 1.00

1.2.1.7 Quality

Management Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.1.8 Communication

Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.1.9 Change

Management Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.1.10 Risk Management

Plan 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 2 hrs 4 hrs 4 hrs 2.00 1.00

1.2.1.11 Project Closeout

Report 100%

Thu

7/3/14 Thu 7/10/14

Wed

7/9/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.2.2 Baseline Project

Charter 0%

Fri

7/11/14 Fri 8/8/14 NA 0 hrs 0 hrs? 0 hrs 0.00 0.00

1.2.3 Baseline MS

Project File 0%

Sat

7/19/14 Thu 8/7/14 NA 0 hrs 0 hrs? 0 hrs 0.00 0.00

1.3

Architecture

Design

Specification

77% Wed

7/23/14

Mon

8/25/14 NA 29.5 hrs 56 hrs 34 hrs 0.00 0.00

1.3.1 First Draft 89% Wed

7/23/14 Fri 8/1/14 NA 29.5 hrs 36 hrs 34 hrs 0.00 0.00

1.3.1.1 Introduction 100% Wed

7/23/14 Fri 8/1/14

Thu

7/31/14 3 hrs 5 hrs 5 hrs 1.67 1.00

1.3.1.2 Meta Architecture 100% Wed

7/23/14 Fri 8/1/14 Sat 8/2/14 3 hrs 5 hrs 5 hrs 1.67 1.00


1.3.1.3 Architecture

Overview 100%

Wed

7/23/14 Fri 8/1/14

Wed

7/30/14 2 hrs 3 hrs 3 hrs 1.50 1.00

1.3.1.4 Input Layer 100% Wed

7/23/14 Fri 8/1/14 Fri 8/1/14 3 hrs 3 hrs 3 hrs 1.00 1.00

1.3.1.5 Processing Layer 100% Wed

7/23/14 Fri 8/1/14 Sat 8/2/14 3 hrs 3 hrs 3 hrs 1.00 1.00

1.3.1.6 Storage Layer 100% Wed

7/23/14 Fri 8/1/14

Thu

7/31/14 3 hrs 3 hrs 3 hrs 1.00 1.00

1.3.1.7 Output Layer 100% Thu

7/31/14 Fri 8/1/14

Thu

7/31/14 3 hrs 3 hrs 3 hrs 1.00 1.00

1.3.1.8 Requirements

Mapping 0%

Wed

7/23/14 Fri 8/1/14 Fri 8/1/14 2 hrs 2 hrs 0 hrs 0.00 0.00

1.3.1.9 Relationship

Mapping 100%

Thu

7/31/14 Fri 8/1/14

Thu

7/31/14 4 hrs 5 hrs 5 hrs 1.25 1.00

1.3.1.10 Testing

Consideration 100%

Wed

7/23/14 Fri 8/1/14

Wed

7/30/14 1.5 hrs 2 hrs 2 hrs 1.33 1.00

1.3.1.11 Operating System

Dependencies 100%

Wed

7/23/14 Fri 8/1/14

Tue

7/29/14 2 hrs 2 hrs 2 hrs 1.00 1.00

1.3.2 Gate Review 0% Fri 8/8/14 Sun 8/10/14 NA 0 hrs 20 hrs 0 hrs 0.00 0.00

2 Phase 2(Senior

Design 2) 0%

Tue

8/26/14

Thu

12/11/14 NA 0 hrs 25 hrs 0 hrs 0.00 0.00

2.1

Architecture

Design

Specification

0% Tue

8/26/14 Sun 8/31/14 NA 0 hrs 10 hrs 0 hrs 0.00 0.00

2.2 Detailed Design 0% Tue

8/26/14

Wed

9/17/14 NA 0 hrs 15 hrs 0 hrs 0.00 0.00

2.2.1 Introduction 0% Tue

8/26/14

Wed

9/17/14 NA 0 hrs 0 hrs? 0 hrs 0.00 0.00

2.2.2 Architectural

Overview 0%

Tue

8/26/14

Wed

9/17/14 NA 0 hrs 3 hrs 0 hrs 0.00 0.00

2.2.3 Components 0% Tue

8/26/14

Wed

9/17/14 NA 0 hrs 3 hrs 0 hrs 0.00 0.00

2.2.4 Quality Assurance 0% Tue

8/26/14

Wed

9/17/14 NA 0 hrs 3 hrs 0 hrs 0.00 0.00

2.2.5 Requirements

Traceability Matrix 0%

Tue

8/26/14

Wed

9/17/14 NA 0 hrs 3 hrs 0 hrs 0.00 0.00

2.2.6 Acceptance Criteria 0% Tue

8/26/14

Wed

9/17/14 NA 0 hrs 3 hrs 0 hrs 0.00 0.00

2.3 Test Plan 0% Fri

9/19/14 Fri 10/10/14 NA 0 hrs 0 hrs 0 hrs 0.00 0.00

2.3.1 Introduction 0% Fri Fri 10/10/14 NA 0 hrs 0 hrs 0 hrs 0.00 0.00


9/19/14

3 Meeting 100% Mon

6/16/14 Fri 12/5/14 NA 181 hrs

158.5

hrs 158.5 hrs 1.13 0.00

4 Research 100% Mon

6/16/14 Fri 12/5/14 NA 42 hrs 45 hrs 45 hrs 0.00 0.00


7 Quality Management Plan

7.1 Introduction

In order to build a reliable product, guidelines must be set and followed to ensure all the

requirements of the product are met. This plan outlines the steps that will be taken by the team to

ensure the quality of the product.

7.2 Documentation

We have adopted Google drive which provides a suite of tools for effective document

collaboration. This enables us to work on all documents remotely and be more productive. We

also schedule early deadlines so that we have adequate time for revision by the team. During

revisions we check for conceptual and grammatical errors which gives us the opportunity to

discuss and understand the evolution of the project. We also expect all team members to

document their ideas and thoughts in their engineering notebook to be shared during team

meetings.

7.3 Software

In order to provide stable and reliable software the Breaking Bat team will ensure the following:

● Source code must be well documented with comments.

● Source code style guide must be adhered for consistency.

● Utilization of source revision tool.

● Behavioral or Test-driven development.

7.4 Hardware

The product will be utilizing a Virtual Reality Headset and additional sensors. All hardware

components must be well researched and must be feasible based on the budget. Hardware

components will be tested before and after being integrated into the product to ensure proper

functioning.

7.5 Test Plan

A detailed test plan for hardware and software components will be developed. Every major

feature will be tested against the requirements in the System Requirement Specification. Testing

will cover performance, reliability and safety.


8 Communications Plan

8.1 Introduction

Communication is very important in building a successful product. This will highlight the

different methods and tools used by team for internal and external communication.

8.2 Internal Communication

8.2.1 Team Meetings

We have brief meetings after class where we provide updates on assigned tasks. We also have

more detailed meeting on Saturdays and Sundays where we are able to meet for hours and

discuss more on the project and the specified agenda.

8.2.2 GroupMe

This is a mobile application that supports group messages. We use this for short messages as

well as messages that require immediate feedback.

8.2.3 Hangouts

Since it is not possible to have everybody meet in person all the time we use Google Hangouts

for remote conferencing. We are still able to discuss and work on the project without losing

productivity.

8.2.3 Facebook

We also have a private group on Facebook. This is where we share links to interesting research

and findings related to the project.

8.2.4 Email

This is for more official communication among team members.

8.3 External Communication

8.3.1 Email

This is for communicating with our Sponsor (UTA Baseball Coach) as well as other official

external communication.


8.3.2 Meetings

We schedule meetings with our sponsor and other outside parties ahead of time and also provide

an agenda for the meeting.


9 Change Management Plan

9.1 Purpose of Integrated Change Management Plan

In developing and building a product, change is bound to occur either in the customer or system

requirements. If change is not handled properly by the team, we could end going in the wrong

direction or have no direction at all. So in order to be better prepared for changes we have

outlined measures in the sections below.


The following are the stakeholders and their responsibilities as regarding change management:

● Project Sponsor: Our sponsor may propose changes to the project which will be

reflected in the Systems Requirement Specification under customer requirements. Also,

any additional changes that may affect the concept of the product may require the

sponsor’s approval.

● Project Manager: The manager will provide insight and guidance on proposed changes

to the product before a final decision is made collectively as a team.

● Project Team: Members of the team may propose any change to the product which will

be reviewed and assessed by the other team members before being approved by the

project manager.

● Other Stakeholders: other interested and concerned parties may propose changes to the

system which will be reviewed by the team members and project manager or supervisor

and eventually decided upon.


9.3 Review and Approval Process

Changes to the product can be proposed by the stakeholders identified above. When a change is

proposed, the change will be documented in a Change Proposal Document and sent to the team

members to be reviewed. The team will analyze the proposed change by looking at the various

areas the proposed change will affect such as budget costs, delays in project plan etc. If agreed

feasible, the team will run this with the project manager/supervisor for guidance and further

insight. If approved by manager then the proposed change will be implemented.


9.4 Change Identification, Documentation, Implementation and Reporting

When a change request is proposed, the requester fills out a change request form which will be

hosted on Google drive as a form for easy access. On submit, the form is emailed to all team

members and a team meeting is scheduled to discuss the proposed change(s). If the change is

officially approved, the System Requirement Specification will be updated if necessary as well

as the WBS to account for any schedule changes, deliverable changes and project cost changes.

All submissions will be tracked and stored on Google drive for future references.

Link to Change Requested Form hosted on Google drive.

Change request form -- Breaking Bat

https://docs.google.com/forms/d/1ptsuKKsLciUwTsohtFl7YE0VFKMgHGBLO4CU0_zP8CM/edit


10 Risk Management Plan

10.1 Purpose of Risk Management Plan

This section will deal with risk management of the project and how to deal with and mitigate

these risks. Risk management is important for our project because of the different types of

technologies that we are incorporating which our team have little or no experience with. The

team will work together to come up with a plan to deal with the different types of risk and

address them accordingly. Because of our limited knowledge of the scope of the project up

front, we will initially have many risks to address dealing with the unknown.


● Project Sponsor - The sponsor will be kept up to speed with project activities/risks and

consulted when necessary.

● Project Manager - The project manager will be in charge of keeping the team on task

and on track. He is responsible for keeping up with the risk management plan and

ensuring that the correct action is taken in the event that one of the identified risks occurs.

● Project Team - The team is responsible for identifying potential risks and developing a

plan to mitigate the risks.

● Risk Manager - The risk manager is responsible for keeping track of risks and

addressing potential new risks that may arise. They will lead the team in identifying risks

and how to deal with them.

10.3 Risk Identification

The team will have a meeting to discuss potential risks and try to identify as many as possible.

The team will review high-level deliverables, the work breakdown structure, and any other input

from the team member based on their experiences to identify risks. Each of these risks will be

analyzed by the group to assess probability of the risk happening and how much time will be

lost. The biggest risks identified will be discussed further to devise a plan of action to avoid the

risk and reduce the probability of the risk coming to fruition.

10.4 Risk Triggers

● Delay in receiving sensors or other equipment ordered

● Schedule slips

● Sensor Integration Issues

● Lack of game development experience leading to more development time

● Requirement changes


10.4 Risk Analysis

This section identifies initial risks associated with the project. The team has identified these risks

and estimated their probability and potential lost time associated with each risk. The table below

shows the results:

Risk Probability Time Lost (weeks) Assessment

Sensor Integration

Issues

Medium (50%) 6 2.4

Lack of Game

Development

Experience

High (70%) 3 2.1

Equipment not

arriving on time

Low (20%) 1 .2

Getting behind

schedule

Medium (40%) 1 .4

Loss of team member

for a period of time

Low (20%) 1 .2

Additional issues that

may arise during

development

Low-Medium (35%) 4 1.4


10.5 Risk Severity

Risk Priority Containment Strategy Triggers

Sensor Integration

Issues

1 Use different

sensors/method

Unable to connect

sensors on bat with

game engine

Lack of Game

Development

Experience

1 remove some

requirements to make

more time

Game development

taking longer than

expected

Equipment not

arriving on time

2 try to work on other

areas of the project

Equipment arrival

time delayed

Getting behind

schedule

2 remove some

requirements to make

more time

Schedule slips

Loss of team member

for a period of time

3 re-allocate workload Team member is

unable to contribute

their part of the work

for the time period

Additional issues that

may arise during

development

3 assess each issue as it

arises and allocate

time and resources to

solve the issue

One of our

requirements requires

additional work that

was not planned


10.6 Risk Response Planning

Team Breaking Bat will account for the highest priority risks by allocating additional time for

research and learning. Outside sources with experience will be contacted and used as a source of

information to help the team make the best choices available. The team will stick to an internal

schedule to stay ahead of deliverable dates to account for additional time loss.

10.7 Risk Documentation and Reporting

The team will use a spreadsheet on Google drive for to keep track of risks like the table above.

New risks identified will be added by the risk manager. When risk triggers occur the risk

manager will follow the plan documented on the risk management spreadsheet.

10.8 Risk Control

Team Breaking Bat will continually discuss risk weekly to ensure they are not any surprises. Any

new risk identified will be documented and the team will discuss a plan on how to manage this

risk. Once a plan is developed the risk manager will update his spreadsheet and the project

planner will update the project plan with these new changes. The entire team will be held

responsible for identifying risk and communicating to the team when a new risk has been found.


11 Procurement Management Plan

11.1 Purpose of the Procurement Management Plan

The Procurement Management Plan is a detailed plan on how the team plans to acquire all the

necessary equipment to successfully complete the project. This is an essential part of our plan

because our group will need quite a few pieces of equipment to get started on development. It

also details the roles and responsibilities of all the parties involved as well as the

necessity/timing of planned procurements relative to our schedule.


● Project Sponsor - Will provide a standard collegiate metal bat as well as player testers as

required and coaching tips

● Project Manager - The Project Manager will collect all the research data from the team

and lead a discussion on what the finalized purchase orders should be and submit a

document to the COTR

● Project Team - Team members will conduct extensive research on bat sensors to ensure

that the correct sensors will be acquired.

● Project Stakeholders - The UT Arlington baseball team may be required to test our

prototype.

● Contract Officer Technical Representative (COTR) - The COTR will be responsible

for communication between the team and Professor O’Dell as well as delivering our

procurement document

11.3 Required Project Procurements and Timing

The team will need to make a number of purchases to acquire the necessary equipment to

develop the product. Our team has a lack of experience in game development and we would like

to counteract this risk by getting familiar with the game engine and Oculus Rift technology.

Luckily we already have an Oculus Rift 1.0 at our disposal and plan to start experimenting with

it in the next couple of weeks.

Our team sponsor has offered us one of his baseball bats to use for the prototype. The team

needs to do more research on accelerometer/gyroscope sensors before we make an order to start

developing the bat controller.

The team will be taking note of the Microsoft Kinect 2.0 demo July 15th to get an idea on if the

Kinect will meet our requirement for capturing the position of the bat in the game engine. This

piece of equipment is not available until later on in the year and we will decide on the necessity

of it after the demo.


11.4 Description of Items/ Services to be acquired

List of major project deliverables to be acquired for project integration:

● Oculus Rift

● Kinect

● X-Box Controller

● Game Engine

● Accelerometer

● Gyroscope

● Baseball Bat


12 Project Closeout Report

12.1 Purpose of Closeout Report

At the end of the project a closeout report will be produced discussing any personnel, contract,

administrative and financial issues. Also ensuring all documents are archived and lessons learned

are captured.

12.2 Administrative Closure

i. Were the objectives of the project met?

A comparison of the Systems Specification Requirements and the final product will be done by

the team and the sponsor. Any accomplished and unaccomplished requirements will be

documented and reflected upon by the team.

ii. Archiving Project Artifacts

All major documents will be hosted on Google drive for easy access by team members. Some of

the documents saved will include:

Systems Specification Requirement

Project Charter

Receipts of all purchases made.

Change Requests

Architecture Design Specification

Detailed Design Document

MS Project Plan

System Test Plan

Financial Record

Team Status Reports/Presentations

12.2.3 Lessons Learned

At project completion, a lesson learned session will be organized where an analysis of the project

from the beginning to end will be done with each member reflecting on the whole process and

identifying classic mistakes or what could have been done differently to achieve a better result.


iii. Plans for Post Implementation Review (PIR)

On project completion, a review will be done with the sponsor based on the Acceptance criteria

in the System Specification Requirement. The PIR will be included in the closeout report.

iv. Final Customer Acceptance

On project completion, a meeting will be held with the sponsor (UTA Baseball Coach) where he

will provide feedback on the product and discuss any future requirements.

v. Financial Records

All receipts will be stored on Google drive and reviewed by the team and Project manager and

supervisor.

vi. Final Project Performance Report

On project completion, a summary of the project’s scope management, schedule performance,

cost performance and risk containment performance will provided and included in the closeout

report. Also, schedule and cost variances will be discussed by the team.

Department of Computer Science and Engineering The...

Documents

Transcript of Department of Computer Science and Engineering The...