学习目录

• 数据流图的基本概念
• 数据平衡原则
• 解题技巧
• 实战演练

1.1 题目

【问题1】 （3分）

根据【说明】，将图11-3中的E1～E3填充完整。

【问题2】 （3分）

图11-3中缺少三条数据流，根据【说明】，分别指出这三条数据流的起点和终点。（注：数据流的起点和终点均采用图中的符号和描述）

【问题3】 （5分）

图11-4中有两条数据流是错误的，请指出这两条数据流的名称，并改正。（注：数据流的起点和终点均采用图中的符号和描述）

【问题4】 （4分）

根据【说明】，将图11-4中P1～P4的处理名称填充完整。

• 核心总结：

  • 问题1：补充外部实体，从人物角色、组织机构、外部系统中找。
  • 问题2：补充缺失数据流，依据数据平衡原则和题目说明匹配。
  • 问题3：找出错误数据流并改正，注意父图与子图平衡、加工输入输出是否合理。
  • 问题4：补充加工名，找“动词+名词”结构。

1.2 问题1

根据【说明】，将图11-3中的E1～E3填充完整。

答案： E1:非信用卡客户；E2:信用卡客户；E3:银行。

1.3 问题2

图11-3中缺少三条数据流，根据【说明】，分别指出这三条数据流的起点和终点。（注：数据流的起点和终点均采用图中的符号和描述）

答案：​$E_1 \to P_0 : \text{信用卡申请表}$；$E_2 \to P_0 : \text{激活请求}$；$E_2 \gets P_0 : \text{交易信息}$。

1.4 问题3

图11-4中有两条数据流是错误的，请指出这两条数据流的名称，并改正。（注：数据流的起点和终点均采用图中的符号和描述

答案：

• 错误的数据流：

  • $E_1 \gets P_4 : \text{信用卡申请表}$
  • $P_3 \gets P_4 : \text{激活请求}$

• 修改正确：

  • $E_1 \to P_4 : \text{信用卡申请表}$
  • $E_2 \to P_3 : \text{激活请求}$

1.5 问题4

根据【说明】，将图11-4中P1～P4的处理名称填充完整。

答案： P4:信用卡申请；P3：信用卡激活；P2:信用卡客户信息管理；P1:交易信息查询。

2. 题目二

2.1 题目

阅读下列说明，回答问题1至问题4，将答案填入对应栏内。

【说明】

某医疗护理机构为老年人或有护理需求者提供专业护理，现欲开发一基于Web的医疗管理系统，以改善医疗护理效率。该系统的主要功能如下：

1. 通用信息查询。客户提交通用信息查询请求，查询通用信息表，返回查询结果。
2. 医生聘用。医生提出应聘/辞职申请，交由主管进行聘用/解聘审批，更新医生表，并给医生反馈聘用/解聘结果；删除解聘医生的出诊安排。
3. 预约处理。医生安排出诊时间，存入医生出诊时间表；根据客户提交的预约查询请求，查询在职医生及其出诊时间等预约所需数据并返回；创建预约，提交预约请求，在预约表中新增预约记录，更新所约医生出诊时间并给医生发送预约通知；给客户反馈预约结果。
4. 药品管理。医生提交处方，根据药品名称从药品数据中查询相关药品库存信息，开出药品，更新对应药品的库存以及预约表中的治疗信息；给医生发送“药品已开出”反馈。
5. 报表创建。根据主管提交的报表查询请求（报表类型和时间段），从预约数据、通用信息、药品库存数据、医生以及医生出诊时间中进行查询，生成报表返回给主管。

【问题1】 （3分）

使用说明中的词语，给出图1-1中的实体E1～E3的名称。

【问题2】 （5分）

使用说明中的词语，给出图1-2中的数据存储D1～D5的名称。

【问题3】 （4分）

使用说明和图中术语，补充图1-2中缺失的数据流及其起点和终点。

【问题4】 （3分）

使用说明中的词语，说明“预约处理”可以分解为哪些子加工，并说明建模图1-1和图1-2是如何保持数据流图平衡。

核心总结：

• 系统主要功能：通用信息查询、医生聘用、预约处理、药品管理、报表创建。
• 补充实体时关注：客户、医生、主管等人物角色。
• 补充数据存储时关注：通用信息表、医生表、医生出诊时间表、预约表、药品数据等。
• 补充加工名时关注：查询、聘用、审批、预约、开出药品、生成报表等“动词+名词”结构。

2.2 问题1

使用说明中的词语，给出图1-1中的实体E1～E3的名称。

答案： E1:客户；E2:医生；E3:主管。

2.3 问题2

使用说明中的词语，给出图1-2中的数据存储D1～D5的名称。

答案： D1:通用信息表；D2:预约表；D3:医生表；D4:医生出诊时间表；D5:药品库存表。

2.3.1 问题3

使用说明和图中术语，补充图1-2中缺失的数据流及其起点和终点。

答案：

• $P_4 \to D_2 : \text{更新预约表中的治疗信息}$
• $P_3 \to D_4 : \text{更新所约医生出诊时间}$
• $P_2 \to D_4 : \text{删除解聘医生的出诊安排}$
• $P_4 \gets D_5 : \text{相关药品信息}$

2.4 问题4

使用说明中的词语，说明“预约处理”可以分解为哪些子加工，并说明建模图1-1和图1-2是如何保持数据流图平衡。

正确答案：

• “预约处理”可以分解为：安排出诊、预约查询、创建预约、预约反馈。

• 如何保持数据流图平衡：

  • 即保持父图与子图之间的平衡：父图中某个加工的输入输出数据流必须与其子图的输入输出数据流在数量上和名字上相同。
  • 父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，而子图中组成的这些数据流的数据项全体正好是父图中的这一个数据流。

‍

• 父图与子图之间平衡是指任何一张 DFD 子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致。

• 如果父图中某个加工的一条数据流对应于子图中的几条数据流，而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流，那么它们仍然是平衡的。

2. 考点：子图内平衡

• 黑洞：加工只有输入没有输出。
• 奇迹：加工只有输出没有输入。
• 灰洞：加工中输入不足以产生输出。

‍

1.1 元素说明

|元素|说明|图元| |

1.1 补充实体

实体可能是：

1. 人物角色：如客户、管理员、主管、经理、老师、学生
2. 组织机构：如银行、供应商、募捐机构
3. 外部系统：如银行系统、工资系统、后台数据库（当要开发的是中间件时）

