w

Rayat Shikshan Sanstha’s

Karmaveer Bhaurao Patil Polytechnic, Satara
Micro-Project Report
ON
“ Taxi Booking System ”
Presented By

ROLL NO. NAME

02 Mr. BAGWAN SALMAN RIYAJULKARIM
04 Mr. BALLAL TANMAY NILESH
14 Mr. BORGE UDAYAN SANTOSH
07 Mr. BHOSALE AYUSH YOGESH

Program: DIPLOMA COMPUTER ENGINEERING

Class: SY-CO SECOND YEAR (Fourth Semester)
Course: Software Engineering (Subject Code: 22413 )

Guided By
Mrs. NIKAM S.A.

COMPUTER ENGINEERING DEPARTMENT

[2023-24]
 Rayat Shikshan Sanstha’s
Karmaveer Bhaurao Patil Polytechnic, Satara

CERTIFICATE

This is to Certify That

Mr. BAGWAN SALMAN RIYAJULKARIM
Mr. BALLAL TANMAY NILESH
Mr. BORGE UDAYAN SANTOSH
Mr. BHOSALE AYUSH YOGESH

Of SECOND YEAR (THIRD SEMESTER) have successfully completed the

Micro-Project work entitled “TAXI BOOKING SYSTEM ” in the course
SOFTWARE ENGINEERING of the Program of COMPUTETR ENGINEERING in
Maharashtra State of Technical Education, Mumbai, Maharashtra State.

Mrs. NIKAM S.A. Prof. GHORPADE.B.S. Prin. Shaikh K.C.

Guide Head of Department Principal
 Undertaking by Students

We will preserve micro-project and the report in our custody till end
of completion of our program. We assure that we will produce the
same whenever we or anybody from our group will be asked to
produce it without fail.

Sr. Roll Name of Student Mobile No. Signature

No. No.
1 02 Mr. Bagwan Salman 7843040936
2 04 Mr. Ballal Tanmay 7057890543
3 14 Mr. Borge Udayan 9004621876
4 07 Mr. Bhosale Ayush 7841088411
 Part A – Plan

Title of Micro-Project- TAXI BOOKING SYSTEM

1.0 Brief Introduction:

A taxi booking system is a software application designed to facilitate the booking

and management of taxi services for users and taxi drivers. It typically includes
features for both customers and drivers, as well as an administrative interface for
managing the system.
In these micro project we have gathered all the required functional and non-
functional requirements of the Taxi Booking system . Prepare the SRS document
. Draw various diagrams required for building the software such as DFD , Use
case diagram , Activity Diagram ,etc.
For customers, the system allows users to request a taxi ride, specify pickup and
drop-off locations, choose vehicle options (like sedan, SUV, etc.), view
estimated fares, track the
arrival of the assigned taxi, and make payments through various methods such as
cash, credit/debit cards, or mobile wallets.
For drivers, the system provides tools to receive and accept ride requests,
navigate to pickup and drop-off locations using integrated maps or GPS,
communicate with customers, manage their availability, track earnings, and
access reports.

2.0 Aim of the Micro-Project

The aim of a micro project for a taxi booking system could be to develop a very
good quality functional prototype or minimum viable product (MVP) that
demonstrates core features of the system.

1. Gathering all Functional and Non-functional Requirements

2. Preparing the SRS Document
3. Preparing a Use Case diagram for the project
4. Drawing the Data Flow Diagram
5. Creating Class diagram , Sequence diagram & Activity Diagram
6. Estimating the Size of the project and Cost needed for the project

Using these key points, we can build and good quality software and reach to the
needs of the
End-users stakeholders and customers.
 3.0 Action Plan

Sr. Planned Planned Name of

Details of Activity Responsible
No. Start date Finish
date Team Members
1 Topic Selection 21/09/2023 21/09/2023 All Group Members
2 Distributing of work 23/09/2023 23/09/2023 All Group Members
3 Collecting basic information 27/09/2023 29/09/2023 2,7
4 Requirements gathering 30/09/2023 01/10/2023 4,14
5 Planning about the project 11/10/2023 27/10/2023 4,14
6 Preparing the SRS document 28/10/2023 30/10/2023 All Group Members
7 Drawing Use case diagram 31/10/2023 31/10/2023 7,14
8 Creating DFD diagram 4
9 Creating Class diagram
10 Creating Sequence Diagram
& Activity diagram
11 Estimating The Cost
12 Preparing the soft copy

