《软件工程》复习指南

《软件工程》复习指南
一、试卷题型和分值分布
1．选择题（单选）10个，每个2分，共20分。
2．判断题10个，每个1分，供10分。
3．简答题10个，每个4分，共40分。
4．测试用例设计题，10分。
5．应用题，20分。

二、对考试出题范围的解释
1. 应用题将考察结构化分析与设计技术的掌握情况。给定某个软件的背景及需求描述材料，要求根据题目要求完成数据流图（某一分层DFD）、数据字典（词条）定义。参考平时小测验的例子。
2. 测试用例设计题将考察白盒和黑盒测试用例设计技术的掌握情况。给定某个需求的功能定义及约束，根据题目要求用黑盒方法（等价类和边界值方法）进行测试用例设计；给定某段程序（或其流程图），根据题目要求用白盒方法（语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径测试）进行测试用例设计。参考平时作业和课堂例子。
3. 简答题主要考察对“软件工程”各阶段中的基本概念和基本思想的认识，要求对内容在理解基础上记忆。参考本指南第三部分。
4. 选择题和判断题，考察对一些知识点细节的把握。参考教材和本指南第三部分。

三、精炼的知识点 
1. 软件发展的3个阶段 （了解）
程序设计阶段，软件设计阶段，软件工程阶段 
2. 软件的特点（了解）
软件是一种逻辑实体，而不是具体的物理实体，开发人员智力的体现 
软件的生产与硬件不同，在它的开发过程中没有明显的制造过程
在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题

3. 软件工程定义
Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法
IEEE1993: (1)把系统化的、规范化的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；(2)研究(1)中提到的途径

4. 软件生存周期概念及每个阶段的描述
计算机系统工程：确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算做出进度安排，并进行可行性分析
需求分析：确定软件的功能，性能，数据，界面等要求，生成软件需求规约
设计：概要设计 — 把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应。
详细设计 — 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础。
编码：用某种程序设计语言将设计结果转换为可执行的程序设计代码
测试：发现并纠正软件中的错误和缺陷，包括，单元测试，集成测试，确认测试，系统测试
运行和维护：当发现了软件中潜藏的错误或需要增加新的功能或软件适应外界环境的变化等情况出现时，进行修改
5. 瀑布模型思想、特点及局限性
主要思想：软件开发过程与软件生命周期是一致的，相邻二阶段之间存在因果关系，需对阶段性产品进行评审
特点：接收上一阶段活动的结果作为本阶段活动的输入，依据上一阶段活动的结果实施本阶段应完成的活动，对本阶段的活动进行评审，将本阶段活动的结果作为输出传递给下一阶段
局限性：缺乏灵活性，如用户需求一开始很难确定， 到最后阶段才能得到可运行的软件版本


