软件架构开发与架构师的多角色参与

### 软件架构开发与架构师的多角色参与 #### 1. 物理架构的验证与文档更新 在软件架构开发过程中，对架构进行验证是至关重要的环节。在验证架构时，需要将到目前为止构建的所有模型，即功能模型、部署模型和数据模型，对照已知需求进行验证。同时，架构决策工作产品中记录的关键决策（并由架构概念验证支持），将与架构概述工作产品一起在验证过程中使用。 完成架构验证后，需要更新软件架构文档，以反映已定义的物理架构。软件架构文档的目的是将所有相关的架构信息汇总在一处，便于进行架构的沟通和审查。该文档通常是参考工作产品中所有可用信息的子集。 在更新软件架构文档以包含物理架构时，面临的挑战是决定是扩展现有的文档，还是将可能庞大的文档拆分为多个单独的文档，共同构成软件架构文档工作产品。这种拆分可以通过多种方式实现，例如基于逻辑架构与物理架构的区分，或者按架构视图进行划分。 将架构工作产品整合到一个总体工作产品（软件架构文档）中的主要原因，是为了将到目前为止所做的工作传达给所有团队成员，并让利益相关者进行审查，以便他们签字确认。对于大多数有一定规模的项目，通常会有一个或多个项目推进授权点（AtP），在获得进一步的资金或资源之前，必须成功通过这些授权点。为了满足 AtP 的输入要求，作为 AtP 一部分需要审查的重要工作产品通常需要在商定的水平上进行基线化。这也是创建软件架构文档的主要原因之一，它为利益相关者提供了一个架构的时间点视图，供他们审查和达成一致。 #### 2. 与利益相关者审查架构 与利益相关者审查架构这一任务，与创建逻辑架构时的类似任务几乎相同，但此次是针对物理架构进行的。在这个任务中，首先要对物理架构工作产品进行基线化，然后与关键利益相关者一起审查软件架构文档和支持性的架构工作产品。发现的任何问题都记录在变更请求中。审查完成后，在审查记录中简要记录审查结果，包括任何行动项。 这种审查起到了质量关卡的作用，确保物理架构足够稳定，能够支持依赖它的任务。因此，相关方的参与至关重要，例如项目经理、测试人员和开发人员等。 下面是一个简单的流程图，展示了与利益相关者审查架构的流程： ```mermaid graph LR A[基线化物理架构工作产品] --> B[审查软件架构文档和支持性工作产品] B --> C{发现问题?} C -- 是 --> D[记录在变更请求中] D --> B C -- 否 --> E[记录审查结果到审查记录] ``` #### 3. 架构师在项目各方面的角色 架构师作为项目的技术负责人，对软件开发项目的许多方面都有影响。下面将详细介绍架构师在项目不同方面的具体角色。 ##### 3.1 架构师与需求 架构师在需求方面有多种职责。主要贡献包括确保考虑到系统中更具技术性的用户（如系统管理员），确保更具技术性的需求（特别是非功能需求，如质量和约束）得到适当的捕获和详细说明，并协助对请求和由此产生的需求进行优先级排序。 | 架构师职责 | 具体内容 | | --- | --- | | 考虑技术用户 | 确保系统管理员等技术用户的需求被考虑 | | 强调技术需求 | 重点关注非功能需求的捕获和详细说明 | | 协助需求优先级排序 | 帮助确定需求的优先级 | ##### 3.2 架构师与开发 开发阶段的目的是执行详细设计任务，定义实现的组织方式，实现详细设计元素，对实现进行单元测试，集成各个开发人员的工作，并最终生成可执行系统。 架构是详细设计活动的输入，因为它确定了系统的主要组件及其接口。架构师的影响不仅限于此，还负责实现中与架构相关的重要方面，例如用于组织源代码的实现结构。良好的实现结构支持并发开发，不同的开发人员（或开发团队）可以并行实现系统的不同元素。 架构师还负责识别任何与开发相关的标准、指南和可重用资产。此外，架构师需要考虑实现的各个元素集成以提供交付系统的顺序。架构在集成和测试方面提供了很好的指导，例如可以将系统创建为一系列单独集成和测试的构建。 架构师不仅要在与开发相关的某些技术问题上提供具体输入，还要对整个技术成果负责。架构师通常会与项目团队成员密切合作，指导和指导他们的工作，确保遵守任何架构决策和标准。 以下是架构师在开发方面的职责列表： 1. 确定要设计和实现的元素 2. 识别重要的实现结构（如代码组织） 3. 影响元素实现和集成的顺序 4. 确保遵守架构决策和标准 ##### 3.3 架构师与测试 测试阶段的目的是发现并记录软件质量中的缺陷，就感知到的软件质量提供建议，并验证系统是否按设计和要求运行。测试阶段补充了开发阶段进行的单元测试，重点关注开发人员提供的集成单元和整个系统。 测试阶段包括集成测试、系统测试和验收测试。集成测试侧重于测试多个开发人员的工作作为一个集成整体；系统测试侧重于测试整个系统