Senior Design Documentation Library Project Charter

Department of Computer Science and Engineering

The University of Texas at Arlington

Team B: Door Keepers

Project: Wi-Fi Garage Door Opener

Team Members:
Anup Patel
Santosh Shrestha
Wasyhun Tesfaye
Adrian Echavarria

Last Updated: Sunday, August 3, 2014, 11:05 PM

Project Charter
 Senior Design Documentation Library

Table of Contents
Document Revision History ..........................................................................................................6
1 General Organization ........................................................................................................8
1.1 Project Manager .................................................................................................................. 8
1.2 Project Oversight ................................................................................................................ 8
1.3 Roles and Responsibilities .................................................................................................. 9
1.4 Project Constraints ............................................................................................................ 10
1.5 Project Assumptions ......................................................................................................... 10
1.6 Preliminary Schedule and Costs Estimates ....................................................................... 10
2 Scope Statement ...............................................................................................................11
2.1 Purpose.............................................................................................................................. 11
2.2 Product Definition............................................................................................................. 11
2.3 Intended Audience ............................................................................................................ 12
3 Cost Management Plan....................................................................................................13
3.1 Purpose.............................................................................................................................. 13
3.2 Financial Management ...................................................................................................... 13
3.3 Labor Management ........................................................................................................... 13
4 Earned Value Management ............................................................................................14
4.1 Introduction....................................................................................................................... 14
4.2 Components of Microsoft Project Plan ............................................................................. 14
4.3 Performance Analysis ....................................................................................................... 14
4.4 Earned Value Analysis...................................................................................................... 15
5 Scope Management Plan .................................................................................................16
5.1 Purpose.............................................................................................................................. 16
5.2 Staged Plan ....................................................................................................................... 16
6 Work Breakdown Structure ...........................................................................................17
6.1 Purpose.............................................................................................................................. 17
6.2 Microsoft Project File ....................................................................................................... 17
7 Quality Management Plan ..............................................................................................19
7.1 Purpose.............................................................................................................................. 19
7.2 Documentation Management ............................................................................................ 19
7.3 Software Management ...................................................................................................... 19
7.4 Testing Management......................................................................................................... 19

3 August 2014 @ 11:05:00 PM 4 Document Revision History

 Senior Design Documentation Library

8 Communications Plan ......................................................................................................20

8.1 Internal Communication ................................................................................................... 20
8.2 External Communication .................................................................................................. 21
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 ......................... 23
9.5 Change Proposal Form...................................................................................................... 24
10 Risk Management Plan....................................................................................................26
10.1 Purpose of Risk Management Plan ................................................................................... 26
10.2 Roles and Responsibilities ................................................................................................ 26
10.3 Risk Identification............................................................................................................. 27
10.4 Risk Triggers..................................................................................................................... 27
10.5 Risk Analysis .................................................................................................................... 27
10.6 Risk Severity ..................................................................................................................... 27
10.7 Risk Response Planning.................................................................................................... 29
10.8 Risk Documentation and Reporting .................................................................................. 29
10.9 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 .................................................................. 30
12 Project Closeout Report ..................................................................................................32
12.1 Purpose of Closeout Report .............................................................................................. 32
12.2 Administrative Closure ..................................................................................................... 32

3 August 2014 @ 11:05:00 PM 5 Document Revision History

 Senior Design Documentation Library

Document Revision History

Revision Revision
Description Rationale
Number Date
0.1 3/3/2014 First Draft Compiling of incomplete sections
0.2 3/4/2014 First Corrections Added in some missing sections
0.3 3/5/2014 Completed First Draft All sections assembled and integrated.
1.0 3/6/2014 Touches Last touches before turn in.
1.1 4/30/2014 Updates before Baseline A number of updates
2.0 5/1/2014 Final Baseline Updates List minute changes
2.1 8/3/2014 Baseline Updates Changes from DDS

3 August 2014 @ 11:05:00 PM 6 Document Revision History

 Senior Design Documentation Library

List of Figures
Figure 1: Product Scope ................................................................................................................ 11

List of Tables
Table 1: Roles and Responsibilities ................................................................................................ 9
Table 2: Schedule .......................................................................................................................... 10
Table 3: Cost Breakdown.............................................................................................................. 13
Table 4: Work Time Estimation ................................................................................................... 13
Table 5: Work Schedule................................................................................................................ 18
Table 6: Risk Analysis .................................................................................................................. 27
Table 7: Risk Severity................................................................................................................... 28
Table 8: Risk Response Planning ................................................................................................. 29

3 August 2014 @ 11:05:00 PM 7 Document Revision History

 Senior Design Documentation Library

1 General Organization
1.1 Project Manager
The project manager for the team will be Anup Patel. Anup Patel will be in charge of making
sure each member is reaching deadlines for required document submission and will make sure
the team is staying on track with the Microsoft Project Plan. Anup will also be in charge of
taking meeting minutes for each team meeting that we have and reporting them back to the team
as a refresher. Anup has had much experience working on various teams through his school
career and he will bring those skills and help the team stay on task.

