ACKNOWLEDGEMENT

“The compilation of any project depends upon the co-operation, coordination and
combined efforts of several resources of knowledge, inspiration and energy”.
Words fall short acknowledging immense support lent to us by everyone and we
give full credit to them.
Our sincere thanks goes to Mr. Anil Kumar for giving us the opportunity to
discover more knowledge. We are thankful to him for his constant support,
guidance and cooperation throughout to accomplish this project. It has been of
the greatest help in bringing out our task in the present state.
It would be unfair on our part if we do not thank our parents for their continuous
help and support without which this work could have never been accomplished.
We are equally grateful to all our teachers and friends for their help and guidance.

Jatin Rohilla
Surbhi Mittal
 CERTIFICATE

This is to certify that the project entitled,

“AIRLINE RESERVATION SYSTEM” has been done by
Jatin Rohilla and Surbhi Mittal of Bachelor of Computer Science
(Hons.) during semester IV in the academic year 2015-2016 from
Deen Dayal Upadhyaya College, University of Delhi under the
supervision of Mr Anil Kumar.

Mr. Anil Kumar

 Table of Contents
ABSTRACT
1. INTRODUCTION
1.1 Overview
1.2 Problem Statement
1.3 Objectives
1.4 Significance
1.5 Process Model Used

2. REQUIREMENTS ENGINEERING
2.1 Feasibility Study
2.2 Requirement Elicitation
2.3 QFD
2.4 SRS
2.5 Requirements Validation

3. SYSTEM DESIGN AND ANALYSIS

3.1 ER Diagram
3.2 Database Design
3.3 CFD
3.4 Cohesion and Coupling
3.5 DFD
3.6 Data Dictionary

4. PROJECT MANAGEMENT
4.1 Function Points
4.2 Risk Estimation
4.3 Timeline Chart
5. TESTING
5.1 Verification and Validation
5.2 Testing Strategies
5.3 Black Box and White Box Testing
5.4 Cyclomatic Complexity

CONCLUSION
BIBLIOGRAPHY
 ABSTRACT

Airline Reservation Systems (ARS) used to be standalone systems. Each airline

had its own system, disconnected from other airlines or ticket agents, and usable
only by a designated number of airline employees.
Today, air travel information is linked, stored, and retrieved by a network of
Computer Reservations Systems (CRS), accessible by multiple airlines and travel
agents.
This report is a summary of the steps that were undertaken to design and
implement an airline reservation system. The airline reservation system designed
in this project was developed using php, java script and html as the programming
languages and MySQL as the database Management system.
We used brainstorming and questionnaire methods during the data collection
phase, these data collection methods helped the researcher to better understand
the existing system in use. Data flow and Entity Relationship diagram were used
during the development process to simulate the process of airline reservation and
ticket booking. The outcome of the study was an online airline reservation system
tested and implemented to book, schedule and reserve flights.
 1. INTRODUCTION
1.1 Overview
In science and technology, the desire for improvement is a constant subject which
triggers advancements. This is visible in every ramification and the airline industry is
not an exemption. Airline reservation systems were first introduced in the late 1950s as
relatively simple standalone systems to control flight inventory, maintain flight
schedules, seat assignments and aircraft loading. Today modern airline reservation
systems are comprehensive suites of products to provide systems that assist with a
variety of airline management tasks and service customer needs from the time of initial
reservation through completion of the flight.
A Computer Reservations System is a computerized system used to store and retrieve
information and conduct transactions related to travel. Computer reservation systems
are classified as Passenger Service Systems (PSS) which handles a series of critical
functions for the airline.
The Internet has become a major resource for people looking for making reservations
online without the hassle of meeting travel agents. Businessmen who travel on regularly
face difficulties on day to day basis. This issue can be resolved by implementing an
online reservation system.
For an Airline, the reservation system is a mission critical system that should use the
latest state of the art technology to provide for all flight reservations on a robust
platform, which is flexible and can be adapted to any style of airline along with Security
and stability.

1.2 Problem Statement

