Car_parking_system(sample Report).pdf

AUTOMATED CAR PARKING SYSTEM

SUBMITTED BYRAJIT SINGH (00000000009) RAHUL SHARMA (00000000046) BSc (H) Computer Science II year

CERTIFICATE This is to certify that RAJIT SINGH and Rahul Sharma, the students of BSc. (H) Computer Science, ________ College , Delhi University, with Roll No. 36 and 17 respectively have made the project titled “Automated Car Parking System” in their individual capacities under my supervision for the fulfillment of IV Semester practical examination.

(Ms Kavita Rastogi)

2

ACKNOWLEDGEMENT We extend our profound gratitude to our project guide Ms Kavita Rastogi, for her interest, guidance and suggestions throughout the course of the project. We feel honored and privileged to work under her. She shared her vast pool of knowledge with us that helped us steer through all the difficulties with ease. This project would not have been possible without her guidance and we would like to thank her for everything she has done for us.

Rajit Singh & Rahul Sharma

3

TABLE OF CONTENTS Serial No.

1. 1.1 1.2 1.3

2.

CONTENTS

Page Number

PRELIMINARYANALYSIS EXISTING SYSTEM PROBLEM STATEMENT SCOPE OF THE PROJECT

DETAILED ANAYSIS

2.1 2.2 2.3 2.4

PROPOSED SYSTEM PROCESS MODEL USED FEASIBILTY STUDY LIST OF REQUIREMENTS

2.5 2.6

CONSTRAINTS AND LIMITATIONS EXTERNAL INTERFACE REQ.

3. 3.1 3.2

4. 4.1 4.2 4.3

5. 5.1 5.2 5.3

6. 6.1 6.2

7.

2.4.1 FUNCTIONAL 2.4.2 NON FUNCTIONAL

MODELLING DATA FLOW DIAGRAMS DATA DICTIONARY

PROJECT PLANNING ESTIMATION COMPUTATION OF FUNCTION POINTS. TIME LINE CHART RISK MANAGEMENT -> RISK TABLE ALONG WITH ‘ RMM’ PLAN

PROJECT DESIGN ARCHITECTURAL DESIGN DATA BASE DESIGN COMPONENT LEVEL DESIGN

TESTING TESTING STRATEGY WHITE BOX TESTING-----BASIS PATH TESTING

REFERENCES

5 5 6 7 10 10 11 12 12 13

14 17

20 23 24

26 27 29

30 31

35

4

1. PRELIMINARY ANALYSIS 1.1 EXISTING SYSTEM There are over 500 million cars running on the road worldwide and this number is increasing at a very fast rate. As the number of cars grow, so does the demand for convenient and safe parking. Car parking is the bane of any property developer's life. It has now become important for all of us to have a safe and better car parking solutions. In the existing system, we generally have the basement parking which also involves a much large cost and the men labour involved in parking process.

1.2 PROBLEM STATEMENT Conventionally, parking systems does not have any intelligent monitoring system. Parking lots are maintained by human beings. All vehicles enter into the parking area and waste their time searching for the vacant parking slots. Sometimes it creates blockage. Condition worse when there are multiple parking lanes and each lane have multiple parking slots. One of the major problem arise due to the estimation of the space for the parking lot:  If space is overestimated it results in loss of revenue and wastage.  If space is underestimated, it results in customers’ frustration and hence leading to a loss of clients who go elsewhere.

5

As the population grows and society's dependence on automobiles, the need for more efficient and intelligent parking solutions is required. Moreover it becomes difficult to satisfy those clients with the existing parking systems.

1.3 SCOPE OF THE PROJECT The main goals of this software development project is to maximize the revenue of a parking lot by introducing an automated system for parking and develop a user-friendly mechanism that helps customers to easily park their vehicles in the parking lot. It also aims at reducing the labour force in the project.

6

