Online Rent A Car In Malaysia

Published Date: 02 Nov 2017

The purpose of this Software Quality Assurance Plan (SQAP) is to define the procedure, techniques and methodologies that will be used to assure the full functioning of the Online Rent-A-Car System in Malaysia (ORAC). This document is going to be used by the Quality Assurance Team so as to determine the quality of the product.

1.2 Scope

This SQAP applies only to Online Rent-A-Car System in Malaysia. It comprises of keeping records of cars, customers and staff in order to allow users to perform transactions in the system such as renting a car, staff accepting user registration and making online payment after booking. A little more detailed scope would be as follows:

This system is for use by only one company which will be maintained by the staff.

The company has different branches in Malaysia.

The customers will be charged according to terms and conditions specified.

The different features of a car rental system to be included will be:

Managing details of Vehicles

Managing Staff details

Managing Customer Details

Producing Daily, weekly and monthly reports

Booking of Vehicles

1.3 Quality Objective

The product must fulfill with all of the requirements as described in Software Requirements Specification (SRS) and Software Design Document (SDD).

The product will be tested in order to verify if it contains all the requirements put forward and the quality will be decided by the certified Quality Assurance Team.

1.4 Abbreviations and Acronyms

The Abbreviations used are as follows:

APU Asia Pacific University of Technology and Innovation

CASE Computer Aided Software Engineering

CMP Configuration Management Plan

GUI Graphical User Interface

RAD Rapid Application Development

SDD Software Design Document

SVVP Software Verification and Validation Plan

SQAP Software Quality Assurance Plan

SRS Software Requirements Specifications

UMD User Manual Document

2.0 REFERENCE DOCUMENTS

The documents used to produce this SQAP are as follows:

ORAC Software Requirement Specification document (SRS).

ORAC Software Design Document (SDD).

ORAC Software Verification and Validation Plan (SVVP)

ORAC Configuration Management Plan (CMP)

Software Engineering, Roger S. Pressman, 5th Ed.

IEEE Standard for Software Quality Assurance Plans, IEEE Std 730 – 2002.

3.0 MANAGEMENT

3.1 Organization

The Organisation Chart for ORAC System is given below:

3.2 Roles and Responsibilities

Since there are only three persons involved, their roles and responsibilities have been listed below:

Project Sponsor

1. Finalize the approval of the deliverables

2. Provide sponsorship for the project

3. Provide budget to the project and is considered to be the major recipient of the project

Project Manager

1. Manage the overall project

2. Establish Project Charter

3. Manage and develop a good work plan strategy

4. Solve Conflicts to make sure it does not affect the overall project quality and timing

5. Act as an interface for sponsors and provide an overall accountability for the project

Quality Assurance Officer

1. Analyze requirements during the requirements analysis phase of projects. 

2. Keep track of the new requirements from the Project. 

3. Forecast / Estimate the Project future requirements. 

System Analyst

1. Collect information to analyze and evaluate existing or proposed systems.

2. Write and maintain system documentation.

3. Document system problems and resolutions for future reference.

4. Prepare detailed flow charts and diagrams outlining systems capabilities and processes.

Developer

1. Write code or documentation patches.

Tester

1. Overall Testing of the system.

4.0 DOCUMENTATION

Various Documents are being used by ORAC in order to provide a system of quality. The following sections describe the documents. The documents follow IEEE Standards and all information as required by IEEE is found.

4.1 Software Requirements Specifications (SRS)

The SRS is a complete description of the requirements of a project. It includes Business Rules, hardware specifications, data models and other relevant information required by ORAC before the design of the system begins. An SRS is consistent if there is no requirement that conflicts with another. It important that every requirement represents something in the final ORAC System. Most importantly, non-functional Requirements should also be included in the SRS.

An example of the content of SRS is the Performance requirements under non-functional Requirements given as follows:

4.2 Software Design Document (SDD)

The SDD outlines all the designs made for prior to the development process of ORAC. It provides the complete written description of ORAC and gives the development team an overall guide of the architecture of ORAC. It contains information like Use Case Diagrams and GUIs. The Use Case Diagram of ORAC has been provided below.

E:\desktop 2013\MY FYP\22-12-2012 Docs\Documentation\Use case.jpg

4.3 Software Verification and Validation Plan (SVVP)

The SVVP of ORAC specifies the whole plan for the software verification and validation. It contains specific test data, possible outcomes, that is, what the quality assurance officer should expect of ORAC System while using. It is an assessment of ORAC overall quality with task specifications as in the methodology used for ORAC planning. The SVVP emphases more on the development stage of the methodology and summarises the anomalies of the system.

4.4 Configuration Management Plan (CMP)

Configuration management is a process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life. ORAC uses the CMP in order to control and document changes in ORAC and acts as a log to record issues and task being done.

4.5 User Manual Document (UMD)

The UMD provides a complete guide for installing, using and maintaining the ORAC System. It gives detailed description about all the components in the car rental system which allows the staff of the company to make full/efficient use of ORAC System. The UMD explains how the user can add a new car, view reports about transactions, change prices of bookings and add different branches.

