软件工程17-18期末试卷

2.敏捷开发提倡一个迭代80%以上的时间都在编程，几乎没有设计阶段。敏捷方法可以说是一种无计划性和纪律性的方法。错

敏捷开发是一种软件开发方法论，它强调快速响应变化、持续交付有价值的软件、紧密合作和适应性。虽然敏捷方法鼓励迭代开发和灵活性，但它并不是一种无计划性和纪律性的方法。相反，敏捷开发是有计划、有纪律的，但它强调的是不断适应和改进计划，而不是严格遵循固定的计划。

以下是一些关于敏捷开发的核心原则和实践，以解释为什么它并不等同于无计划性和纪律性：

1. 迭代和增量开发： 敏捷开发将项目划分为小的迭代周期，每个迭代都有明确的目标和可交付的功能。这些迭代是有计划的，团队在每个迭代开始前制定计划，然后在迭代结束时回顾和改进。

2. 重视需求变更： 敏捷开发接受需求的变化，并鼓励与客户或利益相关者的密切合作，以便在项目的不同阶段进行调整。这并不意味着没有计划，而是计划要灵活适应变化。

3. 持续集成和交付： 敏捷开发强调频繁地集成和交付代码。这需要有纪律，以确保代码的质量和可维护性。

4. 自组织团队： 敏捷开发鼓励自组织的团队，但这并不是无纪律的意味。团队成员需要在计划、协作和交付方面具有纪律性。

5. 透明度和度量： 敏捷开发注重透明度，通过各种指标和度量来评估项目的进展和质量。这需要纪律和计划来收集和分析数据。

总之，敏捷开发并不是一种无计划性和纪律性的方法。它强调适应性、快速响应变化和紧密合作，但这并不排斥计划、纪律和质量控制。敏捷方法强调灵活性，以更好地满足客户需求，但同时也有其自身的原则和实践，以确保项目的成功和质量。

3.软件模块化可以降低解决问题的复杂度，从而降低软件开发的工作量，所以实际开发中应将软件模块分得越多越好。错

软件模块化是一种良好的软件设计和开发原则，可以带来许多好处，包括降低问题的复杂度、提高代码可维护性和重用性。然而，将软件模块划分得过多并不总是一个明智的选择，因为它可能引入新的问题和复杂性。在实际开发中，模块化应该根据具体项目和需求来平衡。

以下是一些关于软件模块化的考虑：

1. 代码复用： 模块化允许代码的重复使用，这可以显著降低工作量，因为你可以在不同项目或不同部分中重复使用相同的模块。然而，如果划分得过多，可能导致模块之间的重复或过度复杂的依赖关系。

2. 维护性： 模块化使得软件更易维护，因为每个模块都有明确定义的功能和接口。然而，维护许多小模块可能会增加维护的复杂性，因此需要谨慎选择模块数量。

3. 可理解性： 较小的模块通常更容易理解，但过多的小模块可能会使整个系统的理解变得困难。在某些情况下，较大的、更集中的模块可能更易于理解。

4. 性能： 模块化可以提高性能，因为你可以并行开发和测试各个模块。然而，模块之间的通信和数据传输可能会引入一些开销，需要谨慎优化。

5. 复杂性管理： 模块化可以帮助降低问题的复杂度，但划分得过多可能会引入额外的复杂性。你需要在模块划分和系统整合之间取得平衡。

综上所述，软件模块化是一个重要的原则，但在实际开发中，模块数量和划分方式应根据具体项目需求和复杂性来决定。要确保软件具有良好的结构和可维护性，需要考虑模块之间的适当关联，以避免引入不必要的复杂性。模块的设计应该在团队的讨论和评估中进行，以找到适合特定项目的最佳模块化策略。

4.结构化程序设计遵循的是自顶而下，逐步求精的设计方法。对
5.界面设计除了设计人（例如，用户）和计算机间的界面，即人机界面设计（例如：用户界面-User Interface）外，还包括设计软件构件间的接口、设计模块和其他非人的信息生产者和消费者（例如，其他外部实体）的接口。对
6.桩模块相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果。而驱动模块用于代替所测模块调用的子模块。错

这个描述存在一些混淆。通常，"桩"和"驱动"是与软件测试和集成测试相关的术语，用于模拟或代替所测模块的其他模块，以便进行测试。描述中的一些概念存在一些混淆。

