A software product spends more than 65% of its lifecycle in maintenance. Software systems with good maintainability can be easily modified to fix faults. We define maintainability-based risk as a product of two factors: the probability of performing maintenance tasks and the impact of performing these tasks. In this paper, we present a methodology for assessing maintainability-based risk in the context of corrective maintenance. The proposed methodology depends on the architectural artifacts and their evolution through the life cycle of the system. In order to prioritize corrective maintenance tasks, we combine components' maintainability- based risk with the severity of a failure that may happen as a result of unfixed fault. We illustrate the methodology on a case study using UML models.

Development of software systems utilizes only 20%-40% of the overall project cost; the rest is consumed by maintenance. Systems with poor maintainability are difficult to modify and to extend. Maintainability based risk is defined as a product of two factors: the probability of carrying out maintenance tasks and the impact of these tasks. The decision of adopting a single architecture over others should be verified through some pre-implementation analysis. This paper assesses different architectures for process control applications using a maintainability risk analysis. The paper illustrates the methodology using a simple example of a Gas Burner process control system.

The study of software architectures is gaining importance due to its role in various aspects of software engineering, like product line engineering, componentbased software engineering and other emerging paradigms. With the increasing emphasis on design patterns, the traditional practice of ad-hoc software construction is slowly shifting towards pattern-oriented development. Various architectural attributes like error propagation, change propagation, requirements propagation provide a wealth of information about software architectures. In this paper, we show that change propagation probability (CP) is helpful and effective in assessing the design quality of software architectures. We study two different architectures (one that employs patterns versus one that does not) for the same application. We also analyze and compare the change propagation metric with respect to other coupling-based metrics.

Summary form only given. Software architectures are an emerging discipline in software engineering as they play a central role in many modern software development paradigms. Quantifying software architectures is an important research agenda, as it allows software architects to subjectively assess quality attributes and rationalize architecture-related decisions. In this paper, we discuss the attribute of change propagation probability, which reflects the likelihood that a change that arises in one component of the architecture propagates (i.e. mandates changes) to other components.

Component based development is gaining popularity in the software engineering community. The reliability of components affects the reliability of the system. Different models and theories have been developed to estimate system reliability given the information about system architecture and the quality of the components. Almost always in these models a key attribute of component-based systems, the error propagation between the components, is overlooked and not taken into account in the reliability prediction. We extend our previous work on Bayesian reliability prediction of component based systems by introducing the error propagation probability into the model. We demonstrate the impact of the error propagation in a case study of an automated personnel access control system. We conclude that error propagation may have a significant impact on the system reliability prediction and, therefore, future architecture-based models should not ignore it.

The study of software architectures is gaining importance due to its role in various aspects of software engineering such as product line engineering, component based software engineering and other emerging paradigms. With the increasing emphasis on design patterns, the traditional practice of ad-hoc software construction is slowly shifting towards pattern-oriented development. Various architectural attributes like error propagation, change propagation, and requirements propagation, provide a wealth of information about software architectures. In this paper, we show that change propagation probability (CP) is helpful and effective in assessing the design quality of software architectures. We study two different architectures (one that employs patterns versus one that does not) for the same application. We also analyze and compare change propagation metric with respect to other coupling-based metrics.

Performance is a nonfunctional software attribute that plays a crucial role in wide application domains spreading from safety-critical systems to e-commerce applications. Software risk can be quantified as a combination of the probability that a software system may fail and the severity of the damages caused by the failure. In this paper, we devise a methodology for estimation of performance-based risk factor, which originates from violations, of performance requirements, (namely, performance failures). The methodology elaborates annotated UML diagrams to estimate the performance failure probability and combines it with the failure severity estimate which is obtained using the functional failure analysis. We are thus able to determine risky scenarios as well as risky software components, and the analysis feedback can be used to improve the software design. We illustrate the methodology on an e-commerce case study using step-by step approach, and then provide a brief description of a case study based on large real system.

To assist the analysis software architectures, we have developed a Web-based CASE tool that automates the steps of capturing, modeling, and inspection of software architectures, in order to derive and display the change propagation probabilities.

Recent evidences indicate that most faults in software systems are found in only a few of a system's components [1]. The early identification of these components allows an organization to focus on defect detection activities on high risk components, for example by optimally allocating testing resources [2], or redesigning components that are likely to cause field failures. This paper presents a prototype tool called Architecture-level Risk Assessment Tool (ARAT) based on the risk assessment methodology presented in [3]. The ARAT provides risk assessment based on measures obtained from Unified Modeling Language (UML) artifacts [4]. This tool can be used in the design phase of the software development process. It estimates dynamic metrics [5] and automatically analyzes the quality of the architecture to produce architectural-level software risk assessment [3].

Risk assessment is an essential part in managing software development. Performing risk assessment during the early development phases enhances resource allocation decisions. In order to improve the software development process and the quality of software products, we need to be able to build risk analysis models based on data that can be collected early in the development process. These models will help identify the high-risk components and connectors of the product architecture, so that remedial actions may be taken in order to control and optimize the development process and improve the quality of the product. In this paper, we present a risk assessment methodology which can be used in the early phases of the software life cycle. We use the Unified Modeling Language (UML) and commercial modeling environment Rational Rose Real Time (RoseRT) to obtain UML model statistics. First, for each component and connector in software architecture, a dynamic heuristic risk factor is obtained and severity is assessed based on hazard analysis. Then, a Markov model is constructed to obtain scenarios risk factors. The risk factors of use cases and the overall system risk factor are estimated using the scenarios risk factors. Within our methodology, we also identify critical components and connectors that would require careful analysis, design, implementation, and more testing effort. The risk assessment methodology is applied on a pacemaker case study.