5.0 STANDARDS

5.1 Product Standards

In order for the system to have a nice feel and look the product standards have to be followed to produce understandable, pleasant and attractive display. Therefore the following standards will be followed by ORAC to give a product of quality:

Windows Standard User Interface – Follow MSDN Rules.

Microsoft SQL Standard – Supports for Better Compliance and Manageability improved.

5.2 Process Standards

The back-end coding that is being used in the system to do functionalities also has to be assessed in a SQAP. The following will be used as process standards for qualifying the ORAC system:

The development process will be carried out according to Rapid Application Development Methodology.

The Model used for developing database is the relational database.

PHP and JQuery coding and name standards will be used in writing the code (Indenting, variable names,...).

Unit Testing, Usability Testing, Integration Testing, Acceptance Testing, Ad-hoc Testing, Gorilla Testing and Install/Uninstall Testing will be used as testing practices.

5.3 Standards to be considered

5.3.1 Coding Standards

The PHP coding Standard was followed by ORAC so as to provide a system with clean and understandable lines of codes and allows the developer to have better structured sets of codes. The following table shows the coding standards used for ORAC.

5.3.2 User Interface Standards

The User Interface Standard to be followed by ORAC is the Windows User Interface Standard. The following table shows the Windows User Interface Standard to be followed.

5.3.3 IEEE Standards

Standards pertaining to IEEE will be used in all documents being produced for ORAC. These include the SRS, SDD, CMP and SVVP. In order for ORAC to achieve an international standard, all the documents related with ORAC, has to conform with IEEE standards.

5.3.4 Checklist Standards

All the checklists used in auditing and review for ORAC have been designed based on the IEEE and have been given in the Review and Auditing section.

6.0 COACHING AND MENTORING ACTIVITIES

Each task will take place in an organized way to ensure the timely delivery of the product. Coding, test cases and user documentation will take place according to the scheduled plan to meet development schedule. On a weekly basis, the developer will cross check his own work to ensure the correctness and meeting the planned required deliverables.

7.0 REVIEWS AND AUDITS

7.1 Work Product Reviews

Work Product

When to carry out Quality Assurance

How Reviewed by Quality Assurance (Standards or Method)

Code

Weekly

Conformance to coding Standards

Test Cases

After Development

Conformance to Requirements Specifications

Test Results

After Execution of Tests

Re Run Tests

User Documentation

Upon Completion

Conformance to Program Logic and Use Cases Paths

User Interface

Upon Completion

Standard: Windows UI

7.2 Process Reviews

Process to Review

When Reviewed by Quality Assurance

(Status or Criteria)

How Reviewed by Quality Assurance

Development Process

Weekly

Meeting with Mr. Debashish

Testing Process

After completion of testing

Meeting with Mr. Debashish

7.3 Quality Assurance Progress Reviews

The Quality Assurance progress reviews will be conducted on weekly basis during the meetings with the quality assurance team.

7.4 Quality Assurance Lessons Learned Review

The lessons learned of the Quality Assurance activities will be gathered as part of the project’s lessons learned activities.

7.5 Independent Review of Quality Assurance

Independent reviews of the Quality Assurance activities will be done by Mr. Debashish.

7.6 Schedule of Quality Assurance Activities

Activity

Date(s) of Execution

Code Review

Every week starting on 28/3/2013 to 14/7/2013

Test Cases

14/6/2013

Test Results

After Code Review

User Documentation

14/6/2013 – 24/7/2013

User Interface

Included in Code Review

7.7 SRS Audit Checklist

The SRS audit checklist allows the quality assurance team to verify all the different components that are essential in order to ensure the top quality of the software.

7.8 SDD Audit Checklist

It is a means of verifying whether all the design considerations required have been taken into consideration while preparing the SDD for ORAC. The Audit Checklist for ORAC has been given as follows:

8.0 TESTING

The different testing methods to be used in ORAC have been given in the following sections and are going to be used to test each and every part of ORAC. The detailed justifications for use have also been included.

8.1 Unit Testing

Unit Testing will be carried out to see whether each component that has been included meets the requirement as stated in the requirement and planning section. This enable the developer to know which deliverable has been missed out and which component is not functioning as described. This is very helpful because each and every component shall be tested and is functioning properly.

8.2 Integration Testing

It is a logical extension of Unit Testing whereby the modules are tested as a whole instead of every little component in each module. This is necessary because the link established between any two components cannot be tested through unit testing. For example, when the staff uploads the details of a new vehicle, the user has to be able to view the vehicle on his screen when he logs in.

8.3 Usability Testing

In this test, the system will be tested in a real time mode, whereby some students will be given staff designation while some will register as customer and try to make the necessary transactions. This is carried out to know how much satisfied the users are with the system and how well the application works. It also serves to debug small remaining errors in the system.

9.0 FEEDBACK AND REPORTS

Reports contain the recommended actions for correction or improvement. Copies of scheduled and unscheduled audits and reviews will be kept by Software Quality Assurance. The reports will be carried to the developer, responsible for producing the software deliverable.

