MBSE

すべてのモデルは間違っているが、一部は有益である。

─ジョージ・E・P・ボックス

モデルベースシステムエンジニアリングの概要

人間は、システムや建造物の設計を始めたときから、抽象化、学習、伝達のためにモデルを使用してきた。モデルベースシステムエンジニアリング(MBSE)とは、構築前にシステムの特徴を学習するための費用効率の高い方法として、要求、設計、分析、検証作業のモデリングを行うことである。モデルを使用することで、システムに関する意思決定について早期にフィードバックを得ることができ、システムの意図するところを、顧客、利害関係者、開発者、テスト担当者など、関係する全員に伝えることができる。

ボックス博士が主張するように、モデルで実世界を完全に写し取ることはできないが、実装で得られるよりもずっと早期かつ安価に知識とフィードバックを得ることができる。実際にエンジニアは、モデルを使って知識を得たり(パフォーマンス、温度、流体など)、モデルに沿ってシステムを実装したり(SysML、UMLなど)、場合によっては実際の実装を直接構築したりする(電気CAD、機械CADなど)。

モデルを使ってシステムの特徴やプロパティや振る舞いを早期にテストし検証することで、要求や設計の意思決定に対する早期のフィードバックが可能になり、早い段階での学習が促進される。

詳細

工学の分野では、何年も前からモデリングを使用して、ライフサイクルの早い段階で、構造や振る舞いを発見して仕様化し、代替案を検討し、決定内容を伝えてきた。リーンのプラクティスでは、小さい作業の継続的なフローを実現し、意思決定に対する素早いフィードバックを得ることで、素早く学習することができる。モデルベースシステムエンジニアリング(MBSE)は、変更コストが大きくなりすぎる前に開発対象のシステムについて素早くインクリメンタルに学習するための、規律でありリーンなツールである。

モデルで学習サイクルをサポートする

MBSEでは素早い学習サイクルをサポートしているため、プロダクトのライフサイクルの早い段階でリスクを軽減するのに役立つ。モデルを使ってシステムの特徴やプロパティや振る舞いを早期にテストし検証することで、設計の意思決定に対する早期のフィードバックが可能になり、早い段階での学習が促進される。

モデルの形式は、動的、立体、グラフ、方程式、シミュレーション、プロトタイプなど、さまざまである。図1のように、それぞれがシステムの1つまたは複数の特徴を異なる視点から表していて、それによってシステム能力やフィーチャーを作成することが可能になる。

図1.  モデルと学習サイクル

モデルによって、パフォーマンス(応答時間、信頼性)や物理プロパティ(温度、放射、強度)を予測できたり、ユーザーエクスペリエンスの設計や外部刺激に対する反応を調査することができる。

影響分析とコンプライアンスに追跡可能性を使用する

モデル間の関係によって、システムの有用性をさらに予測し、分析とコンプライアンスの作業をサポートすることができる。システムには、さまざまな分野(電気、機械、ソフトウェアなど)のモデルが含まれることがあるし、システムレベルの要求や設計のモデルが含まれることもある。追跡可能性は、モデル内およびモデル間でシステム要素を関係付けることで得られる。これには多くの利点がある。

  • 規制および契約上のコンプライアンスのニーズのほとんどを単純化し自動化できる。
  • 新しい作業をサポートするのに必要な影響分析の時間と工数を削減でき、検査と適応の作業に情報が提供される。
  • 一つの分野のモデルから別の分野のモデルへ追跡できるため、分野横断的な協調が容易になる。
  • 情報(および関連する分野横断的な情報)にチームがアクセスしやすくなるため、汎用的な知識の発見が進む。

リーンで常に変化し続ける環境では、モデルの関連付けの必要性が高まる。カバレージやコンプライアンスを手動で管理する方法は、ステージゲートプロセスでは十分に機能するかもしれないが、頻繁で継続的な変化を推奨するアジャイルな環境では、すぐに無理がでてくる。

図2に示す高いレベルのモデルリンク構造では、要求が、テストモデル内のテストと、システムモデル内のシステムレベルの要素とにリンクされている。

図2.  ドメイン横断的なモデルのリンク

