SE 2020 - Vasile Stoicu-Tivadar 1 / 63

Objectives
for the 6th Chapter
Software Configuration
Management

•Program families
•Derivations
•Interfaces
•Baselines and private workspaces
•Procedures
•Applying the principles

SE 2020 - Vasile Stoicu-Tivadar 2 / 63

Configuration Management - the
problem
It is frustrating to work as a member of a large
software development team, you can spend more
time co-ordinating with the other team members
than you do programming.
The increasing of the team size does not increase as
much the productivity as the team increasing (see
process models). Number of communication channels
2
C n =n*(n-1)/2 (combination of n things 2 at a time)

Person 2 Person1 Person2

Person 1
Communication
channels

Person 3 Person 3 Person 4

3 person team 4 person team

SE 2020 - Vasile Stoicu-Tivadar 3 / 63
Configuration Management - the
problem - continued 1
It is possible to identify a common theme among the co-ordination
problems faced by a software team: programmers spend too much
time trying to answer one question:
What program is this ?
See manifestations as :
“This worked yesterday. What happened ?”
“I can’t recreate the bug in this copy.”
“What happened to the fix I put in last week ?” a.s.o.
In all of these cases, the programmer is struggling to understand exactly
which particular program is in hand.
The essence of all these problems is co-ordination failure - people are
tripping over each other, forgetting to do something they meant to do,
making changes that interfere with progress.
Example: somebody installed a ‘fixed” copy of a subroutine, erroneously resetting a data
item that was supposed to be left around for a later phase.

On any team project, a certain degree of confusion is inevitable. The goal is to minimise the
confusion so that more work can get done.
The co-ordination of the software development to minimise this particular type of confusion is
called configuration managementSE 2020 -. Vasile Stoicu-Tivadar 4 / 63
Configuration Management - the
problem - continued 2
Configuration management can be applied to project materials other than software:
documentation, test reports, schedules, specifications, plans etc.

Examples: maintainers might find that test cases change mysteriously, or that bug reports
remain open long after the bug is fixed. Managers might find that milestones are accomplished
on schedule, but nobody can agree exactly which schedule was met.

Every software project should have someone assigned to be the configuration manager.
On a project too small for the services of a full-time configuration manager, the job can be
combined with other responsibilities.

Typical problems that argue the need for configuration management:

 the double maintenance problem
 the shared data problem
 the simultaneous update problem

SE 2020 - Vasile Stoicu-Tivadar 5 / 63

Configuration Management - the
problem - continued 3
The double maintenance problem - results from keeping multiple identical copies of
software:
 when there are two copies of the same software, then both copies need to be maintained;
when a bug is found, someone needs to remember to fix it in both copies (failing that, the bug
must be diagnosed and repaired twice).
 When a bug is fixed, must be fixed identically in both copies
The first principle of configuration management: to avoid
multiple copies of the same information.
In the real word, no amount of effort can ensure that two copies will
be identical forever - multiple copies inevitably diverge.

The shared data problem - arises when many people are simultaneously accessing and
modifying the same data (eventually program code):
 when programmers are modifying a single copy of a program, then changes made by one
programmer can interfere with the progress of others
 the most obvious case of interference is when the modification is wrong (a bad fix)
 even when a modification is valid, it might change the behaviour of the program in ways that
the entire programming team needs to understand (example: a subroutine is passed arguments
whose meanings are now slightly different)
 there are always going to the problems when programmers work together on one piece of
source-code; regardless of how well programmers communicate with each other, there will be
SE 2020 - Vasile Stoicu-Tivadar
times when changes introduced by one programmer are an unpleasant surprise to the others.
6 / 63
Configuration Management - the
problem - continued 4
The simultaneous update problem - because of the shared data problem:
 a programmer who wants to modify a module makes a copy of it and changes the copy
 the programmer then tests the change to make sure it is valid before making the change in the
shared copy
 the likelihood of team progress being spoiled by a defective fix is thereby minimised
 when two people are simultaneously updating the same software, is possible to overwrite one
person’s updates
 an even worse case can arise when a programmer makes a change that spans multiple
modules (and the update refers only to one of them)

We have a dilemma:
 if we keep multiple copies we have the double maintenance problem
 if we keep one shared copy of the whole project, the shared data problem is our penalty
 if we try to get around the shared data problem by allowing people to make temporary copies
of modules so that they may test without affecting others, then we will losing time because of
the simultaneous update problem

Solving problems like these is the concern of the configuration manager.

SE 2020 - Vasile Stoicu-Tivadar 7 / 63
Program Families

The purpose of a professional software

development project is to build a
family of computer programs.
Every product exists in alternative
forms, successive releases,
custom-tailored applications, the
aggregate of which we call a
program family.

The configuration management

strategy must successfully control
all the members of a program family
so that maintenance effort is
minimised and unnecessary
duplication of work is eliminated.

SE 2020 - Vasile Stoicu-Tivadar 8 / 63

Program Families - continued 1

The most common approach is to keep for

each version the source code (or other
related codes) on distinct physical media.
but
the double maintenance problem appears

solution

store in one place all the different

modules used throughout the family
and keep a list of all the different
modules of which any particular
member is composed
general pool of modules -> library;
for each member of the family, a list shows which
modules are to be included in that version;
the list is called the configuration;
each module is present in only one place (no double
maintenance problem)
SE 2020 - Vasile Stoicu-Tivadar 9 / 63
Program Families - continued 2

When it comes time to configure a new version the programmer picks from the
library the relevant ones to link together (but chooses the correct version of
each module).

The library must be properly organised to make it easy to create new

configurations: must reflect the relationships among the modules.

If a module is to be presented in many versions, then we must intelligently

represent the versions. We need to understand the ways in which the versions
differ.

We must distinguish between two fundamentally different kinds of versions:

 revisions
 variations

SE 2020 - Vasile Stoicu-Tivadar 10 / 63

 Revisions
