简介
本篇章为软考中级软件设计师“软件工程”科目的上篇核心内容精讲，系统覆盖以下重点模块：
- 软件过程与成熟度模型：深度剖析CMM 5级成熟度框架（初始级→优化级）与CMMI阶段式/连续式模型的差异，结合例题掌握过程改进核心逻辑。
- 经典开发模型：从瀑布模型、V模型到增量/原型/螺旋模型，详解各模型的适用场景、优势局限及典型考题解法（如喷泉模型的同步开发特性、统一过程的4阶段迭代）。
- 系统测试与维护：聚焦单元测试5大特征、集成测试策略（自顶向下/自底向上）、白盒测试6大覆盖准则，以及软件维护4大类型（纠错性/适应性/完善性/预防性），结合McCabe复杂度度量强化实战应用。
- 敏捷开发与新兴实践：解析极限编程（XP）的4大价值观、12项实践，对比水晶法、并列争求法的迭代管理差异。
通过知识点梳理+高频例题双轨制解读，助力构建软件工程全生命周期知识体系，精准突破考试重难点。
一、软件过程
功能成熟度模型（CMM）
- 5个成熟度级别
- 初始级
- 项目的成功依赖于一个人的努力和英雄核心人物的作用
- 可重复级
- 建立了基本的项目管理过程和实践来跟踪项目费用、进度、和功能特性
- 已定义级：
- 文档化、标准化、标准软件
- 已管理级：
- 产品质量
- 优化级：
- 加强了定量分析
- 例题1
- 例题2
- 例题3
- 例题4
能力成熟度模型集成（CMMI）
- CMMI提供了2种表示方法
- 阶段式模型
- 连续式模型
- 阶段式模型（了解）
- 5个成熟度等级
- 连续式模型---(6个过程能力等级)
- CL0（未完成的）
- 未执行、未得到
- CL1（已完成的）
- 输入转输出
- CL2（已管理的）
- 集中于已管理的过程制度化
- CL3（已定义的）
- 集中于已定义的过程制度化
- CL4（定量管理）
- 集中于定量管理的
- CL5（优化）
- 使用量化手段改变和优化
- 例题1
- 例题2
- 例题3
- 例题4
二、软件过程模型
瀑布模型
- 五个阶段
- 每完成一个阶段后，都会进行阶段评审和文档控制，对真个开发过程指导。
- 适用：
- 需求很明确的软件项目
- 优点：
- 容易理解，管理成本低
- 不足：客户必须能够完整，并且正确和清晰表达出他的需求。
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
- 例题6
V模型
- 是瀑布模型的一个变体
- 描述了质量保证活动和沟通，建模相关活动
增量模型
- 第一个增量是核心产品
- 客户对每个增量的适用和评估都作为下一个增量发布的新特征和功能
- 例如：一直迭代，给客户看后，直到成品完成
- 该模型是瀑布模型的一个变体，具有它的所有优点
- 优点：
- 第一个版本开发成本和时间快
- 开发风险不发
- 可以减少用户需求的变更
- 不足：
- 如果没有对用户变更要求规划，初始增量可能出现不稳定
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
- 例题6
演化模型
- 该模型是迭代过程模型
- 适用于：
- 对软件需求缺乏准确认识的情况
- 分类：
- 原型模型
- 螺旋模型
- 例题1
原型模型
- 适用性：
- 用户需求经常变化
- 系统规模不大也不复杂
- 目的：快速、低成本地构建原型，帮助用户确定需求
- 注意点：原型模型开始于沟通
- 例题1
- 例题2
螺旋模型
- 适用：
- 大规模软件
- 需要风险分析
- 庞大、复杂且高风险的系统
- 例题1
- 例题2
喷泉模型
- 是一种以用户需求为动力、以对象为驱动的模型
- 适用：
- 面向对象的开发方法
- 特征：
- 各个阶段没有明显的界限，开发人员可以同步进行
- 优点：
- 提高开发效率、节约开发时间
- 缺点:
- 各个开发阶段是重合的，在开发阶段需要大量的开发人员，不利于项目管理
- 例题1
- 例题2
- 例题3
统一过程（UP）模型
- 是一种用例和风险驱动，以架构为中心，迭代并且增量的开发过程
- 4个阶段
- 4个阶段的重要里程碑
- 扩展题1
- 扩展题2
- 例题1
- 例题2
- 例题3
敏捷方法（5种）
极限编程
- 由4个组成：价值观、原则、实践、行为
- 4大价值观：
- 沟通、简单性、反馈、勇气
- 5大原则：
- 快速反馈 、简单性假设、逐步修改、提倡更改和优质工作。
- 12个最佳实践
水晶法
- 水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。
并列争求发
- 30天一次的迭代为一个冲刺。
自适应软件开发（了解） 
敏捷统一过程
例题
- 题1
- 题2
- 题3
- 题4
- 题5
结对编程实例图：
两个人使用一台电脑进行开发
- 题6
- 题7
- 题8
- 题9
三、需求分析
1. 软件需求
- 例题1
- 例题2
四、系统设计
1. 概要设计
- 设计软件总体结构是概要设计的关键步骤
- 数据结构级数据库设计（了解）
- 编写概要设计文档
2. 详细设计
- 对每个模块进行详细的算法设计
3. 总结：
概要设计：总体结构
详细：算法
4. 例题
- 例题1
- 例题2
- 例题3
- 例题4
五、系统测试
1. 意义和目的
2. 九个测试原则
3. 例题
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
六、单元测试
- 别名：模块测试
- 在模块编写完成且无编译错误后九可以及进行
- 单元测试主要检查的5个特征
- 模块接口：保证数据可以正确流入、流出
- 局部数据结构
- 主要的执行路径
- 出错处理
- 边界条件
- 单元测测试的过程
- 例题1
- 例题2
七、集成测试
1. 自顶向下集成测试
- 是一种增量方法
- 记：不用编写驱动模块，需要编写桩模块
2. 自底向上集成测试
- 记：不用编写桩模块，需要编写驱动模块
3. 回归测试
总结：软件变更了，就要重新测试。
4. 冒烟测试（了解）
5. 例题
- 例题1
- 例题2
- 例题3
八、测试方法
- 分类
- 静态测试
- 以人工检测
- 例如：计算机辅助静态分析
- 动态测试
- 黑盒测试（功能测试）：
- 测试方法有：边界值分析、有效、无效等价类划分
- 白盒测试
- 例题1
- 例题2
- 例题3
- 例题4
九、McCabe度量法
重点公式：弧总数-结点总数+2
代码行数是度量软件复杂读的一个主要参数
- 例题1
8-7+2=3
- 例题2
10-7+2=5
- 例题3
- 注意：需要补起点结点或少算一条弧
11-9+2=4
- 例题4
十、白盒测试
- 别称：结构测试
- 原则
1. 逻辑测试
1.1. 语句覆盖
每条语句至少执行一次
例如：a=1,b=1,c=1
1.2. 判断覆盖
条件整体的真和假，都执行一次
例如：用例1：a=1,b=1,c=1
用例2：a=0,b=0,c=0
1.3. 条件覆盖
条件整体中的每个部分条件的真和假都执行一次
1.4. 判定/条件覆盖
条件的整体和部分条件的真假都执行一次
1.5. 条件组合覆盖
判定中条件的各种可能值的组合都至少出现一次
1.6. 路径覆盖
覆盖被测试程序中所有可能的路径
1.7. 例题
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
- 例题6
- 例题7
- 例题8
- 例题9
- 例题10
2. 白盒测试+McCabe度量法
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
3. 伪代码+白盒测试+McCabe度量法
- 示例1
- 示例2
- 示例3
- 例题1
- 例题2
- 例题3
十一、运行和维护
1. 系统可维护性的评价指标
- 可测试性
- 可理解性
- 可修改性
- 例题1
2. 维护与软件文档
- 文档是软件可维护性的决定因素
- 文档分为：
- 用户文档
- 系统文档
- 例题1
- 例题2
- 例题3
3. 软件文档
- 例题1
- 例题2
十二、系统维护内容
- 3类
- 硬件维护
- 软件维护（重点）
- 数据维护
软件维护（重点）
- 4个类型：
- 正确性维护
- 关键词：错误
- 改正开发阶段发生而测试阶段未发现的错误
- 适应性维护
- 为了适应某种变化
- 完善性维护
- 扩充功能，改善性能
- 预防性维护
- 为了改进应用软件的可靠性和和维护性
- 为了使用未来的软件、硬件环境的变化
- 例题1
- 例题2
- 例题3
- 例题4
- 例题5
- 例题6
- 例题7
- 例题8
- 例题9
- 例题10
- 例题11
- 例题12
- 例题13
十三、可靠性、可用性、可维护性
背：
- 可靠性、可用性、可维护性是软件啊的质量属性
- 软件工程中，用0、1之间的树来度量
- 例题1
- 例题2
选：B
- 例题3
- 例题4
十四、沟通路径
考题形式1（没有主程序员）
重点公式：（n-1）*n/2
4+3+2+1=10
考题形式2：（有主程序员）
公式：n-1
例题
- 例题1
(8-1)*8/2=56/2=28
- 例题2
- 例题3
十五、软件项目估算
COCOMO估算模型
记：
- 分类：
- 基本cocomo模型：
- 静态单变量模型
- 中级cocomo模型：
- 静态多变量模型
- 详细cocomo模型（了解）
COCOMOII模型
记 ：
- 分类
- 应用组装模型：
- 对象点
- 早期设计阶段模型：
- 功能点
- 体系结构阶段模型：
- 代码行
例题
- 例题1
- 例题2
- 例题3
- 例题4
