Rational and Telelogic

Transcription

1 IBM Stware Group Rational Telelogic Solutions for Systems Engineering & Product Lifecycle Brett Hillhouse, WW Rational PLM Executive 2007 IBM Corporation

2 Agenda Introduction Telelogic Cusmer Challenges Solutions 2

3 Who is Telelogic? IBM Stware Group Rational stware Proven leader in: Requirements engineering Enterprise architecture Model driven development complex systems Real-time embedded stware development ols Systems services expertise Publicly held stware company founded in 1983 Over 1110 employees operating in 22 countries Headquartered in Malmö, Sweden with U.S. headquarters in Irvine, CA Over 8000 cusmers, more than one third Fortune Global 500 Strong cusmer base in Aumotive, Aerospace Defense, Electronics Supports industry stards such as AUTOSAR (Au) SysML, DO-178B (A&D) MISRA (Au) 2007: SD Times 100 Winner Stware Magazines Stware 500 list 3

4 Why IBM acquired Telelogic Telelogic re-invigorates Rational expertise capabilities in Systems Delivery Brings critical industry systems engineering / services expertise Strengths IBM PLM ferings Provides up-sell opportunities at Rational Telelogic cusmers Complementary Rational Stware & Systems Delivery Platform Focal Point Product portfolio management System Architect Enterprise architecture DOORS Requirements engineering Rhapsody Model driven development NOTE: Partial list. Click here for complete product portfolio. Stware Development Platform 4

5 Best in Class Products Rely On More Electronics Proportion Products that are Mechatronic Laggard Average Best In Class 5

6 Competition cusmer dem are driving market changes in product development delivery Aumotive In-vehicle electronics stware value will increase 35-40% by % all innovation is based on electronics 80% this is based on embedded stware. Powertrain Engine Transmission Steering Brakes & Stability Lighting Climate & comfort Networks Safety Electronics The need for product differentiation along with continued advances in electronics is driving ever increasing amount stware in products Aerospace defense Cost reductions increased innovation through growth in use an extensive set design partners crossing multiple legal, technology security boundaries 6

7 But product failures increased costs risk are impacting botm line Aumotive Complexity electronic systems leads problems with quality, project delays warranty costs Aumotive warranty costs in US Europe range 2% - 3% revenue Approx. 50% warranty costs are related electronic embedded stware Electronics Delays cost overruns when manufacturer finds errors during electronics stware integration testing. Skyrocketing warranty costs if errors are found after-market. Aerospace defense Increased level manpower time underst impact changes coordinate m across development team leads cost over-runs, delays quality problems. 7

8 What s behind se failures increasing costs? Product missed cusmer needs Late market/missed dem Poor commercialization / promotion Product quality Pricing No clear product differentiation Inadequate distribution channel Invenry or availability issues Regulary issues Or 5% 8% 7% 13% 26% 24% 23% 19% 33% 46% The business view The engineering view Where re s electrical, re s stware! 8

9 Capitalizing on this opportunity requires solutions that address product development at enterprise-level Platform ols for full lifecycle stware development for systems Integration product development teams across all design domains enterprise Tools that aumate systems engineering best practices industryspecific stards Manage all product requirements from cusmer needs through full product lifecycle end life Support for large scale teams teams development projects, including extended team contracrs suppliers Solutions that integrate with IBM PDIF framework 9

10 System Stware Delivery Platform Solution Overview Enterprise Architecture/ Architectural Frameworks Telelogic System Architect Product Portfolio Telelogic Focal Point Measurement & Reporting Rational ProjectConsole Telelogic Dashboard Production Requirements Definition & Telelogic DOORS Release Rational BuildForge Analysis & Design Telelogic Rhapsody Rational Systems Developer Configuration & Change Mgmt Rational ClearCase Rational ClearQuest Telelogic Synergy Telelogic Change Quality Rational Test RealTime Telelogic Logiscope Rational PurifyPlus Watchfire AppScan System Lifecycle Process Rational Method Composer, Harmony, RUP-SE Construction Eclipse WindRiver Workbench or IDEs Asset & Reuse Rational Asset Manager Differentiating Capabilities Easily reuse stware assets End -end traceability across complete lifecycle Stards-based platform Open extensible Support for industry stards Supports communication among original equipment manufacturers (OEMs), suppliers, agencies contracrs Solution Solution Overview Overview Adoption Adoption a a Model Model Driven Driven Development Development approach approach build build more more flexible flexible stware stware Adoption Adoption Requirement Requirement Definition Definition ols ols best best practices practices define define manage manage requirements requirements throughout throughout product product life life cycle cycle Aumation Aumation stware stware build build management management testing testing reduce reduce time time labor labor needed needed do do testing testing ten ten early early in in development development cycle cycle Trace Trace requirements requirements through through development development process: process: from from stware stware artifacts, artifacts, build build records, records, test test results results all all change change made made during during life life product product Rational Rational Stware Stware Systems Systems Delivery Delivery Platform Platform 10

