Within this report I will discuss why software configuration management is important. I will introduce four principals of configuration management; configuration management planning, change management, version & release management and system building. I will also cover standards within configuration management and version identification.

Lehman's first ?law? draws attention to a basic property of software systems, which is they evolve or die. One reason there is software change is new requirements, improvements are thought up and old ones become obsolete, evolving technology may cause this. Lehman's second ?law? points to a fundamentally important precept that, when there is software change work has to be done to preserve quality of structure, let alone improve it if need be.

Configuration management is the development and application of standards and procedures for managing an evolving systems product. As discussed above there is many reasons for management of systems, another reason is many different versions within one system. Different versions involve proposals for change, corrections of faults and adaptations for alternate hardware or operating systems. Configuration management keeps a track of all changes made and how these changes have been implemented into the software. Configuration management procedures define how to record and process proposed system changes, relating to system components and methods used to identify versions of system. Configuration management tools are used to store versions of system components, build systems from components supplied and track the releases of version to the customer. Configuration management is sometimes seen as a general software quality management process this could be because manager share quality management and configuration management responsibilities. I have produced a simple diagram to clearly show the root from developer to configuration management;

Configuration managers are responsible for keeping track of differences between versions, ensuring new versions are derived in a controlled way and releasing new versions to correct customers at correct time. I can here you saying why have different configurations? The answer is many reasons for different configuration;

? Different computers (dell,hp)

? Different operating systems (linux,windows)

? Different client-specific functions

This diagram shows an example piece of software with different configuration and how one configuration can have others based on it.

Configuration management process and associated documents should be based on standards such as IEEE 828-1983, which defines standards for configuration management plans. The standard should be published in the configuration management handbook or part of the quality handbook. Many standards can be used because all include important comparable processes. Taking some models as examples, ISO 9000 and SEI's capability maturity model, organisations must define and follow formal configuration management standards for quality certification. Waterfall model the software is delivered to configuration management team after development complete and individual components tested. The team then takes control of builds and testing of complete system. If any faults are discovered during testing, the specific component is passed back to developer for repair then passed back to configuration management when fault is fixed. This approach influenced the development of configuration management standards and these have an embedded assumption that a waterfall model of the software process will be used for system development. Some organisations have therefore developed to configuration management that supports concurrent development and system testing. This relies on very regular (daily) build if the whole system from its components:-

? Time will be set for component delivery. All new versions must be delivered even if incomplete but should provide some functionality.

? New version is built, linking all components to make complete system.

? It's then sent for testing, developers still work on components on previous faults and functionality.

? Faults found are documented and returned. These are repaired for next version.