PROJECT on Railway Reservation System

Mohit Tyagi(7478) Kavyank Gupta (7504) B.sc (H)Computer Science IV KESHAV MAHAVIDYALAYA (University of Delhi)

Acknowledgement
The project work in this report is an outcome of perennial work and intellectual support from various sources. It is almost impossible to express the debts owed to many people who have been subservient in imparting this work a successful status. It is however a matter of immense pleasure to express our gratitude and appreciation to all those people who had helped in completion of this project. We would like to take the opportunity to thank Ms. Jyotsana Tanwar and Mrs. Shagun Agarwal for giving us an opportunity to work on this project, which not only has increased our knowledge but also has taught the importance of teamwork. It is because of her guidance, constant encouragement and inspiration that we have been able to accomplish the task of completing this project. Her suggestions have helped us to maintain a good quality of work. We express our deep gratitude to her. Our special cordial thanks to Computer Science Department, KESHAV MAHAVIDYALAYA for its earnest efforts and guidance throughout out project work.

Certificate
This is to certify that this project work on Cellular Management System done sincerely and satisfactorily by Mohit Tyagi (7478) & Kavyank Gupta (7504) of Computer Science (H) IV semester of Keshav Mahavidyalaya, New Delhi. This report has not been submitted for any other examination and does not form part of any other course undergone by candidate and qualifies for submission of project evaluation purpose.

Signature of candidate Name: Mohit tyagi

Signature of candidate Name: Kavyank Gupta

TABLE OF CONTENT
I PROBLEM STATEMENT II. Software Requirement Specification 1. Introduction
1.1 Objective 1.2 Scope 1.3 Definition And Acronyms 1.4 Overview 7 7 8 8

Page number 5

2. Overall Description
2.1 Product Perspective 2.1.1 System Interface 2.1.2 User Interface 2.1.3 Hardware Interface 2.1.4 Software Interface 2.1.5 Communication Interface 2.2 System Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions And Dependencies 9-11

12 13 13 13

SYSTEM MODEL III. Software Design Documentation 1. Entity-Relationship Diagram 2. Data Flow Diagrams
3. Data Dictionary 4. Screen Dumps FEASIBILITY STUDY AND REPORT TESTING OF THE DOCUMENT TESTING STRATEGIES ASSUMED TEST PLANS/VALIDITY TESTING LIMITATION FUTURE SCOPE CONCLUSION

14

17 18-22 23 26 35 37 38 39 42 43 44

PROBLEM STATEMENT
Railway Reservation System mechanism initially had to maintain lots of ledgers and lots of paper work had to be done. But now only the software used to implement e-reservation system has to be loaded on the computer and work can be done in a much faster way. The RAILWAY RESERVATION MANAGEMENT SYSTEM should be able to manage all the reservation related functions. The administrator must be able to enter any change related to the train information like change in train name, number etc. The system should reserve seat in a train for a passenger. First the clerk will check for availability for the seats in a particular train on a specified date of journey. If it is available the clerk will reserve seats. The passenger will be given a unique PNR no. The system must also be able to cancel a reservation. The clerk will delete the entries in the system. The passengers can check their reservation status online by entering their PNR no. The system will display his current status like confirmed, RAC or waiting list. They are also able to see information related to the train schedules. The system should also be able to print the report like it should be able to generate reservation chart, train report, reservation ticket which will have train no and name, date of journey, boarding station, destination station, person name, age, [censored], total fare and a unique PNR no. The system must also be able to print the cancellation ticket which will have total fare and the amount deducted. This saves a lot of time and money. Now The work has become fully automated and any information regarding the organization can be obtained by clicking the button.

SOFTWARE REQUIREMENT SPECIFICATION

1. INTRODUCTION

1.1OBJECTIVE