2. DETAILED ANALYSIS 2.1 PROPOSED SYSTEM The solution to the current existing system is a scale-able, reliable automated car parking system that can resolve the density/parking issues immediately. Automated car parking systems are particularly suited for use in commercial and private parking lots, car dealerships, hospitals, universities, government buildings and especially in apartment buildings. Also, they are economical to install and operate. They are safe, dependable and robust. The main advantage of AUTOPARK SYSTEM is that it will help us to park more vehicles in a car park space while maximizing your parking revenue profits. Many users have effectively doubled or even tripled their parking capacity without using any additional property. Dependable, low maintenance, free standing units fit easily into your existing space and usually require little foundation preparations or additional services. They cost a fraction of traditional concrete car-parks to build and install and once erected, need little maintenance to function perfectly for decades. They are user-friendly, are built to last and have excellent safety and reliability records. It offers many important advantages including innovative design and engineering, quality workmanship, maximum utilization of space and low installation. Car systems can be free standing or clad in a variety of finishes, bricks, glass, concrete etc. to match neighbouring buildings. 7

2.1.1 DESCRIPTION 1) Vehicle enters the parking area. 2) Vehicle owner presses the button on the machine. 3) Card/token with entry time, slot_no and vehicle_no is issued. 4) LED display unit present at the entrance parking shows the existing vacant slots. 5) Vehicle is being parked in the parking area using robotic trolleys. 6) There are different segments for two- wheelers and fourwheeler parking. 7) The LED display is updated for vacant slots. 8) At exit time, the ticket collector check the details i.e. the vehicle_no, slot_no and the time. 9) Fee is generated. 10) The owner of the vehicle makes the payment through smart card or cash. 11) The payment is received by the ticket collector and the bar is raised and vehicle exits. 12) LED is updated again.

Charges are as follows:Four wheelers:Weekdays: Rs. 40 Weekend and all public holidays: Rs. 60 for first three hours and additional Rs. 10 for each subsequent hour.

8

Two wheelers:Weekdays: Rs. 10 Weekend and all public holidays: Rs. 20 for first three hours and additional Rs. 5 for each subsequent hour. Lost ticket charges:4 wheelers: Rs. 60 + id proof verification 1

wheelers: Rs.40 + id proof verification

Smart Card users will get 10% discount.

2.1.2 LIST OF INPUTS AND OUTPUTS:Inputs:    

Entry time Vehicle_no Type of vehicle Payment

Outputs:  Ticket  Parking slot  Fee

9

2.2 PROCESS MODEL USED Car Parking System is based on LINEAR SEQUENTIAL MODEL (Waterfall Model) because of the following reasons:  Car Parking System Project requires a systematic and sequential approach towards the development of the software which begins at system level and progress through analysis, design, coding, testing and support in order to fulfil the requirements of the project.  Since the requirements are fixed and are stated at the beginning so there is very little scope of customers’ deviation from current requirements.  There is no modular structure as there is only one team to develop the system project and to do all the tasks related to it.

2.3 FEASIBILITY OF THE PRODUCT The main question of the whole system: “Is the project feasible?” The feasibility of the product is the question that confirms the reality of the ideas. This software provides the ability to increase the efficiency of the existing system by automating. Financial test is crucial. The dimensions that define the feasibility of the project are: ECONOMIC FEASIBILITY The cost incurred for the developing the software is much less as compared to the manpower employed for handling all the details manually. The cost of the software is the one long time 10

investment. Cost of maintenance and incorporating new functionalities will be low. TECHNICAL FEASIBILITY Since the software is Windows compatible, therefore the software is workable on any machine having C++ Compiler. Hence we can say the product is technical feasible. BEHAVIOUR FEASIBILITY Since the software is based on windows platform so understanding the software is a very simple task here. User doesn’t require any special training to run it. Moreover, the software is easy to deploy and use, hence it offers trouble free working environment.

2.4 REQUIREMENT ANALYSIS 2.4.1 FUNCTIONAL REQUIREMENTS The requirement analysis maximizes customer’s satisfaction by evaluating the functional requirements of the customer. It consists of the following:  Bright LED display displaying the vacant slots.  Payment through card and cash both.  The fee generation system should be according to the entry time and exit time.  Some warning system for wrong entry of data.  Token should be provided as a proof.  Sophisticated virus protection system for any type of malfunctioning, e.g. Discrepancies between the vacant slots being displayed and actual vacant slots.  Impressive graphical user interface. 11

