Previous Next Functional Tool Requirements Homepage  
Configuration Management Submodel  
SCM02 - Version Management  

  LKM02 - Versionen verwalten

  • 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.1 - Product Initialization

    CM2.3 - Product Management



    2 Brief Characteristics

    This service unit defines the requirements for tools used

    3 Requirements

    3.1 Requirements for Interfaces

    SCM02.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.
    SCM02.I.2 Output interface to SCM01 - Supporting Configuration Planning and Control It is possible to transmit versions of storage objects without further transformation to SCM01 in order to be integrated into the configuration planning and control.
    SCM02.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

    SCM02.F.1 Administration of the Configuration Objects
    SCM02.F.1.1 Attributes It is possible to put attributes on configuration objects.
    SCM02.F.1.2 Entry of Attributes The values of the following attributes are automatically entered and displayed: date and time of the generation, name of the person in charge, and name of the owner.
    SCM02.F.2 Identification of the configuration objects
    SCM02.F.2.1 Identification It is possible to uniquely identify configuration objects.
    SCM02.F.2.2 Name Different versions are distinguishable via their names.
    SCM02.F.3 Version merge
    SCM02.F.3.1 Version merge It is possible to merge a configuration object from objects with different versions.
    SCM02.F.3.2 Information about conflicts A version generated by means of a merge contains information about conflicts that have occurred.
    Conflicts occur where both initial versions differ in that way that the merge cannot be realized by means of a simple "And" operation but only by an "Exclusive Or" operation.
    SCM02.F.4 Comparing versions
    SCM02.F.4.1 Comparing versions It is possible to investigate versions of configuration objects with regard to their differences.
    SCM02.F.4.2 Number/position of differences The number and the position of the differences will be displayed.
    SCM02.F.4.3 Content of differences The content of the differences will be displayed.
    The environment of the different lines will be displayed.
    SCM02.F.4.4 Size of environment It is possible to choose the size of the environment.
    SCM02.F.5 Controlling the development state
    SCM02.F.5.1 V-Model states It is possible to represent the states (state transitions) requested by the V-Model.
    The V-Model demands the following product states: planned, being processed, submitted, and accepted.
    SCM02.F.5.2 General validity Each configuration object is allocated a state according to the V-Model.
    SCM02.F.5.3 Attributes for states The states comprise attributes.
    For example the date and the person in charge of a state transition.
    SCM02.F.6 Reproducibility of changes
    SCM02.F.6.1 History A change history is maintained.
    SCM02.F.6.2 Detailed information The change history contains at least the following information: date and time of the change, person in charge of the change, location of each individual change, comment.
    The comment explains, among other things, the individual background, the intentions, and effects of the change.
    SCM02.F.6.3 Representation The representation of every configuration object is realized in such a manner that the individual changes are allocated to the text.
    For example, each line is represented with the version number of the corresponding configuration object.
    SCM02.F.6.4 Information about new version Each new version generated since the configuration object was last utilized will be reported.
    SCM02.F.7 Change management
    SCM02.F.7.1 Allocation It is possible to allocate every change document to the corresponding versions.
    SCM02.F.7.2 Affected versions It is possible to relate all versions affected by a change to the corresponding change documents.
    SCM02.F.7.3 Change states It is possible to represent at least all states requested for the change management in the V-Model.
    SCM02.F.7.4 Representation of the change events It is possible to represent the change events for a version.
    For example: which parts of a configuration have been released for the change, which parts of the configuration have been actually changed, when has the change been carried out, which is the current state of the change, by whom was the change realized, by whom was the change accepted.
    SCM02.F.7.5 Logbook Changes are entered into corresponding configuration objects so when utilizing the configuration object the change history is permanently visible.
    SCM02.F.7.6 Statistics It is possible to generate overviews and evaluations of the current and the past situation of changes (change statistics) on request.
    SCM02.F.7.7 New version Each change of a version results in a new version.
    SCM02.F.7.8 Follow-up changes It is possible to show the objects sequentially concerned by the change of another object on the basis of the configuration structure. The objects may be related by hierarchical, network or variable structures.
    SCM02.F.8 Handling
    SCM02.F.8.1 Navigation A navigation function is available for the fast retrieval of information.
    The current position in the structure is to be made visible, e. g. by representing the path from the entry down to the objects below the current version.
    SCM02.F.8.2 Several versions It is possible to process several versions simultaneously.
    SCM02.F.8.3 Overview of states It is possible to generate an overview of all states in one version of a configuration .
    SCM02.F.9 Structure of a configuration object The definition of the structure of a configuration object prior to its existence is possible.
    SCM02.F.10 Controlling the attributes The use of the attributes is controlled.
    The entry of attributes is either realized automatically or forced on the user.
    SCM02.F.11 Control of the CID 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.

    3.4 Other Requirements

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