dart configuration management services

8/2/2019 Dart Configuration Management Services

1/31

1

Carnegie Mellon University

SoftwareEngineeringInstitute

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

January 22, 1992

Sponsored by the U.S. Department of Defense


2/31

2



Past, Present and Future of CM paper

Initial set of services

Rational, benefits, goals

Issues for research


3/31

3



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)


4/31

4



CONSTRUCTION STRUCTURE

CONTROLLINGACCOUNTING

AUDITING

TEAM

PROCESS

BuildingSnapshotsOptimizationChange impact analysisRegeneration

System modelInterfacesRelationshipsSelectionConsistency

VersionsConfigurationsVersions of

configurationsBaselinesProject ContextsRepository

Kinds of components

WorkspacesConflict resolutionFamilies

HistoryTraceabilityLogging

StatisticsStatusReports

Access controlChange requestsBug trackingChange propagationPartitioning

Lifecycle supportTask management

CommunicationDocumentation COMPONENTS


5/31

5



SystemModelling

ObjectPool

ChangeRequest

ContextManagement

DistributedComponent

Contract ChangeSet

Subsystem

Attribution

ConsistencyMaintenance

Workspace

TransparentView

Transaction

PowerFrame*

Sherpa DMS*

RCS*

LIFESPAN*

ISTAR*ADC*

NSE*

SMS*

DSEE*

CMA*

shape*

Jasmine*

Rational*

Adele*

* This system exemplifies the concept shown in the node.

LifecycleModel

CCC*

Repository


6/31

6



Component Structure, Construction

Team Process

RepositoryDistributed component

Change setSystem modellingSubsystem

Object poolAttributionConsistency maintenance

WorkspaceTransparent viewTransaction

Context managementContractChange requestLifecycle model


7/31

7



Understanding of the CM problem: complexity

Home-grown CM systems, if any

Version control, build, change control

CM was a private problem


8/31

8



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?


9/31

9



1. Technology issues

2. Process issues

3. Political issues

4. Managerial issues


10/31

10



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


11/31

11



Process issues:

Defining, implementing, using, monitoring

Matching CM system with process

Roles


12/31

12



Political issues:

Standardization: frameworks e.g., PSEWG

Government requirement of process maturity level 3


13/31

13



Managerial issues:

Management buy-in Commitment of resources

Evaluation of CM capabilities Buy vs. build inhouse decision Technology transition


14/31

14



Addresses many of the issues:

Technology: client/server technology

Process: grouping, tailoring services per process

Standardization: standard services

Managerial: forecasting of costs of services


15/31

15



CASE vendors: vocabulary

Customers: checklist for evaluating & choosing

Tool integrators: discuss integration interfaces

Environment builders: partial reference model

Government organizations: verification base


16/31

16



Conceptual framework for a set of well-defined services

Service = an abstraction representing a particularfunctionality

Well-defined: semantics, interface, properties areunderstood enough framework reference models implemented, albeit different mechanisms


17/31

17



Takes into account the marketplaces need to apportionand distribute functionality

Parts of CM solutions distributed throughout tools

Portions = building blocks

Services: plug in/plug out functionality


18/31

18



Pick & tailor service re role for a process

Implement and integrate

Tie together process models and user roles: servicesindependent of role and process


19/31

19



Surveying concepts in CM systems -> implementable

Determining how CM systems combine concepts toaddress 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


20/31

20



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


21/31

21



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


22/31

22



Experiment: find services from extant implement some services integrate some services


23/31

23



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?


24/31

24



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)

Version differentiation (diff)


25/31

25



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


26/31

26



Transaction

Interoperability CM system

Change control board

CM plan

Role filtering

Snapshot

Space optimization (delta, virtual copy, link)

Change impact analysis


27/31

27



Regeneration: code (source, intermediate, object) context (pathname, workspace, tools)

Relationship (Adele)

Consistency management (CMA, Adele)

Merging (NSE)

Conflict resolution (NSE)

Version identification

Configuration identification


28/31

28



Release identification

Project context (PowerFrame)

Family identification (Jasmine, Adele)

Access control

Change request

Change propagation (ADC)

Change set (ADC)

Contract (ISTAR)


29/31

29



Communication

Notification

Process definition

Traceability

Logging

Statistics gathering

Report generation

Status indication


30/31

30



Attribution

User assignment


31/31

31



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

dart configuration management services

Documents