软件工程期末冲刺：以生命周期为主线，构建考点地图的高效复习法

期末周遇到软件工程，大多数人都会陷入同一种状态：教材翻了大半，PPT看到第三章就开始心不在焉，脑子里只剩“瀑布”“敏捷”“UML”几个词，真到考前两天才发现名词解释、简答、画图、计算全堆在一起，越背越虚。我当年备考这门课也崩溃过一次，后来花了个通宵把整门课从“知识点清单”改成“考点地图”，才算摸到门道。

作为一门典型的计算机专业核心课，软件工程考的根本不是谁背得细，而是谁能在有限时间内抓住主线。这条主线就是生命周期：从问题定义、可行性研究，到需求分析、设计、编码、测试，再到维护。过程模型、需求工程、UML建模、软件设计、软件测试、项目管理，全是挂在这条线上的分支。只要先把这条线立起来，后面无论是背概念还是做画图题，都会顺很多。这篇内容就是按这个思路整理出来的，适合考前突击型选手，也适合想拿高分的同学做一遍知识盲区自查。

1. 为什么软件工程考前“背了就忘”：先建立整门课的地图

1.1 软件工程不是“背多分”科目

不少同学把软件工程当成文科在复习，抱着教材从头到尾念一遍，念到后面忘了前面，等到做题发现：名词解释仿佛见过，简答题能扯两句，但选择题一做就错，应用题完全不会动笔。问题出在大家没有意识到，软件工程这门课的每一个知识点都不是孤立的。

比如“瀑布模型”这个概念，它不只是一个“阶段清晰、文档驱动”的定义。它前面连着软件危机的背景，后面连着为什么需求变更会带来高成本，再往后还要和原型模型、增量模型、螺旋模型放在一起对比。考试出题人设计选择题时，很少直接问“瀑布模型有哪些阶段”，更常见的是给出一个项目背景，问你该选哪种模型、这种模型的缺点是什么。如果只背概念，没有理解知识点之间的联系，题目稍微换个说法就不会了。

所以复习软件工程的第一原则：先理解，再背诵。理解的重点不是每个字，而是“这个模型解决什么问题”和“当时为什么提出它”。

1.2 一张覆盖所有考点的知识主干

软件工程速成最有效的方式，是把所有考点挂在一张树上。你可以不用画出来，但心里必须清楚：

• 软件危机：为什么要引入工程化思想？危机原因和表现是什么？
• 软件生命周期：开发一个软件要经过哪些阶段？
• 过程模型：瀑布、原型、增量、螺旋、统一过程、敏捷，怎么选？
• 需求工程：做什么？怎么做需求分析？UML里哪些图最关键？
• 软件设计：结构化设计中的内聚和耦合，面向对象设计中的SOLID原则。
• 软件测试：白盒黑盒、单元集成系统验收测试，测试用例怎么设计。
• 软件维护与项目管理：四类维护、项目估算、关键路径、CMMI等级。

这七大块基本就是绝大多数《软件工程》期末试卷的命题范围。把主干记清楚之后，剩下的事就是往分支里填细节。

1.3 先搞清楚出题人喜欢怎么考

虽然每个学校、每个老师的出题风格不一样，但软件工程期末题型高度相似，通常包含以下几种：

拿到试卷前，先做两件事：一是翻平时的作业题、小测题，老师课上反复强调的细节往往是重点；二是找同专业学长学姐回忆一下上一届题型，哪怕只有几句话也有参考价值。我复习时从上一届那里打听到有关键路径计算题，于是专门把这类题做了十道，结果考试果然考了极其相似的一道RUP风险评估思路。

2. 软件过程与生命周期模型：模型对比题的“题干定位法”

2.1 软件危机：所有过程模型存在的理由

软件危机不是指“写代码写到崩溃”这种个人状态，而是一个专业术语：在软件开发与维护过程中遇到的一系列严重问题。要记住它的四个典型表现：开发进度严重拖延；开发成本超出预算；软件质量达不到用户要求；维护极其困难甚至无法维护。

为什么会发生危机？教材上的原因通常包括：软件本身是逻辑实体，存在复杂度高、不可见的特点；项目规模变大后，个人作坊式开发无法应对；用户需求描述不清，后期频繁变更；以及缺少规范化的开发过程与文档管理。软件工程这门课就是针对这些原因提出的一套系统化解决思路，所以几乎所有过程模型都可以看作是“对软件危机的不同应对方式”。

