Basic Concepts of Software Quality

Defining Quality

Presenter

Ambili P K
1

Introduction
In this section, we will discuss quality from the perspective of the customer as well as the producer.

A successful project
The success of a project is usually measured along the
following three axes: Schedule: Was the project delivered on time? Cost: Did the project stay within budget? Quality: Was the product of good quality?

The role of quality in a successful project

Most of the times, software project managers tend to focus on the schedule and the cost and just hope the quality will be okay. This is because the schedule and the cost can be easily measured and, therefore, any slippage in these attracts immediate attention from the management. Project managers and software engineers get so busy meeting budgets and deadlines that quality takes a backseat. Also, because software quality is not visible and measured, problems do not become obvious until they are extremely difficult to correct.
4

What do customers want?

They may even be able to forgive a project that delivers software at a cost that was higher than projected. But no customer will ever forgive poor quality.

Customer perspective of quality

A product is built to meet customer requirements. These requirements are of the following two types: Explicit: What the customer states specifically

Implicit: What the customer does not specify but expects

Quality is more than conformance to specifications

A producer considers a product as a quality product when it meets all the specifications given by the customer.
For software, a process is established to assist the producer in moving from the initial statement of requirements to the final product.

The better the process, the more likely it is that quality will be achieved. Therefore, software producers should always strive to improve the process so that the product created conforms to the specifications.

A process-centric view of quality

A 'process-centric' view of quality by saying that a good process is likely to result in good quality.

Today, the focus of quality gurus is on achieving total quality. Most of the organizations are, therefore, adopting the approach of Total Quality Management, often referred to as TQM.

Other viewpoints on quality

According to ISO (ISO 9000:2000), quality is the degree to which a set of inherent characteristics fulfills the requirements. IEEE (Std 610.12-1990) has defined quality as: The degree to which a system, component, or process meets specified requirements The degree to which a system, component, or process meets customer or user needs or expectations

Some key points on quality

Although various people have defined quality differently, all viewpoints share the same core concepta quality product must meet the specifications and fulfill customer requirements. Some key points from various definitions of quality are as follows. Meeting explicit as well as implicit customer requirements

Continually improving the software process

Removing defects throughout the process Developing a product that is fit for use
10

Some key points on quality

11

Basic Concepts of Software Quality

Software Quality Factors

12

Introduction
Software professionals, such as project managers, software engineers, and the people who support the development of industry-grade software, want to develop high-quality software products.

13

What is software quality?

Some leading experts in the field of software quality have defined quality in terms of factors such as low defect levels, good reliability, fitness for use, maintainability, and so forth. These factors collectively help us describe what good quality should be for a specific product.

14

What are software quality factors?

To build quality software products, the quality requirements of a product need to be clearly defined so that software engineering can aim to achieve them. The quality requirements of a product being developed can be specified in terms of the quality factors. Using the framework of quality factors, a project manager decides which quality factors are relevant for a particular software product. Clear understanding of the quality requirements enables project managers to focus software engineering activities towards meeting these requirements.
15

Categories of quality factors

The quality factors are grouped into three broad categories. Product operation - Refers to the operational characteristics of a product or how well a product operates Product revision - Refers to the extent of ease in changing or revising product, that is, its modifiability, to ensure that it remains useful Product transition - Refers to the ease in the transition from one environment to another or how adaptable a product is to a new environment

16

What is product operation?

The product operation category includes factors that help us to
understand the operational characteristics of a product. The factors in this category are: Correctness Reliability Efficiency Integrity Usability These factors help in determining how well a product works from the user's perspective. They impact how the user feels about operating the product in a given environment with the current functionality.
17

Product operation: Correctness

Correctness is the extent to which specifications are met and the customer's mission objectives are fulfilled. IEEE, in its definition of correctness, is concerned with the degree to which a system or component is fault free, meets specified requirements as well as user needs and expectations (whether specified or not). Correctness includes aspects such as consistency and completeness.

18

Product operation: Reliability

Reliability as the extent to which we can expect a product to perform the intended function with the required precision. A product that keeps failing because defects surface is not reliable.

19

Product operation: Efficiency

Efficiency determines how efficiently the computing resources and code are used. Poor efficiency in the use of computer resources affects the performance of a system under peak loads and can lead to user inconvenience due to degraded performance, and inability to cope with peak loads. The following are some examples of what we can consider while assessing efficiency. Usage of processor time, memory, and disk storage Speed of access to network resources Ability to interact smoothly with other systems
20

Product operation: Integrity

Integrity determines how safe the software and data are from unauthorized access. It is necessary to protect a system from inadvertent damage or deliberate mischief and crime. Therefore, only authorized people within a defined scope of activities should be given access to the system Poor integrity leads to virus attacks, loss of privacy of data, and computer crimes.

21

