admin管理员组

文章数量:1600155

软件工程—期末复习题

选择

在结构化分析方法中，（ C ）表达系统内部数据运动的图形化技术。
A、数据字典
B、实体关系图
C、数据流图
D、状态转换图

数据流图（Data Flow Diagram，DFD）是一种图形化的工具，用于描述系统中数据的流动和处理过程。数据流图能帮助分析人员和开发人员更好地理解和描述系统的功能和数据流程，从而进行需求分析、系统设计和功能实现。

随着软硬件环境变化而修改软件的过程是（ B ）。
A、校正性维护
B、适应性维护
C、完善性维护
D、预防性维护

适应性维护是指根据软硬件环境的变化对软件进行修改的过程。适应性维护旨在确保软件在新的环境下继续正常运行，并充分利用新的技术和功能。

关于极限编程（XP）的优点，以下哪个说法是正确的？（ A ）
A. 提供高度灵活性和响应变化能力
B. 强调个人技能而忽视团队合作
C. 仅适用于小型项目
D. 降低软件质量和可维护性

极限编程（XP）注重高度灵活性和快速响应变化的能力。它通过迭代开发、持续交付和频繁反馈的方式，使团队能够适应需求变化，并在项目进展中及时调整。

软件工程的敏捷理念强调以下哪个重要方面？（ C ）
A. 高度规范化的流程和文档
B. 个人技能的发展和提升
C. 自组织团队的控制力
D. 长期的计划和预测

软件工程的敏捷理念强调4个关键问题：

自组织团队对所开展工作具有控制力的重要性；
团队成员之间以及开发参与者和客户之间的交流与合作；
对“变更代表机遇”的认识；
强调快速交付让客户满意的软件。

15、软件详细设计的主要任务是确定每个模块的（ A ）。
A、算法和使用的数据结构
B、外部接口
C、功能
D、编程
A、算法和使用的数据结构

软件详细设计的主要任务是确定每个模块的算法和使用的数据结构。在软件详细设计阶段，开发人员需要具体规划每个模块的实现方式，包括选择适当的算法和数据结构来支持模块的功能实现。通过设计和选择恰当的算法和数据结构，可以确保软件在运行时能够高效、准确地完成其功能。

其他选项的解释：
B、外部接口：虽然外部接口在软件设计中也很重要，但它更多涉及到系统级的设计和交互，而不是每个模块的具体实现。
C、功能：功能在软件设计中是一个重要考虑因素，但软件详细设计更侧重于模块级别的实现细节。
D、编程：编程是软件实现的具体过程，而软件详细设计更关注于模块功能的具体实现方式，包括算法和数据结构的选择，而不是编程语言本身。

17、需求分析是（ A ）。
A、软件开发工作的基础
B、软件生存周期的开始
C、由系统分析员单独完成的
D、由用户自己单独完成的

A、软件开发工作的基础

需求分析是软件开发工作的基础。在软件开发过程中，需求分析是确定系统或软件应具备的功能、性能和约束条件的过程。它涉及与用户和相关利益相关者的交互，以了解他们的需求、期望和问题。通过需求分析，开发团队能够确保软件开发的目标和范围明确，并为后续的系统设计和开发工作提供指导。

其他选项的解释：
B、软件生存周期的开始：需求分析是软件生命周期的一个重要阶段，但不是生命周期的开始。软件生命周期包括需求分析、设计、编码、测试、部署和维护等多个阶段。
C、由系统分析员单独完成的：需求分析通常是由一个专门的需求分析团队或者由整个开发团队共同完成的，而不是由单独的系统分析员完成。
D、由用户自己单独完成的：虽然用户的参与和反馈在需求分析中至关重要，但需求分析通常需要专业的分析人员与用户合作，以确保需求的准确性和可行性。用户通常需要与分析人员一起完成需求分析工作。

18、极限编程（XP）模型在处理增量原型方面与螺旋模型有何不同？（ABCD）
A、迭代周期的长度
B、风险管理的方法
C、客户参与程度
D、项目控制的重点

迭代周期的长度：极限编程（XP）模型的迭代周期通常较短，而螺旋模型的迭代周期相对较长。

风险管理的方法：螺旋模型更注重风险管理和风险驱动的开发，而极限编程通过测试驱动开发（TDD）和持续集成等方法来管理风险。

客户参与程度：极限编程强调与客户的密切合作和持续交流，客户作为团队的一员参与到开发过程中。而螺旋模型中的客户参与相对较少。

项目控制的重点：极限编程采用简单的规则和实践来控制项目，如规划游戏、持续集成和团队内部的自我组织。螺旋模型更注重阶段之间的控制和规划。

19、软件维护时(maintenance) ，为扩充功能和改善性能而进行的修改，主要对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征，这种为改善性能、可维护性或其他软件属性而进行的维护一般被称为（ C ）。
A、适应性维护
B、纠错性维护
C、完善性维护
D、逆向(再生)工程

适应性维护：指为了适应环境变化或新需求而对软件进行修改的维护类型，通常是通过添加新功能或进行适应性调整来应对变化。
纠错性维护：指修复已经发现的软件缺陷或错误的维护类型**，旨在使软件恢复到预期的功能状态。
完善性维护：指对已有软件进行修改以改进其性能、可读性、可维护性或其他非功能特征的维护类型。
逆向(再生)工程：指对已有软件系统进行分析和研究，以获取其内部结构、功能和设计原理等信息的过程。**

