Polarion Feature: Collections

Collections are an undervalued standard feature of Polarion. Even though it can help organize documents for audits of regulatory bodies or to separate between different developments for the same product, not many companies use the Collections.

 

Blog by Martin Bron

want to learn more about Collections?

Preamble

Collections are an undervalued standard feature of Polarion. Even though it can help organize documents for audits of regulatory bodies or to separate between different developments for the same product, not many companies use the Collections.

For whom this could be intersting

  • Anyone that needs to collect data/documents for regulatory bodies or (external) parties
  • Any company that designs new features simultaneously and independent for any product.
  • Anyone who needs better control over the documentation for variant management.

 

what is a collection?

Collections support parallel development activities, help with audit and regulatory compliance, and support advanced reuse scenarios. At first glance, it may seem like Collections are simple containers for Documents, but there is more to them than that. Collections can also be archived for historic and regulatory compliance needs.

The Complex Waterfall (V-model) product development approach is frequently utilized in heavily regulated industries such as Aerospace, Defense, and Automotive. It is common for various teams to focus on different phases of development, and specifications are often created concurrently or in parallel.

How you can use a collection

Of course 1 of the options is to collect all the documents necessary for an audit or submissions. But it can also be used for the normal development process.

So lets now look at a basic example:

  • Team A works on the Product Need Specification.
  • Team B works on System Level Specifications.
  • Team C works on HL (high-level) Software Specifications.
  • Team D works on LL (low-level) Software Specifications.

Note: Based on their scale and size, each Specification box here can represent a Document, and the red oval would be a Collection, at its current level of progress.OR, with hierarchical Collections, each Specification box can be a Collection of Documents, and the red oval would be a particular Collection hierarchy, as determined by the lowest (most Downstream) Collection, the LL Software Specification.

Phase 1 of the project begins, and Team A starts their work. When they finish Version 1 of the Product Need Specification (in a waterfall development process), Team B starts working on its System-level Specification.

As Team B develops their specification based on Version 1 of the Product Need specification, they develop traceability from the System Level Specification they are working on back to Version 1 of the Product Need Specification.

This is repeated for the other levels that Teams C and D work on.

Once all teams have finished Version 1 of their specifications and have gone through their respective reviews, Phase 1 of the project concludes, and in order to satisfy regulatory needs, they may baseline the involved Documents and Collections and Close the Collection to represent Release 1 of the product delivery (shown by the red oval in the diagram above).

Many companies can’t afford the luxury of waiting for Phase 1 of the product delivery to finish before they start working on the next phase of their product delivery. So, they supplement the classic V-Model lifecycle with a concurrent workflow.

Collections ensure that the teams work with the correct versions of the product specifications for the correct product deliveries or releases. This way, they also ensure that any links that get created between the specifications within a Collection or Collection hierarchy point to the correct versions.

If, at any time in the future, the project team needs to go back and review a specific product release, Collections make it easy to review that information because everything is contained within the scope of the Collection or Collection Hierarchy.

It doesn’t fully negate the need for branching and merging, but it can help reduce the need for having to do it for each release

Latest updates for collections

In the newer versions of Polarion, it is also possible to add Test Runs and LiveReport Pages to the Collection. With the Test Runs, you have all your requirement data and the testing performed for those requirements all together without the need of a Project Baseline. With the added benefit that the “Baseline” you now have is not 1 fixed point in time, but for each part of the process the correct fixed point for each part.

And now it is also possible to have LiveReport Pages as part of the Collection. Not all available widgets are compatible with the collections. But InnoFour can help you with generating LiveReport Pages for your collection.

want to learn more about collections?

Fields with * are required