1. Configuration Management
CIS 376
Bruce R. Maxim
UM-Dearborn

2. Configuration Management
New versions of software systems are created as they change
Configuration management is concerned with managing evolving systems
Involves the development of procedures and standards to manage product evolution
May be viewed as part of a more general quality management process

3. Software Configuration Items
Computer programs
both source and executable
Documentation
both technical and user
Data
within a program or external to it

4. Fundamental Sources of Change
New business or market conditions
dictate changes to SW requirements or business rules
New customer needs
demand modification of data, functionality, or services
Business reorganization
causes changes in project priorities or software engineering team structure
Budgetary or scheduling constraints
cause system to be redefined

5. Configuration Management Standards
CM should always be based on a set of standards which are applied within an organization
Should define how
items are identified
changes are controlled
versions are managed
Should be based on an evolutionary process model rather than something like the waterfall model

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

7. Software Configuration Management Tasks
Identification
tracking multiple versions to enable efficient changes
Version control
control changes before and after release to customer
Change control
authority to approve and prioritize changes
Configuration auditing
ensure changes made properly
Reporting
tell others about changes made

8. Software Configuration Objects part 1
To control and manage configuration items
each must be named
should be managed using an object-oriented approach
Basic objects
created by software engineers during analysis, design, coding, or testing
Aggregate objects
collections of basic objects and other aggregate objects

9. Software Configuration Objects part 2
Configuration object attributes
unique name
description
list of resources
realization (a pointer to a work product for a basic object or null for an aggregate object)
An entity-relationship (E-R) diagram
can be used to show the interrelationships among the objects

10. Version Control
Combines procedures and tools to manage the different versions of configuration objects created during the software process
An entity is composed of objects at the same revision level
A variant is a different set of objects at the same revision level and coexists with other variants
A new version is defined when major changes have been made to one or more objects

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

12. Change Control - part 2 Engineering change order (ECO)
generated for each change approved (describes 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

13. Change Control - part 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
used to ensure that parallel changes made by different people don’t overwrite one another

14. Concurrent Development and Testing
Delivery time is agreed upon for system components
New system version is built from these components
The new version is delivered for testing using predefined tests
Detected faults are documented and returned to system developers

15. Daily System Builds
Allows early detection of component interaction problems
Encourages developers to do thorough unit testing
Developers are under pressure not to “break the build”
Requires the use of a strict management process to track problems that are discovered and repaired

16. Configuration Management Planning
All products of the software process (including documents) may have to be managed
Must start early in project life cycle
Must define formal documents to be managed
Documents which are likely to be used for future system maintenance work should be identified and specified as managed documents

17. Configuration Management Plan
Defines the documents to be managed
Defines who take responsibility for the configuration management procedures and creation of baselines
Defines policies for change control and version management
Defines configuration records to be maintained
Describes the tools that should be used

18. Configuration Database
All configuration management information should be maintained in a configuration database
The database should allow queries like
Who has a particular software version?
What platform is required for a particular version?
What versions are affected by component X changes?
How many reported faults for version Y?
The database should be linked to software being managed (e.g. use of CASE tools)

19. Software Configuration Audit Questions
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?
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?

20. Change Tracking Tools
Major problem in change management is tracking the change status
Change tracking tools help track the status of each change request
Ensures that change requests are sent to the right people at the right time
Can be integrated with systems to allow electronic distributions of change requests

21. Derivation History
Records changes applied to a document or code component
Should record
change made
rationale for change
who made the change?
when was change implemented?
May be included as comment in the code

22. Version Terminology Version Variant Release
instance of system that is functionally distinct from other system instances
Variant
instance of system that is functionally identical but non-functionally distinct from other system instances
Release
system instance distributed to users outside the development team

23. Version and Release Management
Invent identification scheme for system versions
version numbering
attribute-based identification
change-oriented identifications
Plan when new release is to be produced
Ensure that version management procedures and tools are applied properly

24. Version Numbering Derivation Structure from Sommerville

25. Attribute-Based Identification
Attributes can be associated with a version
Date
Creator
Programming Language
Customer
Status
More flexible than explicit name for version retrieval (esp. database queries)
Can cause uniqueness problems
Needs an associated name for easy reference

26. Change-Oriented Management
Integrates versions and the changes made to create each version
Used for systems rather than components
Each version has change set that describes the changes used to implement the version
Change sets are applied in sequence so that system versions can be composed by incorporating arbitrary combinations of changes

27. System Releases Not just a set of executable programs May also include
configuration files used to define system required for a particular installation
data files needed for system operation
installation shields or shells for specific platforms
electronic and paper documentation
packaging and publicity information

28. System Building Problems
Do the build instructions include all required components?
Is the appropriate version specified for each build component?
Are all data files available?
Are data file references within components correct?
Is system being built for the right platform?
Is the correct versions of the compiler and other tools specified?