驱动模块：

驱动模块是用来模拟被测模块的上一级模块，相当于被测模块的主程序。它接收数据并将相关数据传送给被测模块，启用被测模块并打印出相应结果。驱动模块的目的很单纯，就是访问类库的属性和方法来确定类库是否正确。

桩模块：

桩模块是模拟被测试模块所调用的模块，而不是软件产品的组成部分。主程序作为驱动模块，与之直接相连的模块是桩模块，也称为"替身模块"。桩模块本身不执行任何功能，只在它作为替身被调用时返回静态值。

所以，描述中的概念存在一些混淆。桩模块通常用于代替所测模块的依赖，而驱动模块用于调用被测模块，提供输入并记录输出。这两者都是集成测试的重要工具，以确保软件的各个部分能够正常协同工作。

7.确认测试是基于实际应用环境对计算机系统的一种多方位的测试，每一种测试都具有不同的目的，但所有的测试都是为了检验各个系统成分是否正确集成到一起并且是否能完成预定的功能。

错

是系统测试

描述中的内容更符合系统测试（System Testing）的定义，而不是确认测试（Validation Testing）。系统测试是一种多方位的测试，它确保整个计算机系统的各个组件正确集成到一起，并能够完成预定的功能。系统测试通常是在实际应用环境下进行的，旨在验证整个系统是否满足用户需求和规格。

确认测试（Validation Testing）通常是在软件开发的早期阶段进行的，目的是验证软件是否满足用户需求和规格。它通常关注的是单个功能或模块的验证，而不涉及整个系统。确认测试的目的是确保开发的软件在满足特定要求方面是正确的。

所以，描述中提到的是系统测试的特征，而不是确认测试。确认测试通常是更早的测试阶段，而系统测试则是在整个系统集成后进行的测试。

8."初始化"是指对软件的功能、性能、接口等作适当的改变以适应客户的实际需求（客户化），"初始化"正式安装之前完成的。"客户化"是指在使用软件前所做的一些基础资料的输入工作，如各种信息编码的形成和输入初始化在正式安装之后完成（初始化）。错

描述中存在一些混淆和不准确的术语使用。

1. 初始化（Initialization）： 初始化通常指的是软件系统在首次安装或启动时执行的一系列操作，以准备软件运行。这包括设置默认配置、创建数据库、加载初始数据等。初始化是在正式安装之前或安装后的初始设置中执行的，旨在确保软件能够正常运行。

2. 客户化（Customization）： 客户化是指根据客户的实际需求对软件进行定制化的调整。这包括对功能、界面、性能和其他方面的适应性修改，以满足特定客户的需求。客户化通常是在软件安装后执行的，因为它需要根据特定客户的要求进行定制。

所以，描述中关于初始化和客户化的使用存在一些混淆。初始化通常在正式安装之前或之后执行，以确保软件的基本设置和准备工作完成。客户化是在使用软件后，根据客户的特定需求进行的个性化定制。两者是不同的概念和操作。

9.软件项目管理的主要任务包括软件项目计划与组织、软件项目成本管理、软件项目进度控制、软件质量保证、软件配置管理、生成软件项目管理文档等。

对
10.基线是经正式评审批准的阶段性软件工作产品，是软件生存期各开发阶段的一个特定点。对
11.安全程序（或安全软件）开发，尤其是大型安全程序的开发应把程序的安全控制分散到各个开发阶段中去。对
12.软件框架（软件架构）是一个系统的草图，软件架构描述的对象是直接构建系统的抽象组件。软件架构（软件框架）其实就是将代码放到一个我们看不到的容器中，当我们使用的时候直接调用。错

描述中的表述存在一些混淆和不准确。软件框架（Software Framework）和软件架构（Software Architecture）是两个不同的概念，描述中混淆了它们。

1. 软件架构（Software Architecture）： 软件架构是一个系统的高级结构，它定义了系统的组件、它们之间的相互关系以及系统的整体设计原则。软件架构是对系统的整体设计和结构的抽象描述，包括系统的层次结构、模块化、数据流、通信方式等。它用于指导软件开发，确保系统的组件能够协同工作以满足系统的需求。

