Project Charter Final

Senior Design Documentation Library
Project Charter
Department of Computer Science and Engineering

The University of Texas at Arlington
Team Virtual MD
iGait Application
Team Members:
Kevin Kocian
Abdul Hadi Khan
Mohammad Kothawala
Jesus Linares
Ross Walker
Last Update: 15 August 2015 @ 5:16:00 PM
Project Charter
Table of Contents
1
General Organization........................................................................................................1
1.1
1.2
1.3
1.4
1.5
1.6
Introduction
4
Product Definition
Intended Audience
4
4
Cost Management Plan......................................................................................................5

3.1
Scope Statement.................................................................................................................4
2.1
2.2
2.3
Project Manager
1
Project Oversight
1
Roles and Responsibilities
2
Project Constraints
2
Project Assumptions
3
Preliminary Schedule and Cost Estimates
Project Budget 5
Earned Value Management...............................................................................................6

4.1
4.2
Use Microsoft Project for scheduling tasks

Report will be made within Microsoft Project.
6
6
Scope Management Plan...................................................................................................7
Work Breakdown Structure..............................................................................................9
Quality Management Plan..............................................................................................15

7.1
7.2
7.3
7.4
Communications Plan......................................................................................................17
8.1
8.2
8.3
Introduction
17
Internal communication 17
External communication
18
Change Management Plan..............................................................................................19

9.1
9.2
9.3
9.4
10
Introduction
15
Documentation 15
Software
15
Testing 15
Purpose of Integrated Change Management Plan 19

20
Review and Approval Process 20
Change Identification, Documentation, Implementation and Reporting
21
Procurement Management Plan.....................................................................................22

10.1
Purpose of the Procurement Management Plan
15 August 2015 @ 5:16:00 PM
22
Table of Contents
10.2
10.3
10.4

22
Required Project Procurements and Timing
Description of Items/ Services to be acquired
15 August 2015 @ 5:16:00 PM
22
23
Table of Contents
1 General Organization
1.1
Project Manager
Kevin Kocian
1.1.1 Roles and Responsibilities:
Schedule Manager
Team Leader
Meeting Scribe
1.1.2 Skills and Justification:
1.2
Previous leadership positions
Organized
Attention to documenting meetings
Project Oversight
Internal Oversight: Design decisions will have three levels. At the lowest level the leads
of the various application functionalities are free to implement the functionality as they
see fit. If their implementation requires adding additional or changing functionality then
the addition or change will be discussed at the next level, a team meeting. The lead of the
affected functionality and the team leader must approve the change.
External Oversight: If the change is approved then it will be added to the list of proposed
changes and will be brought to the attention of the project sponsor at the next meeting
with the sponsor. Any changes that affect the cost of the project must also be brought to
the attention of the organization / company for approval.
15 August 2015 @ 5:16:00 PM
Procurement Management Plan
Design Lead
1.3
Team Meeting
Sponsor & Organization Approval

Interface Development Team:
Name
Kevin Kocian
Role
Team Leader
Frontend Developer
Software Developer
Mohammad
Kothawala
Frontend Developer
Backend Developer
Server Manager
Software Developer
Jesus Linares
Abdul Hadi
Khan
Network Developer
Performance Optimizer
Document Master
Network Developer
Security Developer
Ross Walker
GitHub Manager
Software Developer
15 August 2015 @ 5:16:00 PM
Responsibilities
Handles the team schedule, and assigns individual
assignments to team members.
General software development responsibilities:
design, coding, and testing.
Primary developer for the backend server
functionalities.
Responsible for ensuring the server is maintained.
Creates the functionalities necessary for interaction
between the server and client services.
Overlooks algorithms to ensure they are optimized.
Compiles documents into their final iteration and
manages changes to documentation.
Creates the functionalities necessary for interaction
between the server and client services.
Develops functionalities that responsible for
ensuring data transfer between client and server is
secure.
Maintains the GitHub version control system, and
aids other developers with properly committing their
work.
2

