• Q.3 how can we calculate the raliability of a software?
Answers
Explanation:
Key Concepts
Definition
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. [ANSI91][Lyu95]Although Software Reliability is defined as a probabilistic function, and comes with the notion of time, we must note that, different from traditional Hardware Reliability, Software Reliability is not a direct function of time. 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. [Rook90] While the complexity of software is inversely related to software reliability, it is directly related to other important factors in software quality, especially functionality, capability, etc. Emphasizing these features will tend to add more complexity to software.
Software failure mechanisms
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.[Keiller91] While it is tempting to draw an analogy between Software Reliability and Hardware Reliability, software and hardware have basic differences that make them different in failure mechanisms. Hardware faults are mostly physical faults, while software faults are design faults, which are harder to visualize, classify, detect, and correct. [Lyu95] Design faults are closely related to fuzzy human factors and the design process, which we don't have a solid understanding. 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]:
Failure cause: Software defects are mainly design defects.
Wear-out: Software does not have energy related wear-out phase. Errors can occur without warning.
Repairable system concept: Periodic restarts can help fix software problems.
Time dependency and life cycle: Software reliability is not a function of operational time.
Environmental factors: Do not affect Software reliability, except it might affect program inputs.
Reliability prediction: Software reliability can not be predicted from any physical basis, since it depends completely on human factors in design.
Redundancy: Can not improve Software reliability if identical software components are used.
Interfaces: Software interfaces are purely conceptual other than visual.
Failure rate motivators: Usually not predictable from analyses of separate statements.
Built with standard components: Well-understood and extensively-tested standard parts will help improve maintainability and reliability. But in software industry, we have not observed this trend. Code reuse has been around for some time, but to a very limited extent. Strictly speaking there are no standard parts for software, except some standardized logic structures.
The bathtub curve for Software Reliability
15❤️+follow=inbox