さらに、ドメインモデルはシステムモデルにリンクされている。エンジニアは、要求の変更がシステムやドメインに及ぼす影響や、ドメインレベルの変更がシステムおよび要求の他の部分に及ぼす影響を、素早く確実に理解することができる。さらに、リンクの有無を見ることでカバレージやコンプライアンスの漏れが分かる(要求がテストされていないなど)。

この追跡可能性の情報を手動で作成して保守する代わりに、モデル情報とモデル間のリンクからコンプライアンスドキュメントを生成することができる。システムの要求や設計が変更されたときには、追跡可能性の情報から、変更の影響や、テスト/要求のカバレッジの漏れ、疑わしくなったため再確認が必要なリンク情報などが明らかになる。

ソリューションの意図にモデルを記録する

技術的な知識や意思決定は、ソリューションの意図に記録され、ソリューション開発全体のチームメンバーに伝えられ、参照できるようになる。現実には、技術情報は、ドキュメントから、スプレッドシート、モデリングツールまで、さまざまな形式で表現される。ドキュメントやスプレッドシートは、記述する側にとっては作成しやすいが、リーンなシステムエンジニアリングに必要な知識移転や継続的協調にはつながりにくい。そのために必要なのはモデルベースシステムエンジニアリング(MBSE)である。

ソリューションの意図には、さまざまな種類のモデルが含まれ、情報を整理してリンクするオプションも数多く存在する。一般に、モデル情報や組織の記述から品質の確保までの作業は、システムおよびソリューションアーキテクト/エンジニアが責任を負う。アジャイルチームは、それぞれの持つ知識や情報をモデルに追加する。書き込む人が多い大規模システムの場合には、モデル所有者の役割を割り当て(たいていはシステムエンジニアリングのメンバー)、モデルの内容や構造の一貫性を保つ責任を負わせることがある。

コンプライアンス用のドキュメントを生成する

SAFeでは、早期発見のために、またはシステムドキュメントとして、モデルを使用することを重要視しているが、多くのプロダクトやエンジニアリングの領域では、法規制の順守(FAA、FDAなど)や契約上の義務(政府機関との契約のCDRLなど)のためにドキュメントが必要になる。さらに、利害関係者全員がモデルやその表記法を熟知しているとは限らず、情報を伝えるのにドキュメントを使い続けるわけではない。

可能な限り、ドキュメントはシステムモデル内の情報から生成するべきである。(コンプライアンスドキュメントを作成するという重複した作業をエンジニアが行うべきではない。これはリーンの言うムダの例である。)さらに、システムのさまざまな視点から利害関係者向けにドキュメントを生成することができる。アーキテクチャーフレームワークの標準(DoDAFやMODAFなど)では、システム情報を伝えるための複数の利害関係者の視点やさまざまなビューが定義されている。すべての利害関係者のビューをまたがって一貫性を保つには、モデルからドキュメントを生成するのが一番である。

正式なドキュメントはすべてのプロダクトやプログラムでおそらく必要になるが、システムエンジニアは、義務を果たせるだけの最小限のドキュメントで顧客や規制機関と協力して働くことが好ましい。すべてではなくてもほとんどの情報がエンジニアリングリポジトリに格納される。検査や公式のレビューでは、それを使用できるし、可能な限り使用するべきである。

モデルの品質を作り込む

先に述べたように、情報の追加は多くの多様な人が行うため、モデルの品質を保つのは困難になりかねない。適切に監督しなければ、多くの人が継続的に変更を行うことで、品質が低下してしまう。モデル所有者は、チームと協力して、品質プラクティス(モデル標準やモデルテスト)を定義し、それが確実に守られるよう手助けする。

以下で説明する品質プラクティスは、早期の学習サイクルを実現するのに役立つ。SAFeでは「ひどいコードは大規模展開できない」と述べているが、モデルに表現されたシステム設計についても同じことが言える。品質プラクティスを導入することで、エンジニアは自信をもって頻繁にモデルの変更をすることができ、システムの意図を実現するのに貢献できる。

モデル標準

モデル標準は、品質を制御し、最善のモデリング方法をチームに伝えるのに役立つ。この標準には次のような内容を含めることができる。

  • どのような情報を記録するべきか。
  • モデリング表記法(SysMLなど)と、その表記法のうち使用する部分と使用しない部分(ユースケースなど)。
  • ソリューション要素やサブシステム要素に関するモデリング情報をどこに置くべきか。
  • モデル要素の種類ごとに、格納しなければならないメタ情報。
  • モデル内のリンク、他の分野横断的モデルとのリンク。
  • システム全体で使われる共通の型や共通のサイズ。
  • モデリングツールのプロパティや構成(おそらくはエンジニアリング環境の一部)。
  • 使用するバージョン管理システムとの協調プラクティス(関係がある場合)。