iGait Development Team: iGait is the software that the interface will be designed to
interact with. This team is responsible for the development and testing of the iGait
software.
1.4
1.
2.
3.
4.
5.
5.1.
5.2.
5.3.
6.
Project Constraints
Interface must communicate with iGait software / server

Limiting Data / Hour used
Business Model effects design
Architecture Design
Components
Wrapper
Camera
Test Data
Meeting with physicians / Subject matter experts.
1.5
Project Assumptions
Backend Server Hosting: We are assuming we will make use of a dedicated host server.
The server will be dedicated to handling the backend of the interface. This also includes
the assumption that the client base will be large enough to justify dedicated server
hosting.
1.6
Preliminary Schedule and Cost Estimates

Preliminary Project Schedule
Project Milestone
Due Date
Cost (Hours)
Project Charter
07/17/2015
30
SRS Gate Review
07/24/2015
60
Architectural Gate Review
08/13/2015
100
Final Design
09/14/2015
10
DDS Gate Review
09/20/2015
STP Gate Review
10/1/2015
30
Early Prototype I
10/26/2015
30
Early Prototype II
11/15/2015
20
Final Presentation and Demonstration
12/15/2015
50
15 August 2015 @ 5:16:00 PM

Server costs - estimate $50. 00 (Shall have better estimate towards development)
15 August 2015 @ 5:16:00 PM
2 Scope Statement
2.1
Introduction
The purpose of this project is to provide a graphical interface of the iGait program that has
been created by Dr. Mariottini and his research team in the ASTRA Robotics Lab. This
interface will be in the form of an android application and a web application that doctors or
therapists can use to monitor the progress or regress of their patients. The application will
work in collaboration with Kinects that will be installed at the patients residence to
monitor their gait.
2.2
Product Definition
The application that we propose to develop will have features that are going to be of great
benefit not only to doctors but also to the well being of the patient. According to what
version of the application the doctor purchases, there will be a difference of features.
However, the enterprise/professional edition describes the entire scope of services that the
application will render. Firstly, it will have a database of the entire clientele that a
particular doctor will have. This will only be accessible once the doctor successfully logs
into the system. Once the doctor enters the system there will be a list of all patients with
their picture/demographics. There will also be a status of the patient, showing either red or
green. If the status is green, the doctor will know that the particular patient is doing fine. A
red status bubble will indicate to the doctor that there is something wrong and they should
investigate. Patient list will appended according to the frequency of red events. Once the
doctor selects the patient, they will be able to view a timeline of weeks, days and hours.
The doctor will be able to view the gait of person as a skeletal video of that occurrence.
Furthermore, the doctor will have a chat service embedded in the application that can be
used for communication with the patient or staff. The doctor can also request for an actual
video of the incident; however, he/she will have to send a request that needs to be accepted
by the patient.
2.3
Intended Audience
Our target audience in mainly doctors and therapists involve themselves with the patients
recovery. Furthermore, this will attract hospitals and clinics running pain management
facilities to monitor their patients condition after surgery.
15 August 2015 @ 5:16:00 PM
3 Cost Management Plan

3.1
Project Budget
Senior Design is a two semester long course, the first half being documentation of
analysis, requirements, feasibility study etc. with second half reserved for the actual
implementation, review, testing etc. Roughly it is a 2000 person-hours job for both parts.
For the first half we have planned to allocate approximately 800 - 900 person-hours and
the rest for the second phase where the actual implementation is scheduled to begin.
We dont plan on using much of our budget, but at most will cover the following
2 Kinect($130 x 2 = $260)
1 Amazon Server ($100)
2 tablets (approximately $400)
license software (approximately $70)
15 August 2015 @ 5:16:00 PM
4 Earned Value Management

4.1
Use Microsoft Project for scheduling tasks
a. Will use a range between 0.00-2.00

