Project Hierarchy

Working with Linked Projects

Projects can be linked to each other in a hierarchical structure to allow the re-use of documentation common in multiple products.

The standard scenario is to create documentation for components (in Module Projects) and refer to the documentation in these components through traces from a Master Project (that represents a Product or System) to one or more Module Projects.

Accessing Linked Project Items

When a Master Project is opened, all linked projects are automatically loaded as well. The Project Explorer displays the Document Object books of the Master Project.

To display the Project Explorer of a linked project, use the Current Project Project selector dropdown in the Project Explorer.

To access the File Explorer of a linked project, select the corresponding project name under the File Explorer.

To link a Master Project to a Module Project, select Add/Remove button to select the project you want to link to.

Note! It is not possible to create circular linked-project structures.

The hierarchy of linked projects can be of arbitrary depth. The project linking hierarchy is displayed when clicking Project Hierarchy in the Navigation Bar.

Note! To access a Master Project and its Module Projects, you have to use credentials for the project in question. If the credentials in the sub-project are identical to those in the master project, you will be automatically logged in.

It is possible to create traces from the Master Project to your Linked projects (e.g.: You can trace a requirement in Product 1 to a specification in sub-module A.) and vice versa.

Note! Traces from master projects to sub-projects are not automatically updated to the latest state when a linked item is updated.

Consequently, you have to manually update traces (in the Trace Explorer, see below) to these document objects every time the document objects in the sub-project changes.

The Project Settings contains an option to configure the system to automatically update the traces between linked projects (Project Settings).

A trace between linked projects that are not of the latest revision is called an Obsolete Trace. Updating a child item in a linked trace relationship, causes this state as the trace from parent to child are per default not automatically updated. The child item is depicted with the Obsolete Trace icon in the Trace Explorer.

The Trace Explorer provides the function Trace to the latest revisions. Linked projects are ignorant of the traces from the master project. Traces from the master project will not appear in linked projects when the linked project is opened separately. This also applies to traces from linked projects to their master project.

To unlink a project, select the Add/Remove button for the project to unlink and click Save to store the new state.

Note! Traces from a master project to any unlinked projects still exist but are not displayed after the project has been unlinked.

Branching and Merging Projects

Branching

Aligned Elements projects can be branched in order to create an independent line of the documentation.

When triggering a branch from the Action dropdown menu, a new Aligned Elements Project will be created. The user must select the types of Document Objects that shall be copied from the origin to the branch project. The branch project will then contain the latest revisions of Document Objects of the selected Document Object types.

At branching, Project History events are added to both the origin and the branch projects to record the branch action. The branch project will indicate the name of the origin project in the lower left corner of the application.

Note that the following restrictions apply when branching a project. The branch project will not contain the following elements form the origin project:

• Test Runs

• Signatures

• Snapshots

• Old Revisions of Document Objects

Merging

When merging a branch back to the origin project, Document Object changes in the branch are added to the origin. If any conflicts exist between changes in the origin and the branch, they will be displayed to you and you can decide which version to use; i.e., the origin change or the branch change.

Note that the following elements are not merged back to the origin:

• Test Runs

• Signatures

• Trace Tables

• Queries

• Charts

• Tags

• Locked Document Objects

• Snapshots

• Reviews

• Users and User Groups

Template Paths – The Template path for the original and the branch project must be exactly the same at the time of merge.

Users – The users in both the original and branch project must be the same at the time of merge.

Note that the branch project still exists after merging. Although it is possible to continue working on the branch and merge additional changes back to the origin, only changes after the last merge occasion will be considered during a subsequent merge.

Note! Objects that were created in the branch will be merged back as new objects at every merge! Thus, if an item is created in the branched and the branched is merged twice, the created item will be created as _two separate_items in the original project.