声明：本文内容是对zst账号所讲的往年常考知识点的汇总，若喜欢看视频学习可移步b站

概念题偏多，分值占比：10分以上

一、软件过程

1、CMM（能力成熟度模型）

• 将软件过程分为5个成熟度级别（及对应常出现的词）
  • 初始级-依赖个人努力
  • 可重复级-有必要的准则
  • 已定义级-文档化、标准化
  • 已管理级-软件过程和产品质量
  • 优化级-反馈、新观念、新技术、持续改进

2、CMMI（能力成熟度模型集成）

• 提供了两种表示方法，分别是阶段式模型和连续式模型
• 阶段式模型有5个成熟度等级（没考过）
  • 初始的-过程不可预测且缺乏控制
  • 已管理的-过程为项目服务
  • 已定义的-过程为组织服务
  • 定量管理的-过程已度量和控制
  • 优化的-集中于过程改进
• 连续式模型-6个等级（0~5）
  • 未完成的-未执行、未得到
  • 已执行的-目标：输入->输出
  • 已管理的-已管理的过程的制度化
  • 已定义级的-已定义的过程的制度化
  • 定量管理的-可定量管理的过程的制度化
  • 优化的-改变、优化、满足客户要求的改变、持续改进

二、软件过程模型

1、瀑布模型

• 关键词：需求明确（二次开发也算）、不适合超大规模
• 某些需求明确则代表需求不明确、可能发生变化则代表需求不明确
• 此模型是最适合需求明确的

2、V模型

• 瀑布模型的变体（和瀑布模型一起出现都是选择瀑布）

3、增量模型

• 融合了瀑布模型的基本成分和原型实现的迭代特征
• 关键字：需求明确、适合超大规模
• 特点：
  • 可快速交付
  • 开发由增量表示的小系统所承担的风险不大
  • 可以减少用户需求的变更
  • 第一个增量是核心产品、每个增量都有测试
  • 适合商业产品的开发
  • 有瀑布模型的所有优点

4、演化模型

• 应对不断演变的软件产品，即需求不明确

4.1  原型模型

• 关键字：需求不明确、不适合超大规模
• 可快速、低成本地构建原型
• 开始于沟通
• 为了有效地捕获系统需求

4.2  螺旋模型

• 关键字：需求不明确、适合超大规模、风险评估
• 此模型最适合超大模型
• 结合瀑布模型和演化模型
• 工作步骤
  • 制度计划
  • 风险分析
  • 实施工程
  • 用户评估

5、喷泉模型

• 具有迭代性和无间隙性（开发活动之间不存在明显的界限）
• 以用户需求为动力
• 以对象作为驱动的模型，适合于面向对象的开发方法
• 克服了瀑布模型不支持软件重用和多项开发活动集成的局限性
• 模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统

6、统一过程（UP）模型

14年之后就没考过了

• 定义了四个阶段
  • 起始阶段：专注项目的初创活动
  • 精华阶段：进行需求分析和架构演进
  • 构建阶段：关注系统的构建、产生实现模型
  • 移交阶段：关注软件提交方面的工作、产生软件增量

7、敏捷方法

7.1  极限编程（XP）

• 4大价值观：沟通、简单性、反馈和勇气
• 5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作（暂时没考过）
• 12个最佳实践：
  • ​​​​​​​计划游戏：快速制度计划、随着细节的不断变化而完善
  • 小型发布：系统的设计要能够尽早地交付
  • 隐喻：找到合适的比喻传达信息
  • 简单设计：只处理当前的需求，使设计保持简单
  • 测试先行：先写测试代码，然后再编写程序
  • 重构：重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求
  • 结对编程：效率低
  • 集体代码所有制
  • 持续集成：可以按日甚至按小时为客户提供可运行的版本
  • 每周工作40个小时
  • 现场客户
  • 编码标准
• 考点：
  • ​​​​​​​选项中不属于12个最佳实践的
  • 每个实践对应的概念

7.2  水晶法

• 水晶法认为每个不同的项目都需要一套不同的策略、约定和方法论

7.3  并列争求法

• 30天一次的迭代称为“冲刺”

7.4  自适应软件开发

​​​​​​​没考过

7.5  敏捷统一过程（AUP）

• 在大型任务上连续、在小型任务上迭代

三、需求分析

上午题只考了软件需求，时间多的可以看下

四、系统设计

4.1  概要设计

4.1.1  设计软件系统总体结构

考的次数较多，重点

• 考点：设计软件系统总体结构属于哪个阶段-答：概要设计阶段
• 要点：
  • ​​​​​​​将一个复杂的系统按功能划分成模块
  • 确定每个模块的功能
  • 确定模块之间的调用关系
  • 确定模块之间的接口（即模块之间传递的信息）
  • 评价模块结构的质量

4.1.2  数据结构及数据库设计-了解

4.1.3  编写概要设计文档

• 文档主要有：
  • ​​​​​​​概要设计说明书
  • 数据库设计说明书
  • 用户手册
  • 修订测试计划

4.1.4  评审-了解

4.2  详细设计

• 要点：算法设计

五、系统测试

