软件工程概论

参考答案
第1章
一、填空题
1.C omputer Aided Software Engineering
2.定义阶段、开发阶段、支持阶段
3.可行性研究、项目开发计划、需求分析、软件设计、编码、测试、维护
4.软件危机
5.软件开发、运行、维护
6.瀑布、增量
7.线性
二、选择题
1.B
2.A
3.C
4.A
5.B
6.B
三、问答题
1．答：（1）在计算机软件的开发和维护过程中所遇到的一系列严重问题，长期找不到解决
这些问题的办法，使问题逐渐积累起来，形成了尖锐的矛盾，从而导致了软件危机。

（2）表现：
开发的软件不能满足用户要求；
无完整、规范的文档，难以维护；
项目计划不周，进度拖延；
软件质量差。

（3）原因：
缺乏正确的理论指导，开发人员各行其是；
软件规模越来越大，无开发管理经验；
软件复杂度越来越高，而开发技术不相适应；
缺少先进的开发工具，开发方式落后。

2．答：软件工程是用科学知识和技术原理来定义、开发、维护软件的一门学科。

软件工程研究的主要内容是软件开发技术和软件开发管理两个方面。

在软件开发技术方面，主要是研究软件开发方法、软件开发过程、软件开发工具和环境。

在软件开发管理方面，主要是研究软件管理学、软件经济学、软件心理学等。

3．答：软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。

软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段活动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。

4．答：软件生存周期是指一个软件从提出开发要求开始直到该软件报废为止的整个时期。

把整个生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。

软件生存周期在各阶段有不同的划分。

在划分软件生存周期阶段时，应遵循的一条基本原则是：各阶段的任务应尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件项目开发的组织管理。

通常，软件生存周期包括可行性分析和项目开发计划、需求分析、概要分析、详细分析、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同阶段去完成。

5．答：为了克服瀑布模型的局限性，使开发过程具有一定的灵活性和可修改性，于是产生了增量模型。

它是在瀑布模型的基础上加以修改而形成的。

增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。

而增量模型属于非整体开发模型，它推迟某些阶段和所有阶段中的细节，从而较早地产生工作软件。

增量模型是在项目的开发过程中以一系列的增量方式开发系统。

增量方式包括增量开发和增量提交。

增量开发是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。

增量开发和增量提交可以同时使用，也可以单独使用。

第2章
一、填空题
1．软件可行性研究
2．自顶向下估算、自底向上估算、差别估算法
3．技术、经济、社会
4．项目实施计划、质量保证计划、软件测试计划、文档编制计划、用户培训计划、综合支持计划、软件发布计划
5．验证、确认、评审、审核
6．高级管理者、技术管理者、开发人员、客户、最终用户
二、选择题
1.A
2.D
3.ABCD
4.ABCD
5.ABC
6.ABCD
三、问答题
1．答：软件质量保证是一种应用于整个软件过程的庇护性活动，包括：
（1）质量管理方法
（2）有效地软件工程方法和工具
（3）过程中采用的正是技术评审
（4）多层次的测试策略
（5）对软件文档及其修改的控制
（6）保证与开发标准符合的规程
（7）软件度量及报告机制等等方面的内容
2．答：可行性研究的主要任务是了解用户的要求及现实环境，从技术、经济和社会因素等方面研究并论证本软件项目的可行性，编写可行性研究报告供项目管理人员评审，以便作出是否开发软件项目的决策。

3．答：（1）复查确认系统目标、规模
（2）研究现行系统的工作流程
（3）导出目标系统高层逻辑模型
（4）导出和评价供选择的方案
（5）推荐可行方案
（6）编写可行性研究报告，送审
4．答：（1）项目实施计划（软件开发计划）：这是软件开发的综合性计划，通常应包括任务、进度、人力、环境、资源、组织等多个方面。

（2）质量保证计划：把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动。

（3）软件测试计划：规定测试活动的任务、测试方法、进度、资源、人员职责等
（4）文档编制计划：规定所开发项目应编制的文档种类、内容、进度、人员职责等。

（5）用户培训计划：规定对用户进行培训的目标、要求、进度、人员职责等。

（6）综合支持计划：规定软件开发过程中所需要的支持，以及如何获取和利用这些支持。

