设计定义 - IEEE 12207-2017 软件和系统工程标准系列-软件生命周期流程-技术过程

目的

设计定义过程 ¹的目的是提供有关系统及其元素的足够详细数据和信息，以使实施与系统架构模型和视图中定义的架构实体一致。

对于软件系统，设计活动通常与系统/软件需求定义和架构定义中的活动一起迭代。设计定义通常以迭代和增量的方式应用于开发详细设计，包括软件元素、接口、数据库和用户文档。软件设计通常与软件实施、集成、验证和确认同时进行。附件 H 讨论了使用敏捷方法的软件设计。在设计和实施过程 ²中，进一步的流程应用将细化软件元素之间不断发展的需求的分配。

注：设计定义过程由已通过架构审查和更详细的可行性分析的需求驱动。架构侧重于适用性、可行性和可取性，而设计侧重于技术和其他设计元素的兼容性以及实施和集成的可行性。有效的架构是设计可知论的，尽可能允许设计交易空间的最大灵活性。

注：此过程向软件系统架构提供反馈，以合并或确认架构实体的分配、分区和对齐。

结果

成功实施设计定义过程的结果是：

a)定义每个系统元素的设计特性。

• 2. 系统/软件需求分配给系统元素。

c)选择或定义设计定义所必需的设计推动因素。

d)定义或细化组成系统的系统元素之间的接口。

• 5. 评估系统元素的设计替代方案。
• 6. 设计成果得到开发。

g)设计定义所需的任何支持系统或服务均可用。

• 8. 建立了设计特性到系统架构的架构实体的可追溯性 ³。

注意设计定义考虑适用的技术及其对系统解决方案的贡献。设计提供了定义的“实施”级别，例如图纸、状态图、故事和详细的设计描述。对于软件元素，此过程可产生可根据需求和软件架构进行验证的详细设计描述。即使软件设计没有完全以正式描述指定，它也足够详细以允许软件实施（构建）和测试规划。

活动和任务

项目应根据组织关于设计定义过程的适用政策和程序实施以下活动和任务。

注：SWEBOK， 软件工程知识体系指南，提供了关于软件设计。这个知识领域涉及基础知识、关键问题、设计策略和方法以及设计符号。

a)准备软件系统设计定义。此活动包括以下任务：

1）定义设计定义策略，与所选的生命周期模型和预期的设计保持一致文物。

注：软件设计策略可以包括初始或逐步分解为系统元素；创建自动化程序、数据结构和控制系统的各种视图；选择设计模式，或逐步更详细地定义对象及其关系。

2）选择并确定设计原则和设计特征的优先顺序。

注：设计原则包括抽象、模块化和封装、接口和实现分离、并发性和数据持久性等控制思想。安全考虑包括最小特权原则、分层防御、限制对系统服务的访问，以及最小化和防御系统攻击面的其他考虑。设计特征包括可用性、容错和弹性、可扩展性、

可用性、容量和性能、可测试性、便携性和可负担性。

• 3. 识别并规划支持设计定义所需的必要支持系统或服务。

注：这包括识别支持系统的需求和接口。设计定义支持系统包括选择软件和系统平台、编程语言、设计符号和协作与设计开发工具、设计重用存储库（用于产品线、设计模式和设计工件）以及设计标准。

• 4. 获取或获得将要使用的支持系统或服务的访问权。

注：验证过程 ⁴用于客观确认支持系统是否实现了其支持的预期用途。

b)建立与每个软件系统元素相关的设计。此活动包括以下任务：

1）将建筑和设计特征转化为软件系统元素的设计。

注：特性适用于物理和逻辑系统元素，例如数据库结构、内存和存储规定、软件流程和控制、外部接口（例如用户界面）或服务。ISO9241‐

210提供以人为本的设计/人体工程学设计指南。

• 2. 定义、准备或获取必要的设计推动因素。

注：设计推动因素包括模型、方程式、算法、计算、参数的正式表达式和值、模式和启发式方法，它们与使用适当表示形式的设计特征相关，例如图纸、逻辑图、流程图、编码约定、逻辑模式、信息模型、业务规则、用户配置文件、场景、用例或用户故事 ⁵，以及指标及其值的表格（例如功能点或用户故事点）。

