SPMS Final Documentation

SPMS
SMART PARKING MANAGEMENT SYSTEM
SESSION: 2013-2017; GROUP ID: G-15
PROJECT SUPERVISOR
Mian Muhammad Munir ud Din
GROUP MEMBERS
Khubaib Muzammal 2013-I-259 9849/988
Hassan Naveed 2013-I-216 9843/940
M. Umer Arif 2013-I-224 9785/948
A DOCUMENTATION SUBMITTED IN PARTIAL FULFILLMENT OF

THE DEGREE OF BS HONOURS IN INFORMATION TECHNOLOGY
FROM
DEPARTMENT OF COMPUTER SCIENCE,
GOVT. ISLAMIA COLLEGE, CIVIL LINES, LAHORE
AFFILIATED WITH UNIVERSITY OF THE PUNJAB, LAHORE
CERTIFICATE
This is to certify that Khubaib Muzammal (Roll No. 9849/988), Hassan Naveed (Roll No.
9843/940) and M. Umer Arif (Roll No. 9785/948) members of group no. 15 have worked on and
completed their software project at Govt. Islamia College, Civil Lines, Lahore affiliated with
University of the Punjab, Lahore in fulfillment of the requirements for the degree of BSIT under
my guidance and supervision.
In my opinion, it is satisfactory and up to the mark and therefore fulfills the requirements of BS
Information Technology.
MIAN MUHAMMAD MUNIR UD DIN

HEAD,
DEPARTMENT OF COMPUTER SCIENCE,
GOVT, ISLAMIA COLLEGE CIVIL LINES, LAHORE
Accepted By:
___________________
(For Office Use Only)
I
“AND HOLD FIRMLY TO THE ROPE OF ALLAH TOGETHER AND DON’T
BECOME DIVIDED”
DEDICATION
This work is dedicated to our supervisor, Sir Munir ud Din without his caring support it would
not have been possible. Who gave us the new concepts and methods to complete the project,
without his effort we would have never complete our project within a given deadline from
University and specially dedicated to memory of our parents. They have never failed to give us
financial and moral support, by giving all which we needed during the time we studied and
developing our system and for teaching us that even the largest task can be accomplished if it is
done one step at a time, who passed on a love of reading and respect for education, all group
members also cooperated with each other to complete this project in time, and many relatives
and friends who prayed for our success.
II
ACKNOWLEDGEMENT
Up and above, everything, all appreciation to Allah Almighty, the compassionate and merciful,
Who enabled us to elucidate a drop from the existing ocean of knowledge, countless salutation
be upon the Holy Prophet Muhammad (Sallallaho Alaihe wa Aalehi Wassalam), the city of
knowledge, Who has guided our “Ummah” to seek knowledge from cradle to grave.
We truly acknowledge the cooperation and help given by Project CS department, GICCL. It has
been a constant source of guidance throughout the course of this project. It is quite delectable
and to becoming to avail of this most propitious opportunity to articulate with utmost
gratification, our profound and intense sense if indebtedness to our affectionate Supervisor, Prof.,
Lecturer, Govt. Islamia College Civil Lines Lahore. Their proficient counseling, valuable
suggestions, boundless forbearance, indefatigable help with anything, anywhere, anytime,
consummate advice and thought-provoking instruction in piloting this project. Special thanks for
department would always be due.
We express our thankful feeling to our friends and families whose silent support led us to
complete our project.
1- Khubaib Muzammal
2- Hassan Naveed
3- M. Umer Arif
III
Table of Contents
ABSTRACT ............................................................................................................................................... VI
PROJECT PROPOSAL............................................................................................................................. 1
1. Introduction ........................................................................................................................................ 1
2. Literature Review ............................................................................................................................... 2
3. Methodology.......................................................................................................................................... 4
INTRODUCTION & BACKGROUND.................................................................................................... 6
1.1 Project Overview Statement .......................................................................................................... 6
1.2 Introduction to SPMS ........................................................................................................................ 6
1.3 Problem Statement ............................................................................................................................. 7
1.4 Product Function ................................................................................................................................ 8
1.5 Feasibility Study ................................................................................................................................. 9
1.6 Background ....................................................................................................................................... 11
1.7 Operating Environment ................................................................................................................... 12
1.8 Tools and Technologies/Languages................................................................................................. 12
REQUIREMENTS GATHERING & PLANNING ............................................................................... 13
2.1 Functional Requirements ................................................................................................................. 13
2.2 Non-Functional Requirements ........................................................................................................ 14
2.3 System Requirements ....................................................................................................................... 15
2.4 Gantt Chart ....................................................................................................................................... 16
Analysis & Design ..................................................................................................................................... 17
3.1 System Architecture ......................................................................................................................... 17
3.2 Data Flow Diagrams ......................................................................................................................... 17
3.3: Use Case Modeling ............................................................................................................................ 19
3.4 Domain Model..................................................................................................................................... 35
3.5 State Diagram ..................................................................................................................................... 36
3.6 Sequence Diagrams .......................................................................................................................... 37
3.7 Class Diagram ..................................................................................................................................... 51
3.8 Database Diagram: .......................................................................................................................... 52
3.9 Data Dictionary: ................................................................................................................................. 53
3.10 User Interface Design ..................................................................................................................... 57
IMPLEMENTATION .............................................................................................................................. 69
TESTING & RESULTS ........................................................................................................................... 75
5.1 Project Test Plan: ............................................................................................................................. 75
5.2 Test Cases .......................................................................................................................................... 79
IV
SYSTEM EVALUATION........................................................................................................................ 86
CONCLUSIONS & FURTHER WORK ................................................................................................ 88
USER GUIDE ........................................................................................................................................... 90
8.1 User Guide Contents .......................................................................................................................... 90
8.2 Detailed Description of User Guide .................................................................................................. 90
BIBLIOGRAPHY..................................................................................................................................... 94
APPENDICCES........................................................................................................................................ 95
V
ABSTRACT
In recent times, parking management influences drivers search time and cost for parking spaces,
parking revenue, and traffic congestion. In this project, we study state-of-the-art parking policies
in smart parking management systems (SPMS), and show that the smart parking system needs to
be “smarter”. Our design goals of the smart parking systems include: Simplify the operations of
parking systems, improve drivers’ satisfaction, increase parking revenue, and alleviate traffic
congestion without the use of hardware resources. We then model the behavior of both service
providers and drivers in smart parking systems, and explore the dynamic pricing scheme (per
hour) besides static (per day) to achieve the goals in smart parking system design. Furthermore,
we design and implement a prototype of Smart Parking System that automatically allots a
specific parking slot for a vehicle from the available slots as well as provides the functionality of
manual slot allocation. The System also provides the functionality of storing records of incoming
and outgoing vehicles and later on checking reports like strength and revenue in the form of
statistics and charts.
VI
Project Proposal
PROJECT PROPOSAL
1. Introduction
The concept of Smart parking management system (SPMS) highlights the standard of shopping
malls, schools, multi-national Companies which are one of the most important features of any
type of company. This paper focuses on the less man power and an automated system.
In our solution, as the car will enter and exit the parking lot, the records will be maintained in the
log file of the service provider. System will check and allot a specific slot from free slots to each
vehicle at the time of entry, so as to make an easy parking instead of searching for the parking
slot, which may lead to traffic congestion. Each parker will be provided a slip upon entry into
parking lot on which vehicle (car) detail (i.e. registration no. etc.), arrival time and allotted slot
are displayed. All this process is automatic except the service provider has to enter registration
number.
Data maintained by the SPMS in the form of logs includes vehicle details, in-time and out-time
of the vehicle, total stay time (i.e. total time between in-time and out-time), which is done at the
time of entry and exit of vehicle automatically.
The parker will check out (pay the price) at the time of exit so at that time software will store
out-time and total stay time. The system will provide the option of static as well as dynamic
pricing. The system will provide the option of subscription (monthly/quarterly/half-year/yearly)
payment to accommodate parkers that park on daily basis.
The system in question i.e. SPMS aims to provide a low cost, easy, simple implementation
catering the needs of medium level parking operators by eliminating the need of hardware,
without compromising on performance. It integrates many of the features provided by different
Govt. Islamia College, Civil Lines, Lahore 1

Project Proposal
systems into single software. Once the system is implemented successfully it can be later
extended to other robust features as the need arises and resources allow so.
2. Literature Review
Currently there are different type of parking software with different functionalities are available
in the market. A short review of those systems (functions, tools and technologies) is presented
below.
Traffic Tech (Gulf): Car Park Equipment & Management Systems
• Parking Guidance Systems
• Valet Parking System - Smart ValetTM
• On-Street Parking Control Systems
- Parking meters and pay & display
• Integration of access control and security features such as “Automatic Number Plate
Recognition (ANPR)”, “Radio Frequency Identification (RFID)”, “CCTV Surveillance”,
and others
• Traffic Barriers
• Electro-mechanical / Hydraulic / Manual Bollards
• Signage of Parking Areas
• Operation and Maintenance [1]
The SKIDATA Solution
• Violation processing: enterprise level or off-the-shelf
• Meter, sensor and off-street revenue collection systems

