IBM Rational Solution for Systems and Software Engineering Overview

© 2013 IBM Corporation
IBM Rational Solution for Systems and
Software Engineering
Practices and Delivery Processes

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

3
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…

4
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

5
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

6
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

7
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

8
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

9
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
Architecture,
Design and
Development
QualityQualityRequirementsRequirements
Planning, Change/
Configuration
Management
Visualize,
Analyze, and
Organize
Visualize,
Analyze, and
Organize

10
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

11
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

12
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…

13
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

14
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)

15
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

16
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

17
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

18
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

19
Managing Performance through Measurements
 This practice leverages the use and analysis of data from the Performance Measurement
System to better support key business decisions.

20
Setting up a Performance Measurement System
 This is a practice for establishing a Performance Measurement System to support timely,
informed decisions.

21
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

22
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.

23
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.

24
Iterative Development
 Create a solution in increments. Each increment
is completed in a fixed period of time, an
iteration.

25
Reviews
 This practice provides guidance on how to conduct reviews.

26
Shared Vision
 This practice supports defining and communicating an overall vision for the project.

27
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.

28
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

29
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.

30
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.

31
Architectural Design - Use-Case based
 This practice describes a use-case based approach of defining the system architecture.

32
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.

33
Preparation for Downstream Engineering
 This practice describes the main activities
supporting the handoff from Systems
Engineering.

34
Formal Change Management
 This practice explains what formal change
management is, and how you can implement
this practice in your projects.

35
Test Management
 This practice describes the process of
managing the testing effort.

36
Systems Engineering Lifecycle Delivery Process

37
Use Case Focused Systems Engineering Delivery Process

38
Systems Engineering Process Content Website

39
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

40
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).

41
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.

42
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.

43
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.

44
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.

45
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.

46
Embedded Software Development Delivery Process

47
Embedded Software Development Process Content Website

48
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

49
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

50
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.

51
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)
Reader License
Client wishes to blend a
combination of IBM method
content with homegrown
content
How?
RMC tooling for method
authoring
document,
enactment
Licensing
Option 3
Client wishes deploy only
homegrown process content
(all non-derivative)
How?
authoring
document,
enactment
LicensingEach tooling user
content consumers
do not require a license

52
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

53
 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

54
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)

55
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

56
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

57
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

58
 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

59
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

60
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

61
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

62
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

63
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.

64
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

65
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

66
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

67

68
Rational Solutions for DO178B: Links to DO-178B Objectives

69
Rational Solutions for DO178B: Links by Safety Level

70
Rational Solutions for DO178B: Links to DO-178B Objectives

71
Rational Solutions for DO178B: Process Overview

72
Rational Solutions for DO178B: Iterative Development (Microcycle)

73
Rational Solutions for DO178B; High-Fidelity Modeling

74
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.

75
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.

76
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

77
Hazard Analysis

78
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

79
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

80
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

81
Creating Safety View in UML

82
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

83
Fault Tree Analysis (FTA)
Fault Tree Analysis determines what combinations of conditions
or events are necessary for a hazard condition to occur

84
Example Fault Tree Analysis

85
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

86
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

87
6. Implement Safety
8. Test, Test, Test
Initial Safety Analysis
(within Prespiral Planning)

88
Agile Safety Analysis Update
(within microcycle iterations)
6. Implement Safety
8. Test, Test, Test

89
Hazard Table (generated)
Hazard Description Metadata

90
FTA Hypoxia Hazard
Normal Event
Transfer
Operator
Undeveloped
Fault
Hazard
Basic Fault
AND operator
Resulting
Condition
OR operator

91
FTA Gas Flow Problem

92
FTA Gas Connection Problem

93
Fault Table

94
Connecting FTA to Requirements (TraceToReq)

95
Fault-Requirement Matrix (generated)

96
Analysis Model of the SleepyTime Machine

97
Analysis Model of the Ventilator Subsystem

98
FTA Hypoxia Hazard with Design Elements

99
FTA Connection Problem with Design Elements

100
Fault-Source Matrix (generated)

101
Fault Detection Matrix (generated)

102
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

103
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

104
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

105
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

106
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

107
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

108
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

109
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

110
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

111
 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

112
 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

113
RTC ISO 26262 Process and Practice templates
 Scope of Process template and guidance covers 95%, phases 2-8*

114
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

115

116
The ISO 26262 Safety Lifecycle

117
ISO 26262 Processes and links to Practices

118
MBSE Practices

119
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

120
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

121
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

122
ISO 26262: Management of functional safety