Product operation: Usability

The effort required to learn, operate, prepare input, and interpret output of a program Users can easily prepare the input for such products and understand the generated outputs. Usability is one of the quality factors that helps in determining how well the product works from a user's point of view. Usability plays an important role in situations where users need to interact with products, especially if there are many users with different profiles and training them is not possible or desirable.
22

Perception of usability
The perception of usability is subjective and is often dependent on the types of users, their background, and their experience with the product that is to be used. The various aspects to be considered while determining 'usability' in a particular context are: The type of users Costs Tradeoffs between the training required before using a product and ease of its use

23

What is product revision?

The product revision category of framework includes the factors that contribute to ease in revising a product. These are: Maintainability Testability Flexibility If a product cannot be revised easily, then: Enhancements cannot be made to meet the changing requirements. Defects cannot be fixed or are very costly to fix. Any changes made might add more defects. Any changes made might be difficult to verify.
24

Product revision: Maintainability

Maintainability means the effort required to locate and fix defects.

25

Possible measures for maintainability

Maintainability is affected by the way a product is developed. It is difficult when the code is complex, does not include comments, and is non-modular in design. Some of the possible measures for maintainability are: The average time taken to fix a problem The percentage of fixes made correctly

26

Product revision: Testability

Testability means the effort required to execute tests to ensure that the product meets the required functionality. Testing is done during development and whenever a product is revised. It is particularly important during revision, because each change in a product must be tested before it is released. Testing involves the following: Identifying test cases Designing and executing tests Checking the actual test results against the expected results
27

Product revision: Flexibility

Flexibility means the extent of difficulty in modifying an operational program. A good design is typically flexible. Well-designed modular programs are easier to modify.

28

What is product transition?

The product transition category includes factors related to the ease of moving software to another environment. These are: Portability Reusability Interoperability The factors in this category are concerned with how well a product supports possible transition. Transitioning may be required for various reasons.

29

Product revision: Maintainability

McCall defines reliability as the extent to which we can expect a product to perform the intended function with the required precision. A product that keeps failing because defects surface is not reliable. More pragmatically, it is extremely frustrating to use. Inability or difficulty in transitioning means the product is no longer available.

30

Product transition: Portability

McCall defines reliability as the extent to which we can expect a product to perform the intended function with the required precision. A product that keeps failing because defects surface is not reliable. More pragmatically, it is extremely frustrating to use.

31

Product transition: Portability

Portability means the effort required to transfer a program from one hardware or software environment to another. It may be necessary to port a program from one environment to another for various reasons. For example, an organization may be shifting the hardware/software platform or may need to execute the software product on multiple hardware/software platforms. Another reason may be that the existing platform has become obsolete or is no longer supported. If a product that needs to be ported cannot be ported, it becomes useless. It is, therefore, important to check whether portability is a relevant factor for a product.
32

Product transition: Reusability

Reusability is the extent to which a program or its parts can be reused in other applications. While designing a product for reuse, the following aspects should be considered. Modularity - Modularity enables reuse. Component design - The components should be designed such that they can be reused for various applications. Documentation - Good documentation is necessary to be able to understand possible reuse. Libraries of components and a search facility - Libraries enable acquiring of the appropriate component for reuse.
33

Product transition: Interoperability

McCall defines interoperability as the effort required to couple one system to another. Interoperability is concerned with the exchange of data and services between systems.

34

Types of relationship between quality factors

The relationship between two quality factors is of the following types: Indifferent: The quality factors do not affect each other. Complementary: The quality factors work in the same direction. Conflicting: An increase in one quality factor reduces the other.

35

Measuring quality factors

Quality cannot be measured directly. However, it is possible to measure quality indirectly. McCall's framework is useful for such measurement. This framework has: Software quality factors that are management-and useroriented Software-oriented attributes or criteria Metrics for these attributes The framework is also called F-C-M (factor-criteriametric) because of this structure.

36

Difference between errors and defects

Defects are the problems that are found either by the customer or by the software professionals after a product has been delivered. These are the problems that the customer encounters or can encounter. Defects lower the customer perspective on product quality. We use the term 'error' for the problems that are found using formal processes but are detected before the delivery of a product to the customer.
37

Categories of metrics for quality

There are two broad categories of metrics that can be used for quality. These are: Technical metrics After-the-fact metrics

38

After-the-fact metrics
After-the-fact metrics are based on the measures made at the end of a project. They are simple summary metrics and are usually relatively easy to collect. They are based on the measures visible to managers and do not require technical insight into the process.

39

Technical metrics enable action in time

Technical metrics are based on measures of the technical attributes of a product made by software engineers as part of the software process. Technical metrics provide a good understanding of the technical quality of the product while it is being made. Software engineers use technical metrics to improve the way they work and to create better design and code.

40

41