SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
ONLINE FLIGHT TICKET MANAGEMENT
SYSTEM

TEAM MEMBERS REG NO

VENKATESH RA2011003020284

Aakash raj RA2011003020277

YASWANTH RA2011003020275
 EX NO: 1 Identify the software project, create
business case, arrive at a problem
DATE: statement

INTRODUCTION:
The project aims to design an Airline Reservation System
application that enables customers to search to book flights. Airline Reservations
Systems contain fare tariffs, passenger reservations, and ticket records. An airline
reservation system is a computerized system used to store and retrieve information and
conduct transactions related to air travel. The project is aimed at exposing the
relevance and importance of Airline Reservation Systems. It is projected towards
enhancing the relationship between customers and airline agencies through the use of
ARSs, thereby making it convenient for the customers to book flights when they
require such that they can utilize this software to make reservations.

1.1.PROBLEMS
:
Some of the problems being faced by the existing system include:

 The inability of passengers to select seat(s) for their chosen flight(s) from the
existing reservation system. This has ultimately resulted in time being wasted at
the check-in counter in assigning seats to passengers before they are allowed to
board the airplane.
 No option for passengers to print their boarding passes from the existing system.
 Non-notification of passengers in the event of flight cancellation or delays.
 No access to aircraft maintenance reports easing passenger fears as regards air
travel and its disasters.
 To study the existing Airline Reservation System challenges and to infer possible
solutions.
 To design an improved ARS that will solve the problems being faced by the
existing system which include; the inability of passengers to select seats for their
chosen flight, no option of passengers printing their boarding pass, nonnotification
of passengers of flight cancellations or delays, and lack of access to aircraft
maintenance reports.
 To implement the design and create an online ARS (airline reservation system )
that captures self-booking.
 PROPOSAL :
The purpose of this project is to implement or design a database for an airline
reservation system to check the flight details and book and cancel flight tickets. It
makes the process of booking and canceling flight tickets simple and easy for the
passengers.
1.2. BUSINESS CASE TEMPLATE

THE PROJECT:
 There is an increase in commuters in the digital world which is not possible for
manual flight reservations for everyone.
 The development of the Online Flight Reservation System helps commuters
book flight tickets through the internet.

THE HISTORY:
 The manual system includes problems like lack of time consumption, security
problems, and high cost.
 In a manual system, the transfer of information between branches is costly and
time-consuming.
 Records may be insufficient or lost due to manual error.

LIMITATIONS:
 The main limitation of the system is if any plane does not stop at a
particular destination that has not been included in the airline reservation
system.
 Passengers cannot transfer /her reservation from one flight to another flight
 Per ticket, only one other service is included at a time.

APPROACH:
 The development of the project requires basic knowledge of HTML, CSS
for the front end, and SQL for back-end programming
 From technical aspects, both the passenger and the airline authorized
employees to manage booking information.

BENEFITS:
 Easy to book tickets
 Time and energy consumption are reduced
 Provides every information about a flight
 24/7 customer support through chat and calls
 Send automated tickets to the customer by mail
 Easy Cancellation and Refund Policies
1.1.2 ARRIVE AT THE PROBLEM STATEMENTS

PROJECT PROBLEM STATEMENTS

• Inability of passengers to select their preferred seat(s) from the reservation
system
• Non-notification of passengers of flight cancellation
• Website loading issues.
• Online payment issues.
• Bank server issues.
• Refund sometimes takes a longer time
• after cancellation.

PROJECT DESCRIPTION
• Online Flight Reservation System is a web application that helps commuters
book flight tickets online.
• To book a ticket, the commuter must register himself by filling up the details.
• Once the user had registered himself, he has to log in to book the ticket.
• While booking the user must select the type of airline he will be traveling, and
he has to specify the place he is going to travel between. According to the type
of airline and place, the system will provide information regarding flight and
venue which are available on the date specified by the Commuter.
• Commuters can view the reservation after booking the ticket. Commuters will
be able to view the details related to their reservation.
• The System will provide notice related to the flight to the passengers.

PROBLEM CONSTRAINTS
• The Applicants require a computer to submit their information.
• Prior knowledge of computers and the English language should be known
• The main objective of the Airlines Reservation System is to manage the details
of Airlines Ticket, Flights, Customers, and Booking Counter Venders.
• It manages all the information about Airline’s Ticket, Bookings, Venders, and
Airlines Ticket.
• The project is built at the administrative end and thus only the ad minitractor is
guaranteed the access.
• The purpose of the project is to build an application program to reduce the
manual work of managing Airlines tickets, Flights, Bookings, and
Customers.
• It tracks all the details about the Customer, Booking Counter, and Venders.

SCHEDULE, RESOURCE, AND BUDGET CONSTRAINTS