6. 增量模型、原型模型、螺旋模型各自的思想、特点及局限
增量模型思想和特点：增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征
原型模型：思想：原型应该包括目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能。原型模型两个阶段：原型开发阶段，目标软件开发阶段
局限性：不能支持风险分析
螺旋模型思想和特点：螺旋模型是瀑布模型、原型模型的有机结合，同时增加了风险分析，螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。
局限性：只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功
7. 基于计算机的系统概念及6个组成元素 
指通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列
元素有：软件，硬件，人员，数据库，文档和规划
8. 可行性分析的任务
从经济，技术，法律等方面分析给出的解决方案是否可行，能否在规定的资源和时间的约束下完成 
9. 需求工程的6个阶段及任务
需求获取：通过与用户的交流，了解业务现状以及对待开发系统的期望
需求分析与协商：对需求进行分类组织，分析需求之间的关系，检查需求的一致性、重叠和遗漏的情况，根据用户的需要对需求进行排序。
系统建模：借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图
需求规约：通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求
需求验证：对功能的正确性、完整性和清晰性，以及其它需求给予评价
需求管理：对所有需求工程相关活动的规划和总体控制
10. 软件需求的概念
指用户对目标软件系统在功能，行为，性能，设计约束等方面的期望
11. 软件设计阶段的任务（注意，教材上介绍了4种设计，应该将接口设计中的界面设计补充进来解释一下，那么有5种设计）
数据/类设计：将分析-类模型变成类的实现和软件实现所需要的数据结构
体系结构设计：体系结构设计定义了软件的整体结构
接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
构件级设计：构件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述
界面设计：是人与计算机之间传递和交换信息的媒介
12. 软件设计过程
是一个本软件需求变换为软件表示的工程
13. 模块化的概念
吧软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件
14. 信息隐藏的概念
每个模块的实现细节对于其他模块来说应该是隐藏的
15. 功能内聚的概念与数据耦合的概念
内聚：是一个模块内部各个元素彼此结合的紧密程度的度量
耦合：是模块之间的相对独立性（互相连接的紧密程度）的度量。
16. 结构化分析与设计中，判断结构好坏的标准—高内聚低耦合 （了解）
17. 结构化分析模型包含哪些模型（如，数据字典…）
18. 数据流图的基本元素及说明
源和宿：表示软件系统输入数据的来源和输出数据的去向
加工：描述了输入数据到输出数据流的变换
数据流：由一组固定成分的数据组成
文件:用于存放数据
19. 启发式设计策略（了解）
改造程序结构图，降低耦合度，提高内聚度
避免高扇出，并随着深度的增加，力求高扇入
模块的影响范围应限制在该模块的控制范围内
降低模块接口的复杂程度和冗余程度，提高一致性
模块的功能应是可预测的，避免对模块施加过多的限制
尽可能设计但入口和单出口的模块
20. 系统响应时间的概念
指从用户执行某个控制动作到软件做出响应的时间
21. 界面设计问题（了解）
22. 界面设计的黄金原则
让用户拥有控制权
减少用户的记忆负担
保持界面一致
23. 编程实现时需注意的问题（细节包括标识符命名的注意问题，程序注释的注意问题，代码的视觉组织，数据说明的注意问题，语句结构的注意问题）
标识符的命名：应有一定的意义，应选择精炼的意义明确的名字，不用关键字做标识符，不用相似的名字，避免使用混淆的字符
注释：注释要正确，为程序做注释，而不是为每一个语句做注释，用缩进和空行，应提供一些从程序本身难以的带的信息
视觉组织：通过缩进技巧可清晰地观察到程序的嵌套层次，自然的程序段之间用空行分开，
可通过添加空格是语句成分清晰，可添加括号突出运算的优先级，一般把左大括号放在行尾，右括号放在行首
数据说明：数据说明次序规范化，说明语句中变量安排有序化，使用注释说明复杂的数据结构
语句结构：一行只写一条语句，首先考虑清晰性，直接了当的说明程序员的用意
24. 软件测试的目的，测试用例的概念
目的：发现软件中的错误和缺陷并加以纠正
测试用例：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
25. 各种逻辑覆盖准则之间的关系 （了解）
语句覆盖：
判定覆盖
条件覆盖
判定/条件覆盖
26. 单元测试、集成测试、确认测试和系统测试的对象、依据和任务 
单元测试：称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行验证
集成测试 也称组装测试、联合测试经单元测试  每个模块都能独立工作，但把它们放在一起往往不能正常工作。
确认测试以软件需求规约为依据，以发现软件与需求不一致的错误。主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。
系统测试是对整个基于计算机的系统进行的一系列测试。
27. 集成测试的集成次序
自顶向下集成：从主控模块（主程序）开始，然后按照程序结构图的控制层次，将直接或间接从属于主控模块的模块按深度优先或广度优先的方式逐个集成到整个结构中，并对其进行测试。
自底向上集成：从程序结构的最底层模块（即原子模块）开始，然后按照程序结构图的控制层次将上层模块集成到整个结构中，并对其进行测试。
28. α测试和β测试的概念、回归测试的概念
回归测试就是对已经进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。
 α测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。
β测试是由软件的最终用户在一个或多个用户场所进行的
29. 测试完成的标准
如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试
使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止。
30. 软件维护及4种类型的维护的概念
软件维护：是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程 
纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护
适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程
改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护
预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动
31. 改善性维护在维护中所占比重最大 （了解）
32. 提高可维护性的方法
确定质量管理目标和优先级，规范化程序设计风格，选择可维护性高的程序设计语言，改进程序文档，保证软件质量审查方法
33. 软件质量的定义
与软件产品满足明确或隐含需求的能力有关的特征和特性的总和
34. 软件可靠性的概念及其度量指标
软件可靠性是指在规定的条件下和规定的时间内软件按规格说明要求不引起系统失效的概率
度量指标：
MTTF (Mean Time to Failure)平均失效等待时间
MTBF (Mean Time Between Failures) 平均失效间隔时间
35. 软件配置项、软件配置、基线的概念
软件配置项(Software Configura tion item，SCI)：为配置管理设计的软件的集合，它在配置管理过程中作为单个实体对待
软件配置(Software configuration)：软件产品在不同时期的组合。该组合随着开发工作的进展而不断变化
基线(baseline)：业已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理过程方能加以修改的规格说明或产品