Project of 123

ABSTRACT
Our project information is related to “BIKE BOOKING MANAGEMENT SYSTEM”.

Visakhapatnam.
What is the purpose of this bike booking system?
Since the Visakhapatnam is a metropolitan city, bikes plays a major role in helping people for
Transportation.
The Bikes have always been a preferable mode of transport to the majority of the people.
This Bike management system is designed for users who are looking for bike ride booking.
Via this system, the users can directly access any details relevant to the bikes of their choice
and they can seek any information like bike details, prices as well as reviews for the bike.
The proposed bike booking management system provides a very effective solution, in which
one can log in to the system and can book a ride and time slot according to their requirement.
1
REQUIREMENTS GATHERING
• Requirement analysis is a software engineering task that bridges the gap

between the system level software allocation and software design.
• It enables the system engineer to specify software function and performance,

indicate software interface with other system elements, and establish design
constraints that the software must meet.
• It provides the software designer with a representation of information and

function that can be translated to data, architectural and procedural design.
2
SYSTEM SPECIFICATION
1. Hardware Requirements
Processor : 11th Gen Intel(R) Core(TM) i5-1135G7 2.42 GHz

Clock speed : 500MHZ
System bus : 64 bits
RAM : 8 GB of RAM
HDD : 500 GB
Monitor : SVGA COLOR
Keyboard : 108 keys
Mouse : 2 button mouse
2. Software Requirements
OS : MS WINDOWS 10
Front End : JAVA
3
SOFTWARE REQUIREMENT SPECIFICATION
A Software Requirement Specification (SRS) - a requirements specification for a software

system is a complete description of the behaviour of a system to be developed. It includes a
set of use cases that describes all the interactions the users will have with the software. Use
cases are also known as functional requirements. In addition to use cases, the SRS also
contains non-functional (or supplementary) requirements. Non-functional requirements are
requirements which impose constraints on the design or implementation (such as
performance engineering requirements, quality standards, or design constraints).
This project is based on Bike Booking Management System. The basic purpose of this system
is to Travel and it is available in affordable prices to the common people.
The System Requirements specification (SRS) will provide a detailed description of the
requirements for the BIKE BOOKING MANAGEMENT SYSTEM (BBMS).The SRS will
allow for a complete understanding of what is needed for the Bike Booking Management
System. The clear understanding of the HMS and its functionally will allow for the correct
software to be developed for the end user and thus will be used for the development of the
further stages of the project. This SRS will also provide the foundation for the project. From
this SRS, the BBMS can be designed, constructed, and finally tested.
This SRS be used by the software engineers constructing the BBMS and Bike booking
customer. The software engineers will use the SRS so that to fully understand the
expectations of this EBPS to construct the appropriate will use the SRS so that to fully
understand the expectations of this EBPS to construct the appropriate software.
The system product to be produced is a Bike Booking Management System. So that the
customer can know the price of travel.
4
FEASIBILITY ANALYSIS
Feasibility study is an important phase in the software development process. It Enables the
developer to have an assessment of the product being developed.It refers to the feasibility
study of the product in terms of outcomes of the product, Operational use and technical
support required for implementing it.
Feasibility study should be performed on the basis of various criteria and parameters.
The various feasibility studies are:
1. Economic Feasibility: It refers to the benefits or outcomes we are deriving from the
product as compared to the total cost we are spending for developing the product. If the
benefits are more or less the same as the older system, then it is not feasible to develop the
product.
2. Operational Feasibility:It refers to the feasibility of the product to be operational.

Some products may work very well at design and implementation but may fail in the real
time environment. It includes the study of additional human resource required and their
technical expertise.
3. Technical Feasibility: It refers to whether the software that is available in the market
fully supports the present application. It studies the pros and confusing a particular software
for the development and its feasibility. It also studies the additional training needed to be
given to the people to make the application work.
5
DESIGN
Using SRS as input, system design is done. System design included designing of software
and hardware i.e. functionally of software and hardware is separated-out. After separation
design of software modules is done. The design process translates requirements into
representation of the software that can be assessed for quality before generation of code
begins.
6
DATA FLOW DIAGRAM
 A Data Flow Diagram (DFD) is a process – oriented graphical representation of an

application system. A DFD “is a picture of the movement of data between external
entities the processes and data stores within a system.”
 The components of a typical dataflow diagrams are: the process, the flow, the data store
and the terminator.
7
LEVEL-0 DFD : BIKE BOOKING MANAGEMENT SYSTEM
Bikes model
Bike number
Customer name
Bike booking
system
Location
Driver contact number
Customer contact number
Zero level DFD-Bike booking management system
8
LEVEL -1 DFD : BIKE BOOKING MANAGEMENT SYSTEM
Customer ID
Models of bike
Customer contact number

