系统架构设计笔记 Part 3

第三篇 软件架构设计系统工程

6 软件工程学

6.1 软件工程学概述

6.2 软件实现

图6-4 需求的层次

图6-6 四象限法

https://s1.wailian.download/2020/04/05/four_quadrant-min.pngfour_quadrant

表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

  • 《系统架构设计:程序员向架构师转型之路》