The origin of most software systems is in the need of a client, who either wants to automate the existing manual system or desires a new software system. The software system is itself created by the developer. Finally, the end user will use the completed system. Thus, there are three major parties interested in a new system: the client, the user, and the developer. Somehow the requirements for the system that will satisfy the needs of the clients and the concerns of the users have to be communicated to the developer. The problem is that the client doesnt usually design the software or the software development process and the developer does not understand the clients problem and the application area. This causes a communication gap between the parties involved in the development of the project. The basic purpose of Software Requirement Specification (SRS) is to bridge this communication gap. SRS is the medium through which the clients and the users needs are accurately specified; indeed SRS forms the basis of software development. Another important purpose of developing an SRS is helping the clients understanding their own needs. An SRS establishes the basis for agreement between the client and the supplier on what the software product will do. An SRS provides a reference for validation of the final product. A high quality SRS is a prerequisite to high quality software and it also reduces the development cost.

1.2 SCOPE
"Railway Reservation System (RRS) is a computerized system used to store and retrieve information and conduct transactions related to travel. The following functions are being performed by the system: Search for trains for a particular destination on a particular date and time Booking of the selected train Payment of the seats booked Cancellation of the booked tickets

1.3 DEFINTIONS AND ACRONYMS

1. DFD :- Data Flow Diagram 2. ERD :- Entity Relationship Diagram 3. SRS :- Software Requirements Specification 4. RRS :- Railway Reservation Software

1.4 OVERVIEW

Rail Transport Industry is an area of commerce that uses trains to transport people, cargo, and mail. Railway provides rail transport services for passengers or freight, generally with a recognized operating certificate or license. The history of railway reservations systems began in the late 1950s to try to create a system that would allow real-time access to train details in all of its offices, to integrate and automate its booking and ticketing processes. Prior to this, manual systems required centralized reservation centers, groups of people in a room with the physical cards that represented inventory, in this case, seats on trains. Rail reservation includes: Issuing of tickets if available Cancellation of tickets. Tickets are issued to passengers to travel to a particular destination on a particular day and time. If a passenger for some reason wants to cancel a confirmed ticket, then the penalty is calculated based on the time the cancellation is made and the balance amount is refunded. The amount to be refunded is based upon the railways cancellation policy.

2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

Before the automation, the system suffered from the following DRAWBACKS: The existing system is highly manual involving a lot of paper work and calculation and therefore may be erroneous. This has lead to inconsistency and inaccuracy in the maintenance of data. The data, which is stored on the paper only, may be lost, stolen or destroyed due to natural calamity like fire and water. The existing system is sluggish and consumes a lot of time causing inconvenience to customers and the railways staff. Due to manual nature, it is difficult to update, delete, add or view the data. Since the number of passengers have drastically increased therefore maintaining and retrieving detailed record of passenger is extremely difficult. Railway has many offices around the country, an absence of a link between these offices lead to lack of coordination and communication.

Hence the railway reservation system is proposed with the following PRODUCT PERSPECTIVE: The computerization of the reservation system will reduce a lot of paperwork and hence the load on the railway administrative staff. The machine performs all calculations. Hence chances of error are nil. The passenger, reservation, cancellation list can easily be retrieved and any required addition, deletion or updation can be performed. The system provides for user-ID validation, hence unauthorized access is prevented.

2.1.1 SYSTEM INTERFACE

The OS types are Windows XP Windows 98

2.1.2 USER INTERFACE

Login: Customers must have a valid login id(PNR number) to enter into the site. View Details: Customer can view/edit his reservation details, payment details, and details about services provided. Search: Customer can search for desired train according to his/her schedule. Choosing and comparing products: Can view all reservation products. Review: The customer can cross check his ticket. Order: Can make the payment service through valid credit card. Cancel: Customer can cancel his reserved ticket at any time.

2.1.3 HARDWARE INTERFACE

Minimum Hardware Requirements
Processor Pentium III Hard disk drive 40 GB RAM 1.28 MB Cache 512 kb

10

Preferred Hardware Requirements

