|SCM02 - Version Management|
LKM02 - Versionen verwalten
|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.|
|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.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.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|
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.|
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.
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.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.|
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.
|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.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|