We are sorry if you are not getting the correct synopsis.

This is an auto generated document, if you looking for

the particular project then, please whatsapp to
9243101428. We will send you the available updated
document for you.

HighBlix - Final Year Projects | Bangalore

We train and assist you in doing final year projects of Electronics

and CS Students.

BE, ME, BTech, MTech, BCA, MCA, BSc, MSc, Diploma students

We do project in VB, VB.net, ASP.net, C#, MS SqlServer, Java, JSP, PHP, Mysql, Python, Android,
Electronics, IOT etc.,

You can share your project related queries here. We have around 20 years of experience in
developing projects in VB, VB.net, ASP.net, C#, MS SqlServer, Java, JSP, PHP, Mysql, Python, Android.
We specialize in providing be final year project along with proper guidance and training. We
provide all these so that students can get real time knowledge along with training and guidance
throughout their final year. By joining our institute not only you will complete your project, you
gain lot of subject knowledge and project experience.

Please contact us at.

HighBlix Projects
No 826, 9th Main, Hampinagar
Bangalore, Karnataka, India. Pin - 560104.
email : highblix@gmail.com
Land Mark (Near Hampinagar Main BusStop, Opp National Public School)

Mobile: 9243101428, 7019755620

 Online Air
ticket Booking
System

Document
 Description Page No

1. Requirement Specification 3 - 5
2. Functional Specification 6 - 9
3. Design specification 10-13
4. Database Design 14-15
5. Test phase and text cases 16-23
6. User Documentation 24-48
Software Requirements Specification
(SRS)
Abstract
This document fully and formally describes the requirements of the proposed said
project system. It sets out the functional and non-functional requirements and
includes a description of the user interface and documentation and training
requirements.

Introduction
Online Air Ticket Booking system is to provide an option to customers to book the
tickets online and to check the confirmation online. This system will help the this
company to sell the flight tickets online. Unless like in the previous stage people as
to walk into travel agency or this company ticket counter to buy the tickets. And
also to check the flight timings. This problem is over come introducing this system.
Existing System
Presently this company have ticket counters in the airport. Where people as to
come to book the tickets or to check the flight timings. Also there are many travel
agents take the advance booking. In turn these agents will check out with the main
ticket counter officials for the ticket confirmation. Which is very lengthy and tedious
process.

Proposed System
The proposed system will available online. So anybody who are interested in the
flight timings and ticket booking they check online only.
Hardware Requirements

Pentium III 400MHz and Above

128MB RAM

15” Color Monitor

Keyboard

Mouse

Software Requirements

Windows 2000/XP Operating System.

Visual Basic.net 2003

Asp.net

MS Access

Internet Explorer
IIS 5.0
Functional Specification
The Functional Specification is created after the Software Requirements Document.
It provides more detail on selected items originally described in the Software
Requirements Document. Some software development organizations combine these
two documents into a single document.

The Functional Specification describes the features of the software product. It

describes the product's behavior as seen by an external observer, and contains the
technical information and data needed for the design. The Functional Specification
defines what the functionality will be, but not how that functionality will be
implemented.

The software engineer uses the Functional Specification document to create a

detailed design document that explains in detail how the software will be designed
and developed. The detailed design work may further decompose and translate the
functional requirements into pseudocode, and from there into a computer module
or program.

The functional specification translates the Software Requirements Document into a

technical description that:

 Ensures that the product feature requirements are correctly understood

before moving into the next step, the software design process.
 Clearly and unambiguously provides all the information necessary to design
the software.

Developing Functional Specification Contents

The Functional Specification contents are determined by the project manager, the
software developer, and typical end-users.

The end-users are important members of this team, because they will help ensure
the software will meet the business and engineering needs of those who will use the
software. The project's user group is a good source for information and review. For
guidance on drafting a functional specification, please see the links in the
Background Material and Examples section below.
Functional Specification Scope

The Functional Specification includes specific information about each functional

requirement of the software. The Functional Specification should describe, for each
functional requirement:

 Purpose - What the function is intended to accomplish.

 Input - What inputs will be accepted, in what format the inputs arrive,
sources for the inputs, and other input characteristics.
 Process -The steps to be performed, algorithms, formulas, or techniques to
be used. Software implementation details are not included, however.
 Output - Desired outcomes such as the output form (e.g. report layout), the
destination of the output, output volume and timing, error handling
procedures, and units of measure.