1.2 Project Oversight

This section will demonstrate how the Door Keepers plan to stay on task and keep the progress
flowing the development of the Smart Garage product with our internal and external controls.

1.2.1 Internal Control

 Google Docs
Google Docs has been a crucial part of our project to date. It is a online server which
hosts all of our document files for individual sections as required for the deliverables.
Each member can go into the shared folder and make edits live, and that will not affect
anyone else. This saves the hassle of a single person only being able to edit a document at
one time.

 Team Meetings
For senior design one, team meetings for the Door Keepers are currently at 10:30am in
the Senior Design Lab right after the class lab session. Most members are able to stick
around for 2-3 where we can address any issues we are having with the project, discuss
requirements, discuss deadlines or even just hang out. For the intersession between spring
and summer, we will be conducting virtual team meetings via Google Hangout. Lastly,
for senior design two, we plan on meeting two to three times a week based on member
availability.

 Communication
GroupMe is an essential tool that the Door Keepers use as a form of communication.
Instead of a plain group text, all members have downloaded the GroupMe app on their
smartphone devices and we are all able to stay in touch with each other directly and see
what each other is talking about. GroupMe can also be accessed from the web incase
access via smartphone is unable at the time.

3 August 2014 @ 11:05:00 PM 8 General Organization

 Senior Design Documentation Library

1.2.2 External Control

 Individual Status Reports
Individual status reports allows Mr. O’Dell to evaluate the progress that each team
member is making on required deliverables for the current time period.

 Team Status Reports

Team status reports allows Mr. O’Dell to evaluate the progress that a team is making as a
whole on required deliverables for the current time period. While presenting our team
status reports, this allows for other groups to ask questions and we receive feedback.

 Gate Review
Formal Gate reviews exist for our team to present major deliverables to the teacher and
class within a 40 minute time period and receive feedback during the last 10 minutes of
class.

1.3 Roles and Responsibilities

Project Member Role(s) Description

Mike O’Dell Team Supervisor Oversees project as a whole.
Protection1 Team Sponsor Provides team with feedback on
Security deliverables.
Anup Patel Team Leader / Graphics / Assigns tasks, manages MS Project
Web Development File, and takes notes. Will design
website.
Adrian Echavarria Document Master / Web / Reviews and compiles all deliverables.
Software / Hardware / Hardware Research, Android lead.
Android
Santosh Shrestha Hardware / Android Hardware Lead
Wasyhun Tesfaye Packaging / Android Risk Management and Packaging lead.

Table 1: Roles and Responsibilities

3 August 2014 @ 11:05:00 PM 9 General Organization

 Senior Design Documentation Library

1.4 Project Constraints

Because the second half of the course is in the summer, we will have a few constraints:
 The project is to be completed in 7 months.
 Our team consists of 4 members to split the work.
 No hardware or android experience between the members

1.5 Project Assumptions

All team members will learn MS Project Plan and basic android development by the end of
summer intersession in June.

1.6 Preliminary Schedule and Costs Estimates

Task Due Date

SRS Initial Draft 02-27-2014
Project Charter Initial Draft 03-06-2014
MS Project Plan Initial Draft 03-06-2014
Architecture Design Draft 04-23-2014
SRS Due 03-27-2014
MS Project Plan Due 05-02-2014
Project Charter Due 05-02-2014
Architecture Design Due 06-04-2014
Detailed Design Due 07-04-2014
System Test Plan Due 07-11-2014
Prototype Due 07-24-2014

Table 2: Schedule

3 August 2014 @ 11:05:00 PM 10 General Organization

 Senior Design Documentation Library

2 Scope Statement

Figure 1: Product Scope

2.1 Purpose
The goal of this accessory is to give a homeowner remote control over their garage door,
utilizing their existing garage door opener, home internet connection, and smart phone. This will
allow the homeowner to monitor their garage, raise and lower the door, and check door activity
via sensors and live video.

2.2 Product Definition

The microcontroller is the brains of the Smart Garage. Microcontroller will have input/output
pins to fire signals to the garage door opener hardware, slots for internal storage and camera,
ports for wired and wireless access, and an online community with a lot of sample code,
instructions, and documentation on features.
The controller will be packaged in a hard enclosure with will prevent dust from entering. The
case will be also able to withstand high and low temperatures from weather. Smart Garage will
be mountable on ceiling with the brackets which will be included in it.

3 August 2014 @ 11:05:00 PM 11 Scope Statement

 Senior Design Documentation Library

While the hardware will not need much change, the software underneath must accommodate for
the microcontroller and its hardware. There are many distributions of GNU/Linux available for
use on the microcontroller, along with additional code to use its special hardware features (the
I/O pins and accessory slots/ports). We will however, need to setup a webserver in the
controller’s software to serve as a gateway for controlling the device and storing/serving
data/images/etc. This server will be accessible through the web and smartphone app.
App development must take into account how the microcontroller accepts inputs and deal with
the underlying software. Homeowner must be able to setup the Smart Garage and use it through
the android app or web browsers GUI based environment. Homeowner must not have any
circumstances on which they have to modify lines of code, deal with a terminal/command
prompt, or otherwise touch the underlying software. A simplified interface and setup will be
implemented.

