Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

1.1 Project Overview: Railway Reservation System

Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

RAILWAY RESERVATION SYSTEM

CHAPTER 1

INTRODUCTION
India is the 7th largest country in terms of geographical size. This means there is a need
for efficient means for long distance transportation. The long distance road network is
very poorly developed in most parts of India. Bulk of long distance traffic is carried by
the Indian Railway as a result Indian railways. Therefore, forms a backbone of public
transport in India. The efficiency of the railway will increase result of computerization
due to dramatic reduction in communication time among geographically dispersed
offices. For the reservation of the ticket a person goes to ticket counter of the railway
reservation office and expend its valuable time in standing queue. Now to save that time
we have a facility of Online Reservation now we can book cancel or search other train
information just by click on computer.

1.1 PROJECT OVERVIEW

This project will give us the information about railway reservation. This system is
basically concerned with the reservation and cancellation of railway tickets to the
passengers. To be more specific, our system is limited in such a way that a train starting
from a particular source will have a single destination. The basic functions being
performed by our system are reservation and cancellation.

Customers can find the proper and correct information about the railway and shows the

 It reserves and cancels seats for the passenger.


 It contains information about the trains.
 It contains information about the Seat Availability.
 Railway time table.
 Reservation Possibilities.
 Train Ticket booking.
 Booked Railway Ticket Status.
 Train between stations.

DEPT. OF CSE | BTLITM Page 1


RAILWAY RESERVATION SYSTEM

1.2 NEED OF THIS SYSTEM


 To reduce complexity of existing system.
 Effective management of time.
 To make work easy, simple and error free.
 Effective utilization of available resource.
 To enhance the efficiency and diversification of services activities.
 User friendly.
 Interactive graphical user interface.

The scope of project defines the project feasibility the technology, finance, time and
resources best define in technology weather the defects can be reduced in the project and
up which level financially, weather the overall project cost is affordable. Time describe
the weather the projection finishing point will be achieved on time or before time
resources required should be available at the rate of cost and time.

DEPT. OF CSE | BTLITM Page 2


RAILWAY RESERVATION SYSTEM

CHAPTER 2

LITERATURE SURVEY
2.1 EXISTING SYSTEM

In the existing system exams are done only manually but in proposed system we have to
computerize the exams using this application. The existing system has the following
problems:

 Lack of security of data.


 More man power.
 Time consuming.
 Consumes large volume of pare work.
 Needs manual calculations.
 No direct role for the higher officials.

2.2 PROPOSED SYSTEM

The aim of propose system is to develop a system of improved facilities. The proposed
system can overcome all the limitations of the existing system. The system provides he
following services:

 Security of data.
 Ensure data accuracy.
 Proper control of the higher officials.
 Minimize manual data entry.
 Minimum time is needed for various processes.
 Greater efficiency.
 Better service.
 User friendliness and interactive.

DEPT. OF CSE | BTLITM Page 3


RAILWAY RESERVATION SYSTEM

2.3 FEASIBILITY STUDY

The feasibility study is the important step in any system development process. Because it
makes analysis of different aspects like cost required for developing and executing the
system, the time required for each stage of the system. If these important factors are not
analysed then definitely it would be a total failure. So for running the application and the
organization successfully this step is a very important step in a software development
lifecycle process.

There are three types of feasibility analysis:

 Operational feasibility
 Technical feasibility
 Economical/financial feasibility

2.3.1 OPERATIONAL FEASIBILITY

Operational feasibility measures how well the solution will work in the organization and
how will end-user and management feels about the system. Proposed system is helpful for
all the users associated with the organization. It will allow the administrator to have up-
to-date information regarding all the aspects of their users, the decision-making process
will also become faster with the use of data integration, consolidation. So it is feasible to
implement the system.

2.3.2 TECHNICAL FEASIBILITY

This involves questions such as whether the technology needed for the system exists, how
difficult it will be to build, and whether the firm has enough experience using that
technology. This system required minimum hardware equipment to run efficiently.

2.3.3 ECONOMICAL FEASIBILITY

Economically to find out whether this project is economically feasible or not for that used
feasibility analyses. In this stage list direct costs or indirect costs associated with the
project.

DEPT. OF CSE | BTLITM Page 4


RAILWAY RESERVATION SYSTEM

2.4 OBJECTIVES

The objective of this project is to provide tickets to public in the comforts to their home or
residence and to save them from hassles to visit ‘Railway Reservation Centres’. By doing
this, we are not only saving time of public but also saving their cost of traveling or
parking to these centres. For Railways it is saving on their infrastructure i.e. Buildings,
Air-Conditioning, Electricity, Furniture, Staff etc.

DEPT. OF CSE | BTLITM Page 5


RAILWAY RESERVATION SYSTEM

CHAPTER 3

SYSTEM REQUIREMENTS AND SPECIFICATION


3.1 REQUIREMENTS SPECIFICATION

A Software Requirements Specification (SRS) is a complete description of the behaviour


