A methodology for architecture-level reliability risk analysis

Abstract

The process of risk assessment is useful in identifying complex modules that require detailed inspection, estimating potentially troublesome modules, and estimating testing effort. According to NASA-STD-8719.13A [20] risk is a function of: the possible frequency of occurrence of an undesired event, the potential severity of resulting consequences, and the uncertainties associated with the frequency and severity. The defines several types of risks, for example, availability risk, acceptance risk, performance risk, cost risk, schedule risk, etc. In this study, we are concerned with reliability-based risk, which depends on the probability that the software product will fail in the operational environment and the adversity of that failure.For the purpose of this work, we adopt the definition in [23], which defines risk as a combination of two factors: probability of malfunctioning (failure) and the consequence of malfunctioning (severity). The probability of failure depends on the probability of existence of a fault combined with the possibility of exercising that fault. Whereas a fault is a feature of a system that precludes it from operating according to its specification, a failure occurs if the actual output of the system for some input differs from the expected output [36]. It is difficult to find exact estimates for the probability of failure of individual components in the system. Therefore, in this study we use quantitative factors that have been proven to be correlated with the probability of faults in the development of software components, such as complexity factors [18]. Moreover, to account for the probability of a fault manifesting itself into a failure, we use dynamic metrics. Dynamic metrics are used to measure the dynamic behavior of a system based on the premise that active components are sources of failures [34]. A fault may not manifest itself into a failure if never executed. Therefore, it is reasonable to use measurements obtained from executing the system models to perform risk assessment and analysis 1 . To study the second factor in the risk definition, the consequence of a failure (severity), we apply the MIL_STD 1629A Failure Mode and Effect Analysis [7].Risk assessment can be performed at various development phases. Architecture models abstract design and implementation details and describe the system using compositions of components and connectors. A component can be as simple as an object, a class, or a procedure, and as elaborate as a package of classes or procedures. Connectors can be as simple as procedure calls or as elaborate as client-server protocols, links between distributed databases, or middlewares. We envisage that risk assessment at the architecture level is more beneficial than assessment at later development phases. An early detection and correction of problems is much less costly than detection at the code level. The architecture of a software is critical to

Prioritizing Program Elements: A Pretesting Effort to Improve Software Quality

“…Researchers [31,32] are accepting these selection of linear scale values for the severity classes. The damage may be classified into different classes as mentioned above or it may be quantified into money value, whatever the analyst feels better.…”

Probabilistic Risk Assessment for Security Requirements: A Preliminary Study

“…In a security C&A process, our probabilistic risk assessment is motivated by the following needs to: 1) Make the process of risk assessment more explicit and systematic to support better decisions under uncertainty; 2) Make risk assessment techniques be based on probabilistic metrics that can be evaluated systematically with little involvement of subjective measures from domain experts [34]; 3) Classify the relevant risk components and map their causal relationships to concepts in the domain-specific taxonomies of threats, assets, vulnerabilities, and countermeasures modeled in the PDO; 4) Use BBN to represent and model uncertainty among dependability requirements in C&A process then, analyze causal relationships and impacts qualitatively and quantitatively among different risk components; and 5) Automatically generate BBN according to the given risk assessment scenarios. Also, our probabilistic risk assessment approach has the following benefits: 1) Different stakeholders can have an explicit and common understanding of the risk assessment process and the decision rationale; 2) Every phase of risk assessment process is arguable and can be re-evaluated based on the common understanding; and 3) Simulation is possible through sensitivity analysis to show how different risk components are related to and impacted by each other.…”

Genetic algorithm based software integration with minimum software risk

“…In large hierarchical systems, a system is composed of several subsystems, which in turn, are composed of components. The system risk is an aggregate of individual component risk factors [10,18]. Risk = frequency × severity (11)…”

“…For example, assuming that the frequency of failure for each line code is 10 -5 per year, the frequency of failure for a 1000 lines code component is computed to be about 0.01 per year. This estimating method was adopted by other researchers as well [10]. For the companies that are using shrink-wrapped software in which the LOC is not known, other…”

“…The Software Engineering Institute (SEI) deals with software risk on a high/medium/low (H/M/L) basis. Some researchers [9,10] used quantitative factors such as complexity factors, connection factors, and severity indices for the estimation of software risk. The more complex the software is, the higher the probability that it will have faults.…”