软件工程选择题

1软件工程介绍

1. 软件会退化而不是磨损, 因为多个变更请求在组件交互中引入错误
2. 大多数软件仍然是客户定制的, 因为许多应用领域没有现成的备用供应软件构件
3. 软件不包含商业策划部分
4. 软件危机产生的主要原因是软件本身的特点-软件开发和维护的方法不正确

2.1过程的通用视图

1. 制造不是软件工程层之一
2. 五个通用软件工程框架活动: 沟通、策划、建模、构建、部署
3. 过程模型强调机动性和适应性, 所以被称为敏捷
4. 已执行级; 已管理级; 已定义级; 已定量管理级; 已优化级属于能力成熟度模型中的级别
5. 从业者需要项目经理的仔细监督不是个人软件过程的特征
6. 已管理级管理级别中已实现基本的项目管理

2.2过程模型

1. 线性顺序模型: 需求定义明确时的一种合理的方法
2. 线性顺序模型也称为经典生命周期模型和瀑布模型
3. 软件开发的增量模型是当需要快速开发核心产品时的一个很好的方法
4. 快速应用开发模型是线性顺序模型的高速变种
5. 演化过程模型: 本质上是迭代的; 能够轻松适应产品需求的变化; 一般不产生废弃的系统
6. 软件开发的原型模型是当客户无法明确定义需求时的一种有用的方法
7. 软件开发的螺旋模型: 以软件产品的交付结束; 比增量模型更混乱; 每个迭代周期都有项目风险评估
8. 并行开发模型常用于开发客户机/服务器应用程序
9. 形式化软件开发模型利用数学方法: 基于计算机的系统定义了规格说明; 开发无缺陷的计算机系统; 验证计算机系统的正确性
10. 统一过程模型定义的阶段名称: 初始阶段; 细化阶段; 构建阶段
11. 在统一流程模型中, 需求是迭代确定的, 可能跨越流程的多个阶段(T)
12. 不可以使用原型模型开发航天相关系统和公司的财务系统
13. 螺旋模型: 过程包括制定方案、风险分析、制定计划、阶段实施; 支持系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期; 支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型; 每个阶段开始时的任务是确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件

3敏捷软件工程

1. RSD不是敏捷过程模型
2. XP敏捷过程模式鼓励"结对编程"
3. 强调协作以收集需求不属于 XP
4. Agile 方法不适合大中型业务系统或 PC 产品
5. DSDM模型应用了帕累托最优原则
6. 强调“沟通最大化”，“每天一个圆桌会议”，“使用的一系列过程模式被证实在时间紧张、 需求变化和业务关键的项目是有效的”是Scrum
7. ASD模型强调自我组织、自我学习和反思
8. 使用多个模型进行有目的地建模，保留前进灯的是敏捷建模
9. Crystal不属于轻量级软件开发方法

4需求工程

1. 在项目启动期间，其任务是确定: 对基本问题的理解; 所需解决方案的性质; 项目共利益者
2. 需求工程精化的结果是一个分析模型，该模型定义了信息, 功能, 行为问题领域
3. 系统需求规格说明描述了基于计算机的系统的功能、性能和约束
4. 需求追溯表的使用有助于识别、控制和跟踪需求更改
5. 强制需求不是质量功能部署（QFD）中使用的需求分类
6. 需求获取过程中产生的工作产品将根据正在构建的产品规模而有所不同
7. 数据流图不属于创建系统分析模型的 UML 图
8. 软件的系统需求不包括用户需求
9. 软件需求可分为: 系统需求; 业务需求; 用户需求 三类

5-6分析模型测试

