PROBLEM DEFINITION

The definition of our problem lies in manual system and a fully automated system.

Manual system:

The system is very time consuming and lazy. This system is more prone to errors and
sometimes the approach to various problems is unstructured.

Technical system:

With the advent of latest technology if we do not update our system then our
business result in losses gradually with time. The technical systems contains the
tools of latest trend i.e. computers printers, fax, Internet etc. The systems with this
technology are very fast, accurate, user-friendly and reliable.

Need of Airlines system

A few factors that direct us to develop a new system are given below -:

1) Faster System
2) Accuracy
3) Reliability
4) Informative
5) Reservations and cancellations from anywhere to any place

AIRLINES SYSTEM

RESERVATION CANCELLATION

UPDATION

1
EXISTING SYSTEM
In the existing system there is no provision for senior citizen concession and there is
no facility for viewing single passenger record.

PROPOSED SYSTEM

The main implementation requirements for this project are

The client tier must not be changed, which means that the format of all the
communication messages have to be preserved.

Some functionality, like check digit validation, time, stamps etc.

Are supplied by already existing routines which we are obliged to use.

The format of communication in modules are fixed and non changeable.

All the technical documentation formats are also fixed and have to be followed.

Some customer implementation techniques have to be followed.

A facility for viewing the single passenger record is made available.

We have made concession in ticket fair for senior citizen

DESIGN CONCEPT

The algorithm is developed as flow chart and the data flow diagrams, to describe the
step-wise procedure of the application. The basic requirements, which are got from the
customer, should all be covered in this algorithm developed. Most components described
in the system architecture section will require a more detailed discussion. Other lower-
level components may need to be described as well. The kind of component, such as a
subsystem like delete, insert, module like student detail, class like library, package,
function, file etc.The specific purpose and semantic meaning of the component describe
this. This may need to refer back to the requirement specification.

2
 REPORT MODULE

The tickets issued should have the details such as plane number, ticket number, seat
number, traveler’s name, time of departure. The traveler should be informed about the
check-in time.The names of the fields involved in the airline reservation system are

FLIGHT DETAILS

CHECK AVAILABILITY

BOOK TICKET

VIEW SINGLE PASSENGER RECORD(by taking the ticket number)

EXIT

MODULE 1: FLIGHT DETAILS

This module is used to view the flight details with ease and it tends the passenger to
book tickets without much difficulty.

MODULE 2: CHECK AVAILABILITY

This module is used to check the availability of the flights and the information of the
seats in that flight.

MODULE 3: SINGLE PASSENGER RECORD

This module is used to view the single passenger details with the help of the ticket
number issued after booking with input support information.

MODULE 4: BOOK TICKET

This module is used to book the ticket after checking the availability of tickets I the
flights. A ticket can be booked to a maximum of five just by entering the passenger
name, age and their details.

MODULE 5: EXIT

This module is used to exit from the reservation form.

3
 FEASIBILITY STUDY

Feasibility study is to check the viability of the project under consideration. Theoretically
various types of feasibilities are conducted, but we have conducted three type of feasibilities
explained as under.

ECONOMIC FEASIBILITY

With the manual system the operating cost of the system is about 60 Lacks P.A.. This cost
comprises salary of 25 people, stationary, building rent, electricity, water, telephone etc.
But with the new system this reoccurring cost comes out to be about 20 Lacks P.A. Hence
the new system is economically feasible.

TECHNICAL FEASIBILITY

The new system requires only 6 trained person to work with the system and in overall 10
people per office are sufficient. So we will identify 6 best people from existing system and
train them.

As our existing system is purely manual, so we need a one time investment of Rs 4 Laks for
the purchase of 7 computers, 5 Ticket printers, a laser printer, AC and networking etc. It
requires 20 Lacks PA as a operating cost.

With the above details our system is technically feasible as after investing 24 Lacks in a
year, the company is still saving Rs 25 Lacks PA.

OPERATIONAL FEASIBILITY

The new solution is feasible in all sence but operationally it is not. The new system
demands the expulsion of at least 15 people from the company. It creates an environment of
joblessness and fear among the employees. It can lead to an indefinite strike in the
company also. So the management must take corrective actions prior in advance in order to
start the further proceedings.

4
 REQUIREMENT ANALYSIS

Background
This project deals with the development of a Software Requirements Specification
(SRS) document that specifies what an airline reservation system should and
should not do. The SRS document is divided into five sections namely

1. System Objectives
This section lists all the goals and objectives of the system categorized based
on the viewpoint of the airline company and the customer (passenger). These
are higher-level goals which are somewhat broad in nature. They help in a
top-down development of the SRS.

2. System Context
This section clearly depicts the environment and boundaries of the ARS and
the entities with which it interacts. It helps us see how the system fits into
the existing scheme of things. What the system will do by itself and what it
expects other entities to do is clearly delineated.

3. Functional Requirements
This section is the bulk of the document and precisely states the functions of
the system – what it should do and what it should not. This section is split
into subsections modeled after the real world activities like reserving tickets,
rescheduling tickets etc. Freedom from ambiguity and navigability were kept
in mind while documentation. A consistent terminology has been followed
throughout and the terms are explained in the appendix. The subsections
follow a logical sequence that reflects the real world. For example, a customer
cannot reschedule a ticket unless he has bought one earlier and cannot buy
one unless he has checked its availability.

5
 4. Non-functional Requirements
These are quality requirements that stipulate the performance levels
required of the system for various kinds of activities. Numerical lower and
upper limits set conditions on the response times, access times etc of the
system. Sometimes, tradeoffs are necessary among various non-functional
requirements.

5. Future Requirements
These are the specifications which are not provided for now in the current
version of ARS but which could be incorporated into future versions. Some of
these need advanced technologies and interfaces with other systems. The
ARS could be designed in future to enhance the existing capabilities or add
entirely new ones.

The assumptions and limitations of the ARS have been interspersed in the SRS
to present the same in their proper context.

1. System Objectives

1.1 The Airline Reservation System (ARS) is a software application to assist an

airline with transactions related to making ticket reservations, which
includes blocking, reserving, canceling and rescheduling tickets.
1.2 From the viewpoint of the airline -

1.2.1 Minimize repetitive work done by the system administrator and

reservation clerks.
1.2.2 Maintain consistency among different access modes, e.g. by phone, by
web, at the information desk and across different physical locations. The
users should be basically taken through the same steps by the system as they
go through in conventional desk-reservation systems.

1.2.3 Maintain customer information in case of emergency, e.g. flight

cancellation due to inclement weather. The profile can also be used by the

6
 airline company to track user preferences and travel patterns to serve them