A revision is a new version intended to supersede the old
commonly reflect progress in debugging the module or they
can also reflect added functionality or performance
improvement
Each revision introduced into the library should have fewer bugs
or in some other way be better then the earlier; the intention of
the designer is that the newest revision will make the older
ones obsolete.
Revisions come in a linear order, related to the time sequence in
which they are created; commonly they are numbered (with 1
being the first revision).
The library is organised to show that the multiple versions of each
module are a set of revisions

The revisions are illustrated as a stack of cards, with the oldest at the back.
But why are the older versions kept in the library ? (the newest version is intended to supersede the
older ones):
•one reason is that despite the intentions of the programmer, revision N+1 might not be
better than revision N ( perhaps revision N+1 has more bugs than revision N; even if
N+1 has fewer bugs, its bugs may not be a subset of the bugs in revision N - example: 3
bugs fixed, 1 new created)
•they may be needed to reproduce bugs that are present in older software (especially
for the maintenance - reported form the field)
SE 2020 - Vasile Stoicu-Tivadar 11 / 63
Variations
Module variations fulfil the same function for slightly
different situations The variations are illustrated as
coequal alternatives
Are therefore intended to be alternative, implementing a variation set.
interchangeable parts
The hexagon is not itself a
A configuration includes only one variation of any module but a is a notational
given module. mechanism for showing the
The new variations do not supersede old, multiple organisation of the variation
variations coexist as equal alternatives set.
Variations are named, not numbered (because is no
meaningful linear order among them); the name
reflects the purpose it serves.
Reasons why a library might include multiple
variations of a module:
1. alternative variations might support different
types of hardware
2. multiple variations that fulfil alternative
functionalities (example: in a payroll system, multiple The naming convention is an
variations of the state-tax withholding module might exist to important tool for describing the
reflect the differences in the tax lows of each state; or in a relationship among the variations
building security system, variations might describe
SE 2020 theStoicu-Tivadar
- Vasile different
12 / 63
floorplans)
Variations - continued 1

Sometimes a library contains module variations that exist only for purposes of
testing and debugging (might include traces, assertions and data dumps
designed to aid debugging).
Another variation used only during program development: stub
A stub of a module is a variation that does nothing but without crashing
(gracefully). Programmers might build a configuration that references stubs of
those modules they do not want to test, without the risk of being blocked by
bugs other than the ones they are seeking.

Typically, there are both variations and revisions of a single module.

SE 2020 - Vasile Stoicu-Tivadar 13 / 63

Storing versions of modules

Every module is present in the library as a set of

versions. They are stored as:
1. Separate files - naming conventions are used
to record the fact that different files represent
different versions of the same module
the double maintenance problem
appears
Keeping both versions up-to-date can be but
complicated; since the variations are
different, how do we know that a bug
discovered in one of the versions exists in
another ? The bug may be in a portion of the
code that is intended to be different. And
even if the bug does exist in both variations,
what lead us to believe that is possible to
apply the identical fix ?

2. Deltas - store a single full version and

represent the other versions by their differences
(called deltas) from the one.
SE 2020 - Vasile Stoicu-Tivadar 14 / 63
 Storing versions of modules - continued 1
The delta file contains a complete description of the difference between the
two variations; typically it contains editing commands that describe exactly what
statements to add at exactly what place to transform one variation to another.
If we want to read the transformed variation we retrieve the original variation and apply the
delta.
The advantages of the delta approach:
 when a bug is fixed in the original variation it is not necessary to fix the bug again
in the other variation
 economical in the use of storage space

The disadvantages:
 if the original file should be lost or corrupted, then the entire set of versions is lost
(but regular backup procedure minimises the risk)
 the complication involved in representing transformations

Example: if we use the reference to line numbers, if the original file is modified,
such a scheme fails - more sophisticated algorithms are necessary.
Deltas are a good method for representing revisions of modules. It is possible to
use either forward or reverse deltas (forward deltas start with the oldest revision - N-
>N+1 and reverse deltas start with the most recent revision - N-> N-1). Advantage for
the reverse delta - the most recent revision is immediately available. Since the recent
revisions are accessed more often than the older ones, reverse deltas are an
optimisation of retrieval effort, but the drawback is that the most recent revisions might
be subject to change, which would
SE 2020require
- Vasilerecreation of the deltas.
Stoicu-Tivadar 15 / 63
 Storing versions of modules - continued 2
3. Conditional compilation - to represent all the versions using one copy of source
code and to include the differences by conditional compilation: source code that is
relevant to only some versions is bracketed by macro commands so that the compiler
can recognise which statements are relevant for which versions. When the compiler is
invoked, it is told which version is to be produced (and it automatically ignores source
statements that are not part of the proper version).
The advantages:
 shared code is represented only once, so fixes to the code are effective for all
versions (no double maintenance problem)
 avoids the combinatorial explosion that can result if the module is varied for multiple
reasons
Example: if a particular module must support 3 types of input devices and 4 types of output devices,
we will have 12 variations and 12 files. But if conditional compilation is used, the source code will probably
contain 3 conditionally bracketed sections for input and 4 sections of code for output, with no multiplicative
effect.
Disadvantage: vulnerable to loss of all versions if the one file is lost (like the delta
approach)

Conditional compilation can be an effective scheme until the differences between versions become so
complex that the source code is impossible to read (for this reason is used primarily to store
variations, not versions - differences among variations are typically localised and stable, as
contrasted with the random nature of bug fixes).
If we want to use conditional compilation
SE 2020for revisions,
- Vasile the complexity of the source code would
Stoicu-Tivadar 16 / 63
become unmanageable.
 Derivations
Many times the fastest approach to find a bug is analysis
of the history of the program - how it was created.
The history of the program is called its derivation.
A programmer can compare the derivations of the last program builds and of the actual
program build and see what modules might introduce errors (modules with higher-
numbered revision). Also, he can compare the differences between the revisions and
identify the possible cause. Thus, the programmer can locate the bug without not one line
of code has been examined.
A precise derivation of a program or module requires:
1. An identification of the tool that created it (example: integrated development
environment used for)
2. An identification of the data that was input to the tools
3. An identification of the options and arguments given to the tool (example: compiler
options)
4. The reason why that particular data, arguments and options were given to the tool
5. The person who was responsible for creating the data
6. The date and time
A derivation should be kept for every file used by the software team (source code,
object code, executables, documentation, schedules, budgets etc.). We can locate
bugs only if we examine a chain of derivations. Each file has attached to it a
derivation; each derivation references other files, and thereby other derivations,
producing a genealogy that SE can be traced until the error is found.
2020 - Vasile Stoicu-Tivadar 17 / 63
 Derivations - continued 1