1. 为问题构建简洁的解决方案不是构建分析模型的目标
2. 数据要素不是面向对象分析模型的元素
3. UML 活动图对于表示分析模型基于场景的元素很有用
4. 数据流图: **描述了数据流转换的函数, 表示系统如何进行数据转换 **
5. 控制流程图: 需要对事件驱动系统建模, 用于实时系统建模
6. 事件, 人, 结构应该被视为问题空间中的候选对象
7. 数据转换不是操作的分类之一
8. 类可靠性不会出现在 CRC 卡上
9. 类的职责: 它的属性和操作
10. 事件发生在: 参与者和 OO 系统交换信息; 类操作被调用; 消息在对象之间传递
11. 状态图: 表示系统对外部事件的反应
12. 为了进行行为建模，状态是任何可观察的行为模式

7设计工程

1. 架构, 数据, 接口是设计模型所关注的领域
2. 软件设计的重要性可以用质量这个词来概括
3. 实现分析模型中所有的需求, 提供软件的全貌 是优秀设计的特征
4. 体系结构模型可以用来表示软件的架构设计
5. 内聚性是对模块只专注于一件事的定性指示
6. 在使用结构化设计方法时，逐步求精的过程是必要的
7. 耦合是模块连接其它模块和外部世界的定性指示
8. 软件设计被重构有助于创建更容易集成、更容易测试和更容易维护的软件(T)
9. 多态减少了扩展对象系统所需的工作，因为允许许多不同的操作共享相同的名称
10. 实体类不是五种设计类类型之一
11. 数据设计元素被用来描述信息模型
12. 体系结构设计可以类比于房屋的平面图
13. 界面设计可以类比于房屋的内部接入点或与外部公用设施连接的详细图纸
14. 构件级设计可以类比于一套房子里每个房间的详细图纸
15. 软件重用的关键问题之一是，当存在数百个候选设计模式时，无法找到现有的可重用设 计模式(T)

8体系结构设计

1. 体系结构风格包含约束, 组件集, 语义模型, 连接器元素
2. 为了确定最适合系统的体系结构风格或风格组合，需求工程师通常需要给出特征和约束条件
3. 在系统环境建模过程中，与目标系统交互的系统可以表示为同级系统; 下级系统; 上级系统
4. 在系统环境建模过程中，与目标系统在对等的基础上相互作用的是同级系统
5. 在体系结构权衡分析方法中，体系结构风格应该使用用户视图来描述
6. 评估所提议的体系结构的整体复杂性的一种有用的技术是查看该组件的依赖关系
7. 当数据流图中整个的数据流动以一种顺序的方式沿着一条或仅仅很少的几条直线路径进行, 变换流就出现了
8. 当单个项目沿着数据流图的多个路径之一触发其他数据流时，事务流可标志该信息流的特征
9. 在事务映射中，第一级分解的结果是控制层次结构的导出
10. 通过变换或事务映射得到体系结构设计的应用程序可以由模块接口描述和每个模块的过程详述进一步补充说明
11. 控制类用于描述系统中业务逻辑处理
12. 从管理角度看，软件设计包括概要设计 详细设计

9构件级设计

1. 在面向对象的软件工程环境中，构件包含一组协作类
2. 在传统的软件工程中，模块必须扮演控制构件; 基础设施构件; 问题域构件
3. 简约复杂性原理不是用于指导构件级设计的四项原则之一
4. 在构件设计中, 精化需要详细描述属性; 接口; 操作
5. 在构件级设计中，“持久数据源”指 数据库和文件
6. 条件; 循环; 顺序经常被用于结构化编程
7. 流程图是过程细节描述的图形符号化表示
8. 当一组复杂的条件和动作出现在构件中时使用决策表
9. 程序设计语言（PDL）通常是程序结构与描述文本的组合
10. 在评估特定设计符号的有效性时，可维护性; 模块化; 简洁是有用的

10用户接口测试

