Model Based Systems and Software Engineering an overview of the IBM Rational solution

© 2013 IBM Corporation
Innovation for a smarter planet
Model Based Systems and Software Engineering
an overview of the IBM Rational solution
Edmund Mayer, Systems Solution Architect
20 June 2013

Software and Systems Engineering | Rational
Abstract topics
Capturing and enacting workflow descriptions with Method Composer
Project planning and collaboration with Team Concert
– Work management
– Change and process management
– Dashboard and metrics
Systems and software development with DOORS and Rhapsody
Document publishing with Publishing Engine
Model based test with Rhapsody TestConductor
2 2

3
IBM Rational Solution for DO-178C
Process Definition and Enactment
Testing
3

IBM Rational Solution for DO178B/C
A set of practices, customizable process guidelines, and compatible products to
help organizations develop products for certification under DO-178B/C
Goal – to help provide evidence of the consistent development of safe software
in a cost-effective, efficient, and productive manner
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

Rational solution for Systems and Software Engineering
QUALITY MANAGEMENT
Achieve “quality by design” with an
integrated, automated testing process
ARCHITECTURE & DESIGN
Use modeling to validate requirements, architecture
and design throughout the development process
REQUIREMENTS MANAGEMENT
Manage all system requirements
with full traceability across the lifecycle
BEST PRACTICES AND SERVICE OFFERINGS
Open Services for Lifecycle Collaboration
COLLABORATION, PLANNING & CHANGE MANAGEMENT
Collaborate across diverse engineering disciplines and development teams
5

The SSE solution uses both Jazz and OSLC tool integrations
OSLC tools:
• DOORS 9.5
• SA
• Rhapsody
• ….
Jazz tools:
• RTC
• RQM
• DOORS NG
• RDM
• …..

7
Testing
7

IBM Rational Solutions for DO178-C
process adoption made easy
Role-based guidance available as a web site
Integrated Software Development Process for DO-178B/C (ISDP-178)

Characteristics of effective process management and use
Authoring and capturing process descriptions
Tailoring and configuring process content
Process reuse
Deploying and accessing process information (in context)
Process enactment and workflow enforcement
9

Integrated process and tools
Process enactment through a Rational Team Concert (RTC) “process template”
Easy creation of work
assignments consistent
with the documented
practice content
Assignable to team
members
Visible in dashboards
Alerts and feeds
available

Rational Team Concert (RTC) Plan Definition

Rational Team Concert (RTC) Plan Definition
Unified view of Information
– What - Work Items
– Who – Project Area / Team Area
– When – Iteration

13
Process support across the development organization
Sample showing different development teams following different processes

14

Demonstration overview
Create new DO-178C project
– Process template – roles, plans, views, work items
Review System-level project
– Personal and mini dashboards
– Update plan for changes
15 15

16

17
Testing
17

18
Manage requirements across lifecycle and across disciplines
using Rational DOORS
1. 820.30(b) Design and Development Planning
Eachmanufacturer shall establishandmaintainplans that describe or reference the designanddevelopment
activities anddefine responsibility for implementation.
The plansshall identifyanddescribe the interfaceswithdifferent groups or activitiesthat provide, or result
in, input tothe designanddevelopment process.
The plansshall be reviewedas designanddevelopment evolves.
The plansshall be updated as designanddevelopment evolves.
The plansshall be approved asdesignanddevelopment evolves.
2. 820.30(c) DesignInput
2.1. Eachmanufacturer shall establishprocedures to ensure that the designrequirements relatingto a
device are appropriate and addressthe intended use of the device, includingthe needsof the user
andpatient.
2.2. Eachmanufacturer shall maintainprocedures to ensure that the designrequirements relatingto a
andpatient.
2.3. The procedures shall include a mechanismfor addressingincomplete requirements.
2.4. The procedures shall include a mechanismfor addressingambiguous requirements.
2.5. The procedures shall include a mechanismfor addressingconflicting requirements.
2.6. The designinput requirements shall be documentedbya designatedindividual(s).
2.7. The designinput requirements shall be reviewedby a designatedindividual(s).
2.8. The designinput requirements shall be approvedbya designatedindividual(s).
2.9. The approval, including the date andsignature of the individual(s) approving the requirements,
shall be documented.
2.10.Questions.
2.10.1. Summarize the manufacturer'swrittenprocedure(s) for identification and control of
designinput.
2.10.2. Fromwhat sourcesare designinputs sought?
2.10.3. Do design input procedures cover the relevant aspects, suchas: (Markall that applyand
list additional aspects.)
2.10.3.1. intendeduse
2.10.3.2. user/patient/clinical
2.10.3.3. performance characteristics
2.10.3.4. safety
2.10.3.5. limits andtolerances
2.10.3.6. riskanalysis
2.10.3.7. toxicityandbiocompatibility
2.10.3.8. electromagnetic compatibility(EMC)
2.10.3.9. compatibility withaccessories/auxiliary devices
2.10.3.10. compatibility withthe environment of intendeduse
2.10.3.11. humanfactors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
2.10.3.14. reliability
2.10.3.15. statutoryandregulatory requirements
2.10.3.16. voluntarystandards
2.10.3.17. manufacturingprocesses
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific designcovered, how were the designinput requirementsidentified?
2.10.5. For the specific designcovered, how were the designinput requirementsreviewedfor
adequacy?
ComplywithFDADesignControl Guidance GMP Regulation
1. Capture design and relatedinformation
1.1. Input electronically formatteddata
1.2. Reference external informationsources
1.3. Reference external documentation
2. Store designandrelatedinformation
2.1. Identify and tagdesign informationasunique “designelements”
2.2. Organize designelements
2.2.1. Organize by Design Control Guidance Element
2.2.2. Organize by inter-relationships
2.3. Ensure all designelements are available
2.3.1. Store designelements by Design Control Guidance Element
2.3.2. Store designelements andtheir historical values
3. Manage all user needs
3.1. Identify the sourceof theuser need
3.2. Identify all user types (groups)
3.3. Identify the customer (s)
3.4. Profile the expected patients
3.5. State the intended use of the product (family)
3.6. Capture the acceptance criteria for eachuser need
4. Manage designinput requirements
4.1. Identify the sourceof therequirement
4.2. Identify the associated user need
4.3. Capture requirement descriptionandattributes
4.4. Capture acceptance criteria
4.5. Assignresponsibility for each requirement
4.6. Manage incomplete requirements
4.7. Manage ambiguous requirements
4.8. Manage conflicting requirements
4.9. Approve all requirements
5. Manage acceptance
5.1. Ensure the acceptance of everyuser need
5.2. Ensure the acceptance of everydesign input requirement
5.3. Document theresultsof every user needacceptance test
5.4. Document theresultsof every design input requirements test
5.5. Make acceptance results available
6. Manage change
6.1. Maintain history of design element changes
6.1.1. Make complete change historyavailable
6.1.2. Maintainhistory withinand acrossany organizational procedure
6.1.3. Maintainhistory withinand acrossany project milestone
6.1.4. Maintainhistory withinand acrossany Design Control Guidance Elements
6.2. Capture frequency andnature of element changes
6.2.1. Provide rationale for change
6.2.2. Describe decisions made
6.2.3. Identifyapproval authorityfor the change
6.2.4. Capture date, time, andsignatureof approving authority
6.3. Identify impacted elements due to a change inanother element
6.3.1. Create backwardtraces todesignelements within and across anyorganizational procedure
6.3.2. Create backwardtraces todesignelements within and across anyproject milestone
1.1. Identifyimpacted elements due toa change inanother element
• Traceability Reports: consistency with drivingdesign elements
• Impact Reports: other design elements affected
• Links toimpacted design elements
1.1.1.Create backward tracesto design elements within and across any organizational
procedure
• TraceabilityReports: Procedure Attribute
1.1.2.Create backward tracesto design elements within and across any project milestone
• TraceabilityReports: Milestone Attribute
1.1.3.Create backward tracesto design elements within and across Design Control
Guidance Elements
• TraceabilityReports: Linkeddesignelements
1.1.4.Create forward impacts todesignelements withinand across anyorganizational
procedure
• Impact Reports: Procedure Attribute
1.1.5.Create forward impacts todesignelements withinand across anyproject milestone
• Impact Reports: Milestone Attribute
1.1.6.Create forward impacts todesignelements withinand across Design Control
Guidance Elements
• Impact Reports: Linkeddesign elements
1.2. Associate changeddesign elements withrelated elements
• LinkChange Design Object with affected design element(s)
• Traceability Links and Reportsfromaffecteddesign element(s)
• Impact Links and Reports fromaffected design element(s)
1.2.1.Associate design element changes with decisions, rationale, andapproval authority
information
• Change DecisionObjects with followingAttributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2.Provide associations within and acrossany organizational procedure
• Change DesignObject Traceability Link onProcedure Attribute
• Change DesignObject Impacts Link onProcedure Attribute
1.2.3.Provide associations within and acrossany project milestone
• Change DesignObject Traceability Link onMilestone Attribute
• Change DesignObject Impacts Link onMilestone Attribute
1.2.4.Provide associations within and acrossDesign Control Guidance Elements
• Change DesignObject Traceability Link totraced design elements
• Change DesignObject Impacts Link to linked designelements
1.3. Mange the change process
• Design Change Module
• Design Change Reports
• Object History
• Object History Reports
• Versions
• Baselines
1. 820.30(b) Design and Development Planning
Eachmanufacturer shall establishandmaintainplans that describe or reference the designanddevelopment
activities anddefine responsibility for implementation.
The plansshall identifyanddescribe the interfaceswithdifferent groups or activitiesthat provide, or result
in, input tothe designanddevelopment process.
The plansshall be reviewedas designanddevelopment evolves.
The plansshall be updated as designanddevelopment evolves.
The plansshall be approved asdesignanddevelopment evolves.
2. 820.30(c) DesignInput
2.1. Eachmanufacturer shall establishprocedures to ensure that the designrequirements relatingto a
andpatient.
2.2. Eachmanufacturer shall maintainprocedures to ensure that the designrequirements relatingto a
andpatient.
2.3. The procedures shall include a mechanismfor addressingincomplete requirements.
2.4. The procedures shall include a mechanismfor addressingambiguous requirements.
2.5. The procedures shall include a mechanismfor addressingconflicting requirements.
2.6. The designinput requirements shall be documentedbya designatedindividual(s).
2.7. The designinput requirements shall be reviewedby a designatedindividual(s).
2.8. The designinput requirements shall be approvedbya designatedindividual(s).
2.9. The approval, including the date andsignature of the individual(s) approving the requirements,
shall be documented.
2.10.Questions.
2.10.1. Summarize the manufacturer'swrittenprocedure(s) for identification and control of
designinput.
2.10.2. Fromwhat sourcesare designinputs sought?
2.10.3. Do design input procedures cover the relevant aspects, suchas: (Markall that applyand
list additional aspects.)
2.10.3.1. intendeduse
2.10.3.2. user/patient/clinical
2.10.3.3. performance characteristics
2.10.3.4. safety
2.10.3.5. limits andtolerances
2.10.3.6. riskanalysis
2.10.3.7. toxicityandbiocompatibility
2.10.3.8. electromagnetic compatibility(EMC)
2.10.3.9. compatibility withaccessories/auxiliary devices
2.10.3.10. compatibility withthe environment of intendeduse
2.10.3.11. humanfactors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
2.10.3.14. reliability
2.10.3.15. statutoryandregulatory requirements
2.10.3.16. voluntarystandards
2.10.3.17. manufacturingprocesses
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific designcovered, how were the designinput requirementsidentified?
2.10.5. For the specific designcovered, how were the designinput requirementsreviewedfor
adequacy?
ComplywithFDADesignControl Guidance GMP Regulation
1. Capture design and relatedinformation
1.1. Input electronically formatteddata
1.2. Reference external informationsources
1.3. Reference external documentation
2. Store designandrelatedinformation
2.1. Identify and tagdesign informationasunique “designelements”
2.2. Organize designelements
2.2.1. Organize by Design Control Guidance Element
2.2.2. Organize by inter-relationships
2.3. Ensure all designelements are available
2.3.1. Store designelements by Design Control Guidance Element
2.3.2. Store designelements andtheir historical values
3. Manage all user needs
3.1. Identify the sourceof theuser need
3.2. Identify all user types (groups)
3.3. Identify the customer (s)
3.4. Profile the expected patients
3.5. State the intended use of the product (family)
3.6. Capture the acceptance criteria for eachuser need
4. Manage designinput requirements
4.1. Identify the sourceof therequirement
4.2. Identify the associated user need
4.3. Capture requirement descriptionandattributes
4.4. Capture acceptance criteria
4.5. Assignresponsibility for each requirement
4.6. Manage incomplete requirements
4.7. Manage ambiguous requirements
4.8. Manage conflicting requirements
4.9. Approve all requirements
5. Manage acceptance
5.1. Ensure the acceptance of everyuser need
5.2. Ensure the acceptance of everydesign input requirement
5.3. Document theresultsof every user needacceptance test
5.4. Document theresultsof every design input requirements test
5.5. Make acceptance results available
6. Manage change
6.1. Maintain history of design element changes
6.1.1. Make complete change historyavailable
6.1.2. Maintainhistory withinand acrossany organizational procedure
6.1.3. Maintainhistory withinand acrossany project milestone
6.1.4. Maintainhistory withinand acrossany Design Control Guidance Elements
6.2. Capture frequency andnature of element changes
6.2.1. Provide rationale for change
6.2.2. Describe decisions made
6.2.3. Identifyapproval authorityfor the change
6.2.4. Capture date, time, andsignatureof approving authority
6.3. Identify impacted elements due to a change inanother element
6.3.1. Create backwardtraces todesignelements within and across anyorganizational procedure
6.3.2. Create backwardtraces todesignelements within and across anyproject milestone
1.1. Identifyimpacted elements due to a change in another element
• Traceability Reports: consistency with driving design elements
• Impact Reports: other designelementsaffected
• Links toimpacted design elements
1.1.1.Create backward traces todesignelements withinand across any organizational
procedure
• Traceability Reports: Procedure Attribute
1.1.2.Create backward traces todesignelements withinand across any project milestone
• Traceability Reports: Milestone Attribute
1.1.3.Create backward traces todesignelements withinand across DesignControl
Guidance Elements
• Traceability Reports: Linked design elements
1.1.4.Create forward impacts to design elementswithin and across any organizational
procedure
• Impact Reports: Procedure Attribute
1.1.5.Create forward impacts to design elements within and across any project milestone
• Impact Reports: Milestone Attribute
1.1.6.Create forward impacts to design elementswithin and across Design Control
Guidance Elements
• Impact Reports: Linked design elements
1.2. Associate changeddesign elements with related elements
• Link Change Design Object with affected design element(s)
• Traceability LinksandReportsfromaffected design element(s)
• Impact Links andReportsfromaffected design element(s)
1.2.1.Associate design element changes withdecisions, rationale, andapproval authority
information
• Change Decision Objectswithfollowing Attributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2.Provide associations within and across any organizational procedure
• Change Design Object Traceability Linkon Procedure Attribute
• Change Design Object Impacts Link on Procedure Attribute
1.2.3.Provide associations within and across any project milestone
• Change Design Object Traceability Linkon Milestone Attribute
• Change Design Object Impacts Link on Milestone Attribute
1.2.4.Provide associations within and across Design Control Guidance Elements
• Change Design Object Traceability Linktotraced design elements
• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process
• DesignChange Module
• DesignChange Reports
• Object History
• Object History Reports
• Versions
• Baselines
User
Requirements Test CasesDesign
Technical
Requirements
End-to-end visual
validation in one view
Traceability to/from
work items
Traceability to/from
tests
Requirements change
management