2.4.2 NON-FUNCTIONAL REQUIREMENTS 1) RELIABILITY-: The system will consistently perform its intended functions. For e.g. the important information must be validated. 2) EFFICIENCY-: Unnecessary data will not be transmitted on the network and database server will be properly connected. 3) PERFORMANCE :  Software works within operable and acceptable speed and can work efficiently.  Uses modern OOPS concepts and equally relies on Databases.  Produces outputs in accordance to the inputs. Graphical User Interface (GUI) support. 4) SECURITY : Only system administrator has rights to access the database not every user can access all the information.

2.5 CONSTRAINTS AND LIMITATIONS OF THE SYSTEM Although the system is fairly efficient but it has some constraints also:  Since the system is not fully automatic, so it requires labour though it’s less.  The system entertains only one vehicle at a time.  The system utilizes the horizontal space only. 12

2.6 EXTERNAL INTERFACE REQUIREMENTS HARDWARE REQUIREMENTS    



PC with a 1GHz processor, Pentium IV recommended. 256 MB of RAM. 2GB of available hard-disk space for full installation. Super VGA (800 x 600) or higher resolution with 256k colours. Pointing Device, optical mouse would be preferred.

SOFTWARE REQUIREMENTS 

  

The system will run on Windows XP or later operating systems. UNIX (Linux) Operating System is not supported. All functions would be developed in C++ as front-end tool. SQL must be installed for database handling.

INTERFACE REQUIREMENT Graphical User Interface (GUI) compatible with windows would be used to make the software product user-friendly.

13

3. MODELLING 3.1 DATA FLOW DIAGRAMS

14

15

16

3.2 DATA DICTIONARY DATA FLOW: 1) Name: vehicle_details Description: Contains details of the vehicle and is used to generate to generate the fee slip. Source: User Destination: Process 1 (Details processing) Process 3.1 (Fee Generation) Type data flow: File Data structure Travelling with flow: Vehicle record

DATA STRUCTURE: 1) Vehicle Record = vehicle_no +entry_time +exit_time+vehicle_type+slot_type +payment_type+(contact_no)+fee 2) Payment =

3) Slot info =

[cash|card]

slot_no+slot_type

17

DATA ELEMENTS: 1) Data name : Vehicle_no Data description: it uniquely identifies each vehicle Origin: Keyed in by the user. Part of vehicle_details & fee slip. Destination: Process:i) 1 (Details processing) ii) 3.1(FEE generation) Data type: alphanumeric character Length: 12 Remarks: It is primary key for parking_ticket.dat file 2) Data Name: Description: Origin:

Entry_time it denotes the arriving time of vehicle in the parking lot. keyed in by the user. Detected by the system.

Destination: Process i) 2 (vehicle parked in slot) ii) 3.1 (FEE generation) Data type: alphanumeric Length: Limit : It must be in the format 00:00 format. Remarks: It is in 24-hours format. 3) Data Name: payment_type Description: it indicates the mode of payment. Origin: keyed in by user and part of updated info. Destination: Process 3.1 (FEE generation) Data type: varchar Length: 4 digit Limit : value must be “card” or “cash” only. Remarks: by default value is “card”.

18

4) Data Name: vehicle_type Description: it describes about the type of vehicle whether it is 2 wheeler or 4 wheeler. Origin: keyed in by user and part of updated info. Destination: Process 1 (Details Processing) Process 3.1 (FEE generation) Data type: integer Length: 1 digit Limit : either 2 or 4 Remarks: 2 for 2wheeler and 4 for 4wheeler is specified

PROCESS SPECIFICATION: 1) Name : FEE Generation Process id: - 3.1 4) Input: - vehicle_no +entry_time +exit_time+vehicle_type+slot_type +payment_type+(contact_no)+fee Output: - parking ticket Description: - it is used to generate the fee slip.

