You are on page 1of 135

Carnegie Mellon University

Software Engineering Institute

Configuration Management
Systems
Susan A. Dart

Ada Road Show Australia, May 18-27, 1992
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Use of any trademarks in this slide set is not intended in any way to infringe on the
rights of the trademark holder.
1

Carnegie Mellon University

Software Engineering Institute

Overview
➜ Introduction to configuration management (CM) issues
Spectrum of concepts in CM systems
Past, present and future of CM systems

2

Carnegie Mellon University

Software Engineering Institute

Survey
How many people





3

are currently doing CM?
are using an automated CM system?
are using a homegrown CM system?
are happy with their CM system?
resent being controlled by CM practices?
think that CM is a fascinating topic?

Carnegie Mellon University

Software Engineering Institute

Overview of Introduction

Definitions of CM and CM system
CM solution
Functionality requirements for CM systems
Kinds of CM systems
Summary of introduction

4

Carnegie Mellon University

Software Engineering Institute

Definition of CM - 1
Standard definition (IEEE 729-1983)

5

Identification: identifying components, structure

Control: controlling releases and changes

Status accounting: recording, reporting status

Audit and review: validating completeness

Carnegie Mellon University

Software Engineering Institute

Definition of CM - 2
Based on existing CM systems, broaden definition

6

Manufacture: managing construction, building

Process modelling: ensuring life-cycle model

Team work: controlling team interactions

Carnegie Mellon University

Software Engineering Institute

What is a CM System?
A system that is intended to provide some form of CM
has either
• version control
• configuration item identification
• structure identification
• system building
CM system
• CM tool
• CM service in an environment
• CASE tool

7

Carnegie Mellon University

Software Engineering Institute

Views of CM
CCM, PCM, DCM, ACM
Corporate
CM
Project
CM
Developer
CM

Enterprise computing
environment
Project group specific CM

Programmer CM

Application Application reconfiguration
CM
8

Carnegie Mellon University

Software Engineering Institute

Overview of Introduction
Definitions of CM and CM system
➜ CM solution
Functionality requirements for CM systems
Kinds of CM systems
Summary of introduction

9

Carnegie Mellon University

Software Engineering Institute

CM Solution
CM plan
Planning
CM system
Management
Process

Automation

10

People

Carnegie Mellon University

Software Engineering Institute

CM Planning - 1
What should be in the CM plan?
• CM process
• CM policies
• CM procedures
• 4 key elements of CM
• what, how, when, why, where
• link to software life cycle
• CM organization and interfaces to others
• vendor/subcontractor terms
For evolving plans, use references to separate
documents

11

Carnegie Mellon University

Software Engineering Institute

CM Planning - 2
Variety of standards
• IEEE 828-1990, IEEE 1042-1987
• NASA Guidebook for SCM for managers
• MASA SFW DID 04
• DOD-STD-2167a
• DOD DID DI-MDDR-80030A
• MIL-STD-973
• MIL-STD-483A
Customize based on
• project size and organization type
Should the plan evolve or sit on the shelf?

12

Carnegie Mellon University

Software Engineering Institute

CM Process
What needs to be described?
• tasks, activities, and products
• policies and procedures
• SEI Capability Maturity Model practices
What are the data structures
What level of control will be enforced?
• tight, active control (enforcement, guidance)
• loose, passive control (freedom, recording)
How much is automated?
• combination of automation and manual procedures

13

Carnegie Mellon University

Software Engineering Institute

Example of a Partial Process
Bug
Fixes

Change
Management

Plan
System
Release

Request
for a
Change

System
Code
Enhancements

Change
Request
Management

Impact
Analysis

Repository

Change Management System

Change Form

14

Testing

CCB Review

Approval

Diagram adapted from L. J. Arthur’s Software Evolution - The Software Maintenance Challenge

Design Documents

Release

Carnegie Mellon University

Software Engineering Institute

People: Who Has CM Needs?
Project Manager: manages progress
Configuration Manager: sets procedures and policies
Developer: develops and maintains code
Tester: tests all code
Quality Assurance Manager: ensures quality
Customer: uses product and reports bugs
Should the organization have a separate CM group?

15

Carnegie Mellon University

Software Engineering Institute

CM Automation
Need to cater for various user roles
What CM system functionality is needed?
• CM requirements
• CM tool features
Choosing and evaluating a CM system
How does the CM system integrate with the
environment?
• coexist, use, and enhance the environment
• process - fit CM services with project’s process
• control - fit CM services with tools (who’s in charge)
• data - data management
16

Carnegie Mellon University

Software Engineering Institute

CM Management
When to start using automated CM?
The time at which a project group starts to use a CM
system depends on the capabilities of the CM system.
• before project start-up (corporate memory)
• during product development
• after product release (maintenance)
Buy or build?
• tradeoffs required
Technology transition

17

Carnegie Mellon University

Software Engineering Institute

