Team 4Loop. Project: Smart Fitness Trainer. Department of Computer Science and Engineering University of Texas at Arlington

Transcription

1 Project Charter Project Name: Smart Fitness Trainer Department of Computer Science and Engineering University of Texas at Arlington Project Charter Team 4Loop Project: Smart Fitness Trainer Late Updated: 2 May 10:09:00 PM Team Members: Thanuja Fernando Andrew Gallagher Thomas Heinen Mark Ragunton

2 Project Charter Project Name: Smart Fitness Trainer Table of Contents 1 General Organization Project Manager Project Oversight Roles and Responsibilities Project Constraints Project Assumptions Preliminary Schedule and Cost Estimates Scope Statement Introduction Production Definition Intended Audience Cost Management Plan Introduction Cost Management Approach Project Budget Earned Value Management Purpose Earned Value Definitions and Calculations Earned Value Analysis Scope Management Plan Introduction Scope Management Approach Scope Control Scope Acceptance Work Breakdown Structure Description of Work Breakdown Structure MS Project Work Breakdown Structure Quality Management Plan Overview Documentation Design Software Hardware May 10:09:00 PM i Table of Contents

3 Project Charter Project Name: Smart Fitness Trainer 8 Communications Plan Overview Internal Communication External Communication Change Management Plan Purpose Roles and Responsibilities Review and Approval Process Change Identification, Documentation, Implementation and Reporting Risk Management Plan Purpose of Risk Management Plan Roles and Responsibilities Risk Identification Risk Triggers Risk Analysis Risk Severity Risk Response Planning Risk Documentation and Reporting Risk Control Procurement Management Plan Purpose of the Procurement Management Plan Roles and Responsibilities Required Project Procurements and Timing Description of Items/ Services to be acquired Project Closeout Report Purpose of Closeout Report Administrative Closure May 10:09:00 PM ii Table of Contents

4 1 General Organization 1.1 Project Manager Thomas Heinen is the Project Manager of Team 4Loop for the Smart Fitness Trainer project. He was selected based on his prior management experience in non-software fields, and desire to implement these skills in a software field. Thomas will act as a supervisor during this project by organizing and setting agendas for team meetings, delegating tasks to members based on their skills, setting internal deadlines, and overseeing the final submission of all deliverables. Thomas is a senior Software Engineering student, and his skills involve software development methodologies, software design, team management, and team communication. Thomas Heinen can be reached at theinen1@gmail.com 1.2 Project Oversight Team 4Loop has organized a set of procedures to follow in order for us to maintain control over the day-to-day activities of our project. Both internal and external oversights have been taken into account in our setup. Not only will we focus on project-level milestones and objectives, but also on very specific task-level objectives External Oversight Our external oversights mainly involve our Project Supervisor, Mr. O'Dell, and our Project Sponsor, Jeremy Roden. Mr. O'Dell will be involved in several of these external oversights including: Individual Status Reports Team Status Reports Gate Reviews The individual status reports will be used by Mr. O'Dell to track our individual contributions to the project and track our individual earned value. They will focus mostly on task-level objectives, as the reports are broken down by task. Team status reports will focus on our overall team progress on major deliverables and total earned value as a team. These reports will focus more on the project-level milestones and objectives as they will provide a better overall report on our project. Gate Reviews will also look at project-level milestones as they will be evaluating a phase of the development process and determining whether or not we can proceed. Jeremy Roden will also serve as external oversight to our team through our sponsor meetings. We will meet with Mr. Roden every 2-3 weeks to update him on our progress, and discuss problems we have encountered as well as potential solutions. His feedback is invaluable to our 2 May 10:09:00 PM 1 General Organization

5 team as he has a huge amount of experience in the personal training field. Meetings with Mr. Roden will include a mix of overall project oversight as well as task-level oversight depending on our work in the weeks leading up to the meeting Internal Oversights Both the team as a whole and the Project Manager will be responsible for the internal oversight of the project. The Project Manager will set up team meetings and control the agenda of those meetings to ensure the team is on track to meet deadlines. The entire team will also share responsibility in a few ways in regards to internal oversight. The MS Project Plan is monitored and updated primarily by Thanuja Fernando, but all team members will be responsible for tracking their time spent on tasks. The hours spent working on tasks will be updated at every team meeting. Team meetings are another form of internal control on this project. Team 4Loop will have meetings every Monday and Wednesday at 11am in the Senior Design lab. At these meetings we will discuss project ideas, give status updates on individual assignments, and talk about problems encountered and possible solutions. 1.3 Roles and Responsibilities Team 4Loop has assigned major roles and responsibilities of the project to different members to give each member a fair amount of involvement in our project. The division of these responsibilities will help the team stay organized and complete the project in a timely manner. These roles, individuals, and stakeholders are listed below: Team Members - Thanuja Fernando - Andrew Gallagher - Thomas Heinen - Mark Ragunton Project Sponsor - Jeremy Roden Project Supervisor - Mike O'Dell Role Responsibilities Assigned To Project Sponsor Provide guidance based on real life experience Assist in choosing exercises in include in final product Jeremy Roden 2 May 10:09:00 PM 2 General Organization

6 Project Supervisor Give feedback on team presentations and deliverables Project Manager Coordinate team meetings and set agenda Delegate of tasks to group members Scheduling Manager Maintain MS Project File Calculate Earned Value on tasks Head Researchers Research domain specific technologies Provide group with additional information on project related areas Software Lead Monitor software design and development process Assist developers with software development Developers Design and develop software to meet requirements Risk Manager Develop risk management plan Re-assess risks on weekly basis Document Reviewer Review documents prior to submission Responsible for submission of deliverables Quality Assurance Ensure high quality through testing of product Mike O'Dell Thomas Heinen Thanuja Fernando Andrew Gallagher Mark Ragunton Thomas Heinen Thanuja Fernando Andrew Gallagher Mark Ragunton Andrew Gallagher Thomas Heinen All team members 2 May 10:09:00 PM 2 General Organization