i.
The range will be determine with agreement of the team
1. Below 1.00 stands for easy task
2. 1.00 stand for normal workload.
3. Above 1.00 stands for more difficult and/or time consuming task
ii.
If agreement cant be made,
1. Will proceed to do anonymous majority vote.
2. Once vote is made, decision is final.
4.2
i.
Report will be made within Microsoft Project.
a. If necessary,
Will use Excel to tally total Earned Value.
b. Team lead shall distribute Earned Value evenly
15 August 2015 @ 5:16:00 PM
5 Scope Management Plan

Controlling the scope involves constructing a bureaucratic yet effective system. A strict
adherence to the initial feature set can be accomplished using a feature checklist and feature role
sheet. Comparisons between the initial feature set and actual feature set will be completed by
committee at scheduled dates and dynamically at major GitHub commits. The scheduled
committee comparison will hold deliberations of approving or disapproving excess features and
of completing uncompleted features. Approved features to the feature set will follow a careful
update of the feature checklist, cost management, earned value, work breakdown structure, and
requirements.
Feature Checklist:
Feature
Completion in %
Month view:
Display the average levels of health per month.
---%
Week view:
Display the average levels of health per week.
---%
Day view:
Display the average levels of health per day.
---%
Hour view:
Display the average levels of health per hour.
---%
Glance view:
Display a simple Green/Red icon for the patients current
health.
---%
Patient view:
View patient information such as name, phone number,
address, and e-mail.
---%
Chat function:
Communicate with a certain patient using text messaging.
---%
Add/Remove patient function:

Allow the ability to add and remove patients.
---%
Video request function:

Request archived patient video stream. User must the
accept request.
---%
15 August 2015 @ 5:16:00 PM

Feature Role Sheet:
Developer
Role
Abdul Hadi Khan
Document Master
Network Developer
Security Developer
Kevin Kocian
Team Lead
Frontend Developer
Software Developer
Mohammed Kothawala
Frontend Developer
Backend Developer
Server Manager
Software Developer
Jesus Linares
Network Developer
Performance Optimizer
Ross Walker
GitHub Manager
Software Developer
Scheduled Comparison Structure

Every second week of every month all developers will hold a committee to compare the original
feature set and the actual feature set. The process is as follows:
1.
2.
3.
4.
5.
6.
GitHub masters review all committed changes to the committee.

GitHub masters bring forth excess features and features not completed.
Committee deliberates and votes on the approval or disapproval of the excess features.
Committee deliberates and votes on how to complete uncompleted features.
Feature checklist is updated.
Cost management, earned value, work breakdown structure, and requirements are updated if
needed.
Dynamic Comparison Structure
With every major commit to GitHub, the GitHub masters will compare the original feature set
and the actual feature set. The process is as follows:
1. GitHub masters review major commits.

2. GitHub masters approve or disapprove commit based on comparison of feature set.
If a commit is disapproved, the GitHub masters will bring it forth during the scheduled
comparison for further deliberation.
15 August 2015 @ 5:16:00 PM
6 Work Breakdown Structure
WBS
Name
Start_Date
Finish_Date
Senior Design
June 9, 2015
November 10, 2015
1.1
Phase 1
June 9, 2015
August 17, 2015
1.1.1
Charter
June 9, 2015
July 7, 2015
1.1.1.1
Initial Charter Draft
June 29, 2015
June 29, 2015
1.1.1.2
Complete General Organization section of Charter Draft
June 30, 2015
July 6, 2015
1.1.1.3
Complete Scope Statement section of Charter Draft
June 30, 2015
July 6, 2015
1.1.1.4
Complete Cost Management Plan section of Charter Draft
June 30, 2015
July 6, 2015
1.1.1.5
Complete Earned Value Management section of Charter

Draft
June 30, 2015
July 6, 2015
1.1.1.6
Complete Scope Management Plan section of Charter