• The Company follows a manual system for maintaining the Airline Reservation
System.
• Whenever any requisition comes to the Counter to issue a ticket firstly the
Ticket Capacity checked whether the required quantity of the ticket is present
or not.
• If the required tickets are present, then issue a ticket and update the reservation
Information and an entry is done to the Ticket Issue Register
• Airline reservation systems are systems that allow an airline to sell their seats
• It contains information on schedules and fares and a database of reservations
and tickets issued (if applicable)
 EX NO: 2 Stakeholder and user description,
identify the appropriate process models,
DATE:
comparative study with agile model
2.1.1 IDENTIFYING STAKEHOLDERS

 The system will have many stakeholders with potentially conflicting interests
 a stakeholder is anyone affected by the success or failure of the system
• primary - actually use system
• secondary - receive output or provide input
• tertiary - no direct involvement but affected by success or failure
• facilitating - involved in the development or deployment of the system

 designers need to meet as many stakeholder needs as possible.

• usually in conflict so have to prioritize
• often priority decreases as move down categories e.g. primary
most important
• not always e.g. life support machine
• Example: Classifying stakeholders – an airline booking system

Our Airline Reservation System plan is introducing a new booking system for
use by associated travel agents to sell flights directly to the public. If this plan is
successful, it will be implemented in the real world/life. It's just virtual thinking
or an imagination to make our project better.

2.1.2 Types of Stackholders:

Primary stakeholders: travel agency staff, airline booking staff

Secondary stakeholders: customers, airline management

Tertiary stakeholders: competitors, civil aviation authorities, customers’
traveling companions, airline shareholders
Facilitating stakeholders: design team, IT department staff

Six stage process - focus on stakeholders:

• Describe the organizational context, including primary goals,
physical characteristics, and political and economic background.

• Identify and describe stakeholders including personal issues, role in

the organization, and job.

• Identify and describe work groups whether formally constituted or not.

• Identify and describe task - object pairs i.e. tasks to be performed
and objects used.

• Identify stakeholder needs: Stages 2–4 described in terms of both current

and proposed system - stakeholder needs are identified from the differences
between the two.

• Consolidate and check stakeholder requirements against earlier criteria.

2.1.2 USER STORY:

1] APPLICANTS FOR THE AIRLINE

RESERVATION SYSTEM(ARS):
An Applicant here is the individual who applies for the reservation of seats in the
flight.
2] AIRLINE RESERVATION INFORMATION PROVIDERS:
Applicants can ask any kinds of doubt related to seat booking from the Airline
Reservation information providers.

3] FINANCE DEPARTMENT:
The finance department is responsible for management of the cash flow when
the processing fee is applied while booking seats through online.
 2.1.3 IDENTIFYING THE PROCESS MODULES

This project contains 5 modules

 LOG IN:
In this module, the customer must create an account by entering their
username/Email and password if he doesn’t create an account the
customer cannot enter int to the portal

 SEARCH DETAILS
After logging in, Enter the arrival and destination place, date, class And
no of passengers. Flight details will be shown according to the details
given by the passenger. Customer can select their suitable flight by fare,
time, and comfortability.

 CUSTOMER DETAILS
After the selection of flight, customer must fill in their customer details
such as name, mobile number, email, and address. If they need, they can
select insurance, charity, etc

 PAYMENT METHOD
After filling in customer details, check your passengers and flight details
provided and move to the payment method. Check the fare details in the
bill and choose the payment method to pay the fare

 BOOKING DETAILS
After paying the fare, the receipt will be generated to the customer’s
mobile no through message/mail.
2.1.4 ARRIVE AT THE PROBLEM STATEMENT

PROBLEM STATEMENTS
• Inability of passengers to select their preferred seats from the reservation
system.
• Refund sometimes takes a long time after cancellation.
• Non-notification of passengers of flight cancellation
• Website loading issues, Online payment issues, Bank server issues.
 • It contains information on schedules and fares and a database of
reservations and tickets issued (if applicable).

2.1.5 COMPARISON BETWEEN AGILE AND WATERFALL

MODEL

• Agile model is an incremental delivery process whereas, the Waterfall

model is highly structured and systematic.
• In the Agile model progress is measured in terms of the developed and
delivered functionalities
• In the Waterfall model progress is generally measured in terms of the
 EX NO: 3 Identify the Requirements, System
Requirements, Functional
DATE:
Requirements, Non-functional
Requirements
number of completed and reviewed artifacts
• Waterfall is a linear system of working that requires the team to complete
each project phase before moving on to the next.
• Agile encourages the team to work
simultaneously on different phases of the
project.
3.1.1 REQUIREMENTS
•
 Agile is an incremental and
iterative approach
• Waterfall is a linear and sequential approach.
Project requirements are the needs for the completion of the project
Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or
unexpected from the client’s point of view.
 3.1.2 FUNCTIONAL REQUIREMENTS
Functional requirements are product features or functions that developers must
implement to enable users to accomplish their tasks. In our project, the
functional requirement is Log In After the login module we explain the details
about

 Analysis
 Design
 Implementation
 Maintenance

