PROJECT REPORT

ON

DESIGN AND DEVELOPMENT OF DRIVER MANAGEMENT SYSTEM

(Monthly Basis Driver Module)

FOR

Indian Drivers Private Limited

BY

Mr. Abhiram A. Sadhu

Seat No. 14841

AT

SAVITRIBAI PHULE PUNE UNIVERSITY

MASTER OF COMPUTER APPLICATION

PIMPRI CHINCHWAD EDUCATION TRUST’S

PIMPRI CHINCHWAD COLLEGE OF ENGINEERING

SECTOR NO. 26, PRADHIKARAN, NIGDI, PUNE-411044

2016-2019
 ACKNOWLEDGEMEMNT

The completion of any project is always due to the efforts from numerous people, so no project would

be considered complete without a word of appreciation for all those who contribute to the project.

I wish my sincere gratitude to the “ID Software Solutions” for giving me an opportunity to work with

them and especially Mrs. Zeba Pathan, External project guide for her valuable guidance.

It is also great pleasure to express my sincere gratitude to Dr. A. M. Fulambarkar, Principal for

providing me with excellent facilities and valuable guidance.

I would like to express my sincere gratitude to Prof. Anjana R. Arakerimath, HOD MCA for her

valuable guidance and suggestions to finish the project successfully.

I express my gratitude towards the efforts taken by Prof. Dipali N. Railkar, Internal project guide

for her tremendous support and help during the development of the project.
 Index

Chapter Chapter Name

No.
1 INTRODUCTION
1.1 Company Profile
1.2 Existing System and Need for System
1.3 Scope of Work
1.4 Operating Environment – Hardware and Software
1.5 Detail Description of Technology Used
2 PROPOSED SYSTEM
2.1 Proposed System
2.2 Objectives of System
2.3 User Requirement
2.4 Work Flow Diagram
3 ANALYSIS & DESIGN
3.1 Class Diagram
3.2 Use Case Diagrams
3.3 Activity Diagram
3.4 Sequence Diagram
3.5 Component Diagram
3.6 Deployment Diagram
3.7 Module Hierarchy Diagram
3.8 Module Specifications
3.9 Input and Output Screens
3.10 Table specifications:
3.10.1 Entity Relationship Diagram
3.10.2 Data Dictionary
3.10.3 Table Design
3.11 Test Procedures and Implementation
4 USER MANUAL
4.1 User Manual
5 DRAWBACKS AND LIMITATIONS
6 PROPOSED ENHANCEMENTS
7 CONCLUSION
8 BIBLIOGRAPHY(References)
9 ANNEXURES:
ANNEXURE 1 : Source Code / Algorithm
1.1 Company Profile:

Indian Drivers represent as a Professional Car Driver Management Company

engaged in providing Car drivers to individuals and corporates. Indian Drivers
started its business activities in the year 2009 having corporate registered office
at Sadashiv Peth, Pune. Company providing car driver services on Daily,
Monthly and Annual basis or as per customer requirement.

Indian Drivers having registrations of more than 10000 car drivers in Pune
region, which are growing month on month. Indian Drivers started its business
activities with a vision to create employment opportunities to car drivers
without any cost part as a social responsibility.

Indian Drivers not only take the responsibility to provide reliable

drivers but also involved into payroll management of provided drivers
i.e. Salaries, advances, statutory compliances etc.

Indian Drivers served more than 40,000 customers all over Pune and
Pimpri Chinchwad which consists Individuals, SMEs and Large
corporates. Company management have been working 24*7 for applying
thoughts, conducting survey, create and innovate new mantras for
corporate and individual driver management. Routine business activities
are managed by qualified staff members in professional manner which
consists multiple division viz.HR, Accounts, Sales, Relationship etc.
As mobile technology is becoming more adaptable, the trend of using smart
devices is growing like wildfire, and there is in fact no stoppage. Looking at
market need & scenario Indian Drivers Launched mobile application for
Customer and Drivers.