Draft
June 30, 2015
July 6, 2015
1.1.1.7
Complete Work Breakdown Structure section of Charter

Draft
June 30, 2015
July 6, 2015
1.1.1.8
Complete Quality Management Plan section of Charter

Draft
June 30, 2015
July 6, 2015
1.1.1.9
Complete Communications Plan section of Charter Draft
June 30, 2015
July 6, 2015
1.1.1.10
Complete Change Mangement Plan section of Charter

Draft
June 30, 2015
July 6, 2015
1.1.1.11
Complete Procurement Management Plan section of

Charter Draft
June 9, 2015
June 9, 2015
15 August 2015 @ 5:16:00 PM
10

1.1.1.12
Compile Chapter Draft Sections Together
June 9, 2015
June 9, 2015
1.1.1.13
Review final draft of Charter
July 7, 2015
July 7, 2015
1.1.2
Requirements Definition
July 8, 2015
July 17, 2015
1.1.2.1
Requirements Spread Sheet
July 8, 2015
July 8, 2015
1.1.2.2
SRS
July 9, 2015
July 17, 2015
1.1.2.2.1
Initial SRS Draft
July 9, 2015
July 9, 2015
1.1.2.2.2
Complete Product Concept
July 9, 2015
July 15, 2015
1.1.2.2.3
Complete Product Description and Functional Overview

Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.4
Complete Customer Requirements Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.5
Complete Packaging Requirements Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.6
Complete Performance Requirements Section of SRS

Draft
July 9, 2015
July 15, 2015
1.1.2.2.7
Complete Safety Requirements Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.8
Complete Maintence and Support Requirements Section of

SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.9
Complete Other Requirments Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.1
0
Complete Acceptance Criteria Section of SRS Draft
July 9, 2015
July 15, 2015
1.1.2.2.1
1
Complete Use Cases Section of SRS Draft
July 16, 2015
July 17, 2015
1.1.2.2.1
2
Complete Feasibility Assessment Section of SRS Draft
July 9, 2015
July 9, 2015
1.1.2.2.1
3
Complete Future Items Section of SRS Draft
July 9, 2015
July 9, 2015
1.1.2.2.1
4
Compile SRS Draft Sections Together
July 9, 2015
July 9, 2015
15 August 2015 @ 5:16:00 PM
11

1.1.2.2.1
5
Review Final Draft of SRS
July 10, 2015
July 10, 2015
1.1.3
System Architecture
July 20, 2015
July 28, 2015
1.1.3.1
Initial ADS Draft
July 20, 2015
July 24, 2015
1.1.3.2
Complete General Section of ADS Draft
July 20, 2015
July 24, 2015
1.1.3.3
Complete Introduction Section of ADS Draft
July 20, 2015
July 24, 2015
1.1.3.4
Complete Meta Architecture Section of ADS Draft
July 20, 2015
July 24, 2015
1.1.3.5
Complete Layer Definition Section, Section of ADS Draft
July 20, 2015
July 24, 2015
1.1.3.6
Complete Inter-Subsystem Data Flow Section, Section of

ADS Draft
July 20, 2015
July 24, 2015
1.1.3.7
Complete Subsystem Descriptions Section, Section of

ADS Draft
July 20, 2015
July 24, 2015
1.1.3.8
Complete Operating System Dependencies Section,

Section of ADS Draft
July 20, 2015
July 24, 2015
1.1.3.9
Complete Testing Considerations Section, Section of ADS

Draft
July 20, 2015
July 24, 2015
1.1.3.10
Compile ADS Draft Sections Together
July 27, 2015
July 27, 2015
1.1.3.11
Review Final Draft of ADS
July 28, 2015
July 28, 2015
1.1.4
Weekly Tasks
June 9, 2015
August 17, 2015
1.1.4.1
Teem Meeting Agenda
June 9, 2015
August 12, 2015
1.1.4.1.1
Team Meeting Agenda 1
June 24, 2015
June 24, 2015
1.1.4.1.2
July 1, 2015
July 1, 2015
1.1.4.1.3
July 8, 2015
July 8, 2015
1.1.4.1.4
July 15, 2015
July 15, 2015
15 August 2015 @ 5:16:00 PM
12

