paulellis 270001KTVW Visits (10251)
On April 25th 2016, IBM released Collaborative Lifecycle Management 6.0.2. In Moshe Cohen's blog
One of those highlights was:
And Moshe said:
Maybe it's a coincidence, but a lot of upgrades have occurred in the last few months.
Unfortunately, not all of them have gone as smoothly as they could have done.
Why are people finding that their upgrades are not wildly successful?
This, for me, is particularly frus
We also published a useful blog post "Planning your CLM upgrade?" to help find information about the latest available fixes and system requirements; and Dan Toczala wrote a
All of which was great, but do we just have too much information in too many places?
What we have missed all this time is a single entry point to our expansive library of information relating to your specific upgrade - in a single page!
In order to have a positive upgrade, where success is planned in from the start, a simple, handy checklist is required.
One, simple, must
This checklist includes simple links to assist with obtaining all the information required for each of the key areas of an upgrade:
* Upgrade Testing
* Software Licenses
* Server, infrastructure and performance considerations
* Latest Upgrade flashes and news per CLM application
* Ways to contact us so we can help
* Additional pertinent links/information
We are strongly recommending that this be the starting point of every CLM upgrade. Please also give us your feedback if you believe something is missing.
Sizing recommendations for planning migration of data from Rational DOORS to Rational DOORS Next Generation
paulellis 270001KTVW Visits (10256)
Are you considering migrating your data from Rational DOORS to Rational DOORS Next Generation(RDNG)?
Are you looking for guidance and best practice before you begin to be successful first time?
If so, then your starting point is definitely the detailed guidance on developerWorks on how to Migr
New Sizing and Best Practice Guide on Jazz.net's Deployment wiki
Since the developerWorks article was published, we realized that more detailed sizing information was required prior to executing the migration of data packages from DOORS 9 to RDNG. We collated pertinent sizing information from the Rati
There are significant improvements to the import timings with RDNG 6.0.2 release, so please refer to this article if you are evaluating an existing or future migration as this could indeed be an influencing factor.
The document details:
Sizing Guidelines for Rational DOORS Next Generation 6.x
Recommendations on the maximum sizes of your modules, projects and repositories so as to maximize your success when importing your packages and working in the future within RDNG.
The considerations for hardware are simplified from guidance published elsewhere in the Deployment wiki, but here they are explained within the context of how to plan for your new world.
Guidance on how to convert your Rational DOORS modules prior to migration
Invariably there will be modules and projects within DOORS 9 which will not match up to the guidance prescribed for RDNG. Use this section to understand how to easily manipulate your data before migrating.
What if the data to be migrated exceeds the recommendations?
The guidance is clearly aimed for the general use cases and is very much our strongest recommendation.
It is understood that there are very large enterprise requirements management estates out there. It is recommended that you contact IBM if this applies to you.
Romain_Barth 2700076HKB Visits (5543)
In DOORS 9, it is not possible via the user interface to manage the "baseline power" for users.
But it is possible to modify the original behavior of DOORS by editing a DXL file and by creating a "special" group for those users.
When a user attempts to create a baseline from the UI, this code will be executed and only users in the group will be able to create baseline.
Romain_Barth 2700076HKB Visits (10213)
DOORS 9 - RQM integration : How to update link properties in DOORS after renaming a test case in RQM
After creating a link from RQM artifact to DOORS requirement, if you change the name of the RQM artifact (test case or step of test script), this change is not updated in DOORS : the link description and title in DOORS are still referring to the old name of the RQM artifact.
This is working as designed when the integration between DOORS and RQM uses back-linking (in other words: 2 links are created, 1 in DOORS and 1 in RQM)
There are 2 ways to correct this issue :
- Manually edit the link description in DOORS
- Run a DXL script on your DOORS module that will query RQM to gather the name of the RQM artifact for each link to RQM in the module. Then it updates the description and title of those links.