Software Engineering

Software Project Planning Document

Russell Dixon
Simon Palenchar
Ryan Richardson
Erik Miller
Radford University Software Engineering
http://radfordwildcats.weebly.com/
2/8/2016

Revisions
Version

Primary
Author(s)

Description of Version

1.0
2.0

Ryan Richardson
Erik Miller

1.0 Project overview, scope, and resources

2.0 Risk Management

Date
Completed
01/27/16
02/08/16

Review & Approval

Project Planning Document Approval History
Approving Party
Project Manager

Version
Approved

Signature

Date

Erik Miller

2.0

3/2/16

Dr. T. L. Lewis

Project Planning Document Review History

Reviewer

Version
Reviewed

Signature

Date

Russel Dixon

2.0

Russell Dixon

3/2/16

Erik Miller

2.0

Erik Miller

3/2/16

Simon Palenchar

2.0

Simon Palenchar

3/2/16

Ryan Richardson

2.0

Ryan Richardson

3/2/16

1
Wildcats

Contents
TEAM INFORMATION....................................................................................................................................3
Team Name.............................................................................................................................................3
Project Title............................................................................................................................................3
Customer Name/Contact Information....................................................................................................3
PROJECT OVERVIEW.....................................................................................................................................3
PROJECT SCOPE............................................................................................................................................3
PROJECT SUCCESS........................................................................................................................................3
PROJECT RESOURCES...................................................................................................................................2
Human Resources...................................................................................................................................2
Non-Human Resources...........................................................................................................................3
KEY STAKEHOLDERS....................................................................................................................................4
MAJOR RISKS...............................................................................................................................................4
Technology Risks....................................................................................................................................4
People Risks............................................................................................................................................4
Requirements Risks.................................................................................................................................5
Estimation Risks.....................................................................................................................................5
MINIMIZING RISKS.......................................................................................................................................5
Technology Risks....................................................................................................................................6
People Risks............................................................................................................................................6
Requirements Risks.................................................................................................................................6
PROJECT DELIVERABLES/MILESTONES........................................................................................................7
MANAGEMENT OBJECTIVES AND PRIORITIES..............................................................................................8
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS.........................................................................................8
PRELIMINARY SCHEDULE.............................................................................................................................9
REFERENCES.................................................................................................................................................9

Team Information
Team Name
Wildcats
2
Wildcats

Project Title
Deliverable
Customer Name/Contact Information
Kyle Wallace
(703) 424-6967

Project Overview
We will develop a multi-route optimizer through a GPS plug-in, using user customization
and an address queue to aid delivery drivers and managers.

Project Scope
We will develop a mobile multi-route optimizer through a GPS plug-in, using user
customization and an address queue to aid delivery drivers. Users will be entering
multiple addresses and the app will calculate and display the optimal route. Users will be
able to turn off the optimization to use a standard queue. The application will be
accessible to delivery drivers with GPS capabilities on their cell phones and within the
Google Maps boundaries. A companion website will display this queue to a delivery
drivers manager.

Project Success
Our project is successful if the application can return an optimized route based on a user
entered address list, save that list, and display the list on a website as well.

Project Resources
Human Resources
Russell Dixon
Simon Palenchar
Ryan Richardson
Erik Miller
Kyle Wallace
Non-Human Resources
Artis Lab
Google Maps API
Google Directions API
Google Drive
Cell phones
3
Wildcats

Computers
Weebly

Key Stakeholders

Delivery drivers
Local businesses and their employees
ITEC 370 Wildcats
Dr. Lewis

Major Risks
Technology Risks

Google maps or directions api could go down. The probability is low but the
impact would be catastrophic.

Entering in too many addresses could be too resource intensive and the phone
may crash. This has a moderate probability and would be serious.

There is a moderate probability that drivers could lose signal while driving. This
risk is moderate and tolerable

Team Weebly page is may be inaccessible. This is a low probability and tolerable.

Data corruption or loss is a low probability but would be catastrophic.

People Risks
We have a moderate but tolerable risk of user errors, i.e. wrong addresses.

We have a low/tolerable risk that developers are absent at critical points.

4
Wildcats

There is a low risk that we will be unable to get in contact with client at critical
points.

We have a moderate risk that required training could not be met in time. This
would have serious implications and push our delivery date back.

Requirements Risks

Driver is no longer allowed to use a smartphone for policy reasons. This has a
low but would be catastrophic, impacting our market.

Voice commands are not easily integrated into the software is moderately
probable with a serious impact.

