IDEF6

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

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

設計根拠は、明示的に記録された場合、通常は構造化されていないテキストコメントの形で存在します。要求に応じて関連情報を見つけることが困難、あるいは不可能であることに加えて、設計根拠の記録を整理し、完全性の基準を提供するための構造化された方法がないため、重要な情報が文書化される可能性は低くなります。設計が何であるか（設計仕様）を文書化するのに役立つ設計方法とは異なり、IDEF6 設計根拠記録方法は、次の情報を記録することを目的としている: ^[3]

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

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

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

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

IDEF6の適用範囲は、初期概念化から予備設計と詳細設計活動まで、情報システム開発プロセスのすべての段階をカバーしています。ソフトウェアシステムの詳細な設計決定がコーディング段階に委ねられている限り、IDEF6の手法はソフトウェア構築プロセスでも使用できるはずです。^[4]

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

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

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

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

• 設計の根拠の現象 : 設計の根拠の一般的な特徴は、「人間が設計上のコミットメントを行う (または正当化する) ため、およびそれらのコミットメントを広めるために使用する信念と事実、およびそれらの構成」と説明できます。
• 設計根拠の捕捉に関する問題 : 根拠が失われる理由の 1 つは、ソフトウェア成果物の仕様と成果物の完成の間に長い時間差があることです。また、明示的に捕捉された設計根拠を構成するものについての一般的な理解を深めることにも問題があります。つまり、設計根拠を表現する際の顕著な難しさは、概念自体が一様に理解されていないことです。これは、人工知能 (AI) 研究者が引き続き苦労している他のすべての形式の「説明」と共通する特徴です。

IDEF6では、根拠獲得手順には、分割、分類/仕様、アセンブリ、シミュレーション/実行、および再分割のアクティビティが含まれます。進化する設計のシミュレーション/実行アクティビティで通常適用される根拠獲得手順は、2つのフェーズを使用します。フェーズIでは問題を記述し、フェーズIIではソリューション戦略を開発します。^[1]

設計は、分割、分類/仕様、組み立て、シミュレーション、および再分割のアクティビティを含む反復的な手順です (図を参照)。まず、設計は設計成果物に分割されます。各成果物は、既存の設計成果物に対して分類されるか、外部仕様が開発されます。外部仕様により、設計成果物の内部仕様を委任して同時に実行できます。分類/仕様の後、設計成果物間のインターフェイスが組み立てアクティビティで指定されます (つまり、設計成果物間の相互作用のさまざまな側面を詳述する静的、動的、および動作モデルが開発されます)。モデルの開発中は、設計成果物間の使用シナリオまたは使用ケース^[5]をシミュレートして設計上の欠陥を発見することが重要です。これらの欠陥を分析することで、設計者は既存のモデルを再配置し、満足するまでシミュレーションを行うことができます。観察された設計上の欠陥と、それぞれに対して検討および実行されたアクションが、設計根拠キャプチャ手順の基礎となります。^[1]

問題を特定する

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

制約を特定する

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

ニーズを特定する

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

目標と要件を策定する

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

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

要件とは、ソリューションの機能、動作、物理、または開発方法の側面に対する制約です。設計目標とは、設計構造と仕様がサポートする必要がある明示された目的です。

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

設計戦略は、頻繁に発生する設計状況に対処するための「メタプラン」と考えることができます。これらは、上記で特定した基本的な設計活動 (つまり、分割、分類/仕様、アセンブリ、シミュレーション、および再分割) の方法化または組織化として見ることができます。IDEF4 の根拠コンポーネントで考慮される 3 種類の設計戦略には、次のものがあります。

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

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

ウィキメディア・コモンズには、 IDEF6に関連するメディアがあります。