系统架构设计笔记 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#
《系统架构设计:程序员向架构师转型之路》