ARTICLE · 1111708
详细讲解项目管理软件工程的软件实现和软件部署交付
智慧水务项目管理中的软件工程，可以理解为：用软件工程的体系，把“感知设备、边缘网关、数据平台、业务应用、算法模型、现场运维”组织成一套可计划、可评审、可测试、可交付、可运维的工程过程。
它不只是写代码，而是覆盖从需求、架构、开发、测试、部署、配置、变更、质量、安全到运维移交的全生命周期。
软件配置管理(Software Configuration Management, SCM)核心 2 部分：
1. 版本控制(Version Control)= 对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理；最主要功能是追踪文件的变更；另一重要功能是并行开发(分支与合并解决 Bug 修正问题)
2. 变更控制(Change Control)= 对变更进行管理，确保变更有序进行(目的不是控制变更的发生)
SCM 整体定义：一种标识、组织和控制修改的技术。SCM 应用于整个软件工程过程。
SCM 4 个目标：标识变更、控制变更、确保变更正确实现、向其他有关人员报告变更。
速记方法SCM 核心 2 部分口诀：版 · 变
- 版(版本控制)→ 追踪文件变更和并行开发
- 变(变更控制)→ 确保变更有序
软件配置管理活动 6 项：
1. 软件配置管理计划：制订需要了解组织结构环境和组织单元之间的联系，明确软件配置控制任务
2. 软件配置标识：识别要控制的配置项，并为这些配置项及其版本建立基线
3. 软件配置控制：关注的是管理软件生命周期中的变更
4. 软件配置状态记录：标识、收集、维护并报告配置管理的配置状态信息
5. 软件配置审计：独立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动
6. 软件发布管理与交付：通常需要创建特定的交付版本，完成此任务的关键是软件库
软件配置管理与软件质量保证活动密切相关，可以帮助达成软件质量保证目标。
速记方法SCM 6 项活动口诀：计 · 识 · 控 · 录 · 审 · 发
- 计(计划)→ 制订配置管理计划
- 识(标识)→ 识别配置项和建立基线
- 控(控制)→ 管理生命周期变更
- 录(状态记录)→ 报告配置状态
- 审(审计)→ 独立评价
- 发(发布管理与交付)→ 创建交付版本和软件库
软件测试方法 2 大类：
1. 静态测试：被测试程序不在机器上运行；只依靠分析或检查源程序的语句、结构、过程等
- 对文档的静态测试 → 检查单形式
- 对代码的静态测试 → 桌前检查和代码走查和代码审查
- 经验：能发现 30% ~ 70% 的逻辑设计和编码错误
2. 动态测试：在计算机上实际运行程序；对得到的运行结果与预期的结果进行比较分析
- 一般采用：白盒测试和黑盒测试
注：使用静态测试的方法也可以实现白盒测试。
速记方法测试方法 2 大类按「程序是否运行」分：
- 静态(不运行)→ 检查代码 / 文档
- 动态(运行)→ 跑程序看结果
内部细分：静态有 3 种代码方式(桌前检查和代码走查和代码审查)；动态有 2 种主流方式(白盒和黑盒)。
静态测试的 2 个对象和对代码的 3 种方式：
1. 对文档的静态测试 → 检查单形式
2. 对代码的静态测试 → 3 种方式：
- 桌前检查(Desk Checking)= 程序员独立审查自己的代码
- 代码走查：团队共同走读代码
- 代码审查：正式的同行评审
经验数据：使用静态测试方法能够有效地发现 30% ~ 70% 的逻辑设计和编码错误。
注：静态测试是「不运行程序」的测试方法，仅依靠分析或检查源程序的语句、结构、过程等来检查程序是否有错误。
速记方法对代码的静态测试 3 种方式口诀：桌 · 走 · 审
- 桌(桌前检查)→ 个人独立审
- 走(代码走查)→ 团队走读
- 审(代码审查)→ 正式评审
按强度递增：个人 < 团队 < 正式。
动态测试 2 大方法对照：
1. 白盒测试(也称结构测试)：
- 主要用于：软件单元测试中
- 思想：将程序看作一个透明的白盒，测试人员完全清楚程序的结构和处理算法
- 设计依据：按照程序内部逻辑结构设计测试用例
- 主要方法：控制流测试、数据流测试、程序变异测试
- 主要技术：逻辑覆盖(语句覆盖、判定覆盖、条件覆盖、条件 / 判定覆盖、条件组合覆盖、修正的条件 / 判定覆盖、路径覆盖)
- 注：使用静态测试的方法也可以实现白盒测试
2. 黑盒测试(也称功能测试)：
- 主要用于：集成测试、确认测试、系统测试中
- 思想：将程序看作一个不透明的黑盒，完全不考虑程序的内部结构和处理算法
- 设计依据：根据 SRS 所规定的功能设计测试用例
- 主要方法：等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法、正交试验法
速记方法白盒 vs 黑盒一表清：
- 白盒：结构测试：单元测试主战场(看内部)
- 黑盒：功能测试：集成 / 确认 / 系统测试主战场(看外部)
资深解读：白盒(结构)vs 黑盒(功能)双称谓和用途辨析是 5.4.3 节最高频考点(经典 100 题第 3 题同套路)。命题人最爱考「也称为某某测试」和「主要用于某某测试」双辨析——记忆诀「白盒：看结构(单元测试)/ 黑盒：看功能(集成和确认和系统)」。
单元测试关键特征：
- 测试对象：模块(独立编译或汇编的程序模块、软件构件、OO 软件中的类)
- 技术依据：软件「详细设计」说明书
- 测试方面：模块接口、局部数据结构、重要执行通路、出错处理通路、边界条件
- 主要方法：白盒测试(主战场)
集成测试关键特征：
- 测试对象：已严格按程序设计要求和标准组装起来的模块
- 技术依据：软件「概要设计」文档
- 准入条件：一般测试准入条件和模块均已通过单元测试
- 主要方法：白盒和黑盒结合
核心区别：技术依据匹配设计粒度。
速记方法单元 vs 集成技术依据匹配设计粒度：
- 单元 → 详细设计(最细颗粒)
- 集成 → 概要设计(模块组装)
顺序：先单元后集成(必须通过单元才能集成)。
面向对象(Object-Oriented, OO)测试 vs 传统结构化测试对比：
相同点：
- OO 系统的测试目标与传统信息系统的测试目标是「一致的」(都是发现错误，确保质量)
不同点(2 大方面)：
1. 测试焦点：从「模块」移向了「类」
2. 测试视角：扩大到了「分析和设计模型」
不同的根因：OO 系统 3 个明显特征：
1. 封装性对测试的影响：信息隐蔽原则对测试的影响和对象状态与类的测试序列
2. 继承性对测试的影响：继承对测试充分性的影响和误用引起的错误
3. 多态性对测试的影响：动态绑定对测试充分性的影响和抽象类的测试和误用对测试的影响
正是由于这 3 个特征，给 OO 系统的测试带来了一系列的困难。
速记方法OO 测试 vs 传统结构化测试关键辨析：
- 目标 → 一致(找错误，确保质量)
- 策略 → 不同(焦点变和视角扩)
口诀：「目标同，策略变」。
软件实现 4 大内容板块对照：
1. 软件配置管理(5.4.1)
- 核心 2 部分：版本控制和变更控制
- 6 项活动：管理计划 / 标识 / 控制 / 状态记录 / 审计 / 发布管理与交付
2. 软件编码(5.4.2)
- 编码效率 4 类：程序 / 算法 / 存储 / I/O
- 程序设计风格 4 方面：源程序文档化 / 数据说明 / 语句结构 / 输入输出方法
3. 软件测试
- 测试方法 2 大类：静态和动态(白盒 / 黑盒)
- 测试类型 6 类：单元 / 集成 / 确认 / 系统 / 配置项 / 回归
- OO 测试：封装 / 继承 / 多态对测试的影响
4. 软件调试
- 调试策略 3 种：蛮力法 / 回溯法 / 原因排除法
速记方法
软件实现 4 大块快速辨析：
- SCM → 关键词「版本 / 变更 / 配置项 / 基线」
- 编码 → 关键词「程序设计语言 / 编码效率 / 设计风格」
- 测试 → 关键词「静态 / 动态 / 白盒黑盒 / 6 类测试类型」
- 调试 → 关键词「蛮力 / 回溯 / 原因排除」
抓关键词秒判内容板块归属。
资深解读
软件实现 4 大块(SCM / 编码 / 测试 / 调试)实战中协同——SCM 管变更、编码写代码、测试找错误、调试定位修复。软考爱用「某团队实现某系统」场景考 4 大块辨析能力，少哪块都会让实现不完整。节末综合题练就「场景对照 4 大块」的快速判断能力，是 整体应用考点。
软件部署 4 个主要特征：
1. 过程覆盖度 2. 过程可变更性 3. 过程间协调 4. 模型抽象
软件部署是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件产品的后续运行。
软件部署模型 6 种(用于有效地指导部署过程)：应用模型、组织模型、站点模型、产品模型、策略模型、部署模型。
「安装 / 配置 / 激活 / 卸载」是软件部署的具体活动，不是过程的主要特征
「计划 / 设计 / 实现 / 部署」是软件开发阶段
「单元 / 集成 / 系统 / 回归测试」是测试类型 6 类中的 4 种
速记方法4 主要特征口诀：覆 · 变 · 协 · 抽
- 覆(过程覆盖度)→ 部署过程的覆盖范围
- 变(过程可变更性)→ 过程支持变更的能力
- 协(过程间协调)→ 多过程的协同
- 抽(模型抽象)→ 用部署模型抽象指导
传统软件交付流程 4 步：
1. 业务人员：诞生一个软件的想法
2. 开发人员：将想法变为一个产品或者功能
3. 测试人员：测试之后提交给用户使用并产生收益
4. 运维人员：参与产品或功能的后期运维
这是从想法到上线的完整链路。
速记方法4 步口诀：业 · 开 · 测 · 运
- 业(业务人员)→ 想法
- 开(开发人员)→ 产品 / 功能
- 测(测试人员)→ 测试和提交用户
- 运(运维人员)→ 后期运维
关键流向：想法 → 产品 → 验证 → 维护
持续交付的关键定义：
1. 本质：一系列开发实践方法
2. 目标：确保代码能够快速、安全地部署到生产环境中
3. 特点：完全自动化的过程；当业务开发完成的时候，可以做到「一键部署」
4. 背景：经过对传统软件交付问题的分析和总结，持续交付应运而生
持续交付改进 3 方面：
- 在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的「用户故事」
- 在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试
- 在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统一
速记方法持续交付关键词：「自动和快速和一键和安全」
联想互联网巨头：单日部署 8000+ 次(部分组织 20000+ 次)= 持续交付实战。
互联网公司软件交付能力 2 个评价指标：
1. 核心指标：仅涉及一行代码的改动需要花费多少时间才能部署上线
2. 第二指标：开发团队是否在以一种可重复、可靠的方式执行软件交付
互联网组织的部署频率参考数据：
- 国内外主流互联网组织部署周期都以「分钟」为单位
- 互联网巨头组织单日的部署频率都在 8000 次以上
- 部分组织达 20000 次以上
高频率的部署代表着能够更快更好地响应客户的需求。
题干场景中提到的 3 个改进对应持续交付的 3 方面改进：
- 需求阶段 → 用户故事(代替传统需求文档)
- 开发测试阶段 → 持续集成(测试人员尽早进入)
- 运维阶段 → 开发与运维统一(打通通路)
速记方法持续交付能力 2 大评价指标：
- 速度指标(核心)：1 行代码改动 → 上线所需时间
- 可靠指标：交付方式是否可重复、可靠
联想：「分钟级部署 + 8000 次 / 天」是互联网巨头标杆。
持续部署 8 条原则：
1. 部署包全部来自统一的存储库
2. 所有的环境使用相同的部署方式
3. 所有的环境使用相同的部署脚本
4. 部署流程编排阶梯式晋级(在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作)
5. 整体部署由「运维人员」执行(不是开发人员)
6. 仅通过流水线改变生产环境，防止配置漂移
7. 不可变服务器
8. 部署方式采用蓝绿部署或金丝雀部署
速记方法8 条原则关键词：「统一和相同和阶梯和运维和流水线和不可变和蓝绿金丝雀」
- 统一来源(原则 1)
- 相同方式和相同脚本(原则 2 + 3)
- 阶梯晋级(原则 4)
- 运维执行(原则 5)
- 流水线和不可变(原则 6 + 7)
- 蓝绿 / 金丝雀(原则 8)
关键反陷阱：「运维」执行(不是开发)。
完整的镜像部署 3 环节(Build-Ship-Run)：
1. Build = 跟传统的编译类似，将软件编译形成 RPM 包或者 Jar 包
2. Ship = 将所需的第三方依赖和第三方插件安装到环境中
3. Run = 在不同的地方启动整套环境
部署层次的设置对于部署管理来说非常重要。首先要明确：部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。
制作完成部署包之后，每次需要变更软件或者第三方依赖、插件升级的时候，不需要重新打包，直接更新部署包即可。
速记方法Build-Ship-Run 3 环节口诀：建 · 运 · 启
- Build(建) → 编译软件包(RPM / Jar)
- Ship(运) → 装入第三方依赖和插件
- Run(启) → 在目标环境启动整套
联想集装箱模式：建造集装箱(Build) → 运送(Ship) → 在港口运营(Run)。
蓝绿部署 vs 金丝雀部署关键对比：
1. 蓝绿部署：
- 准备新旧两个部署版本
- 通过域名解析切换的方式将用户使用环境切换到新版本中
- 当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整
- 切换方式：全量切换(所有用户一次切到新版本)
2. 金丝雀部署：
- 当有新版本发布的时候，先让少量的用户使用新版本
- 并且观察新版本是否存在问题
- 如果出现问题，就及时处理并重新发布
- 如果一切正常，就稳步地将新版本适配给所有的用户
- 切换方式：灰度发布(逐步扩大新版本用户)
核心区别：
- 蓝绿：全量切换和双版本备份
- 金丝雀：灰度发布和少量先试
速记方法蓝绿 vs 金丝雀辨析：
- 蓝绿(Blue-Green)→ 双版本切换(域名解析切换)→ 出问题快速切回
- 金丝雀(Canary)→ 灰度发布(少量先试 → 稳步扩大)
本质区别：「双版本切换」vs「灰度逐步」。
资深解读蓝绿 vs 金丝雀是 节高频陷阱(命题人最爱颠倒考)。记忆诀「蓝绿：双版本切换(域名解析)/ 金丝雀：灰度发布(少量用户先试)」——本质区别在于切换方式：蓝绿是「全量切换」，金丝雀是「逐步扩大」。
部署交付节 5 部分对照：
1. 软件部署：部署模式 3 种(单机 / 集中式 / 微服务分布式)+ 主要特征 4 个(过程覆盖度 / 可变更性 / 协调 / 模型抽象)(场景①体现：微服务分布式和容器 / DevOps)
2. 软件交付(传统流程) = 传统 4 步(业务 → 开发 → 测试 → 运维)+ 3 方面问题(需求沟通效率低 / 测试自动化低 / 运维排期挤占)(场景未涉及——已被持续交付替代)
3. 持续交付：用户故事和持续集成和开发运维统一(场景②体现)
4. 持续部署：K8s + Docker 容器方案 + 8 条原则 + Build-Ship-Run + 蓝绿 / 金丝雀(场景③④体现)
5. 部署和交付新趋势：工作分工转变和云计算飞跃和研发运维融合(可视为整体趋势)
速记方法4 大块快速辨析：
- 部署 → 关键词「单机 / 集中 / 微服务分布式 + 4 主要特征」
- 传统交付 → 关键词「业务 → 开发 → 测试 → 运维 4 步 + 3 方面问题」
- 持续交付 → 关键词「用户故事和持续集成和开发运维统一」
- 持续部署 → 关键词「K8s / Docker + 8 原则 + Build-Ship-Run + 蓝绿 / 金丝雀」抓关键词秒判子节归属。
资深解读部署交付节实战中：传统交付(业务 → 开发 → 测试 → 运维 4 步)已被持续交付(用户故事和持续集成和开发运维统一)替代，落地手段是持续部署(K8s + 蓝绿 / 金丝雀)。