D

[解析] 效率是指与在规定的条件下，软件的性能水平与所使用资源量之间关系有关的一组属性。
   易用性是指与一组规定或潜在的用户为使用软件所需做的努力和对这样的使用所做的评价有关的一组属性。
   稳定性是指与修改所造成的未预料结果的风险有关的软件属性。
   可靠性是指与在规定的一段时间和条件下软件维持其性能水平的能力有关的一组属性。

B

[解析] 《计算机软件质量保证计划规范》(GB/T 12504—1990)第3.3条“文档质量的度量准则”条文规定，评审文档质量的度量准则是有以下6条：①完备性。所有承担软件开发任务的单位，都必须按照GB 8567的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。②正确性。在软件开发各个阶段所编写的文档的内容，必须真实地反映阶段的工作，且与该阶段的需求相一致。③简明性。在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简炼，适合各种文档的特定读者。④可追踪性。在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性；文档的可追踪性包括纵向可追踪性和横向可追踪性两个方面，前者是指在不同的文档的相关内容之间相互检索的难易程序；后者是指确定同一文档某一内容在本文档中的范围的难易程度。⑤自说明性。在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。⑥规范性。在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义及图示符号等符合有关规范的规定。

B

[解析] 软件需求可以分为功能需求、非功能需求和设计约束三种类型。性能需求属于非功能需求，例如处理速度、存储容量、信号速度、吞吐量和可靠性等方面的需求。

C

[解析] “4+1”视图模型从逻辑视图(设计视图)、开发视图(实现视图)、进程视图、物理视图(实施视图)、场景视图(用例视图)5个不同的视角来描述软件体系结构。

B

[解析] “软件产品交付后进行的修改”是这四类软件维护定义中的共同特征。

A

[解析] 出自《计算机软件质量保证计划规范GB/T12504—1990》“4.5评审与检查”第4.5.7条原条文。

C

[解析] 运行测试是指在软件生存周期中的测试阶段及任何运行阶段，测试软件产品以评价某软件产品的质量的测试活动。而系统测试是针对整个产品系统进行的测试，其目的是验证最终软件系统是否满足用户规定的需求，以评价该软件产品的质量。

C

[解析] 出自《计算机软件质量保证计划规范GB/T12504—1990》“4.3文档”第4.3.1.5条原条文。
   软件需求规格说明书必须清楚、准确地描述软件的每一个基本需求(功能、性能、设计约束和属性)和外部界面。必须把每一个需求规定成能够通过预先定义的方法(例如检查、分析、演示或测试等)被客观地验证与确认的形式。
   软件设计说明书应该包括软件概要设计说明和软件详细设计说明两部分。其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每一个子部件进行描述。其详细设计部分必须给出每一个基本部件的功能、算法和过程描述。
   软件验证与确认计划必须描述所采用的软件验证和确认方法(例如评审、检查、分析、演示或测试等)，以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现，软件设计说明书表达的设计是否已由编码实现。它还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相一致。

A

[解析] 测试是指软件开发公司组织内部人员模拟各类用户行为，对即将面市软件产品(称为α版本)进行测试，试图发现错误并修正。经过α测试调整的软件产品称为β版本。
   β测试是由软件的最终用户在一个或多个用户场所进行测试活动。它是一种验收测试。与α测试不同，开发者通常不在β测试的现场，因为β测试是软件在开发者不能控制的环境中的“真实”应用。
   在软件中，“冒烟测试”是指在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了程序代码之后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。
   静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

A

[解析] 软件结构是指软件系统的模块层次结构，反映了整个系统的功能实现，即将来程序的控制体系。软件结构设计优化准则包括(但不限于)：①划分模块时，尽量做到高内聚、低耦合，保持模块相对独立性，以此为原则优化初始的软件结构；②一个模块的作用范围应在其控制范围之内，且判定所在的模块应与受其影响的模块在层次上尽量靠近；③软件的深度、宽度、扇入、扇出应适当；④模块的大小要适中；⑤模块的控制范围模块的接口要简单、清晰、含义明确，便于理解，易于实现、测试与维护。
   若系统的主要功能仅由一个模块来实现，则这种做法是很不利于今后软件维护的。

B

[解析] 依题意，由于甲开发数据库程序的缺陷率低于开发操作系统程序的缺陷率，而乙则反之，因此应该维持前任项目经理的任务分工安排，由甲开发该软件的数据库程序，乙开发该软件的操作系统程序。同时，由于丙开发操作系统程序和数据库程序的缺陷率都比较高，因此建议由乙培训丙。

C

[解析] 在CMMI已管理级中，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。在这种情况下，组织已经营造了一个稳定的、受控的开发环境，项目已经在受控制的状态下运行。该等级包括以下7个过程域：需求管理(RM)、项目策划(PP)、项目监督与控制(PMC)、供方协定管理(SAM)、测量与分析(MA)、过程和产品质量保证(PPOA)和配置管理(CM)。其中，“过程和产品质量保证”的目的在于使工作人员和管理者客观地了解过程和相关的工作产品。“测量和分析”的目的在于开发和维持度量能力以便支持对管理信息的需要。
   “供方协定管理”旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
   “项目策划”的目的在于建立并维护规定项目各项活动的计划。

