1. Configuration Management

2. Maintenance is Inevitable
System requirements are likely to change while the system is being developed because their environment is changing
Systems are tightly coupled to their environment
When a system is installed it changes the environment and that can change the system requirements
The delivered system may not meet its requirements
Systems must be maintained to remain useful in their environment

3. Types of Maintenance Corrective Maintenance (21%)
making changes to repair defects
Adaptive Maintenance (25%)
making changes to adapt software to external environment changes (hardware, business rules, OS, etc.)
Perfective Maintenance (50%)
extending system beyond its original functional requirements
Preventative Maintenance (4%)
modifying work products so that they are more easily corrected, adapted, or enhanced

4. Spiral Maintenance Model

5. Maintenance Costs
Usually greater than the development costs (2 to 10 times as much in some cases)
Affected by both technical and non-technical factors
Increase as software is maintained and system corruption is introduced
Aging software can have high support costs (e.g. old languages, compilers, etc.)

6. Maintenance Developer Tasks
Understand system.
Locate information in documentation.
Keep system documentation up to date.
Extend existing functions.
Add new functions.
Find sources of errors.
Correct system errors.
Answer operations questions.
Restructure design and code.
Delete obsolete design and code.
Manage changes.

7. Maintenance can be tough
Limited understanding of hardware and software (maintainer).
Management priorities (maintenance may be low priority).
Technical problems.
Testing difficulties (finding problems).
Morale problems (maintenance is boring).
Compromise (decision making problems).

8. Maintenance Cost Factors
Staff turnover
no turnover usually means lower maintenance costs
Contractual responsibility
developers may have no contractual obligation to maintain the delivered system and no incentive to design for future change
Staff skills
maintenance staff are often inexperienced and have limited domain knowledge
Program age and structure
as programs age their structure deteriorates, they become harder to understand and change

9. Maintenance Prediction
Concerned with determining which parts of the system may cause problems and have high maintenance costs
Change acceptance depends on the maintainability of the components affected by the change
Implementing changes degrade system and reduces its maintainability
Maintenance costs depends on number of changes
Costs of change depend on maintainability

10. Maintenance Prediction

11. Maintenance Complexity Metrics
Predictions of maintainability can be made by assessing component complexities
Most maintenance efforts only affect a small number of system components
Maintenance complexity depends on
complexity of control structures
complexity of data structures
module size

12. Maintenance Process Metrics
Maintainability measurements
number of requests for corrective maintenance
average time required for impact analysis
average time to implement a change request
number of outstanding change requests
If any of these increases it may signal a decline in maintainability

13. Maintenance Tools Text editors (better than punch cards).
File comparison tools.
Compilers and linkage editors.
Debugging tools.
Cross reference generators.
Complexity calculators.
Control Libraries.
Full life cycle CASE tools.

14. Configuration Management
Software changes are inevitable
One goal of software engineering is to improve how easy it is to change software
Configuration management is all about change control.
Every software engineer has to be concerned with how changes made to work products are tracked and propagated throughout a project.
To ensure quality is maintained the change process must be audited.

15. Software Configuration Items
Computer programs
source
executable
Documentation
technical
user
Data
contained within the program
external data (e.g. files and databases)

16. Baselines
A work product becomes a baseline only after it is reviewed and approved.
A baseline is a milestone in software development marked by the delivery of one or more configuration items.
Once a baseline is established each change request must be evaluated and verified before it is processed.

17. Sources of Change
New market conditions dictate changes to product requirements or business rules
New customer needs demand modification of data, functionality, or services
Business reorganization causes changes in project priorities or SE team structure
Budgetary or scheduling constraints require system to be redefined

18. Change Requests Requests can come from
users,
customers, or
management
Change requests should be carefully analyzed as part of the maintenance process before they are implemented
Some changes requests must be implemented urgently due to their nature
fault repair
system environment changes
urgently required business changes

19. Change Prediction Predicting the number of changes requires
understanding the relationships between a system and its environment
Tightly coupled systems require changes whenever the environment changes
Factors influencing the system/environment relationship
number and complexity of system interfaces
number and volatility of system requirements
business processes where the system is used

20. What is Configuration Management
CM is a key process in Capability Maturity Model (recently updated to CMMI)
Level 1-Initial: ad hoc/chaotic
Level 2-Repeatable: basic project management and documentation
Level 3-Defined: standard and complete process control and procedures
Level 4-Managed: predictable process performance and precise measurements
Level 5-Optimizing: continuous and recursive improvement to performance
CM operates through the software life cycle

