Previous Next V-Model Official Homepage by IABG  
Header  
8.2.8.1 SW Architecture (SwArc)  

  SW-Architektur

Contents  
  • Introduction
  • Document Index
  • Document Structure
  • Links to the V-Model Mailinglist
  • Introduction

    The SW Architecture (preliminary design) contains proposals for possible SW architectures and for the selected decomposition of the SW Unit: dynamically into individual processes, statically into SW Components, SW Modules, and Databases. The interrelations among processes, SW Components, SW Modules, and Databases are illustrated. Furthermore, the external and internal interfaces of the SW Unit are identified and, finally, the allocation to the requirements is made.

    Such a product exists for each SW Unit.


    Document Index

    1. General Information
    2. Solution Proposals
    3. Modularization/Database Design
          3.1. Overview of SW Components, SW Modules, Processes and Databases
          3.2. Individual Descriptions
                3.2.m. SW Component/SW Module/Process/Database (m)
          3.3. Dynamic Sequence Model
          3.4. Criticality of the SW Components/SW Modules/Processes/Databases
          3.5. Other Design Decisions
    4. Interfaces
          4.1. External Interfaces of the SW Unit
          4.2. Internal Interfaces of the SW Unit
    5. Requirements Allocation

    Document Structure

    1. General Information

    See schema 1. General Information.

    2. Solution Proposals

    This chapter includes a description and the following evaluation of possible SW Unit architectures.

    The solution proposals for the SW Unit architecture are outlined. They roughly describe the decomposition of the SW Unit into processes as well as into SW Components, SW Modules, and Databases.

    For each solution proposal, individual advantages and disadvantages (e. g. with regard to the interface complexity, usability of off-the-shelf products) as well as the feasibility will be illustrated. The selection of one of the solution proposals is documented and justified.

    3. Modularization/Database Design

    The modularization describes the static decomposition of a SW Unit into SW Components and SW Modules as well as the real-time-specific connections. Furthermore, this chapter includes a preliminary design of the Databases (if available) of the SW Unit.

    3. 1. Overview of SW Components, SW Modules, Processes and Databases

    All SW Modules, processes, SW Components, and Databases are listed, together with their identifications and a long name. A graphical representation should be selected as well (tree) to illustrate the "exists of" hierarchy.

    3. 2. Individual Descriptions

    3. 2. m. SW Component/SW Module/Process/Database (m)

    The SW Component/the SW Module/the process/the Database is defined by a performance specification (purpose and function) and by the utilized resources (CPU, memory, peripherals, processors).

    If relevant this also contains the allocation of the SW Component/the SW Module to the process to be realized.

    Note: "m" is used for consecutive numbers of individual descriptions from 3.2.1 to 3.2.n and as place holder for the identifier of the SW Component, the SW Module, the process, or the Database, according to the conventions for identification defined in the CM Plan.

    3. 3. Dynamic Sequence Model

    This chapter describes the dynamic interrelations of processes. Graphical methods are best suited for the representation.

    This chapter also describes the mechanisms and concepts made available by the runtime environment and during the realization of the processes.

    3. 4. Criticality of the SW Components/SW Modules/Processes/Databases

    A criticality level is allocated to each SW Component/SW Module/process/Database in the form of a table. The criticality level is derived from that of the function realizing the SW Component/the SW Module/the process/the Database.

    3. 5. Other Design Decisions

    This chapter explains other design decisions that have not yet been mentioned before.

    4. Interfaces

    The external interfaces of the SW Unit resulting from the Technical Requirements and the System Architecture and the internal interfaces resulting from the structure of the SW Unit are identified and allocated to the SW Components, SW Modules and Databases.

    This chapter is integrated into the product Interface Overview.

    4. 1. External Interfaces of the SW Unit

    External interfaces are interfaces of the SW Unit to its environment, i. e. to other SW Units or HW Units and to the user.

    4. 2. Internal Interfaces of the SW Unit

    Internal interfaces of the SW Unit are interfaces between SW Components, SW Modules and Databases.

    5. Requirements Allocation

    The relationships to the Technical Requirements will be set up. It must be documented if all requirements for the corresponding SW Unit are covered and how the requirements have been allocated to processes/SW Components/SW Modules/Databases.

    In connection with the requirements allocation, the following items have to be observed:


    Links to the V-Model Mailinglist

    Mail 0685 - SW-Architektur (Grobentwurf) (685)
    Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
    Mail 0524 - Mehrere Fragen zum V-Modell (524)
    Mail 0251 - Midestanforderungen (251)

    Previous Next This page online  •  GDPA Online  •  Last Updated 17.Jul.2003 by C. Freericks