Project Proposal
• Advance data analytics, supported by data scientists and subject matter experts, including
data-driven decision-making
• Operations powered by Conduent Merge® Parking Management System
• Managed receivables and collections, including innovative payment plans [2]
Web Parking Software
• Full Parking Management System for any size building
• Issue professional parking permits
• Assign parking spaces for tenants
• Allocate guest parking and special event parking
• Ticket Violators
• Process and Pay fines online
• Track and manage all properties, occupants and tenants [3]
PermitTech: Parking Permit Management Software
This system takes a different approach by introducing different types of permits and managing
parking accordingly.
Different types of permits include residential permits, merchant permits, city employees, bulk
permits, visitor permits, temporary permits, car pools,
Some functional characteristics are as follows
 Set-up, update a variety of permit types in multiple locations/ zones, permit series
number ranges
 Set-up, add to, and remove from wait lists
 Issuance of new and renewal permits
 Sell/transact payments of new and renewal permits

Project Proposal
 Maintain a history of all permit transactions entered into the system. Entries are
automatically date/time-stamped and available for the user to display and review [4]
A review of all these systems makes it clear that some features are overlapping, while many of
these are too much expensive and most features offered thereby are of no need to medium sized
parking operators. Our SPMS aims to provide a low cost, easy, simple implementation catering
the needs of medium level parking by eliminating the need of hardware, without compromising
on performance. It integrates useful features provided by different systems into single software.
Once the system is implemented successfully it can be later extended on to other robust features
as the need arises and resources allow so.
3. Methodology
The work of the system starts at the entry of car, when a car reaches the parking, parking
attendant will type the registration no. of vehicle in the system, then the details will be printed on
slip which will be given to parker and will also be stored in the database. Besides storing the
registration number system will also record in-time of car in the database. The system will also
automatically allot a specific slot to each car. The system will assign slots in an order by simply
incrementing slot no. each time. The in-time and allotted space will be printed on slip along with
detail of car as well as stored in the database along with record of car. The system has also option
of giving choice to attendant to allot specific slot.
The system will store logs for each car in the parking with the above mentioned details. The logs
will be in the form of list in which each entry corresponds to a vehicle parked in the lot. The
details of any car can be viewed by opening the relevant list item. The system will also show
total no. of slots, available/free slots and reserved/filled slots in form of counters.

Project Proposal
At the time when a car leaves the parking the check-out process will be executed. The car driver
will return the slip to parking attendant along with the parking fee. The parking attendant will
then enter the relevant slot and will proceed to check-out upon which out-time and total stay time
will be calculated and the entry for that vehicle will removed from the current status grid view of
the software.
As it is usually seen, that some people park cars on daily basis in parking, because they might be
working in a nearby office, or because of some other reason. The system accommodates such
parkers by offering them option of monthly payment by opening an account for them. In this
process, the parker will pay parking fee in advance for the whole month, quarter of year, half
year or whole, an account will be opened in the system for such a parker in which payment
record will be stored and in this way parker will be saved from process of paying daily. At end of
the month the balance will be zeroed and parker will have to pay for next month again.
As mentioned earlier in the introduction the system also provides functionality of dynamic
pricing optionally the out time and stay time will help system calculate the fee of parking base on
the total stay time e.g. if we charge 3 rupees for one hour and a parker parks the car for 8 hours
the system will calculate 24 Rs based on the total stay time generated.
 References
1. Traffic Tech (Gulf) W.L. L. Parking Management Systems. (n.d.). Retrieved from
www.traffic-tech.com/pdf/Parking_Management_Profile.pdf
2. SKIDATA. (n.d.). Retrieved from https://www.skidata.com/en/business-areas/parking-

operators/
3. Web Parking Software Cloud Based Parking Solutions. (n.d.). Retrieved from
http://www.webparkingsoftware.com/
4. Smart Parking. (n.d.). Retrieved from https://www.smartparking.com/

Chapter 1 Introduction & Background
CHAPTER 1
INTRODUCTION & BACKGROUND

1.1 Project Overview Statement
The objectives we target are:
• To maintain parking data
• Parking space/slots management
• Pricing management(Dynamic/Static)
• View reports and statistics
1.1.1 Project Success Criteria:
We will consider our project successful if we make a Smart Parking Management System
Desktop Application (C#.Net) that meets requirements.
1.2 Introduction to SPMS

The SPMS presents a solution where we manage parking function in computerized environment.
Our project contains following primary functionalities
 Check In
 Check Out
 Slot Allocation (automatic, manual)
 Logs (old records)
 Reports (daily, monthly, yearly)
 Subscriptions
 Pricing schemes (dynamic\static pricing rates).
As the car enters and exits the parking lodge the records are maintained in the log file of the
service provider. System checks and allots a specific slot from free slots to each vehicle at the

time of entry, so as to make an easy parking instead of searching for the parking slot, which may
lead to traffic congestion. Each parker will be provided a slip upon entry into parking lot on
which vehicle (car) detail (i.e. registration no., owner etc.), arrival time and allotted slot are
displayed. All this process is automatic except the service provider has to enter registration
number.
Data maintained by the SPMS in the form of logs includes vehicle details, in-time and out-time
of the vehicle, total stay time (i.e. total time between in-time and out-time) and number of time
the vehicle visited the parking area which is done at the time of entry and exit of vehicle
automatically.
The parker will check out (pay the price) at the time of exit so at that time software stores out-
time and total stay time. The system provides the option of static (per day) as well as dynamic
(per hour) pricing. The system will provide the option of monthly payment to accommodate
parkers that park on daily basis.
1.3 Problem Statement

At present there are varying parking management systems with some over-relying on hardware
infrastructure, some only offering ticketing and violations management while some offering
mobile applications for pre reservation and easy payment methods. Seldom has a system
provided all these features at the same time. A review of all these systems makes it clear that
parking systems offer varying features with some features overlapping, while many of these are
too much expensive and most features offered thereby are of no need to medium sized parking
operators. Our SPMS aims to provide a low cost, easy, simple implementation catering the needs
of medium level parking by eliminating the need of hardware, without compromising on
performance. It integrates useful features provided by different systems into single software.

Once the system is implemented successfully it can be later extended on to other robust features
as the need arises and resources allow so.
1.4 Product Function

The system work starts at the entry of car, when a car reaches the parking; parking attendant will
type the registration no. of vehicle in the system. The record will then be used to print the
information on slip and will also be stored in the database. Besides storing the record of vehicles
the system will also record in-time of car in the database. The system will also automatically
allot a specific slot to each car. The system will assign slots in an order by simply incrementing
slot no. each time or it will provide attendant the option to allot slot manually. The in-time and
allotted space will be printed on slip along with excise detail of car as well as stored in the
database along with record of car.
The system stores logs for each car in the parking with the above mentioned details. The logs are
in the form of list in which each entry corresponds to a vehicle parked in the lot. The system also
shows total number of slots, available/free slots and reserved/filled slots. At the time when a car
leaves the parking the check-out process will be executed. The car driver will return the slip to
parking attendant along with the parking fee. The parking attendant will then select type of
vehicle and enter relevant slot number and will then proceed to check-out upon which out-time
and total stay time is calculated and the entry for that vehicle is removed from the grid view
showing currently parked vehicles.
Some people park cars on daily basis in a parking because they might be working in a nearby
office, or because of some other reason. The system accommodates such parkers by offering
them option of monthly payment by opening an account for them. In this process, the parker will
pay parking fee in advance for the whole month, quarter of year, half year or whole, an account

will be opened in the system for such a parker in which payment record will be stored and in this
way parker will be saved from process of paying daily. At end of the subscription term the
parker will have to pay again to renew subscription. Special offers can be offered to such parkers
such as discounted fee.
As mentioned earlier in the introduction the system also provides functionality of dynamic
pricing optionally the out time and stay time will help system calculate the fee of parking based
on the total stay time e.g. if we charge 3 rupees for one hour and a parker parks the car for 8
hours the system will calculate 24 Rs based on the total stay time calculated.
1.5 Feasibility Study

1.5.1 Technical Feasibilities
The language used in this software is C# which is part of .Net platform. For the development of
this project structure we will use different tools like Visual studio, SQL server which are easily
available in the market. This Project is feasible as we have all resources that are necessary. The
required tools and team effort will make it possible to accomplish the project.
1.5.2 Economical Feasibilities
Economically the project is reasonable. This software can easily be engineered using the already
available tools in the software market. Most of the tools are freeware software. Our software can
be deployed at any sort of organization at a reasonable cost, because it has been built according
to market situation where less money can be applied to get full use of it. The project has some
characteristics such as low budget software building and less man power required these
characteristics will make this software economically feasible and cost effective.

1.5.3 Schedule Feasibilities
To complete this project assets and appropriate time have been spent. Project is divided into
work breakdown structure to complete within given time. Tasks are then divided into all group
members to complete it in a systematic approach, within the time limit. Our Software will be
built through stages
• Initialization Stage
• Intermediate Stage
• Finalization Stage
Initialization stage consists of Dashboard and “Check In” and “Check Out” functionalities. The
intermediate stage consists of subscription and logs features. Finalization Stage consist of
Reports Forms and Compilation of Our Software.
1.5.4 Operational Feasibilities
SPMS is desktop based application for managing parking operations. The development process
of software is well feasible because we have all resources software as well as hardware needed.
We are providing a user-friendly infrastructure to perform actions on it. It will provide easy
control to the user. Application GUI is easy to use for everyone. Usability is an important feature
of this application. Our software has a good performance. It can perform all operations at good
speed and can perform well under heavy load.
The application will require following resources:
• A Database management system
• An Integrated development environment
All these resources are easily available for development online. They are mostly freeware
software.

1.5.5 Legal and Ethical Feasibilities
Our Software does not contain any un-ethical or vulgar content. It does not hurt sentiments of
any culture, person or religion. It does not evoke any legal issues neither it does contain any
pirated materials. If any freeware resource used in the project references have been given.
1.6 Background
We have studied different systems and there features in literature review, a careful study tells us
that they offer slightly different objectives, while many of these are too much expensive and
most features offered thereby are of no need to medium sized parking operators. Our SPMS aims
to provide a low cost, easy, simple implementation catering the needs of medium level parking
by eliminating the need of hardware, without compromising on performance.
1.6.1 Existing System in intended Organization
In IT Tower
 There is no computerized system.
 There is no system of storing parking records.
 There is no slot allocation mechanism.
 Manual ticketing system.
A) Drawbacks of existing system
The company cannot maintain the daily basis of parking records without computerized system.
The manual system cannot tell the exact value of revenue being generated by a parking lot. There
is no a slot allocation mechanism system due to which user faces difficulty to park the vehicle. In
manual parking system they cannot track number of vehicles parked at any time and many such
indicators. Moreover reports about total number of vehicles visits in a specific time span i.e. day,
month year cannot be checked.