The CM Solution is Complex - 1
The CM problems are complex.
• very large, heterogeneous applications
• distributed sites
• long-lived applications
The CM/environment technology available is limiting.
• process enactment
• tool integration
• scale
• software architectures and families of applications
• enterprise’s way of business
• no “silver bullet” for CM
• buy or build
There are different views, roles, and expectations of CM.
18

Carnegie Mellon University

Software Engineering Institute

The CM Solution is Complex - 2
People react negatively toward CM
• controlling and constraining
Evolution of applications, environments, CM system
Kinds of maintenance
• corrective - bug fixes and patches
• adaptive - enhancements
• perfective - improvements for amenability and
robustness to change

19

Technology addresses corrective and adaptive
• change requests
• change control boards
• life-cycle state transitions
• module interconnection languages - partitioning

Carnegie Mellon University

Software Engineering Institute

Overview of Introduction to CM
Definitions of CM and CM system
CM Solution
➜ Functionality requirements for CM systems
Kinds of CM systems
Summary of introduction

20

Carnegie Mellon University

Software Engineering Institute

Functionality Requirements
Roles, goals, responsibilities, and tasks of the different
users determine the functionality required of a CM
system.

21

Carnegie Mellon University

Software Engineering Institute

CM Requirements
CONSTRUCTION
Building
TEAM
Snapshots
Optimization
Change impact analysis
Regeneration
Workspaces
Conflict resolution
Families

AUDITING
History
Traceability
Logging

Versions
Configurations
Versions of
configurations
Baselines
Project Contexts
Repository
Kinds of components

Life-cycle support
Task management
Communication
Documentation

Statistics
Status
Reports
ACCOUNTING
22

STRUCTURE
System model
Interfaces
Relationships
Selection
Consistency

PROCESS

COMPONENTS
Access control
Change requests
Bug tracking
Change propagation
Partitioning
CONTROLLING

Carnegie Mellon University

Software Engineering Institute

Component Requirements
These identify, classify, and access components.






23

Components: source, derived, diagrams, documents
Versions: record version identification, reason
Configurations: identify grouping of components
Versions of configurations: versions of groupings
Baseline: identify a frozen baseline
Project contexts: recognize context of a project
Repository: library for all artifacts

Carnegie Mellon University

Software Engineering Institute

Structure Requirements
These describe the architecture and grouping of
components.

24

System model: system structure

Interfaces: interface descriptions

Relationships: dependencies among components

Selection: choosing the right version

Consistency: valid groupings

Carnegie Mellon University

Software Engineering Institute

Construction Requirements
These support the construction of the product and its
artifacts.

25

Building: system build

Snapshots: freeze status of product

Optimization: reduce recompilation time and space

Change impact analysis: predict effect of changes

Regeneration: recreate an artifact

Carnegie Mellon University

Software Engineering Institute

Team Requirements
These synchronize and coordinate teamwork.

26

Workspaces: isolating work

Conflict resolution: resolving and merging changes

Families: developing related products

Carnegie Mellon University

Software Engineering Institute

Controlling Requirements
These control how and when changes are made.

27

Access control: limiting access to components

Change requests: driving the change process

Bug tracking: tracking bugs and fixes

Change propagation: propagating related changes

Partitioning: limiting the effects of change

Carnegie Mellon University

Software Engineering Institute

Auditing Requirements
These maintain an audit trail of product and process.

28

History: keeping a history of changes for audit

Traceability: tracking related components for
checking validity of configuration items

Logging: recording details of work for audit trail

Carnegie Mellon University

Software Engineering Institute

Accounting Requirements
These correlate facts about product and process.

29

Statistics: recording and generating statistics

Status determination: browsing status

Reports: generating reports

Carnegie Mellon University

Software Engineering Institute

Process Requirements
These manage product evolution.

30

Life-cycle support: enforcing life-cycle model

Task management: tracking tasks

Communication: ensuring appropriate interactions

Documentation: recording knowledge

Carnegie Mellon University

Software Engineering Institute

Summary of Requirements
8 functionality areas
• components
• structure
• construction
• team
• controlling
• accounting
• auditing
• process
Many requirements
Intended to suit all user roles
Team and process “integrate” all requirements
31

Carnegie Mellon University

Software Engineering Institute

Overview of Introduction to CM
Definitions of CM and CM system
CM solution
Functionality requirements for CM systems

Kinds of CM systems
Summary of introduction

32

Carnegie Mellon University

Software Engineering Institute

List of CM Systems
The following list represents a variety of CM systems.
It includes
• environments with CM capabilities
• CASE tools
• research systems
• defunct systems
The key messages area
• we can learn about CM concepts
• how stable is the CASE and environments industry?

33

Carnegie Mellon University

Software Engineering Institute

Some CM Systems - 1
ADC (Software Maintenance & Development Systems Inc.)
Adele (University of Grenoble)
AmplifyControl (CaseWare Inc.)
CADEX (Database Applications Inc.)
CCC (Softool Corp.)
Cedar (Xerox)
CMA (Tartan Inc.)
CMF (Expertware)
34

Carnegie Mellon University

Software Engineering Institute