1.2 补充存储

存储的文字方面特征：“文件”、“表”、“库”、“清单”、“档案”。

• 核心总结：

  • 补充实体：从人物角色、组织机构、外部系统三个方向找。
  • 补充存储：看到“文件、表、库、清单、档案”等字眼，通常就是数据存储。

1.3 补充加工名

加工是用于处理数据流的，所以要补充加工名，可以把该加工涉及到的数据流在说明中标识出来，再在数据流名称所在的句子中，找“​动词+名词”的结构，分析是否可作为加工的条件。

“动词+名词”如：生成报告、发出通知、批改作业、记录分数等，当然这只是普遍情况，也有例外（“​名词+动词”），如物流跟踪、用户管理。

• 核心总结：

  • 补充加工名​：找“​动词+名词”结构。
  • 常见示例：生成报告、发出通知、批改作业、记录分数。
  • 例外情况：“​名词+动词”，如物流跟踪、用户管理。

2. 考点：利用数据平衡原则

2.1 补充数据流

1、数据平衡原则

• （1）顶层图与0层图对比，是否有顶层图有，但0层图无的数据流，或反之。
• （2）检查图中每个加工，是否存在只有入没有出，或只有出没有入，或根据输入的数据无法产生对应的输出的情况。

2、按题目说明与图进行匹配

说明中的每一句话，都能与图中有对应关系，当把说明中的实体与数据流标识出来之后，容易缩小对应范围，找出纰漏。

• 核心总结：

  • 补充数据流​：依据数据平衡原则和​题目说明与图匹配。
  • 数据平衡原则：检查父图与子图的数据流是否一致，检查每个加工是否存在黑洞、奇迹、灰洞。
  • 题目说明与图匹配：说明中每句话都应在图中有对应，标识实体和数据流后可缩小范围、找出纰漏。

2. 历年考试分布

学习目录

• 进度管理
• 成本管理
• 风险管理
• 沟通管理

• 项目估算​：主要是需要估算出所需的​成本、规模和工作量，而并不是对类型进行估算。

1.1 COCOMO II 模型

• 应用组装模型：

  • 对象点

• 早期设计阶段模型：

  • 功能点
  • 代码行

• 体系结构阶段模型：

  • 代码行

• 核心总结：

  • 项目估算的对象：成本、规模、工作量。

  • COCOMO II 模型分为三种：

    • 应用组装模型 → 用对象点估算。
    • 早期设计阶段模型 → 用功能点或代码行估算。
    • 体系结构阶段模型 → 用代码行估算。

2. 经典例题

2.1 题目一

题目： 工作量估算模型 COCOMO II 的层次结构中，估算选择不包括（ ）。

• A、对象点
• B、功能点
• C、用例数
• D、源代码行

【解析】

• 正确答案：C

• 解析说明：

  • 关于选项 C（用例数） ​：COCOMO II 模型的估算选择中​不包括用例数。用例数通常用于其他估算方法（如用例点估算），但不是 COCOMO II 的层次结构中的估算选择。

  • 其他选项说明：

    • A、对象点​：属于 COCOMO II 中应用组装模型的估算选择。
    • B、功能点​：属于 COCOMO II 中早期设计阶段模型的估算选择。
    • D、源代码行​：属于 COCOMO II 中体系结构阶段模型的估算选择，同时也出现在早期设计阶段模型中。

正确答案：C（用例数）。

• 基本概念：

  • 无主程序员团队（民主式团队）强调团队成员地位平等，没有绝对的技术专制或单一领导。
  • 团队成员之间需要进行高度的协作和​两两沟通。

• 核心公式（沟通路径计算） ：

  • 设团队总人数为 $n$，由于每两个程序员之间都需要建立一条沟通路径，因此总沟通路径数的计算公式为：
  • $Path = \frac{n(n-1)}{2}$ （即 $1 + 2 + 3 + \dots + (n-1)$ 的等差数列求和）

• 核心结论与考点总结：

  • 平方级增长：沟通路径数随团队人数 $n$ 的增加呈​平方级增长。
  • 成本剧增：随着团队规模扩大，沟通路径会呈爆炸式膨胀，导致协调成本过高、效率显著下降。
  • 适用场景​：该模式由于沟通开销大，​不适合大型团队，通常适用于小型、高凝聚力、需要深度技术探讨的攻坚团队。

2. 考点：有主程序员

• 基本概念：

  • 主程序员团队（主程序员制）设立一个核心的​主程序员（Chief Programmer） ，由其负责系统的大部分设计、核心编码和统筹协调工作。
  • 其他普通程序员围绕主程序员展开协同工作。

• 核心公式（沟通路径计算） ：

  • 沟通路径数：由于普通程序员之间通常不直接进行复杂的横向沟通，所有成员主要与主程序员单线联系，因此沟通路径数大幅减少。
  • 路径公式：若团队总人数为 $n$（1个主程序员 + $n-1$ 个普通程序员），则总沟通路径数为 ​**$n - 1$**。

• 核心结论与考点总结：

  • 线性增长：相比于无主程序员团队呈平方级增长 ($\frac{n(n-1)}{2}$) 的沟通成本，主程序员团队的沟通路径呈​线性增长（$n-1$）。
  • 优缺点：大大降低了沟通成本，提高了决策和开发效率；但对主程序员个人的技术与管理能力要求极高，容易产生“关键人风险”（主程序员离职或过载会导致项目瘫痪）。

3. 经典例题

3.1 题目一

题目： 在进行软件开发时，采用无主程序员的开发小组，成员之间相互平等；而主程序员负责制的开发小组，由一个主程序员和若干成员组成，成员之间没有沟通。在一个由 8 名开发人员构成的小组中，无主程序员组和主程序员组的沟通路径分别是（ ）。

• A、32和8
• B、32和7
• C、28和8
• D、28和7

【解析】

• 正确答案：D

• 解析说明：

  • 无主程序员组：

    • 成员之间相互平等，两两之间都需要沟通。
    • 沟通路径数为 $\frac{n(n-1)}{2}$。
    • 当 $n=8$ 时，$\frac{8 \times (8-1)}{2} = \frac{8 \times 7}{2} = 28$。

  • 主程序员组：

    • 由一个主程序员和若干成员组成，成员之间没有沟通。
    • 所有成员都只与主程序员沟通，沟通路径数等于成员数。
    • 当总人数为 8 时，主程序员 1 人，成员 7 人，沟通路径数为 $8-1=7$。