A precise derivation depends on strict control of file names.
Example: is not sufficient to identify all the different stages
simple as module A, the different stages could be named A(1),
A(2)a.s.o. or they could be named A from Sept., 20, 2001, A from
Oct., 10, 2001 a.s.o. (they must be distinguish).
An essential principle of configuration management is that file
names must never be reused. If a file is modified, then a
new version has been created and must receive a new
name.
The derivation of a readable file (source-code, documentation)
includes an explanation of the reason the file was created and
an emphasis on the differences between this file and other
versions. When programmers create a new version of source
code, they record in the derivation the version and the motivation
and details of the changes they made.

A common convention - > to create a change log at the top of

each source-code.
Every time programmers make a change they add a new
paragraph to the top of the change log (because of the
presumption that the most recent changes are of greatest
interest). SE 2020 - Vasile Stoicu-Tivadar 18 / 63
 Derivations - continued 2
Example: change log

A common mechanism for emphasising

changes between revisions are change bars -
vertical lines that appears in the left or right
margin to designate a line that is different or
new in this revision and distinguishes it from
the previous revision (but do not show that
lines have been omitted nor do they describe
the nature of the change) - only if the compiler
can ignore them -> normally used in
documentation SE 2020 - Vasile Stoicu-Tivadar 19 / 63
 Reproducibility
If the software product exists in only a few releases, you can keep a copy of each (when a
bug is reported, you can go to the tape library and retrieve the release against which the bug was
reported).
This approach doesn’t work when the program exists in a large variety of configurations.
(example: when we have a lot of customers, with different configurations and monthly update).
• The only reasonable approach is to create the proper program as needed, using the customer’s
report starting which release was used and which patches have been installed.
• The customer’s report might be a derivation of the software.
• The customer’s program is recreated in-house using the derivation supplied by the customer.
• The derivation shows the tool, the inputs, the options etc. in order to reproduce the software.
To recreate a configuration is useful:
• when each copy of a program is custom configured (for maintenance purposes)
• during initial program integration, when the program may often change
To use derivations to recreate software, anything that appears in a derivation
must be frozen (deletion and modification forbidden for certain files).
Freezing includes immutability and protection against deletion.
Protection against deletion :
• implies use of a large amount of storage space (if you want to be able to reproduce any
software that ever existed, you have to save every piece of source code that ever existed).
• Or, if isn’t necessary to recreate every transient piece of software that ever existed, so not
everything needs to be saved
• or, many files can migrate to an offline archive, carefully organised for case of retrieval.
SE 2020 - Vasile Stoicu-Tivadar 20 / 63
 Interfaces
The hiding principle of the software engineering (Parnas, 1971) states that software
development proceeds more rapidly when the programmers understand as little as possible
of what each other is doing.
This principle can also been applied to the problem of software configuration management.
Example of such a problem: one programmer is involved in database inquiry functions for an
inventory management system, another, for a particular part (calls the functions developed
from the first one, but decides to direct access the needed fields in the database, because the
too slow routines from the other). Every time when a change in database structure is needed
and the responsible might not announce the other programmer because he didn’t thing he was
using directly database structures.

classic double maintenance problem

Applying the principles of information hiding:
•divide the software into pieces (modules) so that each programmer can work on one piece without
understanding anything about how other programmers are building their pieces
•since all the pieces need to work together in the end, such a strategy requires careful planning -
called design
•each module must be related to the others in a precisely defined way
•the purpose of each module as is related to all the other modules -> interface

•the way that the module accomplishes its purpose -> its implementation
•the logical separation between interface
SE 2020 -and implementation
Vasile Stoicu-Tivadar is essential 21 / 63
 Interfaces - continued 1
The author of any given module need
understand only the interfaces between the
module and the others, and need not
understand the implementation of any other
module.
A well-defined interface is useful :
•for debugging - when an author is fixing a bug, as long
as conformity with the interface is maintained,
The interface is like the top of
modifications will not affect the operations of any other
the iceberg, it’s a small part,
module
the only part that anyone sees
•for version development - all of the revisions and
variations are interchangeable
But the real-word solution is not as simple as all those above (bugs, staff turnover, tight
deadlines):
• The author of a module must sometimes help other programmers to find bugs in their
code. Having only one person who understands a critical portion of code creates
unnecessary management exposure.
• Programmers maybe want to improve their professional skills and accordingly to this, to
study other software than the own developed solutions.

Interfaces and implementation must be properly for the software development but not
SE 2020 - Vasile Stoicu-Tivadar
necessarily for people involved. 22 / 63
 The Hierarchy of Interfaces

Part of the job of the design phase is to define interfaces that will allow
interchangeability of versions and thereby facilitate configuration management.
Interfaces themselves are objects to be controlled by the configuration manager. Just
like source code, each interface is likely to be revised and varied into multiple versions.
Interfaces are in fact the primary output and purpose of the design phase:
• design begins with the entire software product viewed as a single entity; its
interfaces with the outside world are called the functional requirements
• designers break down (decompose) the software product into a group of
modules and designate the interfaces among the modules
• the process continues recursively until the submodules are so small that their
implementation is obvious
• then the design is complete

At each iteration the designer specifies the component submodules (what they are,
purpose, interaction between submodules).

The design begins with a box that represents the module

The interfaces
the module must
meet
SE 2020 - Vasile Stoicu-Tivadar 23 / 63
The Hierarchy of Interfaces - continued 1
The design of the implementation is then expressed with smaller boxes that represent
submodules.

Interfaces among
submodules