The Entire on demand/ Hourly basis car driver requirements taken care by
technology platform which is managed by our group Firm ID Software
solutions. This application has three parts viz. Web Portal for Staff, Admin,
Customer mobile app and Driver application. Customer app enable app user
to add booking/trip i.e. Local / Outstation, Monthly drivers as per their
requirement whereas Driver application help driver to choose booking as per
his convenience. Indian Drivers manages and monitor entire activities on
admin application for smooth running of the business.
1.2 Existing System and Need for System

Existing System

• Customer calls to Indian Drivers for Driver Booking when they are
having requirement of Driver

• After that Indian Driver’s employee calls to driver for job allocation.
Based on this duty driver was having a choice to finalize the trip.

• Then employee calls to customer for confirmation and finalization of

driver.

• In this process there was an issue of start time and stop time as well
as confirmed driver allotment and fixed trip fares.
Need for System:

 “Design and Development of Driver management System” will help

users and help desk of the company for booking processes and various
reports will be generated through system.

 It will be simple process for customers to find a driver on their

requirements and also for the driver to select compatible duty.

 This system will provide the direct interaction of drivers and customers
which will reduce communication gap.
1.3 Scope of Work

 System will provide features like add, delete, modify customers and

drivers.

 Through system fixed fare calculations can be done.

 Scheduling of drivers as per customer needs can be made.

 This system will provide reliable services to customers according to their

driver convenience.
1.4 Operating Environment –Hardware & Software
Hardware Requirement

Component Minimum Recommended

Processor 1 GHz Pentium4 and more

RAM 2 GB 4 GB

Hard disk 20GB 30GB

Software Requirement
Component Minimum Recommended

O/S Windows 7 and above Any

HTML,
AngularJS,
Development NodeJS
tools PostgreSQL Database
1.5 Detail Description of Technology Used
Angular JS
AngularJS is a JavaScript-based open-source front-end web framework mainly
maintained by Google and by a community of individuals and corporations to address
many of the challenges encountered in developing single-page applications.
It aims to simplify both the development and the testing of such applications by
providing a framework for client-side model-view-controller (MVC)
and model-view-view model (MVVM) architectures, along with components
commonly used in rich Internet Applications.

Node JS
Node JS is an open-source, cross-platform JavaScript run-time
environment that executes JavaScript code outside of a browser. JavaScript is
used primarily for client-side scripting, in which scripts written in JavaScript
are embedded in a webpage's HTML and run client-side by a JavaScript engine
in the user's web browser. Node.js lets developers use JavaScript to write
command line tools and for server-side scripting—running scripts server-side
to produce dynamic web page content before the page is sent to the user's web
browser. Consequently, Node.js represents a "JavaScript everywhere"
paradigm, unifying web application development around a single programming
language, rather than different languages for server side and client side scripts.
PostgreSQL
PostgreSQL, often simply Postgres, is an open source object-relational
database management system with an emphasis on extensibility and standards
compliance. It can handle workloads ranging from small single-machine
applications to large Internet-facing applications with many concurrent users.
PostgreSQL is developed by the PostgreSQL Global Development Group, a
diverse group of many companies and individual contributors. It is free and
open-source, released under the terms of the PostgreSQL License, a permissive
software license.

Strongloop
Strongloop is the (IBM) company that has built an API Platform which features
the open source Loopback framework. Loopback enables you to quickly
compose APIs and runs on top of the express framework. It could've been
named Strongloop Loopback Starter. In addition to the loopback framework, the
Strongloop API Platform also includes the Arc graphical UI, which has tools for
building, profiling, and monitoring Node Apps. You could create your API
using Loopback & then monitor & profile that API using Arc. Both are a part of
the strongloop platform.
2.1 Proposed System
In the proposed System we will provide automation to all the manual
process performed by customer, driver and staff.

 Admin can manage all the activities through web portal.

 Admin can allocate driver to customer booking.
 Registration of new driver will be done by admin.
 Transparency and fixed fare charges will be calculated for the
customers.
 Calculation of fare will be made automatically as per the time and
distance travelled.
2.2 Objective of the Project
 To make drivers available to customers according to their requirements.

 To have clear and perfect fare calculations.

 To maintain information of an experienced and professional driver.

 To provide new driver if the allotted driver is unavailable.