正确答案：D（28和7）。

• 示例：

|工作编号|工作名称|工作时间（M）|1|2|3|4|5|6|7|8|9|10| |

1.1 风险分类与特征

• 风险分类：

  • 项目风险
  • 技术风险
  • 商业风险

• 风险两大特性：

  • 不确定性
  • 损失性

• 风险管理关注点：

  • 关心未来
  • 关心变化
  • 关心选择

1.2 风险曝光度（Risk Exposure）

• 计算方法：风险出现的概率 × 风险可能造成的损失。

• 示例：

  • 假设正在开发的软件项目可能存在一个未被发现的错误，而这个错误出现的概率是 0.5%，给公司造成的损失将是 1000000 元。
  • $\text{风险曝光度} = 1000000 \times 0.5\% = 5000\ \text{元}$。

1.3 风险管理步骤

1. 风险识别
2. 风险预测
3. 风险评估
4. 风险控制

• 核心总结：

  • 风险分类：​项目风险、技术风险、商业风险。
  • 风险两大特性：​不确定性、损失性。
  • 风险管理关注：​未来、变化、选择。
  • 风险曝光度：​概率 × 损失。
  • 风险管理步骤：​识别 → 预测 → 评估 → 控制。

2. 经典例题

2.1 题目一

题目： 以下叙述中，（ ）不是一个风险。

• A、由另一个小组开发的子系统可能推迟交付，导致系统不能按时交付客户
• B、客户不清楚想要开发什么样的软件，因此开发小组开发原型帮助其确定需求
• C、开发团队可能没有正确理解客户的需求
• D、开发团队核心成员可能在系统开发过程中离职

【解析】

• 正确答案：B

• 解析说明：

  • 关于选项 B（客户不清楚想要开发什么样的软件，因此开发小组开发原型帮助其确定需求） ：

    • 这描述的是一种​应对措施或解决方案，而不是风险本身。
    • 风险指的是​可能发生的不利事件​（具有不确定性和损失性）。选项 B 中“开发原型帮助确定需求”是开发小组采取的​主动行动，目的是消除或降低风险，所以它不是一个风险。

  • 其他选项说明：

    • A、由另一个小组开发的子系统可能推迟交付，导致系统不能按时交付客户​：这是​项目风险，可能发生且会造成损失。
    • C、开发团队可能没有正确理解客户的需求​：这是​技术风险/项目风险，可能导致返工或交付失败。
    • D、开发团队核心成员可能在系统开发过程中离职​：这是​人员风险，属于项目风险，可能导致进度延误或知识流失。

正确答案：B（客户不清楚想要开发什么样的软件，因此开发小组开发原型帮助其确定需求）。

2.2 题目三

题目： 下列关于风险的叙述中，不正确的是（ ）。

• A、风险是可能发生的事件
• B、如果能预测到风险，则可以避免其发生
• C、风险是可能会带来损失的事件
• D、对于风险进行干预，以期减少损失

【解析】

• 正确答案：B

• 解析说明：

  • 关于选项 B（如果能预测到风险，则可以避免其发生） ​：说法不正确。风险具有​不确定性​，即使能够预测到风险，也​不能完全避免其发生​。预测风险的目的是为了提前制定应对措施，从而​降低风险发生的概率或减少风险带来的损失，而不是彻底避免。

  • 其他选项说明：

    • A、风险是可能发生的事件：正确，风险具有不确定性。
    • C、风险是可能会带来损失的事件：正确，风险具有损失性。
    • D、对于风险进行干预，以期减少损失：正确，风险管理的目的是减少损失。

正确答案：B（如果能预测到风险，则可以避免其发生）。

‍

核心作用：用于衡量计算机程序的逻辑复杂度。

1.1 核心计算方法

• 公式法：$V(G) = m - n + 2$

  • $m$：有向图中的有向弧数（边数）
  • $n$：图中的节点数

• 秒杀技巧​：​最小独立闭环数 + 1（考试中最推荐、最高效的计算方式）

1.2 避坑指南与注意事项

• 流程图转换：当把程序流程图转换为控制流图（节点图）时，若线条在途中相交，必须在相交位置补充一个节点，否则直接套用公式会导致计算错误。

2. 经典例题

2.1 题目一

【解析】

• 正确答案：C

• 解析说明：

  • 统计结点数 n​n​：图中节点编号为 1 到 10，共 n=10n=10 个节点。

  • 统计有向弧数 m​m：

    • 1 → 2
    • 2 → 3
    • 3 → 4
    • 4 → 5
    • 5 → 6
    • 6 → 7
    • 7 → 8
    • 4 → 10
    • 5 → 9
    • 9 → 6
    • 8 → 4
    • 共 m=11m=11 条有向弧。

  • 代入公式计算​：V(G)=m−n+2=11−10+2=3V(G)=m−n+2=11−10+2=3。

• 技巧验证：最小独立闭环数 + 1。

  • 图中有 2 个独立闭环：

    1. 4 → 5 → 6 → 7 → 8 → 4
    2. 5 → 9 → 6 → 7 → 8 → 4 → 5（与第一个共享部分路径，但独立闭环为 2 个）

  • 2+1=32+1=3，与公式计算结果一致。

正确答案：C（3）。

2.2 题目二

题目： 若用白盒测试方法测试以下代码，并满足条件覆盖，则至少需要（ ）个测试用例。采用 McCabe 度量法算出该程序的环路复杂度为（ ）。

int find_max (int i, int j, int k) {
    int max;
    if (i > j) then
        if (i > k) then max = i;
    	else max = k;
    else if (j > k) then max = j;
    else max = k;
}

第一组选项：

• A、3
• B、4
• C、5
• D、6

第二组选项：

• A、1
• B、2
• C、3
• D、4

【解析】

• 正确答案：第一空选 B，第二空选 D。