123
ISO 26262: Development Safety Management

124
ISO 26262: Development Safety Management

125
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

126
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.

127
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

128
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

129
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

130
 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

131
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

132
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

133
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

134
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

135
Model Driven Testing
IBM Rhapsody Test Conductor
Test Execution &
Test Reporting
Design & Test
Processes Fully
Integrated

136
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

137
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

138
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

139
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

140
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

141
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

142
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

143
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
Architecture,
Design and
Development
QualityRequirements
Planning, Change/
Configuration
Management
Visualize,
Analyze, and
Organize

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

145
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

146
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

147
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

148
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

149
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.

150
Hazard Analysis & FMEAs within Rational DOORS

151
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?

152
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

153
Software
Development
Product Development and Verification Life Cycle (Process)
Implementation Software Unit
Test
DEFINITION / DEVELOPMENT TEST / VERIFICATION
Change Management and Problem Reporting
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

154
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

155
 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

156
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

157
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

158
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
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

159
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

160
 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.

161
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.

162
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.

163
Medical Device Practice Content
 Practice content developed and delivered through Rational
Method Composer
 Published as a web site
 Linked to tools

164
Design Control Solution

165
Intended Use Validation

166
IEC 62304 Process Content

167

168
Medical Device Software Development Delivery Process

169
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
Architecture,
Design and
Development
QualityQualityRequirementsRequirements
Planning, Change/
Configuration
Management
Visualize,
Analyze, and
Organize
Visualize,
Analyze, and
Organize

170
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

171
SSE Information Center
 SSE information center covering Installation, Configuration, Troubleshooting
 URL: http://pic.dhe.ibm.com/infocenter/rssehelp/v1r0m0/index.jsp

172
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!

173
Jazz.net
https://jazz.net/products/sse/
Explore and
Participate in the
SSE Solution on
Jazz.net

174
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

175
175
Agenda
 DO178B
 ISO26262
 IEC 62304
– Hands-On Work

176
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

177
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

178
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.

179
How do customers access our practice content?
Option 1
Reader License
Customer does not need to
deploy RMC for this option
Client wishes to use IBM
method content without
changes
How?
document,
enactment
Licensing
Option 2
Each tooling user
Reader License
Client wishes to blend a
combination of IBM method
content with homegrown
content
How?
authoring
document,
enactment
Licensing
Option 3
Client wishes deploy only
homegrown process content
(all non-derivative)
How?
authoring
document,
enactment
LicensingEach tooling user
content consumers
do not require a license

180
Practices Customization Workshop Agenda
• Background and Review
• Current solution process-related assets
• Rational Method Composer – Content Architecture
• Customization Scenarios

181
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

182
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

183
Rational Method Composer - Tooling

184
Rational Method Composer – Methods

185
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

186
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

187
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

188

189
Use Case Focused Systems Engineering Delivery Process

190
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

191
Embedded Software Development Delivery Process

192
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>

193
SSE Solution – Process-related Assets
 IBM Rational Solution Process Assets

194
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

195
SSE Solution – RTC Process Description
A project created based on the
SE Process Template includes
a link to the SE published
website

196
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

197
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.

198
RMC Content Architecture
 Main content areas:
– Core
– Practice
– Process
– Publish
– Configurations

199
RMC Content Architecture – SSE plug-ins
SSE Solution plug-in
locations:
 SE
 Real-time
 DO178
 ISO26262

200
Customization Scenarios
 Pre-requisites:
– RMC 7.5.1
– Updated RMC Library: IBM Rational Solution Process Assets
– Customer requirements
 Environment-driven
 Process-driven

201
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

202
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

203
Add new content packages named:
Assignments
Tool Mentors
Add a new tool mentor and
specify the Name, Presentation
Name, Brief Description, and
Main Description

204
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

205
Add a new task that will
contribute to the base task
Specify the name, and
set the Content
Variability

206
Add the tool mentor
created earlier into the
Guidance tab

207
Add new guidance that will
contribute to the base practice
Specify the name, and
set the Content
Variability

208
Add the tool created
earlier into the
References tab

209
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

210
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

IBM Rational Solution for Systems and Software Engineering Overview

IBM Rational Solution for Systems and Software Engineering Overview

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie IBM Rational Solution for Systems and Software Engineering Overview

Ähnlich wie IBM Rational Solution for Systems and Software Engineering Overview (20)

Mehr von IBM Rational software

Mehr von IBM Rational software (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

IBM Rational Solution for Systems and Software Engineering Overview

Hinweis der Redaktion