针对于考研复试
软件工程
的面试问答,一般都是抽查重点的概念问题,所以本文对软件工程知识点进行重点的精炼,力求节省准研究生们的复习时间。
写这篇博客也是因为小编也在准备复试,对学习的网课进行笔记梳理,可以帮助自己更好的理清知识点。
相比于课件内容,我删减了很多非重点内容和冗余语句,力求内容的简洁和突出重点。
注意:不要过多在意知识点的全面性,先把重点掌握再说,老师面试提问也一般问一些 高频知识点 。
⭐表示必须掌握
;☆ 表示看情况掌握
;
408 考研复试 - 决战期
,复试速成笔记,导航🚥🚥🚥
- 🥬
数据结构与算法
考研复试速成 - 知识点精炼(加班中)
- 🥕
计算机网络
考研复试速成 - 知识点精炼- 🥪
操作系统
考研复试速成 - 知识点精炼- 🍊
计算机组成原理
考研复试速成 - 知识点精炼- 🍒
软件工程
考研复试速成 - 知识点精炼⇦当前位置🪂
- 🎨 408 全套初复试笔记汇总 传送门 🏃🏃🏃
本文配套资料
如果本篇文章对大家起到帮助的话,跪求各位帅哥美女们,
求赞👍 、求收藏 👏、求关注!👀
你必考上研究生!
我说的,耶稣来了也拦不住!😀😀😀
软件工程
第一章 软件工程概述
1.1 软件与软件危机 ⭐
1.1.1 软件
一、概念
答:软件是计算机系统中与硬件相互依存的另一部分,
软件 = 程序 + 数据 + 文档
- 数据:是使程序能够适当处理信息的数据结构。
- 程序:是能够完成预定功能和性能的可执行指令序列。
- 文档:是开发、使用和维护过程程序所需要的图文资料。
二、特点
答:
- ① 软件是一种逻辑实体。
- ② 软件开发过程复杂。
- ③ 软件需要长期维护。
- ④ 软件成本昂贵。
- ⑤ 软件可以复制。
1.1.2 软件危机
一、概念
答:
在计算机软件开发和维护过程中所遇到的一系列严重问题 。包含两方面内容:
- ① 如何开发软件,以满足对软件日益增长的需求;
- ② 如何维护数量不断膨胀的已有软件。
二、原因
答:
- ① 用户需求不明确;
- ② 缺乏正确的理论指导;
- ③ 软件开发规模越来越大;
- ④ 软件开发复杂度越来越高。
三、消除软件危机的途径
答:管理 + 技术,软件工程的出现来源于软件危机。
1.2 软件工程 ⭐
一、软件工程定义
答:
采用 工程 的概念、原理、技术和方法来开发与维护软件,包括: 开发管理 和 开发技术 两方面
目标:
- 付出较低的成本开发出可交付的软件;
- 较好的性能、易维护、可靠性高
二、软件工程方法学
答:
把在软件生命周期全过程中使用的 一整套技术方法的集合 称为方法学,也称为泛型。
软件工程方法学包括三个要素:方法、工具和过程
;
- 方法:完成软件开发各项任务的技术方法,回答 “怎么做”;
- 工具:为运用方法提供的自动或半自动软件工程支撑环境(基础);
- 过程:是为了获得高质量软件所需要完成的一系列任务框架,回答“何时做”。
三、软件工程方法学分类
生命周期方法学
面向对象方法学
1.3 软件生命周期 ⭐
1.4 软件过程 ⭐
软件过程:是为了获得高质量软件所需要完成的一系列任务框架。
通常用 软件生命周期模型 描述软件过程。
主要包括:
- 瀑布模型
- 快速原型模型
- 增量模型
- 螺旋模型
- 喷泉模型等
1.4.1 瀑布模型
将软件生存周期的各项活动 规定为 依照固定顺序连接的若干阶段工作,最终得到软件产品。
1.4.2 快速原型模型
快速建立可运行的程序,它完成的功能往往是最终产品功能的一个子集。
1.4.3 增量模型
先完成一个系统子集的开发,再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。
1.4.4 螺旋模型
在每个阶段之前都增加了风险分析过程的快速原型模型。看作增加了 风险分析 的 快速原型模型 。
1.4.5 喷泉模型
第二章 可行性研究
2.1 可行性研究 ⭐
一、可行性研究目的
用最小的代价在最小的时间内确定问题 是否 能够解决。
二、可行性研究实质
系统分析和设计过程的大大 压缩和简化 ,在 较高层次 上以较为抽象的方式进行系统的分析和设计过程。
三、可行性研究过程
① 分析和澄清问题定义。
② 导出系统的逻辑模型。
- 数据流图+数据字典
③ 根据逻辑模型探索若干种可供选择解法
④ 研究每种解法可行性。
- 经济可行性:经济效益是否大于开发成本
- 技术可行性:现有技术能否实现
- 操作可行性:系统操作方式是否可行
四、可行性研究内容 (步骤) ⭐
- ① 复查系统规模和目标
- ② 研究目前正在使用的系统
- ③ 导出新系统的高层逻辑模型
- ④ 进一步定义问题
- ⑤ 导出和评价供选择的解法
- ⑥ 推荐行动方针
- ⑦ 草拟开发计划
- ⑧ 书写文档提交审查
2.2 系统流程图 ☆
是一种描绘 物理系统 的图,用图形符号以黑盒子形式描绘 物理系统的各部件 ,表达数据在系统各部件之间流动的情况。而不是对数据进行加工处理的控制过程。
2.3 数据流图与数据字典 ☆
2.3.1 数据流图 DFD
描述 信息流和数据 从输入到输出过程所经受的变换。
没有任何具体物理部件,只是描绘数据在软件中流动和被处理的 逻辑过程 。
2.3.2 数据字典
一、概念
是关于数据的信息集合,即对数据流图中包含的所有元素定义的集合。
数据字典的内容:
- 数据流、数据流分量(数据元素)、数据存储、处理。
定义数据的方法:
- 由数据元素组成数据的方式:顺序、选择、重复、可选
二、数据字典用途
在软件分析和设计的过程中给人提供关于数据的描述信息。
- ① 作为分析阶段的工具;
- ② 估计改变一个数据将产生的影响;
- ③是数据库开发的第一步
第三章 需求分析
3.1 需求分析的任务 ⭐
需求分析:开发人员经过深入细致的调研和分析,准确理解用户和项目的功能、性能、可靠性等具体要求,将用户非形式的需求表述转化为完整的需求定义,从而确定系统必须做什么的过程。
基本任务:
- ① 确定对系统的综合要求
- ② 分析系统的数据要求
- ③ 导出系统的逻辑模型
- ④ 修正系统开发计划
3.2 分析建模与规格说明 ⭐
一、模型 ☆
是指为了理解事物而对事物做出的一种抽象,是对事物的一种无歧义的书面描述。
二、模型分类 ⭐
数据模型 (实体-联系图)︰描绘数据对象及数据对象之间的关系。
功能模型 (数据流图):描绘数据在系统中流动时被处埋的逻辑过程,指明系统具有的变换数据的功能。
行为模型 (状态转换图):描绘系统的各种行为模式在不同状态间转换的方式。
3.3 实体联系图、状态转换图 ☆
3.3.1 实体联系图 E-R图
3.3.2 状态转换图
第四章 总体设计 (概要设计)
4.1 概念 ⭐
把一个软件需求转换为软件表示时,首先是设计出软件总的体系结构,称为 概要设计 或 结构设计 。
任务:
- 完成软件结构的设计;
- 确定系统的模块及其模块之间的关系;
- 划分出物理元素。包括 程序、文件、数据库、文档 等。
4.2 设计过程 ☆
设计过程 包括 系统设计阶段 和 结构设计阶段
一、系统设计阶段
① 设想供选择的方案:数据流图出发,将处理分组抛弃行不通分组。
② 选取合理的方案:上一步方案选取低、中、高成本三种方案。
③ 推荐最佳方案:推荐最佳方案,制定详细实现计划
二、结构设计阶段
④ 功能分解:对数据流图进一步细化,进行功能分解。可以用IPO图等工具描述细化后每个处理的算法。
⑤ 设计软件结构:层次图或结构图描绘软件结构。或数据流图导出软件结构。
⑥ 设计数据库
⑦ 制定测试计划
⑧ 书写文档
⑨ 审查和复审
4.3 软件设计的基本原理 ⭐
一、模块化
模块
:能够单独命名,由边界元素限定的程序元素的序列,是构成程序的基本构件。
模块化
:把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求。
二、抽象
抽出事务的本质的共同特性,而暂时不考虑它们的细节。
三、逐步求精
逐步揭露出底层细节。
四、信息隐藏与局部化
信息隐藏:将模块的实现细节与数据隐藏起来。
五、模块独立
指每个模块只完成系统要求的独立的子功能。
衡量模块的理想的度量标准:耦合、内聚
软件设计目标:高内聚、低耦合
1. 耦合
又称为块内联系
,模块之间相互联系程度的程度,以 低耦合 为目标。
耦合性越高,模块独立性越弱。
耦合分类 (程度从低 -> 高):
无直接耦合 =>数据耦合 => 标记耦合(特征耦合) => 控制耦合 => 外部耦合 => 公共耦合
2. 内聚
又称为块间联系
,指模块内部各成分之间相互关联的程度,以 高内聚 为目标。
内聚分类(程度从低->高):
偶然内聚 => 逻辑内聚 => 时间内聚 => 过程内聚 => 通信内聚 => 顺序内聚 => 功能内聚
4.4 启发原则 ☆
1. 改进软件结构提高模块独立性
2. 模块规模应该适中
3. 深度、宽度、扇入和扇出应适当
- 深度:表示软件结构中控制的层数。
- 宽度:软件结构内同一个层次上的模块总数的最大值
- 扇出:一个模块直接控制(调用)的模块数目,扇出过大意味着模块过分复杂。一般一个设计的好的典型系统的平均扇出是3或4,扇出的上限是5到9。
- 扇入:指有多少上级模块调用它,扇入大说明上级模块共享该模块的数目多。好的软件结构顶层扇出比较高,中层扇出比较少,底层扇入到公共的实用模块中,即底层模块有高扇入。
4. 模块的作用域应该在控制域之内
- 作用域:指受该模块内一个判定影响的所有模块的集合。
- 控制域:是这个模块本身以及所有直接或间接从属于它的模块的集合。
5. 力争降低模块接口的复杂程度
6. 设计单入口单出口的模块
7. 模块功能应该可以预测
4.5 结构设计图像工具 ☆
一、层次图 + IPO图
二、结构图
4.6 结构化设计方法 SD ⭐
一、按数据流图分类
数据流图 (DFD) 一般可分为:变换流、事务流;
- 变换流:由 输入、输出、变化中心 三部分组成,是一顺序结构。
- 事务流:事务中心有多条路径,根据输入值来选择一个事务进行执行。
二、变换分析
把具有变换流特点的数据流图映射成软件结构。
第五章 详细设计
5.1 详细设计 ⭐
详细设计 目的 :
- 确定怎样具体地实现所要求的系统。得出对目标的精确描述。
详细设计 任务 :
过程设计
:即设计软件体系结构中所包含的每个模块的实现算法;数据设计
:设计软件数据结构;接口设计
:设计软件内部各模块之间的接口.
5.2 结构化程序设计 SP ⭐
基本要点:
- 采用
自顶向下、逐步求精
的程序设计方法;- 只用
三种基本的控制结构
就能实现任何 单入口、单出口 的程序;- 主程序员组的组织形式;
5.3 结构化程序分析 SA ⭐
一、概念
结构化分析
:面向数据流进行数据分析的方法。采用自顶向下逐层分解的分析策略。
- 顶层抽象地描述整个系统;
- 底层具体地画出系统工程的每个细节;
中间层则是从抽象到具体的过度。
二、使用的描述根据
使用 数据流图、数据字典 作为描述工具,使用结构化语言,判定表、判定树 描述架构逻辑。
三、步骤
- 了解当前系统的工作流程,获得当前系统的物理模型;
- 抽象出当前系统的逻辑模型;
- 建立目标系统的逻辑模型;
- 做进一步补充和优化。
5.4 详细设计的描述方法 (过程设计工具) ⭐
过程设计工具:描述程序处理过程的工具。
详细设计的描述方法有 图形、表格和语言 ,其中:
- 图形常用
程序流程图、盒图、PAD图 (问题分析图)
来作为工具;- 表格常用
判定表、判定树
来作为工具;- 语言常用
PDL 过程设计语言 (伪码)
来作为工具;
第六章 实现与测试
6.1 实现
软件生命周期的 编码 和 测试 统称为实现;
6.2 测试 ⭐
软件测试的目标:
软件测试 是为了发现错误而执行程序的过程。
- 编码阶段(单元测试)
- 测试阶段 (各种综合测试)
软件测试的方法 (技术):
黑盒测试法:将软件看作一个黑盒子,不考虑其内部结构和处理过程,只按照规格说明书的规定,测试软件是否能够正确接收输入数据,产生正确的输出数据。即测试程序是否正确的实现了其功能。又称为 功能测试 。
白盒测试法 完全知道程序的内部结构和处理算法,因此可以将程序看作一个透明的白盒子,根据程序内部的逻辑结构测试程序内部的主要执行通路是否能够按照预定的要求正确工作。又称 结构测试 。
软件测试的步骤:
- ①
单元测试 (模块测试)
:将每个模块作为一个单独的实体进行测试。发现的错误编码和详细设计阶段的错误- ②
子系统测试
:将模块集成为一个子系统进行测试。着重测试模块的接口。- ③
系统测试
:将子系统组装为一个完整的系统进行测试。子系统测试与系统测试总称为为 集成测试 。- ④
验收测试 (确认测试)
:在用户的参与下,往往使用实际的数据进行的测试。发现需求说明中的错误- ⑤
平行运行
:同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。
6.3 测试步骤 ⭐
6.3.1 单元测试
测试依据:
详细设计文档
测试技术 (设计测试用例的方法):白盒测试
着重点 (内容):
1. 模块接口
2. 局部数据结构
3. 重要的执行通路
4. 出错处理通路
5. 边界条件
6.3.2 集成测试
目标:
发现与接口有关的问题
实施者:独立的测试机构或第三方人员
集成方法:
- 非渐增测试
- 渐增测试:
自顶向下集成
:从主控模块开始,沿着程序的控制层次自顶向下移动,逐步添加新的模块;自底向上集成
:从最底层模块开始组装
自顶向下与自底向上相结合的方法:
- 上层模块使用自顶向下方法;
- 下层模块采用自底向上方法;
6.3.3 确认测试
又称
验收测试
,目标是验证软件的有效性。
- 验证 :为了保证软件 正确的实现了某个特定要求 而进行的一系列活动。
- 确认 :为了保证软件 确实满足了用户需求 而进行的一系列活动。
6.4 白盒测试 ⭐
测试用例:测试输入数据和预期的输出结果。
测试方案:测试目的、测试用例的集合。
1. 逻辑覆盖测试
:
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
- 路径覆盖
2. 控制结构测试
:
- 基本路径测试
- 条件测试
- 循环测试
6.5 黑盒测试 ⭐
黑盒测试 又称功能测试,着重测试软件的功能。
等价类划分法:
- 把程序的输入数据集合按输入条件划分为若干个等价类,每一个等价类相对于输入条件表示为一组有效或无效的输入。
- 为每一等价类设计一个测试用例。
边界值分析法:
- 输入等价类和输出等价类的边界就是应该着重测试的程序边界情况。
- 选取的测试数据应该刚好等于、刚好小于、刚好大于边界值
6.6 调试 ⭐
调试 (也称为纠错) ,是在测试发现错误之后排除错误的过程。
方法:
- 蛮干法;
- 回溯法;
- 原因排除法
结果:
- 找到了原因,然后改正和排除;
- 没找到原因,猜测一个原因,进行测试来验证假设。
6.7 软件可靠性 ⭐
软件可靠性:在给定 时间间隔内 ,按照规格说明书的规定成功运行的概率。
软件可用性:在给定 时间点 ,按照规格说明书的规定成功运行的概率。
第七章 维护
7.1 软件维护的概念 ⭐
软件维护的定义
答:
是在软件已经交付使用之后,为了 改正错误 或 满足新的需要 而修改软件的过程。
分类 (内容):
- 改正性维护:诊断和改正错误
- 适应性维护:适应软硬件环境
- 完善性维护:增加新功能、性能优化
- 预防性维护:提高可维护性与可靠性
软件维护的特点
答:
① 结构化维护与非结构化维护差别巨大
非结构化维护:惟一成分是程序代码,那么维护活动从艰苦地 评价程序代码 开始。
结构化维护:有完整的软件配置存在,那么维护工作从 评价设计文档 开始。
② 维护的代价高昂
③ 维护的问题很多
7.2 软件可维护性 ⭐
答:
软件被 理解、改正、优化 的难易程度。
决定因素:
- 可理解性:理解软件的难易程度;
- 可测试性:论证程序正确性的容易程度。
- 可修改性:程序容易修改的程度。
- 可移植性: 转移到另一计算环境的难易程度。
- 可重用性:同一个软件不做修改或稍加改动,就可以在不同环境中多次重复使用。
7.3 预防性维护与再工程过程
预防性维护也称为软件再工程,是为了提高未来的可维护性或可靠性,而主动地修改软件
第八章 软件项目管理
8.1 面向对象方法学概述 ☆
面向对象 = 对象+类+继承+通信
要点:
- 万物皆对象。
- 对象是对象类的一个实例。
- 类之间可以继承,子类继承父类的全部特性,又可以有自己的新特性。子类与父类形成类的层次结构。
- 对象之间通过消息传递相互联系。
8.2 面向对象建模 ⭐
模型:是一组图示符号和组织这些符号的规则,利用它们来定义和描述问题域中的术语和概念。
- ①
对象模型
:定义 做事情的实体,描述系统数据,定义 对谁做 ;- ②
动态模型
:描述系统控制结构,规定 何时做 ;- ③
功能模型
:描述系统功能,指明系统应 做什么 。
第九章
9.1 估算软件规模 ☆
软件项目管理:通过计划、组织和控制等一系列活动,合理地配置和使用各种资源,以达到既定目标的过程。
估算软件规模方法:
1. 代码行技术
根据以往开发经验和历史数据,估算实现一个功能所需源代码行数。
- 优点:代码是所有项目都有的 “产品”,容易计算代码行数。
- 缺点:源代码为软件配置的一个部分,用来衡量整个软件规模不太合理。不同语言实现同一软件所需代码行数不相同。
不适用于非过程语言。
2. 功能点技术
- 以
功能点(FP)
为单位度量软件规模
9.2 工作量估算 ☆
工作量估算模型:
- 静态单变量模型(基本的COCOMO模型)
- 静态多变量模型(COCOMO2模型)
- 动态多变量模型 (putnam模型)
工作量是软件规模的函数,工作量单位通常是人月(pm)
9.3 进度计划 ☆
甘特图 (Gantt图):是制定进度计划的工具,优点是能形象描述任务分解情况,直观简洁和容易掌握。
工程网络
9.4 人员组织 ☆
软件开发的人员组织方式:
- 民主制程序员组
- 主程序员组
- 现代程序员组
9.5 质量保障 ☆
软件质量:
- 软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”
软件质量保障措施主要有:
- 基于非执行测试 (复审或评审);
- 基于执行测试 (软件测试);
- 程序正确性证明(数学方法)
9.6 软件配置管理 SCM ⭐
软件配置管理 是在软件生命期内管理变化的一组活动,用来标识、控制、报告变化,确保适当的实现了变化。
基线 :通过了正式复审的软件配置项,可以作为进一步开发的基础,只有通过正式的变化控制过程才能改变它。
软件配置管理 5项任务:标识对象、版本控制、变化控制、配置审计和状态报告。
9.7 能力成熟度模型 CMM ⭐
能力成熟度模型 是用于评价软件机构的软件过程能力成熟度模型,用于帮助软件开发机构建立一个有规模的,成熟的软件过程。
五个等级从低到高:
初始级、可重复级、已定义级、已管理级、优化级
。