这个知识点很容易出简答题，比如“什么是软件危机？产生原因有哪些？”答题时不要只写三点原因，最好先说定义，再展开表现和原因，最后补一句“软件工程正是为了解决软件危机而提出”，这样答案结构就完整了。

2.2 六个常见过程模型的核心逻辑和适用场景

过程模型是期末选择题和简答题的重灾区，复习时要抓住每个模型的“灵魂”。

• 瀑布模型：阶段自上而下，像瀑布一样不可回流。优点是阶段划分清晰、每阶段有明确文档；缺点是一旦需求变化或前期有偏差，后期很难纠正。适合需求明确、不易变更的小型稳定项目。
• 原型模型：先快速开发一个可运行的原型，让用户提前看到系统长什么样，再根据反馈迭代完善。适合需求不明确、用户说不清楚自己想要什么的场景。注意原型有两种走向：提交前抛弃的“抛弃型原型”，或者逐步演化为正式产品的“演化型原型”。
• 增量模型：把整个系统拆成一系列可独立交付的增量，每个增量都能交付一部分可运行功能，随着增量增多系统逐渐完整。适合需要早期部分交付、整体功能可以分批开发的项目，但要求系统架构具备良好扩展性。
• 螺旋模型：在瀑布模型每一轮迭代前后加入风险分析，一次迭代就是一圈螺线，每个周期都经过“制定计划—风险分析—实施开发—客户评估”四个象限。适合大型、复杂、高风险项目，是目前应对未知风险比较成熟的模型。
• 统一过程RUP：以用例驱动、以架构为中心、迭代增量开发。它把软件过程分为初始、精化、构建、移交四个阶段，各阶段可以有多次迭代。面试和期末都容易考，核心词是“用例驱动”和“架构中心”。
• 敏捷开发：与上面那些“重量级”过程相反，强调个体和互动高于流程和工具，可用软件高于详尽的文档，客户协作高于合同谈判，响应变化高于遵循计划。常见实践有极限编程XP、Scrum等。

为了好记，我自己的习惯是：瀑布一条路走到底，原型做出来先给用户看，增量分批交货，螺旋转圈做风险，RUP用例驱动架构成中心，敏捷直接拥抱变化。

2.3 模型选择题的三种问法不要再掉坑

观察近几年的题目，模型题通常有以下三种问法。

问法一：给一个项目特征，选择最合适的过程模型。比如“某客户需求模糊，希望尽快看到可运行版本”选原型；“项目规模大、风险高、容易出安全问题”选螺旋。这种题关键是抓题干形容词，看到“需求明确”优先瀑布，看到“需求变化快”优先敏捷，看到“高风险”优先螺旋。

问法二：判断模型阶段或特点。比如给出一句话“该模型强调通过风险分析降低不确定性”，这种只要把过程模型名称和核心特点对应起来就能选对。

问法三：考多个模型的对比。比如简答题问“比较瀑布模型与原型模型的优缺点”。答题结构可以用“先分别写定义，再写适用场景，最后对比差异”：瀑布重视阶段性控制和文档，原型重视快速反馈和需求确认；瀑布在后期发现问题代价高，原型能较早暴露需求风险；但原型如果没有做好约束，容易导致系统结构混乱、后期难以继续维护。

复习过程模型时千万别把目光只放在“定义背熟”上，最好结合场景自己去想一遍：如果我是项目经理，用户需求一变再变，我选什么？想通了这种问题，选择题不管怎么绕你都能绕回来。

3. 需求分析老丢分？功能需求与非功能需求、UML图一次分清

3.1 需求工程流程：每一条都是简答题候选

软件需求是后续设计、编码和测试的基础，需求错了，后面改起来代价成倍增长，所以教材里常有一句话：需求分析是软件工程中最困难、最关键的一个阶段。

需求工程通常包括四步：需求获取、需求分析、编写软件需求规格说明书SRS、需求验证。每一步都有对应考点。需求获取的方法有哪些？访谈、问卷调查、原型法、观察用户工作流程、联合应用开发等。需求分析的目的是什么？分析出系统必须做什么，剔除不可能实现的需求，构建逻辑模型。需求验证的作用是什么？请客户和领域专家一起确认需求文档是否完整、一致、无歧义。