20、软件测试分成几个步骤，其中的（ A ）是在模拟的环境下，运行黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
A、确认(有效性)测试
B、集成(组装)测试
C、模块(单元)测试
D、并行(平行)测试

确认(有效性)测试：确认测试是一种验证软件是否符合需求的测试方法，旨在确保软件满足用户的期望和规格说明书的要求。

集成(组装)测试：集成测试是在将多个模块或组件组装在一起后进行的测试，以验证它们在联合工作时是否正常运行。

模块(单元)测试：模块测试是对软件中的独立模块或单元进行测试，以验证其功能的正确性和预期行为。

并行(平行)测试：并行测试是指在相同环境中同时运行两个或多个版本的软件，以比较它们之间的性能、功能和其他特性的差异。

21、软件设计(Software Design)是软件开发的关键步骤，直接影响软件质量。下述（ B ）不是软件设计阶段所应包含的工作?
A、软件(体系)结构
B、软件过程(构件)
C、用户接口
D、软件风险分析

B、软件过程(构件)

在软件设计阶段，通常应包含以下工作：

A、软件(体系)结构：设计软件的整体结构，包括组织模块、定义组件和它们之间的关系。软件结构设计旨在确保系统的组织和架构满足功能和性能要求。

C、用户接口：设计软件与用户之间的接口，包括界面设计、用户交互设计和用户体验设计。用户接口设计旨在提供用户友好的界面，使用户能够轻松使用和操作软件。

D、软件风险分析：进行软件风险分析，识别和评估与软件开发和使用相关的潜在风险。软件风险分析有助于制定适当的风险管理策略，以减少风险对软件质量和项目成功的影响。

选项B中的软件过程(构件)并不是软件设计阶段所应包含的工作。软件过程或构件更多涉及到软件开发过程中的组织、管理和流程方面的工作，与软件设计阶段的具体设计决策和设计文档编制不直接相关。

22、下面哪一个选项不属于系统测试（B）。
A、回归测试
B、安全测试
C、性能测试
D、压力测试

回归测试：回归测试是在进行系统修改或更新后执行的测试，旨在确保新的修改不会影响现有功能的正确性。

安全测试：安全测试是验证系统在安全方面的漏洞和弱点的测试，以保护系统免受未经授权的访问、数据泄露或其他安全威胁。

性能测试：性能测试是评估系统在各种负载和压力条件下的性能表现，包括响应时间、吞吐量和资源利用率等方面。

压力测试：压力测试是通过将系统置于负载或压力的最大限度下进行测试，以评估系统的稳定性和可靠性，以及在超负荷条件下的性能表现。

23、软件工程是一门迅速发展的新兴学科，现已经成为计算机科学的一个重要分支。软件工程是一种层次化的技术，软件工程包括（ C ）三个要素。
A、技术、方法和工具
B、封装、继承、多态
C、方法、工具和过程
D、过程、模型、方法

24、软件质量是难于定量度量的软件属性，但是仍然能够提出许多重要的软件质量指标，这些指标主要从管理的角度对软件质量进行度量。在这些因素中，软件系统在硬件故障、操作错误等意外情况下仍然能够做出适当反应的程度称为软件的（ B ）。
A.可靠性
B.健壮性
C.可用性
D.完整性

B.健壮性

在给定的选项中，软件系统在硬件故障、操作错误等意外情况下仍然能够做出适当反应的程度被称为软件的健壮性。健壮性指的是软件系统在面对异常或非预期情况时的稳定性和可靠性。健壮的软件能够正确处理异常情况，避免系统崩溃、数据损坏或其他严重问题，并能够在错误发生后进行恢复或继续运行。

其他选项的解释：
A.可靠性：可靠性指软件系统在给定时间和条件下正确执行所需功能的能力，与健壮性有一定的关联，但健壮性更强调在异常情况下的反应和处理能力。
C.可用性：可用性指软件系统对于用户而言的易用性和可访问性，与健壮性有区别，健壮性更关注软件系统在异常情况下的表现。
D.完整性：完整性指软件系统的数据或信息的完整性和准确性，与健壮性的概念不同，健壮性更关注软件系统的稳定性和处理异常的能力。

25、软件测试分成几个步骤，其中的（ D ）通常应该先进行“桌前检查"和/或“步行检查"，再以白盒法为主，辅以黑盒法进行动态测试。该类测试可以并行进行。
A、确认(有效性)测试
B、验收(接收)测试
C、模块(单元)测试
D、并行(平行)测试

26、数据流图(DFD: Data Flow Diagram)描绘系统的逻辑模型。它是软件开发（ D ）阶段经常使用的工具。
A、软件维护
B、软件测试
C、详细(过程)设计
D、需求分析

数据流图可以通过图形化的方式描述系统的功能、数据流动和处理过程，帮助分析人员和开发团队理解系统的需求和功能。在需求分析阶段，数据流图可以用于捕捉和表示用户需求、业务过程以及数据在系统中的流动和处理。

32、（ D ）是软件投入市场前由支持软件预发行的客户对FLURPSS进行测试，是软件的多个用户在实际使用环境下进行的测试，开发者通常不在测试现场。
A、验收测试
B、功能测试
C、α测试
D、β测试

验收测试：验收测试是在软件开发完成后，由用户或客户进行的测试，以确认软件是否满足其要求和期望。验收测试是软件开发的最后阶段，开发者和用户共同参与。

功能测试：功能测试是验证软件的功能是否按照规格说明书和需求定义进行设计和实现的测试。它主要关注软件的功能是否符合预期，功能测试可以在开发过程的各个阶段进行。

