网站架构师的工作内容(一下不同角色的架构师的定义及其职责-首席架构师)

　　网站架构师的工作内容(一下不同角色的架构师的定义及其职责-首席架构师)

　　通过上一节的介绍，相信你对架构设计有了初步的了解。本节主要讲解架构的方法和基本原理。虽然这很粗俗，但我们还是要对它做一个大概的介绍，以免我们在设计架构时陷入误区。

　　我们知道，软件开发项目是由不同角色的人完成不同任务而产生的工作产品。如果我们要开发软件，我们需要研究角色、任务和工作产品来开发架构。接下来，我们将详细介绍这三个部分。

　　角色

　　角色定义了在软件开发组织中作为团队一起工作的一群人或个人的职责。角色不是一个人，一个人可以扮演多个角色，多人也可以扮演同一个角色。下面我们介绍架构师在不同角色中的定义和职责：

　　首席架构师全权负责定义系统架构的主要技术决策。该角色还负责为这些决策提供理论基础；平衡不同利益相关者的关注点；管理技术风险和问题；并确保有效地传达、验证和执行决策。

　　应用程序架构师专注于那些自动化业务流程和满足业务需求的元素。这个角色主要关注业务所需的功能，但他也关心应用相关的元素如何满足系统的非功能需求（质量和约束）。

　　基础架构架构师专注于不依赖于业务功能的系统元素，例如持久性机制、硬件和中间件。这些元素支持与应用程序相关的元素的执行。这个角色关注那些对系统质量有重大影响的元素。因此，他也会处理一些扩​​展的非功能性需求。

　　数据架构师关注系统的数据元素，尤其是那些使用适当机制（如数据库、文件系统、内容管理系统或其他存储机制）来维护持久数据的数据元素。该角色定义了适当的数据相关属性，例如结构、来源、位置、完整性、可用性、性能和年龄。

　　任务

　　任务是在项目上下文中提供有意义结果的工作单元。它有明确的目的，通常涉及创建或更新工作产品。所有任务都由适当的角色执行。

　　任务可能会重复多次，尤其是在采用迭*敏*感*词*发时。下图列出了架构师不同角色的相关任务。

　　工作产品

　　工作产品是在流程执行过程中产生和使用的一些信息或物理实体。工作产品包括模型、计划、代码、可执行代码、文档、数据库等。虽然多个角色可以协作产生一个工作产品，但它是单个角色的责任。

　　SPEM（软件系统过程工程元模型规范）定义了三种类型的工作产品：工件、可交付成果和结果。工件是真实的工作产品，例如文档、模型源代码、可执行文件或项目计划。可交付成果是实际打包和交付的工作产品。成就表示结果或任务执行结果的状态。下图展示了架构师不同角色的一些文档产品。

　　我们知道软件行业中使用的各种方法之间的差异主要与遵循的过程有关，而不是与角色、工作产品和任务有关，所以我们现在讨论三种最常用的过程类型：瀑布、迭代和敏捷.

　　瀑布模型是早期软件开发模型的一个模型，但是在开发绿地项目（架构师从头开始）或者那些经过大量修改的项目中，由于项目进度的原因，瀑布模型无法准确衡量，并且直到项目后期才能获得用户。由于反馈等原因逐渐放弃。在这里，我不会过多介绍瀑布模型，仅用下图来说明瀑布模型的开发过程。

　　迭代是一个项目的短期划分。迭代期间清晰、固定时间的活动序列将生成可执行产品的版本。OpenUP 定义了软件开发的四个阶段：启动、细化、构建和移交。在每个阶段，将进行 N 次迭代以形成一个产品。

　　与瀑布式开发过程相比，迭*敏*感*词*发是由结果而不是工作产品驱动的，这有助于更准确地衡量项目的进度。迭代法通过系统增量版本的执行，尽早获得用户反馈，这些反馈促进了实际需求的收敛。

　　敏捷开发是近年来最流行的开发方式。代表性方法包括极限编程、Scrum、精益和特征驱动开发。虽然每种具体的敏捷方法和所提倡的方法都存在一些差异，但它们都基于相同的基本原则——敏捷宣言：

　　关注个人及其互动，而不是流程和工具。

　　专注于可用的软件而不是详细的文档。

　　专注于客户协作胜于合同谈判。

　　专注于响应变化比坚持计划更好。

　　敏捷流程不提倡预先设计，架构直接来自代码。但是，“关注可用软件而不是详细文档”的原则并不意味着没有文档，它仅意味着只有满足当前迭代目标的文档。

　　在本文中，我们介绍了软件架构的一些方法和基本原理。同时，我们还用生动的图形来说明工程师在不同角色中的职责和工作成果。通过这些介绍，我们可以详细介绍项目生命周期中使用的方法以及如何设计架构。欢迎您继续关注。. .