Cross-domain Baseline
The primary use case for this workgroup 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
- Identify the version of a given resource within the context of a configuration
- Establish a baseline (snapshot) of a configuration
- Describe the contents of a configuration in terms of sets of changes with respect to some other configuration
Legacy Scenarios from Core Workgroup
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.
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 the properties of a baseline, and link that baseline to 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.
Control the use of a baseline, component-based development
As a software 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 software developers unless they explicitly choose to do so. Once the library has passed testing, we need to be able to mark the baseline as suitable for general use
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.)
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
As a user of baselines, I need to be able to decide which baseline or version of a baseline to use as a sub-component, library, or similar dependency (possibly within limits and policies determined by the process owner)
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 this 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.
Compare baselines
As a test engineer, I want to be able to see the new change sets included in a baseline wrt the baseline I tested last week, and I want to be able to trace those change sets back to any associated defects or requirement changes.
As a creator or user of baselines, I need to be able to compare two baselines, or the current state of the system vs. a baseline, and get a report of the differences, tracking those differences back to their root causes across multiple SCM domains