21. What is CM not Not just version control
Not just for source code management
Not only for development phase
Selecting and using tools are important, but design and management of CM process are more crucial for project success

22. Some Simple CM Scenarios
Developer A wants to see latest version of foo.c and its change history since last week
B needs to revert foo-design.doc to its version two days ago
B makes a release of the project and he needs to know what items to include and which version

23. Some Simple CM Scenarios (cont.)
A lives in New Delhi, India and B lives in Boston, US, they want to work on HelloWorld.java together
In the latest release, a serious bug is found and manager C wants to track
what changes caused the bug,
who made those changes and
when
C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release

24. SCM Terminology Configuration Item (CI) Version, Variant, and Revision
Baseline
Workspace

25. Configuration Item (CI)
An approved and accepted deliverable, changes have to be made through formal procedure
Examples:
Management plan
Requirement
Design specification
Source code and executable code
Test specification, data, and records
Log information
User documentation
Library and supporting software
Bug reports, etc.

26. Version, Variant, and Revision
Version: a CI at one point in its development, includes revision and variant
Revision: a CI linked to another via revision-of relationship, and ordered in time
Variant: functionally equivalent versions, but designed for different settings, e.g. hardware and software
Branch: a sequence of versions in the time line
1.2
1.3
1.4
Win32 on x86
Solaris on SPARC
1.2
1.3
1.4

27. How Versions are Stored
Full copy of each version
Delta (differences between two versions)
Forward delta
Reverse delta
Mixed delta
1.1
1.2
1.3
1.4
1.1
1.2
1.3
1.4

28. Configuration An arrangement of functional CIs according to their
nature,
version and
other characteristics
Guaranteed to recreate configurations with quality and functional assurance
Sometimes, configuration needs to record environment details,
e.g. compiler version, library version, hardware platform, etc.
Simple examples
Ant buildfile, Makefile

29. Baseline
A collection of item versions that have been formally reviewed and agreed on, a version of configuration
Marks milestones and serves as basis for further development
Can only be changed via formal change management process
Baseline + change sets to create new baselines

30. Workspace
An isolated environment where a developer can work (edit, change, compile, test) without interfering other developers
Examples
Local directory under version control
Private workspace on the server
Common Operations
Import: put resources into version control in repository
Update: get latest version on the default branch
Checkout: get a version into workspace
Checkin: commit changes to the repository

31. Version Control Models (1/3)
Basic problem of collaborative work
Figure from svn-book

32. Version Control Models (2/3)
Model 1-Pessimistic: lock-modify-unlock
Problems:
Forget to unlock
Parallel work not possible
Deadlock
Figure from svn-book

33. Version Control Models (3/3)
Model 2-Optimistic: copy-modify-merge
Figure from svn-book

34. SCM Processes Change control process Status accounting
Configuration audit
Release management
CM planning

35. Change Control Process
Submission of Change Request (CR)
Technical and business evaluation and impact analysis
Approval by Change Control Board (CCB)
Engineering Change Order (ECO) is generated stating
changes to be made
criteria for reviewing the changed CI
CI’s checked out
Changes made and reviewed
CI’s checked in

36. Status Accounting
Administrative tracking and reporting of CIs in CM system
Examples
Status of proposed changes
Status of approved changes
Progress of current version, on or behind schedule
Estimate of resources to finish one task
bugs identified by configuration audit

37. Configuration Audit
Independent review or examination to assess if a product or process is in compliance with specification, standards, contractual agreement, or other criteria
Examples
Verifies that CIs are tested to satisfy functional requirements
Verifies that baseline contains necessary and correct CI versions
Ensures that changes made to a baseline comply with the configuration status reports

38. The change management process
Change Request Form
Project: SICSA/AppProcessing Number: 23/02
Change requester: I. Sommerville Date: 20/01/09
Requested change: The status of applicants (rejected, accepted, etc.) should be shown visually in the displayed list of applicants.
6:01 AM
Chapter 25 Configuration management

