IEEE 1633-2008 pdf download

IEEE 1633-2008 pdf download.IEEE Recommended Practice on Software Reliability
Software reliability (SR) models have been evaluated and ranked for their applicability to various situations. Many improvements have been made in SR modeling and prediction since 1992. This revised recommended practice reflects those advances in SR since 1992, including modeling and prediction for distributed and network systems. Situation specific usage guidance was refined and updated. The methodologies and tools included in this recommended practice are extended over the software life cycle (SLC).
1.2 Purpose
The recommended practice promotes a systems approach to SR prediction. Although there are some distinctive characteristics of aerospace software, the principles of reliability are generic, and the results can be beneficial to practitioners in any industry.
1.3 Intended audience
This recommended practice is intended for use by both practitioners (e.g., managers, software developers/engineers, software acquisition personnel, technical managers, and software quality and SR personnel) and researchers. Researchers are considered to be academics in universities and personnel doing research work in government and industry laboratories It is assumed that users of this recommended practice have a basic understanding of the SLC and an understanding of statistical concepts.
1.4 Applications of software reliability engineering
The techniques and methodologies presented in this recommended practice have been successfully applied to software projects by industry practitioners in order to do the following:
⎯ Assess SR risk
⎯ Indicate whether a previously applied software process is likely to produce code that satisfies a given SR requirement
⎯ Provide a measure for software design process improvement evaluation and software quality
⎯ SR assessment procedures (i.e., measure current software reliability)
⎯ Data collection procedures to support SR estimation and prediction
⎯ Determine when to release a software system, or to stop testing the software and make improvements
⎯ Calculate the probability of occurrence of the next failure for a software system, and other reliability metrics
⎯ Identify elements in a software system that are leading candidates for redesign to improve reliability
⎯ Indicate software maintenance effort by assessing SR
⎯ Assist software safety certification
1.5 Relationship to hardware reliability
The creation of software and hardware products is alike in many ways and can be similarly managed throughout design and development. While the management techniques may be similar, there are genuine differences between hardware and software (see Kline [B36], Lipow and Shooman [B39] 1 ). Examples are as follows:
⎯ Changes to hardware require a series of important and time-consuming steps: capital equipment acquisition, component procurement, fabrication, assembly, inspection, test, and documentation. Changing software is frequently more feasible (although effects of the changes are not always clear) and often requires only testing and documentation.
⎯ Software has no physical existence. It includes data as well as logic. Any item in a file can be a source of failure.
⎯ One important difference is that hardware is constrained by physical law. One effect is that testing is simplified, because it is possible to conduct limited testing and use knowledge of the physics of the device to interpolate behavior that was not explicitly tested. This is not possible with software, since a minor change can cause failure.
⎯ Software does not wear out. Furthermore, failures attributable to software faults come without advance warning and often provide no indication they have occurred. Hardware, on the other hand, often provides a period of graceful degradation.
⎯ Software may be more complex than hardware, although exact software copies can be produced, whereas manufacturing limitations affect hardware.
⎯ Repair generally restores hardware to its previous state. Correction of a software fault always changes the software to a new state.
⎯ Redundancy and fault tolerance for hardware are common practice. These concepts are only beginning to be practiced in software.
⎯ Hardware reliability is expressed in wall clock time. SR may be expressed in execution, elapsed, or calendar time.IEEE 1633 pdf download.IEEE 1633-2008 pdf download