4.0 Resources Requires :

Sr. Resources Specification Quantity Remark

no
1 Creately.com Website Used
2 Laptop HP pavilion Used
3 Internet Google, YouTube Used
4 Teacher Guidance Used

*******************
 Part B – Outcome after Execution

Title of Micro-Project : TAXI BOOOKING SYSTEM

1.0 Brief Description:

A taxi booking system is a software application designed to facilitate the booking

and management of taxi services for users and taxi drivers. It typically includes
features for both customers and drivers, as well as an administrative interface for
managing the system.
In these micro project we have gathered all the required functional and non-
functional requirements of the Taxi Booking system . Prepare the SRS document.
Draw various diagrams required for building the software such as DFD , Use case
diagram , Activity Diagram ,etc.
For customers, the system allows users to request a taxi ride, specify pickup and
drop-off locations, choose vehicle options (like sedan, SUV, etc.), view estimated
fares, track the arrival of the assigned taxi, and make payments through various
methods such as cash, credit/debit cards, or mobile wallets.
For drivers, the system provides tools to receive and accept ride requests,
navigate to pickup and drop-off locations using integrated maps or GPS,
communicate with customers, manage their availability, track earnings, and
access reports.
The objective of creating a taxi booking software system is to provide a
convenient, accessible, and safe transportation experience for users while
optimizing resource allocation, ensuring transparent pricing, enhancing safety
measures, and leveraging data insights for operational efficiency and business
growth.
By using these various processes and techniques we can easily build a good
quality software project and deliver a product which meets the needs of the users
stakeholders and the customers.
This project gives a overview how a project is built in the companies and the
exact process both backend and frontend is observed and understood with the
help of these microproject.
 2.0 Aim of Micro Project:

The aim of a micro project for a taxi booking system could be to develop a very
good quality functional prototype or minimum viable product (MVP) that
demonstrates core features of the system.

1. Gathering all Functional and Non-functional Requirements

2. Preparing the SRS Document
3. Preparing a Use Case diagram for the project
4. Drawing the Data Flow Diagram
5. Creating Class diagram , Sequence diagram & Activity Diagram
6. Estimating the Size of the project and Cost needed for the project

Using these key points, we can build and good quality software and reach to the
needs of the
End-users stakeholders and customers.

3.0 Course Outcome Integrated:

We successfully implemented the processes which were guided by our guide and
designed or built a software project . We prepared the SRS document which had
all the details of the project. We created a Use case diagram . We also created a
sequence diagram , class diagram , activity diagram and the data flow diagram for
our project that is TAXI BOOKING SYSTEM . We also understood the
techniques used for estimating the cost of the project .

4.1 Actual Procedure Followed:

The groups were created and topics were distributed by the project guide.
The work was distributed between the group members. All the basic required
information was collected by the two of our group members. And we other two
members worked on gathering the both functional and non-functional requirements
required for our Taxi Booking System .After gathering requirements and Software
Requirement Specification document was created by one of our teammate .
Selected a suitable model for our project. We prepared a Use case Diagram using
the Creately software which is available on the Google Chrome Browser. Using
the same software our team members also created the remaining other diagrams
that are sequence diagram, the activity diagram and class diagram.
We drew the data flow diagram with the help of EDrawMax. Later we studied
about the cost estimation techniques such as Function Point & COCOMO model.
We prepared a soft copy of the whole procedure and study which we did and got it
checked from the project guide and got the final project conformed.
4.2 Actual Resources Used:

Sr. Resources Specification Quantity Remark

no
1 Creately Latest version Used
2 Laptop HP pavilion Used
3 Internet Google, YouTube Used
4 Teacher Guidance Used

5.0 Output of the Micro-Project:

We successfully implemented the processes which were guided by our guide and
designed or built a software project . We prepared the SRS document which had all
the details of the project. We created a Use case diagram . We also created a
sequence diagram , class diagram , activity diagram and the data flow diagram for
our project that is TAXI BOOKING SYSTEM . We also understood the techniques
used for estimating the cost of the project .

6.0 Skill developed / Learning out of the Micro-Project:

From this micro project we developed our skills in coding in the Course Computer
Graphics. We also got to learn about the functions of graphics files and used them to
complete our micro-project and display the output on the screen.

*********
 Topic: Taxi Booking System

Functional Requirements:
Functional requirements for a taxi booking system typically include features and
capabilities that directly contribute to the system's primary functions and user
interactions. Here are key functional requirements for a taxi booking software
system:
1. User Registration and Login:
- Users should be able to create accounts with valid credentials.
- Users should be able to log in securely to access the booking system.

2. Booking a Ride:
- Users should be able to enter their pickup location and destination.
- Users should be able to select vehicle options (e.g., sedan, SUV) if available.
- Users should be provided with estimated fares based on the selected options.

3. Real-time Availability:
- The system should display available taxis/drivers based on location and availability.
- The system should assign a taxi/driver to a user's booking request promptly.

4. Tracking and Notifications:

- Users should be able to track the assigned taxi/driver's location in real-time.
- Users should receive notifications regarding ride confirmation, driver details, and ride status
updates.

5. Payment Integration:
- Users should be able to make payments securely through various methods (e.g., cash,
credit/debit cards, mobile wallets).
- The system should integrate with a payment gateway for seamless and secure transactions.
6. Driver Functions:
- Drivers should receive ride requests and be able to accept or decline them.
- Drivers should have access to navigation tools to reach pickup and drop-off locations
efficiently.

7. Admin Dashboard:
- Admins should have access to a dashboard to manage user accounts, driver profiles, fares,
and ride requests.
- Admins should be able to view and generate reports related to system usage, earnings, and
performance metrics.

8.Rating and Review System:

- Users should be able to rate and provide feedback on their ride experience.
- Drivers should be rated based on factors such as professionalism, cleanliness, and
punctuality.

9. Data Security and Privacy:

- The system should ensure data security and privacy for user information, payment details,
and ride history.
- Compliance with relevant data protection regulations (e.g., GDPR, CCPA) should be
maintained.

These functional requirements collectively ensure a smooth and efficient booking

experience for users, effective management for drivers and administrators, and
secure transactions within the taxi booking system.
Non-Functional Requirements:
Non-functional requirements define system attributes such as performance,
security, usability, reliability, and scalability. Here are five non-functional
requirements for a taxi booking system:
1. Performance:
- Response Time: The system should respond to user interactions (booking requests, driver
assignments, etc.) within seconds to provide a seamless experience.
- Scalability: The system should be able to handle increasing numbers of users, bookings, and
concurrent transactions without significant degradation in performance.

2. Security:
- Data Encryption: User data, payment information, and sensitive details should be encrypted
to ensure confidentiality and prevent unauthorized access.
- Authentication and Authorization: Implement secure login mechanisms and role-based access
controls to ensure that only authorized users (customers, drivers, admins) can access relevant
functionalities.

3. Usability:
- User Interface Design: The user interface should be intuitive, easy to navigate, and accessible
across different devices (web, mobile apps).
- Error Handling: Provide meaningful error messages and feedback to users during booking,
payment, or any system interactions to guide them effectively.

4. Reliability:
- System Availability: Ensure high system availability (uptime) so that users can book rides at
any time without service disruptions.
- Fault Tolerance: Implement mechanisms such as data backups, redundant servers, and
failover strategies to mitigate system failures and ensure continuity of service.

5. Scalability:
-Load Balancing: Distribute incoming traffic evenly across server instances to optimize
performance and handle varying load conditions effectively.
-Database Scalability: Design the database architecture to scale horizontally or vertically to
accommodate growing data volumes and user activities without compromising performance.

These non-functional requirements are crucial for ensuring that the taxi booking
system not only functions correctly but also deliver a high-quality, secure, and
reliable experience for users, drivers, and administrators.
Software Requirements Specification (SRS)
1. Introduction
1.1 Purpose
The purpose of this document is to define the requirements for the development of a
taxi booking system to facilitate efficient and convenient taxi services for customers
and drivers.