3.1.3 NON - FUNCTIONAL REQUIREMENTS

 The processing speed of the system must be 2.5Ghz-5.00 GHz
 It must have storage of at least 64 GB and RAM of 2 GB
 Transferring data speed 50 Mbps in time
 It is User Satisfaction, high Response Time, Error Handling, Portable and
Safety, and Robustness

3.1.4 HARDWARE REQUIREMENTS

 Processor: Intel Core i7 8750H
 Hard drive: 256 GB
 RAM: 4GB

3.1.5 SOFTWARE REQUIREMENTS

 Operating system: Windows 10
 Front-end: HTML, CSS and Javascript
 Back-end: SQL
 EX NO: 4 Prepare project plan based on scope, find
job roles and responsibilities, calculate
DATE:
project effort based on resources

4.1.1 PROJECT PLAN

PROJECT NAME:
“ONLINE FLIGHT TICKET MANAGEMENT SYSTEM”

PROJECT MEMBERS:
Our Project consists of 3 members:

1. ARULAN M - RA2011003020319
2. D L VAISHNAV REDDY – RA2011003020329
3. M S R YOGESH – RA2011003020326

MODULES:
• Login
• Search details
• Customer details
• Payments
• Booking details

SCHEDULING:

TASK START DATE END DATE

Business case 14/3/2022 20/03/2021
development

Identifying 21/03/2022 27/03/2022

Stakeholders, Process
Modules and
required
Modules
Identifying 28/03/2022 10/04/2022
requirements

Setting cost estimates 11/04/2022 24/04/2022

and budget

UML Diagrams 26/04/2022 29/05/2022

Coding 30/05/2022 11/06/2022

Final Revisions 12/06/2022 13/06/2022

4.1.2 IDENTIFYING JOB ROLES AND RESPONSIBILITIES

MEMBERS ROLES AND RESPONSIBILITIES

 ARULAN M • TEAM LEADER: Responsibility
(RA2011003020319) of coordination of the team, checking for
errors, updating for the current status of
the project, guiding the team.
• DEVELOPER: Responsibility of
coding, compiling and debugging of the
modules.
• SOFTWARE ARCHITECT:
Design of UML Diagrams and other
blueprint.
D L VAISHNAV REDDY • WEB DEVELOPER:
(RA2011003020329) Responsibility
of designing the website and interfacing
with the server.
• DEVELOPER: Responsibility of
coding compiling and debugging of the
modules.
• MANUAL TESTER:
Responsibility
of testing the project at a smaller level
and reporting the errors.
MSR • WEB DEVELOPER:
YOGESH Responsibility
(RA2011003020326) of designing the website and interfacing
with the website.
• TESTER: Responsibility of
testing the project at a vast level
and variety of ways.
• DESIGNER: Identifying areas for
modification in existing programs and
developing the modification.
6.1.2 COCOMO MODEL
COCOMO model refers to a group of models and is used to
estimate the development efforts which are involved in a project. COCOMO is
based upon the estimation of lines of code in a system and the time. COCOMO
has also considered the aspects like project attributes, hardware, assessment of
produce, etc. This provides transparency to the model which allows software
managers to understand why the model gives the estimates it does. Moreover,
the baseline COCOMO originally underlies a waterfall model lifecycle. The
developments are done on multiple COCOMO models in parallel for cost
estimates that cover a broader scope that exceeds the boundaries of traditional
software development are discussed. The COCOMO model has basically two
parameters like effort calculation and development time to define the quality of
any software product:
Schedule: Simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put in. It is measured in the
units of time such as weeks, and months.

Types of COCOMO Model

Software projects under COCOMO model strategies are classified into 3

categories, organic, semi-detached, and embedded.

Organic:

• Project is small and simple.

• Project team is small with prior experience.
• The problem is well understood and has been solved in the past.
• Requirements of projects are not rigid, such a mode example is payroll
processing system.

Semi-Detached Mode:

 Project has complexity.

  Project team requires more experience,better guidance and creativity.
 The project has an intermediate size and has mixed rigid requirements
such a mode example is a transaction processing system which has fixed
requirements.
 It also includes the elements of organic mode and embedded mode.
 Few such projects are- Database Management System(DBMS), new
unknown operating system, difficult inventory management system.

Embedded Mode:

• A software project has fixed requirements of resources .

• Product is developed within very tight constraints.
• A software project requiring the highest level of complexity, creativity,
and experience requirement fall under this category.
• Such mode software requires a larger team size than the other two models

Effort (E) = ab(KLOC)bb

Deployment (D) = cb(E)b

Productivity (P) = E/D

Where, ab, bb, cb, db are called as coefficient

PROJECT Ab Bb cb db
Organic 2.4 1.05 2.5 0.38
Mode
Semidetached 3.0 1.12 2.5 0.35
Mode
Embedded 3.6 1.20 2.5 0.32
Mode

