Configuration management is a software engineering discipline that involves identifying and managing the configuration of software assets such as code, documents, and other project artifacts. It aims to control modifications to software and maintain integrity and traceability throughout the development and maintenance lifecycles. Key aspects of configuration management include configuration identification, change control, configuration management planning, builds, and tools.

1. 1
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
Faculty of Engineering - Helwan University

2. 2

3. 3
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

4. 4

5. 5
 A software engineering discipline
 Comprised of tools and techniques
 used to manage change to software assets.
 Made of many parts
 Documents
 Programs
 Thousands of separate documents are generated for a
large software system.

6. 6
 A software system changes
 Different instantiations of software for different customers
 Same software changes over time
 Parts of software must be kept consistent over changes
 Configuration management
• A methodology to control and manage a software
development project.
“No matter where you are in the system life
cycle, the system will change, and the desire
to change it will persist throughout the life
cycle.” [Bersoff et al., 1980]

7. 7

8. 8
 Team develops software
 Many people need to access parts of software
 Common repository, all can read/write documents/ programs
 Problems:
 Concurrent access
• What if two people access same document at same time?
 Concurrent modification
• What if two people access same document and both modify
it?
 Notification of changes
• Document is changed, how all are informed?

9. 9
 One
 John changes module A to fix bug
 Meanwhile Linda downloads old A and links it
 Two
 John and Jack download A to fix bugs
 John uploads A
 Jack uploads A (John’s changes are lost)
 Three
 Module A is used in system X
 John fixes bug in A
 Nobody is notified to relink A in X

10. 10
 Definition:
 Software Configuration Management encompasses the
disciplines and techniques of initiating, evaluating and
controlling change to software products during and after
the software engineering process.
 Standards (approved by ANSI)
 IEEE 828: Software Configuration Management Plans
 IEEE 1042: Guide to Software Configuration Management

11. 11
 Need Configuration Management in order to:
 Identify and manage parts of software
 Control access and changes to parts
 Help control product integration
 (and to meet ISO and CMM standards)
 Main functions of CM are:
 Configuration Identification
 Configuration Control
 Configuration Audits
 Configuration Status Accounting
 Done properly, CM is almost invisible!
 CM mistakes are often far too visible

12. 12
 Configuration Control
 Controlling product release and its updates.
 Status Accounting
 Recording and reporting components’ status.
 Review
 Ensuring completeness and consistency of all parts.
 Build Management
 Managing the build process and its tools.
 Process Management
 Ensuring adherence to the development process.
 Environment Management
 Managing the components that host our system.
 Teamwork
 Facilitate team interactions

13. 13
 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

14. 14
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

15. 15
 Configuration item (CI)
 Configuration
 Version
 Baseline

16. 16
 Configuration Item (SCI)
 A piece of software, a document, apiece of hardware or work
product which is subject to change is a configuration item
 Configuration items are ‘things’ we want to keep track
of and control.
 Examples:
 Requirement document
 Design document
 Software code
• Source code, Object code, or Prototype software
 Data Files
• Test cases and test scripts, Parameters, codes, etc.
 Software Development Tools
• Compilers and debuggers, or Application generators

17. 17
 Software configuration items are not only program code
segments but all type of documents according to
development, e.g
 all type of code files
 drivers for tests
 analysis or design documents
 user or developer manuals
 system configurations (e.g. version of compiler used)
 In some systems, not only software but also hardware
configuration items (CPUs, bus speed frequencies) exist!
 Changes to CI are subject to procedures defined by CM
system
 Typically, change must be approved and recorded
 New version of CI must be generated

18. 18
 Problem Statement
 Software Project Management Plan
(SPMP)
 Requirements Analysis Document
(RAD)
 System Design Document (SDD)
 Project Agreement
 Object Design Document (ODD)
 Dynamic Model
 Object model
 Functional Model
 Unit tests
 Integration test strategy
 Source code
 API Specification
 Input data and data bases
 Test plan
 Test data
 Support software (part of the
product)
 Support software (not part of the
product)
 User manual
 Administrator manual

19. 19
 Problem Statement
 Software Project Management Plan
(SPMP)
 Requirements Analysis Document