Processor Pentium IV Hard disk drive 80 GB RAM 256 MB Cache 512 kb

2.1.4 SOFTWARE INTERFACE

Any window based operating system with DOS support are primary requirements for software
development. Windows XP, FrontPage and visual basic (VB) for making screen dumps are required.

The systems connection to the internet is mandatory.

2.1.5 COMMUNICATION INTERFACE

Indian Railways web-site, www.indianrail.gov.in offers PRS enquiries on the internet
Berth/Seat availability, Passenger Status, Fare, Train Schedule etc,.

National Train Enquiry System (NTES) website, www.trainenquiry.com gives dynamic

information about the running status of any train and its expected arrival/departure at any given station.

Mobile telephone based SMS enquiry service. A new mobile phone based facility for rail users
viz.,

Country wide extension of Universal Rail Enquiry number 139 through setting up of
Interactive Voice Response System (IVRS)

11

2.2 SYSTEM FUNCTIONS

Booking agents with varying levels of familiarity with computers will mostly use this system. With this in mind, an important feature of this software is that it will be relatively simple to use. The scope of this project encompasses: Search : This function allows the booking agent to search for trains that are available between the two travel cities, namely the "Departure city" and "Arrival city" as desired by the traveller. The system initially prompts the agent for the departure and arrival city, the date of departure, preferred time slot and the number of passengers. It then displays a list of trains available between the designated cities on the specified date and time. Selection : This function allows a particular train to be selected from the displayed list. All the details of the train are shown :1. 2. 3. 4. 5. 6. Train number Date, time and place of departure Date, time and place of arrival Duration Fare per head Number of stoppages 0, 1, 2

Review : If the seats are available, then the software prompts for the booking of train. The train information is shown. The total fare including taxes is shown and train details are reviewed. Traveller Information : It asks for the details of all the passengers supposed to travel including name, age, address, telephone number and e-mail id. Payment : It asks the agent to enter the various credit card details of the person making the reservation. 1. 2. 3. 4. 5. Credit card type Credit card number CVC number of the card Expiration date of the card The name on the card

Cancellation : The system also allows the passenger to cancel an existing reservation. This function registers the information regarding a passenger who has requested for a cancellation of his/her ticket. It includes entries pertaining to the train No., Confirmation No., Name, Date of Journey, Fare deducted.

12

2.3 USER CHARACTERISTICS

EDUCATIONAL LEVEL:-At
English language. TECHNICAL EXPERTISE: - User should be comfortable using general purpose applications on the computer system. least user of the system should be comfortable with

2.4 GENERAL CONSTRAINTS

Software constraints: The system will run under windows98 or higher platforms of operating system. No multilingual support.

2.5 ASSUMPTIONS AND DEPENDICIES

Booking Agents will be having a valid user name an password to access the software The software needs booking agent to have complete knowledge of railway reservation system. Software is dependent on access to internet.

13

SYSTEM MODEL Prototype Model

For the development of the current software I will go for the PROTOTYPE MODEL as I found it to be most appropriate in the light of my project . REASON FOR CHOOSING THE MODEL: When the customer in turn has a legitimate demand but is clueless about the details then one should develop a prototype as the first step to the software development. In this case I as a customer knew as to what kind of software I required but I was completely unaware of the detailed input , processing and other output requirements for the software. Hence I as a developer thought of going for a quick design (prototype) that would serve as a mechanism for identifying the software requirements which I could then use for developing the actual software . Also since the concept being developed was absolutely a new one therefore I was very much unclear about the exact requirements for the software at the beginning of the project. This made me take the approach as suggested by the Prototype Model for the development of the software ,to better understand what exactly needs to be done.

THE PROTOTYPE PARADIGM

The prototype paradigm begins with the requirement gathering. Developer and the customer meet and define the overall objectives of the software, identify whatever requirements are known and outline the areas where further definition is mandatory. A quick design then occurs. This quick design then focuses on the representation of those aspects of the software that will be visible to the