The current system is manual, this system is slow, time consuming and it is very difficult
for each person to book through office agents. Users inquire about the tickets through
phones and it is very difficult for the user to remember all the details that they received
through phones. It is very difficult to calculate how many peoples registered and how
many seats on a particular plane are vacant .This requires quite a lot of time and wastage
of money as it requires quite lot of manpower to do.
Therefore, a better system is required in place to handle all the inconsistencies and to
provide a better customer support.
1.3 Objectives

General objective
To automate the process of airline ticket reservation, booking and airline management
hence minimize errors resulting from manual system operations. The main AIM is to
develop an Online Reservation System.

Specific objectives
1. To determine the requirements for the new system.
2. To design an online airline reservation information system to facilitate online
booking and flight scheduling.
3. To implement the developed web based airline information system.
4. To test and validate the developed system.

1.4 Advantages

For Customers -
1. Convenience: Being able to make all your travel plans on the Internet means
you can do it any time of the day or night at home, or while you are on your
lunch break at the office. Customers on the go can even make reservations on
their smartphones or tablets. With just a few minutes and a click of the mouse,
you will have all your plans finalized.

2. Changes and Cancelations: It is simple for travellers to change or cancel

online reservations. Instead of calling the hotel or airline and waiting for a
customer service representative to help you through the process, booking online
means you can cancel it wherever you have Internet access.

3. Customer Reviews: Making a reservation over the phone or at a travel agency

does not allow you to check out what past customers have thought of hotel chains
or certain airlines. Another benefit of making online reservations is being able to
see these customer reviews.
For the Airline Company -
1. Minimize repetitive work done by the system administrator and reservation
clerks.
2. Maintain consistency among different access modes, e.g. by phone, by web, at
the information desk and across different physical locations.
3. Minimize the number of vacant seats on a flight and maximize flight capacity
utilization.
4. Reduce effort and frustration for travellers in scheduling a trip, especially by
reducing the search effort for the flight they need to take.

1.5 Software Model Used

Waterfall Model
In the development of the “Airline Reservation System”, we used the Waterfall Model.
The waterfall Model illustrates the software development process in a linear sequential
flow, hence it is also referred to as a linear-sequential life cycle model. This means that
any phase in the development process begins only if the previous phase is complete.
Typically, the outcome of one phase acts as the input for the next phase sequentially.

The sequential phases in Waterfall model are:

1. Requirement Gathering and analysis: All possible requirements of the

system to be developed are captured in this phase and documented in a
requirement specification doc.

2. System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in defining
overall system architecture and the data flow of different modules.

3. Implementation: With inputs from system design, the system is first

developed in small programs called units. Each unit is developed and tested for
its functionality. In the next phase, all these units are integrated to form the final
product.
 Figure 1: The Waterfall Model

4. Integration and Testing: All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.

5. Maintenance: Once the functional and non-functional testing is done, the

product is deployed in the customer environment or released into the market.
There are some issues which come up in the client environment. To fix those
issues patches are released. To enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer
environment.

Limitations of the Waterfall Model –

1. Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-thought out in the concept stage.
2. No working software is produced until late during the life cycle.
3. Not suitable for the projects where requirements are at a moderate to high risk of
changing.
 2. Requirements Engineering
The process to gather the software requirements from client, analyse and document
them is known as requirement engineering. The goal of requirement engineering is to
develop a sophisticated and descriptive ‘Software Requirements Specification’
document.
In the waterfall model, requirements engineering is presented as the first phase of the
development process. It is a four step process, which includes –
1. Feasibility Study.
2. Requirement Gathering.
3. Software Requirement Specification.
4. Software Requirement Validation.

2.1 Feasibility Study

Financial Feasibility
This project is financial feasible as its development can be done at affordable costs.
While we are developing our project, all the facilities are provided to us. The only
investment we had to make was in gathering study material because all the hardware
and software requirement of this project are readily available therefore our project is
financially feasible.

