Organizing components

Edit online

You can divide the artifacts in a project among multiple pieces called components. Each component is like a building block that represents a physical or logical part of your project. Components are smaller collections of artifacts that can be reused easily or delivered on independent schedules or to other teams.

Before you begin

About this task

Although IBM® Engineering Lifecycle Management applications have ways of grouping artifacts into smaller collections, such as IBM Engineering Requirements Management DOORS® Next modules and folders and Engineering Test Management test suites and test plans, you can’t easily mix and match them, reuse them, or deliver them independently.

For example, managing configurations requires more attention if Team1 wants to work with Stakeholder Requirements Baseline 1 and Functional Requirements Baseline 1, but Team2 wants to work with Stakeholder Requirements Baseline 2 and Functional Requirements Baseline 1.

You can divide the different requirement types into separate components so that you can mix and match them, and deliver them independently.

Consider using separate components for sets of artifacts when you’re in these situations:

  • The collection of artifacts is intended for reuse in more than one larger assembly: more than one product or product variant, or in more than one place in a complex product or system. Examples: an engine control unit that is used in both X (old) and Y (new) models of a car; a screen used for a car’s navigation system and its infotainment system.
  • The collection of artifacts is delivered to another party as a separate delivery. Examples: delivering an updated radio component to the team working on the luxury model of a car; delivering a radio component to a third-party vendor so they can add proprietary satellite technology.
  • The collection of artifacts is delivered by a separate team, or on a different cadence.
  • The collection of artifacts has a separate delivery cycle (such as different test stages or approval cycles) .

For each Engineering Lifecycle Management application, carefully plan which components to create to ensure flexibility in assembling products and their variants. If you don’t plan, you will encounter problems when you assemble the components into hierarchies that represent products and their variants.

This topic follows the example of a car, which includes both physical pieces and software including an engine, sunroof, infotainment system, brakes, and so on.

Components are smaller collections of artifacts

Before version 6.0.3, the project area was the container for artifacts. You couldn’t divide a project into smaller pieces. Each configuration (stream or baseline) in the project contained one version of each artifact in the project. Continuing with the car example:
  • Each configuration in an DOORS Next Car project contained a version of all the stakeholder, safety, performance, and environmental compliance requirements
  • Each configuration in a Engineering Test Management Car project contained a version of all the safety, performance, and environmental compliance tests
And so on.

If you wanted smaller collections of project artifacts, you had to create projects to correspond with each collection, which had much administrative overhead.

A component is the container for artifacts. The ability to divide a project into components gives you these benefits:
  • It’s easier to create versions and variants of a product or system by reusing its parts. You can quickly respond to market demands or changing regulations in different geographies.

    Example: While developing a luxury car with seat heaters and all-wheel drive that can withstand a harsh climate, you can quickly respond to a market shift that demands a simpler, less expensive car with fewer automated systems and sensors, and a different combination of existing parts.

  • Teams can work independently on different components on different schedules. They can develop and deliver new features or fixes without affecting other teams working on other components.

    Example: Replace a non-IoT fuel sensor with one that sends IoT data on fuel consumption back to engineers. High consumption rates might indicate a problem that must be fixed; engineers can then develop and deliver the fix to reduce overall fuel consumption. The teams working on other parts of the car (infotainment, sunroof, and so on) are not interrupted and forced to update the stream (version of the car) they are working in.

Team members with administrative roles define and create components

