Carnegie Mellon University

Software Engineering Institute

Configuration Management Services

Susan Dart
January 22, 1992 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U.S. Department of Defense
1

Carnegie Mellon University

Software Engineering Institute

Status of CM Services work

Past, Present and Future of CM paper Initial set of services Rational, benefits, goals Issues for research

Carnegie Mellon University

Software Engineering Institute

CM Adoption Issues
1. User roles (programmer, managers, tester,...) 2. Integration (process, toolset, database) 3. When to start using CM (before, during, after) 4. Control level (loose - tight) 5. Process and product 6. Automation level (manual - automatic) 7. System functionality (spectrum of concepts)
3

Carnegie Mellon University

Software Engineering Institute

CM Requirements
CONSTRUCTION Building TEAM Snapshots Optimization Change impact analysis Regeneration AUDITING History Traceability Logging Lifecycle support Task management Communication Documentation Access control Change requests Bug tracking Change propagation Partitioning CONTROLLING Workspaces Conflict resolution Families Versions Configurations Versions of configurations Baselines Project Contexts Repository Kinds of components COMPONENTS STRUCTURE System model Interfaces Relationships Selection Consistency

Statistics Status Reports ACCOUNTING

4

PROCESS

Carnegie Mellon University

Software Engineering Institute

CM Spectrum
Context Management Lifecycle Model
CCC* PowerFrame*

Transaction
NSE*

Distributed Component
Sherpa DMS*

Transparent View
SMS*

Change Request
LIFESPAN*

Workspace
shape*

Repository
RCS*

System Modelling
Jasmine*

Object Pool
DSEE*

Attribution
Adele*

Contract
ISTAR*

Change Set
ADC*

Subsystem
Rational*

Consistency Maintenance
CMA*

* This system exemplifies the concept shown in the node.

Carnegie Mellon University

Software Engineering Institute

Concepts categories
Component
Repository Distributed component

Structure, Construction
Change set System modelling Subsystem Object pool Attribution Consistency maintenance

Team
Workspace Transparent view Transaction

Process
Context management Contract Change request Lifecycle model

Carnegie Mellon University

Software Engineering Institute

Conclusion: The Past

Understanding of the CM problem: complexity Home-grown CM systems, if any Version control, build, change control CM was a private problem

Carnegie Mellon University

Software Engineering Institute

Conclusion: The Present

Lots of CM tools and some environments Difficult to find a CM solution SEI work: Understanding CM: vocabulary Spectrum of 15 concepts in CM systems Classification of developer CM systems Process maturity level classification Environment technology: integration problems Who owns the CM problem/solution?

Carnegie Mellon University

Software Engineering Institute

Conclusion: The Future

1. Technology issues 2. Process issues 3. Political issues 4. Managerial issues

Carnegie Mellon University

Software Engineering Institute

Conclusion: The Future-2

Technology issues: CASE tool coalitions and IPSEs 10% of CM solution is the technology Merging CM efforts with CAD and database fields New requirements: -Interoperability between CM systems -Preventative maintenance support -Global perspective on repositories -Switching CM services -Distributed CM system

10

Carnegie Mellon University

Software Engineering Institute

The Future - 3
Process issues: Defining, implementing, using, monitoring Matching CM system with process Roles

11

Carnegie Mellon University

Software Engineering Institute

The Future - 4
Political issues: Standardization: frameworks e.g., PSEWG Government requirement of process maturity level 3

12

Carnegie Mellon University

Software Engineering Institute

The Future - 5
Managerial issues: Management buy-in Commitment of resources Evaluation of CM capabilities Buy vs. build inhouse decision Technology transition

13

Carnegie Mellon University

Software Engineering Institute

CM Services Model
Addresses many of the issues: Technology: client/server technology Process: grouping, tailoring services per process Standardization: standard services Managerial: forecasting of costs of services

14

Carnegie Mellon University

Software Engineering Institute

Users who benefit

