Software configuration management
1 / 52

Software Configuration Management - PowerPoint PPT Presentation

  • Uploaded on

Software Configuration Management. Sudipto Ghosh CS 406 Fall 99 October 26, 1999 Revised: Aditya Mathur Fall 2001. Learning objectives. What are versions, releases, variations? What is version control? What is configuration management? Need for configuration management

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Software Configuration Management' - sandro

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software configuration management

Software Configuration Management

Sudipto Ghosh

CS 406 Fall 99

October 26, 1999

Revised: Aditya Mathur

Fall 2001

Learning objectives
Learning objectives

  • What are versions, releases, variations?

  • What is version control?

  • What is configuration management?

  • Need for configuration management

  • Steps in configuration management

  • Configuration management tools

CS 406 Testing

Software versions
Software versions

  • Consider the maintenance phase

    • at least two versions exist

      • old

      • new

    • product consists of modules, so

      • 2 or more versions of component modules

  • Version control also applies to other phases – Why?

CS 406 Testing

Revisions and variations



Printer driver for PC

Driver for

Ink-jet printer

Version n+1


Revisions and Variations

Version n

(with fault)

Driver for

Laser printer

CS 406 Testing

Revisions why
Revisions - why?

  • Corrective maintenance

    • fix faults

  • Perfective maintenance

    • write new modules

    • change existing modules

  • Adaptive maintenance

    • change modules

CS 406 Testing

Problem with revisions
Problem with revisions

  • Multiple versions of the same module

  • New version should replace the old one

  • Simple solution:

    • Just throw the old version away!!!

  • Will this work?

CS 406 Testing

Why should we keep versions
Why should we keep versions?

  • Revision n+1 is not necessarily more correct than revision n

  • Is everyone using revision n+1?

    • Not necessarily

    • What if a site using revision n sends a fault report?

  • We need to maintain all the revisions for all kinds of maintenance.

  • Actually, all versions from the implementation phase need to be kept.

CS 406 Testing


  • A variation does not replace another

  • Variations co-exist

  • Examples:

    • Two printer drivers - laser, ink-jet for a PC supporting both laser and ink-jet printers

    • Same product ported to a variety of:

      • operating systems

      • hardware

  • Multiple revisions of each variation may exist

CS 406 Testing

Configuration management
Configuration management

  • Multiple versions have to be managed

  • Need a CASE tool for configuration control

  • Many tools available commercially

CS 406 Testing

Forms of code
Forms of code

  • Source code

  • Object code

  • Executable load image

Run-time routine

Executable load image

Object File 1

Object File 2

Object File n

• • •

• • •

Source File 1

Source File 2

Source File n

CS 406 Testing

Scenario 1
Scenario 1

  • Report from SQA: module failed on a specific set of data

  • How does the programmer determine which revision of which variation went into the version?

    • Bad method

      • Compile all versions and compare object code with the object code that went into the executable

    • Good method

      • Use version control

CS 406 Testing

Version control for revisions
Version control for revisions

  • Operating system may provide version control

  • Otherwise, use a separate tool

  • Maintain file name as

    • The file name itself

    • Revision number

  • Module that acknowledges receipt of message will have revisions:

    • acknowledgeMessage / 1

    • acknowledgeMessage / 2

CS 406 Testing

Multiple revisions
Multiple revisions

acknowledgeMessage / 1

acknowledgeMessage / 2

acknowledgeMessage / 3

acknowledgeMessage / 4


CS 406 Testing

Version control for variations
Version control for variations

  • Notation

    • Have a basic file name

    • Followed by a variation name in parenthesis

  • Printer driver for inkjet and laser

    • printerDriver (inkjet)

    • printerDriver (laser)

  • Multiple versions of each variation

    • printerDriver (laser) / 12

    • printerDriver (laser) / 13

    • printerDriver (inkjet) / 2

CS 406 Testing

Version control for variations1
Version control for variations


(inkjet) / 2

printerDriver (laser) / 12

printerDriver (laser) / 13

printerDriver (laser) / 14

CS 406 Testing

Managing multiple versions
Managing multiple versions

  • Use a version control tool

  • Keep a detailed record or derivation of every version of the product

  • Derivation contains:

    • Name of each source code element, including the variation and revision

    • Versions of source code compilers and linker

    • Name of person who constructed the product

    • Data and time of construction

CS 406 Testing

Is maintaining multiple revisions enough
Is maintaining multiple revisions enough?

  • No

  • Problems with maintaining variations

    • Often a fault occurs in a variation and may have to be fixed for all the variations, in the same way.

  • Just store one variation, printDriver(inkjet)

  • Other variations are stored in terms of the list of changes to be applied to the original to get that variation – delta

  • For n variations, store

    • one variation

    • n-1 deltas

  • Can there be problems with deltas?

CS 406 Testing

Problem with deltas
Problem with deltas

  • What if the main version is lost or corrupted?

  • More important:

    • Sometimes it is difficult to express each variation as a transformation from the main version

  • What about conditional compilation as an alternative to deltas?

