The following use cases should be addressed in the scope of the work for Change Management 3.0 and Configuration Management 1.0.


Cross-domain Baseline

The primary use case for the OASIS CCM TC is the creation and management of cross-tool, cross-domain configurations and baselines - that is, configurations and baselines composed of versions of resources from multiple applications that have might have multiple approaches to their own internal version and configuration management, and where those resources might be from more than one OSLC domain, or might not be defined by any current OSLC domain. A user needs to be able to:

Global Configurations

In a cross-tool, cross-domain environment, there may be multiple configuration management tools or systems involved. For example, a site may use a mix of SCM systems such as Rational Team Concert, Subversion, Git, etc., and may use other systems for change, requirements and quality management. A user needs to be able to:


Configuration Management Scenarios

Create a baseline

Modify and delete baselines

Manage streams

High-ceremony requirements-driven development

This scenario illustrates the way in which an immutable requirement specification is used to drive downstream development work.

  1. System engineer (RM) writes requirement specification, baselines it, gets it reviewed and signed off.
  2. [Optional] Sytem engineer responds to review comments and updates the specification. A new baseline containing those updates is created, and re-submitted for review and approval.
  3. [Optional] Unwanted baselines are deleted.
  4. Quality engineer (QM) works to a given requirement baseline, creating tests, and creates links from those tests to the requirements specification in the context of that baseline.
  5. # [Optional] QA provides feedback on the requirements (rework required; goto 1.1)
  6. Quality engineer creates a overall baseline consisting of all the requirements and all the tests, and all the links between same.
  7. Test necessity and sufficiency is assessed with respect to that requirements specification, in the context of this overall baseline.
  8. The baseline is published as an auditable workpackage/deliverable for that project.

Incremental Development Using Baselines

This scenario is a generalization of the previous one, “High-ceremony requirements-driven development”.

As a developer, I want to establish a configuration (work space, project, etc.) using my own resources under development plus one or more baselines of referenced resources. After some development and testing, I want to construct a baseline that represents my current state - making a baseline from my own resources and including the referenced baselines or resources from those referenced baselines. This process may be repeated by me; furthermore, other developers can use the baseline I established as the start for their incremental development.

Do parallel development, merging and reconciling conflicts

* More detailed use cases TBD

Track changes between configurations

When changes occur anywhere in our systems of systems, the development and management teams need to understand the reasoning for and impact of those changes. This includes answering these typical questions:

There are two different change traces that need to be done. The simple one is to determine what direct configuration items were changed since the last configuration (compare to a simple file diff pointing out rows that are different). For the more complex delta, a complete trace of changes in all versions that have been created of configuration items in the configuration (for each row that is different in the “file diff” we need to step through each version between these configuration items and find change data).

Create a maintenance release

* More detailed use case TBD

PLM Systems engineering change scenario

This follows the PLM Systems engineering change scenario and extracts CM related aspects of it. The scenario outline includes:

Assign & communicate the change request

As part of the development lifecycle, the team needs to be able to assign a context for addressing a set of related change requests. The actual change requests are created in that context. Notifications are sent to team members responsible owning, managing and/or governing the change request and associated iteration, release and/or project plans. Responsible stakeholders need to be able to access the change request in the right context from the notifications they receive.

There appears to be a number of contexts that might be associated with the change request:

  1. The context against which the issue is being reported. This is typically going to be some immutable configuration representing a product, component, or subsystem. For example, a defect might be reported against a component with release 1.0.
  2. A context representing the target in which the change will be delivered. For example, the fix for the defect in the previous entry might target release 2.0.
  3. A context representing the workspace in which the latest appropriate versions of resources are provided as a starting point for applying the change.

The first type of context is usually expected against a specific version of some configuration. This implies that CM providers must support URIs that always resolve to a specific versioned resource. We might use the term absolute resource version URI for this.

The third type of context is likely to represent a configuration whose versioned members are the latest according to some context. In the example, a configuration that has the latest delivered changes for release 2.0. This implies that CM providers might support a URI that represents the pair of a concept URI plus a context. We might use the term composite resource version URI. Is there a better term? Consumers of this data should not assume anything about semantics. Such a URI might literally composed of these two parts (concept+context), or might be simply an opaque URI. All that is required is that the underlying CM provider should be able to resolve that URI to reference the appropriate version of the concept resource.

The context might represent a number of tool or domain dependent forms. For a PLM tool, it is likely to include some notion of effectivity. For an SCM tool, it might include a release, or stream, or workspace.

Apply request context to establish impacted requirements & implementation

During change and impact analysis, as well as development and quality management activities, team members need to be able to locate requirements in the right context. New versions of requirements may need to be created, and these may need to be done in a separate, related, or branched context. Other team members will then see the new revision in the proper context.

Some of the steps in the PLM Systems engineering change scenario imply a capability to perform a check out to create such a new version, and be able to reference that new version in other resources, such as a change request. This raises some interesting questions:

PLM Reference model and scenario

PLM Reference model and scenario

Deferred Use Cases

The following use cases may be valid, but are not addressed in the scope of the work for Change Management 3.0 and Configuration Management 1.0.

CCMUseCases (last edited 2015-10-30 17:20:53 by ndjc)