Some CM Systems - 2
CMS (Digital Equipment Corp.)
Compass (Configuration Management and Product Assurance Corp.)
DMS (Sherpa Corp.)
DSEE (Apollo Corp.)
EAST (SFGL France)
Enterprise II (Syseca France)
Endevor (Legent Corp.)
Gandalf (Carnegie Mellon University)
35

Carnegie Mellon University

Software Engineering Institute

Some CM Systems - 3
ISPW (Benchmark Technologies)
ISTAR (Imperial Software Technology, Ltd.)
Jasmine (Xerox)
Librarian (Computer Associates)
LIFESPAN (Yard Software Systems)
Maestro (Softlab)
NSE (Sun Microsystems)
PACT (Esprit Consortium)
36

Carnegie Mellon University

Software Engineering Institute

Some CM Systems - 4
Panlcm (Pansophic)
Panvalet (Pansophic)
PCMS (SQL Systems Ltd.)
PowerFrame (EDA Systems, Inc.)
PVCS (Sage)
Rational (Rational)
RCS (Free Software Foundation)
SCCS (AT&T)
37

Carnegie Mellon University

Software Engineering Institute

Some CM Systems - 5
SCLM (IBM)
shape (University of Berlin)
SLSCE (General Research Corp.)
SMS (BiiN)
Softboard (Atherton Technology)
Supercase (Advanced Technology International)
Teamnet (TeamOne Systems)
Teamwork (Cadre Technologies)
38

Carnegie Mellon University

Software Engineering Institute

State of CM Systems - 1
Come from
• research - academia, industry
• vendors
- environments with CM
- CM tools: base, turnkey
- CASE tools with a bit of CM
• in-house
Automate different requirements
Cover different functionality
Suit single or multiple platforms
Implement a particular control level
39

Carnegie Mellon University

Software Engineering Institute

State of CM Systems - 2
No standardization
Plethora of common concepts
Complex mechanisms - not transparent
Beginnings of a terminology with spectrum of concepts
Most systems offer simple functionality
User has to create a CM solution

40

Carnegie Mellon University

Software Engineering Institute

Summary of Introduction
Definitions: CM, CM system
Four views of CM: CCM, PCM, DCM, ACM
CM solution
• planning, process, people, automation, management
• CM plan, CM system
User requirements: functionality areas supported
• team, construction, structure, components
• process, controlling, auditing, accounting
Many CM systems
State of CM systems
41

Carnegie Mellon University

Software Engineering Institute

Overview
Introduction to configuration management (CM) issues
➜ Spectrum of concepts in CM systems
Past, present and future of CM systems

42

Carnegie Mellon University

Software Engineering Institute

Spectrum of Concepts in CM Systems

Descriptions and examples of concepts
Conclusion

43

Carnegie Mellon University

Software Engineering Institute

Spectrum of Concepts
Context
Management

Transaction

PowerFrame*

Life-cycle
Model
CCC*

NSE*

Transparent
View

Distributed
Component

SMS*

Sherpa DMS*

Change
Request

Workspace
shape*

LIFESPAN*

System
Modelling

Repository
RCS*

Jasmine*

Object
Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change
Set

Subsystem

ADC*

Rational*

Consistency
Maintenance
CMA*

44

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Overview of the Spectrum
Nodes are concepts.
Lines indicate evolution of concepts.
Example of a system with a concept.
No common concept terminology.
Simplified descriptions of concepts.
Many CM systems implement several concepts.

45

Carnegie Mellon University

Software Engineering Institute

Functionality Areas
Component

46

Structure, Construction

Repository
Distributed component

Change set
System modelling
Subsystem
Object pool
Attribution
Consistency maintenance

Team

Process

Workspace
Transparent view
Transaction

Context management
Contract
Change request
Life-cycle model

Carnegie Mellon University

Software Engineering Institute

Overview of Concept Descriptions

Component functionality
Structure and construction functionality
Team functionality
Process functionality

47

Carnegie Mellon University

Software Engineering Institute

Spectrum of CM Concepts
Context
Management

Transaction

PowerFrame*

Life-cycle
Model
CCC*

NSE*

Transparent
View

Distributed
Component

SMS*

Sherpa DMS*

Change
Request

Workspace
shape*

LIFESPAN*

System
Modelling

Repository
RCS*

Jasmine*

Object
Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change
Set

Subsystem

ADC*

Rational*

Consistency
Maintenance
CMA*

48

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Component Functionality - 1

Distributed
Component
Sherpa DMS*

Repository
RCS*

* This system exemplifies the concept shown in the node.

49

Carnegie Mellon University

Software Engineering Institute

Component Functionality - 2
Addresses requirements



50

versions
configurations
repository
kinds of components

Carnegie Mellon University

Software Engineering Institute

Repository - 1

Check in

Centralized File Repository
Check out

1.1
1.2
1.2.2.1

1.3
2.1

1.2.2.1.1.1
1.2.2.2

1.3.3.1

A version tree with three side branches
51

Carnegie Mellon University

Software Engineering Institute

Repository - 2
Example: RCS
Library of source ASCII files
Immutable files
Version control in repository
Contents are CM information
• file differences
• logs (reason, who, when)
• version numbers
• tags (state, symbolic name)

52

Using repository
• check out/check in: new version

Carnegie Mellon University

Software Engineering Institute

Repository - 3
File locking to avoid change clashes
Version numbering scheme
Version tree
• predecessor/successor
• branching - variants
Delta - space and time savings
Repository
• captures CM information about objects
• stores files as immutable objects

53

Carnegie Mellon University

Software Engineering Institute

Distributed Component - 1

DEC

APOLLO

Centralized
File
Repository

54

SUN

Check out, check in
File format translation

Carnegie Mellon University

Software Engineering Institute

Distributed Component - 2
Example: Sherpa DMS
Heterogeneous platforms
Repository: physically centralized
CM spans the network.
• transparent distribution
• fault tolerance
• format translation of files
• multiple copies of files
• knowledge of latest copy
• teams work on same configuration
Data is logically distributed
55

Carnegie Mellon University

Software Engineering Institute

Overview of Concept Descriptions
Component functionality
➜ Structure and construction functionality
Team functionality
Process functionality

56

Carnegie Mellon University

Software Engineering Institute

Spectrum of CM Concepts
Context
Management

Transaction

PowerFrame*

Life-cycle
Model
CCC*

NSE*

Transparent
View

Distributed
Component

SMS*

Sherpa DMS*

Change
Request

Workspace
shape*

LIFESPAN*

System
Modelling

Repository
RCS*

Jasmine*

Object
Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change
Set

Subsystem

ADC*

Rational*

Consistency
Maintenance
CMA*

57

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Structure and Construction
Functionality - 1
System
modelling

Repository

Object
pool

Jasmine*

DSEE*

Attribution
Adele*

Change
set

Subsystem

ADC*

* This system exemplifies the concept shown in the node
58

Rational*

Consistency
maintenance
CMA*

Carnegie Mellon University

Software Engineering Institute

Structure and Construction
Functionality - 2
Addresses requirements








59

building - construct
optimization - space, reduce compilation time
change impact analysis - reduce scope of change
regeneration - record, minimize
system model - record structure
interfaces - reuse
relationships - dependencies
selection - binding
consistency - check

Carnegie Mellon University

Software Engineering Institute

Change Set - 1
Change
Set 1

Change
Set 2

Change
Set 3

File
1

File
2

File
3

File
4

Release 1
60

Release 2

Diagram adapted from “Aide-De-Camp Software Management System Product Overview.” Software Maintenance & Development
Systems Inc., 1989

Carnegie Mellon University

Software Engineering Institute

Change Set - 2
ADC has an example
Change set represents a logical change to a
configuration
Captures differences due to changes
• changes to all files
• reason(s)
• author, when
Change set has a name
Automatic tracking of which change to which file

61

Carnegie Mellon University

Software Engineering Institute

Change Set - 3
Access to any version not dependent on latest version
User specifies a formula: baseline + list of change sets
Dependent or independent of change history
User determines scope of change
ADC automatically captures details
Audit trail of changes
Change set
• captures logical change details
• independence from latest version configuration
62

Carnegie Mellon University

Software Engineering Institute

System Modelling - 1
BTree: TEMPLATE =
BEGIN
COMPONENTS: SET = {BTreeInterface.Src, BTreeInterface.Bin,
BTreeImpl.Src, BTreeImpl.Bin};
IMPORTS: SET = {Filesystem.Bin, Heap.Bin};
EXPORTS: SET = {BTree.Bin};
Sources: SET = {BTreeInterface.Src, BTreeImpl.Src};
Binaries: SET = {BTreeInterface.Bin, BTreeImpl.Bin};
IsCompiledFrom: FUNCTION = BEGIN
BTreeInterface.Bin: {BTreeInterface.Src};
... END IsCompiledFrom;
IsCompiledImporting: FUNCTION = BEGIN... END...
IsCompiledUsing: FUNCTION = IsCompiledFrom PLUS
IsCompiledImporting;
... END BTree;
63

Carnegie Mellon University

Software Engineering Institute

System Modelling - 2
Example: Jasmine
Via a textual description, it models
• system component inventory
• structure
• related components/configurations
• how to build it (tools, options)
• results
Description involves
• relations - structure, dependency, build order
• version binding
• construction rules
• verification rules
64

Template = description of structure

Carnegie Mellon University

Software Engineering Institute

System Modelling - 3
User-defined relations: queries
Construction rules: past and future building
Verification rules: structural, organizational constraints
Version selection according to a context (pathname)
Image = bound objects
System modelling
• useful for programmers and tools
• abstracts definition from instance of a system
• aids tools in maintaining integrity of system
65

Carnegie Mellon University

Software Engineering Institute

System Modelling - 4

Templates

Verification rules
Version selection

Image

Construction rules

Executable objects
66

Carnegie Mellon University

Software Engineering Institute

Subsystem - 1
Subsystem A
Spec 1

System
Susans-Release
Subsystem A

Impl 1
Impl 2

Spec 1
Impl 1
Subsystem B
Spec 1
Impl 2

Subsystem B
Spec 1
Spec 2

Impl 1
Impl 2
Impl 3

67

Diagram adapted from Feiler, Dart, & Downey,Evaluation of the Rational Environment CMU/SEI-88-TR-15, July 1988

Carnegie Mellon University

Software Engineering Institute

Subsystem - 2
Example: Rational
Partitions a large Ada program
Subsystem = interfaces + implementations
Components: invisible, unless exported
Recompilations within subsystem
Can mix-’n-match versions of subsystems: system
Runtime check for compatibility
Subsystem: confines effects of changes
68

Carnegie Mellon University

Software Engineering Institute

Derived Object Pool - 1
BCT

Derived object
with BCT
BCT

BCT

Pool

BCT

BCT
BCT

System Modelling

69

System Modelling

Carnegie Mellon University

Software Engineering Institute

Derived Object Pool - 2
Example: DSEE
Object pool = pool of derived objects, to be shared
All generation details associated with each object
Bound Configuration Thread (BCT)
User indicates desired derivation properties
DSEE automatically uses an existing object
Computes BCT: automatic matches in object pool

70

Carnegie Mellon University

Software Engineering Institute

Derived Object Pool - 3
BCT
• versions of source, tools, options
• user comments
• date, time, person involved, location
Defunct objects automatically deleted
Different kinds of object pools, e.g., personal
Object pools
• optimize need for generating objects
• maximize amount of sharing/reuse

71

Carnegie Mellon University

Software Engineering Institute

Attribution - 1
Example of attributes
manual m2-susan-v1
attributes
type = debug
syst = unix
author = susandart
state = experimental
date = 91-05-13
end

Example adapted from J. Estublier “A Configuration Manager: The Adele Data Base of Programs,” Proceedings of the Workshop
on Software Engineering Environments for Programming-in-the-Large, June 1985
72

Carnegie Mellon University

Software Engineering Institute

Attribution - 2
Adele presents an example
Data modelling facilities: any structure
Objects: attributes and relationships
Attributes
• name and value
• predefined and user-defined attributes
Selection rules and constraints
Configuration: characteristics of objects (rather than
specific composition of versions)
73

Higher level of abstraction

Carnegie Mellon University

Software Engineering Institute

Consistency Maintenance - 1
Compiler

v

ld
cd

Compiler.V1.VAX

c
c

lc

c

v

lc

lc
id

FRONT
END
ld

lc

v

MIDDLE
END

v

FE.V1

BACK
END

v

FE.V2

v

Version
Logical component
Inheritable dependency
Configured

v
v

ME.V3.VAX

c

Consistent dependency

ld

cd
ME.V2.MC68K

v

v

ME.V4.I86386

cd

74

id

id

Logical dependency

Diagram taken from E. Ploedereder, Tartan Inc.

BE.V7.VAX

BE.V9.MC68K

BE.V10.IBM370

Carnegie Mellon University

Software Engineering Institute

Consistency Maintenance - 2
CMA provides an example
Modelling + usage information: check consistency
Classes of attributes and relationships
Checks that combinations of objects are consistent
Accumulates usage information in database
A usable configuration must be
• complete
• unambiguous
• consistent
• devoid of version skews
75

Carnegie Mellon University

Software Engineering Institute

Consistency Maintenance - 3
Attributes: constraints, types, versions
Relationships: logical, compatible, component,
instance, inheritable dependencies
Identifies, preserves, and predicts consistencies in
creating and reusing configurations
User relies on CM system to identify and preserve
consistencies and predict inconsistencies

76

Carnegie Mellon University

Software Engineering Institute

Overview of Concept Descriptions
Component functionality
Structure and construction functionality

Team functionality
Process functionality

77

Carnegie Mellon University

Software Engineering Institute

Spectrum of CM Concepts
Context
Management

Transaction

PowerFrame*

Life-cycle
Model
CCC*

NSE*

Transparent
View

Distributed
Component

SMS*

Sherpa DMS*

Change
Request

Workspace
shape*

LIFESPAN*

System
Modelling

Repository
RCS*

Jasmine*

Object
Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change
Set

Subsystem

ADC*

Rational*

Consistency
Maintenance
CMA*

78

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Team Functionality - 1

Transaction
NSE*

Transparent
view
SMS*

Workspace
shape*

Object pool

* This system exemplifies the concept shown in the node
79

Carnegie Mellon University

Software Engineering Institute

Team Functionality - 2
Addresses requirements

80

workspaces
- isolation of work
- concurrency control

conflict resolution
- merging changes in workspace and repository

families
- product versions across workspaces

Carnegie Mellon University

Software Engineering Institute

Workspace - 1
Public Database

1.0

1.0

1.1

1.1

Private Workspace

81

2.0

1.2

1.3

2.1

2.2

2.2

