软件设计过程
软件设计过程
任何软件都有其创建历史、创建者及其背后的实际需求。在过程的意义上，软件创作更被公众认可为“软件设计”或“软件设计过程”。软件设计师被公认为软件架构师、软件工程师等。几十年来，软件架构师设法在全世界构建了数百万个软件。结果，有很多关于软件设计中好的和坏的实践的信息。
然而，任何实践，无论好坏，都是从设计过程中构建的。对于正确的软件设计，任何设计师都需要一个正式的过程来组织设计软件。以下内容将深入探讨软件设计过程和总体设计过程。
什么是设计本身？
首先，要了解必须如何定义和形式化设计过程，必须确定设计意味着什么。牛津英语词典将动词设计定义为：
形成计划或方案，安排或构思。 . .
供以后执行。
设计通常意味着将设计师的想法形成并构建到材料中，这是他心中的想法。此外，物化过程可以被认为是设计的，当它可以执行时。定义有很多抽象，允许在不同的设计领域进行相同的定义投影。从这个意义上说，各种各样的设计师：软件设计师、建筑设计师、流程设计师等，都有很多共同点，最后，还有一些可以共享的通用知识。
这些设计师有一些共同的标准工具：
- 设计文档——每个设计过程都必须写下来，以更具体地针对最终的可执行文件（可交付，无论是软件、桥梁、医院）
- 用户研究——任何设计输出都有其用户受众。只有满足用户需求甚至更多需求，交付物才能被认为是“精心设计的”。
- 环境研究——需要正确研究可交付成果的执行环境。
考虑到软件设计过程有一个简明的历史（约 80 年），有必要看看其他具有更长评估过程的设计领域。设计过程从一开始就被触及 维特鲁威（古罗马建筑师） ~BCE 20。所有书籍的主要成果是与未来的设计师分享设计经验。可悲的是，任何设计师都可以构建最少数量的最终可交付成果，这为从他人的经验、失败和设计中学习打开了大门。
根据不同的作者，有许多设计过程分离。以下是如何将设计过程非正式地分成几个阶段的一个示例：
- 概念结构的制定——任何设计师都牢记可交付成果的概念。
- 在真实媒体中实施——之后，设计师开始将概念实施到材料中。
- 在实际使用中与用户交互——设计的最后阶段是实际交付。当设计理念面对真实用户时
设计种类
设计领域本身可以分为两部分：
- 系统设计——设计复杂的结构（建筑物、编译器等）
- 艺术设计——更多地为印象和意义设计结构（排字师、画家等）
在很多情况下，现有的设计研究和设计手册可以在不改变设计而是通过适应的情况下进行调整以满足新的需求。
著名设计模型
合理的设计模型
• 目标——任何设计都服务于一个主要目标。目标可以用一句话“构建一个可在任何关系数据上运行的软件”组成。
• Desiderata — 最终的可交付成果必须符合不同的要求。 “无论数据大小，软件必须快速”，“必须自动找到数据关系”等。
• 效用函数——效用函数始终是需求者的“敌人”。效用函数是系统需要高度关注和优化的可交付成果的主要功能部分。在大多数情况下，对需求的任何添加都会增加此功能的复杂性。最后一个使优化变得更加困难
• 约束——任何设计都包括特定的合同。例如，无论数据大小如何，都希望效用函数快速执行，这将对关系计数带来一定的限制。从这个意义上说，在某些情况下，约束及其相互联系可能会成为一个真正令人头疼的问题
• 资源分配、预算和关键预算——任何设计都有其有限的资源。大多数时候，典型的限制是时间、金钱、软件 CPU/GPU 等。识别设计中最关键的资源至关重要，因为它是所有需求的限制边界。效用函数是对设计中最关键的预算资源提供指导的函数
• 决策设计树——从设计已经设定目标开始，找到需求点，选择约束条件和资源可能分配，设计需要开始设计效用函数。这个过程总是像解决一个又一个问题一样，所以最终会形成一个树结构，其中每个树节点都是对特定问题的决策。当深入研究设计树时，设计师应该认识到之前的每一个决定都是下一个决定的基础， 所以越深入，就越难改变决策树 .通过设计树可以找到所有的需求及其解决方案。因此，人们可以测试所有做出的决定的效用函数。
模型有什么问题
不幸的是，理性模型在大多数情况下都不起作用（一些作者认为它根本不起作用）。以下是理性模型的主要原因和目标：
- 从起点看不到目标—— 设计中最具挑战性的部分是决定设计什么。 如前所述，设计过程是用户和设计师之间无声的、非语言的对话，这使得对话必须继续进行变得困难。大多数时候，客户对他想要从设计中得到什么没有想象。 设计师的主要服务是帮助客户发现他们想要设计的东西。
- 效用函数不能在一开始就被测量——在交付物准备好之前，很难评估效用函数。例如，如果没有用户系统、系统实现的确切细节，就无法充分衡量数据操作的性能（决策树中的任何解决方案都可能对效用函数性能产生巨大影响）
- 需求和约束不断变化——每个设计决策都会改变可交付成果的当前状态。随着情况的变化，会出现新的约束或现有约束的一些变化。这些约束会影响需求，这可能会改变它们的优先级，甚至超出设计范围。例如，当效用函数开始处理超过 1TB 的数据时，可能的关系计数会减少一个数量级。更糟糕的是，自动关系检测机制已经减少了五个数量级，从而使这种需求超出了设计范围。相反，有新的需求让最终用户提供关系。
- 设计树很难发现——由于在自然设计过程中约束和需求变化很大，所以一开始基本上不可能发现设计树。相反，可以在设计过程中不断发现设计树。
替代模型
- 共同进化模型——该模型描述了更具交互性的决策树。在此期间正在评估设计的最终目标和该目标的解决方案（决策树）。每个新的解决方案都会带来对最终目标的新理解。因此，需求正在发生变化。根据这一变化，设计者试图调整效用函数和决策树。这些过程可能永远到期，因为没有理想的设计，总是有改进的大门。该模型没有特定的截止日期，但更像是一个研发过程。
- Raymond's Bazaar 模型（开源）— 2001 年，埃里克·雷蒙德 写了一篇关于开源设计过程的文章。作者将开源设计过程描述为所有设计问题的解决方案。主要思想是一些设计师选择一个共同的问题，解决它，并为设计师社区提供解决方案。其他设计师可以自由使用和调整解决方案。任何设计者都可以改进实用功能（例如，修复错误）。至于社区正在使用设计解决方案并为一些日常斗争提供解决方案，社区模型正在评估是有效的并且可以完美运行。但是，并不是所有的问题都可以预料到，也不是所有的解决方案都可以因为保密而开源。
- Boehm 的螺旋模型 — 1998 年，Barry Bohem 提出设计过程 Spiral Model .该过程是关于循环进行设计过程：制作原型解决方案，设计效用函数，在用户和可交付成果之间进行测试，并重复此过程直到最终的预期结果。该模型被/被社区高度接受，是理性模型的合适替代品。对该模型的主要批评是，它更像是对可交付成果的改进，而不是对用户体验的改进。该模型的预期下一步是用户收集的反馈以及基于该反馈的可交付成果调整。
技术设计中的美学（什么是逻辑美？）
在谈到物理设计交付物时，自然会讨论交付物的形式、美学和美感（例如，汽车）。然而，软件设计人员一直在谈论编程语言或解决方案的优雅。这些描述不是物理的，而是指向一些逻辑结构。描述优雅的逻辑结构有一些属性：
- 简约 - 当问题有多个解决方案时（即使没有），数学中没有书面规则，最好有一个使用更少元素的解决方案。 在系统中，尽可能多地制造，而不是尽可能多地制造是必不可少的。
- 结构清晰 — 如果有一种直接的方法可以实现您的目标，该系统也被认为是好的。
- 一致性 — 系统的细节和内部概念必须一致。三个不同的属性可以描述一致性概念：
- 正交性——如果系统组件可以保持独立，那就必须如此。因此，对系统的一个部分进行更改将不需要将来对其他部分进行更改。
- 属性——系统或系统组件总是具有描述该组件的属性，拥有它们是很自然的。在大多数软件中，不同的属性不是该系统组件描述的一部分，但由于环境或互补的系统组件，它们本质上是必然的。系统必须尽量避免添加此类额外属性。
- 通用性——如果可以保持更高的抽象标准，系统必须这样做。例如，如果可能，要编写一个可以计算任何给定多边形的函数的函数，系统不能将自身限制为仅计算三角形。
设计师的研究
如果任何设计师想弄清楚他所编写的设计过程定义是什么，他最好从以下四个步骤开始：
- 理想设计过程的规定——必须以书面形式拥有设计过程理念的理想形式。过程是最顶层的抽象，只有能写下来，才有可能形式化。
- 描述设计问题的内在本质——设计者需要理解和定义设计的问题领域。设计过程是设计师和最终用户之间的非语言对话方式，因此有很多问题需要坚持。
- 观察设计活动的现实——设计过程必须不断发展。对可交付成果的观察为问题领域传播了新的曙光，并为改进打开了一扇门。
- 对设计基本概念的反思——在第 2 点和第 3 点中“找到”的过程必须反映第 1 点的理想过程。
参考文献：
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
