软件工程基础 简答题 哈工程

一、简答题范围（25分左右）
1.简述软件的定义及特征（第1章）
(1)指令的集合，执行这些指令提供期望特性、功能、性能；
(2)数据结构，使程序合理地操纵信息；
(3)文档，描述程序的操作和使用。
2.简述软件工程的定义（IEEE）及软件过程的5种框架活动（第2章）
1.
IEEE 定义：
软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在(1)中所述方法的研究。
-需要规范，也需要可适应性和灵活性（有些方法对于一个团队符合（1），但对于另一个团队可能是负担）
2.
沟通(与客户沟通与协调，以理解项目目标）
策划（工作、技术任务、风险、资源、产品，进度计划）
建模（用模型来理解软件需求，完成设计）
需求分析
设计
构建（编码、测试）
代码生成
测试
部署（软件交付用户，用户测评并反馈）

3.画图说明软件过程流的各种类型（第3章）

4.画图说明软件过程的增量模型及适用情形和特点（第4章）

2.初始的软件需求明确，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。
例如第一个增量往往是核心产品，附加功能进入下个增量计划。
3.综合了线性过程流和并行过程流的特征。
每个增量都提交一个可以运行的产品。
例如：文字处理软件，第一个增量是基本的文件管理、编辑和文档生成（核心功能）；第二个增量是复杂的编辑和文档生成；第三个增量是拼写检查和语法检查功能；第四个增量是高级页面排版功能；第2至4个增量是附加功能。
5.画图说明软件过程的原型模型及适用情形和特点（第4章）

适用情形
客户提出了一些基本功能，但没有详细定义功能和特性需求
开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定
特点
很少是好用的，可能太慢太大，难以使用。
一般作为被丢弃的系统。

6.画图说明统一过程的各个阶段（第4章）

7.简述敏捷原则（第5章）

1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求的变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在开发团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要衡量标准。
8. 敏捷过程提倡可持续的开发。责任人、开发者和用户应该能够长期保持稳定的开发速度
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使不必做的工作最大化的艺术——是必要的。
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

8.简述需求建模的模型（第8章）
基于场景的模型
从用户角度来看的系统。
数据模型
表示数据在系统内是如何转换的。
面向类的模型
定义对象、属性和关系。
面向流的模型
表示数据在系统内是如何转换的。
行为模型
表示事件对系统状态的影响
9.简述CRC模型的评审步骤（第9章）
所有参加（CRC模型）评审的人员拿到一部分CRC模型索引卡。
拆分协作卡片（也就是说每个评审员不得有两张存在协作关系的卡片）。
分类管理所有的用例场景（以及相关的用例图）。
评审组长细致地阅读用例。
当评审组长看到一个已命名的对象时，给拥有相应类索引卡的人员一个令牌。
当令牌传递时，索引卡的拥有者需要描述卡上记录的职责。
评审组确定（一个或多个）职责是否满足用例需求。
如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。
修改可能包括定义新类（和相关的CRC索引卡），或者在已有的卡上说明新的或修改的职责、协作。

10.简述行为建模的步骤（第10章）
列出不同的系统状态（系统如何表现？）
表明系统如何从一个状态转变为另一个状态（系统怎样改变状态？）
指出事件
指出活动
画状态图或顺序图

11.画图说明从需求模型到设计模型的转换（第11章）

12.简述模块的功能独立及评估标准（第11章）
通过开发具有“专一”功能和“避免”与其他模块过多的交互的模块，可以实现功能独立。
独立性有两条定性标准进行评估：
内聚性显示了某个模块相关功能的强度。
一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。简单地说，一个内聚的模块应该（理想情况下）只完成一件事情。
耦合性显示了模块间的相互依赖性。
耦合性依赖于模块之间的接口复杂性、引用或进入模块所
13.简述重构的定义及重构时的检查要点（第11章）
Fowler [FOW99] 用下面的方式定义重构：
“重构是使用这样一种方式改变软件系统的过程：不改变代码[设计]的外部行为而是改进其内部结构。”
当重构软件时，检查现有设计：
冗余性
没有使用的设计元素
低效的或不必要的算法
拙劣的或不恰当的数据结构
其他设计不足，修改这些不足以获取更好的设计。
14.简述体系结构风格描述的4个要素及其分类（第12章）
每种风格描述一种系统类别，包括：（1）完成系统所需要的某种功能的一组构件（例如数据库、计算模块）；（2）能使构件间实现“通信、协调和合作”的一组连接件；（3）定义构件如何集成为系统的约束；（4）语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。
以数据为中心的体系结构
数据流体系结构
调用和返回体系结构
面向对象体系结构
层次体系结构

15.简述构件级设计的7个基本原则（第13章）
开闭原则(OCP)。“模块[构件]应该对外延具有开放性，对修改具有封闭性”。
Liskov 替换原则(LSP)。“子类可以替换它们的基类”。
依赖倒置原则(DIP)。“依赖于抽象，而非具体实现”。
接口分离原则(ISP)。“多个客户专用接口比一个通用接口要好”。
发布复用等价性原则(REP)。“复用的粒度就是发布的粒度”。
共同封装原则(CCP)。“一同变更的类应该合在一起”。
共同复用原则(CRP).。“不能一起复用的类不能被分到一组”。
16.简述黄金规则中把控制权交给用户的规则（第14章）
以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。
提供灵活的交互。
允许用户交互被中断和撤销。
当技能水平高时可以使交互流线化并允许定制交互。
使用户与内部技术细节隔离开来。
设计应允许用户与出现在屏幕上的对象直接交互。

17.简述黄金规则中减轻用户记忆负担的原则（第14章）
减少对短期记忆的要求。
建立有意义的默认设置。
定义直观的快捷方式。
界面的视觉布局应该基于真实世界的象征。
以一种渐进的方式揭示信息。

18.简述黄金规则中保持界面一致的原则（第14章）
允许用户将当前任务放入有意义的环境中。
在完整的产品线内保持一致性。
如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。

19.简述OO测试中集成测试的3种策略（第17章）
集成测试应用三种不同的策略
基于线程的测试——对响应系统的一个输入或事件所需的一组类进行集成
基于使用的测试——对响应系统的一个用例所需的一组类进行集成
簇测试——对演示一个协作所需的一组类进行集成

20.简述压力测试并举例说明（第17章）
压力测试
以非正常的数量、频率或容量的方式执行系统。测试是想要破坏程序。
举例：
— 如果正常的中断频率为每秒5次，强度测试设计为每秒50次中断。
— 把输入数据的量提高一个数量级来测试输入功能会如何响应。
— 若某系统正常运行可支持200个终端并行工作，强度测试则检验1000个终端并行工作的情况。

21.简述单元测试中桩模块和驱动模块的作用？（第17章）

22.简述测试中症状与原因之间的关系（第17章）

23.简述软件基线及SCI和项目数据库并画图说明（第21章）
IEEE (IEEE标准610.12-1990) 是这样定义基线的：
已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。
基线是软件开发中的里程碑，其标志是正式技术评审中已经获得批准的一个或多个软件配置项的交付。

24.简述选择软件团队结构时应考虑的7个因素（第22章）
待解决问题的难度
开发程序的规模 ，以代码行或者功能点来度量
团队成员需要共同工作的时间 (团队生存期)
能够对问题做模块化划分的程度
待开发系统的质量要求和可靠性要求
交付日期的严格程度
项目所需要的友好交流的程度
25.简述软件团队的组织范型（第22章）
封闭式范型 ——按照传统的权利层次来组织团队
1个高级工程师（主程序员），2-5个技术人员，1个后备工程师
随机式范型 ——松散地组织团队，团队工作依赖于团队成员个人的主动性
开放式范型 ——试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队
同步式范型——依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流
26.简述如何避免“团队毒性”（第22章）
狂乱的工作氛围；
使团队成员浪费精力，同时也使他们在工作中表现出毫无目的性。
引起团队成员间产生摩擦的重大挫折
由个人、商业和技术因素引起的重大挫折导致团队成员间产生摩擦。
“碎片式的或协调很差”的软件过程
缺乏定义的或选择不合适的过程模型都会成为成功路上的路障。
在软件团队中没有清晰的角色定义
不清晰的角色定义导致缺乏责任，并相互指责。
“接连不断地重蹈覆辙”
使团队成员失去信心并降低斗志。
二、综合题题型（25分左右）
1.用例图、类图、状态图、活动图（泳道图）
2.白盒测试（计算环复杂度、列出具体的独立路径，可从代码或流程图画出流图、也可从流图画出流程图）
3.黑盒测试（用表列出有效等价类和无效等价类，设计测试用例和预期结果）一般与边界法相结合
4.过程度量与项目度量、软件项目估算（代码行，功能点等）。见23章、24章
5.综合题亦可改变为简答题
三、填空、选择、判断（50分左右）（填空来自第8版PPT）
填空10分，选择30分，判断10分