7 1.4 Project Constraints The Smart Fitness Trainer project has several constraints, including the time, budget, resources, and team size. These constraints are as follows: The Smart Fitness trainer is being developed through the Spring and Summer semesters, and must be completed by the end of the Summer semester (August 2013). Our sponsor will not provide additional financial assistance to our project, which means project has a final budget of $ The schedules of the team members vary considerably. All members are full-time students, and some have other non-school responsibilities such as work and family as well. Team size is limited to four members. Our team is also limited to using software which we own personally or can obtain from the Microsoft Dreamspark site. 1.5 Project Assumptions Assumptions for the Smart Fitness Trainer project include the following: Team 4Loop will be given a budget of $ Deliverables must be submitted by due dates posted by project supervisor Team 4Loop will meet twice a week Both our Dropbox and Assembla server will be operational at all times during the project Team 4Loop will not be responsible for providing maintenance to the Smart Fitness Trainer after August Team 4Loop will receive ordered hardware components on time 1.6 Preliminary Schedule and Cost Estimates Project Milestone Due Date SRS First Draft 3/18/2013 Project Charter First Draft 3/25/2013 Project Plan First Draft 3/25/2013 Requirements Gate Review 4/01/2013 Architecture Design Specification First Draft 5/01/2013 Baseline Project Charter 5/03/2013 Baseline Project Plan 5/03/2013 System Architecture Gate Review 6/11/2013 Detailed Design Review 6/28/2013 Final System Test Plan 7/23/ May 10:09:00 PM 3 General Organization

8 Early Prototype Review 7/25/2013 Final Presentations 8/9/2013 Phase 1 Task Preliminary Cost (hours) System Requirements Specification 85 Project Charter 76 Project Plan 28 Architecture Design Specification (Draft) 111 Phase 2 Task Preliminary Cost (hours) Architecture Design Specification (Baseline) 111 Detailed Design Specification 127 System Test Plan 166 Implementation May 10:09:00 PM 4 General Organization

9 2 Scope Statement 2.1 Introduction The goal of this project will be to develop a home workout system that will automatically generate user workouts for an individual based on an initial assessment of their fitness and medical history, as well as provide the user with workout statistics that can be used to track the progress for an individual. By breaking down the overall project into several milestones, the development team will be better equipped to track the overall progression of the project and stay productive and avoid delays. 2.2 Production Definition The Smart Fitness Trainer system is composed of pieces of hardware that allow an individual to engage in workout-related activities at home through the use of RGB-D cameras to recognize and analyze user movement. The system will be controlled and executed from a component built of several PC components such as a CPU, graphics processor, RAM, etc. and will be attached to the RGB-D to process and store all video data. The system will process the data which in turn will be used to generate a custom workout for an individual. 2.3 Intended Audience The intended audience for the Smart Fitness Trainer system will be the average individual with any amount of workout experience. The use of this system will be focused on people who are capable of performing simple workout tasks such as pushups, planks, etc. A warning and precaution notification will be displayed to all individuals within the system noting of potential health risks. 2 May 10:09:00 PM 5 Scope Statement

10 3 Cost Management Plan 3.1 Introduction Much of the performance in all product-related activities is measured by earned value which will be tracked in our Microsoft Project Plan. The development team as a whole will be responsible for managing all cost deviations as well as assessing all budget constraints that are set to occur within the project. During team meetings, members will both present and review the current cost performances in order to scale the project within the budget. 3.2 Cost Management Approach In order to manage all costs for this project, we will be using a Work Breakdown Structure in our Microsoft Project file. Our project manager, Thomas Heinen, will be responsible for keeping track of all earned value. 3.3 Project Budget The development team currently has a maximum budget of $800. The following section will break down the total costs of our system within the given budget. The main component of our system will be the RGB-D camera. With a student discount available at the Microsoft store, we are able to obtain the RGB-D camera for a lower cost. This lowered cost will range between $145 and $155. The camera will allow us to be flexible with our budget since the camera itself houses an onboard microphone. Since the camera contains a built-in microphone, we will not have to account for the microphone costs. The second main component of our system will be the mini computer. Many PC components will be bundled together in order to create a working PC unit to store and process the data for the Smart Fitness Trainer. We will spend $75 on a solid-state drive which will serve as the storage area for both our data and the executable program. A total amount of $165 will spent on the graphics processing unit (GPU) as well as the onboard memory. Since our system will be undergoing a rigorous processing load of video data, a larger percentage of our budget is accommodated towards the GPU and system memory. Other basic PC components will also be 2 May 10:09:00 PM 6 Cost Management Plan

11 budgeted such as a power supply for an estimated $45, a motherboard to integrate all the PC components for $70, an exterior case to shell the parts for $70, and lastly a CPU for $125. The last component to be accounted for is the heart-rate monitor. The heart rate monitor will be a third-party component that will be able to detect an individual's heart rate. We have estimated the cost of this component to be approximately $80. 2 May 10:09:00 PM 7 Cost Management Plan

12 4 Earned Value Management 4.1 Purpose Earned Value will serve as a consistent way to measure the productivity of both the individuals of our team, and the team as a whole. We will track earned value, as well as other performance metrics, and save them in our Microsoft Project Plan file to ensure we are staying on track with our project development. These values will be updated at the beginning of each team meeting based on the work our team has performed. 4.2 Earned Value Definitions and Calculations The performance metrics and definitions of each that our team will use are as follows: BCWP - Budgeted Cost of Work Performed BCWS - Budgeted Cost of Work Scheduled ACWP - Actual Cost of Work Performed CPI - Cost Performance Index = BCWP / ACWP SPI - Schedule Performance = BCWP / BCWS These values will be calculated and recorded by our team in order to consistently provide ourselves and our Project Supervisor with feedback of our team's productivity and performance. 4.3 Earned Value Analysis In order to gather meaningful feedback, we must keep track of BCWP, BCWS, and ACWP, which we will use to calculate the CPI and SPI. The CPI will not track our monetary budget, but rather our time budget, so we will use it to see if we are spending too much time on things, or finishing quicker than we though. The SPI will track our schedule and will tell us if we completed more tasks than originally scheduled, or if we have not met some deadlines. A CPI value greater than 1.0 will tell us that we are spending less time than we initially thought on the tasks we have completed, meaning that we are under budget. If the CPI is less than 1.0, then we can conclude that we are over budget, or spending more time on tasks than we had initially planned. If the SPI value is greater than 1.0, it means that we are ahead of schedule, and have finished tasks before their due date. If the value of the SPI drops below 1.0, then we know that we are running late on some of deliverables. 2 May 10:09:00 PM 8 Earned Value Management

