A

[解析] 模式是一种问题的解决思路，它已经适用于一个实践环境，并且可以适用于其他环境。设计模式通常是对于某一类软件设计问题的可重用的解决方案，将设计模式引入软件设计和开发过程，其目的就在于要重用成功的软件开发经验。

B

[解析] 常见的信息系统开发方法有结构化法、原型法、面向对象方法。其中原型法也称原型化法，原型法的基本思想与结构化方法不同，原型法认为在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求。系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工。
   C中的“面向对象的开发方法”既适合于需求明确的情况，也适合于需求不明确的场合，A太笼统，“瀑布式”是一种软件开发模型，而非开发方法。

C

[解析] 耦合度是指模块间关联的紧密程度，从强至弱依次分为7种：内容耦合、公共耦合、外部耦合、控制耦合、标记耦合、数据耦合、非直接耦合。

C

[解析] 通俗地说，概要设计是设计模块之间的关系，而详细设计是设计模块内部的细节。因此模块内部的算法设计属于详细设计的范畴。

B

[解析] 需求分析是软件系统生命周期中较早期的一个阶段，其目的主要是确定软件系统应该具备哪些功能，即明确“做什么”的问题。

B

[解析] 数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
   数据库设计具体分为三个阶段：
   (1)概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)。
   (2)逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
   (3)物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。

D

[解析] 黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
   黑盒测试通常可以细分为边界值测试、等价类划分、错误推测与因果图这四种小类。状态测试可以理解为等价类划分测试法的一个分支。

A

[解析] 软件测试应由独立于软件设计开发的人员进行，根据软件项目的规模等级和安全性关键等级，软件测试可由不同机构组织实施。
   (1)软件单元测试由承建单位自行组织，一般由软件开发组实施测试。
   (2)软件集成测试由承建单位自行组织，软件开发组和软件测试组联合实施测试。
   (3)软件确认测试由承建单位自行组织，软件测试组实施测试。
   (4)系统测试应由业主单位组织，成立联合测试组(一般由专家组、业主单位、软件评测单位、承建单位等联合组成测试组)实施测试。

C

[解析] 1999年，软件“产品评价”国际标准ISO 14598给出的“软件质量”的定义是：软件特性的总合，软件满足规定或潜在用户需求的能力。也就是说，质量就是遵从用户需求，达到用户满意。从而可判断“④选项”的描述错误。
   2001年，软件“产品质量”国际标准ISO 9126定义的软件质量包括“内部质量”、“外部质量”和“使用质量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。

B

[解析] 软件配置项不论大小都必须实施软件配置管理。每个计算机系统均应制定软件配置管理规程，至少应明确规定：
   (1)各级、各库中所管的软件实体的清单。
   (2)保证安全性、可靠性、保密性、正确性、完备性、一致性和可追踪性的具体措施。
   (3)入库控制办法和审批手续。
   (4)出库条件及其必备的手续。
   (5)变更控制办法和审批手续。

A

[解析] 任何软件配置管理项都必须做到“文实相符、文文一致”，以满足“有效性”、“可见性”和“可控性”要求。

B

[解析] 本题主要考查我们对各开发模型的理解。
   瀑布模型具有可强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审等优点。但瀑布模型过于理想化，而且缺乏灵活性，无法在开发过程中逐渐明确用户难以确切表达或一时难以想到的需求。
   原型模型一般是基于需求不容易明确这一事实：并非所有的需求在系统开发之前都能准确地说明和定义。因此，它不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法。快速原型法适用于需求不够明确的项目。
   V模型一种典型的测试模型，该模型强调开发过程中测试贯穿始终。
   螺旋模型综合了瀑布模型和演化模型的优点，并在此基础上还增加了风险分析。采用螺旋模型时，软件开发沿着螺旋线自内向外旋转，每转一圈都要对风险进行识别和分析，并采取相应的对策。
   本题描述的是一个大型项目，那么对文档的要求应该相应较高，而且具备了相关领域及类似规模系统的开发经验，那么系统的需求应该较明确，综合考虑，应该采用瀑布模型。

B

