software configuration management l.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Configuration Management PowerPoint Presentation
Download Presentation
Software Configuration Management

Loading in 2 Seconds...

play fullscreen
1 / 47

Software Configuration Management - PowerPoint PPT Presentation

  • Uploaded on

Software Configuration Management . Concepts in SCM, versioning, change control, and future trends Jalote-2002, SEI-1991, Estublier-2000, Conradi-1998. Motivations. Sample Case 1: Two change requests from customer, assigned to different people, overwriting each other work when saving

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' - DoraAna

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
  • Concepts in SCM, versioning, change control, and future trends
  • Jalote-2002, SEI-1991, Estublier-2000, Conradi-1998
  • Sample Case 1:
    • Two change requests from customer, assigned to different people, overwriting each other work when saving
  • Sample Case 2:
    • Requests to fix a defect or explain implementation of the system in an old version w/o upgrading, need for old code
  • Sample Case 3:
    • Faulty software due to old versions of components used in build
  • Software Configuration Management (SCM) is the discipline that enables us to keep evolving software systems under control, and contribute to satisfying quality and time constraints.
  • SCM emerged in early 70s soon after the “software crisis” (Software Engineering is not equal to Programming !)
  • Most of the research was done in 80s but not implemented in actual systems till 90s.
short history
Short History
  • 80s
    • In house systems
    • Unix scripts over RCS (Revision Control System) and Make
    • Sun NSE (Network Software Environment), versioning and cooperation
  • Early 90s
    • First real SCM systems
    • File control -based with limited workspace support
    • ClearCase and Adele
  • Late 90s
    • Process support and reliability
    • Over $1 billion sales
primary definitions
Primary Definitions
  • Configuration is a set of “software objects” required to build a software system.
  • Baseline is a snap-shot of configuration status with a functional relation between items, e.g. :
    • Initial
    • Developmental
    • Test
    • Released
  • Release is a delivered (deliverable) baseline
  • Version is a configuration item state.
scm definition
SCM Definition
  • SCM is a discipline to control and manage the evolving configuration of software systems.
  • IEEE standard 729-1983 for SCM:
    • Identification: structure and components
    • Control: changes to and release of products, consistency of components
    • Status Accounting: recording and reporting the status of components and change requests
    • Audit and Review: validating the completeness of product and consistency of components
scm extensions
SCM Extensions
  • User roles and operating environments introduce extra SCM functionality.
  • Manufacture
    • Managing the construction and building of the product in an effective and optimal way
  • Process management
    • Ensuring the carrying out of the organization’s procedures, policies, and lifecycle model
  • Team work
    • Controlling the work and interactions between multiple users on a product
user roles and views
User Roles and Views
  • Project manager
    • Developing within a certain time frame and meeting requirements
    • Status reporting and reviews
  • Configuration manager
    • Defining and following procedures for creating and changing items
    • Software Change Request (SCR), Configuration Control Board (CCB), task lists
  • Developer
    • Working efficiently (sharing, changing, building)
  • Library of configuration items (e.g. files), providing version control.
  • Objects are immutable while in repository. Need to be “checked-out” to change.
  • Changes automatically create a new version (and number)
  • Versions may not be saved completely but as “delta”
  • Multi-user management may exist to some degree
distributed components
Distributed Components
  • Repository may be logically centralized but physically distributed in different platforms (e.g. Sherpa Design Management System, DMS)
  • Fault tolerance and format translation for user transparency.
change set
Change Set
  • Change set is the set of logically related changes to configuration items.
  • Change set relates low level configuration changes to higher level change requests, in Rational UCM terminology, artifacts to activities.
  • All related file changes (e.g. for a bug-fix) are put in one set linking modified files, the reason, people involved, and additional information.
  • The notion of a workspace is designed to prevent users from interfering with one another’s work.
  • Workspace is a private area where users can “change” a configuration item, e.g. a local directory.
  • It is this service that really convinced practitioners that SCM was thee to help.
  • Needs:
    • Resynchronization (e.g merging)
    • Concurrency control
