製品紹介 IBM Rational DOORS 日本アイ・ビー・エム株式会社

®
IBM Software Group
IBM Rational® DOORS® 製品紹介
日本アイ・ビー・エム株式会社
ラショナル・テレロジック・
テクニカル・セールス＆サービス
© 2008 IBM Corporation
IBM Software Group | Rational software
はじめに
2
IBM Software Group | Rational software
要件管理を取り巻く様々な問題点
【開発プロセスと要件管理の問題点】
追加・変更要求
顧客要求
ビジネス要求
産業要求
要求仕様書
¾顧客要求が不明瞭
¾顧客との合意ができていない
¾要求がドキュメント化されない
¾要件定義過程での
変更履歴が不明
システム要求
設計仕様
テスト仕様
¾ドキュメントが一元管理されていない
¾追加・変更の影響範囲が分らない
¾修正・変更履歴がなく最新版がわからない
¾関連するメンバーで情報が共有されない
¾上流の要求を漏れなく
カバーしているかが不明瞭
開発/テスト
リリース
¾ テスト内容が開発内容を
カバーしているかが不明瞭
¾ 納品仕様書のバージョン管理
ができていない
3
IBM Software Group | Rational software
要件管理の目的
ƒ 様々なステークホルダの要求を整理・共有
ƒ 開発拠点・部署間での協調作業の促進と重複作業の排除
ƒ 影響分析の効率化
ƒ 要求を満たしていることの確認・証明
ƒ コンプライアンスの証明
4
IBM Software Group | Rational software
要件管理ツール Rational® DOORS® の特徴
要件毎の履歴管理
データベースにて要件の一元化
変更通知
システム設計仕様書
変更履歴
DOORSクライアント
ユーザ要求仕様書
変更前
変更後
！
変更
DOORS
B
データベース
A
トレーサビリティと影響分析
ユーザー
要求仕様書
設計仕様書
レポート化
標準規格
Printer
Word
Export
Excel
PowerPoint
HTML
システム
テスト仕様書
受け入れ
テスト仕様書
ASCII
5
IBM Software Group | Rational software
Rational® DOORS® の機能
6
IBM Software Group | Rational software
要件の一元管理
• 文書をサーバで一元管理
• 常に最新の情報を閲覧できることを保証
• コミュニケーションを促進
The Single Source of Truth
7
IBM Software Group | Rational software
DOORSで文書作成・編集
8
IBM Software Group | Rational software
ドラッグアンドドロップでのリンク作成
9
IBM Software Group | Rational software
情報トレース
ユーザー要求
1.
820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and development
activities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or result
in, input to the design and development process.
システム要求
システム設計
1. 820.30(b) Design and Development Planning
Comply with FDA Design Control Guidance GMP Regulation
Comply with FDA Design Control Guidance GMP Regulation
Each manufacturer shall establish and maintain plans that describe or reference the design
and development
1.1. Identify
impacted elements due to a change in another element
activities and define responsibility for implementation.
1. Capture design and related information
1. Capturewith
design
and related
information
driving
design
elements
• Traceability Reports: consistency
1.1. Input electronically formatted data
Input electronically
Impact Reports: other design1.1.
elements
affected formatted data
The plans
shall identify and describe the interfaces with different groups or activities that•provide, or result
1.2. Reference external information
sources
1.2. Reference external information sources
• Links to impacted design elements
in, input to the design and development process.
1.3. Reference external documentation
1.3. Reference external documentation
1.1.1. Create backward traces to design elements within and across any organizational
The plans shall be reviewed as design and development evolves.
The plans shall be updated as design and development evolves.
The plans shall be approved as design and development evolves.
2.
820.30(c) Design Input
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
2.5. The procedures shall include a mechanism for addressing conflicting requirements.
2.6. The design input requirements shall be documented by a designated individual(s).
2.7. The design input requirements shall be reviewed by a designated individual(s).
2.8. The design input requirements shall be approved by a designated individual(s).
2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of
design input.
2.10.2. From what sources are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)
2.10.3.1.
intended use
2.10.3.2.
user/patient/clinical
2.10.3.3.
performance characteristics
2.10.3.4.
safety
2.10.3.5.
limits and tolerances
2.10.3.6.
risk analysis
2.10.3.7.
toxicity and biocompatibility
2.10.3.8.
electromagnetic compatibility (EMC)
2.10.3.9.
compatibility with accessories/auxiliary devices
2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging
2.10.3.14. reliability
2.10.3.15. statutory and regulatory requirements
2.10.3.16. voluntary standards
2.10.3.17. manufacturing processes
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?
2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
2.
3.
4.
5.
6.
The plans shall be reviewed as design and development evolves.
Store design and related information
2. Store design and related information
procedure
The plans shall
be updated
as design
and development evolves.
2.1. Identify and tag design information
as unique
“design
elements”
2.1. Identify
and tag design information as unique “design elements”
Attribute
• Traceability Reports: Procedure
The plans shall be approved as design and development evolves.
2.2. Organize design elements
2.2. Organize design elements
1.1.2. Create backward traces to design
elements within and across any project milestone
2.2.1. Organize by Design Control Guidance Element
2.2.1. Organize by Design Control Guidance Element
Traceability
Reports:
Milestone
Attribute
2.
820.30(c)
Design
Input
•
2.2.2. Organize by inter-relationships
2.2.2. Organize
by inter-relationships
2.1.
Each
manufacturer
shall
establish
procedures
to
ensure
that
the
design
requirements
relating
to
a
1.1.3.
Create
backward
traces
to
design
elements
within
and are
across
Design Control
2.3. Ensure all design elements are available
2.3. Ensure all design
elements
available
device
are appropriate
address the intended use of the device, including the needs Guidance
of the user Elements
2.3.1. Store design elements by Design
Control
Guidance and
Element
2.3.1. Store design elements by Design Control Guidance Element
andhistorical
patient. values
2.3.2. Store design elements and their
2.3.2.
Store design
elements and their historical values
Reports: Linked
design
elements
• Traceability
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating
to a
forward impacts3.to design
within and across any organizational
device are appropriate and address the intended use of the device, including the1.1.4.
needs Create
of the user
Manage all user needs
Manage elements
all user needs
and patient.
procedure
3.1. Identify the source of the user need
3.1. Identify the source of the user need
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
3.2. Identify all user types (groups)
3.2. Identify
all user types (groups)
Attribute
• Impact Reports: Procedure
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.
3.3. Identify the customer (s)
3.3. Identify
the customer
1.1.5. Create forward impacts to design
elements
within(s)
and across any project milestone
2.5.
The
procedures
shall
include
a
mechanism
for
addressing
conflicting
requirements.
3.4. Profile the expected patients
3.4. Profile the expected patients
Attribute
• Impact Reports: Milestone
The(family)
design input requirements shall be documented by a designated individual(s).
3.5. State the intended use of the 2.6.
product
3.5. State
the intended use of the product (family)
2.7.forThe
input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design
elements
within and
across
Design
Control
3.6. Capture the acceptance criteria
eachdesign
user need
3.6. Capture
the acceptance
criteria
for each
user need
2.8. The design input requirements shall be approved by a designated individual(s).
Guidance Elements
Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements,
4. Manage
input requirements
designdesign
elements
• Impact Reports: Linked
shall be documented.
4.1. Identify the source of the requirement
4.1. Identify the source of the requirement
1.2. Associate changed design elements with related elements
2.10. Questions.
4.2. Identify the associated user need
4.2. Identify the associated user need
LinkofChange Design Object 4.3.
withCapture
affected
design element(s)
2.10.1.
Summarize the manufacturer's written procedure(s) for identification and
• control
4.3. Capture requirement description and
attributes
requirement
description and attributes
design input.
4.4. Capture acceptance criteria
4.4. from
Capture
acceptance
criteria
affected
design
element(s)
• Traceability Links and Reports
2.10.2. From what sources are design inputs sought?
4.5. Assign responsibility for each requirement
4.5. affected
Assign responsibility
for each requirement
Links and Reports from
design element(s)
• thatImpact
2.10.3.
Do
design
input
procedures
cover
the
relevant
aspects,
such
as:
(Mark
all
apply
and
4.6. Manage incomplete requirements
4.6. Manage incomplete requirements
1.2.1. Associate design element changes
with decisions, rationale, and approval authority
list additional aspects.)
4.7. Manage ambiguous requirements
4.7. Manage ambiguous requirements
information
2.10.3.1.
intended use
4.8. Manage conflicting requirements
4.8. Manage conflicting requirements
2.10.3.2.
user/patient/clinical
with
following
Attributes:
4.9. Approve all requirements
Approve
all requirements
• Change Decision Objects4.9.
2.10.3.3.
performance characteristics
• Disposition Attribute
2.10.3.4.
safety
Manage acceptance
5. Manage acceptance
• Decision Attribute
2.10.3.5.
limits and tolerances
5.1. Ensure the acceptance of every user need
5.1. Ensure the acceptance of every user need
risk analysis
• Rationale Attribute
5.2. Ensure the acceptance of every design2.10.3.6.
input requirement
5.2. Ensure the acceptance of every design input requirement
2.10.3.7.
5.3. Document the results of every user need
acceptancetoxicity
test and biocompatibility
5.3. Document the results of every user need acceptance test
• Owner Attribute
electromagnetic
compatibility (EMC)
5.4. Document the results of every design 2.10.3.8.
5.4. Document the results of every design input requirements test
input requirements
test
• Management Approval Attribute
compatibility with accessories/auxiliary devices
5.5. Make acceptance results available 2.10.3.9.
acceptance results available
1.2.2. Provide associations within5.5.
andMake
across
any organizational procedure
2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
Link on Procedure Attribute
• Change Design Object
Manage change
6. Traceability
Manage change
2.10.3.12. physical/chemical characteristics
6.1. Maintain history of design element changes
6.1. Maintain
of design Attribute
element changes
Change Design Object Impacts
Link history
on Procedure
•
2.10.3.13. labeling/packaging
6.1.1. Make complete change history available
6.1.1.
Makeany
complete
change
history available
1.2.3.
Provide
associations
within
and
across
project
milestone
2.10.3.14.
reliabilityprocedure
6.1.2. Maintain history within and across
any organizational
6.1.2. Maintain history within and across any organizational procedure
Link on Milestone Attribute
• Change Design Object Traceability
2.10.3.15.
statutory
and regulatory requirements
6.1.3. Maintain history within and across
any project
milestone
6.1.3. Maintain history within and across any project milestone
2.10.3.16.
voluntary
on Milestone
Attribute
• Change Design Object Impacts
6.1.4. Maintain history within and across
any Design
Control standards
Guidance Elements
6.1.4.Link
Maintain
history within
and across any Design Control Guidance Elements
2.10.3.17.
manufacturing
processes
6.2. Capture frequency and nature of element changes
natureGuidance
of element changes
1.2.4. Provide associations within6.2.
andCapture
acrossfrequency
Design and
Control
Elements
2.10.3.18. sterility
6.2.1. Provide rationale for change
6.2.1. Provide
fordesign
change elements
Linkrationale
to traced
• Change Design Object Traceability
2.10.3.19. MDRs/complaints/failures and other historical data
6.2.2. Describe decisions made
6.2.2. Describe decisions made
Link to linked design elements
• Change Design Object Impacts
2.10.3.20.
6.2.3. Identify approval authority for the
change design history files (DHFs)
6.2.3. Identify approval authority for the change
2.10.4.of approving
For the specific
design covered, how were the design input requirements
identified?
1.3. Mange
the change process
6.2.4. Capture date, time, and signature
authority
6.2.4. Capture date, time, and signature of approving authority
For
specific
design covered, how were the design input requirements reviewed
forChange Module
6.3. Identify impacted elements due to2.10.5.
a change
in the
another
element
6.3. Identify impacted elements due to a change in another element
• Design
adequacy?
6.3.1. Create backward traces to design elements
within and across any organizational procedure
6.3.1. Create backward traces to design elements within and across any organizational procedure
• Design Change Reports
6.3.2. Create backward traces to design elements within and across any project milestone
6.3.2. Create backward traces to design elements within and across any project milestone
•
•
•
•
Object History
Object History Reports
Versions
Baselines
テスト仕様
1.1. Identify impacted elements due to a change in another element
• Traceability Reports: consistency with driving design elements
• Impact Reports: other design elements affected
• Links to impacted design elements
1.1.1. Create backward traces to design elements within and across any organizational
procedure
• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone
• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design Control
Guidance Elements
• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizational
procedure
• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone
• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design Control
Guidance Elements
• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements
• Link Change Design Object with affected design element(s)
• Traceability Links and Reports from affected design element(s)
• Impact Links and Reports from affected design element(s)
1.2.1. Associate design element changes with decisions, rationale, and approval authority
information
• Change Decision Objects with following Attributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure
• Change Design Object Traceability Link on Procedure Attribute
• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone
• Change Design Object Traceability Link on Milestone Attribute
• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements
• Change Design Object Traceability Link to traced design elements
• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process
• Design Change Module
• Design Change Reports
• Object History
• Object History Reports
• Versions
• Baselines
10
IBM Software Group | Rational software
情報トレースの結果
ƒ 開発の理由（なぜこれを作成しているか）が明確化
ƒ いかにこの要求が実装されているか判断可能
ƒ 要求が変更された場合、システムの変更にどれだけのコストがかかるか
見積もりを簡単にする
ƒ すべての要件が満たされていることを証明が可能
ƒ すべてはユーザ要求に基づいているか（不要な作り込みはないか）の確
認が容易
11
IBM Software Group | Rational software
影響分析
• 要件が変更された場合の影響範囲は？
ユーザー
要求仕様書
システム
要求仕様書
受け入れ
テスト仕様書
システム
テスト仕様書
設計仕様書
標準規格
インテグレーション/ユニット
テスト仕様書
12
IBM Software Group | Rational software
影響分析（追跡可能性）
要求仕様
各ドキュメントの項目毎の
つながりを明確にする
受け入れ
テスト
システム
設計書
システムテスト
基本設計書
統合テスト
詳細設計書
単体テスト
13
IBM Software Group | Rational software
影響分析
ユーザ要求
機能要求
テスト仕様
14
IBM Software Group | Rational software
• 設計に抜け・漏れがないか？
• テストに抜け・漏れがないか？
カバレッジ分析
ユーザー
要求仕様書
システム
要求仕様書
受け入れ
テスト仕様書
システム
テスト仕様書
設計仕様書
標準規格
インテグレーション/ユニット
テスト仕様書
15
IBM Software Group | Rational software
カバレッジ分析
カバレッジの確認
更にフィルターにより反映
されていない要求事項の
みを表示
16
IBM Software Group | Rational software
サスペクトリンク
このユーザが
ここを変更すると…
… 警告情報がこち
らの仕様に示される
要件に変更があった際、リンク先に警告を表示
影響を受ける可能性を予告表示することで、
後戻りを防止し、作業をスピードアップをする
17
IBM Software Group | Rational software
履歴管理
18
IBM Software Group | Rational software
属性の管理
要件に関連する各種情報の管理と、それらを用いた分析が可能
属性の例：
• 優先度
• 承認ステータス
• 担当者
• リリース時期
• 試験結果
• 試験実施日
• コメント
• etc.
19
IBM Software Group | Rational software
文書とトレーサビリティの版管理
• レビュー、承認された文書を版管理
• ベースラインに対する電子署名が可能
（FDA 21 CFR Part 11に対応）
• 文書のセットに対するベースライン設定
が可能
• バージョン間の比較が可能
20
IBM Software Group | Rational software
バージョン間の比較
変更点を一覧表示
21
IBM Software Group | Rational software
モジュールコンペア機能
z
モジュール間またはベースラ
イン間の比較が可能
z
変更箇所はマークアップされ、
表示される
z
変更箇所だけフィルタリング
して表示することも可能
22
IBM Software Group | Rational software
DOORS外部とのトレーサビリティ
ƒ DOORSからDOORS外部の情報へリンク可能
ƒ リンクには対象データのURL／パスを指定
23
IBM Software Group | Rational software
外部からDOORSを呼び出す
ƒ
DOORSデータは、データベース、プロジェクト、フォルダ、モジュール、オブジェクトの単位で
URLを持っている
ƒ
このURLを用いて、他のアプリケーションからDOORSデータベース内の特定データを開くこ
とができる
ƒ
ユーザ認証、セキュリティの制御も適用される
24
IBM Software Group | Rational software
Rational® DOORS® Web Access
25
IBM Software Group | Rational software
DOORS Web Accessが開発チームにもたらす機能
ƒDWA 1.2の主な機能
DOORS データベースの要求に対し読取りのみもしくは
編集権限にてアクセス
ƒ すべてのアトリビュートを編集可能（正しくアクセス権
が設定されていれば）
要求、画像、OLEオブジェクト、テーブルの表示
ベースラインの表示
グローバルチームでの簡易な利用
DOORS ディスカッションを利用したレビューへの参加
ƒ 新しいディスカッションの作成
ƒ 既存のディスカッションに対しコメントの提供
DOORSユーザーは簡単に
DOORSデータにアクセスできる方
法を待っていました。そこでDOORS
Web Accessがついにリリース
Rational DOORS ファミリー
既存のDOORS ビューの閲覧
モジュール内検索
要求の印刷
モジュール間のリンクトレース
26
IBM Software Group | Rational software
DOORS Web Accessから編集
プロジェクトメンバーができる操作:
ƒ編集プロファイルを用
いた作業
ƒアクセス可能オブジェク
トに対し編集コントロー
ルを使う
モジュール
ビュー
ƒアクセス方法の切換え
ƒHTTP URLを利用した
アクセスの提供
ƒモジュールビューの印
刷
編集
コントロール
ƒモジュールデータに簡
単アクセス
編集
インジケーター
27
IBM Software Group | Rational software
DOORS Web Access 日本語インターフェイス
日本語
ベースライン
28
IBM Software Group | Rational software
Rational® DOORS Analyst TM
29
IBM Software Group | Rational software
DOORS Analyst のご紹介
ƒ 要件仕様を作成する際、システムのモデルを図にしていますか？
ƒ 要件収集の際、絵コンテ、 PowerPoint ®のイラスト等で図を作成していますか？
ƒ 要件がどのように理解されるべきか、図を描いて説明していますか？
30
IBM Software Group | Rational software
DOORS Analyst の特徴
ƒ DOORS内でダイアグラムを記述可能
ƒ テキストの要求から自動的にモデル
のエレメントが作成される
ƒ DOORSの要求とモデルのエレメント
間にリンクを作成することができ、相
互にたどることが可能
作成!
ƒ ダイアグラムの履歴の追跡、バージョ
ンの管理が可能
ƒ ユーザが定義したアイコンをシンボル
として使用することが可能
保存!
31
IBM Software Group | Rational software
Rational® Change との連携機能
32
IBM Software Group | Rational software
変更管理ツール Rational® Change との連携
要件と、その追加／変更にともない発生した変更要求とのトレーサビリティを確保
DOORS画面にて変更要求の番号と処理状況を把握可能
要件
変更要求の番号
変更要求の処理状況
ここでいう変更要求とは、
ソフトウェアの実装要求その他の
作業要求などを指す
33
IBM Software Group | Rational software
アクティビティレポートの作成
さらに、構成管理ツール Rational
Synergyとの連携により
ƒ 要件－実装要求－ソースのトレ
ーサビリティを管理・可視化
ƒ 担当者や作業ステータス、ファイ
ルバージョン、盛り込まれたリリ
ースを可視化
ƒ FDA、FAA (DO-178B)等のコンプ
ライアンス証明に有効
要件項目
実装要求
変更タスクと
ソースリスト
の情報
34
IBM Software Group | Rational software
Rational® Publishing Engine
35
IBM Software Group | Rational software
Rational Publishing Engine
シンプルな文書作成
ƒ Rational DOORSから文書作成
ƒ テンプレートの再利用と共有
ƒ 付属のテンプレートを用いてROI
の即時向上
ƒ 業界標準テンプレートの利用
ƒ 直感的な編集環境を用いてのテ
ンプレートの作成と編集
ドラッグ＆ドロップ操作
強力なスクリプト言語のサポ
ート
(Javascript)
36
IBM Software Group | Rational software
Rational Publishing Engine
わかりやすく洗練された文書
ƒ さまざまなフォーマットでの文書作成 (MS Word, HTML, PDF)
ƒ ひとつもしくは複数の情報源からのデータ取得
37
IBM Software Group | Rational software
Rational Publishing Engine
わかりやすく洗練された文書
ƒ 独自の文書形式を定義し、ユーザが出力したいフォーマットで出力可能
リッチフォーマットテキスト
目次
ハイパーリンク – 内部へもしくは外部へ
OLE
図
ユーザ定義のスタイル
条件式によるフォーマット
…
38
IBM Software Group | Rational software
まとめ：DOORSの効果
ƒ ドキュメント一元管理による、重複作業、後戻り作業の低減
ƒ 影響分析の効率化と精度の向上
ƒ 見積りの正確化
ƒ 影響分析を行うことによる、不用意な要件変更の排除
ƒ 要件と要件のリンクセットをそのまま再利用
ƒ 情報の可視化と管理の効率化
ƒ 規格・規制への効率的な準拠とコンプライアンスの証明
ƒ コミュニケーションの促進と効率化
ƒ 要求分析・レビュー・管理に対する意識の高まり
ƒ 工数・コスト削減
ƒ 品質向上と顧客満足度の向上
39
IBM Software Group | Rational software
IBM Rational® DOORS®
40
IBM Software Group | Rational software
Learn more at:
ƒ IBM Rational software
ƒ IBM Rational Software Delivery Platform
ƒ Process and portfolio management
ƒ Change and release management
ƒ Quality management
ƒ Architecture management
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Rational trial downloads
Leading Innovation Web site
developerWorks Rational
IBM Rational TV
IBM Business Partners
IBM Rational Case Studies
© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any
kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor
shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use
of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or
capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product
or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, , the logo, and other IBM products and services are trademarks of the International Business Machines Corporation,
in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
41