JMU20软件专业 软件工程（老师划重点）

JMU软件工程专业，不同学校不同专业不同老师都有可能导致考题方向的差异，所以仅供参考！

软件专业是直接告诉考什么，试卷范围没有出考纲，其他专业要用这个复习的话慎重。
每年画的内容也不一样，所以20级后面的同学复习的时候注意老师给的考纲，20和18的画的填空选择就不太一样。

填空题

1. 软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的工程。
2. 复杂性是“软件危机”的本质原因
3. 软件工程的3要素：方法、工具、过程。它们构成了一种层次化的技术
4. 结构化开发方法由结构化分析、结构化设计和结构化程序设计三部分有机组合而成。
5. 若干不同任务的集合——每一个集合都由工作任务、里程碑、交付物以及质量保证点组成——使框架活动适应不同软件项目的特征和项目组的需求(作用)。P29
6. 增量模型和瀑布模型之间的本质区别是: 瀑布模型属于整体开发模型,它规定在开始下一个阶段的工作之前,必须完成前一个阶段的所有细节；而增量模型属于非整体开发模型,它推迟某些阶段或所有阶段小的细节，从而较早地产生工作软件。
7. ⭐⭐软件过程成熟度是指一个特定的软件过程被显式地定义、管理、度量、控制和能行(按步骤执行)的程度。
8. CMM 分为5个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已定量管理级，五级为优化级
9. 软件项目管理就是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员 (People)、产品 （Product)、过程（Proeess ) 和项目(Project) 进行分析和管理的活动，这4个要素构成了软件项目管理的主要内容
10. ⭐⭐软件项目估算指估算软件开发过程中所花费的工作量及相应的代价。软件成本预测的直接目的是估算出成本和工作量,而其最终目的是为项目的过程和结果提供概率意义上的预测，同时可以用来改进软件过程。
11. 一般认为软件风险有3种类型，即项目风险、技术风险与商业风险
12. ⭐⭐风险管理过程划分为成4个相关阶段：风险识别、风险估计、风险规划和风险监控。
13. 系统论也可以说是一种方法论。系统论的基本思想方法就是：以所研究和处理的对象作为一个系统，分析系统的结构和功能，研究系统、要素、环境3者的相互关系和变动的规律性，并优化系统观点看问题。
14. 辅助测试模块分为两种，一种是驱动模块(Driver），另一种是桩模块(Stub）
15. 桩模块是作为被测模块所调用的子模块形式出现的
16. 驱动模块是模拟被测模块的上级，相当于被测模块的主程序。
17. IEEE 定义基线如下：“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步的基础，并且只能通过正式的变化控制过程的改变。”
18. 变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

选择题

1. ⭐⭐原型开发的思想来源于工程实践。快速原型（Rapid prototype Model）是利用原型辅助产品设计开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信和反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

2. 甘特图，也称为条状图，是在1917年由亨利·甘特开发的，其内在思想简单，基本是一条线条图，横轴表示时间，纵轴表示活动（项目），线条表示在整个期间上计划和实际的活动完成情况。P69

3. 软件质量保证是一个复杂的系统，它采用一定的技术、方法和工具，来处理和调整软件产品满足需求时的相互关系，以确保软件产品满足或超过在该产品的开发过程中所规定的标准。

4. 正式技术复审（Formal Technical Review,FTR）是一种由软件工程师进行的软件质量保证活动。P122

5. WBS是一个详尽的、层次的(从全面到细节)树形结构，由明确的可提交项目目标与为了完成项目需要执行的任务组成。WBS 的目的是识别项目中实际需要完成的工作。——WBS的意义
   

6. 一般而言，质量是一组固有特性满足要求的程度，是产品或服务满足规定或潜在需要的特征和特性的总和

7. 需求分析是分析员经了解用户需求，认真细致的调研分析，最终建立目标系统的逻辑模型，并写出软件规格说明书的过程

8. 软件设置的目的是发现软件的错误

9. 评价良构模块独立性的度量标准是耦合小，内聚大

10. Boehm把这两部分归结为“风险揭露”，用公式可以表示为 RE = P · C

11. 使用4种策略应对可能对项目目标存在消极影响的风险或威胁。这些策略分别是风险规避、风险转移、风险接受、风险减缓。

12. 风险减缓:风险减缓是指建立一种行动计划以阻止风险的发生或者是当风险发生时减少它对项目的影响。

13. 用例图描述了待开发系统的功能需求,它将系统看做**黑盒,**从外部执行者的角度来理解系统。

14. 传统的结构化方法设计的结果是模块结构图

15. 封装是把对象的属性和操作结合在一起构成一个独立的对象，其内部的信息对外部是屏蔽的

16. 汽车与发动机的关系是整体和部分的关系

计算题

IFP=SUM(个数*权重)=功能点总计数
FP功能点总计数值=IFP*(0.65+0.01*SUM(Fi复杂参数))

生产率=代码行数/PM工作量
生产率=NOP（新增节点数）/PM工作量

NOP=累加所有带权重对象实例*（100-可复用占比）/100
DROP(生产率)=NOP/PM
PM=NOP/DROP

L代码行数=P生产率*E工作量^1/3*td时间^4/3

BCWS,BCWP,BAC,ACWP

F是种值，P是现值，A每年收付金额

————黑图选自https://blog.csdn.net/qq_45034708/article/details/112062350

数学期望：Ex=SUM(pi*xi),pi是概率，xi是值
标准差：σ=sqrt((xi-EX)²*pi)

知道NOP怎么算，PRDS和NOP，PM的关系，两种求生产率这几个式子就ok了。

设计题

数据流图

• 数据流用 ——> 表示
• 加工用⚪表示
• 数据存储用双横线=表示
• 数据流外部实体用长方形 ⃞表示

画数据流的注意点：0层图只能有一个⚪，不能有数据存储

软件结构图

一般是将数据流图转换成软件结构图
基本就是最上一层一个系统，接下来第二层三个模块：输入模块，变换模块，输出模块

• 模块用方框 ⃞标记，方框中标明模块名称
• a模块箭头指向b模块表示a模块调用b模块
• 通信用小箭头，在调用箭头的边上，指明传送的数据内容和传送方向
• 判断调用用菱形
• 循环调用用弧形箭头表示

程序流程图

盒式N-S图

PAD图

判定树

判定表

是一个表格，显示条件和条件导致的动作集合。

逻辑覆盖

语句覆盖

每个执行语句至少执行一次，这些都是语句f

判定/分支覆盖

每个判定的所有结果至少出现一次

条件覆盖

要考虑到每个判定式所有条件，单不用考虑判定的结果

区分一下判定/分支覆盖和条件覆盖：比如a>1 or b>1，a=0，b=0一组为假，a=3，b=0一组为真，满足判定/分支覆盖但不满足条件覆盖，如果要满足条件覆盖还要考虑到b，比如a=0，b=0一组是假，a=3，b=3一组是真，满足条件覆盖。

满足条件覆盖不一定满足判定覆盖（rea：不用考虑判定的结果）

判定条件覆盖

既满足条件也满足覆盖

条件组合覆

每个判定条件结果中的所有可能组合至少出现一次
一个判定是有两个条件，构成四种组合2²，真真，真假，假真，假假

路径覆盖

流程图中每条路走一遍

用例图

• 用小人表示参与者，参与者不是人，而是指参与用例时担当的角色。
• 椭圆形表示用例，用例就是外部可见的系统功能，对系统提供的服务进行描述。
• 关系

• 泛化可以理解成父类子类，继承关系。子类指向父类
• 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。比如汽车换车，基本用例是换车，超时要罚钱，罚钱就是扩展用例。扩展用例指向基本用例（箭头上写<< extend>>）
• 包含关系用来把一个较复杂的用例表示的功能分解成较小的步骤。基本用例指向包含用例，包含是<< include>>。执行基本用例一定执行包含用例。

用例归约

用例编号，用例名称，用例概述，参与者，前置条件，后置条件，基本事件流，备选流，成功场景，失败场景（必写）

CRC建模卡片

UI类和后台系统类全部都不要！！

持久化建模

就是把类模型转化成e-r图