High Dependability Computing Program Modeling Dependability(14)

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

FA: The adjustments and extensions concern the Software component of the Framework:

Adverse conditions are defined as invalid inputs or stressful environment

conditions.

o LD: Correctness system implementation precisely satisfies its requirements and/or design specifications [Boehm03]. FA: The adjustments and extensions concern the Software component of the Framework:

Correctness failures are introduced and defined as improper system state

alterations.

Again, the previous analysis reveals, that the Hardware component of the framework is stable across the various definitions of the various dependability attributes, whereas the Software component of the framework is flexible enough to accommodate the necessary adjustments and extensions.

2.3 UMD to capture stakeholders dependability needs

As illustrated in Figure 4, UMD permits the transfer of the stakeholders’ focus from the very abstract concepts of dependability and its attributes to the more concrete and manageable concepts of failure, hazard, event and scope.

abstract

level

concrete

level

Figure 4. Making the “dependability definition” problem more concrete Transfer of thedependability definitionproblem:Stakeholder deals withdependability at a moreconcrete level

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

So, while for a stakeholder it could be difficult to define dependability, or to provide a clear definition of what a dependability attribute means for a specific system, it could be easier to specify which failures the system should not have. Put another way, the UMD-Hardware component reduces the complexity of the problem, so that the stakeholders, rather than dealing with abstract entities (dependability and its attributes), can organize their thoughts about dependability by defining the characterization of the failures (e.g., failures types, and availability impact), and the hazards (e.g., hazards types and severity) that should not affect the system, together with the possible triggering external events (e.g., events types). So, for example, stakeholders will express their views of performance of the system, or a service, by specifying the characteristics of the performance failures that should be avoided. Similarly, stakeholders will define the system or service’s security, by specifying first what possible attacks the system could face, and then identifying the resulting failures that should be avoided. For example, a stakehoder could recognize as possible attacks the “denial of service attacks”, and then specify the characteristics of the possible resulting performance failures that the system should avoid. During this process, UMD-Software component provides stakeholders with useful guidance: they can use the characterization already available, or, whenever necessary, extend it with their own definitions or with other definitions available in literature. For example, a stakeholder could:

Use the same types of failures already present in the framework. That is, they could use the existing definition which states that a “performance failure is the departure of the system behavior from providing the desired static or dynamic capability”, and then declare that: “Service X should not manifest performance failures”.

Use the same types of failures but provide different definitions. That is, they could say that a “performance failure is a failure in response time or throughput“, and then state that: “Service X should not manifest performance failures”.

Introduce more specific failures types, that is, state that a “response time failure is when the system reacts too slowly to a user input”, and then that: “Service X should not manifest response time failures”.

Introduce templates for failures definitions (maybe designed for specific classes of systems). That is, stakeholders could introduce the template “response time failure is when the system fails responding within xx seconds”, then declare that “a response time failure is when the system fails responding within 2 seconds”, and finally state that “Service X should not manifest response time failures”.

As shown in Figure 5, UMD can be seen as an experience base that supports the stakeholders while building a specific system dependability model: a) the knowledge embedded in UMD can be customized and provides guidance while eliciting the specific context needs, then b) the new knowledge acquired while building the system dependability model can be extracted, and, finally, c) analyzed and packaged for reuse in UMD.