of the system to be developed. It includes a set of use case that describes all the
interactions that the users will have with the software. Use cases are also known as
Functional Requirements. Non-Functional Requirements are requirements which
impose constraints on the design or implementation (such as performance requirements,
quality standards, or design constraints).

3.1.1 FUNCTIONAL REQUIREMENTS

In software engineering, a functional requirement defines a function of a software-system


or component. A function is described as a set of inputs, the behaviour and outputs.
Functional requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that show how a use case to be fulfilled.
Typically, a requirements analyst generates functional requirements after building use
cases. However, this may have exceptions since software development is an iterative
process and sometime certain requirements are conceived prior to the definition of the
use case. Both artefacts (use cases documents and requirements documents) complement
each other in a bidirectional process. A typical functional requirement will contain a
unique name and number, a brief summary, and a rationale. This information is used to
help the reader understand why the requirement is needed, and to track the requirement
through the development of the system. The core of the requirement is the description of
the required behaviour, which must be a clear and readable description of the required
behaviour. This behaviour may come from organizational or business rule, or it may be
discovered through elicitation sessions with users, stakeholders and other experts within
the organization. Software requirements must be clear, correct unambiguous, specific and
verifiable.

DEPT. OF CSE | BTLITM Page 6


RAILWAY RESERVATION SYSTEM

Purpose a description of the functional requirement its reason(s).

what are the input; in what form will they arrive; from what sources
Inputs
can the input come; what are the legal domains of each input.

Describes the outcome rather than the implementation; includes any


Processing validity checks on the data, exact timing of each operation (if
needed), how to handle unexpected or abnormal situations.

The form, shape, description and volume of output; output timing;


range of parameters in the output; unit measure of the output;
Outputs
process by which the output is stored or destroyed; process for
handling error message produced as output.
Table 3.1 Functional Requirements

3.1.2 NON-FUNCTIONAL REQUIREMENTS

In systems engineering and requirements engineering, non-functional requirements are


requirements which specify criteria that can be used to judge the operation of system,
rather than specific behaviours. Non-functional requirements are often called qualities of
a system. Other terms for non-functional requirements are “constraints”, “quality
attributes”, “quality goals” and “quality of service requirements”. Qualities, i.e. non-
functional requirements can be divided into 2 main categories:

 Execution qualities, such as security and usability, are observable at runtime.


 Evolution qualities, such as extensibility and scalability, embody in the static
structure of the software system.

Time The project should be completed within the stipulated time period.

Cost The cost involved in marketing the project should be less.

Usability This requirement is present, as this system will interact with user.

Reliability This system must be highly robust.

Performance It should be fast enough to produce the output.

Table 3.2 Non-functional Requirements

DEPT. OF CSE | BTLITM Page 7


RAILWAY RESERVATION SYSTEM

3.2 HARDWARE REQUIREMENTS

Main Memory : 256MB

Micro Processor : Pentium-III, intel core-2-duo, i3, i5, i7

Hard Disk Drive : 4.3 GB.

Cache Memory : 512KB.

3.3 SOFTWARE REQUIREMENTS

Operating System : Windows 98/NT, Windows 7, 8, 10

Front End : PHP

Back End : MySQL Server

DEPT. OF CSE | BTLITM Page 8


RAILWAY RESERVATION SYSTEM

CHAPTER 4

SYSTEM DESIGN
4.1 DATA FLOW DIAGRAM

4.1.1 LEVEL 1 DFD

Fig. 4.1 Level 1 DFD of ORRS

4.1.2 LEVEL 2 DFD

Fig. 4.2 Level 2 DFD of ORRS

DEPT. OF CSE | BTLITM Page 9


RAILWAY RESERVATION SYSTEM

4.2 ER DIAGRAM

Fig. 4.3 ER Diagram of ORRS

4.3 SCHEMA

Fig. 4.4 Schema of ORRS

DEPT. OF CSE | BTLITM Page 10


RAILWAY RESERVATION SYSTEM

CHAPTER 5

SYSTEM TESTING
5.1 TESTING

Software testing is a critical phase of software quality assurance. It indicates the ultimate
review of specification, design and code generation. Once source code has been
generated, software must be tested to uncover and correct maximum possible errors,
before being delivered. Testing emphasizes on a set of methods for the creation of test
cases that fulfil overall testing objectives.

The primary objectives of software testing are as follows:

 Testing is a process of executing a program to find an error in it.


 A good test case should have a high probability of finding an as yet-undiscovered
error.
 A test case will be considered successful if it uncovers an as-yet undiscovered
error.

5.2 TESTING USED IN THIS PROJECT

5.2.1 UNIT TESTING

Unit testing aims the verification effort on the smallest unit of software design i.e., a
software component or module. It uses procedural design as a guide to test major control
paths and uncover errors within the module boundary. It is a White box oriented and the
step can be conducted in parallel for multiple components.

