Figure 7.1 - Parent - child relationship between objects
Computer systems are normally composed of many types of objects. Numerous objects may belong to a given type and several variants of a given object may be current at any one time.
Comprehensive records and the implementation of a control process are necessary to enable the management and control of the complex and evolving object relationships within computer systems.
Configuration management is the title given to the process to manage and control the object relationships.
Configuration records are collected and logged into a configuration log to enable the tracking of objects.
Objects generally migrate between several environments as the system is developed, e.g. from development to integration to QA and then to production. These environments should be treated as objects and should be effectively managed, e.g. objects should not be migrated into production unless they have completed their designated approval process, e.g. user acceptance testing, and appropriate authorisation granted, e.g. from the Software Development Manager.
This relationship exists when one object is derived from another, e.g. a design is the child of the requirements. When a parent is modified, there is always a need to make appropriate changes to a child. Figure 8.1 shows an example of a parent - child relationship.
Figure 7.1 - Parent - child relationship between objects
This relationship exists between two or more objects that are derived from a common parent object, e.g. sibling is the relationship between the various design objects in figure 7.1.
Objects that are grouped together to construct a compound object are referred to as components, e.g. a program may be composed of a number of header and source files. Each time a component is modified, the compound object has to be rebuilt.
Additional relationships may exist between different types of objects.
Where a relationship is likely to have an impact on the progress or quality of a project then this should be investigated, documented and controlled.
The following are further examples of relationships.
• Connected: A relationship that may exist between a network cable and a networked PC.
• Contains: A relationship that defines the contents of a directory, environment, or release.
When documenting relationships, it is important to identify the impact of object variants. Where object variants are of importance then this should be documented.
There are no strict rules determining when variants should be considered. However, a rule of thumb should be that variants are relevant unless proven otherwise. The examples below may assist in determining a suitable criterion.
• High level and generic relationships are not affected by variants, e.g. all designs are derived from requirements.
• An instance of any relationship is affected by variants, e.g. design version 1.1 is derived from requirements version 1.6.
• Formal tracking of variants is not generally necessary for objects that are in development that have not yet been approved and baselined. One would track relationships alone, and update the log with information on variants when the objects are approved and baselined.
Relationships shall be documented for all objects that are classified as Controlled. These relationships should be logged into a configuration log.
Where a development tool is used that automatically maintains object relationships, e.g. a CASE tool, then this tool can be used as a substitute to the configuration log as long as it adequately performs the following:
• Tracks object variants, e.g. document a relationship that identifies the objects and their version numbers.
• Produces detailed impact reports, including processes, and down to the lowest level, i.e. individual code objects.
• Tracks and reflects the status of the object.
• Prevents unauthorized access and modification of configuration records, e.g. only nominated roles should be able to modify the status of an object.
Populating the configuration log shall be performed on an ongoing bases as objects are developed. The data entered into the log is dependent on the object life-cycle.
The following are major milestones:
New objects shall be logged as soon as their production commences. The initial log entry should contain the object name and “Draft” status identifiers (refer to the Labelling and Identification Standard)
The status of the object should be marked as “Approved” and the log updated with all the mandatory identifiers as soon as the object completes its approval process (refer to the Approval and Baselining Standard).
A baseline is a record that documents the contents of an approved object at a given instance in time. Individual objects are baselined as soon as the approval process is completed and the configuration log is updated.
A baseline of a compound object, e.g. a program that is composed of a number of code objects, is achieved when all the components are baselined and the application built.
The release function (refer to the Release Control Standard) involves moving a baseline from one environment to another. In this case, the baseline records do not have to be updated. However the configuration record for the environment to which release has taken place should be updated to indicate the new contents.
All changes to approved objects are managed using change control (refer to the Change Control Standard). The appropriate configuration record should be updated as soon as the object status is changed to draft and the version number incremented.