Carnegie Mellon University

Software Engineering Institute

Workspace - 2
Example: “shape”
Isolation from other users
Development on mutable objects
Workspace achieved via version status model
Private objects: busy state, mutable, promotion
Public objects: frozen state, immutable
Distinction between temporary and long-term
repository
82

Carnegie Mellon University

Software Engineering Institute

Transparent View - 1
Changes From Workspaces
Public Repository

1.1

1.0

1.0

1.1

Private Workspace
83

2.0

1.2

1.3

1.4

2.1

1.5

2.2

2.2

Carnegie Mellon University

Software Engineering Institute

Transparent View - 2
SMS provides an example
Only particular versions of configurations seen in
workspace: special, yet mimics repository
Other versions can be “hidden” from view
User assigned access to workspace
Components belong to workspace (rather than to user)
History captured in workspace
Naming of objects local to workspace
Viewing + protection mechanism
84

Carnegie Mellon University

Software Engineering Institute

Transaction - 1
Individual’s Workspace
1.0

acquire

1.1
reconcile

6.0
Public Repository

85

1.2

acquire

Group Workspace
1.0

1.1

1.2
resync

6.1

reconcile

1.3

1.4

reconcile

6.2

1.3

6.3

6.4

1.5

Carnegie Mellon University

Software Engineering Institute

Transaction - 2
Example: NSE
Transaction = coordinated and isolated unit of work
Modelled by “environments” and commands
Environment: directory of source and derived objects
Commands: protocol of interactions
Merging of changes across environments
Nested transactions
Synchronized and coordinated teamwork
86

Carnegie Mellon University

Software Engineering Institute

Overview of Concepts Descriptions
Component functionality
Structure and construction functionality
Team functionality
➜ Process functionality

87

Carnegie Mellon University

Software Engineering Institute

Spectrum of CM Concepts
Context
Management

Transaction

PowerFrame*

Life-cycle
Model
CCC*

NSE*

Transparent
View

Distributed
Component

SMS*

Sherpa DMS*

Change
Request

Workspace
shape*

LIFESPAN*

System
Modelling

Repository
RCS*

Jasmine*

Object
Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change
Set

Subsystem

ADC*

Rational*

Consistency
Maintenance
CMA*

88

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Process Functionality - 1
Context
Management
PowerFrame*

Life-cycle
Model CCC*
Change
Request
LIFESPAN*

Repository

Contract
ISTAR*
89

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Process Functionality - 2
Addresses requirements

90

life-cycle support
- change and development process

task management
- tasks specific to context and processes

communication
- tasks and people

documentation
- automatic record

Carnegie Mellon University

Software Engineering Institute

Context Management - 1
Workspace: susan

Projects: sample

Options:

Designs: full_adder Views: simulation

verilog

Vistas: engineer

full_adder

pcb_editor
fast

standard

half_adder

compiler
packager
91

fast

standard

Carnegie Mellon University

Software Engineering Institute

Context Management - 2
Example: PowerFrame
Provides CM in a domain-specific manner
Operates in a behind-the-scenes manner
Characterizes “tool run” context
Captures current context
• data sets (source, derived)
• commands, options
• tools
Does automatic versioning on data items
92

Eliminates user’s need to remember context

Carnegie Mellon University

Software Engineering Institute

Contract - 1
Legend: CI = Configuration
Item
Client contract

CI

CI

assign

deliver

CI

CI

Contract

import

CI

notify

Contract
repository
93

export

CI

scan

CI

CI

Diagram adapted from Graham and Miller, ISTAR Evaluation CMU/SEI-88-TR-3, July 1988

Tool
Work
Area

Carnegie Mellon University

Software Engineering Institute

Contract - 2
Example: ISTAR
Models part of software process and product
Formal agreement: tasks, input, deliverables, resources
Exchange of contracts
Contract fulfillment
Monitor the status
Track artifacts
Contract: plan for, and a record of, a unit of work
94

Carnegie Mellon University

Software Engineering Institute

Change Request - 1
Online
change
request

Software
Status
Report
(SSR)

Software
Problem
Report
(SPR)

Investigate

Design
Changes
(DC)

Repository

CCB
vote
approval

DC agreed
Changes
frozen
DC “frozen”

95

DC work QA
approved
Changes
made

DC “active”
Files locked

Diagram adapted from A. Tilbury, “Why Software Quality Control Now Needs To Be Automated” LIFESPAN brochure

Carnegie Mellon University

Software Engineering Institute

Change Request - 2
Example: LIFESPAN
An associated process model for making changes
Series of online forms
• Software Performance Report (SPR)
• Design Change (DC)
• Software Status Report (SSR)
Series of states, tasks, roles
• designers and implementors investigate SPR
• change impact analysis
• people affected by changes - CCB, DC “active”
• engineers make changes - new version
• QA approval - DC “approved” and SSR
96

Carnegie Mellon University

Software Engineering Institute

Change Request - 3
Means for users and maintainers to communicate
History of changes related to change requests
Audit trail of changes completed
Status reports for changes in progress
Ensures the right people do their job
Drives the process of change