• 要点：发现错误
• 系统测试阶段的测试目标来自于需求分析阶段
• 软件测试实际分为：单元测试、集成测试、确认测试和系统测试（后两个没考过）

5.1  单元测试

• 测试模块中的内部处理逻辑和数据结构，一般用白盒测试
• 主要检查的内容：模块接口、局部数据结构、重要的执行路径、出错处理和边界条件

5.2  集成测试

5.2.1  自顶向下集成测试

• 抽象到具体
• 不需要编写驱动模块，需要编写桩模块

5.2.2  自底向上集成测试

• 具体到抽象
• 不需要编写桩模块，需要编写驱动模块

5.2.3  回归测试

• 软件发生变更后，变更引起原来功能出现问题，需要回归测试

5.2.4  冒烟测试

5.3  测试方法

• 测试方法分为静态测试和动态测试，动态测试包括黑盒测试和白盒测试（白盒考的较多）

5.3.1  黑盒测试

• 常用的黑盒技术：等价类划分、边界值分析、错误推测和因果图（前两个重要）

1、等价类划分

• 分为有效等价类和无效等价类。在设计测试用例时，要同时考虑这两种等价类

2、边界值分析

• 当多个参数中存在多个参数输入不在边界内时，则不是好的测试用例

5.3.2  白盒测试

1、逻辑覆盖-重中之重

覆盖能力从弱到强

• 语句覆盖：被测试程序中的每条语句至少执行一次（此语句是非判断语句）
• 判定覆盖（分支覆盖）：每个判定表达式至少获得一次“真”值或“假”值
• 条件覆盖：每个判定语句中每个逻辑条件的各种可能的值至少满足一次
• 判定/条件覆盖
• 条件组合覆盖：满足条件组合覆盖一定满足判定覆盖、条件覆盖和判定/条件覆盖
• 路径覆盖

2、循环覆盖

3、基本路径测试

六、运行与维护知识

以背为主

• 系统可维护性的评价标准：可理解性、可测试性和可修改性
• 选项中说软件文档不好的就是不正确的

1、系统维护的内容及类型

• 系统维护主要包括硬件维护、软件维护（重点）和数据维护

1.1  软件维护

• 正确性维护：改正系统开发阶段已发生而系统测试阶段尚未发现的错误，占比17%~21%
• 适应性维护：使应用软件适用信息技术变化和管理需求变化而进行的修改
• 完善性维护：扩充功能和改善性能
• 预防性维护：为了改进应用软件的可靠性和可维护性

1.2  软件可靠性、可用性、可维护性

• 可靠性、可用性、可维护性是软件的质量属性，软件工程中，用0-1之间的数来度量
• 可靠性：一个系统对于给定的时间间隔内、在给定条件下无效运作的概率。可MTTF/(1+MTTF)来度量，其中MTTF为平均无故障时间
• 可用性：在给定时间点内，一个系统能够按照规格说明正确运作的概率。可以用MTBF/(1+MTBF)来度量，MTBF为平均失效间隔世家
• 可维护性：在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。用1/（1+MTTR）来度量，MTTR为平均修复时间

七、软件项目管理

1、软件项目估算

1.1  COCOMO模型

• 按其详细程度分为：
  • 基本COCOMO模型：静态单变量模型
  • 中级COCOMO模型：静态多变量模型
  • 详细COCOMO模型

1.2  COCOMOⅡ模型

• 被分为3个阶段性模型：
  • 应用组装模型-对象点
  • 早期设计阶段模型-功能点
  • 体系结构阶段模型
• 在模型层次结构中有3中不同的规模估算选择：对象点、功能点和代码行，功能点可以转换为代码行

2、进度管理

• 进度安排的常用图形描述：Gantt图（甘特图）和项目计划评审技术（PERT）图-了解

项目活动图

重点

3、软件配置管理

• 主要目标：变更标识、变更控制、版本控制、确保变更正确的实现、变更报告
• 主要内容：
  • 版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持
  • 软件配置标识、变更控制、版本控制、系统建立、配置审核、配置状态报告
• 配置数据库可分为：开发库、受控库和产品库

4、风险管理

• 软件风险的两个特性：不确定性和损失
• 风险的分类：项目风险、技术风险和商业风险

4.1  风险识别

• 风险条目检查表
• 风险因素：性能、成本、支持和进度

4.2  风险预测（风险估计）

• 预测风险技术：建立风险表
• 影响风险所产生后果的因素：风险的本质、范围和时间
• 风险显露度 = 风险发生的概率+风险发生时带来的项目成本
• 风险显露度可设定风险的优先级
• 评估风险：风险发生的可能性和风险发生所产生的后果

4.3  风险评估

• 风险参照水准：成本、进度和性能

4.4  风险控制

• 风险控制的目的：辅助项目组建立处理风险的策略
• 有效的策略必须考虑：
  • 风险避免-是最好的风险控制策略
  • 风险监控
  • RMMM计划

八、软件质量

• ISO/IEC9126软件质量模型

九、软件度量

MaCabe度量法

• 有向图的复杂性 = 边-节点+2
• 有向图的复杂性 = 闭合区域+1
• 度量软件复杂性的主要参数：功能点、对象点、代码行数