basic concepts of software quality

8/2/2019 Basic Concepts of Software Quality

1/41

1

Basic Concepts of Software QualityDefining Quality

Presenter

Ambili P K


2/41

2

In this section, we will discuss quality from the

perspective of the customer as well as theproducer.

Introduction


3/41

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?

3


4/41

4

The role of quality in a successfulproject

Most of the times, software project managers tend to focuson the schedule and the cost and just hope the qualitywill be okay.

This is because the schedule and the cost can be easily

measured and, therefore, any slippage in these attractsimmediate attention from the management.

Project managers and software engineers get so busymeeting 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 extremelydifficult to correct.


5/41

5

What do customers want?

They may even be able to forgive a project that deliverssoftware at a cost that was higher than projected. But nocustomer will ever forgive poor quality.


6/41

Customer perspective of quality

6

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 butexpects
http://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htmhttp://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htmhttp://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htmhttp://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htmhttp://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htmhttp://www.edistalearning.com/Content/Courses/COU250550621747/files/mod7/les01/topic2/l01_020_090.htm


7/41

Quality is more thanconformance to specifications

7

A producer considers a product as a qualityproduct when it meets all the specifications givenby the customer.

For software, a process is established to assist theproducer in moving from the initial statement ofrequirements to the final product.

The better the process, the more likely it is thatquality will be achieved. Therefore, softwareproducers should always strive to improve theprocess so that the product created conforms to

the specifications.


8/41

A process-centric view of quality

8

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

Today, the focus of quality gurus is on achieving totalquality. Most of the organizations are, therefore, adopting

the approach of Total Quality Management, often referredto as TQM.


9/41

9

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

Other viewpoints on quality


10/41

10

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


11/41

11

Some key points on quality


12/41

12

Basic Concepts of Software QualitySoftware Quality Factors


13/41

Introduction

13

Software professionals, such as projectmanagers, software engineers, and the peoplewho support the development of industry-grade

software, want to develop high-quality softwareproducts.


14/41

What is software quality?

14

Some leading experts in the field of software quality havedefined quality in terms of factors such as low defectlevels, good reliability, fitness for use, maintainability, andso forth.

These factors collectively help us describe what goodquality should be for a specific product.


15/41

What are software quality factors?

15

To build quality software products, the qualityrequirements of a product need to be clearly defined sothat 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 managerdecides which quality factors are relevant for a particularsoftware product.

Clear understanding of the quality requirements enablesproject managers to focus software engineering activitiestowards meeting these requirements.


16/41

Categories of quality factors

16

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 remainsuseful

Product transition - Refers to the ease in the transition from

one environment to another or how adaptable a product is to a

new environment


17/41

What is product operation?

17

The product operation category includes factors that help us tounderstand the operational characteristics of a product. The

factors in this category are:

Correctness

ReliabilityEfficiency

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.


18/41

18

Product operation: Correctness

Correctness is the extent to which specifications are metand 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, meetsspecified requirements as well as user needs andexpectations (whether specified or not).

Correctness includes aspects such as consistency and

completeness.


19/41

19

Product operation: Reliability

Reliability as the extent to which we can expect a productto perform the intended function with the requiredprecision.

A product that keeps failing because defects surface is not

reliable.


20/41

20

Product operation: Efficiency

Efficiency determines how efficiently the computingresources and code are used.

Poor efficiency in the use of computer resources affects the

performance of a system under peak loads and can lead touser inconvenience due to degraded performance, andinability 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


21/41

21

Product operation: Integrity

Integrity determines how safe the software and data are fromunauthorized access.

It is necessary to protect a system from inadvertent damageor deliberate mischief and crime.

Therefore, only authorized people within a defined scope ofactivities should be given access to the system

Poor integrity leads to virus attacks, loss of privacy of data,and computer crimes.


22/41

22

Product operation: Usability

The effort required to learn, operate, prepare input, andinterpret 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 indetermining how well the product works from a user's pointof view.

Usability plays an important role in situations where usersneed to interact with products, especially if there are manyusers with different profiles and training them is not possibleor desirable.


23/41

23

Perception of usability

The perception of usability is subjective and is oftendependent on the types of users, their background, andtheir 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 aproduct and ease of its use


24/41

24

What is product revision?

The product revision category of framework includes thefactors that contribute to ease in revising a product. Theseare:

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.


25/41

25

Product revision: Maintainability

Maintainability means the effort required to locate and fixdefects.


26/41

26

Possible measures for maintainability

Maintainability is affected by the way a product isdeveloped. It is difficult when the code is complex, does notinclude comments, and is non-modular in design. Some of

the possible measures for maintainability are:The average timetaken to fix a problem

The percentageof fixes made correctly


27/41

27

Product revision: Testability

Testability means the effort required to execute tests toensure 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 itis released.

Testing involves the following:

Identifying test cases

Designing and executing tests

Checking the actual test results against the expectedresults


28/41

28

Product revision: Flexibility

Flexibility means the extent of difficulty in modifying anoperational program.

A good design is typically flexible.

Well-designed modular programs are easier to modify.


29/41

29

What is product transition?

The product transition category includes factors related tothe 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 berequired for various reasons.


30/41

30

Product revision: Maintainability

McCall defines reliability as the extent to which we canexpect a product to perform the intended function with therequired precision.

A product that keeps failing because defects surface is notreliable. More pragmatically, it is extremely frustrating to use.

Inability or difficulty in transitioning means the product is nolonger available.


31/41

31

Product transition: Portability

McCall defines reliability as the extent to which we canexpect a product to perform the intended function with therequired precision.

A product that keeps failing because defects surface is notreliable. More pragmatically, it is extremely frustrating to use.


32/41

32

Product transition: Portability

Portability means the effort required to transfer a programfrom 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 thehardware/software platform or may need to execute thesoftware product on multiple hardware/software platforms.Another reason may be that the existing platform hasbecome obsolete or is no longer supported.

If a product that needs to be ported cannot be ported, itbecomes useless. It is, therefore, important to checkwhether portability is a relevant factor for a product.


33/41

33

Product transition: Reusability

Reusability is the extent to which a program or its partscan 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 designedsuch 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.


34/41

34

Product transition: Interoperability

McCall defines interoperability as the effort required tocouple one system to another.

Interoperability is concerned with the exchange of data and

services between systems.


35/41

35

Types of relationship between qualityfactors

The relationship between two quality factors is of thefollowing types:

Indifferent:The quality factors do not affect each other.

Complementary:The quality factors work in the samedirection.

Conflicting:An increase in one quality factor reducesthe other.


36/41

36

Measuring quality factors

Quality cannot be measured directly. However, it is possibleto measure quality indirectly. McCall's framework is usefulfor such measurement. This framework has:

Software quality factors that are management-and user-oriented

Software-oriented attributes or criteria

Metrics for these attributes

The framework is also called F-C-M (factor-criteria-metric) because of this structure.


37/41

37

Difference between errors anddefects

Defects are the problems that are found either by thecustomer or by the software professionals after a producthas been delivered.

These are the problems that the customer encounters orcan encounter.

Defects lower the customer perspective on product quality.

We use the term 'error' for the problems that are foundusing formal processes but are detected before the deliveryof a product to the customer.


38/41

38

Categories of metrics for quality

There are two broad categories of metrics that can beused for quality. These are:

Technical metricsAfter-the-fact metrics


39/41

39

After-the-fact metrics

After-the-fact metrics are based on the measures made atthe 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 anddo not require technical insight into the process.


40/41

40

Technical metrics enable action intime

Technical metrics are based on measures of the technicalattributes of a product made by software engineers as partof the software process.

Technical metrics provide a good understanding of thetechnical quality of the product while it is being made.

Software engineers use technical metrics to improve theway they work and to create better design and code.


41/41

basic concepts of software quality

Documents