Usability items need to be included in the Functional Specification. These are

features that ensure user friendliness of the software. Examples include clear error
messages, input range checking as soon as entries are made, and order of choices
and screens corresponding to user preferences.
FUNCTIONAL DESCRIPTION:

The problem under study is being divided into several modules/functions

discussed below to understand the approach to the solution in the broader way:

Admin Part

Place Entry Screen : In this screen enter all city or place names where flights
have route. This is used in the flight scheduling. Make the name short if it is more
than 50 characters

Place Entry Result Screen : If the place name successfully entered then
message as to be appear stating that the record created successfully else if the
place name already entered then it should give the display that place name already
entered, so there is no chance of duplication of the names.

Flight Scheduling Screen : In this screen option should be provided to schedule

the flights. Here Flight name, from place, to place, date and time as to be
considered properly.

Ticket Price Entry : In this screen provision is provided to enter the ticket price
for each class and for each flight.

Ticket Booking Checking : This screen must show all the tickets booked for the
particular flight

Flight wise Ticket Booked list : This show complete list of the confirmed booking
list.
Admin Password Change screen : This screen is provided to change the admin
password.

New User Creation Screen : This screen is provided to create the new user.
Client Part

Customer Login Screen : In this screen options are provided to customer login
with username and password. If the username and password is correct then
customer allow login. Else it should show appropriate message.

New User Signup form : This screen is provided to new user to sign up. Any new
customer can signup from this form. All the personal details as be collected in this
form. Along with the phone number and email address.

Client Option Screen : It show all the possible options for the customer after
login.

Flight Checking Screen : From this screen customer can check the flight timings.
Option should provided to select the flight and date.

Flight Schedule result screen : This shows all the possible flights available for
the customer.

Client Ticket booking Screen : Based on the flight timings customer can book the
ticket. Here flight name, date, time, seating type all will considered.

Client Ticket Payment Screen : Here customer will enter the mode of payment,
and details of the payment.

Ticket Booking Result Screen : this show message if ticket booked is complete.
Client Ticket Confirmation display form : After confirm ticket in the admin part,
customer can see the message about the confirmation of the ticket.
Software Design Specification
The Software Design Specification (SDS) given in this outline are guidelines to the contents
of your SDS. The document should present the conceptual and detailed technical design of
the software/module that you are developing.

Introduction
Purpose of this Document

This Software Design Specification (SDS) document contains a statement of the design of
the above title project. In an SDS, the designers are supposed to provide an unambiguous
design of the product. The design should contain an explanation of a way to carry out each
of the product specifications written in the Software Requirements Specification (SRS). The
design then serves as a guide to the developers who write the code and actually create the
product. The SDS discusses how the program is separated into modules, how the modules
interact with each other, and how users see the program. The SDS also looks into several
design considerations, including design tradeoffs and code reusability.

Scope of the Development Project

The project Tool is a new project which creates an interactive and easy program. The
package serve to the end user customers. Eventually, we hope to reach a broader audience.

Definitions, Acronyms, and Abbreviations

 ActionScript - ActionScript is a tool used to write the code that controls the actions
in animated Flash presentations.
 Asp.net – Microsoft web based project development tool
 C, C++ - The names of two object oriented programming languages commonly used
in industry.
 CEO - Chief Executive Officer.
 Form – is object holder in Visual Basic Language. Defines single screen.
 HTML - Hypertext Markup Language. A language used to create Web documents.
 IIS – Internet Information Server 5.0
 Internet Explorer – Microsoft Internet Browser version 6.0
 MS Access – Microsoft developed Database Program.
 Oracle – Oracle Corporation RDBMS database program.
 SDS - Software Design Specification document.
 SQL Server – Microsoft RDBMS software.
 SRS - Software Requirements Specification document.
 Visual Basic 6.0 – Programming Language
 VB.net – Microsoft dot net Programming tool
System architecture description
Document Outline

Here is the outline of the proposed template for software design specifications. Please note that
many parts of the document may be extracted automatically from other sources and/or may be
contained in other, smaller documents. What follows is just one suggested outline format to use
when attempting to present the architecture and design of the entire system as one single
document. This by no means implies that it literally is a single document (that would not be my
personal preference):

Major Screens/Page Description

Place Entry Screen used enter the place or city names

Place Entry Result Screen This show confirmation

Flight Scheduling Screen used for flight scheduling

