Parking Revenue Management System

Final Project Report
Parking Revenue Management System
Project Supervisor
Mr. Arif H. Rashid
Submitted By
S18020224CA
Tayyab Hussain Malik MC160200254
Pg. 1

Software Projects & Research Section,
Department of Computer Sciences,
Virtual University of Pakistan
CERTIFICATE
This is to certify that Tayyab Hussain (MC160200254) have worked on and
completed has Software Project at Software & Research Projects Section,
Department of Computer Sciences, Virtual University of Pakistan in partial
fulfillment of the requirement for the degree of Masters in Information
Technology under my guidance and supervision.
In our opinion, it is satisfactory, up to the mark, and therefore fulfills the
requirements of Masters in Information Technology.
Supervisor / Internal Examiner
Arif H. Rashid
Supervisor,
Software Projects & Research Section,
Pg. 2

Department of Computer Sciences
Virtual University of Pakistan
___________________
(Signature)
External Examiner/Subject Specialist
___________________
(Signature)
Accepted By:
_____________
(For office use)
EXORDIUM
In the name of Allah, the Compassionate, the
Merciful.
Pg. 3

Praise be to Allah, Lord of Creation,
The Compassionate, the Merciful,
King of Judgment-day!
You alone we worship, and to You alone we pray
for help,
Guide us to the straight path
The path of those who You have favored,
Not of those who have incurred Your wrath,
Nor of those who have gone astray.
Pg. 4

DEDICATION
Dedicated to my Spiritual Mentor, Haji Sufi Masood Ahmad
Siddiquie, Lasani Sarkar, whose spiritual guidance led me to
recognize Allah (SWT) and our beloved Prophet Hazrat
Muhammad (P.B.U.H)
Dedicated to my family, who has tolerated me for not
attending my responsibilities toward them throughout my
two years of education, and stood by my side to see it
completed.
Dedicated to my all collogues at Lahore Parking Company,
who actually pushed me to go for the MIT Program and
chosen Virtual University for me.
Dedicated to all my staff and collogues at Windsor Parking
Services (Pvt.) Ltd, without the morale support of whom, I
could not have completed my MIT program and without their
help, the work that I am able to complete in one hour, would
have completed in half an hour.
Finally, Dedicated to all my Teachers and Course Instructors
at Virtual University, who actually made it possible, who gave
me “The Best Education at my Doorstep”
Pg. 5

ACKNOWLEDGEMENT
I would like to take this opportunity to express my sincere
thanks to Mr. Arif H. Rasheed who is my supervisor of
this project for his helpful guidance on this project despite
his busy schedules he guided me through emails.
I would like to express my sincere thanks to management
of Lahore Parking Company Ltd, and Windsor Parking
Services (Pvt.) Ltd who guided me to in developing the
Parking Revenue Management System. We had spent a lot
of time having meetings and discussions and with their
professional knowledge and rich experiences. Both the
managements not only assisted me to facing and tackle the
problems but also guiding me to analyses and approach
for a better solution.
I would like to thanks to the staff of operations and
revenue department of LePark who had provided very
valuable comments base on my output and put me back
onto the right track even when it comes to the very last
minute. Without their input and comments, this project
would become very unrealistic and impractical for general
use.
I would like to express my appreciation to the IT
Department of both the companies, for offering me
various resources including hardware and software that
was needed to do the RND work and make this project
possible.
Finally yet importantly, I would like to thanks to all my
co-workers who share their input throughout the project.
Pg. 6

PREFACE
With the increasing rate of vehicles being produced by using Chinese
technology and luxury vehicles being leased out easily, parking in the city
of Lahore has become a well-known issue. With this increasing rate, the
Public Facilitation Department of CGDL started contracting out the
parking stands at different places. This contracting out of parking stands is
a source of income for the City District Government.
Over the years, these contractors became a mafia. With the help of some,
corrupt elements in the government departments and political influences,
these contractors distributed areas and made a hold on these parking stands
to its roots. An estimated amount of 720 Million was earned annually from
these sites and the Government received 120 Million as contract amount.
This was due to arbitrarily charging at different parking sites and no
security was guaranteed to the public if the vehicles were reported stolen.
In mid of 2012 the local government, under the guidance of some
visionary government officers and the Chief Minister of Punjab, decided to
put an end to this rotting system, and decided to launch companies, that
would be operated by professionals from the private sector under the
supervision of the local government. The main aim of these companies was
to change the attrited system and bring in a new modernized system where
Information System was in the center.
Lahore Parking Company (LePark) was one of the companies, with the
aim to put an end to the parking mafia, implement homogeneous parking
rates, and give public a sense of safety and security for their vehicles. The
main aim of the Parking Revenue Management System is to put an end to
the traditional ticket based system and implement and new e-Ticketing
system and the revenue collected on daily basis can be monitored and
effectively utilized by the City District Government.
Pg. 7

Table of Contents
1 GATHERING INFORMATION AND ANALYSIS............................................13
1.1 Goals and Objectives..................................................................................................................13
1.2 Scope of Project:.........................................................................................................................14
1.3 Definitions, Acronyms and Abbreviations....................................................................................14
1.4 Use Case Diagram(s):..................................................................................................................16
1.4.1 Mobile Application:.......................................................................................................................16
1.4.2 Use Case: Main..............................................................................................................................16
1.5 Usage Scenarios – Mobiles Application:......................................................................................17
1.5.1 Login..............................................................................................................................................17
1.5.2 Check-In.........................................................................................................................................17
1.5.3 Add Parking...................................................................................................................................18
1.5.4 Reporting.......................................................................................................................................18
1.5.5 Synchronization.............................................................................................................................19
1.6 Use Case: Web Portal..................................................................................................................20
1.6.1 Web Portal....................................................................................................................................20
1.7 Functional Requirements:...........................................................................................................22
1.7.1 Mobile Devices:.............................................................................................................................22
1.7.2 Startup...........................................................................................................................................22
1.7.3 Security..........................................................................................................................................22
1.7.4 Connectivity..................................................................................................................................22
1.7.5 Printing of Parking Tickets.............................................................................................................22
1.7.6 Update Portal................................................................................................................................22
1.7.7 Reporting Logs..............................................................................................................................22
1.7.8 Synchronization of Data................................................................................................................22
1.8 Web Portal.................................................................................................................................22
1.8.1 Admin Login..................................................................................................................................22
1.8.2 Dashboard.....................................................................................................................................23
1.8.3 Defining Parking Sites....................................................................................................................23
1.8.4 Defining Mobile Devices...............................................................................................................23
1.8.5 Defining the Device Users.............................................................................................................23
1.8.6 Defining of Web Portal Users........................................................................................................23
1.8.7 Defining the Vehicle Types............................................................................................................23
1.8.8 Defining Fares or Rates.................................................................................................................23
1.8.9 Reporting.......................................................................................................................................23
1.9 Supplementary Requirements.....................................................................................................23
1.9.1 Usability.........................................................................................................................................24
Pg. 8

1.9.2 Non-Functional Requirements:.....................................................................................................26
2 PLANNING THE PROJECT...........................................................................29
2.1 Methodology..............................................................................................................................30
2.2 Available Methodologies............................................................................................................31
2.2.1 Waterfall Model............................................................................................................................31
2.3 Spiral Model...............................................................................................................................33
2.4 Rapid Application Development Model (RAD).............................................................................35
2.5 Agile Model................................................................................................................................37
2.6 Chosen Methodology..................................................................................................................39
2.6.1 What is VU Process Model............................................................................................................39
2.7 Reasons for the Chosen Methodology.........................................................................................41
2.8 Work Plan...................................................................................................................................42
2.8.1 Work Break Down Structure.........................................................................................................42
2.8.2 Dependencies................................................................................................................................43
2.9 Project Structure.........................................................................................................................43
2.9.1 Team Structure..............................................................................................................................43
2.9.2 Project Schedule (Delivery Calendar)...........................................................................................43
3 DESIGNING THE PROJECT..........................................................................48
3.1 Purpose:.....................................................................................................................................50
3.2 Scope.........................................................................................................................................51
3.3 Architectural Representation (Architecture Diagram)..................................................................51
3.3.1 Mobile Application........................................................................................................................51
3.3.2 Web Portal....................................................................................................................................52
3.3.3 The Presentation Layer.................................................................................................................52
3.3.4 The Business Logic Layer...............................................................................................................52
3.3.5 The Data Tier.................................................................................................................................53
3.4 Sequence Diagrams....................................................................................................................53
3.4.1 The Mobile Device........................................................................................................................53
3.4.2 Web Portal....................................................................................................................................57
3.4.3 Add Vehicles..................................................................................................................................58
3.4.4 Fares..............................................................................................................................................58
3.4.5 Locations.......................................................................................................................................59
3.4.6 Devices..........................................................................................................................................60
3.4.7 Device Users..................................................................................................................................61
3.4.8 Web User.......................................................................................................................................61
3.4.9 Reports – Date Wise......................................................................................................................62
3.4.10 Reports – Location Wise, Date Wise...........................................................................................62
3.5 Class Diagram.............................................................................................................................62
Pg. 9