(RAD)
 System Design Document (SDD)
 Project Agreement
 Object Design Document (ODD)
 Dynamic Model
 Object model
 Functional Model
 Unit tests
 Integration test strategy
 Source code
 API Specification
 Input data and data bases
 Test plan
 Test data
 Support software (part of the
product)
 Support software (not part of the
product)
 User manual
 Administrator manual
Once the Configuration Items are selected, they are usually organized in a tree

20. 20
“The project” CI
Models Subsystems Documents
Object Model Dynamic Model
Database User Interface
. . . .
Code Data Unit Test
RAD ODD
. . . . . . . .
. . . .
“The project”
RAD: Requirements Analysis Document
ODD: Object Design Document

21. 21
 Version:
 An initial release or re-release of a configuration item
associated with a complete compilation or recompilation
of the item. Different versions have different
functionality.
 Instance of CI
 Revision:
 Change to a version that corrects only errors in the
design/code, but does not affect the documented
functionality.
 Release:
 The formal distribution of an approved version.

22. 22
 Snapshot of software at certain time
 Various CIs, each in a certain version
 Same CI may appear in different configurations
 Also configuration has version
 Example:
 System 1.0 (configuration 1.0)
• File2.c 1.0 + File1.c 1.0 + Readme 1.0
 System 1.1 (configuration 1.1)
• File2.c 1.0 + File1.c 1.1 + Readme 1.0

23. 23
 Baseline is “A specification or product that has been formally
reviewed and agreed to by responsible management, that
thereafter serves as the basis for further development, and can
be changed only through formal change control procedures.”
 Configuration in stable, frozen form
 Not all configurations are baselines
 Any further change/development will produce new version(s) of
CI(s), will not modify baseline
 Types of baselines:
 Development baseline – (SRS, SDD, Integration Test, ...)
• Goal: Coordinate engineering activities.
 Functional baseline - (first prototype, alpha release, beta release)
• Goal: Get first customer experiences with functional system.
 Product baseline - product for delivery
• Goal: Coordinate sales and customer support.

24. 24

25. 25
 The process of:
 Breaking a system down into a number of known and
manageable parts (configuration items)
 Labeling software and hardware configuration items with unique
identifiers.
 Identifying the documentation that describes a configuration
item.
 Grouping related configuration items into baselines.
 Labeling revisions to configuration items and baselines.
 The following tables show how a unique number is
developed for each project CI.

26. 26
 Record of changes applied to a document or code component
 Should record, in outline, the change made, the rationale for
the change, who made the change and when it was
implemented
 May be included as a comment in code.

27. 27
 Procedures for version identification should define an
unambiguous way of identifying component versions
 Basic techniques for component identification:
1) Version numbering:
• Simple naming scheme uses a linear derivation
• e.g. V1, V1.1, V1.2, V2.1, V2.2 etc.
• Names are not meaningful.
2) Attribute-based identification:
• Attributes can be associated with a version with the
combination of attributes identifying that version.
• Examples of attributes are Date, Creator, Programming
Language, Customer, Status.

28. 28
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

29. 29
 The problem: allow users to share information, but prevent
them from accidentally stepping on each other's feet?
Figure from svn-book

30. 30
 Changes must be disciplined
 Who controls
 What is controlled
 How control is implemented
 Approaches:
1)Configuration Control Board (CCB):
• Best for maintenance process
– Ex Windows Vista after jan 2007
2)Check in – check out model, Workspaces:
• Best for development process
– Ex Windows Vista before jan 2007

31. 31
 Repository
 A server where the files are stored.
 Workspace
 ‘Private’ space where developer has full control
 Check-Out
 Extraction of CI from repository
• with goal of changing it or not
• After checkout next users are notified
 Checked-out CI is locked or not
• If locked, one writer, many readers [i.e. Only one can modify]
 Commit or Check-in
 Insertion of CI under control
 Checked-in CI increments version or not
• If not, old version is lost

32. 32
 Change
 A specific modification to a document under version control.
 Change List
 The set of changes made in a single commit.
 A sequential view of the source code.
 Update
 copies the changes that were made to the repository into your
working directory.
 Merge / Integration
 brings together (merges) concurrent changes into a unified
revision.

33. 33
 Revision or version
 one version in a chain of changes.
 Conflict
 Occurs when two changes are made by different parties to the
same document or place within a document.
 Resolve
 The act of user intervention to address a conflict between
different changes to the same document.