• 解析说明：

  • 第一空：满足条件覆盖，至少需要（ B ）个测试用例。

    • 题目要求满足​条件覆盖，即每个判定中的每个条件的真假取值都至少出现一次。

    • 代码中共有 3 个判定条件：

      1. 判定1​：​i > j
      2. 判定2​：​i > k
      3. 判定3​：​j > k

    • 需要让这 3 个条件的真假取值都出现。至少需要 4 个测试用例，例如：

      • 用例1：​i>j​ 为真，​i>k​ 为真（如 i=3, j=1, k=2）
      • 用例2：​i>j​ 为真，​i>k​ 为假（如 i=2, j=1, k=3）
      • 用例3：​i>j​ 为假，​j>k​ 为真（如 i=1, j=3, k=2）
      • 用例4：​i>j​ 为假，​j>k​ 为假（如 i=1, j=2, k=3）

    • 因此，至少需要 4 个测试用例。

  • 第二空：采用 McCabe 度量法算出该程序的环路复杂度为（ D ）个。

    • 根据右侧控制流图：

      • 节点数 n​n​：图中节点编号为 1 到 10，共 n=10n=10 个节点。

      • 有向弧数 m​m：

        • 1 → 2
        • 2 → 3
        • 3 → 4
        • 3 → 5
        • 4 → 6
        • 4 → 7
        • 5 → 8
        • 5 → 9
        • 6 → 10
        • 7 → 10
        • 8 → 10
        • 9 → 10
        • 共 m=12m=12 条有向弧。

      • 代入公式：V(G)=m−n+2=12−10+2=4V(G)=m−n+2=12−10+2=4。

    • 技巧验证：“最小独立闭环数 + 1”。

      • 图中有 3 个独立闭环：

        1. 3 → 4 → 7 → 10 → ...（经判定链回环）
        2. 3 → 5 → 8 → 10 → ...
        3. 3 → 4 → 6 → 10 → ...（与判定链构成闭环）

      • 3+1=43+1=4，与公式计算结果一致。

正确答案：第一空 B（4），第二空 D（4）。

‍

2. 历年考试分布

学习目录

• 软件工程概述
• 开发模型
• 开发方法
• 需求分析
• 系统设计
• 模块设计
• 人机界面设计
• 软件文档
• 软件质量保证
• 系统测试的基本原则
• 测试的阶段划分
• 测试的分类
• McCabe复杂度计算
• 系统维护

• 置于用户控制之下

• 减少用户的记忆负担

• 保持界面的一致性

• 核心总结：

  • 人机界面设计的黄金三准则：​用户控制、减轻记忆、界面一致。

经典例题

题目一

题目： Theo Mandel 在其关于界面设计所提出的三条“黄金准则”中，不包括（ ）。

• A、用户操纵控制
• B、界面美观整洁
• C、减轻用户的记忆负担
• D、保持界面一致

【解析】

• 正确答案：B

• 解析说明：

  • 关于选项 B（界面美观整洁） ​：Theo Mandel 提出的界面设计三条“黄金准则”是：​置于用户控制之下、减少用户的记忆负担、保持界面的一致性。“界面美观整洁”不属于这三条黄金准则。

  • 其他选项说明：

    • A、用户操纵控制：对应“置于用户控制之下”，属于黄金准则之一。
    • C、减轻用户的记忆负担：对应“减少用户的记忆负担”，属于黄金准则之一。
    • D、保持界面一致：对应“保持界面的一致性”，属于黄金准则之一。

正确答案：B（界面美观整洁）。

1.1 结构化方法（瀑布模型）

• 核心思想：用户至上，自顶向下，逐步分解（求精）。

• 核心特点：

  • 严格区分工作阶段：每阶段有明确的任务和结果。
  • 强调系统开发过程的整体性和全局性。
  • 系统开发过程工程化，文档资料标准化。

• 适用场景：需求明确、稳定的项目。

• 记忆总结​：结构化 = 瀑布模型，重文档、重阶段、自顶向下。

1.2 原型法

• 核心特点：更好的复用性。
• 适用场景：用户需求不清、需求经常变化，且系统规模不是很大也不太复杂的情况。
• 记忆总结​：原型法 = 快速构建、反复修改、需求不清时使用。

1.3 面向对象方法

• 核心思想：关键在于建立一个全面、合理、统一的模型。
• 阶段划分：分析、设计、实现三个阶段，界限不明确。
• 记忆总结​：面向对象 = 对象驱动、迭代无间隙、分析/设计/实现界限模糊。

1.4 对比总结

|开发方法|核心特点|关键词| |

• 阶段划分：

  • 定义阶段：包含软件计划、需求分析。
  • 开发阶段：包含软件设计、程序编码、软件测试。
  • 维护阶段：包含运行维护。

• 核心特点​：以文档作为驱动，适合于软件需求很明确的软件项目。

• 特点总结：

  1. 需求确定。
  2. IT类。
  3. 项目不大。

2. 考点：V模型

• 左侧开发阶段：

  • 需求分析
  • 概要设计
  • 详细设计
  • 编码

• 右侧测试阶段：

  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试

• 核心特点​：测试贯穿始终，确保需求实现，是瀑布模型的升级。

• 重点：明确每种测试的测试目标来源。

3. 考点：演化模型与原型模型

• 演化模型​：演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本，特别适用于对软件需求缺乏准确认识的情况。

• 原型方法​：比较适合于用户需求不清、需求经常变化的情况，当系统规模不是很大也不太复杂时，采用该方法比较好。

• 核心循环步骤：交流 $\rightarrow$ 快速计划 $\rightarrow$ 快速设计方式建模 $\rightarrow$ 构建原型 $\rightarrow$ 部署交付和反馈。

• 核心总结：

  • 演化总结：甲方项目很大，先做其中一部分。
  • 原型总结：甲方需求完全不清，从 0 开始做，初始版本往往摒弃。

4. 考点：螺旋模型

• 核心概念​：螺旋模型是瀑布模型和演化模型结合，加入了风险分析。

• 适用场景​：特别适用于庞大、复杂并且具有高风险的系统。

• 四个主要象限与活动：

  • 制定计划：决定目标、方案和限制。
  • 风险分析：评价方案、识别风险、消除风险。
  • 实施工程：开发、验证下一产品（包括需求确认、软件产品设计、详细设计、编码、单元测试、组装与测试、验收测试与验证等）。
  • 客户评估：提交线、评审、客户评估。

• 核心特点说明：螺旋模型沿着螺线旋转，每个循环（代表一个阶段或版本）都从制定计划开始，进行风险分析，然后实施工程开发，最后通过客户评估进入下一个循环，这使得开发团队能在早期阶段及时识别并控制项目风险。