2. 软件框架（Software Framework）： 软件框架是一个抽象的、可扩展的代码结构，它提供了一种通用的解决方案或框架，用于构建特定类型的应用程序。框架通常包括一组通用功能、类、库和工具，开发人员可以在其基础上构建特定应用程序的定制代码。框架的目的是提供一种开发的结构和约定，以加速应用程序的开发。

所以，软件框架是一种开发工具，用于加速应用程序的开发，而软件架构是系统的整体设计和结构描述。它们是软件开发中不同层次的概念。描述中的"将代码放到一个看不见的容器中"并不准确地描述了软件框架的概念。软件框架通常是可见的工具，供开发人员使用和扩展。

13.在MVC中，视图与控制器是一对多的关系，而模型与视图是一对一的关系。错

描述中有一些混淆。在经典的MVC（Model-View-Controller）架构中，视图、控制器和模型之间的关系如下：

1. 视图（View）与控制器（Controller）： 视图和控制器之间是一对多的关系。一个控制器可以关联多个视图，这意味着不同的视图可以使用同一个控制器来处理用户界面交互。控制器负责接收用户输入并将其传递给相应的视图或模型，以及响应来自视图的事件。

2. 模型（Model）与视图（View）： 模型和视图之间通常是一对多的关系。一个模型可以与多个视图相关联，这允许多个视图同时显示模型的数据。当模型发生变化时，所有相关视图都会更新以反映这些变化。

所以，描述中的"视图与控制器是一对多的关系，而模型与视图是一对一的关系"是不准确的。在MVC中，视图与控制器是一对多的关系，而模型与视图通常是一对多的关系，允许多个视图同时显示同一个模型的数据。这种关系结构有助于分离用户界面、应用逻辑和数据模型，提高代码的可维护性和扩展性。

14.顺序图和协作图都属于交互图，用来描述对象之间的动态关系。协作图强调消息的时间顺序，顺序图强调参与交互的对象的组织关系。错

描述中的表述不准确。顺序图和协作图确实都属于UML（统一建模语言）中的交互图，但它们的主要关注点和用途略有不同。

1. 协作图（Collaboration Diagram）： 协作图强调对象之间的合作关系和协同工作方式。它展示了多个对象之间的交互，包括对象之间的消息传递、协同工作和合作。协作图通常更注重对象之间的关系和互动，而不太强调消息的时间顺序。它更关注对象的合作和组织结构。

2. 顺序图（Sequence Diagram）： 顺序图强调对象之间的消息传递的时间顺序。它描述了对象之间的交互，包括消息的发送和接收顺序，以及消息的时序。顺序图通常用于表示对象之间的消息流程，特别是强调时间顺序的消息传递。

因此，协作图更关注对象之间的合作和组织，而顺序图更关注消息传递的时间顺序。它们都用于描述对象之间的动态关系，但强调不同的方面，根据需要选择合适的图形工具。

15.设计模式一般采用用例图，活动图，状态图等，而需求模型一般常用类图、交互图、活动图，状态图等。错

描述中存在一些混淆。设计模式和需求模型使用的UML（统一建模语言）图形工具可以有一些重叠，但它们有不同的目的和上下文。

1. 设计模式： 设计模式是在软件设计中用于解决常见设计问题的通用解决方案。它们通常不是特定于某个用例或需求的，而是可重用的设计范本。设计模式通常不涉及用例图、需求模型等，而是更关注类之间的关系、对象的创建方式、控制流程等。它们通常通过类图、序列图等来描述。

2. 需求模型： 需求模型用于捕捉系统需求和用户需求，通常包括用例图、类图、交互图（如顺序图和协作图）、活动图、状态图等。这些模型有助于理解系统的功能需求、结构和行为，以便在软件开发的早期阶段定义系统需求。

因此，设计模式通常不使用用例图、活动图和状态图，而是更关注类图和交互图等，而需求模型通常包括用例图、类图、交互图、活动图和状态图等，以捕捉需求和系统设计。

16.聚集表示类之间一种紧密的整体与部分的组成关系。组合表示类之间一种松散的整体与部分的组成关系。错

描述中存在一些混淆，实际上是相反的：

1. 聚集（Aggregation）： 聚集表示一种松散的整体与部分的组成关系。在聚集关系中，整体对象包含部分对象，但部分对象也可以存在独立于整体对象。聚集关系通常表示成菱形（空心或实心）。