简答题问到“为什么软件工程强调需求分析”时，有一个非常关键的理由：错误修正成本随开发阶段迅速上升。需求阶段的错误如果拖到维护阶段才发现，修复成本可能是需求阶段的几十倍甚至上百倍，因为设计方案、代码、测试用例都要跟着改。

3.2 功能需求与非功能需求的判断技巧

需求分类是选择题和判断题的常客，掌握判断技巧后基本送分。

功能需求指系统提供什么功能，即“系统能做什么”。比如“系统支持用户登录”“系统根据库存数量自动生成补货单”“管理员可以删除违规评论”，这些都是功能需求。

非功能需求指系统实现功能的约束和品质，即“做到什么程度”。包括性能需求（系统并发用户数、响应时间）、可靠性需求（可用性指标）、安全需求（加密、权限）、易用性需求、可维护性、可移植性等。

考试经常给出一个句子让你判断：“用户登录时密码需要加密传输”看起来像功能需求，但它描述的是安全约束，应该算非功能需求；“系统高峰期每秒可以处理1000个请求”是性能需求，也属于非功能需求；“系统必须在一个月内开发完成”这类也常被人忽略，它属于开发过程中的约束/资源需求。所以在判断时，不要看句子里有没有动词，关键看它是在描述“系统动作”还是“系统品质”。

3.3 用例图、类图、时序图，分别想清楚再下笔

UML图的考点非常集中，期末没有必要把所有图都背一遍，重点先拿下以下三类。

用例图描述“谁”用系统“做什么”。三个组成要素要清楚：参与者是系统外部角色，用例是系统提供的一段功能，系统边界用来划分内外。用例之间的关系常考：包含关系include、扩展关系extend、泛化关系generalization。考试画用例图时，先把参与者列在边界外，把核心用例放进边界内，再连线；如果两个用例有公共动作，用包含关系把共用部分抽出来。

类图是面向对象分析的核心，要清点出候选类、类属性、类方法以及类与类之间的关系。类关系里最容易混的是聚合和组合。聚合是“整体-部分”关系，部分可以脱离整体独立存在，比如人和部门；组合关系更强，部分随着整体创建和销毁，比如订单与订单项。画类图时，类框分三层：类名、属性、方法；体现关系用不同的箭头和菱形。

时序图考察对象之间按时间顺序的消息传递。看到“登录过程完整时序”这类题，先画三个对象：用户界面、认证服务、数据库；再沿时间轴从上到下画生命线和激活条，消息箭头上写明方法名和参数。画完一定要检查每条“返回消息”有没有画反方向，很多同学在这里丢分。

3.4 SRS和需求变更：为什么平时不起眼，考试总爱出

软件需求规格说明书SRS的内容包括功能需求、非功能需求、外部接口、约束与假设等。它不仅是开发人员的依据，也是测试人员编写测试用例的依据和验收标准。如果把这门课的各种交付物排个优先级，SRS绝对排前两名。

需求变更管理是另一个必考小题。需求在项目全过程中都可能变化，但变化要受控。软件配置管理里有个概念叫“基线”，需求基线一旦确定，所有变更必须按照变更控制流程评审，不能今天改一下、明天又改回去，导致项目范围失控。这类题的答题思路是：变更需求、影响评估、提交变更控制委员会审批、修改SRS和相关文档、重新评审、通知相关人员，每一步都要落在文档上。

4. 内聚耦合与设计原则：结构化设计的“送分题”怎么全拿到

4.1 七种内聚：从最差到最好怎么判断

软件设计的目标之一是让每个模块“高内聚、低耦合”。高内聚指模块内部各个元素之间的关联紧密，共同完成一个功能；低耦合指模块与模块之间的联系简单清晰。听起来很简单，但考试一旦考到具体分类，很多人就开始猜。

内聚按强度由弱到强，记忆顺序是：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。每种都要能识别。

• 偶然内聚：模块内几条语句之间几乎没有关系，纯粹是“顺手”组合在一起，比如把几个函数里都用到的一个赋初值语句抽出来放一起。
• 逻辑内聚：模块里集合了多个在逻辑上相似但动作不同的功能，例如一个模块既能打印学生成绩表又能打印教师工资表，依靠传入的“报表类型”决定执行哪个。
• 时间内聚：模块内动作需要在同一时间段执行，典型例子是“初始化模块”，开机或程序启动时把所有初始化动作放一起。
• 过程内聚：模块内各处理动作有特定执行顺序，模块按这个顺序一步一步执行，例如先读卡再验证最后扣款。
• 通信内聚：模块内各动作使用同一输入数据或产生同一输出数据，例如“读入员工记录并更新工资、更新考勤”这些动作围绕同一份数据展开。
• 顺序内聚：前一个动作的输出直接作为后一个动作的输入，动作之间有传递关系，例如“读数据—处理数据—写数据”。
• 功能内聚：模块只做一件事且这件事是完整的，比如“计算个人所得税”，内部所有语句都为这一个目标服务，这是最理想的情况。

