Software configuration management
Download
1 / 47

Software Configuration Management - PowerPoint PPT Presentation


  • 285 Views
  • Updated 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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 l.jpg
Software Configuration Management

  • Concepts in SCM, versioning, change control, and future trends

  • Jalote-2002, SEI-1991, Estublier-2000, Conradi-1998


Motivations l.jpg
Motivations

  • 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


Background l.jpg
Background

  • 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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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)




Repository l.jpg
Repository

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


Workspace l.jpg
Workspace

  • 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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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)



Composition l.jpg
Composition

  • 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

A

B

C

1.0 1.1

1.0 1.1 1.2


Long transaction l.jpg
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 l.jpg
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

A B

C D

+

+

Fix 1

Feature 4


Common scm tools l.jpg
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 l.jpg
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


Versioning l.jpg
Versioning

  • Product space

    • Software objects

    • Relationships

    • Representations

  • Version space

    • Versions

    • Deltas

    • Version graphs

    • Interplay with product space

  • Merge tools


Product space l.jpg
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 l.jpg
Representations of Product Space

  • Product “foo”

  • Modules with dependencies

  • File system structure

  • Tree structure with typed objects and relationships

  • Dependency graph



Version space l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


ad