As the design process recurses, the submodules are similarily designed, starting with their
interfaces and developing their implementation (what is implementation for the designer of the
module is interface to the designer of the submodule).
A large software development process must maintain a hierarchy of interfaces that reflects the
decomposition of the software:
• top level - functional requirements
• next levels - interfaces among the modules,
- interfaces among the submodules a.s.o.
The decomposition of the software into modules is frequently reflected in the organisation of the
project into teams and subteams -> the interfaces between modules become the interfaces
between teams.

Typically, the smallest submoduleSE

is a2020
subroutine (function, procedure).
- Vasile Stoicu-Tivadar 24 / 63
Precision of Interfaces
Real design is done by making tentative decisions and backing up to fix or refine them
when necessary.
The first time a module is decomposed, the designer will not be able do define precise
interfaces among the submodules.
Refinement of the interfaces will have to be a matter for negociation among the
subteam responsabile for the submodules.

For this reason, an interface is frequently specified in succesive degrees of

precision as reflected in succesive revisions of the interface.

Example: The designer of a product has specified that 2 of the submodules are called
Shelf-Space Allocation and Parts-Description Database. The system designer specifies
SE 2020 - Vasile Stoicu-Tivadar
an interface between the 2 modules called Shelf-Allocation Attributes Interface. 25 / 63
Precision of Interfaces - continued 1
The first revision is
specified by the product designer:

The second revision is more detailed than the

first because one of the designers has
developed a better understanding of exactly
what information the database must provide:

The succeeding revisions describe the exact format of the inquiry, the types and ranges of the data
passed in and out, the handling of errors and further details.
SE 2020 - Vasile Stoicu-Tivadar 26 / 63
Precision of Interfaces
- continued 2

In this example, the third revision of

the interface is sufficiently detailed
for implementation:

SE 2020 - Vasile Stoicu-Tivadar 27 / 63

Types of Interfaces
Interfaces :
1. call interfaces
- exists among the calee and caller
- the calle provides a service to the caller
- designates the entry points (names of the subroutines that are provided)
- describes (for each entry point):
the parameters
-how many, the order
-type and legal range
-meanings of special values and end conditions
-meaning and purpose of the parameter
-whether the parameter is input/output (only)
side-effects
-assumed values for global data
-modifications to global data
-circumstances under which the subroutine might not return normally
-the purpose of the subroutine - why it is called, what it does

The interface might define special data types (is the used language permits).
2. data interfaces
describe data that is accessed by more than one module (if only one module references data, then
the definition is part of the implementation)
describe shared data (global variables, data stuctures, disk files, external inputs and outputs)
include name, type, meaning, record structures field by field (typically using the precise syntax of the
used programming language),SE time and- circumstances
2020 under which the data is to be changed,
Vasile Stoicu-Tivadar 28 / 63
including the initialisation
Types of Interfaces - continued
Example for the Shelf-Allocation
Module presented above:

The distinction between data and call interfaces is frequently an artificial one. In modern
programming practice, most significant data structures are isolated within modules whose
purpose is to provide access to the data for the other modules.
Often, physical organisation of the databases is hidden as part of the implementation of the
module, and the interface is a call interface to a database manager rather than to a data
SE 2020 - Vasile Stoicu-Tivadar
structure. 29 / 63
Automatic enforcement

We would want to perform configuration management so that interfaces are automatically

enforced. A number of schemes partially accomplish this goal.
Example: a programmer which writes C code uses header files and include compile orders. The
logical effect is as if the definitions had been coded into the module, but the programmer does not
actually write the definitions of the data. Instead the definitions are included by reference to the
header. The header files are protected under control of the configuration manager. Any programmer
can include any interface but nobody can change one without going through a special procedure to
secure the approval of project management.

Certain aspects of the data interface are

automatically enforced but there is no
enforcement of which modules have
rights for accessing or modifying data
and is no enforcement of the meaning of
the data.

There are special text editors that allow free access to one part of the file (the
implementation) and prohibit access to other parts (the interface).
Also, compilers for modern programming languages are designed to help check
for particular kinds of nonconformance to interfaces. It is common to
automatically check subroutine calls to make sure that actual parameters match
the types shown in the subroutine definition.
SE 2020 - Vasile Stoicu-Tivadar 30 / 63
Automatic enforcement - continued

Example: the language ADA represents further advancement in the area of automatic interface
enforcement. The major element of program structure is the package, which is a module with a
precisely defined interface to the other modules of the program. A package’s interface is called its
specification and includes definitions of variables, data types and calling sequences for subroutines.
In the next example, a stack package specifications is shown (includes the definition of the type of
data to be stacked, a publicly accessible variable that holds the number of entries currently on the
stack and the definitions of two procedures – Push and Pop):
The compiler checks for conformance to the
interface even though the interface and the
module that references the interface are
presented in separate compiler invocations.

But no compiler can make sure

that a subroutine does the right
thing at the right time. To make
sure that an interface is correctly
implemented in its semantics as
We have also interfaces in JAVA. well as its syntax, testing is
We can also relate COM technology to this problem. necessary.

SE 2020 - Vasile Stoicu-Tivadar 31 / 63

The importance of Stability
It is not possible to overemphasize the importance of stability to successful software development. Nothing is
more frustrating to programmers than not being in control of changes affecting the program they are trying to get
working.
Example: Somebody has found a bug in the source-code, a corruption in static data area (s subscript
out of range, an invalid pointer or something similar). First, our programmer must make the bug
reproducible and he find a corruption of a specific field in a particular record in static storage. Then, he can
try why the problem happens. Suddenly, the bug is no longer repeatable, and that particular field is no longer
being corrupted. The system still crashes, but now the nature of the crash is random again. The bug has
moved. What happened ?
Someone else modified some other routine unrelated to the debugged module from our example and the
allocation of code and data has been moved to slightly different locations. Now there is something
completely different being corrupted, so that our programmer has to start over again from the beginning and
try once again to develop a mechanism for dependably producing the bug.

For our programmer the stability is the issue, not mistakes. He wants a shared database will be unchanged
for his tests. But all the other programmers also want full control, and their productivity depends on it. This need
can cause conflicts. This is the essence of the team coordination problem.