13 When we obtain these values, we can analyze the cause for a CPI or SPI that is too high or too low, and adjust our work based on the values. If both values drop below 1.0, then we can see what problems we are having, re-assess risks and risk factors, and devise a new plan to get us back on schedule or cost. These emerging risks and risk factors will be documented in our risk management plan to ensure that we will not repeat them later. Though we can gather a lot of information from the CPI and SPI, we will make sure that the team realizes that it is simply a snapshot of that exact moment in time, and that a low CPI or SPI does not mean that we are as behind as it may seem. If major deliverables are approaching, the team may be almost finished with several items, causing our CPI or SPI to appear low. These numbers can experience a sudden quick jump when several things that are close to being finished are completed in rapid succession. We will make sure to assess the overall status of our project before we make judgments based on a very low or very high CPI or SPI value. 2 May 10:09:00 PM 9 Earned Value Management

14 5 Scope Management Plan 5.1 Introduction The scope management plan will be used to provide an overall scope for the project. This area will focus on the scope management approach, several definitions of scope control, and scope acceptance. 5.2 Scope Management Approach For this project, the responsibility of scope management will belong to the project manager. All scope will be defined in scope management and the Work Breakdown Structure that is to be found within the Microsoft Project file. All scope must be approved by both the project manager and project sponsor through the System Requirements Specification. If any changes are requested, a change request form must be submitted to the project manager who will assess the request Scope Definition The general analysis for our project is based on existing technologies as well as feedback from the project sponsor. In order for scope to be successfully established, all requirements documentations, the work breakdown structure, and a management plan must have been completed Minimizing Feature Approach An emphasis will be placed on minimizing features to prevent any wasted effort, disorder in control, and constraints. Balance must be maintained in quality features and critical functional requirements to deliver all results correctly. 5.3 Scope Control In order to control the scope for the project, the project manager and all team members will work together cohesively. Microsoft Project will be used to model all planned work in the Work Breakdown Structure. Members of the development team will only follow their corresponding items within the project schedule and outline found inside the project file and must report all tasks to the project manager. 2 May 10:09:00 PM 10 Scope Management Plan

15 5.4 Scope Acceptance All changes within the project should be discussed at all team meetings with all members of the team present. To implement the changes, the project manager will assess the changes and coordinate them with the project sponsor. When both the sponsor and project manager have approved the changes, the System Requirements Specification shall be updated along with the Microsoft Project file. In the event of a scope not being approved by any deciding factor, the item will be referenced in future updates. 2 May 10:09:00 PM 11 Scope Management Plan

16 6 Work Breakdown Structure 6.1 Description of Work Breakdown Structure The Work Breakdown Structure (WBS) for the Smart Fitness Trainer project has been created and maintained by using Microsoft Project. The entire project is broken down into two phases: Senior Design I (phase 1) and Senior Design II (phase 2). Phase I is broken into eight sections; the System Requirement Specification, Project Charter, Architecture Design Specification, Project Research, MS Project Plan, Team Meetings, Team Presentations Preparation, and Sponsor Meetings. Phase II is also broken into eight sections; Detailed Design Specification, Test Plan, Prototype, Project Wrap up, MS Project Plan, Team Meetings, Team Presentations Preparation, and Sponsor Meetings. These main sections are broken down into many subsections to the smallest level of work to be done. Each task will be assigned to individual team members (or a subset of team members) for completion. The individual team member will track their hours in their engineering notebook and will be entered in Microsoft Project at time of completion during team meetings. 6.2 MS Project Work Breakdown Structure WBS Task Name Start Finish Planned to Work 1 Phase 1 (Senior Design 1) Fri 1/25/13 Mon 5/6/ hrs 1.1 System Requirement Specification Mon 2/18/13 Wed 4/10/13 73 hrs Rough Draft Mon 2/18/13 Sun 3/17/13 51 hrs Product Concept (Section 1) Mon 2/18/13 Thu 3/14/ hrs Purpose and Use (Section 1.1) Mon 2/18/13 Wed 3/6/ hrs Intended Audience (Section 1.2) Mon 2/18/13 Thu 3/14/ hrs Product Description and Functional Overview (Section 2) Wed 2/27/13 Wed 3/6/13 3 hrs Features and Functions (Section 2.1) Wed 2/27/13 Wed 3/6/13 1 hr External Inputs and Outputs (Section 2.2) Wed 2/27/13 Wed 3/6/13 1 hr Product Interfaces (2.3) Wed 2/27/13 Wed 3/6/13 1 hr Customer Requirements (Section 3) Mon 2/25/13 Fri 3/8/13 6 hrs Packaging Requirements (Section 4) Wed 2/27/13 Fri 3/15/13 2 hrs Performance Requirements (Section 5) Wed 2/27/13 Wed 3/6/13 6 hrs Safety Requirements (Section 6) Mon 2/18/13 Fri 3/8/13 4 hrs Other Requirements (Section 7) Mon 2/25/13 Fri 3/8/13 3 hrs Maintenance and Support Requirements (Section 8) Mon 2/18/13 Tue 3/12/13 3 hrs Testing (Section 8.1) Mon 2/18/13 Tue 3/12/ hrs Code Documentation (Section 8.2) Mon 2/18/13 Mon 3/11/ hrs Acceptance Criteria (Section 9) Mon 2/18/13 Thu 3/14/13 3 hrs Use Cases (Section 10) Mon 3/4/13 Fri 3/15/13 3 hrs Feasibility Assessment (Section 11) Mon 2/18/13 Thu 3/14/ hrs Scope Analysis (Section 11.1) Wed 2/27/13 Mon 3/11/ hrs Research (Section 11.2) Tue 3/12/13 Thu 3/14/13 1 hr Technical Analysis (Section 11.3) Wed 2/27/13 Mon 3/11/13 1 hr 2 May 10:09:00 PM 12 Work Breakdown Structure