Schedule Feasibility
The development of this project is at a small scale with limited features, all of which
can be easily achieved within the stipulated time frame. Therefore we can say that a
project is schedule feasible.

Operational Feasibility
To use the developed product, the user must be familiar with computer systems and
internet. Today, most of the urban citizens are well acquainted with PCs and internet,
so no extra skill is required to use the product. Also, the product would be beneficial to
its users as their needs are fully satisfied. As this project satisfies all the requirements
of the users and requires no extra skill set, it is operationally feasible.
2.2 Requirement Elicitation

2.2.1 Brainstorming
Brainstorming is an excellent way of eliciting many creative ideas for an area of interest.
Structured brainstorming produces numerous creative ideas about any given "central
question" or topic.
Brainstorming works by focusing on a topic or problem, and then coming up with many
radical solutions to it. This technique is best applied in a group as it draws on the
experience and creativity of all members of the group. In the absence of a group, one
could brainstorm on one's own to spark new ideas.

Limitations –
i. Dependent on participants' creativity.
ii. May not end up with usable solutions.

2.2.2 Questionnaire
We used questionnaire to gather information from clients who would come to the airline
head offices to book and check in when their flights are due. We used a combination of
open and closed ended questions. The respondents were asked to tick their choice from
a given number of choices (closed ended). Also the respondents were asked to describe
the current system in their own words (open ended questions). Context free as well as
Context Specific Questions were asked in the questionnaire.
Limitations –
i. Some views deviated from the question (open ended questions).

Context Free Questions

1. Who would be using the system?
2. How would the new system benefit you?
3. What output do you expect from the software?
4. Where the software would to be installed?
5. Do you want any special features?
6. What security level would you like to set for the software?
7. What is the time limit for the software to be completed?
Context Specific Questions
1. What details of the customer do you want to store?
2. Do you want the history trips of the customer to be saved?
3. Can user book multiple tickets?
4. Is online payment facility required in the software?

2.3 Quality Function Deployment (QFD)

QFD is a quality management technique that translates the need of the customer into
technical requirements for the software. It maximizes customer’s satisfaction by
evaluating the requirements of the customer.

Normal Requirements –
i. Storing customer details.
ii. Reservation/ cancellation of tickets.
iii. Displaying Schedule.

Expected Requirements –
i. Interactive Interface.
ii. Proper Security measures for online payment.
iii. Confirmation of booking by email.
iv. Showing history of Journey’s.

Exciting Requirements –
i. Impressive lightweight graphics
ii. Registration directly via google/ Facebook account.
iii. Displaying LIVE status of Flights on the website.
iv. Advertising most frequently bought Journey’s.

2.4 Software Requirements Specification (SRS)

A software requirements specification (SRS) is a document that captures complete
description about how the system is expected to perform. It is usually signed off at the
end of requirements engineering phase.
2.4.1 Scope –
1. Facilitate online booking.
2. Keep customer records.
3. Provides an online menu on flight schedules.
4. Flight destinations and their prices.

2.4.2 Functional Requirements –

1. User account: A registered user can directly view flight details or/and book
flights. A new user must register first.

2. Creation of new user account: When there is a new customer he should fill
the form containing field like Name, Address, and Contact No. , Gender, Email_
id, Age and also User Id and Password.

3. Checking Availability: To check the available flight the user should input the
origin city and destination city, date of journey.

4. Reservation of Flight: After providing all information the system will ask user
for confirmation. After confirming the information the seats get reserved.

5. Cancelling / Rescheduling of Ticket: To cancel the reservation the customer

should provide the details about Ticket no and flight no.

2.4.3 Non-Functional Requirements –

1. Security Requirements: There is only one authorized person who can see the
confidential Information. The information of the customer is only available for
the administrator.

2. Software Quality Attributes: The system must be user friendly, interoperable

and flexible.
2.5 Requirements validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost.
Requirements can be checked against following conditions -
1. If they can be practically implemented.
2. If they are valid and as per functionality and domain of software.
3. If there are any ambiguities.
4. If they are complete.
5. If they can be demonstrated.
 3. SYSTEM DESIGN AND ANALYSIS

