AIRLINE MANAGEMENT SYSTEM - Projects Org



Table of Contents

DECLARATION OF THE STUDENT

CERTIFICATE ISSUED BY THE SUPERVISOR

ACKNOWLEDGEMENT

CONTENTS

List of Tables (Annexture-III)

List of Figures (Annexture-IV)

List of Abbreviations (Annexture-V)

1. Introduction…………………………………………………………………...1-4

1.1 About Project……………………………………………………………..1

1.2 Objectives………………………………………………………………....2

1.3 Purpose……………………………………………………………………2

1.4 Scope of the project………………………………………………………3

1.5 Project Overview…………………………………………………………4

2. Problem Selection…………………………………………………………….5-7

2.1 Existing System…………………………………………………………..5

2.2 Proposed System………………………………………………………….7

3 Project Monitoring System …………………………………………………..8

3.1 Module Description………………………………………………………8

4 System Study …………………………………………………………………9-11

4.1 Feasibility Study………………………………………………………….9

4.1.1 Operational Feasibility…………………………………………10

4.1.2 Technical Feasibility…………………………………………...10

4.1.3 Behaviour Feasibility…………………………………………..11

5 System Analysis ……………………………………………………………..12-35

5.1 SDLC…………………………………………………………………….16

5.2 USE CASE DIAGRAM…………………………………………………19

5.2 Data Flow Diagram………………………………………………………20

5.3.1 0 Level DFD…………………………………………………..22

5.3.2 1ST Level DFD……………………………………………………23

5.3.1 2ND Level DFD…………………………………………………..24

5.4 ERD……………………………………………………………………...26

5.5 Flow Chart……………………………………………………………….28

6 System Design ……………………………………………………………….36-43

6.1 Design Methodologies……………………………………………………38

6.2 Structured Design ………………………………………………………..39

6.3 Module Coupling………………………………………………………...40

6.4 Module Cohesion………………………………………………………...41

6.5 Strategy of design………………………………………………………...42

7 System Testing and Implementation…………………………………………44-48

7.1 Levels of Testing…………………………………………………………44

7.1.1 Unit Testing or Module Testing………………………………..44

7.1.2 Integration Testing……………………………………………...44

7.2 Types of Testing …………………………………………………………46

7.2.1 Black Box Testing………………………………………………46

7.2.2 White Box Testing……………………………………………...46

7.2.3 Acceptance Testing……………………………………………..46

7.2.4 Alpha Testing…………………………………………………...47

7.2.5 Beta Testing…………………………………………………….47

8 Documentation………………………………………………………………..49-81

8.1 Coding…………………………………………………………………….49

8.2 Screen shots……………………………………………………................77

9 Conclusion……………………………………………………………………82

10 Scope of the project…………………………………………………………..83

Bibliography………………………………………………………………….84

Appendices……………………………………………………………………85-92

ANNEXTURE-III

LIST OF TABLES

|S.no. |Table No. |Description of Tables |Page No. |

|1 |1.1 |S\W requirements table | 92 |

|2 |2.1 |H\W requirements table | 92 |

1. INTRODUCTION

This project on Airline Management System is the automation of registration process of airline system. The system is able to provide much information like passenger’s information, criminal’s, list of all passengers etc. The system also allows us to add records when a passenger reserves a ticket. For data storage and retrieval we use the file-handling facility of C Language. It enables us to add any number of records in our database. But for intrinsic nature of file handling, the retrieval process is slow when we

Search a particular record in the database, because record is searched sequentially.

1.1 About Project

The project named “Airline Management System” is written in Turbo C++ IDE3.0, mainly because of it’s suitability for this type of application. Its user friendly nature and in-built documentation, complication, error detection, binding facilities and interaction with other software packages make it most powerful tool for software development. Moreover .Turbo C++ consists of all the technologies that help in creating and running robust, scalable and distributed packages.C++ is a general-purpose object-oriented programming language, and is intended to be an improved C with object capabilities

Assistance is provided to the user at each and every step so that no problem is faced during using it. Further the details of every process and the user manuals attached in the report make it very easy to understand. Every possible care has been taken to make the software and the report clear, simple and error free which makes it so special and one of its kind.

1.2 Objectives of the Project

➢ .To provide some amount of automation in airlines mangement.

➢ .To help airlines system in making their business more efficient.

➢ . An added attraction for their potential customers.

➢ . It will also show the attitute of the management that they are aware to the newly

introduced technology and ready to adopt them.

1.3 Purpose of the project

Electronically handling of flight’s record to enhance the accuracy, flexibility,

reliability and to remove the human’s error.

• An airline provides air transport services for passengers, generally with a recognized

operating

• To provide accurate information about the addition, deletion and modified movie’s

record.

• To provide, efficient, accurate, reliable, fast, and robust structure that can handle any

number of passenger’s transactions.

1.4 SCOPE OF THE PROJECT

This project on Airline Management System is the automation of registration process of airlines system. The system is able to provide much information like passenger’s information, criminal’s, list of all passengers etc.

The system also allows us to add records when a passenger reserves a ticket.

