セーフティクリティカル・ソフトウェア開発のためのアジャイル分析プラクティス

その規律と効率ゆえ、アジャイル開発プラクティス(実践法)はセーフティクリティカルなソフトウェアの開発に適用されるべきであると考えます。組込みリアルタイム開発プロセスのためのIBM Rational Harmony方法論の著者であるBruce Douglassが、セーフティクリティカル・システムのための重要な分析プラクティスと、それが如何にアジャイルなやり方で実現できるかについて解説します。

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rationalチーフ・エバンジェリスト, システムズ・エンジニアリング, IBM

author photoBruce Douglassは、30年以上にわたり、特に、リアルタイム組込みシステムとソフトウェアの開発に関係したソフトウェア分野に携わっています。彼は、IBM Rational Harmony for Embedded RealTime Development (Harmony/ERT)プロセスの著者です。彼は、Peter Hoffmannと共に、システムズ・エンジニアリングとソフトウェア・エンジニアリングを組合せ、その間をスムーズに統合された形で連携すべく規定された受け渡し方法を含んだオリジナルのHarmonyプロセスを開発しました。彼のIBMにおける役割としては、コンサルティングの担当者であると同時に、Rationalソフトウェアの顧客のみならず、IBM自身のサービス専門エンジニア、アプリケーション・エンジニア、研究・開発・マーケティングのそれぞれの部門に対する、UML, SysML, DoDAFを応用するための先進トレーニングを提供しています。Bruceは、100以上におよぶ雑誌の記事と15冊の技術書籍を執筆しています。また、Embedded Systems ConferenceとUML World Conferenceの講演者であり、諮問委員会のメンバーでもあります。彼の専門領域は、アジャイル開発、システムズ・エンジニアリングにおけるアジャイル方法、モデルベース開発、そしてセーフティクリティカル・システムにわたります。



2013年 9月 20日

アジャイル方法論は、迅速さや適応性で定評がありますが、規律が弱く頑強でないとも言われます。しかし、アジャイル方法論は、実際かなりの規律を求めますし、これらのプラクティス(実践法)は、品質とチームの生産性を強化するのです。それゆえ、アジャイル開発プラクティスは、セーフティクリティカル・システムの開発に適用されるべきであると考えます。この記事では、アジャイル分析手法が如何にセーフティクリティカル・システムの開発に利用できるかを説明します。

セーフティクリティカル・システムの性質

セーフティクリティカルという言葉は、危害の原因となる、もしくは、危害を防止する責務を持つシステムを指します。このようなシステムは、医療機器から、自動車のブレーキ・システム、原子力発電所制御、航空管制システムといったものを含みます。ほとんどのセーフティクリティカル・システムは、その目的への合致を保証するために、監督機関による認証を受けなければなりません。これは、「システムの正しさ」が導かれるように意図された、適切な開発プラクティスが適用されていること、そして、関連する標準により要請される目的が忠実に守られていることを示せることを意味します。

実際上意味がある形で、ソフトウェアの正しさを決定論的に示すことは不可能であるので、こういった標準のほとんどは、そのプロセス標準に従っていることの証拠提出のための、プロセス目標や要求事項を規定することに、重きを置いています。例えば、最近リリースされた航空電子工学での標準、「DO-178C, 航空機システムおよび機器認証におけるソフトウェアの考慮点」は、個々のシステム・プロジェクトが、セーフティクリティカル・レベルによっては71項目にもなる目標に対しての、幾つかのカテゴリーの証拠を準備することを要請しています。その補助標準である「DO-331, モデルベース開発と検証」や「DO-332, オブジェクト指向技術と関連技法」などは、それらの技術が使われている場合に対応して、幾つかの目標を追加しています。それらのほとんどの目標は、次のようなフェーズに関連付けられます。

  • 計画策定 (これは機器のセーフティ・レベル仕様の記述作業を含む)
  • ソフトウェア開発プロセス定義
  • 要求管理
  • ソフトウェア設計とコード作成
  • 構成管理
  • 品質保証
  • 統合
  • 検証
  • ツールの能力検定
  • システム認証

ここで気に留めておく必要があるのは、これらの標準は、セーフティクリティカル・システムの開発に使われる、いかなるプロセスもが満たすべき目標を規定してはいるものの、プロセス自体は規定していない、ということです。そのプロセスが、その関連する標準が要請していることを満たしていることが示せれば、開発チームがどのようなプロセスを使うかは自由です。ということは、最先端のアジャイル方法論を、それがもつ様々な利点を生かし、安全性の目標を達成するような形にした上で使うことも可能になります。