2.3 Intended Audience

Our intended audience are smartphone-owning homeowners with garages who wants to monitor
and control their garage remotely. Some technical experience will be required to ease setup, as
there will be door-switches to place and ports on the garage door opener to hardwire. Our
product will be a small package that can be installed and executed on same day.

3 August 2014 @ 11:05:00 PM 12 Scope Statement

 Senior Design Documentation Library

3 Cost Management Plan

3.1 Purpose
The primary purpose of the team Door Keepers, cost management wise is to keep the material
cost with in the budget of $800 and divide the labor time equally between the team members.
Since our target audience are homeowners; our goal is to make an affordable accessory. To
achieve our goal we have decided to split Cost Management Plan into Financial Management
and Labor Management.

3.2 Financial Management

To keep the project under budget, team Door Keepers has researched the price of all the
components that will be required to build Smart Garage. These are hardware so far identified as:
a Garage Door Opener unit, Microcontroller Kit (includes, Wi-Fi adaptor, SD card, case, power
adaptor, etc), Camera, Sensors, and wires. This may change depending on requirements changes
during detail design, but this is baseline.
Since, during our implementation and test some product may break down. So, Door Keepers has
decided to get some of the equipment more than one depending on the risk and warranty the
equipment will have. According to the price of the components that has been provided at
Amazon.com we have estimated that this project will cost from $400.00 to $600.00. The
breakdown of the estimated price is shown in table below:

Item Name Lowest Cost Estimated Highest Cost Estimated

1. Garage Door Opener $150.00 $300.00
2. Micro-controller x 2 $120.00 $160.00
3. Camera x 2 $60.00 $60.00
4. Door Sensors x 4 $60.00 $60.00
5. Wires (for sensor/hook ups) x 2 $10.00 $20.00
Total Cost $400.00 $600.00
Table 3: Cost Breakdown

3.3 Labor Management

The total hours the team have to work to finish the project that we have obtained is around 1800
hours. Our total time period for the project is for 33 weeks. So, each member will have to work
for 13 hours per week. We have also estimated Source Line of Code (SLOC) to be around 1500
to 2000, according to COCOMO II. To obtain the best result each team member of The Door
Keepers must work effectively for:

Estimate Technique (in months) Best in Class Average Worst In Class

Jones’ First Order Estimation Practice 6.65 7.26 8.29
COCOMO II 7.9
Table 4: Work Time Estimation

3 August 2014 @ 11:05:00 PM 13 Cost Management Plan

 Senior Design Documentation Library

4 Earned Value Management

4.1 Introduction
Earned Value Management will be used by the Door Keepers to measure the productivity
relating to developing the Smart Garage. This measure is given by certain components in the
Microsoft Project Plan where we estimate the amount of hours (person-hours) that a task should
take then taking the actual (person-hours) for each of the tasks. Each member is responsible for
tracking their hours worked on anything relating to the product and documenting it in their
engineering lab book. On Friday during our weekly team meeting, these values are all requested
by one team member and updated into our Microsoft Project Plan.

4.2 Components of Microsoft Project Plan

Each task in our Microsoft Project Plan has the following items associated with it:
 Budgeted Cost Of Work Scheduled (BCWS) - Planned Value
Amount of work do we estimate a task will take. This value is assigned when the task
was created during our project planning phase.

 Actual Cost of Work Performed (ACWP) - Actual Cost

Amount of work does a task actually take. This value will be updated after the task is
completed.

 Budgeted Cost of Work Performed (BCWP) - Earned Value

The earned value for each individual task.
Along with the above, each task for our project is given a planned start and finish date to help
estimate and keep the team on track with development.

4.3 Performance Analysis

The Door Keepers will use CPI and SPI as performance indices to track individual and team
performance levels. Each task in our Microsoft Project Plan will be given a CPI and SPI to
analyze if we are on good performance, or bad with the task. The following are formulas on how
to calculate these values:

Cost Performance Index (CPI)

CPI = BCWP/ACWP = Earned Value/Actual Cost

Schedule Performance Index (SPI)

SPI = BCWP/BCWS = Earned Value/Planned Value

3 August 2014 @ 11:05:00 PM 14 Earned Value Management

 Senior Design Documentation Library

4.4 Earned Value Analysis

In order to make sure the development of our Wi-Fi garage door opener stays on progress, we
must make sure our performance analysis values states at the following levels:
CPI or SPI > 1.0 = Good Performance
CPI or SPI < 1.0 = Bad Performance

3 August 2014 @ 11:05:00 PM 15 Earned Value Management

 Senior Design Documentation Library

5 Scope Management Plan