•A solution : In the early stages of the development process, programmers can use private copies of the
source code for individual use, under absolute control. The programmers can work in complete isolation. But they
work for a single product, so when the integration is needed, the isolation is unnaceptable.

•But if each programmer has a copy of the whole source code, we have a double maintenance situation. If a
programmer fix a bug, he must transmit the fix to the other programmers, who must make the change in
their private source code. The workload might be unnacceptable.
•We must devise a mechanism for granting programmers a measure of control over their own stability and
at the same time allow them to integrate their work with the other team members to produce a complete
SEenhanced
product (individual less productivity but 2020 - Vasile
teamStoicu-Tivadar
productivity). 32 / 63
Private Workspaces
One solution to the team coordination problem:
use of project baseline & individual workspaces.

Baseline - is the shared project database

(source code, object code, library of
modules, documentation etc.)
- the access is sharply restricted
- contains the definitive copy of each
module
Private Workspace - can contain information
copied form the baseline (for each
programmer)
- does not contain all of the project data
but only that its owner chooses
to include in
- place to try out new code

A programmer who needs to make changes to

any module does not change the baseline’s copy,
instead, makes a copy into the workspace then
freely change this. SE 2020 - Vasile Stoicu-Tivadar 33 / 63
Private Workspaces - continued
Bill tests module A in his own
workspace.

- he makes a copy of this module

- for tests he needs other
modules so that he makes
copies for linking with other
modules (without modifying
them)
- after the tests succeed, he
places back the revised copy of
the tested module
The odds are diminished that a
defective fix will interfere with the progress of other team members.
The fact that there is a public place (the baseline) to put the new revision
means Bill has a distribution channel to send the new revised software to
the other project members.
In this way, we have no double maintenance problem, without having
SE 2020 - Vasile Stoicu-Tivadar 34 / 63
multiple copies fo the entire source code database.
Locking
In order to avoid the simultaneous
update problem, we need a
mechanism to prevent two
programmers from simultaneously
copying a single module into their
workspaces for update (if two people
simultaneously update the same
module, one of the changes will
inevitably be last).
Although we want only one
programmer to copy a given module
for update, we would like other
programmers to be able to look at
the module.

It is necessary for all team members to be able to read the baseline copy
of a module but only one team member has a copy into his private
workspace for update (only one person at a time can borrow, all can read).
We keep a record of who the borrower is so that no one is permitted to
return something that he has not borrowed.
SE 2020 - Vasile Stoicu-Tivadar 35 / 63
Locking - continued 1
The facilities for borrowing and
returning:
charge-out - copies a module from
the baseline into the programmer’s
workspace and puts a lock on the
module so that nobody else may
perform a charge-out
charge-in - copies the module from
the workspace, creating a new
revision in the baseline, also removes
the lock so that other programmers
may make further revisions.

Although we want only one programmer

to copy a given module for update, we
would like other programmers to be able
to look at the module.

Simultaneous update is replaced by serial update.

SE 2020 - Vasile Stoicu-Tivadar 36 / 63
Locking - continued 2

•Private workspaces provide a simple but powerful capability for

decreasing the number of defective fixes that become public (but
depends on the degree of testing that is performed in the private
workspace ).
•The rigor of charge-out/charge-in facilitates recording of derivations
(at the time of a charge-in, the derivation of the new revision may be
recorded -nature of the change, reason, date, author etc.).
•Because nobody may change any modules in the baseline except
through the charge-out and charge-in protocol, all revisions in the
baseline are permanently frozen at the time they are charged-in.
•Since no revision in the baseline is ever changed, names of versions
of modules are secure and may safely be used in derivations without
danger of imprecision.

SE 2020 - Vasile Stoicu-Tivadar 37 / 63

 Sharing
The process of referencing data from the
baseline is called sharing from the database.
If we refer to the stability problem (everybody from the software team wants to
maintain the modules needed for testing the won modules, unchanged during
his tests) we can identify one solution: the programmer who wants to test a
module uses charge-out for all the modules needed (not only for the tested
module) -> nobody else can accomplish any work with those modules, until the
programmer finish the tests.
Better solution: the programmer copy all the modules he needs, but without
charge-out.

The risk is in case of occurrence of new revisions until the tests

that use those modules are finished. => before a test is finished
(before the charge-in), the programmer must check if new revisions
are available and test again with these, to be sure that his fix was
current; after the programmer found a bug, the currency is the
primary issue, rather than stability.
• copying specific revisions - when stability is the concern
• sharing from the baseline - when currency is the concern
SE 2020 - Vasile Stoicu-Tivadar 38 / 63
 Integrity of the baseline
•We must take measures to ensure the integrity (internal
consistency) of the baseline (example: we want the
source code always to match the object code).
•The charge-in facility can not guarantee the internal
consistency of the baseline
Example: something that affect several modules is
modified - as a COMMON data structure - and not all
the modules affected are updates, accidentally).
•Configuration management is easier when the software
has an effective distinction between interfaces and
implementation.
Example: the configuration manager
decides that is better if the COMMON data
structure is stored only once and included
in all related modules with a macro facility
The interfaces among modules must be
separate entities stored in the baseline, subject
to their own revision control with charge-out
and charge-in.
•The interface revisions produce problems of keeping
the baseline’s object code current with the source code.
•When redundancy is necessary, the charge-in facility
can minimise errors. We must be careful to keep the
double maintenance monster under SE control
2020 - Vasile Stoicu-Tivadar 39 / 63
 Tools and Procedures

•The job of the configuration manager is to plan the configuration management

strategies for the project.
•The strategies are implemented using configuration management procedures.
•Automatic versus Manual Procedures:
•obtaining compliance with manual procedures can be a major problem
because of the possibility of human error
•manual procedures can, when heavily used, become time-consuming
•in a good development environment, the heavily used procedures are
automated and the rarely used ones can be manual
•the greater the team size, the greater the possibility of error in manual
procedures and the greater the number of procedures that must be automated
•the automated configuration management is not free, so that the project
manager must consider the cost of automating against the cost of not
automating
•for non automating, there are also hidden costs:
•the time programmers spend following manual procedures
•the errors that occur under manual procedures

