Vol.3 No.3 2010

23/84

研究論文:複雑システムの信頼性を向上させる開発手法(加藤ほか)−199−Synthesiology Vol.3 No.3(2010)るためである。また、産業界の実例に対してこの研究での開発手法を適用することで、開発手法としての有効性を確認する。適用対象として産業界の実例を選択した理由は二つある。理由の一つ目は、本開発手法が産業界において実用可能であることを確認するためには、サンプル的なケースではなく、安全性などの考慮が必要な、機能的に複雑な実例を適用対象とする必要があるためである。理由の二つ目は、産業界の実例に対する開発手法の有効性を社会に発信することにより研究活動と、研究成果の社会貢献との間のギャップ、いわゆる死の谷を越えられる可能性があるためである。3 技術の選択この研究における開発手法を確立するにあたり、本開発手法が満たすべき機能を次の二つに分解する。a.システム仕様を構成要素の仕様および構成要素間のインタフェース仕様に分解する機能b.構成要素の仕様および構成要素間のインタフェース仕様における協調動作が整合していることを検証する機能システム開発技術の中から、機能a.を満たすシステム設計技術を選択する。一般にシステム設計とは、ユーザーの要求を分析してシステム仕様にまとめること、さらにシステム仕様に基づいてシステムを構成する要素の機能および実現方法そして構成要素間の関係を仕様化する作業を指す。アーキテクチャ設計手法以外の代表的なシステム設計技術として、構造化分析・設計手法[13]用語12がある。構造化分析・設計手法とは、実現すべきシステムのデータの流れに着目し、システムを構成要素に分解する設計手法である。構造化分析・設計手法は、要求変更や技術の進歩に影響を受けやすい機能や処理ではなく、システム環境の変化に対して安定している業務情報などのデータに着目しシステム設計を行う。それにより、保守性および拡張性を有するシステムを構築することができる。しかし、構造化分析・設計手法は情報システムを念頭において開発された手法であることから、制御の流れや処理タイミングに関する設計を考慮していない[14]。したがって、組込みシステムなど情報システム以外のシステム設計には不向きな側面を持っている。一方、アーキテクチャ設計手法は、例えば前述のデータに着目するといった特定のシステム設計を行う場合、その設計に特化した手順や作業が規定されていないため、特定の設計手法に比べ労力を要する。しかし、アーキテクチャ設計手法は、システムの機能および実現方法を明確にするプロセスが規定されている、特定の技術システムに依存しない汎用的な設計手法である。したがって、この研究の目標としている特定の技術システムに特化しない開発手法を実現するという点を踏まえ、機能a.を満たすシステム設計技術として、アーキテクチャ設計手法を選択する。また、アーキテクチャ設計手法が規定される代表的なシステムエンジニアリング標準として、ISO 15288[9]用語13、ANSI/EIA 632[10]用語14、IEEE 1220[11]用語15が挙げられる。ISO 15288は、システムの概念検討から利用および廃棄というシステムライフサイクルプロセスの全般を適用範囲としているものの、アーキテクチャ設計における作業および手順が詳細には規定されていない。ANSI/EIA 632は、システムの概念検討から利用移行というシステムライフサイクルプロセスの広範を適用範囲としているものの、アーキテクチャ設計における作業および手順が詳細には規定されていない。一方、IEEE 1220は、適用範囲がシステムの要求分析・定義から試験に限定されているものの、アーキテクチャ設計における作業および手順が詳細に規定されている。したがって、本開発手法としてIEEE 1220に規定されるアーキテクチャ設計手法を選択する。また、システム開発技術の中から、機能b.を満たすシステム検証技術を選択する。一般にシステム検証とは、開発するシステムがシステムの仕様を満たすか否かを確認する作業を指す。モデル検査以外の代表的なシステム検証技術として、テスト手法用語16およびシミュレーション手法[15]用語17がある。テスト手法とは、テストケースに対する実プロダクトの動作を確認する検証手法である。実プロダクトに関する実際の動作を確認することができるものの、起こりうるすべてのケースをもれなく抽出し、それらすべてのケースにおける動作を確認することは困難である。シミュレーション手法とは、検証対象およびその周辺環境を計算機上にモデルとして模擬し、テストケースに対する検証対象モデルの動作を確認する検証手法である。実プロダクトおよび周辺環境が存在しない開発早期の段階で、検証対象の動作を確認することができるものの、テスト手法と同様に、起こりうるすべてのケースをもれなく抽出し、それらすべてのケースにおける動作を確認することは困難である。一方、モデル検査は、検証対象の状態遷移しか確認することができないものの、状態遷移については満たすべき性質が成り立つかどうかを網羅的に検証することができる。システムの状態遷移にデッドロック用語18などが存在する場合、システムの運用時に致命的な事象を引き起こす可能性がある。したがって、本開発手法として、モデル検査を選択する。次に、IEEE 1220に規定されるアーキテクチャ設計手法およびモデル検査を詳述する。

※このページを正しく表示するにはFlashPlayer9以上が必要です