For data storage and retrieval we use the file-handling facility of C Language. It enables us to add any number of records in our database. But for intrinsic nature of file handling, the retrieval process is slow when we search a particular record in the database, because record is searched sequentially.

Need of Computerisation

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

1) Faster System

2) Accuracy

3) Reliability

4) Informative

5) Reservations and cancellations from any where to any place

1.5 PROJECT OVERVIEW

➢ Database and database systems have become an essential component of everyday life

in modern society. In the course of a day, most of us encounter several activities that

involve some interaction with the database. For example, if we go to the bank to

deposit or withdraw funds or if we make a Hotel or Airline Reservation, chances are

that our activities will involve someone accessing a database.

➢ The above interactions are examples of what we may call traditional database

applications, where most of the application that is stored and accessed is either textual

or numeric. In our project we will concentrate on this aspect of computer application.

➢ There are several ways to implement databases. Some of them are file handling

mechanism, relational database, object-relational database or object-oriented

databases. In our project we will use file-handling feature provided by C++ Language.

➢ This program shows you an insight into the management process of reservation in

Airline Management system. The whole process of Airline Management System is

shown with the help of this project. It provides facility to add/Modify/Delete/search

Airline Management details. and provide facility to view the list of Team .

➢ Facility to view the list of Team .

2. PROBLEM SELECTION

1. Before making this application, we assumed that an airline which had recently started

its operation found it very difficult to handle their customers.

2. It was due to their great customer service and efficient handling of daily operations

that they customer base started growing and in a day, they started to handle lot of

customer requests. The problem is that in manual airline record keeping system,

excessive staff employment is required, extremely time consuming process is

involved, inconveniences to both customers as well as to the manager.

3. Slowly & slowly the count of such customers started to grow very rapidly and the

airline employees had to devote their maximum time in handling such customers.

4. Slowly, an airline started loosing its important or gold customers due to poor response

times by the employees and they even started loosing those customers whose requests

could not be fulfilled.

5. After this, the management decided to install a system that can effectively &

efficiently service the request of such customers and can the corresponding work of

its employees who were overburdened with such tasks.

6. This action was a step towards serving important or fresh customers with a minimum

possible and improve the response times & efficiency of an airline employees.

Objective of this software is to simplify the employee record using computers

2.1 Existing System:

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

If any old data or information is to be fetched then it is a great problem for user to get the information in short span of time as to get information from files is not an easy task.

As everything is done manually, so if any record is misplaced then agency has to take full responsibility.

Limitation of existing system:

The earlier experiences have shown that manual monitoring of employee enquiries about their loans, conveyance, etc. Often fails to achieve the desired targets, mainly because of the following reasons:

➢ Much time required in giving correct information.

➢ Less reliability and maintainability of data.

➢ Secrecy of information may not be maintained due to visible facts on paper.

➢ Manual procedure of providing information is not reliable.

Every manager faces lot of minor & major problems like:

➢ Maintaining database.

➢ Record entry.

➢ Searching duplicate records.

➢ Searching & updating records.

An object oriented system draws upon class definitions that are derived from the analysis model. Some of the definitions will have to be built from scratch but many other can be reused if appropriate design patterns are recognized. Object oriented design establishes a design blueprint that enables a software engineer to the object oriented architecture in a manner that maximized reuse, thereby improving development speed and product quality.

The four layers of object oriented design are:

➢ The Subsystem Layer: It represents each of the sub systems It represents each of the subsystems that enable the software to achieve its user-defined requirements and to implement the technical infrastructure.

➢ The Class and Object Layer: It contains the class hierarchies that enable the system to be created using generalizations and increasingly more targeted specializations.

➢ The Message Layer: It contains the design details that enable each object to communicate with its collaborators. This layer establishes internal and external interfaces for the software.

➢ The Responsibility Layer: It contains the data structure and algorithmic design for all attributes and operations for each object. Monitoring system activity and server performance is a necessary part of preventive maintenance for the server. Through monitoring, you obtain data that u can use to diagnose system problems, plan growth and trouble shoot problems. You can use the monitoring and status tool, diagnostic logging, extended logging and queue viewer to keep the data up-to-date.

2.2 Proposed System:

The proposed system is computer based, user friendly, and easy to maintain. It makes safely storing of records easy and for a very long period of time. It would significantly improve the quality of work in the airport. The time spent in processing the above mentioned queries would significantly reduce. The proposed system provides free, easy and efficient management of the day-to-day activities of the passenger’s in airline so that the manual work can be reduced and even minute details can be accessed easily.

3. PROJECT MONITORING SYSTEM

3.1 Module Description

AIRLINE MANAGEMENT SYSTEM is basically a menu driven program. This

kind of format is designed considering the user requirements. This is to provide an

easy and faster method of operation to the user.

We have implemented validation at 03 points in the system as:

1. The first point is where the user enters his account & pin no. This is the most important part of our application because the information which would be fetched & is displayed to the user is confidential and it should be displayed only after proper authentication. So, for security reasons, we have given only one chance to the user to enter his pin correctly. If he does not, the system issues a warning through a proper message and exits. The user then again has to swipe his card, enter his account & pin no. to view the account details or undertake any account activity.

