软件工程学复习大纲

2013级云计算专业软件工程学期末考试复习大纲
一、第一章软件工程介绍
（1）何为软件？
（2）软件和硬件不同的特性：
①软件是设计开发的，而不是传统意义上生产制造的。

②在软件不会“磨损”，但存在退化，硬件失效曲线与软件失效曲线对比
③整体向着基于构建的模式发展，但多数仍是按客户需求定制的。

（3）软件危机（了解）是引入软件工程的原因
（4）何为软件工程？（IEEE1993的定义）：软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。

（2）在（1）中
所述方法的研究。

二、第二章过程综述
（1）软件工程是一种层次化技术，其包括质量关注点、过程、方法和工具。

（2）过程框架定义了若干小的框架活动，为完整的软件开发过程建立了基础。

①通用过程框架活动包括沟通、策划、建模、构建和部署五种。

②过程框架还包含一些适用于各个软件过程的普适性活动。

这样活动主要有软件项目跟踪和
控制、风险管理、软件质量保证、正式的技术复审、测量、软件配置管理、可复用管理和工作产品的准备和产生。

三、第三章过程模型
（1）软件过程模型是软件开发全部过程、活动和任务的结构框架，也称软件开发模型或软件生存周期模型。

①惯例过程模型（又称传统过程模型、严格过程模型），强调对过程活动和任务的详
细定义、识别和应用。

它力求实现结构化和有序。

②敏捷过程模型提倡弱化软件过程中过于正式的要求，并将自我组织、协作、沟通
和可适应性作为主要原则。

③惯例软件过程模型主要有瀑布模型、演化过程模型和统一过程模型等类型。

（2）瀑布模型
①瀑布模型又被称为经典生命周期，它提出了一个系统的、顺序的软件开发方法。

它从
用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一个完整的
软件并提供持续的技术支持。

②瀑布模型存在的问题：
●缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发，实际的项目很少遵守
瀑布模型提出的顺序。

●客户必须要有耐心，因为只有在项日接近尾声的时候，他们才能得到可执行的程序。

●开发早期存在的问题往往要到交付使用时才发现，维护代价大。

（3）演化过程模型演化模型是迭代的过程模型，使得软件工程师能够逐步开发出更完整的软件版本。

其主要有原型模型和螺旋模型两种。

①原型模型的主要特点
●快速制订原型开发的计划、快速建模和快速构建
●原型应交付给客户试用，并收集反馈意见，改进原型
②螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点。

随着演进过程的
开始，从圆心开始顺势针方向，执行螺旋上的一圈表示的活动。

每次演进都要考虑风
险，每个演进过程都要标记里程碑。

螺旋模型应用在计算机软件的整个生命周期。

是
开发大型系统的理想方法，可以有效的应对风险。

●螺旋模型的特点：
可应用在计算机软件的整个生命周期
是开发大型系统和软件的理想方法
把原型开发作为降低风险的机制
（4）统一过程（UP）是一种“用例驱动、以架构为核心，迭代并却增量”的软件过程。

其包括并发进行的起始、细化、构建、转化和生产5个阶段。

●起始阶段包括沟通和策划，定义软件的需求，提出系统的大致框架，并制定开发计划，
以保证开发具有迭代和增量的特性。

●细化阶段包括沟通和建模活动。

细化阶段扩展了起始阶段定义的用例，并扩展体系结
构以包括软件的5种视图：用例模型、分析模型、设计模型、实现模型和部署模型。

●构建阶段于通用软件过程中的构建活动相同，构建采用体系结构模型作为输入，开发
系统构建，使最终用户能够操作用例。

●转化阶段包括通用构建活动的后期活动以及部署活动。

软件被提交最终用户进行beta
测试，并发布支持信息（手册、问题解决指南及安装步骤）。

转换阶段结束时，软件
增量称为可用的发布版本。

●生产阶段和通用过程的部署活动一致。

在该阶段，监控软件持续使用，提供运行环境
的支持，提交缺陷报告和变更请求。

四、第四章敏捷视角下的软件过程
（1）敏捷联盟的12条原则（了解即可，注意选择题和判断题）
①尽早交付有价值的软件来让顾客满意。

②在后期也欢迎变更，利用变更来为客户创造竞争优势。

③交付的时间间隔越短越好。

④业务人员和开发人员必须天天在一起。

⑤围绕受激励的个人构建项目。

⑥最有效的信息传递方式是面对面交谈。

⑦可工作软件是进度的首要度量标准。

⑧提倡可持续的开发速度。

⑨关注优秀的技能和好的设计。

⑩简单是必要的。

⑪好的架构和设计出自于自组织团队。

⑫每隔一定时间，反省工作，调整行为。

（2）建立敏捷过程的三个关键性假设
①提前预测哪些需求是稳定的和哪些需求会变化非常困难。

②对很多软件来说，设计和构建是交错进行的。

③从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。

（3）极限编程(eXtreme Programming, 简称XP)是一种常用的敏捷过程。

它使用面向对象方法作为推荐的开发范型。

XP包括策划、设计、编码和测试4个框架活动。

①策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”，XP团队成员
评估每一个故事并给出以开发周数为度量单位的成本。

②设计严格遵循KIS原则，适用简单而不是复杂的表述。

鼓励适用CRC卡来组织相关的
对象和类，鼓励重构。

③编码的一个关键概念是结对编程。

两个人面对同一台计算机共同为一个故事开发代码。

实施中两个人担当的角色略有不同。

④测试。

在编码开始之前建立单元测试是XP的关键因素，所建立的单元测试应当适用
一个可以自动实施的框架，易于重复执行，这种方式支持代码修复后的回归测试策略。

（4）Scrum是一种有效解决时间紧张的、需求变化的和业务关键的项目的敏捷过程。

Scrum 过程定义了计划会议、每日例会、评审会议和回顾会议四种会议。

①Scrum的计划会议
●订出Sprint 目标和需要完成的Backlog
●对本次Sprint 的Backlog进行必要的细化和任务分割
●会议的结束后，团队将会决定他们能够交付哪些东西，以及验收的标准
②Scrum的每日例会
●团队成员间工作进度的沟通和协调
昨天做了什么
存在什么问题
今天准备做什么
●沟通任务板和燃尽图
③Scrum的评审会议
●团队在会议中向最终用户展示这次Sprint工作成果
●评审检查是否已达到Sprint 的目标
●团队成员得到反馈，并以之创建或变更Backlog条目
④Scrum的回顾会议
●继续做……(保持好的做法)
●停止做……（去除错误的做法）
●更好地做……（改进有问题的做法）
五、第七章需求工程
（1）需求工程是一个软件工程动作，始于沟通并持续到建模。

（2）需求工程为以下工作提供了良好的机制：理解用户需要什么、分析要求、评估可行性、协商合理的方案、无歧义的详细说明方案、确认规格说明。

（3）需求工程过程通过执行起始、导出、精化、协商、规格说明、确认和管理七个不同的活动来完成。

①在起始阶段，软件工程师会询问一些似乎与项目无直接关系的问题，以建立基本的谅
解。

②导出需求面临范围问题、理解问题和易变问题。

导出需求的主要有协同需求收集、质
量功能部署和用户场景三种方法。

③精化阶段开发精确的技术模型用以说明软件的功能、特征和约束。

精化的最终结果是
形成一个分析模型，该模型定义了问题的信息域、功能域和行为域。

④通过协商过程来调解客户/最终用户提出的过高要求和需求冲突。

⑤规格说明是需求工程师完成的最终工作产品。

它将作为软件工程师后续活动的基础，
它描述了一个基于计算机系统的功能和特性，以及那些将影响系统开发的约束。

⑥在确认阶段将对需求工程的工作产品进行质量评估。

确认需求时需要检查需求模型的
一致性、是否有遗漏以及歧义性。

正式技术评审是最主要的需求确认机制。

⑦需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活
动。

（4）质量功能部署（QFD）是一种将客户要求转化为软件技术的技术。

QFD目的是最大限度的让客户从软件工程中感到满意。

它确认三类需求：正常需求、期望需求、令人兴
奋的需求。

（5）需求工程导出的工作产品包括七种：必要性和可行性陈述、系统或产品范围的说明、客户/用户及共利益者的列表、系统技术环境的说明、需求列表及每个需求适用的领域
限制、一系列适用场景和任何能够更好定义需求的原型。

（6）分析模型应为基于计算机的系统提供必要的信息、功能和行为域的说明。

分析模型主要包括基于场景的元素、基于类的元素、行为元素和面向信息流的元素。

六、第八章构建分析模型
（1）分析模型使用文字和图表的综合形式以相对容易理解的方式描绘需求的数据、功能和行为。

更重要的是可以更直接的评审它们的正确性、完整性和一致性。

（2）分析模型必须实现的三个主要目标：描述客户需要什么、为软件设计奠定基础、定义在软件完成后可以被确认的一组需求。

分析模型在系统描述和设计模型之间建立桥梁。

（3）分析建模的方法主要有面向对象分析和结构化分析两种。