DATA STORE 1) ID :- P1 Name: parking_ticket Alias: updated details File type: computer File format: database Record size: 250 characters No. of records: Maximum: 3000 Average: 2000 Data structure: fee_slip and updated details Primary key: vehicle_no Secondary key: No secondary key Description: Stores the details of the vehicle parked in the lot. 19

4. PROJECT PLANNING 4.1 ESTIMATION PROJECT METRICS Project metrics are used to control and coordinate software engineering process and to improve quality of the software to be produced. Project specific metrics provide indication of productivity and insight into the technical activities. Adapt project workflow and technical activities and code.

FUNCTION ORIENTED METRICS Function oriented metrics use function point as normalization value. Function points are derived using an empirical relationship based on countable (direct) measure of software’s information domain and assessments of software complexity. Calculation of complexity adjustment values:

Does the system require reliable backup and recovery? Are data communications required? Are there distributed processing functions? Is performance critical? Will the system run in an existing, heavily utilized operational environment? Does the system require online data entry? 20

Grade value 1 5 3 5 4 0

Does the on-line data entry require the input transaction to be built over multiple screens or operations? Are the master files updated online? Are the inputs, outputs, inquiries complex? Is the internal processing complex? Is the code designed to be reusable? Are conversion and installation included in the design? Is the system designed for multiple installations in different organizations? Is the application designed to facilitate change and ease of use by the user? ∑F =

Calculation of Function point for the current software: Measurement parameter Number of user inputs Number of user outputs Number of user enquiries Number of files Number of external interfaces

Count Weighting Weighting count Factor 6 4 24 3 5 15 0 4 0 3 10 30 0 7 0 Count total= 69

Function point = Total count * (0.65+ 0.01 * (∑F)) = 69 * (0.65 + 0.01 * 34) = 68.41 21

0 0 2 3 3 2 1 5 34

Once function point has been calculated it can be used to normalize measures for software quality, productivity and other attributes such as:   

Errors per FP Defects per FP $ per FP

22

4.2 TIMELINE CHART

23

4.3 RISK MANAGEMENT Identifying potential risks and developing a plan to mitigate, monitor and manage risks is of paramount importance. Risk analysis enables to build a risk table by providing detail guidelines in identification and analysis of risk. Points to be considered are   

Risk avoidance Risk monitoring Risk management and contingency plan.

For all activities that lie above the cut-off point, a mitigation plan has been developed to mitigate the risk. A plan of action is structured, and the risk is being monitored at all the phases, i.e. a number of factors are considered. In our context the risks for which a mitigation plan has been put into place are: 1. 2. 3. 4. 5. 6.

Lack of clear product vision. No of people may be inadequate to do the job. Delivery date may extend. Lack of documentation. Customer may change the requirements. End users may resist the system.

Impact Values for RISK TABLE 1- Catastrophic 2- Critical 3- Marginal 4- Negligible

24

For our project the RISK TABLE is as follows: Risks

Category Probability Impact

Lack of clear product vision.

PS

60%

2

RMMM 



Delivery deadline BU may be tightened.

80%

2





No. of people may PS be inadequate to do the job.

60%

Customer will change requirements.

60%

PS

2

 

2





End user may resist BU the system.

40%

1





25

Ensure that requirements are clearly understood. Constantly monitoring and revising the requirements. Schedule made should be realistic and achievable. Monitor that efforts put are according to schedule. Organize task network. Assign backup staff member as third party for testing and review. Update the employers regularly about the status and working assumptions. Get Customers’ feedback periodically Involve the end users in development of the system. Develop techniques to evoke favourable responses from the users.

5. PROJECT DESIGN 5.1 ARCHITECTURAL DESIGN

26

5.2 DATABASE DESIGN TOKEN DATABASE Attributes

Data type

Key specified

Default

Description

Vehicle_no

Varchar(12)

PRIMARY KEY, FOREIGN KEY

-

Vehicle plate no.

Time

NOT NULL

-

Time of arrival

number

FOREIGN KEY

-

Slot allotted for parking

Entry_time Slot_no

SLOT DATABASE Attributes