1. 为完成任务仅提供一种定义的方法不允许用户保留与计算机的交互控制
2. 定义直观快捷键; 以渐进的方式披露信息; 建立有意义的缺省值 可以减少用户的记忆负担
3. 界面一致性: 输入机制在整个应用系统家族中保持一致; 根据设计标准组织视觉信息
4. 用户模型描述了计算机系统的最终用户的轮廓
5. 心理模型或系统感知描述了终端用户在他或她的头脑中创建的系统的形象
6. 实现模型描述了用户界面的外观和感觉以及所有支持信息
7. 成本估算通常与用户界面设计过程无关
8. 研究现有的基于计算机的解决方案; 观察用户手动执行任务的情况在用户界面设计中是有用的

14测试策略测试

1. 使用独立软件测试团队的最佳原因是测试团队将更彻底地测试软件
2. 组织传统软件测试的正常活动顺序是 单元~, 集成~, 验证~, 系统~
3. 在成功的软件测试过程中需要强调: 在测试前进行正式的技术审查; 以可量化的方式具体化需求
4. 在单元测试期间需要评估: 错误处理; 执行路径
5. 自上而下的集成测试具有的主要优势: 重大决策点及早测试; 无需编写驱动模块程序
6. 自下而上集成测试具有无需编写桩模块程序的主要优势
7. 回归测试应是集成测试的正常部分，因为当新模块添加到系统中, 会调用新的控制逻辑; 会产生新的数据流路径
8. 冒烟测试最好的描述为滚动式集成测试
9. 面向对象测试集成策略指测试以某种方式协作或沟通的类组
10. 验收测试通常由最终用户进行
11. 回溯法; 蛮力法; 原因排除法属于调试方法
12. 在软件质量保证工作中，软件验证和软件确认没有区别(F)
13. 面向对象软件的类测试相当于传统软件的单元测试(T)
14. 通过收集软件指标并利用现有的软件可靠性模型，可以制定有意义的准则，以确定软件测试何时完成(F)
15. 单元测试不需要驱动程序和桩程序，因为模块是独立测试的(T)
16. 在测试面向对象软件时，作为单元测试过程的一部分，必须单独测试每个类操作(F)
17. 确认测试的重点是让用户发现软件不符合其需求的地方(T)
18. 软件确认是通过在工作环境中部署软件后用户进行一系列测试实现的(T)
19. 如果在软件集成期间严格应用了回归测试，则不需要配置审查(F)
20. 恢复测试是一种系统测试，它迫使软件以各种方式失败，并验证软件是否能够不间断地 继续执行(T)
21. 安全测试试图验证系统中内置的保护机制是否保护它免受不正当入侵(T)
22. 压力测试检查在极端环境中使用系统期间对用户施加的压力(F)
23. 性能测试仅对实时或嵌入式系统重要(F)
24. 调试不是测试，但是始终作为测试的结果发生(T)

15测试技术

1. 通过严格的测试，可以在交付给客户之前从程序中消除所有缺陷(F)
2. 可观察性; 简单性; 稳定性是可测试软件的特征
3. 黑盒测试需要设计测试用例来演示每个程序功能的可操作性
4. 白盒测试需要设计测试用例来执行软件模块的内部逻辑
5. 逻辑错误会被黑盒测试遗漏，而可以被白盒测试检测出
6. 环复杂度度量为设计人员提供了关于程序中的独立路径的数量信息
7. 程序的环复杂度可以直接从算法的 PDL 表示中计算出来，而无需绘制程序流图(T)
8. 条件测试是一种控制结构测试技术，用于设计测试用例的标准是测试程序模块中的逻辑条件
9. 数据流测试是一种控制结构测试技术，用于设计测试用例的标准是根据变量的位置和使用选择测试路径
10. 循环测试是一种控制结构测试技术，用于设计测试用例的标准是专注于测试循环结构的有效性
11. 黑盒测试试图找出 错误或缺失的功能; 接口错误; 性能错误
12. 基于图的测试方法只能用于面向对象的系统(T)
13. 等价类测试将输入域划分为测试用例可以导出的数据类，以减少必须开发的测试用例的 总数(T)
14. 边界值分析只能用于白盒测试(F)