（7）软件发布计划：软件开发项目完成后，如何提交给用户。

5．答：（1）定义项目目标，确定软件范围；
（2）把项目按项目范围分解为多个任务；
（3）确定对应每个任务必须执行的活动；
（4）将每个任务分配给一个小组，并为每个开发者分配角色和职责；
（5）用Gantt图或PERT图表示出项目的进度。

6．答：（1）风险识别：确定风险的类型（管理、技术）。

（2）风险分析：评估风险出现的可能性及其后果。

（3）风险规划：指定避免或降低风险的策略。

（4）风险控制：定期进行风险评估，及时修正缓解风险的计划。

7．答：（1）用户验收：根据项目协议中规定的验收标准对系统进行评价，并通过场景演示，测试系统功能性和非功能性需求。

（2）安装：在目标环境下安装、运行系统并提交文档。

（3）总结：总结经验教训，建立团队工作效率的历史档案，以便提高个人和团队整体的软件工程能力。

第3章
一、填空题
1．彻底的解决用户的问题
2．功能需求、性能需求、环境需求、用户界面需求
3．数据流、加工、数据存储、数据的源点或终点
4．手工建立、利用计算机辅助建立并维护
5．功能活动及联系、功能模型
6．数据处理方面、“做什么”、静态模型、控制模型
二、选择题
1 A
2 A
3 C
4 B
5 C
6 C
7 A
三、简答题
1．答：需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约的过程。

需求分析的基本任务是要准确地定义新系统的目标，为了满足用户需求，回答系统必须“做什么”的问题。

本阶段要进行以下几个方面的工作：
（1）问题识别。

（2）分析与综合，导出软件的逻辑模型。

（3）编写文档。

2．答：需求分析的原则如下：
（1）必须能够表达和理解问题的数据域和功能域。

数据域包括数据流、数据内容和数据结构，而功能域反映上述三方面的控制信息。

（2）可以把一个复杂问题按功能进行分解并可逐层细化。

通常软件要处理的问题如果太大太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体功能。

在需求分析过程中，软件领域中的数据、功能和行为都可以划分。

（3）建模。

模型可以帮助分析人员更好地理解软件系统的信息、功能和行为，这些模型也是软件设计的基础。

3．答：数据字典是用来定义数据流图中的各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关因素的一致的定义和详细的描述。

数据字典和数据流图共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分。

数据字典是为了分析人员查找数据流图中有关名字的详细定义而服务的，因此也像普通字典一样，要把所有条目按一定的次序排列起来，以便查阅。

数据字典有以下四类条目：数据流、数据项、数据存储、基本加工。

4．答：需求说明书是需求分析阶段最重要的技术文档之一。

它提供了用户与开发人员对开发软件的共同理解，其作用相当于用户与开发单位之间的技术合同，是今后各阶段设计工作的基础，也是本阶段评审和测试阶段确认与验收的依据。

需求说明书的主要内容如下：
（1）前言：说明项目的目的、范围，所用的术语的定义；用到的缩略语和缩写词；参考资料。

（2）项目概述：产品的描述；产品的功能；用户的特点；一般的约束等。

（3）具体需求：说明每个功能的输入、处理和输出；外部接口需求，包括用户接口、软件接口、硬件接口和通信接口；性能需求；设计约束；其他需求，包括数据库、操作等。

5．答：结构化设计方法的优点：结构化设计方法是软件需求分析中公认的、有成效的、技术成熟、使用广泛的一种方法，它较适合于开发数据处理类型软件的需求分析。

该方法利用图形等
半形式化工具表达需求，简明、易读，也易于使用，为后一阶段的设计、测试、评价提供
了有利条件。

结构化设计方法的缺点：
（1）传统的SA方法用于数据处理方面的问题，主要工具DFD体现了系统“做什么”的功能，但它仅是一个静态模型，没有反映处理的顺序，即控制流程。

因此，不适合描述实时控制系统。

（2）20世纪60年代末出现的数据库技术，使许多大型数据处理系统中的数据都组织成数据库的形式，SA方法使用DFD在分析与描述“数据要求”方面是有局限的，DFD应与数据库技术中的实体联系图结合起来。

