43170803 Online Railway Reservation System Report

Railway Reservation System

“On line Railway Reservation System”

Abstract

In this emerging world of computers all most all manual system

automated and computerized but maximum of them are so complex and a

common user is unable to operate that software system. We are developing

the “Online Railway Reservation System” to model the present system and

to remove the drawbacks.

This project explores how computer technology can be used to solve

the problem of user. We specifically props way to computerize the

administration and engineering offices of Indian Railway Online. A high

speed communication network needs to be developed for interconnecting the

offices of railways. This same communication network can be used to

provide high speed internet connection to the public and leas out network

capacity to internet service providers.


TABLE OF CONTENTS

1. INTRODUCTION

a. Current system b. Need of proposed system

2. SYSTEM DEVELOPMENT LIFE CYCLE

3. ANALYSIS a. Requirement analysis

b. Requirement Specification

4. DESIGN a. System Flow Diagram

b. Modules identified

c. Database Design i. E-R Diagram

5. IMPLEMENTATION

a. Platform Used

i. Hardware Platform ii. Software Platform

b. Implementation

c. Testing i. Testing Technique used

6. CONCLUSION a. Important Features

b. Limitations c. Future Work


Introduction


1. Introduction

1.1 Current System

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 go 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.2 Need of proposed 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 define 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 achieve on time or before time

resources required should be available at the rate of cost and time.


System Development Life Cycle


2. System development life cycle

2.1 Definition

A software process model or a software engineering is an abstract representation of a software process. It is a software development

strategy that encompasses the process, methods and tools layers plus

the generic phases namely definition phase, development phase and

support phase. A process model is chosen based on the nature of the project and application, the methods and tools to be used and the

controls and deliverables that are required.

2.2 Spiral Model

The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle model used in information technology (IT).

This model of development combines the features of the prototyping

model and the waterfall model. The spiral model is favored for large,

expensive, and complicated projects.

The steps in the spiral model iteration can be generalized as follows:

1. The system requirements are defined in as much detail as possible.

This usually involves interviewing a number of users representing

all the external or internal users and other aspects of the existing system.

2. A preliminary design is created for the new system. This phase is

the most important part of "Spiral Model". In this phase all

possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies to use them are

decided. This phase has been added specially in order to identify

and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping

may be used to proceed with the available data and find out

possible solution in order to deal with the potential changes in the requirements.

3. A first prototype of the new system is constructed from the

preliminary design. This is usually a scaled-down system, and


represents an approximation of the characteristics of the final

product. 4. A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths,

weaknesses, and risks; 2. Defining the requirements of the second prototype;

3. Planning and designing the second prototype;

4. Constructing and testing the second prototype.

Spiral Model:-


Analysis


3. Analysis

3.1 REQUIREMENT ANALYSIS:

Requirements are a feature of a system or description of something

that is capable of doing in order to fulfill the system‟s purpose. It provides the appropriate mechanism for understanding what the

customer wants, analyzing the needs, assessing feasibility, negotiating a

solution, specifying the solution unambiguously, validating the specification and managing the requirements as they are translated into

an operational system. Requirement Analysis is a task done under

software engineering and software design. While requirements

engineering specifies software‟s operational characteristics i.e. function, data behavior, indicates software‟s interface constraints, requirements

analysis let the software engineer (called analysis) to refine the software

allocation and construct models of data, functional and behavioral domains. Moreover, requirements analysis provides software developer

with a representation of data, function and behavior that can be

converted to data, architectural, interface and component-level designs. At last, we can say that the requirement specification makes available,

the developer and the customer, a means to assess quality, once the

software has been built.

Software requirements analysis can be categorized into four areas

of effort, as follows-

Evaluation and synthesis

Modeling

Specification

Review


The analyst starts with the studies of system specification and the

software project plan. It is then important to understand the software in a system context. Also, the review of the software scope, used to generate

planning estimate, is necessary. Next, communication for analysis must

be established, so as to ensure problem recognition. The reason behind

is to recognize the basic problem elements perceived by customer.

The next major area of effort for analysis is problem evaluation and

solution synthesis. The engineer (or analyst) must define all data objects

that are extremely observable. He must evaluate the content and flow of

information. Also, he must define and describe all software functions, understand software behavior in the context of the system affected

events, establish the characteristics of system interface, and uncover

additional design constraints.

After evaluating the current problems and desired information (i.e., input and output), the engineer and analyst synthesizing one or more

solutions. Initially, the data objects, processing functions and the system

behavior are defined in detail. Once establishing this information, the analyst then considers basic architectures for implementation. Thus the

process of evaluation and synthesis proceeds until both analyst and the

customer are sure that software can be adequately specified for

subsequent development steps.

During the evaluation and synthesis activity, the analyst creates the system model so as to better understand data and control flow,

functional processing, operational behavior and the information content.

The model provides a base for software design and the creation of

specifications for the software.

3.2 REQUIREMENT SPECIFICATION:

A Software Requirements Specification (SRS) is a complete