1.6.2 Smart Parking Management System
We aim to provide a computerized solution to the target organization that has the capacity to
manage parking functions more smoothly and efficiently besides providing many more benefits
which are not possible in simple manual or paper systems.
Data maintainability is the main feature any parking company would like to have because it
provides many useful functions such as security, viewing reports etc. Moreover slot allocation is
another primary feature we are covering; the software provides option of manual as well as
automatic slot allocation.
Pricing and receipt management is another feature covered by this software per hour as well as
per day pricing schemes are offered. Hence the software provides many useful features that will
help organization grow at a better pace.
1.7 Operating Environment

The expected operating environment of the SPMS (Smart Parking Management System) is
through Windows 7 to Windows 10 any edition (32-bit, 64-bit).
1.8 Tools and Technologies/Languages

The tools and technologies which are used in making this software are listed below:
• C#
• SQL
• SQL Server 2012
• Visual Studio 2015

Chapter 2 Requirements Gathering & Planning
CHAPTER 2
REQUIREMENTS GATHERING & PLANNING

2.1 Functional Requirements
• Parking data maintenance (logs)
• Slip Issuance
• Parking space/slots management.
• Pricing management (Dynamic/Static)
• Generate reports and view statistics
Detailed overview of these functional requirements is as follows
Data Maintenance:
Data maintenance is important thing in any type of software where our old parking records are
saved in database and we can find old record later on from logs window. We can find the
particular date records through filter.
Slip Issuance:
As the vehicle enters in the parking area the parking receipt will be given to the customer which
includes some details i.e. slot#, registration#, entry date/time, charges etc.
Slot Management:
Slot management has an importance in our parking software, two types of slot management
options are available.
 Automatic
 Manual

Automatic slot management means the software automatically allocates the slot to the customer
whereas in manual slot allocation the parking attendant has the facility to allocate the slot to the
customer wherever he chooses.
Pricing Management:
The pricing management has two types of pricing in it
 Dynamic (per hour)
 Static (per day)
Dynamic pricing means the pricing strategy of parking should be of per hours pricing whereas in
static pricing means the pricing strategy of parking area should be of full day pricing.
Reports:
Reports section gives us facility to view statistics about parking such as
 Strength reports
 Revenue reports
Statistics are also shown in the form of charts and graphs.
2.2 Non-Functional Requirements

2.2.1 Performance
• The system can provide automatic service of parking and calculating charge.
• The response time of the whole system would be minimal.
• Perform under any condition.
2.2.2 Reliability
The system is reliable and data is not lost if failure happens. The system will recover from a
failure after restart.

2.2.3 Usability
Operators can easily learn how to use it. He can even use the system without training with some
effort. Interface is user friendly.
2.2.4 Safety
The only authorized attendant will use software.
2.3 System Requirements

2.3.1 Hardware Specification
Processor: Intel (Dual Core or above)
RAM : 1 GB (or above)
Hard disk: 80 GB (or above)
2.3.2 Software Specification
Operating System: Windows 7 (Or above)
Development Tool: Visual Studio
Database: Microsoft SQL Server

2.4 Gantt Chart
Figure 2.1: Expected schedule for “Smart Parking Management System”

Chapter 3 Analysis & Design
CHAPTER 3
ANALYSIS & DESIGN

3.1 System Architecture
Corresponding
GUI
BLL
DAL
Figure 3.1: System architecture of “Smart Parking Management System"
3.2 Data Flow Diagrams

Here we present our software’s Dataflow Diagram:
DFD level 0
View Reports Generated Reports
Subscribe Subscription
Logs View Logs
CheckOut
CheckedOut
Attendant Attendant
CheckIn SPMS CheckedIn
Figure 3.2: Abstract DFD level 0

DFD Level 1:
Add Subscriber Details
Subscribed
Subscription
Check Logs
Logs
Show Status ,Show Counter, Map
Home
Log Details Update
Map
CheckIn Details in Database

Update
CheckIn Credentials CheckIn
Status
Update
CheckOut
Give Slot# Counter
Slot is Free
Figure 3.3: Detailed DFD level 1

3.3: Use Case Modeling

3.3.1: SPMS Use Case Diagram
Figure 3.4: Overall functionalities available in “Smart Parking Management System”

3.3.2 Software Use Case Description:
Use Case Name:

 Check In (Auto)
Figure 3.5: Checkin auto function
Brief description
In this use case, when a vehicle enters parking area. Parking attendant of parking area will have a
look at its number plate vehicle, select type in software and enter registration number.

Precondition
No action performed by parking attendant as pre condition.
Basic flow
When any vehicle enter in parking area. The parking attendant will see vehicle number plate.
Enter its type and enter its registration number .The information is then stored in storage area of
our software.
Flow of events:
1. Select Vehicle Type
2. Enter Registration No
3. Click Check In Button
Alternate flows
If attendant enters registration no. in wrong format. Error message is shown.
Post conditions
Information is successfully stored in database.

 Use Case Name: CheckIn (Manual)
Brief description Figure 3.6: CheckIn manual function
In this use case, when any vehicle enters parking area. Parking Attendant of Parking Area will
see Vehicle. Select type in software. And enter registration number.
Precondition
No action performed by parking attendant as pre condition.
Basic flow
As the vehicle enter in parking area. The Parking Attendant will see vehicle number plate. Enter
its type, registration number, and slot number to allocate. The information is then stored in
storage area of our software.

Flow of events:
1. Select Vehicle Type
2. Enter Registration No.
3. Enter Slot No.
4. Click Check In button
Alternate flows
If attendant enters registration no. in wrong format, error message is shown.
Post conditions
Information is successfully stored in database.
 Use Case Name: Print Receipt
Figure 3.7: Print receipt

Brief Description
As the vehicle enter in parking area. The attendant will enter vehicle credentials and click check
in button. After clicking button a receipt will be generated with complete details about vehicles
including its registration number, date time in, date time out as well as price is printed on receipt.
Preconditions
Before this an attendant will have to complete “Check In” process.

Basic flow
When Attendant enter registration number and then click button. After clicking button this
information generated on slip/receipt and soon receipt prints.
Alternate flow
If the user does not want to print he can cancel.
Post conditions
Receipt is printed successfully.
 Use Case Name: Check Out
Figure 3.8: Checkout functionality
Brief Description
The main purpose of this use case is to remove vehicle details from software grid view
temporarily but in reality will data will be updated backend.
Precondition
Vehicle is “Checked In”.

Basic Flow
When a vehicle (i.e. car or bike) will leave parking area, then attendant first clicks on
“CheckOut” button. A new checkout window is open in which two things must be essential. First
one is to select type of vehicle type (Whether it is Car or Bike) and then second one is its slot
number which it leaves. When these two things are successfully provided to software by
attendant, then attendant clicks on a button in this window. Which is named “Proceed To
Checkout”. By clicking this button Vehicle Successfully Checkout.
Alternate Flow
If wrong procedure is followed error message shown.
Post Condition
Vehicle is successfully checked out.
 Use Case Name: Check Logs