2. The second point where this is implemented is the menu where the user chooses from a list of options to process his requests. Since this is a menu-driven program, we expect from the user to input correct option. But if, for some reason, the user is unable to enter it correctly, we flash a message which requests the user to enter a correct option.

3. The third point where we have taken care of user input is the place where user wants to withdraw money from his account. Ideally, the user should not enter the withdrawal amount greater that his total amount and if mistakenly he does, the system flashes a user message and inform him about the same.

4. SYSTEM STUDY

4.1 FEASIBILITY STUDY

A feasibility study is carried out to select the best system that meets performance requirements.

Feasibility is the determination of whether or not a project is worth doing. The process followed in making this determination is called a feasibility study. This type of study determines if a project can and should be taken.

Since the feasibility study may lead to the commitment of large resources, it becomes necessary that it should be conducted competently and that no fundamental errors of judgment are made.

Depending on the results of the initial investigation, the survey is expanded to a more detailed feasibility study. Feasibility study is a test of system proposal according to its workability, impact on the organization, ability to meet user needs, and effective use of resources.

The objective of the feasibility study is not to solve the problem but to acquire a sense of its scope . During the study, the problem definition is crystallized and aspects of the problem to be included in the system are determined.

Consequently, costs and benefits are described with greater accuracy at this stage.

It consists of the following:

1. Statement of the problem: A carefully worded statement of the problem that led to analysis.

2. Summary of finding and recommendations: A list of the major findings and recommendations of the study. It is ideal for the user who requires quick access to the results of the analysis of the system under study. Conclusion are stated , followed by a list of the recommendation and a justification for them .

3. Details of findings : An outline of the methods and procedures under-taken by the existing system, followed by coverage of the objectives and procedures of the candidate system. Included are also discussions of output reports, file structures, and costs and benefits of the candidate system.

4. Recommendations and conclusions: Specific recommendations regarding the candidate system, including personnel assignments, costs, project schedules, and target dates.

Three key considerations are involved in the feasibility analysis these are

1. Operational Feasibility

2. Technical Feasibility

3. Behavioral Feasibility

4.1.1 Operational Feasibility:

Operational analysis is the most frequently used method for evaluating the effectiveness of a system. More commonly known as cost/ benefit analysis, the procedure is to determine the benefits and savings that are expected from a system and compare them with cost.

Earlier in Computer Craft the work has been done manually which takes lot of time as well as man power which is more economical. Now the same work is computerized which is more effective and efficient, less time consuming, reduces man power which in turn proves to be less economical.

4.1.2 Technical Feasibility:

Technical Feasibility centers around the existing computer system (hardware/ software) and also it can support the modification.

In manual processing there are more chance of errors are there, creating lot of complications, less technical or logical.

Through proposed system we can set this process in a very systematic pattern, which is more technical, full proof, authentic, safe and reliable.

4.1.3 Behavior Feasibility:

Our proposed system works to minimize the human errors, take less time, easy interaction with user, bug free.

This project/software is further expanded by connecting various interrelated departments and by installing an extension part of this software.

• System level goals and requirements.

• Cost estimation for development process and work product.

• Solution strategy development.

• Outlines of the several solutions strategies.

• Recommendation of solutions strategy.

• Feasibility and study of each strategy.

5. SYSTEM ANALYSIS

The analysis model must achieve three primary objectives:-

1. To describe the requirements of the customer.

2. To establish a basis for the creation of a software design.

3. To define a set of requirements that can be validated once software is built.

An Overview to system analysis

The system analysis phase is considered to be one of the most important phases in the system development life cycle. It is immensely important that the software developer make through study of the existing system. Thorough study of the system is made and need i.e. features that are critical to system success and users wants (i.e. features that would be good but not essential) are brought out. The study will enable the developer to know the intricacies of the existing system.

Requirement analysis is done in order to understand the problem which the S/W system is to solve e.g., the problem could be automating the existing manual system or developing a completely new automated system or a combination of the two. For large systems having a large number of features and the need to perform many different tasks, understanding the requirement of the system is a major task. The emphasis in requirement analysis is on identifying what is needed from the system, and not how the system achieves its goal.

The main objective behind any business organization is to maximize its profit besides maintaining quality and strategic norms. This can be achieved by improving the efficiency of the system by providing more facilities using automation, by adopting faster data access, proper communication. , whereas the main objective behind automation is not only to maximize profit but also to take care of passenger’s interest by providing them better facilities.

The most important objective behind automation is to minimize Paper Work. Paper Work/Registers are replaced by a Centralized Data Bank, which is well equipped to store / provide information as and when required. Data Bank also helps speed up the

communication between various depts. outside agencies, as there is no need of making request against different departments for a specific data and to wait for it for a long period. This also improves the efficiency as it saves time and human resources.

By making the manual system computerized, we can ensure complete utilization of our existing resources. Automation helps in generating the reports / information in a consistent way, which saves time and labour if done manually.

