1 概述
作为一名程序员，最令人沮丧的莫过于：投入了大量时间与精力，开发出的软件却不好用、甚至不可用。现在vibe coding日臻完善，但是软件的开发仍然还是达不到随心所欲的程度。现实中也不时陷入琐碎事务而难以抽身，由此反观自身是不是我们站位不够高？很多时候，换一个视角看问题，答案便截然不同。最近一段时间学习北京大学孙艳春老师的《软件工程》课程获益良多，结合自己AI使用的经验又大胆拓展了AI 驾驭工程（AI Harness Engineering，本文第10节）内容以期待与时俱进。
2 生存周期模型
为保证软件开发及时、高质量地完工，需要针对项目特点，选择合适的开发流程与策略，即软件生存周期模型。常见的模型对比如下：
| 模型 | 主要特点 |
|---|---|
| 瀑布模型 | 阶段顺序展开、文档驱动，适合需求明确且稳定的场景 |
| 增量模型 | 分批交付可用的软件增量，逐步丰富产品功能 |
| 演化模型 | 通过多轮原型迭代，逐步明确并实现需求 |
| 喷泉模型 | 支持迭代与无间隙开发，适合面向对象开发方式 |
| 敏捷模型 | 拥抱变化、小步快跑、持续交付，强调人与协作 |
3 需求分析
3.1 需求在系统工程中的作用
- 需求分析（问题定义）：通过分析分配给软件的那些系统需求，确定软件需求及约束。
- 软件体系结构设计（解决方案分析）：针对软件需求及约束，确定一组候选解决方案，进行实例研究，分析各种可能的方案，并选出其中最佳的一个。
- 验证、确认及测试（产品评估）：以需求为准则，通过测试、演示、分析及审查等方式，评估最终产品和文档，其中包括一些必要的软件系统集成活动。
3.2 需求的分类
功能需求、性能需求、外部接口需求、设计约束、质量属性。
3.3 需求的发现
自悟、交谈、观察、小组会、提炼，以及多种方式的综合运用。
3.4 需求规约的概念和格式
需求规约是对软件产品及其外部行为的完整描述，是后续软件设计、验证与确认活动的基础和依据。
4 结构化方法
4.1 结构化分析方法
核心工具是数据流图（DFD）：先建立顶层数据流图，然后自顶向下、逐层求精，形成分层数据流图；配合数据字典与加工说明，最终产出需求规格说明书。
4.2 结构化设计方法
包括初始模块结构图的设计与精化、接口设计、数据设计，并以软件设计规约为载体表达设计结果。
5 面向对象方法
5.1 UML 建模
静态建模
- 类图：显示类（及其接口）、类的内部结构以及与其他类之间的联系，是面向对象分析与设计所得到的最重要的模型。
- 构件图：在转入实现阶段之前，可以用它表示如何组织构件；构件图描述了构件及构件之间的依赖关系。
- 部署图：展示运行时进行处理的结点和在结点上生存的制品的配置，用来对系统的静态部署视图建模。
动态建模
- 用况图：面向需求的模型，描述参与者与系统之间的交互。
- 状态图：当对象的行为比较复杂时，可作为辅助模型描述对象的状态及其状态转移，从而更准确地定义对象的操作。
- 活动图：注重从活动到活动的控制流，既可描述对象的操作流程，也可描述一组对象之间的协作行为或用户的业务流程。
- 顺序图：注重消息的时间次序，可用来表示一组对象之间的交互情况。
- 通信图：注重收发消息的对象的组织结构，与顺序图语义等价、视角互补。
- 交互概观图：用于描述系统的宏观行为，是活动图和顺序图的混合物。
- 定时图：用于表示交互，展现消息跨越不同对象或角色的实际时间，而不仅仅关心消息的相对顺序。
此外，UML 还提供了"包"这一控制复杂性的通用组织机制，用于对模型元素进行分组管理。
5.2 面向对象分析方法
核心是对"人、事、物"的识别与筛选：先识别类（对象），再识别属性与操作，最后识别对象之间的关系（关联、泛化、依赖、细化等）。
5.3 面向对象设计方法
面向对象设计包括四个部分：问题域部分的设计、人机交互部分的设计、控制驱动部分的设计与数据管理部分的设计。
问题域设计所要考虑的问题
- 编程语言；
- 硬件、操作系统及网络设施；
- 复用支持；
- 数据管理系统；
- 界面支持系统。
如何进行问题域部分的设计
- 继续运用 OOA 的方法：概念、表示法及策略；
- 使用 OOA 结果，并加以修改：应对需求的变化、修正新发现的错误；
- 使用 OOA 结果，并进行补充与调整（重点）：
- 为复用设计与编程的类而增加结构；
- 增加一般类以建立共同协议；
- 按编程语言调整继承；
- 提高性能；
- 为实现对象永久存储所做的修改；
- 为编程方便增加底层细节。
6 软件开发环境与工具
课程从 CASE（计算机辅助软件工程）的概念出发，介绍了软件开发工具与环境的构成：
- CASE 工具：支持软件生存周期某一过程或活动的单个工具（如需求分析工具、设计工具、编码与测试工具、维护工具、项目管理工具等）。
- CASE 工作台：支持某一生存周期过程的一组集成化工具。
- 软件开发环境：工具与集成机制的组合，为开发者提供一体化的支持。
- 工具集成模型：包括 Wasserman 五级模型、APSE 模型、层次模型和 PCTE 等。
- 常用的开发工具与环境：按技术方向划分，覆盖 Java、C/C++、Web、移动应用等领域的开发、构建与管理工具链。
7 编码实现与测试
课程资料对本部分着墨不多，以下是结合课程理念的个人理解：
- 编码实现：编码本质上是把设计"翻译"为代码，应遵循良好的编码规范与风格，让代码像文档一样可读、可维护。
- 过程质量：代码走查、结对编程与合理的重构，都是在编码阶段保障质量的有效手段。
- 测试与评估：验证与确认（V&V）以需求为准则，通过测试、演示、分析及审查等方式评估最终产品，贯穿开发全过程。
- 核心理念：质量不是最后测出来的，而是从需求捕获、分析、设计、编码等过程就要监控的。
8 项目管理与 CMMI
8.1 项目管理知识体系
项目管理涉及九大知识领域：
- 四大核心知识领域：范围、时间、成本和质量。
- 四大辅助知识领域：人力资源管理、风险管理、沟通管理和采购管理。之所以称其为辅助知识领域，是因为项目目标正是通过它们来实现的。
- 项目整体管理：在项目生命周期中协调所有其他项目管理知识领域所涉及的过程，确保项目的所有组成要素在正确的时间结合在一起，以成功地完成项目。
项目整体管理包括以下几个主要过程：
- 项目计划制定：收集其他计划编制过程的结果，并将它们整合为一个协调一致的文件——项目计划；
- 项目计划执行：通过执行项目计划所包含的有关活动，实施项目计划；
- 整体变更控制：协调整个项目范围内的变更。
8.2 软件开发管理
- 软件开发管理过程：启动、计划、实施、监控、收尾。
- 人员管理：关注团队的组织架构、沟通等方面的协调与监控。
- 软件采购管理：如今早已不流行从零开始开发软件，基于成熟组件采购与复用是常态。
- 质量控制：质量不是测试出来的，而是要从需求捕获、分析、设计、编码等过程就要监控。
- 进度计划：重视里程碑，以可验证的阶段性成果牵引整体进度。
8.3 CMMI 能力成熟度模型
CMMI 将软件组织的过程能力划分为五个等级（原文误将第 5 级写作 “CMMI 4”，此处已订正）：
| 等级 | 名称 | 特征 |
|---|---|---|
| CMMI 1 | 初始级 | 过程混乱无序，基本没有计划，成功依赖个人英雄主义 |
| CMMI 2 | 可重复级 | 以往项目的成功经验可以被重复利用 |
| CMMI 3 | 已定义级 | 过程已标准化、文档化，组织级统一执行 |
| CMMI 4 | 已管理级 | 过程与质量可量化度量与管理 |
| CMMI 5 | 优化级 | 持续过程改进，不断优化提升 |
除 CMMI 之外，ISO 9000 系列标准也是软件行业常用的质量管理体系，两者互为补充。
9 软件维护与再工程
- 软件维护的概念与活动：软件交付使用后，为修正缺陷、改善性能或适应环境变化而进行的一系列活动，核心是程序修改的管理与实施。
- 逆向工程：从已有的代码和文档中，反向恢复出系统的设计与需求信息。
- 软件再工程：在逆向工程的基础上，对遗留系统进行重构，得到更完善的实现。其重点是对文档、代码和全局变量的理解与重构。
- 软件设计的借鉴和复用，也是软件再工程的重要组成部分。
10 AI 驾驭工程（AI Harness Engineering）
10.1 打好地基，避免返工
- 把想法聊清楚
- 让AI把聊天内容整理成产品需求文档PRD
- 确定技术栈和架构
- 设置Git版本管理
10.2 高效协作，小步快跑
- 先做MVP，小步迭代
- 勤用git commit存档点
- 先规划，后编码
11 结语
这门课程带给我的最大改变，是从"埋头编码"转向"站高一层看系统"：先想清楚再动手，过程可控、质量可管、进度可视。从需求到设计、从过程到管理，软件工程提供的是一套系统性思维；而这套思维与 Cursor 等 AI 编程工具相结合，正是当下工程师的核心竞争力。
