INTRODUCTION

Introduction

Before we make any attempt to define the term, Software Quality Assurance, SQA, we need to understand what each of the terms in software quality assurance. According to IEEE definition of software, it is a computer program, procedure, documentation and data, which pertain in the operation of a computer system. This definition identifies four components of software, which are:

• Computer program (codes)
• Procedures
• Documentation
• Data necessary for operating the software system

Computer software is developed based on the specifications/requirements of the customer under the constraint of a given budget and timeline. Software quality, on the other hand, is the extent to which developed software meets the three criteria of customer requirements, budget and timeline. In order to assure the quality of software, the four components of software are needed for the following reasons:

• Computer programs are needed because they activate the computer to perform a required application.
• Procedures are needed so that the order and schedule in which the programs are performed will be clearly defined, together with the method employed and the person responsible for performing the activity.
• Different types of documentation are needed for developers, users and maintenance personnel. The documentation for developers will contain the requirement reports, design reports, program description etc. The developers’ documentation will enable the development team to efficiently cooperate and coordinate among themselves. The users’ documentation (aka users’ manual) provides a description of the application and the method for the use of the program. The maintenance documentation (aka programmer software manual) provides all the required information that the maintenance team members need about the codes and the structure and task of each software module.
• Data that the software will use to turn into information will be needed. This includes test data, which will identify what kind of software malfunctions can be expected. The test data will also help to confirm that the software has undergone thorough test.

1. Software errors, faults and failures

Software error is an error made by a programmer during programming. This error can be logical error or syntax error. A software error can lead to software fault when the error causes the program to malfunction. However, not all software errors lead to software fault because the error can be corrected or neutralized by subsequent line of code. Software fault become software failure when the piece of program that malfunction as a result of the software error is activated or executed. If it is not activated, the software fault cannot become software failure. This means that not all software faults can become software failure.

1. Causes and classification of software errors

Poor software quality is as a result of software error. Based on the definition of software as codes, procedures, documentations and data, therefore, software error can be classified as code error, procedure error, documentation error and data error. These classes of error are caused by human (system analysts, programmers, software testers, documentation experts and customers or their representatives). Below are the different errors that can be caused in different stage of software development.

1.2.1    Faulty definition of requirements

The faulty definition of requirements, usually prepared by the client, is one of the main causes of software errors. The most common errors of this type are:

■          Erroneous definition of requirements.

■          Absence of vital requirements.

■          Incomplete definition of requirements. For instance, one of the requirements of a municipality’s local tax software system refers to discounts granted to various segments of the population: senior citizens, parents of large families, and so forth. Unfortunately, a discount granted to students was not included in the requirements document.

■          Inclusion of unnecessary requirements, functions that are not expected to be needed in the near future.

1.2.2    Client–developer communication failures

Misunderstandings resulting from defective client–developer communication are additional causes for the errors that prevail in the early stages of the development process:

■          Misunderstanding of the client’s instructions as stated in the requirement document.

■          Misunderstanding of the client’s requirements changes presented to the developer in written form during the development period.

■          Misunderstanding of the client’s requirements changes presented orally to the developer during the development period.

■          Misunderstanding of the client’s responses to the design problems presented by the developer.

■          Lack of attention to client messages referring to requirements changes and to client responses to questions raised by the developer on the part of the developer.

1.2.3    Deliberate deviations from software requirements

In several circumstances, developers may deliberately deviate from the documented requirements, actions that often cause software errors. The errors in these cases are byproducts of the changes. The most common situations of deliberate deviation are:

■          The developer reuses software modules taken from an earlier project without sufficient analysis of the changes and adaptations needed to correctly fulfill all the new requirements.

■          Due to time or budget pressures, the developer decides to omit part of the required functions in an attempt to cope with these pressures.

■          Developer-initiated, unapproved improvements to the software, introduced without the client’s approval, frequently disregard requirements that seem minor to the developer. Such “minor” changes may, eventually, cause software errors.

1.2.4    Logical design errors

Software errors can enter the system when the professionals who design the system – systems architects, software engineers, analysts, etc. – formulate the software requirements. Typical errors include:

■          Definitions that represent software requirements by means of erroneous

algorithms.

■          Process definitions that contain sequencing errors. For example, the software requirements for a firm’s debt-collection system define the debt-collection process as follows. Once a client does not pay his debts, even after receiving three successive notification letters, the details are to be reported to the sales department manager who will decide whether to proceed to the next stage, referral of the client to the legal department. The systems analyst defined the process incorrectly by stating that after sending three successive letters followed by no receipt of payment, the firm would include the name of the client on a list of clients to be handled by the legal department. The logical error was caused by the analyst’s erroneous omission of the sales department phase within the debt-collection process.