14

customer. This quick design then leads to the construction of the prototype which is evaluated by the customer. Iteration occurs as the prototype is tuned to satisfy the needs of the customer.

15

SOFTWARE DESIGN DOCUMENTATION

16

1.ENTITY RELATIONSHIP DIAGRAM

17

2. 0 LEVEL DATA FLOW DIAGRAM

18

3.LEVEL ONE DATA FLOW DIAGRAM

19

4.1 LEVEL TWO DATA FLOW DIAGRAM - LOGIN

20

4.2 LEVEL TWO DATA FLOW DIAGRAM - TICKETING

21

4.3 LEVEL TWO DATA FLOW DIAGRAM PAYMENT

22

5. Data Dictionary
1. Name :- Passenger Aliases:- None

23

Where used / how used:- A passenger boards a train from the source of the journey Description:S. no
1. 2. 3. 4. 5.

Field name
Name Address Phone no. e-mail id Gender

Data type
Characters

Description

Name of the Passenger Both characters and Residential address numbers. of the passenger Integer Phone number of passenger Characters, numbers e-mail id of the and symbols passenger One character long Sex of the passenger

2. Name:- Train Aliases:- None Where used / how used:- Passenger travels through the train from source to destination. Description:S.No
1. 2.

Field name
Number Schedule

Data type
Both characters and numbers Both characters and numbers

Description
Number of the trains. City from which the train departs. City at which the train arrives. Time at which train departs from the source station. Time at which train arrives at the destination station. Time the train takes.

3. Name:- Station Aliases:- None Where used / how used:- A train either arrives or departs from the station. Description:-

24

S.No
1. 2.

Field name
Name State

Data type
Characters Characters

Description
Name of the station State of the country of to which the city belongs. Unique identification number of the station.

3.

Station-Id

Both characters and numbers.

4. Name:- Ticket Aliases:- None Where used / how used:- Passenger needs the ticket to travel. Description:S.No
1.

Field name
PNR Number

Data type
Both characters and numbers.

Description
Unique identification number of each ticket. Date of departure of train for which the ticket is booked. Amount that has been paid to book the ticket. Name of the passenger. Whether the ticket is for economy or executive class.

2.

Date

Date

3.

Fare

Currency

4. 5.

Passenger details Class

Characters Characters

5. Name:- Booking agent Aliases:- None Where used / how used:- Makes the reservation or cancellation on behalf of customer. Description:-

25

S. no
1. 2.

Field name
Username Password

Data type
Characters Characters

Description
User name of the Booking agent. Password assigned to that user name.

6. SCREEN DUMPS

26

27

28

29

30

31

32

33

34

35

FEASIBILITY STUDY & REPORT

It aims to objectively and rationally uncover the strengths and weaknesses of the existing software, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success.

a.

FINANCIAL AND ECONOMIC FEASIBILITY

For any system if the expected benefits equal or exceed the expected costs, the system can be judged to be economically feasible. In economic feasibility, cost benefit analysis is done in which expected costs and benefits are evaluated. Economic analysis is used for evaluating the effectiveness of the proposed system. In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an analysis of the costs to be incurred in the system and benefits derivable out of the system. When it comes to RAILWAY RESERVATION SYSTEM project, the project is sponsored by the organization. Sponsoring such a project will not be a problem for the organization as this software will decrease the time of various operations and working of organization by providing an automated system which takes lesser time as compare to other means.

b.

TECHNICAL FEASIBILITY

The assessment is based on an outline design of system requirements in terms of Input, Processes, 5b4Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project when writing a feasibility report, the following should be taken to consideration: A brief description of the business The part of the business being examined The human and economic factor The possible solutions to the problems At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost)

c.

LEGAL FEASIBILIY

It includes study concerning contracts, liability, violations, and legal other traps frequently. Our RAILWAY RESERVATION SYSTEM project is legally feasible as all the licenses required for this project development and working are already taken from the authorities.