ER图能增加对数据存储的细节以及数据与数据之间、数据与处理过程之间关系的理解，还解决了在DD中所包含的数据内容表示问题，这样才能较完整地描述用户对系统的需求。

（3）对于一些频繁的人机交互的软件系统，如飞机订票、银行管理、文献检查等系统，用户最关心的是如何使用它，输入命令、操作方式、系统响应方式、输入格式等等，都是用户需求的重要方面，DFD不适合描述人机界面系统的需求。

SA方法往往对这一部分用自然语言作补充。

（4）描述软件需求的精确性有待提高。

6．该题功能比较简单，首先找出该系统的外部环境，从而获得系统的输入输出。

与该系统打交道的外部实体只有储户，输入有存取款原始单。

该系统经过处理后，输出给储户正式的存款单或结算清单。

这样，该系统的顶层DFD就确定了。

其次，考虑该系统内部功能。

系统要检验用户填写单据的合法性及区分存款还是取款，然后分别进行
存款处理和取款处理。

存款处理要登记储户的存款信息，需要建立数据存储文件；而取款处理要读取数据存储文件及查阅储户的信息，取款后要修改储户信息。

另外还要通过银行自己的利率计算存款利率。

根据以上分析画出该系统的数据流图(未分层)如下图：
7．顶层图：
数据流条目：
报名单＝姓名＋性别＋年龄＋学历＋身份证号码＋地区＋职业＋待考专业
成绩单＝姓名＋专业＋｛科目＋考试时间＋成绩｝41
考生通知单＝姓名＋专业＋｛科目＋考试时间＋考试地点｝？？
准考证＝编号＋姓名＋性别＋年龄＋身份证号
总报名单＝｛报名单｝＋各专业人数＋总人数
数据项条目：
成绩：别名：平均成绩
类型：实型
长度：6位，小数点后一位
准考证编号：别名：无
类型：字符串
长度：10
取值范围及含义：前四位表示专业，后六位表示本专业内编号
……
加工条目：
加工名称：EMS
编号：无
输入/出：略
加工逻辑：对全市的成人自学考试进行管理，主要功能有：报名、考试、成绩管理等。

0层图：
其他条目略。

数据存储条目：
文件名：考生记录
组成：准考证编号＋姓名＋性别＋年龄＋地区＋职业＋｛科目＋成绩｝1 15
组织方式：索目文件，以准考证编号为主关键字
……
第4章
一、填空题
1．“程序＝算法＋数据结构”、系统总体结构的设计和规范
2．构件
3．共享数据库
4．模块化分解、面向数据的分解、面向事件的分解、由外往内的设计、面向对象的设计
5．人的能力
6．直接操纵、菜单选择、表格填写、命令语言、自然语言
7．模型－视图－控制器
二、选择题
1.Ａ
2.Ｄ
3.Ｄ
4.Ｃ
5.Ａ
6.Ｂ
7.Ｂ
三、问答题
1．答：在软件需求分析阶段，已经搞清楚了软件“做什么”的问题，并通过需求说明书将这些需求描述了出来，这也是目标系统的逻辑模型。

进入了设计阶段，要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型。

即着手实现软件的需求，并将设计的结果反映在“设计说明书”文档中，所以软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。

概要设计的基本任务有：
（1）设计软件系统结构（简称软件结构）
（2）数据结构及数据库设计
（3）编写概要设计文档
（4）评审
2．答：（1）结构模型：是构件、连接件（定义构件之间交互规则、消息协议的构造模块）有组织的集合。

反映系统的重要语义内容，包括系统的配置、约束等。

（2）框架模型：与结构模型类似，不侧重细节，侧重于系统的整体结构（模式）。

（3）动态模型：补充模型，强调系统的行为性质。

（4）过程模型：注重系统必须适应业务和技术的过程。

（5）功能模型：一组功能构件按层次组成，下层向上层提供服务，是一种特殊的框架模型。

3．答：以下设计原则适用于所有的用户设计：
（1）用户熟悉：界面所使用的术语和概念是来自于用户的经验，这些用户是将要使用系统最多的人。

（2）一致性：界面应该是一致的，命令、菜单格式相同，参数以相同方式传递，减少用户学习时间。