4 DEVELOPMENT PLAN..................................................................................70
4.1 Mobile Application.....................................................................................................................71
4.1.1 Main Activity.................................................................................................................................71
4.1.2 The Main Menu.............................................................................................................................72
4.1.3 Selecting the Vehicle Type ...........................................................................................................73
4.1.4 Add Parking...................................................................................................................................74
4.1.5 Reports..........................................................................................................................................76
4.1.6 Date Wise Reports ........................................................................................................................77
4.1.7 Administration – Synchronization.................................................................................................78
4.2 Web Portal.................................................................................................................................80
4.2.1 Login and Dashboard....................................................................................................................80
4.2.2 CRUDs – Vehicles...........................................................................................................................82
...............................................................................................................................................................82
...............................................................................................................................................................82
4.2.3 CRUDs – Fares...............................................................................................................................84
4.2.4 CRUDS – Locations........................................................................................................................86
4.2.5 CRUDs – Mobile Devices...............................................................................................................88
4.2.6 CRUDs – Devices Users..................................................................................................................90
4.2.7 Reports - Datewise........................................................................................................................92
4.2.8 Reports – Datewise and Location Wise........................................................................................94
4.3 Database Diagram......................................................................................................................95
5 DIFFICULTIES...............................................................................................96
6 FUTURE EXTENSIONS AND VARIATIONS.................................................96
6.1 The Desktop Application for Off-Street Parking...........................................................................96
6.2 The Parking Machine Approach...................................................................................................97
6.3 The Valet Car Parking Application...............................................................................................97
Pg. 10

CHAPTER 1
Gathering & Analyzing Info
Pg. 11

1 Gathering Information and Analysis
Parking space in the heart of Pakistan, Lahore, is the need of the people as well as a
revenue-generating source for the City District Government, Lahore (Now MCL). For a
long time, the parking sites were auctioned to contractors by the CDGL. After the
contract was awarded, a small fee was deposited in the Government treasury but the
charges were arbitrarily charged causing revenue loss to the Government.
Looking into the matter above, CDGL moved a summery to the CM for making a
parking authority who would enter into a Private Public Partnership with a single
contractor, who would modernize the parking by introducing latest technology and
develop parking that, would facilitate the public as well as generate revenue for the
Government. The project ran into jeopardy, as the awarding of contract got late and the
authority having no previous Parking Management experience re-employed, either the
contractors themselves who used to run the sites previously or the employees of the
contractors. The contractors where used to the “Parchi System” that still exists, leaving
the government with the same revenue embezzlement and loss as before.
The aim of the project is to develop a Mobile Based Parking Revenue Collection
System, with a Web Based Portal, to facilitate the Government to collect and manage
the revenue and monitor activities at the parking sites on real time basis and get rid of
the Parchi System. Other than the local Governments, this system can be applicable to
Hospital managements or Mall managements to operate their parking and can use this
software to monitor their revenue.
1.1 Goals and Objectives
Upon have continuous discussions with the senior authorities and the management team
of the revenue department, the main goal and tasks was to develop a Parking Revenue
Management system, which will provide the following goals:
1. To replace the primitive ticketing system with a modernized e-ticketing
system.
2. To facilitate the Revenue Department of Parking Authority in analyzing
the real time data and determining the actual revenue collected on day-to-
day basis.
3. To minimize the embezzlements that was a major issue faced by the
District Authorities.
4. Facilitate the City District Government to look into the real time data so
that they on their own end can predict and forecast the revenues that
would help them to make budgets for any Development Programs and
contribute their share into the mainstream revenue of the country.
Pg. 13

1.2 Scope of Project:
This project will be developing a Parking Revenue Management System that will run
on a mobile-based technology, and supported by a web based back end services. The
scope is defined as follows:
• Investigate the value and the benefits of a system that would assist the
management of the Parking Authority and the City District Government.
• Study the loopholes in the existing non-computerized system and fill in
the fragmentation.
• Reduce the effects of embezzlement caused by the operational staff, and
report actual revenue to the higher authorities of both the departments on
real time basis.
• Eliminate the traditional ticketing System and introduction of the
modernized e-Ticketing system.
• Maintain the record on the mobile device on day-to-day basis.
• Send real time data to the web server for different analysis
1.3 Definitions, Acronyms and Abbreviations
Before getting in to the discussion of the project in detail, I would like to define some
terminologies first. During my study and observation, some of the words that come my
knowledge and their meanings “CDGL” etc. are mentioned below.
Word Meaning
CDG City District Government
Parking authority Lahore parking Company Ltd.
Parchi The traditional tickets applied on the streets parking
e-Tickets
New modernized ticketing system, using Android Devices to
produce parking tickets
Embezzlement Theft or misappropriation of funds placed in one’s trust
Check-in When a vehicle come to park and use the parking service
Check-out
The vehicle leaves the parking space and finishes the parking
service
Operator
The person standing on the parking area to facilitate the customer
by helping them to park their vehicles
Vehicles Usually the four types i.e. Car, Bike, Van or SUV and the Truck
Pg. 14

Device The mobile phone usually an Android based phone
PRMS Parking Revenue Management System
Revenue The amount of parking tax collected by the government
Portal
The web-based application to manage the system with, a database
at the back end
4G The 4th
Generation mobile broadband internet
Synchronization
The process of transferring the data from mobile device to the
cloud.
Use Case
A graphical representation of interactions among elements of a
system
Web Portal
A browser based web page to display information and provide
access to controls to a user.
SQLite A lightweight database usually used to store data in mobile devices.
localDB
A database usually on local system. In our case the a lightweight
database on the mobile device
SDK Software Development Kit
PDF
A file format for capturing and sending electronic documents in
exactly the intended format. An Adobe Product
CRUD
Create, Read, Update, Delete. A code that the MVC automatically
creates for you in controllers and views
GUI Graphic User Interface
MVC Model View Controller
ASP.Net Open source application framework by Microsoft.
Visual C# An object oriented language by Microsoft
ColdFusion An application development server side language by Adobe
Bootstrap
Bootstrap is the most popular HTML, CSS, and JavaScript
framework for developing responsive, mobile-first websites.
HTML Hyper Text Markup Language
CSS Cascade Style Sheets
JavaScript Client side language usually used with HTML
Xamarin
Programing language for mobile devices like Android, iOS and
Windows phone by Microsoft.
SQL Server
Microsoft's relational database management system (RDBMS). It is
a full-featured database.
Ajax Asynchronous JavaScript And XML
JSon JavaScript Object Notation.
Pg. 15

1.4 Use Case Diagram(s):
The system consists of a set of functions to assist in the PRMS. The following use cases
as shown below provides a better understanding and overview of the features and user
requirements included, as well as actors involved. It also represents the Functional
requirements of our system.
1.4.1 Mobile Application:
1.4.2 Use Case: Main
Device User
Admin User
Login
Checkin
Reports
Admin
Logout
Daily reports
Date Wise
Reports
<<include>>
<<include>>
<<include>>
vehicle Type
Selection
<<extend>>
Add parking
<<include>>
Sync data<<include>>
Delete Data
Figure 1 Use Case Mobile Application
Pg. 16

1.5 Usage Scenarios – Mobiles Application:
1.5.1 Login
Use Case Name Main Login
Implementation
Priority
Actor Device User
Summary The device users will login from the main screen providing
the username and a password
Pre-Condition Internet connection either 4G or DSL is required, Bluetooth
Printer should be paired and Bluetooth services activated.
Extends
Uses
Normal Course of
Action
The device user will check internet connectivity, the
Bluetooth pairing for each device and the login by providing
username and password.
Alternative Path If 4G connection is not available, using the nearest provided
DSL or any hotspot to connect the devices
Exception If the internet, the Bluetooth is not available or either
username or password is not provided, the system will
through exceptions.
Assumption
1.5.2 Check-In
Use Case Name Check-In
Implementation
Priority
Actor Device User, Admin User
Summary The user will select the required vehicle type to perform
operation like car, bike, van or truck.
Pre-Condition Although, Internet is not necessary, but to synchronize data to
live DB internet is required. Bluetooth connectivity with the
printer a prerequisite.
Extends Add Parking activity
Uses
Normal Course of
Action
The user clicks on the check-in option and will be taken to
the vehicle selection option. There the user will click on the
required vehicle type and will proceed to the Add Parking
activity. Sometimes it is observed that the Bluetooth skips
connectivity with the paired devices, so rather the user wastes
time in un-pairing and the re-pairing to re-gain the
connectivity, a button to re-pair will be available.
Alternative Path N/A
Exception No exception observed at this point.
Assumption
Pg. 17

