Terminology and concepts

The terms and concepts that are used in this tool are defined and illustrated here. More terms and concepts that are specific to other tools are described briefly here, with links to detailed descriptions in other Rational® product documentation.

If you are an existing customer that upgraded to the latest release, certain terms changed. For a map of old terms to new terms, see Terminology changes. This document uses the new terms.

The following terms and concepts are ordered so that information builds from the most simple terms and concepts to detailed explanations that combine terms and concepts.

Artifacts: A general term for the objects in a repository. Artifacts include products and objects that are created and maintained in other tools, such as Rational Team Concert™ work items and Rational DOORS® requirements.

Products: Visually represent work your team is focused on. A product can be as large as a car or as small as a mechanical heart valve. A product can have no or more child products and child product configurations. Products know their immediate child products, but not their versions. The product configuration that the product is a member of determines the version of the child products and child product configurations that it contains.

Products can contain child configurations, which can contain child configurations and child products. Child products also can contain child configurations and child products.

Products display in the Browse Products screen, in a tree view.

"Browse Products" screen shows a product configuration with child products.

Teams can change the term products to a term accepted in their organization. After the term is changed and saved, and users refresh their session, the custom term is used in menus, dialog boxes, and messages.

For information about using products, see Working with products and Managing product hierarchies.

Product configurations: Represent a collection of versions of products and child configurations that make up a product tree. A product tree is always viewed in the context of a product configuration. The product configuration determines which versions of products and child product configurations are used. A product configuration can have no or more child products and child product configurations.

See Using product configurations.

Product configuration grouping: Collects like product configurations into meaningful groups for you or your team. You can group product configurations in any way you want, by date (month, year), by milestone (beta, general), by feature (laser printers, inkjet printers), and so on. Product configuration groupings are displayed in the Browse Products list box.

Property: A piece of descriptive information about an artifact, such as a product. A property has a type, for example, name or value. For example, a product that is called dashboard might have a property name of material with a value of walnut.

Lifecycle Query Engine: An index of data that can be queried. The data is retrieved from data sources that implement the tracked resource set (TRS), such as products from Rational Engineering Lifecycle Manager, work items from Rational Team Concert, requirements from Rational DOORS, and other tools.

Link: Represents a reference to another artifact. The link might be stored in another tool, such as Rational Team Concert, Rational DOORS, or on a product.

Branch: A variant of a product. A variant is created when a team must change the same product in different ways or independently of each other. After branching a product, teams can make parallel changes.

For example, your team created a blood pressure cuff for adults and is ready to work on the same product for juveniles. The team would create a variant of blood pressure cuff and call it blood pressure cuff (cuffsize=juvenile).

Only products can be branched. Configurations cannot be branched.

For information about creating and replacing product branches, see Replacing a branch.

Dimensions: A dimension describes how a product configuration or product branch is unique by defining its aspects. A dimension consists of a name, such as cuffsize, and a value, such as juvenile, which displays after a product name: (cuffsize=juvenile).

When you set dimension and value pairs for a product configuration, the pairs determine the versions of all the products in that configuration. A configuration can specify only a single value for a dimension. Typically, each configuration has a unique combination of dimensions and their values.

A product branch is defined by its unique set of dimensions. A dimension for a product (product-local dimension) usually defines a specific aspect of a product branch, such as a dimension name of car_lock and value of infrared. A shared dimension usually defines a general aspect of a product configuration or product branch, such as a dimension name of year and value of 2017.

You can manage product-local and shared dimension by using the Manage Branch Dimensions screen. (Products > Manage Dimensions) For information about how dimensions and values are ranked, see Dimension values precedence.

Baselines: Non-modifiable product configurations. A baseline is created from a modifiable product configuration and represents the state of that product configuration when the baseline was created. Baselines typically represent the state of a product tree at important milestones in product development.

Teams usually create baselines to mark a milestone, for example, a weekly build, a beta release, or a general release.

The image shows several baselines of the Wiring configuration, which is at a milestone called sprint 3. Notice that the Wiring-3 child product was updated in sprint 2 to add copper. Wiring-4 was updated in sprint 3 to add titanium. A team that must roll back to exclude a previous child product, for example, titanium, could do so by replacing a version.

Image shows several baselines of the "Wiring" configuration.

For information about creating a baseline and creating a modifiable copy, see Capturing a milestone.

Version: Represents a specific state of a product or product configuration.

Each version of a product and product configuration has a version number that is unique across all the versions of that product or product configuration.

For information about creating and replacing product versions, see Replacing a version to roll back to a milestone.

Audit: Examines the changes that were made to the selected product and then displays the results in a table to the right of the products tree.

Image of an audit, showing the users who changed the product, what and when changes were made, and the name of the products that were added, imported, or removed.

For information about viewing the audit log, see Showing who changed a product.

