Several national and international standards contain a concise definition of the various configuration management processes, ISO 9000 for example. The following sections contain a more detailed specification of each process.
This is a predominantly manual process that aims to identify the items that will be produced by the project and also specify their interdependencies. This is by far the most complex configuration management process and most difficult to implement. The complexity of this process is essentially derived from the following factors;
· It is difficult to identify what will be produced before it is produced.
· This is a manual process that applies throughout the system life cycle.
· There are very few tools available that can satisfy the needs of this process.
Figure 5-1: Life cycle of labelling and identification
The project-planning task should attempt to identify the various planned items and document their relationships. Once the development process commences, additional items will be identified, these must be added to the list of planned items and incorporated in to documentation that specifies relationships.
Configuration items should be classified and itemised at the start of the project and status should be tracked as the project progresses.
One of the main aims of configuration management is to manage and control change to configuration items. It therefore follows that such items should be itemised and classified to ensure that the configuration management system is effective. Issues to consider when itemising deliverables include the following:
· How many items need to be controlled?
· How frequently will such items change?
· What is the level of resource required to operate the configuration management system?
· What tools will be required to control and manage change?
· The number of items that cannot or will not be controlled and the risk that this poses to the project.
The effort required to implement and maintain the configuration management system is determined by the number of items to control and the level of change. Identifying the number of configuration items will enable the estimation and determination of the following:
· The effort required to control the configuration items.
· The size of environments needed to store these configuration items.
· The size of the master library and its structure.
It is important to ensure that all configuration items are included when the estimation process is undertaken. The list of items should include:
· All system software, i.e. operating system files that are required for the operation of the application.
· All development tools files, i.e. files from the development tool that are required to run the application.
· All application files including program and data files.
The items accounted for when identifying the number of configuration items should include all files that are necessary for the operation of the application.
Once the items that make up the application have been identified, these should be classified into one of the following:
· System items: These are system items that the application requires. System configuration items are generally supplied by the operating system vendor and do not undergo any changes during the project life cycle other than updates from the operating system supplier.
· Development tool items: These are items that the application requires to enable it to operate with the development tool. Development tool configuration items are generally supplied by the tool supplier and do not undergo any changes during the project life cycle other than updates from the tool supplier.
· Application files: These are items that make up the application. Application items are the prime items that should be controlled as they will undergo changes during the project life cycle and hence need to be controlled and managed.
Configuration items can be further classified into:
· Items that have the form of data, i.e. records that are stored in one or more database tables.
· Items that have the form of source files.
· Items that have the form of composite set of files, e.g. directories.
Classifying items as data or program items is very important since the mechanisms for controlling each are very different. Of major importance are applications where program code in the traditional sense does not exist and where the program logic is stored as database records in a repository.
For all configuration items one must identify the process that will trigger changes and hence the necessary control processes to ensure that this change is managed effectively. Changes can generally be triggered by one of the following:
· Changes triggered by normal day to day development activity. These changes are implemented by the development team and should be managed by the project management method and controlled using configuration management.
· Changes triggered by the normal usage of the application being developed. The volume and nature of these changes are determined by the application and are generally triggered by the various application processes. Tracking such changes by following configuration management principles is generally unnecessary and very difficult, as doing so would hinder the usage of the application.
· Changes triggered by upgrades from third party suppliers. These changes should be managed and controlled using configuration management from the point at which the changes are delivered for installation.
Identifying the process that triggers change is essential, as this will enable one to identify classes of items that can be controlled via configuration management and classes that cannot.
Once configuration items have been classified they should be itemised in a list of deliverables table. This table should itemise the deliverables that make up the system and should include the following information:
· Item name or unique reference.
· Class of item (system, application or tool).
· Change process type (user, third party or system).
· Type of items, source or data.
This list need not be complete at the start of the project, however it should include all items that make up the system by the time the system is placed into production.
For all items, define the process that will be used to control and monitor change. Following are some guidelines:
· All files that are modified by the developers should be under formal configuration control.
· Files that are modified by the developers but that are of data format should be under formal configuration control, however source control may not be possible or cost effective.
· System and application files should be monitored to ensure that they are not deleted or replaced without formal approval and release control.
· All static files should be monitored to ensure that they are not deleted or modified.
Identifying the necessary control process should enable one to define the optimum configuration management approach and the suitable tools.
The status of all items that are to be controlled via formal configuration management should be documented and tracked. In particular it is important to note the following:
· Items that have draft status.
· Items that have approved status.
· The version number.
A full audit trail should also be maintained that identifies the following:
· When items changed status.
· Why they changed status.
· Reference to records that authorised changes to items and their status.
The list of deliverables document is a live document that should be kept up to date as the system is developed. This list should itemise the complete system by the time it is released into production.
A monitoring process should be devised to assure that static items are not undergoing change. Such items include the following:
· Static system files.
· Static tool files.
· Static application files.
· Static data files.
The monitoring process does not need to identify the nature of change, but should be able to identify the items that have been modified. Where changes are identified, then one should identify the reasons for this change and determine if the item should be re-classified and placed under formal configuration management control.
When monitoring changes to static items the following should be taken into consideration:
· Static items may change as a result of an upgrade from the third party supplier.
· The monitoring process should be automated to reduce the administrative overhead. This may necessitate the physical segregation of static items from those that should undergo change. This can be done by placing static items in dedicated directories and environments that do not contain items that will undergo regular change.
· A baseline of static files should be produced each time these items are changed..
Configuration items must contain sufficient labels as to enable effective identification. As a minimum, each configuration item should contain the following identification information:
· Configuration item name.
· Configuration item status.
· Version number.
· Description.
· Change history.
Figure 5-2: Mandatory labels
As a minimum, the status must identify those items that are approved and those that are draft, i.e. all approved items must have approved status and all draft items must have draft status.
Configuration item name
Configuration items should have a clear and concise name to facilitate identification. Ideally, names should be unique and should attempt to convey information about the purpose and usage of the item.
Configuration item names can take one of the following forms:
· Descriptive.
· Abbreviated.
· Coded.
Where configuration items have a name that is different from that used to refer to the source file, then one should either define the relationship between the item’s name and the file name or alternatively one should maintain a mapping that specifies the file name for each item name.
Maintaining relationships and mappings is generally made more complex in environments where a single file contains several discrete items each with its own name.
Always aim to establish a one to one relationship. With many modern development tools, one may be forced to store several discrete items into a single file.
Descriptive names
This is a free format name that is made up by aggregating verbs and nouns. Descriptive names are user friendly and can be effectively convey the purpose and function of the item.
Descriptive names can be long and difficult to use. On certain platforms long descriptive names are not feasible due to restrictions that may be imposed by the operating system. For example, some operating environments impose a name length of 8 characters.
Following are sample descriptive names:
· UpdateCustomerAccount;
· ActivateCustomerAccount.
Descriptive names are easy to construct and easy to read.
Abbreviated names
Abbreviated names are similar to descriptive names and are formed by aggregating two or more abbreviated nouns or verbs.
The use of abbreviated names may be necessary to accommodate name length constraints that may be imposed by the operating system.
Following are sample abbreviated names:
· UpdtCustAcct;
· DispAcctDetls.
Abbreviated names require a high level of skill to construct and can be cryptic and difficult to use. Adopting standard abbreviations and familiarity with the standard codes improves usability of an abbreviated naming convention.
Coded names
Coded names are very different from descriptive and abbreviated names and can take many different forms. Coded names always employ short codes and may also include a serial number to document one or more of the following:
· Type of components.
· Ownership of components.
· Product breakdown.
Following are sample coded names:
· RSH001, PRG101;
· CISRSH001, FINPRG101;
· CISCENMOD, FINUPDTFRM.
Using coded naming conventions can be very difficult, on the other hand, adopting a simple coding scheme can simplify the naming convention significantly and introduce a rigorous and dry uniformity across all applications.
Status
All items should have a defined life cycle where each stage of the life cycle is assigned a single status. Items must be clearly labelled to enable one to identify the status.
Labelling certain types of configuration items may be either difficult or impossible, for example labelling of individual database attributes. In such a situation a source control tool can be used to assign each version of the item its own unique status or promotion value.
The labelling scheme should facilitate the segregation of draft items from those that are approved.
Version number
Configuration items that undergo many updates should contain a label that identifies the version number of each revision.
Each revision of an item should have a unique version number. Version numbers should have a numeric format. Since most source control tools are only able to generate numeric version numbers, the inclusion of symbols or letters into the version should be avoided. Source control tools do not generally support a version label of the form of 1.0a.
Title or description
Whilst naming conventions attempt to describe and identify configuration items, this is rarely sufficient to enable one to effectively identify documents.
All items should have a title or description that can be used to describe the purpose and usage of the configuration items. The effective use of descriptions can facilitate reuse. This can be further facilitated by inserting keywords into the description to enable one to search for items using the keyword.
Change history
A change history is a concise record that traces the changes that an item has undergone during its development. As a minimum the following should be contained in the change history:
· Author of change.
· Date of change.
· Description of change.
· Purpose of change.
The description should be used to define the nature of the change and also to establish a link with the change control process that triggered the change and the approval process that triggered the change in status.
In many respects, this activity is the core requirement and key feature of any configuration management system. Unfortunately, documenting relationships is by the far the most complex task, which is, complicated further by the shortage of suitable tools to automate this the process and by the ever increasing complexity of modern IT systems.
Documenting relationships is essential as it enables one to perform effective impact assessment to determine the scope and impact of a planned change. This in turn determines the tasks necessary to implement the change and their order.
In an ideal situation one should be able to produce a relationship decomposition that establishes a clear link from initial requirements down to individual configuration items. Such a decomposition would enable one to identify the items that may require update when a requirement is modified and hence the likely impact of such a change on other requirements.
Documenting relationships in the first instance is very time consuming and requires utmost dedication from those producing the decomposition documentation. Once produced, the decomposition information requires considerable time and effort to maintain as the system evolves and develops.
There are many techniques that can be used to document relationships. These include product breakdown structures and product flow diagrams. Maintaining product breakdown structures and product flow diagrams is very difficult especially if they are produced using a charting tool that is not supported by any intelligence.
Status accounting is the process by which the status of items is identified and tracked. Status accounting is a key process within configuration management as many of the various configuration management processes are triggered by changes in status.
Where possible one must define a life cycle that defines the various status values, or transition states, that an item or group of items may assume during their development life cycle. Such a life cycle may be generic and apply to all types of configuration items, however in many cases the life cycle will be dependent on the type of item being managed. The following diagram represents a generic item life cycle.
Figure 5-3: Generic life cycle
The standard generic life cycle may need to be extended to address one or more of the following:
· Development life cycle employed on the project.
· The types of configuration item; source, executable and documentation items tend to have different life cycles.
· The level of approval being used within the project.
It is important that one is able to accommodate different types of life cycles for different types of items. It is also important that the configuration management tool being used is able to support the different life cycles.
Following is an example of document life cycle.
Figure 5-4: Document life cycle
The states listed in the above diagram have the following definition:
In Progress is the state of all items that are undergoing work, i.e. they are being produced.
Complete is the state of all items that have been produced but have not yet undergone the required approval process.
Peer Reviewed is the state of all items that have been peer reviewed.
Technically Reviewed is the state of all items that have undergone technical review.
Issued is the state of all items that have been issued for general use.
As expected, software items should have a life cycle that reflects the development process. The following diagram represents a typical software life cycle.
Figure 5-5: Life cycle for software item
The states listed in the above diagram have the following definition:
In Progress is the state of all items that are undergoing work, i.e. they are being produced.
Complete is the state of all items that have been produced but have not yet undergone the required approval process.
Unit Tested is the state of all items that have undergone unit testing.
Built is the state of all items that have undergone assembly to produce the run time component.
Baselined is the state of items that have been built and are now ready for system testing.
System tested is the state of baselines that have passed system testing.
Released is the state of items that have been released.
The above state transitions are flexible and one can define a life cycle to match the requirements of the project. In the above example one may choose to move the stage at which a baseline is produced so that it happens after system testing.
When defining the life cycles one must identify the configuration management processes that are triggered when an item changes state. The following diagram shows the processes that are triggered for the software life cycle mentioned above.
The above diagram is simply an example. Different organisations may need to define their own generic life cycle that should be based on their own development process and the types of development tools being used.
Figure 5-6: CM processes and item life cycle
A key point to note in the above diagram is the status from which change control should be applied. Formal change control should be applied from the baselined status and onwards. It is also important to note that full traceability of change is required for all changes following the point at which the baselined state is achieved. It therefore follows that the earlier the baselined state is achieved the more formal and extensive the level of configuration management.
Defining a life cycle is an excellent mechanism for phasing in the various configuration management processes. One may choose to delay the baseline stage until the stage prior to which the items are released. Once the configuration management process becomes more established one can move the baselined stage to earlier stages within the life cycle.
A baseline is a key point in the life cycle of an item, e.g. functional baseline. Once a baseline is reached, all changes to this baseline must be under formal configuration control. It should be possible for one to identify all changes between two baselines and trace the reasons for each change.
Some tools have different “types” of baselines. The generic definition is a baseline is a snapshot of a configuration. This can be used for a progress reporting process but may not be a formal baseline.
Maintaining full traceability between baselines is achieved through formal change control. Whilst source and version control will enable one to identify the individual changes, source and version control does not generally provide information on why the changes were implemented and why they were authorised.
Delaying the stage at which a baseline is established minimises the level of configuration control but reduces the process overhead. Producing a baseline in the early stages of the life cycle provides maximum configuration control.
The point at which a baseline is established may be linked with approval from the customer. Whilst this provides a state that is related to contractual requirements, i.e. customer approval, this generally hinders the configuration management process, especially if the customer is reluctant to sign-off deliverables due the financial implications.
Baselines should not be confused with backups. A secure copy of an environment to tape is not necessarily a baseline. For a backup to be viewed as a baseline one must be able to identify the status of each item and its version number and must also be able to produce a meaningful report that provides traceability between the current backup (or baseline) and the previous backup (or baseline).
It is essential that one is able to identify the status of all items throughout the life cycle of the system. This can be achieved in one of three ways:
· Physical labelling of items with their current status.
· Status identification using a configuration management database.
· Physical segregation of items into different environments.
Status identification using labelling is generally achievable for source configuration items, especially those that have ASCII format. One can add a label to the item’s identification to specify its status.
In many cases it is not possible to add the physical label to an item to identify its status. In such a situation one may maintain a register or a database that contains the essential details of each item and their current status.
A final approach for identifying an item’s status is through physical segregation. Items that are still under development would reside in a development library or environment, completed items would reside in a source control library, and items that are released would reside on the production platform.
It is important not to overlook the fact that different versions of an item may have different status values; version 5.0 may be in production, 6.0 may be in system test, 8.0 may be in development.
Libraries, commonly referred to as environments, can be classified into:
· Controlled.
· Managed.
Controlled environments and their contents should be under complete configuration management. All changes to such environments must be subject to one ore more of the configuration management procedures mentioned earlier.
Managed environments are those that are not controlled. These are generally made available to the general users and may contain items that may or may not be subject to configuration control.
Library management is a relatively simple process if developing on a central mainframe system that enables easy management of the following:
· Authorised users.
· Directory structures.
· Directory permissions.
· Available tools.
Mainframe systems also provide a simple process for segregating and managing the various types of environments. It is relatively easy to provide read access to system directories, read and write access to development directories and to revoke all access to directories that should be completely secured. Also the various environments can be easily identifiable through their names. Following is an example based on the standard UNIX directory structure:
· “/bin” is the directory that contains all system utilities.
· “/usr” is the directory that contains user utilities. This directory is generally read only to users but writeable to the root and administrator accounts.
· “/user” is the directory that contains user produced files.
Managing environments on a client sever environment is more complicated. Uncontrolled and controlled environments are generally distributed across the complete network. Also it is very common for some operating systems not to make any distinctions between controlled and uncontrolled; it is very easy for a user to modify the contents of the Window’s system directory for example.
Insufficient environment control manifests itself in a number of different ways. Following are examples of problems that arise due to poor environment control:
· An application that fails to operate in different environments that appear to be identical.
· Unexplained application failure when the application code has not been modified.
· An application that operates inconsistently on different platforms.
Developers used to working on a mainframe environment may find the above problems difficult to understand. PC and UNIX platforms require considerable administration to eliminate environment inconsistencies.
A well-managed environment should provide the following:
· Stable development platform. What works today should continue to work tomorrow.
· Clear boundaries between directories that can be modified and those that should not be modified by users and developers.
· Secure migration paths that will ensure that items are not migrated between environments without proper authorisation and without the generation of an audit trail.
Environments should be created to support the development process and reflect the life cycle being used. A life cycle that has a development, integration, system testing, user testing and production states should have appropriate environments to support each of the life cycle stages.
Additional environments are also required to support parallel development and independent application building.
It is generally good practice to provide each parallel stream of development with its own set of environments. A project that is working on phase 1 and phase 2 of a system should have separate environments to support each of the phases.
It is also good practice to provide a separate set of environments to provide a platform for supporting a system that is in production. This is particularly essential if the system is also undergoing development to incorporate additional change or enhancements.
The following diagram shows an environment schematic to support development and independent system testing.
Figure 5-7: Simple environment schematic
The environments required to support a project should be defined early in the project life cycle and should be maintained to ensure that they are able to support the development processes.
In the early stages, one may be able to manage by constructing development and master library environments. Once independent testing is scheduled to start then additional environments will be required to generate the run time and to perform system testing.
Changes to development phasing should be reviewed on a regular basis to ensure that the current environments can support them. A decision to commence parallel development, i.e. working on two parallel versions of the system should immediately trigger the generation of a second set of environments to support the new phase of development. The following diagram shows a schematic for a project working on two phases of a system in parallel. The new structure assumes that the two streams of development are incompatible and hence cannot be accommodated in the same environment.
Figure 5-8: Environments to support two parallel phases of development
Environments are an essential mechanism for segregating configuration items and for controlling the development activities.
A typical project will require the following essential environments.;
· Software development.
· Storage of approved items.
· Application assembly.
· System testing.
· User testing.
· Production systems.
The above environments should be correctly classified into controlled or managed and then secured appropriately. Migration of items between the various environments should also be controlled to ensure that a full audit trail is maintained for all change to controlled environments. The following diagram shows a typical migration strategy.
Figure 5-9: Managed vs. Controlled environments
The development environment is a physical disc area that is dedicated to the development process. The development environment may be;
· Centralised and application based.
· Distributed and owned by the different developers.
Developers should have read/write access to the development environment. Development environments should be designed to facilitate the development process. Development environments may contain draft items as well as approved.
It is important to note that whilst development environments are essentially uncontrolled and used by the individual developers, the general structure of such environments should be controlled and the development tools used within such environments should be under full control.
The structure of development environments should be controlled to ensure that items developed and built in a development environment are easily transferable to other controlled environments, e.g. master library or system test.
Development tools should be fully controlled to make sure that items developed in a development area could be re-generated and used in a controlled environment.
The master library is the environment that is dedicated for the storage of approved configuration items. The master library should contain the source for all approved configuration items.
If a source control tool is used to construct the master library then draft items may be stored in the library as the source control tool is able to segregate the draft items from those that are approved.
Access to the master library should be restricted to ensure that items cannot be modified or deleted.
Where a source control tool is being used, then a single master library may be created to support all the parallel phases of development. A source control tool is able to segregate the various phases of development without the need to create separate physical areas for each parallel phase of development.
This is a controlled environment that is dedicated to the construction of the application run time using software configuration items that originated from the master library.
Access to the assembly area should be restricted to the configuration manager or build manager. Release into testing environments should always come from the assembly area. This can happen through a direct release from the application assembly area or via the master library. Releases via the master library are preferable as this enables one to save a baseline of the released code prior to release. This facilitates traceability.
The application assembly area serves a very special purpose, namely to provide an environment that will ensure that builds are repeatable. It is important to note that developers produce the source code while testers test the run time software.
It is essential that the builds being passed to formal testing have the following features:
· The constituents of the build must be known and documented.
· The status of each constituent must be known and documented.
· Each constituent item must be stored in the master library.
· The process to generate the run time is documented and controlled.
Failure to satisfy the following requirements may prevent one from being able to generate repeatable builds.
Builds that are produced in the development environment must never be passed into a system test environment, as it is practically impossible to guarantee the identification of the source that was used to produce the run time.
All testing and production environments should be controlled and fully secured to prevent accidental or intentional modifications. Where possible, testing and production environments should not contain any source configuration items or any development tools. This would make it impossible for developers to accidentally modify live software.
Testing and production environments should be populated with configuration items that originate from the application assembly area or master library.
Migration of code between environments must be controlled through the use of the various configuration management procedures. The following diagram shows a typical environment schematic and the control processes.
Figure 5-10: Migration and control processes
Items should only be migrated into the master library once they are fit for purpose and have passed the first level of approval. Where a source control tool is used to provide the master library then it is permissible to migrate draft items into the master library since the source control tool is able to segregate the draft and approved items. This ensures that all items that reside in the master library have a known and proven status.
Approved items that reside in the master library should be checked out for change into the development area only after authorisation through change control has been granted. This ensures that approved items are not modified without prior authorisation. Where a source control tool is used, it is possible to protect items and prevent their modification without formal change control.
Where a source control tool is used to implement the master library, then the migration of items into development is achieved using a check out command and the migration back into the master library is achieved using a check in command. The source control tool will provide a record of the check out and check in.
Items should be migrated into the build area only if a formal request for a new release is received. This assumes that the build area is used to support the system-testing environment. This is necessary since the contents of the build area will determine the contents of the system test area and therefore there is a need to control the movement of all items into the build area.
Movement from the build area into the system test and then into production should be managed using the release process. This process aims to document the contents of each release. Also approved releases should only be performed on approved items, i.e. items that can have passed application assembly and system testing.
Items may pass trough several approval processes through their life cycle. Each approval process aims to establish the fitness for purpose of the items being approved. As a rule, the approval point should be used as the point following which all changes must be managed through formal change control.
Once approved, a configuration item is declared as being fit for re-use and complete. All changes and use of such an item should be brought under configuration control.
The approval of a configuration item may be a formal process, e.g. a Fagan inspection of a design or unit testing of a program module, or can be informal and undocumented, using an informal peer review.
Identifying the correct approval process is essential. Mandating a formal and thorough approval process may be too costly, whilst accepting a totally informal process may introduce excessive risks into the development process and may compromise the quality of the system.
Many developers confuse testing with approval. Whilst it is true that testing can be used as an approval mechanism, approval should be possible in the absence of testing. The rational for this is derived from the fact that testing is essentially an inspection process that attempts to identify and uncover non-conformance. The completion of testing does not guarantee that a product is fault free, it merely proves that the aspects tested satisfy the requirements of the testing that were completed.
Given the above, it is perfectly acceptable to define a product as approved if it has been developed following a defined and agreed development approach. For example, one can agree to approve a product on the condition that it is produced in accordance with approved development standards.
The definition of approval, as given above, may not be fully compatible with that adopted with most implementation of the industry standard for quality management systems, namely ISO 9000. Quality management systems demand that key products do undergo a formal approval process and that this approval process should be signed-off, hence proving that the product does comply with its requirements.
The difference between the above two definitions of approval is subtle but important;
· Approval of products from the configuration management perspective is the point at which the product becomes a formal controlled item and hence subject to configuration management standards and procedures.
· Approval of products with respect to quality management systems is the point at which the product is formally accepted or signed off by its ‘user’ or ‘owner’.
Treating approval as being the point at which items are controlled facilitates early control of such products and without the need to undergo a significant and costly testing.
Treating approval as being the point at which items are signed-off as complete may delay the point of approval and hence reduce the scope of configuration management and its benefits.
Once approved, all items should be protected and controlled to ensure that, when changed again, they do so following a managed process. By managing the change process of approved items, one is able to ensure that all changes are necessary and to the benefit of the user and the project. It is also necessary to archive approved items to ensure that they are available for re-use, while their next variant is being produced, and to ensure that a cost effective roll-back process is available to recover the previous approved variant in the event of the new changes being abandoned.
This archiving process may be a considerable overhead when performed manually. If source control tools are used, then this process is very simple since such tools automatically archive old revisions of an item, hence preventing them from being modified and making them readily available for re-use.
The need to archive approved items should not be underestimated. The only time when an approved item can be discarded is when a new revision is approved, and even then discarding the approved item should be done after considerable thought.
Whilst a computer system is composed of smaller components, many of which can be easily classified, the level of modularity at which configuration management will be applied to software is not as easy to ascertain.
Applying configuration management at component level maximises the level of control being exercised by the configuration management system and also increases the volume of data being processed and hence the overhead of administering the system.
Applying configuration management at system level, i.e. when the system moves into production, may be easy to implement, but the benefits of such a system would be minimal.
When developing a large system, different parts of the system may need to be managed at different levels of modularity, e.g. requirements may be managed as a single product, while programs may be managed at individual program level. For this reason, the configuration management system should be scaleable, i.e. should be applicable when attempting to manage discrete and small components as well as composite components.
When defining the granularity for a particular product, it is essential that the level of granularity is linked to a physical milestone, e.g. the program is complete, rather than an intangible, e.g. the end of two months development, milestone. This requirement is often overlooked.
By linking modularity, and hence approval, to a physical milestone one is able to easily verify that the milestone has been achieved, document the basic characteristics of the baseline and hence enable the re-production of this baseline in the future.
Agreeing the approval process and when it should take place is an essential component of configuration management as it determines when the various configuration management procedures should be applied.
Enforcing all configuration management procedures to all products, regardless of their status, is expensive and probably unrealistic.
Delaying the point of approval may undermine the configuration management system and hence reduce its potential benefits.
A clear definition of the approval process of all classes of products will ensure that items are approved when required and that this approval is valid and beneficial.
As mentioned in the previous section, approval may be achieved when a particular approval process is complete, or when a series of defined development activities are performed and completed in accordance with agreed standards. In either case, a product reaches a milestone in its development, and that that milestone the product is approved and then placed under configuration management control.
The state of the product at the milestone is referred to as the baseline and the various states that a product can have during its development are collectively grouped together and known as a life cycle.
A baseline, in the physical sense, is the status of one or more configuration items that defines their status, contents and attributes, physical and logical.
A baseline, in the recording sense, is a set of records that document the physical baseline. Baselines are generally documented to facilitate the re-production of such a baseline if and when required.
Many IT practitioners baseline software products by creating a backup. By producing a backup they are able to re-generate this baseline at will. The main problem in this approach is that such a baseline is meaningless unless it represents a milestone, e.g. completion of unit testing for example. A further limitation of this approach is that the number of baselines may increase to such an extent that the process starts to impose significant resource requirements, disc space for example, resulting in the eventual abandonment of the process.
Some configuration management tools record a baseline in the configuration management database rather than copying all the physical files each time. This is a powerful feature and enables projects to take baselines at all major project baselines.
Baselines should be linked to key milestones, e.g. completion of certain development or approval processes. Milestones for systems are generally satisfied when the system reaches a pre-determined level of testing, inspection or approval, e.g. completion of system testing.
Baselines that are produced at the completion of a physical milestone are generally easy to document and hence reproduce. Baselines that are linked to an intangible milestone can be very difficult to document and hence difficult to reproduce. A baseline of the system as on the 21st of October may be meaningless, whilst a baseline of the system following the completion of the first cycle of user acceptance testing is much more useful.
Baseline reports may be produced to aid progress reporting, e.g. a project manager may want to know what changed between 21st and 28th October. This type of baseline is quite different from a configuration baseline.
The overall software development process is inherently cyclic and can be broken up into stages or phases, analysis, design and construction for example. In common with the development process, the development process for individual components is also cyclic and can be broken up into stages or phases.
Whilst the life cycle for the development process is well defined and established and has several forms that are defined by various analysis and design methods, the life cycle for individual software components are not as clear and defined.
When applying configuration management to a system, one should define an overall system life cycle, resulting in one or more system baselines, and component life cycles, resulting in many component baselines.
When investigating the life cycles for components one should always take into account relationships with other types of components. For example, when working with Visual Basic, a screen may have several basic functions closely associated with it. Defining a life cycle that groups the screen with its relevant basic program modules is much more meaningful than treating each component on its own.
The logical groupings resulting from accounting for the life cycle dependencies result in the formulation of meaningful baselines. By baselining groups of items, rather than individuals, one is able to minimise the number of baselines and the associated administrative overhead associated with documenting and tracking these baselines.
System baselines are governed by the development method being used. In general, these are composed of a baseline at the end of each of the development stages, e.g. analysis, design, construction, system testing, user acceptance and final production.
Structured development methods attempt to specify definitive boundaries and criteria to facilitate the definition of the various development stages and hence their associated baselines. These methods generally define the products that form each baseline, how they are related and how they should be approved. Whilst these methods are common place within the analysis and design stages, they are not as common within construction.
Techniques that apply to the management of the system can be employed to exercise similar control on individual or groups of components. In essence this involves the definition of life cycles for individual or groups of components and their associated stages.
All products, individually or when grouped together go through very similar life cycles, they all start as draft products, undergo approval, get released for re-use, undergo many cycles of re-development and enhancement before they are de-commissioned.
Approval may involve a single approval activity or may involve several, e.g. unit testing followed by system and then user acceptance.
Life cycles should be defined for all major products, and the stages at which baselining baselines will be produced should be clearly defined.
Formal approval must generate quality records, test results and test sign-off for example. It is important that all quality records are uniquely identified and filed for future reference. Such records can be used as part of the audit trail to provide evidence of when items were approved.
Change is an integral part of the whole system lifecycle and is unavoidable even when adopting the most stringent development procedures.
Change to an IT system or its components can take place for one of the following reasons;
· Changes in the business processes or requirements that the system relates to. These are generally driven by the end user.
· Changes in the development or target platforms. These may be driven by the user, the IT department or in some exceptional cases may be forced on an organisation.
· Changes to correct defects in the system. These defects may have been introduced into the system by ineffective analysis, design or construction.
· Unintentional modification to one or more components of the system. The user or the system implementers may generate these changes.
Change management is the process that aims to manage and control the first three categories of change and to prevent the final category.
Ineffective control of change is one of the main causes of the run away project; all changes have an impact on the system development cost, timescale and resource requirements.
Ineffective control of change is also one of the main causes of software problems and defects. IT systems, software in particular, have complex and intangible characteristics; it is not always possible to identify the impact of change, hence resulting in incomplete updates to the system.
Implementing change to approved (complete) software products should always be tackled with care and after considerable thought and planning; a badly implemented change would negate all the effort expended in developing and approving the products in question.
The following roles may be involved in one or more of the activities within the change control process.
Change co-ordinator
The change co-ordinator is responsible for overseeing the change control process by performing the following;
· Acting as the first point of contact when initiating a change request.
· Maintaining a log of all changes.
· Producing regular reports on the status of all changes.
· Liasing between all involved parties to ensure that changes are given the required visibility.
· Arranging, chairing and documenting all change review meetings.
· Forwarding the recommendations of the change review panel to change approval board.
· Documenting the decisions of the change approval board and forwarding those that are approved to the appropriate development area for implementation.
· Contacting change initiators with the aim of informing them of all decisions and actions against the changes that they have initiated.
The change co-ordinator role may be part time role and should be assigned to a person who has the following skills;
· Detailed understanding of the change control process.
· Detailed understanding of the various change control processes.
· Good administrative and organisational skills.
· Experience in the use of spreadsheet and database tools and ability to generate the required reports to track the status of change requests.
Change review panel
The change review panel is responsible for reviewing all changes and for generating the necessary impact analysis and change justification or business case. Detailed responsibilities of the change review panel are as follows;
· Review all change requests and identify their impact. The impact of change requests should be formally documented in an impact analysis report which identifies the products and services affected and the necessary work to implement the required work.
· Review all change requests and document their benefits or justification. Minor changes may require a high level justification, major changes may require a full business case. Changes that involve the correction of software defects may not require a justification but should trigger an investigation of the cause of error and how this cause can be reduced or eliminated.
· Prioritise and agree a schedule for implementing all changes.
· Agreeing the severity of changes.
· Identifying and documenting the cost of implementing the change and the impact of this change on the project scope, cost and timescale.
· Making recommendations to the change approval board by identifying which changes should be rejected, deferred or implemented.
Given the considerable scope of the responsibility of the change review panel, this role cannot be fulfilled by a single person and should ideally be made up of several representatives:
· User representative: The user representative should be responsible for reviewing all changes from the user’s perspective. The most important contribution the user representative has to make is to ensure that all changes are being interpreted as the user had originally intended and in a manner that does not prejudice the user’s interests.
· Technical representative: The technical representative should be responsible for reviewing all changes to ensure that they do not undermine the overall integrity of the systems affected. The technical representative should also ensure that the proposed implementation approach is optimal and valid.
· Project representative: The project representative is responsible for identify the necessary work to implement the change and for specifying the full impact of the change in terms of costs, additional work and resources.
· Business representative: The business representative is responsible for verifying the costs and for verifying the benefits of the proposed changes.
Initiator
This is the person who initiated the change. The initiator may be a user or a developer. The initiator is responsible for supplying all the necessary information to accompany the change and for performing any necessary follow up, producing the justification or business case for example.
Change approval board
The prime role of the change approval board is to review the recommendations of the change review panel with the aim of approving or rejecting all change requests.
The membership of the approval board may be restricted to the project manager, for small-scale changes, or may include the project board, for major changes.
There are three main stages in the life cycle of a change:
· Investigation.
· Authorisation.
· Implementation.
Investigation is a technical task that involves the assessment of the impact of the proposed change. This impact assessment should aim to identify the scope of the proposed change, the affected items, and the required approval process to approve the change and the necessary development tasks to implement the change. Technical staff should investigate changes that affect the physical implementation of software. Changes that have an impact on business process should be investigated by those who are involved in defining and developing the business process.
Authorisation is a management process that aims to review the likely cost and impact of a change with the aim of reaching a decision on whether or not the change should be allowed to progress. Change authorisation should be performed by management and where possible user representatives.
Figure 5-11: Change life cycle
The main life cycle of a change is defined in the following sections.
Initiation
All those involved in developing the system should be allowed to initiate change, i.e. users and developers. Implementing changes in the early stages of a project are much less costly to implement than changes that are identified during the later stages of the project.
All changes should be indexed and logged centrally. Logging changes centrally should facilitate effective tracking of individual changes and should enable the grouping of related changes to ensure optimal phasing of implementation.
Investigation
Change investigation aims to identify the following;
· Cause of change, i.e. change in requirements, defect or change in software or hardware platform.
· Impact of change on other software items, hardware, documentation. This in return should enable the identification of the necessary development work to implement the change.
· Relationship with other current changes and optimal phasing for the implementation.
Change investigation should be a formal process and should aim to identify the full impact of the change, where possible. Change investigation generally results in the production of an impact report.
Change review
All changes should undergo a formal review to assess the fullness of the impact analysis report and to determine the course of action to take to implement the change.
Change should be reviewed from the following perspectives;
· Technical: The review should assess the correctness of the investigation from the technical perspectives. Particular attention should be paid to assuring that the impact is fully assessed.
· Business: The review should assess the business work of the change and the need for it. Changes that cannot be justified from the business perspective should be avoided unless there are other overriding reasons.
· User: The review should assess the benefits of the change to the end user. Many changes may be fully justified when reviewed from the technical perspective but may offer little or no benefits to the end user.
Authorisation
The outcome of the review should be a recommendation as to whether or not the change should progress. Final authorisation rests in the hand of a panel who will have the final authority to approve or reject changes.
A clear and unambiguous approval/rejection process is essential for the effective operation of change control.
Change Implementation
All approved items that require change should be obtained from the master library and in accordance with the source control process being used. By obtaining the source from the master library one is assured that the change is being implemented on the definitive version of the source.
All items being modified should be labelled to identify the changes being implemented and cross referenced to the change control process through which authorisation was granted.
Once a change is implemented, the modified items should be approved, and returned to the master library. Where necessary items should be released to the users by using the formal release process.
All changes should be closed once the items are approved and returned to the master library. Change closure should be a formal and visible process and best executed by the approval panel.
All changes that have to be re-implemented, because the implementation was not completed correctly, should be re-work by re-opening the original change request.
By tracking the number of re-opened change requests one will be able to gauge the number of changes that required re-implementation either due to incorrect or incomplete implementation. Tracking re-opened changes is an effective mechanism for tracking the effectiveness of many of the development processes that are triggered by change control.
The change control process generates copious records relating to all changes and how they were implemented. A change log should be developed for tracking all changes. This log should cross-refer to the library that contains all raised change requests.
Developers implementing changes should cross-refer to the change log. All changed modules should contain a reference to the change log.
The combination of the above two cross-references should enable the organisation to maintain traceability between all changed components and their initial change requests. This is an important requirement of all the major standards that this standards aims to satisfy, ISO 9000 for example.
The change co-ordinator shall be responsible for maintaining the change log and all the associated forms and records.
Change management is an effective mechanism for financial control. Effective tracking of all changes and their causes may enable the project manager minimise project costs.
The change authorisation process is a key point at which unnecessary changes can be terminated and prevented from progressing.
The change review process is a key point for assessing planned changes with the aim of prioritising the work and grouping related changes together.
The change investigation process is a key point for assessing the various approaches available to implement the change to ensure that the selected approach will minimise impact and costs to the project.
User participation will ensure that the requirements of the user are interpreted correctly for each and every change.
User participation will enable the user to appreciate the impact of change and its implication to project costs and timescale.
Where possible user participation should be encouraged in the change review and authorisation stages.
A change is generally used to refer to a request to modify an item due to a change in stated objectives or requirements.
A problem is generally used to refer to a request to correct a defect in an item to make sure that it meets its stated objectives or requirements.
Many organisations provide different processes for managing change and problems. From the configuration management perspective, both processes are identical as both are implemented by modifying one or more configuration items.
Build management is the process by which the system source is transformed to the run time image. Whilst one may wish to extend this definition to apply to other deliverables, e.g. design model, composite documents, the benefits of this are likely to be limited.
The build management process can be broken up into two categories;
· Activity to define and document the component dependencies that make up the various sub-systems and the build instructions needed to produce the run time.
· Activity to generate the run time using the information documented in the first activity.
Documenting dependencies is essential for all development tools as this information forms the basis of defining logical baselines and when items should be approved.
The build activity is mandatory for all development tools, however, many 4GL environments now have this function built into the development tool. 3GL developers may need to make use of dedicated tools, e.g. MAKE, to automate this function.
Software generally exists in at least two distinct forms;
· Source.
· Run time.
Developers using development tools, e.g. editors, painters or code generators, produce the source. Compiling the source produces the run time.
Whilst the transformation of source to run time is a simple process, identifying the source that was used to generate a given run time is not as simple.
Build management is also needed to ensure that the source used to generate a run time is the correct source and that it is archived to enable the generation of the run time in the future.
For all run time components the following must be documented:
· Items used to generate the build.
· Version number of each item used.
· Compile and link directives.
· Link libraries.
When generating a run time using a 4GL it may also be necessary to document the contents of the 4GL repository.
This term is used to describe a build that is performed in a controlled environment, application assembly for example. Such a build should make use of items that are controlled in a master library and should only refer to items that are of known status.
Controlled builds are generally required to ensure that the run time being produced is re-predicable.
The traditional build process is made up of the following steps:
· Pre-processing.
· Compilation.
· Linking.
The build process for many modern languages does not involve the code-linking step. In some cases only part of the code is linked at build time and the remaining code is linked at run time.
A traditional build cycle provides assurance that all code being referenced is available. The linker generally performs this. Also the linker binds the referenced code into a single run time module. The link process generally fails if one or more of the referenced items cannot be found. Compilers and linkers also check for correct calling convention and generate errors if functions are being called incorrectly, i.e. the programmer is not passing the correct number or type of arguments.
Tools that link at run time pose a number of major problems and it is no longer possible for the build process to verify correct calling conventions or assure the availability of the referenced items at run time.
This process is often treated as part of the software distribution process. Whilst it is acceptable to group the two processes together, there are several good reasons for treating each process separately:
· Release management is predominantly a management task that should involve considerable management input. One defines the scope and contents of a release in terms of functionality and configuration items and also defines the process to be used to deploy the system into the final production environment.
· Distribution management is predominantly a technical task that involves minimal management input. Distribution management involves the replication, storage and deployment of systems of changes into the production environment.
· Release management is a manual process with minimal scope for automation.
· Distribution management is a mechanical process with considerable scope for automation.
Release management is the process by which one determines the release strategy for a project or system. This may involve one or more of the following:
· Identifying the total functionality of the system being developed.
· Defining a release strategy, i.e. defining the various system releases that will be required.
· Defining the precise scope and contents of each release. This should define functionality in terms of end user and business features rather than identifying the individual configuration items required.
· Defining the phasing of releases. Will work on release be in parallel or will the work be sequential?
The ideal approach to defining the contents of a release is by identifying its scope in terms of functionality. Once this is specified it can be translated into a bill of materials. This can be achieved manually, using a requirement traceability tool or by decomposing the system into its individual items through the use of product decomposition and breakdown structures.
Defining a release strategy is essential as the strategy determines the level of parallel development within the project and hence the environments that will be required. A release strategy with a high degree of parallel development will require a high degree configuration control. Also, a release strategy with parallel independent phases of development can only be supported by creating dedicated development and build areas for each of the phases.
The user and project management generally determines the release strategy. Decisions on changes in the release strategy must be communicated to the configuration management function to make sure that the required environments and controls are created. Additional environments create increased demands on disc and CPU resource. Delays in securing the required hardware resources may affect the delivery dates for the planned releases.
The requirements for additional environments are most serious when using repository based 4GL tools. The majority of such tools cannot support more than one phase of development at any one time, i.e. one cannot have multiple versions of a given item in a single repository. With such tools, a dedicated repository will be required for each development phase.
This is the process by which applications or their updates are deployed into production. This may involve copying the application to one or more production platforms,.
The software distribution process is made up of the following activities:
· Identify release.
· Prepare configuration items.
· Prepare release pack.
· Perform release to production environment.
· Update release log.
· Acknowledge delivery.
The above activities represent a realisation of the release management process by identifying the physical items that must be released.
It is important to fully identify the contents of the release. Minimal requirements are as follows:
· Identify the names of the configuration items that should make up the release.
· Identify the status of the items to be released. Particular attention should be paid to those items that have not yet been approved and those that are currently undergoing development.
· Identify outstanding and pending change requests. Particular attention should be paid to those that relate to defects and errors.
· Identify the impact of the planned release on previous releases. Particular attention should be paid to releases that should be accompanied by a data migration process, moving data from an existing database and into the released database.
The work necessary to prepare the configuration items to be released is determined by the nature and type of items to be released.
The preparation task may involve one or more of the following:
· Extract the required items from the master library.
· Construct the run time if you intend to release a run time application.
· Construct any necessary scripts to install the new release.
· Construct any necessary scripts to migrate data from the existing system and into the system being released.
The release pack should be produced prior to release and should be issued as part of the formal release. The release pack is made up of the following:
· Release items. These are the items that are being released.
· Release contents. This lists the complete contents of the release.
· Outstanding changes. This lists the current outstanding change requests on the items being released.
· Implemented changes. This lists changes that have been implemented since the previous release.
· Release instructions. These are instructions on the necessary work to install the new release.
· Acknowledgement letter. This is a form that the recipient of the release should sign and return to acknowledge receipt of the release.
Two copies of the acknowledgement letter should be produced. The first copy should be released with release pack and the second copy should be filed in the master library. The release pack should be assigned a unique id.
The release process should ensure that the release pack is conveyed to the target recipient promptly and without damage.
If the release pack contains magnetic media, then the packaging of the release pack should be as prescribed by the manufacturer of the media.
If the release pack contains classified items, then the packaging should be labelled in accordance with the company’s security guidelines.
There are special tools that are specifically designed to enable one to automate the process by which software is distributed to the various production platforms. Such tools are also able to manage the distribution process across LANs and WANs.
A release log should be maintained that identifies the various releases and their recipients. The release log should be updated to include the following information:
· Baseline id.
· Date of release.
· Recipient of release.
The recipient of the release must acknowledge receipt by signing and returning the release acknowledgement letter to the release co-ordinator the recipient must also ensure that the release instructions are followed to ensure that the release is processed correctly.
The recipient should not sign the acknowledgement of the letter if he/she is not satisfied with the contents of the release. Signing the letter signifies acceptance of the release.
The source and version control is one of the most important configuration management processes. Many of the other processes revolve around this process. The importance of the source control process is derived from the fact that this is the process that aims to control access and change to the physical configuration items being used. It is very difficult to imagine how one would be able to implement a configuration management process without effective source and version control.
Source and version control is extremely labour intensive and satisfying all of its requirements would require considerable effort.
Fortunately, this process is the easiest to automate. Also source and version control tools are the most common and most established in the configuration management market.
The following is a description of the various processes that make up the source and version control process.
Creating a master library is the first step in establishing effective source control. Establishing effective control on a centralised repository is much easier than when the configuration items are dispersed across the various development platforms.
The master library should have the following features:
· It should contain separate directories or sections for the various systems or projects that make use of the library;
· It should be located on a network drive that can be easily accessed by those who have the necessary privileges;
· It should have a centralised access control mechanism, i.e. should be administered as a single unit rather than as many separate units;
· It should have effective backup and recovery procedures.
Given that all configuration items will be stored in the master library, it follows that effective security control mechanisms should be in place to protect the items that are stored in it.
Securing the master library involves the following:
· Identifying and implementing the necessary permissions. In general users should have read access but should not be granted delete access. In practice this is not always possible;
· Each section of the library should be owned by its target users, i.e. a user should only be able to access those sections that relate to his/her work.
Once the library is created and secured, its users should be identified and documented. Having identified the users the following should be performed:
· Identify the libraries that the user should have access to and granting the user the necessary update privileges.
· Identify the libraries that the user should not have access to and revoking the user all update or read privileges.
· Determine the mode of access to shared libraries, read only or read and update.
Configuration items should be registered and placed into the master library as soon as they are created. The registration process involves the following:
· Identifying the library the configuration item belongs to.
· Copying the configuration item into the library.
· Updating the master index for the library with the item’s name, author, change date and description.
· Assigning the item an initial status of draft or in progress.
The configuration item registration details should be stored in the master index of the configuration management database.
This is the main purpose of the source and version control process and is made up of three activities:
· Securing all approved items to prevent their modification or loss.
· Flagging items that are being modified to prevent or manage parallel updates to individual items.
· Updating master library with changes.
Securing approved items
Securing approved configuration items is essential to ensure that that they are not modified or deleted by accident. Draft items do not need to be secured and should be available for developers to read and modify if required.
Items that are secured should remain in this status until appropriate authorisation via change control has been granted. The user of a source control tool automates the task as such tools prevent a user from modifying a revision once it has been created.
Flagging items to be modified
When intending to modify a configuration item, the master that resides in the master library should be replicated and copied into the developers working area and a record maintained to indicate that a user is currently modifying the item.
Developers should not modify items that are reserved for modification by another developer.
The following information should be documented for each locked configuration item:
· The library the item belongs to.
· The revision that is reserved for modification.
· The person who is modifying the reserved item.
In addition to the above, it is beneficial to record the reason why the item has been reserved.
Updating master library
The master library should be updated once the reserved item has been modified. Returning the modified item ensures that the master library always contains the latest version of the configuration item. Since the master library is available to all authorised users then these uses will have immediate access to the latest versions as they are returned to the master library.
The following information should be documented on returning a locked item to the master library:
· The library the item is returned to.
· The revision being returned.
· The new revision generated.
· The date when the update has taken place.
· The person performing the update.
· A description of the change.
· Related change records and other configuration items.
Superseded versions should be archived to ensure that they can be recovered if and when required. . All superseded versions should be archived and a history record documented to identify when and why the modification was implemented.
The user of source control tools automates this task as these tools automatically create a new revision as the configuration item is returned to the master library.
A complete audit trail should be maintained for all items that reside in the master library. This audit trail should identify the following:
· The items that have undergone change.
· When they were changed.
· Who implemented the change.
· A description of the change.
· The revision number of the items before and after the change.
The user of source control tools automates this task, as these tools are able to document the above information as each new revision is created.
On a multi-user development environment, i.e. one where two or more developers are likely to modify a given configuration item, concurrent updates should be managed effectively. This involves one or more of the following:
· Preventing concurrent updates by reserving configuration items when they are being modified. Reserving configuration items enables one to synchronise the changes in a sequential manner.