17 Cost Analysis (Section 11.4) Fri 3/1/13 Mon 3/4/13 2 hrs Resource Analysis (Section 11.5) Wed 2/27/13 Mon 3/11/13 1 hr Schedule Analysis (Section 11.6) Mon 2/18/13 Mon 2/25/13 3 hrs Future Items (Section 12) Mon 2/25/13 Fri 3/8/13 1 hr Revisions Thu 3/14/13 Sun 3/17/13 8 hrs Final Draft Mon 3/25/13 Mon 4/8/13 13 hrs Revisions Mon 3/25/13 Fri 3/29/13 13 hrs Product Concept (Section 1) Mon 3/25/13 Fri 3/29/13 1 hr Product Description and Functional Overview (Section 2) Mon 3/25/13 Fri 3/29/13 3 hrs Customer Requirements (Section 3) Mon 3/25/13 Fri 3/29/13 3 hrs Packaging Requirements (Section 4) Mon 3/25/13 Fri 3/29/13 0 hrs Performance Requirements (Section 5) Mon 3/25/13 Fri 3/29/13 0 hrs Safety Requirements (Section 6) Mon 3/25/13 Fri 3/29/13 0 hrs Other Requirements (Section 7) Mon 3/25/13 Fri 3/29/13 0 hrs Maintenance and Support Requirements (Section 8) Mon 3/25/13 Fri 3/29/13 3 hrs Acceptance Criteria (Section 9) Mon 3/25/13 Fri 3/29/13 0 hrs Use Cases (Section 10) Mon 3/25/13 Fri 3/29/13 0 hrs Feasibility Assessment (Section 11) Mon 3/25/13 Fri 3/29/13 3 hrs Future Items (Section 12) Mon 3/25/13 Fri 3/29/13 0 hrs Baseline SRS Wed 4/3/13 Wed 4/10/13 9 hrs Revisions Wed 4/3/13 Wed 4/10/13 9 hrs Section Define Progression Mode or change Wed 4/3/13 Wed 4/10/ hrs Section Explain why Kinect is correct choice Wed 4/3/13 Wed 4/10/ hrs Section 3 - Longer Descriptions Wed 4/3/13 Wed 4/10/13 2 hrs Section 4 - Specify interfaces Wed 4/3/13 Wed 4/10/13 1 hr Section 7 - Fix Wed 4/3/13 Wed 4/10/13 1 hr Section 11 - State overall assessment Wed 4/3/13 Wed 4/10/ hrs Replace Kinect with RGB-D camera Wed 4/3/13 Wed 4/10/ hrs Grammar/Spelling Wed 4/3/13 Wed 4/10/13 2 hrs User Interface pictures Wed 4/3/13 Wed 4/10/13 1 hr 1.2 Project Charter Mon 3/18/13 Fri 5/3/13 60 hrs First Draft Mon 3/18/13 Mon 3/25/13 46 hrs General Organization Mon 3/18/13 Wed 3/20/ hrs Scope Statement Mon 3/18/13 Wed 3/20/13 3 hrs Cost Management Plan Mon 3/18/13 Wed 3/20/13 3 hrs Earned Value Management Mon 3/18/13 Fri 3/22/13 3 hrs Scope Management Plan Mon 3/18/13 Wed 3/20/13 3 hrs Work Breakdown Structure Mon 3/18/13 Fri 3/22/13 3 hrs Quality Management Plan Mon 3/18/13 Fri 3/22/13 3 hrs Communication Plan Mon 3/18/13 Fri 3/22/13 3 hrs Change Management Plan Mon 3/18/13 Fri 3/22/13 3 hrs Risk Management Mon 3/18/13 Thu 3/21/13 9 hrs Purpose of Risk Management Plan Mon 3/18/13 Mon 3/18/ hrs Roles and Responsibilities Mon 3/18/13 Mon 3/18/ hrs Risk Identification Mon 3/18/13 Mon 3/18/13 1 hr Risk Triggers Mon 3/18/13 Mon 3/18/13 1 hr Risk Analysis Mon 3/18/13 Mon 3/18/13 2 hrs Risk Severity Mon 3/18/13 Mon 3/18/13 1 hr Risk Response Planning Mon 3/18/13 Mon 3/18/13 1 hr Risk Documentation and Reporting Mon 3/18/13 Mon 3/18/13 1 hr Risk Control Mon 3/18/13 Mon 3/18/13 1 hr Procurement Management Plan Mon 3/18/13 Fri 3/22/ hrs Purpose of the Procurement Management Plan Mon 3/18/13 Mon 3/18/ hrs Roles and Responsibilities Mon 3/18/13 Mon 3/18/13 1 hr Required Project Procurement and Timing Mon 3/18/13 Mon 3/18/13 1 hr 2 May 10:09:00 PM 13 Work Breakdown Structure

