1 目的
架构定义过程 1的目的是生成系统架构替代方案，选择一个或多个能够体现利益相关者关注点并满足系统要求的替代方案，并将其表达为一组一致的观点。
通常会使用架构定义过程与业务或任务分析过程、系统 / 软件需求定义过程、设计定义过程以及利益相关者需求和要求定义过程 2进行迭代，以便对需要解决的问题达成协商理解并确定令人满意的解决方案。架构定义过程的结果在整个生命周期过程中得到广泛使用。架构定义可以应用于抽象的许多级别，突出显示该级别决策所需的相关细节。
息，请参阅 系统架构涉及基本原理、概念、属性和特点以及它们如何融入感兴趣的系统。架构定义有更多用途，而不仅仅是设计的驱动因素或一部分。有关架构描述以及架构的用途和性质的更多信ISO/IEC/IEEE42010:2011。
注：架构定义过程支持对利益相关者 3及其关注点的识别。随着过程的展开，可以深入了解软件系统的特定要求与系统元素之间的交互和关系所产生的新出现的特性和行为之间的关系。有效的架构是设计不可知的，尽可能允许设计交易空间的最大灵活性。即使对于单一产品软件系统，产品的设计也可能会随着时间的推移而改变，而架构保持不变。
有效的架构还强调并支持设计定义流程和可能的其他流程（例如项目组合管理、项目规划、系统/软件需求定义和验证）的权衡。
注：架构定义可适用于产品线，而不是单个软件系统。产品线架构描述了构建一组具有通用组件和相互关系的相关系统的结构属性。在产品线架构中，架构必然跨越几种设计。架构用于使产品线具有凝聚力，并有助于确保整个产品线的兼容性和互操作性。ISO/IEC26550:2013 描述了为产品线建立域架构。
注：SWEBOK （软件工程知识体系指南）的软件需求、软件设计和软件工程模型和方法知识领域讨论了软件架构与系统关系的关键方面，以及与设计迭代相关的关键方面。
2 结果
成功实施架构定义过程的结果是：
- 已识别的利益相关者关注的问题已通过架构得到解决。
- 架构观点已得到发展。
- 定义系统的背景、 边界和外部接口。
- 开发系统的架构视图和模型。
- 对⋯有重要意义的概念、 性质、特征、行为、功能或约束系统的架构决策分配给架构实体。
- 识别系统元素及其接口。
- 对建筑专业候选人进行评估。
- 实现了整个生命周期中流程的架构基础。
- 架构与需求和设计特征实现一致。
- 架构定义所需的任何支持系统或服务均可用。
- 开发了架构元素到利益相关者和系统/软件需求的
可追溯性4。
- 开发了架构元素到利益相关者和系统/软件需求的
3 活动和任务
项目应根据与架构定义过程相关的适用组织政策和程序实施以下活动和任务。
a)准备架构定义。此活动包括以下任务：
- 审查相关信息并确定架构的关键驱动因素。
注：关键驱动因素通过审查以下内容确定： （a）市场研究、行业预测、竞争对手产品计划和科学发现； （b）组织战略 5、 组织级运营概念、组织政策和指令、 监管和法律约束以及利益相关者要求；（c）使命或业务运营概念、 利益系统和相关系统运营概念、运营环境、技术路线图和系统/软件要求，以及（d） 影响软件系统在其生命周期内适用性的其他因素。对关键驱动因素的分析通常基于业务或使命分析、 利益相关者需求定义和系统/软件需求定义过程。
注：架构的关键驱动因素包括架构风格和模式、元素、原则（例如可替换组件）、实施和集成的可行性；COTS 和开源组件的可用性；数据密集型系统的数据源；以及性能影响。如果软件系统架构合理，选择各种设计元素的影响可以减轻。
2）识别利益相关者的关注点。
注：利益相关者最初在利益相关者需求和要求过程中确定。其他利益相关者通常在架构定义过程中确定。 利益相关者对架构的关注包括系统完整性的关注，即软件系统是否会因威胁代理而有意或无意地受到损害，或导致事故，从而造成安全隐患。利益相关者的期望或约束通常与系统的生命周期阶段 6有关，例如利用率（例如可用性、安全性、有效性、可用性、与现有系统的互操作性、系统中数据的可用性或风险）、支持（例如，系统对软件的支持能力）、
系统在其预计的生命周期内的生命周期、淘汰管理）、软件系统及其环境的演变（例如，适应性、可扩展性、生存性）、生产（例如，分发、可测试性）和退役（例如，敏感数据的消除或保留）。
注：影响软件系统架构的因素包括数据源和数据性能影响密集型系统，以及对外包、现有、新开发、专有、商业可用或开源软件元素的使用的限制，包括软件许可。虽然软件架构在理想情况下是设计
不可知论者认为，在可负担的软件系统中实现该架构的可行性对于大多数系统来说是一个重大的制约因素。
3）定义架构定义路线图、方法和策略。
注：这包括确定与指定利益相关者沟通的机会、定义架构审查活动、评估方法和标准、测量方法和测量方法（参考测量过程）。路线图显示架构将演变为预想的最终状态，并且通常比当前感兴趣的系统具有更长的时间范围。方法是完成工作的方式，例如如何与利益相关者接触、如何审查结果或在哪里开展工作。策略涉及与路线图一致地实施方法的系统行动计划。
4）根据利益相关者的关注点和关键要求定义架构评估标准。
5）识别并规划支持架构所需的必要支持系统或服务定义过程。
注：这包括识别支持系统和服务的需求和接口。用于架构定义的支持系统可以包括用于协作和架构开发的工具，以及用于诸如架构模式、模型和参考架构等工件的架构重用存储库。
- 获取或获得将要使用的支持系统或服务的访问权。
注：验证过程 7用于客观确认支持系统是否实现了其预期用途和功能。基础设施管理过程支持支持系统的重复使用。
b)开发架构观点。此活动包括以下任务：
1）根据利益相关者的关注点选择、调整或发展观点和模型类型。
- 建立或确定用于开发模型和视图的潜在架构框架。
注意：一些架构框架会确定利益相关者及其关注点，以及解决这些问题的相关观点，而其他架构框架则具有更广泛的指导意义。 观点指定了要使用的模型类型以及如何使用生成的模型来生成架构视图。有关架构框架和架构描述实践的更多信息，请参阅 ISO/IEC/IEEE42010。
3）获取选择框架、观点和模型类型的依据。
4）选择或开发支持建模技术和工具。
注意 SWEBOK 和 ISO/IECTR24748‑3 都描述了支持软件元素的架构定义和设计定义的建模技术。
c)开发候选架构的模型和视图。此活动包括以下任务：
1）定义软件系统与外部接口和交互的上下文和边界實體。
注：此任务主要基于业务或任务分析过程的结果，并与利益相关者需求 8和要求定义过程同时执行。它包括识别软件系统外部的实体（即构成系统上下文的现有和项目系统、产品和服务）以及定义软件系统的边界（即通过跨越边界的接口与这些外部实体的交互）。外部实体包括必要的支持系统。架构定义过程将接口定义为支持基本架构决策和理解所需的程度。
这些接口定义随后通过设计定义过程 9进行细化。
- 识别解决关键利益相关者关注点和关键软件系统要求的架构实体以及实体之间的关系。
注意：架构并不一定涉及所有需求，而只涉及那些驱动架构的系统 / 软件需求。另一方面，设计定义过程处理并考虑所有需求。有时，通过架构定义过程，会有一些需求被认为不适当、无法承受或不合适。这些需求问题可通过系统 / 软件需求定义过程的迭代得到解决。架构处理关键利益相关者关注的问题也很重要，因为并非所有这些问题都会在需求中得到捕获。
3）分配对以下方面重要的概念、属性、特征、行为、功能或约束：软件系统对架构实体的架构决策。
注意分配的项目可以是物理的、逻辑的或概念的。
4)选择、调整或开发软件系统的候选架构模型。
注：在架构定义中通常使用模型。所使用的模型最能解决关键利益相关者的关注问题。 有关如何实现这一点，请参阅 ISO/IEC/IEEE42010。从历史上看，在架构定义中通常使用逻辑模型和物理模型。附件 F 中提供了有关逻辑模型和其他模型的信息。
5）根据确定的观点从模型中整理观点，表达架构如何解决利益相关者的关注并满足利益相关者和系统/软件的要求。
6）协调建筑模型和视图。
注：框架的对应规则是建立观点间和谐的一种方式。请参阅 ISO/IEC/IEEE42010。
d)将架构与设计联系起来。此活动包括以下任务：
1）识别与架构实体相关的软件系统元素及其性质关系。
注意：有时软件系统元素最初都是概念性的，直到设计定义出现，因为这取决于要完成的实际设计。有时会使用这些概念性的系统元素创建“参考架构”，作为传达架构意图和检查设计可行性的相同手段。
2）定义软件系统元素和外部实体之间的接口和交互。
注意：这是在传达建筑意图所需的详细程度上定义的，并且可以在设计定义过程中进一步细化。
3）对架构实体和系统元素进行划分、对⻬和分配需求。
- 将软件系统元素和架构实体映射到设计特征。
- 定义软件系统设计和演进的原则。
例如，原则可以包括互操作性、所选设计模式的使用、系统元素的替换和升级的简易性、或安全级别。
e)评估架构候选人。此活动包括以下任务：
1）根据约束和要求评估每个候选架构。
2）根据评估标准评估每个候选架构是否符合利益相关者的关注点。
注意：系统分析过程 10和风险管理过程可用于支持此任务。
- 选择首选架构并捕获关键决策和理由。
注意：决策管理流程可用于支持此任务。
- 建立所选架构的架构基线。
注意：架构基线由模型、视图和其他相关的架构描述组成。
f)管理选定的架构。此活动包括以下任务：
1）正式化架构治理方法，并明确与设计、质量、安全和安全相关的治理相关角色 11和职责、责任和权限。
2）获得利益相关者对架构的明确接受。
注意：验证过程用于确认架构模型和视图反映了利益相关者的要求，利益相关者的关注点得到解决，并帮助确保软件系统架构的未来迭代能够更好地解决利益相关者的关注点。
3）保持建筑实体及其建筑结构的一致性和完整性特征。
注意：要检查的实体不仅是技术实体，还包括法律、经济、组织和操作实体，这些实体通常是利益相关者的要求和关注的一部分。
4）组织、评估和控制架构模型和视图的演变，以帮助确保架构意图、架构愿景和关键概念得到正确实施。
5）维护架构定义和评估策略。
注：这包括根据技术（例如过时）、实施或操作经验更新架构。这包括在软件系统分解的这一级别定义的外部和内部接口的管理。
6）保持架构的可追溯性。
注：在整个生命周期中，通常在架构实体或元素（模型、视图和视点）、需求（包括分配、分解和派生）和利益相关者关注点、软件系统设计、接口定义、分析结果和验证方法或技术之间保持可追溯性。
- 提供已选定的基线关键工件和信息项。
注意配置管理流程用于建立和维护配置项和基线。此流程确定基线的候选者。信息管理流程控制信息项，例如架构描述（架构模型、架构视图、评估和可追溯性）。