α测试：α测试是在软件开发的早期阶段由开发者或内部测试团队进行的测试。它主要用于发现和修复软件中的缺陷和问题，在软件投入市场前的内部测试阶段进行。

β测试：β测试是软件的多个用户在实际使用环境下进行的测试，通常由终端用户或特定目标用户参与，开发者通常不在测试现场。

38、采用甘特(Gantt)图表示软件项目进度安排。下列说法中不正确的是（ C ）。
A、一种按照时间进度标出工作活动，常用于项目管理的图表。
B、以图示的方式通过活动列表和时间刻度形象地表示出活动顺序与持续时间。
C、纵轴表示时间，横轴表示活动，线条表示活动完成情况。
D、直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。

甘特图的纵轴表示活动，横轴表示时间。

44、可行性研究又称为可行性分析，目的是避免盲目投资，减少不必要的损失。下列（ C ）不是可行性分析阶段的任务。
A、确定项目规模和目标
B、确定资源(人力、硬件、软件等)需求
C、建立新系统的高层逻辑模型
D、提出实现高层逻辑模型的各种方案，并推荐可行的方案

可行性研究是在项目初期进行的一项工作，旨在评估项目的可行性和可行性方案的可行性。在可行性分析阶段，主要任务包括确定项目规模和目标、确定资源需求（人力、硬件、软件等）、提出实现方案并推荐可行的方案。

"建立新系统的高层逻辑模型"不是可行性分析阶段的任务，而是在系统设计阶段进行的工作，用于描述系统的逻辑结构和组成部分。

51、结构化程序设计（SP：Structured Program）由荷兰科学家Di jkstra首先提出，它是具有一定限制的程序设计方法，下述的（ D ）不是结构化程序设计所要求遵循的基本原则：
A、只使用三种程序基本结构
B、使用自顶向下，逐步求精的方式编程
C、保持模块的单入口、单出口
D、有限制地使用switch语句

D、有限制地使用switch语句

结构化程序设计要求遵循以下基本原则：

A、只使用三种程序基本结构：结构化程序设计鼓励使用顺序结构（顺序执行语句）、选择结构（条件语句，如if-else语句）和循环结构（循环语句，如for循环、while循环）这三种基本结构，以确保程序的可读性和可维护性。

B、使用自顶向下，逐步求精的方式编程：结构化程序设计强调将大问题分解为小问题，并逐步细化，从高层次到低层次进行编程。这种自顶向下的设计方法有助于提高程序的可理解性和可测试性。

C、保持模块的单入口、单出口：结构化程序设计要求每个模块（子程序或函数）具有单一的入口和单一的出口。这有助于模块的独立性和可测试性，并减少程序中的混乱和复杂性。

D、有限制地使用switch语句并不是结构化程序设计所要求遵循的基本原则。尽管结构化程序设计主张使用条件语句（如if-else语句）来进行选择，但并没有明确规定对于switch语句的使用有限制。在一些情况下，switch语句可以是合理的选择，但在其他情况下，可能更倾向于使用if-else语句或其他结构化的方式来实现相同的逻辑。

53、单元测试的测试用例主要根据（ D ）的结果来设计。
A、需求分析
B、源程序
C、概要设计
D、详细设计

D、详细设计

单元测试的测试用例主要根据详细设计的结果来设计。详细设计是在需求分析和概要设计之后，更加具体地定义了系统的组件、模块和其内部结构，包括输入、输出和内部逻辑。在详细设计中，确定了每个模块的功能和接口规范，这为编写单元测试提供了依据。

根据详细设计，可以确定模块的输入值、边界条件和预期输出，进而设计相应的测试用例来验证模块的正确性。测试用例应该覆盖模块的各种情况和路径，以尽可能地发现潜在的错误和缺陷。

其他选项的解释：
A、需求分析：需求分析是确定系统或软件的功能、性能和约束条件的过程，它不直接用于设计单元测试的测试用例。
B、源程序：源程序是编写代码的结果，它是在详细设计的基础上实现的，因此单元测试的测试用例并不主要根据源程序来设计。
C、概要设计：概要设计是在需求分析之后，定义系统的整体结构和组件之间的关系，它提供了设计系统的框架，但不提供足够的细节来设计单元测试的测试用例。

54、类构件的重用方式有多态重用、继承重用和（C）。
A、实例重用
B、重载重用
C、代码重用
D、方法重用

C、代码重用

类构件的重用方式主要包括多态重用、继承重用和代码重用。

  • 多态重用：多态是面向对象编程的一个重要特性，它允许以统一的方式使用不同类的对象，实现灵活的代码重用。通过多态，可以通过父类或接口类型引用对象，并根据实际对象的类型调用相应的方法。

  • 继承重用：继承是面向对象编程中的另一个重要特性，通过继承，一个类可以从另一个类派生，并继承父类的属性和方法。这种重用方式允许子类直接使用父类的代码和功能。

  • 代码重用：代码重用是通过将可复用的代码块封装为独立的函数、类或模块，并在其他地方多次调用来实现重用。这种重用方式不依赖于继承或多态，而是通过调用可重用的代码来实现功能的重用。

选项A、实例重用：实例重用并不是类构件的常见重用方式。实例重用通常指在运行时复制或重用现有的对象实例，而不是重用类本身。

选项B、重载重用：重载是指在同一类中使用相同名称但参数列表不同的多个方法，以便根据不同的参数调用相应的方法。重载重用主要解决同一个类中方法的多态性。

