Software Configuration Management

1
Software Configuration Management

• Sudipto Ghosh
• CS 406 Fall 99
• October 26, 1999
• Revised Aditya Mathur
• Fall 2001

2
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

3
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?

4
Revisions and Variations
Version n (with fault)
Driver for Laser printer
5
Revisions - why?

• Corrective maintenance
• fix faults

• Perfective maintenance
• write new modules
• change existing modules

• Adaptive maintenance
• change modules

6
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?

7
Why should we keep versions?

• Revision n1 is not necessarily more correct than
  revision n
• Is everyone using revision n1?
• 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.

8
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

9
Configuration management

• Multiple versions have to be managed
• Need a CASE tool for configuration control
• Many tools available commercially

10
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
11
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

12
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

13
Multiple revisions
acknowledgeMessage / 1
acknowledgeMessage / 2
acknowledgeMessage / 3
acknowledgeMessage / 4
Revisions
14
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

15
Version control for variations
printerDriver (inkjet) / 2
printerDriver (laser) / 12
printerDriver (laser) / 13
printerDriver (laser) / 14
16
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

17
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?

18
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?

19
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

20
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

21
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

22
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.

23
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

24
Configuration Management
Configuration Management
Configuration Identification
Configuration Audits
Configuration Control / Change Management
Configuration Status Accounting
25
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

26
Configuration management terms

• Configuration Status Accounting
• Provide status and information about a product
  and its configuration documentation
• Configuration Audits
• Verify consistency of configuration

27
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

28
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

29
Configuration identification (contd)

• How do you get a consistent system from the
  SCIs?
• when SCIs may be getting changed
• when there are many versions
• Makefiles may be used

30
Identification of SCI

• Requirements SCI - requirements document or
  chapters / paragraphs of document.
• Design SCI - usually design document
• Code level - multiple SCIs
• Each separately compileable module
• Each file consisting of modules

31
Dependencies of SCIs

• 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.

32
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?

33
Change control

• SCIs 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 SCIs, it is in the working state.
• That SCI is not under SCM and can be changed.

34
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.

35
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 SCIs that are affected
• Second part (filled by CCB)
• Decision taken by the CCB (approved/not)
• Actions needed to implement the change

36
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

37
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

38
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

39
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 CRs?
• What is the average time and effort for fixing a
  CR?
• What is the number of CRs per SCI?

40
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 CRs and FR

41
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

42
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.

43
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.

44
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?

45
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

46
Build Tools

• Suppose that you dont 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.

47
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.

48
Rational ClearCase

• Meets the challenge of team-based software
  development
• Provides
• Version control
• Workspace management
• Build management
• Process control

49
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

50
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

51
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

52
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