判断题和选择题通常会给你一个小例子，让你判断它属于哪种内聚。答题时可以优先找关键字：没有任何逻辑关系选偶然，靠参数选择不同逻辑选逻辑，集中在固定时间执行选时间，有执行顺序选过程，操作同一数据集选通信，前输出是后输入选顺序，单一职责选功能。

4.2 七种耦合：模块之间到底是好是坏

耦合由弱到强，一般可以记为：无直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。考试最爱考的是中间几种的判断。

数据耦合是最好的一种耦合方式：模块之间只通过参数传递普通数据，比如传递一个整数price给“计算税额”模块。标记耦合也叫特征耦合，传递的是数据结构而不是简单数据。比如A模块把整张Student结构体传给B模块，B实际上只需要Student里面的学号字段，这种结构会让两个模块都依赖同一个数据结构，耦合度比数据耦合高。

控制耦合是经常容易判断错的一种：一个模块把控制信号传给另一个模块，从而控制对方的执行流程。比如Admin模块调用报表模块时传入一个布尔值“按表格打印”，报表模块内部要根据这个参数走不同逻辑。这种耦合把“控制权”交了出去，模块不再完全独立，设计时应尽量避免。

公共耦合指多个模块共享同一全局数据区，优点是方便，缺点是一处修改可能影响所有使用该数据的模块，很难定位问题。内容耦合是最强也最差的一种耦合：一个模块直接访问另一个模块的内部数据或代码，比如模块B跳过模块A的接口直接改A的内部变量，这种情况要坚决禁止。

复习口诀可以这么记：无数据好，标记控制要小心，公共内容最要命。目标永远是“高内聚、低耦合”，但这个“低耦合”不是越低越好吗？不对，模块之间必须要有连接才能协作，完全没有耦合无法组成系统，数据耦合通常是可接受的最佳状态。

4.3 模块化设计中的经典术语和启发式规则

除了内聚耦合，软件设计部分还会考“模块化”“逐步求精”“信息隐藏”三个原则。模块化是把系统拆分为可独立开发和测试的模块；逐步求精是人类解决复杂问题的通用策略，先抽象后具体，层层细化；信息隐藏则要求每个模块只暴露必要接口，内部实现细节尽可能对外不可见，这样修改模块内部时不会波及其他模块。

程序结构图也有一批关键词：深度（结构图层次数）、宽度（同一层模块最大数量）、扇出（模块直接控制的下级模块数量）、扇入（直接控制该模块的上级模块数量）。设计启发式规则包括：保持模块规模适中；深度宽度不要失衡；模块的扇出不宜过大，一般控制在7左右；模块的作用范围要保持在其控制范围之内；降低模块接口复杂度；设计单入口单出口的模块。

其中“作用范围在控制范围之内”这句话很多人不理解。模块作用范围指一个模块内受某判定影响的所有模块，控制范围指该模块及其所有从属模块。如果作用范围超过了控制范围，意味着某个判断结果要影响一个“管不到”的模块，程序流程会变得难理解，修改一个判定可能引起连锁反应。

4.4 面向对象设计为什么反复强调SOLID

面向对象设计部分不会让你画特别复杂的东西，但设计原则经常进入选择题和简答题。记忆方式就用SOLID五个字母：

• S（单一职责原则）：一个类只应该有一个引起它变化的原因，职责越多，被修改的概率越大。
• O（开闭原则）：对扩展开放，对修改关闭。增加新功能时优先通过新增类实现，而不是改已有类的内部逻辑。
• L（里氏替换原则）：子类应该能替换父类并保持程序行为正确。简单说，能放父类的地方应该能放下它的子类。
• I（接口隔离原则）：不要强迫客户端依赖它不需要的接口。与其设计一个大而全的接口，不如拆成多个专用接口。
• D（依赖倒置原则）：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。常见的做法是依赖接口而不是依赖具体实现类。