19
Capabilities
Specify, design and develop systems and
software for technical, embedded and real-
time solutions, including those based on
multi-core architectures
Validate and verify designs with model
based simulation and test throughout the
product lifecycle
Develop complete C, C++, Java and Ada
applications, working in either the code or
model while ensuring the two remain in
sync
Model-Based Systems Engineering and Model-Driven Development
for real-time, embedded systems using Rational Rhapsody
Benefits
Build the right product through optimized communication and collaboration
Eliminate defects early and increase quality by continually testing the design
Reduce development time by automatically generating applications and
documentation

20
Rational Publishing Engine
Automate the generation of documentation, from multiple sources

21

Demonstration overview
Model based functional analysis
– Using models to improve the quality of requirements
Requirements driven software development
– Using models to generate readable and certifiable code
22 22

23

24
Testing
24

Define test cases with sequence diagrams,
statecharts, flowcharts or even code
OMG UML Testing Profile
Automate testing tasks
Create Test Architecture
Execute and monitor tests
Host level and target based execution
White-Box, Black-Box for design validation
“Offline testing” mode - for testing on target
C++, C, Java, Ada Supported
Definition and management of regression tests
Reporting of results, coverage and traceability
Rhapsody TestConductor Add-on for Model-Based Testing
Traceability across lifecycle – from requirements to integration