CASE vendors: vocabulary Customers: checklist for evaluating & choosing Tool integrators: discuss integration interfaces Environment builders: partial reference model Government organizations: verification base

15

Carnegie Mellon University

Software Engineering Institute

CM Services Model
Conceptual framework for a set of well-defined services Service = an abstraction representing a particular functionality Well-defined: semantics, interface, properties are understood enough framework reference models implemented, albeit different mechanisms

16

Carnegie Mellon University

Software Engineering Institute

Rationale
Takes into account the marketplaces need to apportion and distribute functionality Parts of CM solutions distributed throughout tools Portions = building blocks Services: plug in/plug out functionality

17

Carnegie Mellon University

Software Engineering Institute

Usage
Pick & tailor service re role for a process Implement and integrate Tie together process models and user roles: services independent of role and process

18

Carnegie Mellon University

Software Engineering Institute

Sources of Services;
Surveying concepts in CM systems -> implementable Determining how CM systems combine concepts to address particular needs Evaluating how to use various CM systems Examining market literature for CM requirements Recognizing roles that need to be supported Analysing user experience in building & customizing

19

Carnegie Mellon University

Software Engineering Institute

Issues for research

Mixture of viewpoints: end-user - pick and choose (change mgt) environment builder - tailoring (traceability) tool integrator - building blocks (RCS, make,ws) Definition of a service: semantics = meaning, capability properties = items of interest (interface) Intention: model encompass all imaginable CM capabilities services be minimal; no overlap; complement e.g., repository vs. version tree

20

Carnegie Mellon University

Software Engineering Institute

Research-2
Distinguish between: specification (definition) & instance (usage) service & mechanism Define architecture: effect of service tailoring of service usage process interface to service (integration) groupings/views meets which requirements (mgt vs. eng) various implementations how service span implementations complete list of services
21

Carnegie Mellon University

Software Engineering Institute

Research-3
Experiment: find services from extant implement some services integrate some services

22

Carnegie Mellon University

Software Engineering Institute

Questions
How to pick terminology? What is service criteria? What categories for grouping services? requirements based? role based? benefit based? What levels of abstraction for services? decompose services? What is similar work? ISO Reference model HP OO models what is a good model & definition of one?

23

Carnegie Mellon University

Software Engineering Institute

Examples of Services
CM repository: centralized db (PCTE) disjoint db (RCS) distributed db (Sherpa) source object System modelling (Jasmine) System model querying (Jasmine) System build (Jasmine) Derived object management (DSEE)
24

Version differentiation (diff)

Carnegie Mellon University

Software Engineering Institute

Services-2
Version binding (Jasmine) Version selection description(Adele, DSEE, Jasmine) Change boundary (Rational) Change management lifecycle (LIFESPAN) normal emergency fix (CCC) Audit trail Manual (vs. automated) service Workspace
25

Carnegie Mellon University

Software Engineering Institute

Services-3
Transaction Interoperability CM system Change control board CM plan Role filtering Snapshot Space optimization (delta, virtual copy, link) Change impact analysis
26

Carnegie Mellon University

Software Engineering Institute

Services-4
Regeneration: code (source, intermediate, object) context (pathname, workspace, tools) Relationship (Adele) Consistency management (CMA, Adele) Merging (NSE) Conflict resolution (NSE) Version identification Configuration identification
27

Carnegie Mellon University

Software Engineering Institute

Services-5
Release identification Project context (PowerFrame) Family identification (Jasmine, Adele) Access control Change request Change propagation (ADC) Change set (ADC) Contract (ISTAR)
28

Carnegie Mellon University

Software Engineering Institute

Services-6
Communication Notification Process definition Traceability Logging Statistics gathering Report generation Status indication
29

Carnegie Mellon University

Software Engineering Institute

Services-7
Attribution User assignment

30

Carnegie Mellon University

Software Engineering Institute

Conclusion
What is the CM boundary? e.g., traceability 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, lifecycle model What part of the software engineering problem is CM? e.g, team, process, integration, reference models

31