configuration Management

"Configuration Management", or "Version Control", describes the technical and administrative control of the deliverable components. It applies particularly where components need to operate together to provide the overall solution. There will be thousands of components in the overall solution - each one must fit.
Configuration Management may be applied to all version-controlled deliverable s, for example:

• objects, code modules etc,
• specification documents,
• configuration settings,
• client operating system builds,
• user procedures and documentation.

More typically, it is thought of in respect of the various software components of the technical solution. Corresponding but less technical procedures would be used for Documentation Control.
All deliverable s may have different versions as they pass through various stages of development and revision. Software components often have multiple "latest" versions. For example, different versions of a given item might be in use in the current live system, also be under test as part of an update project, be under revision by a programmer in the development environment, and be having updates from its external supplier applied to the baseline version. Each of those four versions could have variations in the way it connects with other related components.

As well as the tracking the status and nature of multiple versions, there needs to be control over their access and usage. It is a common error to find two people have separately updated the same thing. Whoever finishes last gets the changes applied. The other changes vanish.
Another common mistake is to assume wrongly that you already have the latest version to work from.
It is easy to make mistakes due to poor version control. What is worse, because the developers did not think they were affecting the "lost" content, they might not realise that it needs to be re-validated in the testing. Errors can easily be released into the live system.
The main rule is, therefore, only one person should have the ability to update a controlled item at any one time. The library system should "check out" an item for update, and "check in" the item when the work has been completed, checked and approved for update. Various access and authorization rules will be applied to ensure people follow the procedures. You should make sure the controls are enforced physically with password systems, discrete environments, etc - but remember to allow for those operational emergencies when the library's owners are unavailable in the middle of the night.
The precise mechanism will vary. Tools are often specific to a particular software environment. You might find you need more than one tool where the project involves a combination of technologies.

At the Start of the Project

Configuration Management does not form a major part of the Project Definition work. You would probably agree that suitable procedures and tools must be used.

If the project uses an existing software environment, the organization should have suitable procedures and tools in place. If not, you should evaluate your needs and acquire appropriate Configuration Management tools.

 At the Start of the Development Work

Configuration Management tools will not normally be required until the Project Team starts working with the software. Early development work may not require version control where individuals have discrete parts of the system to work on. When the different components begin to be fitted together it is generally helpful to have them subject to version control.

By the time that components are ready for formal, controlled testing, an appropriate set of procedures and tools must be in place. Formal testing has to take place in a controlled environment, otherwise there is no proof that the components being tested have not been subsequently changed - which would invalidate the testing.

At the start of the work, Project Team members need to be briefed on the system and its importance.

Running the Configuration Management / Version Control Process

Operation of the Configuration Management / Version Control process might be a Project Office task, it might be a designated role within the development sub-team, or it might be a specific service within the organization's IT department. The custodian of the Library would administer the process, although good tools automate most of the work and allow "self-serve" subject to predetermined authorization and procedural rules.

It is helpful to understand the migration of software components between various environments or contexts. Software projects are normally undertaken in such a way that incompatible activities are separated from each other in different environments. One way of doing this is to have completely separate equipment for each environment. There are also many ways in which differing logical environments can co-exist as part of a single physical environment.

The minimum requirement for control is normally three environments:

• The live environment needs to be carefully protected. No components or revisions should be allowed into the live environment without proper testing, review and approval. Developers should not be allowed to update live components except in emergencies.
• The formal testing or Quality Assurance (QA) environment equally needs to be controlled and protected. There can be no certainty about the reliability of the results if uncontrolled updates and corrections could be taking place.
• The development environment, therefore, is where all the main work takes place, safely away from the protected areas.

Other environments might be desirable. Project Managers often debate precisely how many environments you should have. Obviously, each new environment means additional resources and control overheads. Some of the other common environments might be:

• Operational testing environment - where the system is tested with full-size transaction loads to see whether it has enough capacity. The technical configuration and components would also be "tuned up" to ensure adequate efficiency of processing. The environment might also be used for testing the operational procedures such as backup, recovery, running interfacing suites etc.
• Separate Project Team testing and User Acceptance Testing environments where there are two separately controlled stages of formal testing.
• Training Environment - where users can safely perform training activities with no risk of interfering with the live system nor accidentally sending a payment to "Mickey Mouse".
• Baseline environment - containing "vanilla" versions of externally supplied software components. These components form the reference baseline for testing whether an error was caused by the supplied code (or was introduced later by the Project Team), and for applying updates from the external supplier.

This diagram shows a typical flow of released components. The Configuration Management system would control the migration. Note how the development team might need to work on components that are currently released for testing or already live. They would check out the live or test version of the component but would not be able to check it directly back into the live environment without passing through appropriate testing.

  

At the End of the Project

Configuration Management is a continuing process that will be required for the full operational life of the system. The procedures, information and tools would be handed over to whoever has on-going operational responsibility for the support, maintenance and enhancement of the system.