选项D、方法重用：方法重用在本质上与多态重用是相同的，因为多态性是通过方法的动态绑定来实现的。因此，选项D的方法重用可以被看作是多态重用的一种形式。

55、在白盒测试技术测试用例的设计中，（ B ）是最强的覆盖标准。
A、语句覆盖
B、路径覆盖
C、条件组合覆盖
D、判定覆盖

路径覆盖是一种白盒测试方法，它要求测试用例能够覆盖软件程序的所有可能路径。
语句覆盖要求测试用例能够覆盖软件程序的每个语句，但并不保证覆盖所有可能的路径。
条件组合覆盖是一种基于条件的覆盖标准，要求测试用例能够覆盖所有条件的组合情况。它通常用于测试具有复杂条件逻辑的程序。
判定覆盖是一种要求测试用例覆盖所有可能的判定结果的覆盖标准，它关注程序中的判断语句和判断结果。

从最弱的覆盖标准到最强的覆盖标准，可以按照以下顺序进行排序：
语句覆盖：要求测试用例能够覆盖到被测程序中的每个语句至少一次。
判定覆盖：要求测试用例能够覆盖到每个条件判定的真假两个结果。
条件组合覆盖：要求测试用例覆盖到所有可能的条件组合。
路径覆盖：要求测试用例能够覆盖到被测程序中的每条可能的路径。

从上述排序可以看出，语句覆盖是最弱的覆盖标准，只要求覆盖每个语句至少一次。判定覆盖要求进一步覆盖每个条件判定的真假两个结果。条件组合覆盖比判定覆盖更为细粒度，要求覆盖到所有可能的条件组合。而路径覆盖是最强的覆盖标准，要求覆盖到被测程序中的每条可能的路径，包括各种条件分支和循环结构。

57、软件开发的结构化生命周期方法将软件生命周期划分成（ C ）。
A、计划阶段、开发阶段、运行阶段
B、计划阶段、编程阶段、测试阶段
C、总体设计、详细设计、编程调试
D、需求分析、功能定义、系统设计

C、总体设计、详细设计、编程调试

软件开发的结构化生命周期方法将软件生命周期划分成总体设计、详细设计和编程调试三个阶段。

  1. 总体设计阶段：在这个阶段，对软件系统进行整体设计，确定系统的结构和组成模块，定义模块之间的接口和关系，以及确定整体的软件架构。总体设计阶段关注系统的高层逻辑和结构，确定系统的框架。

  2. 详细设计阶段：在总体设计阶段完成后，进入详细设计阶段。在这个阶段，对系统的每个模块进行详细设计，包括定义模块的功能、接口、数据结构和算法等。详细设计阶段关注模块的内部逻辑和实现细节。

  3. 编程调试阶段：在详细设计阶段完成后，进入编程调试阶段。在这个阶段，根据详细设计的要求，实际编写和实现软件代码，并进行调试和测试，确保软件的功能正确性和稳定性。

其他选项的解释：
A、计划阶段、开发阶段、运行阶段：这个选项涵盖了软件开发过程的一些常见阶段，但并不是结构化生命周期方法中所特有的划分方式。
B、计划阶段、编程阶段、测试阶段：这个选项也包含了软件开发过程的一些常见阶段，但同样不是结构化生命周期方法中的划分方式。
D、需求分析、功能定义、系统设计：这个选项给出了软件开发过程中的一些常见活动，但并不是结构化生命周期方法中所特有的划分方式。

58、可行性研究主要从以下几个方面进行研究：（ B ）
A、技术可行性，经济可行性，操作可行性
B、技术可行性，经济可行性，系统可行性
C、经济可行性，系统可行性，操作可行性
D、经济可行性，系统可行性，时间可行性

B、技术可行性，经济可行性，系统可行性

可行性研究是在项目或计划开始之前进行的评估，旨在确定项目的可行性和可行性的程度。可行性研究主要从以下几个方面进行研究：

  1. 技术可行性：评估项目所需的技术能力、技术资源和技术难度。这包括评估所需技术是否可行、可用性和适用性，以及是否有足够的技术能力来完成项目。

  2. 经济可行性：评估项目在经济上的可行性，包括成本估算、收益预测、投资回报率等。这包括评估项目的投资成本、运营成本、预期收益和盈利能力，以确定项目的经济可行性。

  3. 系统可行性：评估项目对现有系统和环境的影响和适应性。这包括评估项目与现有系统的兼容性、整合性以及对组织流程和业务流程的影响，以确定项目的系统可行性。

其他选项的解释：
A、操作可行性：操作可行性是指评估项目在操作层面的可行性，包括项目的操作复杂度、操作流程和操作资源等。尽管操作可行性在项目评估中也是一个重要的考虑因素，但不是可行性研究的主要方面。
C、时间可行性：时间可行性是指评估项目在时间上的可行性，包括项目的时间要求、项目进度安排和项目的时效性。尽管时间可行性在项目评估中也是一个重要的考虑因素，但不是可行性研究的主要方面。

59、黑盒测试在设计测试用例时，主要研究（ A ）。
A、需求规格说明于概要设计说明
B、详细设计说明
C、项目开发计划
D、概要设计说明与详细设计说明

A、需求规格说明与概要设计说明

黑盒测试是一种测试方法，侧重于对软件系统的功能和行为进行测试，而不关注内部实现细节。在设计黑盒测试用例时，主要研究以下两个方面：

  1. 需求规格说明：黑盒测试的一个重要依据是软件的需求规格说明，即对系统功能和行为的描述。测试人员通过仔细研究需求规格说明，了解系统应该具备的功能和行为，从而设计出能够覆盖这些需求的测试用例。

  2. 概要设计说明：概要设计说明是对系统的整体结构和组件之间的关系进行描述的文档。测试人员可以参考概要设计说明，了解系统的组件和模块的关系，从而设计出能够覆盖系统整体结构和各个组件之间交互的测试用例。

其他选项的解释：
B、详细设计说明：详细设计说明主要描述系统的内部实现细节，包括各个模块的详细设计和算法等。黑盒测试不关注内部实现细节，因此详细设计说明对于黑盒测试用例的设计并不是主要研究对象。
C、项目开发计划：项目开发计划主要涉及项目的进度安排、资源分配等方面，与黑盒测试用例的设计关系较小。
D、概要设计说明与详细设计说明：概要设计说明和详细设计说明都描述了系统的设计和结构，但黑盒测试主要关注系统的功能和行为，因此更侧重于概要设计说明中对系统整体结构和组件之间关系的描述。详细设计说明中的内部实现细节对黑盒测试用例的设计影响较小。

60、根据缺陷排除效率的定义，假设一个软件项目在发布前发现了100个缺陷，而发布后又发现了50个缺陷。计算该项目的缺陷排除效率（DRE）是多少？（ C ）
A、0.33
B、0.5
C、0.67
D、0.75

缺陷排除效率（Defect Removal Efficiency，DRE）是指在软件开发生命周期中成功修复的缺陷数量与总缺陷数量之比，用于衡量软件开发过程中缺陷修复的效率。

根据给定的信息，软件项目在发布前发现了100个缺陷，而发布后又发现了50个缺陷。总缺陷数量为100 + 50 = 150个。

缺陷排除效率（DRE）计算公式为**：DRE = (N - M) / N，其中N表示总缺陷数量，M表示发布后发现的缺陷数量**。

在这个例子中，N = 150，M = 50。将这些值代入公式计算：

DRE = (N - M) / N = (150 - 50) / 150 = 100 / 150 = 0.67

因此，该项目的缺陷排除效率（DRE）为0.67。

选项C、0.67 正确。

73、在传统软件工程环境中，以下哪个描述最符合控制构件的特点？（ B ）
A、完成部分或全部用户的需求
B、协调问题域中所有其他构件的调用
C、完成问题域所需相关处理的功能
D、实现构件之间的接口

控制构件：位于高层，协调问题域中所有其他构件的调用；
问题域构件：位于底层，完成部分或全部用户的需求；
基础设施构件：完成问题域所需相关处理的功能。

74、下面哪个原则适用于构件级设计，使得产生的设计在发生变更时能够适应变更并且减少副作用的传播？（ A ）
A、开闭原则 (The Open-Closed Principle, OCP)
B、Liskov替换原则 (Liskov Substitution Principle, LSP)
C、依赖倒置原则 (Dependence Inversion Principle, DIP)
D、接口分离原则 (Interface Segregation Principle, ISP)

开闭原则：模块应该对外延具有开放性，对修改具有封闭性;
Liskov替换原则：子类可以替换它们的基类;
依赖倒置原则：依赖于抽象，而非具体实现;
接口分离原则：多个用户专用接口比一一个通用接口要好。

试卷

class JobQueueClass
{
	public:
		int queueLength;
		int queue[25];
	public:
		void initializeJobQueue();
		void addJobToQueue();
		void removeJobFromQueue();
}

JobQueueClass 定义如上图，则该类的内聚情况属于（ B ）。
A、实用内聚
B、功能内聚
C、顺序内聚
D、通信内聚

功能内聚是指模块或类内的各个成员函数共同实现一个特定的功能。在给定的代码中，JobQueueClass 类包含了一系列与作业队列相关的操作函数，包括初始化队列、添加作业到队列、从队列中移除作业等。这些函数共同实现了作业队列的功能，因此属于功能内聚。

其他选项的解释：

实用内聚：模块或类内的成员函数用于实现一组相关的操作，但功能之间没有明显的关联。
顺序内聚：模块或类内的成员函数按照顺序执行，其中一个函数的输出作为下一个函数的输入。
通信内聚：模块或类内的成员函数之间通过共享数据进行通信。

2、关注点分离、模块化、抽象、信息隐蔽概念的直接产物是模块的（ C ）。
A、独立性
B、重构
C、封装
D、具体化

封装是指将模块内部的实现细节隐藏起来，只暴露对外部可见的接口，从而实现模块与外部的隔离和独立性。关注点分离、模块化、抽象以及信息隐蔽的概念都有助于实现封装。

其他选项解释：

独立性：模块独立于其他模块，可以单独进行开发、测试和维护。

重构：重构是对现有代码的改进和优化，旨在提高代码的质量和可维护性。

具体化：不符合给定描述，不是封装的直接产物。

3、在团队协助中，（ D ）行为是合理的。
A、斤斤计较
B、向组长反映对某个组员的不满
C、找到高薪就跳槽
D、能力很强，大包大揽

4、如果客户要求交付产品的时间非常迫切、团队中有几个项目同时在开发，我们最好采用（ A ）来开发这个项目。
A、增量模型
B、螺旋模型
C、瀑布模型
D、原型模型

增量模型是一种软件开发方法，它将项目划分为多个小的增量部分，每个增量都是一个可交付的、完整的功能子集。在每个增量中，团队可以按照优先级完成必要的功能和特性。这种方法可以让团队快速交付部分功能，并在后续增量中逐步完善和改进。对于紧迫的项目交付需求和并行开发的情况，增量模型可以帮助团队以迅速且可控的方式进行开发，并及时满足客户的要求。

5、用于衡量软件开发组织的过程能力和成熟度水平的模型是（ A ）。
A、CMMI
B、RAD
C、CPM
D、UP

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）:
CMMI是一种广泛使用的评估模型，旨在评估和改进组织的软件工程过程。它提供了一套指南和最佳实践，帮助组织评估其软件开发和管理过程的成熟度，并提供改进路径。CMMI定义了不同成熟度级别，从初始级到优化级，组织可以根据其过程能力和成熟度水平进行评估和改进。
RAD（Rapid Application Development，快速应用程序开发）
CPM（Critical Path Method，关键路径法）
UP（Unified Process，统一过程）不是用于评估组织过程能力和成熟度的模型。

6、对于一个项目的工作量，给出的乐观、可能和悲观估计分别是10、25、60人月。基于三点估算，这个项目的工作量为（ C ）人月。
A、25
B、31.7
C、28.3
D、30

基于三点估算，可以使用PERT（Program Evaluation and Review Technique）来计算项目的工作量。PERT计算公式如下：

工作量 = (乐观估计 + 4 * 可能估计 + 悲观估计) / 6

在这个例子中，乐观估计为10人月，可能估计为25人月，悲观估计为60人月。

工作量 = (10 + 4 * 25 + 60) / 6
 工作量 ≈ 28.3人月

因此，这个项目的工作量约为28.3人月。

7、用于找到关键路径的方法是（ C ）。
A、UP
B、UML
C、CPM
D、DFD

用于找到关键路径的方法是：CPM（Critical Path Method，关键路径法）

CPM是一种项目管理技术，用于确定项目中的关键路径和关键活动。关键路径是指在项目网络图中，连接起始节点和结束节点，且具有最长时间的路径。关键路径上的活动对于项目的完成时间具有重要影响，延误任何一个关键路径上的活动都会延误整个项目的完成时间。CPM通过计算活动的最早开始时间、最晚开始时间、最早完成时间和最晚完成时间等参数，确定关键路径和项目的总工期。

UP（Unified Process，统一过程）是一种软件开发过程框架；UML（Unified Modeling Language，统一建模语言）是一种图形化建模语言；DFD（Data Flow Diagram，数据流程图）是一种描述系统功能和数据流的图形化表示方法；它们与关键路径的计算无直接关系。

8、你现在正在测试一个学籍管理系统。假设你已经完成“学生选课“功能的测试，正在对“课程设置”功能进行测试。现在你发现“课程设置"功能中有一个错误，并进行了改动。按照软件工程测试的要求，此时你应该做（ B ）。
A、冒烟测试
B、回归测试
C、集成测试
D、确认测试

回归测试是在对软件进行更改或修复后重新运行现有的测试用例，以确保已修复的错误没有引入新的错误或没有破坏现有的功能。在这种情况下，你已经发现并更改了“课程设置”功能中的错误，现在需要对整个系统进行回归测试，以确保修复过程中没有引入其他问题，并且之前通过的测试用例仍然能够通过。

冒烟测试主要用于在对软件进行全面测试之前，快速验证系统的基本功能和稳定性。集成测试是用于测试多个组件或模块在一起协同工作的测试。确认测试是由最终用户或客户进行的测试，旨在确认软件是否符合其需求和期望。在这种情况下，回归测试是最适合的选择。

9、假设你在开发团队有3个人，每个人的生产率是3000 LOC/月，每条通信路径上的生产率开销为300 LOC/月，但是现在表明你们已经落后于进度。如果加入2个人，每个人的生产率至少是（ B ）才能使得小组能够赶上进度。
A、1350
B、1050
C、2700
D、2100

首先，需要计算目前的总生产率，即每月能完成多少LOC的代码。根据题目，一共有3个人，每个人的生产率是3000 LOC/月，但是每条通信路径上的生产率开销为300 LOC/月。通信路径是指团队成员之间的沟通和协作，如果团队有n个人，那么通信路径的数量是n * (n - 1) / 2。所以，目前的总生产率是：

(3 * 3000) - (3 * (3 - 1) / 2 * 300) = 8100 LOC/月
 然后，需要计算还需要完成多少LOC的代码，才能赶上进度。假设已经完成了M LOC的代码，还剩下N LOC的代码没有完成，那么需要的时间是：

N / 8100 个月
 接下来，需要计算如果加入2个人，这两人的生产率为X LOC/月，那么总生产率会变成多少。根据题目，如果加入2个人，那么团队有5个人，通信路径的数量是5 * (5 - 1) / 2 = 10。所以，总生产率变为：

(3 * 3000 + 2 * X) - (10 * 300) = 2X + 6000 LOC/月
 最后，需要计算这两人的生产率至少是多少，才能使得小组能够赶上进度。为了赶上进度，需要在相同的时间内完成N LOC的代码，所以有以下等式：

N / (2X + 6000) = N / 8100
 解得：

X = 1050 LOC/月
 所以，如果加入2个人，每个人的生产率至少是1050 LOC/月才能使得小组能够赶上进度。

因此，这道选择题的正确答案是B。

10、团队正在开发一个智慧停车场系统，结合团队实际情况，其中一个风险为：原定复用的构件必需要自行开发，且该风险发生的概率为60%。假设该项目需要复用40个构件，每个构件预估的代码行为200 LOC，每代码行成本为15 元/LOC。则针对此风险的RE是（ D ）。
A、1800
B、120000
C、48000
D、72000