Symbols used in ER diagram:

3.1 ER Diagram

Figure 2: ER diagram
3.2 Database Design

Table 1: Customer Table

Attribute Description
Cust_Id (PK) Unique customer Id
F_Name First name of Customer
L_Name Last name of Customer
Email Email
Password Password ( 8 to 16 digits)
Mobile_No Mobile number

Table 2: Journey Table

Attribute Description
Journey_Id (PK) Unique Journey Id
Source Source of the journey
Destination Destination of the Journey
Fare Fare of the Journey

Table 3: Tickets Table

Attribute Description
Ticket_no [ Seat No
Flight_Id Flight Id
Journey_id Journey Id
Takeoff_date Take Off Date of the Flight ] - composite primary
key
Cust_Id foreign key

Table 4: Schedule Table

Attribute Description
Flight_Id [ Flight Id
Journey_Id Journey Id
Takeoff_Date Take Off Date of the Flight ] - composite primary
key
Tickets_booked Passenger count
Takeoff_Time Takeoff time in 24 hour format
Table 5: Flight Table

Attribute Description
Flight_id 3 letter flight code
Flight_Name Flight Name
Total Capacity Total capacity of the Flight

3.3 Context Flow Diagram (CFD)

Context Flow diagram is one in which the entire system is treated as a single process
and all its inputs, outputs, sinks, and sources are identified and shown.

Figure 3 : CFD
3.4 Cohesion and Coupling
When a software program is modularized, its tasks are divided into several modules
based on some characteristics. As we know, modules are set of instructions put together
in order to achieve some tasks. They are though, considered as single entity but may
refer to each other to work together. There are measures by which the quality of a design
of modules and their interaction among them can be measured. These measures are
called coupling and cohesion.

Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of
a module. The greater the cohesion, the better is the program design.
Cohesion measures the strength of relationship between pieces of functionality within
a given module.
Advantages of high cohesion are:
1. Readability – closely related functions are contained in a single module.
2. Maintainability – debugging tends to be contained in a single module.
3. Reusability – because developers will find the component they need more
easily among the cohesive set of operations provided by the module.

Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The
lower the coupling, the better the program. A program with low coupling is often called
loosely coupled.
Coupling is the manner and degree of interdependence between software modules.
Advantages of loosely coupled systems are:
1. Maintainability – changes are confined in a single module.
2. Components in a loosely coupled system can be replaced with alternative
implementations that provide the same services.
3. Testability – modules involved in unit testing can be limited to a minimum.
4. Components in a loosely coupled system are less constrained to the same
platform, language, operating system, or build environment.
3.5 Data Flow Diagram (DFD)
A data flow diagram is a graphical representation that depicts information flow and the
transforms that are applied as data move from input to output.
DFD is an abstract description of the system. The data flow diagram may be used to
represent a system or software at any level of abstraction. DFDs may be partitioned into
levels that represent increasing information flow and functional detail like the Level 0
DFD (or the CFD), followed by Level 1 DFD and so on where each level has increased
degree of functional details. DFDs are very useful in understanding a system and can
be effectively used during analysis.

Figure 4: Level 1 DFD

3.6 Data Dictionary
The data dictionary is an organized listing of all data elements that are pertinent to the
system, with precise, rigorous definitions so that both user and system analyst will have
a common understanding of inputs, outputs, components of stores and intermediate
calculations.
Data dictionary is often referenced as meta-data (data about data) repository. It is
created along with DFD (Data Flow Diagram) model of software program and is
expected to be updated whenever DFD is changed or updated.

Symbol Meaning
= Composed of
{} Repetition
() Optional
+ And
| Or

 Customer=Cust_id+F_Name+L_name+Email+Password+Mobile_No
o Cust_id= digit+digit+digit+digit+digit
o Mobile_No= digit+digit+digit+digit+digit+digit+digit+digit+digit+digit

 Journey= Journey_id+Source+Destination+Fare