Unit testing is a dynamic method for verification, where the program is actually compiled
and executed. It is one of the most widely used methods, and the coding phase is
sometimes called “coding and unit testing phase”. The goal of unit testing is to test
modules or “units”, not the whole software system. Unit testing is most often done by the
programmer himself/herself. The goal of Unit testing is to isolate each part of the
program and show that the individual parts are correct. A unit test provides a strict,
written contract that the piece of code must satisfy. As a result, it affords several benefits.

DEPT. OF CSE | BTLITM Page 11


RAILWAY RESERVATION SYSTEM

5.2.2 INTEGRATION TESTING

Integration testing is a phase of software testing in which individual software modules are
combined and tested as a group. It follows snit testing and precedes system testing. The
major objective of integration testing is to tackle the problem of integration i.e. putting all
the modules together. One module can have an inadvertent, adverse effect on another, sub
functions, when combined, may not be magnified to unacceptable levels; global data
structure can cause problems and to truncate this list of problems we use integration
testing.

Integration testing strategy used is Bottom-Up Integration Testing. In it all the bottom or
low level modules, procedures or functions are integrated and then tested. After the
integration testing of lower level integration modules, the next level of modules will be
formed and can be used for integration testing. This approach is helpful only when all or
most of the modules of the same development level are ready. This method helps to
determine the levels of software development and makes easier to report testing progress
in the form of a percentage.

5.2.3 VALIDATION TESTING

At the climax of integration testing, software is developed as a package having all the
errors uncovered and corrected. At this time, a final series of software test May be in
process. It is called validation testing. Validation succeeds when software function in a
reasonably expectable manner. Validation attempts to uncover errors, but the emphasis is
on the requirements level i.e. the things that will be immediately apparent to the
customer.

DEPT. OF CSE | BTLITM Page 12


RAILWAY RESERVATION SYSTEM

CHAPTER 6

RESULTS AND DISCUSSION


6.1 ORRS HOME PAGE

Fig. 6.1 ORRS Home Page

6.2 ADMIN LOGIN PAGE

Fig. 6.2 Admin Login Page

DEPT. OF CSE | BTLITM Page 13


RAILWAY RESERVATION SYSTEM

6.3 RESERVATION SCHEDULE PAGE

Fig. 6.3 Reservation Schedule Page

6.4 ACCOMODATION SETTING PAGE

Fig. 6.4 Accommodation Setting Page

DEPT. OF CSE | BTLITM Page 14


RAILWAY RESERVATION SYSTEM

6.5 PASSENGER INFORMATION PAGE

Fig. 6.5 Passenger Information Page

6.6 RESERVATION CONFIRMATION PROMPT

Fig. 6.6 Reservation Confirmation Prompt

DEPT. OF CSE | BTLITM Page 15


RAILWAY RESERVATION SYSTEM

6.7 PAYMENT INFORMATION PAGE

Fig. 6.7 Payment Information Page

6.8 RESERVATION LISTING FOR ADMIN

Fig. 6.8 Reservation Listing for Admin

DEPT. OF CSE | BTLITM Page 16


RAILWAY RESERVATION SYSTEM

6.9 ACCEPTING PAYMENT FOR RESERVATION

Fig. 6.9 Accepting Payment for Reservation

6.10 TRANSACTION SAVED PROMPT

Fig. 6.10 Transaction Saved Prompt

DEPT. OF CSE | BTLITM Page 17


RAILWAY RESERVATION SYSTEM

6.11 TRANSACTION LISTING FOR ADMIN

Fig. 6.11 Transaction Listing for Admin

DEPT. OF CSE | BTLITM Page 18


RAILWAY RESERVATION SYSTEM

CONCLUSION
Rather than designing manually we have made use of computer as once that data’s are
input it performs accurate function. There is no chance of fault or miscalculation if the
data are fed correctly. Use of the computers has solved many problems, which are faced
while manual calculation. This is not the end but beginning of the versatile, efficient and
outsourcing railway reservation system. This is the one which is compatible to all
operating system. By making this we project we made a small footstep towards the path
of progress of platform independent railway reservation system.

DEPT. OF CSE | BTLITM Page 19


RAILWAY RESERVATION SYSTEM

BIBLIOGRAPHY
[1]. Database systems Models, Languages, Design and Application Programming,
RamezElmasri and Shamkant B. Navathe, 7th Edition, 2017, Pearson.
[2]. Database management systems, Ramakrishnan, and Gehrke, 3rd Edition, 2014,
McGraw Hill.
[3]. Silberschatz Korth and Sudharshan, Database System Concepts, 6th Edition, Mc
GrawHill, 2013.
[4]. Coronel, Morris, and Rob, Database Principles Fundamentals of Design,
Implementation and Management, Cengage Learning 2012.
[5]. Agrawal,V. 2004. Managing Indian Railways, New Delhi, Manas Publications.
[6]. Edvardsson, B. 2006. Service quality: beyond cognitive assessment. Managing
Service Quality, 15(2): 127-131.
[7]. Gremler, DD. 2004. The critical incident technique in service research. Journal of
Service Research, 7(1): 65-89.

DEPT. OF CSE | BTLITM Page 20

You might also like