Ticket Price Entry here you can enter the ticket price

Ticket Booking Checking shows the list of ticket booked

Flight wise Ticket Booked list individual flight wise ticket booked

Admin Password Change screen to change the admin password

New User Creation Screen allow to create the new user.

Detailed description of components

Admin Part

Place Entry Screen : In this screen enter all city or place names where flights
have route. This is used in the flight scheduling. Make the name short if it is more
than 50 characters

Place Entry Result Screen : If the place name successfully entered then
message as to be appear stating that the record created successfully else if the
place name already entered then it should give the display that place name already
entered, so there is no chance of duplication of the names.

Flight Scheduling Screen : In this screen option should be provided to schedule

the flights. Here Flight name, from place, to place, date and time as to be
considered properly.

Ticket Price Entry : In this screen provision is provided to enter the ticket price
for each class and for each flight.

Ticket Booking Checking : This screen must show all the tickets booked for the
particular flight

Flight wise Ticket Booked list : This show complete list of the confirmed booking
list.

Admin Password Change screen : This screen is provided to change the admin
password.

New User Creation Screen : This screen is provided to create the new user.
Client Part

Customer Login Screen : In this screen options are provided to customer login
with username and password. If the username and password is correct then
customer allow login. Else it should show appropriate message.

New User Signup form : This screen is provided to new user to sign up. Any new
customer can signup from this form. All the personal details as be collected in this
form. Along with the phone number and email address.

Client Option Screen : It show all the possible options for the customer after
login.

Flight Checking Screen : From this screen customer can check the flight timings.
Option should provided to select the flight and date.

Flight Schedule result screen : This shows all the possible flights available for
the customer.

Client Ticket booking Screen : Based on the flight timings customer can book the
ticket. Here flight name, date, time, seating type all will considered.

Client Ticket Payment Screen : Here customer will enter the mode of payment,
and details of the payment.

Ticket Booking Result Screen : this show message if ticket booked is complete.
Client Ticket Confirmation display form : After confirm ticket in the admin part,
customer can see the message about the confirmation of the ticket.
Database Design

ADMINTAB

UNAME TEXT

PWORD TEXT

ANAME TEXT

CUSTOMER

UNAME TEXT

PWORD TEXT

CNAME TEXT

GENDER TEXT

DOB DATE

ADD1 TEXT

ADD2 TEXT

ADD3 TEXT

ADD4 TEXT

PHONE TEXT

EMAIL TEXT

PASSPORT TEXT

FLIGHTSDET

FNAME TEXT

DES TEXT

DOP DATE

FTYPE TEXT
DCLASS INTEGER

BCLASS INTEGER

ECLASS INTEGER

FSCHEDULE

RNO INTEGER

FNAME TEXT

FPLACE TEXT

TPLACE TEXT

FDATE DATE

FTIME TEXT

PLACENAMES

PNAME TEXT

COUNTRY TEXT

DIS INTEGER

TICKETORDER

RNO INTEGER

FDATE DATE

FTIME TEXT

FPLACE TEXT

TPLACE TEXT

FNAME TEXT

TTYPE TEXT

UNAME TEXT

STATUS TEXT
TPRICE CURRENCY

QTY INTEGER

PTYPE TEXT

AMOUNT CURRENCY

DDNO TEXT

BALAMT CURRENCY

BALAMTPAID CURRENCY

BPDATE DATE

CMSG TEXT

TICKETPRICE

FNAME TEXT

FPLACE TEXT

TPLACE TEXT

LCLASS CURRENCY

BCLASS CURRENCY

ECLASS CURRENCY
Testing
Introduction

This document is intended to be used throughout the coding and testing phases of the
project. It outlines the procedures used for testing and verification of the code. The
document also describes the integration procedures and the order in which modules will be
coded, and describes the test procedures and results of testing.

This section deals with the details of the classes of tests which must be conducted to
validate the functions, performance, and the constraints. This is achieved basically by the
means of testing which plays a vital role in the development of the software. The various
low level testing which can be grouped on a broader sense are discussed as below:

There are three levels of testing:

1. Unit Testing -- Each module will be tested separately to ensure that it is working
before being combined with other modules.
2. Integration Testing -- Related modules will be integrated and tested together
before being placed into the system.
3. System Testing -- The entire system will be tested together after integration is
complete. System testing includes function, acceptance, installation and regression
testing. System testing will involve some beta testing by the client.