[解析] 软件复杂性主要表现在程序的复杂性。程序的复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少、开发周期长短和软件内部潜伏错误的多少。同时它也是软件可理解性的另一种度量。
   软件复杂性度量的参数很多，主要有：
   (1)规模，即总共的指令数，或源程序行数。
   (2)难度，通常由程序中出现的操作数的数目所决定的量来表示。
   (3)结构，通常用于程序结构有关的度量来表示。
   (4)智能度，即算法的难易程度。

C

[解析] 软件系统文档既包括有一定格式要求的规范文档，又包括系统建设过程中的各种来往文件、会议纪要、会计单据等资料形成的不规范文档，通过它可以提高软件开发的可见度，提高软件开发的效率以及便于用户理解软件的功能、性能等各项指标。

C

[解析] 软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品(主要是指程序)中的错误和缺陷。软件测试是软件质量保证的主要手段之一。
   一个好的测试用例是极有可能发现至今为止尚未发现的错误的测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。一个高效的测试是指用少量的测试用例，发现被测软件尽可能多的错误。软件测试不能说明软件中不存在错误。

B

[解析] 黑盒测试又称功能测试。它把软件看做一个不透明的黑盒子，完全不考虑(或不了解)软件的内部结构和处理算法，它只检查软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息(例如文件和数据库)的完整性等。
   常用的黑盒测试技术包括等价类划分、边界值分析、错误推测和因果图等。

A

[解析] 软件的可靠性是指一个系统在给定时间间隔内和给定条件下无失效运行的概率。
   软件的可用性是指软件在特定使用环境下为特定用户用于特定用途时所具有的有效性。
   软件的可维护性是指与软件维护的难易程度相关的一组软件属性。
   软件的可伸缩性是指是否可以通过运行更多的实例或者采用分布式处理来支持更多的用户。

C

[解析] 软件维护占整个软件生命周期的60%～80%，维护的类型主要有以下4种。
   (1)改正性维护：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。
   (2)适应性维护：在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
   (3)完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。
   (4)预防性维护：这是指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护可定义为“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。
   而本题所描述的为软件的运行增加监控设施属于完善性维护。

C

[解析] 面向对象分析的任务是了解问题域所涉及的对象、对象间的关系和操作，然后构造问题的对象模型。问题域是指一个包含现实世界事物与概念的领域，这些事物和概念与所设计的系统要解决的问题有关。因此面向对象分析的第一步是要确定问题域。

B

[解析] OOA是软件需求分析的一种方法，而需求分析所关心的是软件要做什么，不需要考虑技术和实现层面的细节问题。OOA的结果是分析模型及说明文档，同时OOA的结果是OOD的输入。

B

[解析] 数据流图主要由实体、数据存储、处理过程和数据流四部分组成。在顶层数据流图中，将系统描述成一个处理过程，而其他的是与该处理过程相关的输入输出流，因此顶层数据流图描述了系统的输入与输出。

B

[解析] 增量模型是一种非整体开发的模型，该模型具有较大的灵活性，适合于软件需求不明确的一种模型。使用该模型开发产品，一般是尽快构造出可运行的产品，然后在该产品的基础上再增加需要的新的构建，使产品更趋于完善。

A

[解析] 瀑布模型严格遵循软件生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段。瀑布模型的优点是：可强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审。但瀑布模型过于理想化，而且缺乏灵活性，无法在开发过程中逐渐明确用户难以确切表达或一时难以想到的需求。该模型比较适合于需求明确，对交付时间有严格要求的开发。
   原型模型基于这样一种客观事实：并非所有的需求在系统开发之前都能准确地说明和定义。因此，它不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法。它适用于需求不明确的开发环境。
   螺旋模型综合了瀑布模型和演化模型的优点，还增加了风险分析。螺旋模型包含了四个方面的活动：制订计划、风险分析、实施工程、客户评估。采用螺旋模型时，软件开发沿着螺旋线自内向外旋转，每转一圈都要对风险进行识别和分析，并采取相应的对策。螺旋模型比较适合大规模的开发，它对风险控制有很高的要求。
   综上所述，要满足题目描述的要求，应该采用瀑布模型开发最适宜。

A