system product model
System/Product Model
  • System modeling describes a software product, its structure and components, and how to build it.
    • Usually and historically only file-based
    • Build with makefiles. Not adequate enough !
  • System modeling includes the notion of family to capture the history of the product, i.e. succession of versions of the components.
  • Version selection rules determine which versions of components have to be used for each version of the product.
change request
Change Request
  • Software Change Request (SCR) is a documented request for any modification in software (correcting a defect, adding a feature, …) according to a certain procedure
  • Change tracking part of SCM traces any SCR to all modified configuration items.
  • Common SCR attributes are status (e.g. assigned and completed), people, dates, and comments.
cm paradigms
CM Paradigms
  • No single CM system supports all CM concepts and requirements.
  • Certain pattern of CM concepts can be seen in existing systems, resulting in four (sometimes combined) paradigms:
    • Checkin/checkout
    • Composition
    • Long transaction
    • Change set
checkin checkout
  • Repository support for versioning of components
    • Branching and merging
    • Concurrency control through locking
  • Users “check out” before accessing an existing version and “check in” to create a new one.
    • Local file system is the working area for checked out items
    • Mutually exclusive modification within a version branch
  • Checkin/checkout paradigm results in a version history in form of a graph (version graph)
  • Creating configurations and managing their history/family.
  • Configuration consists of
    • a system model (aggregation of components)
    • version selection rules (appropriate version of each component)

1.0 1.1 1.2




1.0 1.1

1.0 1.1 1.2

long transaction
Long Transaction
  • Evolution of the whole software system as a series of atomic changes.
    • Start with a versioned configuration
    • End up with creation of a new version of configuration
    • Development path is the sequence of transactions.
    • Multiple transactions coordinated through concurrency control
  • Different from traditional DB transaction
    • Creating a new version rather than updating existing one
    • Persistence, i.e. long duration more than a login session
  • Paths can create branches.
change set22
Change Set
  • Management of logical changes to configurations
    • Change-oriented vs. version-oriented SCM
    • Logical change is a set of physical changes
    • Link between change requests and actual modifications in configuration items
  • No concurrency control, so combined with checkin/checkout





Fix 1

Feature 4

common scm tools
Common SCM Tools
  • SCCS, RCS (Unix)
  • ClearCase, Summit, CMVC (Rational)
  • Visual SourceSafe (Microsoft)
  • CVS, Bugzilla (open source and free software)
  • Razor (Tower)
  • Bugbase (Archimedes Software)
  • Many other tools with CM capabilities (e.g. Requisite Pro and Rational Rose)
layered cm system
Layered CM System
  • Levels of CM support

CM Policy

QA, CM Process, etc

e.g. SCR and quality audits procedures

CM Protocol

Transactions, workspaces, etc

e.g. checkin/checkout and change sets

CM Primitives

Tool primitives, OS operations, etc

e.g. versioning and locking

  • Product space
    • Software objects
    • Relationships
    • Representations
  • Version space
    • Versions
    • Deltas
    • Version graphs
    • Interplay with product space
  • Merge tools
product space
Product Space
  • Software objects are the results of a development or maintenance activity.
    • Coarse or fine-grained
    • Composite objects (configurations)
  • Relationships connect software objects
    • Composition
      • Composite vs. atomic
      • Product is the root of composition hierarchy
    • Dependency
      • Master and dependent objects
representations of product space
Representations of Product Space
  • Product “foo”
  • Modules with dependencies
  • File system structure
  • Tree structure with typed objects and relationships
  • Dependency graph
version space
Version Space
  • Version v represents a state of an evolving item I
    • v = (ps, vs)
    • Revision (modified) or variant (alternative)
  • Difference between two versions is called a “delta”
    • Symmetric delta between two versions (state-based versioning)
    • Directed delta is a sequence of elementary change operations to create a version from another (change-based versioning)
one level version graphs
One-Level Version Graphs
  • One level organization
    • Each version connected by one single type of relationship called “successor”
    • Supported in NSE and PCTE
    • Different shapes based on multiple sibling and successor
