C O N F I G U R AT I O N

MANAGEMENT
PROJECT MANAGEMENT

9/2020
1
Contents
1. Introduction to Configuration management
2. Change management
3. Version management
4. System building
5. Release management

2
Contents
1. Introduction to Configuration management
2. Change management
3. Version management
4. System building
5. Release management

3
Introduction to CM
• Changes: Software systems always change during
development and use.
– Bugs are discovered and have to be fixed.
– System requirements change, and you have to implement
these changes in a new version of the system.
– New versions of hardware and system platforms become
available and you have to adapt your systems to work with
them.
– Competitors introduce new features in their system that you
have to match.
• As changes are made to the software, a new version
of a system is created.

4
Introduction to CM
• Configuration management (CM) is concerned with
the policies, processes, and tools for managing
changing software systems.
– You need to manage evolving systems because it is easy to
lose track of what changes and component versions have
been incorporated into each system version.
– There may be several versions under development and in
use at the same time. If you don’t have effective
configuration management procedures in place, you may
waste effort modifying the wrong version of a system,
deliver the wrong version of a system to customers, or
forget where the software source code for a particular
version of the system or component is stored.

5
CM activities
• The configuration management of a software system
product involves four closely related activities:
1. Change management This involves keeping track of
requests for changes to the software from customers and
developers, working out the costs and impact of making
these changes, and deciding if and when the changes
should be implemented.
2. Version management This involves keeping track of the
multiple versions of system components and ensuring that
changes made to components by different developers do
not interfere with each other.

6
CM activities
• The configuration management of a software
system product involves four closely related
activities (cont.):
3. System building This is the process of assembling
program components, data, and libraries, and then
compiling and linking these to create an executable
system.
4. Release management This involves preparing
software for external release and keeping track of the
system versions that have been released for
customer use.

7
CM activities
• Configuration management policies and processes
define:
– how to record and process proposed system changes,
– how to decide what system components to change,
– how to manage different versions of the system and its
components, and
– how to distribute changes to customers.
• Configuration management tools are used to
– keep track of change proposals, store versions of system
components, build systems from these components, and
track the releases of system versions to customers.

8
CM and Quality Management
• Configuration management is sometimes considered
to be part of software quality management, with the
same manager having both quality management and
configuration management responsibilities.
– When a new version of the software has been
implemented, it is handed over by the development team to
the quality assurance (QA) team.
– The QA team checks that the system quality is acceptable.
If so, it then becomes a controlled system, which means
that all changes to the system have to be agreed on and
recorded before they are implemented.

9
CM and Quality certification
• The definition and use of configuration management
standards is essential for quality certification in both
the ISO 9000 and the CMM and CMMI standards.
– These CM standards can be based on generic CM
standards that have been developed by bodies (IEEE, etc.)
– For example, standard IEEE 828-1998 is a standard for
configuration management plans. These standards focus
on CM processes and the documents produced during the
CM process.
– Using the external standards as a starting point, companies
then develop more detailed, company-specific standards
that are tailored to their specific needs.

10
Contents
1. Introduction to Configuration management
2. Change management
3. Version management
4. System building
5. Release management

11
Change management
• Organizational needs and requirements change
during the lifetime of a system, bugs have to be
repaired, and systems have to adapt to changes in
their environment.
• To ensure that the changes are applied to the system
in a controlled way, you need a set of tool-supported,
change management processes.
• Change management is intended to ensure that the
evolution of the system is a managed process and
that priority is given to the most urgent and cost-
effective changes.
12
Change management
• The change management process is concerned
with
– checking the change requests,
– analyzing the costs, benefits of proposed changes,
– approving those changes that are worthwhile, and
– tracking which components in the system have been
changed.

13
• Bug report
• Request for new
functionality

14
Change requests
• Change request may be:
– a bug report, where the symptoms of the bug are
described, or
– a request for additional functionality to be added to the
system.
• Some companies handle bug reports and new
requirements separately but, in principle, these
are both simply change requests.
• Change requests may be submitted using a
change request form (CRF)