2.3 User Requirement

 Any individual with basic knowledge of computer can easily execute

web-based driver management system functionalities.

 Web based driver management system make it extremely fast and

secure.

 Once a user is assigned a role in the system, user can perform all the
functionalities of role assigned. All the information about customer and
driver should be available on same platform.

 It should give the error message if the data is invalid. If user input
invalid data then it verifies the data with the database and gives error
message.
2.4 Work Flow Diagram
3.1 Class Diagram
3.2 Use Case Diagram
1. Use Case Diagram For Staff
2. Use Case Diagram For Staff
3.4 Sequence Diagram
1. Sequence Diagram for providing access to driver and bookings
2. Sequence Diagram for payment process
3.3 Activity Diagram
3.5 Component Diagram
3.6 Deployment Diagram
3.7 Module Hierarchy Diagram:
3.8 Module Specification

1. Manage Customer
Here Admin can view, add, update and delete the customers. Also,
admin can search the customers using mobile number or name.

2. Manage Driver
In this section Admin can view, add, update and delete the drivers.
Also, admin can search the drivers using mobile number or name.

3. Monthly Driver Request

The bookings for monthly driver can be created here by admin or
admin can view, update or delete the existing bookings made by
customers.

4. Analysis
This section includes various analysis reports such as booking analysis
reports, search analysis report by user and overall analysis report.

5. Job Report
In this section new job report can be added as well as search for
existing job request and new job request can be searched.

6. Billing Customer Report

In here the monthly customer billing of both companies can be
calculated. Also, searching of bill of customer and search of total bills
can be calculated.
3.10.1 Entity Relationship Diagram
3.10.2 Data Dictionary:
Sr. Size
Field Name Datatype Constraint Table name Description
No (Bytes)
character Driver Account
1 account_number N Not Null driver_details
varying Number
double company2_cu Driver's advance
2 advance_amount 8 Not Null
precision stomer_bills amount
3 agent_id bigint 8 Primary Key agent Agent's ID
Date of
agreement_end_ company2_cu
4 date 4 Not Null agreement to be
date stomer_details
ended
How many
agreement_numb company2_cu
5 integer 4 Not Null agreements have
er stomer_details
been done
agreement_start_ company2_cu Start of
6 date 4 Not Null
date stomer_details agreement
double company2_bil Total amount in
7 amount 8 Not Null
precision l_details bill details
8 analysis_id bigint 8 Primary Key analysis ID of analysis
character Driver's bank
9 bank_name N Not Null driver_details
varying name
company2_bil
10 bd_id bigint 8 Primary Key ID of Bill details
l_details
company2_cu
bill_date date 4 Not Null Date of Bill
11 stomer_bills
company2_cu
12 bill_from_date date 4 Not Null Gross bill date
stomer_bills
company2_cu
13 bill_to_date date 4 Not Null Gross bill date
stomer_bills
character company2_cu Company or
14 bill_type N Not Null
varying stomer_bills personal bill
character permanent_dri
15 car_type N Not Null Type of car
varying ver_request
16 cb_id bigint 8 Primary Key company2_cu ID of Customer
Sr. Size
Field Name Datatype Constraint Table name Description
No (Bytes)
stomer_bills Bill
double company2_cu
17 cgst 8 Not Null CGST
precision stomer_bills
character company2_cu Name of
18 company_name N Not Null
varying stomer_details Company
company2_custo company2_cu ID of Customer
19 bigint 8 Foreign Key
mer_id stomer_bills Bill
contact_person_ character company2_cu Email of
20 N Not Null
email varying stomer_details customer
contact_person_ character company2_cu Name of
21 N Not Null
name varying stomer_details customer
22 conuser_id bigint 8 Foreign Key agent Id of conusers
Company Police
23 cpv boolean 1 Not Null driver_details
Verification
ID of a person
24 created_by bigint 8 Foreign Key agent who has created
the booking
Name of person
created_by_nam character permanent_dri
25 N Not Null who has created
e varying ver_request
the booking
timestam Date on which
26 created_date p with 8 Not Null agent booking has
time zone been created
company2_cu
27 cust_id bigint 8 Primary Key ID of Customer
stomer_details
company2_cu ID of Customer
28 cust_rate_id bigint 8 Primary Key
stomer_rate defined Rate
character The batch of
29 driver_batch N Not Null driver_details
varying driver
Autogenerated
30 driver_code bigint 8 Not Null driver_details
Driver code
31 driver_id bigint 8 Primary Key driver_details ID of Driver
driver_job_re
32 driver_job_id bigint 8 Foreign Key Driver job detail
quest
33 driver_name character N Not Null company2_cu Name of Driver
Sr. Size
Field Name Datatype Constraint Table name Description
No (Bytes)
varying stomer_details
permanent_dri
34 duty_hours bigint 8 Not Null Hours of duty
ver_request
character
emergency_num Emergency
35 varying N Not Null driver_details
ber number
(15)
character Address of
36 free_address N Not Null driver_details
varying driver
character company2_cu
37 gstin_number N Not Null GST number
varying stomer_details
character company2_cu
38 hsa_number N Not Null Duty number
varying stomer_details
character
39 ifsc_code N Not Null driver_details IFSC code
varying
character Is the vehicle
40 is_luxury N Not Null driver_details
varying luxury
company2_cu
41 item_id bigint 8 Foreign Key ID of Item
stomer_rate
character company2_ite
42 item_name N Not Null Name of Item
varying ms
double company2_ite
43 item_value 8 Not Null Value of Item
precision ms
company2_ite Company Police
44 items_id bigint 8 Primary Key
ms Verification
driver_job_re
45 job_request_id bigint 8 Primary Key Id of job request
quest
character company2_cu
46 landline N Not Null Landline number
varying stomer_details
character
47 micr_code N Not Null driver_details MICR
varying
character
48 month N Not Null analysis Months
varying
double company2_cu
49 monthly_salary 8 Not Null Monthly Salary
precision stomer_details
50 nature_of_duty character N Not Null permanent_dri Home, Office,
Sr. Size
Field Name Datatype Constraint Table name Description
No (Bytes)
varying ver_request School
double company2_cu
51 net_amount 8 Not Null Net Amount
precision stomer_bills
52 nt_date date 4 Not Null driver_details NT date
Duty hours if
53 outstation_duty boolean 1 Foreign Key analysis
outstation
permanent_dri Id of permenent
54 pdr_id bigint 8 Primary Key
ver_request driver request
Permenent
permanent_addre character
55 N Not Null driver_details Address of
ss varying
driver
Police
56 pv boolean 1 Not Null driver_details
Verification
double company2_bil Quantity of
57 quantity 8 Not Null
precision l_details items
double company2_bil
58 rate 8 Not Null Defined Rate
precision l_details
double company2_cu Received amount
59 received_amount 8 Not Null
precision stomer_bills of customer
received_bill_dat company2_cu Date of bill
60 date 4 Not Null
e stomer_bills received
character company2_cu
61 remark N Not Null Remark on bills
varying stomer_bills
character company2_cu Reverse
62 reverse_charge - Not Null
(1) stomer_bills travelling
character permanent_dri
63 salary_budget N Not Null Budget of salary
varying ver_request
double company2_cu
64 sgst 8 Not Null SGST
precision stomer_bills
character company2_cu
65 status N Not Null Status
varying stomer_bills
double company2_cu Total of Sub
sub_total 8 Not Null
66 precision stomer_bills amounts
double company2_cu
67 total 8 Not Null Total
precision stomer_bills
Sr. Size
Field Name Datatype Constraint Table name Description
No (Bytes)
double
68 total_overtime 8 Not Null analysis Total Overtime
precision
double
69 total_time 8 Not Null analysis Total time period
precision
70 tr_date date 4 Not Null driver_details TR date
character company2_bil
71 unit N Not Null Unit
varying l_details
Updated by
72 updated_by bigint 8 Foreign Key agent user/customer/dr
iver
timestam
73 updated_date p without 8 Not Null agent Date on updated
time zone
timestam
company2_cu Value defined by
74 value p without 8 Not Null
stomer_details customer
time zone
double company2_cu
75 vehicle_name 8 Not Null Name of Vehicle
precision stomer_rate
character company2_cu
76 vehicle_type N Not Null Type of Vehicle
varying stomer_details
character company2_cu Weekday of
77 weekly_off N Not Null
varying stomer_details leave
character company2_cu
78 year N Not Null null
varying stomer_details
3.10.3 Table Specification
1. Agent
Table Name Agent
Description This table stores information about agents.