In this project we have used Rapid Application Development (RAD) model. RAD is an incremental software development process model that emphasizes an extremely short development cycle. The following phases are encompassed:

Business modeling: All the information about the business functioning of the Airways department is collected, how the data and information is flow from one end to another end using the following questions: What information drives the department process? What information is generated? Who generates it? Where does the information go? Who process it?

Data modeling: The information collected in Business modeling phase is refined into a set of data objects that are needed to support the project. The attributes of each object are identified and the relationships between these objects defined.

Process modeling: Processing descriptions and functions like adding, modifying, deleting records, printing reports, providing information, file handling etc. are created.

Application generation: The fourth generation techniques are used to generate application, like reusing the predefined functions or creating reusable components.

Testing: Most of the functions are already tested, as they are predefined functions. However, new components or functions are also tested after application generation.

It is the interdiciplinary part of science, dealing with analysis of sets of interacting entities, the systems often prior to their automation as computer systems, and the interactions within those systems. This field is closely related to operations results It is also "An explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made."

Systems analysis researchers apply mathematical methodology to the analysis of the systems involved trying to form a detailed overall picture.

The development of a computer-based information system often comprises the use of a systems analyst. When a computer-based information system is developed, systems using computer hardware/software), what the system would be used for etc.analysis would constitute the following steps:

The development of a feasibility study, involving determining whether a project is

economically, socially, technologically and organizationally feasible.

Conducting fact-finding measures, designed to ascertain the requirements of the

system's end-users. These typically span interviews, questionnaires, or visual

observations of work on the existing system.

Gauging how the end-users would operate the system.

It refers to the process of examining a business situation with the intent of improving it

through better procedures and methods. Systems development can generally be thought

of as having two major components: Systems Analysis and Systems Design.

Systems design is the process of planning a new system or replace or complement an

existing system. But before this planning can be done, we must thoroughly understand

the existing system and determine how computers can best be used to make its

operation more effective. Systems analysis, then, is the process of gathering and

interpreting facts, diagnosing problems and using the information to recommend

improvement to the system. In brief, we can say that analysis specifies what the system

should do. Design states how to accomplish the objective.

Analysis is a detailed study of the various operations performed by a system and their

relationships within and outside of the system. A key question is: What must be done

to solve the problem? One aspect of analysis is defining the boundaries of the system

and determining whether or not a candidate system should consider other related

systems. During analysis, data are collected on the available files, decision points and

transactions handled by the present system. There are some logical system models and

tools that are used in analysis. Data flow diagrams, interviews, on-site observations,

and questionnaires are examples. The interview is a commonly used tool in analysis. It

requires special skills and sensitivity to the subjects being interview. Bias in data

collection and interpretation can be a problem. Training, experience, and common

sense are required for collection of the information needed to do the analysis. Once

analysis is completed, the analyst has a firm understanding what is to be done. The

next step is to decide how the problem might solve. Thus, in systems design, we move

from the logical to the physical aspects of the life cycle.

The decision to acquire computer hardware or software must be handled in the same

way as any other business decision. The variety of sizes and types of computing

resources available puts a burden on the analyst who must select suitable hardware,

software or services and advise the top management accordingly.

Today, selecting a system is a serious and time-consuming business. The time spent on

the selection process is a function of the applications and whether the system is a basic

micro- computer or a mainframe. In either case, planning system selection and

acquiring experienced help where necessary pay off in the long run.

There are various important factors, which should be considered prior to system

selection. They are:

Define system capabilities that make sense for the business.

Specify the magnitude of the problem, i.e., clarify whether selection entails a few

peripherals or a major decision concerning the mainframe.

Assess the competence of the in-house staff.

Hardware and software should be considered as a package.

Develop a time frame for the selection process.

Provide user indoctrination.

This is crucial, especially for first-time users. Selling the system to the user staff, provide adequate training and creating an environment conductive to implementation are prerequisites for system acquisition.

The selection process should be viewed as a project and a project team should be formed with the help of management. The selection process consists of several steps, which are discussed below:

➢ Requirements analysis: The first step in selection understands the user's requirement within the framework of the organization’s objectives and the environment in which the system is being installed.

➢ System specifications: System specifications must be clearly defined. These specifications must reflect the actual applications to be handled by the system and include system objectives, flowcharts, input-output requirements, file structure and cost.

Request for proposal: After the requirement analysis and system specifications have

been defined, a request for proposal is prepared and sent to selected vendors for

bidding.

Evaluation and validation: The evaluation phase ranks various vendor proposals and

determines the one best suited to the user's requirements. It looks into items such as

price, availability and technical support. System validation ensures that the vendor

can, in fact, match his/her claims, especially system performance.

Vendor selection: This step determines the vendor with the best combination of

reputation, reliability, service record, training, delivery time, lease/finance terms. The

selected vendors are invited to give a presentation of their system. The system

chosen goes through contract negotiations before implementation.

WORKING OF THE PROJECT

User can view record about flight by selecting option 1 from the main menu.

User can reserve the seat for view the flight. by selecting option 2.