2. 组合（Composition）： 组合表示一种紧密的整体与部分的组成关系。在组合关系中，整体对象包含部分对象，但部分对象通常没有独立存在的意义，它们依赖于整体对象。组合关系通常表示成实心菱形。

所以，描述中的陈述反了过来。聚集是一种松散的关系，而组合是一种紧密的关系。

17.web服务是一个向其他应用提供数据和服务的应用逻辑单元，也可以是软件构件。对
18.从本质上来说，SOA是一种架构模式，而web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。对
19.（软件）过程为实现预定目的而执行的一组实践；过程包含工具、方法、材料和人员。对
20.CMMI的"已定义级"的主要内容包括：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。错

描述中提到的CMMI（Capability Maturity Model Integration）中的"已定义级"（Defined Level）的内容是不准确的。

在CMMI中，"已定义级"实际上是指已经建立了基本的项目管理过程来跟踪费用、进度和功能特性，并且制定了必要的过程纪律，以便能够重复早先类似应用项目取得的成功经验。所以描述中的表述是正确的，不是错误的。

"已定义级"是CMMI的第三级，通常被称为"定义级别"，在这个级别上，组织建立了一套已定义的软件工程过程，以便在项目中实施。这有助于确保项目的重复性和可管理性，并减少项目风险。这一级别是在过程成熟度模型中的一个重要里程碑，组织需要在此级别上建立稳健的过程基础，以支持项目的成功交付。

二、简答题
1.说明单元测试和集成测试的再测内容和测试方法上的区别。

单元测试与集成测试的区别在于： (1)测试方法不同。单元测试主要属于白盒测试，集成测试结合使用白盒与黑盒测试方法，较多采用黑盒方法构造测试用例 (2)考察范围不同。单元测试主要测试模块内部接口、数据结构、逻辑、异常处理等对象，消除局部模块的逻辑和功能上的错误和缺陷；集成测试主要测试模块之间的接口和异常，

2.为什么说CMMI不是一套可以直接拿来用的过程。

毫无疑问，对于软件企业而言，CMMI是一套提供了包含产品和服务开发以及最佳实践的模型，通过合理运用CMMI提供的指引可帮助企业更好地实施过程改进。但是，CMMI并不等于一套可以直接生搬硬套的标准。对于CMMI-DEV模型的22个过程域，每个过程域都有明确的实践目标和一些最佳实践，具体到一个特定企业，需要根据该企业的商业目标和自身情况，来确定采取哪些方法和行动来达成CMMI模型提出的实践要求。

3.简述SOAP的作用。说明为什么该协议可以穿透防火墙。

作用：应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信的方式会产生兼容性以及安全问题；防火墙和代理服务器通常会阻止此类流量。通过 HTTP 在应用程序间通信是更好的方法，因为HTTP 得到了所有的因特网浏览器及服务器的支持。SOAP 提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信。因为SOAP使用HTTP协议（80端口），而服务器的这个协议一般都是开放的，而且可以穿过防火墙的。

4.简述应用软件安全的重要性。说明如何利用信息安全等级保护来保证应用软件的安全性。

应用程序安全是指使用软件、硬件和程序方法来防止应用程序受外部威胁。应用程序内置的安全措施和良好的应用安全程序能尽量避免黑客操纵、访问、窃取、修改或删除敏感数据。在软件设计之后，在开发过程中，安全性变得越来越重要，因为应用程序一旦在网络上可以广泛获得，就很容易受到各种威胁。

主要流程：

1.定级。根据信息和信息系统遭到破坏或泄露后，对国家安全、社会秩序、公共利益及公民、法人和其他组织的合法权益的危害程度来进行定级。

2.备案

3.系统建设、整改

4.等级测评，测评内容包括技术测评和管理测评，技术测评包括物理环境、网络测评、主机安全、应用安全、数据备份与恢复，管理测评包括安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理。

5.信息安全监管部门定期开展监督检查

6.简述软件架构对软件开发的作用。说明目前主流的软件架构的技术特点。

作用：

1.软件构架设计是系统设计的主要工作

2.软件构架是构造高质量系统逻辑模型的保障

3.软件构架是涉众之间信息交流的工具

4.软件构架是其他软件开发的参考