EX NO: 5 Prepare the work breakdown structure

based on timelines, Risk identification
DATE:
plan
5.1. WORK BREAKDOWN STRUCTURE: -
A work breakdown structure is a tool that helps you organize your project by
hierarchy. With a WBS, you break down deliverables into sub-deliverables to
visualize projects and outline key dependencies. Every work breakdown
structure is made up of a few parts:

• A project baseline or scope statement, which includes a project plan

description, and name
• Project stakeholders
• An organized project schedule
• Project deliverables and supporting subtasks
Project managers use work breakdown structures to help teams to break down
complex project scopes visualize projects and dependency-related deliverables
and give team members a visual project overview as opposed to a list of to-
dos.
The levels of work breakdown structure are:
Level 1: The parent task
Level 2: Dependencies and tasks
Level 3: Subtasks
Continuing the above example, here are the level three tasks you could use for a
new site design:

• Choose brand colors

• Build a brand mood board
• Assign UX designers
• Build a mockup design
• Review and approve mockups
• Schedule a brand photoshoot
• Resize and edit pictures

The work needed to complete the project objective is becoming much clear.
You may even choose to add additional levels to your WBS, depending on how
specific you want your visual to be.
5.2. RISK MANAGEMENT: -

DESCRIPTION:

"Tomorrow problems are today's risk." Hence, a clear definition of

a "risk" is a problem that could cause some loss or threaten the progress of the
project, but which has not happened yet.

These potential issues might harm the cost, schedule, or technical success of the
project and the quality of our software device, or project team morale.

Risk Management is the system of identifying addressing and eliminating these

problems before they can damage the project.

RISKS TO BE HANDLED:

There are several types of risks that occur frequently,

regardless of the specifics of the project. These common types of risk include:

• Cost: The risk of events that impact the budget, especially those that
cause the project to be completed over budget. Errors in cost estimation
commonly generate risk in addition to external factors.

• Schedule: The risk of unplanned scheduling conflicts, such as events that

cause the project to be delayed. Scope creep is a common reason for
scheduling issues and project delays.

• Performance: The risk of events that cause the project to produce results
that are inconsistent with the project specifications.

To protect a project from unplanned risk, project managers typically follow an

ongoing risk management process that helps them identify, understand, and
respond to threats and opportunities. Before beginning this process, however,
it’s important to fully understand your organization’s practices and how you will
conduct your risk work for that project. This plan then will drive the following
steps:

• Identify the risks that could potentially impact your project.

• Assign ownership of each identified risk to a team member who will be

charged with overseeing that threat or opportunity. Although some project
managers prefer to assign ownership after the risks have been analyzed
and prioritized, taking this step early can be beneficial. “Many times I
assign
 an owner to the risk very early on because I want that person to drive the
analysis of the risk,” Emerson notes.
• Analyze each risk to fully understand the driving factors involved and
potential impacts. Be sure to consider the breadth and depth of each threat
at this stage to evaluate the severity of each risk in the context of the
overall project.

• Prioritize project risks according to urgency and the severity of the impact
they could cause.

• Respond to your identified risks by your risk management approach,

either by taking steps to prevent the risk event from occurring or to
minimize the impact if it does occur. This step should include building the
response as well as taking action.

• Monitor your risk management strategy and make changes as needed.

Although there are clear steps in the risk management process, this should
ideally be an ongoing effort. After all, the nature of risk is inherently
unpredictable, and project managers need to have the agility and discipline to
continuously adapt to changes throughout a given project.

MANAGING RISKS:

1. Create a risk management plan.

2. Keep your risk register up to date.

3. Understand the risk event.

4. Be proactive instead of reactive.

5. Develop your project management skills.

6. Maintaining the server.

7. Using security protection to protect from bot attack. (i.e.Captcha)

8. Bugs must be removed and code must pass many test cases.
 EX NO: 6 Design a System Architecture, Use Case
DATE:
Diagram, ER Diagram, DFD Diagram,
Class Diagram, Collaboration Diagram

6.1. SYSTEM ARCHITECTURE: -

After gathering the entire requirements specific to the software project usually
we need to think about different solution strategies for the project and analyze
their benefits in cost, time, and resources required to develop them.
The estimated cost, effort, and duration for a software project, and then select
one solution approach which will be found suitable to fulfill the organizational
goal.
The important project parameters that are estimated include:

 Productivity
 Effort
 Size
 Requirement Stability
 Quality
 efficiency
 cost
6.1.1 FUNCTION POINT ANALYSIS

Function point analysis is the process of sizing software based on the number of
business functions an application must accomplish. It eliminates the need to
tediously go through each line of code to determine if an application meets
business needs and has the required quality.

6.1.2 SYSTEM ARCHITECTURE