39. A partially completed change request form (a)
Project: SICSA/AppProcessing Number: 23/02
Change requester: I. Sommerville Date: 20/01/09
Requested change: The status of applicants (rejected, accepted, etc.) should be shown visually in the displayed list of applicants.
Change analyzer: R. Looek Analysis date: 25/01/09
Components affected: ApplicantListDisplay, StatusUpdater
Associated components: StudentDatabase
6:01 AM
Chapter 25 Configuration management

40. A partially completed change request form (b)
Change assessment: Relatively simple to implement by changing the display color according to status. A table must be added to relate status to colors. No changes to associated components are required.
Change priority: Medium
Change implementation:
Estimated effort: 2 hours
Date to SGA app. team: 28/01/09 CCB decision date: 30/01/09
Decision: Accept change. Change to be implemented in Release 1.2
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments:
6:01 AM
Chapter 25 Configuration management

41. Release Management
Creation and availability of a new version of software to the public
Release format
Source code + build script + instructions
Executables packaged for specific platforms
Other portable formats: Java Web Start, plugins
Patches and updates: automatic, manual
Release content
Source and/or binary, data files, installation scripts, libraries, user and/or developer documentation, feedback programs, etc.

42. Chapter 25 Configuration management
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.
6:01 AM
Chapter 25 Configuration management

43. Chapter 25 Configuration management
Release tracking
In the event of a problem, it may be necessary to reproduce exactly the software that has been delivered to a particular customer.
When a system release is produced, it must be documented to ensure that it can be re-created exactly in the future.
This is particularly important for customized, long-lifetime embedded systems, such as those that control complex machines.
Customers may use a single release of these systems for many years and may require specific changes to a particular software system long after its original release date.
6:01 AM
Chapter 25 Configuration management

44. Chapter 25 Configuration management
Release reproduction
To document a release, you have to record the specific versions of the source code components that were used to create the executable code.
You must keep copies of the source code files, corresponding executables and all data and configuration files.
You should also record the versions of the operating system, libraries, compilers and other tools used to build the software.
6:01 AM
Chapter 25 Configuration management

45. Chapter 25 Configuration management
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.
6:01 AM
Chapter 25 Configuration management

46. Chapter 25 Configuration management
Release components
As well as the the executable code of the system, a release may also include:
configuration files defining how the release should be configured for particular installations;
data files, such as files of error messages, that are needed for successful system operation;
an installation program that is used to help install the system on target hardware;
electronic and paper documentation describing the system;
packaging and associated publicity that have been designed for that release.
6:01 AM
Chapter 25 Configuration management

47. Factors influencing system release planning
Description
Technical quality of the system
If serious system faults are reported which affect the way in which many customers use the system, it may be necessary to issue a fault repair release. Minor system faults may be repaired by issuing patches (usually distributed over the Internet) that can be applied to the current release of the system.
Platform changes
You may have to create a new release of a software application when a new version of the operating system platform is released.
Lehman’s fifth law (see Chapter 9)
This ‘law’ suggests that if you add a lot of new functionality to a system; you will also introduce bugs that will limit the amount of functionality that may be included in the next release. Therefore, a system release with significant new functionality may have to be followed by a release that focuses on repairing problems and improving performance.
6:01 AM
Chapter 25 Configuration management

48. Factors influencing system release planning
Description
Competition
For mass-market software, a new system release may be necessary because a competing product has introduced new features and market share may be lost if these are not provided to existing customers.
Marketing requirements
The marketing department of an organization may have made a commitment for releases to be available at a particular date.
Customer change proposals
For custom systems, customers may have made and paid for a specific set of system change proposals, and they expect a system release as soon as these have been implemented.
6:01 AM
Chapter 25 Configuration management

49. Make a CM Plan Standards CM plan components
IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc.
CM plan components
What will be managed (list and organize CIs)
Who will be responsible for what activities (roles and tasks)
How to make it happen (design processes for change requests, task dispatching, monitoring, testing, release, etc.)
What records to keep (logs, notes, configurations, changes, etc.)
What resources and how many (tools, money, manpower, etc.)
What metrics to measure progress and success

50. CM Tools Version control Bug tracking Build Project management
RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase
Bug tracking
Bugzilla, Mantis Bugtracker, Rational ClearQuest
Build
GNU Make and many variants, Ant
Project management
Sourceforge.net, freshmeat.net, GForge, DForge

51. Configuration Management Tasks
Identification
tracking changes to multiple SCI versions
Version control
controlling changes before and after customer release
Change control
authority to approve and prioritize changes
Configuration auditing
ensure changes are made properly
Reporting
tell others about changes made