36

d.

SCHEDULE FEASIBILITY

A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Our RAILWAY RESERVATION SYSTEM project is schedule wise feasible as the development of the software is done within the time bound assigned and is completed according to the timetable.

37

TESTING OF THE DOCUMENT

TESTING often accounts for more project than any other software engineering activity. If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. It would therefore seem reasonable to establish a systematic strategy for testing software. The software testing is a critical step of the software quality assurance and represents the ultimate review of specification, design and code generation.

OBJECTIVES
Once a system has been designed, it is necessary to undergo an exhaustive testing before installing the system. This is important because in some cases a small system error, not detect and corrected early before installation, may explode into a much larger problem later on. Testing is performed when user is asked to assist in identifying all possible situations. That might arise as regards the factors that effort was put to tackle the problem under consideration. Any engineering product can be tested in one of two ways: Knowing the specified function that a product has been designed to perform. Knowing the internal working of the product.

The first test approach is called black box testing and the second, white box testing. When computer software is considered, black box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black box tests are used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and the integrity of external information is maintained. A black box test examines some fundamental aspects of a system with little regard for the internal logical structure of the software. White box testing of software is predicted on close examination of procedural detail. Providing test cases that exercise specific conditions and/or loops tests logical paths through the software.

During development, the software has to pass through a number of stages. At each of these stages we have the probability of committing errors. It is actually the inability of humans to communicate with perfection that introduces a step of quality assurance, which is carried out after software development. Testing represents the ultimate review of specification, design and coding. Testing is carried out with the intent of finding errors, which always exist in software, no matter how stringent the checks may be. This step can never show the defects, it can only show their presence.

38

TESTING STRATEGIES
There are four testing procedures: UNIT TESTING: - This is the testing of an individual module and is usually carried out to ensure the validity of a particular module. NOTE: It makes use of white box testing technique. INTEGRATED TESTING: - Integrated testing is the testing of the system modules. This is done to identify errors, which relate to the interaction of different module, which cannot be found by unit testing but only through an interactive testing. NOTE: It makes use of black box testing technique.

SYSTEM TESTING: -

System testing is the testing of the system against its initial objectives. It is done either in a simulated environment or in a live environment. VALIDATION TESTING: - Validation testing is the testing where requirement established as part of software requirement analysis are validated against the software that has been constructed. NOTE: It makes use of black box testing technique. Our project uses system testing mechanism to test the various vulnerable risks of the project. In system testing we have followed the following four steps: 1. Recovery testing: Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. In our project re-initialization, check pointing mechanisms, data recovery and restart are evaluated for correctness automatically. 2. Security Testing: Security testing verifies that production mechanisms built into a system will, in-fact, protect it from improper penetration. In our project we have included the concept of user id and password, which helps in control of any kind of misuse of the ticketing/billing system. 3. Stress Testing: Stress testing executes the system in a manner that demands resources in abnormal quantity, frequency or volume. If the number of users trying to login at the same time or are making bulk reservations the system has proper methods to handle it. 4. Performance Testing: Performance testing is designed to test the run time performance of software within the context of an integrated system. Before, we launch our facility or the system to general public the project has gone through various performance testing strategies often coupled with stress testing & usually require both hardware and software instrumentation.

39

ASSUMED TEST PLANS/VALIDITY CHECKS

S.No

Test case

Expected Requirements

Exceptions

1.

2.

3.

4.

Username should consist of characters & numbers. Username should start with characters. Login Password should start with characters & must be exactly 6 characters long. Password should not contain special symbols. Departure & Arrival city should be selected from a drop down list. Departure & Arrival dates should refer to future. Search & Select Time should be in am/pm format. Train number should consist of letters & digits. Only one of the scheduled trains should be selected at a time. First, middle, and last names should be no more than 20 characters. Telephone number should consist Travellers of valid STD code of the area. Information E-mail Id should follow standard format. Pin code should be of exactly 6 digits. Card type should be Master, Visa or American Express. Card number should be 14, 15 or Payment 16 digits. Card number should either begin with 4, 5 or 3. Expiration date should be valid.

