An overview & Insight to Software Configuration Management
Article by: Swastika Nandi – A Guest Publisher of the article.
Following four obvious questions come to the mind of every software professional
Q 1. Can a software build be tested without knowing the build version?
Q 2. Can a software build be released into production without a build release note?
Q 3. Can a change in software system be implemented directly into production?
Q 4. Can a requirement specification document be circulated to stakeholders without base-lining it?
Questions like these are answered via Software Configuration Management or SCM.
This article tries to give readers an overview and insight of SCM.
Configuration management is a Software Change Control process, and it covers the processes used to control, coordinate, and track code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and
who makes the changes. It is basically managing the units that make up the software system through out the project or the product life cycle. This includes test ware, test results, build, delivery, incident, release note etc. It handles version control of various test documents and build documents. Release note is accompanied along with the version controlled source code build.Software application like VSS (Visual Source Safe), SVN (Subversion) etc facilitate SCM.
Controlling software changes requires both a configuration management process and a change control process. Both are described in the sections.
Software is bounded only by the limits of the human imagination. Software configuration management helps to check this uncontrolled and undirected, imagination limit.
The dynamic nature of most business activities causes software or system changes. Changes require well-formulated and well-documented procedures to prevent the manipulation of programs for unauthorized purposes. The primary objective of configuration management (or change control) is to get the right change installed at the right time.
Change control concerns should be identified so that proper control mechanisms can be established to deal with the concerns.
Some key points regarding changes include:
1) Each release of software, documentation, database, etc., should have a unique version number. Changes should be incorporated through new versions of the program. There should be a process for moving versions in and out of production on prescribed dates.
2) Procedures should exist for maintaining the production and source libraries. They should address when to add to the library and when prior versions should be deleted. Care should be taken to regularly review libraries for obsolete programs, as large libraries can negatively impact operations performance.
3) Project documentation such as requirements specifications, design documents, test plans, standards, procedures, and guidelines should also be identified with version numbers and kept under version control to ensure the project team is working with the latest, approved documents.
4) Other environmental considerations to keep under version control are the operating system and hardware, as changes to either of these have the potential for impacting the project.
Last but not the least, Configuration management has a number of important implications for testing. For one thing, it allows the testers to manage their test ware and test results using the same configuration management mechanisms, as if they were as valuable as the source code and documentation for the system itself. Also, configuration management supports the build process, which is essential for delivery of a test release into the test environment.
About the Author: Swastika Nandi is a guest publisher of the article & is solely responsible for the ownership of its contents.