1.2 Scope
The taxi booking system will include features for users to book rides, track taxi
locations, make payments, and for drivers to receive and manage ride requests. An
administrative interface will also be provided for system management.

1.3 Definitions, Acronyms, and Abbreviations

- SRS: Software Requirements Specification
- API: Application Programming Interface
2. Overall Description
2.1 Product Perspective
The taxi booking system will interface with mapping services for location tracking,
payment gateways for secure transactions, and will be accessible via web and
mobile
platforms.

2.2 User Classes and Characteristics

1. Customer: Can register, book rides, track taxis, and make payments.
2. Driver: Can register, accept ride requests, navigate to pick-up and drop-off
locations.
3. Administrator: Manages system settings, user accounts, driver profiles, fares, and
reports.
2.3 Operating Environment
The system will run on web servers with database support (e.g., MySQL) and will
be accessible through web browsers and mobile apps (iOS and Android).

3. System Features
3.1 User Management
- Users can register, log in, and manage their profiles.
- Admins can manage user accounts and permissions.

3.2 Booking and Ride Management

- Customers can book rides, select vehicle types, and view fare estimates.
- Drivers can accept/reject ride requests, navigate to locations, and update ride
status.

3.3 Payment Processing

- Integration with payment gateways for secure payment processing.
- Users can view payment history and receipts.

3.4 Location Tracking

- Real-time tracking of taxis/drivers using maps or GPS.

3.5 Reporting and Analytics

- Generate reports on rides, earnings, user feedback, etc.
- Analyse data to optimize operations.

4. External Interface Requirements

4.1 User Interfaces
- Customer interface for ride booking, tracking, and payments.
- Driver interface for ride management and navigation.
- Admin dashboard for system management.

4.2 Hardware Interfaces

The system will run on standard hardware configurations for web and mobile
platforms.

4.3 Software Interfaces

- Integration with mapping APIs (e.g., Google Maps API) for location services.
- Integration with payment gateway APIs (e.g., Stripe API) for payment processing.

5. Non-functional Requirements
5.1 Performance
- System should respond to user actions within 2 seconds.
- Support concurrent user access without performance degradation.

5.2 Security
- Encrypt sensitive data such as user information and payment details.
- Implement secure authentication and authorization mechanisms.

5.3 Usability
- User interfaces should be intuitive and accessible across devices.
- Provide error messages and feedback for user interactions.

6. Other Requirements
- System should be scalable to accommodate increasing user and ride volumes.
- Compliance with data protection regulations (e.g., GDPR, CCPA).
Use Case Diagram:
A use case diagram is a visual representation that illustrates how users interact
with a system and the various actions they can perform within that system. It
consists of actors, use cases, and their relationships. Here's a brief explanation:

1. Actors: Represent entities that interact with the system, such as users, external
systems, or devices.
2. Use Cases: Represent specific functionalities or actions that the system provides
to its users.
3. Relationships: Show how actors interact with use cases within the system.
Overall, a use case diagram provides a high-level overview of system
functionalities and user interactions, helping stakeholders understand the system's
behaviour and requirements.
Class Diagram:
A class diagram is a visual representation of the structure and relationships of
classes in a system, showing the attributes and methods each class possesses.
Here's a brief explanation:

1.Classes: Represent entities or objects in the system, such as Customer, Driver,

Ride, Payment, etc.
2.Attributes: Represent properties or characteristics of classes, such as name, ID,
address, etc.
3.Methods: Represent behaviors or actions that classes can perform, such as
bookRide(), acceptRideRequest(), processPayment(), etc.
4.Relationships: Show how classes are related to each other, such as associations
(e.g., one-to-one, one-to-many), generalizations (inheritance), and dependencies.

For example, in a taxi booking system class diagram:

- Classes can include Customer, Driver, Ride, Payment, Vehicle, etc.
- Attributes of Customer class can include name, email, phone number.
- Methods of Ride class can include calculateFare(), assignDriver(),
completeRide().
- Relationships show how classes are connected, such as a customer booking a
Ride, a Ride being associated with a Driver, Payment being associated with a Ride,
etc.