（3）意外最小化：永远不要让用户对系统的行为感到吃惊，类似的操作应该有类似的效果。

（4）可恢复性：界面应该有一种机制来允许用户从错误中恢复。

（5）用户指南：在错误发生时界面应该提供有意义的反馈，并具有用户帮助功能。

（6）用户差异性：界面应该为不同类型用户提供合适的交互功能。

4．答：把用户界面中的表示、交互和实体相分离是该模型的基础。

MVC是一种用来使用户界面层和系统的其他部分分离的体系结构模式。

MVC不仅有助于增强用户界面层的层内聚，而且有助于降低用户界面与系统其余部分以及UI本身各部分之间的耦合。

MVC模式使系统的功能层（模型）同用户界面的两个方面分离：试图（view）和控制器（controller）。

用户能够用适当的交互方式与每种表示形式进行交互。

要显示的数据被封装到一个模型对象中。

每个视图都是模型的一种显示表示方式。

每个模型对象可能有许多独立的视图对象与之关联，例如表示数字数据的模型可能有一个直方图的或一个表格的视图。

每个视图都有一个的处理用户输入和设备交互的控制器对象。

使用MVC模式的好处：
（1）三个构件可独立设计
（2）提高内聚，降低耦合：构件之间通信信道最小且易查找。

（3）增加重用：视图和控制器通常会使用大量的可重用构件作为各种UI控件。

（4）灵活设计：很易通过改变视图或控制器来改变UI。

（5）可测试性设计：可脱离UI层测试应用程序。

5．答：（1）算法设计
（2）数据结构设计
（3）物理设计
（4）其他设计，例如代码设计、输入/输出格式设计、人机对话设计。

（5）编写详细设计说明书
（6）评审
6．答：（1）耦合性是软件结构中各构件间相互联系紧密程度的一种度量。

包括：无直接耦合、数据耦合、标记耦合、控制耦合、公共耦合、内容耦合。

（2）内聚性是一个构件内部各种元素彼此结合的紧密程度的度量。

包括：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。

7．答：（1）评估软件结构的初始模型以降低耦合并提高内聚。

（2）高层高扇出使最小化；当深度增加时（特别是底层）争取提高扇入。

（3）将模块的作用范围限制在模块的控制范围内。

作用范围：受模块内一个判定影响的所有模块的集合。

控制范围：模块本身及其所有下属模块的集合。

（4）评估模块接口以降低复杂度和冗余并提高一致性。

（5）定义功能可以预测的模块，（如对于相同的输入，输出是恒定的），但要避免过分限制模块（如数据结构的大小、控制流的选择、外部接口的模式等限制）。

第5章
一、填空题
1．动态测试方法、静态测试方法、黑盒测试、白盒测试
2．确定错误的原因和位置、改正错误、纠错
3．所调用的模块、返回被测模块所需的信息
4．划分等价类、确定测试用例
5．等价类、边界值
二、选择题
1.C
2.D
3.B
4.B
5.B
6.A
7.D
三、问答题
1．答：（1）测试用例不但应有输入数据，还应有预期的输出数据。

这样便于对照检查，做到“有的放矢”。

（2）测试用例不仅选用合理的输入数据，还要选择不合理的输入数据。

这样能更多的发现错误，提高程序的可靠性。

对于不合理的输入数据，要将反馈信息提供给用户。

（3）除了检查程序是否做了它应该做的事，还可检查程序是否做了它不应该做的事。

例如程序正确地打印出用户所需信息的同时还是否打印出用户并不需要的多余信息。

（4）应指定测试计划并严格执行，排除随意性。

（5）长期保留测试用例，为以后进行的回归测试和维护提供方便。

（6）对发现错误较多的程序段，应进行更深入的测试。

因为在修改错误过程中容易引入新的错误。

（7）为了达到最有效的测试效果，程序员避免测试自己的程序。

2．答：黑盒测试是把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程。

只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能需求。

因此，黑盒测试又称为功能测试或数据驱动测试。

通过黑盒测试主要发现以下错误：
（1）是否有不正确或遗漏了的功能。

（2）在接口上，能否正确地接受输入数据，能否产生正确的输出信息。