multi level version graphs
Multi-Level Version Graphs
  • Two-level organizations
    • Graph is composed of branches each with a sequence of revisions
    • At least two relationships
      • Successor (within a branch)
      • Offspring (between branches)
    • Supported in RCS
    • ClearCase introduces merging
  • Multidimensional variation
    • So many variants may explode the graph
    • Clusters of related versions can be used
    • Grids (n-dimensional coordinate system) are another solution.
    • Revisions can be represented in grids by adding a time dimension
interplay of version product spaces
Interplay of Version/Product Spaces
  • Multiple configuration items with multiple versions
  • AND/OR graphs provide a general model for integrating product and version space.
    • AND/OR edges come from AND/OR nodes, respectively.
    • Product can be represented by only AND nodes/edges.
    • Versioning is introduced to product space by adding OR nodes/edges.
  • Selection order
    • Product first
    • Version first
    • Intertwined
and or graphs37
AND/OR Graphs
  • In intertwined graph, it is easier to add a new version for one of the items without having to create virtual versions for other items as in “version first” graph.
merge tools
Merge Tools
  • Raw merging applies a change in a new context
    • Supported by SCCS
  • Two-way merging compares two alternative versions and combine them into a new one.
    • Displays differences to the user and allow the choice of appropriate one
    • No automatic resolution of differences
  • Three-way merge tool consults a common baseline when difference is detected
    • Conflicts can be resolved manually or automatically
    • Aide-de-Camp provides this method.
semantic level of merging
Semantic Level of Merging
  • Textual merging
    • Only for text files
    • Supported by almost all SCM systems
    • Only physical conflicts are detected (no valid C file !)
  • Syntactic merging
    • Needs knowledge of file structure
    • Can guarantee a syntactically correct output
    • Research prototypes
  • Semantic merging
    • Can find semantic conflicts and fix if possible
    • Not fully implemented yet
scm process
SCM Process
  • Planning and Setting up SCM
    • Configuration items and procedures
  • Performing SCM
    • Managing the state transition of configuration items
      • Controlled and uncontrolled environments
      • Checkin/checkout
      • Release
    • Change control
  • Monitoring and Audits
scm planning steps
SCM Planning Steps
  • Identify configuration items
  • Choose the tools and environments
  • Define naming and numbering scheme, and director structure
  • Define change control procedure (and people)
  • Set up configuration control board (CCB)
  • Define status tracking methods
  • Define procedures for backup, release, archival, and audits
software change control
Software Change Control
  • Tools for creating and tracking software change request (SCR), examples:
    • ClearQuest
    • Bugzilla
  • SCR General Procedure
    • Accept
    • Assign
    • Check out
    • Perform
    • Check in
change control integration
Change Control Integration
  • Change control needs to be integrated with repository and other SCM tools to trace all changes to the SCRs.
  • Rational Unified Change Management combines ClearQuest (activity-based) with the version control tool, ClearCase (artefact-based).
  • More intelligent tools can/should show and track the changes in higher levels of abstraction than files, e.g. functionality modules.
status monitoring and audits
Status Monitoring and Audits
  • Projects must perform regular status checking (e.g. “under development”, “ready for release”) for all configuration items.
  • SCRs must also be checked regularly.
  • Projects can also perform CM audits o make sure procedures are being followed.
    • Audit report should generate a task list assigned to specific people.
state of practice
State of Practice
  • Most useful features
    • Change control
    • Activity control
    • Workspace support
    • Global view
    • traceability
  • Most missing features
    • Process support
    • Concurrent and distributed engineering support
    • Scalability
    • Cross platform operation
current research
Current Research
  • Versioning
    • Why are two objects versions of each other?
  • Data/product model
    • Use of more advanced data models rather than file systems
    • Relation with version model (on top, below, part of)
  • Composition
    • Configuration description languages
  • Building
    • Unified makefiles
    • Language dependent systems (smart build)
current research47
Current Research
  • Workspace
    • Complex objects available at a given location in a given format (e.g. editor file or DBMS schema)
  • Cooperative and remote work
    • Define, at high level, the cooperation strategies, organization and procedures
    • Merging objects (more than text files)
    • Web support
  • Process support
    • Integration of activity-based and item-based approaches
    • High level procedures and models