5.1 Purpose
The Scope Management Plan details how the Door Keepers will keep the project under our
specified scope and not deviate from its intended purpose. Given the nature of our current
microcontroller and associated off-the-web software, its vast online communities, and its abilities
as a general computing device, maintaining this scope is extremely important.
Any major changes to the product will need to be scrutinized by the team: finding new
requirements, importance, impact, and the time required to perform these tasks. A general
description follows:

5.2 Staged Plan

5.2.1 New Requirements

We must find the root requirements of the desired change. The customer may say
one thing but mean something very different, and the hardware may or may not
have ways to accommodate. We will identify what specifically is desired (clarify
all new changes requested), and find the resulting new requirements.
The first question of these new requirements: are they in-line with the current
product feature set? Are we stepping into different territory, using or requiring a
new interface or item, and do we want to take this step? If so, we proceed to the
next step, determining importance and priority.

5.2.2 Importance
We must determine how important the desired change is. This will require
feedback from the customer and developer to decide on a priority. This will help
us prioritize changes, so the most desired changes are done earliest, based on
impact to the current project.

5.2.3 Impact
Based on those priorities, we must determine how feasible the requested change
will be. This feasibility will be weighted with the priority of the change, helping us
determine an overall impact on development for the desired change.
The team will then update the System Requirements Specification and Project Plan
documents accordingly. More on how we plan to deal with the resulting changes is
detailed in Section 9, Change Management Plan.

3 August 2014 @ 11:05:00 PM 16 Scope Management Plan

 Senior Design Documentation Library

6 Work Breakdown Structure

6.1 Purpose
Our Work Breakdown Structure is split up into three phases which include our two classes
Senior Design 1 and Senior Design 2 and the summer intersession. Senior Design 1 is the
primary planning phase of our project to identify what the Smart Garage will entail. Summer
Intersession is when the team will be remote from each other, but still continue to work on
project requirements such as learning android development. Lastly, Senior Design 2 is when the
team will start to actually work on finalizing specifications for our product and begin the primary
development phase.

6.2 Microsoft Project File

The following is an export from our Microsoft Project Plan which shows when we planned on
starting certain elements for our product. The information for Senior Design 2 will be updated
when an updated calendar is created for the course.

Task Number Task Name Planned Start Planned Finish

1 Senior Design 1 Fri 1/24/14 Tue 5/6/14
1.1 Documents Fri 2/7/14 Tue 5/6/14
1.1.1 System Requirements Fri 2/7/14 Thu 3/27/14
1.1.2 Project Charter Fri 2/21/14 Fri 5/2/14
1.1.3 Architecture Design Thu 4/3/14 Tue 5/6/14
1.1.4 Microsoft Project Plan Tue 1/28/14 Fri 5/2/14
1.2 Team Meetings Fri 1/24/14 Fri 5/2/14
1.3 Presentations Thu 1/30/14 Tue 5/6/14
1.3.1 Team Status Reports Thu 1/30/14 Fri 2/28/14
1.3.2 Charter and Project Plan Review Sun 3/16/14 Fri 3/21/14
1.3.3 SRS Gate Review Presentation Fri 3/21/14 Fri 3/28/14
1.3.4 Architecture Gate Reviews Fri 5/2/14 Thu 5/8/14
1.4 Research Mon 1/27/14 Fri 3/28/14
1.5 Sponsor Meetings Mon 2/10/14 Wed 4/30/14
1.6 Project LOGO Mon 3/17/14 Sun 3/23/14
2 Summer Intersession Mon 5/12/14 Fri 6/6/14

3 August 2014 @ 11:05:00 PM 17 Work Breakdown Structure

 Senior Design Documentation Library

2.1 Team Logo Design Mon 5/12/14 Fri 5/23/14

2.2 Android Programming Training Mon 5/12/14 Fri 6/6/14
2.3 Team Virtual Meetings (Google Mon 5/12/14 Mon 6/2/14
Hangouts)
3 Senior Design 2 Mon 5/26/14 Fri 8/8/14
3.1 Architecture Design Mon 5/26/14 Tue 6/3/14
3.2 Detailed Design Specification Thu 6/5/14 Fri 7/4/14
3.3 System Test Plan Sat 6/28/14 Fri 7/11/14
3.4 Prototype Tue 6/10/14 Thu 7/24/14
3.5 Presentations Mon 6/2/14 Fri 7/11/14
3.6 Team Meetings Mon 6/2/14 Mon 8/11/14
3.7 Research Mon 6/2/14 Fri 8/8/14
Table 5: Work Schedule

3 August 2014 @ 11:05:00 PM 18 Work Breakdown Structure

 Senior Design Documentation Library

7 Quality Management Plan

7.1 Purpose
The Quality Management Plan will make sure that the final product meets all the requirements
from the System Requirements Specification document. By abiding to these management plans,
The Door Keepers hopes to achieve quality control over the various parts of the documentation,
software, and testing, as the project continues forward.

7.2 Documentation Management