1.1.4.1.5
July 22, 2015
July 22, 2015
1.1.4.1.6
July 29, 2015
July 29, 2015
1.1.4.1.7
August 5, 2015
August 5, 2015
1.1.4.1.8
August 12, 2015
August 12, 2015
1.1.4.1.9
June 9, 2015
June 9, 2015
1.1.4.1.1
0
June 9, 2015
June 9, 2015
1.1.4.2
Team Meeting
June 24, 2015
August 17, 2015
1.1.4.2.1
Team Meeting 1
June 24, 2015
June 24, 2015
1.1.4.2.2
Team Meeting 2
July 1, 2015
July 1, 2015
1.1.4.2.3
Team Meeting 3
July 8, 2015
July 8, 2015
1.1.4.2.4
Team Meeting 4
July 15, 2015
July 15, 2015
1.1.4.2.5
Team Meeting 5
July 15, 2015
July 15, 2015
1.1.4.2.6
Team Meeting 6
July 29, 2015
July 29, 2015
1.1.4.2.7
Team Meeting 7
August 5, 2015
August 5, 2015
1.1.4.2.8
Team Meeting 8
August 12, 2015
August 12, 2015
1.1.4.2.9
Team Meeting 9
August 12, 2015
August 12, 2015
1.1.4.2.1
0
Team Meeting 10
August 17, 2015
August 17, 2015
1.1.4.3
Weekly Meeting Minutes
June 9, 2015
August 12, 2015
1.1.4.3.1
Weekly Meeting Minutes 1
June 24, 2015
June 24, 2015
1.1.4.3.2
July 1, 2015
July 1, 2015
15 August 2015 @ 5:16:00 PM
13

1.1.4.3.3
July 8, 2015
July 8, 2015
1.1.4.3.4
July 15, 2015
July 15, 2015
1.1.4.3.5
July 22, 2015
July 22, 2015
1.1.4.3.6
July 29, 2015
July 29, 2015
1.1.4.3.7
August 5, 2015
August 5, 2015
1.1.4.3.8
August 12, 2015
August 12, 2015
1.1.4.3.9
June 9, 2015
June 9, 2015
1.1.4.3.1
0
June 9, 2015
June 9, 2015
1.1.4.4
Status Reports/ Friday Deliverables
June 24, 2015
August 5, 2015
1.1.4.4.1
Team Status Report 1
June 24, 2015
June 24, 2015
1.1.4.4.2
July 1, 2015
July 1, 2015
1.1.4.4.3
July 8, 2015
July 8, 2015
1.1.4.4.4
July 29, 2015
July 29, 2015
1.1.4.4.5
August 5, 2015
August 5, 2015
1.1.4.5
Status Report Presentation
June 26, 2015
August 7, 2015
1.1.4.5.1
Status Report Presentation 1
June 26, 2015
June 26, 2015
1.1.4.5.2
July 3, 2015
July 3, 2015
1.1.4.5.3
July 10, 2015
July 10, 2015
1.1.4.5.4
July 31, 2015
July 31, 2015
1.1.4.5.5
August 7, 2015
August 7, 2015
15 August 2015 @ 5:16:00 PM
14

1.1.4.6
Meeting with Dr. Mariottini
June 24, 2015
July 6, 2015 9:00

AM
1.1.4.6.1
Meeting with Dr. Mariottini 1
June 24, 2015
June 24, 2015 9:00

AM
1.1.4.6.2
June 29, 2015
June 29, 2015 9:00

AM
1.1.4.6.3
July 6, 2015
July 6, 2015 9:00