Overall, a class diagram helps visualize the structure of a system's classes and their
relationships, aiding in system design, understanding class responsibilities, and
modeling object-oriented concepts.
The figure on the next page showcases the class diagram of the project that is the
Taxi booking system.
Fig. Class Diagram Taxi Booking system
Data Flow Diagram:
A Data Flow Diagram (DFD) is a visual representation that illustrates the flow of
data within a system and how it is processed. It consists of processes, data stores,
data flows, and external entities. Here's a brief explanation:

1. Processes: Represent activities or transformations that process input data to

produce output data. Processes are typically represented by circles or rectangles in a
DFD.
2. Data Stores: Represent where data is stored within the system. Data stores can be
databases, files, or even temporary storage locations.
3. Data Flows: Represent the movement of data between processes, data stores, and
external entities. Data flows are represented by arrows indicating the direction of data
movement.
4. External Entities: Represent external sources or destinations of data, such as users,
other systems, or devices interacting with the system.
example, in a taxi booking system DFD:
- External entities can include customers, drivers, payment gateways, and administrative systems.
- Processes can include booking a ride, assigning a driver, processing payments, generating
reports, etc.
- Data stores can include databases for storing customer information, ride details, driver profiles,
payment records, etc.
- Data flows represent the movement of data between these processes, data stores, and external
entities, showing how information flows through the system during activities like booking a ride,
tracking a ride, making payments, etc.

Overall, a Data Flow Diagram helps visualize the flow of data within a system,
understand data processing activities, identify data sources and destinations, and
design or analyse system functionalities effectively.
DFD Level 0:

DFD Level 1:
 DFD Level 2:

To draw the data flow diagrams we have used the EdrawMax software which is
available on the chrome browser.

Sequence Diagram:
A sequence diagram is a type of interaction diagram that illustrates how objects in a
system interact in a particular sequence to achieve a specific behaviour or
functionality. It shows the flow of messages between objects over time and can depict
the order of interactions in a system. Here's a brief explanation:

1. Objects: Represent instances of classes or entities in the system that interact with each other
to perform actions or exchange messages.

2. Lifelines: Represent the lifespan of an object during the sequence of interactions, shown as
a vertical dashed line labelled with the object's name.

3. Messages: Represent the communication or interaction between objects, shown as arrows

indicating the direction of message flow.
4. Activation Boxes: Represent the period during which an object is active or processing a
message, shown as a box on the lifeline.

For example, in a sequence diagram for a taxi booking system:

- Objects can include Customer, Driver, Ride, Payment Gateway, etc.
- Lifelines for each object show their existence and involvement in the sequence of interactions.
- Messages exchanged between objects can include method calls, responses, and
acknowledgments related to actions such as booking a ride, confirming a ride, processing
payment, etc.

The diagram below shows the sequence diagram of Taxi Booking System:

Overall, a sequence diagram helps visualize the chronological order of interactions

between objects in a system, including the messages exchanged and the sequence
of method calls, aiding in understanding system behaviour, communication
patterns, and identifying potential issues or optimizations in the system's
workflow.
Activity Diagram:
An activity diagram is a type of behavioural diagram in UML (Unified Modelling
Language) that illustrates the flow of activities or actions within a system or
business process. It shows the sequence of activities, decisions, branching paths,
and parallel activities in a process. Here's a simplified explanation of an activity
diagram for a taxi booking system:

Activity Diagram for Taxi Booking System

1. Start: The process begins when a user initiates the booking process.

2. User Registration/Login:
- If the user is new, they register for an account.
- If the user is existing, they log in to their account.

3. Book Ride:
- User inputs pickup and drop-off locations.
- User selects vehicle type (optional).
- System calculates fare estimate.

4. Check Availability:
- System checks for available taxis/drivers based on location and availability.

5. Assign Driver:
- System assigns an available driver to the ride request.
- Driver receives notification and accepts the ride.

6. Track Ride:
- User can track the assigned taxi in real-time on the map.
- Driver navigates to the pickup location.
7. Ride in Progress:
- User and driver complete the ride to the destination.
- User confirms ride completion and provides a rating/review for the driver.
8. Payment:
- User makes payment through the selected payment method (e.g., credit card,
cash).
- Payment is processed securely through integration with payment gateways.