Each member is responsible for documenting the amount of time they have spent on the work
assigned to them. Before the documented works are brought together, reviews are done to make
sure that major points would not be left out. If any changes would have to be made then the
responsible person for that document would be notified to change it. After the documented works
are brought together, their formatting, grammar, and punctuation will be reviewed and altered by
our document-master, so that the entire finished document will be consistent. This draft is then
up for scrutiny by the team, sponsors, peer review group and Mr. O’Dell, before finalization.

7.3 Software Management

The software portion will use many off-the-web components/software made specifically for the
micro-controller and certain common tasks (web server, file storage, etc), shortening actual
development. All off-the-web components/code used will be in-line documented, with sources,
source URLs, access dates, compile dates, and author citation, along with original, unaltered
sources provided for review.
The custom parts, our look and feel, the phone app, and customized web page and controls, will
be stored and updated on the team’s online repository as updates occur. GitHub may be utilized
for our coding parts to help maintain version control, depending on our current online repository
strategy.

7.4 Testing Management

Testing will verify that the resulting product fully abides by our System Requirements
Specifications. The SRS will be on hand during all tests to ensure everything is as planned.
Once primary tests are concluded, it will be open for testing and feedback by our sponsor,
potential customers, and Mr. O’Dell.

3 August 2014 @ 11:05:00 PM 19 Quality Management Plan

 Senior Design Documentation Library

8 Communications Plan
8.1 Internal Communication
To communicate within the team, Door Keepers has decided to hold meetings and use Emails,
GroupMe, Google+ Hangout, Google Drive and our phones. The time period of this project is for
two semester so, the time and place for meetings will be managed as it will be easier during that
time. Door Keepers has also decided to meet virtually during the intersession of first and second
phase of the project.

8.1.1 Meetings
The Door Keepers has decided to meet every Friday after 10:30 am till 12:00 pm
in the Senior Design Lab for first phase. For the second phase since we will have
to build the Smart Garage so, team has decided to have meeting two times a week.
Team will meet in the Senior Design Lab on Wednesday and Friday. During this
period, major decisions and project planning will be done. Each team member
status will be discussed and next task will be assigned according to skills and time
available.
In addition to weekly meeting, the team has decided to meet one hour before each
senior design class to keep each member updated on any changes or plans during
the first phase of the project. This would help to bring more efficiency on the
work and work load on each member where we would be able identify the risk.
Since class will start early during second phase so no plan has been made yet.

8.1.2 Emails
Email will be used for longer communication, agendas, task questions, or
anything too large for a simple chat box between the team members.

8.1.3 GroupMe
GroupMe helps us cut phone-texting down and maintains a log of all our
communication for review by the team. This allows us to quickly share
information and updates with the group all at one time. GroupMe can also be used
through web. This has become very helpful when one of our member had lost the
smartphone.

8.1.4 Google+ Hangout

Google+ Hangout will be used when some of us would not be able to attend the
meetings. Since most of our team members live far away from the School. So by
using Google+ Hangout it will save time which we would have spent by travelling
to School. During the intersession phase some of us may travel but since we
would be still working for our project so we have expected to use Google+
Hangout for all of our meetings. During this meeting we would discuss about the

3 August 2014 @ 11:05:00 PM 20 Communications Plan

 Senior Design Documentation Library

Android app training and some pre planning for the Smart Garage design. Dates
and time for this meetings has not been decided yet.

8.1.5 Google Drive

The team has decided to share all the documents through Google Drive. Each
document would be sub-divided into subsections. After updating one of the
subsections that has been assigned, version number needs to be increased to keep
track of the updates that would be done according to time period. After the
completion of the subsection, it would be examined by each team member to
identify if there would be any mistakes. All of these subsections would be
arranged, combined and formatted together by one team member and examined
by the others after completion.

8.1.6 Phone
Phone calls are reserved for urgent problems or questions since we are busy
throughout the day. However, GroupMe has smartphone apps, keeping us
notified anywhere.

8.2 External Communication

To communicate with sponsor or Mr. O’Dell, the team utilizes Text Messages, Emails and
Meetings.

8.2.1 Text Messages

The primary way of communicating with the sponsors would be through text
messages. Sponsors would be updated about the status of Door Keepers, project,
schedule meeting and any other additional actions that would be taken such as:
email sent to sponsor regarding project question or documentation through text
messages.

8.2.2 Emails
Primary means of communication with Mr. O’Dell, and secondary with our
sponsor.
Emails will be used to submit documentation/deliverables and to communicate
about any difficulties that would arise in the project.

8.2.3 Meetings
Meetings with the sponsors would be held according to our combined availability.
Since Mr. O’Dell holds our classes, our primary meeting time is during class for
short inquiry or his office hours for longer sessions.

3 August 2014 @ 11:05:00 PM 21 Communications Plan

 Senior Design Documentation Library

9 Change Management Plan

9.1 Purpose of Integrated Change Management Plan
The need for changes in key features of a product during development processes in large-scale
projects is unavoidable. Such need of changes became the most significant factor due to the fast
growing technological achievements, the uncontrolled market variations, and the schedules
required for developing our product. Hence, preparing a thought-out change management plan is
one of the most important responsibilities that must be performed by any successful development
team. A well-documented change management plan will be used as a guideline when dealing
with changes that may occur during any product development phase.

