System Architect study note _ Chapter 2 (ii) _ serialization

13.2 software reliability modeling

13.2.1 factors affecting Software Reliability

Software Reliability Model refers to the Reliability block diagram and mathematical Model established to predict or estimate the Reliability of Software.

The model divides the reliability of a complex system into the reliability of a simple system, so that the reliability of a complex system can be quantitatively estimated, allocated, estimated, and evaluated.

Major factors affecting Software Reliability: Defects introduction, discovery, and removal.

The introduction of defects mainly depends on the features of the software products and the features of the software development process.

Defect discovery relies on the running section.

Defect Removal relies on investments in failure discovery, repair activities, and reliability.

The main factors affecting software reliability are as follows:

1. Run the section (Environment ).

2. Software scale.

3. Internal software structure.

4. Software development methods and development environment.

5. Software Reliability investment. Manpower, capital, resources, and time.

In the early days, software reliability was emphasized and measures were taken to develop the software. The reliability was significantly improved.

13.2.2 software reliability modeling method

The reliability model usually consists of the following parts:

1. Model hypothesis. The model is simplified or normalized in actual situations and always contains several assumptions.

2. Performance measurement. The output of the software reliability model is the performance measurement.

3. parameter estimation method.

4. data requirements.

Most models have three common assumptions:

1. Representative assumptions. Select the actual running section of the software.

2. independence hypothesis. It is assumed that software failure occurs independently at different times.

3. Same-Sex hypothesis. It is considered that all software failures have the same consequences (levels), that is, the modeling process only considers the specific occurrence time of software failures, and does not distinguish the software failure severity levels.

If a new error is detected during the prediction, or the repair action causes the new fault to occur continuously, the prediction should be stopped. Otherwise, this change will reduce the applicability of the model because of increasing the complexity of the problem.

A good software reliability model should have the following important features:

1. reliability-based assumptions.

2. Simple.

3. Calculate some useful quantities.

4. provides a good ing of future failures.

5. It can be widely used.

13.2.3 software reliability model classification

Reliability models can be roughly divided into the following 10 categories:

1. Seed method model.

The number of errors in the program is estimated using capture sampling techniques repeatedly, and some preset "Seeds" are intentionally "seeding" in the program ", then, the number of residual errors in the program is estimated based on the ratio of the original errors and the induced errors found.

The advantage is that it is easy to implement, but the disadvantage is that it is difficult to estimate the category between the "seed" of the error and the actual original error.

2. Failure Rate Model.

3. Curve Fitting Model.

The method of regression analysis is used to study software complexity, number of defects, failure efficiency, and failure interval, including parameter method and non-parameter method.

4. Reliability Growth Model.

5. program structure analysis model.

Through the reliability of each node, the reliability of Inter-node conversion, and the probability of Inter-node network conversion, the overall reliability of the program is obtained.

6. input domain classification model.

7. Run the path analysis method model.

8. Non-second Poisson process model.

NHPP, which uses the number of failures per unit time during software testing as an independent Poisson random variable to predict the number of accumulated failures at a certain time point of use of the software in the future.

9. Markov process model.

10. Bayesian model.

The reliability of the software is evaluated using the pre-test distribution of the failure rate and the current test failure information.

When the software reliability engineer has a full understanding of the software development process, the software has a good inheritance of Reliability Analysis Model with good results.

Time Domain.

Number of failures: whether the number of failures is limited or not.

Number of failures.

Finite class: Function Form of the failure intensity expressed in time.

Infinite class: A function form that represents the failure intensity using the expected number of failures.

13.2.4 software reliability model example

1. Model hypothesis

The basic assumptions of the JM model are as follows:

1. The number of initial errors is an unknown constant.

2. When an error is found, it is immediately completely ruled out, and no new error is introduced. The exclusion time is ignored and not recorded. Therefore, 1 is required after each troubleshooting.

3. The remaining error count is proportional to the failure rate.

2. function expression.

.

The software reliability model is not mature. quantitative analysis methods and mathematical models must be verified and corrected continuously in practice.

Different types of software have different application methods.

13.2.5 Software Reliability Test Overview

The reliability test consists of the determination of the reliability target, the development of the running section, the design of the test case, the test implementation, and the analysis of the test result.

The impact on software development progress and cost must also be considered for software reliability testing. It is best to be completed by a professional testing organization in a controlled automatic testing environment.

13.2.6 define the software running section

The arc is used to connect the State and indicate the conversion caused by various incentives. The conversion probability is allocated to each arc.

Each type of user may use the system in different ways.

There are two types of hierarchy: user-level hierarchy and usage-level hierarchy.

Usage-level hierarchy depends on what the system can do in the test state.

User-level hierarchy considers various types of users and how they use the system.

These Probability Estimates are mainly based on the following aspects:

1. Data collected from the existing system.

2. Information obtained from conversations with users or observations.

3. Results of prototype usage and test analysis.

4. opinions of experts in related fields.

13.2.8 Implementation of Reliability Testing

It is necessary to check whether the software requirements and documents are consistent and the accuracy, integrity and consistency of documents formed during software development.

Reliability Testing depends on software testability.

To obtain more reliable data, you should use a multi-state computer to run software at the same time to increase the cumulative time.

Software reliability data defined by time is divided into four types:

1. Failure Time data.

2. Failure interval data.

3. invalid data within the group time.

4. The cumulative number of failures of the Group time.

These four types of data can be converted to each other.

The test process must be recorded in a real way. Each test record must contain the following information:

1. test time.

2. test instructions or identifiers containing test cases.

3. All test results related to the test, including failure data.

4. testers.

After the test, you must compile the software reliability test report with the following content:

1. software product identification.

2. test environment configuration (hardware and software ).

3. test basis.

4. Test results.

5. Test the problem.

6. test time.

13.3 Software Reliability Assessment

13.3.1 Software Reliability Evaluation Overview

Estimate the current reliability of the software to determine whether the testing can be terminated and the software can be released. It is also possible to predict the time and workload required for the software to reach the corresponding reliability level, check the consistency between software execution and requirements.

13.3.2 how to select a reliability model

You can compare and select from the following aspects:

1. Applicability of model assumptions.

2. ability and quality of prediction.

3. Whether the model output value can meet the reliability evaluation requirements.

The most important quantitative metrics for reliability that require accurate estimation include:

1. Current reliability.

2. Average failure time.

3. fault density.

4. date to reach the specified reliability target.

5. Meet the cost requirements for the specified reliability objectives.

4. Simplicity of model Use

Simplicity generally includes the following three meanings:

1. The data required by the model is easy to collect, and the cost cannot exceed the budget of the reliability plan.

2. The model should be easy to understand. testers will not spend too much time studying professional mathematical theories.

3. The model should be easy to use.

13.3.3 collection of Reliability Data

After analyzing the test data generated by the defect-oriented reliability test, we can obtain very valuable reliability data, which depends on the defined running section and the selected test case set.

Reliability Data is collected throughout the entire software lifecycle.

Some feasible methods are as follows:

1. determine the reliability model as soon as possible.

2. Specify a highly feasible and reliable data collection plan, designate a person in charge, and collect and record reliability data according to unified specifications.

3. sort out and analyze the testing data generated by software testing, especially reliability testing.

4. Make full use of the database to store and analyze reliability data.

13.3.4 evaluation and prediction of software reliability

1. Determine whether the reliability target is achieved.

2. If it fails to be reached, how much time, manpower, and capital will be invested.

3. After the software system has been put into operation for a certain period of time, can it reach the level of reliability for delivery or some delivery users.

Reliability cannot be estimated without failure.

Statistical techniques and techniques should be run outside the model to analyze the reliability data and supplement, improve, and correct the reliability model.

The auxiliary method is as follows:

1. Graphic Analysis Method of invalid data.

1. accumulate the number of failures.

2. The number of failures in a unit of time.

3. Failure interval graph.

2. information useful for reliability Analysis by the Exploratory Data Analysis technology (EDA) is as follows:

1. Loop-related.

2. The number of failures has increased sharply in the short term.

3. Time period in the invalid number set.

13.4 Software Reliability Design and Management

13.4.1 Software Reliability Design

Practice has proved that the most effective, economical, and important means to ensure software reliability is to take measures for reliability control in the software design stage.

1. Software Reliability Design is part of software design and must be used in the overall design framework of the software and cannot conflict with other design principles.

2. The software reliability design aims to improve and ensure the software reliability on the premise of meeting the requirements for improving the software quality.

3. The software reliability design should determine the software reliability objectives, and should not be infinitely expanded. This should be considered after the functional level, user requirements, and development costs.

Fault Tolerance Design, error detection design, Complexity Reduction design, and other technologies.

1. Fault Tolerance Design Technology

1. Recover the block design. If the text fails, replace it with the backup text.

2. Version N Program Design. A majority of voting is performed on the operation results with the same initial conditions and input to prevent faults of a software module/version from providing incorrect services.

Pay attention to the following two aspects:

Make the Software Requirement Description complete and accurate.

Non-relevance of the entire design process.

3. Redundancy Design

In the same running environment, where one set of software fails, the other set will certainly fail.

In addition to a complete software system, a module or system with different paths, algorithms, or implementation methods is designed as a backup.

The fee may be twice the software development fee for a single version, and may also increase the storage space, memory consumption, and running time for the software runtime, A compromise must be made between the reliability requirement and the extra cost.

2. Error Detection Technology

The cost of error detection is generally lower than that of fault tolerance and redundancy. However, an obvious disadvantage is that the fault cannot be automatically solved.

It focuses on several elements: detection objects, detection latency, implementation methods, and processing methods.

3. Design with Reduced Complexity

The module complexity mainly includes two aspects: Internal data stream direction and program length. The structural complexity is expressed by the degree of association between different modules.

Software complexity is an important source of Software defects.

Designers should consider reducing software complexity and improving software reliability.

On the basis of ensuring the implementation of software functions, the software structure is simplified, the program code length is shortened, the software data flow direction is optimized, and the software complexity is reduced, so as to improve the software reliability.

13.4.2 Software Reliability Management

In order to further improve the software reliability, the concept of software reliability management is proposed, and the software reliability activities are carried out throughout the whole process of software development.

Objectives, plans, progress, tasks, and corrective measures of reliability activities at various stages.

Because of the large differences between software, each of the following activities is not a must for the reliability management of each software system, nor is it all the content of software reliability management.

List omitted.