Sr. Field Name Datatype Size Constraint

No. (Bytes)
1 agent_id bigint 8 Primary Key
2 conuser_id bigint 8 Foreign Key
3 created_by bigint 8 Not Null
4 created_date timestamp with time zone 8 Not Null
5 updated_by bigint 8 Not Null
6 updated_date timestamp without time 8 Not Null
zone

2. Analysis
Table Name Analysis
Description This table stores analysis details.

Sr. Field Name Datatype Size Constraint

No. (Bytes)
1 analysis_id bigint 8 Primary Key
2 month character varying N Not Null
3 year bigint 8 Not Null
4 total_time double precision 8 Not Null
5 total_overtime double precision 8 Not Null
6 outstation_duty boolean 1 Not Null
3. company2_customer_details
Table Name Company2_customer_details
Description This table stores the information customers opted the
monthly booking.

Sr. Field Name Datatype Size Constraint

No. (Bytes)
1 customer_id bigint 8 Primary Key
2 conuser_id bigint 8 Foreign Key
3 agreement_number integer 8 Not Null
4 landline character varying N Not Null
5 contact_person_name character varying N Not Null
6 contact_person_email character varying N Not Null
7 vehicle_name character varying N Not Null
8 vehicle_type character varying N Not Null
9 gstin_number character varying N Not Null
10 hsa_number character varying N Not Null
11 duty_hours integer 4 Not Null
12 weekly_off character varying N Not Null
13 agreement_start_date date 4 Not Null
14 agreement_end_date date 4 Not Null
15 company_name character varying N Not Null
16 created_by bigint 8 Nullable
17 created_date timestamp with time 8 Nullable
zone
18 updated_by bigint 8 Nullable
19 updated_date timestamp without 8 Nullable
time zone
20 monthly_salary double precision 8 Not Null
21 driver_name character varying N Not Null
4. company2_customer_rate
Table Name Company2_customer_rate
Description This table stores the budget rate of a customer

Sr. Field Name Datatype Size Constraints

No. (Bytes)
1 rate_id bigint 8 Primary Key
2 company2_customer_id bigint 8 Foreign Key
3 item_id bigint 8 Foreign Key
4 value double precision 8 Not Null
5 unit character varying N Not Null

5. company2_items
Table Name Company2_items
Description This table stores the hourly charges for a transaction.

Sr. Field Name Datatype Size Constraints

No. (Bytes)
1 items_id bigint 8 Primary Key
2 item_name character varying N Not Null
3 item_value double precision 8 Nullable
4 created_by bigint 8 Nullable
5 created_date timestamp with time 8 Nullable
zone
6 updated_by bigint 8 Nullable
7 updated_date time without time zone 8 Nullable

6. company2_bill_detail
Table Name Company2_bill_detail
Description This table stores the customer bill details

Sr. Field Name Datatype Size Constraints

No. (Bytes)
1 bill_details_id bigint 8 Primary Key
2 bill_id bigint 8 Foreign Key
3 item_id bigint 8 Foreign Key
4 amount double precision 8 Not Null
5 created_by bigint 8 Nullable
6 created_date timestamp with time zone 8 Nullable
7 updated_by bigint 8 Nullable
8 updated_date timestamp without time 8 Nullable
zone
9 quantity double precision 8 Not Null
10 rate double precision 8 Not Null
11 unit character varying N Not Null

7. company2_customer_bills
Table Name Contact
Description This table stores the customer bill

Sr. Field Name Datatype Size Constraints

No.
1 bill_id
2 company2_custo
mer_id
3 bill_date
4 total
5 created_by
6 created_date
7 updated_by
8 updated_date
(Bytes)
bigint 8 Primary Key
bigint 8 Foreign Key
date 8 Foreign Key
double precision 8 Not Null
bigint 8 Nullable
timestamp with 8 Nullable
time zone
bigint 8 Nullable
timestamp without 8 Nullable
 time zone