Notes

All testing has been carried out using some sample data.

Each section in the remainder of this document has lists of test criteria that must be
satisfied for the system to have passed that section of testing. In front of the each criterial
test Passed or Failed is written.

Unit Testing
The purpose of unit testing is to uncover errors in the smallest software unit -- the routine.
Each routine will be tested individually using black box-oriented tests. The programmer of
each module will design a set of test cases for that module and ensure that the module is
fully tested. Important or complex routines will also be tested by at least one other person.
Integration Testing
This section describes the integration strategy and procedures for the system. It gives the
order in which modules will be developed and how they will be integrated. It also describes
the specific tests that will be performed on integrated sets of modules. Note: It is important
that each module be thoroughly tested as a unit before being integrated with other
modules.

Integration testing of unit tested modules is necessary to ensure that:

 modules interface correctly with each other;

 one module does not have inadvertent, undesirable effects on another module;
 submodules (routines) combine to produce the desired functions of the major
module;
 interfaces to, and use of global data structures are consistent.
System Testing
Functional Requirements Testing
The functionality tests should be performed by the application representatives and treat the
whole system as a black box using the actual applications or middleware. The aim of these
tests is to verify the overall functionality of the system.

This will be performed by a section by section walkthrough of the SRS functional

requirements section. All functional requirements in the SRS must be fulfilled.
Beta Testing
Method

This will be performed by the client, and by potential users of the system at the Bureau of
Meteorology. Users will be given a copy of the system to try out. Any problems with the
system will be reported back to the group.

Beta Testing

To help us achieve the best possible result with our project, we have decided to get as much
input as possible from potential users of our system.

Bugs.

If unexpected events happen while using project,

Alterations.

If there is anything missing from the system, that you would like to see there, we would
also like to know about it. Most likely we will not be able to implement the changes to the
current system (due to time restraints), but when the full system is written next year, it will
most likely be present.

 All Comments... Can be sent to us in various ways.

Please include your name and email address in any correspondence.

Results

Comments received from the customers:

Alpha testing - prototype 2 of system

Performance and Stress Testing
A set of tests have been developed for performance and stress testing. Performance tests
will ensure that the system responds in a reasonable time to user input (as defined in the
SRS). The aim of stress testing is to try to break the program by giving it abnormal or
extreme input quantity, frequency or volume.

Performance testing will be performed at the client's site after installation. According to the
SRS:

The system must respond to all reports within 10 seconds on an Pentium IV computer with
a load average less than 1.

Performance criteria satisfied.

Stress testing with extreme and abnormal input cases has been been performed where
necessary on individual routines in the Unit Testing section.

Stress testing satisfied.

Acceptance Testing
Acceptance testing consists of a suite of tests to be performed in the presence of the client
before he accepts the system. It will consist of the function tests, performance tests (at the
client's site), a walk-through of the user manual and the final demonstration.

Function tests accepted.

Performance tests accepted.

User manual walkthrough accepted. Will be held performed along with Installation
Testing.

Final demonstration accepted.

Installation Testing
Installation tests will check the installation and configuration procedure as well as any
missing dependencies.

Installation tests test the installation and configuration procedures. These tests are a set of
scripts that automatically download all necessary packages and install them.

Acceptance testing will be repeated after installation of the system at the Customer Place.
This is to ensure that the system works correctly in the Customer Place.

Note: System has not been installed for the client yet. Will be installed this week.

Some specific points that also need to be tested are:

1. Directory paths for data and help files are set up correctly and can be found by the
system.
2. Check for necessary third party controls.
3. All IDL library functions can be found by the system.
4. All fonts for the text tool can be found and loaded -- beta testing uncovered some
problems loading some fonts.
5. Check Printer drivers are installed properly.
Regression Testing
The selective retesting of a software system that has been modified to ensure that any bugs
have been fixed and that no other previously working functions have failed as a result of the
reparations and that newly added features have not created problems with previous
versions of the software. Also referred to as verification testing, regression testing is
initiated after a programmer has attempted to fix a recognized problem or has added source
code to a program that may have inadvertently introduced errors. It is a quality control
measure to ensure that the newly modified code still complies with its specified
requirements and that unmodified code has not been affected by the maintenance activity.

Regression testing was not usually necesary, because most of the errors detected were very
localised, and did not affect other functions in an adverse manner.
User Manual
Index Page