18 Description of Items/Services to be acquired Mon 3/18/13 Mon 3/18/13 1 hr Project Closeout Report Mon 3/18/13 Fri 3/22/13 1 hr Purpose of Closeout Report Mon 3/18/13 Mon 3/18/ hrs Administrative Closure Mon 3/18/13 Mon 3/18/ hrs Revisions Fri 3/22/13 Sat 3/23/13 4 hrs Baseline Draft Tue 3/26/13 Fri 5/3/13 14 hrs General Organization Tue 3/26/13 Fri 5/3/ hrs Project Management Tue 3/26/13 Fri 5/3/ hrs Project Oversight Tue 3/26/13 Fri 5/3/ hrs Roles and Responsibilities Tue 3/26/13 Fri 5/3/ hrs Project Constraints Tue 3/26/13 Fri 5/3/ hrs Project Assumptions Tue 3/26/13 Fri 5/3/ hrs Preliminary Schedules and Cost Estimates Tue 3/26/13 Fri 5/3/13 1 hr Scope Statement Tue 3/26/13 Fri 5/3/13 1 hr Cost Management Plan Tue 3/26/13 Fri 5/3/13 1 hr Earned Value Management Tue 3/26/13 Fri 5/3/13 1 hr Scope Management Plan Tue 3/26/13 Fri 5/3/13 1 hr Work Breakdown Structure Tue 3/26/13 Fri 5/3/13 1 hr Quality Management Plan Tue 3/26/13 Fri 5/3/13 1 hr Communication Plan Tue 3/26/13 Fri 5/3/13 1 hr Change Management Plan Tue 3/26/13 Fri 5/3/13 1 hr Risk Management Tue 3/26/13 Fri 5/3/ hrs Purpose of Risk Management Plan Tue 3/26/13 Fri 5/3/ hrs Roles and Responsibilities Tue 3/26/13 Fri 5/3/ hrs Risk Identification Tue 3/26/13 Fri 5/3/ hrs Risk Triggers Tue 3/26/13 Fri 5/3/ hrs Risk Analysis Tue 3/26/13 Fri 5/3/ hrs Risk Severity Tue 3/26/13 Fri 5/3/ hrs Risk Response Planning Tue 3/26/13 Fri 5/3/ hrs Risk Documentation and Reporting Tue 3/26/13 Fri 5/3/ hrs Risk Control Tue 3/26/13 Fri 5/3/ hrs Procurement Management Plan Tue 3/26/13 Fri 5/3/13 1 hr Purpose of the Procurement Management Plan Tue 3/26/13 Fri 5/3/ hrs Roles and Responsibilities Tue 3/26/13 Fri 5/3/ hrs Required Project Procurement and Timing Tue 3/26/13 Fri 5/3/ hrs Description of Items/Services to be acquired Tue 3/26/13 Fri 5/3/ hrs Project Closeout Report Tue 3/26/13 Fri 5/3/ hrs Purpose of Closeout Report Tue 3/26/13 Fri 5/3/ hrs Administrative Closure Tue 3/26/13 Fri 5/3/ hrs 1.3 Architecture Design Specification Mon 4/1/13 Wed 5/1/ hrs Rough Draft Mon 4/1/13 Wed 5/1/ hrs Introduction (Section 1) Mon 4/1/13 Wed 5/1/13 1 hr Meta Architecture (Section 2) Mon 4/1/13 Wed 5/1/13 10 hrs Architecture Layers (Section 3) Mon 4/1/13 Wed 5/1/13 10 hrs Input Layer (Section 4) Mon 4/1/13 Wed 5/1/13 10 hrs Workout Processing Layer (Section 5) Mon 4/1/13 Wed 5/1/13 10 hrs Profile Processing Layer (Section 6) Mon 4/1/13 Wed 5/1/13 10 hrs Database Management Layer (Section 7) Mon 4/1/13 Wed 5/1/13 10 hrs Presentation Layer (Section 8) Mon 4/1/13 Wed 5/1/13 10 hrs Relationship Mapping (Section 9) Mon 4/1/13 Wed 5/1/13 10 hrs Requirement Mapping (Section 10) Mon 4/1/13 Wed 5/1/13 10 hrs Operating System Dependencies (Section 11) Mon 4/1/13 Wed 5/1/13 10 hrs Testing Considerations (Section 12) Mon 4/1/13 Wed 5/1/13 10 hrs 1.4 Project Research Fri 1/25/13 Fri 5/3/ hrs Meeting (Dr. Mariottini) Fri 1/25/13 Fri 1/25/ hrs Software Thu 2/14/13 Fri 5/3/13 30 hrs 2 May 10:09:00 PM 14 Work Breakdown Structure

19 1.4.3 Hardware Thu 2/14/13 Fri 5/3/13 20 hrs Medical Assessment Fri 1/25/13 Fri 1/25/13 1 hr 1.5 MS Project Plan Fri 1/25/13 Mon 5/6/13 28 hrs First Draft Fri 1/25/13 Fri 3/1/13 13 hrs Plan Phase 1 Fri 1/25/13 Mon 2/18/13 3 hrs Update Phase 1 Tue 2/19/13 Tue 2/19/13 2 hrs Update Phase 2 Thu 2/21/13 Mon 2/25/13 5 hrs Final Draft Edit Tue 2/26/13 Fri 3/1/13 3 hrs Baseline Thu 4/4/13 Fri 5/3/13 15 hrs 1.6 Team Meetings Mon 2/18/13 Mon 5/6/ hrs Meeting 1 Mon 2/18/13 Mon 2/18/13 1 hr Meeting 2 Wed 2/20/13 Wed 2/20/13 1 hr Meeting 3 Mon 2/25/13 Mon 2/25/13 1 hr Meeting 4 Wed 2/27/13 Wed 2/27/ hrs Meeting 5 Mon 3/4/13 Mon 3/4/13 1 hr Meeting 6 Wed 3/6/13 Wed 3/6/13 1 hr Meeting 7 Thu 3/14/13 Thu 3/14/ hrs Meeting 8 Mon 3/18/13 Mon 3/18/13 1 hr Meeting 9 Wed 3/20/13 Wed 3/20/13 1 hr Meeting 10 Mon 3/25/13 Mon 3/25/ hrs Meeting 11 Wed 3/27/13 Wed 3/27/13 1 hr Meeting 12 Mon 4/1/13 Mon 4/1/13 1 hr Meeting 13 Wed 4/3/13 Wed 4/3/ hrs Meeting 14 Mon 4/8/13 Mon 4/8/ hrs Meeting 15 Wed 4/10/13 Wed 4/10/ hrs Meeting 16 Mon 4/15/13 Mon 4/15/ hrs Meeting 17 Wed 4/17/13 Wed 4/17/13 3 hrs Meeting 18 Mon 4/22/13 Mon 4/22/ hrs Meeting 19 Wed 4/24/13 Wed 4/24/13 1 hr Meeting 20 Mon 4/29/13 Mon 4/29/13 1 hr Meeting 21 Wed 5/1/13 Wed 5/1/13 1 hr 1.7 Team Presentations Preparation Thu 1/31/13 Thu 4/18/13 10 hrs Team Status Report 1 Thu 1/31/13 Thu 1/31/ hrs Team Status Report 2 Thu 2/14/13 Thu 2/14/13 1 hr Team Status Report 3 Thu 2/28/13 Thu 2/28/ hrs Team Status Report 4 Thu 3/21/13 Thu 3/21/13 2 hrs Team Status Report 5 Thu 4/4/13 Thu 4/4/13 2 hrs Team Status Report 6 Thu 4/18/13 Thu 4/18/13 2 hrs 1.8 Sponsor Meeting Wed 2/6/13 Thu 3/28/13 2 hrs Meeting 1 Wed 2/6/13 Wed 2/6/13 1 hr Meeting 2 Thu 3/28/13 Thu 3/28/13 1 hr 1.9 Peer Review Fri 3/29/13 Fri 3/29/13 1 hr Review SRS (Galaxy Team) Fri 3/29/13 Fri 3/29/13 1 hr 2 Phase II (Senior Design 2) Tue 6/4/13 Fri 8/9/ hrs 2.1 Architecture Design Specification Tue 6/4/13 Mon 6/10/ hrs Baseline Tue 6/4/13 Mon 6/10/ hrs Introduction (Section 1) Tue 6/4/13 Mon 6/10/13 1 hr Meta Architecture (Section 2) Tue 6/4/13 Mon 6/10/13 10 hrs Architecture Layers (Section 3) Tue 6/4/13 Mon 6/10/13 10 hrs Input Layer (Section 4) Tue 6/4/13 Mon 6/10/13 10 hrs Workout Processing Layer (Section 5) Tue 6/4/13 Mon 6/10/13 10 hrs Profile Processing Layer (Section 6) Tue 6/4/13 Mon 6/10/13 10 hrs Database Management Layer (Section 7) Tue 6/4/13 Mon 6/10/13 10 hrs Presentation Layer (Section 8) Tue 6/4/13 Mon 6/10/13 10 hrs Relationship Mapping (Section 9) Tue 6/4/13 Mon 6/10/13 10 hrs Requirement Mapping (Section 10) Tue 6/4/13 Mon 6/10/13 10 hrs 2 May 10:09:00 PM 15 Work Breakdown Structure

