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 live documents, but there is more to it than that.

If your organization falls into this category you can Create a Collection of Documents to help manage the scenario described below.

Complex Waterfall (V-model) product development is often used in heavily regulated industries (Aerospace, Defense and Automotive to name a few), and its not unusual to have different phases of development done by different teams. It's also not unusual for specifications to be developed concurrently or in parallel with one another.

The Polarion Collection concept helps projects with that concurrent workflow. It helps them to ensure they are working with the right versions of specifications, links that are created point to the correct specification versions, and the collection can be archived for historic and regulatory compliance needs.

So lets now look at an 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.

Phase 1 of the project begins, and Team A starts their work and at some point, they finish Version 1 of the product Need specification. At this point, (in a waterfall development process), Team B starts working on their System level specification. As they develop 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 then repeated for the other levels that are worked on by Teams C and D. In Polarion, now this work can be done inside a Collection.

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 close the Collection to represent Release 1 of the product delivery (shown by the red oval in the diagram above). Thus, the closed Collection now consists of:

Now 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 to that end, they will supplement the classic V-Model lifecycle with a concurrent workflow. To illustrate this concept, Team A would begin working on Phase 2 of the project and thus work on the next iteration of the User need specification even though Teams B, C and D are concurrently working on Phase 1 of the project.

Collections ensure that the teams will work with the correct versions of the product specifications for the correct product deliveries or releases. As such they will also ensure that any links that get created between the specifications within the Collection 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.