better, plan routes, for better marketing and efficient scheduling of flights.

1.2.4 Maximize the revenue of the airline company by various means:

1.2.4.1 Increase awareness among frequent travelers about

various special offers and discounts.

1.2.4.2 Minimize the number of vacant seats on a flight and

maximize flight capacity utilization.

1.2.4.3 Maintain the capability to adopt a flexible pricing policy.

The price of the tickets should be dynamically determined based on
how early, before the date of departure, the customer buys the ticket.

1.3 A survey conducted by airline companies shows that users of an existing

reservation system would respond favorably to an ARS that satisfied or
helped them satisfy the following objectives:
1.3.1 Reduce effort and frustration for travelers in scheduling a trip,
especially by reducing the search effort for the flight they need to take.

1.3.2 Show all possible combinations and itineraries available for a pair of
origin-destination cities.

1.3.3 Reduce redundancy in the information required from the customers in

order for them to buy tickets, create user accounts etc.

1.3.4 Check the validity of input data and give a feedback to the user in case
of errors or inconsistency.

1.3.5 Provide flexible access modes to users – internet, telephone, PDA.

1.3.6 Protect customers’ privacy concerns.

1.3.7 Make it easy for travelers to check the ticket status or make changes to
their trip.

7
2. System Context
2.1 The ARS will provide the following types of easy-to-use, interactive, and
intuitive graphical and telephonic interfaces.
2.1.1 The ARS will provide an easy-to-use, intuitive Graphical User
Interface (GUI) as part of the Clerk/Administrator’s working desktop
environment.

2.1.2 The ARS will also provide an interactive GUI, on the World Wide Web
for the general customers.
2.1.3 The above two ARS interfaces shall help provide the following
functionalities to the users - access to the ARS to check the flight
schedule, availability of seats, ticket price and to block, reserve, cancel,
and reschedule tickets.
2.1.4 The ARS will also provide an easy-to-use, simple telephonic user
interface, which can be accessed by the customers through telephone or
cell phone from anywhere. This interface shall provide access, only to
the following functionalities, namely, check flight schedule and check
ticket status including any change in the flight timings. The
functionality available through this telephonic interface is limited
because of security constraints.
2.2 The system and its environment and the interactions between them are
depicted in the diagram below.

The closed boundary above clearly delineates the system and the
environment. The diagram shows the interactions between the ARS software and
the databases inside the system. There are three databases internal to the system
and which the system maintains. DB-user is the database containing all the
personal information of the registered users of the ARS. This can be updated by the
user by logging in to the system.

8
 Information from this database is used during transactions like charging the
credit card etc. DB-schedule is a copy of the flight schedule database. The latter
exists independently and is updated by a flight scheduler system which is out of
scope of the ARS.

DB-Reservations
Customer DB-User Flight
Schedul
Via Web
DB-Schedule e
I

T DB-Geography
ARS
E software

R
INTERFACE ‘Cp’

INTERFACE ‘A’
Customer

Via Phone
Administrator

DB-schedule is updated with the latest status of the flight schedule database
whenever there is any change in the latter. For example, if a flight has been added
to the schedule between two cities on Tuesdays, DB-schedule gets updated with this
change through a process with which we are not concerned. It is external to the
system and is out of the scope of this SRS. DB-schedule also contains the base
prices of tickets for various flight numbers. DB-reservations are a database
containing information regarding the number of seats available on each class on
different flights. It has provision for marking how many of the reserved seats have
been blocked but not yet bought.

9
 DB-reservations should update itself using DB-schedule, for example, if a
new flight is added. DB-geography is a database, which contains information about
the cities and towns serviced by the airline. The distance between all cities and
towns is contained in a matrix form. There are three interfaces, one for the
administrator, one for the customer via web and another for the customer via
phone. The administrator can update DB-schedule with any changes in the base
prices of flight tickets. The system uses a pricing algorithm and dynamically
determines the actual price from this base price depending on the date of
reservation vis-à-vis date of departure. The customer interfaces (web and phone)
enable multiple functions which are described in the following section – section 3.

3. Functional Requirements

3.1 User Accounts

3.1.1 The passenger, who will henceforth be called the ‘user’, will be presented with
3 choices by the reservation system, as the first step in the interaction between
them. A user can choose one of these and his choice would be governed by whether
he is a guest or a registered user and whether he wants to check the availability of
tickets or also block/buy them. The terms ‘registered user’ and ‘guest’ are described
below.
3.1.1.1 A user who has traveled by the airline earlier would have been given a
user id and a password. He would have his personal information stored in the
database referred to earlier in section 2 as ‘DB-user’. This ‘personal
information’ would be henceforth referred to as ‘profile’. Such a user with a
profile in DB-user shall be called a ‘registered user’. A registered user will be
able to check the availability of tickets as well as block/buy a ticket by logging
into the system.

3.1.1.2 A new user, on the other hand, would either have to

10
 a) register himself with the system by providing personal information or
b) log into the system as a guest.
In case of ‘a’, the new user becomes a registered user.

In case of ‘b’, the new user would remain a guest.

A guest can only check the availability of tickets and cannot block or buy
tickets.

But a registered user can also act as a guest if he only wants to check the
availability of tickets. ‘Availability of tickets’ always refers to viewing the
flight schedule for given days, the price of tickets and any discount offers. The
system shall present the user with an option to exit from the system at any
time during the following processes.

3.2 Registration and creation of user profile

The system shall require a user to register, in order to carry out any
transactions with it except for checking the availability of tickets. It will ask
the user for the following information at the least – a user id, a password,
first name, last name, address, phone number, email address, sex, age,
preferred credit card number. The system will automatically create a ‘sky
miles’ field and initialize it to zero in the user’s profile.

3.3 Checking Availability

3.3.1 After logging in a user (either a registered user or a guest), the system shall
request him to enter the following details – origin city and destination city.
“City’ is a generic term and refers to a city or town as the case may be. The
origin and destination cities would be entered as text.

3.3.2 The system shall now refer to the flight schedule database, referred to as
‘DB-geography’ in section 2, and check if there is any ambiguity with the
names of the cities. In case there are more than two cities with same name as

11
 entered by the user, the system shall list all of them (with more
qualifications) and ask the user to select one of them. In case, either the
origin or destination cities are not listed in DB-geography as being directly
serviced by the airline, the system shall suggest the nearest city to which
service is available, including the distance of the destination city from this
nearest city.
3.3.3 After the origin and destination cities are ascertained, the system shall now
access the flight schedule database, referred to as ‘DB-schedule’ in section 2,
and checks if there is a direct operational service between the two cities. If
not, the system shall suggest possible routes and transfer points using a
‘route selection algorithm’. The user shall now be presented with a choice of
either selecting one of the routes. In case he selects a route, the system shall
fill in the intermediate stop over points and create a multiple trip itinerary
for the user.
3.3.4 The system shall now ask the user to enter the following details - class, one-
way or round trip, departure date and the number of adult passengers,
children and senior citizens.

