High Dependability Computing Program Modeling Dependability(15)

Individuals and organizations increasingly use sophisticated software systems from which they demand great reliance. “Reliance ” is contextually subjective and depends on the particular stakeholder’s needs; therefore, in different circumstances, the sta

Figure 5. Building dependability knowledge

2.4 Measuring dependability

Up to now, we have used the UMD to build qualitative definitions of dependability, or, in other terms, to specify the failures and the hazards that we do not want to occur. Although useful, this is only partly valuable, given that failures and hazards will always be likely to happen. For this reason, it is important to introduce the possibility of measuring dependability, allowing the stakeholders not only to identify the undesired failures and hazards for the system or a specific service, but also to quantify what they assume could be tolerable corresponding manifestations. Here, we want to extend the framework to enable the stakeholder to quantify their dependability needs, i.e. to express a measure of dependability.

Built around the elementary concept of issue, the framework can easily address such a need. It is, in fact, possible to introduce the concept of measure as another basic item of the framework, an item whose value defines the manifestation of the Issue.

The resulting framework is illustrated in Figure 6, where the concept of measure has been added to the Hardware component, and its characterization, defining the possible different kinds of measures that the stakeholder can use, has been added to the Software component. As example, we used the following measures types:

Time-based (probabilistic) measures, such as Mean Time to Failure (MTTF),

Probability of Occurrence (in next time unit or transaction).

Absolute measures, such as number of occurrences (in a given time frame).

Ordinal measures, for example by introducing an ordinal scale such as “very

rarely”/”rarely”/”sometimes”.

Thus, structured as in Figure 6, UMD allows the stakeholder to specify, for the whole system or a specific service, the acceptable manifestation of a specific failure or class of failures, together with the triggering events that can cause it (when applicable).

So, for example, stakeholders will express their views of performance of the system, or a service, by specifying the characteristics of the performance failures and then specifying the tolerable manifestation of such failures. In particular, by extending the example in the previous Section, stakeholders will not simply state that “Service X should not manifest response time failures”, but, more precisely, can say that “Response time failures could