5. 考点：增量模型

• 核心概念：将需求分段为一系列增量产品，每一增量可以分别开发，其中第1个增量往往是核心产品。
• 开发步骤：每一个增量均经历“分析 $\rightarrow$ 设计 $\rightarrow$ 编码 $\rightarrow$ 测试”的过程，随后将该增量交付客户（如增量1、增量2、增量3至增量n）。
• 核心总结​：项目规模很大时，采用先做核心模块的策略；核心模块能够得到充分测试，因此整体运行比较稳定。
• 对比注意：演化模型同样是先做一部分，但它没有像增量模型那样强制强调“优先开发核心模块”。
• 缺点： 模块大小划分是比较困难的。

6. 考点：喷泉模型

• 核心定义​：以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。

• 过程层次（从下到上） ：

  • 分析
  • 设计
  • 实现
  • 测试
  • 维护
  • 演化

• 模型特点​：迭代无间隙、并行、效率高。

• 记忆口诀：一口盐汽水喷到对象脸上。

7. 考点：RUP模型 (Rational Unified Process 统一过程)

• 核心特征（中心红圈） ：

  • 用例驱动
  • 以架构为中心
  • 迭代和增量

• 四大核心阶段：

  • 1、初始（Inception） ：

    • 确定项目范围和边界
    • 识别系统的关键用例
    • 展示系统的候选架构
    • 估计项目费用和时间
    • 评估项目风险

  • 2、细化（Elaboration） ：

    • 分析系统问题领域
    • 建立软件架构基础
    • 淘汰最高风险元素

  • 3、构建（Construction） ：

    • 开发剩余的构件
    • 构件组装与测试

  • 4、交付（Transition） ：

    • 进行 $\beta$ 测试
    • 制作发布版本
    • 用户文档定稿
    • 确认新系统
    • 培训、调整产品

8. 考点：敏捷方法

8.1 基本概念

• 总体目标：通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。

• 适用场景​：秉持“小步快跑”的思想，适合小项目小团队，用少的人，做大的事，追求利润最大化。

• 核心总结：体现在“快”大于“好”。

• 基本原则：

  • 短平快的会议
  • 小型版本发布
  • 较少的文档
  • 合作为重
  • 客户直接参与
  • 自动化测试
  • 适应性计划调整
  • 对子编程
  • 测试驱动开发
  • 持续集成
  • 重构

8.2 敏捷方法常见方法与特点：

|敏捷方法|特点| | :

• 保持模块的大小适中

• 深度、宽度适中

• 扇入、扇出系数要合理

• 模块的作用域应该在模块之内

• 功能应该是可预测的

• 高内聚、低耦合

• 核心总结：

  • 模块设计的目标是实现​高内聚、低耦合。
  • 设计时需注意：模块大小适中、深度宽度适中、扇入扇出合理、作用域在模块之内、功能可预测。

2. 考点：模块设计基本原则（高内聚，低耦合）

2.1 耦合类型与描述

|内聚类型|描述| |

• 动态测试（机器运行） ：

  1. 黑盒测试法（测试功能）
  2. 白盒测试法（测试结构）
  3. 灰盒测试法（黑白结合）

• 静态测试（纯人工） ：

  1. 桌前检查（现场检查）
  2. 代码审查（SVN服务器）
  3. 代码走查（边走代码边检查）

• 核心总结：

  1. 动态测试 = 机器运行，包含黑盒、白盒、灰盒测试法。
  2. 静态测试 = 纯人工，包含​桌前检查、代码审查、代码走查。
  3. 黑盒测试测功能，白盒测试测结构，灰盒测试是黑白结合。

1.1 黑盒测试法与白盒测试法

• 黑盒测试法：

  • 等价类划分
  • 边界值分析
  • 错误推测
  • 因果图

• 白盒测试法：

  • 基本路径测试

  • 循环覆盖测试

  • 逻辑覆盖测试

    • 语句覆盖
    • 判定覆盖
    • 条件覆盖
    • 条件判定覆盖
    • 条件组合覆盖
    • 路径覆盖

• 核心总结：

  • 黑盒测试法：等价类划分、边界值分析、错误推测、因果图。
  • 白盒测试法：基本路径测试、循环覆盖测试、逻辑覆盖测试。
  • 逻辑覆盖由弱到强：语句覆盖 < 判定覆盖 < 条件覆盖 < 条件判定覆盖 < 条件组合覆盖 < 路径覆盖。

2. 考点：黑盒测试

|方法|说明| |

• 单元测试：模块测试、模块功能、性能、接口等。
• 集成测试：模块间的接口。【自顶向下-桩模块，自底向上-驱动模块，三明治】
• 系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接。
• 确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试。
• 回归测试：测试软件变更之后，变更部分的正确性、对变更需求的符合性。

2. 经典例题

2.1 题目一

【解析】

• 正确答案：第一空选 C，第二空选 D。

• 解析说明：

  • 第一空：此测试采用了（ C ）测试策略。

    • 观察图（b）的测试顺序：

      • 先并行测试 ​A​（顶层）和 ​E、F、G（底层）；
      • 然后测试 ​B、E、F；
      • 再测试 ​D、G；
      • 最后测试 ​A、B、C、D、E、F、G。

    • 测试同时从顶层和底层两个方向推进，属于自顶向下和自底向上结合的测试策略，即三明治策略。

  • 第二空：该测试策略的优点不包括（ D ）。

    • 三明治策略结合了自顶向下和自底向上的特点，其优点包括：

      • 较早地验证了主要的控制和判断点（A正确）；
      • 较早地验证了底层模块（B正确）；
      • 测试的并行程度较高（C正确）。

    • D 不正确​：三明治策略既需要​桩模块​（自顶向下部分），又需要​驱动模块​（自底向上部分），因此​驱动模块和桩模块的编写工作量都比较大，而不是“较少的驱动模块和桩模块的编写工作量”。

正确答案：第一空 C（三明治），第二空 D（较少的驱动模块和桩模块的编写工作量）。

‍

1. 尽早、不断地进行测试
2. 程序员避免测试自己设计的程序
3. 既要选择有效、合理的数据，也要选择无效、不合理的数据
4. 修改后应进行回归测试
5. 尚未发现的错误数量与该程序已发现错误数成正比

2. 经典例题

2.1 题目一

题目： 以下关于软件测试的叙述中，不正确的是（ ）。