97

Carnegie Mellon University

Software Engineering Institute

Life-Cycle Model - 1
Production
configurations

Release 1

Release 2

Program
Manager
approval

Current
Release
Generate
new release

Check out
Check
out

Development

Test
Manager
approval

Approve
Check in

Emergency
fix

Integration

Development
configuration
Turnover
Approve
Program
Manager
approval

98

Diagram adapted from CCC brochure, 1986

Testing
and QA
Test
configuration

Test
Manager
approval

Approved
configuration

Carnegie Mellon University

Software Engineering Institute

Life-Cycle Model - 2
CCC presents an example
Separates phases and responsibilities
Models phases, tasks, transition, data flow
Code passes through phases/configurations
• development
• testing
• approval
• production
Protocol of interactions approve transitions

99

Life cycle achieved via activities on different states of a
configuration

Carnegie Mellon University

Software Engineering Institute

Overview of Spectrum of Concepts
Concept descriptions
➜ Conclusion

100

Carnegie Mellon University

Software Engineering Institute

Conclusion -1
Spectrum covers 15 concepts
Topology: features build upon one another
Provides a vocabulary for discussing CM support
Is a research vehicle for understanding CM support
No single CM system provides all functionality.
Some systems provide many concepts.
CM systems seem to be approaching a common model.

101

Carnegie Mellon University

Software Engineering Institute

Conclusion - 2
Mechanisms primarily implemented
• version control
• logging for an audit trail
• system modelling
• baseline
• email for communication
• notion of a configuration
• change request

102

Carnegie Mellon University

Software Engineering Institute

Conclusion - 3
Less frequently implemented
• change set
• subsystem
• object pool
• workspace
• transparent view
• transaction
• attribution
• consistency checks and maintenance

103

Carnegie Mellon University

Software Engineering Institute

Overview
Introduction to configuration management (CM) issues
Spectrum of concepts in CM systems
➜ Past, present and future of CM systems

104

Carnegie Mellon University

Software Engineering Institute

The Future of CM Systems
Where were we: the past
Where are we: the present
Where are we going: the future
Conclusion

105

Carnegie Mellon University

Software Engineering Institute

Where Were We: The Past
Understanding of the CM problem: complexity
Homegrown CM systems, if any
Version control, build, change control
CM solution was a manual one
CM was a private problem
Researchers: third-party solutions
• RCS, Gandalf, Cedar
Version control, compiling code, bug tracking
106

Carnegie Mellon University

Software Engineering Institute

Where Are We: The Present
Lots of CM technology
• CM tools: turnkey, base system
• CASE tools with CM capabilities
• environments with CM capabilities
Difficult to find a CM solution
• long-lived, evolving software
• large applications
• evolving, homegrown CM systems
• off-the-shelf solution
• heterogeneous platforms
• nature of tools
• more variables to consider

107

Carnegie Mellon University

Software Engineering Institute

Where Are We Going: The Future
Technology
Process
Standards
Politics
Management

108

Carnegie Mellon University

Software Engineering Institute

Technology
CASE tool coalitions and IPSEs
10% of CM solution is the technology
New requirements
• interoperability between CM systems
• preventative maintenance support
• global perspective on repositories
• switching CM services
• distributed CM system

109

Carnegie Mellon University

Software Engineering Institute

Interoperability Between CM
Systems
RCS

SCCS

DSEE

110

CCC

System integration
Tool import/export

Carnegie Mellon University

Software Engineering Institute

Preventative Maintenance Support
Makes software more robust, durable, and amenable to
future changes
Involves
• reverse engineering
• reengineering
• change impact analysis
We need
• better capturing of architectures (system models)
• semantic-based change impact analysis
• better module interconnection languages

111

Carnegie Mellon University

Software Engineering Institute

Global Perspective On Repositories
Home
Project A

RCS ...

112

Project B

RCS ...

Source...

RCS ...

Carnegie Mellon University

Software Engineering Institute

Switching CM Services
Switches/options on CM system to suit
• life-cycle phase
• kind of application
• kind of users
• policies
• risk factor

113

Carnegie Mellon University

Software Engineering Institute

Distributed CM System
What is distributed CM? logical or physical or both?
Italy

Germany

Unisys

Unisys

Database
Database

New York

Unisys
Los Angeles

TCP/IP
Unix

IBM

Sun Apollo

Unix IBM Sun Apollo

Europe
USA
114

Paris

Carnegie Mellon University

Software Engineering Institute

Process
Defining, implementing, enacting, using, monitoring
Need supportive implementations
Matching CM system with process
Roles

115

Carnegie Mellon University

Software Engineering Institute

Standards
Standardization: frameworks, e.g., PSESWG
• Project Support Environment Standards Working
Group for the U.S. Navy’s Next Generation Computer
Resources
Spanning fields and merging groups, e.g., CFI
• Computer-Aided Design Framework Initiative
CM services model
Process of evolution

116

