Recommended
More Related Content
What's hot
What's hot (20)
Similar to Migration from IBM DOORS 9 to DOORS Next Generation
Similar to Migration from IBM DOORS 9 to DOORS Next Generation (20)
Recently uploaded
Recently uploaded (20)
Migration from IBM DOORS 9 to DOORS Next Generation
- 1. #WatsonIoT DOORS 9.x to DOORS NG Migration Matt Mendell SyntheSys 15th May 2018
- 2. 2#WatsonIoT Agenda • The current landscape • Why might we migrate? • What is migration? • What is not migrated? • The recommended approach • Analysis • Preparation • Execution • Post-Processing • Questions
- 3. 3#WatsonIoT The current landscape Visionary directions Internet of Things Requirements drive system-of-systems design IoT feedback loop accelerates product innovation Cognitive data & Watson Analytics How can we can make observations that humans might take weeks to find? Requirements quality analysis Consistency and conflict resolution between disjoint requirements Understanding reuse Ease of use and adoption Projects still fail due to poor requirements practices Encourage all stakeholders within an organization to adopt a tool, not just “tool experts” Ease of use, look and feel Reducing the ergonomic shift for adoption Product Line Engineering Support for strategic reuse in product lines through configuration management and business partner integrations for feature modelling Managing requirements scope with approvals Working with 100s and 1000s of configurations Product and requirements variation
- 4. 4#WatsonIoT The current landscape: the DNG differentiators Quickly define and organise requirements with rich-text specification documents, Use Case diagrams, UI mock-up, story boards and predefined templates Capture Requirements Because administration services are shared with the applications on one Jazz Team Server, teams save time and effort Common Administration Connect project requirements, scenarios, test artifacts and development work items through traceability to identify gaps and change impact Traceability IBM DOORS Next Generation allows you to reuse requirements in multiple places rather than copy them, reducing repetition of work and management of complex products Strategic Reuse Utilise the Report Builder to create your own reports harvesting live data from across the lifecycle to report on, evaluate and improve project performance Real-Time Reporting IBM DOORS Next Generation provides a client extension API that you can use to extend the functionality of the tool, using the widely known JavaScript language Extend Functionality IBM DOORS Next Generation allows you to create a custom dashboard with multiple pages, each displaying a customisable view of a given project Custom Dashboards Manage versions and variants of your requirements as part of the Global Configuration Management capabilities Global Configurations
- 5. 5#WatsonIoT The current landscape • DOORS Next Generation increasingly gaining functionality over DOORS 9.x • Greater number of customers wanting to migrate • DNG is structured differently to DOORS 9.x • Recent functionality additions make the process much easier • DOORS 9.x is not going anywhere
- 6. 6#WatsonIoT The current landscape • IBM is the market leader in Requirements Management • We see 3 trends with our customers 1. Customers who are happy and want to stay with DOORS 9 2. Customers who are in process of fully migrating to DOORS NG 3. Customers who are gradually moving to DOORS NG, starting with new projects • IBM recommends approach # 3 DOORS NG has differentiating capabilities DOORS NG is closing its gaps Migration tooling allows DNG and DOORS to share data repositories
- 7. 7#WatsonIoT What is migration? Migration is: • One-way • Non-destructive • A selection of data, with the original locked down and never coming back • A move from one tool to the other • Where (a selection of) the users move too
- 8. 8#WatsonIoT What is not migrated? • Users and user options • Groups • Access Controls (will be handled by Jazz) • Baselines (including Baseline Sets and Baseline Sets Definitions) • Dictionaries • Favourites • ReqIF packages • DOORS partitions • DOORS project and module archives (i.e. DPA or DMA) • Soft-deleted data (i.e. deleted but not purged) • Template files for Rational Publishing Engine • DXL • Layout DXL columns (although these can be converted to Attribute DXL) • Attribute DXL (although the displayed results are migrated)
- 9. 9#WatsonIoT What is not migrated? • Link attributes • Link modules • Linkset pairings • History • Discussions (although these can be converted to Attribute DXL) • Filters (although the migrated collection will show the expected result set) • Sorts • Suspicion
- 10. 10#WatsonIoT What is migration? • One-way, non-destructive, careful selection of data and links • Project-by-project basis • Exported from DOORS 9 and imported into DNG • Source data is locked to prevent further editing • Baselines are not migrated • Only “clean” data will be migrated, the “noise” will be left behind • Migrated data in DNG contains links back to source objects • Used to browse history and baselines • No two situations are the same • No single solution to satisfy everybody • Variety in shape, size and structure of data • Many different scenarios and needs to be considered
- 13. 13#WatsonIoT The recommended approach Analysis 1. Understand the size and shape of the data 2. Identify potential risk areas and possible process improvements Preparation Optional activities performed in response to Analysis, cleansing of the DOORS Execution Creation and export of migration packages from DOORS 9 and import into DNG Post Processing Optional activities such as additional harmonization of artifact types in DNG
- 14. 14#WatsonIoT The recommended approach OSLC OSLC • One-way • Non-destructive • Incremental, not big bang
- 20. 20#WatsonIoT Preparation • Remove soft deleted artefacts • Consolidate attributes • Consolidate attribute types • Consider adding an ‘Artifact Type’ attribute if it doesn’t exist and organising objects accordingly
- 36. 36#WatsonIoT Post Processing • Tidy up type system • Tidy up module structure • Review data in DOORS Next Generation, potentially adapt process to leverage functionality • Potentially write Javascript to do tasks
- 37. 37#WatsonIoT Summary • IBM is the only vendor who fully understands DOORS data • IBM is best placed to offer migration • Full migration not always the best option • DOORS licence holders can run DOORS and DNG in parallel • DOORS will be around for a very long time to support your needs • Migration itself is ‘easy’ on a technical level • Business transformation can take more time • Migrate existing live data to new projects • Move viable projects from DOORS to DNG • Retain a reference model in DOORS for a formal audit trail
- 39. 39#WatsonIoT Considerations for DNG vs. DOORS 9.x Benefits DNG DOORS DNG Differentiating functionality • Requirements reuse (as opposed to copy) • Centrally defined type system • Built-in review capabilities • Native support for informal diagrams Web client • Fully functional web client • Zero Client Installation Collaboration server (Jazz) • Shared Jazz functionality using an OTS database • Collaboration between team members • Collaborative dashboards CM & CfgM • Built in Task planning and management • Built in configuration management of requirements and lifecycle data Client side scripting Java Script DXL Scalability Medium Large DOORS Differentiating Functionality • Easier sharing between disconnected databases • Fine grained READ access control of data • Electronic signature usable for 21 CFR Part 11 • Multi-level traceability in one view
Editor's Notes
- What that translate to in RM… 3 years ago, 4.05, drag and drop linking… Particularly since v6, existing customers… DOORS never reach version 10, but still long life ahead of it and not going anywhere. For that reason, strongly recommended historical data and project audit trails kept in DOORS 9.x.
- DOORS 9 largest install base, growing, here to stay IBM aims to provide end to end solution, so DNG fits into suite IOT platform solutions IBM entitled DOORS customers to DNG to ease transition DNG has differentiating capabilities (change and configuration management, fine grain components, collaboration) DNG closing gaps (Scalability improvements, data sharing and usability) Migration tooling allows them to share repositories Customers can keep large data archives in D9 and still access when needed New projects start in NG, still connect D9 Migration can be done phased approach Migration services available
- NOT A repeated interchange between tools, where data moves for review and potentially for update NOT All data NOT Where users continue to exist in both tools
- DNG not DOORS 10 Not gaps Either no equivalent in DNG, or equivalent works differently
- Integrations also not migrated Custom integrations may need to be considered
- Working around the clock… Involves time and effort to great right, responsibilities must be clearly defined Have to acknowledge each tool + how it works to migrate effectively If I need to track back from my new data, how do I do that? How do we bring the business process into the new system? If requirements errors exist, how can we ensure our V&V methods will catch them? If data was not standardised, how do we ensure that it is standardised in the new tool?
- Exactly how done depends on organization priorities and needs. Broadly 4 stages, but first decide which parts of 9.x database migrated. In order to reduce effort and cost, only migrate relevant subset data in context of business need. Subset focus on only current and future work which will benefit from DNG capabilities, not include historical or completed projects. Which projects finished? Which are active? Which have elements to reuse?
- Analysis done original data What data we have, what attributes and types we have How many projects/folders/modules Things don’t match? Things can consolidate?
- New Family Car project New migration menu
- New migration menu options First to manage metrics…
- Detail entirely lost in this slide… Lots of useful metrics on the data, including things like… # objects # heading object # attributes at each level, and at each type All of this data arms us for the next stage of operation…
- Left shift… Best way is to harmonise…
- Technially ReqIF package, but optimized with extra data beyond standard ReqIF – DOORS tables, OSLC links Only migration functionality in market that does this
- Potentially could have several different packages being worked on, status of each is tracked…
- Move the file
- Create new project No need to create types!
- In summary, what I’d like you to be able to take away from this…