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

Configuration Management

CIS 376

Bruce R. Maxim

UM-Dearborn

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

Software Configuration Items

• Computer programs– both source and executable

• Documentation– both technical and user

• Data– within a program or external to it

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

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

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.

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

Software Configuration Objectspart 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

Software Configuration Objectspart 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

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

Change Control - part 1

• Change request– 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

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

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

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

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

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

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

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)

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?

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 e-mail systems to allow electronic distributions of change requests

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

Version Terminology

• Version– 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

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

Version Numbering Derivation Structurefrom Sommerville

V1.0 V1.1 V1.2 V2.0 V2.1 V2.2

V1.1b V1.1.1

V1.1a

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

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

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

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?