description of the behavior 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.2.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 behavior 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 artifacts (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 behavior, which must be a clear and readable description of the required

behavior. This behavior 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.


Detailed Description of Functional Requirements:

Template for describing functional requirements.

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

Inputs what are the input; in what form will they arrive; from what

sources can the input come; what are the legal domains of

each input

Processing Describes the outcome rather than the implementation; includes any validity checks on the data, exact timing of

each operation (if needed), how to handle unexpected or

abnormal situations

Outputs The form, shape, description and volume of output; output timing; range of parameters in the output; unit measure of

the output; process by which the output is stored or

destroyed; process for handling error message produced as output

3.2.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 behaviors. 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:

1. Execution qualities, such as security and usability, are observable

at runtime. 2. Evolution qualities, such as extensibility and scalability, embody in

the static structure of the software system.

The nonfunctional requirements in our projects are:-

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.

3.3 USECASE ANALYSIS:

Use Case Analysis is an object-oriented method for designing

information systems by breaking down requirements into user functions. Each case is a transaction or sequence of events performed by user. Use

cases are studied to determine what objects are required to accomplish

them and how they interact with other objects.

3.3.1 GOALS OF USE CASE ANALYSIS:

Design system from user‟s perspective.

Communicate system behavior in user‟s terms.

3.3.2 CHARACTEISTICS OF USE-CASE ANALYSIS:

USE-CASE: The specific ways in which the system is used.

Each use case expresses a “complete thought” or end-to-end

transaction.

3.3.3 SOME KEY COMPONENTS OF USE CASE ANALYSIS:

ACTORS: Entities that use or are used by system, typically people,

but could be other systems or devices as long as long as they are outside the system being specified.

CONNECTIONS: Connections from actors to use cases. RELATIONSHIPS: Relationships between actors or between use

cases.


3.4 USE CASE DIAGRAM:

A use is a description of a system‟s behavior as it responds to a request that originates from outside of that system. The use case

technique is used in software and system engineering to capture the

functional requirements of a system. Use cases describe the interaction between a primary actor- the initiator of the interaction- and the system

itself, represented as a sequence of simple steps. Actors are something or

someone which exists outside the system under study, and that takes part in a sequence of activities in a dialogue with a system, to achieve

some goal: they may be end users, other systems, or hardware devices.

Each use case is a complete series of events, describes from the point

view of the actor.

3.4.1 USE CASE NAME:

A use case name provides unique identifiers for the use case. It should be written in verb-noun format, should describe an achievable

goal and should be sufficient for the end user to understand what the

use case is about.

3.4.2 GOAL:

Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A briefly

describes what the user intends to achieve with this use case.

3.4.3 ACTORS:

An actor is someone or something outside the system that either

acts on the system- a primary actor – or is acted on by the system- a

secondary actor. An actor may be a person, a device, another system, or time. Actors represent the different roles that something outside has in

its relationship with the system whose functional requirements are being

specified. An individual in the real world can be represented by several

actors if they have different roles and goals in regards to a system.

3.4.4 PRECONDITIONS:

A preconditions section defines all the condition that must be true

(i.e., describes the state of the system) for the trigger to meaningfully

cause the initiation of the use case. That is, if the state describes in the

preconditions, the behavior of the use case is indeterminate.


3.4.5 POSTCONDITION:

The post conditions section describes what the change in the state

of the system will be after the use case completes. Post conditions are

guaranteed to be true when the use case ends.

SIMPLE USE CASE DIAGRAM FOR ONLINE RAILWAY RESERVARION

SYSTEM:

g

USER

REQUEST FOR BOOKING

TICKET

REQUEST FOR TICKET

CANCELATION

REQUEST FOR OTHER

QUERY

SYSTEM

ADMINISTRATOR

VALIDATE USER

VIEW TRANSACTION


3.5 USE CASE DIAGRAM DESCRIPTION:

In the ticket reservation system, users are the passenger, the

counter clerk and the reservation and ticketing system (R & T system). Take each user and identify the roles played, which would lead us to

identify the roles played. Which, in turn, would lead us to an

identification of use case? Table shows the result of the process of identifying the use case. Table shows the result of the process of

identifying the use case; let us take the passenger (a user of system). A

passenger as a user may play one or three roles. i.e. passenger, counter

clerk, reservation and ticketing system.


DESIGN


4. DESIGN

4.1 SYSTEM FLOW DIAGRAM:

A System Flow Diagram (SFD) shows the relationship between the,

major components in the system. It is a systematic representation of an

algorithm or a process. The steps in a process are shown with symbolic shapes, and the flow of the process is indicated with arrows connecting

the symbols.

In order to improve a process, it is first necessary to understand its

operation in detail. Describing this in text lacks the clarity of a pictorial diagram, where individual steps are more easily seen. The flowchart is a

simple mapping tool that shows the sequence of actions within a process,

in a form that is easy to read and communicate. The mapping of „what follows what‟ is shown with arrows between sequential action boxes, as

in the illustration. This also shows the boxes for process start and end

points of which there are normally one each.

Process becomes more complex when decisions must be made on

which, out of an alternative set of action, must be taken. The decision is shown in a flowchart as a diamond shaped box containing a simple

question to which the answer is yes or no.


PASSENGER PROCESS

RESERVATON

ADMINISTRATOR

CHACK

DATABASE

PROCESS

CANCELLATION

DATABSE

CHECK

STATUS

DATABSE

CANCELATION

AUTHORITY

ENQUIRY

AUTHORITY


Here are 6 steps which can be used as a guide for completing flow

diagrams:

1. Describe the process to be charted and to give a chart the title.

2. Start with a trigger event i.e. begins to draw diagram by first

describing the event which initiates the process.

3. Note each successive action concisely and clearly.

4. Go with the main flow i.e. when we reach a point at which the

flowchart branches into a number of alternatives, and the resulting

complexity threatens to overwhelm the exercise, choose the most

important alternative to continue flowcharting with.

5. Make cross reference to supporting information.

6. Follow the process through to a useful conclusion (end at a target

point).


SYSTEM FLOWCHART:

Respond to Request Respond to Request and

And Ticket Booked Ticket Cancel

START

USER NAME & PASSWORD

GO BACK

ENTER LOCATION

CUSTOMER -1

CUSTOMER-2

IF VALID

CUSTOMER-3

End User


COMPLEX FLOW CHART FOR ORRS DECISION CONTROL:

Yes No

Yes

No

Start

Input User

Name

Compare it to valid user list

Maintained at Server

Is User

Valid

Want to

Logout

Deny Login

Enter the Train Name, no,

Source & Destination

Logout

Is Train

Available X

Stop


No

Yes

No

Yes

X

Is

User

Authorized

Access

Denied

Enter the Operation to

Be Performed

Is Option

Reservati

on of

Ticket

Is Option

Cancel of

Ticket Book Ticket

Cancel Ticket Y


Yes No

Y

Is Option

Other

Information

Give Information Ask What You Want


Request

LEVEL 1 DFD OF ORRS

System User Server

Server Response


User and File

Password Request

LEVEL 2 DFD OF ORRS

System User

User Validation

Services to

User

Server

Response


TRAIN

DESTINATION

RUNNING_DAY SOURCE

TRAIN_NAME TRAIN_ NO

BELONG_TO

TRAVEL

BELONG_TO

RESRVATION

CHARGE FARE

TRAVEL

STATION

DATE

DISTANCE

TRAIN_NO

TIME

SEAT

STATUS

PNR_NO.

PASSENGER_DTL

DATE_OF_JRNY

SOURCE

CLASS

SLEEPER

FIRST_CLASS

DISTANCE

1_AC

2_AC

SECOND

_CLASS


IMPLEMENTATION


5. IMPLEMENTATION

5.1 Platform Used

5.1.1 Hardware Platform:

Client side:

Processor: 166 MHz or above

RAM: 64 MB

Hard Disk Space: 100 MB

Server side:

Processor: 166 MHz or above

RAM: 64 MB

Hard Disk Space: 300 MB

5.1.2 Software Platform:

Operating System: - Windows Xp

Front End: - Microsoft Visual Studio 2005

Back End: - Sql Server 2005


1.2 Implementation Level Details:

Database table being used is:

Field name Data type

PNR_Number Numeric

Source Varchar

Destination Varchar

Train_name Varchar

Train_number Varchar

Departure_from_source Varchar

Arrival_at_destination Varchar

Date_of_journy Numeric

Name_of_passenger Char

Sex Char

Age Numeric

Address Nvarchar

Telephone_number Numeric

Class Varchar

Distance Numeric

Seat_no. Numeric


5.3 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 fulfill overall testing objectives.

The primary objectives of software testing are as follows:

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

2. A good test case should have a high probability of finding an as-

yet-undiscovered error. 3. A test case will be considered successful if it uncovers an as-yet-

undiscovered error.

5.3. 1 TESTING TECHNIQUE USED:

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.


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.

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 being. 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.


CONCLUSION


2. CONCLUSION

6.1 LIMITATION OF THE PROJECT:

1. The most significant limitation of over project is its dependency

over the server because of this when is fail then whole work is to be

stopped.

2. Response time of the system may vary because of variable

network speed.

3. Another limitation of our project is that in this software and

hardware requirement is high comparison of existing system.

6.2 DIFICULTIES ENCOUNTERED:

There were many difficulties that came in our way in the process of

development of this real time project some of them are illustrated below.

1. Real time transfer of the file with minimum time delay.

2. Searching an efficient security package and studying its usage.

3. Enabling the multi user environment and simultaneous usage of

files.

6.3 FUTURE ENHANCEMENT:

1. Extra and user defined security needs can be employed during

request and response. 2. Records of client activities can be maintained. 3. Another enhancement would be to add more modules to cover all

information off the system.

6.4 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 feeded 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.

43170803 Online Railway Reservation System Report

Documents

Transcript of 43170803 Online Railway Reservation System Report