Use Cases for OASIS OSLC CCM TC
The following use cases should be addressed in the scope of the work for Change Management 3.0 and Configuration Management 1.0.
Use Cases for OASIS OSLC CCM TC
- Cross-domain Baseline
- Global Configurations
- Configuration Management Scenarios
- PLM Systems engineering change scenario
- Deferred Use Cases
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:
- Create and update configurations that capture complex, related information at some point in time from multiple tools
- Identify the version of a given resource within the context of a configuration
- Establish a baseline (snapshot) of a configuration
- Create and merge parallel development branches
- Manage product line variability
- Reuse components with known provenance and quantifiable quality
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:
Define global configurations that assemble, contain, or otherwise reference configurations managed by more than one configuration management tool; the referenced configurations are called contributions
- Edit a global configuration, adding or removing one or more contributions, or replacing a contribution with a different version or variant
- Use these global configurations to resolve links between artifacts in all the other OSLC Configuration Management scenarios
- As a user, I need to run reports on items in the content of a configuration (including its recursive contributions)
- As a user, I need to compare configurations
- As a user, I need to find which configurations use a particular version of a resource
Configuration Management Scenarios
Create a baseline
- As a software developer, I need to record the exact state of my SCM configuration for building a library that will be used by other software components, including the right header files, the binary build artifacts for various platforms, the README or release notes, etc.
- As a requirements manager, I need to record the exact state of my fighter jet requirements following a review by the Air Force. Since requirements may change, I need this snapshot to be available at any time later, so we can review what the Air Force has or has not yet approved. Links between my requirements must be included in the snapshot.
- (Generic wording) As a user of a system, I need to treat a thing (resource, metric, etc.) or collection of things as a related group, and I want the system to record and/or freeze a copy at some point in time, or (for resources that are versioned in some way by their provider) record the version of the resource at that time. The state of links between resources must also be captured.
Modify and delete baselines
- As a release manager, I need to make a formal release of a software product. The previously created baseline for the tested final build of the product should be marked and preserved, adding appropriate version numbers and comments to the updated baseline. After that, I want to delete several previous test and published baselines for earlier intermediate states of this new product release, and the associated intermediate versions of build artifacts, in order to save space and speed up future queries.
- As a baseline manager, I need to be able to modify some of the properties of a baseline, and link to that baseline from other resources such as test results.
- As a baseline manager, I need to be able to delete or mark obsolete old and unused baselines, so they do not affect users’ operations and queries.
- As a configuration manager, I need to be able to create a new stream branching off my current development or some baseline to start development of a new variant or release
- As a configuration manager, I need to be able to create a new stream branching off my current development or some baseline, where I will make or merge in limited or controlled changes to stabilize and then publish a new release of my product.
- As a configuration manager, I need to be able to decide which baselines or streams to use as contributions to my stream, for any sub-components, libraries, or similar dependencies
High-ceremony requirements-driven development
This scenario illustrates the way in which an immutable requirement specification is used to drive downstream development work.
- System engineer (RM) writes requirement specification, baselines it, gets it reviewed and signed off.
- [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.
- [Optional] Unwanted baselines are deleted.
- 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.
- # [Optional] QA provides feedback on the requirements (rework required; goto 1.1)
- Quality engineer creates a overall baseline consisting of all the requirements and all the tests, and all the links between same.
- Test necessity and sufficiency is assessed with respect to that requirements specification, in the context of this overall baseline.
- 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:
- Why was the new configuration assembled?
- What was done since the predecessing configuration, who did it and why?
- What problems have been solved from an old configuration to the current one?
- What features have been added from an old configuration to the current one?
- When is a configuration “good enough” for us to release (planned changes are implemented) or be built?
- What is the “newest and best” configuration?
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:
- 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.
- 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.
- 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:
Is an OSLC Configuration Management provider required to support initiating the check out to create the new version? For example, a POST to the current immutable version might create a new version. Or would it be sufficient in phase 1 to support an appropriate link type but require that the user use the versioning tool to initiate the check out?
- Should a Configuration Management provider support a delegated UI to allow a link to/from another resource to be created and stored on the configuration item?
What about versioning tools for which check out does not create a new version but rather creates some kind of lock? Such tools might only create a new resource on check in.
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.
- Describe the contents of a configuration in terms of sets of changes with respect to some other configuration
- As a developer, I need to be able to mark my new library baseline as available to the testing group, but I do not yet want the new library to be picked up by other developers unless they explicitly choose to do so. Once the library has passed testing, I need to be able to mark the baseline as suitable for general use.
- As the process owner, I need to be able to set rules for when new baselines or new versions of baselines are picked up by the users of my system.
- (Generic wording) As a user of a system, I need to announce and/or control the availability of a collection of resources to some audience (such as a testing group, or another development group using component assembly, etc.).