9. End: The booking process is completed, and the system returns to the start state
for the next booking.

Activity diagrams visually represent the flow and interactions between different
activities in a process, helping to understand the system's behaviour, identify
possible bottlenecks, and design efficient processes. The actual diagram would
include symbols such as activity states, decision points (diamond shapes), arrows
representing transitions, and swim lanes for actors or system components.
Cost Estimation:
Cost estimation is the process of approximating the expenses or financial resources
required to complete a project, produce a product, or deliver a service. It involves
forecasting the costs associated with various project activities, resources, materials,
labour, overhead, and other relevant factors. Cost estimation is a crucial aspect of
project management and business planning, providing valuable insights into
budgeting, resource allocation, pricing strategies, and profitability analysis.
Function points are a unit of measurement used in software development to
quantify the size or functional complexity of a software application based on its
features and functionalities. They provide a standardized way to estimate and
compare the effort required to develop software across different projects. Here's a
brief explanation of function points:

1. Functional Components: Function points measure the functionality or features provided

by a software application. This includes inputs, outputs, inquiries, internal logical files, and
external interfaces.

3. Function Point Analysis (FPA): Function point analysis is a method used to calculate
function points for a software application. It involves identifying and quantifying the number of
inputs, outputs, inquiries, files, and interfaces based on defined criteria.

4. Benefits:
- Estimation: Function points help in estimating the effort, time, and resources required for
software development.
- Productivity Metrics: Function points can be used to measure productivity and track progress
during software development.
- Project Management: They aid in project planning, resource allocation, and budgeting.

5. Function Point Counting:

- External Inputs (EI): User inputs that result in significant processing or data changes within
the system.
- External Outputs (EO): Outputs provided to users that convey information or data outside .
- External Inquiries (EQ): Queries or requests for information from users that result in data
retrieval but no significant data processing.
- Internal Logical Files (ILF): Internal data stores or files maintained by the system.
- External Interface Files (EIF): Data passed between the system and external entities.
6. Formula: The function point count is typically calculated using a weighted sum of the above
components, where each component is multiplied by a complexity factor and then summed to
obtain the total function points.

Function points provide a standardized and objective measure of software size,

helping in estimation, project management, and productivity analysis in software
development projects.
COCOMO (Constructive Cost Model) is a well-known software cost estimation
model developed by Barry Boehm. It is used to estimate the effort and cost
required for software development projects based on various parameters.
COCOMO comes in different versions, with the original COCOMO model and its
subsequent extensions (COCOMO II) being the most widely used. Here's an
overview of the COCOMO model:

1. COCOMO Basic Model:

- The basic COCOMO model categorizes software projects into three types based on size and
complexity:
- Organic Projects: Relatively small and simple projects with well-understood requirements.
- Semi-Detached Projects: Moderate-sized projects with some degree of complexity and
uncertainty in requirements.
- Embedded Projects: Large-scale projects with complex requirements, often involving
cutting-edge technologies and stringent constraints.
- Effort estimation in the basic COCOMO model is based on the size of the software in lines of
code (LOC) and the project type, using empirical formulas and historical data.

3. Estimation Parameters:
- COCOMO models consider various estimation parameters such as effort (person-months),
duration (months), staffing (number of personnel), productivity (LOC per person-month), and
cost (in monetary terms).
- Factors influencing effort estimation include project size, complexity, development
environment, team experience, schedule constraints, and risk factors.

4. Usage:
- COCOMO models are used during project planning and early stages of software
development to estimate resource requirements, budget, and schedule.
- They help in making informed decisions regarding project scope, staffing levels, technology
choices, and risk management strategies.

5. Advantages:
- Provides structured and systematic approach to software cost estimation.
- Considers multiple factors influencing effort and cost estimation.
- Can be tailored to specific project characteristics and development environments.
Overall, COCOMO models are valuable tools for software project managers and
developers to estimate effort, cost, and schedule for software development
projects, guiding decision-making and resource allocation throughout the project
lifecycle.