Program reliability

The reliability and maintenance team will already take precautionary measures, predict failures and prevent them in the first place using proactive approach. These estimations and recommendations are usually the results of continuous feedback from good Research and Development departments of the corporations. That is why having an expert team for the reliability and maintenance program is always a unique feature of any organization that gives it a competitive edge over other firms in the market, saving money and time while adding great value to the productivity of the organization.

Rooted In Reliability podcast is a proud member of Reliability. We encourage you to please rate and review this podcast on iTunes and Stitcher. It ensures the podcast stays relevant and is easy to find by like-minded professionals. It is only with your ratings and reviews that the Rooted In Reliability podcast can continue to grow. Thank you for providing the small but critical support for the Rooted In Reliability podcast!

Software can make decisions, but can just as unreliable as human beings. The British destroyer Sheffield was sunk because the radar system identified an incoming missile as "friendly". Software can also have small unnoticeable errors or drifts that can culminate into a disaster.

On February 25, , during the Golf War, the chopping error that missed 0. Fixing problems may not necessarily make the software more reliable. On the contrary, new serious problems may arise. In , after changing three lines of code in a signaling program which contains millions lines of code, the local telephone systems in California and along the Eastern seaboard came to a stop. After the success of Ariane 4 rocket, the maiden flight of Ariane 5 ended up in flames while design defects in the control software were unveiled by faster horizontal drifting speed of the new rocket.

There are much more scary stories to tell. This makes us wondering whether software is reliable at all, whether we should use software in safety-critical embedded applications.

With processors and software permeating safety critical embedded world, the reliability of software is simply a matter of life and death. Are we embedding potential disasters while we embed software into systems? According to ANSI, Software Reliability is defined as: the probability of failure-free software operation for a specified period of time in a specified environment.

Electronic and mechanical parts may become "old" and wear out with time and usage, but software will not rust or wear-out during its life cycle. Software will not change over time unless intentionally changed or upgraded. Software Reliability is an important to attribute of software quality, together with functionality, usability, performance, serviceability, capability, installability, maintainability, and documentation. Software Reliability is hard to achieve, because the complexity of software tends to be high.

While any system with a high degree of complexity, including software, will be hard to reach a certain level of reliability, system developers tend to push complexity into the software layer, with the rapid growth of system size and ease of doing so by upgrading the software. For example, large next-generation aircraft will have over one million source lines of software on-board; next-generation air traffic control systems will contain between one and two million lines; the upcoming international Space Station will have over two million lines on-board and over ten million lines of ground support software; several major life-critical defense systems will have over five million source lines of software.

Emphasizing these features will tend to add more complexity to software. Software failures may be due to errors, ambiguities, oversights or misinterpretation of the specification that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen problems.

Hardware faults are mostly physical faults , while software faults are design faults , which are harder to visualize, classify, detect, and correct. In hardware, design faults may also exist, but physical faults usually dominate. In software, we can hardly find a strict corresponding counterpart for "manufacturing" as hardware manufacturing process, if the simple action of uploading software modules into place does not count.

Therefore, the quality of software will not change once it is uploaded into the storage and start running. Trying to achieve higher reliability by simply duplicating the same software modules will not work, because design faults can not be masked off by voting.

A partial list of the distinct characteristics of software compared to hardware is listed below [Keene94] :. Over time, hardware exhibits the failure characteristics shown in Figure 1, known as the bathtub curve. Period A, B and C stands for burn-in phase, useful life phase and end-of-life phase. A detailed discussion about the curve can be found in the topic Traditional Reliability.

Software reliability, however, does not show the same characteristics similar as hardware. A possible curve is shown in Figure 2 if we projected software reliability on the same axes. One difference is that in the last phase, software does not have an increasing failure rate as hardware does. In this phase, software is approaching obsolescence; there are no motivation for any upgrades or changes to the software.

Therefore, the failure rate will not change. The second difference is that in the useful-life phase, software will experience a drastic increase in failure rate each time an upgrade is made. The failure rate levels off gradually, partly because of the defects found and fixed after the upgrades.

Figure 2. Revised bathtub curve for software reliability. The upgrades in Figure 2 imply feature upgrades, not upgrades for reliability. For feature upgrades, the complexity of software is likely to be increased, since the functionality of software is enhanced. Even bug fixes may be a reason for more software failures, if the bug fix induces other defects into software. For reliability upgrades, it is possible to incur a drop in software failure rate, if the goal of the upgrade is enhancing software reliability, such as a redesign or reimplementation of some modules using better engineering approaches, such as clean-room method.

A proof can be found in the result from Ballista project, robustness testing of off-the-shelf software Components. Since software robustness is one aspect of software reliability, this result indicates that the upgrade of those systems shown in Figure 3 should have incorporated reliability upgrades.

Since Software Reliability is one of the most important aspects of software quality, Reliability Engineering approaches are practiced in software field as well. Software Reliability Engineering SRE is the quantitative study of the operational behavior of software-based systems with respect to user requirements concerning reliability [IEEE95].

A proliferation of software reliability models have emerged as people try to understand the characteristics of how and why software fails, and try to quantify software reliability. Over models have been developed since the early s, but how to quantify software reliability still remains largely unsolved. Interested readers may refer to [RAC96] , [Lyu95].

As many models as there are and many more emerging, none of the models can capture a satisfying amount of the complexity of software; constraints and assumptions have to be made for the quantifying process.

Therefore, there is no single model that can be used in all situations. No model is complete or even representative. One model may work well for a set of certain software, but may be completely off track for other kinds of problems. Most software models contain the following parts: assumptions, factors, and a mathematical function that relates the reliability with the factors. The mathematical function is usually higher order exponential or logarithmic.

Software modeling techniques can be divided into two subcategories: prediction modeling and estimation modeling. The major difference of the two models are shown in Table 1. Table 1. Difference between software reliability prediction models and software reliability estimation models. Using prediction models, software reliability can be predicted early in the development phase and enhancements can be initiated to improve the reliability.

Representative estimation models include exponential distribution models, Weibull distribution model, Thompson and Chelson's model, etc. The field has matured to the point that software models can be applied in practical situations and give meaningful results and, second, that there is no one model that is best in all situations. Only limited factors can be put into consideration.

By doing so, complexity is reduced and abstraction is achieved, however, the models tend to specialize to be applied to only a portion of the situations and a certain class of the problems. MTBF consists of. Improvement completely depends upon the problems occurred in the application or system, or else the characteristics of the software.

According to the complexity of the software module,the way of improvement will also differ. Two main constraints time and budget, which will limit the efforts are put into the software reliability improvement. Testing for reliability is about exercising an application so that failures are discovered and removed before the system is deployed.

To estimate test-retest reliability, a single group of examinees will perform testing process only a few days or weeks apart. The time should be short enough so that the examinees skills in the area can be assessed. This type of reliability demonstrates the extent to which a test is able to produce stable, consistent scores across time.

Many exams have multiple formats of question papers, this parallel forms of exam provide Security. Parallel forms reliability is estimated by administrating both forms of the exam to the same group of examinees. The examinees scores on the two test forms are correlated in order to determine how similarly the two test forms functions.

This reliability estimate is a measure of how consistent examinees scores can be expected to across test forms. After doing Test-Retest Reliability and Parallel Form Reliability, we will get a result of examinees either pass or fail. It is the reliability of this classification decision that is estimated in decision consistency reliability.

A thorough assessment of reliability is required to improve the performance of software product and process. Testing software reliability will help the software managers and practitioners to a great extent.

Reliability Testing is the important part of a reliability engineering program. More correctly, it is the soul of reliability engineering program.