o Journey_id= digit+digit+digit

 Flight= Flight_id+Flight_name+Total_Capacity
o Flight_id= digit+digit+digit

 Tickets= Ticket_no+Flight_id+Journey_id+Takeoff_date+Cust_id
o Ticket_no= digit+digit+digit
o Flight_id= digit+digit+digit
o Journey_id= digit+digit+digit
o Takeoff_date= month+day+year [ mm/dd/yyyy ]
o Cust_id= digit+digit+digit+digit+digit

 Schedule= Flight_id+Journey_id+Takeoff_date+Tickets_booked+Takeoff_time
o Flight_id= digit+digit+digit
o Journey_id= digit+digit+digit
o Takeoff_date= month+day+year
o Takeoff_time= hours+minutes+seconds
 4. Project Management
4.1 Function Points
The function point (FP) metric can be used effectively as a means for measuring the
functionality delivered by a system.

Using historical data, the FP metric can then be used to:

1. Estimate the cost or effort required to design, code, and test the software.
2. Predict the number of errors that will be encountered during testing.
3. Forecast the number of components and/or the number of projected source lines
in the implemented system.
Function points are derived using an empirical relationship based on direct measures of
software’s information domain and qualitative assessments of software complexity.
Information domain values are defined in the following manner:

Number of external inputs (EIs)

Each external input originates from a user or is transmitted from another application
and provides distinct application-oriented data or control information. Inputs are often
used to update internal logical files (ILFs).

Number of external outputs (EOs)

Each external output is derived data within the application that provides information to
the user. In this context external output refers to reports, screens, error messages, etc.

Number of external inquiries (EQs)

An external inquiry is defined as an online input that results in the generation of some
immediate software response in the form of an online output (often retrieved from an
Internal Logical File).

Number of internal logical files (ILFs)

Each internal logical file is a logical grouping of data that resides within the
application’s boundary and is maintained via external inputs.

Number of external interface files (EIFs)

Each external interface file is a logical grouping of data that resides external to the
application but provides information that may be of use to the application.
 Information Count Simple Average Complex Total
Domain Value
External Inputs (EIs) 4 3*4 4 6 12

External Outputs (EOs) 1 4*1 5 7 4

External Inquiries (EQs) 2 3*2 4 6 6

Internal Logical Files (ILFs) 5 7*5 10 15 35

External Interface Files (EIFs) 0 5*0 7 10 0

Count total 57

The ∑f i where i = 1 to 14 are "Complexity Adjustment Values" based on responses

to the following questions:

1. Does the system require reliable backup and recovery? 5

2. Are specialized data communications required to transfer information to or 4
from the application?

3. Are there distributed processing functions? 5

4. Is performance critical? 4
5. Will the system run in an existing, heavily utilized operational 3
environment?

6. Does the system require online data entry? 5

7. Does the online data entry require the input transaction to be built over 1
multiple screens or operations?

8. Are the ILFs updated online? 5

9. Are the inputs, outputs, files, or inquiries complex? 4
10. Is the internal processing complex? 4
11. Is the code designed to be reusable? 4
12. Are conversion and installation included in the design? 2
13. Is the system designed for multiple installations in different organizations? 5

14. Is the application designed to facilitate change and ease of use by the user? 4

TOTAL 55
Once these data have been collected, a complexity value is associated with each count.
Organizations that use function point methods develop criteria for determining whether
a particular entry is simple, average, or complex. To compute function points (FP), the
following relationship is used:

FP = Count Total * 0.65 + 0.01 * ∑fi

[ ]
Where count total is the sum of all FP entries obtained from table.

[
= 57 * 0.65 + 0.01*55 ]
= 57 * 1.20
= 68 (approx.)

4.2 Risk Estimation

Risk projection, also called risk estimation, attempts to rate each risk in two ways –
(1) The likelihood or probability that the risk is real and
(2) The consequences of the problems associated with the risk, should it occur.