除了SOLID，还有一个最少知识原则，也叫迪米特法则：一个对象应尽量减少对其他对象的了解，不要和“陌生人”说话。这个原则的目的是降低对象之间的耦合，在大型项目里维护起来会舒服很多。

5. 软件测试突击直击：白盒、黑盒、集成策略别再混为一谈

5.1 测试和调试不是一回事

测试经常被误认为“把程序跑一遍看看有没有报错”，实际上软件测试的定义要严格得多：测试是为了发现程序中的错误而执行程序的过程。它和调试最大的区别是，调试的目的是定位并修复已经发现的错误。

教材里有两句话非常出题：第一句是“测试只能证明程序中有错误，不能证明程序中没有错误”，这句话要写在“测试的目的是什么”这类简答题的开头；第二句是“成功的测试是发现了至今尚未发现的错误的测试”，既然测试是为了找错，那没找到任何问题的测试并不能说明程序优质，只能说明这个用例的设计不够有针对性。

5.2 测试阶段链路：单元、集成、系统、验收各有分工

软件测试和开发过程存在明显的“V”型对应关系。需求分析对应系统测试和验收测试，概要设计对应集成测试，详细设计对应单元测试，编码完成后先做单元测试，再逐步向上集成。

单元测试针对的是单个模块，重点测模块接口、局部数据结构、边界条件、独立路径和错误处理通路。集成测试要把模块装到一起，检查模块之间接口是否匹配、数据是否能在模块间正确传递。系统测试把整个软件系统放在真实或模拟环境中运行，检查功能、性能、安全性等是否达到SRS要求。验收测试由用户或客户参与，有时会采用Alpha测试和Beta测试，前者是用户在开发环境下测试，后者是用户在真实环境下测试。

选择题经常把这些阶段混在一起让你排序或判断。要注意：发现模块接口错误的阶段是集成测试，不是系统测试；验证软件是否满足用户需求的是验收测试，不是系统测试。

5.3 集成测试策略：桩模块和驱动模块到底怎么用

集成测试策略里最常考的是自顶向下和自底向上。

自顶向下集成从顶层的主模块开始，逐层向下加入子模块。问题是下层的模块还没写好，上层模块无法直接调用真实子模块，所以要写“桩模块”来模拟被调用的下层模块。桩模块接收上层传来的数据，按预期给一个返回值，方便先测试高层逻辑。

自底向上集成从最底层模块开始，逐层向上合并。底层模块比较容易找真实模块，但顶层模块还没开发出来，需要写“驱动模块”来模拟调用方。驱动模块要负责构造测试数据、调用被测模块、接收并显示结果。

一套集成方案究竟该用哪种？要结合项目结构判断。主模块逻辑复杂、接口稳定性差，可以用自顶向下，从整体流程往下验证；底层模块问题多，优先把底层打磨好，则适合自底向上。实际工程常采用混合策略，比如“核心模块优先”或“三明治集成”。

5.4 白盒测试：六种覆盖标准别只会背名字

白盒测试也叫结构测试，它是把程序看成透明的盒子，按照程序内部逻辑结构设计测试用例。覆盖标准从弱到强大致是：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

语句覆盖要求每条可执行语句至少执行一次，这是最低要求。判定覆盖又叫做分支覆盖，要求每个判定的“真”和“假”分支都至少经过一次，条件覆盖要求每个判定中的每个条件都取过真和假，判定/条件覆盖应该同时满足判定覆盖和条件覆盖，条件组合覆盖要求每个判定中条件的各种真假组合都至少出现一次，路径覆盖要求程序的所有可能路径都至少走一遍。

考试解题的过程通常是这样：先按代码画出流程图，给每个判断节点标号，然后一个个罗列“条件组合”，再尝试用最少的测试用例满足覆盖率要求。

这里有一个很多教材都会提的结论：满足路径覆盖不一定满足条件组合覆盖？要小心，路径覆盖最强是在“路径”维度，但路径覆盖往往并不要求覆盖所有条件组合，这两种覆盖方向维度不同，不能简单说谁包含谁。复习到具体代码题时，最好按流程逐步验证，不要凭常识判断。

5.5 黑盒测试：边界值分析为什么要测边界

黑盒测试又叫功能测试，不需要看代码内部，只依据规格说明书设计用例，重点看输入输出是否符合预期。最常用的三种方法如下。