Harmonyプロセスの概要

Harmonyプロセスは、リアルタイム組込みシステム開発のためのモデル駆動型アジャイルプロセスです。(詳細については参考文献のReal-Time Agilityを参照。)これは、強力なアーキテクチャに関するコンセプトを持っており、セーフティクリティカル・システムのような、故障が甚大な損害をもたらすようなシステムの開発に使われる上で必要となる厳格さを提供できるものです。

Harmonyプロセスは、ソフトウェア開発のための、あるまとまった方法に組み込んで使うたくさんのプラクティスから成っています。それは以下のような重要なプラクティスを含んでいます。

  • 分析指向プラクティス
    • 初期安全性分析
    • 継続的安全性アセスメント
    • 実行可能要求モデル
    • トレーサビリティ分析
  • 設計指向プラクティス
    • モデルベース・エンジニアリング
    • アーキテクチャの5つのビュー
    • 防衛的設計
  • 品質指向プラクティス
    • 継続的実行
    • テスト駆動開発
    • 継続的統合
    • Harmonyマイクロサイクルによるインクリメンタルな開発
    • 作業成果物レビュー
    • 作業者タスク監査
  • 証拠指向プラクティス
    • トレーサビリティ記録の管理
    • テスト・カバレッジ分析

この記事では、最初の分析指向プラクティスのみを取り上げます。

注:
Harmonyはアジャイル・システムズ・エンジニアリングにも対応していますが、この記事ではソフトウェア開発にのみ焦点を当てます。

図1は、Harmonyソフトウェア・プロセスの概要を示しています。図中のアクティビティは、標準アジャイル・プラクティスと呼ぶかアジャイル的なトラディショナル・プラクティスと呼ぶかは別として、そういったプラクティスの具体化を表しています。ここには、3つの重要な並列フロー、すなわち、繰返し設計(iterative design)、品質保証監査(quality assurance audit)、構成管理(configuration management)、が含まれています。繰返し設計フローは、更に2段に分かれた並行タスクに分解されます。1段目は、スパイラル前計画策定(Prespiral planning)、開発環境の定義と展開(define and deploy the development environment)、要求開発(requirements development)から成っています。2段目は、プロジェクト統制(project control)、マイクロサイクル(Microcycle)、変更管理(change management)から成っています。ソフトウェア開発は、「マイクロサイクル」と呼ばれている繰返しステップの中で行われます。

図1. Harmonyソフトウェア・プロセス概要
Harmonyソフトウェア・プロセス概要

初期安全性分析

初期安全性分析の目的は、そのシステムやその利用・作動環境に固有の安全性に関する関心事を特定することです。これらの関心事というのは、プロジェクトの開始以前に知られていないような、後の設計でなされる技術的な決定に由来するような安全性への影響というのは含んでいません。しかしながら、そういったものも、この記事の中で継続的安全性アセスメントとしてとりあげるプラクティスの中では特定され、分析されることにはなります。

「固有な」安全性の関心事というのは、そのほとんどは、実現のための必要な設計とは独立しているものです。例えば、自動車は、道路上で人を運ぶ装置であり、そのこと自体として、搭乗者や車の周りの人々の基本的な安全性に関する懸念事項を含んでいます。例えば、

  • 車をうまく効率よく停止できないことによる衝突
  • 車を正確に操縦できないことによる衝突
  • 前進・後退動作の制御不能による衝突
  • 車への制御操作に対するドライバーへの視覚的フィードバックの不足による衝突
  • 車からの落下

これらの懸念は、車がどのように動力を伝え、加速、減速するかということとは関係はありません。それらは、単に車が動くという本来の性質からくるものであり、衝突によって解放される動力学的エネルギーが、搭乗者や近くにいる人への怪我や死につながるかもしれない、という本来的な懸念なのです。設計上の決定事項に由来するような安全性の関心事については、次の継続的安全性アセスメント・プラクティスのセクションで取り上げます。

