教材（据说很烂）：
本门课程的判断题对的居多（？还有这种操作）
# 第一章 软件工程背景知识
# 重点
- 软件的四个组成成分（等式）、组成成分的定义（PPT）
- 软件的特点（书上大标题，简答题）
- 软件的双重作用
- 软件工程的目标（一句话）
- 软件工程的七原则（大标题）
- IEEE 软件工程知识体系涵盖的十个方面（大标题）
- “缺乏有力的方法学的指导和有效的开发工具的支持，这往往是产生软件危机的原因之一。”
- 软件危机的表现（书上）
- PPT 上 Misunderstanding & Reality
- 软件工程中文档的作用是什么
- 提高软件开发过程的能见度
- 记录开发过程的有关信息，便于使用与维护
- 作为开发人员阶段工作成果和结束标志
- 提高开发效率
- 提供软件运行、维护、培训的有关资料
- 便于用户了解软件功能和性能
# 题
- 软件产品的开发主要是（研制）
- 软件是一种（逻辑产品）
- 软件工程的出现主要是由于（软件危机的出现）
# 第二章 软件过程模型
# 重点
- 软件过程模型的定义是什么？列举至少四种模型
- 定义补充：软件过程模型能直观表达软件开发全过程，明确规定要完成的主要任务、活动和开发策略
- 瀑布模型：线性、文档驱动
- 瀑布模型适用于 xx 情况
- 瀑布模型的特点（一二点背标题、三点全背）、缺点（全背）
- 螺旋模型：风险驱动
- 优缺点（全背）
- 增量模型：增量是可以运行的，程序的运行版本在早期就可以得到
- 优缺点、需要注意的问题
- 适用于软件需求不明确、设计方案有一定风险的软件项目
- 如何选择过程模型（PPT 背第三点）
- 软件工程以质量为中心，软件过程、方法和工具为三要素（工具不是过程模型）
- 软件生存周期分为几个阶段，每个阶段的提交x是什么
- 可行性研究、项目开发计划 -> 项目开发计划、可行性分析报告
- 需求分析 -> 软件需求说明书
- 概要设计 -> 概要设计说明书
- 详细设计 -> 详细设计说明书
- 编码 -> 源程序清单
- 测试 -> 测试报告
- 维护 -> 维护报告
- CMMI 五个级别的名字和侧重点
- 增量模型和螺旋模型的异同点？
- 相同：都是非整体的、迭代式开发方式
- 不同：
- 迭代层级不同：增量模型为活动级的迭代；螺旋模型是过程级的迭代
- 需求分析时间不同：增量模型常先做总体需求分析和设计，再编码和测试逐个增量包开发；螺旋模型在开发周期内采用瀑布模型
- 交付软件的方式不同：增量模型每次增量开发都在上一次增量的基础上提交新的一部分软件；螺旋模型每次迭代每次提交一个新的软件版本
- 减少风险的方式不同：增量模式通过避免使用未成熟的技术和经常的客户反馈等方法减少风险；螺旋模型则是直接引入风险分析
# 题
- 大多数软件系统不容易变化，除非他们在设计时考虑了变化（√）
- 目前的绝大多数软件都不适合快速原型模型（x，其实绝大多数适合）
- 下面按个选项不属于能力成熟度模型的级别（重复级、确定级、高效级√、优化级）
- （原型化方法）是用户和设计交换最频繁的方法
- 对增量模型，以下叙述错误的是（C） A. 使用增量模型开发软件时，把软件产品分解为一系列的增量构建来设计 B. 增量构建的开发可以采用瀑布模型 C. 第一个增量构建往往实现软件的高级功能 D. 采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计
- 常用的三种软件过程模型：瀑布模型、演化模型、增量模型
# 第三章 需求分析
# 重点
- 需求的定义（背）
- 功能性需求和非功能性需求的定义和区别（背，理解例子，列举五种非功能性需求）
- 需求分析的 4 个步骤的定义
- 需求分析的主要任务：PPT + 准确定义未来系统的目标，确定为了满足用户的需求，系统应该做什么，并用需求规格说明书规范的形式、准确地表达用户需求
- 结构化分析方法要建立哪三种模型，（以什么为核心），每个图分别对应哪种建模
- 数据流图的四种符号
- 数据流图中的每个加工至少有一个输入和一个输出
- 结构化分析方法的分析策略是（自顶向下、逐步求精）
- 讲过的图的名字（UML、部署图、顺序图（时序图）等）
- UML 中动态模型的描述工具：顺序图、活动图、状态图
- 用例图由哪些元素组成？主要用途？
- 元素：用例、参与者、关系、系统
- 用途：用于需求的获取、定义和分析
- UML 中什么是参与者？可以通过提出什么问题来明确参与者？（PPT）
- 谁或者什么。。。。。。
- 画用例图（注意可能有
include和extend） - 顺序图的组成元素：类、角色、生命线、对象、激活期、消息
- 用例图是显示一组用例、参与者、以及他们关系的图；用例图从用户的角度（而不是开发者）描述对软件产品的需求，分析产品所需的功能和动态行为
- 用例图的作用：用来对需求建模，用例图是至关重要的，他的正确与否直接影响了用户对最终产品的满意度
- 用例图的内容是：参与者、用例、泛化、扩展和 xxxx
# 题
- 数据流图的组成元素中，（数据流）用于描述数据处理所需的输入或输出
- 在 UML 图中，（顺序图）图用于描述为实现一个用例多个对象之间动态的交互关系，以及的对象的生存期
- UML 状态图可以用来描述多个对象之间的行为协作（×）因为顺序图是多个对象之间的 状态图是一个对象的
- 有效的需求变更管理需要对变更带来的潜在影响及可能的成本费用进行评估。（√）
- 需求分析和设计，在这两个阶段主要确定目标系统的（逻辑模型），不涉及软件的（物理实现）
- UML 状态图用于描述一个对象所能达到的所有状态以及引起状态改变的（事件）
- UML用例图中，（包含）用例是指经过封装后可以在各种不同的基本用例中复用的用例（但实际意思是被包含，这是答案的问题）
- 以下针对需求分析作用的描述中，错误的是（B） A. 使开发者和用户对需求达成一致 B. 使程序接口定义明确 C. 使开发工作有章可循 D. 使测试有理可依
- 如果使用增量模型，任何需求都可以很好控制（√）
- UML 活动图用于描述一个对象所能到达的所有状态以及引起状态转变的事件。（x）活动图没讲，其实是状态图
- 软件需求可以分为哪两类？软件需求过程包括哪几个阶段？
- 分类：功能、非功能需求
- 阶段：需求获取、分析、定义
- 出现软件缺陷的首要原因是 / 项目失败的首要原因是（B） A. 设计技术不成熟 B. 需求不清 C. 代码错误 D. 进度压力
- （B）这一活动开始时作为系统工程或业务过程的一部分，接下来作为软件需求分析的第一步。 A. 确定软件开发过程 B. 定义产品的目标和范围 C. 进行项目估算 D. 定义项目度量
- 如下图
- 成员方法是指向自己的
- 私有方法是
# 第四章 软件设计工程
- 软件设计包含两类主要活动：教材 45 页后，背下来
- 创新设计不属于软件设计（而是需求分析、需求定义的一部分）
- 模块划分不是划分越多越好（接口会变多，形成 U 形的）
- 简述模块化和软件成本的关系
- 模块的扇入数大好不好？什么情况下好/不好？
- 衡量模块独立的两个标准：内聚、耦合（分别表示什么含义）
- 独立性强的模块应该是（高内聚）、（低耦合）的模块
- 内聚、耦合的集中类型的定义和含义
- 顺序内聚那页 PPT 看一下（包括例子）
- 内部耦合那页 PPT
- 设计应该是（模块化的），换言之，软件应该在逻辑上划分为多个模块和子系统
- 结构化设计的基本思想：将系统设计成由相对独立、功能单一的模块组成的层次结构（√）
- 要去理解程序结构的深度、宽度、扇入数、扇出数
- 重构的定义 P50 4.3.7 第一段话最后引号内
- 设计 = 概要设计 + 详细设计
- 概要设计 = 体系结构设计 + 接口设计 + 数据设计
- 用户界面设计由一系列的分析开始（三种分析 背 PPT）
- 接口方面 = 内部接口 + 外部接口
- 外部接口 = 软件和硬件、其他软件的接口；软件和用户的接口
- 根据信息隐藏原则，模块……（P49 书上原话）
- 信息隐藏原则有利于提高模块的内聚性
- 五种架构风格：数据中心架构（包含黑板架构）、数据流架构、调用和返回架构、面向对象架构、层次架构
- 结构化程序定义：。。。。看 PPT
- 流程图的主要缺点 看 PPT 三点
- 体系结构的另一种分类：单主机结构（集中式体系结构）、分布式结构、（？）
# 第七章 软件测试技术
- 软件测试的基本原则（只背标题，但要理解意思）
- 软件测试的目标（7 条标题）
- 什么情况下叫发生了一个软件缺陷（5 点）
- 软件测试只能证明程序有错误，不能证明没有错误
- 软件测试的各个阶段只能有测试员而不能由程序员自己进行（×），模块测试可以
- 测试用例的定义（3 部分）
- 软件测试的评估准则（3 点，背名字）
- 覆盖率的定义？能否达到 100 %？为什么？
- 测试与质量保证（84 页第 3 点）“软件测试人员的目标是……”
- 白盒测试、黑盒测试、灰盒测试定义（86 页）
- 是由独立的测试人员吗
- 需要有编程能力吗？（有，因为白盒测试）
- 简述软件测试和软件调试的相同点、不同点（86 页软件调试与测试全背）
- 测试用例的测试应该力求（）而非着眼于是正确的（85 页 7.1.3）
- 根据不同的覆盖准则设计测试用例
- 各种覆盖的强弱关系（并非单调递增，PPT 的反例）
- 分支覆盖又叫判定覆盖
- 基本路径测试（可能出大题）画控制流图、基本路径 测试用例
- 基本路径集合不是唯一的，但路径数目唯一
- 黑盒测试的三种方法
- 状态测试的定义
- 错误猜测法、因果图法（P109 第三点 继承测试用例 第二段的最后一句话）
- 大题用边界值分析
- 静态范围的测试很广……（目的，基本思想，P95）
- 通用评审过程 6 个步骤名（大部分问题在“准备”发现）
- 评审的三种类型名（P96）哪种是正式的
# 题
- 为了提高测试的效率，应该（在完成编码以后指定软件的测试计划）
- 下列评审类型中不属于静态评审类型的是（自查）
- 软件测试的目的是（尽可能多地发现软件系统中的错误）
- 在黑盒测试中，边界值分析法作为等价类划分法的（有效补充）
- 在等价类划分方法中。既可以定义为输入等价类，也可以定义为（输出等价类）
# 第八章 软件测试策略
- 四个级别的测试，其主要目的（测试依据）是什么（P101）
- 系统测试的定义（P109最后一行）、理解验收测试的关注点，测试用例是如何得到的，是否需要客户的参与（P111）；在多个级别中进行
- 改进的 V 模型中，测试的计划和用例要提前，一旦有了xx就可以测试xx
- 理解回归测试，回归测试可以在所有测试级别下进行，并可应用在功能和非功能测试中；应该尽量采用自动化测试
- 四个测试分别应使用白盒/黑盒方法？
- 驱动模块、桩模块的含义；被测试模块需要驱动模块的时候，测试样例通常是在驱动模块中进行
- 单元测试的主要内容（五个方面，P104）整段话背下来
- 为什么单元测试的依据不是代码（P104 图上两句话）
- 集成测试有哪三种集成方法（自顶向下、自底向上、Smoke）
- 自顶向下、自底向上集成测试的定义及优缺点（P107、108）
- 自顶向下鉴真式测试法有两种组合策略：深度优先策略和广度优先策略
- 五种系统测试策略的名字
- 压力测试：“高一个数量级”
- 现场测试：\alpha测试、\beta测试的定义
# 题目
- 单元测试主要针对模块的几个基本特征进行测试，该阶段不能完成的测试是（A） A. 系统功能 B. 局部数据结构 C. 重要的执行路径 D. 错误处理
- 不属于系统测试的主要内容是（接口测试）
- 系统测试是把软件、硬件、环境连在一起的全面测试（√）
- 单元测试时，对所有出错处理的路径都要测试。（√）
# 第五章 生产率度量
- 软件生产率度量基于功能点（间接）的度量和代码量（直接）的度量
- FP 计算（表格后公式都会给）
- FP/LOC 的相关度量
- LOC 的优缺点（背）
- LOC、FP 的换算
- 不要苛刻。。。。。。。。。（√）
- 成本估算的方法之一是 COCOMO 模型
# 题
- 软件的功能和质量是不可测的，现有的评价依据都是主观评价（×，度量）
- 问题分解不适用于（A） A. 对软件详细设计 B. 进行项目估算 C. 制定项目计划 D. 细化软件功能
# 第九章 软件维护
- ISO 2008 对软件维护的定义（P118） 到第一个句号
- 维护是软件生命周期花费最多的时间（测试也很多）
- 四种维护，及占的百分比
- 软件维护随时间，纠错性维护的工作量逐渐降低
- 软件维护的必要性，七点（P118）
- 软件维护的困难性，四点
- 可维护性的定义`
- 估算维护工作量的模型，理解四个参数
- 软件维护技术：程序理解、软件正向工程、软件逆向工程
- 软件再工程的定义
- 软件逆向工程的主要内容、看下过程
- P-CMM 是什么，五个级别名称 P137 图
# 第十章 软件项目管理
- 项目管理的四个要素，最重要的
- 三种团队组织形式、名字、缩写
- 沟通是横向的还是垂直的？那种会带来更高的士气和满意度？模块化程度高/低的适合哪一种？
- 团队有没有/有一个/多个领导者？
- 虚拟团队的定义、优缺点；对虚拟团队，目标是最重要的方面
- 产品下面的第一句话 P135 第二段
- 软件项目管理的第一个活动：确定软件范围
- 项目估算的方法：分解技术、经验模型
- P146 10.6.2 第一段前两句话、最后一段
- 产品的前两句话（P135 第二段）
- 知道问题分解是用来干什么
- 软件质量保证涵盖整个开发过程