等价类划分是把输入域划分成若干部分，认为同一部分里的不同输入有相似效果。有效等价类是能够代表需求的合理输入，无效等价类是非法输入。真正测试时两个方向都要考虑，因为程序不仅要正确处理正常输入，还要能优雅拒绝非法输入。

边界值分析是等价类划分的一种补充，专门针对边界附近的输入。原因是编码时最容易出错的往往不是“中间值”，而是“大于等于”“小于等于”这类边界判断。比如某个输入字段的有效范围是1到100，对边界值分析来说，至少要测0、1、100、101这四个值，顺带测一个50确认正常范围。

因果图法和决策表法适合输入条件较多、条件组合会影响输出结果的场景。考试如果看到“多个条件组合、不同组合对应不同动作”的描述，优先考虑决策表；看到“凭直觉和经验推测常见错误”则属于错误推测法。

6. 项目管理常考的画图与计算：关键路径和估算题的固定解法

6.1 项目估算：LOC、功能点、COCOMO模型考到什么程度

软件项目管理的计算题里，估算是一个常规考点。传统估算单位包括代码行LOC和功能点FP，代码行太依赖语言，功能点按用户可见功能计数，比如输入、输出、查询、内部逻辑文件、外部接口文件等。

COCOMO模型如果老师只讲了概念，你需要记住它的基本形态：工作量估算与软件规模（通常用可交付代码千行数KLOC衡量）成非线性关系，通常公式是E = a × (KLOC)^b，然后乘以若干调整因子。COCOMO的三种项目类型也要知道：组织型（小团队、需求简单，比如业务管理系统）、半独立型（中等规模，有一定约束条件）、嵌入型（软硬件强耦合、需求严格，比如实时控制系统）。

不同教材给出的a、b系数可能有差异，考试如果要求计算，都会直接把系数表给你或者考得非常基础，只要会用幂函数算数就行。真正的易错点是单位换算：题目给的是“2000行LOC”，代入公式必须是2个KLOC，不是2000。这种低级错误至少能吞掉一半分数，考场上一定要顺手写下单位。

6.2 关键路径法：手把手算一次，之后大概率丢不了分

很多同学看到进度管理题就放弃，其实关键路径法是项目管理计算题里性价比最高、套路最固定的题，拿下一道就能稳定涨分。

解题分三步走：先把活动列表画成有向网络图；然后“顺推”计算每个活动的最早开始时间和最早结束时间；再“逆推”计算每个活动的最晚开始时间和最晚结束时间；最后找到最早结束到最晚结束没有差额的活动，这些活动构成关键路径。

举个例子，一个项目有6个活动，依赖关系和工期如下：

顺推：A最早开始0，最早完成3。B最早开始3，最早完成8。C最早开始3，最早完成7。D最早开始8，最早完成10。E最早开始7，最早完成8。F有两个前驱D和E，它的最早开始必须等D、E都完成，所以是max(10,8)=10，最早完成13。项目最短工期是13天。

逆推算最晚时间：F最晚完成13，最晚开始10。D最晚完成10，最晚开始8。E最晚完成10？注意F最晚开始是10，所以E最晚完成必须不晚于10，其最晚开始=9。但这里E的工期是1，如果E最晚开始9、最晚完成10，还没影响F。继续逆推：B最晚完成必须等于D最晚开始8，因此B最晚开始3。C最晚完成必须等于E最晚开始9？E最晚开始9，所以C最晚完成9，最晚开始5。A是两个后驱的公共起点，A最晚完成时间必须同时满足B最早？这里的判断标准是A最晚完成=min(B最晚开始, C最晚开始)=min(3,5)=3，A最晚开始0。

总时差的计算简化：关键路径上总时差为0的活动有A、B、D、F。C总时差是2天，E总时差是1天。所以关键路径是A-B-D-F，工期13天。

考试很少要求把网络图画得多精致，关键是路径计算的过程要清楚。判断关键路径还有一个偷懒办法：把每条路径的工期累加，最长的那条就是关键路径，只有存在多条并行路径且时差计算比较复杂时才需要逐项逆推。题目问“某活动延迟几天不影响总工期”时，答案就是它的总时差。

6.3 PERT三点估算：期望时间和标准差公式别丢

除了确定性的工期，有些题目会给“悲观时间P、乐观时间O、最可能时间M”，让用PERT法估算期望工期。期望工期公式是(O + 4M + P) / 6，标准差是(P - O) / 6。这个公式在进度风险类题目里非常常见，平时只要亲手算过一遍就不会忘。