The developer work along with other managers and technical staff to perform four risk
projection steps:
1. Establish a scale that reflects the perceived likelihood of a risk.
2. Delineate the consequences of the risk.
3. Estimate the impact of the risk on the project and the product.
4. Assess the overall accuracy of the risk projection so that there will be no
misunderstandings.

The intent of these steps is to consider risks in a manner that leads to prioritization. No
software team has the resources to address every possible risk with the same degree of
rigor. By prioritizing risks, you can allocate resources where they will have the most
impact.
Risk Table
A risk table provides with a simple technique for risk projection. You begin by listing
all risks (no matter how remote) in the first column of the table. Each risk is categorized
in the second column. The probability of occurrence of each risk is entered in the next
column of the table. Next, the impact of each risk is assessed. Once the first four
columns of the risk table have been completed, the table is sorted by probability and by
impact. High-probability, high-impact risks percolate to the top of the table, and low-
probability risks drop to the bottom.
All risks that lie above the cutoff line should be managed. The column labeled RMMM
contains a pointer into a risk mitigation, monitoring, and management plan or,
alternatively, a collection of risk information sheets developed for all risks that lie above
the cutoff.

Risks Category Probability Impact RMMM

Larger number
of users than PS 70 % 2 Improve infrastructure
planned and Resources

Customer will
change PS 70 % 2 Modify software with
requirements time.

Lack of training Train the staff with latest

DE 70 % 3
on tools tools.
Size estimate Be ready with extra
may be PS 60 % 2 space. Try to minimize
significantly low space used.
Delivery
deadline will be BU 60 % 2 Allocate more resources
tightened to complete the task.

Less reuse than Revise component to

PS 50 % 3 make them more
planned
reusable.
Technology will
not meet TE 40 % 1 Update the technology
expectations and use latest measures.
End-users resist Take user feedback and
BU 40 % 2
system update system.
Staff Train the staff with
ST 30 % 2
inexperienced experts.
Performance
will not meet BU 30 % 2 Minimize the overhead
expectations operations.

Funding will be Self-funding & find new

CU 30 % 4
lost investors.
Staff turnover Make the system more
ST 20 % 3
will be high automated.

Symbols used:
Impact values:
1 catastrophic
2 critical
3 marginal
4 negligible

Category :
PS Project Size Risk
BU Business Risk
CU Customer Characteristics Risk
TE Technology Risk
DE Development Environment Risk
ST Staff Size and Experience Risk
4.3 Timeline Chart
 5. TESTING

5.1 Verification and Validation

Criteria Verification Validation

Definition The process of evaluating work-
products of a development phase
to determine whether they meet
the specified requirements for that
phase.
The process of evaluating
software during or at the end of
the development process to
determine whether it satisfies
specified business requirements.

Objective To ensure that the product is To ensure that the product

being built according to the
requirements and design
specifications. In other words, to
ensure that work products meet
their specified requirements.
actually meets the user’s needs,
and that the specifications were
correct in the first place.

Question Are we building the Are we building

product right? the right product?

Evaluation Plans, Requirement Specs, Design The actual product/software.

Items Specs, Code, Test Cases

Activities  Reviews  Testing

 Walkthroughs
 Inspections
5.2 Testing Strategies
A test strategy is an outline that describes the testing approach of the software
development cycle. It is created to inform project managers, testers, and developers
about some key issues of the testing process. This includes the testing objective,
methods of testing new functions, total time and resources required for the project, and
the testing environment.
Test strategies describe how the product risks of the stakeholders are mitigated at the
test-level, which types of test are to be performed, and which entry and exit criteria
apply. They are created based on development design documents. System design
documents are primarily used and occasionally, conceptual design documents may be
referred to. Design documents describe the functionality of the software to be enabled
in the upcoming release. For every stage of development design, a corresponding test
strategy should be created to test the new feature sets.

Levels of Testing -
 Unit testing
 Integration testing
 Validation testing
o Focus is on software requirements
 System testing
o Focus is on system integration
 Alpha/Beta testing
o Focus is on customer usage
 Recovery testing