User can also cancel the reserved ticket for flight by selecting option 3.

Admin can collect total amount. by selecting option 4.

5.1 SDLC

In this project we have followed the Waterfall model.

The waterfall model is the most familiar model. This model has five phases:

requirements analysis and specifications, design, implementation and unit testing,

integration and system testing, and operation and maintenance.

1.Requirements Analysis and Specification Phase: The goal of this phase is to

understand the exact requirements of the customer and to document them properly.

This activity is usually executed together with the customer, as the goal is to document

all functions, performance and interfacing requirements for the software. The

requirements describes the “what” of a system, not the “how”.

2. Design phase: The goal of this is to transform the requirements specification into a

structure that is suitable for implementation in some programming language.

3. Implementation and Unit Testing Phase: During testing, the major activities are

centered around the examination and modification of the code. Initially, small modules

are tested in isolation from the rest of the software product. There are problems

associated with testing a module in isolation. How do we run a module without

anything to call it, to be called by it or, possibly, to output intermediate values obtained

during execution? Such problems are solved in this phase and modules are tested after

writing some overhead code.

4. Integration and System Testing Phase: The purpose of unit testing is to determine

that each independent module is correctly implemented. This gives little chance to

determine that the interface between modules is also correct, and for this reason

integration testing is performed. System testing involves the testing of the entire system

whereas software is a part of the system. This is essential to build confidence in the

developers before software is delivered to the customer or released in the market.

5. Operation and Maintenance Phase: Software maintenance is a task that every

development group has to face, when the software is delivered to the customer’s site,

installed and is operational. Therefore, release of software inaugurates the operation

and maintenance phase of the life cycle. The time spent and effort required to keep the

software operational after release is very significant.

Fig. 1

5.2 USE CASE DIAGRAM

Administrator

Manager

Fig. 2

5.3 DATA FLOW DIAGRAM

Data flow diagrams are commonly used during problem analysis. Data flow diagrams are quite general and not limited to problem analysis for software requirement specification. A DFD shows the flow of data through a system. It views a system a function that transforms the inputs into desired outputs. Any complex system does not perform this transformation into a single step and a data will typically undergo a series of transformation before it becomes an output. The DFD aims to capture the transformations that take place within a system to the input data so that eventually the output data is produced.

The agent that performs the transformation of data from one state to another is called a process. So, a DFD shows the movement of data through the different transformations or processes in the system. Named circles show the processes and data named arrows entering or leaving the bubbles represent flows.

Process Activity

The rectangle represents a source and sink and is a net originator or consumer of data. A source or sink is typically outside the main system of study.

Originator or Consumer of data

All external files are shown as a labeled straight line.

File name

The need ofr multiple data flows by a process is represented by a “*” between the data flows.the symbol represents the AND relationship.for example, if there is a “*” between the two input data flows A and B for a process,it means that A AND B are needed for the process.

A

*

B

5.3.1 0 Level DFD

Fig. 4

5.3.2 1st Level DFD

Fig. 5.2 Reservation

5.3.3 2nd Level DFD

1. LOGIN

2. TICKETS

3. CUSTOMER

Fig. 5.3 level DFD

5.4 ER DIAGRAM

An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes. If the application is primarily a database application, the entity-relationship approach can be used effectively for modeling some parts of the problem. The main focus in ER modeling is the Data Items in the system and the relationship between them. It aims to create conceptual scheme for the Data from the user’s perspective. The model thus created is independent of any database model. The ER models are frequently represented as ER diagram. Here we present the ER diagram of the above mentioned project.

E-R DIAGRAM

5.5 FLOWCHART

In procedural language program is started with the first line and follow a pre-define Path. Flow chart is used to define that pre-defined path and it show the flow of control throughout the program. The flow charts are used in programming for purpose of indicating the sequence of Operation of Program. It is very useful tool available for the programmer to generate method of writing the program and statement of program. It creates sequence of operations and indicated transfer of control in an effective manner. The flow charts use symbol’s or blocks of different shapes for representing statement of program.

A flowchart is a common type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.

FLOW CHARTS

6. SYSTEM DESIGN

The systems objectives outlined during the feasibility study serve as the basis from which the work of system design is initiated. Much of the activities involved at this stage is of technical nature requiring a certain degree of experience in designing systems, sound knowledge of computer related technology and thorough understanding of computers available in the market and the various facilities provided by the vendors. Nevertheless, a system cannot be designed in isolation without the active involvement of the user. The user has a vital role to play at this stage too. As we know that data collected during feasibility study will be utilized systematically during the system design. It should, however, be kept in mind that detailed study of the existing system is not necessarily over with the completion of the feasibility study. Depending on the plan of feasibility study, the level of detailed study will vary and the system design stage will also vary in the amount of investigation that still needs to be done. This investigation is generally an urgent activity during the system design as the designer needs to study minute’s details in all aspects of the system. Sometimes, but rarely, this investigation may form a separate stage between Feasibility Study and Computer System Design. Designing a new system is a creative process, which calls for logical as well as lateral thinking. The logical approach involves systematic moves towards the end product keeping in mind the capabilities of the personnel and the equipment at each decision making step. Lateral thought implies encompassing of ideas beyond the usual functions and equipment. This is to ensure that no efforts are being made to fit previous solutions into new situations.