[解析] 封装是面向对象技术的三大特点之一，封装的目的是使对象的定义和实现分离，这样，就能减少耦合。封装可以使得其他开发人员不需要知道一个软件组件内部是如何工作的，只需要使用该组件提供的接口来完成交互即可，如果在另外一个地方需要完成同样的功能，我们就可以将该组件使用在另外一个地方，这样提供了软件的复用性。

B

[解析] 数据流图是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。数据流图还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
   数据流图的作用主要有以下几个方面：
   (1)数据流图是理解和表达用户需求的工具，是系统分析的手段。由于数据流图简明易懂，理解它不需要任何计算机专业知识，便于通过它同客户交流。
   (2)数据流图概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具。因而是系统设计的重要参考资料，是系统设计的起点。
   (3)数据流图作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
   数据流图从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。

D

[解析] 软件需求规格说明书的编制是为了使用户和开发人员对软件要做什么有共同的理解，使之成为整个软件设计和软件验收工作的基础。
   需求分析在可行性研究之后，当然不能成为可行性研究的依据。

D

[解析] 软件的复杂性与源程序的代码行数、程序的结构、算法的难易程度有关，与程序中注释的多少无关。程序中注释的多少与程序的可阅读性和可理解性有关。

A

[解析] 盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

D

[解析] 静态分析中进行人工测试的主要方法有桌前检查(Desk Checking)、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。
   1．桌前检查
   由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误。检查项目有：
   (1)检查变量的交叉引用表：重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列；临时变量在某条路径上的重写情况；局部变量、全局变量与特权变量的使用；
   (2)检查标号的交叉引用表：验证所有标号的正确性：检查所有标号的命名是否正确；转向指定位置的标号是否正确。
   (3)检查子程序、宏、函数：验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏、函数是否存在；检验调用序列中调用方式与参数顺序、个数、类型上的一致性。
   (4)等值性检查：检查全部等价变量的类型的一致性，解释所包含的类型差异。
   (5)常量检查：确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性；
   (6)标准检查：用标准检查程序或手工检查程序中违反标准的问题。
   (7)风格检查：检查在程序设计风格方面发现的问题。
   (8)比较控制流：比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档和校正错误。
   (9)选择、激活路径：在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖。
   (10)对照程序的规格说明，详细阅读源代码：程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。
   (11)补充文档：桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。
   这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。
   2．代码审查
   代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步：
   (1)小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
   (2)召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
   在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。
   3．代码走查
   代码走查与代码审查基本相同，其过程也分为两步。
   (1)把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
   (2)开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
   由此可见，与代码审查相比，代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。

A

[解析] 软件经过测试，交付给用户后，在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是所谓的维护。软件维护占整个软件生命周期的60%～80%，维护的类型主要有三种：
   (1)改正性维护：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。
   (2)适应性维护：在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
   (3)完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。
   除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。
   以上各种维护过程占整个软件维护工作量比例如下图所示。
 
   有形的软件维护成本是花费了多少钱，而其他非直接的维护成本有更大的影响。例如，无形的成本可以是：
   (1)一些看起来是合理的修复或修改请求不能及时安排，使得客户不满意；
   (2)变更的结果把一些潜在的错误引入正在维护的软件，使得软件整体质量下降；
   (3)当必须把软件人员抽调到维护工作中去时，就使得软件开发工作受到干扰。
   软件维护的代价是在生产率方面的惊人下降。有报告说，生产率将降到原来的1/40。维护工作量可以分成生产性活动(如分析和评价、设计修改和实现)和“轮转”活动(如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等)。下面的公式给出了一个维护工作量的模型：
   M=p+ke^c-d
   其中，M是维护中消耗的总工作量，p是生产性工作量，k是一个经验常数，c是因缺乏好的设计和文档而导致复杂性的度量，d是对软件熟悉程度的度量。
   这个模型指明，如果使用了不好的软件开发方法(未按软件工程要求做)，原来参加开发的人员或小组不能参加维护，则工作量(及成本)将按指数级增加。
   在软件开发过程中，错误纠正成本在逐步放大。也就是说，错误发现得越早，纠正错误所花费的成本就会越低，反之则越高。例如，如果在软件设计阶段有个错误未被发现，而待编码阶段时才发现，这时，纠正这个设计错误比纠正源代码错误需要更大的成本。