モデルベース開発の拡張(XMBD)
- eXtended Model Based Development -

「開発」とは一般的に、多くの人員が関り、多くのプロセスを経て、完成に近づいて行きます。
プロセス開発とは、多くの人員が最後のゴールである成果物まで繋げてゆくマラソンの様なものです。
では、そのマラソンでランナー（各プロセスとそれを担う人員）たちが繋げていく「バトン」とは何か？を考えると、これはV字プロセスの最初に必ず作られる「要求」であると考える事が出来ます。
開発論法には、V字プロセスをはじめ、アジャイルやモデルベース開発など、様々な角度からのアプローチがありますが、その全ての目的が「要求」というバトンを途中で落とさずにゴールまで届ける事で、成果物の品質を高める事と全人員の意識の統合、そして作業の効率化をしたいという点にある事で、共通しています。

V字プロセスは、今日の開発の現場において多く使われている開発プロセスです。
プロセスを進めるにあたって、我々が認識しなくてはならない事は「V字プロセスを完成させる事で、必ずしも開発プロセスの最適な解に到達するわけではない（プロセスに最適な解は無い）」点です。

ここでは「V字プロセスで最先端(State of Art)と思われているものに対して、現実はどうなっているのか？」を踏まえて、"モデルベースの拡張"を提案いたします。

V字プロセスで”最先端(State of Art)”と思われているもの

生産プロセスにおける従来型モデル「ウォーターフォール」

従来型モデルには下記の特徴があります。

• 一般的にソフトウェア開発で使われる概念である。
• 「要求」から「実装」へ進むにつれて具体性を増し非抽象的になっていく。
  「単体テスト」から最終的な「キャリブレーション、検証、リリース」へ進むに従いテストは逆に抽象的になっていく。

製品開発プロセス合理的なモデル「V字プロセス」（折り返されたウォーターフォール）

「実装」は確実に「実装デザイン」を満たしたものでなくてはならない。
そのために「実装デザイン」は可能な限り非抽象的にする必要があり、それには下記の様な事が求められる。

• 「実装デザイン」を出来る限り具体的に書く。
• 「実装デザイン」に対する「単体テスト」に重点を置く。
• 「単体テスト」の範囲は「実装デザイン」と「実装」をカバーする。
  (「実装デザイン」の抽象度でのテストとなる)

メカトロニクスシステムは最終的に要求で定義された品質目標を満たすために…

• 「要求」に対する「検証」がされる。
• 必要に応じてキャリブレーションがされる。

これらは「要求」の抽象度での要求検証となる。

①と②より、V字の右側プロセスは対応する左側プロセスの抽象度で行われる事が判ります。

製品開発プロセス合理的なモデル「MBD V字プロセス」（折り返されたウォーターフォール）

“システムデザイン”プロセスの加速
フィジカルシステムと制御に「モデル」を使用する。

• それにより設計ソリューションはより具体的になる。
  しかし、それは論理的根拠があるとは言い難い。
• 設計ソリューションにおける「システムデザイン」と実行可能な「実装デザイン」との境界が曖昧になっている。
• 自動実装（自動コーディング）。

• MIL、SIL、HILシミュレーションの使用による事前仮想テスト
  プロトタイプでの実テスト回数の削減
  テストでカバーできる範囲と種類の増加
  
• 仮想シミュレーションで”事前” キャリブレーション

ここでは”抽象レベルの検証”と”非抽象レベルの検証”の統合がなされます。

前述の通り、「要求」や「実装デザイン」のレベルにおいてV字の対応する左右プロセスは、それぞれ同じ抽象度で行われます。
右側で抽象と非抽象の統合がされていますが、これは左側の対応するプロセスが同じ抽象度(設計ソリューションがより具体的)である事が前提となりますます。

製品開発プロセス合理的なモデル「MBSE V字プロセス」（折り返されたウォーターフォール）

“システムデザイン”プロセスの加速
システム・オブ・システムズと言われるような複雑化が進むに従い「設計が要求を正しく捉えて書かれているか？」はこれまで以上に重要となります。

その為には…

• これまで以上の「要求」の具体化
• 具体化された「要求」と、その実現(不)可能性の分析
• 「要求」に対する「システムデザイン」の事前検証

が必要になります。

「要求」は抽象的であり「検証」も非構造的ではありますが、具体的な「実装」されたものを「検証」するための「要求」もまた、より具体的である事が求められます。


これが今日一般的に「 State of Arts(最先端) 」と言われているものです。
“State of the Art”は、MBDに用いられるプロセスやツールにおいて最新の開発と一般的に”思われている”ものです。
世のツールは“State of the Art”をサポートする目的で開発されています。

しかし…

V字プロセスの”現実(State of Practice)”

製品開発プロセス経験に基づいた実証的モデル「デザイン～要求間で繰り返されるプロセス」

現実には図の様な繰り返しが発生し「State of the Practice」とも言える状況となっています。
これからわかる事は、

• 「要求」は必ずしもプロセスのスタート地点では無い。
• 現実の開発はプロセスのどこからでもスタートし得る。
• コード、モデル、 デザインアイデア、 何れもスタート地点になり得る。
• 開発は”繰り返し”の連続であり、「要求」は「システムデザイン」、「実装」などと相互に影響を与え合う。
• 「要求」は「システムデザイン」、「実装」、「テスト」からの”繰り返し”により修正や再定義がなされる。

これが、どの様な開発においても必ず起こり得る「現実」と言えます。


既存のツールやプロセスは”State of Art”を前提として 作られているので、”State of Practice”をモデル化し、サポートさせる為には、その間を紐づけるための“新しいツール”が必要であることが判ります。