针对风险的RE（Risk Exposure）是根据风险概率和风险影响来计算的。在这种情况下，风险是原定复用的构件必需要自行开发，且该风险发生的概率为60%。

首先，计算风险发生的影响：
 影响 = 复用构件数量 * 每个构件的代码行数 * 每代码行的成本
 影响 = 40 * 200 LOC * 15 元/LOC = 120,000 元

然后，计算风险的RE：
RE = 风险概率 * 影响
RE = 0.6 * 120,000 元 = 72,000 元

因此，针对该风险的RE为72,000 元。

PPT

75、以下情况应该选用什么过程模型？

（1）客户不太清楚待开发的系统需要提供什么服务。

需求不明确
原型模型
（2）开发团队了解待开发软件的相关领域知识，尽管此系统庞大，但其较已经开发的系统差异并不大。

需求明确
瀑布模型
（3）软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。

需求很明确
瀑布模型
（4）开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。

新版本 + 严格期限
增量模型
（5）汽车防锁死刹车控制系统

考虑技术风险 + 循环的方式逐步加深系统定义和实现深度
螺旋模型
（6）大学记账系统，准备替换一个已存在的系统

需求很明确
瀑布模型
（7）一个位于火车站的交互式火车车次查询系统

“交互式”体现的是沟通上的迭代，需求不明确
原型模型
76、
（1）黑盒测试是从（）观点出发的测试，白盒测试是从（）观点出发的测试

A、开发人员，管理人员
 B、用户，管理人员
 C、用户，开发人员
 D、开发人员，用户

答案：C

（2）使用白盒测试时，确定测试用例应根据（）和指定的覆盖标准

A、程序的内部逻辑
 B、程序的复杂结构
 C、使用说明书
 D、程序的功能

答案：A

（3）软件测试的目的是（）

A、证明软件的正确性
 B、找出软件中存在的所有错误
 C、证明软件中存在错误
 D、尽可能多地发现软件中的错误

答案：D

（4）从下列叙述中，选出依次分别与需求分析、设计、编码相对应的软件测试：

A、集成测试，确认测试，单元测试
 B、单元测试，集成测试，确认测试
 C、单元测试，确认测试，集成测试
 D、确认测试，集成测试，单元测试

答案：D

（5）一般来说，与测试数据无关的文档是（）

A、需求规格说明书
 B、设计说明书
 C、源程序
 D.、项目开发计划

答案：D

77、
​ 设一个人单独开发软件，生产率是5000行／人年；如果多人开发软件，在每条通信路径上耗费的工作量是 250 行／人年。

​ 若 4 人组成一个小组共同开发这个软件，则需要6条通信路径，则小组中每个人的软件生产率降低为：

5000 - 6 × 250／4 = 4625 行／人年
​ 若 10 人组成一个小组共同开发这个软件，则需要45条通信路径，则小组中每个人的软件生产率降低为：

5000 - 45 × 250／10 = 3875 行／人年
78、
1、软件计划是软件开发的早期和重要阶段，此阶段要求交互和配合的是（ B ）
A、设计人员和用户
B、分析人员和用户
C、分析人员和设计人员
D、编码人员和用户

2、在软件工程项目中，不随参与人数的增加而使生产率成比例增加的主要原因是（ D ）
A、工作阶段的等待时间
B、产生原型的复杂性
C、参与人员所需电脑数
D、参与人员之间的通信困难

3、编写程序的工作量通常占用软件开发总工作量的（ D ）
A、80%
B、60%
C、40%
D、20%

4、描述软件项目进度安排的甘特图能够表示（ D ）
A、多个任务之间的复杂关系
B、任务之间的相互依赖制约关系
C、哪些任务是关键任务
D、子任务之间的并行和串行关系

5、可行性研究要进行的需求分析和设计应是（ C ）
A、详细的
B、全面的
C、简化、压缩的
D、彻底的

名词解释

1、RMMM

RMMM（Risk Mitigation, Monitoring, and Management）是风险缓解、监控和管理计划的缩写，是一种常见的软件项目管理技术。它包括以下几个方面：

风险缓解：指采取措施避免或减少风险发生的可能性或影响，例如消除风险的根源，制定应急预案，提高团队能力等。
风险监控：指对已识别的风险进行跟踪和评估，以确定风险是否发生或变化，以及风险缓解措施是否有效，例如收集风险数据，更新风险状态，调整风险策略等。
风险管理：指当风险缓解失败而导致风险成为现实时，采取应对措施控制风险的损失或影响，例如启动应急预案，分配资源，沟通协调等。
 RMMM计划通常作为软件项目计划的一部分，在项目开始前制定，并在项目过程中持续执行和更新。RMMM计划有助于提高软件项目的质量和成功率。

2、统一过程

统一过程（UP, unified process）是一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架，由UML方法和工具支持。它融合了瀑布模型、增量过程模型、演化过程模型、基于构件的开发等多种软件工程方法。它将软件开发生命周期分为四个顺序的阶段：初始阶段、细化阶段、构造阶段和交付阶段，每个阶段包含若干次迭代，每次迭代都以一个可执行的软件版本结束。它还定义了九个核心工作流，分别是业务建模、需求、分析与设计、实现、测试、部署、项目管理、配置与变更管理和环境工作流。

3、依赖倒置原则

依赖倒置原则（Dependency Inversion Principle, DIP）是指设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。这样可以降低类之间的耦合度，提高代码的可扩展性和可维护性。