■          Erroneous definition of boundary conditions. For example, the client’s requirements stated that a special discount will be granted to customers who make purchases more than three times in the same month. The analyst erroneously defined the software process to state that the discount would be granted to those who make purchases three times or more in the same month.

■          Omission of required software system states. For example, a real-time computerized apparatus is required to react according to a combination of temperatures and pressures. The analyst did not define the needed reaction when the temperature is over 120°C and the pressure is between 6 and 8 atmospheres.

■          Omission of definitions concerning reactions to illegal operation of the software system. For example, in a computerized theater ticketing system operated by the customer with no human operator interface, the software system is required to limit the sales to 10 tickets per customer. Accordingly, any request for the purchase of more than 10 tickets is “illegal”. In his design, the analyst included a message stating that sales are limited to 10 tickets per customer, but did not define the system’s reaction to the case where a customer (who might not have listened carefully to the message) keys in a number higher than 10. When performing the illegal request, a system “crash” is to be expected as no computerized reaction was defined for this illegal operation.

1.2.5    Coding errors

A broad range of reasons cause programmers to make coding errors. These include misunderstanding the design documentation, linguistic errors in the programming languages, errors in the application of CASE and other development tools, errors in data selection, and so forth.

1.2.6    Shortcomings of the testing process

Shortcomings of the testing process affect the error rate by leaving a greater number of errors undetected or uncorrected. These shortcomings result from the following causes:

■          Incomplete test plans leave untreated portions of the software or the

application functions and states of the system.

■          Failures to document and report detected errors and faults.

■          Failure to promptly correct detected software faults as a result of inappropriate indications of the reasons for the fault.

■          Incomplete correction of detected errors due to negligence or time pressures.

            1.2.7    Procedure errors

Procedures direct the user with respect to the activities required at each step of the process. They are of special importance in complex software systems where the processing is conducted in several steps, each of which may feed a variety of types of data and allow for examination of the intermediate results. For example, “Eiffel”, a chain of construction materials stores, has decided to grant a 5% discount to customers, who are billed once a month. The discount is offered to customers whose total purchases in the last 12 months exceed $1 million. Nevertheless, Eiffel’s management has decided to withdraw this discount from customers who returned goods valued in excess of 10% of their purchases during the last three months. The chain’s billing system is decentralized, so that every store processes the monthly invoices independently. Table 2.1 presents a comparison of correct and incorrect procedures regarding application of the discount.

1.2.8    Documentation errors

The documentation errors that trouble the development and maintenance

teams are errors in the design documents and in the documentation integrated into the body of the software. These errors can cause additional errors in further stages of development and during maintenance. Another type of documentation error, one that affects mainly the users, is an error in the user manuals and in the “help” displays incorporated in the software. Typical errors of this type are:

■          Omission of software functions.

■          Errors in the explanations and instructions given to users, resulting in

“dead ends” or incorrect applications.

■          Listing of non-existing software functions, that is, functions planned in

the early stages of development but later dropped, and functions that

were active in previous versions of the software but cancelled in the current version.

1.3    Definition of software quality and software quality assurance

            IEEE has provided these two definitions of software quality.

1. The degree to which a system component or process meets specified requirements.
2. The degree to which a system components or process meets customer or user needs or expectations.

Similarly, IEEE has provided two definitions of SQA as follows:

1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.
2. A set of activities designed to evaluate the process by which the products are developed or manufactured.

The IEEE definitions of SQA focus on the development process. It did not include the maintenance process. The definitions also focus on technical requirements, without any emphasis on financial requirement (budget constraint) and time requirement (timeline). As a result of these limitations of IEEE definitions of SQA, there is need for an expanded definition of SQA.

The expanded definition of SQA states that SQA is a systematic, planned set of activities necessary to provide adequate confidence that the software development process or the maintenance process of software system product conforms to established functional technical requirements as well as managerial requirements of keeping to the schedule and operating within the budgeting confines.

1. Differences between SQA and SQC

Software Quality Control, SQC, according to IEEE is a set of activities designed to evaluate the quality of developed or manufactured product, with the aim of with-holding the delivery of that product, if it does not attain a certain level of quality. This means that SQC takes place before the product or service is delivered to the customer. It does not take place after the product or service is delivered to the customer. On the other hand, the aim of SQA is to prevent the causes of error during the development and maintenance of the product. It detects and corrects the error early in the development/maintenance stage. Therefore, SQA reduces the rate that a product will not qualify for delivery to the client.

1. Objectives of SQA activities

The following are the objectives of SQA activities that are performed during the development and maintenance of software product.

• Assuring an acceptable level of confidence that the development and maintenance of the software will conform to functional technical requirements.
• Assuring an acceptable level of confidence that the development and maintenance of the software will conform to managerial scheduling and budgetary requirements.
• Initiating and managing of activities for the improvement and greater efficiency of software development/maintenance and SQA activities.