SE 2020 - Vasile Stoicu-Tivadar 40 / 63

 Noncompliance

•Every manual procedure will find people who cannot follow it

•Every automated procedure will have loopholes that will be abused or stumbled
into
•Why is so difficult to enforce configuration management procedures ?
•Is difficult to staff members to understand the motivation for the
procedures especially inexperienced programmers - tunnel vision -
•see the problem only in terms of individual productivity
•for using the automated tools, they did not understand the difference
between loopholes and intended functionality
It is necessary to teach the inexperienced project members the
reasons for the procedures and the importance of following them
both for their personal growth and to ensure compliance
•The configuration management is a source of irritation for everybody =>
the renegade:
•people who will challenge the rules: “Why are you wasting my time
like this ?” - we can explain to them
•other will resign themselves to doing what they are told: “I’ll do
whatever you want. I’m getting paid by the hour” - also okay people
•there are also stubborn people which must be convinced about the
importance of theSEconfiguration management
2020 - Vasile Stoicu-Tivadar 41 / 63
 Design of the Procedures

•Providing procedures for every exceptional circumstance results in procedures that are
complicated and difficult to use
•It is more important that the procedures be easy to use in the common case than that they
handle all the cases; no set of procedures can be powerful enough for all eventualities
•The initial designer of the procedures should attempt to foresee the common configuration
management needs
•If pervasive symptoms of confusion appear, new procedures can be developed to address
the problem
•Modification of the procedures must be carefully measured because stability is essential
for productivity (“better” procedures are not necessarily better if the increment in quality is
offset by the instability caused by modification)
•The danger in introduction new adaptation of the procedures is that will induce a greater
confusion than ii removes: a perceived inadequacy in the configuration management might
be just an exceptional circumstance requiring manual intervention rather than a
requirement for new procedures

Configuration management is a means, not an end.

SE 2020 - Vasile Stoicu-Tivadar 42 / 63
 The safety valve

•No configuration management procedures can anticipate every eventuality => it is

necessary to build into every automatic procedure an escape valve for human intervention
to override the procedures.
Examples:
•it might be necessary to allow a programmer to violate a charge-out lock and
perform a manually coordinated simultaneous update on a particular module
•it might be necessary to circumvent automatic regression testing if a test is found
to be wrong
•The escape must never be entrusted to someone who will use it to increase personal
productivity at the expense of the project.
•The escape must be entrusted to someone who is of high enough rank that no pressure can
be exerted to grant unwarranted exceptions.
•The automated procedures require substantial money to build. The only way that
configuration management procedures can survive all the obstacles is if they have the
support of management.

•When a deadline is near, there is a strong temptation to throw the configuration

management procedures out and make the maximum number of bug fixes possible =>
wrong fixes get made and the software regresses rather than improves

•The goal of configuration management is not individual productivity in

the short term but long term productivity of the team (if the project is running
late with good configuration management, thinkStoicu-Tivadar
SE 2020 - Vasile how late it will be without it). 43 / 63
Applying the Principles - the system design
phase
about the role of the configuration manager throughout a software project
example (each phase in the project life cycle presents its own challenges):
The system design phase:
• the team is typically small and experienced and can easily coordinate on an informal basis
• the programmers are not thinking about configuration management
• no code is being written, no confusion is evident
• the configuration manager can now head off problems that would appear in later phases
(to lay the groundwork)
• goals:
• to ensure that the design is structured for maximum modularity and information
hiding to simplify configuration management during the later phases
• to institute effective change control on the design documents
• strategy : the configuration manager builds the project baseline to represent the
structure of the software (the elements are software components, the interfaces, the
documentation); this interface is gradually built during the design and coding phases.
•The first design task is to create the information for the initial draft of the system
design document - that shows the decomposition of the system into modules and the
corresponding enumeration of interfaces among the modules
•The system design document contains
•a decomposition illustration showing the modules and their interfaces
•a description of the purpose of each module
•a description of each interface
SE 2020 - Vasile Stoicu-Tivadar 44 / 63
Applying the Principles - The system design
phase - continued 1
The decomposition illustration is an important project reference:
•is given a position of prominence for ease of access by all project members
•it may be posted on the wall in a central location of conference room

SE 2020 - Vasile Stoicu-Tivadar 45 / 63

Applying the Principles - The system design
phase - continued 2
•The descriptions for all modules and
all interfaces are stored in the project
baseline (controlled with charge-in and
charge-out tools).
•A change log is kept for each module of
interface description, every change is
accompanied by an entry into the change
log telling who made the change and
why; the charge-in tool prompts the
designer to provide the change log
information and it automatically records
it
•The system design document is derived
from the project baseline; it is assembled
from the most recent revisions of each
description in the database
•The system design document is
continuously improved and corrected
throughout the project
•The configuration manager controls the
format of each description (the designer
answers to questions and a description
of the module is automatically done):
SE 2020 - Vasile Stoicu-Tivadar 46 / 63
Applying the Principles - The system design
phase - continued 3
The implementation of the strategy - the configuration manager provides the followings to
the team members:
•a write-protected project baseline containing a description file for each module or interface (with all
the revisions of descriptions)
•a procedure that allows a designer to read any interface or module in the project baseline
•private workspaces for each designer
•a procedure that allows a designer to describe a new module or a new interface by answering a
prescribed set of questions (or filling in a form)
•a charge-out procedure that allows a designer to obtain a copy of a description in a private
workspace and which records who performed the charge -out and locks the description against
simultaneous charge-out
•a charge-in procedure that
•checks to make sure that the same person who charged-out is charging-in
•checks the revision to make sure correct format has been preserved
•enters a new revision of a description into the baseline
•creates a change log
•removes the lock
•if an interface is being charged-in, obtains permission from representatives of participating
modules before recording the revision
•a procedure that records that a module or interface no longer exists
•a procedure that goes through the baseline and collects all the modules and interface descriptions
and collates and formats them into a system design document
•a procedure that checks the module descriptions against the interface descriptions to make sure that
the baseline is consistent
•a manual procedure for checking the decomposition illustration against the descriptions present in
the baseline (example: all the modules and interfaces are present in both)
SE 2020 - Vasile Stoicu-Tivadar 47 / 63
Applying the Principles - The detailed design
phase
The product of this phase is a description of the
packages that comprise each module. For each
package, the functions and major data
structures are enumerated and defined.
Goals
•to ensure that the design is structured for
maximum modularity and information hiding
•to institute effective change control on the
design documents themselves
•to organise the baseline to avoid double
maintenance problem
Strategy
•A designer decomposing a module creates a
decomposition illustration showing the
packages of which the modules is composed
•Each package is described to specify:
• functions in the package
(emphasising the global functions)
• major data definitions in the package
(emphasising the global data
structures)
A designer describing a package completes an
online interactive questionnaire. SE 2020 - Vasile Stoicu-Tivadar
48 / 63
Applying the Principles - The detailed design
phase - continued 1
Then, the procedure uses the answers to
prepare a skeleton of the package. This is
an outline of the source code, containing as
much of the package as can be inferred
from the information supplied by the
designer (this is also the first revision of the
source code) and is placed into the project
baseline.
The subroutines are only stubs