DO-178 qualification of software development and verification tools

Rhapsody Kit for ISO 26262, IEC 61508, and DO-178B/C
Overview Document: describes the contents of
the Rhapsody kit
Rhapsody Reference workflow: provides an
exemplary workflow for modelling, code
generation and verification in safety critical
Rhapsody TestConductor Add On Workflow:
describes testing activities and objectives
Rhapsody TestConductor Safety Manual:
provides additional information for using
TestConductor in safety related applications
TÜV SÜD Certificate for Rhapsody
TestConductor Add On
TÜV SÜD Report on Certificate for ISO 26262
and IEC 61508
Rhapsody TestConductor Add On Validation
Suite: separately available test suite for
Rhapsody TestConductor to help in qualification
efforts
Certification kits for the SXF and SMXF
real-time execution frameworks

IBM Rational Rhapsody Reference workflow
Rhapsody Reference Workflow for the development of safety-related software
– provides guidance on how to fulfill functional safety requirements with model-based
development methods and tools
– is based on best practices for safety-related projects
– addresses various workflow activities relevant for the development of safety-related software
with a special focus on verification and validation to develop safe software28

IBM Software, Rational
29
www.ibm.com/software/rational
29

30
IBM Rational DOORS Next Generation
DOORS concepts improved and much more….
Definition
Rich-text documents
Diagrams: Process, Use Case
Storyboards, UI sketching & flow
Project glossaries
Templates
Collaboration
Review & Approval
Discussions
Email Notification
Visibility
Customizable dashboards
Analysis views
Collections
Milestone tracking & status
Management
Structure, Attributes/Types
Traceability, Filtering, Tags
Baselines, Change History
Reuse (reqs & types)
Reporting Metrics & Doc.
Planning
Integrated planning
Effort estimation
Task Management
Lifecycle
Central requirements, test,
& development repository
Common administration
and role-based user
licensing
Warehouse reporting

