设计理由

基于决策的设计结构，它涵盖了工程设计，设计理由和决策分析的领域。

设计基本原理是设计系统或工件时做出决定背后的原因的明确文档。正如WR Kunz和Horst Rittel最初开发的那样，Design Arigation旨在为解决邪恶问题的政治，协作过程提供基于论证的结构。

概述

设计基本原理是对设计过程中做出的决策的明确列表，以及做出这些决定的原因。它的主要目标是通过提供记录和传达设计过程背后的论证和推理的方法来支持设计师。因此，它应该包括：

  • 设计决定背后的原因，
  • 理由，
  • 考虑了其他替代方案
  • 评估的交易折扣，以及
  • 导致决定的论点。

设计理由的研究涉及几个科学领域，例如计算机科学认知科学，人工智能和知识管理。为了支持设计基本原理，已经提出了各种框架，例如QOC，DRCS， IBIS和DRL。

历史

虽然可以追溯到1950年代基准，索赔，认股权证，背景和反驳的史蒂芬·图尔明（Stephen Toulmin ）的作品，但设计基本原理的起源可以追溯到WR Kunz和Horst Rittel对基于问题的信息的开发1970年的系统（IBIS）表示法。此后提出了宜必思的几种变体。

  • 第一个是问题的程序层次结构（PHI），尽管当时未命名，但在雷·麦考尔（Ray McCall）的博士学位论文中首次描述。
  • Potts＆Bruns在这种情况下也经过了宜必思的修改，以支持软件工程。然后通过决策表示语言（DRL）扩展了Potts＆Bruns方法。这本身是由Ratspeak扩展的。
  • 问题选项和标准（QOC），也称为设计空间分析是基于论点的基本原理的替代表示，Win-Win以及决策建议和意图模型（DRIM）也是如此。

第一个基本原理管理系统（RMS）是协议，该协议支持PHI，其次是其他基于PHI的系统Mikropolis和Phidias。提供IBIS支持的第一个系统是Hans Dehlinger的Stiec。 Rittel于1983年开发了一个小型系统（也没有出版），并于1987年开发了众所周知的Gibis （图形IBIS）。

并非所有成功的DR方法都涉及结构化论证。例如，卡罗尔（Carroll）和罗森（Rosson）的情景主张分析方法在描述系统的使用方式以及系统功能如何支持用户目标的方案中捕获了基本原理。 Carroll和Rosson的设计基本原理方法旨在帮助计算机软件和硬件的设计人员确定基本的设计权衡，并推断潜在的设计干预措施的影响。

设计基本原理的关键概念

有多种表征DR方法的方法。一些关键的区别特征是其捕获的方式，如何表示以及如何使用。

理由捕获

基本原理捕获是将理由信息获取到理由管理的过程

捕获方法
  • 一种称为“重建”的方法以原始形式（例如视频）捕获理由，然后将它们重建为更结构化的形式。重建方法的优点是可以仔细捕获理由，并且捕获过程不会破坏设计师。但是这种方法可能会导致产生理由的人的高成本和偏见
  • “记录和复制”方法只是在展开时捕获了理由。理由是在视频会议上同步捕获的，或通过公告板或基于电子邮件的讨论异步捕获的。如果系统具有非正式和半正式表示，则该方法将有所帮助。
  • “方法论副产品”方法在架构之后的设计过程中捕获了理由。但是很难设计这样的模式。这种方法的优点是其低成本。
  • 通过提前创建丰富的知识库（KB），“学徒”方法通过在混淆或不同意设计师的行动时提出问题来捕获理由。此方法不仅使用户，而且使系统受益。
  • 在“自动生成”方法中，设计理由是从执行历史记录以低成本自动生成的。它具有保持一致和最新的理由的能力。但是，由于某些机器学习问题的复杂性和困难，编译执行历史记录的成本很高。
  • “历史学家”方法让一个人或计算机程序观看所有设计师的行动，但没有提出建议。在设计过程中捕获了原理。

理由代表

设计拟议代表的选择对于确保我们捕获的理由是我们想要的，并且我们可以有效地使用。根据形式的程度，用于代表设计理由的方法可以分为三个主要类别：非正式，半身或正式。在非正式表示中，可以通过使用我们传统上接受的方法和媒体（例如文字处理器，音频和视频记录甚至手工著作）来记录和捕获理由。但是，这些描述使自动解释或其他基于计算机的支持变得困难。在正式的表示中，必须以严格的格式收集基本原理，以便计算机可以解释和理解理由。但是，由于正式表示形式定义的严格理由形式，人类几乎无法理解内容，并且捕获设计理由的过程将需要更多的努力才能完成，因此变得更加侵入性。

半身代表试图结合非正式和形式代表的优势。一方面，捕获的信息应能够通过计算机处理，以便可以提供更多基于计算机的支持。另一方面，用于捕获设计理由信息的过程和方法不应非常侵入性。在具有半明象表示的系统中，建议了预期的信息，用户可以按照说明填写根据某些模板填写属性，或者只是将其键入自然语言描述来捕获理由。

基于论证的模型

Toulmin模型
半合格设计理由表示的一种普遍接受的方法是将设计理由作为论点进行构建。许多设计基本原理系统使用的最早基于论证的模型是Toulmin模型。 Toulmin模型通过六个步骤定义了设计理由论证的规则：
  1. 提出索赔；
  2. 提供支持数据；
  3. 认股权证为现有关系提供了证据；
  4. 逮捕令可以得到支持；
  5. 提供了模型预选赛（有些，大多数等）；
  6. 还考虑了可能的反驳。