3）检查设计方案及实施的可行性。

注：对于软件系统和软件元素，通常会检查重用、适应、外包服务或新开发。

注：评估实现设计特性的可行性。如果评估结果证明有必要，当设计特性无法实现时，应检查其他替代设计选项，或在架构或要求中进行权衡。

4)细化或定义软件系统元素之间以及与外部实体的接口。

注：接口在架构定义过程 ⁶（见 6.4.4）中被识别和定义为架构意图和理解所需的级别或程度。这些接口在设计定义过程中根据设计特性、接口以及软件元素与组成软件系统的其他元素以及外部实体的交互进行细化。有时会识别和定义架构定义中未涉及的其他接口。

5)建立设计工件。

注意：此任务通过专用工件将软件系统元素的设计特征形式化，具体取决于实施技术。工件的示例包括原型、数据模型、伪代码、实体

关系图、用例、用户角色 ⁷和权限矩阵、接口规范、服务描述和

程序。设计工件被开发、获得或修改为选定的替代方案。数据与实施的详细可接受裕度相关联（如果与此处理器任务迭代相关）。

c)评估获取软件系统元素的替代方案。此活动包括以下任务：

• 1. 确定组成软件系统每个元素所需的技术。

注意：有时会使用多种技术来给定软件系统元素，例如互联网存在、嵌入式系统、开源软件的适应性、人类操作员角色。

2）确定软件系统元素的候选方案。

注：替代方案包括新设计和构建的项目；对现有产品线、组件、 对象或服务的改编；或获取或重新使用未开发项目 (NDI)。NDI 包括 COTS（商用现货）或FOSS（免费和开源软件）软件包或元素、重新使用以前的设计或现有资产，包括收购方提供的项目。

3）根据预期设计特征制定的标准评估每个候选方案，并元素要求来确定是否适合预期的应用。

注：自制或购买决策以及由此产生的实施和集成方法通常涉及设计标准的权衡，包括成本。设计选择通常考虑启用系统以测试候选替代方案（测试驱动设计和开发）和系统生命周期内的可持续性，包括维护成本。维护过程 ⁸可用于确定设计是否适合长期维护和可持续性。

• 4. 在软件系统元素的候选设计方案中选择可取的方案。

注意：系统分析过程 ⁹可用于分析和评估，以支持执行选择的决策管理过程。设计审查使用验证过程进行。

d)管理设计。此活动包括以下任务：

1）捕捉设计和原理。

注：通常捕获的信息包括软件系统元素和附属需求和设计数据，例如，软件元素、内部和外部接口、数据结构、实施和测试要求、集成的单元聚合数据和测试用例。基本原理通常包括有关主要实施选项和推动因素的信息。最终设计根据策略进行控制。

2）建立详细设计元素、系统/软件需求和软件系统架构的架构实体。

注：此任务有助于为架构定义过程提供反馈，以便进行潜在的修改，例如，修改软件系统元素的分配以获得预期的架构特性；或者可能由于设计过程中发现的因素而修改预期的架构特性，或者让利益相关者 ¹⁰意识到潜在的影响。

注：在整个生命周期中，设计和验证方法或技术以及软件系统元素需求之间保持双向可追溯性。将分配和设计属性指定给软件元素、软件单元和附属工件，其详细程度足以允许软件测试和实施，包括构造。

3）确定软件系统和元素设计的状态。

注：测量过程用于在设计过程中建立完整性和质量的测量标准。验证和确认过程 ¹¹用于验证和确认详细的设计和实施。

注：这包括对软件系统及其架构演变的设计特性进行定期评估，以及预测组件和技术的潜在过时性、它们在软件系统生命周期中随着时间的推移被其他组件和技术取代的可能性以及设计定义的影响。 风险管理流程通常用于评估设计策略、初始设计和演变设计中的风险。

• 4. 提供已选定的基线关键工件和信息项。

注意配置管理流程用于建立和维护设计模型等工件的配置项和基线。此流程确定基线的候选者，信息管理流程控制信息项，如设计描述和规范。