Figure 3.9: Check logs

Brief description
Logs check contains the old records related parking details. This use case is very helpful for
attendant who can easily see the old record.
Preconditions
Vehicles should be check in beforehand.
Basic flow
In our home screen a button whose name is “Logs”. The attendant clicks on the button. A new
window is opened that contains old records of vehicles. There are two date time pickers shown
on this window. One picker name is “From” and other picker name is “To”. In “From” picker we
enter date of starting date from which you want to see records and In “To” picker we enter finish
date to which you want to see records
Alternate flow
No records shown if wrong filter chosen.
Post conditions
No post condition.

 Use Cases (Subscription Related)
Figure 3.10: Subscription (view, add, edit, delete) functionalities
Subscription section is covered by 4 use cases.
1. View Subscriber
Brief description
The purpose is to see subscribers.
Precondition
Subscribers are already available.
Basic flow
The main purpose of View Subscriber is that parking attendant will be able to see the records of
Subscribers. When he clicks on “Subscription” button in main window a new window is open
and he will be to see the complete details of subscriber.
Alternate flow
Empty grid view shown.

Post condition
Attendant will easily see the ‘subscribers’ records.
2. Add Subscriber
Brief Description
The main purpose of this use case is to provide facility to those customers who park daily. We
will provide the opportunity to create their accounts by entering their necessary details like
name, guardian Name, ‘CNIC’, address, vehicle type and as well as vehicle registration number ,
subscription type and amount etc.
Precondition
No precondition required.
Basic Flow
For this purpose Attendant will first Click on Subscription button that shown button right of the
page. When he will click on this button a new window is open on screen. In this window
attendant will see “Add Subscribe” button on top left of screen. By clicking this button a new
subscription form is open. In this form attendant will enter the complete details upcoming
subscriber like its name, its guardian name, its ‘CNIC’, its address, its vehicle type and as well as
its vehicle registration number , subscription types and amount etc. And then Click Submit
button to save these complete details in DB.
Alternate Flow
If wrong credentials are entered error message can be shown.
Post Condition
Such customer becomes Subscriber.

3. Edit Subscriber
Brief Description
The main purpose of this use case is to provide facility to our subscriber that they will change
their account details in some circumstances. Some necessary details like their vehicle type
change / update their new vehicle type, similarly change their address/ update their new address,
similarly update contact no and so on.
Precondition
Before this we add its account details in our software.
Basic Flow
When attendant start software. He will be able to see “Subscription” button on bottom right of
the main window. When attendant click this button a new subscription window form is open. In
this window form he will see existing subscriber details. On each subscriber details he will see
“Edit” button. By clicking on this button a new window will open up. In this window form he
will update subscriber’s desired details and then click “Submit” button.
Alternate Flow
If wrong credentials entered error message shown.
Post Condition
After this subscriber details are successfully updated according to its needs and desire.
4. Delete Subscriber
Brief Description
If any subscriber is not interested in our services and he wants to “Un-Subscribe”. So we provide
facility to delete its account details.
For this purpose we delete its account.

Precondition
Before this we should create its account.
Basic Flow
An attendant first Click on Subscription button. A Subscription window is open. In this window.
Attendant will be able to see the Records of Existing Subscribers. On each Subscriber he will see
“Delete” Button. If desired Subscriber want to be unsubscribe An attendant first Selects it’s
account details and press “Delete” button.
Alternate Flow
If user choses cancel button from prompt confirmation then record is not deleted.
Post Condition
After this Such Subscriber will be successfully Un-subscriber.
 Use Case Name: Reports
Figure 3.11: View reports
Brief description
Attendant or management can see reports i.e. statistics in form of figures and charts.

Precondition
Records should exist
Basic flow
The user clicks “Reports” button from main window. Reports window is shown with two options
where i.e. “Strength Report” and “Revenue Report”. Then he selects one of those options then
report is generated in new window that contains many different options for timespan of reports.
Alternate flow
No alternate available.
Post condition
Report is generated and shown to user.
 Use Case Name: Slot Allocation Setting
Figure 3.12: Slot allocation settings

Brief Description
The main purpose of this use case is to set settings to assign a slot to vehicle i.e. by using
software automatically or by using the guidance of parking attendant manually. In software we
generally set two types of slot allocation setting “automatic” and “manual”.
Precondition
There is no pre-condition.
Basic Flow
When a vehicle enters the parking area, attendant first checks in it. In our software we provide
two types of slot settings. First one is automatic and second one is manual. It will depend upon
attendant which setting he chooses for slot allocation (automatic / manual). In our software
“configuration” menu bar is shown on top of scre en. When attendant open it a pop-up
window is shown on screen select type of slot allocation setting, one option is selected from two
and then click save button to save this setting successfully.
Alternate Flow
Any alternate flow is not available for this.
Post Condition
If you choose “automatic” slot allocation setting, then software automatically assign free slots to
vehicles but if you choose “manual” slot allocation setting then in case attendant provide
guidance to customers to park their vehicles on free slot.

 Use Case Name: View Slot Data from Map
Figure 3.13: View slot data from

map
Brief Description
An attendant will be able to see the filled slot details. Simply mean that he will click on filled
(red) slot to view parked vehicle details.
Precondition
Slot should already be filled.
Basic Flow
When vehicle comes in parking lot. An attendant must check in first. After check in its detail go
in grid view and as well as in map to corresponding that Slot Number on which its park. So it is
easy way for attendant that he can be able to see particular slot detail on which that vehicle park.
Alternate Flow
No Alternate available.
Post condition
An attendant must easily see slot details from map.

 Use Case Name: Rate Setting
Figure 3.14: Rate settings
Brief Description
The main purpose of this setting is to set parking rates (dynamic/static). From which method we
can get parking charges. Here in our software there are two standard types of parking rates i.e.
static rates and dynamic rates.
Precondition
Attendant will be able to select first type of Price.
Basic Flow
In our Software a “Configuration” menu shown on top of software. When attendant clicks rates
from configuration’s sub menu. A new Pop-Up window shows up on screen. In which attendant
set rates of parking (like Dynamic / Static). A “Save” button show on below pop-up Window.
After click this button the desired rates are saved.
Alternate Flow
There is no alternate Flow is available.
Post Condition
After clicking on save button rates is being successfully updated

3.4 Domain Model
Figure 3.15: Domain model of Smart Parking Management System

3.5 State Diagram
Figure 3.16: State diagram of Smart Parking Management System

3.6 Sequence Diagrams
CheckIn Auto
User : Attendant GUI : Main DB : MS SQL Server
Select Vehicle Type
Elements shown for entering CheckIn credentials
Enter Registration No
If Subscribed == True
Click Subscribed Button
Enter Account Number GUI : Receipt
Click CheckIn Button
Save Record
Record Saved
Successfully CheckedIn
Show data in gridview, update counter & map
Open Receipt Window
Receipt Window Opened and Receipt Shown
Figure 3.17: CheckIn auto

CheckIn Manual
User : Attendant GUI : Main GUI : Slot Allocation DB : MS SQL Server
Select Vehicle Type
Elements shown for entering CheckIn credentials
Enter Registration No
If Subscribed == True
Click Subscribed Button
Enter Account Number
Click CheckIn Button
Open Slot Allocation Window
Slot Allocation Window Opened
Enter Slot Number to allocate GUI : Receipt
Click Proceed Button
Save Record
Record Saved
Successfully CheckedIn
Show data in gridview, update counter & map

Open Receipt Window
Open Receipt Window and Show Receipt
Figure 3.18: CheckIn manual

CheckOut
User : Attendant GUI : Main GUI : CheckOut DB : MS SQL Server
Click CheckOut Button
Open CheckOut Window
CheckOut Window Opened
Select Vehicle Type
Enter Slot Number
Click Proceed to CheckOut Button
Update DB
Record Updated
Successfully CheckedOut
If Pricing Type == Dynamic

Calculate Stay Time
& Total Price
Display Information
Go to Main GUI to update status
Remove data from Gridview, update counter & map
Figure 3.19: Checkout function

View Subscription
User : Attendant GUI : Main GUI:Subscription DB : MS SQL Server
Click Subscriptin button
Open Subscription Window
Fetch Subscriber Records
Records Successfully Fetched
Successfully Opened Subscription Window & Subscription records shown
Figure 3.20: View subscription

Add Subscriber
User : Attendant GUI : Main GUI:Subscription GUI: New Subscription DB : MS SQL Server
Click Subscriptin button
Open Subscription Window
Successfully Subscription Window
Click Add Subscriber button
Open New Subscription Window
New Subscription window opened
Enter Subscriber Details
Click Submit button
Store Subscriber Details
Subcriber Details Saved
Successfully Added Subscriber
Figure 3.21: Add subscriber Function

Edit Subscriber
User : Attendant GUI : Main GUI : Subscription GUI : Edit Subscriber DB : MS SQL Server
Click Subscriptions button
Open Subscriptions window
Retreive data
Data Successfully Retreived
Subscription Window Opened & Subcribers Shown Successfully
Click specific Edit button from Gridview of record/row you want to Edit
Open Editing Window
GUI for Editing opened
Update Customer Data
Click Submit button

Update Record
Successfully Updated Record
Record Updated
Figure 3.22: Edit subscriber Function

Delete Subscriber
User : Attendant GUI : Main GUI: Subscription DB : MS SQL Server
Click Subscription button
Open Subscription window
Retrieve Records
Successfully Retrieved Records
Subscription Window Successfully Opened
Click specific Delete button of user/row from Gridview you want to Delete
Delete Record
Successfully Deleted Record
Record Successfully Deleted
Figure 3.23: Delete subscriber

Logs Check
User : Attendant GUI : Main GUI:Logs DB : MS SQL Server
Click on Logs Button
Open Logs Window
Fetch Records
Records Fetched Sucessfully
Logs Window Opened & Records shown
Figure 3.24: Check logs

Print Receipt
User : Attendant GUI : Main GUI : Receipt
Complete CheckIn Process
Open Receipt Preview
Receipt Preview Shown
Click Print Button
Receipt Printed
Receipt:
Slot No.
Registration No.
Vehicle Type
Date
TimeIn
Figure 3.25: Print receipt

Rate Setting
User : Attendant GUI : Main GUI:Price Type DB : MS SQL Server
Select Configuration from Menu bar
Configuration Menu options shwon
Select Pricing option from sub-menu
Pricing sub options shown
Select Rate Option from sub-menu
Open Parking Rate Settings window
Pricing Rate Settings window opened
Set Car and Bike Rates for Static/Dynamic setup
Click Save Button
Update Setting
Settings Info. Updated
Rates have been successfully saved/updated
Figure 3.26: Rate settings

Slot Allocation Setting
User : Attendant GUI : Main GUI:Slot Allocation Setting DB : MS SQL Server
Select Configuration from Menu bar
Configuration Menu options shwon
Select Slot Allocation option from sub-menu
Open Slot Allocation Window
Slot Allocation Settings window opened successfully
Select Slot Allocation Setting from Window (Automatic/Dynamic)
Click Save Button
Update Setting Data
Settings Info. Updated
Settings Saved
Figure 3.27: Slot allocation settings

View Slot Detail from Map
GUI : Slot Status(Map)

User:Attendant GUI : Main DB : MS SQL Server
CheckIn Vehicle
Store Vehicle Record
Successfully Stored Vehicle Records
Vehicle CheckIn Successfully
Update Status Gridviews, Counter & Map
Click Any Alloted(Red) space on Map
Open Slot Status(Map) Window
Fetch Parked Vehicle Record
Provide Vehicle Records
Window Opened & Provide Slot# Vehicle Record
Figure 3.28: View slot details from map

Revenue Reports
User : Attendant GUI : Main GUI: Reports GUI:Revenue Report DB : MS SQL Server
Click Reports button
Open Reports Window
Successfully Opened Report Window
Select Revenue Report Option
Open Revenue Report window
Gets Data
Successfully gets data
Revenue Report Window Opened & Reports Displayed
Figure 3.29: Display Revenue reports

Strength Report
User : Attendant GUI : Main GUI: Reports GUI : Strenth Report DB : MS SQL Server
Click Reports button
Open Reports Window
Successfully Opened Report Window
Select Strength Report Option
Open Strength Report window
Gets Data
Successfully gets data
Strength Report Window Opened & Reports Displayed
Figure 3.30: Display strength reports

3.7 Class Diagram
Figure 3.31: Class diagram of Smart Parking Management System

3.8 Database Diagram:
Figure 3.32: Database design of SPMS

3.9 Data Dictionary:

Below Given the Table Names and their fields with data types and description to show what we
are storing in database:
Data Table: Bikes Primary Key: Slot
Table 3.1: Detail schema of Bikes
Sr No. Fields Data Types Description
1 Serial Int Contains serial numbering.
2 Reg_No Varchar50 Stores the registration no. of the
bikes.
3 DateTimeIn Datetime2(7) Stores the date and the entry time of
the bikes.
4 Slot Int Stores the slot no. of the registered
bikes.
5 Subscribed Bit It stores the data of the customer
that if customer is subscribed or
not.
6 Acc_No Int It stores the account details of the
customer.

Data Table: Cars Primary key: Slot
Table 3.2 .Detail schema of Cars
Sr No. Fields Data Types Description
1 Serial Int Contains serial numbering.
2 Reg_No Varchar50 Stores the registration no. of the
cars.
3 DateTimeIn Datetime2(7) Stores the date and the entry time
of the cars.
4 Slot Int Stores the slot no. of the registered
cars.
5 Subscribed Bit It stores the data of the customer
that if customer is subscribed or
not.
6 Acc_No Int It stores the account details of the
customer.

Data Table: Logs Primary Key: Serial
Table 3.3. Detail schema of Logs
Sr No Fields Data Types Description
1. Serial Int It stores the serial no. of the logs.
2. Reg_No Varchar50 It stores the registration no. of the

vehicles.
3. Types Varchar50 It stores the type of vehicle whether its

bike or car.
4. DateTimeIn Datetime2(7) It stores the date and the entry time of the
vehicles.
5. Slot Int It stores the allocated slot number.
6. DateTimeOut Datetime2(7) It stores the date and the exit time of the
vehicles.
7. Subscribed Bit It stores the subscription details of the

vehicles.
8. Acc_No Int It stores the account number of the

vehicles.

Data Table: Subscriptions Primary Key:Acc_No
Table 3.4. Schema of Subscription
Serial No Fields Data Types Description
1. Acc_No Int It stores the account no of

the customer
2. Name nVarchar50 It stores the name of the

customer
3. GName nVarchar50 It stores the guardian

name of the customer
4. CNIC Bigint It stores the identity card

no. of the customer
5. Contact Bigint It stores the contact no of

the customer
6. V_Type Char(10) It stores the vehicle type

of the customer
7. Balance Int It stores the balance of the

customer
8. Address Text It stores the address of the

subscribed customers
9. Reg_No nVarchar50 It stores the registration

of the subscribed
customers.
10. PricingType Char(10) It stores the price type.
11. Fee Int It stores charged fee.

3.10 User Interface Design

Introduction:
This document describes the User Interface for the Smart Parking Management System (SPMS).
Structure and Navigation:
The overall structure of the application is relatively simple, as shown in the following diagram.
Note: Numbers in the diagram provide a cross-reference to individual screens described in this
document.
Every Structure has its own importance and has been shown below with the original screenshots
below and can be explained as well.
Navigation:
A brief description of how this page or screen is accessed.
Figure 3.33: Structure/Navigation diagram of SPMS

Pages are displayed in a single browser window, which are shown in a pop-up. The pop-up
contains no browser controls.
Descriptions
This major part of the document contains detailed descriptions of each screen in Smart Parking
Management System (SPMS).
Unless otherwise noted, no graphic treatment has yet occurred.
Main Form of Application:
Figure 3.35. Main form of Application

Figure 3.34: Main Form of application
Description:
The Main form of application contains all the user interface design of our application.
Navigation:
When you open the Smart Parking Management System (SPMS), the main form of application
opens.

Elements:
The main form consist of these things.
It shows the
 Parking Counters
 Gridviews
 Map
 Vehicle Selection
 CheckIn Elements
 CheckOut Button
 Reports Button
 Subscriptions Button
 Logs Button
Receipt Form of Application:
Figure 3.35: Receipt form of application

Description:
The receipt form of our application is the receipt which we give when the customer park the car,
in the receipt there is some type of details in it like
 Registration No.
 Vehicle Type
 Date
 TimeIn
Navigation:
The navigation to receipt form is that when we select the vehicle type and write the reg no then
click on the checkin button the receipt form is open to print the receipt.
Elements:
 Registration No.
 Vehicle Type
 Date
 TimeIn
CheckOut Form of Application:
Figure 3.36: Checkout form of application

Description:
Whenever a car/bike wants to leave our parking area the checkout process is executed. The way
to checkout is that we want to enter the slot no of the registered car/bike to checkout that vehicle.
Navigation:
The navigation to checkout form is that you click the checkout button to open the checkout
window.
Element:
 Car/Bike radio buttons

 Slot No. Input box
 Click proceed button
About Menu of Application:
Figure 3.37: About menu form of application

Description:
The About menu form of our application tell about the software we are using, about the
developers, credits and the parking rules that are implemented in a parking areas.
Navigation:
The navigation to about menu form is at the top of the application near configuration button.
Elements:
 About Software
 About Developer
 Credits
 Rules
