系统架构设计笔记 Part 3
第三篇 软件架构设计系统工程
6 软件工程学
6.1 软件工程学概述
6.2 软件实现
图6-4 需求的层次
图6-6 四象限法
表6-2 UML图
| 名称 | 描述 | 小类 | 大类 |
|---|---|---|---|
| 类图 | 类以及类之前的相互关系 | 静态图 | 结构 |
| 对象图 | 对象以及对象之前的相互关系 | 静态图 | 结构 |
| 组件图 | 组件及其相互依赖关系 | 实现图 | 结构 |
| 部署图 | 组件在各个节点上的部署 | 实现图 | 结构 |
| 时序图 | 强调时间顺序的交互图 | 交互图 | 行为 |
| 协作图 | 强调対象协作的交互图 | 交互图 | 行为 |
| 状态图 | 类所经历的各种状态 | 行为图 | 行为 |
| 活动图 | 工作流程的模型 | 行为图 | 行为 |
| 用例图 | 需求捕获和描述 | 用例图 | 行为 |
图6-8 UML图关系
图6-21 业务架构和技术架构
图6-23 架构师的桥梁作用
6.3 项目管理
表6-3 质量观点对比
| 传统质量观点 | 现代质量管理观点 |
|---|---|
| 质量是检查出来的 | 质量是规划出来的，而非检查出来的 |
| 质量就是指产品的质量 | 质量不只是产品还包括过程 |
| 缺陷是不可避免的 | 事情一次作对成本最低-零缺陷 |
| 质量管理是质量部门人员的事情 | 质量管理，人人有责 |
| 对于质量事故，基层人员负主要责任 | 质量责任高层管理者承担85% |
| 质量越高越好 | 质量就是符合要求、适用、客户满意，需要考虑成本与收益 |
| 改进质量主要靠检査和返工 | 改进质量考预防和评估 |
图6-27 一致性成本和非一致性成本
质量保证和质量控制的本质区别：
质量保证的对象是过程本身
质量控制的对象是软件系统
表6-4 质量工具与使用场景
| 场景 | 使用工具 | 特点 |
|---|---|---|
| 需要找出引发问题的原因 | 因果图、流程图 | 发散思维 |
| 需要判断过程是否在控制内、是否出现了典型偏差 | 过程控制图 | 按时间定义测量数据 |
| 需要找出影响问题的关键原因，指导采取纠正行动 | 帕累托图 | 20/80原理 |
| 需要看产品是否符合要求，可时间有限、费用有限 | 统计抽样 | 节约成本 |
图6-29 风险管理过程框架
项目管理与架构师
一般意义上的架构师主要职责在于：
跟客户或需求分析人员进行沟通后获取客户需求
将面向客户的需求文档变成面向开发人员的开发文档
同时要从功能实现的角度出发来实现系统的总体规划
然而现实中，架构师可能担当着需求分析和系统建模工作，成为一名业务架构师
同时，架构师作为研发团队的负责人，也需要把控团队的资源、成本、进度、质量等项目管理因素，成为半个项目经理
6.4 过程改进
图6-40 瀑布模型
Water-Scrum-Fall模型是迭代与瀑布的一种结合
图6-45 Water-Scrum-Fall模型
7 敏捷方法与实践
7.1 敏捷方法论概述
敏捷宣言中强调的敏捷软件开发4个核心价值是：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
敏捷方法论是一种理念，在理念背后有很多实现模型，最具代表性的有两大派系:
面向工程实践。包括：极限编程（eXtreme Programing, XP）、特征驱动开发（Feature Driven Development, FDD）等
面向过程管理。包括：Scrum、精益（Lean）思想等
7.2 极限编程与工程实践
图7-3 极限编程中的迭代
图7-5 TDD流程
7.3 Scrum与过程管理
目前，主流的做法就是把极限编程与Scrum整合起来一起应用，通过Scrum先确定软件开发的基本流程和步骤，再通过极限编程中的各项工程实践来具体实现这些流程和步骤。
图7-7 Scrum框架
表7-1 Scrum团队中的顶目管理工作与角色映射关系
| 项目管理领域 | Product Owner | Scrum Master | Development Team | 说明 |
|---|---|---|---|---|
| 范围 | √ | 通过迭代计划会议共同决定 | ||
| 时间 | √ | 固定 | ||
| 成本 | √ | 时间固定则范围决定成本 | ||
| 质量 | √ | √ | √ | 共同承担 |
| 风险 | √ | √ | √ | 共同承担 |
7.4 敏捷方法论与架构师
8 软件交付模型
8.1 软件交付模型概述
比较典型的软件交付工作流程可以抽象为：代码提交→代码编译→自动化测试→手工测试→部署→预发布→正式发布。
8.2 配置管理
表8-1 配置管理基本元素
| 元素 | 描述 |
|---|---|
| 软件配置项（SCI） | 与配置控制下的软件项目有关的任何事物 |
| 版本（Version） | 配置项的一个实例 |
| 基线（Baseline） | 组成系统的各个组件版本的集合，不能改变 |
| 配置管理数据库（CMDB） | 保存配置项及其关系的数据库 |
| 主线（Mainline） | 代表系统不同版本的基线的序列 |
| 发布版本 | 发布给客户使用的系统版本 |
| 工作区间（Workspace） | ー个私有的工作区间，在其中可以修改而不至于影响其他会修改软件的开发者 |
| 分支（Branch） | 从现存的代码线版本中构建一个新的代码线 |
| 系统构建 | 通过耦合和链接组件和库的合适版本创建一个可执行的系统版本 |
8.3 持续集成
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。
每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。
许多团队发现这个过程可以大大减少集成的问题，让团队能够更快地开发内聚的软件。
8.4 交付工作流
图8-16 交付工作流组成结构
References
《系统架构设计：程序员向架构师转型之路》