1.5.3 Add Parking
Use Case Name Add Parking
Implementation
Priority
Actor Device User, Admin User
Summary Takes in the number of the vehicle and prints the E-tickets
Pre-Condition Only Bluetooth connectivity is required, Internet connectivity
is optional.
Extends N/A
Uses N/A
Normal Course of
Action
On the arrival of vehicle, the Device user will enter the
Numeric number (alpha numeric may cause delay) and hit the
save button, The system will print the ticket with the name of
the parking site, time in, the fare to be paid, a barcode or a
QR code and some disclaimers. The data will be saved
locally; if the internet is available, the data will synchronize
to live DB on the cloud that will be displayed on the web
portal. If due to any reason the internet connectivity is not
available the data will be saved on the local device informing
the user through some message alert or a toast that the data
saved but not synchronized but saved.
Exception If due to Bluetooth disconnection, which rarely occurs, the
system will throw an exception, the device user will get a
Bluetooth connectivity error, which the user can resolve by
pressing the re-pairing button.
Assumption
1.5.4 Reporting
Use Case Name Reporting
Implementation
Priority
Actor Device user, Admin User
Summary Prints Daily and Date wise reports
Pre-Condition Bluetooth printer should be active
Extends N/A
Uses Daily reports and Date Wise Reports
Normal Course of
Action
The user will press the reports button from the main
operation screen will be taken to the reports activity. There
the user can print 2 types of reports
• Daily report
• Date wise report
The devise user will just press the daily report button. The
only exception to be taken care is that the report should be
Pg. 18

taken before 12:00 am at day closing. The report will display
the site name, the count of vehicles and the total revenue
collected from that particular device.
Same actions will be taken for Date Wise reports except that
the user will give the starting, an ending date, and the same
report with the number of tickets showing the count of
vehicles types dispensed from a particular device from a
specific starting and ending date along with the revenue
collected will be printed on the report.
Alternative Path No alternative path
Exception N/A
Assumption
1.5.5 Synchronization
Use Case Name Synchronization
Implementation
Priority
Actor Admin User
Summary Synchronizes data to the cloud DB
Pre-Condition Internet Connectivity is required
Extends
Uses
Normal Course of
Action
At the end of the day when the collection team comes to
collect the revenue, after getting the reports from the devices,
the admin or the collection team will use their logins to
synchronize the data that was left un-synchronized during the
day due to fluctuation in 4G connection.
Alternative Path If 4G is not available, any DSL Connection can also be used
to sync the data.
Exception During the data transformation, if the 4G is used, there might
be chances that some data might be left un synchronized,
keeping in view the fluctuation nature of 4G, a message that
some data might be left unsynchronized will be displayed to
the user. The user will run the process once again until all of
the data is synchronized and the OK message displayed.
Assumption It is assumed that a high speed DSL is used for this process
Pg. 19

1.6 Use Case: Web Portal
Web User
Login
Vehicles
Fares
Locations
Devices
Users
Main Index
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Reports
Edit
Delete
<<include>>
<<include>>
<<include>>
PDF Builder
Admin User
<<include>>
Create
<<include>>
Date Wise
<<include>>
Date Wise/
Vehicle Wise
<<extend>>
<<extend>>
Figure 2 Use Case Web Portal
1.6.1 Web Portal
Use Case Name Web Portal
Implementation
Priority
Actor Web User, Admin User
Summary The Web Portal will be the controlling center for defining all
the users, vehicle types, vehicle fare, devices, parking sites
and reports.
Pre-Condition The user must be logged in
Extends PDF Builder
Uses
Normal Course of
Action
The web user will perform different administrative functions
here.
• The user will login in giving a username and a
password.
• The user will define the vehicle type. Usually
there will be four types of vehicles, Cars, Bikes,
Van, and Trucks. The user van delete and edit the
Pg. 20

types
• The user can define fares of the vehicles types
here and define that what type of vehicle will be
allowed on which parking site.
• In the management section:
o The user can define, update and delete
Parking Locations.
o The user can define, update and delete the
android devices. The user will provide the
location where the device is to be used, the
SIM number and its status, whether the
device should be activated or not.
o The user can define mobile device uses
and web users by defining their username
and passwords. The user can delete or edit
any entry
• The Reports section defines 2 types reports,
o Date wise
o Site Wise and Date Wise
The user will provide the start date and an end date and hit
the view report button.
In the second report, the user will provide the start date and
an end date and finally provide the parking site name for
which to view the report.
Both the reports will provide the location name, vehicle type,
ticket number, time in and the amount paid. The user can
down load both the reports by hitting the download PDF
button.
Exception N/A
Assumption N/A
Pg. 21

1.7 Functional Requirements:
1.7.1 Mobile Devices:
1.7.2 Startup
This would check the internet connectivity and login and fetch data like types of
vehicles and their rates from the internet and store in a local DB (SQLite) and would
facilitate even if the 4G were not available. If the internet connectivity is not available,
an error will be generated
1.7.3 Security
IEMI or SIM number will be stored on the cloud and at the time of login, the app will
compare the numbers (either of the both) and if checked, it will proceed to next
activity.
1.7.4 Connectivity
An SDK will be used to make the connectivity with a portable Bluetooth printer and
use its features. If the device is not paired and error will be generated.
1.7.5 Printing of Parking Tickets
After the connectivity with the printer, the operator will choose the desired vehicle
(Car, bike, van or truck) for which the ticket will be issued, enter the vehicle’s numeric
number, and a ticket will be printed with some required information.
1.7.6 Update Portal
After the ticket is issued, the data entered will be sent on the cloud, containing
information like, the vehicle no, time of arrival, etc. If in case, the data is not sent due
to fluctuation in the 4G it will be saved in the local DB, to be sent later.
1.7.7 Reporting Logs
Mobile device wise daily or date wise report (either or both), shall be printed at any
given time of the day for inspection by authorities for day closing purpose containing
the count of tickets issued to different vehicles.
1.7.8 Synchronization of Data
Due to fluctuation of 4G, the un-synced data mentioned above in point 5 will be synced
and complete data will be sent to the web portal to be reviewed by the authorities, next
day or whenever required.
1.8 Web Portal
1.8.1 Admin Login
An admin login will be done, by the authorized personals, who wants to perform
various tasks, as per authorization. A super admin will have all the rights.
Pg. 22

1.8.2 Dashboard
An attractive dashboard depicting various summaries in form of graphs shall be
presented.
1.8.3 Defining Parking Sites
This process shall be used for definition of the parking sites, i.e. the parking sites can
be created, edited or deleted. Sometimes, due to some governmental issues like
construction (Orange line, or extension in metro etc.) or any other reasons, parking
operations on those areas has to be terminated for sometime, so the status of the site can
be deactivated, and afterwards activated on resume.
1.8.4 Defining Mobile Devices
Keeping in view the security of devices and unauthorized usage, this process shall
register the SIM number or IEMI, which when set to active mode shall be used to login
the mobile device. Other than registering, the device the process shall be used to delete
the device (in case of theft or damaged to SIM or device) and update the status of the
device like its activation or deactivation (in case of lost device or SIM).
1.8.5 Defining the Device Users
This process shall define the device users. The admin can create, edit, delete, activate or
deactivate the users who will operate the mobile devices.
1.8.6 Defining of Web Portal Users
Likewise, the device users, web portal users can be created, edited, deleted, activated
and deactivated. This will also define the rights of the portal users.
1.8.7 Defining the Vehicle Types
The vehicles types shall be defined, though by default it is assumed that there are four
types of vehicles, Car, Bikes, Vans and Trucks.
1.8.8 Defining Fares or Rates
This process shall define the fares of the vehicles and this process will consider that on
which parking site, what types of vehicles are allowed and their rates. Sometimes, due
to some gazetted occasion, like 23rd
of March or some cricket match, the authorities
might decide to let the parking for free or subsidized for all or some types of vehicles,
this process will be used edit the fares.
1.8.9 Reporting
Several reports like, Date wise reports of all the vehicles, Vehicles wise reports, for a
particular date, Summary report just the count of vehicles type for a particular period,
Site wise reports etc. can be produced. They can be downloaded in PDF format for
further usage or record purposes.
1.9 Supplementary Requirements
Supplementary specifications define the Requirement that are not easily defined in the
use case Model. Requirements such as legal standards, quality aspects, supportability
and execution criteria of the system. The supplementary specifications cover all the
Pg. 23

nonfunctional requirements of the system. The scope of the supplementary
specifications is limited to all the nonfunctional requirements.
1.9.1 Usability
PRMS is user-friendly system. Both the modules i.e. the Mobile and the Web portal
needs a little bit of training. Following are the steps
1.9.1.1 Mobile Device
The user will start the application as any other mobile application. A login screen will
appear where the user will give in the user name and the password. A very simple and
user friendly GUI will appear. The user selects the checks-in option, selects the desired
vehicle for which the e-ticket is required, simply punch in the number and the printer
will print the e-ticket.
1.9.1.2 Web Portal
The web portal has a very user-friendly interface. The simple login screen will require
a username and a password. The Dashboard will appear with a self-explanatory side
menu, the screens are simple to use with the CRUD operations. The reports are also
easy to extract with either date calendar to extract reports date wise or with the vehicle
types to extract report vehicle wise and site wise. All reports has the PDF button to
extract the reports in PDF format, for further usage.
1.9.1.2.1 Usability Requirement
The mobile device uses Internet and Bluetooth connectivity. This is necessary feature
for the mobile devices to operate. Prior to operate the mobile device the operator will
connect the mobile device to the internet. Then he will check the connectivity to the
Bluetooth. If for the first time the connectivity is required, the user will scan the MPT-
II Bluetooth Printer and establish a connection by punching in the key which is usually
‘0000’.
To ensure security of the system and misuse of devices, a SIM security module is used.
Before issuing the mobile devices to the operators, the SIM that is inserted in to the
mobile device is registered by the admin, and when the user logs in the system checks
for the SIM number and if it is registered, the operator will be able to use the devise.
1.9.1.3 Reliability
Reliability is the Mean Time between Failures.
• Failures like drop signals in the 4G connection can occur while using the
mobile device. It is roughly estimated to be 3 to 4 times during the day.
• Another issue, which is, reported that, the printing head Bluetooth device
when exposed to sunlight stops printing.
• One major issue, the reason of which is still unknown, that when the
synchronization process is being conducted some duplicate entries are
reported to occur on the web portal.
Pg. 24

1.9.1.3.1 Reliability Requirements
The system handles this issue elegantly
• For drop signals of 4G, the system keeps a record on the mobile device in
a SQLite local DB marked as un-synced, which, as an SOP, at the end of
the day is synchronized.
• For Bluetooth head issue special belt pouches are used to keep the
printer’s head from being exposed to sunlight. This also gives safety from
dust and water.
• To solve the duplicate entry on the web portal, an SQL Query is written,
which is executed by the admin user to remove the duplicates if any. This
issues is also reported as resolved if, the synchronization process is
executed in chunks during the operational hours.
The reliability of the Web Portal is tested and no issues have been reported yet.
1.9.1.4 Supportability
All Android Devices ranging from Android version 4.x Kit Kat to latest Android
Version support the system. However, for the purpose of this project the supportability
is limited to Android Version 4.x Kit Kat. For this purpose, the DLL file of the
Bluetooth printer is built as a separate project and compiled on Android version 4.x
1.9.1.5 System Requirements
The system requirement for this software to run, and must adhere to are:
1.9.1.5.1 Software Requirements
• Visual C# MVC Framework and Entity Framework
• ColdFusion Markup Language (For APIs)
• C#-Xamarin native for Android
• Bootstrap, Ajax, HTML, CSS (For Front End)
• SQL Server used as Database
• SQLite used as local database for mobile devices
Pg. 25

1.9.1.5.2 Hardware Requirements
• Android version 4.x Kit Kat
• MPT-II Bluetooth printer or compatible
• 4G SIM of any mobile communication company
1.9.2 Non-Functional Requirements:
1.9.2.1 Operational Requirements
As the operational staff, which are, workers and supervisors, on the parking sites are
not well educated, except for some exceptions, needs to be trained and educated. The
common functions of mobile devices like, setting the internet connectivity, pairing
Bluetooth devices and usage of keyboard is required.
1.9.2.2 Maintenance Requirements
As the devices are assumed to be roughly used, maintenance is required, at least on
quarterly basis.
1.9.2.3 Safety Requirements
For the safety of devices, glass protection to save the screen and touch, will be
required.
1.9.2.4 Misuse of the Devices
So that the operators do not misuse the devices, a data sim with 4G connection will be
provided, to avoid phone calls, and some pattern security software to avoid unnecessary
downloads and change of mobile settings.
1.9.2.5 Legal Requirements
No such legal requirements currently required.
1.9.2.6 Security of Database
Only the DB admin whomever the authorities appoint shall be allowed to make changes
in the database structure of the handle the data.
1.9.2.7 Other Operational Requirements
No such operational requirements currently required, other than mentioned above.
Pg. 26

CHAPTER 2
Planning the Project
Pg. 28

2 Planning The Project
Before starting a software project, it is essential to determine the tasks to be performed
and properly manage allocation of tasks among individuals involved in the software
development. Hence, planning is important as it results in effective software
development.
Project planning is an organized and integrated management process, which focuses on
activities required for successful completion of the project. It prevents obstacles that
arise in the project such as changes in projects or organization's objectives, non-
availability of resources, and so on. Project planning also helps in better utilization of
resources and optimal usage of the allotted time for a project. The other objectives of
project planning are listed below.
• It defines the roles and responsibilities of the project management team
members.
• It ensures that the project management team works according to the
business objectives.
• It checks feasibility of the schedule and user requirements.
• It determines project constraints.
Project planning should be effective so that the project begins with well-defined tasks.
Effective project planning helps to minimize the additional costs incurred on the project
while it is in progress. For effective project planning, some principles are followed.
• Planning
• Risk analysis
• Tracking of project plan
• Meet quality standards
A project plan provides information about the end date, milestones, activities, and
deliverables of the project. In addition, it describes the responsibilities of the project
management team and the resources required for the project. It also includes the
description of hardware and software the methods and standards to be used. These
methods and standards include algorithms, tools, review techniques, design language,
programming language, and testing techniques.
A project plan helps a project manager to understand, monitor, and control the
development of software project. This plan is used as a means of communication
between the users and project management team. There are various advantages
associated with a project plan, some of which are listed below.
Pg. 29

• It ensures that software is developed according to the user requirements,
objectives, and scope of the project.
• It identifies the role of each project management team member involved
in the project.
• It monitors the progress of the project according to the project plan.
• It determines the available resources and the activities to be performed
during software development.
• It provides an overview to management about the costs of the software
project, which are estimated during project planning.
2.1 Methodology
Software development methodology is a process or series of processes used in software
development. Again, quite broad but that it is things like a design phase, a development
phase. It is ways of thinking about things like waterfall being a non-iterative kind of
process. Generally, it takes the form of defined phases. It is designed to describe the
how of the life cycle of a piece of software.
It is also codified communication. So you’re actually setting a set of norms between a
group of people that say this is how you’re going to work and this is how you’re going
to pass information between each of you in certain ways; whether that is
documentation, whether that is discussion, whether that is drawings on paper.
It is also known as a software development life cycle. The methodology may include
the pre-definition of specific deliverables and artifacts that are created and completed
by a project team to develop or maintain an application. Some of the methodologies are
• Waterfall Model
• Spiral Model
• Rapid Application Development (RAD)
• Agile Model
Pg. 30

2.2 Available Methodologies
2.2.1 Waterfall Model
The Waterfall Model was the first ever process model to be introduced. It is a very
simple to understand and use. In Waterfall Model, each process must be completed
before the next phase can begin and there is no overlapping in the processes. It is the
earliest SDLC approach that was used in the software development.
Figure 3 Water Fall Model
In the Waterfall approach, the whole process of software development is divided into
separate phases. The outcome of one phase acts as the input of the next phase
sequentially. This means that any phase in the development process begins only if the
previous phase is complete. The Waterfall Model is sequential design process progress
is flowing downwards steadily through the phases of Conception, Initiation, Analysis,
Design, Construction, Testing, Production, Implementation and Maintenance.
Sequential Phases of Waterfall Model
• Requirements
• System Design
• Implementation
Pg. 31

• Integration and Testing
• Deployment of system
• Maintenance
Advantages of Waterfall Model
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Disadvantages of Waterfall Model
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Poor model for long and ongoing projects.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
Pg. 32

• Integration is done at the very end, which does not allow identifying any
technological or business bottleneck or challenges early.
2.3 Spiral Model
The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model. This Spiral model is a combination of
iterative development process model and sequential linear development model i.e. the
waterfall model with a very high emphasis on risk analysis. It allows incremental
releases of the product or incremental refinement through each iteration around the
spiral.
Figure 4 Spiral Model
The Spiral Model is widely used in the software industry, as it is coordinated with the
natural development process of any product, i.e. learning with maturity involves
minimum risk for the customer as well as the development firms.
Spiral Model Phases
• Identification
• Design
• Construct
• Evaluation and Risk Analysis
Pg. 33

The following pointers explain the typical uses of a Spiral Model
• When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
• Customer is not sure of their requirements that is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line that should be released in phases to get enough
customer feedback.
• Significant changes are expected in the product during the development
cycle.
Advantages of the Spiral Model
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
Disadvantages of the Spiral Model
• Management is more complex.
• End of the project may not be known early.
• Could be expensive for small projects.
Pg. 34

• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.
2.4 Rapid Application Development Model (RAD)
Rapid Application Development is based on prototyping and iterative
development with no specific planning involved. The process of writing the
software itself involves the planning required for developing the product.
This focuses on gathering customer requirements through workshops or focus groups,
early testing of the prototypes by the customer using iterative concept, reuse of the
existing prototypes (components), continuous integration and rapid delivery.
RAD Development Phases
Following are the various phases of the RDA Model
• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
• Testing and Turnover
Pg. 35

Figure 5 Rapid Application Development
Following are the point use of RAD Model
• RAD should be used only when a system can be modularized to be
delivered in an incremental manner.
• It should be used if there is a high availability of designers for modeling.
• It should be used only if the budget permits use of automated code
generating tools.
• RAD SDLC model should be chosen only if domain experts are available
with relevant business knowledge.
Advantages of the RAD Model
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
Pg. 36

• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
Disadvantages of the RAD Model
• Dependency on technically strong team members for identifying business
requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills.
• Inapplicable to cheaper projects as cost of modeling and automated code
generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.
2.5 Agile Model
Agile SDLC model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working
software product. Agile Methods break the product into small incremental builds.
These builds are provided in iterations. Every iteration involves cross-functional teams
working simultaneously on various areas like:
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and
important stakeholders.
Pg. 37

Figure 6 Agile Model
Advantages of Agile Model
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned
context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
Disadvantages of Agile Model
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is necessary without
which it will not work.
Pg. 38

• Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can
be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum
documentation generated.
• Transfer of technology to new team members may be quite challenging due to
lack of documentation.
2.6 Chosen Methodology
Methodology is framework that is used to structure, plan and control the process of
development of any software. The required methodology by the institution is VU
process Model.
2.6.1 What is VU Process Model
VU process model is proposed software engineering process by Virtual University of
Pakistan that is the combination of waterfall model and spiral model in software
development. A process model explains the simplified description of software
processes in iteration to avoid maximum risk. There are many existing methodologies
in software engineering processes such as waterfall model, spiral model, building and
fix model, rapid prototyping model, incremental model, fountain model. These
methodologies help to successful delivery of product; however, two methodologies can
also be combined like VU process model combines waterfall and spiral model.
The Waterfall Model
In this approach, we see that processes flows in a downward fashion from requirement
phase to accepting phase that meets to client satisfaction. Requirements phase collects
software specifications, functional and non-functional requirements in SRS (software
requirement specification) document of VU final project. Analysis phase analyzes cases
and work plan based on software requirement phase that covers use case scenarios up to
methodology and work plan.
Pg. 39

Figure 7 Water Fall Model
Design phase goes through with flow charts, algorithms and GUI based on analysis
phase. Coding phase generates the actual logic of the application and provide
functionality to the system. The system logic is tested if it is working as it is as in
designing phase. Finally, client acceptance phase verifies if application meets to the
client’s requirement.
Spiral Model
Spiral model overcomes the cons of waterfall model by adding risk analysis to its phase
and one after another iteratively follows these phases in order to avoid maximum risk
during software development. By Iteratively followed means, that task move through
four processes many times until quality ensured.
Figure 8 Spiral Model
Pg. 40

Planning phase covers scope, requirements and functionality of the system. Second
phase Risk analysis is most important phase of spiral model that defines cost-effective
strategies in project development. Risk at any stage indicates that requirements must be
reviewed to find out solution for the problem by given data in the previous phase before
proceed to the next. Development phase covers the designing, coding and testing and
finally application is delivered to client for further evaluation. In case of any change, it
is required to iterate the application from all four phases again.
The VU Process Model (Combination of Waterfall and Spiral Model)
Figure 9 VU Model
2.7 Reasons for the Chosen Methodology
This methodology is a combination of waterfall methodology and spiral
methodology. This may also be called as “Hybrid Methodology”. It has five phases
that are
• Gathering and analysis requirements
• Design phase
• Development Phase
• Testing Phase
• Final Report and implementation
This model, as mentioned above is the hybrid model that is developed keeping in
view the pros and cons of both waterfall methodology and the spiral
methodology. In this model, each stage of waterfall is preceded by identification
of alternatives and risk analysis and then followed by evaluation and planning of
Pg. 41

next phase. It enhances the quality of project through documentation of each
phase and minimize risk by doing task analysis.
Why VU Process Model
Some of the reasons for choosing this model is as follows
Documentation driven Model: The VU Process Model is a documentation
driven model. It generates complete documentation and makes maintenance of
tasks such easier because the feedback the user gives must be fulfilled on each
phase of development.
Concise and Advance: Comparing the waterfall model, this model is more
concise and advanced, because at any stage we can go back, do the task and again
move forward, but in waterfall we can cannot move back.
Dependent on Risk Analysis: The VU process model is very much dependent
on risk analysis and contentiously evaluating each phase.
Corrective Measures: Corrective measures are allowed any stage.
2.8 Work Plan
2.8.1 Work Break Down Structure
The following is the list of deliverables and activities required to produce the
deliverables
Deliverables Activities
Requirement Documents
• Meet with the client
• Analyze necessary documents
• Create use case and modeling diagrams
Project Plan
• Based on Requirements, determine detailed task list to carry
project to first iteration
• Assign staff, estimate time needed
• Analyze schedule and timeline to determine feasibility
• Make allowance and reprioritize as necessary
Technology Prototype
• Learn the development language environment
• Create a prototype of the website and the Mobile App for user
review
• Analyze the workability of the features
Architecture Document
• Determine architecture of the project
• Create UML models showing data flow
First Iteration
• Software system to date will be shown to client
• Client analysis of software will be gathered
• Changes needed to requirements, design, and code will be
determined
• New documentation of requirements and design will be written
as needed
Second Iteration
• Software system to date will be shown to client
• Client analysis of software will be gathered
• Changes needed to requirements, design, and code will be
determined
• New documentation of requirements and design will be written
as needed
• All Changes at second time shall be considered as final tweaks
Final Product • Final Product will be presented to the client
Pg. 42

2.8.2 Dependencies
Due to time constraints, project management plans, requirements plan, architecture
plans, and development are all happening simultaneously. An advanced copy of early
stage requirements was received and thus was able to start multiple tasks. Code
development depends on the requirements document which will lead to the first
iteration. Remaining code development after the first (and second) iterations will
require analyzing customer feedback, changing the requirements document as needed,
and changing the architecture as necessary.
2.9 Project Structure
2.9.1 Team Structure
Arif Husen
Course Instructor
Tayyab Hussain
Student
Name
Software Developer
Name
UI Developer
Name
Android Developer
Figure 10 Team Structure
2.9.2 Project Schedule (Delivery Calendar)
The project schedule is one of the most important parts of the project development
plan. The plan includes:
• Scheduling of development activities and
• Scheduling of project resources, particularly people
The project development plan describes in detail:
• how the project manager plans to develop the project · what resources
will be required and
Pg. 43

• how these resources will be applied
No matter how well the project schedule is prepared, that schedule is useless
unless it is adhered to. It is the project manager's responsibility to withstand
pressure and to assure that the project is developed in an orderly fashion,
according to the schedule. Whenever circumstances change, the project schedule
should then be updated to reflect the new situation.
A schedule is a list of:
• Activities and
• Anticipated time of implementation of these activities
There are many ways of representing a schedule:
• Lists of activities,
• Diagrams,
• Graphs etc.
The most common methods of schedule representation are:
• precedence network diagrams
• Gantt charts and
• lists of milestones
The goal of a software project schedule is to determine the duration of the software
project and the phases with in the project. A software project schedule enables you to
distribute the estimated effort to be spent in performing the critical activities.
Schedule Calendar
Deliverables Submission Date
Project Macro Plan May 9, 2018
Baseline Requirements Document May 16, 2018
Project Plan May 21, 2018
Technology Prototype May 23, 2018
Customer-Approved User Interface May 31, 2018
Architecture Document June 14, 2018
First Iteration of the Product (Group Review) June 20, 2018
First Iteration of the Product (User Review) July 09, 2018
Testing Document Aug 06, 2018
Second Iteration of the Product (Group
Review)
Sep 09, 2018
Second Iteration of the Product (User Review) Sep 28, 2018
Final Product (Group Review) Sep 30, 2018
Final Product (Class Review) Oct 08, 2018
Final Product Presentation to User Estimated
Pg. 44

CHAPTER 3
Designing the Project
Pg. 47

3 Designing The Project
Systems are created to solve problems. One can think of the system approach as an
organized way to solve the problem. This subject, i.e. System Analysis and Design
deals with the software development activities.
System Analysis:
System analysis the process of collecting factual data, understanding the process,
identifying the problem and the solution to for an improved, fully functional system.
This involves of understanding the business process, collecting operational data,
understanding the flow of information, identifying the bottlenecks and recommending
the solution for overcoming the weaknesses in the system to achieve the business goals.
It also includes the sub-division of complex problem, involving the entire system,
identification of data store and manual process.
The major object of system analysis is to find the answers for each business process.
What is being done, for how long is it being done, who is doing it, since when is he/she
doing it, why is it being done, and finally, how can it be improved. It is more of a
thinking process and involves the creative skills of the system analyst. It attempts to
create a new efficient system that is more beneficial to the organization and has scope
for feature growth of the business within the organizational constrains.
System Analysis is an iterative process that continues until a new system emerges, this
preferred and acceptable to all stakeholders. It is an essential part of developing a
system. It consists of system elements, process and technology.
To analyze a system, the system analyst has to study the system in detail. Before
designing the system, the system analyst hast to understand the functional parts, and the
concept. For this, the analyst has to carry out a customary approach, for solving the
problem.
System analysis include the following basic concepts:
• Primary investigation
• Requirement specification
• Feasibility study
• Detailed investigation
• Designing and coding
• Testing and Training
Pg. 48