‘Class’ refers to business class/first class/club class/smoking/non smoking. This

choice shall be made by the user through a drop down menu indicating all the
possible combinations of choices.
3.3.4.1 One-way/round trip shall be either a drop down menu or a check
box selection. ‘Departure date’ refers to either a single date or a range
of dates, entered through a calendar-like menu. This menu shall not
show dates in the past or those dates that are too ahead in the
future(as determined by the airline policy). In case, the trip is a round
trip, the system shall also ask the user to enter the departure date on
the return trip.
3.3.4.2 Having taken all the above input from the user, the system
checks for any false entries like the departure date on the return trip

12
 being earlier than the departure date on the onward trip. In case of
incompatibility, the system shall display a suitable error message and
prompt the user to enter the information correctly.
3.3.5 Having taken all of the information as laid out above in 3.3.1 and 3.3.4, the
system shall now access the flight schedule database ‘DB-schedule’ and
queries it using the input provided by the user.
3.3.6 The system queries the reservation database ‘DB-reservations’ to check
which of the flights on the schedule have seats available. The system displays
the results in a suitable form (a tabular form) with the following information
depicted – for each flight number – the flight number, departure time in
origin city, arrival time in destination city, the duration of the flight (taking
into account the possibility of a change of time zone) and the number of seats
available on that flight.
3.3.6.1 There can be several flights between two cities and all of them
will be listed for the particular date that the user wants to depart from
the Origin City. In case, the user has entered a range of dates, the
system shall display all the flights for all those dates in the range.
3.3.6.2 If the user has requested a round trip, the system shall display
two tables - one for the onward trip and one for the return trip. There
will be a check box in front of each line in the table representing a
flight with available seats.
3.3.6.3 The user is now asked to check one of the boxes reflecting a
choice of a flight number and time. In case of a round trip, the user is
asked to check one box each in the two tables.
3.3.7 The system shall now display the price of the ticket for the trip. This will be
the sum of the prices for all the members of the travel party being
represented by the user.
3.3.7.1 The system shall also list any rules regarding the cancellation of
tickets – what percentage of the price will be refunded within what
date ranges. This will be displayed as a table.

13
3.4 Making Reservations/Blocking/Confirmation
3.4.1 After having taken the user through the step 3.3, Checking Availability, The
system will now ask the user if he wishes to block/buy the ticket. If yes, and

a) if the user has been a guest, he will have to first register and become a
registered user and then log onto the system.
b) If the user is already a registered user, and if he has logged on already, he
can block/buy the ticket, but if he has been acting as a guest, he will have to
log on.
3.4.2 Having ensured that the user is logged on validly according to 3.4.1, the
system compares the departure date with the system date. If the departure
date falls within 2 weeks of the system date, the system informs the user that
he has no option to block the ticket and asks him if he would like to buy it.
3.4.2.1 If the difference between the departure date and system date is
more than 2 weeks, the system asks the user if he would like to block
or buy the ticket. The system informs the user that he can block the
ticket at no cost now. It also informs him that if he chooses to block the
ticket, he should make a final decision before 2 weeks of the departure
date. The system shall send an email to the user, 3 weeks before the
departure date as a reminder, in case he decides to block the ticket
now.
3.4.3 Having taken the input from the user in 3.4.2, the system shall now proceed
to update the reservation database DB-reservation. It will decrement the
number of available seats on the particular flight for the particular class by
the number of travelers being represented by the user.
3.4.3.1 In case of a blocking, the system makes a note of it in the
database - to be used if the user doesn’t turn up before 2 weeks of the
departure date. It generates a blocking number and displays it for the
user to note down.

14
 3.4.3.2 In case the user buys the ticket, the system accesses his profile
and charges the price of the ticket to his credit card number. It
simultaneously generates a confirmation number and displays it to the
user for him to note down. The ticket has been reserved.
3.4.3.3 It adds the mileage of the trip (accounting for the number of
travelers) to the skymiles in his profile.
3.5 Confirm Ticket
3.5.1 A user who has earlier blocked a ticket after going through the steps 3.2
through 3.4, is required to either confirm the ticket before two weeks of the
departure date or the ticket stands cancelled.

3.5.2 To let the user confirm a ticket, the system shall first log him on and ask for
his blocking number. Then it accesses DB-reservation and removes the check
mark, which so far represented a blocked seat. The seat is now confirmed and
reserved for the user.
3.5.3 The system accesses DB-user and charges the price of the ticket to the credit
card number of the user. It simultaneously generates a confirmation number
and displays it for the user to note down. The ticket has been reserved.
3.5.4 It adds the mileage of the trip (accounting for the number of travelers) to the
skymiles in his profile.
3.6 Reschedule Ticket
3.6.1 The system shall present the user with an option to re-schedule his travel
party’s trip. In order to do this, the system first logs on the user and requests
his confirmation number. It will not allow a user to reschedule a blocked
ticket but only a confirmed ticket. Using this, it queries DB-reservation and
presents the details of the trip to the user, including but not limited to origin
city, destination city, date of departure and date of arrival (in case the trip is
a round trip).
3.6.2 The system shall now ask the user to select new dates from the calendar-
menu. It now goes through step 3.3.

15
 3.6.2.1 In case, there are no available tickets for the dates entered, it
displays a suitable message informing him that rescheduling to that
date is not possible.
3.6.2.2 In case there are tickets available, the system asks the user to
select the flight number for the trip (another for the return trip if the
trip is a round trip) and proceeds to update the database.
3.6.3 The system accesses DB-reservation and decrements the number of available
seats on the flight(s) by the number of members in the user’s travel party. It
then increments the entry for the previous flight by the same number to
reflect an increase in the available seats on it as a result of the rescheduling.
3.6.4 The system now checks if there is any difference in the prices of the tickets. If
so, it accesses DB-user and charges or credits the credit card as the case may
be. The system generates a new confirmation number and displays it to the
user.

3.7 Cancellation
3.7.1 The system shall also give the user an option to cancel a confirmed ticket or a
blocked ticket.
3.7.1.1 The latter case is simpler and will be dealt with first – the
system shall first log on the user and request the blocking number.
Then it accesses DB-reservation and updates it by incrementing the
number of available seats by the number of people in the user’s travel
party.
3.7.1.2 In the former case, i.e., for a confirmed ticket, it asks for the
confirmation number and accesses DB-reservation and presents the
details of the trip as in step 3.6.1.
3.7.2 It then lists the applicable rules for cancellation of tickets and depending on
the system date and the departure date, it displays the % of the amount that
would be refunded if the user cancels the ticket.