Booking ID
Bike booking Pick up area

Booking time management
system
Drop area
Driver name
Total amount
Driver contact number
LEVEL-2 DFD
Bike number
Customer name
First level DFD-bike booking management system
9
LEVEL-2 DFD: BIKE BOOKING MANAGEMENT SYSTEM
From source to Time of Name of the customer

Login user
destination journey
Age
Manage
Password Phone number
modules
Email ID
Submit Gender
Bike name
Conformation message Payment mode Price Timings
Second level DFD –bike booking management system
10
USE CASE DIAGRAM
Vehicle
Vehicle ID name
User-ID User name
M M
USER Booking VEHICLE
Vehicle- Vehicle-
type reg.no
Driver-ID Driver-name
1 M
DRIVER Allot USER BOOKING TABLE
1
Driver license
no
Proceed
for
PAYMENT
ER Diagram for bike booking system
11
SAMPLE CODING
Login Code:
package bike;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
class Login extends JFrame implements ActionListener
{
/**
*
*/
private static final long serialVersionUID = 1L;
JButton SUBMIT;
JPanel panel;
JLabel label1,label2;
final JTextField text1,text2;
Login()
{
label1 = new JLabel();
label1.setText("Username:");
text1 = new JTextField(15);
label2.setText("Password:");
text2 = new JPasswordField(15);
SUBMIT=new JButton("SUBMIT");
panel=new JPanel(new GridLayout(3,1));
panel.add(label1);
panel.add(text1);
panel.add(label2);
panel.add(text2);
12
panel.add(SUBMIT);
getContentPane().add(panel,BorderLayout.CENTER);
SUBMIT.addActionListener(this);
setTitle("LOGIN FORM");
}
public void actionPerformed(ActionEvent ae)
{
String value1=text1.getText();
String value2=text2.getText();
if (value1.equals("BIKE") && value2.equals("654321"))
{
Location t = new Location();
t.setVisible(true);
t.getContentPane();
}
else
{
System.out.println("enter the valid username and password");
JOptionPane.showMessageDialog(this,"Incorrect login or password",
"Error",JOptionPane.ERROR_MESSAGE);
}
}
}
class LoginDemo
{
public static void main(String arg[])
{
try
{
Login frame=new Login();
13
Container c=frame.getContentPane();
c.setLayout(new FlowLayout());
c.setBackground(Color.BLUE);
frame.setSize(500,500);
frame.setVisible(true);
}
catch(Exception e)
{JOptionPane.showMessageDialog(null, e.getMessage());}
}
}
14
Details Code:
package bike;
import java.awt.*;
class Details extends JFrame implements ActionListener
{
/**
*
*/
private static final long serialVersionUID = -1314331175392389926L;
JButton NEXT;
JPanel panel;
JList<String> list;
JLabel label1,label2,label3,label4,label5;
final JTextField text1,text2,text3,text4;
String[] gender = { "Male", "Female", "Others"} ;
@SuppressWarnings({ "rawtypes", "unchecked" })
JComboBox g = new JComboBox(gender);
Details()
{
label1.setText("Name");
label2.setText("Age");
label3.setText("Phone Number");
text3=new JTextField(10);
label4=new JLabel();
15
label4.setText("Email");
text4=new JTextField(15);
label5.setText("Gender");
NEXT=new JButton("NEXT");
panel.add(label1);
panel.add(text1);
panel.add(label2);
panel.add(text2);
panel.add(label3);
panel.add(text3);
panel.add(label4);
panel.add(text4);
panel.add(label5);
panel.add(g);
panel.add(NEXT);
add(panel,BorderLayout.CENTER);
NEXT.addActionListener(this);
setTitle("User Details");
}
{
Payment cb=new Payment();
Container c3=cb.getContentPane();
c3.setLayout(new FlowLayout());
c3.setBackground(Color.BLUE);
cb.setSize(800,800);
cb.setVisible(true);
}
16
}
class UserDetails
{
public static void main(String args[])
{
try
{
Details d=new Details();
Container c=d.getContentPane();
d.setSize(500,500);
d.setVisible(true);
}
catch(Exception e)
}
}
17
Location Code:
package bike;
import java.awt.*;
class Location extends JFrame implements ActionListener
{
JButton NEXT;
JPanel panel;
JList<String> list;
final JTextField text1,text2;
Location()
{

label1.setText("From");
label2.setText("To");
NEXT=new JButton("SUBMIT");
panel.add(label1);
panel.add(text1);
panel.add(label2);
panel.add(text2);
panel.add(NEXT);
18
setTitle("Location");
}
{
Details cb=new Details();
}
}
class LocationDetails
{
{
try
{
Location d=new Location();
d.setSize(500,500);
d.setVisible(true);
}
catch(Exception e)
}
}
19
Payment Code:
package bike;
import java.awt.*;
class Payment extends JFrame implements ActionListener
{
JButton NEXT;
JPanel panel;
JList<String> list;
JLabel label1,label2,label3,label4;
final JTextField text1;
String[] time = { "6:00 AM","8:00 AM", "10:00 AM","12:00 PM","2:00 PM","4:00
PM","6:00 PM"} ;
String[] Price = { "200"} ;
String[] card = { "Debit Card", "Credit Card","pay with cash"} ;
JComboBox g = new JComboBox(time);
JComboBox h = new JComboBox(Price);
JComboBox i = new JComboBox(card);
Payment()
{
label1.setText("bike Name");
label2.setText("Timings");
20
label3.setText("Price per KM");
label4.setText("payment mode");
NEXT=new JButton("SUBMIT");
panel.add(label1);
panel.add(text1);
panel.add(label2);
panel.add(g);
panel.add(label3);
panel.add(h);
panel.add(label4);
panel.add(i);
panel.add(NEXT);
setTitle("Location");
}
{
Welcome cb=new Welcome();
}
}
class PaymentDetails
21
{
{
try
{
Location d=new Location();
d.setSize(500,500);
d.setVisible(true);
}
catch(Exception e)
}
}
22
Welcome Code:
package bike;
import java.awt.*;
class Welcome extends JFrame
{
/**
*
*/
private static final long serialVersionUID = 1L;
JPanel panel;
Welcome()
{
setDefaultCloseOperation(javax.swing.
WindowConstants.DISPOSE_ON_CLOSE);
label1.setText("YOUR RIDE IS CONFIRMED");
label1.setVisible(true);
label2.setText("HAVE A SAFE JOURNEY");
panel.add(label1);
panel.add(label2);
add(panel,BorderLayout.CENTER);
setTitle("THANK YOU FOR USING OUR SERVICES");
}
{
try
{
23
Welcome n=new Welcome();
Container c=n.getContentPane();
n.setSize(600,600);
n.setVisible(true);
}
catch(Exception e)
}}
24
SCREENS
25
26
27
28
29
TESTING
INTRODUCTION:
Software testing methods are traditionally divided into white- and black-box testing. These
two approaches are used to describe the point of view that a test engineer takes when
designing test cases.
TESTING METHODS:
White Box Testing:

White box testing is when the tester has access to the internal data structures and algorithms
including the code that implement these.
Types of white box testing:

The following types of white box testing exist:
•API testing (application programming interface) - testing of the application using public and
private APIs
•Code coverage - creating tests to satisfy some criteria of codecoverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)
•Fault injection methods - improving the coverage of a test .
Grey Box Testing:

Grey box testing (American spelling: grey box testing) involves having knowledge of internal
data structures and algorithms for purposes of designing the test cases, but testing at the user,
or black-box level. Manipulating input data and formatting output do not qualify as grey box,
because the input and output are clearly outside of the "black-box" that we are calling the
system under test.
This distinction is particularly important when conducting integration testing between two
30
modules of code written by two different developers, where only the interfaces are exposed
for test. However, modifying a data repository does qualify as grey box, as the user would not
be able to change the data outside of the system under test.
Grey box testing may also include reverse engineering to determine, for instance, boundary
values or error messages.
Testing levels:
Tests are frequently grouped by where they are added in the software development process,
or by the level of specificity of the test.
1. Unit Testing- Unit testing refers to tests that verify the functionality of a specific section
of code, usually at the function level. In an object-oriented environment, this is usually at the
class level, and the minimal unit tests include the constructors and destructors These type of
tests are usually written by developers as they work on code (white-box style), to ensure that
the specific function is working as expected. One function might have multiple tests, to catch
corner cases or other branches in the code. Unit testing alone cannot verify the functionality
of a piece of software, but rather is used to assure that the building blocks the software uses
work independently of each other .Unit testing is also called component testing.
2. Integration Testing- Integration testing is any type of software testing that seeks to verify
the interfaces between components against a software design. Software components may be
integrated in an iterative way or all together ("big bang"). Normally the former is considered
a better practice since it allows interface issues to be localised more quickly and fixed.
Integration testing works to expose defects in the interfaces and interaction between
integrated components (modules). Progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the
software works as a systems.
3.System Testing - System testing tests a completely integrated system to verify that it meets
its requirement
4. System Integration Testing- System integration testing verifies that a system is integrated
31
to any external or third party systems defined in the system requirements.
5.Regression Testing - Regression testing focuses on finding defects after a major code
change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that
have come back. Such regressions occur whenever software functionality that was previously
working correctly stops working as intended. Typically, regressions occur as an unintended
consequence of program changes, when the newly developed part of the software collides
with the previously existing code. Common methods of regression testing include re-running
previously run tests and checking whether previously fixed faults have re-emerged. The depth
of testing depends on the phase in the release process and the risk of the added features. They
can either be complete, for changes added late in the release or deemed to be risky, to very
shallow, consisting of positive tests on each feature, if the changes are early in the release or
deemed to be of low risk.
6.Acceptance Testing - Acceptance testing can mean one of two things: A smoke test is used
as an acceptance test prior to introducing a new build to the main testing process, i.e. before
integration or regression. Acceptance testing performed by the customer, often in their lab
environment on their own hardware, is known as user acceptance testing (UAT). Acceptance
testing may be performed as part of the handoff process between any two phases of
development.
7.Alpha Testing- Alpha testing is simulated or actual operational testing by potential