There is a high probability we cannot easily integrate the android app and device
with Google Directions API, the effect of which is serious.

CASE tools may cause delays or not work properly. The probability of this is
moderate and the risk is tolerable.

There is a low, tolerable risk that customers dont understand the impact of extra
features.

Estimation Risks
We have a moderate risk of being unable to meet deadlines. This would have
serious implications directly effecting delivery time of our product.

There is a moderate risk of underestimating skill-level needed for tasks. This

could be potentially serious if we dont have enough time flexibility to catch up.

Underestimating time needed for tasks is a moderate risk that has serious
implications.

There is a high chance of scope creep that can potentially have serious effects on
our delivery time.
5
Wildcats

There is a moderate chance that software size will be underestimated, this can
cause major delays on project delivery date.

Minimizing Risks
Technology Risks

If Google maps or directions Api goes down, we will show an error page and tell
them to try again later when the Api is back up.

To prevent the phone from crashing, we will limit the number of addresses
entered or have a timeout for high response time. We will also do extensive
testing on various numbers of addresses.

In case drivers lose signal, we will allow for the software to save the address
queue and continue pinging for the satellites. We will also provide a list of
directions in a text format to the user.

We will have a back-up webpage with the necessary documents available for
download in case Weebly page is inaccessible.

We will have data backups to our RU H: drives and we will use version control
for the software development to prevent data loss or corruption.

People Risks

We can minimize user error by including good instructions and we will provide
validation when a user enters an address to make sure it is a proper address.

To minimize developer absence during critical points we will share schedules

often and plan our critical points around developers other responsibilities.
6
Wildcats

We can minimize the lost interest of our client by staying in touch with client
often, and address critical requirements as early as possible.

We will begin training on the platform and required technologies as early as

possible.

Requirements Risks

We will Restrict initial usage of software to device owners, and provide a web
service in a future version.

We will not include voice commands in the software.

We will research methods to integrate the app with Google Directions API and
brainstorm a successful system architecture.

We will establish a standard working environment that all team members will use,
and test it to make sure it is effective. If not, we will find other CASE tools.

We will communicate often, give detailed explanations of features, and accurate

cost estimates to keep the customer informed.

Estimation Risks

We will have detailed plans and a schedule that allows for critical components to
be done as early as possible.

We plan to do tutorials and discuss them prior to attempting big tasks.

Have a schedule that allows for milestones to be completed, which are smaller
pieces of larger tasks.

7
Wildcats

Identify if scope creep happens and make sure that initial requirements are
prioritized over new features.

Attempt to predict software size early and get all team members work extra time
to complete tasks.

Project Deliverables/Milestones

Milestone/Deliverable

Project Manager
Asst. Project Manager
(Select a PM and an Asst. PM for
each phase)

Project Planning (including six

web presentation)

PM: Erik

Requirements

PM: Ryan

Scheduled
Start

Scheduled
Finish

Feb. 8

Mar. 2

Mar. 2

Apr. 4

Apr. 4

Apr. 13

Apr. 4

Apr. 11-Apr. 20

Apr. 13

Apr. 25

Asst. PM: Simon

Asst. PM: Simon

Design

PM: Simon
Asst. PM: Russell

Development

PM: Russell
Asst. PM: Erik

User Manual and Final

Presentation

PM: Russell
Asst. PM: Ryan

Management Objectives and Priorities

A Google Doc with all team meetings and times will be updated.
Meeting days vary depending on scheduling conflicts.
The team will meet at least twice a week, unless behind schedule.
Email and text communication will be used daily to schedule meetings and answer
questions.
What are the consequences for a member missing a meeting?
Members missing meetings will cause delays in project development and an increased
effort by other teammates.
8
Wildcats

 How will your team compensate if a member does not respond appropriately to expected
assignments?
If a member is not responding appropriately, we will communicate effectively with the
member to better understand why they are not responding appropriately and the effects
the member is having on the team and project. If that doesnt work, everyone else will be
increasing their workload.
How who will serve as the lead customer contact?
Ryan will serve as the lead customer contact.
How often will you contact your customer?
We will contact the customer every day.

Definitions, Acronyms, and Abbreviations

App Application
Api Application programming interface

Preliminary Schedule

9
Wildcats

References

Android Studio - https://developer.android.com/training/index.html

Google Maps API - http://www.w3schools.com/googleapi/default.asp
Google Maps Directions API https://developers.google.com/maps/documentation/directions/intro?hl=en
Weebly http://radfordwildcats.weebly.com/

10
Wildcats