Infrastructure activities are those that should be performed to define the SCM system being used. In an ideal scenario, these should be performed at the start of the project.
Some of the infrastructure activities are project specific, itemising configuration items for example, and some should be viewed as global, selecting an SCM tool and writing the SCM standard and procedure.
Implementing the infrastructure at the start of the project will help ensure that the system is mature and established by the time it will be required. Delaying the implementation of SCM infrastructure activities may reduce the overall benefits of the SCM and may reduce its effectiveness.
An IT system is generally made up of several types of configuration items many of which may not be developed and delivered by the project team. Some of these may be delivered by the operating system supplier, some by the tool vendors, some by the user or client, ... etc.
Whilst each of the involved parties may declare an interest and ownership of his/her own deliverables, the SCM system aims to deliver the complete IT system as a single integrated entity, irrespective of the owner or author of the deliverables.
Many project management and development methods break up the project life cycle into stages each with its own deliverables. Some project management methods advocate the splitting of a large project into many smaller projects but few methods attempt to address and cover all the stages, all the configuration items and all the parties involved in implementing a large system.
I suspect that many methods do acknowledge the need to address all the life cycles, parties and configuration items but choose not to due to practical and realistic constraints. How does one expect to apply a single method or discipline on all the parties involved on a large project?
The proposal put forward in this paper does acknowledge the real life constraints, however the proposal does not ignore the issue arising from these constraints.
There is a need to know the scope of the project in terms of its configuration items and how these are related. It is important that one is able to identify the types of deliverables expected as early on in the project as possible.
Itemising the types of deliverables expected will enable one to gauge the complexity of the project in terms of the relationships between its deliverables and will also identify how the various parties are involved and when they are likely to be involved.
Itemising deliverables should take place in the early stages of the project. If the project aims to deliver a new system into an established architecture, a Windows system implemented using Visual Basic for example, then one should be able to identify the types of deliverables even before the analysis and design work has commenced. In the above example the system may be made up of the following component types:
· Visual Basic run time components, VBRUN200.dll for example. These are provided by the Visual Basic supplier.
· Windows OLE dynamic link libraries. These are provided by the operating system supplier.
· Visual Basic initialisation file. This is provided by the Visual Basic supplier but needs to be modified by the project.
· Visual Basic custom controls. Some of these are supplied by the Visual Basic supplier, sum by third party suppliers and some may be developed by the project team.
· The compiled application. This is created by the development team.
· The application initialisation file. This is created by the development team.
Note how the example above shows configuration items being delivered by many suppliers. Notice also how the control of the various types above may be assigned to different departments of the organisation, for example:
· Roll out of the operating system may be controlled by the operations department. They are responsible for supporting and upgrading components that belong to the operating system.
· Roll out of the development tools and its add-ins may be by the tool support group.
· Delivery of the application and some of the custom controls is the responsibility of the project team.
You should also note that some of the above components may be shared by different projects and systems.
The itemisation task does not need to be an arduous task, consultation with the various parties who own or control the component types should produce a reasonably complete list of configuration items to monitor and control.
Representing the data in the form of a diagram or schematic would enable one to easily identify what items need to be controlled, where they reside and who normally has access to them.
The sections below identify the various types of deliverables that may make up a system
Most IT departments deliver systems that will run and operate on the existing technical architectures. The term technical architecture is used to describe the:
· Operating system,
· Network,
· Hardware platform,
· Network protocols,
· Security and access control mechanisms.
If a system requires additional configuration items to enable it to operate within the chosen architecture then these should be identified and documented. This is a vital consideration as some changes to the technical architecture may have profound impact on the application being developed or supported.
Case Study 1: The rogue API call.
An organisation had over 80 installations of a tool that was designed to work with MS Windows. The product was being used with Windows version 3.1. A detailed evaluation of Windows 3.11 was performed and this was then rolled out across the organisation. On attempting use the tool, an incompatibility was identified. Close examination of the problem revealed that the tool employed a mechanism for accessing the user name that was no longer supported in the new version of Windows. The offending component was a small dynamic link library that was still being delivered as part of the upgrade, but some of its functions no longer operated as with the previous version.
Identifying the technical architecture related items will enable one to identify the interfaces between the application and the architecture and hence identify the scope of change if the architecture is to change or if the system is to be operated under a different architecture.
Identifying technical architecture items will also enable one to identify deliverables that may be required from the teams that support and own the technical architecture, operations for example.
The advent of Dynamic Linking, through the use of dynamic link libraries (DLLs) for example, makes the need to identify the architecture very important. Some DLLs are operating system or architecture specific, by calling such DLLs one may eliminate the need to write bespoke programs or may be able to write an application that is closely linked to the operating system. The itemisation task should identify and document instances where such DLLs are being used. This is important as all the target environments must have a copy of the DLLs that are being called by the application. If these DLLs are missing, due to differences in the technical architecture, then the application will not run.
Case Study 2: Know your target environments.
UNIX systems can be purchased with a standard text interface or with a graphical user interface (GUI). If an application is developed that makes use of the GUI, then the GUI component of the operating system should be installed.
I recently came across a problem while installing a configuration management tool on an AIX platform. The supplier of the tool stipulated that a particular version of the GUI should be installed on the system. This was purchased and installed together with the configuration management tool. When the tool was run several error messages were displayed indicating that a DLL was not found or missing.
The supplier proposed that either the GUI was not installed correctly or that the user did not have the correct permissions to access the required DLLs.
The GUI was installed again. A detailed search for the required DLLs showed that they were still not on the system. A call to the supplier of the AIX system revealed that the DLLs were only available to AIX users who hold the GUI developer's license.
A call back to the supplier now brought an admission that the tool was built using the incorrect set of DLLs. The build process had used the developer's version of the DLLs rather than the run time. Given that not all target systems have the developer's version, and given that the documentation had failed to stipulate this requirement, it is not a surprise that the application would fail on some of the target installations.
Architecture items that are used in this manner should accompany the system when it is released to target environments. Also the version of the architecture components used must be compatible with those that are on the target system.
Itemising the technical architecture components is not enough. One also needs to identify the version or variant used. This is particularly important when using Windows that has a number of coexisting variants. I recently developed an application for a client using MS Access for Windows. I developed the application under Windows 95 and produced a distribution disc. The application made calls to a number of Windows DLLs that I included on my distribution disc.
Installing the application on a Windows 95 system was OK.
Installing the application on a Windows 3.11 was OK.
Running the application under Windows 3.11 was OK.
When my client came to use his system with other Windows applications, none would work!!
These are configuration items that are developed by a third party supplier but which will form part of the system when it is installed. It may not be possible to itemise such items at the start of the project, however, where possible one should attempt to segregate these from all other classes of configuration items since these will have their own development life cycle that is driven by the third party supplier.
The term segregate implies that third party configuration items should be separated from those developed in house. This can be done by either storing these items in their own directory structure or by adopting a naming convention that will logically segregate the items.
These are the configuration items that will be produced by the various development teams working on the project. For these, one should attempt to itemise each configuration item and its type.
The development tool used to implement the system will invariably include components that have to be installed on the target system for the application to run. These may include the following:
· Tool runtime modules.
· DLLs
· Data files
· Documentation
Itemising the tool specific components is important as these must be installed on the target system and also need to be replaced in the event of an upgrade.
Tool specific components should be static, with updates being made at release dates from the supplier.
This by far is the hardest to identify and control. Identification is difficult because architecture data is determined by the operating system being used and the design of the application. Control is generally difficult for one or more of the following reasons:
· Technical architecture data may need to be different for the various environments that the application is going into;
· The actual data may change as the structure of the environment changes;
· The responsibility for maintaining and updating the architecture data is generally the responsibility of an “operations” type organisation which is independent of the developers;
· The update and maintenance of the architecture data is generally seen as part of the day to day administration of the system and hence difficult to control using formal change control;
· Some the static data may be shared across several applications, resulting in potential conflicts when one application architecture is modified.
Following are examples of architecture data;
· UNIX profiles,
· DOS autoexec.bat and config.sys files,
· Windows “.ini” files,
· User password and group files,
· UNIX mount tables and DOS shared drive mappings,
· General assignment files and wrappers.
Case Study 3: Are you pointing where you should.
I worked on a project that had several formal testing stages that included system testing and user acceptance testing. Each type of testing had its own dedicated run time and data directories. Due to the phasing of the project, the version being system tested was not always the same as the one being user tested. Also the data used for both types of testing was different.
Access to the various environments was using separate PCs, each had its own start up routine during which a number of assignment files were read. These assignment files established pointers between the PC and the environment being used.
A problem came to light when one of the testers encountered some unexpected errors, errors were being found that had been tested and corrected in an earlier release. These were raised as faults to be resolved by the change control process.
Close examination of the faults revealed that they were not related to the latest changes to the system being testing. These errors could have come about if one of the following had taken place:
o The release co-ordinator had released code into the incorrect environment. Investigations revealed that this had not happened.
o The release co-ordinator had used the incorrect source to produce the run time. Investigations revealed that this had not happened.
o The developers had updated the master library with the incorrect version of the source. Investigations revealed that this had not happened.
Having confirmed that all the possible causes were investigated, questions were directed at the testing team. Is it possible that the fault was always there and that the testers had not detected it in previous testing?
The problem could not be resolved until a tester complained that some new features had appeared that were targeted at the next release of the system. This immediately triggered another flurry of investigations that included close scrutiny of the system being tested. This now revealed that the tester was in fact working with the incorrect version of the system.
A discussion with “operations” revealed that they had been upgrading some of the start up files over the week end. When these where checked, the cause of the problem was found. An operator had replaced a start up file with an incorrect version hence forcing the user to access the incorrect test environment.
All applications must have data of one sort or another, application data is that which is used by the application and is independent of the technical architecture data mentioned above. Application data can be classified into the following:
· Tool data,
· Static user data,
· Dynamic user data.
Tool data takes many forms and is determined by the application tool being used. This may include the following;
· User profiles data,
· Security data,
· Tuning and performance data.
Tool data is generally maintained by a “tool expert” or “guru” who generally has responsibility for administering and supporting the tool. Maintaining tool data is generally seen as a day to day activity hence making formal control difficult.
Static user data, as the name implies, is static data that the user supplies to enable the system to operate, the chart of accounts is a good example. Controlling this type of data should be easy as long as one is able to identify that the data is static.
Dynamic user data is the data that the user maintains and modifies using the application being developed. This data should not be included in the scope of the configuration management process and should be controlled using the user business processes and controlled by the applications internal security and auditing features
Defining the life cycle for configuration items is very important. The life cycle essentially defines the activities that will act on the configuration item from the moment it is created to the time it is taken out of service.
One must be realistic and pragmatic when defining the life cycle for any given type of deliverable. The life cycle should be appropriate for the level of change that the item is likely to undergo, the party that is responsible for implementing the change and the impact of change on the integrity and reliability of the system.
A null life cycle should be considered where necessary, as attempting to impose a life cycle for items that cannot be controlled may be costly and may undermine the complete SCM.
It is remarkably how many organisations fail to define life cycles for configuration items. Life cycles are generally defined for the implementation of the project management method, but rarely for individual types of configuration items. How can one hope to manage the configuration of a complex system if the life cycles of its constituents are not defined and documented.
In simple terms, the life cycle of an item defines the states that the item may go through during its development and use. By identifying the life cycle one is able to:
· Identify the events that trigger the change in state;
· Identify the party or parties who are involved in triggering the change;
· Identify the party or parties who will be involved in implementing the change;
· Identify the parties who should monitor and control the change;
· Identify the parties who should approve the change.
Life cycles need not be complex. The following generic life cycle covers most of the common states.
Figure 1: Generic Life Cycle
The above life cycle shows how items start as draft they then assume the approved status, then are baselined and finally released. Different development and configuration management processes need to occur to trigger the changes in state.
Having identified the basic types of configuration items' one should apply the generic life cycle, omitting states as appropriate for the control required.
As the name implies, static items should not change and should have a null life cycle or one that has a limited set of states, draft and approved for example. Draft is when the item is being created or acquired and approved when it is accepted.
Where possible one should aim to fully itemise static items and if possible place all such items in a single location. If static items are dispersed across the system then a method of identification should be defined and implemented.
Centralising the storage of static items will enable the configuration management function to devise an effective method for monitoring such items to make sure that they are actually static.
Always monitor the change date on “static” items. It is remarkable how often such items do change.
Case Study 4: Mutton dressed as lamb.
A number of months ago I came across an interesting experience. Having consulted the project team and itemised all the configuration items that relate to the system, 2000 in total, I created a number of UNIX scripts to monitor the changes to all items within the system testing environment. The reports were rather confusing:
o Many items that were defined as static were actually being modified;
o About 1800 files that were defined as being under development were completely static
o The total number of files within the testing area exceeded 12,000, whilst the project had only declared 1800.
Why the discrepancy?
Several meetings later, the technical guru on the project declared that the 1800 files that are under source and change control are expected to change once or twice a year (at each release of the system) and therefore could be placed under strict configuration control, the remaining files where likely to undergo much change and could not be placed under change control as this would have affected the project delivery date.
When static items do change, then one should identify the name of the author of the last change. This is easy when using UNIX but may be impossible if using DOS.
Where such static items do change, and one is unable to identify why, then operating system security should be applied to protect such items. This may either identify the offending process, e.g. a program that modifies the file, or the offending party.
If secured items still change then the scope of investigation should be narrowed to those with sufficient privileges to over ride the applied security mechanisms.
Third party items generally undergo change on a periodic basis. The process for accepting and releasing such items is obviously determined by the type of item and its supplier. Periodic releases from of technical architecture items will obviously require a different life cycle than releases of application components.
Particular care should be taken when handling third party items that need to be customised before they are incorporated into the system.
It is good practice to fully itemise each periodic release. When doing so, make sure to record each item, it's last modify date and the size of the file.
Under DOS you may wish to modify the date and time stamp to a predetermined value to enable easy identification of items that belong to a given release.
Figure 2: File date and time stamps
The listing above shows the contents of the directory that is used to store a copy of a windows accounts package. Note how the majority of the above items have the same date stamp of “12/5/94” and the same time stamp of “09:00:00”. Two items have different date and time stamps:
· qbw.ini. This is an initialisation file and one would expect it to change if the application features and options are modified.
· Qbwin.log. This a log file maintained by the tool as it is being used.
Date and time stamping items is reasonably simple and one can easily monitor change by assigning all files the same data and time stamp.
Items that undergo development should have a full life cycle with all the states listed in the generic life cycle. Tracking the state of each item is very important as this will help establish a consistent baselines with all items at the correct state at the point of release.
It is only necessary to monitor items that have approved, baselined or released status as these should change if the appropriate change procedures are invoked. The implication of the above is that items that can change while under development may be classified as static once they are approved, baselined or released.
Items that undergo change as the application is used, user data, journal and transaction log files, cannot be controlled or managed using the SCM.
One hopes that the application is able to track such changes and that the backup procedures are able to re-produced required files as and when required.
Such items have one status, draft, and one would expect them to undergo change as the tool is used, regardless of the environment that they may reside in.
It is a good idea to attempt to group all files that belong to this class in a single set of directories. Once such items are together one is assured that they will not appear in any of the statistics being generated by the monitoring programs mentioned earlier. Case 4 above mentioned that the application had over 12,000 files, several thousand of these were data file that changed on a regular basis. Filtering these files out of the statistics helped flag genuine cases of change.
Environments are physical disc partitions or locations that are used to store configuration items. Environments are key to the operation and success of the SCM. An effective environment structure will facilitate:
· Assist in enforcing the use and adoption of the configuration management system;
· The segregation and identification of different types of configuration items;
· Control user and developer access to configuration items;
· Control and where necessary prevent intentional or accidental modification of configuration items;
· Facilitate the movement and release of configuration items;
· Facilitate the monitoring of the state of items, in particular the last modify date.
An environment that allows one to store static items, with third party items with items being developed internally is likely to be more difficult to monitor and secure than one that segregates items of different type.
When constructing the environments, make sure to take into account the security mechanisms that are supported by the operating system. Setting permissions and ownership within UNIX is very simple, achieving the same under PC based operating systems is much more difficult.
The basic types of environments are listed below:
· Development
· Master library
· Build
· QA
· Production
The development environment is generally classified as managed, e.g. its structure should be managed but its contents do not need to be controlled.
The remaining environments are classified as controlled, e.g. their structure and contents should be fully controlled.
The relationship between the above environments is represented in the following diagram.
Figure 3: Environments
The development environment is the area where items are modified and developed. The maintenance environment is similar to development but is used to support the implementation of change to a version of the system that is currently live and different from the one that is being developed.
The master library is the environment where master items are stored and protected. This area is generally implemented using a source and version control tool.
The build environment is the area where run time is produced using configuration items that have been obtained from the master library.
Movement of run time from development and maintenance into the build area should not be allowed. Physical and security mechanisms must be used to prevent this movement.
QA environments are used to perform formal testing. This may include system testing, acceptance testing, regression testing, ... etc.
Movement of run time from development and maintenance into the QA area should not be allowed. Physical and security mechanisms must be used to prevent this movement.
Production is the area that is used to support the live system.
Defining the environments may be relatively simple. Ensuring that physical areas are easily identified as belonging to a given environment may not be as easy!
The advent of networked PC systems has complicated the task of identifying environments. Once environments have been created, check that users are able to easily identify the area that they are using and also identify the environment that this area belongs to. This can be performed by assigning users different log on ids for each different environment.
The use of environments need not be governed by complex rules. A simple set of rules can define how the environments should be used to achieve maximum benefits.
· Developers can add files to the master library as and when needed.
· Nothing gets assigned an approved status unless it has a signed off approval record and where necessary an authorised change:
· Release into controlled environments can only take place through the master library:
The above rules are very simple to communicate to developers and easy to implement.
The use of a source control tool to implement the master library can enhance the benefits of the environments as the source control tool:
· Prevent the deletion of approved revisions;
· Generate a complete audit trail of all changes;
· Provide an easy to use mechanism for moving items from the master library and into controlled environments.
An effective and secure environment structure is one of the cornerstones of a good configuration management system.
Many organisations fail to address the need to support instances of environments. For example, if one is supporting two versions of a system, then should one have a single development environment. Or does one need to have two instances of this environment?
The price of disc storage has come down considerably over the past 10 years. The first 500MB disc that I purchased about 10 years ago cost over £12000. A similar disc will cost about £100 today. With this in mind, I generally recommend that each strand of development be supported by its own set of environments.
Allocating separate environments to separate instances of the system will prevent or reduce the risk of cross over between instances, releasing code that belong to one system with code that belongs to the other.
Environments should be identified at the initiation stage and should be based on the system test and build strategy. Given that creating additional environments may require the procurement of extra disc, or hardware with their ensuing delays, it is better to be prepared than be faced with an urgent requirement without the means to provide the required solution.
Once the various environments have been defined and once the different types of configuration items have been identified, directory structures should be created to facilitate the development and the configuration management processes.
Unfortunately, a directory structure that facilitates development, is not necessarily a structure that facilitates configuration management.
As a rule, all the environments that are defined as controlled should have identical directory structures. The development environment should be split into two separate areas:
· User working areas. These are owned by the individual developers and may reside on their personal drives.
· A collective system development area. This resides centrally and is used to perform the last level of development and testing before the items are moved into the master library.
User working areas are generally uncontrolled and their structure and contents is dependent on the individual developer. This enables each developer to feel at home and in control of matters that affect their day to day work.
The collective system development area is a managed area that has a directory structure that matches the target controlled environments. This is an essential area as it allows developers to make last minute changes to application and data files before they are moved into the controlled area. Many organisations fail to provide this area resulting in a need to modify data files once they have been released into the controlled environments.
Where possible, directories should be created to store different classes of configuration items as classified earlier on during the itemisation process. Static files should be stored together, application files should be stored together, ... etc.
Grouping similar items together is important as it facilitates the monitoring of change and enables effective security control.
Each environment requires its own set of users and permissions. Controlled environments should be predominantly read only areas.
Within each environment , directories should be assigned permissions that are consistent with the life cycle of the items that they contain. A directory that contains static items should be write protected for example.
As a rule, developers who have read/write permissions on a development environment should not be given write permission to a controlled environment. The only exception to this is the master library.
There appears to be a general trend to automate processes using tools and configuration management is no exception. What many organisations fail to recognise is that no single tool is able to provide a complete SCM system.
CM tools are most important when it comes to operating the SCM system, they are not as important when it comes to defining it. Close review of the most popular CM tools, SCCS, CMS, PVCS and RCS, will quickly reveal a considerable resemblance. The tools may differ in their user interface, but below the surface, all are practical identical.
Organisations that have performed the tasks listed under “Itemising Configuration items” are well ahead in establishing an SCM. The selection of the necessary tools should be of secondary importance.
While automating, some organisations appear to reduce the scope of the SCM process to reflect the features that their tool provides. The correct approach should be to complement the tool with manual procedures rather than reduce the scope of the SCM process.
The configuration management process can be simplified by adopting one or more of the following tools:
· Source control tool:- this is used to deliver the necessary controls to construct the master library and to keep track of versions of individual configuration items.
· Build management tool: - this is used to automate the task of generating the run time from the source. Build management tools are becoming difficult to use or redundant as development moves from a 3GL to a 4GL environment.
· Release management tool: - this is used to automate the release of items between environments. This tool would also be used to keep track of what has been released to each individual environment. There are practically no release management tools on the market, and many organisations have been tempted to ignore this process altogether.
· Master index or configuration management database:- this is a reporting tool that is used to keep track of the contents of the master library and all other controlled environments. There are practically no tools on the market to deliver this functionality.
· Change management tool:- this is used to keep track of all issues, changes and faults. There are many change management tools on the market, many of which offer considerable functionality most of which is not really necessary.
Unfortunately, trends now taken for granted with general office tools, have started to make inroads into the CM tool market. These tools are now becoming large and complex, the days of the simple yet reliable and effective tool are quickly coming to an end. CM tools still remain the one area where simple is beautiful.
Case Study 5: The 9 minute wonder.
I had a call from a project manager regarding the configuration management requirements for his project. System was due to start in two weeks time and the manager expressed a need for a tool to track faults detected during testing. A short meeting revealed that the manager did not have a clear idea of what he needed and how it was to be used. I proposed to develop a simple system using MS Access to demonstrate what he may need. The manager agreed. Together we produced a single table, single form prototype in about 9 minutes.
The manager demonstrated the prototype to his team and six months and 800 fault reports later, they were still using the same prototype.
If it works then use it.
Whilst a project may require several tools, as listed above, not all are required from the beginning of the project. Realistic deadlines for employing tools are as follows:
· Master Index: from the start of the project.
· Source control tool: as soon as the first deliverable is produced.
· Change control tool: from the start of unit testing or following the start of approval.
· Release management tools: from the start of system testing.
The above may represent a dilemma for the following reasons:
· Most source and version control tools do not come with an integrated master index. Hence making it necessary for the project to develop its own in house master index. Given that most of the information that should reside in the master index is generally generated by the source control tool, one cannot realistically develop the master index without first procuring the source control tool.
· Most source control tools do not come with an integrated change management feature. Tools that come with a change management feature are generally large and complex configuration management tools that require extensive effort to install and configure.
· Nearly all tools lack a release management feature. Software distribution tools are starting to appear but most do not integrate with either of the low end source control tools or the high end configuration management tools.
Having identified the necessary tools, procedures should be drafted to enable the users and administrators to operate the system.
Where possible, include the CM procedures into other development procedures. Of all the CM processes mentioned in this document, the change control and release management are the only that warrant their own procedures. The remaining should be integrated into other procedures. This has the following benefits:
· Brings CM back into the development process (where it belongs) rather than treating it as a stand alone process.
· Highlights the need to perform CM tasks as deliverables are implemented rather than at the end.
· Integrates the CM into other development procedures and minimises the likely hood of a mismatch between procedures.
· Producing a large number of CM related procedures may give the wrong message to developers and managers; CM is not an extra process, CM is part of development.
The following CM processes need to be defined:
· Labelling and identification.
· Source control.
· Version control.
· Approval and testing.
· Change control.
· Build management.
· Release management.
The above processes should be included with other development standards and procedures. Following are examples of how this can be done:
· Labelling and identification can be added into the various programming style guides under the topic of naming conventions. Addressing naming conventions as part of a programming style guide is a good idea as many tools impose their own restrictions and recommendation on how items should be named and labelled.
· Version, source and approval should be included as part of the testing procedures. Testing standards define how one should document and perform testing. Adding version control enables one to establish a link between changes to correct test faults and incrementing the version number. Adding source control enables one to identify the need to save old revisions and enter a change history as result of correcting faults from testing.
Avoid producing procedures that act as user guides to the CM tools being used. If a heavy weight tool is adopted, then extensive training and documentation may be required.
When developing procedures, do not overlook that fact that some CM tasks are targeted at the user and others are targeted at the administrator. I generally recommend that these be separated.
Integrating the CM procedures into general development procedures should minimise the need for specific CM training. Many organisations manage with minimal training in this area.
Training on the use of CM tools is a different issue; some CM tools are very complex and may need extensive training. On the other hand some of the simpler tools can be picked up with minimal training.
Case Study 6: Simple tools are easy to use.
I worked on a large site that had very limited experience with CM tools. The organisation was in the process if down sizing its system and moving them to a Windows environment. A CM system was required quickly and at minimal cost.
Instead of adopting a fully fledged configuration management tool, we chose to make use of an established source control tool. The CM system was then developed to exploit the major features of this tool and training course prepared that showed how the tool should be used to support the CM system.
In house training was conducted for over 80 developers. The three hour course covered all the user commands, included a detailed handout of how to use the tool, and examples of all the major problems that are likely to be encountered.
This is a key configuration management document that defines how the SCM will be applied within the project. There are remarkably few standards for the configuration management plan.
A major problem with the CM plan is positioning it relative to other documents including;
· Project quality plan,
· Project plan,
· CM standards,
· CM procedures
There is considerable overlap with all the above documents and the resulting overlap can be confusing.
Organisations that do not produce a quality plan and/or CM standards and procedures should produce a CM with the following contents:
· Outline description of the CM process.
· Detailed definition of the main CM processes. These include:
o Change control
o Version control
o Source control
o Naming conventions
o Approval procedures
o Build management
· Release management
· Detailed definition of the environments to be produced.
· System phasing and build strategy.
· Roles and responsibilities.
Organisations that produce a quality plan and those who do have documented configuration management procedures should define the following in the CM plan:
· Outline description of the CM process
· Cross reference to other standards and procedures
· System phasing and build strategy
· Detailed definition of the environments to be produced
· Roles and responsibilities
A CM plan that is produced by the configuration manager is likely to end up filed away. Most of the CM plans that I have come across take a long time to produce and rarely get used.
This is mainly because the CM plan is used as a working instruction rather than a contract between the parties involved on the project.
Writing a CM plan that acts as a contract can transform this document into a powerful tool: This can be done by assigning the various CM sections to authors in the following manner:
Outline description of the CM process. This is best produced by the CM administrator or manager. This section is really a primer and aims to define the overall process.
Detailed definition of the environments to be produced. Setting up and maintaining environments is likely to be performed by a service group within the IT department. This group may be independent of the project or the CM function. The section on environments and how they will be produced and secured should be produced by the party that will be responsible for performing this work. Having produced the document, this party should be made responsible for implementing it.
System phasing and build strategy. This should be assigned to the project manager who will be responsible for defining the phasing of the project. Many of the requirements of the CM system are determined by the phasing of the development process. Major changes to the phasing of development may impose considerable strains on the system. This is particularly important when management chooses to allow parallel phases of development.
Roles and responsibilities. This should be assigned to the project manager. Given that the project manager has the ultimate responsibility for managing and allocating project resources, it is only right that the manager is given the opportunity to appoint and empower the required staff.
Several roles are required to support the CM system. On small projects, up to 30 staff, most can be operated by a single person.
The main roles are listed below:
· Project manager. This is the person who has the final responsibility for the effectiveness of the CM system. Given that the project manager is responsible for delivering the system, it is only correct for him/her to ensure that adequate resources are provided for all processes including the CM process.
· Change co-ordinator. This is an administrative role with responsibility for operating the change control process. Careful design of the CM process may enable one to appoint relatively unskilled staff for this role.
· Release co-ordinator. This is an administrative role with responsibility for moving deliverables from the master library and into controlled environments.
· Change approval board. This is a panel of managers, users and technical staff who have the responsibility for making decisions on whether or not changes can go ahead.
· Configuration librarian. This is certainly a full time post if a source control tool is not being used. The role becomes practically redundant if a good source control tool is used.
Some organisations appoint a configuration manager who has the responsibility for identifying and assessing the impact of changes. This can be a very technical post requiring a person with extensive development experience. I generally recommend that this post be delegated to development staff with the project manager acting as a reviewer.
Assigning clerical or administrative staff to the clerical CM tasks helps improve the quality of the service and reduce the operational costs of the CM system. Technical staff rarely make good administrators as many view administrative work as being menial.
Assigning the task of assessing the impact to development staff enables one to focus accountability; if development do not perform this task well, then development will have to spend more time implementing changes.
A good CM system is one that can be operated by the project without the need for any additional overhead or skills.
Provided that the project has adequate CM tool support, and provided a source control tool is used effectively, then most of the remaining CM processes can be performed by relatively unskilled users.
The key skill required within the CM process is that which relates to the assessment of the impact of change and how best to implement changes. If delegated to development staff, no additional skills will be required.
The best CM systems that I have implemented relay on clerical staff with little or no IT experience.