Configuration Menu of Application:
Figure 3.38: Configuration menu form of application
Description:
The Configuration form of our application tells the pricing schema of our applications that we
wants to use in our parking area.

Navigation:
The navigation to configuration is also at the top of the application like the about menu form.
Elements:
 Pricing Types option
 Pricing Rates option
Price Rate Setting Form of Application:
Figure 3.39: Price rate setting form of application
Description:
The Price rate setting form of our parking application has the facility that make the organization
to select which rates of parking they wants. They can put dynamic rates which can be a hours
rates or They can put a static rates which is static for a full day park.
Navigation:
The navigation to price rate setting is at the top of the application. You have to select the
configuration menu pricing will open then you have select the rate button to open the price rate
setting.

Elements:
 Rate input boxes
Logs Form of Application:
Figure 3.40: Logs form of application
Description:
The Logs form of our application helps the attendants to see the old records of parking area. It
also has the facility to filter the date that from which date you want the data of parking.
Navigation:
The navigation to logs form is that you have to select the log button to open the logs window.
Elements:
 Filters
 Search Button

Main Subscription Form of Application:
Figure 3.41: Main subscription form
Description:
The Main Subscription form of our application have the subscribed customer’s data. If the
parking attendant wants to check the data of a subscribed customer he has to click the
subscription button.
Navigation:
The navigation to main subscription form is to click the subscription button than the main
subscription window is opened.
Elements:
 Add New Subscription
 Edit
 Delete

New Subscription Form of Application:
Figure 3.42: New subscription form of application
Description:
The “New Subscription” form of our application helps the attendant to make new subscriptions
of customers. When a customer wants a subscription the attendant click the “add new"
subscriptions and write the details of the customer.
Navigation:
The navigation to new subscription window is that to click at the subscriptions button than you
have to click at the new subscription to open the new subscription window.
Elements:
Customers Details
 Customer Name
 Guardian Name
 CNIC

 Contact No.
 Address
Vehicle Details
 Car
 Bike
 Reg No.
Subscription Types
 Monthly
 Quarterly
 Half-Yearly
 Yearly
 Amountpaid
Report Generation forms of Application:
Figure 3.43: Report Generation form

Description:
The reports form of our application helps the attendants to see the records of parking data details
in a parking lot. In reports system you have the facility to check the reports of two types like
 Strength Reports
 Revenue Reports
Navigation:
The navigation to the reports window is that to click at the reports button which is at the main
form of application and then we select type of report after which we are redirected to report
generation form.
Elements:
 Daywise button
 Monthly button
 Yearly button
 Chart
 Counters
 Update button

Chapter 4 Implementation
CHAPTER 4
IMPLEMENTATION
Smart Parking Management System has been written in layered architecture i.e it has been
insured that user interface and business logic is separated from sql queries i.e. data access layer
has been implemented using separate dal classes for each functionality.
Below is the list of classes/forms of the project:
UI+BLL:
• SPMSMain
• CheckOutForm
• SlotAllocationForm
• ReceiptForm
• Logs
• SubscriptionsMain
• NewSubscription
• Reports
• Report Generation
• Pricetypesettingsform
• ratesettingsform
• slotallocationsetting
• filledslotdetails
SPMSMain:
The SPMSMain form is the home page of SPMS which consist of features which are given
below:

 Parking counters
 Maps
 Bike/Car Gridviews
 Registration Credentials
 CheckIn/CheckOut Functionality
 Logs
 Reports
 Subscription
CheckOut:
This form includes checkout functionality of the software. It has to select the type of a vehicle to
checkout and enter the slot no to checkout the desired vehicle.
SlotAllocationForm:
This form consist of input box in which attendant enter the slot no given by the customer to park
their vehicle. It is also called manual slot allocation.
ReceiptForm:
This form is generated when we enter the registration credentials and click on the parking receipt
to print it. The receipt we have implemented contains following details of the vehicle like,
• Date
• TimeIn
• Slot No
• Registration No
• Parking Fee
• Vehicle Type

Logs:
It has the old records of the application. If we want to search the parking data from different
dates than this software provides the facility to filter the data on different dates then click on the
search button to get the result.
SubscriptionsMain:
The Main Subscription form of our application have the subscribed customer’s data. If the
parking attendant wants to check the data of a subscribed customer he has to click on the
subscription button. It also gives the facility to edit the existing customer’s details, add new
customer’s subscription and delete the customer’s subscription.
NewSubscription:
The New Subscription form of our application helps the attendant to make new subscriptions of a
customers. When a customer wants a subscriptions the attendant click the add new subscriptions
window and write the details of the customer. It consist of different input boxes where the
attendant enter the customer’s details to make new subscription. It includes some details like:
• Customer Name
• Guardian Name
• CNIC
• Contact No
• Address
• Vehicle Type
• Registration No
• Subscription Type
• Amount Paid

Reports:
It consist of two type of reports:
• Strength Reports
• Revenue Reports
Strength reports are those type of reports where the software provides the knowledge of how
many vehicles has been in a parking lot in a required time.
Revenue reports are those type of reports where the software provides the knowledge of how
many revenue has been generated in a required time.
Report Generation:
This form provides the facility of generating parking report.
ratesettings:
This form consist of two types of rate setting
• Dynamic rate setting
• Static rate setting
In dynamic rate setting , rates are set according to the hours parking rules for both bikes and cars.
Whereas in static rate setting rates are set according to full day parking rules for both bikes and
cars.
slotllocationsetting:
There are two types of slot allocation setting
• Automatic slot allocation setting
• Manual slot allocation setting
In automatic slot allocation setting, the software automatically allocate the slot to the registered
vehicle.

Whereas in manual slot allocation setting, there is a choice for both of the attendant and
customer to select the desired slot for allocation.
FilledSlotDetails:
In this form our software provides some essential details of filled slot include:
• Vehicle type
• Registration#
• Arrival Date/Time
• Subscribed Customer
• Account #
Vehicle type show the type of vehicle that is parked on fill slot. Registration No that is unique
for each vehicle which create uniqueness of each vehicle. Arrival Date/Time indicate that time in
which such vehicle come on it slot. Subscribed Customer indicate that the owner of parked
vehicle is our regular customer or Not?. If owner of vehicle is our subscribed customer then
software verify its account #.
DAL:
• check_inoutdal
• logsdal
• mappingdal
• receiptdal
• reportsdal
• subscriptiondal

check_inoutdal:
“check_inoutdal” access the data using SQL queries for SPMSMain and CheckOut form mainly
check in and checkout functionalities.
logsdal:
“logsdal” access the data from logs form using SQL queries
mappingdal:
“mappingdal access the data for SPMSMain, filledslotdetails and slot allocation form using SQL
queries.
receiptdal:
Receiptdal access the data from db using SQL queries for receipt form.
reportsdal:
Reportsdal access the data for reports class.
subscriptiondal:
Subscriptiondal access the data for SubscriptionMain and NewSubscription class.

Chapter 5 Testing & Results
CHAPTER 5
TESTING & RESULTS

5.1 Project Test Plan:
Table 5.1
Overview
Test Plan Objectives To ensure that the Smart Parking Management System will:
 Function consistently and reliably in accordance with current
business operations.
 Meet or exceed user requirements and technical
specifications.
 Not adversely impact other systems or the existing
technology Environment.
Testing Assumption  Software has some default settings at start.
 The subscription ID’s of each customer are assumed to be
unique.

Table 5.2
Test Risks/Issues
Risk Impact Trigger Mitigate Plan
Scope Creep(testers want High Delays in Functionality will be
more functionality as they implementation date closely monitored in
become familiar) each iteration, priorities
set and discussed.
Any changes to High(to schedule and Loss of test cases Export data prior to any
functionality may require quality) upgrade, and re-import
test/test cases to be altered after upgrade
Table 5.3
Test Scope
Features to be Tested All features, forms, reports and interfaces affected by the Smart Parking
Management System will be tested. These include:
CheckIn
CheckOut
Logs
Subscriptions
Reports
Configurations
Features Not to be Tested Data integrity

Table 5.4
Test Methodologies
Testing Approach The following approach will be used to test the Smart Parking Management
System
Unit, integration & system testing will be conducted to provide an initial
stable testing environment as follows:
Unit Testing: Ensure the correct functionality of individual units of software.
• Integration Testing: Ensure operability of Smart parking management
system within each of the new modules.
• System Testing: Ensure that all the test databases are accessible for
testing
Test cases are devised.
Test Documents The following test documents will be created and maintained throughout the
project lifecycle:
Test Plan
Master test case lists for each of the following functional units: Login,
Search, Subscribe, Review, Publish, Update status, Logout.
Test case scripts for each test case recorded in the master test case list
Log of all problems encountered during the testing phase of the Project.
Test Case Pass/Fail Criteria Each Test Case will be evaluated against the acceptance criteria as outlined
in the test case scripts to determine if the test passed or failed. In the case of
a failure, the tester will assign a severity to the problem using the
appropriate priority rating system established within Tracker for each
application.
Suspension / Resumption Test Cases that do not run to completion will be evaluated on a case by case
Criteria basis to determine if the testing must start over or resume at the point where
the failure occurred. In extremely long test cases, checkpoints will be
established for resumption in the middle of a test case where appropriate. In
general, a test may be resumed in the middle when the error is not Critical.