9.2 Roles and Responsibilities

 Project Sponsor
The sponsor needs to present the details about the change to the attention of the team via
email or face-to-face meeting to the manager depending on the significance of the change
on the project. The team manager then will send the proposal, including his concerns on
the impact of the proposed change against the overall project schedule, via email to the
change manager. The change manager then will presents the proposal to the team for
decision. If it is a minor change, the team members will discuss during the team’s regular
meeting. If it is a major change, the team will decide to make a face-to-face discussion
with the sponsor. Upon acceptance, the sponsor will need to fill out the ‘Change Proposal
Form’ for the team records, and the change will be documented in further paperwork
rehearsals.

When the proposed change comes from a team member, the team will discuss and
evaluate the proposal. If the proposed change is moderate, the sponsor will be notified
during the nearest next meeting. If the proposed change is major, the sponsor will be
notified immediately. The sponsor will need to give approval of any change, regardless of
the rating of the proposed change. If the sponsor accepted the proposed change, the team
will fill out a Change Proposal Form, and document the change.

 Project Manager
The project manager is responsible to arrange meeting schedules with sponsors and
stakeholders whenever there will be a major change to be made. He will discuss the
qualities of a change proposed by either the sponsor or any stakeholder. Any changes or
modifications from any source shall first reach the project manager before it goes into
further actions.

3 August 2014 @ 11:05:00 PM 22 Change Management Plan

 Senior Design Documentation Library

 Project Team
Any team member is allowed to suggest a change throughout the projects life. The team
will then evaluate the pros and cons of performing the change make decision either by
consensus or by vote before passing the proposal to the sponsor and stakeholders.
 Change Manager
The change manager is responsible to arrange team meeting schedules whenever there
will be a major change to be made. He is responsible to make further researches
regarding the impact of proposed changes before bringing the change to the stage for
decision.
 Other Stakeholders
The project supervisor, Prof. O'Dell, is the only stakeholder of the project. The project
supervisor shall be alerted whenever there is any major change on the project. Moderate
and minor changes will be reported on the team and individual status reports. The project
supervisor can propose changes. The proposed changes will be processed in the same
manner as the project sponsor is going through.

9.3 Review and Approval Process

The details of proposed changes should be filled out onto Change Proposal Form. Any proposed
change shall go through the project manager before passed into further steps. The project
manager then sends the proposed change and his concerns, if any, via email to the change
manager. The change manager, after making some researches, then shall bring the proposed
changes to the team for discussions and evaluations. The team then shall make decisions on
whether the proposal is accepted or declined via consensus or vote. The team will also decide on
whether the proposed change will be passed to the project sponsor on both cases of accepting and
rejecting.

9.4 Change Identification, Documentation, Implementation, and Reporting

This section describes detailed information regarding the suggested change. The informations on
the ‘Change Proposal Form’ that will be required to be filled at the time of proposing a change
include: change description, the need of proposed change (Why?), effects of proposed change,
handling other effects due to the proposed change, rating of the proposed change(Major,
moderate, minor), and any other comments. It will also provide blank line spaces to fill the name
of the requester, the date, the signatures of; the person requesting the change, the project
manager and all other team members, as well as for the project sponsor and project supervisor
as needed. The form presented on the next pages, Change Proposal Form, will be used to record
about any proposed change in the project.

3 August 2014 @ 11:05:00 PM 23 Change Management Plan

 Senior Design Documentation Library

9.5 Change Proposal Form

Change Proposal Form
Requester’s Name: _____________________
Description of Change:
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Importance of Change:
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Effects of Change:
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Handling Effects of Change:
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Rating of Change:
Minor Moderate Major

3 August 2014 @ 11:05:00 PM 24 Change Management Plan

 Senior Design Documentation Library

Other Comments (if any):

____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Signatures
Name Signature Date
_______________________ _________________________ ____________
_______________________ _________________________ ____________
_______________________ _________________________ ____________
Project Manager
_______________________ _________________________ ____________
Project Sponsor
_______________________ _________________________ ____________
Project Supervisor
_______________________ _________________________ ____________

3 August 2014 @ 11:05:00 PM 25 Change Management Plan

 Senior Design Documentation Library

10 Risk Management Plan

10.1 Purpose of Risk Management Plan
This section contains the risk assessment and management plan of our project. Any
complication and difficulty that could probably be faced by the team and could potentially
obstructs or blocks the advancement of the project is considered to be a risk. The risk
management plan considered the most probable risks that may be encountered during project
development processes and established ways and procedures to deal with it whenever occurred.
The risk management plan is a fundamental reference to systematically recognize, sort, highlight,
and control any potential risk in the project

10.2 Roles and Responsibilities

 Project Sponsor