4、开闭原则

开闭原则（Open-Closed Principle, OCP）是面向对象设计中的一条基本原则，指的是“软件实体（类、模块、函数等）应该对扩展开放，对修改关闭”。这意味着一个软件实体应该在不修改其源代码的情况下，可以通过扩展来增加新的功能或改变原有的行为。开闭原则的目的是提高软件的可维护性和可复用性，降低软件的耦合度和变更成本。开闭原则的实现方法主要依赖于抽象化和多态。通过使用抽象类或接口，将软件实体的公共行为抽象出来，而将不同的行为封装在子类或实现类中。通过使用多态，可以动态地替换不同的子类或实现类，从而改变软件实体的行为。

5、接口分离原则

接口分离原则（Interface Segregation Principle, 简称ISP）是指客户不应该依赖它们用不到的方法，只给每个客户它所需要的接口。接口隔离原则指在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好。 这样可以减少接口之间的耦合，提高接口的内聚性，降低接口的复杂度，提高系统的可维护性和可扩展性。接口隔离原则的实现方法主要依赖于抽象化和多态。通过使用抽象类或接口，将软件实体的公共行为抽象出来，而将不同的行为封装在子类或实现类中。通过使用多态，可以动态地替换不同的子类或实现类，从而改变软件实体的行为。

6、Liskov替换原则

Liskov替换原则（The Liskov Substitution Principle, 简称LSP）是由Barbara Liskov女士于1988年提出的，其定义为：“如果对于类型S的每个对象O1存在类型T的对象O2，那么对于所有定义了T的程序P来说，当用O1替换 O2并且S是T的子类型时，P的行为不会改变”。Liskov替换原则是对子类型的特别定义，也是多态性的一种表现。它要求子类型必须能够替换掉它们的基类型，并且保持程序的正确性和一致性。Liskov替换原则的目的是提高软件的可重用性和可扩展性，降低软件的耦合度和复杂度。Liskov替换原则的实现方法主要依赖于继承和多态。通过使用继承，可以使子类继承父类的公共属性和方法，而通过使用多态，可以使子类覆盖或重写父类的方法，从而改变或扩展父类的行为。

7、重构

重构（refactoring）是指在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构的目的是提高代码的可理解性，降低代码的修改成本，提升代码的质量。重构的方法有很多，例如提炼函数，提炼变量，提炼类，合并函数，合并变量，合并类，移动函数，移动变量，移动类，重命名函数，重命名变量，重命名类等等。重构的过程应该遵循一些原则，例如小步骤修改，频繁测试，保持可运行状态等等。

8、CRC(Class Responsibility Collaborator)

类—职责—协作者是一种面向对象的分析和设计方法，它通过使用一组表示类的索引卡片来描述系统的结构和行为。每张卡片分成三部分，它们分别描述类名、类的职责和类的协作者。

类名是一个突出的名词或名词词组，代表了一组相似的对象，例如 学生、教授 或 研讨会 。
类的职责是类知道或做的任何事情，包括属性、方法、事件等，例如 学生有姓名、参加研讨会、请求查看成绩单 等。
类的协作者是与该类有交互或依赖关系的其他类，它们可以提供信息或服务来帮助该类完成职责，例如 学生与研讨会、教授、成绩报告单 等有协作关系。
类—职责—协作者方法的优点是简单易用，能够快速地识别出系统中的主要类和它们之间的关系，促进团队合作和沟通。缺点是不够形式化，不能表示细节和约束，需要与其他建模工具如UML类图等结合使用。

9、α测试（Alpha Testing）

α测试（Alpha Testing）是一种软件测试方法，它是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。α测试的目的是评价软件产品的功能、可用性、可靠性、性能和支持，尤其注重产品的界面和特色。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。α测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

10、β测试（Beta Testing）

β测试（Beta Testing）是一种软件测试方法，它是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。β测试是在开发者无法控制的环境下进行的软件现场应用。β测试的目的是评价软件产品的功能、可用性、可靠性、性能和支持，着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试（Alpha Testing）达到一定的可靠程度时，才能开始β测试。

11、信息屏蔽（informetion hiding）

信息屏蔽（information hiding）是一种软件设计原则，旨在将系统的内部实现细节和数据隐藏起来，使其对外部组件和用户不可见。该原则强调将关键的信息封装在模块内部，只暴露必要的接口供其他组件使用，从而提高系统的可维护性和可扩展性。

12、功能独立

功能独立是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其它模块的接口是简单的。功能独立的模块应该是高内聚低耦合的，即模块内部各个元素彼此结合的紧密程度高，而模块之间的互相连接的紧密程度低。这样可以提高模块的可维护性、可测试性、可重用性和可扩展性。

13、模块化

模块化是一种软件设计方法，它把软件系统划分为若干个相对独立的功能单元，即模块。每个模块只负责一项具体的子功能，而且模块之间通过简单的接口进行通信。模块化的目的是降低软件的复杂性，提高软件的可维护性、可测试性、可重用性和可扩展性。

14、软件生命（生存）周期（software life cycle）

软件生命（生存）周期（software life cycle）是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。通常把软件生命（生存）周期分为若干个阶段，如需求、设计、实现(编码)、测试和维护等。每个阶段都有明确的任务、输入、输出和质量标准。软件生命（生存）周期的目的是降低软件开发的复杂性，提高软件的质量和可控性，以满足用户的需求和期望。

本文标签： 软件工程题目

版权声明：本文标题：软件工程题目 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dianzi/1728335130a1154706.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。