The Past,Present,and Future of Configuration Management(Susan A.Dart)(1992)

1.Introduction

The standard definition for  CM taken from IEEE standard 729-1983[scm] includes:

• Identification: indentifying the structure of the product,its componets and their type,and making them unique and accessible in some form.For exmaple,theis addresses the quesion,"What version of the file is this?"
• Control: controlling the release of a product and changes to it throughout the life cycle by having controls in palce that ensure consistent software via the creation of a baseling product.For example,this addresses the question,"What changes went into the latest version of this product?"
• Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product. For example, this addresses the question,"How many files were affected by fixing this one bug?"
• Audit and review: validating the completeness of product and maintainning consistency among the components by ensuring that the product is a well-defined collection of components. For example, this addresses the quesion,
  "Are all the correct versions of files used in this current release?"

When examining current technology that automates CM functions, it becomes clear that definition of CM as given by the IEEE standard needs to be broadened to encompass the extra functionality found in CM systems. This concerns:

• Manufacturing: managing the construction and building of the product in an optimal manner.For example, this addresses the question,"What vertions of files and tools were used to generate this latest relaese?"
• Process management: ensuring the correct execution of the organization's
  procedure, policies, and life-cycle model. For example, this addresses the question,"Were all the files tested and checked for quality before being
  released to the customer?"
• Team work:controlling the work and interactions between multiple developers on a product. For example, this addresses the question,"Were all the locally made changes of the programmers merged into the last release of the product?"

The CM solution is pervasive--it affects the software development
environment, the software process model, the users of the CM sytem, the quality of the software product, and the user's organization.

This article discusses the past and present situation concerning CM systems in order to focus on the furure CM challenges. The past is characterized as in-house CM solutions whereas the present is characterized by many third-part CM solutions. The future involves technological, process-oriented, political standardization and managerial challenges. One way of addressing these challenges is through the definition of  a CM services model, which is briefly dicussed. This article concludes by raising some questions about the nature of CM in relation to software engineering problems in general.

2.The Past

In the past CM was a private, organizational problem. A few organizations fell into a CM solution because they realized that managing changes to their software was very complex and they needed assistance. Other organizations dis not use CM because the problems were not clearly evident nor were there any third-party tools available to assist them, and the cost of  in-house development was viewed as too expensive. CM solutions generally entailed version control facilities that came with the operating system (such as SCCS with Unix) and some kind of build facility (such as job control scripts or Make). Organizations were thus dependent upon the operating system vendor for any CM capabilities or had to develop them in-house. Usually change control facilities(such as change request solution involved manual procedures and policies; people would keep any CM information in their head of filling cabinet; or a librarian would be assigned to carry out the CM functionsl and in large companies, lengthy procedures and policies were documented in large company manuals.

3. The Present

1. Repository: captures CM information and stores versions of files as immutable objects, as in RCS.
2. Distributed component: allows distributed users to have access to a repository workstations, as in Sherpa DMS.
3. Context management: captures in a domain-specific manner the working context for the user, thereby eliminating the need for users to remember how they got to a particular working status and what all the data items, their relationships, and tools are  in that context, as in Powerframe.
4. Contract: represents a formal plan for, and a record of, a unit of work on a configuration item, as in ISTAR.
5. Change request: assists in driving the process of change to configurations and keeping an audit trail of the changes, as in LIFESPAIN.
6. Life-cycle model: represent the process of developing and maintainning configurations through various phases, as in CCC.
7. Change set: represents a logicl change to a product and a means of creating any version of configuration that is not necessarily dependent on the latest version of that configuration, as in ADC.
8. System modeling : abstracts the notion of a configuration from an instance of it and by fully describing the configuration , assists tools in maintaing the configuration's integrity, as in Jasmine.
9. Subbsystem: provide a means to limit the effect of changes and recomplilation, and for the environment to check the validity of configurations, as in Rational.
10. Object pool: optimizes the need for regenerating objects and maximizes the amount of sharing of derived objects, as in DSEE.
11. Attribution: permits the description of a system at a higher level of abstraction via its characteristics, as in Adele, rather than in terms of a composition of files from a lengthy file list.
12. Consistency maintenance: enables the environment to identify any inconsistencies and to preserve consistencies in creating and reusing configurations, as in CMA.
13. Workspace: provides isolation of work between programmers and distinguishes between a global, long-term repository for immutable objects and a orivate, shorter term repository for mutable objects , as in shape.
14. Transparent view: gives a viewing mechanism for a configuration from the main repository into a workspace with protection agains unacuthorized access as in SMS.
15. Transaction: synchronizes and coordinates teams of engineers changing the same of different configuration, as in NSE.

These concepts provide a vocabulary that enables people to discuss automated CM suport. No single CM system provides all these concepts. It is also possible to categorize some CM tools suited to developers based on the sets of concepts they provide. The four categorites are:

1. The Check Out/Check In paradigm is based on the repository concept. An example system is RCS.
2. The Composition paradigm is based on the repository and system modeling concepts. An example system is DSEE.
3. The Change set paradigm is based upon the repository and change set concepts. An example system is ADC.     
4. The Transaction paradigm is based upon the repository, workspace, and transcation concepts. An example system is NSE.

CM technology of the past and present attempts to address corrective and adaptive maintenance through notions such as change requests, change control boards, and life-cycle state transitions.

4. The Future

The future is characterized by five main issues: technology, process orientation, management, politics, and standardization.