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