Carnegie Mellon University

Software Engineering Institute

Process of Evolution
Research
Systems

Commercial
Systems

Many mechanisms

Concepts and
classification

Standardization
on frameworks/
infrastructures
117

Consolidation
of efforts

Definition of
services

Carnegie Mellon University

Software Engineering Institute

Politics
Government requirement of process maturity level 3
What CM tools/capabilities are needed?

118

Carnegie Mellon University

Software Engineering Institute

Management
Management buy-in
Commitment of resources
Evaluation of CM capabilities
Buy versus build in-house decision
Technology transition

119

Carnegie Mellon University

Software Engineering Institute

Management Buy-In
Buy versus build continuum
Want a cost-effective solution
Building blocks as a starting point

Buy

Build
Decision
point

120

Carnegie Mellon University

Software Engineering Institute

Buy A CM System Decision - 1
+ Saving development costs
+ Up-front cost known, including maintenance
+ Technology leverage and risk
+ Reliability – production quality (hopefully)
+ Documentation and training (at extra cost)
+ User group
+ Have a starting point and choices
+ Can evaluate company and expertise to a degree
121

Carnegie Mellon University

Software Engineering Institute

Buy A CM System Decision - 2
– Lack of control, ability, and timing of changes
– Lack of in-house expertise
– Must customize and adapt
– Must trust vendor for quality of system
– Vendor provides generic mechanisms, not solution
– Longevity of vendor
– 6 month technology evaluation and transition
– Need to guarantee upward compatibility
122

Carnegie Mellon University

Software Engineering Institute

Build a CM System Decision - 1
+ Meet unique needs (hardware, software, people)
+ Control over development and use of CM system
+ In-house expertise
+ Can match organization’s life-cycle model
+ Not necessary to evaluate third-party tools
+ Can use building blocks as starting point
+ Can ensure upward compatibility

123

Carnegie Mellon University

Software Engineering Institute

Build a CM System Decision - 2
– Difficult to estimate cost of development and
maintenance
– Enough resources
– Reinventing the wheel
– Continuous maintenance
– When to stop developing
– Maintaining in-house experts

124

Carnegie Mellon University

Software Engineering Institute

Commitment of Resources
People
Tools
Time
Money
Process
Policies

125

Carnegie Mellon University

Software Engineering Institute

Evaluation of CM Capabilities
Evaluate CM systems
Evaluations take time
Know your CM requirements
Know your process
Know your tradeoffs

126

Carnegie Mellon University

Software Engineering Institute

Technology Transition
Convincing employees to use CM
Fit the tool into the environment and organization
Dealing with a moving target
Technology maturation

127

Carnegie Mellon University

Software Engineering Institute

CM Services Model - 1
Addresses many of the issues

128

technology - client/server technology

process - grouping, tailoring services per process

standards - standard services

politics - tools that provide services

management - forecasting of effects of services

Carnegie Mellon University

Software Engineering Institute

CM Services Model - 2
Conceptual framework for a set of well-defined services
Service = a particular functionality that is treated as a
replaceable black box
Suit the marketplace’s need to apportion and distribute
functionality (client/server)
Well-defined = semantics, interface, and other
properties are understood well enough to be included in
reference models and implemented (alternative
mechanisms)

129

Carnegie Mellon University

Software Engineering Institute

Examples of CM Services
Repository service
Version control service
System modelling service
Manufacturing service
Derived object management service
Change boundary service
Change management service
Workspace service, etc.
130

Carnegie Mellon University

Software Engineering Institute

Questions
What is the CM boundary?
e.g., traceability on artifacts
When is a problem not a CM problem?
e.g., creating a new slide presentation
When is a solution not a CM solution?
e.g., transaction, attribution, life-cycle model
What part of the software engineering problem is CM?
e.g., team and process support, tool integration
131

Carnegie Mellon University

Software Engineering Institute

Conclusion - 1
CM systems exist and are evolving.
Organizations are trying to solve their CM problems.
A long-term CM solution that supports long-lived
changing applications for large organizations will not
be found in a single CM tool, nor an off-the-shelf
environment.
Presented the breadth of issues for CM systems
• approaching a CM solution
• requirements for CM systems
• concepts in CM systems
• past, present and future
132

Carnegie Mellon University

Software Engineering Institute

Conclusion - 2
The CM change process tends to be the focus of the
corporate process model.
CM functionality tends to be the pivotal point that
makes or breaks an environment.
Minimum CM capabilities
• inventory tracking (release management)
• change tracking (change management)
• history gathering (version control)

133

Carnegie Mellon University

Software Engineering Institute

Conclusion - 3
CM should not be viewed in isolation from other
software engineering problems and solutions.
Need to address in unison
• process modelling
• software architectures
• team support
• tool integration
• database repositories
CM is the keystone of software engineering.

134

Carnegie Mellon University

Software Engineering Institute

Further Contact
Susan Dart
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
USA
Fax: 412-268-5758
Phone: 412-268-6310
Internet: sad@sei.cmu.edu

135