（3）访问外部信息是否有错。

（4）性能上是否满足要求等等。

白盒测试是把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。

3．答：软件测试一般分为四个步骤：
（1）单元测试（也称模块测试）：针对软件设计的基本单元—程序模块，进行正确
性检验的测试工作。

目的在于发现各个模块内部可能存在的各种差错。

单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行、独立地进行测试；
（2）集成测试（也称组装测试，联合测试）：在单元测试的基础上，将所有模块按设计要求集成在一起进行测试，以检验总体设计中各模块间的接口设计问题、模块之间的相互影响、上层模块存在的各种差错及全局数据结构对系统的影响等方面。

（3）确认测试（也称验收测试，有效性测试）：主要检验软件的功能和性能是否与需求说明书中的规定一致。

（4）系统测试：将软件系统作为一个元素，放入整个实际的计算机系统中，与计算机硬件、其他软件、使用人员等系统元素结合在一起，在实际使用环境下进行综合全面的测试。

4．答：集成测试的方法主要有非渐增式测试和渐增式测试。

（1）非渐增式测试：该测试是首先对每个模块分别进行单元测试，然后再把所有的模块按设计要求组装在一起进行的测试。

（2）渐增式测试：该测试是逐个把未经过测试的模块组装到已经测试过的模块上去，进行集成测试。

每加入一个新模块进行一次集成的测试，重复此过程直至程序组装完毕。

非渐增式测试和渐增式测试的区别有如下几点：
（1）非渐增式方法把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。

而渐增式测试把单元测试与集成测试合在一起，同时完成。

（2）非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量较少。

（3）渐增式可以较早地发现接口之间的错误，非渐增式最后组装时才发现。

（4）渐增式有利于排错，发生错误往往和最近加进来的模块有关，而非渐增式发现接口错误推迟到最后，很难判断是哪一部分接口出错。

（5）渐增式比较彻底，已测试的模块和新的模块组装在一起再测试。

（6）渐增式占用的时间较多，但非渐增式需更多的驱动模块、桩模块，也占用一些时间。

（7）非渐增式开始可并行测试所有模块，能充分利用人力，对测试大型软件很有意义。

5．答：可靠性：系统在给定的时间间隔内，根据需求说明成功地运行的概率。

也可以说可靠性是系统依照需求指定的功能不失败运作的可能性。

可用性：系统在给定的时间点上根据需求说明成功地运行的概率。

也可以说可用性是当有请求时（即在一定时刻）系统能执行有用服务的可能性。

可靠性与长期的行为有关，而可用性描述时间中某一给定点上的事情。

对于硬件，有的东西可能是高可靠的，但在时间的某一特定点上可能是不可用的。

同样的概念也适用于软件系统。

可靠性、可用性是相互依赖的系统特性。

都反映了用户对系统的信任程度。

如果系统是不可靠的，就很难保证系统的安全性、保密性等许多特性。

如果系统不可用，用户将无法接受。

第6章
一、填空题
1．改正性维护、适应性维护、增强性维护
2．人员的不稳定、合同责任、维护人员技术水平、系统结构衰退
3．软件再工程
4．生产率
5．可维护性、可使用性、可靠性
二、选择题
1.D
2.A
3.C
4.C
5.C
6.A
7.C
三、问答题
1．答：软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。

（1）校正性维护
在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试
中发现，因此必然有一部分隐含的错误被带到维护阶段来。

这些隐含的错误在某些特定的使用环境下会暴露出来。

为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。

校正性维护占整个维护工作的20%左右。

（2）适应性维护
随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也
在不断发生变化。

为了使应用软件适应这种而修改软件的过程称为适应性维护。

这种维护活动占整个维护活动的25%。

（3）完善性维护
在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。

这
是因为用户的业务会发生变化，组织机构也会发生变化。

为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的50%。

（4）预防性维护
为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。

这是为
以后进一步的运行和维护打好基础，占整个维护工作的4%。

2．答：软件可维护性的定义：软件能够被理解、校正、适应及增强功能的容易程度。

软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，也是用户十分关心的几个问题。

软件的可维护性是软件开发阶段的关键目标。

影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。

软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和。