Teachers can learn many lessons by examining experiences in teaching SRE to software practitioners and analyzing their feedback. I have taught several thousand participants over 15 years in a wide variety of organizations and applications. Participants included software developers, testers, reliability and quality control staff, and managers. Most of what I've learned applies to any course and is not SRE-specific. It also applies to the practitioners of the future, university students

This paper outlines the nature of the standard, proven, widespread best practice of software reliability engineering (SRE). It is widely applicable, low in cost, and its implementation has virtually no schedule impact. SRE helps one develop and test more reliable software faster and cheaper. We show how it does this, and present some resources that will help one learn more about it.

This paper examines the nature of mobile code and compares it with past software, both in regard to similarities and differences. It then looks at how greater code mobility is likely to effect the practice of software reliability engineering (SRE).

No abstract available.

Failure intensity depends on the operational profile used in executing a system. Operational profiles can change, so we would like to determine the new failure intensity without the expense of actually reexecuting the system under the new operational profile. We derive a transformation for adjusting the failure intensity to the value it would have under the new operational profile. This transformation does not require that we measure operation failure intensities in the field, a requirement that would often be impractical to meet. It is only necessary to know the operational profile used in test; this information is used to estimate the operation failure intensities. The old and new field operational profiles and the estimated operation failure intensities are employed to determine the overall target failure intensity.>

Sensitivity of field failure intensity estimates to operational profile occurrence probability errors is investigated. This is an important issue in software reliability engineering, because these estimates enter into many development decisions. Sensitivity was computed for 59,200 sets of conditions, spread over a wide range. For 99.4% of these points, the failure intensity was very robust with respect to occurrence probability errors, the error in failure intensity being more than a factor of 5 smaller than the occurrence probability error. Thus projects do not have to spend extra effort to obtain high precision in measuring the operational profile, nor do they need to worry about moderate changes in system usage with time.>

Provides an overview of a step-by-step approach for developing the operational profile used in software reliability engineering. The operational profile can help guide managerial and engineering decisions throughout the product life cycle, including requirements specification, design, implementation and testing. It is particularly valuable in guiding test planning and testing. The development and use of this profile typically involves product and market managers and systems engineers. It is used by software developers and managers, system test planners and testers, and quality assurance and reliability engineers. The presented material has been drawn from experience in developing operational profiles for a variety of applications.>

A set of criteria is proposed for the comparison of software reliability models. The intention is to provide a logically organized basis for determining the superior models and for the presentation of model characteristics. It is hoped that in the future, a software manager will be able to more easily select the model most suitable for his/her requirements from among the preferred ones.

The execution time theory of software reliability developed by the author provides measures that offer promise as valuable tools in managing a software project. The measures furnish excellent current status indicators and permit schedule forecasts to be developed. The relationships among reliability, project completion date, project cost, and various resource parameters can be examined through simulation as an aid in making management decisions. Managers have indicated that the conceptual framework provided is valuable in understanding the testing process. Experience has been gained in the use of the theory on a number of projects. A program has been developed to handle most of the calculations.

The theory permits the estimation, in advance of a project, of the amount of testing in terms of execution time required to achieve a specified reliability goal [stated as a mean time to failure (MTTF)]. Execution time can then be related to calendar time, permitting a schedule to be developed. Estimates of execution time and calendar time remaining until the reliability goal is attained can be continually remade as testing proceeds, based only on the length of the execution time intervals between failures. The current MTTF and the number of errors remaining can also be estimated. Maximum likelihood estimation is employed, and confidence intervals are also established. The foregoing information is obviously very valuable in scheduling and monitoring the progress of program testing. A program has been implemented to compute the foregoing quantities. The reliability model that has been developed can be used in making system tradeoffs involving software or software and hardware components. It also provides a soundly based unit of measure for the comparative evaluation of various programming techniques that are expected to enhance reliability. The model has been applied to four medium-sized software development projects, all of which have completed their life cycles.