Where does Rhapsody ATG fit with DO-178C testing?
DO-178C and DO-331 address software design, code, and verification
Verification involves:
– review (test requirement, coverage review, …)
– analysis (automated MISRA C++ compliance, code coverage analysis, …)
– testing activities (mainly requirements based testing)
TestConductor directly supports many of the required testing activities and
analysis activities (requirements based testing, code coverage, model
coverage)
ATG provides more automation, but does not address additional
verification methods beyond TestConductor
Step 1 – define and implement a DO-178C/DO-311 compliant process
using Rhapsody, TestConductor, Team Concert
Step 2 – if step 1 is working, consider using ATG for more automation

RTCA DO-178B is an objective-based standard applied by FAA (Federal Aviation
Administration) for the certification of software in avionics systems.
Published in 1992, it covers the 5 main processes concerning Planning, Development,
Verification, Configuration Management and Quality Assurance.
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)
Example: RTCA DO-178B
Software Criticality
Level
Failure Condition
Category
Failure Condition Description Objectives
Level A Catastrophic Conditions which would prevent continued safe flight and landing. 66
Level B Haazardous/ Sever-Major Conditions which would reduce aircraft safety margin/functional
capabilities, produce a higher workload to the flight crew or have
serious adverse effencts on occupants
65
Level C Major Conditions which would not significantly reduce aircraft safety, crew
ability to work under adveser operation or produce discomfort to
occupants.
57
Level D Minor Conditions which would not significantly reduce aircraft safety, slight
increas in crew workload or produce some inconvenience to
occupants
28
Level E No Effect Conditions which do not affect the aircraft operations or crew
workload.
0

Model Based Systems and Software Engineering an overview of the IBM Rational solution

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Model Based Systems and Software Engineering an overview of the IBM Rational solution

Similaire à Model Based Systems and Software Engineering an overview of the IBM Rational solution (20)

Plus de Real-Time Innovations (RTI)

Plus de Real-Time Innovations (RTI) (20)

Dernier

Dernier (20)

Model Based Systems and Software Engineering an overview of the IBM Rational solution