• Implementation
The above steps constitute the logical framework, for system analysis. After primary
investigation and feasibility study, the scope of the defined and comparable items are
set, and hence detailed investigation is executed. Then system is designed and coding is
done. The system is tested, training is conducted for the persons to operate the system
and the system is finally implemented.
System Design:
Based on the user requirements and detailed analysis of the existing system, the new
system is designed. This is the most crucial phase in developing a system. The logical
design arrives as a result of system analysis, which is then converted to physical design.
Usually, the design proceeds in two stages.
• Primary or General Design
• Structured or Detailed Design
Primary or General Design
In the Primary or General Design, the features of the new system are specified. The
cost to implement and benefits to be derived are estimated. If the project seems to be
feasible, then we move to the detail design stage.
Structured or Detailed Design
At this stage, the design gets more structured. Structured design is a blue print, of a
solution to a given problem having the same components, and interrelations among the
same components, as the original problem. At this stage, the software platform, the
language(s) to be used, the hardware, the codification scheme, all are drawn up in detail
and decided.
There are several tools and techniques used for describing the system design like,
Flowcharts, Data flow diagrams, Data Dictionary, Decision trees, Decision tables,
Pseudocode.
Pg. 49

Figure 12 Design Phase
System Design Involves
• Defining precisely the required system output.
• Determining the data requirement for producing the output.
• Determining the medium and format of files and databases.
• Devising processing methods and use of software to produce output.
• Determine the methods of data capture and data input.
• Designing Input forms.
• Designing Codification Schemes.
• Detailed manual procedures.
• Documenting the Design.
3.1 Purpose:
The purpose of this document is to describe the reasons for implementation of the
Parking Revenue Management System. For decades the Municipal Corporation or the
City District Government, to collect revenue from different public facilities has been
contracting out its facilities. One of the facilities were the parking sites. During this
period, the contractors grew into mafia and started to operate the sites arbitrarily.
To put an end to this mafia and compete the established CDGs all over the world, the
CM called upon a meeting of the higher officials and hence passed a summary to form
Pg. 50

such companies that would uplift the quality of services provided to the public and
place city of Lahore into the top-rated modern cities. One of the companies was the
parking authority that was formed. The core purpose of the authority was to put an end
to the parking mafia and introduce a new modernized Parking Management System.
Looking into the dynamics of the city, the complete parking system was not possible,
but collection of revenue was needed to be ensured as soon as possible. For this
purpose, The Parking Revenue Management System was needed, that would ensure
that the actual amount of revenue collected and give details on real time basis, eradicate
the previous ticketing system and replace with a modernized e-ticketing system on the
parking sites.
To meet the challenges of real time and modernized parking revenue management
system, blend of mobile devices and cloud-based application was required. The parking
operators, hence replacing the previous ticketing system with the new e-ticketing
system and a web-based system to be operated by the revenue department of the
parking authority and the officials of the CGD jointly, will operate the mobile devices.
3.2 Scope
This document describes the implementation of the PRMS. The system will be a
Parking Revenue Management System that will facilitate the staff of the Parking
Authority and the officials of the CDG to jointly operate and manage the system
effectively. The document will define the detailed structure of the software. It is
assumed that the SRS has been studied and the behaviors of the system understood. It
will be a guideline for the developers who will develop and implement the system. The
system will contain the sequence diagrams, class diagrams and architecture diagrams of
the system.
3.3 Architectural Representation (Architecture Diagram)
3.3.1 Mobile Application
Figure 13 Architecture Diagram - Mobile App
Pg. 51