比如某活动乐观时间3天、最可能时间5天、悲观时间9天，那么期望工期=(3 + 4×5 + 9)/6=32/6≈5.33天，标准差=(9-3)/6=1天。按正态分布近似，工期落在期望值正负一个标准差的概率大约是68%。很多题会问“要在哪个时间前完成的把握最大”，本质上就是用期望加标准差来判断。

6.4 软件维护、配置管理和CMMI的速记包

软件维护虽然概念不难，但容易在最后选择判断里出题。四类维护分别是：校正性维护，修复发现的错误；适应性维护，让软件适应外部环境变化，比如操作系统升级、数据库版本更换；完善性维护，为了改善性能或增加改进功能，这是实际中占比最高的一类维护；预防性维护，为了防止未来问题而做的结构调整，比如重构。

软件配置管理SCM的核心是“版本控制+变更控制”。配置项包括代码、文档、数据等，基线是经过正式评审批准的配置项，对软件生命周期的开发进度非常重要。考试如果让写配置管理流程，思路是：配置标识、配置控制、配置状态报告、配置审计。

软件能力成熟度模型CMMI的五个级别：初始级、已管理级、已定义级、量化管理级、优化级。记忆时可以理解为从一个混乱的“能做就行”阶段，逐步走向可重复、可定义、可量化、可持续优化的过程。选择题最喜欢把“优化级”和“已管理级”的顺序打乱，注意CMMI最高级是优化级而不是量化级。

7. 48小时“冲刺三板斧”：从遍读教材到从容上考场

7.1 把考点清单当自测表刷，而不是反复看PPT

离考试只剩两天时，最忌讳的事情是打开PPT从第1章开始重新看。正确做法是拿一张纸，把我认为出现概率最高的80个考点写下来，然后逐个自问自答，能答出来的直接打钩，答不上来马上翻PPT定位。

我当时给自己列了一个速查表，分成三档：第一档是必须闭眼能写出来的概念，比如软件工程定义、软件危机原因、测试原则；第二档是必须能默画出对比表格的知识点，比如过程模型对比、白盒覆盖标准对比；第三档是必须能动手算的题，比如关键路径、PERT期望时间、等价类边界值用例。每晚睡前花15分钟把第一档的考点过一遍，坚持两天比熬夜看一整本教材都有效。

7.2 简答论述的“三步踩点法”拿稳基础分

软件工程考试批卷大多按点给分，简答题最怕写得又长又没踩到点。我总结出一个三步套路：先给定义，再分条展开，最后补场景或影响。

举一个高频题：“简述软件危机及其表现。”第一步写软件危机的定义，第二步分条写表现，比如进度超出预期、成本超出预算、质量难保证、维护困难，每条写成一句简短的话；第三步补一句“软件危机促使软件工程成为一门独立的学科”。三步写完，答案骨架完整。

再比如“为什么软件测试要在开发早期介入？”你的第一步可以说测试的目的是尽早发现错误，第二步说bug发现得越晚修复成本越高，第三步举具体场景，比如需求阶段错误到上线才发现，需要同时改代码、文档、测试用例，成本呈指数放大。这类题目只要让阅卷老师看到“尽早测试”“成本递增”两个关键词，分数不会差。

7.3 考场做题顺序和临场应急预案

考试不是必须按题号顺序做。我的习惯是先做会背的名词解释和填空题，这部分是稳定分，靠瞬时记忆就能拿到。选择题放中间做，画图题和计算题紧接着做，因为这类题型一旦思路断了下笔很难。最后留下的时间专门处理案例分析题和论述题，这类题不需要特别精确，关键是能迅速写满框架。

如果遇到一道画图题完全没有思路，不要空着。用例图不会画，至少把参与者和用例画出来；类图确定不了关系，至少把候选类列出来，注明哪些方法可能属于哪些类。软件工程的阅卷本身会找“答题点”，你哪怕只给出框架也有可能捞到一半分数。所以我的应急原则是：宁可写点沾边的，也不要白卷交上去。

最后再说一个亲测有用的技巧：进考场前，把最容易记混的模型特点和关键路径顺推逆推步骤写到草稿纸上，开考前快速扫一遍，不用背整段，只看“关键词开头”就能激活完整记忆。这门课能考多少分，拼的不是谁熬夜更狠，而是谁在考前把框架搭得清楚、把练习落在纸上。