Problem Logging / Errors identified through testing will be logged. Resolved the problem
Resolution according to the deemed Severity level and update the master test case list.
Once the problem has been fixed record the resolution in the database.
The failed test cases will be Retested using the same test case script that
detected the error in order to verify that problem has been rectified.
Table 5.5
Resources
Environmental Needs A working system and database is required.
Staffing Requirements Developers

5.2 Test Cases
Table 5.6. TC1 CheckIn
Test Case ID TC1
Description CheckIn Vehicle
Prepared By Khubaib Date Prepared 3/2/2018
Muzammal
Reviewed / Hassan Naveed Date Reviewed 4/2/2018
Updated
Tested By M.Umer Arif Date Tested 4/3/2018
Test Activities
Sl. Step Description Expected Results Actual Results Pass/Fail
No.
1 Select Vehicle Type Successfully Selected Pass
Vehicle Type
2 Enter Reg No Successfully entered Pass
registration no
3 Click on CheckIn Successfully checkedIn Pass
button.

Table 5.7. TC2 Checkout
Test Case ID TC2
Description CheckOut Vehicle
Muzammal
Updated
Test Activities
No.
1 Click on checkout Pass
button on Main form
2 Select Vehicle Type Successfully Selected Pass
Vehicle Type
3. Enter Slot No Successfully entered Pass
Slot no
4 Click on Proceed Successfully Pass
button checkedout

Table 5.8. TC3 Logs
Test Case ID TC3

Description Logs
Muzammal
Updated
Test Activities
No.
1 Click on the logs Logs window open Pass
button
2 Check old records Successfully checked Pass
old records
3. Select particular Date Date Selected Pass
to filter data
4 Click on Filter button Records shown Pass
successfully

Table 5.9. TC4 Add subscriber
Test Case ID TC4
Description Add Subscriber

Muzammal

Updated
Test Activities

No.
1 Click on the Pass

subscription button on
Main form
2 Click on the Add Successfully Selected Pass

subscriber button on
subscription form
3. Enter the details of new Successfully entered Pass

subscriber details
4 Click on submit button Successfully Subscribed Pass

Table 5.10. TC5 Edit Subscriber
Test Case ID TC5
Description Edit Subscriber

Muzammal

Updated
Test Activities

No.
1 Click on the Pass

subscription button on
Main form
2 Click on the Edit Successfully Selected Pass

subscription form
3. Update the details of Successfully Updated Pass

existing subscriber
4 Click on submit button Successfully Updated Pass

Table 5.11. TC6 Delete Subscriber
Test Case ID TC6
Description Delete Subscriber
Muzammal
Updated
Test Activities
No.
1 Click on the subscription Pass
button on Main form
2 Click on the Delete Successfully Deleted Pass
subscription form

Table 5.12. TC7 Revenue/Strength Reports
Test Case ID TC7
Description Revenue/Strength Reports
Muzammal
Reviewed Hassan Naveed Date Reviewed 16/2/2018
Updated
Test Activities
No.
1 Click on the Reports Pass
button on Main form
2 Select the revenue or Successfully Selected Graphs and statistics is Pass
strength option shown

Chapter 6 System Evaluation
CHAPTER 6
SYSTEM EVALUATION
The objectives defined for this project were
• To maintain parking data
• Parking space/slots management
• Pricing management(Dynamic/Static)
• View reports and statistics
We now analyze the extent this project was successful in achieving objectives.
Approach and Outcome:
Our software SPMS has the approach that will help the parking business to flourish.
Whenever a vehicle has been entered the parking lot, the system will write the registration no of
the vehicle and CheckIn that vehicle. When a car has been successfully checked in the data has
been maintained in the database and we can check these data through logs, hence our objective
of maintaining parking data is successfully achieved.
As far as parking space/slot management is concerned when a vehicle enters the parking area
two types of flows can happen. There will be automatic slot selection or there will be manual slot
selection. In case of manual slot allocation the attendant select the no of slots to assign. The
objective of pricing management has the importance that the parking company has the benefit of
having two types of pricing in the software. Dynamic pricing is that pricing which is changing
after some time whereas the static pricing is not changing. We charge the parking fee through
receipt, in that receipt there is some details in it.

Chapter 6 System Evaluation
The vehicle that entered the parking area has been recorded in our database. The records has
been maintained in Reports form, we can check the records of vehicles by Strength records and
by Volume of records. The records has been maintained in a way that you can check it in daily ,
weekly , monthly or even yearly basis.
The scope of our software is different from others in such a way that we examined that parking
system offer varying features with some features overlapping, while many of these are too much
expensive and most features offered thereby are of no need to medium sized parking operators.
Our SPMS aims to provide a low cost, easy, simple implementation catering the needs of
medium level parking by eliminating the need of hardware, without compromising on
performance. It integrates useful features provided by different systems into one software.
The software has some advantages
• As we use software to allocate slots, we can track the current status of parking slots
without the use of hardware sensors, hence providing a cheap alternative
• Computerized Receipt will be given , which reduces the time of writing receipt
• We have deployed a rare phenomenon of giving a Dynamic pricing in parking business,
which means the price will charged according to mins/hours.

Chapter 7 Conclusions & Further Work
CHAPTER 7
CONCLUSIONS & FURTHER WORK
As far as the overall project objectives we have achieved desired goals and during the course of
project we have learned a lot, it was a great experience in which taught us team work, working
with respect to schedule and gave us practical touch by providing opportunity to implement
theoretical ideas and subjects into practice, but as with any other project ours also has some type
of type of limitations present in it and we encountered some tiresome problems during
development.
Limitation & Problem:
 The main problem that we faced in our project during making is the manual and automatic
slot selection of the vehicle at the same time. The idea is that we can make the software to
automatically allocate the parking slot to the vehicle and also we can make it do manual slot
allocation, but this makes some kind of difficulty. We have provided configuration menu to
change slot allocation type at any time, but suppose if we start software and keep checking in
using manual option i.e. attendant allocating slot# and after some time we change option to
automatic allocation, and e.g. previous slots filled were 2, 3, 4, 5, now software has to detect
which 1st slot is free i.e. “1”, and that was very tough algorithm to make, and also it forced us
to make two algorithms for slot allocation.
Solution:
We solved this problem by giving a variable value 1 and checking if corresponding slot#
is filled in db, incrementing its values repeating process again and again until we find
corresponding slot# free in db.

Chapter 7 Conclusions & Further Work
o We have not included the facility of integrating hardware resources such as sensors, barriers
in the software some may regard it as a limitation but we have done it willfully.
Further work:
 We plan to further add QR codes to the printed receipts as it will speed up the process
of checkout by just scanning QR code. Now a days QR codes can even be scanned by
using mobiles making the process simpler.
 We plan to access the vehicle details through excise website and store it in our
database for security reasons.
 We further plan to integrate hardware resources (Sensors) to make it more robust
solutions.
 We plan to connect our software with a LED to display dynamic calculated price at
the time of checkout. At the moment our software only displays the parking price to
attendant only.
 We plan to enhance our map in future.
o We plan to integrate our software with the specialized cameras that will take picture of
vehicles and automatically extract the registration no of vehicle.

Chapter 8 User Guide
CHAPTER 8
USER GUIDE
8.1 User Guide Contents
Our Software SPMS contain some different User manuals. That given below:
1. Counter
2. Maps
3. Grid Views of cars & Bikes parked Status
4. CheckIn
5. Checkout
6. Subscription
7. Logs
8. Reports
9. About
10. Configurations
8.2 Detailed Description of User Guide

Counter:
As we usually know that simply “Counter” means to count number of things. But here counter
indicate that how many numbers of cars and bikes are parked in our parking Area. If any vehicle
comes in our parking area for example a car come a parking attendant of our parking area (enter
its types and registration number) check in. As Attendant “CheckIn” it’s details. Counter shows
current number of cars Park in parking area. If number of cars was 20 before this car enter. Then
after check in the current car details then the number of cars increment from 20 to 21. So counter
shows 21 cars park at time. Same dealing repeated for bikes Counter.