The first revision of the package skeleton might contain

only the name of the package, a brief statement of its
purpose, and the names of some of its global functions
and data structures.
Later revisions gradually add more information until the
description is complete.
Because there is no separate design description, there is
no double maintenance between code and design.
When necessary, a document that describes the detailed
design of an entire module is created by collecting from
the baseline the skeleton of all the module packages with:
•a decomposition illustration with packages and
interfaces
•a skeleton of each package SE 2020 - Vasile Stoicu-Tivadar 49 / 63
Applying the Principles - The detailed design
phase - continued 2
Implementation
The configuration manager must provide:

• a procedure that allows a designer to describe a new package by

answering a prescribed set of questions (the procedure automatically
places into the baseline a new package skeleton)

•procedures that allow designers to read, charge-out, charge-in and and

delete packages from the project baseline

•a procedure that collates and formats the skeletons into a detailed

design document

•a procedure that compares each interface that a module provides against

the matching package skeleton and resolves any inconsistencies

The detailed design for a module is finished when its packages are described. At
this point the project has a baseline containing a skeleton for each package in the
module. SE 2020 - Vasile Stoicu-Tivadar 50 / 63
Applying the Principles - The coding phase
Goals:
•to minimise divergence between the code and the detailed design
•to structure the code to simplify debugging
•to maximise compile-time checking of conformance to interfaces

Strategy:
•the programmer writes the code for his package by charging-out the existing source-code
(the skeleton) and filling in the algorithms of the subroutines (without manually copy any
design information)
•the strategically placed comments within the skeleton act as reminders of the expected
purpose, side effects, assumptions, error detection a.s.o., encouraging the programmers to
keep them up to date by correcting commentary errors as they find them
•when a package enters the coding phase, a procedure places into the baseline a
specification file for the package - the configuration manager’s mechanism for obtaining
compile-time checking of conformance to interfaces (these will be included by other
packages that make use of the interface provided)
Example: # include directives in C programs

SE 2020 - Vasile Stoicu-Tivadar 51 / 63

Applying the Principles - The coding phase
- continued
The specification file for
a package (buildstack)

The specification contains only interface

not implementation.

In the C language, the compiler

does not check types of parameters
used in cross-package function
calls (a handicap for the
configuration manager)

Implementation:
•the configuration manager must
provide a procedure that produces a
specification for each package and
places it into the project baseline

SE 2020 - Vasile Stoicu-Tivadar 52 / 63

Applying the Principles - The test phase
After a package is coded, it must be tested: although coding takes very little time and
accounts for a small percentage of the work of the project, testing is time consuming. The
measure of the configuration manager’s success is how quickly the testing phase progress.
Goals:
•to continue to minimise divergence between the code and the detailed design
•to allow programmers to find and fix bugs as quickly as possible by providing a
maximum of independence and stability
•to build a project baseline containing accurate and internally consistent code in
preparation for eventual delivery
Strategy:
•each package is presented by the
following 3 files:
•the source code - original + deltas
• the specification - original + deltas
•the object code - the most recent,
automatically created by configuration
management tools (not charged-in by
the programmers)

SE 2020 - Vasile Stoicu-Tivadar 53 / 63

Applying the Principles - The test phase -
continued 1
•To provide themselves with a completely stable test environment, programmers copy in all
specifications that their packages reference and object code for all modules with which they
are linked.
•After they believe their edits are correct, they will want to test against the current baseline
rather than the copies in their own workspace before charging-in; they compile referencing
the most recent specifications present in the baseline then link with the baseline object
code, then they charge-in; programmers are not allowed to change the specification directly
or change the source-code in a way that contradicts its established specification

•The procedure for charging-in source code:

•for each package, the source-code is compared to its specification to make sure that
programmers haven’t changed anything that would put the source-code in conflict with
the specification (is there is a conflict, programmers must repair)
•the new source code is compiled using the most recent revisions and all the new
source code is rejected if any compilation fails
•the resultant object code is linked with the other object code present in the baseline
•a few tests are submitted against the executable; if any of the tests fails, all the new
package source code is rejected
•the programmer provides a change log entry for each new source code
•a new revision for each package source code is created and saved in the baseline with
SE 2020 - Vasile Stoicu-Tivadar 54 / 63
each newly compiled object code, along with their corresponding derivation histories
Applying the Principles - The test phase -
continued 2
•If is necessary to change in specification, the configuration manager personally charge-out,
edits and charge-in the revised specification. If changes in source code are necessary, the
configuration manager gathers these from the responsible programmers so that all may be
introduced into the baseline at once (in this way the configuration manager maintains the
internal consistency and correctness of the baseline)
•When a specification is changed, object code is potentially incorrect for every package that
uses the specification so that an special charge-in procedure automatically recompiles all
affected packages