11 Requirements Engineering Solution Overview Marketing Sales Market Analysts Cusmers Centralized management cusmer needs design requirements Suppliers Development Cusmer Support Overview Overview Adoption Adoption Requirement Requirement Definition Definition best best practices practices supporting supporting ols ols define define manage manage requirements requirements throughout throughout product product life life cycle cycle Capture Capture cusmer cusmer needs needs link, link, trace, trace, analyze analyze manage manage through through product product development, development, manufacturing, manufacturing, maintenance maintenance retirement/disposal retirement/disposal Can Can cross cross across across all all design design domains domains (electronics, (electronics, stware stware mechanical/hardware) mechanical/hardware) Integrated Integrated with with PLM PLM ISV ISV business business partner partner solutions solutions Competirs Differentiating Differentiating Capabilities Capabilities Supports Supports large large scale scale / / complex complex systems systems development development projects projects including including distributed distributed teams teams Provides Provides security security necessary necessary for for projects projects involving involving design design partners, partners, suppliers, suppliers, ISVs ISVs Analysis Analysis capabilities capabilities underst underst impact impact approving approving changes changes Identify Identify unaddressed unaddressed requirements requirements through through gap gap analysis analysis Integrated Integrated with with Change Change Program Program solutions solutions Cusmer Need/Req Functional Req. Design Req. Test Req. 11

12 IBM Aerospace & Defense Industry Integrated Change : Synchronize Changes No Matter Where They Are Initiated Change PDM System Change Mechanical Design Synchronization changes Suppliers E&E Design Change SW E&E Change Change SW Design Cusmers Change Requirements SW E&E Configuration 12

13 IBM Aerospace & Defense Industry Why Not Just Use One Change System? The domains are different The language is different The type design data being changed (text vs geometry) Supply partners (tier 2 suppliers) can not support multiple change management systems required by OEMs (prime contracrs) Each domain uses ols that best fit ir needs Mechanical WIP data Electronic WIP Design data Stware WIP artifacts 1x change rate 5 x change rate 10 x change rate 2007 AMR Research, Inc. 13

14 IBM Aerospace & Defense Industry The Product Development Integration Framework (PDIF) Enables Integration Across All The Development Domains Project (OEM /or Suppliers) Product Architects (OEM /or Suppliers) Engineering Specialists (OEM /or Suppliers) Engineering Specialists (OEM /or Suppliers) Collaboration - Role-based PLM Workplace (Portals) Collaboration - Role-based PLM Workplace (Portals) Business Process e.g., Engineering Change, Part Reuse Enterprise Integration - PLM Enterprise Information Relationships SOA for PLM Framework IBM SOA Foundation Enterprise Application Systems Program Portfolio Requirements Data Mechanical Authoring Data Electrical Authoring Data Stware Authoring Data Analysis & Simulation Enterprise PDM ERP EAM Or Enterprise Applications 14

15 Integrated Product Change Impact Reduce time propagate changes throughout entire design team Reduce turn-around-time in design & defect resolution Reduce discovering missed changes late in project Leverage existing investment in PDM, SW Electronics systems Electronics Impact Remove latency (delay) from process reduce costs (e.g. warranty or chip re-spin costs) shorten time market Ensure delivery products that meets cusmer needs Reduce risk regulary violation Reduce late cycle discovery product problems that delay/halt launches Improve stware system quality 15

16 Systems Engineering How does this apply se issues? INCOSE Definition a branch engineering whose responsibility is creating executing an interdisciplinary process ensure that cusmer stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient schedule compliant manner throughout a system's entire life cycle, from development operation disposal. This process is usually comprised following seven tasks: State problem, Investigate alternatives, Model system, Integrate, Launch system, Assess performance, Re-evaluate. The systems engineering process is not sequential: tasks are performed in a parallel iterative manner." 16

17 Model Based Systems Engineering is encouraged replace documents as primary design product A&D engineering processes Past Future SE Artifacts Specifications Interface requirements System design Analysis & Trade-f Test plans Document centric Model centric Model-based systems engineering (MBSE) is formalized application modeling support system requirements, design, analysis, verification validation activities beginning in conceptual design phase continuing throughout development later life cycle phases. 17

18 Model-driven system development models a system--systems in four recursive stages. Context describes system people systems who interact with it (acrs). Usage describes how acrs use system is used produce results purposes system. Realization describes how each usage is accomplished by a collaboration system elements. Joint realization describes how operations each system element are also realized in additional viewpoints. Context Usage Realization Joint Realization 18

19 Aumated Model Based Systems Engineering Direction Goal our client projects Provide a tight support for MBSE improve its application including: Modeling productivity, assets reusability across programs, aumatic report generation, etc. Aumatic capture traceability between artifacts enable decision analytics, impact analysis, simulation capabilities Provide an aumated, systematic verification mechanism for system requirements Aumate management multiple representations system. Allow application a model-driven approach system modeling by minimizing necessary modeling skills 19

20 IBM Stware Group Thank you! Danke German Korean Japanese Merci French Grazie Italian Gracias Spanish Russian Simplified Chinese Arabic Obrigado Brazilian Portuguese Thai Traditional Chinese Questions? 2007 IBM Corporation