The History Of The Software Configuration Management

Published Date: 02 Nov 2017

Introduction

In this lecture, the objectives and benefits of software configuration management (SCM) are identified. Also, the various tasks of SCM are explored, such as configuration identification, change control, and version control. Finally, the best practices of SCM are presented.

Learning Outcomes

Appreciate the objectives of SCM and its importance.

Be familiar with the tasks and best practices of SCM.

23.0 Introduction

Software Configuration Management (SCM) is a technique used for monitoring and preserving the reliability of software throughout its life cycle. This includes establishing configuration settings, and managing, and reporting changes/alterations and

23.1 Software Configuration Management (SCM) Fundamentals

SCM is the process of maintaining, managing, and controlling software packages in order for them to evolve and continuously improve and as a result, produce a higher quality with less faults/errors. SCM can be thought of as an umbrella technique that facilitates the initiating, evaluating, and the control of changes/alterations to software products, during the coding stage and once the product has been fully developed.

In the early days of software engineering, software was relatively small and easy to monitor and control using SCM. However, this is not the case nowadays due to the complexity and interlinking of the software which makes software configuration a much more complex task. The IEEE standard for software configuration management defines SCM as the "forming of good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance". SCM improves the quality and integrity of software by:

Establishing a configuration for the creation and monitoring of documentation, code, databases, and user-facing interfaces to assist throughout the software life-cycle.

Assisting the development and maintenance approach which works towards the achieving of the requirements of the software and the management style of the project.

Creating continuous product information in regards to updates and new versions of a piece of software in terms of documenting the changes, how they were carried out and how they were tested.

Software Configuration Management (SCM) is a technique used to manage alterations/modifications. It monitors the modifications that occur on various documents. A collection of documents without any configuration management could lead to major consequences. An example of this occurs when a document can be opened by more than one user at the same time, with the ability to modify it. The following is a scenario of what happens when a document is opened and modified at the same time:

User A opens up a document and modifies it.

User B opens up the same document, at the same time and modifies it.

User A, completing his modifications, saves the document.

User B, completes his modifications and saves the document, overwriting user A’s save.

The above scenario illustrates the problem of allowing more than one user to work on the same document at the same time, as user A thinks he has modified the document and saved it whereas it has been overwritten by user B’s alterations.

This problem would not occur when using a SCM system as no overwriting would occur. This is achieved by the merging of the changes by user A and B instead of overwriting the changes of user A with user B’s changes. The SCM knows that there are two user working on the same document at the same time and is able to recognize and compare the changes made by both and merge them together once both changes are completed.

The objectives of SCM are as follows:

Configuration identification: Establishing suitable configurations of the software and creating baselines.

Configuration control: Establishing and carrying out a planned and controlled change process.

Configuration status accounting: Accounts the progress of the development process through documentation and reporting.

Process management: This makes sure the development process is followed at all times.

Environment management: This involves the management of the environment that operates the software/system, including software and hardware components.

Teamwork: Assists the interaction and communication between members of the project.

Defect tracking – This allows a fault in the software to be tracked back to its source. In other words, the location of the initiation of the fault will always be discovered.

The benefits of using SCM are as follows:

The building/developing of software can be automated, saving time and effort.

Errors/bugs which were discovered in earlier versions cannot be re-programmed into newer ones.

SCM allows the documentation of the various software products produced by a company, including the changes/alterations carried out on each one.

The complexity and size of software projects nowadays where many teams who are not geographically connected can be working on the same project at the same time is ever growing, which can lead to confusion and lack of communication between the members of the project (as well as changes being overwritten etc). This can all be avoided using a SCM system.

23.2 Software Configuration Management (SCM) Tasks

There are five tasks in the SCM process. These are:

Configuration identification,

Change control

Version control

Configuration auditing

Reporting

Configuration identification: This is a central task of a SCM system. It acts as the first step which influences the succeeding process(s) to follow. It is a task that sets-up the configuration process in the shape of identifying the software components that need defined, their relationship with one another, and establishing a suitable method for configuration.

Change control: The task of the change control is to establish a process which is used when handling change requests, from the moment they are initialized till the change has been implemented and re-published back to the users. The change process which is established should be able to recognize the change request, evaluate it, and carry it out.

Version control: Version control can be thought of as an archiving system where various versions of software are kept, in case they are needed to be used in the future. This task automates the changes that are carried out on a particular software/document by using a ‘check-in/check-out’ system where on user checks in when initially opening up a document, makes his changes and then checks out when finished. This can be done by multiple users at the same time and the version control is able to maintain a history of the changes that have took place.

Configuration auditing: This is a software quality assurance process task which monitors/audits the quality of the changes being made, making sure the desired standard is being met and the correct procedures when carrying out the changes are being implemented.

Reporting: The reporting task of a SCM provides updates/information on the progression of the change, as requested by the various stakeholders, be it the end-users, the maintainers, the developers, or the project/organization manager.

23.3 Software Configuration Management (SCM) Best Practices

In order to produce the best results and maintain the highest standard possible, the following SCM best practices must be carried out at all times:

Identify and store artifacts in a secure repository: There are certain documents which are crucial to the correct running of a system/software, such as a project plan, the design model of the system, or the low-level structure of the software. These need to be placed in a secure, protected place as they are vital for any SCM to be carried out on the system, due to them being a reference point which will be used every time a change is requested.

Control and audit changes to artifacts: Once these documents have been identified and safely stored, access rights have to be established, i.e. it must be decided on who has access to these documents and is able to modify them. As well as this, monitoring and recording these modifications has to take place as well as the reasoning behind it.

Organize versioned artifacts into versioned components: When a system has a large number of files/directories, it is best to group them into a small number of objects in order for them to become easier to handle/manage. These grouped files (which are grouped into ‘objects’) can also be called ‘modules’, ‘packages’, or ‘development components’.

Create baselines at project milestones: For every project, there are milestones which need to be met. Once these milestones are reached, the documents/files/components that make up the system should be base-lined. In other words, the components making up the system should be saved and archived once a milestone is reached. This is repeated at every milestone to ensure that if the system fails between milestones, a back-up can always be used.

Record and track requests for change: Every time a request for a change is induced, either by an end-user, maintainers, or developers, the request has to be recorded. As well as this, the progress of the request also needs to be recorded and tracked, whether the request is implemented or not.

Maintain stable and consistent workspaces: A workspace, a "private file area where developers can implement and test code in relative isolation" needs to be provided for developers in order for them to produce a high level of productivity. As well as this, the developer’s workspace needs to consistent with other workspaces of other developers (working on the same project or other external projects). This decreases the chances of any confusion and miscommunication between the developers if/when they need to work together.

Support concurrent changes to artifacts and components: In an ideal world, a component which has a change request would be worked on by one person or one team. However, this is not efficient and many request are worked on at the same time on the same component. An example of this can be found when one team is working on developing a newer version of the system while another team is working on changes for the current one. In the early days of SCM, this was not possible and developers were given ‘turns’ for making changes on a system. However, nowadays, SCM allow changes to be made at the same time as it integrates these changes once they are all completed.

Integrate early and often: The involvement of end-users is essential in the development life cycle, and it is best to involve them as early and as often as possible and during the development stage as this will strengthen the relationship between them and the developers, allowing them to understand what the end-users need and what their requirements are.

Ensure reproducibility of software builds: It is advised that the building process of any system/software package is well documented in order for a straightforward reproduction and maintenance of it in the future. This is done through recording who/what team was responsible for building the system, what ‘libraries’ were used, and what operating system was in place.

Summary

In this lecture, the objectives and benefits of software configuration management (SCM) are identified. Also, the various tasks of SCM are explored, such as configuration identification, change control, and version control. Finally, the best practices of SCM are presented.

Exercises