Fast Pass Parking (FPP)
Concept of Operations
Cop 4331, Fall, 2014
Modification history:
Version | Date | Who | Comment |
v1.0 | 10/15/14 | Kyle Mera, Alex Gordon | Created diagrams |
v1.1 | 10/19/14 | Kyle Mera, Alex Gordon, Ivan Lugo | High level architecture, Design issues |
v1.2 | 10/23/2014 | Alex Gordon | Proof read and ready for submission |
Team Name: Group 13 - Fast Pass Parking
Team Members:
Contents of this Document
High-level Architecture:
Design Issues:
Reusability
Reusability was not a priority for Fast Pass Parking because of time constraints. As a group we decided to create code that was specific to FPP. Making the code reusable would have been more time consuming. FPP is a complex application and we only had 2.5 months to complete it. It did not make sense to spend extra time to create reusable code in this circumstance. Another issue with reusability is that FPP is a specific application. The use cases of the features are designed specifically for FPP, not other applications. Although most of the objective-c code is not reusable, the backend code is reusable. The backend would be able to be used for any iOS, android, or web application.
Maintainability
Fast Pass Parking has two different development teams. There is an iOS team and a backend team. Therefore once the application is created, maintainability could be challenging because there is one group that is more familiar with how the backend works. This could bring up issues if people from the backend team are not available to maintain the backend code. Furthermore, one of the members of the backend team is hosting a server from a personal laptop. This could become problematic if that member decides he does not want to host the server anymore or is unavailable if there is a server crash. Just like there are problems with the backend team being more familiar with the backend, the same issues can occur with the iOS team. Only 3 members of the team have access to xcode 6. Therefore if these people are not available, it would be impossible to do maintenance on the front end code.
Testability
There are 6 members in the group and only 3 of the members have iOS devices. Therefore the devices that are readily available to the group are only iphone 4s, 5, and 6. Therefore the application can only be tested on actual hardware for some devices. The other devices will have to be tested on xcode simulators. This is not an ideal situation for development because an application can look differently on an actual device versus the simulator.
Portability
Portability was an issue that was discussed from the original design of Fast Pass Parking. The group decided that FPP should be an iphone application because statistics show that iPhone users are more likely to use credit cards on application. Another factor that played into this decision also was time constraints. With only 2.5 months to complete a complex mobile application, it did not make sense to make it portable for multiple operating systems. Therefore as a group we made the executive decision to make iOS the only operating system. This reduces the portability of the application because it makes it only available to certain users. Most smartphone users are using the Android operating system, therefore the lack of portability losses many users.
Security
Security is a concern when it comes to any application that takes credit card information. Fast Pass Parking will not be holding actual credit card numbers, but it will be holding other credit card information in the database. The database will also contain user information and passwords. The database is being hosted on a local server. This could provide security risks for the user’s information. A malicious user that is looking to steal this information could access the database easier because there is not high security within the database. A way to create higher security, while staying on the same server, is to create a more advanced encryption algorithm for the data in the database. This would make it more difficult for malicious users to steal the data.
Performance
The FPP platform is an iOS and network-connected system utilizing both mobile devices and hardline networked resources. A user will be accessing the application for no more than 5-10 minutes at a time to find and pay for a parking lot. All of the device to web-service interaction must happen in the millisecond interactions that a user will be creating to query and pay for parking lots. We have taken these use cases into account, and developed a strategy of data querying and downloading to allow a user to seamlessly pull lot information from our database. This will be accomplished by ‘chunking’ geolocated lots based on queries, and using those chunks to sort, display in a table, and render the locations of the parking lots in our system.
Prototype Requirements
The initial system must have the minimum use case scenarios of account creation and sign in, parking lot search and selection, payment database persistence, lot timing controls, and fee management and display. The enterprise application must incorporate the minimum use case scenarios of account sign in, license plate validation, and license plate fee assignment. The web services must incorporate the necessary routes, request handling, and model recognition and validation for those services required by the mobile client and parking lot managers.
Technical Difficulties and Solutions
So far, the technical issues we have encountered have been relatively minimal in scope and difficulty. Most, if not all, have been related to the initial ramp time required for building these services and applications for the first time; no ‘fundamental understanding’ issues have been encountered. Although there is a high level issue that has occurred due to the way the work load has been distributed. The work load was distributed between a backend team and front end team. Therefore should one portion of the application requirements be finished before the other, those developers responsible for the early-completed deliverables would be unable to assist the complementary platform software development team. They would not be able to do this efficiently because the iOS platform is written solely in Objective C and uses a unique toolset to that of web services piped through NodeJS, MongoDB, et al. Therefore there would be a significant learning curve for either team if they were looking to assist the complementary platform software development team.
Design Trade Offs
To date, no design trades have been made in terms of the implementation of our vision. The robust iOS platform, coupled with the well documented NodeJS, MongoDB, and Express.js APIs, have allowed us to code our vision exactly as we had originally intended. Our only trade offs have been in the implementation of the designs with the various iOS devices and their screen sizes (4s, 5s, and 6). Since each device has different amounts of screen real estate, the designs of the application have had to become slightly dynamic to handle the logos / tables / maps that each screen of the application contains. For example, logos must change in size to take up a proportional amount of space.
Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on Aug 15, 2000
This page last modified by FastPassParking Team on October 23rd, 2014