• A、在设计测试用例时应考虑输入数据和预期输出结果
• B、软件测试的目的是证明软件的正确性
• C、在设计测试用例时，应该包括合理的输入条件
• D、在设计测试用例时，应该包括不合理的输入条件

【解析】

• 正确答案：B

• 解析说明：

  • 关于选项 B（软件测试的目的是证明软件的正确性） ​：说法不正确。软件测试的目的是​发现软件中的错误，而不是证明软件的正确性。测试只能证明软件存在错误，不能证明软件没有错误。

  • 其他选项说明：

    • A、在设计测试用例时应考虑输入数据和预期输出结果：正确。测试用例应包括输入数据和预期的输出结果。
    • C、在设计测试用例时，应该包括合理的输入条件：正确。测试用例应包含合理的输入条件。
    • D、在设计测试用例时，应该包括不合理的输入条件：正确。测试用例也应包含不合理的输入条件，以检验系统的容错能力。

正确答案：B（软件测试的目的是证明软件的正确性）。

2.2 题目二

题目： 招聘系统要求求职的人年龄在20岁到60岁之间（含），学历为本科、硕士或者博士，专业为计算机科学与技术、通信工程或者电子工程。其中（ ）不是好的测试用例。

• A、20，本科，电子工程
• B、18，本科，通信工程
• C、18，大专，电子工程
• D、25，硕士，生物学

【解析】

• 正确答案：C

• 解析说明：

  • 关于选项 C（18，大专，电子工程） ​：这个测试用例有​两个部分不合规​——年龄 18 岁不符合（应≥20 岁），学历大专不符合（应为本/硕/博）。一个测试用例中同时包含多个无效条件，一旦测试失败，​不容易定位到底是年龄规则出错还是学历规则出错，不利于缺陷定位，因此它不是好的测试用例。

  • 其他选项说明：

    • A、20，本科，电子工程：年龄、学历、专业全部符合要求，属于有效输入，能验证正常流程，是合理的测试用例。
    • B、18，本科，通信工程​：只有年龄 18 岁​不符合，学历和专业均符合，只包含一个无效条件，便于定位缺陷，是好的测试用例。
    • D、25，硕士，生物学​：只有专业生物学​不符合，年龄和学历均符合，同样只包含一个无效条件，便于定位缺陷，是好的测试用例。

正确答案：C（18，大专，电子工程）。

1.1 可维护性的性能指标

• 可理解性
• 可测试性
• 可修改性

1.2 软件维护类型

• 改正性维护：

  • 指为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误，应当进行的诊断和改正错误的过程。
  • 关键词：​bug。

• 预防性维护：

  • 系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，通过预防性维护为未来的修改与调整奠定更好的基础。
  • 关键词：​程序员。

• 完善性维护：

  • 扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
  • 关键词：​用户。

• 适应性维护：

  • 指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
  • 关键词：​除开用户的第三方 。

1.3 核心总结：

• 可维护性的性能指标：可理解性、可测试性、可修改性。

• 软件维护类型：

  • 改正性维护 → 修 bug。
  • 预防性维护 → 程序员主动预防。
  • 完善性维护 → 用户提出扩充功能/改善性能。
  • 适应性维护 → 外部环境（第三方）变化导致。

1.1 基本概念

• 阶段划分：

  • 概要设计
  • 详细设计

• 核心原则与方法：

  • 抽象化
  • 自顶而下、逐步求精
  • 信息隐蔽
  • 模块独立（高内聚、低耦合）

• 核心总结：

  • 软件设计分为概要设计和详细设计两个阶段。
  • 设计过程中遵循：​抽象化、自顶而下逐步求精、信息隐蔽。
  • 最终目标是实现模块独立，即高内聚、低耦合。

1.2 概要设计

• 设计软件系统总体结构：

  • 采用某种设计方法，将一个复杂的系统按功能划分成模块；
  • 确定每个模块的功能；
  • 确定模块之间的调用关系；
  • 确定模块之间的接口，即模块之间传递的信息；
  • 评价模块结构的质量。

• 数据结构设计：

  • 此处宜使用​抽象的数据模型，详细阶段规定具体实现细节。

• 数据库设计：

  • 概念设计、逻辑设计 、物理设计（如数据项存储要求、存取方法、索引的建立等）。

• 编写概要设计文档：

  • 主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

• 评审。

• 核心总结：

  • 概要设计的核心是：​划分模块、确定功能、确定调用关系、确定接口、评价质量。
  • 数据库设计包含：​概念设计、逻辑设计、物理设计。
  • 最终产出：​概要设计说明书、数据库设计说明书、用户手册、修订测试计划，并经过评审。

1.3 详细设计

• 算法设计：

  • 对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块的处理过程的详细算法描述出来。

• 模块内数据结构设计：

  • 对模块内的数据结构进行设计。

• 数据库物理设计：

  • 对数据库设计进行​物理设计，即确定数据库的物理结构。

• 其他设计：

  • 代码设计、输入/输出格式设计、用户界面设计等。

• 编写详细设计说明书。

• 评审：

  • 对处理过程的算法和数据库的物理结构都要评审。

• 核心总结：

  • 详细设计的重点是：​算法设计、模块内数据结构设计、数据库物理设计。
  • 最终产出：​详细设计说明书，并进行评审。

1.4 结构化设计的任务与活动

• 概要设计（模块的外部设计） ：

  • 体系结构设计：定义软件系统各主要部件之间的关系。
  • 数据设计​：基于 E-R 图确定软件涉及的​文件系统的结构及数据库的表结构。

• 详细设计：

  • 接口设计（人机界面设计） ：软件内部，软件和操作系统间以及软件和人之间如何通信。
  • 过程设计​：系统结构部件转换成软件的过程描述。确定软件​各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

• 核心总结：

  • 概要设计 = 模块的外部设计，包含体系结构设计和​数据设计。
  • 详细设计 = 包含接口设计（人机界面设计） 和​过程设计。
  • 概要设计中的数据设计基于 E-R 图确定文件系统结构及数据库表结构。
  • 详细设计中的过程设计确定各组成部分内的算法及内部数据结构。

2. 经典例题

2.1 题目一

题目： 概要设计文档的内容不包括（ ）。

• A、体系结构设计
• B、数据库设计
• C、模块内算法设计
• D、逻辑数据结构设计