安全性に関するメタデータを把握するための主たる手段として、ハザード解析があります。また、そのようなデータを獲得する最も良く使われる手段として、フォルトツリー解析(FTA)があります。このタスクを、「初期の安全性および信頼性解析を実施する(Perform Initial Safety and Reliability Analysis」(図2参照)と呼ぶことにします。これは、図1に示されているスパイラル前計画策定アクティビティの一部になっています。では、これがアジャイル・プラクティスであるというのはどういうことなのでしょうか?

このプラクティスのHarmonyでの実現というのは、以下の意味においてアジャイルと言えます。

  • それは、インクリメンタルに、並行して、そして要求開発と協調しながらなされます。
  • それは、安全性への関心事を、リスクの優先度付けの枠組みの中でインクリメンタルに取り上げてゆき、まず最も高度なリスクから取り上げていきます。それぞれリスクが取り上げられるに従い、要求モデルも更新され検証されていきます。
  • それは、実行可能要求プラクティスへ統合されます。そして、テスト駆動開発のアプローチをとることで、FTAから生まれてくる要求の完全性、一貫性、正当性をインクリメンタルに検証できます。

スパイラル前計画策定プラクティスは、図2にある6つの並行タスクからなっています。

  • スケジュールを作成する(Create Schedule)
  • チーム構造を作成する(Create Team structure)
  • 再利用を計画する(Plan for Reuse)
  • リスク縮小を計画する(Plan for Risk Reduction)
  • 論理的アーキテクチャを明確化する(Specify Logical Architecture)
  • 初期の安全性および信頼性解析を実施する(Perform Initial Safety and Reliability Analysis)
図2. スパイラル前計画策定
スパイラル前計画策定

このプラクティスの結果得られる主要な結果としては次のものが含まれます。

  • 初期のハザード解析(未軽減および軽減化された安全性の関心事の両方を含む)
  • フォルトツリー解析
  • 安全性に関連した要求(安全性対策要求を含む)

FTAは、危険な状態を明示的に表現するために、事象と(正常時および故障時)条件の組合せをグラフィカルに示した一連の図として表されます。この作業は、単独のFTAツールを用いて行うこともあれば、IBM Rational RhapsodyソフトウェアのFTAプロファイル(正式にはSafety Analysis Profile)を用いて、要求および設計モデルの中に統合することもできます。

図3では、異なる故障状態が論理的に結合されて一つの危険状態を表現している様子がわかると思います。標準的なFTAの条件・事象・論理演算子に加えて、このFTAプロファイルは、関連付けられる要求や、この安全性への懸念を明示し、検知し、軽減する、といった設計要素へのトレーサビリティ・リンクを提供することもできます。この例では、危険は「目標の誤認識(target misidentification)」であり、それは異なる中間状態、例えば、低減できていない画像ノイズ、通信遮断、目標データの破壊、目標仕様の不具合等により引き起こされることを示しています。

ここで起きているそれぞれの状態は、原因となる事象と条件に由来しています。FTAツリーの底辺では、正常事象と条件、あるいは、初期段階で未発達な故障といった最初の要素が置かれています。このような分析を、システムが起こしうる危険のそれぞれについて行うことで、そのシステムが安全に目的を果たす上で保持しなければならない安全機構に関する思考を展開していくことができます。

この例では、目標の誤認識を引き起こすかもしれないメッセージの破壊を検知するために、メッセージの内容に対してCRCの計算をするという安全性の方策を採っているのがわかると思います。この最初の故障が危険状態として出現するためには、次の故障(すなわちCRCが破壊の検知に失敗する)も起こることになります。したがって、この例の場合、この危険が生じるには元の故障と保護機構の両方の故障が同時に起こる必要があるとしたことで、そういうことが起こりにくくしていることになります。しかるに、この初期安全性分析から、メッセージの破壊を検知する方法(具体的にはCRC)を安全性要求として追加するに至るというわけです。

図3.FTAプロファイル機能を使うRational RhapsodyのFTA図
FTAプロファイル機能を使うRational RhapsodyのFTA図

このFTA図のそれぞれのグラフィカルな要素は、単なる表記ではなく、それが表現する事の個別の意味や(メタデータとして知られている)情報を持った要素になっています。例えば、危険(Hazard)は通常次のようなメタデータを持つものです。

  • 耐障害性持続時間
  • 発生確率(非軽減のケース)
  • 発生確率(軽減されるケース)
  • 深刻度(非軽減のケース)
  • 深刻度(軽減されるケース)
  • リスク(非軽減のケース)
  • リスク(軽減されるケース)
  • 安全度水準

故障(fault)は次のような別の特徴を持っています。

  • 平均故障間隔(MTBF)
  • 発生確率
  • 作用機構
  • 顕在化要素(Manifesting element)
  • 検知要素
  • 検知手段
  • 軽減要素
  • 軽減戦略

システムが引き起こすかもしれない危険状態の全てについてFTA図が作成されると、このメタデータは、表にまとめることができます。これがプロジェクト開始の時点でなされた場合、初期ハザード分析とよばれるものになります。


継続的安全性アセスメント

推力を伝える手段を実現するある設計がなされると、新たな安全性への関心事が生まれます。これを「設計上の安全性懸念(design safety concerns)」と呼びます。例えば、車を動かすには、ディーゼルエンジンで動かす(これは可燃性燃料による発火や爆発のリスクを伴う)、大規模なバッテリーで動かす(これは感電や化学反応による爆発の危険を伴う)、原子力で動かす(これは被爆や危険物質の爆発のなんらかの危険を伴う)、フラックス・キャパシターで動かす(これはブラックホールを生成する恐れがある)、といった選択肢がありえます。これらは設計上の、あるいは技術上の危険と考えられ、通常は設計上の判断をしていく中で特定され、分析されていくものです。

Harmonyプロセスにおいて、継続的安全性アセスメント・プラクティスは、図1にも示されていたプロジェクト統制(Control Project)アクティビティの中の、「安全性と信頼性分析を更新する(Update Safety and Reliability Analysis)」タスクにより実施されます。図4は、プロジェクト統制アクティビティの中の幾つかのタスクを示しています。見てのとおり、このタスクは、ソフトウェアが開発されているマイクロサイクル全体とは並列に流れます。つまり、この分析は、ソフトウェアが詳細に仕様化され、設計され、実装されるのと同時並行でなされていきます。このタスクは、ウォーターフォール型プロジェクトでよく見られるようにプロジェクトの最後に実施されるのではなく、その目的は、プロセスの中で継続的に、技術的かつ設計上の安全性懸念を特定し取り上げていくことである、という意味でアジャイルなのです。このタスクの成果物は、現在や今後の設計イテレーションの中で受理される「更新された要求」ということになります。

図4.プロジェクト統制アクティビティ
プロジェクト統制アクティビティ

図4にあるように、プロジェクト統制アクティビティは次の4つのタスクから成っています。

  • イテレーションを管理する(Manage iteration)
  • リスクを管理する(Manage risks)
  • 安全性と信頼性分析を更新する(Update safety and reliability analysis)
  • 開発環境を洗練し展開する(Refine and deploy the development environment)

このプラクティスの目的は、対象システムが、デザイン・パターンやその他の技術が適用され実装されるのに並行して、安全が保たれている状態を確実にするということです。

このプラクティスの主要な成果物は次のようなものになります。

  • 設計ハザード分析
  • FTA(更新版)
  • 安全性関連要求
  • 安全性アセスメント報告書

実行可能要求モデリング

要求には厄介な側面があります。要求は、通常は、「人が読む」文書として.表現され、機能的、および、クオリティ・オブ・サービスの両方の観点から、システムが持つべき特質を詳しく述べるために使われます。厄介であるというのは、システムというのは非常に複雑で、人間の言葉で十分完全に述べつくすことは難しいということです。なぜなら、システムの多様な機能性や性能を捕らえるには数百数千の単位の記述が必要になるからです。人間が使う言語は非常に表現力が豊かですが、曖昧さや、正確さに欠けるという問題も含んでいます。更に加えて言えば、このような大量の要求を、完全性、正確性、一貫性において検証できるような信頼できる方法が無いわけです。

一方、モデルというのは、非常に正確であり、曖昧さもありません。それは、人間の言語のような豊富な表現力はないのですが、そのかわり厳密さが増すと言えます。モデルを構築することで、形式的な分析手法(例えば到達可能性分析)や、実行とテストといった手段により、「検証」することが可能になります。実行可能モデルは、シミュレーションまたは実行ができる程度な正確さを持っており、関連する全ての状況や条件におけるシステム・データと制御の変換を記述して、それを用いて仕様がユーザ要求を満たしていることを検証することができます。

人工呼吸器の2000もの要求が書いてある文書を想像してみましょう。それは、システムが様々な状況に応じて対応すべきシステム・パラメタを詳しく記述しています。例えば、一回換気量(一呼吸ごとの換気量)、酸素濃度、バランス・ガス組成、呼吸速度、などです。もしユーザが、呼吸速度を毎分20呼吸とし、一回換気量を600mlとし、次に酸素濃度を設定しようとしているとき、システムはどのように振舞うべきか、あなたならどのように決めるでしょうか。許容される酸素濃度は、十分な総酸素流量を保証するために、そこでの設定次第でおそらく変わってくるでしょう。

普通の要求文書であれば、この質問に対して、一貫性や完全性を確実にするために、全ての関連する要求を探すことになります。それは時間がかかる困難な検索になるでしょう。それで、結局結論がでないかもしれません。実行可能モデルであれば、特定のケースに対してどう規定されているのかを、シミュレーションを走らせることで確認することができます。極端に言えば、システムは、それが規定されていたかどうかにかかわらず、何らかのはっきりとした動作をしてしまうものである、という点は気に留めておく必要があります。正しいシステムを作りたければ、その正しさを仕様書の中で定義しておくことは重要なことです。

モデルの観点から、Harmonyでの要求記述のやり方は以下のようなものになります。

  1. ユースケースの観点から要求をそれぞれ独立したまとまりに分ける。(独立という意味は、実装が独立しているということではなく、あくまで要求として独立であるということ。)
  2. それぞれのユースケースを複数のシナリオとシーケンス図を使って詳細化する。シーケンス図上のそれぞれのメッセージは、文章として記述されている何かの要求に関連付ける。シーケンス図のライフラインは、そのユースケースと、アクター(すなわちシステムの外部要素でシステムとやりとりするもの)とである。
  3. ユースケースは、規範的なステートマシンを使って詳細化する。それぞれのシナリオがそのステートマシンで表現される流れと合うようにする。ステートマシン上のトリガ・イベントは(大抵は)アクターからのメッセージであり、ステートマシン上のアクションは(大抵は)その同じアクターへの返信である。
  4. 要求は、シナリオやステートマシンに対して追加していき、段階的に検証していくことが可能なので、そのユースケースに関する全ての振舞いや制約条件がモデル化されるまで、ステップ2へのループバックを繰り返す。

図5にこの作業手順を示しています。この手順のアジャイルな特質は、以下のようなところからわかります。

  1. 我々は、要求モデルの開発を「深さ優先」に行います。このことは、大雑把なレベルにおいて実行可能なユースケース仕様を開発することと、詳細レベルにおいて、この実行可能ユースケース仕様を、少しずつ徐々に作りながらも、継続的に検証して構築していくという、両方のレベルを含みます。
  2. トレーサビリティについても同様で、ウォーターフォール型のプロセスのように要求フェーズの最後にではなく、インクリメンタルに追加するという形をとります。

このステートマシンは、そのユースケースの規範的な仕様を形作っており、適切になされたならば、実行可能になります。図6は、動作中のモデルのあるスナップショットを示したものです。その一部は、Rhapsodyで実現されており(その中で色を使って強調表示してシミュレーションにおけるそのユースケースの現在状態を明らかにしており)、また、一部の制御ロジックではMathWorks社のSimulinkを使うことで、協調シミュレーションがなされています。

図5.実行可能要求モデリング・プラクティス
実行可能要求モデリング・プラクティス

さて、文書の表現力を取るか、モデルの正確さを取るか、という点ですが。ベストプラクティスとしての答えは、両方の良いところを使いましょう、ということになります。このことは、次に議論するトレーサビリティ分析プラクティスにて追加されるトレースリンクの中に現れてきます。

図6.実行可能要求モデルの例
実行可能要求モデルの例

トレーサビリティ分析

セーフティクリティカル・システムの開発では、それぞれ異なる側面に焦点を当てたたくさんの成果物が作られることになります。それらに一貫性があることを確実にするために、個々の要素が一つの視点から別の視点にどのように関係しているのかを示すためのトレーサビリティ・リンクが追加されます。一般的に必要とされるトレースリンクというのは、以下のようなものです。

  • 利害関係者要求からシステム要求へ
  • システム要求からシステム・ユースケースへ
  • システム要求からソフトウェア要求へ
  • ソフトウェア要求からソフトウェア・ユースケースへ
  • ソフトウェア要求からアーキテクチャへ
  • ソフトウェア要求から設計へ
  • ソフトウェア要求からソースコードへ
  • ソフトウェア要求からテストケースへ
  • アーキテクチャから設計へ
  • 設計からソースコードへ
  • ソースコードから実行可能オブジェクトコード(EOC)へ
  • テストケースからソースコードへ
  • テストケースからテスト結果へ

これらのトレースリンクは双方向であるべきです。例えば、ある(一つの)要求からそれを実現する(複数の)設計要素への追跡ができるならば、逆にある(一つの)設計要素からそれが実現を担う全ての要求への追跡もできるべきであるということになります。

このようなトレースリンクを作成して維持していくことは、Rational DOORS のような要求管理ツールが作業の多くを自動化してくれるとはいえ、大変チャレンジングな取り組みです。一連のトレースリンクを表現する方法はたくさんあります。スプレッドシートは最も良く使われている方法ですし、DOORSソフトウェアに加えてその他の表形式による表現を使うこともできるでしょう。トレースリンクは、モデルの中ではUMLの<<trace>>依存関連を使って追加することもできます。図7は、個々の要求からユースケースへのリンクを表示することで、トレースリンクがユースケース図の中でどのようにグラフィカルに表現されるかを示しています。DOORSはアジャイルとは直接関係ありませんが、要求をインクリメンタルに開発し要求のもつ特性を管理しながら発展させていく発展的な開発ライフサイクルにおいて使うことは、もちろん可能です。

図7.UML中のトレースリンク
UML中のトレースリンク

このような一連の図に含まれているリンクを表にまとめて表示することも可能です。図8はそれを示しています。

図8.生成されたトレーサビリティ表
生成されたトレーサビリティ表

トレーサビリティは、インクリメンタルに追加されていくものです。設計要素がテスト駆動開発プラクティスにしたがって安定化されたら、直ちにリアルタイムに(トレーサビリティの作業を)実施する、というのがベストでしょう。ソフトウェア要求がユースケース・シナリオやステートマシンに対してインクリメンタルに追加されたときに、ソフトウェア要求からソフトウェア・ユースケースへのトレーサビリティが追加される、というのも一例でしょう。これは、図5に示したタスクの中のステップにてなされていきます。


要約

セーフティクリティカル・システムは、セーフティクリティカルでないシステムに比べ、開発はより困難になります。通常の品質や市場投入までの時間といった関心事に加え、関係する安全性標準から要請される目標を満たさなくてはならず、厳格な認証にも対応しなければなりません。チームや組織は、大筋において、品質向上・プロジェクトの予測可能性・エンジニアリングの効率といった観点に基づいて、アジャイルな方法へと移行しています。一般的なアジャイル・プラクティスは、セーフティクリティカル・システムにおいてうまく当てはまりますが、安全性の目標を確実に満たすために、仕立て直す、カスタマイズして用いる、ということも必ず必要になります。

Harmonyプロセスは、多くのプラクティスを含んでいます。それらは、分析、設計、品質、証拠構成、といったものに分類できます。この記事にて解説した主要なプラクティスは、初期安全性分析、継続的安全性アセスメント、実行可能要求、トレーサビリティ分析でした。これらのプラクティスは、セーフティクリティカル・システムの開発に必要なプロセスに厳格さや完全性を取り入れるという形で、最も広く使われているアジャイル・プラクティスを強化をしたものになっています。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のBruce Douglassを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。

参考文献

学ぶために

製品や技術を入手するために

  • Rationalソフトウェアの試用版ダウンロードはこちら。free trial version (US)
  • 目的に応じてIBMソフトウェアの評価ができます。ダウンロード、オンライン評価、クラウド環境での利用が可能です。Evaluate other IBM software (US)。SOAサンドボックスによりサービス指向アーキテクチャの学習も可能です。 SOA Sandbox (US)。

議論するために

  • Rational DOORSフォーラムに参加して質問や議論をしましょう。 Rational software forums (US)
  • こちらで質問や回答を通して専門性が高まります。 Rational forums, cafés, wikis (US)
  • 仲間とつながり最新の情報交換をしましょう。 Rational community (US)
  • Rationalソフトウェアの評価・レビュー。手間はかかりません。簡単です。Rate or review (US)

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=945615
ArticleTitle=セーフティクリティカル・ソフトウェア開発のためのアジャイル分析プラクティス
publish-date=09202013