1. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 1
Configuration management
McGill ECSE 428
Software Engineering Practice
Radu Negulescu
Winter 2003

2. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 2
About this course module
A typical software project may generate thousands of source files and
pieces of documentation, and there are many opportunities for
introducing inconsistencies between these artifacts:
• Teamwork, parallel development and QA
• Change requests
• Bug fixes
• Schedule pressures
Here we discuss how to effectively organize the artifacts of a software
project.
Recommended reading:
• Jalote ch. 10
• Bruegge & Dutoit 10.2,10.3,10.4.1,10.4.3,10.4.4
• McConnell Rapid Dev. pp. 338-341, 403-414

3. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 3
What is configuration management
B&D: The disciplines and techniques of initiating, evaluating and
controlling change to software products during and after development.
• In other words, staying on top of change
Known by many names:
• CM
• SCM - sometimes pronounced “scum”
• Version control
• Source control (especially in relation to code)
• Document control

4. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 4
Development problems addressed
Typical problems of software projects due to lack of tracking:
• Communication blocks
• Inconsistencies
Accidental deletes
Wrong releases
Overlapping updates
• Lost issues (and rework)
Lost bug reports
Lost reasons for change
• Poor predictability
Absence of baseline data
• Awkward integration
• High cost of human error
Difficult “undo”

5. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 5
Challenges of configuration management
Challenges:
• Number of change requests (100s, 1000s, ...)
• Rapid growth of configurations: builds components variants
• Superlinear growth of team coordination overhead
Number of communication paths required
• Dangers of bureaucracy
• ...

6. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 6
Configurations
Item: artifact under configuration management
• Possibly nested aggregate
• Possibly overlapping with other aggregates
Configuration: state of an item
Variants: configurations of the same item that are intended to coexist
Beware:
• Terminology varies, although needs and solutions are similar
• Focus on the concepts

7. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 7
Configurations
Version: augmented specification
• Additional features
• Major or minor, depending on the amount of features
Release: same spec, enhanced implementation
• Bug fixes
• Refactored architecture
Build: instance of a system, integrated
• For testing
• Release candidates
Shown to customer for evaluation
Become a release once accepted

8. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 8
Typical CM functions
Retrieve a configuration / undo a change
• E.g. what was our best build?
• … before we messed up the event model?
Life cycle control
• Static access restrictions
E.g. a code module can only be signed out by the “owner” (Dev.)
E.g. a bug report can only be put in “closed” state by QA
E.g. each new feature must be impact analyzed before it is scheduled for
development
E.g. only PL and CC create releases
• Dynamic access restrictions
E.g. no simultaneous updates

9. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 9
Typical CM functions
Automatic builds
• Invoke the compiler tools on the updated files only
Concurrent updates
• Branching then merging
• Reconciliation of changes
Tracing rationale
• E.g. why did we need a new event model anyway?
• Who issued a request for change?
Propagating change
• E.g. bug fix for deployed version then new version
• E.g. multiple platforms, languages, user privileges
Statistics
• E.g. determine percentage of testing vs. development delays

10. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 10
Retrieving a configuration
What we want from a mechanism for retrieving configurations:
• Label configurations in a way that orients the users
• Store configurations efficiently
There can be many of them...
• Be tailored to the actual flow of configurations

11. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 11
How configurations are generated
Three main sources of change
• Shifting requirements
Rework previous code
• Bug fixes
Batches from QA sessions
Continuous flow from debugging
• Internal issues, such as:
New vendor/new technology
Performance tuning
Refactoring
Not synchronized to the main development process
• Need for change may occur at any time
• Thus, you need some buffering
Req
flow
Issue
flow
Bug
flow
Develop.
process
Customer
QA

12. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 12
Labeling of configurations
File names are vital
• Orient the developers and customers
• Gets interesting when dealing with 100s of files
… or even 10s of files
Releases
• 2.5: version 2, release 5
• 2.3.5: version 2.3, release 5
Builds
• RN-2002-03-08-16:01:53
• Internal use only
Not in the release file name
CC keeps record of release number

13. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 13
Example: JAR files
Distinguish release candidates sent to customer
• E.g.: do not send multiple System.jar files to customer
Better: FlatCart-Release4.3-…
Include the purpose of the file in an envelope name
E.g.: FlatCart-Release4.3-ForAcceptanceCandidate2.zip
Can use normal release names in the contained files
E.g.: FlatCart4.3.jar (JAR file)
E.g.: FlatCart4.3.exe (self-extracting archive)
In Java 2, JAR files can be annotated with version info
• Version (“specification-version” attribute)
• Release or build (“package-version” attribute)
What if the system includes multiple components with different version &
release numbers?
• The system can have yet another version scheme

14. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 14
Example: branch labeling
[After Bruegge & Dutoit]
revised
revised
Main
revised
Branch
derived
merged
released
MUE.1.1:Releas
MUE.1.2:Releas
MUE.1.3:Releas MUE.1.2.1.1:Releas
MUE.1.2.1.2:Releas
MUE.2.0:Releas

15. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 15
Storage of configurations
Basic operations supported
• Get latest configuration: most frequent
• Insert a new configuration: frequent
• Get previous configurations: on a need-to basis
Rollback (undo changes)
Locate insertion of a defect

16. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 16
Storage of configurations
Reverse delta
• Complete “baseline” version: latest
• Deltas
See diff tool
• Retrieval: compute previous versions from deltas
• E.g. VSS
Storing branches and variants
• A new base can be created for each branch on splitting from trunk
Not many branches sharing won’t save much space
Storing aggregates
• Store cross-references only consistency, space (preferred)
• Store copies of all included components ready access

17. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 17
Item life cycles
Enforcing item life cycles
• Proper state transitions
• E.g. program modules
The system is ready for acceptance testing when all modules are OK
(Next page)
• E.g. triage of new feature requests
Impact analysis: which modules will be affected?
Prioritization, cost estimation
Development, testing
Acceptance

18. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 18
Item life cycles
Passed
Module 1
Private
Ready for
unit test
Baselined
/ released
Done
Failed
Passed
Module 2
Private
Ready for
unit test
Done
Failed
...
System/accepta
nce testing
Passed
Failed

19. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 19
Life cycle control
Objectives
• Facilitate access by developers
• Permit collection of management stats
• Allow easy traceability
Main mechanisms
• Directories
• Item database
• Document logs

20. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 20
Directories
Storage
• One directory for each module state
• State transitions: move among directories
• May use read/write permissions for directories
• Use CM tools for access restrictions in common areas
• Example: Infosys’ WAR project
Enforcement
• Directory read/write privileges

21. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 21
Item database
Storage
• State attributes for each item
• Some tools restrict which users may set which attributes
Enforcement
• Attribute settings

22. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 22
Document logs
Storage
• Use module headers
• Insert date of change, author
• Specify distribution list
Enforcement
• Self-discipline
• Configuration audits
A reason to maintain redundant info...

23. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 23
Dynamic rights
Mutual exclusion of updates
• Check-in/check-out
• Except for deliberate branching/merging

24. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 24
Example: WinCVS
www.wincvs.org
Work areas
• Repository
• Working directory
Check out
• CVS admin → Checkout module
• Specify module and working directory
Check in
• Update the working directory
• Commit to the repository
Related tools
• On-line CVS: www.freepository.org
• CVS
Workspace 1
Workspace 2
Master directory
Software repository
Check-in
Check-out
Baseline

25. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 25
Example: WinCVS

26. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 26
Example: document control
[After Jalote]
States = directories
• Under development
← Initial state
Author: Done → Under review
• Under review
Reviewer: Defects found → Under development
Reviewer: No defects → Baselined
• Baselined
CCB: CR authorized → Under development
Under dev
Under
review
Baselined
[author]
[reviewer]
[reviewer]

27. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 27
Example: document control
Distribution list
Controlled
Proprietary
Limited
Unlimited
Uncontrolled
To be destroyed

28. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 28
Automatic builds
Builds are frequent
• Some processes support daily builds
E.g. McConnell ch. 18
Highly effective schedule reduction
• Other processes support continuous refactoring
XP compensates de-emphasis of global design
Compilation can take a lot of time
• Idea: recompile only the updates
• Careful not to compile the wrong ones
Redundancy is hard to maintain
• Executables are easily created
⇒ executables are not normally controlled
• Hence the term “source control”

29. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 29
Example: the make utility
Make
• A tool that controls generation of executables
• Handles multiple source files
• Recompiles if executable is older than a source
• Looks up change dates
• Not tied to a particular language
• Can even be used to format documents
Makefile
• Tells make how to recompile
• A text file
• Two sections: variables and rules
• Variables come first, but are optional
More info (GNU make)
http://www.gnu.org/software/make/make.html
http://www.gnu.org/manual/make/html_mono/make.html

30. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 30
Makefile rules
E.g. [from GNU]
edith : main.o kbd.o command.o display.o
insert.o search.o files.o utils.o
cc -o edith main.o kbd.o command.o display.o
insert.o search.o files.o utils.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edith main.o kbd.o command.o display.o
insert.o search.o files.o utils.o

31. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 31
Makefile rules
Call
make Program
make
make clean
General format
target: prerequisite1 prerequisite2 ...
<tab> command1
<tab> command2
...
And here's a very useful one:
clean:
rm *.o core ./tmp/*
Deletes all object files in the current directory
any core dump
all files in ./tmp
// Looks up a file named “makefile”

32. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 32
Makefile variables
Example
objects = main.o kbd.o command.o display.o
insert.o search.o files.o utils.o
edith : $(objects)
cc -o edith $(objects)
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean : rm edith $(objects)

33. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 33
Concurrent updates
Branch: concurrent development path requiring independent
configuration management.
Merge: reconcile different branches.
merging
point
UI branch
main trunk
comms
branch

34. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 34
Concurrent updates
Support for change reconciliation
• View changes side-by-side
Decide which changes to adopt
Might be tedious for divergent versions
Supported for text files, not binary (e.g. VSS)
• Merge the most recent changes
Example: Word for windows “Merge Documents”
Tools → Merge Documents → open document
Accept or reject changes
(Tools→Track changes→ ...)

35. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 35
Example: feature interaction
Functionality partitioning
• First release: F1, F2
• Second release: F3, F4
F3 is easy
• M4, M5 can be a separate increment
• Versioning of M4, M5 independent of
M1, M2, M3
F4 needs a separate CM branch
• Create branch: copy M2, M4, M5;
create M6
Do not check out M2, M4, M5 at this
time
Other developers keep working on
M2, M4, M5
• Implement F4
• Reintegrate branch to main build
(trunk)
Check out M2, M4, M5
Use delegated permission
Merge changes
Regression tests of F4
Check in M2, M4, M5
Regression tests of F1, F2, F3
(and F4 to be sure)
• If reintegration fails, one version
is dumped…
M1 M2 M3 M4 M5 M6
F1 X X X
F2 X X
F3 X X
F4 X X X X

36. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 36
Change propagation & traceability
Forward change requests to all related modules
Retrieve reason for each modification
• So the modification can be undone!
Traceability databases
• Propagate changes along dependency relations
E.g. among variants
E.g. from SRS to DD to code to TP
• Dependency matrix
• Dependency tree

37. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 37
Change propagation & traceability
Example: derived modules
• After the current version is deployed
The current version is in a maintenance phase.
Work may begin on a new version.
• If multiple versions are supported
Bug fixes may occur for any supported version
Bug reports, changes, etc. must propagate to the other versions
Keep module derivation relationships across multiple supported system
versions.

38. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 38
The CM plan
CM item structure
• Naming scheme
• Versioning scheme
Release
Baseline
Physical setting
Configuration control process
• Staff responsibilities
Configuration audits

39. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 39
CM item structure
Can be more or less elaborate
• Depends on size of project, usage of artifacts, and change flow
Same idea as in modular design
• Things that are likely to change together should be kept together
• Things that are unlikely to change together should be separate
• The hierarchy of storage should reflect the likelihood of change
Modularity
• Subsystems
Nesting
• E.g. per increment
Overlapping
• E.g. per increment & per artifact type

40. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 40
Example: client-server system
[From B&D]

41. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 41
Responsibilities
Example:
• Configuration controller
Create executables
Baseline code and docs
...
• Developers
Check out, check in at specific times

42. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 42
Configuration auditing
Danger: state related mistakes
• E.g. move a non-tested module into the release directory
Use several mechanism for life-cycle support
• E.g.: directory structure + “master table”
• E.g.: directory structure + revision lists in module headers
Status monitoring
• Consistency of the redundant state mechanisms
E.g. directory placement same as master table entry
• Consistency of the revision list with the artifact life cycle
Audits
• Check whether proper process is being followed
• Check the baseline and release states

43. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 43
Change control board
The change control board (CCB)
• Analyze changes
• “Triage” changes
• Bundle changes
Representatives from each party
• Development, QA, user documentation
Artifacts owners
• Customer support, marketing, mgmt
Danger: go overboard...

44. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 44
CASE example: the Rational Suite
The full Rational Enterprise Suite is installed in our lab.
Team integration tools
• RequisitePro: organize, prioritize, track, control requirements
• ClearQuest: manage every type of change
Implements artifact lifecycle
Talks to a database
• SoDA: automated documentation
Extracts info and puts it in a Word template

45. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 45
Development
• Rose: draw UML diagrams
Checks consistency
Implements code frameworks from the diagram: it writes class and method
declarations and some docs, and you fill in the body of the methods
• Purify: run-time errors and memory leaks
Needed big time in C/C++
Theoretically, not needed in Java (JVM-managed garbage collection)
Practically, Java programs can exhibit object pool overflows, JVM
malfunctions, heap reallocations, etc. -> need memory leak tools
• Visual PureCoverage: expose testing gaps
It instruments the code to register execution
• Visual Quantify:
Profiles the application to check performance bottlenecks

46. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 46
CASE example: the Rational Suite
Quality assurance
• Robot: record and playback test scripts
Point-and-click operations are saved into a script
Graphical object capture
Verification points: test only certain properties of certain objects. This allows
changes in the UI design without changing all the test cases
The scripting language is called SQA-Basic, and it is very similar to VB
except for a couple of statements. See if you can run SQA-Basic scripts in
VB
• TestFactory
Automatic test generation:
“Best test”: a random run through the code that works out as much of it as
possible
Source code coverage analysis: what code was exercised by the test cases

47. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 47
CASE example: the Rational Suite
Integration among these tools
• Rational Administrator
Integration with other tools
• MS Project: activities can be linked to requirements in the
RequisitePro database
• MS Office: many of the Rational tools use Access for a RDBMS, and
Word for their documentation interface
• MS VisualStudio: VB, VC++, ...
• Java

48. McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 48
Discussion
Thank you!
Any questions?