SI. Sicherheit und Kritikalität

Contents		SA.1 Safety Handling SA.2 Criticality Handling Links to the V-Model Mailinglist

SA.1 Safety Handling

From the point of view of the development process the following can be deduced:

• requirements for the existence of certain products
• requirements for the content and the characteristics of these products
• requirements for the assessment of these products
• requirements for methods/tools, development
• requirements for the allocation of roles and the connected organizational measures

SA.2 Criticality Handling

SA.2.1 Allocation of Criticality

The criticality levels illustrated in Table SA.1 can be regarded as general definition for technical systems.

Criticality	Type of Incorrect Behavior
high	incorrect behavior may cause the loss of human lives
medium	incorrect behavior may endanger human health or destroy material goods
low	incorrect behavior may damage material goods without, however, endangering human health
none	incorrect behavior does not endanger human health nor material goods

For software, the definition of criticality depends on the application. The definition of criticality for software, like the number of levels, must always be project-specific, by estimating the direct and indirect effects of a possible incorrect behavior.

In administrative information systems, incorrect behavior is not expected to endanger human lives. The criticality levels of Table Table SA.2, for example, might be applied for a specific project.

Criticality	Type of Incorrect Behavior
high	Incorrect behavior makes data accessable for unauthorized persons, or it prevents administrative processes ( paying salaries, allocation of resources) or results in wrong decisions based on faulty data.
low	Incorrect behavior prevents access to information that are required on a regular basis.
none	Incorrect behavior does not essentially impair guaranteed characteristics.

The criticality level in Table SA.3 can be seen as an example for the definition of project-related criticality levels for a real-time application (e. g. air safety).

Criticality	Type of Incorrect Behavior
high	Incorrect behavior that may lead to false positioning information of flight objects on the radar monitor.
low	Incorrect behavior that may lead to the failure of plan data and thus to deleted departures.
none	All other types of incorrect behavior.

Within the application scope of the V-Model, additional quality requirements are derived from a defined criticality level that have to be allocated to the corresponding functionality, i. e. to the corresponding functions and their import interfaces. The definition of the criticality for functions has to be illustrated for the System, for each Segment and for each SW Unit/HW Unit in a criticality/function matrix. In this connection, a certain criticality level is allocated in the form of a matrix to each function. In this a particular criticality level is assigned to each function in a matrix.

SA.2.2 Criticality Inheritance

Since development costs rise together with the criticality level, it is necessary to minimize always the number of critical functions while the system behavior remains the same. High criticality must only be allocated when necessary.

The following rule 1 (inheritance rule) must be applied:

R 1a	Product Function At least one of the functions generated in the above mentioned improvement process must have the same criticality level as the product itself.
R 1b	Function Product At least one product allocated to a function must have the same criticality level as the function during the allocation of functions to the products.

Another rule, R2, refers to the criticality of dependent functions:

R 2a	If two functions influence each other, i. e. if one function uses the capabilities of the other function, then the criticality level of the influencing (used) function must be as high as the one using the function.
R 2b	If two functions influence each other, e. g. by sending signals to and from, they must both have the same criticality level.

The inheritance rule R1 guarantees that a criticality level for a product, once defined, remains in at least one improvement branch during the course of the improvement process. During the design, this is to prompt a designer to localize the criticality estimation as precisely as possible.

Rule R2 is to prompt the designer to minimize the dependencies between the design units. This corresponds to an essential design principle for safe, dependable, and maintainable systems.

SA.2.3 Measures to Prevent Effects of Incorrect Behavior

• constructive measures:
  development of intrinsically or correspondingly error-tolerant function units
• analytic measures:
  realization of comprehensive verification and validation, up to certificate level

While the definition of the criticality level is documented in submodel SD, the allocation of the required measures is handled in activity QA1 - QA Initialization. This requires specifications for the generation and assessment of products. These specifications predominantly consist of the commitment to certain methods, but also comprise tool instructions of how the products are to be generated and assessed. To prevent faulty behavior, it is necessary to specify for each criticality level which measures (applicable methods and/or tools to be applied) are required. This information can best be illustrated in a matrix. Therefore, the generation and assessment specifications with regard to criticality levels are referred to as criticality/methods matrix. This criticality/methods matrix must be documented in the QA Plan.

When defining the project-specific criticality/methods matrix, the contractual agreements and specifications have to be observed, e. g. with regard to certification rules, permission rules, validated tools or diversified developments.

The procedure and the cooperation between SD and QA is illustrated in Figure SA.1. By observing the rules R1 and R2, the criticality of the function units is determined, refined and illustrated in criticality/function matrices in activities SD1 - System Requirements Analysis to SD4 - Preliminary SW Design.

By using the criticality/methods matrix in the QA Plan,

• the design specifications are converted in an activity plan (activities PM1 - Project Initialization, PM4 - Detailed Planning),
• the steps for the design are taken (activities SD1 - System Requirements Analysis-SD6 - SW Implementation),
• assessment specifications are set up (activity QA2 - Assessment Preparation),
• assessments are realized (activity QA4 - Product Assessment),
• assessed products are integrated (activities SD7 - SW Integration-SD8 - System Integration),
• and integrated SD products are tested (activity QA4 - Product Assessment).

Figure SA.1: SD and QA Cooperation with Regard to Criticality

The following Table SA.4 contains examples for recommendations with regard to the generation of a criticality/methods matrix for software products, by taking into consideration the present state-of-the-art and the state-of-the-art expected for the future. The tables only show the allocation as a suggestion, without consideration of specific application aspects. Thus, in the current case, neither an assessment via C1 test covering for an uncritical function unit can be ruled out, nor is a specification according to strictly mathematical methods for a highly critical function unit obligatory. However, if a specification is made as in the example in Table SA.4, this is binding for the project.

Constructive Quality Assurance Methods (Generation Methods)	Criticality Level
	high	medium	low	none
SW Requirements with SADT
Preliminary Design with HOOD
Detailed Design with HOOD PDL
Detailed Design with VDM (algebraic)
Adhering to Programming Rules XYZ
Structured Programming
Using a Validated Compiler

Analytical Quality Assurance Methods (Assessment Methods)	Criticality Level
	high	medium	low	none
Walkthrough
Audit for Activities according to QA Plan
Average C1 Test Coverage of at least 90 %
Average C2 Test Coverage of at least 90 %
Informal Assessment according to Assmtl. Specification
Correctness Check Code versus Detailed Design
Stat. Analysis with regard to maintaining Prog. Rules XYZ
Simulation

Links to the V-Model Mailinglist

This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks