IDEF6
IDEF4設計活動のIDEF6モデル[ 1 ]

IDEF6または設計根拠の統合定義 (Integrated Definition for Design Rationale Capture)は、エンタープライズ システムの開発で使用される設計根拠の取得、表現、操作を容易にする方法です。意思決定プロセスを推進する動機を定義することを目的としたこの方法はまだ開発中です。[ 2 ]根拠とは、設計者が特定の戦略や設計機能を選択した理由、正当性、根底にある動機、または言い訳です。簡単に言えば、根拠は「なぜこの設計はこのように行われるのか」という質問に対する答えとして解釈されます。ほとんどの設計手法は、設計が何であるか (つまり、設計がなぜそのようになっているかではなく、最終製品) に焦点を当てています。[ 1 ]

IDEF6 は、システムおよびソフトウェア エンジニアリングの分野におけるモデリング言語のIDEFファミリーの一部です。

概要

設計根拠は、明示的に記述された場合、通常は構造化されていないテキストコメントの形で存在します。必要な情報を見つけることが困難、あるいは不可能であることに加え、設計根拠の記述を体系化し、完全性の基準を提供するための構造化された方法が欠如しているため、重要な情報が文書化される可能性は低くなります。設計とは何か（設計仕様）を文書化するための設計手法とは異なり、IDEF6設計根拠記述法は、以下の情報を取得することを目的としています。[ 3 ]

  • デザインがなぜそうなるのか
  • なぜそれが他の形で現れないのか、そして
  • 最終的な設計構成にどのように到達したか。

IDEF6は、情報システムの設計根拠を捉え、それを最終システムの設計モデルおよび文書に関連付けるための表現能力を備えた手法となることを目指しました。したがって、IDEF6は、最終設計に貢献する、あるいは最終設計に至る決定の根底にある論理を捉えようとします。設計根拠を明示的に捉えることは、過去の過ちを繰り返すことを回避し、提案された設計変更の影響を直接的に判断する手段を提供し、目標と仮定を明確に記述することを促し、最終的なシステム仕様の伝達を支援します。[ 3 ]

情報システム開発で一般的に見られる主な設計モード

IDEF6は、必要な概念的リソースと言語能力を備えた方法となるだろう[ 4 ]

  • 特定のシステム内の設計根拠を構成する情報の性質と構造を表現すること、そして
  • その根拠をシステムの設計仕様、モデル、およびドキュメントに関連付けます。

IDEF6の適用範囲は、情報システム開発プロセスの全段階、すなわち初期概念化から予備設計および詳細設計活動までを網羅する。ソフトウェアシステムの詳細設計上の決定がコーディング段階に委ねられている限り、IDEF6の手法はソフトウェア構築プロセスにおいても利用可能であるべきである。[ 4 ]

設計上の決定が状況の制約によって完全に決定されない場合、設計根拠が重要になります。したがって、決定ポイントを特定し、それらの決定ポイントに関連する状況と制約を定義し、選択肢がある場合は、選択された選択肢の根拠と、他の選択肢（つまり、選択されなかった設計オプション）を破棄する根拠を記録する必要があります。設計根拠を記録する作業は、以下の目的に役立ちます。

  • 企業情報システムの進化的な統合を可能にします。
  • 情報システム開発における並行エンジニアリング手法の使用を可能にします。
  • ライフサイクル アーティファクト間のより優れた統合をサポートします。
  • ビジネス ケースの決定の根拠を把握することで、ビジネス リエンジニアリングを促進します。
  • 意思決定の効率的な追跡を可能にします。

根拠の捕捉は、システム開発プロセスのすべてのフェーズに適用できます。IDEF6の対象ユーザーは、ビジネスシステムエンジニア、情報システム設計者、ソフトウェア設計者、システム開発プロジェクトマネージャー、プログラマーなどです。

IDEF6トピック

基本概念

設計根拠（なぜ、どのように）は、設計仕様（何を）および設計履歴（実行された手順）という関連概念と対比される。設計仕様は、最終的な物理的な成果物においてどのような意図が実現されるべきかを記述する。設計根拠は、設計仕様がなぜそのようになっているのかを記述する。これには、動作原理や動作原理、正しい動作モデル、そして成果物が故障した際の動作モデルなどの情報が含まれる。設計プロセス履歴には、実行された手順、それらの手順に至るまでの計画と期待、そして各手順の結果が記録される。[ 1 ]

  • 設計根拠現象 : 設計根拠の一般的な特徴付けは、「人間が設計上のコミットメントを行う (または正当化する) ため、およびそれらのコミットメントを広めるために使用する信念と事実、およびそれらの構成」とすることができます。
  • 設計根拠の把握における問題 ：根拠が失われる理由の一つは、ソフトウェア成果物の仕様策定から完成までの時間差が長いことに起因しています。また、明確に把握されるべき設計根拠とは何かという一般的な理解を深めることにも問題があります。つまり、設計根拠を表現する上で顕著な困難は、その概念自体が一様に理解されていないことです。これは、人工知能（AI）研究者が依然として取り組んでいる他のあらゆる「説明」形式と共通する特徴です。

手順の開発

Sysと呼ばれる設計パーティション。構成する静的モデルと動的モデル、そして関連する要件モデルを示しています。要件モデルにはIDEF0の機能モデルが含まれており、そのアクティビティはIDEF3のプロセスシナリオを呼び出します。
分析モデルの機能および使用シナリオと、要件および目標ステートメントとのマッピング。設計がアクティビティや使用シナリオを適切にサポートしていない場合、要件モデルを使用することで、設計者は違反している要件制約や目標ステートメントを容易に特定できます。