Implementation:
The configuration manager must provide procedures to allow programmers to perform:
•charge-out and charge-in source code for packages
•read-only specifications
•compile and link packages against the most recent copies of specifications and object code
present in the baseline
•a manual procedure for proposing and seeking approval for changes to package
specifications
•procedures restricted for use only by the configuration manager for charging-out and
charging-in specifications SE 2020 - Vasile Stoicu-Tivadar 55 / 63
Applying the Principles - QA, Delivery and
Maintenance
•As delivery nears, the project seeks Quality Assurance certification. It is now necessary to
identify, track and fix bugs in an organised manner so management can decide when to
deliver to the customer.
•After the delivery, bugs will continue to be identified.
•The customer will expect revised deliveries in which the bugs are fixed and new functions
are provided.

Goals: The configuration manager’s goals:

•to continue to maintain the accuracy and consistency of the project baseline
•to keep track of which bugs have and have not been fixed
•to prepare customer deliveries that reflect the best state of the software
•to continue to allow programmers to find and fix bugs and to add new features as quick as
possible with a maximum of independence and stability

Strategy:
•the project continues to use charge-out and charge-in
•in this phase, the programmers no longer make changes on their own initiative, only in
response to reported bugs (to the configuration manager by the customers or by the
programmers)
SE 2020 - Vasile Stoicu-Tivadar 56 / 63
Applying the Principles - QA, Delivery and
Maintenance - continued 1
•for each bug reported, the
configuration manager prepares a
bug report, which contains a
description of the bug and a list
of tests that fail due to the bug
and keeps a log of all bug reports
with open and closed bugs (when
a bug has been fixed)

•The programmers locate the

errors and use charge-out and
charge-in
•After making the changes, they
must perform the tests that •The configuration manager prepares an exe file
previously failed, making sure they from the most current object code in the baseline
now pass. and performs the tests that previous failed to make
sure that they now pass.
•On the bug report, the
programmers describe the cause •Then the bug is officially declared dead and the bug
of the bug and the package report is closed.
repaired and which revision
SE 2020 - Vasile Stoicu-Tivadar
resulted. 57 / 63
Applying the Principles - QA, Delivery and
Maintenance - continued 2
•The configuration manager gives the project management a periodic summary of
outstanding and fixed bugs, categorising the bugs by priority; this summary
allows management to decide when the software is or will be ready for delivery
and where resources should be concentrated to fix the most important bugs
•When is time to deliver the software, the configuration manager prepares an exe
file using the most recent object code in the baseline
•This file is thoroughly tested by QA and if it passes, is delivered to the customer
•The configuration manager prepares a special derivation history, called version
description document with:
•the revision numbers of all package source codes and specifications (with
the tools and parameters used, allow to the exe file to be reproduced if
necessary)
•the list of all bug reports still unfixed
•a comprehensive list of differences between this customer delivery and the
last one (including bugs fixed and features added)

SE 2020 - Vasile Stoicu-Tivadar 58 / 63

Applying the Principles - QA, Delivery and
Maintenance - continued 3
•During the maintenance of the software, customers will expect in addition to bug fixes, new
or different functions to be added
•if the changes necessary for these new functions are localised and quick to implement,
they can be tracked and implemented using the bug-tracking mechanism
•If the changes affect a large number of packages, the configuration manager provides
procedures that allow for parallel development efforts

To allow for parallel development, the

configuration manager allows the
team working on new features to
create variations of packages they
plan to modify; since the variation is
available for new feature
development, the package need not
be locked against concurrent access
by the rest of the programming team

The team working on the new functionality (development path 2) has one revision
series whereas the rest of the team (development path 1) has its own parallel series.

SE 2020 - Vasile Stoicu-Tivadar 59 / 63

Applying the Principles - QA, Delivery and
Maintenance - continued 4
•To support the variations of source code, specifications and object code, the
configuration manager provides different sets of baseline management procedures, one
for each of the development paths. For example, the path 2 team will have a special
procedure to vary source code or specification when they decide it is necessary to
change it. Their charge-out procedure will forbid them to charge-out a package until they
have varied it:
•compares the new source code against the path 2 variation of the package
specification to make sure specification and source code do not conflict
•compiles the new source code using the most recent revisions of the path 2
specifications
•links the resultant object code with other path 2 object code
•performs special tests for path 2 against the resultant executable (necessary
because path 2 has different functionality than path 1)
•accepts from the programmers change-logs for the new source code
•saves in the baseline a new revision for the path 2 variation
•The teams now merge their development paths in preparation for a new delivery
(includes both the new functionality - path 2- and the bug fixes and enhancements - path
1): for each package whose source code has been varied, a programmer is assigned to
merge the development paths.
SE 2020 - Vasile Stoicu-Tivadar 60 / 63
Applying the Principles - QA, Delivery and
Maintenance - continued 5
•The programmer starts with the most
recent revision of one of the paths and
applies all the deltas that have been applied
along the other paths.

Implementation: to support the

programming staff during the QA, Delivery
and Maintenance, the configuration
•For parallel development
manager provides the following:
•Capabilities in the baseline to support dual
•a procedure for creating a new bug report object code for each package
(including entering the bug in the
•a procedure to vary a package source
configurations manager’s log)
code, specification or description
•a procedure for closing a bug report •improved procedures for charge-in,
(including appropriate testing of the fix) charge-out and other
•periodic reports on the status and number •Semiautomatic procedures for merging
of bugs parallel development paths (including
•a version description document for each automatic application of deltas from one
software delivery path to a revision on the other path)
SE 2020 - Vasile Stoicu-Tivadar 61 / 63
 What this chapter means for You
You can use the concepts from this chapter in the following ways:
as individual
- to understand the need and the importance of the configuration
management
- to learn to be configuration manager and to use appropriate
configuration management tools
- to learn to develop software projects accordingly to the needs of
configuration management, including the specific discipline, technique
and tools needed

as team
- to work together and to collaborate with the configuration manager in
order to implement the concepts of the configuration management

SE 2020 - Vasile Stoicu-Tivadar 62 / 63

Thank you for your
attention !

SE 2020 - Vasile Stoicu-Tivadar