Skip Navigation LinksHome Page > Forums > SpiraTeam Forums > SpiraTeam Issues & Qu... > Working with multiple Spi...

Working with multiple Spira 'Projects (PRs)' during an integration work-package

Friday, May 10, 2013

Hi all

I just wanted to ask the wider Spira user community if they had experiences of maintaining multiple, concurrent Projects (PRs) as part of a common package-of-work, and what constraints and solutions they were aware of.

At our company, we have PRs for each of our products as we have a continuous development culture which means RQs, INs and TCs must persist across many Releases (or "work-packages"). This is great for when a product is being developed and enhanced in isolation.

However, some of our products are (directly or indirectly) integrated, and hence there is a need for integrated regression testing. Tracking these work-packages is more tricky.

We have previously adopted a couple of different models:

where we created a fresh PR for the work-package, with it's own finite Requirements, Releases, Tests and Defects. The PR was then decommissioned at the end of the work-package. Some of the re-usable assets or outstanding incidents were then migrated to another PR to continue the pattern etc etc etc. The problems here were duplications (eg proliferation of id# for artefacts which were the same thing) and reporting. We have dropped this as a model now.
where we deliberately duplicate artefacts (eg RQs) in both PRs and progress them uniquely. For instance, an integration requirement is logged in both PRs. We then treat one PR as the "master", because it is the product which is most active/complex, and store all the integration TCs/TXs in there and run everything in there. This gives us a single place for test results. But we still log Defects in the correct product PR so that we keep a proper record, which means managing bugs in two places. The biggest problem with this is keeping the "junior" PR in synch with the "master".

Considering that these work-packages are quite regular, and that we don't want to end up with a massive list of short-lived PRs, what model could we adopt that gives us the flexibility, maintainability and searchability that we need?

If you've ever been in a similar dilemma, how did you resolve it?

Cheers.

3 Replies

Tuesday, May 14, 2013

inflectra.david

re: astrium_tm Friday, May 10, 2013

Anyone have any ideas for Andy?

Friday, May 24, 2013

vsmith

re: inflectra.david Tuesday, May 14, 2013

We are using what you call Model 1. I am interested in any other solutions others may have. Model 2 would require too much SpiraTeam Administration for us to handle at this point.

Wednesday, July 3, 2013

sedavbe

re: vsmith Friday, May 24, 2013

Hi
Sad to say I don't have a solution but exactly the same dilemma, I now have multiple projects for the same product but for different customer implementations. My initial approach was to keep the base line artifacts in a generic project and instruct the customer projects to create specific artifacts for just that customer then use the artifacts in the generic project for all other purposes, this was a bit naive and the projects have exported artifacts from the generic to their own, I don't need to say what the subsequent problems are. On top of this the number of new projects is growing continually, I'm heading into chaos to put it mildly.
The only solution I can see is that Inflectra make it possible to be able to cross project link and not copy artifacts and I have suggested this.

/David

Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885

Statistics

Started: Friday, May 10, 2013
Last Reply: Wednesday, July 3, 2013
Replies: 3
Views: 2967

Working with multiple Spira 'Projects (PRs)' during an integration work-package

Spira Helps You Deliver Quality Software, Faster and With Lower Risk

Edit Thread

Edit Message

Search Results