The Project Sponsor, Protection1, is a home security company with extensive experiences
in home security concerns in general and garage doors controls in particular. They are
willing to share real world experiences and knowledge in project development processes
and the potential risks to occur, provide available hardware devices as possible, advise
project ideas, comment and help to set up system requirement specifications, follow up
project developments and progresses throughout the lives of the project.

 Project Manager
The major responsibility of the project team leader is overseeing the whole project and
making sure the successful accomplishment of the system requirement specifications
according to the schedule. He need to make sure any progress in the project goes
according to the scheduled time frame. He, as any other team member, is also responsible
to get done his other specific project task assignments as needed.

 Project Team
The team is responsible to strictly follow the predetermined risk plans and task schedules.
The team shall evaluate project work progresses at least ones in a week to make sure the
development is going according to the plan and to retain risk impacts on the growth of the
project to a minimum.

 Project Stakeholders
We designed the project to develop a system that is targeted to be used in both business
and residential facilities. The potential risk here is, if our product will not satisfy the need
of our targeted stakeholders. Hence we focused and considered businesses and
individuals needs in relation to our product while setting up risk plans and system
specification requirements. We also considered potential change requests that may arise
from the stakeholders in terms of the need, technology, and demands of our product.

3 August 2014 @ 11:05:00 PM 26 Risk Management Plan

 Senior Design Documentation Library

 Risk Manager
The major responsibility of the risk manager is overseeing the project risks prevention or
minimization approaches. He is also responsible for collaborating any risks related
management concerns of the project within the rest of the team. He is also responsible to
develop risk management plans of the project.

10.3 Risk Identification

Although managing the risk minimization task is the major responsibility of the project risk
manager, identifying any potential risks of the project is the responsibility of each team member.
The risk manager is then responsible to document the risks and develop risk management plans,
though the final plan will be set by the team through discussions in a meeting. Discussing the
plan will also help other team members know how to deal with any risk that may occur during
development processes. The discussion, in turn, will make the team diminish the effect of risks
and retain the project development schedule accordingly.

10.4 Risk Triggers

Risk triggers are events or performance characteristics that warn of the occurrence of risk events.
The following risk triggers have been recognized by the team:
1. Missing individual deliverable deadlines/schedule
2. Emotional indicators of stress or non-school related issues
3. Requirements changes
4. Inability to construct hardware correctly/low hardware knowledge.
5. Low real world product development experiences
6. Members sickness

10.5 Risk Analysis

The following table shows the qualitative risk analysis table of risks that have been identified by
the team. It shows the ranks and probability of the risk occurring, and also its estimated cost to
the production schedule by days.
Risks Priority Probability Cost
(Ranks*) (%) (Days)
1. Missing individual deliverable 3 5 1
deadlines/schedule
2. Non-school related issues 3 15 3
3. low hardware knowledge 2 50 7
4. Low real world product development 1 100 7
experiences
5. Members sickness 3 10 3
6. Requirements changes 3 5 7
Table 6: Risk Analysis *Ranks: Critical-1, High-2, Low-3

3 August 2014 @ 11:05:00 PM 27 Risk Management Plan

 Senior Design Documentation Library

10.6 Risk Severity

The following table shows the severity of the identified risks. The table shows the
priority/severity, the resolution as well as the trigger for each risk.

Risks Priority/Severity Resolution Trigger

1. Missing individual Low Make sure the team Unable to
deliverable focus on the schedule move forward
deadlines/schedule as scheduled
2. Non-school related Low Try help to each other Problem to
issues and insure the move as
problem is solved as scheduled
possible.
3. low hardware Medium Make sure each Results to
knowledge member researched schedule
on all necessary overlapping
hardware devises and crowd
4. Low real world product High/Sever Try to identify the Uncertain
development real world risks by about what
experiences requesting experience will happen
sharing from seniors next for sure
5. Members sickness Low Make ready everyone Work load on
to cover up to each individuals
other next time may occur
6. Requirements changes Medium Make ready for any Work load on
possible requirement individuals
changes to come and may occur
to allocate time for it
Table 7: Risk Severity

3 August 2014 @ 11:05:00 PM 28 Risk Management Plan

 Senior Design Documentation Library

10.7 Risk Response Planning

Risks Response Type Descriptions

1. Missing individual deliverable Management Make sure the team members
deadlines/schedule focus on the schedule

2. Non-school related issues Management Try help to each other and

insure the problem is solved
as possible.
3. low hardware knowledge Management Make sure each member
researched on all necessary
hardware devises

4. Low real world product Management Try to identify the real world
development experiences risks by requesting
experience sharing from
seniors / experienced
personnel
5. Members sickness Management Make ready everyone to
cover up to each other next
time
6. Requirements changes Management Make ready for any possible
requirement changes to come
and to allocate time for it
Table 8: Risk Response Planning

10.8 Risk Documentation and Reporting

The risk manager will prepare a spread sheet to keep detailed information about the identified
risks and the risk management plans. The spread sheet will be uploaded in the team’s google
drive made available to be viewed by any member. The risk manager will be responsible to
update the spread sheet whenever new risk is identified. All other members shall be responsible
to discuss with the Risk Manager about the spread sheet to make sure no missed information in
the spread sheet.

