CM Tutorial

Carnegie Mellon University
Software Engineering Institute
Configuration Management
Systems
Susan A. Dart
Ada Road Show Australia, May 18-27, 1992

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
Overview
Introduction to configuration management (CM) issues
Spectrum of concepts in CM systems
Past, present and future of CM systems
Survey
How many people
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?
Overview of Introduction
Definitions of CM and CM system

CM solution
Functionality requirements for CM systems
Kinds of CM systems
Summary of introduction
Definition of CM - 1
Standard definition (IEEE 729-1983)
Identification: identifying components, structure
Control: controlling releases and changes
Status accounting: recording, reporting status
Audit and review: validating completeness
Definition of CM - 2
Based on existing CM systems, broaden definition
Manufacture: managing construction, building
Process modelling: ensuring life-cycle model
Team work: controlling team interactions
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
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
Overview of Introduction
CM solution
Kinds of CM systems
CM Solution
CM plan
Planning
CM system
Management
Process
Automation
10
People
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
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
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
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. Arthurs Software Evolution - The Software Maintenance Challenge
Design Documents
Release
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
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 projects process
control - fit CM services with tools (whos in charge)
data - data management
16
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
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
enterprises way of business
no silver bullet for CM
buy or build
There are different views, roles, and expectations of CM.
18
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
Overview of Introduction to CM
CM Solution
Kinds of CM systems
20
Functionality Requirements
Roles, goals, responsibilities, and tasks of the different
users determine the functionality required of a CM
system.
21
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
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
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
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
Team Requirements
These synchronize and coordinate teamwork.
26
Workspaces: isolating work
Conflict resolution: resolving and merging changes
Families: developing related products
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
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
Accounting Requirements
These correlate facts about product and process.
29
Statistics: recording and generating statistics
Status determination: browsing status
Reports: generating reports
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
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
Overview of Introduction to CM
CM solution
Kinds of CM systems
32
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
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
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
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
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
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
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
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
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
Overview
42
Spectrum of Concepts in CM Systems
Descriptions and examples of concepts

Conclusion
43
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.
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
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
Overview of Concept Descriptions
Component functionality
Structure and construction functionality
Team functionality
Process functionality
47
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
Component Functionality - 1
Distributed
Component
Sherpa DMS*
Repository
RCS*
49
Component Functionality - 2
Addresses requirements
50
versions
configurations
repository
kinds of components
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
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
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
Distributed Component - 1
DEC
APOLLO
Centralized
File
Repository
54
SUN
Check out, check in

File format translation
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

Team functionality
56
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
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*
Structure and Construction

Functionality - 2
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
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
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
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
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
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
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
Templates
Verification rules
Version selection
Image
Construction rules
Executable objects
66
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
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
Derived Object Pool - 1

BCT
Derived object
with BCT
BCT
BCT
Pool
BCT
BCT
BCT
System Modelling
69
System Modelling

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

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
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
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
Consistency Maintenance - 1
Compiler
ld
cd
Compiler.V1.VAX
c
c
lc
lc
lc
id
FRONT
END
ld
lc
MIDDLE
END
FE.V1
BACK
END
FE.V2
Version
Logical component
Inheritable dependency
Configured
v
v
ME.V3.VAX
Consistent dependency
ld
cd
ME.V2.MC68K
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
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
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

Team functionality
77
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
Team Functionality - 1
Transaction
NSE*
Transparent
view
SMS*
Workspace
shape*
Object pool
* This system exemplifies the concept shown in the node

79
Team Functionality - 2
80
workspaces
- isolation of work
- concurrency control
conflict resolution
- merging changes in workspace and repository
families
- product versions across workspaces
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
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
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
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
Transaction - 1
Individuals 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
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
Overview of Concepts Descriptions

Team functionality
87
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
Process Functionality - 1
Context
Management
PowerFrame*
Life-cycle
Model CCC*
Change
Request
LIFESPAN*
Repository
Contract
ISTAR*
89
Process Functionality - 2
90
life-cycle support
- change and development process
task management
- tasks specific to context and processes
communication
- tasks and people
documentation
- automatic record
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
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 users need to remember context
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
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
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
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
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
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
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
Overview of Spectrum of Concepts

Concept descriptions
Conclusion
100
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
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
Conclusion - 3
Less frequently implemented
change set
subsystem
object pool
workspace
transparent view
transaction
attribution
consistency checks and maintenance
103
Overview
104
The Future of CM Systems

Where were we: the past
Where are we: the present
Where are we going: the future
Conclusion
105
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
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
Where Are We Going: The Future

Technology
Process
Standards
Politics
Management
108
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
Interoperability Between CM
Systems
RCS
SCCS
DSEE
110
CCC
System integration
Tool import/export
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
Global Perspective On Repositories

Home
Project A
RCS ...
112
Project B
RCS ...
Source...
RCS ...
Switching CM Services
Switches/options on CM system to suit
life-cycle phase
kind of application
kind of users
policies
risk factor
113
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
Process
Defining, implementing, enacting, using, monitoring
Need supportive implementations
Matching CM system with process
Roles
115
Standards
Standardization: frameworks, e.g., PSESWG
Project Support Environment Standards Working
Group for the U.S. Navys Next Generation Computer
Resources
Spanning fields and merging groups, e.g., CFI
Computer-Aided Design Framework Initiative
CM services model
Process of evolution
116
Process of Evolution
Research
Systems
Commercial
Systems
Many mechanisms
Concepts and
classification
Standardization
on frameworks/
infrastructures
117
Consolidation
of efforts
Definition of
services
Politics
Government requirement of process maturity level 3
What CM tools/capabilities are needed?
118
Management
Management buy-in
Commitment of resources
Evaluation of CM capabilities
Buy versus build in-house decision
Technology transition
119
Management Buy-In
Buy versus build continuum
Want a cost-effective solution
Building blocks as a starting point
Buy
Build
Decision
point
120
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
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
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 organizations life-cycle model
+ Not necessary to evaluate third-party tools
+ Can use building blocks as starting point
+ Can ensure upward compatibility
123
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
Commitment of Resources
People
Tools
Time
Money
Process
Policies
125
Evaluation of CM Capabilities
Evaluate CM systems
Evaluations take time
Know your CM requirements
Know your process
Know your tradeoffs
126
Technology Transition
Convincing employees to use CM
Fit the tool into the environment and organization
Dealing with a moving target
Technology maturation
127
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
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 marketplaces 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
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
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
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
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
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
Further Contact
Susan Dart
Pittsburgh, PA 15213-3890
USA
Fax: 412-268-5758
Phone: 412-268-6310
Internet: sad@sei.cmu.edu
135

CM Tutorial

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CM Tutorial

Uploaded by

Copyright:

Available Formats

Carnegie Mellon University

Software Engineering Institute

Ada Road Show Australia, May 18-27, 1992

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

are currently doing CM?

Carnegie Mellon University

Software Engineering Institute

Definitions of CM and CM system

Carnegie Mellon University

Software Engineering Institute

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

Manufacture: managing construction, building

Process modelling: ensuring life-cycle model

Team work: controlling team interactions

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Application Application reconfiguration

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Example of a Partial Process

Change Management System

Carnegie Mellon University

Software Engineering Institute

People: Who Has CM Needs?

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

The CM Solution is Complex - 1

Carnegie Mellon University

Software Engineering Institute

The CM Solution is Complex - 2

Technology addresses corrective and adaptive

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute

Carnegie Mellon University

Software Engineering Institute