GPS Based Bus Management 

 
System 

Software Engineering
Project Report
(CSHP - 410)

Submitted by: Under the supervision of

2013
Keshav Mahavidyalaya
University of Delhi
Table of Contents

Problem Statement 3

1 INTRODUCTION 4

1.1 Purpose 4

1.2 Scope 4

1.3 Definitions 4

1.4 Overview 4

2 Software Requirement Specification 5

2.1 Data Flow Diagram 5

2.1.1 DFD Level 0 5

2.1.2 DFD Level 1 6

2.1.3 Data Dictionary 7

3 Project Management 9

3.1 Cost Estimations 9

3.1.1 Functional Point Estimation 9

3.1.2 Efforts 10

3.2 Schedule 11

3.3 Risk Table 11

4 Design Engineering 12

4.1 Architectural Design 12

4.2 Entity- Relationship Diagram 13

5 Testing 14
 Problem Statement

Problem Analysis:-

1. We don’t have system which could inform Passenger about their Bus Timing, Shedule
etc.
2. We only do have record of bus Timings on which bus should start on a route which is
also sometimes not followed by drivers.
3. There is no information provided to passenger about buses.

Method of Solution:-

1. The problem of bus timing and other problem could be solved by Schedule
Monitoring
of Buses.

2. Real time Information should be provided to user about their bus this could be done
by using GPS in buses.
1 INTRODUCTION

1.1 Purpose
The ​GPS Based Bus Management System (GBMS) is used to keep Track of Buses by
Company. Also this facility can be used to give information to Passenger by web and a
Display on Bus Stop​.

1.2 Scope
Many cities have found that using GPS tracking systems not only improve the efficiency of
city bus operations, but also encourage more commuters to take advantage of their city bus
systems.
Many city bus systems have discovered that GPS tracking systems which allow passengers to
monitor the location and estimated arrival time of their bus actually increases the number of
people using city buses for routine commuting. For example, if a rushed commuter can

1.3 Definitions
Our System also provides information about Buses to Passenger. ​Consider the possibility of
implementing GPS tracking systems which allow customers to monitor bus locations via
website, or cell phones. This will likely increase the satisfaction of customers. Also a display
is fixed on every Stop so passenger will know where their bus is and when will it arrive.

1.4 Overview
The purpose of this section is to obtain agreement regarding the objectives the system must
meet. Ultimately this segment defines the boundaries of the effort. The “GPS Based Bus
Management System” helps administrator honor their professional commitments by
following a tailored version of the organization’s standard process. This project aims to
provide helpful information about Bus in a given geographic area. Also it store Tracking
Information in Database. It also keep track of Bus’s speed if it is crossed the authority will
get the information.verify his or her bus is running on time via their cell phone or a website,
they are much more likely to ride the bus rather than take a cab or drive themselves.
2 Software Requirement Specification
2.1 Data Flow Diagram

2.1.1 DFD Level 0

2.1.2 DFD Level 1
2.1.3 Data Dictionary

Table 1: Bus Database

Field Name Type Description

Bus_ID Long Integer Primary Key

Route_no Integer

Emp_no Long Integer

Driver_name Character[20]

Table 2: Route

Field Name Type Description

Route_no Integer Primary Key

Route_Name Character[20]

Start Character[20]

Destination Character[20]

Path Integer Multi valued

Table 3: Stops

Field Name Type Description

Stop_id Integer Primary Key

Stop_name Character[20]

Degree_lat Float

Min_lat Float

Sec_lat Float

Degree_log Float

Min_log Float

Sec_log Float

Table 4: Main

Field Name Type Description

Bus_ID Long Integer

Route_no Integer

Route_Name Character[20]

Time Time Stamp

Loc_lat Degree Float

Min Float

Sec Float

Loc_log Degree Float

Min Float

Sec Float

Next_stop Integer

Last_stop Integer
3 Project Management

3.1 Cost Estimations

3.1.1 Functional Point Estimation

Info Domain Value Opt. Est. Count Weight FP Count

External Inputs 5 4 5 23

External Outputs 6 5 4 23

External Inquires 2 2 5 10

Internal Logical 4 3 10 35
Files

External Interface 2 1 7 11
Files

Count Total 102

FP (EST.) = Count Total * Value adjustment factor

FP (EST.) = Count Total * [0.65+0.01*​ ​Ʃ (Fi)​]

Calculation of Value adjustment factor:-

S No. Factor Values

1 Backup and Recovery 3

2 Data communication 4

3 Distributed processing 2

4 Performance Critical 3

5 Existing operating environment 1

6 Online-line data entry 2

7 Input transaction over multiple screens 2

8 ILFs update online 1

9 Information domain values complex 3

10 Internal processing complex 4

11 Code design for reuse 3

12 Conversion/installation in design 4

13 Multiple installation 1

14 Application design for change 5

Total 38

Ʃ (Fi)​] = 38

​ 8]​
Value adjustment factor= [0.65+0.01*​ 3

=0.65 + 0.38

= 1.03

FP (EST.) = 102 * 1.03

= 105.06

Our average productivity is ​8 FP/month​.

If labour rate is Rs.10000 per month.

Cost per FP is Rs. 1250.

Total ​Cost for Project​ is Rs. 130,000​.

3.1.2 Efforts
Effort= Total Functional Points/Average Productivity

= 105.06/8

=13 pm

● Our estimated ​Effort​ is 13 person-month

3.2 Schedule

S.No. Process/Phase Start Date Finish Date

1. Requirement gathering 20/01/13 15/02/13

2. Requirement analysis 16/02/13 27/02/13

3. DFD preparation 28/02/13 10/03/13

4. Data Dictionary preparation 11/03/13 20/03/13

5. Risk Management Plan 21/03/13 30/03/13

6. ERD preparation 31/03/13 10/04/13

7. FPA calculation 11/04/13 16/04/13

3.3 Risk Table

S.No RISK CATEGORY PROBABILIT IMPACT RMMM PLAN
Y
1 Some team members Technical risk 30% 2 ● Use backup staffs
leave the project which knows what was
development going on in the project.
in-between

2 Delivery deadline Project risk 30% 1 ● Team may use extra

tightened members to complete
the task on scheduled
time
3 Losing of all the project Project risk 20% 2 ● Carry out necessary
data, this may be backup of database
caused by a hard disk data, source code and
documentation
being wiped out by a
virus, hard disk failure,
etc.

4 Team dissension/lack of Project risk 10% 3 ●We could set some

cohesion guide-lines and rules
regarding how we deal
with each other .
4 Design Engineering

4.1 Architectural Design

4.2 Entity- Relationship Diagram
5 Testing

❖ Administrator module :

1. Test case: Login

Input​ :​ ​ID, Password.
Process : ​Click on the login link. If administrator enters ID and password correct it goes to
the admin services otherwise displays the same page with an error message.
Output : ​Displays the admin services page.

2. Test case: Add/Delete new Bus

Input: Bus​_Id.
Process:​ A new Bus can be added into the system and admin can update details.
Output:​ Changes will take place in Database

3. Test case: Add/Delete new Route

Input:​ Route_id
Process:​ A new Route can be added/deleted into the system and admin can update details.
Output:​ Changes will take place in Database

4. Test case: Track a Bus

Input:​ Bus_Id
Process:​ All GPS Message coming from this bus ID will be displayed through Map.
Output:​ Real Time tracking will be shown on Map.