20 Operating System Dependencies (Section 11) Tue 6/4/13 Mon 6/10/13 10 hrs Testing Considerations (Section 12) Tue 6/4/13 Mon 6/10/13 10 hrs 2.2 Detailed Design Specification (DDS) Tue 6/11/13 Wed 6/26/ hrs Introduction Tue 6/11/13 Wed 6/26/13 1 hr Architecture Overview Tue 6/11/13 Wed 6/26/13 15 hrs Component Design Tue 6/11/13 Wed 6/26/13 50 hrs Quality Assurance Tue 6/11/13 Wed 6/26/13 20 hrs Test Plans and Procedures Tue 6/11/13 Wed 6/26/13 10 hrs Test Cases Tue 6/11/13 Wed 6/26/13 10 hrs Requirements Traceability Matrix Tue 6/11/13 Wed 6/26/13 10 hrs Acceptance Plan Tue 6/11/13 Wed 6/26/13 30 hrs Packaging and Installation Tue 6/11/13 Wed 6/26/13 10 hrs Acceptance Testing Tue 6/11/13 Wed 6/26/13 10 hrs Acceptance Criteria Tue 6/11/13 Wed 6/26/13 10 hrs Appendices Tue 6/11/13 Wed 6/26/13 1 hr 2.3 Test Plan Thu 6/27/13 Thu 7/11/ hrs Test Plan Identifier (Section 1) Thu 6/27/13 Thu 7/11/13 5 hrs References (Section 2) Thu 6/27/13 Thu 7/11/13 5 hrs Introduction (Section 3) Thu 6/27/13 Thu 7/11/13 5 hrs Test Items (Section 4) Thu 6/27/13 Thu 7/11/13 10 hrs Software Risk Issues (Section 5) Thu 6/27/13 Thu 7/11/13 10 hrs Features to be Tested (Section 6) Thu 6/27/13 Thu 7/11/13 10 hrs Features not to be tested (Section 7) Thu 6/27/13 Thu 7/11/13 10 hrs Approach (Section 8) Thu 6/27/13 Thu 7/11/13 10 hrs Item Pass/Fail Criteria (Section 9) Thu 6/27/13 Thu 7/11/13 10 hrs Suspension Criteria and Resumption Requirements (Section 10) Thu 6/27/13 Thu 7/11/13 10 hrs Test Deliverables (Section 11) Thu 6/27/13 Thu 7/11/13 10 hrs Remaining Test Tasks (Section 12) Thu 6/27/13 Thu 7/11/13 10 hrs Environmental Needs (Section 13) Thu 6/27/13 Thu 7/11/13 10 hrs Staffing and Training Needs (Section 14) Thu 6/27/13 Thu 7/11/13 10 hrs Responsibilities (Section 15) Thu 6/27/13 Thu 7/11/13 10 hrs Schedule (Section 16) Thu 6/27/13 Thu 7/11/13 10 hrs Planning Risks and Contingencies (Section 17) Thu 6/27/13 Thu 7/11/13 10 hrs Approvals (Section 18) Thu 6/27/13 Thu 7/11/13 10 hrs Glossary (Section 19) Thu 6/27/13 Thu 7/11/13 1 hr 2.4 Design and Prototype Fri 7/12/13 Wed 7/24/ hrs 2.5 Project Wrap-up Requirements Wed 7/24/13 Tue 7/30/13 10 hrs 2.6 Project Research Tue 6/4/13 Fri 8/9/ hrs 2.7 MS Project Plan Tue 6/4/13 Fri 8/9/13 30 hrs 2.8 Team Meetings Tue 6/4/13 Fri 8/9/13 22 hrs 2.9 Team Presentations Preparation Tue 6/4/13 Fri 8/9/13 20 hrs 2.10 Sponsor Meetings Tue 6/4/13 Fri 8/9/13 8 hrs 2 May 10:09:00 PM 16 Work Breakdown Structure