o forces the software to fail in a variety of ways and verifies that recovery
is properly performed
 Security testing
o verifies that protection mechanisms built into a system will, in fact,
protect it from improper penetration
 Stress testing
o executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
 Performance Testing
o test the run-time performance of software within the context of an
integrated system
5.3 Test Case Design
The design of tests can be as challenging as the initial design of the project itself. Testing
design tests that have the highest likelihood of finding the most errors with a minimum
amount of time and effort.
Any software product can be tested in any of the two ways:

1. Knowing the specific function that a product has been designed to perform, test
can be conducted that demonstrate each function is fully operational.
2. Knowing the internal working of a product. Test can be conducted to ensure that
the internal operation of product performs according to specification and all
internal components have been adequately exercised.

The first step is called the black box testing and the second white box testing.
Test cases are design to answer the following questions:
 How is functional validity tested?
 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input values?
 How are the boundaries of a data class isolated?
 What data rates and data volumes can the system tolerate?
 What effect will specific combinations of data have on system operation?

In this project since no coding has been done, we describe testing in brief.

Testing Objectives –
The main purpose of testing is to detect errors and error prone areas in a system. Testing
must be thorough and well-planned. A partially tested system is as bad as an untested
system. And the price of an untested and under-tested system is high.
Testing is a process of executing a program with the intent of finding an as yet
undiscovered error. A successful test is one that uncovers a yet undiscovered error. Our
objective is to design tests that systematically uncover different classes of errors and to
do so with a minimum amount of time and effort.
5.4 Black Box & White Box Testing

Black-box testing
It is a method of software testing that examines the functionality of an application
without peering into its internal structures or workings. This method of test can be
applied to virtually every level of software testing: unit, integration, system and
acceptance.

White-box testing
Also known as clear box testing, glass box testing, transparent box testing, and
structural testing, White Box Testing is a method of testing software that tests internal
structures or workings of an application, as opposed to its functionality (i.e. black-box
testing). In white-box testing an internal perspective of the system, as well as
programming skills, are used to design test cases.

Criteria Black Box Testing White Box Testing

Definition Black Box Testing is a
software testing method in
which the internal structure/
design/ implementation of the
item being tested is NOT
known to the tester
White Box Testing is a
software testing method in
which the internal structure/
design/ implementation of the
item being tested is known to
the tester.

Responsibility Generally, independent Generally, Software

Software Testers Developers

Programming Not Required Required

Knowledge
Implementation Not Required Required
Knowledge
Basis for Test Requirement Specifications Detail Design
Cases
5.5 Cyclomatic Complexity

Figure 5: Flow graph for "Book Ticket"

Cyclomatic complexity is a software metric that provides a quantitative measure of the
logical complexity of a program.
In figure, the Cyclomatic complexity can be computed by using the algorithm:
1. The number of closed regions in the flow graph + 1.
The above figure has 4 closed areas. So,
Cyclomatic complexity = 4+1 = 5

2. Cyclomatic complexity V(G), for a flow graph G is defined as

V(G) = E-N+2 , where E= no. of edges and N= No of nodes
For the figure given above, Edges = 12, Nodes= 9
V(G) = 12 – 9 + 2
V(G) = 5

3. Cyclomatic complexity V(G), for a Flow graph G, is define as

V(G)= P+1, where P is the number of predicate nodes
V(G) = 4+1
V(G) = 5

Therefore, The Cyclomatic Complexity for the Book Ticket Module is 5.

5.5.1 Independent Program Paths

An independent path is any path through the program that introduces atleast new set of
processing statements or a new condition. When stated in terms of a graph, an
independent bpath must move along atleast one edge that has not traversed before the
path is defined.
The set of independent paths flow graph illustrated in figure is:
Path 1: 1-2-3
Path 2: 1-2-4-9-3
Path 3: 1-2-4-5-6-7-9-3
Path 4: 1-2-4-5-6-8-9-3
Path 5: 1-2-4-5-6-8-9-4-5-6-7-9-3
CONCLUSION
BIBLIOGRAPHY