From: anderson@bigun.enet.dec.com (Keith J. Anderson)
Subject: SEI speaker on Configuration Management
Organization: Digital Equipment Corporation (Australia)
Date:  8 SEP 92 14:35:27    

In May, the International Conf on Software Eng was held in Melbourne Australia.
Unfortunately time and cost pressures kept me from attending. I was however
lucky enough to be able to attend a seminar organised by the local Ada
Association that took some of the speakers from ICSE around Australia. 

One of the speakers was Susan Dart from Software Engineering Institute at
Carnegie Mellon University, who spoke on configuration management. The
following is from my notes, but I cannot explain my notes now after so
long. I imagine a copy of her longer ICSE talk is in the Proceedings.

She identified 15 different kinds of CM concepts. She has done a study of most
common CM tools, but not all. She made the point early that any strong CM
toolset is going to take at least 6 months to come productive with.

She listed the following as examples: CMS (DEC), Compass (CMPAC),
DMS (Sherpa), DSEE, EAST (SFGL), Enterprise II, Endeavor, Gandalf, ADC, Adele,
AmplifyControl, CADEX, CCC, Cedar, CMA, CMF, ISPW, ISTAR, Jasmine, Librarian,
LIFESPAN, Maestro, NSE, PACT, Panicm, Panvalet, PCMS, Powerframe, PVCS,
Rational, RCS, SCCS, SCLM, shape, SLSCE, SMS, Softboard, Supercase, Teamnet,
Teamwork.

    She broke CM requirements down into 8 functionality areas:
    - Components
    - Structure
    - Construction
    - Auditing
    - Accounting
    - Controlling
    - Process
    - Team
    and then went through each listing the key requirements in each. The
    talk ended looking at CM directions being towards providing CM
    Services, where a Service is a particular functionality that is treated
    as a replaceable black box, and well-defined (semantics, interface,
    and other properties included in reference models).

    She saw Repository service as being one of the CM services, Version
    Control another, etc..

    Component Requirements: identify, classify, and access components:
    . components
    . versions
    . configurations
    . versions of configurations
    . baseline
    . project contexts
    . repository
    Structure Requirements
    . system model
    . interfaces
    . relationships
    . selection
    . consistency
    Constructure
    . building
    . snapshots
    . optimisation
    . change impact analysis
    . regeneration
    Team
    . workspaces
    . conflict resolution
    . families
    Controlling
    . access control
    . change requests
    . bug tracking
    . change propogation
    . partitioning
    Auditting
    . history
    . traceabilility
    . logging
    Accounting
    . statistics
    . status determination
    . reports
    Process
    . lifecycle support
    . task management
    . communication
    . documentation

    Team and Process "integrate" all requirements


    The CM concepts areas that have developed with CM systems are:

    Concept			example

    Repository			RCS
    Distributed Component	Sherpa DMS
    Change set			Aide-De-Camp
    System modelling		Jasmine
    Subsystem			Rational
    Object Pool			DSEE
    Attribution			Adele
    Consistency maintenance	CMA
    Workspace			shape
    Transparent view		SMS
    Transaction			NSE
    Context management		Powerframe
    Contract			ISTAR
    Change Request		LIFESPAN
    Lifecycle model		CCC

    The different CM concept areas that have evolved can be mapped to her
    requirements areas, in terms of primary focus?:

    Component			Structure, Construction

    Repository			Change set
    Distributed Component	System modelling
    				Subsystem
    				Object Pool
    				Attribution
    				Consistency maintenance


    Team			Process

    Workspace			Context management
    Transparent view		Contract
    Transaction			Change Request
    				Lifecycle model


No single CM system provides all functionality, Some systems provide many
concepts, CM systems seem to be approaching a common model. Mechanisms poorly
implemented: version control, logging for an audit trail, system modelling,
baseline, email for communication, notion of a configuration, change request.
Less frequently implemented : change set, subsystem, object pool, workspace,
transparent view, transaction, attribution, consistency checks and
maintenance. 

Standards : Project Support Environment Standards Working Group, for the US
Navy's Next Generation Computer Resources, CAD Framework Initiative, 

    "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. Min CM capabilities: inventory tracking (release
    mgmt), change tracking (change mgmt), history tracking (version
    control)."

    Also refer to Mickey Williamson "Automated Software Configuration
    Management: Issues, technology and Tools", Cutter information group,
    1990; Fletcher, Backley, "Configuration Management Hardware, Software
    and Firmware" IEEE Computer Society Press 1990.

-------------------------------------------------------------------------------
EM: anderson@bigun.enet.dec.com		Keith J. Anderson
or  anderson%bigun.enet@decwrl.dec.com	CASE and Information Management  
Phone: (+61 6) 2754800			Digital Equipment Corp (Aust) P/L
FAX  : (+61 6) 2473654			7 Barry Drive, Turner ACT 2601 AUSTRALIA
X.400: c=au;a=otc;p=digital;o=digital;ou=sno;s=anderson;g=keith
***** My words are not those of my employer *****
Newsgroups: comp.software-eng