【解析】

• 正确答案：C

• 解析说明：

  • 关于选项 C（模块内算法设计） ​：模块内算法设计属于详细设计阶段的内容。详细设计会对每个模块进行详细的​算法设计，用图形、表格和语言等工具将每个模块的处理过程详细描述出来。因此，模块内算法设计不属于概要设计文档的内容。

  • 其他选项说明：

    • A、体系结构设计：属于概要设计的内容，定义软件系统各主要部件之间的关系。
    • B、数据库设计：属于概要设计的内容，包含概念设计、逻辑设计、物理设计。
    • D、逻辑数据结构设计：属于概要设计的内容，概要设计阶段会进行数据设计（如基于 ER 图确定文件系统结构和数据库表结构）。

正确答案：C（模块内算法设计）。

2.2 题目二

题目： 软件详细设计阶段的主要任务不包括（ ）。

• A、数据结构设计
• B、算法设计
• C、模块之间的接口设计
• D、数据库的物理设计

【解析】

• 正确答案：C

• 解析说明：

  • 关于选项 C（模块之间的接口设计） ​：模块之间的接口设计属于概要设计阶段的内容。概要设计的核心任务之一就是确定模块之间的调用关系和接口，即模块之间传递的信息。详细设计则聚焦于模块内部的实现细节，因此模块之间的接口设计不属于详细设计的主要任务。

  • 其他选项说明：

    • A、数据结构设计​：属于详细设计的内容，即对模块内的数据结构进行设计。
    • B、算法设计：属于详细设计的内容，对每个模块进行详细的算法设计，描述其处理过程。
    • D、数据库的物理设计：属于详细设计的内容，对数据库设计进行物理设计，即确定数据库的物理结构。

正确答案：C（模块之间的接口设计）。

2.3 题目三

题目： 在采用结构化开发方法进行软件开发时，设计阶段接口设计主要依据需求分析阶段的（ ）。接口设计的任务主要是（ ）。

第一组选项：

• A、数据流图
• B、E-R图
• C、状态-迁移图
• D、加工规格说明

第二组选项：

• A、定义软件的主要结构元素及其之间的关系
• B、确定软件涉及的文件系统的结构及数据库的表结构
• C、描述软件与外部环境之间的交互关系，软件内模块之间的调用关系
• D、确定软件各个模块内部的算法和数据结构

【解析】

• 正确答案：第一空选 A，第二空选 C。

• 解析说明：

  • 第一空：设计阶段接口设计主要依据需求分析阶段的（ A ） 。

    • 结构化开发方法中，需求分析阶段的核心产出是​数据流图（DFD） ，它描述了数据的流动和加工变换。设计阶段进行接口设计时，主要依据数据流图来划分模块和确定模块间的数据传递关系。
    • B 错误：E-R 图用于数据建模，主要面向数据库设计。
    • C 错误：状态-迁移图用于行为建模，主要面向实时/控制类系统。
    • D 错误：加工规格说明是对数据流图中加工的详细说明，不是接口设计的主要依据。

  • 第二空：接口设计的任务主要是（ C ） 。

    • 接口设计即人机界面设计，主要任务是描述​软件与外部环境之间的交互关系​，以及​软件内模块之间的调用关系。
    • A 错误​：定义软件的主要结构元素及其之间的关系，属于体系结构设计的任务。
    • B 错误​：确定软件涉及的文件系统的结构及数据库的表结构，属于数据设计的任务。
    • D 错误​：确定软件各个模块内部的算法和数据结构，属于​过程设计（详细设计）的任务。

正确答案：第一空 A（数据流图），第二空 C（描述软件与外部环境之间的交互关系，软件内模块之间的调用关系）。

‍

2. 考点：CMM模型 (Capability Maturity Model 能力成熟度模型)

• 1、初始级：杂乱无章，甚至混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用；成熟度最低。
• 2、可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
• 3、已定义级：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准过程。
• 4、已管理级：制定了软件过程和产品质量的详细度量标准。
• 5、优化级：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进；成熟度最高。

3. 考点：CMMI模型

3.1 CMMI阶段式模型

3.2 CMMI连续式模型：Capability Maturity Model Integration 能力成熟度模型集成

|等级CL|说明| | --|

• 开发文档（开发人员） ：

  • 可行性研究和项目任务书
  • 需求规格说明
  • 功能规格说明
  • 设计规格说明（包括程序和数据规格说明）
  • 开发计划
  • 软件集成和测试计划
  • 质量保证计划、标准、进度
  • 安全和测试信息

• 产品文档（用户） ：

  • 培训手册
  • 参考手册和用户指南
  • 软件支持手册
  • 产品手册和信息广告

• 管理文档（负责人） ：

  • 开发过程的每个阶段的进度和进度变更的记录
  • 软件变更情况的记录
  • 相对于开发的判定记录
  • 职责定义

• 核心总结：

  • 开发文档​：给开发人员看，涵盖需求、设计、开发计划、测试计划等。
  • 产品文档​：给用户看，涵盖培训手册、用户指南、产品手册等。
  • 管理文档：给负责人看，涵盖进度记录、变更记录、判定记录、职责定义等。

2. 经典例题

2.1 题目一

题目： 以下关于文档的叙述中，不正确的是（ ）。

• A、也是软件产品的一部分，没有文档的软件就不能称之为软件
• B、文档只对软件维护活动有用，对开发活动意义不大
• C、软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量
• D、质量文档对于发挥软件产品的效益有着重要的意义

【解析】

• 正确答案：B

• 解析说明：

  • 关于选项 B（文档只对软件维护活动有用，对开发活动意义不大） ​：说法不正确。文档在软件开发活动中同样具有重要意义。开发文档是开发人员之间沟通、协作和传递信息的依据，贯穿需求分析、设计、编码、测试等各个阶段。因此，文档不仅对维护活动有用，对开发活动也有重要作用。

  • 其他选项说明：

    • A、也是软件产品的一部分，没有文档的软件就不能称之为软件：正确，文档是软件产品不可或缺的组成部分。
    • C、软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量：正确，文档编制是开发工作的重要组成部分，工作量较大。
    • D、质量文档对于发挥软件产品的效益有着重要的意义：正确，高质量的文档有助于软件产品的使用、维护和效益发挥。

正确答案：B（文档只对软件维护活动有用，对开发活动意义不大）。

1.1 记忆口诀

