Software configuration management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 52

Software Configuration Management PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Software Configuration Management

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

Variations

Revisions

Printer driver for PC

Driver for

Ink-jet printer

Version n+1

(fixed)

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


Variations

Variations

  • 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

Revisions

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

printerDriver

(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

Configuration

Management

Configuration

Identification

Configuration

Audits

Configuration

Control /

Change

Management

Configuration

Status

Accounting

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


Auditing

Auditing

  • 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


References

References

  • 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


  • Login