16
3.7.3 After the user cancels the ticket, the system generates a cancellation number
and displays it for the user to note down. It accesses DB-reservation and
updates it by incrementing the number of available seats on that flight by the
number of travelers in the user’s party. It accesses DB-user and credits the
refund amount to his credit card number. The system then deducts the
mileage of the trip (taking into account the number of travelers in his party)
from the sky miles in his profile.
3.8 Update Profile
The system shall enable the user to update his profile at any time. Changes
can be made in fields including but not limited to address, phone number and
preferred credit card number.

3.9 View Ticket Status

The system shall allow a user to view all information about his trip. After
logging him on, it asks for his blocking number or his confirmation number.
It accesses DB-reservation and retrieves the details of the trip and presents
them to the user in a convenient format, including any last minute changes to
the flight timings etc. Such changes will be highlighted.

3.10 Query Flight Details

The system shall allow any user (registered or non registered) to access the
details about the arrival and departure times of a flight by requesting the
user to input the flight number and date. The system accesses DB-schedule
and presents the time of arrival and departure.

3.11 Telephone access

The system shall be accessible through a touch-tone telephone. The
telephonic interface shall, at the least, provide the customer with the facility
to check availability of tickets and query flight details. The system shall walk
the customer exactly through steps 3.3 and 3.9 respectively but through a
telephonic interface.

17
4 Non-functional Requirements

4.1 Performance
4.1.1 Response time of the Airline Reservation System should be less than 2
second most of the time. Response time refers to the waiting time while the
system accesses, queries and retrieves the information from the databases
(DB-user, DB-schedule etc) (A local copy of flight schedule database is
maintained as DB-schedule to reduce this access time)

4.1.2 ARS shall be able to handle at least 1000 transactions/inquiries per

second.
4.1.3 ARS shall show no visible deterioration in response time as the
number of users or flight schedule data increases
4.2 Reliability
4.2.1 ARS shall be available 24 hours a day, 7 days a week
4.2.2 ARS shall always provide real time information about flight availability
information.
4.2.3 ARS shall be robust enough to have a high degree of fault tolerance. For
example, if the user enters a negative number of passengers or a value too
large, the system should not crash and shall identify the invalid input and
produce a suitable error message.
4.2.4 ARS shall be able to recover from hardware failures, power failures and other
natural catastrophes and rollback the databases to their most recent valid
state.

4.3 Usability
4.3.1 ARS shall provide a easy-to-use graphical interface similar to other existing
reservation system so that the users do not have to learn a new style of
interaction.

18
4.3.2 The web interface should be intuitive and easily navigable Users should be
able to understand the menu and options provided by ARS.

4.3.3 Any notification or error messages generated by ARS shall be clear, succinct,
polite and free of jargon.

4.4 Integrity
4.4.1 Only system administer has the right to change system parameters, such as
pricing policy etc. The system should be secure and must use encryption to
protect the databases.

4.4.2 Users need to be authenticated before having access to any personal data.

4.5 Interoperability
4.5.1 ARS shall minimize the effort required to couple it to another system, such as
flight schedule database system.

5 Future Requirements
5.1 Support for waiting list functionality
5.1.1. ARS shall be made more flexible in ticket reservation handling, and
shall accept waiting list for reservation.

5.1.2 The waiting list handling capability of ARS shall be made more
advanced, by enabling it to send requests to the Flight Scheduler to schedule
extra flights, depending on the demand in a particular corridor, and
providing the wait listed passengers with a new flight.

5.2 The telephonic interface of the ARS shall be improved to support more
functionality like allowing the customers to cancel a ticket etc., by
incorporating security measures.

5.3 ARS shall be made more dynamic and helpful to the users by enabling it to
send instant messages to the passengers, of a cancelled or rescheduled flight,

19
 through email, phone, fax etc., informing them about the change, and
providing them with other feasible alternatives.

5.4 Information about the kind of meals served in a flight and the type of
entertainment offered on a flight should be incorporated into the system.
5.5 Provide service integration with auto rental agencies and hotel chains.
5.6 Interface for the travel agents shall be provided in the future versions with
additional features like informing them of any availability of seats on a flight
which was earlier booked to capacity.
5.7 Choices like aisle or window seats shall be provided to the users.
5.8 The ARS shall be able to handle the situation where flight services are
available to multiple airports in a single city.

20
 SYSTEM ANALYSIS

This was the most important phase of my project life cycle. It had connected my
maximum time .The block diagram given bellow depict various fact which were
understood by one during the analysis phase.

BLOCK DIAGRAM

21
In that phase initially I had observed the system by visiting to Indiragandhi
Airport(domestic terminal) and a few airline reservation agency.

Pardes Airline agencies, Lotus Airline agencies.

The above block diagram is an implementation of this observation .In the

next phase I had various quiries in my mind ,Which I tried to ask from appropriate
authorities.

Q.1 Tick mark the features to be included in the new system?

• Enquiry
• Reservation
• Cancellation
• Report
• Edit
• Other specify
Q2. Tick mark that the system should be ?

• Multi-user
• Single user
Q3. Tick marks the total time required for the implementation of the project?

• 3 months
• 6 months
• 9 months
• Others specify
Q4. Tick mark the reports to be Incorporated?

• List of all passenger

• List of all flights
• List of passenger(date wise)
• List of passenger(flight wise)
• Any other

22
After getting solution my queries I started studying database structure used in the
existing system . In this connection I had come to know about various master files as

In passenger list: Passenger name, Address, tel_no , d_o_b, profession father name,

Fleet info: No aircraft, club_pre_capacity, economic capacity, engine type, cruisespeed,

air length,

Flight info: f_name, f_code, c_code,t_exeseat no, t_economic seat no.

Concession: concession name, concession code, class, discount, v_o_t, baggage

allowance, fare.

Move of payment: Passenger code, Date of paid, Current date, cash,

Debit,cheque,credit.

Fare: route, destination place, source place, Departure time, Arrival time,Flight
code,class,Fare.

Reservation: Ticket report, PNR, flight code, destination place, source place,
departure time arrival time, Class, number of passenger, Age, sex, Fare, seat.

Enquiry: Ticket no, seat number, pnr.

Cancellation: Pnr, ticket no, Days left, Basic amount, Cancel amount.

Various categories of flight code are display here

