|SCM01 - Supporting Configuration Planning and Control|
LKM01 - Konfigurationsplanung und -kontrolle unterstützen
|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.|
|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.|
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.
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.|
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.
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.
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|
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.|
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.
It is possible to generate a product from its parts.|
This requires that storage and administration of documents is realized in parts.
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.
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.
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|
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.|
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|
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.
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).
|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.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|