A system architecture is a conceptual model that defines the structure, behavior,
and views of a system. An architecture description is a formal description and
representation of a system, organized in a way that supports reasoning about the
structures and behaviors of the system.
A system architecture can consist of system components and the sub-systems
developed, that will work together to implement the overall system
architectural diagram
6.2 USE CASE DESCRIPTION:
Use-case diagrams describe the high-level functions and scope of a system.
These diagrams also identify the interactions between the system and its actors.
The use cases and actors in use-case diagrams describe what the system does
and how the actors use it, but not how the system operates internally.

6.2.1. USE CASE SYMBOL AND NOTATION:

The notation for a use case diagram is pretty straightforward and doesn't involve
as many types of symbols as other UML diagrams.
• Use cases: Horizontally shaped ovals that represent the different uses
that a user might have.
• Actors: Stick figures that represent the people actually employing the use
cases.
* Primary actor: Initiates the use of the system. It should be
placed on the left side of the system.
* Secondary actor: It is more reactionary and should be placed
on the right side of the system.
• Associations: A line between actors and use cases. In complex diagrams,
it is important to know which actors are associated with which use cases.
• System boundary boxes: A box that sets a system scope to use cases. All
use cases outside the box would be considered outside the scope of that
system. For example, Psycho Killer is outside the scope of occupations in
the chainsaw example found below.
• Packages: A UML shape that allows you to put different elements into
groups. Just as with component diagrams, these groupings are represented
as file folders.

6.2.2 USE CASE DIAGRAM:

6.3 ER MODELLING DESCRIPTION

ENTITY RELATIONSHIP

DIAGRAM:

• An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how

“entities” such as people, objects or concepts relate to each other within a
system. •ER Diagrams are most often used to design or debug relational
databases in the fields of software engineering, business information systems,
education and research.
USES OF ER DIAGRAM:

• Database design
• Database troubleshooting
• Business information systems
• Business process re-engineering (BPR)
• Education
• Research

COMPONENTS OF ER DIAGRAM:

ER Diagrams are composed of entities, relationships (Cardinality) and attributes.

They also depict cardinality, which defines relationships in terms of numbers.

1. ENTITY: A definable thing—such as a person, object, concept or event—that

can have data stored in it.
2. ATTRIBUTES: A property or characteristic of an entity.
3. KEYS:
PRIMARY KEY(PK): It is unique, cannot be repeated and never null.
FOREIGN KEY(FK): It is not unique and can be repeated.
4. CARDINALITY:
Defines the numerical attributes of the relationship between two entities.
6.3.2 ER DIAGRAM

in this diagram flight,flight details,card details,ticket info and passanger profile

are the entitie

6.4 DATA FLOW DIAGRAM:

A data-flow diagram is a way of representing a flow of data through a process
or a system (usually an information system). The DFD also provides information
about the outputs and inputs of each entity and the process itself. A data-flow
diagram has no control flow — there are no decision rules and no loops. Specific
operations based on the data can be represented by a flowchart.

For each data flow, at least one of the endpoints (source and / or destination)
must exist in a process. The refined representation of a process can be done in
another data-flow diagram, which subdivides this process into subprocesses.The
data-flow diagram is a tool that is part of structured analysis and data modeling.
When using UML, the activity diagram typically takes over the role of the data-
flow diagram. A special form of data-flow plan is a site-oriented data-flow plan.

COMPONENTS OF DATA FLOW:

DFD consists of processes, flows, warehouses, and terminators. There are
several ways to view these DFD components.
Process
The process (function, transformation) is part of a system that transforms inputs
to outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle
with rounded corners (according to the type of notation). The process is named
in one word, a short sentence, or a phrase that is clearly to express its essence.
Data flow
Data flow (flow, dataflow) shows the transfer of information (sometimes also
material) from one part of the system to another. The symbol of the flow is the
arrow. The flow should have a name that determines what information (or what
material) is being moved. Exceptions are flows where it is clear what
information is transferred through the entities that are linked to these flows.
Material shifts are modeled in systems that are not merely informative. Flow
should only transmit one type of information (material). The arrow shows the
flow direction (it can also be bi-directional if the information to/from the entity
is logically dependent - e.g. question and answer). Flows link processes,
warehouses and terminators.
Warehouse
The warehouse (datastore, data store, file, database) is used to store data for
later use. The symbol of the store is two horizontal lines, the other way of view
is shown in the DFD Notation. The name of the warehouse is a plural noun (e.g.
orders) - it derives from the input and output streams of the warehouse. The
warehouse does not have to be just a data file but can also be, for example, a
folder with documents, a filing cabinet, or a set of optical discs. Therefore,
viewing the warehouse in a DFD is independent of implementation. The flow
from the warehouse usually represents reading of the data stored in the
warehouse, and the flow to the warehouse usually expresses data entry or
updating (sometimes also deleting data). The warehouse is represented by two
parallel lines between which the memory name is located (it can be modeled as
a UML buffer node).
Terminator
The Terminator is an external entity that communicates with the system and
stands outside of the system. It can be, for example, various organizations
,groups of people (e.g. customers), authorities (e.g. a tax office) or a department
(e.g. a human-resources department) of the same organization, which does not
belong to the model system. The terminator may be another system with which
the modeled system communicates.

Data flow diagram

6.5 MODELING OF CLASS DIAGRAM
6.5.1 CLASS DIAGRAM DESCRIPTION:

Class diagrams are one of the most useful types of diagrams in UML as they
clearly map out the structure of a particular system by modeling its classes,
attributes, operations, and relationships between objects.
COMPONENTS OF CLASS DIAGRAM:
The standard class diagram is composed of three sections:

• UPPER SECTION: Contains the name of the class. This section is always
required, whether you are talking about the classifier or an object.

• MIDDLE SECTION: Contains the attributes of the class. Use this section to
describe the qualities of the class. This is only required when describing a
specific instance of a class.

• BOTTOM SECTION: Includes class operations (methods). Displayed in list

format, each operation takes up its own line. The operations describe how a
class interacts with data. 22/03/2021
MEMBER ACCESS SPECIFIERS: All classes have different access levels
depending on the access modifier (visibility). Here are the access levels with
their corresponding symbols.

• Public (+)
• Private (-)
• Protected (#)
• Package (~)
6.5.2 CLASS DIAGRAM
6.6 MODELING OF COLLABRORATION DIAGRAM 6.6.1
COMMUNICATION DIAGRAM DESCRIPTION
1] OBJECTS:

Objects can be classed as either a supplier or a client. Suppliers call the function
that supplies the message. Clients send the message to the supplier, who receives
it. It is represented by rounded rectangle.

2] ACTORS:

Stick figure represents the actor. It is the instances that invokes the interaction.
Each actor has a specific name and a role.
3] LINKS:

A straight line connecting two objects indicates a relationship between them.

The two objects are able to send messages to each other.

4] MESSAGES:

Typically, messages will have a number and description next to them. The
number determines the order in which messages should be read.

NOTE:

Communication diagrams shows much more than just a sequence of

events. Using a communication diagram to model your system allows you to
breakdown a series of complex interactions in said system.
6.6.2 COMMUNICATION DIAGRAM

State and Sequence Diagram,

EX NO: 7 Deployment Diagram, Sample
DATE: FrontendDesign

7.1 STATECHART DIAGRAM DESCRIPTION

7.1.1. STATECHART DIAGRAM:

A state diagram, sometimes known as a state machine diagram, is a type of

behavioral diagram in the Unified Modeling Language (UML) that shows the
transitions between various objects.

COMPONENTS OF STATECHART DIAGRAM:

We can include many different shapes in a state diagram, particularly if we
choose to combine it with another diagram. This list summarizes the most
common shapes we may encounter.

1] START STATE:

It is denoted by black filled circle and represents the beginning of the state.

2] STATE:

We use a rounded rectangle to represent a state. A state represents the conditions

or circumstances of an object of a class at an instant of time. 15/03/2021

3] TRANSITION:

We use a solid arrow to represent the transition or change of control from one
state to another. The arrow is labelled with the event which causes the change in
state.

4] FORK:

We use a rounded solid rectangular bar to represent a Fork notation with

incoming arrow from the parent state and outgoing arrows towards the newly
created states. We use the fork notation to represent a state splitting into two or
more concurrent states.

5] JOIN:

We use a rounded solid rectangular bar to represent a Join notation with

incoming arrows from the joining states and outgoing arrow towards the
common goal state. We use the join notation when two or more states
concurrently converge into one on the occurrence of an event or events.

6] DECISION:

We use a diamond symbol to apply a condition wherever necessary.

7] COMPOSITE STATE:

We use a rounded rectangle to represent a composite state also. We represent a

state with internal activities using a composite state.
8] FINAL STATE:

We use a filled circle within a circle notation to represent the final state in a state
machine diagram.

7.1.2 STARTCHART DIAGRAM

7.2. SEQUENCE DIAGRAM DESCRIPTION

SEQUENCE DIAGRAM: Sequence diagram are a popular dynamic modeling
solution in UML because they specifically focus on lifelines, or the processes
and objects that live simultaneously, and the messages exchanged between them
to perform a function before the lifeline ends.

COMPONENTS IN SEQUENCE DIAGRAM:

1] ACTOR: Stick figure represents the actor. Shows entities that interact the
external objects of the system.

2] OBJECTS: Rectangular boxes represent the object, demonstrates how an

object will behave in the context of the system.
3] ACTIVATION BOXES: Represents the time needed for an object to
complete a task. The longer the task will take, the longer the activation box
becomes.

4] MESSAGE SYMBOLS: We use the following arrows and message

symbols to show how information is transmitted between objects. These
symbols may reflect the start and execution of an operation or the sending and
reception of a signal.

• SYNCHRONOUS MESSAGE: Represented by a solid line with a solid

arrowhead. This symbol is used when a sender must wait for a response to a
message before it continues. The diagram should show both the call and the
reply.

• ASYNCHRONOUS MESSAGE: Represented by a solid line with a lined

arrowhead. Asynchronous messages don't require a response before the sender
continues. Only the call should be included in the diagram.

• REPLY MESSAGE: Represented by a dashed line with a lined

arrowhead, these messages are replies to calls.

• DELETE MESSAGE: Represented by a solid line with a solid arrowhead,

followed by an X. This message destroys an object.
7.2.2 SEQUENCE DIAGRAM
7.3 DEPLOYMENT DIAGRAM: -
7.3.1. DEPLOYMENT DIAGRAM DESCRIPTION:
A UML deployment diagram is a diagram that shows the configuration of run
time processing nodes and the components that live on them. Deployment
diagrams is a kind of structure diagram used in modeling the physical aspects of
an object-oriented system. They are often be used to model the static deployment
view of a system (topology of the hardware)
7.4. SAMPLE FRONTEND DESIGN: -
The figures 7.4.1shows the login page of customer and 7.4.2 show the
registration for the new customers and the change their account password for
existing customers. And possesses a button that permits the customer to enter
into search details module.
 Figure 7.4.1 Login page

Figure 7.4.2 (a)Signup page Figure 7.4.2 (b)Change passwword

EX NO: 8 Module Description and Module
Implementation Using Agile
DATE:

8.1. MODULE DESCRIPTION: -

Features of Student Result Management System:

project contains 5 modules

 Log in: permits the user to enter into the website

 search details: to find available flights

 customer details: to enter the passenger details

 payment method: to pay the fare for the ticket

 booking details: gives a e-receipt of ticket

FEATURES OF AIRLINE RESEVATION SYSTEM

 Online Flight Reservation System is a web application that

helps commuters book flight tickets online.
 To book a ticket, the commuter must register himself by filling up
the details.
 Once the user had registered himself, he has to log in to book the ticket.
 While booking the user must select the type of airline he will be traveling,
and he has to specify the place he is going to travel between. According to
the type of airline and place, the system will provide information regarding
flight and venue which are available on the date specified by the
Commuter.
 Commuters can view the reservation after booking the ticket. Commuters
will be able to view the details related to their reservation.
 The System will provide notice related to the flight to the passengers.
8.2. MODULE IMPLEMENTATION USING AGILE: -

The fig.8.2.1shows the available flight to book tickets for the customers usergiven
by entering flight details such as destion,arrival,date and name

Figure 8.2 Search Flight

 Ex no:09 Module Implementation (Phase 1) Scrum Master
Date: to Induce New requirements in Agile Development,
Scrum Master to Induce New Issues in Agile
Development, Code development

The fig.9.1 show the page to login where an existing customer can signin to
enter into search module
If the user is not an existing customer he must signup by clicking the signup
link.

Figure 9.2 Figure9.3

If the existing user forgots his password then he will change his password by
clicking forgot password link which is present below sigin page.In figure 9.3 the
password is generated to the registered email id given during sigup

Fig:9.4 Search flight

After login the user is moved to the search details where the users can enter into
the arrival,departure,flight name and date to find the available fights

After selecting suitable flight click the blue button for further process
 Ex no:10 Module Implementation (Phase 2) Scrum Master
Date: to Induce New requirements in Agile Development,
Scrum Master to Induce New Issues in Agile
Development, Code development

And then it moves booking portal where it confirms the flight details ,fare ,time
other details of the flight with the user by displaying the details

Fig:10.1.1 Booking portal

After confirmation of details then user must enter the details such as no of seats
and type of class(like economy,business) and click submit

Fig:10.1.2
After clicking submit button .the user need to fill the passenger details such as
passenger name and gender and click proceed to pay button for payment
process
 Ex no:11 Module Implementation (Phase 3) Scrum Master
Date: to Induce New requirements in Agile Development,
Scrum Master to Induce New Issues in Agile
Development, Code development

11.1. MODULE IMPLEMENTATION (PHASE 3): -

Then in payment process user must choose the suitable payment method to pay
through online by clicking any one of the payment button and then click proceed
button .
 Fig:11.1 Fig 11.2

Then a suitable gateway page is opened then pay the amount by entering the
users payment details such as card no,name,ccv and expiry date then click the
pay button to pay
 Fig :11.3
After the payment process the e-reciept is generated for the user and the user can
print the ticket by clicking the Here word (anchor link )

Fig:11.4

11.2. CODE DEVELOPMENT

The Airline Reservation System is developed using PHP, MYSQL, HTML,
CSS, JAVASCRIPT. Functional decomposition of the system and its key
modules are provided to explain the major functionalities proffered by the
system. Also, use case diagram is presented to show the different categories of
the system users and the various functionalities associated the different system
user
 EX NO:12 Master Test Plan ,Test Case Design
DATE: (Phase 1)

12.1. MASTER TEST PLAN:

TESTING OBJECTIVE: FOCUSING ON
PERFORMANCE
ISSUE

Login system, Registration

Test Items system, Search and customer
details system, Payment System

Features to be tested Login verification, search details,

Customer details, Payment
Feature
 Database Connectivity,
Features not to be tested Payment verifier,
Two way pinging tool

Approach Method – Manual Testing

A PC with 8 GB RAM,
Required Hardware/Software Internet Connectivity

Instability of the product

Risks

Tester: M.Arulan
Testers & Schedule Scheduling Information :
25th April 2022,
3:00 PM

12.2.TEST CASE DESIGN

Software testing can be stated as the process of verifying and validating
whether a software or application is bug-free, meets the technical requirements
as guided by its design and development, and meets the user requirements
effectively and efficiently by handling all the exceptional and boundary cases.
The process of software testing aims not only at finding faults in the existing
software but also at finding measures to improve the software in terms of
efficiency, accuracy, and usability. It mainly aims at measuring the specification,
functionality, and performance of a software program or application.
Software testing can be divided into two steps:
1. Verification: it refers to the set of tasks that ensure that the software
correctly implements a specific function.
2. Validation: it refers to a different set of tasks that ensure that the
software that has been built is traceable to customer requirements.
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”

16.1.2 TESTING FRAMEWORKS

MODULE BASED TESTING FRAMEWORK:

Abstraction is the concept on which this framework is built. Based on the

modules, independent test scripts are developed to test the software.
Specifically, an abstraction layer is built for the components to be hidden from
the application under test. This sort of abstraction concept ensures that
changes made to the other part of the application does not affect the underlying
components.

KEYWORD DRIVEN TESTING FRAMEWORK:

Keyword Driven Framework is a functional automation testing

framework that divides test cases into four different parts in order to separate
coding from test cases and test steps for better automation.
Keyword driven testing framework divides the test cases as test steps,
objects of test steps, actions on test steps and data for test objects for better
understanding.

Keyword Driven Testing is a scripting technique that uses data files to

contain the keywords related to the application being tested.
These keywords describe the set of actions that is required to perform a
specific step.
A keyword-driven test consists of high and low-level keywords, including
the keyword arguments, which is composed to describe the action of a test case.

It is also called table-driven testing or action word based testing.

In Keyword Driven Testing, you first identify a set of keywords and then
associate an action (or function) related to these keywords. Here, every testing
action like opening or closing of browser, mouse click, keystrokes, etc. is
described by a keyword such as openbrowser, click, Typtext and so on. Keyword
based testing can be done in both ways, manually as well as automated. But
usually, it is used with automated testing.The objective behind automating
Keyword based testing is

• It helps to reduce maintenance cost

• Avoids duplicated specifications
• Greater reuse of function scripting
• Better testing support and portability
• Achieve more testing with less or same effort
EX NO:13 MANUAL TESTING:
Date:

13.1 MANUAL TESTING:

TEST INPUT TEST OUTPUT/RESULT

AREA DESCRIPTION

Login module User name Permits the user to Tested

and enter into the website
password
Search module To Fill Allows the user to tested
flight search about the
details available flight

To fill Stores the customer tested

customer customer detail and Checks the
Module details available seats

Payment Click Checks whether the tested

Module validate payment feature is
and pay functioning and
option secure
 EX NO: User Manual, Analysis of Costing, Effort and
14 DATE: Resources

14.1. USER MANUAL: -

14.1.1 Introduction:

The "AIRLINE RESERVATION SYSTEM" application is a user interface to

access their account from a mobile device to view and book their ticket etc. This
document will provide instructions for using the application.

14.1.2. Getting Started:

Download and install the "Examination and Result Management System"

14.1.2 a. Quick Start: users

Step 1: Tap the browser and type"Online Airline Reservation" in your browser
and click the site The Login screen will be brought up.
Step 2: user need to Log In to use the site by providing their username and
password.
Step 3: Once you are logged in, your profile will be opened.

Step 4: Now, a user can book their ticket by giving essential flight details

Step 5: then book the available flight and give the passenger details
Step 6: then pay the fare in the payment method and the e-reciept is generated

14.1.2b. System Requirements:

• Smartphone with Android versions 5.0 and above.

• Internet connection for site to function.

14.1.3. Troubleshooting:
Missing or Incorrect Password or E-Mail. A message will be displayed in the
event Try again with proper credentials to access

14.2. ANALYSIS OF COSTING, EFFORT AND RESOURCES: -

Development of the project:

RESOURCE REQUIREMENT COST

Computer with core i5 6th gen Rs.40000/-

processor, at least 4Gb of RAM,
running on windows 7,8,10
Code Open source

Printing Rs.450/-

Server-End:
RESOURCE REQUIREMENT COST
 MY SQL Enterprise Edition Rs.15000/-

UPS 25000/-

Other cost:
EMPLOYEE SALARY --

Maintenance Cost Rs.2000/- per month