Maps:
Here Maps really mean Our “Parking map”. In our software we provide map’s facility to our
customer. Maps easily show to our customers that how they parked their vehicles (i.e. car, bike)
park. Generally map shows number of slots to our customer. We define 50 50 partition of slots.
50 reserved for Cars and 50 Reserved for Bikes. Map uses two colors i.e. green, red. If Map
show “GREEN” color on slot its mean. Such slot is Free for every Vehicle. If map show “RED”
color on slot then its mean such slot is reserved/ i.e. Vehicle is parked.
Grid Views of Cars & Bikes Parked Status:
In our homepage there are two grid views are shown. One represent for car park status. And
another one is represent for Bike Park Status. These grid views contains vehicle Registration
Number, Current Date, Current Time In , Current Time Out Slot# etc. These grid views are
showing current numbers of vehicles with details (i.e. cars or bikes) are parked. After checking
in current vehicle the grid views show its current parameters.
Check In:
In our software this process consist of Two sub processes. First one is Selection type of Vehicle
(Whether it is Car Or Bike). If Vehicle is Bike then our Parking attendant will select its type
“Bike “from software. And second one is enter Registration No. After complete selection type.
Parking attendant enter its Registration No. Because “Registration No” is unique for every
Vehicle. After enter “Registration No.” Such Vehicle is successfully “CheckIn”. After
“CheckIn” its proper Details are save in our software.
Check Out:
In our software we provide facility of check out Vehicle. This process is based on two things.
One is to select Vehicle type. And second one is to provide current number of slot in which it’s
stand. Checkout process is done only when such vehicle will leave our parking area. For example

if Vehicle is Car. And its Reg No is “XYY-12-1234” and is parked on slot No 4. And when it
leave our parking Area. We will enter its Slot No. Then we click on “proceed to Checkout
“button in Checkout window. After Click button. Such Vehicle is successfully Checkout.
Subscription:
In our Software you will see “Subscription” button on bottom left of homepage. Click this
button. After clicking this button new window show in our homepage. The main purpose of this
button is to provide facility to those customers whom they park their vehicles on regular basis
and as well as pay on regular basis. So instead of paying on regular basis, they pay parking
Charges only one time in month. And park their vehicles on daily Basis. In subscription Window
“Add new” button on top of Window. By clicking this event we can create new subscriber
account by entering customer details, Vehicle Details, And Subscription Type and as well
Amount paid etc. Moreover we provide facility for customers that they can edit their account for
some circumstances (like change vehicle, change address, Change Contact# etc.). For this
purpose Edit button place with each record by using this button attendant can easily update the
records of existing subscribers in such types of circumstances. More if any customer would not
to take advantage our services/ they want to unsubscribe. So we provide facility of Delete such
customer. For this purpose delete button place with edit button on each subscriber record. By
clicking this button we will delete its record. And such customer will unsubscribed.
Logs:
In our software we provide facility of Logs Check. In our Software home page we provide
“Logs” button on bottom left. If an attendant want to see old parking records, then he will click
on this button. Logs window will be open. In this window attendant will be able to see particular
Vehicle records from date to date, from current month to next coming month. An attendant enter
current Date in “From text bar” to “To text bar” to that past date and then click on Search button.

In this window we see complete old records of vehicles with its registration No, Type, Entry date
Time, Exit date time and as well as we can see that such customer whom owner of such vehicle
is our subscribed customer? Or Not? If such customer is our Subscribed Customer then we can
see it Account No.
Reports:
Our software provide facility of reports. For this purpose “Reports” button show on bottom
center of home page.
About Menu bar:
In our homepage you will see about menu bar on top. When attendant click on this menu bar.
Attendant will see 4 basic things i.e about software, about developers, Credit, Rules. In “About
software” Tab attendant will see complete brief information about software (i.e. its complete
detail working of its each module). In “About developer” attendant will see complete detail
introduction about developer/ Authors including its (Professional skills, what kind of tools that
he will use.
Configuration:
In our Home page you will see Configuration Menu bar. This menu bar consist of parking Price
related Vehicles (whether it is Car or it is Bike). When attendant open this menu bar. Then he
will select pricing. A new window is open. Attendant fix can parking rate of vehicle (whether it
is car or bike) according to its type of price that he select. One thing remember here is that both
car and bike are separate price selection and separate parking rate fix.

Chapter 9 Bibliography
CHAPTER 9
BIBLIOGRAPHY
o Capterra. The Smart Way to Find Business Software. (n.d.). Retrieved from
https://www.capterra.com/parking-management-software
o ICONFINDER. (n.d.). Retrieved from https://www.iconfinder.com/
o CODEPROJECT For those who code. (n.d.). Retrieved from https://www.codeproject.com/
o stack overflow Learn, Share, Build . (n.d.). Retrieved from https://stackoverflow.com/
o Microsoft Developer Network. (n.d.). Retrieved from https://msdn.microsoft.com/
o Bow Valley College. RGO Library & Lerning Commons Retrieved from
https://bowvalleycollege.libguides.com/apa-style/website

Chapter 10 Appendices
CHAPTER 10
APPENDICCES
Appendix A: Source Code
(Google Drive Link)
https://drive.google.com/open?id=1-8Ozcjyz30zySauLO3yBFSchRPJ1ryNS
Appendix B: Report Format & Type Setting Rules:
The information in this section explains how the report should look. Set them up on a word
processor and use them throughout the preparation of the document than to attempt a major
rearrangement of material at the last minute.
Length:
There is no hard rule about overall length because this will vary with each project depending on
the nature of the work. For a B.Eng. report, approximately 120 pages, including tables and
appendices is an acceptable upper limit. Ask advice from your supervisor and remember,
quantity is no substitute for quality.
Paper:
The entire report must be submitted on A4 size paper. Printing. The report should be printed on
one side of each page only. The print quality should be dark and clear.
Margins:
Left margin 25mm. top, bottom and right margins 20mm.

Chapter 10 Appendices
Justification:
Right and left margins should be justified (giving a straight edge to the text on both sides).
Size:
Use a Times New Roman or similar style font, point size 12 for most of the document.
Pagination:
The report must carry sequential pagination throughout, including appendices. The page number
should be on the top right margin of each page. The title page is counted in the numbering, but
bears no page number.
Page Breaks:
Try to ensure that these occur in sensible places. There is no need to take a new page for each
main section heading but you should do so for new chapters. Never let a page break separate the
last line of a paragraph. Try to ensure that, if possible, enumerated lists (a, b, c etc.) are not split
across pages.
Header:
A header should be placed at the top of each page apart from the title page. In addition to the
page number, the document header should include the candidate’s name, qualification sought and
calendar year.

SPMS Final Documentation

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SPMS Final Documentation

Загружено:

Авторское право:

Доступные форматы

SPMS

SMART PARKING MANAGEMENT SYSTEM

SESSION: 2013-2017; GROUP ID: G-15

A DOCUMENTATION SUBMITTED IN PARTIAL FULFILLMENT OF

my guidance and supervision.

MIAN MUHAMMAD MUNIR UD DIN

(For Office Use Only)

and friends who prayed for our success.

suggestions, boundless forbearance, indefatigable help with anything, anywhere, anytime,

department would always be due.

complete our project.

statistics and charts.

time of entry and exit of vehicle automatically.

pricing. The system will provide the option of subscription (monthly/quarterly/half-year/yearly)

payment to accommodate parkers that park on daily basis.

without compromising on performance. It integrates many of the features provided by different

Govt. Islamia College, Civil Lines, Lahore 1

Traffic Tech (Gulf): Car Park Equipment & Management Systems

• Parking Guidance Systems

• Valet Parking System - Smart ValetTM

• On-Street Parking Control Systems

- Parking meters and pay & display

Recognition (ANPR)”, “Radio Frequency Identification (RFID)”, “CCTV Surveillance”,

• Electro-mechanical / Hydraulic / Manual Bollards

• Signage of Parking Areas

• Operation and Maintenance [1]

The SKIDATA Solution

• Violation processing: enterprise level or off-the-shelf

• Meter, sensor and off-street revenue collection systems

Govt. Islamia College, Civil Lines, Lahore 2

• Operations powered by Conduent Merge® Parking Management System

• Managed receivables and collections, including innovative payment plans [2]

Web Parking Software

• Full Parking Management System for any size building

• Issue professional parking permits

• Assign parking spaces for tenants

• Allocate guest parking and special event parking

• Process and Pay fines online

• Track and manage all properties, occupants and tenants [3]

PermitTech: Parking Permit Management Software

permits, visitor permits, temporary permits, car pools,

Some functional characteristics are as follows

 Set-up, add to, and remove from wait lists

 Issuance of new and renewal permits

 Sell/transact payments of new and renewal permits

Govt. Islamia College, Civil Lines, Lahore 3

as the need arises and resources allow so.

of giving choice to attendant to allot specific slot.

Govt. Islamia College, Civil Lines, Lahore 4

2. SKIDATA. (n.d.). Retrieved from https://www.skidata.com/en/business-areas/parking-

4. Smart Parking. (n.d.). Retrieved from https://www.smartparking.com/

Govt. Islamia College, Civil Lines, Lahore 5

INTRODUCTION & BACKGROUND

The objectives we target are:

• To maintain parking data

• Parking space/slots management

• View reports and statistics

1.1.1 Project Success Criteria:

Desktop Application (C#.Net) that meets requirements.

1.2 Introduction to SPMS

Our project contains following primary functionalities

 Slot Allocation (automatic, manual)

 Logs (old records)