Department of Computer Science Department of Computer ScienceNo matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.
Change occurs throughout the development process. Of course, during development we expect changes to be needed to specification and design documentation, as well as code, as the work progresses. Post-release ÔmaintenanceÕ involves further changes to the product to accommodate new user requirements (plus bug fixes).
Need for change results from improved understanding as the development evolves, for example: of the problem, of possible solutions, of the usersÕ requirements, of resource implications, etc.
Working on a smallish programming problem individually, we can sometimes get away with a fairly undisciplined approach to recording and managing change; the requirements may be inside our head, along with most of the design documentation (!) and the latest version of the software may be the only important one. Even here, most programmers eventually learn the hard way that (say) before embarking on a speculative change to a piece of code, it is wise to keep a copy of the original (so that the change can be undone if it doesnÕt work).
When working on larger projects, in teams with different engineers developing different components in parallel, it is essential to have formal procedures for controlling change and tracking the different versions of a software configuration item. Without this, scenarios such as the following would rapidly lead to chaos:
Programmer A is implementing Unit 1.
Programmer B is implementing Unit 2.
Programmer C is implementing Unit 3. Units 2 and 3 both depend on Unit 1 (e.g. they are Eiffel client classes, or Delphi Units naming Unit 1 in a uses clause).
C asks A to modify the features exported from Unit 1 that she is using (e.g. she wants a function which takes an object reference as parameter modifies the object, and returns a result calculated from it, changed to a procedure which modifies the object and a function to return the results). So A modifies Unit 1, producing a new version.
Unless B is told of these changes, she will continue working with the old version of Unit 1, and Unit 2 will fail to compile when integrated with the other modules.
A change in syntax is easily spotted (by the compiler, if all else fails); much more dangerous are changes to behaviour or functionality (which of course (!) should be reflected back in the specifications), which could cause bugs if not properly dealt with by everyone involved.
So everyone needs access to current versions of specifications and developed code - and needs to be sure that these are the current ones.
If completed code is changed, all client programmers need to be informed so they know what else has to be changed, and what has to be retested.
Even worse consequences may result if more than one programmer is allowed to make changes to a code item at the same time. This is a version of the 'simultaneous update' problem: if both programmers make a copy of the item from some shared area into their own workspace, change it and then copy the modified version back, there is a danger that the second copy back will overwrite the first one, thereby losing the first programmer's changes.
A fundamental requirement is the ability to uniquely identify each version of each item of specification, code or other documentation. It is also necessary to know which versions of software components fit together to make a working system for release. This is further complicated if different releases are sold to different customers, and we have to provide maintenance.
Versions arise for two reasons: a revision of an SCI replaces the original, e.g: if fixing an error, or changing it to meet a modified requirement. We might still want to keep the original as well, however. Versions, therefore, are in a chronological sequence, and are identified by version numbers.
A variant of an SCI is a version of it for use in a different environment; e.g. with a different operating system; on different hardware; with a different database, or communications system, or model of printer. Variants, therefore, exist in parallel.
At its simplest, identification is usually based on a numerical scheme: a new release usually involves significant change in functionality - e.g. numbered 1.0, 2.0, 3.0, etc. Similarly for variants.
A new version usually results from changes fixing bugs within a release - e.g. numbered 2.1, 2.2, 2.3, etc.
Keeping track of all of this, and controlling changes in such a complex environment, is usually called Configuration Management, and is supported by specialised tools based on database technology.
Configuration of a product: the components which make it up, and the versions of these.
Configuration management: coordinating software development and controlling the change and evolution of software products.
Versions: Revisions and Variants
Configuration Management addresses the problems associated with:
simultaneous access to a common repository of components - e.g. managing changes to a module which is being used in a number of different places, and the simultaneous update problem
handling product families - e.g. different versions/variants of components used in different releases.
Most approaches to these problems are based on the notion of a ÔbaselineÕ - a collection of software configuration items which have been subjected to some formal approval process, and which cannot be further changed without applying procedures which are part of the organisationÕs quality system.
Prior to being baselined, an item can be modified quickly and easily, with a minimum of red tape. Eventually it will be validated by some combination of testing, inspection and review, and brought into the baseline. It is now under the control of the organisationÕs change control system. Any further changes involve raising a formal request, getting it approved (or turned down) by a Change Control Authority, etc. See any standard software engineering text for details (e.g. Sommerville, ch33)
We can get a good idea of the requirements for version control in realistic development environments by looking at the facilities offered by a fairly simple Unix tool. RCS maintains a typical database-type locking mechanism to prevent multiple updates.
"The Revision Control System (RCS) manages multiple revision of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, graphics, papers, and form letters.Ó. Functions of RCS include:-
• Store and retrieve multiple revisions of text....previous revisions remain accessible.
• Maintain a complete history of changes. Logs all changes automatically. Besides the text of each revision, RCS stores the author, the date and time of check-in, and a log message summarising the change.
• Resolve access conflicts. When two or more programmers wish to modify the same revision, RCS alerts the programmers and prevents one modification from corrupting the other.
• Maintain a tree of revisions representing ancestral relationships among revisions.
• Merge revisions and resolve conflicts.
• Control releases and configurations. Revisions can be assigned symbolic names and marked as released, stable, experimental, etc.
• Automatically identify each revision with name, revision number, creation time, author, etc.
• Minimise secondary storage. RCS needs little extra space for the revisions (only deltas).
•
Establish a project database for specifications and code - on paper, or (preferably) on a machine.•
Establish a mechanism for bringing items into the database - ÔbaseliningÕ them so that they are under your change control system.•
Establish a mechanism to ensure that only the author of a specification or piece of code is allowed to change it.•
Establish a mechanism for notifying people about changes.•
Number versions and maintain a change log (in spec/code comments, or separately), format like:-Class PACK
Version Date Change and Reason Components affected
1.0 15/2/95 Initial version
1.1 20/2/95 Added PACK.print routine to help testing. TESTCARD.main,
1.2 23/2/95 Fixed bug in PACK.shuffle TESTCARD.main, DEAL.bridge
Note that developing using an environment like Delphi is further complicated by the existence of form files, resource files, option files, etc. plus the multiple files involved to store database tables.
6.1.1 General
CM provides a mechanism for identifying, controlling and tracking the versions of each software item. In many cases earlier versions still in use must also be maintained and controlled.
The CM system should:
identify uniquely the versions of each software item;
identify the versions of each software item which together constitute a specific version of a complete product;
identify the build status of software products in development or delivered and installed;
control simultaneous updating of a given software item by more than one person;
provide coordination for the updating of multiple products in one or more locations as required
identify and track all actions and changes resulting from a change request from initiation through to release."
From ISO 9000-3 Guidelines for the application of ISO 9001 to the development, supply and maintenance of software.
Last Updated: 07/12/98 by M.Wood@herts.ac.uk
© University of Hertfordshire Higher Education Corporation (1998)