Data type

Key specified

Default

Description

Slot_no

number

PRIMARY KEY

-

Slots of parking lot

Slot_status

Varchar(8)

NOT NULL

“unfilled”

Tells about empty and filled slots

Slot_type

Varchar(2)

NOT NULL

-

2 wheeler of 4 wheeler slot

27

PARKING_TICKET DATABASE Attributes

Data type

Key specified

Default

Description

Vehicle_no

Varchar(12)

PRIMARY KEY

-

vehicle plate no.

Entry_time

Time

NOT NULL

-

Time of arrival

Exit_time Vehicle_type

Time number

NOT NULL NOT NULL

-

Time of exit

Slot_no

number

NOT NULL

Payment_type

Varchar(4)

NOT NULL

“CASH”

mode of payment

ALLOW NULL

-

Contact no of vehicle owner

NOT NULL

-

Parking charges

Contact_no Fee

number Decimal(3,2)

Vehicle is 2 wheeler or 4 wheeler Empty Parking slot

DATABASE CONNECTIVITY DIAGRAM

28

5.3 COMPONENT LEVEL DESIGN

1

Void payment_collection() { Ttime=0; sslotno=0; Cout<<”enter entry time and slot no\n”; Cin>>ttime>>slotno;

2 3

If ((ttime==entry_time)&& (sslotno==slot)) { If (payment_type==”card”) Cout<<”Money detected from the card\n”; Else Cout<<”Cash balance clearing\n”; Break; } Else { Cout<<”Invalid Entry….Try Again Later\n”; Break; } Cout<<”Thank You for using Parking System\n”;

4 5 6 7

8 9 10 }

29

6. TESTING 6.1 TESTING STRATEGY UNIT TESTING  Focuses testing on the function or software module.  Concentrates on the internal processing logic and data structures.  Is simplified when a module is designed with high cohesion.  Reduces the number of test cases.  Allows errors to be more easily predicted and uncovered.  Concentrates on critical modules and those with high cyclomatic complexity when testing resources are limited.

Targets for Unit Test

• Module interface

Ensure that information flows properly into and out of the module

• Local data structures

Ensure that data stored temporarily maintains its integrity during all steps in an algorithm execution

30

• Boundary conditions

Ensure that the module operates properly at boundary values established to limit or restrict processing

• Independent paths (basis paths)

Paths are exercised to ensure that all statements in a module have been executed at least once

Common Computational Errors in Execution Paths • Misunderstood or incorrect arithmetic precedence • Mixed mode operations (e.g., int, float, char) • Incorrect initialization of values • Precision inaccuracy and round-off errors • Incorrect symbolic representation of an expression ( int vs. float)

31

6.2 WHITE BOX TESTING

1

Void payment_collection() { Ttime=0; sslotno=0; Cout<<”enter entry time and slot no\n”; Cin>>ttime>>slotno;

2 3 4 5 6 7

8 9 10

}

If ((ttime==entry_time)&& (sslotno==slot)) { If (payment_type==”card”) Cout<<”Money detected from the card\n”; Else Cout<<”Cash balance clearing\n”; Break; } Else { Cout<<”Invalid Entry….Try Again later\n”; Break; } Cout<<”Thank You for using Parking System\n”;

32

Flow graph

33

BASIS PATH CALCULATION CYCLOMETIC COMPLEXITY [V (G)]: 1) V (G) =No. Of Regions = 4 {R1, R2, R3, R4} 2) V(G) =E-N+2 ;Where E=no. of edges , N=no. of nodes =12-10+2 =4 3) V(G) = P+1 ; Where P= no. of predicate nodes = 3+1

P= {2, 3, 4}

=4

NUMBER OF INDEPENDENT PATHS:    

1->2->3->4->5->7->10 1->2->3->4->6->7->10 1->2->3->8->9->10 1->2->8->9->10

34

7. REFERENCES 1) Software Engineering, A Practitioner’s Approach Sixth Edition by Roger S. Pressman. 2) Software Engineering by Pankaj Jalote. 3) www.en.wikipedia.com.

35