Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Safety and Criticality  Homepage  

  SI. Sicherheit und Kritikalitšt

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

    Criteria catalogues for the safety summarize corresponding sets of assessment criteria for the security part of a System, depending on the defined security-relevant level. This defined level determines the evaluation with regard to effectiveness and correctness.

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

    The requirements to the first three categories are directly met by the regulations of the V-Model. The requirements with regard to methods, tools and organizational measures are met within the scope of the procedures described in the V-Model, since they are specified in the corresponding planning documents and can thus be realized under supervision.

    SA.2 Criticality Handling

    In the V-Model, the term "criticality" refers to the incorrect behavior of an observation unit. Both physical observation units-these are the products System, Segment, SW Unit/HW Unit, SW Component, SW Module, Database-and logical observation units exist-as there are functions (system function, segment function, unit function). In order to define the criticality level not only the physical observation unit but also the corresponding environment must be taken into consideration. For example, in the case of incorrect behavior of the software of an IT System, all potential effects must be taken into consideration, those that have an effect on the System itself and those that, as a result, shall have an effect on the environment.

    SA.2.1 Allocation of Criticality

    The criticality of an observation unit is defined in levels (criticality levels). The more serious the expected direct and indirect effects of incorrect behavior, the higher the level.

    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

    Table SA.1: Definition of Criticality for Technical Systems

    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.

    Table SA.2: Definition of Criticality for Administrative Information Systems

    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.

    Table SA.3: Definition of Criticality for Real-time Applications

    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

    In the course of the development, observation units are constantly improved. In this connection, the criticality levels are inherited from the System to the system function (product function), from the system functions to the Segments (function product), from Segment to segment functions and from here via the SW Units/HW Units to the functions of the SW Units/HW Units and finally to the SW Components, SW Modules and Databases.

    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

    In optimal critical paths, the required security and dependability cannot be improved by increasing the criticality of other functions. Thus, the measures connected with the corresponding criticality levels can be realized directly and with special care. These measures are of a constructive or analytical nature. They are intended to increase the dependability and security in different ways: Generally expressed, the measures can be applied both for the hardware or the material function units (e. g. from the circuits to the devices) and for the software (e. g. from procedures to processes).

    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,

    Figure SA.1
    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 punto punto punto  
    Preliminary Design with HOOD punto punto punto  
    Detailed Design with HOOD PDL punto punto punto  
    Detailed Design with VDM (algebraic) punto      
    Adhering to Programming Rules XYZ punto punto punto punto
    Structured Programming punto punto punto punto
    Using a Validated Compiler punto punto punto  

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

    Table SA.4: Example of a Criticality/Methods Matrix

    Links to the V-Model Mailinglist

    Mail 0343 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0341 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0340 - Kritikalitaet u. Qualitaetsstufen
    Mail 0198 - Re: IT-Sicherheitskonzept (198)
    Mail 0167 - Re: Kritikalitaet im Finanzbereich (167)

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