CS 406 Testing

More on configuration control
More on configuration control

  • Configuration control can automatically manage different variations and do a lot more.

    • Handle problems caused by

      • Development and

      • Maintenance by teams

CS 406 Testing

Configuration control during maintenance
Configuration control during maintenance

  • Suppose 2 programmers, P1 and P2, are assigned 2 different fault reports.

  • Both faults localized to the same module.

  • Each programmer makes a copy of the module mMod / 16 and starts fixing the fault

  • P1 fixes the fault first and replaces the module with mMod / 17.

  • Then P2 fixes the fault and installs mMod / 18

CS 406 Testing

Problems in previous example
Problems in previous example

  • All changes made by the first programmer are lost!

  • Only one user should be allowed to change a module at a time

CS 406 Testing

Formal definition ieee
Formal definition (IEEE)

SCM is the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests and verifying the completeness and correctness of the items.

CS 406 Testing

Configuration management1
Configuration management

  • Pfleeger:

    • It is used throughout the life cycle

    • It is a set of procedures that track

      • Requirements that define what the system should do

      • Design modules that are generated from the requirements

      • Program code that implements the design

      • Tests that verify the functionality of the system

      • Documents that describe the system

    • Provides threads that tie parts of system together

    • Coordinate development activities

CS 406 Testing

Configuration management2
Configuration Management








Control /






CS 406 Testing

Configuration management terms
Configuration management terms

  • Configuration:

    • Functional and Physical characteristics of hardware and software as set forth in technical documentation or achieved in a product

  • Configuration Identification:

    • Define the product and its configuration documentation identification

  • Configuration Item

  • Change management:

    • Control changes to a product and its configuration documentation

CS 406 Testing

Configuration management terms1
Configuration management terms

  • Configuration Status Accounting:

    • Provide status and information about a product and its configuration documentation

  • Configuration Audits:

    • Verify consistency of configuration

CS 406 Testing

Configuration identification
Configuration identification

  • Agree on a basis for change

    • i.e. to what are changes applied?

  • Requires that baselines are established

  • Baselines can be defined for many phases

    • Functional or requirements baseline

    • Design baseline

    • Product or system baseline

  • Makes sense to establish baseline when product is relatively stable

CS 406 Testing

Configuration identification1
Configuration identification

  • The current version is “frozen”

  • No one may make changes to the frozen version.

  • A baseline can consist of many Software Configuration Items (SCI)

    • Documents or artifacts that is explicitly placed under configuration control

    • Regarded as a basic unit of modification

CS 406 Testing

Configuration identification contd
Configuration identification (contd)

  • How do you get a consistent system from the SCI’s?

    • when SCI’s may be getting changed

    • when there are many versions

  • Makefiles may be used

CS 406 Testing

Identification of sci
Identification of SCI

  • Requirements SCI - requirements document or chapters / paragraphs of document.

  • Design SCI - usually design document

  • Code level - multiple SCI’s

    • Each separately compileable module

    • Each file consisting of modules

CS 406 Testing

Dependencies of sci s
Dependencies of SCI’s

  • One SCI X may “depend” on another SCI Y, if a change in Y might require a change in X for X to remain correct or for baselines to be consistent.

  • Change request may require changes to some other SCIs.

CS 406 Testing

Maintaining modules
Maintaining modules

  • One version is frozen as the baseline.

  • Programmer takes a copy, makes changes and tests.

  • The new version is installed, thereby modifying the baseline.

  • The previous version is not altered, but is still retained.

  • How does this fix the problem of two programmers trying to work on fixing two faults?

CS 406 Testing

Change control
Change control

  • SCI’s have been identified and dependencies are understood.

  • Decisions regarding change are taken by the configuration control board (CCB)

  • If an SCI is under development and not visible to other SCI’s, it is in the working state.

  • That SCI is not under SCM and can be changed.

CS 406 Testing

Change control contd
Change control (contd.)

  • If SCI is considered stable enough, it is given to the CCB to review.

  • It is considered as frozen and any changes made privately by the developer are not recognized.

  • It is entered in a library, after which it is formally under SCM.

  • Once in the library, it cannot be modified by anyone without permission of CCB.

CS 406 Testing

Change request cr
Change request (CR)

  • Reasons for a change:

    • requirement changes, bugs, enhancements…

  • What does the CR contain?

    • First part

      • Description

      • Reason for change

      • Priority of the change

      • The SCI’s that are affected

    • Second part (filled by CCB):

      • Decision taken by the CCB (approved/not)

      • Actions needed to implement the change

CS 406 Testing

Change request contd
Change request (contd.)

  • What does it contain?

    • Third part (filled by the implementer):

      • Status of change implementation

      • Change log to facilitate undoing of the change

  • CR has a unique number for reference

  • Evaluation of CR by considering

    • Effect of change on cost, schedule

    • Quality of project

    • Benefits

    • Evaluation may be recorded on the CR itself

CS 406 Testing

Fault report fr
Fault report (FR)

  • Common reason for a CR is the discovery of a bug or a problem

  • These are frequently on a different kind of form (FR) - High priority CR

  • Assigned unique ID

  • FR also tracks the status of known bugs

    • Description of the fault

    • Severity of the fault

    • Item suspected of being faulty

    • Effect of the fault

CS 406 Testing

Fault report contd
Fault report (contd.)

  • FR also contains:

    • Circumstances and environment data that caused the fault to manifest itself

    • Possible fixes

    • Originator

    • Comments from CCB

      • Approved/reject

      • Priority

    • Fault fixing information

      • Items changed

CS 406 Testing

Status accounting
Status accounting

  • Incorporating changes takes time.

  • Mechanisms are required to record the current status of a change request or fault report.

  • Answer questions like:

    • What is the status of CR? Approved or not

    • What is the frequency of CR’s?

    • What is the average time and effort for fixing a CR?

    • What is the number of CRs per SCI?

CS 406 Testing

Status accounting contd
Status accounting (contd.)

  • Source of information

    • CR and FR

    • Both CR and FR have fields to show the status

    • Information about dates and efforts can be added to the CR’s and FR

CS 406 Testing


  • Objective:

    • Determine if the specified process is being followed and whether the specified process satisfies the goals of the process

  • Past changes are evaluated by the auditor to determine if SCM procedures are followed.

  • Procedures are evaluated to ensure that SCM goals are met

CS 406 Testing

Auditing contd
Auditing (contd)

  • While performing SCM, enough information has to be recorded such that an SCM audit can be performed.

  • Auditing is done periodically.

    • Period may be small in the beginning

    • Increases later after processes are well established and institutionalized.

  • Auditors are different from those implementing the process.

CS 406 Testing

Configuration management team
Configuration management team

  • Maintain a correspondence among the requirements, design, implementation and tests.

  • Tells what changes to make in something when something else changes.

  • Coordinate between variations of the system, so that functionality is consistent.

CS 406 Testing

Things the team should know
Things the team should know

  • Synchronization: When was it changed?

  • Identification: Who made the change?

  • Naming: What components were changed

  • Authentication: Was the change made correctly?

  • Authorization: Who authorized the change?

  • Routing: Who was notified of the change?

  • Cancellation: Who can cancel the request for change?

  • Delegation: Who is responsible for the change?

  • Valuation: What is the priority of the change?

CS 406 Testing

Case tools for scm
CASE tools for SCM

  • Unix version control

    • SCCS (Source code control system)

    • RCS (Revision control system)

    • CVS (Concurrent versions system)

  • Configuration control tools

    • CCC

    • PVCS

    • Aide-de-Camp

    • Microsoft Source Safe

    • ClearCase

CS 406 Testing

Build tools
Build Tools

  • Suppose that you don’t want to have a full configuration tool.

  • You should at least have a Build tool with a version control tool.

  • Build tool assists in selecting the correct version of object-code module to be linked to form a specific version of the product.

  • Usually version control tools do not attach revision numbers to object versions.

CS 406 Testing

Unix make
Unix make

  • Avoid unnecessary compilations

  • Use Unix make

  • Create Makefile specifying the hierarchy of source and object files.

  • Complex dependencies can be handled by make.

  • Timestamps of source file and object file compared.

  • Task of building object file simplified.

CS 406 Testing

Rational clearcase
Rational ClearCase

  • Meets the challenge of team-based software development

  • Provides

    • Version control

    • Workspace management

    • Build management

    • Process control

CS 406 Testing

Features of clearcase
Features of ClearCase

  • Acceleration of development process

  • Accuracy of releases

  • No need to change environment or tools

  • Powerful graphical merge tools

    • Automatically merge up to 32 contributors

    • Additive and subtractive merging

    • Editable synchronized windows

  • Transparent workspace management

    • No need to leave the native Windows or UNIX development environment

CS 406 Testing

Features of clearcase contd
Features of ClearCase (contd.)

  • Powerful version control

    • Not just source code control

    • Every object in the s/w development lifecycle

      • Tracks changes to files, directories

      • Annotated histories of source, binaries, executables, documentations, test suites, libraries, user-defined objects

      • Allows identification and roll-back to earlier versions.

      • Check-in/check-out model

      • Interleaved delta compression

CS 406 Testing

Features of clearcase contd1
Features of ClearCase (contd)

  • Effective build management

    • Automatically documents system builds

    • Compatible with popular Unix and Windows Makefiles

  • Flexible process control

    • Allows you to establish project or site specific policies without dictating particular policies, procedures or methodologies. Policies for:

      • Development roles,

      • Workflows

      • Promotion models

    • Audit trails and access controls

CS 406 Testing


  • Textbook

    • S. R. Scach - Classical and Object-Oriented Software Engineering

  • Other books

    • P. Jalote - An Integrated Approach to Software Engineering

    • S. L. Pfleeger - Software Engineering - Theory and Practice

    • Rational Rose - Clearcase manual

CS 406 Testing