System Design Considerations:

The system design process is not a step-by-step adherence of clear procedures and guidelines. Though, certain clear procedures and guidelines have emerged in recent days, but still much of design work depends on knowledge and experience of the designer.

When designer starts working on system design, he will face different type of problems. Many of these will be due to constraints imposed by the user or limitations of the hardware and software available in the market. Sometimes, it is difficult to enumerate the complexity of the problems and solutions thereof since the variety of likely problems is so great and no solutions are exactly similar. However, following considerations should be kept in mind during the system-designing phase:

The primary objective of the design: Of course, is to deliver the requirements as specified in the feasibility report. In general, the following design objectives should be kept in mind:

Practicality: The system must be stable and can be operated by people with average

Efficiency: This involves accuracy, timeliness and comprehensiveness of the system

output.

Cost: it is desirable to aim for a system with a minimum cost subject to the condition that it must satisfy all the requirements.

Flexibility: The system should be modifiable depending on the changing needs of the user. Such modifications should not entail extensive reconstructing or recreation of software. It should also be portable to different computer systems.

Security: This is very important aspect of the design and should cover areas of hardware reliability, fall back procedures, physical security of data and provision for detection of fraud and abuse.

System design involves first logical design and then physical construction of the system. The logical design describes the structure and characteristics of features, like the outputs, inputs, files, databases and procedures. The physical construction, which follows the logical design, produces actual program software, files and a working system.

The designer normally will work under following constraints:

Hardware: The existing hardware will obviously affect the system design.

Software: The available software (operating system, utilities, language etc.) in the market will constrain the design.

Budget: The budget allocated for the project will affect the scope and depth of design.

Time-scale: The new system may be required by a particular time (e.g. the start of a financial year). This may put a constraint on the designer to find the best design.

Interface with other systems: The new system may require some data from another computerized system or may provide data to another system in which case the files must be compatible in format and the system must operate with a certain processing cycle.

Processing Techniques:

The processing options available to the designer are:

Batch processing

Real-time processing

On-line processing

A combination of all the above

You are already aware of these techniques. It is quite interesting to note, however, that a combination of these is often found to be ideal in traditional data processing applications. This increases throughput of the system as also brings down the response time of on-line activities. In most of die business applications, 24-hour data is acceptable enough and hence it is possible to update voluminous data after office-hours in batch mode.

6.1 DESIGN METHODOLOGIES

The scope of the systems design is guided by the framework for the new system developed during analysis. More clearly defined logical method for developing system that meets user requirements has led to new techniques and methodologies that fundamentally attempt to do the following:

Improve productivity of analysts and programmers

Improve documentation and subsequent maintenance and enhancements.

Cut down drastically on cost overruns and delays

Improve communication among the user, analyst, designer, and programmer.

Standardize the approach to analysis and design

Simplify design by segmentation.

6.2 STRUCTURED DESIGN

Structured design is a data flow based methodology. The approach begins with a system specification that identifies inputs and outputs and describes the functional aspects of the system. The specifications then are used as a basis for the graphic representation. The next step is the definition of the modules and their relationships to one another in a form called a structure chart, using a data dictionary and other structured tools.

Logical design proceeds from the top down. General features, such as reports and inputs are identified first. Then each is studied individually and in more detail. Hence, the structured design partitions a program into small, independent modules. They are arranged in a hierarchy that approximates a model of the business area and is organized in a top-down manner. Thus, structured design is an attempt to minimize the complexity and make a problem manageable by subdividing it into smaller segments, which is called Modularization or decomposition. In this way, structuring minimizes intuitive reasoning and promotes maintainable provable systems.

A design is said to be top-down if it consists of a hierarchy of modules, with each module having a single entry and a single exit subroutine. The primary advantages of this design are as follows:

➢ Critical interfaces are tested first.

➢ Early versions of the design, though incomplete, are useful enough to resemble the real system.

➢ Structuring the design, perse, provides control and improves morale.

➢ The procedural characteristics define the order that determines processing.

Major System Design Activities:

Several development activities are carried out during structured design. They are data base design, implementation planning, system test preparation, system interface specification, and user documentation.

Data base design: This activity deals with the design of the physical database. A key is to determine how the access paths art to be implemented.

Program design: In conjunction with database design is a decision on the programming language to be used and the flowcharting, coding, and debugging procedure prior to conversion. The operating system limits the programming languages that will run of the system.

System and program test preparation: Each aspect of the system has a separate test requirement. System testing is done after all programming and testing completed the test cases cover every aspect of the proposed system, actual operations, user interface and so on. System and program test requirements become a part of design specifications - a pre requisite to implementation.

6.3 MODULE COUPLING

Coupling is the measure of the degree of interdependence between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another. “Loosely coupled” systems are made up of modules which are relatively independent. “Highly coupled” systems share a great deal of dependence between modules.

DATA COUPLING