IDEF6では、根拠収集手順は、分割、分類／仕様策定、アセンブリ、シミュレーション／実行、そして再分割という活動から構成されます。進化する設計におけるシミュレーション／実行活動で通常適用される根拠収集手順は、2つのフェーズで構成されます。フェーズIでは問題を記述し、フェーズIIでは解決策の戦略を策定します。[ 1 ]

設計は、分割、分類／仕様設定、組み立て、シミュレーション、再分割という反復的な手順です（図参照）。まず、設計は設計成果物に分割されます。各成果物は、既存の設計成果物に基づいて分類されるか、外部仕様が作成されます。外部仕様により、設計成果物の内部仕様を委任し、同時に実行することが可能になります。分類／仕様設定後、組み立て作業において設計成果物間のインターフェースが指定されます（つまり、設計成果物間の相互作用のさまざまな側面を詳細化する静的、動的、および動作モデルが開発されます）。モデルの開発中は、設計成果物間の使用シナリオまたはユースケース[ 5 ]をシミュレートして設計上の欠陥を発見することが重要です。これらの欠陥を分析することで、設計者は既存のモデルを再編成し、満足のいく結果が得られるまでシミュレーションを行うことができます。観察された設計上の欠陥と、それぞれに対して検討および実施された措置が、設計根拠捕捉手順の基礎となります。[ 1 ]

問題を特定する

設計者は、要件モデルのユースケースを段階的に実行することで、現在の設計状態における問題点を特定し、設計が要件を満たしていることを検証し、設計が意図したとおりに機能することを検証します。設計者は、現在の設計状態に関する症状や懸念事項を記録します。症状とは、既存の設計における運用上の不具合や望ましくない状態の観察です。懸念事項とは、既存の設計において予期される不具合や望ましくない状態の観察です。[ 1 ]

制約を特定する

次に、設計者は問題が違反している、または違反する可能性のある制約を特定します。これらの制約には、要件、目標、物理法則、慣習、仮定、モデル、リソースが含まれます。ユースケースシナリオ内のアクティビティとプロセスは要件と目標にマッピングされるため、ユースケースのアクティビティまたはプロセスにおける設計の失敗は、要件ステートメントと目標ステートメントに直接起因します。[ 1 ]

ニーズを特定する

次に、設計者は問題を解決するための必要条件、つまりニーズを特定します。ニーズとは、特定の問題または一連の問題を解決するために満たされなければならない必要条件です。ニーズステートメントでは、設計を規定する要件と目標の制約を緩和することの重要性を記述する必要があるかもしれません。[ 1 ]

目標と要件を策定する

設計移行のニーズが特定されると、設計者は[ 1 ]を策定する。

  1. ソリューションが満たさなければならない要件と
  2. ソリューションが満たそうとする目標。

要件とは、ソリューションの機能、動作、物理的特性、または開発方法のいずれかの側面に対する制約です。設計目標とは、設計構造と仕様がサポートしなければならない明確な目的です。

解決戦略を策定する

要件と目標が確立されると、設計チームは設計の次の主要な移行における探索のための代替戦略を策定します。[ 1 ]

設計戦略は、頻繁に発生する設計状況に対処するための「メタプラン」と考えることができます。これは、上記で特定した基本的な設計活動（すなわち、分割、分類／仕様策定、組立、シミュレーション、再分割）を方法化または体系化したものと考えることができます。IDEF4の根拠要素で検討される3種類の設計戦略には、以下のものがあります。

  1. 外部制約駆動設計 — 目標、意図、要件が明確に定義されていない状況下で行われる設計。このような状況は、設計者が製品開発プロセスに早期に関与した場合によく発生します。
  2. 特性駆動設計 - 厳格な説明責任と適切性の証明が厳格に求められる、厳密に管理された状況下での設計。このような設計状況では、生命を脅かす可能性のある状況がしばしば発生します。
  3. キャリーオーバー主導設計 - 「ルーチン」設計と呼ばれることもあります。

要約すると、認知的な取り組みとしてのデザインは、計画や診断といった他の活動と多くの共通点を持つ。しかし、デザインは、それが実行される文脈、関連する一般的な活動、採用される戦略、そして適用される知識の種類によって区別される。大きな特徴は、デザインプロセスが最終製品の仕様の作成（洗練、分析など）に重点を置くことである。[ 1 ]

参考文献

  1. ^ a b c d e f g h i j k Richard J. Mayer (1995) 他「同時実行エンジニアリングのための情報統合（IICE）手法概要報告書」ライトパターソン空軍基地、オハイオ州 45433-7604。
  2. ^ Andrew P. Sage, William B. Rouse (2009).システム工学とマネジメントハンドブックJohn Wiley and Sons. ISBN 0-470-08353-0、427ページ。
  3. ^ a b IDEF6: 設計根拠捕捉法コンセプトペーパー概要。2009年7月17日にアクセス。
  4. ^ a b Richard J. Mayer、Patricia A. Griffith、Christopher P. Menzel (1990-91) 「IDEF6: 設計根拠捕捉法コンセプトペーパー」 2007年4月2日アーカイブ、Wayback Machine国防技術情報センター
  5. ^ Ivar Jacobson、M. Ericsson、A. Jacobson (1994).オブジェクト・アドバンテージ：オブジェクト技術によるビジネスプロセス・リエンジニアリング (ACM Press) . Addison-Wesley, ISBN 0-201-42289-1
ウィキメディア コモンズには、 IDEF6に関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=IDEF6&oldid=1322171778」より取得