歴史 議論の形式は、1950年代のスティーブン・トゥールミン の研究[ 7 ] ホルスト・リッテル [ 1 ] 問題ベース情報システム （IBIS）表記法に遡ることができます。それ以来、IBISのいくつかのバリエーションが提案されています。
1つ目は手続き的問題の階層（PHI）で、レイ・マッコール博士の博士論文[ 8 ] IBIS も、この場合はソフトウェア エンジニアリングをサポートするために Potts と Bruns によって修正されました。[ 9 ] [ 10 ] [ 5 ] 質問オプション基準（QOC）、別名デザイン空間分析[ 11 ] [ 12 ]は、Win-Win [ 13 ] [ 14 ] 最初の根拠管理システム (RMS) は PROTOCOL で、PHI をサポートしていました。その後、他の PHI ベースのシステムである MIKROPOLIS と PHIDIAS が登場しました。IBIS をサポートする最初のシステムは、Hans Dehlinger の STIEC でした。[ 15 ] gIBIS (グラフィカル IBIS) は 1987 年に開発されました。[ 16 ]
成功した設計根拠アプローチのすべてが構造化された議論を伴うわけではありません。たとえば、Carroll と Rosson のシナリオ主張分析アプローチ[ 17 ] [ 18 ]
設計理念における重要な概念 災害復旧（DR）のアプローチを特徴づける方法はいくつかあります。主な特徴としては、どのようにデータが取得されるか、どのように表現されるか、そしてどのように活用できるかなどが挙げられます。
根拠の把握 根拠の取得 とは、根拠情報を根拠管理のために取得するプロセスである。
キャプチャ方法 「再構築」 [ 4 ] [ 19 ] 「記録再生」[ 4 ] ビデオ会議で同期的に記録される場合もあれば、 掲示板 や電子メールによる議論を通じて非同期的に記録される場合もあります。システムに非公式かつ半公式的な表現がある場合、この方式は役立ちます。 「方法論的副産物」[ 4 ] 事前に作成された豊富な知識ベース（KB）を使用して、「見習い」[ 4 ] 「自動生成」[ 4 ] 「ヒストリアン」[ 20 ] [ 19 ]
根拠表現 設計根拠の表現方法の選択は、取得する根拠が望ましいものであり、効率的に使用できることを確実にするために非常に重要です。形式性の程度に応じて、設計根拠を表現するために使用されるアプローチは、非公式、半公式、公式の 3 つの主要なカテゴリに分類できます。[ 4 ]
半形式表現は、非形式表現と形式表現の利点を組み合わせようとするものです。一方では、取得された情報はコンピュータで処理できる必要があり、より多くのコンピュータベースのサポートを提供できるようになります。他方では、設計根拠の情報をキャプチャするために使用される手順と方法は、あまり侵入的であってはなりません。半形式表現のシステムでは、期待される情報が提案され、ユーザーは指示に従って、いくつかのテンプレートに従って属性を入力するか、自然言語の説明を入力することで根拠を取得できます。[ 4 ]
議論に基づくモデル トゥールミンモデル 半形式的な設計根拠表現の一般的な方法の 1 つは、設計根拠を議論として構造化することです。[ 5 ] [ 7 ] ミン モデルは 、設計根拠の議論のルールを 6 つのステップで定義しています。[ 21 ] 請求が行われた。 裏付けとなるデータが提供されています。 令状は既存の関係を裏付ける証拠を提供する。 保証は裏付けによって支えられることができる。 モデル修飾子（一部、多数、ほとんどなど）が提供されています。 反論の可能性も考慮される。 トゥールミンモデルの利点の1つは、ほとんどの人が容易に理解できる言葉や概念を使用している点です。 課題別情報システム（IBIS） 設計の根拠を論証するためのもう 1 つの重要なアプローチは、Rittel と Kunz の IBIS ( Issue-Based Information System ) [ 1 ] です。これは実際にはソフトウェア システムではなく、論証表記法です。gIBIS (グラフィカル IBIS)、itIBIS (テスト ベース IBIS)、Compendium などのソフトウェアでソフトウェア 形式で実装されています。 [ 22 ] [ 23 ] 手続き上の問題階層（PHI） PHI（手続き上の問題の階層）[ 24 ] 質問、選択肢、および基準（QOC） QOC（質問、選択肢、基準）[ 25 ] 決定表現言語（DRL） DRL (Decision Representation Language) [ 26 ]は、DR [ 9 ] [ 26 ] ラットスピーク DRLに基づいて、RATSpeakはSEURAT（Software Engineering Using RATionale）の表現言語として開発され使用されています。[ 27 ] ウィンウィンスパイラルモデル WinWinアプローチで使用されるWinWinスパイラルモデル[ 28 ] スパイラルソフトウェア開発モデル [ 29 ] WinWin スパイラル モデルでは、各ステークホルダーの目標は Win 条件として定義されます。Win 条件間で衝突が発生すると、それは問題として記録されます。次に、ステークホルダーはオプションを考案し、トレードオフを検討して問題を解決します。問題が解決されると、ステークホルダーの Win 条件を満たし、合意されたオプションを記録する合意が成立します。WinWin モデルのプロセス中に、決定の背後にある設計の根拠が記録され、ステークホルダーと設計者が後の意思決定を改善するために使用されます。[ 28 ] [ 30 ] 設計推奨および意図モデル（DRIM） DRIM（設計推奨および意図モデル）はSHARED-DRIMで使用されています。[ 14 ]
アプリケーション 設計の根拠は、さまざまな方法で活用される可能性を秘めている。バージとブラウン（1998）[ 19 ]
設計検証 ― 設計の根拠を用いることで、設計上の決定事項や製品自体が、設計者やユーザーが実際に望んでいたものを反映しているかどうかを検証できる。 設計評価 ― 設計の根拠は、設計プロセス中に議論された様々な設計案を評価するために用いられる。 設計の保守 ― 設計の根拠は、設計を変更するために必要な変更点を決定するのに役立ちます。 設計の再利用 ― 設計の根拠は、既存の設計を、変更の有無にかかわらず、新しい要件にどのように再利用できるかを判断するために使用されます。設計の変更が必要な場合は、設計のどの部分を変更する必要があるかも提案されます。 デザイン教育 ― デザインの根拠は、デザインやシステムに不慣れな人々に教えるための教材として活用できる。 デザインコミュニケーション ― デザインの根拠を明確にすることで、デザインプロセスに関わる人々の間のコミュニケーションが円滑になり、より良いデザインを生み出すのに役立ちます。 設計支援 ― 設計の根拠は、設計プロセス中に下された設計上の決定を検証するために使用できる。 設計ドキュメント — 設計の根拠は、会議室での審議、検討された代替案、設計決定の理由、製品概要など、設計プロセス全体を文書化するために使用されます。 DR は、ソフトウェア エンジニアリング、機械設計、人工知能、土木工学、ヒューマン コンピュータ インタラクション研究などの研究コミュニティで使用されています。ソフトウェア エンジニアリングでは、要件分析中に設計者のアイデアをサポートしたり、設計会議を記録して文書化したり、新しい設計アプローチによる潜在的な問題を予測したりするために使用できます。[ 31 ] ソフトウェア アーキテクチャ とアウトソーシング ソリューション設計では、アーキテクチャ上の決定 の結果を正当化し、設計ガイドとして機能します。[ 32 ] [ 33 ]
DRは、プロジェクトマネージャーがプロジェクト計画とプロジェクトのステータスを最新の状態に保つためにも使用できます。また、設計会議を欠席したプロジェクトチームメンバーは、DRを参照して特定のトピックについて何が議論されたかを確認できます。DRに記録された未解決の問題は、それらのトピックに関するさらなる会議を組織するために使用できます。[ 31 ]
設計の根拠は、設計者が以前の設計で犯したのと同じ間違いを避けるのに役立ちます。これは、作業の重複を避けるのにも役立ちます。[ 5 ] [ 2 ]
HCI [ 34 ] [ 4 ] [ 35 ]
参考文献 1 2 3 Kunz, W.; Rittel, H. (1970), Issues as elements of information systems . Working Paper 131, Center for Urban and Regional Development, University of California Berkeley 1 2 3 Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "ソフトウェアエンジニアリングの設計根拠：概説",第25回ハワイ国際システム科学会議 、2、pp. 577-586 1 2 Horner, J.; Atwood, ME (2006)、「効果的な設計根拠：障壁の理解」、Dutoit, AH; McCall, R.; Mistrík, I. 他編『ソフトウェアエンジニアリングにおける根拠管理』、Springer Berlin Heidelberg、pp. 73-90 1 2 3 4 5 6 7 8 9 Lee, J. (1997). "設計根拠システム：問題点の理解". IEEE Expert 12 (3): 78–85 1 2 3 4 Burge, JE; Brown, DC (2000)、「設計の根拠に基づく推論」、Gero, J.編『 Artificial Intelligence in Design '00』 、オランダ：Kluwer Academic Publ.、pp. 611–629 ↑ Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory", Systems, Man and Cybernetics , pp. 1904 - 1908. 1 2 スティーブン・トゥールミン （1958）。議論の用途 。ケンブリッジ：ケンブリッジ大学出版局。↑ McCall, R. (1978), On the structure and use of issue systems in design , 博士論文、カリフォルニア大学バークレー校、University Microfilms 1 2 Potts, C.; Burns, G. (1988)、「設計決定の理由の記録」、第10回国際ソフトウェア工学会議 （ICSE '1988）、pp. 418-427 ↑ Lee, J. (1991), "設計根拠を記録するためのポッツとブランズのモデルの拡張",第13回国際ソフトウェア工学会議（ICSE '13）議事録 、IEEE Computer Society Press、カリフォルニア州ロスアラミトス、pp. 114-125 ↑ Maclean, A.; Young, RM.; Moran, T. (1989), "設計の根拠：成果物の背後にある議論", SIGCHI Bull . 20, pp. 247-252114-125 ↑ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996)、「質問、選択肢、基準：設計空間分析の要素」、Moran, T.; Carroll, J.編『設計の根拠の概念、技法、および使用法』、Lawrence Erlbaum Associates 、pp. 53-106 ↑ Barry Boehm 、Ross、R (1989)。「Theory-W ソフトウェアプロジェクト管理：原則と例」。IEEE Transactions on Software Engineering 18 (7): 902-916。1 2 Pena-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design Recommendation-Intent Management System", Proceedings Enabling Technologies Infrastructure for Collaborative Enterprise , IEEE Press, Morgantown, WV, pp. 213-221 ↑ デリンガー、H. (1978)、「プロジェクト STIEC: 欧州共同体における科学技術情報の生成と普及のシステム分析」報告書 No. 26: STIEC のバッチ版に関する報告書 、ハイデルベルク/シュトゥットガルト ↑ Conklin, J.; YakemBegemanovic, M. (1988). "gIBIS: 探索的政策議論のためのハイパーテキストツール". ACM Transactions on Office Information Systems 6 (4): 303-331. ↑ Carroll, JM; Rosson, M (1992). 「タスク・アーティファクト・サイクルを回避する：シナリオによる主張と設計の方法」 ACM Trans. Inf. Syst . 10 (2): 181-212 ↑ Carroll, JM、& Rosson, MB (2003). 設計の根拠を理論として。HCIモデル、理論、フレームワーク：学際的な科学に向けて、431-461。 1 2 3 Burge, J.; Brown, DC (1998), Design Rationale: Types and Tools, Technical Report , Worcester Polytechnic Institute, Computer Science Dept. , 2007年4月27日取得 ↑ Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "デザイン履歴知識表現とその基本的なコンピュータ実装", 第2回デザイン理論と方法論に関する国際会議、イリノイ州シカゴ、pp. 175-185 ↑ Reynolds, Chris (2000), What is the Toulmin Model? Archived 2007-08-25 at the Wayback Machine ↑ Conklin, J.; Yakemovic, K. (1991). "設計根拠へのプロセス指向アプローチ". Human-Computer Interaction 6 (3 & 4): 357–391. ↑ Rittel, Horst WJ ; Noble, Douglas (1989 年 1 月).設計のための課題ベース情報システム (PDF) (技術報告書). カリフォルニア州バークレー: カリフォルニア大学 都市地域開発研究所. OCLC 20155825. 492. ↑ McCall, RJ (1991). "PHI: デザインハイパーメディアの概念的基盤". Design Studies 12 (1): 30–41. ↑ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996)、「質問、選択肢、基準：設計空間分析の要素」、Moran, T.; Carroll, J.編『設計の根拠：概念、技法、および活用』 、Lawrence Erlbaum Associates、pp. 53-106 1 2 Lee, J. (1991), "設計根拠を記録するためのポッツとブランズのモデルの拡張",第13回国際ソフトウェア工学会議 （ICSE '13）議事録、IEEE Computer Society Press、カリフォルニア州ロスアラミトス、pp. 114-125 ↑ Burge, J. (2005), Software Engineering Using design RATionale , Worcester Polytechnic Institute, Computer Science Dept. 1 2 Barry Boehm ; Kitapci, H. (2006)、「WinWinアプローチ：要件交渉ツールを用いた根拠の収集と利用」、Dutoit, AH; McCall, R.; Mistrík, I. 他編『ソフトウェアエンジニアリングにおける根拠管理』 、Springer Berlin Heidelberg、pp. 173-190↑ バリー・ボーム （1998）。「ソフトウェア開発と機能強化の螺旋モデル」。Computer 21 （5）：61–72↑ Bose, P. (1995). 「WinWinコラボレーションフレームワークにおける意思決定維持のためのモデル」.知識ベースソフトウェアエンジニアリング （KBSE '95）. 1 2 Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Rationale Management in Software Engineering , Springer pp.1-48. ↑ O. Zimmermann、C. Miksovic、J. Küster、「情報技術サービスにおけるアーキテクチャ知識管理のための参照アーキテクチャ、メタモデル、およびモデリング原則」、Journal of Systems and Software、Elsevier、第85巻、第9号、2012年9月 ↑ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Application Of Design Rationale Systems To Project Definition – Establishing A Research Project . Archived 2007-09-28 at the Wayback Machine ↑ Moran, T.; Carroll, J. 編 (1996), Design Rationale Concepts, Techniques, and Use , Lawrence Erlbaum Associates, ↑ デュトワ著「ソフトウェアエンジニアリングにおける理論的根拠管理」
さらに読む 本 ジョージア州バージ。キャロル、JM。マッコールR;ミストリーク 1 世 (2008)。理論に基づいたソフトウェア エンジニアリング 。ハイデルベルク: Springer-Verlag。 デュトワ、ああ、マッコールR;ミストリク 1 世。ペーチ B (2006)。ソフトウェアエンジニアリングにおける論理的管理 。ハイデルベルク: Springer-Verlag。 コンクリン、J (2005)。ダイアログ マッピング 。ワインハイム: Wiley-VCH Verlag。 Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Visualizing Argumentation: Software Tools for Collaborative and Educational Sense-Making . London: Springer-Verlag. Moran, T; Carroll J (1996).設計の根拠：概念、技術、および使用法 。ニュージャージー州：Lawrence Erlbaum Associates。 特集号 人工知能によるエンジニアリング設計、解析、製造（AIEDAM）、特別号：2008年秋、第22巻第4号、設計根拠http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html 人工知能によるエンジニアリング設計、解析、製造（AIEDAM）、設計根拠の表現と利用に関する特集号、1997年、第11巻第2号、ケンブリッジ大学出版局 ワークショップ 第2回アーキテクチャ知識の共有と再利用に関するワークショップ - アーキテクチャ、根拠、設計意図（SHARK/ADI 2007）（RC.rug.nl）は、第29回国際ソフトウェア工学会議（ICSE 2007）（CS.ucl.ac.uk）の一部として開催されました。 設計理念に関するワークショップ：問題点と進捗状況（Muohio.edu） ワークショップ議長：ジャネット・バージ、ロブ・ブレイスウェル。2006年7月9日、デザイン、コンピューティング、認知'06と併催。アイントホーフェン（wwwfaculty.arch.usyd.edu.au）、オランダ
外部リンク Bcisive.austhink.com：設計根拠およびより広範な意思決定根拠を分析するために設計された商用ソフトウェアパッケージ。グラフィカルインターフェース、共有機能付き。 Compendium：IBISをベースとしたビジュアル知識管理機能を提供するハイパーメディアツール。無料のJavaアプリケーションで、バイナリとソースコードが提供され、活発なユーザーコミュニティが毎年会合を開いています。 designVUE：IBISなどの手法に基づいた、視覚的な知識獲得のためのツール。無料のJavaアプリケーション。 SEURAT：ソフトウェア開発環境に論理的根拠のキャプチャと使用を統合するEclipseプラグイン。SEURATはGitHubでオープンソースプロジェクトとして入手可能です（)
