Quality Assurance Plan AIRLINE RESERVATION SYSTEM Project Code: S301
Internal Advisor: Ma’am Sabeen Amjad
Project Manager:
Sarim Khan (SP15-BSE-079-A) Project Team:
Myra Anwar(SP15-BSE-075-A) Roha Ijaz (SP15-BSE-059-A) (SP15-BSE-059-A) Wasif Ali (SP15-BSE-065-A) (SP15-BSE-065-A) Submission Date:
Oct 9,2017
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Pr o je ject M Manager ’s S Signatur e
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations
3 3 3 3
2. Overview 2.1 Product Perspective
4 4
2.1.1 System Interfaces
4
2.1.2 User Interfaces
4
2.1.3 Hardware Interfaces
4
2.2
4
Product Functions
3. Software Requirements According to McCall’s Quality Factors: 3.1 Correctness Requirements 3.2 Reliability Requirements 3.3 Efficiency Requirements 3.4 Integrity Requirements 3.5 Usability Requirements 3.6 Maintainability Requirements 3.7 Flexibility Requirements 3.8 Testability Requirements 3.9 Portability Requirements 3.10 Reusability Requirements 3.11 Interoperability Requirements
5 5 5 5 6 6 6 6 7 7 7 7
1. Introduction This section lists all the goals and objectives of the system categorized based on the viewpoint of the airline company and the customer (passenger). These are higher-level goals which are somewhat broad in nature
1.1 Purpose The main purpose of this software is to reduce the manual errors involved in the airline reservation process and make it convenient for the customers to book the flights as when they require such that they can utilize this software to make reservations, modify reservations or cancel a particular reservation.
1.2 Scope The name of the software is “AIRLINE RESERVATION SYSTEM”. This software provides options for viewing different flights available with timings for a particular date and provides customers with facility to book a ticket, modify or cancel a particular reservation but it doesn’t provide the customers with details of cost of the ticket and it does not allow the customer to modify a particular part of his reservation and he/she can modify all his details.
1.3 Definitions, Acronyms, and Abbreviations Airline Reservation System will henceforth be abbreviated as ARS. The passenger will henceforth be called the 'user. A user is categorized as a guest or a registered user. A guest can only check the availability of tickets and cannot block or buy tickets. A registered user on the other hand will be able to check the availability of tickets as well as block/buy a ticket by logging into the system. The system will have the following database systems: DB-user is the database containing all the personal information of the registered users of the ARS. This can be updated by the user by logging in to the system. Information from this database is used during transactions like charging the credit card etc. DB-schedule is a copy of the flight schedule database. DB-schedule is updated with the latest status of the flight schedule database whenever there is any change in the latter. DB-reservations are a database containing information regarding the number of seats available on each class on different flights. It has provision for marking how many of the reserved seats have been blocked but not yet bought. DB-reservations should update itself using DB-schedule. DB-geography is a database, which contains information about the cities and towns serviced by the airline. The distance between all cities and towns is contained in a matrix form.
2. Overview The rest of the document deals about all the main features of this software each will its purpose and its main functions. It also gives details about the interface with other products and related functionality of each product.
2.1 Product Perspective The “ARS” software is an independent application. It is a self -contained product. The system interfaces, user interfaces and hardware interfaces related with this software are defined as follows.
2.1.1 System Interfaces The client systems should be able to share the data available in the data base through the network connection.
2.1.2 User Interfaces There are three interfaces, one for the administrator, one for the customer via web and another for the customer via phone. The screen formats and menu structure should be in such a way that even have users will find it easy to use. The product must be usefriendly and very inter-active. The functionality provided by the system like displaying error messages should adapt itself to the different users of the software.
2.1.3 Hardware Interfaces The software system has two hardware interfaces one is the desk-reservation system (also a desktop computer sytem) which uses Windows OS and the other is the smartphone device which uses Android OS.
2.2 Product Functions The major functions include: •Providing flight details •Flight bookings for a particular destination, date and time and also p roviding with a pin code. • Allowing the customer to modify or cancel his reservation providedthe correct pin code is given. •Displaying a report of the number of people flying in a particular flight.
3. Software Requirements According to McCall’s Quality Factors:
3.1 Correctness Requirements
The system shall allow the employee to cancel the reservation of a customer when required. The probability for a non-accurate output, containing one or more mistakes, will not exceed 1%. The probability of missing data about a customer, his reservation, and his payments will not exceed 1% in two weeks. Average reaction time for queries will be less than two seconds; the reaction time for reports will be less than 20 minutes. The Airline reservation system and its documentation are required to comply with the client’s guidelines and standards. Help document must be written using minimal technical terms; any technical terms used must be additionally defined at the end of the document
3.2 Reliability Requirements
Airline Reservation System’s Mean Time to Failure should not be more than 10 seconds within 24 hours of use Data redundancy and use of special/blank characters must be avoided. 150 airline employees should be able to simultaneously access the system and update the database
Average system response time should not be greater than 2 seconds.
Defects of the system after release must not exceed 2 critical bugs per month
In case of server crash all information/data should be recoverable within 15 Minutes of the incidence.
3.3 Efficiency Requirements
There must be a 64 MB on board memory The software system would require a disk space of 10 GB for desk-reservation systems. There should be two communication lines of 29.9KBPS between e ach branch of the airline and the head office. System must successfully run on a client machine with 2 56 MB RAM or above.
There should be a storage volume of 10GB per branch computer and 30 GB in the head office. Phone version of the software system will require a smartphone device with Android OS 2.3 or above.
3.4 Integrity Requirements
Airline Reservation System must provide access only to authorized employees that enter through the login module. Airline Reservation System must provide access only to designated users to update the airline database. No airline employee can read data of any other employee or department through any report or views provided by the Airline Reservation System. After the end of an employee session, no information must be saved anywhere on the client machine. The system must always be exited normally
3.5 Usability Requirements
ARS shall provide a graphical interface similar to other existing reservation system so that the users do not have to learn a new style of interaction. The web will use GUI interface to allow the Users to understand the menu and options provided by ARS. Any notification or error messages generated by ARS shall be clear, succinct, polite and free of jargon and should not take more than 10 to 15 seconds for a person with average reading skills to understand it.
3.6 Maintainability Requirements
The software will be developed by implementing the concept of modularity (30 modules per statement) which in turn reduces the complexity involved in maintaining it. The administrator should have a sound technical knowledge about maintaining the software and further enhancements will be undertaken by the developer.
3.7 Flexibility Requirements
Employees shall be able to use the software within 3 days of training. Changes in the System modules can be made according to the requirements of the users within 4 weeks.
The System shall be able to adapt new features according to the Customer’s changing desires.
3.8 Testability Requirements The system in normal mode of operation, shall be able to respond in 6 seconds or less to any processing request of any type, from any user type request, with up to 200 concurrently active users; each making processing requests determined to place the greatest processing demand on the system. Under this load, the system shall have at least 35% spare CPU capacity.
3.9 Portability Requirements
Porting the Airline Reservation System for web and desk-reservation systems from Windows 8 to Windows 10 shall not require modifying more than 0.5% of the lines of non-comment, non-blank source code. The average time needed to port the application from Windows 8 to Windows 10 shall not exceed 1 month.
Porting the Airline Reservation System for phone from Android OS to iPhone OS shall not require modifying more than 20 % of the modules. The average time needed to port the a pplication from Android OS to iPhone OS shall not exceed 3 months.
3.10 Reusability Requirements The reusable modules will allow:
Requests to the Flight Scheduler to schedule extra flights.
Providing the wait listed passengers with a new fl ight.
The telephonic interfaces of the ARS allow the customers to cancel a ticket.
Send instant messages to the passengers, of a cancelled or rescheduled flight, through email, informing them about the change, and providing them with other feasible alternatives. Information about the kind of meals served in a flight and the type of e ntertainment offered on a flight.
3.11 Interoperability Requirements
The users (registered), by phone or by web should be basically taken through the same steps by the system as they go through in conventional desk-reservation systems.
DB-schedule is updated with the latest status of the Flight Schedule Database whenever there is any change in the Flight Schedule Database.
DB-user is updated with the latest status whenever the user logs into the system.
DB-reservations will update itself using DB-schedule.
Quality Factors
Correctness Reliability Efficiency Integrity Usability Maintainability Flexibility Testability Portability Reusability Interoperability
McCall’s software quality factors model + + + + + + + + + + +
Airline Reservation System
+ + + + + + + + + + +