Audit history: The Audit History screen visually presents all versions and branches of a product. The example shows a version that is called Model_T-3. The audit history shows relevant metadata: the user who changed the product, what and when changes were made, and the name of added, imported, and removed products. The latest version displays at the top of the column. When a product is branched, the branches are shown in a new column.

Image shows the Audit History screen.

For information about audit history, see Viewing audit history.

Hierarchy: A pyramid-like ranking of product configurations and products. View hierarchies in the product tree in the Products screen.

Move: To physically relocate a configuration or product under a different configuration or product. You can move a configuration or product from one location to another in the product tree. For example, the Deluxe Rims product was in the Wheels (Rims=chrome) product. The placement was incorrect, so Deluxe Rims was moved to a luxury car brand. Additionally, if Deluxe Rims had a hierarchy beneath it, the hierarchy would move with Deluxe Rims.

You can view the movement of products by looking at their audit history. The image shows that Deluxe Rims started out in Wheels (Rims=chrome), but was later removed.

Image shows the audit history of the "Wheels" product, which user moved the product, and when it was moved.

To learn more about where Deluxe Rims was moved, you could compare versions, which would show you information about products that were added to and removed from the target product.

For information about moving products, see Manipulating configurations and products.

Reuse: To use again. You can reuse a configuration or product in the same configuration or product and in other configurations or products. You can also reuse configurations or products multiple times in the same configuration or product, and the configurations or products you are reusing are the exact same one, just reused. When you reuse a configuration or product, they both include their child configurations or products.

The image shows the Body-2 product expanded. The Body-2 product is used in two different configurations, allowing mirror-2 to be reused. The convenience is that if you change one reused product, for example mirror-2, the change is propagated to both uses.

Image shows that the "mirror-2" product is reused in two different configurations.

For information about reusing products, see Manipulating configurations and products.

Replace: To take the place of. Versions can be replaced by former or newer configurations or products. Product branches can be replaced by former or newer product branches. Replacing a version or branch is useful when a team must replace a current broken artifact with a previous working artifact.

For information about versions and branches, see Versions and variants.

Views: Visual representations of the development lifecycle. The standard views are described in Sample views overview, including the V Process view.

V Process is a visual representation of a systems development lifecycle. Many systems development processes exist, such as agile, waterfall, and V Process methodologies. The V Process represents a common information traceability model.

Visually, the information is divided between the two sides of the V. The left side shows tasks that are driven by product definition, such as creation of concepts, requirements, architecture, and design. The right side shows tasks that are driven by product testing and integration, such as system verification and validation, and integration, test, and verification. The verification and validation on the right of the V can be completed simultaneously with the product definition steps on the left side of the V.

Because teams participate in early product verification and validation, teams find defects in early development stages and therefore avoid the downward flow of defects. Finding defects early reduces the cost of fixing the defects. Additionally, early validation and improved communication between team members ensures that your quality standard is met.

The V Process does not depend on any particular organization scheme, so each team can tailor the V Process for their product. The Shared Views page contains sample V Process views for hardware and software development.

This image shows an example V Process hardware view.

For information about views, see Creating a view.

To understand how views are populated, read the next entry, "Queries." For information about queries and views, see How queries and views work together.

Queries: A way of retrieving information from the index. Artifacts (such as products, work items, requirements, design models, test cases), are retrieved from the Lifecycle Query Engine.

Administrators craft queries to embed in the custom views that they create. The queries pull data from the index and refresh the custom view with the appropriate artifacts. The retrieved artifacts can then be used to populate a view, run a report, perform an analysis, and more.

Several queries are available on the Shared Queries page.

For information about queries, see Creating and running queries.

Analysis: A detailed examination of artifacts. Analyze artifacts to explore and discover how they relate to one another.

Use the shipped impact analysis profiles to customize profiles for impact analysis diagrams that show relationships between artifacts. For example, if a child product in your product is recalled, you can run impact analysis on that child product to gauge the impact of replacing it.

The analysis output shows all dependencies, child products, and blocked artifacts that are related to the recalled child product.

Image shows an example of an impact analysis diagram and the relationships between related artifacts.

For information about analysis, see Analyzing an artifact's relationship to other artifacts.

Reports: A physical performance measurement. Reports use data from the index to produce documents that track status and progress. You can use this information to manage and mitigate development risks, improve product quality, control product costs, and more.

For information about reports, see Running and printing a report to show the status of artifacts.

Requirements: Describe what users want from a product or service. A requirement can contain links to related artifacts that enhance its definition. See Rational DOORS Next Generation.

Design models: Help teams architect, design, and develop software and systems in an iterative and collaborative way. See Rational Rhapsody® Design Manager.

Test cases: Help teams plan, develop, execute, and report on their test plan to ensure that the quality standard is met. See Rational Quality Manager.

Work items: Manage the tasks and issues that your team must address during the development cycle. See Rational Team Concert.


Feedback