CD455,IC548,IC7896,IC567,CD445

Flight schedule - gau to del 12.33 pm to2.33 pm

In this process further I had visited the air port again in order to INTER VIEW people
to know more about the system

The main purpose was To analyses the method of calculating daily income reservation
cost generation methods, and few concern things. Duty schedule.

23
 SYSTEM DESIGN

In this phase initially I had designed E-R diagram of the processes, in order to identify
various entities and relationship set, entity set, attributers, link attributes The
Diagram of this process as under. After this step we had tried design the data base for
the new system and normalized it. The tables motivated in data dictionaries enclosed
as annex II is an outcome of this step. The symbols of entities are shown below.

24
E-R DIAGRAM FOR BOOKING DEPARTMENT

25
E-R DIAGRAM FOR CANCELLATION

26
DATA FLOW DIAGRAM

In order to design a better solution. I had designed the DFD for system including all
technical processing details is given bellow.

LEVEL 0 DATA FLOW DIAGRAM

27
LEVEL 1 DATA FLOW DIAGRAM OF GENERAL ENQUIRY SYSTEM

28
LEVEL 2 DFD OF BOOKING

29
LEVEL 2 DFD OF CANCELLATION

30
 USE CASE DIAGRAM

Use Case Modeling

Use Case modeling is the simplest and most effective technique for modeling system
requirements from a user’s perspective. Use Cases are used to model how a system or
business currently works, or how the users wish it to work. It is not really an object-
oriented approach; it is really a form of process modeling. It is, however, an excellent
way to lead into object-oriented analysis of systems.

Use cases are generally the starting point of object-oriented analysis with UML. The
Use Case model consists of actors and use cases. Actors represent users and other
systems that interact with the system. They are drawn as stick figures. They actually
represent a type of user, not an instance of a user. Use cases represent the behavior of
the system, scenarios that the system goes through in response to stimuli from an
actor. They are drawn as ellipses.

Use Case Modeling

31
Each Use Case is documented by a description of the scenario. The description can be
written in textual form or in a step-by-step format. Each Use Case can also be defined
by other properties, such as the pre- and postconditions of the scenario – conditions that
exist before the scenario begins, and conditions that exist after the scenario completes.
Activity Diagrams provide a graphical tool to model the process of a Use Case. These
are described in a later section of this document.

Capture and/or Verify Requirements

The final objective of any software design is to satisfy the user requirements for the
system. These requirements can be software requirements, product requirements, or
testing requirements. The goal of capturing and verifying user requirements is to
ensure that all requirements are fulfilled by the design, and that the design conforms to
the defined requirements.

Oftentimes system requirements exist already in the form of requirements documents.

Use Cases are used tocorrelate every scenario to the requirements it fulfills. If the
requirements do not exist, modeling the system through Use Cases enables discovery of
requirements.

Organization of Use Case Diagrams

During business analysis of the system, you can develop one Use Case model for the
system, and build packages to represent the various business domains of the system.
You may decompose each package with a Use Case diagram that contains the Use
Cases of the domain, with actor interactions.

A Use Case for Every Scenario

The goal is to build a Use Case diagram for each significantly different kind of scenario
in the system. Each scenario shows a different sequence of interactions between actors
and the system, with no 'or' conditions.

32
Model Alternate Sequences through "Extends" Relationship

Typically, one models each Use Case with a normal sequence of actions. The user then
considers "what if" conditions for each step, and develops Use Cases based on these
alternate sequences of events. The alternate sequences are modeled in separate Use
Cases, which are related to the original Use Case by an "Extends" relationship. The
Extends relationship can be thought of as a Use Case equivalent to inheritance, in that
the Extending Use Case inherits and overrides behavior of the original Use Case.

Eliminate Redundant Modeling through "Uses" Relationship

To eliminate redundant modeling of a chunk of behavior that appears in multiple Use

Cases, the chunk of behavior can be modeled in a separate Use Case that is related to
the other Use Cases by the Uses relationship. The Uses relationship can be thought of
as a Use Case equivalent of aggregation

Use Case Extends Versus Uses Relationships

33
Use Cases Aid in Testing System against Requirements

Use Cases are also used to build test scripts that are used to verify that the application
satisfies the business and system requirements.When you have arrived at the lowest
Use Case level, you may create a Sequence diagram for the Use Case. With the
Sequence and Collaboration diagrams, you can model the implementation of the
scenario.

34
 SEQUECNCE DIAGRAM FOR AIRLINE BOOKING SYSTEM

The Sequence diagram is one of the most effective diagrams to model object interactions
in a system. A Sequence diagram is modeled for every Use Case. Whereas the Use Case
diagram enables modeling of a business view of the scenario, the Sequence diagram
contains implementation details of the scenario, including the objects and classes that
are used to implement the scenario, and messages passed between the objects.

Typically one examines the description of the Use Case to determine what objects are
necessary to implement the scenario. If you have modeled the description of the Use
Case as a sequence of steps, then you can ‘walk through’ the steps to discover what
objects are necessary for the steps to occur. A Sequence diagram shows objects involved
in the scenario by vertical dashed lines, and messages passed between the objects as
horizontal vectors. The messages are drawn chronologically from the top of thediagram
to the bottom; the horizontal spacing of objects is arbitrary.

During initial analysis, the modeler typically places the business name of a message on
the message line. Later, during design, the business name is replaced with the name of
the method being called by one object on the other. The method called, or invoked,
belongs to the definition of the class instantiated by the object on the receiving end of
the message.

35
SEQUENCE DIAGRAM FOR AIRLINE BOOKING SYSTEM

Sequence Diagram for a Scenario

36
 COLLABORATION DIAGRAM FOR AIRLINE BOOKING
SYSTEM

The Collaboration Diagram presents an alternate to the Sequence Diagram for

modeling interactions between objects in the system. Whereas in the Sequence Diagram
the focus is on the chronological sequence of the scenario being modeled, in the
Collaboration Diagram the focus is on understanding all of the effects on a given object
during a scenario.

Objects are connected by links, each link representing an instance of an association

between the respective classes involved. The link shows messages sent between the
objects, the type of message passed (synchronous, asynchronous, simple, balking, and
time-out), and the visibility of objects to each other.

Collaboration Diagram for a Group of Objects

37
 CLASS DIAGRAM

Analysis and Design with the Class Diagram

The class diagram is the main static analysis and design diagram for a system. In it,
the class structure of the system is specified, with relationships between classes and
inheritance structures. During analysis of the system, the diagram is developed with an
eye for an ideal solution. During design, the same diagram is used, and modified to
conform to implementation details.

Development of Class Diagram during Analysis

Use Case Driven Approach

In a Use Case-driven approach to OO analysis, the Class diagram is developed through

information garnered in the Use Cases, Sequence diagrams, and Collaboration
diagrams. The objects found during analysis are modeled in terms of the classes they
instantiate, and the object interactions are mapped to relationships between the
instantiated classes.

Class Diagram During Analysis Stage

38
Responsibility-Driven Extension

The CRC card technique is sometimes used as an extension to UML for responsibility-
driven analysis. Class definitions are refined based on the class's responsibilities and
other classes it collaborates with to fulfill responsibilities.

Each class is represented on an index card, and designers play-act the roles of classes in
the system to determine their job, and who they need to collaborate with to fulfill their
responsibilities. This information translates directly into a class diagram;
responsibilities correspond to class methods, collaborations translateto associations
between classes.

Informal UML Extension -- CRC Cards for Responsibility Driven Analysis

39
Design of System with Class Diagram

During design, the class diagram is elaborated to take into account the concrete details
of implementing thesystem.

Multi-Tiered Architectures

One concern during design is to establish the architecture of the system. This includes
establishing whether it will be a simple system designed to run on a single machine, a
two-tiered system consisting of a client and a server, or a multi-tiered system with user-
interface objects separate from business application objects separate from the database,
each potentially running on different platforms.One approach to managing the class
diagram for a complex system is to separate the diagram into sections that show the
application logic, the user interface design, and the classes involved with the storage of
data. This can be physically done by segmenting the class diagram, using separate
diagrams for each section, or simply by adding a property to each class that tracks
which tier it belongs to.

40
 COMPONENT DIAGRAM

Component Design

A component is a group of interacting objects or smaller components that combine to

provide a service. A component is similar to a black box, in which the services of the
component are specified by its interface or interfaces, without providing knowledge of
the component's internal design and implementation. Component-based development is
the process of assembling the right combination of components in the right
configuration to achieve desired functionality for a system.

Components are represented in the UML class diagram by specifying the interface of a
class or package. There are two notations to show an interface – one is to show the
interface as a regular class symbol with the stereotype <<interface>>, with a list of
operations supported by the interface listed in the operation department. The alternate,
shortcut notation is to display the interface as a small circle attached to the class by a
solid line, with the name of the interface by the circle.

The example in shows that the class Passenger provides a move(x coord, y coord)
operation for its appearance on a GUI, through its Displayable interface. Both UML
interface notations are shown in the figure. In addition, the Passenger class also
provides a save(store at) operation through its Persistent interface. A database
connectivity class or component might use this interface.

41
 INTERACTION DIAGRAM

Iterative Analysis and Design

The class diagram can be developed in an iterative fashion, through a repeated cycle of
analysis, design, and implementation, and then back to analysis, to begin the cycle
again. This process is often referred to as ‘round-trip engineering’. Modeling tools such
as System Architect 2001 can facilitate this process by enabling you to implement the
design in a language such as C++ or Java, and then reverse the code back into the
existing class diagram, automatically updating the information stored on the diagram
and in the underlying repository.

Iterative Analysis and Design and Documentation with Class Diagram

42
 STATE CHART DIAGRAM

Modeling Class Behavior with State Diagram

While interaction and collaboration diagrams model dynamic sequences of action

between groups of objects in a system, the state diagram is used to model the dynamic
behavior of a particular object, or class of objects. A state diagram is modeled for all
classes deemed to have significant dynamic behavior. In it, you model the sequence of
states that an object of the class goes through during its life in response to received
stimuli, together with its own responses and actions.

For example, an object’s behavior is modeled in terms of what state it is in initially, and
what state it transitions to when a particular event is received. You also model what
actions an object performs while in a certain state. States represent the conditions of
objects at certain points in time. Events represent incidents that cause objects to move
from one state to another. Transition lines depict the movement from one state to
another.Each transition line is labeled with the event that causes the transition.
Actions occur when an object arrives in a state.

Modeling Dynamic Behavior of Flight Object with State Diagram

43
 ACTIVITY DIAGRAM

The Activity Diagram is a multi-purpose process flow diagram that is used to model
behavior of the system. Activity diagrams can be used to model a Use Case, or a class,
or a complicated method. An Activity Diagram is similar to a flow chart; the one key
difference is that activity diagrams can show parallel processing. This is important
when using activity diagrams to model business processes, some of which can be
performed in parallel, and for modeling multiple threads in concurrent programs.

Using Activity Diagrams to Model Use Cases

Activity Diagrams provide a graphical tool to model the process of a Use Case. They can
be used in addition to, or in place of, a textual description of the Use Case, or a listing of
the steps of the Use Case. A textual description, code, or another activity diagram can
detail the activity further.

Using Activity Diagrams to Model Classes

When modeling the behavior of a class, a UML State Diagram is normally used to
model situations where asynchronous events occur. The Activity Diagram is used when
all or most of the events represent the completion of internally generated actions. You
should assign activities to classes before you are done with the activity diagram.

44
OBJECT DIAGRAM FOR AIRLINE BOOKING SYSTEM

Activity Diagram

45
Modeling Software Components

The component diagram is used to model the structure of the software, including
dependencies among software components, binary code components, and executable
components.

In the component diagram you model system components, sometimes grouped by

package, and the dependencies that exist between components (and packages of
components).

Modeling Components with Component Diagram

46
 ALGORITHM

In this phase further I had designed algorithms for various technical sub problem a few
than are enclosed here with.

RESERVATION

• A PERSON COME TO RESERVED A TICKET.

• THEN HE GIVES HIS FULL DETAILS
• IN CUSTOMER FORM THOSE DETAILS WERE WRITTEN.
• THEN COMPUTER CHEQUE THE DATE WHAT DATE THE PERSON
RESER VED
• DATE WISE IT CHEQUE THE FLIGHTS
• IF THE FLIGHT IS FLING THAT DAY
• THEN SYSTEM JUSTIFY THE SPECIFIC FLIGHT ID
• IT CHEQUE ITS SEAT CLASS.
• IF THE PASSENGER WANT TO ECONOMIC CLASS AND WINDOW SIDE
SEAT
• THEN SYSTEM CHEQUE IF THERE ANY SEAT IN ECONOMIC CLASS
WHICH IS INSIDE THE WINDOW
• IF SEAT IS EMPTY THEN SYSTEM RESERVED THE SEAT .
• THEN TICKET IS GENERATED.
• THE TICKET IS CONFIRMED.
• IF THE CONDITION IS NOT APPLIED THEN IT CHEQUE NEXT SEAT
• AND JUSTIFIED IT .
• IF IT IS NOT ALSO EMPTY THEN IT CHEQUE NEXT BY NEXT.
• IF THERE IS NO SEAT THEN SYSTEM TAKE TICKET WHICH IS NOT
CONFIRMED
• THEN IT GIVE WAITING LIST.
• END.