B

[解析] 根据《软件工程术语GB/T 11457-2006》，验收测试(acceptance testing)是指确定一系统是否符合其验收准则，使客户能确定是否接收此系统的正式测试。
   合格性测试是指确定系统或部件是否适合于操作使用的测试行为。
   运行测试是指在它的目标环境中，评价系统或部件的测试行为。
   系统测试是指在完整的、集成的系统上的测试行为，它用以评价系统与规定的需求的遵从性。

D

[解析] 根据《软件工程术语GB/T 11457-20069，鉴定(qualification)是一个正式的过程，通过这个过程决定产品是否符合它的规格说明，是否可在目标环境中使用。

D

[解析] 根据《软件工程产品质量第1部分：质量模型(GB/T16260.1-2006)》，有效性(或可用性)是在规定的使用条件下，软件产品处在给定的时间点完成所需功能的状态的能力。有效性可以根据软件产品在全部时间中处于正常工作状态的百分比进行外部评估。依题意，该软件系统每天计划运行时间为早8点至晚6点，即10小时。在10天运行时间中，其有效性=(10×10-1-4-1)/(10×10)=94%。

B

[解析] 根据《软件可靠性和可维护性管理GB/T 14394-2008》，在软件开发各阶段都要求进行评审，评审管理要求按GB/T 8556-2007进行，其中与软件可靠性和可维护性有关的具体评审要求有：概念评审、需求评审、设计评审、测试评审、安装和验收评审、软件用户手册评审。

A

[解析] 《软件可靠性和可维护性管理GB/T 14394-2008》将软件生存周期中“开发”过程细分为概念、需求、设计、实现、测试、安装和检验6个活动过程。其中，在概念活动中的可靠性和可维护性要求是：进行软件可行性分析，制定初步软件开发计划，提出软件可靠性和可维护性分解目标、要求及经费。

A

[解析] 题干描述的是软件审计的目的。

C

[解析] 应用软件是指设计用于实现用户的特定需要而非计算机本身问题的软件。例如，导航(浏览)、工资、过程控制软件。支持软件是指辅助其他软件开发或维护的软件。例如，编译程序、装入程序和其他实用程序。系统软件是指包含系统常驻软件的软件库。可供访问和使用，或通过引用而合并到其他程序中去，例如，宏库。

A

[解析] 使用质量是基于用户观点的软件产品用于指定的环境和使用周境时的质量。它测量用户在特定环境中能达到其目标的程度，而不是测量软件自身的属性。

D

[解析] 这是一道求解系统可靠性方面的试题。依题意，每个元件的失效率λ=0.001次/小时，该系统的平均失效间隔时间

D

[解析] 用例用来描述系统在对事件做出响应时所采取的行动，即它确定了一个与系统参与者进行交互、并由系统执行的动作序列。选项D所描述的范围太广，不够准确。在UML规范中，参与者是指系统所涉及的人，或者是用户在本系统中扮演的角色。一个参与者总是在系统的自动化边界之外。

B

[解析] 统一建模语言(UML)是一个通用的可视化建模语言。XML(可扩展的置标语言)是Web Service平台中表示数据的基本格式。VC++和Java都是面向对象的程序设计语言。

B

[解析] RUP(统一开发过程)属于“过程方法”，是一种软件项目实施过程的方法论。其目标是在可预见的工期内、在确定的预算内提交能够满足最终用户需求的高质量产品。EGP、RIP和BGP分别是TCP/IP协议族中的路由协议。

C

[解析] 使用UML表示软件体系架构，用到的5个视图分别是用例视图、逻辑视图、进程视图、构件视图和部署视图。其中，用例视图描述系统应交付的功能，即从外部参与者的角度出发所观察到的系统功能，是其他视图的核心和基础；逻辑视图用于描述所设计的静态/动态对象模型，以支持系统的功能需求；进程视图用于描述所设计的并发与同步结构，以支持系统的运行特性；构件视图用于描述软件在开发环境中的静态结构，以支持软件开发的内部需求；部署视图表示软件到硬件的映射及分布结构，以支持系统的拓扑、安装和通信需求。

B

[解析] 模式是一条由3部分组成的规则，它表示了一个特定环境、一个问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题的解决方案，从而减少不必要的重复劳动。设计模式使得系统开发者可以更加简单和方便地去复用成功的软件设计和体系结构，从而帮助设计者更快更好地完成系统设计。

C

[解析] 用例建模是指使用用例的方法来描述系统的功能需求的过程，包括用例图和用例规约。

B

[解析] 类图、对象图和部署图都属于结构类模型图，用于描述系统应用的静态结构。而序列图属于行为类模型图，用于描述系统动态行为的各个方面，能够表达用户与系统的复杂交互过程。

B

[解析] RUP细化阶段的具体任务有(但不限于)：①确保软件结构、需求及计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度；②针对项目的软件结构上的主要风险已经解决或处理完成；③通过完成软件结构上的主要场景建立软件体系结构的基线；④建立一个包含高质量组件的可演化的产品原型；⑤说明基线化的软件体系结构可以保障系统需求，可以控制在合理的成本和时间范围内；⑥建立好产品的支持环境。