Using spaces may result in error. Username & password in different case will not be acceptable.

Using different date or time format will result in errors.

Using spaces in first, middle or last names will result in error. Use of more than required number of digits in telephone number will result in error.

Entering card with leading digit other than 3, 4 or 5 will not be acceptable. Expired card will not be accepted.

40

5.

Confirmation Cancellation

Confirmation Number should be automatically generated. Confirmation Number should If wrong payment details are consist of train number & digits. entered, confirmation number Tickets should contain all the will not be generated. relevant information. Each ticket should bear a unique number. Valid confirmation number should be entered to proceed to Using train number or spaces cancellation process. in confirmation number will Cancellation of only future cause an error. reservation can be made.

6.

USER REQUIREMENT

FULFILLED REQUIREMENT

1. Search a) All the necessary fields should be set up to Submit button on search screen doesnt b) search for trains. proceed further until all fields are filled in c) All the field entries should follow the c correctly. d) indicated format. 2. Select R Radio buttons are provided for each train, so O only one train should be selected at a time. T only one train can be selected at a time. 1. Review A All the information about the train and fare E Explicit review screen is provided, which relshould be verified by the customer. L evant details which are reviewed by customer. 2. Traveller Information a) Personal information about the same a) Personal information about the exact number of b) number of passengers should be accepted b) passengers is demanded automatically. as specified during searching of trains. c) The processing of reservation will not proceed c) All the field entries should follow the d) further until all fields are filled up correctly. d) indicated format. 3. Payment a) Credit card should be either master, bias or a) Credit card type is selected from a drop down b) American Express. list. Length of card number is checked b) Credit card number should be of 14, 15, or a automatically for the designated card type. 1 16 digits. Confirmation number is generated c) Confirmation number should consist of automatically only after processing of payment. d) train number & digits.

41

4. Cancellation a) All the field entries should follow the b) indicated format. c) Cancellation should be made, if there is a d) reservation

a) Cancellation will not be processed until the b) required entries are filled up correctly. c) Cancellation can only proceed if a valid d) confirmation number is entered.

42

LIMITATION
The system has no multilingual support, thus creating problem for the users who do not understand English. The system requires at least windows 2000/XP operating system to run. Since the technology is changing rapidly we need to keep it updated so it can run on the upcoming new versions. To update the software according to the latest technology, we require halting the project work i.e. it does not provide a back plan for continuous functionality.

43

FUTURE SCOPE 1. The system can be made multilingual in the future for convenience of the users. 2. Backup plans can be made so that there are no halts in between.

44

CONCLUSION
To conclude the description about the project. The project is based on the requirement specification of the user and the analysis of the existing system, with flexibility for future enhancement. The expanded functionality of todays software requires an appropriate approach towards software development. This railway reservation management software is designed for people who want to use various activities of the railway reservation process. For the past few years the numbers of travelers are increasing rapidly. Thereby the numbers of reservations are also increasing as one cannot travel without the ticket. And hence there is a lot of strain on the person who is making the reservation and softwares are generally not used in this context. This particular project deals with the problems on managing railway related operations like reserving or cancelling a ticket and avoids the problems which occur when carried manually. Identification of the drawbacks of the existing system leads to the designing of computerized system that will be compatible to the existing system with the system which is more user friendly and more GUI oriented.

45

BIBLIOGRAPHY

Software Engineering, A practitioner, by Pressman, 5th edition. Introduction to Software Engineering, by K.K. Aggarwal and Yogesh Singh. Software Engineering ,by Pankaj Jalote, Narosa. Software Engineering, by I. Sommerville

Software Engineering : An Engineering approach by J.F.Peters,W.Pedrycz www.google.com www.scribd.com www.indianrail.gov.in

46