• 功能：适准互安从
• 可靠：成熟容复容
• 易用：理解学操作
• 效率：时间资源优
• 维护：分析稳测改
• 移植：安装应致换

2. 经典例题

2.1 题目一

题目： 在ISO/IEC软件质量模型中，易使用性的子特性不包括（ ）。

• A、易理解性
• B、易学性
• C、易操作性
• D、易分析性

【解析】

• 正确答案：D

• 解析说明：

  • 关于选项 D（易分析性） ​：易分析性不属于易使用性的子特性，它属于可维护性的子特性之一。因此，易使用性的子特性不包括易分析性。

  • 其他选项说明：

    • A、易理解性：属于易使用性的子特性。
    • B、易学性：属于易使用性的子特性。
    • C、易操作性：属于易使用性的子特性。

正确答案：D（易分析性）。

2.2 题目二

题目： 在ISO/IEC 9126软件质量模型中，可靠性质量特性是指在规定的一段时间内和规定的条件下，软件维持在其性能水平有关的能力，其质量子特性不包括（ ）。

• A、安全性
• B、成熟性
• C、容错性
• D、易恢复性

【解析】

• 正确答案：A

• 解析说明：

  • 关于选项 A（安全性） ​：在 ISO/IEC 9126 软件质量模型中，安全性属于功能性的子特性，不属于可靠性的子特性。因此，可靠性的质量子特性不包括安全性。

  • 其他选项说明：

    • B、成熟性：属于可靠性的子特性，指软件避免由软件中错误而导致失效的能力。
    • C、容错性：属于可靠性的子特性，指软件在出现故障或违反指定接口的情况下维持规定的性能水平的能力。
    • D、易恢复性：属于可靠性的子特性，指软件在失效后重建其性能水平并恢复直接受影响数据的能力。

正确答案：A（安全性）。

‍

• 需求分析的任务：找出系统要实现什么功能。

• 需求的任务和需求的过程：

  • 问题识别，定位当前问题
  • 分析与综合，确定大致解决方案、功能方案
  • 编制需求分析文档，把功能方案记下来
  • 需求分析与评审，确保功能方案的可行性

• 结构化分析的结果：

  • 一套分层的​数据流图（功能建模）
  • 一本数据词典
  • 一组​小说明​（也称加工逻辑说明）
  • 补充材料​（ER图）

2. 考点：需求的获取和分类

• 需求的获取方法：

  • 收集资料
  • 联合讨论会
  • 用户访谈
  • 书面调查
  • 现场观摩
  • 参加业务实践
  • 阅读历史文档
  • 抽样调查

• 软件需求的分类：

  • 按层次分类：

    • 业务需求：整体全局
    • 用户需求：用户视角
    • 系统需求：计算机化

  • 系统需求进一步细分：

    • 功能需求
    • 性能需求
    • 设计约束

  • 按 QFD（质量功能部署）分类：

    • 基本需求：明示，常规需求
    • 期望需求：隐含
    • 兴奋需求：多余

• 记忆总结：

  • 获取方法：收集、讨论、访谈、调查、观摩、实践、文档、抽样。
  • 层次分类：业务 → 用户 → 系统，系统再分功能、性能、约束。
  • QFD 分类：基本（明示）、期望（隐含）、兴奋（多余）。

3. 考点：需求分析的产物

3.1 数据流图

3.1.1 数据流图各元素的含义

|元素|说明| |

与 软考·算法基础 的分工：软考部分面向上午场选择题的考点速记，本分类面向代码实现与推导细节，两者互为补充。

1. 算法设计策略总览

| 策略 | 核心思想 | 解的性质 | 典型问题 | 时间复杂度量级 | |

| 类别 | 含义 | |

分支限界法在问题的解空间树上搜索，但与回溯法的深度优先不同，它采用广度优先或最小耗费（最大效益）优先的策略扩展结点。每一个活结点只有一次机会成为扩展结点：一旦成为扩展结点，就一次性产生其所有儿子结点，并用限界函数估算这些儿子结点的上界或下界：

• 若某儿子结点的估值不可能产生比当前最优解更好的解，直接舍弃该子树；
• 其余儿子结点加入活结点表，等待被选取为下一个扩展结点。

2. 两种常见的活结点表组织方式

| 方式 | 数据结构 | 扩展顺序 | 特点 | |

把规模为 $n$ 的问题分解为 $k$ 个规模较小的相互独立的子问题，递归求解后再把子问题的解合并成原问题的解。

三个阶段：

1. 划分（Divide）：将原问题划分为若干规模更小的同类子问题。
2. 求解（Conquer）：递归求解各子问题；若子问题规模足够小（到达递归出口）则直接求解。
3. 合并（Merge）：将子问题的解合并为原问题的解。

2. 适用条件

• 问题可缩小到一定规模后容易直接求解；
• 问题具有最优子结构，即可以分解为若干规模较小的相同问题；
• 子问题的解可以合并为原问题的解；
• 各子问题相互独立，不包含公共子问题（否则应改用动态规划）。

3. 复杂度分析方法

分治法的时间复杂度满足递推式：

$$T(n) = aT(n/b) + f(n)$$

三种求解方式：

• 代入法：猜出解的形式，用数学归纳法验证。
• 递归树法：逐层展开，累加每层代价。
• 主定理（Master Theorem）：比较 $f(n)$ 与 $n^{\log_b a}$ 的量级：

| 情形 | 条件 | 解 | |

动态规划与分治法类似，都是把问题分解为规模更小的子问题。区别在于：分治法的子问题相互独立，而动态规划的子问题相互重叠——同一个子问题会在递归过程中被反复求解。动态规划把每个子问题的解记录在表中，需要时直接查表，从而把指数级的重复计算压缩为多项式级。

2. 两个基本要素

2.1 最优子结构（Optimal Substructure）

问题的最优解包含其子问题的最优解。这是能用动态规划求解的前提，也是写出递归关系式的依据。

证明思路：用「剪贴法（cut-and-paste）」反证——若子问题的解不是最优的，把它替换为最优子问题的解就能得到原问题更优的解，矛盾。

2.2 重叠子问题（Overlapping Subproblems）

递归求解过程中会反复遇到相同的子问题。若子问题互不重叠，则退化为分治法，用表反而浪费空间。

3. 两种实现方式

| 方式 | 方向 | 特点 | |