21 7 Quality Management Plan 7.1 Overview The quality management plan will be used to ensure that the Smart Fitness Trainer system shall meet all of the customer requirements, and that a high quality product will be produced. This plan outlines different quality management techniques that will be used. The following quality management plan will be implemented by the 4Loop team. 7.2 Documentation All of the documents are divided into sections and assigned todifferent members of the 4Loop team. Each team member is responsible for completing their individual sections by the assigned due date. Any team member may request help from other team members on any assigned sections if needed. Before final submission, these sections are combined, and there is a team read-through of the entire document. This lets every team member approve each section of the document. This also assures correct and concise terminology and formatting throughout the final document. 7.3 Design Team 4Loop shall use the hybrid waterfall method provided by Mr. O Dell to design the Smart Fitness Trainer system. Two design documents, the Architectural Design Specification document and the Detailed Design Specification document, will be submitted with the Smart Fitness Trainer system. These documents shall allow the team to ensure all requirements in the System Requirements Specification document are encountered. This will also allow for a modular design and help meet the maintenance requirements of the Smart Fitness Trainer system. 2 May 10:09:00 PM 17 Quality Management Plan

22 7.4 Software The software for the Smart Fitness Trainer system shall be designed, documented, and tested to the highest competence of the 4Loop team. The code shall be written in a modular manner which will allow for easy testing. Also the code shall be written with readability in mind. All code will be stored within a subversion repository to keep track of all changes to the code. 7.5 Hardware Hardware for the Smart Fitness Trainer system shall be purchased based on need, quality, power, and cost. This is to ensure that the Smart Fitness Trainer system is a highly responsive and durable product. All required hardware must be thoroughly researched before purchase to ensure that they are compatible with each other. All hardware will be individually tested before being integrated into the system. Test cases shall be written and implemented to test the correct output of the system based on different input scenarios. 2 May 10:09:00 PM 18 Quality Management Plan

23 8 Communications Plan 8.1 Overview The communication plan will establish guidelines for internal and external communication. Internal communication is any communication within the team and external communication will be any communication with our sponsor. 8.2 Internal Communication Team Meetings Team meetings will be held twice a week. The duration of the meeting will vary depending on the content of the meeting. Attendance is mandatory. If a team member cannot attend a meeting they are required to inform the team leader by or phone/text. This is a time for team members to update the Project Plan with work done, share ideas or concerns they have had since the last meeting, review the work schedule and any major documents, and to keep everybody updated. After discussion, it will serve as a time for group work will be the secondary form of internal communication after team meetings. Team members should check their several times daily. will be used for less comprehensive communication. This will include things like afterthoughts of meetings, reminders and confirmations Dropbox Dropbox will be used to share documents in an informal way. This will mostly be used to compile the sections of a major document. Each team member will deposit their section in Dropbox and it will be subject to peer review from there. The person in charge of compiling major documents will be Thomas Heinen. He will gather the individual sections from the Dropbox folder Assembla Assembla will be used for source control. All major documents and source code will be submitted to Assembla. This will control the problem that could arise from different team members changing a shared document without the rest of the team s knowledge. Changes made by one team member can conflict with changes made by another. This can cause serious problems especially with source code. Assembla will make it easier to track changes to a file and 2 May 10:09:00 PM 19 Communications Plan

24 will keep track of conflicting copies of a document. It will also provide ways to show exactly how two conflicting copies of the same file differ. 8.3 External Communication will be the most frequently used form of communication with our sponsor, Jeremy Roden. Since our sponsor is very busy this will be the most convenient form of communication for him. The team leader, Thomas Heinen, will be the only one who should our sponsor Meetings Meetings with the sponsor will happen less frequently. We will our sponsor in advance to set an appointment. These will only be held to present major deliverables of the final product and receive feedback. 2 May 10:09:00 PM 20 Communications Plan

25 9 Change Management Plan 9.1 Purpose A change management plan is necessary when working on a big project. Changes can be constructive for the project,butcan also pose new risks that make the project infeasible and cause it to be a failure. Some changes are planned, and some are spur of the moment, so it is important to have a change management plan in place to ensure that the team does not make any hasty decisions regarding changes on the project. Having a detailed change management plan in place shall help Team 4Loop address these changes as they derive and transform those changes into benefits for the project. 9.2 Roles and Responsibilities Project Leader - Thomas Heinen Our project leader Thomas will consider the changes and determine if these changes are worth being implemented. He will bring these changes up with our sponsor or department head for discussion if needed. Project Team 4Loop Team 4Loop will decide whether the changes are beneficial or not based on a meticulous discussion about the change. We will address the change democratically to determine if these changes are necessary to project. Department Head - Mike O Dell Our department head Mr. Mike O Dell will give us assistance regarding changes to our project, and give his opinion on if changes are beneficial to our project or not based on his experience. Project Sponsor Jeremy Roden Mr. Roden will provide us with his advice and consultation regarding the project. He will give us input on if the changes are necessary for the success of our system. 9.3 Review and Approval Process When a change to the project is brought up by a team member or the sponsor, there will be a change request form filled out by the team member who thought of the change, or heard the change from the sponsor. After the form is filled out there will be a team meeting where we will 2 May 10:09:00 PM 21 Change Management Plan

26 discuss the change in full detail and determine if this change is a smart decision to make. If needed, we will consult our department head (Mr. O Dell) and our sponsor (Mr. Roden), for their opinion on this change to the project. Ultimately, the team will decide if the changes are necessary or not for the project. 9.4 Change Identification, Documentation, Implementation and Reporting Team 4Loop will have a simple change request form that will be available in our senior design cubicle. This form will be filled out by the person that who is proposing to the change and will begin the process of analyzing the change and determining if this change is worth to make. If a change is approved by the team, the appropriate documents will be corrected to reflect the change immediately by the team. Change Request Form Team member requesting change: Change number: Meeting Date: Priority: Description of the change: Team Member Signatures: Thomas Heinen Thanuja Fernando Andrew Gallagher Mark Ragunton Sponsor (if needed) 2 May 10:09:00 PM 22 Change Management Plan