前者关注于定义类和影响客户需求的类之间的协作方式。

而后者则考虑数据和数据处理的分析建模方法。

（4）基于场景的建模从用户的角度表现系统；面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示；基于类的建模定义了对象、属性和关系；行为建模描
述了系统状态、类和事件在这些类上的影响。

●基于场景的模型从用户的角度描述软件需求。

用例是主要的建模元素，还可以适用活
动图说明场景，泳道图显示了处理流如何分配给不同的用户。

●面向流的建模，常常使用DFD（数据流图）。

它开始于环境图，结束于模块规格说明。

●在基于类的建模型中，按职责划分可将类分为实体类、控制类和边界类三种。

CRC（类
-职责-协作）提供了一个简单的方法，可以识别和组织与系统或产品需求相关的类。

CRC卡片被分为三部分，顶部写类名，下面左侧列出类的职责，右侧部分列出类的
协作关系。

●可以运用UML的状态图和顺序图进行行为建模。

七、第九章设计工程
（1）软件设计是软件工程过程的技术核心，它开始于需求分析和需求建模完成之后。

设计模型提供了数据/类设计、体系结构设计、接口设计和构件设计的细节。

（2）软件设计工程中，进行数据/类设计、体系结构设计、接口设计和构件设计的目的
①数据/类设计：将分析类模型转化为设计类的实现以及软件实现所要求的数据结构。

②体系结构设计：定义软件的主要结构元素之间的联系、可用于达到系统所定义需求的
体系结构风格和设计模式以及影响体系结构实现方式的约束。

③接口设计：描述软件和协作系统之间、软件和使用人员之间是如何通信的。

④构件设计：将软件体系结构的结构元素变换为对软件构件的过程性描述。

（3）HP公司开发了软件质量属性FURPS：
①功能性（Functionality )：评估程序的特征集和能力、所提交功能的普遍性以及整个
系统的安全性。

②易用性(Usability )：通过考虑人为因素、整体美感、一致性和文档来评估。

③可靠性(Reliability)：通过测量故障的频率和严重性、输出结果的精确性、故障平均
时间、故障恢复能力和程序的可预见性来评估。

④性能(Performance) ：度量处理速度、响应时间、资源消耗、吞吐量和效率。

⑤可支持性(Supportability ) ：综合了可扩展性、适应性和耐用性三面的能力。

（4）抽象是人类处理复杂问题的基本方法之一，主要有数据抽象和过程抽象两种。

（5）模式（Pattern）是解决某一类问题的方法论，它将解决某类问题的方法总结归纳到理论高度。

软件模式主要有分析模式、体系结构模式、设计模式和编码模式（又称习惯用
语）四种。

