• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SSE Practices Overview
 

SSE Practices Overview

on

  • 641 views

SSE Practices Overview covering systems engineering, embedded software development, DO178B/C, ISO 26262, IEC62304, and including some short exercises on practice customization

SSE Practices Overview covering systems engineering, embedded software development, DO178B/C, ISO 26262, IEC62304, and including some short exercises on practice customization

Statistics

Views

Total Views
641
Views on SlideShare
641
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • DAY_01_SYSTEMS_KEYNOTE__v02
  • DAY_01_SYSTEMS_KEYNOTE__v02
  • More detailed interpretation of RMC licensing policy found below. This interpretation is not a legal document and was not created so to try and find a loophole to exploit; it was created to enable an open conversation between Rational and its customers regarding how they are licensed and how they can get most value from their investment in RMC. We’ve reviewed and discussed this policy with many customers – and will be happy to do so again. It’s the policy most fair to both Rational and the customer as it is relatively easy to audit and interpret. We appreciate that this licensing policy may not scale appropriately for many hundreds of users (e.g. 500+) and that the RMC product manager may need to be involved in those situations. (He is happy to do so!) That said… Every person using the Rational Method Composer (RMC) tooling requires a “Rational Method Composer” license. Content published from RMC that includes IBM content such as all or part of the Rational Unified Process (RUP), IBM Practices, the IBM Tivoli Unified Process (ITUP), or any of the plug-ins that ship with the product or are made available via IBM developerWorks or other mechanisms for download require a “Rational Method Composer Content Reader” license. Who needs to be licensed? Typically we interpret licensing requirements as: Every team member of any project executing the process -- since all team members directly or indirectly are exposed to the process, its templates, derivative works such as project plans and/or RTC Work Item templates, etc. Any process subject matter experts, etc. referencing the process in order to customize Clarifications of policy: Extended members of a project team are typically not required to be licensed -- people who perform only "informed" or "consulted" roles IBM appreciates that the process may be made available to users via the corporate intranet or other means. This may make the process accessible to those that are not licensed (or authorized) for use. Licenses will not be required for those users if: (1) reasonable effort is made to communicate that the published process requires a license and who to contact within your company for any related questions regarding licensing; (2) some reasonable governance of this is made. Clarification of “RMC / Homegrown Blend” as per above: Typically any blend of content still requires all project team members to be licensed. That the content is, say, out-of-the-box RUP, RUP with 10% customer material, or a mix of RUP and customers material co-mingled is immaterial. Rational created the RMC tooling as it is expected that customers will want to customize and RMC content is licensed and priced with that in mind, buffet style – “all you can eat” for the same price. If that is the case why does it depend upon the usage model as noted? Because there are exceptions that make sense and we didn’t want to paint with too broad a brush. To exemplify: A customer wants to deploy a (customized) RUP process as well as a 100% homegrown waterfall process using RMC. Rational would only require that users of the RUP content be licensed assuming projects using only homegrown content use no RUP tasks, roles, work products, templates, checklists, etc. and that RUP isn’t being cross-referenced by the homegrown waterfall process! A customer is using (customized) IBM Practices and the customer also creates some of their own practices using only their own content. Interpreting this can be muddled for a variety of reasons, but its probably clearest to say that if a project team member is not using any of the IBM Practices they don’t need to be licensed. (Why “probably clearest”? What if to understand the customer’s practice every user would have to reference and understand the IBM Practice that provides the associated input work products?!? Shades of grey.) Hopefully the above gives clarity. When in doubt reach out to the RMC Product Manager for clarification. FAQs So why is the content licensed this way? Why isn’t the RMC Content Reader license enforced via FlexLM? How else can you reasonably license intellectual capital? Content can be viewed via the published web site, via PDF, by using the templates, by using printouts of tool mentors, through derivations of the process (e.g. project plans, evolved templates), etc. There is no reasonable way to use FlexLM or any other kind of mechanized license manager to manage “when someone is using the process.” Moreover, if a company’s auditor asked are you following a process you’d say “yes”, not “only when I need to look at the documentation for it” – so in that essence this is not unreasonable. In this internet-based world there is the misperception that “content is and should be free”. Why isn’t RMC content “free” also? IBM invests much in authoring, editing, and translating its content. Moreover, it does so with respect to existing copyrights and has underwent a comprehensive legal review to this effect. (Has a customer’s homegrown process vetted their process the same way?!?) Trust us, we aren’t getting rich doing this and reselling it. Even rewriting a subset of the content from scratch typically has a greater loaded cost for customers as well. When you purchase an iPod you still have to pay for the music. Having purchased the iPod does not mean the music should be free. There are engineers that created the iPod and artists who created the music. Each deserve payment for their efforts and for the value they provide. The same is true with RMC tooling and content: we have developers who create RMC tooling and process experts authoring content. Both groups provide value and receive a paycheck. (And we don’t provide content a la carte as per the iPod as that is a governance/compliance nightmare!) IBM donated a portion of RUP to the Eclipse Process Framework (www.eclipse.org/epf) and are major committers to this open source effort. So there is a "free" RUP-like process there... but it lacks the meat on the bone that RUP provides. (Ditto for the IBM Practices.) IBM/Rational continues to invest in its commercial process content that is packaged with RMC because we find enough customers who have found the value in purchasing it. We're constantly exploring ways to increase the value of what we provide. For example, RMC has capabilities for exporting RMC content into RTC and we’re looking to do more and more with enactment on Jazz in that regard as noted at RSC in 2009 and years past. Do we still have to pay a license fee if we create a “RUP-like” process? What if we copy and paste parts of your published content in to ours and don’t use your libraries? To exemplify with something other than RUP... Why did Tolkien's Lord of the Rings books have royalties paid for the movie rights? Why do movies that are only "based on" books or short stories have to compensate those authors? Because regardless of format (paper, web site, etc.) someone owns the copyright for the original work and derivative works of that effort require licensing. Does every movie that has a wizard need to pay Tolkien's estate? No. But there is some point where Tolkien-like becomes substantially Tolkien and require royalty/licensing -- even if things like wizards are "in the public domain.“ Whether its RUP in RMC or RUP from a book (or any other of our content in any other form) its still under copyright – copy-and-pasting or retyping it into the RMC tooling doesn’t change that fact. This is not said to start a huge debate or argument about where black becomes grey and grey becomes white with copyright law in general or for RUP (or the rest of our content). Admittedly, there are various portions that is in the public domain or open source (often because IBM donated them!), the property of various authors, etc. so there certainly is grey. Rather, this topic is noted because we can’t give an answer about what your legal department / lawyers (or even your own moral compass) says where copyright of IBM content begins and ends... so there is no definitive answer to asking about a RUP-like process not requiring licensing. (How "RUP-like"?!?
  • All of these products can be used to implement MDSD. The three main products we will focus on in this deck are DOORS, RTC and Rhapsody.
  • File Name Here.ppt File Name Here.ppt File Name Here.ppt

SSE Practices Overview SSE Practices Overview Presentation Transcript

  • © 2013 IBM Corporation IBM Rational Solution for Systems and Software Engineering Practices and Delivery Processes
  • © 2013 IBM Corporation 2 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO-178B/C  ISO 26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 3 Product and System Innovation The Goal  A Software and / or Systems Engineering Organization that is: –Predictable • Performs on target and does not confront stakeholders with surprises –Competitive • Makes the right choices and delivers quality on time –Profitable • Works cost efficiently and delivers for the right price –Compliant • Complies with relevant industry or government regulations  But there are challenges…
  • © 2013 IBM Corporation 4 Product and System Innovation The Process Challenge – Process Silos Change Test Design & Develop Support Requirements CM Process Turmoil V1.0 V1.1 V1.2 V2.0 V2.1 V2.2 V1.1b V1.1.1 V1.1a
  • © 2013 IBM Corporation 5 Product and System Innovation The Technology Challenge – Tool Silos Change Test Design & DevelopSupport Requirements CM Communication Turmoil Tool D Tool E Tool F Tool C Tool B Tool A
  • © 2013 IBM Corporation 6 Product and System Innovation Overcoming Process and Technology Challenges Pays off A Combination of Technology and Process Improvement delivers best Business Value ProductivityImprovement Technology Only Process Only Technology and Process 2% 8% 20% Source: London School of Economics – McKinsey survey and analysis of 100 companies in France, Germany, United Kingdom, and United States “When IT lifts productivity”, Stephen J. Dorgan and John J. Dowdy, ©2004 McKinsey & Company
  • © 2013 IBM Corporation 7 Product and System Innovation New and enhanced solutions for systems and embedded software engineers Accelerate development with industry specific systems and software development solutions Access a growing and extensive business partner ecosystem Enhanced products that deliver integrated capabilities for product and systems development ProductsLifecycle Solutions Ecosystem
  • © 2013 IBM Corporation 8 Product and System Innovation 8 THE FOUNDATION IBM Rational solution for systems and software engineering Accelerate time to value through a collaborative lifecycle Specify, design, implement and validate complex products and the software that powers them with an integrated systems lifecycle management solution Recent enhancements:  Improve quality and ensure compliance with requirements-driven-testing  Improve asset reuse with software variant management  Increase efficiency with cross-project planning  Increase security for product development IP  Enhanced support for numerous safety critical standards IBM Solution for Systems and Software Engineering • IBM Solution for Systems and Software Engineering – IBM Rational DOORS – IBM Rational Quality Manager – IBM Rational Team Concert – IBM Rational Rhapsody with Design Manager Requirements Architecture, Design and Development Systems Lifecycle Management Change/ Configuration Management Best Practices and Services “Our ability to maximize the breadth of the IBM software let us provide NASA with demand-based statistics while maintaining control of the costs.” - Joseph Dress, Requirements Management, Constellation Software Engineering, Corporation 8 Quality Open Lifecycle Integration Lifecycle
  • © 2013 IBM Corporation 9 Product and System Innovation Aerospace and Defense • DO-178B/C • DoDAF, MODAF and UPDM • SysML Automotive • ISO 26262 • AUTOSAR • GENIVI Electronic Design • Hardware software co-design • EDA Integrations Medical Devices • FDA QSR standard • International standards (IEC 62304) Industry focused solutions A family of industry focused solutions with support for Functional safety as a common theme IBM Rational Solution for Systems and Software Engineering Open Lifecycle Integration Best Practices and Services Architecture, Design and Development QualityQualityRequirementsRequirements Planning, Change/ Configuration Management Visualize, Analyze, and Organize Visualize, Analyze, and Organize
  • © 2013 IBM Corporation 10 Product and System Innovation Process Management and Enactment The engine of lifecycle management  Improve quality and predictability by leveraging proven practices and patterns of success  Quickly and easily compose right- sized project/team processes and deploy process, methods and tools to project  Surface process guidance in-context directly within practitioner tools to speed on-boarding, process adoption and return on investment in Rational tools  Simplify compliance with pre-defined methods and mappings to industry standards and regulations  Increase productivity and turn “know-how” into competitive advantage
  • © 2013 IBM Corporation 11 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 12 Product and System Innovation Applying systems engineering to the development system  Whenever we build a system for delivery to a customer (or mass market) we actually build (at least) four systems: – Operational System: product delivered to the customer (or to the market) – Maintenance System: system used to maintain and support the operational system – Production System: system used to manufacture and test the operational system – Development System: system used to define, design and test the prototypical operational system  A good development system is a company’s biggest competitive differentiator  Four main components of the development system architecture:  Development Process (what to do, when to do it)  Development Methods (how to do it)  People (who does it)  Tools (collaboration, automation, reporting)  But it all starts with your business objectives…
  • © 2013 IBM Corporation 13 Product and System Innovation Business objectives drive measured improvement  What if you could?  Assess your current development system against your prioritized business objectives  Develop a roadmap for improvement  Incrementally adopt methods and tools  Achieve measured outcomes like:  23% faster product delivery  40% increase in productivity  70% reduction in defects  50% reduction in on-boarding time  ROI in 5 months w/ $1M annual savings 0 2 4 6 Time-to-Value Business Value CostQuality Predictability Today 3-year goal
  • © 2013 IBM Corporation 14 Product and System Innovation IBM Rational development system architecture  Flexible platform architecture – Jazz Integration Services – Open Services for Lifecycle Collaboration  Modular solution components linked to objectives Jazz/OSLC enabled tools IBM Practices (Methods)
  • © 2013 IBM Corporation 15 Product and System Innovation Reference Library: Rational Automotive Solution for ISO-26262  VTT content  Practice library  Governance schemes  Metrics and dashboards Reference Library: Rational Aerospace Solution for DO-178B  VTT content  Practice library  Governance schemes  Metrics and dashboards IBM Solution Stack Discovery Presentation Administration (users, projects) Query Collaboration Additional Services Storage Jazz Integration Services Solution Specific Products Process Workflow Solution Specific Ref Libraries OSLC/REST APIs RQM DOORS RMCRhapsody Pick the appropriate Library Reference Library: IBM Rational Solution for Systems and Software Engineering  Practices (including recommended metrics and tool guidance)  Elaborate Draft System Requirements, Build and Validate Use Cases, Architectural Analysis - Key System Functions, Trade Study – Weighted Objectives Method, Architectural Design – Use Case Based, Joint Realization, Test Management  Lifecycle model (Work Breakdown Structure, Milestones) based on Practices  Process, project and artifact Templates and collection of Work Item Templates  Other Tool configuration assets (pre-defined: dashboards, reports, artifact templates, attributes, links, etc.) RTC
  • © 2013 IBM Corporation 16 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 17 Product and System Innovation SSE Method Libraries and Process Based Content  SSE Solution – One method library – Three process content websites for the SSE Foundation • Use Case Driven Systems Engineering • Requirements Driven Systems Engineering • Embedded Software Development – One process content web-site for the A&D Solution • DO-178B/C Compliant Software Development – One process content web-site for the Automotive Solution • ISO 26262 Compliant Product Development (System and Software) – One process content web-site for the Medical Devices Solution • Design Control Solution Guidance and IEC 62304 Compliant Software Development
  • © 2013 IBM Corporation 18 Product and System Innovation Enterprise Practices  The IBM Rational Enterprise Practices The Enterprise Practices provide a proven starter set for selected aspects of overall project management through measurement of performance. They can be incrementally adopted. Two initial Enterprise Practices are listed below: – Managing Performance through Measurements – Setting up a Performance Measurement System The Enterprise Practices are included in the Systems Engineering Process Content website
  • © 2013 IBM Corporation 19 Product and System Innovation Managing Performance through Measurements  This practice leverages the use and analysis of data from the Performance Measurement System to better support key business decisions.
  • © 2013 IBM Corporation 20 Product and System Innovation Setting up a Performance Measurement System  This is a practice for establishing a Performance Measurement System to support timely, informed decisions.
  • © 2013 IBM Corporation 21 Product and System Innovation Systems Engineering Practices  The IBM Rational Systems Engineering (SE) Practices The SE Practices provide a proven starter set for selected aspects of the Systems lifecycle. They can be incrementally adopted. The documentation provides two different delivery processes, representing two examples on how to combine and use these SE practices – one focusing on use case driven system development, and a second based on a more traditional V development model. Fourteen initial SE Practices are listed below: – Release Planning – Project Process Tailoring – Iterative Development – Reviews – Shared Vision – Elaborate Draft Systems Requirements Specification – Build and Validate Use Cases – Architectural Analysis - Key System Functions – Trade Study – Weighted Objectives Method – Architectural Design - Use-Case based – Joint Realization – Preparation for Downstream Engineering – Formal Change Management – Test Management
  • © 2013 IBM Corporation 22 Product and System Innovation Release Planning  The Release Planning practice embodies the concept of high-level planning for the complete project scope (macro-) and low-level (micro-) planning for the immediate and next increments or iterations.
  • © 2013 IBM Corporation 23 Product and System Innovation Project Process Tailoring  This practice describes how to select tools and an appropriate process and perform the typical tailoring required for use on a specific project.
  • © 2013 IBM Corporation 24 Product and System Innovation Iterative Development  Create a solution in increments. Each increment is completed in a fixed period of time, an iteration.
  • © 2013 IBM Corporation 25 Product and System Innovation Reviews  This practice provides guidance on how to conduct reviews.
  • © 2013 IBM Corporation 26 Product and System Innovation Shared Vision  This practice supports defining and communicating an overall vision for the project.
  • © 2013 IBM Corporation 27 Product and System Innovation Elaborate Draft Systems Requirements Specification  This practice focuses on providing the first cut definition of system requirements derived from stakeholder requirements delivered as the Systems Requirements Specification (draft). The functional requirements are grouped and prioritized as system use cases.
  • © 2013 IBM Corporation 28 Product and System Innovation Build and Validate Use Cases  In this practice, each system use case is translated into a model and the underlying requirements verified and validated through model execution. Model execution may lead to the new and/or derived system requirements. This practice can be performed activity-driven, scenario-driven, or state-driven. Activity diagram: Build & validate Use Cases (Activity Driven variant) There are additional variants for Scenario and State based
  • © 2013 IBM Corporation 29 Product and System Innovation Architectural Analysis - Key System Functions  The main focus of this practice is the functional grouping of system operations identified in the system use cases. For these groups (key system functions) alternative solutions will be elaborated through trade studies.
  • © 2013 IBM Corporation 30 Product and System Innovation Trade Study – Weighted Objectives Method  The objective of a trade study is to determine the best means of achieving the capability of a particular aspect of the system in a rational manner.
  • © 2013 IBM Corporation 31 Product and System Innovation Architectural Design - Use-Case based  This practice describes a use-case based approach of defining the system architecture.
  • © 2013 IBM Corporation 32 Product and System Innovation Joint Realization  Joint Realization is about analyzing how the elements of multiple viewpoints collaborate in carrying out an operation or service. For example, in joint realization, the flow-down might consist of simultaneously determining the collaboration of logical and distribution elements.
  • © 2013 IBM Corporation 33 Product and System Innovation Preparation for Downstream Engineering  This practice describes the main activities supporting the handoff from Systems Engineering.
  • © 2013 IBM Corporation 34 Product and System Innovation Formal Change Management  This practice explains what formal change management is, and how you can implement this practice in your projects.
  • © 2013 IBM Corporation 35 Product and System Innovation Test Management  This practice describes the process of managing the testing effort.
  • © 2013 IBM Corporation 36 Product and System Innovation Systems Engineering Lifecycle Delivery Process
  • © 2013 IBM Corporation 37 Product and System Innovation Use Case Focused Systems Engineering Delivery Process
  • © 2013 IBM Corporation 38 Product and System Innovation Systems Engineering Process Content Website
  • © 2013 IBM Corporation 39 Product and System Innovation Embedded Software Engineering Practices  The IBM Rational Embedded Software Engineering (ESW) Practices The ESW Practices provide a proven starter set for selected aspects of the Embedded Software lifecycle to complement the SE Practices. They can be incrementally adopted. Six initial ESW Practices are listed below:: – High-Fidelity Modeling – Real-Time Architectural Design – Real-Time Collaborative (“Mechanistic”) Design – Real-Time Detailed Design – Model-Based Testing – Safety and Reliability Analysis
  • © 2013 IBM Corporation 40 Product and System Innovation High-Fidelity Modeling  The High-Fidelity Modeling practice provides a workflow for creating and managing models, primarily in UML and SysML, that precisely describe the abstractions under consideration. It is used to create requirements models (Computationally Independent Models or CIMs) , object analysis models (Platform Independent Models or PIMs) or design models (Platform Specific Models or PSMs).
  • © 2013 IBM Corporation 41 Product and System Innovation Real-Time Architectural Design  The Real-Time Architectural Design (RTAD) practice specifies how architectural design can be achieved through the creation of models from different viewpoints. The five key viewpoints - subsystem and component view, Concurrency and resource view, Distribution view, Safety and reliability view, and Deployment view - each have their own design patterns and technical solutions.
  • © 2013 IBM Corporation 42 Product and System Innovation Real-Time Collaborative Design  The Real-Time Collaborative Design (RTCD) practice optimizes an individual collaboration of elements, typically realizing a single use case. Within a microcycle or iteration that realizes multiple use cases, this practice will be repeated for each use case within the microcycle.
  • © 2013 IBM Corporation 43 Product and System Innovation Real-Time Detailed Design  The Real-Time Detailed Design (RTDD) practice optimizes individual classes, objects, functions, data structures, and types. This is the lowest level of design and is performed by applying design patterns at this primitive level, often known as idioms. In practice, most of the concern at this level of design is placed upon elements that are special in terms of their complexity, criticality, or impact on system performance.
  • © 2013 IBM Corporation 44 Product and System Innovation Model-Based Testing  Modeling brings to the table two primary advantages: the ability to focus on different aspects of a system (such as functional, state behavioral, algorithmic, or structural) and to look at those aspects at different levels of abstraction from simple functions and data structures all the way up to systems of systems. Model-based engineering brings these benefits to the engineering of systems. Model-based testing (MBT) brings the same benefits to testing. This practice describes the application of MBT to MBE-developed systems. Model-Based Testing is an aspect oriented practice. Tasks are adopted as needed.
  • © 2013 IBM Corporation 45 Product and System Innovation Safety and Reliability Analysis  This practice integrates reasoning about safety and reliability in the development process. It uses industry standard work products such as Fault Tree Analysis (FTA), Fault Means and Effect Analysis (FMEA) and Fault Means, Effect, and Criticality Analysis (FMECA) and integrates the development of the work products into the development process. Safety and Reliability Analysis is an aspect oriented practice. Tasks are adopted as needed.
  • © 2013 IBM Corporation 46 Product and System Innovation Embedded Software Development Delivery Process
  • © 2013 IBM Corporation 47 Product and System Innovation Embedded Software Development Process Content Website
  • © 2013 IBM Corporation 48 Product and System Innovation Collaboration, Planning, and Change Management Collaborate across diverse engineering disciplines and development teams Rational Team Concert (RTC) DOORS Quick StartDOORS Quick Start Planning and Governance with RTC Quick Start Planning and Governance with RTC Quick Start SE Practice workshopsSE Practice workshops RTC Quick StartRTC Quick Start RQM Quick StartRQM Quick Start How do I ensure development implements the business needs? How do I validate quality with the business? Adopt DOORS & RTC Accelerator for Systems and Software Engineering – PSO Mappings Adoption Paths Moving services from product-based offerings to solution-based offerings! 48 Adopt RQM & DOORS How do I ensure development is tested by independent test? Adopt RTC & RQM Supporting PSO Continued adoption Entry Point Determine next step in the adoption path Quality Management Improve quality and reduce and cost by automating the testing process Rational Quality Manager (RQM) Requirements Management Improve capacity to deliver value by effectively capturing, prioritizing, managing and monitoring requirements throughout the lifecycle Rational DOORS Common Entry Points Supporting PSO Continued Adoption Design Management Increase innovation by using model driven engineering techniques to manage increasing complexity Rational Rhapsody Rhapsody Deployment PackageRhapsody Deployment Package How do I manage increasing complexity and still find capacity to innovate? Adopt Rhapsody Systems and Software Engineering Assessment of current capabilities and recommendations for deployment of new and/or improved capabilities All SSE Foundation SSE Assessment PackagesSSE Assessment Packages
  • © 2013 IBM Corporation 49 Product and System Innovation Rational Packaged Service Offerings FastTracks Approx: 5 Days Quick value add. Often used to accelerate installation, migrations and deployments. Ideal For... New engagements with small budgets Clients who would benefit from product upgrades (provides second entry for Sales) Existing clients starting new projects, adding new product or require PoC. Prescriptive packaged services with pre-defined known activities and deliverables An offering for each incremental adoption stage with measurable return on investment Approx: 10-15 Days QuickStarts provide a clearly defined roadmap with pre- defined activities and deliverables that rapidly implement foundational capabilities using Rational tools. Ideal For... Great foundation to accelerate new client engagements Existing clients starting new projects, adding new product or require PoC. Approx: >15 Days Provide proven processes, methods and solutions services based on known best practices tailored to client requirements. The deployment packages are designed in a modular fashion. Depending on client requirements, different deployment options can be selected. Ideal For... Projects requiring tailoring to support a deployed usage models / solution. QuickStarts Approx: variable Employing proven methodologies to gain knowledge of client requirements and environment. Ideal For... New engagements when client is not certain of their current capability status. Support existing clients to review current capabilities or deployments advising on current status and best practices. Approx: 1-5 Days Packaged, well bounded predefined IP (tool) sold as is with services. Solution provided to address a specific customer requirement. Ideal For... Accelerate customer’s time to value/adoption with out of the box assets. Rational Commercial Assets are an important part of a complete solution. Deployment Packages Assessments Commercial Assets * Durations depend on specific scope of each offering
  • © 2013 IBM Corporation 50 Product and System Innovation Incremental solution adoption – DOORS entry point Entry Point Add Capability Add Capability Add Capability Client looking to better capture and communicate stakeholder need Need a more flexible way to handle evolving customer demands Need a more formal method to capture, analyze, and share system designs Need a more rigorous to system validation and quality management DOORS Requirements Driven Engineering RTC Add Requirements Change Management & Work Item Management Rhapsody Add System architecture modeling and design analysis RQM Add Requirements driven test management Measure Total number of Reqs Req Volatility Number of req sourced defects Measure Req changes Work item throughput Measure Number of design sourced defects Rate of design maturity Measure Total number of test cases Level of test coverage Defect identification PSO DOORS Quickstart DOORS Upgrade PSO Introducing RTC Assessment RTC QuickStart PSO Rhapsody Deployment Package Harmony Workshop PSO RQM QuickStart 50 These adoption models assume a whitespace client. For existing customers choose an alternate entry point down the thread.
  • © 2013 IBM Corporation 51 Product and System Innovation How do customers access our practice content? Option 1 51 Each content consumer requires an RMC Content Reader License Customer does not need to deploy RMC for this option Client wishes to use IBM method content without changes How? Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment Licensing Option 2 Each tooling user requires an RMC Author License (AU, Floating, Token) Each content consumer requires an RMC Content Reader License Client wishes to blend a combination of IBM method content with homegrown content How? RMC tooling for method authoring Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment Licensing Option 3 Client wishes deploy only homegrown process content (all non-derivative) How? RMC tooling for method authoring Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment LicensingEach tooling user requires an RMC Author License (AU, Floating, Token) content consumers do not require a license
  • © 2013 IBM Corporation 52 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 53 Product and System Innovation  Aerospace Agency $1 billion prototype rocket self- destructed 40 seconds after takeoff. due to a bug in on-board guidance software  F-22 Dateline Issue All software systems crashed due to software bug when F-22 flew over international dateline on test flight  V-22 Osprey Helicopter Hydraulic failure and flight control software bug causes V-22 Osprey to lose control and crash Failure is not an option—but it sometimes happens
  • © 2013 IBM Corporation 54 Product and System Innovation Standards intended to prevent failures often initially increase project costs--Example: DO-178B +25-40% +60 – 100% Source: Avionics Certification – Vance Hilderman and Tony Baghai (avionics publications)
  • © 2013 IBM Corporation 55 Product and System Innovation What is DO-178B?  DO-178B defines detailed guidelines for development of aviation software that performs intended functions  The Federal Aviation Authority (FAA) accepts use of DO-178B as a means of certifying software in avionics  DO-178B outlines the objectives to be met, the work activities to be performed for each objective, and the evidence (output documents) to be supplied for each objective (based on criticality level A-E)  Objectives are organized into process areas – Planning – Development – Verification – Configuration Management – Quality Assurance  Applies to *any* company that needs to supply aviation software that will be used in an airborne system, for commercial airspace
  • © 2013 IBM Corporation 56 Product and System Innovation The need - Common Issues arising from adopting Standards. Example: DO-178B Planning Development • PSAC • SDP • SVP • SCMP • SQAP • Standards PSAC – Plan for Software Artifacts of Certification SDP – Software Development Plan SVP – Software Verification Plan SCMP – Software Configuration Management Plan SQAP – Software Quality Assurance Plan Requirements Verification Data, SQA data, SCM data Verification, Configuration Management, Quality Assurance Design Code Integration SOI#1 SOI#2 SOI#3 SOI#4 • High Level Req • Derived High Level Req • Architecture • Low Level Req • Derived Low Level Req • Source Code • Exec, Object Code • Test Cases & Procedures • Test Results Cert. Liason Inadequate formal plans or not following them Inadequate level of detail and process for Reqs Inadequate or non-automated Reqs Mgmt and Traceability Mgmt Excessive code iterations Lack of automated testing Improper Tool Qual (too much or too little) Neglecting “Independence” & QA Empowerment (“Boss”) Weak process and checklist management
  • © 2013 IBM Corporation 57 Product and System Innovation IBM Rational Solutions for DO178B  IBM Rational Solutions for DO-178B are a set of practices to help organizations developing products for certification under DO-178B and mappings from the practices to the applicable sections of the DO178-B standard  The solutions address three primary needs – Process specification – Process enactment – Specific links from the DO-178B standard to process content to aid in ensuring compliance • By Objective • By Certification Level • By Work Product • By Checklist  The process may be applied to any appropriate development tooling but is specifically optimized for the Rational Systems and Software Solution consisting of tools – Rational Team Concert – Rational DOORS – Rational Rhapsody – Rational Quality Manager
  • © 2013 IBM Corporation 58 Product and System Innovation  Supports processes and work products defined in the standards  Implemented in the Rational Software Platform for Systems – including Rational DOORS, Rational Rhapsody and more !! Process template   Work product template A look to the inside: Overview of IBM practices for DO-178B DO-178B Standard Rational Team Concert Rational Rhapsody Rational DOORS Rational RMC Published website
  • © 2013 IBM Corporation 59 Product and System Innovation IBM Rational Solutions for DO178-B provide process support A dashboard in RTC A Practice library & tool mentors Practice tasks based on work items in RTC Learn and check how to use a Practice Check progress Understand tasks and deliverables Execute my tasks Update my tasks Collaborate with colleagues Starting templates Artifact samples Tool usage DOORS Rhapsody
  • © 2013 IBM Corporation 60 Product and System Innovation IBM Rational Solutions for DO178-B Practice library and published web-site  A step by step guide to the Systems & Software Engineering Practices, formed from the well proven IBM experience with Harmony and the application of Rational Unified Process to Systems  Delivered as RMC and published web-site content
  • © 2013 IBM Corporation 61 Product and System Innovation Practice Enactment  Practice enactment is provided through a Rational Team Concert (RTC) process template  Provides an initial set of tasks for a project  Additional Work Items are created using the Work Item Templates matching the tasks in the Practices  Assignable to team members  Visible in dashboards  Alerts and feeds available
  • © 2013 IBM Corporation 62 Product and System Innovation Activity enactment  Work Item templates enact the key activities for each practice  Each template instantiates a set of work items aligned with the key practice activities  Each work item is linked back to the activity description
  • © 2013 IBM Corporation 63 Product and System Innovation Role and team dashboards  Rational Team Concert dashboards provide summaries of the state of an individual or team activities, such as the application of one of the Practices.
  • © 2013 IBM Corporation 64 Product and System Innovation Tool configuration templates and practice artifact samples  Certain practice deliverables are defined within the library or have examples provided  They are adopted and customised through the supporting Tool mentors and guidelines and applicable tools  Configuration templates and profiles provide initial tool configuration provided for IBM Rational DOORS and Rhapsody at the latest releases – ESW profile for Rhapsody – Project & Module templates for DOORS
  • © 2013 IBM Corporation 65 Product and System Innovation Practice Tool mentors and Practice guidelines  A hands on view of the Practice steps are illustrated in a core set of IBM Rational tools, – DOORS and Rhapsody  Describes “How to” in the tool – E.g. build a specific deliverable  Additional specific guidance provided for RTC in the context of Requirements Change Handling with DOORS
  • © 2013 IBM Corporation 66 Product and System Innovation Rational Solutions for DO178B Process Definition  The Rational Solutions for DO178B Process consists of a delivery process composed of a number of best practices, including: – Prespiral Planning – Developing Requirements – Defining and Deploying the Development Environment – Project Control (governance) – Change Management – Configuration Management – Incremental Iterative Development – High Fidelity Modeling – Real-time Embedded Architecture – Collaborative Design – Continuous Integration – Verification and Validation
  • © 2013 IBM Corporation 67 Product and System Innovation
  • © 2013 IBM Corporation 68 Product and System Innovation Rational Solutions for DO178B: Links to DO-178B Objectives
  • © 2013 IBM Corporation 69 Product and System Innovation Rational Solutions for DO178B: Links by Safety Level
  • © 2013 IBM Corporation 70 Product and System Innovation Rational Solutions for DO178B: Links to DO-178B Objectives
  • © 2013 IBM Corporation 71 Product and System Innovation Rational Solutions for DO178B: Process Overview
  • © 2013 IBM Corporation 72 Product and System Innovation Rational Solutions for DO178B: Iterative Development (Microcycle)
  • © 2013 IBM Corporation 73 Product and System Innovation Rational Solutions for DO178B; High-Fidelity Modeling
  • © 2013 IBM Corporation 74 Product and System Innovation What is Safety?  Safety is freedom from accidents or losses.  Safety is not reliability! – Reliability is the probability that a system will perform its intended function satisfactorily.  Safety is not security! – Security is protection or defense against attack, interference, or espionage.
  • © 2013 IBM Corporation 75 Product and System Innovation Safety-Related Concepts  Accident is a loss of some kind, such as injury, death, or equipment damage  Risk is a combination of the likelihood of an accident and its severity: risk = p(a) * s(a)  Hazard is a set of conditions and/or events that leads to an accident.
  • © 2013 IBM Corporation 76 Product and System Innovation Safety-Related Concepts  A failure is the nonperformance of a system or component, at random – Failures are events – e.g., a component failure  An error is a systematic fault – A systematic fault is an design error – Errors are states or conditions – e.g., a software bug  A fault is either a failure or an error
  • © 2013 IBM Corporation 77 Product and System Innovation Hazard Analysis
  • © 2013 IBM Corporation 78 Product and System Innovation Safety Fault Timeline Fault MTBF Fault Tolerance Time Safety Measure Execution Fault Detection Time safety-related fault occurs tfault dectection < tsafety measure execution < tfault tolerance time << tMTBF accident expected (if unmitigated) fault handled (mitigated) second fault expected
  • © 2013 IBM Corporation 79 Product and System Innovation Safety Measures  Safety measures do one of the following: – Remove the hazard – Reduce the risk, either by • Reducing the likelihood of the accident • Reducing the severity of the accident – Identify the hazard to supervisory personnel so that they can handle it within the fault tolerance time  Safety measures typically do the following – Fault detection – Fault isolation – Fault mitigation, OR – Fault obviation  The purpose of the safety measure is to avoid accident or loss
  • © 2013 IBM Corporation 80 Product and System Innovation Creating Safety View in UML  With code based systems, you essential have a single view for all information  With UML, you can create a view that focuses on a single aspect only – Because there is a model repository, you are assured your view is consistent with the model – Changes in one view (diagram) automatically update the repository, hence all the other model views – With Model-Code Associativity, changes in the model result in changes in the code AND changes in the code result in changes in the model
  • © 2013 IBM Corporation 81 Product and System Innovation Creating Safety View in UML
  • © 2013 IBM Corporation 82 Product and System Innovation Safety-Critical Profile in UML  UML is a general modeling language and can be extended to model metadata beyond its standard usage, for example – UML Profile for Schedulability Performance and Time (SPT) – Model Analysis of Real-Time Systems (MARTE) – Systems Modeling Language (SysML) – UML Profile for DoDAF and MoDAF (UPDM)  A safety critical profile can be developed that provides – FTA diagrams – Hazard analysis table view – Constraint table view
  • © 2013 IBM Corporation 83 Product and System Innovation Fault Tree Analysis (FTA) Fault Tree Analysis determines what combinations of conditions or events are necessary for a hazard condition to occur
  • © 2013 IBM Corporation 84 Product and System Innovation Example Fault Tree Analysis
  • © 2013 IBM Corporation 85 Product and System Innovation Design Redundancy for Safety  The key to safe systems is to analyze the system and to identify the conditions and events that can lead to hazards  Fault Tree Analysis (FTA) determines what logical combination of events and conditions lead to faults  By adding “ANDing-redundancy”, architectural redundancy can be added
  • © 2013 IBM Corporation 86 Product and System Innovation Eight Steps to Safety 1. Identify the Hazards 2. Determine the Risks 3. Define the Safety Measures 4. Create Safe Requirements 5. Create Safe Designs 6. Implement Safety 7. Assure the Safety Process 8. Test, Test, Test
  • © 2013 IBM Corporation 87 Product and System Innovation Eight Steps to Safety 1. Identify the Hazards 2. Determine the Risks 3. Define the Safety Measures 4. Create Safe Requirements 5. Create Safe Designs 6. Implement Safety 7. Assure the Safety Process 8. Test, Test, Test Initial Safety Analysis (within Prespiral Planning)
  • © 2013 IBM Corporation 88 Product and System Innovation Eight Steps to Safety Agile Safety Analysis Update (within microcycle iterations) 1. Identify the Hazards 2. Determine the Risks 3. Define the Safety Measures 4. Create Safe Requirements 5. Create Safe Designs 6. Implement Safety 7. Assure the Safety Process 8. Test, Test, Test
  • © 2013 IBM Corporation 89 Product and System Innovation Hazard Table (generated) Hazard Description Metadata
  • © 2013 IBM Corporation 90 Product and System Innovation FTA Hypoxia Hazard Normal Event Transfer Operator Undeveloped Fault Hazard Basic Fault AND operator Resulting Condition OR operator
  • © 2013 IBM Corporation 91 Product and System Innovation FTA Gas Flow Problem
  • © 2013 IBM Corporation 92 Product and System Innovation FTA Gas Connection Problem
  • © 2013 IBM Corporation 93 Product and System Innovation Fault Table
  • © 2013 IBM Corporation 94 Product and System Innovation Connecting FTA to Requirements (TraceToReq)
  • © 2013 IBM Corporation 95 Product and System Innovation Fault-Requirement Matrix (generated)
  • © 2013 IBM Corporation 96 Product and System Innovation Analysis Model of the SleepyTime Machine
  • © 2013 IBM Corporation 97 Product and System Innovation Analysis Model of the Ventilator Subsystem
  • © 2013 IBM Corporation 98 Product and System Innovation FTA Hypoxia Hazard with Design Elements
  • © 2013 IBM Corporation 99 Product and System Innovation FTA Connection Problem with Design Elements
  • © 2013 IBM Corporation 100 Product and System Innovation Fault-Source Matrix (generated)
  • © 2013 IBM Corporation 101 Product and System Innovation Fault Detection Matrix (generated)
  • © 2013 IBM Corporation 102 Product and System Innovation Tool Qualification for DO-178B  Is Tool Qualification Necessary? – Generally not. Ask these questions: DO-178B process eliminated, reduced or automated? Is output of tool verified per Section 6? No Qualification Needed N Y N Can an Error be Introduced Y Can an Error be overlooked Qualify as Dev. Tool Qualify as Verification Tool Y Y
  • © 2013 IBM Corporation 103 Product and System Innovation IBM Rational DO-178B Qualification kits available IBM Rational Solutions: • IBM Rational Rhapsody • IBM Rational Rhapsody TestConductor • Legacy Solutions •IBM Rational Test RealTime •IBM Rational Logiscope
  • © 2013 IBM Corporation 104 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 105 Product and System Innovation What is Safety?  Safety in the context of automotive embedded systems is about the prevention, detection, and response to unintended behavior that can lead to harm for the vehicle occupants and other road user  Issues with the complexity of automotive Electrical and Electronic systems • Diagram schematics for most vehicles now resemble small modern aircraft with a similar amount of code and its inherent complexity: Typically 50 + ECUs 8 Buses of 4 different types Network controllers • Embedded systems are being used to implement more and more advanced features to improve safety, although this adds complexity, risk, and cost
  • © 2013 IBM Corporation 106 Product and System Innovation Drivers for ISO 26262  Numerous cases of recalls and problems with automotive software (just some examples, many others) – March 2004: Chrysler Pacifica (34,561 vehicles) • Software protocol used to test the vehicle exhaust gas recirculation (EGR) system may • lead to engine stalling under certain circumstances, increasing the risk of a crash. • http://www.car-accident-advice.com/chrysler-pacifica-recalls-030004.html – Apr 2004: GM recalls 12,329 Cadillac SRXs • One-second delay in brake activation “The problem, due to a software anomaly, only • occurs during the first few seconds of driving when the SUV is moving slowly” • http://www.accidentreconstruction.com/news/apr04/040204a.asp – Dec 2004: Hyundai recalls 120,000 Elantras • Airbag software problem detected in Insurance Institute crash tests (driver side airbag didn’t deploy in crash test) • http://money.cnn.com/2004/12/19/pf/autos/bc.autos.hyundai.recall.reut/index.htm
  • © 2013 IBM Corporation 107 Product and System Innovation Drivers for ISO 26262  German Legislature requires, that safe cars are developed according to state-of the-art technology  You need a defensible process for creating safe software – Consider adopting documented best practices instead of inventing your own – If everyone else adopts MISRA, IEC 61508 or ISO 26262 and you don’t, you might be considered negligent (failure to follow “standard practices”)  ISO 26262 was approved in November 2011
  • © 2013 IBM Corporation 108 Product and System Innovation Scope of ISO 26262 • ISO 26262 (derived from principles in IEC 61508) Functional Safety for EE Systems in passenger vehicles Automotive as opposed to Trucks and Buses Covers the management and technical aspects of the complete safety development lifecycle Takes a risk-based approach for determining risk classes (Automotive Safety Integrity Levels, ASILs). Definition of optional, recommended and highly recommended methods for development activities within system-, hardware and software development depending on defined ASIL • Design safety into the system from the outset • ISO 26262 covers the complete development lifecycle from Lust to Dust • Tool qualification Safety of the design is dependant upon the reliability of the tools used Guidelines for Tool Confidence Levels (TCLs) mapped to ASILs for specific tasks
  • © 2013 IBM Corporation 109 Product and System Innovation What this means for Automotive  All Automotive System development for Electronic and Electrical components need to comply to ISO 26262  Consists of 10 parts  Due to the reuse of a large number of existing elements and pre-existing vehicle architectures the development cycle is seldom a pure top down V-cycle  Means that the safety-lifecycle must be adaptable and flexible  Heavily influenced by the V-model  Made more modular 1 Vocabulary 2 Management of functional safety 10 Guideline on ISO 26262 (informative) 9 ASIL-oriented and safety-oriented analysis 8 Supporting processes 3 Concept phase 4 Product development on system level 5 Hardware development 6 Software development 7 Production and operation DIS 26262DIS 26262
  • © 2013 IBM Corporation 110 Product and System Innovation Manage Evolving Requirements Manage Architecture Accelerate Change & Delivery Improve Project Success Deliver Enduring Quality Deploy Process & Governance Best Practices  Rational Rhapsody  Rational System Architect  Rational Team Concert  Rational Harmony  Rational Unified Process  Rational Asset Manager  Rational Test RealTime  Rational Quality Manager  Rational TestConductor  Rational Team Concert  Rational Synergy / Change- ClearCase / ClearQuest  Rational Build Forge  Rational DOORS  Rational Focal Point  Rational Requirements Composer Rational Tools for Automotive Sector An Integrated Portfolio for Delivering Competitive Advantage and Innovation
  • © 2013 IBM Corporation 111 Product and System Innovation  Rational Team Concert is the enabler for controlling process and managing change  Process template for ISO 26262  Helps with project management  Team management  Task allocation  Integrates with practices that give can guidance on the application of ISO 26262  Configuration management  Integrates with multiple Rational Tools  Rational DOORS for requirements management  Synergy, ClearCase or RTC for Configuration Management  Rational Rhapsody for Model Based Systems Engineering  Removes system design errors early in the development process  Has a safety profile to aid in FMEA, FTA and hazard analysis  Developing an Automotive Safety profile specifically for ISO 26262  Rational Quality manager to plan tests  Rational test conductor to automate tests The IBM Rational product safety and quality management solution
  • © 2013 IBM Corporation 112 Product and System Innovation  Supports all core processes and work products defined in the standard  Process template implemented in Rational Team Concert  Guidance and practices implemented in Rational Method Composer Process template with work items   Web based ISO 26262 guidelines and MBSE practices ISO 26262 RTC and RMC ISO26262 Standard Rational Team Concert Rational Method Composer Guidelines reference ISO 26262 ISO26262 Work productsWork items, products and flows derived from ISO 26262 Workitems linked to process guidance
  • © 2013 IBM Corporation 113 Product and System Innovation RTC ISO 26262 Process and Practice templates  Scope of Process template and guidance covers 95%, phases 2-8*
  • © 2013 IBM Corporation 114 Product and System Innovation Available practices for ISO 26262  Mainly in the areas of supporting practices and around MBSE, SW and test  Work going on with Embedded HW and SW integration 1 Vocabulary 2 Management of functional safety 10 Guideline on ISO 26262 (informative) 9 ASIL-oriented and safety-oriented analysis 8 Supporting processes 3 Concept phase 4 Product development on system level 5 Hardware development 6 Software development 7 Production and operation DIS 26262DIS 26262 Practices for Requirements management Configuration Management Change management
  • © 2013 IBM Corporation 115 Product and System Innovation
  • © 2013 IBM Corporation 116 Product and System Innovation The ISO 26262 Safety Lifecycle
  • © 2013 IBM Corporation 117 Product and System Innovation ISO 26262 Processes and links to Practices
  • © 2013 IBM Corporation 118 Product and System Innovation MBSE Practices
  • © 2013 IBM Corporation 119 Product and System Innovation ISO 26262 scalability and modularity  Process flow is very modular, componentized across Systems, SW or HW or OEM and Subcontractor relationships  Process template also modular to reflect major tasks or phases
  • © 2013 IBM Corporation 120 Product and System Innovation ISO 26262 Process flow  The modular nature of the time lines means that the flow can be adapted  Duplicate the available flows or  Further levels of detail can be applied at the iteration level  The process flow is controlled in the project environment by start and end dates  Make the relevant work task the active iteration in a timeline
  • © 2013 IBM Corporation 121 Product and System Innovation ISO 26262 in Rational Method Composer  RMC captures activities and flows  Flows are generic and reflect ISO 26262  Can be customized to fit your process  Activities and flows Reflected in RTC process template  RTC allows project managers to plan the work and assign tasks to teams  Drill down through activities for more detail  Workflows  Task descriptions  Incoming and outgoing workproducts  Applicable roles
  • © 2013 IBM Corporation 122 Product and System Innovation ISO 26262: Management of functional safety
  • © 2013 IBM Corporation 123 Product and System Innovation ISO 26262: Development Safety Management
  • © 2013 IBM Corporation 124 Product and System Innovation ISO 26262: Development Safety Management
  • © 2013 IBM Corporation 125 Product and System Innovation ISO RTC 26262 Roles  Only two roles specifically defined  Project manager  Safety manager  A number of other roles can be inferred by the nature of the tasks e.g  Software engineer  Safety engineer  Roles defined in the template allow project managers to assign them to team members  Affects what they do  Controlled by permissions (pre set)  Task and work item assignment can be further controlled using teams
  • © 2013 IBM Corporation 126 Product and System Innovation ISO 26262 Teams  Set of predefined teams that map to the concept phases  Need to be populated with team members  Teams can be linked to project phases  Makes it easy for a project manager to allocate the contents of work item template to team  Team leaders assign work items to team members.
  • © 2013 IBM Corporation 127 Product and System Innovation ISO 26262 work item templates  Work item templates are modularized, they cover  Separate safety management section  Main concept phases  Separation of production and operation activities  Aspects of supporting processes
  • © 2013 IBM Corporation 128 Product and System Innovation ISO 26262 work items  Individual activities are children of main task  Individual activities are linked together in flows  Contain basic description that links to details of task
  • © 2013 IBM Corporation 129 Product and System Innovation 129 Some activities which support ISO 26262 compliance  Requirements (DOORS)  26262 Standard should be placed into a requirements database  Drive activities as well as support traceability and verification  Systems Modeling, Simulation, and Auto-Code Generation (Rhapsody)  SysML modeling provides ability to architect overall system – mechanical and E/E and then to execute to verify model  AUTOSAR functionality  Auto-Code Gen  Configuration and Change Management (Rational Team Concert)  Configuration management of E/E In development (baseline and other revisions), as well as configuration management for different option combinations  Change Management for control of ECRs to E/E  Asset Management (Rational Asset Manager)  Substantial documentation requirements  Process (Rational Team Concert and Method Composer)  26262 is very process based  Non-prescriptive: “what to do” as opposed to “how to do”  Verification and verification planning (Test Conductor and Rational Quality Manager)  Lot of emphasis on validation and verification of Systems, HW and SW  Level and type of test dependent upon ASIL of element to be developed
  • © 2013 IBM Corporation 130 Product and System Innovation  Development efforts spent on capabilities that don’t translate into revenue  Address the highest value opportunities by collecting, organizing and prioritizing requirements to derive the highest customer value  Drive engineering with business objectives that meet customer needs  Close the gap between testing and requirements  Changing requirements result in missed expectations from lack of coordination with all stakeholders  Trace requirements to code  Analyze the impact of change  Ensure requirements coverage Quality begins with Requirements Rational DOORS: Manage Evolving Requirements for Systems and Software Deploy Process & Governance Best Practices Manage Evolving Requirements
  • © 2013 IBM Corporation 131 Product and System Innovation Maximize your budget & boost productivity with effective Systems Engineering IBM Rational Rhapsody® software FamilySafety driven Systems Design  Understand Safety requirements early in the development cycle  Design safety into the system to begin with Model Driven Testing:  Bring the benefits of abstraction and automation to testing  Deliver products that meet customer expectations faster, cheaper Simulation, Execution and Automation:  Identify and eliminate errors early when they are less costly to fix  Visually communicate intended behavior to customers to deliver the right product  Perform design level debugging Requirements Driven Testing:  Reduce overall dev costs by dramatically reducing time in the testing phase  Automatic regression testing, Change impact and analysis Simulation Finding & Correcting ErrorsSequence Diagrams Requirements-based testing Automated unit testing Host based Target based
  • © 2013 IBM Corporation 132 Product and System Innovation Safety-Critical Profile in UML for Rhapsody  Brings together model based systems and software development with safety analysis – Safety Analysis profile in Rhapsody allows safety analysis to be carried out  Covers – FTA diagrams – Hazard analysis table view – Constraint table view – Derived safety based requirements  Also offer integration with IKV – Medini tool – Safety analysis – Integrate with Rhapsody and RTC
  • © 2013 IBM Corporation 133 Product and System Innovation Auto-generation of safety-relevant summary data Fault Source Matrix, Fault Detection Matrix, Fault-Requirement Matrix, Hazard Analysis… • Traceability improves your ability to make your safety case • Safety metadata guides downstream engineering work
  • © 2013 IBM Corporation 134 Product and System Innovation Automotive Safety Analysis Profile  Extends the original safety analysis profile  Extended FMEA table into an ASIL table  Captures ISO 26262 specific concepts  SafetyGoal  SafetyRequirement  ASILs for elements  Captures Safety Requirements  ASIL  System/Subsystem Allocation  Requirement type
  • © 2013 IBM Corporation 135 Product and System Innovation Model Driven Testing IBM Rhapsody Test Conductor Test Execution & Test Reporting Design & Test Processes Fully Integrated
  • © 2013 IBM Corporation 136 Product and System Innovation Rational Rhapsody TestConductor integration with Rational Quality Manager  Enables full execution control & management of model based Rhapsody TestConductor test cases from RQM  Execution status (passed/failed) and result reports (Execution Results, Coverage Results) accessible through RQM  RQM can utilize TestConductor execution results to continuously provide transparent & up to date QA statistics and QA reports
  • © 2013 IBM Corporation 137 Product and System Innovation Tool Qualification for ISO 26262  ISO 26262 requires tools “used in the development” of safety related software be qualified – Unlike standards such as DO-178B, ISO 26262 spans tools used across the entire development cycle. (RM, CM, etc).  Within the ISO 26262 standard, there is detailed guidance on tool qualification – Use cases for tools first documented and analyzed – Analysis will evaluate if malfunctioning software tool (or output from tool) can lead to violation of safety requirement – Probability of preventing or detecting such errors is determined. – This leads to Tool Confidence Level (TCL) determination – TCL + ASIL guides how you qualify a tool. • E.g. increased confidence of use is a possible tool qualification method  The ISO/DIS 26262 tool qualification process requires the creation of the following tool qualification work products (ISO/DIS 26262-8, 11.5; see the appendix for a summary) by our customers: – Software Tool Qualification Plan – Software Tool Documentation – Software Tool Classification Analysis .. .For TCL determination. – Software Tool Qualification Report  One step further is to have a independent authority, e.g. TUV (Technical Inspector Association) .. to audit development process to develop tool along with qualification work products.  DOORS and Rhapsody Test Conductor Tool Qualification Kits are available
  • © 2013 IBM Corporation 138 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 139 Product and System Innovation The medical device industry adds several unique issues  Extreme time to market pressures – 1st to market usually gains 80% of that market  Compliance with strict regulations – FDA, IEC and many smaller groups for different countries  Defects are VERY costly to handle – Want to avoid warning letters, recalls, etc...  Most of these products are developed in a geographically distributed way  Safety Critical products (Class I, II and III medical devices)  Need to take user feedback into consideration – Building a device that gets approved isn’t enough, users need to buy it
  • © 2013 IBM Corporation 140 Product and System Innovation Medical device industry needs  Support for compliance  Design control and history  Cross-functional traceability required by IEC/ISO/FDA regulation and CMMI  Ready to run – Development execution with risk management  Safety critical embedded development  Reporting templates and generators  Integration of verification and validation including certification (Intended Use Validation)  Support for on the fly changes to design – Agile development is a key  The ability to reuse what has been developed previously
  • © 2013 IBM Corporation 141 Product and System Innovation Any solution to these issues needs to…  Help manage regulatory compliance  Allow teams to leverage current development practices, like Agile – Without compromising compliance  Allow a team to get up an running quickly  Provide traceability and support for the full development lifecycle – Everything from having a feature request to validating that a product is ready to ship  Help with geographically distributed teams  Help management understand the status of the work as a bi-product of that work – To reduce effort in manual status reporting  Allow reports to be easily generated to support audits – While keeping auditors out of your live systems
  • © 2013 IBM Corporation 142 Product and System Innovation IBM Rational Solution for Medical Devices  Tailors our foundation of tools to specialize for Medical Device Development – Risk Management – Design Control and Design History File – Intended Use Validation – Regulatory compliance for development of medical devices  Process compliance (Example Design and Development Plan) – Documented process description aligned with FDA QSR and IEC 62304 – Tool configuration assets (DOORS, RTC) • DOORS Design Control templates and utilities • RTC process templates • RTC Work item/Plan templates aligned and integrated with process description
  • © 2013 IBM Corporation 143 Product and System Innovation IBM Rational Solution for Medical Device Development Based on Rational’s proven solutions for systems & software engineering • Meet regulatory compliance with enhanced automation and reporting to simplify audits, reputation loss, lawsuits and company collapse • Manage product complexity by integrate requirements and quality management • Reduce time-to-market and cost by early defect detection and removal IBM Rational Solution for Medical Devices extends the core Rational solution with integrated products, practices and guidance for:  Product compliance:  Medical device development specific processes (e.g. IEC 62304)  Traceability in medical device development  Design Control and Intended Use Validation  Evidence of regulatory compliance  Incremental migration to Agile work practices IBM Rational Solution for Systems and Software Engineering Open Lifecycle Integration Best Practices and Services Architecture, Design and Development QualityRequirements Planning, Change/ Configuration Management Visualize, Analyze, and Organize
  • © 2013 IBM Corporation Product and System Innovation A tour of our offering relative to IEC 62304 Source: European Medical Device & Technology, June 2010  Quality management system  RISK MANAGEMENT  Software safety classification  Software development PROCESS – Software development planning – Software requirements analysis – Software ARCHITECTURAL design – Software detailed design – SOFTWARE UNIT implementation and verification – Software integration and integration testing – SOFTWARE SYSTEM testing – Software release  Software maintenance PROCESS  Software RISK MANAGEMENT PROCESS  Software configuration management PROCESS  Software problem resolution PROCESS  Documentation Requirements Gap Analysis 144
  • © 2013 IBM Corporation 145 Product and System Innovation Gap Analysis: DOORS and RMC Determine compliance with IEC 62304 by performing gap analysis 1. Capturing your existing processes in a solution for tagging (Rational DOORS) 2. Identify and tag each of the respective control points in your existing process 3. Capture the IEC 62304 standard as the yardstick to evaluate each of "your processes" control points (Rational DOORS) 4. Display a traceability matrix between the process standard ( IEC 62304) and your process  Identify and remediate process gaps  Document updated process into Rational Method Composer Allows change control, version control, publication, and general oversight of process changes as the process matures. Compliance statement Business Process DefinitionsRegulations Rich tracing 145
  • © 2013 IBM Corporation 146 Product and System Innovation Dashboards Practice library Auto generation of practice work items Starting templates Tool mentors Our IEC 62304 Process Guidance and Enactment Establish sound practices for implementing organization-wide development workflow
  • © 2013 IBM Corporation 147 Product and System Innovation Quality Management System: RQM Make quality management a continuous lifecycle activity  Unify the entire team with a shared view of quality assets  Integrates with Requirements Management to insure Customer needs are met  Intelligent automation to improve accuracy and efficiency  Automated reporting to enhance project decision- making and compliance QA Manager Security Officer Project Manager Tester Business Stakeholder Test Cases Skill Availability Project Logs Use Cases Requirements Security Mandates Defect Logs Business Objectives Quality Asset Infrastructure Central hub captures everything that matters for quality releases QA Manager Security OfficerSecurity Officer Project Manager Project Manager TesterTester Business StakeholderBusiness Stakeholder Test Cases Skill Availability Project Logs Use Cases Requirements Security Mandates Defect Logs Business Objectives Test Cases Skill Availability Project Logs Use Cases Requirements Security Mandates Defect Logs Business Objectives Quality Asset Infrastructure Central hub captures everything that matters for quality releases The MANUFACTURER of MEDICAL DEVICE SOFTWARE shall demonstrate the ability to provide MEDICAL DEVICE SOFTWARE that consistently meets customer requirements and applicable regulatory requirements. Demonstration of this ability can be by the use of a quality management system that complies with: ISO 13485 IBM Rational Quality Manager 147
  • © 2013 IBM Corporation 148 Product and System Innovation Risk Management: Rational DOORS & Rhapsody  Anticipate possible failures of the system Define control measures o Inherently safe, Preventive, Corrective, Informative  Systematic risk analysis is to anticipate failures Top-down: Function analysis - ISO 14971 o Hazard Analysis Bottom-up: Design Analysis – FMEA, FTA o Failure Modes and Effects Analysis  Each failure leads to risk control (RCM) measures  Each RCM leads to requirements implemented in product hardware, software or documentation  Risk Management File documents traceably risk to control measure, to verification of control measure  Risk Management Activities continue after release Document TRACEABILITY of software HAZARDS • From hazardous situation to the SOFTWARE ITEM • From SOFTWARE ITEM to the specific software cause • From the software cause to RISK CONTROL measure • From RISK CONTROL measure to VERIFICATION of • RISK CONTROL measure Hazards Failures RCMs Requirements User Needs System Sub-system Design Implementation Risk Management File Product Function DesignRational DOORS 148
  • © 2013 IBM Corporation 149 Product and System Innovation Common Risk Analysis in medical device development  FMEA: Failure Modes and Effects Analysis – FMEA is a bottom-up, inductive analysis method aimed at analyzing the effects of single component or function failures on equipment or subsystems. – FMEA is good at exhaustively cataloging initiating faults, and identifying their local effects. – FMEA is not good at examining multiple failures or their effects at a system level. – FMEA does not consider external events.  FMECA extends FMEA by including a criticality analysis, which is used to chart the probability of failure modes against the severity of their consequences. – The result highlights failure modes with relatively high probability and severity of consequences, allowing remedial effort to be directed where it will produce the greatest value.  FTA: Fault Tree Analysis – FTA is a deductive, top-down method aimed at analyzing the effects of initiating faults and events on a complex system. – FTA is very good at showing how resistant a system is to single or multiple initiating faults. – FTA is not good at finding all possible initiating faults. – FTA considers external events.
  • © 2013 IBM Corporation 150 Product and System Innovation Hazard Analysis & FMEAs within Rational DOORS
  • © 2013 IBM Corporation 151 Product and System Innovation FTAs: Diagramming potential fault cascades in Rhapsody Safety Eng. Process Lead Project Manager Integrated Safety, Requirements DesignIntegrated Safety, Requirements Design Safety Elements Design Elements Requirements What Hazards have no safety requirements? A System Requirement changed…did that effect my Safety Analysis? Do I address all the safety requirements and hazards in my design?
  • © 2013 IBM Corporation 152 Product and System Innovation Software Safety Classification  Typical Safety Critical Workflow – Implement code from textual requirements – Test only on target late in development cycle  Safety Critical with Model-Driven Development – Consistent Design, Code and Documentation – Visualization of complex requirements – High quality code generation (tool dependent) – Test Driven Development support • Early functional verification on host, detect bugs early in development – Harmony for Embedded RealTime™ process defines a safety workflow and provides guidance – Safety analysis profile supports FTA, FMEA, FMECA and Hazard analysis – supports safety classification and compliance to section 4.3 of IEC 62304 152 Safety Critical with MDD: Rational Rhapsody
  • © 2013 IBM Corporation 153 Product and System Innovation Software Development Product Development and Verification Life Cycle (Process) Implementation Software Unit Test DEFINITION / DEVELOPMENT TEST / VERIFICATION Change Management and Problem Reporting Configuration Management ProjectPlanningandAssessment Requirement Traceability Requirements Capture and Analysis System Analysis and Design Software Design Component Integration and Test System/Subsystem Integration and Test System Acceptance Validating the Product  Traceability for Test Coverage  Verifying the System Qualifying the ComponentsRequirement Traceability Requirement Traceability DOORS DOORSRhapsody DOORSRhapsody Rhapsody Rhapsody RhapsodyRQM RhapsodyRQM RQM RTC RiskManagementandSafetyAssessmentProcess RTC DOORS Rhapsody The Software Development Process and Tooling Rational DOORS, Rational Rhapsody, Rational Team Concert, Rational Quality Manager, Rational Publishing Engine Integratedcoverageofthesoftwareandsystems engineeringlifecycle (includescompliancecoverageforSOUP) Automate Document Generation RPE 153 Design History File IEC62304section5
  • © 2013 IBM Corporation 154 Product and System Innovation IBM Requirements Engineering Solution Capture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring Business Analysis Product Management Test & MaintenanceAnalysisIdeas Implementation Requirements DefinitionRequirements Definition Requirements ManagementRequirements Management Systems/Product Analysis & Implementation Disposal  Improves visibility of and collaboration on requirements for all product stakeholders  Comprehensive support for recording, structuring, managing, and analyzing requirements and their traceability  Supports FDA 21 CFR Part 11 compliant electronic signatures for signing off requirements baselines for IEC 62304 compliance  Integrates with portfolio management, modeling, change management and quality management solutions for a full lifecycle solution  Can manage requirements across multiple engineering disciplines - Software, Electronic & Mechanical  Scalable from small to large projects with distributed teams Requirements Engineering with Rational DOORS Manage All Requirements Across Lifecycle and Disciplines 154
  • © 2013 IBM Corporation 155 Product and System Innovation  Visualize requirements and build architecture  Integrates requirements, design and implementation  Execution validates requirements  Facilitates communication across disciplines  Impact analysis of changes in requirements or design Trace requirements to design and implementation Requirement information generated in code Model Driven Analysis and Design using Rational Rhapsody and Rational DOORS 155 The MANUFACTURER shall transform the requirements for the MEDICAL DEVICE SOFTWARE into a documented ARCHITECTURE that describes the software’s structure and identifies the SOFTWARE
  • © 2013 IBM Corporation 156 Product and System Innovation Increase Productivity through Continual Testing  Eliminate errors as they are introduced – Before they become too expensive to find and repair  Simulate often to validate functionality and verify correctness  Automatically create and execute tests against design model or target platform – Create test harnesses for unit testing  Manage test cases using Rational Quality Manager Powered by using Rational Rhapsody 156
  • © 2013 IBM Corporation 157 Product and System Innovation Test Cases Use Cases Requirements Audit Trail Compliance Defect Management Quality Hazard Analysis Project Manager V & V Design / Dev Regulatory Affairs Business Stakeholder Test plans are more than just test cases!  Collect and track all quality-related data Central location for business objectives, requirements, test plans, test results, and resources  Defined Responsibilities Individual sections are assigned to team members to clearly establish ownership  Goal Oriented Formalized and documented acceptance criteria  Keep track of changes Snapshot version control to track plan history throughout the life of the project Collaborate and capture everything that matters for quality releases and compliance A Quality Management System Comprehensive rich test plan to comply with IEC 62304 Rational Quality Manager 157
  • © 2013 IBM Corporation 158 Product and System Innovation Configuration, Change, Maintenance Management Establish an integrated change process across the lifecycle Testing Eco-system Develop Model-Driven System -> Software Collaboration, Process, Workflow Execute Tests Capture & manage requirements Integrated Change Management Configuration Management Integrate Suppliers Capture customer requests, problems & market driven enhancements Mechanical Collaborate across Development Disciplines Electrical Software Project planning and assessment using Rational Team Concert 158
  • © 2013 IBM Corporation 159 Product and System Innovation Software maintenance PROCESS  Build efficient embedded software that exactly matches the design intent Specify and test deployable source code from the system requirements Generate complete C, C++, Java, and Ada applications – including behavior  Maintain automated synchronization between model and code Simultaneously work with the architecture, software and target View how a change in any one area is reflected in the others Software Generation Improve maintenance and Serviceability by Visualizing existing code using Rhapsody 159
  • © 2013 IBM Corporation 160 Product and System Innovation  Collaborate in-context  Integrated work items, process guidance, reporting, chat  Streamline change  Out-of-the-box, Customizable Workflows  Implement “virtual” Change Control Boards  Automate compliance & traceability  eSignatures to help support 21 CFR Part 11 compliance  Automated data capture  Support for CMMI compliance  Project Health, Project Transparency  Assess project status and trends in real-time  Web-based dashboards, metrics and reporting  Powerful querying  Customized views for end user roles  Scale to the enterprise  Small teams to 1000’s of contributors and stakeholders  Integrate a broad array of tools and clients Innovation through Collaboration with our Jazz based products, including Rational Team Concert 160 The MANUFACTURER shall monitor feedback on released SOFTWARE PRODUCT from both inside its own organization and from users.
  • © 2013 IBM Corporation 161 Product and System Innovation Automate Document Generation Generate the right document at the right time  Increase productivity by allowing engineers to focus on engineering  NOT formatting concerns  Maintain accuracy through quick one-click document generation  Captures last minute changes from data held in different source applications  Enhance documentation quality thru template reuse Rational Publishing Engine 161 Compliance is determined by inspection of all documentation required by this standard including the RISK MANAGEMENT FILE, and assessment of the PROCESSES, ACTIVITIES and TASKS required for the software safety class. This standard does not prescribe the name, format, or explicit content of the documentation to be produced… the decision of how to package this documentation is left to the user of the standard.
  • © 2013 IBM Corporation 162 Product and System Innovation Process Guidance Based on Industry Standards  The method website includes: – Design Control Solution: Systems engineering process aligned with the FDA Quality System Regulations – Intended Use Validation: Validation activities required by the FDA to demonstrate COTS software is appropriate for use in and FDA regulated environment – IEC 62304: Details of a software development process aligned with the IEC standard for medical device software.
  • © 2013 IBM Corporation 163 Product and System Innovation Medical Device Practice Content  Practice content developed and delivered through Rational Method Composer  Published as a web site  Linked to tools
  • © 2013 IBM Corporation 164 Product and System Innovation Design Control Solution
  • © 2013 IBM Corporation 165 Product and System Innovation Intended Use Validation
  • © 2013 IBM Corporation 166 Product and System Innovation IEC 62304 Process Content
  • © 2013 IBM Corporation 167 Product and System Innovation Systems Engineering Lifecycle Delivery Process
  • © 2013 IBM Corporation 168 Product and System Innovation Medical Device Software Development Delivery Process
  • © 2013 IBM Corporation 169 Product and System Innovation Summary: Rational’s Solution for Medical Device Development promotes consistency and efficiency, with step by step adoption  Proven practices for Systems & Software Engineering – Includes CMMI – Addresses Safety & Security of complex systems  “Ready to run” FDA QSR and IEC 62304 templates – Process compliance – Engineering activity – Quickly on-board members into projects  Tool mentors and templates – Drive productivity – Specific capabilities for safety, reliability and security engineering, e.g. FMEA, FTA, traceability matrices  Dashboards – Reduce time for reporting – Alerts for out of line situations IBM Rational Solution for Systems and Software Engineering Open Lifecycle Integration Best Practices and Services Architecture, Design and Development QualityQualityRequirementsRequirements Planning, Change/ Configuration Management Visualize, Analyze, and Organize Visualize, Analyze, and Organize
  • © 2013 IBM Corporation 170 Product and System Innovation Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 171 Product and System Innovation SSE Information Center  SSE information center covering Installation, Configuration, Troubleshooting  URL: http://pic.dhe.ibm.com/infocenter/rssehelp/v1r0m0/index.jsp
  • © 2013 IBM Corporation 172 Product and System Innovation Additional Resources  Client stories – Invensys Rail Dimetronic (video, case study) – General Motors (case study and videos)  Self Assessment on System Engineering – Tips to increase profit margins by Aberdeen Group  Systems Engineering for Dummies ebook  Learn more about the Rational solutions for systems and software engineering – Web page – Podcast: Systems & Software Engineering Practices – Unleash the Potential!
  • © 2013 IBM Corporation 173 Product and System Innovation Jazz.net https://jazz.net/products/sse/ Explore and Participate in the SSE Solution on Jazz.net
  • © 2013 IBM Corporation 174 Product and System Innovation Process Customization Resources  Practice Assets – http://www-01.ibm.com/support/docview.wss?rs=2360&uid=swg24030663  Creating RTC Process Templates from RMC – https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang =en#/wiki/W6b0a089a62f3_4493_bcc1_ebe60a2ebb41/page/Integrating%20with%20Rational%20Te  Process Customization Demo Recordings – http://bit.ly/dVxoyK
  • © 2013 IBM Corporation 175 Product and System Innovation 175 Agenda  Context and challenges  Applying systems engineering to the development system  The core systems and software engineering practices  DO178B  ISO26262  IEC 62304  Additional Resources  Workshop on Practice Library Customization – Practices, A Closer Look – Hands-On Work
  • © 2013 IBM Corporation 176 Product and System Innovation IBM Rational solution for systems and software engineering  A modern, multi-disciplinary, collaborative solution for delivering smarter systems and products that was defined, built and tested as a system  Supports a measured improvement model for incremental adoption of methods and tools with measurable return on investment at each and every stage  Built on a flexible architecture that supports integration with existing tools, incremental improvement, and tailoring to meet your evolving needs  Practice (methods)  10 systems engineering practices  6 embedded software engineering practices  A lifecycle model/workflow  V Model  Collaborative tools  Rational DOORS  Rational Rhapsody  Rational Quality Manager  Rational Team Concert  Services  Deployment  Adoption  Tailoring
  • © 2013 IBM Corporation 177 Product and System Innovation How are practices and process presented to practitioners? A dashboard in RTC A Published Process Best Practices, tool mentors, tool config assets, metrics Work items in RTC based on Process Tasks Learn and check how to use a Practice Check progress Understand tasks and deliverables My Process guidance feed Guidance to Execute my tasks Track progress on tasks Collaborate with colleagues Templates and guidance in RQM, DOORS, Rhapsody Artifact templates & sample Artifacts Process guidance in context
  • © 2013 IBM Corporation 178 Product and System Innovation Incremental solution adoption – DOORS entry point Entry Point Add Capability Add Capability Add Capability Client looking to better capture and communicate stakeholder need Need a more flexible way to handle evolving customer demands Need a more formal method to capture, analyze, and share system designs Need a more rigorous to system validation and quality management DOORS Requirements Driven Engineering RTC Add Requirements Change Management & Work Item Management Rhapsody Add System architecture modeling and design analysis RQM Add Requirements driven test management Measure Total number of Reqs Req Volatility Number of req sourced defects Measure Req changes Work item throughput Measure Number of design sourced defects Rate of design maturity Measure Total number of test cases Level of test coverage Defect identification PSO DOORS Quickstart DOORS Upgrade PSO Introducing RTC Assessment RTC QuickStart PSO Rhapsody Deployment Package Harmony Workshop PSO RQM QuickStart These adoption models assume a whitespace client. For existing customers choose an alternate entry point down the thread.
  • © 2013 IBM Corporation 179 Product and System Innovation How do customers access our practice content? Option 1 Each content consumer requires an RMC Content Reader License Customer does not need to deploy RMC for this option Client wishes to use IBM method content without changes How? Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment Licensing Option 2 Each tooling user requires an RMC Author License (AU, Floating, Token) Each content consumer requires an RMC Content Reader License Client wishes to blend a combination of IBM method content with homegrown content How? RMC tooling for method authoring Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment Licensing Option 3 Client wishes deploy only homegrown process content (all non-derivative) How? RMC tooling for method authoring Usage via published website / document, guidance such as templates & checklists, indirect or derivative works such as project plans, and enactment LicensingEach tooling user requires an RMC Author License (AU, Floating, Token) content consumers do not require a license
  • © 2013 IBM Corporation 180 Product and System Innovation Practices Customization Workshop Agenda • Background and Review • Current solution process-related assets • Rational Method Composer – Content Architecture • Customization Scenarios
  • © 2013 IBM Corporation 181 Product and System Innovation Practices - modular solution components Guidance for software & systems development, management, governance, and more  A practice is an approach to solving one or several commonly occurring problems – Practices are intended as "chunks" of process for adoption, enablement, and configuration – Address one aspect of the development process that can span disciplines/domains/lifecycle.  Practices apply the concepts of “components” or “services” to process management – Include associated tool guidance and tool configuration assets – Include recommended metrics to assess practice adoption (process metrics) and project status (product/project metrics) – Generally re-usable across a variety of lifecycle models  Practices enable a compositional approach to building methods with the following benefits: – Adaptability and scalability – Mapped to operational objectives – Incremental adoption – Easy to configure and use – Enable community development Results:  Avoids self-inflicting too much process  Faster and more predictable results  Measured Improvement Practice - Table of Contents  Motivation – why do it, benefits  How to adopt this practice  Enablement, and reference material  Key Concepts  Work Products – what you produce  Tasks – what you do  Guidance – how you do it  Tools guidance for executing the tasks  Recommended Metrics/Measurements  Related practices
  • © 2013 IBM Corporation 182 Product and System Innovation IBM Rational Method Composer  IBM Rational Method Composer (RMC) is comprised of: Tooling that provides capabilities to:  create and maintain well-architected libraries of structured process assets,  create organizational standard and project specific process descriptions, and  to publish these processes in easy to consume formats to help practitioners execute. Methods in a “customizable process library” that includes IBM Practices, the Rational Unified Process (RUP) and various domain specific extensions  Can be used as-is, customized, or leveraged to augment your own processes
  • © 2013 IBM Corporation 183 Product and System Innovation Rational Method Composer - Tooling
  • © 2013 IBM Corporation 184 Product and System Innovation Rational Method Composer – Methods
  • © 2013 IBM Corporation 185 Product and System Innovation SSE Method Libraries and Process Based Content  SSE Solution – One method library – Three process content websites for the SSE Foundation • Use Case Driven Systems Engineering • Requirements Driven Systems Engineering • Embedded Software Development – One process content web-site for the A&D Solution • DO-178B/C Compliant Software Development – One process content web-site for the Automotive Solution • ISO 26262 Compliant Product Development (System and Software) – One process content web-site for the Medical Devices Solution • Design Control Solution Guidance and IEC 62304 Compliant Software Development http://www-01.ibm.com/support/docview.wss?rs=2360&uid=swg24030663
  • © 2013 IBM Corporation 186 Product and System Innovation Enterprise Practices  The IBM Rational Enterprise Practices The Enterprise Practices provide a proven starter set for selected aspects of overall project management through measurement of performance. They can be incrementally adopted. Two initial Enterprise Practices are listed below: – Managing Performance through Measurements – Setting up a Performance Measurement System The Enterprise Practices are included in the Systems Engineering Process Content website
  • © 2013 IBM Corporation 187 Product and System Innovation Systems Engineering Practices  The IBM Rational Systems Engineering (SE) Practices The SE Practices provide a proven starter set for selected aspects of the Systems lifecycle. They can be incrementally adopted. The documentation provides two different delivery processes, representing two examples on how to combine and use these SE practices – one focusing on use case driven system development, and a second based on a more traditional V development model. Fourteen initial SE Practices are listed below: – Release Planning – Project Process Tailoring – Iterative Development – Reviews – Shared Vision – Elaborate Draft Systems Requirements Specification – Build and Validate Use Cases – Architectural Analysis - Key System Functions – Trade Study – Weighted Objectives Method – Architectural Design - Use-Case based – Joint Realization – Preparation for Downstream Engineering – Formal Change Management – Test Management
  • © 2013 IBM Corporation 188 Product and System Innovation Systems Engineering Lifecycle Delivery Process
  • © 2013 IBM Corporation 189 Product and System Innovation Use Case Focused Systems Engineering Delivery Process
  • © 2013 IBM Corporation 190 Product and System Innovation Embedded Software Engineering Practices  The IBM Rational Embedded Software Engineering (ESW) Practices The ESW Practices provide a proven starter set for selected aspects of the Embedded Software lifecycle to complement the SE Practices. They can be incrementally adopted. Six initial ESW Practices are listed below:: – High-Fidelity Modeling – Real-Time Architectural Design – Real-Time Collaborative (“Mechanistic”) Design – Real-Time Detailed Design – Model-Based Testing – Safety and Reliability Analysis
  • © 2013 IBM Corporation 191 Product and System Innovation Embedded Software Development Delivery Process
  • © 2013 IBM Corporation 192 Product and System Innovation Accessing Practice Content in the Image  The index.htm file that will load the process content associated with each project can be found in the process folder inside the webapps folder of the jazz server as shown below – Note the jazz server must be up and running prior to opening the index.htm file  Alternative, after the jazz server is started, you can open a browser to: – https://<server_URI>:<port>/<process_folder>
  • © 2013 IBM Corporation 193 Product and System Innovation SSE Solution – Process-related Assets  IBM Rational Solution Process Assets
  • © 2013 IBM Corporation 194 Product and System Innovation SSE Solution – Navigation • Start with the Welcome and Getting Started folder • Delivery Processes: focus on Activities and Tasks • Roles Sets: role-based filter through the entire content • Tools: tool-centric view
  • © 2013 IBM Corporation 195 Product and System Innovation SSE Solution – RTC Process Description A project created based on the SE Process Template includes a link to the SE published website
  • © 2013 IBM Corporation 196 Product and System Innovation SSE Solution – RTC WI Templates Create Work Items based on the SE WI Templates A Work Item created based on one of the SE WI Templates includes a link to the Task description
  • © 2013 IBM Corporation 197 Product and System Innovation SSE Solution – Change Handling Use the Change Handling WI Template to take advantage of the RTC/DOORS integration A Work Item created based on one of the SE WI Templates includes a link to the Task description. Follow the link for more information.
  • © 2013 IBM Corporation 198 Product and System Innovation RMC Content Architecture  Main content areas: – Core – Practice – Process – Publish – Configurations
  • © 2013 IBM Corporation 199 Product and System Innovation RMC Content Architecture – SSE plug-ins SSE Solution plug-in locations:  SE  Real-time  DO178  ISO26262
  • © 2013 IBM Corporation 200 Product and System Innovation Customization Scenarios  Pre-requisites: – RMC 7.5.1 – Updated RMC Library: IBM Rational Solution Process Assets – Customer requirements  Environment-driven  Process-driven
  • © 2013 IBM Corporation 201 Product and System Innovation Environment-driven Customization Scenario 1. Create the plug-in (if not there) 2. Add a package for tool mentors and one for contributions/assignments 3. Create a tool mentor and fill in the description fields based on the customer’s input 4. Assign it to the task which is supporting 5. Create the tool element and assign the tool mentor to it 6. Add a practice contribution to the main practice for the AM tool
  • © 2013 IBM Corporation 202 Product and System Innovation Create a new method plug-in named practice.tech.syseng.arch_analysis_key_sys.extend_itool-def Add the reference to the base plug-in Make sure to save your changes throughout this exercise
  • © 2013 IBM Corporation 203 Product and System Innovation Add new content packages named: Assignments Tool Mentors Add a new tool mentor and specify the Name, Presentation Name, Brief Description, and Main Description
  • © 2013 IBM Corporation 204 Product and System Innovation Add a new tool and specify the Name and Presentation Name Add the Tool Mentor created on the previous slide to list of tool mentors belonging to the tool
  • © 2013 IBM Corporation 205 Product and System Innovation Add a new task that will contribute to the base task Specify the name, and set the Content Variability
  • © 2013 IBM Corporation 206 Product and System Innovation Add the tool mentor created earlier into the Guidance tab
  • © 2013 IBM Corporation 207 Product and System Innovation Add new guidance that will contribute to the base practice Specify the name, and set the Content Variability
  • © 2013 IBM Corporation 208 Product and System Innovation Add the tool created earlier into the References tab
  • © 2013 IBM Corporation 209 Product and System Innovation Environment-driven Customization Scenario - cont 7. Make a copy/paste of the SE Acc configuration, rename it to xyz and add the new plug-ins to the configuration 8. Go to the Browsing Perspective and show the new elements
  • © 2013 IBM Corporation 210 Product and System Innovation Process-driven Customization Scenario 1. Reuse the already plug-in and create another package for Tasks 2. Add an XYZ company specific task: as an example, Review Current Solutions 3. Add the new task to the Practice main description, by adding it to the references list of the practice contributor
  • © 2013 IBM Corporation 211 Product and System Innovation Process-driven Customization Scenario - cont 4. Create a new “process” plug-in, under the process node: process.syseng.base-xyz 5. Create a new CP, use the existent one for reference, add the new task, and then create an activity diagram 6. Copy over the main delivery process where this workflow is used and replace the original Architectural Analysis activity with the new one (new name SE XYZ) 7. Deselect the original process plug-in and add the XYZ one
  • © 2013 IBM Corporation 212 Product and System Innovation Process-driven Customization Scenario – Export WI Template • Right-click on the Capability Pattern you want to export as a WI Template: all the sub-activities and tasks marked as planned will be exported. • Choose “Use RMC URLs” • In the SE case, the Base Content URL should be /SE_UC • For the other solutions you need to use /ESW, /do178 or /iso26262 • Save the file in a local directory
  • © 2013 IBM Corporation 213 Product and System Innovation Process-driven Customization Scenario – Import WI Template • Go to File/Import in RTC • Select “Work Item Template” • Choose the Project Area where you want to install the new WI Template
  • © 2013 IBM Corporation 214 Product and System Innovation © Copyright IBM Corporation 2011. 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.