In Engineering Lifecycle Management applications (DOORS Next, Engineering Test Management, Engineering Workflow Management, administrators create components. In the GCM application, a configuration lead typically creates components. On the Permissions page in the application administration section, see the Configuration Management group for the permissions related to managing components and configurations, and assign those permissions based on your project needs.

Use components to organize the artifacts in your project

After you create a project in the GCM and Engineering Lifecycle Management applications, follow these high-level steps to use components to organize the logical and physical pieces of your project.

Procedure

  1. Design and create components.
    1. Plan the components your project needs by thinking about the building blocks that make up your product or system. You must plan them so that components do not share artifacts, or, overlap. You’ll see an example later in this topic.
    2. Organize any existing artifacts into the new components. In the DOORS Next and Engineering Test Management applications, this action is called cloning, and is described later in this topic. If you clone shared artifacts into separate components to avoid overlap, remember that in the DOORS Next application, you can link between artifacts in different components.
    3. For each component, create the configurations (streams and baselines) that teams need to do their work. Each configuration of the component contains one version of each artifact in that component.
  2. Assemble the relevant configurations of components to build the product or variant that you need. Typically, a GCM configuration lead does this step.
    1. Create the global configurations for the project.
    2. Add the appropriate local configurations of components to the global configurations, to build the hierarchy of configurations components for the project in the GCM application

Design and create components

Edit online

About this task

Consider the building blocks that your project needs. For example, in an DOORS Next project for a Car, you might have several types of requirements: stakeholder, safety, performance, environmental compliance. Each of these types might be in their own module. You might decide to create a component that corresponds with each module.

You can always create more components later if you need more building blocks, and reorganize the artifacts again by cloning them into the new components.

When you clone artifacts from one component to another, to prevent team members from using the incorrect versions of artifacts, consider archiving the component you clone from.

Plan components so they don't contain the same artifacts

Edit online

About this task

Each project artifact can be in only one component. When two components contain any version of the same artifact, they overlap. You cannot add configurations of those components to the same global configuration, and this might prevent you from building the version or variant that you need.

Consider a requirements project in which you’ve created finer-grained components and organized the requirements from the initial project so that the new components contain the following artifact versions:
  • Component A: requirement1-v1, requirement2–v1, requirement3–v1
  • Component B: requirement1-v2, requirement4–v1, requirement5–v1
  • Component C: requirement5-v2, requirement6–v1
  • Component D: requirement1-v3, requirement7–v1
  • Component D overlaps with A (both have versions of requirement1)
The following components overlap:
  • Component A overlaps with B and D (all have versions of requirement1)
  • Component B overlaps with A and C (B and A contain versions of requirement1; B and C contain versions of requirement 5)
  • Component C overlaps with B (both have versions for requirement5)

As component A overlaps with B, and B overlaps with C, does not imply that A overlaps with C. Using the car example, you might have different categories of requirement: safety, performance, stakeholder, and environmental compliance, but some requirements belong to multiple categories: “Airbags must finish deploying within 0.025 seconds” might be considered both a safety and performance requirement. To avoid overlap you must add it (by cloning it) to only one component.

You can’t add configurations of overlapping components to the same global configuration, so it is difficult to build versions and variants of a product. Reconsider either the components you’ve defined or how you’ve assigned artifacts to each component.

Preventing the overlap. You might organize the artifacts this way instead:
  • Add requirement1 to component D only
  • Add requirement5 to component C only
The components now contain these artifacts:
  • Component A: requirement2–v1, requirement3–v1
  • Component B: requirement4–v1
  • Component C: requirement5-v2, requirement6–v1
  • Component D: requirement1-v3, requirement7–v1
If you later decide that requirement1 should be in component A, you can clone it into that component, but you’ll have to fix the new overlap between A and D. Here’s how:
  1. Create another component named E.
  2. Clone requirement7 from component D to component E.
  3. Archive component D so that its artifacts are no longer visible to team members.
Your components now have the following artifacts. When you clone an artifact, it creates a new version of it in the stream you clone into.
  • Component A: requirement1-v4 (cloned requirement1-v3 from Component D), requirement2–v1, requirement3–v1
  • Component B: requirement4–v1
  • Component C: requirement5-v2, requirement6–v1
  • New: Component E: requirement7–v2 (cloned requirement7-v1 from component D)
  • Archived: Component D: requirement1-v4, requirement7–v1 (archived to remove the overlap with Component A)
Even though these are general guidelines, DOORS Next and Engineering Test Management have a few differences to consider when you organize your artifacts into components as described in the next step.

Organize existing artifacts and link to shared artifacts across components

Edit online

About this task

You can create links between artifacts in different requirement components. For example, if two modules share a requirement, you can clone the shared requirement into its own component to prevent overlap, but still link that artifact to its related artifacts that are in other components.

Continuing with the car example, assume an initial project-level component in an DOORS Next project named Car, which has the following artifacts:
  • Module A: includes requirements R1, R2, and R-shared
  • Module B: includes requirements R3, R4, and R-shared
You decide to create components to correspond with each module. If the global configuration that represents a future version or variant of the car might need configurations of both modules, consider cloning R-shared into its own component; otherwise, you won’t be able to add a configuration of Module A and Module B to the same global configuration. The following steps elaborate on this example.

Procedure

  1. In the DOORS Next Car project, a configuration lead defines finer-grained components for this project: Safety, Performance, and Environmental. Each component contains an empty initial stream.
  2. In the GCM application, a configuration lead creates a Car project. He then creates finer-grained components such as Car High-Performance model, Engine, Infotainment System, Sunroof, and so on. Each component contains an empty initial stream.

    The team is currently building a product named “Car High-Performance model”. The GCM configuration lead completes these steps:

    1. Open the Car High-Performance model initial stream.
    2. Build the configuration hierarchy for the Car High-Performance model variant: He adds the initial stream of each of the Safety, Performance, and Environmental components from DOORS Next.
  3. An DOORS Next configuration lead reorganizes the artifacts in the DOORS Next Car project. He starts by cloning Module A from the Car project-level component to the new Safety component.
    1. He clones R1 and R2 into the initial stream of the Safety component.
    2. He clones R-shared into the Environmental component, to prevent overlap between the Safety and Performance requirements.
      At this point, the following components overlap:
      • Project-level component and the Safety component
      • Project-level component and the Environmental component
      The GCM configuration lead cannot add configurations of the overlapped components to the Car High-Performance model global configuration.
  4. The DOORS Next configuration lead continues to reorganize artifacts by cloning Module B from the Car component to the Performance component.
    1. He clones R3 and R4 into the initial stream of the Performance component.
  5. He creates the links from the R-shared artifact in the Environment component to its related artifacts in the other components.

Results

At this point, the project-level component overlaps with the new Safety, Performance, and Environmental components. The GCM configuration lead cannot construct the Car High-Performance model stream to contain configurations from the project-level component and any of the Safety, Performance, or Environmental components.

To remove this restriction, the DOORS Next configuration lead should clone all the artifacts from the project-level component into finer-grained components, and then optionally archive the project-level component to prevent team members from accessing the wrong versions.

Create the configurations (streams and baselines)

Edit online

About this task

After any existing artifacts are organized into components, the DOORS Next configuration lead can create the local streams and baselines that teams need to work on the correct versions of the artifacts. For teams to get a holistic view of all the artifacts in a project, and to see and create links between artifacts in other Engineering Lifecycle Management applications, they must work in a global configuration context.

Building the global configuration hierarchy

Edit online

About this task

After components and configurations are created, and the artifacts are organized into the correct components, teams can work on the artifacts and configurations for the version or variant.

The GCM configuration lead works with the DOORS Next (and other Engineering Lifecycle Management) configuration leads to build and maintain the hierarchies that teams need for the versions and variants of the product.