IBM Software Group What's new with Rational IBM s Telelogic Solutions move to Jazz Heimo Feldbaumer, 11.11.2010 2010 IBM Corporation
IBM s Telelogic Solutions move to Jazz Zusammenspiel und Integration in die Jazz Welt Einführung Anwendungsfall: Embedded Systems & Software Entwicklung DOORS Rhapsody RTC Quality Manager Anwendungsfall: Enterprise Architecture Modification Projects System Architect Focal Point Publishing Engine 2
IBM s Solution is built on Jazz, a Unified Collaboration Platform IBM s prev. Telelogic Solutions move to Jazz Future IBM Capabilities Your Existing Capabilities System Architect Focal Point Rhapsody DOORS Best Practice Processes Publish. Engine 3 rd -Party Jazz Capabilities Collaboration Presentation: Mashups Discovery Query Storage Administration: Users, projects, process Client Integrations RDz Eclipse Web 2.0 Microsoft SharePoint, Microsoft Project, Lotus Quickr, etc. Open Service Lifecycle Integrations Jazz is A scalable, extensible team collaboration platform An integration architecture, enabling mash-ups and non-jazz based products to participate Server Integrations Existing Rational offerings Business partner offerings Open source offerings (Subversion, etc.) Others to come (Other IBM servers, etc.) 3
Open Services for Lifecycle Collaboration An Open initiative to collaborate on a common integration architecture for software delivery Barriers to sharing resources and assets across the software lifecycle Multiple vendors, open source projects, and in-house tools Private vocabularies, formats and stores Entanglement of tools with their data Open Services for Lifecycle Collaboration Community Driven specified at open-services.net Specifications for ALM Interoperability Inspired by Internet architecture Loosely coupled integration with just enough standardization Common resource formats and services A different approach to industry-wide proliferation Please visit www.open-services.net 4
The future of integrations OSLC Producing a generic integration framework DOORS 9.3, DWA 1.4 *DWA server is required for OSLC Publish Consume Requirements Management Services Consume Change Management Services Consume Open Services for Lifecycle Collaboration Publish Quality Management Services Publish Consume Architecture Management Services Publish Consume Publishing Services Publish Products wishing to integrate to DOORS 5
IBM Rational Integrated Systems Lifecycle Management Rational DOORS Optimized requirements management Links requirements to development for easy and powerful traceability Ensure your sw/system/product/service meets the requirements Analysis & Design Rational Rhapsody Model-driven development of systems and software Standards-based: UML 2.1, SysML 1.1, DoDAF, MODAF, AUTOSAR Visualize and transform complex requirements into deployable products Requirements Definition & Management Construction Rational Team Concert Organizational collaboration Integrated agile planning, project health, source code, work item and build management Enables distributed development across the program Build & Release Management Production Configuration & Change Mgmt Quality Management Asset Management & Reuse Rational Quality Manager Test and quality management for systems & software delivery Track all aspects of the quality assurance effort 6
Rational DOORS IBM Software Group Rational software Worldwide market and technology leader Yphise award for best RM product ISO 9001 compliant development Easy-to-use document oriented views Traceability to any information Compliance status at your fingertips Intuitive reuse capabilities Comprehensive stakeholder collaboration Simple but powerful versioning
DOORS: Manage requirements across lifecycle and across disciplines User Requirements Technical Requirements Design Test Cases 1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy? Traceability to/from Team Concert work items End-to-end visual validation in one view 1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design 1.1. Identify and development impacted elements due to a change in another element 1. Capture design and related information activities and define responsibility for implementation. Traceability Reports: consistency 1. Capture with design driving and related design information elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, Impact or result Reports: other design elements affected 1.2. Reference external information sources 1.2. Reference external information sources 1.3. Reference external documentation in, input to the design and development process. Links to impacted design elements 1.3. Reference external documentation 1.1.1. Create backward traces to design elements within and across any organizational 2. Store design and related information The plans shall be reviewed as design and development evolves. procedure 2. Store design and related information 2.1. Identify and tag design information The plans shall as unique be updated design as design elements and development evolves. 2.1. Identify and tag design information as unique design elements The plans shall be approved as design and development evolves. Traceability Reports: Procedure Attribute 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2.2.2. Organize by inter-relationships 2. 820.30(c) Design Input Traceability Reports: Milestone 2.2.2. Organize Attribute by inter-relationships 2.3. Ensure all design elements are 2.1. available Each manufacturer shall establish procedures to ensure that the design requirements 1.1.3. relating Create to backward a traces to design 2.3. Ensure elements all design within elements and are across available Design Control 2.3.1. Store design elements by Design device Control are appropriate Guidance and Element address the intended use of the device, including the needs of Guidance the user Elements 2.3.1. Store design elements by Design Control Guidance Element 2.3.2. Store design elements and their and historical patient. values 2.3.2. Store design elements and their historical values 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating Traceability to a Reports: Linked design elements 3. Manage all user needs device are appropriate and address the intended use of the device, including the 1.1.4. needs of Create the user forward impacts 3. to design Manage elements all user needs within and across any organizational 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 2.3. The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure 3.2. Identify Attribute all user types (groups) 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 1.1.5. Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 3.4. Profile the expected patients 3.5. State the intended use of the 2.6. product The (family) design input requirements shall be documented by a designated individual(s). Impact Reports: Milestone 3.5. State Attribute the intended use of the product (family) 3.6. Capture the acceptance criteria 2.7. for The each design user need input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design 3.6. Capture elements the acceptance within and criteria across for each Design user need Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements shall be documented. Impact Reports: Linked design elements 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 2.10. Questions. 1.2. Associate changed design elements with related elements 4.2. Identify the associated user need 4.2. Identify the associated user need 4.3. Capture requirement description and 2.10.1. attributes Summarize the manufacturer's written procedure(s) for identification and control Link ofchange Design Object 4.3. with Capture affected requirement design element(s) description and attributes 4.4. Capture acceptance criteria design input. Traceability Links and Reports 4.4. from Capture affected acceptance design criteria element(s) 4.5. Assign responsibility for each requirement 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that Impact apply and Links and Reports from affected design element(s) 4.6. Manage incomplete requirements 4.6. Manage incomplete requirements list additional aspects.) 1.2.1. Associate design element changes with decisions, rationale, and approval authority 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements 4.9. Approve all requirements 2.10.3.2. user/patient/clinical Change Decision Objects 4.9. with Approve following all requirements Attributes: 2.10.3.3. performance characteristics 2.10.3.4. safety Disposition Attribute 5. Manage acceptance 5. Manage acceptance 5.1. Ensure the acceptance of every user need 2.10.3.5. limits and tolerances Decision Attribute 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design 2.10.3.6. input requirement risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.3. Document the results of every user need 2.10.3.7. acceptance toxicity test and biocompatibility Owner Attribute 5.3. Document the results of every user need acceptance test 5.4. Document the results of every design 2.10.3.8. input requirements electromagnetic test compatibility (EMC) 5.4. Document the results of every design input requirements test 5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices Management Approval Attribute 5.5. Make acceptance results available 2.10.3.10. compatibility with the environment of intended use 1.2.2. Provide associations within and across any organizational procedure 6. Manage change 2.10.3.11. human factors Change Design Object 6. Traceability Manage change Link on Procedure Attribute 6.1. Maintain history of design element changes 2.10.3.12. physical/chemical characteristics Change Design Object Impacts 6.1. Maintain Link history on Procedure of design Attribute element changes 6.1.1. Make complete change history available 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.2. Maintain history within and across 2.10.3.14. any organizational reliability 1.2.3. Provide associations within and across any project milestone procedure 6.1.2. Maintain history within and across any organizational procedure 6.1.3. Maintain history within and across 2.10.3.15. any project statutory milestone and regulatory requirements Change Design Object Traceability Link on Milestone Attribute 6.1.3. Maintain history within and across any project milestone 6.1.4. Maintain history within and across 2.10.3.16. any Design voluntary Control standards Guidance Elements Change Design Object Impacts 6.1.4. Link Maintain on Milestone history within Attribute and across any Design Control Guidance Elements 6.2. Capture frequency and nature of element 2.10.3.17. changes manufacturing processes 1.2.4. Provide associations within 6.2. and Capture across frequency Design and Control nature Guidance of element changes Elements 6.2.1. Provide rationale for change 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.2. Describe decisions made 2.10.3.19. MDRs/complaints/failures and other historical data Change Design Object Traceability Link to traced design elements 6.2.2. Describe decisions made 6.2.3. Identify approval authority for the 2.10.3.20. change design history files (DHFs) Change Design Object Impacts 6.2.3. Link Identify to linked approval design authority elements for the change 6.2.4. Capture date, time, and signature 2.10.4. of approving For the specific authority design covered, how were the design input requirements 1.3. Mange identified? the change process 6.2.4. Capture date, time, and signature of approving authority 6.3. Identify impacted elements due to 2.10.5. a change For in the another specific element design covered, how were the design input requirements reviewed for Design Change Module 6.3. Identify impacted elements due to a change in another element 6.3.1. Create backward traces to design elements adequacy? within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone Object History Object History Reports Versions Baselines 1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1. Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3. Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6. Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1. Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines Requirements change management Traceability to/from Quality Manager tests
DOORS Jazz Integration for Requirements Change Management and Requirements Driven Development A user integrating with OSLC from DOORS can use rich hover functionality to see information from the other system inside of DOORS: A user integrating with OSLC to DOORS can use rich hover functionality to see the requirements information inside the other tool: e.g. RTC task being displayed inside of DOORS e.g. DOORS requirements being displayed inside of RTC
Team based, quality driven software delivery using Rational Quality Manager Collaborate A quality management hub for the software delivery team Web access with Web 2.0 style collaboration Reuse homegrown, other vendor and partner test assets Extensible plug-in architecture Automate Eliminate manual documentation Improve utilization with automated test lab management Govern Traceability across business objectives, skills, test cases, resources, defects and exit criteria Dynamically prioritize risk resolution by role Open and extensible on Collaborate in context Right-size governance Day one productivity
DOORS - Quality Manager: Requirements driven testing Knowing what to test Requirements tracking built into the test management tooling Customizable attributes enable you to track what is important to your team Real-time impact analysis of requirements changes Traceability of test results to user needs 11
Model-Driven Development for Systems & Software Rational Rhapsody Capabilities Requirements Visualization Strategic Reuse Model Execution Standards- Based MDD Software- Centric Workflow Model-Driven Testing Requirements-driven analysis and design for technical, embedded or real-time solutions, including those based on multi-core architectures Rapid design validation and verification with frequent simulation and testing Development and deployment of complete C, C++, Java and Ada applications Benefits Build the right product through non-ambiguous communication and frequent collaboration Eliminate defects early and increase quality by continually testing the design Reduce development time by automatically generating applications and documentation Re-use and adapt existing technology through reverse engineering and product line engineering
Rhapsody Integrations & Team Collaboration Collaborative development with Rational Team Concert Shared views Collaborative debugging Linked work items Powered by Iterative requirements engineering with Rational DOORS or Requisite Pro Enterprise systems delivery with Rational System Architect Test management and execution control with Rational Quality Manager Embedded software testing with Rational Test RealTime Team-based configuration management with Rational ClearCase or Synergy Embedded platform development and multi-core extensions with Wind River Workbench/VxWorks and other embedded IDEs/RTOSs. Product Line Engineering with BigLever Gears Reduce time and risk associated with parallel development even across very large, distributed teams
Enterprise Architecture Modification Projects Rational Focal Point Collect Estimate Prioritize Decide assigned to Features Projects Features Analyze Plan Trace Rational System Architect Processes belong to depends on Applications Hardware depends on Assign Execute Track Build Code change Rational Team Concert Projects Tasks Teams contain assigned to Features satisfies System requirements satisfies Component requirements Analyze Trace Ensure compliance Rational DOORS
Rational Focal Point for Project & Product & Portfolio Management Focal Point supports demand management, high level resource analysis, evaluation and selection of project proposals, and their periodic review. Provides support to maintain the inventory of projects with their KPIs. Capabilities to balance and align the portfolio with strategy and business needs. Implemented with a top-down approach. Uses strategy and business plans as criterion for the portfolio analysis. Approved proposals flow from Demand Management to Project Execution. Project status flows back for periodic Portfolio reviews. Integration / Interface to: RTC & Jazz, DOORS, System Architect, for high level analysis and prioritization of requirements, initiatives, demands,...
Rational System Architect for Enterprise Architecture Enterprise blueprinting with interactive visualization and analysis Link, consolidate and analyze business and IT information in blueprints Business architecture and process analysis: align strategies, goals, organization Applications, systems, services, data, networks and components Understand your current state, and use it to map to your future optimized state Identify redundancy and reuse of business and technology assets Identify and minimize execution risk Minimize execution risk through transformation due diligence
System Architect: Visualize the Organization Enterprise Strategies & Direction Projects & Initiatives Business Processes & Services Orgs & People Applications Data IT Infrastructure & Services With SA you can see key EA components supporting Enterprise strategies & goals! With SA you can see key EA components dependent upon specific technologies! With SA you can manage key EA components as projects and initiatives!
Rational Publishing Engine High Quality Reports Automates Your Document Creation Process Coherent Same concepts used for all data sources Same concepts used for all output formats Separates data from formatting Self contained Platform, data source and output format independent template format and editor Does not require Microsoft Word or any other 3rd party tools installed for output Non-intrusive No changes made to the data sources during document generation Extensible Speed Usability Rational Publishing Engine Mechanisms in place for adding new data sources and output formats Flexible output
Rational Publishing Engine Integrations Document automation across the development lifecycle Access data from a wide range of Rational tools, including: Asset Manager, DOORS, ClearCase/ClearQuest, Focal Point, Quality Manager, RequisitePro, Rhapsody, Requirements Composer, System Architect, Tau Access data from third party tools via XML and REST interfaces Source 1 Source 2 Source 3 Source n
www.ibm.com/software/rational Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.