Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD18 - Estimating Performances  

  LSE18 - Leistungen abschätzen

  • 1 Allocation to V-Model and Methods Allocation
  • 2 Brief Characteristics
  • 3 Requirements
  •       3.1 Requirements for Interfaces
  •       3.2 Requirements for the Methods Support
  •       3.3 Requirements for Functions
  •       3.4 Other Requirements
  • 1 Allocation to V-Model and Methods Allocation


    SD2.3 - Investigation of Feasibility

  • System Architecture.Feasibility Studies
  • SD5.2 - Analysis of Resources and Time Requirements

  • SW Design (Module).Characteristic Quantities
  • SW Design (Database).Characteristic Quantities
  • Method


    2 Brief Characteristics

    This service unit defines the requirements for tools used to realize an analysis of the performance behavior of Components, Modules and Databases.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD18.I.1 Granularity The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface.
    SSD18.I.2 Input interface to SSD16 - Linking It is possible to integrate code linked with SSD16 without further transformation from the object management in order to estimate the expected performance behavior.

    3.2 Requirements for the Methods Support


    3.3 Requirements for Functions

    SSD18.F.1 Collecting measuring results
    SSD18.F.1.1 Sensors It is possible to instrument that part of the application that is to be analyzed by means of sensors detecting and displaying relevant events.
    Sensors generate measuring records that are further processed by subsequent components of the measuring system.
    SSD18.F.1.2 Measuring quantities It is possible to allocate measuring quantities to events.
    SSD18.F.1.3 Abstraction level It is possible to realize measurements on various abstraction levels.
    Various levels with regard to granularity of measuring quantities result in different volumes of information to be analyzed and thus correspond to a special abstraction level.
    SSD18.F.1.4 Activation/deactivation It is possible to activate and to deactivate sensors at any time.
    SSD18.F.1.5 Handling of results It is possible to allocate an individual event handling routine to each sensor.
    SSD18.F.2 Evaluation of measuring results
    SSD18.F.2.1 Interference The evaluation of the measuring results has no impact on the quantities to be measured, or this impact is known, and the result can thus be corrected.
    The evaluation of the measuring results can cause a loss of performance and inaccurate values. Therefore, the evaluation ought to be realized with separate resources of the measuring system (e. g. on separate hardware).
    SSD18.F.2.2 Collectors It is possible to combine logically connected measuring records of sensors and to generate new measuring records for the following evaluation.
    SSD18.F.3 Representation of measuring results
    SSD18.F.3.1 Evaluator It is possible to convert measuring data into characteristics and to graphically represent them.
    The conversion of measuring data into characteristics allows the representation of the results as pie and bar charts or other graphical forms of representation.
    SSD18.F.3.2 On-line It is possible to get characteristics displayed on-line on screen.
    SSD18.F.3.3 Off-line It is possible to collect characteristics and to evaluate the results off-line.
    SSD18.F.3.4 Display It is possible to select between different forms to represent the characteristics.
    SSD18.F.4 Load generator A load generator is available replacing the natural environment of the whole application or individual parts to be analyzed.
    A load generator is required if the application to be analyzed has the character of a prototype and/or it is not possible to measure the performance under the conditions of production. A load generator is not an actual tool. It may possibly replace part of an application for measuring purposes in order to observe the later behavior of the application in production process.
    SSD18.F.5 Time basis A time basis in sufficient resolution is available.
    The time basis is best realized by a hardware clock.

    3.4 Other Requirements

    SSD18.O.1 Upward compatibility It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality.
    SSD18.O.2 Procedural command language The tool has a procedural command language that can be applied by the user to generate and run macros or procedures.
    SSD18.O.3 Complexity There is no limitation of the complexity caused by the tool itself.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster