PMIT 6111

08

1
Why Software Configuration Management ?

 Because software changes frequently, systems, can be thought of

as a set of versions, each of which has to be maintained and
managed.
 Versions implement proposals for change, corrections of faults, and
adaptations for different hardware and operating systems.
 Configuration management (CM) is concerned with the policies,
processes and tools for managing changing software systems.
You need CM because it is easy to lose track of what changes
and component versions have been incorporated into each
system version.

2
Configuration Management Activities
The configuration management of a software system
product involves four closely related activities
• Version control 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.
• System building This is the process of assembling program
components, data, and libraries, then compiling and linking these to
create an executable system.
• Change management This involves keeping track of requests for
changes to delivered 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.
• Release management This involves preparing software for external
release and keeping track of the system versions that have been
released for customer use.

3
Configuration Management Activities 4
Configuration Management Roles

• Configuration Manager
Responsible for identifying configuration items. The configuration manager
can also be responsible for defining the procedures for creating promotions
and releases
• Change control board member
Responsible for approving or rejecting change requests
• Developer
Creates promotions triggered by change requests or the normal activities of
development. The developer checks in changes and resolves conflicts
• Auditor
Responsible for the selection and evaluation of promotions for release and
for ensuring the consistency and completeness of this release

5
Terminology

Term Explanation

Configuration item or Anything associated with a software project (design, code, test data,
software configuration document, etc.) that has been placed under configuration control. There are often

item (SCI) different versions of a configuration item. Configuration items have a unique name.
The process of ensuring that versions of systems and components are recorded
Configuration control and maintained so that changes are managed, and all versions of components are
identified and stored for the lifetime of the system.
An instance of a configuration item that differs, in some way, from other instances
Version of that item. Versions always have a unique identifier, which is often composed of the
configuration item name plus a version number.
A baseline is a collection of component versions that make up a system. Baselines
are controlled, which means that the versions of the components making up the
Baseline
system cannot be changed. This means that it should always be possible to
recreate a baseline from its constituent components.
A codeline is a set of versions of a software component and other
Codeline
configuration items on which that component depends.

6
Change management

• Change management is the handling of change requests

A change request leads to the creation of a new release
• General change process
❖ The change is requested (this can be done by anyone including users
and developers)
❖ The change request is assessed against project goals
❖ Following the assessment, the change is accepted or rejected
❖ If it is accepted, the change is assigned to a developer and
implemented
❖ The implemented change is audited.
• The complexity of the change management process varies with the project. Small
projects can perform change requests informally and fast while complex projects
require detailed change request forms and the official approval by one more managers.

7
Factors in change analysis

• The consequences of not making the change

• The benefits of the change
• The number of users affected by the change
• The costs of making the change
• The product release cycle

8
Change management and agile methods

• In the most popular agile methods, customers are

directly involved in change management.
• They propose a change to the requirements and work
with the team to assess its impact and decide whether
the change should take priority over the features
planned for the next increment of the system.
• Changes to improve the software improvement are
decided by the programmers working on the system.
• Refactoring, where the software is continually improved,
is not seen as an overhead but as a necessary part of
the development process.

9
System building 10

• System building is the process of creating a complete, executable

system by compiling and linking the system components, external
libraries, configuration files, etc.
• System building tools and version management tools must
communicate as the build process involves checking out
component versions from the repository managed by the version
management system.
• The configuration description used to identify a baseline is also
used by the system building tool.
System building 11

Figure :System building

Tools for system integration and building

1. Build script generation The build system should

analyze the program that is being built, identify
dependent components, and automatically generate a
build script (configuration file). The system should also
support the manual creation and editing of build scripts.
2. Version control system integration The build system
should check out the required versions of components
from the version control system.
3. Minimal recompilation The build system should work
out what source code needs to be recompiled and set
up compilations if required.

12
Tools for system integration and building

4. Executable system creation The build system should

link the compiled object code files with each other and
with other required files, such as libraries and
configuration files, to create an executable system.
5. Test automation Some build systems can
automatically run automated tests using test
automation tools such as JUnit. These check that the
build has not been “broken” by changes.
6. Reporting The build system should provide reports
about the success or failure of the build and the tests
that have been run.
7. Documentation generation The build system may be
able to generate release notes about the build and
system help pages. 13
Build platforms 14

Building is a complex process, which is potentially

error-prone, as three different system platforms may
be involved
• The development system, which includes development tools
such as compilers, source code editors, etc. Developers check out
code from the version management system into a private
workspace before making changes to the system.
• The build server, which is used to build definitive, executable
versions of the system. Developers' check-in code to the version
management system before it is built. The system build may rely on
external libraries that are not included in the version management
system.
• The target environment, which is the platform on which the
system executes. This may be the same type of computer that is
used for the development and build systems
Development, build, and target platforms 15
Agile building (Continuous Integration)

Agile methods recommend that very frequent system

builds should be carried out, with automated testing used
to discover software problems. Frequent builds are
part of a process of continuous integration. The steps in
continuous integration are:
1. Check out the mainline system from the version management
system into the developer’s private workspace.
2. Build the system and run automated tests to ensure that the built
system passes all tests. If not, the build is broken and you should
inform whoever checked in the last baseline system. They are
responsible for repairing the problem.
3. Make the changes to the system components.
4. Build the system in the private workspace and rerun system tests.
If the tests fail, continue editing.
16
Agile building(Continuous Integration)

5. Once the system has passed its tests, check it into the build
system but do not commit it as a new system baseline.
6. Build the system on the build server and run the tests. You need to
do this in case others have modified components since you
checked out the system. If this is the case, check out the
components that have failed and edit these so that tests pass on
your private workspace.
7. If the system passes its tests on the build system, then commit the
changes you have made as a new baseline in the system
mainline.

17
Continuous integration 18
Daily building
For large systems or for systems where the execution platform is not
the same as the development platform, continuous integration is
usually impossible. In those circumstances, frequent system building is
supported using a daily build system:
1. The development organization sets a delivery time (say 2 p.m.) for
system components. If developers have new versions of the
components that they are writing, they must deliver them by that
time. Components may be incomplete but should provide some
basic functionality that can be tested.
2. A new version of the system is built from these components by
compiling and linking them to form a complete system.
3. This system is then delivered to the testing team, which carries out
a set of predefined system tests.
4. Faults that are discovered during system testing are documented
and returned to the system developers. They repair these faults in
a subsequent version of the component.
19
Release management

• A system release is a version of a software system that

is distributed to customers.
• For mass market software, it is usually possible to
identify two types of release: major releases which
deliver significant new functionality, and minor releases,
which repair bugs and fix customer problems that have
been reported.
• For custom software or software product lines, releases
of the system may have to be produced for each
customer and individual customers may be running
several different releases of the system at the same
time.

20
Release planning

• As well as the technical work involved in creating a

release distribution, advertising and publicity material
have to be prepared and marketing strategies put in
place to convince customers to buy the new release of
the system.
• Release timing: If releases are too frequent or require
hardware upgrades, customers may not move to the
new release, especially if they have to pay for it. If
system releases are too infrequent, market share may
be lost as customers move to alternative systems.

21
Factors influencing system release planning

• .

22