9 sub_total double precision 8 Not Null
10 cgst double precision 8 Not Null
11 sgst double precision 8 Not Null
12 status character varying 8 Not Null
13 bill_from_date date 4 Not Null
14 bill_to_date date 4 Not Null
15 reverse_charge character (1) - Not Null
16 advance_amount double precision 8 Not Null
17 net_amount double precision 8 Not Null
18 bill_type character varying N Not Null
19 received_bill_date date 4 Not Null
20 received_amount double precision 8 Not Null
21 remark character varying N Not Null

8. permanent_driver_request
Table Name Permanent_driver_request
Description This table stores the information about permanent
driver requests

Sr. Field Name Datatype Size Constraints

No. (Bytes)
1 permanent_id bigint 8 Primary Key
2 customer_id, bigint 8 Foreign Key
3 status character varying N Not Null
4 created_by bigint 8 Not Null
5 created_date timestamp with 8 Not Null
time zone
6 updated_by bigint 8 Nullable
7 updated_date timestamp without 8 Nullable
time zone
8 remark character varying N Not Null
9 created_by_name character varying N Not Null
10 car_type character varying N Not Null
11 duty_hours bigint 8 Not Null
12 salary_budget character varying N Not Null
13 nature_of_duty character varying N Not Null
14 weekly_off character varying [] N Not Null

9. driver_details
Table Name Driver_details
Description This table stores the information about drivers

Sr. Field Name Datatype Size Constraint

No. (Bytes)
1 driver_id bigint 8 Primary Key
2 conuser_id bigint 8 Foreign Key
3 is_luxury character varying N Not Null
4 permanent_address character varying N Not Null
5 account_number character varying N Not Null
6 ifsc_code character varying N Not Null
7 micr_code character varying N Not Null
8 created_by bigint 8 Not Null
9 created_date timestamp with time 8 Not Null
zone
10 updated_by bigint 8 Nullable
11 updated_date timestamp without 8 Nullable
time zone
12 bank_name character varying N Not Null
13 pv boolean 1 Not Null
14 cpv boolean 1 Not Null
15 emergency_number character varying (15) n Not Null
16 tr_date date 4 Not Null
17 nt_date date 4 Not Null
18 driver_batch character varying N Not Null
19 free_address character varying N Not Null
20 driver_code bigint 8 Not Null
21 remark character varying N Nullable
 10. driver_job_request
Table Name Driver_job_request
Description This table stores the information about drivers job
request
Sr. Field Name
No.
1 request_id
2 driver_job_id
3 driver_id
4 remark
5 created_by
6 created_date
7 updated_by
8 updated_date
9 created_by_name
10 status
3.11 User Interface Design
Input Screens
Login Screen
Datatype Size Constraint
(Bytes)
bigint 8 Primary Key
bigint 8 Foreign Key
bigint 8 Foreign Key
character varying N Nullable
bigint 8 Not Null
timestamp with 8 Not Null
time zone
bigint 8 Nullable
timestamp without 8 Nullable
time zone
character varying N Not Null
character varying N Not Null
Home Page
Add Driver
New Driver Update after PV and CPV
Add Customer
Monthly Driver Request
Monthly Driver Request New Booking
Monthly Driver Request Searching
Output Screens
Booking Analysis Report searching

Bookings search result report

Search Analysis Report By User Searching
Analysis Result by User Report
Overall Analysis Report
Driver Transaction History:
Bill Generation for specific customer
Bill of a customer
Bill of a Customer
3.11 Test Procedures and Implementation
1. Test plan identifier

Test plan for Design and development of Driver Service

Administration Portal 1.0

2. Reference

The test plan is prepared based on project documents and in

consideration with documents required to cover all the test cases for
the project.
Documents that are used for reference:
1. Requirements specifications
2. Detail design document

3. Introduction

The aim of this document is to develop a test plan for the driver
service administration portal. The objectives of the test plan are to
define the activities for performing testing process, define the test
deliverable documents and to identify the schedule and staff require
for various activities in testing.

4. Features to be tested

The following list describes the features to be tested:

 Registration
 Driver Booking
 Analysis
 Job report

5. Approach
 This section describes the overall approach of the testing which ensures that
each feature and the combination of the features are adequately tested.

The levels of testing that are performed through this test plan are:

5.1 Unit testing

Unit testing is a method to verify the individual units of source code are
working properly. The purpose of unit testing is to isolate each part of the
program and show that the individual parts are correct. This process is applied
to all the modules of my project. The Basic modules Booking of Driver and
registration is thoroughly testing and that test cases are shown below.

5.2 Integration testing

Integration testing is used for checking the interface between two components.

It is used for checking for different modules are working with each other in
correct way.

To identify the error, appear in the two different interfaces this type of testing
is used. Example: Booking of Driver and booking history.

6. Pass/Fail criteria
The system should satisfy all the functional requirements, in the SRS
document. Each feature to be tested will be evaluated against its requirement as
stated in the SRS Document. The pass or fail of a test depends on whether the
system meets with all the particular post conditions. Test cases executed on the
Automation will pass if they meet the specific requirements as mentioned in
the SRS Document.

7. Suspension criteria and resumption requirements

7.1 Suspension criteria
If the system contains one or more critical defects like the defects in the GUI
editor the entire system should be suspended.
The testing may also be suspended if the hardware and software components
required are not available on time.
The failed test cases should be recorded along with the description for failure.

7.2 Resumption requirement

When a new version of the system is transmitted to the test group after a
suspension of testing has occurred, all previous tests will be rerun to ensure
program changes have not inadvertently affected other portions of the program.

8. Test deliverables
The following documents are available for test deliverables
1. Test plan
2. Test case
3. Test input and output data
9. Schedule

Sr. No. Test Name Dates

1 Unit Testing- 05/03/2019
Black Box Testing to 09/03/2019

2 Integration Testing 12/03/2019

to 21/03/2019

3 System Testing 22/03/2019

To 04/04/2019
 Add Customer

ADD_CUST_DMS_01:
To check the functionality of adding customer.
Fill the valid details of user and click on ADD CUSTOMER button
System will generate the message “Customer added successfully”.
ADD_CUST_DMS_02:
To check the functionality of adding customer.
Fill the Invalid details of user and click on ADD CUSTOMER button.
System will generate the message “Please fill out this field”

Monthly Driver Request

MNTH_DRV_DMS_01: To check the functionality of Monthly Driver

Booking.
Fill the valid details of monthly driver request and click on ADD REQUEST
button.
System will generate the message “Request posted successfully”

MNTH_DMS_02: To check the functionality of Monthly Driver Booking.

Fill the Invalid details of monthly driver request and click on ADD REQUEST
button.
System will generate the message “Please fill this field”.

1.Test Case for Adding Customer

Test Case ID: ADD_CUST_DMS_01 Test Designed by: Abhiram Sadhu
Test Priority (Low/Medium/High): High Test Designed date: 05/03/19
Module Name: Adding Customer Test Executed by: Abhiram Sadhu

Test Title: To validate the add customer module Test Execution date: 06/03/19
with Proper validation
Description: To check the validation of adding customer Module in the application
Pre-conditions: Application should be properly installed and registration page should be
open.
Test Case Id Steps to be Test Data Expected Actual Pass/ Remark
executed Result Result Fail

VALID INPUT DATA

ADD_CUST_D 1.Enter Name Abhiram User User is Pass

MS_01 Sadhu should navigated
8007899492 navigate to to next
2.Enter Mobile the next page.
page
3. Enter the abhiramsadhu1 without
Email Id @gmail.com error and
will
display the
4.Enter Status Active message”
Customer
added
5. Landmark Akurdi Successful
ly”
6.Customer
R
Type

7.Address Akurdi
 INVALID INPUT DATA

ADD_CUST_D 1.Enter Name Fgdfjdfl Applicatio Applicatio Pass

