Professional Documents
Culture Documents
“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
2. REQUIREMENTS ENGINEERING
2.1 Feasibility Study
2.2 Requirement Elicitation
2.3 QFD
2.4 SRS
2.5 Requirements Validation
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
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.
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.
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.
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.
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).
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. 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.
Figure 2: ER diagram
3.2 Database Design
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
Attribute Description
Journey_Id (PK) Unique Journey Id
Source Source of the journey
Destination Destination of the Journey
Fare Fare of the Journey
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
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
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.
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.
Count total 57
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:
[
= 57 * 0.65 + 0.01*55 ]
= 57 * 1.20
= 68 (approx.)
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.
Larger number
of users than PS 70 % 2 Improve infrastructure
planned and Resources
Customer will
change PS 70 % 2 Modify software with
requirements time.
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
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.