AM
1.1.4.7
Holiday Break Meetings
June 9, 2015
June 9, 2015
1.1.4.7.1
<New Task>
1.2
Project Planning
June 9, 2015
June 26, 2015
1.2.1
Individual Schedules
June 9, 2015
June 9, 2015 9:00

AM
1.2.2
Project Schedule
June 22, 2015
June 26, 2015
1.2.3
MS Project
June 22, 2015
June 26, 2015
1.3
Phase 2
August 18, 2015
November 10,
2015
1.3.1
Design
August 18, 2015
September 14, 2015
1.3.2
Implementation
September 15,
2015
October 12, 2015
1.3.3
Testing
October 13,
2015
November 9, 2015
1.3.4
Demonstration
November 9,
2015
November 10, 2015
15 August 2015 @ 5:16:00 PM
15
7 Quality Management Plan

7.1
Introduction
The purpose of a quality management plan is to develop an effective method for
maintaining standards for all aspects of this project. Among other set of documents a wellcrafted system requirement specification document in key to keep the project streamlined.
It will comprise of the requirements we receive from our customers (Dr. Mariottini,
Kinesiology Department and JPS Hospital) and what we, as developers, deem to be
appropriate.
7.2
Documentation
All the documentation and minutes from meetings are well organized into separate folders
per topic or deliverable in a shared Google Drive repository. Each folder has two
subfolders, namely Compiled and Working. Each team member is designated sections
from the actual document which they can edit on Google Docs in real time. This way each
member can conform to a common format set by the document master for the purpose of
making the compilation as smooth as possible. An internal deadline for each document is
set before a collective team meeting is held to critique on the produced draft. Should there
be a need to make any changes the document master will update the document and post it
inside the Compiled folder.
7.3
Software
Our team in going to adhere to well established principles of software design and
development. In order to keep are application focused we will be creating a chart of
features and requirements, requirements being on the x-axis while features on the y-axis.
Where ever most intersections take place with corresponding requirements, that feature
will be implemented into the application. We will also be employing various software
testing techniques so as to eliminate any margin of error.
7.4
Testing
To elaborate on testing techniques, as individual parts completed with an integrated we will
be performing Integration testing. This will ensure that the two modules are compatible
and congruent. This will be performed after each new module is added to the base product.
Once we have an initial system ready we shall perform white box testing on the system to
ensure everything performs smoothly. During this time designers of all individuals
modules will look for any anomalies under their sections. If so, that anomaly will be
tackled as a group and that particular module will undergo another Integration test,
followed by white box test. After the initial systems is ready, additional features will be
added to the system and a final Unit test will be performed before presenting the
application to the sponsor.
15 August 2015 @ 5:16:00 PM
16
8 Communications Plan
8.1
Introduction
We all established earlier that communication will be an integral part of this project. An
effective plan of communication is essential to keep all aspects of the project in order,
otherwise everything would be in disarray. Our plan has been made a standard to be
followed by all team members. We have also tried to establish an emergency mode of
contact incase the university has be closed.
8.2
Internal communication
8.2.1 Team meetings
Weekly Team meetings, which include implementation and completion of tasks due for the
week. Apart from that, preparing and planning for meetings with the sponsor and
professor as well as assigning individual tasks. Impromptu meetings (especially in order to
prevent unnecessary delays. Allowing some flexibility when needed (and which is not
detrimental to the project). All in all this fosters an environment that is conducive to
communicating.
8.2.2 Scrum meetings
Employing project status, and scrum meetings for 15 minutes after each senior design
class. In these meetings we discuss what we have been doing for the tasks that have been
assigned to us. A team member can enlighten others with some extra research they have
been doing regarding something that might be useful but had not been talked about during
our weekly meetings. Furthermore, in the last few minutes we discuss if we have any
questions, concerns or announcements that we have.
8.2.3 Whatsapp and Skype
We employ agreed-upon methods of communication, such as email, where we have shared
our student emails as well as a secondary email address. Skype accounts have been setup
for virtual meetings in case of emergencies where the university has to be closed down.
Group chat has been established on Whatsapp for instant messaging and updates. This is an
application that is quite useful for instant updates to all group members. It allows voice
messages and picture messages should an opinion is needed which is also time sensitive.
The messages are kept relevant, concise and simple so as to avoid confusion among team
members.
8.2.4 Google Drive and GitHub
We use Google Drive to upload documentary material related to the project for team
members so that they can view and modify/update as per the situation. Furthermore, a
15 August 2015 @ 5:16:00 PM
17

GitHub account has been created that will contain all the code that has been written and
similar to Google Drive any team member can view/update the code without having
multiple different files leading to confusion.
8.3
External communication
8.3.1 Meetings with project mentor (Dr. McMurrough)
We have decided to have short meetings with Dr. McMurrough, our project mentor, in
case we are unclear as to how to tackle a situation. Furthermore, since we have a sponsor,
Dr. Mariottini, who also provides us with requirements pertaining to the project, it is
beneficial to converse with our mentor so we can steer ourselves towards the correct
course of action.
8.3.2 Meetings with project sponsor (Dr. Mariottini)
We hold weekly meetings with the sponsor on Monday, to discuss the current situation of
the project. Update him with the progress made and discuss the future plans for the
project. Also get a much better understanding of what he wants us to do regarding the
application and whether or not a proposed feature is necessary to be embedded.
8.3.3 Weekly status reports
Hold weekly presentations for the class, so that everyone is aware as to what we are
currently working on, steps that have been taken to accomplish the tasks at hand, as well
as to inform them of the future plans and scope.
15 August 2015 @ 5:16:00 PM
18
9 Change Management Plan

9.1
Purpose of Integrated Change Management Plan

The purpose of the Integrated Change Management plan is determined what shall happen
in an event where a major change must occur. This plan is not to outline when a dynamic
change shall happen, but more of what minimally shall happen in a major change.
Furthermore, we plan to define all processes, tools, review bodies, and authority necessary
to monitor and control project performance, identified change and the potential impact of
change on project objectives.
9.1.1 Processes
Identification of Change
Change Management
Approval of Change
9.1.2 Tools
MS Project
GitHub
IDE
Server
Database
9.1.3 Authority to monitor and control project performance
Project Mentor Dr. McMurrough

Project Sponsor Dr. Mariottini
Project Manager Kevin Kocian
9.1.4 Expected change
Architecture Design
Physicians wants and needs
9.1.5 Potential impacts
Wasted work and time

Converting code
15 August 2015 @ 5:16:00 PM
19
9.2

Project Sponsor Shall meet with Project Manager and Project Team. Shall review
Project Teams progress.
Project Manager - Shall halt all progress in working. Shall plan emergency meeting
with Project Sponsor, Course Professor, and Project Team. Shall be main person
responsible for communicate with Project Team.
Project Team Shall meet with Project Manager and Project Sponsor. Project Team shall
continue working in anyway where the change will not be an issue of confliction.
Project Mentor - Shall be readily available to help in any decision making progress.
9.3
Review and Approval Process

9.3.1 Identification of Change
i.
Be brought up to members immediately

If needed
Emergency meeting shall take place
Team manager notifies sponsor and stakeholders
9.3.2 Change Management
i.
i.
i.
i.
Change in Project Scope:

Shall be determine by Project Sponsor and Project Manager
Change in Cost:
Shall be determined by Project Sponsor and Project Manager.
Change in Budget:
Shall be determined by Project Sponsor and Project Manager.
Review boards:
Project Team.
Change Approval Authorities: Project Sponsor, Project Manager, Project Mentor.
9.3.3 Approval of Change
i.
i.
ii.
1.
2.
a.
b.
Project Team meets with Project Sponsor

Project Team and Project Sponsor create a list of options for change ideas
Project Team makes majority vote on options
Team Sponsor and/or Team Manager can request to override the vote
Once request is made, the Project Team shall discussion the overridden vote
If any member in the Project Team doesnt not agree with the decision
Project Team will meet with Project Mentor
Project Mentor will determine what change shall be made
Project Mentor decision is final and must be follow
Change immediately takes effect.
15 August 2015 @ 5:16:00 PM
20
9.4

Change Identification, Documentation, Implementation and Reporting
MS Project shall be adjusted by Team Lead

Earn Value Shall be adjusted by Team Lead
Communication- Shall be done by Team.
15 August 2015 @ 5:16:00 PM
21
10 Procurement Management Plan

10.1 Purpose of the Procurement Management Plan
The Procurement Management Plan will ensure that all necessary tools, services, and
components are available at appropriate times based on the project schedule. The plan
will also provide a procedure to follow to ensure the team, and sponsor are in agreement
that procurement of the product or service is necessary and worthwhile.
10.2 Roles and Responsibilities
Title
Role/Identification
Project Sponsor
Approves procurement list before it is

submitted.
Project Manager
Communicates to Project Sponsor and to

Project Team
Project Team
Communicates to Project Manager
Project Stakeholders
Dr. Mariottini
Project Mentor
Dr. McMurrough
10.3 Required Project Procurements and Timing

Product /
Service
Description
Server
Hosting
Necessary for the implementation of the backend services for the interface.
Analysis:
Server Hosting: Approximately $50 / month for dedicated server hosting. May also use a service
that charges based on use, for this the charge is estimated at $0.008 / gigabyte. Developing the
infrastructure for a dedicated server will also drastically decrease the amount of man hours that
could have been spent to further the quality of the interface itself.
Planned procurements only include materials that will be necessary for the
implementation of the interface system, as such procurements must be completed before
Phase 2 begins. Procurement of services may wait until the completion of Phase 1.
15 August 2015 @ 5:16:00 PM
22
10.4 Description of Items/ Services to be acquired

The scope of the project includes developing an interface to the iGait software that will user
friendly for a physician to view relevant data on their patients whose gait is being recorded.
Under this scope we are to develop an android application.
Major Deliverables
iGait Interface - Android
15 August 2015 @ 5:16:00 PM
23

Project Charter Final

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Project Charter Final

Загружено:

Авторское право:

Доступные форматы

Senior Design Documentation Library

Department of Computer Science and Engineering

Last Update: 15 August 2015 @ 5:16:00 PM

Cost Management Plan......................................................................................................5

Earned Value Management...............................................................................................6

Use Microsoft Project for scheduling tasks

Scope Management Plan...................................................................................................7

Work Breakdown Structure..............................................................................................9

Quality Management Plan..............................................................................................15

Change Management Plan..............................................................................................19

Purpose of Integrated Change Management Plan 19

Procurement Management Plan.....................................................................................22

Purpose of the Procurement Management Plan

15 August 2015 @ 5:16:00 PM

Roles and Responsibilities

15 August 2015 @ 5:16:00 PM

Senior Design Documentation Library

1.1.2 Skills and Justification:

Previous leadership positions

Attention to documenting meetings

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

Sponsor & Organization Approval

Roles and Responsibilities

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

Interface must communicate with iGait software / server

Preliminary Schedule and Cost Estimates

SRS Gate Review

Architectural Gate Review

DDS Gate Review

STP Gate Review

Final Presentation and Demonstration

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

3 Cost Management Plan

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

4 Earned Value Management

Use Microsoft Project for scheduling tasks

a. Will use a range between 0.00-2.00

Report will be made within Microsoft Project.

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

5 Scope Management Plan

Add/Remove patient function:

Video request function:

15 August 2015 @ 5:16:00 PM

Procurement Management Plan

Senior Design Documentation Library

Abdul Hadi Khan

Scheduled Comparison Structure