10.9 Risk Control

The identified risks and risk management plans shall be discussed in team meetings whenever
identified. Risk management plans shall be discussed by the team and carefully documented by
the Risk Manager. The plans shall be made available in the team’s Google drive to be viewed by
all team members so that all team members can follow the plan and be on the same page with the
team. The responsibility of identifying, researching, mitigating any identified risk shall be of all
members including the risk manager.

3 August 2014 @ 11:05:00 PM 29 Risk Management Plan

 Senior Design Documentation Library

11 Procurement Management Plan

11.1 Purpose of the Procurement Management Plan
The purpose of the procurement management plan is to explain the process that must be followed
in order to acquire items that will be necessary to build out product. This process will help make
sure that only items that are necessary for our product are to be purchased and nothing is wasted.

11.2 Roles and Responsibilities

 Project Manager
Mike O’Dell will have the final say in purchasing items for our product.

 Project Sponsor
The Project Sponsor, Protection 1 Security, will provide insight into what may be needed
to build and design our product to specification.

 Project Team
The Door Keepers will be in charge of compiling a list of items that will be needed based
on team member domains.
o Anup Patel – Web / Software
o Adrian Echavarria – Web / Software / Hardware / Android
o Santosh Shrestha – Hardware / Android
o Wasyhun Tesfaye – Packaging / Android
The team members will do research in their own domains and bring back options to the team of
what exactly is needed to develop and make our product function.

11.3 Required Project Procurements and Timing

Items needed for our product should be procured before the implementation phase of our project.
Because of the design concepts of our product, we should be able to purchase everything needed
at the start and not need to purchase much in the future. We plan on purchasing all items at least
two weeks before our implementation phase to ensure all items arrive on time due to shipping.

11.4 Description of Items/ Services to be acquired

List of items the project needs to fully function:
 Microcontroller
 Web-Camera
 SD Card
 Form-fitting Case
 Mounting Screws
 Mounting Bracket

3 August 2014 @ 11:05:00 PM 30 Procurement Management Plan

 Senior Design Documentation Library

 Power Adapter
 Speakers
 Garage Door Sensors

Extra/future features to make our product better:

 LCD Screen
 Microphone
 External Light

3 August 2014 @ 11:05:00 PM 31 Procurement Management Plan

 Senior Design Documentation Library

12 Project Closeout Report

12.1 Purpose of Closeout Report
This report is conducted to assess how the project succeeded or failed upon completion. Lessons
learned, best practices, and shortcomings will be captured by this report. This will also resolve
personal, contract, administrative, and financial issues.

12.2 Administrative Closure

12.2.1 Were the objective of the project met?

Our product will be analyzed against our System Requirements Specifications
documentation and a prototype will be subject for inspection by our sponsor, any
potential customers, and Mr. O’Dell. Any requirements not met or deviations from
the SRS will be documented in the closeout report with explanations.

12.2.2 Archiving Project Artifacts

All documents, images, and sources will be kept as soft copies in the team’s
Google Docs online file repository, along with hard copies of the documents kept
in the senior design lab for reference. Receipts and other outside-source
documents/printables will maintain originals and scanned-copies.
The following are what will be archived and available for review:
 System Requirements Specification (SRS)
 Project Plan
 Project Charter
 Architectural Design Specifications (ADS)
 Detailed Design Specifications (DDS)
 System Test Plan (STP)
 Financial Records
 Purchase Receipts
 Team Status Report Presentations
 Source code with each major revision
 Build and Use Instructions
 General Status Reports

12.2.3 Lessons Learned

As we continue with this project, we will be recording everything in Engineering
Notebooks, and occasionally review each other’s notebook to help identify key
points when problems and successes occur. We will also occasionally ask each
other at meetings about problems we faced and successes we uncovered. These
will be recorded/noted in our repository for future reference.

3 August 2014 @ 11:05:00 PM 32 Project Closeout Report

 Senior Design Documentation Library

12.2.4 Plans for Post Implementation Review (PIR)

Upon our prototype passing acceptance criteria and inspection, we will conduct the
Post Implementation Review (PIR). This feedback will help us as we go toward
the final product.

12.2.5 Final Customer Acceptance

Upon finalizing the prototype, the team will conduct hands-on demonstrations of
the product with any potential customers, the sponsor, and Mr. O’Dell. They will
be given the opportunity to verify the compliance with the requirements and
provide feedback on their expectations.

12.2.6 Financial Records

All purchases will be documented and all receipts digitized and maintained by our
team on our repository (archival) with the hardcopies in the lab. These will be
incorporated into our final closeout report.

12.2.7 Final Project Performance Report

This report will review the performance of the project based on a few certain areas:
 Scope: Did the project maintain its desired area of specialization?
 Schedule: How was the team on their scheduled tasks?
 Quality: How well was the prototype/product accepted?
 Risk: Was the Risk Management Plan effective?

3 August 2014 @ 11:05:00 PM 33 Project Closeout Report