52. Version Control Terms Entity Variant New version
composed of objects at the same revision level
Variant
a different set of objects at the same revision level and coexists with other variants
New version
defined when major changes have been made to one or more objects

53. Version identification
Procedures for version identification should define an unambiguous way of identifying component versions.
There are three basic techniques for component identification
Version numbering;
Attribute-based identification;
Change-oriented identification.

54. Version numbering Simple naming scheme uses a linear derivation
V1, V1.1, V1.2, V2.1, V2.2 etc.
The actual derivation structure is a tree or a network rather than a sequence.
Names are not meaningful.
A hierarchical naming scheme leads to fewer errors in version identification.

55. Version derivation structure

56. 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 etc.
This is more flexible than an explicit naming scheme for version retrieval; However, it can cause problems with uniqueness - the set of attributes have to be chosen so that all versions can be uniquely identified.
In practice, a version also needs an associated name for easy reference.

57. Attribute-based queries
An important advantage of attribute-based identification is that it can support queries so that you can find ‘the most recent version in Java’ etc.
The query selects a version depending on attribute values
AC3D (language =Java, platform = XP, date = Jan 2003).

58. Change-oriented identification
Integrates versions and the changes made to create these versions.
Used for systems rather than components.
Each proposed change has a change set that describes changes made to implement that change.
Change sets are applied in sequence so that, in principle, a version of the system that incorporates an arbitrary set of changes may be created.

59. Change Control Process - 1
Change request is submitted and evaluated to assess its technical merit and impact on the other configuration objects and budget
Change report containing the results of the evaluation is generated
Change control authority (CCA) makes the final decision on the status and priority of the change based on the change report

60. Change Control Process - 2
Engineering change order (ECO) is generated for each change approved
ECO describes the change, lists the constraints, and criteria for review and audit
Object to be changed is checked-out of the project database subject to access control parameters for the object
Modified object is subjected to appropriate SQA and testing procedures

61. Change Control Process - 3
Modified object is checked-in to the project database and version control mechanisms are used to create the next version of the software
Synchronization control is used to ensure that parallel changes made by different people don’t overwrite one another

62. Configuration Management Team
Analysts.
Programmers.
Program Librarian.

63. Change Control Board
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.
The CCB may include representatives from client and contractor staff.
Customer representatives.
Some members of the Configuration management team.

64. Programmer’s View - 1 Problem is discovered.
Problem is reported to configuration control board.
The board discusses the problem
is the problem a failure?
is it an enhancement?
who should pay for it?
Assign the problem a priority or severity level, and assign staff to fix it.

65. Programmer’s View - 2 Programmer or analyst
locates the source of the problem
determines what is needed to fix it
Programmer works with the librarian to control the installation of the changes in the operational system and the documentation.
Programmer files a change report documenting all changes made.

66. Change Control Issues Synchronization (when?) Identification (who?)
Naming (what?)
Authentication (done correctly?)
Authorization (who O.K.’d it?)
Routing (who’s informed?)
Cancellation (who can stop it?)
Delegation (responsibility issue)
Valuation (priority issue)

67. Software Configuration Audit - 1
Has the change specified by the ECO been made without modifications?
Has an FTR been conducted to assess technical correctness?
Was the software process followed and software engineering standards applied?
Engineering change order
formal technical review

68. Software Configuration Audit - 2
Do the attributes of the configuration object reflect the change?
Have the SCM standards for recording and reporting the change been followed?
Were all related SCI's properly updated?

69. Configuration Status Report
What happened?
Who did it?
When did it happen?
What else will be affected by the change?
Reference
Introduction to Configuration Management, lecture slides for COMP3100/3500, Ian Barnes, the Australian National University.
Software Configuration Management, Center for Development of Advanced Computing, Mumbai at Juhu, India.
Concepts in Configuration Management Systems, Susan Dart, CMU.
Software Configuration Management: A Roadmap, Jacky Estublier, CNRS, France.
Further Reading
Software Engineering, a Practitioner’s Approach (6th), part 4, Roger Pressman.
Code Complete (2nd), Steve McConnel.
Implementing and Integrating PDM and SCM, Ivica Crnkovic et al.
Version Control with Subversion, Ben Collins-Sussman et al.