47
 CANCELLATION

• A PASSENGER COME TO CANCEL THE TICKET

• THEN THE SYSTEM OPEN THE DELET FORM
• THEN CLICK SHOE COMMAND
• IT DISPLAY ALL THE PASSENGER LIST
• THEN SELECT THE PNR NUMBER AND CLICK DELET OPTION
• THE SYSTEM SHOW RECORD IS DELETED.
• WHEN PASSENGER COME TO RESERVED A TICKET THEN SYSTEM
FIND OUT THE FLIGHT DETAILS.
• SYSTEM CLICK FLIGHT DETAILS OPTION THEN THE FLIGHT
DETAILS FORM OPEN
• THOSE SYSTEM ARE FOLLOWED .

FLIGHT DETAILS

• IN FLIGHT DEAILS WE FIRST CREATE A FORM.

• THEN WE MAKE ALL TEXT BOX.
• WE CREATE COMMAN BOX..
• IN THIS FORM WE ARE USE VARIOUS COMMAND BOX THOSE ARE
• PREVIOUS,FIRST,NEXT, ADD,NEW,UPDATE, DELETE, SAVE
• IN THIS FORM WE ADD NEW FLIGHT RECORD AND UPDATE IT
THEN THE VALUE IS GO TO THE DATABASE.
• WHEN WE CLICK NEXT , LAST , PREVIOUS, FIRST COMMAND
BUTTON
• THEN IT SHOW VARIOUS THING SERIALLY.
• A PERSON COMES TO KNOW THE TIMMINGS FOR THE FLIGHT WHICH
IS GOFROM DELHI TO GAU.
• THEN WE CLICK SHOW COMMAND BUTTON.

48
 CONCESSION

• FIRST IT CLICK THE CONCESSION BOX.

• CONCESSION BOX OPEN
• IT SELCT THE CETEGORI.
• THEN IT IS CALCULATE.
• AND THE FARE IS CALCULATE.
• THEN FINAL FARE IS GENERATE IN TICKET.

49
 FUNCTION POINT ANALYSIS

(COCOMO MODEL)

Function point analysis is a structural technique of problem solving. It is a method to

break system into small components so that they can be better understood and
analyzed.

Function point analysis is a unique measure for software.

1. Data communications-2
2. Distributed data processing-2
3. Performance-3
4. Heavily used configuration-2
5. Transaction rate-3
6. Online data entry-0
7. End user efficiency-1
8. Online update-0
9. Complex processing-3
10. Reusability-4
11. Installation ease-3
12. Operational ease-3
13. Multiple sites-0
14. Facilitate change-3