The dependency between module A and B is said to be coupled it their dependency is based on the fact they communicate by only passing of data.

STAMP COUPLING

Stamp coupling occurs between module A and B when complete data structure is passed from one module to another.

CONTROL COUPLING

Module A and B are said to be control coupled if they communicate by passing of control information.

EXTERNAL COUPLING

A form of coupling in which has a dependency to other module, external to the software being developed or to a particular type of hardware.

COMMON COUPLING

With common coupling, module A and B have shared data. Global data areas are commonly found in programming languages. Making a change to the common data means tracing back to all the modules which access that data to evaluate the effect of change.

CONTENT COUPLING

Content coupling occurs when module A changes data of module B or when control is passed from one to the middle of another.

6.4 MODULE COHESION

Cohesion is a measure of the degree to which the elements of a module are functionally related. A strongly cohesive module implements functionality that is related to one feature of the solution and requires little or no interaction with other modules.

FUNCTIONAL COHESION

X and Y are part of a single functional task. This is very good reason for them to be contained in the same procedure.

SEQUENTIAL COHESION

X output some data which forms the input to Y. This is the reason for them to be contained in the same procedure.

COMMUNICATIONAL COHESION

X and Y both operate on the same input data or contribute towards the same output data. This is okay, but we might consider making them separate procedures.

PROCEDURAL COHESION

X and Y are both structured in the same way. This is a poor reason for putting them in the same procedure. Thus, procedural cohesion occurs in modules whose instructions although accomplish different tasks yet have been combined because there is a specific order in which the tasks are to be completed.

TEMPORAL COHESION

X and Y both must perform around the same time. So, module exhibits temporal cohesion when it contains tasks that are related by the fact that all tasks must be executed in the same time-span.

LOGICAL COHESION

X and Y perform logically similar operations. Therefore, logical cohesion occurs in modules that contain instructions that appear to be related because they fall into the same logical class.

COINCIDENTAL COHESION

X and Y here no conceptual relationship other than shared code Hence, coincidental cohesion exists in modules that contain instructions that have little or no relationship to one another.

6.5 STRATEGY OF DESIGN

A good system design strategy is to organize the program modules in such a way that are easy to develop and later to, change. Structured design techniques help developers to deal with the size and complexity of programs. Analysts create instructions for the developers about how code should be written and how pieces of code should fit together to form a program.

Bottom Up Design

These approach lead to a design where we decide how to combine these modules to provide larger ones; to combine those to provide a larger ones, and so on, till we arrive at one big module which is the whole of the desired program. The set of these modules form a hierarchy. This is a cross-linked tree structure in which each module is subordinate to those in which it is used.

Since the design progressed from bottom layer upwards, the method is called bottom-up design. This method has one terrible weakness; we need to use a lot of intuition to design exactly what functionality a module should provide. If we get it wrong, then at higher level, we will find that it is not as per requirements; then we have to redesign at a lower level.

Top- Down Design

A top design approach starts by identifying the major modules of the system, decomposing them into lower level and iterating until the desired level of detail is achieved. This is a stepwise refinement; starting from an abstract design, in each step the design is refined to a more concrete level, until we reach a level where no refinement is needed and the design can be implemented directly. Most design methodologies are based on this approach is suitable, if the specifications are clear and development is from the scratch.

Hybrid Design

Hybrid approach has really become popular after the acceptance of reusability of modules. Standard libraries, Microsoft foundation classes, object oriented concepts are steps in this direction. We may soon have internationally acceptable standards for reusability.

7. SYSTEM TESTING AND IMPLEMENTATION

Software testing is the process of executing a program with the intention of finding errors in the code. It is the process of exercising or evaluating a system or system component by manual or by automatic means to verify that it satisfies specified requirements or to identify differences between expected and actual results.

The objective of testing is to show incorrectness and testing is considered to succeed when an error is detected. An error is a conceptual mistake made by either the programmer or the designer or a discrepancy between a computed value and a theoretically correct value. A fault is a specific manifestation of an error. An error may be cause of several faults. A failure is the inability of a system or component to perform its required function within the specified limits. A failure may be produced when a fault is executed or exercised.

Other activities that are often associated with software are static analysis and dynamic analysis. Static analysis investigates the source code of software, looking for problems and gathering metrics without actually executing the code. Dynamic analysis looks at the behavior of software while it is executing, to provide information such as execution traces, timing profiles and test coverage information.

7.1 Levels of testing

7.1.1 Unit Testing or Module Testing

The starting point of testing is Unit testing. In this, a module is tested separately at each step. This helps to detect syntax and logical errors in the program and is performed by the coder himself /herself during coding.

7.1.2 Integration Testing

The modules, which are tested in the Unit Testing, are integrated to build the overall system. It is observed that many errors crop up when the modules are joined together. Integration testing uncovers these errors while integrating the modules. It helps in establishing confidence (correctness) in the complete, assembled system. It tests the System Design. It focus on control, communication, interfaces, performance (other system qualities). It make use of stubs, test-beds, data generators. It is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.

Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Integration testing concentrates entirely on module interactions, assuming that the details within each module are accurate. Module and Integration testing can be combined, verifying the details of each module's implementation in an integration context. Many projects compromise, combining module testing with the lowest level of subsystem integration testing, and then performing pure integration testing at higher levels. Each of these views of integration testing may be appropriate for any given project, so an integration testing method should be flexible enough to accommodate them all.