15
16
Checking the change requests
• After a change request has been submitted, it is
checked to ensure that it is valid.
• The checker may be from a customer or
application support team or, for internal requests,
may be a member of the development team.

17
Checking the change requests
• Checking is necessary because not all change
requests require action:
– If the change request is a bug report, the bug may have
already been reported.
– Sometimes, what people believe to be problems are
actually misunderstandings of what the system is expected
to do.
– On occasions, people request features that have already
been implemented but which they don’t know about.
 If any of these are true, the change request is closed
and the form is updated with the reason for closure. If
it is a valid change request, it is then logged as an
outstanding request for subsequent analysis.

18
Change assessment and
costing
• For valid change requests, the next stage of the
process is change assessment and costing.
– This is usually the responsibility of the development or
maintenance team as they can implement the change.
– Checking the impact of the change on the rest of the
system. To do this, identify all of the components
affected by the change  cost may be increased!
– Next, the required changes to the system modules are
assessed. Finally, the cost of making the change is
estimated, taking into account the costs of changing
related components.

19
Approving change requests
• A separate group should decide if the change is
cost-effective from a business perspective
– For military and government systems, this group is
often called the change control board (CCB).
– In industry, it may be called something like a ‘product
development group’, who is responsible for making
decisions about how a software system should evolve.

20
Approving change requests
• This group should review and approve all change
requests, unless the changes simply involve
correcting minor errors on screen displays,
webpages, or documents.
– These small requests should be passed to the
development team without detailed analysis, as such
an analysis could cost more than implementing the
change.

21
Approving change requests
• The CCB or product development group
considers the impact of the change from a
strategic and organizational rather than a
technical point of view.
– It decides whether the change in question is
economically justified and prioritizes accepted
changes for implementation.
– Accepted changes are passed back to the
development group;
– Rejected change requests are closed and no further
action is taken.
22
Approving change requests
• Significant factors that should be taken into account
in deciding whether a change should be approved:
1. The consequences of not making the change what will
happen if the change is not implemented. If the change is
associated with a reported system failure, the seriousness
of that failure has to be taken into account.
• If the system failure causes the system to crash  very serious
• If the failure has a minor effect (incorrect colors…)  it is not
important to fix the problem quickly  low priority.

23
Approving change requests
• Significant factors (cont.):
2. The benefits of the change Is the change something
that will benefit many users of the system or is it
simply a proposal that will primarily be of benefit to
the change proposer?
3. The number of users affected by the change If only
a few users are affected, then the change may be
assigned a low priority.
• In fact, making the change may be inadvisable if it could have
adverse effects on the majority of system users.

24
Approving change requests
• Significant factors (cont.):
4. The costs of making the change If making the
change affects many system components (hence
increasing the chances of introducing new bugs)
and/or takes a lot of time to implement, then the
change may be rejected - elevated cost!
5. The product release cycle If a new version of the
software has just been released to customers, it may
make sense to delay the implementation of the
change until the next planned release.

25
Derivation history
• As the development team changes software
components, they should maintain a record of the
changes made to each component.
– This is sometimes called the derivation history of a
component.
– A good way to keep the derivation history is in a
standardized comment at the beginning of the
component source code.
– This comment should reference the change request
that triggered the software change.

26
 Derivation history

For documents, records of changes are usually maintained in

a separate page at the front of the document.
27
 Derivation history

Derivation history
You can write simple scripts that scan all components and process
the derivation histories to produce component change reports.
28
Tools
• Change management is usually supported by
specialized software tools:
– Bugzilla
– Jira
– Mantis

29
Contents
1. Introduction to Configuration management
2. Change management
3. Version management
4. System building
5. Release management

30
Version management
• Version management (VM) is the process of
keeping track of different versions of software
components or configuration items and the
systems in which these components are used.
• It also involves ensuring that changes made by
different developers to these versions do not
interfere with each other.
– You can, therefore, think of version management as
the process of managing codelines and baselines.

31
• A codeline is a sequence of versions of source code with
later versions in the sequence derived from earlier versions.
• A baseline specifies the component versions are included in
the system plus libraries used, configuration files…
• The mainline is a sequence of system versions.
32
Baselines
• Baselines may be specified using a configuration
language, which allows you to define what
components are included in a version of a
particular system.
– It is possible to explicitly specify a specific component
version (X.1.2) or simply to specify the component
identifier (X).
– If you use the identifier, this means that the most
recent version of the component should be used in the
baseline.