34. 34
 Lock-Modify-Unlock (or serialization)
 One can change at a time
 Copy-Modify-Merge
 Many change in parallel, then merge

35. 35
 Only one person to
change a file at a
time.

36. 36
 Administrative problems:
 A user can lock a file and forget about it.
• Time is wasted while others wait to edit the file.
 Unnecessary serialization:
 Different parts of a file don’t necessarily overlap.
• E.g.: Alice works on the beginning of a file, Bob wants to
edit the end of the same file.
 False sense of security:
 Let’s say Alice locks and edits file A, while Bob
simultaneously locks and edits file B.
 Let’s say A and B depend on one another, and the changes
made to each are semantically incompatible.
 Suddenly, A and B don't work together anymore.

37. 37

38. 38
 Configuration Control Board
 Authorizes changes to a baseline
• Corrective maintenance
 Defines what will be in next baseline
• Perfective maintenance
 Changes should be reviewed by an external group who
decide whether or not they are cost-effective from a
strategic and organizational viewpoint rather than a
technical viewpoint
 Should be independent of project responsible for
system. The group is sometimes called a change control
board

39. 39

40. 40
 Definition of change request form is part of the CM
planning process
 Records change required, suggest of change, reason why
change was suggested and urgency of change (from
requestor of the change)
 Records change evaluation, impact analysis, change cost
and recommendations (System maintenance staff)

41. 41

42. 42
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

43. 43
 Starts during the early phases of the project
 Must define (CM plan document)
 CIs
• Identification, versioning
 Baselines
 Change control rules, roles, responsibilities
 Tools used

44. 44
 The product
 Several subsystems, each subsystem an executable and
several source files (modules)
 Hierarchy
 The team
 One person responsible per module
 One person responsible per subsystem
 The repository
 One repository per subsystem
 Check in/out
 Workspace per person

45. 45
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

46. 46
 The process of compiling and linking software
components into an executable system
 Different systems are built from different combinations
of components
 Invariably supported by automated tools that are driven
by ‘build scripts’

47. 47

48. 48
 Do the build instructions include all required components?
 When there are many hundreds of components making up a system,
it is easy to miss one out. This should normally be detected by the
linker.
 Is the appropriate component version specified?
 A more significant problem. A system built with the wrong version
may work initially but fail after delivery.
 Is the system being built for the right platform
 Sometimes must build for a specific OS version or hardware
configuration.
 Is the right version of the compiler and other software tools
specified?
 Different compiler versions may actually generate different code
and the compiled component will exhibit different behavior.
 Are data file references within components correct?
 Embedding absolute names in code almost always causes problems
as naming conventions differ from place to place.

49. 49
 Configuration Management
 Configuration Identification
 Change Control
 Configuration management planning
 Build
 Tools

50. 50
 Functions:
 Change management
 Version management
 Build
 Tools:
 CM + VM
● RCS ● VSS
● CVS ● SCCS
● PCVS ● Clearcase
● Subversion ● BitKeeper
 Build
● Make
● Ant
● Maven
 Continuous integration
● Jenkins
● Hudson
● CruiseControl

51. 51
 Visual SourceSafe (VSS):
 Central repository of read-only files.
 Everybody sees the same version.
 Only one user can check in at once.
 Limited merge capabilities.
 Advantages of SourceSafe:
 Synchronized with Visual Studio.
 Relatively inexpensive.
 Relatively simple to administrate.
 Disadvantages of SourceSafe:
 Not compatible with other OS’s.

52. 52
 Part of Unix
 Allows to describe components and dependencies among
components
 Allows to describe operations to build system from
components
 Builds system – recompiles only if component was
changed (using data tag)

53. 53
 A build tool like make
 Open source
 from the Apache Jakarta project
 http://jakarta.apache.org/ant
 Implemented in Java
 Used to build many open source products
 Such as Tomcat and JDOM

54. 54
 “Software configuration management: A roadmap”, J.E
stublier, Proc. Int. Conf. on Software Engineering, 2000,
IEEE Press.
 IEEE STD 1042 – 1987 IEEE guide to software
configuration management
 IEE STD 828-2005 Standard for Software Configuration
Mangement Plans
 “Configuration Management Principle and Practice”,
A.M.J.Hass,2002, Addison Wesley

55. 55