Function point = count total*[0.65+ (0.01*f(i)]

Where the f(i) [1, 2,…,14] are complexity adjustment values based on the responses to
14 statements. Scales ranges from 1, 2,3,4,5.

50
Type of component Complexity of the components
Count Low Function point
External inputs 9 3 15
External outputs 9 4 16
External inquiries 3 3 9
Internal logic files 1 7 7
External interface 1 5 6
Files
Count total 33

Formula

FP = count total*[0.65+ (0.01*ΣFi)]

=33*[0.65+ (0.01*29)]

= 31.02

Function point count for Airline reservation system= 31.02

Lines of code=31.02*29=899.5=0.8KLOC
Code developed in ‘C++’

Estimation of effort using Cocomo Model:

a=3.2; b=1.05

Effort =a*(KLOC) b
=3.2*(0.8)1.05
=2.5 person-month

Estimation of time using Cocomo Model:

Type of Project = Organic. Then, c=2.5; d=0.38

Time = (Effort) d * c
= (2.5) 0.38 * 2.5= 3.3 months
Estimation of Cost using Cocomo Model:
Cost = 3.3 *10000
= Rs. 33,000.

51
 TABLES

THE LIST OF TABLE IS WRITTEN HERE WHICH ARE USED IN DATABASE.

CUST_DETAIL
FIELD TYPE TYPE DESCRIPTION
T _DATE TRAVEL DAT
TEXT
TEXT CUSTOMER NAME
CUST_NAME
FATHER _NAME TEXT CUSTOMER FATHER
NAME

GENDER TEXT GENDER OF CUSTOMER

D_O_B DATE/TIME DATE OF

BIRTHOFCUCTOMER

ADDRESS TEXT ADDRESS OF CUSTOMER

TEL_NO NUMBER CUSTOMER TELPHONE

NUMBER

PROFESSION TEXT PROFESSION OF

CUSTOMER

SECURITY TEXT SECURITY OF CUSTOMER

CONCESSION TEXT CONCESSION OF

SECURITY

FLIGHT INFORMATION
F_NAME TEXT FLIGHT NAME

F_CODE NUMBER FLIGHT CODE

C_CODE TEXT CLASS CODE

T_EXE SEATNO NUMBER TOTAL EXECUTIVE

SEATNUM,BER

T_ECO SEATNO NUMBER TOTAL ECONOMIC SEAT

NUMBER

52
 FLEET INFORMATION

FIELD NAME DATATYPE DESCRIPTION

NO_AIRCRAFT TEXT NUMBER OF AIRCRAFT

CLUB_PRE_CAPACITY TEXT CLUB PRE CAPACITY

ECO_CAPACITY TEXT ECONOMIC CAPACITY

ENGINE_TYPE TEXT ENGINE TYPE

CRUISESPEED TEXT CRUISESPEED

AIR_LENGTH TEXT LENGTH OF AIR

WING_SPAM TEXT WING_SPAM

CONCESSION

CONCE_NAME TEXT CONCESSION NAME

CONCE_CODE NUMBER CODE OF CONCESSION

CLASS TEXT CLASS OF CONCESSION

DISCOUNT TEXT DISCOUNT CONCESSION

BASIS

V_O_T TEXT VALIDITY OF TICKET

BAG_ALLOW TEXT BAGGAGE ALLOWANCE

FARE_BASIC TEXT FARE BASIC FIXED

53
 FARE

FIELD NAME DATATYPE DESCRIPTION

ROUTE_CODE TEXT CODE NUMBER OF

ROUTE

S_PLACE TEXT SOURCE PLACE

VIA TEXT VIA

D_PLACE TEXT DESTINATION PLACE

D_TIME DATE/TIME DEPARTUE TIME

A_TIME DATE/TIME ARRIVAL TIME

F_CODE TEXT FLIGHT CODE

C_CODE TEXT CLASS CODE

FARE TEXT FARE OF CLASS

TICKET REPORT

TICKET NO NUMBER TICKET NUMBER

PNR NUMBER PASSENGER NUMBER

F_ID TEXT FLIGHT ID

S_PLACE TEXT SOURCE PLACE

D_PLACE TEXT DESTINATION PLACE

T_DATE TEXT TRAVEL DATE

D_TIME DATE/TIME DEPARTURE TIME

A_TIME DATE/TIME ARIVAL TIME

FARE 1 NUMBER FARE OF

FIRSTPASSENGER

FARE 2 NUMBER FARE OF SECOND

PASSENGER

FARE 3 NUMBER FARE OF

HIRDPASSENGER

54
 FARE 4 NUMBER FARE OF FOURTH
PASSENGER

FARE 5 NUMBER FARE OF

FIFTHPASSENGER

FARE 6 NUMBER FARE OF

SIXTHPASSENGER

SEAT_NO 1 NUMBER SEAT NUMBER OF 1ST

PASSENGER

SEAT_NO 2 NUMBER SEAT NUMBER OF 2ND

PASSENGER

SEAT_NO 3 NUMBER SEAT NUMBER OF 3RD

PASSENGER

SEAT_NO 4 NUMBER SEAT NUMBER OF 4TH

PASSENGER

SEAT_NO 5 NUMBER SEAT NUMBER OF 5TH

PASSENGER

SEAT_NO 6 NUMBER SEAT NUMBER OF 6TH

PASSENGER

AGE 1 NUMBER AGE OF 1ST PASSENGER

AGE 2 NUMBER AGE OF2ND

PASSENGER

AGE 3 NUMBER AGE OF 3RD PASSENGER

AGE 4 NUMBER AGE OF 4TH PASSENGER

AGE 5 NUMBER AGE OF 5TH PASSENGER

AGE 6 NUMBER AGE OF 6TH PASSENGER

CLASS TEXT CLASS

PASSENGER NUMBER TOTAL PASSENGER

55
 ENQUIRY

T_NO TEXT TICKET NUMBER

F_NAME TEXT FLIGHT NAME

F_CODE NUMBER FLIGHT CODE

C_SEATNO NUMBER CLASS SEAT NUMBER

C_FARE NUMBER CLASS FARE

CUST_CODE NUMBER CUSTOMER CODE

T_DATE TEXT TRAVEL DATE

T_TIME DATE/TIME TRAVEL TIME

CANCELLATION

CUST_CODE TEXT CUSTOMER CODE

CLASS TEXT CLASS

S_NO NUMBER SEAT NUMBER

DAYS LEFT DATE/TIME DAYS LEFT

HOURS LEFT DATE/TIME HOURS LEFT

BASIC AMMOUNT TEXT BASIC AMMOUNT

CANCELAMMOUNE NUMBER CANCEL AMMOUNT

RULES

DATE FROM DEP TEXT DATE FROM

DEPARTURE

PERCENTAGE TEXT PERCENTAGE OF

CANCEL

REFUND NUMBER REFUND AMMOUNT

56
 TERMS

AGE TEXT AGE OF PASSENGER

SEX TEXT SEX OF PASSENGER

FARE NUMBER FARE OF PASSENGER

RESERVED SEAT

F_CODE TEXT FLIGHT CODE

T_RES_ECO_SEAT NUMBER TOTAL RESERVED

ECONOMIC SEAT

T_RES_EXE_SEAT TEXT TOTAL RESERVED

EXECUTIVE SEAT

T_DATE TEXT TRAVEL DATE

WAITING_NO NUMBER WAITING LIST

57
 TESTING DEBUGGING AND VALIDATION

In these phases I had tried to check all the modules separately for their proper
formatting. After this step I had performed a unit test to check the functionality of
the whole system. Further I had come to know to add certain validation in project as
given bellow

1) Table name- Customer information

Field name –Customer name

Data type -Text.

When we enter number in the form then it show wrong .Because it is not number
type

It is a character. So it show wrong value.

2) Table name _Customer information

Field name- Departure time, Arrival time

Data type- Date/Time.

When we enter 12.33 then it automatically show 12.33pm.

When we enter 11.33 then it automatically show 11.33am.

3) Table name –Flight information

Field name- Flight-code

Data type- number

When we put any other value or character then it ask validity check.

58
 TESTING ANALYSIS

BLACKBOX TESTING:

The black box testing is used to demonstrate that the software functions are
operational. As the name suggests in black box testing it is tested whether the input is
accepted properly and output is correctly produced. The major focus o block box testing
is on functions, operations, external interfaces, external data and information.

WHITEBOX TESTING:

In white box testing the procedural details are closely examined. In this testing the
internals of software are tested to make sure that they operate according to
specifications and designs. Thus major focus of white box testing is on internal
structures, logic paths, control flows, data flows, internal data structures, conditions,
loops, etc

IMPLEMENTATION

For the implementation of my project the mirror H/W & S/W requirements as under

HARDWARE SOFTWARE

Pentium II to IV Window-9x,2000,2000server

Attempt 200 MHz MS-Access

Ram –32MB MS-Excel

H.D .space-4xGB MS-Word

Steps implementation

Steps of implementation are:

1. First load VB in system

2. Make a software .In this s/w The airlines Reservation system is stored.

59
 3. First make all form.
4. Make Main menu. Join every form with Main menu .
5. Main menu open .It show all forms heading.
6. Now choose what form will be open then click.
7. If Reservation form is open then it show new pnr and ticket number.
8. After put various value we click save bottom.
9. It automatically go to report.

MAINTENANCE

In software engineering the software maintenance is the process of enhancing and

optimizing deployed software as well as remedying defects.

Software maintenance is one of the phases in the software development process and
follows deployment of the software into the field. The software maintenance phase
involves changes to the software in order to correct defects and deficiencies found
during the field usage as well as the addition of new functionality to improve the
software usability and applicability.

CONCLUSION

When looking for solid AIRLINE RESERVATION SYSTEM software, you

want to find a solution that gives you the easy way of booking ticket. Naturally, you
first want to find the software that meets your needs, both now and in the future.
Engineering is based on designing different projects. Nowadays,” most products and
systems are becoming more complex in nature, and there is an increasing demand
relative to new technology applications at a time when our natural resources are
dwindling” now that’s where engineering jumps in. Business depending on natural
resources is no longer in a safe position. Engineering and engineers are not only useful
for the technologies and machineries in the business world, but it is also constructive in
different components of business such as entertainment, telecommunication and etc…

60