27 10 Risk Management Plan 10.1 Purpose of Risk Management Plan Risks will be defined as the probability of events that put our project behind schedule and/or over-budget. The purpose of the risk management plan is to identify risks, analyze them and produce a plan to deal with them if they should occur Roles and Responsibilities Project Sponsor: Our sponsor is Jeremy Roden. He is the Assistant Director of University Wellness Program and is very knowledgeable about physical fitness. He will tell us what a personal trainer is observing and assessing when a personal trainer is working with a client. This will help us understand how feasible it will be to make a computer system perform the same type of observation and assessment. We can then make conclusions about the risk of not being able to complete the requirements. Project Team: As a team, we analyze and assess the requirements we have gathered from our sponsor and the ones we have come up with ourselves. We consider the limits of the technology involved, the capabilities of the individual team members and the time and budget we have been provided, then conclude the risk of not completing each requirement. Project Manager: The Project Manager is Thomas Heinen. He is responsible for communicating with the Project Sponsor about risks involved with the project and then relaying this communication to the rest of the team. Risk Manager: The Risk Manager is Andrew Gallagher. He is responsible for leading the Risk Management Plan and maintaining the risk database. This involves helping identify risks and then collecting all of them in the database, and analyzing them. He will decide which risks pose the most serious threats. He will then show the results to the rest of the team, and discuss potential plans to handle them if they should occur Risk Identification The Risk Manager is responsible for putting the most time into identifying risk. He will analyze all project documentation and use any resources he has, including his own knowledge and experience, to identify risk. Also, each team member will be responsible for keeping track of any risk that they think of at any time. It will be encouraged to write these risks in their engineering notebook. During each team meeting there will be a designated portion dedicated for discussing risk management. At this point each team member will present any risk they have thought of since the last meeting. Each risk brought up during a meeting will be considered by the team as a whole and if the risk is considered valid it will be entered into the risk database. 2 May 10:09:00 PM 23 Risk Management Plan

28 10.4 Risk Triggers The responsibility for keeping an eye out for possible risk triggers first goes to the Risk Manager. It is also each team member s responsibility to bring it to the rest of the team s attention if they recognize a risk trigger. Once a risk trigger is identified and brought to the attention of the team the Risk Manager should set in motion a plan to keep the potential risk from developing into a serious threat. Some risk triggers identified are: The team starts to miss internal deadlines, which starts pushing our schedule back. Team members start to lose interest in their work. Team members miss team meetings. Team members miss class. Integrating software and hardware components produces errors. Team members have communication issues with each other Risk Analysis The following table presents a list of risks the team has identified. Risk Group Risk Priority Probability (%) Cost (days) Schedule Schedule Technical Technical Team More time than scheduled learning OpenNI. More time than scheduled learning new programming language: C++, C#, Java. Processing speed is insufficient for real time video processing. Components are incompatible: hardware, Linux, OpenNI, Kinect. Team members become ill. 1-Critical 25% 7 1-Critical 10% 7 2-High 5% 10 1-Critical 15% 14 4-Low 30% 1 Schedule Shipping delays. 3-Moderate 15% 4 Budget Running out of money. 2-High 10% 3 Sponsor, Team Feature creep. 3-Moderate 5% 14 2 May 10:09:00 PM 24 Risk Management Plan

29 Technical Sponsor Heart rate monitor does not work. Cannot get in touch with sponsor. 2-High 10% 7 2-High 20% Risk Severity The following table presents the severity of each risk identified. Severity is defined by risk exposure which is calculated by multiplying the probability of the risk occurring by the cost in days. Schedule Schedule Technical Technical Risk Group Risk Risk Exposure More time than scheduled learning OpenNI. More time than scheduled learning new programming language: C++, C#, Java. Processing speed is insufficient for real time video processing. Components are incompatible: hardware, Linux, OpenNI, Kinect. Team Team members become ill..3 Schedule Shipping delays..6 Budget Running out of money..3 Sponsor, Team Feature creep..7 Technical Sponsor Heart rate monitor does not work. Cannot get in touch with sponsor May 10:09:00 PM 25 Risk Management Plan

30 10.7 Risk Response Planning The following table is the list of risks identified and the planned risk response method for each. Each response method will be one of these: research, watch, mitigate, accept, or transfer. Risk More time than scheduled learning OpenNI. More time than scheduled learning new programming language: C++, C#, Java. Processing speed is insufficient for real time video processing. Components are incompatible: hardware, Linux, OpenNI, Kinect. Team members become ill. Shipping delays. Running out of money. Feature creep. Heart rate monitor does not work. Cannot get in touch with sponsor. Risk Response Method Risk is likely to occur. Response will be to watch for team members who are having trouble using OpenNI. Someone will be assigned to bring that team member up to speed. Risk is not likely to occur. Most of the team has had experience with at least one of these programming languages. It is expected that each team member has the capability to learn a new programming language in a timely manner. We will accept this risk. Risk is not likely to occur. We will research ahead of time what kind of processor will be required. Risk is not likely to occur. We will research ahead of time if the components are compatible. Risk is likely to occur. We will accept this risk. If someone becomes ill we will adjust our work schedule appropriately. Risk is likely to occur. It is not uncommon for there to be shipping delays. We will mitigate this risk by ordering our parts early so that any shipping delays will not affect our schedule. Risk is not likely to occur. We will do sufficient research to make sure that the components we select to buy will not cost us more than our budget allows. Risk is not likely to occur. We have discussed with our sponsor lots of features we would like to have for our product. We put many of these features in the future requirements category. Our sponsor was able to define our product in a more concise set of requirements. We will still watch for any feature creep. Risk is likely to occur. We will do rigorous research to ensure that the heart rate monitor works. Risk is likely to occur. We have past experience getting our sponsor to reply to our s promptly. We will mitigate this risk by communicating in manner that allows a response to take two weeks and not put us behind schedule. 2 May 10:09:00 PM 26 Risk Management Plan