The procedure for managing the test object and related testware should be described.
The version Management of the testware is ultimately the test team responsibility.
One of the issues that must be addressed in Configuration is that modified objects may only be installed in the test environment with the test team permission, after action has been taken on the basis of the errors. This is to prevent a test from failing when a different version of the object under test is unexpectedly being used. The Change Management documentation also has to be updated since the documentation is intimately connected to the testware.
In addition, the way in which change requests are dealt with must be indicated. If this results in extra tests being required, a bottleneck could be created in the project. Therefore, the test team must be informed so that any new tests can be included in the test plan.
1. What is Software Configuration Management?
Current definition would say that SCM is the control of the evolution of complex systems. More pragmatically, it is the discipline that enable us to keep evolving software products under control, and thus contributes to satisfying quality and delay constraints.
SCM emerged as a discipline soon after the so called "software crisis" was identified, i.e. when it was understood that programming does not cover everything in Software Engineering (SE), and that other issues were hampering SE development, like architecture, building, evolution and so on.
SCM emerged, during the late 70s and early 80s, as an attempt to address some of these issues; this is why there is no clear boundary to SCM topic coverage. In the early 80s SCM focussed in programming in the large (versioning, rebuilding, composition), in the 90s in programming in the many (process support, concurrent engineering), late 90s in programming in the wide (web remote engineering). Currently, a typical SCM system tries to provide services in the following areas:
a. Managing a repository of components. There is a need for storing the different components of a software product and all their versions safely. This topic includes version management, product modeling and complex object management.
b. Help engineers in their usual activities. SE involves applying tools to objects (files). SCM products try to provide engineers with the right objects, in the right location. This is often referred as workspace control.
c. Compilation and derived object control is a major issue. Process control and support. Later (end 80s), it became clear that, if not the, major issue is related to people. Traditionally, change control is an integral part of an SCM product; currently the tendency is to extend process support capability beyond these aspects.
2. Short History
In the 80s, the first systems were built in house and focussed closely on file control. Most of them were built as a set of Unix scripts over RCS (a simple version control tool) and Make (for derived object control).
From this period we can mention DSEE, the only serious commercial product, which introduced the system model concept which was an Architecture Description Language ancestor; NSE which introduced workspace and cooperative work control; Adele which introduced a specialized product model with automatic configuration building, and Aides de Camp (now TRUE software) which introduced the change set. The first real SCM products appeared in the early 90s.
These systems are much better. They often use a relational database but still rely on file control, they provide workspace support, but no or built-in process support. This generation included Clear Case (DSEE successor) which introduced the virtual file system and Continuus which introduced, with Adele, explicit process support. Continuus and Clear Case are currently the market leaders.
In the second half of the 90s, process support was added and most products matured. This period saw the consecration of SCM, as a mature, reliable and essential technology for successful software development; the SCM market was over $1 billion sales in 1998.
Many observers consider SCM as one of the very few Software Engineering successes.
3. Summary of Concepts:
Most SCM products are based on a tiny core of concepts and mechanisms. Here is a summary of these concepts.
In the early 70s, the first version control system appeared. The idea is simple: each time a file is changed a revision is created. A file thus evolves as a succession of revisions, usually referred to by successive numbers (foo.1, foo.2 .). Then from any revision, a new line of change can be created, leading to a revision tree. Each line is called a branch (the branch issued from foo.2 is called foo.2.1, foo.2.2). At the same time, 3 services were provided: History, delta, multi user management and a bit later, merging facilities.
History simply records when and who created a revision along with a comment. Deltas were provided because two successive revisions are often very similar (98% similar in average). The idea is to store only differences (the 2% that are different). Of course, it vastly reduces the amount of required memory.
Multi-user management consists in preventing concurrent changes from overlapping each other. A user who wants to change a file creates a copy and sets a lock on that file (check-out); only that user can create a new revision for that file (check-in).
Despite the fact that all this is 25 years old, it is still the base of the vast majority of today SCM systems.
From the beginning, the focus was on file control. It is no surprise to see that, even today, the data model proposed by most vendors resemble a file system, plus a few attributes, often predefined. This is archaic and contrasts with today's data modeling.
A configuration is often defined as a set of files, which together constitute a valid software product. The question is twofold: (1) what is the real nature of a configuration, and (2) how to build it, prove its properties and so on.
Surprisingly, in most systems, a configuration is not an object, but "something" special. It is a consequence of a weak data model in which complex objects and explicit relationships are not available.
The traditional way to build a configuration is by changing an existing one. No correctness criteria are available.
In the change-set approach, a change, even it involves many files, receives a logical name (like "FixBug243"). Later on, a configuration can be produced as a set of change-sets to add or remove from a base configuration (like "C2 = C1 + FixBug243 - Extention2"), C1 being the base configuration and C2 the new one. In the Adele system, a configuration is built interpreting a semantic description which looks like a query: the system is in charge of finding the needed components based on their attributes and their dependencies. None of these approaches is available in the vast majority of today's systems.
7.Engineers Support Practitioners rejected the early systems because they were helping the configuration manager, and bothering everybody else. A major move toward acceptance was to consider the software programmer as a major target customer: helping him/her in the usual SE activity became a basic service.
8.Building and Rebuilding
The aim of rebuilding is to reduce compilation time after a change, i.e. to recompile, automatically, only what is needed. Make is the ancestor of a large family of systems based on the knowledge of "dependencies" between files, and their last modification date. Make proved to be extremely successful and versatile, but difficult to use and inadequate in many respects. All attempts to do substantially better have so far failed. Most systems "only" generate the make files.
A workspace is simply a part of a file system where the files of interest (w.r.t. a given task like debug, develop etc) are located. The workspace acts as a sphere where the programmer can work, isolated from the outside world, for the task duration. The SCM system is responsible for providing the right files (often a configuration), in the right file system, to let users work (almost) independently, and to save the changes automatically when the job is done. It is this service that really convinced practitioners that SCM was there to help them.
10.Cooperative Work Support
A workspace is a support for concurrent engineering, since many concurrent workspaces may contain and change the same objects (files). Thus there is a need for (1) resynchronizing objects and (2) controlling concurrent work.
Resynchronizing, so far, means merging source files. Mergers found in today tools simply compare (on a line by line basis) the two files to merge, and a file that is historically common to both (the common ancestor). If a line is present in a file but not in the common ancestor, it was added, and must be kept; if a line is present in the ancestor and not in the file, it was removed and must be removed. If changes occurred at different places, the merger is able to decide automatically what should be the merged file. This algorithm is simply a heuristic that provides in output a set of lines with absolutely no guaranties about correctness. Nevertheless mergers proved to work fine, to be very useful and became almost unavoidable.
Controlling concurrent work means defining who can perform a change, when, on which attribute of which object. It is one of the topics of process support that, currently, no tool really provides.
Process support means (1) the "formal" definition of what is to be performed on what (a process model), and (2) the mechanisms to help/force reality to conform to this model.
A State Transition Diagram (STD) describes, for a product type, the legal succession of states (and optionally which actions produce the transition), and thus describes the legal way to evolve for entities of that type. Since SCM aims to control software product evolution, it is no surprise many process models are based on STDs. It is a product-centered modeling. Indeed, experience shows that complex and finegrained process models can be define that way.
Unfortunately, experience also shows that STDs do not provide a global view of a process, and that large processes are difficult to define using (only) STDs.
The alternative way to model processes is the so-called activity centered modeling, in which the activity plays the central role, and models express the data and control flow between activities. This kind of modeling is preferred if a global view is required, if a large process is to be structured, or if products are not the main concern. But this approach lacks precision for product control. Experience has demonstrated that both are needed, but integration is not easy and the few tools that intended to do so only propose two independent modeling. High-level process models mixing both are not currently available in commercial products, but have been experimented.
12.Most useful / appreciated features
Clearly the number one was change control, activity control, and workspace support. Then comes, in differing order: Global view, traceability etc. Worse aspect, most missing feature
Clearly the number one was: Better and more flexible process support, concurrent and distributed engineering support. Then comes: scalability, efficiency, incrementality, cross platform capability, PDM compatibility, interoperability etc. It is interesting to see that both the most appreciated and the most criticized feature concern process support. Almost no comments concerned the basic aspects of SCM, like versioning and merging. Practitioners think tools are good and stable enough but still lack efficiency, scalability and interoperability with the other SE tools. It is likely that, in the near future, the distinctive features between tools will be, functionally, their strength in process support, technically, their capability to grow with the company needs to inter-operate with other company tools and to support concurrent, distributed and remote engineering.