Toulmin模型的一个优点是，它使用大多数人可以轻松理解的单词和概念。
基于问题的信息系统（IBIS）
设计基本原理论证的另一个重要方法是Rittel和Kunz的IBIS（基于问题的信息系统），这实际上不是软件系统，而是论证符号。它是由GIBIS （图形IBI），ITIBI（基于测试的IBIS）， Compendium和其他软件以软件形式实施的。 ibis使用一些基本原理元素（称为节点），例如问题，立场，论点，决议和几种关系，例如比逻辑后继者，更典型的继任者，替代和类似的逻辑后继者链接问题讨论。
问题的程序层次结构（PHI）
phi（问题的程序层次结构）将宜必思扩展到了非构造问题，并重新定义了这种关系。 PHI添加了次发达关系，这意味着一个问题的解决方案取决于另一个问题的解决。
问题，选择和标准（QOC）
QOC（问题，选项和标准）用于设计空间分析。与宜必思性类似，QOC将关键设计问题确定为问题，并可能对问题作为选项的答案。此外，QOC使用标准明确描述评估选项的方法，例如要满足的要求或所需的属性。这些选项与标准呈正相关或负面关系，这些链接定义为评估。
决策表示语言（DRL）
DRL（决策表示语言）扩展了DR的POTTS和BRUNS模型，并将主要要素定义为决策问题，替代方案，目标，索赔和群体。 Lee（1991）认为DRL比其他语言更具表现力。 DRL更多地关注决策及其理由的代表，而不是设计基本原理。
Ratspeak
基于DRL，Ratspeak被开发并用作Seurat（使用Rationale的软件工程）中的表示语言。 Ratspeak考虑了要求（功能性和非功能性）作为决策问题的替代方案的一部分。 Seurat还包括一个参数本体，该论点是参数类型的层次结构，包括系统中使用的主张类型。
Winwin螺旋模型
Winwin螺旋模型在Winwin方法中使用，该模型添加了Winwin谈判活动，包括确定系统的关键利益相关者，并确定每个利益相关者和谈判的胜利条件，并将其识别为螺旋软件开发模型每个周期的前端为了实现该项目的所有利益相关者的相互满意（Winwin）协议。
在Winwin螺旋模型中，每个利益相关者的目标被定义为胜利条件。一旦胜利条件之间发生冲突，就会将其捕获为一个问题。然后，利益相关者发明选择并探索权衡解决问题的权衡。解决该问题时，一项满足利益相关者的胜利条件并捕获商定选择的协议。在Winwin模型的过程中，捕获了决策背后的设计基本原理，并将由利益相关者和设计师使用来改善其后来的决策。 Winwin螺旋模型通过为利益相关者提供一个明确的谈判过程来减少捕获设计理由的间接费用。定义了决策原理的本体，其模型利用本体来解决Winwin协作框架中支持决策维护的问题。
设计建议和意图模型（DRIM）
DRIM（设计建议和意图模型）用于共享Drim。 DRIM的主要结构是一项建议，由每个设计师的意图组成，这些建议满足了建议的意图和理由。当不同设计师的意图之间存在冲突时，还需要进行谈判。接受的建议将成为一个设计决定，并且在此过程中还记录了未接受但建议的建议的理由，在迭代设计和/或系统维护期间，这可能很有用。

申请

设计基本原理有可能以许多不同的方式使用。 Burge和Brown（1998）定义的一组用途是：

  • 设计验证 - 设计基本原理可用于验证设计决策和产品本身是否反映了设计师和用户实际想要的内容。
  • 设计评估 - 设计基本原理用于评估设计过程中讨论的各种设计替代方案。
  • 设计维护 - 设计基本原理有助于确定修改设计所需的更改。
  • 设计重用 - 设计基本原理用于确定如何使用或没有任何更改的新要求重复使用现有设计。如果需要修改设计，那么DR还建议设计中需要修改的内容。
  • 设计教学 - 设计基本原理可以用作教导不熟悉设计和系统的人们。
  • 设计沟通 - 设计的理由促进了参与设计过程的人们之间更好的沟通，因此有助于提出更好的设计。
  • 设计协助 - 设计基本原理可用于验证设计过程中做出的设计决策。
  • 设计文档 - 设计基本原理用于记录涉及会议室审议的整个设计过程，讨论的替代方案，设计决策背后的原因和产品概述。

DR在软件工程，机械设计，人工智能，土木工程和人类计算机互动研究中使用了DR。在软件工程中，它可用于在需求分析，捕获和记录设计会议的过程中支持设计师的想法，并通过新的设计方法预测可能的问题。在软件架构和外包解决方案设计中，它可以证明建筑决策的结果合理并作为设计指南。在土木工程中，它有助于协调设计师在建筑项目不同领域同时所做的各种工作。它还可以帮助设计师理解和尊重彼此的想法并解决任何可能的问题。

项目经理还可以使用DR来维护其项目计划和最新项目状态。此外，错过设计会议的项目团队成员可以将DR引用，以了解有关特定主题的讨论。在DR中捕获的未解决的问题可用于组织有关这些主题的进一步会议。

设计基本原理可以帮助设计师避免在上一个设计中犯同样的错误。这也有助于避免重复工作。在某些情况下，当软件系统从以前的版本中升级时，DR可以节省时间和金钱。

有几本书和文章提供了适用于HCI，工程设计和软件工程的理由方法的出色调查。

也可以看看