33
Baselines
• Baselines are important because you often have
to re-create a specific version of a complete
system.
– For example, individual system versions for different
customers. You may have to re-create the version
delivered to a specific customer if, for example, that
customer reports bugs in their system that have to be
repaired.

34
Version management tools
• To support version management, you should
always use version management tools. Sometime
called:
– version control systems or
– source code control systems.
• Some version management tools:
– CSV
– Subversion (centralized)
– Git (distributed)
– Mercurial (distributed)

35
Distributed and centralized
version control

1. You commit
2. They update

https://homes.cs.washington.edu/~mernst/advice/version-control.html 36
Distributed and centralized
version control

1. You commit
2. You push
3. They pull
4. They update

https://homes.cs.washington.edu/~mernst/advice/version-control.html 37
Check in / Commit

Check in: Upload a file to the repository (if it has changed).

The file gets a new revision number.
38
Features of version
management systems
• Version management systems normally provide a
range of features:
– Version and release identification: Managed
versions are assigned identifiers when they are
submitted to the system.
- These identifiers are usually based on the name of the
configuration item (e.g., ButtonManager), followed by one or
more numbers. So ButtonManager 1.3 means the third
version in codeline 1 of the ButtonManager component.

39
Features of version
management systems
• Version management systems normally provide a
range of features:
– Storage management: To reduce the storage space
required by multiple versions of components that differ
only slightly, version management systems usually
provide storage management facilities.
- Instead of keeping a complete copy of each
version, the system stores a list of differences
(deltas) between one version and another.
- By applying these to a source version, a target
version can be re-created.

40
Features of version
management systems

Storage management using deltas

41
Features of version
management systems
• Version management systems normally provide a
range of features:
– Change history recording All of the changes made to
the code of a system or component are recorded.
– Independent development Different developers may
be working on the same component at the same time.
The version management system keeps track of
components that have been checked out for editing
and ensures that changes made to a component by
different developers do not interfere.

42
Features of version
management systems
• Version management systems normally provide a
range of features:
– Project support A version management system may
support the development of several projects, which
share components.
- In project support systems, such as CVS, it is
possible to check in and check out all of the files
associated with a project rather than having to work
with one file or directory at a time.

43
Both Alice and Bob are changing C.
It’s important to avoid these changes interfering with each
other—Bob’s changes to C overwriting Alice’s or vice versa.
44
Conflict

45
Supporting independent
development
• To support independent development without
interference, version management systems use
the concept of a public repository and a private
workspace.
– Developers check out components from the public
repository into their private workspace and may
change these as they wish in their private workspace.
– When their changes are complete, they check in the
components to the repository.

46
Tortoise Merge

47
 Branching and merging

• Codelines may branch: different developers work independently on

different versions of the source code and change it in different ways.
• At some stage, it may be necessary to merge codeline branches to
create a new version of a component that includes all changes that have
been made. 48
Key points
• Configuration management is the management of an
evolving software system. When maintaining a
system, a CM team is put in place to ensure that
changes are incorporated into the system in a
controlled way and that records are maintained with
details of the changes that have been implemented.
• The main configuration management processes are
concerned with change management, version
management, system building, and release
management. Software tools are available to support
all of these processes.

49
Key points
• Change management involves assessing proposals
for changes from system customers and other
stakeholders and deciding if it is cost-effective to
implement these in a new version of a system.
• Version management involves keeping track of the
different versions of software components that are
created as changes are made to them.
• System building is the process of assembling system
components into an executable program to run on a
target computer system.
50
Key points
• Software should be frequently rebuilt and tested
immediately after a new version has been built.
This makes it easier to detect bugs and problem
that have been introduced since the last build.
• System releases include executable code, data
files, configuration files, and documentation.
Release management involves making decisions
on system release dates, preparing all
information for distribution, and documenting
each system release.

51
References
As described in the Introduction slide.

52