モデルからドキュメントを生成する場合には、早い段階でドキュメントテンプレートを定義するべきである。ドキュメントテンプレートがこれらの決定に影響するためである。システム設計者は、クエリやドキュメント生成やコンプライアンスで使用するモデル要素や、そのモデル要素で必要なメタデータやリンクを、どこに格納するかを知っておく必要がある。

ベストプラクティスは、システム全体の高いレベルのモデルを見本として早期に作成することである。この見本がソリューション全体のスケルトンモデル(すべてのサブシステムを定義したもの)であり、1つの要素を使って1つのサブシステムの構造と振る舞いをどうモデリングすればよいかを示したものであれば理想である。この構成を使って早い段階でドキュメント生成のテストを行うと、必要なものがすべて揃っているかを確認することができ、情報が足りないためにモデルを作り直す(ムダ)必要がなくなる。

テストと実行が可能なモデルを作成する

SAFeのテストファーストのプラクティスを実施すると、早い段階でプロダクトに品質を作り込むことができ、アジャイルソフトウェア開発で見られる継続的な小さい変更が容易になる。テストファーストでは一揃いの豊富なテストケースを作成する。開発者はそれを使用することで、システムの別の部分でエラーを発生させることなく自信をもって変更を行うことができる。

リーンのプラクティスでは、必要に応じてテストと実行が可能なモデルを作成し、下流のエラーに伴うムダを削減することを推奨している。ドメインまたは分野の評価基準が存在する場合には、それに照らしてモデルをテストできなければならない。機械のモデルには物理的問題や環境の問題に関するテストが、電気のモデルにはロジックのテストが、ソフトウェアモデルには例外に関するテストが、実行可能システムモデルにはシステム動作に関するテストがある。ほとんどのモデリングツールには、モデルをチェックしたり、モデルを反復的に処理して異常を探すスクリプトを作成したりする機能が備わっている。

要求モデルのテスト。要求をテキストで表したものは、ほとんどすべてのシステムで使われ、現在のプラクティスでは通常、手作業でレビューされる。コミュニティーでは、実行してテストできる形式で要求を仕様化するという「実行可能な仕様」を、長い間模索してきた。しかし、それが成功したのは、問題をうまく定義できる特定のドメインに限られていた。アジャイルプラクティスでは、受け入れテスト駆動開発(Acceptance Test-Driven Development:ATDD)という、実行可能な仕様の改良形を提唱している。システム開発でも、ATDDをサポートする調査的な仕事が行われ始めている。しかし、ATDDは、要求テストの解決策として見込みはあるものの、まだ大きな規模では使われていない。要求とテストを可能な限り同一にし、できる限り自動化するべきである。

分析モデルと設計モデルのテスト。モデルに表現された設計は、静的と動的と、どちらの方法でもテスト可能である。モデリングツールは、通常、モデルの中に異常がないかを確認する静的モデルアナライザー(「チェッカー」)を備えている。モデルの所有者は、モデルの構成、モデリング規約やモデリング標準、必要なメタ情報(SysMLのタグ、ステレオタイプなど)といった、独自の規則を付け足すことができる。アナライザーが存在しない場合には、スクリプトでモデルを反復的に処理して、静的モデル内の違反を探すことができる。

モデルは動的にテストすることもできる。エンジニアリング分野のモデルには品質評価を行うための独自のソリューションがあるため、それをテストプラクティスの一部として利用するべきである。

テストの追跡可能性。適切なクエリや、ドキュメント生成、コンプライアンスを確実に行うには、モデルが決められたリンク構造に従っていなければならない。

ドキュメント生成。上記の追跡可能性のスクリプトと重複するかもしれないが、ドキュメント生成用に、モデルの構造が適切であり、すべてのドキュメントテンプレートに対応するすべてのデータが存在することを保証するスクリプトを作成する場合がある。規模の大きなモデルでは、ドキュメントテンプレートよりもスクリプトをデバッグする方が容易であることが多い。


最終更新日:2015年9月27日