Software Quality Assurance status is updated monthly. The content of this report will identify items produced by the Software Quality Assurance functions, audits, reviews, and tests accomplished during the reporting period.

Problem reporting is used when software deliverable is released with numeric or alphabetic revision. Anytime when a problem is found in the released revision, a Software Problem Reports will be used.

10.0 PROBLEM REPORTING AND CORRECTIVE ACTION

All problems will be reported and tracked. Each problem will be assigned a unique tracking number. Problems will start in an open state. Once resolved, the problem will be marked as closed and the resolution and corrective actions will be recorded. All problem entries and changes should be time and date stamped.

Developer or reviewer will write the initial review version of requirements and design. In case of disagreement between the reviewers and the owner, a special meeting is assigned, where the all points of conflicted parts are covered and agreement upon the final version of the document is reached.

In the code review, developer makes the initial review version as a text-file. This document must be revised by other developers or reviewers. In case of disagreement between the reviewers and the owner, a special meeting is assigned, where all conflicts are resolved and agreement upon the final version of the document is reached. On the basis of this document the source code must be modified by the code owner and checked by the reviewer for its compliance with the final code review version.

11.0 TOOLS, TECHNIQUES, AND METHODS

It identifies the special software tools, techniques, and methods employed to support quality assurance, state their purposes, and describe their use for ORAC.

9.1 Tools

9.2 Techniques

.

9.3 Methodology

The methodology used for ORAC System is James Martin’s RAD. The RAD is a software methodology which is used in projects where the time is limited and all the requirements need to be met. The "key objective of this method is for fast development and delivery of a high quality system at a relatively low investment cost in a limited time". Moreover, it allows the system to be broken down into different smaller segments, providing more ease-of-change during the development process.

12.0 QUALITY ASSURANCE MEASURES

To provide control over the development process and quality assurance the following measures are used:

Measures for

How

Completion

The completion of the code is reviewed once every week in order to convey the plan and the percentage of completion should be calculated.

Time

The process of development should be in the exact time according to the plan and the delay time should be calculated and the iteration plan will adopt these changes.

Audits Result

The result of the audit will be noted and the suggested changes are to be done in the next iteration.

Test coverage

The test cases coverage will be measured and the important portion of software will be tested more.

Code Review

Code will be reviewed every week and the applicability with Microsoft .NET Framework Design Guidelines standard will be evaluated.

13.0 SUPPLIER CONTROL

No plan will be made for supplier Quality Assurance since the software used for designing the system are from branded companies such as Oracle, therefore there is no need to make Quality Assurance Plans for suppliers.

14.0 RECORDS COLLECTION, MAINTENANCE AND RETENTION

All defects found during the testing phase are recorded and kept. During the project implementation, Netbeans debugger is used to locate the error.

Also Audit notes contain the recommended actions for correction or improvement will be collected during the development time. Moreover, Audit, change, interview, and review logs will also be kept by the developer for future reference.

These records will be used by the developer to improve the quality of the product and most of these records will be converted to new tasks so as to provide a bug free system.

15.0 TRAINING

No special training needed for this system. The Quality Assurance Officer is already well acquainted with the Software Quality Assurance and can well monitor the project. As for the users of this system, they can use it as any normal website, but it will only has an international standard in terms of quality.

16.0 RISK MANAGEMENT

RISK CHECKLIST

CHARACTERISTICS

LOW RISK

MEDIUM RISK

HIGH RISK

The business benefit of the project is:

Well defined



Poorly defined

The scope of the project is:

Well defined



Poorly defined

The business customer commitment level is:

Passionate and enthusiastic



Passive and hard to engage

The Project Manager has:

Similar experience on multiple projects



Little experience on similar projects

The project team is:

Located together



Dispersed at multiple sites

Project management processes and procedures are:

Familiar and will be utilized



Not familiar and will not be utilized

The business requirements of the project are:

Understood and straightforward



Very vague or very complex

The system availability requirements include:

Windows of availability and downtime



Available on a 24 X 7 basis

The technical requirements are:

Similar to others in the company



New and complex

The data requirements are:

Simple



Complex

The number of locations to deploy to is:

One



More than four

The number of system interfaces are:

One or none



More than five

The number of organizations this will impact is:

One or two



More than five

The total estimated effort hours are:

Less than 1,000 hours



Greater than 5,000 hours

The total estimated project duration is:

Less than three months



Longer than one year

The subject matter is:

Well-known by the project team



Not well-known by the project team

The project is dependent on:

Zero or one outside project or team



Three or more outside teams or projects

Business processes, procedures, policies require:

Little or no change



Substantial change

Changes to the organizational structure require:

Little or no change



Substantial change

The technology being utilized consists of:

Existing software, hardware, languages, databases and tools.



New software, hardware, languages, databases or tools (or new releases)

The quality of current data is:

Well defined and simple to convert



Poor or complex to convert

The Risk Checklist provided on the previous page, outlines all the statements that should be answered to before moving ahead with the project. Part of the risk management plan is given below: