Ensuring Software Reliability

Ann Marie Neufelder

• Publisher: CRC Press
• Year: 2018
• Print ISBN: 9780824787622
• eBook ISBN: 9781351833646
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Ingeniería computacional

Explains how software reliability can be applied to software programs of all sizes, functions and languages, and businesses. This text provides real-life examples from industries such as defence engineering, and finance. It is aimed at software and quality assurance engineers and graduate students.

PART I

Introduction to Software
Reliability

CHAPTER 1

Introduction

This book addresses four essential areas of software reliability:

1. Measurement and analysis

2. Development techniques for reliable software

3. Improvement of the process

4. Management of the process

Figure 1.1 illustrates the major components of a reliable software development process and therefore the topics that will be addressed by this book.

Originally, in the early and mid-1970s, software engineering principles were researched in order to project scheduling and staffing requirements for software development. Then the focus shifted toward measuring and predicting software fault counts. Recently the emphasis has shifted toward measuring the process and the product as well as the fault counts.

Many articles and books available today concentrate on only one or possibly two of the four topics listed earlier. Each of the four topics described in this book is dependent on the other three, to a great extent, to be successfully implemented. Measurement and analysis do not serve much of a purpose unless there is an improvement process for which to use those measurements. The software cannot be improved unless there are development techniques for doing so. This whole process cannot be optimized with respect to cost and time without management of the measurement, analysis, improvement, and development methodologies, and the procedures, resources, and schedule. Measurements and analyses are necessary in order to indicate to both management and development the state of the product and the process.

Figure 1.1 Major components of a software development process.

1.1 MEASUREMENT AND ANALYSIS OF SOFTWARE RELIABILITY

The measurement and analysis techniques include software metrics, software reliability models, and software analyses such as fault trees and failure modes effects and criticality (FMECA). Software metrics are measures of some aspect of the software product or process itself. Software reliability models, for the most part, model the failures occurring because of the software. Software analyses enable development personnel to find errors in the software while the software is still in a laboratory environment.

There are many types of software metrics and reliability models. Some of these metrics and models have been shown over time to be invalid. For example, in the 1970s the most commonly used metric was errors per executable source lines of code. Over time, however, it has been found that this metric is not as valuable or valid as originally thought (at least not in many circumstances); see Chapters 4 and 7 for more on this.

Software models and metrics are most useful when used in conjunction with each other and when used during the most appropriate phase or phases of the life cycle. It is not effective to use all existing metrics, nor it is effective to use the incorrect metric. Chapters 7 and 8 discuss which metrics and models to use and when.

It is necessary that metrics and models be used and chosen discriminately. There are some metrics that should be used in every project, such as distribution of error types and total error counts; however, some metrics should only be used if there is reason to believe that the metric will expose some valuable information that will improve the development process. Software reliability models should also be used discriminately because the assumptions of each model vary and may not fit the characteristics of a given software project. A common mistake when implementing some of the reliability models is to adjust the development environment to fit the model instead of finding the model that fits the development environment.

Software analyses will determine some potential sources of error and should be used while designing, coding, and testing the software. Analyses may also be used to prevent critical errors from becoming faults. Software engineers as well as reliability or systems engineers may use these analyses. The results of a fault tree analysis or FMECA will probably be unique to every person who performs it. Some organizations have a software engineer and a systems or reliability engineer perform the analyses so that more than one viewpoint is represented. Chapter 11 discusses these analyses. The author has found that if resources permit, this can be an effective way to detect severe errors before they have manifested themselves in a real environment.

Software measurement and analysis should not necessarily be performed by an independent organization or department. We explore how different metrics, models, and analyses are used by software developers, managers, reliability engineers, systems engineers, and other personnel involved in the process. Software measurement and analysis should not be an isolated part of the process. It must be integrated into the process to be successful.

1.2 DEVELOPMENT TECHNIQUES FOR RELIABLE SOFTWARE

In this book development techniques are techniques used in every phase of the life cycle, from concept to maintenance. The techniques discussed in this book are for the design, code, unit test, integration test, acceptance test, maintenance test, and maintenance phases. These techniques include:

1. Requirements tracing and translation to design and code

2. Design methodologies

3. Code methodologies

4. Unit testing methodologies

5. System testing methodologies

6. Inspections and walkthroughs

7. Error prevention and fault tolerance

Versions of each of these techniques have been shown to be effective in reducing errors and improving maintainability and reliability. Chapters 5, 9, 10, and 11 discuss these.

It has been shown in many studies that modular, structured design and code are less prone to errors than code that is not modular or structured. The design, code, unit test, system test, and maintenance techniques discussed are based on these principles. There exist methods of unit testing and system testing that most effectively cover the most source code and the most functionality. There are also methods for performing more effective walkthroughs and inspections in order to detect errors before they occur. Many of the more costly errors are those that may be found by inspection before they become costly. Fault tolerance may be achieved at various levels depending on the software being developed. All software may be fault tolerant with respect to error and input/output (I/O) checking. Some mission-critical software or systems may require redundancy to achieve the required level of system availability.

1.3 IMPROVING THE PROCESS

The improvement process is the feedback from measurement to development. It depends on using the right metrics at the right time and being able to interpret the results of those metrics in a timely enough fashion to impact the end product. It is an ongoing process that never ends. The improvement depends on:

1. Ability to implement the correct measurements and correctly interpret outputs of that measurement.

2. Efficiency of the measurements used; ability to produce results in a practical amount of time with practical amounts of resources.

3. Interface between individuals and groups responsible for developing, measuring, analyzing, and managing the software. A clear definition of tasks is required to develop and improve the software.

4. Ability to make necessary changes to the development process and respond to the results of the measurements within a practical and reasonable time period in order to improve the software.

5. Ability to continue to repeat steps 1 through 4. The cycle does not end. It can and should be continued from one project to the next.

1.4 MANAGEMENT OF THE PROCESS

Management is performing tradeoffs of software design parameters including reliability, scheduling personnel effectively, and implementing procedures for measurement, development, and improvement. There are some software metrics that were intended to aid management decisions. Some of these management indicators are the estimated projected number of errors to exist after some period of time, the estimated cost of each corrective action, the estimated time required to detect some number of errors, and the average turnaround time for error corrections.

SUMMARY

Development of reliable software is dependent on each of the following:

1. Correct selection and usage of metrics, models, and analyses

2. Correct interpretation of the results of metrics, models, and analyses

3. Feedback from measurement and analysis results to the development process in a practical period of time

4. Response to measurement results to improve the development process

5. Development techniques and methodologies that optimize reliability and maintainability as well as other design parameters or quality factors

6. Interfacing between personnel to perform the required tasks necessary to measure, analyze, develop, and improve the software with respect to reliability

7. Implementation of the necessary procedures for accomplishing these tasks

8. Scheduling of personnel and resources to optimize for the necessary design parameters, including reliability

9. Keeping the measurement and analysis, development, improvement, and management process going

We will see in each of the following chapters how to measure, analyze, develop, improve, and manage for reliable software.

CHAPTER 2

Defining Software Reliability

What is software reliability? Software reliability is a relatively new concept, and although industry and government have been making efforts to standardize it, to date, no one definition of software reliability nor one method of measuring or predicting software reliability is accepted as standard. There are many models and metrics available today for estimating software reliability and measuring characteristics of software. Some of these models have been invalidated, some are currently being validated, and some have been shown to be valid during some phases of the life cycle but not others. The question remaining today is whether or not it is possible for one model to be standardized for all applications, or whether a combination of models is appropriate. There is also a question of whether or not it is feasible to predict the reliability of software before it is even developed.

This chapter addresses the definition of software reliability, how software can be unreliable, why software reliability is important today, and the cost of unreliable software.

2.1 SOFTWARE RELIABILITY DEFINITIONS

Some of the most commonly accepted definitions of software reliability follow.

The Institute of Electrical and Electronic Engineers (IEEE) defines ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication
• Table of Contents
• About the Series
• Preface
• PART I: INRODUCTION TO SOFTWARE RELIABILITY
• PART II: MEASURING SOFTWARE RELIABILITY
• PART III: IMPROVING SOFTWARE RELIABILITY
• PART IV: MANAGEMENT OF SOFTWARE RELIABILITY
• Index