Topic: Software Configuration Management

Message

Software Configuration Management

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. 
4.Versioning

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. 
5.Product Model

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.
6.Composition

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.

9.Workspace Support

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.
11.Process Support

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.

Author	Message
tanushree Senior Member Joined: 04Apr2007 Online Status: Offline Posts: 2160	Topic: Software Configuration Management Posted: 27Oct2007 at 5:39am
	Software Configuration Management 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. 4.Versioning 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. 5.Product Model 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. 6.Composition 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. 9.Workspace Support 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. 11.Process Support 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. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Testing Tools @ OneStopTesting : QuickTest Pro @ OneStopTesting