Project Management Plan

Fast Pass parking is a mobile app which solves the problem of antiquated parking systems. With the app, you can quickly check what parking lots are nearby and their respective pricing. You can also enter your credit card information and pay for parking time. You can either pay for a full day or pay in increments. The app will show how much time you have remaining and give you reminders to add time to your parking if necessary.

The ‘enterprise’ application, linked to the same database storing user accounts, will allow for attendants to scan and ticket users of the FPP platform to assert payment of a lot space, and to ticket users found to be violating parking times or rules.

Applicable Standards

NodeJs standards: http://nodeguide.com/style.html
Server side code standards: http://www.mongodb.org/about/contributors/server-guidelines/
Ivan Lugo will amend standards as documents are created and finalized. The project page will be monitored by all group members for device compatibility, usability, and readability. The living standards of the FPP Project, including user documentation, GIT repository information, digital rights information, UML diagrams, and our self-established standard will be hosted on our course page located http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-13/ . Our initial documentation will follow the prescribed formats from Doxygen (http://www.stack.nl/~dimitri/doxygen/index.html) and JSDoc (http://usejsdoc.org/) .
FPP will adhere to the Apple prescribed pixel-to-point size metrics (https://developer.apple.com/library/ios/documentation/2ddrawing/conceptual/drawingprintingios/graphicsdrawingoverview/graphicsdrawingoverview.html), with the 1x / 2x / 3x / SVG asset modeling.
Application assets and code will always be defined in ‘bytes’, and time will be based in fractions of hours.

Project Team Organization

Project Members: Ivan Lugo, Kyle Mera, Pedro Poveda Quevedo, Jason Braswell, Alex Gordon, Darin Doria
Ivan Lugo is in charge of the website. Pedro, Kyle, and Jason will be working on the database. Darin, Ivan, and Alex will be working on the iOS App. We will all be responsible for testing and QA of the app.
The team will meet twice a week in person, on Wednesdays and Sundays. The team will be pre-fed upon arrival - no exceptions. We also use an online communication interface: Slack.com. This allows us to chat with each other throughout the week. Our docuement sharing application will be ‘Google Drive’ to allow for live editing and version control.
We will also be using Google Docs to share documents and using GitHub in order to synchronize our code base.

Deliverables

Artifact	Due Dates
Meeting Minutes	Meetings are every Wednesday and Sunday at 5:30PM and 12:00PM respectively.
Individual Logs	Logs will be updated weekly and posted on the webpage.
Group Project Management Reports	N.A Please see weekly logs.
ConOps	September 18, 2014
Project Plan	September 18, 2014
SRS	September 18, 2014
High-Level Design	October 1, 2014
Detailed Design	October 8, 2014
Test Plan	September 18, 2014
User's Manual	November 25, 2014
Final Test Results	November 25, 2014
Source, Executable, Build Instructions	November 25, 2014
Project Legacy	November 25, 2014

Software Life Cycle Process

We will be implementing an Agile model, with weekly meetings and goals. We need to adjust quickly to customer needs as we learn more about the parking industry. We require a rapid development model to have a product before the deadline. We will define units of work under the standard Agile ‘Sprint’ model, consisting of 1-2 weeks of developer work, depending on a predefined group spec.

Tools and Computing Environment

The product will be released on iOS, as a result, we need to use Apple computers with OSX and Xcode to develop on. The programming language is Objective-C. We will also be using NodeJS for web services with MongoDB as our database. Development for this will be done on any SSH / VM capable machine.

Configuration Management

Version control will be done using Git.

Quality Assurance

QA will be involve at least two team members. For example, if a developer completes a feature another team member will QA it. If needed, more team members can QA a feature depending on how important it is. At our twice weekly meetings, difficult issues can also be tested and discussed per Agile requirements.

Risk Management

Risks:

There will be a learning curve for the group members that have not developed iOS applications
The will be a learning curve for the group members that have not worked with NodeJS.
Parking Lot owners unwilling to invest time in the FPP platform.
Time to complete / Amount of work ratio (3 month deadline / 6 developers).
Hosting limitations
Credit card security

Since there is a learning curve for users new in NodeJS and iOS, we have allowed members to specialize in a specific task.

To mitigate our risk of, for example, the City of Orlando having no interest in endorsing FPP we will make sure our app is secure, intuitive, easy to use. Additionally, we will not limit our app to the city of Orlando.

To deal with hosting limitations, we will be using our own server until the app is ready for deployment. Afterwards, we will deploy our app on a reliable server such as AWS.

As for as security issues, we will be saving user information on our databases. We will use encryption on our hosted datasources to prevent breaches in security. User credit card -stored locally- info also needs to be secured, and we will use a reliable third party such as Paypal to mitigate that risk.

Table of Work Packages, Time Estimates, and Assignments

Team 1: IOS (Ivan, Darin, Alex)

Team 2: Backend: Database/Webserver ( Pedro, Ivan, Jason, Kyle)

Package	Time EST.	Team Responsible
Create Sign In Page	1 Sprint	Team 1
Create User Database	2 Sprints	Team 2
Implement Screen with Parking Lots	1 Sprint	Team 1
Create Parking Lot Database	1 Sprint	Team 2
Interface with hosted Server	1 Sprint	Team 1, Team 2
Create Interface for purchasing parking passes	2 Sprints	Team 1
Create interface for checking which customers are currently parked/overdue	1 Sprint	Team 1
Set up Accurate GPS	1 Sprint	Team 1
Ensure Web Server Security	TBD / Rolling	Team 2
User Interface Testing	TBD / Rolling	Team 1, Team 2
Ensure Service Reliability	TBD / Rolling	Team 1, Team 2

PERT Chart

Technical Progress Metrics

For the requirements phase, we will count all of our planning documents, our charts, requirements tables, and changing requirements as our project concept is further refined.

For OO analysis and design, we will count UML diagrams completed.

For design and code, we will simply measure our output in terms of the functionality it has accomplished. Each feature will be time tracked in order to weed out and tackle bottlenecks in the development process.

For visual design and usability, we will rate our app in terms of speed of transition into different screens, as well as whether it has an intuitive interface through general QA testing.

Plan for tracking, control, and reporting of progress

Each team member will post individual time and activity log, and will also update our issue tracker located on our Git repository. In order to find and fix software bugs, members will consult one another to conduct testing.

Each week we will meet and discuss issues, solve larger problems, and discuss our software engineering philosophy (per Agile). We will also seek to eliminate bottlenecks in order to be seamless in our creation of our project.

Our project management report will be generated every two weeks and will include any changes to the project, as well as an updated PERT chart.

This page last modified by Pedro Poveda Quevedo (pedropovedaq@knights.ucf.edu) on 09/17/2014