The System testing is bringing together of all programs that a system comprises for testing purposes. System testing is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. Programs are typically integrated in a top-down, incremental fashion. It is a series of different tests whose primary purpose is to fully exercise the computer-based system. It includes the following tests: -

• Recovery Testing: - It is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed.

• Stress Testing:- These are designed to confront program functions with abnormal situations. It executes a system in a manner that demands resources in abnormal quantity, frequency or volume.

• Security Testing:- This testing attempts to verify that protection mechanism built into a system will protect it from unauthorized penetration.

The system testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and test not only the design, but also the behaviour and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specification(s).

7.2 Types of testing

7.2.1 Black Box Testing

It is also known as Functional Testing. It tests the overall functional requirements of product. Inputs are supplied to product and outputs are verified. If the outputs obtained are the same as the expected ones then the product meets the functional requirements. In this, the internal procedures are not considered. In this the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs. This Testing is more effective on larger units of code. In this test’s are done from user point of view.

7.2.2 White Box Testing

It is also known as Structure Testing. It focuses on the internal functioning of the product. It tests the loops of the Procedure, Decision points, Execution paths etc.

White box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable. As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively. The other advantage of white box testing is that it helps in optimizing the code. It helps in removing the extra lines of code, which can bring in hidden defects.

7.2.3 Acceptance Testing

This Testing is done when the software is developed for the specific customer. A series of tests are conducted to enable the customer to validate all requirements. The end user/ customer conducts these tests and may range from adhoc test to well-planned systematic series of tests. Acceptance testing may be conducted for few weeks or months. The discovered errors will be fixed and better quality software will be delivered to the customer.

Acceptance testing is performed by the customer on a system prior to the customer accepting delivery or accepting transfer of ownership of that system.

The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works. Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release. A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created each iteration or the development team will report zero progress.

7.2.4 Alpha Testing

Testing after code is mostly complete or contains most of the functionality and prior to users being involved. Sometimes a select group of users are involved. More often this testing will be performed in-house or by an outside testing firm in close cooperation with the software engineering department.

In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

7.2.5 Beta Testing

Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large in hopes that they will buy the final product when it is released.

IMPLEMENTATION

The application can be uploaded in the AIRLINE MANAGEMENT SYSTEM. To access it, the user will just require running the executable file of the software. System must have Turbo c++ driver. Basically the application is for the recording of the Star Sport’s records. As implementation of AIRLINE MANAGEMENT System software fully automate the existing system. In the designed system implementation was done to replace a manual system with the computerized one. The objective was to put the tested system in to operation. Critical aspects of conversion are not disrupting the functioning of the organization. This phase gives us the clears pictures of our new system and all the points that have been carefully looked in when designing the computerized system.

Sincere efforts were taken for the implementation of the following goals.

➢ Maximizing the output reliability

➢ Maximizing the source test readability

➢ Minimizing the development time.

8. DOCUMENTATION

8.1 AIRLINE MANAGEMENT CODING

/*

|***********************************************************************|********

| THIS PROGRAMME HELPS

| ==================== |

| (1) A PASSENGER TO BOOKED DOMESTIC FLIGHT

| (2) A PASSENGER TO BOOKED INTERNATION FLIGHT

| (3) A PASSENGER TO CONFIRMED HIS/HER TICKET

| (4) TO VIEW ALL THE MEMBER WHO BOOKED THEIR TICKET

| (5) TO CANCEL YOUR TICKET |

| (6) TO VIEW ALL THE MEMBER WHO RECENTLY CANCELLED THEIR

| TICKET

|

|*******************************************************************************

*/

#include

#include //FOR COUT,CIN,FLOAT,INT

#include //FOR GETCH,CLRSCR,GOTOXY

#include //FOR GRAPHIC FUNCTIONS(CLOSEGRAPH,LINE)

#include //FOR ENDL

#include //FOR STRCMP

#include //FOR GETS,PUTS

#include //FOR SOUND,NOSOUND,DELAY

int x=14;

int y=14; // GLOBAL VARIABLES

int ch;

int a;

// FUNCTION DECLARATION

void port(void);

void show(void);

void ichos(void);

void dchos(void);

void wel(void);

void ars(void);

void option(void);

void ticksho();

int cho();

void line(void);

void end(void);

void table(void);

void exit();

class airport{

private:

char name[30];

char sex[10];

char dest[30];

char meal[10];

char* airways;

char* flno;

public:

char a,b,c,d,e,f,g ;

int age;

float fare;

int time;

void input();

void calculate();

void dcalculate();

void show();

void output();

char *return_name();

}; //end of class declaration

// MEMBER FUNCTION DECLARATION

char * airport::return_name()

{

return name;

}

void airport::input()

{

cout ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download