users/customers or an independent test team at the developers' site. Alpha testing is often
employed for off-the-shelf software as a form of internal acceptance testing, before the
software goes to beta testing.
8. Beta Testing - Beta testing comes after alpha testing. Versions of the software, as beta
versions, are released to a limited audience outside of the programming team. The software is
released to groups of people so that further testing can ensure the product has few faults or
bugs. Sometimes, beta versions are made available to the open public to increase the
feedback field to a maximal number of future users.
32
9.Non-Functional Testing - Special methods exist to test non-functional aspects of software.
In contrast to functional testing, which establishes the correct operation of the software
(correct in that it matches the expected behaviour defined in the design requirements), non-
functional testing verifies that the software functions properly even when it receives invalid
or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-
functional testing. Non-functional testing, especially for software, is designed to establish
whether the device under test can tolerate invalid or unexpected inputs, thereby establishing
the robustness of input validation 25 routines as well as error-handling routines. Various
commercial non-functional testing tools are linked from the software fault injection page;
there are also numerous open-source and free software tools available that perform non-
functional testing.
10.Software Performance Testing and Load Testing - Performance testing is executed to

determine how fast a system or sub-system performs under a particular workload. It can also
serve to validate and verify other quality attributes of the system, such as scalability,
reliability and resource usage. Load testing is primarily concerned with testing that can
continue to operate under a specific load, whether that be large quantities of data or a large
number of users. This is generally referred to as software scalability. The related load testing
activity of when performed as a non-functional activity is often referred to as endurance
testing .Volume testing is a way to test functionalityThe terms load testing, performance
testing, reliability testing, and volume testing, are often used interchangeably.
11.Stability Testing - Stability testing checks to see if the software can continuously function
well in or above an acceptable period. This activity of nonfunctional software testing is often
referred to as load (or endurance) testing.
12.Usability Testing- Usability testing is needed to check if the user interface is easy to use
and understand.
13.Security Testing -Security testing is essential for software that processes confidential data
to prevent system intrusion by hackers.
33
SUGGESTIONS
1. In future we can add database tables to view the daily report.

2. We can implement our software for bike booking management.
34
REFERENCE
Referred from the websites github and code projects.

Referred from the book Software Engineering and Project Management by Pankaj Jalote.
35

Project of 123

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project of 123

Uploaded by

Copyright:

Available Formats

ABSTRACT

Our project information is related to “BIKE BOOKING MANAGEMENT SYSTEM”.

What is the purpose of this bike booking system?

• Requirement analysis is a software engineering task that bridges the gap

• It enables the system engineer to specify software function and performance,

• It provides the software designer with a representation of information and

Processor : 11th Gen Intel(R) Core(TM) i5-1135G7 2.42 GHz

A Software Requirement Specification (SRS) - a requirements specification for a software

2. Operational Feasibility:It refers to the feasibility of the product to be operational.

 A Data Flow Diagram (DFD) is a process – oriented graphical representation of an

Customer contact number

Zero level DFD-Bike booking management system

Customer contact number

Bike booking Pick up area

First level DFD-bike booking management system

From source to Time of Name of the customer

Conformation message Payment mode Price Timings

Second level DFD –bike booking management system

ER Diagram for bike booking system

label1 = new JLabel();

White Box Testing:

Types of white box testing:

Grey Box Testing:

7.Alpha Testing- Alpha testing is simulated or actual operational testing by potential

10.Software Performance Testing and Load Testing - Performance testing is executed to

1. In future we can add database tables to view the daily report.

Referred from the websites github and code projects.

You might also like