MS_02 n should n displays
display the the
2.Enter Mobile 9879898f99 message message
“Please “Please
3. Enter the
enter valid enter valid
#abc@gmail.co
Email Id details and details and
m
try Again” try Again”

4.Enter Status
Active

5. Landmark
Dehu

6.Customer
Type
A

7.Address
Dehu

Monthly Driver Request Test Case

Test Case ID: MNTH_DRV_DMS_01 Test Designed by: Abhiram Sadhu
Test Priority (Low/Medium/High): High Test Designed date: 12/03/2019
 Module Name: Monthly Driver Request
Module Test Executed by: Abhiram Sadhu
Test Title: To validate the Monthly Driver
Request with Proper validation Test Execution date: 15/3/2019
Description: To check the validation of Monthly Driver Request in the application
Pre-conditions: Application should be properly installed and login page should be open.

Test Case Id Steps to be Test Data Expected Actual Pass/ Remark

executed Result Result Fail

VALID INPUT DATA

MNTH_DRV 1. Car type Automatic User User is Pass

_DMS_01 should navigated
navigate to to next
2. Duty hours 11 the next page.
page
3. Salary budget 12000 without
error.

4.Weekly off Saturday

5. Nature of Home to office

duty
6. Remark
Fluent English
INVALID INPUT DATA

MNTH_DRV 1. Car type Manual It should It displays

_DMS_02 display message
message “Invalid
2. Duty hours 13 “Invalid Details”,
Details”, and
 and navigate to
navigated to monthly
3. Salary budget 14000 monthly driver
driver request
request page.
4.Weekly off NA page.

5. Nature of Home to office

duty
6. Remark
NA

4.1 User Manual

Although the user interface of the system is constructed in such a way

that person with particular access can use the system if he has the basic
knowledge of operating keyboard and mouse operation of a computer.
 All pages of the application contain the descriptive links and the buttons
that will help the user to perform the required operation.

The following section provides the details, which can be very useful for
using the system. The Description is much in detail so that any user can
use it very easily.

1.2 Operations Manual / Menu Explanation

Step 1: Login with proper credentials.

 Step 2: Select the desired tile from dashboard

Step 3: Let’s take an example of new booking.

 Step 4: After clicking on new booking we get the following popup.

Step 5: Fill the details and click add request the booking will be saved.
Another Example will be Analysis reports
Step 6: In booking analysis report enter from date and to date and click search:

Report

Step 7: In search analysis report by user enter the same along with user name or
number.
 Report

Step 8: Select required year and quarter from another drop box.
5. Drawback and Limitations
Drawback

 There is a manual process of interviewing the driver by customer and

company.
 Agents in the company, who have to visit customers opted for monthly
drivers at their house or working places.
 The PostgreSQL is not a distributed database that’s why manual backups
are necessary.

Limitations

 PostgreSQL isn’t distributed database.

 Google API key’s need to be updated each month.
 Company users and help desk can use this system.
 Adding new city requires changes in database directly.

6. Proposed Enhancement
The system can be enhanced in future. More features can be added to the
system such as

 It will provide a facility to pay using different online payment modes.

 Distributed database and parallel processing will be adopted.
 New feature for adding cities will be provided.

7. Conclusion
This is my first experience to perform such as professional work. I learnt

lot from this project and specially how to apply the technical skills at

different stages of software development.

While implementing “Driver Management System” I got conceptual and

practical knowledge of software engineering, system analysis and real

time experience of project implementation.

The “Driver Management System” web portal will provide interface over

drivers and customer dynamically to the organization. Through this system it

combines data of driver, customer and the employees of the organization.

Extending this module can generate fare bill calculations and different reports

required for analysis.

8. BIBLIOGRAPHY
 Books:
1. “UML” – by Mahesh Martha.

2. “Practical Node.js: Building Real-World Scalable Web Apps”

– by Azat Mardan

3. “Practical PostgreSQL” – by John C. Worsley and Joshua D. Drake

4. “Beginning JSON” - Book by Ben Smith

Websites:
1. https://loopback.io/doc/

2. https://tutorialspoint.com

3. https://stackoverflow.com

4. https://github.com/github

9. ANNEXURES:
Source Code