吉林大学软件工程课程速成（知识点速记）

吉林大学软件工程课程速成（知识点速记）

这部分只能说速成了，可以先大概看看有个印象，或者考前再看背一背。

这里面只包含核心问答题的部分。选择题（细节知识点）我是看了这个专栏
软件工程考试复习，作图题我是看了B站的这个专辑软件工程画图题，这里面缺少一个关键路径，是我们在数据结构拓扑排序里学过的，因此我是看的数据结构的讲解，但是具体的画图和软件工程来说有细微的差别，大家可以看PPT进行学习。我自己是软件工程专业的，学过UML，所以没有记UML的笔记（第十章）。

希望大家都取得好的成绩。

2023-12-11 因为要考试了，所以里面有很多关键的图由于CSDN导入图片的原因还没有插入成功，要是有时间了我会补进来的。

1 软件工程学概述

软件

1. 计算机系统中与硬件相互依存的另一部分。包含程序、数据、文档

程序：指令序列

数据：数据结构

文档：图文材料

1. 软件=逻辑实体（软件！=物理实体）⇒抽象性
2. 不存在磨损和老化，只存在由于修改而引起的退化

软件发展的三个时期

• 程序设计阶段（50-60）
• 程序系统阶段（60-70）
• 软件工程阶段（70-）

软件危机

软件在开发和维护过程中遇到的一系列重大问题

• 开发软件，满足日益增长的需求
• 维护数量不断膨胀的已有软件

产生软件危机的原因

• 软件自身逻辑性
• 软件复杂庞大
• 软件开发与维护中护士软件定义时期的工作
• 认为软件开发就是写程序并设法运行
• 轻视软件维护

软件危机和软件工程的提出

• 1968 NATO会议签署声明“软件工程”
• 软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

*软件工程的七条基本原理

B.W.Boehm在1986年提出

• 用分阶段的生命周期计划严格管理
• 坚持进行阶段评审
• 实行严格的产品控制
• 采用现代程序设计技术
• 结果应能清楚的审查
• 开发小组的人员应该少而精
• 承认不断改进软件工程实践的必要性

软件工程方法学

• 在软件生命周期全过程中使用的一整套技术方法的集合→方法学
• 三要素：过程，方法，工具
• 传统方法学&面向对象方法学
  • 传统方法学
    • 结构化泛型
    • 生命周期方法学

2 软件过程

软件过程

团队软件过程：过程定义了谁在什么时间如何做什么事情来达到一个确定的目的。

瀑布模型

• 文档驱动的模型
• 优点
  • 可强迫开发人员采用规范的方法（例如，结构化技术）
  • 严格地规定了每个阶段必须提交的文档
  • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
  • 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型
• 缺点
  • 要求用户不经过实践就可以提出完整准确的需求
  • 仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品
  • 将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况
  • 软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的。
  • “由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要

V模型

• 活动驱动的模型
• 优点
  • 本质是把瀑布模型中一些隐含的迭代过程明确出来，使开发活动和验证活动的相关性更加明显；
  • V模型使抽象等级的概念也更明显：所有从需求到实现部分的活动关注的是建立更多的系统详细表述，而所有从实现到交付运行的活动关注的是对系统的验证和确认。
• 缺点：和瀑布模型一样，都是对软件开发过程过份简单、理想化的抽象，对需求变化的适应性差。

快速原型模型

• 优点
  • 快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。原因如下
    原型系统已经通过与用户交互而得到验证
    开发人员通过建立原型系统已经学到了许多东西
  • 利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认；
  • 可以考虑结合瀑布模型，二者互补性强。用快速原型做为需求分析的一种技术，用于收集客户的真实需求，然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补。
• 缺点
  • 快速建立供给运行的模型，不可能想最终产品一样面面俱到
  • 只是模型而已

增量模型

• 优点
  • 适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况；
    能有计划地管理技术风险；
  • 每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能；
  • 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新的软件可能给客户带来的冲击。
• 缺点
  • 软件体系结构必须是开放的，使得每个新的增量构件能够无缝地集成到现有的软件体系结构中，增加了设计阶段的投入；
  • 本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立。需要开发人员协调这一矛盾。

螺旋模型

• 基本思想

  使用原型及其他方法来尽量降低风险。

• 四个步骤

  制定计划

  风险分析

  实施工程

  客户评估

• 优点

  • 螺旋模型是对瀑布模型的发展，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；
  • 由于引入风险分析等活动，测试活动的确定性增强了；
  • 螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视

• 缺点

  • 主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；
  • 只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；
  • 对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟。

喷泉模型

“喷泉”体现了面向对象软件开发过程迭代和无缝的特性

为避免使用喷泉模型开发软件时开发过程过于无序，应该把一个线形过程作为总目标；

3 可行性研究

可行性研究的路线

1. 分析和澄清问题定义
2. 导出系统逻辑模型
3. 探索若干种可供选择的主要解法
4. 对每种解法进行可行性研究
5. 为每种可行的解法制定一个粗略的实现进度

系统流程图

成本效益分析

第一步：估计开发成本、运行费用、经济效益

一律加沙生命周期为5年

考虑货币的时间价值 F=P（1+i）^n

4 需求分析

功能需求：应该做什么

非功能需求：设定约束

需求过程

定义：导出、确认、维护系统需求文档的一组结构化活动

• 需求提取
• 需求分析和协商
• 需求确认

数据流图的作用

• 交流信息的工具
• 分析和设计的工具
• 映射出软件结构

数据字典的作用

对数据流图中包含的所有元素的定义的集合

数据字典的组成

数据流、数据流分量、数据存储、处理

5 软件设计过程

分类

• 概要设计
  • 系统设计阶段
  • 结构设计阶段
• 详细设计

总体设计的步骤

1. 设想供选择的方案
2. 选取合理的方案
   1. 通常至少选取低成本，中成本，高成本的3种方案
3. 推荐最佳方案
4. 功能分解
5. 设计软件结构
   1. 结构设计
   2. 过程设计
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审

设计原理

• 模块
• 抽象
• 逐步求精
• 信息隐藏和局部化
• 模块独立性

耦合

非直接耦合→数据耦合→标记耦合→控制耦合→外部耦合→公共耦合→内容耦合

针对耦合的设计指导原则

• 尽量使用数据耦合
• 控制使用标记耦合和控制耦合
• 限制使用外部耦合和公共耦合
• 完全不使用内容耦合

降低耦合度的方法

• 根据问题特点，选择适当的耦合类型
• 降低模块接口的复杂性
• 把模块信息放到缓冲区
• 减少公共区，使之局部化
• 输入输出应局限在少数模块，不要分散在全系统

内聚

功能内聚→顺序内聚→通信内聚→过程内聚→时间内聚→逻辑内聚→偶然内聚

启发规则

• 改进软件结构提高模块独立性
• 模块规模应该适中
• 深度，宽度，扇入删除应该适当
• 模块的作用域应该在控制域之内
• 力争降低接口的复杂程度
• 设计单入口、单出口的模块
• 模块功能应该可以预测，避免对模块施加过多的限制

面向数据流的设计方法（SD）

1. 复查基本系统模型
2. 复查并精化数据流图
3. 确定数据流图具有变换特性还是事务特性
4. 确定输入流和输出流的边界，从而孤立出变换中心
5. 完成“第一级分解”
6. 完成“第二级分解”
7. 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化

6 详细设计

McCaBe方法缺点

• 对于不同种类的控制流的复杂性不能区分；
• 简单IF语句与循环语句的复杂性同等看待；
• 嵌套IF语句与简单CASE语句的复杂性是一样的；
• 模块间接口当成一个简单分支一样处理；
• 一个具有1000行的顺序程序与一行语句的复杂性相同。

7 编码

测试

测试是程序的执行过程，目的在于发现错误

• 一个好的测试用例在于能发现至今还未发现的错误
• 一个成功的测试是发现了至今未发现的错误的测试

测试的准则

• 所有测试都应该能追溯到用户需求。
• 应该远在测试开始之前就制定出测试计划 。
• 测试发现的错误中的80％很可能是由程序中20％的模块造成的。
• 应该从“**小规模”**测试开始，逐步进行“大规模”测试。
• 穷举测试是不可能的。
• 为达到最佳的测试效果，应该由独立的第三方从事测试工作

驱动程序和存根程序

• 驱动程序就是模拟一个“主程序”，接受测试数据，把这些数据传给被测试的模块
• 存根程序就是代替被测试的模块所调用的模块，做最少量的数据操作，印出对入口的检验或操作结果，把控制归还给调用它的模块

8 软件维护

维护困难的原因（问题）

• 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。
• 需要维护的软件往往没有合格的文档，或者文档资料显著不足。
• 当要求对软件进行维护时，不能指望由开发人员仔细说明软件。
• 绝大多数软件在设计时没有考虑将来的修改。
• 软件维护不是一项吸引人的工作。

软件维护过程

开始做组织工作

• 建立维护组织
• 确定提出维护申请的过程和评价过程
• 为维护申请规定标准化的事件序列
• 建立记录保管过程并规定复审标准

工程网络活动的四个参数

• 前置条件
• 持续时间
• 最终期限
• 结束点

9 软件项目管理

软件配置

通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致

软件配置项（sci）

为了配置管理而作为单独实体处理的一个工作产品或一段软件，简称SCI。软件过程输出的全部计算机程序、文档数据

配置管理聚集（CM聚集）

SCI的组合

版本

一个确定的时间点上，某个SCI或某个配置的状态

基线

已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。基线就是通过了正式复审的软件配置项。