3.3.2 Web Portal
Cloud
Client Browser
Presentation Layer - Views (HTML, JS, CSS, Ajax)
Business Logic Layer - Controller (ASP.NET C# files))
SQL Sever - Model
Figure 14 Architecture Diagram - Web Portal
3.3.3 The Presentation Layer
The presentation layer is the top most layer of the application is the user interface. The
function of the interface is to translate tasks and results to something the user can
understand.
The following files are part of the presentation layer
3.3.3.1 Mobile Application
• All .axml files in the Resources/layout folder
• All images in the Resources/drawable folder
3.3.3.2 Web Application
All .cshtml files in the Views folders
3.3.4 The Business Logic Layer
This is where the business rules are implemented. In the tiered architecture business,
logic is separated from the user interface and data access. This layer simplifies
maintenance and integration of new component and subsystems.
In the Mobile application all, the .cs files under the project folder are the Business Tier
files
Pg. 52

Not necessarily, but in ASP.net MVC framework, all the files under the Controller
folders are the business logic layer
3.3.5 The Data Tier
In this layer, the information is stored and retrieved from the Database or the file
system. The information is ten passed back to the Business tier for processing and
finally back to the Presentation layer for the user to act upon.
In the mobile application, the data layer may consist in two parts, the SQLite database
and through a special layer, the internet layer the data is passed through the APIs to
the database on the cloud. The Data Layer on the cloud might use tools like SQL
Server, Oracle, MySQL, etc.
In the MVC framework, the Data layer is in the Models folder, the .emdx file.
3.4 Sequence Diagrams
Sequence diagrams describe interactions among classes in terms of an exchange of
messages over time. They are also called event diagrams. A sequence diagram is a good
way to visualize and validate various runtime scenarios. These can help to predict how
a system will behave and to discover responsibilities a class may need to have in the
process of modeling a new system.
3.4.1 The Mobile Device
The mobile device used is an Android based 4.4 Kit Kat Operating System. The
mobile-based system is very simple to use and develop. The language used is Xamarin,
a flavor of C#.
Pg. 53

3.4.1.1 Login
Figure 15 Sequence Diagram - Login Mobile App
The mobile device at its main activity will check for the internet connectivity and
Bluetooth printer connectivity, If both are connected the system will proceed to the
login menu else, it will prompt the user to connect either or both. After the
connectivity, the system will display the login screen. When the user logs in the system
will get the username, password, the SIM number from the cloud DB, if any of the
elements do not match, the system will prompt an error. If the elements match the
system will then get the new fares (if any) of the vehicles against that site and delete the
old data and store new data into the local DB. On success the system will go to the next
activity
3.4.1.2 Select Vehicle
Figure 16 Sequence Diagram Select Vehicle Mobile App
Pg. 54

Upon successful login, the operator will be prompted to a simple menu (the application
GUI) where the user will select the check-in option. After selecting the user will be
taken to activity where he will select the vehicle type, this activity will get the fare of
the selected vehicle from the local DB and move to the next activity where parking is
added.
3.4.1.3 Add Parking
Figure 17 Sequence Diagram - Add Parking Mobile App
When the user selects the vehicle, add parking activity will appear prompting the
operator to enter the vehicle number. When the operator enters the vehicle number and
press the save button the first sequence is that it prints the e-ticket then saves the e-
ticket in the local DB and finally using an API saves the ticket to the cloud. If due to
fluctuation in the 4G connection, the user will be prompted but the record is
successfully saved into the local DB.
3.4.1.4 Reports - Daily Reports
Figure 18 Sequence Diagram Daily Report Mobile App
Pg. 55

The operator will select the report option from the main menu and then select the daily
reports option. Upon selecting the option the system gets the tickets and list of tickets
for that day is returned which is sent to the Bluetooth printer for printing
.
3.4.1.5 Reports Date Wise
Figure 19 Sequence Diagram Date Wise Report Mobile App
The other option in the report menu is the Date Wise option. This option is there if the
operator needs to het a report from that particular device for any back date or range of
dated. Upon selecting the option the operator will taken to a UI where he can enter date
range. The system checks the dates and returns a list of tickets which are then sent to
the Bluetooth printer for printing.
3.4.1.6 Synchronization
Figure 20 Sequence Diagram Synchronization Process Mobile App
Pg. 56

To run this activity the user must have the administrative rights. The user logins with
the admin rights and the sync activity will appear in the main menu, upon selecting this
option the sync activity will start. It gets all the tickets that are unmarked as sync. The
tickets are sent to the cloud and when the tickets are all synced, the tickets entry in the
local DB are marked as isSync.
3.4.2 Web Portal
The web portal is a very simple system, and no special training is needed to operate the
system. Any person who is well versed with web sites and internet can find the way
through the main menu to operate the system. The Admin Portal is developed using
ASP.Net MVC framework and for connectivity with the database, it uses the entity
framework DB First approach.
3.4.2.1 Login
Figure 21 Sequence Diagram Login Web Portal
When the system starts the user, is prompted with a login screen. Upon giving the
username and password the system verifies the credentials from the database and the
user is taken to the web portal GUI.
Pg. 57

3.4.3 Add Vehicles
Figure 22 Sequence Diagram Add Vehicles Web Portal
To add the vehicles types, the user clicks on the vehicle option is directed to the GUI
where the admin can perform CRUD operations i.e. Add, Edit and Delete the vehicles.
The system requests the vehicle detail and in response, the list of vehicles is returned.
The user can add a new vehicle type, and saves the changes. The vehicle will appear in
the main list. The user can perform the edit operation, the system will update the list
and display the changes made. The delete operation deletes the vehicle type and the
changes are displayed on the main screen.
3.4.4 Fares
Figure 23 Sequence Diagram Add Fares Web Portal
Pg. 58

However, the fares are homogeneous on all the sites, but sometimes the fare for a
particular location needs to be customized. For Example if at any parking site there is
an event and the authorities want to have that sited charged as free or charge
differently, the fare for that location can be changed. So the fares are associated with
the location and the type of vehicles. The CRUD operations are same, like upon adding
a fare the admin selects the parking location, selects the vehicle type, add the amount of
fare to be charged, and saves the changes. The edit operation is no different and the
delete operations are simple to delete the fare. The changes made here reflect in the
mobile devices upon fresh login.
3.4.5 Locations
Figure 24 Sequence Diagram Add Locations Web Portal
The Locations are defined by the Admin User, The CRUD operations are simple and
well defined. Like any other CRUD the system retrieves a list of operating sites. The
Admin can add a new Parking Location or site, Edit and Delete the same.
Pg. 59

3.4.6 Devices
Figure 25 Sequence Diagram Add Devices Web Portal
Registration of the devices are a part of the security system, so that misuse of devices
cannot be done. In the current system, the printed parking tickets are used which is very
prone to be misused as they can be printed fraudulently, and used. The security system
will prevent the misuse and even if the operator somehow gets hold of the apk file and
installs the system, the system checks for the registered device. These devises are
registered by the admin user before allotting a mobile device to the supervisor to be
used on the parking location. The CRUD operations are simple and well defined.
Pg. 60

3.4.7 Device Users
Figure 26 Sequence Diagram Add Device Users Web Portal
The Defining the device user is a very simple CRUD operation. The user selects the
option to add the device user, the list of the available users is displayed. The Admin
user ADD the user name which is usually a site name, allots a username and a
password and saves the data. The Edit and Delete operations are also very simple.
3.4.8 Web User
Figure 27 Sequence Diagram Add Web Users Web Portal
Defining the Web Users is also the same as defining the device users. The CRUD
operations are very simple.
Pg. 61

3.4.9 Reports – Date Wise
Figure 28Sequence Diagram Date Wise Report Web Portal
The date wise report is very simple report. The Admin user at any given period of time
can retrieve this report. The GUI is very simple. The user selects the dates and the
database returns a date wise report. A simple partial view is used to view the report.
The reports can be downloaded as a PDF file for further use.
3.4.10 Reports – Location Wise, Date Wise
Figure 29 Sequence Diagram Location Wise Reports Web Portal
Same the Date Wise report this report gets the location for which the report is
requested, then the date picker is used to enter the date range and the report is retrieved.
This report can also be downloaded in PDF format for record and analysis purposes.
3.5 Class Diagram
A class diagram is a static diagram. It represents the static view of an
application. Class diagram is not only used for visualizing, describing, and
documenting different aspects of a system but also for constructing executable
code of the software application.
Pg. 62

Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object-
oriented systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations,
and constraints. It is also known as a structural diagram.
Purpose of a Class Diagram
The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence
flow of the application, however class diagram is a bit different. It is the most popular
UML diagram in the coder community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
Pg. 63

Tickets
TicketID
Ticket_no
Date_Created
status_id
user_id
vehicle_type_id
time_in
time_out
isActive
LocationID
Amount
Location
LocationID
Name
IsActive
CreatedDate
CreatedBy
UpdateDate
UpdateBy
Vethicle_type
vehicle_type_id
name
status
CreatedDate
CreatedBy
UpdateDate
UpdateBy
Fares
FairID
LocationID
Vehicle_Type_ID
Charges
IsActive
UpdatedDate
UpdatedBy
CreatedDate
CreatedBy
User
UserID
RoleID
Username
Email
Password
Device
DeviceID
SerialNo
IsActive
LocationID
UserID
CreatedDate
CreatedBy
UpdateDate
Updateby
DeviceUser
UserID
Username
Password
LocationID
isLogin
Figure 30 Class Diagram
Class - User
Field Type
UserID Int
UserName String
Email String
Password String
This class is used to define the Web Users i.e. the users who will control the web
portal. The fields are self-explanatory.
Locations
• AdminPanelCntroller.cs
• UserControler.cs
Class – Device User
Field Type
UserID Int
UserName String
Password String
IsLogin Bool
This class will define the operators who will operate the mobile devices. The isLogin
field is of Boolean type, showing that whether the operator is active or not. The rest of
the fields are self-explanatory.
Pg. 64

Locations
• DeviceUserController.cs
• Index.cshtml (AreaManagementViewsDeviceUsers)
Class – Fares
Field Type
FairID Int
LocationID Int
Vehicle_type_id Int
Charges Double
IsActive Bool
CreatedDate Date
CreatedBy Int
UpdatedDate Date
UpdatedBy Int
The Fares class will be used to define the fares. This class has a relationship with the
Location and vehicle_type. The CreatedBy, CreatedDate, UpdatedBy and UpdatedDate
are check fields in case the something controversial arises regarding the definitions of
fares.
Locations - Areasvehicles
• FareController.cs (Controller)
• _Create.cshtml (Views)
• _Edit.cshtml (Views)
Class – Locations
Field Type
LocationID Int
IsActive Bool
Name String
CreatedDate Date
CreatedBy Int
UpdatedDate Date
UpdatedBy Int
The location class will be used to define the locations. The fields are very much easy to
understand.
Locations - AreasManagement
• LocationController.cs (Controllers)
Pg. 65

Class – Vehicle_type
Field Type
Vehicle_type_id Int
Status Bool
Name String
CreatedDate Date
CreatedBy Int
UpdatedDate Date
UpdatedBy Int
The vehicle_type class will be used to define the types of vehicle. The fields are very
much easy to understand.
Locations – AreasVehicles
• VehicleTypeController.cs (Controllers)
Class - Devices
Field Type
DeviceID Int
SerialNo String
IsActive Bool
LocationID Int
UserID Int
CreatedDate Date
CreatedBy Int
UpdatedDate Date
UpdatedBy Int
This class defines the Devices, The SerialNo is the serial number of the SIM module,
the locationID is the location on which the device is to be used. The other fields are
simple to understand.
Location – AreaManagement
• DeviceController.cs (Controllers)
Pg. 66

Class – Tickets
Field Type
TicketID Int
Ticket_no String
Date_created Datetime
User_id Int
Vehicle_type_id Int
Time_in Datetime
Location_id Int
Amount Int
The ticket class is the main class that controls the transections in this system, The
ticket_no is the vehicle number e.g. 8320 or 2392 etc. the Date_creates and Time_in are
the timings when a vehicle enters the parking site and the e-ticket issued. The amount is
the actual amount collected and the location_id is the id of the site where the vehicle is
parked.
Locations – AreaVehicles
• ReportController.cs (Controllers)
• SiteAndDateWiseController.cs (Controller)
• VehicleReport.cshtml (ViewsReports)
• VehicleReport.cshtml (ViewsSiteWiseDateWise)
Pg. 67

4 Development Plan
Architecture Diagram
Mobile Application
Figure 31Architecture Diagram Mobile App
Web Application
Cloud
Client Browser
Presentation Layer - Views (HTML, JS, CSS, Ajax)
Business Logic Layer - Controller (ASP.NET C# files))
SQL Sever - Model
Figure 32 Architecture Diagram Web Portal
Pg. 70

4.1 Mobile Application
4.1.1 Main Activity
Start
If IsOnline
NoYes Error Message
Get Bluetooth
printer
If Device
Coonected
Yes
No
Get Username
,Password and Sim
Number
API
If error
Json
Yes
Error Message
No
Get fares
Create DB,Create
Table fares and
Tickets and Role.
Delete any
previous info and
insert new fares
Json
Next
Activity
Local DB
Figure 33 Mobile Login
This is the main starting point where the system checks whether the internet
connectivity is active. Then the system checks for the Bluetooth connectivity and
availability of the Bluetooth printers. If both the conditions meet the criteria, the system
prompts the operator for username and password. The operator provides the username
and password and a call is made to the API. The API returns json result. If there are any
errors mismatch of username, password and the SIM number, the system will prompt
an error else the system will get the fares of the vehicles and create a localBD, create
tables Fares and Tickets, insert fare record. After the process, the system moves on to
the next activity.
Pg. 71

4.1.2 The Main Menu
Start
Istheuseradmin Yes
No
Adminmenu
OperatorMenu LogoutApiIfLogout
End
Checkin,Reports
Activities
Check-in,Reports
andSynchronization
Activities
Next
Activity
Next
Activity
Figure 34 Mobile app - Main Menu
After the operator or the admin user login, there are three to four options. The Check
In, Check Out (not functional) Reports, and the Admin Operation for Admin user. If
any of the users wants to logout, the logout process makes an API call and marks the
user inactive in the database.
Pg. 72

4.1.3 Selecting the Vehicle Type
Start
Get variables from
the previous activity
Get
fares
Local DB
If fares are null Yes Error Message
Check if the
vehicle is
available for the
Parking Site
No Prompt the user
Yes
Store necessary
variables
Next
Activity
Figure 35 Mobile App - Check In
In this activity the user, select the vehicle type for dispensing of the ticket. The activity
starts by getting the variable from the previous activity and the gets the fares for all the
vehicle types from the localDB. If due to any reason, the fares table us null the system
generates an error and the user is prompted to logout and login again. This gets the
fares from the cloud DB and stores in the Fare table of the local DB. Then the vehicle
for which the ticket is dispensed is selected. The system checks whether the vehicle
type is allowed on that parking site. This happens when the admin defines a site from
the portal, the admin needs to define the types of vehicles it will cater and their parking
rates. The check is that the operator be in the limits of dispensing tickets rather than
creating ambiguity for dispensing wrong type of tickets.
Pg. 73

4.1.4 Add Parking
START
GETS VARIABLE
FROM PREVIOUS
ACTIVITY
CHECK S FOR THE TYPE
SELECTED (SWITCH
STATEMENT)
CHECK S IF THE
CONNECTION TO BT
PRINTER IS OP EN
NO
Check if the Veh.
# is entered
No
Prepares the Ticket
Prints the Ticket
Check Internet
Connection
No
Yes API Call
Inset data
on Cloud DB
1
Error Message
Error Message
2
Pg. 74

Insert ticket
Info on
localDB
If Insert True Exception
Prompt the user but
no exception
No
1
Yes
Prompts the user for
successful Insertion
2
Figure 36 Mobile App - Add Tickets
In this activity, the operator dispenses the ticket. The activity start and checks for the
variable brought from the previous activity. Check the type of vehicle that was select
and checks for the printer connectivity as sometimes the printer gets disconnected due
to any reason line time off or distance more than 10 m etc. Then the user is prompted to
enter the vehicle number. If the number is empty, an error message appears, asking the
operator to reenter the number. The system then prepares the ticket i.e. gets the
graphics and necessary variables and then prints the ticket. Then the system checks the
internet connection and if the connection is ok, the system makes an API call, saves the
data on the net, and then saves the data to the tickets table in the localDB. If for any
reason the internet connection is not on, the system saves the data on the localDB and
prompts that the data has been saved but not synced to the internet. The system then is
again ready for the user to enter the data.
Pg. 75

4.1.5 Reports
Start
Get AllTickets LocalDB
Loop over the
number of tickets in
current date
Add all the ticket
count for each
vehicle and prepare
daily sale
Prepare Ticket
Print Ticket
End
Figure 37 Mobile App – Reports
In this activity, the operator prints the daily reports. The system gets the tickets from
the local DB, loops over the number of tickets available. Adds all the ticket count for
each vehicle. The system then prepares the ticket and sends the ticket to the printer
Pg. 76

4.1.6 Date Wise Reports
Start
Get AllTickets LocalDB
Loop over the
number of tickets in
Given dates
Add all the ticket
count for each
vehicle and prepare
daily sale
Prepare Ticket
Print Ticket
End
Figure 38 Mobile App - Date Wise Reports
In this activity, the operator prints the date wise reports. The system gets the tickets
from the local DB in a given range of dates, loops over the number of tickets available.
Adds all the ticket count for each vehicle. The system then prepares the ticket and sends
the ticket to the printer.
Pg. 77

4.1.7 Administration – Synchronization
Start
Is Internet
Connected
Yes
NO Error Meesage
Get AllTickets
for IsSync
If Cout>0 Prompt userNo
Yes
API Call
1
LobalDB
Pg. 78

1
Is Net Coonected Error Message
Yes
No
Save to Tickets
Table
Cloud DB
Json
Updatetickets
table
Loop for no of
vehicles found for
IsSync
IfIsErrorSync Error Message
Prompts a success
message
Yes
No
End
Figure 39 Mobile App - Sync Records
The admin operation contains two operations, the delete records and the sync data. The
sync operation. Due to the fluctuation in the 4G internet sometimes the data is not save
to the cloud database, but the data is not lost and saved in the tickets table of the local
db. To reconcile the revenue, and looking into the problem of un-synced data the
synchronization process is used. When the process starts it checks the internet
connectivity as it is must to have to send data to the internet. Then the process gets the
list of all tickets not marked as IsSync. If the count is zero the system prompts the user
that there are no records for synchronizing, else it starts a loop for the number of counts
not marked as isSync and makes an API call and saves the data on the cloud DB and
updates the localDB and marks the record as isSync. If there are no errors during
synchronization process the system prompts the user for a successful operation else
prompts for an error.
Pg. 79

4.2 Web Portal
4.2.1 Login and Dashboard
`
Figure 40 Web Portal - Login Screen
Figure 41 Web Portal - Dash Board
Pg. 80

Start
If Usernameand
password is null in
cookies
Yes
No
Enter Username and
password
If Usernameand
password exists
Dashboard View
Yes
No Error Message
Partial View of
Dashboard
Data from DB
Tickets
Username from
cookeies
The system starts and the checks if the username and the password is saved in the
cookies. If the null in cookies the system prompts the user to enter username and
password. If the cookies are present, the username and password are filled in the text
fields. The system then checks for the username and password. If the fields exist the
system displays the Dashboard view and data from the tickets table is shown on the
dashboard.
Pg. 81

4.2.2 CRUDs – Vehicles
Figure 42 Web Portal - CRUD Vehicles
Pg. 82

Start
Get List of
vehicles from
Vehicle table
Return View of
vehicle type list
Create Vehicle Edit Vehicle Delete Vehicle
Data Insert,
Update and
Deleted in DB
The user selects the Vehicle type to perform CRUDs on vehicles. The system starts by
calling the VehicleType controller and gets the list from vehicles from the vehicles
table of the DB. The system returns the view displaying the list of available vehicles
from the index.cshtml. The user can perform the CRUD operations in the Create, Edit
and Delete functions in the VehicleType controller. The system uses the Entity
framework to perform these operations.
Pg. 83

4.2.3 CRUDs – Fares
Figure 43 Web Portal - CRUD Fares
Pg. 84

Start
Get List of
Fares from
fares table
Return View of Fares
list
Create Fares Edit Fares Delete Fares
Data Insert,
Updateand
Deleted in DB
The user selects the Fares to perform CRUDs on Fares. The system starts by calling the
Fares controller and gets the list of fares from the fares table of the DB. The system
returns the view displaying the list of available fares from the index.cshtml of fares
view. The user can perform the CRUD operations in the Create, Edit and Delete
functions in the Fares controller. The system uses the Entity framework to perform
these operations.
Pg. 85

4.2.4 CRUDS – Locations
Figure 44 Web Portal - CRUD Locations
Pg. 86

Start
Get List of
Location from
Location table
Return View of
location list
Create Location Edit Location Delete Location
Data Insert,
Updateand
Deleted in DB
The user selects the location to perform CRUDs on locations. The system starts by
calling the Location controller from the Manager Area and gets the list of location from
the locations table of the DB. The system returns the view displaying the list of
available locations from the index.cshtml of Location view in the Area Manager. The
user can perform the CRUD operations in the Create, Edit and Delete functions in the
Location controller. The system uses the Entity framework to perform these operations.
Pg. 87

4.2.5 CRUDs – Mobile Devices
Figure 45 Web Portal - CRUD Mobile Devices
Pg. 88

Start
Get List of
Devices from
Devicetable
Return View of
Devicelist
Create DeviceInsert
Sim#
Edit Device Delete Device
Data Insert,
Update and
Deleted in DB
The user selects the Device option from the Management section to perform CRUDs on
devices. The system starts by calling the device controller from the Manager Area and
gets the list of devices from the devices table of the DB. The system returns the view
displaying the list of available devices from the index.cshtml of Devices view in the
Area Manager. The user can perform the CRUD operations in the Create, Edit and
Delete functions in the Device controller. The system uses the Entity framework to
perform these operations.
Pg. 89

4.2.6 CRUDs – Devices Users
Figure 46 Web Portal - CRUD Device Users
Pg. 90

Start
Get List of
DeviceUsers
from Device
User table
Return View of
DeviceUser list
Create DeviceUser Edit Device User Delete DeviceUser
Data Insert,
Updateand
Deleted in DB
The user selects the Device User option from the Management section to perform
CRUDs on Device Users. The system starts by calling the Device User controller from
the Manager Area and gets the list of Device Users from the Device Users table of the
DB. The system returns the view displaying the list of available Device Users from the
index.cshtml of Device Users view in the Area Manager. The user can perform the
CRUD operations in the Create, Edit and Delete functions in the Device User
controller. The system uses the Entity framework to perform these operations.
Pg. 91

4.2.7 Reports - Datewise
Figure 47 Web Portal - Reports
Pg. 92

Start
Return View with
Dates From and To
Gets List of
Vehicles
Time_in wise
Return View of all
vehicles date wise
The user calls the Reports by selecting the type of dates from the main menu the date
wise report displays the reports on date-to-date basis. The system calls the report
controller and display the view for the user to enter the date range. As the date ranges
are entered, the system calls the Vehicle Report function of the ReportController and
gets the list of vehicles date wise. The view is displayed by the VehicleReport.cshtml in
ViewReport folder in Vehicles area.
Pg. 93

4.2.8 Reports – Datewise and Location Wise
Figure 48 Web Portal - Reports DateWise Location Wise
Pg. 94

Parking Revenue Management System

Parking Revenue Management System

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Parking Revenue Management System

Similar to Parking Revenue Management System (20)

Recently uploaded

Recently uploaded (20)

Parking Revenue Management System