（6）模块化是将软件被划分为独立命名的、可寻址的构件(又被称为模块），把这些构件集成到一起可以满足问题的需求。

（7）信息隐蔽原则建议模块应该具有的特征是：每个模块对其他所有模块都隐蔽自己的设计决策。

（8）通过开发具有“专一”功能和“避免” 与其他模块过多交互的模块，可以实现功能独立。

独立性可以使用内聚性（显示模块相关功能的强度）和耦合性（显示模块间的相互依
赖性）两条定性的标准评估。

（9）求精是一个细化的过程，它和抽象是互补的概念。

（10）重构是在不改变代码(或设计)的外部行为的前提下，改进软件系统内部结构的过程。

通过重构提高模块的内聚性，降低模块间的耦合性，在实施重构前，保证已有足够的测
试用例，以在重构之后进行回归测试。

（11）在设计模型通常定义了用户接口类、业务域类、过程类、持久类和系统类五种不同的设计类。

良定义设计类的四个特征是完整性与充分性、原始性、高内聚和低耦合。

八、第十章进行体系结构设计
（1）软件体系结构的作用是：分析设计在满足需求方面的有效性、在设计变更相对容易的阶段，考虑体系结构可能的选择方案、降低与软件构造相关联的风险。

（2）体系结构风格是一种加在整个系统设计上的变换，其目的在于为系统的所有的构件建立一个结构。

通常分为：以数据为中心的体系结构、数据流体系结构、调用和返回体
系结构、面向对象体系结构和层次体系结构五种风格。

（3）传统的结构化设计需要映射变换流和事务流两种数据流到软件体系结构。

九、第十一章构件级设计建模
（1）构件是系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列接口。

构件级设计定义了数据结构、算法、接口特征和分配给每个软件构件的通
信机制。

（2）基于类的构件基本设计原则：（前四个）
①开关原则：模块对外延具有开放性，对修改具有封闭性。

②LISKOV替换原则（或里氏替换原则）：子类可以替换它们的基类。

③依赖倒置原则：依赖于抽象，而非具体实现。

④接口分离原则：多个用户专用接口比一个通用接口要好。

（3）内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。

按从强到弱排序内聚性：功能内聚、分层内聚、通信内聚、顺序内聚、
过程内聚、暂时内聚、实用内聚。

（4）藕合是类之间彼此联系程度的一种定性度量。

按从强到弱排序耦合性：内容藕合、共用耦合、控制耦合、印记耦合、数据耦合、例程调用耦合、类型使用耦合、包含或者
导入耦合、外部耦合。

（5）模块的高内聚和低藕合是构件设计建模的重要目标。

（6）传统构件的设计常用表示方法有图形化设计表示（程序流程图、N-S图）、表格式设计表示（决策表：条件、动作、条件组合和处理规则）和程序设计语言(PLD)。

十、第十三章软件测试策略
（1）软件测试策略将软件测试用例的设计方法集成到一系列经周密计划的步骤中去，从而使软件构造成功地完成。

任何测试策略都必须包含测试计划、测试用例设计、测试执
行以及测试结果数据的收集与评估。

（2）传统软件的测试策略是将测试分为单元测试、集成测试、确认测试和系统测试。

①单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。

②集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。

③确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错
误。

④系统测试是针对基于计算机系统中的软件，以揭露不符合系统工程中对软件要求的错
误。

（3）单元测试的主要内容包括：模块接口、局部数据结构、边界条件、所有独立路径和所有错误处理路径。

在单元测试中，每个被测模块开发一个驱动(driver)程序和若干个桩
(stub)模块。

（4）集成测试通常采用增量方式，其主要有自顶向下集成和自底向上集成方法。

①自顶向下集成的优缺点：
●优点：不需要驱动模块；能尽早对程序的主要控制和决策机制进行检验，能较早发现
整体性的错误；深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。

●缺点：测试时低层模块用桩模块替代，不能反映真实情况；重要数据不能及时回送到
上层模块。

②自底向上集成的优缺点：
●优点：不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一
层次的簇可并行进行测试，可提高效率。

●缺点：整体性的错误发现得较晚。

（5）回归测试是对已进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。

回归测试集（已经过测试的子集）包括三种不同类型的测试用
例：
①能测试软件所有功能的代表性测试用例
②专门针对可能会被修改影响的软件功能的附加测试
③注重于修改过的软件模块的测试
（6）冒烟测试是一种常用的集成测试方法，它让软件团队频繁地对项目进行评估。

冒烟测试提供了下列好处:
①降低了集成风险
②提高最终产品的质量
③简化错误的诊断和修正
（7）α测试和β测试是确认测试的两种常用方法。

①α测试是由用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。

经α测试后的软件称为β版软件。

②β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通
常不在测试现场。

（8）系统测试是对整个基于计算机的系统进行的一系列测试。

常用的系统测试主要包括：恢复测试、安全测试、压力测试和性能测试。

（9）测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正。

十一、第十四章软件测试战术
（1）软件测试是一个为了发现错误而执行程序的过程，软件测试的目标是用尽可能少的测试用例，来发现尽可能多的软件错误。

（2）软件测试方法主要有白盒测试方法和黑盒测试（又称行为测试）方法。

前者主要根据程序内部的逻辑结构设计测试用例，而后者则主要根据程序完成的功能设计测试用例。

（3）白盒测试的目标：
①对每一个模块中的所有独立路径至少被执行一次
②对所有的逻辑值均需测试真和假
③在上下边界和可操作的范围内执行所有的循环
④检验内部数据结构以确保其有效性
（4）黑盒测试能发现以下类型的错误
①功能不正确或遗漏
②接口错误
③数据结构或外部数据库访问错误
④行为或性能错误，
⑤初始化和终止错误。

（5）常用的白盒测试方法有：逻辑覆盖测试、基本路径覆盖测试、数据流测试和循环测试（6）逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑的覆盖程度。

逻辑覆盖测试主要包括语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖和路径
覆盖。

十二、备注
（1）考试题型：单项选择（30分）、判断（20分）、简答（30分）和应用题（20分）。

（2）简答题大致范围：绝大多数包含在考试大纲中
（3）应用题范围
①根据需求描述，运用UML绘出用例图（注意角色之间、用例之间关系）
②根据需求描述，运用UML绘出设计类图（注意类之间泛化、关联。

如有关联需要确定
关联的多重性）
③根据描述，绘出决策表
④根据程序流程图，设计基本路径测试用例。