Previous Next Functional Tool Requirements Homepage  
Configuration Management Submodel  
SCM01 - Supporting Configuration Planning and Control  

  LKM01 - Konfigurationsplanung und -kontrolle unterstü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


    CM2.2 - Configuration Initialization

  • Configuration Identification Document (CID)
  • CM2.4 - Configuration Update

  • Configuration Identification Document (CID)
  • Method


    2 Brief Characteristics

    This service unit defines the requirements for tools used to

    3 Requirements

    3.1 Requirements for Interfaces

    SCM01.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.
    SCM01.I.2 Input interface to SCM02 - Version Management It is possible to transfer versions of storage objects from SCM02 without further transformation in order to be integrated into the configuration planning and control.
    SCM01.I.3 Output interface to SOM01 - Creating, Storing, Administration of Data Structures and Data of the SDE It is possible to file information about configuration structures and baselines as storage objects in SOM01.

    3.2 Requirements for the Methods Support


    3.3 Requirements for Functions

    SCM01.F.1 Representation of configurations
    SCM01.F.1.1 Hierarchy It is possible to handle hierarchical structures.
    SCM01.F.1.2 Network It is possible to handle non-hierarchical (network-oriented) structures.
    SCM01.F.1.3 Document structure It is possible to represent complex text documents by means of structured subdocuments.
    Certain text documents (e. g. manuals) are configuration objects which, based on their size or inhomogeneity, require the manipulation in small units, both for generation and for later administration. The utilization of subdocuments in other configurations as well (redundancy-free) may be a further reason.
    SCM01.F.1.4 Relations It is possible to relate configuration object to other configuration objects.
    This applies both for complex and elementary configuration objects, in particular for references to configuration objects that are not included in the storage system, e. g. hardware and devices.
    SCM01.F.1.5 Variable relation It is possible to handle variable relations between objects in a configuration structure.
    SCM01.F.1.6 Configuration attributes It is possible to equip the configuration and all configuration objects with various additional information individually addressable.
    Example: Description of the characteristics/features of a version, its characteristic differences to previous versions or to functionally equal variants; references about the reason the version was generated; reference to the change documents.
    SCM01.F.1.7 Product attributes It is possible to represent the product attributes requested by the V-Model.
    The attributes represent information to be stored but not have to be handled as "attribute" in the physical sense.
    SCM01.F.1.8 Baselines It is possible to define baselines.
    All products of a project belonging to a certain baseline are related to each other.
    SCM01.F.1.9 Number The number of possible configuration objects and versions is not limited.
    SCM01.F.2 Presettings and controls
    SCM01.F.2.1 Configuration structure The definition of the structure and the structure elements of a configuration prior to their existence is possible.
    It must be possible to specify the structure of a configuration and to establish it in the tool before the versions (contents) are actually entered.
    SCM01.F.2.2 Change authorization The change of a structure is controlled by means of authorizations.
    SCM01.F.2.3 Reproducibility The change of a structure is reproducible.
    SCM01.F.2.4 Value range It is possible to assign a value range to the attributes. It is also possible to control that the value range is complied with.
    SCM01.F.2.5 CID validity The validity of the Configuration Identification Document (CID) is controlled.
    Updating the CID can be realized either automatically or manually. In the case of manual updates the entries can be checked against the available, accepted configuration objects; on the other hand, the CID can be controlled when the status of a configuration object is changed.
    SCM01.F.2.6 Generation It is possible to generate a product from its parts.
    This requires that storage and administration of documents is realized in parts.
    SCM01.F.2.7 Partial configuration It is possible to transfer parts of a configuration to another configuration.
    Generation characteristics are certain versions or variants, textual representation, transmission to other tools.
    SCM01.F.2.8 Multiple use It is possible to use identical configuration objects in different configurations.
    This is done to reduce administration and maintenance effort since identical configuration objects in one configuration family do not have to be multiply maintained.
    SCM01.F.3 Differences
    SCM01.F.3.1 Structural differences It is possible to represent structural differences of configurations.
    Finding out structural differences must be realized by the tool itself in any case since only this tool has access to the required data.
    SCM01.F.3.2 Differences in attributes It is possible to represent the differences in attributes (description, attributes, status data, administration data).
    Finding out the differences must be realized by the CM tool itself in any case since only this tool has access to the required data.
    SCM01.F.4 Requirements with Regard to the Handling
    SCM01.F.4.1 Navigation A navigation function is available for the fast retrieval of information.
    The current position in the structure is to be made visible by representing the path from the entry down to the objects below the current version.
    SCM01.F.4.2 Configuration graph It is possible to graphically represent the configuration structure.
    SCM01.F.4.3 Configuration overview It is possible to represent the entire configuration in the form of an overview.
    SCM01.F.4.4 Current authorizations It is possible to get an overview of the authorizations for a version of a configuration.
    SCM01.F.4.5 Overview of states It is possible to get an overview of the states within a version of a configuration.
    SCM01.F.4.6 Libraries It is possible to administer libraries as objects.
    This way the manipulation of libraries can be realized under tool control.
    SCM01.F.4.7 Control of delivery
    SCM01.F.4.7.1 Delivery versions Deliveries are administrated as versions.
    A delivery has special accompanying data, e. g. addressee, installation, date of delivery, release (version number, variant), date of acceptance, references to problem reports, etc.
    SCM01.F.4.7.2 Reproducibility Each delivery is reproducible.
    It must be possible to control which user of the configuration has received a copy of a version, not only because of the administration of problem reports and the required delivery of new releases (revisions, versions).

    3.4 Other Requirements

    SCM01.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.
    SCM01.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.
    SCM01.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